CS435: Introduction to Software Engineering

Dr. M. Zhu

 Process Models
Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

Software Engineering 9/e

By Ian Sommerville

Chapter 2 1

These slides are designed and adapted from slides provided by Software Engineering: A Practitioner’s Approach, 7/e
(McGraw-Hill 2009) by Roger Pressman and Software Engineering 9/e Addison Wesley 2011 by Ian Sommerville
 Social Learning
Process
• Software is embodied knowledge that is initially dispersed,
tacit and incomplete.

• In order to convert knowledge into software, dialogues are

needed between users and designers, between designers and
tools to bring knowledge into software.

• Software development is essentially an iterative social

learning process, and the outcome is “software capital”.
2
 What: Go through a series of predictable steps--- a road map that helps you
create a timely, high-quality results.
 Who: Software engineers and their managers, clients also. People adapt the
process to their needs and follow it.
 Why: Provides stability, control, and organization to an activity that can if left
uncontrolled, become quite chaotic. However, modern software engineering
approaches must be agile and demand ONLY those activities, controls and
work products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the software that you
are building. One process might be good for aircraft avionic system, while an
entirely different process would be used for website creation.
 How to ensure right: A number of software process assessment mechanisms
that enable us to determine the maturity of the software process. However, the
quality, timeliness and long-term viability of the software are the best
indicators of the efficacy of the process you use.

What / who / why is

Process Models? 3
 Definition of Software
Process
• A framework for the activities, actions, and tasks that
are required to build high-quality software.

• SP defines the approach that is taken as software is

engineered.

• Is not equal to software engineering, which also

encompasses technologies that populate the process–
technical methods and automated tools.
4
A Generic Process
Model 5
 As we discussed before, a generic process
framework for software engineering defines five
framework activities-communication, planning,
modeling, construction, and deployment.
 In addition, a set of umbrella activities- project
tracking and control, risk management, quality
assurance, configuration management, technical
reviews, and others are applied throughout the
process.
 Next question is: how the framework activities and
the actions and tasks that occur within each
A Generic Process
activity are organized with respect to sequence
and time? See the process flow for answer.
Model 6
Process Flow

7
 Linear process flow executes each of the five
activities in sequence.
 An iterative process flow repeats one or more of
the activities before proceeding to the next.
 An evolutionary process flow executes the
activities in a circular manner. Each circuit leads
to a more complete version of the software.
 A parallel process flow executes one or more
