Enablers and Inhibitors for Expediting Systems and Software Development

University of Southern CaliforniaCenter for Systems and Software Engineering

Enablers and Inhibitors for Expediting Systems and Software Development

Sue Koolmanojwong and Jo Ann LaneCOCOMO ForumOctober 16, 2012


2

Overview• Characterize “expediting”• Overview of current research• Enablers and Inhibitors for “expediting”

– Single system– Systems that participate in one or more systems of

systems (SoS)– SoS capabilities

• Observations


3

What Does it Mean to “Expedite Systems Engineering”?

• Expedite “systems engineering” or “system development”?– Most are interested in “system development”:

Capability development schedule from concept to delivery

– Some will include enhancement, maintenance, retirement

Early decisions can affect ability to expedite later….


4

General Ways to “Expedite”• Minimal engineering/quick solutions• Minimal features• Commercial-off-the-Shelf (COTS) solutions• Lean approach

– Eliminate non-value adding activities– Reduce wait times

• Pacing– Go slow to establish good

• Foundation• Architecture• Interfaces• Relatively low complexity

– Then go fast


5

Balancing “Expedited Engineering”• Trades to consider when “expediting”

– Long term affordability– Flexibility/adaptability for meeting future needs– Desired level of performance/speed/throughput– Maintainability– Securability– … and others

• Trades may– Reduce future flexibility– Result in

• Degradation of existing capabilities• System limitations• Later reworkDepending on the situation/need, it may be OK to

incur technical debt….


6

Tradespace Example: System Flexibility

• Goal of “flexibility” is to go beyond quick solution to build in flexibility that will allow system to – Easily evolve in the future to meet future (often unknown)

needs– Interoperate with future systems (e.g., in one or more

SoS environments)• Must balance “flexibility” with “complexity”

– Performance issues may result if system tries to be “everything for everyone”

• Ways to evaluate flexibility– Total ownership costs– Option analyses using Monte Carlo techniques


7

Expediting Development and Increasing Value through Flexibility*

• Flexibility in design– Routinely improves expected value by 25% or more– Enables system to

• Avoid future downside risks• Take advantage of new opportunities

– Often reduces initial capital expenditures• Greater expected value at less cost• Enables manager to better control the risks• Substantial increases on the return on investment

• “Sweet-spot” found through Monte Carlo analysis of business options– Identifies how much engineering/system performance/system capacity

is enough– Allows future decisions/investments to be made when more is known

about the future• Types of flexibility to explore depend on the context

* Richard de Neufville and S. Scholtes, Flexibility in Engineering Design, The MIT Press, Cambridge MA, 2010.


Factors in Expedited Systems Engineering

• 2012 PSM Workshop– Representatives from commercial, military/ defense, and

academic sectors– List the enablers and inhibitors

• A Single System• An Existing Single System• A System of Systems

– Rate High, Medium, Low for the impact level

8


Enablers and Inhibitors

9

A Single System An Existing Single System A System of Systems

• A clean sheet of paper• Greenfield• Considerable freedom in

development• NDI • Architecture• Process choices

• Enhancement, Maintenance, Perfection

• Brownfield or continuation of previously Greenfield

• Major of minor modification after first delivery

• Multidisciplinary• Constituent-systems are

operationally independent • Diseconomy of scale


Top 10 Inhibitors – Similarities

10

A New Single System An Existing Single System A System of Systems

Requirements Volatility Requirements Volatility Lack of Interoperability

Unprecedentedness High numbers of external interfaces Lack of / incompatible standard & protocol

Delayed authority to proceed/start with fixed milestone Unprecedentedness Requirements Volatility

Infeasible schedule/staffing profile Vague Requirements Unprecedentedness

Lack of Domain Experience Embedded poor quality software High numbers of external interfaces

Technology Volatility Conflicting Stakeholders Infeasible schedule/staffing profile

High numbers of external interfaces Delayed authority to proceed/start with fixed milestone Inability to test across systems

Vague Requirements Infeasible schedule/staffing profile Delayed authority to proceed/start with fixed milestone

Under average people / Personnel Capability Technical debt Lack of Domain Experience

Technology Immaturity Interoperability / compatibility Technology Volatility


Top 10 Inhibitors – Differences

11


Requirements Volatility Requirements Volatility Lack of Interoperability

