SOFTWARE PROCESS MODELS-2

SPIRAL MODEL



The spiral model, originally proposed by Boehm [BOE88], is an evolutionary software
process model that couples the iterative nature of prototyping with the controlled and
systematic aspects of the linear sequential model. It provides the potential for rapid
development of incremental versions of the software. Using the spiral model, software
is developed in a series of incremental releases. During early iterations, the
incremental release might be a paper model or prototype. During later iterations,
increasingly more complete versions of the engineered system are produced.
A spiral model is divided into a number of framework activities, also called task
regions.6 Typically, there are between three and six task regions. Figure depicts a
spiral model that contains six task regions:
• Customer communication—tasks required to establish effective communication
between developer and customer.
• Planning—tasks required to define resources, timelines, and other projectrelated
information.
• Risk analysis—tasks required to assess both technical and management
risks.
• Engineering—tasks required to build one or more representations of the
application.
• Construction and release—tasks required to construct, test, install, and
provide user support

• Customer evaluation—tasks required to obtain customer feedback based
on evaluation of the software representations created during the engineering
stage and implemented during the installation stage.

Each of the regions is populated by a set of work tasks, called a task set, that are
adapted to the characteristics of the project to be undertaken. For small projects, the
number of work tasks and their formality is low. For larger, more critical projects,
each task region contains more work tasks that are defined to achieve a higher level
of formality. In all cases, the umbrella activities noted in Section 2.2 are applied.
As this evolutionary process begins, the software engineering team moves around
the spiral in a clockwise direction, beginning at the center. The first circuit around
the spiral might result in the development of a product specification; subsequent
passes around the spiral might be used to develop a prototype and then progressively
more sophisticated versions of the software. Each pass through the planning region
results in adjustments to the project plan. Cost and schedule are adjusted based on
feedback derived from customer evaluation. In addition, the project manager adjusts
the planned number of iterations required to complete the software.
Unlike classical process models that end when software is delivered, the spiral
model can be adapted to apply throughout the life of the computer software. An alternative
view of the spiral model can be considered by examining the project entry point
axis, also shown in Figure Each cube placed along the axis can be used to represent
the starting point for different types of projects. A “concept development

project” starts at the core of the spiral and will continue (multiple iterations occur
along the spiral path that bounds the central shaded region) until concept development
is complete. If the concept is to be developed into an actual product, the process
proceeds through the next cube (new product development project entry point) and
a “new development project” is initiated. The new product will evolve through a number
of iterations around the spiral, following the path that bounds the region that has
somewhat lighter shading than the core. In essence, the spiral, when characterized
in this way, remains operative until the software is retired. There are times when the
process is dormant, but whenever a change is initiated, the process starts at the appropriate
entry point.
The spiral model is a realistic approach to the development of large-scale systems
and software. Because software evolves as the process progresses, the developer and
customer better understand and react to risks at each evolutionary level. The spiral model
uses prototyping as a risk reduction mechanism but, more important, enables the developer
to apply the prototyping approach at any stage in the evolution of the product. It
maintains the systematic stepwise approach suggested by the classic life cycle but incorporates
it into an iterative framework that more realistically reflects the real world. The
spiral model demands a direct consideration of technical risks at all stages of the project
and, if properly applied, should reduce risks before they become problematic.
But like other paradigms, the spiral model is not a panacea. It may be difficult to
convince customers (particularly in contract situations) that the evolutionary approach
is controllable. It demands considerable risk assessment expertise and relies on this
expertise for success. If a major risk is not uncovered and managed, problems will
undoubtedly occur. Finally, the model has not been used as widely as the linear
sequential or prototyping paradigms. It will take a number of years before efficacy of
this important paradigm can be determined with absolute certainty.

Read more...

SOFTWARE PROCESS MODELS-1

INCREMENTAL MODEL

The incremental model combines elements of the linear sequential model (applied
repetitively) with the iterative philosophy of prototyping.The
incremental model applies linear sequences in a staggered fashion as calendar time
progresses. Each linear sequence produces a deliverable “increment” of the software
[MDE93]. For example, word-processing software developed using the incremental
paradigm might deliver basic file management, editing, and document production
functions in the first increment; more sophisticated editing and document production
capabilities in the second increment; spelling and grammar checking in the third
increment; and advanced page layout capability in the fourth increment. It should be
noted that the process flow for any increment can incorporate the prototyping paradigm.
When an incremental model is used, the first increment is often a core product.
That is, basic requirements are addressed, but many supplementary features (some
known, others unknown) remain undelivered. The core product is used by the customer
(or undergoes detailed review). As a result of use and/or evaluation, a plan is
developed for the next increment. The plan addresses the modification of the core
product to better meet the needs of the customer and the delivery of additional
features and functionality.

