software asset management | functional documentation

Software Asset Management Functional documentation

RBG Applications (Pty) Ltd [email protected]

Abstract About master data, transacting and configuration

SOFTWARE ASSET MANAGEMENT | Functional documentation

Table of Contents

1 Overview ......................................................................................................................................... 3

1.1 Introductory note .................................................................................................................... 3

2 Master data ..................................................................................................................................... 4

2.1 Participant ............................................................................................................................... 4

2.2 Functional area ....................................................................................................................... 4

2.3 Functional owner .................................................................................................................... 4

2.4 Functional consultant ............................................................................................................. 4

2.5 SDLC team ............................................................................................................................... 5

2.6 Project ..................................................................................................................................... 5

2.7 Business process ID ................................................................................................................. 6

2.8 Clearance code ........................................................................................................................ 6

3 Transactional data ........................................................................................................................... 7

3.1 Change request ....................................................................................................................... 8

3.2 Development request and request version ............................................................................ 8

3.3 Work request .......................................................................................................................... 9

3.4 Work item ............................................................................................................................... 9

3.5 Deployment unit ..................................................................................................................... 9

3.6 Technical objects ................................................................................................................... 10

3.7 Time record ........................................................................................................................... 10

3.8 Activity .................................................................................................................................. 10

4 Configuration ................................................................................................................................ 11

4.1 Request settings .................................................................................................................... 11

Priority ........................................................................................................................................... 11

Complexity .................................................................................................................................... 11

Classification ................................................................................................................................. 11

Cancellation reason ....................................................................................................................... 12

4.2 Request category .................................................................................................................. 12

Change request category .............................................................................................................. 12

Work request category ................................................................................................................. 12

4.3 Request number ranges ........................................................................................................ 12

Number range for change request................................................................................................ 12

Number range for development request ...................................................................................... 13


Number range for composite development ................................................................................. 13

Number range for work request ................................................................................................... 13

4.4 Change request approval ...................................................................................................... 13

4.5 Application settings ............................................................................................................... 14

Application behaviour ................................................................................................................... 14

Application attributes ................................................................................................................... 14

Tracking notification ..................................................................................................................... 14

Classification ................................................................................................................................. 15

Online help .................................................................................................................................... 15

Archiving ....................................................................................................................................... 16

4.6 Technology settings .............................................................................................................. 16

Systems ......................................................................................................................................... 16

Technology .................................................................................................................................... 17

Load ABAP object types ................................................................................................................ 17

4.7 Capacity period settings ........................................................................................................ 18

Capacity period ............................................................................................................................. 18

Time unit of measure .................................................................................................................... 18

4.8 Business document service settings ..................................................................................... 18

BDS document classes .................................................................................................................. 18

BDS document class descriptions ................................................................................................. 19

Relevant BDS document classes ................................................................................................... 19

4.9 Application integration ......................................................................................................... 20

Ticket system ................................................................................................................................ 20

4.10 Enhancement ........................................................................................................................ 20

Change request business add-in ................................................................................................... 20

Development request business add-in ......................................................................................... 21

Work request business add-in ...................................................................................................... 21

5 Administration .............................................................................................................................. 22

5.1 Close expired change requests ............................................................................................. 22

5.2 Reschedule open work requests ........................................................................................... 22

5.3 Mass load of parent deployment units ................................................................................. 22

5.4 Evaluate work request implementation progress against schedule ..................................... 23

5.5 Update of SAP CTS+/ TMS deployment units from original system ..................................... 23

5.6 Export of time records for SDLC resources ........................................................................... 24


1 Overview

During the course of IT projects and in continuous improvement thereafter substantial capital

expenditure is made for bespoke software development. The purpose of ‘Management of bespoke

Software Assets’ (‘Software Asset Management’ for short) is to ensure a transparent, well

documented outcome of bespoke software development and in that way to protect the investment

made. Software Asset Management (SAM) will orchestrate project managers, functional consultants,

team leads, testers, application support and technical resources in such way that supportable and

maintainable software is produced on time.

Application features of SAM include support of all steps of the Software Development Lifecycle

(SDLC) managed in change requests, development requests, development request versions, work

requests, work items, tasks, activities and time records.

The add-on automatically carries out SDLC team capacity planning within and across development

teams giving achievable estimated software build completion dates. A workload overview by SDLC

team and each team member provides for capacity monitoring.

Role based user interfaces provide focused workplaces for role players participating in SDLC.

Further features of Software Asset Management include amongst others storage of supporting

documents, management of technical objects as bespoke software assets, capture of deployment

units and tracking through the configured system landscape, management of SDLC participants and

authorization control including management of clearance levels, free text and attribute search for all

application objects, automated e-mail based communication to participants, audit trail of changes,

capacity planning for SDLC teams with automated calculation of estimated completion dates for

work items.

This document provides an overview of master data, transactional data, configuration options and

