Presentation is loading. Please wait.

Presentation is loading. Please wait.

Stevens Institute of Technology

Similar presentations


Presentation on theme: "Stevens Institute of Technology"— Presentation transcript:

1 Stevens Institute of Technology
UNDERSTANDING and EFFECTIVELY USING FUNCTIONAL MEASUREMENT Presented By The David Consulting Group

2 PRESENTATION HIGHLIGHTS
Function Point Overview Effective Use of Function Points Establishing a Function Point Program

3 FUNCTION POINT OVERVIEW
The Need for Sizing The Function Point Methodology A Sample Count

4 CRITICAL SOFTWARE ISSUES
Understanding the Customer’s Requirements Effectively Sizing the Requirements Accurately Estimating the Deliverable Managing a Successful Delivery PROCESS

5 THE NEED FOR SIZING Quantitative (Objective) Measure
Basis for Comparison Manage Expectations (Value) Satisfies SPI Requirements

6 CHARACTERISTICS OF AN EFFECTIVE SIZING METRIC
Meaningful to developer and user Defined (industry recognized) Consistent (methodology) Easy to learn and apply Accurate, statistically based Available when needed (early) What does ISO say about sizing metrics?

7 TYPES OF SIZING METRICS
Common Sizing Metrics Lines of Code Artifacts Function Points What other metrics do we need to consider

8 MEASURING WITH LINES OF CODE
The Pros and Cons of Using SLOC Can be counted consistently within organization Available late in the life cycle Lines of code not always available No industry standard for counting lines of code Limited ability to compare among various language groups Internal use only, not meaningful to customer

9 SIZING FROM ARTIFACTS Determine size (and estimate) based on an evaluation of existing or planned artifacts Artifacts may include: Document size Number of screens, reports Programs/modules WBS

10 FUNCTION POINTS Function Point Analysis is a standardized method for measuring the functionality delivered to an end user. Consistent method Easy to learn Available early in the lifecycle Acceptable level of accuracy Meaningful internally and externally Results are normalized across different environments

11 FUNCTION POINTS IS AN EFFECTIVE SIZING METRIC
Function Point Analysis is a standardized method for measuring the functionality delivered to an end user. Function Point Counts have replaced Lines of Code counts as a sizing metric that can be used consistently and with a high degree of accuracy.

12 BENEFITS OF USING FUNCTION POINTS
A vehicle to estimate cost and resources required for software development, enhancement and maintenance A tool to quantify performance levels and to monitor progress made from software process improvement initiatives A tool to determine the benefit of an application to an organization by counting functions that specifically match requirements A tool to size or evaluate purchased application packages

13 INTERNATIONAL FUNCTION POINT USERS GROUP (IFPUG)
Purpose To promote and encourage use of Function Points To develop consistent and accurate counting guidelines Benefits Networking with other counters IFPUG Counting Practices Manual Research projects Hotline Newsletter Certification Utilization Member companies include all industry sectors Over 1200 members in more than 30 countries

14 FUNCTION POINT ANALYSIS
Definition Standard method for measuring software development from the customer’s point of view Quantifies functionality provided to the user based primarily on logical design Objectives Measure software development and maintenance independently of technology used for implementation Measure functionality that the user requests and receives

15 FUNCTION POINT ANALYSIS
- A LOGICAL VIEW Physical Lines of code or programs/modules Physical database or files Physical transactions (screens) Logical Functionality required Logical groups of user data Business processes

16 THE FUNCTION POINT METHODOLOGY
Five key components are identified based on logical user view External Inputs External Outputs External Inquiries Internal Logical Files External Interface Files External Input External Inquiry External Output Internal Logical Files External Interface File Application

17 LOGICAL VIEW OF USER REQUIREMENT
External Inquiries VENDOR SUPPLY USER USER Interface WORK CENTERS LIST OF MOLDS VENDOR INFORMATION PARTS External Output PLANT MOLDS Internal Logical Files PARTS LISTING BILL OF MATERIALS USER ORDER PARTS PLANT INFORMATION CENTER External Inputs USER CHANGE BILL

