Software Engineering Process Models

1
Software Engineering Process Models
In this course we will have a project
with Product requirements A defined
development process A team of 3-4 developers We
will use the Unified Modeling Language (UML) to
describe our product specifications and
design Today we will discuss some standard
process models
2
Software Engineering Phases
3
Developing a program / system
How do you develop a program / system from
scratch? For example --what did you do in your
first computing class? --what do you do
differently now? --what good / bad practices
have you come into contact with in your co-op
jobs? --what are differences for small / large
projects?
4
Capability Maturity Model

• CMM capability maturity model--defines level of
  the development process itself
• 1. Initial ad hoc
• 2. Repeatable basic project management
  processes in place
• 3. Defined documented process integrated into
  an organization-wide software process
• 4. Managed detailed measures are collected
• Optimizing--desired level Continuous process
  improvement from quantitative feedback
• Question what software process models have you
  used? How large / complex was the project? What
  level did the associated process represent?

5
Software Process Model
Software Process Model --A development
strategy that encompasses the process, methods,
and tools --Specific model is chosen based
upon the project/application, the methods/tools
to be used, resources available, and the
deliverables required basic model problem?develo
p?integrate each step is carried out recursively
until an appropriate level of detail is achieved
6
Process Model Types
Process Model Types Prescriptive Model
includes a specific set of tasks, along with a
workflow for these tasks and definite milestones
and outcomes for each task end result is the
desired product "Agile" Model tends to be
simpler than prescriptive models emphasis is on
incremental development, customer satisfaction,
and minimal process overhead "Mathematical" Form
al Method Model stresses mathematical rigor and
formal proofs that product is meeting
carefully-defined goals
7
Some Common Prescriptive Models
Some common models used in practice Prescriptive
"Basic" Linear Sequential
Model Prototyping Model "Evolutionary"
(product evolves over time) Incremental
Model Component-based Model Formal
Methods Z-based methods Agile Extreme
Programming
8
Waterfall Model
Linear Sequential Model (waterfall model)
Sequential approach from system level through
analysis, design, coding, testing,
support--oldest and most widely used paradigm
Advantages --better than nothing --can be
appropriate for for small, well-understood
projects Disadvantages --Real projects rarely
follow a sequential flow --Requirements usually
not fully known. --Working version not available
until late in project.
9
Prototyping Model
Prototyping Model customer defines set of
general objectives no details on input,
processing, output requirements may be unsure of
algorithm efficiency, adaptability, OS,
human/machine issues Advantages --Focuses on
what is visible to customer --Quick design leads
to a prototype --Prototype evaluated by the
customer who can refine requirements --Ideal
mechanism for identifying and refining SW
requirements Disadvantages --Customer sees
something that appears to work and wants
it. --Less than ideal choices move from prototype
to product SW
Prototyping A--gtD--gtC--gtT--gtM (Aanalysis,
Ddesign, Ccoding, Ttesting, Mmaintenance)
10
Evolutionary Models
11
Incremental Model
Incremental Model Elements of linear sequential
(applied repetitively) with prototyping. As
result of use, a plan is developed for next
increment. Advantages Unlike prototyping, an
operational product is delivered at each
increment. Disadvantages Variable staffing at
each increment (task dependent). Risk analysis
must be done at each increment.
Incremental A--gtD--gtC--gtT--gtM--gtA--gtD--gtC--gtT--gt
--gtM (Aanalysis, Ddesign, Ccoding,
Ttesting, Mmaintenance)
12
Component Based Development
Component Based Development emphasizes the
creation of classes that encapsulate data and the
algorithms to manipulate the data. Reusability.
Evolutionary and iterative. But composes
applications from prepackaged SW components
(classes) Process steps --candidate class is
identified --library is searched for existing
class --if none exists, then one engineered
using object-oriented methods. Advantages
Faster development and lower costs. Disadvantages
requires expertise in this type of development
Component based A--gtD--gtLibrary--gtIntegrate--
gtT--gtM C (Aanalysis, Ddesign,
Ccoding, Ttesting, Mmaintenance)
13
Process Models--Comparison
Graphical comparison of basic and evolutionary
models

