Software Development Life Cycle (SDLC)

Overview 

The Software Development Life Cycle (SDLC) is a systematic process that development teams use to produce high-quality software, that meets customer expectations, in a cost-effective way. It provides a methodical, step-by-step approach to developing successful software, including gathering the initial requirements for a new product, through to maintaining a mature product on the market. The SDLC is used by both large and small software organizations.

Teams follow development models ranging from Waterfall to Agile and others. Determining which SDLC is right for your project depends heavily on not just the expected outcome, but the parameters by which the project is executed. Since there's no one-size-fits-all approach to software development, it's important for software project managers, architects, and team leads to grasp the different options at their disposal before making a decision that affects the budgeting, staffing, and management of software delivery.

Why SDLC? 

• Offers a basis for project planning, scheduling, and estimating
• Provides a framework for a standard set of activities and deliverables
• It is a mechanism for project tracking and control
• Increases visibility of project planning to all involved stakeholders 
• Increase development speed
• Improved client relations

Knowledge of the SDLC can be used by anybody that contributes to software development, including product teams, management, etc. 

Skills Covered: Software Project Management, Software Development Life Cycle (SDLC) 

"If you fail to plan, you are planning to fail!" Benjamin Franklin

SDLC Phases

These are the standard stages of the SDLC: 

1. Requirement Gathering and Analysis (i.e. Planning)
2. Design
3. Implementation (i.e. Coding / Development)
4. Testing
5. Deployment
6. Maintenance

Most popular SDLC Models

Traditional

1. Waterfall Model (e.g. smaller projects; sequential phases): 1) Requirement Analysis ? 2) System Design ? 3) Implementation ? 4) Testing ? 5) Deployment ? 6) Maintenance
2. Iterative Model (e.g. large projects; multiple builds/versions): Requirements ? Build(s) ? Design & Development ? Testing ? Implementation (then repeat). 
3. Spiral Model (e.g. medium to high-risk projects; long-term project commitment; emphasis on risk analysis): The Spiral model takes a cue from the Iterative model and its repetition. The project passes through four phases over and over in a “spiral” until completed, allowing for multiple rounds of refinement. The spiral model has four phases: 1) Requirements ? 2) Risk Analysis ? 3) Engineering ? 4) Evaluation 
4. V-Shaped Model (e.g. short projects; emphasis on testing): The V-Model, also called the "Validation and Verification" model, is an extension of the Waterfall model. It is based on the association of a testing phase for each corresponding development stage: Coding (center point of 'V') + Verification Phases (Analysis & Design) + Validation Phases (Testing). 
5. Big Bang Model (e.g. small projects with very small developent teams and very little planning): The Big Bang Model is an SDLC model that does not follow any specific process. It focuses all possible resources into software development and coding, with very little going into planning. It is ideal where the requirements are not well understood and there is no final release date. 
6. Agile Model (adaptable iterative process): The Agile SDLC model focuses on process adaptability, rather than rather than a predictive approach like traditional SDLC models. Customer interaction is the backbone of the Agile methodology. Customer satisfaction is achieved by delivering iterations of working software. Agile Methods break the product into small incremental builds.

Modern Approaches

1. Scrum is the most popular and widely adopted Agile framework. The Development Team members, Product Owner and Scrum Master (the 3 Scrum roles) collaborate to work in short iterations of 30 days, or less, called a sprint. They start from a to do list of work items, called the product backlog and pull a subset of work items to implement in a sprint. The development team conducts their daily sync ups called daily Scrum meetings and continue to implement work items. At the end of the spring, a product increment in the form of working software is produced. 
2. Lean is a collection of principles centered on the key tenet to minimize waste. It is modelled after manufacturing pipeline of the Toyota production system - a combination of management style, working culture and production environment that was aimed at manufacturing at optimal efficiency. Lean Key Principles include: Eliminate waste, Amplify learning, Decide as late as possible, Deliver as fast as possible, Empower the team, Build in integrity, See the whole, Visualize production, and Look for bottlenecks & inefficiencies. 
3. Kanban uses a Kanban Board for communicating task progress and bottlenecks.
4. Extreme Programming or XP, is a fine-grained implementation-centric approach. XP recommends a customer-driven iterative approach with short weekly iterations, which proposes a collaborative approach where customers provide requirements, and the developers break the requirements into tasks and assign tasks to themselves. 
5. Building efficient software delivery pipeline requires cooperation between Dev and Ops teams. DevOps offers offers continuous integration / delivery / deployment and uses automation tools and Lean principles. Dev comprising of developers and testers, is the team that writes and validates software. The Ops part of DevOps related to the release part of software that involves knowledge of servers, middleware, network, storage configurations, and monitoring techniques that most developers are not comfortable with. 
6. Six Sigma was developed at Motorola in the 1980s and popularized by Jack Welch and General Electric in the 90s. Six Sigma was designed to improve the quality of the products. Statistical methods calculate the Six Sigma numbers and percentages. The sigma in Six Sigma indicates variation from a desired reference point. Higher sigma level is better because it means lesser number of defects. Six Sigma includes a five-phase process improvement cycle called the DMAIC: Define, Measure, Analyze, Improve, and Control. 

Summary

• The Software Development Life Cycle (SDLC) is a systematic process for building software that ensures the quality and correctness of the software being built
• The most notable traditional SLDC Models are: Waterfall (small projects), Iterative (large projects; incremental builds), and Agile. Modern approaches include: Scrum, Lean, Kanban, DevOps, and Six Sigma. 
• Less popular SDLC Models include: Spiral Model (emphasis on risk analysis), V-Shape Model (emhasis on testing), and Big Bang (small projects with very small Dev teams and very little planning). 
• The standard SDLC Phases are: 1) Requirements Gathering and Analysis 2) Design 3) Implementation & Coding 4) Testing 5) Deployment and 6) Maintenance. 
• Software Development is human-centric and is heavily dependent on judgement and creativity.  
• In computer scientist Alistair Cockburn's research, he determined that the most important factors for a project's success are people's interactions, effective communication and collaboration.

Agile vs. Waterfall:

A simplified version of a typical iteration cycle in agile project management: 

SDLC Tutorial 

