With a number of SDLC models to choose from, how can you be sure to select the most suitable methodology for the job in hand? Operations, in response to the rapid speed of change and growth in organizations, need to deliver in a fast paced and efficient environment. Because system technicalities are often highly complex, the usual process is to create structure by using a workflow methodology. In an earlier post, we discussed the merits of the Software Development Life Cycle (SDLC), which has seven distinct phases:
For large systems, each contributing activity can be intricate, so to help navigate we require methodologies and procedures that will efficiently guide and support those activities. Numerous models, such as waterfall, iterative/incremental, prototype, agile and v-shape, have been developed in response to particular situations. In this article, we will analyze each model one by one.
Waterfall was proposed by the software development pioneer, Winston Royce in 1970, and follows a linear and sequential model. It follows the phases of requirement analysis, design, coding, testing, and implementation. In this model, when operation in one phase has been completed or carried out, the framework does not allow return, so we cannot go back or repeat the same phase again. Equally, the next phase in the sequence cannot be started until the work in the previous phase has been completed.
- The project is divided into sequential phases
- Strong emphasis is placed on planning, time, target dates, budget, and implementation
- Strict controls are in place through written documentation so that all requirements will be fulfilled before moving into the next phase
- Each stage has well defined milestones or deliverables
- The model is simple to use and easy to understand
- Suitable for less experienced project teams
- Returning to earlier phases is unsupported
- The client is often unclear on what are the exact requirements
- Occasionally, problems are not apparent until the testing phase
Situation where most appropriate
- When a project has clear objectives and solutions
- When there are enough well defined requirements, which should be comprehensive and unambiguous
- When team members may be inexperienced
Iterative / Incremental Model
This model combines both a linear and iterative process. The project is divided into smaller parts so the result of every increment can be used for the input of the next increment. In this way, the development team can readily demonstrate a result, and get timely feedback from the client. Each iteration in this model functions as a mini-waterfall model, so feedback from one phase can be utilized in the second phase for development. When the product is eventually delivered following every individual increment, the client then provides the feedback on the whole. On the basis of the provided feedback, the next increment is planned and modifications are then adjusted.
- Useful where requirements are not well understood
- A working system can be generated quickly and early
- The development team(s) can get feedback after every increment
- This model offers flexibility for the customer
- Testing and debugging is easy during every iteration
- More managerial attention is required for adjusting the frequently changing environment
- Problem may arise with architecture because not all requirements are gathered up front
Situation where most appropriate
- For large projects
- When requirements are not well understood due to reasons such as expectations, or budget
- When projects are related to a web information system, event driven system, etc.
This model is a developmental approach where incomplete versions are deployed. Prototype is not a standalone or complete development methodology. Before freezing coding and design requirements, a prototype is developed according to the requirements provided by the client. The purpose of this model is to provide a working but basic system to the client for assessment. This way, the developer and designer can get early feedback, so be able to create meaningful deadlines and milestones. Another useful element to this model is that it reduces overall risk, and the project is divided into smaller segments, allowing ease of change during the development process.
- The customer gains an early idea of the final system by assessing the prototype
- The prototype is cost effective because adaptations can be made earlier in the process
- Development speed is increased
- Difficult functions and missing functionalities are more easily identified
- Prototypes can give the customer the mistaken impression that the system is complete. The system might looks good, and have adequate UI, but the functionality will not be complete
- If client is not satisfied with the prototype, then money and effort will have been wasted
- With too many changes, the rhythm of development may disturbed
Agile methodology uses short iterative cycles often call sprints and relies on the knowledge of team members, rather than documentation. The term ‘Agile’ came into use in 2001, following a meeting between seventeen process methodologists discussing future trends in software development.
Characteristics of Agile
Agile software development experts, Highsmith and Cockburn, are of the view that agile recognizes that people are the primary drivers of a project’s success if the emphasis is put on its effectiveness.
- A greater flexibility for responding to frequent changing requirements
- In Agile, no guesswork is involved between team and the customer, as there is regular communication and continuous input
- For relatively small projects, agile can be costly
- For larger projects, it can be difficult to judge the amount of effort and time required to complete the project. Experienced team members are in a better position to provide milestones
- Due to the above, less-experienced or junior resources cannot properly contribute until is combined with senior members
This model is considered as the extension of the waterfall model and demonstrates the relationship of each phase in the development lifecycle and associated test phase. The purpose of this model is to improve efficiency and effectiveness in the software development lifecycle. Once the system is functional and all the activities are executed, if they are not maintained properly, then all the efforts will have been in vain. In V-Model, the developer and tester work in parallel and joint approval must be given before the system can move into the next phase.
- Testers are involved in the requirement phase
- Requirements can be changed at any stage
- The model is rigid and inflexible
- If any changes occur in the midway, then not only the requirement documents need to be updated but the test documentations as well
- The model is not appropriate or suggested for, short term projects
If requirements change frequently, and delivery is expected in a short time period, then the Agile methodology should be adopted. If requirements have clarity and the project is also large, then the most often the Waterfall model is used. But if requirements frequently change, and proper validation is required at each phase with the tester involved from the initial phase of the project, then the V-Model may be appropriate.