administration related to Software Asset Management.

1.1 Introductory note

In the following we will refer to transaction codes where required to start relevant Software Asset

Management UIs. In order to avoid having to use SAP GUI for back office features we suggest you

activate the ‘HTML GUI’ internet service on your application servers using transaction SICF (path

‘/default_host/sap/bc/gui/ sap/its/’) and use your browser to navigate to the transactions that are

being pointed out.

Transaction /MBSA/APP is a useful area menu of Software Asset Management that contains all

possible master data, configuration, administration and UI options. Insert this transaction into your

favourites in SAP GUI or bookmark the corresponding webgui URL to this transaction in your

preferred browser. To view transaction /MBSA/APP in any browser the URL is composed as follows:

<protocol http or https>://<hostname>:<port>/sap/bc/gui/sap/its/webgui?sap-

client=<sapclient>&~transaction=/MBSA/APP


2 Master data

Software Asset Management uses master data to keep track of people, organization and business processes that are affected by the Software Development Lifecycle. The following is a synopsis of all master data items that the application uses. You can access all master data by following option ‘Maintain master data’ in area menu /MBSA/APP.

2.1 Participant

Participant in the Software Development Lifecycle (SDLC)

Use

A participant is any person participating in SDLC as functional owner, project manager, team lead, functional consultant, software developer, system administrator or tester. Depending on the role each participant contributes different services to the implementation of bespoke software assets.

Dependencies

Depending on team membership a participant plays a technical, system administrator or functional role in SDLC.

2.2 Functional area

Functional area of a change request or work request

Use

A functional area is an area of common business practices with similar requirements in respect of their IT processing needs.

Dependencies

A functional area is owned by one or several functional owners. The functional owner approves or rejects suggested business requirements in his functional area to ensure a consistent overall approach.

2.3 Functional owner

Functional owner of a request for change

Use

The functional owner is a participant in Software Asset Management. He owns business requirements from ideation of a solution to deployment of its implementation to the Production system.

Dependencies

It is part of the responsibilities of the functional owner to approve change requests for implementation. The functional owner uses his functional owner workplace for this purpose.

2.4 Functional consultant

Functional consultant


Use

Functional consultants are participants in Software Asset Management. Their role in the Software

Development Lifecycle is to translate business requirements into solution proposals for technical

resources to implement as bespoke software solutions.

Dependencies

Functional consultants create development requests or new development request versions, they

upload functional specifications to document the proposed solution and accompany the

implementation, testing and deployment to the production systems. To fulfil their tasks functional

consultants can make use of the functional consultant workplace.

2.5 SDLC team

SDLC team

Use

An SDLC team is a team taking part in the Software Development Lifecycle (SDLC) for the

implementation of bespoke software solutions. An SDLC team provides technical, functional or

system administration services to the IT services organization.

Dependencies

An SDLC team has a defined capacity determined by the number of team members and allocated

percentage of time each team member spends working for the team. Work requests that are

scheduled for implementation by an SDLC team consume that team's capacity. The estimated

implementation completion date of a newly scheduled work request is calculated automatically in

light of current team capacity.

Each SDLC team has a team lead who analyses business requirements coming through change

requests or solution proposals in the form of functional specifications submitted by functional

consultants in new development request (versions). Team leads estimate implementation effort and

schedule work requests for implementation thereof. They monitor implementation progress and

manage delays or overruns with their team members. To fulfil their tasks SDLC team leads can make

use of the team lead workplace.

2.6 Project

Project for the implementation of bespoke software solutions

Use

A project in Software Asset Management serves to ring-fence budget and resources for the

implementation of bespoke software assets. A project has a project manager and team members

that all contribute to the delivery. A project goes through various project phases. Depending on the

project phase different activities are allowable.

Dependencies

During the 'Planning' phase change requests and development requests can be created and

implementation scheduled using work requests. No hours may yet be logged for implementation of


work. During 'Implementation' all planning activities for scope adjustment are allowed and

implementation time may be logged against the project. During 'Debriefing' no further scope

changes are allowed but further implementation hours for closing out of the project may be logged.

Project managers manage functional consultants to ensure timeous delivery of solution proposal

documents in the form of functional specifications. They follow up with SDLC team leads for the

timeous scheduling of work requests and with software developers for completion of work within

estimated timelines. To fulfil their tasks project managers can make use of the project manager

workplace.

2.7 Business process ID

Business Process ID as context of a bespoke software asset

Use

Business process IDs can be recorded against development request use cases. A use case identifies

the user group, action, object, location and timing in which the bespoke software solution plays a

role.

Dependencies

Development requests and their related technical objects can be found with use case elements as

selection criteria. This way it is possible to find development requests e.g. by user group or location

of its use.

2.8 Clearance code

Clearance code

Use

A clearance code provides an additional level of authorization control to protect classified

