View
43
Download
0
Category
Preview:
Citation preview
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
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
Recommended