Software Release Management Handbook free essay sample

Full documentation of each change: each change in a SAP system has a link to a Change Request and a Service Desk incident. 3. Changes can be scheduled according to priority, category, and possible impact. 4. Ensure a consistent approval process for each change: all changes have to follow an established workflow. Only changes that are approved and tested come into production. 5. SAP Change Request Management incorporates SAP Best Practices in transport Management and ITIL-compliant processes. 6. Management ABAP and non-ABAP system changes is possible Driving factors for Software Release Management Would you fly to Mars with the software of your organization? † * * Overview A software release decision is a trade-off where, in theory, the objective is to maximize the economic value. Inputs into the release decision are expected cash inflows and outflows if the product is released. When should a product be released? What is the market window? What are the expectations of customers and end-users? A software release decision deals with the difficulty of verifying the correct implementation of functional and non-functional requirements. We will write a custom essay sample on Software Release Management Handbook or any similar topic specifically for you Do Not WasteYour Time HIRE WRITER Only 13.90 / page How much testing is needed? IT departments are challenged to find the optimal level of information, as information has its price in cost and time. The decision-making process to release a product will normally involve different stakeholders, who will not necessarily have the same preferences for the decision outcome. A decision is only considered successful if there is congruence between the expected outcome and the actual outcome, which sets requirements for decision implementation. In SAP applications, there are several problems and risks if no Software change strategy has been established: . Forgotten transports may lead to errors in production 8. Downgrading Object Versions by transport sequence violations 9. Inconsistencies between DEV, QAS, Pre-PRD and PRD, due to different reasons: * Open developments in DEV which have not been yet exported * Transport in QAS or Pre-PRD which have not been imported in PRD * Therefore, all those systems are on different software levels: One big risk is that programs succe ssfully tested, might fail in PRD 10. Several parallel projects with different timelines, Projects and maintenance in parallel 11. Version inconsistencies during bug-fixing: an object in production must be maintained, but it’s version in DEV is already changed 12. Detection of cross-reference errors during bug-fixing: an object in production depends on another project which has been changed in DEV and QAS but not in PRD. To mitigate these risks a Pre-PRD system should be in place, between QAS and PRD, to detect errors and inconsistencies before the changes reach production. Pre-PRD must represent the current software/configuration state of production, thus it should be kept as aligned as possible. The importance of Planning Projects amp; Maintenance During the SAP application lifecycle, changes of different types, risk and impact and criticality, will need to be developed, tested and imported into production. There are different strategies to bundle all the changes: * From a permanent flow of changes (at a given point, all changes move through the landscape and go into production) * To a strict release ma nagement who bundles all changes to larger packages – the releases – that are transported and quality assured as one entity. The latter is the recommended approach: to strictly bundle the changes into difference release categories to enable an effective Quality Management process and reduces the frequency of importing changes into production. However, bundling all changes into releases slows down the realization time of changes. This leads to the SAP supported concept of Parallel Projects. Projects are managed and documented by SAP Solution Manager, and there defined by their Release Cycles: any change which is related to a project, moves synchronously from development, trough test and production. Working with Parallel Projects: Risk of Objects conflicts and dependencies There are two types of problems when working with parallel projects: Object Conflicts : 13. This means that the same objects are contained in different projects. 14. The project which is imported as last, overwrites the objects of the other project. Therefore, the project which was imported first might not work anymore after the import of the second project. Object Dependencies : 15. Objects in different projects use each other, for example a program in project 1 calls an object included in project 2. 16. If only one of the projects is imported into another system, it will fail. This is a problem called cross-reference inconsistency. Again, to allow IATA managing SAP Parallel Projects, we’ve set a Pre-PRD environment, which has the current software/configuration release of PRD plus the next coming project: dependencies and crossed reference errors can be isolated and fixed before they go into production. * * Parallel Projects Best Practises * An estimation of potential collisions (object changed in different projects) should be performed before a project starts by the development team responsible * If no collision are expected, projects can be done in parallel * If collisions are expected, projects should be done in sequence of having a common Go-Live * If possible, several small projects should be bundled into one big project with a common Go-Live date. S wap out long running projects into separate environments, if possible. * Advantages of Managing Software Releases * Frequency of changes to production is dramatically reduced * End users won’t be confused by frequently changed functionality * The rollout of a new functionality can be done in a controlled way, including announcement, end user training, testing and documentation * For each change the right testing approach is taken Enough time for testing invasive changes in Major Releases * Common regression and integration testing for several projects in one run (resulting in lower cost and reduced risk) * Appropriate tests and infrastructure for testing minor releases * Reduction of daily changes to the absolute emergencies * Risk of inconsistencies reduced (forgotten transports or sequence violations) * Reduced administration efforts for transport management as all projects move at a single point in time * Using change categories consequently still allows flexibility for ur gent changes * Higher stability in Production * Release Management Calendar After the first major Go-Live each organization faces the need for a Release Management Methodology that appropriately prioritizes projects and initiatives handle: the backlog of additional functionality requests fot the SAP system, additional SAP rollouts on deck (to other business units or territories), and other projects that need to be implemented, requiring use of the same resources that would be used for your SAP improvements and rollouts. An integrated Release Management methodology provide the following: 17. Ensures internal and external business drivers are considered in planning implementation timelines 18. Establishes a single point of accountability as release plans change through the lifecycle of projects in planning implementation timelines 19. Establishes a single point of accountability as release plans change through the lifecycle of projects 20. Provides a coordinated schedule for integration testing cycles, as well as an overall QA test, to minimize the risk of inconsistencies during Go-Lives in PRD 21. Provides a common infrastructure for control in the lifecycle (standards, checkpoints, go/no-go criteria, etc. ) 22. Provides consistent communications toward end users and project sponsors Especially for Major releases it is required to set up and publish a fixed maintenance calendar for a complete year (ideally 18 months), which includes the SAP maintenance activities: * A well defined maintenance calendar is an important condition for the approval process and the planning of changes. This calendar needs to include also the related test activities, the application maintenance phases and code freeze periods. * Projects phases will be compliant with the application maintenance phases to minize all the exposed risks of version downgrade, transport sequence violation, code inconsistencies. SAP Solution Manager for Operations SAP Solution Manager is a set of tool to successfully implement and efficiently manage an SAP solution from its inception and implementation to daily operations an d support. Change Request Management workflows (ChaRM) represents a core functionality within the End2End Change Management Process in SolMan and consists of a number of individual elements which offer support to Project Management, Scheduling of changes, Deployment of change and consistent approval workflows. Projects in SAP Solution Manager * * Overview SAP offers its concept of PROJECTS to group comprehensive customizing and development activities. Project Administration allows you to structure and classify change activities and the associated technical changes. These technical changes result in transport requests, which are distributed within the system landscape using the SAP Transport Management System. Various project types are delivered as standard with SAP SolMan, the project types which can take advantage of the Change Request Management workflows are: 23. Implementation project 24. Upgrade project 25. Maintenance project 26. Template project A first distinction between these projects is made whether they are executed cyclically or once only. Clearly a Maintenance project can be defined as recurring, because it’s always starting over once has been successfully completed. A Maintenance project is used to maintain processes or functions that are already in production, this means the project cycles will be slightly different from the ones of the other project types. Defining a Project in SAP SolMan is a prerequisite for ChaRM workflows; however additional Project functions are used in the managed systems and linked to the SolMan project to facilitate the monitoring of changes in these systems. The Project functions used in the monitored systems are the IMG (Implementation Guide) Projects and the CTS (Change and Transport System) Projects. If you activate ChaRM workflows for your Project in SAP Solution Manager, a link to an IMG project and a CTS project will be established in automatic in the managed SAP systems, to coordinate the technical changes in the SAP landscape, between DEV, QAS, Pre-PRD and PRD. Projects phases and lifecycle In SAP SolMan, all Projects have a certain lifecycle, referred to as the Project Cycle. A Project Cycle is, in turn, divided into a number of Phases. These phases reflect the individual steps involved in a project, such as the development and test phase. Project Phases are visible in the blueprint and configuration transaction. Project Phases determine whether or not a transport request can be created, released or imported. ChaRM maps project phases and the functions required during each of these. The possible phase value for a cycle, which are identical in all projects, are as follows: 27. Created 28. Development without Release 29. Development with Release 30. Test 31. Emergency Correction (also referred as Go-Live Preparation) 32. Go-Live 33. To be Closed 34. Closed Let’s have a closer look to those phases in blue, for two different Project types, which are relevant for daily system operations: various activities are executed within these phases. Besides the Project Phases are identical for all Project type, when SAP Change Request Management is activated for a Project, SolMan generates a specific task list the Project type. Let’s have a look at the task lists for the two broader Project types: Maintenance Project and Implementation/Upgrade Projects. Technically a Project Cycle is represented in SolMan by a task list (generated into the Schedule Manager) and a change transaction (a CRM document). The task list contains the list of activities of the Project and the change transaction allows you to move from one project phase to another and provides information about the transport requests belonging to the project. Implementation/Upgrade Projects For Implementation and Upgrade projects, the Project Cycle looks like the picture below. The allowed activities (transactions) in Change Request Management, for these project types, are: 35. Development / Development Activity in Upgrade and Templates 36. Administration Maintenance Projects Maintenance projects have also their own project lifecycle, however in this case we refer to as a Maintenance Cycle. For example, a permanent maintenance project for a live solution may be divided into maintenance cycles of three months each, which divide the release calendar in quarterly releases. All necessary support and maintenance tasks are executed within these maintenance cycles. These include, most importantly, development and testing of corrections. These activities are divided into phases within each three-month maintenance cycle. For example, each cycle includes a development phase and a test phase. At the end of the three months, the maintenance cycle has reached the final phase and all of the changes from the cycle are imported into the production system, and a new maintenance cycle can then be generated to manage all the changes that arise over the next three months. Maintenance projects differ from other project types in one important respect. Within a maintenance cycle it may be necessary to import an important change or correction into the production system as quickly as possible. In this case, the three-month cycle is too long. A special change transaction is therefore provided for this very typical scenario: an Urgent Correction. This change is only available in the Maintenance Projects and enables an immediate transport of changes into the production system, independent of the phases in the maintenance cycle. For a Maintenance Project, the Project Cycle (Maintenance Cycle) looks like the picture below. The allowed activities (transactions) in Change Request Management, for these project types, are: 37. Normal Correction 38. Urgent Correction 39. Administration 0. Test Message As illustrated above, Normal Corrections for a Maintenance Cycle are only possible during the Development Phases, during the subsequent phases, Normal Corrections can only be transported into the quality assurance system and, from there, the production system. Urgent Corrections, on the other hand, can be created up until shortly before the Go-Live to ensure their integration into the same maintenance cycle. You can create Normal Corrections after the development phase; however these will then be part of the next maintenance cycle. Transactions in Change Request Management In ChaRM various workflows are provided to fulfil diverse change requests process requirements. These workflows, from a technical point of view, represent various transactions types and documents created in the CRM service process transaction (CRMD_ORDER). The Service Desk message is not part of Change Request Management, but it often initiates actions in ChaRM. In a Service Desk incident message you have the option of creating a linked Change Request. These Change Request may give raise to various follow-up transactions, which are mapped by default by urgent corrections, normal corrections and the administration message. Test messages represent a special case because they are issued without a change request. Information about the people and the system involved is stored in each transaction, as master data, which must be maintained in SAP Solution Manager. Business Partners need to be maintained for the people involved, whereas information must be maintained in the installed base (IBase) for the supported systems. Change Request The creation of a Change Request represents the first sub-process of the SAP Change Request Management; its main role is to document the request and all the associated information, about change status, requestor, approver, ester, as well as the technical change (transport orders) in the SAP system. Some of these information are essential to ensure that no error occurs during further processing of the Change Request Management. A Change type must be entered, there you specify the transaction that is to be used to implement the change: you can choose between a Development or Adm inistration message, and in case of a maintenance project, you can even choose a Normal or Urgent Correction. The purpose of the Change Request is to have your change approved or rejected. A Status Profile maps the change request process, we’ll go later into details. A Change Request can be created from transaction CRMD_ORDER, within a Service Desk Incident Message or using the transaction CHARM_CREATE. Once a description of the change has been entered, as well as information about the Sold-To-Party, Requester and Change Manager, an action to approve or reject the request will be requested to the Change Manager. If the Change is rejected, the user status Rejected is set automatically and the document is closed. No further changes can be made to the document at this point. If the Change is approved, the user status Approved is set and a follow-up transaction is generated, called Change Document, which is different whether it’s been selected the change to be a Normal Correction, an Urgent, a Development, etc. The following table represents the different Change Request Management transactions available. If several projects or maintenance cycles exist for a system, the system prompts you to select to which project or maintenance cycle the change request belong. SAP SolMan Transaction| SAP CRM transaction| Scenario| Remarks| Sevice Desk Incident Message| SLFN| Incident Management|   | IATA Custom Support Message| ZSLF| Incident Management| IATA Custom version for SFLN| Change Request| SDCR| ChaRM|   | Urgent Correction| SDHF| ChaRM| Only available in Maintenance Cycles| Normal Correction / Development| SDMJ| ChaRM| New version, with Transport of copies| OLD Normal Correction / Development| SDMI| ChaRM|   | Administration message| SDAD| ChaRM|   | Test message| SDTM| ChaRM|   | Maintenance Cycles| SDMN| Project Management|   | Project Cycles| SDDV| Project Management|   | Change Document The Change Document, as shown in an earlier picture, is an umbrella term for the transaction types that represent Urgent, Normal Corrections, Development, Administration messages, etc. Change Documents implement an approved Change Request and follow-up with their specific workflow the type of change that has been requested into the SAP system. Normal Correction / Development A Normal Correction, which is also referred to as a Development activity in implementation/template/upgrade projects, represents the typical process used for new or change implementations. Most changes should be executed with this transaction type. This Change Document is represented by two transaction types in SolMan: SDMJ and SDMI. The SDMJ is an improved recent version, whose main difference with the SDMI is that this latter requests the developer to create new transport orders if, for any reasons, the first development has to be repaired in quality assurance. The SDMJ bypass this problem because only transport of copies is executed between the development and quality assurance systems. The original transport request remains in the development system until the correction has been tested successfully, and it’s released after successful testing and can be imported into the quality assurance systems again, to proceed its test phase for the project. Various users will be actively involved in a normal correction as part of the Change Request Management process, these are well represented by the picture below. During the course of a normal correction, these users (as example, the developer) can set the correction to In Development and then generate transport requests in the DEV system, to which the change will be added later. After the development activity has been completed, the normal correction can be transferred to testing. The change is automatically released in the DEV system and imported into QAS system and then evaluate if testing as successful or unsuccessful. If testing is unsuccessful, the status of the change document is reset to In Development, whereas the successful testing changes to status Consolidated. This status indicates that testing has been successful and enables the import of the change into PRD or Pre-PRD, according to the specific SAP landscape strategy. When all changes have been successfully imported into PRD system, the individual change documents can be completed by setting the user status from Consolidated to Production. The various user statuses that represent the individual steps involved in a normal correction are as follows: 41. Created 42. In Development 43. To be Tested 44. Consolidated 45. Production 46. Withdrawn These status values map the various steps in a normal correction, provide a general overview for users and facilitate navigation. The following table shows the activities that are possible in a normal correction during the various phases of an Implementation, Template or Upgrade project. Normal Correction in an Implementation, Template or Upgrade Project|   |   |   | Phase| Request| Approval| In Development| Release| Finish dev. | Pass to Test | Production Import| Created| Y| N| N| N| N| N| N| Dev. w. out Release| Y| Y| Y| N| N| N| N| Dev. with Release| Y| Y| Y| Y| Y| Y| N| Test| N| N| N| N| N| N| N| Emergency Correction| N| N| N| N| N| N| N| Go Live| N| N| N| N| N| N| Y| Being Completed| N| N| N| N| N| N| N| Completed| N| N| N| N| N| N| N| Noticeably, a normal correction can only be created and transported during the development phases of a project. Once the project has entered the Test Phase, any necessary improvements or corrections can be executed using a Test message. All corrections must be released or withdrawn in the development system when the project passes into the Test phase. Any necessary corrective action can still be implemented during Test and Emergency Correction phases. However, transport requests can only be created centrally in the project task list at this point. Notice also how import of transports into production system is only possible during the Go Live phase. The following table shows the activities that are possible in a normal correction during the various phases of a Maintenance cycle. Normal Correction in Maintenance Project|   |   |   |   |   | Phase| Request| Approval| In Development| Release| Finish dev. | Pass to Test | Production Import| Created| Y| N| N| N| N| N| N| Dev. w. out Release| Y| Y| Y| N| N| N| N| Dev. with Release| Y| Y| Y| Y| Y| Y| N| Test| Y| Y| Y| N| N| N| N| Emergency Correction| Y| Y| Y| N| N| N| N| Go Live| Y| Y| Y| N| N| N| Y| Being Completed| N| N| N| N| N| N| N| Completed| N| N| N| N| N| N| N| In the case of a Maintenance project, a normal correction can be created and edited at any stage. However, once the maintenance cycle reaches the Test phase, any normal correction created in Test phase or the subsequent phases, will not be part of the current maintenance cycle, i. e. will be imported in production during next cycle. In Test phase, normal corrections cannot release other transport; this prevents the transport of changes into QAS during the integration test. Corrective actions can be created by the Release Manager on the central task list of the maintenance cycle, either during Test and Emergency Correction phases, but this can be considered for exceptional cases. Urgent Correction Urgent Correction, which is only available in maintenance projects, is a transaction used when a change must be transported immediately into the target system. It allows you of transporting a change into production system regardless the maintenance cycle phase. Urgent corrections are partly automated transactions, where users do not have to enter many actions as in the Normal corrections. This flexibility is due to the individual task list of an urgent correction; Project cycle and task list are normally assigned to a project or a maintenance. This is why you can release transports and move into systems freely, cause you’re not assigned to a project or maintenance cycle. Urgent corrections may have the following statuses: 47. Created 48. In Development 49. To be Tested 50. Successfully Tested 51. Production 52. Withdrawn Urgent corrections workflow is well represented by the picture below: Administration Message The Administration message is used to document activities that do not result in a transport request; for example, changing an instance profile parameter or maintaining master data. An administration message is only of relevance to a selected system (say QAS) rather than to the entire system group (DEV, QAS, Pre-PRD and PRD) as in the case of a normal or urgent correction. The purpose of an administration message is to document specific changes so that it is possible to track, at any point, which users have made which changes to the system, An administration message may have the following status values: 53. Created 54. In Process 55. Completed 56. Confirmed 57. Withdrawn In principle, an administration message offers the same functionality as a normal or urgent correction; the only functions not available in this messages are those relating to the Transport Management System. Test Message The Test message represents something of an exception; this transaction is created without reference to a Change Request. Test messages are used for troubleshooting purposes during the integration test and can therefore only be created during the Test phase of a Project or a Maintenance Cycle. As the Test message refers to the correction of a change that has already been approved, there’s no need for a change request in this case. The users involved in this message are a developer and a tester. Test messages can be created by testers by transaction TEST_CREATE in Test phase, the developer can then create a corresponding correction in the DEV system and then transfer it to QAS for retesting. A test message may have the following user statuses: 58. Created 59. In Process 60. To be Retested 61. Confirmed 62. Withdrawn When the correction has been imported into the QAS system, the tester can conduct a new test to include the correction. If the test is successful, the test message is completed. Change Process in IATA * 5. 1 SAP System Change Request approval process 5. 2Decision Criteria for Change categories in Application Management A SCR (System Change Request) can be categorized as Urgent Correction if it regards: 63. Critical Business Processes do not work 64. Resolution of priority 1 application incident tickets 65. Bug-fixes (corrections to existing functionalities) 66. Small enhancements requests with limited effort (less than 5 days) A SCR can be categorized as Normal Correction if it regards: 67. Completely new functionality 68. Enhancement requests with a major effort (more than 5 days) 69. System outage required * 5. 3 Change Meeting and schedule Below a representation of IATA’s Change Process, the two milestones to approve a system change are: 70. Change Control Board : the SCR are presented using a specific form to facilitate the discussion and approval by the Business Process Owners gt;gt; CCB Meeting is scheduled each Thursday 71.