The document discusses various software engineering process models, including prescriptive, V-model, incremental, evolutionary, and RAD models, each with distinct characteristics and use cases. It highlights the importance of meticulously defined requirements and the iterative nature of software development to manage risks and adapt to changing needs. Specialized process models like component-based development, formal methods, and aspect-oriented software development (AOSD) are also briefly examined for their roles in enhancing software quality and efficiency.

1. Subject: Software Engineering & Project
Management
Topic: Process Models
Shared By: Ms. K.D. Patil, SRES's SCOE,
Kopargaon

2. Prescriptive Process Model
 Originally proposed to bring order to chaos.
 Prescriptive process models advocate an orderly approach to software engineering.
 Called as Prescriptive because they prescribe a distinct set of process elements,
framework activities, SE actions, tasks, milestones, and work products, quality
assurance and change control mechanism for each project.
 The activities may be linear, incremental, or evolutionary


3. Waterfall Model
 Also called as classic life cycle
 Oldest software lifecycle model and best understood by
upper management
 Work flow is in a linear (i.e., sequential) fashion
 It suggests a systematic, sequential approach to software
development that begins with customer specification of
requirements and progress through planning, modeling,
construction and deployment with ongoing support of the
completed software


4. Waterfall Model
When to Use:
 Used often with well-defined adaptations or enhancements
to current software
 Used when requirements are well defined and reasonably
stable and risk is low
Problems:
 Doesn't support iteration, so changes can cause confusion
 Difficult for customers to state all requirements explicitly and
up front
 Requires customer patience because a working version of
the program doesn't occur until the final phase
 Problems can be somewhat alleviated in the model through
the addition of feedback loops

5. V-Model

6. V-Model
 A variation of waterfall model depicts the relationship of
quality assurance actions to the actions associated with
communication, modeling and early code construction
activates.

 Team first moves down the left side of the V to refine the
problem requirements. Once code is generated, the team
moves up the right side of the V, performing a series of tests
that validate each of the models created as the team moved
down the left side.

7. Incremental Process Model

8. Incremental Process Model
 It combines elements of linear and parallel process flows.
 Each linear sequence produces deliverable increments of
the software.
 Focuses on delivery of an operational product with each
increment.
 The first increment is often a core product with many
supplementary features. Users use it and evaluate it with
more modifications to better meet the needs.
 Increments can be plan to manage Technical Risks.
 Eg. Word Processing Software

9. Incremental Process Model
 When to Use:
 When initial requirements are reasonably well defined, but
the overall scope of the development effort precludes a
purely linear process.
 When there is a compelling need to expand a limited set of
new functions to a later system release.
 When staffing is unavailable.
 Steps:
 Communication
 Planning
 Modeling (Analysis, Design)
 Construction (Code, Test)
 Deployment (delivery, feedback)

10. Evolutionary Models
 Software system evolves over time as requirements often change
as development proceeds. Thus, a straight line to a complete end
product is not possible. However, a limited version must be
delivered to meet competitive pressure.
 Usually a set of core product or system requirements is well
understood, but the details and extension have yet to be defined.
 You need a process model that has been explicitly designed to
accommodate a product that evolved over time.
 It is iterative that enables you to develop increasingly more
complete version of the software.
 Two types : Prototyping and Spiral models.

11. Prototyping Model

12. Prototyping Model
 When to use: Customer defines a set of general objectives but
does not identify detailed requirements for functions and features.
Or Developer may be unsure of the efficiency of an algorithm, the
form that human computer interaction should take.
 What step:
 Begins with communication by meeting with stakeholders to
define the objective, identify whatever requirements are known,
outline areas where further definition is mandatory.
 A quick plan for prototyping and modeling (quick design)
occur.Quick design focuses on a representation of those
aspects the software that will be visible to end users. ( interface
and output).
 Design leads to the construction of a prototype which will be
deployed and evaluated.
 Stakeholder’s comments will be used to refine requirements.

13. Prototyping Model
 Both stakeholders and software engineers like the prototyping
paradigm.
 Users get a feel for the actual system, and developers get to
build something immediately. However, engineers may make
compromises in order to get a prototype working quickly.
 The less-than-ideal choice may be adopted forever after you get
used to it.
 Problems :
 The customer sees a "working version" of the software, wants
to stop all development and then buy the prototype after a "few
fixes" are made
 Developers often make implementation compromises to get the
software running quickly (e.g., language choice, user interface,
operating system choice, inefficient algorithms)


14. Spiral Model

15. Spiral Model
 Invented by Dr. Barry Boehm in 1988
 It couples the iterative nature of prototyping with
the controlled and systematic aspects of the
waterfall model
 It is a risk-driven process model generator that
is used to guide multi-stakeholder concurrent
engineering of software intensive systems.
 Two main distinguishing features:
 One is cyclic approach for incrementally growing a
system’s degree of definition and implementation
while decreasing its degree of risk.
 The other is a set of anchor point milestones

16. Spiral Model
 In Spiral Model, A series of evolutionary releases are
delivered.
 During the early iterations, the release might be a
