1

Software Processes
Software Processes 2

• Coherent sets of activities for specifying, designing,

implementing and testing software systems.
Objectives 3

• To introduce software process models

• To describe a number of different process models and when they
may be used
• To describe outline process models for requirements engineering,
software development, testing and evolution
• To introduce CASE technology to support software process
activities
The software process 4

• A structured set of activities required to develop a

software system
• Specification
• Design
• Validation
• Evolution
• A software process model is an abstract representation of a
process. It presents a description of a process from some
particular perspective
Waterfall model 5

• Waterfall model is universally known, simple and

powerful – yet it introduces many tough challenges to
software development processes.
• Known as software-life cycle, classical life cycle and
linear sequential model.
• The oldest and widely used model.
• A product is delivered after the linear sequence is
complete.
Waterfall model 6

Requirements
definition

System and
software design

Implementation
and unit testing

Integr ation and

system testing

Operation and
maintenance
Waterfall Model Limitations/Problems 7

• A phase should not start until the previous phase is signed off.
• Iterations is costly and involve significant work.
• Software is put into use during final phase of study.
• Partitioning into the distinct stages of projects is inflexible.
• Requirements should be well understood.
Waterfall model Limitations/Problems 8

• There is no way to collect all requirements at the start.

• Appropriate only when the requirements are well-understood
• There is no way to change requirement.
• It expects that people are never wrong.
• It expects that platform will not change.
• It expects that platform is known very well before implementation.
• It expects that problems and bugs are easy to locate and fix from the final
product. The product is always correctly designed and built, save for some
bugs.
Prototype Model 9
Prototype Model 10

 It is an effective paradigm for software engineering.

 Generally in this model developers listen to customer, design a
prototype and then the prototype is tested.
 The procedure is repeated until all the requirements of the system
are identified and a complex system can be designed for the system
Prototype Model 11

• Steps:
 First of all developers meet the customers and consult them. General
objectives are define and known requirements are identified.
 Areas where further definition is mandatory are outlined.
 A quick design occurs. The design focuses on a representation of
those aspects of the software that will be visible to customers/users
 Then a prototype is constructed.
 The prototype is evaluated to refine the software requirements.
 Iteration can occur to satisfy the customer’s needs.
Prototype Model 12

• Suitable scenario:
 General objectives of software are defined.
 Detail requirements of input, processing and output are not identified.
 Efficiency of algorithms is not sure.
 Adaptability can take place.
• The model’s objective:
 Defined rules are used in the prototype to identify the detail requirements.
Advantages of Prototype model 13

• Users are actively involved in the development

• Since in this methodology a working model of the system is
provided, the users get a better understanding of the system being
developed.
• Errors can be detected much earlier.
• Quicker user feedback is available leading to better solutions.
• Missing functionality can be identified easily
•.
Disadvantages of Prototype model 14

• Leads to implementing and then repairing way of building systems.

• Practically, this methodology may increase the complexity of the
system as scope of the system may expand beyond original plans.
• Incomplete application may cause application not to be used as
the full system was designed Incomplete or inadequate problem
analysis.
Incremental Model 15

• Incremental model is an approach to software development where

some of the developed increments are delivered to the customer
and deployed for use in an operational environment.

Design Coding Test Deployment

Requirements

Release 2
Design Coding Test Deployment
Release 3
Design Coding Test Deployment
Advantages of Incremental Model 16

• Customers can use the early increments as prototypes and gain

experience that informs their requirements for later system
increments.
• Customers do not have to wait until the entire system is delivered
before they can gain value from it.
• The process maintains the benefits of incremental development in
that it should be relatively easy to incorporate changes into the
system.
 Advantages of Incremental Model 17

• Provides better support for process iteration

• Reduces rework in the software construction process
• Some decisions on requirements may be delayed
• Allows early delivery of parts of the system
• Supports easier integration of sub-systems
• Lower risk of project failure
Disadvantages of Incremental Model 18

• Increments need be relatively small

• Mapping requirements to increments may not be easy
• Common software features may be difficult to identify
• Applicability:
• When it is possible to deliver the system “part-by-part”
Boehm’s spiral model 19

• A risk-driven software process framework (the spiral model) was

