Download An Agile Process Model - Department of Electrical Engineering and

Software Engineering Process Models
In this course we will have a project with:
Product requirements
A defined development process
A team of 3-5 developers
We will use the Unified Modeling Language
(UML) to describe our product specifications
and design
Today we will discuss some standard process
models
1
Software Engineering Phases
Software Engineering: Systematic, disciplined
quantifiable approach to the development,
operation and maintenance of SW.
Three distinct phases:
•
Definition phase: WHAT, i.e., what information,
function, performance
Develop—
Design,
Code.
•
Development phase: HOW
Maintain
•
Support Phase: CHANGE, i.e., correction,
adaptation, enhancement, prevention
Analyze—
Requirmnts,
Spec.
2
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?
3
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
5.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?
4
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developintegrate
each step is carried out recursively until an appropriate
level of detail is achieved
5
What does the model need to provide?
--organized development:
specify, design, implement, test, maintain
--testing strategy
--tracking / change management
--schedule
Etc.
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"
Formal 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
Analysis
Design
Code
Test
Maintain
Advantages:
--better than nothing
--can be appropriate 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-->D-->C-->T-->M
(A=analysis, D=design, C=coding, T=testing,
M=maintenance)
10
Evolutionary Models
Evolutionary Models--useful for:
Business and product requirements
which change during development.
Tight market deadlines.
Cases where core requirements are
understood but details of extensions are
not known.
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-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M
(A=analysis, D=design, C=coding, T=testing, M=maintenance)
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-->D-->Library-->Integrate-->T-->M
C
(A=analysis, D=design, C=coding, T=testing, M=maintenance)
13
Process Models--Comparison
Graphical comparison of basic and evolutionary models:
•Basic waterfall model: A-->D-->C-->T-->M
(A=analysis, D=design, C=coding, T=testing, M=maintenance)
•Prototyping:
A-->D-->C-->T-->M
•Incremental: A-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M
Component based:
A-->D-->Library-->Integrate-->T-->M
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 Programming—an 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
Introduction to "Extreme Programming" (XP):
references:
1. Bergin & Williams, SIGCSE 2002;
2. www.extremeprogramming.org
Idea: allow project to develop incrementally,
building in new features and changed
requirements; involve customer as an integral
part of the process; meet tight market deadlines
XP is one example of the newer "Agile
Processes"--designed for quick releases, good
for competitive businesses
18
“12 Practices” of XP
"12 practices":
1. metaphor
2. release planning
3. testing
4. pair programming
5. refactoring
6. simple design
7. collective code ownership
8. continuous integration
9. on-site customer
10. small releases
11. 40-hour work week
12. coding standards
("13th practice": stand-up meeting)
19
Metaphor
1. metaphor
describe project in terms of a
metaphor to give a consistent picture
of the system and where
modifications can be made
ex: "paycheck goes down an
assembly line along which new
information is added"
finding a good metaphor may not
always be possible
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 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
33
Analysis and specification in XP
Question:
How are analysis and specification done
--in the “extreme programming” model?
--in the waterfall model?
34