06 september 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

06 September 2007 Kaiser: COMS W4156 Fall 2007 1

COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]

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

mailto:[email protected]



Software Engineering Activities

• System Engineering

• Process Selection and Training

• Requirements– Eliciting– Analysis– Recording

• Technology Selection and Training• Design

– Architecture– Components– Modules

• Coding – Unit Testing– Debugging

• Integration– Build– Integration Testing– Configuration Management

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

ImplementationVerify

Design

Requirements Change

Waterfall*


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 won’t commit to specification

• Once requirements “known”, waterfall (or some other process model) 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 (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)

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 iteration’s deliverable 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:

– Set the date for delivering 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 (e.g., 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


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 firm implemented 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, 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/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


Software Engineering Activities

• System Engineering• Process Selection and Training• Requirements

– Eliciting– Analysis– Recording

• Technology Selection and Training• Design

– Architecture– Components– Modules

• Coding – Unit Testing– Debugging

• Integration– Build– Integration Testing– Configuration Management

• 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– Process Improvement– Training– Documentation– Personnel Management


Requirements

• What is the (future) software system supposed to “do”? And “why?”

• Requirements must be measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design

• Usage scenarios– User stories– Use Cases– Process specifications– Generic natural language– …


User Stories• Written by the customers (or end-users) as

things that the system needs to do for them • About 3 sentences in the customer’s

terminology, without technical detail• Written on index cards (!)• May be augmented by samples (e.g., formatted

report)• Prioritize (high, medium, low)• Generally does not address non-functional

requirements (e.g., performance, security)


Example Story Card

111 Instructor View

The instructor view for a given course includes the course number, name and semester; a button to edit the introduction; a button to designate library reserves; and a button to adjust settings for the course.

Otherwise the instructor view is the same as the student view.

Priority High


Continuing Example

222 Student View

The student view for a given course includes the course number, name and semester; general courseinformation; and instructor information.

There are buttons to select introduction, discussion, board, class e-mail, dictionary, notepad and help.

Priority High


Continuing Example

123 Instructor vs. Student View

When an instructor selects one of the courses he/she is teaching, the instructor view is shown.The instructor view should include a button to show the student view, and then that special studentview should include a button to switch back to the instructor view

Priority Medium


Continuing Example

321 Login

The user is prompted to enter uni and password

If the uni and password match database,the user is shown the default screen with his/her list of current courses

Priority High


Why are user stories on cards?

• Easy to rip up• Tangible Unit of

– Discussion– Estimation– Scheduling– Testing– Completion

• Used for:– Construction of engineering tasks– Creation of acceptance tests– Derivation of time estimates for planning


Use Case Modeling• Each use case provides one or more scenarios

that convey how the system should interact with the end user or another system to achieve a specific business goal

• Use case model emphasizes the behavior as it appears to external actors, treats the system as a black box

• Partitions system functionality into interactions (‘use cases’) that are meaningful to users or external systems (‘actors’)

• Sometimes hundreds of use cases are needed to fully specify a system


Use Case Diagram

• Using, e.g., UML = Unified Modeling Language• Visualizes the high-level functions of the system

and the system's scope– Including the relationship of "actors" to essential

processes and system functionality– As well as the relationships among different use

cases• By looking at a use case diagram, you can easily

tell the functions that the system provides (and doesn’t provide)

• Generally does not address non-functional requirements (e.g., performance, security)


Example Use Case• This system lets the band

manager view a sales statistics report and the Billboard 200 report for the band's CDs

• It also lets the record manager view a sales statistics report and the Billboard 200 report for a particular CD

• The diagram also tells us that our system delivers Billboard reports from an external system called Billboard Reporting Service


Continuing Example

• This use case diagram does not provide a way for a band manager to listen to songs from the different albums on the Billboard 200 — i.e., we see no reference to a use case called Listen to Songs from Billboard 200


Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

Fill orders

Shipping Clerk

status

order

Another Simple Example

06 September 2007 Kaiser: COMS W4156 Fall 2007 55Fig. 3-54, UML Notation Guide

Not So Simple Use Case Relationships

additional requests :

OrderProduct

SupplyArrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog


Yet Another Simple Example

Online HR System

LocateEm ployees

UpdateEm ployee

Profile

Update Benefits

Access TravelSystem

Access PayRecords

Em ployee

M anager

Healthcare P lan System

{if currentMonth = Oct.}

{readOnly}

Insurance P lan System


More Not So Simple Use Case Relationships

Update M edicalP lan

Update DentalP lan

Update Benefits______________Extension pointsbenefit options:

after required enrollm ents

UpdateInsurance P lan

Em ployee

<<include>> <<include>> <<include>>

ElectReim bursem entfor Healthcare

Elect StockPurchase

<<extend>>em ployee requestsstock purchase option

<<extend>>em ployee requestsreim bursem ent option

extensioncondition

extension pointname andlocation


Use Cases vs. User Stories

• Both intended to capture functional requirements

• Neither directly address non-functional requirements

• Use Cases are more formal

• User Stories tend to be more fine-grained

• User Stories don’t easily map relationships


One problem with User Stories and User Cases

• Where do the usage scenarios come from?

• The customers (or users).

• But how do the customers know what to put in their usage scenarios?


Requirements Elicitation• Process of “discovering” the requirements for a system• Through communication with customers, system users,

system administrators and other stakeholders• Through domain analysis• Through investigation of previous and similar systems –

reuse requirements– Saves time and money– Reduces risk – Reused requirements have a better chance of being

understood by all stakeholders– Requirements reuse may lead to additional reuse in

other lifecycle activities


Requirements Elicitation• Use Business Concerns to drive elicitation

– If a system is to be useful, it must contribute to the key concerns of the business

– If those business concerns are identified and used as drivers of the requirements elicitation process, there will be higher confidence that the system will meet real organization needs

• Collect requirements from Multiple Viewpoints– If the requirements are collected from a single viewpoint,

unlikely to meet other stakeholders requirements– Identified viewpoints can be used to help organize

requirements elicitation and the resulting requirements specification


Requirements Challenges: “Yes, But”

• The first time users see the system, the first reaction is either, “Wow this is so cool” or “Yes, but, hmm, now that I see it what about this…?”

• This reaction is simply human nature

• Need to get the “buts” out early

• Anticipate that there will be “buts” and add time and resources to plan for feedback


Requirements Challenges: “Undiscovered Ruins”

• Developers struggle with determining when they are done with requirements elicitation– How can we tell whether all the requirements have

been elicited, or have we found at least enough?– Like asking an archeologist “how many undiscovered

ruins are there?”• First scope the elicitation effort by defining the

business problem(s) to be solved by the system• Employ techniques that help find some of those

ruins and get the stakeholders to buy-into the requirements


Requirements Challenges:“User versus Developer”

• Users do not know what they want, or cannot articulate it

• Users think they know what they want until developers give them what they said they wanted

• Developers think they understand user problems better than users do

• Recognize and appreciate the users as domain experts

• Provide alternative elicitation techniques earlier: storyboard, role playing, prototypes, etc.

• Put the developers in the users’ place


Requirements Challenge: Living with “the Sins

of your Predecessors”• Like it or not, your customers and developers

remember what happened in the past– “Total Quality Management” programs that promised

things would be different– The last project where requirements were vague and/or

were delivered short of expectations• Need to build trust slowly: do not over-commit to

features, schedule or budget• Deliver highest priority features early


Requirements Elicitation Techniques

• Interviewing and questionnaires

• Brainstorming and idea reduction

• Storyboarding

• Role Playing

• Requirements workshops

• Prototyping


Technique: Interviewing

• Simple direct technique

• Context-free questions about what system needs to do for the users

• Convergence on some common needs will initiate a “requirements repository”

• A questionnaire is no substitute for an interview, but may precede or follow interviews


Interview: Context-free questions

• Goal is to prevent prejudicing the user’s response to the questions

• Examples:– Who is the customer?– Who is the user?– Who is the user’s customer?– Are their needs different?– Where else can a solution to this problem be found?

• After context-free questions are asked, suggested solutions can be explored


Technique: Brainstorming

• Brainstorming involves both idea generation and idea reduction

• The most creative, innovative ideas often result from combining seemingly unrelated ideas

• Various voting techniques may be used to prioritize the ideas created

• Although live brainstorming is preferred, web-based brainstorming may be a viable alternative


Rules for Brainstorming

• Do not allow criticism or debate• Let your imagination soar• Generate as many ideas as possible• Mutate and combine ideas• Only then do Idea Reduction

– Prune ideas that are not worthy of further discussion– Group similar ideas into one super topic

• Prioritize the remaining ideas


Technique: Storyboarding

• Scripted walkthrough of system activities and/or screen mockups

• Identify the players, explain what happens to them, and describes how it happens

• Make the storyboard sketchy and easy to modify


Technique: Role Playing

• Role playing allows developers to experience the user’s world from the user’s perspective

• Live storyboard or unscripted walkthrough

• Generate system activities and/or screen mockups as you go along


Technique: Requirements Workshop

• Perhaps the most powerful technique for eliciting requirements

• Gather all key stakeholders together for a short but intensely focused period

• Use an outside facilitator experienced in requirements management

• May combine interviewing, brainstorming, storyboards, role playing


Technique: Prototyping

• Partial implementation of a software system, built to help developers, users and customers better understand system requirements

• Focus on the “fuzzy” requirements: poorly defined and/or poorly understood


Reminder: First Assignments Due Next Week!

• Tuesday 11 September, 10am

• Assignments posted on course website

• Submit via CourseWorks

• Individual Development Assignment #1

• Pair Formation

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

https://courseworks.columbia.edu/

http://york.cs.columbia.edu/classes/cs4156/homeworks/IDA-1.html

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


Upcoming Deadlines

• Individual development assignment #2 due September 18th

• Teams announced September 18th • Team project concept due September 25th • Individual development assignment #3 due

October 2nd • Revised project concept due October 9th – first

iteration begins


COMS W4156: Advanced Software Engineering

Prof. Gail Kaiser

[email protected]


mailto:[email protected]


06 september 2007kaiser: coms w4156 fall 20071 coms w4156: advanced software engineering prof. gail...

Documents

coms w4156

discussion of code

incremental model

wellthe waterfall

discussion of prototypingmock

feedback model

educlassescs4156 kaiser

process model usedprototypes