Determine the kind of Software
Tags: books, softwaredevelopment, computerscience, devjournal
Published: 2021-08-27 20:06:06


## 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](https://cdn.hashnode.com/res/hashnode/image/upload/v1630089987527/iPsNh7Adq.png)
<br>

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](https://cdn.hashnode.com/res/hashnode/image/upload/v1630088826811/lxW77-9ip.jpeg)  |  ![tabular representation of costs when prerequisites are focused in both approaches](https://cdn.hashnode.com/res/hashnode/image/upload/v1630088856875/HIynBJs1J.jpeg)



> 
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](https://cdn.hashnode.com/res/hashnode/image/upload/v1630090425063/eehHslclL.jpeg)

***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.
<br>

----


## How to choose between Iterative and Sequential Approaches

![a thinking gorilla](https://cdn.hashnode.com/res/hashnode/image/upload/v1630090559663/EQEDpe_G4.jpeg)
</br>
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](https://cdn.hashnode.com/res/hashnode/image/upload/v1630090922688/yRXfulcNp.jpeg)

![tabular comparison of more good practices](https://cdn.hashnode.com/res/hashnode/image/upload/v1630090930422/UtU9TwSu4.jpeg)