The goal of the software development process is to produce a high quality software product. As the development process specifies the major development and quality control, it therefore focuses on activities directly related to production of the software, for example, design, coding, and testing.
A process
model specifies a general process, the basic premise behind a process model is
that, in the situations for which the model is applicable, using the process
model as the project’s process will lead to low cost, high quality, reduced
cycle time, or provide other benefits. In other words, the process model
provides generic guidelines for developing a suitable process for a project.
The
following some of the software development process models :
- Waterfall Model
The model was originally proposed by Royce [74],
which states that the phases are organized in a linear order. In this model, a
project begins with feasibility analysis. Upon successfully demonstrating the
feasibility of a project, the requirements analysis and project planning begins
The design starts after the requirements analysis is complete, and coding
begins after the design is complete. Once the programming is completed, the
code is integrated and testing is done. Upon successful completion of testing,
the system is installed. After this, the regular operation and maintenance of
the system takes place.
the following documents generally form a reasonable
set that should be produced in each project :
·
Requirements
document
·
Project
plan
·
Design
documents (architecture, system, detailed)
·
Test
plan and test reports
·
Final
code
·
Software
manuals (e.g., user, installation, etc.)
The waterfall model, although widely used, has
some strong limitations. Some of the key limitations are:
- It assumes that the requirements of a system can be frozen (i.e., baselined) before the design begins. This is possible for systems designed to automate an existing manual system.
- Due to the speed at which hardware technology is changing, it is likely that the final software will use a hardware technology on the verge of becoming obsolete.
- It follows the “big bang” approach—the entire software is delivered in one shot at the end.
- It encourages “requirements bloating”.
- It is a document-driven process that requires formal documents at the end of each phase.
The waterfall model works well, and may be the
most efficient process.
- Prototyping
The goal of a prototyping-based development process
is to counter the first limitation of the waterfall model. The basic idea here
is that instead of freezing the requirements before any design or coding can
proceed, a throwaway prototype is built to help understand the requirements. By
using this prototype, the client can get an actual feel of the system, which
can enable the client to better understand the requirements of the desired
system.
Prototyping is an attractive idea for complicated
and large systems for which there is no manual process or existing system to
help determine the requirements. It is also an effective method of
demonstrating the feasibility of a certain approach. The following of the
prototyping model :
Overall, prototyping is well suited for projects
where requirements are hard to determine and the confidence in the stated
requirements is low. It is also an excellent technique for reducing some types
of risks associated with a project.
- Iterative Development
The iterative enhancement model is shown in this
Figure :
 |
| Iterative delivery approach |
- Rational Unified Process
Rational Unified Process (RUP) [51, 63] is another
iterative process model that was designed by Rational, now part of IBM.
RUP proposes that development of software be
divided into cycles, each cycle delivering a fully working system. Generally,
each cycle is executed as a separate project whose goal is to deliver some
additional capability to an existing system (built by the previous cycle).
Hence, for a project, the process for a cycle forms the overall process. Each
cycle itself is broken into four consecutive phases :
·
Inception
phase
·
Elaboration
phase
·
Construction
phase
·
Transition
phase
Each phase has a distinct purpose, and
completion of each phase is a well defined milest one in the project with some
clearly defined outputs. Similarly, the model has the development process
active in elaboration, which allows a project to build a prototype during the
elaboration phase to help its requirements activity, if needed. However, most
of the implementation does happen in the construction phase. The effort spent
in a subprocess in different phases will, of course, depend on the project.
Overall, RUP provides a flexible process model,
which follows an iterative approach not only at a top level (through cycles),
but also encourages iterative approach during each of the phases in a cycle.
And in phases, it allows the different tasks to be done as per the needs of the
project.
- Timeboxing Model
In the timeboxing model, the basic unit of development
is a time box, which is of fixed duration. Since the duration is fixed, a key
factor in selecting the requirements or features to be built in a time box is
what can be fit into the time box. This is in contrast to regular iterative approaches
where the functionality is selected and then the time to deliver is determined.
The model also requires that the duration of
each stage, that is, the time it takes to complete the task of that stage, is
approximately the same. Furthermore, the model requires that there be adedicated
team for each stage. That is, the team for a stage performs only tasks of that
stage—tasks for other stages are performed by their respective teams.
Timeboxing is well suited for projects that require
a large number of features to be developed in a short time around a stable
architecture using stable technologies.
- Extreme Programming and Agile Processes
Agile development approaches evolved in the
1990s as a reaction to documentation and bureaucracy-based processes,
particularly the waterfall approach.
Agile approaches are based on some common
principles, some of which are [www.extremeprogramming.org] :
·
Working
software is the key measure of progress in a project.
·
For
progress in a project, therefore, software should be developed and delivered
rapidly in small increments.
·
Even
late changes in the requirements should be entertained (small-increment model
of development helps in accommodating them).
·
Face-to-face
communication is preferred over documentation.
·
Continuous
feedback and involvement of customer is necessary for developing good-quality
software.
·
Simple
design which evolves and improves with time is a better approach than doing an
elaborate design up front for handling all possible scenarios.
·
The
delivery dates are decided by empowered teams of talented individuals (and are
not dictated).
Extreme programming (XP) is one of the most
popular and well-known approaches in the family of agile methods.
This is a very simplified description of XP.
There are many other rules in XP relating to issues like rights of programmers
and customers, communication between the team members and use of metaphors,
trust and visibility to all stakeholders, collective ownership of code in which
any pair can change any code, team management, building quick spike solutions
to resolve difficult technical and architectural issues or to explore some
approach, how bugs are to be handled, how what can be done within an iteration
is to be estimated from the progress made in the previous iteration, how
meetings are to be conducted, how a day in the development should start, etc.
XP, and other agile methods, are suitable for
situations where the volume and pace of requirements change is high, and where
requirement risks are considerable.
- Using Process Models in a Project
We have seen many different development process
models. What is the need for the different models? As mentioned earlier, while
developing (industrial strength) software, the purpose is not only to develop
software to satisfy the needs of some users or clients, but we want that the
project be done in low cost and cycle time, and deliver high-quality software.
Reference :
Software Engineering-London Springer-Verlag London (2008)
Summary Task From Mr. Benny Benyamin Nst
0 comments:
Post a Comment