ETSF01: Software Engineering Process Economy and Quality. Chapter Five. Software effort estimation. Software Project Management

Transcription

1 Software Project Management ETSF01: Software Engineering Process Economy and Quality Dietmar Pfahl Lund University Chapter Five Software effort estimation What makes a successful project? Cost/Schedule Estimation Basic Idea Delivering: agreed functionality on time at the agreed cost with the required quality Stages: 1. set targets 2. attempt to achieve targets BUT what if the targets are not achievable? Software cost/schedule estimation is the process of predicting the amount of effort (cost) required to build a software system and the time (schedule) to develop it. Project Cost: Hardware costs. Travel and training costs. Work costs (based on the effort spent by engineers). Project Schedule: Elapsed time (in hours, days, weeks, months) Basis for successful estimating Typical problems with estimating Information about past projects Need to collect data about past project: Size/difficulty(complexity)/functionality? Effort/time consumption? Need to be able to measure the amount of work involved Lines of Code (or Statements, Halstead s measures) KLOC vs. Delta-KLOC Cyclomatic Complexity (McCabe) Function Points (or Use Case Points, User Stories, ) Subjective nature of estimating It may be difficult to produce evidence to support your assumptions about cost (schedule) drivers Political pressures Managers may wish to reduce estimated costs in order to win a project proposal Developers may wish to increase estimates to safeguard themselves from unforeseen (unforeseeable) risks Changing technologies They involve risks (uncertainties), especially in the beginning when there is a learning curve Projects differ Experience on one project may not be transferable to another 1

2 Effort-Time Trade-Off People Effort = 4 Source: B. Boehm: Software Engineering Economics, Prentice-Hall, Effort-Time Trade-Off COCOMO Time People Effort = 4? Time People Effort = ? Time Price S COCOMO Estimation Techniques Main Types Top-Down Estimation Algorithmic/ Parametric Models Constraint Models: - SLIM - Jensen Model - COPMO - etc. Cost/Schedule Estimation Techniques Analogy Machine Learning: - Case-Based Reasoning - Collaborative Filtering - Classification Systems - etc. Expert Judgment Empirical Factor Models: - COCOMO / COCOMO II - ESTIMACS - PRICE S - Softcost - DOTY - CheckPoint Source: Boehm (1981) - etc. Other Parkinson s Law Pricing-to-Win Top-Down Estimation Bottom-Up Estimation A cost/schedule estimate is established by considering the overall functionality of the product and how that functionality is provided by interacting sub-functions. Cost estimates are made on the basis of the logical functionality rather than implementation details. Advantage: Takes into account costs such as integration, configuration management and documentation Disadvantage: Can underestimate the cost of solving difficult low-level technical problems Example: Top-down schedule estimation Bottom-Up Estimation Produce overall schedule estimate overall project Estimate: 100 days Start at the lowest system level. The cost/schedule of each component is estimated. All these costs are added to produce a final cost estimate. Distribute proportions of overall estimate to components design 30% i.e. 30 days code 30% i.e. 30 days test 40% i.e. 40 days Advantage: Can be accurate, if the system has been designed in detail Disadvantage: May underestimate costs of system level activities such as integration and documentation 2

3 Pricing-to-Win Parkinson's Law The software cost/schedule is estimated to be whatever the customer has available to spend on the project. The estimated effort depends on the customer's budget and not on the software functionality. Advantage: Good chances to get the contract Disadvantages: The probability that costs accurately reflect the work required and the probability that the customer gets the system he or she wants are small. Parkinson's Law states that work expands to fill the time available. In software costing/scheduling, this means that the cost is determined by available resources rather than by objective assessment. Example: If the software has to be delivered in 12 months and 5 people are available, the effort required is estimated to be 60 person-months. Advantage: No overspending Disadvantage: System is often unfinished / or effort is wasted Expert Judgement Estimation by Analogy One or more experts in both software development and the application domain use their experience to predict software costs. Process iterates until some consensus is reached (e.g., using Delphi Method). Advantage: Relatively cheap estimation method. Can be accurate if experts have substantial experience with similar systems. Disadvantage: Very inaccurate if there are no experts! Difficult to trace back, in case the estimate was not accurate. This technique is applicable when other projects in the same application domain have been done in the past. The cost of a new project is computed by comparing the project to a similar completed project in the same application domain Advantages: Accurate if similar project data are available Disadvantages: Impossible if no comparable project available. Needs systematically maintained project database (à expensive). It s not always clear how to define a good similarity function. How to find similar projects in a data base? Case-Based Reasoning (CBR): Involves (a) matching the current problem against ones that have already been encountered in the past and (b) adapting the solutions of the past problems to the current context. It can be represented as a cyclical process that is divided into the four following sub-processes as depicted in the Figure (Aamodt & Plaza 1994): retrieve the most similar cases from the case base reuse the case to solve the problem revise the proposed solution if necessary retain the solution for future problem solving Effort Estimation Model Example (1) Case-Based Reasoning (CBR) Example: Attributes New Case Retrieved Case 1 Retrieved Case 2 Project Category Real Time Real Time Simulator Language C C C Team Size System Size Effort? Similarity 90% ~50% Possibilities to predict effort: adapted effort based on 1 project average effort of 2 projects weighted average effort of 2 projects Effort=f (System_Size) Possible adaptation rule: 150 Predicted _ Effort = 1000 =

