Skip to end of metadata
Go to start of metadata

Purpose

With the content in this document you will be able to start to practice with the expected workflows for Focused Build for SAP Solution Manager Requirement-to-Deploy (R2D) scenario in the test landscape created in wiki page First steps to work with Focused build for SAP Solution Manager - Set-up.

I will try to give tips and tricks for the common issues/errors in the workflows by creating a Requirement document and moving the successor documents Work Package WP and Work Item WI until the completed status.

Note: This is just a starting document to start working with Focused Build for SAP Solution Manager written from a Change Control Management perspective.

For a complete view about how the different R2D functional areas like: Portfolio&Project Management, Process Management, Requirements Management, Change Control Management, Release Management, Test Management integrates together please don´t miss document Role-specific training curriculum document, last version here.


Important remark

To avoid methodically misuse of the functionality, it’s still highly recommended to:

  1. Start with Focused Build before you start with the conversion or implementation project, because it’s the project infrastructure where the project is based on. This is not only a tool set-up, but it comes along with methodology changes.
  2. After configuring the SAP Solution Manager/Focused Build development system, execute an initial project planning workshop with an experienced Focused build expert. E.g. the set-up of projects, release and test strategy should be discussed in context of your specific situation and needs, here.
  3. In addition, it makes very much sense to plan at least reviews for the topics:
    1. Solution Documentation/Document Management set-up before the Explore phase starts
    2. How to scope/tailor Requirement, Work Package and Work Items before the Realize phase starts
  4. Often underestimated is, to efficiently train the project team members before the project starts (general Focused Build overview) and during the project execution (brief role specific trainings according to the current project phase)


The system screenshots provided in this wiki are taken from an internal SAP Solution Manager 7.2 ST-OST 04 system.

The documentation screenshots are taken from:


Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Important information before starting

In the wiki First steps to work with Focused build for SAP Solution Manager - Set-up we created a Solution, a Release cycle and the required Projects, see below how these areas link together and with the Focused Build documents.

All these pictures below are taken from the document “Role-specific training curriculum” and I will suggest keep them in mind when working with the different Focused Build documents.


Our test case in that wiki followed this use case: One Release per project, with two Waves, and three Sprints per Wave:

See the different milestones per sprint and per wave:




 

Create a Requirement from a Solution Documentation Business Process/Process Step

During the Fit-Gap workshops the requirements are usually created.

The best practice is to add requirements to process or process steps reference, but requirements could be linked also to library elements if required.

As you can read in SAP Reference IMG SPRO point “Automatic release of technical objects between branches” then the elements: Executables, Developments, Configuration units, assigned to this process or process step will be considered to be released between the design and the development branch when running action Handover to Release in the Work Package created from this requirements.

Open your solution – Design branch in /nSOLDOC and select a process step for example.

Remember that we moved the processes relevant for our project implementation from the Best practices imported into the Import branch to the Design branch.

Now we need to create the requirements per each business process, process step reference. Select for example a process step from the processes structure, then go to Related Documents section on the right side.

When clicking in the Requirement: X link you will see that Requirement Managements tile opens with this Solution, branch and process step selected by default:

Create a new requirement by clicking in Requirement button, Create new Requirement:

Note: You could create Requirements directly from Requirements Management tile and link the element manually in the Element field by selecting it from the Processes structure.

Enter the required information like the owner who will be responsible of the requirement.

You need to describe in an attachment the requirement description, what you need to have for this particular process step in this particular process context.

Attachments

The attachments tab in the requirement/work packages is a possibility to describe detailed and based on a predefined template what is requested. This document is exclusively stored in the CRM transactions. Once created in a requirement, the attachment will be passed to all work packages which are successors of the requirement.

You can create an attachment based on a template, edit it offline and update it by dropping (document type attribute will be maintained) or just by dropping a local file over the drop area.

See SAP Reference IMG SPRO point Define allowed document types as attachment.


You can also change the element or add additional elements from the Processes structure.

The business processes, process steps assigned to the Requirement will be inherited by the Work Package created or linked with this requirement.

Requirement Classification

It is really important to indicate the Requirement Classification:

  • Gap: Is used for a new development. Technical design is done by developer in the Work Item- Technical design document
  • WRICEF: Is an SAP extension for a workflow, report, interface…, the specification is often already a mixture between functional and technical design in the work item
  • Fit: Is used for customizing. So, specification is often an existing standard configuration guide and only a customizing documentation is needed to be maintained on Work Item level
  • Non-functional: Is used for documentation upload or a parameter setting without the need to document a Functional Specification (no document KPI maintained in customizing for Work Package and Work Item). 

