Chapter 1 The Product

Chapter 1
The Product
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach,
5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001
1
What is
Software?
Software is a set of items or objects
that form a “configuration” that
includes
• programs
• documents
• data ...
2
What is
Software?
❏ software is engineered
❏ software doesn’t wear out
❏ software is complex
❏ software is a ‘differentiator’
❏ software is like an ‘aging
factory’
3
Wear vs.
in
c
ra
te
Deterioration
re
a
d
u
s
e
e
dfa
to
ilu
s
id
re
ee
ffe
cts
F
ailu
re
ra
te
c
ha
ng
e
a
ctu
alc
urv
e
id
ea
liz
edc
urv
e
T
im
e
4
The Cost of Change
60-100x
1.5-6x
1x
Definition Development After release
5
Software
Applications
❏ system software
❏ realtime software
❏ business software
❏ engineering/scientific software
❏ embedded software
❏ PC software
❏ AI software
❏ WebApps (Web applications)
6
Software Poses Challenges
How do we ensure the quality of the software that
we produce?
How do we meet growing demand and still

maintain budget control?
How do we upgrade an aging "software plant?"
How do we avoid disastrous time delays?
How do we successfully institute new software

technologies?
7
Software Engineering: A Practitioner’s Approach,
6/e
Chapter 2
Process: A Generic View
8
A
L
a
Software Engineering
y
tools
er
e
methods
d
process model
T
a “quality” focus
e
c
h
n
9
A
Pr
o
Process framework
c
Framework activities
e
work tasks
ss
work products
Fr
milestones & deliverables
a
QA checkpoints
m
Umbrella Activities
e
w
or
10
Fr
a
m
❏ Communication
❏ Planning e
❏ Modelingw
➯ Analysis of requirements
➯ Design or
❏ Constructionk
A
➯ Code generation
➯ Testing
❏ Deployment cti
vit
ie
s
11
U
m
br
❏ Software project management
❏ Formal technical reviews
el
❏ Software quality assurance
la
❏ Software configuration management
A
❏ Work product preparation and production
ct
❏ Reusability management
❏ Measurement ivi
❏ Risk management ti
es
12
The Process Model:
Adaptability
❏ the framework activities will always be
applied on every project ... BUT
❏ the tasks (and degree of rigor) for each
activity will vary based on:
➯ the type of project
➯ characteristics of the project
➯ common sense judgment; concurrence of the
project team
13
T
h
e
❏ The CMMI defines each process area in terms of
“specific goals” and the “specific practices”

required to achieve these goals.
C
❏ Specific goals establish the characteristics that must
exist if the activities implied by a process area are to
be effective.
M
M
❏ Specific practices refine a goal into a set of process
related activities. I
14
Pr
o
c
❏ Process patterns define a set of activities, actions,
work tasks, work products and/or related behaviors
e
❏ A template is used to define a pattern
❏ Typical examples: ss
P
➯ Customer communication (a process activity)
➯ Analysis (an action)
a
➯ Requirements gathering (a process task)
tt
➯ Reviewing a work product (a process task)
e
➯ Design model (a work product)
rn
s
15
Pr
o
c
❏ The process should be assessed to ensure
that it meets a set of basic process criteria
es
that have been shown to be essential for a
s
successful software engineering .
As
❏ Many different assessment options are
available:
➯ SCAMPI se
➯ CBA IPI
➯ SPICE
ss
➯ ISO 9001:2000 m
e
nt
16
Assessment and Improvement
Software Process
identifies is examined by identifies capabilities

