Software Engineering

Zheng Li（李征）
Jing Wan（万静）
Topic covered today

 Software Process Structure

 Process Models
 Agile Development
 Project
Part One : The Software Process

Chapter 3:
Software Process Structure
A Story

 You start a project, as a project leader

 You got 10 people to work on your project, you have a
one-year schedule plan
 Some programmers comes and leaves
 Some programmers with talent, some do not
 You have them work as a team. Most of the time, you
and they communicate via meeting and face to face
A Story

 You roughly plot the design

 You expect the programmers to work smartly, more
importantly, you believe your programmers understand
and remember your idea and hopefully they can
smartly transfer your idea into programs.
 You think you just need to do the coordinating work,
managing resources.
A Story-The Hard Time Comes

 When programmers begin to merge and integrate their

code.
▪ programmer A said "Oh! I don't know I need to write that part! when
did we have a deal?"
▪ programmer B complains to others "We have an agreement on the
interface and specification, when did you change that ?"
▪ programmer C complains " How come his model is not tested? how
can we do the integration testing?"
▪ programmer D complains "Why F's model can do different things
when called several times ?"
▪ programmer E is in charge of debugging and he complains "How
come programmer X can write such a lousy program that i cannot
even read?"
A Story-The Hard Time Comes

▪ programmer F complains "How come during integration, there are so

many bugs and isolate the bugs are difficult?"
▪ programmer G complains " how come the design is wrong and does
not work in the beginning ?"
▪ programmer H complains "How come the product manager keep
enforce us to change specification in the middle of development?"
Final Results

 A poor quality product is produced. Bug number is

beyond reasonable level
 Your product is difficult to maintain. Maintenance tasks
are left to rookie programmers because the original
developer knows the truth!
 Your project delayed
 Your project exceeds budge limits
 Customer is unhappy
 Programmers are sad and ask for transfering to other
teams
New Chance Comes

 Now, you are again in charge of another project.

 20 people again is under your supervision
 What will you do to avoid the mess of last project
The solutions:
 programmer A said "Oh!I don't know I need to write that
part! when did we have a deal?"
▪ You want programmers to write down their communications as
formal documents or in a software which can traced back to
every decisions and action items made along the process
 programmer B complains to others "We have an
agreement on the interface and specification, when did
you change that ?"
▪ A elite design team is formed(includes experienced
programmers, software architect, project managers) to plot the
design and module interface. Detailed descriptions should be
included in the document so that programmers can begin their
work simply by reading the documents. A formal meeting is
called to dispatch the work to programmers.
The solutions:
 programmer C complains " How come his model is not
tested?how can we do the integration testing?"
▪ You lay down a rule."Before integration testing, each
programmer should fully test their module. A test report should
be released by the programmer to show how much they have
tested their module."
 programmer D complains"Why F's model can do
different things when called several times ?"
▪ In the middle of development, a "code review meeting " is
initiated to have everyone review code. You want to make sure
every programmer does not strange things for their
programming convenience, such as using global variables
excessively.
The Solutions

 Programmer E is in charge of debugging and he

complains "How come programmer X can write such a
lousy program that I can not even read?"
▪ A "code quality assurance "team is formed. A rule of submitting
source code to CQA is laid down. A cod review meeting is called
in the middle of development.
 programmer F complains "How come during
integration, there are so many bugs and isolate the
bugs are difficult?"
▪ Introduce a better process to perform integration testing which
allows to isolate bugs from different modules.
The Solutions

 programmer G complains " how come the design is

wrong and does not work in the beginning ?"
▪ Introduce a design review meeting
▪ introduce a new position called software architects who is
capable of review design or write good design documents.
 programmer H complains "How come the product
manager keep enforce us to change specification in the
middle of development?"
▪ Introduce a strict specification change process after coding
begins.
▪ After coding begins, a specification change meeting is called to
evaluate the impact of a specification, requirement, and design
change.
The Final Answer

The root cause of these problems is

Software process
A Generic Process Model（通用过程模型）
 Framework activities
▪ communication
▪ planning
▪ modeling
▪ construction
▪ deployment

 Umbrella activities
▪ project tracking and control
▪ risk management
▪ quality assurance
▪ configuration management
▪ technical reviews

