COCOMO III Drivers of Cost

Transcription

1 Software Size Product Attributes Platform Attributes COCOMO III Drivers of Cost Personnel Attributes Project Attributes Quality Attributes Attributes & Drivers Product Attributes... 3 Impact of Software Failure (FAIL)... 3 Product Complexity (CPLX)... 4 Developed for Reusability (RUSE)... 6 Required Software Security (SECU)... 6 Platform Attributes... 8 Platform Constraints... 8 Platform Volatility (PVOL) Personnel Attributes Analyst Capability (ACAP) Programmer Capability (PCAP) Personnel Continuity (PCON) Applications Experience (APEX) Language and Tool Experience (LTEX) Platform Experience (PLEX) Project Attributes Precedentedness (PREC) Development Flexibility (FLEX)

2 Opportunity and Risk Resolution (RESL) Stakeholder Team Cohesion (TEAM) Process Capability & Usage (PCUS) (Formerly PMAT) Use of Software Tools (TOOL) Multisite Development (SITE)

3 Product Attributes Product factors account for variation in the effort required to develop software due to characteristics of the product under development. Impact of Software Failure (FAIL) [Was Required Software Reliability (RELY)] This is the measure of the extent to which the software must perform its intended function over a period of time. Rating Impact of Failure Project Activities Impact Very Slight inconvenience Little detail; Many requirement TBDs Little verification Basic design information Informal design inspections No code inspections No test procedures Minimal path test or standards check Minimal stress or off-nominal tests Many requirements untested Minimal user manual Minimal as-built documentation Minimal QA or CM, easily recoverable losses Basic information; Basic verification; Frequent requirements TBDs Moderate design detail Minimal test procedures Partial path test or standards check Some requirements untested Partial stress or off-nominal tests Basic QA, CM, Standards, Draft User Manual or Test Plans Moderate, easily recoverable losses financial risk project V&V Very few requirement TBDs Detailed design information and verification Very thorough code inspections Very extensive off-nominal tests Detailed test plans and procedures Extensive stress or off-nominal tests Independent Verification & Validation (IV&V) Detailed verification, QA, CM, standards, and documentation 3

4 Rating Impact of Failure Project Activities Impact Very Loss of human life Little or no requirement TBDs Detailed requirement verification Very detailed test plans or procedures Detailed design verification Very thorough design inspections Very thorough code inspections Detailed code test procedures Very extensive off-nominal code tests Very detailed integration test plans or procedures Very extensive stress or off-nominal tests IV&V interface Detailed QA, CM, standards, and documentation Extra Loss of many human lives More of the above # People: # People: 20 # People: Product Complexity (CPLX) Complexity is divided into five characteristics. The complexity rating is the subjective weighted average of the selected area ratings. Rating Very Control Operations Straight-line code with a few nonnested structured programming operators: DOs, CASEs, IF- THEN-ELSEs. Simple module composition via procedure calls or simple scripts. Straightforward nesting of structured programming operators. Mostly simple predicates Computational Operations Evaluation of simple expressions: e.g., A=B+C*(D-E) Evaluation of moderate-level expressions: e.g., D=SQRT(B**2-4.*A*C) Devicedependent Operations Simple read, write statements with simple formats. No cognizance needed of particular processor or I/O device characteristics. I/O done at GET/PUT level. Data Management Operations Simple arrays in main memory. Simple COTS-DB queries, updates. Single file subsetting with no data structure changes, no edits, no intermediate files. Moderately complex COTS- DB queries, updates. User Interface Management Operations Simple input forms, report generators. Use of simple graphic user interface (GUI) builders. 4

