MEMOindicate, First Submission, Second Submission, or Final Sub.docx

MEMO
<indicate, First Submission, Second Submission, or Final
Submission>
FROM: <insert student name>
TO: Professor
DATE: <insert date>
SUBJECT: Memo on <insert speaker name>, <insert title of
speaker’s presentation in quotes>
On February XX, 2015 in the SELP 694 Seminar Class, Mr.
XYZ presented a lecture entitled “Systems Engineering LMU
SE Seminar Class.” Mr. XYZ is currently the Vice President of
ABC Corp. Mr. XYZ graduated from XYZ University and
joined the US Navy to work in various intelligence positions
and travelled throughout the world.
Mr. XYZ described the typical career path for a systems
engineer including the expectations and responsibilities of the
various positions. Furthermore, Mr. XYZ shared the different
aspects of business sizes and how to develop new business in
both the commercial and government arenas.
Mr. XYZ started off the seminar with a concept called
“MATTESS,” which stands for “Money, Advancement, Travel,
Training, Experience, Satisfaction, and Security.” The concept
states that an employee is motivated to do their best work by at
least one of the aforementioned items. System engineers usually
promote themselves out of a job, which includes the transition
to engineering management, then managing engineering, then
program management, and finally business development.
Transitioning to engineering management requires good
communication and motivational skills. In addition,

transitioning to managing engineering requires the
understanding of corporate goals as well as management of
budgets, schedules, requirements, and business strategy
development. Furthermore, transitioning to program
management requires successful budget, schedule, requirements,
and new business development as well as providing key
interactions with the customer. Lastly, transitioning to business
development requires a good understanding of how business is
generated, engaging customers and competitors, helping the
customer sell the solution, find funding, and finally keeping the
program sold. Mr. XYZ described the different business sizes
including the large-sized businesses such as Lockheed Martin
and Northrop Grumman, medium-sized businesses such as
Honeywell and Rockwell Collins, and finally small-sized
businesses, which are the largest growing market segments
relied upon by the government and large-sized businesses.
Mr. XYZ’s presentation made me realize that satisfaction is
what motivates me to do my best work as a subcontracts
manager at my company. Furthermore, my position allows me to
transition into my company’s business development area and I
found Mr. XYZ’s presentation useful in helping me achieve my
promotion goal into this new area.
I found the speaker very engaging and I appreciated his
openness with his personal life which allowed the audience to
connect more with him on a personal level. I also appreciated
the information he shared about the current and future financial
situation of the nation that allowed us to remain optimistic
about our future business and security.
Class note 03/19/2015 “ Economics, policy and political
processes”
Look at the speaker’s bio in page 1-5

what are the areas in terms of cost and software and the
impact of it for new project and how we estimate the cost? The
cost has an important role within the program/ project life cycle
especially in the Aerospace companies who has a complex
system in their large projects.
Not only establish cost but also schedule is important.
Timeframe to estimate the budget during the expected
timeframe. There is a lot of regulation that should be considered
like safety. In order to make the project successful you should
mitigate the risks.
Page 7: the circle shows the domain of the system arch in any
project. Once you get out of the circle “ less technical focus
will be” all of them affect each other.
Think about what important to them because they all involve
into the program/project.
Page 8: political system is large
Page 9: political system its not an easy to model and figure it
out because its deals with many people decisions and
perspectives
Page 10: design the project “ the process”
Page 11: why so complex? Business people, contractors, they all
involves
Page 12: economics associated with these kinds of project
Page 13: negotiate what might be needed “ coping is important”
* Usually in aerospace company they do research and see who
they are ganna deal with before they start any new project
(PLAN TIME AHEAD)
Page 14: value judgment= “Budget”

What’s most important to the nation before start the project?
NASA tries very hard to capture the challenge into the new
generation in order to success
Page 15: federal budget and funds it’s the most important aspect
Page 16: Heuristics, which mean lessons learn, for example,
Murphy’s rule: if you don’t have time to six it now, you will
have time to fix it later!
What those facts and heuristics needed? The speaker gave 5
examples of heuristics that involves in the political processes..
its all about balance heuristics keeping in mind! Not to go broad
but control and capture the real picture for the project
Page 17: talks about Macro level in politics that deal with
government and large program. What’s important to the project
manager and customer in any program, the have different
perspectives in any problem/project. Try to understand where
they come from. EX: a lot of seniors managers don’t know what
important to them, so smart buyer should know how to deal with
different industries. Project managers should be aware of what
going on into their project in certain aspects that related to their
program.
* Good relationship between the government and the industry is
crucial in order to have good measures
Page 18-19-20: X diagram / Systems Engineering Vee shape:
apply the Vee, which is SE processes and convert it into X
shape in Aerospace companies:
Congress and taxpayer involves
*System program director in first shape pg.18
*Industry program manager: goes to sector level then corporate
returns
* X diagram: shows the relationships between both of SE
director and program manager

