Sear

Systems
development life
cycle

In syst ems engineering, informat ion syst ems and soft ware engineering, t he systems
development life cycle (SDLC), also referred t o as t he application development life-cycle, is a
process for planning, creat ing, t est ing, and deploying an informat ion syst em.[1] The syst ems
development life cycle concept applies t o a range of hardware and soft ware configurat ions, as a
syst em can be composed of hardware only, soft ware only, or a combinat ion of bot h.[2] There are
usually six st ages in t his cycle: requirement analysis, design, development and t est ing,
implement at ion, document at ion, and evaluat ion.
Model of the software development life cycle, highlighting the maintenance phase

Overview

A syst ems development life cycle is composed of a number of clearly defined and dist inct work
phases which are used by syst ems engineers and syst ems developers t o plan for, design, build,
t est , and deliver informat ion syst ems. Like anyt hing t hat is manufact ured on an assembly line, an
SDLC aims t o produce high-qualit y syst ems t hat meet or exceed cust omer expect at ions, based
on cust omer requirement s, by delivering syst ems which move t hrough each clearly defined
phase, wit hin scheduled t ime frames and cost est imat es.[3] Comput er syst ems are complex and
oft en (especially wit h t he recent rise of service-orient ed archit ect ure) link mult iple t radit ional
syst ems pot ent ially supplied by different soft ware vendors. To manage t his level of complexit y,
a number of SDLC models or met hodologies have been creat ed, such as wat erfall, spiral, Agile
soft ware development , rapid prot ot yping, increment al, and synchronize and st abilize.[4]

SDLC can be described along a spect rum of agile t o it erat ive t o sequent ial met hodologies. Agile
met hodologies, such as XP and Scrum, focus on light weight processes which allow for rapid
changes (wit hout necessarily following t he pat t ern of SDLC approach) along t he development
cycle.[5] It erat ive met hodologies, such as Rat ional Unified Process and dynamic syst ems
development met hod, focus on limit ed project scope and expanding or improving product s by
mult iple it erat ions. Sequent ial or big-design-up-front (BDUF) models, such as wat erfall, focus on
complet e and correct planning t o guide large project s and risks t o successful and predict able
result s. Ot her models, such as anamorphic development , t end t o focus on a form of
development t hat is guided by project scope and adapt ive it erat ions of feat ure development .

In project management a project can be defined bot h wit h a project life cycle (PLC) and an
SDLC, during which slight ly different act ivit ies occur. According t o Taylor (2004), "t he project life
cycle encompasses all t he act ivit ies of t he project , while t he syst ems development life cycle
focuses on realizing t he product requirement s".[6]

The SDLC is not a met hodology per se, but rat her a descript ion of t he phases in t he life cycle of
a soft ware applicat ion. In a broad sense, t hese phases are: invest igat ion, analysis, design, build,
t est , implement , and maint enance and support . All soft ware development met hodologies follow
t he SDLC phases but t he met hod of doing t hat varies vast ly bet ween met hodologies. In t he
Scrum framework,[7] for example, one could say a single user st ory goes t hrough all t he phases
of t he SDLC wit hin a single t wo-week sprint . Cont rast t his t o t he wat erfall met hodology, as
anot her example, where every business requirement (recorded in t he analysis phase of t he SDLC
in a document called t he Business Requirement s Specificat ion) is t ranslat ed int o
feat ure/funct ional descript ions (recorded in t he design phase in a document called t he
Funct ional Specificat ion) which are t hen all built in one go as a collect ion of solut ion feat ures
t ypically over a period of t hree t o nine mont hs, or more. These met hodologies are different
approaches, yet t hey bot h cont ain t he SDLC phases in which a requirement is born, t hen t ravels
t hrough t he life cycle phases ending in t he final phase of maint enance and support , aft er-which
t he whole life cycle t ypically st art s again for a subsequent version of t he soft ware applicat ion.

History and details

The product life cycle describes t he process for building informat ion syst ems in a very
deliberat e, st ruct ured and met hodical way, reit erat ing each st age of t he product 's life. The
syst ems development life cycle, according t o Elliot t & St rachan & Radford (2004), "originat ed in
t he 1960s, t o develop large scale funct ional business syst ems in an age of large scale business
conglomerat es. Informat ion syst ems act ivit ies revolved around heavy dat a processing and
number crunching rout ines".[8]

Several syst ems development frameworks have been part ly based on SDLC, such as t he
st ruct ured syst ems analysis and design met hod (SSADM) produced for t he UK government
Office of Government Commerce in t he 1980s. Ever since, according t o Elliot t (2004), "t he
t radit ional life cycle approaches t o syst ems development have been increasingly replaced wit h
alt ernat ive approaches and frameworks, which at t empt ed t o overcome some of t he inherent
deficiencies of t he t radit ional SDLC".[8]