information in Software Asset Management from unauthorized access.

Example

In exceptional situations project teams might engage in design and implementation of bespoke

software solutions that are subject to non-disclosure agreements. All transactional data related to

such initiative can be protected from unauthorized access by capturing an appropriate clearance

code. Clearance codes are inherited from change request to development request and request

version and from development request version to work request.


3 Transactional data

Software Asset Management uses transactional data to keep track of information that originates

during the Software Development Lifecycle. One of the most important outcomes of SDLC and a

focus of the Software Asset Management application are the bespoke software assets (technical

objects) that get created during implementation of business requirements. The following is a

graphical synopsis of the transactional data items that the application uses and their relationships.

You can access all transactional data in Software Asset Management by executing

transaction ‘/MBSA/APP_INBROWSER’ from within the SAP GUI or

using one of the ‘Execute’ options (in place or in browser) in area menu /MBSA/APP or

specifying URL <protocol http or https>://<fully qualified host name>:<http port of the ABAP

web application server>/sam, e.g. http://solmanprod.co.uk:8000/sam (available only if

related post-installation activity has been carried out)

This will open the UI of Software Asset Management (SAM UI for short) in your default browser

(options 1 and 2) or the browser of your choice (option 3). Each of the above transactional data

items has its own registry that allows for selection by attributes or search by means of free text.

Apart from registries there are also dedicated workplaces for all SDLC role players. Workplaces

contextualize the above transactional data items in a way best suited for the role held by SDLC

participants. Functional owners use their functional owner workplace for change request approval,

technical and functional team leads use their workplace for work request scheduling, technical and

functional resources use their workplace for self-service including self-allocation of work items,

progress feedback with time- and activity recording, to deliver solution proposals and other

supporting documentation for development requests or to monitor deployment of approved

changes to Production. Functional testers use their workplace to pass or fail testing of bespoke

software assets. Project managers orchestrate deliverables of project team members.

http://solmanprod.co.uk:8000/sam


3.1 Change request

The change request is an optional transactional data item in Software Asset Management. Its main

purpose is to be the ‘interface’ between the holder of requirements for bespoke software solutions

in an enterprise (typically: business, facilitated by an Enterprise Helpdesk Ticketing system) on the

one and the IT delivery organization on the other. The change request is the handle to:

Approval for implementation

Effort estimation and actuals

Business requirement documentation

Organizational context of the required change

Overall implementation, test and deployment status

After submission change requests are approved by the functional owner of the affected functional

area. After approval for implementation is granted, SDLC team leads analyse the required change,

create follow-on development requests or development request versions for solution

documentation and schedule for implementation using work requests. SDLC resources pick up

scheduled work requests and implement as per functional specification provided in the development

request (version). Status and actual implementation effort of the change request are tracked based

on progress feedback provided by SDLC resources on a regular basis.

Access change requests by means of option ‘Change requests’ in SAM UI.

3.2 Development request and request version

The development request and development request version is core to the Software Asset

Management application. It collects solution documentation and implementation context of

technical objects that represent the assets as outcome of bespoke software development. A

development request can be created stand alone or from a preceding change request.

A new development request should be created whenever a new bespoke software feature is

required. A new development request version should be created when an existing software feature

is amended during continuous improvement. An example of a development request is e.g. created

for the first implementation of a BAdI for purchase order item changes. Each change to the initial

BAdI implementation thereafter is documented with a new development request version. Each

development request version is a container for solution documentation. Ideally functional

specification documents are versioned and contain a revision history.

Development request versions are scheduled for implementation by creating related work requests.

SDLC resources pick up such scheduled work requests and implement as per functional specification

provided in the development request (version). Implementation status and actual implementation

effort of development request versions are tracked based on progress feedback provided by SDLC

resources on a regular basis.

Access development requests by means of option ‘Development requests’ in SAM UI.


3.3 Work request

The work request is core to scheduling, capacity planning and implementation status tracking in the

Software Asset Management application. A work request can be created standalone, from a

preceding change request or from a preceding development request version. A work request should

be created standalone or with reference to a change request e.g. for bug fixes to bespoke software

features in Production. A work request should be created with reference to a development request

version when it is for implementation of a new software feature or for a change to an existing one

that is documented in a new version of the related functional specification.

For creation of a work request the following items of interest have to be provided (amongst others):

Implementation effort estimate

Requested date of completion

SDLC team and SDLC resource

Planned specification delivery date

Using this information Software Asset Management schedules the implementation of the work

request and calculates the estimated completion date in consideration of the current workload of

the assigned SDLC team. SDLC resources pick up such scheduled work requests and implement as

per functional specification provided in the related development request (version). Implementation

status and actual implementation effort of work requests are tracked based on progress feedback

provided by SDLC resources on a regular basis.

Access work requests by means of option ‘Work requests’ in SAM UI.

3.4 Work item

