About SDLC Models
Software Development Life Cycle ( also called SDLC Models ) is a workflow process which defines the core stages and activities of development cycles or A framework that describes the operations performed at each phase of a software development project.
SDLC Models
The SDLC aims to produce high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.
Some of the SDLC Models are as follows
- Waterfall Model
- Incremental SDLC Model
- Spiral Model
- Evolutionary Prototyping Model
- Agile Model
- RAD Model
1) Waterfall Model
- It is one of the oldest and most well-known SDLC models
- It follows a sequential step-by-step process from requirements analysis to maintenance.
- Systems that have well-defined and understood requirements are a good fit for the Waterfall Model
Waterfall Model Strong Points
- Easy to understand, easy to use
- Provides structure to inexperienced staff
- Milestones are well understood
- Sets requirements stability
- Good for management control (plan, staff, track)
- Works well when quality is more important than cost or schedule
Limitation of the Waterfall Model
- Not suitable for the project where requirements are changing.
- The high amount of risk and uncertainty
- Not good for the object-oriented project
- Poor model for long and ongoing project
- Can give a false impression of progress
- Integration is one big bang at the end
- Little opportunity for the customer to preview the system
Suitable Situation to use Waterfall Model
- Work well for a small project
- When Requirements are very well known
- When Product definition is stable
- When Technology is understood
- When New version of an existing product
- When Porting a current product to a new platform.
2) Incremental SDLC Model
- In this model, it constructs a partial implementation of a total system that is divide project into builds then slowly add functionality in each build.
- The incremental model prioritizes the requirements of the system and then implements them in groups.
- Each subsequent release of the system adds function to the previous version until all designed functionality has been implemented.
Incremental Model Strong Points
- Develop high-risk or major functions first
- Each release delivers an operational product
- The customer can respond to each build
- Uses “divide and conquer” breakdown of tasks
- Lowers initial delivery cost
- Initial product delivery is faster
- Customers get important functionality early
- Risk of changing requirements is reduced
Incremental Model Limitations
- Requires good planning and design
- Needs an early definition of a complete and fully functional system to allow for the definition of increments
- Well-defined module interfaces are required (some will be developed long before others)
- The total cost of the complete system is higher than the waterfall model
Suitable Situation to use Incremental Model
- Risk, funding, schedule, program complexity, or need for early realization of benefits.
- Most of the requirements are known up-front but are expected to evolve over time
- A need to get basic functionality to the market early
- On projects which have lengthy development schedules
- On a project with new technology
3) Spiral SDLC Model
- It is a “risk-driven” iterative model
- It divides a project into iterations
- Each iteration deals with 1 or more risks
- Each iteration starts with a small set of requirements and goes through the development phase (except Installation and Maintenance) for those set of requirements.
Spiral Model Strong Points
- It provides an early indication of insurmountable risks, without much cost
- Development phases can be determined by the project manager, according to the complexity of the project.
- Users can be closely tied to all lifecycle steps and can see the system early because of rapid prototyping tools
- Project monitoring is very effective. Each phase requires a review from concerned people (Early and frequent feedback from users). This makes the model more transparent. The design does not have to be perfect
- Estimates such as budget and schedule become more realistic as work progressed because important issues are discovered earlier.
- Manages risks and develops the system into phases.
- Changes can be introduced later in the life cycle as well.
Spiral Model Limitations
- Time spent on evaluating risks too substantial for small or low-risk projects
- Time spent planning, resetting objectives, doing risk analysis and prototyping may be excessive
- The model is complex
- Risk assessment expertise is required
- Spiral may continue indefinitely
- Maybe hard to define the objective, verifiable milestones that indicate readiness to proceed through the next iteration
- High cost and time to reach the final product.
- Needs special skills to evaluate the risks and assumptions.
Suitable Situation to use Spiral Model
- When the creation of a prototype is appropriate
- When costs and risk evaluation is important
- For medium to high-risk projects
- For Long-term project commitment unwise because of potential changes to economic priorities
- When users are unsure of their needs
- When requirements are complex
- For New product line
- When Significant changes are expected (research and exploration)
4)Evolutionary Prototyping Model
- Developers build a prototype during the requirements phase
- The prototype is evaluated by end users
- Users give corrective feedback
- Developers further refine the prototype
- When the user is satisfied, the prototype code is brought up to the standards needed for a final product.
Steps in Prototyping SDLC Models
- A preliminary project plan is developed
- A partial high-level paper model is created
- The model is a source for a partial requirements specification
- A prototype is built with basic and critical attributes
- The designer builds the database, user interfaces, and algorithmic functions
- The designer demonstrates the prototype, the user evaluates for problems and suggests improvements.
- This loop continues until the user is satisfied
Evolutionary Prototyping SDLC Models Strong Points
- Requires user involvement
- Customers can “see” the system requirements as they are being gathered
- Developers learn from customers
- Reduce the development time
- Reduce the development cost
- Unexpected requirements accommodated
- Allows for flexible design and development
- Missing functionalities can be easily added
- Result in higher user satisfaction
Evolutionary Prototyping SDLC Models Limitations
- Too much involvement of the customer
- Insufficient analysis
- The design is of less quality
- The resulting system is harder to maintain. Overall maintainability may be overlooked
- A prototype is a quick-and-dirty” solution
- The customer may want the prototype delivered.
- The process may continue forever
Suitable Situation to use Evolutionary Prototyping SDLC Models
- When requirements are unstable or must be clarified
- For developing user interfaces
- For Short-lived demonstrations
- For the new, original development
- With the analysis and design portions of object-oriented development.
5)Agile Model
- The biggest problem with software development is changing requirements
- Agile processes accept the reality of change versus the hunt for complete, rigid specifications
- Speed up or bypass one or more life cycle phases
- Usually less formal and reduced scope
- Used for time-critical applications
- Used in organizations that employ disciplined methods
Agile Model Strong Points
- It can adapt well with changing requirement
- Deliver a working product faster than a conventional linear development model
- Customer feedback at every stage ensures that the end deliverable satisfies their expectations
- No guesswork between the development team and the customer, as there is face to face communication and continuous inputs from the client
- Decrease the time required to avail some system features.
- A test can be conducted during the design cycle
- Fewer risks and has more flexibilities
- Modification in the system needs less time
- The result is high-quality software in the least possible time duration and satisfied customer.
Agile Model Limitations
- More Programmer centric than user-centric
- For larger projects, it is difficult to judge the efforts and the time required for the project in the SDLC.
- Since the requirements are ever-changing, there is hardly any emphasis, which is laid on designing and documentation. Therefore, chances of the project going off the track easily are much more
- Scalability
- The ability and collaboration of the customer to express user needs.
- Documentation is done at later stages.
- Reduce the usability of components.
- Needs special skills for the team.
Rapid Application Development Model (RAD)
Phases in the RAD model are as follows,
- Requirements planning phase – a workshop utilizing structured discussion of business problems
- User description phase – automated tools capture information from users
- Construction phase – productivity tools, such as code generators and screen generators
- Cutover phase – installation of the system, user acceptance testing and user training
RAD Model Strong Points
- Reduced cycle time and improved productivity with fewer people means lower costs
- Time-box approach mitigates cost and schedule risk
- It increases the reusability components
- Greater customer satisfaction
- Fast delivery time
- Reduce the development time
- The focus moves from documentation to code (WYSIWYG).
- Uses modeling concepts to capture information about business, data, and processes.
RAD Model Limitations
- Large manpower is required to create the number of RD teams.
- Risk of never achieving closure
- Hard to use with legacy systems
- Requires a system that can be modularized
- Require highly skilled developer and designer.
- Not useful when technical risks are high
- Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.
Suitable Situation to use RAD Model
- Reasonably well-known requirements
- The user involved throughout the life cycle
- The project can be time-boxed
- Functionality delivered in increments
- High performance not required
- Low technical risks
- The system can be modularised