september 10, 2009coms w41561 coms w4156: advanced software engineering prof. gail kaiser...

September 10, 2009 COMS W4156 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

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

mailto:[email protected]



Topics covered in this lecture

• Introduce software process

• Describe several generic process models and consider advantages/disadvantages

• If time permits: Overview of planning and scheduling


Software Process


What is a software process?

• A structured set of activities required to develop a software product– Specification;

– Design and implementation;

– Validation;

– Evolution (operation and maintenance).


Software specification

• The process of establishing what features and services are required, as well as the constraints on the system’s operation and development.

• Requirements engineering process– Feasibility study;– Requirements elicitation and analysis;– Requirements specification;– Requirements validation.


Software design and implementation

• The process of converting the system specification into an executable system.

• Software design– Design a software structure that realizes the

specification;

• Implementation– Translate this structure into an executable

program;

• The activities of design and implementation are closely related and may be inter-leaved.


Software validation

• Verification and validation (V & V) is intended to show that a system conforms to its specification and meets the requirements of the customer(s).

• Involves checking and review processes, and acceptance or beta testing.

• Custom software: Acceptance testing involves executing the system with test cases that are derived from the real data to be processed by the system in the customer’s environment.

• Generic software: Beta testing executes the system in many customers’ environments under real use.


Software evolution

• Software is inherently flexible and can change.

• As requirements change due to changing business circumstances, the software that supports the business must also evolve and change.

• Although there has historically been a demarcation between development and evolution, this is increasingly irrelevant as fewer and fewer systems are completely new.


Process Models


Software Process

• A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.– Major Task Identification– Sequencing

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

– Difficulty of accommodating change after the process is underway: One phase has to be complete before moving onto the next phase.


Discussion of Waterfall• The original waterfall model (as interpreted by many)

disallowed iteration– Inflexible partitioning of the project into distinct stages

makes it difficult to respond to changing customer requirements.

– Therefore, this model is only appropriate when the requirements are very well-understood and changes will be very limited during the design process.

– But few business systems have stable requirements.• The “waterfall with feedback” model was, however,

what Royce had in mind


Requirements

Validate

Retirement

Operations

Test

ImplementationVerify

Design

Requirements Change

Waterfall*


Waterfall*REQUIREMENTS

ANALYSIS

SYSTEMDESIGN

PROGRAMDESIGN

CODING

UNIT & INTE-GRATION TESTING

SYSTEMTESTING

ACCEPTANCETESTING

OPERATION& MAINTENANCE


Evolutionary• Throw-away prototyping

– Objective is to understand the system requirements.– Should start with poorly understood requirements to clarify

what is really needed.

• Incremental development – Objective is to work with customers to evolve a final

system from an initial outline specification. – Should start with well understood requirements and stage

development and delivery.


Prototyping

Initial Concept

Complete and Release

Prototype

Refine Prototype Until Acceptance

Design and Implement

Initial Prototype


Discussion of prototyping• Mock-ups allow users to visualize an application that

hasn't yet been constructed• Used to help develop requirements specification

– Useful for rapidly changing requirements– Or when customer isn’t sure what specification should be

• Prototypes should be discarded once requirements are “known”, and another process model used for development– Prototypes should not be used as a basis for implementation,

since rapid prototyping tools do not create production quality code

– Customer (and management) may need to be “educated” about prototypes: a prototype is not 80-90% of the final product, usually not even 10%


Incremental (staged) delivery

Detailed Design, Implement, Test, Deliver Feature Set

Requirements

Validate

Retirement

Operations

Verify

Architectural Design


Discussion of incremental delivery

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

• Lack of process visibility - when will it be done?

• Systems are often poorly structured.


Process Iteration

• System requirements ALWAYS evolve in the course of a project so process iteration where earlier stages are reworked is always part of the process for large systems.

• Iteration can be applied to any of the generic process models.

• Several approaches.


Iterative delivery

Initial Concept

Operations

Acceptance Testing

and Delivery

Requirements and Iteration

Planning

Next Iteration

Design andImplement


Discussion of iterative delivery• Rather than deliver the system as a completed product,

the development and delivery is broken down into iterations, with each iteration delivering part of the required functionality.

• User requirements are prioritized and the highest priority requirements are included in early iterations.

• Once the development of an iteration is started, the requirements are frozen - but requirements for later iterations can continue to evolve (this is the distinction compared to incremental delivery of feature sets)


Discussion of iterative development

• Customer value can be delivered with each iteration so system functionality is available earlier.

• Each iteration’s deliverable is not a prototype, but an operational system.

• However, early iterations act as a prototype to help elicit requirements for later iterations (exploratory).

• Lower risk of overall project failure.• The highest priority system services tend to receive

the most testing.


Agile (eXtreme) Programming

• Iterative, but with a lot of hype• Timeboxing:

– Set the date for delivering an iteration– Date cannot change– Only functionality (scope) can change– Short duration iterations (weeks, not

months)


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

Constraints 2

Constraints 3

Constraints 4

Budget2

Budget3Budget4

Altern

atives 2

Altern

ative

s 3Altern

ative

s 4

Prototype 1

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

• Process is represented as a spiral rather than as a sequence of activities with backtracking.– Each loop in the spiral represents a phase in the

process. – No fixed phases such as specification or design -

loops in the spiral are chosen depending on what is required.


Discussion of Spiral Model

• Each iteration is driven by “risk management”

– Determine objectives and current status

– Identify risks and priorities

– Next iteration addresses (current) highest risk and/or highest priority items


The Basic Problem: Risk

• The spiral and agile iterative process models view “risk” as the main problem of software development– Schedule slips– Business changes– Staff turnovers– New technologies– …


Planning and Scheduling


Gantt charts

• Articulated by Henry Gantt, ~1903• 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

http://www.ganttchart.com/History.html


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 (e.g., in days)

Explicit calendar bar


Another Gantt chart


Planning and Scheduling: Pert chart

• Alternative to Gantt chart• PERT = Project

Evaluation and Review Technique (developed for US DoD, ~1958)

• Different perspective - Focuses on dependencies more than calendar time

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 chart


The BIG Question: How do you know how long a

software engineering 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 end-user’s viewpoint


Function Points• Number of basic FP building blocks determined from

application, not implementation (which doesn’t exist yet!):– 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


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


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


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 company implemented 29 FPs?


Function Points

• Building blocks identification and weight assignment depend critically on:– A world-wide database of FP practices– History of the company (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/


Constructive Cost Model

• Barry Boehm [again], ~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, dividing according to development mode


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 - and elsewhere - but costs $$$)

• Supporting software available from USC and commercially

• http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html


Final Notes


Reminder:First Assignment Due Next Week!

• Due Tuesday 15 September, 10am

• Posted on course website

• Submit via CourseWorks

• Pair Formation

http://bank.cs.columbia.edu/classes/cs4156/homeworks/pair.htm

https://courseworks.columbia.edu/

http://bank.cs.columbia.edu/classes/cs4156/homeworks/pair.htm


Upcoming Deadlines

• Teams announced September 22nd

• Team project concept due September 29th

• Project concept feedback by October 6th First iteration begins October 6th


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


september 10, 2009coms w41561 coms w4156: advanced software engineering prof. gail kaiser...

Documents

generic software

software structure

coms w4156software design

custom software

software designdesign

coms w4156code

implementationthe process

generic process models