1. 2.1/65 The Software Process

2. 2.2/65 Overview Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

3. 2.3/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

4. 2.4/65 Session 2 – 2,000 Ft. Location Commentary Session 1 – 100,000 Ft.,,

5. 2.5/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

6. 2.6/65 Terminology – מינוח Systems analysis, –Requirements + specifications phases, Operations mode –Maintenance, Design –Architectural design, detailed design, Client, Developer, Vendor, Manufacturer, User, “עולם הדג של אברום” ספק לקוח משתמש יצרן Made in China מפתח

7. 2.7/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

8. 2.8/65 Testing Phase? There is NO testing phase!, Testing is an activity performed throughout SW production, Testing related terminology: Verification – אימות, אישור –Performed at the end of each phase, Validation - מתן תוקף חוקי –Performed before delivering the product to the client,

9. 2.9/65 Documentation Phase? There is NO documentation phase!, Why?: Every phase must be fully documented before starting the next phase, Postponed documentation may never be completed, The responsible individual may leave, The product is constantly changing, we need the documentation to do this, The design (for example) will be modified during development, but the original designers may not be available to document it.

10. 2.10/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

11. 2.11/65 Requirements Phase Assumption: –The SW being considered is economically justifiable, Concept exploration –Determine what the client needs, not what the client wants, Requirement Engineering,, Moving target problem –The Rapid prototype,

12. 2.12/65 Requirements Phase Documentation Rapid prototype or, Requirements document.

13. 2.13/65 Requirements Phase Testing Requirements Review, Rapid prototyping.

14. 2.14/65 Requirements Phase Testing

15. 2.15/65 Specification Phase Specifications document (“specifications”): –Legal document, –Must not have phrases like “optimal,” or “98% complete”, –Explicitly describes the functionality of the product, –List all inputs and outputs, –Lists all constrains, … Specifications must not be: –Ambiguous, foggy, misty –Incomplete, –Contradictory.

16. 2.16/65 Specification Phase Documentation Only when specification is completed – we can really plan the project! Only now we can appreciate time & money, (the needed personnel, environment, tools …), SDP, SDP Specification document (specifications) – EPS. EPS

17. 2.17/65 Specification Phase Testing Check the spec doc. Check the SDP, Traceability, –Every part of the specification can be linked to a statement in the requirements, Review – walkthrough.

18. 2.18/65 Design Phase Specification Phase — what, Design Phase — how, Architectural design: –Decompose the product into modules, Detailed design: –Design each module: data structures, algorithms, Retain design decisions: –When a dead-end is reached, –For the maintenance team, –Ideally, the design should be open-ended.

19. 2.19/65 Design Phase Documentation Architectural design, Detailed design, Keeping records of design decisions.

20. 2.20/65 Design Phase Testing Traceability: –Every part of the design can be linked to a statement in the specification document, and –Every statement of the specification document is reflected in some part of the design, Review, looking for: –Logical faults, –Interface fault, –Lack of exception handling & nonconformance to specifications.

21. 2.21/65 Implementation Phase Implement the detailed design in code, The modules should be tested while they are being implemented.

22. 2.22/65 Implementation Phase Documentation Source code –Test cases (with expected output), Test case and Test case results, –They will be the base for the regression testing library.

23. 2.23/65 Implementation Phase Testing Review, –Code review, Test cases, –Informal testing (desk checking): Modules should be tested while they are being implemented, –These tests are verification, –Formal testing (SQA).

24. 2.24/65 Integration Phase Combine the modules and check the product as a whole, Bottom-up vs. Top-Down integration methods.

25. 2.25/65 Integration Phase Documentation Commented source code, Test cases for the product as a whole.

26. 2.26/65 Integration Phase Testing SQA involvement, Special care for interfaces, Product testing, Acceptance testing – customer, (Checking correctness, robustness, …), Validation testing.

27. 2.27/65 Integrating COTS SW – תוכנת מדף “Shrink-wrapped SW”, Commercial Off-The-Shelf (COTS), COTS SW is often downloaded, “Click-wrapped SW”, –First version, Alpha version – Alpha testing, –Corrected Alpha version – Beta testing.

28. 2.28/65 Maintenance Phase Maintenance: –Any change once the client has accepted the SW: Corrective, Enhancement, Perfective, Adaptive, Most of the money is devoted to this phase, The problem of lack of documentation.

29. 2.29/65 Maintenance Phase Documentation Record of all changes made, with reasons, The CCB – (Change Control Board) meeting minutes, Regression test cases.

