1 / 90

Convener: Houman Younessi

Software Engineering Management. Course # CISH-6050. Lecture 2: . Software Process Maturity. Convener: Houman Younessi. 05/ 14/2012. AGENDA. Software Process Maturity Need for Process Maturity? Maturity Concepts and Origins Software Maturity Models Frameworks Quagmire

bina
Télécharger la présentation

Convener: Houman Younessi

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Software Engineering Management Course # CISH-6050 Lecture 2: Software Process Maturity Convener: Houman Younessi 05/14/2012

  2. AGENDA • Software Process Maturity • Need for Process Maturity? • Maturity Concepts and Origins • Software Maturity Models • Frameworks Quagmire • Standards vs. Capability Maturity Models 2

  3. AGENDA … • Standards • Software • Systems Engineering • Quality • Measurements • Six Sigma • SPICE • In Class Team Assignment 3

  4. Software Process Maturity What is it? Why do it? 4

  5. Software Process Maturity … • A need for Process Maturity, from SW-CMM V1.1 • Two decades of unfulfilled promises about productivity & quality gains from applying new software methodologies & technologies • Industry & government organizations realize fundamental problem is inability to manage the software process 5

  6. Software Process Maturity … • Even in undisciplined organizations, some individual software projects produce excellent results • When such projects succeed, generally through the heroic efforts of a dedicated team vs. through repeating the proven methods of an organization with a mature software process 6

  7. Software Process Maturity … • Success relying on specific individuals provides no basis for long-term productivity & quality improvement throughout an organization • Continuous improvement occurs through focused & sustained effort in buildinga process infrastructure of effective software engineering and management practices 7

  8. Software Process Maturity … • Characteristics of an Immature Software Organization • Software process improvised • Software process not always followed • Reactionary vs. planned • Fire fighting mode • Quality & functionality compromised to make schedule • Difficult to predict product quality • Schedules and budgets routinely exceeded 8

  9. Software Process Maturity … • Characteristics of a Mature Software Organization • Organization-wide processes communicated to all staff • Work done and tracked according to planned process • Process improvement where necessary • Project quality managed & monitored • Schedules & budgets are realistic and usually achieved 9

  10. Process Maturity Concepts • Software Process Capability • Range of expected results that can be achieved by following a software process • Software process capability of an organization provides one means of predicting the most likely outcome to be expected from the next software project the organization undertakes 10

  11. Process Maturity Concepts … • Software Process Performance • Represents actual results achieved by following a software process • Based on the attributes of a specific project and the context within which it is conducted, the actual performance of the project may not reflect the full process capability of the organization 11

  12. Process Maturity Concepts … • Software Process Maturity • Extent to which a specific process is explicitly defined, managed, measured, controlled, and effective • Implies potential for growth in capability • Indicates the richness of an organization's software process & the consistency with which it is applied in projects throughout the organization 12

  13. Process Maturity Concepts … • Institutionalization • Building infrastructure & corporate culture that supports the methods, practices, and procedures of the business so they endure after those who originally defined them have gone 13

  14. Process Maturity How Process Maturity Started 14

  15. Process Maturity • Start of Process Maturity • Software process management objectives include producing products according to a plan, while simultaneously improving the organization to produce better products • These are also the basic principles of Statistical Process Control (SPC) • A process is under statistical process control if its future performance is predictable within established statistical limits 15

  16. Process Maturity … • W. E. Deming • Introduce the concept of SPC • Worked with Japanese industry after World War 2 to improve quality • Japanese industry committed to continuous process improvement for many years • SPC contributed largely to the quality of Japanese manufactured goods 16

  17. Process Maturity … • SPC Methodology • Basis - measuring product defects and relating these defects to the process • Process is improved with goal of reducing the number of defects • Process is improved until it is repeatable • Process is then standardized and further improvement cycles begin 17

  18. Process Maturity … • SPC Application • With manufacturing, process and product relationship is very obvious • Improving process to remove defects in the manufacturing process will produce a better product • Relationship less obvious with intangible products like software • Dependent on an intellectual process which can not be automated 18

  19. Process Maturity … Watts Humphrey on SPC: "While there are important differences, these [SPC] concepts are just as applicable to software as they are to producing consumer goods like cameras, television sets, or automobiles." 19

  20. Intellectual Product Quality With Intellectual products like software, where quality is principally dependent on design, four factors affect product quality Development Technology Product Quality People Quality Process Quality Cost, Time, Schedule 20

  21. Intellectual Product Quality … • Example: Very large systems made up of subsystems, which are developed by different teams • Factor determining product quality will probably be the software process • Why Process Quality factor rather than the other 3 factors? 21

  22. Intellectual Product Quality … • Example: For smaller teams, with only few team members • The quality of the development team (i.e. people quality factor) is more important than the development process used. • Why People Quality factor rather than the other 3 factors? 22

  23. Intellectual Product Quality … • Product Quality Factors affecting productivity • Smaller teams • Development Technology • Developers spend good portion of time in development activities • Good development tools affect productivity 23

  24. Intellectual Product Quality … • Larger teams • Software Process • Members spend less time developing & more time communicating and understanding other parts of the system • Basic level of development technology essential for information management 24

  25. Intellectual Product Quality … • For all projects, regardless of size, Cost, Time, and Schedule are key quality factors • Under budgeted • Unrealistic schedules • Insufficient resource • Inadequate resource 25

  26. Intellectual Product Quality … • Process improvement to become a mature development organization • Assess the organization's current process • Develop goal of desired process capability • Determine where to improve • Produce a plan to accomplish the actions • Commit resources and funding for the plan • Make improvements • Repeat the improvement process 26

  27. The Frameworks Quagmire Thoughts on the Frameworks Quagmire? 27

  28. Source: S. A. Sheard, "Evolution of the Frameworks Quagmire", IEEE Computer, July 2001, p. 97. 28

  29. The Frameworks Quagmire • Elements of the Frameworks Quagmire • Software Capability Maturity Models • Systems Engineering Maturity Models • Software Standards • Systems Engineering Standards • Measurements Standards • Quality Standards 29

  30. The Frameworks Quagmire … • Three ways to create a standard: • De facto – free interplay of market forces; example: MS Windows • Government body – example: DoD standards for the US • Voluntary consensus – established by standard setting organization; example: ISO, ANSI, IEEE 30

  31. The Frameworks Quagmire … • Voluntary consensus organizations: • ISO- International Standards Organization: • Non gov’t org established in 1947 • Established to improve international communication and trade • 160 Technical committees • ANSI - American National Standards Institute: • Represents US in ISO • Carries out standards activities 31

  32. The Frameworks Quagmire … • Voluntary consensus organizations: • IEEE– Institute of Electrical and Electronics Engineers: • Professional society • Active with Telecom and Computer standards activities • 300,000 members world wide • 530+ currently active standards 32

  33. The Frameworks Quagmire … • Standards vs Capability Models • Both describe good systems/software engineering, but differently: • Standards must go through a defined industry approval process to meet a nation's guidelines, such as those set by ANSI • Capability models can be created by anyone with resources 33

  34. The Frameworks Quagmire … • What not how: • Both focus on processes and related activities (what), not on methods or tools (how) • Purpose: • Capability Models provide a way to evaluate systems or SE capability • US Military standards originally supported contracts to aid the government in utilization of consistent processes by contractors 34

  35. The Frameworks Quagmire … • Lifecycle: • Capability models don’t prescribe a life cycle, but rather applies to any system life-cycle • Standards may prescribe a life-cycle • Number of process elements • Capability models have 18 or 19 • Most standards have less than 10 35

  36. The Frameworks Quagmire … • Standards and Models distinction can blur: • EIA/IS 731 is SE Capability Model submitted as standard • Model heavily tied to existing standards EIA 632 and IEEE 1220 • Two consistent SE standards • EIA 632 – What to do in SE systems • EIA/IS 731 – How to measure and improve the SE systems capability 36

  37. The Frameworks Quagmire Software Standards 37

  38. Quagmire: Software Standards • MIL-STD-498 - Created in 1994 by US Defense Department to integrate: • DOD-STD-2167A - Software development • DOD-STD-2168 - Software quality • DOD-STD-7935A - Documentation requirements 38

  39. Quagmire: Software Standards … • J-STD-016 - Demilitarized version of MIL-STD-498: • Released by joint IEEE and (EIA) committee • Based on MIL-STD-498 • Limited changes 39

  40. Quagmire: Software Standards … • ISO/IEC 12207 - Jointly released in 1995 by ISO and IEC • Standard for Information Technology software life-cycle processes 40

  41. Quagmire: Software Standards … • IEEE/IEA 12207 - Jointly created by IEEE and EIA work group • Based on ISO/IEC 12207 • Supersedes MIL-STD-498 and J-STD-016 41

  42. Quagmire: Software Standards … • RTCA DO -178B - Software Considerations in Airborne Systems and Equipment Cert. • Addresses aviation software systems safety • Developed independently of other frameworks 42

  43. Quagmire: Software Standards … • Summary – Four Software Standards in Quagmire: • IEEE/EIA 12207 • ISO/IEC 12207 • RTCA DO-178B • SPICE (To be discussed) 43

  44. The Frameworks Quagmire System Engineering Standards 44

  45. Quagmire: SE Standards • MIL-STD-499B - Submitted in May, 1992 by the Department Of Defense: • Total systems approach for developing defense systems • Industry never accepted these standards • DOD Cancelled in 1993 45

  46. Quagmire: SE Standards … • EIA/IS 632 - Approved as an Interim Standard (IS) in December, 1994: • Total systems approach for developing defense systems • EIA sponsored a small group to make minor wording changes to MIL-STD-499B 46

  47. Quagmire: SE Standards … • IEEE 1220 - Released as trial-use standard in 1994 & re-released as full standard in 1998: • Created at the same time as EIA/IS 632 • Contains a more commercial life-cycle and less military terminology 47

  48. Quagmire: SE Standards … • EIA 632 - Released in January, 1999: • Bears little resemblance to the EIA/IS 632 • Defines 13 processes and 34 requirements for engineering a system • Can be applied to any enterprise based life cycle phase to engineer system 48

  49. Quagmire: SE Standards … • ISO/IEC 15288 – • Addresses both systems engineering and management (business) processes • Focuses on “system” vs. “component” 49

  50. Quagmire: SE Standards … • Summary – 5 Systems Engineering standards in quagmire: • MIL-STD 499B, EIA/IS 632, IEEE 1220, EIA 632, ISO/IEC 15288 50

More Related