The pragmatic use of technology to achieve CMMi goals

1. The pragmatic use of technology to achieve CMMi goals

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. Part 1 – Technology in support of CMMI

4. Tools • CaliberRM • Together • StarTeam • MS Project • JBuilder • Others 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 make the tasks of the SW Development Methodology more efficient • Tools support the measurement of the SW Management Methodology

5. 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)

6. 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.

7. 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…

8. 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?

9. 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)

10. 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

11. 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

12. 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…)

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

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

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

21. Requirement definitions should be easily exposed to other users without a need to switch UI 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

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

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

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

25. 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/WSADEmbedded Integration 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

26. 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)

27. 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

28. 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

29. 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

30. Part 2 – Guidelines to successful SPI

31. 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

32. 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)

33. 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

34. Successful Implementation of CMMIManagement Participation • Communicate regularly and often the business drivers that have initiated the project • Actively participate in review and approval of processes • Lead by example

35. Successful Implementation of CMMIStudy 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

36. Successful Implementation of CMMIInvest 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

37. Successful Implementation of CMMIProcess 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

38. Successful Implementation of CMMIProcess 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

39. 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

40. Part 3 – Panel Discussion

41. Panel Introduction

42. Thank you for participating!

43. APPENDIX SECTION

44. 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

45. 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

46. Borland Application Lifecycle Management JBuilder Delphi JBuilder Delphi Together Together StarTeam StarTeam OptimizeIt OptimizeIt CaliberRM CaliberRM BES Janeva Interbase BES Janeva Interbase

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

48. 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

49. 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

50. SD • System Development • context and objectives • best practices CMMI • Total Quality • Management • quantitative management • continuous improvement • Organizational Change • and Development • culture & maturity • change management TQM OD What Is CMMI –Conceptual Foundations • 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