Software Size Matters

OSMmsa behind e Intelligensofftware Projects The SOFTWARE SIZE MATTERS WHY DO WE CARE ABOUT SOFTWARE SIZE? Size is one of the 5 core metrics behind software estimation - Ignorance of size leads to bad what are the other four? estimates. Without software size, it's hard to estimate: How long a software project will take How much it will cost How many people we'll need How many defects we can expect to find during testing How productive we are likely to be WHY? Because there's a non-linear relationship between size and schedule, effort (cost), and defects. ESTIMATING SIZE IS EASY, RIGHT? Unfortunately, no. WHAT DO WE MEAN BY "SIZE" ANYWAY? There are two main types of software sizing: Estimators need to use different sizing methods, depending on where the project is in its life cycle, and what information is available. functional size and technical size. FUNCTIONAL SIZE is the amount of software functionality software logic TECHNICAL SIZE is the amount of Broadly, we can divide the software lifecycle into four stages: delivered to the end that creates the 3 user. functionality. WHAT HOW DO DEPLOY/FIX If we were building a house, those phases might correspond to: Physically building the Drawing an Creating detailed blueprints Handing over keys and warranty period initial sketch structure End users only care Developers care about TECHNI CAL SIZE - how many logical source lines of code about At each stage, we're able to estimate size in new ways, and with greater clarity - sometimes referred as "PROGRESSI VE ELABORATION." or configurations are required. BUT HERE'S THE TRICK: Since we'll be using different sizing methods together, we'll need a way to normalize or convert to a common measurement unit. This is important because it allows broad comparisons across different technologies, projects, industries and organizations. For FUNCTIONAL SIZE, we can convert all our measurements into base units called FUNCTION POINTS. (The International Function Point Users Group (IFPUG) method is the most widely used ISO standard for functional sizing.) For TECHNICAL SI ZE, we can convert all our measurements into base units called IMPLEMENTATION UNITS. An IU is equivalent to writing one source line of code or one technical step in configuring a commercial package (COTS) package. FUNCTION POINTS can be converted to IMPLEMENTATION UNITS using QSM's Function Point Languages Table: www.qsm.com/function-point-table. 970,000 Us LARGE 16,800 FPS 211,000 Us MEDIUM 3,700 FPs WHAT'S IN A NA ME? Individual methodologies have their own names for the four basic stages: 6,500 Us SMAIL 110 FPs METHOD OLOGY WHAT HOW DEPLOY/FIX Rqmts. & Design Construct & WATERF ALL Concept Deploy Test RUP Initiation Elaboration Construction Transition Iteration Iteration AGILE Initiation Production Planning Development Project Preparation SAP ASAP Business Realization & Go Live Blueprint Final Prep WHAT ARE THE MOST COMMON SIZING METHODS? 曾 首 首 首 E Order of magnitude size (T-shirt sizing) Ranges (XS to XXL) can scale with sizes of completed projects (industry or corporate). FUNCTIONAL SIZE (normalized to FUNCTION POINTS, then to IMPLEMENTATION UNITS) FUNCTIONAL Testable "shall statements" that describe the intended REQUIREMENTS functions of software; often maintained in a Requirements (A.K.A. FUNCTIONAL CAPABILITIES) traditional software development. Traceability Matrix (RTM) spreadsheet or database tool; requires a consistent definition; most often used in A higher level of abstraction that comprises multiple BIUSINESS functional requirements; can be used for ballpark estimates, REQUIREMENTS assuming a given number of functional requirements per business requirement; most often used in traditional software development. Placeholders for future conversations between developers and customers; equates to one scenario (i.e., thread of U SER STORIES functionality) in the software that will satisfy a user goal; requires a consistent definition; most often associated with Agile projects. Containers of multiple scenarios (i.e., user stories) that describe the interactions between a human (or external USE CASES System) and a software system to achieve a common user goal; can be used for ballpark estimates, but requires a consistent definition; commonly associated with both traditional and Agile projects. FUNCTION POINTS (ISO STANDARDS: More robust but time consuming methods for measuring IFPUG, MARK-II, functional size; can be estimated using shortcuts early, but COSMIC, FISMA. can only be counted after requirements are established. NESMA) < 011011011010 TECHNICAL SIZE (normalized to IMPLEMENTATION UNITS) 010110110111 1101110110110 Counts the number of high-level and detailed business RICE OBJECTS AND process configurations in a COTS package; customizations BUSINESS PROCESS of the package are sized by counting the number of reports, CONFIGURATIONS interfaces, conversions and enhancements; requires consistent definitions for each component. TECHNICAL Counts screens, reports, forms, tables, modules, etc.; COMPONENTS requires consistent definitions for each component. A ballpark estimate of the number of Source Lines of Code SOURCE CODE FILES (SLOC), assuming an average number of SLOC per source code file The number of logical source statements delivered to the SLOC COUNTS customer, specific to the type of project and programming language; only measurable after coding. 0101 1001 NOW LET'S LOOK AT THE WHOLE PROCESS (Notice what happens to our uncertainty) PHASE WHAT HOW DO DEPLOY/FIX METHOD(S) Order of Magnitude Functional Requirements, Functional Requirements, Business Requirements, User Stories, Use Cases, ISO Standards, RICE Objects, Technical Components, Source Code Files, SLOC Count Functional Requirements, (T-shirt sizing) Business Requirements, User Stories, Use Cases, ISO Standards Business Requirements, User Stories, Use Cases, ISO Standards, RICE Objects, Technical Components, Source Code Files, SLOC Count ТУРЕ High-level requirements Refined requirements Physical measurements Refined physical measurements UNCE RTA INTY: HIGH UNCERTAINTY: MEDIUM UNCERTAINTY: LOW UNCERTAINTY: LOWEST FOR MORE INFORMATION ON SIZING FROM THE SIZING AND ESTIMATION EXPERTS AT QSM DOWNLOAD THE QSM SOFTWARE ALMANAC wWW.QSM.COM/2014-ALMANAC www.qsm.com EST IMATION VS. VARIABILITY OVER TIME SCHEDULE (DURATION) EFFORT (COST) QUALITY (DEFECTS) PRODUCTIVITY SIZE (SCOPE) (HOW) (DO) (DEPLOY/FIX) (XIH/ A0130) (00)