Software Account

Management
S. Ramanathan

Introduction to Account
Management

Account Management Vs. Sales

Management
Sales

Account

Sales process is all about

presenting a product / service
along with its functions &
features to the buyer and hoping
he sees the fit.

Account management is about

selling in a continuum to a
single large account,

The salesperson selects the best

proposition to sell , then presents
or
generates it as a sales
proposition to the prospect and
finally helps (or pushes!) the
prospect to under-stand the fit
between the proposition and the
problem that the prospect has

Account management begins with

under-standing the problem of
the account.
The account management team
then starts generating possible
solutions that can help the
customer and selects the best
option

Focus on vendor offerings

Focus on customer need and

exploring for solution with the
customer

Account Qualification

Customer Lifetime Value

Possibility for strategic alliance
Financial stability
Relationship between organizations
between the senior managements
Over time relationship gets
converted from Basic to Integrated

Program Management
Program: a group of projects
large, complex efforts that combine the delivery of
software elements, new and changed business
models, and overall changes to organizational
structure and capabilities
More complex governing structure
than Project Management

Project Management Vs. Program

Management
Project Management

Program Management

Tactical

Focus on realization of
strategic business objectives

Single function

Cross-functional

Technical
Goals: on-time delivery,
budgetary control and
performance level targets

Managerial and Technical

Goals: Feasibility from
business standpoint

Software Estimation

the art of prophecy is very difficult, especially with respec

to the future
- Mark Twain

What is Estimation?
Attempt to determine how much
Money
Effort (in person months)
Resources
Time

it will take to build a software

It is part of the planning process
It is the things that you do not estimate
that hurt you

Challenges in Estimation

Uniqueness of each project

Changing technology
Lack of homogeneity of project experience
Lack of historical data on projects
Customer requirements expand beyond scope
of functional requirements
Estimation is based on some assumptions which
may change completely once the project starts
Subjectivity in estimation
Organizational pulls

Establishment of Scope
First step in estimation
Coverage of scope

functional requirements
data to be processed
control requirements
performance requirements
constraints
interfaces
reliability requirements

Software Project Estimation

Delay as late as possible
Duplicate based on experience in
similar projects
Decompose into simple tasks and
estimate on experience
Derive use empirical models
There is no silver bullet

estimation gets better as the project progresses.

Source: Boehm, Barry W, Software Engineering

Economics, Prentice-Hall, 1981

 It is not only difficult to estimate a

project in its early stages, it is
theoretically impossible
- Steve McConnel, Software Project Survival
Guide, Microsoft Press, 1998

Improved Estimation with Historical

Data

Project Repository
International Software Benchmarking Standards
Group (ISBSG) maintains information on 1200
projects http://www.isbsg.org.au
Helps with data on project estimation, risk
analysis, productivity and benchmarks
Adv: ready availability of data for
comparison
Disadv: The repository data may not
contain all information about the context,
which if applied to a dissimilar
environment, may lead to wrong results

Decomposition Techniques
Decomposition of the problem to
manageable smaller problems
Two decomposition approaches
Problem decomposition
Process decomposition

Work Breakdown Structure

Hierarchical description of all work that must be done to

meet the requirements of the customer
Developed by the Project Manager in consultation with the
core team
Helps in estimation of the duration of the project, resource
requirement and schedule
Inputs

Project Request Approval Form

Project Overview Statement
Project Approach
Quality Strategy
Business Case

Process

Top Down
Bottom up

Top Down Approach

1.
2.

Identify the objective of the project

Break it into deliverables
100% Rule: sum of the work at the child level must
equal 100% of the work represented by the parent ;
neither less nor more

3.
4.

Break down deliverables into activities

Progressive Elaboration: Successively
decompose into manageable components until
each component is logically distinct
time estimates of these components can be arrived at
with reasonable accuracy
each lowest level of entry will be of duration of 1 10
days

Bottom Up Approach
1. Identify the first level breakdown
2. Divide into as many groups
3. Each group identifies the activities
needed to achieve the first level
breakdown
4. Integrating the group efforts, the
team removes redundant activities
more like brainstorming than an organized approach to
building WBS

Common Activities for Both the

Approaches
5.