18 THE FUNCTION POINT METHODOLOGY
Each identified component is assigned a Function Point size value based upon the make-up and complexity of the data Complexity Components: Low Avg High Total Internal Logical File (ILF) __ x __ x __ x 15 ___ External Interface File (EIF) __ x __ x __ x 10 ___ 1 3 External Input (EI) __ x __ x __ x 6 ___ External Output (EO) __ x __ x __ x 7 ___ External Inquiry (EQ) __ x __ x __ x 6 ___ 3 Total Unadjusted FPs ___ Record Element Types Data Elements (# of unique data fields) or File Types Referenced Data Relationships Low Low Average Low Average High Average High High

19 THE FUNCTION POINT METHODOLOGY
14 General Systems Characteristics are evaluated and used to compute a Value Adjustment Factor (VAF) General System Characteristics Data Communication On-Line Update Distributed Data Processing Complex Processing Performance Objectives Reusability Heavily Used Configuration Conversion & Install Ease Transaction Rate Operational Ease On-Line Data Entry Multiple-Site Use End-User Efficiency Facilitate Change The final calculation is based upon the Unadjusted FP count X VAF

20 WHEN TO COUNT FUNCTION POINTS
PROPOSAL REQUIREMENTS DESIGN CONSTRUCTION TESTING DELIVERY CORRECTIVE MAINTENANCE Initial User Requirements Scope Adjustment Feasibility Study Change Request SIZING SIZING Initial Technical Requirements SIZING SIZING Final Functional Requirements SIZING

21 BASIC COUNTING PROCESS
Determine the type of function point count Identify the boundary for counting Count the data function types Count the transactional function types Determine the Function Point count

22 IDENTIFY THE BOUNDARY FOR COUNTING
Definition: Indicates the border between the project or application being measured and external applications or user domain Functionality: What Does a User See? Data going into an application -- inputs Data coming out of an application -- outputs, inquiries Data, inside or outside an application -- logical files Application Inputs Outputs Data References/Feeds Data

23 DEFINITION OF AN INPUT An External Input (EI) processes data that comes from outside the application’s boundary. External Input 1.0 ON-LINE UPDATE CUSTOMER INFORMATION ENTRY Transaction Multi-Screen CUSTOMER INFO FILE

24 DEFINITION OF AN OUTPUT
An External Output (EO) generates data that is sent outside the application boundary. CUSTOMER INFO FILE External Output 1.0 END USER Summary SUMMARIZE CUSTOMER INFO

25 DEFINITION OF AN INQUIRY
An External Inquiry (EQ) is an output that results in data retrieval. The result contains no derived data. CUSTOMER INFO FILE External Inquiry DISPLAY CUSTOMER INFO 1.0 END USER Selected Customer Info

26 DEFINITION OF A FILE An Internal Logical File (ILF) is a user-identifiable group of logically related data that is maintained within the boundary of the application. END USER 1.0 UPDATE CUSTOMER INFO Customer Info Updated Customer Info CUSTOMER INFO FILE Internal Logical File

27 DEFINITION OF A INTERFACE FILE
An External Interface File (EIF) is a user-identifiable group of data referenced by the application, but maintained within the boundary of another application. External Interface File ZIP CODE TABLE VALID ZIP CODES 1.0 VALIDATE ZIP CODE & UPDATE CUSTOMER INFO UPDATES UPDATES END USER CUSTOMER INFO FILE

28 DETERMINE THE FUNCTION POINT COUNT
COMPONENTS ARE ASSESSED BASED UPON COMPLEXITY: Data Element Types (Fields or Attributes) File Types Referenced (ILFs or EIFs) Record Element Types (Data Sub-Groups) Complexity Components: Low Avg. High Total Internal Logical File (ILF) X X X External Interface File (EIF) X X 7 X External Input (EI) X 3 X X External Output (EO) X 4 X 5 X External Inquiry (EQ) X X 4 X 59 Function Point Count

29 AN EXERCISE IN COUNTING
External Input Inquiry Output Internal Logical Files Interface File Application

30 USEFUL PROJECT/APPLICATION DOCUMENTATION
High Level System Diagrams Logical Data/Process Models Entity Relationship Models Design Specifications Requirements Functional Specifications Detailed Design Layouts of Files and Databases On-Line Screen Prints User Manuals

31 LOGICAL VIEW OF USER REQUIREMENT
ADD, CHG INVOICES PAYMENTS VENDOR ACCOUNTS PAYABLE PAYMENT STATUS PAID INVOICES PURCHASE ORDER INFO PURCHASE ORDER SYSTEM

32 APPLICATION BOUNDARY Definition:
Indicates the border between the project or application being measured and external applications or user domain USER ADD, CHG INVOICES PAYMENTS VENDOR ACCOUNTS PAYABLE PAYMENT STATUS PAID INVOICES PURCHASE ORDER INFO PURCHASE ORDER SYSTEM External Interface File External Inputs External Input External Inquiry External Output Internal Logical Files

33 DETERMINE THE FUNCTION
POINT COUNT COMPONENTS ARE ASSESSED BASED UPON COMPLEXITY: Data Element Types (Fields or Attributes) File Types Referenced (ILFs or EIFs) Record Element Types (Data Sub-Groups) Complexity Components: Low Avg. High Total Internal Logical File (ILF) X X X External Interface File (EIF) X X 7 X External Input (EI) X X X External Output (EO) X X 5 X External Inquiry (EQ) X X 4 X 58 Function Point Count

34 COMMON CRITICISMS WITH FUNCTION POINTS
FP methodology terms are confusing Too long to learn, need an expert Need too much detailed data Does not reflect the complexity of the application “I did more work than I am getting credit for” Does not fit with new technologies Takes too much time We tried it before

35 EFFECTIVE USE OF FUNCTION POINTS
Requirements Management Estimating Benchmark Comparisons Managing Change

36 MANAGING REQUIREMENTS
Functionality requested by the user may be organized into logical parts that match the five function point components USER ADD, CHG INVOICES PAYMENTS VENDOR ACCOUNTS PAYABLE PAYMENT STATUS PAID INVOICES PURCHASE ORDER INFO PURCHASE ORDER SYSTEM External Interface File External Inputs External Input External Inquiry External Output Internal Logical Files

37 ESTIMATING MODEL ESTIMATE DEFINITION CAPABILITY PROJECT SIZE X RISK
FACTORS COMPLEXITY REQUIREMENT Schedule Costs Effort SLOC Artifacts FUNCTION POINTS

38 COMPLEXITY FACTORS Estimates are influenced by size and other factors such as complexity variables noted below: Logical and mathematical algorithms Code structure Data relationships Reuse Memory Security Warranty

39 RISK FACTORS Estimates will also vary based upon a variety of
Technology Applied such as tools, languages, reuse, platforms Process/Methodology including tasks performed, reviews, testing, object oriented Customer/User and Developer skills, knowledge, experience Environment including locations, office space System Type such as information systems; control systems, telecom, real-time, client server, scientific, knowledge-based, web Industry such as automotive, banking, financial, insurance, retail, telecommunications

40 ESTIMATING MODEL ESTIMATE DEFINITION CAPABILITY PROJECT SIZE PROJECT
COMPLEXITY RISK FACTORS REQUIREMENT X X Schedule Costs Effort PROFILE Data Relationships Code Structure Algorithmic Compl. Performance etc. Technology Skill Levels SQA Project Management etc.

41 QUALITATIVE ASSESSMENT
MEASURE ASSESS Environment Definition Design Build Test Management Size Effort Duration Defects Performance Productivity Capability Profiles Software Excellence

42 DEVELOPING A BASELINE OF DATA
Product Deliverable Performance Indicators Risk Factors Management Definition Design Build Test Environment D D C Time to Deliver - Duration - Number of days B A PRODUCTIVITY MEASURES SIZE PROFILES A 136 10 mnths B 276 11 mnths PROFICIENCIES C 10 mnths 435 INADEQUACIES D 26 mnths 558 32 mnths : 759

43 ESTABLISHING A BASELINE
Performance Productivity Size is expressed in terms of functionality delivered to the user Rate of Delivery Function Points per Person Month 200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 Software Size A representative selection of projects is measured Organizational Baseline Rate of delivery is a measure of productivity

44 MONITORING IMPROVEMENTS
Track Progress Rate of Delivery Function Points per Person Month 200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 Software Size Year 2 grouping of projects

45 Industry Baseline Performance
COMPARISONS TO INDUSTRY Industry Baseline Performance 2200 2000 1800 1600 Software Size 1400 1200 1000 800 600 400 200 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 Rate of Delivery Function Points per Person Month

46 ESTIMATING USING DELIVERY RATES
DEFINITION CAPABILITY ESTIMATES – Effort PROJECT SIZE PROJECT COMPLEXITY DELIVERY RATE = Function Points Profiles

47 ESTIMATING BEST PRACTICES
The Software Engineering Institute (SEI) requirements for good estimating: Corporate historical database Structured processes for estimating product size and reuse Mechanisms for extrapolating benchmark characteristics of past projects Audit trails Integrity in dealing with dictated costs and schedules Data collection and feedback processes foster correct data interpretation

48 ESTIMATING PROCESS The estimate is based on
the best available information. A poor requirements document will result in a poor estimate Profile Size Time REQUIREMENT Analyst ESTABLISH PROFILE GENERATE ESTIMATE WHAT IF ANALYSIS ACTUALS SIZE REQUIREMENT SELECT MATCHING PROFILE Project Manager Counter Software PM / User Metrics DataBase Plan vs. Actual Report Accurate estimating is a function of using historical data with an effective estimating process.

49 CHANGE OF SCOPE MANAGEMENT
Initial Interim Estimate Estimate Estimate Variance Function Points Effort (months) Schedule (months) Staffing Levels (FTE) Production Rate (FP/mo)

50 Change of Scope Summary
COMMUNICATING CHANGES IN SCOPE Function Point Change of Scope Summary Change of Scope Inputs Outputs Inquiries Files Interfaces Total Add vendor function Graphical display Banking System Mandatory Changes Total

51 COMMUNICATING IMPACT AND OPTIONS
Additional Additional Additional FP Effort Cost Schedule Change in Scope Count (staff mo.) ($000)___ (calend. mo.) Add Vendor Function Graphical Displays Banking System Mandatory Changes Total $ mos. OPTIONS 1. Increase funding level and schedule 2. Reduce functionality, or do not accept change 3. Trade off quality and maintenance costs for schedule 4. Delay delivery of change

52 FUNCTION POINT PROGRAM
Organizational Needs Benchmark Performance Measurement Selection Roadblocks

53 A SUCCESSFUL SOFTWARE MEASUREMENT PROGRAM
FOCUS ON BUSINESS NEEDS ESTABLISH PERFORMANCE LEVELS PLAN WHAT TO MEASURE DEFINE A MEASUREMENT PROCESS BUILD A STRONG INFRASTRUCTURE AUTOMATE

54 BUSINESS NEEDS: SELECTION CRITERIA FOR MEASUREMENT
Align with business needs and the needs of the development organization Select only a few metrics to implement initially Create measures that are realistic and measurable Use industry standard metrics to facilitate comparisons Allow metrics to change and evolve as the organization matures

55 FOCUS ON BUSINESS NEEDS
Use of Goal-Question-Metric paradigm helps to identify the “right” measures Goal: Ensure that the correct goals are identified in support of the organization’s business drivers Question: Validated goals through a series of questions that ensure that the data collected will effectively measure the strategic goals Metric: The result is a metrics positioning statement which describes how the identified metrics support strategic business goals

56 DETERMINE ORGANIZATION OBJECTIVES FOR EACH GOAL
Example of using the Goal-Question-Metric paradigm Goal Improve application development productivity Questions Do we have a methodology for tracking productivity? Do we want to collect data on new and/or enhancement projects? Do we have time tracking capabilities? Metric By tracking the hours throughout the life cycle of a project, we can use the productivity rate metric to determine if we are meeting our goal

57 BASELINE CURRENT LEVELS OF PERFORMANCE
What is baselining? A process involving the collection, analysis and reporting of performance data A performance baseline will: Establish a "stake in the ground" from which improvement programs can be identified Display qualitative data regarding the effectiveness of the techniques and methods currently being used Permit the measurement of the impact of new tools, techniques and methods SSB Baseline Levels of performance were established for productivity, work effort, duration and staffing levels

58 BASELINE CURRENT LEVELS OF PERFORMANCE
PRODUCTIVITY CAPABILITIES SOFTWARE PROCESS IMPROVEMENT TIME TO MARKET EFFORT DEFECTS MANAGEMENT SKILL LEVELS PROCESS TECHNOLOGY IMPROVEMENT INITIATIVES / BEST PRACTICES RISKS MEASURED BASELINE 0.00 5.00 10.00 15.00 20.00 25.00 30.00 35.00 100 200 400 800 1600 3200 6400 Sub Performance Best Practices Industry Averages Organization Baseline

59 PLAN WHAT TO MEASURE Customer based metrics-- impact, value added
Delivery metrics – responsiveness, quality Project metrics – effort, cost, duration Demand metrics -- backlog, type of work

60 IMPACT MEASURES +22% 0% 18% +21% $938 $613 $800 32 49 40 20% 10% 15% 4
Measure Name Calculation Notes Example Median Industry Median) primarily Level 3 organizations Goal by 2003 Estimating Accuracy - Effort (actual labor hours - estimated) / estimated positive values represent overruns; negative underruns ( )/500 = +100% overrun +22% 0% 18% - Schedule (actual calendar months - (4 - 3)/3 = +33% overrun +21% Unit Cost dollars / function points Dollars are estimated from labor $110 per hour * 145 hrs per staff month $200,000/100 = $2,000 $938 $613 $800 System Delivery Rate function points / calendar months QSM value is a mean - median not available 100 FPs/ 2 calendar months = 50 32 49 40 Requirements Volatility added, changed, deleted / total baselined rqts For all but one project, data not available. Project manager gave an estimate 10 changed / 100 baselined = 10% 20% 10% 15% Client Satisfaction ratings by project manager For all but three projects, ratings by clients unavailable. 5 = very satisfied 1 = very unsatisfied 4 Not available System Test Effectiveness defects found in system test / total defects total defects = defects found in system test + defects found in production (first 30 days) 40 / 50 = 90% 83% 90% Delivered Defect Density (Defects per 100 function points) (defects found in production / function points) * 100 production = first 30 days (5 defects / 200 FPs) * 100 = 2.5 2.3 1.3 1.8 20 100 FPs/4 staff months = 25 17 26 Productivity function points / labor months varies with project size

61 MEASUREMENT MATURITY Level 1 Level 2 Level 3 Measures: Purpose:
Business Metrics Customer Metrics Technology Metrics Project Focused Customer Focused Business Focused IT Efficiency Organizational Impact Business Impact Cost Reduction Increased Profitability Revenue Generation Process Improvement Customer Satisfaction Time to Market Size and Complexity Portfolio Management Defect Tracking Effort/Cost Plan vs. Actual Production Problems Operational

62 Recognizing And Overcoming Roadblocks, Challenges And Hurdles
In order for your metrics program to not only survive, but flourish, adhere to the following: Always have management and executive support Choose your metrics personnel carefully, making sure that: They will be enthusiastic supporters of the program They have the determination to see the program succeed They have the tenacity to keep pursuing individuals and project teams who are not cooperative Properly set and manage expectations Takes six months to begin collecting data, takes six more months to have data accuracy

63 Recognizing And Overcoming Roadblocks, Challenges And Hurdles
Be consistent and persistent Make sure that everyone understands that this is not just “the flavor of the month” and that the metrics program is there to stay Educate! Personnel includes executives, management, project leaders and the project team Subjects include function points and metrics Share success Communicate success stories to everyone in the organization

64 Recognizing And Overcoming Roadblocks, Challenges And Hurdles
Most Important… Participants need to know what’s in it for them Project team members need to be shown how the correct utilization of metrics can help them institute processes that will go a long way in creating projects that are “better, cheaper, faster” This in turn can translate into project team recognition and rewards

65 INFRASTRUCTURE ORGANIZATIONAL ISSUES
Organizing for a Successful Function Point Program Centralization vs Decentralized Function Point counting is provided as a service vs. everyone (Project Managers) does the counting Policy and Procedures Policies define what gets counted (type, size) Procedures define how it gets counted (guidelines, lifecycle) Determine what gets counted Responsibility Who in the organization is involved in counting and what level of expertise do they require Certification Function Point Certification (CFPS) - IFPUG.org Tools Counter, DDB Software Function Point Workbench, Charismatek


Download ppt "Stevens Institute of Technology"

Similar presentations


Ads by Google