A work item originates when a work request is allocated to an SDLC resource for implementation.

This occurs when the SDLC team lead assigns an SDLC resource or when the SDLC resource picks up a

work request for implementation in his or her workplace. SDLC resources provide feedback about

implementation progress for each work item regularly. Progress feedback consists of:

Open effort estimate

Actual work hours spent

Revised completion date

SDLC resources use their relevant workplaces to provide progress feedback (functional consultant,

software developer, system administrator). Their progress feedback is considered when evaluating

the implementation status in respect of schedule, when rescheduling open work requests and also

for scheduling of new work requests in the SDLC team.

3.5 Deployment unit

A deployment unit is created in Software Asset Management for the purpose of getting insight into

technical objects that were created or changed during the implementation of a work request and

also to track their deployment in the system landscape.


When you choose to create a deployment unit for deployment tool ‘SAP TMS’ or ‘SAP CTS+’

Software Asset Management automatically retrieves the content of that deployment unit (in this

case: the transport request) from the original (source) system. For each entry in the transport

request a technical object is created in the application and cross-references are established to the

work request, development request, solution documentation and change request involved.

Access deployment units by means of option ‘Deployment units’ in SAM UI.

3.6 Technical objects

Technical objects are the outcome of development of bespoke software solutions. Technical objects

can be captured manually for work requests or can be created automatically by capturing related

deployment units for ‘SAP TMS’ or ‘SAP CTS+’. Technical objects like classes, methods, functions and

screens are bespoke software assets and management of those is a core purpose of Software Asset

Management. Technical objects are cross-referenced to the work requests, development requests,

solution documentation and change requests that caused the object to be created or changed.

Access technical objects by means of option ‘Technical objects’ in SAM UI.

3.7 Time record

Time records are created when SDLC resources feedback actual working time for their work items. A

time record documents the time in hours that a participant spent on a specific workday for the

implementation of a specific work request. Participants use their functional consultant, software

developer or system administrator workplaces to capture their actual working time.

Time records are rolled up into the related work request, development request version and change

request. With this the overall actual implementation effort across all participating resources involved

in a change request is available for comparison to the effort estimate.

Access time records by means of option ‘Reports->Time log’ in SAM UI.

3.8 Activity

When the granularity of time records (participant, day of work, work request) is not sufficient for

tracking of actual time spent then progress feedback may also be provided on activity level. Using

activities participants can break down further their time spent on a day for a specific work request.

As an example a software developer can document for a specific day and work request which time

he or she spent analysing the functional specification and how much time was spent writing source

code.

To provide activity level progress feedback participants have to ‘toggle’ their view in progress

feedback. When in the activity view, several activities can be captured for the same work request

and work day. Saved activity time is rolled up into time records.

Access time records by means of option ‘Reports->Activity log’ in SAM UI.


4 Configuration

Software Asset Management is a configurable application. The following is a synopsis of all options

in the Implementation Guide (IMG) to configure the application to your needs. You can access the

IMG by using transaction code /MBSA/IMG in the SAP GUI or by choosing option ‘Configure

application’ in area menu /MBSA/APP.

4.1 Request settings

Priority

Use

Optional configuration setting.

Priorities indicate the importance/ urgency of requests for bespoke software development. Priority can be specified as an attribute of a change request or work request. Priorities captured in the change request are merely for indicative purposes. When a work request is created with reference to a change request the change request priority is promoted into the work request. In the work request the priority influences the calculation of the estimated completion date. When scheduled work requests absorb developer team capacity in descending sequence of priority.

Requests can be selected by priority.

Activities

Capture priority identification and description. Assign a ranking to establish a sequence of priorities. This will impact scheduling in the developer team capacity.

Complexity

Use


Complexity is an optional work request attribute. In Software Asset Management complexity is merely captured to help the developer team lead to make an effort estimate. Work request complexity thus only plays an indirect role for calculation of the estimated completion date.

Activities

Capture complexity identification and description.

Classification

Use


Classifications are used to group requests in Software Asset Management for the purpose of request selection.

Activities

Capture classification identifications and their descriptions.


Cancellation reason

Use


Cancellation reasons can be captured for change requests, development requests and work requests. A cancellation reason indicates that the corresponding request is no longer required. No follow-on activities are allowed for cancelled requests.

Activities

Capture cancellation reason identifications and their descriptions.

4.2 Request category

Change request category

Use


Just like classifications request categories are used to group requests in Software Asset Management for the purpose of request selection. In addition to a request classification though the request category has attributes that control application behaviour. With change request categories you may configure that requests of certain categories do not (yet) require development. Change request of such categories are e.g. captured for the purpose of investigation before release to development.

Activities

Capture request categories and their descriptions.

Work request category

Use