Define how each of the component will be

accomplished
6. Check all deliverables have been accounted for
7. Make provisions for reviews and documentation
8. Ensure that testing and training are accounted
for
9. Ensure delivery approval cycles are accounted
for
10. Provide for installation and other associated
implementation activities
11. Verify lower level tasks are necessary and
sufficient for achieving the decomposed task
12. Verify to see each task is clearly defined

Creating A Work Breakdown

Structure

List of deliverables become Level 1

All deliverables should be specified as (adjective) nouns
(eg) (Design) Specification
WBS Entry a generic term for any level, but always with a
deliverable
Decompose levels into component levels: referred by verb
(adjective) noun (eg) Update (Design) Specification
Each level must be logically distinct
Level the number of activities by possible mergers / splits;
ideal 72 activities per level. Balance the breadth and
depth
Identify the risk events and create contingency activities for
them
Define milestones major points of progress with zero
duration refereed by past tense events (eg) Acceptance
Test Completed
Once completed, validate the WBS bottom up

t Projects

WBS is Proper, if

Status / Completion is measurable

Start and End events are clearly defined
Each activity has a deliverable
Time / cost of each task can be easily
estimated
Work assignments are independent: Once
the task has begun, it can continue
uninterrupted without waiting for any need
for additional input

Work Breakdown Dictionary

Project Name WBS Name WBS id
WBS Owner
Start Date
WBS Detail
Deliverable Description
Acceptance Criteria
Assumptions
Resources Assigned
WBS Dependencies
Time
Approved by

Date

Parent id
End date

Basis of Estimate (BOE)

A written justification for the project
estimate and the basis (Planning
assumptions) by which the Project
Manager can predict how changes in the
project landscape will affect the project
plan and cost
Project communication vehicle to increase
the probability of project success
Coverage

Estimating techniques that were used

Participants in the estimation process
Projects that were used for comparison
Historical data that were used for estimation
Confidence level of the estimate

Software Sizing
Whole project: Compare with similar
Project
Processes and tasks
Standard Components (modules, screens,
reports)
LOC or FP or OP

Why Estimate Size?

To measure productivity
To estimate development effort and cost
for cost-benefit analysis
To monitor outsourcing agreements
To dive IS related business decisions
should we retain / retire / redesign
applications?
To normalize other measures such as
defect count

The LOC Method

Easy to measure,
but
Programming language dependent
Penalizes efficient programming
Line itself is not easy to define (Software Engineering
Institute, have published some guidelines in an
attempt to standardize counting)
Is it possible to get detail of line count at the time of
analysis?
Feature to LOC ratio computation is difficult
There are no objective ways of defining LOC / feature
"the use of lines of code metrics for productivity and
quality studies to be regarded as professional
malpractice starting in 1995." - Capers Jones
Measuring software productivity by lines of code is
like measuring progress on an airplane by how much
it weighs." Bill Gates.

FUNCTION POINTS
SOFTWARE COST ESTIMATION

A language independent approach to estimating software

development effort
Developed by Allan Albrecht at IBM: first published in 1979
In the early eighties, the function point technique was
refined and a counting manual was produced by IBM's
GUIDE organization.
The International Function Point Users Group (IFPUG) was
founded in the late eighties
IFPUG produced its own Counting Practices Manual
Despite the refinements suggested in the IFPUG releases,
the guidelines still remain very close to that originally
proposed by Albrecht
Other techniques of function point counting very different
from Albrecht method have also been proposed

Function Point
Measure of functionality derived from
countable measures of information domain
and assessment of complexity, using an
empirical relationship
Function points are a measure of the size
of computer applications and the projects
that build them. The size is measured from
a functional, or user, point of view. It is
independent of the computer language,
development methodology, technology or
capability of the project team used to
develop the application

Conceptual Basis of Function Points

A software application is a defined set of
elementary processes
Two types of elementary processes
Data in motion: transactional functions
External Inputs
External Outputs
External Queries

Data at rest
Internal Logical Files
External Interface Files

Elementary Processes
Information Domain

Functional Requirement

External Input

an elementary process in which data crosses the boundary from

