1February 14, 2007 © 2007 BAE Systems Land & Armaments L.P. February 14, 2007 Tom Schroeder FCS MGV...

February 14, 2007 © 2007 BAE Systems Land & Armaments L.P. 1

February 14, 2007

Tom Schroeder

FCS MGV Software Engineering Manager

BAE Systems, Ground Systems

Requirements Volatility Topic:Using Anchor Point Milestones


Purpose

Frame a discussion about:

What are the major software-intensive systems risks related to Requirements Volatility with respect to experiences using Anchor Point Milestones?

What are the current best practices for addressing these risks? What are the top-priority research topics for addressing the risks?


Outline

Perspective - Company Background & Projects Software Build 1 Lesson in Requirements Idealized Software Build Life Cycle Extending the Software Life Cycle to Systems and SOS Levels Hard Questions to Answer about LCO’s and LCA’s Sources of Requirements Volatility


Protected Fighting Platforms for Today’s Warfighter as well as the Battlefield of Tomorrow• Predominant Supplier to the U.S. Army Heavy Brigades with

Bradley, HERCULES, Paladin, M113• Mine-Protected Wheeled Vehicles• FCS Manned Ground Vehicles and Armed Robotic Vehicle

Key Technologies• Advanced Protection and Mobility Solutions for Soldiers, Manned

Vehicles and Robots• Outstanding Program Management and Experienced Workforce• 3,250 employees, including more than 600 technologists

World-Class Development Processes• CMMI Level 5 Software and Systems Engineering Process• Physics-Based Models & Real-Time Simulation Capabilities• Rapid Prototyping of Complex Systems

Lean, Cost-effective Production Facilities

Ground Systems – A Summary

GS is a modern, efficient, full-spectrum developer, integrator and supplier of survivable, lethal ground combat platforms and advanced technologies


FCS Brigade Combat Team (BCT)18 Integrated Systems + 1 Network + 1 Soldier

FCS is about the 21FCS is about the 21stst Century Soldier Century SoldierFCS is about the 21FCS is about the 21stst Century Soldier Century Soldier

Unmanned Aerial Vehicles

Class II Class III Class IV

Class I

ARV-A (L)

Small (Manpackable) UGV

MULE(Countermine)

MULE(Transport)

Unmanned Ground Vehicles

Unattended Ground Sensors

Armed Robotic Vehicle (ARV)

Unattended Munitions

ARV RSTAARV Aslt

Intelligent MunitionsSystems

NLOS LS

Infantry CarrierVehicle (ICV)

Manned Systems

Command andControl Vehicle (C2V)

Reconnaissance andSurveillance Vehicle (RSV)

Mounted Combat System (MCS)

Non-Line of SightCannon (NLOS-C)

Non-Line of Sight Mortar (NLOS-M)

Medical VehicleTreatment (MV-T)

FCS Recovery and Maintenance Vehicle (FRMV)

Medical VehicleEvacuation (MV-E)

Approved for Public Release, Distribution Unlimited, TACOM 20 SEP 2006, case 06-208.


Software Build 1 Objectives

Build initial prototype vehicles for one vehicle type (“variant”), the Non-Line of Sight Cannon (NLOS-C)

Develop “threshold path” common components and software for a common chassis.• Hybrid Electric Drive Powertrain, Driving functions, Vehicle Management• Power Distribution, Remote Interface Units, Servo Control Units• Embedded Training

Develop “threshold path” mission equipment and software for the weapon and mission control functions

Develop low-cost software and hardware “surrogates” to stand-in for functionality that is not yet available, such as the sustainment system, the displays and user interface system, etc.

Develop and improve processes for software development and integration

Reduce risk for objective vehicles and software development


A Software Build 1 Lesson in Requirements Systems Engineering selected a waterfall life cycle. Software Engineering selected an

iterative life cycle. Software Engineering introduced a new event, Requirements Baseline Review (RBR) as a

handoff to receive the requirements allocated to Software from Systems & Subsystems. RBR was not in the IMP, so it lacked completion criteria.

RBRDR2 (PDR)

Sys/Subsys Requirements Focus Sys/Subsys Design Focus

DR1 (SFR)

Inception (Rqmts Focus)

LCO

Elaboration (Design Focus)