4 Effort Estimation Model Example (2) Case-Based Reasoning (CBR) Example: Effort=f (System_Size) Effort Estimation Model Example (3) Case-Based Reasoning (CBR) Example: Effort=f (System_Size) Attributes New Case Retrieved Case 1 Retrieved Case 2 Project Category Real Time Real Time Simulator Language C C C Team Size System Size Effort? Similarity 90% ~50% Attributes New Case Retrieved Case 1 Retrieved Case 2 Project Category Real Time Real Time Simulator Language C C C Team Size System Size Effort? Similarity 90% ~50% Possibilities to predict effort: adapted effort based on 1 project average effort of 2 projects weighted average effort of 2 projects Possible adaptation rule: Predicted _ Effort = Possibilities to predict effort: adapted effort based on 1 project average effort of 2 projects weighted average effort of 2 projects Possible adaptation rule: Predicted _ Effort = 1000* 950* Effort Estimation Model Similarity (1) Case-Based Reasoning (CBR) Example: Distance Measure (Euclidean Distance) à Similarity = 1 Distance Effort Estimation Model Similarity (2) Case-Based Reasoning (CBR) Example: Distance Measure (Euclidean Distance) à Similarity = 1 Distance dis tance( P,P ) i j n k= 1 = δ ( P,P ) n ik jk 2 P ik Pjk if k continuous maxk mink δ ( Pik,Pjk ) = 0, if k categorical AND Pik = Pjk 1,if k categorical AND Pik Pjk dis tance( P,P ) i j n k= 1 = δ ( P,P ) n ik jk 2 P ik Pjk if k continuous maxk mink δ ( Pik,Pjk ) = 0, if k categorical AND Pik = Pjk 1,if k categorical AND Pik Pjk P.,k P new,k P 1,k δ(p new,k, P 1,k ) Project Category Real Time Real Time 0 Language C C 0 Team Size System Size =(50/250) 2 distance(p new, P 1 )= 0.1 Assume that smallest system in DB has 100 KLOC and largest system has 350 KLOC à max min = 250 KLOC P.k P new,k P 2,k δ(p new,k,p 2,k ) Project Category Real Time Simulator1 Language C C 0 Team Size =(1/10) 2 System Size =(25/250) 2 distance(p new, P 2 ) 0.5 Assume that smallest system in DB has 100 KLOC and largest system has 350 KLOC à max min = 250 KLOC Algorithmic/Parametric Models Parametric Models Simple Example Idea: System characteristics: Expected size/difficulty/complexity/functionality System Characteristics Algorithm (Model) Estimate Model needs to be calibrated to data from past projects (or is universal) Simplistic models: Estimated effort = (Estimated system size) / Productivity1 Estimated time = (Estimated system size) / Productivity2 E.g.: System size estimated in KLOC Productivity1 = KLOC / Person-day Productivity2 = KLOC / Day Productivity1 = (System size) / Effort Productivity2 = (System size) / Day E.g., calculated as average value from past projects 4

5 Parametric model: COCOMO COCOMO Introduction /1 COCOMO = Constructive Cost Model Size measure (KLOC, FP) & productivity factors as input System size COCOMO Model Productivity factors Estimated Effort & schedule COCOMO (Constructive Cost Model) [Boe81] COCOMO is a model based on inputs relating to the size of the system and a number of cost drivers that affect productivity. Enhanced version, called COCOMO II, accounts for recent changes in software engineering technology, including object-oriented software, software created following spiral or evolutionary development models, software reuse, Prof. Dr. Barry Boehm building new systems using off-the-shelf software components (COTS). COCOMO Introduction /2 COCOMO Development Modes The original COCOMO is a collection of three models: Basic model applied early in the project Intermediate model applied after requirements acquisition Advanced model applied after design is complete All three models take the form: b d E = as EAF Tdev = ce where E is effort in person months Tdev is the development time (schedule) S is size measured in thousands of lines of code (or DSI*) EAF is an effort adjustment factor (=1 in the Basic model) Factors a, b, c and d depend on the development mode. COCOMO has three development modes: Organic mode: small teams, familiar environment, well-understood applications, no difficult non-functional requirements (EASY) Semi-detached mode: project team may have experience mixture, system may have more significant non-functional constraints, organization may have less familiarity with application (HARDER) Embedded mode: hardware/software systems, tight constraints, unusual for team to have deep application experience (HARD) *DSI = Delivered Source Instructions Basic COCOMO Effort Equations Basic COCOMO Examples /1 Organic mode: PM = 2.4 (KDSI) 1.05 Semi-detached mode: PM = 3.0 (KDSI) 1.12 Embedded mode: PM = 3.6 (KDSI) 1.20 KDSI = Kilo Delivered Source Instructions (~KLOC) Note: large changes in effort and productivity, small changes in schedule 5