outside to inside. This data may come from a data input screen or
another application. The data may be used to maintain one or more
internal logical files. The data can be either control information or
business information. If the data is control information it does not
have to update an internal logical.

External Output

an elementary process in which derived data passes across the

boundary from inside to outside. Additionally, an EO may update
an ILF

External Query

an elementary process with both input and output components that

result in data retrieval from one or more internal logical files and
external interface files.

Internal Logical File

user identifiable group of logically related data that resides entirely

within the applications boundary and is maintained through
external inputs. Normalized entity types

External interface
File

user identifiable group of logically related data that is used for

reference purposes only. The data resides entirely outside the
application and is maintained by another application. The external
interface file is an internal logical file for another application.

Function Point Model

Application Boundary

EI

Other
app

App
EI

Users

EO

ILF

EO
EQ

EQ
EIF

ILF

Computing Function Points

Parameter Count
Simple Averag Comp
e
lex
Inputs
Outputs
Queries
Files
Interfaces
Total

*
*
*
*
*

3
4
3
7
5

4
5
4
10
7

6
7
6
15
10

=
=
=
=
=

Value Adjustment Factor

General System Characteristic

Brief Description

1. Data communications

How many communication facilities are there

to aid in the transfer or exchange of
information with the application or system?

2. Distributed data processing

How are distributed data and processing

functions handled?

3. Performance

Was response time or throughput required by

the user?

4. Heavily used configuration

How heavily used is the current hardware

platform where the application will be
executed?

5. Transaction rate

How frequently are transactions executed

daily, weekly, monthly, etc.?

6. On-Line data entry

What percentage of the information is

entered On-Line?

7. End-user efficiency

Was the application designed for end-user

efficiency?

Value Adjustment Factor

Contd.
General System Characteristic

Brief Description

8. On-Line update

How many ILFs are updated by On-Line

transaction?

9. Complex processing

Does the application have extensive

logical or mathematical processing?

10. Reusability

Was the application developed to meet

one or many users needs?

11. Installation ease

How difficult is conversion and

installation?

12. Operational ease

How effective and/or automated are

start-up, back-up, and recovery
procedures?

13. Multiple sites

Was the application specifically

designed, developed, and supported to
be installed at multiple sites for multiple
organizations?

14. Facilitate change

Was the application specifically

designed, developed, and supported to
facilitate change?

Computing Function Points

FP = Count Total*{0.65+(0.01*Value
Adjustment Factor)}
Function Point does not have any physical
meaning and only a number

FP Definition Sequence
For a project > 1000 FP

Parameter
Output

Defn. Period
Uncertainty
Within 1 month +/- 40%

Input

Within 2 mths

+/- 20%

Interfaces

Within 3 mths

+/- 15%

Logical files

Within 4 mths

+ / - 10%

Inquiries

Within 5 mths

+ / - 5%

Function Point Sizing Rules of

Thumb
Scope

Class

Type

1. Subroutine

1. Individual software

1. Nonprocedural

2. Module

2. Shareware

2. Web applet

3. Reusable module

4. Single location internal

3. Batch

4. Disposable prototype

5. Multilocation - internal

4. Interactive

5. Evolutionary prototype

7. Timesharing

5. Interactive GUI or webbased

6. Standalone program

9. Internet

6,7. Database

7. Component of system

10. Leased software

8. Client / Server

8. Release of system

12. Marketed commercially

11. Communications

9. New system

13.Outsourced contract

12. Process Control

10. Compound system

14. Embedded
15. Image processing

Raise the sum to

the 2.35 power

16. Multimedia
17. Robotics
18. Artificial Intelligence

Metrics
Collect data from each project on LOC /
FP / Use Case, Effort in person days, Cost,
Documentation in pages, Errors, Defects
Examples of size-oriented metrics:

Errors per KLOC / FP / Use Case

Defects per KLOC / FP / Use Case
Cost per KLOC / FP / Use Case
Page of documentation per KLOC / FP / Use
Case
LOC / FP / Use Case per person month

Backfiring
1 FP equals
128 C statements
107 Cobol statements
50 Java statements

Some Thumb Rules

# pages of documentation = (FP) 1.15

