10 October 2006 Kaiser: COMS W4156 Fall 2006 1
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/
10 October 2006 Kaiser: COMS W4156 Fall 2006 2
Software Development Activities
• Process Selection• System Engineering• Requirements
– Determining Needs– Analysis
• Design– Architecture– Modules
• Coding – Unit Testing– Debugging
• Integration– Build– Integration Testing
• System Testing– Performance Testing &
Optimization– Acceptance Testing– Beta Testing
• Deployment– Delivery– Installation
• Operations– System Management– Maintenance– Upgrades
10 October 2006 Kaiser: COMS W4156 Fall 2006 3
Support Activities
• Project Planning and Tracking• Customer Interaction• Configuration Management• Process Improvement• Training• Documentation• Personnel Management• …
10 October 2006 Kaiser: COMS W4156 Fall 2006 4
Software Process
• Major Task Identification
• Sequencing
• General model to be tailored
In the beginning was......
10 October 2006 Kaiser: COMS W4156 Fall 2006 5
Build FirstVersion
Retirement
Operations
Modify untilCustomer satisfied
Code-and-Fix
10 October 2006 Kaiser: COMS W4156 Fall 2006 6
Discussion of Code-and-Fix
• Really Bad• Really Common• Advantages
– No Overhead– No Expertise
• Disadvantages– No means of assessing progress– Difficult to coordinate multiple programmers
• Useful for “hacking” single-use/personal-use programs: start with empty program and debug until it works
10 October 2006 Kaiser: COMS W4156 Fall 2006 7
Requirements
Validate
Retirement
Operations
Test
ImplementationVerify
Design
Waterfall
10 October 2006 Kaiser: COMS W4156 Fall 2006 8
More Detailed WaterfallREQUIREMENTS
ANALYSIS
SYSTEMDESIGN
PROGRAMDESIGN
CODING
UNIT & INTE-GRATION TESTING
SYSTEMTESTING
ACCEPTANCETESTING
OPERATION& MAINTENANCE
10 October 2006 Kaiser: COMS W4156 Fall 2006 9
Discussion of Waterfall• Articulated by Win Royce, ~1970• Widely used today• Advantages
– Measurable progress– Experience applying steps in past projects can be used in estimating
duration of “similar” steps in future projects– Produces software artifacts that can be re-used in other projects
• The original waterfall model (as interpreted by many) disallowed iteration– Inflexible– Monolithic– Requirements change over time– Maintenance not handled well
• The “waterfall with feedback” model was, however, what Royce had in mind
10 October 2006 Kaiser: COMS W4156 Fall 2006 10
Waterfall*REQUIREMENTS
ANALYSIS
SYSTEMDESIGN
PROGRAMDESIGN
CODING
UNIT & INTE-GRATION TESTING
SYSTEMTESTING
ACCEPTANCETESTING
OPERATION& MAINTENANCE
10 October 2006 Kaiser: COMS W4156 Fall 2006 11
Requirements
Validate
Retirement
Operations
Test
ImplementationVerify
Design
Requirements Change
Waterfall*
10 October 2006 Kaiser: COMS W4156 Fall 2006 12
Rapid Prototyping
Rapid Prototype
Validate
Retirement
Operations
Test
ImplementationVerify
Design
Requirements Change
10 October 2006 Kaiser: COMS W4156 Fall 2006 13
Evolutionary Prototyping
Initial Concept
Complete and Release
Prototype
Refine Prototype Until Acceptance
Design and Implement
Initial Prototype
10 October 2006 Kaiser: COMS W4156 Fall 2006 14
Discussion of Prototyping
• Prototypes used to help develop requirements specification– Useful for rapidly changing requirements– Or when customer won’t commit to specification
• Once requirements “known”, waterfall (or some other process model) is used
• Prototypes discarded once design begins– Prototypes should not be used as a basis for implementation,
since prototyping tools do not create production quality code– Customer may need to be “educated” about prototypes, a
prototype is not 80-90% of the final product (not even 10%)
10 October 2006 Kaiser: COMS W4156 Fall 2006 15
Incremental (Staged)
Detailed Design, Implement, Test, Deliver Feature Set
Requirements
Validate
Retirement
Operations
Verify
Architectural Design
10 October 2006 Kaiser: COMS W4156 Fall 2006 16
Discussion of Incremental
• Iterations are classified according to feature sets
– e.g., features 1 and 2 will be delivered in this iteration, features 3 and 4 are next
• Series of increasingly “complete” releases
10 October 2006 Kaiser: COMS W4156 Fall 2006 17
Spiral Model
PLAN DEVELOP AND TEST
DETERMINE GOALS,ALTERNATIVES,CONSTRAINTS
EVALUATE ALTERNATIVESAND RISKS
Requirements,life-cycle plan
Budget1
Alternatives1
Constraints1
Risk analysis1
Risk analysis2
Risk analysis3
Risk analysis4
Constraints2
Constraints3
Constraints4
Budget2
Budget3Budget4
Altern
atives 2
Altern
ative
s 3Altern
ative
s 4
Prototype1
Proto-type2
Proto-type3
Proto-type4
Concept ofoperation
Softw
are
requ
irem
ents
Validated
requirements
Developmentplan
Integrationand test plan
Softw
are
desig
n
Validated,
verified design
Detaileddesign
Code
Unit test
SystemtestAcceptance
testImplementation
plan
start
10 October 2006 Kaiser: COMS W4156 Fall 2006 18
Discussion of Spiral Model
• Proposed by Barry Boehm, ~1986• Similar to Incremental Model, but each
iteration is driven by “risk management” and/or customer feedback
• Determine objectives and current status• Identify risks and priorities• Next iteration addresses (current) highest
risk and/or highest priority items• Repeat
10 October 2006 Kaiser: COMS W4156 Fall 2006 19
Agile Programming
Initial Concept
Operations
Acceptance Testing
and Delivery
Requirements and Iteration
Planning
Next Iteration
Design andImplement
10 October 2006 Kaiser: COMS W4156 Fall 2006 20
Discussion of Agile
• Each iteration a mini-project– Each piece is not a prototype, but an operational
system– Understand risk vs. business value in planning
iterations– Put some working functionality into user’s hands as
early as possible• Timeboxing:
– Setting the date for an iteration– Date cannot change– Only functionality (scope) can change– Short duration iterations (weeks, not months)
10 October 2006 Kaiser: COMS W4156 Fall 2006 21
The Basic Problem: Risk
• The spiral model and agile programming view “risk” as the main problem of software development– Schedule slips– Business changes– Staff turnovers– New technologies– …
10 October 2006 Kaiser: COMS W4156 Fall 2006 22
Planning and Scheduling: Gantt Chart
• List tasks• Graphically represent dependencies among
tasks• Show duration and time period of each task• Heavily dependent on prediction regarding:
– Activities involved– Effort and time required
10 October 2006 Kaiser: COMS W4156 Fall 2006 23
Gantt chart example• Programmer working on a small software
project
ID Task Name Start FinishDuratio
n
Dec 2002
5 6 7 8 9 10 11 12 13 14 15 16 17 18
1 2d12/6/200212/5/2002Requirement gathering
2 1d12/9/200212/9/2002Analysis
3 2d12/11/200212/10/2002Design
4 4d12/17/200212/12/2002Coding
5 10d12/31/200212/18/2002Testing
19 20 21 22 23 24 25 26 27 28 29 30 31
Explicit start time, end time, and duration (in days )
Explicit calendar bar
10 October 2006 Kaiser: COMS W4156 Fall 2006 25
Planning and Scheduling: Pert chart
• Alternative to Gantt chart• Different perspective
– Focuses on dependencies more than calendar time
• No fixed format
2 12/6/2002
Late Start Slack Late Finish
12/5/2002
Requirement gathering
1 12/9/2002
Late Start Slack Late Finish
12/9/2002
Analysis
2 12/11/2002
Late Start Slack Late Finish
12/10/2002
Design
4 12/17/02
Late Start Slack Late Finish
12/12/2002
Coding
10 12/31/2002
Late Start Slack Late Finish
12/18/2002
Testing
Start time
Duration
End timeTask
10 October 2006 Kaiser: COMS W4156 Fall 2006 27
So how do you know how long a task is going to take?
10 October 2006 Kaiser: COMS W4156 Fall 2006 28
Function Points
• A.J. Albrecht of IBM, ~1979
• FP is a unit for estimating time and effort independent of programming language
• Identify set of application activities (building blocks) and sum the weights assigned to each
• From user’s viewpoint
10 October 2006 Kaiser: COMS W4156 Fall 2006 29
Function Points• Number of basic FP building blocks determined
from application, not implementation:– Input files – Output files– Inquiries (snapshot request, no state change)– Internal files (transformations)– External interfaces (to other systems)
• Score for each block based on complexity: low, medium, high
• Unadjusted FP (UFP) is sum of the scores
10 October 2006 Kaiser: COMS W4156 Fall 2006 30
UFP Scores
Low Medium High
Input files 3 4 6
Output files 4 5 7
Inquiries 3 4 6
Internal files 7 10 15
External interfaces
5 7 10
10 October 2006 Kaiser: COMS W4156 Fall 2006 31
Function Points• 14 “technical factors” related to complexity
– Grouped under 3 classes of complexity:system, I/O, application
– Each factor ranked from 0 to 5
• Technical complexity factor (TCF)
• Adjusted function points (AFP or FP)FP = UFP * (0.65 + TCF)
01.014
1 i iTCFTCF
The sum of the 14 factors’ ranks
10 October 2006 Kaiser: COMS W4156 Fall 2006 32
Using FPs to Estimate Time/Effort
• Previous measurements of FP per staff month or FP per calendar month
• Applies to maintenance as well as development (“enhancement function points”)
• Tables available for lines of code per FP in various programming languages
10 October 2006 Kaiser: COMS W4156 Fall 2006 33
Technical Factors1. System Complexity 2. I/O Complexity 3. Application Complexity
1.1 Data communication
2.1 Reliable and transaction-oriented data management
3.1 Algorithms and processing ability
1.2 Distributed data processing
2.2 Online data management
3.2 Need to reuse the code later
1.3 Relevance of performance
2.3 Usability and efficiency of end user
3.3 Installation easiness
1.4 Configuration of hardware and software
2.4 Online update of the data
3.4 Startup, shutdown, and operation easiness
Partial (1) Partial (2) 3.5 Requirements to run on multiple sites
3.6 Readiness to change
Partial (3)
Total
10 October 2006 Kaiser: COMS W4156 Fall 2006 34
UFP for Making CappuccinoName Type
(building block)Complexity Value
Milk Input File Medium 4
Coffee Input File Medium 4
Water Input File Low 3
Cappuccino Output File High 7
Water Temperature Inquiry Low 3
External Temperature External Interface Medium 7
Total Unadjusted Function Points 28
10 October 2006 Kaiser: COMS W4156 Fall 2006 35
FP for Making Cappuccino1. System Complexity 2. I/O Complexity 3. Application Complexity
1.1 Data communication 5 2.1 Reliable and transaction-oriented data management
0 3.1 Algorithms and processing ability
1
1.2 Distributed data processing
3 2.2 Online data management
4 3.2 Need to reuse the code later
0
1.3 Relevance of performance
4 2.3 Usability and efficiency of end user
4 3.3 Installation easiness 5
1.4 Configuration of the hardware and the software
4 2.4 Online update of the data
2 3.4 Startup, shutdown, and operation easiness
3
Partial (1) 16 Partial (2) 10 3.5 Requirements to run on multiple sites
2
3.6 Readiness to change 2
Partial (3) 13
Total = 39
10 October 2006 Kaiser: COMS W4156 Fall 2006 36
FP for Making Cappuccino
• FP = UFP * (0.65 + TCF)
= 28 * (0.65 + (39 * 0.01)) = 29.12
• So what was the time/effort required last time your firm implement 29 FPs?
10 October 2006 Kaiser: COMS W4156 Fall 2006 37
Function Points
• Building blocks identification and weight assignment depend critically on:– A world-wide database of FP practices– History of the firm (or consultants)– Experience of the FP estimators (certification)
• International Function Points User Group– 200 page Function Point Counting Practices
Manual (but you have to be a member to get it!)– http://www.ifpug.org/
10 October 2006 Kaiser: COMS W4156 Fall 2006 38
Constructive Cost Model
• Barry Boehm of TRW (now USC), ~1981, updated ~1995
• COCOMO estimates best/likely/worst case range for cost, effort and schedule required to develop software
• Based on empirical data from numerous projects, divided according to 3 development modes: organic, semidetached, embedded
10 October 2006 Kaiser: COMS W4156 Fall 2006 39
Development Modes
• Organic: relatively small software teams develop software in a highly familiar, in-house environment
• Semidetached: intermediate stage between the organic and embedded modes
• Embedded: Product must operate within (is embedded in) a strongly coupled complex of hardware, software, regulations, and operational procedures
10 October 2006 Kaiser: COMS W4156 Fall 2006 40
Additional Factors
Platform Personnel Project
Execution Time Constraints
Analyst Capability Use of Modern Programming Practices
Main Storage Constraints Programmer Capability Use of Software Tools
Platform Volatility Applications Experience Multi-site Development
Computer Turnaround Time
Platform Experience Required Development Schedule
Language and Tool Experience
Classified Security Application
Personnel Continuity
10 October 2006 Kaiser: COMS W4156 Fall 2006 41
COCOMO
• Assumes separate guestimate of lines of code (e.g., “backfiring” function points), then considers additional factors
• Polynomial model
• A and B are computed based on the development mode and additional factors
0,
)(
BAwhere
SizeASizeEffort B
10 October 2006 Kaiser: COMS W4156 Fall 2006 42
Using COCOMO
• Continued data collection to improve prediction accuracy (questionnaires, software, NDAs)
• 544 page handbook available as a guide for the calculations of A and B (anyone can order from amazon.com)
• Supporting software available from USC and commercially
• http://sunset.usc.edu/research/COCOMOII/
10 October 2006 Kaiser: COMS W4156 Fall 2006 43
Summary
• FP and COCOMO macro-estimation based partially on large historical databases of contributing software projects from multiple domains and partially on in-house experience
• In contrast, most software industry micro-estimation entirely in-house, usually based on same or similar projects by same or related project team
10 October 2006 Kaiser: COMS W4156 Fall 2006 45
Project Deliverables
• Project concept (P/F)• Revised concept (P/F)• First iteration (25%)
– 1st iteration plan – 1st iteration progress
report – 1st iteration demo– 1st iteration final report
• Second iteration (25%)– 2nd iteration plan – Code inspection– 2nd iteration progress
report – 2nd iteration demo– 2nd iteration final report
10 October 2006 Kaiser: COMS W4156 Fall 2006 46
First Iteration Plan due Tuesday October 24th
• The purpose of this assignment is to – more precisely define the requirements for
your systems, and – to plan the engineering tasks necessary to
fulfill those requirements.
10 October 2006 Kaiser: COMS W4156 Fall 2006 47
Requirements
• Reconsider the user stories or informal use cases you submitted for your Revised Project Concept. – It may be appropriate to subdivide some requirements
and merge others. – You may also want to add or remove some
requirements.• Assign a priority to each requirement, e.g., high,
medium, low. – Any requirements that must be fulfilled in order to
demonstrate your system should be labeled as high priority.
10 October 2006 Kaiser: COMS W4156 Fall 2006 48
Work Breakdown
• Refine and elaborate your user stories or informal use cases as engineering tasks.
• Some requirements may consist of multiple engineering tasks. – Make sure to label each engineering task with the requirement it
corresponds to. • “Infrastructure” tasks:
– Some engineering tasks may cut across multiple functional requirements, such as implementing a database facility or a client GUI
– Some engineering tasks may not correspond directly to functional requirements, such as getting the component model framework up and running, setting up a shared code repository, etc.
10 October 2006 Kaiser: COMS W4156 Fall 2006 49
Work Breakdown
• Assign each engineering task a positive number of "points", where a "point" is the amount of work you expect one pair to be able to accomplish within one week.
• You will probably want to assign most tasks as fractional, e.g., 1/2 point, 1/4 point, etc.
• You have three weeks between the Revised Project Concept deadline (Tuesday 17 October) and the beginning of demo week (Wednesday 8 November)– So for a two-pair team, there should be a maximum of 6 points
assigned to high priority requirements and infrastructure (maximum 3 points if only one pair)
– It is ok if there are fewer than 6 points. – Note one of those weeks will already be past by the time this
assignment is due!
10 October 2006 Kaiser: COMS W4156 Fall 2006 50
Schedule
• Map out a day to day schedule for the three weeks, including the week already past. – Your schedule should include both already completed tasks as
well as upcoming tasks.– You do not need to show the schedule in any fancy format such
as a Gantt or Pert chart.
• Keep in mind that you must have a demoable system at the end of this iteration, to be able to show during the first iteration demo week (November 8-14).
• A "sliding scale" of extra credit will be granted to teams who demo earlier during demo week rather than later.
10 October 2006 Kaiser: COMS W4156 Fall 2006 51
First Iteration Plan: Deliverables
1. Cover page (maximum 1 page): Team name, membership, which component model framework you are using
2. Requirements (maximum 4 pages): Define your requirements in the form of use cases or informal use cases, each with a stated priority.
You may be able to copy and paste much of this from your Revised Project Concept, but make sure to add the priorities!
3. Work Breakdown (maximum 4 pages): Define your engineering tasks, each with a (fractional) point value. Give the detailed schedule with personnel assignments for completing the engineering tasks, including any work already completed.
4. Controversies (maximum 1 page)
Post in YOUR TEAM FOLDER on CourseWorks
10 October 2006 Kaiser: COMS W4156 Fall 2006 52
Upcoming
• Revised project concept due October 17th
• First iteration plan due October 24th
• First iteration progress report due October 31st
• First demo week November 8-14
• First iteration final report due November 14
10 October 2006 Kaiser: COMS W4156 Fall 2006 53
COMS W4156: Advanced Software Engineering
Prof. Gail Kaiser
http://york.cs.columbia.edu/classes/cs4156/