1. James Nowotarski 7 November 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006

2. 2 Topic Duration Recap 20 minutes Capability maturity model (CMM)60 minutes *** Break Current event reports 20 minutes CMM (continued)60 minutes Today’s Agenda

3. 3 Design Communication project initiation requirements Modeling analysis design Construction code test Deployment delivery support Planning & Managing Primary deliverables Design model: Data/Class Architecture Interfaces Components

4. 4 Key principles of architectural design Abstraction Modularity Reuse

5. 5 Cohesion A measure of the relative functional strength of a module Two qualitative criteria Func A-1 Func A-2 Func A-3 Func B-1 Func B-2 Func B-3 High Cohesion (good) Coupling A measure of the relative interdependence among modules High coupling (bad)

6. 6 Architecture arch·i·tec·ture n. An architecture depicts the overall structure of a man-made complex system

7. 7 Software architecture Applications and Data Middleware Hardware/Network System Software Presentation layer Application logic Data management

8. 8 Taxonomy of architectural styles Data-centered Data flow (aka pipes and filters) Call and return Object oriented architectures Layered Systems Online transaction processing Process control

9. 9 Data centered

10. 10 Examples: UNIX shell commands Compilers: Lexical Analysis -> parsing -> semantic analysis -> code generation Batch Processing Filter Pipe Data flow

11. 11 Call and return PROCESS_PAYROLL for each employee get_data(:employee_data) calc_salary(employee_data:salary) calc_tax(salary:tax) print_check(employee_data, salary, tax) GET_DATA employee_data CALC_SALARY employee_ data salary CALC_TAX salary tax PRINT_CHECK employee_data salary tax

12. 12 Deriving a software architecture: Structured approach Derive architectural context diagram (ACD) Refine the DFD Map DFD to program structure: Transform mapping Transaction mapping

13. 13 Architecture context diagram (ACD)

14. 14 Transform mapping

15. 15 Transaction Mapping a b t g h d e f i k j l m n Data flow model x1 b a t x2 x3 x4 d e f g h x3.1 l m n i j k mapping program structure

16. 16 The art of coordinating software changes to minimize confusion SCM activities: Identification Change control Version control Configuration auditing Reporting Software configuration management (SCM)

17. 17 SCIs modified approved extracted SCIs stored Project database Formal technical reviews Software engineering tasks SCM controls Baselined SCI’s

18. 18 Req No.DescriptionTraces To U2Users shall be able to process retirement claimsS10, S11, S12 U3Users shall be able to process survivor claimsS13 S10The system shall accept retirement dataU2 S11The system shall calculate the amount of retirementU2 S12The system shall calculate point-to-point travel timeU2 S13The system shall calculate the amount of survivor annuity. U3 EntitiesU2U3S10S11S12S13 U2 XXX U3 X S10X S11X S12X S13X Traceability matrix

19. 19 An alternate and probably more common representation. Traceability matrix

20. 20 Control the Change 1. Need for change is recognized 2. Change request is submitted as a “request for change” (RFC) 3. Developer evaluates 4. Change report is generated 5. Change control authority makes a decision to either: Proceed Deny request. 6. Request if queued for action. ECO is generated (Engineering Change Order). 7. Individuals assigned to configuration objects. 8. Objects checked out and change made. 9. Change audited. 10. Objects checked in. 11. Baseline established. SQA activities performed. 12. Rebuild & distribute.

21. 21 Sample RFC form from: http://www.nws.noaa.gov/oso/oso1/oso11/oso112/drg/drgrc.htm

22. 22 Check-in/Check-out Most version control tools in widespread use employ the checkout-edit-checkin model to manage the evolution of version-controlled files in a repository or codebase. http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html

23. 23 Serial development with exclusive checkouts. In a strictly sequential development model, when a developer checks-out a file, the file is write-locked: No one may checkout the file if another developer has it checked-out. Instead, they must wait for the file to be checked-in (which releases or removes the write-lock). This is considered a pessimistic concurrency scheme which forces all work to take place on a single line of development. http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html

