The technical basis for my post is a SAP Solution Manager system version 7.1 with a service pack SP14. To be honest, I expect that the Solman 7.2 functionality (e.g. more FIORI-apps to come) will be more complete. But I couldn't wait. Additionally installed is the add-on Focused Build. (see also http://support.sap.com/focused-build). I'll show You in an application lifecycle management approach, how releases can be managed with SAP Solution Manager. Part 1 covers the gathering of requirements and documents ending in scoping the software-deliverables.
Coming from a waterfall-based project methodology it was interesting for me how to overcome the hurdles of an agile software development method.
Focused Build (FB) uses the SAP Solution Manager Change Request Management (CHARM) stack plus the PPM (project and portfolio management) stack. Please ensure first of all that CHARM is configured and works. Install the Focused Build add-on and do the customizing following the configuration guide provided by SAP.
Compared to standard SAP Change Request Management, FB delivers a few excellent features. Just to name a few:
a.) Easy document management (for blueprints, user-stories, manual test cases, configuration guides, requirements etc.) called DropDocs.
b.) Release management for bigger projects with the ability to build the software in sprints (e.g. 2 weeks) and waves (more than one sprint). At the end of a wave it's a good practice to invite customers for so-called show & tell sessions.
c.) Enhanced Testing Suite (including test plan creation from the PPM-Project linked to a Solution Manager project) and enhanced tester capabilities. Every phase of development can be assigned to certain test phases. (e.g. waves could be linked to UAT, meaning user acceptance tests).
d.) Dashboards (for releases, projects, test status and solution readiness).
One of my favourite reasons to evaluate FB is the possibility to have a daily updated quality dashboard.
Quality starts in my opinion with the requirement. It's useful to have a unique reference in every requirement to ensure traceability (backwards from an incident) and completeness checks.
Summarized - with the Focused Build suite my wish to create an early warning system for development projects is more likely to become true.
Let me give you an impression of how to approach this mission by means of the process which follows the diagram.
(diagram) starting from top left:
1. Analysis of the requirements:
I recommend using the 7R for changes following ITIL (IT infrastructure library). This means storing the information about ...
(1) the requestor(role: requestor),
(2) the responsible ( role: change manager),
(3) the resources (the corresponding PPM-resources are: developer, technical architect, business process owner, IT operator etc.),
(4) the return (= result of a successful implementation, could be stored in a text),
(5) the risks,
(6) the relationships and last
(7) the reasons ( ... for the change)
in the appropriate transaction types in the Solution Manager system.
2. Requirements documents:
Compared to the standard CHARM (change request management process), where the documents are uploaded as attachments, in Focused Build it's easier - simple by means of drag & drop. (tool Dropdocs).
3. Blueprints & Concepts:
The ALM (application lifecycle management) circle at the right shows the build-process followed by a QM (quality management) part and ends-up in the production system with the phases operation and run.
The above mentioned information in a CHARM-based system would have been stored in the several parts of the incident and change request. Until version 7.1 of solution manager You could use an incident as an early form of requirement just by making clear in the short text that it's something new
to be build.
In Focused Build you get an additional transaction type named business requirement. Further information will be stored in work packages and work items derived from this business requirement. These work items differ between a general change and a normal change (with the ability to add software transport functionality).
In the Focused Build the project planning and software development process is divided into these phases:
a. Prepare
b. Scope
c. Build
d. Deploy
e. Run.
You can use project templates just by uploading these company-standards as XML-document.
After that you have to change the scheduled dates and assign the responsible resources.
Depending on the project type you assign a release. The release specifies beneath others the go live date. Set your project priority and status. Continue with the planning (preparing of the project). Go on with planning work packages and scope your release by work items adding controlled project documents.
As I mentioned before documents in Focused Build are handled easier than in a standard Solution Manager. You assign these to the work packages just by dragging & dropping them from the file explorer. Via customizing you are able to control which documents are obligatory and who is in charge of releasing them. This is the part where the document steering is done with. By means of standard SAP business workflow workitems You are able to let a responsible person to finally release the attached project documents. Please differentiate between the Focused Build work items (a kind of change document) and the SAP business workflow workitems which are representatives of clickable next transactions, dialogues or actions.
A work package correlates in CHARM with a change request document. The work item correlates with a certain kind of change document.
In my next post I'll address how to test the requested parts of the project in order to release them. There You will learn some of the additional roles which have been invented with the add-on and which appreciated testing functionalities have been added.
Coming from a waterfall-based project methodology it was interesting for me how to overcome the hurdles of an agile software development method.
Focused Build (FB) uses the SAP Solution Manager Change Request Management (CHARM) stack plus the PPM (project and portfolio management) stack. Please ensure first of all that CHARM is configured and works. Install the Focused Build add-on and do the customizing following the configuration guide provided by SAP.
Compared to standard SAP Change Request Management, FB delivers a few excellent features. Just to name a few:
a.) Easy document management (for blueprints, user-stories, manual test cases, configuration guides, requirements etc.) called DropDocs.
b.) Release management for bigger projects with the ability to build the software in sprints (e.g. 2 weeks) and waves (more than one sprint). At the end of a wave it's a good practice to invite customers for so-called show & tell sessions.
c.) Enhanced Testing Suite (including test plan creation from the PPM-Project linked to a Solution Manager project) and enhanced tester capabilities. Every phase of development can be assigned to certain test phases. (e.g. waves could be linked to UAT, meaning user acceptance tests).
d.) Dashboards (for releases, projects, test status and solution readiness).
One of my favourite reasons to evaluate FB is the possibility to have a daily updated quality dashboard.
Quality starts in my opinion with the requirement. It's useful to have a unique reference in every requirement to ensure traceability (backwards from an incident) and completeness checks.
Summarized - with the Focused Build suite my wish to create an early warning system for development projects is more likely to become true.
Let me give you an impression of how to approach this mission by means of the process which follows the diagram.
(diagram) starting from top left:
1. Analysis of the requirements:
I recommend using the 7R for changes following ITIL (IT infrastructure library). This means storing the information about ...
(1) the requestor(role: requestor),
(2) the responsible ( role: change manager),
(3) the resources (the corresponding PPM-resources are: developer, technical architect, business process owner, IT operator etc.),
(4) the return (= result of a successful implementation, could be stored in a text),
(5) the risks,
(6) the relationships and last
(7) the reasons ( ... for the change)
in the appropriate transaction types in the Solution Manager system.
2. Requirements documents:
Compared to the standard CHARM (change request management process), where the documents are uploaded as attachments, in Focused Build it's easier - simple by means of drag & drop. (tool Dropdocs).
3. Blueprints & Concepts:
The ALM (application lifecycle management) circle at the right shows the build-process followed by a QM (quality management) part and ends-up in the production system with the phases operation and run.
The above mentioned information in a CHARM-based system would have been stored in the several parts of the incident and change request. Until version 7.1 of solution manager You could use an incident as an early form of requirement just by making clear in the short text that it's something new
to be build.
In Focused Build you get an additional transaction type named business requirement. Further information will be stored in work packages and work items derived from this business requirement. These work items differ between a general change and a normal change (with the ability to add software transport functionality).
In the Focused Build the project planning and software development process is divided into these phases:
a. Prepare
b. Scope
c. Build
d. Deploy
e. Run.
You can use project templates just by uploading these company-standards as XML-document.
After that you have to change the scheduled dates and assign the responsible resources.
Depending on the project type you assign a release. The release specifies beneath others the go live date. Set your project priority and status. Continue with the planning (preparing of the project). Go on with planning work packages and scope your release by work items adding controlled project documents.
As I mentioned before documents in Focused Build are handled easier than in a standard Solution Manager. You assign these to the work packages just by dragging & dropping them from the file explorer. Via customizing you are able to control which documents are obligatory and who is in charge of releasing them. This is the part where the document steering is done with. By means of standard SAP business workflow workitems You are able to let a responsible person to finally release the attached project documents. Please differentiate between the Focused Build work items (a kind of change document) and the SAP business workflow workitems which are representatives of clickable next transactions, dialogues or actions.
A work package correlates in CHARM with a change request document. The work item correlates with a certain kind of change document.
In my next post I'll address how to test the requested parts of the project in order to release them. There You will learn some of the additional roles which have been invented with the add-on and which appreciated testing functionalities have been added.
- SAP Managed Tags:
1 Comment
