All about Software Development Life Cycle (SDLC)

I completed a course on Software Development Life Cycle (SDLC) basics recently and decided to write this article to document my notes that might be quite helpful for those that want a quick glance at SDLC concepts.

This article is slightly different from my regular style of writing since the reason I’m writing this in case I ever need to revise a few points.

This whole article is really more like revision notes at a quick glance, but those are the ones that help the most especially for last minute preparations, hence, you are permitted to make use of this as you see fit.

What is Software Development Life Cycle or SDLC ?

Software Development is a process that software organisations generally follow to design, develop and test softwares that meet required quality standards. It also helps estimate cost and time requirements for a software development and implementation while enabling it to either meet or even exceed client requirements and expectations.

ISO/IEC 12207 is the international standard for software life cycle processes. It defines all the processes for developing and maintaining software systems.

The course I took explained software development life cycle by traditional methods, early agile methods, modern approaches and other approaches. The sections below cover all the points explained according to these categories. Points that stood out to me have also been covered in the end along with summary.

All about Software Development Life Cycle (SDLC)

1. Traditional Methods :

• Waterfall model : Also called as manufacturing approach, it is a traditional software development approach includes requirements analysis and design, development testing, and finally deployment and maintenance phases.

Overview :

Generally contains well-defined checklists, processes, tools, clearly-defined phases, fixed scopes, comprehensive system documentation.

Cons :

• Late delivery of business value
• Frozen requirements (stakeholders need to change requirements)
• Precedence/over-emphasis on detailed checklists and control processes over people (not human-centric)

Impact :

• project failures
• comprehensive documentation
• detailed checklists

Application :

• simple systems
• enhancements in ongoing maintenance
• mission critical systems where gated phases and checks are required

• Spiral Model : Developed in 1986 by Barry Boehm, is a mix of waterfall and iterative approaches.

Overview :

Each waterfall in a spiral model consists of four phases :

• Planning : requirements identification and analysis, stakeholders identification and life cycle objectives of system, successful condition definition
• Risk analysis : risk identification, risk prioritisation and mitigation
• Engineering : software implementations, detailed design, coding, unit and acceptance testing, and deployment
• Evaluation : stakeholder review, feedback, next iteration planning

Each iteration is built on top of the output of the previous iteration (key note : each iteration is different from the other iterations as there is better understanding of requirements and mitigation of risks as you proceed)

Key Takeaways :

• Iterative nature of software development process
• Risk Driven

• Rational Unified Process :

History :

• Developed by Rational software
• greatly influenced by object-oriented analysis and design and UML (Unified Modelling Language)
• influenced by other contemporary methodologies
• IBM acquired Rational Software in 2003 and developed a subset of RUP in 2006 which was more agile-centric called OpenUP

Overview :

• RUP was an attempt to come up with a comprehensive iterative software development framework
• Large pool of knowledge
• consists of sample artefacts, processes, templates, detailed documentations, guidelines, phases and disciplines
• Customisable process that will work for building small, medium or large software systems
• Customisable with plugins.

Phases (each phase has several iterations) :

• Inception : achieves lifecycle objective milestone (all stakeholders agree to build objective)
• Elaboration : achieves lifecycle architecture milestone (baselines architecture of software system)
• Construction : achieves initial operational capabilities milestone (software product ready for client use)
• Transition : achieves production release milestone (fine-tuning application at production scale)

RUP Disciplines :

• Business Modelling
• Requirements
• Analysis and Design
• Implementation
• Test
• Deployment
• Configuration and Change management
• Project management
• Environment

Cons :

• heavy process with a lot of documentation
• prescriptive and templates were too large to be easily customisable

Key Principles :

• Iterative development
• Requirement and change management
• continuous quality verification
• visual modelling of software
• component-based architecture facilitates creation of smaller and more manageable components

Life Cycle Example :

• number of iterations and duration of each phase may vary from project to project
• Inception and Elaboration iterations are heavy on business modelling and requirements
• Construction iterations are heavy on analysis and design, implementation, testing and deployment

2. Early Agile Methods :

