Presentation is loading. Please wait.

Presentation is loading. Please wait.

The pragmatic use of technology to achieve CMMi goals.

Similar presentations


Presentation on theme: "The pragmatic use of technology to achieve CMMi goals."— Presentation transcript:

1 The pragmatic use of technology to achieve CMMi goals

2 2 Agenda Part 1: Technology in support of achieving CMMI goals  Role of Automation in SPI initiatives  Choosing the right technology  Technology support for Level 2 Process Areas  Configuration Management (CMMI Level 2)  Requirements Management (CMMI Level 2)  Others Part 2: Guidelines to Successful SPI Part 3: Panel Discussion

3 3 Abstract Abstract: Can technology really help you achieve your CMMi goals? What type of technology approach makes sense to support your CMMi initiatives? How do you judge the suitability of specific technologies to support your CMMi program? In this session, Corné Human will shed some light on the practical application of technology in support of your CMMi objectives. The session will focus on the areas of Requirements-, Change-, and Software Configuration Management - all vital ingredients to successful CMMi implementation.

4 4 Part 1 – Technology in support of CMMI

5 5 Mapping Methodologies to Tools SW Development Methodology (How/Recipe) Waterfall Iterative Extreme Programming others SW Mgmt Methodology (What/Menu)  CMM/CMMI  ISO  SPICE  others Tools  CaliberRM  Together  StarTeam  MS Project  JBuilder  Others Tools make the tasks of the SW Development Methodology more efficient Tools support the measurement of the SW Management Methodology

6 6 The “Tool Capability Spread” Using a Requirements Management Tool as an example, let’s plot the “Aggregate Need” for tool support throughout the Application Development Lifecycle (Blue) and compare against Tool Capabilities (Green, Red)

7 7 The “Requirements Capability Spread” Gap analysis of Tool A capabilities (Green) vs. Tool support Need (Blue) Gap analysis of Tool B capabilities (Red) vs. Tool support Need (Blue). Note the difference in “coverage profile”, ie. Tool B has less overall gap area than Tool A.

8 8 The “Requirements Capability Spread” Represents the Capabilities of “Tool A” over and above those provided by “Tool B” for the DEFINITION ROLE ONLY. Question: Are these extra features/capabilities worth it, when you consider the next slide…

9 9 The “Requirements Capability Spread” Represents the Capability Areas where “Tool B” provides more coverage for roles other than just “Definition”. Question: Are the extra features from previous slide worth it when key roles “downstream” are missing out on improved RM process support?

10 10 Spreading the goodness… (RM Example) Requirements affects what everyone does. Start thinking beyond just your Analysts! Don’t make Tool decisions solely based on the needs of your Analysts (Definition Role), but consider the impact of your choice on downstream Roles. The key to real significant organisational Requirements Management improvements, lies in the wide internal adoption of RM tools & processes across many key roles, not just catering to the needs of the few. (analysts)

11 11 Thinking in a silo The Requirements Silo (or “Tower of Smart People”) Is this good enough for the overall business? Isn’t requirements for the rest of us too? “ Tool Silos” exist everywhere, placing a burden on smooth process enablement across multiple roles

12 12 Tool Selection Criteria Process enablement first, then process Enforcement  Make process “fun”, not “forced”  Focus on process participation as the only means of working  Tools should allow you to choose & grow your process  Tools with a specific process “designed in” often fail to penetrate  Lack of tool penetration results in non-process conformity Coverage is more important than silo capabilities  Wide internal adoption is the secret, not Hero-worship  Look for cross-tool reporting capabilities

13 13 Tool Selection Criteria Flexibility, Openness, Customisable  Industry Standard, Open API’s a must  Easy Forms customisation a big bonus  Be wary of proprietary-languages, -scripting and –repositories  Deep, Embedded Integrations is the way to go  Touchpoint integrations are a crutch for poor process Minimal automated workflow is a VAST improvement  Be wary of “big bang” implementations  Humans evolve slower than technology does  Start with simple workflow, then improve it. Constantly.  Look for tools that make small incremental improvements easy  Focus on improving workflow, not always getting it right (Business Environments changes so fast nowadays, by the time you have the answer, the problem has changed…)