LCA

System / Subsystem Activity

Software Activity

Inception (Rqmts Focus)During this period most effort was needed to develop SRSs and IRSs

LCO

Elaboration (Design Focus) During this period, time for software architecture work was too short, resulting in an LCA slip

LCA

RBR Recovery LCO / DR2 Issues

LCACompletion

Software Activity

At RBR, Software evaluated allocated Subsystem requirements. Quality issues resulted in an intense three-month systems/software “RBR Recovery” effort, but LCO wasn’t allowed to slip. Requirements rework was finally resolved during the first half of LCA, but it pushed the LCA milestone out, reducing time for construction iterations.


6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12 1 2 3 4 5 6 7 8 9 10 11 12

SW Build 1 (Plan)

SW Build 1 (Adjusted)

2005 2006 2007

Develop LCA Required Documents

Detail External Interfaces

Develop SI Software Designs

Update MGV SW Architecture

Refresh LCA Design

Refresh LCA Documents

ER1 Software

Refresh ER2 Docs

ER3 Software

Support Common Integ

Support Common Integration

Refresh ER1 Design

Refresh ER1 Documents

ER2 Software

Refresh ER2 Design

Support Common Integ

RBR

RBR LCO

LCO

LCA

LCAFinish

ER1

ER1

ER2

ER2

ER3/TRR

ER3/TRR B1 CommonSW Integration

Complete

B1 CommonSW Integration

CompleteLCAStart

Build 1 Common SW Schedule

An adjustment of iteration durations was preferable to inserting an iteration.

Turns out that systems and subsystems engineering has provided every subsequent software iteration with necessary updates, aka beneficial “Requirements Volatility.”


Build 1 LCO and LCA Statistics

LCO October 3-21, 2005 Participation by 68 Reviewers

• 10 IPT Areas Reviewed

• 55 Artifacts Reviewed

• 2059 Comments Received

60% of All Comments from SRS/IRS• Most HIGH priority comments were

submitted against the SRS/IRS

LCA Stage 1 February 16-27, 2006 LCA Stage 2 March 27–April 21, 2006 Participation by 83 Reviewers

• 11 IPT Areas Reviewed

• 68 Artifacts Reviewed

• 2499 Comments Received

0

100

200

300

400

500

600

700

800

COTS

/Reu

se

Feasib

ility

IRS

OCDM

isc

SADDSIP

Proto

Pre

sent

ation

SRSSTP

Undefined

Low

Medium

High

0

50

100

150

200

250

300

350

400

450

STP SRS IDD IRS FR SDD SIP ArchDesignModel

SADD SDS CommonSIP

NLOS-CSIP

Other

High Medium Low None Positive Feedback (blank)


A Software Build 1 Lesson in Requirements

Why was LCO held steady?• Award Fee tied to “successful LCO”• Needed to hold schedule for some Subsystem software teams• Systems/subsystems engineering functions would need support future

software iterations, although not explicitly in their plans to do so Why was LCA moved 6 weeks instead of adding a new cycle?

• Award Fee tied to “successful LCA”• First part of LCA period dedicated to addressing requirements issue work

plans resulting from both RBR and LCO• Needed time to make software design progress to meet LCA criteria, and

customer willing to grant extension provided time made up in construction iterations

• An iteration no-go decision was not a viable option for the software teams Technologies in use were relatively mature, risks were manageable, and

vehicle schedules too important to move


Idealized Software Build Life CycleYear 2Year 1

SW SITDI 1.1

Start

SW SITDI 1.2

SW SITDI 1.3

SW SITDI 1.4

SW SIT

SW SITDI 1.6

SW SITDI 1.7

SWDI 1.8

SwLCO

SwLCA

InceptionPhase

ElaborationPhase

ConstructionPhase

TransitionPhase

TRR

Acronyms and AbbreviationsDI b.c Development Increment, Build b, Increment cIOC Initial Operational CapabilityLCA Life Cycle Architecture MilestoneLCO Life Cycle Objectives MilestoneSI Software ItemSIT Software Subsys/Sys Integration & TestSW Software Engineering (incl. SI-Level Int & Test)SwLCA Software LCASwLCO Software LCOTRR Test Readiness Review (SI Level)

IOC

SIT

