COCOMO Farah-Stapleton November-2015-DRAFT9 MFS

8/18/2019 COCOMO Farah-Stapleton November-2015-DRAFT9 MFS

http://slidepdf.com/reader/full/cocomo-farah-stapleton-november-2015-draft9-mfs 1/26

Resource Analysis Based On

System Architecture Behavior

Monica Farah-Stapleton

Professor Ray Madachy

Professor Mikhail Auguston

Professor Kristin Giammarco

November 2015



Overview of Today’s Presentation

• Pervasive Challenge and Response• Research Alignments

• Applying FP Methodology To MP Model

• Relating Activities

• Closing Thoughts

2

We would like to acknowledge Lori Holmes-Limbacher for her

contributions as a FPA subject matter expert and the Q/P Management

Group, Inc. for the Tee Time System example.



Pervasive Challenge and Response

Challenge

•

Information Technology (IT) systems are large, challenged by the rate of change ofcommercial IT, and represent a significant investment in time and resources – Introduction of new system/capability results in unintended or unexpected

system/environment behaviors

– Operational and financial impacts often assessed after the fact

– Resourcing decisions and precise architectural descriptions of system/environment often

minimally related

Approach

• Leverage precise behavioral modeling using Monterey Phoenix (MP) to assess

architectural design decisions and their impacts prior to, during, and after deployment

•Relate architectural modeling to resourcing through analysis of behaviors andUnadjusted Function Point Analysis (FPA) counts, leveraging complexity and size

metrics, e.g. Data Element Type (DET) and File Type Referenced (FTR)

• Align activities with Systems Engineering Research Center (SERC) Ilities Tradespace

and Affordability Program (iTAP)

3



4

iTAP Research Objectives

• Total Ownership Cost (TOC) modeling to enable affordability tradeoffs with

integrated software-hardware-human factors• Current shortfalls for ilities tradespace analysis

– Models/tools are incomplete wrt/ TOC phases, activities, disciplines, SoS aspects

– No integration with physical design space analysis tools, system modeling, or each other

• New aspects

– Integrated costing of systems, software, hardware and human factors across full lifecycleoperations

– Extensions and consolidations for DoD application domains

– Tool interoperability and tailorability (service-oriented)

• Can improve affordability-related decisions across all joint services

• Current Phase 4 Plans – Extract: – Assess Monterey Phoenix (MP) for automatically providing cost information from architectural

models

– MP will extract software sizing cost model inputs to compute costs, and we will assess

mapping MP architectural elements into systems engineering cost model inputs

Please See Our Demo At the Tools Fair 5:00-6:30 PM 4



Applying FPA Methodology to MP

Architecture Model

5

Step 1: Identify problem statement, i.e. typical questions to be answered, determine type of count

Step 2: Describe behaviors of system and environment in natural language, identify scope boundary

Step 3: Unambiguously represent behaviors using MP, extract use cases/initial views from MP model

Step 4: Relate MP system/environment behaviors to Function Point behaviors

Step 5: Identify coefficients that inform complexity and scale, identify counting rules

Step 6: Determine Unadjusted Function Point (UFP) count

Step 7: Assess effort using MP-COCOMO II/III tool and extracting coefficientsStep 8: Visualize results in views specific to stakeholders



• Event - any detectable action in

system’s or environment’s behavior

• Event trace - set of events with

two basic partial ordering relations,

precedence (PRECEDES) and

inclusion (IN)

• Event grammar - specifies the

structure of possible event traces

Basic Concepts for Monterey Phoenix (MP)

Behavioral Modeling

6

Innovations:

• Uniform Framework: Describe behaviors and interactions of the system AND environment using the sameframework

• Leverage Small Scope Hypothesis: Exhaustive search through all possible scenarios (up to the scope limit),expecting that most flaws in models can be demonstrated on small counterexamples

• Separation of System Interaction from System Behavior: Specify behavior of each system’s components

separately from interactions between those components



What Does “Separation of System Interaction

from System Behavior” Mean?

7



Function Point AnalysisFunctionality From User’s Perspective

