Click here to view the complete list of archived articles

This article was originally published in the Spring 2006 issue of Methods & Tools

---

Using UML Use Cases to Implement Application Lifecycle Management (ALM) Systems

Paul Bowden, MKS Systems, http://www.mks.com

Planning an Implementation

If, when embarking on an enterprise implementation, we try to identify all the use cases that the developers, architects, managers, etc. will execute we’ll have an enormous job on our hands. To avoid so called "analysis paralysis" we need to focus our attention on analysis activities that deliver value. Examining routine check-ins will not be a good use of time. However, a detailed description of how a check-in triggers an automatic integration build will be. This use case is worth considering because

• It is complex in that it involves the interaction of several systems
• It is a part of the implementation that delivers significant business value
• It is important to the success of the implementation

Using these criteria we can identify the key use cases of the implementation. Investigating these use cases will feed into several aspects of the project planning process

• Scoping
• Estimation
• Security
• Documentation
• Training
• Identification of risks

Scope

The diagram below shows a set of use cases grouped into a two phase implementation. As part of the scoping exercise we have identified the use cases that we will implement first and those that will wait until a later stage (the criteria used to make this judgement may be complex. However, the analysis of the use cases will give us the information we need to make an informed choice). Irrespective of any more detailed description of the individual use cases the diagram shows the scope of the project succinctly and clearly.

The development of all use cases to some degree of detail at an early stage is useful as it allows us to verify that the set is consistent and fulfils the requirements of the project as a whole, even if implementation is phased. It also demonstrates the understanding between the team, or vendor, implementing the system and the customer or stakeholders.

Estimation

The two use cases below summarise how we may integrate an enterprise help desk system with our development tracking system. A support representative raises a help request and further analysis reveals this to require a change to software by the development team. When the support representative classifies the request as a Development Problem we want to automatically raise a corresponding Defect in the development tracking system. This is then assigned to a developer and when completed we want to communicate this fact to the help desk. To improve visibility we could feed back more information about the development process to the Support Department, but for the sake of this example we’ll just communicate completion.

Notice here we’ve set the scope; for this phase we’ll only communicate completion. We could add more use cases such as Change Defect State to a later phase.

Elaborating each use case gives us help in estimating the time we’ll need for these tasks.

Later in this paper we’ll look at how we can decompose a use case in more technical detail. The use case rightly doesn’t go into technical detail about how we’re going to achieve the automatic creation of the Defect, but we do have enough information to identify interfaces with other systems and areas for automation.

Security model

Through developing the important use cases we identify the actors involved. The set of actors gives us insight into the groups of user we need to consider when we develop the security permissions for the system.

Each use case identifies the actor(s) that can execute the operations. However, as an adjunct to our model of the key use cases we can map our actors to more fine-grained permissions:

• The ability to edit data in a form or within the repository
• Visibility of data, say specific fields on a form or areas of a repository
• The ability to perform detailed operations not expressed by the key use cases (for example the creation of a baseline by, say, Team Leaders only).

Page 1    Page 3   Back to the archive list