Life Cycle Objective LCO Life Cycle Plan LCP and Feasibility Rational Description FRD

1
Life Cycle Objective (LCO)Life Cycle Plan
(LCP)andFeasibility Rational Description (FRD)

• CS577a
• Fall 2001

2
Life Cycle Objective (LCO)Life Cycle Plan(LCP)
3
Outline

• Software Planning Guidelines
• Motivation
• Software Project Plans
• - General Outline
• - Content of Sections

4
Problems With Computer System Acquisition and Use
in U.S. Government, 1965-1976
1
Source GAO Report FGMSD-77-14
5
Project Plans May Look Complicated,
But They Arent!

• Just Answer the Simple Questions
• - Why?
• - What?
• - When?
• - Who?
• - Where?
• - How?
• - How Much?
• - Whereas?

Objectives Milestones Products Responsibilities
Approach Resources Assumptions
6
Objectives of Software Development

• Deliver a computer program?
• Deliver a correct computer program?
• Deliver a correct, maintainable computer program?
• Make winners of key stakeholders
• Operators procedures, facility preparation
• Users, Operators, Maintainers data conversion,
  training, transition procedures, support
  capabilities

7
(No Transcript)
8
COCOMO II PM Estimates and CS 577 Rough Team Size
(for risk assessment, not precise planning)

• 1 CS 577 Team Member 2 COCOMO II Person
  Months
• (EST-Most Likely from display)
• 1 CS 577 TM (12 weeks)(12 project
  hours/week) 144 proj-hr
• 2 COCOMO II PM (2)(152 hr/PM)(.66project
  hr/total hr)(.72 in CS 577) 144 proj-hr
• .66 of day spent doing project work (see
  Figure)
• 72 of effort in Elaboration and Construction
  stage

9
1. Objectives (Why?)

• 1.1 Purpose
• Provide feasible management approach for
• meeting system goals
• Basis for Project Control
• - Make Best Use of People, Resources
• - Provide Evidence That Developers Know What
  Theyre Doing

10
1.1 Purpose of the Life Cycle Plan Document

• Describe the purpose of the document, and the
  intended audience
• To serve as the basis for controlling the
  project's progress in achieving the software
  product objectives.
• To help make the best use of people and resources
  throughout the development cycle.
• To provide evidence that the developers have
  thought through the major development issues in
  advance (proactive development).

11

• 1.2 Assumptions
• Conditions Necessary to Meet Plans
• - Otherwise, Renegotiate
• Examples
• - Requirements Stability
• - Schedule Stability
• - Continuity of Funding
• - Customer-Furnished Items
• On-Schedule, Acceptable
• Customer Response Time on Approvals
• Other external dependencies (Hardware, COTS,
  other projects)
• 1.3 References

12
2. Milestones and Products (What? When?)

• Overall Life Cycle Strategy
• Detailed Schedule of Deliverables
• Detailed Milestones and Schedules

13
2.1 Overall Life Cycle Strategy

• Describe overall approach
• Choice of process model(s) used and major life
  cycle stages, phases and milestones
• Nature and phasing of the planned prototypes
• Nature and phasing of the successive increments
  to be developed (if applicable)
• Top-level milestone charts and activity networks
  showing the sequence of major products and
  activities.

14
Process Model Decision Table
15
Incremental Model
16
Entire Life Cycle Model
17
Process model for CS 577

• Engineering Stage
• Inception Phase (LCO)
• WinWin Spiral cycle for LCO
• LCO Architecture Review Board review
• Elaboration Phase (LCA)
• WinWin Spiral cycle
• LCA Architecture Review Board review
• Production Stage
• WinWin Spiral Cycle
• Risk-driven Waterfall Cycle
• Transition Readiness Review

18
Process model for CS 577 (continued)

• Transition Phase
• Release Readiness Review
• Support Stage (Customer responsibility)
• Release 1
• Release Readiness Review
• Release 2
• Release Readiness Review

