Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
SE 325/425 Principles and Practices of Software Engineering Autumn 2006 James Nowotarski 7 November 2006 Today’s Agenda Topic Duration Recap 20 minutes Capability maturity model (CMM) 60 minutes *** Break Current event reports 20 minutes CMM (continued) 60 minutes 2 Design Planning & Managing Communication project initiation requirements Modeling analysis design Design model: • Data/Class • Architecture • Interfaces • Components Construction code test Deployment delivery support Primary deliverables 3 Key principles of architectural design Abstraction Modularity Reuse 4 Two qualitative criteria Cohesion A measure of the relative functional strength of a module Func A-1 Func B-1 Func A-2 Func B-2 Func A-3 Func B-3 High Cohesion (good) Coupling A measure of the relative interdependence among modules High coupling (bad) 5 Architecture arch·i·tec·ture n. An architecture depicts the overall structure of a man-made complex system 6 Software architecture Applications and Data • Presentation layer • Application logic • Data management Middleware System Software Hardware/Network 7 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 8 Data centered 9 Data flow Filter Pipe Filter Filter Pipe Filter Pipe Filter Filter Pipe Pipe Pipe Filter Examples: UNIX shell commands Compilers: Lexical Analysis -> parsing -> semantic analysis -> code generation Batch Processing 10 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) employee_data employee_data employee_ data salary salary tax salary GET_DATA CALC_SALARY CALC_TAX tax PRINT_CHECK 11 Deriving a software architecture: Structured approach Derive architectural context diagram (ACD) Refine the DFD Map DFD to program structure: Transform mapping Transaction mapping 12 Architecture context diagram (ACD) Safehome Product control panel homeowner Internet-based system target system: Security Function uses surveillance function peers uses uses sensors sensors 13 Transform mapping a b d e h g f i c j data flow model x1 x2 b x4 x3 c a "Transform" mapping d e f g i h j 14 Transaction Mapping Data flow model f e a d b mapping t x1 program structure i g h l k j m t b a x2 n d e x4 x3 f g l x3.1 h m n j i k 15 Software configuration management (SCM) The art of coordinating software changes to minimize confusion SCM activities: Identification Change control Version control Configuration auditing Reporting 16 Baselined SCI’s modified Project database SCIs approved Software engineering tasks SCIs Formal technical reviews SCIs stored SCIs SCM controls extracted SCIs 17 Traceability matrix Req No. Description Traces To U2 Users shall be able to process retirement claims S10, S11, S12 U3 Users shall be able to process survivor claims S13 S10 The system shall accept retirement data U2 S11 The system shall calculate the amount of retirement U2 S12 The system shall calculate point-to-point travel time U2 S13 The system shall calculate the amount of survivor annuity. U3 Entities U2 U3 S10 U2 X U3 X S12 S13 X X S10 X S11 X S12 X S13 S11 X 18 Traceability matrix An alternate and probably more common representation. 19 Control the Change 1. 2. 3. 4. 5. Need for change is recognized Change request is submitted as a “request for change” (RFC) Developer evaluates Change report is generated Change control authority makes a decision to either: Proceed Deny request. 6. 7. 8. 9. 10. 11. 12. Request if queued for action. ECO is generated (Engineering Change Order). Individuals assigned to configuration objects. Objects checked out and change made. Change audited. Objects checked in. Baseline established. SQA activities performed. 20 Rebuild & distribute. Sample RFC form from: http://www.nws.noaa.gov/oso/oso1/oso11/oso112/drg/drgrc.htm 21 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 22 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 23 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 24 http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html Synchronizing using merges 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 25 Today’s Agenda Topic Duration Recap 20 minutes Capability maturity model (CMM) 60 minutes *** Break Current event reports 20 minutes CMM (continued) 60 minutes 26 Software process assessment and improvement Software Process is examined by identifies modifications to identifies capabilities and risk of Software Process Assessment Software Process Improvement leads to leads to Capability Determination motivates 27 Sources of improvement ideas 28 Software Process Improvement Models A number of models enable software development organizations to compare their practices to a set of “best practices” IT specific models ISO 15504 ISO 9000-3 TickIT Capability Maturity Model Integration (CMMI) General models Total Quality Management (TQM) Six Sigma 29 Capability Maturity Model Integration (CMMI) “the de facto process improvement framework for software developers” - Gartner Group 30 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 31 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 32 Brief History - CMMI 1989 1991 - 1993 1994 2001 2002 2006 - Publication of Managing the Software Process by Watts Humphrey Capability Maturity Model for Software (CMM) v1.0 released by Software Engineering Institute (SEI) CMM v1.1 released Systems engineering (SE) CMM released CMM Integration (CMMI)-SE/SW v1.0 released CMMI-SE/SW/IPPD/SS v1.1 released CMMI-Dev v1.2 released 33 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) 34 Brief History - CMMI 1989 1991 1993 1994 2001 - 2002 2006 - Publication of Managing the Software Process by Watts Humphrey Capability Maturity Model for Software (CMM) v1.0 released CMM v1.1 released Systems engineering (SE) CMM released CMM Integration (CMMI)-SE/SW v1.0 released CMMI-SE/SW/IPPD/SS v1.1 released CMMI-Dev v1.2 released 35 Why CMMI? Benefits Practical Structured Proven reputation Quantitative benefits (median): cost productivity: time to market: post-release defects: customer satisfaction: return on investment: 34% 61% 50% 48% 14% 4:1 36 CMMI Maturity Levels Optimized (5) Process improvement (“nirvana”) Quantitatively Process measured and Managed controlled (4) Defined (3) Managed (2) Initial (1) Process characterized for the organization and is proactive Process characterized for projects and is often reactive Process poorly controlled and unpredictable 37 Process areas (PAs) Maturity levels Contain Process areas 38 CMMI Process Areas Process Areas Level 5 Optimized Level 4 Quantitatively Managed Level 3 Defined Level 2 Managed Causal Analysis & Resolution Organizational Innovation & Deployment Organizational Process Performance Quantitative Project Management Requirements Development Technical Solution Product Integration Verification Validation Organization Process Focus Organization Process Definition Organizational Training Integrated Project Management Risk Management Decision Analysis & Resolution Requirements Management Project Planning Project Monitoring & Control Supplier Agreement Management Measurement & Analysis Product & Process Quality Assurance Configuration Management 39 Process areas (PAs) Process area categories Maturity levels Contain Contain Process areas Achieve Specific goals Contain Specific practices 40 Process areas (PAs) Process area Specific goals “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.” What must be achieved to satisfy the process area Specific practices Refine a goal into a set of process-related activities 41 Process areas (PAs) Process area category Maturity level Project management Level 2 - Managed Process area Project planning Specific goal Establish estimates Specific practice Determine estimates of effort and cost 42 Level 1: Initial Instability Dependence on “heroes” Inability to meet targets Key process areas: none 43 Class Activity Summarize and explain to the rest of the class: The 22 key process areas 44 Appraisal process CMMI Reference model used by Standard CMMI Appraisal Method for Process Improvement (SCAMPI) Appraisal process 45 CMMI Appraisal Method Team Selection Maturity Questionnaire Response Analysis 3 2 1 PA Profile On-site visit Interviews & document reviews 4 Findings based on the CMMI 5 6 46 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 47 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 48 Process Maturity Profile 1998 thru August 2002 100% 90% % of Organizations 80% 70% 60% 43.2% 50% 40% 23.4% 30% 19.3% 20% 7.3% 6.8% 10% 0% Initial Repeatable Defined Managed Based on assessments from 1998-2002 of 1124 organizations Optimized 49 Process Maturity Profile, April 2002-June 2006 50 Time to Move Up # of months to move to next level 75 50 Largest observed value that is not an outlier 28 Recommended time between appraisals (18-30 mos) 23 25 75th percentile 22 17 Median (50th percentile) 25th percentile Smallest observed value that is not an outlier 0 1 to 2 2 to 3 3 to 4 4 to 5 51 CMMI Market Pressure Many, if not most, of the publicly-acknowledged Level 5 CMM-certified organizations are in India 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 52 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 53 For more information http://www.sei.cmu.edu/cmmi/cmmi.html 54 For November 14 See course home page for light reading Current event reports: Karas Modi Paternostro Final exam review 55 Extra slides 56 Core Concepts The focus of SE 425 is the process component of software engineering Process Technology People … for the delivery of technology-enabled business solutions Process People Technology 57 Software Process Improvement Models ISO 15504 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 15504conformant assessment provide a migration path for existing assessment models and methods wishing to become 15504conformant 58