Phases

The syst em development life cycle framework provides a sequence of act ivit ies for syst em
designers and developers t o follow. It consist s of a set of st eps or phases in which each phase
of t he SDLC uses t he result s of t he previous one.[9][10]

The SDLC adheres t o import ant phases t hat are essent ial for developers—such as planning,
analysis, design, and implement at ion—and are explained in t he sect ion below. This includes
evaluat ion of t he current ly used syst em, informat ion gat hering, feasibilit y st udies, and request
approval. A number of SDLC models have been creat ed, including wat erfall, fount ain, spiral, build
and fix, rapid prot ot yping, increment al, synchronize, and st abilize.[11][12] The oldest of t hese, and
t he best known, is t he wat erfall model, a sequence of st ages in which t he out put of each st age
becomes t he input for t he next .[10] These st ages can be charact erized and divided up in
different ways, including t he following:[9][10][13][14]
A ten-phase version of the systems development life cycle[9]

Preliminary analysis: Begin wit h a preliminary analysis, propose alt ernat ive solut ions, describe
cost s and benefit s, and submit a preliminary plan wit h recommendat ions.
1. Conduct t he preliminary analysis: Discover t he organizat ion's object ives and t he nat ure
and scope of t he problem under st udy. Even if a problem refers only t o a small segment
of t he organizat ion it self, find out what t he object ives of t he organizat ion it self are. Then
see how t he problem being st udied fit s in wit h t hem.

2. Propose alt ernat ive solut ions: Aft er digging int o t he organizat ion's object ives and specific
problems, several solut ions may have been discovered. However, alt ernat e proposals may
st ill come from int erviewing employees, client s, suppliers, and/or consult ant s. Insight may
also be gained by researching what compet it ors are doing.

3. Cost benefit analysis: Analyze and describe t he cost s and benefit s of implement ing t he
proposed changes. In t he end, t he ult imat e decision on whet her t o leave t he syst em as is,
 improve it , or develop a new syst em will be guided by t his and t he rest of t he preliminary
analysis dat a.
Systems analysis, requirements definition: Define project goals int o defined funct ions and
operat ions of t he int ended applicat ion. This involves t he process of gat hering and int erpret ing
fact s, diagnosing problems, and recommending improvement s t o t he syst em. Project goals will
be furt her aided by analysis of end-user informat ion needs and t he removal of any
inconsist encies and incomplet eness in t hese requirement s.
A series of st eps followed by t he developer include:[15]
1. Collect ion of fact s: Obt ain end user requirement s t hrough document at ion, client
int erviews, observat ion, and quest ionnaires.

2. Scrut iny of t he exist ing syst em: Ident ify pros and cons of t he current syst em in-place, so
as t o carry forward t he pros and avoid t he cons in t he new syst em.

3. Analysis of t he proposed syst em: Find solut ions t o t he short comings described in st ep
t wo and prepare t he specificat ions using any specific user proposals.
Systems design: At t his st ep, desired feat ures and operat ions are described in det ail,
including screen layout s, business rules, process diagrams, pseudocode, and ot her
document at ion.

Development: The real code is writ t en here.

Integration and testing: All t he modules are brought t oget her int o a special t est ing
environment , t hen checked for errors, bugs, and int eroperabilit y.

Acceptance, installation, deployment: This is t he final st age of init ial development , where
t he soft ware is put int o product ion and runs act ual business.

Maintenance: During t he maint enance st age of t he SDLC, t he syst em is assessed/evaluat ed

t o ensure it does not become obsolet e. This is also where changes are made t o init ial
soft ware.

Evaluation: Some companies do not view t his as an official st age of t he SDLC, while ot hers
consider it t o be an ext ension of t he maint enance st age, and may be referred t o in some
 circles as post -implement at ion review. This is where t he syst em t hat was developed, as well
as t he ent ire process, is evaluat ed. Some of t he quest ions t hat need t o be answered include if
t he newly implement ed syst em meet s t he init ial business requirement s and object ives, if t he
syst em is reliable and fault -t olerant , and if it funct ions according t o t he approved funct ional
requirement s. In addit ion t o evaluat ing t he soft ware t hat was released, it is import ant t o
assess t he effect iveness of t he development process. If t here are any aspect s of t he ent ire
process (or cert ain st ages) t hat management is not sat isfied wit h, t his is t he t ime t o improve.