Table of Contents

1. SDLC Overview 
2. Waterfall Model 
3. Iterative Model 
4. Spiral Model 
5. V-Model
6. Big Bang Model 
7. Agile Model
8. Additional Traditional SDLC methodologies: RAD, Prototyping, RUP
9. Modern Approaches: Scrum, Lean, Kanban, Extreme, DevOps, Six Sigma 

• Final Thoughts
• Appendix: Further Reading 

1. SDLC Overview 

1.1 What is SDLC?

The Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high quality software that meets or exceeds customer expectations, and reaches completion within times and cost estimates. It is a framework defining tasks performed at each step in the software development process. SDLC consists of a detailed plan describing how to develop, maintain, replace and alter or enhance software. The Software Development Life Cycle helps improve the quality of software and the overall development process. 

Benefits of the SDLC:

• Lowers the cost of software development
• Ensures all stakeholders have a chance to give their input in the early stages of development
• Helps developers better understand what they are building and why
• Improves the quality of the software that the organization delivers
• Shortens development timelines by preventing after-the-fact fixes
• Gives everyone on the cross-functional team an understanding of the costs and resources needed to complete the project

1.2 SDLC Phases

These are the standard stages of the SDLC: 

1. Requirement Gathering and Analysis 
2. Design
3. Implementation (i.e. Coding / Development)
4. Testing
5. Deployment
6. Maintenance

Every phase of the SDLC life Cycle has its own process and deliverables that feed into the next phase. 

1. Requirement Gathering and Analysis 

Each software development life cycle model starts with the analysis, in which the stakeholders discuss the requirements for the final product. This stage gives a clearer picture of the scope of the entire project and the anticipated issues, opportunities, and directives which triggered the project. The goal of this stage is the detailed definition of the system requirements. This helps companies to finalize the necessary timeline to finish the work of that system.

Requirement analysis is the first stage in the SDLC process. It is performed with inputs from the customer, the sales department, and domain experts in the industry. This information is then used to plan the project and to conduct the product feasibility study. There are mainly five types of feasibility checks: economical, legal, operational, technical, schedule. Planning includes identification of the risks associated with the project. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks. 

Once the requirement analysis is complete the next step is to clearly define and document the product requirements and get them approved from the customer. This is done through documentation that consists of all the product requirements to be designed and developed during the project life cycle (e.g. Software Requirement Specification aka SRS). 

2. Design 

In systems design, the design functions and operations are described in detail, including screen layouts, business rules, process diagrams, and other documentation. At this stage we also define the technologies used in the project, team load, limitations, time frames, and budget. 

Design elements describe the desired system features in detail, and they generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules, business process diagrams, pseudo-code, and a complete entity-relationship diagram with a full data dictionary. 

This design phase serves as input for the next phase of the model. For a product team, this phase would include determining the priority order of the proposed work, building a product roadmap, and obtaining stakeholder agreement on it. This will help everyone on both the development and product teams get a clearer picture of what they are aiming for.

High-Level Design (HLD):

• Brief description and name of each module
• An outline about the functionality of every module
• Interface relationship and dependencies between modules
• Database tables identified along with their key elements
• Complete architecture diagrams along with technology details

Low-Level Design(LLD):

• Functional logic of the modules
• Database tables, which include type and size
• Complete detail of the interface
• Addresses all types of dependency issues
• Complete input and outputs for every module

3. Implementation & Coding

At this stage of SDLC the actual development starts and the product is built. In the coding phase, tasks are divided into units or modules and assigned to the various developers. The development team translates the high-level overview communicated in the roadmap into a tactical set of assignments, due dates, and day-to-day work schedules.

Different high level programming languages such as C, C++, Pascal, Java and PHP are used for coding. The programming language is chosen with respect to the type of software being developed. Developer need to follow certain predefined coding guidelines. Coding is the longest phase of the Software Development Life Cycle process.

4. Testing

Testing activities are commonly part of all the stages of SDLC. However, this stage refers to the testing only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches targeted quality standards.

5. Deployment 

Once the product is tested and ready to be deployed it is released formally into the market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment (UAT - User Acceptance Testing). 

6. Maintenance 

After the product is released in the market, technical support is often offered to customers. 

The developers will need to be ready to address requests for enhancements, bug fixes, and new features. These requests will come from many sources - sales, executives, customers - but the product management team will determine which of these initiatives make it onto the product roadmap for developers to work on.

1.3 SDLC Models 

There are various software development life cycle models defined and designed which are followed during the software development process. These models are also referred as "Software Development Process Models". Each process model follows a series of steps unique to its type.

Most popular traditional SDLC models:

1. Waterfall Model
2. Iterative Model
3. Spiral Model
4. V-Shaped Model
5. Big Bang Model
6. Agile Model

Additional SDLC methodolgies: RAD, Prototyping, RUP, etc. 

2. Waterfall Model 

In the Waterfall approach the process of software development is divided into separate phases which move in a linear sequential flow. Progress through the phases can be viewed as flowing steadily downwards (like a waterfall). The next phase is started only after the defined set of goals are achieved for previous phase and it is signed off. In this model, phases do not overlap, and the outcome of one phase acts as the input for the next phase. Many traditional Waterfall projects have fixed scope because you tend to freeze the scope of one phase before starting the next. It is the earliest SDLC approach that was used for software development. 

2.1 Phases of the Waterfall Model

The sequential phases of the Waterfall model: 1. Requirement Analysis ? 2. System Design ? 3. Implementation ? 4. Testing ? 5. Deployment ? 6. Maintenance 

1. Requirement Gathering and Analysis: All possible requirements of the system to be developed are captured in this phase and documented in a Software Requirement Specification (SRS) document. 

2. System Design: The requirement specifications from first phase are studied in this phase and the system design & architecture are defined. 

3. Implementation: With inputs from the system design, the system is first developed in small programs called units, which are integrated in the next phase. Each unit is developed and tested for its functionality, which is referred to as Unit Testing. 

4. Integration and Testing: All the units developed in the implementation phase are integrated into a system after testing of each unit. Post integration the entire system is tested for any faults and failures. 

5. Deployment of system: Once the functional and non-functional testing is done, the product is deployed in the customer environment or released into the market. 