Requirements creep @ avg. rate of 2% per month from design to
coding phase
On an average, software applications will grow by at least 15%
during development
# test cases = (FP)1.2
Defect potential = no. of possible bugs in requirement, design,
source code, user manual, bad fixes = (Total Function Points) 1.25
Schedule in calendar months = (Total Function Points) 0.4. This can
vary from 0.32 (for agile projects) to 0.43 (military software)
Schedule in calendar months = 3.0 * (person-months)0.33 (instead
of 3.0, a range of values from 2.0 4.0 is suggested. With
experience, you can decide the value for your organization)
No. of technical staff (such as analysts, programmers, technical
writers, database administrators) required = Function Points / 150
For project under tight schedule constraints, the denominator can
drop to 100
Technical staff for maintenance projects = Function Points / 1500
(Maintenance includes defect repairs and enhancements up to 10
function points)

Guidelines An Example
Phase

% of total effort

Preliminary study

1 (max. 5 days)

Feasibility study

5-7

Systems Analysis

12-14

Logical design

4-6

Physical design

10-12

Program design

6-8

Coding and testing

18-20

System testing

12-16

Acceptance testing

9-11

Implementation

12-14

Post implementation review

Use Case Point Approach

# Transactions

Type

3 or less

Simple

Weightage
Factor
5

47

Medium

10

>7

Complex

15

Use Case Point Approach

Contd.
Obtain unadjusted use case points
(UUCP) based on the factors
Adjust UUCP to reflect project
complexity and people factors and
get UCP
20 -28 person hours per UCP

Agile Software Development

Requirement in the form of stories
Metric: Story point size measure of
stories
Velocity = no. of story points that can
be developed in an iteration / sprint /
time box
It is observed one story to code takes
about 8 hrs
A typical story point = 2 standard
function point

Software Costing

Types of Cost Estimates

ROM Estimate (Rough Order of Magnitude)

Budgetary Estimates

Provides a ball park estimate

Done very early in the project, sometimes even before the project
is started
Often used by seniors to make project selection decisions
Low accuracy (-25% to +75%)
Lot of buffer built into such estimates coz of the uncertainity
involved
Used to allocate money towards budget
More accurate than ROM
Variation is lower (-10% to +25%)

Definitive Estimate

Much higher accuracy

Often used for estimating final project costs

Cost Estimation Tools and

Techniques

3 basic tools and techniques for cost

estimates:
Analogous or top-down
Use the actual cost of a previous, similar project
as the basis for the new estimate

Bottom-up
Estimate individual work items and sum them to
get a total estimate
Also called activity based costing
Size of work items and the experience of
estimators drive accuracy
Having a detailed WBS helps to develop this

Parametric: use project characteristics in a

mathematical model to estimate costs

Generic Steps in cost

estimation
Detailed activities to be performed Phases,
activity, tasks & sub tasks.
Time for documentation, review, testing, setup,
procurement

Plan for rework changes, defects, iterations

Plan for Staffing
Number, skills, roles against efforts requirements

Plan for Maintenance and Enhancements

Versions, release management
Plan for risks, risk mitigation plans and risk
contingency allowances

SW Project Break-down
Project
Project

Phase
Requirements
Analysis
Design
Coding
Testing
Installation

Activity
Discussions
Collection / Collation
Prototyping

Task

Planning
Architecture /Technology /
Reusability
Macro Design
Detailed Design
Design Review

Phase Activity - TaskSubtask detailing

compliments the sizing
exercise

Code walk thru

Unit Testing
Functional Testing
Integration Testing
Regression testing
Testing Automation
Documentation
Packaging
User Acceptance
Implementation

Test Plan / Scenario /

Case
Test Execution
Defect Removal
Re testing
Iterations

Person-Hour Rate
Work hours per month

160

Average monthly salary

Rs. 60000

Overhead rate

200%

Monthly rate

180000

Hourly rate

Rs. 1125

But estimation is no simple

Technology

Processes

Weak basis
Poor Knowledge

Software
Efforts
{work,
quality,
productivit
y}

Creativity Vs. Repetition

Complexity
Environment

Professionals

Estimates
Project
Size

Project
Attributes

Requirement volatility
Estimation

Schedule
Effort
Cost
Deliverable

Compliments
Conflicts

Plan for Reusability,