19
2.2 Phase Milestones and Schedules

• Provide more detailed milestone charts and
  activity networks
• For each increment, indicate
• Completion of integration, of product test, and
  of acceptance test
• Major dependencies on development activities, on
  other increments, on facilities, etc.
• Milestones showing the overall order in which
  components are integrated, and the intermediate
  stages of increment and acceptance testing.
• How these are synchronized with milestones for
  preparation of test drivers, facilities, etc...
  for the various increments.

20
Management Checkpoints
MAJOR MILESTONES
Initial Operational capability milestone
Strategic focus on global concerns of the entire
software project
Minor Milestones
Tactical focus on local concerns of current
iteration
Status Assessment
Periodic synchronization of stakeholder
expectations
21
(No Transcript)
22
Workflow Balance over the Life Cycle
23
CS 577 Typical Software Process
INITIAL SUBMITTAL
RLCA
IOC
TESTING BEGINS
WATERFALL-TYPE
CONSTRUCTION BEGINS
LCO
LCA
EARLY PROTOTYPE
SPIRAL CYCLE
SPIRAL CYCLE
24
(No Transcript)
25
Example Overall Life Cycle Strategy
From Hispanic Digital Archive LCP The proposed
amount of flexibility. Therefore, we propose to
use the evolutionary development as our software
engineering process as suggested by the Process
Model Decision Table. Further, we propose to use
the WinWin Spiral Model as it is understood
fairly well by the team members and system
envisages a moderately understood set of
requirements to be met with a low degree of
robustness but with a high is supported by the
Center for Software Engineering, University of
Southern California. The schedules for project
activities have been estimated using COCOMO II
post-architecture model.
26
Phases Milestones and Schedules

• Measurable milestones
• - Not Get team thinking about GUI
• - But Obtain team consensus GUI
• Specific schedule dates
• Gantt charts
• Calendar-oriented tasks lists
• Task dependencies optional
• Activity networks/PERT charts
• - Task dependencies explicit

27
Phase Deliverables and Completion Criteria

• Describe for each Phase
• The Deliverable
• The Exit or Completion Criteria

28
Example Phase Deliverables and Completion
Criteria
2.2.1 Inception Phase During this phase initial
understanding of the desired system must be
accomplished. This is achieved by defining the
scope of the project so all stakeholders are in
concurrence. Feasibility analysis and
prioritization of the tasks must also be done
here. 2.2.2 Elaboration Phase During this
phase prototyping must demonstrate the
architectures feasibility and stability. Risks
and plans to minimize risk must also be assessed
and developed in this phase. Additionally an
appropriate development schedule should be
created. Furthermore, cost estimates must also be
conceived here. Moreover, an operational impact
analysis must be completed to observe how useful
the proposed would be to the customer and user.
29
Example Project Schedule
Figure . High Level PlagueWare Project Schedule
30
Example Detailed Schedule
31
4. Approach (How?)
4.1 Monitoring and Control 4.1.1 Closed loop
feedback control 4.1.2 Reviews 4.1.3 Status
Reporting 4.1.4 Risk Monitoring and Control 4.2
Methods, Tools, and Facilities 4.3 Configuration
Management 4.4 Quality Assurance
32
4.1 Risk Management

• Identify major sources of risk in the software
  development project, and show how the project
  will address, monitor, and resolve these sources
  of risk.
• System Priorities (FRD 3.1) identified optional
  requirements that can be left out in the case of
  schedule slippage

33
4.1 Risk Management (continued)

• For every critical risk, you can indicate
• Description
• Potential Damage to schedule and stakeholders
• Actions to Mitigate Risk
• Contingency Plan
• Change in Status
• Different point of view from FRD
• Risk assessment and feasibility of mitigation
  approach
• (later in FRD) Risk Exposure (Probability of
  unsatisfactory outcome) x (Loss if unsatisfactory
  outcome)