• DSDM (Dynamic systems Development Method) :

History :

• DSDM Consortium formed in 1994
• DSDM Handbook made public in 2014
• DSDM Consortium renamed to Agile Business Consortium in 2016

Overview :

• DSDM framework developed in 1994 built by group of organisations for project delivery and management.
• Rapid Application Development (RAD) was becoming the norm when DSDM was introduced
• RAD enabled quick builds but was unstructured.
• DSDM had a tight set of rules and was designed to be compatible with ISO 9000 and PRINCE2

Life Cycle (phases can be repeated and iteration between phases allowed) :

• Pre-Project : Analysis, feasibility,, business case for project
• Project life cycle : iterative development, time boxing, MoSCoW
• Post-project : determine if expected benefits of project have been realised

Principles :

• focus on business needs
• on-time delivery
• collaborations
• no compromise on quality
• incremental development from firm foundations
• iterative development
• clear and continuous communication
• control demonstration (highly-visible plan with careful and diligent management)

Key Takeaways :

• Time-boxing activities
• MoSCoW prioritisation
• iterative and incremental approach
• FDD (Feature-Driven Development) :

Overview :

• lightweight and agile process
• software is a collection of features
• software feature = working functionality + business value (action, result and object)
• working software delivery (working features)
• short iterative process (five activities)

Life cycle :

• Develop overall model : high level initial domain model built based on team’s problem understanding
• Build feature list : domain is divided into subject areas and each subject areas contains business activities and workflows where steps in each activity are identified as features
• Plan by feature : feature implementation plan is developed; includes feature assignments to developers
• Design by feature : more details added to classes in domain model, sequence diagrams developed
• Build by feature : classes that implement features are implemented, tested and deployed

Status Reporting :

• subjective
• steps have multiple milestones
• each milestone has a percentage completion (completion % = sum of completion % of all milestones up to that point)

Key Takeaways :

• Features teams (team organisations based on features and teams having end-to-end functionalities)
• Parallel Development (Good scalability)
• Completion status Tracking (completion percentage and milestones)

Crystal Methods :

History :

Crystal method evolved as a result of research done by Alistair Cockburn in 1990s

Overview :

• Family of methodologies
• each methodology apt for a project size/team size and criticality
• people-centric, lightweight and highly flexible

Selecting the model :

• y-axis represents criticality (severity of damage caused by system malfunction)
• x-axis represents team size

Crystal method examples :

• Crystal Clear : working software with minimal documentation (sponsor, senior designer and programmer roles sufficient)
• Crystal Orange : working software, requirements document, user interface design, user manual, test cases (sponsor, market analyst, architect, business analyst, project manager, etc., roles required)

Key Takeaways :

• People-centric
• Frequent delivery of working software
• There is no ‘one-size-fits-all’ for all projects
• Modern principles : automated tests, frequent integration
• Clear communication

3. Modern Approaches :

• Scrum :

History :

Introduced by Ken Schwaber and Jeff Sutherland in 1995

Overview :

• lightweight, agile framework (small set of rules and guidelines)
• simple and features iterative and incremental approach (short sprints)
• easy to understand, difficult to master (scrum guides available)

Development process :

• development team members, product owners and scrum master collaborate to work with short iterations of 30 days or less
• Product backlog : start with to-do list of items
• Sprint backlog : subset of work items and working plan
• Daily scrum meetings : daily sync ups for development team and continue to implement work items (team sync-up, review progress towards sprint goal), optional ‘3 question format’ (what did I do since the last daily scrum? what do I plan to do today? are there any impediments to accomplishment goals?)
• Product increment : produced in form of working software at end of sprint
• Sprint review : attended by scrum team and external stake holders, product increment review, informal event i.e., no formal acceptance, time bound (4 hours for 30 days, adjusted for shorter sprints)
• Sprint Retrospective : review other aspects (process, communication, skills, etc), prioritise/commit to improvement related action items, time bound (3 hours for 30 day sprints, adjusted for shorter sprints)

Roles :

1. Product Owner :