finical pyramid and how we use it?
Becomes the link between them and use the additional money to
the opportunities
Page 22: what kind of metrics needed in the program? Project
manager is involve along with system program director and
CEO and other
Page 24-25: Shows the area that should be considered in new
complex project especially cost, technical & schedule baseline.
Arrange requirements in acquisitions contracts. Having specific
processes to follow in any project will absolutely help
mitigating risks.
Page 26: Tom Young Case Study “ rather than focus in mission
success, the individual engineers make decisions that impact the
whole project.
Page 27: Some additional heuristics that related to cost &
schedule.
Page 28: stability by manage the baselines “cost, capability,
schedule, requirements and architecting “ carefully
Page 30: Next generation systems & software cost estimation by
Barry Boehm:
If u had better communication between system to system &
share info & data, will affect the project positively.
Page 31: for most cost effectiveness, narrowing CU “ Cone of
uncertainty” is better than start to build something from scratch
Page 32: better to describe what really needed to put into the
model and how many interfaces & requirements do I have?
Estimate efforts to estimate cost?
Page 33: Rapid change & technology is a big threat!

Rapid change creates a late CU/ arrange and plan the
budget during the lifecycle of the project
Page 35: example that clarify how much you need to build to
reach full operational capability!
Page 36: net-centric systems of systems
Page 37-38: summary table
Page 39: system of system challenge. What really matter here is
skills in people with communication and negotiating and
leadership skills
Page 40: Examples of cost derivers that help you define in your
project. What technology needed? And other factors … etc
“Comparison of cost model parameters”
Page 41: always on never fail systems: balance agility &
discipline
Page 42: how to estimate the high-reliability, you really need to
look to whole model parameters and determine any additional
cost.
Page 43: challenges in cost estimation in the future!!
· It’s very important to write how this topic will influence or
impact your organization and how it will help you in your
business.
From my experience, I was able to start my own simple
company, and design and produce my own line of clothing
accessories. I have exhibited my work throughout the Middle
East, including exhibitions in Riyadh, Jeddah, and Kuwait. By

growing Guzal Collections, I seek to elevate myself to the
position of CEO of my own major Saudi fashion company.
Economics, Policy and Political Process
Presentation to LMU Systems Engineering Leadership Program
Marilee J. Wheaton
March 19, 2015
*
Marilee J. Wheaton
Education:
Bachelor Degrees in Math and Spanish
Magna Cum Laude, California Lutheran University
Graduate coursework in Mechanical Engineering (Thermal
Fluids)
California State University, Northridge

Masters in Systems Engineering from USC Viterbi
Industrial and Systems Engineering Department, 1993
UCLA Executive Education Program
Anderson School, 2001
PhD Program, Systems Architecting and Engineering,
Astronautical Engineering Department, USC Viterbi
CMMI certified team member, Six Sigma Black Belt training
Marilee J. Wheaton
Work Experience:
Started at Lockheed California Company in Burbank
The Aerospace Corporation, from 1980 to 1999 and 2002 to
present
FFRDC for Space Systems, GSE&I, Architect-Engineer for
Space Systems
Currently Systems Engineering Fellow, Systems Engineering
Division
Previously General Manager, Computer Systems and Systems
Engineering Divisions, The Aerospace Institute
Previous program office experience in Milstar, SDI Programs,
Ground Systems programs (AFSCN, IC)
Industry experience at TRW Systems (now NGIS) from 1999 to
2002
Marilee J. Wheaton
Teaching Experience:
USC Viterbi School of Engineering
Originally taught CS 510, Software Engineering Economics,
Fall 2003

Request by Dr. Barry Boehm, Director CSSE, who was on
sabbatical
Then started teaching SAE 549 in 2004 through 2008
Share Dr. Rechtin’s vision for the importance of system
architecting concepts and heuristics
Fall 2006 taught ISE 561, Advanced Engineering Economics
Fall 2008, Spring and Fall 2009, Co-Developer and Instructor,
SAE 560, Economic Considerations for SAE
Fall 2010, Full circle to CS 510 again
Spring 2011, Back to SAE 549
Spring 2013, Back to SAE 560
Marilee J. Wheaton
Professional Affiliations:
Fellow, AIAA
Immediate Past Chair, Economics Technical Committee
Leadership Team, Space 2009 through Space 2011 Conferences
Fellow Life Member, Society of Women Engineers
Past SWE LA President, National Life Membership Coordinator
Long time active member in Cost Societies
International Society of Parametric Analysts (ISPA) and Society
for Cost Estimating and Analysis (SCEA)
Past Board Chair, Board Member and Conference Chair for
ISPA
Member, Space Systems Cost Analysis Group
Fellow, International Council on Systems Engineering
(INCOSE)
Member, Corporate Advisory Board (CAB)
Technical Program Chair, CSER 2011 and 2014
*
Management Relationships:

The Political ProcessWhy is this subject important?Some
reasons why an engineer might care:The political process
determines budgetsThe political process often sets time limits to
accomplish a projectAnd then doesn’t provide enough resources
to accomplish that projectThe political process often imposes
regulations and constraints on designs
*
*
The Political ProcessThe domain of the system architect in a
project:
*
*
The Political ProcessThe political system:Not just formal
political institutions (Congress & White House)Interagency
rivalriesIntra-agency tensionsDozens of lobbying
groupsInfluential external review groupsPowerful individuals
both within and outside governmentAnd always, the media

