Introduction

The SDLC is a process for the development, testing and deployment of a software system.

Most large IS/IT organizations have their own SDLC, or use a variant of a well-known one like RUP or DSDM.

The architect needs ongoing oversight of the SDLC; should monitor adherence to plan, interaction between components, specification changes, systems build; should maintain, review and refine architecture documentation accordingly.

The life cycle of a project is a process, or a collection of related processes.

Underlying any formal description of an SDLC are assumptions that:

The SDLC is divided phases (or stages)
A phase (say construction) is composed of activities
A discipline (say analysis) is a set of related activities that can be sequenced in a workflow (or activity diagram) that crosses phases
An activity consumes and produces artifacts
A role is responsible for producing artifacts and completing activities.

Our various guides to planning and management, also sponsors, stakeholders and inputs, amplify on several of the points made above.

One size doesn’t fit all

Process improvement approaches like Six Sigma, Lean and CMMI are all about repeated processes.

A process becomes repeatable when instances:

start from the same input.
produce the same output.
are short and repeats often enough for people to learn it and practice their role.
are embedded in a stable organisation structure.
are measurable in ways that people find meaningful and useful.

Trouble is, across the industry, the software development process fails the criteria above.

The search for a repeatable software development process is frustrated by the findings that:

Software development differs from hardware development
Software development differs from mass manufacturing
Projects with fixed requirement differ from those with changeable requirements.
Small-scale (< 10 people) projects differ from large-scale (> 100 people) projects.
Public sector projects differ from private sector projects.
Projects completed within an enterprise differ from those that involve partners and commercial customer-supplier relationships.

And within the world of software development:

Maintenance differs from enhancement differs from development.
Building a software product for sale differs from building a bespoke application for one enterprise.
The already large variety of software products/applications is increasing all the time: application development differs from application integration differs from data warehousing differs from web site development differs from performance critical batch processing differs from embedded process control systems.

A process that is repeatable in all those circumstances has to be a generalised abstraction.

Most people find it too vacuous in practice.

Off-shore software development can be a relatively repeatable process.

Especially if it is limited to short-cycle work for which there is a detailed specification, and ideally pre-defined test cases.

Even there, the process can vary due to reasons above, different organisation structures and contractual or commercial agreements.

Mature enterprises have concluded that one size doesn't fit all, there is no single formula for success.

Using one prescriptive process for all projects can bring more costs than benefits.

Most define variations of their sequential process for different kinds of work, and define process tailoring guidelines.

This is the assumption underlying process improvement schemes like CMMI.

The following sections describe a range of process variations from waterfall at one end to agile at the other.

Waterfall methods (aka sequential methods)

Waterfall methods are based on the classic sequence of activities in a mechanical or hardware engineering project.

The “waterfall” appears in a Gantt chart representation.

Sequential development
Analyze	Analyze
Design		Design
Build			Build
Test				Test
Roll out					Roll out

The assumption is that the activities, roles and artifacts of a project are predetermined in the initial project plans.

The process determines the project life cycle.

The trouble is, you don’t learn what’s wrong with the requirements or the product until it is released.

Software engineering isn’t like hardware engineering.

Software products are more difficult to envisage up front.

Software remains malleable even after delivery.

Moreover, you don’t learn what’s wrong with your process until the end.

Few if any SDLC processes are strictly sequential.

Modern methods like RUP and the MSF process are better described as waterfall iterative.

Even where a sequential process is imposed on a project, managers and architects will strive to proceed as iteratively as constraints allow.

Iterative (delivery early) methods

An iterative method divides a large project into a series of smaller, often overlapping, projects that yield successively more complete versions of the desired product.

Iterative development
Initiation	High-level architecture	Ongoing development and refinement of the architecture
Product v1	A, D,	B, T, R
Product v2		A, D,	B, T, R
Product v3			A, D,	B, T, R
Product v4				A, D,	B, T, R

Iteration enables part of the desired solution to be delivered earlier, and lessons to be learned from this.

Some allow that an iteration may last 6 months.

In agile approaches, an iteration lasts no more than 90 days.

In the agile method “Scrum”, an iteration is a 30 day sprint.

Iterative development can make projects small enough for the classic waterfall method to be applied in a sequential fashion from start to end of each iteration.

Iterative development can be subdivided into two kinds:

Waterfall Iterative methods: The principle is to deliver early, but the final target is relatively fixed. You must strive to deliver a tested working solution early. Sometimes, in practice, the earliest iterations can deliver only prototypes.
Evolutionary Iterative methods: The principle is not only to “deliver early” but also to “commit late”. Every iteration must deliver a tested solution – however limited. But the end target is allowed (even expected) to change radically. So the development team commit only to the next iteration. Plans after the next iteration are regarded as extremely flexible.