• owns product backlog and accountable for contents
• final authority for order and priority of items
• individual, not a committee

2. Development Team :

• developers, testers, documentation experts, database administrators (DBAs), system administrators, and others
• cross-functional (team has all the skills necessary to build, test and deploy fully-functional software features)
• self-organising (need minimum interference or help from external sources)

3. Scrum Master :

• agile coach (guide or mentor for scrum team), help team optimise performance, facilitates scrum events if necessary
• servant masters (lead team by overcoming hurdles that prevent team performance)
• remove barriers
• coach and convince team to work optimally, do not manage teams

Artefacts/deliverables :

• Product backlog : master list of what needs to be built
• Sprint backlog : subset of product backlog, items selected to be implemented in current sprint with task list for selected items
• Product increment : slice of functionality produced in current sprint along with functionalities produced by all previous sprints

Key Takeaways :

• business value-driven comprehensive and simple framework
• potentially shippable product increment each sprint

Workflow :

• Lean :

History :

• modelled after Toyota production system’s manufacturing pipeline (aimed at reduced wastes and manufacturing at optimal efficiency)
• Mary and Tom Poppendieck were inspired by this to write the book Lean Software Principles in 2003

Overview :

• collection of principles centred on key tenet to minimise waste
• visualize production pipelines
• highlight bottlenecks, inefficiencies

Key Concepts :

• value stream is a very well used technique, workflow or sequence of steps to produce a product or service with business value
• value stream mapping 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 and is critical

Value Stream Mapping :

• Lead Time is the total time taken from customer request to product/service delivery
• Cycle time is actual time spent working on given item (subset of lead time)
• Lead time >= cycle time (goal is to make lead time = cycle time)

Principles :

• elimination of wastes :
• waste is any work that does not add value (waste = non-value work)
• no gold plating (nothin more, nothing less, no extra features necessary)
• avoid unnecessary processes and context switching (task switching)
• amplify learning (constant learning by regular feedback from stake holders)
• decide as late as possible (early decisions are a possible risk)
• deliver as fast as possible (smaller iterations are easier to manage)
• team empowerment (fosters creativity for designers)
• build in integrity (value deliverance, conceptual integrity)
• see the whole picture
• Kanban :

Overview :

• process to organise work inspired by lean principles
• core values encourage visualising work and limiting work in progress
• powerful approach based on advanced queuing theory

Little’s Law (defined in 1950s) :

• Number of items in a work queue = Average time spent working on each item * Arrival rate of work items
• Average time spent on each work item = number of items in work queue / arrival rate of work items

Kanban Board :

• powerful and effective communication tool about team progress and bottlenecks
• value stream can be visualised via a Kanban board

Kanban Board Features :

• Pull system
• no artificial time boundaries
• continuous value delivery
• daily stands

• Extreme Programming (XP) :

Overview :

• Collection of software engineering practices developed by Kent Beck (1991)
• Customer-driven iterative approach — collaborative approach where customer provides requirements and developers break requirement tasks and assign tasks to themselves.
• Focused on short weekly iterations, collaborations and quarterly macro-level planning (to container weekly iterations)

XP Signature Processes :

• Just-in-time design : start at a simple high-level design and continue to evolve, also refactor code continuously to improve code quality and address technical debt. XP teams run short builds of 10 mins or less.
• Pair Programming :
• collaboration
• continuous code inspection
• code quality improvement via continuous inspection of code

Test Driven Development :

• Step 1 : write a test for a function that is yet to be written, code will not compile
• Step 2 : write function to fail test; just enough code for the code to compile, test must fail. If the test passes, test is inadequate to verify any functionality and should be refactored.
• Step 3 : Write code to pass test; complete coding of the function to meet requirements of test, refactor code to pass the test.

Key Takeaways :

• criticised for being over-simplistic
• ineffective for building large systems or for inexperienced developer teams
• pair programming and test driven development are known to work for small and large systems alike
• Spotify :

History :

• Scrum company around 2008
• ran into scaling issues with scrum, found many scrum practices to be counter productive
• defined their own approach (agility over scrum) instead of choosing a more formal scrum method