6. Maintenance: Issues can come up in a client environment. To fix those issues, patches are released. To enhance the product, improved versions are released. Maintenance is done to deliver these changes in the customer environment. 

2.2 Waterfall Model ─ Pros and Cons 

Advantages of the Waterfall SDLC Model:

• Simple and easy to understand and use.
• Processes and final product are generally very well documented in a Waterfall project. 
• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process. 
• Phases are clearly defined and completed one at a time. A schedule can be set with deadlines for each phase of development.
• Works well for small or mid-sized projects where requirements are well understood. 
• Well understood milestones. 
• Easy to arrange tasks. 

Disadvantages of the Waterfall SDLC Model:

• No working software is produced until late during the life cycle. 
• Frozen requirements (change orders).
• High amounts of risk and uncertainty. 
• Poor model for complex, long and ongoing projects. 
• Does not easily allow for revisions. Since there is little room for revisions once a stage is completed, problems can’t be fixed until you get to the maintenance stage. 
• Not suitable for the projects where requirements are at a moderate to high risk of changing and flexibility is needed. 
• Early delays can throw off the entire project timeline. 
• Precedence of detailed checklists/control processes over people.

Use cases for the Waterfall SDLC model:

• Short projects. Simple systems.
• Product definition is stable. The requirements are precisely documented, with no ambiguity. 
• The technologies stack is predefined, not dynamic.
• Enhancements done as part of ongoing maintenance.
• Mission critical systems where gated phases required (e.g. Medical)

3. Iterative Model

An Iterative life cycle model does not attempt to start with a full specification of requirements. Instead, development begins by specifying and implementing just part of the software (i.e. subset of the requirements), which is then reviewed (i.e. tested & evaluated) to identify further requirements. This process is then repeated, producing a new version of the software with each iteration. 

The Iterative model is most often used when: 

• Major requirements must be defined; however, some functionalities or requested enhancements may evolve with time. 
• There is a time to market constraint. 

3.1 Iterative Model ─ Application 

Iterative process starts with a simple implementation of a subset of the software requirements and iteratively enhances the evolving versions until the full system is implemented. At each iteration, design modifications are made and new functional capabilities are added. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental). 

Iterative Development Model: 

In this incremental model, the whole requirement is divided into various builds. During each iteration, the development module goes through the requirements, design, implementation and testing phases. Each subsequent release of the module adds function to the previous release. 

The key to a successful use of an iterative software development life cycle is rigorous validation of requirements, and verification & testing of each version of the software against those requirements within each cycle of the model. As the software evolves through successive cycles, tests must be repeated and extended to verify each version of the software. 

3.2 Iterative Model - Pros and Cons 

Advantages of the Iterative SDLC Model:

• There is working functionality very early stage of development, which makes it easier to find functional or design flaws. 
• It supports changing requirements. 
• Results are obtained early and periodically. Software produced early facilitates customer evaluation and feedback. 
• Parallel development can be planned. 
• Progress can be measured. 
• Testing and debugging during smaller iterations is easy. 
• Easier to manage risk - High risk part is done first. 
• Risks are also identified and resolved during each iteration and each iteration is an easily managed milestone. 
• Issues, challenges and risks identified from each increment can be utilized / applied to the next increment. 

Disadvantages of the Iterative SDLC Model:

• More resources may be required (e.g. compared to Waterfall). 
• More management attention is required. 
• System architecture or design issues may arise because not all requirements are gathered in the beginning of the entire life cycle. 
• The Iterative Model is applicable only to large and bulky software development projects. It is not suitable for smaller projects. This is because it is hard to break a small software system into further small serviceable increments/modules. 
• Risks analysis requires involvement of the highly-qualified specialists.
• Resources can quickly be eaten up by repeating the process again and again.

Use cases for the Iteration model: 

• Better suited for large projects. 
• The main task is predefined, but the details may advance with the time.

4. Spiral Model 

The Spiral Model was developed by Barry Boehm in 1986. The Spiral model is a hybrid approach that uses both Waterfall and iterative approaches with a very high emphasis on risk analysis. It includes a series of waterfalls. Each waterfall builds on top of the previous one to build a system iteratively.

This method is consistent with approaches that have multiple software builds and releases. It allows incremental releases of the product or incremental refinement through each iteration around the spiral. 

4.1 Spiral Model ─ Application 

The spiral model has four phases. A software project repeatedly passes through these phases in iterations called Spirals. 

1. Requirements: This phase starts with gathering the business requirements in the baseline spiral. In the subsequent spirals as the product matures, identification of system requirements, subsystem requirements and unit requirements are all done in this phase. This phase also includes understanding the system requirements by continuous communication between the customer and the system analyst. 

2. Risk Analysis: Risk Analysis includes identifying, estimating and monitoring the technical feasibility and management risks, such as schedule slippage and cost overrun. 

3. Engineering (Construct or Build): The Construct phase refers to production of the actual software product at every spiral. In the baseline spiral, when the product is just thought of and the design is being developed a POC (Proof of Concept) is developed in this phase to get customer feedback. Then in the subsequent spirals with higher clarity on requirements and design details a working model of the software called a build is produced with a version number. These builds are sent to the customer for feedback. 

4. Evaluation: At the end of first iteration, the customer evaluates the software and provides feedback. 

The following illustration is a representation of the Spiral Model:

Based on the customer evaluation, the software development process enters the next iteration. The process of iterations along the spiral continues throughout the life of the software. 

Building software iteratively leads to identification and easier management of risks. As you build a system, you get a better understanding of the requirements and continue to mitigate risks. 

The following are typical uses of the Spiral Model: 

• When there is a budget constraint and risk evaluation is important. 
• For medium to high-risk projects. 
• Long-term project commitment because of potential changes to economic priorities as the requirements change with time. 
• Customer is not sure of their requirements which is usually the case. 
• Requirements are complex and need evaluation to get clarity. 
• Significant changes are expected in the product during the development cycle. 

4.2 Spiral Model ─ Pros and Cons 

Advantages of the Spiral SDLC Model: 