Unprecedentedness High numbers of external interfaces Lack of / incompatible standard & protocol

Delayed authority to proceed/start with fixed milestone Unprecedentedness Requirements Volatility

Infeasible schedule/staffing profile Vague Requirements Unprecedentedness

Lack of Domain Experience Embedded poor quality software High numbers of external interfaces

Technology Volatility Conflicting Stakeholders Infeasible schedule/staffing profile

High numbers of external interfaces Delayed authority to proceed/start with fixed milestone Inability to test across systems

Vague Requirements Infeasible schedule/staffing profile Delayed authority to proceed/start with fixed milestone

Under average people / Personnel Capability Technical debt Lack of Domain Experience

Technology Immaturity Interoperability / compatibility Technology Volatility


Top 10 Enablers - Similarities

12


Rapid Prototyping Target hardware lab / test like you fly & simulation Customer /tech requirements flexibility

Target hardware lab / test like you fly & simulation Incremental test and feedback Rapid Prototyping

Customer /tech requirements flexibility Incremental Delivery & feedback Target hardware lab / test like you fly & simulation

Incremental test and feedback Flexible / Tailorable rules Incremental test and feedback

Incremental Delivery & feedback Agile/lean approach Common standard and protocol

Decision making authority Rapid Prototyping Reusing assets

Best people / personnel capability Common standard, interface Tools and automation

Agile/lean approach Customer /tech requirements flexibility Common standard, interface

Less context switching when doing multiple projects Domain knowledge Best people / Personnel Capability

Tools and automation Understanding of the existing system and interfaces Team cohesion


Top 10 Enablers - Differences

13


Rapid Prototyping Target hardware lab / test like you fly & simulation Customer /tech requirements flexibility

Target hardware lab / test like you fly & simulation Incremental test and feedback Rapid Prototyping

Customer /tech requirements flexibility Incremental Delivery & feedback Target hardware lab / test like you fly & simulation

Incremental test and feedback Flexible / Tailorable rules Incremental test and feedback

Incremental Delivery & feedback Agile/lean approach Common standard and protocol

Decision making authority Rapid Prototyping Reusing assets

Best people / personnel capability Common standard, interface Tools and automation

Agile/lean approach Customer /tech requirements flexibility Common standard, interface

Less context switching when doing multiple projects Domain knowledge Best people / Personnel Capability

Tools and automation Understanding of the existing system and interfaces Team cohesion


ObservationsFlip side of a coin

14

Enablers Inhibitors

Best people Under average people

Decision making authority Lack of decision making authority

Team Cohesion Conflicting stakeholders

Incremental Test and Feedback Inability to test across systems


ObservationsGrey Area

• Common standard• Flexible rules

• Requirements Volatility• Requirements Flexibility

• Agile/lean approach• Constituent Documentation

15


ObservationsOverlap & Similar but not the same

• Lack of Domain Experience• Unprecedentedness

• Technology Immaturity• Technology Volatility

• Lack of decision making at lower levels• Lack of decision making authority

16


Next Steps• Consolidate list of enablers and inhibitors

– Considerable overlap• Continue

– Identification of enablers and inhibitors– Solicit additional evaluations of enablers and inhibitors

• Evaluate related technical debt issues• Map enablers and inhibitors to cost model

parameters• Refine cost models using

– Enablers/inhibitors– Technical debt information


Backup Charts


Conclusions, Recommendations, and Results Single System New

Number Identified

Estimated Impact Levels (5 assessments)High Medium Low

Enablers 26 37 55 35

Inhibitors 29 29 70 42

Single System Existing

Number Identified



Inhibitors 35 32 89 46

SoS Number Identified



Inhibitors 35 49 84 37Scope of enablers and inhibitors: People, process, tools, product


A New Single System

20

Rank Enablers Inhibitors1 Rapid Prototyping Requirements Volatility2 Target hardware lab (experimentation / test lab) /

test like you fly & simulationUnprecedentedness

3 Customer /tech requirements flexibility Delayed authority to proceed/start with fixed milestone

4 Incremental test and feedback Infeasible schedule/staffing profile5 Incremental Delivery & feedback Lack of Domain Experience6 Decision making authority Technology Volatility7 Best people / personnel capability High numbers of external interfaces8 Agile/lean approach Vague Requirements9 Less context switching when doing multiple

projectsUnder average people / Personnel Capability

