Module 1

Software Process Models

A process model for software engineering is chosen based on the
nature of the project and application,
the methods and tools to be used, and
the controls and deliverables that are required.
All software development can be characterized as a problem solving loop in which four
distinct stages are encountered:
status quo,
problem definition,
technical development, and
solution integration.

Status quo represents the current state of affairs

problem definition identifies the specific problem to be solved;
technical development solves the problem through the application of some
technology, and
solution integration delivers the results (e.g., documents, programs, data,new
business function, new product)
This problem solving loop applies to software engineering work at many different
levels of resolution.
It can be used at the
macro level when the entire application isconsidered,
at a mid-level when program components are being engineered,
at the line of code level.
Therefore, a fractal representation can be used to provide an idealized view of process

The Prototyping Model

The prototyping paradigm begins with requirements gathering.

Developer and customer
meet and define the overall objectives for the software,
identify whatever requirements are known, and
outline areas where further definition is mandatory.
A "quick design" then occurs.
The quick design focuses on a representation of those aspects of the software that
will be visible to the customer/user
The quick design leads to the construction of a prototype.
The prototype is evaluated by the customer/user and used to refine requirements for
the software to be developed.
Iteration occurs as the prototype is tuned to satisfy the needs of the customer, while
at the same time enabling the developer to better understand what needs to be done.
Ideally, the prototype serves as a mechanism for identifying software requirements

Problems
1. The customer sees what appears to be a working version of the software,unaware
that in the rush to get it working no one has considered overall software quality or
long-term maintainability
2. The developer often makes implementation compromises in order to get aprototype
working quickly.
An inappropriate operating system or programming language may be used simply
because it is available and known;
An inefficient algorithm may be implemented simply to demonstrate capability.
After a time, the developer may become familiar with these choices and forget all the
reasons why they were inappropriate.
Although problems can occur, prototyping can be an effective paradigm for software
engineering.

Incremental Model -Evolutionary Model

The incremental model combines elements of the linear sequential model with the
iterative philosophy of prototyping.
the incremental model applies linear sequences in a staggered fashion.
Each linear sequence produces a deliverable increment of the software

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.
When an incremental model is used, the first increment is often a core product.
That is, basic requirements are addressed, but many supplementary features remain
undelivered.
The core product is used by the customer .
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 eac increment, until the complete
product is produced.
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.
Incremental development is particularly useful when staffing is unavailable for
acomplete 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

Spiral Model
The spiral model,originally proposed by Boehm , 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.
Customer communicationtasks required to establish effective communication
between developer and customer.
Planningtasks required to define resources, timelines, and other project related
information.
Risk analysistasks required to assess both technical and management risks.
Engineeringtasks required to build one or more representations of the application.
Construction and releasetasks required to construct, test, install, and provide user
support (e.g., documentation and training
Customer evaluationtasks required to obtain customer feedback based on
evaluation of the software representations created during the engineering stage and

implemented
during
the
installation
stage
Alternative view of the spiral model
An alternative view of the spiral model can be considered by examining the project
entry point axis.
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 until
concept development is complete.
If the concept is to be developed into an actual product, the process proceeds
through the next cube 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.
Whenever a change is initiated, the process starts at the appropriate entry point (e.g.,
product enhancement).
Advantages

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.
Itmaintains 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
Disadvantages
It may be difficult to convince customers 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.

Waterfall Model or Classic Life Cycle

 Requirement Analysis and Definition: What - The systems services, constraints and
goals are defined by customers with system users.
Scheduling tracking Assessing progress against the project plan.
Require action to maintain schedule.
System and Software Design: How It establishes and overall system architecture.
Software design involves fundamental system abstractions and their relationships.
Integration and system testing: The individual program unit or programs are
integrated and tested as a complete system to ensure that the software requirements
have been met. After testing, the software system is delivered to the customer.
Operation and Maintenance: Normally this is the longest phase of the software life
cycle. The system is installed and put into practical use. Maintenance involves
correcting errors which were not discovered in earlier stages of the life-cycle.
Limitations of the waterfall model
The nature of the requirements will not change very much During development;
during evolution
The model implies that you should attempt to complete a given stage before moving
on to the next stage
Does not account for the fact that requirements constantly change.
It also means that customers can not use anything until the entire system is
complete.
The model implies that once the product is finished, everything else is maintenance.
Surprises at the end are very expensive
Some teams sit ideal for other teams to finish
Therefore, this model is only appropriate when the requirements are well-understood
and changes will be fairly limited during the design process.
Problems:
1. Real projects are rarely follow the sequential model.
2. Difficult for the customer to state all the requirement explicitly.
3. Assumes patience from customer - working version of program will not available until
programs not getting change fully.
Capability Maturity Model Integration (CMMI)
The Software Engineering Institute (SEI) has developed process meta-model to
measure organization different level of process capability and maturity.
CMMI developed by SEI

 The CMMI defines each process area in terms of specific goals and the specific
practices required to achieve these goals.
Specific goals establish the characteristics that must exist if the activities implied by
a process area are to be effective.
Specific practices refine a goal into a set of process-related activities.
CMMI Levels
Level 0 (Incomplete)
Process are not perform or not achieve all the goals and objectives defined by
the CMMI for Level I capability.
Level 1 (Performed) All specific goals are performed as per defined by CMMI
Level 2 (Managed)
All level 1 criteria have been satisfied
In addition to Level I;
People doing work have access to adequate resources to get job done,
Stakeholders are actively involved,
Work tasks and products are monitored, controlled, reviewed, and
evaluated for conformance to process description.
Level 3 (Defined)
All level 2 criteria have been achieved.
In addition;
management and engineering processes documented
standardized and integrated into organization-wide software process
Level 4 (Quantitatively Managed) All level 3 criteria have been satisfied.
Software process and products are quantitatively understood
Controlled using detailed measures and assessment.
Level 5 (Optimized)
Continuous process improvement is enabled by quantitative feedback from the
process and testing innovative ideas.