• Development can be divided into smaller parts and the risky parts can be developed earlier on, which helps in better risk management. 
• The development process is precisely documented yet changing requirements can be accommodated. 
• Users see the system early. 
• Forces an early user involvement in the system development effort.

Disadvantages of the Spiral SDLC Model:

• Not suitable for small or low risk projects and could be expensive for small projects. 
• Risk control demands involvement of highly-qualified professionals. 
• Management is more complex. 
• Large number of intermediate stages requires excessive documentation. 
• The risk of creating a never-ending spiral for a project that goes on and on.

Use cases for the Spiral model:

• Customer isn’t sure about the requirements
• Major edits are expected during the development cycle
• The projects with mid or high-level risk, where it is important to prevent these risks

5. V-Shaped Model 

The V-model is known as Verification and Validation model. It is an SDLC model where execution of processes happens in a sequential manner, in a V-Shape. 

The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each corresponding development stage. This means that for every single phase in the development cycle, there is a directly associated testing phase. This is a highly-disciplined model and the next phase starts only after completion of the previous phase. 

Under the V-Model, the corresponding testing phase of the development phase is planned in parallel. So, there are Verification phases on one side of the ‘V’ and Validation phases on the other side. The Coding Phase joins the two sides of the V-Model.

 The following illustration depicts the different phases in a V-Model of the SDLC: 

5.1 Verification Phases 

There are several Verification phases in the V-Model, each of these are explained in detail below. 

Requirement Analysis 

This is the first phase in the development cycle where the product requirements are understood from the customer’s perspective. This phase involves detailed communication with the customer to understand their expectations and exact requirement. This is a very important activity and needs to be managed well, as most of the customers are not sure about what exactly they need. The acceptance test design planning is done at this stage.

High Level Design (System & Architectural) 

Once you have the clear and detailed product requirements, it is time to design the complete system. The system design will have the understanding and detailing the complete hardware and communication setup for the product under development. The system test plan is developed based on the system design. 

Architectural specifications are understood and designed in this phase. Usually more than one technical approach is proposed and based on the technical and financial feasibility the final decision is taken. The system design is broken down further into modules taking up different functionality. 

The data transfer and communication between the internal modules and with the outside world (other systems) is clearly understood and defined in this stage. With this information, integration tests can be designed and documented during this stage. 

Detailed Design (Module Design)

In this phase, the detailed internal design for all the system modules is specified. It is important that the design is compatible with the other modules in the system architecture and other external systems. Unit tests are an essential part of any development process and help eliminate any faults or errors at a very early stage. 

5.2 Implementation Phase (Coding)

The actual coding of the system modules that were designed in the design phase are taken up in the Implementation phase. The most suitable programming language is decided based on the system and architectural requirements. 

The coding is performed based on the coding guidelines and standards. The code goes through numerous code reviews and is optimized for best performance before the final build is checked into the repository. 

5.3 Validation Phases 

The different Validation Phases in a V-Model are explained in detail below. 

Unit Testing 

Unit tests designed in the module design phase are executed on the code during this validation phase. Unit testing is the testing at code level and helps eliminate bugs at an early stage, though all defects cannot be uncovered by unit testing. 

Integration Testing 

Integration testing is associated with the architectural design phase. Integration tests are performed to test the co-existence and communication of the internal modules within the system. 

System & Acceptance Testing 

System testing is directly associated with the system design phase. System tests check the entire system functionality and the communication of the system under development with external systems. 

Acceptance testing is associated with the business requirement analysis phase and involves testing the product in user environment. Acceptance tests uncover the compatibility issues with the other systems available in the user environment. It also discovers the non-functional issues such as load and performance defects in the actual user environment.

5.4 V- Model ─ Application 

V-Model application is almost the same as the waterfall model, as both the models are of sequential type. Requirements have to be very clear before the project starts, because it is usually expensive to go back and make changes. This model is used in the medical development field, as it is strictly a disciplined domain. 

The following pointers are some of the most suitable scenarios to use the V-Model application. 

• Requirements are well defined, clearly documented and fixed. 
• Product definition is stable. 
• There are no ambiguous or undefined requirements. 
• The project is short. 

5.5 V-Model ─ Pros and Cons 

Advantages of the V-Model:

• Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process. 
• Testing and verification take place in the early stages. 
• Works well for smaller projects where requirements are very well understood. 

Disadvantages of the V-Model:

• Not flexible to changes.
• No working software is produced until late during the life cycle. 
• Not suitable for the projects where requirements are at a moderate to high risk of changing. 
• Once an application is in the testing stage, it is difficult to go back and change a functionality. 

Use cases for the V-shaped model:

• Good for the small and mid-sized projects, where requirements are strictly predefined, and accurate product testing is required.
• Not a good model for long, complex and ongoing projects. 

6. Big Bang Model 

A bit of an anomaly among SDLC methodologies, the Big Bang model follows no specific process, and very little time is spent on planning. The majority of resources are thrown toward development, and even the client may not have a solid grasp of the requirements. The requirements are implemented on the fly without much analysis. The output is software developed which may or may not be as per customer requirement. This methodology is typically used for small projects with only one or two software engineers.

6.1 Big Bang Model ─ Application 

The Big Bang Model focuses all possible resources in the software development and coding, with very little going into planning. The requirements are understood and implemented as they come. Any changes required may or may not need to revamp the complete software. 

This model is ideal for small projects with one or two developers. It is an ideal model for projects where requirements are not well understood and the final release date is not given. 

6.2 Big Bang Model ─ Pros and Cons 

Advantages of the Big Bang SDLC Model:

• This is a very simple model.
• Little or no planning required. 
• Easy to manage. 
• Very few resources required. 
• Gives flexibility to developers. 
• It is a good learning aid for new comers or students. 

Disadvantages of the Big Bang Model SDLC Model:

• Very High risk and uncertainty. 
• Not a good model for complex, long and ongoing projects, as it’s a high-risk model; if the requirements are misunderstood in the beginning, you could get to the end and realize the project may have to be started all over again. 
• Can turn out to be very expensive if requirements are misunderstood. 
• Changes in the requirements or misunderstood requirements may even lead to complete reversal or scraping of the project. 
• It is ideal for repetitive or small projects with minimum risks. 

