How do we choose a development approach?
On this page 1 headings
Mostly YES answers suggest Plan and Document; mostly NO answers suggest Agile.
A no answer suggests Agile; a yes suggests Plan and Document
| # | Decision question |
|---|---|
| 1 | Is specification required? |
| 2 | Are customers unavailable? |
| 3 | Is the system to be built large? |
| 4 | Is the system to be built complex (e.g., real time)? |
| 5 | Will it have a long product lifetime? |
| 6 | Are you using poor software tools? |
| 7 | Is the project team geographically distributed? |
| 8 | Is team part of a documentation-oriented culture? |
| 9 | Does the team have poor programming skills? |
| 10 | Is the system to be built subject to regulation? |
I. Sommerville, Software Engineering, Ninth Edition, Addison-Wesley, 2010.
If requirements/specifications must be fixed upfront → Plan and Document. If clients are unavailable most of the time → Plan and Document.
Large or very complex systems such as an air missile system or a nuclear power plant have no margin for error, so extensive planning and documentation are necessary.
If the team is geographically distributed or already familiar with a documentation model → Plan and Document.
Systems subject to regulation, e.g. banking software that needs approvals from banks and the government, need upfront planning and documentation.
The approach depends on the clients, the characteristics of the system and the team. Once you work in a software company, different teams and organisations will use different processes based on these factors.
REMEMBER Pick an approach based on the client, the system and the team - not just a fashionable method.