1 U08784 Software Project Management lecturer: Timothy Au url:

Slides:



Advertisements
Similar presentations
FPA – IFPUG CPM 4.1 Rules.
Advertisements

Estimation using COCOMO More Science, Less Art. COCOMO History COCOMO History Constructive Cost Model Dr. Barry Boehm TRW in 1970s COCOMO
Project Estimation: Metrics and Measurement
Metrics. A Good Manager Measures measurement What do we use as a basis? size? size? function? function? project metrics process metrics process product.
Metrics for Process and Projects
Software Engineering II - Topic: Software Process Metrics and Project Metrics Instructor: Dr. Jerry Gao San Jose State University
Software project management (intro)
1 COST ESTIMATION Basics, COCOMO, FP. 2 What is estimated? TIME MONEY TIME: –duration, chronological weeks, months, years –effort, person-month (man-month)
CSC 395 – Software Engineering
CS 551 Estimation Fall December QSE Lambda Protocol Prospectus Measurable Operational Value Prototyping or Modeling sQFD Schedule, Staffing,
SOFTWARE PROJECT MANAGEMENT AND COST ESTIMATION © University of LiverpoolCOMP 319slide 1.
Information Technology Project Management
1 Cost Estimation CIS 375 Bruce R. Maxim UM-Dearborn.
Cmpe 589 Spring Software Quality Metrics Product  product attributes –Size, complexity, design features, performance, quality level Process  Used.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 22 Instructor Paulo Alencar.
COCOMO Models Ognian Kabranov SEG3300 A&B W2004 R.L. Probert.
Estimation Why estimate? What to estimate? When to estimate?
Chapter 6 : Software Metrics
Project Management Estimation. LOC and FP Estimation –Lines of code and function points were described as basic data from which productivity metrics can.
Function Point Analysis What is Function Point Analysis (FPA)? It is designed to estimate and measure the time, and thereby the cost, of developing new.
CS /39 Illinois Institute of Technology CS487 Software Engineering David A. Lash.
A Brief Introduction to COCOMO Hossein Saiedian EECS810: Software Engineering.
Quality Assurance vs. Quality Control Quality Assurance An overall management plan to guarantee the integrity of data (The “system”) Quality Control A.
Software Metrics Software Engineering.
Software Engineering SM ? 1. Outline of this presentation What is SM The Need for SM Type of SM Size Oriented Metric Function Oriented Metric 218/10/2015.
1 U08784 Software Project Management lecturer: Timothy Au url:
1 Estimation Function Point Analysis December 5, 2006.
Lecture 4 Software Metrics
10/27/20151Ian Sommerville.  Fundamentals of software measurement, costing and pricing  Software productivity assessment  The principles of the COCOMO.
Cost Estimation. Problem Our ability to realistically plan and schedule projects depends on our ability to estimate project costs and development efforts.
Project Estimation Model By Deepika Chaudhary. Factors for estimation Initial estimates may have to be made on the basis of a high level user requirements.
Software complexity estimation by Adam Bondarowicz by Adam Bondarowicz.
Estimating Software Projects & Activity Scheduling in the Dynamic, Multi-Project Setting: Choosing Heuristics Through Deterministic Simulation.
Estimation - Software Metrics Managers frequently have to measure the productivity of software engineers.
Function Point Analysis. Function Points Analysis (FPA) What is Function Point Analysis (FPA)? Function points are a standard unit of measure that represent.
SEG3300 A&B W2004R.L. Probert1 COCOMO Models Ognian Kabranov.
Introduction to Software Project Estimation I (Condensed) Barry Schrag Software Engineering Consultant MCSD, MCAD, MCDBA Bellevue.
SOFTWARE PROCESS AND PROJECT METRICS. Topic Covered  Metrics in the process and project domains  Process, project and measurement  Process Metrics.
Estimation using COCOMO
Function Points Synthetic measure of program size used to estimate size early in the project Easier (than lines of code) to calculate from requirements.
CSC 480 Software Engineering Lecture 6 September 11, 2002.
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.
Functional Size Measurement Methodologies. What is FSM ? Definitions: Functional Size: A size of the software derived by quantifying the Functional User.
Project, People, Processes and Products Project management skills – schedule, monitoring, risk management, … People management skills – delegation, mentoring,
540f07cost12oct41 Reviews Postmortem u Surprises? u Use white background on slides u Do not zip files on CD u Team leader should introduce team members.
FUNCTION POINT ANALYSIS & ESTIMATION
Software Project Management Lecture # 3. Outline Metrics for Process and Projects  Introduction  Software Metrics Process metrics Project metrics Direct.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by.
1. 2 Software Project Planning After the finalization of SRS, we would like to estimate size, effort cost and development time of the project. Also, in.
بشرا رجائی برآورد هزینه نرم افزار.
Estimation Questions How do you estimate? What are you going to estimate? Where do you start?
Cost23 1 Question of the Day u Which of the following things measure the “size” of the project in terms of the functionality that has to be provided in.
THE FAMU-CIS ALUMNI SYSTEM
Alternative Software Size Measures for Cost Estimation
RET Rules One of the following rules applies when counting RETs:
Function Point Analysis
Software Planning
Constructive Cost Model
Software Development & Project Management
Personal Software Process Software Estimation
Function Point.
Chapter 5: Software effort estimation- part 2
Software Metrics “How do we measure the software?”
Activities During SPP Size Estimation
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.
Software metrics.
Software Effort Estimation
COCOMO MODEL.
Presentation transcript:

1 U08784 Software Project Management lecturer: Timothy Au url:

2 What have we learnt last week Project Scheduling & Tracking Project Scheduling & Tracking Project Scheduling & Tracking: WBS, CPM, Gantt Charts 4aProject Scheduling & Tracking: WBS, CPM, Gantt Charts 4a 4a Project Planning & Project Planning Techniques: Network Diagram 4bProject Planning & Project Planning Techniques: Network Diagram 4b 4b Assignment Briefing Assignment Briefing Week 1 Exercise Week 1 Exercise Exercise on Network Diagrams (Page 105) will be covered on this week lecture and the fourth lectureExercise on Network Diagrams (Page 105) will be covered on this week lecture and the fourth lecture

3 Lecture 4 In this lecture, you will learn : In this lecture, you will learn : Project Estimation: An Introduction to COCOMO 5aProject Estimation: An Introduction to COCOMO 5a 5a An Introduction to COCOMO (Word document) 5bAn Introduction to COCOMO (Word document) 5b 5b An Introduction to Estimating 5cAn Introduction to Estimating 5c 5c The COnstructive COst MOdel (COCOMO) 5dThe COnstructive COst MOdel (COCOMO) 5d 5d In the second-half lecture, In the second-half lecture, Week 2 Exercise Ex. COCOMO (Page )Week 2 Exercise Ex. COCOMO (Page ) Measure Software Quality (Page ) 6aMeasure Software Quality (Page ) 6a6a Estimating Function Point Analysis (Page ) 6eEstimating Function Point Analysis (Page ) 6e 6e

4 Lecture Outcomes You should be able to understand the following upon this lecture: You should be able to understand the following upon this lecture: Sizing, Effort Estimation and Cost justificationSizing, Effort Estimation and Cost justification Review: Project Planning Steps Project Management PhasesReview: Project Planning Steps Project Management Phases Project Milestones Project Milestones Have your ballpark effort estimationHave your ballpark effort estimation Define your Cost Estimation Report ContentsDefine your Cost Estimation Report Contents Draft detailed project plan (individual)Draft detailed project plan (individual) Identify your project risks (risk analysis report)Identify your project risks (risk analysis report) Draft Quality PlanDraft Quality Plan

5 Software Measurement Measurement in the physical world can be classified into two ways: Measurement in the physical world can be classified into two ways: Direct measures (e.g. the length)Direct measures (e.g. the length) Indirect measures (e.g. the quality, the functionality)Indirect measures (e.g. the quality, the functionality) In software engineering, In software engineering, Direct measures mean cost and effort including line of code (LOC), memory size and defects reported.Direct measures mean cost and effort including line of code (LOC), memory size and defects reported. Indirect measures mean functionality, quality, complexity, efficiency, reliability, maintainability, …Indirect measures mean functionality, quality, complexity, efficiency, reliability, maintainability, …

6 Software Measurement Size oriented metrics Size oriented metrics derived by normalizing quality and/or productivity measures by considering the size of the software.derived by normalizing quality and/or productivity measures by considering the size of the software. The usual practice is to express the work content using SLOC for effort estimationThe usual practice is to express the work content using SLOC for effort estimation lines of code (LOC) or thousand lines of code (KLOC) are chosen as a valuelines of code (LOC) or thousand lines of code (KLOC) are chosen as a value Function-oriented metrics Function-oriented metrics Indirect measures mean functionality, quality, complexity, efficiency, reliability, maintainability, …Indirect measures mean functionality, quality, complexity, efficiency, reliability, maintainability, …