Agile (formerly RAD) methods

Introducing iterative development reduces the difficulties of large projects.

But it does not make a project agile - as agilists mean it.

Agile methods are not just iterative.

First, the attitude to requirements is different. Agilists observe that:

Software requirements are usually unclear or uncertain until users get hold of the product.
Software products are extremely varied.
People in a team have to communicate and collaborative very closely.
The process cannot be well-defined before the project.

Second, the attitude to process is different. Agilists believe it is best that:

Through iteration, the project largely determines its own process.
The best-fit process, roles and artifacts emerge from iterative and collaborative development.
A range of tough principles and disciplines must be employed to ensure this happens.

What does agile mean? Among other things:

Delivery early, commit late.
Acceptance of flexible, prioritised and ever changing requirements.
Minimal documentation of specifications and models.
Test-driven rather than model-driven. Waterfall methods suggest model > code > test. Agile methods suggest test > code > model.

Q) Do agile methods apply only to small projects?

A) No. Perversely: Sequential/waterfall processes work better on smaller projects, and agile principles are valuable on, even necessary for, larger projects.

The philosophy is that an agile method must and will provide better value, because it is inherently a more cost-efficient process than a sequential/waterfall method.

The stated aim is that when the time or money runs out, the system will do what the users need most, what is possible and useful, rather than what might have been written down at the beginning.

For much more discussion of agile development: Top ten agile development principles

What most SDLC processes have in common

Most SDLC processes (and there are many to choose from) call somewhere between waterfall and agile extremes.

This section discusses what most SDLC processes have in common before discussing special features of agile methods.

The common features below are roles, principles, phases and milestones, iterative development and prototyping.

Roles

A SDLC usually comes with default role definitions.

E.g. The MSF process includes

product management,
program management,
development, testing,
release management,
user experience;

also

project sponsor,
business sponsor,
end user,
operations.

Most SDLC processes encourage close user involvement

Principles

SDLC processes share many of their principles.

The more agile the method, the more prescriptive it is about the principles and techniques (rather than sequence of activities).

This table draws some correspondences between principles in different SDLC processes.

RUP - four imperatives	The MSF process - four main principles	DSDM - nine principles
focus on architecture
develop iteratively	iterative	iterative/incremental development
	milestone-driven	frequent delivery of products
	phase-based
continuously ensure quality		base-lining of requirements at a high level
		testing thru the lifecycle
		focus on fitness for business purpose
manage change & assets.		reversibility of changes
	allow for feedback and creativity.	empowered teams
		active user involvement
		a collaborative and co-operative approach between all stakeholders.

Phases and milestones

A SDLC is usually divided into four or five phases.

This applies across the board from relatively sequential/waterfall methods to an agile method like DSDM.

IBM/Rational - RUP	Microsoft - MSF Process	DSDM
Inception	Envisioning	Feasibility/Business Study
Elaboration	Planning	Functional prototype
Construction	Developing - Stabilising	Design prototype
Transition	Deploying	Implementation

Each phase ends at a stop/go milestone.

Imposing stop/go reviews at pre-defined milestones helps managers spot and stop a runaway train.

Note that agilists argue that reviewing abstract specifications is never adequate; it simply doesn’t reveal enough, so there must be some directly testable product.

Within each RUP phase, one plans a limited number of iterations, each yielding a tested system generation.

Activities within phases

The table below our version of the SDLC, with activities grouped under four phases as in RUP.

SDLC phase	Usual activities and products
Inception	Outline solution (architecture version 1)
	Requirements catalogue
	Business architecture version 2
	IS development architecture version 2
	IT operations architecture version 2
Elaboration	Development guidelines (patterns and standards)
	Functional specification (use cases, UI design, business services, domain/data model)
	Data migration (if needed)
	Test strategy
	Transition plans: including migration paths
Construction	Detailed design: software & data
	Build: test documentation, Unit & link tested code
	System test: test documentation, System tested code
Transition	Acceptance testing, Acceptance tested code
	Transition into operations, Procedures & training
	Transition into maintenance, Maintenance procedures
Cross-phase	Requirements management and traceability records

The more waterfall the method, the more prescriptive it is about the activities within a phase and the sequence of those activities.

Nevertheless, the SDLC is a very complex and flexible process.

This complexity means that the SDLC is not readily captured in a flow chart.

Iterative development

Even where a sequential/waterfall process is imposed on a project, managers and architects will strive to proceed as iteratively as constraints allow.

For some, an iteration may deliver only a prototype, and may last 6 months.

Agilists are more rigorous and disciplined about iterative development.

An iteration must deliver a tested solution – however limited.

An iteration may last from 30 to 90 days.

In the agile method “Scrum”, an iteration is a 30 day sprint.

Prototyping