DI 1.5


Idealized Systems and Software Integrated Build Life CycleYear 2Year 1

S/SS SW SITDI 2.1

Start

S/SS SW SITDI 2.2

S/SS SW SITDI 2.3

S/SS SW SITDI 2.4

S/SS SW SIT

S/SS SW SITDI 2.6

S/SS SW SITDI 2.7

S/SS SWDI 2.8

SwLCO

SwLCA

SyLCO

SyLCA

InceptionPhase

ElaborationPhase

ConstructionPhase

TransitionPhase

TRR

Acronyms and AbbreviationsDI b.c Development Increment, Build b, Increment cIOC Initial Operational CapabilityLCA Life Cycle Architecture MilestoneLCO Life Cycle Objectives MilestoneS/SS Systems/Subsystems (IPT) EngineeringSI Software ItemSIT Software Subsys/Sys Integration & TestSW Software Engineering (incl. SI-Level Int & Test)SwLCA Software LCASwLCO Software LCOSyLCA Systems/Subsystems LCASyLCO Systems/Subsystems LCOTRR Test Readiness Review (SI Level)

IOC

SIT

DI 2.5

By adding Systems & Subsystems requirements and design engineering stages synchronized with Software development increments, upstream work products can be worked iteratively to support Software.

Software can provide valuable implementation feedback to Systems & Subsystems teams, with pre-planned learning adjustments.

Consider introduction of Systems LCO and LCA events. Software support would be a subset of Systems Engineering total scope.


Systems Lifecycle

SystemRqmtsSystem Design

Subsystem Rqmts

Subsystem Design

Software Rqmts

Software Design

Software Code!

Man

y IP

Ts


Systems Lifecycle

SystemRqmts

System Design

Subsystem Rqmts

Subsystem Design

Software Rqmts

Software Design

Software Code!


Systems Lifecycle

SystemRqmts

System Design

Subsystem Rqmts

Subsystem Design

Software Rqmts

Software Design

Software Code!

Requirements are “realized” through design processes to become the next tier’s requirements which in turn are “realized” …

PIDS SSDD CIDSICD

SSDD SRSIRS

SDDIDD

SE AL1UML Model

SE AL2 UML Model

SW UML Model

Sw IntegThreads

DDMs

CodeSVD

DDMs

SE AL0.2Model

‘L4’ Rqmtsin DOORS

‘L3’ Rqmtsin DOORS

SADD

SWARCHNotes

SDS

SW Item Design Model

= Influences

to the worldof integration

What is the turn-around

time to change

requirements with this process?

Work Products


SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts

SW Mgmt & EnvSW Mgmt & Env

Construction Iteration ER3(~4 months)



Workflow Integration


CMN SW TestCMN SW Test

CMN SW IntCMN SW Int

CMN SW I&T EnvCMN SW I&T Env

SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts







VNT SW TestVNT SW Test

VNT SW IntVNT SW Int

VNT SW I&T EnvVNT SW I&T Env




SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts



















SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts








SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts




SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts





Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement

Improvement















SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts








SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts




SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts





Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t

Imp

rove

men

t









SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts













SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts


SSys Spec/AllocSSys Spec/Alloc

SSys DesignSSys Design

SSys AL2 RqSSys AL2 Rq












SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts





Sys Spec/AllocSys Spec/Alloc

Sys DesignSys Design

Sys PIDS/AL1 RqSys PIDS/AL1 Rq


















SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts










SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts










SW I&TSW I&T

SW C&UTSW C&UT

SW DesignSW Design

SW RqmtsSW Rqmts



















Idealized System of Systems Build Life CycleYear 2Year 1

S/SS SW SITDI 2.1

Start

S/SS SW SITDI 2.2

S/SS SW SITDI 2.3

S/SS SW SITDI 2.4

S/SS SW SIT

S/SS SW SITDI 2.6

S/SS SW SITDI 2.7

S/SS SWDI 2.8

SyLCO SwLCO

SyLCA SwLCA

InceptionPhase

ElaborationPhase

ConstructionPhase

TransitionPhase

TRR

