CNMES 2017 Software Cost Estimating with COSMIC - Critical knowledge for today and tomorrow
•Download as PPTX, PDF•
1 like•1,033 views
Presentation from Alain on the second national software measurement congress in Mexico CNMES.MX on the principles of software cost estimating using the COSMIC method.
More Related Content
What's hot
What's hot (20)
Similar to CNMES 2017 Software Cost Estimating with COSMIC - Critical knowledge for today and tomorrow
Similar to CNMES 2017 Software Cost Estimating with COSMIC - Critical knowledge for today and tomorrow (20)
More from COSMIC - Common Software Measurement International Consortium
More from COSMIC - Common Software Measurement International Consortium (20)
Recently uploaded
Recently uploaded (20)
CNMES 2017 Software Cost Estimating with COSMIC - Critical knowledge for today and tomorrow
- 2. Software Effort Estimating with COSMIC: Critical knowledge for today and tomorrow Alain Abran with C.Symons, C.Ebert, F.Vogelezang, H.Soubra
- 3. Presenter background - Alain Abran 3 20 years 20 years Development Maintenance Process Improvement ISO: 19761, 9126, 25000, 15939, 14143, 19759 + 40 PhD
- 4. Agenda 1. Software effort estimation & software size 2. COSMIC: 2nd generation of Function Points 3. Versatility of COSMIC Function Points 4. Contributions of COSMIC to Estimation models 5. Early & Quick COSMIC sizing at estimation time 6. Summary 4 ICEAA Bristol 2016
- 5. The Cone of Uncertainty across the Project Lifecycle 5 Range of expected variations in ‘estimation’ models across the project life cycle Adapted from Boehm (2000), Fig. 1.2
- 6. 6 You build estimation models with completed projects (with almost no uncertainty in the inputs) Organization Data Repository
- 7. 7 You do estimation upfront with a lot of uncertainty Organization Data Repository
- 8. What is Available & Measurable Across the Software Lifecycle? 8
- 9. Software Sizing Options across the Lifecycle? 9 Lines of code: X Can’t estimate until software designed X Technology-dependent, no standards Functional size (Function Points): International standard methods Technology-independent Usecase Points, Object Points, .. X Technology dependent, no standards X Mathematical validity? Story Points X Entirely subjective
- 10. Agenda 1. Software Effort Estimation & Software Size 2. COSMIC: 2nd generation of Function Points 3. Versatility of COSMIC Function Points 4. Contributions of COSMIC to Estimation models 5. Early & Quick COSMIC sizing at estimation time 6. Summary 10
- 11. 1st Generation of Function Points = Complexity tables & Weights11 Inputs - Matrix Output & Enquiries – Shared Matrix Transactions: weights in FP (Function Points)
- 12. Function Points weights = Step functions 3 FP 4 FP 6 FP 3-step size range for the IFPUG External Input Transactions Key limitations: - Only 3 values - Limited ranges (min,max) - No single measurement unit of 1 FP! 12
- 13. 1st Generation of Function Points Function Points (FP) 3 FP 4 FP 6 FP 13 = ?
- 14. 1980 1985 1990 1995 2000 Allan Albrecht FPA COSMIC v. 4.0.1 2017 COSMIC FFP v. 2.0 IFPUG 4.0 IFPUG 4.1 MkII FPA MkII FPA v.1.3 Full FP’s v.1 3-D FP’s Feature Points ISO ‘FSM’ Standard 14143 IFPUG 4.3 1st generation 2nd generation 14
- 15. 2nd Generation of Function Points Every software is different, but ….. what is common across all software: In different types of software? In very small software? In very large software? In distinct software domains? In various countries? 15
- 16. 2nd Generation of Function Points All software does this: Software being measured Boundary Functional Users types: 1. Humans 2. Hardware devices 3. Other software Entries Exits Reads Writes Persistent storage The ‘Data Movement of 1 data group’ is the unit of measurement: 1 CFP (1 CFP = 1 COSMIC Function Point) 16 COSMIC view of software
- 17. 2nd Generation with COSMIC COSMIC Function Points (CFP) No abitrary max A single CFP exists & is well defined 1 2 4 3 6 5 8 7 10 9 11 17 Largest observed functional processes: In avionics >100 CFP In banking > 70 CFP
- 18. Example 1: Intruder Alarm System - Requirements The embedded alarm software Software BoundaryInput devices (functional users) Output devices (functional users) External alarm Internal alarm 2 x LED’s Keypad Power voltage detector Front door sensor Movement detectors Persistent storage 18
- 19. Data Movem ent Functional User Data Group Entry Front-door sensor ‘Door open’ message (triggering Entry) Read - / Occupant PIN (from persistent storage) Exit Green LED Switch ‘off’ command Exit Red LED Switch ‘on’ command Exit Internal siren Start noise command Entry Keypad PIN (If the wrong code is entered, the user may enter the PIN two more times but the process is always the same so it is only measured once.) * Green LED Switch ‘on’ command (after successful entry of PIN) * Red LED Switch ‘off’ command Exit Internal siren Stop noise command (after successful entry of PIN) Exit External siren Start noise command (after three unsuccessful PIN entries, or if the PIN is not entered in time) Exit External siren Stop noise command (after 20 minutes, a legal requirement) Functional process: Possible intruder detected. Triggering event: Door opens whilst alarm system is activated. Size = 9 CFP (COSMIC Function Points) 19 The embedded alarm software Software BoundaryInput devices (functional users) Output devices (functional users) External alarm Internal alarm 2 x LED’s Keypad Power voltage detector Front door sensor Movement detectors Persistent storage
- 20. Agenda 1. Software Effort Estimation & Software Size 2. COSMIC: 2nd generation of Function Points 3. Versatility of COSMIC Function Points 4. Contributions of COSMIC to Estimation Models 5. Early & Quick COSMIC sizing at Estimation Time 6. Summary 20
- 21. Versatility - Guidelines by Application Domains • Business applications • Real-time software • Data Warehouse software • SOA software (SOA: Service Oriented Architecture) • Mobile apps • Agile Development TThhee CCOOSSMMIICC FFuunnccttiioonnaall SSiizzee MMeeaassuurreemmeenntt MMeetthhoodd VVeerrssiioonn 44..00..11 GGuuiiddeelliinnee ffoorr SSiizziinngg BBuussiinneessss AApppplliiccaattiioonn SSooffttwwaarree VERSION 1.3a Febuary 2016 21
- 22. Versatility – COSMIC Case Studies 22 • Real-time: • Rice cooker • Automatic line switching • Valve control • Business: • Course registration (distributed) • Restaurant management (web & mobile phone) • Banking web advice module • Car hire (existing legacy app.)
- 23. Versatility - at any level of software requirements Middleware Layer (Utilities, etc) Operating System Layer Keyboard Driver Screen Driver VDU Screen KeyboardHardware Disk Driver Hard Disk Drive Print Driver Printer Central Processor Database Management System Layer DBMS 1 DBMS 2 App 1Application Layer App 2 App ‘n’ 23
- 24. Agile: COSMIC Aggregation rules COSMIC size usable for: • early Total System sizing & effort estimation • US, Sprint etc. sizing & estimation • Progress control at any levelSprint Iteration Release System User Story (new &/or re-work) 24 Functional User Requirements Data Movements Functiona l Processes Functional User Event
- 25. Agenda 1. Software Effort Estimation & Software Size 2. COSMIC: 2nd generation of Function Points 3. Versatility of COSMIC Function Points 4. Contributions of COSMIC to Estimation models 5. Early & Quick COSMIC sizing at estimation time 6. Summary 25
- 26. COSMIC data from Industry 26 COSMIC method in Automotive embedded software By: Sophie Stern Renault
- 27. Data from Renault - 2012 27 © Copyrights Renault 2012
- 28. Data from Renault – 2012 28 © Copyrights Renault 2012
- 29. Renault: Estimation & Negociations 29 © Copyrights Renault 2012
- 30. Renault - Remarkable cost estimation accuracy from its ECU software specifications Cost vs size (CFP) Memory size vs software size (CFP) 30 © Copyrights Renault 2012
- 31. Renault: COSMIC Automation with Matlab SIMULINK 31 Ref. H. Soubra, and K. Chaaban, "Functional Size Measurement of Electronic Control Units Software Designed Following the AUTOSAR Standard: A Measurement Guideline Based on the COSMIC ISO 19761 Standard," IWSM-MENSURA Conference, Assisi (Italy), IEEE CS Press, 2012.
- 32. AUTOMATION ACCURACY REACHED WITH COSMIC Steer-by-Wire Runnable Functional size obtained by the manual FSM procedure (CFP) Functional size obtained by the automated FSM procedure (CFP) Steer_Run_Acquisition 3 3 Steer_Run_Sensor 4 4 Steer_Run_Command 7 7 Steer_InterECU_Wheel 3 3 Steer_Run_Actuator 2 2 Wheel_Run_Acquistion 3 3 Wheel_Run_Sensor 4 4 Wheel_Run_Command 7 7 Wheel_InterECU_Steer 3 3 Wheel _Run_Actuator 2 2 Total 38 38 Total Number of Models Total Size obtained manually (CFP) Total Size obtained using the prototype tool (CFP) Difference (%) Accuracy 76 fault- free models 1,729 1,739 Less than 1% >99% All 77 models 1,758 1,791 1.8% >98% Ref. : Hassan Soubra, Alain Abran, A. R. Cherif, ‘Verifying the Accuracy of Automation Tools for the Measurement of Software with COSMIC – ISO 19761 including an AUTOSAR-based Example and a Case Study,’ Joint 24rd International Workshop on Software Measurement & 9th MENSURA Conference, Rotterdam (The Netherlands), Oct. 6-8, 2014, IEEE CS Press, pp. 23-31. 32 Steer-by-wire case study Automation in Industry
- 33. Industry Data – Example 2 Work-hour Residuals Ref.: ‘Web Effort Estimation: Function Point Analysis vs. COSMIC By Di Martino, Ferrucci, Gravino, Sarro, Information and Software Technology 72 (2016) 90–109 33 1000 500 0 -500 -1000 CFP FP Median 25 industrial Web applications Conclusions: ‘The results of the … study revealed that COSMIC outperformed Function Points as indicator of development effort by providing significantly better estimations’3 FP 4 FP 6 FP COSMIC Function Points (CFP) No abitrary max A single CFP exists & is well defined 1 2 4 3 6 5 8 7 10 9 11
- 34. Industry Data – Example 3: Security & surveillance software systems Context: Scrum method Teams estimate tasks within each iteration in Story Points Measurements of 24 tasks in 9 iterations Each task estimated in Story Points Task actual effort recorded Each task also measured in CFP Ref. ‘Effort Estimation with Story Points and COSMIC Function Points - An Industry Case Study’, C. Commeyne, A. Abran, R. Djouab. Obtainable from www.cosmic-sizing.org ‘Software Measurement News’. Vol 21, No. 1, 2016 34
- 35. Industry Data – Example 3: Security & surveillance software systems 0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200 ActualEffort(hours) Estimated Effort (Hours) Effort = 0.47 x Story Points + 17.6 hours and R2 = 0.33) Story Points 35
- 36. Industry Data – Example 3: Security & surveillance software systems 0 20 40 60 80 100 120 140 160 180 200 0 10 20 30 40 50 60 70 80 ActualEffor(Hours) Functional Size in CFP Y = 2.35 x CFP - 0.08hrs and R2 = 0.977) 36 0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200 ActualEffort(hours) Estimated Effort (Hours) Effort = 0.47 x Story Points + 17.6 hours and R2 = 0.33) Story Points COSMIC
- 37. Other sources of COSMIC examples with industry data 37 • COSMIC web site at: www.cosmic-sizing.org
- 38. Agenda 1. Software Effort Estimation & Software Size 2. COSMIC: 2nd generation of Function Points 3. Versatility of COSMIC Function Points 4. Contributions of COSMIC to Estimation models 5. Early & Quick COSMIC sizing at estimation time 6. Summary 38
- 39. Quality of the documentation of a functional process at measurement time 39 Functional Process Quality Level Quality of the functional process definition Completely defined Functional process and its data movements are completely defined Documented Functional process is documented but not in sufficient detail to identify the data movements Identified Functional process is listed but no details are given of its data movements Counted A count of the functional processes is given, but there are no more details3 Implied (A ‘known unknown’) The functional process is implied in the actual requirements but is not explicitly mentioned Not mentioned (An ‘unknown unknown’) Existence of the functional processes is completely unknown at present
- 40. COSMIC Guidelines for Early or Rapid sizing 40 Presents 8 approximation techniques (including reported use, strengths & weaknesses): 1. Average functional process approximation 2. Fixed size classification approximation 3. Equal size bands approximation 4. Average use case approximation 5. Early & quick COSMIC approximation 6. Easy function points approximation 7. Approximation from informally written texts The COSMIC Functional Size Measurement Method Version 4.0.1 GGuuiiddeelliinnee ffoorr EEaarrllyy oorr RRaappiidd CCOOSSMMIICC FFuunnccttiioonnaall SSiizzee MMeeaassuurreemmeenntt bbyy uussiinngg aapppprrooxxiimmaattiioonn aapppprrooaacchheess July 2015 8. Approximation using fuzzy logic - EPCU
- 41. Example 1: Fixed size intervals 41 Classification Size (CFP) #E #X #R #W Error messages Small 5 1 1 1 1 1 Medium 10 2 2 3 2 1 Large 15 3 3 4 4 1 …
- 42. Example 2: Equal size bands 42 Band .Average size of a Functional Process % of total Functional Size % of total number of Functional Processes Small 4.8 25% 40% Medium 7.7 25% 26% Large 10.7 25% 19% Very Large 16.4 25% 15% Equal size bands from 37 business applications Band Average size of a Functional Process % of total Functional Size % of total number of Functional Processes Small 5.5 25% 49% Medium 10.8 25% 26% Large 18.1 25% 16% Very Large 38.8 25% 7% Equal size bands from a major component of an avionics system Organization Data Repository Organization Data Repository
- 43. Example 3: Probability distribution in the Business domain 43 Classification of the FP Specification level CFP (min) CFP CFP (max) Approximate CFP Probability Small FP Little unknown 2 (10%) 3 (75%) 5 (15%) 3.2 >80% Small FP Unknown (No FUR) 2 (15%) 4 (50%) 8 (35%) 5.1 <50% Medium FP Little unknown 5 (10%) 7 (75%) 10 (15%) 7.25 >80% Medium FP Unknown (No FUR) 5 (15%) 8 (50%) 12 (35%) 8.95 <50% Large FP Little unknown 8 (10%) 10 (75%) 12 (15%) 10.1 >80% Large FP Unknown (No FUR) 8 (15%) 10 (50%) 15 (35%) 11.45 <50% Complex FP Little unknown 10 (10%) 15 (75%) 20 (15%) 15.25 >80% Complex FP Unknown (No FUR) 10 (15%) 18 (50%) 30 (35%) 21 <50%
- 44. Agenda 1. Software Effort Estimation & Software Size 2. COSMIC: 2nd Generation of Function Points 3. Versatility of COSMIC Function Points 4. Contributions of COSMIC to Estimation Models 5. Early & Quick COSMIC sizing at Estimation Time 6. Summary 44
- 45. 45 Organization Data Repository Software COST Estimating: Critical knowledge for today & tomorrow Ample industry evidence that COSMIC Function Points allow: 1. Meaningfull benchmarking 2. Early & Quick sizing 3. Estimation with very low variations (… conditions apply…) The COSMIC Functional Size Measurement Method Version 4.0.1 GGuuiiddeelliinnee ffoorr EEaarrllyy oorr RRaappiidd CCOOSSMMIICC FFuunnccttiioonnaall SSiizzee MMeeaassuurreemmeenntt bbyy uussiinngg aapppprrooxxiimmaattiioonn aapppprrooaacchheess July 2015
- 46. Thank you for your attention ? www.cosmic-sizing.org Alain Abran alain.abran@etsmtl.ca Charles Symons cr.symons@btinternet.com Christof Ebert christof.ebert@vector.com Frank Vogelezang frank.Vogelezang@cosmic-sizing.org Hassan Soubra: hassan.soubra@estaca.fr
Editor's Notes
- The well-known cone of uncertainty attempts to represent the range of expected variations in models across the project life cycle – see Figure 1.5. X axis: from project inception (t=0) to project closure Y axis: range of variability on Effort precision in estimation At the early, feasibility stage, which is about future projects (i.e. t = 0): The project estimate can err on the side of underestimation by as much as 400%, or on the side of overestimation by 25% of the estimate. At t = the end of the project: The information on effort, duration, and costs (i.e. the dependent variables) is now known relatively accurately (with respect to the quality of the data collection process for effort recording). The information on the cost drivers (independent variables) are also relatively well known, since they have all been observed in practice – the variables are therefore considered to be ‘fixed’ without uncertainty (many of these are non quantitative, such as the type of development process, programming language, development platform, etc.) However, the relationships across these dependent variables and the independent variable are far from being common knowledge. Even in this context of no uncertainty at the level of each variable at the end of a project, there is no model today that can perfectly replicate the size-effort relationship, and there remains uncertainty in the productivity model itself. We refer to this stage as the productivity model stage (at t = the end of project). The reason why the cone of uncertainty at the extreme right of Figure 1.5 does not infer full accuracy is because all the values in this cone are tentative values provided mostly by expert judgment.
- At t = the end of the project: The information on effort, duration, and costs (i.e. the dependent variables) is now known relatively accurately (with respect to the quality of the data collection process for effort recording). The information on the cost drivers (independent variables) are also relatively well known, since they have all been observed in practice – the variables are therefore considered to be ‘fixed’ without uncertainty (many of these are non quantitative, such as the type of development process, programming language, development platform, etc.) However, the relationships across these dependent variables and the independent variable are far from being common knowledge. Even in this context of no uncertainty at the level of each variable at the end of a project, there is no model today that can perfectly replicate the size-effort relationship, and there remains uncertainty in the productivity model itself. We refer to this stage as the productivity model stage (at t = the end of project). The reason why the cone of uncertainty at the extreme right of Figure 1.5 does not infer full accuracy is because all the values in this cone are tentative values provided mostly by expert judgment. Predictive Estimation models are typically built with data from completed projects, that is at the tail-end of the Uncertainty cone. At that point in time, the facts are known on: The product functions developed and delivered to the users The development process has been completed and corresponding information is precise: days spent in total, and in each project phases-iterations-Sprints The constraints encountered are now known facts There is no more risks It is to be noted that even within this state of certainty, the mathematical models still have limitations and will not explain 100% of the variation in productivity across projects and across development environments. (note: the variation is still not at zero at project completion)
- The expected accuracy of estimation models will vary considerably across the project life cycle. This is illustrated in this figure of the Cone of Uncertainty by B. Boehm: for instance - at the Early Feasibility Study stage, the estimated may be up 4 orders of magnitude. This uncertainty range will decrease rapidly as the information about the project becomes more complete and precise. In summary, estimation is highly dependent of the levels of completeness and levels of ambiguity of the requirements, be they either functional, non functional and quality requirements. Key lessons: The Estimation Models (with uncertainty in the inputs) cannot be better than Productivity Models with no uncertainties in their inputs. What can be measured across the software lifecycle?
- Story points - It lacks traceability & is non-verifiable: it leads to unaccountability. The ‘No estimate’ movement in Agile: derives from its estimates are so bad tht it’s not worth spending time on it: Unaccountability: ‘No estimate is brilliant marketing by the software industry. We have a better alternative: - just give us money’. Making estimates only leads to suppliers clearly delivering late and over budget.
- The 1st generation of Function Points from the late 1970s are based on set of 2-dimensions table to assign ‘weights’ to functions. These weights have been set arbritarily in 1970 from an IBM environment developing Business Application software, and have not been modified since then. While numbers are assigned, there is no recognized definitions of what is Function Point. A very large number of variants have been proposed trying to handle additional dimensions using additional criteria.
- This figure illustrates the structure and impact of these 1st generation Function Points weights: They are a 3-step function There is an arbitrary minimum of 3 FP In this example, there is an arbitrary maxinum of 6 FP And a single 1 FP does not exists
- This figure illustrates the impact of these limitations This 3 step function is like a classification with only 3 values: a size for a child, a size for a teenager, and a size for an adult. But does it measure well the size of: an infant (software example: a minor change to a function will still have a size of 3FP) a basket ball player ? a much taller animal - ex. girafle? These limitations will indeed have limitations in their use of FP in estimation models based on size – the estimation models inherit the limitations of their parameters….
- 1st generation of Function Points: from the late 1970’s A large number of variants with the same structure to try to improve Innovation in 2000 with an improved & simplified design: COSMIC
- COSMIC design: it looks at all types of software, and of software sizing methods But did not try to include everything that was different from on software to another one, and from one method to another one. Instead, it look at was was COMMON across all types of sofware and what was making consensus within sizing methods
- A- presentation of the generic view of software The functional users : 3 types (human, hardware, other software) of users sending data to software or receiving data from software … and asking participants if they agree. B- the COSMIC view of software: the 4 data movements types (E,X,R,W) C- the data movement of 1 data group = 1 CPF = the measurement unit. Simple concept that everybody can understand and recognize.
- In COSMIC, the size of a functional process starts from 1 CFP up to no size limit: it size equals the number of Data movement types (of the 4 types). Largest size observed to date: + 100 CFP in avionics and + 70 CFP in banking.
- Example 1: Left of figure: the functional users sending data to the software (keypad, voltage detector, front door sensor, movement detectors) Center of figure: the software itself (and persistent storage) Right of figure: the functional users receiving data from the software (external alarm, internal alarm, 2 LED lights (red and green)
- The table on the right list the sequence of the requirements to describe: 1 functional process: a possible intruder detected And this functional procerss is triggerd when the door opens wilst the alarm system is activated. The table lists: The data movement and its type (Entry, Exit, Read, Write The functional user of that dat movement The data group for each data movement Note: two data movements do not lead to a size: there is a ‘de-duplication rule’ that states that within a functional process, the data movement of a specific data group must be sized only once. (to avoid some cheating by programmers who want to inflate its own sizing by making duplication of code, for example). The COSMIC measurement must be independent of implementation in the code.
- These various COSMIC guidelines available free on the web provides detailed examples on how to measure with COSMIC in various software domains.
- A large number of free case studies in various software domain.
- In COSMIC, there are rules and examples of how to size pieces of software in various levels of a software application architecture. A few key concepts: 1- the COSMIC measurement process starts by identifying the purpose of measurement (for instance, the purpose is to measure the size of the operating sytem layer; or to measure the size of the software embedded within the keyboard software driver. 2- the purpose of measurement will next lead to identify the functional user for this piece of software 3- this will then lead to the identification of the functional user requirements for this piece of software (and this include the other software as functional users of that piece of software. For an example of 3: the ‘operating sytem Layer (a piece of software as its user) and the Keyboard driver (a hardware piece of software) are the functional users of the ‘keyboard software driver’. This is analogous to measurement of engineering and architect plans where different plans presents different views – for different purposes - of a building.
- COSMIC can be easily measure on the basis of a User Story in Agile.
- Renault 15 uses CFP sizing to control the development and enhancement of Electronic Control Units (ECU’s) tracks progress of ECU specification teams… who create designs in Matlab Simulink… which are automatically measured in CFP Motivation for automation: speed, accuracy of measurement ‘Manage the automotive embedded software development cost & productivity with the automation of a Functional Size Measurement Method (COSMIC)” Alexandre Oriou et al, IWSM 2014, Rotterdam, www.ieeexplore.org
- Web effort estimation is more accurate with COSMIC than using classic FP ‘Web Effort Estimation: Function Point Analysis vs. COSMIC Sergio Di Martinoa, Filomena Ferruccib,∗, Carmine Gravinob, Federica Sarroc a Dipartimento di Ingegneria Elettrica e delle Tecnologie dell’Informazione, University of Napoli “Federico II”, Italy b Department of Computer Science, University of Salerno, Italy c CREST, Department of Computer Science, University College London, United Kingdom Information and Software Technology 72 (2016) 90–109
- Effort vs Story Points (24 tasks) = a poor predictor of effort Very low R2 at 0.37 Large dispersion across the regression line
- Effort with COSMIC size is much better for estimation R2 = .97
- The expected accuracy of estimation models will vary considerably across the project life cycle. This is illustrated in this figure of the Cone of Uncertainty by B. Boehm: for instance - at the Early Feasibility Study stage, the estimated may be up 4 orders of magnitude. This uncertainty range will decrease rapidly as the information about the project becomes more complete and precise. In summary, estimation is highly dependent of the levels of completeness and levels of ambiguity of the requirements, be they either functional, non functional and quality requirements. Key lessons: The Estimation Models (with uncertainty in the inputs) cannot be better than Productivity Models with no uncertainties in their inputs. What can be measured across the software lifecycle?