DoD SOFTWARE ENVIRONMENT

1
DoD SOFTWARE ENVIRONMENT

• MN3309 Session 4
• Prof. Mark Nissen

2
Extended PM Exercise

• Form 2 teams
• Task walk with book on head (closed)
• Across room, no hands - 10 times (R/T)
• Speed important
• Start over if dropped
• Estimate and measure
• Number of steps, hands drops
• Time to complete task
• Sketch scalability model

3
Agenda

• Military Software Environment
• S/W Process Practices
• Program Management Culture
• Real Requirements Determination
• Summary

4
Power of Military Software

• Changed battlefield (Powell)
• F-16 FBW (15M lawn dart - Ludwig)
• B-2 stealth - no vertical surfaces
• F-117 stealth - automated flight controls
• F-22 - 80 functionality via S/W
• Too much battlefield info w/o AI (Busey)
• Seawolf - virtual design simulation
• C-17 - virtual airframe durability testing

5
DoD S/W Domains

• Weapon systems
• Embedded
• C3 C3I
• Other (MPS, train, sim, PM, CM, testing)
• Management Information Systems
• Information System Resources (ISR)
• Automated Information System (AIS)
• Information Resource Management (IRM)
• Other (security, telecom, DBMS, mgmt)

6
S/W Development Life Cycle

• Life cycle of development activities
• Generic model of development process
• IEEE/ANSI SDLC
• Requirements analysis --gt SRS
• Logical physical design --gt SDD
• Code test --gt unit-tested modules
• Test integration --gt tested subsystems
• Acceptance test --gt accept/reject decision
• Maintenance --gt support/upgrade activities

7
Committed vs. Expended Cost
8
S/W Complexity Exercise

• Refer to figure on board
• What does this software do? Trace steps
• How many paths through S/W?
• Perform six simulated tests (proofs)
• Inputs (1,1), (2,-1.6), (I,f), (A,Q), (1,B),
  (!,.)
• How will program respond to each?
• How many SLOC to develop (in 3LL)
• How long and at what cost?

9
Acquisition Reform for S/W

• DoD non-VA rqmts add 20-50 cost
• Mil-Com conversion --gt industrial base
• Mil superiority --gt com tech access
• Com design 3 yrs, mil 8
• Cycle time is key driver in acq reform
• DoD must do business like business
• Benchmarking and innovation

10
S/W Best Practices

• Formal risk management
• Agreement on interfaces
• Metric-based scheduling tracking
• Defect tracking vs. quality targets
• Wide visibility of program vs. plan
• Binary gates _at_ inch pebble level
• Inspections, reviews, walkthroughs
• CM, teamwork, people orientation

11
Software Estimating

• Good mgmt begins with a plan
• Cost schedule estimates hard
• Complex task itself
• Estimators lack experience data
• Human bias underestimate
• Mgmt bias competitive goals
• General tools, specific projects
• Three model classes economic, Raleigh, function
  point (more later)

12
Architectural Emphasis

• Architectural design
• Map function to structure
• Compatibility interoperability
• Planning for change enhancement
• Open systems
• Interfaces, protocols, standards
• Extensibility upgradability
• Popularity (in FAR 11)

13
Interface Exercise

• Interface spec for thesis work
• Students submit draft thesis chapters
• Exchange in dependable I/O location
• Advisors review return comments
• Functions
• I/O location available 24/7 (student prof)
• Must accommodate 4 entire theses
• Remain in I/O until async retrieval
• Groups - HL design for thesis exchange
• Design to interface spec
• DoD preference for approaching requirements
• No questions. Report on approach. 5 minutes

14
IPT Environment

• IPT mandated by acquisition reform
• Benefits of cross-functional integration
• Difficulties
• Group problem solving decision making
• Diminished authority role of leader
• Peers influencing peers
• Professional knowledge workers
• Specialized knowledge and fields
• Mgmt orchestra conductor?

15
Program Management Culture

• Smart, dedicated, hardworking people
• Over-programming - 150B - effect?
• GAO report
• Questionable W/S requirements
• Unrealistic cost/sked/perform estimates
• Program concurrency
• Powerful incentives to support program
• Problems? Solutions?

16
Real Requirements Determination

• Pentagon Wars

17
Summary

• 3 W/S S/W domains
• S/W remains a complex artifact
• AR best practices offer some hope
• Architecture is important
• PM culture opportunity impediment
• Role of covert leadership