Acronyms and AbbreviationsDI b.c Development Increment, Build b, Increment cIOC Initial Operational CapabilityLCA Life Cycle Architecture MilestoneLCO Life Cycle Objectives MilestoneS/SS Systems/Subsystems (IPT) EngineeringSI Software ItemSIT Software Subsys/Sys Integration & TestSW Software Engineering (incl. SI-Level Int & Test)SOS Systems of Systems EngineeringSOSIOC SOS Initial Operational CapabilitySOSIT SOS Software Integration & TestSOSLCA System of Systems LCASOSLCO System of Systems LCOSwLCA Software LCASwLCO Software LCOSyLCA Systems/Subsystems LCASyLCO Systems/Subsystems LCOTRR Test Readiness Review (SI Level)

IOC

SOS

SOS

SOS

SOS

SOS

SOS

SOS

SOS

SOSIT

SOSIT

SOSIT

SOSIT

SOSIT

SOSIT

SOSIT

SOSITSIT

Year 3

DI 2.5

SOSLCO

SOSLCA

SOSIOC

Very difficult to achieve!


Problems with SOS Staging

Synchronizing development to similar iterations across many organizations, each with its own development processes, is extremely difficult• Unsynchronized workflows increase the number “surprise” requirements changes

Greater numbers of participants tend to stretch out the iterations to make the same amount of progress.• Takes time to discover who to coordinate with, and if they have tasking to do so• Organizations change, people move around, responsibilities shift, POC’s change• Potential O(2) effect with more interactions and interfaces

Interface and scope negotiation across many associate teams adds activities and stretches iterations.• To make progress, teams are forced to make unilateral decisions• From SOS perspective, may be sub-optimal or not even viable system-wide

Coordinating compatible requirements to achieve viable functioning threads across associate contractors for small increments is difficult.

Incremental SOS use of tactical software can be prohibitively expensive in terms of numbers of computers, simulators, emulators, and plant models needed prior to long-lead time dedicated hardware being available.

Intellectual property protection, licensing, and legal involvement increases.


Hard Questions to Answer about LCO’s and LCA’s

What level of completion of Systems Engineering work products is needed for Software to have a successful LCO?

A typical answer from Software: All requirements allocated to software need to be specified. Reasons:• If Software doesn’t keep up the pressure on Systems Engineering, the Requirements

provided to Software will be incomplete. LCO could fail.• If Software doesn’t have a complete set of requirements, Software will be unable to

complete SRS trace tables to parent requirements. Obvious problem of handoff adequacy and criteria definition

• Software can try to create a risk that all necessary requirements will not be available “Cry Wolf” approach sure to fail at the Risk Review Board

• Systems could create a risk that all the Systems work products will not be available for software

“Hit Me” approach never seems to emerge, either• What should the completeness and completion criteria be?



What level of completion of Systems Engineering work products is needed for Software to have a successful LCO?

A typical answer from Systems: All requirements allocated to software will be specified, with traceability to upper-level models. Other documents will be made available as reference (work in progress) leading up to System PDR:• System Architecture which may include applicable DDM's, such as Vehicle

Electronics Architecture, System/Subsystem Schematics, Specialty Engineering Reports (Security, HFE/MANPRINT, Safety, Maintainability), Sustainment and Training Design Concepts

• Thread based performance analyses

• Current Version of Common Subsystem and Variant Level S/SDD's

• Vehicle External ICD’s - Interfaces to all C4ISR, Sustainment, and Training supplied subsystems.

• Vehicle Internal ICD’s – Interfaces to MGV Subsystems

• HW Configuration Item Specifications (HW CIDS - as available)



What level of completion of Software Engineering work products is needed for Software to have a successful LCO/LCA?

To pass the LCO/LCA, what percent of the software requirements need to be documented? How is that measured?• What is the answer if there are a lot of requirements but the risks are

relatively low?

• What is the answer if there exist some risks, but feasibility analysis indicates they are manageable.

At what point should the requirements be baselined?• Defines what to measure volatility against

• Drives how much time is spent in various SCCB’s reviewing requirements changes during development iterations


Requirements Problems Specific to Software Intensive Systems

Lines between systems engineering and software engineering activities and work products are blurred• System/Subsystem/Component Engineers can over-specify requirements,

resulting in limited or no opportunities for software engineers to optimize the technical solution

