Rational Business Driven Development For Compliance: Front Cover
Rational Business Driven Development For Compliance: Front Cover
Rational Business Driven Development For Compliance: Front Cover
Ueli Wahli Majid Irani Matthew Magee Ana Negrello Celio Palma Jason Smith
ibm.com/redbooks
International Technical Support Organization Rational Business Driven Development for Compliance November 2006
SG24-7244-00
Note: Before using this information and the product it supports, read the information in Notices on page ix.
First Edition (November 2006) This edition applies to IBM Rational software tools, such as RequisitePro, ClearCase, ClearQuest, ClearQuest Test Manager, Portfolio Manager, BuildForge, Functional Tester, Manual Tester, Performance Tester, Method Composer, Unified Process, ProjectConsole, and SoDA.
Copyright International Business Machines Corporation 2006. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi The team that wrote this IBM Redbook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Thanks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Chapter 1. A discussion about compliance . . . . . . . . . . . . . . . . . . . . . . . . . 1 Overview of todays regulated environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 What it means to be compliant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Policy creation and management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Regulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Sarbanes-Oxley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 USA Patriot Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Basel II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Title 21 CFR 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 HIPAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Gramm-Leach-Bliley . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Sustainable compliance management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 How auditors inspect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Compliance: an opportunity to improve the business. . . . . . . . . . . . . . . . . . . . 13 Regulations versus standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Software development oriented standards. . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 COSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 COBIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 ITIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 SPICE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ISO 900x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Six Sigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 CMMI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 RUP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Typical compliance challenges and concerns . . . . . . . . . . . . . . . . . . . . . . . . . 22 External business factors impacting compliance initiatives . . . . . . . . . . . . . . . 25 Chapter 2. Compliance guidelines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Why business compliance often requires software development compliance . 30 Compliance in automated business transactions . . . . . . . . . . . . . . . . . . . . 30
iii
Governance versus compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Implementing software applications is a kind of governance . . . . . . . . . 33 Compliance process requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Satisfying provisioned policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Demonstration of audit data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Compliance cost and controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Adoption of best practices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Workflow automation for tool-directed behavior. . . . . . . . . . . . . . . . . . . 41 Considerations for compliant process design. . . . . . . . . . . . . . . . . . . . . . . . . . 42 Software development process documentation . . . . . . . . . . . . . . . . . . . . . 42 Separation of duties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Financial approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Technology approvals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Software development audit trails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Electronic signatures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Authentication and authorization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Points of control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Documentation and reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 Metrics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Defining metrics and measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Selection of key metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 General considerations and practical control strategies. . . . . . . . . . . . . . . . . . 50 Leveraging the infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 High trust and high security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 High and low ceremony . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Establishing your organizational position . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Practical control strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 General strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Define a compliant software development process . . . . . . . . . . . . . . . . 53 Assign roles, responsibilities, and reporting requirements. . . . . . . . . . . 54 Establish points of control in the flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 The three points of control strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Control point 1: Deliver change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Control point 2: Register derived objects . . . . . . . . . . . . . . . . . . . . . . . . 55 Control point 3: Deploy objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Roles and responsibilities in this strategy . . . . . . . . . . . . . . . . . . . . . . . 56 Chapter 3. IBM Rational's key capabilities for compliance management 59 The IBM Rational solution for compliance management . . . . . . . . . . . . . . . . . 60 Business-driven development for compliance . . . . . . . . . . . . . . . . . . . . . . . . . 61 Control principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Development governance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
iv
Supporting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Rational Portfolio Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Supporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Requirements management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Supporting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Rational RequisitePro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 WebSphere Business Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Supporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Software change management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Supporting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Rational ClearQuest. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Rational ClearCase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Supporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 Build and deployment management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Supporting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Rational BuildForge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Tivoli Provisioning Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Supporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Software validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Supporting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Rational ClearQuest Test Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 Rational Functional Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Rational Manual Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Rational Performance Tester . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Supporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Validating your compliance process. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Supporting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Rational Method Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Rational Unified Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 RUP Plug-in for Compliance Management . . . . . . . . . . . . . . . . . . . . . 107 Supporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Contents
Documenting results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Discussion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Supporting tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Rational ProjectConsole . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 Rational SoDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Supporting process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 Defining a customized solution for an organization . . . . . . . . . . . . . . . . . . . . 112 Three-phases approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Chapter 4. Roadmap to compliance management . . . . . . . . . . . . . . . . . . 119 A solution using Rational tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Compliance roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Capability patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Rational tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Solution details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Process modeling and design for compliance. . . . . . . . . . . . . . . . . . . . . . 125 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 Manage compliance portfolio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Manage projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Initiate compliance project. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Deliver auditable change. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
vi
Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Securely deploy a release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Validate automated business controls . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Manage and generate metrics and reports . . . . . . . . . . . . . . . . . . . . . . . . 158 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Appendix A. Unified Method Architecture . . . . . . . . . . . . . . . . . . . . . . . . 163 Unified Method Architecture defined . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Fundamental principles of UMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 The basic elements of UMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Key concepts of UMA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Method content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 Development process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Separation of method content and process . . . . . . . . . . . . . . . . . . . . . . . 168 Content reuse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Process families . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Multiple life cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Flexible extensibility and plug-in mechanisms . . . . . . . . . . . . . . . . . . . . . 169 Multiple process views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Reusable process patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Abbreviations and acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Contents
vii
Rational . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Tivoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 Compliance regulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 How to get IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
viii
Notices
This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information about the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-IBM product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not give you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing, IBM Corporation, North Castle Drive Armonk, NY 10504-1785 U.S.A. The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-IBM Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. COPYRIGHT LICENSE: This information contains sample application programs in source language, which illustrates programming techniques on various operating platforms. You may copy, modify, and distribute these sample programs in any form without payment to IBM, for the purposes of developing, using, marketing or distributing application programs conforming to the application programming interface for the operating platform for which the sample programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or imply reliability, serviceability, or function of these programs. You may copy, modify, and distribute these sample programs in any form without payment to IBM for the purposes of developing, using, marketing, or distributing application programs conforming to IBM's application programming interfaces.
ix
Trademarks
The following terms are trademarks of the International Business Machines Corporation in the United States, other countries, or both: Eserver Eserver Redbooks (logo) z/OS ClearCase ClearQuest DB2 IBM MQSeries OMEGAMON ProjectConsole Rational Method Composer Rational Portfolio Manager Rational Summit Rational Unified Process Rational Redbooks RequisitePro RUP SoDA Summit Team Unifying Platform Tivoli WebSphere Workplace
The following terms are trademarks of other companies: Java, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Visual Basic, Visual Studio, Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Other company, product, or service names may be trademarks or service marks of others.
Preface
This IBM Redbook will help you design your processes and solutions using Rational products to manage compliance. It shows how IBM Rational solutions can be applied by an organization to realize a controlled, auditable software development environment to help alleviate specific challenges imposed by standards, policies, and regulations. This book provides a usage model and product configuration guidance to help a tools administrator implement and configure some or all of the Rational tools to address compliance challenges. This book will help you and your partners understand the design and deployment of IBM Rationals Business Driven Development for Compliance solution. This book focuses on problems addressed by Rational products. The emphasis is on auditable change processes, in particular using ClearQuest and ClearCase. Additional coverage is on requirements for compliance using RequisitePro and compliance attestation using ClearQuest Test Manager, IT governance using Rational Portfolio Manager, Rational Method Composer, and the Rational Unified Process (RUP). This book presents a solution for compliance management that demonstrates support of all three dimensions of business driven development of software for compliance, say what you do, do what you say, and be able to prove it.
xi
Jason
Majid
Ana
Celio
Ueli
Ueli Wahli is a Consultant IT Specialist at the IBM International Technical Support Organization in San Jose, California. Before joining the ITSO over 20 years ago, Ueli worked in technical support at IBM Switzerland. He writes extensively and teaches IBM classes worldwide about WebSphere Application Server and WebSphere and Rational application development products. In his ITSO career, Ueli has produced more than 30 IBM Redbooks. Ueli holds a degree in Mathematics from the Swiss Federal Institute of Technology. Majid Irani is a Senior IT Specialist at IBM Software Group, Rational in Cupertino, California. He works with IBM teams, performs on-site assessments, and delivers workshops to ensure successful deployment and adoption of Rational UCM/SCM solutions. He has over 10 years of experience in software configuration management and is a Rational certified engineer. He has been with IBM for over six years. Majid holds a Bachelors degree in Computer Science and Engineering from the University of California in Los Angeles.
xii
Ana Negrello is an IBM Certified IT Specialist in the IBM Software Group in Brazil, specializing in process, requirements, and project management. She has worked in software engineering for the last 20 years. She graduated with a degree in Computer Science from the University of Campinas and earned a post-graduate degree in Marketing at the Escola Superior de Propaganda e Marketing in Sao Paulo, Brazil. Celio Palma is an IT Specialist in Uruguay. He is the leader of the tools group for BCS Uruguay, a team member of the tools and technology core group for SSA, Rational focal point for BCS Uruguay, and SCM responsible for BPS projects. He has seven years of experience in the service delivery center and two years of experience in tools configuration and deployment. His experience includes participation in CMMi level 4 and 5 certifications and IBM Rational tools administration. He is a Computer Analyst, holding a degree from Facultad de Ingeniera at the Universidad de la Repblica, Montevideo, Uruguay. Jason Smith is a Senior IT Specialist for IBM Rational Sales based in Waltham, Massachusetts. He has 14 years of experience in software configuration management, the last eleven supporting Rational tools. He holds Rational certifications in ClearCase, ClearQuest, and UCM. He has been with IBM for just over a year, and before that worked for a variety of start-up companies in the New England area. Jason holds a degree in Electrical Engineering from Tufts University in Medford, Massachusetts.
Thanks
A special thank you to Matthew Magee, the author of a white paper on IBM Rationals solution for compliance that was used as a primary input for this IBM Redbook. Matthew also provided a thorough review and partial rewrite of several chapters. Thanks to the following people for their contributions to this project: Lynn Mueller, IBM West Chester, for her overall project guidance, support, and content reviews. Jamie Klein, IBM Lexington, for her legal guidance and review of the contents of this book. Thierry Paradan, IBM Cupertino, and Zoe Eason, IBM UK, for their contribution regarding the Unified Method Architecture and the RUP plug-in for compliance management. Robyn Gold, Bernie Coyne, David Lubanko, and Paul Tasillo, IBM Lexington; Roger Le Blanc, IBM Minneapolis; Joseph Meagher, IBM Dallas; Dudley Thomas, IBM Nashville; and Calvin Powers, IBM Durham, for providing help, reviews, and material for this book.
Preface
xiii
Comments welcome
Your comments are important to us! We want our Redbooks to be as helpful as possible. Send us your comments about this or other Redbooks in one of the following ways: Use the online Contact us review redbook form found at: ibm.com/redbooks Send your comments in an e-mail to: redbook@us.ibm.com Mail your comments to: IBM Corporation, International Technical Support Organization Dept. HYTD Mail Station P099 2455 South Road Poughkeepsie, NY 12601-5400
xiv
Chapter 1.
Non-directiveWhile regulatory authorities typically define what needs to be done, rarely do regulatory authorities detail the how, that is, the specific steps that companies must take in order to ensure compliance. The interpretation of regulations into policies and operating procedures is left up to organizations and their legal and policy-making staffs. Continuously changingRegulations, their interpretation, and their adoption/absorption/reflection in corporate policies can change frequently and at inconvenient times. Commonly accepted standards for meeting regulatory requirements can evolve as regulations are tested and their interpretations refined. Regulatory authorities themselves can be malleable. For example, when the Food and Drug Administration (FDA) developed guidance governing the implementation of the Title 21 Part 11, Electronic
Records and Signatures Rule, guidance was developed and revoked four times before the agency settled on a final direction.
Non-certifiableAgencies generally do not approve, recommend, or validate a companys compliance solutions. Most agencies will not certify that any solution guarantees compliance. Intrinsically related to harmRegulatory authorities tend to set the bar for compliance relative to the harm associated with a given occupation. To take Occupational Safety and Health regulations created by OSHA, it is generally acknowledged that a lower bar of compliance has been set for a small bookstore operation versus a steel framing or construction company where jobs are more dangerous.
As you move from one regulated domain to another, harm and accountability fluctuate as well. The risks to life and health to the general population are significantly higher in the life sciences, bio sciences, pharmaceutical, and medical device industries. Consequently, the regulations in this area tend to set higher bars for compliance, and have a significantly higher cost of implementation and a stricter standard of accountability. Where risk of non-compliance can be measured in loss of life or health risks, regulations typically carry stiffer penalties as well. The impact of complying with regulations, standards, and policies runs enterprise-wide, affecting people, processes, information, technology infrastructure, and facilities. Regulatory business controls impact everything from facilities (Is the front door locked?), to organization (Is their an independent board of directors?), to strategy (Is our product strategy subject to FDA approval?).
Because many regulations do not tell companies exactly what they need to do, companies must rely on their own legal staffs and risk officers to interpret regulations and reflect, adopt, or absorb their interpretation into company policy.
Given the interdependencies of policy artifacts, it is useful to consider structured policy management techniques that can create a chain of traceability among policies and policy-related artifacts in an enterprise. This can allow an enterprise to show a traceable chain from the IT controls implemented in the enterprise all the way back to the corporate level policy statement.
Regulations
Figure 1-1 shows examples of regulations and Figure 1-2 shows certain regulations that are gaining a lot of focus, by industry.
Sarbanes-Oxley Act
(Markets in Financial Instruments Directive)
MiFID
21CFR11
Patriot Act
REACH
FDA
Industry
Cross Industry
S a rb a n e s-O x le y
C a p a b ility M a tu rity M o del C o m p lia n c e IS O 1 7 7 9 9 NF P A 1 60 0
Automotive
T re a d A c t
Banking
U S P a trio t A ct B a s e l II A cc o rd
G ra m m L e a c h B lile y Check 21
Electronics
W a s te E le c tr ic a l an d E le c tr o n ic E q u ip m e n t (W E E E ) in itia tiv e
Financial Markets
S E C 1 7 A -4 N A S D 3 0 1 0 /3 1 1 0 NY SE 472 / NASD 2711
GovernGovernment
D o D 5 0 1 5 .2 DOM EA G o v e rn m e n t P ap er E lim in a t io n A ct
Regulation / Standard
The regulations that are getting the most attention today include: Sarbanes-Oxley US Patriot Act Basel II Accord 21 CFR 11 HIPAA Graham-Leach-Bliley We briefly introduce these regulations next.
Sarbanes-Oxley
Intended to restore confidence in public financial reporting in the wake of a series of public scandals, the Sarbanes-Oxley Act of 2002 (SOX) represents a fundamental change in how management carries out its fiduciary responsibilities. Not only does this mandate require a magnified look at process, but it has also becomes a catalyst for CFOs to build proactive control into processes like revenue recognition. Some of the objectives are: Requires management to demonstrate knowledge of underlying process of the business Describes how transactions are authorized or accepted for input into processing Identifies critical data files used during processing Defines key reports resulting from processing Ongoing process to monitor internal controls while continuously evaluating and improving their effectiveness Internal controls over financial reporting are those controls that ensure that the relevant financial statement assertions are complete and accurate and in accordance with Generally Accepted Accounting Principles (GAAP). To learn more about SOX refer to:
http://www.sec.gov/news/studies/principlesbasedstand.htm http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=107_cong_bills&do cid=f:h3763enr.tst.pdf
A is for analyzing and understanding the components of your current program. D is for developing a comprehensive Bank Secrecy Act Anti-Money Laundering application, which includes a customer identification program. Ap is to apply your revised program throughout the affected day-to-day operation. T is to test the new program through internal audits and testing to ensure that the program functions as intended.
As you read through the check-up list you will find many great control guidelines. To learn more about the USA Patriot Act refer to:
http://thomas.loc.gov/cgi-bin/query/z?c107:H.R.3162.ENR:
Basel II
The premise of the Basel accord was to address the amount of capital that banks were required to hold against loans, which provides protection to depositors and shareholders in the event of default on the loans. The accord required that all banks use the same measure of risk for their loan portfolios. The result is that most banks are required to hold more capital than may be necessary. To address this discrepancy Basel II was developed. This updated version of the Basel accord allows banks to use their own performance data to determine their risk and thus the amount of capital they will be required to hold. Based on this new framework, institutions must now address the systems they have in place.
Basel came about because of financial market loss (due to poor risk management practices and fraud) since 1992. Implementation of the new capital rules is due in 2007, but requires that banks are using Basel-compliant systems and data before then. To learn more about Basel II refer to:
http://www.bis.org/publ/bcbs118.htm
Title 21 CFR 11
The Code of Federal Regulations (CFR) is a codification of US federal rules and regulations. Title 21 is allocated to the Food and Drug Administration. Chapter I Part 11 of Title 21 describes the criteria under which the agency considers electronic records, electronic signatures, and handwritten signatures executed to electronic records to be trustworthy, reliable, and generally equivalent to paper records and handwritten signatures. To learn more about Title 21 CFR 11 refer to:
http://www.access.gpo.gov/cgi-bin/cfrassemble.cgi?title=200521 http://www.access.gpo.gov/nara/cfr/waisidx_05/21cfr11_05.html
HIPAA
The Health Insurance Portability & Accountability Act (HIPAA) adopts standards for the security of electronic protected health information to be implemented by certain health care institutions. The Center for Medicare and Medicaid Services (CMS) has prepared a HIPAA readiness checklist to assist companies with compliance. The checklist provided is designed to help companies start to think about what they incorporate into their transaction processing to ensure that these security requirements are met. Health care providers must have a complete understanding of how each of these processes is currently run, and how they need to be updated and documented so that customers and auditors alike can be assured the critical data is not at risk. In summary, HIPAA provides strong protection of personal health care information. To learn more about HIPAA refer to:
http://www.cms.hhs.gov/HIPAAGenInfo
Gramm-Leach-Bliley
The Gramm-Leach-Bliley Act requires financial institutions to disclose to consumers and customers their policies and practices for protecting the privacy of non-public personal information. The bottom line is that each financial institution must develop an information security program that establishes administrative, technical, and physical safeguards. To learn more about Gramm-Leach-Bliley refer to:
http://www.ftc.gov/privacy/glbact/glbsub1.htm
10
Typically, inspectors are looking for one of three things when an exception is raised: Was the exception a result of: System design flaw Human error Malicious behavior Although each audit can be different, here are some of the main areas the auditors will likely investigate:
Evidence of documented process/adherenceInspectors often want to know that you have a documented process. In the case of an IT audit, for example, they may ask for your software development life cycle (SDLC) documentation. Upon review the auditors may request interviews with two or three people from the department being audited. They typically interview each person independently to determine whether their practices match both the stated documentation and other team members practices. Should the results of these interviews not match each other as well as the documented SDLC, it is a sign of a problem that will trigger a deeper exploration. Evidence of process maturity and stabilityEven if the practices match the
documentation above and each other, auditors will look for corroborating evidence of process stability. For example, auditors may examine application development metrics, which can only be gathered consistently over time where there is process stability (otherwise the metrics become skewed, and invaluable, and may pose another remediation point).
11
Evidence of process complianceDocumented evidence of a formal change control board (CCB) should also be demonstrated as evidence of control over both the quality process mechanism and the metrics gathering mechanisms, as well as to the applications themselves. Linkages between process and artifactsBecause the approach to systems
inspection tends to be by exception, it is not uncommon for auditor or inspector to examine a problem artifact and request all of the related information for that problem artifact (artifact traceability). This presents a significant challenge to most businesses because the archeology necessary to locate most of these artifacts could be quite lengthy, if these artifacts can be located at all.
Linkage between documented test results and requirementsAt the very least
an auditor will test a demonstrated ability to show linkages between the feature requirements of a system and the test results that conclusively illustrate compliance with those feature requirements.
Documented and formalized hand-offs and sign-offsLast but not least, any
process should include some formalized authorization procedure to establish accountability for the delivery of the system from development to quality assurance (QA), and from QA to production, and ultimately to the user community at large. As part of the investigations and to better understand how a business operates, auditors ask questions about your software development practices. Here are some examples of the types of questions that are asked: Which compliance requirements were delivered in release x? Does the application fulfill compliance requirement x? Who signed off on this project at design and deployment? Who approved funding for this project? Which projects will reduce compliance risk? Can you confirm that all of the components are in the release? Can you confirm that the software developed was actually deployed? Who made changes to the manufacturing application? Regular inspections should be anticipated and will likely be scheduled to evaluate your level of compliances.
12
If companies view the new laws as opportunities opportunities to improve internal controls, improve the performance of the board, and improve their public reporting they will ultimately be better run, more transparent, and therefore more attractive to investors.1
William Donaldson former SEC Chairman
CONTROL
Unreliable Survive
BUSINESS PERFORMANCE
Thrive
Often, companies are initially interested in complying with the mandates only, but quickly recognize the opportunity for improving their processes and eventually transforming their enterprises to gain competitive advantage. Meeting regulatory requirements is more than an obligationit is also an opportunity to improve an organizations software development transparency, oversight, and results. The implementation of a sustainable compliance architecture typically replaces ad hoc or undocumented development processes with a more structured software development process. They can also capture the project meta-data and metrics that will enable organizations to realistically assess current practices of the software development organization and iteratively improve either the practices or their execution. In addition, reducing compliance risk is the first step toward establishing a strategic framework for IT governance to improve visibility over IT investment. Over time, the value that good IT governance can deliver continually increases. IT organizations can start out managing risk and monitoring remediation projects. Then, by automating development workflow, companies can make the best practices operational and finally optimize their execution to enable true business transformation for the enterprise (Figure 1-5).
13
Reducing risk is the first step toward establishing a strategic framework for IT governance.
IT Executive
Manage Risk
Prioritize Compliance Initiatives Evaluate and Mitigate Risks
Time
Figure 1-5 Compliance: foundation for good IT governance
14
Regulations
Patriot Act HIPAA DoDAF Basel II FEAF CFR 21 Part 11 FDA CoBIT RUP ITIL SOX
Standards
CMM Six Sigma ISO 900x CMMI ISO 17799
An ITG Process Solution
In addition, process standards seek to embody the fundamental philosophy of current good systems practices and quality-by-design as integral parts of business operations. This is essentially what auditors and inspectors are seeking during an inspection. Businesses are looking for a mechanism that will assist them in achieving their compliance objectives while simultaneously improving their overall capacity to produce products and services. Rather than reinvent the wheel, most businesses turn to emerging process standards as a solution. By integrating regulations and standards, organizations can formulate comprehensive IT governance solutions. Often auditors state that it does not matter so much which framework you choose, as long as you document which one you are using and why. In practice, large organizations implement a mix of these frameworks, drawing from IT Infrastructure Library (ITIL) and Control Objectives for Information and related Technology (COBIT), for example. There is often a layering of these frameworks, such as organizations who adopt the ITIL to govern their operations environment, COBIT to manage their IT governance efforts, and the Capability Maturity Model (CMM) implementation to govern their software development organization. As an example, SOX does not mandate use of a particular internal control standard or framework, but most companies adopt one or meld them together to come up with framework that fits their needs.
15
COSO
Committee of Sponsoring Organizations of the Treadway Commission (COSO) is a voluntary private sector organization dedicated to improving the quality of financial reporting though business ethics, effective internal controls, and corporate guidance. Formed in 1985 to sponsor the National Commission on Fraudulent Financial Reporting, COSO is jointly sponsored by the five major financial professional associations in the United States. Commission members (wholly independent of each sponsoring organization) contained representatives from industry, public accounting, investment firms, and the New York Stock Exchange. COSO promotes consistent risk and control consciousness throughout the enterprise and common models for discussing and evaluating risk and internal controls. To learn more about COSO refer to:
http://www.coso.org
COBIT
Control Objectives for Information and related Technology (COBIT) helps meet the multiple needs of management by bridging the gaps between business risk control needs and technical issues. COBIT is built in part upon the COSO framework and provides good systems practices across domain and process framework and presents activities in a manageable and logical structure. It also serves as an independent yardstick for assessing performance. COBITs framework principle is to link managements IT expectations with managements IT responsibilities. To learn more about COBIT refer to:
http://www.isaca.org/Template.cfm?Section=COBIT6&Template=/TaggedPage/Tagge dPageDisplay.cfm&TPLID=55&ContentID=7981
16
ITIL
Information Technology Infrastructure Library (ITIL) is a library of books that describe best practices for infrastructure management. ITIL is a registered trademark of the U.K. Government's Office of Government Commerce (OGC). ITIL is a framework and the models show the goals, inputs and outputs, and general activities of the various processes. Some of the most popular books for ITIL are: Service SupportProcesses required to support IT services Incident management, problem management, configuration management, change management, release management Service DeliveryProcesses required to deliver IT services Service level management, financial management for it, capacity management, service continuity management, availability management To learn more about ITIL refer to:
http://www.itil.org/itil_e/index_e.html
SPICE
Software Process Improvement and Capability dEtermination (SPICE) is a major international initiative to support the development of an international standard for software process assessment. The project has three principal goals: 1. Develop a working draft for a standard for software process assessment. 2. Conduct industry trials of the emerging standard. 3. Promote the technology transfer of software process assessment into the software industry world-wide. The benefits for the software industry are supposed to be: Software suppliers will submit to just one process assessment scheme (presently numerous schemes are used). Software development organizations will have a tool to initiate and sustain a continuous process improvement. Program managers will have a means to ensure that their software development is aligned with and supports the business needs of the organization.
17
The hoped-for benefit for the purchasers of software is that purchasers will be able to determine the capability of software suppliers and assess the risk involved in selecting one supplier over another. To learn more about SPICE refer to:
http://www.isospice.typepad.com/isospice_spice_project
ISO 900x
International Organization for Standardization (ISO) is one of the first process standards to be applied to software. It previously mainly applied to manufacturing processes. IT departments are often required to comply as a result of organization level commitment to ISO 900x. The ISO 900x:
Measures the degree to which an organization says what they do, and does Examines the ability to closely follow documented process Does not necessarily imply that those processes are any good A total quality management (TQM) approach: Great for organizations that repeat the same thing with little variation Assumes risk and quality can be controlled by repetition
Six Sigma
Six Sigma is a statistical concept that measures a process in terms of defects. It is also a methodology consisting of phases, tools, and techniques that improves an organizations processes in a way that can measurably impact customers and the bottom line: Six Sigma represents the chance that the measured value of a specified item is outside acceptable customer tolerances: Defined as <= 3.4 deviations per million opportunities to measure (DPMO) 99.99966% pass rate (sometimes known as 5-nines quality) Six Sigma is also a business philosophy with a goal of continual process improvement to reduce the costly defects that exist inside an organization. Six Sigma projects follow a life cycle that is designed to ensure that an organization does not jump straight to a solution without first understanding the underlying problems, processes, root causes, and supporting data.
18
There are three process variants: Define, measure, analyze, improve, control (DMAIC) is used to improve performance with existing processes. Design for Six Sigma (DFSS) is less widely used and has no universally accepted life cycle. Define, measure, analyze, design, verify (DMADV) is the most common variant used for process definition. Some of the main terminology and concepts in Six Sigma are:
Black belt certified Six Sigma is a subject matter expert who mentors or
manages Six Sigma projects.
Tollgate is a formal checkpoint between phases of the methodology. Quality audit is a scheduled review of process and project.
To learn more about Six Sigma refer to:
http://www.motorola.com/motorolauniversity.jsp http://en.wikipedia.org/wiki/Six_sigma
CMMI
Capability Maturity Model Integrated (CMMI) is a framework that describes the key elements of an effective software process. CMMI provides an evolutionary improvement path from an ad hoc, immature way of doing business to a mature, disciplined, controlled process. CMMI guides software organizations that want to gain control of their activities for developing and maintaining software and to evolve toward a culture of software engineering and management excellence. The success of the Capability Maturity Model (CMM) spawned a number of other engineering-related process improvement models, such as CMMI. CMMI was developed at Carnegie Mellon Universitys Software Engineering Institute (SEI). The development of the CMMI was sponsored by the U.S. Department of Defense to provide a means for assessing the capability of software development organizations working on Department of Defense contracts. Since then, the government has reduced its funding to a small fraction because the private industry has recognized the return on investment (ROI) potential.
19
CMMI provides a model that can be applied consistently across many parts of an organization, lowering cost for training, implementation, and assessment, as well as reducing redundancy and complexity. CMMI has five levels of maturity: 1. InitialThe software process is characterized as ad hoc, and occasionally chaotic. Few processes are defined, documented, or used consistently. Success depends on individual effort and heroics. 2. ManagedBasic project management activities are established to plan and track cost, schedule, requirements, and changes. Sufficient process discipline is in place to document and repeat earlier successes on projects developing similar applications. Documented processes are used on all projects, though each project may use different processes. Basic measurements are collected and used to manage projects and process improvement. 3. DefinedProcesses for both management and engineering activities are documented and integrated into a standard, tailorable software process for the organization. All projects use an approved, tailored version of the organizational software process for developing and maintaining software. More sophisticated measurements are collected and used to manage projects and process improvement. 4. Quantitatively managedBoth the software process and work products are quantitatively characterized and controlled. Measurements of software process performance and product quality are collected and used to quantitatively manage projects and improve processes. 5. OptimizingContinuous process improvement is enabled by quantitative feedback from repeated process execution and from piloting innovative ideas and technologies in response to changing business drivers. Processes are statistically controlled and include defect prevention measures. Studies show that less that 5% of organizations are rated at level 4 or 5. To learn more about CMMI refer to:
http://www.sei.cmu.edu/cmmi/cmmi.html
RUP
The Rational Unified Process (RUP) is a framework for improving software development effectiveness that helps: Enable organizations to achieve better results more predictably. Provide a set of proven practices for improving effectiveness. Link development activities to delivering stakeholder value.
20
Reduce cost of improving effectiveness by leveraging the successful experiences of others. Figure 1-7 shows the RUP framework.
Time
The time aspect of the process is enacted through phases (Table 1-1), iterations, and milestones (end of phase objectives). Progressing by meeting milestones helps minimize wasted resources because they are allocated only on a firm basis.
Table 1-1 RUP phases
Phase
Inception
Objectives Mitigate business risks; gain agreement on overall scope. Vision, high-level requirements, business case
Elaboration
Mitigate technical risks; agreement on solution approach. Baseline architecture, most requirements detailed, high-level design
Construction
Mitigate logistical risks; apply approach. Working product, system test complete
21
Phase
Transition
Objectives Mitigate deployment risks; roll-out solution into production. Stakeholder acceptance
The phases of RUP were chosen such that phase boundaries correspond to significant decision points in the life of a project. For example, at the end of inception, enough work has been done to capture the problem to be solved, and a vision of the system has been developed. An initial set of risks has also been identified and evaluated. Based on this information, a decision is made whether to fund the project. Similar decision points correspond to the end of elaboration, construction, and transition. Milestones help you to assess the progress of a project at key points. Management can use these to establish clear criteria from which to decide the course of a project. They provide opportunities to change course. Phases contain iterations that yield executable results. To learn more about RUP refer to:
http://www-306.ibm.com/software/awdtools/rup/
22
Risk Officer / Analyst Complexity of tracking and managing multiple, multi-year remediation efforts Poor visibility into project status Negative ROI impact
Overwhelming complexity Continuous change and reinterpretation Poor enterprise visibility Accelerating cost pressure
IT Management Lack of domain expertise Cost and time-to-market pressure Burdensome documentation requirements Negative impact on productivity
Development Team
Figure 1-8 Challenge for compliance: visibility and cohesion across domains
Compliance, however, is an ongoing process and one that companies must come to terms with by establishing appropriate controls and automation in order to make compliance a productive and value added process. Tools that bridge the gap between the varying roles of the organization and facilitate information sharing and communication are necessary to make compliance something that provides benefit to its participants. Other challenges are in the areas of:
SecurityWho can access artifacts? Are the roles valid? Are the employees in the roles? AuditabilityWho made changes to artifacts? Are they authorized? Can they
be tracked?
Data and application accessAuthorization, execution, acceptance Monitoring of applications in productionOperation changes/authorization,
exception handling/tracking
23
Content/records management and document management strategies not keeping up with heightened demands Dependence upon spreadsheets Loose off the ledger audit trails (insufficient documentation, data consistency, and controls), especially on software development processes and packaged application customization processes An example is lack of a process in place to track that functional requirements are implemented in the applications that automate business rules. Lagging IT infrastructure Unclear accountability structures Lack of compliance policy for the retention of key information and process controls when operating the business Limited ability to ensure proper destruction Inability to prove records were not falsified Unable to quickly and easily retrieve records upon request Storage media may be inappropriate for retention needs In addition, here are some examples of the types of compliance concerns that may be expressed. They are shown in no particular order or priority. It is important to note that this list is not exhaustive, as it will vary from problem domain to problem domain: How can I manage the multi-year effort required to implement the regulatory changes across all of my systems, controlling the costs, budget, delivery, functionality, and integration of all of my systems? This is a complex problem requiring portfolio management expertise, integrated with program and project management. How will I demonstrate a linkage between the business processes I develop and the rules that my processes satisfy? Auditing specialists are continually looking for something that ties the business back to the language of the legislation, regulations, standards, or policies. This is often accomplished through the use of a document or position paper that describes a plan for achieving compliance. The reality is that many times these documents are drafted and forgotten, particularly on initiatives that run longer than six months. How will I document my existing business processes and systems as they are implemented today? Certain legislation demands that executives have a full accounting of how the business operates. As a component of any remediation effort for a business, it
24
is now necessary to document how the business operates, and where the key points of control exist. Auditors and inspectors can ask you how you did things before you changed them. Auditors and inspectors are also keenly interested in demonstrated control over changes to the business. They will want to see that you have a process for modifying business operations and automation. How will I assess the compliance gap between my current business operations today and where I want to be tomorrow? To transform the business, one has to leverage the As-Is model of business operations into a To-Be model that fully complies. However, one cannot blindly construct a compliance process without having a rudimentary understanding of what the costs of changing the business processes will be. How will I transition my automated systems from their existing implementation to a new implementation? To achieve compliance, it is often less expensive to replace an existing system than to redesign the old system for something it was never intended to do. Gap analysis has to be performed between these older systems being replaced, and the newer systems you may be considering. Homegrown systems that provide competitive advantage may have to be redesigned. Finally, you will have to reintegrate your newly selected systems to your existing systems or modify the functionality of your homegrown systems to close the loop. How can I demonstrate that the business processes I have employed are actually being adhered to as documented? Although the executive committee defines how things are done, someone has to monitor the business to ensure adherence to new operating rules. Auditors will be seeking evidence that the newly defined rules have been implemented. Simple implementation of appropriate measurements and metrics can solve this problem easily.
25
Maintenance of COTS customizationsManagement of commercial off the shelf (COTS) applications is just as important from a compliance standpoint as green field systems development.
In many cases the applications created today are acts of aggregation more than acts of creation. Significant work must be performed to understand the gaps between the needs of the business, the capabilities of the products under consideration, and the performance and procedural requirements that must be satisfied.
26
27
28
Chapter 2.
Compliance guidelines
In this chapter we discuss the relationship between compliance management and the software development process, and the importance of having a compliant software development process to achieve a solution for compliance. We examine the desirable features of a software development processes and we introduce some of the key considerations when examining compliance processes. Finally, we analyze practical control strategies for enforcement of the software development process.
29
30
auditor must evaluate the integrity of processes used for the implementation of these business rules and policies, and must be concerned with the software applications that support these business transactions. In this sense, compliance with regulations, standards, and policies quite naturally leads to business application compliance. Compliance audits are thus redirected to software applications and packaged application customization. Businesses may recognize the need to carry an inventory of their systems, to be able to determine which systems may be impacted by change in regulations, standards, and policies. We will explore this idea a little further in a subsequent section on governance of software development. There is added complexity to this problem to be considered. The systems for which a business has no source code, nor the ability to modify a packaged application, must still comply. Furthermore, consider the need to implement manual business processes that institute checks and balances against business decisions that are recorded in an automated system. These controls must be accounted for as well.
Governing the business process of software and systems development, by Murray Cantor and Rachael Rusting, IBM Corporation, Liz Barnett, EZ Insight Inc.
31
The purpose of good software development governance is to address these goals: Define and implement a structure within which to execute organization management and administration. Provide active direction, periodic review of interim results, and identification and execution of adjustments to ensure achievement of the planned outcome (which contributes to the success of the overall business strategy). These goals are achieved through a combination of the right personnel, an effective structure for management and oversight, and a set of program roles and responsibilities. It also requiresas our previous general definition of governance outlinedappropriate measurement and control mechanisms to empower people to monitor and improve the process. Roles and responsibilities should be defined and structured with the required outcomes of the organization in mind, and to fit within the management philosophy and enterprise approach. Thus, each person is invested in a role and must have a clear understanding of the decision rights, responsibilities, and objectives assigned to them by management, and the relationship their role has with all the other roles within the organization. The concept of governance has multiple business and governance components (Figure 2-1):
People empowermentIt is necessary to have a clear and well-understood assignment of people to specific roles. This is not to say that a given individual cannot function in multiple roles, provided that the responsibility of these roles do not conflict. Structure definitionEstablish clear chains of responsibility and
communication to facilitate development coordination.
PolicyIt is essential to define, document, and clearly communicate management principles and decision-making criteria. MeasurementIt is essential to ensure that appropriate measures are placed throughout the process at multiple levels, in order to evaluate the effectiveness of the structure, process, product quality, and alignment of the process to organizational goals:
Organizational measures should evaluate items such as estimation maturity, value creation, and development maturity. Project or program measures should evaluate items such as results, variance reduction, program or project financials, and product quality.
32
Business
Roles in structure People
Policies
Governance
If this is what governance is, then what is compliance? Here is our rather pragmatic definition: Compliance is the set of deliverables, processes, and documentation necessary to satisfy a company's interpretation of a given regulation, standard, or policy. Why does our definition contain the company's interpretation of a given regulation, standard, or policy? As we have stated earlier, many of these rules are non-directive. In other words, they contain no actionable plan for a company to follow. Consequently, the companies are forced to interpret these rules and devise their own action plans. These action plans are actually a minimalist form of governance. The reality is, that to implement compliance well, companies should utilize good governance first. Good governance ensures the establishment of consistent process, decision rights, and authority with which to conduct business, as well as the necessary measurements and controls required to track the process and improve its operation and product outputs. After all, what is the first thing an auditor or inspector asks for? Your procedures.
33
needs, implementation of such packages is a form of governance and compliance over the process that you want to automate (or that is automated in the case of package replacement). After all, the criteria typically contained in a request for information or proposal (RFP or RFI) for the selection of such packages is often driven by the need to ensure alignment between the organization's existing process and the behavior of the package. In the case where no package exists to meet these criteria, companies will develop their own package to address the appropriate business need. Incidentally, the RFI/RFP process is in itself a governance of acquisition process. However, this is not software development governance. This is a form of governance over the business process that the package satisfies. Software applications can be the basis of organizational business activities. Through such an approach the company aims to enforce business policies into organizational activities, to control the execution of these activities, and to review the results. You can see the similarity between this and the previous definition of governance that outlines chains of accountability, responsibility, measurement, and control. Using information technology components (applications and tools), organizations can automate policy enforcement tasks and facilitate control and review tasks easier, faster, and less expensively than using a manual process. Compliance is also a business requirement that is often a criteria found in RFPs and RFIs, because it is the intention of the organization to enforce regulations, standards, and policies, and to establish controls associated with them using an automated mechanism that also reduces compliance cost. Information technology applications allow organizations to: Enforce policies in application processes, including those related to regulatory compliance. Establish control mechanisms throughout applications processes to guarantee conformance. Facilitate information recovery and report generation to help management oversee and gather information needed to demonstrate compliance. Share integrated information among all involved roles to consistently distribute data across the organization. Ensure information security issues, control access rights and information confidentiality. Automate tasks to reduce cost and reduce the likelihood of human error.
34
Hopefully, you should now see the similarities between packaged application implementation, software development governance, and compliance. If so, then you understand why we advocate for the use of formalized tools and processes for software development governance. We make this distinction now, because you cannot implement compliance well without some governance. Therefore, when we outline our solution for compliance, you will understand why our process includes some process design components from governance, in addition to documentation, artifact tracking, and accountability as in compliance. Figure 2-2 shows our area of interest, which is compliance-driven development, and those parts of business controls and IT governance related to software development.
Business Controls Automation Business Controls & Reporting IT Governance Compliance-Driven ComplianceDevelopment
Workplace Business Controls and Reporting
CFO
Govern IT assets
Security/ Identity Information Management Manage data privacy, access, and integration
IT Controls Automation
35
Facilitate information extraction related to the demonstration of compliance. Gather sufficient information to respond to internal controls and auditors demands. Attend to compliance cost reduction, based on best practices and supported tools.
INTERPRETATION REGULATIONS
COMPLIANCE REQUIREMENTS
36
During an audit it may be necessary for such a business to substantiate that it has taken appropriate action in the implementation of corporate policy to respond to a given regulation or act. Based upon requests from auditors or inspectors, the organization may have to demonstrate that appropriate controls have been implemented, by following the chain of traceability from corporate policies to structured application requirements (that is, traceability from corporate policies to software artifacts) (Figure 2-4).
Corporate Compliance Corporate Corporate Policy Policy Documents Documents Software Development Compliance Structured Structured Application Application Requirements Requirements Software Software Artifacts Artifacts
LOB Compliance Business Business Process Process Guidelines/ Guidelines/ Standards Standards Application Application Guidelines Guidelines & Standards & Standards
TRACEABLE
It is important to note, however, that implementation of such traceability is not sufficient. Auditors and inspectors are also just as concerned about how the artifact chain of traceability was established. Thus, software development governance is designed to ensure that the process is followed and that all actions are recorded to substantiate compliance. A compliant software development process should institute good governance practices in order to enforce proper authorization points and execution of the critical controls with the process. See Points of control on page 46 for a more detailed description.
37
Examples of the type of data to be recorded include items such as: Who did what activity and when it was done The action that changed the record and its final state The name of each changed field, its old value, and its new value Deltas for multi-line text edits Reason or explanation of change
38
Loss of productivity due to overhead introduced by the additional process constraints Increased backlog of transactions impacted by the process change Degradation of morale among those with excessive workloads Failure to completely follow the prescribed process as documented Bypassing of the documented process, threatening the integrity of the established controls Naturally, these costs impact all areas of the business, including the software development process itself, and potentially the integrity of the controls implemented. One should consider the documentation of the process as only a first step. If implemented properly, compliance can actually lower overall operational costs by streamlining business operations, ensuring complete control over the task, establishing accountability for product or service quality, and automatically establishing artifact traceability and metrics gathering. In order to reduce these process costs, two main items should be considered (Figure 2-5): Adoption of best practices in the target domain Use of automated workflow, also known as tool-directed behavior (TDB)
39
40
Tool stack integrationTo reduce the risk of inconsistent artifact linkage across the development domains and to provide common access to all development assets, it is desirable that the tools are designed to interact directly with each other. ConfigurableTo enforce software processes and minimize the overhead of
manual execution of control tasks, the tools should be configurable to match your commercial method or in-house method design.
FlexibleThe stack of tools should not create constraints on the process design due to limitations in process support. Traceability and reportingThe tools should provide the ability to
conveniently expose the chain of traceability or the metrics associated with evaluating program or project quality.
41
Separation of duties
When constructing a robust process, in a set of related activities, separation of duties is a policy that consists of assigning responsibility to different people for each major activity in the flow of execution. That is, each critical activity must have a different person responsible for the creation or approval of a given
42
artifact. Consequently, use of authentication is an unavoidable matter to be implemented in the separation of duty policy. Common uses of separation of duties policy include: Assure that no important activity can be bypassed in a process. Mitigate the risk of consecutive errors in process execution.
Approvals
Approvals ensure that specific actions that occur throughout the process are appropriately sanctioned. Approvals are put in place to prevent the introduction of unapproved changes in the target business system or software, and thus ensure accountability. Approvals are also required from a business perspective to allow the execution of IT-related projects at the portfolio level. The term used to describe this accountability is non-repudiation. In other words, the elevated accountability through approval eliminates the possibility that someone may repudiate or deny having authorized one or more activities throughout the process. These approvals may be paper-based, or electronic, utilizing handwritten or digitized electronic signatures or perhaps a simple and unique user ID and password combination. Each organization has to define and tailor the approvals to align with the compliance requirements of the development or portfolio management process. Approvals may be added or removed in accordance with the organization policies. We can differentiate between two kinds of approvals: Financial approvalsThese approvals are related to funding. Technical approvalsThese approvals are related to the design or construction of a system.
Financial approvals
Financial approvals in the software development process may seem foreign to some, but may be a necessary component of a compliance process to substantiate due diligence in the eyes of an auditor or inspector. The reasons for this tie back to our earlier discussions regarding demonstration of intent. Funding may indicate the level of executive and management commitment to a compliance effort. Organizations implementing appropriate governance processes for changes to information technology infrastructure recognize the need for prioritizing requests for these changes. Furthermore, implementation of a comprehensive approach to managing these requests improves the likelihood that the organization will receive a good return on investment related to these expenditures.
43
Earlier we established that the need to implement new processes and business controls in response to changesparticularly if these controls are automatednecessitates the need for modifying several business systems simultaneously. Because the impact of changing multiple systems concurrently is likely to have a significant impact on the business, a careful accounting of cost, schedule, and effort must be an integral part of the systems management process. Ideally, this process should begin by evaluating the systems inventory. The processes should also include an estimation of time, effort, and cost by constructing project plans based on previous experience in implementing similar changes to the impacted systems, and based on complexity and current good practices utilized by each organization performing the changes. The combined assessment, along with these estimates, can then be evaluated together to present better information with which to make decisions about which systems to modify and when. Through the implementation of such a process, organizations ensure that they are adequately prepared to demonstrate compliance or, if remediation is needed, intent to take corrective action, or at least demonstrate the reasons for the pace with which adoption is proceeding based on currently available resources, schedule, and effort.
Technology approvals
Technology approvals are typically performed after the approval of funding and the initiation of a systems modification effort. These controls are implemented to ensure that adequate technical oversight was applied to the implementation of automated business controls, and to ensure alignment of these controls with the strategic direction of the application to the those of the business. For example, a technical reviewer may examine whether the solution for a business control is designed to conform the organization's technical standards for service publication, if the component is part of a system design with service-oriented architectural style.
44
The audit trail description for CFR Title 21 Part 11 includes: Who changed itIdentifying information for the person who performed the modification to the electronic record. When it was changedInformation describing the date, time, and time zone of the change. What actionThe action that changed the work product and the process state. What fields were changedDelineating the name of each field modified including its old and new value. PurposeSome people even believe this requires an explanation of the reason for the change to the work product. When utilizing such audit trails it is presumed that this information is never deleted. Because the nature of creating such audit trails is tied to an appropriate good electronics records management strategy, audited work products can never be directly deleted. Typically, systems implementing solid audit trails implement a strategy where an entry is made against the record indicating that a work product is flagged for deletion, and will subsequently be deleted in accordance with organization policies regarding record retention periods.
Electronic signatures
Electronic signatures, also known as e-signatures, provide approval capabilities for automated tooling environments. The purpose of an electronic signature is to implement an approval that will be made by one or more authenticated users with the intention of replacing a handwritten signature. The three predominant mechanisms acceptable as an e-signature mechanism in use today include a unique user ID/password combination, biometric authentication (such as retinal scan, or thumb print mapping) or digitized signature analysis. In all three cases, the intent of an electronic signature is to validate the credentials of the signer, and to ensure non-repudiation of any artifacts created, modified, or deleted by the signer. Non-repudiation is the term used to indicate that it is not possible for the authenticated user to refute performing the recorded action against the electronic record or work product.
45
Typically, customers will look to identity management solutions that provide a single point of authentication for the enterprise. Such identity management systems should provide the ability to grant, manage, and enforce user access permissions, implement a standardized recertification process (to validate each user account is still needed for a valid business purpose), and the ability to quickly produce reports to help speed the preparation for internal audits. Many of the identity management solutions available today are extensions to the open standard of the Lightweight Directory Access Protocol (LDAP). LDAP is an industry standard protocol used for accessing and managing information directories. Using LDAP, users can search for e-mail addresses and other information in a directory service and also update that information. One or more LDAP servers contain the data making up the LDAP directory tree or backend database. The goal of identity management solutions is to protect sensitive information and prevent that information from unauthorized access.
Points of control
The purpose of implementing workflow is usually to ensure that those who participate in its execution conform to the various steps to produce output of consistent quality. As an additional mechanism to ensure accountability of product quality approval and gating procedures can be installed in the workflow throughout. These gating procedures typically require an inspection step, whereupon the reviewer is required to indicate his satisfaction or dissatisfaction with the produced output. These control points are key events in the development workflow, where an action of approval has to be taken to allow the process to continue. Careful consideration must be given to several items simultaneously when building an automated workflow solution. These considerations must include the establishment of those roles that participate in the workflow, the decision rights each role will be granted, and the points in the workflow where sufficient data is available with which to make a determination of the output quality.
46
auditors in an easy-to-read and portable form. Reports are also essential for management to quickly assess issues and identify appropriate actions under changing business conditions. Once issues are identified, reports are also useful for monitoring the results of decisions and consequential activities taken. As a consequence, by having relevant reports on-hand, organizations can expect that the time required to complete an audit may be shortened. To ensure that these documents and reports are timely, several actions should be taken from a governance or process perspective. In most cases, work products created during software development activities can be documented through the use of automation, by leveraging the artifact definitions contained within their design tools and repositories. Automated documentation generation tools, which have the ability to reach into such repositories, can create robust and fully formatted reports containing even greater, painstaking detail than any human might wish to pursue. Documents or reports regarding the governance process itself, or those related to business transactions, will have to be retrieved and generated from the related transactional systems under scrutiny by the inspector or auditor, in the same manner. The second action that teams should consider is the institution of scheduled generation of these types of reports, with consistent archiving based upon aging. When implementing such an infrastructure, consistent and timely information can be on-hand, even in the event of a surprise audit. You should also keep in mind that these types of reports and documentation also have to be retired, based upon your company's records retention policy.
Metrics
As Lord Kelvin once said, If you cannot measure it, you cannot improve it. However, as many experienced scientists know, the moment you start observing or measuring something is the same moment that its behavior begins changing. As humans beings, we are very much influenced by both positive and negative feedback. Consequently, once you establish a set of criteria by which you will begin measuring a team, that is the moment their behavior is likely to change. Formally metrics are numbers used as a measurement for comparing different items for trend, distribution, and aging analysis. The main objective of metrics is to enable management to take corrective action in the execution of a given process, based upon information about the quality of the product or service, or regarding the execution of the processes that actually produces or manages the given product or service.
47
Metrics share a common set of desirable characteristics: Must be simple, objective, easy to collect, easy to interpret, and hard to misinterpret Must be automated and non-intrusive to minimize interfering with other project activities Must contribute to take fast corrective actions, when actions can be more effective Must be consistent and expressed in some absolute value
collected
Tools
calculated
The term measures is used to describe metrics primitives. In other words, measures are metrics used to calculate other metrics. These measures are raw data and are usually obtained directly from the tools that support processes, or from the tools that are used to generate work products. Primitive metrics cannot be interpreted in isolation. The term metrics is used for measurable attributes of entities, where each metric is made up of one or more primitive metrics and can consequently be evaluated alone or in conjunction with other metrics. During the process of metrics selection, each organization decides what goals and objectives will be monitored during the measurement process. Utilizing the agreed upon goals and objectives, appropriate measures can be selected with
48
which the metrics are derived. Be careful not to select too many measures, or to select measures that are unfitting measures to observe behavior from an organizational perspective to be of value. In other words, measures should be placed at the organizational level to monitor the governance process itself. Measures should be implemented at the program or project level to monitor software development process conformance, and at the artifact level to monitor product or service quality levels. Finally, be careful not to take unnecessary metrics. Collecting a large number of metrics is likely to be a waste of time because of the effort typically required to collect, process, and store the raw measure data. A minimal set of more extensive and simple metrics is preferred. A reasonable set of measures reduces the effort of collecting measurement data while still delivering the same level of benefit. A good rule of thumb allows no more than four to five metrics, with appropriate measurement data to support them.
OrganizationalExamples of organizational metrics are those related to manage cost and improve organizational performance, reduce risks, and manage business compliance. ProjectExamples of project metrics are those related to being able to
manage functional and non-functional capabilities, and technical, budgetary, and scheduling constraints.
TechnicalExamples of technical metrics are process-related and product-related metrics that contribute to project-level metrics, but are at a lower level and more useful in the technical analysis or product quality, typically supporting technical personnel.
For more information related to metrics and measurements refer to: Rational Unified Process (RUP)
http://www-306.ibm.com/software/awdtools/rup/
49
50
To illustrate this range of operational tolerance, we look at two common relevant considerations related to compliance: security and process (Figure 2-7).
Process Intensive High Ceremony
Process-driven Workflow Many points of control Detailed audit package Detailed traceability matrix Process-driven Workflow Many points of control Detailed audit package Detailed traceability matrix
High Trust
points of control lack e-sig authentication shared access to artifacts Ad-hoc workflow Few points of control Forensic documentation High-level traceability
High Security
Points of control validated with e-sig Access on a need to know basis Ad-hoc workflow Few points of control Forensic documentation High-level traceability
51
ceremony is encouraged and enforced. In such conditions it is often difficult for all members of the team to communicate regularly. Consequently, institution of very formalized and ceremonious processes ensures that product quality is high through the use of formalized process-based checks and balances. In this way, high ceremony processes protect stakeholders, but increase cost considerably.
General strategy
One possible approach to implement a compliant software development process is based on the five-step flow of activities (Figure 2-8).
52
53
54
Change requestsChange requests are child records to releases and serve to track related activities that must be completed together to support some delivered application functionality. For example, a particular application may have both a Motif and Windows client. However, the change request will not be considered complete until the functionality has been implemented for both interface types. ActivityThe activity record gives team leaders and release managers the ability to assign related, but dissimilar tasks to different developers, while tracking the delivery of functionality through the change request record. Ideally, these activities should be used through an integration with the configuration management repository, thus linking all code modifications for each activity to all versions of code modified to implement a feature or application fix. DeployThe deployment record type is used to manage the movement of
application release builds for each operational environment to the next. One example of such a movement would be the approval of movement of code from the development environment to the quality assurance build area on a certified build machine. Naturally, your organizational procedures may be different, perhaps permitting a copy operation of built bits from the development environment into the quality assurance area. Refer to Figure 2-9 for the details regarding the actual steps. The three control points are explained in the sections that follow.
55
Change Request
Submitted
Assign
Activity
Submitted
Assign
Deploy
Submitted
Assign
Assigned
Open
Planned
Complete
Assigned
Open
Assigned
!2
Working
Open
Working
Complete
Completed
Verify
Opened
Complete
Complete
Completed
Verify
Completed
Approve
Tested
Release
Completed
Deploy
Verified
Release
Approved
Deliver
Released
!1
!3
Deployed
Close
Released
Delivered
Closed
56
Responsibility Ensuring that all configuration items are included for the application to function in a test or production environment. Primary source change approver. Creates and assigns UCM activities. Creates deployable objects and the appropriate deployable baselines.
Integrator
Creates and maintains all scripts necessary to build an application for use. Performs controlled builds for one or more applications. Deploys configuration items from controlled sources to the various environments used to test an application or into production itself. Representative from the quality organization responsible for verification of one or more applications.
Release manager
Tester
Controls the approval or rejection of a release package in the appropriate quality states. Approval is required before any release package can be moved into a production environment. A primary user of the solution, this role is responsible for making changes to code and assuring the level of quality of those changes. Relies on the solution for version control and workflow enforcement.
Implementer
Participates in design activities and constructs, tests, and documents application configuration items.
57
58
Chapter 3.
59
60
CFO
Govern IT assets
Rational Portfolio Management, Tivoli Business Systems and Service Level Management
Compliance-Driven ComplianceDevelopment
Security/ Identity
IT Controls Automation
Figure 3-1 IBM Rational: a modular solution for reducing cost of compliance
61
requirements (for example, in the translation of regulations into business policies). This is a very important step, as it is likely that changes in company policy will affect the customer's business and any actions the customer may have to take to comply with the law. After identifying policies and procedures designed to address compliance concerns, a company may begin appropriate projects to implement the policies defined. These projects might be related to manual control implementations, sales force training, systems development, and changing or implementing new requirements on existing systems. Once a company has established its policies, IBM Rational can assist the customer with the automation of those policies through several automated mechanisms contained within the IBM Rational Business Driven Development for Compliance solution. Consequently, the scope of this book is limited to business the driven development for compliance capability offered by the IBM Rational brand with a light treatment regarding those components of the solution outside of the brand offerings. So let us review what we have established thus far. Compliance requires both manual and automated business controls over the application portfolio, as well as the software development life cycle to address three main capabilities:
62
The specific components of the general solution that support audit, traceability, and workflow enforcement are shown in Figure 3-3. Notice that the key components used to manage business controls and reporting include Workplace for Business Controls and Reporting (WBCR), and those for IT governance include Rational Portfolio Manager (RPM). These components facilitate the management of the artifacts used for tracking regulations, standards, policies, and other business risks, demand management, resource management, project proposal tracking and workflow, balanced scorecard design and evaluation, project tracking, and cross organizational coordination.
Business Controls Automation Business Controls & Reporting IT Governance
Workplace Business Controls and Reporting
CFO
Govern IT assets
Rational Portfolio Management, Tivoli Business Systems and Service Level Management
Compliance-Driven ComplianceDevelopment
Security/ Identity
CIO
IT Controls Automation
The components in the upper two layers of the IBM BDD for Compliance solution benefit customers with the following: Control principles that ensure appropriate capture of evidence of due diligence Tools to automate these principles and provide traceability across development artifacts Services to customize the BDD process such that it applies these principles to conform to the organization's existing environment These components are combined to address compliance issues and needs through IBM BDD features (Figure 3-3).
63
Compliance Risk
Policy Documented Process Automated Procedures Demonstration Of Control Proof of Due Diligence
Business Response
IT Response
BDD for Compliance Solution Support RUP and/or Customer Methods Rational Tooling Say what you do Do what You Say
Plan
Software Business Procedures Methodology Business Development Tool Applications Directed Behavior Business Transaction Data Business Reports
SDG
Define
Enable
Dev Project/Tools Automated Artifact Traceability Artifact Linkages Measurement Plans Project & Process Analytics Reporting Be able to Prove it
Measure
Some of the most commonly desired information for an audit is listed here: Documented software development life cycle (SDLC) processes for creation of all business artifacts Adherence to the defined process by artifact creators/SDLC compliance Linkages between supported tools using tool-directed behavior Process linkages to automated processes supported by tool mentors Linkage between artifacts that align with the business process steps Artifact traceability to points of accountability in the delivery chain Transparency of reporting Accountability in the chain of delivery Non-repudiation of any artifact throughout the system Evidence of SDLC process maturity and stability Documented test results requirements linkage Documented and formalized handoffs and signoffs The following are the key capabilities of the IBM BDD solution that make it possible to gather the proof necessary to substantiate compliance. They are delivered through the application of both the principles and the tools: Life cycle requirements traceability to help auditors verify that compliance requirements were accurately captured and implemented in key applications
64
Auditable workflow management capabilities that help ensure and document that all software changes were made by authorized personnel for valid business reasons Flexible metrics and reporting, electronic signature, and audit trail capabilities that can be tailored to the exact processes and IT controls that govern your development environment Verifiable software builds to help ensure and document that software developed was actually deployed Automated deployment that is fully integrated into the development process Continuous validation of compliance mandates through integrated test management Tool-directed behavior (TDB) with appropriate product and process quality metrics management A fully integrated process and product audit console solution for the process and development artifacts
Control principles
Any solution for compliance should assist a company in the demonstration of due diligence for compliance with that regulation, standard, or policy. This is accomplished by accumulating documented evidence of organizational behavior, responsibility for artifact management, and due diligence regarding the implementation of policy within these efforts. Remember, the goal is to Say what you do, do what you say, and be able to prove it. The control principles defined within the IBM BDD for Compliance solution are a set of automated current good practices for application development. These control principles have been pre-tested as the success factors for many other software development projects over the course of the past ten years. In the context of compliance, these control principles play a much more crucial role. The automated control principles provided with the tools, in conjunction with the documented best practices, aid organizations in the delivery of compliance-related information required by auditors. The data that must be provided to auditors is accumulated through the automated traceability features provided within the tools. We refer to the features that establish the traceability, along with the process enforcement provided, as tool-directed behavior. Look back at the list of information most commonly requested by IT auditors. Notice that the key to demonstrating control over your process is traceability. Demonstration of control, from a traceability perspective, requires linkages from the regulation to the business policies, to application requirements, to the project
65
plans, to business process changes, to application changes, and all of it must be under change control. These principles are the foundation of a repeatable process that together with tool-directed behavior provides the traceability required. Due to the transparency of this approach, managers and executives are now empowered to make more effective decisions based upon near real-time project data. The IBM BDD for Compliance solution is a compliance-driven development infrastructure that consists of a set of well-established principles, tied to a documented and easily customized operational process standard, that directs practitioners in their day-to-day conduct through the use of specific tooling. Finally, the process enforcement provided through the tooling ensures process conformance by practitioners, ensuring measurement data is accurate across these projects as well. This is an important aspect of our solution, which can be easily overlooked. Companies that fail to implement a consistent software development process will fail in more ways than one. Failure to implement a consistent process means that any measures or metrics from one project to another will be inconsistent. Therefore comparative results will be skewed. This has a detrimental impact on decision making.
Development governance
Say what you do
In order to accurately assemble an appropriate solution for compliance, it is necessary that we describe some of the overlapping functions of IT governance, which by definition fall outside of the domain of software development. You must understand that IT governance is a comprehensive process comprised of many other smaller processes. Although IT governance is a goal to strive for, it may encapsulate a process that is far too heavy for most organizations. The purpose of including some of the unrelated software development processes of IT governance with our development governance solution is to incorporate the necessary related processes to help achieve compliance. Examples of such processes include application release management and application deployment. IT governance also contains other peer processes to IT operations, such as those used for the software development process itself. The reason these processes must coexist together is because of the implied linkage that exists among these interrelated processes.
66
An example of when a peer process is described within the solution is when a software patch has to be deployed into production to fix an application problem. It also occurs, for example, during the process of coding and testing the fix. Finally, you must recognize that the formalized best practices for IT operations and software development have evolved into standalone codified process standards, such as the Information Technology Infrastructure Library (ITIL) and the Rational Unified Process (RUP). Each of these process standards can be considered a kind of governance for IT operations and software development, respectively. Consequently, a failure to describe some of the high-level processes for IT governance and the interrelated processes of IT operations would be a failure to describe a complete development governance solution. Thus we begin our description of the IBM BDD for Compliance solution.
Discussion
Meeting compliance mandates is both a challenge and a business need for organizations in most markets. The potential impact that a given policy can have on a business is wide spread and enterprise encompassing. Consequently, businesses responding to regulations, standards, and policies must realize that implementation of appropriate processes and business controls must be implemented throughout the business operation as well as throughout the systems inventory. However, companies cannot attack this problem without first assessing the impact that new policies will have on the business operations, as well as the systems impacted by the resultant policy. This dictates that companies evaluate the impact a given policy will have on the business as well as its systems inventory. Examining this problem from a business process perspective, the organization can leverage tools such as Workplace for Business Controls and Reporting (WBCR) to capture policy requirements and trace them to the manual business controls (processes) that ensure their implementation. However, from a systems perspective, the ability to accomplish this task can be significantly more daunting. The challenge is that most companies do not utilize technology that links the systems inventory to all of the related project management plans, the resources executing those plans, in conjunction with the project proposal and demand management process. Further complicating this problem is the absence of any functional knowledge at the executive level regarding which systems, or systems components, implement policy. Finally, without a complete understanding of the business issues each application is designed to mitigate for the business, how can any company hope to perform an informed analysis on the systems inventory?
67
This has a direct impact on the quality of business decisions regarding IT investment, because an adequate level of information to make an informed decision is typically unavailable. This absence of information to determine which projects or proposals an organization should invest in typically leads to the hiring of a firm to gather this information, or a large-scale information-gathering initiative. Although this approach is pragmatic, it will surely elongate the time for change, which is likely to be operating on a fixed deadline to begin with. Once all of this information is aggregated, a careful balancing of business issues and business investment can then be acted upon. Compliance initiatives may or may not be related to software development, but from a business perspective, all of these processes are part of an operational portfolio that must be governed. In Figure 3-4 you see an example where external regulations, standards, and policies (in red) are the starting point. In response to these regulations, companies typically formulate an interpretation of these regulations as their internal policy. After performing impact analysis on the business and business systems, candidate projects are identified for modification. Once approved, these projects are then instantiated in their respective business units, and finally to the supporting application systems or as business process implementation work.
Regulations Standards Policies
Internal Policies Project Project Project Candidates Candidates Candidates Portfolio Management Process Implementation Project Compliance Project
Figure 3-4 Governance for compliance initiatives
The practice of governance for compliance must start at the portfolio level to ensure its effectiveness. The portfolio management process is shown in Figure 3-4 as the blue box surrounding the internal policies and project candidates objects. Unless the organization has at its disposal all of the necessary information with which to demonstrate the intention to make the right
68
business decisions, it can be difficult to show that the organization intends to protect the interests of its business stakeholders. A portfolio-based approach to compliance allows executives to have the necessary information on-hand, in order to prioritize compliance and non-compliance initiatives, and evaluate and mitigate related risks to make appropriate decisions. However, the benefits of this portfolio-based approach to managing compliance initiatives extend beyond the compliance domain. Other benefits of leveraging such an approach include: Improving the effectiveness of project teams and existing technologies to deliver better business results within the constraints of current investments and skill sets Improving the management of business and technical risk to lower the costs of the software innovation and change necessary for business resilience and growth Because the solution also incorporates workflow for the management of the portfolio, these additional challenges are addressed by the governance practices and mechanisms as well: Establishment and enforcement of chains of responsibility, authority, and communication to empower people to make the correct decisions Establishment of measurement, policy, and control mechanisms that enable people to carry out their roles and responsibilities In general, you see that our compliance solution is really focused on governance by supporting: Chains of authority and responsibility and clear channels of communication to facilitate the objective setting and informed decision making that keeps IT aligned with business Establishment and execution of measurements and controls to enable people to carry out their roles and responsibilities in ways that maximize development flexibility, minimize risk, and facilitate effective change management As we defined earlier, governance is the empowerment of others through appropriate authority, responsibility, communications, and measurement. What is different from the generic definition of governance in the context of software development governance is that we are applying it to the business process of software and systems development.
69
Consider the following hypothetical scenario: A major automotive manufacturer in early 2006 required its IT organization to take corrective action to comply with deficiencies found during a Sarbanes-Oxley audit. This organization had approximately 10,000 applications in its systems portfolio. Due to the absence of a systems inventory, or any consolidated knowledge of the application inventory, it took five months to determine that 2,000 application were potentially impacted by a new policy. Finally, after interviewing each of the application owners, it was determined two months later that approximately 200 of those applications directly impacted financial reporting. Had the customer been utilizing a portfolio-based approach for managing the systems inventory, a request for self disclosure using an online questionnaire might have saved the company seven months of potential implementation time. The overall goal of the business-driven development solution from a portfolio perspective is to shift the focus from a purely process discipline of service-level issues to those of corporate risk mitigation. A shift to this perspective adds new value to the IT portfolio, as well as to the IT organization as a whole. Properly balancing risk and return on investments is not simply a set of technical decisions. When you govern the business process of software development and decision making, you move from managing an activity once treated simply as a cost center to managing the decision process itself. Figure 3-5 illustrates some of the business criteria that impact the portfolio management process, as well as the progression of decisions (circles) that result from those criteria.
GOVERNANCE DASHBOARD
Business priorities
Source/ resource
Deployment ready
Value analysis
Evaluate initiatives
Identify solution
Integrate
70
Supporting tools
IBM Rational Method Composer (RMC), the industry's leading process platform, is now integrated with Rational Portfolio Manager (RPM). IBM Rational Method Composer is designed to allow customers to either tailor the Rational Unified Process or to capture their own processes in a standard format recognized by the Object Management Group (OMG). The tooling is a based upon the Unified Method Architecture (UMA), which uses UML to internally store the documented processes. Leveraging this technology allows customers to easily extend documented processes through the application RMC plug-ins. Since each plug-in is designed with UMA, and is UML based, it inherits all of the object-oriented advantages of UML. Thus, any existing processes documented using this technology can be easily extended by simply inheriting the characteristics of other processes or plug-ins. For example, customers wishing to extend their existing process could download and apply a plug-in for SOA, and have their process inherit all of the activities, work products, roles, and processes defined by such a plug-in. Finally, unlike other process documentation solutions, RMC allows documentation of not only process guidance, but work breakdown structure, as well as process dependencies. This allows a complete articulation of process guidance that is fully linked to an executable process. Through the RMC-to-RPM integration, users can automatically apply industry-leading best practices to project plans by exporting the documented methodology. These project plans can then serve as templates for the instantiation, costing and estimating of potential development projects within the demand management function of RPM. This saves time and money by replacing time-consuming, error-prone manual approaches with proven and consistent processes and tooling.
71
RPM helps business executives and IT leadership align IT investments with business goals. It helps project teams efficiently plan and execute projects. It provides a collaborative workflow environment for project and asset management, insight into resource capacity planning, and oversight of project financial. RPMs marriage of top-down portfolio analysis with bottom-up project management best practices provides a comprehensive on demand capabilityfrom initiative identification and investment prioritization through project execution and closure. It is about achieving the desired return for your IT investment, while balancing fiscal expenditures. RPM makes it possible to: Monitor current projects by periodically reviewing: Investment maps Organizational scorecard for compliance Scorecard mapping Online analytical processing (OLAP) pivots (for more details) Other reports as appropriate
Monitor and control risks: Perform risk trend analysis. When a risk materializes, incorporate its risk response package into the work breakdown structure (WBS). Execute the risk tasks in the WBS. Using Rational Portfolio Manager, project information is entered into a repository and it is made available to others as their needs dictate. RPM functions are designed to serve the main stakeholders of a project, namely: For project managers to plan, track, and control projects For project team members to access relevant standards, procedures, and other documents For project team members to receive their assignments and to report their progress For project executives to maintain awareness of the status of all projects in their area of responsibility/portfolio For resource managers to effectively manage the resources within their area of responsibility To learn more about Rational Portfolio Manager refer to:
http://www-306.ibm.com/software/awdtools/portfolio/
72
Supporting process
The supporting process is defined in the Project Management discipline in IBM RUP.
Conclusion
Table 3-1 shows the control principles for IT governance.
Table 3-1 Control principles for IT governance Control principle Benefits IT governance Align IT projects and investments with business priorities. Plan and manage portfolios of projects to meet enterprise objectives. Manage compliance requirements as risks at the portfolio level. Focus on resolving risks. Qualify initiatives with business attributes. Not using attributes to qualify initiatives. Projects being completed late, or not at all, and usually over budget. Evidence of SDLC process maturity and stability. Transparency of reports.
Pattern
Antipatterna
Evidence
a. An example of an inferior design solution that is commonly made by developers. They are used to reinforce better planning during the development process as well as provide a problem-solving reference point.
Requirements management
Say what you do
Although requirements are routinely thought of as features for software development, requirements can be captured for nearly any project or initiative. Let us consider for a moment your own criteria for the neighborhood where you selected your home. Did you have requirements for good schools, good resale value, a community you could relate to with similar values, or proximity to other family members? All of these are requirements that could be considered requirements for selection of a neighborhood in which to live.
73
Shifting the perspective to a compliance example, you might consider other criteria as input for a compliance-related initiative. Regulations can be considered criteria for risk requirements and subsequent risk mitigation, and policies can be considered your interpretation of a regulation. Using this perspective on regulations, policy, and process, you should be able to see the importance of organizing regulations and policies in a structured way so they can be traced to systems and integrated with other life-cycle tools and artifacts. Of course, it is always essential to ensure that requests for new enhancements or changes to systems are implemented appropriately. By extension, the same regulations and policies described earlier may have an impact on those systems that automate policy as an automated process.
Discussion
As the say what you do to be in compliance component of the IBM BDD for Compliance solution, you should be able to demonstrate that all compliance mandates are accurately captured and implemented in your key applications. The consequence of such an imperative is that compliance mandates become a significant source of the requirements for future releases of those systems otherwise overlooked. The consequence of such imperative is that compliance mandates become the main requirements source for business and supporting systems. IBM RUP defines the requirements management discipline as a systematic approach to finding, documenting, organizing, and tracking a system's changing requirements. A requirement is defined as a condition or capability to which the system must conform. RUP also formally defines requirements management as a systematic approach to both: Eliciting, organizing, and documenting the requirements of the system Establishing and maintaining agreement between the customer and the project team on the system's changing requirements Every organization must obtain advice of competent legal counsel for the identification and interpretation of any relevant laws and regulatory requirements that might affect its business operation. From this internal interpretation of external regulations, risk officers and analysts create a set of policies for the company, which will guide the companys behavior. Because systems are used
74
to automate business behavior, these policies might create new systems requirements, change existing ones, or demand a new system development. In the IBM BDD for Compliance solution policies, standards, and regulations are the highest level requirements source for the systems within an organization. This is because they are usually linked not only to one system, but to many different systems. The key to effective requirements management is maintaining a clear statement of the requirements, along with appropriate attributes and traceability to other requirements and other project artifacts. It is also important that these requirements have a high level of maturity, which means that every featurewhether a regulatory requirement or notbe written, organized, structured, and traced to requirements. They must also be integrated with other life-cycle tools and artifacts. This is the only way to implement the traceability necessary to demonstrate compliance to auditors. At the onset, achieving this level of maturity might require a cultural change for many organizations. However, this is an important step towards the implementation of the IBM BDD for Compliance solution. Managing requirements helps you build the right thing and many other principles rely on good requirements: change management, validation, documentation, and deployment.
Supporting tools
Requirements management is supported by a number of IBM products.
Rational RequisitePro
RequisitePro is the central repository for all organization regulations, policies, and systems requirements. Figure 3-6 shows how requirements are used as input to many others activities during the software development life cycle of an application.
75
Enhancement Requests
Use Cases
Project Managers
Test Cases
Requirements
Team
Define test cases based on requirements Manage changes
System Analysts
Baselines
Testers
Using Rational RequisitePro, compliance requirements are captured in a central repository and validated by analysts through detailed use cases. These details are used by the development team to design and build the required controls into the appropriate applications. Based on the documented requirements, testers develop application test cases that thoroughly test that the application meets strict requirements. These can be manually described tests or automated tests that are captured once and repeated every time the application is changed in some way. There is another challenge regarding compliance requirements: they change, mostly due to external changes in regulations, standards, and policies. For example, companies subject to a regulation are typically bound to comply with changes to these regulations within a specified period of times. Being prepared to perform impact analysis when such a change occurs is an important component of the solution. What makes changing requirements complex to manage is not only that a changed requirement means that time has to be spent on implementing a particular new feature, but also that a change to one requirement may have an impact on other systems. Managing change includes activities such as establishing a baseline, determining which dependencies are important to trace, establishing traceability between related items, and implementing change control.
76
Figure 3-7 shows the example mentioned above. You can see the detailed relationships between the regulation, the company policy, the process features for the new model, the application features needed in the supporting systems, and the assignment of work to these projects by the change control board or project management office.
Corporate INTERPRETATION
BPR Efforts Document Process Features App Remediation Document App Features
REGULATION
Company Policy
RequisitePro Import
REGULATION
Starting with the external regulations, the organization creates internal policies. Both are stored in IBM Rational RequisitePro and traced into features of supporting use cases. A change on any of these requirements can be easily tracked by RequisitePro and linked to every change request when using IBM Rational ClearQuest. IBM Rational RequisitePro is a requirements and use case management tool for project teams that want to improve the communication of project goals, enhance collaborative development, reduce project risk, and increase the quality of applications before deployment. Some of the features are: Uses advanced integration with Microsoft Word to provide a familiar environment for activities such as requirements definition and organization Incorporates a powerful database infrastructure with real-time Word document synchronization to facilitate requirements organization, integration, and analysis
77
Enables detailed attribute customization and filtering to maximize informative value of each requirement Provides detailed traceability views that display parent/child relationships and show requirements that may be affected by upstream or downstream change Performs project-to-project comparisons using exportable XML-based project baselines Integrates with multiple tools in the IBM Software Development Platform to improve accessibility and communication of requirements To learn more about Rational RequisitePro refer to:
http://www-306.ibm.com/software/awdtools/reqpro/
Supporting process
IBM RUP defines the task Defining Automation Requirements in the business modeling discipline, which specifies how to derive system requirements from the business modeling work products.
78
For more details about requirement management, see Requirement Management and Business Modeling Disciplines in IBM RUP.
Conclusion
Table 3-2 shows the control principles for requirements management.
Table 3-2 Control principles for requirements management Control principle Benefits Requirement management Align applications with business needs and regulatory needs. Easily access the impact of implementing or changing a policy into supporting systems. Control over regulations and policies. Create a central repository for regulations, standards, and polices. Trace regulations, standards, and policies to supporting systems. Establish control over changes in regulations, standards, and polices. Define, understand, and prioritize implementation. Manipulate regulations, standards, and policies as documents. Start their implementation without previous assessment of risks and benefits to business. Linkage between artifacts that align with the business process steps.
Pattern
Antipattern
Evidence
79
Discussion
Beyond the traditional change requests sources, such as end users and stakeholders, businesses must keep up with current and emerging laws, regulations, and standards. Consequently, organizations must realize that compliance is not a one-time project or activity. Compliancy is an on-going process that must be integrated as a first class business process. Different changes on regulations, standards, and policies might demand changes in many different supporting systems, which, in turn, might be developed by different teams. Compliance management requirements highly affect the productivity of software development teams. This scenario becomes more challenging if organizations have geographically distributed development teams. Auditors want to see the appropriate evidence of IT internal control, showing that changes are developed through a secure, controlled, and auditable process with the following characteristics:
Software and asset data controlFull inventory and safeguard storage of all
software assets.
Software change controlComprehensive change histories detailing why each software change was made, what changed, who changed it, and when it was changed. Separation of dutiesImportant feature for preventing fraud. Some roles in
the chain of development must be played by different people. The person who changes the code is not the same who approves the change, and is not the same who approves the code to be released to the production environment. Due to the temporal nature of change, it can be very difficult to manage. Ensuring that many moving and changing parts are delivered simultaneously to construct a cohesive whole requires a great deal of rigor. Change management should be presented using a natural and intuitive interface that reduces the perception of complexity. If change is managed at a higher level of abstraction than simply working on files, then the task of managing change appears simpler. Consequently, the change management solution should be design to allow people to work on activities, and as a result of working on those activities all of the necessary assets are tracked, traced, modified, and audited. This approach reduces the complexity of change management by allowing personnel to focus on what has to be changed, as opposed to the task of tracking all of the individual elements requiring the change.
80
Supporting tools
Companies operating in highly regulated environments require the implementation of a robust configuration management, which includes change request management, version control, automated work space management, and build management. To fulfill these requirements, the IBM BDD for Compliance solution is based on the use of both IBM Rational ClearCase and IBM Rational ClearQuest tools. The activity-level abstraction capability is provided by the Rational Unified Change Management (UCM) process framework, which is contained within the ClearCase tooling. Using UCM, practitioners can focus on activities, such as implement changes for policy 275. UCM manages the association between this activity and software development artifacts that are created or modified as result. These features are part of the foundation of the IBM BDD for Compliance solution and play a special role for organizations with geographically distributed teams for development. In such cases, no matter which role the organization is playing, vendor or contractor, having such an infrastructure in place is a must. Software configuration management (SCM) is a key capability in modern software development practice. It allows teams to carefully manage all artifacts created in the software development life cycle, during which numerous changes occur, including changes to requirements, models, code, and so forth.
Rational ClearQuest
ClearQuest is an auditable workflow change request management solution, featuring electronic signature, audit trail, and user authentication. This tooling helps to ensure that all software changes are performed for a valid business reason by an authorized person. Use of this tooling ensures adequate documentation of actions taken against your artifact base in accordance with an organization's software development business controls. ClearQuest also enables better insight, predictability, and control of the software development process. Through its flexible workflow management, defect and change tracking capabilities, ClearQuest helps to automate and enforce development processes, manage issues throughout the project life cycle, and facilitate communication between all stakeholders across the enterprise. Here is a list of some of the features and benefits of the ClearQuest tooling:
Audit trailCapture and document evidence of who made a change, what they changed, and when they made a change. Electronic signatureVerify and document the identity of users to ensure that
only authorized users may approve the transition of a change request from one state to another.
81
User authenticationEnsure that ClearQuest passwords provide a reasonable level of security against various kinds of security threats. User authorization and data controlEnsure that only authorized users may
make changes to controlled data.
Life cycle managementAutomate the capture of key information from requirements to testing related to controlled changes via product integrations. Project managementProject status, workload, and issues including defect submissions and enhancement requests can be easily monitored and prioritized through queries, charts, and reporting capabilities. Regulation supportElectronic signatures and audit trails help you to meet regulatory and audit compliance requirements. InterfacesLocal, remote, and Web interfaces enable access virtually
anytime and anywhere.
Rational ClearCase
ClearCase is the central repository designed to provide life-cycle management and control of all software development assets. Unlike most other solutions, ClearCase is a file system that implements integrated version control, automated workspace management, parallel development support, baseline management, and build and release management. Because ClearCase is a file system, and not just a version control tool, it not only versions files, but actually versions the entire file system structure. In other words, ClearCase versions the entire directory tree structure in addition to all of the files supporting a system. Rational ClearCase provides all of the capability required to create, update, build, deliver, reuse, and maintain business-critical assets. ClearCase can help increase productivity through parallel development, reduced build/release cycle times, and increased software reuse. Because ClearCase provides native integration with most of the leading IDEs including Rational Application Developer, Rational Software Architect, WebSphere Integration Developer, Microsoft Visual Studio .NET, and the open source Eclipse framework, it further streamlines the development process by allowing practitioners to work with the tool they are most comfortable with.
82
ClearCase provides these features that benefit the solution in the following way:
Parallel development supportVersion selection for building software, and record keeping to accurately reproduce a build. Build managementVersion selection for building software, and record
keeping to accurately reproduce a build.
ClearQuest integrationClearCase is seamlessly integrated with Rational ClearQuest for a complete software configuration management solution. UCM supportThe Unified Change Management (UCM) provides the ability to manage artifacts at a higher level by abstracting individual files and directories to higher level objects that actually represent your software architecture.
To learn more about Rational ClearCase refer to:
http://www-306.ibm.com/software/awdtools/clearcase/
83
ClearQuest provides an easy way to assign project work to specific team members and rank the priority of the work. For example, you are assigned to work on the special promotion Web page. An individualized to-do list appears on your desktop through ClearQuest. The entire team knows their responsibilities on the project and can track the status of the work in real time. From ClearQuest, you can automatically access ClearCase and review all the artifacts associated with the special promotion activity from the ClearCase database. ClearCase conveniently and automatically gathers all the changes that you make to project files and other artifacts while working on the special promotion Web page and adds them to the activitys change set. Now that all of the artifact changes are associated with a particular activity, ClearCase can manage that change set as a single unit. By associating activities and artifacts, users save time and are confident that they have all of the information they need to complete a task. This association also assures higher software quality. Practitioners cannot unintentionally forget to check in a file and affect the success of a build or a project. Through Unified Change Management, ClearCase takes what was once a manual, error-prone process, and automates the collection of change set data so that you can be sure that all changes related to an activity are accounted for.
Supporting process
The supporting process is defined in the Change Management Discipline in IBM RUP.
Conclusion
Table 3-3 shows the control principles for software change management.
Table 3-3 Control principles for software change management Control principle Benefits Software change management Provide an auditable workflow management process, featuring electronic signature, audit trail, and user authentication support, to document compliance with your organization's software development business controls. Automate asset and change management. When used with Rational ClearQuest, provides auditable asset management to help ensure that software deliverables include only authorized files built using auditable workflow processes.
84
Software change management Team performs activities, following automated process for change and configuration process. Implementing authorization workflow, quality gates, separation of duties. Not organizing change request, not following an approval workflow, not prioritizing them, not assessing their impact on supporting systems. Accountability on the chain of delivery. Documented and formalized handoffs and signoffs.
Antipattern
Evidence
Discussion
From a compliance perspective, every application running in production must be traceable back to the original work products and artifacts used to assemble a given application. The reason for this degree of rigor goes back to our discussion in previous chapters regarding the need to show which requirements and regulatory mandates are satisfied by a given feature deployed on a target system. This traceability from requirements to application and back to requirements is crucial for organizations to give answers to most common questions posed by an auditor. Absence of this kind of information makes it difficult to prove to an auditor that the system is exactly the same system that was developed to satisfy some specific policy mandate. In Figure 3-8 we illustrate this bidirectional traceability in detail. Through this traceability we can see that all the activities and artifacts are linked together. The
85
point is that an audit can pose the question starting from any artifact within the software development life cycle, and you still arrive at the correct answer.
Application Of this Release Implemented these Requirements Which required these Changes Implemented with this Source Code Built using these Build Scripts Build Artifacts
Tests
Where these
Auditors will look for much more information to know exactly what was delivered to the customer. Here are other types of questions, easily answered using this chain of traceability: Who approves the deployment of applications into test and production environments? Where is the audit trail? What version of build artifacts are deployed in the test environment? What about the production environment? Can you accurately reproduce all artifacts that you deliver to your customer? What build artifacts are associated with this release of the application? What version of the source is associated with this build artifact? Who deployed the code on this server? How is that controlled? To ensure the integrity of this data it is important to implement proper security and the ability to electronically sign off at critical steps within the process. The great challenge faced by many organizations is how to connect the development and operations areas all together, to give auditors the right answers.
Development
Approved by
Operations
86
This is overcome by establishing a build management process that establishes a repeatable workflow, enforced through tooling to implement traceability of builds and releases throughout the SDLC. The build management solution also gives updated information regarding the status for each build or release. This ensures timely and accurate tracking of related builds as well. Organizations employing manual or home-grown processes for build management often view build management as a minor concern. This is due to the perception that testing activities are optimally carried out upon completion of a total systems build. Often organizations using this approach fail to realize that testing teams remain idle waiting for a release to be ready for validation. Because project deadlines tend to be fixed, validation or testing duration tends to be hit the hardest, as it is found at the end of a traditional development cycle. This can lead to an incompletely tested release of a system that can shut down the business operation for many hours or days, with very high cost to organizations. In Figure 3-9 we illustrate a sample build workflow that an application follows from development into the production environment. Testing and validating of the system against its requirement and regulatory mandates is an important step in the approval flow for an application to proceed into the production environment.
Implementer
Integrator
Deployment Manager
Tester
E-SIG
Project Manager
Implement
Function Test
Approve In Production
The development team manipulates many project work products that are physically stored in the project repository, to create an operational version of an application, which we called build (refer to the definition for build in the Configuration and Change Management discipline in IBM RUP).
87
This operational version must be validated against regulatory requirements into functional and testing environments. Therefore, the team must create a subset of the end product that is the object of evaluation for these major milestones, and we call this a release. A release is a stable, executable version of the product, together with any artifacts necessary to use this release, such as release notes or installation instructions (refer to the definition for release in the Configuration and Change Management discipline in IBM RUP). Once this release is validated and approved, it is ready to be deployed into production by the operations team. The operations team must have a complete deployment model to make sure that software and hardware requirements are satisfied for each workstation and server running the application. To perform deployment well, a great deal of information must be captured, recorded, and shared during these tasks and among the different teams inside the organization. Participants should come from both the development and operation areas and include the roles of developers, testers, build managers, project managers, and deployers. Compliance demands a high level of exactitude of information. This level of exigency and precision is not achieved by a manual log of operations, and certainly cannot be achieved in a reasonable amount of time or expense through a manual process.
Supporting tools
Figure 3-10 shows IBM tools support for automating the build and deployment management process.
88
Rational Clearcase
IBM Rational ClearCase Change Management Solution Rational Tivoli Provisioning Manager BuilForge and Configuration Manager
Implementer
Integrator
Deployment Manager
Tester
E-SIG
Project Manager
Implement
Function Test
Approve
In Production
The tools are: IBM Rational ClearCase manages source code, artifacts, and deployment units. IBM Rational Unified Change Management provides an out-of-the-box development process that integrates ClearCase artifacts with ClearQuest activities. This solution allows you to track builds and deployments through the test environment: Track which build is to be used for testing. Define and sequence test environments specific to your organization. Establish approval gates before deploying to an environment. Pass regulatory audits: Associate builds with deployments. Capture electronic signatures when needed. Maintain build artifacts under version control in UCM. Add build automation: Integrate with BuildForge build automation packages. Automatically create and update build records.
89
Add deployment automation: Link to Tivoli Provisioning Manager to automate the provisioning of servers with the latest build. Deploy approved build files directly from the source control. IBM Tivoli Configuration Manager deploys software for distributed devices.
Rational BuildForge
BuildForge products provide complete build and release process management. They provide a framework that helps development teams to standardize and automate tasks and share information. Build acceleration capabilities reduce the process execution time, resulting in faster time-to-market. Enterprise reporting improves visibility into the build and release process. Process control and audit trails help meet compliance mandates. BuildForge technology, when combined with other Rational software, can help organizations to automate, track, audit, and analyze their application development life cycle, often using the tools they have in place today. As a result, they can increase product quality, improve team efficiency, and move toward achieving sustainable compliance management. IBM markets the following BuildForge products:
BuildForge FullThrottleBuild accelerator that executes processes concurrently across server pools BuildForge PrismDesktop IDE for developer self-service build activities BuildForge AdaptorsIntegrates BuildForge products with third-party change and configuration management tools
To learn more about IBM Rational BuildForge refer to:
http://www-306.ibm.com/software/rational/buildmanagement/
90
Some of the features of Tivoli Provisioning Manager are: Graphical user interface designed to simplify change execution tasks for the datacenter operator, hardware, software, and network resource discovery and drift detection to help ensure that desired configurations are maintained. Integration with Tivoli Configuration Manager for enterprise-wide software distribution, and image and script management to help leverage existing company standards and procedures in a consistent and controlled way. Provisioning Manager also incorporates solution install, a self-managing autonomic technology enabling the deployment of complex applications to multiple real and virtual servers. To learn more about IBM Tivoli Provisioning Manager refer to:
http://www-306.ibm.com/software/tivoli/products/prov-mgr/
Supporting process
The supporting process is defined in the Deployment, Configuration, and Change Management disciplines in IBM RUP. A build produces an operational version of a system or part of a system that demonstrates a subset of the capabilities to be provided in the final product. A build comprises one or more implementation elements (often executable), each constructed from other elements, usually by a process of compilation and linking of source code. A release is the delivery of a functional system meeting predefined objectives.
Conclusion
Table 3-4 shows the control principles for build and deployment management.
Table 3-4 Control principles for build and deployment management Control principle Benefits Build and deployment management Consistent, reliable, high performance process for build and deployment management Eliminates multiples sources for manual and error prone in all SDLC cycle Increases team productivity and improves communication among different areas in organization Processes and automates Manual control Accountability in the chain of delivery
91
Reference
See IDC White Paper Establishing Build Management for IT Efficiency and Business Adaptability, January 2006:
http://www.buildforge.com/index.php?option=com_wp&Itemid=122&paper=idc
Software validation
Be able to prove it
Nobody likes to discover that they have application bugs in their software, particularly people who depend on it. This section discusses the importance of using requirements as a basis for software testing and validation and also discusses the importance of traceability to all of the system artifacts, such as testing results. The principle of software validation is not only a product quality indicator, but a development process quality indicator as well. For example, in most highly regulated environments you must be able to demonstrate that all compliance mandates have been accurately captured and implemented in your key applications.
Discussion
To demonstrate due diligence, both the functional and non-functional requirements that were spawned from the company policy must be implemented and the system must be validated against them. If there is one cardinal rule of systems audit, it is the demonstration of traceability between system requirement and system test results. One can then conclude by extension that system requirements spawned from policy requirements must align with system test results that substantiate that a system is fit for its intended use. Creating these proof points is far more than validating the requirements. You must register and track each of the tests, as well as the corresponding test results. Upon completion you should have documented when and how these tests were conducted, and on which platforms the systems were validated. Non-functional requirements validation is even more complicated. Creating and configuring test environments is sometimes impossible to achieve without supporting tools. Consider the challenge of how to validate a performance requirement of a simulation of 1,000 simultaneous users accessing a system? Validating software is a key piece of the overall solution. Because the success of an implemented system is a reflection of the quality of the processes and the
92
team that designed it, the system quality is perceived as a quality indicator for the whole development process that a company has in place. For example, not meeting a regulatory requirement might indicate that policies were not implemented properly. However, this is clearly a misnomer, as it is not always the code that is the problem. Systems are more complex today, and validating them against all of these combinations of environments and user profiles requires a lot of resource allocation, not only human resources, but in the form of servers and workstations. Validation resources tend to be limited and usually shared among teams that perform the validation of many systems. Depending on the nature of the test, it is quite common for the creation of a test environment to be more costly than the implementation of the system requirement itself. Once a system is validated, how are the test results communicated? How does the development team gain an awareness that there is a defect to fix? How will you quantify that a given system has achieved the minimum quality level specified by the operations team to permit a release into the production area? Software validation is a key piece of the IBM BDD for Compliance solution, and tooling support is a key piece necessary to create the traceability needed among work products or artifacts. The link between software validation and requirements management is stronger in the context of compliance and gives visible value if they are used as input for validation plans. Auditors do care about which specific requirements are being satisfied and how they were validated. From the traceability perspective, it is important to show to auditors the link between regulatory mandates, test planning, and test results. Such a level of complexity and required traceability among work products for auditors demands tool support. Manually testing might create bottlenecks, which can result in a negative impact on business operations, and potentially negatively impact the reputation of the business.
Supporting tools
Before executing any tests to validate a system, the organization must establish the scope of validation tests necessary to acquire the data to make the critical decisions about deploying an application. Included among the considerations are: Which regulatory requirements must be validated? Which functional and non-functional requirements are targeted to be tested? When?
93
Which environment and platform will be used? Everything begins with the construction of an appropriate test plan, typically assembled from the original design requirements for the system.
Adapters can be written to support third-party or custom test tools. CQTM supports the Eclipse Test & Performance Tools Platform Project (TPTP), a framework that contains testing editors, deployment and execution of tests, execution environments, and associated execution history analysis and reporting. Test scripts associated with CQTM test cases may be executed from within the CQTM client, or from within the test tool. When execution is performed from CQTM, results are automatically published to ClearQuest. When execution is performed from the test tool, results can be pulled into the ClearQuest database. CQTM features built-in queries, charts, and reports for coverage/suspicion, status, and trends over time. Users can also create custom queries, charts, and reports. Support for distributed teams is enabled via replication or through a Web interface. To learn more about Rational test tools and testing solutions refer to:
http://www-306.ibm.com/software/awdtools/clearquest http://www-306.ibm.com/software/awdtools/tester/clearquest/functionaltest/i ndex.html
94
Requirement
Headline Description
Test Case
UCM Activity
System Analyst
Usually requirements are managed by system analysts who work with customers to elicit and organize them. However, all members of the team require access to the requirements for the system including developers, testers, and all of the other roles on the team. Often these team members are geographically distributed, so communication can become even more of a challenge. When the development team uses CQTM they can easily inquire about the last revision of the underlying requirements for a test, and assess the impact that changes to these requirements may have on these tests. Because test procedures must also be updated with any requirements that change, additional information about a requirement can be located by simply selecting the View option for the ClearQuest requirement. The point is that transparent access to
95
any artifact can be gained from nearly any tool by leveraging the native integration provided by the solution.
0..n
Test Case
1
Configuration
Default
0..n
Script
TestLog
0..n 0..n
Test Suite
SuiteLog
Defect
96
Classics Master Regulatory Test Plan Test Plan Customer Use Cases Functional Test Admin Use Cases Test Plan Load Test Test Plan
Test Case
Purchase
Order Inquiry
Cancel Order
Purchase on XP
Purchase on Linux
The technology allows test cases to be associated with a test configuration, thereby assembling a configured test case record (a child of the parent test case). This provides the ability to execute and report on test cases on a platform-specific basis. For example, the solution under test may be ready on Linux before it is ready on Windows. Similarly, a test case implementation may be different across platforms. Configured test cases provide a mechanism to manage these conditions so that they do not become a bottleneck in the testing sequence. Test cases may be executed multiple times to establish trend data that can be useful during audit situations. CQTM accomplishes this by storing the result data from every run so that this data is available for comparative analysis and queries.
97
Manual tests can also contain notes, attached files, and other information to make test execution, directions, and results reporting more precise. You do not have to use all manual or all automated tests. Mixing both types, manual and automated test script, in a single test plan is quite common. Quite frankly, if a business control contains both an automated and manual component to the control, both halves of the control must be exercised to substantiate that the control is fit for its intended use. Such may be the case where an application is dependent upon the judgement of an authorized user to proceed with a transaction.
98
Rational ClearQuest
http://www.ibm.com/software/awdtools/clearquest/
The integration between Rational and Tivoli tools provides an enhanced solution set combining analysis tools and data from both development and production environments. Key data is shared across organizational boundaries to enable traceability from concept through production deployment. This capability brings important benefits to customers, such as increased reliability and reduced system downtime, deployment of more robust and secure applications, monitoring of expected service level agreements at minimum cost, and faster analysis of problems and faster introduction of updates.
99
Offers advanced testers a choice of scripting language and industrial-strength editorJava in Eclipse or Microsoft Visual Basic .NET in Visual Studio .NETfor test authoring and customization. To learn more about IBM Rational Functional Tester refer to:
http://www-306.ibm.com/software/awdtools/tester/functional/
Supporting process
The supporting process is defined in the Test discipline in IBM RUP.
Conclusion
Table 3-5 shows the control principles for software validation.
Table 3-5 Control principles for software validation Control principle Benefits Software validation Regulatory mandates are captured and validated. Validation evidences are automatically generated through tools integration. Using regulatory mandates and other requirements as input to test plan. Using tools to create traceability among requirements, test planning, and test results. Using tools to configure test environments.
Pattern
100
Software validation Not using traceability among artifacts. Not formally assessing validation results before deployment to production. Not implementing separation of duties. Documented test results to requirements linkage. SDLC process maturity and stability.
Evidence
101
Discussion
Let us begin with a definition of validation. Validation can be defined as establishing documented evidence that provides a high degree of assurance that a specific process will consistently produce a product meeting its predetermined specifications and attributes. The key phrases are: Predetermined specifications Documented evidence Consistent product High degree of assurance The main requirement that a compliance framework must satisfy is helping organizations to prove that they do what they say they do to be in accordance with their policy and procedures. Therefore, there are three aspects to be validated: Have you fully documented your existing software development process? Do practitioners actually adhere to the documented process throughout the organization's teams on all projects? Does the process yield the expected results of quality and performance, as demonstrated by the product quality and organizational effectiveness? If you consider the development process itself a product of governing the process of software development, you realize that it requires validation just like the software product it produces. This means that the software development process must be validated against the original business needs that motivated executives to invest in establishing such a process in the first place. Using a requirements analysis tool, the business requirements can be mapped to the components of the development process to illustrate compliance with documented policies, methods, or goals it was design to achieve. To utilize this approach, it is important to have established the success criteria for the process, prior to process design.
102
However, this validation will not always be a manual step. To ensure that practitioners actually adhere to the documented process, certain components of the software development cycle can be automated. This is one of the strengths of the IBM Rational BDD for Compliance solution. Through the use of our automated tooling, practitioner behavior can be guided, thus ensuring that the documented procedure is actually adhered to. For example, management of change requests can be automated through the use of ClearQuest, as described earlier. Because the workflow is configurable, adjusting the workflow to match the documented workflow ensures that practitioners adhere to the process. Because it is impossible to advance artifacts through the software development life cycle, without satisfying the criteria defined in the configured ClearQuest record life cycle, practitioners have no choice but to adhere to the documented process. If you take the additional step of validating this configuration by using automated testing or manual testing tools, you ensure the quality of this configuration by comparing it with the configuration design goals outlined in the software development methods. Thus, expected results of quality, performance, and organizational effectiveness are apt to improve significantly. There are other powerful side effects of implementing such a solution that bear mentioning. These side effects include the establishment of a shared understanding of the way in which work should be performed, a common language with which to describe tasks, as well as consistent behavior across the organization. The remaining benefits of this approach trickle out in hidden capabilities of the organization to be more effective. Such an approach enables the business to easily move staff from one development organization or project to another. This is due to the common understanding of the development process held by practitioners. This allows for more effective cross training from a business domain perspective, because no cycle time is wasted acquainting staff with the differences in software development procedures.
103
Leveraging this technology allows customers to easily extend documented processes through the application RMC plug-ins. Since each plug-in is designed with UMA, which is UML based, it inherits all of the object-oriented advantages of UML. Thus, any existing processes documented using this technology can be easily extended by simply inheriting the characteristics of other processes or plug-ins. For example, customers wishing to extend their existing process could download and apply a plug-in for service-oriented architecture (SOA), and have their process inherit all of the activities, work products, roles, and processes defined by such a plug-in. In terms of IBM Rational, this is easily accomplished by using the RUP Plug-in for Compliance Management with Rational RMC to instantiate a BDD for compliance process, using the required policies, process standards, and frameworks or other criteria as input to the process design. The goal is to assemble a process that satisfies our design criteria by incorporating appropriate approval checkpoints. When automating the development process approval checkpoints, you can enforce the approval behavior through the electronic signature capabilities found in the IBM Rational ClearQuest product. This ensures that the technical approval is in place for your process. The project level approvals for funding, release of budget, and other business aspects of the process can be enforced through workflow found in the Rational Portfolio Manager solution, when proposals are promoted to projects. Finally, technical quality gates can be enforced by adding steps for the validation and sign-off during the software development life cycle using CQTM and electronic signatures. This ensure appropriate product quality evaluation, for example. Because access to all of these artifacts is constrained by user login, appropriate separation of duties is a natural outcome. After documenting your software methods Web site using RMC and automating the workflow with tool-directed behavior, you can be assured that practitioners will adhere to the documented process. The generated Web site allows auditors, practitioners, and inspectors to navigate all process definitions, either designed or inherited. Refer to the IBM RMC and RUP Plug-in for Compliance Management for further information.
104
Typical metrics are: How many projects are applying the process? How many people have been trained so far? How many projects are in the inception, elaborate, construction, and transition phases? How many people are using which tools? Ability to monitor and report software development controls status within broader IT-wide and corporate-wide controls management systems.
105
Supporting tools
The IBM Rational supporting tools are the IBM Rational Portfolio Manager, the IBM Rational Method Composer, the Rational Unified Process (RUP), and the RUP Plug-in for Compliance Management. The Rational Portfolio Manager is described in Rational Portfolio Manager on page 71.
106
domains, such as database modeling or advanced requirements management, to be added or removed. Out-of-the-box delivery processes to provide the project manager with a quick starting point for planning and initiating a project. A delivery process will provide an initial project template, identify what type of milestones to have in the project, what work products are delivered by each milestone, and what resources are needed for each phase. To learn more about RUP refer to:
http://www-306.ibm.com/software/awdtools/rup/
Supporting process
The process component of the IBM BDD for Compliance solution is itself an instantiation of the RUP process and might be configured and tailored following the guidance in the Environment discipline of IBM RUP.
Conclusion
Table 3-6 shows the control principles for compliance validation.
Table 3-6 Control principles for compliance validation Control principle Benefits Pattern Validating your compliance process Leverage compliance for business advantage. Identify business needs that must be addressed by the process. Prioritize them. Define and apply principles for each need. Have an owner for the process.
107
Validating your compliance process Try to do everything at once. Do not automate it. Overwhelm team with manual documentation. Documented SDLC process for creating all business artifacts. Process linkages to automated process supported by tool mentors.
Evidence
Documenting results
Be able to prove it
Very few people derive a great deal of joy out of surprise in the business world, least of all in a regulated environment. Consequently, we design a significant amount of procedure to contend with the most likely eventualities. So why do most organizations operate as though there is no such thing as a surprise audit or inspection? Generally, shops that do not use our type of automated traceability find themselves doing an archeological dig for the artifacts needed for audit every time one occurs. This section articulates the importance of the automating the documentation in opposition to annual creation. Whenever a system changes, the documentation must de updated to reflect the change. Many regulations, standards, and policies require a demonstrated ability to show linkages between the feature requirements of a system and the test results that conclusively illustrate compliance with those feature requirements. This need is particularly true when the automated system provides, houses, or stores regulated data. Failure to provide such information will result in an inspection failure. This is because without this data, there is no way to prove that the system is fit for its intended use.
Discussion
As we established earlier in this book, any solution for compliance must help companies to prove they are in compliance with a regulation, standard, or policy based upon the documented evidence for organizational behavior and due diligence in compliance enhancement efforts. To substantiate such a position, a company must be prepared to respond to requests for this information in a reasonable time frame.
108
However, experience has proven that those that can provide this information in an instant appear to have better control over their processes. This need might lead organizations to implement a documented driven development for compliance solution instead of implementing a business driven development solution. Manually generating documentation for compliance purposes is a huge and time-consuming task. Ideally, required documentation should be generated as the result of tool usage, as practitioners perform each of their respective tasks and activities. Traditional manual software documentation methods provide a high degree of flexibility. However, this method frequently does not offer the same level of timeliness, accuracy, and document linkage that is needed for compliance that an automated solution can provide. This is because manual documentation is extremely labor intensive, is very difficult to maintain, and due to human error can threaten the consistency required across document boundaries. The challenge is that manual documentation efforts typically cannot keep up with the rate of on-going changes that need to occur to keep documentation up-to-date. As you begin to document your business using automated tools, instead of hand-crafted documents or pictures, you discover that achieving the level of traceability required for compliance is relatively easy. This is due to tool features that support the IBM BDD for Compliance solution documented in the Rational Unified Process plus the RUP Plug-in for Compliance Management. This process is something we have discussed earlier, tool-directed behavior. Tool-directed behavior is the implementation of process requirements in each tool, such that the process cannot be circumvented. If you think about it, this is something that businesses have been doing for quite some time. This is to say that businesses have been automating their business processes as tool-directed behavior in the application packages they select, or by custom programming systems to carry out transactions as the business dictates. Because the relationships between all of the artifacts are already there, all you must do to create appropriate documentation is to generate a suitable report that walks the chain of traceability, dumping all of the required information. Generally, the reason for handcrafting such documentation is for formatting purposes. The sophistication of the automated documentation tools available today provide for detailed formatting constraints. These tools even provide for the generation of this documentation into multiple formats simultaneously, such as HTML, XML, and of course Microsoft Word.
109
Supporting tools
The solution components that support automated documentation include both Rational ProjectConsole and the Rational Software Documentation Automation tool (SoDA). These tools do exactly as described above. Using each of the respective product APIs, each reporting product can access all of the artifact repositories for exposure of the artifact details. The solutions can be used to assemble charts or documents to formulate nearly any style report to serve the needs of the stakeholders.
Rational ProjectConsole
The ProjectConsole enables the development team to automatically quantify the current project status and assess development trends. Measurements are automatically collected from the Rational development environment and selected third-party tools, and then stored in a data warehouse. The Rational ProjectConsole hyperlinks all artifacts together and displays the analysis in charts, indicators, and tables as your team Web site is automatically created and updated. The ProjectConsole automates reporting on project status, dynamically creating a project Web site with a graphical dashboard based on data you collect. This reduces the time to build, update, and maintain a team Web site, plus the time and effort of manually gathering status updates. The ProjectConsole collects both standard and custom metrics from your Rational Team Unifying Platform (TUP) and third-party products, presenting the results graphically so that you can easily assess project progress and quality. This allows you to better predict which areas will require special attention and where to focus scarce resources to stay on schedule. More importantly, ProjectConsole enables you to make decisions based on quantitative analysis, rather than subjective status reports. To learn more about Rational ProjectConsole and Team Unifying Platform refer to:
http://www-306.ibm.com/software/awdtools/team/client/ http://www-306.ibm.com/software/awdtools/team/
110
You can also visualize the planned-versus-actual measures, trace historical data trends, and view cross-discipline measures to get a better view across the entire project. These capabilities enable your software development team to take prompt corrective actions and realize the cause for late deliverable.
Rational SoDA
Rational SoDA is a project-wide documentation automation tool, and is part of the supporting foundationthe IBM Rational Team Unifying Platform (TUP). Its interface leverages well-known, powerful publishing tools. SoDA generates documents by extracting the requested data directly from the tool's data repositories. Some of the features of SoDA are: It automatically generates documents and reports in HTML format. Its templates encourage the standardization of document types within a project or throughout a company. It is customizable to comply with individual project's standards. It regenerates precise, up-to-date documents easily. It preserves additional data entered directly into the document. To learn more about Rational SoDA refer to:
http://www-306.ibm.com/software/awdtools/soda/
Supporting process
Documentation is provided as reports and documents:
111
Conclusion
Table 3-7 shows the control principles for documenting results.
Table 3-7 Control principles for documenting results Control principle Benefits Documenting results Objective project status. All team members can generate comprehensive reports that span across products. Documents are never obsolete. Always reflect up-to-date status of the system. Facilitates collaboration across teams. Support to business decision. Create templates for documents and Web site. Real-time documents and reports. Manually creating and updating documents. Transparency of reporting. SDLC process maturity and stability. Adherence to the defined process by artifact creators/SDLC. Linkages between supported tools using tool-directed behavior compliance.
112
Compliance Risk
Policy Documented Process Automated Procedures Demonstration Of Control Proof of Due Diligence
Business Response
IT Response
BDD for Compliance Solution Support RUP and/or Customer Methods Rational Tooling Say what you do Do what You Say
Plan
Software Business Procedures Methodology Business Development Tool Applications Directed Behavior Business Transaction Data Business Reports
SDG
Define
Enable
Dev Project/Tools Automated Artifact Traceability Artifact Linkages Measurement Plans Project & Process Analytics Reporting Be able to Prove it
Measure
Although the IBM BDD for Compliance solution is a complete framework, organizations are able to select those components that best fit their immediate needs for implementation. The solution is designed for incremental adoption, such that each component can be added over time, and yet provide seamless integration to the previously existing components implemented. No matter which tool is selected, the process component always plays an important role, providing guidance on how to use these components all together. Customers can, and have, executed initiatives to implement the entire solution as phased implementation engagements.
Three-phases approach
The minimum number of phases to accomplish such an implementation is three, although it is possible to have as many as ten phases. The difference between these approaches is simply a function of the number of tools selected and implemented at any one time. Success depends upon the technical sophistication of the team, the degree of compliance that currently exists, and the organization's need to change.
Phase I
During a three-phases approach, in phase I you establish a project management plan for the execution of the tasks required to assess your current infrastructure, relative to the current best practice in each of the RUP disciplines.
113
Your assessment should consider the following areas: Software development life-cycle methods and consistency across the organization Program and portfolio management best practices Requirements gathering and management best practices Architectural analysis methods and systems analysis and design Application modeling and simulation Change request and configuration management best practices Build management and environmental configuration Systems testing and validation Release management and application deployment The objective is to take an inventory of current practices and compare them to existing industry best practices to evaluate what is working and what might stand for improvement. Provided that there is a desire to begin documenting a new integrated process, this is the time to initiate such an effort.
Phase II
Once sufficient information is gathered from the investigative phase, you can begin to prepare for phase II. During phase II a subsequent project plan is constructed based upon what has been learned, to begin assembly of your integrated compliant process design, and to begin establishing the tooling infrastructure required to support that process. This can be accomplished through one of two methods, typically: It can be initiated by consuming the default configuration of Rational products and consumption of the Rational Unified Process as the standard process for the organization. Alternately, the tools can be configured to support any existing process, although one should expect that those existing processes that do not conform to current best practice should not be tolerated. To ensure appropriate deployment of the Rational tooling, the following areas require further investigation and planning based on current organizational activities, release schedules, and so forth:
Environment specificationIBM should work with your management team, administrators, and IT personnel to assess the computing infrastructure; determine where to install software components; and document these decisions in an environment specification report.
114
Usage model definitionIBM should work with the management team and designated personnel to define how the solution is to be used on specified pilot projects, and document these decisions in the usage model report. Installation and configurationIBM should also work with the management
team and administrators to install the software components for the prototype solution according to the environment specification report and configure the tools according to the usage model report.
Rollout to end-usersIBM will work with the designated members of the team
to train and mentor end users on how to use the solution in their daily work, including not only the basic tool usage, but to incorporate specific workflow training regarding any new processes.
Administration planningFinally, IBM should work with members of the IT staff and the designated Rational tool administrators to plan for the administration and maintenance of the IBM Rational environment. Phase III
Phase III is an optional component to the process. During phase III we revisit those areas where the technology is being utilized, and critically examine whether the goals and objectives defined for the implementation are being satisfied. In the event that the organization has found an issue with the operation of the solution, IBM can be called upon to evaluate these issues and discuss approaches for mitigating those risks that have been identified. Areas examined during a phase III engagement include:
AdoptionHow well has the process and associated tooling been adopted? UsageHow well is the organization adhering to the documented process, and how well is the configuration supporting that process? PracticesFor those practices that cannot be enforced through tool direct behavior, how well is the organization doing in adhering to the documented best practices for these activities? EnvironmentHow well is the current environment holding up to the
expanded usage of the tooling?
115
Table 3-8 Providing evidence through automation of control principles Principles IT governance Automated by tools Portfolio Manager Features Track change progress. Manage risk. Provide evidences Evidence of SDLC process maturity and stability Transparency of reports Linkage between artifacts that align with the business process steps
Requirement management
Business needs better mapped into supporting systems. Regulations, standards, policies and requirements central repository. Change management to policies and regulations. Record and trace application requirements for compliance mandates. Audit trails. Electronic signatures. User authentication, authorization, and data control. Defect and change management. Baseline, reporting, build auditing, project policies and triggers. Automated and controlled deployment.
ClearCase+ ClearQuest
Accountability on the chain of delivery Documented and formalized handoffs and signoffs
Deployment management
Accountability on the chain of delivery Documented and formalized handoffs and signoffs Documented SDLC process for creating all business artifacts Documented test results to requirements linkage
Software validation
Creates test plans based on requirements. Automates functional and performance requirements validation.
116
Features Provides guidelines, best practices, and common process. Communicates workflow and interactions through diagrams. Browser-based, providing accessibility for all users. Define data collection, analysis, and reporting procedures into indicators and reports that are automatically organized and updated on the Web or in Word documents. Data collection for reports and documents in a non-intrusive manner. Well updated and valid information for decision makers. Improve communication by sharing a common project and initiatives, status, and information among team members.
Provide evidences Documented SDLC process for creating all business artifacts Process linkages to automated process supported by tool mentors Transparency of reporting SDLC process maturity and stability Adherence to the defined process by artifact creators/SDLC Linkages between supported tools using tool-directed behavior compliance
Documenting results
Each solution might be customized for each customer. To accelerate its adoption IBM offers a service package described at:
http://www.ibm.com/software/rational/services/professional/index.html
The level of formality for these process components might also vary according to the organizations characteristics and implementation strategy followed (Figure 3-15).
117
High Trust
High Security
Control points lack e-sig authentication Shared access to many artifacts Forensic documentation sufficient High-level traceability sufficient
As more and more customers recognize the value of governance and compliance, they are increasingly interested in moving from environments and operational models in the bottom left quadrant to the upper right quadrant where there is a higher degree of both security and ceremony. The quadrant that any particular organization will select is dependent upon their particular business needs and available resources to execute. Those who have not done so in the past should consider adopting an iterative approach to implement process solutions like these. The advantage is that it allows the organization to consume technology while simultaneously receiving feedback from auditors during its adoption.
Extensibility
Those organizations that desire to operate at the cutting edge of technology or have needs for extremely formalized procedures may desire to implement customizations on top of the IBM BDD for Compliance solution. Due to the modularity of the IBM solution custom tailoring can be carried out by either IBM or appropriate IBM business partners. For more information about Eclipse and IBM Rational tools visit:
http://www.ibm.com/software/rational/eclipse/
118
Chapter 4.
119
120
The key capabilities that make this possible through the use of Rational tools are:
Verifiable software builds to help ensure and document that software developed was actually deployed Automated deployment that is fully integrated into the development process Continuous validation of compliance mandates through integrated test
management
A fully integrated process and product audit console solution for the process
and development artifacts
Compliance roadmap
The compliance solution presented here supports all three dimensions of business-driven compliance for software development:
Say what you doDemonstrate that all compliance mandates are accurately
captured and implemented in key applications.
121
Roles
This section provides an overview of the roles within this framework. A role defines the behavior and responsibilities of an individual or a group of individuals working together as a team within the context of a software engineering organization:
Business analystDetails the compliance project application requirements, and establishes priorities and workflow around the in scope requirements. ImplementerDevelops software components and performs developer testing for integration into larger subsystems, in accordance with the project's adopted standards. Technical leadA senior designer/implementer for an application. This role has both technical and managerial responsibilities. This role guides and oversees development of application software components. The technical lead is responsible for approving the code changes and completing the change requests. IntegratorLeads the planning and execution of implementation element
integration to produce builds.
Release managerResponsible for collating the released work products from multiple projects, to produce a release that can be delivered into the production environment. Owns the release management process and has the responsibility and authority for the overall process results. The release manager is responsible for the overall quality of the process. This role is also the main coordinator within this process and is the focal point regarding releases for both the customer and the IT organization.
122
Deployment managerDelivers the software release into the production environment. The deployment manager works alongside the release manager and deploys the release under his authority. TesterConducts tests and logs the outcomes of testing. Test managerLeads the overall test effort. This includes quality and test
advocacy, resource planning and management, and resolution of issues that impede the test effort.
AuditorResponsible for inspecting the business operation. A primary objective for an auditor is to determine whether the business complies with company policies. An outside auditor may be seeking to determine compliance with regulations, standards, and policies.
Capability patterns
Capabilities patterns express and communicate process knowledge for a key area of interest such as a discipline or a practice and can be directly used by practitioners to guide their work. Examples for capability pattern are: Use case-based requirements management Use case analysis Unit testing Capability patterns cover the set of activities that is required to deliver an auditable change for the project. There are eight capability patterns in our solution for compliance. The main objectives for these use cases are:
Process modeling and design for complianceDocument a method for defining an IT governance process in accordance with applicable process standards, frameworks, and regulations. Manage compliance portfolioPerform compliance/governance activities while ensuring alignment of compliance initiatives with the organizations strategic business priorities. Manage projectsUse templates and embedded process controls and
measures to ensure repeatable and auditable project and risk management processes for compliance projects.
123
Securely deploy a releaseBuild applications and securely move the build from the development environment to test and finally to production while providing traceability from the production back into the development environment. Validate automated business controlsActivities include validating the business rules and approving or rejecting the release. Manage and generate metrics and reportsDefine organizational metrics for
management reporting and performance analysis. Refer to Appendix A, Unified Method Architecture on page 163 for more information about capability patterns.
Rational tools
The IBM Rational tools that are used in the IBM BDD for Compliance solution were introduced in Chapter 3, IBM Rational's key capabilities for compliance management: Rational Portfolio Manager on page 71 Rational RequisitePro on page 75 WebSphere Business Modeler on page 78 Rational ClearQuest on page 81 Rational ClearCase on page 82 Rational BuildForge on page 90 Tivoli Provisioning Manager on page 90 Rational ClearQuest Test Manager on page 94 Rational Functional Tester on page 99 Rational Manual Tester on page 100 Rational Performance Tester on page 100 Rational Method Composer on page 106 Rational Unified Process on page 106 RUP Plug-in for Compliance Management on page 107 Rational ProjectConsole on page 110 Rational SoDA on page 111
124
Solution details
Now that we have introduced the roles, capability patterns, and provided an overview of the Rational tools used as part of the compliance solution, we are ready to discuss the details of our compliance solution. For each capability pattern we list the challenges that are addressed and the evidence that must be provided as part of the audit process. We also discuss the Rational tools that we use in our solution to achieve compliance.
<<Tool Stack>> RationalMethod Composer Rational RequisitePro Rational ClearQuest Rational's Testing solution
125
Objectives
The objective is to be able to prove compliance by providing the following evidence: Evidence of appropriate processes Design and development methodology (for example, written and documented software methodology, or written controls) Documentation and records managementResponsibility for generating, maintaining, and controlling documents Training and educationFormal system to enable all personnel to perform assigned functions MaintenanceSupport organization and mechanisms to assist customers Evidence of current good practices (CGP) for project management Utilization of formalized planning methods for process design and work breakdown structure
Challenges
Some of the main challenges for governance process design and utilization are: Absence of a single process that meets the business compliance requirements Inability to ensure that practitioners conform to defined methods Inability to monitor process execution Absence of consolidated reporting on process metrics One of the greatest challenges in most organizations is the disconnect between the software development organizations and other parts of the organization, such as IT operations. The challenge from a compliance perspective is that neither auditors nor inspectors care about organizational boundaries, if such boundaries present a risk of malfeasance. Note that the audit is directly aimed at the software development life cycle, as we discussed in Chapter 2, Compliance guidelines on page 29. Because critical information and business controls are implemented and stored in the IT applications, nearly all audits turn into a defacto audit of IT applications and package development. Thus, if an organization is to ensure appropriate protection for its stakeholders, a comprehensive shared process must be defined that crosses the organizational and governance boundaries.
126
Another significant challenge for most companies is the absence of any process specifically designed to meet their particular needs. Government regulations present no concrete actionable plan for the implementation of process. Furthermore, many pieces of legislation, such as Sarbanes-Oxley, cross multiple industrial domains or verticals. Consequently, differing practices and processes for business operation must be accounted for. This is the reason that most organizations seek out solutions designed to meet the specific, well-recognized, and accepted process frameworks and process standards for their specific industry. COBIT is an example of a well-recognized framework used for SOX, as we discussed in Chapter 1, A discussion about compliance on page 1. In some cases the businesses have to establish several different standards and frameworks such as ITIL, COBIT, and IISO 900x to achieve the integration between SDLC and IT governance.
Discussion
To integrate a process that is designed to meet such requirements using IBM Rational tools, perform these activities:
127
Activities
Table 4-1 shows the roles and tasks that are performed to achieve the objectives for process modeling and design for compliance.
Table 4-1 Roles and tasks in modeling and design for compliance Roles Process engineer Activities 1. 2. 3. 4. Analyze process requirements. Integrate process and methods. Document methodware and process. Automate process or workflows.
Tester
Conclusion
Table 4-2 shows Rational tools that can help provide the evidence to prove compliance when documenting and defining an IT governance process, in accordance with applicable process standards, frameworks, and regulations.
Table 4-2 Conclusion: process modeling and design for compliance Requirements Evidence of appropriate processes Design and development methodology, for example, written and documented software methodology or written controls Documentation and records management: assigned responsibility for generating, maintaining, and controlling documents Training and education: formal training to enable all personnel to perform assigned functions Maintenance: support organization and mechanisms to assist customers Rational capability RUP - RMC configured IT governance w/RUP and ITIL/ITUP Standards-based configurable methodware ensures documented processes can be found by all roles within the organization Tool mentors with templates ensuring consistent tool usage among practitioner Tool-directed behavior ensuring behavior is aligned with method and consistent among users and groups
128
Requirements Evidence of current good practices for project Management: institution of formal planning methods
Rational capability RPM configured project Exported work breakdown structure (WBS) from RMC ensuring linkages between project plans and roles, tasks and activities Near real-time project tracking
Objectives
The objective is to be able to prove compliance by providing the following evidence: Evidence of appropriate risk management Implementation of a risk-based (risk reduction/removal) approach to compliance Evidence of project management Institution of formal planning methods Evidence of process adherence
129
Challenges
Some of the main challenges for the portfolio management activities of IT governance are: Difficulty assessing application compliance impact on business This is the task of determining how much of a problem a given compliance issue will be to the business. Difficulty selecting systems and organizations for change How to develop a profile of how well a particular organization or system satisfies predefined compliance criteria. Inability to evaluate proposal and project return on investment (ROI) relative to compliance mandates How to measure the potential improvement that could be realized by executing a proposal or continuing to execute upon an existing project. Inability to counterbalance investments in controlled or uncontrolled efforts Every business has a limited amount of resources. Consequently, it can be difficult to determine which projects or proposals you must invest in. This requires a careful balancing of cost and business investment.
Discussion
Successfully adopting a business-driven development approach for compliance requires close alignment of development and IT projects with business priorities, as discussed in Chapter 1, A discussion about compliance on page 1, and Chapter 2, Compliance guidelines on page 29. It also requires visibility for executives into the status of assets, whether those assets are projects or applications, so that resources and investments can be applied to the highest priority activities. IT needs the ability to manage with a seamless process from discovery to development to deployment and beyond (Figure 4-3).
130
Business View Clear view of technology ROI Top-down and bottom-up visibility into technology projects Objective decision-making support Operations View Improved service and quality compliance Predictable deployments Accelerated diagnosis and repair Application Development View Rapid application development and deployment Improved collaboration Asset reuse
Business Analysts
The IBM Rational solution provides the comprehensive visibility that companies need to bridge the gap between business and IT, combining: Project portfolio management (PPM), which provides the ability to prioritize, plan, manage, and measure projects as a comprehensive portfolio Application life cycle management (ALM), which bridges the gap between development and post-deployment by providing both with a comprehensive set of development tools This will provide the top-down visibility from PPM with the bottom-up development tool data and application monitoring capabilities of a complete ALM solution (Figure 4-4).
131
IT
Figure 4-4 Connecting business, development, and operations
We observe at least seven process areas that all organizations seek to support with their project and portfolio management efforts: Manage portfoliosAchieve the business vision. Align priorities, projects, and resources with business priorities to meet organizational needs. Manage scopeDeliver business value. Seamlessly evolve ideas, proposals, initiatives, and requirements to measurable programs and projects. Manage workPlan a balanced approach. Plan, cost, budget, resource, schedule, and report on programs, projects, and procurements. Manage resourcesOptimize your staffing profile. Utilize staffing profiles for effective resource assignments and comprehensive capacity planning. Manage financialRegulate your financial health. Manage charge of accounts with time keeping, expense, and capital expenditure tracking. Manage exceptionsReact to changing needs. Capture, quantify, assign, collaborate and communicate, and track actions, issues, risk, constraints, opportunities, and changes in a workflow model.
132
Manage qualityTrack the expected results. Ensure that customer priorities get the attention that they deserve with the right process execution. Some organizations may be more rigorous in some processes than others, and most organizations are challenged by a lack of consistency in how these processes are practiced across projects. They have either failed to codify their best practices for these processes or they have them in a document somewhere that few take the time to read and fully apply. Rational supports project management process standards such as the Project Management Body of Knowledge (PMBOK) of the Project Management Institute (PMI), the Rational Unified Process, and the IBM Global Services World Wide Project Management Method. Rational Portfolio Manager helps customers facilitate and automate these best practices. Utilizing scorecards in Rational Portfolio Manager, one can develop a profile of how well a particular organization or system satisfies predefined compliance criteria and be able to forecast how much potential improvement could be realized by executing a proposal or continuing to execute upon an existing project. By combining multiple scorecards for organizations, projects and proposals, and existing project/proposal investments, one can construct a view that would present the optimal combination of investment for compliance and return on investment (ROI). Similarly, this solution space takes on the individual project efforts in addition to the enterprise portfolio view to minimize risk (Figure 4-5). The PMBOK core processes are identified by some analysts as your base set of functionality areas critical to a PPM tool. We can leverage this collection of processes as a well-known and proven framework for describing our functional capabilities.
133
Balance portfolios, prioritize investments Align resources with strategic enterprise objectives Make timely, informed decisions based on accurate project data Ensure best practices are repeated for all management processes Input and track time and expense Leverage reusable process templates for collaboration and communication Generate accurate, objective status data
Development Environment
Managing investments and balancing cost across the entire portfolio of an organization's IT assets is an important aspect in IT governance. In recent years, this responsibility has expanded to include executive oversight of the multi-year effort required to implement regulatory changes across the organization, controlling costs, budget, and delivery. As we discussed in Chapter 1, A discussion about compliance on page 1, auditors want to see how you manage oversight for your IT compliance projects. Rational Portfolio Manager (RPM) makes effective IT oversight a reality with the ability to prioritize, track, and manage compliance projects across the IT portfolio by: Managing tasks and resources Tracking effort expended and maintaining artifacts created Managing schedule and milestones against deadlines Minimizing overhead and automating development flows When RPM is used with other IBM Rational tools, it provides organizations with a 360-degree view of their evolving compliance project status.
134
In addition, RPM brings executive, management, and team member processes into one integrated environment to achieve the business vision to: Deliver business value. Plan a balanced approach. Optimize the staffing profile. Regulate the financial health. React to changing needs. Track the expected results. Finally, RPM can be used to measure the success and health of compliance-related projects: Executive oversight of compliance initiatives across divisions, departments, geographies. Identify IT projects based on compliance risk. Review and compare proposals/projects for ROI. Figure 4-6 shows an investment map (bubble chart) in RPM that is a graphical depiction of the project status.
Rational Portfolio Manager
135
Figure 4-6 shows several dimensions including size in dollars, size in relation to other projects, and current health (red, yellow, or green). The settings for the investment maps have many options, and multiple maps can be built. The lower portion of the screen is pie charts showing budget, work, and schedule variances. In the live system, clicking any of these charts will take you directly to the details of the underlying item.
Activities
Table 4-3 shows the tasks that are performed to achieve the objectives for process modeling and design for compliance.
Table 4-3 Roles and tasks in portfolio for compliance Roles Portfolio manager Activities 1. Acknowledge business issue. Precondition: Raising a business issue by the auditor 2. 3. 4. 5. Analyze stakeholder request. Develop and rank proposals. Convert proposals to projects. Close business issues. Precondition: Deployment to production by the deployment manager
Conclusion
Table 4-4 shows that Rational tools can help provide the evidence to prove compliance when aligning compliance initiatives with organization strategy and business priorities.
Table 4-4 Conclusion: managing compliance portfolio Requirements Evidence of appropriate risk management Implementation of a risk reduction approach to compliance Rational capability RPM configured Scorecards for organizational units Scorecards for projects and proposals Portfolio analytics for compliance Evidence of project management Institution of formal planning methods RPM-configured project Exported work breakdown structure (WBS) from RMC ensuring linkages between project plans and roles, tasks and activities
136
Requirements Evidence of process adherence Implementation of adequate project monitoring and status
Rational capability RPM configured project Near real-time project tracking, leveraging timecards linked to method-based tasks
Manage projects
This scenario describes how a project manager uses templates, embedded process controls, and measures to ensure repeatable and auditable projects and management processes for compliance projects. Figure 4-7 shows the use case diagram.
Manage Project
<<IBM Tool Stack>> Rational Portfolio Manager Rational RequisitePro Rational ClearQuest
Objectives
The objective is to be able to prove compliance by providing the following evidence: Evidence of management of development process for a project Collecting, validating, triaging, and prioritizing change request including enhancement requests and defects Evidence of project management Institution of formal planning methods Evidence of plan adherence Implementation of adequate project monitoring and status reporting
137
Challenges
Some of the main challenges for managing compliance projects are in the area of: Managing a controlled change process Enforcing approvals and controls Traceability across the life cycle of the original change requests, to the compliance requirements imposed on the application, to the implementation and associated testing Capturing compliance metrics and controls Enforcement of policies through phase gates
Discussion
The basic workflow for this use case is discussed next.
Initiate projects
Identify and assign a project team (affect at project level). Identify and implement all mandatory reporting and tracking requirements. Set up all required links and projects in other Rational tools: Rational Portfolio Manager Rational ClearQuest Rational RequisitePro
138
Calculate and level project schedule. Validate project duration and costs against expected budgets and targets. Perform planning stage gate approval workflow. Baseline project schedule, resources, and costs. Copy proposed plan and commit resources.
Activities
Table 4-5 shows the tasks that are performed to manage projects.
139
Table 4-5 Roles and tasks for managing projects Roles Project manager Activities 1. Initiate a project. 2. Plan a project. 3. Execute and control a project. 4. Close a project.
Conclusion
Table 4-6 shows Rational tools that can help provide the evidence for repeatable and auditable project and management processes for compliance projects.
Table 4-6 Conclusion: Manage projects Requirements Evidence of management of development process for a project. Collecting, validating, triaging, and prioritizing change request including enhancement requests and defect. Rational capability ClearQuest configure project is used for change management including: Collecting change requests including enhancement requests and defects. Validating, triaging, and prioritizing change requests. Establishing traceability between compliance requirements and ClearQuest request for enhancement (RFE). Use Rational RequisitePro and ClearQuest integration. Evidence of project management Institution of formal planning methods RPM configured project Exported work breakdown structure (WBS) from RMC ensures linkages between project plans and roles, tasks and activities.
140
Requirements Evidence of plan adherence Implementation of adequate project monitoring and status reporting
Rational capability Using Rational Portfolio Manager Monitor predefined compliance conditions using reports and automated triggers. Authorize any template or workflow changes that affect the compliance model. Enforce the policies controlling the phase gates by management in RPM.
141
Objectives
The objective is to be able to prove compliance by providing the following evidence: Evidence of processes conformance Implementation of workflow automation Tool-directed behavior (TDB) Artifact approval Artifact quality gating
Evidence of artifact linkage Tool-directed artifact linkages Chain of traceability on completed artifacts
Challenges
Some of the main challenges in this area are: Processes are documented, but nobody will adhere to them. Different organizations or departments make up their own procedures. Cannot locate the sign-offs for specific artifacts. Cannot locate even the latest versions of requirements, designs, and changes that correlate. As companies seek to find more streamlined methods for operation, the reasons for some business controls can get lost over time. Although significant documentation exists in most organizations that outline standard procedures and sign-off of critical business controls, these are more often viewed as unnecessary bureaucracy rather than protections for the business and employees.
Discussion
Through the implementation of workflow automation that implements tool-directed behavior, you protect the business from lackluster controls or circumvention by practitioners. TDB is a term used in regulatory domains described as the implementation of documented workflow via automation, such that the defined process cannot be circumvented, and defined artifacts can only be created through prescribed tooling.
142
Automated workflow can do several good things, besides ensuring that workflow is adhered to: TDB ensures that appropriate authorization points are not bypassed, and it can be used later to demonstrate to auditors that certain tasks were actually started or completed, as a result of what is documented. TDB and automated workflow can also ensure proper linkage of differing artifacts in the correct sequence. This becomes important downstream, when it can become necessary to reconstruct sequences of events in order to determine the what and when on a specific transaction Create artifact relationships that cannot be created any other way. For example, this is the case between the RequisitePro and ClearQuest integration. Unless the TDB enforced by the ClearQuest integration server is invoked, the data can never be applied to either RequisitePro or ClearQuest.
Activities
Table 4-7 shows the roles and tasks that are performed to achieve the objectives for process modeling and design for compliance.
Table 4-7 Roles and tasks in initiate compliance project Roles Project manager Activities 1. Initiate development. Precondition: Project approval by portfolio manager 2. Schedule release. Precondition: Create change request by business analyst 3. Schedule change request Business analyst 1. Analyze stakeholder requests. Precondition: Initiate development by project manager 2. Design automated controls. 3. Create change requests.
Conclusion
Table 4-8 shows Rational tools that can help provide the evidence to prove compliance when tracking the definition, design, and implementation of the compliance requirements from requirements elicitation through deployment.
143
Table 4-8 Conclusion: Initiate compliance project Requirements Evidence of processes conformance Implementation of workflow automation Tool-directed behavior in workflow Controlled artifact approval Artifact quality gating Tool directed artifact linkages Chain of traceability on completed artifacts Rational capability ClearQuest configured Workflow designed to match method workflow. Integration to requirements tooling ensures artifact linkage can only occur one way. Workflow approval with role separation in ClearQuest. RequistePro and ClearQuest Integration Artifacts linkages created via tool integration Evidence of requirements satisfaction Evidence that system is fit for its intended use Documented linkages between business drivers and business controls RPM configured project Exported work breakdown structure (WBS) from RMC ensures linkages between project plans and roles, tasks and activities. Near real-time project tracking.
144
<<BusinessActor>> Implementer
Objectives
The objective is to be able to prove compliance by providing the following evidence: Evidence of appropriate configuration management and change control process Documented methods for configuration, change, and version management Implementation of appropriate role-based structures and separation of responsibilities Management of releases, configuration items, source, and documentation Evidence of adherence to change management procedures Process metrics, evidence of control points, such as sign-off or code walkthrough Process metrics gathering Evidence of metrics for process monitoring and optimization
145
Challenges
Some of the main challenges in the area of configuration management and change control are: Inability to manage multiple concurrent releases, deployments, and platforms simultaneously with high quality Inconsistent change control procedures, a team using multiple processes and likely multiple tools Inability to change control file system structures Absence of integration between IT operations and development Inability to prove what code versions were deployed into production In typical non-regulated environments you hear plenty of stories about developers crushing changes implemented in production, regressions in product, and the inadvertent releases of non-production quality code. In regulated environments this is unacceptable.
Discussion
Industrial strength configuration management procedures and processes must be implemented to protect the interests of all of the stakeholders of the business. These stakeholders include product or service consumers, senior executives or managers accountable for business controls, or shareholders of a publicly traded company. At the heart of it all is the need to demonstrate due diligence in the design, development, testing, and handling of the application assets that implement automated business controls for the company. These controls are simply the bits of logic embedded in these applications. Therefore, in order to demonstrate due diligence and control over these bits of logic, a company must show appropriate configuration management and change control over all of the assets used in the implementation of the automated systems. Furthermore, it is not enough to simply implement a version control system. Version control simply implements a librarian function against code which can help in locating a problem after it has occurred. Appropriate integrated change management and configuration management processes are designed to reduce or eliminate the possibility that such catastrophes occur in the first place. Figure 4-10 shows a strategy for instituting release management, deployment control, configuration management, and change request management including the three points of control, as discussed in The three points of control strategy on page 54.
146
Activity
Submitted
Assign
Deployment
Submitted
Assign
Assigned
Open
Assigned
Open
Assigned
!2
W orking
Open
W orking
Complete
Opened
Complete
Complete
Completed
Verify
Completed
Approve
Completed
Deploy
Verified
Release
Approved
Deliver
!1
!3
Deployed
Close
Released
Delivered
Closed
Release managementDeals with the coordination of multiple concurrent enhancements, defect corrections, or other changes to a target application. Deployment controlDeals with the synchronized release of applications to
the product environment itself, taking into account dissimilarities between the various platforms that a given application must operate on in a target technical environment. For example, a given financial clearing system used at the Mercantile Exchanges in New York and Chicago has client interfaces operating on Windows XP, MQSeries middleware running on DEC Alphas and IBM z/Series, databases implemented under DB2, and various extended client platform trading integrations via multiple Web servers. Each of these components of the application architecture requires a separate release, with coordinated deployment across these disparate platforms.
Change requestsDeals with high-level requests to modify the system, which may span the application architecture. These requests must then be broken up into one or more change requests, or activities as part of the Unified Change Management (UCM) workflow.
147
This style of comprehensive control ensures auditors and inspectors that the business understands the potential risks presented to stakeholders by inadequate code and configuration control. As we discussed previously, automated workflow can ensure proper linkage of differing artifacts in the correct sequence using Rational tools, as shown in Figure 4-11. These are must have capabilities when reconstructing sequences of events, for example, to determine what transactions took place at specific times.
Rational ClearQuest
Business Issue Release
Rational RequisitePro
Stakeholder Request or Compliance Requirement Feature
Rational CQTM
Test Suite
Activity
Change Set
EXE
Deployed
EXE
QA Environment
Production
Activities
Table 4-9 shows the roles and tasks that are performed to achieve the objectives to deliver auditable change for compliance.
Table 4-9 Roles and tasks from deliver auditable change for compliance Roles Implementer Technical lead Activities Code, review, and approve automated control. Precondition: Schedule change request by project manager.
148
Conclusion
Table 4-10 shows Rational tools that can help provide the evidence necessary for compliance by providing a foundation for an audit-ready software development infrastructure.
Table 4-10 Conclusion: Deliver auditable change Requirements Evidence of appropriate configuration management and change control process Documented methods for configuration, change, and version management Implementation of appropriate role-based structures, separation of responsibilities Management of releases, configuration items, source, documentation, and so on Evidence of adherence to change management procedures Process metrics, control points such as sign-off or code walkthrough Process metrics gathering Evidence of metrics for process monitoring and optimization Rational capability Rational Unified Process for ITG Appropriate documentation for all aspects of change are found in the exiting methodware and can be extended to include methods from other frameworks. ClearCase with unified change management Automated project and component definition ensures project containment and precludes development stream pollution. Workspace ownership enforces activity delivery controls. Version control at the file system level ensures that all artifacts must be checked-out for any changes to occur. ClearQuest configured for compliance Process monitoring and metrics can be derived utilizing the ClearQuest reporting interface. External reporting is supported through rational software documentation automation tool, RPM, Rational project console, or via crystal reports.
149
This use case also demonstrates how using ClearCase and ClearQuest change management software along with Tivoli Provisioning Manager for distribution software can help automate, streamline, and accelerate the software build/deploy process. We also show the use of a release record and e-signature capability. Figure 4-12 shows the use case diagram.
<<IBM Tool Stack>> Rational ClearCase Rational ClearQuest Rational BuildForge Tivoli Provisioning Manager
Objectives
The objective is to be able to prove compliance by providing the following evidence: Evidence of secure deployment Presence of consistent best practices for deployment Consistent tracking of platform configurations, patch levels, dependent software, and layered products Control of products deployed to secure regions including through multi-tiered firewalls Evidence of tamper-resistant production environment
Challenges
Some of the main challenges in the area of secure deployment of a release are: Absence of consistent best practices for deployment
150
Inconsistent platform configurations, patch levels, dependent software, and layered products Difficulties with secure deployment of code beyond multi-tiered firewalls Deployment of servers from bare metal chassis Deployment to pervasive devices, such as palmOS, pocketPC, or mobile phone
Discussion
To overcome these challenges, we must capture best practices in automated deployment within the organization. Using Rational ClearQuest, ClearCase, BuildForge, and Tivoli Provisioning Manager together facilitates the build and deployment process and minimizes errors and inconsistencies that can arise during the course of your deployment. You can implement a process for managing the deployment of your release through your test environments using a Rational ClearQuest deployment record. A Rational ClearQuest deployment record enables you to track the set of build artifacts that you want to deploy through a link to a Rational ClearCase deployment unit (DU). Each time you build your release, you create a new DU in Rational ClearCase that contains a list of which versions of the build artifacts will be deployed. The Rational ClearQuest deployment record (DR) uses the Rational ClearCase DU to track which build artifacts are deployed to which test environment at any point in the project life cycle. BuildForge provides continuous monitoring of the IBM Rational ClearCase source repository, and executes builds automatically either when a change occurs or on a scheduled basis. The connection quickly and easily enables complete visibility and documentation of the code-build cycle. The adaptor gathers and reports source metrics for each software build. The adaptor interfaces directly with the IBM Rational ClearCase system through user-defined view specifications that are defined in the BuildForge user interface. Once the IBM Rational ClearCase views are established, they can be linked to BuildForge projects. For each of the views defined, BuildForge scans the specified list of VOBs at scheduled intervals for changed files since the last successful build for a project, and collects the file differences and check-in comments. The change data is stored in the BuildForge repository and is associated with the executed build. A document view of each build session is captured and recorded in BuildForge, called a bill of materials (BOM), which includes the associated IBM Rational ClearCase information. BuildForge can automatically detect IBM Rational ClearQuest activities that are part of a current build session by listing the activities that are associated with the designated view where the code resides. These activities are recorded during the
151
build process and are part of the build record stored in BuildForge. Upon successful build exit status, BuildForge can automatically advance the state of the associated IBM Rational ClearQuest activities to a resolved status, and include a note from the build session. The BuildForge adaptor for IBM Rational ClearQuest also supports e-mail notification. Rational ClearCase and ClearQuest enable you to track your software deployment through your specified test environments and to approve the deployment as needed, providing audit trails for your software assets that satisfy regulatory compliance requirements. You could then deploy your application to a production system by integrating Rational ClearCase and Rational ClearQuest with a software provisioning solution such as Tivoli Provisioning Manager. This integration automates your deployment process for your specific servers. Tivoli Provisioning Manager is a resource management solution that provides core automated provisioning capability for corporate and Internet data centers. It coordinates and provisions assets based on your defined business processes. You can use Tivoli Provisioning Manager to provision, configure, and deploy a release into your production environment. Tivoli Provisioning Manager introduces the concept of workflows. You can use workflows to automate and consistently repeat configuration and deployment tasks that you currently perform manually. Tivoli Provisioning Manager provides workflows that you can customize to support your existing tools and processes. You can also create new workflows. Workflows can automate processes from configuring and allocating servers, to installing, configuring, and patching software, and can be either large and complex or can consist of a single command. The workflow framework enables you to manage your data center infrastructure. A data center infrastructure is made up of devices and integrated systems, called data center assets. Data center assets include both physical and logical assets: Servers that support managed applications Network devices such as switches, routers, load balancers, and firewalls that support communication between servers and applications Logical assets such as subnetworks and ports Service access points and access control lists that support secure data transmission Software products, software stacks, and software service releases Storage devices
152
The Rational ClearCase integration with Tivoli Provisioning Manager enables you to extract versioned file elements from Rational ClearCase and import them into the Tivoli Provisioning Manager deployment environment, ensuring that the correct versions of your files are deployed. The Rational ClearQuest integration with Tivoli Provisioning Manager does the following: Enables Tivoli Provisioning Manager to check for deployment approval status in Rational ClearQuest, ensuring that your deployed release meets established quality standards Enables workflows to be represented as Rational ClearQuest records, facilitating deployment tracking and reporting Enables traceability between workflows and Rational ClearQuest deployment records, providing an audit trail that helps satisfy your organization's process and regulatory compliance requirements
Activities
Table 4-11 shows the roles and tasks that are performed to achieve the objectives for securely deploying a release for compliance.
Table 4-11 Roles and tasks for securely deploying release Roles Integrator Release manager Deployment manager Activities 1. Build application. Precondition: Code automated controls by implementer/technical lead 2. Deploy to test environment (sign-off). 3. Complete release (sign-off). 4. Deploy to production (sign-off). Precondition: Verify release by Test manager
Conclusion
Table 4-12 shows Rational tools that can help provide the evidence necessary for compliance by providing a foundation to securely deploy a release.
153
Table 4-12 Conclusion: securely deploying a release Requirements Evidence of secure deployment: Documented best practices for deployment Configuration accounting, irrespective of platform configurations, patch levels, dependent software and layered products Control of products deployed to secure regions including through multi-tiered firewalls Rational capability Rational ClearCase, ClearQuest, and BuildForge Facilitates the build and deployment process and minimizes errors and inconsistencies Provides traceability between build record and deployment record Provides control points for approval before deploying to QA and production Tivoli Provisioning Manager Automated deployment utilizing software package blocks for reusable deployment scripts. Documented deployment logic via automated logic blocks. Control over third-party deployment mechanisms, for example, Microsoft automatic deployment services and remote installation services Enterprise directory support providing software distribution and inventory operations to be targeted by user Evidence of tamper-resistant production environment: Implementation of appropriate security measures on core production components Tivoli Provisioning Manager Monitors deployed resources and will automatically redeploy modified elements should they be changed in any form
154
Validate Compliance
Objectives
The objective is to be able to prove compliance by providing the following evidence: Evidence of adequate testing procedures Documentation of testing procedures Evidence that systems are fit for their intended use Linkages between system requirements to test results Examination of test results sign-off
Challenges
Some of the main challenges for the automated validation of business controls are: Inadequate ability to determine test motivation or to document requirements requiring tests Lower test quality because of rapid development of applications and aggressive schedules Inadequate management mechanisms for the support of multi-platform applications and configurations for each test
Discussion
A first important question to answer is Why should you create and run a given test? In other words, What is the driving force for the test? The most common reason is because there is a system requirement that says The system should do X, therefore you should have a test for X.
155
It is essential to establish the following linkage when a feature or use case supports a compliance initiative: Establish a link between the test and the motivator. The motivator can be requirements in RequisitePro, for example. The objective is to be able to identify and to re-evaluate the test whose motivator has changed. This can be facilitated by having a link between the motivator and the test artifacts such as test plan, test case, and configured test case. Establishing a link enables requirements coverage reporting. Establishing the reason for the test case also enables you to do requirement coverage reporting. With the link established, you are able to see which of your requirements pass, which requirements fail, and which requirements are not tested. This type of information is invaluable to have when it comes to release time. Rational CQTM queries can be used to identify tests requiring re-evaluation by determining if a new revision of requirements has been established. CQTM out-of-the-box query called requirements coverage can be used to show requirements and their related test artifacts for requirement coverage reporting. The next question to answer is Where should you run a test? That is, on what workstation should the test execute and what are the specific attributes that specify the makeup of a workstation? Configuration testing can be very difficult to manage. Testers often have hundreds of tests that must be executed on a variety of different workstations and, in some cases, the details of the test cases are different depending on the workstation where the test is executing. An important strength of Rationals testing solution is the ability to maintain the information regarding the location of test execution. Rationals solution allows testers to define the configuration information for the workstations that they must test, including attributes such as operating system, browsers, disk space, and memory. They then select which configurations a test case, or group of test cases, must execute on. Next, a tester can specify, if needed, different test case variations for different types of workstations. Finally, ClearQuest TestManager (CQTM), Rationals newest test management solution, acts as a gate keeper, ensuring that the correct test case is executed on the correct configuration. Perhaps the more important question about a test case to answer is, What test cases run first? In other words, what are the guidelines for prioritizing test cases? CQTM allows users to assign priority to tests. The higher the priority, the more important the test. CQTM also recognizes that while a test case requires some
156
status such as pass, fail, or blocked for reporting purposes, it also recognizes that a test is rarely a 100% pass or fail. Results are not often so black and white. As a example, sometimes a test case will pass, but the tester may spot some small flaw along the way. To handle these types of situations, CQTM can be configured by adding additional fields to be used to indicate how much of a pass or fail a test really is.
Activities
Table 4-13 shows the roles and tasks that are performed to achieve the objectives for validating automated business controls for compliance.
Table 4-13 Roles and tasks for validating automated business controls Roles Test manager Activities 1. Perform tests. Precondition: complete release by release manager 2. Verify change requests. 3. Verify release (sign-off).
Conclusion
Table 4-14 shows Rational tools that can help provide the evidence necessary for compliance by providing a foundation to validate automated business controls.
Table 4-14 Conclusion: Validate automated business control Requirements Evidence of adequate testing procedures Documentation of testing procedures Evidence that systems are fit for their intended use Linkages between system requirements to test results Examination of test results sign-off Rational Capability Rational software quality solutions Tool mentors document best practices for use of Rational testing tools with rational methods. Utilization of CQTM integrations to RequisitePro, ClearQuest ensure appropriate documentation of test motivation. Support for both manual and automated tests with aggregation of test results in a single interface ensures complete coverage of business controls testing. Use of Rational ClearQuest workflow can serve as the sign-off required to allow applications to move forward toward production.
157
Generate Measurement and Control Metrics <<BusinessActor>> Project Manager <<IBM Tool Stack>> Rational Method Composer Rational Project Console
Objectives
The objectives are: Evidence of appropriate measurement plans Documented measurement plan, controls, and processes Evidence of quality metrics program Consistent data gathering and reporting program including distribution analysis, trend analysis, and aging analysis
158
Challenges
Some of the main challenges for the automated validation of business controls are: Absence of a single process that meets the compliance requirements Inability to ensure that practitioners conform to defined methods Inability to monitor process execution Absence of consolidated reporting on process metrics
Discussion
To demonstrate to an auditor that you have appropriate controls in place, you must do more than just show that you have measures of quality. For example, configuration management and change control on both your business processes as well as the measurement process itself is instrumental to moving to the CMMI Level 5 standard. Also, demonstrating due diligence for process optimization is another important component of any compliance solution. As we previously stated, to be in compliance with a regulation generally means that you can achieve both the performance and procedural requirements of a law: Performance requirementsYour ability to deliver functionality or tasks that support a specific regulation, standard, or policy Procedural requirementsYour ability to document adherence to an established operational process It is not enough to only have plans and processes in place. A company must faithfully execute the plans and adhere to the processes, and put in place sufficient resources, time, training, and material to ensure their continual success. In other words, if a process is left unmonitored and unenforced, it is just a matter of time before it decays into anarchy. The three main inputs to a software project are: Product requirements Project plan Software process The measurements and reports for project management are therefore guided by: Identifying and tracking requirements Identifying the achievable objectives Tracking the status and progress of work performed to achieve the objectives
159
The same measurement data, as well as additional measurement of the process itself, provides the ability to control, fine-tune, and improve the software development process common framework for establishing and sustaining the measurement activities, as illustrated in Figure 4-15.
Im prove Process
Process Managem ent
ReqisitePro
Control Process
Control Process
Control Process
Execute Process Softw are Softw are Developm ent Developm ent Execute Plan
Program /Project Managem ent
Rational Unified Process
Requirem ents
Product
Define Plan
Adjust Plan
Measure Plan/Actual
Table 4-15 shows some examples of the types of measurement to perform to monitor and improve the process. The fitness targets the requisites for a successful process execution, such as skills, experience, personnel, facilities, training, tools, and documented procedures. The use targets the execution of the process and the usage of the requisites, such as tools, and documented process.
Table 4-15 Fitness and use Fitness People skills Experience Training Quantity Tools accessibility Adequacy Utility Skills Use People Effort Time Tools How widely How frequently How long
160
Fitness Procedures coverage Sufficiency Quality Documentation Facilities space Computers Technical support Sufficiency Work plan targets Work breakdown Structure Applicability Understandable
Use Procedures awareness How widely How frequently How long Facilities How widely How frequently How long Work plan awareness How widely How frequently How long
Using Rational ProjectConsole and its integration with Rational tools or other third-party tools, a company can automate measurement of process execution against the defined plans. The result of these measurements can then be used to improve the plans and the processes incrementally (Figure 4-16).
Server
Project Console
Metrics Warehouse
Web Server
Server
Collector
Templates Templates
Requisite Pro
Rose
ClearQuest
MS-Project MS-
Client
3rd Partry
161
Activities
Table 4-16 shows the roles and tasks that are performed to achieve the objectives for generating metrics and reports for compliance.
Table 4-16 Roles and tasks to manage and generate metrics and reports Roles Project manager Activities 1. Define and implement the development processes and the associated control points. 2. Implement the types of queries for each policy and process instantiated in the workflow engines.
Conclusion
Table 4-17 shows Rational tools that can help provide the evidence necessary for compliance by providing a foundation to generate metrics and reports.
Table 4-17 Conclusion: Manage and generate metrics and reports Requirements Evidence of appropriate measurement processes Documented measurement plan Documented key measures and data collection strategy Documented strategy for data analysis Evidence of sustained commitment to the plan Rational capability Rational Method Composer Implemented practical software and systems measurement (PSM) plug-in defines a program for appropriate measurement and documents roles, activities, and disciplines for execution. Rational ProjectConsole Defined measures and control mechanisms document strategy for data collection. PJC dashboard demonstrates metrics for consistent reporting of data analysis and summary. Consistency of measures against plan, illustrates sustained commitment to optimizing processes for product quality. Rational SoDA Provide automated traceability, as well as automated artifact reporting.
Summary
In this chapter we described the benefits of Rational tools and their relevance to the regulatory compliance.
162
Appendix A.
163
Method content describes what is to be produced, the necessary skills required, and the step-by-step explanation describing how specific development goals are achieved, independently of the placement of these items within a development life cycle. Processes take these method elements and relate them into semi-ordered sequences that are customized to specific types of projects. For example, a software development project that develops an application from scratch performs development tasks such as Develop Vision or Use Case Design similar to a project that extends an existing software system. However, the two projects will perform the tasks at different points in time with a different emphasis, that is, they will perform the steps of these tasks at different points in time and perhaps apply individual variations and additions.
164
Figure A-1 shows the difference between method content and process by representing them as two different dimensions: Method content describing how development work is being performed is categorized by disciplines. Each discipline comprises tasks (not visible in the figure) that provide step-by-step descriptions of how specific development goals are achieved. For a process, tasks have been referenced by the process from the method content and placed into breakdown structures and workflows ready for instantiation by allocating resources to perform the work and having real work products as the inputs and outputs of the tasks.
Method Content
Process
Figure A-1 Method content and process
UMA's key concepts reflect this separation of method content from process, as shown in Figure A-2. It shows that a method (also referred to as a method framework) contains method content, described with concepts such as work products, roles, tasks, and categories, as well as processes, described with activities, capability patterns, or delivery processes.
165
Method content
Method content is fundamentally described by defining tasks described with steps that have work products such as input and output and that are performed by roles. Roles also define important responsibility relationships to work products. The key method content elements are: Work product Role Task
166
Development process
A development process defines the structured work definitions that have to be performed to develop a system, for example, by performing a project that follows the process. Such structured work definitions delineate the work to be performed along a timeline or life cycle and organize it in so-called breakdown structures or activity diagrams. A process takes reusable core method elements, such as tasks and work products, and relates them into semi-ordered sequences that are then customized to specific types of projects. Fundamental concepts used in UMA to define processes include: Key process elements Activity Capability patterns Delivery process Guidance comes in many types: Checklist Concept Example Guideline Practice Report Reusable asset Roadmap Supporting material Template Term definition Tool mentor
The UMA meta-model has been developed as a unification of different method and process engineering languages, such as the Software Process Engineering Metamodel (SPEM) extension to the UML for software process engineering, and the languages used for RUP V2003, Unified Process, IBM Global Services Method, and IBM Rational Summit Ascendant. As such it provides concepts and capabilities from all of these source models unifying them in a consistent way, but still allowing the expression of each of these source methods with their specific characteristics. This concept provides you with a general overview of UMA capabilities.
167
Content reuse
UMA allows each process to reference common method content from a common method content pool. Because of these references, changes in the method contents will automatically be reflected in all processes using it. However, UMA still allows overwriting certain method-related content within a process as well as defining individual process-specific relationships for each process element (such as adding an additional input work product to a task, renaming a role, or removing steps that should not be performed from a task).
Process families
UMA's goal is to not only support the representation of one specific development process or the maintenance of several unrelated processes, but to provide process engineers with a tool set to consistently and effectively manage whole families of related processes. UMA realizes this by defining the concepts of capability patterns and delivery processes, as well as specific reuse relationships between these types of processes. These concepts allow a process engineer to maintain consistent families of delivery processes that are project type specific and are variations of the same base method content and capability patterns. The result is different variants of specific processes built up by dynamically reusing the same method content and patterns, but applied with different levels of detail and scale; for
168
169
170
COSO
171
PJC PMBOK PMI PPM PVOB QA RFP RMC ROI RPM RUP SCLM SCM SDLC SEC SEI SLA SOX SPEM SPICE
ProjectConsole Project Management Body of Knowledge Project Management Institute Project portfolio management Project VOB Quality assurance Request for proposal Rational Method Composer Return on investment Rational Portfolio Manager Rational Unified Process Software configuration library management Software configuration management Software development life cycle Securities and Exchange Commission Software Engineering Institute Service level agreement Sarbanes-Oxley Software Process Engineering Metamodel Software Process Improvement and Capability DEtermination Tool-directed behavior Tivoli Monitoring for Transaction Performance Tools Platform Project Total quality management Team Unifying Platform Unified change management Unified Method Architecture Unified Modeling Language Uniform Resource Locator
172
Related publications
The publications listed in this section are considered particularly suitable for a more detailed discussion of the topics covered in this IBM Redbook.
IBM Redbooks
For information about ordering these publications, see How to get IBM Redbooks on page 175. Note that some of the documents referenced here may be available in softcopy only. Software Configuration Management: A Clear Case for IBM Rational ClearCase and ClearQuest UCM, SG24-6399 Deploying Applications Using IBM Rational ClearCase and IBM Tivoli Provisioning Manager, REDP-4105 Rational Application Developer V6 Programming Guide, SG24-6449 Using a Single Business Pattern with the Rational Unified Process (RUP), REDP-3877 Patterns: Model-Driven Development Using IBM Rational Software Architect, SG24-7105 Build a Business Process Solution Using Rational and WebSphere Tools, SG24-6636
Online resources
These Web sites and URLs are also relevant as further information sources.
Rational
Rational software
http://www-306.ibm.com/software/rational/ http://www-306.ibm.com/software/rational/offerings/lifecycle.html
Rational products
http://www-306.ibm.com/software/rational/sw-atoz/ http://www-306.ibm.com/software/awdtools/clearcase/ http://www-306.ibm.com/software/awdtools/clearquest/
173
http://www-306.ibm.com/software/awdtools/reqpro/ http://www-306.ibm.com/software/awdtools/portfolio/ http://www-306.ibm.com/software/awdtools/rmc/ http://www-306.ibm.com/software/awdtools/tester/functional/ http://www-306.ibm.com/software/awdtools/tester/manual/ http://www-306.ibm.com/software/awdtools/tester/performance/ http://www-306.ibm.com/software/awdtools/soda/ http://www-306.ibm.com/software/rational/buildmanagement/ http://www-306.ibm.com/software/awdtools/team/ http://www-306.ibm.com/software/awdtools/team/client/ http://www-306.ibm.com/software/awdtools/developer/application/ http://www-306.ibm.com/software/awdtools/studioapplicationmonitor/ http://www-306.ibm.com/software/rational/toolkit/ipo_toolkit.html
Rational on developerWorks
http://www-128.ibm.com/developerworks/rational/library/
Rational services
http://www.ibm.com/software/rational/services/professional/
Tivoli
Tivoli Provisioning Manager and Monitoring for transaction Performance
http://www-306.ibm.com/software/tivoli/products/prov-mgr/ http://www-306.ibm.com/software/tivoli/products/monitor-transaction/
Compliance regulations
Sarbanes-Oxley
http://www.sec.gov/news/studies/principlesbasedstand.htm
Basel II
http://www.bis.org/publ/bcbs118.htm
CFR 11
http://www.access.gpo.gov/cgi-bin/cfrassemble.cgi?title=200521 http://www.access.gpo.gov/nara/cfr/waisidx_05/21cfr11_05.html
HIPAA
http://www.cms.hhs.gov/HIPAAGenInfo
Gramm-Leach-Bliley Act
http://www.ftc.gov/privacy/glbact/glbsub1.htm
174
Six Sigma
http://www.motorola.com/motorolauniversity.jsp http://en.wikipedia.org/wiki/Six_sigma
Related publications
175
176
Index
A
activity record 55 ADApT methodology 7 application deployment 114 approval 43 financial 43 technical 43 artifact traceability 12 audit 1 data 37 trail 44, 81, 121 auditable change 123, 144 auditor 10, 123 authentication 45, 82 biometric 45 authorization 45 automated deployment 121 tests 97 workflow 39, 46 controls 1, 124, 154 environment 25 philosophy 18 process 4 regulated 2 rules and policies 30 transactions 30 transformation 13, 120 Business Driven Development for Compliance solution 59
C
capabilities patterns 123 Capability Maturity Model Integrated see CMMI capability patterns 167 Carnegie Mellon University 19, 101 CCB 12 Center for Medicare and Medicaid Services 8 ceremony 51 CFR 8, 44 chain of traceability 5 chains of authority 69 chains of responsibility 32, 69 change control board 12 management 79 request 55, 147 change process 138 ClearCase 82, 144, 150 ClearQuest 81, 103, 141, 144, 150 CMM 19 CMMI 14, 19, 101, 159 COBIT 1516, 127 Code of Federal Regulations 8, 44 commercial methods 40 Committee of Sponsoring Organizations of the Treadway Commission 16 compliance architecture 13 audit 30 challenges 1, 22 considerations 51
B
backlog 39 Bank Secrecy Act 7 Basel accord 7 Basel II 7 be able to prove it 62 best practices 3940, 114 bidirectional traceability 85 bio sciences 3 biometric authentication 45 build management 83, 85, 87, 114 BuildForge 90, 151 Adaptors 90 FullControl 90 FullThrottle 90 Prism 90 business analyst 122 artifact 10 compliance 30
177
controls 38 cost 38 environment 1 guidelines 29 initiatives 22, 68 management 9, 29, 59 roadmap 119 meaning 3 metrics 138 opportunity 13 portfolio 123, 129 problem and solution spaces 64 process 35 project 123, 141 requirements 76 roadmap 121 sustainable 9 validation 101 compliant software development process 53 configuration management 83, 145 best practices 114 Control Objectives for Information and related Technology 15 see COBIT control principles 65 automation 116 build and deployment management 91 compliance validation 107 documenting results 112 IT governance 73 requirements management 79 software change management 84 software validation 100 control strategies 50, 52 corporate policies 36 policy 4 COSO 16 COTS 26 CQTM 94, 127, 156 critical data file 6 CTQ 19 cultural change 27
automatic 121 control 147 management 85 manager 123 record 55 release 149 development governance 66 process 167 DFSS 19 DMADV 19 DMAIC 19 do what you say 62 documentation 46 documented handoff 12 process 11 test results 12 documenting results 108
E
EASHW 2 Eclipse 82 Eclipse Test & Performance Tools Platform Project 94 electronic signature 43, 45, 81, 121 enhancement request 158 environment specification 114 e-signature 45, 150 European Agency for Safety and Health at Work see EASHW evidence documented process 11 process compliance 12 process maturity 11 extensibility 40, 118
F
FDA 2, 44 financial approvals 43 report 3 reporting 6 Food and Drug Administration 2 Functional Tester 99
D
DB2 147 defect 18 deployment
178
G
GAAP 6 gap analysis 25 Generally Accepted Accounting Principles 6 governance 31 components 33 dashboard 70 development 66 measures 32 policy 32 roles 32 government agency 10 Government's Office of Government Commerce 17 governmental regulations 2 Gramm-Leach-Bliley 9
requirements traceability 121 life sciences 3 Lightweight Directory Access Protocol see LDAP
M
M&A 26 mandatory regulation 2 manual process 38 Manual Tester 100 maturity 20 measurable attributes 48 measures 48 medical device 3 mergers and acquisitions 26 method content 165 methodology ADApT 7 metrics 4748, 145 characteristic 48 flexible 121 primitives 48 selection 48 Microsoft Visual Basic .NET 100 Microsoft Visual Studio .NET 82, 99 money laundering 7 MQSeries 147
H
Health Insurance Portability & Accountability Act 8 HIPAA 8, 14
I
identity management 46 implementer 57, 122 infrastructure 50 inspector 10 integrator 57, 122 International Organization for Standardization see ISO ISO 18 ISO 9000 14 ISO 900x 18, 127 IT governance 13, 66 framework 127 process 125 IT infrastructure 24 IT Infrastructure Library 15 ITIL 15, 17, 67
N
National Commission on Fraudulent Financial Reporting 16 non-certifiable regulation 3 non-directive regulation 2 non-functional requirements 92 non-repudiation 43, 45, 64
O
Object Management Group 71, 103 Occupational Safety & Health Administration see OSHA Office of Thrift Supervision 7 OGC 17 OLAP 72 opportunity 13 organizational metrics 49 policies 36
L
laundering 7 LDAP 46 legislation 24 life cycle 64 business driven development 70 management 82, 131
Index
179
Q
quality assurance 12, 55 audit 19 critical 19 management 18
P
parallel development 83 performance requirements 3, 9 Performance Tester 100 pharmaceutical 3 Plug-in for Compliance Management 107 points of control 46, 54 policy analyst 122 artifacts 4 corporate 4 impact 67 internal 68 management 1 statement 4 portfolio management 68, 131 best practices 114 manager 122 procedural requirements 9 process compliance 12 conformance 50 design 42 engineer 122 exception 10 improvement 17 integrity 31 linkage 64 manual 38 measurement 160 modeling 123, 125 standards 15 program manager 17 project management 82, 137 manager 56, 122 metrics 49 status 110 Project Management Body of Knowledge 133 Project Management Institute 133 ProjectConsole 110 Provisioning Manager 90
R
Rational product offerings 60 tools 59 Rational Application Developer 82, 99 Rational BuildForge 90 Rational ClearCase 82 Rational ClearQuest 77, 81, 99, 138 Rational ClearQuest Test Manager 94 Rational Functional Tester 97, 99, 127 Rational Manual Tester 97, 100 Rational Method Composer 71, 103, 106, 125, 127, 163 Rational Performance Tester 99100, 127 Rational Portfolio Manager 63, 71, 104, 133, 138 Rational ProjectConsole 110, 161 Rational RequisitePro 75, 95, 127, 138, 141 Rational SoDA 111 Rational Software Architect 82 Rational Team Unifying Platform 110111 Rational Unified Process 106 see RUP recertification 46 records management 24 retention 47 Redbooks Web site 175 Contact us xiv regulation 1 business controls 3 examples 5 IT impact 3 mandatory 2 non-certifiable 3 non-directive 2 support 82 regulatory requirements 61 release 88 deployment 124, 149 management 114, 147 manager 5657, 122
180
record 54 reports 6, 46 requirements best practices 114 compliance 76 management 73 non-functional 92 performance 3, 9 procedural 3, 9 taxonomy 77 RequisitePro 75, 154 resource manager 72 utilization 139 retention policy 47 return on investment 19 RFI 34 RFP 34 risk and control consciousness 16 roadmap 121 ROI 19 roles 122 RPM 71 RUP 20, 49, 67, 7374, 84, 106 framework 21 phases 21 Plug-in for Compliance Management 107 plug-ins 106 process framework 106
SoDA 111 software artifacts 37 change management 79 change questions 53 development assets 82 audit trails 44 compliance 30 governance 31, 35 process 29 process documentation 42 process assessment 17 project questions 53 supplier 17 validation 92 software development life cycle 11, 64 Software Development Platform 78 Software Process Engineering Metamodel 167 Software Process Improvement and Capability dEtermination 17 SOX 6, 14, 127 SPICE 17 stakeholder 49 standards 14 status reporting 137 sustainable compliance 9
T
TDB 10, 39, 65, 120121, 127, 142 Team Unifying Platform 110 technical lead 57, 122 metrics 49 technology approvals 44 test manager 123 plan 96 progress 98 tester 57, 123 three points of control strategy 54 roles and responsibilties 56 Title 21 CFR 11 8 Title 21 Part 11 2, 45 Tivoli Configuration Manager 91 Tivoli Monitoring for Transaction Performance 99 Tivoli Provisioning Manager 90, 150 TMTP 99
S
Sarbanes-Oxley see SOX say what you do 62 Say what you do, do what you say, and be able to prove it 60 SCLM Advanced Edition for z/OS 82 SCM integration 82 SDLC 11, 64, 125 security 23, 51 separation of duties 42, 80 service delivery 17 desk 17 level agreement 4, 99 service-oriented architecture 104 Six Sigma 18 SOA 104
Index
181
tollgate 19 tool directed behavior see TDB tool stack 41 tools 59 TPTP 94 TQM 18 traceability 5, 37, 41, 64 artifact 12 bidirectional 85 trust 51 TUP 110
U
UCM 83, 163 UMA 71, 103, 164 capability patterns 170 concepts 166 elements 164 meta-model 167 method plug-ins 169 UML 71 Unified Change Management see UCM Unified Method Architecture see UMA USA Patriot Act 7 usage model 115 user authentication 82
V
validation 102 version control 83 VOC 19
W
Websphere Business Modeler 78 WebSphere Integration Developer 78, 82 WebSphere MQ Workflow 78 WebSphere Process Server 78 WebSphere Studio Application Monitor 99 workflow 46, 50 automation 41 management 82, 121 Workplace for Business Controls and Reporting 63, 67 workspace management 83
182
Back cover
BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE IBM Redbooks are developed by the IBM International Technical Support Organization. Experts from IBM, Customers and Partners from around the world create timely technical information based on realistic scenarios. Specific recommendations are provided to help you implement IT solutions more effectively in your environment.