cs 564 – on requirements lecture 4
DESCRIPTION
CS 564 – On Requirements Lecture 4. QSE Lambda Protocol. Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing, Quality Estimates ICED-T Trade-off Analysis. Requirements Specification Spec. Project Title, Revision Number and Author - PowerPoint PPT PresentationTRANSCRIPT
CS 564 – On RequirementsLecture 4
QSE Lambda Protocol
• Prospectus
• Measurable Operational Value
• Prototyping or Modeling
• sQFD
• Schedule, Staffing, Quality Estimates
• ICED-T
• Trade-off Analysis
Requirements Specification Spec
1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Operational Value4. Description5. Feature List including ICED T and Simplified QFD
analysis6. Interfaces7. Constraints8. Change Log and Expected Changes9. Responses to the unexpected10. Measurements11. Glossary12. References
Software Business Models
Mass MarketMass Market NicheNicheGeneral
Product CentricProduct Centric CustomCustomSoftware
In-HouseIn-House OutsourceDevelopment
OutsourceDevelopment
Requirements •Functional – Industry
•Configurable
•Functional – Company specific
Software vs. Hardware Income Statement
Hardware Software ConsultingProduct Centric Custom
($M) ($M) ($M)
Revenue $300 $300 $300Costs Cost of Sales $190 $20 $150 Amortization $0 $60 $0 Total Incurred Costs $190 $80 $150
Margin $110 $220 $150% Margin 37% 73% 50%
Expenses Development $10 $100 $50 Marketing/Sales $65 $65 $65 Distribution $10 $0 $0 G & A $5 $5 $5 Total Expenses $90 $170 $120
Other Income $0 $5 $0
Operating Income $20 $50 $30
OROS 7% 17% 10%
Capitalization/Amoritization Intervals
Research & Development Expense
Technical Feasibility
Product Realization Expense
General Availability
Capitalization
Marketing Expense
Amoritization
Asset Balance=0
Income Statement Elements
Line Item Hardware Software Consulting
Revenue Hardware Revenue and Maintenance
Licensing, services and maintenance
Services and Maintenance
Cost of Sales Manufactured and purchased componentsDedicated labor to assemble
Purchased componentsInstallation services
Labor related to deliverables
Amortization Writing off capitalized R&D
Margin Revenue minus Costs Revenue minus Costs Revenue minus Costs
Development Expenses
R&D to develop hardware R&D to develop software R&D to develop practices and non-billable hours
Marketing & Sales Sales and marketing program costs
Sales and marketing program costs
Sales and marketing program costs
Distribution Cost of distribution
G&A Overhead Overhead Overhead
Other Income Co-marketing income
Operating Income Revenue minus Costs minus Expenses
Revenue minus Costs minus Expenses
Revenue minus Costs minus Expenses
Mapping Requirements to a Framework
• ICED T• Intuition• Consistent• Efficient• Durable
• Thoughtful
• UML Framework• Use Cases• Structure • Business Rules
PMO Models
Requirements
ElicitationReports
Use Cases
Use Cases
Static Structure
Static Structure
Activity Model
Activity Model
ICED T Mappings
• Ratings• 1= ‘Worst I have ever seen’• 2 = ‘Worse than Average’• 3 = ‘Average, like most other systems’• 4 = ‘Better than Average’• 5 = ‘Best I have ever seen’
Simplified QFD (scale 0 to 10)
Features/
Functions
Track Delivery Trucks
.On-line Customer Inquiry
Credit Check
1. Easy to Order
0 9 3
2. 10% Less Inventory
0 0 0
3. 20% Profit Increase
3 9 9
4. Speed Product Introduction
0 9 0
Total 3 27 12
Systems Engineering
Systems Engineering
“An interdisciplinary approach and means to enable the realization of successful systems.”
– INCOSE (The International Council on Systems Engineering)
System:
“A group of interacting, interrelated, or interdependent elements that together form a complex whole.”
– NGE Project (Next Generation Education Project)
A systems engineer has smart friends.
A Framework for Systems Analysis
FormulatingThe
Problem
Identifying,Designing,
AndScreening
TheAlternatives
BuildingAnd
Using ModelsFor
PredictingThe
Consequences
ComparingAnd
RankingAlternatives
Initiation
Boundaries & Constraints
Objectives
Values and Criteria
Alternatives
ForecastingFuture
Contexts
Consequences (Impacts)
Communicate Results
Formulation Research Evaluation and Presentation
Source: Miser, Hugh J., Quade Edward S., Handbook of Systems Analysis Overview of Uses, Procedures,
Applications, and PracticesNorth-Holland, 1985
Source: Miser, Hugh J., Quade Edward S., Handbook of Systems Analysis Overview of Uses, Procedures,
Applications, and PracticesNorth-Holland, 1985
Systems Engineer
CustomerNeeds
CustomerNeeds SolutionsSolutions
UnderstandDomain
Knowledge
UnderstandDomain
Knowledge
CommunicateDomain
Knowledge
CommunicateDomain
Knowledge
Customer Domain Development Domain
Some SE Foundation Concepts
• System Architecture Planning and Business Planning are not separate disciplines, but are a part of Systems Engineering
• Good Front End decisions of necessity are not serial, but a cascaded series of iterative decisions, at various levels, that optimize across:
• Customer Driven Requirements• Architecture requirements and needs (Function, Form, Economy and Time)• Business Strategies, sales needs and related considerations
• The difficulty in balancing these factors cannot be over-emphasized • There are many complex, inter-relating issues to solve• Zealots of various kinds can force particular views, losing balance
• In the final analysis, the above is an art, and any and all insights/data, etc. can help (even clairvoyance)
Work Areas for Systems EngineersPrimary work products:
• Gathering of customer needs and technology opportunities• Opportunity analysis, problem definition and objectives selection• Solution synthesis and analysis• System architecture and alternative selection including developing• business cases• Product specification including requirements generation • and documentation• Development planning to select implementation plan• Project feedback assessment and documentation
Interdisciplinary Skills:• People • Business• Financial• Technical
• • •
Concept of Systems Engineering Tiers
• Layers or Tiers• Many Applications
• Business
• Product Definition
• Interrelates the Artifacts
• Related to Craft Skill Model• Apprentice• Novice• Journeyman• Master
Tier 1Tier 1
Tier 2Tier 2
Tier 3Tier 3
Tier 4Tier 4
Context, Concepts, Framework, Architecture
Use Cases, Scenarios
Detailed Requirements
Business Cases, Customer Value Proposition
Skill Level
Master
Novice
Requirements Engineering Success
• Do the Right Thing• Evaluate Opportunities
• Customer Benefits• Business Case• Feasible Project
• Do It the Right Way• Valid Requirements
• Focused on Customer Value• Customer Agreement• Clearly communicated to Development, etc.
Requirements Specification Spec
1. Project Title, Revision Number and Author2. Scope and Purpose of the system3. Measurable Operational Value4. Description5. Feature List including ICED T and Simplified QFD
analysis6. Interfaces7. Constraints8. Change Log and Expected Changes 9. Responses to the unexpected10. Measurements11. Glossary12. References
Required Measurements
• Function Points
• Logical Consistency from sQFD metrics
• Stability = feature changes/month
• ICED T
Key Question
• What’s the problem?
Engineering Economics
=V0(1+i) =V1(1+i) =V2(1+i)
=V0(1+i)2 =V1(1+i)2
=V0(1+i)3 FV=PV(1+i)n
PV =V0 V1 V2
o 1 2 3
V3
n
FV=Vn
Time-Value of Money
o 1 2 3 n
Value of a Cash Flow
Annual Benefit
Net Present Value Annual
BenefitAnnual Benefit
Cost Cost Cost
Engineering Economics
PV =
a1=a0(1+i) a2=a0(1+i)2
o 1 2 3 n
Value of an Annuity
a a a a
a3=a0(1+i)3 an=a0(1+i)n
a
(1+i)1+
a
(1+i)2+
a
(1+i)3+
a
(1+i)n+… …
PV =(1+I)n -1
i(1+i)na PV =
As n a
i
Engineering Economics
o 1 2 3 n
Value of a Cash Flow
Annual Benefit
Net Present Value Annual
BenefitAnnual Benefit
Cost Cost Cost
Interval 1/(1+I)**n Benefit Costs Cash FlowPresnt Value Interest
($K) ($K) ($K) ($K) 5%0 1.000 $500 ($500) ($500)1 0.952 $2,500 ($2,500) ($2,381)2 0.907 $2,000 ($2,000) ($1,814)3 0.864 $5,000 $500 $4,500 $3,8874 0.823 $5,000 $500 $4,500 $3,7025 0.784 $5,000 $500 $4,500 $3,526
Net Present Value $6,420
The Origin of Discounting
• Samuelson showed in 1937 under certain assumptions that the value today of something received k years from today is its value when received in year k discounted by the factor 1/(1+i)k, where i is a positive number
• He specifically made statements that• The model had no demonstrated descriptive validity with
respect to empirical data• The model had no prescriptive validity as a method of
determining social welfare
• Nevertheless, Samuelson’s constant rate discounting is now the method prescribed by the U.S. government and others for making life cycle cost comparisons
Source: Discounting Models for Long-TermDecision Making, Kenley, C. Robert, Armstead,
Conference on Systems Integration,Stevens Institute of Technology,
March 13, 2003
Source: Discounting Models for Long-TermDecision Making, Kenley, C. Robert, Armstead,
Conference on Systems Integration,Stevens Institute of Technology,
March 13, 2003
Problems of Constant Rate Discounting
• Discrete Time• A cost occurring at the beginning of an
interval is discounted the same as a cost on the last day of an interval
• Preference Stationarity • Delay can change preference implying that
the model is inaccurate
Source: Discounting Models for Long-TermDecision Making, Kenley, C. Robert, Armstead,
Conference on Systems Integration,Stevens Institute of Technology,
March 13, 2003
Source: Discounting Models for Long-TermDecision Making, Kenley, C. Robert, Armstead,
Conference on Systems Integration,Stevens Institute of Technology,
March 13, 2003
A Live Experiment (Question 1)
14 Oct2005
2:00 PM
15 Oct2004
2:00 PM
ALERNATIVE A ALTERNATIVE B
• What is your preference: A or B?
Source: Kenley, ArmsteadSource: Kenley, Armstead
14 Oct.2005
2:00 PM
15 Oct.2006
2:00 PM
ALERNATIVE A ALTERNATIVE B
A Live Experiment (Questions 2 & 3)
• Now what is your preference: A or B?• What is your preference on 14 October 2104?
Source: Kenley, ArmsteadSource: Kenley, Armstead
Definition: Preference Reversal
• When A is preferred to B at one time but B is preferred to A at another (later) time
• For instance, one might prefer 1 candy bar today to 2 candy bars tomorrow, but one would surely prefer 2 candy bars in one year and one day to 1 candy bar in a year
• Constant rate discounting does not allow preference reversal!
Source: Kenley, ArmsteadSource: Kenley, Armstead
Discounting Models
Discounting M odel Name
Time Perception Function (t)
Discount Factor w t at Time t
Constant Rate t
1 1 i t
Exponential
h
ln (1 i)t
1 e h t
Hyperbolic
h
glog 1 i (1 gt )
1 1 gt hg
Relative
h log 1 i (1 t )
1 1 t h
Proportional
log 1 i (1 gt )
1 1 gt
Source: Kenley, ArmsteadSource: Kenley, Armstead
Constant
• If the time difference between receipt of 1 candy bar and 2 candy bars is constant, the preferences remain the same• If 1 candy bar 1 day from today is
equivalent to 2 candy bars 2 days from today, then
• 1 candy bar 1 year from today is equivalent to 2 candy bars 1 year and 1 day from today
• 1 candy bar 4 years from today is equivalent to 2 candy bars 4 years and 1 day from today
Relative Rate Discounting
• The preference relationship is relative in that if ratio of the delay is constant then the ratio of the equivalent rewards is constant• If 1 candy bar 1 day from today is
equivalent to 2 candy bars 2 days from today, the 1 candy bar 1 year from today is equivalent to 2 candy bars 2 years from today
Preference Implication for Proportional Discounting
• The preference relationship is proportional in that the acceptable amount of delay is proportional to the amount of reward• A delay of 1 year for 1 candy bar is equivalent to a delay of 4 years for 4
candy bars
Source: Kenley, ArmsteadSource: Kenley, Armstead
Research Summary
• Empirical studies all agree that proportional discounting best fits data
• Proportional discounting allows for preference reversals
• Proportional discounting can be derived from the same type of axiomatic rationale as constant discounting
• Constant discounting has an inherent 40-year maximum
Source: Kenley, ArmsteadSource: Kenley, Armstead
Selecting A Proportional Discount Parameter
• At year 30, a proportional model with parameter g = 7.2% is equivalent to a constant discount rate of 3.9% applied to cost and benefits incurred in year 30
• 3.9%is the OMB-approved rate for 30-year internal government project tradeoff analyses
• This provides an “anchor point” for proportional discounting to match the OMB guidance
1
1 0.072 30
1
1.03930
Years 3 5 7 10 30
OMB Approved Constant Discount Rate 0.021 0.028 0.030 0.031 0.039
Source: Kenley, ArmsteadSource: Kenley, Armstead
Opportunity Analysis
Opportunity Analysis
• Opportunity Valuation• Customer Value• Willingness to pay• Market Size
• Strategic Fit• Business Direction• Product Direction
• Manageable Risks• Incremental • Bounded• Exit Strategies• Core Competency Match
Idea Filtering
Business & TechnologyStrategy
Business & TechnologyStrategy
TechnologyDrivers
MarketDrivers
Customer
TechnicalProspectus
TechnicalProspectus
Idea Generation
OpportunityDefinition
Feasibility/Sizing
OpportunityEvaluation
Gate
Concept Concept
ConceptValidation
Opportunity Analysis
Technical Prospectus• Basis for the Concept of
Operations document• Product Concept• Constraints• Trade-Off Analysis
• Support the Preliminary System Design• Product Concept• Sizing Model
• Support Business Case• Customer Benefit Model• Market Sizing
TechnicalProspectus
TechnicalProspectus
Concept ofOperations
Concept ofOperations
CustomerBenefitModel
CustomerBenefitModel
Market Sizing
Market Sizing
Sizing Model
Sizing Model
System Design
System Design
ProductConcept
ProductConcept
BusinessCase
BusinessCase
Defining the Problem
• Understand Domain• Processes• Operations Strategy• Costs
• Critical Problem• Root Cause of Costs• Pareto Analysis
• Define Scope• Identify Constraints• Market Realities
• Values• “Good” Solution
UnderstandDomain
Processes,Operations,& Expense
Processes,Operations,& Expense
Focus onCritical
Problem
DefineValues
Define Scope
Get the Big Picture
• Management Concerns• New Services• Reduce Debt
• Must get OPEX Savings
• Operations represents ~35% of the total expense before taxes
• About $14 per subscriber per month
• Software can often be used to reduce operations expenses
• Expense savings flow directly to the bottom line
• Examples?• Web Access• Bundling of activities• Reduction of Back Office
CATV Operations Opportunity
CATV Expenses
37%
13%11%
17%
7%
15% Content & Interconnect
Marketing & Sales
Custpmer Service
Technicians
G&A
Debt Service
Workflow Model
TroubleEntry
TroubleEntry
ServiceChangeServiceChange
DispatchDispatch
STB ActivationSTB Activation
100 Customer Calls from 10 Subscribers
10 Orders
4 Orders85 Calls
4.5 Tickets
8.5 Dispatches
0.2 Orders
Bulk Loading
8.5 Dispatches
90 Orders
10 Rework
Subscriber
InquiryInquiry
5 Tickets
10 Orders
ScreenScreen
Formulating a Solution
• Objectives• Customer Key Strategies
• Process Approach• Mechanization• Business Process Automation• Business Process
Improvement• Business Process Re-
Engineering
• Constraints• Business• Industry Practices
• Boundaries• Scope of the System
SystemDefinition
Objectives
ProcessInnovation
Constraints
Boundaries
PMO Workflow Model
Need to Capture Key Activities & Costs
Model where you have impact Lower call volume
Web Svcs Lower Dispatch rate
Correlation of troubles
Customer Self-Install
Need to cross check with other data
Overall Expense Consistent with Labor
Allocation
Operations Labor
49%
7%6%
21%
17% 0%
CSRs Dispatch Clerks Line Techs
New Install Techs Svc/Mtce Techs Contract Install
Activity/Task
Work Content
(hrs)Rate ($/hr) Cost ($)
Work Occur Automation ReWorkContent Factor(hr)
Customer SvcsBilling Inq 0.05 4.00 0.0% 0.5% 0.20 $50.00 $10.05Svc Inq 0.05 4.00 0.0% 2.0% 0.20 $50.00 $10.20New Acct & Video Svc 0.30 0.20 0.0% 2.0% 0.06 $50.00 $3.06New Data Svc 0.30 0.20 0.0% 2.0% 0.06 $50.00 $3.06Vertical Svc 0.10 0.40 0.0% 2.0% 0.04 $50.00 $2.04Disconnect 0.10 0.20 0.0% 0.5% 0.02 $50.00 $1.01
Trouble Report 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25Svc Inq 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25
DispatchScreen Troubles 0.10 0.50 0.0% 0.0% 0.05 $50.00 $2.50Loading 0.05 0.85 0.0% 0.0% 0.04 $50.00 $2.13
TechnicianDispatch Install Video 0.50 0.20 0.0% 5.0% 0.11 $100.00 $10.50Dispatch Disc Ord 0.50 0.20 0.0% 20.0% 0.12 $100.00 $12.00Disp Cust Install Data 0.50 0.20 90.0% 5.0% 0.02 $100.00 $1.50Trouble 0.50 0.45 0.0% 5.0% 0.24 $101.00 $23.86
STB ActivationUpdate STB 0.20 0.00 0.0% 2.0% 0.02 $50.00 $1.00
Labor per Subscriber per Year 1.23 $85.40
Activity Cost (hrs)
FMO Operations
• Key System Attributes• Web to offload
Customer Services
• Correlation of troubles to equipment outages
• Customer STB Turn-Up
• Savings• ~$10 per sub
per year
Activity/Task
Work Content
(hrs)Rate ($/hr) Cost ($)
Work Occur Automation ReWorkContent Factor(hr)
Customer SvcsBilling Inq 0.05 4.00 25.0% 0.5% 0.15 $50.00 $7.55Svc Inq 0.05 4.00 25.0% 2.0% 0.15 $50.00 $7.70New Acct & Video Svc 0.30 0.20 5.0% 2.0% 0.06 $50.00 $2.91New Data Svc 0.30 0.20 5.0% 2.0% 0.06 $50.00 $2.91Vertical Svc 0.10 0.40 25.0% 2.0% 0.03 $50.00 $1.54Disconnect 0.10 0.20 25.0% 0.5% 0.02 $50.00 $0.76
Trouble Report 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25Svc Inq 0.05 0.50 0.0% 0.0% 0.03 $50.00 $1.25
DispatchScreen Troubles 0.10 0.50 25.0% 0.0% 0.04 $50.00 $1.88Loading 0.05 0.85 0.0% 0.0% 0.04 $50.00 $2.13
TechnicianDispatch Install Video 0.50 0.20 65.0% 5.0% 0.04 $100.00 $4.00Dispatch Disc Ord 0.50 0.20 0.0% 20.0% 0.12 $100.00 $12.00Disp Cust Install Data 0.50 0.20 90.0% 5.0% 0.02 $100.00 $1.50Trouble 0.50 0.45 0.0% 5.0% 0.24 $100.00 $23.63Disp Cust Install Video 0.5 0.00 0.0% 5.0% 0.00 $100.00 $0.00STB Shipping 0.60 0.13 0.0% 0.0% 0.08 $50.00 $3.90
STB ActivationUpdate STB 0.20 0.80 98.0% 2.0% 0.01 $50.00 $0.32
Labor per Subscriber per Year 1.09 $75.21
Activity Cost (hrs)
Case Study: PV of Benefits
o 1 2 3 5
Present Value
a a a a
(1+i)n -1
i(1+i)nPV = a
4
a
What’s a?
6M customer deployment - $10/customer/year
a = $60M per year
(1+.05)5 -1
.05(1+.05)5= $60M = $259.7M
Or = $43 per Sub
Relative Project Costs
Relative Cost Range x
1.25x
1.5x
2x
4x
0.8x
0.5x
0.8x
0.67x
Phases and Milestones
Feasibility
Concept of Operation
Plans and Requirements
Requirements Specifications
Product Design
Product Design Specifications
Detailed Design
Detailed Design Specifications
Development and Test
Accepted Software
Motivation for Value-Based Software Engineering
• Current Software Engineering Methods are basically value neutral• Every requirement, use case, object, and defect is equally
important• Object oriented development is a logic exercize• “Earned Value” systems don’t track business value• Separation of concerns: SE’s job is to turn requirements into
verifiable code• Practitioners escape from blame
• Value-neutral SE methods are increasingly risky• Software decisions increasingly drive system value• Corporate adaptability to change achieved via software
decisions• System value-domain problems are the chief sources of
software project failures Source: Value-Based Software Engineering, Boehm, Barry, USC
CSE Annual Research Review,March 18, 2003
Source: Value-Based Software Engineering, Boehm, Barry, USC
CSE Annual Research Review,March 18, 2003
7 Key Elements of VBSE
1. Benefits Realization Analysis2. Stakeholders’ Value Proposition Elicitation
and Reconciliation3. Business Case Analysis4. Continuous Risk and Opportunity
Management5. Concurrent System and Software
Engineering6. Value-Based Monitoring and Control7. Change as Opportunity
Source: Value-Based Software Engineering, Boehm, Barry, USC
CSE Annual Research Review,March 18, 2003
Source: Value-Based Software Engineering, Boehm, Barry, USC
CSE Annual Research Review,March 18, 2003
DMR/BRA* Results Chain
Initiative
* DMR Consulting Group’s Business Realization Approach
Outcome OutcomeContribution Contribution
AssumptionOrder to delivery time is an important buying decision
Reliable service is an important buying criteria
Implement New Network Operation
Reduce Time to Provision Service
Improve MTTR
Reduced order processing cycle
Reduced MTTR
(Intermediate Outcome)
Improved service perception
Increased Video Sales
Case Study: Repair Operations System
• In the 1970’s, New York Telephone was experiencing a service crisis. Customers had complained to the PUC about NYTel’s service level for telephone repair.
• Complaints ranged from long repair times, lost trouble tickets, and missed appointments.
• NYTel was facing fines for poor performance.• NYTel believed that computerization of the
repair records would enable them to improve service and to clearly report on their performance.
Repair Center Circa 1970
Subscriber
Line Card Tub File
TroubleTickets
Customer calls Repair Bureau
Repair Service Attendant creates a Trouble Ticket Screener picks
up Trouble Ticket
Screener retrieves line card for telephone line and screen trouble
Trouble referred to dispatch
Trouble referred to test
Trouble referred to Field Technician
SwitchingCenter
Trouble referred to switching
Repair Center Operations Circa 1970
• Centers cover approximately 25K lines• Trouble rate is 1/line/yr.• Average Busy Hour is unknown but a busy day for a 25K line office is 135 troubles.• Most troubles are taken between 9 and Noon.
• Most Personnel at $40K/yr loaded salary• Testers are at $60K/yr loaded salary• Screening function removes tester load.
• RSA function• One of the customer complaints is that RSB phones are not answered.• Hold times for a trouble report are 2 minutes.• NYT has set an objective to answer calls within 30 seconds in the busy hour.
• Screeners perform a variety of functions• Complete troubles from the field during the busy end of day closeout.• Update Line Record file for service order and cable maintenance activity
• Order activity is 1 order/line/year
• Track and complete tickets referred to switching or cable maintenance.
• Management is a critical issue• Cannot find TR when customer wants current status.• Difficult to tell how mis-matched force is to load.
• Customer Environment• Environment is largely manual records.• Exception is there is a locally developed service order processor that can provide a batch file of
completed service orders• The service order will contain services the customer ordered and plant assigned to those services.
Workflow Model
TroubleTicket
Creation
TroubleTicket
CreationScreeningScreening TestingTesting
DispatchDispatch
SwitchingSwitching
200 Customer Calls
100 Troubles
72 Troubles
Network Systems Western Electric
STARNET
STARNET
STARNET
STARNET
100 Troubles
20 Troubles
57 Troubles
8 Troubles
37 Troubles
Subscriber
3 Troubles
5 Troubles
30 Troubles Test OK
5 Troubles Closed
AM Load
PM Load
Assignment
• Define objectives, operations strategies, and a solution concept for NYT’s problem
• Construct a benefit model for the solution.
• Determine the NPV for the benefits.• Use a term of 5 years and 8% interest.
Automation of Provisioning
Provisioning Functions
1. Accept, edit and process service orders.
2. Interpret service order -- translate it to a request for “so many pairs at such-and-such an address.”
3. Assign the pairs -- find unused pairs for the service; rearrange existing telephone company pairs as needed.
4. Assign central office equipment -- connect the assigned pairs to the main distributing frame.
5. Request telephone company people to make the needed connections if none already exist.
6. Activate dial tone.
7. Rearrange telephone company plant as new pairs are installed in anticipation of neighborhood growth.
8. Assign new pairs when repair is needed
Goal: Flow-Through Provisioning
Technicians
Cost of Work Today Technician
New Costof Work
SystemAdministrator
Cost of SystemOperation
Cost of System
Hardware
Software
Training
Standards ReuseProcesses
ToolsTechnology
$100m/yr
Developer
Benefits of Automation
Organization Structure
SYSTEM REQ.S
ALGORITHMS
TRANSACTIONPROJECTIONS
FEATUREENGINEERING
ARCHITECTURE
TRAFFICENGINEERING
ENGINNERINGREPORTS SUPPORT/ OPERATIONS
- COMPUTER CENTER - DEVELOP.MACHINE - TEST MACHINE
SOFTWAREDEVELOPMENT
HUMAN FACTORS
DEVELOPMENT
SOFTWAREMANUFACTURE INTEGRATION
TO SITES
Project A: Order Reading and Analysis Software
Size of Prototyping Effort: 12K lines of C Code (10% of final system module) Purpose: Find a method for order reading and analysis, applicable to variable formats. Duration and Staff of Prototype:
Four people for eight months.
Experience:
1. Final requirements based on prototype results.
2. Alerted developers' to the possibility of a having a tunable system.
3. Early evaluation of functional decomposition and performance showed bottlenecks in the dispatcher.
4. Eliminated the possibility of reusing code from another project.
5. Prototype was thrown away due to decomposition and performance problems.
Project B: Outside Plant Data Base System
Size of Effort: 5% of 500K line of source code. Purpose:
To evaluate database structures for an outside plant data and to experiment with approaches to handling multiple future states of equipment usage. Duration: Three people for 15 months.
Experience:
1. A data base structure using hyper graph theory was invented.
2. An algorithm for handling both time-driven and event-driven assignments was invented
3. The prototype became the basis for the production code.
4. UNIX flat files were used to model loop plant by way of a directed graph.
5. The prototype showed database portability from Unix to the Mainframe.
Why bad things happen to good systems
• Customer buys working software product.
• System works with 40-60% flow- through
• Developers make requested changes
BUT
• Customer refuses critical Module
• Customer demands 33 enhancements and allows data corruption
• Developers misgauge extent of changes
CONCEPT of Operations TemplateTable of Contents
• 1. Scope • 2. References• 3. Definitions • 4. Concept of Operations Document Guide • 4.1 SCOPE (Clause 1 of the ConOps Document)
• 4.1.1 Identification (1.1 of the ConOps Document).
• 4.1.2 Document Overview (1.2 of the ConOps Document).• 4.1.3 System Overview (1.3 of the ConOps Document
• 4.2 REFERENCED DOCUMENTS (Clause 2 of the ConOps Document).
• 4.3 THE CURRENT SYSTEM OR SITUATION (Clause 3 of the ConOps Document).
• 4.3.1 Background, Objectives, and Scope (3.1 of the ConOps Document).
• 4.3.2 Operational Policies and Constraints (3.2 of the ConOps Document).
• 4.3.3 Description of the Current System or Situation (3.3 of the ConOps Document).
• 4.3.4 Modes of Operation for the Current System or Situation (3.4 of the ConOps Document).
• 4.3.5 User Classes and Other Involved Personnel (3.5 of the ConOps Document).
• 4.3.6 Support Environment (3.6 of the ConOps Document).
• 4.4 JUSTIFICATION FOR AND NATURE OF CHANGES (Clause 4 of the ConOps Document).
• 4.4.1 Justification for Changes (4.1 of the ConOps Document).
• 4.4.2 Description of Desired Changes (4.2 of the ConOps Document).
• 4.4.3 Priorities Among Changes (4.3 of the ConOps Document).
• 4.4.4 Changes Considered but not Included (4.4 of the ConOps Document).
• 4.4.5 Assumptions and Constraints (4.5 of the ConOps Document).
• 4.5 CONCEPTS FOR THE PROPOSED SYSTEM (Clause 5 of the ConOps Document).
• 4.5.1 Background, Objectives, and Scope (5.1 of the ConOps Document).
• 4.5.2 Operational Policies and Constraints (5.2 of the ConOps Document).
• 4.5.3 Description of the Proposed System (5.3 of the ConOps Document).
• 4.5.4 Modes of Operation (5.4 of the ConOps Document).• 4.5.5 User Classes and Other Involved Personnel (5.5 of
the ConOps Document).• 4.5.6 Support Environment (5.7 of the ConOps Document).
• 4.6 OPERATIONAL SCENARIOS (Clause 6 of the ConOps Document).
CONOPS Template• 4.7 SUMMARY OF IMPACTS (Clause 7 of the
ConOps Document).• 4.7.1 Operational Impacts (7.1 of the ConOps
Document).• 4.7.2 Organizational Impacts (7.2 of the ConOps
Document).• 4.7.3 Impacts During Development (7.3 of the
ConOps Document).
• 4.8 ANALYSIS OF THE PROPOSED SYSTEM (Clause 8 of the ConOps Document).
• 4.8.1 Summary of Improvements (8.1 of the ConOps Document).
• 4.8.2 Disadvantages and Limitations (8.2 of the ConOps Document).
• 4.8.3 Alternatives and Trade-offs Considered (8.3 of the ConOps Document).
• 4.9 NOTES (Clause 9 of the ConOps Document).
• 4.10 APPENDICES (Appendices of the ConOps Document).
• 4.11 GLOSSARY (Glossary of the ConOps Document).
• Assignment Template• Objectives• Problem Description
• PMO Description
• Operations Strategies• Solution Description
• FMO Description
• Solution Architecture
• System Features
• Customer Business Case• Customer Benefits
• Customer Costs
• Operations Modelb• Use Cases
• Transaction Model
• Business Case• Potential Market
• Income Statement