6 Basic COCOMO Examples /2 Basic COCOMO: Effort Distribution [Boe81] Staffing? Organic mode project: 32 KLOC PM = 2.4 (32) 1.05 = 91 person-months TDEV = 2.5 (91) 0.38 = 14 months N = 91/14 = 6.5 people (on average) Embedded mode project: 128 KLOC PM = 3.6 (128) 1.2 = 1216 personmonths TDEV = 2.5 (1216) 0.32 = 24 months N = 1216/24 = 51 people (on average) Table shows percentages! Basic COCOMO: Schedule Distribution [Boe81] Basic COCOMO: Accuracy and Quality [Boe81] Pred(0.3) = 0.29 Pred(1.0) = 0.60 Table shows percentages! NB: good predictive quality is Pred(0.25) = 0.75, i.e., 75% of all estimates are within ±25% of actual effort Intermediate COCOMO Intermediate COCOMO: EAF The Intermediate COCOMO model computes effort as a function of program size and a set of cost drivers. Intermediate COCOMO equation: ( ) b E = a KLOC EAF Mode a b Organic Semi-detached Embedded d Tdev = cenom Mode c d The factors a, b, c and d for Organic the intermediate model are Semi-detached shown in the tables. The effort adjustment factor Embedded (EAF) is calculated using 15 cost drivers. extra high very high high nominal low very low The effort adjustment factor (EAF) is calculated using 15 cost drivers. The cost drivers are grouped into 4 categories: product, computer, personnel, and project. Each cost driver is rated on a 6 point ordinal scale ranging from very low to extra high importance. Based on the rating, the effort multiplier (EM) is determined (Boehm, 1981). The product of all effort multipliers is the EAF. 15 = nom = i= 1 E E EAF EAF EM i 6

7 Intermediate COCOMO: 15 Cost Drivers Cost Driver Rating Product Factors Product Factors Reliability (RELY) Data (DATA) Complexity (CPLX) Platform Factors Time constraint (TIME) Storage constraint (STOR) Platform volatility (PVOL) Personnel factors Analyst capability (ACAP) Program capability (PCAP) Applications experience (APEX) Platform experience (PLEX) Language and tool experience (LTEX) Personnel continuity (PCON) Project Factors Software tools (TOOL) Multisite development (SITE) Required schedule (SCED) RELY Description Very Low Low Nominal High Very High Required software reliability DATA Database size CPLX Product complexity Extra High Cost Driver Rating Computer Factors Cost Driver Rating Personnel Factors TIME STOR VIRT TURN Description Execution time constraint Main storage constraint Virtual machine volatility Computer turnaround time Very Low Low Nominal High Very High Extra High ACAP AEXP PCAP VEXP LEXP Description Analyst capability Applications experience Programmer capability Virtual machine experience Language experience Very Low Low Nominal High Very High Extra High Cost Driver Rating Project Factors Description MODP Modern programming practices Very Low Low Nominal High Very High TOOL Software Tools SCED Development Schedule Extra High Advanced COCOMO Average Staffing Effort Effort Effort Effort RPD DD CUT IT Phase The Advanced COCOMO model computes effort as a function of program size and a set of cost drivers with weights according to each phase of the software lifecycle. The Advanced COCOMO model applies the Intermediate model at the module level, and then a phasebased approach is used to consolidate the estimate. 7