7. Agile Model 

The Agile SDLC model is an iterative process that produces ongoing releases, each with small, incremental changes from the previous release. It has a focus on process adaptability and customer satisfaction through rapid delivery of working software product. The Agile method splits the product into small incremental builds (e.g. every month). Agile has become popular due to its flexibility and adaptability. 

Every iteration involves cross functional teams working simultaneously on various areas like:

• Planning 
• Requirements Analysis 
• Design 
• Coding 
• Unit Testing 
• Acceptance Testing

Here is a graphical illustration of the Agile Model: 

7.1 What is Agile? 

In the Agile method, the entire project is divided into small incremental builds. All of these builds are provided in iterations (or small development cylces called sprints).

After every development iteration, the customer and important stakeholders are able to see the result (i.e. a working product) and understand if he is satisfied with it or he is not. This is one of the advantages of the agile software development life cycle model. 

This model emphasizes interaction, as the customers, developers and testers work together throughout the project. But since this model depends heavily on customer interaction, the project can head the wrong way if the customer is not clear on the direction he or she wants to go.

The most popular Agile methods include Rational Unified Process (1994), Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These are now collectively referred to as Agile Methodologies, after the Agile Manifesto was published in 2001. 

7.2 The Manifesto for Agile Software Development

Agile Software Development Values

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Agile Software Development Principles:

1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Deliver working software frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the primary measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity — the art of maximizing the amount of work not done — is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly

7.3 Agile Vs Traditional SDLC Models 

Agile is based on adaptive software development methods, whereas the traditional SDLC models, like the waterfall model, are based on a predictive approach. Predictive teams in the traditional SDLC models usually work with detailed planning and have a complete forecast of the exact tasks and features to be delivered in the next few months or during the product life cycle. 

Predictive methods entirely depend on the requirement analysis and planning done in the beginning of cycle. Any changes to be incorporated go through a strict change control management and prioritization. 

Agile uses an adaptive approach where there is clarity on future tasks only in respect of what features need to be developed. There is feature driven development and the team adapts to the changing product requirements. The product is tested frequently, with each release iteration.

Customer interaction is the backbone of the Agile methodology. The agile teams work in close collaboration with each other and are most often located in the same geographical location. 

Agile vs. Waterfall:

How Does the Software Development Lifecycle Work with Agile Sprints?

A typical agile sprint lasts between 1 and 4 weeks. The team will start each sprint with a sprint planning session. At this time, the cross-functional team reviews the backlog. Then, they determine a few strategically advantageous projects to work on and assign tasks. They will then focus only on those projects and test their work at the end of the sprint. Finally, they will move on to the next sprint. Breaking up the process this way allows agile organizations to quickly and frequently release new functionality to the market. This frees them from having to wait to build an entire product before releasing anything.

7.4 Agile Model ─ Pros and Cons 

Advantages of the Agile SDLC Model: 

• Project is divided by short and transparent iterations. 
• Risks are minimized thanks to the flexible change process. 
• Delivers an early partially working solution. 
• Functionality can be developed rapidly and demonstrated. 
• Enables concurrent development and delivery within an overall planned context. 

Disadvantages of the Agile SDLC Model:

• Depends heavily on customer interaction, so if the team is not client-orientated or the customer is not clear, the team can be driven in the wrong direction. 
• New requirements may conflict with the existing architecture.
• With all the corrections and changes there is possibility that the project will exceed expected time.
• Strict management is required to dictate the scope, functionality to be delivered, and adjustments to meet the deadline for each build. 

Use cases for the Agile model:

• The users’ needs change dynamically.
• Reduced cost for implementing change requests because of the many iterations.
• Unlike the Waterfall model, it requires only initial planning to start the project.

7.5 Dynamic Systems Development Method (DSDM) 

Early Agile Methods include: Dynamic Systems Development Method (DSDM) , Crystal Methods, and Feature-driven development (FDD).

Origin of DSDM: Waterfall ? Rapid Application Development ? Dynamic System Development Method 

DSDM History:

• Developed in 1994. DSDM Consortium was formed in 1994. 
• DSDM Handbook made public in 2014. 
• DSDM Consortium renamed Agile Business Consortium in 2016.

DSDM Life Cycle: 

• Pre-project: Analysis, feasiblity, business case for project 
• Project life cycle: Iterative development, timeboxing, MoSCow 
• Post-porject: Determine if the expected benefits of the project have been realized

DSDM Principles 

1. Focus on business need 
2. Deliver on time 
3. Collaborate 
4. Never compromise 
5. Develop incrementally from firm foundations 
6. Develop iteratively 
7. Communicate continuously and clearly 
8. Demonstrate control 

Key Takeaways

• Timeboxing: Timeboxing refers to the maximum time allocated to an activity. It cannot be extended. The activity is stopped if the time period expires before the activity is done.
• MoSCoW prioritization: Must haves, Should have, Could have, Won't have)
• Iterative and incremental approach 

Resources

• Agile Business Consortium Website
• View and download templates 
• DSDM Principles

8. Additional Traditional SDLC methodologies

8.1 RAD

Rapid application development is a software development methodology that uses minimal planning in favor of rapid prototyping. The RAD (Rapid Application Development) model is based on prototyping and iterative development. A prototype is a working model that is functionally equivalent to a component of the product. 

Rapid Application Development focuses on gathering customer requirements through early testing of the prototypes by the customer, workshops or focus groups, reuse of the existing prototypes (components), continuous integration, and rapid delivery. The most important aspect for this model to be successful is to make sure that the prototypes developed are reusable. In the RAD model, the functional modules are developed in parallel as prototypes and are integrated to make the complete product for faster product delivery. 

The traditional SDLC follows a rigid process models with high emphasis on requirement analysis and gathering before the coding starts. It puts pressure on the customer to sign off the requirements before the project starts and the customer doesn’t get the feel of the product as there is no working build available for a long time. 

The RAD model focuses on iterative and incremental delivery of working models to the customer. This results in rapid delivery to the customer and customer involvement during the complete development cycle of product reducing the risk of non-conformance with the actual user requirements. Since there is no detailed planning, it makes it easier to incorporate the changes within the RAD process.

