REQUIREMENTS

1
REQUIREMENTS RISK MANAGEMENT

• MN3309 Session 7
• Prof. Mark Nissen

2
Agenda

• Software Project Staffing
• Program Growth Exercise
• Requirements Management
• Requirements Exercise
• Risk Management
• Summary

3
Software Project Staffing

• Raleigh CoCoMo staffing profiles
• Rules of Thumb - heuristics
• 25 core staff _at_ project start
• Outlines maximum rate of buildup/down
• Experienced staff ratio gt 1/6 1/3
• Look for skill/productivity degradation
• 30 annual manpower buildup
• Mythical manmonth effect
• Staffing example

4
Staffing Example
Comments? Critiques?
5
Program Growth Exercise

• Baseline program
• 110 KSLOC development
• 12.8M program baseline
• Steady for 5 quarters
• New data
• Quarter 6 10 KSLOC
• 120 KSLOC development
• ? program cost impact

6
KSLOC Trend (Plan/Actual)
7
Program Growth Exercise

• Baseline program
• 110 KSLOC
• 12.8M program baseline
• New data
• 120 KSLOC
• 24.5M program update
• 91 program cost impact!

8
KSLOC Component Trend
9
Requirements Management

• Why must get requirements right?
• Requirements VV important?
• Problems with natural language?
• SATC Tool?
• Examples of requirements metrics?
• What use for metrics database?

10
Requirements Comparison
Options/imp good or bad?
11
Requirements Tracking Testing

• Meeting requirements is important
• Not meeting requirements as bad as system full of
  bugs
• Meeting right requirements more important than
  meeting all requirements?
• Requirements stability important
• How to track stability?
• Ready for CDR?
• How to test requirements?

12
Requirements Exercise

• Interface for student thesis review
• Students submit draft thesis chapters
• Exchange in dependable I/O location
• Advisors review return comments
• Project groups
• Develop requirements for thesis interface
• Spend 1 minute with customer (instructor)
• 5 minutes to draft requirements
• Critique
• Read requirements to class
• Other groups critique

13
Risk

• Risk cannot be eliminated!
• P(undesirable event occurring) - P(UO)
• Risk exposure P(UO) x L(UO)
• Minimize RE, not P(UO)
• Risk function cost
• Risk-aversion vs. expected loss
• DoD policy PMs take risks?
• Key is to ID manage risk

14
Risk Function Cost
15
Software Risk

• S/W is THE risk-prone W/S activity
• Poor management cited for S/W failure
• 5 software risk areas
• Technical (performance)
• Supportability (performance)
• Programmatic (environment)
• Cost
• Schedule
• Requirements risk is ominous

16
Software Top-10 Risks

• Personnel shortfalls
• Unrealistic schedules and budgets
• Developing the wrong software functions
• Developing the wrong user interface
• Goldplating
• Shortfalls in externally furnished components
• Shortfalls in externally performed tasks
• Real-time performance shortfalls
• Straining computer science capabilities

17
Software Risk Notes

• Management reacts to problems
• Orgs discard process to buy schedule
• Try silver bullet
• PMs do not realize they are in trouble
• Success-oriented schedules
• Effort focused on calendar, not events
• Customer takes hands off approach
• Immature S/W development process
• Funding instability rqmts changes

18
S/W Risk Taxonomy

• Product Engineering
• Requirements
• Design
• Code test
• Engineering specialties
• Development Environment
• Development process system
• Management process methods
• Work environment
• Program Constraints
• Resources
• Contract
• Program interfaces

19
Risk Mitigation

• Risk avoidance
• Select lower-risk alternative
• Risk control
• Monitor correct risky conditions
• Risk assumption
• Accept risk consequences
• Risk transference
• Risk sharing (contractual)

20
Risk Management

• Costs time money
• Less s than unexpected problems
• ID, analyze, plan, track, control, comm
• Key elements (plan execute)
• Valid cost schedule estimates
• Realistic program plan schedule
• ID manage major risks
• Obtain track metrics (C-SAWS?)
• Customer-developer comm cooperation

21
Formal Risk Management Methods

• PERT/CPM
• Software Risk Evaluation (SEI)
• Boehms S/W Risk Mgmt Method
• SPMN Risk Management Method
• Team Risk Management Method
• B-1 B computer upgrade experience
• Fairleys 7 step method
• Link risk management metrics?

22
COTS Risks

• Integration?
• Upgrading?
• Source code?
• Vendor failure or buyout?

23
Deadline Pressure

• View problem as big boss?
• Evolutionary delivery
• How different?
• Why deliver some parts early?
• Software inspections
• How does it work? TQM?
• Why positively impact schedule?
• Attribute specification
• Quality attributes measurable testable?
• Spec 2 performance levels worst goal?

24
Risk Source Selection

• S/W experience process maturity
• Risk management in RFP
• Proposal is prelim SDP!
• S/W development methodology
• S/W architecture reuse
• Rqmts configuration management
• Estimates metrics
• Development envir, tools, process
• Buy information to reduce risk
• Prototyping, phases, shoot outs

25
Real-Time Systems

• Challenges
• Real-Time Tasks
• Design Requirements
• Design Guidelines

26
Real-Time System Challenges

• Time is of the essence
• Interface with physical environment
• Safety often critical
• Recovery redundancy required
• Size, memory, speed often constrained
• COTS H/W often inadequate
• H/W S/W design intimately related
• Testing includes sim, HITL, live fire

27
Real-Time Tasks

• 2 categories of RT S/W
• Hard RT - safety-critical timing
• Firm RT - utility-critical timing
• Soft RT - non-critical timing
• 3 categories of RT tasks
• Periodic - fixed-interval execution
• Aperiodic - random arrival rates
• Server - encapsulates common resources handles
  synchronization aperiodics

28
Design Requirements

• Complete predictability - difficult
• Schedulability
• Meet all rqmts under normal conditions
• Meet critical rqmts in all conditions
• Execution time estimates
• Computer instruction execution time
• Computer interrupt latency
• Functional descriptions
• I/O execution times
• Computer HITL!

29
Design Guidelines

• Executive
• Resource manager
• Scheduling algorithm
• I/O services
• Tasks
• Separate periodic aperiodic
• Prioritize tasks
• Low coupling high cohesion
• Separate timing from task code

30
Design Guidelines (Cont)

• Group tasks by execution rate
• Minimize number of groups
• Validate CPU requirements
• Ensure adequate CPU I/O margins
• Develop application timeline
• Apply algorithm (RMS) iterate
• May require AI!

31
Summary

• Carefully monitor project staffing
• Understand nuances of CDRL data
• NL causes problems with requirements
• Verify requirements through testing
• Risk management is investment