In the SAP Reference IMG SPRO point Document KPI Framework you need to answer these questions:

  • Which documents are required in the work package and in the work item?
  • What is the right document processing status for each particular work package or work item document status?

You can see that the KPI-logic is like this:

If you have a work package it depends on the classification this is what you need to provide from documentation-perspective:

  • Gap: Functional Specification type Gap, Single Functional Test Case
  • WRICEF: Functional Specification type WRICEF, Single Functional Test Case
  • Fit: Configuration Guide, Single Functional Test Case
  • Non-Functional: no documentation required

The Functional Specification type Gap and WRICEF, and the Single Functional Test Case document needs to be in status Released when the Work package moves to Scope Finalized and beyond this status. KPIs: FSPEC and FSPEC.

For the work item (NC) the developer will create a Technical Specification document for Gap and WRICEF classifications, or a Configuration Guide for a Fit classification. The Technical Specification/ Configuration Guide document need to be in status Released when the work item moves to status Successfully tested. KPI: TSPEC.

But if for example you have a work item with Non-Functional classification, but you created a technical design document, although it is not needed, also this document needs to be in status Released when the work item moves to status Successfully tested.

I selected in my example GAP Classification and Save.

I move back to the Requirements Management tile and open the created requirement and execute the first action: Send for Approval and then Approve.

Note: you could approve the requirements also in the Mass Change Operations tile.

Working with the Work Package

When the requirement is in status Approved you can create a Work Package from it or assign the requirement to an existing work package.

The Work Package and Requirements relation is defined in SAP Reference IMG SPRO point Define Requirement and Work Package, attribute REQ_WP, options 1:1, 1:n or n:m.

If you select the option to create a new work package you will get this screen:

Enter the Title, Owner and select the project and wave that you created.

Select the classification for the Work Package. Remember that depending on the classification selected you will need to create different documents.

Only if you select Non-Functional no document needs to be created.

It is possible to create a Work Package directly and without Requirement assignment. Later you could add the process structure.

Work Package is created, click in the document number:

The Focused Build – Architect owner of the work package can find the work package under My Work Packages tile.

When the Work Package opens you can see in the Details section the release cycle linked to the document in Actual Release field.

If you click on the Title of the document, you will get the document opened in CRM Web UI.

Run Action-> Define Scope

WP moves to status Scoping and FIRST you need to go the Documentation tab as you need to add/create the two required documents per the process step: Functional Specification and Single Functional Test case (Categories: Single Functional test case or/and Integration test case or/and Regression test case, …), click on the Create icon below if the documents still are not created.

Documentation


Enter any Filename value, then Document Type will be available. Select the Document type for the element you want and click on Create.

Create also the Single Functional Test document:


Note: the document types offered in the Work Package will depend on what is behind the structure selected, will depend on the elements assigned to the process step.

For example, if under the process step you have an element of type Configuration unit you would get the option to select Document type Configuration guide.

Or if you created an element of type Transaction you will get the Document type Technical Design, although the Technical Design is expected to be created in the work item created from this work package.


In the Document Type Administration for document Technical Design you will see in the Usage that this document is not available at process level, only at process steps level and only for element types like BSP, Classes, Transactions.


In the case that you have already created documents for a process steps in SOLDOC you can assign this document to the work package by clicking in the Assign icon next to the document.

You could also create the documents locally and select several documents and drop them over the Documents area. A popup will appear for you to select the document type, element type to which the document will be assigned and the element for each of the dropped documents.

The decision where the dropped document will be stored is done in the background by dropDocs and based on the standard document type configuration e.g.:

            - Functional specification will be stored at <Step origin>

            - Single Functional Test at <Step origin>

            - Technical Design at development or executable elements

            - Use Case at <Step reference>

Scope

In the Scope tab click on Add + icon:

Select the type:

  • Work Item (NC): development with TR transport
  • Work Item (GC): development with no TR transport

You need to add the processes/process steps of this work package and the associated scoped documents, all of them, in one single work item or in several work items according to your business needs.

Then when creating the work items or work items all elements will be inherited to the Work item that is in the development branch.

You can select the Sprint for the work item and the productive system of the cycle in case that more than one production system exists.

You can enter the developer responsible, then the developer will be able to find the work item in tile My work items.

Still the work item is not created.

Now you need to set to Released status both documents, select the document and click on this icon:

Then the Solution Architect is ready to select Action-> Approve Scope

When the scoping is finalized run the action Handover to Development, the work item will be created.

When the handover is done to Dev Team, the status of the Work Package will be changed to To be Developed. Doing this, the Work Items will be created.