34
Example Risk Management
4.1.1 Personnel Description Team member
departure. Potential Effects Team resources will
be stretched due to a lack of personnel. As
result the project could fall behind schedule.
Avoidance or Containment Plan To avoid this
desperate situation it is the job of the project
leader to maintain and monitor team felicity. If
team member happiness is low the potential for
desertion will be high. Thus is becomes vital for
the project manager to ensure the morale of all
the members of his team. Similar to
hand-holding of the customer, the project lead
must do the same with his staff members. A
manager must have the ability of discernment to
identify the problem and the patience to mend the
problem.
From Team 4s LCA
From Team 12s LCA
35
4.4 Quality Assurance Functions

• Documentation and Code Standards
• Standards Compliance Monitoring
• Plans Policies Compliance Monitoring
• Review Test Monitoring
• Corrective Action Monitoring
• Verification and Validation
• QA is everyones job
• --but people need reminders

36
4.7 Status Monitoring and Control

• Describe techniques, procedures, and reports to
  be used in tracking project progress vs. plans
  and expenditures vs. budgets. Include, as
  appropriate
• Summary Task Planning Sheets
• Earned Value Status Reports
• Project Expenditure Summaries
• Cumulative Milestone Progress Reports
• PERT/ COST Systems
• Budget-Schedule-Milestone Charts
• Personnel Loading Charts
• Detailed Expenditure vs. Budget Reports.

37
Life Cycle Objective (LCO)Feasibility Rationale
Guidelines(FRD)
38
Outline

• Objective and Motivation
• Content
• Audience and Participants
• Document Outline
• Section Guidelines

39
Objective

• Ensure feasibility and consistency of other LCO,
  LCA package components
• OCD, SSRD, SSAD, LCP, Prototype
• Demonstrate viable business case for the system
• Identify shortfalls in ensuring feasibility,
  consistency, and business case as project risk
  items for LCP

40
Pass/Fail Condition

• The feasibility rationale covers the key
  pass/fail question
• If I build this product using the specified
  architecture and processes, will it support the
  operational concept, realize the prototyping
  results, satisfy the requirements, and finish
  within the budgets and schedules?

41
The Need For Feasibility

• 1. A commercial customer specified a natural
  language interface for an otherwise simple query
  system. The project was cancelled after the
  natural language interface caused a factor-of-5
  overrun in project budget and schedule.
• 2. A government customer specified a 1-second
  response time for an extremely large transaction
  processing system. Meeting this requirement
  involved a custom architecture and a 100M
  project. The customer authorized a prototyping
  activity, which determined that 90 of the
  transactions needed only 4-second response time.
  With this performance requirement, a
  commercial-technology-based solution was achieved
  for 30M.
• 3. A commercial customer specified a project to
  fully digitize a set of corporate records via
  scanning and optical character recognition. The
  resulting cost escalated by a factor of 10 after
  if was discovered that the records included many
  hard-to-capture tables, charts, and graphs.

42
Need for Feasibility Rationale
100M
Arch. A Custom many cache processors
50M
Arch. B Modified Client-Server
Original Spec
After Prototyping
5
1
2
3
4
Response Time (sec)
43
Content

• Business Case Analysis
• Satisfactory (Win-Win) return on investment
• Consistency and Feasibility Rationale
• If we build to this architecture,
• We will support the operational concept,
• Be consistent with the prototypes,
• Satisfy the requirements,
• And stay within the budgets and schedules in the
  plan

44
Audience and Participants

• Primary audience ARB members
• Key system stakeholders
• Experienced peers
• Technical Specialists in critical areas
• Also valuable to stakeholders outside ARB
• Project manager responsible for content
• OCD author should prepare business case
• All stakeholders responsible for consistency and
  feasibility via Win-Win negotiations
• Agreements can be contingent on demonstration of
  feasibility

45
Outline

