Assignment

on

All Process Models

Prepared for
A. K. M. Ahsanul Haque, Assistant Processor
CSE345.6; Information System Design & Software Engineering

Prepared by
Istiack Amin
ID: 2022100000030

Date: 13 March, 2024

Southeast University
Department of Computer Science and Enginerring
List of Contents
• Introduction
1. The Waterfall Model
2. The V-Model
3. The Incremental Model
4. The Prototyping Model
5. The Spiral Model
6. The Concurrent Model
7. Component-Based Development
8. The Formal Methods Model
9. Aspect-Oriented Software Development
10. The Unified Process
11. Personal Software Process
12. Team Software Process
13. The Agile Process
14. The XP Process
15. Industrial XP
16. Scum Process flow
17. Dynamic Systems Development Method

2
Introduction
Software process models aim to bring order to software development chaos,
but the nature of software work remains on the edge of chaos. Prescriptive
models offer structure, but adaptability is crucial in a constantly changing
environment. Nogueira et al. highlight this dynamic relationship between
order and chaos in software engineering. Prescriptive models prioritize
project consistency and orderliness, prescribing specific process elements
and workflows. However, the suitability of such models in a dynamic
software landscape is debated. Alternative approaches exist, each
emphasizing different aspects of framework activities and process flows,
reflecting the ongoing quest for balance between structure and adaptability
in software engineering.

1. The Waterfall Model:

In cases where requirements are clear and stable, work can progress in a
linear manner from communication to deployment. This scenario often
arises in adaptations to existing systems or in some new development
projects with well-defined requirements. The waterfall model advocates a
sequential approach to software development, starting with customer
requirements and progressing through planning, modeling, construction,
deployment, and ongoing support.

3
2. V-Model:
The V-Model, a variation of the waterfall model, illustrates the relationship
between quality assurance and software development activities. As the team
progresses down the left side of the V, requirements are refined into
technical solutions. Then, moving up the right side, the team conducts tests
to validate the earlier models. The V-Model offers a visual representation of
how verification and validation are integrated into the development process.
Among the problems that are sometimes encountered when the waterfall
model is applied are:
i. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so indirectly.
As a result, changes can cause confusion as the project team proceeds.
ii. It is often difficult for the customer to state all requirements explicitly. The
waterfall model requires this and has difficulty accommodating the natural
uncertainty that exists at the beginning of many projects.

4
iii. The customer must have patience. A working version of the program(s)
will not be available until late in the project time span. A major blunder, if
undetected until the working program is reviewed, can be disastrous.
Bradac (1994) found that the linear structure of the classic life cycle can lead
to blocking states in projects, where team members must wait for
dependent tasks to be completed. This waiting time can exceed productive
work time, particularly at the beginning and end of the process. In today's
fast-paced software environment, characterized by constant changes, the
waterfall model may not be suitable. However, it can still be useful in
situations with fixed requirements and a need for linear progression towards
completion.

3. Incremental Process Models:

There exist numerous scenarios where the initial software requirements are
adequately articulated, yet the complexity of the development endeavor
prohibits a strictly linear approach. Furthermore, there might be a significant
imperative to swiftly deliver a basic set of software functionalities to users,
followed by subsequent iterations for refinement and expansion. In such
instances, opting for a process model tailored for incremental software
development becomes advantageous.

5
The incremental model combines linear and parallel process flows, applied
progressively over time. Each stage produces software increments, with each
subsequent increment adding additional features or functionalities. For
instance, a word-processing software developed incrementally might deliver
basic functions initially, then add more advanced capabilities in subsequent
increments. The first increment often serves as a core product, with further
enhancements based on customer feedback and evaluation, repeating until
the final product is achieved.

EVOLUTIONARY PROCESS MODELS

Software development is dynamic, with evolving business needs and
changing product requirements. Straightforward linear paths to end
products often prove unrealistic due to these shifts. Tight market deadlines
necessitate introducing limited versions to meet competitive pressures. In
situations where core requirements are clear but extension details are
undefined, a process model explicitly designed for growth and change is
essential. Evolutionary models, characterized by iteration, enable the
development of progressively more comprehensive software versions.
Below, we introduce two common evolutionary process models.

4. The Prototyping Model:

When detailed requirements are lacking or uncertainties exist in software
development, the prototyping paradigm offers a valuable approach. It can
be employed independently or integrated into existing process models.
Prototyping aids in clarifying objectives and understanding what needs to be
built in ambiguous situations. The process involves initial communication to
define objectives and requirements, followed by quick design modeling and
prototype construction. Stakeholder feedback drives iterative refinement,
helping to align the prototype with stakeholder needs and enhance
understanding of project requirements.

