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

Transactional focus. Relationship as a consequence of Sales

Relationship building necessary prerequisite

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 Managerial and Technical

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

Goals: Feasibility from business standpoint

Software Estimation

the art of prophecy is very difficult, especially with respect to the future

- Mark Twain

What is Estimation?

• Attempt to determine how much

it will take to build a software• It is part of the planning process

MoneyEffort (in person months)ResourcesTime

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

Source: Boehm, Barry W, Software Engineering Economics, Prentice-Hall, 1981

estimation gets better as the project progresses.

• 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 Approach1. Identify the objective of the project2. 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. Break down deliverables into activities4. Progressive Elaboration: Successively decompose into

manageable components untileach component is logically distincttime estimates of these components can be arrived at with reasonable accuracyeach lowest level of entry will be of duration of 1 – 10 days

Bottom Up Approach

1. Identify the first level breakdown2. Divide into as many groups3. Each group identifies the activities needed to

achieve the first level breakdown4. 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 accomplished6. Check all deliverables have been accounted for7. Make provisions for reviews and documentation8. Ensure that testing and training are accounted for9. Ensure delivery approval cycles are accounted for10. Provide for installation and other associated

implementation activities11. Verify lower level tasks are necessary and sufficient for

achieving the decomposed task12. 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 7±2

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

WBS Format for System Development 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 DictionaryProject Name WBS Name WBS id Parent id

WBS Owner Start Date End date

WBS Detail

Deliverable Description

Acceptance Criteria

Assumptions

Resources Assigned

WBS Dependencies

Time

Approved by 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 ProcessesInformation 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

UsersILF

EIF

App

ILF

Other app

EI

EO

EQ

EI

EO

EQ

Application Boundary

Computing Function Points

Parameter Count Simple Averag

eComplex

Inputs * 3 4 6 =Outputs * 4 5 7 =Queries * 3 4 6 =Files * 7 10 15 =Interfaces * 5 7 10 =Total

Value Adjustment FactorGeneral 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 ILF’s 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 user’s 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

Parameter Defn. Period UncertaintyOutput 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%

For a project > 1000 FP

Function Point Sizing Rules of ThumbScope 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 web-based

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

16. Multimedia

17. Robotics

18. Artificial Intelligence

Raise the sum to the 2.35 power

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 1

Use Case Point Approach

# Transactions Type Weightage Factor

3 or less Simple 5

4 – 7 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) 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 Budgetary Estimates

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-downProjectProject

PhaseRequirementsAnalysisDesignCodingTestingInstallation

ActivityDiscussionsCollection / CollationPrototyping

Planning

Architecture /Technology / ReusabilityMacro DesignDetailed DesignDesign Review

Code walk thruUnit TestingFunctional TestingIntegration TestingRegression testingTesting Automation

DocumentationPackagingUser AcceptanceImplementation

Task

Test Plan / Scenario / CaseTest ExecutionDefect RemovalRe testingIterations

Phase – Activity - Task- Subtask detailing

compliments the sizing exercise

Person-Hour RateWork hours per month 160

Average monthly salary Rs. 60000

Overhead rate 200%

Monthly rate 180000

Hourly rate Rs. 1125

But estimation is no simple• Requirement volatility• Estimation

– Weak basis– Poor Knowledge

• Creativity Vs. Repetition• Complexity

– Compliments– Conflicts

• Plan for Reusability, standards, processes

• Capability Estimation• Commercial considerations

Software Efforts {work,

quality, productivity}

Technology

Environment

Processes

Professionals

ProjectSize

ProjectAttributes

Estimates- Schedule- Effort- Cost- Deliverable

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 (cont’d)COCOMO

• COCOMO requires as input the project’s 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 (cont’d)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 (cont’d)

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

ost Drivers

Ratings

Very Low Low Nominal HighVery High Extra High

Product attributes

Required software reliability 0.75 0.88 1.00 1.15 1.40

Size of application database 0.94 1.00 1.08 1.16

Complexity of the product 0.70 0.85 1.00 1.15 1.30 1.65

Hardware attributes

Run-time performance constraints

1.00 1.11 1.30 1.66

Memory constraints 1.00 1.06 1.21 1.56

Volatility of the virtual machine environment

0.87 1.00 1.15 1.30

Required turnabout time 0.87 1.00 1.07 1.15

Personnel attributes

Analyst capability 1.46 1.19 1.00 0.86 0.71

Applications experience 1.29 1.13 1.00 0.91 0.82

Software engineer capability 1.42 1.17 1.00 0.86 0.70

Virtual machine experience 1.21 1.10 1.00 0.90

Programming language experience

1.14 1.07 1.00 0.95

Project attributes

Application of software engineering methods

1.24 1.10 1.00 0.91 0.82

Use of software tools 1.24 1.10 1.00 0.91 0.83

Required development schedule

1.23 1.08 1.00 1.04 1.10

COCOMO (cont’d)

• The model makes its estimates of required effort (measured in Person-Months) based primarily on the project’s 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 CostTiming 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 ExampleBudget Category Estimated Costs Explanation

Headcount (FTE) 13 Included are 9 programmer/analysts, 2database analysts, 2 infrastructuretechnicians.

Compensation $1,008,500 Calculated by employee change notices(ECNs) and assumed a 4% pay increase inJune. Overload support was planned at$10,000.

Consultant/PurchasedServices

$424,500 Expected consulting needs in support of theProject Accounting and Cascadeimplementation efforts; maintenanceexpenses associated with the Hewlett-Packard (HP) computing platforms;maintenance expenses associated with thesoftware purchased in support of the BSRproject.

Travel $25,000 Incidental travel expenses incurred insupport of the BSR project, most associatedwith attendance of user conferences andoff-site training.

Depreciation $91,000 Included is the per head share ofworkstation depreciation, the Cascade HPplatform depreciation, and the depreciationexpense associated with capitalizedsoftware purchases.

Rents/Leases $98,000 Expenses associated with the Mach1computing platforms.

Other Suppliesand Expenses

$153,000 Incidental expenses associated with thingssuch as training, reward and recognition,long distance phone charges, miscellaneousoffice supplies.

Total Costs $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.

 Validate user

 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:

– 1a1. Insurance company requests missing information– 1a2. Claimant supplies missing information

• 2a. Claimant does not own a valid policy: – 2a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.

• 3a. No agents are available at this time – 3a1. (What does the insurance company do here?)

• 4a. Accident violates basic policy guidelines: – 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 well-structured?When it

• Is focused on communication one aspect of a system’s 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.

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

Principles of Drawing Use Case Diagrams

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 client’s 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 client’s mind, satisfaction is how close you’re 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 guessworkThose 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 it2. 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, prototype6. Balance the give and take

A Framework for Managing Expectations