Then all content related to the Work Package, is automatically released to the Development Branch.

Work item document is created, by clicking in the Description name link you can open the document:

Also, you can see in the Relations tab the document number of this created work item:


The process step and the associated documents are now in the Development branch.

Working with the Work Item

The developer should go to My Work Items tile and open the Work Item.

In the Mass Change Operations tile you could always find the Work Items, by selecting Work item.

Then move the work item to In development as first step by selecting action Start Development. For this the sprint needs to be assigned in the Details tab, only the released sprints in the Project Management can be assigned.

Transport

Developer can start with the development activities.

Documentation

First development task should be to create the Technical Design document.

This document type is offered in the Work item if there is a Executable element like a transaction created for this process step, but in our example the selected process step “Provide additional information” was not containing any element, so in this example we will not get the Technical Design document offered.

As we did before we click on the icon Create new document in the Documentation tab, Documents section for this structure process step:

But if under this Process step Provide additional information there was in the element side an executable like a Transaction then the option to select Technical Design document will be shown for selection and a Technical Design needs to be created and released.

Now developer moves to the Transport tab to create a TR that contains the required changes for your work item of type GAP. Click on the + icon.

Ensure that you see the correct transport track under Transport Landscape Information area.

Transport requests will be created in the development system, source system, CRY:100.

Click in the icon next to the development system to logon to the system.

How make a dummy change in the source system:client, like an entry in sm30: T005A.

Save it to the created TR.

Release only the task of this TR in se03 for example.

and then move the Work item to status To be tested, action Pass to Test.

According to the entries for the Work item transaction type S1MJ, remember that in Focused Build you need to work with the delivered transaction types, a TOC will be created,  released and then imported into the target system CRY:200 in our test scenario.

See this in sm34:aic_settings2:


A tester should logon to the quality system and check the changes by making the Unit test of this work item and then if the tests are passed tester can select action Confirm Successful test, this will release the original transport request and move the work item to status Successfully tested.


At this point the transport request is released and added to the import buffer of the quality system CRY:200 and in the document you get only the option to request the use of the preliminary import scenario to move this transport request quickly to production system via PPF actions in the document.

This predecessor work package could have several work items, so in Focused Build, when the last work item reaches the status Successfully tested the WP will move to status To be tested, SOCM action SET_PREDOC.

The test coordinator needs to run the Single Function test SFT created at work package level, and if the SFT are ok then the test coordinator for this work package will set the status of the Work package from To be Tested to Successfully tested, in the work package.

If during the SFT issues are detected a Defect correction document can be created from the Work Package, that is in status To be tested. Work package will move to status In Repair.


Note: Usage of Test Suite in Focused Build

During this wiki we were speaking about different test types, test documents.

However, I don´t have enough knowledge to give you the steps to set up the Test Suite scenario and integrated it in the workflow explained here.

What I can say is that you need to go through the configuration guide for the Test Suite Configuration Activities.

After this you would be able to create from the Solution element test cases types like: Manual test cases in form of Test documents and Test documents URLs, Automatic test cases in form of Test Configuration and Test Steps test cases, only available in Focused Build.

You could assign then this Test Step test case to the work package, when scoping the work package.

When the successor Work item reaches the status Successfully tested after making the unit tests, the work package reaches the status To be tested.

Now for the Work packages that contains a test case, in the tile “Test Plan Management- Assignment Analysis and Test Plan Generation” the test manager can create a test plan that includes the selected work packages and from here the test packages will be created always one test package per work package since ST-OST 05 for Single functional test and Acceptance tests.

If you selected Work packages in status Handed over to release that are ready for the Functional Integration Test the test package creation is not mandatory one test package per work package you will see other options like One Test Package containing all Test Cases.

During the testing of the test cases the tester can find issues and create a Defect document and then a Defect correction document to fix the issues.

If there is no Test Suite integration the test coordinator can manually create a Defect correction from the work package Scope tab, when the work package is in status To be tested, where the developer and the tester will need to work to fix the detected issue.

This Defect correction can contain also new transport requests.

See the status workflow for ST-OST 07 where a new status In Delivery is introduced.

In the example I will select the option Confirm Successfully Test action in the work package:

Work package moves to status Successfully tested and also the successor Work Items.

What we have at this point is the TR released but not imported into the quality system:

Now we need to trigger the import of this transport request into the quality system CRY:200 by using the release batch import report, se38: /SALM/BATCH_IMPORT_TRIGGER

But first you need to configure this report in SAP Reference IMG SPRO point Configure Release Deployment and Batch Import.