24. 24 Concurrent development using branches Branching is a common mechanism to support concurrent software development. Allows development to take place along more than one path for a particular file or directory. When the revision on the new branch is modified and checked-in, the two lines of development will have different contents and will evolve separately http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html

25. 25 Merging is the means by which one development line synchronizes its contents with another development line. The contents of the latest version on a child branch are reconciled against the contents of the latest version on the parent branch (preferably using a 2-way or 3-way file differencing or comparison tool). http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html Synchronizing using merges

26. 26 Topic Duration Recap 20 minutes Capability maturity model (CMM)60 minutes *** Break Current event reports 20 minutes CMM (continued)60 minutes Today’s Agenda

27. 27 Software process assessment and improvement Software Process Assessment is examined by identifies capabilities and risk of identifies modifications to Software Process Improvement Capability Determination leads to motivates

28. 28 Sources of improvement ideas

29. 29 Software Process Improvement Models ISO 15504 ISO 9000-3 TickIT Capability Maturity Model Integration (CMMI) IT specific models A number of models enable software development organizations to compare their practices to a set of “best practices” Total Quality Management (TQM) Six Sigma General models

30. 30 Capability Maturity Model Integration (CMMI) “the de facto process improvement framework for software developers” - Gartner Group

31. 31 What is CMMI CMMI = Capability Maturity Model Integration Developed in1991 by Software Engineering Institute (SEI) to assess the software engineering capability of government contractors A framework for software process improvement (SPI) that has gained wide acceptance in the industry A roadmap of effective practices that build on one another in a logical progression coherent ordered set of incremental improvements

32. 32 What is SEI SEI = Software Engineering Institute Federally funded research & development center Sponsored by Department of Defense Affiliated with Carnegie Mellon University in Pittsburgh Established in 1984 Research and publications oriented Mission is to improve the state of the practice of software engineering

33. 33 Brief History - CMMI 1989 - Publication of Managing the Software Process by Watts Humphrey 1991 -Capability Maturity Model for Software (CMM) v1.0 released by Software Engineering Institute (SEI) 1993 - CMM v1.1 released 1994 - Systems engineering (SE) CMM released 2001 - CMM Integration (CMMI)-SE/SW v1.0 released 2002 - CMMI-SE/SW/IPPD/SS v1.1 released 2006 - CMMI-Dev v1.2 released

34. 34 A proliferation of models Different capability maturity models Software CMM (SW) Systems Engineering CMM (SE) Integrated Product and Process Development CMM (IPPD) Supplier Sourcing (SS) Software Acquisition (ACQ) Services (SVC) Team Software Process Personal Software Process People CMM (P-CMM)

35. 35 Brief History - CMMI 1989 - Publication of Managing the Software Process by Watts Humphrey 1991 -Capability Maturity Model for Software (CMM) v1.0 released 1993 - CMM v1.1 released 1994 - Systems engineering (SE) CMM released 2001 - CMM Integration (CMMI)-SE/SW v1.0 released 2002 - CMMI-SE/SW/IPPD/SS v1.1 released 2006 - CMMI-Dev v1.2 released

36. 36 Why CMMI? Practical Structured Proven reputation Quantitative benefits (median): cost34% productivity:61% time to market:50% post-release defects:48% customer satisfaction:14% return on investment:4:1 Benefits

37. 37 CMMI Maturity Levels Managed (2) Managed (2) Defined (3) Defined (3) Quantitatively Managed (4) Quantitatively Managed (4) Optimized (5) Optimized (5) Initial (1) Initial (1) Process poorly controlled and unpredictable Process characterized for projects and is often reactive Process characterized for the organization and is proactive Process measured and controlled Process improvement (“nirvana”)

38. 38 Process areas (PAs) Maturity levels Process areas Contain

