VARIATIONS IN SOFTWARE DEVELOPMENT PATTERNS. June 24, 2013 Draft 3.0

Transcription

1 VARIATIONS IN SOFTWARE DEVELOPMENT PATTERNS June 24, 2013 Draft 3.0 Keywords Activity-based costs, Capers Jones data, function points, Namcook Analytics data, software costs, software development, software methodologies, software occupations, pattern matching, Abstract Software projects of various sizes and types use different patterns of development. These patterns are useful for both benchmark data collections and also for predicting the results of new applications before they start. Some of the factors that influence software patterns include the size of the application, its class, its type, and even the country in which the application will be built. This paper illustrates six different patterns for software projects whose size ranges between 1 and 100,000 function points. It also illustrates six different patterns used for systems software, embedded software, commercial software, and other classes. In total there are some 122 factors that influence software patterns. With 122 total elements the combinations of software patterns total to 214,200,000. Capers Jones, CTO and Vice President Namcook Analytics LLC Web Capers.Jones3@gmail.com Copyright 2013 by Capers Jones. All Rights Reserved.

2 INTRODUCTION Software development is not a one size fits all kind of activity. Small projects of 10 function points or 500 lines of code are not built the same way as large systems of 10,000 function points or 500,000 lines of code. Military software projects are not built the same way as civilian software projects. Namcook Analytics LLC has developed a sizing and estimating method based on pattern matching. The method uses 122 factors and the total number of patterns is 214,200,000. There is also a set of algorithms for sizing and estimating applications which might be unique. Two of the more interesting factors used in pattern matching are application size and application type, which are discussed in this report. Variations in Software Development Patterns by Size of the Application Software development has many patterns based on application size and application type. These patterns involve occupation groups, methods of quality control, and other key factors that affect software project outcomes. Pattern matching is an important emerging technology. In many industries building large products is not the same as building small products. Consider the differences in specialization and methods required to build a rowboat versus building an 80,000 ton cruise ship. A rowboat can be constructed by a single individual using only hand tools. But a large modern cruise ship requires more than 500 workers including many specialists such a pipe fitters, electricians, steel workers, painters, and even interior decorators. Software follows a similar pattern: Building a small application of 10 function points can be done by a single software engineer with little or no help. Building large system in the 10,000 to 100,000 function point range is more or less equivalent to building other large structures such as ships, office buildings, or bridges. Many kinds of specialists are utilized and the development activities are quite extensive compared to smaller applications. Table 1 illustrates the variations in development activities noted for the six size plateaus using the author s 25-activity chart of account for software development projects:

3 Table 1: Development Activities for Six Project Size Plateaus ,000 Function Function Function Function Function n P o i n t s Activities Performed Point Points Points Points Points 01 Requirements X X X X X X 02 Prototyping X X X 03 Architecture X X 04 Project plans X X X 05 Initial design X X X X X 06 Detail design X X X X 07 Design reviews X X 08 Coding X X X X X X 09 Reuse acquisition X X X X X X 10 Package purchase X X 11 Code inspections X X X 12 Ind. Verif. & Valid. 13 Change control X X X 14 Formal integration X X X 15 User documentation X X X X 16 Unit testing X X X X X X 17 Function testing X X X X 18 Integration testing X X X 19 System testing X X X 20 Beta testing X X 21 Acceptance testing X X X 22 Independent testing 1 0 0, F u n c t i o