Let me show you quick which are the settings to configure the release batch import for triggering the imports into the quality system.

Variant provided for this import /SALM/QAS

Using Import Config IMPORT_QAS

See how this import config is taking into account the normal change documents, S1MJ documents, in status Successfully tested:

This import config is also taking into account for imported in transport requests for Defect Correction S1TM in status Transport to Retesting E0004 and To be Retested w/o Transport  E0011.

So, the transport request of our work item that is in status Successfully tested will be considered to be imported.

Create specifically an entry for this variant, by selecting its Import Config, and your solution and change control landscape used in the release cycle where this work item was created.

Enter also the system where the import will be done.

Maintain the client number and the type of RFC to be used to trigger the import into the quality system

Then run the report /SALM/BATCH_IMPORT_TRIGGER indicating the release cycle and the variant

If I remove the Test Mode flag the import of the TR of our work item will be done in CRY:200, report exit:

Check this in the transport request logs:

Or in the work item document Transport tab:

Now it is time to move the work package manually to status Handed Over to Release.

This can be done when the release cycle is in phase Prepare, but theoretically we should move the release cycle to phase Build.

In Build phase no more new Work Package, Work items can be created for this release!!

If you try to move the Work Package to status Handed Over to Release when the cycle is in phase Deploy you will get error message: "Activate the release" /SALM/IT_REQUIREMENT 011 as the only possible phases for the major release are Prepare or Build phase.

Please check SAP Note 3038903 - "Focused Build - Unwanted inconsistent assignment at Work Package prevents status change" when you get an error trying to move the Work Package from 'Successfully tested' to 'Handed over to release', this will help in case of inconsistencies with the Solution Documentation elements assigned in the Work Item and the Work Package.


When you move the work package to status Handed Over to Release, automatically the successor work items and possible defect corrections will move also to status Handed Over to Release. Predecessor requirement will change to Realized automatically.

Note: Only the transport requests of the work items and defect corrections in status Handed Over to Release will be imported into the preproduction system, CRY:300 in our case, when the release batch import report run for the variant /SALM/RELEASE_PRE.

Run report /SALM/BATCH_IMPORT_TRIGGER for /SALM/RELEASE_PRE after making the correct settings for this variant, Import Config IMPORT_INTEGRATION_TEST.

The release cycle should be moved to Test phase, and the Test coordinator would run the Functional Integration Test FIT (Final) or the Regression Test in the Preproduction system CRY:300 before moving the changes to the production system. Test coordinator can make the testing manually with no evidences or by creating a Test Plan for this.

When the release cycle is in status Test, no new Work Packages can be added to the wave for this Release. Project Team can only use Defect Correction.

Finally, we need to get our changes imported into Production system, for this you need to move the cycle to phase Deployment Preparation, in this phase all Defect Corrections with Priority 1 and 2 must be set to ‘Handed Over to Release’ and have to go live with the actual Release

Then move the release cycle to phase Deploy.


The release batch import report will check the release cycle S1MR status when using variant /SALM/RELEASE, Import Config IMPORT_PRODUCTION:

Work items in status Handed Over to Release like our work item will be taken into consideration and this time according to the settings below it will move to next status that is Productive and then to Completed according to the settings in sm30: AIC_CRM_CM_ST_CH for S1MJ

Create the entry for the variant and your solution, change control landscape used by the cycle and the systems entries where to trigger the import:

Move the release cycle until the Deploy phase with the release manager business role, if no the release batch import will fail.

My cycle was at this moment still is in Prepare phase although for being consistent with the methodology it should have been moved to Test phase already as indicated before.

Run the release batch import with these values:

Report exit

When the Import has been successful and according to the settings in the variant used the work item document status will change, this status change can trigger also the PPF action maintained in SM30: AIC_CRM_CM_ST_CH for the document status shift.

Since ST-OST 07 it is requested to activate the Import Feedback functionality as indicated in the configuration guide, see also KBA 2746697 - Active Import Feedback - Additional information. The Release Batch Import program is informed about the actual Import Status via the Active Import Feedback functionality.



So, work item moved to status Completed and the predecessor Work Package too.

Process step arrived to Production branch.

Predecessor Requirement moved also to Completed.

Now you can switch the release cycle to phase Hypercare.

You will get a popup with all open work packages/work items/open defect corrections with Priority 3 and 4 will be assigned to the next Release automatically.

It is time to use the Fix pace scenario by creating Request for Change for Urgent Fixes.



Related Content

Related Documentation 

Related Notes

  • 3038903 - Focused Build - Unwanted inconsistent assignment at Work Package prevents status change