14 14 Technology Supporting RM Manage Requirements-SG 1  Obtain an understanding of Requirements-SP 1.1  Obtain Commitment to Requirements-SP 1.2  Manage Requirements Changes-SP 1.3  Maintain Bidirectional Traceability of Requirements-SP 1.4 CaliberRM Capabilities  Visibility  Secure Approval Process  Baselining and versiioning  Traceability Together Capabilities  Visualization  Traceability

15 15 Project Planning Establish Estimates-SG 1 Develop a Project Plan-SG 2 Obtain Commitment to the Plan-SG 3 CaliberRM Capabilities  Project Plan integration  EstimatePro integration StarTeam Capabilities  Project Plan integration

16 16 Project Monitoring and Control Monitor Project against Plan- SG1  Monitor Project Planning Parameters-SP 1.1 StarTeam Capabilities  Task Assignment and Effort Tracking  StarTeam Datamart

17 17 Measurement and Analysis Many Borland products support this Process Area:  CaliberRM/Datamart  Standard Reports  Full reporting module via Caliber Datamart  Full history of all Requirements  Together  Metrics  StarTeam/Datamart  Standard Reports  Customized reports as part of Consultancy

18 18 Process & Product Quality Assurance Objectively Evaluate Processes and Work Products- SG1  CaliberRM & StarTeam Datamarts Provide Objective Insight-SG 2  CaliberRM & StarTeam  Full history of previous versions and changes including who made the change and what the change was.  StarTeam  Corrective actions assigned to tasks  Full version control of all process documentation and associated work products, plus evaluation reports

19 19 Configuration Management Establish Baselines –SG1  Identify Configuration Items-SP 1.1  Establish a Configuration Management System-SP 1.2  Create or Release Baselines-SP 1.3 Track and Control Changes-SG2  Track Change Requests-SP 2.1  Control Configuration Items-SP 2.2 Establish Integrity-SG3  Establish Configuration Management Records-SP 3.1 All 3 goals supported by StarTeam

20 20 Unified Repository For All Assets Look for tools that provide a single, integrated interface for managing files, change requests, requirements, tasks, and topics All asset types are stored within the same project and folder structures Project and View definitions provide structural flexibility for sharing/restricting assets

21 21 Integrated Change Management Change requests should be integrated, native objects to the central repository Change requests record defects, enhancements, suggestions, etc. Change requests can be linked to other configuration items manually or automatically Change requests can be entered directly or synchronized from other defect tracking sources Change requests definitions can easily be customized with custom fields and forms

22 22 Integrated Requirements Management Requirements should be integrated, native objects to the central repository Requirements should be entered directly or imported from external tools or documentation Requirement definitions should be easily exposed to other users without a need to switch UI

23 23 Integrated Task Management Tasks are native objects that the StarTeam Server understands Tasks can be entered in StarTeam or synchronized from Microsoft Project Assigning tasks and reporting on progress of assigned Tasks should be integrated. “Tasks” should be deeply integrated to PM tools.

24 24 Customizable Workflow & Forms Example Graphical workflow definition allows customization of StarTeam process rules and enforces standards Workflow definition stored in StarTeam Server as configuration items so client deployment is automatic Make the process fit your environment - not the other way around! Custom user interfaces should be easy to setup for all object types (CR’s, Tasks, etc.) Underlying workflow design should preferably have a graphical UI for design work.

25 25 Borland Java Studio Embedded Integration Integrations are subject to all process rules and workflow and security restrictions just like any other StarTeam client type Embedded IDE Client provides full StarTeam functionality within the developer’s environment without and context-switching

26 26 Two new Eclipse perspectives accommodate both novice and experienced StarTeam users 1.) The “Classic” perspective is close to the layout of the other clients 2.) The “Work-Centric” perspective arranges the StarTeam views around the editor space for highly productive daily operations Label decorations add server-side information to shared workspace resources Changes can be checked in or checked out as a whole for selected artifacts or merged into the local versions on a per-difference basis All comparisons are shown within the Eclipse workbench so there is no longer a need for external difference and merge tools Eclipse/WSAD Embedded Integration