The following are the various phases of the RAD Model:

• Business Modeling
• Data Modeling
• Process Modeling
• Application Generation
• Testing and Turnover

RAD should be chosen when a system can be modularized and domain experts are available with relevant business knowledge. 

8.2 Prototyping

The Software Prototyping refers to building software application prototypes which displays the functionality of the product under development, is a working model of software with some limited functionality, but may not actually hold the exact logic of the actual software application. Prototyping is used to allow the users evaluate developer proposals and try them out before implementation. It also helps understand the requirements.

Steps Involved: 

• Basic Requirement Identification
• Developing the Initial Prototype (e.g. basic requirement & U.I.; look & feel)
• Review of the Prototype (with the customer / important stakeholders)
• Revise and Enhance the Prototype

There are different types of prototyping: Throwaway/Rapid Prototyping, Evolutionary Prototyping, Incremental Prototyping, Extreme Prototyping (web development domain; screens presented in HTML format). 

Prototypes can have horizontal or vertical dimensions. A Horizontal prototype displays the user interface for the product and gives a broader view of the entire system, without concentrating on internal functions. A Vertical prototype on the other side is a detailed elaboration of a specific function or a sub system in the product. 

The purpose of both horizontal and vertical prototype is different. Horizontal prototypes are used to get more information on the user interface level and the business requirements. It can even be presented in the sales demos to get business in the market. Vertical prototypes are technical in nature and are used to get details of the exact functioning of the sub systems. For example, database requirements, interaction and data processing loads in a given sub system. 

Software Prototyping is most useful in development of systems having high level of user interactions. Software that involves a lot of data processing, where most of the functionality is internal, and where there is very little user interaction, usually do not benefit from prototyping. 

8.3 Rational Unified Process

Rational Unified Process (RUP) was developed by Rational Software (acquired by IBM in 2003). It was an attempt to come up with a comprehensive iteractive and customizable software development process framework.  

The original RUP had six disciplines:

1. Business Modeling
2. Requirements,
3. Analysis and design,
4. Implementation,
5. Test,
6. Deployment.

RUP Principles: Develop iteratively, Manage requirements & change, Continuously verify quality, Model visually, Component-based architecture.

RUP Shortcomings: Prescriptive & Heavy (e.g. artifacts, processes, templates, phases, and disciplines). 

9. Modern Approaches 

Many teams use a combination of Scrum and Kanban, but their core values are based on Lean principles. Core values from Lean: Avoid waste, Provide business value, Deliver quickly and often. 

Lean, when combined with Six Sigma, can improve customer satisfaction and improve the quality of the goods and services that you produce. Together they help build highly optimized processes for productivity. Six Sigma may not applicable in all cases, but the knowledge of DMAIC cycle and associated techniques is surely something you want to know. 

The primary goal is to organize people together, so they benefit from each other and work together towards the shared vision of the product (rather than focusing on organizational hierarchies). Having a great culture where team members can learn from each other often leads to innovation. 

9.1 Scrum

Scrum is a lightweight, agile framework that is deceptively simple and features an iterative and incremental approach (short sprints). It was introduced by Ken Schwaber and Jeff Sutherland in 1995. Scrum in the most popular and widely adopted agile framework. The investors of Scrum defined it as a framework that is easy to understand and difficult to master. It consists of just a handful events, roles and deliverables and a small set of rules and guidelines. 

With Scrum, a small cross-functional team works in short iterations, called sprints, to create working software. The Development Team members, Product Owner and Scrum Master (the 3 Scrum roles) collaborate to work in short iterations of 30 days, or less, called a sprint. They start from a to do list of work items, called the product backlog and pull a subset of work items to implement in a sprint. The development team conducts their daily sync ups called daily Scrum meetings and continue to implement work items. At the end of the spring, a product increment in the form of working software is produced. 

A Product Owner is in charge of the Product Backlog, and prioritizing tasks / features. This is an individual, not committee, though they may be influenced by a business stakeholders.

A Scrum Master plays the role of an Agile coach and Servant Leader that facilitates removal of impediments in the path of the development team. Even though the Scrum Master has management responsibilities, they do not have administrative responsibilities over what the team does.

A Development Team consists of Developers, Testers, Documenters, DBAs, and so on. These professionals are self-organizing and cross-functional.

Scrum Artifacts / Deliverables include: 

• Product Backlog (master list) 
• Sprint Backlog (subset of product backlog selected to be implemented in the current sprint)
• Product Increment (existing product + new features)

Scrum Overview:  

• Sprint Planning 
• Sprint 
• Review 
• Restrospective (Increment) 

Stakeholders outside the Scrum team participate in the Sprint Review. This is the event when the Scrum team and group of external stakeholders get together to inspect the product increment.

Scrum Workflow

In the Daily Scrum, the Team syncs up and review progress toward sprint goal. Optional "3 Question Format": 

• What did you do since the last Daily Scrum? 
• What do I plan to do today? 
• Any impediments? 

Sprint Review: Attended by the scrum team and external stakeholders. Review product increment. Informal event, no formal acceptance. 

Sprint Restrospective: Review aspects of work other than the Product Increment itself (process, communication, skils). Prioritize/commit to improvement-related action items. 

Key Takeaways

• Business value-driven comprehensive framework 
• Potentially shippable product increment each sprint 

Resources 

• Home | Scrum Guides (Official Scrum Guide is less than 20 pages)
• What Is Scrum Methodology? & Scrum Project Management

9.2 Lean 

Lean is a collection of principles centered on the key tenet to minimize waste. It is modeled after manufacturing pipeline of the Toyota production system - a combination of management style, working culture and production environment that was aimed at reducing waste and manufacturing at optimal efficiency. The book "Lean Software Principles" by Mary and Tom Poppendieck (2003) looks at how many manufacturing philosophies and techniques could be applied to software development. 

Lean Key Principles 

