DEV Community

Cover image for Determine the kind of Software
Prakhar Yadav
Prakhar Yadav

Posted on • Originally published at prakhar.hashnode.dev

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 don’t 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 Prerequisites Focusing on Prerequisites
tabular representation of skipping prerequisite cost in both approaches tabular 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 isn’t 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

Top comments (0)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.