27 27 Overview of Borland technology in support of CMMI Borland products directly support:  Requirements Management (CaliberRM)  Requirements Development (Together/CaliberRM)  Configuration Management (StarTeam)  Technical Solution (Together/IDE’s)  Product Integration (StarTeam) Borland products assist in:  Project Planning (CaliberRM)  Project Monitoring and Control (StarTeam)  Measurement and Analysis (Datamarts)  Process & Product Quality Assurance (Datamarts)

28 28 Technology Change Management (TCM) CMM Level 5 KPA Identify new technologies (i.e., tools, methods, and processes) and transition them into the organization in an orderly manner.  Evaluate new technologies  Use pilot efforts to assess changes  Incorporate changes into projects and organization standards

29 29 Key Considerations Just maintaining a CMM/CMMI level requires investment Benefits result from operating at an improved level of maturity, not from just getting there Some benefits may not be financial, but can still can be “valued” Weaknesses at lower levels of maturity increase risk and cost of achieving higher levels of maturity Costs and benefits must be determined separately for each scenario

30 30 Summary of Key Points Focus on business drivers Ensure fast returns Do what you’re capable of Controlled change Build on what you’ve already got Basic engineering disciplines are critical Don’t ignore basic working practices Your learning is important Use technology to your (competitive) advantage

31 31 Part 2 – Guidelines to successful SPI

32 32 How an initiative typically starts … Identify a process improvement initiative  Make someone responsible Pick a model  CMMI, ISO 9000, SPICE etc. Get an assessment  Strengths, Weaknesses, and Recommendations Close the gap  Implement the recommendations  Write some processes and procedures

33 33 Factors affecting SPI success Senior management monitoring of SPI Compensated SPI responsibilities SPI goals clear and well understood Technical staff involved in SPI SPI people well respected Staff time resources dedicated to SPI Source: CMM: CMU/SEI-95-TR009, Goldenson & Herbsleb op. cit. (www.sei.cmu.edu)

34 34 Common Causes Of Failure Lack of management commitment Lack of capability measures Your business does not have time  You fail to support projects You do not have buy in from practitioners Pilot is successful but roll out fails You try to become “Better” than you need to be You get seduced into compliance with the model Lack of quality assurance

35 35 Successful Implementation of CMMI Management Participation Communicate regularly and often the business drivers that have initiated the project Actively participate in review and approval of processes Lead by example

36 36 Successful Implementation of CMMI Study the Work Analyse what development staff do currently Implement Capability Measures, not Targets:  Measure process, not people  Aligned to the purpose of the work  Assess the strengths and weaknesses Benefits:  Start gaining buy-in from development staff  Able to prioritise improvements

37 37 Successful Implementation of CMMI Invest in Education Formal Training in CMMI  Train project members in the models.  Optionally train selected staff as CMM Evaluators Informal Training:  Attend forums such as the Management Forum for Excellence in Software Development (MFESD)  Talk to other organisations  Trawl the organisation for people with experience

38 38 Successful Implementation of CMMI Process Development Involve development staff at every step Communicate the “What’s In It For Me” items Avoid bureaucracy:  Minimise “red tape”  Eliminate unnecessary paperwork  Automate at every opportunity Avoid following the Standard slavishly:  If you don’t need it, don’t do it

39 39 Successful Implementation of CMMI Process Implementation Create a Communication Plan and communicate! Recognise staff who:  Participate in process improvement  Adopt new and/or changed processes Revise Capability Measures:  Measure process, not people

40 40 Sustaining Improvements Involve those affected  Make it their program  Create an improvement culture Make it clear what Is valued  Leadership by example (People will do what their manager values) Education and Training Be very careful with reward mechanisms  They usually do damage

41 41 Part 3 – Panel Discussion

42 42 Panel Introduction

43 43 Thank you for participating!

44 44 APPENDIX SECTION

45 45 What is StarTeam ? StarTeam is… “…a comprehensive software configuration management system to support the definition and control of all assets and life cycle tasks from within a single repository” Unified repository for all enterprise assets Highly optimized client-server interaction Customizable workflow and process rules

46 46 What is StarTeam ? Requirement Publication Change Management Team Discussion Task Allocation & Tracking File Management Customizable Workflow Customizable Forms Automatic Linking Open Customizable Platform Web-Centric Architecture Secure

47 47 Borland Application Lifecycle Management CaliberRM Together JBuilderDelphi StarTeam BESJanevaInterbase OptimizeIt CaliberRM Together JBuilderDelphi StarTeam BESJanevaInterbase OptimizeIt

