Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
August 27, 2021 08:06 pm GMT

Determine the kind of Software

Iterative approach effect on prerequisite

Different kinds of software projects need different balances between preparation and construction.

(scroll to the Appendix at the end to see some good practices for common kind of software practices)

Some projects need iterative & some need sequential approach.

A misinformed opinion is that iterative techniques don't need to focus on prerequisites.
However in reality, Iterative approaches only tend to reduce the impact of inadequate upstream work, but they dont eliminate it.

poster showing stop misinformation slogan

Example table below compares 2 approaches with respect to prerequisites. Approach 1 relies solely on testing & discovers defects later, making the cost higher, and Approach 2 discovers defects iteratively as the project progresses.

Skipping PrerequisitesFocusing on Prerequisites
tabular representation of skipping prerequisite cost in both approachestabular representation of costs when prerequisites are focused in both approaches

A focus on prerequisites can reduce costs regardless of whether you use an iterative or a sequential approach.

Most projects are neither completely sequential nor completely iterative. It isnt practical to specify 100% of the requirements or design up front.

thumb image

One common rule of thumb is to plan to specify about 80 percent of the requirements up front, and then practice systematic change control to accept only the most valuable new requirements. Another alternative is to specify only the most important 20 percent of the requirements up front and plan to develop the rest of the software in small increments.

How to choose between Iterative and Sequential Approaches

a thinking gorilla

You might choose a more sequential (upfront) approach when:

  • requirements are fairly stable.
  • design is straightforward and well understood.
  • development team is familiar with the applications area.
  • project contains little risk.

You might choose a more iterative (as-you-go) approach when:

  • requirements are not well understood.
  • design is complex.
  • development team is unfamiliar with the applications area.
  • project contains a lot of risk.

Appendix

Table: Good practices for 3 common kinds of projects

tabular comparison of good practices

tabular comparison of more good practices


Original Link: https://dev.to/prakh_r/determine-the-kind-of-software-4m4k

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To