standards, processes
Capability Estimation
Commercial
considerations

Costing Errors
Metric Errors
FP or LOC translation, phase % (Large to Small projects -> Coding
% moves up from 18% to 70% while documentation moves down
from 31% to 5%)

Sizing Errors
Activity mapping errors
Scope errors
Production rate errors
Changes non anticipation errors
Critical path errors Project Control errors
Staffing errors skills, knowledge, ramp up
Technology unknowns
Exceptions / emergencies / risk occurrence

Software Cost Models COCOMO

Constructive Cost Model (COCOMO) is
one of the earliest cost models widely
used by the cost estimating community.
COCOMO was originally published in
Software Engineering Economics by Dr.
Barry Boehm in 1981.
COCOMO is a regression-based model
that considers various historical
programs software size and multipliers.

Software Cost Models (contd)

COCOMO
COCOMO requires as input the
projects estimated size in Source
Lines of Code (SLOC).
In addition to SLOC, COCOMO has
scale factors which allow you to
tailor conditions to your project.

Software Cost Models (contd)

COCOMO
Scale factors include:
Development flexibility, architecture, risk, team
cohesion, and process maturity among others.

Additionally COCOMO uses Cost Drivers

grouped in broad categories such as
personnel, product, platform, project etc.
Product Cost drivers include:
required reliability and product complexity.

Personnel cost drivers include:

language, platform, and tool experience

Schedule

COCOMO (contd)
COCOMO defaults to a nominal value for
all factors when model is first used.
Cost estimators must calibrate the model
to the program being estimated to their
specific development environment and
productivity level of staff.
COCOMO uses analogy and parametric
methods based pm a historical,
proprietary database of data submitted
by consortium members. This allows
COCOMO to be compatible with current
design methods and evolving higher
order languages.

Ratings
ostDrivers
Very Low
Productattr
ibutes
Requiredso
ftwarerelia
0.75
bility
Sizeofappli
cationdata

base
Complexity
oftheprod
0.70
uct
Hardwarea
ttributes
Runtimeperfor

mancecons
traints
Memoryco

nstraints
Volatilityof

Low

Nominal

High

Very
High Extra High

0.88

1.00

1.15

1.40

0.94

1.00

1.08

1.16

0.85

1.00

1.15

1.30

1.65

1.00

1.11

1.30

1.66

1.00

1.06

1.21

1.56

COCOMO (contd)
The model makes its estimates of
required effort (measured in
Person-Months) based primarily on
the projects estimate of the
software size (as measured in
thousands of SLOC, KSLOC)):
Effort = 2.94 * EAF * (KSLOC)**E
EAF is the Effort Adjustment Factor
derived from the Cost Drivers and
E is an exponent derived from the
five Scale Drivers.

COCOMO Model output

example

COCOMO Outputs by Phase

Tools for Effort and Cost

Estimation
As of 1999, there are 50 tools available
in the market 40 of which use function
point method
Productivity Manager for Windows and
S.M.A.R.T. Counter are two IFPUG
certified tools

Tools for Effort and Cost

Estimation
SLIM Estimate
Checkpoint
Function Point
Workbench
KnowledgePlan
Price-S
Estimacs
SEER-SEM
Select Estimator
Project Architect

Costar
SoftCost R
System 4
Asset R
SASET
CA-FP Expert
Function Point
Manager
Function Point Mentor
Before You Leap
SEAT
Sfera

Software Pricing

Pricing Models
Fixed bid
Time & Materials
Fixed price per deliverable unit

Fixed Price Contract

Advantages:
Known customer expenditure
Supplier motivation for cost effectiveness

Disadvantages:
Tendency to have higher margin for
contingencies
Difficulties in modifying requirements
Higher cost for changes to offset initial low cost
Quality a casuality to meet fixed cost

Time and Materials Contract

Advantages:
Ease of changing requirements
Lack of price pressure

Disadvantages:
Higher customer liability
Lack of incentives for supplier

Fixed Price Per Unit

Delivered
Advantages:

Customer has a better understanding of

price calculation
Supplier is not forced to bear the cost of
increased functionality
Incentive for supplier to deliver the
functionality in a cost effective manner
Ability to accommodate changes

