October 29, 2008
COSYSMO Workshop
Harmonization – Roedler
Need to understand structural and operational differences of COCOMO/COSYSMO
Where are the overlaps and gaps between the models
Desire to integrate systems and software estimation
Obtain consensus on changes to cost drivers, life cycle phases, etc.
Sync with Art Pyster and Rich Turner about “touch points”
Most of time examined WBS, work products, and combined activities
Identify ownership of tasks
Determine estimate coverage by current models
Determine more gaps than overlaps
Need to collect the right data at the right level for the right model
Want to agree on how to proceed with the gaps
Issues revealed need for best practice activities, account for tasks of systems engineering
activities which is not necessarily the same as tasks of systems engineering organization
Need to de-conflict Software Requirements Specification (SRS) development (Stacey
Gore from Raytheon)
Noted to address duration or schedule
Overlap areas include PMP system design and development test/evaluation
Both models account for algorithm development, same models?
Areas of uncertainty include DRs, simulation/modeling
Need to detail mapping between to the two models in order to check for consistency
Need to check with John Gaffney and Elliot about results of mapping
Identified need to add documented list of assumptions to COSYSMO, provide guidance
Talk to people from PRICE and Galorath about how they handle overlap between the
models
COSYSMO Application at BAE Systems – Wang
Explanation of SEEMap
Applied to multiple product lines at BAE, product line specific calibrations
Help with engineering bids, make/buy decisions
Good correlation between estimate and actual in calibrations
Incorporated Crystal Ball with COSYSMO to quantify uncertainty and provides risk analysis
Define min, max, and likely values for each value of the model
Explanation of TEEMaP
COSYSMO-R – Gaffney
Capture risk and reuse in COSYSMO
Move away from single point estimates
Been calibrating the model in various organizations and applying to projects
Developed version of COSYSMO-R for avionics
Lockheed experience is that unless you know otherwise, keep the cost drivers nominal
Incorporate into best practice guidance
Estimation of risk enables better management of uncertainty
Expert COSYSMO – Madachy
Utilize COSYSMO drivers to identify risks
Systems Engineering – Reifer
Most industries outside of aerospace don’t know about INCOSE
Systems engineering viewed as engineering assurance group
Systems engineering often provides technical leadership and maintaining customer interfaces
Organizations have three roles: architecture, operations/concept development, management of
the ilities
Systems engineers have specialized tracks but still systems engineers
Most organizations have a chief engineer, but chief engineers are usually not chief architect
Most chief engineers performed management tasks
Very few organizations justify effort with cost models, most use past performance or level of
effort
Most commercial firms only tracked financial, aerospace typically tracked financial and budget
Commercial tracked product quality, aerospace tracked process and product quality
Everyone wanted a SE productivity measure, but there isn’t a single measure
Reuse – Fortune
Mismatch of definitions of “conceptualization” and “develop”. Garry Roedler says that the
LMCO definition of conceptualization is very front end stuff and develop is equivalent to
implementation.
There was a software reuse initiative at Software Productivity Consortium and the DoD.
STARS project out of Darpa, CARDS Air Force and Reuse initiative from DISA.
Spent $600M over a 5 year period. Don Reifer led this effort and has many materials.
Reuse is bad, it’s better to say “multiuse”.
Instead of reusing requirements, it’s better to encapsulate a domain and each system is an
extantiation of those requirements “domain analysis” or “domain engineering”.
John Gaffney has hard copies of everything.
A major factor is design for reuse.
Grady Booch from IBM has developed the concept of “reusable parts”.
Gan Wang thinks it’s difficult to visualize requirements reuse. Don Reifer gave a reference
architecture example for a satellite system where a default architecture is defined and built upon
(i.e., reuse). Compliance to “Link 16” was cited as an example.
Don Reifer said the COCOMO II has two reuse parameters: design for reuse and design with
reuse. How is COSYSMO incorporating these ideas?
Dan Ligett said that COCOMO II accounts for reuse in size drivers, he’s assuming you
considered this as well but decided to stay with cost drivers for some reason.
We should keep four major categories of reuse: new, modified, adopted and deleted. Managed is
a sub-category of adopted.
During outbrief, Joann made the comment that "managed" fits with SoS because SoS teams
frequently just oversee what's going on.
Harmonizing Systems and Software Estimation – Wang
WBS vs. OBS cross-reference matrix identifies gaps and overlaps between models
Recommendations and conclusions
Cover all of 1.1 in COSYSMO
When COSYSMO and COCOMO are run at the same time, COSYSMO should cover all
of 1.2 and COCOMO should leave it alone
1.3.1 is an under-lap
1.5 is a huge area of over-lap; need to use in COSYSMO if using both models, otherwise
use software or hardware model