18
Specifications Standards

• Performance specs now required
• Include criteria for conformance
• Interface interchangeability properties
• Mil-STDs -Specs require MDA waiver
• MIL-STD-498 - S/W Development
• USAF USN waiver to Perry requirement
• To phase-out by end of 1996
• Commercial stds ISO 12207, US 12207
• Tailoring approach to acquisition
• Ada no longer required (new, redesign)

19
DoD 5000 Series

• DoDD 5000.1 DoD 5000.2-R (1996)
• to define acquisition environment . . .
• make DoD smartest buyer
• at best dollar value
• Objectives
• Incorporates FASA, IPTs, other policies
• Separate mandatory, discretionary practice
• Simplify acquisition documentation (DAD)
• Integrate MDAP MAIS regulations

20
DoD 5000 Series (Cont.)

• Major themes
• Teamwork - cross-functional (from BPR)
• Tailoring - based on program size, risk, . . .
• Empowerment - people vendors
• CAIV - responsible cost objectives
• Com products - integrate DoD industrial base with
  tech advances com sector
• Best practices - simplified, flexible process for
  acquisition management (from BPR)

21
DoDD 5000.1

• Disciplined DoD acquisition process
• Principles for all DoD acquisitions
• Flexible-but-disciplined
• As applicable to the MDAP as helmet
• Translate operational needs into stable,
  affordable programs
• Emphasize stability, total systems approach,
  CAIV, non-traditional acquisition

22
DoDD 5000.1 (Cont.)

• Acquiring quality products/services
• Emphasize event-oriented management, mod sim,
  innovation, S/W systems
• Organizing for efficacy efficiency
• Streamline orgs, limited reporting, automated
  acquisition information (DAD)

23
DoD 5000.2-R

• Mandatory process for MDAP/MAISs
• Lists discretionary processes
• Organized into 6 parts (acq design)
• Acquisition management
• General process model for MDAP/MAISs, noting one
  size does not fit all!
• Program definition
• Mandatory process for translating (engr) mission
  needs into performance specs

24
DoD 5000.2-R (Cont.)

• Program structure
• Elements to structure MDAP/MAIS program along
  with strategy/guidance
• Program design
• Disciplined MDAP/MAIS program design
• Program assessments reviews
• Tailored approach to oversight
• Periodic reporting
• Mandatory DAES, SARs, unit cost, test results,
  contract performance

25
Defense Acquisition Deskbook

• Online (CD Web) access to regs
• I agents K systems
• Acquisition process
• Class-level acquisition model
• Checklist for acquisition planning
• Acquisition regulations
• Online search retrieval
• Links regs to process activities
• Differentiates mandatory acquisition regs

26
System Development Problems

• Development time
• System-user interface
• Test integration
• Maintenance
• User-acquirer-developer interfaces
• Compatibility, extensibility, portability

27
Systems Development Solutions

• Postpone technical decisions
• Reduce development cycle time
• Involve users in requirements process
• Thorough test plan responsibility
• Include support criteria into rqmts
• Bridge roles via systems engineering
• Open systems architecture

28
Systems Engineering

• Analyze problem to ID needs
• Develop architecture concept
• Spec system boundaries interfaces
• Establish performance values
• Modeling evaluation of alternatives
• Functional allocation into subsystems

29
Technical Planning

• Technical planning templates/outlines
• Table 1.1 - ToC for system development plan
  (contract, org, tech, risk, schedule)
• Table 1.2 - task descriptions (I/O, reviews,
  procedures, resources, schedule)
• Resource schedule estimation are key
• Risk mgmt change control are critical
• Table 1.3 - ToC for SDP (estimates, staffing,
  standards, SEE, VV)

30
SDLC Models

• Waterfall model - sequential
• DoD (2167) model - DIDs
• Rapid prototyping - throw always
• Incremental - P3I
• Evolutionary - P2I
• Spiral - phased waterfall
• Reuse - always!
• Cleanroom - rqmts quality oriented

31
S/W Acquisition Engineering

• Software system
• Acquisition engineering processes
• Processes intimately related
• Should be closely coupled
• Requires mutual understanding (C-SAWS)
• Commerce Model for redesign
• Integrated supply chain for agents
• Acquire for engineerability, and engineer for
  acquirability