The document discusses various software development approaches and models, including plan-driven, agile, and DevOps methodologies, each catering to different project requirements and customer needs. It highlights the limitations and appropriate contexts for classic, evolutionary, reuse-oriented, rapid application development (RAD), and spiral models. The Rational Unified Process (RUP) is introduced as a comprehensive framework integrating best practices from multiple development approaches.

1. Software Development
Approaches and Process
Models
Chapter 2: Software development approaches
and process models

2. What is software development
process?
• A structured set of activities required to
develop a software.
• Many different software processes, but
ALL involve:
Specification
Development (Design and
implementation)
Validation
Evolution

3. Plan-driven VS Agile development
approach VS DevOps approach
• Plan-driven approach, is a practice where ALL
development activities planned in advance and
progress is measured against that plan.
• Agile approach (continuous delivery), is a
practice where planning incrementally
achieved and easier to change the process to
reflect changing customer requirements.
• DevOps approach (continuous deployment), is
a practice that aims at merging development,
quality assurance, and operations
(deployment and integration) into a single,
continuous set of processes. This methodology
is a natural extension of Agile and continuous
delivery approaches.

4. Waterfall development approach

5. Agile development approach

6. DevOps development approach

7. In practice, no right or
wrong software
development approach

8. Software development process models
• The classic development process model
 Plan-driven approach.
 Separate and distinct phases of specification and
development.
• Evolutionary development process model
 Specification, development and validation are interleaved.
 Could be agile or DevOps.
• Reuse-oriented development process model
 The system is assembled from existing reusable
components, rather than developing them from scratch.
 May be plan-driven or agile.
In practice, most large systems are developed using a
process that incorporates elements from ALL of these
models.

9. Classic development process model

10. Limitations of the classic
development process model
• In practice, requirements are changed
frequently.
• Never go back to previous phase to fix
errors or problems.
• The customer can not use the
software UNTIL the entire system is
complete.
• The model implies that once the
software is completed, everything else
is maintenance cost.

11. When the classic development
process model is appropriate to use?
• Requirements must be well-
understood and identified.
• No changes in requirements
during the development process.
• Large scale software projects
where a software project is
developed at several sites.

12. Evolutionary development process models
• Based on developing an initial
implementation, exposing this to user’s
comments and refining it through many
versions until an adequate software is
developed.
• Specification, development and validation
activities are interleaved with rapid feedback
across activities

13. Types of evolutionary development
process model
Incremental development approach:
This approach works with the customer to
explore their requirements and deliver a
final software step by step. The
development starts with the
requirements of the software that are
well-understood.
Prototyping development approach:
This approach emphasizes on
experimenting with the customer
requirements that are poorly
understood. The development follows
proof of concept method.

14. Limitations of the incremental
development process model
• Lack of process visibility.
• Software is usually poorly
structured.
• Special skills (e.g. technical
skills) may be required for rapid
prototyping.

15. When the incremental development process model is appropriate to use?
• Small to medium size
software projects.
• NOT enough staffing is
available for the whole
software project.
• Parts of a large-scale
project (e.g. user
interfaces)
• Short-lifetime software
projects.

16. Limitations of the prototyping
development process model
• Project may expand beyond the original plans.
• Cost factor since it may take several iterations
for defining software requirements.
• Designing prototypes sometimes quick rather
than quality

17. When the prototyping development
process model is appropriate to use?
• When the customer has poor
information about the software.
• When the software project needs to
have a lot of interaction with end
users.
• Web user interfaces.
• High technology software
projects.

18. Rapid Application Development (RAD)
Model
• It makes heavy use of reusable
software components with an
extremely short development cycle
(60-90) days.

19. Limitations of the RAD development
process model
• Requires sufficient human
resources, particularly for large scale
projects.
• Projects committed in a much-
shortened time-frame.
• Problematic if system can not be
modularized.
• Not appropriate when technical
risks are high (heavy use of new
technology).

20. When the RAD development process
model is appropriate to use?
• If software requirements are well
understood and project time is
constrained.

21. Spiral development process model
• Process is represented as a spiral rather than as a sequence of
activities with backtracking.
• Each loop in the spiral model represents a phase in the
development process model.
• No fixed phases such as specification or design - loops in the spiral
are chosen depending on what is required.
• Risks are explicitly assessed and resolved throughout the process.
21

22. Limitations of the spiral development
process model
• It is difficult to convince
customers (particularly in contract
situations) that the model is
controllable.
• Risk assessment expertise is
required to succeed.
22

23. When the spiral development process
model is appropriate to use?
• Good for large and critical-
mission software projects.
• When the risk and costs
evaluation is important.
• Additional functionality can be
added at a later date.
• When requirements are unclear
and complex.

24. Reuse-oriented development process
model
• Software systems are integrated
from existing components or COTS
(Commercial-off-the-shelf) systems.
• Reuse is now the standard approach
for building many types of business
system.

25. The Rational unified development
process model (RUP)
• RUP is a generic process derived from the
work on the UML and associated process.
• Brings together aspects of the 3 generic
process models discussed previously.
• Normally described from 3 perspectives
A dynamic perspective that shows
phases over time;
A static perspective that shows process
activities;
A proactive perspective that suggests
good practice.
25

26. Phases in the rational unified
development process model
26

27. RUP good practice
• Develop software iteratively
Plan increments based on customer
priorities and deliver highest priority
increments first.
• Manage requirements
Explicitly document customer
requirements and keep track of changes
to these requirements.
• Use component-based architectures
Organize the system architecture as a
set of reusable components.
27

28. RUP good practice
• Visually model software
Use graphical UML models to present
static and dynamic views of the software.
• Verify software quality
Ensure that the software meets
organizational quality standards.
• Control changes to software
Manage software changes using a
change management system and
configuration management tools.
28