• 1. Introduction
• 1.1 Purpose of the Feasibility Rationale Document
• 1.2 References
• 2. Product Rationale
• 2.1 Business Case Analysis
• 2.1.1 Development Cost Analysis
• 2.1.2 Transition Cost Estimate
• 2.1.3 Operational Cost Estimate
• 2.1.4 Maintenance Cost Estimate
• 2.1.5 Estimate of Value Added and Return on
  Investment

46
Outline (Continued)

• 2.2 Requirements Satisfaction
• 2.2.1 Operational Concept
• 2.2.2 Project Requirements
• 2.2.3 Capability Requirements
• 2.2.4 Interface Requirements
• 2.2.5 Level of Service Requirements
• 2.2.6 Evolution Requirements
• 2.3 Stakeholder Concurrence

47
Outline (Continued)

• 3. Process Rationale
• 3.1 System Priorities
• 3.2 Process Match to System Priorities
• 3.3 Consistency of Priorities, Process and
  Resources
• 4. Project Risk Assessment
• 5. Analysis Results
• 5.1 Product Features
• 4.2 Commercial-Off-the-Shelf Solutions
• 6. Appendix

48
1. Introduction

• Describe the purpose of the document, and the
  intended audience
• For a commercial system, this would involve a
  business case analysis demonstrating an
  acceptable financial Return-On-Investment (ROI).
• For a research and education support system, the
  rationale would be expressed in terms of
  improvements in research and educational
  effectiveness as expressed by the users

49
1.1 Purpose of the Feasibility Rationale document

• To demonstrate that a system built using the
  specified architecture and life cycle process
  will
• Satisfy the requirements
• Support the operational concept
• Remain faithful to the key features determined by
  the prototype
• Be achievable within the budgets and schedules in
  the life cycle plan

50
1.1 Purpose of the Feasibility Rationale Document
(continued)

• To rationalize development decisions in a way the
  prime audience (the customer and users) can
  understand
• To enable the customers to participate in the
  decision process and to express their
  satisfaction with the product

51
1.2 References

• Provide complete citations to all documents,
  meetings and external tools referenced or used in
  the preparation of this document
• Useful for consistency checking and traceability

52
2. Product Rationale

• Rationale for the product being able to satisfy
  the system specifications and stakeholders (e.g.
  customer, user).
• Should be consistent with
• Development costs (from LCP)
• SSRD and SSAD for Requirements satisfaction

53
2.1 Business Case Analysis

• Describe the impact of the product in mainly
  monetary terms.
• How much does it cost to develop and to operate?
• How much added value does it generate?
• How high is its return on investment?
• Non-monetary factors may be also decisive. For
  instance, added value can include the improved
  quality of the service provided by the product.

54
2.1.1 Development Cost Analysis

• Provide a summary of the full development cost,
  including hardware, software, people, and
  facilities costs.
• Proof that schedule is enough to deliver
  required capability
• Should be consistent with Budgets in LCP

55
2.1.2 Transition Cost Estimate

• Rough estimate of costs which accumulate during
  transition of the product into production use
  (e.g. training)
• Operational and support software
• Data preparation, COTS licenses
• Operational readiness testing
• Site preparation
• Facilities, equipment, supplies

56
Transition Costs Estimate Example
From Hispanic Digital Archives LCA
57
2.1.3 Operational Cost Estimate

• Provide a summary of the operational costs, i.e.,
  costs to keep the system up

From Data Mining the Library Catalogues LCA
58
2.1.4 Maintenance Cost Estimate

• Provide a summary of maintenance costs if
  applicable
• Should be consistent with Budgets in LCP

59
Maintenance Estimate Example
From Data Mining the Library Catalogues LCA
60
2.1.5 Estimate of Value Added and Relation to Cost

• Provide a summary of cost with and without the
  product and how much value is added by it. The
  value added may also describe non-monetary
  improvements (e.g. quality, response time, etc.)
  which can be critical in customer support and
  satisfaction.