*
*
The Political ProcessThe political system:Extremely complex
interactionImpossible to model quantitativelyToo many
variablesMost unquantifiableConstant unpredictable change
Confusing, sometimes chaoticBut -- determines budgetary
funding levels
*
*
The Political ProcessEither enables engineering design process
to go forward or imposes constraints:Budget cutsSchedule
stretch outsTechnical reviewsReporting requirementsThreat of
outright cancellation
*
*

The Political ProcessWhy so complex?Power is very widely
distributed in WashingtonNo single, clear-cut locus of authority
to support for long-term, expensive programsSupport must be
cobbled together from grab-bag of widely varying groupsEach
may perceive program's worth very differently; interests may
diverge radically when pressure is on
*
*
The Political ProcessCoping skills for the modern design
engineer:First essential skill: ability to think in its termsMust
understand: political process logic system is entirely different
from the one in which scientists and engineers are trainedD.C.
uses logic of politics, which is rigorous - but:Premises & rules
profoundly different from scientific & engineering logicWill
repeatedly arrive at different conclusions on basis of same data
*
*
The Political ProcessCoping skills for the modern design

engineer:Scientific/engineering proof = firm assumptions +
accurate data + logical deductionPolitical logic structured
entirely differentlyNot logical proofBased on negotiation,
compromise & appearancesProof = "having the votes" If so:
program = worthy, useful and beneficial to the nationIf not: no
matter what its technological merits, will lose out
*
*
The Political ProcessFocal point for the system architect’s study
is the budget processThe budget: the ultimate political value
judgmentThat's where the money isNo money means no
program, regardless of need or of the program’s technical
meritRemember that this value judgment repeated each year
*
*
The Political ProcessFederal budget process best understood as
struggle over political values because outcome embodies
nation's current consensus (or its lack) as to the relative
importance of its innumerable prioritiesGovernment is nothing
like military or corporationNo "bottom line" instead, must

decide what its goal is
*
*
The Political Process
The facts of life:Not in priority order!All are “money =
politics”
#1 Politics, not technology, controls what technology is
allowed to achieve
#2 Cost rules
#3 A strong, coherent constituency is essential
#4 Technical problems become political problems
#5 The best engineering solutions are not necessarily
the best political solutions
*
*
Smarter Buyer 1 Course Primary Learnings
Key topics Wall Street Demands: How does influence of
Wall Street impact a government program?Sector Demands:
How do the aerospace/defense industry sector financials impact
individual program design and execution?Industry Bid/no-bid
decision making and customer influenceDemands on the

industry Program Manager: What does this mean for the System
Program Director (SPD)?Take Aways for Future ReferenceThe
“X” chart: The key players in government/industry interaction
and their roles The Financial Pyramid: financial measures
important to industrySmarter Buyer Reference Sheet: summary
of key points we heard from industry
*
Government Risk-Reward “Vee” Diagram
Top-Down
Demands and
Constraints
Program
Success
Contributions
Time
Demands (Risk)
Outcome
(Reward)
Space
Demands
Warfighter and
Policy Maker
Demands
Program
Demands
Space
Capabilities
Warfighter
Capabilities
Program
Capabilities

USecAF/DNRO
Portfolio
PEO’s and NRO Director’s Space
Portfolio
DoD/ IC
Budget
Obligate all money
Portfolio
Success
Mission Success
Space Budget
Program Requirements
And Constraints
System Program Director
Space
Contributions
to Mission Area
PEO’s Space
Portfolio
Congress
Taxpayers
DoD Department of Defense
IC Intelligence Community
*
SHAREHOLDERS
Industry Risk-Reward “Vee” Diagram
Top-Down
Demands and
Constraints
Program
Financial

Contributions
Time
Demands (Risk)
Financial Outcome
(Reward)
Sector
Demands
Wall Street
Demands
Program
Demands
Sector
Financials
Corporate
Financials
Program
Financials
CEO targets
for sectors
Sector targets
for programs
Industry Program Manager
Corporate
Returns
Sector
Returns
BOD
Corporate Financial
Expectations
Sector Portfolio
Returns
Corporate Earnings
Stability and
Predictability
Sector Expectations

Program Financial
Performance Pressures
Program Financial Returns
BOD Board of Directors
CEO Chief Executive Officer
ROI Return on Investment
ROS Return on Sales
Sector Demands
Mission Area pressures – if lose a competition than
corporation may be out for good
Business pipeline demands a fill to compensate for a lack of
backlog
Sector Efficiencies – extend brand
*
The “X” Diagram
Obligate all money
Demands (Risk)
(Reward)
Program
Demands
Program
Capabilities
System Program Director
Program Req’ts
And Constraints

