PDSS PLANNING

1
PDSS PLANNING CM

• MN3309 - Session 16
• Prof. Mark Nissen

2
Agenda

• PDSS Planning
• Empirical Maintenance Studies
• Maintenance Example
• Configuration Management
• CM Exercise
• Summary
• Lots of hidden slides

3
PDSS Planning

• PDSS Importance Misnomer
• PDSS Drivers Activities
• PDSS S/W Development
• PDSS Support Issues
• COTS Issues
• F-22 ALC SPO Army ROADS
• RFP Considerations
• S/W Reengineering

4
PDSS Importance

• Multimillion dollar lawn darts w/o S/W
• Battlefield mods necessary - fast
• 10-20 year W/S life cycles
• 60-80 of S/W LCC for PDSS
• Budgets support few new weapon system developments

5
PDSS Misnomer

• Post Deployment Software Support
• Not repairing broken/worn-out parts
• Software does not break or wear-out
• Half of S/W support driven by changes in external
  environment
• PD Continuing Development
• S/W mod after (initial) delivery (IEEE)

6
Software Change Drivers
7
S/W vs. H/W Reliability
8
PDSS Activities

• Interacting with users to determine what changes
  or corrections are needed,
• Reading existing code to understand how it works,
• Changing existing code to make it perform
  differently,
• Testing the code to make sure it performs both
  old and new functions correctly, and
• Delivering the new version with sufficiently
  revised documentation to support the user and the
  product.

9
PDSS S/W Development
10
S/W Support Issues

• Consider C-SAWS support
• Lack of requirements traceability
• The evolution of software versions or releases
  that are difficult or impossible to trace
• A difficult or impossible to define software
  development process
• Documentation that is nonexistent or of such poor
  quality that it is useless
• Other factors affecting operational systems
• Inflexible software not designed to accommodate
  change.
• Module size and branching
• Maintenance S/W engr stepchild

11
AFOTEC Supportability Evaluation Areas
12
Other Supportability Factors

• Availability of qualified software personnel,
• System structure understandability,
• Ease of system handling,
• Use of standardized programming languages,
• Documentation structure standardization,
• Test case availability,
• Built-in debugging mechanisms,
• Delivery of the original development SEE to the
  maintenance organization, and
• Availability of appropriate computer hardware to
  conduct maintenance activities.

13
COTS Supportability Planning

• acquire and maintain appropriate documentation
  and data rights, licensing, and subscription
  services
• COTS resources must not be altered so as to
  preclude contractor logistics support or void
  licensing or subscription services.
• contract for subscription services required to
  update and maintain COTS assets.
• evaluate operational and logistic impacts of
  change due to hardware and software upgrades.
• evaluating effectiveness and mission impact of
  changes due to subscription-related software
  upgrades.

14
F-22 ALC SPO

• Air Logistics Center (ALC)
• F-22 has 7M SLOC
• All Ada
• OFP to GSE
• Common terminology
• Common SEE
• Contractor-SPO maintenance IPTs
• Working shoulder-to-shoulder during development
  (EMD)

15
Army ROADS
16
PDSS CSFs

• Determine your life cycle support strategy early,
• Ensure adequacy of contractor software
  development processes during source selection,
• Remember that software support is actually
  software re-development,
• Identify supportability requirements and
  objectives in systems requirement documents and
  Statements of Objectives,
• Specify required documentation and verification
  methods in the appropriate CDRLs,
• Identify necessary software development and
  support tools in CRISD, and establish a CRWG IPT.

17
CRLCMP

• Doc mgmt approach, decisions, plans associated
  with acquisition of computer resources
• Includes
• ID major risks control methods
• Describe acquisition strategies
• Describe life cycle S/W testing
• Metrics used to assess program progress
• ID critical issues, objectives, costs,
  methodologies, evaluation criteria
• Structure development to provide data

18
CRISD

• Key document for S/W support
• Facility requirements
• Equipment
• Personnel - number, skills, training
• SEE - type, functionality, limitations
• Product of S/W development process
• Living document
• Changes with S/W configuration
• Changes with S/W environment

19
CRISD Foundation
20
PDSS RFP Considerations

