<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_Exploring_the_Use_of_SAP_Cloud_ALM_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2024-07-01T19:06:23.000Z

Summary: Entities in SAP Cloud ALM for Implementation

<div id="content"><div tabindex="0"><h3></h3></div><div class="formalblock"><p tabindex="0">The following video summarizes the entities that have been presented in this unit.</p></div><div class="kalturaVideoLessonWrapper"><div id="1_yhcwqfgp" data-testid="video" class="kalturaVideoLessonContainer" aria-label="In the video, a detailed flowchart representing the SAP Cloud ALM for Implementation entities is build up starting with the project container. The chart outlines the project’s progression from 'Discover' to 'Run', including 'Prepare', 'Explore', 'Realize', and 'Deploy' phases. It highlights various tasks and sub-tasks involved in each phase and illustrates cross-project entities like roles, systems, landscape components, tags, workstreams, and deployment plans. In addition, it shows arrows from a requirement to both user stories (including sub-tasks) and test cases (including defects) and a feature (pointing to a release)"></div></div></div>

Entities in SAP Cloud ALM for Implementation

Introducing SAP Cloud ALM

<div>Learn about SAP Cloud ALM for implementation, including project containers, cross-project entities, deployment plans, project phases, milestones, and more. Discover how to manage timelines, requirements, user stories, testing, and deployment.<br><br># This description was auto-generated #</div>

Exploring SAP Cloud ALM for Implementation Entities

In SAP Cloud ALM for implementation, the project is a container that holds information together. There are entities that are cross-project (such as roles, systems and workstreams) and there are entities that belong to a specific project. A central cross-project entity is the deployment plan, which is a collection of multiple releases and their assigned system landscape. A release, in turn, is a schedule with a start date and an end date and with a deployment event at the end of the release. Therefore, when running a project, you do not only need to take care about the timeline of your local project, but also the timeline that comes from the release and its assigned deployment plan. The project comes with different phases, which result from SAP Activate methodology but can be adapted by the customer, and milestones that you can define. It allows for an agile implementation approach by defining Sprints during the Realize phase. The tasks that need to be executed can be derived either from the SAP Activate Roadmap or they can be created manually as project tasks, which in turn may contain sub-tasks. In addition, the project contains information on the scope, the team, and the processes to be implemented or enhanced. The relevant processes result from scoping. Scopes are kind of brackets to manage your business processes. Changing the SAP standard processes should be documented during the fit- to-standard workshop. This results in requirements that can be assigned to a business process to allow traceability. You can break down a requirement into user stories with or without sub-tasks. The use of multiple user stories and sub-tasks for a requirement helps you to get a better collaboration and parallel work. For example, think of a user story that may need input from multiple people, such as an UI expert, a user assistance expert, and a database expert. For testing, you can assign test cases to requirements. In case of the observation of test errors, defects can be created that allows to track the fixing of the detected issues. But how does deployment happen? This is where features come into play. Features can also be assigned to requirements. Features in SAP Cloud ALM know about the transport tracks of connected system landscapes, and the deployment to the production system of the transport track will only work in feature status Ready for Production. Finally, a short remark on timelines: The project has a timeline that has been defined by the project lead. But the deployment timeline comes from the deployment plan, that is from constraints that are outside the specific project. Note that the release schedule is kept outside the project so that multiple projects can use the same schedule.