30. 2.30/65 Maintenance Phase Testing New change testing &… Regression testing, Customer are very happy with new capabilities, but they are more than upset with disappearance of previous capabilities!

31. 2.31/65 Retirement – פרישה Good SW is maintained, Sometimes SW is rewritten from scratch, SW might become un-maintainable because: 1.Maintenance is no longer cost-effective, 2.A drastic change in design has occurred, 3.The product must be implemented on a totally new hardware/operating system, 4.Documentation is missing or inaccurate, 5.Hardware is to be changed — it may be cheaper to rewrite the SW from scratch than to modify it, True retirement is a rare event.

32. 2.32/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

33. 2.33/65 Inherent Problems of SW Production Aristotelian categories –Essence – תמצית, מהות, –Accidents – תאונות, Hardware has inherent limits – so does SW, SW inherent limits [Brooks 1986]:Brooks 1986 –Complexity – מורכבות, –Conformity – קבלת מוסכמות, תאימות, –Changeability – גמישות, –Invisibility – אי נראות, Brooks claim: No Silver Bullet,,

34. 2.34/65 (Essence) Complexity – מורכבות While (X>t) read (t) … How many test cases? (assuming integers: 2 16 X 2 16 - what about DW?) SW is far more complex than hardware: –Traditional abstraction will not work, –“We cannot understand the whole, so we cannot understand any part” – Is that true? –Management is difficult, –Maintenance is a nightmare (documentation, too), OOP can reduce Complexity!

35. 2.35/65 (Essence) Complexity – מורכבות (Cont’d) Complexity affects management as well, How to obtain accurate data regarding the process?, How to manage turnover?, Complexity affects maintenance as well, Poor docs >> No docs >> Incorrect docs.

36. 2.36/65 (Essence) Conformity – קבלת מוסכמות, תאימות Does SW needs to conform the world – or is it the other way? Type 1: Existing gold refinery: –In order to increase the gold yield, management wants to computerize the control system, –The SW model – must conform to the real world – not the other way…, Type 2: New gold refinery: –Is SW the most conformable component?

37. 2.37/65 (Essence) Changeability – גמישות Software is easier to change than hardware, Pressure to change: –Reality is changing, –Useful SW – users pressure to extend functionality, –Easier to change (what about programmable HW?), –SW has a longer lifetime (~15 yrs) compared to hardware (~4 yrs).

38. 2.38/65 (Essence) Invisibility – אי נראות SW is invisible and un-visualizable, Complete views are incomprehensible, Partial views are misleading, However, all views can be helpful… –Control Flow, –Data Flow, –Time sequences, –Dependency Pattern.

39. 2.39/65 Is There a Silver Bullet? What about: –High-level languages, –Rapid prototype, –Incremental development, –Time sharing, –CASE tools, These did not solve the intrinsic problems, We have experienced, –6% annual productivity increase!, –Productivity is doubled every 12 years!, But, no “silver bullet” (order-of-magnitude increase) is possible!

40. 2.40/65 Is There a Silver Bullet? (Cont’d) What can be improved? Whenever possible – Buy (instead of make), The NIH syndrome, Emphasis the requirements, specification and design phases, Training designers, There is hope!

41. 2.41/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

42. 2.42/65 Improving the SW Process U.S. Department of Defense initiative: –“After two decades of largely unfulfilled promises about productivity and quality gains from applying new SW methodologies and technologies, industry and government organizations are realizing that their fundamental problem is the inability to manage the SW process [DoD, 1987]”, Translate…, SW Engineering Institute (SEI) Initiatives: –CMM - Capability maturity model, –ISO 9000-series, –SPICE – SW Process Improvement Capability dEtermination (ISO 15504).

43. 2.43/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

44. 2.44/65 SEI CMM – Capability Maturity Model … Not a life-cycle model, Set of strategies for improving the SW process: –SW–CMM for SW, –P–CMM for human resources (“people”), –SE–CMM for systems engineering, –IPD–CMM for integrated product development, –SA–for SW acquisition, These strategies are being unified into CMMI (Capability Maturity Model Integration).

45. 2.45/65 SEI CMM … A strategy for improving the SW process: –Put forward in 1986 by the SEI, Fundamental idea: –Improving the SW process leads to: Improved SW quality, Delivery on time, within budget, –Improved management leads to Improved techniques, Five levels of “maturity” are defined: –Organization advances stepwise from level to level.