Purpose

With the content in this document you will be able to start to practice with the expected workflows for Focused Build for SAP Solution Manager Requirement-to-Deploy (R2D) scenario in the test landscape created in wiki page First steps to work with Focused build for SAP Solution Manager - Set-up.

I will try to give tips and tricks for the common issues/errors in the workflows by creating a Requirement document and moving the successor documents Work Package WP and Work Item WI until the completed status.

Note: This is just a starting document to start working with Focused Build for SAP Solution Manager written from a Change Control Management perspective.

For a complete view about how the different R2D functional areas like: Portfolio&Project Management, Process Management, Requirements Management, Change Control Management, Release Management, Test Management integrates together please don´t miss document Role-specific training curriculum document, last version here.


Important remark

To avoid methodically misuse of the functionality, it’s still highly recommended to:

  1. Start with Focused Build before you start with the conversion or implementation project, because it’s the project infrastructure where the project is based on. This is not only a tool set-up, but it comes along with methodology changes.
  2. After configuring the SAP Solution Manager/Focused Build development system, execute an initial project planning workshop with an experienced Focused build expert. E.g. the set-up of projects, release and test strategy should be discussed in context of your specific situation and needs, here.
  3. In addition, it makes very much sense to plan at least reviews for the topics:
    1. Solution Documentation/Document Management set-up before the Explore phase starts
    2. How to scope/tailor Requirement, Work Package and Work Items before the Realize phase starts
  4. Often underestimated is, to efficiently train the project team members before the project starts (general Focused Build overview) and during the project execution (brief role specific trainings according to the current project phase)


The system screenshots provided in this wiki are taken from an internal SAP Solution Manager 7.2 ST-OST 04 system.

The documentation screenshots are taken from:


Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Important information before starting

In the wiki First steps to work with Focused build for SAP Solution Manager - Set-up we created a Solution, a Release cycle and the required Projects, see below how these areas link together and with the Focused Build documents.

All these pictures below are taken from the document “Role-specific training curriculum” and I will suggest keep them in mind when working with the different Focused Build documents.


Our test case in that wiki followed this use case: One Release per project, with two Waves, and three Sprints per Wave:

See the different milestones per sprint and per wave:




 

Create a Requirement from a Solution Documentation Business Process/Process Step

During the Fit-Gap workshops the requirements are usually created.

The best practice is to add requirements to process or process steps reference, but requirements could be linked also to library elements if required.

As you can read in SAP Reference IMG SPRO point “Automatic release of technical objects between branches” then the elements: Executables, Developments, Configuration units, assigned to this process or process step will be considered to be released between the design and the development branch when running action Handover to Release in the Work Package created from this requirements.

Open your solution – Design branch in /nSOLDOC and select a process step for example.

Remember that we moved the processes relevant for our project implementation from the Best practices imported into the Import branch to the Design branch.

Now we need to create the requirements per each business process, process step reference. Select for example a process step from the processes structure, then go to Related Documents section on the right side.

When clicking in the Requirement: X link you will see that Requirement Managements tile opens with this Solution, branch and process step selected by default:

Create a new requirement by clicking in Requirement button, Create new Requirement:

Note: You could create Requirements directly from Requirements Management tile and link the element manually in the Element field by selecting it from the Processes structure.

Enter the required information like the owner who will be responsible of the requirement.

You need to describe in an attachment the requirement description, what you need to have for this particular process step in this particular process context.

Attachments

The attachments tab in the requirement/work packages is a possibility to describe detailed and based on a predefined template what is requested. This document is exclusively stored in the CRM transactions. Once created in a requirement, the attachment will be passed to all work packages which are successors of the requirement.

You can create an attachment based on a template, edit it offline and update it by dropping (document type attribute will be maintained) or just by dropping a local file over the drop area.

See SAP Reference IMG SPRO point Define allowed document types as attachment.


You can also change the element or add additional elements from the Processes structure.

The business processes, process steps assigned to the Requirement will be inherited by the Work Package created or linked with this requirement.

Requirement Classification

It is really important to indicate the Requirement Classification:

  • Gap: Is used for a new development. Technical design is done by developer in the Work Item- Technical design document
  • WRICEF: Is an SAP extension for a workflow, report, interface…, the specification is often already a mixture between functional and technical design in the work item
  • Fit: Is used for customizing. So, specification is often an existing standard configuration guide and only a customizing documentation is needed to be maintained on Work Item level
  • Non-functional: Is used for documentation upload or a parameter setting without the need to document a Functional Specification (no document KPI maintained in customizing for Work Package and Work Item). 