Determine the Type of Count and Boundary :Develome!t Pro"e#t$ %!ha!#eme!t Pro"e#t$ Ali#atio!

Terminology:• %&ter!al '!uts (%'): Data that is e!teri!* a s+stem

• %&ter!al Oututs (%O) a!, %&ter!al '!uires (%.): Data that is

leavi!* the s+stem

• '!ter!al /o*i#al Files ('/F): Data that is ro#esse, a!, store,

ithi! the s+stem

• %&ter!al '!ter1a#e Files (%'F): Data that is mai!tai!e, outsi,e the

s+stem ut is !e#essar+ to satis1+ a arti#ular ro#ess reuireme!t

Function Point Analysis Practice• ou!t Data a!, Tra!sa#tio!al Fu!#tio! T+es

• Determi!e !a,"uste, FP ou!t

• Determi!e the alue A,"ustme!t Fa#tor A

• al#ulate 1i!al A,"uste, FP ou!t A

8

Function Points:• ormali9e, metric use, to

evaluate so1tare ,eliverales• Measure si9e ase, o! ell-

,e1i!e, 1u!#tio!al

#hara#teristi#s o1 the so1tares+stem

• Must e ,e1i!e, arou!,

#omo!e!ts that #a! e

i,e!ti1ie, i! a ell-ritte!

se#i1i#atio!

Sources: IFPUG



Relating FPA and MP

• Unadjusted Function Point is a unit of measurement to express the amount of

functionality in a system, and can be used to estimate system cost. Of specificinterest are the input/output activities of the system.

• MP architecture model is based on behavior modeling, providing a bridge

between the requirements and high level design, and is supportive of cost

estimates early in the design phase.

•The concept of an event in MP is an abstraction for activity within the system.It is rendered as a pseudo-code, appropriate for capturing the functional

aspects of requirements, and supportive of refinement.

• UFP can be identified in the MP architecture model as an interaction

abstraction (i.e. COORDINATE or SHARE ALL constructs).

• The structure and the complexity of interactions in MP provide a source forassigning weights contributing to the UFP.

• Since an MP model is precise and formal, FP metrics can be identified by

automated tools such as http://csse.usc.edu/tools/MP_COCOMO

http://csse.usc.edu/tools/MP_COCOMO





Tee Time Example System ExampleUFP Count Synopsis

;0



Relating Activities:

Tee Time System -- Golf Courses List, EQ : State Drop Down

;;

Transactional Function: EQ (View or Display Retrieval of Data)

• Click Button from Main Screen, navigate to Golf Courses list. No EP.

• Eit !utton: Navigation, no EP.

EQ -- View/Display State Drop Down Clic on state arrow State list !isplay returne! Stop " FTR (#olf Courses $%F)& ' DET (rrow Clic&

State fiel!)

E" # $ie%&'is(la) Cit) 'ro( 'o%n State *ata entere* Click on Cit) arro% Cit) list *is(la) returne* Sto( + F- Golf Courses I/F0, 1 'E State *ata, 2rro%

Click, Cit) fiel*0

E" # $ie%&'is(la) Golf Courses /ist Enter State an* Cit) Click 'is(la) !utton Name *is(la)e* !ack, *on3t count state, cit). Sto( + F- Golf Course I/F0, 4 'EState, Cit), Name,

Click 'is(la)0

EP Description ILF/EIF FTR/DET Complex UFP

EQ State Drop

Down

Golf

Courses

(I)

(1,2) Low 3

© Copyright 2010. Q/P Management Group, Inc. All Right Reer!e".



MP Model for EQ State Drop DownNested COORDINATE

01 SCHEMA EQ_State_Drop_Down

02 ROOT User_GCL: Inquire_on_state_data something_else;

03 Inquire_on_state_data: Click_state_arrow_dropdown Receive_state_list_display;

04 ROOT Golfcourses_ILF: Get_result anything_else;

05 Get_result: Receive_state_arrow_prompt Send_state_list_display;

06 COORDINATE $x: Inquire_on_state_data FROM User_GCL,

07 $y: Get_result FROM Golfcourses_ILF

08 DO

;2

Lines 02-0

represent the