• Eliminate waste: Non-value work = Waste. Avoid adding features that the customer has not asked for (commonly referred to as Gold plating) and unnessary processes. 
• Amplify learning: Get regular and frequent feedback from stakeholders.
• Decide as late as possible: Wait till we know all the facts and then make a decision at the last responsible moment. 
• Deliver as fast as possible: When you deliver working features to customers quickly and often, you are brining value to the customer. Longer iterations have bigger risks of a large number of unidentified issues, changes in market conditions, and technology changes. Smaller iterations are easier to manage. 
• Empower the team: Empowering a team fosters creativity and motivates the team to do more. People that design and build software are knowledge workers and should be given enough autonomy and support to bring out their creativity and sense of responsibility to build great solutions.  
• Build in integrity: Ensure the customer has a good overall experience of the system. 
• See the whole: Lean teams focus on understanding the entire workflow and work on optimizing the entire process rather than improving a subset of the entire workflow.  
• Visualize production 
• Look for bottlenecks, inefficiencies 

Value Stream Mapping

Value-stream mapping is a lean-management method for analyzing the current state and designing a future state for the series of events that take a product or service from the beginning of the specific process until it reaches the customer. The purpose of value-stream mapping is to identify and remove or reduce "waste" in value streams, thereby increasing the efficiency of a given value stream. Waste removal is intended to increase productivity by creating leaner operations which in turn make waste and quality problems easier to identify

It is a sequence of steps to produce a product or service with business value. In a perfect scenario, you want the value stream to have all steps with value-add and no wasteful steps. An simplified example: Order ? Delivery. It is used to identify areas of improvement, information flow, material flow, and time ladder. Time ladder identifies value-added time and non-value-added time. 

Lead Time vs. Cycle Time

• Lead Time: Total time taken from customer request to product/service delivery (greater than cycle time) 
• Cycle Time: Actual time spent working on that item 
• Goal: To make lead time equal to cycle time 

9.3 Kanban 

Kanban is a visual process management approach that is based on Lean princples. Its core values are to "visualize your work" and "limit work in progress". 

The Kanban Board is a powerful and effective communication tool for the team's progress and bottlenecks. Veritical lanes represent status (or queue) of a work item. Example Lanes: Planning/Coordination, Design, Develop, Accept. Work items such as software features, user stories, and defects are pulled into the board and processed from left to right. Within a Lane you may have 'Doing' and 'Done' statuses. A 'Done' item may not move to the next lane if the next lane has reached it's WIP Limit. All completed work items are eventually pulled to the rightmost lane. You can create a Kanban board using Lean Kit's IDE. 

Kanban Key Features

• Pull system: Items are pulled into a queue when the queue has room for more items
• No artificial time boundaries (like a sprint): Work items are delivered when they are ready
• Continuous value delivery 
• Daily standups: Beside the Kanban Board, the only other practice used by most Kanban teams is daily standups. 

9.4 Extreme 

Developed by Kent Beck (1991), Extreme Programming or XP, is a fine-grained implementation-centric approach. It focuses on short weekly iterations, collaboration, and quarterly macro-level planning.

XP recommends a customer-driven iterative approach with short weekly iterations, which proposes a collaborative approach where customers provide requirements, and the developers break the requirements into tasks and assign tasks to themselves. There's also a quarterly iteration that acts as a container for the weekly iterations and allows teams to take a more macro-level view of the work. 

Key Takeaways

• Just-in-time design 
• Pair programming 
• Test-driven development 

9.5 DevOps 

Building software involves close cooperation between two types of teams. The first team, comprising of developers and testers, is the team that writes and validates software. This is the Dev of DevOps. But good software is useful only if it can be deployed and released to your customers. The release part of software involves knowledge of servers, middleware, network, storage configurations, and monitoring techniques that most developers are not comfortable with. This is the Ops part of DevOps. Building efficient software delivery pipeline requires cooperation between Dev and Ops.

The goal is to create a fast and efficient software delivery pipeline where you release features to your customers as quickly as possible. 

Many enterprises have implemented a cultural shift towards faster delivery to market with the help of DevOps principles. 

Common Deployment Challenges: 

• Differences in configurations 
• Dependencies 
• Data 
• Other aspects of servers, storage, and network settings 

Need for DevOps:

• Frequent deployments caused problems 
• DevOps creates closer cooperation between Dev and Ops 

The Two CDs

• Continuous delivery: Ensuring stable product after every release 
• Continuous deployment: Automating updates to production 

What DevOps Is 

• Close cooperation: DevOps relies on building a culture of cooperation between developers and operations staff. Both Dev and Ops people are responsible for the entire software delivery pipeline. 
• Continuous integration, delivery, and deployment: Helps in the process of making DevOps successful. 
• Automation Tools: Successful DevOps implementation relies on automation tools. It is a good idea for developers to become familiar with these tools. However, it is important to note that tools by themselves do not make the software delivery pipeline efficient. Successful DevOps means close cooperation between Dev and Ops staff. 
• Lean principles: DevOps is based on Lean principles, where you build a fast delivery pipeline with minimal wastage. A working software feature should be available to your customers very quickly or come back to the developer very quickly if it is not ready for release. 

What DevOps Is Not 

• Replacement for Agile: DevOps is not a replacement for Agile. In fact, DevOps enables end to end agility with faster and stable deployments and so compliments traditional Agile approaches. An alternate way of looking at DevOps, is that it is an Agile approach that merges development and operations. 
• Industry buzzword: DevOps is definitely not an industry buzzword, many organizations are reaping the benefits of DevOps practices.
• Tool or technology: DevOps is not a tool or technology. It involves a cultural shift towards building an efficient pipeline that produces stable and faster delivery and healthy operational practices. 
• Way to override checks and balances: DevOps does not mean developers have the complete freedom to push a button to deploy to production. You need proper checks and balances in place to make sure your production deployments are in a stable state.

9.6 Six Sigma

Lean and Six Sigma are both focused on minimizing waste and maximizing customer value. Lean, when combined with Six Sigma, can improve customer satisfaction and improve the quality of the goods and services that you produce. 

Six Sigma originated in manufacturing and used a scientific and statistical approach to measure the quality of a process by tracking the number of defects. Six Sigma was developed at Motorola in the 1980s and popularized by Jack Welch and General Electric in the 90s. Six Sigma was designed to improve the quality of the products. Its effectiveness lead to widespread adoption by companies worldwide. The goal of Six Sigma is to reduce defects and keep the output of a process within certain limits of a baseline. 

