Software development process
In software engineering, a software development
methodology (also known as a system development
methodology, software development
life cycle, software development
process, software process) is
splitting of software development work into distinct phases
(or stages) containing 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-definition of specific deliverables and artifacts that are
created and completed by a project team to develop or maintain an application.[1]
Common methodologies
include waterfall, prototyping, iterative and incremental development, spiral development, rapid application
development, extreme programming and various types of agile methodology. Some people consider a
life-cycle "model" a more general term for a category of
methodologies and a software development "process" a more specific
term to refer to a specific process chosen by a specific organization. For
example, there are many specific software development processes that fit the
spiral life-cycle model.
In practice
The
three basic approaches applied to software development methodology frameworks.
A
variety of such frameworks have evolved over the years, each with its own
recognized strengths and weaknesses. One software development methodology
framework is not necessarily suitable for use by all projects. Each of the
available methodology frameworks are best suited to specific kinds of projects,
based on various technical, organizational, project and team considerations.[1]
Software development organizations implement process
methodologies to ease the process of development. Sometimes, contractors may
require methodologies employed, an example is the U.S. defense industry,
which requires 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 ISO/IEC 12207.
A
decades-long goal has been to find repeatable, predictable processes that
improve productivity and quality. Some try to systematize or formalize the
seemingly unruly task of designing software. Others apply project management techniques to designing software.
Large numbers of software projects do not meet their expectations in terms of
functionality, cost, or delivery schedule
Organizations
may create a Software Engineering Process Group (SEPG), which is the focal point for
process improvement. Composed of line practitioners who have varied skills, the
group is at the center of the collaborative effort of everyone in the
organization who is involved with software engineering process improvement.
A
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 specific software libraries or software frameworks. These details are
generally not dictated by the choice of model or general methodology.
Approaches
Several
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 (SDLC) methodologies, though
this term could also be used more generally to refer to any methodology. A
"life cycle" approach with distinct phases is in contrast to Agile
approaches which define a process of iteration, but where design, construction,
and deployment of different pieces can occur simultaneously.
Waterfall development
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 sequential development approach, in which development is
seen as flowing steadily downwards (like a waterfall) through several phases,
typically:
·
Requirements analysis resulting in a software requirements specification
·
Testing
·
Integration, if there are multiple subsystems
·
Deployment (or Installation)
The
first formal description of the method is often cited as an article published
by Winston W. Royce in 1970 although Royce did not use the
term "waterfall" in this article. The basic principles are:
·
Project is divided into
sequential phases, with some overlap and splashback acceptable between phases.
·
Emphasis 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 project via extensive written documentation, formal
reviews, and approval/signoff by the user and information technology management
occurring at the end of most phases before beginning the next phase. Written
documentation is an explicit deliverable of each phase.
The
waterfall model is a traditional engineering approach applied to software
engineering. A strict waterfall approach discourages revisiting and revising
any prior phase once it is complete. This "inflexibility" in a pure
waterfall model has been a source of criticism by supporters of other more
"flexible" models. It has been widely blamed for several large-scale
government projects running over budget, over time and sometimes failing to
deliver on requirements due to the Big Design Up Front approach. Except when contractually
required, the waterfall model has been largely superseded by more flexible and
versatile methodologies developed specifically for software development.
The
waterfall model is sometimes taught with the mnemonic A Dance In The Dark Every Monday,
representing Analysis, Design, Implementation, Testing, Documentation and
Execution, and Maintenance.
Prototyping
Software prototyping is about creating prototypes, i.e.
incomplete versions of the software program being developed.
The
basic principles are:
·
Prototyping is not a
standalone, complete development methodology, but rather an approach to try out
particular features in the context of a full methodology (such as incremental,
spiral, or rapid application development (RAD)).
·
Attempts to reduce
inherent project risk by breaking a project into smaller segments and providing
more ease-of-change during the development process.
·
The client is involved
throughout the development process, which increases the likelihood of client
acceptance of the final implementation.
·
While some prototypes
are developed with the expectation that they will be discarded, it is possible
in some cases to evolve from prototype to working system.
A
basic understanding of the fundamental business problem is necessary to avoid
solving the wrong problems, but this is true for all software methodologies.
Incremental development
Various
methods are acceptable for combining linear and iterative systems development
methodologies, with the primary objective of each being to reduce inherent
project risk by breaking a project into smaller segments and providing more
ease-of-change during the development process.
1.
A series of
mini-Waterfalls are performed, where all phases of the Waterfall are completed
for a small part of a system, before proceeding to the next increment, or
2.
Overall requirements are
defined before proceeding to evolutionary, mini-Waterfall development of
individual increments of a system, or
3.
The initial software concept,
requirements analysis, and design of architecture and system core are defined
via Waterfall, followed by incremental implementation, which culminates in
installing the final version, a working system.
Iterative and incremental development
Iterative
development prescribes the
construction of initially small but ever-larger portions of a software project
to help all those involved to uncover important issues early before problems or
faulty assumptions can lead to disaster.
Spiral development
Spiral
model (Boehm, 1988)
In 1988, Barry Boehm published a formal software system
development "spiral model," which combines some key aspect of the waterfall model and rapid prototyping methodologies, in an effort to combine
advantages of top-down and bottom-up concepts. It provided emphasis in a
key area many felt had been neglected by other methodologies: deliberate
iterative risk analysis, particularly suited to large-scale complex systems.
The
basic principles are:
·
Focus is on risk
assessment and on minimizing project risk by breaking a project 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
project continuation throughout the life cycle.
·
"Each cycle
involves a progression through the same sequence 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.
·
Each trip around the
spiral traverses four basic quadrants: (1) determine objectives, alternatives,
and constraints of the iteration; (2) evaluate alternatives; Identify and
resolve risks; (3) develop and verify deliverables from the iteration; and (4)
plan the next iteration.
·
Begin each cycle with an
identification of stakeholders and their "win conditions", and end
each cycle with review and commitment.
Rapid application development
Rapid
Application Development (RAD) Model
Rapid application development (RAD) 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 RAD is
interleaved with writing the software itself. The lack of extensive
pre-planning generally allows software to be written much faster, and makes it
easier to change requirements.
The
rapid development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage,
requirements are verified using prototyping, eventually to refine the data and
process models. These stages are repeated iteratively; further development
results in "a combined business requirements and technical design
statement to be used for constructing new systems".
The
term was first used to describe a software development process introduced by James Martin in
1991. According to Whitten (2003), it is a merger of various structured techniques,
especially data-driven Information Engineering, with prototyping
techniques to accelerate software systems development.
The
basic principles of rapid application development are.
·
Key objective is for
fast development and delivery of a high quality system at a relatively low
investment cost.
·
Attempts to reduce inherent
project risk by breaking a project into smaller segments and providing more
ease-of-change during the development process.
·
Aims to produce high
quality systems quickly, primarily via iterative Prototyping (at any stage of
development), active user involvement, and computerized development tools.
These tools may include Graphical User Interface (GUI) builders, Computer Aided Software Engineering (CASE) tools, Database Management Systems (DBMS), fourth-generation programming
languages, code generators, and object-oriented techniques.
·
Key emphasis is on
fulfilling the business need, while technological or engineering excellence is
of lesser importance.
·
Project control involves
prioritizing development and defining delivery deadlines or “timeboxes”. If the
project starts to slip, emphasis is on reducing requirements to fit the
timebox, not in increasing the deadline.
·
Generally includes joint application design (JAD), where users are intensely
involved in system design,
via consensus building in either structured workshops, or electronically
facilitated interaction.
·
Active user involvement
is imperative.
·
Iteratively produces
production software, as opposed to a throwaway prototype.
·
Produces documentation
necessary to facilitate future development and maintenance.
·
Standard systems
analysis and design methods can be fitted into this framework.
Agile development
"Agile
software development" refers to a group of software development
methodologies based on iterative development, where requirements and solutions
evolve via collaboration between self-organizing cross-functional teams. The
term was coined in the year 2001 when the Agile Manifesto was formulated.
Agile
software development uses iterative development as a basis but advocates a
lighter and more people-centric viewpoint than traditional approaches. Agile
processes fundamentally incorporate iteration and the continuous feedback that
it provides to successively refine and deliver a software system.
There
are many agile methodologies, including:
·
Dynamic systems development method (DSDM)
·
Kanban
·
Scrum
Lightweight methodologies
A
lightweight methodology has a small number of rules. Some of these
methodologies are also considered "agile".
·
Adaptive Software Development by Jim Highsmith,
described in his 1999 book Adaptive
Software Development
·
Crystal Clear family of methodologies with Alistair
Cockburn,
·
Extreme Programming (XP), promoted by people such as Kent Beck and Martin Fowler.
In extreme programming, the phases are carried out in extremely small (or
"continuous") steps compared to the older, "batch"
processes. The (intentionally incomplete) first pass through the steps might
take a day or a week, rather than the months or years of each complete step in
the Waterfall model. First, one writes automated tests, to provide concrete
goals for development. Next is coding (by programmers working in pairs, a
technique 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. Design and architecture emerge from refactoring,
and come after coding. The same people who do the coding do design. (Only the
last feature — merging design and code — 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). At this
point, the practitioners start again on writing tests for the next most
important part of the system.[11]
·
Feature Driven Development (FDD) developed (1999) by Jeff De Luca and Peter Coad
·
ICONIX - UML-based object modeling with use
cases, a lightweight precursor to the Rational Unified Process
Other
Other
high-level software project methodologies include:
·
Chaos model - The main rule is always resolve the
most important issue first.
·
Incremental funding methodology - an iterative approach
·
Structured systems analysis and
design method - a
specific version of waterfall
·
Slow programming, as
part of the larger Slow Movement, emphasizes careful and
gradual work without (or minimal) time pressures. Slow programming aims to
avoid bugs and overly quick release schedules.
·
V-Model (software development) - an extension of the waterfall model
·
Unified Process (UP) is an iterative software
development methodology framework, based on Unified Modeling Language (UML). UP organizes the development of
software into four phases, each consisting of one or more executable iterations
of the software at that stage of development: inception, elaboration,
construction, and guidelines. Many tools and products exist to facilitate UP
implementation. One of the more popular versions of UP is the Rational Unified Process (RUP).
Code and fix
"Code
and fix" is an anti-pattern.
Development is not done through a deliberate strategy or methodology. It is
often the result of schedule pressure on the software development team.[13] Without much of a design in the way, programmers immediately begin producing code.
At some point, testing begins (often late in the development
cycle), and the unavoidable bugs must then be fixed - or at least, the
most important ones must be fixed - before the product can be shipped. See cowboy coding.
Process meta-models
Some
"process models" are abstract descriptions
for evaluating, comparing, and improving the specific process adopted by an
organization.
·
ISO/IEC 12207 is the international standard
describing the method to select, implement, and monitor the life cycle for
software.
·
The Capability Maturity Model Integration (CMMI) is one of the leading models
and based on best practice. Independent assessments grade organizations on how
well they follow their defined processes, not on the quality of those processes
or the software produced. CMMI has replaced CMM.
·
ISO 9000 describes standards for a formally
organized process to manufacture a product and the methods of managing and
monitoring progress. Although the standard was originally created for the
manufacturing sector, ISO 9000 standards have been applied to software
development as well. Like CMMI, certification with ISO 9000 does not guarantee
the quality of the end result, only that formalized business processes have
been followed.
·
ISO/IEC 15504 Information technology — Process
assessment also known as
Software Process Improvement Capability Determination (SPICE), is a
"framework for the assessment of software processes". This standard
is aimed at setting out a clear model for process comparison. SPICE is used
much like CMMI. It models processes to manage, control, guide and monitor
software development. This model is then used to measure what a development
organization or project team actually does during software development. This
information is analyzed to identify weaknesses and drive improvement. It also
identifies strengths that can be continued or integrated into common practice
for that organization or team.
·
SPEM 2.0 by the Object
Management Group
·
Soft systems methodology - a general method for improving
management processes
·
Method engineering - a general method for improving
information system processes
Formal methods
Formal methods are mathematical approaches to solving
software (and hardware) problems at the requirements, specification, and design
levels. Formal methods are most likely to be applied to safety-critical or
security-critical software and systems, such as avionics
software. Software safety assurance standards, such as DO-178B, DO-178C,
and Common Criteria demand formal methods at the highest
levels of categorization.
For
sequential software, examples of formal methods include the B-Method,
the specification languages used in automated theorem proving, RAISE, and the Z notation.
In functional programming, property-based
testing has allowed
the mathematical specification and testing (if not exhaustive testing) of the
expected behaviour of individual functions.
The Object Constraint Language (and specializations such as Java Modeling Language) has allowed
object-oriented systems to be formally specified, if not necessarily formally
verified.
For
concurrent software and systems, Petri nets, process algebra,
and finite state machines (which are based on automata theory - see also virtual finite state machine or event driven finite state machine)
allow executable software specification and can be used to build up and
validate application behavior.
Another
approach to formal methods in software development is to write a specification
in some form of logic—usually a variation of first-order
logic (FOL)—and then
to directly execute the logic as though it were a program. The OWL language,
based on Description Logic (DL), is an example. There is also
work on mapping some version of English (or another natural language)
automatically to and from logic, and executing the logic directly. Examples are Attempto Controlled English, and Internet
Business Logic, which do not seek to control the vocabulary or syntax. A
feature of systems that support bidirectional English-logic mapping and direct
execution of the logic is that they can be made to explain their results, in
English, at the business or scientific level.
Comments
Post a Comment