1

Software Engineering Process Models

In this course we will have a project with:Product requirementsA defined development processA 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

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?

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

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"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 ModelPrototyping Model

"Evolutionary" (product evolves over time):

Incremental ModelComponent-based Model

“Formal Methods”Z-based methods

“Agile”Extreme Programming

8

Waterfall Model

Analysis Design Code Test Maintain

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.

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: A-->D-->C-->T-->M-->A-->D-->C-->T--> ……-->M

(A=analysis, D=design, C=coding, T=testing, M=maintenance)

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.

12

Component Based Development

Component based: A-->D-->Library-->Integrate-->T-->M

C(A=analysis, D=design, C=coding, T=testing, M=maintenance)

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 usingobject-oriented methods.

Advantages: Faster development and lowercosts.

Disadvantages: requires expertise in this type of development

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 andavionics) or when severe economic hardshipwill 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:

problemdevelopintegrate

each step is carried out recursively until an appropriate level of detail is achieved

Basic method:

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. metaphor2. release planning3. testing4. pair programming5. refactoring6. simple design7. collective code ownership8. continuous integration9. on-site customer10. small releases11. 40-hour work week12. coding standards("13th practice": stand-up meeting)

19

Metaphor 1. metaphor

describe project in terms of ametaphor to give a consistent pictureof the system and wheremodifications can be made

ex: "paycheck goes down anassembly line along which newinformation is added"

finding a good metaphor may notalways 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 customerresources 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

Question:

How are analysis and specification done

--in the “extreme programming” model?

--in the waterfall model?

Analysis and specification in XP