39. 39 CMMI Process Areas Level 3 Defined Requirements Development Technical Solution Product Integration Verification Validation Organization Process Focus Organization Process Definition Organizational Training Integrated Project Management Risk Management Decision Analysis & Resolution Level 2 Managed Requirements Management Project Planning Project Monitoring & Control Supplier Agreement Management Measurement & Analysis Product & Process Quality Assurance Configuration Management Level 5 Optimized Causal Analysis & Resolution Organizational Innovation & Deployment Level 4 Quantitatively Managed Organizational Process Performance Quantitative Project Management Process Areas

40. 40 Process areas (PAs) Maturity levels Process areas Contain Specific practices Contain Specific goals Achieve Process area categories Contain

41. 41 Process areas (PAs) Process area “A cluster of related practices in an area that, when performed collectively, satisfy a set of goals considered important for making significant improvement in that area.” Specific goals What must be achieved to satisfy the process area Specific practices Refine a goal into a set of process-related activities

42. 42 Process areas (PAs) Level 2 - Managed Project planning Process area Determine estimates of effort and cost Specific practice Establish estimates Specific goal Maturity level Project management Process area category

43. 43 Level 1: Initial Instability Dependence on “heroes” Inability to meet targets Key process areas: none

44. 44 Class Activity Summarize and explain to the rest of the class: The 22 key process areas

45. 45 Appraisal process CMMI Reference model Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Appraisal process used by

46. 46 CMMI Appraisal Method Team Selection 1 Maturity Questionnaire 2 Response Analysis 3 On-site visit Interviews & document reviews 4 Findings based on the CMMI 5 PA Profile 6

47. 47 Appraisal Process For internal purposes: Performed in open, collaborative environment Focuses on improving the organization’s software process For external credential: Performed in a more audit-oriented environment Focuses on identifying risks associated with a contractor Team’s recommendation will help select contractors or set fees

48. 48 CMMI Issues in the Real-World “Level envy” Areas not addressed: Business strategy and linkage to IT Operations, help desk, support Management of the IT human resource Application portfolio Tools Many question whether it is worth the effort to pursue levels 4 and 5

49. 49 Process Maturity Profile 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 0% Initial 19.3% Repeatable 43.2% Defined 23.4% Managed 7.3% Optimized 6.8% % of Organizations 1998 thru August 2002 Based on assessments from 1998-2002 of 1124 organizations

50. 50 Process Maturity Profile, April 2002-June 2006

51. 51 Time to Move Up # of months to move to next level 0 75 50 25 1 to 2 23 22 2 to 3 28 3 to 4 17 4 to 5 Largest observed value that is not an outlier 75th percentile Median (50th percentile) 25th percentile Smallest observed value that is not an outlier Recommended time between appraisals (18-30 mos)

52. 52 CMMI Market Pressure Marketing tool to win clients, who are based predominantly in US and Europe Clients using Indian service providers should have certain key processes in place: service level agreements identifying business requirements scoping requirements managing changes Many, if not most, of the publicly-acknowledged Level 5 CMM-certified organizations are in India

53. 53 CMMI-based Software Process Improvement (SPI) Time and cost often exceed expectations 18-24 months to advance 1 level Can cost $2K per software engineer per year 1-2% full-time resources (e.g., 5-10 in a 500-person organization) 2-4% of rest of organization’s time Key success factors Senior management is engaged Participation and buy-in at all levels, including middle management and technical staff Clearly stated, well understood SPI goals Clear assignment of responsibility SEPG staffed by highly respected people

54. 54 For more information http://www.sei.cmu.edu/cmmi/cmmi.html

55. 55 See course home page for light reading Current event reports: Karas Modi Paternostro Final exam review For November 14

56. 56 Extra slides

57. 57 Technology Process People The focus of SE 425 is the process component of software engineering Core Concepts Technology Process People … for the delivery of technology-enabled business solutions

58. 58 Software Process Improvement Models International collaborative effort (including SEI) Sparked by an investigative study sponsored by the U.K. Ministry of Defense (MOD) Objective: To develop a standard in the area of software process assessment establish a common framework for expressing the process capability ratings resulting from a 15504- conformant assessment provide a migration path for existing assessment models and methods wishing to become 15504- conformant ISO 15504