6
Prototypes are ideally used to identify software requirements, often
leveraging existing program fragments or rapid generation tools. After
fulfilling this purpose, Brooks suggests treating the prototype as the initial
system to be discarded and rebuilt smarter. However, some prototypes
evolve into the actual system. While stakeholders and developers appreciate
the immediate feedback and building opportunities of prototyping, it can
pose challenges. Stakeholders may mistake prototype quality for final
product quality, leading to resistance to rebuilding for higher quality.
Additionally, developers may make implementation compromises for quick
results, potentially embedding inefficiencies into the final system. Clear
agreement among stakeholders at the outset regarding the prototype's role
is essential for effective prototyping in software engineering.

5. The Spiral Model:

The spiral model, originally proposed by Barry Boehm, combines the
iterative nature of prototyping with the systematic approach of the waterfall
model. It allows for rapid development of increasingly complete software
versions while managing risks. Boehm describes it as a risk-driven process
model generator for concurrent engineering of software-intensive systems,

7
featuring cyclic growth in system definition and implementation with
decreasing risk. The model involves iterative releases, starting with models
or prototypes and progressing to more complete versions. Each iteration is
divided into framework activities, following a clockwise path around the
spiral, with consideration of risks and milestone achievements at anchor
points.

The spiral model involves iterative cycles where each circuit may result in
different outputs, like product specifications or prototypes. Adjustments to
project plans are made based on customer feedback, with costs and
schedules being adapted accordingly. Unlike other models that end at
software delivery, the spiral model can be applied throughout the software's
lifecycle, from concept development to product enhancement. It offers a
realistic approach to large-scale system development, allowing for better
risk management through iterative evolution. However, convincing
customers of its controllability and requiring expertise in risk assessment are
challenges associated with this model.

8
featuring cyclic growth in system definition and implementation with
decreasing risk. The model involves iterative releases, starting with models
or prototypes and progressing to more complete versions. Each iteration is
divided into framework activities, following a clockwise path around the
spiral, with consideration of risks and milestone achievements at anchor
points.

6. The Concurrent Models:

The concurrent development model, also known as concurrent engineering,
allows software teams to incorporate iterative and concurrent elements
from various process models. For instance, in the spiral model, activities like
modeling can involve actions such as prototyping, analysis, and design.
Activities progress through different states concurrently, triggered by events
such as requirement changes or model inconsistencies. This approach
enables a flexible representation of software engineering activities, actions,
or tasks, allowing for concurrent progression through different stages of
development.

9
Concurrent modeling is applicable to all types of software development and
provides an accurate picture of the current state of a project. Rather than
con- fining 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 in the process network trigger transitions among the
states associated with each activity.

Evolutionary processes address the need for continual software adaptation

and tight time constraints but come with their own challenges. Concerns
include uncertainty in project planning, the risk of chaos from rapid
evolution, and potential compromises on quality for speed and flexibility.
While flexibility and speed are emphasized, striking a balance with high-
quality outcomes remains crucial for customer satisfaction.

SPECIALIZED PROCESS MODELS

Specialized process models take on many of the characteristics of one or
more of the traditional models presented in the preceding sections.
However, these models tend to be applied when a specialized or narrowly
defined software engineering approach is chosen.

7. Component-Based Development:
Commercial off-the-shelf (COTS) software components, developed by
vendors, offer targeted functionality with defined interfaces for integration.
The component-based development model, akin to the spiral model,
emphasizes an iterative approach. It involves identifying, evaluating, and
integrating prepackaged components into software architecture, followed by
comprehensive testing. This model promotes software reuse, reducing
development time and costs when component reuse is embraced within an
organization's culture.

10
Regardless of the technology that is used to create the components, the
component-based development model incorporates the following steps
(implemented using an evolutionary approach):
1. Available component-based products are researched and evaluated for
the application domain in question.
2. Component integration issues are considered.
3. A software architecture is designed to accommodate the components.
4. Components are integrated into the architecture.
5. Comprehensive testing is conducted to ensure proper functionality.

8. The Formal Methods Model:

The formal methods model involves activities leading to the formal
mathematical specification of computer software. It enables specification,
development, and verification using rigorous mathematical notation.
Cleanroom software engineering is a variation of this approach. Formal
methods help eliminate problems like ambiguity and inconsistency, allowing
for easier detection and correction through mathematical analysis,
particularly during design and development stages.
Although not a mainstream approach, the formal methods model offers the
promise of defect-free software. Yet, concern about its applicability in a
business environment has been voiced:
• The development of formal models 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.
Despite these concerns, the formal methods approach has gained traction
among developers tasked with building safety-critical software, such as
avionics or medical device developers, and those facing significant financial
consequences from software errors.
11
9. Aspect-Oriented Software Development:
Regardless of the chosen software process, complex software builders
model localized features and functions as components, constructed within a
system architecture. As systems grow more sophisticated, certain
concerns—such as security and fault tolerance—span the entire architecture.
These crosscutting concerns, affecting multiple system functions and
features, are addressed by aspectual requirements. Aspect-oriented
software development (AOSD), also known as aspect-oriented programming
(AOP) or aspect-oriented component engineering (AOCE), offers a
methodological approach to defining, specifying, and designing aspects,
addressing crosscutting concerns beyond traditional programming
paradigms.
An aspect-oriented process is still evolving but is expected to blend
characteristics of evolutionary and concurrent models. Evolutionary models
suit aspect identification and construction, while concurrent development's
parallel nature accommodates the independent engineering of aspects and
their impact on software components. Asynchronous communication
between aspect engineering and component construction activities is crucial.
For further details on aspect-oriented software development, refer to
dedicated books such as [Ras11], [Saf08], [Cla05], [Fil05], [Jac04], and
[Gra03].

10. The Unified Process:

In their influential book on the Unified Process (UP), Jacobson, Booch, and
Rumbaugh underscore the necessity for a software development approach
that is use case driven, architecture-centric, iterative, and incremental. They
highlight the growing complexity of software systems, driven by advancing
computer capabilities and increasing user expectations, fueled further by the
widespread use of the Internet for information exchange. This demand for
more sophisticated software reflects an ongoing quest for improvement, yet
simultaneously adds to the complexity of software projects.
12
The Unified Process aims to leverage the strengths of traditional software
process models while integrating agile principles. It places emphasis on
effective customer communication, streamlined use case descriptions, and
robust software architecture. By promoting an iterative and incremental
approach, the Unified Process fosters adaptability and evolution, crucial for
modern software development endeavors.
In the early 1990s, James Rumbaugh, Grady Booch, and Ivar Jacobson
collaborated on a "unified method" to merge their individual object-oriented
analysis and design techniques, incorporating insights from other experts.
This effort resulted in UML (Unified Modeling Language), established as an
industry standard for object-oriented software development by 1997.
Throughout Part 2 of the book, UML is used for both requirements and
design models. An introductory tutorial on basic UML notation and rules is
provided in Appendix 1, while comprehensive study materials are available in
dedicated textbooks listed therein.

The inception phase of the UP involves customer communication and

planning to identify business requirements, propose a rough system
architecture, and develop an iterative project plan. Preliminary use cases
describe fundamental business requirements, while architecture outlines
major subsystems and features.
13
Planning determines resources, assesses risks, and establishes a project
schedule.
During the elaboration phase, communication and modeling activities refine
preliminary use cases and expand architectural representation into five
views: use case, analysis, design, implementation, and deployment models.
Elaboration may create an "executable architectural baseline" to
demonstrate architecture viability. The plan is reviewed to ensure scope,
risks, and delivery dates remain feasible, with adjustments made as needed.
The construction phase of the UP involves developing or acquiring software
components based on the architectural model. Analysis and design models
from the elaboration phase are finalized, and all required features are
implemented in source code. Unit tests are conducted, and integration
activities are performed, with acceptance tests executed before proceeding
to the next phase.
During the transition phase, software is given to end users for beta testing,
with feedback used to address defects and necessary changes. Support
information, such as user manuals and installation procedures, is also
prepared. At the end of this phase, the software becomes a usable release.
The production phase involves ongoing monitoring of software use,
providing support for the operating environment, and evaluating defect
reports and change requests. Work on the next software increment may
overlap with these phases, resulting in staggered concurrency. Throughout
the UP phases, a distributed software engineering workflow guides tasks
and work product production, tailored to meet project needs.

14
11. Personal Software Process:
Every developer has a process, even if it's disorganized or inconsistent. The
Personal Software Process (PSP), proposed by Watts Humphrey, aims to
improve personal software development by emphasizing measurement and
individual responsibility. It consists of five key activities:

1. Planning: Estimating resources, identifying tasks, and creating a project

schedule.
2. High-level design: Developing component specifications and prototypes.
3. High-level design review: Using formal methods to verify the design and
maintain metrics.
4. Development: Refining designs, coding, testing, and maintaining metrics.
5. Postmortem: Analyzing collected data to improve process effectiveness.