!eha"iors of

#$$Ts %Actors&

Lines 0'-()

represent the

!eha"iors of

*+: ,tate

Drop Don

C$$#D./AT*

P Calculation• ( FT# and ( nested C$$#D./AT* %C$$#D./AT* 1 2 ADDs& correspond to ( FT# and 2 D*Ts and a functional

compleity eighting of 3• *+ ,tate Drop Don 4 %( C$$#D./AT*& 5 3 6FP7C$$#D./AT* 4 3 6FPs

Line 0( ,chema

/ame for *+

C$$#D./AT*

17 OD;

09 COORDINATE $xx: Click_state_arrow_dropdown FROM $x,

10 $yy: Receive_state_arrow_prompt FROM $y,

11 $x11: Receive_state_list_display FROM $x,

12 $y11:

Send_state_list_display FROM $y

13 DO

14 ADD $xx PRECEDES $yy;

15 ADD $y11 PRECEDES $x11;

16 OD;

Lines 08 -('

represent

!eha"iors of

nested

C$$#D./AT*9

D*Ts and FT#s

The nested

interactions%ADD& influence

the eight of

this *+

C$$#D./AT*



EQ State Drop Down Use CaseSequence Diagram Automatically Generated by Firebird, Scope 2

;3

• onterey Phoeni and #elated ;or<: http:77

facultynpsedu7maugusto

• P ;i<i: https:77i<inpsedu7display7P

• Pu!lic P ser"er ith P editor9 trace generator9 and tracegraph "isuali=ation: http:77fire!irdnpsedu7

FPA C l l ti

http://faculty.nps.edu/maugusto


https://wiki.nps.edu/display/MP

http://firebird.nps.edu/










FPA CalculationExternal Inquiry (EQ)

EP Description ILF/EIF FTR/DET Complexity UFP

EQ State Drop Down Golf Courses (I) (1,2) Low 3

EQ City Drop Down Golf Courses (I) (1,3) Low 3

EQ Golf Course List Golf Courses (I) (1,4) Low 3

EQ Golf Course Detail Golf Courses (I) (1,12) Low 3

EQ Scoreboard Display Scoreboard (I) (1,6) Low 3

EQ Maintain Golf Course Display(by ID)

Golf Courses (I) (1,13) Low 3

EQ Tee Times Reservation

Display

Tee Times (I) (1,11) Low 3

EQ Tee Times Shopping Display Merchandise (E) (1,3) Low 3

EQ Product View Picture Merchandise (E) (1,3) Low 3

;4Source IFPUG Counting Manual Part 2,

-



MP and FPA UFP CalculationEQ State Drop Down

UFP Calculation: Extracted From MP

• 1 COORDINATE interaction associated withState Drop Down EQ behaviors

• State Drop down EQ COORDINATE

contains a nested COORDINATE (2 ADDs)

• The 2 ADDs relate to 2 DETs

• ROOT Golfcourses_ILF relates to 1 FTR

• 0 -1 FTRs and 1-5 DETs correspond to aLow functional complexity rating

• A Low functional complexity rating

corresponds to 3 UFP

• EQ State Drop Down is equal to 1

COORDINATE with a weight of 3 or

3 UFPs

;5

UFP Calculation: FPA Manual Count

• 1 FTR and 2 DETs identified from thebehavior of the State Drop Down EQ

• 0-1 FTRs and 1-5 DETs correspond to a Low

functional complexity rating

• A Low functional complexity rating

corresponds to 3 UFPs

EP Description ILF/EIF FTR /

DET

Complex UFP

EQ State Drop

Down

Golf

Courses (I)

(1,2) Low 3





Closing Thoughts

• Resourcing is a socio-technical problem

–

Methodology and MP Framework synchronize concepts, architectures,system/software implementation, business processes, organizational dynamics

– Relevant in the System of Systems problem space

– Make the tools and methods user-friendly, enforce across the enterprise

•Next Steps – Refine weights for each Transactional Function

– Refine relationship between steps of a FPA Elementary Process and MP

descriptions• Nested COORDINATES

• ILF and EIF behavioral representations in MP

– Apply methodology to iTAP UAV case study and IFPUG case study

;7



Back Up

;8

FPA C l l ti



FPA CalculationExternal Input (EI)


EI Scoreboard (ADD) Scoreboard (I) (1,7) Low 3

EI Scoreboard (CHANGE) Scoreboard (I) (1,7) Low 3

EI Scoreboard (DELETE) Scoreboard (I) (1,3) Low 3

EI Maintain Golf Course (ADD) Golf Courses (I) (1,13) Low 3

EI Maintain Golf Course (CHANGE) Golf Courses (I) (1,13) Low 3

EI Maintain Golf Course (DELETE) Golf Courses (I)Tee Times

(2,3) Low 3

EI Tee Times Reservations (ADD) Tee Times (I) (1,12) Low 3

EI Tee Times Reservations (CHANGE) Tee Times (I) (1,12) Low 3

EI Tee Times Reservations (DELETE) Tee Times (I) (1,6) Low 3

;Source IFPUG Counting Manual Part 2,-

FPA C l l ti



FPA CalculationExternal Output (EO)


EO Shopping Display (Calculation) Merchandise (1,7) Low 4

EO Buy – Send to Purchasing

(Calculation)

Merchandise (1,15) Low 4

20Source IFPUG Counting Manual Part 2,

-

FPA C l l ti



FPA CalculationData Functions

Description ILF/EIF RET/DET Complexity UFP

Golf Course ILF (1,11) Low 7

Tee Times ILF (1,10) Low 7

Scoreboard ILF (1,5) Low 7

Merchandise EIF (1,3) Low 5

2;Source IFPUG Counting Manual Part 2,

-





23

iTAP Phase 4 Plans – Task 2

• Collaboration with AFIT for a joint Intelligence, Surveillance and Reconnaissance

(ISR) mission application involving heterogeneous teams of autonomous and

cooperative agents.

• NPS will provide cost modeling expertise, tools and Monterey Phoenix (MP) modeling

support. A focus will be on translations between models/tools in MBSE, specifically

mapping architectural elements into cost model inputs.

• Approach – Develop a baseline operational and system architecture to capture a set of military scenarios.

– Transition the baseline architecture to the MP environment.

– Utilize the executable architecture modeling framework of MP to perform automated assertion

checking and find counterexamples of behavior that violate the expected system's correctness.• Operational scenarios will be cycled through the MP modeling process, whereby alternate events are

captured for each actor in each scenario. This will produce a superset of scenario variants from thebehavior models, suitable for input to tradespace analysis and cost models.

– Design and demonstrate an ISR UAV tradespace.

– Develop cost model interfaces for components of the architecture in order to evaluate cost

effectiveness in an uncertain future environment.



24

iTAP Phase 4 Plans – Task 3

• Continue extending the scope and tradespace interoperability of cost models and tools

from previous phases.

• Cost modeling will engage domain experts for Delphi estimates, evolve baseline

definitions of cost driver parameters and rating scales for use in data collection, gather

empirical data and determine areas needing further research to account for differences

between estimated and actual costs.

– Prototype cost models and tools will be extended accordingly for piloting and refinement.• For tool interoperability we will integrate cost models in different ways with MBSE

architectural modeling approaches and as web services. We will also automate systems

and software risk advisors that operate in conjunction with the cost models.

• NPS will provide domain expertise for SysML cost model integration with Georgia

Tech and USC to add software cost model formulas and the risk assessment

capabilities. – This is also allied with Task 2 where we will assess Monterey Phoenix (MP) for automatically

providing cost information from architectural models. MP will extract software sizing cost

model inputs to compute costs, and we will assess mapping MP architectural elements into

systems engineering cost model inputs.



• A US Department of Defense

University-Affiliated Research

Center (UARC)

• The networked national resource

to further systems research and itsimpact on issues of national and

global significance

Systems Engineering Research Center

The Systems Research and Impact Network

25

SERC: 22 Collaborators Led by Stevens



SERC: 22 Collaborators, Led by Stevens

Institute

26

COCOMO Farah-Stapleton November-2015-DRAFT9 MFS

Documents