5 Rating Control Operations Computational Operations Devicedependent Operations Data Management Operations User Interface Management Operations Mostly simple nesting. Some intermodule control. Decision tables. Simple callbacks or message passing, including middlewaresupported distributed processing Use of standard math and statistical routines. Basic matrix/vector operations. I/O processing includes device selection, status checking and error processing. Multi-file input and single file output. Simple structural changes, simple edits. Complex COTS-DB queries, updates. Simple use of widget set. ly nested structured programming operators with many compound predicates. Queue and stack control. Homogeneous, distributed processing. Single processor soft real-time control. Basic numerical analysis: multivariate interpolation, ordinary differential equations. Basic truncation, roundoff concerns. Operations at physical I/O level (physical storage address translations; seeks, reads, etc.). Optimized I/O overlap. Simple triggers activated by data stream contents. Complex data restructuring. Widget set development and extension. Simple voice I/O, multimedia. Very Reentrant and recursive coding. Fixed-priority interrupt handling. Task synchronization, complex callbacks. Singleprocessor hard real-time control. Multi-threaded / multi-core processing Difficult but structured numerical analysis: nearsingular matrix equations, partial differential equations. Simple parallelization. Routines for interrupt diagnosis, servicing, masking. Communication line handling. Performanceintensive embedded systems. Distributed database coordination. Complex triggers. Search optimization. Moderately complex 2D/3D, dynamic graphics, multimedia. Extra Multi-processor heterogeneous distributed processing. Multiple resource scheduling with dynamically changing priorities. Microcode-level control. Distributed hard real-time control. Difficult and unstructured numerical analysis: highly accurate analysis of noisy, stochastic data. Complex parallelization. Device timingdependent coding, microprogrammed operations. Performancecritical embedded systems. ly coupled, dynamic relational and object structures. Natural language data management. Complex multimedia, virtual reality, natural language interface. 5

6 # People: # People: 20 # People: Developed for Reusability (RUSE) This cost driver accounts for the additional effort needed to construct components intended for reuse on the current or future projects. This effort is consumed with creating more generic design of software, more elaborate documentation, and more extensive testing to ensure components are ready for use in other applications. Very Very Extra N/A none across project across program across product line across multiple product lines # People: # People: 20 # People: Required Software Security (SECU) Reflects the level of required security based on the Common Criteria for Information Technology Security Evaluation. The Common Criteria provides assurance that the process of specification, implementation and evaluation of a computer security product has been conducted in a rigorous, standard and repeatable manner at a level that is commensurate with the target environment. The Common Criteria has seven Evaluation Assurance Levels (EAL1 through EAL7) 1. The computer system must meet specific assurance requirements that involve design documentation, design analysis, functional testing, or penetration testing. The higher EALs involve more detailed documentation, analysis, and testing than the lower ones. Achieving a higher EAL certification generally costs more money and takes more time than achieving a lower one. Rating Level Description Very / N/A Functionally Tested: applicable where some confidence in correct operation is required, but the threats to security are not viewed as serious. EAL1 EAL2 Structurally Tested: requires the cooperation of the developer in terms of the delivery of design information and test results, but should not demand more effort on the part of the developer than is consistent with good software engineering practice 1 Evaluation Assurance Level, and the definition is available here: 6

7 Rating Level Description EAL3 Methodically Tested and Checked: permits a conscientious developer to gain maximum assurance from positive security engineering at the design stage without substantial alteration of existing sound software engineering practices. Very EAL4 Methodically Designed, Tested and Reviewed: permits a developer to gain maximum assurance from positive security engineering based on good software engineering development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources Extra EAL5 Semi-formally Designed and Tested: permits a developer to gain maximum assurance from security engineering based upon rigorous software engineering development practices supported by moderate application of specialist security engineering techniques. Super EAL6 Semi-formally Verified Design and Tested: permits developers to gain high assurance from application of security engineering techniques to a rigorous development environment in order to produce a premium target of evaluation for protecting high value assets against significant risks Ultra EAL7 Formally Verified Design and Tested: applicable to the development of security target of evaluation for application in extremely high risk situations and/or where the high value of the assets justifies the higher costs. Currently limited to tightly focused security functionality that is amenable to extensive formal analysis # People: # People: 20 # People: 7

8 Platform Attributes Platform is used here to mean the complex of hardware and software (OS, DBMS, etc.) the software product calls on to perform its tasks, the target platform. If the software to be developed is an operating system then the platform is the computer hardware. If a database management system is to be developed then the platform is the hardware and the operating system. If a network web browser is to be developed then the platform is the network, computer hardware, the operating system, and the distributed information repositories. A target platform can include graphic user interfaces, databases, networks, distributed middleware, mobile computing, cloud computing, high security architectures, fault-tolerant computing, and software as a service (or x as a service). The platform is what the application is being developed to; the target platform. Platform Constraints This driver captures the limitations placed on the platform s capacity such as execution time, primary/secondary storage, communications bandwidth, battery power, and maybe others. The purpose of the limitations is to reserve capacity for future growth of the software application. Platform constraints have the following characteristics: 1. Execution time constraint is the percentage of available execution time expected to be used by the system or subsystem consuming the execution time resource. Very Very Extra N/A N/A <=50% used of available execution time 70% used of available execution time 85% used of available execution time 95% used of available execution time 2. Primary/Secondary storage constraint is the percentage of available primary or secondary storage expected to be used by the system or subsystem consuming the storage resource. Very Very Extra N/A N/A <=50% used of available storage 70% used of available storage 85% used of available storage 95% used of available storage 8

