In software engineering, a software development methodology (also known

as a system development methodology, software development life cycle,

software development process, software process) is a division of software
development work into distinct phases or activities with the intent of better
planning and management. It is often considered a subset of the systems
development life cycle. The methodology may include the pre-defnition of
specifc deliverables and artifacts that are created and completed by a
proect team to develop or maintain an application.!"#
$ommon methodologies include waterfall, prototyping, iterative and
incremental development, spiral development, rapid application
development, and e%treme programming. &ome people consider a life-cycle
'model' a more general term for a category of methodologies and a software
development 'process' a more specifc term to refer to a specifc process
chosen by a specifc organi(ation. )or e%ample, there are many specifc
software development processes that ft the spiral life-cycle model.* variety
of such frameworks have evolved over the years, each with its own
recogni(ed strengths and weaknesses. +ne software development
methodology framework is not necessarily suitable for use by all proects.
,ach of the available methodology frameworks are best suited to specifc
kinds of proects, based on various technical, organi(ational, proect and team
considerations.!"#
&oftware development organi(ations implement process methodologies to
ease the process of development. &ometimes, contractors may re-uire
methodologies employed, an e%ample is the ..&. defense industry, which
re-uires a rating based on process models to obtain contracts. The
international standard for describing the method of selecting, implementing
and monitoring the life cycle for software is I&+/I,$ "0012.
* decades-long goal has been to fnd repeatable, predictable processes that
improve productivity and -uality. &ome try to systemati(e or formali(e the
seemingly unruly task of designing software. +thers apply proect
management techni-ues to designing software. 3ithout e4ective proect
management, software proects can easily be delivered late or over budget.
3ith large numbers of software proects not meeting their e%pectations in
terms of functionality, cost, or delivery schedule, it is e4ective proect
management that appears to be lacking.
+rgani(ations may create a &oftware ,ngineering 5rocess 6roup (&,56),
which is the focal point for process improvement. $omposed of line
practitioners who have varied skills, the group is at the center of the
collaborative e4ort of everyone in the organi(ation who is involved with
software engineering process improvement.
* particular development team may also agree to programming environment
details, such as which integrated development environment is used, and one
or more dominant programming paradigms, programming style rules, or
choice of specifc software libraries or software frameworks. These details are
generally not dictated by the choice of model or general methodology.
7istory!edit#
The software development methodology (also known as &89) framework
didn:t emerge until the ";<1s. *ccording to ,lliott (011=) the systems
development life cycle (&8>$) can be considered to be the oldest formali(ed
methodology framework for building information systems. The main idea of
the &8>$ has been 'to pursue the development of information systems in a
very deliberate, structured and methodical way, re-uiring each stage of the
life cycle from inception of the idea to delivery of the fnal system, to be
carried out rigidly and se-uentially'!0# within the conte%t of the framework
being applied. The main target of this methodology framework in the ";<1s
was 'to develop large scale functional business systems in an age of large
scale business conglomerates. Information systems activities revolved around
heavy data processing and number crunching routines'.!0#
9ethodologies, processes, and frameworks range from specifc proscriptive
steps that can be used directly by an organi(ation in day-to-day work, to
?e%ible frameworks that an organi(ation uses to generate a custom set of
steps tailored to the needs of a specifc proect or group. In some cases a
'sponsor' or 'maintenance' organi(ation distributes an o@cial set of
documents that describe the process. &pecifc e%amples includeA
";21s
&tructured programming since ";<;
$ap 6emini &89, originally from 5*B8*T*, the frst ,nglish translation was
published in ";2=. &89 stands for &ystem 8evelopment 9ethodology
";C1s
&tructured systems analysis and design method (&&*89) from ";C1 onwards
Information De-uirement *nalysis/&oft systems methodology
";;1s
+bect-oriented programming (++5) developed in the early ";<1s, and
became a dominant programming approach during the mid-";;1s
Dapid application development (D*8), since ";;"
8ynamic systems development method (8&89), since ";;=
&crum, since ";;E
Team software process, since ";;C
Dational .nifed 5rocess (D.5), maintained by IF9 since ";;C
,%treme programming, since ";;;
0111s
*gile .nifed 5rocess (*.5) maintained since 011E by &cott *mbler
*pproaches!edit#
&everal software development approaches have been used since the origin of
information technology, in two main categories. Typically an approach or a
combination of approaches is chosen by management or a development
team.
'Traditional' methodologies such as waterfall that have distinct phases are
sometimes known as software development life cycle (&8>$) methodologies,
though this term could also be used more generally to refer to any
methodology. * 'life cycle' approach with distinct phases is in contrast to
*gile approaches which defne a process of iteration, but where design,
construction, and deployment of di4erent pieces can occur simultaneously.
3aterfall development!edit#
9ain articleA 3aterfall model
The activities of the software development process represented in the
waterfall model. There are several other models to represent this process.
The waterfall model is a se-uential development approach, in which
development is seen as ?owing steadily downwards (like a waterfall) through
several phases, typicallyA
De-uirements analysis resulting in a software re-uirements specifcation
&oftware design
Implementation
Testing
Integration, if there are multiple subsystems
8eployment (or Installation)
9aintenance
The frst formal description of the method is often cited as an article
published by 3inston 3. Doyce!G# in ";21 although Doyce did not use the
term 'waterfall' in this article. The basic principles areA!"#
5roect is divided into se-uential phases, with some overlap and splashback
acceptable between phases.
,mphasis is on planning, time schedules, target dates, budgets and
implementation of an entire system at one time.
Tight control is maintained over the life of the proect via e%tensive written
documentation, formal reviews, and approval/signo4 by the user and
information technology management occurring at the end of most phases
before beginning the ne%t phase.
The waterfall model is a traditional engineering approach applied to software
engineering. * strict waterfall approach discourages revisiting and revising
any prior phase once it is complete. This 'in?e%ibility' in a pure waterfall
model has been a source of criticism by supporters of other more '?e%ible'
models. It has been widely blamed for several large-scale government
proects running over budget, over time and sometimes failing to deliver on
re-uirements due to the Fig 8esign .p )ront approach. ,%cept when
contractually re-uired, the waterfall model has been largely superseded by
more ?e%ible and versatile methodologies developed specifcally for software
development. &ee $riticism of 3aterfall model.
The waterfall model is also commonly taught with the mnemonic * 8ance in
the 8ark ,very 9onday, representing *nalysis, 8esign, Implementation,
Testing, 8ocumentation and ,%ecution, and 9aintenance.!citation needed#
5rototyping!edit#
&oftware prototyping, is the development approach of activities during
software development, the creation of prototypes, i.e., incomplete versions of
the software program being developed.
The basic principles areA!"#
Bot a standalone, complete development methodology, but rather an
approach to handle selected parts of a larger, more traditional development
methodology (i.e. incremental, spiral, or rapid application development
(D*8)).
*ttempts to reduce inherent proect risk by breaking a proect into smaller
segments and providing more ease-of-change during the development
process.
.ser is involved throughout the development process, which increases the
likelihood of user acceptance of the fnal implementation.
&mall-scale mock-ups of the system are developed following an iterative
modifcation process until the prototype evolves to meet the usersH
re-uirements.
3hile most prototypes are developed with the e%pectation that they will be
discarded, it is possible in some cases to evolve from prototype to working
system.
* basic understanding of the fundamental business problem is necessary to
avoid solving the wrong problems.
Incremental development!edit#
Iarious methods are acceptable for combining linear and iterative systems
development methodologies, with the primary obective of each being to
reduce inherent proect risk by breaking a proect into smaller segments and
providing more ease-of-change during the development process.
The basic principles areA!"#
* series of mini-3aterfalls are performed, where all phases of the 3aterfall
are completed for a small part of a system, before proceeding to the ne%t
increment, or
+verall re-uirements are defned before proceeding to evolutionary, mini-
3aterfall development of individual increments of a system, or
The initial software concept, re-uirements analysis, and design of
architecture and system core are defned via 3aterfall, followed by iterative
5rototyping, which culminates in installing the fnal prototype, a working
system.
Iterative and incremental development!edit#
9ain articleA Iterative and incremental development
Iterative development!=# prescribes the construction of initially small but
ever-larger portions of a software proect to help all those involved to uncover
important issues early before problems or faulty assumptions can lead to
disaster.
&piral development!edit#
&piral model (Foehm, ";CC)
9ain articleA &piral model
In ";CC, Farry Foehm published a formal software system development
'spiral model,' which combines some key aspect of the waterfall model and
rapid prototyping methodologies, in an e4ort to combine advantages of top-
down and bottom-up concepts. It provided emphasis in a key area many felt
had been neglected by other methodologiesA deliberate iterative risk
analysis, particularly suited to large-scale comple% systems.
The basic principles areA!"#
)ocus is on risk assessment and on minimi(ing proect risk by breaking a
proect into smaller segments and providing more ease-of-change during the
development process, as well as providing the opportunity to evaluate risks
and weigh consideration of proect continuation throughout the life cycle.
',ach cycle involves a progression through the same se-uence of steps, for
each part of the product and for each of its levels of elaboration, from an
overall concept-of-operation document down to the coding of each individual
program.'!E#
,ach trip around the spiral traverses four basic -uadrantsA (") determine
obectives, alternatives, and constraints of the iterationJ (0) evaluate
alternativesJ Identify and resolve risksJ (G) develop and verify deliverables
from the iterationJ and (=) plan the ne%t iteration.!<#
Fegin each cycle with an identifcation of stakeholders and their 'win
conditions', and end each cycle with review and commitment.!2#
Dapid application development!edit#
Dapid *pplication 8evelopment (D*8) 9odel
Dapid application development (D*8) is a software development
methodology, which favors iterative development and the rapid construction
of prototypes instead of large amounts of up-front planning. The 'planning' of
software developed using D*8 is interleaved with writing the software itself.
The lack of e%tensive pre-planning generally allows software to be written
much faster, and makes it easier to change re-uirements.
The rapid development process starts with the development of preliminary
data models and business process models using structured techni-ues. In the
ne%t stage, re-uirements are verifed using prototyping, eventually to refne
the data and process models. These stages are repeated iterativelyJ further
development results in 'a combined business re-uirements and technical
design statement to be used for constructing new systems'.!C#
The term was frst used to describe a software development process
introduced by Kames 9artin in ";;". *ccording to 3hitten (011G), it is a
merger of various structured techni-ues, especially data-driven Information
,ngineering, with prototyping techni-ues to accelerate software systems
development.!C#
The basic principles of rapid application development areA!"#
Ley obective is for fast development and delivery of a high -uality system at
a relatively low investment cost.
*ttempts to reduce inherent proect risk by breaking a proect into smaller
segments and providing more ease-of-change during the development
process.
*ims to produce high -uality systems -uickly, primarily via iterative
5rototyping (at any stage of development), active user involvement, and
computeri(ed development tools. These tools may include 6raphical .ser
Interface (6.I) builders, $omputer *ided &oftware ,ngineering ($*&,) tools,
8atabase 9anagement &ystems (8F9&), fourth-generation programming
languages, code generators, and obect-oriented techni-ues.
Ley emphasis is on fulflling the business need, while technological or
engineering e%cellence is of lesser importance.
5roect control involves prioriti(ing development and defning delivery
deadlines or Mtimebo%esN. If the proect starts to slip, emphasis is on reducing
re-uirements to ft the timebo%, not in increasing the deadline.
6enerally includes oint application design (K*8), where users are intensely
involved in system design, via consensus building in either structured
workshops, or electronically facilitated interaction.
*ctive user involvement is imperative.
Iteratively produces production software, as opposed to a throwaway
prototype.
5roduces documentation necessary to facilitate future development and
maintenance.
&tandard systems analysis and design methods can be ftted into this
framework.
*gile development!edit#
9ain articleA *gile software development
'*gile software development' refers to a group of software development
methodologies based on iterative development, where re-uirements and
solutions evolve via collaboration between self-organi(ing cross-functional
teams. The term was coined in the year 011" when the *gile 9anifesto was
formulated.
*gile software development uses iterative development as a basis but
advocates a lighter and more people-centric viewpoint than traditional
approaches. *gile processes fundamentally incorporate iteration and the
continuous feedback that it provides to successively refne and deliver a
software system.
There are many variations of agile processesA
8ynamic systems development method (8&89)
Lanban
&crum
$ode and f%!edit#
9ain articleA $owboy coding
'$ode and f%' development is not so much a deliberate strategy as an
artifact of naOvetP and schedule pressure on software developers.!;# 3ithout
much of a design in the way, programmers immediately begin producing
code. *t some point, testing begins (often late in the development cycle), and
the unavoidable bugs must then be f%ed before the product can be shipped.
5rogramming without a planned-out design is also known as cowboy coding.
>ightweight methodologies!edit#
9ain articleA >ightweight methodology
* lightweight methodology has a small number of rules. &ome of these
methodologies are also considered 'agile'.
*daptive &oftware 8evelopment by Kim 7ighsmith, described in his ";;; book
*daptive &oftware 8evelopment
$rystal $lear family of methodologies with *listair $ockburn,
,%treme 5rogramming (Q5), promoted by people such as Lent Feck and
9artin )owler. In e%treme programming##, the phases are carried out in
e%tremely small (or 'continuous') steps compared to the older, 'batch'
processes. The (intentionally incomplete) frst pass through the steps might
take a day or a week, rather than the months or years of each complete step
in the 3aterfall model. )irst, one writes automated tests, to provide concrete
goals for development. Be%t is coding (by programmers working in pairs, a
techni-ue known as 'pair programming'), which is complete when all the
tests pass, and the programmers can:t think of any more tests that are
needed. 8esign and architecture emerge from refactoring, and come after
coding. The same people who do the coding do design. (+nly the last feature
R merging design and code R is common to all the other agile processes.)
The incomplete but functional system is deployed or demonstrated for (some
subset of) the users (at least one of which is on the development team). *t
this point, the practitioners start again on writing tests for the ne%t most
important part of the system.!"1#
)eature 8riven 8evelopment ()88) developed (";;;) by Ke4 8e >uca and
5eter $oad
I$+BIQ - .9>-based obect modeling with use cases, a lightweight precursor
to the Dational .nifed 5rocess
+ther!edit#
+ther high-level software proect methodologies includeA
$haos model - The main rule is always resolve the most important issue frst.
Incremental funding methodology - an iterative approach
&tructured systems analysis and design method - a specifc version of
waterfall
&low programming, as part of the larger &low 9ovement, emphasi(es careful
and gradual work without (or minimal) time pressures. &low programming
aims to avoid bugs and overly -uick release schedules.
I-9odel (software development) - an e%tension of the waterfall model
.nifed 5rocess (.5) is an iterative software development methodology
framework, based on .nifed 9odeling >anguage (.9>). .5 organi(es the
development of software into four phases, each consisting of one or more
e%ecutable iterations of the software at that stage of developmentA inception,
elaboration, construction, and guidelines. 9any tools and products e%ist to
facilitate .5 implementation. +ne of the more popular versions of .5 is the
Dational .nifed 5rocess (D.5).
5rocess meta-models!edit#
&ome 'process models' are abstract descriptions for evaluating, comparing,
and improving the specifc process adopted by an organi(ation.
I&+/I,$ "0012 is the international standard describing the method to select,
implement, and monitor the life cycle for software.
The $apability 9aturity 9odel Integration ($99I) is one of the leading models
and based on best practice. Independent assessments grade organi(ations on
how well they follow their defned processes, not on the -uality of those
processes or the software produced. $99I has replaced $99.
I&+ ;111 describes standards for a formally organi(ed process to
manufacture a product and the methods of managing and monitoring
progress. *lthough the standard was originally created for the manufacturing
sector, I&+ ;111 standards have been applied to software development as
well. >ike $99I, certifcation with I&+ ;111 does not guarantee the -uality of
the end result, only that formali(ed business processes have been followed.
I&+/I,$ "EE1= Information technology R 5rocess assessment also known as
&oftware 5rocess Improvement $apability 8etermination (&5I$,), is a
'framework for the assessment of software processes'. This standard is
aimed at setting out a clear model for process comparison. &5I$, is used
much like $99I. It models processes to manage, control, guide and monitor
software development. This model is then used to measure what a
development organi(ation or proect team actually does during software
development. This information is analy(ed to identify weaknesses and drive
improvement. It also identifes strengths that can be continued or integrated
into common practice for that organi(ation or team.
&oft systems methodology - a general method for improving management
processes
9ethod engineering - a general method for improving information system
processes
)ormal methods!edit#
)ormal methods are mathematical approaches to solving software (and
hardware) problems at the re-uirements, specifcation, and design levels.
)ormal methods are most likely to be applied to safety-critical or security-
critical software and systems, such as avionics software. &oftware safety
assurance standards, such as 8+-"2CF, 8+-"2C$, and $ommon $riteria
demand formal methods at the highest levels of categori(ation.
)or se-uential software, e%amples of formal methods include the F-9ethod,
the specifcation languages used in automated theorem proving, D*I&,, and
the S notation.
)ormali(ation of software development is creeping in, in other places, with
the application of +bect $onstraint >anguage (and speciali(ations such as
Kava 9odeling >anguage) and especially with model-driven architecture
allowing e%ecution of designs, if not specifcations.
)or concurrent software and systems, 5etri nets, process algebra, and fnite
state machines (which are based on automata theory - see also virtual fnite
state machine or event driven fnite state machine) allow e%ecutable software
specifcation and can be used to build up and validate application behavior.
*nother emerging trend in software development is to write a specifcation in
some form of logicRusually a variation of frst-order logic ()+>)Rand then to
directly e%ecute the logic as though it were a program. The +3> language,
based on 8escription >ogic (8>), is an e%ample. There is also work on
mapping some version of ,nglish (or another natural language) automatically
to and from logic, and e%ecuting the logic directly. ,%amples are *ttempto
$ontrolled ,nglish, and Internet Fusiness >ogic, which do not seek to control
the vocabulary or synta%. * feature of systems that support bidirectional
,nglish-logic mapping and direct e%ecution of the logic is that they can be
made to e%plain their results, in ,nglish, at the business or scientifc level.