Just like classifications request categories are used to group requests in Software Asset Management for the purpose of request selection. In addition to a request classification though the request category has attributes that control application behaviour. With work request categories you may configure that requests of certain categories do not appear in request listings unless specifically requested. Work request of such categories are e.g. captured for the purpose of support activities that need not be listed on project status reports (but do need to be listed on the timesheet for recording of actual time worked).

Activities

Capture work request categories and their descriptions.

4.3 Request number ranges

Number range for change request

Use

Required configuration setting.


The number range for change requests is used to provide numbers for change request numbering.

Activities

The application will attempt to draw change request numbers from number range '01'. Please therefore capture the number range with identification '01'.

Number range for development request

Use


The number range for development requests is used to provide numbers for development request numbering.

Activities

The application will attempt to draw development request numbers from number range '01'. Please therefore capture the number range with identification '01'.

Number range for composite development

Use


The number range for composite developments is used to provide numbers for composite development numbering.

Requirements

The application will attempt to draw composite development numbers from number range '01'. Please therefore capture the number range with identification '01'.

Number range for work request

Use


The number range for work requests is used to provide numbers for work request numbering.

Activities

The application will attempt to draw work request numbers from number range '01'. Please therefore capture the number range with identification '01'.

4.4 Change request approval

Use


Configure change request approval levels by role and change request release to development dependant on approval level. If approval levels have been configured then Software Asset


Management will request change request approvals for all change requests. If you want to do away with the need for change request approvals remove all approval level configuration.

Choose an approver role allowed to approve on a specific level. Software Asset Management distinguishes the 'Functional owner' and 'External Approver' role. The functional owner chooses to approve or reject in the Functional Owner workplace for his functional area. The External Approver comes into play when a ticket is integrated with Software Asset Management and external approvals need to be taken into account. Approvals for approver role 'External Approver' cannot be given through the Software Management UI but only through the call of a corresponding Enterprise Service from outside the application.

Configure development release for developer teams dependant on a specific approval level. Only the configured teams may start development (create development requests with reference to an approved change request on the configured level).

Activities

Capture approval levels and their descriptions. Capture developer teams that may start development when a specific approval level has been set.

4.5 Application settings

Application behaviour

Use


Certain behaviour of the Software Asset Management application is configurable. Use the configuration settings in this activity to control such application behaviour.

Activities

Configure application behaviour as per your requirements. Choose features and behaviour options from the dropdown menus.

Application attributes

Use


Application attributes of change requests, development requests and work requests are configurable in their field status and whether mass maintenance is allowable (note: mass maintenance is only available for change requests and work requests).

Activities

Configure application attributes with regard to their field status and whether mass maintenance is allowable. Choose the application attribute from the drop down box (note that it needs to exist in table /MBSA/S04 first to be available in F4 help). If an attribute has been allowed for mass maintenance it then becomes available for maintenance (by pressing 'Mass maintain' in the toolbar when listing requests through the change request or work request register).

Tracking notification


Use


For change requests and work requests you can request tracking notifications to be sent by the application. A tracking notification is a PDF document sent by mail to keep a selected role player in the software development process informed about progress made. In this activity you can influence the form that is used to output the tracking notification.

Requirements

For Software Asset Management to be able to successfully send tracking notification by mail it is required for SAPconnect to be set up correctly and working. Please check 'send orders' (transaction SOST) in SAPconnect once in a while to see that the e-mails are sent successfully. Note that if a tracking notification cannot be sent a failed transactional RFC (tRFC) will be visible in transaction SM58.

Activities

Capture the smartform to be used to produce the tracking notification. If no configuration is available while still a notification is requested the system will use the default form '/MBSA/REQST_TRACKINGNOTIF' to format the information for send.

Classification

Use


Use classification to provide additional attributes to change requests and work requests. Request classification is maintained in a separate tab on the request form. With the use of a BAdi implementation you can include characteristic values in the request register for reporting purposes.

Activities

Configure characteristics and related characteristic values that you would like to be available for classification. Allocate characteristics to the change request and/ or work request application model.

To include characteristic values in the request register output use an implementation of BAdi /MBSA/CHREQ or /MBSA/WRKREQ, method FIND_REQUESTS. Append fields to DDIC structures /MBSA/S_CHREQ, and /MBSA/S_CHREQ_UI or /MBSA/S_WRKREQ and /MBSA/S_WRKREQ_UI respectively. Using the BAdI populate the additional fields with the related characteristic value. Classification information is stored in table /MBSA/T15.

Example

To keep track whether SDLC spend for a change request is either capital expenditure or operational expenditure configure a characteristic 'Expenditure'. Capture allowable values 'CAPEX' and 'OPEX'. Allocate the characteristic 'Expenditure' to application model 'Change request'.

With these settings you can now classify a change request in respect of the nature of related expenditure as CAPEX (capital expenditure) or OPEX (operational expenditure).

Online help

Use



Online help for Software Asset Management is held in SAP's KW (Knowledge Warehouse) component. In this activity you configure the info object in SAP KW that is to be presented for each help topic in Software Asset Management.