proposed by Boehm (1988).
• Here, the software process is represented as a spiral, rather than
a sequence of activities with some backtracking from one activity
to another. Each loop in the spiral represents a phase of the
software process.
spiral model 20

• Thus, the innermost loop might be concerned with system

feasibility, the next loop with requirements definition, the next
loop with system design, and so on. The spiral model combines
change avoidance with change tolerance.
21
Four Sectors of Spiral 22

• Objective setting:
Specific objectives for that phase of the project are defined.
detailed management plan is drawn up.
Project risks are identified.

• Risk assessment and reduction:

For each of the identified project risks, a detailed analysis is carried out.
Steps are taken to reduce the risk.
Four Sectors of Spiral 23

• Development and validation:

• After risk evaluation, a development model for the system is chosen.
• prototyping may be the best development approach if user interface risks
are dominant.
• If the main identified risk is sub-system integration, the waterfall model
may be the best development model to use.

• Planning:
• The project is reviewed and a decision made whether to continue with a
further loop of the spiral. If it is decided to continue, plans are drawn up
for the next phase of the project.
Advantages of Spiral Model 24

• Spiral Life Cycle Model is one of the most flexible SDLC models in
place. Development phases can be determined by the project
manager, according to the complexity of the project.
• Project monitoring: is very easy and effective. Each phase, as
well as each loop, requires a review from concerned people. This
makes the model more transparent.
• Risk management is one of the in-built features of the model,
which makes it extra attractive compared to other models.
Advantages of Spiral Model 25

• Changes can be introduced later in the life cycle as well. And

coping with these changes isn’t a very big headache for the
project manager.
• Project estimates in terms of schedule, cost etc become more and
more realistic as the project moves forward and loops in spiral get
completed.
• It is suitable for high risk projects, where business needs may be
unstable.
• A highly customized product can be developed using this.
Disadvantages of Spiral Model 26

• Cost involved in this model is usually high.

• Risk analysis is important phase so requires expert people.
• Is not beneficial for smaller projects.
• Spiral may go infinitely.
• Documentation is more as it has intermediate phases.
Rapid Application Development (RAD) 27

• RAD model is Rapid Application Development model. It is a type of

incremental model. In RAD model the components or functions are
developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into
a working prototype. This can quickly give the customer
something to see and use and to provide feedback regarding the
delivery and their requirements.
Rapid Application Development (RAD) 28

• RAD (rapid application development) is a model based on the

concept that higher-quality products can be developed faster
through more expedient processes, such as early prototyping,
reusing software components and less formality in team
communications.
RAD 29
Phases of RAD 30

• Communication is an activity which works to understand the business

problem and the information characteristics that should
be accommodate by the software.
• Planning is required because numerous software teams works in parallel
on different system functions.
• Modeling includes 3 major phases
• Business modeling: The information flow is identified between various business
functions.
• Data modeling: Information gathered from business modeling is used to define
data objects that are needed for the business.
• Process modeling: Data objects defined in data modeling are converted to
achieve the business information flow to achieve some specific business
objective. Description are identified and created for CRUD of data objects.
• Construction /Application generation: Automated tools are used to
convert process models into code and the actual system.
• Testing and Deployment: Test new components and all the interfaces.
Advantages of the RAD model 31

• Reduced development time.

• Increases reusability of components.
• Quick initial reviews occur.
• Encourages customer feedback.
• Integration from very beginning solves a lot of integration issues.
• Quick initial reviews are possible.
• Constant integration isolate problems and encourage customer feedback.
• Flexible and adaptable to changes.
• RAD realizes an overall reduction in project risk.
• RAD generally incorporates short development cycles - users see the RAD
product quickly.
Disadvantages of the RAD model 32

• RAD requires sufficient human resources to create the right

number of RAD teams. Requires highly skilled
developers/designers.
• Only system that can be modularized can be built using RAD
• Inapplicable to cheaper projects as cost of modeling.
• RAD approach does not work properly if high performance is a
major issue.
• When technical risks are high RAD may not be a suitable option.
Disadvantages of the RAD model 33

• Requires a systematic approach for modularized.

• Requires highly skilled and well-trained developers.
• Product may lose its competitive edge because of insufficient core
functionality and may exhibit poor overall quality.