Prototyping is used in all kinds of approach.

In the agile method DSDM, it is promoted as one of the four main techniques (requirements prioritization, time-boxing, facilitated workshops, and prototyping).

A prototype is a working model of the thing to be built, not full-scale, not fully-featured.

Even a Power Point presentation can be turned into a working UI prototype.

People build various kinds of prototypes at various times in the SDLC.

Throw-away or evolutionary prototype?

A throw-away prototype demonstrates or tests some feature(s). It does not necessarily use the final technology. It might assist production of other products, such as the HCI Style Guide. It is often used to capture requirements or gain approval. Discarding a prototype reduces the risks of consolidating poor design.
An evolutionary or design prototype evolves into the final production system. It can shorten the time required to develop a system, but it can lead to poor design and unmaintainable code, and is usually unsuitable for large projects.

Horizontal or vertical prototype?

Horizontal - demonstrates the breadth of the functionality to be offered by the developing system. Usually a look-and-feel prototype that shows how the user interface can support business processes.
Vertical - develops a single system function from user interface to data sources, involving all technologies in between - can be the first step in incremental development.

Functional or non-functional prototype?

A functional prototype is developed to identify, capture and refine user requirements. It encourages user involvement early in the development lifecycle. Gaining user feedback early reduces the cost of correcting errors.
Non-functional prototype can be divided into three kinds:

· A technology solution prototype tests the feasibility of the specified technology solution. It proves that the chosen technologies can talk to each other and work together without significant problems. It may test the integrity of data passed between each component of the architecture. It may also be a performance prototype.

· A performance prototype demonstrates whether the performance targets can be met. It should include code to exercise known bottlenecks. It may stress a specific bottleneck. It may trial a specific performance tuning method. It may test the solution scalability and performance under a realistic load.

· A development prototype tests class libraries and design standards, it tests the invocation of infrastructure components and evaluates the performance thereof.

Spike development: Systems integration projects increasingly depend on components that are distributed over a wide-area network and/or over the internet.

The more distributed the components the harder it is to predict the performance of the overall system.

The higher the risks, the more effort you should spend on “spike development” to reach the stage where you can run a realistic test in a realistic test environment.

Lessons:

Projects can get stuck in paralysis by prototyping.

· Some prototypes cannot be scaled up to work in the real enterprise.

· That’s why agilists propose an iteration should deliver a solution the customer can use right away.

Manage customer expectations.

· A prototype built to prove one thing does not prove another.

· Most prototypes are best thrown away.

Further effort is needed to harvest the results.

· Lessons learned must be fed back to the developers.

· Some code elements may be re-usable within the main development.

· There needs to be training, standards, and a design authority to implement them.

The architect’s role in the SDLC

The table below shows the main elements of a typical SDLC, which elements you focus on and which you keep an eye on.

SDLC phase	Process step, with products	Focus	Interest
Inception	Outline solution (architecture version 1)	Focus
	Requirements catalogue		Interest
	Business architecture version 2	Focus
	IS development architecture version 2	Focus
	IT operations architecture version 2	Focus
Elaboration	Development guidelines (patterns and standards)	Focus
	Functional specification (use cases, UI design, business services, domain/data model)		Interest
	Data migration (if needed)		Interest
	Test strategy		Interest
	Transition plans: including migration paths	Focus
Construction	Detailed design: software & data		Interest
	Build: test documentation, Unit & link tested code		Interest
	System test: test documentation, System tested code		Interest
Transition	Acceptance testing, Acceptance tested code.		Interest
	Transition into operations, Procedures & training.	Focus
	Transition into maintenance, Maintenance procedures		Interest
Cross-phase	Requirements management and traceability records		Interest

Your goal in supporting a solution development process is to implement a new and working solution at a time, cost and quality that is acceptable to the business.

At the same time, you are concerned to implement overarching enterprise principles and standards.

You may have other goals within the solution development process.

Make sure your manager defines your role in oversight of a programme or project.

Are you responsible for delegating work to others? When should you take an interest in and/or contribute to something that someone else is responsible for? You may be asked to:

Monitor adherence to plans, and contracts, in support of the project manager
Ensure interfaces between major components are specified, agreed and under change control. Especially interfaces with components built by 3rd party suppliers
Control specification changes, in support of the lead analyst and project manager
Investigate technical issues as they arise.

People matter too

In a survey, we asked project team members to apportion the blame for project difficulties between process, people and technology.

They apportioned blame in that order – suggesting process is the biggest challenge.

But many managers will tell you people are the most important factor.

This section includes some noteworthy advice from one such manager.

“I have supported aggressive, dog -eat-dog clients for the last 7 years now and I have accumulated many battle scars and lessons learned to help out anyone who finds themselves in similar situations.

