Software Process

Models
Plan Driven
• Plan Driven processes are processes
where all of the process activities are
planned in advance and progress is
measured against this plan

2
Agile Processes

• In agile processes, planning incremental

and it is easier to change the plan and
the software to reflect changing
customer requirement

3
Cont.

• In practice, most practical processes

include elements of both plan-driven
and agile approaches.
• Different types of system need different
software processes.

4
Example
• Plan-driven Process
 Waterfall Model
• Agile Process
 Incremental Model

5
Software process model
• Attempt to organize the software life cycle by
• defining activities involved in software production
• order of activities and their relationships
• Goals of a software process
• standardization, predictability, productivity, high
product quality, ability to plan time and budget
requirements

6
Major problems in software developments …

The requirements The developers This is how the This is how the problem
specification was understood it in problem was is solved now
defined like this that way solved before.

That is the program after This is how the program is

described by marketing This, in fact, is what the
debugging
department customer wanted … ;-)
The Waterfall Model

8
 Waterfall model phases
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
The drawback of the waterfall model is the difficulty of
accommodating change after the process is underway
Waterfall Model Assumptions
1. The requirements are knowable in advance of implementation.
2. The requirements have no unresolved, high-risk implications
• e.g., risks due to choices, cost, schedule, performance, safety,
security, user interfaces, organizational impacts
3. The nature of the requirements will not change very much
• During development; during evolution
4. The requirements are compatible with all the key system
stakeholders’ expectations
• e.g., users, customer, developers, maintainers, investors
5. The right architecture for implementing the requirements is well
understood.
6. There is enough calendar time to proceed sequentially.

10
Incremental Models: Incremental

11
12
 Incremental development
• Rather than deliver the system as a single delivery, the
development and delivery is broken down into
increments with each increment delivering part of the
required functionality
• User requirements are prioritised and the highest priority
requirements are included in early increments
• Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve
Incremental development advantages

• Customer value can be delivered with each increment

so system functionality is available earlier
• Early increments act as a prototype to help elicit
requirements for later increments
• Lower risk of overall project failure
• The highest priority system services tend to
receive the most testing
15
When to use Incremental models?
• Requirements of the system are clearly understood
• When demand for an early release of a product
arises
• When software engineering team are not very well
skilled or trained
• When high-risk features and goals are involved
• Such methodology is more in use for web
application and product based companies

16
Incremental Models: RAD Model
Rapid Application Development

17
Business Modeling
The information flow among business functions is
modeled in a way that answers the following
questions: What information drives the business
process? What information is generated? Who
generates it? Where does the information go? Who
processes it?

18
Data Modeling
The information flow defined as part of the
business modeling phase is refined into a set of
data objects that are needed to support the
business. The characteristics (called attributes) of
each object are identified and the relationships
between these objects defined.

19
Process Modeling
The data objects defined in the data modeling
phase are transformed to achieve the information
flow necessary to implement a business function.
Processing descriptions are created for adding,
modifying, deleting, or retrieving a data object.

20
21
 When to use RAD Methodology?
• When a system needs to be produced in a short span
of time (2-3 months)
• When the requirements are known
• When the user will be involved all through the life
cycle
• When technical risk is less
• When there is a necessity to create a system that can
be modularized in 2-3 months of time
• When a budget is high enough to afford designers for
modeling along with the cost of automated tools for
code generation

22
Drawbacks of RAD
• InSufficient Human Resources
• Developers and customer’s commitment for rapid-
fire activities
• Modularization
• Difficult to achieve High Performance
• High Technical Risks

23
Evolutionary Process Models
Evolutionary models are iterative. They are
characterized in a manner that enables software
engineers to develop increasingly more complete
versions of the software.

24
Prototyping

25
• The different phases of Prototyping model are:
• 1.Communication
In this phase, developer and customer meet and discuss the overall
objectives of the software.

2. Quick design
• Quick design is implemented when requirements are known.
• It includes only the important aspects like input and output format of the
software.
• It focuses on those aspects which are visible to the user rather than the
detailed plan.
• It helps to construct a prototype.
• 3. Modeling quick design
• This phase gives the clear idea about the development of software because
the software is now built.
• It allows the developer to better understand the exact requirements.
• 4.Construction of prototype
The prototype is evaluated by the customer itself. 26
• 5. Deployment, delivery, feedback
• If the user is not satisfied with current prototype then it
refines according to the requirements of the user.
• The process of refining the prototype is repeated until
all the  requirements of users are met.
• When the users are satisfied with the developed
prototype then the system is developed on the basis
of final prototype.

27
28
The Spiral Model

29
The Spiral Model

30
Analysis of Spiral Model
• Strengths
• Easy to test
• Easy to maintain

• Weaknesses
• For large-scale software only
• For internal software only

31
32