8 Advanced COCOMO: Example Cost Driver The 4 phases used in the detailed (or: advanced) COCOMO model are: requirements planning and product design (RPD), detailed design (DD), code and unit test (CUT), and integration and test (IT). Each cost driver is broken down by phase as in the table below. Estimates made for each module are combined into subsystems and eventually an overall project estimate. COCOMO II Cost Driver Rating RPD DD CUT IT ACAP (Analyst capability) Very Low Low Nominal High Very High ACAP Intermediate 1.46 Very Low 1.19 Low 1.00 Nominal 0.86 High 0.71 Very High COCOMO II Accuracy Funnel Relative Size Range 4x 2x x 0.5x 0.25x Operational Concept Life Cycle Objectives Life Cycle Architecture Feasibility Plans/Rqts. Design Develop and Test Phases and Milestones Initial Operating Capability COCOMO II Three Sub-Models COCOMO II includes a three-stage series of models: The earliest phases (or cycles of the spiral model) will generally involve prototyping, using the Application Composition Model. (replaces Basic COCOMO) The next phases or spiral cycles will generally involve exploration of architectural alternatives or incremental development strategies. To support these activities, COCOMO II provides an early estimation model called the Early Design Model. (replaces Intermediate COCOMO) Once the project is ready to develop, it should have a lifecycle architecture, which provides more accurate information on cost driver inputs, and enables more accurate cost estimates. To support this stage, COCOMO II provides the Post-Architecture Model. (replaces Advanced COCOMO) COCOMO II Early Design Model (EDM) The Early Design model is used to evaluate alternative software/system architectures and concepts of operation. An unadjusted function point count (UFC) is used for sizing. This value is converted to KLOC. The Early Design model equation is: = E2.45 = a ( KLOC ) b EAF = E KLOC EAF b SF The effort adjustment factor (EAF) is the product of seven cost drivers. SF i : Scale Factor i a = j= 1 i COCOMO II EDM Cost Drivers (Effort Multipliers) The effort adjustment factor (EAF) for the Early Design model (= simplified set of effort multipliers (obtained by combining COCOMO s 17 Post-Architecture cost drivers) Cost Driver Description Represent Combined Post- Architecture Cost Drivers 1 RCPX Product reliability and complexity RELY, DATA, CPLX, DOCU 2 RUSE Required reuse RUSE 3 PDIF Platform difficulty TIME, STOR, PVOL 4 PERS Personnel capability ACAP, PCAP, PCON 5 PREX Personnel experience AEXP, PEXP, LTEX 6 FCIL Facilities TOOL, SITE 7 SCED Schedule SCED 5 Scale Factors (Exponent Drivers) 8

9 COCOMO II EDM Cost Drivers (Effort Multipliers) Extra low Very low Low Nominal High Very high Extra high RCPX RUSE PDIF PERS PREX FCIL SCED COCOMO II EDM Scale Factors Scale Factors (SF): 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 COCOMO II EDM SF Ratings Scale Factor (SF) Ratings SF Very Low Low Nominal High Very Extra High High Precedentedness PREC Development/Flexibility FLEX Architecture/Risk Resolution RESL Team Cohesion TEAM Process Maturity PMAT COCOMO II Early Design Model E = a ( KLOC) b EAF [0 6.20] [0 5.07] [0 7.07] [0 5.48] [0 7.80] Person-Month Effort Estimates b= SFi j= 1 b= b= b= B-VL B-L B-N B-H B-VH B-EH b=1 KLOC COCOMO II EDM Scale Factors Sum scale factors SF i to determine a scale exponent, b, with b = Σ SF i COCOMO II EDM SFs PREC & FLEX Elaboration of the PREC and FLEX rating scales: 9

10 COCOMO II EDM Scale Factor RESL Elaboration of the RESL rating scale: Use a subjective weighted average of the characteristics COCOMO II EDM Scale Factor TEAM Elaboration of the TEAM rating scale: Use a subjective weighted average of the characteristics to account for project turbulence and entropy due to difficulties in synchronizing the project's stakeholders. Stakeholders include users, customers, developers, maintainers, interfacers, and others PDR = Product Design Review COTS = Component Off-The-Shelf COCOMO II EDM Scale Factor PMAT Elaboration of the PMAT rating scale: Two methods based on the Software Engineering Institute's Capability Maturity Model (CMM) Method 1: Overall Maturity Level (CMM Level 1 through 5) Method 2: Key Process Areas (see next slide) COCOMO II EDM Scale Factor PMAT Elaboration of the PMAT rating scale (Method 2): Decide the percentage of compliance for each of the KPAs as determined by a judgement-based averaging across the goals for all 18 Key Process Areas. COCOMO II Example Example A software development team is developing an application which is very similar to previous ones it has developed. Information relevant for Scale Factors: A very precise software engineering document lays down very strict requirements. à PREC is very high (score 1.24). FLEX is very low (score 5.07). The good news is that these tight requirements are unlikely to change (RESL is high with a score 2.83). The team is tightly knit (TEAM has high score of 2.19), but processes are informal (so PMAT is low and scores 6.24) 10

11 Example Scale factor calculation Example Effort multipliers The formula for SF is SF = b 0.01 Σ scale factor values = ( ) = If the system contained 10 KLOC then the effort estimate would be 2.94 x = 35.8 person-months Note that for larger systems, the effect of the scale factor becomes over-proportionally stronger Say that a new project is similar in most characteristics to those that an organization has been dealing with in the past, except the software to be produced is exceptionally complex and will be used in a safety critical system; the software will interface with a new operating system that is currently in beta status; to deal with this the team allocated to the job are regarded as exceptionally good, but do not have a lot of experience on this type of software. Example Effort multiplier application Function Points RCPX very high 1.91 PDIFvery high 1.81 PERS extra high 0.50 PREX nominal 1.00 All other factors are nominal Say the estimated size is 10 KLOC resulting in an effort estimate of 35.8 person-months With effort multipliers applied, this becomes: 35.8 x 1.91 x 1.81 x 0.5 = 61.9 [person-months] Function-Oriented Measures Parametric Model Functional Size Specification Architectural Design Micro Design Implementation Integration Test Module Test Acceptance Test à Estimation before implementation! Functionality is one aspect of software size. The assumption is that a product with more functionality is larger in size and thus needs more effort to be developed. The first function-oriented measure was proposed by Albrecht (1979~1983). He suggested a size measurement approach called the Function Point (FP) method. Function points (FPs) measure the amount of functionality in a system based upon the system specification. Number of file types Models for estimating Function Points: Albrecht / IFPUG Function Points Mark II Function Points COSMIC Function Points Model Numbers of input and output transaction types System size (Function Points) 11

12 Function Point (FP) Standards Standard Name Content ISO/IEC :2000 ISO/IEC 20926:2004 ISO/IEC 19761:2003 ISO/IEC 20968:2002 IFPUG 4.1 IFPUG 4.2 COSMIC- FFP Mark II Function Point Analysis Unadjusted functional size measurement method -- Counting practices manual IFPUG Function Points VS 4.1 (unadjusted) Unadjusted functional size measurement method -- Counting practices manual IFPUG Function Points VS 4.2 (unadjusted) A functional size measurement method COSMIC Full Function Points Vs. 2.2 Counting Practices Manual Mark II Function Points Function Points (IFPUG) Albrecht/IFPUG Function Points Albrecht/IFPUG FPs Elements Albrecht worked at IBM and needed a way of measuring the relative productivity of different programming languages. Needed some way of measuring the size of an application without counting lines of code. Identified five types of component or functionality in an information system Counted occurrences of each type of functionality in order to get an indication of the size of an information system Five function types 1. Logical interface file (LIF) types equates roughly to a datastore in systems analysis terms. Created and accessed by the target system 2. External interface file (EIF) types where data is retrieved from a datastore which is actually maintained by a different application. 3. External input (EI) types input transactions which update internal software files 4. External output (EO) types transactions which extract and display data from internal computer files. Generally involves creating reports. 5. External inquiry (EQ) types user initiated transactions which provide information but do not update computer files. Normally the user inputs some data that guides the system to the information the user needs. Albrecht/IFPUG FPs Complexity Multipliers Albrecht/IFPUG FPs Example External user types Low complexity Medium complexity High complexity EI EO EQ LIF EIF Payroll application has: 1. A transaction to add, update and delete employee details à an EI rated to be of medium complexity 2. A transaction that calculates pay details from timesheet data that is input à an EI rated to be of high complexity 3. A transaction that prints out pay-to-date details for each employee à an EO rated to be of medium complexity 4. A file of payroll details for each employee à an LIF rated to be of medium complexity 5. A personnel file maintained by another system is accessed for name and address details à a simple EIF What would be the FP count for such a system? 12

13 IFPUG FP counts IFPUG Function Point Counting Big Picture 1. Medium EI 4 FPs 2. High complexity EI 6 FPs 3. Medium complexity EO 5 FPs 4. Medium complexity LIF 10 FPs 5. Simple EIF 5 FPs Total 30 FPs If previous projects delivered 5 FPs per day, implementing the above should take 30/5 = 6 days Step 2 Step 1b Step 1a EI L A H EO Adjusted FP Count 14 Adjustment Factors EQ EIF Complexity Adjustment Weigthed ILF L A H L A H L A H L A H # EI # EO # EQ # EIF # ILF = = Adjusted Function Points Value Adjustment Factor (VAF)) Unadjusted Function Points (UFP) Weighting of functional (technical) complexities Unadjusted and Unweighted Function Count IFPUG Function Points (FP) Key Elements IFPUG FP External Inputs (EI) External Inputs (EI) External Interface Files (EIF) Internal Logical Files (ILF) Inputs Data Objects Function Point (FP) Outputs Processes External Outputs (EO) External Inquiries (EQ) External Inputs IFPUG Definition: An external input (EI) is an elementary process that processes data or control information that comes from outside the application boundary. The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system. Examples: Data entry by users Data or file feeds by external applications IFPUG FP External Outputs (EO) IFPUG FP External Inquiries (EQ) External Outputs IFPUG Definition: An external output (EO) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external output is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information. The processing logic must contain at least one mathematical formula or calculation, create derived data, maintain one or more ILFs, or alter the behavior of the system. Example: Reports created by the application being counted, where the reports include derived information External Inquiries IFPUG Definition: An external inquiry (EQ) is an elementary process that sends data or control information outside the application boundary. The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information from an ILF or EIF. The processing logic contains no mathematical formulas or calculations, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered. Example: Reports created by the application being counted, where the report does not include any derived data 13

14 IFPUG FP Internal Logical Files (ILF) IFPUG FP Ext. Interface Files (EIF) Internal Logical Files IFPUG Definition: An ILF is a user-identifiable group of logically related data or control information maintained within the boundary of the application. The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted. Examples: Tables in a relational database. Flat files. Application control information, perhaps things like user preferences that are stored by the application. External Interface files IFPUG Definition: An external interface file (EIF) is a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application. The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application counted. This means an EIF counted for an application must be in an ILF in another application. Examples: As for ILF, but maintained in a different system IFPUG Function Point Counting Big Picture IFPUG Unadjusted FP Count (UFC) Step 2 Step 1b Step 1a EI L A H EO Adjusted FP Count 14 Adjustment Factors EQ EIF Complexity Adjustment Weigthed ILF L A H L A H L A H L A H # EI # EO # EQ # EIF # ILF = = Adjusted Function Points Value Adjustment Factor (VAF)) Unadjusted Function Points (UFP) Weighting of functional (technical) complexities Unadjusted and Unweighted Function Count A complexity rating is associated with each count using function point complexity weights: Item Weighting Complexity Factor Simple Low Average Complex High External inputs (à N EI) External outputs (à N EO) External inquiries (à N EQ) External interface files (à N EIF) Internal logical files (à N ILF) UFC = 4 NEI 5NEO 4NEQ 7NEIF 10 N ILF IFPUG FP Counting: Weighting of Technical Complexity IFPUG Function Point Counting Big Picture Elements External Inputs (EI) External Outputs (EO) External Inquiries (EQ) External Interface Files (EIF) Internal Logical Files (ILF) Complexity low average high x 3 = x 4 = x 6 = x 4 = x 5 = x 7 = x 3 = x 4 = x 6 = x 5 = x 7 = x10 = x 7 = x10 = x15 = Unadjusted Function Points (UFP) Sum Step 2 Step 1b Step 1a EI L A H EO Adjusted FP Count 14 Adjustment Factors EQ EIF Complexity Adjustment Weigthed ILF # EI # EO # EQ # EIF # ILF L A H L A H L A H L A H = = Adjusted Function Points Value Adjustment Factor (VAF)) Unadjusted Function Points (UFP) Weighting of functional (technical) complexities Unadjusted and Unweighted Function Count 14

15 IFPUG Value Adjustment Factor (VAF) /1 IFPUG Value Adjustment Factor (VAF) /2 Value Adjustment Factor (VAF) is a weighted sum of 14 Factors (General System Characteristics (GSC)): F1 Data Communications F2 Distributed Data Processing F3 Performance F4 Heavily Used Configuration F5 Transaction Rate F6 On-line Data Entry F7 End-User Efficiency F8 On-line Update F9 Complex Processing F10 Reusability F11 Installation Ease F12 Operational Ease F13 Multiple Sites F14 Facilitate Change 1. Data Communications: The data and control information used in the application are sent or received over communication facilities. 2. Distributed Data Processing: Distributed data or processing functions are a characteristic of the application within the application boundary. 3. Performance: Application performance objectives, stated or approved by the user, in either response or throughput, influence (or will influence) the design, development, installation and support of the application. 4. Heavily Used Configuration: A heavily used operational configuration, requiring special design considerations, is a characteristic of the application. 5. Transaction Rate: The transaction rate is high and influences the design, development, installation and support. 6. On-line Data Entry: On-line data entry and control information functions are provided in the application. 7. End-User Efficiency: The on-line functions provided emphasize a design for end-user efficiency. 8. On-line Update: The application provides on-line update for the internal logical files. 9. Complex Processing: Complex processing is a characteristic of the application. 10. Reusability: The application and the code in the application have been specifically designed, developed and supported to be usable in other applications. 11. Installation Ease: Conversion and installation ease are characteristics of the application. A conversion and installation plan and/or conversion tools were provided and tested during the system test phase. 12. Operational Ease: Operational ease is a characteristic of the application. Effective start-up, backup and recovery procedures were provided and tested during the system test phase. 13. Multiple Sites: The application has been specifically designed, developed and supported to be installed at multiple sites for multiple organizations. 14. Facilitate Change: The application has been specifically designed, developed and supported to facilitate change. IFPUG Value Adjustment Factor (VAF) /3 IFPUG Function Point Counting: Complexity Assessment Details Each component is rated from 0 to 5, where 0 means the component is not relevant to the system and 5 means the component is essential. Step 2 Adjusted FP Count 14 Adjustment Factors Complexity Adjustment Adjusted Function Points Value Adjustment Factor (VAF)) The VAF can then be calculated as: The VAF varies from 0.65 (if all Fj are set to 0) to 1.35 (if all Fj are set to 5) 14 TCF VAF = Fj j= 1 Step 1b Step 1a EI L A H EO EQ EIF Weigthed ILF L A H L A H L A H L A H # EI # EO # EQ # EIF # ILF = = Unadjusted Function Points (UFP) Weighting of functional (technical) complexities Unadjusted and Unweighted Function Count IFPUG Function Point Counting Elements IFPUG Function Types for Complexity Assessment Data Function Types Transaction Function Types Elements evaluated for technical complexity assessment Internal Logical Files (ILF) External Interface Files (EIF) REcord Types (RET): User recognizable sub groups of data elements within an ILF or an EIF. It is best to look at logical groupings of data to help identify them. External Input (EI) External Output (EO) External Inquiry (EQ) File Type Referenced (FTR): File type referenced by a transaction. An FTR must be an Internal Logical File (ILF) or External Interface File (EIF). Data Element Types (DET): A unique user recognizable, non-recursive (non-repetitive) field containing dynamic information. If a DET is recursive then only the first occurrence of the DET is considered not every occurrence. 15