9 3. Communication bandwidth constraint is the percentage of available communication bandwidth expected to be used by the system or subsystem consuming the bandwidth. Very Very Extra N/A N/A <=50% used of available bandwidth 70% used of available bandwidth 85% used of available bandwidth 95% used of available bandwidth 4. Power constraint is the percentage of available electrical power expected to be used by the system or subsystem consuming the power resource. Very Very Extra N/A N/A <=50% used of available battery power 70% used of available battery power 85% used of available battery power 95% used of available battery power 5. Other Resource Constraint #1 (please specify ) Very N/A N/A <=50% used of available constraint 70% used of available constraint Very 85% used of available constraint Extra 95% used of available constraint 6. Other Resource Constraint #2 (please specify ) Very N/A N/A <=50% used of available constraint 70% used of available constraint Very 85% used of available constraint Extra 95% used of available constraint # People: # People: 20 # People: 9

10 Platform Volatility (PVOL) The targeted platform may still be evolving while the software application is being developed. This driver captures the impact of the instability of the targeted platform resulting in unplanned rework. 1. Targeted platform rate of changes Very Very Extra N/A Major change every 12 mo.; Minor change every 1 mo. Major: 6 mo.; Minor: 2 wk. Major: 2 mo.;minor: 1 wk. Major: 2 wk.;minor: 2 days N/A 2. Concurrent development for the target platform and software application Very Very Extra Very little Fairly little Average Extensive Fairly extensive Very extensive # People: # People: 20 # People: 10

11 Personnel Attributes The Personnel Factors are for rating the development team s capability and experience not the individual. Analyst Capability (ACAP) An Analyst is important for solution space development and supervision of its implementation. Analysts work on requirements, high-level design and detailed design in the applicable domain. The major attributes that should be considered in this rating are analysis and design ability, competence, proficiency, aptitude, thoroughness, and the ability to communicate and cooperate. The rating should not consider the level of experience of the analyst. Rating Descriptor Project Activities Impact Very 15th percentile More interface and communication problems Less efficiency More errors and false starts More requirements and systems design rework, errors in rework Less effective response to programmer questions More problems on test plans 35th percentile Improvement in the above 55th percentile Typical capability 75th percentile Fewer interface and communication problems More efficient activity Fewer requirements and systems design rework, errors in rework More effective response to programmer questions Fewer problems on test plans Very 90th percentile Improvement in the above Extra N/A # People: # People: 20 # People: 11

12 Programmer Capability (PCAP) Major criteria which should be considered in the rating are ability, competence, proficiency, aptitude, thoroughness, and the ability to communicate and cooperate. The experience of the programming team should not be considered here. Rating Descriptor Project Activities Impact Very 15th percentile More problems in interactions with analysts Less efficient activity More errors, false starts More detailed design rework, errors in rework More code and documentation rework, errors in rework 35th percentile Improvement in the above 55th percentile Typical capability 75th percentile Fewer problems in interactions with analysts More efficient activity Fewer errors, false starts Fewer detailed design rework, errors in rework Fewer code and documentation rework, errors in rework Very 90th percentile Improvement in the above Extra N/A # People: # People: 20 # People: 12

13 Personnel Continuity (PCON) This driver captures the stability of the project team. It is expressed as an annual turnover rate. Very Very Extra 48% / year 24% / year 12% / year 6% / year 3% / year more than 6 years # People: # People: 20 # People: Applications Experience (APEX) This driver captures the level of application and domain experience of the project team developing the software system or subsystem. This driver is different than the Precedentedness driver. This driver focuses on the development team s experience. The Precedentedness driver focuses on the need for innovation and past successes than have demonstrated that innovation. The amount of experience is based on time. Very Very Extra <= 2 months 6 months 1 year 3 years 6 years more than 6 years # People: # People: 20 # People: 13

14 Language and Tool Experience (LTEX) This is a measure of the level of programming language and software tool experience of the project team developing the software system or subsystem. When rating this driver, consider the volatility of the development tools. Very Very Extra <= 2 months 6 months 1 year 3 years 6 year more than 6 years # People: # People: 20 # People: Platform Experience (PLEX) PEXP recognizes the importance of understanding the target platform. The definition of a target platform is provided above. This driver captures the knowledge or skill required to use the capabilities and services provided by the target platform. Very Very Extra <= 2 months 6 months 1 year 3 years 6 years more than 6 years # People: # People: 20 # People: 14

