sowarecostesmaon with(cocomo(ii( day(2((cost(factors)(bls.buu.ac.th/~se888321/2556/06nov22/software...

So#ware Cost Es-ma-on with COCOMO II

Day 2 (Cost Factors)

M&P Consul+ng

4/11/13 1 M&P Consul+ng

Agenda

•  So#ware Es-ma-on Methods •  Cost Factors •  So#ware Sizing •  COCOMOII Factors


Agenda

•  So#ware Es-ma-on Methods – Sizing and es+ma+on – Project tracking

•  Cost Factors •  So#ware Sizing •  COCOMOII Factors


So#ware Sizing and Es-ma-on

•  Agile techniques – Story points and velocity [Cohn, 2006] – Planning Poker [Grenning, 2002]

•  Treatments for uncertainty – PERT Sizing [Putnam, 1979]

– Wideband Delphi Technique [Boehm, 1981]

– COCOMO-‐U [Yang, 2006]

4/11/13 4

Require high level of exper-se, experience and historical data.

M&P Consul+ng

Project Tracking and Assessment

4/11/13 5

PERT Network Chart [Wiest, 1977]

•  Iden+fy cri+cal paths •  Nodes updated to show progress •  Grows quickly •  Becomes unusable when large, especially in smaller agile environments

GQM [Basili, 1995]

Goal

Ques-on

Metric

Objec-ve

Answer

Measurement

•  Captures progress from conceptual, opera+onal, and qualita+ve levels •  Align with organiza+on/team •  Only useful when used correctly

Burn Charts [Cockburn, 2004]

•  Effec+ve in tracking progress •  Not good at responding to major changes

Architecture Review Board [Maranzano, 2005]

•  Reviews to validate feasibility of architecture and design •  Increases the likelihood of project success •  Adopted by so^ware engineering course •  Stabilize team, reduce knowledge gaps, evaluate risks

M&P Consul+ng

Agenda

•  So#ware Es-ma-on Methods •  Cost Factors

– Significant factors •  So#ware Sizing •  COCOMOII Factors


Cost Factors

•  3 main factors in COCOMOII 1.  Size 2.  Scale factors 3.  Effort mul+plier

•  Defined to be as objec-ve as possible

4/11/13 M&P Consul+ng 7

Cost Factors

•  Significant factors of development cost –  Size of the software to be developed –  scale drivers are sources of exponential effort variation –  cost drivers are sources of linear effort variation

•  product, platform, personnel and project attributes •  effort multipliers associated with cost driver ratings

–  Defined to be as objective as possible •  Each factor is rated between very low and very

high per rating guidelines –  relevant effort multipliers adjust the cost up or down


Agenda

•  So#ware Es-ma-on Methods •  Cost Factors •  So#ware Sizing

– SLOC – Func+on Point

•  COCOMOII Factors


So#ware Sizing Methods

•  Size in SLOC •  Func-on Point •  Applica-on Point •  Story Point •  Use-‐Case Point


COCOMO

Sizing Process

•  Gather and study system requirements •  Break down into subsystems/modules

– High level design – Group func+ons into modules

•  Es-mate so#ware size – Historical data – Expert judgment – Object point


High-‐Level Design

•  Group func-ons into modules •  Es-mate and predict the modules that will be designed and implemented


# Func-on

1 User Login

2 User Logout

3 User Authoriza+on

4 User Registra+on

5 Add User

6 Remove User

7 Content search

8 Content display

9 Content management

User Authen-ca-on

User Management

Search Module

Content Management

Sizing with SLOC

•  ใช้ข้อมูลประวัติ software ที่เคยพัฒนามาก่อน

–  เปรียบเทียบความซับซ้อนที่ใกล้เคียงกัน –  ใช้ค่าเฉลี่ย

•  ปรึกษาผู้เชี่ยวชาญ – แต่ต้องมีรายละเอียดพร้อม

•  เร็วและง่าย – แต่ไม่แม่นยำ – ขึ้นอยู่กับข้อมูลและความเชี่ยวชาญ


Sizing with Func-on Point

•  หาจำนวนฟังก์ชั่นใน 5 ประเภท –  External Input (EI) นับจำนวนข้อมูลนำเข้า หรือการควบคุมข้อมูลนำเข้าโดย ผ่านจากระบบภายนอก

–  External Output (EO) นับจำนวนข้อมูลที่ถูกส่งออกจากระบบ หรือการควบคุมข้อมูลที่ต้องส่งออกจากระบบไปยังระบบภายนอก

–  Internal Logical File (ILF) นับจำนวนแฟ้มข้อมูลเชิงตรรกะ (logical group of user data) หรือการควบคุมข้อมูลที่ใช้กับแฟ้มข้อมูลภายในเชิงตรรกะ (Logical internal file) ซึ่งเป็นแฟ้มข้อมูลที่ใช้ในระบบ

–  External Interface Files (EIF) นับจำนวนแฟ้มข้อมูลที่ส่งผ่าน หรือแลกเปลี่ยนระหว่างระบบ

–  External Inquiry (EQ) นับจำนวนรวมของข้อมูลนำเข้า และส่งออกที่ข้อมูลนำเข้า ทำให้เกิดข้อมูลส่งออกโดยอัตโนมัติ

14 4/11/13 M&P Consul+ng

Transac-on Func-ons


การพิจารณาระดับความซับซ้อนของฟังชั่น

•  จำนวน Data Element Types (DET) –  ข้อมูลที่ผู้ใช้รู้จักและไม่มีความซ้ำซ้อน สามารถใช้กับฟังชั่นข้อมูล และฟังชั่นธุรกรรมได ้ –  ข้อมูลที่ต้องใช้ในแบบฟอร์ม หรือหน้าจอต่าง ๆ

•  จำนวน Record Element Types (RET) –  กลุ่มย่อยของข้อมูลประเภท DETs ที่ใช้ใน ILF และ EIF –  ข้อมูลประเภทนี้มันเป็นข้อมูลที่มีความสำพันธ์แบบแม่ – ลูกในตารางข้อมูล หรือเป็นข้อมูลที่เป็นลำดับชั้น

•  จำนวน Func-on Type Referenced (FTR) –  ฟังชั่นที่ข้อมูล DET อ้างอิงถึงทั้งในส่วนที่เป็น ILF และ EIF –  ตัวอย่างเช่นการรับข้อมูลเพื่อระบุตัวตนผ่านคอมพิวเตอร์ประกอบด้วยการระบุข้อมูลชื่อผู้ใช้


ขั้นตอนในการประมาณการขนาดโดยใช ้Function Point

•  คำนวณจำนวนฟังก์ชั่นในแต่ละประเภทฟังก์ชั่น – ควรทำโดยบุคคลที่มีความเข้าใจในความต้องการของระบบและสถาปัตยกรรม – อาจเป็นผู้นำทางด้านเทคนิค (Technical Leader)

– ประมาณการจำนวนฟังก์ชั่นจากข้อมูลความต้องการของระบบ •  พิจารณาระดับความซับซ้อนของฟังก์ชั่น

– ซับซ้อนน้อย กลาง และมาก –  ใช้ตารางคำนวณค่าความซับซ้อนของ ILF, EIF, EO, EQ และ EI



•  คำนวณค่าน้ำหนักของปัจจัยความซับซ้อนสำหรับจำนวนฟังก์ชั่นในแต่ละประเภท

– Raw Function Point

ประเภทของฟังชั่น ค่าน้ำหนักของความซับซ้อน ต่ำ กลาง สูง

Internal Logical Files (ILF) 7 10 15 External Interfaces Files (EIF) 5 7 10 External Inputs (EI) 3 4 6 External Outputs (EO) 4 5 7 External Inquiries (EQ) 3 4 6



•  รวมค่าน้ำหนักของปัจจัยความซับซ้อนของฟังก์ชั่นทั้ง 5 ประเภท

•  นำค่าที่ได้มาคำนวณหาจำนวนบรรทัดของซอสโค๊ด (Source Line of Code)

19

ภาษา SLOC / FP ภาษา SLOC / FP C 128 Visual C++ 34 C++ 55 Report generator 80 Database – Default 40 Java 53 Fifth Generation Language 4 HTML 15 Fourth Generation Language

20 Third Generation Language 80

High Level Language 64 Unix Shell Scripts 107

4/11/13 M&P Consul+ng

FUNCTION POINT EXERCISE


Agenda

•  So#ware Es-ma-on Methods •  Cost Factors •  So#ware Sizing •  COCOMOII Factors

– Scale factors – Cost Drivers


COCOMO II Model

4/11/13 22

Scale Factors •  Precedentedness PREC •  Development Flexibility FLEX •  Architecture / Risk Resolu+on RESL •  Team Cohesion TEAM •  Process Maturity PMAT

Product •  Reliability RELY •  Database Size DATA •  Product Complexity CPLX •  Developed for Reusability RUSE •  Documenta+on Match to

Life-‐Cycle Needs DOCU

Pla\orm •  Execu+on Time Constraint TIME •  Main Storage Constraint STOR •  Plagorm Vola+lity PVOL

Personnel •  Analyst Capability ACAP •  Programmer Capability PCAP •  Personnel Con+nuity PCON •  Applica+ons Experience APEX •  Plagorm Experience PLEX •  Language and Tool Experience LTEX

Project •  Use of So^ware Tools TOOL •  Mul+site Development SITE •  Required Development

Schedule SCED

Cost Drivers

•  Post-‐architecture es-ma-on model •  Takes

•  Size •  Ra+ngs for each parameter

•  Es-mates effort/resources required to complete project

Very Low

Low Nominal High Very High

Extra High

M&P Consul+ng

COCOMO II Output Ranges

•  COCOMO II provides one standard devia-on op-mis-c and pessimis-c es-mates.

•  Reflect sources of input uncertain-es •  Apply to effort or schedule for all of the stage models.

•  Represent 80% confidence limits: below op-mis-c or pessimis-c es-mates 10% of the -me.


Stage OptimisticEstimate

PessimisticEstimate

1 0.50 E 2.0 E

2 0.67 E 1.5 E

3 0.80 E 1.25 E

Scale Factors

•  Impacts at project level •  Exponen-al effort varia-on


Scale Factors

•  Precedentedness (PREC) –  Degree to which system is new and past experience applies

•  Development Flexibility (FLEX) –  Need to conform with specified requirements

•  Architecture/Risk Resolution (RESL) –  Degree of design thoroughness and risk elimination

•  Team Cohesion (TEAM) –  Need to synchronize stakeholders and minimize conflict

•  Process Maturity (PMAT) –  SEI CMM process maturity rating


Precedentedness (PREC)

•  Similarity to previously developed projects •  Knowledge on the project •  Familiarity


Very Low Low Nominal High Very High Extra High

Thoroughly unprecedented

Largely unprecedented

Somewhat unprecedented

Generally familiar

Largely familiar Thoroughly familiar

Development Flexibility (FLEX)

•  The flexibility in development allowed in the project

•  Levels of conformity required in developing the so#ware product

•  Dependent on external interface and specifica-ons



Rigorous Occasional relaxa+on

Some relaxa+on

General conformity

Some conformity

General goals

Architecture/Risk Resolu-on (RESL)

•  How much effort is spent in reviewing design and mi-ga-ng risks



20% 40% 60% 75% 90% 100%

Team Cohesion (TEAM)

•  How well the team works together •  Based on levels of interac-ons and ability to cooperate



Very difficult interac+ons

Some difficult interac+ons

Basically coopera+ve interac+ons

Largely coopera+ve

Highly coopera+ve

Seamless interac+ons

Process Maturity (PMAT)

•  Based on the SEI’s Capability Maturity Model (CMM)

•  Values correspond to CMMI levels



CMMI 1 CMMI 2 CMMI 3 CMMI 4 CMMI 5 CMMI 5

SCALE FACTOR EXERCISE


M&P Consulting" 32"

Scale Factor Rating

Scale Factors (Wi) Very Low Low Nominal High Very High Extra High

Precedentedness(PREC)

thoroughlyunprecedented

largelyunprecedented

somewhatunprecedented

generallyfamiliar

largelyfamiliar

throughlyfamiliar

DevelopmentFlexibility (FLEX)

rigorous occasionalrelaxation

somerelaxation

generalconformity

someconformity

generalgoals

Architecture/RiskResolution (RESL)*

little (20%) some (40%) often (60%) generally(75%)

mostly(90%)

full (100%)

Team Cohesion(TEAM)

very difficultinteractions

some difficultinteractions

basicallycooperativeinteractions

largelycooperative

highlycooperative

seamlessinteractions

Process Maturity(PMAT)

Weighted average of “Yes” answers to CMM Maturity Questionnaire

* % significant module interfaces specified, % significant risks eliminated

4/11/13

Cost Drivers (Effort Mul-plier)

•  Module specific factors •  Linear effort varia-on •  Focus on the post-‐architecture

– Overall design of the project is already known –  For use in development and maintenance of so^ware products

•  Cost drivers usually tend to be different for each module –  E.g. UI modules are usually less complex than server modules

– Achieve more accurate es+ma+on when done by module


Cost Drivers (Product)

•  Required So#ware Reliability (RELY) •  Database Size (DATA) •  Product Complexity (CPLX) •  Developed for Reusability (RUSE) •  Documenta-on Match to Life-‐Cycle Needs (DOCU)


Required So#ware Reliability (RELY)

•  The required reliability of the so#ware product

•  What is the impact of the so#ware failure?



Slight inconvenience

Low, easily recoverable losses

Moderate, easily recoverable losses

High financial loss

Risk to human life

N/A

Required Database Size (DATA)

•  Based on the ra-o of database size and program size – Not simply how much you need to store

•  The data required to complete test of the program •  Calcula-on formula provided in the COCOMO book



N/A DATA < 10 10 < DATA < 100 100 < DATA < 1000 DATA > 1000 N/A

DATA = DB Bytes / Program SLOC

So#ware Development Complexity (CPLX)

•  5 areas –  Control opera+ons –  Computa+onal opera+ons – Device-‐dependent opera+ons – Data management opera+ons – User interface management opera+ons

•  Find the average between the areas



Developed for Reuse (RUSE)

•  How much of the components will need to be reused in other applica-ons –  Effort needed to achieve generic design –  Effort for tes+ng to ensure wide range of compa+bility

•  Across project •  Across product line •  Across mul-ple product lines



N/A None Across project Across program Across product line

Across mul+ple product line

Level of Documenta-on (DOCU)

•  Based on the life-‐cycle needs – How much of the life-‐cycle is captured in documenta+on

•  How much is suitable •  Affects maintenance por-on of life-‐cycle

– So^ware understanding (SU)



Many needs uncovered

Some needs uncovered

Right-‐sized to life-‐cycle needs

Excessive for life-‐cycle needs

Very excessing for life-‐cycle needs

N/A

PRODUCT FACTOR EXERCISE


Cost Drivers (Pla\orm)

•  Execu-on Time Constraint (TIME) •  Main Storage Constraint (STOR) •  Pla\orm Vola-lity (PVOL)


Pla\orm

•  Given the modern day technologies, these drivers are nearly irrelevant.

•  Most likely NOMINAL for government domain projects – Liple computa+on resource required for web applica+ons

– Storage is cheap – Size of data store tends to be insignificant compared to available storage

– Plagorms are stable (i.e. OS, DBMS). Major changes are not needed.


Execu-on Time Constraint (TIME)

•  Measure the execu-on -me constraint •  Percentage of available execu-on -me expected to be used



N/A N/A 50% usage 70% usage 85% usage 95% usage

Main Storage Constraint (STOR)

•  Degree of main storage constraint •  Percentage of expected storage use



N/A N/A 50% usage 70% usage 85% usage 95% usage

Pla\orm Vola-lity (PVOL)

•  Includes hardware and so#ware – OS, DBMS, etc.

•  Based on the frequency of changes on the pla\orm



N/A Major: 12 mo. Minor: 1 mo.

Major: 6 mo. Minor: 2 wk.

Major: 2 mo. Minor: 1 wk.

Major: 2 wk. Minor: 2 days

N/A

Cost Drivers (Personnel)

•  Analyst Capability (ACAP) •  Programmer Capability (PCAP) •  Personnel Con-nuity (PCON) •  Applica-ons Experience (APEX) •  Pla\orm Experience (PLEX) •  Language and Tool Experience (LTEX)


Analyst Capability (ACAP)

•  Capability of requirements gatherer, high-‐level and detailed designers.

•  Not based on the experience of analyst •  Abili-es in

– Analysis and design –  Efficiency and thoroughness –  Communica+on and coopera+on



15th percen+le 35th percen+le 55th percen+le 75th percen+le 90th percen+le N/A

Programmer Capability (PCAP)

•  Ability of programmers to deal with – COTS packages – SDKs, frameworks, etc.

•  Based on the capability of the team, not the individuals

•  Not experience



15th percen+le 35th percen+le 55th percen+le 75th percen+le 90th percen+le N/A

Applica-on Experience (APEX)

•  Team’s experience with specific type of applica-on



2 months 6 months 1 year 3 years 6 years N/A

Pla\orm Experience (PLEX)

•  Experience with the pla\orms used – Database – Graphical user interface –  Frameworks – Middlewares




Language and Tool Experience (LTEX)

•  Experience on the programming language used

•  Experience with the tool support used for development –  IDE, DBMS




Personnel Con-nuity (PCON)

•  Project’s annual personnel turnover



48%/year 24%/year 12%/year 6%/year 3%/year N/A

PERSONNEL FACTOR EXERCISE


Cost Drivers (Project)

•  Use of So#ware Tools (TOOL) •  Mul-site Development (SITE) •  Required Development Schedule (SCED)


Use of So#ware Tools (TOOL)

•  Extensiveness on the use of tools in the development process –  Code edi+ng –  Life-‐cycle management



Edit, code, debug

Simple, frontend, backend CASE, liple integra+on

Basic lifecycle tools, moderately integrated

Strong, mature lifecycle tools, moderately integrated

Strong, mature, proac+ve lifecycle tools, well integrated to processes

N/A

Mul-site Development (SITE)

•  Based on the loca-ons of the developers – Site colloca+on – Communica+on support

•  Distributed teams require higher level of effort for communica-ons



Some phone, mail

Individual phone, fax

Narrowband mail

Wideband electronic communica+on

Occasional video conference

Interac+ve media

Required Development Schedule (SCED)

•  Based on percentage of schedule compression –  Stretch-‐out or accelera+on – Accelerated schedules tend to produce more effort at early and later phases

–  Balanced out by middle phases

•  Higher ra-ngs do not add or decrease effort



75% of nominal 85% of nominal 100% 130% 160% N/A

PROJECT FACTOR EXERCISE


ขอบคุณคะ / ครับ


[email protected] [email protected]


sowarecostesmaon with(cocomo(ii( day(2((cost(factors)(bls.buu.ac.th/~se888321/2556/06nov22/software...

Documents