16 IFPUG Internal Logical File Complexity Assessment IFPUG Internal Logical File Example Identify number of Record Types (RET) Identify number of Data Element Type (DET) Determine complexity (à used to calculate FP count) ILF: Employee = Employee - Name - ID - Birth Date - Payment Reference 1 RET 4 DET #RET ILF #DET > 50 1 low (7) low (7) average (10) 2-5 low (7) average (10) high (15) > 5 average (10) high (15) high (15) #RET ILF #DET > 50 1 low (7) low (7) average (10) 2-5 low (7) average (10) high (15) > 5 average (10) high (15) high (15) IFPUG External Interface File Complexity Assessment IFPUG External Interface File Example Identify number of Record Types (RET) Identify number of Data Element Type (DET) Determine complexity (à used to calculate FP count) Payroll Software Employee - Name - ID - Birth Date - Payment Reference Weekly Payment - Hourly Rate - Payment Office EIF: Employee Administration (DB) Monthly Payment - Salary Level #RET EIF #DET > 50 1 low (5) low (5) average (7) 2-5 low (5) average (7) high (10) > 5 average (7) high (10) high (10) 2 RET 7 DET #RET EIF #DET > 50 1 low (5) low (5) average (7) 2-5 low (5) average (7) high (10) > 5 average (7) high (10) high (10) IFPUG External Input Complexity Assessment IFPUG External Input Example Identify number of File Types Referenced (FTR) Identify number of Data Element Type (DET) Determine complexity (à used to calculate FP count) Employee - Name - ID - Birth Date - Payment Reference Weekly Payment - Hourly Rate - Payment Office ILF: Employee Administration (DB) Monthly Payment - Salary Level Enter a new employee with Monthly Payment: Name, ID, Birth Date, Payment Reference, Salary Level. #FTR EI #DET > 15 1 low (3) low (3) average (4) 2 low (3) average (4) high (6) > 2 average (4) high (6) high (6) 1 FTR 5 DET #FTR EI #DET > 15 1 low (3) low (3) average (4) 2 low (3) average (4) high (6) > 2 average (4) high (6) high (6) 16