4 23 Quality assurance X 24 Installation/training X X X 25 Project management X X X X Activities Below the plateau of 1000 function points (roughly equivalent to 50,000 source code statements in a mid-level language such as Java or C#) less than half of the 25 activities are normally performed. But large systems in the 10,000 to 100,000 function point range perform more than 20 of these activities. Since all of these 25 activities have time and costs associated with them, variations in software development patterns is one of the reasons why large systems cost more than small applications.

5 The Impact of Size Patterns on Software Costs Knowing patterns associated with application size is key topic for both software estimation and measurement. Assuming a flat rate of $7,500 per staff month the approximate costs per function points for applications by size for a general IT application would be: Size in Function Points $ per Function Point 1 $ $ $550 1,000 $850 10,000 $1, ,000 $2,500 Not only are the activities different from size range to size range but the work content differs too. For example for a small application of 100 function points only requirements, design, and a user manual might be produced in terms of paper documents. For a large system of 10,000 function points more than 50 documents will be produced including requirements, architecture, initial and detailed design, formal test plans, development plans, tutorial materials, and many more. Variations in Software Development Patterns by Type of Software The second factor that exerts an influence on software development activities is the type of software being constructed. For example, the methods utilized for building military software is very different from civilian norms. The systems and commercial software domains also have fairly complex development activities compared to management information systems. The outsource domain, due to contractual implications, also uses a fairly extensive set of development activities. Table 2 illustrates the differences in development activities that the author has noted across the six types of software:

6 Table 2: Development Activities for Six Project Types Activities Performed Web MIS Outsource Commercial Systems Mili tary 01 Requirements X X X X X 02 Prototyping X X X X X X 03 Architecture X X X X 04 Project plans X X X X X 05 Initial design X X X X X 06 Detail design X X X X X 07 Design reviews X X X X 08 Coding X X X X X X 09 Reuse acquisition X X X X X X 10 Package purchase X X X X X X 11 Code inspections X X X X 12 Ind. Verif. & Valid. X 13 Change control X X X X X 14 Formal integration X X X X X 15 User documentation X X X X X 16 Unit testing X X X X X X 17 Function testing X X X X X 18 Integration testing X X X X X 19 System testing X X X X X X 20 Beta testing X X X 21 Acceptance testing X X X X X 22 Independent testing X 23 Quality assurance X X X X 24 Installation/training X X X X X 25 Project management X X X X X Activities As can be seen from, the activities for outsourced, commercial, systems, and military software are somewhat more numerous than for MIS projects where development processes tend to be rudimentary in many cases. Here too this is a partial explanation for why systems software takes longer and is more expensive than a web project of the same size and complexity level.

7 The Impact of Type Patterns on Software Costs Knowing patterns associated with application types is also key topic for both software estimation and measurement. Assuming a flat rate of $7,500 per staff month and a fixed size of 1000 function points the approximate costs per function point for applications by type would be: Application Types $ per Function Point Web $700 MIS $850 Outsource (offshore) $675 Outsource (domestic) $800 Commercial $1,100 Systems $1,300 Military $2,000 Not only are the activities different by type but there are other significant differences too. U.S. Department of Defense standards cause military software projects to create about three times as many paper documents as civilian projects of the same size and complexity level. In fact for defense software the costs of paper documents is higher than the cost of source code. For MIS and web projects, and especially those developed under the Agile method, paperwork costs are less than 10% of total software development. The important point is that patterns are a key factor for both benchmarks and estimates.

8 Patterns of Software Occupation Groups Not only are there different activities carried out for different patterns, but there are also important differences in the kinds of specialists and software occupations. In total in 2013 software employs about 116 different occupations. Some large systems such as IBM s and Microsoft s operating system, ERP packages, and large telecom switching systems employ as many as 50 occupations. Table 3 illustrates some of the more common occupation patterns by software application size. Table 3: Software Occupation Groups For Six Size Plateaus , ,000 Function Function Function Function Function Function Occupation Groups Point Point Point Point Point Point 1 Architects X X 2 Configuration control X X X X 3 Cost analysis X X 4 Cost estimating X X 5 Customer support X X 6 Data administration X X 7 Data base design X X 8 Data quality X X 9 Education/training X X 10 Function point analysis X 11 Globalization X 12 Graphics X X 13 Human factors X 14 Integration X X X 15 Librarians X X X X 16 Metrics/measures X 17 Networks X X 18 Performance analysis X 19 Programming X X X X X X 20 Project management X X X 21 Project planning X X 22 Quality assurance X X X 23 Reliability X 24 Reusability X 25 Security X 26 Software engineering X 27 Standards X X 28 Systems analysis X X 29 Technical writers X X X 30 Testing X X Occupation Groups

9 Both software benchmarks and software cost estimates should include the contributions of all software occupations; not just coding or software engineering. One of the standard features of Software Risk Master (SRM) is both measurement and prediction of software occupations. Because all of these occupations may have individual compensation ranges, it is quite challenging to calculate the costs of large systems when 30 or more occupations are working on 25 or more activities. To simplify cost estimates it is also possible to use the average or aggregated costs for the entire set of occupation groups. Patterns Associated with Software Methodologies There are many different software methodologies in 2013 and they do not all use the same patterns of software development. For example agile applications are famous for dividing projects into sprints and using daily scrum sessions. Other methodologies such as team software process (TSP) are more linear and include frequent inspections. For the 34 methodologies supported by Software Risk Master (SRM) more than 75 different development patterns have been observed. For example every method is different for large and small projects. Every method has different patterns for new projects and for enhancements. Every method has different patterns when used on civilian or military projects. There are too many methodology variations to illustrate all of them here, but the 34 methods supported by SRM for measurements and estimation are shown in table 4: Table 4: Thirty Four Software Methodologies 1 Mashup 2 Hybrid IntegraN 3 ova 4 TSP/PSP 5 Microsoft Solutions Framework 6 RUP 7 XP Agile/Sc 8 rum Data state 9 design 10 T-VEC Informat ion engineer 11 ing (IE) Object 12 Oriented 13 EVO

10 14 RAD 15 Jackson 16 SADT 17 Spiral 18 SSADM Open 19 source Flow 20 based 21 Iterative Crystal develop 22 ment 23 V-Model 24 Prince2 25 Merise 26 DSDM Clean 27 room 28 ISO/IEC 29 Waterfall Pair program 30 ming DoD Proofs of correctn 32 ess 33 Cowboy 34 None Here too pattern matching is useful for sizing, measurements, benchmarks, and estimation of future projects using patterns from historical projects. In order to produce useful accurate estimates it is necessary to know the set of project patterns associated with its nature, its size, its class, its type, and the occupation groups that will be working on the project. This is why pattern matching from historical projects is useful for estimating future projects. A Taxonomy of Software Application Patterns Software size and software type are only two of the topics that form important patterns for software projects. The taxonomy for pattern matching developed by Namcook Analytics LLC for measuring and estimating software projects includes: 1. Project nature (new, enhancement, maintenance, etc.)

11 2. Project scope (1 to > 100,000 function points) 3. Project class (internal use, marketing, SaaS, etc.) 4. Project type (systems, embedded, web, military, etc.) 5. Problem complexity (difficulty of the algorithms) 6. Code complexity (cyclomatic complexity) 7. Data complexity (size and interconnections of data files) These factors are evaluated by means of multiple-choice questions used for application sizing. There are 122 total factors and the combinations yield a total of 214,200,000 combined patterns. Many of these patterns are not likely to occur. A nucleus of about 20,000 patterns is common for the software projects used by most industries to date. Many other factors are also important for understanding software costs, schedules, and other quantified data. Some of these additional topics include but are not limited to: 1. Programming language or combination of languages 2. Methodology used (Agile, RUP, TSP, waterfall, etc.) 3. Volume of reusable materials available 4. Use of pre-test static analysis and inspections 5. Test stages and test methods (automated, manual, etc.) 6. CMMI level of the organization 7. Country where the software will be developed 8. Client experience 9. Project management experience 10. Development team experience 11. Test team experience 12. Maintenance team experience As an example of why these other topics are important, the nominal work week in the United States is 40 hours; in Japan it is 44 hours; in Canada it is 36 hours. The same application developed in Japan would have a shorter schedule than in either the U.S. or Canada due to the longer work week in Japan. All of these other factors form larger patterns that explain software quality, software costs, and software schedules. SUMMARY AND CONCLUSIONS Software patterns are useful for understanding requirements, for improving designs of software applications, and for both benchmark data collections of historical data and for estimation of future software projects. A weakness of software engineering to date has been a need to expand the numbers of patterns that are available for both technical engineering and also for software estimation. Pattern

12 matching is a powerful technology with great promise for improving software development, maintenance, quality, benchmarks, and estimation.

13 ADDITIONAL INFORMATION ON SOFTWARE PATTERNS For additional information on software patterns and the effect that they have on software development and maintenance, refer to the following books by Capers Jones: Jones, Capers and Bonsignour, Olivier; The Economics of Software Quality; Addison Wesley Longman, Boston, MA; ISBN 10: ; 2011; 585 pages. Jones, Capers; Software Engineering Best Practices; McGraw Hill, New York, NY; ISBN ; 2010; 660 pages. (Being translated into Chinese by IBM China.) Jones, Capers; Applied Software Measurement; McGraw Hill, New York, NY; ISBN ; 2008; 662 pages. (Available in English, Japanese, and Chinese editions) Jones, Capers; Estimating Software Costs; McGraw Hill, New York, NY; 2007; ISBN-13: (Available in English and Japanese editions) Jones, Capers; Software Assessments, Benchmarks, and Best Practices; Addison Wesley Longman, Boston, MA; ISBN ; 2000; 657 pages. BOOKS BY ADDITIONAL AUTHORS Boehm, Barry Dr.; Software Engineering Economics; Prentice Hall, Englewood Cliffs, NJ; 1981; 900 pages. Booch Grady, Object Solutions: Managing the Object-Oriented Project; Addison Wesley, Reading, MA; Capability Maturity Model Integration; Version 1.1; Software Engineering Institute; Carnegie-Mellon Univ.; Pittsburgh, PA; March 2003; Brooks, Fred: The Mythical Man-Month, Addison-Wesley, Reading, Mass., 1974, rev Charette, Bob; Software Engineering Risk Analysis and Management; McGraw Hill, New York, NY; Charette, Bob; Application Strategies for Risk Management; McGraw Hill, New York, NY; Cohn, Mike; Agile Estimating and Planning; Prentice Hall PTR, Englewood Cliffs, NJ; 2005; ISBN DeMarco, Tom; Controlling Software Projects; Yourdon Press, New York; 1982; ISBN ; 284 pages. Ewusi-Mensah, Kweku; Software Development Failures; MIT Press, Cambridge, MA; 2003; ISBN pages. Gack, Gary; Managing the Black Hole The Executives Guide to Project Risk; The Business Expert Publisher; Thomson, GA; 2010; ISBSG10: Galorath, Dan; Software Sizing, Estimating, and Risk Management: When Performance is Measured Performance Improves; Auerbach Publishing, Philadelphia; 2006; ISBN 10: ; 576 pages. Garmus, David & Herron, David; Measuring the Software Process: A Practical Guide to Functional Measurement; Prentice Hall, Englewood Cliffs, NJ; 1995.

14 Garmus, David and Herron, David; Function Point Analysis Measurement Practices for Successful Software Projects; Addison Wesley Longman, Boston, MA; 2001; ISBN ;363 pages. Glass, R.L.; Software Runaways: Lessons Learned from Massive Software Project Failures; Prentice Hall, Englewood Cliffs; Hill, Peter R. Practical Software Project Estimation; McGraw Hill, 2010 Harris, Michaael; Herron, David; and Iwanicki, Stacia; The Business Value of IT: Managing Risks, Optimizing Performance, and Measuring Results; CRC Press (Auerbach), Boca Raton, FL: ISBN 13: ; 2008; 266 pages. Humphrey, Watts; Managing the Software Process; Addison Wesley, Reading, MA; IFPUG Counting Practices Manual, Release 4, International Function Point Users Group, Westerville, OH; April 1995; 83 pages. International Function Point Users Group (IFPUG); IT Measurement Practical Advice from the Experts; Addison Wesley Longman, Boston, MA; 2002; ISBN X; 759 pages. Johnson, James et al; The Chaos Report; The Standish Group, West Yarmouth, MA; Park, Robert E. et al; Software Cost and Schedule Estimating - A Process Improvement Initiative; Technical Report CMU/SEI 94-SR-03; Software Engineering Institute, Pittsburgh, PA; May Park, Robert E. et al; Checklists and Criteria for Evaluating the Costs and Schedule Estimating Capabilities of Software Organizations; Technical Report CMU/SEI 95-SR-005; Software Engineering Institute, Pittsburgh, PA; January McConnell; Software Estimating: Demystifying the Black Art; Microsoft Press, Redmund, WA; Roetzheim, William H. and Beasley, Reyna A.; Best Practices in Software Cost and Schedule Estimation; Prentice Hall PTR, Saddle River, NJ; Strassmann, Paul; Information Productivity; Information Economics Press, Stamford, Ct; Strassmann, Paul; Information Payoff; Information Economics Press, Stamford, Ct; Strassmann, Paul; Governance of Information Management: The Concept of an Information Constitution; 2 nd edition; (ebook); Information Economics Press, Stamford, Ct; Strassmann, Paul; The Squandered Computer; Information Economics Press, Stamford, CT; Stukes, Sherry, Deshoretz, Jason, Apgar, Henry and Macias, Ilona; Air Force Cost Analysis Agency Software Estimating Model Analysis ; TR-9545/008-2; Contract F D-0003, Task 008; Management Consulting & Research, Inc.; Thousand Oaks, CA 91362; September Wellman, Frank, Software Costing: An Objective Approach to Estimating and Controlling the Cost of Computer Software, Prentice Hall, Englewood Cliffs, NJ, ISBN , Whitehead, Richard; Leading a Development Team; Addison Wesley, Boston, MA; 2001; ISBN 10: ; 368 pages.

15 Yourdon, Ed; Death March - The Complete Software Developer s Guide to Surviving Mission Impossible Projects; Prentice Hall PTR, Upper Saddle River, NJ; ISBN ; 1997; 218 pages. Yourdon, Ed; Outsource: Competing in the Global Productivity Race; Prentice Hall PTR, Upper Saddle River, NJ; ISBN ; 2005; 251 pages.

16