• Emphasize PDSS in section M
• SDP should reflect transition PDSS
• Integrate support into requirements
• Emphasize supportable architecture
• Consider compute-offs
• Prototypes demonstration S/W
• Force pre-award S/W maintenance mod

21
Deliverable Requirements

• Data rights to make and install changes,
• Source code and documentation adequate to
  understand the code,
• Computer resources (SEE, computers, compilers,
  etc.) needed to modify the source code and
  produce object code,
• Equipment and support software to test the
  subject code, to diagnose problems, and to test
  solutions, enhancements, and modifications,
• Equipment needed to distribute and install the
  new software,
• A workable system to identify problems, resolve
  new requirements, and manage the support workload

22
Supportability Characteristics

• ASC has developed a RFP template which provides
  general and specific guidance on preparing the
  RFP for software-intensive systems.
• Module size a typical computer software
  component (CSC) should generally not exceed 100
  SLOC.
• McCabes Cyclomatic Complexity Measure should not
  exceed 10 for a given module
• Ada is the DoD higher order language of choice.
• Spare memory, computer throughput, I/O
  bandwidth permits the incorporation of
  enhancements and the correction of latent
  deficiencies.

23
Documentation Wish List

• Software and Interface Requirements
  Specifications,
• Software and Interface Design Descriptions,
• Database Descriptions,
• Software Product Specifications,
• Source Code Listings,
• Test plans/descriptions/reports,
• Software Development Plans,
• Software programming manuals,
• Software users manuals, and
• Software maintenance manuals.

24
Software Reengineering

• NOT business process reengineering
• Redesign S/W re-implement code
• Correct maintenance problems
• Legacy systems (outdated H/W, S/W)
• Spaghetti code
• Mixed programming languages
• Application-specific data
• Proprietary, non-modular architectures
• Year 2000 problem?

25
S/W Reengineering Benefits

• Reduce maintenance costs
• Eliminate latent defects
• Convert to modern language or H/W
• Facilitate changes and upgrades
• Augment domain architecture
• Increase object library pool
• Rules of thumb
• Costs less than 50 of new development
• 80 problems caused by 20 modules

26
S/W Reengineering Framework
27
Maintenance Empirical Studies

• Maintenance like bad breath
• Huge economic impact
• 60-80 of S/W LCC
• 50 of com personnel distribution
• Billions of legacy SLOC (50B COBOL)
• Maintenance productivity
• f(procedure/module size)?
• F(branching)?
• L-Form software organization

28
Maintenance Example

• Development more efficient than maint
• Legacy S/W used for long time
• S/W maintainability is important
• Also S/W retirement rate
• Product-line pressures?
• Impact on personnel distribution?
• Maintenance model

29
Configuration Management

• Level-2 KPA in SEI CMM
• Critical for keeping track of S/W
• 4 CM areas
• Identification
• Change control
• Status accounting
• Audit
• Intimately tied to S/W repository data
• Key to evolutionary development

30
Configuration Identification

• Deliverable S/W code
• Other software support S/W, compilers, O/S,
  scripts, object code
• Design data requirements, specs, designs,
  interface controls
• Management data project plans, test plans
  data, SCM reports
• Configuration baseline
• Process configuration? (innovation)

31
Change Control

• Define the change process
• Maintain product baselines
• Process change requests
• Report change activities
• Control product releases
• Reconcile to baseline
• Particularly important with evolutionary
  development methods

32
Status Accounting

• Determine reporting required
• Track status of SCM items
• Track status of S/W changes
• Generate status reports
• SCM activity reporting

33
Configuration Audit

• Verification activity (internal)
• Performed at milestone points
• Fed by ID, change control, tracking
• 2 primary audits
• FCA - verify that S/W meets requirements
• PCA - verify that S/W built as designed

34
CM Exercise

• Individual effort
• Blank sheet of paper
• Initial development
• Each software engineer
• Enter 10 numbers in row (0-9)
• Subsequent developments
• Pass papers CW
• System evolutions
• Look for CM implications

35
Summary

• PDSS is critical activity, misnomer
• Huge economic impact
• More like redevelopment
• Maintenance productivity
• Address first in design
• Consider in PDSS organization
• Several maint productivity factors
• CM is critical activity, Level-2 KPA
• S/W evolution requires effective CM