15 Project Attributes Regardless of their influence in the model, project attributes account for the environment around software development. Precedentedness (PREC) [considered changing this to Required Innovation] The driver captures the project s ability to provide new ideas and methods for solving challenges posed by application requirements. An earlier application development is considered a guide to subsequent development. If a application is similar to several previously developed applications, the precedentedness is high. PREC is based on two characteristics: 3. Need for innovative data processing architectures, algorithms Very Very Extra Very little Little General Considerable Extensive Very extensive 1. Experience in working with related software systems Very Very Extra Very little Little General Considerable Extensive Very extensive # People: # People: 20 # People: 15

16 Development Flexibility (FLEX) This driver captures the flexibility in delivered requirements, development processes and implementation constraints. Types of constraints include how much documentation is required, how much interoperability is needed to other applications, how much formalism is needed, how much qualification is necessary, etc. FLEX is based on three characteristics: 1. Need for software conformance with pre-established requirements, regulations and/or standards Very Very Extra Very extensive Fairly Extensive Considerable Through Moderate Basic 2. Need for software conformance with external interface specifications Very Very Extra Full Mostly full Considerable Intermediate level General Basic 3. Need for documentation conformance with regulations and/or standards Very Very Extra Very extensive Fairly Extensive Considerable Through Moderate Basic # People: # People: 20 # People: 16

17 Opportunity and Risk Resolution (RESL) This driver captures the proactive measures that the software project or team takes to mitigate risk and explore opportunities during the course of system development and project execution. The use of software architects and the establishment of a saleable and flexible software architecture is seen as a major influencer in risk resolution. RESL is based on seven characteristics: 1. Risk Management Plan identifies all critical risk items, establishes milestones for resolving them by preliminary design review (PDR) or life cycle architecture (LCA). Very Very Extra None Little Some Generally Mostly Fully 2. Schedule, budget, and internal milestones through PDR or LCA compatible with Risk Management Plan. Very Very Extra None Little Some Generally Mostly Fully 3. Percent of development schedule devoted to establishing architecture, given general product objectives. Very Very 33 Extra Percent of required top software architects available to project. Very Very 100 Extra Tool support available for resolving risk items, developing and verifying architectural specs. Very None Little 17

18 Very Extra Some Good Strong Full 6. Level of uncertainty in key architecture drivers derived from requirements, e.g., mission, user interface, COTS, hardware, technology, and performance. Very Very Extra Extreme Significant Considerable Some Little Very Little 7. Number and criticality of risk items. Very Very Extra > 10 Critical 5-10 Critical 2-4 Critical 1 Critical > 5Non-Critical < 5 Non-Critical # People: # People: 20 # People: 18

19 Stakeholder Team Cohesion (TEAM) The Team Cohesion scale driver accounts for the sources of project turbulence and entropy due to difficulties in synchronizing the project s stakeholders: users, customers, developers, maintainers, interfacers, others. These difficulties may arise from differences in stakeholder objectives and cultures; difficulties in reconciling objectives; and stakeholders' lack of experience and familiarity in operating as a team. TEAM is based on three characteristics: 1. Stakeholder Team Culture Very Very Stakeholders with diverse expertise, task nature, language, culture, and infrastructure; highly heterogeneous stakeholder communities Heterogeneous stakeholder community, some similarities in language and culture Shared project culture Strong team cohesion and project culture, multiple similarities in language and expertise Virtually homogeneous stakeholder communities institutionalized project culture 2. Stakeholder Team Compatibility Very Very ly conflicting organizational objectives Converging organizational objectives Compatible organizational objectives Clear roles & responsibilities Strong mutual advantage to collaboration 3. Stakeholder Team Familiarity and Trust Very Very Lack of trust; lack of familiarity Willing to collaborate, little familiarity Some familiarity and trust Extensive successful collaboration Very high level of familiarity and trust # People: # People: 20 # People: 19