Disadvantages:
Agreement on the measure for the unit
Ability of the unit to represent all types of
changes
Impact of change may not be uniform
throughout the life cycle

Sliding Scale of Cost

Timing

Cost / FP

Initial

$ 1000

After 3 months

$ 1100

After 6 months

$ 1250

After 9 months

$ 1500

After 12 months

$ 1750

Deletion

$ 250

Project Pricing Factors

Market Opportunity
Resource commitment
Cost estimate uncertainty
Foreign exchange fluctuations
Contractual Terms (e.g. source code
ownership)
Requirements Volatility
Financial Health (e.g. cash flow
considerations)
Pricing to win

At the time of contract

Clarity of deliverables
Formal and complete cost and effort
estimate
Treatment of creeps
Independent assessment of progress
Anticipated quality level
Initial baseline accuracy and fairness

Once the project has started

Budgetary control
Tracking the progress
Cost review along with progress
review
Variance reporting

Cost Budget An Example

Budget Category
Headcount (FTE)
Compensation

Consultant/Purchased
Services

Travel

Depreciation

Rents/Leases
Other Supplies
and Expenses
Total Costs

Estimated Costs
Explanation
13 Included are 9 programmer/analysts, 2
database analysts, 2 infrastructure
technicians.
$1,008,500 Calculated by employee change notices
(ECNs) and assumed a 4% pay increase in
June. Overload support was planned at
$10,000.
$424,500 Expected consulting needs in support of the
Project Accounting and Cascade
implementation efforts; maintenance
expenses associated with the HewlettPackard (HP) computing platforms;
maintenance expenses associated with the
software purchased in support of the BSR
project.
$25,000 Incidental travel expenses incurred in
support of the BSR project, most associated
with attendance of user conferences and
off-site training.
$91,000 Included is the per head share of
workstation depreciation, the Cascade HP
platform depreciation, and the depreciation
expense associated with capitalized
software purchases.
$98,000 Expenses associated with the Mach1
computing platforms.
$153,000 Incidental expenses associated with things
such as training, reward and recognition,
long distance phone charges, miscellaneous
office supplies.
$1,800,000

Proposal Writing

Request for Proposal

Background information
Project purpose and description
Project scope
Criteria of success
Project timeline
Budget
Terms and conditions
Payments, incentives and penalties

Bidder qualification
Standards and tools used
Proposal evaluation criteria and award process
Contact details for future correspondence

Organizing a Proposal
Problem:
What is the problem/need/gap in knowledge to be
addressed?
Objective(s):
What are the proposed outcomes that will address these
problems?
Significance:
Why is it important to accomplish these objectives?
What impact will it have?
Methods:
How will each objective be accomplished? What
activities will take place and when?

Organizing a Proposal
Contd.
Personnel:
Who will carry out each activity?
Equipment/Facilities:
What equipment and facilities are required to carry out each activity?
Budget:
What costs will be involved in the activities, personnel, equipment,
and facilities?
Evaluation:
How will it be measured whether or not the objectives were
accomplished? Sponsors, are more focused on measurable outcomes.
Address your plans for assessment and evaluation.

General Contents of a
Proposal
Title
choose a simple title that explains (to the
extent possible) what you plan to do. There is
no need for cute or catchy titles or fancy
acronyms

Abstract
A brief statement of the project objectives,
procedures, and methods of evaluation and
dissemination. The abstract should not
exceed two hundred and fifty words in length.

General Contents of a Proposal

Contd.
Statement of the Problem
This section is a background and rationale
for the project. It should establish the
need and importance of the project

Objectives
Identification of anticipated outcomes of
the project in clearly specified terms.

Solution Architecture
How the objective is proposed to be met

Proposal Template

Company introduction
Services & Technology
<Main Portion>
Terms and conditions

Main Portion
Introduction
Background
Needs statement
Scope of work in scope and out of scope activities
Assumptions
Objective business goals addressed

Proposed technical approach

Requirements
Components of Solution
Quality assurance plan
Key risks. Dependencies and assumptions
Risk management plan

Implementation plan
Team structure with roles
Customers responsibilities
Implementation approach
Testing strategy and approach
Training and knowledge transfer approach