In the SAP Reference IMG SPRO point Document KPI Framework you need to answer these questions:

  • Which documents are required in the work package and in the work item?
  • What is the right document processing status for each particular work package or work item document status?

You can see that the KPI-logic is like this:

If you have a work package it depends on the classification this is what you need to provide from documentation-perspective:

  • Gap: Functional Specification type Gap, Single Functional Test Case
  • WRICEF: Functional Specification type WRICEF, Single Functional Test Case
  • Fit: Configuration Guide, Single Functional Test Case
  • Non-Functional: no documentation required

The Functional Specification type Gap and WRICEF, and the Single Functional Test Case document needs to be in status Released when the Work package moves to Scope Finalized and beyond this status. KPIs: FSPEC and FSPEC.

For the work item (NC) the developer will create a Technical Specification document for Gap and WRICEF classifications, or a Configuration Guide for a Fit classification. The Technical Specification/ Configuration Guide document need to be in status Released when the work item moves to status Successfully tested. KPI: TSPEC.

But if for example you have a work item with Non-Functional classification, but you created a technical design document, although it is not needed, also this document needs to be in status Released when the work item moves to status Successfully tested.

I selected in my example GAP Classification and Save.

I move back to the Requirements Management tile and open the created requirement and execute the first action: Send for Approval and then Approve.

Note: you could approve the requirements also in the Mass Change Operations tile.

Working with the Work Package

When the requirement is in status Approved you can create a Work Package from it or assign the requirement to an existing work package.

The Work Package and Requirements relation is defined in SAP Reference IMG SPRO point Define Requirement and Work Package, attribute REQ_WP, options 1:1, 1:n or n:m.

If you select the option to create a new work package you will get this screen:

Enter the Title, Owner and select the project and wave that you created.

Select the classification for the Work Package. Remember that depending on the classification selected you will need to create different documents.

Only if you select Non-Functional no document needs to be created.

It is possible to create a Work Package directly and without Requirement assignment. Later you could add the process structure.

Work Package is created, click in the document number:

The Focused Build – Architect owner of the work package can find the work package under My Work Packages tile.

When the Work Package opens you can see in the Details section the release cycle linked to the document in Actual Release field.

If you click on the Title of the document, you will get the document opened in CRM Web UI.

Run Action-> Define Scope

WP moves to status Scoping and FIRST you need to go the Documentation tab as you need to add/create the two required documents per the process step: Functional Specification and Single Functional Test case (Categories: Single Functional test case or/and Integration test case or/and Regression test case, …), click on the Create icon below if the documents still are not created.

Documentation


Enter any Filename value, then Document Type will be available. Select the Document type for the element you want and click on Create.

Create also the Single Functional Test document:


Note: the document types offered in the Work Package will depend on what is behind the structure selected, will depend on the elements assigned to the process step.

For example, if under the process step you have an element of type Configuration unit you would get the option to select Document type Configuration guide.

Or if you created an element of type Transaction you will get the Document type Technical Design, although the Technical Design is expected to be created in the work item created from this work package.


In the Document Type Administration for document Technical Design you will see in the Usage that this document is not available at process level, only at process steps level and only for element types like BSP, Classes, Transactions.


In the case that you have already created documents for a process steps in SOLDOC you can assign this document to the work package by clicking in the Assign icon next to the document.

You could also create the documents locally and select several documents and drop them over the Documents area. A popup will appear for you to select the document type, element type to which the document will be assigned and the element for each of the dropped documents.

The decision where the dropped document will be stored is done in the background by dropDocs and based on the standard document type configuration e.g.:

            - Functional specification will be stored at <Step origin>

            - Single Functional Test at <Step origin>

            - Technical Design at development or executable elements

            - Use Case at <Step reference>

Scope

In the Scope tab click on Add + icon:

Select the type:

  • Work Item (NC): development with TR transport
  • Work Item (GC): development with no TR transport

You need to add the processes/process steps of this work package and the associated scoped documents, all of them, in one single work item or in several work items according to your business needs.

Then when creating the work items or work items all elements will be inherited to the Work item that is in the development branch.

You can select the Sprint for the work item and the productive system of the cycle in case that more than one production system exists.

You can enter the developer responsible, then the developer will be able to find the work item in tile My work items.

Still the work item is not created.

Now you need to set to Released status both documents, select the document and click on this icon:

Then the Solution Architect is ready to select Action-> Approve Scope

When the scoping is finalized run the action Handover to Development, the work item will be created.

When the handover is done to Dev Team, the status of the Work Package will be changed to To be Developed. Doing this, the Work Items will be created.