Requirements

SAP KW must be configured and working on the system running the Software Asset Management application or on a remote system. Create/ maintain RFC destination AIO_FOR_HELP_LINKS to point to the SAP KW system. To edit online documentation presented in the online help you may install the 'SAP Knowledge Workbench' as part of SAP GUI installation. Choose enhancement /MBSA/ to author additional content.

Activities

Choose a Software Asset Management help topic and the appropriate link to the SAP KW info object. The F4 help on the info object field will guide you through selecting the info object.

Archiving

Use


Configure whether requests that are flagged (and ready) for archiving should still be included in request listings.

Activities

Choose an archiving status and flag the corresponding checkbox if you would like to exclude requests of this status from request listings. Requests in this status will then only be included in request listings if explicitly requested.

4.6 Technology settings

Systems

Use

In this activity you define systems that will be involved in your Software Development Lifecycle. In addition to listing systems by ID you configure system connectivity. The system connectivity settings set here allow the Software Asset Management application to read deployment unit content and deployment status from the systems in question.

Systems you configure in this activity will be available to define the deployment path under 'Technology' configuration.

Requirements

In order to maintain system connectivity settings you need to already have created an RFC destination (using transaction SM59) or an eSOA port (using transaction SOAMANAGER for consumer proxy ‘ChangeListIn’). You will need this information to make necessary connectivity settings.

Default Settings


To enable Software Asset Management to retrieve deployment unit content and status for ABAP transport requests (deployment tool TMS and CTS+) please capture an RFC destination for each system in the transport route.

To retrieve content for PI change lists (deployment tool CMS) please configure an eSOA port as connection. When configuring the port of your consumer proxy in transaction SOAMANAGER please adopt the naming convention to use the system id of your PI system as the port name.

Activities

Capture systems and connectivity settings.

Technology

Use


Software development involves various skills of solution development. In this activity you capture the 'technologies' used in the process of implementing bespoke software solutions. The term 'technology' is used in a broad sense referring to the skill of solution providers participating in development.

Note that the configuration of technologies must be made in conjunction with the developer team structure present in the organization. The application model in Software Asset Management assumes that a developer team is providing services in exactly one technology. Due to this it is not advisable to have too much granularity in configuring technologies. Several developer teams may offer services of the same technology.

Configure technical object types that get created by the various implementation technologies. Object types captured here will be used to validate content of deployment units for work requests. Only technical object types configured here will be allowed in deployment units of the specified implementation technology.

Configure task types related to the various implementation technologies. Only task types captured here will be presented for activity recording in progress feedback on the developer workplace and the functional consultant workplace.

Activities

Capture technology identifications, e.g. Java, .Net, SAP ABAP and their descriptions. Note that Configuration of systems (as opposed to coding) are also to be considered a technology for implementation of solutions.

Load ABAP object types

Use

Optional configuration setting (required, if you are managing development using SAP ABAP)

Upon completion of a work request the assigned developer is requested to capture deployment unit(s) that were created during implementation. Deployment units contain reference to technical objects (programs, forms etc.) that make up the implemented solution.

For technology 'SAP ABAP' all technical objects contained in deployment units (transport requests) are automatically loaded from their original system. For this automatic update to be successful the


ABAP technical object types need to be preloaded into configuration of Software Asset Management.

Activities

In the program linked to this activity specify the technology configured in Software Asset Management that represents SAP ABAP. When you execute the program the SAP ABAP technical object types will be loaded into configuration.

Example

Technical object types for SAP ABAP are e.g. 'PROG' (Program), 'DTEL' (Data Element).

4.7 Capacity period settings

Capacity period

Use


Software Asset Management performs capacity planning comparing team capacity with work requests (existing and new). Capacity time slots are buckets of time that are filled up with newly initiated work requests on a 'first come first serve' basis into the future. Once a capacity slot is exhausted scheduling will start consuming capacity of the next slot. During capacity planning the system calculates estimated work completion dates for all work requests. The team lead of a developer team can automatically adjust the existing work schedule of his team to take into account changed priorities, reconfigured developer teams, updated effort estimates etc.

Activities

Configure capacity time slots by providing an identification, description and period. Capacity time slots must be captured without overlap and gaps to avoid unexpected scheduling results. The time slot identification is used in lists and workload overview and should be named conclusively (like <month>-<year>).

Time unit of measure

Use


Effort estimates and actual time spent on implementation is recorded in Software Asset Management. At this moment the only time unit allowed is 'Hr' (Hours).

4.8 Business document service settings

BDS document classes

Use


In this step you need to assign document areas of Software Asset Management to document classes in SAP Business Document Service (BDS). This configuration is required so that uploading of


supporting documents for change requests, development requests, work requests, deployment units and technical objects is possible.

Requirements

