Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
Software Development Life Cycle (SDLC)
Yogi Berra
Capability Maturity Model (CMM)
Level 2 - Repeatable
It is characteristic of processes at this level that some processes are repeatable, possibly with consistent results. Process disciplin
is unlikely to be rigorous, but where it exists it may help to ensure that existing processes are maintained during times of stress.
Level 3 - Defined
It is characteristic of processes at this level that there are sets of defined and documented standard processes established and
subject to some degree of improvement over time. These standard processes are in place (i.e., they are the AS-IS processes) and use
to establish consistency of process performance across the organization.
Level 4 - Managed
It is characteristic of processes at this level that, using process metrics, management can effectively control the AS-IS process
(e.g., for software development ). In particular, management can identify ways to adjust and adapt the process to particular projects
without measurable losses of quality or deviations from specifications. Process Capability is established from this level.
Level 5 - Optimizing
It is a characteristic of processes at this level that the focus is on continually improving process performance through both
incremental and innovative technological changes/improvements.
At maturity level 5, processes are concerned with addressing statistical common causes of process variation and changing the
process (for example, to shift the mean of the process performance) to improve process performance. This would be done at the same
time as maintaining the likelihood of achieving the established quantitative process-improvement objectives.
SDLC Model
A framework that describes the activities
performed at each stage of a software
development project.
Waterfall Model
• Requirements – defines
needed information, function,
behavior, performance and
interfaces.
• Design – data structures,
software architecture, interface
representations, algorithmic
details.
• Implementation – source
code, database, user
documentation, testing.
Waterfall Strengths
• Easy to understand, easy to use
• Provides structure to inexperienced staff
• Milestones are well understood
• Sets requirements stability
• Good for management control (plan, staff, track)
• Works well when quality is more important than
cost or schedule
Waterfall Deficiencies
• All requirements must be known upfront
• Deliverables created for each phase are
considered frozen – inhibits flexibility
• Can give a false impression of progress
• Does not reflect problem-solving nature of
software development – iterations of phases
• Integration is one big bang at the end
• Little opportunity for customer to preview the
system (until it may be too late)
When to use the Waterfall Model
• Requirements are very well known
• Product definition is stable
• Technology is understood
• New version of an existing product
• Porting an existing product to a new platform.
V-Shaped SDLC Model
• A variant of the Waterfall
that emphasizes the
verification and validation
of the product.
• Testing of the product is
planned in parallel with a
corresponding phase of
development
V-Shaped Steps
• Project and Requirements • Production, operation and
Planning – allocate resources maintenance – provide for
enhancement and corrections
• Product Requirements and • System and acceptance testing –
Specification Analysis – complete check the entire software system
specification of the software in its environment
system
• If code reviews are good, review code all the time (pair
programming)
• If testing is good, everybody will test all the time
• If simplicity is good, keep the system in the simplest design that
supports its current functionality. (simplest thing that works)
• If design is good, everybody will design daily (refactoring)
• If architecture is important, everybody will work at defining and
refining the architecture (metaphor)
• If integration testing is important, build and integrate test several
times a day (continuous integration)
• If short iterations are good, make iterations really, really short (hours
rather than weeks)
XP References
Online references to XP at
• http://www.extremeprogramming.org/
• http://c2.com/cgi/wiki?ExtremeProgrammingRoadmap
• http://www.xprogramming.com/
Feature Driven Design (FDD)
Five FDD process activities
1. Develop an overall model – Produce class and sequence diagrams from
chief architect meeting with domain experts and developers.
2. Build a features list – Identify all the features that support requirements.
The features are functionally decomposed into Business Activities steps
within Subject Areas.
Features are functions that can be developed in two weeks and expressed in client terms
with the template: <action> <result> <object>
i.e. Calculate the total of a sale
3. Plan by feature -- the development staff plans the development
sequence of features
4. Design by feature -- the team produces sequence diagrams for the
selected features
5. Build by feature – the team writes and tests the code
http://www.nebulon.com/articles/index.html
Dynamic Systems Development Method
(DSDM)