• Software Engineers conversely may make decisions on what should properly be the purview of systems requirements, and may result in an incomplete system solution

What are proper requirement sets for various domains and levels is often open to interpretation• Especially when multiple organizations and cultures must interact


Volatility Concerns from Using UML for Requirements

UML sequence diagrams created by Systems Engineering to develop interfaces and logical behavior requirements pose challenges• A sequence represents only one path through a use case• A full set of alternative use cases cannot be easily expressed in this form

Textual requirements in a DBMS serve as the “official” allocation of requirements to software• Some problems translating between use case steps and “shalls”• Complete alternative use case specification always a problem

In one case, factoring out alternative use cases into a use case or DDM titled “Handle Operational Problem” is a concern.

– The Mother of all use cases/DDM’s. Software teams are strongly encouraged to use full-up text-based use cases to

specify behavior• Emphasis on handling all conditions and alternative/exception behavior

Can be major feasibility driver!• Non-behavioral requirements sections of SRS must be completed• Everyone has a requirement to follow Software Design Standards (Architecture

Decisions) to address horizontal consistency.• UML is used for software design and detailed interface design


Measuring Requirements Volatility

Mechanics of counting requirements changes• Add requirement

• Delete requirement

• Modify requirement Modify can also be achieved by a delete followed by an add

What is the requirements count measurement worth? What else could be measured with more value?• Consider statistics of implementation risk exposure, or estimated cost to

implement considering each requirement

• Other measures: have observed ratios of SLOC/Requirements Counts from 9 to 300 for different SI’s on BAE Systems programs.

• Have seen great volatility in requirements measurements caused by simply revising same requirements to be more understandable


Source of Requirements Volatility: Requirements vs. Design

Two approaches, sometimes conflicting: Requirements are essential attributes of a system to meet the stakeholders

needs• The requirements should represent an aspect of essential system behavior

• Similar systems should have similar levels of specification

• Avoid overconstraining the specification

Requirements describe whatever the stakeholders want• A requirement can be specified at any level of the system

• A requirement for one system might be a design choice for a similar system, depending on who the stakeholders are

Underlying assumption: The designer for a given system scope is granted authority to select and

optimize design elements to meet the requirements This requires negotiation and trust between the stakeholders


Sources of Requirements Volatility

Actors and Goals• All actors were not considered

• All goals/subgoals of the actors and system were not considered

Stakeholders and Interests• All stakeholders’ interests were not considered when the system was specified

The system must enforce or protect these interests Frequent cause of requirements changes

Architecture-derived requirements• Aspects of the selected architecture that must be specified for correct operation and

to meet quality attributes

• Can be a strong driver of lower-level requirements

General causes of change• A stimulus or condition that the system needs to respond to needs to be changed

• The system response to a stimulus or condition needs to change

• An architectural decision or constraint causes a change


Sources of Requirements Volatility

The requirement was not obvious, unknown, or sometimes even unknowable at the time of specification

Sufficient resources to complete the baseline work were not available All aspects of the requirements effort were not performed Without feedback, the systems/software analyst polishes the

requirements until they are perfect (this can go on forever) Emergent behavior not predictable Changes in forces driving the market, threat, technology, needs Architectural and system quality attributes potentially drive foundational

changes throughout the system Middleware layers that are not transparent to functionality change COTS products that bring along their own set of requirements and

constraints


Some Mechanisms for Coping with Requirements Changes

Build an architecture that is specifically designed to accommodate changes within specified limits• Product line architecture approach

• Extensible design patterns

• Will cost more up front, payoff comes later

• Cost/benefits analysis and estimation modeling needed to justify

Prioritize requirements implementation as dependent variable• SAIV, CAIV

• Hard to say no, but must make decisions

• Potential research areas: decision analysis approaches, strategies, toolsets, decisions with uncertainty, decision-maker utility functions for consistency and attitude towards risk

Reserve budget (cost/schedule) for requirements changes as a function of project parameters. How should this be calculated?

1February 14, 2007 © 2007 BAE Systems Land & Armaments L.P. February 14, 2007 Tom Schroeder FCS MGV...

Documents

Transcript of 1February 14, 2007 © 2007 BAE Systems Land & Armaments L.P. February 14, 2007 Tom Schroeder FCS MGV...