This process is repeated following the delivery of each The incremental process model, like prototyping and other evolutionary
approaches, is iterative in nature. But unlike prototyping, the incremental
model focuses on the delivery of an operational product with each increment. Early
increments are stripped down versions of the final product, but they do provide capability
that serves the user and also provide a platform for evaluation by the user.
Incremental development is particularly useful when staffing is unavailable for a
complete implementation by the business deadline that has been established for the
project. Early increments can be implemented with fewer people. If the core product
is well received, then additional staff (if required) can be added to implement the next
increment. In addition, increments can be planned to manage technical risks. For
example, a major system might require the availability of new hardware that is under
development and whose delivery date is uncertain. It might be possible to plan early
increments in a way that avoids the use of this hardware, thereby enabling partial
functionality to be delivered to end-users without inordinate delay.

increment, until the complete product is produced.

Read more...

SOFTWARE PROCESS

A software process can be characterized as shown in Figure  A common process
framework is established by defining a small number of framework activities that are
applicable to all software projects, regardless of their size or complexity. A number
of task sets—each a collection of software engineering work tasks, project milestones,
work products, and quality assurance points—enable the framework activities to be
adapted to the characteristics of the software project and the requirements of the
project team. Finally, umbrella activities—such as software quality assurance, software
configuration management, and measurement2—overlay the process model.
Umbrella activities are independent of any one framework activity and occur throughout
the process.
In recent years, there has been a significant emphasis on “process maturity.” The
Software Engineering Institute (SEI) has developed a comprehensive model predicated
on a set of software engineering capabilities that should be present as organizations
reach different levels of process maturity. To determine an organization’s
current state of process maturity, the SEI uses an assessment that results in a five
point grading scheme. The grading scheme determines compliance with a capability
maturity model (CMM)  that defines key activities required at different levels
of process maturity. The SEI approach provides a measure of the global effectiveness
of a company's software engineering practices and establishes five process maturity
levels that are defined in the following manner:
Level 1: Initial. The software process is characterized as ad hoc and occasionally
even chaotic. Few processes are defined, and success depends on individual
effort.
Level 2: Repeatable. Basic project management processes are established
to track cost, schedule, and functionality. The necessary process discipline is
in place to repeat earlier successes on projects with similar applications.
Level 3: Defined. The software process for both management and engineering
activities is documented, standardized, and integrated into an organizationwide
software process. All projects use a documented and approved
version of the organization's process for developing and supporting software.
This level includes all characteristics defined for level 2.
Level 4: Managed. Detailed measures of the software process and product
quality are collected. Both the software process and products are quantitatively
understood and controlled using detailed measures. This level includes all characteristics
defined for level 3.
Level 5: Optimizing. Continuous process improvement is enabled by quantitative
feedback from the process and from testing innovative ideas and technologies.
This level includes all characteristics defined for level 4.
The five levels defined by the SEI were derived as a consequence of evaluating
responses to the SEI assessment questionnaire that is based on the CMM. The results
of the questionnaire are distilled to a single numerical grade that provides an indication
of an organization's process maturity.
The SEI has associated key process areas (KPAs) with each of the maturity levels.
The KPAs describe those software engineering functions (e.g., software project planning,
requirements management) that must be present to satisfy good practice at a
particular level. Each KPA is described by identifying the following characteristics:
• Goals—the overall objectives that the KPA must achieve.
• Commitments—requirements (imposed on the organization) that must be met
to achieve the goals or provide proof of intent to comply with the goals.
• Abilities—those things that must be in place (organizationally and technically)
to enable the organization to meet the commitments.
• Activities—the specific tasks required to achieve the KPA function.
• Methods for monitoring implementation—the manner in which the activities
are monitored as they are put into place.
• Methods for verifying implementation—the manner in which proper practice
for the KPA can be verified.
Eighteen KPAs (each described using these characteristics) are defined across the
maturity model and mapped into different levels of process maturity. The following
KPAs should be achieved at each process maturity level:3
Process maturity level 2
• Software configuration management
• Software quality assurance
• Software subcontract management
• Software project tracking and oversight
• Software project planning
• Requirements management
Process maturity level 3
• Peer reviews
• Intergroup coordination
• Software product engineering
• Integrated software management
• Training program
• Organization process definition
• Organization process focus
Process maturity level 4
• Software quality management
• Quantitative process management
Process maturity level 5
• Process change management
• Technology change management
• Defect prevention

Read more...