PSP emphasizes early error identification and self-assessment, leading to

improved productivity and software quality. However, its adoption faces
challenges due to its intellectual rigor, required commitment, lengthy
training, and cultural resistance in the software industry. Despite these
challenges, PSP can be effective at a personal level, offering valuable process
improvement concepts.

12. Team Software Process:

Watts Humphrey expanded on the principles of the Personal Software
Process (PSP) and introduced the Team Software Process (TSP) to address
collaborative software projects. TSP aims to create a self-directed project
team capable of producing high-quality software. Humphrey [Hum981
defines the following objectives for TSP:
• Build self-directed teams that plan and track their work, establish goals,
and own their processes and plans. These can be pure software teams or
integrated product teams (IPTs) of 3 to about 20 engineers.

15
• Show managers how to coach and motivate their teams and how to help
them sustain peak performance.
• Accelerate software process improvement by making CMM level 5
behavior normal and expected.
• Provide improvement guidance to high-maturity organizations.
• Facilitate university teaching of industrial-grade team skills.

A self-directed team in TSP shares common goals, assigns roles, tracks

project data, defines processes and standards, manages risks, and monitors
project status. TSP involves framework activities like project launch, design,
implementation, testing, and postmortem, each aimed at disciplined
software development and process improvement. TSP employs scripts,
forms, and standards to guide team activities, fostering self-direction and
continuous improvement through measurement and analysis of metrics.
Like PSP, TSP requires full team commitment and thorough training for
effective implementation.

AGILITY AND THE COST OF CHANGE

In software development, it's widely understood that the cost of making
changes increases significantly as a project progresses. Early on, when
requirements are being gathered, accommodating changes is relatively easy
and inexpensive. However, as the project advances, particularly during
validation testing, the cost and effort required for making changes escalate
rapidly. Major functional changes at this stage may necessitate architectural
modifications, development of new components, and extensive testing to
ensure seamless integration, all of which significantly increase costs and
time constraints.

16
13. The Agile Process:
Any agile software process is characterized in a manner that addresses a
number of key assumptions (Fow021 about the majority of software
projects:
1. It is difficult to predict in advance which software requirements will per-
sist and which will change. It is equally difficult to predict how customer
priorities will change as the project proceeds.
2. For many types of software, design and construction are interleaved. That
is, both activities should be performed in tandem so that design models are
proven as they are created. It is difficult to predict how much design is
necessary before construction is used to prove the design.
3. Analysis, design, construction, and testing are not as predictable (from a
planning point of view) as we might like.
To manage unpredictability, an agile software process must prioritize
adaptability. This adaptability is achieved through incremental adjustments,
facilitated by regular customer feedback. By delivering software increments
in short cycles, the process ensures that adaptations align with evolving
project needs. This iterative approach allows customers to evaluate each
increment, provide feedback, and influence further adaptations to meet their
requirements.

17
Agility Principles:
The Agile Alliance (see [Agi031, (Fow01]) defines 12 agility principles for
those who want to achieve agility:
1. Our highest priority is to satisfy the customer through early and continu-
ous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile pro-
cesses harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment
and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, devel-
opers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances
agility.
10. Simplicity-the art of maximizing the amount of work not done is
essential.
11. The best architectures, requirements, and designs emerge from self-
organizing teams.
12. At regular intervals, the team reflects on how to become more effective,
then tunes and adjusts its behavior accordingly.

Not every agile process model applies these 12 principles with equal weight,
and some models choose to ignore (or at least downplay) the importance of
one or more of the principles. However, the principles define an agile spirit
that is maintained in each of the process models presented in this chapter.
18
EXTREME PROGRAMMING
In order to illustrate an agile process in a bit more detail, we'll provide you
with an overview of Extreme Programming (XP), the most widely used
approach to agile software development. Although early work on the ideas
and methods as- sociated with XP occurred during the late 1980s, the
seminal work on the subject has been written by Kent Beck IBec04al. A
variant of XP, called Industrial XP (IXP), refines XP and targets the agile
process specifically for use within large organizations.

14. The XP Process:

Extreme Programming uses an object-oriented approach (Appendix 2) as its
pre- ferred development paradigm and encompasses a set of rules and
practices that occur within the context of four framework activities: planning,
design, coding, and testing. Figure 5.2 illustrates the XP process and notes
some of the key ideas and tasks that are associated with each framework
activity. Key XP activities are summarized in the paragraphs that follow.
Planning: Planning in Extreme Programming (XP) begins with listening to
the customer's requirements,

19
resulting in the creation of "stories" that describe the desired features and
functionality of the software. Each story, prioritized by the customer, is
assessed by the XP team in terms of development weeks required. If a story
is estimated to take more than three weeks, it's split into smaller ones.
Customers and developers collaborate to group stories for the next release,
deciding on delivery dates and other project details. Stories can be added,
modified, or eliminated at any time.
After delivering the first project release, the XP team calculates project
velocity, representing the number of customer stories implemented. This
velocity helps estimate delivery dates for subsequent releases and ensures
no overcommitment across the project. As development progresses, the
customer can adjust stories, and the team adapts its plans accordingly.

Design: XP design adheres to the "Keep It Simple" (KIS) principle, favoring

simplicity over complexity and providing only the necessary implementation
guidance for each story. CRC cards are used to organize object-oriented
classes relevant to the current software increment, with design work limited
to their creation. When facing a difficult design problem, XP suggests
creating a spike solution—a quick prototype to mitigate risks and validate
estimates.
Refactoring, a core XP practice, involves modifying code to improve internal
structure without altering external behavior, minimizing the risk of
introducing bugs. Design in XP is transient, continually modified during
construction, with refactoring ensuring small, incremental design changes
for improved code quality. This iterative approach integrates design
throughout coding, allowing the team to refine the design based on
construction activities.

Coding: During coding in XP, the team starts by creating unit tests for each
story in the current release,

20
ensuring focused implementation based on the tests. Pair programming, a
central practice in XP, involves two developers working together at one
workstation, facilitating real-time problem-solving and quality assurance.
One focuses on coding details while the other ensures adherence to
standards and test validation.

As pair programmers work, their code is integrated regularly, either by an

integration team or themselves, following a continuous integration strategy.
This approach prevents compatibility issues and provides early error
detection through continuous testing.

Testing: Testing in XP emphasizes automated unit tests to enable easy and

repeated execution, supporting a regression testing approach with frequent
code modifications. These unit tests are organized into a universal testing
suite, facilitating daily integration and validation testing to monitor progress
and detect issues early.

XP acceptance tests, specified by the customer, focus on system features

visible to the customer and are derived from implemented user stories
within a software release.

15. Industrial XP:

Industrial Extreme Programming (IXP) is an evolution of XP, maintaining its
customer-centric, minimalist approach while enhancing management
involvement, customer engagement, and technical practices. IXP introduces
six new practices:

1. Readiness assessment ensures all project members are aligned, equipped,

and skilled.
2. Project community ensures the right people with the right skills are
involved.
21
3. Project chartering evaluates the project's alignment with organizational
goals.
4. Test-driven management sets measurable progress indicators.
5. Retrospectives review lessons learned after software increments.
6. Continuous learning fosters ongoing skill enhancement.

IXP adapts existing XP practices and redefines roles to suit the needs of
larger projects in large organizations. Visit http://industrialxp.org for more
details.

16. Scrum Process Flow:

Scrum, originating from rugby terminology, is an agile development method

created by Jeff Sutherland in the early 1990s, further developed by Schwaber
and Beedle. It aligns with agile principles and involves framework activities
like requirements, analysis, design, evolution, and delivery, each executed
within time-bound sprints.

22
Key components of Scrum include:
- Backlog: Prioritized list of project requirements or features.
- Sprints: Time-boxed work units aimed at fulfilling backlog items without
introducing changes.
- Daily Scrum meetings: Brief sessions to discuss progress, obstacles, and
plans.
- Demos: Presenting implemented functionality to the customer for
evaluation.
Scrum embraces chaos by acknowledging uncertainty and provides process
patterns for effective team collaboration and adaptation. For a deeper dive,
refer to Beedle et al.'s comprehensive discussion on Scrum process patterns.

17. Dynamic Systems Development Method:

The Dynamic Systems Development Method (DSDM) is an agile approach
aimed at meeting tight time constraints through incremental prototyping
within a controlled project environment. It operates on the principle that
80% of an application can be delivered in 20% of the time required for the
complete application.

DSDM follows an iterative process, adhering to the 80% rule in each

iteration, focusing on delivering enough functionality to move to the next
increment. The DSDM Consortium oversees the method, defining a lifecycle
starting with feasibility and business studies, followed by three iterative
cycles: functional model iteration, design and build iteration, and
implementation.

These cycles involve producing prototypes, revisiting and refining them, and
placing the latest increment into the operational environment. DSDM can be
complemented with Extreme Programming (XP) to enhance the process with
additional practices for building software increments.

23