Disposal: In t his phase, plans are developed for discont inuing t he use of syst em informat ion,
hardware, and soft ware and making t he t ransit ion t o a new syst em. The purpose here is t o
properly move, archive, discard, or dest roy informat ion, hardware, and soft ware t hat is being
replaced, in a manner t hat prevent s any possibilit y of unaut horized disclosure of sensit ive dat a.
The disposal act ivit ies ensure proper migrat ion t o a new syst em. Part icular emphasis is given
t o proper preservat ion and archiving of dat a processed by t he previous syst em. All of t his
should be done in accordance wit h t he organizat ion's securit y requirement s.[16]

In t he following diagram, t hese st ages of t he syst ems development life cycle are divided in t en
st eps, from definit ion t o creat ion and modificat ion of IT work product s:

Not every project will require t hat t he phases be sequent ially execut ed; however, t he phases are
int erdependent . Depending upon t he size and complexit y of t he project , phases may be
combined or may overlap.[9]

System investigation …

First t he IT syst em proposal is invest igat ed. During t his st ep, consider all current priorit ies t hat
would be affect ed and how t hey should be handled. Before any syst em planning is done, a
feasibilit y st udy should be conduct ed t o det ermine if creat ing a new or improved syst em is a
viable solut ion. This will help t o det ermine t he cost s, benefit s, resource requirement s, and
specific user needs required for complet ion. The development process can only cont inue once
management approves of t he recommendat ions from t he feasibilit y st udy.
The following represent different component s of t he feasibilit y st udy:

Operat ional feasibilit y

Financial feasibilit y

Technical feasibilit y

Human fact ors feasibilit y

Legal/Polit ical feasibilit y

Analysis …

The goal of analysis is t o det ermine where t he problem is, in an at t empt t o fix t he syst em. This
st ep involves breaking down t he syst em in different pieces t o analyze t he sit uat ion, analyzing
project goals, breaking down what needs t o be creat ed, and at t empt ing t o engage users so t hat
definit e requirement s can be defined.

Design …

In syst ems design, t he design funct ions and operat ions are described in det ail, including screen
layout s, business rules, process diagrams, and ot her document at ion. The out put of t his st age will
describe t he new syst em as a collect ion of modules or subsyst ems.

The design st age t akes as it s init ial input t he requirement s ident ified in t he approved
requirement s document . For each requirement , a set of one or more design element s will be
produced as a result of int erviews, workshops, and/or prot ot ype effort s.

Design element s describe t he desired syst em feat ures in det ail, and t hey generally include
funct ional hierarchy diagrams, screen layout diagrams, t ables of business rules, business process
diagrams, pseudo-code, and a complet e ent it y-relat ionship diagram wit h a full dat a dict ionary.
These design element s are int ended t o describe t he syst em in sufficient det ail, such t hat skilled
developers and engineers may develop and deliver t he syst em wit h minimal addit ional input
design.

Environments …

Environment s are cont rolled areas where syst ems developers can build, dist ribut e, inst all,
configure, t est , and execut e syst ems t hat move t hrough t he SDLC. Each environment is aligned
wit h different areas of t he SDLC and is int ended t o have specific purposes. Examples of such
environment s include t he:

development environment, where developers can work independent ly of each ot her before
t rying t o merge t heir work wit h t he work of ot hers;

common build environment, where merged work can be built , t oget her, as a combined syst em;

systems integration testing environment, where basic t est ing of a syst em's int egrat ion point s
t o ot her upst ream or downst ream syst ems can be t est ed;

user acceptance testing environment, where business st akeholders can t est against t heir
original business requirement s; and

production environment, where syst ems finally get deployed for final use by t heir int ended end
users.

Testing …

The code is t est ed at various levels in soft ware t est ing. Unit , syst em, and user accept ance
t ast ings are oft en performed. This is a grey area as many different opinions exist as t o what t he
st ages of t est ing are and how much, if any it erat ion occurs. It erat ion is not generally part of t he
wat erfall model, but t he means t o rect ify defect s and validat e fixes prior t o deployment is
incorporat ed int o t his phase.

The following are t ypes of t est ing t hat may be relevant , depending on t he t ype of syst em under
development :
 Defect testing t he failed scenarios, including

Pat h t est ing

Dat a set t est ing

Unit t est ing

Syst em t est ing

Int egrat ion t est ing

Black-box t est ing

Whit e-box t est ing

Regression t est ing

Aut omat ion t est ing

User accept ance t est ing

Soft ware performance t est ing

Training and transition …

Once a syst em has been st abilized t hrough adequat e t est ing, t he SDLC ensures t hat proper
t raining on t he syst em is performed or document ed before t ransit ioning t he syst em t o it s
support st aff and end users. Training usually covers operat ional t raining for t hose people who will
be responsible for support ing t he syst em as well as t raining for t hose end users who will be using
t he syst em aft er it s delivery t o a product ion operat ing environment .

