Software process
COMP-304
Eugene Syriani Modelling, Simulation, and Design Lab
McGill University
COMP-304
SOFTWARE PROJECT • A project abides to a specific software life cycle • A life cycle is composed of processes • Processes consist of activities, divided in sub-activities or tasks • Tasks are quantifiable/measurable and consume time and resources
2
COMP-304
PROCESS: A QUEUING SYSTEM
3
COMP-304
SOFTWARE PROCESSES “The Software Engineering process is the total set of Software Engineering activities needed to transform requirements into software”
Watts S. Humphrey. Software Engineering Institute, CMU. (portal.acm.org/citation.cfm?id=75122)
4
COMP-304
SOFTWARE PROCESSES • Waterfall (Royce) • V Model (German Ministry of Defence) • Prototyping • Operational Specification (Zave) • Transformational (automated software synthesis) (Balzer) • Phased Development: Increment and Iteration • Spiral Model (Boehm) • Rational Unified Process (RUP) • Extreme Programming (XP) • System Dynamics (Dynamic Process Model) 5
COMP-304
SOFTWARE PROCESSES
Shari Lawrence Pfleeger. Software Engineering: Theory and Practice (Second Edition). Prentice Hall. 2001. Chapter 2: Modelling the Process and Life Cycle. 6
COMP-304
WATERFALL PROCESS • Royce ’70 • Activity-centric
• No turn back • Over simplistic
Req Doc
Sys Des Doc
More expensive
• Sequential process
Pgm Des Doc
Code
Report
Report
Cheque $
7
COMP-304
WATERFALL PROCESS IN REALITY
8
COMP-304
• Elicitation layer • Architecture layer • Assembly of components
Validation
• Explicit dependency between development & verification activities
More detailed representation of system
WATERFALL VARIANT: V MODEL
9
COMP-304
WATERFALL VARIANT: WITH PROTOTYPING
10
COMP-304
PROTOTYPING PROCESS
11
COMP-304
OPERATIONAL SPECIFICATION PROCESS
12
COMP-304
TRANSFORMATIONAL PROCESS
13
COMP-304
PHASED DEVELOPMENT PROCESS
14
COMP-304
PHASED DEVELOPMENT: INCREMENTAL VS. ITERATIVE
15
COMP-304
SPIRAL MODEL Boehm ’87 Waterfall in each cycle: 1. Determine objectives 2. Specify constraints 3. Generate alternatives 4. Identify risks 5. Resolve risks 6. Develop & verify 7. Plan next phase
Waterfall
16
COMP-304
THE RATIONAL UNIFIED PROCESS (RUP) Activity Workload as Function of Time Jacobson et. al. ’99 Phases • Inception: scope, use cases • Elaboration: initial architecture design, cost & resource estimates • Construction: build component, release, acceptance criteria • Transition: deployment Activities • Requirements: analysis of app domain & creation of requirement artefacts • Design: creation of solution & design artefacts
• Testing: assessment of processes & products • Deployment: transition of system to user • Environment: maintenance (communication & configuration mgmt)
17
COMP-304
THE (RATIONAL) UNIFIED PROCESS Empirical Observations 1. Waterfall-like sequence of – Requirements, Design, Implementation, Testing.
2. Not pure waterfall: – Phased Development (iterative) – Overlap (concurrency) between activities
3. Testing: – Regression (test not only newly developed, but also previously developed code) – Testing starts before design and coding (Extreme Programming) 18
COMP-304
THE (RATIONAL) UNIFIED PROCESS Cycles, Phases, and Iterations
19
COMP-304
EXTREME PROGRAMMING (XP)
(www.extremeprogramming.org)
20
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS “User Stories are written by the customers as things that the system needs to do for them (requirements). They drive the creation of acceptance tests.” • Code the Unit Test first (from user stories) • All code must have Unit Tests • All code must pass all unit tests before it can be released 21
COMP-304
EXTREME PROGRAMMING (XP) PROCESS • The project is divided into Iterations
• The “inner loop” is a daily cycle! 22
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS Class, Responsibilities, and Collaboration (CRC) Cards
23
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS • Refactor whenever and wherever possible – for readability (maintainability) – for re-use – for optimization –…
• Refactoring code or design • Catalog of Refactoring Patterns (rules) http://www.refactoring.com/catalog/
24
COMP-304
REFACTORING PATTERNS Reverse Conditional 1. Remove negative from conditional 2. Switch clauses Example: if (!isSummer(date)): charge = winterCharge(quantity) else: charge = summerCharge(quantity)
if (isSummer(date)): charge = summerCharge(quantity) else: charge = winterCharge(quantity) 25
COMP-304
REFACTORING PATTERNS Consolidate Duplicate Conditional Fragments 1. lift commonality out of conditional Example:
if (isSpecialDeal()): total = price * 0.95 send() else: total = price * 0.98 send()
if (isSpecialDeal()): total = price * 0.95 else: total = price * 0.98 send()
26
COMP-304
REFACTORING PATTERNS Split Loop 1. Copy the loop 2. Remove the differing pieces from each loop Example: def printValues: averageAge = 0 totalSalary = 0 for person in people: averageAge += person.age totalSalary += person.salary averageAge = averageAge / people.length print averageAge print totalSalary
def printValues: averageAge = 0 for person in people: averageAge += person.age averageAge = averageAge / people.length print averageAge totalSalary = 0 for person in people: totalSalary += person.salary print totalSalary
27
COMP-304
REFACTORING PATTERNS Pull Up Method 1. pull up identical (type-wise) methods from (all) sub-classes Example:
28
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS Pair Programming Advantages: • Higher Quality • Collective Ownership of code/design • Productivity Increase (“flow”) thanks to programmer/backseat pair • Learning/Training • …
Driver //vs// Partner
Reuse? 29
COMP-304
EXTREME PROGRAMMING (XP) PROCESS
30
COMP-304
TEST-DRIVEN DEVELOPMENT
• Tests not used for verification, but rather for specification – Dictate how the code should behave
• Process in very small steps – Minimize collisions during integration 31
COMP-304
THE PROCESS INFLUENCES PRODUCTIVITY
“Adding manpower to a late software project makes it later” Fred Brooks. The Mythical Man-Month. 1975 32
COMP-304
WHY BROOKS’ LAW ? TEAM SIZE N
• Model in Forrester System Dynamics using Vensim PLE (www.vensim.com)
development_rate = nominal_productivity * (1 - C_overhead * (N * (N - 1))) * N 33
COMP-304
TEAM SIZE N = 5
34
COMP-304
TEAM SIZE N = 3 . . 9
Optimal Team Size between 7 and 8 35
COMP-304
THE EFFECT OF ADDING NEW PERSONNEL (FSD MODEL)
development_rate = nominal_productivity * (1 - C_overhead * (N * (N - 1))) * (1.2 * num_exp_working + 0.8 * num_new) 36
COMP-304
5 NEW PROGRAMMERS AFTER 100 DAYS
37
COMP-304
0 . . 6 NEW PROGRAMMERS AFTER 100 DAYS
38
Eugene Syriani Modelling, Simulation, and Design Lab
McGill University
COMP-304
SOFTWARE PROJECT • A project abides to a specific software life cycle • A life cycle is composed of processes • Processes consist of activities, divided in sub-activities or tasks • Tasks are quantifiable/measurable and consume time and resources
2
COMP-304
PROCESS: A QUEUING SYSTEM
3
COMP-304
SOFTWARE PROCESSES “The Software Engineering process is the total set of Software Engineering activities needed to transform requirements into software”
Watts S. Humphrey. Software Engineering Institute, CMU. (portal.acm.org/citation.cfm?id=75122)
4
COMP-304
SOFTWARE PROCESSES • Waterfall (Royce) • V Model (German Ministry of Defence) • Prototyping • Operational Specification (Zave) • Transformational (automated software synthesis) (Balzer) • Phased Development: Increment and Iteration • Spiral Model (Boehm) • Rational Unified Process (RUP) • Extreme Programming (XP) • System Dynamics (Dynamic Process Model) 5
COMP-304
SOFTWARE PROCESSES
Shari Lawrence Pfleeger. Software Engineering: Theory and Practice (Second Edition). Prentice Hall. 2001. Chapter 2: Modelling the Process and Life Cycle. 6
COMP-304
WATERFALL PROCESS • Royce ’70 • Activity-centric
• No turn back • Over simplistic
Req Doc
Sys Des Doc
More expensive
• Sequential process
Pgm Des Doc
Code
Report
Report
Cheque $
7
COMP-304
WATERFALL PROCESS IN REALITY
8
COMP-304
• Elicitation layer • Architecture layer • Assembly of components
Validation
• Explicit dependency between development & verification activities
More detailed representation of system
WATERFALL VARIANT: V MODEL
9
COMP-304
WATERFALL VARIANT: WITH PROTOTYPING
10
COMP-304
PROTOTYPING PROCESS
11
COMP-304
OPERATIONAL SPECIFICATION PROCESS
12
COMP-304
TRANSFORMATIONAL PROCESS
13
COMP-304
PHASED DEVELOPMENT PROCESS
14
COMP-304
PHASED DEVELOPMENT: INCREMENTAL VS. ITERATIVE
15
COMP-304
SPIRAL MODEL Boehm ’87 Waterfall in each cycle: 1. Determine objectives 2. Specify constraints 3. Generate alternatives 4. Identify risks 5. Resolve risks 6. Develop & verify 7. Plan next phase
Waterfall
16
COMP-304
THE RATIONAL UNIFIED PROCESS (RUP) Activity Workload as Function of Time Jacobson et. al. ’99 Phases • Inception: scope, use cases • Elaboration: initial architecture design, cost & resource estimates • Construction: build component, release, acceptance criteria • Transition: deployment Activities • Requirements: analysis of app domain & creation of requirement artefacts • Design: creation of solution & design artefacts
• Testing: assessment of processes & products • Deployment: transition of system to user • Environment: maintenance (communication & configuration mgmt)
17
COMP-304
THE (RATIONAL) UNIFIED PROCESS Empirical Observations 1. Waterfall-like sequence of – Requirements, Design, Implementation, Testing.
2. Not pure waterfall: – Phased Development (iterative) – Overlap (concurrency) between activities
3. Testing: – Regression (test not only newly developed, but also previously developed code) – Testing starts before design and coding (Extreme Programming) 18
COMP-304
THE (RATIONAL) UNIFIED PROCESS Cycles, Phases, and Iterations
19
COMP-304
EXTREME PROGRAMMING (XP)
(www.extremeprogramming.org)
20
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS “User Stories are written by the customers as things that the system needs to do for them (requirements). They drive the creation of acceptance tests.” • Code the Unit Test first (from user stories) • All code must have Unit Tests • All code must pass all unit tests before it can be released 21
COMP-304
EXTREME PROGRAMMING (XP) PROCESS • The project is divided into Iterations
• The “inner loop” is a daily cycle! 22
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS Class, Responsibilities, and Collaboration (CRC) Cards
23
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS • Refactor whenever and wherever possible – for readability (maintainability) – for re-use – for optimization –…
• Refactoring code or design • Catalog of Refactoring Patterns (rules) http://www.refactoring.com/catalog/
24
COMP-304
REFACTORING PATTERNS Reverse Conditional 1. Remove negative from conditional 2. Switch clauses Example: if (!isSummer(date)): charge = winterCharge(quantity) else: charge = summerCharge(quantity)
if (isSummer(date)): charge = summerCharge(quantity) else: charge = winterCharge(quantity) 25
COMP-304
REFACTORING PATTERNS Consolidate Duplicate Conditional Fragments 1. lift commonality out of conditional Example:
if (isSpecialDeal()): total = price * 0.95 send() else: total = price * 0.98 send()
if (isSpecialDeal()): total = price * 0.95 else: total = price * 0.98 send()
26
COMP-304
REFACTORING PATTERNS Split Loop 1. Copy the loop 2. Remove the differing pieces from each loop Example: def printValues: averageAge = 0 totalSalary = 0 for person in people: averageAge += person.age totalSalary += person.salary averageAge = averageAge / people.length print averageAge print totalSalary
def printValues: averageAge = 0 for person in people: averageAge += person.age averageAge = averageAge / people.length print averageAge totalSalary = 0 for person in people: totalSalary += person.salary print totalSalary
27
COMP-304
REFACTORING PATTERNS Pull Up Method 1. pull up identical (type-wise) methods from (all) sub-classes Example:
28
COMP-304
EXTREME PROGRAMMING (XP) HIGHLIGHTS Pair Programming Advantages: • Higher Quality • Collective Ownership of code/design • Productivity Increase (“flow”) thanks to programmer/backseat pair • Learning/Training • …
Driver //vs// Partner
Reuse? 29
COMP-304
EXTREME PROGRAMMING (XP) PROCESS
30
COMP-304
TEST-DRIVEN DEVELOPMENT
• Tests not used for verification, but rather for specification – Dictate how the code should behave
• Process in very small steps – Minimize collisions during integration 31
COMP-304
THE PROCESS INFLUENCES PRODUCTIVITY
“Adding manpower to a late software project makes it later” Fred Brooks. The Mythical Man-Month. 1975 32
COMP-304
WHY BROOKS’ LAW ? TEAM SIZE N
• Model in Forrester System Dynamics using Vensim PLE (www.vensim.com)
development_rate = nominal_productivity * (1 - C_overhead * (N * (N - 1))) * N 33
COMP-304
TEAM SIZE N = 5
34
COMP-304
TEAM SIZE N = 3 . . 9
Optimal Team Size between 7 and 8 35
COMP-304
THE EFFECT OF ADDING NEW PERSONNEL (FSD MODEL)
development_rate = nominal_productivity * (1 - C_overhead * (N * (N - 1))) * (1.2 * num_exp_working + 0.8 * num_new) 36
COMP-304
5 NEW PROGRAMMERS AFTER 100 DAYS
37
COMP-304
0 . . 6 NEW PROGRAMMERS AFTER 100 DAYS
38