SAP Business Document Service (BDS) is a standard feature of the SAP Web Application Server. When choosing the BDS connection as per 'Standard setup' below please ensure to choose one that meets your requirements with regard to client dependency, delivery class and document transportability. The following are available BDS connections and their attributes:

BDS_LOC1/BDS_POC1/BDS_REC1/BDS_CONN00 Client dependant=yes, Delivery class='A', Transportable=no BDS_LOC2/BDS_POC2/BDS_REC2/BDS_CONN05 Client dependant=no, Delivery class='E', Transportable=yes BDS_LOC6/BDS_POC6/BDS_REC6/BDS_CONN06 Client dependant=yes, Delivery class='C', Transportable=yes BDS_LOC7/BDS_POC7/BDS_REC7/BDS_CONN04 Client dependant=yes, Delivery class='E', Transportable=yes

Default Settings

Please capture the following entries or activate the related Business Configuration Set:

To allow uploading of supporting documentation for change requests: /MBSA/CHRSPEC, type: object from class library, BDS connection of your choice

To allow uploading of supporting documentation for development requests: /MBSA/DEVSPEC, type: object from class library, BDS connection of your choice

To allow uploading of supporting documentation for work requests: /MBSA/WRKSPEC, type: object from class library, BDS connection of your choice

To allow uploading of supporting documentation for deployment units: /MBSA/DPLOYUN, type: object from class library, BDS connection of your choice

To allow uploading of supporting documentation for technical objects: /MBSA/TECSPEC, type: object from class library, BDS connection of your choice

BDS document class descriptions

Use

Description of the Business Document Service (BDS) classes. This description will be shown in the document register.

Activities

Maintain the description of the BDS classes or activate the related Business Configuration Set. This is a prerequisite for capturing ‘relevant BDS classes’ for Software Asset Management.

Relevant BDS document classes

Use

List of Business Document Service (BDS) classes that are to be used in Software Asset Management

Requirements


The document browser in the Software Asset Management UI will only consider documents whose document classes are maintained in the present configuration table. Ensure that you capture at least the classes specified under 'Standard setup' or activate the related Business Configuration Set.

Default Settings

Ensure that the following are present in your configuration:

/MBSA/CHRSPEC CL Business requirement specification

/MBSA/COMPOS CL Composite development specification

/MBSA/DEVSPEC CL Functional specification

/MBSA/DPLOYUN CL Deployment unit description

/MBSA/TECSPEC CL Technical specification

/MBSA/WRKSPEC CL Test instructions and results

4.9 Application integration

Ticket system

Use


Software Asset Management organizes processes in the Software Development Lifecycle. During the phase of support and maintenance of an installed base the user community initiates changes to the bespoke software solutions that were put in place. Such changes are regularly requested through a helpdesk system. Software Asset Management provides Enterprise Services for seamless adoption of change requests from helpdesk systems and to provide feedback programmatically.

Default Settings

Software Asset Management provides Enterprise Service Definitions for creation and update of change requests. Use a direct connection or a brokered connection from the helpdesk ticket system to integrate with those services. Browse with transaction SOAMANAGER on the server running Software Asset Management to get the corresponding WSDLs.

Software Asset Management is equipped with a configurable change management service. This service will call a configured consumer proxy to connect to the subscribing helpdesk ticket system in order to distribute change request updates.

Activities

Configure the helpdesk ticket system identification and description.

Configure application attributes that, when changed in Software Asset Management, need to trigger an update to the helpdesk.

4.10 Enhancement

Change request business add-in

Use

Optional activity.


Use this Business Add-In to enhance the behaviour of the change request model.

Default Settings

A default implementation for BAdI '/MBSA/CHREQ_BADI' is present in the system. The default implementation will be executed in case you do not create an implementation of your own. If you do, then the default implementation will not be executed any longer.

The default BAdI implementation '/MBSA/CHREQ_BADI_DEFAULT' ensures that for a helpdesk ticket id there will ever only be one change request.

Activities

Execute this customizing activity to create a BAdI implementation.

Development request business add-in

Use

Optional activity.

Use this Business Add-In to enhance the behaviour of the development request model.

Activities


Work request business add-in

Use

Optional activity.

Use this Business Add-In to enhance the behaviour of the work request model.

Activities



5 Administration

For normal operation Software Asset Management requires a number of programs to be executed in

background at regular intervals. The following gives insight into the purpose of those programs.

5.1 Close expired change requests

Purpose

Closure of expired change requests. Transaction code /MBSA/CHREQ_CLOSE.

Prerequisites

Only change requests that are completely implemented, successfully tested and deployed to

Production will be considered for closure.

Features

All implemented and tested change requests whose deployment was on or before the specified

expiry date will be closed.

5.2 Reschedule open work requests

Purpose

Reschedule open work requests of an SDLC team. Transaction code /MBSA/WRKREQ_RESCHED.

