10 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

10 October 2006 Kaiser: COMS W4156 Fall 2006 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

http://york.cs.columbia.edu/classes/cs4156/

mailto:[email protected]



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


Support Activities

• Project Planning and Tracking• Customer Interaction• Configuration Management• Process Improvement• Training• Documentation• Personnel Management• …


Software Process

• Major Task Identification

• Sequencing

• General model to be tailored

In the beginning was......


Build FirstVersion

Retirement

Operations

Modify untilCustomer satisfied

Code-and-Fix


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


Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

Waterfall


More Detailed WaterfallREQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE


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


Waterfall*REQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE


Requirements

Validate

Retirement

Operations

Test


Design

Requirements Change

Waterfall*


Rapid Prototyping

Rapid Prototype

Validate

Retirement

Operations

Test


Design

Requirements Change


Evolutionary Prototyping

Initial Concept

Complete and Release

Prototype

Refine Prototype Until Acceptance

Design and Implement

Initial Prototype


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


Incremental (Staged)

Detailed Design, Implement, Test, Deliver Feature Set

Requirements

Validate

Retirement

Operations

Verify

Architectural Design


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


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


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


Agile Programming

Initial Concept

Operations

Acceptance Testing

and Delivery

Requirements and Iteration

Planning

Next Iteration

Design andImplement


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)


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


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


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


Another Gantt


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


12/9/2002

Analysis

2 12/11/2002


12/10/2002

Design

4 12/17/02


12/12/2002

Coding

10 12/31/2002


12/18/2002

Testing

Start time

Duration

End timeTask


Another Pert


So how do you know how long a task is going to take?


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


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


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


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


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


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


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


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


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?


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/

http://www.ifpug.org/


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


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


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


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


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/

http://sunset.usc.edu/research/COCOMOII/


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


IDA #3 due TODAY!


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


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.


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.


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.


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!


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.


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


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


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


10 october 2006kaiser: coms w4156 fall 20061 coms w4156: advanced software engineering prof. gail...

Documents

coms w4156

discussion of code

incremental model

wellthe waterfall

process model

feedback model

educlassescs4156 kaiser

customer wont