activities in parallel with other activities
( modeling for one aspect of the software in
parallel with construction of another aspect of
the software.

Process Flow 8
 The
Waterfall
Model
It is the oldest paradigm for SE. When requirements are well
defined and reasonably stable, it leads to a linear fashion.
(problems: 1. rarely linear, iteration needed. 2. hard to state all requirements explicitly.
Blocking state. 3. code will not be released until very late.)

The classic life cycle suggests a systematic, sequential approach

9
to software development.
10
11
When should I use Waterfall model

12
 A variation of waterfall model
depicts the relationship of
The V-Model
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.

13
14
15
16
The
Incremental
Model

17
 The Incremental
• Model
When initial requirements are reasonably well defined,
but the overall scope of the development effort precludes
a purely linear process. A compelling need to expand a
limited set of new functions to a later system release.
• It combines elements of linear and parallel process flows.
Each linear sequence produces deliverable increments of
the software.
• 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. 18
19
20
21
22
23
Rapid Application
Development

24
RAD model is Rapid Application Development model .

• Type of incremental model

• Components or functions are developed in parallel as if they
were mini projects.
• Developments are time boxed, delivered and then assembled into
a working prototype
• Quickly give the customer something to see and use and to
provide feedback regarding the delivery and their requirements.

25
Phases in RAD model

26
Advantages of RAD model

27
Disadvantages of RAD model

28
When should I use RAD model

29
 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 are introduced, namely Prototyping and Spiral models.30
 Evolutionary Models:
Prototyping
• 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.
• 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. 31
Evolutionary Models:
Prototyping
Quick
plan
communication

Modeling
Quick design

Deployment Construction
delivery & of prototype
feedback Construction
of prototype

32
33
34
 Evolutionary Models: The
• Spiral
It couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall
model and 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 for ensuring stakeholder commitment to feasible and mutually satisfactory system solutions.
• 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 adjusted by project manager.
• 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.
• However, it may be difficult to convince customers that it is controllable as it demands considerable risk
assessment expertise. 35
Evolutionary Models: The
Spiral

36
 Three Concerns on
Evolutionary Processes
• First concern is that prototyping poses a problem to project planning because of
the uncertain number of cycles required to construct the product.
• Second, it does not establish the maximum speed of the evolution. If the
evolution occur too fast, without a period of relaxation, it is certain that the
process will fall into chaos. On the other hand if the speed is too slow then
productivity could be affected.
• Third, software processes should be focused on flexibility and extensibility
rather than on high quality. We should prioritize the speed of the development
over zero defects. Extending the development in order to reach high quality
could result in a late delivery of the product when the opportunity niche has
disappeared.
37
38
39
40
41
• WIN-WIN
• For obtaining the project requirements, customer communication is
very important and essential in the spiral model, the WIN-WIN
model also suggests and supports well and proper communication
with the customer.
• In actual practice, the process of negotiation which simply means to
compromise has to be faced by the customers and developers.
When both sides agree, only then successful negotiation occurs.
• This is called the WIN-WIN situation a given deadline and
achievable budgets.

42
• Customer’s win means –
• Obtaining the system that fulfill most of the requirements of
customers.
• Developer’s win means –
• Getting the work done by fulfilling the realistic
requirements of customers in

43
These slides are designed to accompany Software Engineering:
A Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides
copyright 2009 by Roger Pressman.
Win Win spiral Model

• At the beginning of each pass of the spiral, the negotiation

activities are carried out in a WIN-WIN spiral model.
• Various activities that can be carried out in a WIN-WIN spiral
model are shown in the following diagram 44
Boehm’s WINWIN spiral model defines a set of
negotiation activities at the beginning of each pass around
the spiral. Rather than a single customer communication
activity, the following activities are defined:
1. Identification of the system or subsystem’s key
“stakeholders.”
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to
reconcile them into a set of win-win conditions for all
concerned (including the software project team).
Successful completion of these initial steps achieves a
win-win result, which becomes the key criterion for
proceeding to software and system definition.

45
• Identification of ‘stakeholders’.
• Determination of stakeholders to make great efforts to achieve or obtain a win condition.
• Negotiations of stakeholders struggling vigorously for win condition. Software project team
conciliate for a win-win result with concern. Then determine next level objectives, constraints,
and alternatives.
• Evaluation of the process and product and then analyzing and resolving or reducing the risks to
make it easy.
• Defining the next level of product and process for proper working.
• Validation of process and product definitions is must.
• Reviewing of the product and giving the necessary and important comments on it.

46
47
Concurrent Model

48
 Still Other
Process
reuse Models
• Component based development—the process to apply when
is a development objective ( like spiral model)
• Formal methods—emphasizes the mathematical
specification of requirements ( easy to discover and
eliminate ambiguity, incompleteness and inconsistency)
• Aspect Oriented software development (AOSD)—provides a
process and methodological approach for defining,
specifying, designing, and constructing aspects
• Unified Process—a “use-case driven, architecture-centric,
iterative and incremental” software process closely aligned
with the Unified Modeling Language (UML) to model and 49
develop object-oriented system iteratively and incrementally.
The Unified Process
(UP)
elaboration

inception

50
UP
Phases

51
UP Work
Products

52
 Personal Software Process
(PSP)

• Planning. This activity isolates requirements and develops both size and resource
estimates. In addition, a defect estimate (the number of defects projected for the
work) is made. All metrics are recorded on worksheets or templates. Finally,
development tasks are identified and a project schedule is created.
• High-level design. External specifications for each component to be constructed
are developed and a component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
• High-level design review. Formal verification methods (Chapter 21) are applied to
uncover errors in the design. Metrics are maintained for all important tasks and
work results.
• Development. The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics are maintained for all important
tasks and work results.
• Postmortem. Using the measures and metrics collected (this is a substantial
amount of data that should be analyzed statistically), the effectiveness of the process
is determined. Measures and metrics should provide guidance for modifying the
process to improve its effectiveness.

53
 Team Software Process
(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 (IPT) of three to about 20 engineers.
 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.
 The Capability Maturity Model (CMM), a measure of the effectiveness of a
software process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity
organizations.
 Facilitate university teaching of industrial-grade team
skills.
54
 What is
“Agility”?

• Effective (rapid and adaptive) response to change (team members, new technology,
requirements)
• Effective communication in structure and attitudes among all team members,
technological and business people, software engineers and managers 。
• Drawing the customer into the team. Eliminate “us and them” attitude. Planning in
an uncertain world has its limits and plan must be flexible.
• Organizing a team so that it is in control of the work performed
• Eliminate all but the most essential work products and keep them lean.
• Emphasize an incremental delivery strategy as opposed to intermediate products
that gets working software to the customer as rapidly as feasible.

55
 What is
“Agility”?

Yielding …
• Rapid, incremental delivery of software
• The development guidelines stress delivery over analysis
and design although these activates are not discouraged,
and active and continuous communication between
developers and customers.

56
Why and What Steps
are“Agility” important?
• Why? The modern business environment is fast-paced and
ever-changing. It represents a reasonable alternative to
conventional software engineering for certain classes of
software projects. It has been demonstrated to deliver
successful systems quickly.
• What? May be termed as “software engineering lite” The basic
activities- communication, planning, modeling, construction
and deployment remain. But they morph into a minimal task set
that push the team toward construction and delivery sooner.
• The only really important work product is an operational
“software increment” that is delivered.

57
Agility and the Cost
of Change

58
 An Agile
Process
• Is driven by customer descriptions of what is required (scenarios). Some
assumptions:
• Recognizes that plans are short-lived (some requirements will persist, some will change.
Customer priorities will change)
• Develops software iteratively with a heavy emphasis on construction
activities (design and construction are interleaved, hard to say how much design is necessary before
construction. Design models are proven as they are created. )
• Analysis, design, construction and testing are not predictable.

• Thus has to Adapt as changes occur due to unpredictability

• Delivers multiple ‘software increments’, deliver an operational
prototype or portion of an OS to collect customer feedback for
adaption.
59
 Agility Principles -
I
1. Our highest priority is to satisfy the customer through early
and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development.
Agile processes 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.

60
 Agility Principles -
II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The
sponsors, developers, 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.

61
 Human Factors
• the process molds to the needs of the people and
team, not the other way around
• key traits must exist among the people on an agile
team and the team itself:
• Competence. ( talent, skills, knowledge)
• Common focus. ( deliver a working software increment )
• Collaboration. ( peers and stakeholders)
• Decision-making ability. ( freedom to control its own destiny)
• Fuzzy problem-solving ability.(ambiguity and constant changes,
today problem may not be tomorrow’s problem)
• Mutual trust and respect.
• Self-organization. ( themselves for the work done, process for
its local environment, the work schedule)
Agile Testing Methods:
•Extreme Programming(XP)
•Scrum
•Crystal

63
 Extreme
Programming (XP)
• The most widely used agile process, originally proposed by Kent Beck in 2004. It
uses an object-oriented approach.
• XP Planning
• Begins with the listening, leads to creation of “user stories” that describes required output,
features, and functionality. Customer assigns a value(i.e., a priority) to each story.
• Agile team assesses each story and assigns a cost (development weeks. If more than 3 weeks,
customer asked to split into smaller stories)
• Working together, stories are grouped for a deliverable increment next release.
• A commitment (stories to be included, delivery date and other project matters) is made.
Three ways: 1. Either all stories will be implemented in a few weeks, 2. high priority stories first, or
3. the riskiest stories will be implemented first.
• After the first increment “project velocity”, namely number of stories implemented
during the first release is used to help define subsequent delivery dates for other
increments. Customers can add stories, delete existing stories, change values of an
existing story, split stories as development work proceeds.

64
 Extreme Programming
(XP)
• XP Design ( occurs both before and after coding as refactoring is encouraged)
• Follows the KIS principle (keep it simple) Nothing more nothing less than the story.
• Encourage the use of CRC (class-responsibility-collaborator) cards in an object-oriented context. The
only design work product of XP. They identify and organize the classes that are relevant to the current
software increment. (see Chapter 8)
• For difficult design problems, suggests the creation of “spike solutions”—a design prototype for that
portion is implemented and evaluated.
• Encourages “refactoring”—an iterative refinement of the internal program design. Does not alter the
external behavior yet improve the internal structure. Minimize chances of bugs. More efficient, easy to
read.
• XP Coding
• Recommends the construction of a unit test for a story before coding commences. So implementer can
focus on what must be implemented to pass the test.
• Encourages “pair programming”. Two people work together at one workstation. Real time problem
solving, real time review for quality assurance. Take slightly different roles.
• XP Testing
• All unit tests are executed daily and ideally should be automated. Regression tests are conducted to test
current and previous components.
• “Acceptance tests” are defined by the customer and executed to assess customer visible functionality
 Extreme Programming
(XP)
spike solutions
simple design
prototypes
CRC cards
user stories
values
acceptance test criteria
iteration plan

refactoring

pair
programming

Release
software increment unit test
project velocity computed continuous integration

acceptance testing
66
The XP Debate
 Requirements volatility: customer is an active member of XP team, changes to
requirements are requested informally and frequently.
 Conflicting customer needs: different customers' needs need to be assimilated.
Different vision or beyond their authority.
 Requirements are expressed informally: Use stories and acceptance tests are
the only explicit manifestation of requirements. Formal models may avoid
inconsistencies and errors before the system is built. Proponents said changing
nature makes such models obsolete as soon as they are developed.
 Lack of formal design: XP deemphasizes the need for architectural design.
Complex systems need overall structure to exhibit quality and maintainability.
Proponents said incremental nature limits complexity as simplicity is a core
value.

67
68
 Adaptive Software
Development
adaptive cycle planning Requirements gathering
uses mission statement J AD
project constraints mini-specs
basic requirements
time-boxed release plan

Release
software increment
adjustments for subsequent cycles
components implemented/ tested
focus groups for feedback
formal technical reviews
postmortems
69
70
71
72
73
74
75
76