Pongtip Aroonvatanaporn CSCI 577b Spring 2011 March 25, 2011

Slides:



Advertisements
Similar presentations
Software Cost Estimation
Advertisements

COST ESTIMATION TECHNIQUES AND COCOMO. Cost Estimation Techniques 1-)Algorithmic cost modelling 2-)Expert judgement 3-)Estimation by analogy 4)-Parkinsons.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
Cocomo II Constructive Cost Model [Boehm] Sybren Deelstra.
CSCI COCOMO Tutorial1 CS “Tutorial” Presentation: Software Cost Estimation Tools – COCOMO II and COCOTS A Winsor Brown and Ye.
Applying COCOMO II Effort Multipliers to Simulation Models 16th International Forum on COCOMO and Software Cost Modeling Jongmoon Baik and Nancy Eickelmann.
Ch8: Management of Software Engineering. 1 Management of software engineering  Traditional engineering practice is to define a project around the product.
COCOMO II 資管研一 張永昌. Agenda Overall Model Definition COCOMO II Models for the Software Marketplace Sectors COCOMO II Model Rationale and Elaboration Development.
SE is not like other projects. l The project is intangible. l There is no standardized solution process. l New projects may have little or no relationship.
University of Southern California Center for Software Engineering CSE USC 9/14/05 1 COCOMO II: Airborne Radar System Example Ray Madachy
April 27, 2004CS WPI1 CS 562 Advanced SW Engineering Lecture #3 Tuesday, April 27, 2004.
University of Southern California Center for Systems and Software Engineering © 2009, USC-CSSE 1 An Analysis of Changes in Productivity and COCOMO Cost.
Chapter 23 – Project planning Part 2. Estimation techniques  Organizations need to make software effort and cost estimates. There are two types of technique.
Information System Economics Software Project Cost Estimation.
COCOMO-SCORM: Cost Estimation for SCORM Course Development
Chapter 6 : Software Metrics
CEN th Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Effort estimation.
University of Southern California Center for Systems and Software Engineering Cost Estimation with COCOMO II Barry Boehm CS 510, Fall 2015 v3: Slide 10.
REAL TIME GPS TRACKING SYSTEM MSE PROJECT PHASE I PRESENTATION Bakor Kamal CIS 895.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 26 Slide 1 Software cost estimation 2.
University of Southern California Center for Systems and Software Engineering © 2010, USC-CSSE 1 Trends in Productivity and COCOMO Cost Drivers over the.
Estimating “Size” of Software There are many ways to estimate the volume or size of software. ( understanding requirements is key to this activity ) –We.
Effort Estimation In WBS,one can estimate effort (micro-level) but needed to know: –Size of the deliverable –Productivity of resource in producing that.
The COCOMO model An empirical model based on project experience. Well-documented, ‘independent’ model which is not tied to a specific software vendor.
1 COCOMO II Estimation Example: Transaction Processing System (TPS) II Based on Chapter 3 of COCOMO II book Used for new microeconomics examples –Replaces.
Rating Very Very Extra Cost Drivers Low Low Nominal High High High Product Attributes Required software reliability Database size.
Project Manager:PATS Project Manager Estimator:Peter Project Manager Start Date:1/1/2010 PATS Software PATS Project Team.
(6) Estimating Computer’s efficiency Software Estimation The objective of Software Estimation is to provide the skills needed to accurately predict the.
بشرا رجائی برآورد هزینه نرم افزار.
1 Agile COCOMO II: A Tool for Software Cost Estimating by Analogy Cyrus Fakharzadeh Barry Boehm Gunjan Sharman SCEA 2002 Presentation University of Southern.
THE FAMU-CIS ALUMNI SYSTEM
Project Cost Management
COCOMO III Brad Clark 31tst International Forum on
SOCCER DATA WEB CRAWLER
COCOMO III Workshop Summary
PROJECT LIFE CYCLE AND EFFORT ESTIMATION
Metrics and Terms SLOC (source lines of code)
Cost Estimation with COCOMO II
Tutorial: Software Cost Estimation Tools – COCOMO II and COCOTS
COCOMO II Overview CSCI 510 Fall 2013 (c) USC CSSE.
COCOMO II Overview Barry Boehm CSCI 510 Fall 2011 (c) USC CSSE
COCOMO II Overview Barry Boehm CSCI (c) USC CSSE 2018/9/19.
COCOMO II Overview A Winsor Brown (especially from page 50 on)
Constructive Cost Model
COCOMO II Overview Ray Madachy CSCI 510
SLOC and Size Reporting
Software Cost estimation
Cost Estimation with COCOMO II
Software Systems Cost Estimation
COCOMO Model Basic.
Software life cycle models
Cost Estimation with COCOMO II
Cost Estimation with COCOMO II
More on Estimation In general, effort estimation is based on several parameters and the model ( E= a + b*S**c ): Personnel Environment Quality Size or.
COCOMO Models.
Cost Estimation with COCOMO II
COCOMO 2 COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch. Since.
COCOMO II Overview LiGuo Huang Computer Science and Engineering
Chapter 23 Software Cost Estimation
Cost Estimation with COCOMO II
Comparison between each special case
Cost Estimation with COCOMO II
COCOMO II: Airborne Radar System Example
COnstructive COst MOdel
COCOMO II Overview Marilee Wheaton CSCI 510.
COCOMO II: Airborne Radar System Example
Chapter 26 Estimation for Software Projects.
Center for Software and Systems Engineering,
COCOMO MODEL.
Presentation transcript:

Pongtip Aroonvatanaporn CSCI 577b Spring 2011 March 25, 2011 COCOMO II Estimation Pongtip Aroonvatanaporn CSCI 577b Spring 2011 March 25, 2011 3/25/11 (C) USC-CSSE

Outline Problems COCOMO II parameters Scale Factors Cost Drivers CSCI577 Scenario COCOMO II estimation uncertainties 3/25/11 (C) USC-CSSE

Problems Many misunderstandings of COCOMO parameters Name sound straightforward But actual meanings are more detailed Inaccurate estimations of effort Incorrect values specified for COCOMO drivers Many done with guesses 3/25/11 (C) USC-CSSE

Outline Problems COCOMO II parameters Scale Factors Cost Drivers CSCI577 Scenario COCOMO II estimation uncertainties 3/25/11 (C) USC-CSSE

Scale Factors Precedentedness (PREC) Development Flexibility (FLEX) Architecture / Risk Resolution (RESL) Team Cohesion (TEAM) Process Maturity (PMAT) 3/25/11 (C) USC-CSSE

PREC Similarity to previously developed projects Knowledge on the project Familiarity Very low Very high Low Nominal High Extra high Most likely for 577 3/25/11 (C) USC-CSSE

PREC for 577 Most students are familiar with web development Web applications have been done for many years 3/25/11 (C) USC-CSSE

FLEX The flexibility in development allowed in the project Levels of conformity required in developing the software product Dependent on external interface and specifications Very low Very high Low Nominal High Extra high Most likely for 577 3/25/11 (C) USC-CSSE

FLEC for 577 Most clients do not have strict requirements on specifications Only on capabilities, but not implementation Developers can often suggest development approaches Developers often know better 3/25/11 (C) USC-CSSE

RESL How much effort is spent in reviewing design and mitigating risks Very low Very high Low Nominal High Extra high Most likely for 577 3/25/11 (C) USC-CSSE

RESL for 577 ICSM is a risk-based process Risk resolution are done extensively throughout the project life-cycle Project designs and architectures are reviewed ARB at every milestones Reviews by IIV&V 3/25/11 (C) USC-CSSE

PMAT Based on the SEI’s Capability Maturity Model (CMM) Values correspond to CMMI levels Very low Very high Low Nominal High Extra high Most likely for 577 3/25/11 (C) USC-CSSE

PMAT for 577 The level of detail done for 577 equates roughly to CMMI level 2 If you perform extra project management or life-cycle management tasks, level can increase 3/25/11 (C) USC-CSSE

Cost Drivers Focus on the post-architecture Overall design of the project is already known For use in development and maintenance of software 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 estimation when done by module 3/25/11 (C) USC-CSSE

Product Required Software Reliability (RELY) Database Size (DATA) Product Complexity (CPLX) Developed for Reusability (RUSE) Documentation Match to Life-Cycle Needs (DOCU) 3/25/11 (C) USC-CSSE

RELY The required reliability of the software product What is the impact of the software failure? Very low Very high Low Nominal High Slight inconvenience Low, easily recoverable losses Moderate, easily recoverable losses High financial losses Risk to human life Most likely for 577 3/25/11 (C) USC-CSSE

RELY for 577 Most are web application projects Content management systems, user management systems, informative web Systems are used mainly for convenience To speed up process To reach wider audience No safety critical systems 3/25/11 (C) USC-CSSE

DATA Calculation formula provided in the COCOMO book Based on the ratio of database size and program size Not simply how much you need to store The data required to complete test of the program 3/25/11 (C) USC-CSSE

CPLX 5 areas Find the average between the areas Control operations Computational operations Device-dependent operations Data management operations User interface management operations Find the average between the areas Very low Very high Low Nominal High Most likely for 577 3/25/11 (C) USC-CSSE

CPLX for 577 Mostly using simple reads and writes between application and database Utilize NDI/NCS components (i.e. MySQL, PHP, Apache, Tomcat) Simple UI designs No widget designs, no framework designs No direct hardware operations No complex data structure designs 3/25/11 (C) USC-CSSE

RUSE How much of the components will need to be reused in other applications Effort needed to achieve generic design Effort for testing to ensure wide range of compatibility Across project Across product line Across multiple product lines Low Extra high Nominal High Very high Across product lines None Across project Across program Across multiple product lines Most likely for 577 3/25/11 (C) USC-CSSE

RUSE for 577 Not developing for a product line Independent / standalone web applications Very little reuse components Unless designing frameworks and widgets for use within project 3/25/11 (C) USC-CSSE