20 Process Capability & Usage (PCUS) (Formerly PMAT) The consistency and effectiveness of the project team in performing Software Engineering (SEW) processes. It is based on two characteristics: 1. Project Team Behavioral Characteristics Very Very Extra Ad Hoc approach to process performance Performed SWE process, activities driven only by immediate contractual or customer requirements, SWE focus limited Managed SWE process, activities driven by customer and stakeholder needs in a suitable manner, SWE focus is requirements through design, project- centric approach not driven by organizational processes Defined SWE process, activities driven by benefit to project, SWE focus is through operation, process approach driven by organizational processes tailored for the project Quantitatively Managed SWE process, activities driven by SWE benefit, SWE focus on all phases of the life cycle Optimizing SWE process, continuous improvement, activities driven by system engineering and organizational benefit, SWE focus is product life cycle & strategic applications 2. Software Development Plan (SDP) Sophistication Very Very Extra Management judgment is used SDP is used in an ad-hoc manner only on portions of the project that require it Project uses a SDP with some customization ly customized SDP exists and is used throughout the organization. SDP employs organization processes The SDP is thorough and consistently used; organizational rewards are in place for those that improve it. Organizational processes support software development and are included in SDP requiring less specification. Organization develop best practices for SDP; all aspects of the project are included in the SDP; organizational rewards exist for those that improve it # People: # People: 20 # People: 20

21 Use of Software Tools (TOOL) The TOOL rating ranges from simple edit and code to integrated life cycle management tools. This driver consists of three characteristics: Tool Coverage, Tool Integration and Tool Maturity. 1. Tool Coverage (TCOV) 2 Very Very 2. Tool Integration (TINT) 3 Very Text-based editor, basic 3rd generation language compiler, basic library aids, and basic text-based debugger basic linker Interactive graphical editor, simple design language, simple programming support library, simple metrics/analysis tool Syntax checking editor, standard templates, simple configuration management, global find/replace, support metrics, simple repository, basic test case analyzer Semantics checking editor, automatic document generator, requirement specification aids, extended design tools, automatic code generator from design, centralized configuration management tool, process management aids, partially associative repository (simple data model support) test case analyzer, verification aids, basic reengineering & reverse engineering tool Global semantics checking, tailorable document generator, requirement specification aids with tracking capability, design tools with model verifier, code generator, extended static analysis tool, repository with complex data model support, distributed configuration management tool, test case analyzer with testing process manager, test oracle support, extended reengineering & reverse engineering tools Incompatible file formats for each tool, no inter-tool communication/control, unique graphical user interfaces (GUO), incompatible tool process assumptions and object semantics Different but convertible file formats, general message broadcasting/control to other tools, some common GUI elements, some compatibility with process assumptions and object semantics Standard file formats, message broadcasting/control through message server, common GUI elements, workable compatibilities among process assumptions and object semantics Shared file repository, point-to-point messaging/control, customizable GUI support, largely compatible process assumptions and object semantics 2 Baik, J. The Effects of CASE Tools on Software Development Effort, Dissertation, University of Southern California, Dec Baik, J. ibid. 21

22 Very ly associative file repository, point-to-point messaging/control using references, high degree of commonality in GUI elements, consistent process assumptions and object semantics 3. Tool Maturity (TMAT) 4 Very Version in prerelease beta test, simple documentation and help Version on market/available less than 6 months, up- dated documentation, help available Version on market/available between 6 months and 1 year, on-line help, tutorial available Version on market/available between 1 and 2 years, on-line user support group Very Version on market/available between 2 and 3 years, on-site technical user support group Extra Version on market/available more than 3 years # People: # People: 20 # People: 4 Baik, J. ibid. 22

23 Multisite Development (SITE) The multisite development effects on effort are significant. Determining its cost driver rating involves the assessment and judgment-based averaging of three characteristics 1. Site Collocation Very Very Extra 2. Communication Support Very Very Extra International, severe time zone impact Multi-city and multi- national, considerable time zone impact Multi-city or multi- company, some time zone effects Same city or metro area Same building or complex, some co-located stakeholders or onsite representation Fully collocated stakeholders Some phone, mail Individual phone, FAX Narrow band Wideband electronic communication. Wideband elect. comm., occasional video conf. Interactive multimedia 3. Corporate Collaboration Barriers Very Very Extra Severe export and security barriers to collaboration Mild export and security barriers to collaboration Some contractual & intellectual property constraints impacting collaboration Some collaborative tools & processes in place to facilitate and mitigate collaboration barriers Widely used and accepted collaborative tools & processes in place to facilitate and mitigate collaboration barriers Virtual team environment fully supported by interactive, collaborative tools environment # People: # People: 20 # People: 23