model or prototype.
 During later iterations, increasingly more complete
version of the engineered system are produced.
 The first circuit in the clockwise direction might result
in the 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 results in adjustments to the
project plan. Cost and schedule are adjusted based on
feedback. Also, the number of iterations will be

17. Spiral Model
 First Circuit around the Spiral represent Concept
Development Project
 Starts at the core of spiral and continues for
multiple iterations until concept development is
complete.
 If the concept is developed into actual product, the
process proceeds outward on the spiral ans New
Product Development Project starts.
 New product will evolve through a number of
iterations.
 Later the circuit around the spiral might be used to
represent Product Enhancement Project.
 The the last round may represent Product

18. Spiral Model
 When to use:
 Good to develop large-scale system as software
evolves as the process progresses and risk should
be understood and properly reacted to.
 Prototyping is used to reduce risk.
 Problem:
 It may be difficult to convince customers that it is
controllable as it demands considerable risk

19. RAD Model (Rapid Application
Development)
 Is an incremental software development
process model that emphasizes an extremely
short development cycle.
 The RAD model is a “high-speed” adaption of
the linear sequential model.
 Rapid development is achieved by using
component based construction.
 The RAD process model enables a
development team to create a “fully functional
system” within very short time periods.

20. RAD Model

21. RAD Model
 Business Modeling:
 Is modeled to give answers for following questions:
 What information drives the business process?
 What information is generated?
 Who generates it?
 Where does the information go?
 Who processes it?
 Data Modeling:
 Information from Business Modeling is refined into a
set of data objects that are needed to support the
business.
 The attributes of each objects are identifies and the
relationships between these objects defined.

22. RAD Model
 Process Modeling:
 The data objects from data modeling are
transformed to achieve the information flow
necessary to implement the business functions.
 Processing descriptions are created for
 Adding
 Modifying
 Deleting
 Retrieving a data object.
 Application Generation:
 The RAD model assumes the use of fourth
generation techniques.
 The RAD process works to reuse the existing
program components or create reusable

23. RAD Model
 Testing and turnover:
 Since the RAD process emphasizes reuse, many of the program
components have already been tested.
 This reduce overall testing time.
 Only new components must be tested and all interfaces must be fully
exercised.
 Problems:
 For large scalable projects, RAD requires sufficient human resources to
create the right number of RAD teams.
 RAD requires developers and customers who are committed to the rapid
fire activities to get system complete within given time.
 Not all types of applications are appropriate for RAD.
 RAD is not appropriate when technical risks are high.


24. Concurrent
Model

25. Concurrent Model
 Allow a software team to represent iterative and concurrent elements of any of the
process models. For example, the modeling activity defined for the spiral model is
accomplished by invoking one or more of the following actions: prototyping, analysis
and design.
 The Figure shows modeling may be in any one of the states at any given time. For
example, communication activity has completed its first iteration and in the awaiting
changes state. The modeling activity was in inactive state, now makes a transition
into the under development state. If customer indicates changes in requirements, the
modeling activity moves from the under development state into the awaiting changes
state.
 Concurrent modeling is applicable to all types of software development and provides
an accurate picture of the current state of a project. Rather than confining software
engineering activities, actions and tasks to a sequence of events, it defines a process
network. Each activity, action or task on the network exists simultaneously with other
activities, actions or tasks. Events generated at one point trigger transitions among
the states.

26. General Weaknesses of
Evolutionary Process Models
 Prototyping poses a problem to project planning because of the
uncertain number of iterations required to construct the product
 Evolutionary software processes do not establish the maximum
speed of the evolution
 If too fast, the process will fall into chaos
 If too slow, productivity could be affected
 Software processes should focus first on flexibility and extensibility,
and second on high quality
 We should prioritize the speed of the development over zero defects
 Extending the development in order to reach higher quality could result
in late delivery

27. Specialized Process Models
 Three Types:
 Component-based Development Model
 Formal Methods Model
 Aspect Oriented software development (AOSD)

28. Component-based Development Model
 Consists of the following process steps
 Available component-based products are researched and evaluated for the application
domain in question
 Component integration issues are considered
 A software architecture is designed to accommodate the components
 Components are integrated into the architecture
 Comprehensive testing is conducted to ensure proper functionality
 Relies on a robust component library
 Capitalizes on software reuse, which leads to documented savings in project
cost and time

29. Formal Methods Model
 Encompasses a set of activities that leads to formal mathematical specification of
computer software
 Enables a software engineer to specify, develop, and verify a computer-based system
by applying a rigorous, mathematical notation
 Ambiguity, incompleteness, and inconsistency can be discovered and corrected more
easily through mathematical analysis
 Offers the promise of defect-free software
 Used often when building safety-critical systems
 Problems:
 Development of formal methods is currently quite time-consuming and expensive
 Because few software developers have the necessary background to apply
formal methods, extensive training is required
 It is difficult to use the models as a communication mechanism for technically
unsophisticated customers

30.  Aspect Oriented software development (AOSD)

 provides a process and methodological
approach for defining, specifying, designing,
and constructing aspects