Program
Financials
Program
Demands
Financial Outcome (Reward)
Demands (Risk)
DoD/IC Budget
Mission Success
Congress
Taxpayers
Corporate
Financials
Wall Street
Demands
Corporate Financial
Expectations
Corporate Financial Results
BOT
SHAREHOLDERS
Industry Program Manager
Program Financial Returns
Program Financial
Performance Pressures
Warfighter
and Policy
Maker
Demands
Warfighter
and Policy
Maker
Capabilities

Space Budget
Space
Demands
Space
Capabilities
Portfolio Success
Sector
Financials
Sector
Demands
Sector Portfolio
Returns
Sector Expectations
Government side is the creation of public goods
Contractor side is the creation of private good/creation of
wealth
What part of the X interactions do you think has the greatest
impact on the gov't program?
*

Financial Pyramid
What are these financial parameters?How do these parameters
relate to one another?What is the role of the CEO, Sector
GM/VP, and Program Manager in their use?How can the
government influence industry financial metrics?How do these
financial metrics impact your program?
This financial pyramid is the central link between Wall Street
and industry through the CEO, VP/GM, and the Program
Manager
Orders
Sales
Earnings/Cash Flow
Share Value
$
Opportunities
To an industry CFO cash management is as important as battle
management is to a warfighter. Non-attributed quote from an
industry CFO.
*
Shared Financial Risk Management Metrics
PM
SPD
Bus
Dev

VP/GM
CEO
Return metric
Cash flow
Schedule
Hurdle rate
Return metric
Sales Growth
Cash flow
Cash flow
Award fee
Acquisitions
Return metric
Sales Growth
Cash flow
Hurdle Rate
Bus Dev Business Developer
CEO Chief Executive Officer
GM General Manager (from sector)
PM Program Manager
SPD Systems Program Director
Return metric: ROI, ROS, RONA, profit margin, EBIT
ROI – Return on Investment
ROS – Return on Sales
RONA – Return on Net Assets
EBIT – Earnings Before Interest and Taxes
*
Smarter Buyer Reference Sheet

Industry Assessment: Necessary to understand changing
industry environment
· Competitive landscape
· Wall Street’s view of viability – the space industry and
individual contractor returns
· Contractor
· Recent won/lost record
· Margins for particular division/group – Return
· Backlog: What is the Contractor doing today – resources
available
· What else are they bidding on/timing overlap
· Skills and competencies – Past performance, subcontractors
· Strategic plan: to where or into what business do they want to
move, i.e. from sub to prime?
Risk/Return: understand the factors and relationships to keep
this in balance
· Risk and success factors defined and understood – Technical,
Schedule, Cost
· Program return is commensurate with risk for Contractor
· Consistency between contract T’s and C’s – and what is to be
incentivized
Cost: be aware of the motivations behind the cost figures
· Realistic independent cost estimate

· Is the proposal a bid-to-win or price-to-cost (Incumbent loses
75% of the time)
· Focus on value proposition of Contractor/proposal and not
overly emphasized on cost
Cash Flow: help consistent Contractor earnings
· Make regular payments: both for schedule and actual receipts
· Timed between front-end and back-end: between progress
payments and in-orbit success
· Structure savings so that Contractor is able to keep some
Process: Integrate the Gov’t and Contractor business processes
and communication
· Insure optimal requirements understanding and evaluation -
adequate time between draft and final RFP and also between the
RFP and Proposal Submittal
· Optimal timing between Source Selection and Program stand-
up to minimize resources under/non-employed
· Communication often along entire process
Metrics: Understand metrics used by Contractor levels of
management
· Internal metrics Contractor used to measure progress of
program
· Access to data; how often and by what vehicle info shared
· Realize that internal metrics change may also change
contractor performance
Fee: Design and maintain a fee structure that incentives the