15
 Process Flow
describe how the framework activities and the actions and tasks that occur within each
framework activity are organized with respect to sequence and time

 Linear process
flow
 iterative
process flow
 evolutionary witrespect
process flow
 parallel
process flow

16
Defining A Framework Activity
What actions are appropriate for a framework activity, given the nature
of the problem to be solved, the characteristics of the people doing the
work, and the stakeholder who are sponsoring the project?
For a small software project requested by one person, the
communication activity might encompass one action
--phone conversation
▪ Make contact with stakeholder via telephone
▪ Discuss requirements and develop notes
▪ Organize notes into a brief written statement of requierments
▪ Email to stakeholder for review and approval

17
Identifying a Task Set

 A task set defines the actual work to be done to

accomplish the objectives of a software engineering
action.
▪ work tasks
▪ related work products
▪ quality assurance points
▪ project milestones

18
Process Patterns

 A process pattern
▪ describes a process-related problem that is
encountered during software engineering work,
▪ identifies the environment in which the problem has
been encountered, and
▪ suggests one or more proven solutions to the
problem.
 Stated in more general terms, a process pattern
provides you with a template [Amb98]—a consistent (
统一）method for describing problem solutions within
the context of the software process.

19
Process Pattern Types

 Stage patterns—defines a problem associated with a

framework activity for the process.
 Task patterns—defines a problem associated with a
software engineering action or work task and relevant
to successful software engineering practice
 Phase patterns—define the sequence of framework
activities that occur with the process, even when the
overall flow of activities is iterative in nature.

20
Part One : The Software Process

Chapter 4:
Process Models
Prescriptive Process Models

 Prescriptive process models advocate an orderly

approach to software engineering
▪ The waterfall model
▪ Incremental Process models
▪ Evolutional Process models
▪ Concurrent models

22
The Waterfall Model
Com m unic a t ion
proje c t init ia t ion Planning
re quire m e nt ga t he ring estimating Mode ling
scheduling
analysis Const r uc t ion
tracking
design De ploy m e nt
code
t est de liv e ry
s upport
f e e dba c k

• It can serves as a useful model in situation where requirements are fixed

and work is to proceed to completion in a linear manner.

• Real projects rarely follow the sequential flow

• Customers usually can't state all requirements explicitly
• A working version will not be availabe until late in the project time-span

23
The V-Model

24
Advantages of Waterfall Model
▪ The model suggests that software engineers should
work in a series of stages.
▪ Before completing each stage, they should perform
quality assurance (verification and validation).
▪ The waterfall model can be useful in helping
developers lay out what they need to do.
▪ The model postpone（推迟） the coding stage.
Limitations of Waterfall Model
▪ The main drawback of the waterfall model is the difficulty of
accommodating changes after the process is underway
▪ The assumption that all requirements have to be known at the
beginning in sufficient details lead to premature decisions
▪ The activities cannot be performed concurrently
▪ It is hard to locate the system faults in the early stages.
▪ For large projects, the users have to wait a long time for the
delivery of the system

Waterfall model is only appropriate when the

requirements are well-understood and changes
will be fairly limited during the design process.
The Incremental Model

increment # n
Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k

Incremental Process models deliv ery of

increment # 2 nt h increment

Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is Co n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment

Co m m u n i c a t i o n
Pla nning
M ode ling
analy s is Co n s t ru c t i o n
des ign c ode De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e dba c k
1st increment

project calendar t ime

The incremental model combines the elements’ linear and parallel process flows.
27
Evolutionary Models: Prototyping

Q u ick p l an
Quick •Good first step when
Com m unicat ion plan
communication customer has a legitimate(合
Mo d e li n g
Modeling
理） need, but is clueless
Q u ick d e sig n
Quick design about the details
•The prototype must be
thrown away.

Deployment
Deployment
De live r y
delivery
& Fe e dback& Const r uct ion
feedback Construction
of
of ot
pr prototype
ot ype

28
Evolutionary Models: The Spiral
planning
estimation
scheduling
•Prototyping + Waterfall
risk analysis •Risk-driven
•Large-scale systems and
communication software
modeling
analysis
design
start

deployment
construction
delivery code
feedback test

29
Evolutionary Models: Concurrent
none
•Defines a series of events that will
Modeling act ivit y
trigger transitions from state to state
Under
represents the state
of a software engineering
for each of the activities, actions or
development
activity or task
tasks.
•Especially good for client/server
A wait ing
changes applications
•Defines a network of activities
Under review instead of linear sequence of events
Under
revision

Baselined

Done

30
Still Other Process Models

 Component based development—the process to apply

when reuse is a development objective
 Formal methods—emphasizes the mathematical
specification of requirements
 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)
31
The Unified Process (UP)

Elaborat ion
elaboration

Incept ion
inception

const ruct ion

Release
t ransit ion
soft ware increment

product ion

32
UP Phases

UP Phases
Incept ion Elaborat ion Const ruct ion Transit ion Product ion

Workflows

Requirements

Analysis

Design

Implementation

Test

Support

Iterations #1 #2 #n-1 #n

33
UP Work Products
Incept ion phase

Elaborat ion phase

Vision document
Init ial use-case model
Init ial project glossary Const ruct ion phase
Use-case model
Init ial business case Supplement ary requirement s
Init ial risk assessment . including non-funct ional Transit ion phase
Design model
Project plan, Analy sis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Deliv ered soft ware increment
Int egrat ed soft ware
Business model, Descript ion. increment Bet a t est report s
if necessary . Execut able archit ect ural General user feedback
Test plan and procedure
One or more prot ot y pes prot ot y pe.
I nc e pt i o Test cases
n Preliminary design model Support document at ion
Rev ised risk list user manuals
Project plan including inst allat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual

34
Part One : The Software Process

Chapter 5:
Agile Development
The Manifesto(宣言) for Agile Software Development

 2001, Kent Beck and 16 noted software developers, writers,and consultants.

 That is, while there is value in the items on the right, we value the items on the
left more.

36
What is “Agility”?

 Effective (rapid and adaptive) response to change

 Effective communication among all stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in control of the work
performed
Yielding …
 Rapid, incremental delivery of software
 The 12 principles for achieving aility(p.64-65)

37
 Agility and the Cost of Change

 An agile process reduces the cost of chang because software is released in

increments and change can be better controlled within an increment.

38
An Agile Process

 Is driven by customer descriptions of what is required

(scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a heavy emphasis on
construction activities
 Delivers multiple ‘software increments’
 Adapts as changes occur

39
Extreme Programming (XP)
 The most widely used agile process, proposed by Kent Beck

40
Extreme Programming (XP)

 XP Planning
▪ Begins with the creation of “user stories”
▪ Agile team assesses each story and assigns a cost
▪ Stories are grouped to for a deliverable increment
▪ A commitment is made on delivery date
▪ After the first increment “project velocity（速度）” is
used to help define subsequent delivery dates for
other increments

41
Extreme Programming (XP)

XP Design

▪ Follows the KIS (keep it simple)principle

▪ Encourage the use of CRC cards (see Chapter 8)

▪ For difficult design problems, suggests the creation of

“spike solutions”—a design prototype

▪ Encourages “refactoring”—an iterative refinement of

the internal program design

42
Extreme Programming (XP)

XP Coding
▪ Recommends the construction of a unit test for a
store before coding commences
▪ Encourages “pair programming”

XP Testing
▪ All unit tests are executed daily
▪ “Acceptance tests”（验收测试） are defined by the
customer and excuted to assess customer visible
functionality

43
Scrum
Originally proposed by Schwaber and Beedle
Scrum—distinguishing features
▪ Development work is partitioned into “packets”
▪ Testing and documentation are on-going as the product is
constructed
▪ Work occurs in “sprints” and is derived from a “backlog”of
existing requirements
▪ Meetings are very short and sometimes conducted without
chairs
▪ “demos” are delivered to the customer with the time-box
allocated

44
Scrum

45
习题

 P38 3.3，3.4
 P78 5.2，5.11
 Most of Slides are from the slide set to accompany
Software Engineering: A Practitioner’s Approach, 8/e

by Roger S. Pressman and Bruce R. Maxim

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

For non-profit educational use only

Email:[email protected]
http://cist.buct.edu.cn/staff/zheng/

[email protected]