Software Process, Perspective and Specialized Process Models:
One of the primary duties of
the manager of a software development project is to ensure that all of the
project activities follow a certain predefined process, i.e. that the activities are organized as a series of
actions conducing to a desirable end. The activities are usually organized in
distinct phases, and the process
specifies what artifacts should be developed and delivered in each phase. For a
software development team, conforming to a certain process means complying with
an appropriate order of actions or
operations. For the project manager, the process provides means for control and
guidance of the individual team members and the team as a whole, as it offers
criteria for tracing and evaluation of the project's deliverables and
activities.
Software
development process encompasses many different tasks, such as domain analysis
and development planning, requirements specification, software design,
implementation and testing, as well
as software maintenance.
Hence it is no surprise at all that a number of software development processes
exist. Generally, processes vary with the project’s goals (such as time to
market, minimum cost, higher quality and customer satisfaction), available resources
(e.g., the company’s size, the number, knowledge,
and experience of people --
both engineers and support personnel -- and hardware resources), and
application domain.
However,
every software developer and manager should note that processes are very important. It is absolutely
necessary to follow a certain predefined process in software development. It
helps developers understand, evaluate, control, learn, communicate, improve,
predict, and certify their work. Since processes vary with the project's size,
goals, and resources, as well as the level at which they are applied (e.g., the
organization level, the team level, or the individual level), it is always
important to define, measure, analyze, assess, compare, document, and change
different processes.
There
are several well-known examples of software development processes. Each process
relies on a certain model of software
development. The first well-established and well-documented software
development process has followed the waterfall
model. One of its variants is shown in Figure 2. The model assume that the
process of software development proceeds through several phases in a
more-or-less linear manner. The phases indicated in Figure 2 are supposed to be
relatively independent. There is not much feedback and returning to previous
phases other than the one directly preceding the phase in focus. In other
words, once a certain phase is finished it is considered closed, and the work
proceeds with the next phase. Many developers have criticized the waterfall
model for its rigidity in that sense, and for its failure to comply with the
reality of ever-changing requirements and technology. However, the waterfall
model is at least partially present in most of the other models as well, simply
because of its natural order of phases in software development.
System
feasibility
Requirements
specification
Preliminary
design
Detailed design Module coding and testing
System
integration
System
testing
Maintenance
Figure 2 - The waterfall model of software development
There
have been many attempts to overcome the limitations of the waterfall model. Two
common points in all such attempts are introduction of iterations in software development activities and incremental development. Iterative and
incremental software development means going through the same activities more than once, throughout
the product's lifecycle, each time producing new deliverables and/or improving
the old ones. The main advantage of working in that way is that each individual
developer works on a small ``work packet" at any given moment, which is
much easier to control.
A classical example of
iterative and incremental models is the spiral
model, sketched in Figure 3. In the spiral model, there are five core
tasks: planning and design (largely corresponding to the classical analysis
phase), approval (requirements specification), realization (design and
implementation), revision (testing and modification), and evaluation
(integration and system-level testing). The process iterates through these
tasks, getting closer and closer to the end by adding increments (e.g., new
functions, new design, new modules, new or improved testing procedures, new or
improved parts of the user interface, new integration and testing certificates,
and so on) to the product in each iteration. The spiral model underlies many
processes, such as DBWA (Design By Walking Around), and PADRE
(Plan-Approve-Do-Review-Evaluate). The DBWA process combines the spiral model
with multiple design views, flexible structuring of development teams, and
dynamic changes in modes of working (e.g., working individually, working in
pairs, or working in small teams), in order to improve the process efficiency
and parallelism. The PADRE process uses the spiral model at multiple levels -
the project level, the phase level, and the individual software module level -
thus creating the ``spiral in a spiral in a spiral" effect.
The JNIDS model (Joint National Intelligence Development Staff) is similar to the
spiral model in that it is also iterative and incremental. There are, however,
six tasks in the JNIDS model: requirements analysis, team orchestration (i.e.
the team-building stages, ``forming, storming, norming, and performing"),
design, coding, integration, and system implementation (delivery and
maintenance). The model prescribes to iterate through all six tasks in every
phase of software development. There are five phases (requirements
identification, prototype development, the breadth of system functionality,
system functionality refinement, and transition). They differ in the amount of
time and effort they dedicate to each specific task. The first phase focuses
most on requirements analysis, the second one focuses most on team
orchestration, and so on. The last phase is concentrated most on integration
and maintenance. Hence on the time axis the shift of the focus of attention in
different phases generates a waterfall-like shape if the six tasks are put on
the ordinal axis. However, an important difference between the classical
waterfall and JNIDS models is that in the JNIDS model developers conduct their
activities through all tasks in each phase.
The Unified Process for object-oriented software development, Figure 4,
has recently become very popular. It is also iterative and incremental, just
like the spiral and JNIDS models. All of its iterations go through five core
workflows (tasks) shown in Figure 4, and are grouped in four phases - inception
(resulting in a global vision of the software product), elaboration (detailed
analysis and design of the baseline architecture), construction (building the
system's initial capability), and transition (product release). Just like in
the JNIDS model, Figure 4 shows ``fuzzified" traces of the waterfall model
in the Unified Process. The process is architecture-centric, meaning that its
main deliverable is an executable architecture (the system), described by a set
of models generated during the system development (use-case model, analysis
model, design model, deployment model, implementation model, and test model).
The models are represented using the standard UML diagrams . The Unified
Process is also use-case oriented, which means that generic scenarios of how
the user or external applications use the system or its subsystems bind all the
workflows and drive the iterations.
Being
iterative, the Unified Process reduces additional development costs generated
by unexpected situations (usually just a single iteration of work is lost).
Iterating through all core workflows in every iteration, the process is
compliant with the reality of ever changing and incomplete user requirements.
The Unified Process is also risk-driven - it enforces examining areas of
highest risk in every phase and every iteration, as well as doing the most
critical tasks first. Hence it minimizes the risk of project runaways. Managers
can easily adapt the Unified Process to different application types, project
sizes, development teams, and levels of competence.
Because
of the importance of the Unified Process for software project management today,
comments on some other issues from the Unified Process perspective are included
in the following chapters.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.