10 Tools and automation Technology Immaturity11 Common standard, interface Conflicting Stakeholders12 Flexible / tailorable rules Lack of decision making authority13 Model-based engineering large number of subcontractors / stakeholders14 Building the common architecture/foundation Lack of development infrastructure15 Reusing assets Rules and Regulations16 Risk Management Sequential Development17 Team cohesion Classification / sensitivity18 Business process reengineering / process

streamliningFear to protest the contract award resulting in poor requirements

19 COTS Personnel Turnover20 Overnight build Bad RFP


An Existing Single System

21

Rank Enablers Inhibitors1 Target hardware lab (experimentation / test lab) Requirements Volatility2 Incremental test and feedback High numbers of external interfaces3 Incremental Delivery & feedback Unprecedentedness4 Flexible / tailorable rules Vague Requirements5 Agile/lean approach Embedded poor quality software6 Rapid Prototyping Conflicting Stakeholders7 Common standard, interface Delayed authority to proceed/start with fixed

milestone8 Customer /tech requirements flexibility Infeasible schedule/staffing profile9 Domain knowledge Technical debt

10 Understanding of the existing system and interfaces

Interoperability / compatibility

11 Best people / personnel capability large number of subcontractors / stakeholders12 Less context switching when doing multiple

projectsBackpropagation

13 Tools and automation Lack of understanding of the existing system and interfaces

14 Reusing assets Under average people / Personnel Capability15 Team cohesion Lack of Domain Experience16 Feasibility Evidence, Milestone review Technology Volatility17 Model-based engineering Technology Immaturity18 Colocation of hw & sw engineers Classification / sensitivity19 Development process tailoring/adjustment Multiple operational sites with different

configuration / platform / OS20 Risk Management Outdated / stovepipe technology


A System of Systems

22

Rank Enablers Inhibitors 1 Customer /tech requirements flexibility Lack of Interoperability2 Rapid Prototyping Lack of / incompatible standard & protocol3 Target hardware lab (experimentation / test lab) /

test like you fly & simulationRequirements Volatility

4 Incremental test and feedback Unprecedentedness5 Common standard and protocol High numbers of external interfaces6 Reusing assets Infeasible schedule/staffing profile7 Tools and automation Inability to test across systems8 Common standard, interface Delayed authority to proceed/start with fixed

milestone9 Best people / Personnel Capability Lack of Domain Experience

10 Team cohesion Technology Volatility11 Synchronization and Stabilization Technology Immaturity12 flexible / tailorable rules Vague Requirements13 Model-based engineering Large number of subcontractors / stakeholders14 Building the common architecture/foundation Lack of development infrastructure15 Agile/lean approach Lack of communication between teams 16 Incremental Delivery & feedback Classification / sensitivity17 COTS Poor / unknown heritage/pedigree18 Constituent Documentation Bad RFP19 Decision making authority Personnel Turnover20 Development process tailoring/adjustment Under average people / Personnel Capability


Recent Research Overview

23

Key Approaches for Expedited Engineering Commercial-Off-the-Shelf (COTS) ProductsInvestment in product-line architecturesReuse of existing systems/componentsRepurposing existing systems/componentsValue-stream focus (lean)Going fast in general (crisis response)Single purpose architecture

Using the right

people

Key Approaches for Incorporating FlexibilityEmploy open architecturesDesign for reuseDevelop/use product linesStandard interfaces, protocols, services, data

Options-based design Incremental commitment

Common Causes of Technical DebtPressures to compress scheduleLack of requirements understandingLack of system understandingInflexible architectures/softwareOverly complex design/implementationDelayed defect resolutionInadequate testingLack of current documentationParallel development in isolationDelayed refactoring

Can be extended to incorporate other “-ilities”…

Capability OptionsNew system or system of system(s)New procedures for using existing systemsChanges to existing system or SoS - Some robust, well integrated - Others very fragile, close to end of life - Which to invest in/which to retireExisting vs. new technologies

How much, how fast, how accurate, etc. is enough

What is useful, affordable,

and sustainable?


24

Single System Development Perspective

Choices driven by potential– Market share– Future opportunities– Technical debt– Cost of failure to provide needed

capability

Enablers and Inhibitors for Expediting Systems and Software Development

Documents

Transcript of Enablers and Inhibitors for Expediting Systems and Software Development