As project manager, assuming that you have a software background, that the project has been approved , funded and the initial charter elements have been defined , ...

“Follow the ten commandments below

1. Understand and believe in the proposed solution and value proposition.

If you don't, work harder until you are comfortable with the right solution, deliverables and milestones.
Stand your ground.
If you don't believe in the direction of the project, and you aren't successful in changing it, do your best to get out :).
If that's not a realistic option, emphasize the need for weekly face to face communications, additional controls such as reviews and sign offs, if not already part of the culture, and make sure you have every opportunity to communicate the risks in a professional way --- but make sure you have done your homework, have credible sources backing you, and that you clearly communicate mitigation strategies.
Never walk the plank alone :) This is more of an art form rather than a science.
The key to swimming against the political tide is to always be sensitive to the fact that you are running the risk of bruising egos..
You could, in all honestly, commit career suicide if you don't handle this correctly.
Never get emotionally attached to any solution idea that you may have.
Simply, but kindly and softly, report the facts and offer your professional opinion, backed with credible evidence, in a very respectful way.

2. Identify who all of the stakeholders are, what their individual definition of success is, and then figure out who outranks who.

Just satisfying the business owner and sponsor are not enough.
The Org Chart, although an excellent indicator, doesn't always tell the whole power and influence story.
Stay on the look out for management anti-patterns on both the IT and business side.
Some of the worst political battles ( and consequently risks to my software delivery ability) have been with colleagues within my organization (due to upward mobility issues, technical differences, resource contention, etc.)

3. Once you have an idea of who the political fat cats are, figure out what desired outcomes are important to each - to arrive at your best guesstimate on what the definition of success is. This is key.

All success dimensions are not written on the wall.
Success factors - depending on the climate, and individual agendas of various up and comers, duck and divers, and connivers - are not the typical indicators of budget, scope, schedule, quality , etc.

4. Inspect your context.

What's the maturity level of the environment?
Is there an effective PMO? effective Enterprise Architecture group? standards? principles? SDLC?
What's escalation path if conflict arises? Is there a steering committee structure in place to escalate to?
How is testing performed? UAT?
The answers to these questions help you devise your arsenal and appropriate game plan.

5. No matter what the organizational context and culture are, subscribe to a proven project management methodology - like PMI.

6. Communicate, communicate, communicate.

Err on the side of over-communication.
If you don't have to wear multiple hats like tech lead and/or business anlyst, as project manager, this should be at least 75% of your job.

7. Establish a very strong and trusting relationship with your business sponsor and leads.

Cut them some slack on the changing requirements front, and they may repay you with some tolerance on a missed milestone or two :)

8. If you're lucky enough to pick your own team and you are skilled at ensuring the identification of top talent, take all measures to ensure that the highest levels of quality are built into your screening and hiring processes.

Make sure you understand the roles that you need filled.
If you don't have the expertise, beg, borrow and steal it from your colleagues.
NEVER cut any corners here.
Get help if you need it.
Make sure you screen and test - comprehensively.
This is the most important thing that you can do.
If you are in a position where you inherit "talent" that is not ideal for the tasks at hand, figure out the best role for them that doesn't jeopardize the critical path and\or influence your chain of command that you need additional skilled resources to get the job done.

9. Manage team performance, especially dynamics like a hawk.

Never let one personality dominate.
Never allow issues to fester.
If someone calls in sick every Friday during the summer, address the issue immediately and deal with it - - ensuring that the right message is sent to the rest of the team.
Do not tolerate dysfunction in any form.
Terminate toxic carcinogens like finger pointing, belittling, befuddling, disrespect for others, lack of motivation, etc.
Never, at any cost, no matter how talented the individual, allow them to challenge your authority, or maintain any 'leverage' over you in any way.
Don't allow someone to paint you in a corner or hand cuff you.
Make sure that adequate cross training is in place, that peer reviews are performed frequently, that the environment is healthy, collaborative and collegial - -at all time.
This keeps the power and control in the right hands, yours.
If someone hits the lottery, you need to keep moving, never missing a step.

10. Never take yourself too seriously, try not to eat lunch alone, and take your entire team, your business clients and partners included, "out for beers" on a frequent basis.”

From: "rmcdevit" to <development-projectmanagement@Groups.ITtoolbox.com>

Published under the Creative Commons Attribution-No Derivative Works Licence 2.0 05/02/2015 23:46

Attribution: You may copy, distribute and display this copyrighted work only if you clearly credit “Avancier Limited: http://avancier.co.uk” at the start and include this footnote on each page.

No Derivative Works: You may copy, distribute, display only complete and verbatim copies of this paper, not derivative works based upon it – unless you have permission from the author.

For more about the licence, see http://creativecommons.org.

Software Development Life Cycle (SDLC)

Introduction

People matter too