Aft er t raining has been successfully complet ed, syst ems engineers and developers t ransit ion
t he syst em t o it s final product ion environment , where it is int ended t o be used by it s end users
and support ed by it s support and operat ions st aff.

Operations and maintenance …

The deployment of t he syst em includes various changes and enhancement s before t he
decommissioning or sunset of t he syst em. Maint aining t he syst em is a very import ant aspect of
SDLC. As key personnel change posit ions in t he organizat ion, new changes will be implement ed.
There are t wo approaches t o syst em development : t he t radit ional approach (st ruct ured) and
object orient ed. Informat ion engineering includes t he t radit ional syst em approach, which is also
called t he st ruct ured analysis and design t echnique. The object -orient ed approach views an
informat ion syst em as a collect ion of object s t hat are int egrat ed wit h each ot her t o make a full
and complet e informat ion syst em.

Evaluation …

The final phase of t he SDLC is t o measure t he effect iveness of t he syst em and evaluat e
pot ent ial enhancement s.

Systems analysis and design

The systems analysis and design (SAD) is t he process of developing informat ion t echnology
syst ems (ITS) t hat effect ively use hardware, soft ware, dat a, processes, and people t o support
t he company's businesses object ives. It is a process of planning a new business syst em or
replacing an exist ing syst em by defining it s component s or modules t o sat isfy specific
requirement s. Syst em analysis and design can be considered t he met a-development act ivit y,
which serves t o set t he st age and bound t he problem. SAD can be leveraged t o set t he correct
balance among compet ing high-level requirement s in t he funct ional and non-funct ional analysis
domains. Syst em analysis and design int eract st rongly wit h dist ribut ed ent erprise archit ect ure,
ent erprise I.T. Archit ect ure, and business archit ect ure, and relies heavily on concept s such as
part it ioning, int erfaces, personae and roles, and deployment /operat ional modeling t o arrive at a
high-level syst em descript ion. This high-level descript ion is t hen furt her broken down int o t he
component s and modules which can be analyzed, designed, and const ruct ed separat ely and
int egrat ed t o accomplish t he business goal. SDLC and SAD are cornerst ones of full life cycle
product and syst em planning.

Object-oriented analysis

Object -orient ed analysis (OOA) is t he process of analyzing a t ask (also known as a problem
domain), t o develop a concept ual model t hat can t hen be used t o complet e t he t ask. A t ypical
OOA model would describe comput er soft ware t hat could be used t o sat isfy a set of cust omer-
defined requirement s. During t he analysis phase of problem-solving, a programmer might consider
a writ t en requirement s st at ement , a formal vision document , or int erviews wit h st akeholders or
ot her int erest ed part ies. The t ask t o be addressed might be divided int o several subt asks (or
domains), each represent ing a different business, t echnological, or ot her areas of int erest . Each
subt ask would be analyzed separat ely. Implement at ion const raint s, (e.g., concurrency,
dist ribut ion, persist ence, or how t he syst em is t o be built ) are not considered during t he analysis
phase; rat her, t hey are addressed during object -orient ed design (OOD).

The concept ual model t hat result s from OOA will t ypically consist of a set of use cases, one or
more UML class diagrams, and a number of int eract ion diagrams. It may also include some kind of
user int erface mock-up.

The input for object -orient ed design is provided by t he out put of object -orient ed analysis.
Realize t hat an out put art ifact does not need t o be complet ely developed t o serve as input of
object -orient ed design; analysis and design may occur in parallel, and in pract ice t he result s of
one act ivit y can feed t he ot her in a short feedback cycle t hrough an it erat ive process. Bot h
analysis and design can be performed increment ally, and t he art ifact s can be cont inuously grown
inst ead of complet ely developed in one shot .

Some t ypical (but common t o all t ypes of design analysis) input art ifact s for object -orient ed:

Concept ual model: Concept ual model is t he result of object -orient ed analysis, it capt ures
concept s in t he problem domain. The concept ual model is explicit ly chosen t o be independent
 of implement at ion det ails, such as concurrency or dat a st orage.

Use case: Use case is a descript ion of sequences of event s t hat , t aken t oget her, lead t o a
syst em doing somet hing useful. Each use case provides one or more scenarios t hat convey
how t he syst em should int eract wit h t he users called act ors t o achieve a specific business
goal or funct ion. Use case act ors may be end users or ot her syst ems. In many circumst ances
use cases are furt her elaborat ed int o use case diagrams. Use case diagrams are used t o
ident ify t he act or (users or ot her syst ems) and t he processes t hey perform.