Integration

This program reschedules work requests of an SDLC team that are not completed or cancelled (open

work requests).

Prerequisites

Rescheduling of work requests for an SDLC team requires a team capacity that is greater than the

overall time required to complete open work requests for that team. If scheduling reaches the end

of the configured capacity horizon scheduling aborts.

Selection

Depending on program selection either all open work requests are rescheduled or only those work

requests that have been flagged for rescheduling. A work request is automatically flagged for

rescheduling when its scheduling parameters change (priority, implementation sequence, planned

specification delivery date, effort estimate, requested completion date, earliest development start

date). Alternatively a work request can manually be flagged for rescheduling.

5.3 Mass load of parent deployment units

Purpose

Mass load of parent deployment units for deployment units that are layered by definition of their

technology but where the assembly is incomplete (e.g. for SAP ABAP; layer 2 = task, layer 1 =

transport request: reference to task is created while reference to transport request is missing).

Transaction code /MBSA/DPLOY_LOADPRNT.


Integration

In some approach to SDLC team work, different role players are responsible for different layers of

deployment units. While developers are typically required to manage the lowest level of deployment

units, the top layer is typically subjected to approval by a Change Approval Board and generally

managed by functional owners, business analysts or functional consultants.

The present program allows to mass load parent deployment units for a specified deployment unit

layer where such deployment units have not yet been loaded by the responsible SDLC role players.

Selection

Specify a technology (as configured in your installation), original system and/or deployment unit

layer for selection of deployment units. The deployment unit layer is an obligatory selection

parameter.

Output

Parent deployment units for deployment units on the specified layer are created.

Activities

This program should be run in circumstances where the SDLC process that normally leads to

complete assembly of deployment units across all required layers is not adhered to by all role

players.

Example

A SAP ABAP developer has released a workbench task (deployment unit layer 2). The functional

consultant, who is responsible to release the related transport request (deployment unit layer 1)

fails to capture the transport request on SAM (or the ERP API is not activated for automatic creation

on SAM at time of release).

5.4 Evaluate work request implementation progress against schedule

Purpose

Evaluate implementation progress in respect of schedule. Transaction /MBSA/EVAL_SCHEDULE.

Integration

This program compares work request implementation progress at point of program execution with

the planned estimated completion date. Depending on progress, work requests are categorized as

on time, delayed (due to missing functional specification), being on the critical path or overdue.

Output

The result of schedule evaluation will be updated into affected work requests. During work request

rescheduling overdue work requests and work requests on the critical path are considered with

higher priority compared to requests in other statuses.

5.5 Update of SAP CTS+/ TMS deployment units from original system

Purpose


Program to evaluate the progress of deployment units through the system landscape

Integration

This program reads the content and logs of deployment units from connected systems in order to

evaluate the progress of deployment units through the configured system landscape. The

deployment unit content is read from the original system of the deployment unit while the transport

logs are retrieved from its target systems.

Prerequisites

Only deployment units that are using deployment tool 'SAP Change and Transport System' (CTS+) or

'SAP Transport Management System' (TMS) are considered for evaluation of deployment with this

program.

For the program to work correctly, connectivity from the system running Software Asset

Management to connected deployment target systems needs to be configured first. Configuration is

located in the Implementation Guide (IMG) under heading 'Technology settings'. A two or three-tier

landscape including development, (optional: quality assurance) and production can be configured for

each original system. The IMG can be accessed using transaction code /MBSA/IMG.

Output

Deployment unit content (technical objects) and deployment logs from connected deployment

target systems are used to contextualize bespoke software assets that originated from the

implementation of work requests. Once a deployment unit has reached production its deployment

status is changed to 'In Production'. Once all deployment units that are related to a work request

have reached this status then the overall deployment status of the work request is deemed to be

completed.

5.6 Export of time records for SDLC resources

Purpose

Time record export. Transaction /MBSA/TIMEREC_EXPORT.

Integration

The time record export creates IDocs of message type CATS_INSERT either on the local system (if the

Cross Application Timesheet API function ALE_CATIMESHEETMGR_INSERT exists) or remotely on the

system responding to the RFC destination specified in the selection screen. IDocs created with this

program and exported by means of a file port can be imported to a receiver system.

Use program RSEINB00 in the receiving SAP system to post CATS_INSERT IDocs to create time

records in the Cross Application Timesheet application.

Prerequisites

A partner profile for the selected logical system and message type 'CATS_INSERT' needs to exist.

Create such partner profile with type 'Logical System' using transaction 'WE20' and specify an entry

in the 'outbound parameters' table control for message type 'CATS_INSERT'.

Selection

Specify a period of working days and SDLC resources for selection of time records.


Output

IDocs of type CATS_INSERT. Depending on the ALE port you used in the ALE partner profile the IDoc

data will either be written to file or to an RFC destination.

software asset management | functional documentation

Documents