modifications to and risk of
Software Process
Assessment
Capability
Software Process leads to leads to
Determination
Improvement
motivates
17
Per
so
nal
❏ Recommends five framework activities:
➯ Planning
➯ Highlevel design Sof
tw
➯ Highlevel design review
➯ Development
➯ Postmortem ar
e
❏ stresses the need for each software engineer
Pro
to identify errors early and as important, to
understand the types of errors
ce
ss
(PS
18
Tea
m
Soft
❏ Each project is “launched” using a “script”
that defines the tasks to be accomplished
war
❏ Teams are selfdirected
e
❏ Measurement is encouraged
Pro
❏ Measures are analyzed with the intent of
ces
improving the team process
s
(TS
P)
19
Primary Goal of Any Software Process: High Qua
Remember:
High quality = project timeliness
Why?
Less rework!
20
T
h
e
Communication
Planning
W
a
project initiation
requirement gathering estimating Modeling
scheduling
analysis Construction
t
tracking
design Deployment
code
test delivery
support
e
f eedback
rf
al
l
M
o
21
The Incremental Model
increment #n
Communic at ion
Planning
Modeling
analys is C o 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 db ac k
delivery of
nt h increment
increment # 2
Communic at ion
Pl a n ni ng
Modeling
des ign c ode De p l o y m e n t
fe e dba c k
delivery of
increment # 1 2nd increment
Communic at ion
Planning
Modeling
des ign c ode
delivery of
De p l o y m e n t
fe e db a c k
1st increment
project calendar time
22
The RAD Model
Team # n
Mo d e lin g
business modeling
data modeling
process modeling
C o n st ru ct io n
component reuse
Team # 2 automatic code
Communication generation
testing
Modeling
business modeling
dat a modeling
process modeling
Planning
Construction Deployment
Team # 1 component reuse int egrat ion
aut omat ic code
generat ion delivery
Modeling t est ing feedback
business modeling
dat a modeling
process modeling
Construction
component reuse
aut omat ic code
generat ion
t est ing
60 - 90 days
23
Evolutionary Models: Prototyping
Quick plan
Quick
Communication plan
communication
Modeling
Modeling
Quick design
Quick design
Deployment
Deployment
Delivery
delivery & Construction
& Feedback Construction
feedback of
of prototype
prototype
24
Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery code
feedback test
25
Evolutionary Models: Concurrent
none
Modeling activity
represents the state

Under of a software engineering
activity or task
development
Awaiting
changes
Under review
Under
revision
Baselined
Done
26
Sti
ll
❏ Component based development—the process to
Ot
apply when reuse is a development objective
he
❏ Formal methods—emphasizes the mathematical
specification of requirements
r
❏ AOSD—provides a process and methodological
Pr
approach for defining, specifying, designing, and
constructing aspects o
c
❏ Unified Process—a “usecase driven, architecture
centric, iterative and incremental” software process
es
closely aligned with the Unified Modeling Language
(UML) s
M
o
27
The Unified Process (UP)
Elaboration
elaboration
Inception
inception
inception
construction
Release
transition
software increment
production
28
UP Phases
UP Phases
Inception Elaboration Construction Transition Production
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations #1 #2 #n-1 #n
29
UP Work Products
Inception phase
Elaboration phase
Vision document
Init ial use-case model
Init ial project glossary Construction phase
Use-case model
Init ial business case Supplement ary requirements
Init ial risk assessment . including non-funct ional Transition phase
Design model
Project plan, Analysis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Int egrated soft ware Delivered soft ware increment
Business model, Descript ion. increment Beta t est report s
if necessary. Execut able archit ect ural Test plan and procedure General user feedback
One or more prot ot ypes prot ot ype.
I nc ept i o Test cases
n Preliminary design model Support document at ion
Revised risk list user manuals
Project plan including installat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual
30
Chapter 4
Agile
Development

31
The Manifesto for
Agile Software Development
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
•Individuals and interactions over processes
and tools
•Working software over comprehensive
documentation
•Customer collaboration over contract
negotiation
•Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more.”
Kent Beck et al
32
W
h
at
❏ Effective (rapid and adaptive) response to
change
is
❏ Effective communication among all
stakeholders “
A
❏ Drawing the customer onto the team
gi
❏ Organizing a team so that it is in control of the
work performed
lit
Yielding …
y
❏ Rapid, incremental delivery of software
”
?
33
A
n
A
❏ Is driven by customer descriptions of what is
required (scenarios)
gi
❏ Recognizes that plans are shortlived
le
❏ Develops software iteratively with a heavy
Pr
emphasis on construction activities
o
❏ Delivers multiple ‘software increments’
❏ Adapts as changes occurc
e
ss
34
Extr
em
e
❏ The most widely used agile process,
originally proposed by Kent Beck
❏ XP Planning Pro
grauser stories”
➯ Begins with the creation of “
m
➯ Agile team assesses each story and assigns a cost
➯ Stories are grouped to for a deliverable increment
mi
➯ A commitment is made on delivery date
ng
➯ After the first increment “project velocity” is used to help
define subsequent delivery dates for other increments
(XP
)
35
Extr
em
❏ XP Design
➯ Follows the KIS principle e
Pro
➯ Encourage the use of CRC cards (see Chapter 8)
➯ For difficult design problems, suggests the creation of “spike solutions”—a design
prototype
gra
➯ Encourages “refactoring”—an iterative refinement of the internal program design
❏ XP Coding
m
➯ Recommends the construction of a unit test for a store before coding commences
mi
➯ Encourages “pair programming”
❏ XP Testing
ng
➯ All unit tests are executed daily
➯ “Acceptance tests” are defined by the customer and excuted to assess customer
visible functionality
(XP
)
36
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
37
Ad
ap
❏ Originally proposed by Jim Highsmith
tiv
❏ ASD — distinguishing features
➯ Missiondriven planninge
➯ Componentbased focus Sof
tw
➯ Uses “timeboxing” (See Chapter 24)
➯ Explicit consideration of risks
➯ Emphasizes collaborationar for requirements gathering
e
➯ Emphasizes “learning” throughout the process
De
vel
op
38
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
39
Dynamic Systems Development Method
❏ Promoted by the DSDM Consortium (www.dsdm.org)
❏ DSDM—distinguishing features
➯ Similar in most respects to XP and/or ASD
➯ Nine guiding principles
❏ Active user involvement is imperative.
❏ DSDM teams must be empowered to make decisions.
❏ The focus is on frequent delivery of products.
❏ Fitness for business purpose is the essential criterion for acceptance of deliverables.
❏ Iterative and incremental development is necessary to converge on an accurate
business solution.
❏ All changes during development are reversible.
❏ Requirements are baselined at a high level
❏ Testing is integrated throughout the lifecycle.
40
Dynamic Systems Development Method
DSDM Life Cycle (with permission of the DSDM consortium)
41
S
c
r
❏ Originally proposed by Schwaber and Beedle
❏ Scrum—distinguishing features
u packets”
➯ Development work is partitioned into “
m
➯ Testing and documentation are ongoing 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 timebox
allocated
42
C
r
y
❏ Proposed by Cockburn and Highsmith
s
❏ Crystal—distinguishing features
t
➯ Actually a family of process models that allow
“maneuverability” based on problem characteristics
a
➯ Facetoface communication is emphasized
➯ Suggests the use of “reflection workshops” to review the work
habits of the team l
43
A
g
il
❏ Originally proposed by Scott Ambler
e
❏ Suggests a set of agile modeling principles
➯ Model with a purpose
➯ Use multiple models M
➯ Travel light o
d
➯ Content is more important than representation
➯ Know the models and the tools you use to create them
➯ Adapt locally e
li
n
g
44
– Thanks
45

Chapter 1 The Product

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 1 The Product

Uploaded by

Copyright:

Available Formats

Chapter 1

Definition Development After release

How do we meet growing demand and still

How do we upgrade an aging "software plant?"

How do we avoid disastrous time delays?

How do we successfully institute new software

identifies is examined by identifies capabilities

project calendar time

represents the state

DSDM Life Cycle (with permission of the DSDM consortium)

You might also like