Then all content related to the Work Package, is automatically released to the Development Branch.

Work item document is created, by clicking in the Description name link you can open the document:

Also, you can see in the Relations tab the document number of this created work item:


The process step and the associated documents are now in the Development branch.

Working with the Work Item

The developer should go to My Work Items tile and open the Work Item.

In the Mass Change Operations tile you could always find the Work Items, by selecting Work item.

Then move the work item to In development as first step by selecting action Start Development. For this the sprint needs to be assigned in the Details tab, only the released sprints in the Project Management can be assigned.

Transport

Developer can start with the development activities.

Documentation

First development task should be to create the Technical Design document.

This document type is offered in the Work item if there is a Executable element like a transaction created for this process step, but in our example the selected process step “Provide additional information” was not containing any element, so in this example we will not get the Technical Design document offered.

As we did before we click on the icon Create new document in the Documentation tab, Documents section for this structure process step:

But if under this Process step Provide additional information there was in the element side an executable like a Transaction then the option to select Technical Design document will be shown for selection and a Technical Design needs to be created and released.

Now developer moves to the Transport tab to create a TR that contains the required changes for your work item of type GAP. Click on the + icon.

Ensure that you see the correct transport track under Transport Landscape Information area.

Transport requests will be created in the development system, source system, CRY:100.

Click in the icon next to the development system to logon to the system.

How make a dummy change in the source system:client, like an entry in sm30: T005A.

Save it to the created TR.

Release only the task of this TR in se03 for example.

and then move the Work item to status To be tested, action Pass to Test.

According to the entries for the Work item transaction type S1MJ, remember that in Focused Build you need to work with the delivered transaction types, a TOC will be created,  released and then imported into the target system CRY:200 in our test scenario.

See this in sm34:aic_settings2:


A tester should logon to the quality system and check the changes by making the Unit test of this work item and then if the tests are passed tester can select action Confirm Successful test, this will release the original transport request and move the work item to status Successfully tested.


At this point the transport request is released and added to the import buffer of the quality system CRY:200 and in the document you get only the option to request the use of the preliminary import scenario to move this transport request quickly to production system via PPF actions in the document.

This predecessor work package could have several work items, so in Focused Build, when the last work item reaches the status Successfully tested the WP will move to status To be tested, SOCM action SET_PREDOC.

The test coordinator needs to run the Single Function test SFT created at work package level, and if the SFT are ok then the test coordinator for this work package will set the status of the Work package from To be Tested to Successfully tested, in the work package.

If during the SFT issues are detected a Defect correction document can be created from the Work Package, that is in status To be tested. Work package will move to status In Repair.


Note: Usage of Test Suite in Focused Build

During this wiki we were speaking about different test types, test documents.

However, I don´t have enough knowledge to give you the steps to set up the Test Suite scenario and integrated it in the workflow explained here.

What I can say is that you need to go through the configuration guide for the Test Suite Configuration Activities.

After this you would be able to create from the Solution element test cases types like: Manual test cases in form of Test documents and Test documents URLs, Automatic test cases in form of Test Configuration and Test Steps test cases, only available in Focused Build.

You could assign then this Test Step test case to the work package, when scoping the work package.

When the successor Work item reaches the status Successfully tested after making the unit tests, the work package reaches the status To be tested.

Now for the Work packages that contains a test case, in the tile “Test Plan Management- Assignment Analysis and Test Plan Generation” the test manager can create a test plan that includes the selected work packages and from here the test packages will be created always one test package per work package since ST-OST 05 for Single functional test and Acceptance tests.

If you selected Work packages in status Handed over to release that are ready for the Functional Integration Test the test package creation is not mandatory one test package per work package you will see other options like One Test Package containing all Test Cases.

During the testing of the test cases the tester can find issues and create a Defect document and then a Defect correction document to fix the issues.

If there is no Test Suite integration the test coordinator can manually create a Defect correction from the work package Scope tab, when the work package is in status To be tested, where the developer and the tester will need to work to fix the detected issue.

This Defect correction can contain also new transport requests.

See the status workflow for ST-OST 07 where a new status In Delivery is introduced.

In the example I will select the option Confirm Successfully Test action in the work package:

Work package moves to status Successfully tested and also the successor Work Items.

What we have at this point is the TR released but not imported into the quality system:

Now we need to trigger the import of this transport request into the quality system CRY:200 by using the release batch import report, se38: /SALM/BATCH_IMPORT_TRIGGER

But first you need to configure this report in SAP Reference IMG SPRO point Configure Release Deployment and Batch Import.