Statistical methods calculate the Six Sigma numbers and percentages. The sigma in Six Sigma indicates variation from a desired reference point. Higher sigma level is better, so a process that is at a five sigma will produce products with fewer defects as compared to a process at four sigma. Higher sigma level is better because it means lesser number of defects.

Six Sigma and Software

Manufacturing is pure science where you can produce the same type of product repeatedly and quantifying defect is very manageable. Six Sigma generally works at a macro level, so when you are talking about Six Sigma, you're talking about high-level processes, not how you build one software product. 

Software development is part science and part art, and the procedure of measuring quality can be somewhat challenging. You're not producing tangible products repeatedly, and to make things more complex, customer expectations, team skill level, organizational culture, politics, technology, etc., are different for different projects and products. So it becomes extremely challenging to measure the Sigma level of a software development process. 

The DMAIC Cycle

Six Sigma includes a process improvement cycle called the DMAIC cycle, which may be useful for all software and non-software initiatives. DMAIC is an acronym where each letter stands for the name of a phase in this data-driven, five-phase process. The phases are: 

1) Define, this is where you define a problem or an opportunity for improvement. Value stream mapping, which we already covered in this course is one of the techniques for identifying problems. 

2) Measure, in this phase you define how you will measure performance of the activities in your process with the help of techniques such as Pareto charts. 

3) Analyze, this is the phase when you find out the cause of variation or defects. Techniques such as root cause analysis with a fish bone diagram is one such technique for finding the variations. 

4) Improve, in this phase, you apply multiple techniques for reducing the effect of, or eliminating the reasons for defects and variation. The affinity diagram is one technique, where team members write down suggestions for process improvement. And then group similar suggestions into groups, then the team chalks out an action plan for implementing those ideas. 

5) Control, an improved process needs monitoring for two reasons. One, the process has to stay at its optimum level. Secondly, there's always scope for improvement. You apply techniques such as control charts to measure output and keep outputs within allowed limits of variation. 

Lean and Six Sigma together, help you build highly optimized processes for productivity. Six Sigma may not applicable in all cases, but the knowledge of DMAIC cycle and associated techniques is surely something you want to know. 

Final Thoughts

To recap... You'll use Waterfall for smaller projects, Iterative for larger projects with incremental builds / new versions, or Agile for Iterative customer-centric projects that will use adaptive processes. There are a variety of Agile methodologies, the most popular being the Scrum. Other modern approaches include Lean, Kanban (Kanban Board), Extreme Programming, DevOps, and Six Sigma. In my experience up to this point, I've used Agile & Scrum while doing Enterprise Software Development, and used Waterflow & Extreme while doing Web Development. 

Now that you have a solid understanding of the various frameworks and methodologies, I encourage you to take a deeper dive to master the finer details. Each organization or team has unique requirements and works in a unique environment. You can choose what works for you and find your own way. I encourage you and your team to try out Agile practices that make the most sense to you. Don't be afraid of trial and error. Agile is all about continuous learning after all. Go ahead and build your own optimal path to success. Good luck.

Tip: Feature toggle reduces the need for code branching and merging.

Further Reading

SDLC 

• What is SDLC? | Software Development Lifecycle Definition and Overview [5 Pages]
• Software Development Life Cycle (SDLC)- Making Sense of the Different Methodologies [8 Pages] *
• 7 Basic Software Development Models: Which One to Choose? [9 Pages]
• Top 7 SDLC Methodologies [Complete Guide]: Agile, Waterfall [11 Pages] 
• What Is SDLC (Software Development Life Cycle) Phases & Process [14 Pages]
• The Software Development Process - Science, Engineering, Art, or Craft? - CodeProject [18 Pages]

Agile

Agile Alliance & Agile Business Consortium

• Manifesto for Agile Software Development
• Agile Glossary and Terminology | Agile Alliance
• Agile Business Consortium Website
• Agile Templates

Agile Articles

• Agile Development. Agile software development refer to a… - by Davin Iddo - Moodah POS - Medium [5 Pages]
• Your Guide To Agile Software Development Life Cycles [8 Pages]
• Agile Software Development Lifecycle Phases Explained [11 Pages]
• Agile Software Development Process – Everything You Need to Know [12 Pages]

Scrum 

• Home | Scrum Guides (Official Scrum Guide is less than 20 pages)
• What Is Scrum Methodology? & Scrum Project Management

Spotify SDLC Case Study 

• Spotify engineering culture (part 1) : Spotify Engineering
• Spotify engineering culture (part 2) : Spotify Engineering

ISO/IEC 12207 

• ISO - ISO/IEC 12207:2008 - Systems and software engineering — Software life cycle processes
• ISO - ISO/IEC/IEEE 12207:2017 - Systems and software engineering — Software life cycle processes

Wikipedia 

• Systems development life cycle [13 Pages]
• Software development process [8 Pages]
• Agile software development [16 Pages]
• Scrum (software development) [15 Pages]
• Lean product development [3 Pages]
• Kanban [5 Pages]
• Capability Maturity Model Integration [7 Pages]
• Extreme programming [10 Pages]
• DevOps [8 Pages]
• Six Sigma [12 Pages]

Free Database eBooks

• Database Management Systems QuickStart Guide
• Database Design QuickStart Guide
• SQL QuickStart Guide

Learning Resources

• LinkedIn Learning: Online Courses for Creative, Technology, Business Skills
• Best of LinkedIn Learning: Computer Science
• LinkedIn Learning Paths: Computer Science
• Best of Wikipedia: Web Development
• Best of Wikipedia: Software Development
• Computer Science & Application Development Tutorials 
• Learn Google Analytics

Featured Articles

• Top Programming Languages & Web Solution Stacks 2020 
• Building Desktop Apps
• ASP.NET Web Applications (CMS, E-commerce, etc.)
• Glossary of Database Terms
• Launching a Tech Startup
• Data Science
• Top Reporting Tools for ASP.NET (23/03/2017)
• Doing Business on Instagram, The 5 Best Instagram Schedulers, and More
• Napoleon Hill’s Keys to Success

Book Recommendations

• Best New .NET Books To Read In 2019 [Updated: 13/03/2020]