Expected project results

Measure of success

Deliverables and Schedule

Cost and payment schedule
Post-implementation support
Activities covered
Support centre accessibility
Severity levels and response times
Support escalation
Change management process for solution enhancement i(specify members of change control board)

Appendices
Resource profiles
Case studies of successful implementations

Software Documentation

Usage Scenarios Use

cases

A use case specifies behavior of a system or part of a system and is a description

of a set of sequence of actions, including variants that a system performs to yield
an observable result of value to an actor.

It describes WHAT a system does but does not specify HOW it does.

Validateuser

Sensors::Calibrate
location

Actors

Basically users of the system

Actors are external entities (people or other systems) who
interact with the system to achieve a desired goal.
Use Cases are what happens when actors interact with the
system
An actor uses the system to achieve a desired goal
By recording all the ways our system is used ("cases of use"
or Use Cases) we accumulate all the goals or requirements
of our system.
Therefore a use case is a collection of possible sequences of
interactions between the system under discussion and its
Users (or Actors), relating to a particular goal.
The collection of Use Cases should define all system
behavior relevant to the actors to assure them that their
goals will be carried out properly
Any system behavior that is irrelevant to the actors should
not be included in the use cases.

A Use Case Diagram

Top Level Use Case

Top level use case should make

sense for the actors who
interact with it to request only
that service
of your system in a single
session

To model the requirements of a system

Establish the context of the system by identifying the actors that surround it.

For each actor consider the behavior that each expects or requires the system to
provide

Name these common behaviors as use cases

Factor common behavior into new use case that are used by others;

Factor variant behavior into new use cases that extend more main line flows

Model these use cases, actor, and their relationships in a use case diagram

Adorn these use cases with notes that assert nonfunctional requirements

Sample Scenario
System: Claims payment by an
Insurance Company
Primary Actor: The claimant
Goal: Claimant getting paid for an
accident
Condition: Everything is in order

Scenario

Outcome: Insurance company pays claim

1. Claimant submits claim with substantiating data.
2. Insurance company verifies claimant owns a valid policy (failure
here probably means goal failure)
3. Insurance company assigns agent to examine case.
4. Agent verifies all details are within policy guidelines. (an
interaction between the agent and secondary actors)
5. Insurance company pays claimant (implies all preceding goals
managed to pass)

Extensions

1a. Submitted data is incomplete:

2a. Claimant does not own a valid policy:

3a1. (What does the insurance company do here?)

4a. Accident violates basic policy guidelines:

2a1. Insurance company declines claim, notifies claimant, records all this, terminates
proceedings.

3a. No agents are available at this time

1a1. Insurance company requests missing information

1a2. Claimant supplies missing information

4a1. Insurance company declines claim, notifies claimant, records all this, terminates
proceedings.

4b. Accident violates some minor policy guidelines:

4b1. Insurance company begins negotiation with claimant as to degree of payment to

be made.

The greatest value of the use case does not lie in the main scenario, but in alternative
behaviors

Variations
1. Claimant is

a. a person
b. another insurance company
c. the government

5. Payment is

a. by check
b. by interbank transfer
c. by automatic prepayment of next installment
d. by creation and payment of another policy

When is a use case diagram said to be wellstructured?

When it

Is focused on communication one aspect of a systems static use case view

Contains only those use cases and actors that are essential to understand that aspect

Provides details consistent with its level of abstraction; you should expose only
those adornments that are essential to understanding.

Is not so minimalist (simple) as to misinform the reader about semantics that are
important.

Principles of Drawing Use Case

Diagrams

Give it a name that communicates its purpose

Lay out its elements to minimize lines that cross

Organize elements spatially so that behaviors and roles that are semantically close are
laid out physically close

Use notes and color as visual cues to draw attention to important features
of your diagram

Try not to show too many kinds of relationships. If you have any complicated
relationships, take these elements to another diagram.

Release Management

Release Management Issues

How do we ensure that we only release products that

have been thoroughly tested as part of the whole
product?
How can we change an operational product without the
risk of it malfunctioning after the change?
How can we keep a check on which of our customers or
sites has what version of the product?
How do we install a major enhancement of a product?
If the people who developed the product are not to be
the people who install the product, how do they know
how to do it?
Do we issue the complete product for every update or
just the changed components?
Do we issue a complete new operating manual or only
the changed pages?