48 48 Why CMMI – Software Delivery Results are Poor 66% NOT SUCCESSFUL 54% OVER BUDGET 70% LATE CANCELLED 30% Software development is an art, not a science. How are predictability and reliability achieved in software delivery? Source: The Standish Group 2003.

49 49 Why CMMI – Rework Devastates Productivity Without attention to processes, most application development organizations can easily spend 40% of their effort on rework Initial benefits from process improvement result from dramatically reducing rework # of developersBurdened costWasted on rework 30$3,000,000$1,200,000 100$10,000,000$4,000,000 300$30,000,000$12,000,000 500$50,000,000$20,000,000 1000$100,000,000$40,000,000 3000$300,000,000$120,000,000

50 50 What is CMMI – Background CMMI —an evolutionary roadmap for implementing the vital practices needed to continuously improve system development Developed by the Software Engineering Institute at Carnegie Mellon University Created to help U.S. Department of Defense evaluate the capability of bidders on system development contracts

51 51 What Is CMMI – Conceptual Foundations System Development  context and objectives  best practices Total Quality Management  quantitative management  continuous improvement Organizational Change and Development  culture & maturity  change management Characteristics of CMMI  Guidelines for improvement – not a prescriptive method  Indicates the what’s, not the how’s  A benchmark for improvement progress  Not just another process standard, but a unique model of organizational development

52 52 What Is CMMI – Ancestry of CMMI Acquisition CMM People CMM System Eng. CMM CMMI CMM for Software Humphrey’s Process Maturity Framework Shewart, Deming Juran Crosby CMMI was needed to integrate multiple engineering disciplines into one organizational improvement model

53 53 What Is CMMI – Two Representations Staged Continuous Focuses on transforming an organization through a series of evolutionary stages by implementing new process areas at each maturity level Focuses on improving one or more process areas by implementing more sophisticated techniques for managing and performing the process at each capability level Most organizations use the staged representation Borland’s Software Delivery Optimization practice most frequently employs the staged model when implementing improvement programs

54 54 Practices implemented by A subprocess of a process area that contributes to achieving a process area goal Goals scoped by An organizational state that results from implementing some of the practices of a process area; the objectives to be achieved by a process area Process Areas consists of A cluster of interrelated practices and objectives that contribute to the capability established at a maturity level What is CMMI – Structure of CMMI Maturity Level An evolutionary plateau in an organization’s development that establishes a new capability for performing its business functions

55 55 What Is CMMI – Two Kinds of Goals and Practices Specific Goals & Practices Generic Goal & Practices The practices that are typically incorporated into an effective process that achieves the objectives described by the goals for the process area The practices generic to every process area that are associated with the goal of institutionalizing the specific practices of the process area in order to sustain them as routine activities 2.1) Organizational policy2.7) Involve stakeholders 2.2) Plan the process2.8) Monitor & control 2.3) Provide resources2.9) Evaluate adherence 2.4) Assign responsibility2.10) Mgt. status review 2.5) Train people3.1) Define process 2.6) Manage configurations3.2) Collect Improvement

56 56 What Is CMMI – Process Areas by Maturity Level Requirements Management Project Planning Project Monitoring and Control Supplier Agreement Management Measurement and Analysis Process & Product Quality Assurance Configuration Management Organizational Process Performance Quantitative Project Management Causal Analysis & Resolution Organizational Innovation & Deployment Requirements Development Technical Solution Product Integration Verification Validation Organizational Process Focus Organizational Process Definition Organizational Training Integrated Project Management for IPPD Risk Management Integrated Teaming Decision Analysis & Resolution Organizational Environment for Integration Level 2 – Managed Level 4 – Quantitatively Managed Level 5 – Optimizing Level 3 – Defined

57 57 Understanding CMMI – Level 1 – Initial Most Level 1 organizations do some of the practices expected at Level 2, but do not get repeatable results Typical problems:  Untrained project managers  Disciplined practices sacrificed to crisis schedules  Developers rely on personal methods (hero worship)

58 58 Understanding CMMI – Level 2 – Managed Requirements Management Supplier Agreement Management Project Monitoring and Control Measurement and Analysis Project Planning Configuration Management Managed control of interfaces to the external environment Managed control of the project environment Governance of the process Process and Product Quality Assurance