Spotify Agile Model (case study) :

• culture, not methodology (does not follow single framework or methodology, define their approach as a culture of principles and values)
• Spotify engineering culture = Finding your own way

Release Approaches :

• Squads (autonomous and small teams) work in parallel
• small frequent releases with maximised automation (release trains and feature toggles)
• release train : chain of frequent releases, each release includes set of features
• feature toggle : unfinished features part of release trains but hidden from users, reduces need for code branching and merging, difficult for manage and causes technical debt.

Continuous Improvement — Kata Board :

• made popular by Toyota
• Statement of problem — defines a problem to be soled by team
• Ideal Direction — perfect world as defined by team, world may be unrealistic but is a direction not destination.
• realistic target — one step ahead of where they are, or one step closer to ideal direction
• next three actions to move to realistic target

Spotify Culture :

• Innovation — hackathons that bring people with similar interests together and transform their ideas into working features
• Teams learn from each other

Engineering culture :

Spotify Team Structure :

• autonomous and self-governing — teams work independently
• core values from lean — avoid waste, provide business value, deliver quickly and often

1. Squad :

• smallest team in model
• usually comprises of 1–7 people
• similar to scrum team (cross-functional, up to 7 people, self-organising)
• squad team members are colocated and work in a highly collaborative environment

2. Tribes :

• collection of squads that work on a related area of work
• manage one area such as surge or managing playlists

3. Chapters :

• groups with team members with specific area of expertise (UX, DBAs, etc)
• chapter leads similar to line managers
• allows person with specific expertise to switch between squads without a change in line manager

4. Guilds :

• loosely-defined groups with similar interests
• crosses squads and tribes, brings people with any work related interests or even a common hobby together
• email lists, events to interact and benefit from each other
• organises people to benefit from each other and work together towards shared product vision, not create organisational hierarchy
• teams get help from many agile coaches (servant leaders) who work on making the team more productive and help teams remove obstacles from their work

Failure-friendly culture :

• teams experiment freely
• encouraged to experiment and learn from mistakes
• changes have limited impact and are reversible

Other key differentiators :

• code repositories — other teams can view code and make changes if necessary
• minimise handoffs — teams help each other but have minimal handoffs, self-service culture
• minimised bureaucracy — guilds not desirable, but still preferred over bureaucracy

Key Takeaways :

• ‘no fluff’ approach — simple yet effective
• may not work for other organisations
• may need customisations

• DevOps :

Overview :

• close cooperation between developers ad operations staff
• both dev and ops teams responsible for entire software delivery pipeline
• continuous integration, deployment and delivery help make the process successful
• successful DevOps implementation relies on automation and tools
• based on Lean principles to build fast delivery pipeline with minimal wastage
• DevOps is not a replacement for agile, instead complements traditional agile approach by enabling end to end agility and faster and stable deployments
• Agile approach that merges development and operations
• DevOps is not an industry buzzword
• DevOps is a cultural shift to producing a stable delivery pipeline and promotes healthy operational practices, not a tool or technology
• DevOps is not a way to override checks and balances

Background :

• DevOps = software development (Dev) + IT operations (Ops).
• aims to shorten SDLC and high-quality software with continuous delivery
• goals : fast and efficient software delivery pipeline where release features to clients must be as fast as possible; culture of close cooperation between dev and ops needed for efficient software delivery pipeline

Roles impacting Deployment :

1. Business Stakeholders :

• domain, market and competitor knowledge
• come up with ideas and features
• focus is competitiveness of the enterprise

2. Developers :

• implement features thought of by stakeholders
• try their best to push stable product changes

3. QA :

• quality assurance
• test changes and report any issues if found
• push stable product changes

4. IT Operations :

• deploy changes to productions or production like environment
• focus is service level agreements and stability of environments

Common Deployment Challenges :

• Difference in configurations
• Dependencies
• Data
• Other aspects of servers, storage and network settings
• traditional deployment is manual in nature, manual methods prone to errors

Deployment Problem :

