A software development process, also known as a software development life-cycle, is a
structure imposed on the development of a software product.
Similar terms include software life cycle and software process.
It is often considered a subset of systems development life cycle.
There are several models for such processes, each describing approaches to a variety of
tasks or activities that take place during the process.
Some people consider a life-cycle model a more general term and a software development
process a more specific term.
For example, there are many specific software development processes that 'fit' the spiral
life-cycle model.
ISO/IEC 12207 is an international standard for software life-cycle processes.
It aims to be the standard that defines all the tasks required for developing and maintaining
software.
Overview 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.
Without effective project management, software projects can easily be delivered late or over
budget.
With large numbers of software projects not meeting their expectations in terms of functionality,
cost, or delivery schedule, it is effective project management that appears to be lacking.
Organizations may create a Software Engineering Process Group, 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.
Software development activities Planning
Planning is an objective of each and every activity, where we want to discover things
that belong to the project.
An important task in creating a software program is extracting the requirements or requirements
analysis.
Customers typically have an abstract idea of what they want as an end result, but do
not know what software should do.
Skilled and experienced software engineers recognize incomplete, ambiguous, or even contradictory
requirements at this point.
Frequently demonstrating live code may help reduce the risk that the requirements are
incorrect.
Once the general requirements are gathered from the client, an analysis of the scope
of the development should be determined and clearly stated.
This is often called a scope document.
Certain functionality may be out of scope of the project as a function of cost or as
a result of unclear requirements at the start of development.
If the development is done externally, this document can be considered a legal document
so that if there are ever disputes, any ambiguity of what was promised to the client can be
clarified.
Designing Once the requirements are established, the
design of the software can be established in a software design document.
This involves a preliminary, or high-level design of the main modules with an overall
picture of how the parts fit together.
The language, operating system, and hardware components should all be known at this time.
Then a detailed or low-level design is created, perhaps with prototyping as proof-of-concept
or to firm up requirements.
Implementation, testing and documenting Implementation is the part of the process
where software engineers actually program the code for the project.
Software testing is an integral and important phase of the software development process.
This part of the process ensures that defects are recognized as soon as possible.
Documenting the internal design of software for the purpose of future maintenance and
enhancement is done throughout development.
This may also include the writing of an API, be it external or internal.
The software engineering process chosen by the developing team will determine how much
internal documentation is necessary.
Plan-driven models generally produce more documentation than Agile models.
Deployment and maintenance Deployment starts directly after the code
is appropriately tested, approved for release, and sold or otherwise distributed into a production
environment.
This may involve installation, customization, testing, and possibly an extended period of
evaluation.
Software training and support is important, as software is only effective if it is used
correctly.
Maintaining and enhancing software to cope with newly discovered faults or requirements
can take substantial time and effort, as missed requirements may force redesign of the software.
Software development models Several models exist to streamline the development
process.
Each one has its pros and cons, and it is up to the development team to adopt the most
appropriate one for the project.
Sometimes a combination of the models may be more suitable.
Waterfall model
The waterfall model shows a process, where developers have to follow these phases in
order: Requirements specification
Software design Implementation and Integration
Testing Deployment
Maintenance In a strict Waterfall model, after each phase
is finished, it proceeds to the next one.
Reviews may occur before moving to the next phase which allows for the possibility of
changes.
Reviews may also be employed to ensure that the phase is indeed complete; the phase-completion
criteria are often referred to as a "gate" that the project must pass through to move
to the next phase.
Waterfall discourages revisiting and revising any prior phase once it's complete.
This "inflexibility" in a pure Waterfall model has been a source of criticism by supporters
of other more "flexible" models.
The Waterfall model is also commonly taught with the mnemonic A Dance in the Dark Every
Monday, representing Analysis, Design, Implementation, Testing, Documentation and Execution, and
Maintenance.
Spiral model
The key characteristic of a Spiral model is risk management at regular stages in the development
cycle.
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, but 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 Spiral is visualized as a process passing through some number of iterations, with the
four quadrant diagram representative of the following activities:
Formulate plans to: identify software targets, implement the program, clarify the project
development restrictions Risk analysis: an analytical assessment of
selected programs, to consider how to identify and eliminate risk
Implementation of the project: the implementation of software development and verification
Risk-driven spiral model, emphasizing the conditions of options and constraints in order
to support software reuse, software quality can help as a special goal of integration
into the product development.
However, the spiral model has some restrictive conditions, as follows:
The spiral model emphasizes risk analysis, and thus requires customers to accept this
analysis and act on it.
This requires both trust in the developer as well as the willingness to spend more to
fix the issues, which is the reason why this model is often used for large-scale internal
software development.
If the implementation of risk analysis will greatly affect the profits of the project,
the spiral model should not be used.
Software developers have to actively look for possible risks, and analyze it accurately
for the spiral model to work.
The first stage is to formulate a plan to achieve the objectives with these constraints,
and then strive to find and remove all potential risks through careful analysis and, if necessary,
by constructing a prototype.
If some risks cannot be ruled out, the customer has to decide whether to terminate the project
or to ignore the risks and continue anyway.
Finally, the results are evaluated and the design of the next phase begins.
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.
Agile development
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 variations of agile processes: In extreme programming, the phases are carried
out in extremely small steps compared to the older, "batch" processes.
The 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, 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.
The incomplete but functional system is deployed or demonstrated for the users.
At this point, the practitioners start again on writing tests for the next most important
part of the system.
Dynamic systems development method Scrum
Rapid application development
Rapid application development R.A.D is a software development methodology that uses minimal
planning in favor of rapid prototyping.
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.
RAD involves methods like iterative development and software prototyping.
According to Whitten, it is a merger of various structured techniques, especially data-driven
Information Engineering, with prototyping techniques to accelerate software systems
development.
In rapid application development, structured techniques and prototyping are especially
used to define users' requirements and to design the final system.
The 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".
Code and fix "Code and fix" development is not so much
a deliberate strategy as an artifact of naïveté and schedule pressure on software developers.
Without much of a design in the way, programmers immediately begin producing code.
At some point, testing begins, and the unavoidable bugs must then be fixed before the product
can be shipped.
See also: Continuous integration and Cowboy coding.
Process improvement models Capability Maturity Model Integration
The Capability Maturity Model Integration 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 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 ISO/IEC 15504 Information technology — Process
assessment also known as Software Process Improvement Capability Determination, 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.
Formal methods Formal methods are mathematical approaches
to solving software 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.
Formalization of software development is creeping in, in other places, with the application
of Object Constraint Language and especially with model-driven architecture allowing execution
of designs, if not specifications.
For concurrent software and systems, Petri nets, process algebra, and finite state machines
allow executable software specification and can be used to build up and validate application
behavior.
Another emerging trend in software development is to write a specification in some form of
logic—usually a variation of first-order logic—and then to directly execute the logic
as though it were a program.
The OWL language, based on Description Logic, is an example.
There is also work on mapping some version of English 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.
See also
References
External links Gerhard Fischer, "The Software Technology
of the 21st Century: From Software Reuse to Collaborative Software Design", 2001