Release Control
Job of Project Support
Functions
Identify the products to be included in the release;
Ensure that all the required products have reached a status
which allows them to be released into live operation;
Report on any required products which do not have a
current approved status;
Build a release package;
List the changes since the previous release and the error
reports or requests for change solved by the release;
Distribute the release;
Be able to recreate any baseline (i.e. past release) if a site
reports problems on a release;
Know which site has what version and variant of the
product.

Release Identifier
when the new release of the product
provides changed functionality - the baseline
number is incremented up to the next whole
number (e.g. 2.1 becomes 3.0);
when the new release of the product
provides fault fixes only - the issue number is
incremented by one (e.g. 1.4 becomes 1.5);
optionally when the new release of the
product consolidates many (e.g. 20) minor
changes - the baseline number is
incremented up to the next whole number.

Release Package Contents

the release name and identifier;

the release date;
the person/section/group with responsibility for the release.
This will normally be the contact for any installation problems.
a brief description of the release, whether it is a complete or
partial release, what has caused the release, what is its
purpose, the major benefits over previous releases;
a list of prerequisites for the installation of the release;
a list of all the Issue Reports answered by this release;
any customization steps. If the release can be tailored in any
way, this describes the possibilities and lists the steps to be
carried out;
notification of any dates when support for previous releases
will cease;
an acknowledgement to be completed and returned by the
client on successful completion of the installation

Expectation Management

Expectation Management: A Gateway Key to Project Success

Client Satisfaction

What is Expectations Management?

I want an elephant to be arranged for
a marriage at home
Situation 1: You deliver a sick
elephant on the marriage day
Situation 2: You told me one week
before the marriage that you can
only arrange only for a horse and
arranged a horse on the marriage
day

So What is Expectations
Management?
They are not requirements, they are much broader, much deeper
They are your clients vision (or perception) of a future state or
action, usually unstated but is critical to your success.
They are a primary measure of your success.
In your clients mind, satisfaction is how close youre come to their
expectations, not necessarily how close you were to the wording in
the contract, or scope of work, or better yet the performance
criteria.
In some instances, it may not even be the actual results of the
project but the process with which you arrive there.
A good project management practitioner should be able to shape
and influence shaping and influencing stakeholders expectations
such that variance between project performance (outcome) and
stakeholders expectations are within acceptable limits.
Project success is in the eyes of the beholder

When to Manage
Expectations?
Expectation Management should begin at the point of first
contact between the vendor and prospective customer

How to Manage
Expectations?

Expectation Management Matrix

(EMM)

EMM Rules
1. For any project, one must record
priorities P1, P2 and P3 within nine
available cells
2. No row may contain more than one
priority; a single measure of success
must have only one priority
designation
3. No column may contain more than
one priority

EMM for Moon Mission

EMM Challenges
Project Manager does not establish priorities; he
or she merely enforces the rules of the matrix
Only the system owner sets the priorities
Managers to be educated on the reason for
priorities and they cannot maximize all
Intelligent compromises instead of guesswork
Those who do not believe in the principles (of the
matrix) will eventually know the truth. You do not
have to believe in gravity, but you will hit the
ground just as hard as the person who does
Dr. Friedlander

Managing Expectations
Documentation as a Tool?
Traditional approach is to rely on documentation
let us make sure we document every
conceivable aspect of the system in a functional
requirements specification. Have the customer
sign off the document. Then we are covered,
right?
users do not understand documentation
Documentation may help as a contractual
milestone, but does not serve the purpose of
managing user expectations

Influencing Expectations
1. Establish trust: It is not awarded; you must earn it
2. Communicate / educate, Communicate / educate,
Communicate / educate: communicate the big picture
and the details: the more your clients know the
better; through meetings, training, reports.
3. Explain why: it worked in my last three projects
(experience) it would cost less / work well if we did
(partnership)
4. Influence in private: People do not like to change
their mind / admit their mistakes in public
5. Show and sell: proof-of-concept, prototype
6. Balance the give and take

A Framework for Managing

Expectations