• Agile implementations unify and align business, development and QA into a cross-functional team
• agile teams produce integrated product implementations more frequently
• TDD and refactoring to produce stable releases

Need for DevOps :

• frequent deployment caused problems
• DevOps provides closer cooperation between dev and ops

Concepts :

1. DevOps Mindset Shift :

• collective responsibility of delivery pipeline by all involved in the process
• learning and implementing integration practices and patterns

2. DevOps Transition :

• Dev and Ops cooperation culture
• automation tools
• faster delivery pipeline

Key Practices :

1. Continuous Integration :

• CI is the practice where developers frequently commit changes to a centralised repository to trigger an automated build
• the build process validates code for compilation errors, code quality metrics, automated tests, static code analysis, missing dependencies, etc
• developers get quick and early feedback on issues and fix issues on a priority basis

2. Continuous Delivery :

• ensuring stable product after every release

3. Continuous Deployment :

• automating updates to production

4. Other Approaches :

• CMMI (Capability Maturity Model Integration) :

Overview :

• Process improvement model applicable to a wide range of industries
• developed by a collaboration of industry experts at Software Engineering Institute, Carnegie Mellon University
• CMMI V2.0 released in early 2018
• CMMI is a model, not a standard (general guidance, not prescriptive)
• organisations undergo appraisals to be awarded CMMI Maturity levels 1–5

CMMI Maturity Levels :

1. Level 1 :

• Initial
• unpredictable and reactive
• no process documentation
• work is completed but often delayed and over budget

2. Level 2 :

• Managed
• managed on project level
• processes documented at project level
• projects are planned, performed, measured and controlled

3. Level 3 :

• Defined at organisational level
• proactive, not reactive
• Organization-wide standards provide guidance across projects, programs and portfolios

4. Level 4 :

• Quantitatively Managed
• measured and controlled
• organisation is data driven with quantitative performance improvement objectives that are predictable and align to meet needs of internal and external stakeholders

5. Level 5 :

• Optimising
• stable and flexible
• organisations focused on continuous improvement and is built to pivot and respond to opportunity and change
• organisations stability provides a platform for agility and innovation

CMMI application in software development and Agile approach :

• CMMI V2.0 contains guidance on scaling — how agile methods can be used to optimise processes; many agile methods are simple and effective with scaling properties
• process model that provides organisation-wide scaling guidance is very useful at an organisational level
• CMMI V2.0 has iterative and incremental practices to obtain optimal performance
• Six Sigma :

Overview :

• originated in manufacturing and uses a scientifically and statistical approach to measure quality of processes by tracking number of defects
• developed at Motorola in the 1980s and popularised by Jack Welch, Honeywell and General Electric in the 1990s
• goal is to reduce defects and variation and keep output of a process within certain limits of a baseline
• Focused on minimising waste, maximising value and improving quality
• Six Sigma in combination with Lean can improve customer satisfaction and improve the quality of products and services produced
• Each Sigma is a standard deviation

• the goal is to move all outputs into middle where variation in quality is lowest. height of curve in middle is measured between 1 and 6 sigmas. Higher sigma level is better, lesser number of defects

Six Sigma and software :

• Manufacturing is pure science — same product type can be produced repeatedly and quantifying defects is very manageable
• Software development is both science and art and the procedure of measuring quality could be challenging
• Six Sigma generally works at a macro-level for process improvement
• Six Sigma includes DMAIC (process improvement) cycle may be useful for all software and non-software

DMAIC Cycle :

• Define : define problem or opportunity for improvement
• Measure : performance measurement
• Analyse : root casus analysis/fish bone diagram for variations or defects
• Improve : reduce or eliminate variations and defects
• Control : monitor and stay at optimum level (always scope for improvement)

Applying Six Sigma to Software :

• DMAIC cycle and techniques can be implemented
• review software delivery process for improvements
• find opportunities for automation and faster delivery cycles
• quantifying six sigma to a software delivery cycle can be done using comparison technique
• DMAIC cycle techniques can be applied to improve the quality of software products
• lean and six sigma in combination aid in building highly optimised processes for product delivery