7 Software Project Sizing Commonly, two metrics are used in project sizing estimation: Commonly, two metrics are used in project sizing estimation: lines of code (LOC) andlines of code (LOC) and function point (FP)function point (FP)

8 Line of Code Line of Code (LOC): Line of Code (LOC): Software size is estimated by counting the number of source code in the software programs to be developed.Software size is estimated by counting the number of source code in the software programs to be developed. Sizing should consider the complexity of the overall project and also the effort in design and testing – not just coding.Sizing should consider the complexity of the overall project and also the effort in design and testing – not just coding. More commonly, we refer to KLOC (Kilo Line of Code) instead of LOC.More commonly, we refer to KLOC (Kilo Line of Code) instead of LOC.

9 Function Point Function Point (FP): Function Point (FP): The concept of function point is to quantify the functionality to be delivered of the software to be developed;The concept of function point is to quantify the functionality to be delivered of the software to be developed; by counting the number of inputs, outputs, enquiries, internal interfaces and external interfaces.by counting the number of inputs, outputs, enquiries, internal interfaces and external interfaces.

10 Albrecht function point analysis Albrecht FP Albrecht FP This is a top-down method that was devised by Allan Albrecht when he worked for IBM.This is a top-down method that was devised by Allan Albrecht when he worked for IBM. External input types (EI) External input types (EI) External output types (EO) External output types (EO) Logical Internal file types (ILF) Logical Internal file types (ILF) External interface file types (EIF) External interface file types (EIF) External inquiry types (EQ) External inquiry types (EQ)

11 Computing function points Calculation of Adjusted function point total: Calculation of Adjusted function point total: Adjusted FP = count total x ( x Influence Factor)Adjusted FP = count total x ( x Influence Factor) Therefore, the formula can be expressed as: Therefore, the formula can be expressed as: FP = UFC * TCFFP = UFC * TCF Weighting Factors Program characteristic parameters Count Low Complexity Average Complexity High Complexity No. of input types X346= No. of output types X457= No. of user inquiries X346= No. of files X71015= No. of external interfaces X5710= Count total = Unadjusted function point count Influence Factor (and hence Technical Complexity Factor) Adjusted function point count TCFUFC

12 Albrecht function point analysis Complexity Complexity The counts of each external user type in each complexity is multiplied by specified weights (low, average, high) to get the individual FP scores which are summed to obtain an overall FP count which indicates the whole software project size.The counts of each external user type in each complexity is multiplied by specified weights (low, average, high) to get the individual FP scores which are summed to obtain an overall FP count which indicates the whole software project size.

13 Albrecht function point analysis Complexity Complexity One problem with the Albrecht FP is that the question of whether the external user type of low, average, high complexity is rather subjective.One problem with the Albrecht FP is that the question of whether the external user type of low, average, high complexity is rather subjective. The International Function Point User Group (IFPUG) suggests rules on how this to be judged for estimating software project size.The International Function Point User Group (IFPUG) suggests rules on how this to be judged for estimating software project size.

14 Albrecht function point analysis IFPUG File type complexity Number of record types Number of data types < > 50 1LowLowAverage LowAverageHigh > 5 AverageHighHigh IFPUG External input complexity Number of file types accessed Number of data types accessed < 6 6 – 19 > 19 0 – 1 LowLowAverage 2LowAverageHigh > 2 AverageHighHigh IFPUG External output complexity Number of file types Number of data types < 6 6 – 19 > 19 0 – 1 LowLowAverage 2 – 3 LowAverageHigh > 3 AverageHighHigh

15 Albrecht function point analysis Complexity Complexity The general functionality of the systems will be affected by the following 14 complexity characteristics are identified to rate the general functionality of the systemThe general functionality of the systems will be affected by the following 14 complexity characteristics are identified to rate the general functionality of the system (1) Data Communication(8) On-line Update (2) Distributed Processing(9) Complex Processing (3) Performance(10) Reusability (4) Heavily Used Configuration (11) Installation Ease (5) Transaction Rate(12) Operational Ease (6) On-line Data Entry(13) Multiple Sites (7) End-User Efficiency(14) Ease of Change

16 Albrecht function point analysis Complexity Complexity The weight of the 14 complexity adjustment factors are:The weight of the 14 complexity adjustment factors are: 0no influence 0no influence 1incidental 1incidental 2moderate 2moderate 3average 3average 4significant 4significant 5essential 5essential