46. 2.46/65 SEI CMM (Cont’d) … 5 STAGES OF MATURITY 1. Initial level Ad hoc process, 2. Repeatable level Basic project management, 3. Defined level Process definition, 4. Managed level Process measurement, 5. Optimizing level Process control.

47. 2.47/65 [SEI CMM] Level 1. – Initial The Lowest Level, Most organizations world-wide are at level 1!, Ad hoc approach: –Entire process is unpredictable, –Management consists of… responses to crises, How can we tell?,

48. 2.48/65 [SEI CMM] Level 2. – Repeatable Basic SW management, Management decisions should be made on the basis of previous experience with similar products, Measurements (“metrics”) are made, these can be used for making cost and duration predictions in the next project –(e.g. Tracking costs and schedules), Problems are identified, immediate corrective action is taken.

49. 2.49/65 [SEI CMM] Level 3. קו פרשת המים

50. 2.50/65 [SEI CMM] Level 3. – Defined The SW process is fully documented, Managerial and technical aspects are clearly defined, Continual efforts are made to improve quality, productivity, Reviews are performed to improve SW quality (e.g. Walkthrough, inspection), CASE tools are applicable now (and not at levels 1 or 2).

51. 2.51/65 [SEI CMM] Level 4. – Managed Quality and productivity goals are set for each project, Quality, productivity are continually monitored, Statistical quality controls are in place –e.g. Faults per 1,000 LOC.

52. 2.52/65 [SEI CMM] Level 5. – Optimizing Continuous process improvement, Statistical quality and process controls, Information from one project is always being used for projects that are built later on.

53. 2.53/65 [SEI CMM Levels] Summary

54. 2.54/65 [SEI CMM] Key Process Areas There are key process areas (KPAs) for each level, Example: level 2 KPAs include: –Requirements management, –Project planning, –Project tracking, –Configuration management, –Quality assurance, Compare: –Level 2: Detection and correction of faults, –Level 5: Prevention of faults.

55. 2.55/65 [SEI CMM] Experience … It takes: –3 to 5 years to get from level 1 to level 2, –1.5 to 3 years from level 2 to level 3, –SEI questionnaires highlight shortcomings, suggest ways to improve the process, Original idea: Defense contracts would be awarded only to capable firms.

56. 2.56/65 [SEI CMM] Experience (cont’d) Profitability: Hughes Aircraft (Fullerton, CA) spent $500K (1987–90): –Savings: $2M per year, moving from level 2 to level 3, Raytheon moved from level 1 in 1988 to level 3 in 1993: –Productivity doubled, –Return of $7.70 per dollar invested in process improvement, http://www.sei.cmu.edu/cmm/cmms/cmms.html

57. 2.57/65 Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

58. 2.58/65 ISO 9000 … A different attempt to improve SW quality, International Standards Organization – ISO, Standards which are applicable to a wide variety of industrial activities, ISO 9001 for quality systems, ISO 9000-3, guidelines to apply ISO 9001 to SW.

59. 2.59/65 ISO 9000 (Cont’d) There is an overlap with CMM, but they are not identical, Not process improvement, Stress on documenting the process, Emphasis on measurement and metrics, ISO 9000 is required to do business with the E.U., Also by many U.S. businesses, for example, GE, More and more U.S. businesses are ISO 9000 certified.

60. 2.60/65 SPICE - ISO/IEC 15504 … International process improvement initiative, Original name: SW Process Improvement Capability dEtermination (SPICE), Started by British Ministry of Defence (MOD), Includes process improvement, SW procurement, Extends and improves CMM, ISO 9000, Framework, not a method CMM, ISO 9000 conform to this framework, Now referred to as ISO/IEC 15504, Or just 15504 for short, SPICE. SPICE

61. 2.61/65 SPICE (Cont’d) SPICE is an international initiative to support the development of an international standard for SW Process Assessment. The project has three principal goals: To develop a working draft for a standard for SW process assessment, To conduct industry trials of the emerging standard, To promote the technology transfer of SW process assessment into the SW industry world-wide.

62. 2.62/65 Process Improvement Data … SEI report on 13 organizations in the original study, They used a variety of process improvement techniques, not just SW–CMM,

63. 2.63/65 Process Improvement Data (Cont'd) Results of 34 Motorola projects:

64. 2.64/65 Summary Location Commentary, Terminology, “Documentation” and “Testing” Phases, The Classical Development Phases, Inherent Problems of SW Production, Improving the SW Process, SEI Capability Maturity Model, ISO 9000 & SPICE.

65. 2.65/65 The Software Process The End