Points that stood out :

• Iterative development, visual modelling and component-based architecture are listed among RUP best practices
• Elaboration phase of RUP ends with achievement of Lifecycle Architecture Milestone where the architecture of the system is baseline
• Spiral model is a hybrid approach that uses both waterfall and iterative approaches. It includes a series of waterfalls where each waterfall is built on top fo the previous one iteratively
• Although waterfall may not be the best approach for most development initiatives, it may be good for small and simple system developments where the team knows the system and requirements well.
• The biggest risk with waterfall model is that the customer does not get to see the product until very late in the lifecycle. This is because waterfall model builds software in a phased manner and actual functional product is seen very late by client, hindering any valuable customer feedback is delayed. If product does not meet business requirements or usability according to client, their feedback is quite delayed by which point a lot of time and money has already been spent on software development
• Crystal methods approach brought forward the point that the software development approach selected is dependent on the size of efforts and risks involved
• A feature is defined as a working functionality with business value according to FDD (Feature-Driven Development)
• Timeboxing is a time management technique mentioned in DSDM where an activity is allocated a maximum time period.
• Continuous integration keeps the code in a centralised repository in a stable state
• DevOps attempts to accomplish extension of agility to entire product delivery pipeline
• Bureaucracy is discouraged at Spotify
• Spotify model gives teams freedom to choose combinations of Agile frameworks, practices and methodologies
• Spotify model encourages autonomy and innovation with a failure-friendly environment
• Spotify model is based on Agile practices, it is not a formal scaled Scrum framework
• Key Extreme Programming practices involve pair programming, test driven development and continuous integration
• Branching and merging is not an Extreme Programming practice as it is not a generally favourable practice in Agile approaches. Branching has the potential to cause technical debt if changes are not merged frequently. It is not listed as a core XP practice even though risks can be somewhat mitigated by frequent merging
• Kanban board an be used to visually represent a blocked item
• According to Little’s Law, if you want to work at a higher efficiency, number of WIP items in work queue can be decreased or limited to spend less time per work itemA good example of the lean principle ‘decide as late as possible’ is to delay decisions until you know the facts that will help you make a knowledgeable decision. Although there is no clear definition of ‘the last responsible moment’, it is the time where a decision should be made when you have adequate facts. The key concept being not to make decisions based on a preset timeline
• Value stream mapping owes its origin to manufacturing industry and can be applied to software development projects. Value Stream mapping can have variations and can be used for several types of projects and processes
• Value stream mapping is used to identify bottlenecks and areas of improvement in a process. It is a tool for process improvement and can be used to understand complex processes, even though the original purpose is process improvement
• Stakeholders outside the Scrum team participate in the Sprint Review where Scrum team and external stakeholders come together to inspect product increment
• The Scrum Master role is not the same as the Project Manager role. The Scrum Master plays the role of an Agile Coach and facilitates obstacle removal in development team’s path. They do not have administrative responsibilities over what the team does even though they do have management responsibilities.
• The purpose of control step in the DMAIC cycle is for continuous monitoring of processes with a goal to optimise output. Techniques such as control charts are used to measure outputs and keep outputs within allowed variation limits
• Higher variation from a desired baseline means a lower sign. Higher Sigma means less variation from desired baseline and fewer defects with better quality
• CMMI provides guidance on achieving process maturity at organization

Note :

The notes taken here only cover basics and an overall view of the Software Development Lifecycle and do dive deeper into topics of your interests if you find any of these particularly intriguing.

And that is the end of it, usually I end my articles with a ‘happy coding’, but this time it shall be happy learning! 🙂

Note: This article is not sponsored and is purely based on the author’s opinions and personal experience on the journey of learning. None of the links provided here are affiliate links and are provided only for the purpose of learning.

The author is a student completing an Engineering Degree in Computer Science with Specialization in Cloud Technology and Mobile Applications.

All technical diagrams made using Adobe XD

Check out this article on my Personal Blog : All About SDLC

All about Software Development Life Cycle (SDLC)