Syst em Sequence Diagram: Syst em Sequence diagram (SSD) is a pict ure t hat shows, for a
part icular scenario of a use case, t he event s t hat ext ernal act ors generat e, t heir order, and
possible int er-syst em event s.

User int erface document at ions (if applicable): Document t hat shows and describes t he look
and feel of t he end product 's user int erface. It is not mandat ory t o have t his, but it helps t o
visualize t he end-product and t herefore helps t he designer.

Relat ional dat a model (if applicable): A dat a model is an abst ract model t hat describes how
dat a is represent ed and used. If an object dat abase is not used, t he relat ional dat a model
should usually be creat ed before t he design, since t he st rat egy chosen for object -relat ional
mapping is an out put of t he OO design process. However, it is possible t o develop t he
relat ional dat a model and t he object -orient ed design art ifact s in parallel, and t he growt h of an
art ifact can st imulat e t he refinement of ot her art ifact s.

Life cycle

Management and control …

SPIU phases related to management controls [17]

The SDLC phases serve as a programmat ic guide t o project act ivit y and provide a flexible but
consist ent way t o conduct project s t o a dept h mat ching t he scope of t he project . Each of t he
SDLC phase object ives are described in t his sect ion wit h key deliverables, a descript ion of
recommended t asks, and a summary of relat ed cont rol object ives for effect ive management . It
is crit ical for t he project manager t o est ablish and monit or cont rol object ives during each SDLC
phase while execut ing project s. Cont rol object ives help t o provide a clear st at ement of t he
desired result or purpose and should be used t hroughout t he ent ire SDLC process. Cont rol
object ives can be grouped int o major cat egories (domains), and relat e t o t he SDLC phases as
shown in t he figure.[17]

To manage and cont rol any SDLC init iat ive, each project will be required t o est ablish some
degree of a work breakdown st ruct ure (WBS) t o capt ure and schedule t he work necessary t o
complet e t he project . The WBS and all programmat ic mat erial should be kept in t he "project
descript ion" sect ion of t he project not ebook. The WBS format is most ly left t o t he project
manager t o est ablish in a way t hat best describes t he project work.

There are some key areas t hat must be defined in t he WBS as part of t he SDLC policy. The
following diagram describes t hree key areas t hat will be addressed in t he WBS in a manner
est ablished by t he project manager.[17] The diagram shows coverage spans numerous phases of
t he SDLC but t he associat ed MCD has a subset of primary mappings t o t he SDLC phases. For
example, Analysis and Design is primarily performed as part of t he Acquisit ion and
Implement at ion Domain and Syst em Build and Prot ot ype is primarily performed as part of
delivery and support .

Work breakdown structured organization …

Work breakdown structure[17]

The upper sect ion of t he work breakdown st ruct ure (WBS) should ident ify t he major phases and
milest ones of t he project in a summary fashion. In addit ion, t he upper sect ion should provide an
overview of t he full scope and t imeline of t he project and will be part of t he init ial project
descript ion effort leading t o project approval. The middle sect ion of t he WBS is based on t he
seven syst ems development life cycle phases as a guide for WBS t ask development . The WBS
element s should consist of milest ones and "t asks" as opposed t o "act ivit ies" and have a
definit ive period (usually t wo weeks or more). Each t ask must have a measurable out put (e.x.
document , decision, or analysis). A WBS t ask may rely on one or more act ivit ies (e.g. soft ware
engineering, syst ems engineering) and may require close coordinat ion wit h ot her t asks, eit her
int ernal or ext ernal t o t he project . Any part of t he project needing support from cont ract ors
should have a st at ement of work (SOW) writ t en t o include t he appropriat e t asks from t he SDLC
phases. The development of a SOW does not occur during a specific phase of SDLC but is
developed t o include t he work from t he SDLC process t hat may be conduct ed by ext ernal
resources such as cont ract ors.[17]
Baselines
…
Baselines are an import ant part of t he syst ems development life cycle. These baselines are
est ablished aft er four of t he five phases of t he SDLC and are crit ical t o t he it erat ive nat ure of
t he model .[18] Each baseline is considered as a milest one in t he SDLC.

funct ional baseline: est ablished aft er t he concept ual design phase.

allocat ed baseline: est ablished aft er t he preliminary design phase.

product baseline: est ablished aft er t he det ail design and development phase.

updat ed product baseline: est ablished aft er t he product ion const ruct ion phase.

Complementary methodologies …

Complement ary soft ware development met hods t o syst ems development life cycle are:

Soft ware prot ot yping

Joint applicat ions development (JAD)

Rapid applicat ion development (RAD)

Ext reme programming (XP);

Open-source development

End-user development