17 IFPUG External Input Example IFPUG External Output Complexity Assessment Employee - Name - ID - Birth Date - Payment Reference Weekly Payment - Hourly Rate - Payment Office 1 FTR 6 DET ILF: Employee Administration (DB) Monthly Payment - Salary Level #FTR EI Enter a new employee with Weekly Payment: Name, ID, Birth Date, Payment Reference, Hourly Rate, Payment Office. #DET > 15 1 low (3) low (3) average (4) 2 low (3) average (4) high (6) > 2 average (4) high (6) high (6) #FTR EO Identify number of File Types Referenced (FTR) Identify number of Data Element Type (DET) Determine complexity (à used to calculate FP count) #DET > 19 1 low (4) low (4) average (5) 2-3 low (4) average (5) high (7) > 3 average (5) high (7) high (7) IFPUG External Output Example IFPUG External Inquiry Complexity Assessment Report of all Employees containing Names and Birth Dates, sorted by age. ILF: Employee - Name - ID - Birth Date - Payment Reference 40 Years James Miller, Angela Rhodes, Years Mike Smith, FTR 2 DET Identify number of File Types Referenced (FTR) Identify number of Data Element Type (DET) Determine complexity (à used to calculate FP count) #FTR EO #DET > 19 1 low (4) low (4) average (5) 2-3 low (4) average (5) high (7) > 3 average (5) high (7) high (7) #FTR EQ #DET > 19 1 low (3) low (3) average (4) 2-3 low (3) average (4) high (6) > 3 average (4) high (6) high (6) IFPUG External Inquiry Example IFPUG FP Counting Example GUI ILF: Employee Report ILF: Department Report of all employees belonging to Department X containing Names, Birth Dates, and showing the Department Name. Files (ILF): Employee, Department 2 FTR: Employee, Department 3 DET: Name (Employee), Birth Date (Employee), Department Name (Department) Employee Name First Name Street Postal Code City Birth Date new change delete close 3 External Inputs #FTR EQ #DET > 19 1 low (3) low (3) average (4) 2-3 low (3) average (4) high (6) > 3 average (4) high (6) high (6) 1 External Inquiry (input side) External Input (new, 1 FTR, 7 DET, low) = 3 FP External Input (change, 1 FTR, 7 DET, low) = 3 FP External Input (delete, 1 FTR, 7 DET, low) = 3 FP External Inquiry (navigate, 1 FTR, 7 DET, low) = 3 FP 12 FP 17

