CS48720-1/39

Illinois Institute of Technology

CS487

Software Engineering

David A. Lash

CS48720-2/39

Project Elements

The planning & monitoring & control of people, process and event as software evolves

– 2-4 developers working together may not need much but ... What about 30-40, 300?

– Organized customer communication, right development process, estimated effort, quality checkpoints, on-going monitoring of tasks

– Output is project plan with set(s) of tasks.– Manage, People, Product, Process and Project

CS48720-3/39

Problem

What is the appropriate level of rigor? What, if any, standards apply? Software Scope

– Context. How does this item fit into a larger picture

– Information objective. What is the customer going to see.

– Function and performance. How is the software going to process the

information.

CS48720-4/39

People

All people who work in the development process are not interchangeable.

Many people find it objectionable to be called a resource.

Any time there are more than 1 person working to solve a problem, an organization is recommended

CS48720-5/39

Development Team

What is teamwork?– Joint action by a group of people, in which

individual interests are subordinated to group unity and efficiency; coordinated effort, as of an athletic team.

Team size about 4 people. Requires minimal training for the leader.

Each individual should have a unique primary function i.e. leader, librarian, developer, tester.

Periodically switch functions to cross train.

CS48720-6/39

Development Team Organization

Democratic decentralized – no traditional

leader. Works best when the average

experience is 15 years +. Consensus decisions

Controlled decentralized – a defined leader

with secondary leaders. Multiple teams.

Controlled Centralized – Managed by a team

leader. Good for a cross section of people.

Lead gets top-level decisions and internal

coordination

CS48720-7/39

Process

Selecting the right process?– Waterfall – Traditional

Im plem entation

Specification

Requirem ent

Design

Evaluation

Specification

Executable

Report

Release

Error Correction occursin phase in which the

defect was introduced.

O utput of theprevious phase of

developm ent

CS48720-8/39

Process

– Incremental – Solves a number of problems– Spiral – Must be adopted at the enterprise level.

CS48720-9/39

How do you evaluate process?

Are you using the process correctly?

Are you using the correct process?

What can you do better?

CS48720-10/39

Capability Maturity Model

Developed and controlled by the Software Engineering Institute (SEI)

What is the CMM? Arbitrary Not a process Develop for the DOD to evaluate software

contractors. Being adopted by a number of regulators. Defines activities that should be going on. Arranged to make easy to progress through

the 5 levels.

CS48720-11/39

CMM - Review

1. Chaotic - Productivity and Quality are based on individual

effort. No control

2. Repeatable - Requirements Management, Project

Planning, Quality Assurance, Configuration Management,

Subcontractor management

3. Defined - Organization Process Focus, Organization

Process Definition, Training Program

4. Managed - Quantitative Process Management, Software

Quality Management

5. Optimizing - Defect Prevention, Technology change

management, Process change management

CS48720-12/39

Project Planning

What are the tasks necessary for this project?How do these tasks relate to each other?

Planning and scheduling are different:

–Planning defines the tasks, personnel and equipment necessary to deliver the product.

–To determine personnel requirements you must estimate the size of each task.

–Planning is done at the beginning of the project when you know the least about the problem

CS48720-13/39

Estimating

How long is the project going to take?

First, how long is are the tasks going to take?

CS48720-14/39

Estimating

Done early in the process high degree of error

Can only accurately estimate the next step.

Must re-plan at the beginning of each phase.

Establish size metric.

Estimation requires– Experience building this specific application– Knowledge of the Environment– History of similar projects

CS48720-15/39

General Estimation Formula