Object -orient ed programming

Comparison of Methodology Approaches (Post, & Anderson 2006)[19]
Open End
SDLC RAD Objects JAD Prototyping
source User

Cont rol Formal MIS Weak St andards Joint User User

Short
Time frame Long Short Medium Any Medium Short
–

Users Many Few Few Varies Few One or t wo One

MIS st aff Many Few Hundreds Split Few One or t wo None

Transact ion/DSS Transact ion Bot h Bot h Bot h DSS DSS DSS

Int erface Minimal Minimal Weak Windows Crucial Crucial Crucial

Document at ion
Vit al Limit ed Int ernal In Object s Limit ed Weak None
and t raining

Int egrit y and

Vit al Vit al Unknown In Object s Limit ed Weak Weak
securit y

Reusabilit y Limit ed Some Maybe Vit al Limit ed Weak None

Strengths and weaknesses

Few people in t he modern comput ing world would use a st rict wat erfall model for t heir SDLC as
many modern met hodologies have superseded t his t hinking. Some will argue t hat t he SDLC no
longer applies t o models like Agile comput ing, but it is st ill a t erm widely in use in t echnology
circles. The SDLC pract ice has advant ages in t radit ional models of syst ems development t hat
lends it self more t o a st ruct ured environment . The disadvant ages t o using t he SDLC
met hodology is when t here is need for it erat ive development or (i.e. web development or e-
commerce) where st akeholders need t o review on a regular basis t he soft ware being designed.

A comparison of t he st rengt hs and weaknesses of SDLC:

Strength and Weaknesses of SDLC [19]
Strengths Weaknesses

Cont rol Increased development t ime

Monit or large project s Increased development cost

Det ailed st eps Syst ems must be defined up front

Evaluat e cost s and complet ion t arget s Rigidit y

Document at ion Hard t o est imat e cost s, project overruns

Well defined user input User input is somet imes limit ed

Ease of maint enance Lit t le parallelism

Development and design st andards Aut omat ion of document at ion and st andards is limit ed

Tolerat es changes in MIS of st affing Does not t olerat e changes in requirement s

Project s canned early on t he result in lit t le or no value

An alt ernat ive t o t he SDLC is rapid applicat ion development , which combines prot ot yping, joint
applicat ion development and implement at ion of CASE t ools. The advant ages of RAD are speed,
reduced development cost , and act ive user involvement in t he development process.

System lifecycle

The syst em lifecycle in syst ems engineering is a view of a syst em or proposed syst em t hat
addresses all phases of it s exist ence t o include syst em concept ion, design and development ,
product ion and/or const ruct ion, dist ribut ion, operat ion, maint enance and support , ret irement ,
phase-out and disposal.[20]

Conceptual design …
The concept ual design st age is t he st age where an ident ified need is examined, requirement s for
pot ent ial solut ions are defined, pot ent ial solut ions are evaluat ed and a syst em specificat ion is
developed. The syst em specificat ion represent s t he t echnical requirement s t hat will provide
overall guidance for syst em design. Because t his document det ermines all fut ure development ,
t he st age cannot be complet ed unt il a concept ual design review has det ermined t hat t he
syst em specificat ion properly addresses t he mot ivat ing need.

Key st eps wit hin t he concept ual design st age include:

Need ident ificat ion

Feasibilit y analysis

Syst em requirement s analysis

Syst em specificat ion

Concept ual design review

Preliminary system design …

During t his st age of t he syst em lifecycle, subsyst ems t hat perform t he desired syst em
funct ions are designed and specified in compliance wit h t he syst em specificat ion. Int erfaces
bet ween subsyst ems are defined, as well as overall t est and evaluat ion requirement s.[21] At t he
complet ion of t his st age, a development specificat ion is produced t hat is sufficient t o perform
det ailed design and development .

Key st eps wit hin t he preliminary design st age include:

Funct ional analysis

Requirement s allocat ion

Det ailed t rade-off st udies

Synt hesis of syst em opt ions

 Preliminary design of engineering models

Development specificat ion

Preliminary design review

For example, as t he syst em analyst of Vit i Bank, you have been t asked t o examine t he current
informat ion syst em. Vit i Bank is a fast growing bank in Fiji. Cust omers in remot e rural areas are
finding difficult y t o access t he bank services. It t akes t hem days or even weeks t o t ravel t o a
locat ion t o access t he bank services. Wit h t he vision of meet ing t he cust omers needs, t he bank
has request ed your services t o examine t he current syst em and t o come up wit h t he solut ions or
recommendat ions of how t he current syst em can be provided t o meet it s needs.

Detail design and development …