right success goals
· Spread among base, award and incentive
· Split among tech, schedule, cost and management that is
aligned with goals
· Adequate pool as a motivation incentive for contractor to
respond to Government concerns
· Unearned portion with possibility of rollover
*
Top 10 IPA Team Finding Areas
Poor government cost baseline (e.g., awarding the acquisition
contract based on less than government cost estimate)
Poor schedule baseline (e.g., awarding the acquisition contract
based on a schedule shorter than government schedule estimate,
“meet me at the pass” planning, not using technology on/off
ramps effectively
Changes in major requirements after acquisition contract award
4. Poor government SPO technical baseline (e.g., at KDP
B)Missing or poor SOO, TRD, WBS/SOW, CARD, Approved
Acquisition StrategyCutting corners during preparation to save
time in getting on contractUsing success-oriented plans (over
promise/ under perform)Assuming that none of those problems
that other programs have encountered will happen to this
program
Source: S. Soderquist, Director, SMC Acquisition Center of

Excellence (ACE),
presented Jan 2007 Space Systems Cost Analysis Group
(SSCAG) Meeting
*
Top 10 IPA Team Finding Areas (Cont.)
5. Poor contractor processes and poor implementation of those
processes
IMS/IMP, EVMS, engineering/qualification equipment
Parts/box/subsystem/system testing, configuration control
Poor government oversight of contractor processes and testing
7. Program disruption due to problems in government decisions
Time required to provide data to independent teams, and lack of
timely access to decision makers
Time required for RFP preparation and source selection
Budget cut drills
Difficulties in meeting obligation and expenditure standards,
resulting in OSD budget cuts
8. Other system engineering shortfalls
Test and Evaluation planning, requirements decomposition and
traceability, trades, interface planning
9. SPOs not applying the lessons learned and best practices
derived from past program experience
10. Too few qualified people in the SPO and contractors
*

Tom Young Panel on NSS Acquisition
Cost #1, not mission success
Unrealistic estimates = unrealistic budgets = unexecutable
programs
Undisciplined system requirements
Government space acquisition capabilities seriously eroded
Industry failed to implement proven management and
engineering practices
*
*
Cost and Schedule EstimatingRecognizes that best value is not
necessarily lowest cost bid
Government must place value on non-deliverables essential to
mission success (Examples: SE, MA, QA,…)Then industry will
also value themExclude “name-that-tune-in-three-notes” bids
Has a well-established Independent Cost Estimating (ICE) and
program control function
Budget program to 60 - 80% confidence, including a
management reserve sized by riskExpend reserves to execute
unforeseen elements of baseline program—not new
requirements
*

StabilityStable, manageable baselines—requirements, budget,
and schedule also include managing expectationsManage
necessary but unplanned changesRigorous systems engineering
process for
assessing impact of new requirements New requirements must
come with new funding
Allows trade spaces vs. “cast-in-concrete”
requirementsCapabilities, cost, and schedule
Architectures that allow right-sized programs
(can be executed in about 5 years)Regulates appetite of user
community
University of Southern California
Center for Systems and Software Engineering
Next Generation Systems and Software Cost Estimation
Barry Boehm, USC-CSSE
*
Many people have provided us with valuable insights on the
challenge of integrating systems and software engineering,
especially at the OSD/USC workshops in October 2007 and
March 2008. We would particularly like to thank Bruce Amato
(OSD), Elliot Axelband (Rand/USC), William Bail (Mitre), J.D.
Baker (BAE Systems), Kristen Baldwin (OSD), Kirstie Bellman
(Aerospace), Winsor Brown (USC), Jim Cain (BAE Systems),

David Castellano (OSD), Clyde Chittister (CMU-SEI), Les
DeLong (Aerospace), Chuck Dreissnack (SAIC/MDA), Tom
Frazier (IDA), George Friedman (USC), Brian Gallagher (CMU-
SEI), Stuart Glickman (Lockheed Martin), Gary Hafen
(Lockheed Martin), Dan Ingold (USC), Judy Kerner
(Aerospace), Kelly Kim (Boeing), Sue Koolmanojwong (USC),
Per Kroll (IBM), DeWitt Latimer (USAF/USC), Rosalind Lewis
(Aerospace), Azad Madni (ISTI), Mark Maier (Aerospace),
Darrell Maxwell (USN), Ali Nikolai (SAIC), Lee Osterweil
(UMass), Karen Owens (Aerospace), Adrian Pitman (Australia
DMO), Art Pyster (Stevens), Shawn Rahmani (Boeing), Bob
Rassa (Raytheon), Don Reifer (RCI/USC), John Rieff
(Raytheon), Stan Rifkin (Master Systems), Wilson Rosa
(USAF), Walker Royce (IBM), Kelly Schlegel (Boeing), Tom
Schroeder (BAE Systems), David Seaver (Price Systems), Rick
Selby (Northrop Grumman), Stan Settles (USC), Neil Siegel
(Northrop Grumman), Frank Sisti (Aerospace), Peter Suk
(Boeing), Denton Tarbet (Galorath), Rich Turner (Stevens), Gan
Wang (BAE Systems), and Marilee Wheaton (Aerospace), for
their valuable contributions to the study.
Next-Generation Measurement ChallengesEmergent
requirementsExample: Virtual global collaboration support
systemsNeed to manage early concurrent engineeringRapid
changeIn competitive threats, technology, organizations,
environmentNet-centric systems of systemsIncomplete visibility
and control of elementsAlways-on, never-fail systemsNeed to
balance agility and discipline

The Broadening Early Cone of Uncertainty (CU)Need greater
investments in narrowing CUMission, investment, legacy
analysisCompetitive prototypingConcurrent
engineeringAssociated estimation methods and management
metrics
Larger systems will often have subsystems with narrower CU’s
Global Interactive,
Brownfield
Batch, Greenfield
Local Interactive,
Some Legacy
18 February 2009
©USC-CSSE
*
X8
X4
X2
*
COSYSMO

Size
Drivers
Effort
Multipliers
Effort
Calibration
# Requirements
# Interfaces
# Scenarios
# Algorithms
Volatility Factor Application factors8 factors Team factors6
factors Schedule driver
WBS guided by
ISO/IEC 15288
COSYSMO Operational Concept
*
Next-Generation Systems ChallengesEmergent

©USC-CSSE
*
15 July 2008
Rapid Change Creates a Late Cone of Uncertainty
– Need evolutionary/incremental vs. one-shot development
Uncertainties in competition, technology, organizations,
mission priorities
*
There is Another Cone of Uncertainty: Shorter increments are
better
Uncertainties in competition and technology evolution and
changes in organizations and mission priorities, can wreak
havoc with the best of system development programs. In
addition, the longer the development cycle, the more likely it
will be that several of these uncertainties or changes will occur
and make the originally-defined system obsolete. Therefore,
planning to develop a system using short increments helps to
ensure that early, high priority capabilities can be developed
and fielded and changes can be more easily accommodated in
future increments.
Feasibility
Concept of Operation

Rqts. Spec.
Plans and Rqts.
Product Design
Product Design Spec.
Detail Design Spec.
Detail Design
Devel. and Test
Accepted Software
Phases and Milestones
Relative
Cost Range
x
4x
2x
1.25x
1.5x
0.25x
0.5x
0.67x

0.8x
Effects of IDPD on Number of IncrementsModel relating
productivity decline to number of builds needed to reach 8M
SLOC Full Operational CapabilityAssumes Build 1 production
of 2M SLOC @ 100 SLOC/PM20000 PM/ 24 mo. = 833
developersConstant staff size for all buildsAnalysis varies the
productivity decline per buildExtremely important to determine
the incremental development productivity decline (IDPD) factor
per build
2M
8M
SLOC
*
Equivalent SLOC Paradoxes:
Not a measure of software size
Not a measure of software effort
Not a measure of delivered software capability
A quantity derived from software component sizes and reuse
factors that helps estimate effort
Once a product or increment is developed, its ESLOC loses its
identity
Its size expands into full SLOC
Some people apply reuse factors to this to determine an ESLOC
quantity for the next increment
But this has no relation to the product’s size

Some savings: more experienced personnel (5-20%)
Depending on personnel turnover rates
Some increases: code base growth, diseconomies of scale,
requirements volatility, user requests
Breakage, maintenance of full code base (20-40%)
Diseconomies of scale in development, integration (10-25%)
Requirements volatility; user requests (10-25%)
Best case: 20% more effort (IDPD=6%) Worst case: 85%
(IDPD=23%)
Further Attributes of Future Challenges
©USC-CSSE
*
18 February 2009TypeExamplesProsConsCost
EstimationSystems of SystemsDirected: Future Combat Systems

Acknowledged: Missile Defense Agency Interoperability
Rapid Observe-Orient-Decide-Act (OODA) loopOften-
conflicting partner priorities
Change processing very complexStaged hybrid models
Systems engineering: COSYSMO
Multi-organization development costing
Lead Systems integrator costing
Requirements volatility effects
Integration&test: new cost driversModel-Driven
DevelopmentBusiness 4th-generation languages (4GLs)
Vehicle-model driven developmentCost savings
User-development advantages
Fewer error sourcesMulti-model composition incapabilities
Model extensions for special cases (platform-payload)
Brownfield complexities
User-development V&VModels directives as 4GL source code
Multi-model composition similar to COTS integration,
Brownfield integrationBrownfieldLegacy C4ISR System
Net-Centric weapons platform
Multicore-CPU upgradesContinuity of service
Modernization of infrastructure
Ease of maintenanceLegacy re-engineering often complex
Mega-refactoring often complexModels for legacy re-
engineering, mega-refactoring
Reuse model for refactored legacy

Further Attributes of Future Challenges (Continued)
©USC-CSSE
*
18 February 2009TypeExamplesProsConsCost
EstimationUltrareliable SystemsSafety-critical systems
Security-critical systems
High-performance real-time systemsSystem resilence,
survivability
Service-oriented usage opportunitiesConflicts among attribute
objectives
Compatibility with rapid changeCost model extensions for
added assurance levels
Change impact analysis modelsCompetitive
PrototypingStealth vehicle fly-offs
Agent-based RPV control
Combinations of challengesRisk buy-down
Innovation modification
In-depth exploration of alternativesCompetitor evaluation often
complex
Higher up-front cost
But generally good ROI
Tech-leveling avoidance often complexCompetition preparation,
management costing
Evaluation criteria, scenarios, testbeds
Competitor budget estimation
Virtual, proof-of-principle, robust prototypes

Net-Centric Systems of Systems ChallengesNeed for rapid
adaptation to changeSee first, understand first, act first, finish
decisivelyBuilt-in authority-responsibility
mismatchesIncreasing as authority decreases through Directed,
Acknowledged, Collaborative, and Virtual SoS
classesIncompatible element management chains, legacy
constraints, architectures, service priorities, data, operational
controls, standards, change priorities...High priority on
leadership skills, collaboration incentives, negotiation support
such as cost modelsSoS variety and complexity makes
compositional cost models more helpful than one-size-fits-all
models
October 2007
©USC-CSSE
*
Comparison of Cost Model ParametersParameter
AspectsCOSYSMOCOSOSIMOSize drivers# of system
requirements
# of system interfaces
# operational scenarios
# algorithms# of SoS requirements
# of SoS interface protocols
# of constituent systems
# of constituent system organizations
# operational scenarios“Product” characteristicsSize/complexity

Requirements understanding
Architecture understanding
Level of service requirements
# of recursive levels in design
Migration complexity
Technology risk
#/ diversity of platforms/installations
Level of documentationSize/complexity
Requirements understanding
Architecture understanding
Level of service requirements
Component system maturity and stability
Component system readiness
Process characteristicsProcess capability
Multi-site coordination
Tool supportMaturity of processes
Tool support
Cost/schedule compatibility
SoS risk resolutionPeople characteristicsStakeholder team
cohesion
Personnel/team capability
Personnel experience/continuityStakeholder team cohesion
SoS team capability

*
Always-on, never-fail systems
Consider using “weighted SLOC” as a productivity metricSome
SLOC are “heavier to move into place” than othersAnd largely
management uncontrollablesExamples: high values of
COCOMO II cost driversRELY: Required Software Reliability
DATA: Database SizeCPLX: Software ComplexityDOCU:
Required DocumentationRUSE: Required Development for
Future ReuseTIME: Execution Time ConstraintSTOR: Main
Storage ConstraintSCED: Required Schedule
CompressionProvides way to compare productivities across
projectsAnd to develop profiles of project classes
15 July 2008
©USC-CSSE

*
*
ConclusionsFuture trends imply need to concurrently address
new DoD estimation and management metrics
challengesEmergent requirements, rapid change, net-centric
systems of systems, ultrahigh assuranceNeed to work out cost
drivers, estimating relationships for new phenomenaIncremental
Development Productivity Decline (IDPD)ESLOC and milestone
definitionsCompositional approach for systems of systemsNDI,
model, and service composabilityRe-engineering, migration of
legacy systemsUltra-reliable systems developmentCost/schedule
tradeoffsNeed data for calibrating models
15 July 2008
©USC-CSSE
*
*
15 July 2008
©USC-CSSE
*
References

Boehm, B., “Some Future Trends and Implications for Systems
and Software Engineering Processes”, Systems Engineering
9(1), pp. 1-19, 2006.
Boehm, B. and Lane J., "21st Century Processes for Acquiring
21st Century Software-Intensive Systems of Systems."
CrossTalk: Vol. 19, No. 5, pp.4-9, 2006.
Boehm, B., and Lane, J., “Using the ICM to Integrate System
Acquisition, Systems Engineering, and Software Engineering,”
CrossTalk, October 2007, pp. 4-9.
Boehm, B., Brown, A.W.. Clark, B., Madachy, R., Reifer, D., et
al., Software Cost Estimation with COCOMO II, Prentice Hall,
2000.
Dahmann, J. (2007); “Systems of Systems Challenges for
Systems Engineering”, Systems and Software Technology
Conference, June 2007.
Department of Defense (DoD), Defense Acquisition Guidebook,
version 1.6, http://akss.dau.mil/dag/, 2006.
Department of Defense (DoD), Instruction 5000.2, Operation of
the Defense Acquisition System, May 2003.
Department of Defense (DoD), Systems Engineering Plan
Preparation Guide, USD(AT&L), 2004.
Galorath, D., and Evans, M., Software Sizing, Estimation, and
Risk Management, Auerbach, 2006.
Lane, J. and Boehm, B., “Modern Tools to Support DoD
Software-Intensive System of Systems Cost Estimation, DACS
State of the Art Report, also Tech Report USC-CSSE-2007-716
Lane, J., Valerdi, R., “Synthesizing System-of-Systems
Concepts for Use in Cost Modeling,” Systems Engineering, Vol.
10, No. 4, December 2007.
Madachy, R., “Cost Model Comparison,” Proceedings 21st,
COCOMO/SCM Forum, November, 2006,
http://csse.usc.edu/events/2006/CIIForum/pages/program.html
Maier, M., “Architecting Principles for Systems-of-Systems”;
Systems Engineering, Vol. 1, No. 4 (pp 267-284).
Northrop, L., et al., Ultra-Large-Scale Systems: The Software
Challenge of the Future, Software Engineering Institute, 2006.

Reifer, D., “Let the Numbers Do the Talking,” CrossTalk,
March 2002, pp. 4-8.
Valerdi, R, Systems Engineering Cost Estimation with
COSYSMO, Wiley, 2009 (to appear)
*
15 July 2008
©USC-CSSE
*
List of Acronyms
AA Assessment and Assimilation
AAF Adaptation Adjustment Factor
AAM Adaptation Adjustment Modifier
COCOMO Constructive Cost Model
COSOSIMO Constructive System of Systems Integration Cost
Model
COSYSMO Constructive Systems Engineering Cost Model
COTS Commercial Off-The-Shelf
CU Cone of Uncertainty
DCR Development Commitment Review
DoD Department of Defense
ECR Exploration Commitment Review
ESLOC Equivalent Source Lines of Code
EVMS Earned Value Management System
FCR Foundations Commitment Review
FDN Foundations, as in FDN Package
FED Feasibility Evidence Description
GD General Dynamics
GOTS Government Off-The-Shelf

*
15 July 2008
©USC-CSSE
*
List of Acronyms (continued)
ICM Incremental Commitment Model
IDPD Incremental Development Productivity Decline
IOC Initial Operational Capability
LCA Life Cycle Architecture
LCO Life Cycle Objectives
LMCO Lockheed Martin Corporation
LSI Lead System Integrator
MDA Model-Driven Architecture
NDANon-Disclosure Agreement
NDI Non-Developmental Item
NGC Northrop Grumman Corporation
OC Operational Capability
OCR Operations Commitment Review
OO Object-Oriented
OODA Observe, Orient, Decide, Act
O&M Operations and Maintenance
PDR Preliminary Design Review
PM Program Manager
*

15 July 2008
©USC-CSSE
*
List of Acronyms (continued)
RFP Request for Proposal
SAIC Science Applications international Corporation
SLOC Source Lines of Code
SoS System of Systems
SoSE System of Systems Engineering
SRDR Software Resources Data Report
SSCM Systems and Software Cost Modeling
SU Software Understanding
SW Software
SwE Software Engineering
SysE Systems Engineering
Sys Engr Systems Engineer
S&SE Systems and Software Engineering
ToC Table of Contents
USD (AT&L) Under Secretary of Defense for Acquisition,
Technology, and Logistics
VCR Validation Commitment Review
V&V Verification and Validation
WBSWork Breakdown Structure
*
Technical
Management
Business
Political
People

People
People
People
Performance
Focus Is On:
Schedule
Cost
Politics
Technical
Political
Awareness
Awareness
Level of
Level of
HIGH
HIGH
low
low
Operating domain of the
System Architect
SMARTER BUYER REFERE
NCE SHEET
Industry Assessment
: Necessary to understand changing industry environment
·
Competitive landscape
·
Wall Street’s view of viability
–
the space industry and individual contractor returns

·
Contractor
·
Recent won/lost record
·
Margi
ns for particular division/group
–
Return
·
Backlog: What is the Contractor doing today
–
resources available
·
What else are they bidding on/timing overlap
·
Skills and competencies
–
Past performance, subcontractors
·
Strategic plan: to where or into what bus
iness do they want to move, i.e. from sub

to prime?
Risk/Return
: understand the factors and relationships to keep this in balance
·
Risk and success factors defined and understood
–
Technical, Schedule, Cost
·
Program return is commensurate with risk for Cont
ractor
·
Consistency between contract T’s and C’s
–
and what is to be incentivized
Cost
: be aware of the motivations behind the cost figures
·
Realistic independent cost estimate
·
Is the proposal a bid
-
to

-
win or price
-
to
-
cost (Incumbent loses 75% of the time
)
·
Focus on value proposition of Contractor/proposal and not
overly emphasized on cost
Cash Flow
: help consistent Contractor earnings
·
Make regular payments: both for schedule and actual receipts
·
Timed between front
-
end and back
-
end: between progress paym
ents and in
-
orbit
success
·
Structure savings so that Contractor is able to keep some

Process
: Integrate the Gov’t and Contractor business processes and
communication
·
Insure optimal requirements understanding and evaluation
-
adequate time between draft
a
nd final RFP and also between the RFP and Proposal Submittal
·
Optimal timing between Source Selection and Program stand
-
up to minimize resources
under/non
-
employed
·
Communication often along entire process
Metrics
: Understand metrics used by Contractor lev
els of management
·
Internal metrics Contractor used to measure progress of program

·
Access to data; how often and by what vehicle info shared
·
Realize that internal metrics change may also change contractor
performance
Fee
: Design and maintain a fee structur
e that incentives the right success goals
·
Spread among base, award and incentive
·
Split among tech, schedule, cost and management that is aligned
with goals
·
Adequate pool as a motivation incentive for contractor to
respond to Government
concerns
·
Unearned portion with possibility of rollover
ConOpsSpecs/PlansIOC
Feasibility
Concept of

Operation
Rqts.
Spec.
Plans
and
Rqts.
Product
Design
Product
Design
Spec.
Detail
Design
Spec.
Detail
Design
Devel. and
Test
Accepted
Software
Phases and Milestones
Relative
Cost Range
x
4x
2x
1.25x
1.5x
0.25x
0.5x
0.67x
0.8x
0
2000
4000
6000

8000
10000
12000
14000
16000
18000
20000
1
2
3
4
5
6
7
8
Build
Cumulative
KSLOC
0% productivity decline

MEMOindicate, First Submission, Second Submission, or Final Sub.docx

Recommended

Recommended

More Related Content

Similar to MEMOindicate, First Submission, Second Submission, or Final Sub.docx

Similar to MEMOindicate, First Submission, Second Submission, or Final Sub.docx (14)

More from andreecapon

More from andreecapon (20)

Recently uploaded

Recently uploaded (20)

MEMOindicate, First Submission, Second Submission, or Final Sub.docx