• Basic waterfall model A--gtD--gtC--gtT--gtM
• (Aanalysis, Ddesign, Ccoding, Ttesting,
  Mmaintenance)
• Prototyping A--gtD--gtC--gtT--gtM
• Incremental A--gtD--gtC--gtT--gtM--gtA--gtD--gtC--gtT--gt
  --gtM
• ?Component based A--gtD--gtLibrary--gtIntegrate--gtT-
  -gtM
• C

14
Formal Methods
Formal Methods formal mathematical
specification of SW. Uses rigorous mathematical
notation. Advantages --Ambiguity,
incompleteness, inconsistency found more
easily. --Serves as a basis for program
verification. --promise of defect-free SW
Disadvantages --Very time consuming --extensive
training required --not a good communication
mechanism (especially for customer) --handles
syntax well not so successful with
semantics uses Safety critical SW (medicine
and avionics) or when severe economic
hardship will be incurred by developer if error
occurs
15
Extreme Programmingan Agile Process Model

• Extreme Programming--
• An Agile Process Model

16
Review of Process Models

• In process models discussed previously

Basic method
problem?develop?integrate each step is carried
out recursively until an appropriate level of
detail is achieved
17
Introduction to Extreme Programming
18
12 Practices of XP
19
Metaphor
20
Release Planning
2. release planning requirements are given in
terms of "user stories" each "story" is a short
( 1 index card) description of what the customer
wants, in natural language requirements are
prioritized by customer resources and risks are
estimated by developer "planning game"--each
increment is restricted to a "time box" highest
priority and highest risk user stories are in
early time boxes after each increment, replay
the "planning game"
21
Testing
3. testing development is test-driven tests
are written before code unit must run at 100
before going on acceptance tests written with
customer they act as "contract", measure
progress
22
Pair Programming
4. pair programming two engineers, one task,
one computer "driver" controls keyboard
mouse "navigator" watches, identifies defects,
participates in brainstorming roles are rotated
periodically (you will use this approach in week
1 lab to gain some java skills)
23
Refactoring
5. refactoring improve design of existing code,
but don't change functionality relies on
testing no new errors can be introduced
24
Simple Design
6. simple design no big design up front "do
the simplest thing that could possibly work"
don't add features you won't need may use
"CRC cards"
25
Collective Code Ownership
7. collective code ownership code belongs to
project, not individual engineers may browse
into and modify ANY class
26
Continuous Integration
8. continuous integration pair writes unit
test cases code pair tests code to
100 pair integrates pair runs ALL test
cases to 100 pair moves on to next task
27
On-Site Customer
9. on-site customer clarifies stories,
participates in critical decisions developers
don't make assumptions no waiting for
decisions face-to-face communication
28
Small Releases
10. small releases timeboxed as small as
possible, but with "business value" get
feedback early and often do planning game
after each iteration
29
40-Hour Work Week
11. 40-hour work week burning midnight oil
kills performance tired developers make more
mistakes workforce is more content
30
Coding Standards
12. coding standards use coding
conventions write intention-revealing code
31
13th Practice
"13th practice" stand up meeting 15 minutes
at start of each day stand up to keep meeting
short each participant says --what they
did yesterday --what they plan to do
today --any obstacles they are
facing pairs can be reformed based on meeting
32
Contrast with Waterfall Model

• example contrasts "waterfall model XP
• planning upfront incremental
• control of project, "people" questions
  centralized distributed
• customer involvement only for specification,
  reviews ongoing
• risk analysis, scheduling all at beginning in
  increments
• code development assigned sections collective
  ownership
• testing specific phase ongoing and required
  to 100
• project type well-understood, static new,
  dynamic