59 59 Understanding CMMI – Life at Level 2 Manager characteristics:  Balances commitments with resources  Says ‘no’ when necessary  Involves teams in commitments  Plans time to repeat practices that worked in the past  Does not sacrifice disciplined practices to schedule pressures  Takes corrective action when progress deviates from plan  Manages requirements changes  Eliminates blame Developer characteristics:  Participates in planning  Provides realistic estimates  Take commitments seriously  Experience less burnout from working nights and weekends  Uses disciplined practices that have worked in the past  Observes configuration management practices  Requests advice from process and quality assurance

60 60 Understanding CMMI – Level 3 – Defined Organizational Process Focus Organizational Process Definition Organizational Training Decision Analysis and Resolution Organizational Environment for Integration Organizational support for standardized processes Integrated Project Management Risk Management Integrated Supplier Management Integrated Teaming Process-based project management Requirements Development Technical Solution Product Integration Verification Validation Engineering best practices

61 61 Understanding CMMI – Level 3 – Supporting Standard Processes Organization's standard development processes Best practices Guidelines for tailoring standard processes for use on projects Lessons learned Database of standard project measures Project 1 Size $$$ Defects Results Lessons Historical measures Repository of reusable project artifacts Reusable history Process Architecture Specifications of Process Elements Reqts. Analysis Process Organization’s Process Asset Repository

62 62 Understanding CMMI – Level 4 – Quantitatively Managed Quantitative Project Management Goal 1: Manage the project quantitatively Goal 2: Manage subprocess performance statistically Organizational Process Performance Organization’s Process Performance Baselines Inspection preparation times Inspection problem reports Module completion times System test defect reports Mean time to failure in test Project 1Project 1 Project 2Project 2

63 63 Understanding CMMI – Predicting Outcomes from Stable Processes Subprocess 1 result Project outcome Subprocess 2 result Subprocess 3 result Subprocess 1 behavior Subprocess 2 behavior Subprocess 3 behavior Project input  0 +  1 X 1 +  2 X 2 +  3 X 3 +  =  Y outcome Predictive equation for project outcome Stable processes produce more accurate predictors 

64 64 Understanding CMMI – Level 5 – Optimizing Causal Analysis and Resolution Organizational Innovation and Deployment Proactively improve process capability to close gaps between executive business objectives and current results business objective Process performance Capable process { new method

65 65 Understanding CMMI – Proactive Continuous Improvement Select candidate improvements Project’s defined processes Project’s defined process Process Architecture Process Elements Evaluate candidate improvements Deploy proven improvements Organization’s standard processes Organization standard process Process Architecture Process Elements Do Plan Act Check

66 66 Understanding CMMI – Maturity Transformations Inconsistentmanagement Projectmanagement Processmanagement Capabilitymanagement Changemanagement Source: Humphrey (1989) Individuallearning Projectlearning Organizationallearning Statisticallearning Experimentallearning Level 1 Initial Level 2 Managed Level 3 Defined Level 4 QuantitativelyManaged Level 5 Optimizing Inconsistentpractices Projectprocedures Standardprocesses Stableprocesses Capableprocesses

67 67 Validating CMMI – SEI Reported ResultsAnnual Improvement benefitmedianrange Productivity growth  35% 9% - 67% Pre-test defect detection  22% 6% - 25% Time to market  19%15% - 23% Field error reports  39%10% - 94% Return on investment5.0:14:1 - 8.8:1 Source: Software Engineering Institute, CMU/SEI-94-TR-13

68 68 Validating CMMI – Boeing Information Services Level changeAverage months Level 1 to 234 months Level 2 to 325 months Level 3 to 430 months BenefitsL1  L2L2  L3L3  L4 Reduced Defects12%40%85% Reduced Time10%38%63% Reduced Cost8%35%75% Schedule Variance145%25%15% Source: Vu (1996)

69 69 Validating CMMI – Time to Achieve Maturity Levels # of months to change levels 24 22 33 18 Change between levels upper range Interquartile range median Based on assessments from 1992 - present Source: SEI


Download ppt "The pragmatic use of technology to achieve CMMi goals."

Similar presentations


Ads by Google