CEVBAE )(

Where

E is one person effort

A, B and C are empirically derived constants

EV is an estimation of some measure of size

The values of A & B are calibrated for local environment using regression analysis and realdata.

CS48720-16/39

Three-point

Three-point or expected value

Where

Sopt - Optimistic Estimate

Sm - Most-likely Estimate

Spess - Pessimistic Estimate

EV - Estimation Variable

6/)4(pessmoptSSSEV

CS48720-17/39

Three-point

For example, assume to build a software module. Have some LOC estimates:

– optimistic - 4600– most likely - 6900– pessimistic - 8600

– (4600 + 6900*4 + 8600)/6 = 6800

Can also be useful for time to complete

6/)4(pessmoptSSSEV

CS48720-18/39

Function Points

Good method for IT projects. Use Feature Points for embedded and systems projects

An estimation technique that uses the types of I/O for a problem to determine the size of the project

Called an early measure of size

Function Points convert directly to KLOC

CS48720-19/39

Function Points

Method– Count of Information elements

Input files Output files Inquiry transactions Logical files External interfaces

– Total “complexity” factors

CS48720-20/39

Function Point Counting

Element Ct Rate Result

Inputs X3 4 6

Outputs X4 5 7

Inquires X3 4 6

Files X7 10 15

Interfaces X5 7 10

Unadjusted Total

CS48720-21/39

Function Points Calculation

]01.065.0[ iunadjustedestimateFFPFP

•Where: - FP unadjusted = previous calculation - Fi = sum of complexity adjustment values based on subjective ratings from 0-5 on 14 complexity items: - 0 - no influence

- 1 - incidental- 2 - moderate- 3 - average- 4 - significant- 5 - Essential

CS48720-22/39

Complexity Factors

Factor Range EstimateDatacommunications

0 to 5

Distributed functionsPerformanceobjectivesHeavily usedconfigurationTransaction rateOn-line data entryEnd-use efficiencyOn-line updateComplex processing

CS48720-23/39

Complexity Factors

Factor Range EstimateReusability 0 to 5Installation easeOperational easeMultiple sitesFacilitate changeTotal InfluenceFactors

CS48720-24/39

COCOMO Estimation COnstructive COst Model - BB[89] COCOMO II BB[96] Uses function points, KLOC or object points (A BB

funct PT like metrics with different elements) A hierarchy of estimation models for prototype,

requirements established and post-architecture stages– Basic - Compute development effort as a function of

size in KLOC– Intermediate - Compute development effort as a

function of size and cost drivers (HW, people)– Advanced - Intermediate version plus assessment of

cost driver impact on each step (e.g., analysis design, architecture)

CS48720-25/39

COCOMO Project Types

Organic

– In-house development

– Small teams with extensive application experience

– Characteristics Stable development environment Minimal need for innovative data

processing Low premium on early completion

CS48720-26/39

COCOMO Project Types Semidetached

– One of two types of projects1. An intermediate level of the project2. A mixture of the organic and

embedded– Characteristics

Team members have an intermediate level of experience

Team has a wide mixture of experienced and inexperienced people

Team members have experience related to some aspects of the system under development, but not others

CS48720-27/39

COCOMO Project Types

Embedded– Not limited to our current definition of

embedded meaning firmware, but also includes large scale turn-key system

– A major distinguishing factor is a need to operate within tight constraints

– Require a high degree of rigor

CS48720-28/39

COCOMO: Basic

bdEbcD

bbKLOCbaE

Where

E = Effort in person months

D = Chronological months

CS48720-29/39

COCOMO: Basic

Type ab bb cb db

Organic 2.4 1.05 2.5 .38

Semi-detached 3.0 1.12 2.5 .35

Embedded 3.6 1.20 2.5 .32

CS48720-30/39

COCOMO: Intermediate

Type aI bI

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20

CS48720-31/39

COCOMO: Intermediate

bdEbcD

IbKLOCIaE

XEAF

Where

E = Effort in person months

D = Chronological months

EAF = Effort Adjustment Factor - based on subjective rating from very low to extra high on 15 project attributes

CS48720-32/39

Effort Adjustment Cost Factors

Cost Driver Very Low

Low Normal High Very High

Extra High

Product Attributes Required Software Reliability

0.75 .88 1.0 1.15 1.40

Database Size .94 1.0 1.08 1.16 Product Complexity 0.70 .85 1.0 1.15 1.30 1.65

Computer Attributes Execution time constraint

1.0 1.11 1.30 1.66

Main storage constraint

1.0 1.06 1.21 1.56

Virtual machine volatility

.87 1.0 1.15 1.30

Computer turnaround time

.87 1.0 1.07 1.15

CS48720-33/39

Effort Adjustment Cost Factors

Cost Driver Very Low

Low Normal High Very High

Extra High

Personnel Attributes Analyst capabilities 1.46 1.19 1.0 .86 .71 Application experience 1.29 1.13 1.0 .91 .82 Programmer capability 1.42 1.17 1.0 .86 .70 Virtual machine experience 1.21 1.10 1.0 .90 Programming language experience

1.14 1.07 1.0 .95

Project Attributes Use of modern programming practices

1.24 1.10 1.0 .91 .82

Use of software tools 1.24 1.10 1.0 .91 .83 Required development schedule

1.23 1.08 1.0 1.04 1.10

CS48720-34/39

COCOMO example

Suppose used three-point analysis to estimate 33,200 LOC.

Using basic model get

– E = 2.4(KLOC)**1.05

– -2.4(33.2)**1.05

– 96 person months

Duration would be

– D = 2.5E**.38

– 2.5(95)**.38

– 12.3 months

Number of people = N=E/D N=96/12.3 = 8

bdEbcD

bbKLOCbaE

CS48720-35/39

Project Estimation Problems

No Requirements

No Designs

What is a KLOC?– 1000 lines of source code

Are all definitions of a line of code the same?

CS48720-36/39

Project Scheduling and Tracking

When will the project finish?Where is the project now?

CS48720-37/39

Project Scheduling

Project Scheduling

– Adding resources and personnel to establish a list of dates that monitor the development process

– The last completion is when the project is complete

– Adding more personnel will make it later. It also can change a projects profile

– It is always better to be early than late

CS48720-38/39

Project Scheduling Methods

PERT/CPM Charts– Calculate the path with the least amount of

slack Slack is the amount of time between

when a task can begin and must begin

Timeline Charts

CS48720-39/39

Project Tracking

Get status in a timely manner– Weekly at a low level– Monthly at a high level

Time sheet status reports– Separate time into project and non-project– Project time bill to specific task not project,

category or charge code

To avoid 90% complete for 80% of the project. Use Earned Value to determine % completed

CS48720-40/39

Project Tracking

Earned Value tells you where you are based on the completed tasks of your plan

Earned Value = task / project * 100

Example:– In a 1000 hour project, a 15 hour task is 1.5%

of the project. When it completes it adds 1.5% to the completion

Projected Earned Value tells you where your plan should be

100)(

CumulatedActualPlan

ActualPE