OverviewThe 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. Show
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?
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 PhasesThese are the standard stages of the SDLC:
Most popular SDLC ModelsTraditional
Modern Approaches
Summary
Agile vs. Waterfall: A simplified version of a typical iteration cycle in agile project management: SDLC TutorialTable of Contents
1. SDLC Overview1.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:
1.2 SDLC PhasesThese are the standard stages of the SDLC:
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):
Low-Level Design(LLD):
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 ModelsThere 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:
Additional SDLC methodolgies: RAD, Prototyping, RUP, etc. 2. Waterfall ModelIn 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 ModelThe 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 ConsAdvantages of the Waterfall SDLC Model:
Disadvantages of the Waterfall SDLC Model:
Use cases for the Waterfall SDLC model:
3. Iterative ModelAn 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:
3.1 Iterative Model ─ ApplicationIterative 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 ConsAdvantages of the Iterative SDLC Model:
Disadvantages of the Iterative SDLC Model:
Use cases for the Iteration model:
4. Spiral ModelThe 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 ─ ApplicationThe 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:
4.2 Spiral Model ─ Pros and ConsAdvantages of the Spiral SDLC Model:
Disadvantages of the Spiral SDLC Model:
Use cases for the Spiral model:
5. V-Shaped ModelThe 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 PhasesThere 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 PhasesThe 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 ─ ApplicationV-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.
5.5 V-Model ─ Pros and ConsAdvantages of the V-Model:
Disadvantages of the V-Model:
Use cases for the V-shaped model:
6. Big Bang ModelA 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 ─ ApplicationThe 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 ConsAdvantages of the Big Bang SDLC Model:
Disadvantages of the Big Bang Model SDLC Model:
7. Agile ModelThe 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:
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 DevelopmentAgile Software Development Values
Agile Software Development Principles:
7.3 Agile Vs Traditional SDLC ModelsAgile 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 ConsAdvantages of the Agile SDLC Model:
Disadvantages of the Agile SDLC Model:
Use cases for the Agile model:
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:
DSDM Life Cycle:
DSDM Principles
Key Takeaways
Resources
8. Additional Traditional SDLC methodologies8.1 RADRapid 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:
RAD should be chosen when a system can be modularized and domain experts are available with relevant business knowledge. 8.2 PrototypingThe 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:
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 ProcessRational 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:
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 ApproachesMany 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 ScrumScrum 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:
Scrum Overview:
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":
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
Resources
9.2 LeanLean 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
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
9.3 KanbanKanban 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
9.4 ExtremeDeveloped 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
9.5 DevOpsBuilding 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:
Need for DevOps:
The Two CDs
What DevOps Is
What DevOps Is Not
9.6 Six SigmaLean 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 ThoughtsTo 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 ReadingSDLC
AgileAgile Alliance & Agile Business Consortium
Agile Articles
Scrum
Spotify SDLC Case Study
ISO/IEC 12207
Wikipedia
Free Database eBooks
Learning Resources
Featured Articles
Book Recommendations
|