DOCU Based on the life-cycle needs How much is suitable How much of the life-cycle is captured in documentation How much is suitable Affects maintenance portion of life-cycle Software understanding (SU) Very low Very high Low Nominal High Many life-cycle needs uncovered Some life-cycle needs uncovered Right-sized to life-cycle needs Excessive for life-cycle needs Very excessive for life-cycle needs Most likely for 577 3/25/11 (C) USC-CSSE

DOCU for 577 ICSM does require certain amount of documentation May seem excessive due to Learning curve Teaching process Actual documentation may be more than required for project complexity 3/25/11 (C) USC-CSSE

Platform Execution Time Constraint (TIME) Main Storage Constraint (STOR) Platform Volatility (PVOL) 3/25/11 (C) USC-CSSE

Platform Given the modern day technologies, these drivers are nearly irrelevant. Most likely NOMINAL for 577 projects Little computation resource required for web applications Storage is cheap Size of data store tends to be insignificant compared to available storage Platforms are stable (i.e. OS, DBMS). Major changes are not needed. 3/25/11 (C) USC-CSSE

Personnel Analyst Capability (ACAP) Programmer Capability (PCAP) Personnel Continuity (PCON) Applications Experience (APEX) Platform Experience (PLEX) Language and Tool Experience (LTEX) 3/25/11 (C) USC-CSSE

ACAP Capability of requirements gatherer, high-level and detailed designers. Not based on the experience of analyst Abilities in Analysis and design Efficiency and thoroughness Communication and cooperation Very low Very high Low Nominal High 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile Most likely for 577 3/25/11 (C) USC-CSSE

PCAP Ability of programmers to deal with COTS packages SDKs, frameworks, etc. Based on the capability of the team, not the individuals Not experience Very low Very high Low Nominal High 15th percentile 35th percentile 55th percentile 75th percentile Most likely for 577 3/25/11 (C) USC-CSSE

APEX Team’s experience with specific type of application Very low Very high Low Nominal High < 2 months 6 months 1 year 3 years 6 years Most likely for 577 3/25/11 (C) USC-CSSE

APEX for 577 Most are computer science students Familiar with web development 3/25/11 (C) USC-CSSE

PLEX Experience with the platforms used Database Graphical user interface Frameworks Middlewares Very low Very high Low Nominal High < 2 months 6 months 1 year 3 years 6 years Most likely for 577 3/25/11 (C) USC-CSSE

PLEX for 577 Most experiences develop from industry work Many undergraduate courses may not have provided the necessary experience 3/25/11 (C) USC-CSSE

LTEX Experience on the programming language used Experience with the tool support used for development IDE, DBMS Very low Very high Low Nominal High < 2 months 6 months 1 year 3 years 6 years Most likely for 577 3/25/11 (C) USC-CSSE

LTEX for 577 Most are computer science students Should be familiar with few programming languages Chosen language are often picked by developers, not client Pick language most comfortable/experienced with 3/25/11 (C) USC-CSSE

Project Use of Software Tools (TOOL) Multisite Development (SITE) Required Development Schedule (SCED) 3/25/11 (C) USC-CSSE

TOOL Extensiveness on the use of tools in the development process Code editing Life-cycle management Very low Very high Low Nominal High Edit, code, debug Simple CASE, little integration Basic life-cycle tools, moderately integrated Strong life-cycle tools, moderately integrated Proactive life-cycle tools, well integrated with processes, methods, reuse Most likely for 577 3/25/11 (C) USC-CSSE

TOOL for 577 Most teams do not have access to life-cycle support tools Most require expensive licenses Some software engineering aid tools Bugzilla is used for bug/defect tracking SVN for version control 3/25/11 (C) USC-CSSE

SCED Based on percentage of schedule compression Stretch-out or acceleration Accelerated schedules tend to produce more effort at early and later phases Balanced out by middle phases Higher ratings do not add or decrease effort Very low Very high Low Nominal High 75% or nominal 85% of nominal 100% of nominal 130% of nominal 160% of nominal Most likely for 577 3/25/11 (C) USC-CSSE

SCED for 577 Nominal, high, and very high ratings all have value of 1.0 Makes no difference Must be at least nominal since much effort is spent in early phases Address and mitigate risks Design, review, and refine architecture 3/25/11 (C) USC-CSSE

Outline Problems COCOMO II parameters Scale Factors Cost Drivers CSCI577 Scenario COCOMO II estimation uncertainties 3/25/11 (C) USC-CSSE

Purpose To determine the level of estimation uncertainty throughout the project Develop the cone of uncertainty in project effort estimation 3/25/11 (C) USC-CSSE

What to do Revisit project estimation since the beginning of project For each COCOMO parameter, determine Optimistic value Most likely value Pessimistic value The same process done for Code Count assignment 3/25/11 (C) USC-CSSE

What to do First individually revisit the estimations Provide values for the estimations Discuss each COCOMO parameter among team members Final values should be consensus among team members 3/25/11 (C) USC-CSSE