Let me show you quick which are the settings to configure the release batch import for triggering the imports into the quality system.

Variant provided for this import /SALM/QAS

Using Import Config IMPORT_QAS

See how this import config is taking into account the normal change documents, S1MJ documents, in status Successfully tested:

This import config is also taking into account for imported in transport requests for Defect Correction S1TM in status Transport to Retesting E0004 and To be Retested w/o Transport  E0011.

So, the transport request of our work item that is in status Successfully tested will be considered to be imported.

Create specifically an entry for this variant, by selecting its Import Config, and your solution and change control landscape used in the release cycle where this work item was created.

Enter also the system where the import will be done.

Maintain the client number and the type of RFC to be used to trigger the import into the quality system

Then run the report /SALM/BATCH_IMPORT_TRIGGER indicating the release cycle and the variant

If I remove the Test Mode flag the import of the TR of our work item will be done in CRY:200, report exit:

Check this in the transport request logs:

Or in the work item document Transport tab:

Now it is time to move the work package manually to status Handed Over to Release.

This can be done when the release cycle is in phase Prepare, but theoretically we should move the release cycle to phase Build.

In Build phase no more new Work Package, Work items can be created for this release!!

If you try to move the Work Package to status Handed Over to Release when the cycle is in phase Deploy you will get error message: "Activate the release" /SALM/IT_REQUIREMENT 011 as the only possible phases for the major release are Prepare or Build phase.

Please check SAP Note 3038903 - "Focused Build - Unwanted inconsistent assignment at Work Package prevents status change" when you get an error trying to move the Work Package from 'Successfully tested' to 'Handed over to release', this will help in case of inconsistencies with the Solution Documentation elements assigned in the Work Item and the Work Package.


When you move the work package to status Handed Over to Release, automatically the successor work items and possible defect corrections will move also to status Handed Over to Release. Predecessor requirement will change to Realized automatically.

Note: Only the transport requests of the work items and defect corrections in status Handed Over to Release will be imported into the preproduction system, CRY:300 in our case, when the release batch import report run for the variant /SALM/RELEASE_PRE.

Run report /SALM/BATCH_IMPORT_TRIGGER for /SALM/RELEASE_PRE after making the correct settings for this variant, Import Config IMPORT_INTEGRATION_TEST.

The release cycle should be moved to Test phase, and the Test coordinator would run the Functional Integration Test FIT (Final) or the Regression Test in the Preproduction system CRY:300 before moving the changes to the production system. Test coordinator can make the testing manually with no evidences or by creating a Test Plan for this.

When the release cycle is in status Test, no new Work Packages can be added to the wave for this Release. Project Team can only use Defect Correction.

Finally, we need to get our changes imported into Production system, for this you need to move the cycle to phase Deployment Preparation, in this phase all Defect Corrections with Priority 1 and 2 must be set to ‘Handed Over to Release’ and have to go live with the actual Release

Then move the release cycle to phase Deploy.


The release batch import report will check the release cycle S1MR status when using variant /SALM/RELEASE, Import Config IMPORT_PRODUCTION:

Work items in status Handed Over to Release like our work item will be taken into consideration and this time according to the settings below it will move to next status that is Productive and then to Completed according to the settings in sm30: AIC_CRM_CM_ST_CH for S1MJ

Create the entry for the variant and your solution, change control landscape used by the cycle and the systems entries where to trigger the import:

Move the release cycle until the Deploy phase with the release manager business role, if no the release batch import will fail.

My cycle was at this moment still is in Prepare phase although for being consistent with the methodology it should have been moved to Test phase already as indicated before.

Run the release batch import with these values:

Report exit

When the Import has been successful and according to the settings in the variant used the work item document status will change, this status change can trigger also the PPF action maintained in SM30: AIC_CRM_CM_ST_CH for the document status shift.

Since ST-OST 07 it is requested to activate the Import Feedback functionality as indicated in the configuration guide, see also KBA 2746697 - Active Import Feedback - Additional information. The Release Batch Import program is informed about the actual Import Status via the Active Import Feedback functionality.



So, work item moved to status Completed and the predecessor Work Package too.

Process step arrived to Production branch.

Predecessor Requirement moved also to Completed.

Now you can switch the release cycle to phase Hypercare.

You will get a popup with all open work packages/work items/open defect corrections with Priority 3 and 4 will be assigned to the next Release automatically.

It is time to use the Fix pace scenario by creating Request for Change for Urgent Fixes.



Related Content

Related Documentation 

Related Notes

  • 3038903 - Focused Build - Unwanted inconsistent assignment at Work Package prevents status change







  • No labels