This st age includes t he development of det ailed designs t hat brings init ial design work int o a
complet ed form of specificat ions. This work includes t he specificat ion of int erfaces bet ween
t he syst em and it s int ended environment and a comprehensive evaluat ion of t he syst ems
logist ical, maint enance and support requirement s. The det ail design and development is
responsible for producing t he product , process and mat erial specificat ions and may result in
subst ant ial changes t o t he development specificat ion.

Key st eps wit hin t he det ail design and development st age include:

Det ailed design

Det ailed synt hesis

Development of engineering and prot ot ype models

Revision of development specificat ion

Product , process and mat erial specificat ion

Crit ical design review

Production and construction
…
During t he product ion and/or const ruct ion st age t he product is built or assembled in accordance
wit h t he requirement s specified in t he product , process and mat erial specificat ions and is
deployed and t est ed wit hin t he operat ional t arget environment . Syst em assessment s are
conduct ed in order t o correct deficiencies and adapt t he syst em for cont inued improvement .

Key st eps wit hin t he product const ruct ion st age include:

Product ion and/or const ruct ion of syst em component s

Accept ance t est ing

Syst em dist ribut ion and operat ion

Operat ional t est ing and evaluat ion

Syst em assessment

Utilization and support …

Once fully deployed, t he syst em is used for it s int ended operat ional role and maint ained wit hin
it s operat ional environment .

Key st eps wit hin t he ut ilizat ion and support st age include:

Syst em operat ion in t he user environment

Change management

Syst em modificat ions for improvement

Syst em assessment

Phase-out and disposal …

Effect iveness and efficiency of t he syst em must be cont inuously evaluat ed t o det ermine when
t he product has met it s maximum effect ive lifecycle.[22] Considerat ions include: Cont inued
exist ence of operat ional need, mat ching bet ween operat ional requirement s and syst em
performance, feasibilit y of syst em phase-out versus maint enance, and availabilit y of alt ernat ive
syst ems.

See also

Applicat ion lifecycle management

Decision cycle

IPO model

Soft ware development met hodologies

References

1. SELECTING A DEVELOPMENT APPROACH (https://web.archive.org/web/20190828154643/https://ww

w.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-Technology/XLC/Downloads/Select
ingDevelopmentApproach.pdf) . Retrieved 17 July 2014.

2. Parag C. Pendharkara; James A. Rodgerb; Girish H. Subramanian (November 2008). "An empirical
study of the Cobb–Douglas production function properties of software development effort".
Information and Software Technology. 50 (12): 1181–1188. doi:10.1016/j.infsof.2007.10.019 (https://d
oi.org/10.1016%2Fj.infsof.2007.10.019) .