17 Function Points Mark II For each transaction the Unjustified Function points (UFP’s) are calculated from the following factors: For each transaction the Unjustified Function points (UFP’s) are calculated from the following factors: Input data element types (I)Input data element types (I) Entity types referenced (E)Entity types referenced (E) Output data element types (O)Output data element types (O) The Function Point Mk II is The Function Point Mk II is FP = 0.58I E OFP = 0.58I E O

18 COCOMO The COnstructive COst MOdel (COCOMO) The COnstructive COst MOdel (COCOMO) It is an algorithmic Software Cost Estimation Model developed by Barry Boehm.It is an algorithmic Software Cost Estimation Model developed by Barry Boehm. It is an line of code based cost estimation model.It is an line of code based cost estimation model. It is a static, single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code.It is a static, single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code.

19 COCOMO Projects are categorized into three types: Organic projects Organic projects are relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements.are relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements. Semi-detached projects Semi-detached projects are intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.are intermediate (in size and complexity) software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements. Embedded projects Embedded projects are software projects that must be developed within a set of tight hardware, software, and operational constraintsare software projects that must be developed within a set of tight hardware, software, and operational constraints

20 COCOMO The Basic COCOMO model equations take the form The Basic COCOMO model equations take the form E=a b (KLOC)Effort (in Person-Month)E=a b (KLOC)Effort (in Person-Month) D=c b (E)d b Development Time in month (TDEV)D=c b (E)d b Development Time in month (TDEV) P=E/D ProductivityP=E/D Productivity Software project abababab bbbbbbbb cbcbcbcb dbdbdbdb organic Semi-detached Embedded Organic: E=2.4(KLOC) 1.05Organic: E=2.4(KLOC) 1.05 Semi-detached: E=3.0(KLOC) 1.12Semi-detached: E=3.0(KLOC) 1.12 Embedded: E=3.6(KLOC) 1.20Embedded: E=3.6(KLOC) 1.20 bbbbbbbb Effort

21 COCOMO The Basic COCOMO Model equations take the form The Basic COCOMO Model equations take the form E=a b (KLOC)Effort (in Person-Month)E=a b (KLOC)Effort (in Person-Month) D=c b (E)d b Development Time in month (TDEV)D=c b (E)d b Development Time in month (TDEV) P=E/D ProductivityP=E/D Productivity Software project abababab bbbbbbbb cbcbcbcb dbdbdbdb organic Semi-detached Embedded Organic: T=2.5(E) 0.38Organic: T=2.5(E) 0.38 Semi-detached: E=2.5(E) 0.35Semi-detached: E=2.5(E) 0.35 Embedded: E=2.5(E) 0.32Embedded: E=2.5(E) 0.32 bbbbbbbb Time

22 COCOMO The Intermediate COCOMO Model refines The Intermediate COCOMO Model refines the estimate with a complexity factor by computing the project effort as a function of program size;the estimate with a complexity factor by computing the project effort as a function of program size; by the adjustment of 4 cost drivers that includes a subjective assessment of a set of 15 attributes.by the adjustment of 4 cost drivers that includes a subjective assessment of a set of 15 attributes. The product of all effort multipliers results is an Effort Adjustment Factor (EAF) i.e. E=a b (KLOC) x EAF Effort (in Person-Month)The product of all effort multipliers results is an Effort Adjustment Factor (EAF) i.e. E=a b (KLOC) x EAF Effort (in Person-Month)

23 COCOMO The Detailed COCOMO Model includes The Detailed COCOMO Model includes all characteristics of the intermediate version with an assessment of the cost driver's impact on each step of the software engineering process. [By Shamsul Arif Nowshehra]all characteristics of the intermediate version with an assessment of the cost driver's impact on each step of the software engineering process. [By Shamsul Arif Nowshehra]

24 COCOMO II The COCOMO II Model The COCOMO II Model is a more comprehensive cost model to compute the effort, cost and time from the program size.is a more comprehensive cost model to compute the effort, cost and time from the program size. It is evolved from COCOMO (COCOMO 81).It is evolved from COCOMO (COCOMO 81). It is also a phase-based model but the project size may be measured in LOC and FP or even object points such as srceens, reports.It is also a phase-based model but the project size may be measured in LOC and FP or even object points such as srceens, reports. The concept of code reusability is included.The concept of code reusability is included.

25 Staffing Staffing Plan and Resources Planning Staffing Plan and Resources Planning Staffing changes over the project timeline;Staffing changes over the project timeline; What kind of staff is required at what time at what price?What kind of staff is required at what time at what price? Adding staff at the right time;Adding staff at the right time; Team size, team building, motivation, …Team size, team building, motivation, …