1. 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

2. 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
Development phase: HOW
Support Phase: CHANGE, i.e., correction, adaptation, enhancement, prevention
Analyze—
Requirmnts,
Spec.
Develop—
Design,
Code.
Maintain

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
--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

6. 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. --can be appropriate for small, well-understood projects
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 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.
Analysis
Design
Code
Test
Maintain

9. Prototyping: A-->D-->C-->T-->M
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

11. (A=analysis, D=design, C=coding, T=testing, M=maintenance)
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. --Ambiguity, incompleteness, inconsistency found more easily.
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

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. requirements are given in terms of "user stories"
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. development is test-driven tests are written before code
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. two engineers, one task, one computer
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. improve design of existing code, but don't change functionality
Refactoring
5. refactoring
improve design of existing code, but don't change functionality
relies on testing; no new errors can be introduced

24. "do the simplest thing that could possibly work"
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
code belongs to project, not individual
engineers may browse into and modify ANY class

26. 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. clarifies stories, participates in critical decisions
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. as small as possible, but with "business value"
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. burning midnight oil kills performance
40-Hour Work Week
hour work week
burning midnight oil kills performance
tired developers make more mistakes
workforce is more content

30. use coding conventions write intention-revealing code
Coding Standards
12. coding standards
use coding conventions
write intention-revealing code

31. 15 minutes at start of each day stand up to keep meeting short
“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?