• Include a Return-On-Investment (ROI) analysis as
  appropriate.

61
Time Spent With Current vs Proposed
In the current environment a Unicorn report can
be as large as 2 Gigabytes, but are, on average,
no larger than the size of memory and as many as
2000 reports are run in any given month (per the
client estimates). Therefore, if an average size
of a Unicorn report is 16 MB, and 5,135 pages of
information are generated for the client to
decipher, and it takes our client 1/2 seconds to
scan each page for the information, the time
spent deciphering reports takes
It is hoped that SURG will reduce the size of the
reports by at least 1/4, 1/3 or 1/2, which would
reduce these numbers to
From Data Mining the Library Catalogues LCA
62
ROI Analysis Example (Part I)
From Data Mining the Library Catalogues LCA
63
ROI Example (Part II)
From Data Mining the Library Catalogues LCA
Using the previous numbers as the Investment
Costs, and calculating hours saved for one person
as the time it takes to review an original sized
report compared to a SURG filtered report of 1/3
the original Unicorn size (See Section 2.1.5.1),
the Return On Investment for this project is
shown in the table and chart below
64
2.3 Stakeholder Concurrence

• Stakeholders may be anybody involved in the
  development process.
• For instance, a developer may argue that a
  certain response time cannot be achieved in a
  crisis mode unless nonessential message traffic
  is eliminated.
• Customer may argue that the product does not
  satisfy his/her win conditions (e.g. cost).

65
Stakeholder Concurrence Example
From Data Mining the Library Catalogues LCA
66
4. Project Risk Assessment

• Any combinations of capabilities or objectives
  whose feasibility is difficult to assure, are
  major sources of risk.
• Risk Assessment consists of risk
  identification, risk analysis and risk
  prioritization.
• Organize major sources of risk into a Top-10 (or
  Top-N) risk items list to be monitored via LCP
  4.1 (Risk Management and Monitoring Procedures)
• For critical risks indicate
• Description
• Risk Exposure magnitude and probability of
  loss
• Risk Reduction Leverage in reducing risk
  exposure
• Actions to mitigate risk
• Contingency plan
• Identify low-priority requirements that can be
  left out in case of schedule slippage

67
Software Risk Management Techniques
68
Sample risk analysis from Team 16-1 Spring 99
(only the first three risks are shown)
69
5. Analysis Results

• Identify architectural alternatives and impact
• Identify unfeasible architectures or rejected
  alternatives document criteria for rejection to
  avoid having the rejected architectural
  alternative selected in ignorance at some other
  point
• Describe feasible architectural alternatives
  which were rejected due to solution constraints
  on the way that the problem must be solved, such
  as a mandated technology. Those architectural
  alternatives may be reconsidered should the
  solution constraints be relaxed.

70
5.1 Product Features

• Discuss advantages to be gained by new (or
  modified) system
• List any limitations of the new system
• Discuss any alternative ways in which the new
  system could be realized

71
Sample of Analysis Results from Team 16-1 Spring
99
72
Evaluation of architectural alternatives (a
possible approach)

• Alternative 1
• Description (ID, name, purpose, scope, boundary)
• Context (System, Context, Stakeholder, Mission,
  Architecture)
• Views (static, dynamic)
• Impact/Constraint (use Component/COTS/Middleware/D
  atabase/Platform/HCI/etc.)
• Alternative 2
• Evaluation of Alternatives

73
5.2 Commercial-off-the-shelf Solutions

• List of existing products that should be
  investigated as potential solutions.
• Reference any surveys that have been done on
  these products.
• Is it possible to buy something that already
  exists or is about to become available? It may
  not be possible at this stage to say with a lot
  of confidence, but any likely products should be
  listed here.
• Also consider whether there are products that
  must not be used.

74
Sample of FRD 5.2 (formerly 5.1) from Team 16-1
Spring 99