18 FP: Advantages Summary FP vs. LOC /1 Can be counted before design or code documents exist Can be used for estimating project cost, effort, schedule early in the project life-cycle Helps with contract negotiations Is standardized (though several competing standards exist) A number of studies have attempted to relate LOC and FP metrics (Jones, 1996). The average number of source code statements per function point has been derived from case studies for numerous programming languages. Languages have been classified into different levels according to the relationship between LOC and FP. FP vs. LOC /2 Newer Data! Language Level Min Average Max Machine language Assembly C Pascal C Visual C PowerBuilder Excel Code generators Effort Estimation with FP Effort estimation based on organizationspecific data from past projects Function Points FPà MM (IBM data) 500 Person-Months IFPUG FP: Critique Summary FP is a subjective measure (à counting items, complexity weights) Requires a full software system specification But there exist light-weight alternatives à Object Point, Use Case Point Physical meaning of the basic unit of FP is unclear Difficult to apply to maintenance (enhancement) projects Not suitable for complex software, e.g., real-time and embedded applications Proposed solution: COSMIC FP / Feature Points Mark II Function Points 18

19 Function Points Mark II Developed by Charles R. Symons Reference: Software sizing and estimating - Mk II FPA, Wiley & Sons, Builds on work by Albrecht Work originally for CCTA: should be compatible with SSADM; mainly used in UK emerged in parallel to IFPUG FPs but is a simpler method Function points Mk II continued #input items For each transaction, count data items input (N i ) data items output (N #entities o) entity types accessed accessed (N e ) #output items FP count = N i * 0.58 N e * 1.66 N o * 0.26 COSMIC Function Points Function points for embedded systems Albrecht/IFPUG function points (and Mark II) were designed for information systems COSMIC FPs attempt to extend the FP concept to embedded systems Embedded software seen as: being in a particular layer in the system communicating with other layers and other components at same level COSMIC FP Layered software COSMIC FPs Receives request Makes a request for a service Higher layers Data reads/ writes Persistent storage Software component Supplies service Receives service Lower layers Peer to peer communication Peer component The following elements are counted: Entries: movement of data into software component from a user, another layer or a peer component Exits: movements of data out of software component Reads: data movement from persistent storage Writes: data movement to persistent storage Each element counts as 1 COSMIC functional size unit (Cfsu) 19