3. "Systems Development Life Cycle from" (http://foldoc.org/Systems+Development+Life+Cycle) .

FOLDOC. Retrieved 2013-06-14.

4. "Software Development Life Cycle (SDLC)" (http://condor.depaul.edu/~jpetlick/extra/394/Session2.pp

t) .

5. "SDLC Overview: Models & Methodologies" (https://aristeksystems.com/blog/sdlc-overview/) .

Retrieved 2021-12-12.

. Taylor, James (2004). Managing Information Technology Projects. p. 39.

7. "What is Scrum?" (https://www.scrum.org/resources/what-is-scrum) . December 24, 2019.

 . Geoffrey Elliott & Josh Strachan (2004) Global Business Information Technology. p.87.

9. US Department of Justice (2003). INFORMATION RESOURCES MANAGEMENT (https://www.justice.go

v/archive/jmd/irm/lifecycle/table.htm) Chapter 1. Introduction.

10. Everatt, G.D.; McLeod, R Jr (2007). "Chapter 2: The Software Development Life Cycle" (https://books.goo
gle.com/books?id=z8UdPmvkBHEC&pg=PA29) . Software Testing: Testing Across the Entire Software
Development Life Cycle. John Wiley & Sons. pp. 29–58. ISBN 9780470146347.

11. Unhelkar, B. (2016). The Art of Agile Practice: A Composite Approach for Projects and Organizations (ht
tps://books.google.com/books?id=ZqnMBQAAQBAJ&pg=PA56) . CRC Press. pp. 56–59.
ISBN 9781439851197.

12. Land, S.K.; Smith, D.B.; Walz, J.W. (2012). Practical Support for Lean Six Sigma Software Process
Definition: Using IEEE Software Engineering Standards (https://books.google.com/books?id=SsBF_lVbK
_gC&pg=PA341) . John Wiley & Sons. pp. 341–3. ISBN 9780470289952.

13. Kay, Russell (May 14, 2002). "QuickStudy: System Development Life Cycle" (http://www.computerworld.c
om/s/article/71151/System_Development_Life_Cycle) . ComputerWorld.

14. Taylor, G.D. (2008). Introduction to Logistics Engineering (https://books.google.com/books?id=gqpZDN

c5_Y4C&pg=SA12-PA6) . CRC Press. pp. 12.6–12.18. ISBN 9781420088571.

15. "Chapter 5". Information Systems Control and Audit. Institute of Chartered Accountants of India.
August 2013. p. 5.28.

1 . Radack, S. (n.d.). "The system development life cycle (SDLC)" (http://csrc.nist.gov/publications/nistbul/

april2009_system-development-life-cycle.pdf) (PDF). National Institute of Standards and Technology.

17. U.S. House of Representatives (1999). Systems Development Life-Cycle Policy (http://www.house.gov/c
ontent/cao/procurement/ref-docs/SDLCPOL.pdf) . p.13. Archived (https://web.archive.org/web/20131
019091833/http://www.house.gov/content/cao/procurement/ref-docs/SDLCPOL.pdf) 2013-10-19 at
the Wayback Machine

1 . Blanchard, B. S., & Fabrycky, W. J.(2006) Systems engineering and analysis (4th ed.) New Jersey:
Prentice Hall. p.31

19. Post, G., & Anderson, D., (2006). Management information systems: Solving business problems with
information technology. (4th ed.). New York: McGraw-Hill Irwin.
20. Blanchard and Fabrycky (2006). Systems Engineering and Analysis, Fourth Edition. Prentice Hall. p. 19.

21. Dr. Joahn Gouws (2007). Introduction to Engineering, System Engineering. Melikon Pty Ltd.

22. Cunningham, James. "HERC Maintenance" (https://web.archive.org/web/20130121125359/http://hercb

pm.com.au/) . Fargo. XXI (North Avenue): 49. Archived from the original (https://www.hercbpm.co
m.au/) on 21 January 2013. Retrieved 13 May 2009.

Further reading

Cummings, Haag (2006). Management Information Systems for the Information Age. Toront o,
McGraw-Hill Ryerson

Beynon-Davies P. (2009). Business Information Systems. Palgrave, Basingst oke. ISBN 978-0-

230-20368-6

Comput er World, 2002 (ht t p://www.comput erworld.com/development t opics/development /st

ory/0,10801,71151,00.ht ml) , Ret rieved on June 22, 2006 from t he World Wide Web:

Management Informat ion Syst ems, 2005 (ht t ps://web.archive.org/web/20060901145404/ht t

p://www.cbe.wwu.edu/misclasses/MIS320_ Spring06_ Bajwa/Chap006.ppt ) , Ret rieved on
June 22, 2006 from t he World Wide Web:

External links

Wikimedia Commons has media related to Systems Development Life Cycle.

The Agile Syst em Development Lifecycle (ht t p://www.ambysoft .com/essays/agileLifecycle.h

t ml)

Pension Benefit Guarant y Corporat ion – Informat ion Technology Solut ions Lifecycle
Met hodology (ht t p://www.pbgc.gov/docs/ITSLCM%20V2007.1.pdf)

DoD Int egrat ed Framework Chart IFC (front (ht t ps://spacese.spacegrant .org/uploads/Projec
t %20Life%20Cycle/DAU_ wallChart .pdf) , back (ht t ps://www.dau.edu/cop/space/DAU%20Sp
 onsored%20Document s/Ver%205.4.14%20Space%20back%2025%20Jul%202012%20Final.p
df) )

FSA Life Cycle Framework (ht t ps://web.archive.org/web/20100707055603/ht t p://federalst ud

ent aid.ed.gov/st at ic/gw/docs/lcm/FSALCMFrameworkOverview.pdf)

HHS Ent erprise Performance Life Cycle Framework (ht t ps://www.hhs.gov/ocio/eplc/eplc_ fra
mework_ v1point 2.pdf)

The Open Syst ems Development Life Cycle (ht t p://OpenSDLC.org)

Syst em Development Life Cycle Evolut ion Modeling (ht t ps://www.scribd.com/doc/10396674

8/SDLC-Evolut ion-Model)

Zero Deviat ion Life Cycle (ht t ps://web.archive.org/web/20130217023015/ht t p://0deviat ion.co

m/)

Int egrat ed Defense AT&L Life Cycle Management Chart (ht t p://spacese.spacegrant .org/uploa
ds/Project %20Life%20Cycle/DAU_ wallChart .pdf) , t he U.S. DoD form of t his concept .

Retrieved from
"https://en.wikipedia.org/w/index.php?
title=Systems_development_life_cycle&oldid=1114
002735"
Last edited 14 days ago by 212.219.190.125