20 Software Project Management Scheduling Chapter Six Activity planning Having selected and tailored a process for doing the project identified the activities to be carried out assessed the time needed for each activity need to assign dates/times for start and end of each activity Activity networks Defining activity networks Help to: Assess the feasibility of the planned project completion date Identify when resources will need to be deployed to activities Calculate when costs will be incurred Co-ordinate activities Activity networks have the following assumptions: A project is: Composed of a number of activities May start when at least one of its activities is ready to start Completed when all its activities are completed Defining activity networks Identifying activities An activity: Must have clearly defined start and end-points Must have an estimated duration Must have estimated resource requirements these are assumed to be unchanged throughout the project May be dependent on other activities being completed first (precedence networks) Work-based approach Draw-up a Work Breakdown Structure (WBS) listing the tasks (work items) to be performed Product-based approach List the deliverable and intermediate products of project Product breakdown structure (PBS) Identify the order in which products have to be created Work out the activities needed to create the products 20

21 Hybrid approach Example Final outcome of project planning A project plan as a bar chart Activity Network Types PERT vs CPM PERT = Program Evaluation and Review Technique CPM = Critical Path Method PERT Activity A Activity B Activity D Activity C CPM Act. A Act. B Act. D Act. F Act. C Act. E Developing a PERT diagram Lagged activities No loops are allowed deal with iterations by hiding them within single activities Milestones activities, e.g., the start and end the project, indicate transition points and have duration 0. Where there is a fixed delay between activities e.g. seven days notice has to be given to users that a new release has been signed off and is to be installed Acceptance 7days Install new testing release 20 days 1day 21

22 Types of links between activities Types of links between activities Finish to start Software development Acceptance testing Start to finish Operate temporary system Start to start / Finish to finish (here with lag time) Test prototype 1 day 2 days Document Amendments Acceptance test of new system Cutover to new system Start and finish times Example Earliest start activity Latest finish Latest start Earliest finish Activity write report software Earliest start (ES) Earliest finish (EF) = ES duration Latest finish (LF) = latest task can be completed without affecting project end Latest start = LF - duration Earliest start = day 5 Latest finish = day 30 Duration = 10 days Float = LF ES Duration =? Earliest finish =? Latest start =? What is it? Example Day 0 Earliest start = day 5 Latest finish = day 30 Duration = 10 days Float = LF ES Duration = 15 Earliest finish = 15 Latest start = 20 Note that in the last example, day numbers are used rather than actual dates Makes initial calculations easier not concerned with week-ends and public holidays For finish date/times Day 1 means at the END of Day 1. For a start date/time Day 1 also means at the END of Day 1. The first activity therefore may begin at Day 0 i.e. the end of Day 0 i.e. the start of Day 1 22

23 Notation Complete for the previous example Earliest start Duration Earliest finish Earliest Start = 5 Duration = 10 Earliest Finish = 15 Activity label, activity description Write report software Latest start Float Latest finish Latest Start = 20 Float = 15 Latest Finish =30 Example of an activity network?????????? Developing the PERT diagram: Forward pass Start at beginning (Day 0) and work forward following chains. Earliest start date for the current activity = earliest finish date for the previous When there is more than one previous activity, take the latest earliest finish EF = day 7?????? ES = day10 EF = day Example of an activity network Developing the PERT diagram: Backward pass Start from the last activity Latest finish (LF) for last activity = earliest finish (EF) Work backwards Latest finish for current activity = Latest start for the following activity More than one following activity à take the earliest LS Latest start (LS) = LF for activity duration 23

24 Example of an activity network Float ? ? Float = Latest finish - Earliest start - Duration 3? ? 10 7? ? 10 11? ? 13 ES activity FLOAT LF Latest start Earliest finish Example of an activity network Critical path Critical path = the path through the activity network with zero floats Critical path: any delay in an activity on this path will delay whole project Can there be more than one critical path? Can there be no critical path? Sub-critical paths Example of an activity network Free vs. interfering float 0 7w 7 A B can be up to 3 weeks late and not affect any other activity à free float w 4w 4 B w 8 D w 12 E w A B can be another 2 weeks late à affects D but not the project s end date à interfering float 24

25 Rest of this week Next week Read textbook chapters 5 and 6 Continue interaction with ETSA01 Meet project supervisor (if not yet happened) Appointment by dietmar.pfahl@cs.lth.se Read textbook chapters 7, 8, and 9 Continue interaction with ETSA01 Finalise and submit Draft Report to dietmar.pfahl@cs.lth.se Exercise 3 No exercise 25