Category Archives: Documentation

The Waterfall Dentist Anti-Pattern

Posted on by
Reply

Believe it or not, but I have a confession to make. I’m currently in a pure waterfall project. It’s my first in many, many years and despite the fact that I love the technology, I don’t like our way or working it a bit.

During the first phase of this project we are trying to deliver twenty functional work items. All of these twenty work items are analyzed first, then reviewed. After all review comments have been processed, all work items are designed. And again reviewed. After all review comments have been processed again, the developers start constructing them. And once they finish the testers have a go at the software produced.

Yes, I know this is efficient nor effective. And yes, the testers find lots of defects that could have easily been prevented using an iterative approach where we jointly work on a single work item, and only after it’s finished move on to the next. But we just don’t. And the delivery date is nearing. As a result, at the delivery date we will likely deliver twenty half-baked work items, instead of delivering maybe ten or twelve complete work items. It’s a choice.

End of discussion

You could say that the discussions about the chosen approach I have with the project manager are vivid. At the very least. “No, we’re not going to do agile,” he clearly states. “I don’t care if we call it agile or not,” I respond, “But the way we are working now is simply inefficient.” Personally I really don’t care if projects are tagged as agile, Scrum, Smart, RUP or even waterfall. I just dislike inefficient processes. “This approach is easy to explain to the client,” the project manager continues, “So we are going to stick to it. End of discussion.”

And then coming out of my girlfriends’ apartment building this morning I saw this car in the parking lot. It occurred to me immediately. We are waterfall dentists.

2012-08-18 12.42.59

Imaging you’re a young dentist, fresh out of dentistry school, and you are starting a new practice. Why on earth you would name it The Waterfall I don’t know, but twenty new patients are hurdling up to be treated. Being The waterfall dentist you use an appropriate approach. During the first week you examine all twenty patients. During the second week you commence to the first part of their treatment: drilling holes. Then in the third week, all twenty patients come back and have the holes filled. In the fourth week all patients return again for a last check-up. Just testing if all holes are filled properly. Finally, in the fifth week you get to send twenty bills to twenty happy patients. Project done. Next project.

Good bookkeeping and new patients

Doesn’t that sound good? This approach resembles my current project in great detail. So why is it, although this model is easy to explain to patients, no dentist in the world would even slightly consider to apply it? Well, first of all, your patients don’t like to walk around with unfilled holes in their mouths for a least a week. Second, your patients will have to come in to your office four times, and you will have to do pretty good bookkeeping to remember each patients details when they return. If you would have filled a patients tooth right after you’ve drilled a hole, this need for documentation and good memory wouldn’t have been necessary. Moreover, what if a new patient comes in during the second or third week with a terrible toothache? You would have to decline him saying: “Sorry, I don’t take additional work now,” advising the new patient to come back after all current patients are serviced. It’s the vicious change request. And what if you become ill during? Your whole schedule will certainly slide. As a result, none of the patients will have been fully serviced at the end of the scheduled period, leaving them in uncertainty about when you will deliver. Basically, you will loose your patients as fast as they hurdled up. And you won’t be able to send any bills.

I could probably spent another two posts in explaining why the waterfall model isn’t applied by dentist anywhere in the world. But I won’t.

We just might

Dear project managers, despite the fact that the waterfall model is so easy to explain to clients, that doesn’t make it any more effective or efficient. Armed with The Waterfall Dentist Anti-Pattern, you can explain iterative, or agile, approaches to your clients just as easy. In fact you can even service your clients better, as they may send in new urgent patients during the project, and you will be able to service those patients early. And even though you may turn ill during the project, servicing the patients one by one, rather than in a returning batch, you can actually fully service a large number of them within the designated timebox, instead of having serviced all of them half when the deadline approaches. I would much rather be able to send bills to fifteen out of twenty patients, then not being able to bill at all.

So where’s my current project standing? Well, just like The waterfall dentist might actually serve twenty patients during the current phase, we might actually deliver all twenty work items. But I wouldn’t bet my gold teeth on it.

Het institutionaliseren van agile

Posted on by
3

Er is een anti-patroon op het gebied van agile dat me nauw aan het hart gaat. En dat is de institutionalisering van agile.

In de afgelopen vijftien jaar heb ik met veel plezier en inzet organisaties en projecten gecoacht op weg om agile worden. In die vijftien jaar heb ik ongelooflijk veel geleerd, over software ontwikkeling, over programmeren, over processen, over het doen van projecten maar misschien vooral over de mensen in die projecten, en hoe deze mensen samenwerken. En het moet gezegd worden, ieder mens is uniek, iedere samenwerking is uniek, en vooral daardoor, los van alle technieken en technologie, is ieder project anders.

Handboeken agile

Nu zijn we op een punt in de tijd beland dat agile populairder is dan ooit, en waarschijnlijk zelfs populairder is dan het ooit in de toekomst nog gaat worden. We zijn op het punt dat alle grote organisaties hun software ontwikkeling gaan veragiliseren. Dit is het punt in de tijd waarop meer en meer projecten agile worden uitgevoerd. En dit is daarom ook het punt in de tijd dat grote organisaties gaan vastleggen hoe agile projecten dienen te worden uitgevoerd.


Handboek agile in zes delen

Er zullen steeds dikkere en gedetailleerde handboeken verschijnen met voorschriften over hoe lang een stand-up meeting mag zijn, welke vragen daarin moeten worden behandeld, hoe groot een team mag zijn, met welke ontwikkelomgevingen de ontwikkelaars moeten werken, welke testtechnieken mogen worden gebruikt, templates voor het vastleggen van user stories, smart use cases, evaluaties, en wellicht zullen er organisaties zijn die zo ver gaan dat ze gaan voorschrijven dat user stories op langwerpige gele post-its op het taskboard dienen te hangen en individuele taken op vierkante groene.

De geest terug in de fles

Als ik één tip mag geven? Zodra deze verschijnselen zich voordoen in een organisaties is agile ten dode opgeschreven. Agile projecten varen wel bij de juiste hoeveelheid vrijheidsgraden, mensen en samenwerking varen wel bij de juiste hoeveelheid vrijheid. Software ontwikkeling is een creatief proces, en agile werkwijzen zijn geëent op het zichzelf voortdurend verbeteren. Zodra organisaties agile gaan institutionaliseren, wordt de creativiteit langzaam maar heel zeker uit de projecten getrokken. Het zelflerend vermogen van agile projecten aan banden gelegd. De geest is weer terug in de fles, en de stop kan erop.

Death by Dogma versus Agile Assembly

Posted on by
4

On November 3, 2011 I presented the keynote of the Agile Open Holland Conference in Dieren. During this challenging talk I discussed the current state of affairs in agile organizations and projects and the effects of the recent strong rise in popularity of agile approaches. Let’s put it mildly: there’s a lot of work to be done.

Death by dogma

Almost all organizations, large and small, are turning towards agile to escape failing traditional software development projects. Due to this strong increase in popularity of agile approaches and techniques, many newcomers will enter the field of agile coaching. Of course without the very necessary real-life experience but proudly waving their Certified Professional Scrum Master Sensei Trainer Certificate proving they at least had two days of training.


Going through the hardship of two whole intense days of training becoming a Certified Agile Jedi Knight is worthwhile!

In my opinion, as a result many organizations and projects in the next couple of years will be coached why well-willing consultants who have barely made it through boot camp, and in the famous Shu-Ha-Ri learning model haven’t yet made it beyond copying their teacher. This will lead to very dogmatic applications of the more popular agile approaches, mostly Scrum, especially when the so-called leaders in the field themselves turn to dogma. This dogmatic thinking will block the use of more mature techniques and technology in agile projects, even when these would really improve projects, or would prevent agile projects from failing. “No, you can not do modeling in Scrum” and “Burn-down charts are mandatory” are two such simple real-life example statements that I’ve witnessed some certified agile Jedi Knight make. Due to this lack of experience and the growing dogmatism in the agile beliefs, more and more agile projects will fail. Death by dogma.

During my keynote I discussed many examples of dogmatic Scrum implementations and the drawbacks from being dogmagile, building the story up from my previous posts Scrumdamentalists and Crusaders and Flower-Power Agile Fluffiness.

But maybe even more important during the keynote I also show that there is no such thing as one-size-fits-all agile. Different organizations and different projects require different agile approaches. Sometimes lightweight agile, for instance implemented using Scrum, user stories, simple planning, simple estimation, and one co-located team using post-its on a wall is just fine. But in many projects the way of working used should rather be built up from slightly more enterprise ready approaches, for example using Smart, smart use cases, standardized estimation, multiple distributed teams and on-line dashboards.

What is agile anyway?

Implementing agile in your projects starts with establishing what it means to be in an agile project. As I demonstrate in the keynote, I consider short iterations, collaborative teams, a small unit of work, continuous planning, delivering early and often, and simplifying communication to be crucial to considering a project working in an agile way.

From there you can pick and choose from a wide variety of approaches, techniques and technology. Most of them stemming from the agile era, but some of them can also be related to older (or more mature) era’s. Concluding you might say that to be successful in implementing agile in your organization, you will need to assemble your agile approach from everything that will help you implement these six agile bare necessities. Anyway, enjoy!

Death by Dogma versus Agile Assembly

Describing (smart) use cases using Enterprise Architect 8. Part II – Use case scenarios and structured specifications

Posted on by
4

Enterprise Architect by Sparx Systems is a commonly used modeling tool, targeted at modeling UML and BPMN diagrams. One of the most frequently used diagrams is the use case diagram. A use case diagram consists mainly of actors and use cases, either traditional or smart use cases.

Use case scenarios

There’s different ways of modeling and describing what action a use case is comprised of. In general we consider use case scenarios. Each scenario describes a way the use case can be executed. There’s three types of scenarios:

  • Happy day scenario. Executing this scenario leads to the desired result, being the goal that the actor wants to achieve, via the optimal path.
  • Fail scenario. Running this scenario results in not reaching the desired result, but to an alternate result where the actor does not achieve his goal.
  • Recovery scenario. During this scenario some anomaly is encountered that leads of the optimal path, but using some additional action, in the end the positive result is reached, and the actor’s goal is achieved.

Each scenario consists of a number of consecutive steps. As you might expect every result that can be reached is in fact a post-condition of the use case. In my opinion thus use cases can (and will most often) multiple post-conditions.

Scenarios are very useful when it comes to testing the functionality of a use case, as testers are used to describe test cases that match one of the scenarios.

Use case scenarios, basic flows and alternative flows

In Enterprise Architect and most other modeling tools scenarios are not literally described as such, but rather use a different terminology, based on flows. Here a basic flow represents the happy day scenario. Next to the basic flow modeling tools represent alternative flows. Unfortunately these do not always map to either fail or recovery scenarios.

An alternative flow is described as a replacement of one or more of the steps of another flow – either the basic flow or another alternative flow. This differs from scenarios. An alternative flow does not describe a particular scenario, but only a part of it.

Combing the basic flow with one or more alternative flows again leads to a scenario – always a fail or recovery scenario – if it ends at one of the post-conditions of the use case. To facilitate the use of basic and alternative flows, the steps they (similar to scenarios) describe are usually numbered.

Alternative flows and exception flows

Enterprise Architect distinguishes alternative flows and exception flows. Although the concept and differences are not explained, in general an exception flow is modeled when something goes wrong during the execution of a use case, for instance if some validation fails. An alternative flow is modeled when execution is correct, but takes a slightly different path than the basic flow. For instance, the user presses a button that executes some additional action.

In general when the execution of an alternative or execution flow is finished, the flow returns to the calling flow. In theory this can be any other flow. However, Enterprise Architect (using structured specifications) only allow for a single level of alternate and exception flows – which is good because it disallows complex scenario’s. After a flow is finished, the flow can return to the calling flow, but it might also end the use case, resulting in reaching one of the post-conditions.

Structured specifications

Use cases are usually specified in Word or other text editors, because there’s few tools that allow for a more structured way of defining numbered flows. Although writing plain text allows for maximum flexibility trouble arises as soon as the numbering of the steps needs to change, due to newly inserted steps or steps that are deleted. Here, references to these steps from other flows need to be updated too.

From version 8.0 Enterprise Architect offers the possibility of writing flows in a more structured approach using the structured specifications tab in the use case properties window.

SNAGHTML13ddde6_thumb[1]

Although not perfect, this structured specification offers a number of other interesting additional features:

  • Generate activity diagram. The tool can generate an activity diagram that displays all scenarios for the use case, based on the structured specifications, quite similar to how it is described in my UML book.
  • Generate test documentation. Using a document template, the tool allows for quite extensive generation of the test scenarios for the use case.

So structured specifications is an interesting alternative for writing use case scenarios. Some tips.

Tip. First write basic flow

Start with describing the steps for the basic flow. Do not add any of the alternate of exception flows yet. A basic flow contains all steps that are required to reach the goal for the use case, or the success post-condition.

A flow does not include if-then constructs (these will be alternate or exception flows). However loop constructs can appear.

Tip. Actor or System

Start each step with the actor executing the step. If there’s only one actor, I’d prefer the term Actor – to avoid issues when the name of an actor changes in the model. Steps that are executed by the system always start with the term System.

image

Note that Enterprise Architect specifies an icon in front of the steps indicating actor or system. This icon can be flipped from the context menu (although it should recognize it when you type Actor or System).

Tip. Note called use cases

When modeling smart use cases, in some steps of your flow other use cases might get called. Describe calling the other use case as a single step, executed by the system.

image 

As shown in step 6 we use the syntax System starts [Use case name], and sometimes add the parameters we pass to the called use case. In the Uses column of the structured specification, we note the name of the use case, as this column immediately shows when looking at the specification.

Note that unfortunately that if names of use cases are changed in the model, the references to use cases in the structured specifications do not change. This would however make a very interesting new feature.

Tip. Check post-conditions of called use cases

Right after a use case is called, such as Select Contact in step 6 in the example above, you should check for the post-conditions of this use case. In most cases, the positive post-condition for the called use case is the desired result. Note this post-condition in the next step.

In the example above step 7 mentions Other Contact is selected. This literally is one of the post-conditions of use case Select Contact. Although this step is not necessarily an action, such as regular steps are, it is of vital importance that post-conditions are checked. Moreover, adding the positive post-conditions as a step in the (basic) flow, allows for validating the other post-conditions of the called use case in alternate of even exceptions flows that, in this case, branch off of step 7.

image

Here the alternate flow Other Contact not selected describes what happens in that particular case. After finishing, it re-joins the basic flow in step 3. Don’t forget to add these alternate flows.

Tip. Synchronize user actions

Many use cases have a strong component of interaction with the user. In this case the user can often start many actions independent of their order. Think of starting another use case by pressing a button, starting some action by pressing a button, filling in fields on a form, submitting it, or pressing the cancel button.

The trouble with these user actions is that in general they don’t follow a specific order. This makes describing user actions in a sequence of consecutive steps a bit awkward.

I therefore recommend the following. First, create a step in the basic flow that is simply titled User action. This step is used to allows loops and trigger actual user actions in random order. All paths no return to this specific step.

image

In this example, step 3 represents this step, and is title Actor action.

Next, add the user actions that are essential for reaching the positive post-condition in the basic flow. In this example, step 5 to 7 represent such an essential user action.

And third, add all other user actions as either alternative or exception flows. All of these branch of the step right after the Actor action step. In case these flows return to the basic flow, they always return to step 3.

Tip. Put post-conditions in results

The post-conditions of a use cases can be reached in several locations. Of course, the positive post-condition is reached at the end of the basic flow, but alternative and certainly exception flows can also result in ending the use case, in which one of the post-conditions is met.

It is a good habit to note these post-conditions as results in Enterprise Architects structured specification, as shown in the alternative flow Actor clicks Cancel below.

image

We usually precede the actual post-condition (No Relationship is saved) by either OK or Cancel, to show whether or not a positive result is achieved.

Tip. Skip details in fields in forms

When the user needs to fill in a number fields on a form, it is very tempting to add details on these fields to the structured specifications, such as:

  • Label. Name of the label associated with the field.
  • Mandatory. Can the field be left empty.
  • Display format. Is the field displayed as a text box, a radio button list, a drop down list, a checkbox, a link?
  • Edit format. Does the field have a specific edit format, such as with currencies or bank accounts.
  • Validations. All kinds of field validation, such as amounts not allowed below zero, or dates not before today.

However, adding these details to the structured specifications clutters the flows. It is better to add these field details in another location, either in a user interface diagram, or  to an additional document added to the use case. Enterprise Architect uses a linked document for this means. We use a formatted template to create these linked documents.

For the flows then it is sufficient to simply add a single step that defines that the user enters the fields in the form, as in step 9 in the example below.

image

Tip. Skip details on validation

A similar approach can be used to describe validation. As said earlier validation can be part of the use case, or can be part of elements of your domain – your domain objects, value objects, enumerations, repositories, services. In the latter case, validation is already modeled and described there. There is no need to repeat these validation in your basic and alternative flows. Validation this is specific to this use case should be specified with the use case, again not in the flows, but in the conditions.

Thus, in the flows of your use case it suffices to describe that validation takes place. But, due to the fact that validation can have different outcomes, add an additional step that handles the validation results. Always not the positive result directly below the validation step, such as in step 12 below..

image

Model any other outcome either as an alternative or exception flow that branches off of the positive outcome, in this case that branch off of step 12, such in alternative flow 12a below.

image 

Tip. Check results for save and remove actions

Although with the current state of technology it appears that implementing save or remove actions on a domain object is trivial, in fact both action can end in an undesirable result. For instance, a remove from the database might fail due to the fact other records depend on the record you are deleting. A save might fail due to concurrency, or due to rules in the database failing.

So again, similar to checking the result of validations, it is good practice to also monitor the result of a save or remove actions with an additional step.

Describing (smart) use cases using Enterprise Architect 8. Part I – Templates and validations

Posted on by
2

Enterprise Architect by Sparx Systems is a commonly used modeling tool, targeted at modeling UML and BPMN diagrams. One of the most frequently used diagrams is the use case diagram. A use case diagram consists mainly of actors and use cases, either traditional or smart use cases.

A use case template

The specification of the individual use cases in the model follows a template, that at least should contain:

  • Name. Every use case should have a clear descriptive name, that will in most use cases suffice to make clear what this use cases is all about. Please name use cases in active sense, most often a combination of an active verb and a noun.
  • Goal. What is it the use case should do? Can also be used for a brief description of the use case, often a first draft of the use case.
  • Pre-conditions. The set of conditions that must be met before the use case can be executed.
  • Post-conditions. The set of conditions that must be met by the use case on completion. In my opinion these can be both positive and negative condition.
  • Basic flow. A sequence of steps that describes the interaction between the actors and the system that leads to the desired result. The actors can be both the executing actor (often a person or role) as assisting actors (in many cases other systems, or services).
  • Alternative flows. Deviations from the basic path may lead to one or more alternative flows. Each alternative flow again describes a sequence of steps that starts at a certain step in either the basic flow or another alternative flow, and returns to possibly the same step, or to another step (in the same scenario), or even possibly ends the use case.

Constraints

In addition, we often model other types of constrains (next to pre- and post-conditions) with a use case:

  • Input. Parameters that are passed into the use case when the use case is started. Note: these are not preconditions.
  • Validation. With certain steps validation can occur. In most cases validation concerns the domain objects or view models that are handles by the use case. These should be modeled with the object it concerns. However, sometimes additional validation is typical for the use case at hand. These validations are modeled as constraints on the use case.

Describing use cases in Enterprise Architect

In Enterprise Architect every use case comes with a property window, which is opened for instance on double-clicking a use case in the diagram. Unfortunately this property windows is implemented as a modal window, which means it is not possible to navigate away from the window without pressing OK or Cancel. Thus it is hard to check on other diagrams or elements in the model while specifying a use case.

On the main page of the property window the use case is named. We usually use the Notes property to specify the goal of the use case. Keep this description short, as it is not intended to capture one or more of the flows in the use case. In the example below, the Notes property is clearly far too long.

SNAGHTML1736b47

Describing constraints in Enterprise Architect

We consider an number of types of constraints with a use case, as described above. Enterprise Architect allows to define your own constraint types, next to the pre-defined types, so we’ve added Input and Validation.

SNAGHTML17a43ab

The constraints for a specific use case can again be described in Enterprise Architect in the property window. We usually specify both a name and a description for each of these constraints.

SNAGHTML17dc346

In the example here, the use case has defined a pre-condition, a post-condition, requires both a valid Contact and a Relationship to be passed in (constraint type Input), and describes a number of validations (constraint type Validation).

Please note that the name for validation constraints should be clear and descriptive, as they will also appear in code, on the implemented use case, resulting in a method of the use case class, as suggested in the C# code example below.

   1: [BusinessRule]
   2: public ValidationResult OtherContactIsNotEmpty()
   3: {
   4:     return !Relationship.To.IsEmpty 
   5:         ? ValidationResult.CreateError(this.Prop(t => t.Relationship.To), "Other contact in relationship may not be empty")
   6:         : ValidationResult.Success;
   7: }

Different types of validations

When describing validations, it is vital to understand which validations are handled by the use case, and which validation are handled by the domain object or view model that is handled by the use case.

Validations on domain objects

During the execution of a particular use case the state of a domain object (or view model) might be altered, for instance due to user input, but also due to specific steps in the use case. When this happens, the domain object can be considered as dirty. This is a state where it is uncertain whether the domain object is actually valid, or that is has become invalid. Validations may now be performed on the domain object, for instance before persisting it.

Such validations may include required fields, validations properties that are value typed (think of email, zip codes, social service numbers), but can also be business rules (start date for a contract must be before the end date of a a contract). These validations are always true when the domain object is in valid state.

Modeling validations on domain objects

Such validations are best modeled and describe with the specific domain object.

image

In the example above the domain object Relationship (which is stereotyped here as business class) we have modeled different types of validations:

  • Required. The properties Description, StartDate and EndDate are not mandatory for the domain object to be valid. The multiplicity of these properties is set to [0..1] – which implies that zero or one instances of this property are present.
  • Value object. Although not visible in the example, properties may have types that are defined as value objects, such as Email or Isbn. This means that the validations rules for this particular value object will apply to this property.
  • Enumeration. In the class RelationshipType, the property To is modeled as ContactType, which is an enumeration of possible values. This enumeration is modeled elsewhere in the domain model.
  • Association. The class Relationship described three associations with other classes. The properties From and To are modeled as associations with Contact, and given the multiplicity are mandatory for an instance of Relationship to be valid.
  • Rule. Additional, we have modeled  some business rules as methods on the domain object Relationship, such as ToContactMustMatchRelationshipType(). We have use the stereotype business rule to make sure developers will implement these accordingly, such as in the code example below. 
   1: [BusinessRule]
   2: public ValidationResult ToContactMustMatchRelationshipType()
   3: {
   4:     return !To.IsEmpty && RelationshipType.To != To.ContactType
   5:         ? ValidationResult.CreateError(this.Prop(r => r.To), "Contact type '{1}' for {0} does not match required contact type '{2}'.", To, To.ContactType, RelationshipType.To) 
   6:         : ValidationResult.Success;
   7: }

Validations on use cases

With some use cases validations may occur during the execution of the use case steps. Such validations will validate the correct behavior of the use case, and are not specific to the domain objects that are handled by the use case.

A good example would be a use case Change Password, where the user has to enter his old password for his Account, and twice a new password. Typically, Password is a property of the domain object Account. But entering a new password twice is only temporary and checking whether the first entered new password matches the second entered new password does not validate the state of the attached Account object.

Therefore both new passwords are not modeled and implemented as properties on Account, but rather it’s the use case’s responsibility to validate equality on the new passwords. It’s only after these appear to match, and the the entered old password matches the Password property of the Account object, that this property gets sets, the Account object is validated and saved.

Modeling validations on use cases

Such validations can be modeled in Enterprise Architect in the property window of the use case.

SNAGHTMLa5bcfb

Use the (custom) constraint type Validation. Give the validation a name that will match the name of the method on the use case in code to guarantee traceability. Also write a undisputable description for the validation.

Part II of this post will deal with writing use case scenarios, basic flows, alternative and exception flows using structured specifications in Enterprise Architect.

A recipe for enterprise agile. Mixing Scrum and Smart

Posted on by
2

To cut to the chase, those of you who have worked on enterprise or service oriented projects before already know this. These types of projects are characterized by a large number of organizational, functional and technically complicating factors. Enterprise software development projects are surrounded by a large number of complicating characteristics and challenges:

  • Many different stakeholders. Projects have many different parties in the organization that are involved. Often such project realize goals for different departments or divisions in the organization. As an example I once coached a project that served 22 different departments. Quite often these departments or division try to achieve overlapping or even contradicting goals.

IMAG0218[4]

  • Business processes. In general enterprise projects (re-)implement (parts of) business processes that are key to the organizations success, rather than building a straightforward web application.
  • Complex software architectures. Most likely, enterprise projects implement business processes in a complex IT landscape or architectures. Think of landscapes that host many different applications all tied together.

IMAGE_634[8]

  • Many external dependencies. Often, such complex IT landscapes contain components that are outside of the organization. Services that run outside the corporate firewall, with other parties. A well known issue to agile projects is that of availability. We need the new version of the service in this iteration, but the other party runs a waterfall project that will not deliver this year.
  • Changing requirements. In enterprise projects, requirements change continuously. Either by changing insights during the project, but more often due to changing legislation or regulations.
  • Many different types of deliverables. Traditionally these projects count many different types of deliverables. Think of service description, user interface, process models, non-functional requirements, workflow, project plans, test plans and many, many others.
  • Multiple roles. Large organizations count many different roles that are involved in projects. There are business analysts, enterprise architects, information analysts, testers, release managers, SAP developers, web developers, SAP functional consultants,

Thus these project often become a mission impossible, and fail in large numbers. Such projects are difficult to estimate, therefore hard to plan. For developers it’s tough to build the software, often with many new techniques and technologies, and even worse for testers, these projects are sheer Impossible to test well. This is where a structured agile approach should come to the rescue.

Being agile in enterprise projects

Independent of the approach that is applied, or the agile process that is followed, being successful in agile projects follows a number of key principles:

  • Multi-disciplinary teams. Instead of different roles such as analysts, designers, developer and testers working in consecutive stages in a project, all roles collaborate in implementation individual work items from heads to tales.
  • Short iterations. Project work in short time boxes, in most cases 2, 3 or 4 weeks. During such an iteration, a number of work items is planned, completed and evaluated – with different terminology in use with different agile processes.
  • A small standardized unit of work. Projects requires a small unit of work, to be able to deliver a number of them in a single iteration. Large work items such as traditional use cases therefore do not apply well.
  • Testing from day one. Testing is an important discipline during agile projects. Testers are involved from the very first iteration, when the first work items are realized. Note that testing in most projects goes way beyond the obvious unit testing – which is actually a developer technique.
  • Continuous measurement. Successful agile projects continuously measure their progress. Since they are always delivering individual work items, measurement in agile projects is easy.
  • Continuous (process) improvement. At the end of each iteration not only the realized work items are evaluated, but also the project approach itself is evaluated, leading to highly effective project approaches.

Scrum in a nutshell

When organizations first start with agile projects, Scrum is often the process of choice. At this point in time, Scrum is by far the most popular and best known agile approach. Scrum is a straightforward lightweight agile process that offers a collection of highly applicable principles and techniques for short iterative projects and is easy to understand. It also specifies a remarkable terminology with scrums, sprints and user stories.

image[3]

In a nutshell, Scrum is characterized as follows:

  • Sprints. Projects are divided into iterations, called sprints. In general these are 2 to 4 weeks.
  • Backlogs. Work items still to be done during a project reside in a so called project backlog. At the start of each sprint items from the backlog are placed in the sprint backlog. These are the worked items to be realized.
  • Sprint cycle. All iterations follow the same simple process, with an iteration kick-off, actual work and a retrospective workshop for evaluation.
  • User stories. The main unit of work is usually the user story, although this is not mandatory. This rather informal requirements technique is shared with the agile process extreme programming.
  • Planning. In general the project and sprint planning is visualized in task boards, which usually is put up on a wall using post-its. Progress is monitored by using burn down charts, a straightforward diagram that on a daily basis displays the number of points still to realize. A trend line in the burn down chart extrapolated from the points identifies the likely project end date. Again this technique is shared with a number of other agile processes, including Smart and extreme programming.
  • Delivery. Every iteration or sprint results in fully delivered products, software or otherwise.

Scrum has proven to be a successful approach in many (smaller scale) web projects. In larger, more complex, service or cloud oriented and enterprise projects, I think Scrum needs to be augmented to fit the project and its environment. Let me explain.

Beyond lightweight agile

When applying Scrum or other lightweight agile processes such as Crystal Clear or the set of lean principles (applied to software development that is) to more complex projects of all sorts, you might recognize a number of shortcomings:

  • Business goals. It is often unclear how the work items in such projects (in most cases user stories) link back to business goals, stakeholders and business processes to implement.
  • Analysis and design. Although many people in the so-called agile community will now think I’m promoting a waterfall approach, in most agile approaches there are hardly any analysis or design activities or deliverables defined.

    For instance, it is undefined how the backlog in a Scrum project is assembled. Let me assure you, in more complex projects some analysis and design is required, albeit not in big-upfront-design mode.

  • Architecture. The same argument goes for software architecture. Most agile approaches lack decent software architectural activities and deliverables. Architecture is often assumed as-is. If you’re implementing business processes that run through a systems landscape of over 40 collaborating systems, you will definitively need to design your architectures, but again this need not be in big-upfront-architecture mode.
  • Roles. Scrum and extreme programming describe a very limited set of roles that, although looking slick,  in most projects does not adhere to the standing organization. There’s often enterprise architects, information analysts, business analysts, middleware developers, application management, testers, release manager. How will a project work with all those roles? There’s a bit more to it than just saying they are allowed to participate in the daily scrum.
  • Testing. Apart from the obvious (developer) techniques such as unit testing, the role of testing more specifically – which is essential in larger agile projects – is not very well described in lightweight agile approaches.
  • User stories. Although very flexible, user stories are a highly unstructured unit of work, despite efforts in epics or story maps. Applying such an unstructured unit of work may result in low re-use, non-repeatable estimation, difficult to standardize development, testing and measurement beyond the individual projects. In a multi-project environment user stories will block progress and reuse (of for instance metrics and code).
  • Delivery cycle. Scrum does not specify the organization of delivery of the products to different environments such as test, acceptance and (pre)production (so called OTAP).

When executing large, more complex, service oriented or enterprise projects, I therefore strongly recommends to overcome these limitations by augmenting Scrum and the likes with additional techniques.

Smart accelerators

In my personal experience in enterprise projects I have had very good experiences with mixing the agile process Scrum with the best practices from another agile processes called Smart to overcome the drawbacks of the aforementioned approach.

Smart originated from the Netherlands in 1998 and was originally designed to implement best practices for DSDM, an iterative approach that was popular in those days. Later Smart grew out to a stand-alone agile approach that particularly combines well with other more basis agile approaches such as Scrum and extreme programming, but also aligns well with PRINCE2.

 image[7]

More specifically Smart puts accents on aspects in project that are only marginally highlighted in other agile approaches. As an example Smart adds the following accelerators to projects:

  • Preliminary iterations. Preliminary iteration types Propose and Scope is where work items are added to the backlog such as a modeling business processes, modeling smart use cases, creating an estimate, creating a cost-benefit analysis, writing a project plan (not that obvious it seems), first-cut software architecture set-up, development environment set-up, project kick-off, team education and first-cut user interface guidelines.
  • Smart use cases. Next to the more “non-functional” work items mentioned above, Smart introduces the well-known smart use cases requirements technique. Smart use cases not only model the needs of the user, but also identify workflow and reusable back-end services.

    This technique allows for identifying re-use, repeatable and reliable estimation, and very good traceability between requirements, architecture and code, great functional testing capabilities. An absolute must in enterprise projects.

ManageSite[2]

  • Estimates. Estimation of size and complexity of a project is estimated and measured in smart use case points, defined on a scale from 1 to 10. Smart use case points of course come from estimating the size or complexity of smart use cases, and is a highly pragmatic and repeatable technique..
  • Work item life cycle. Where Scrum’s work item life cycle contains to-do, working and done, in Smart, work items are delivered through a slightly more structured life cycle, that allows for all roles in enterprise projects to be maximally involved in a collaborative manner.

    Due to the life cycle, work items need not be broken down in tasks, a cumbersome and highly unstructured elements of Scum. In Smart work items simply move through the stages of the life cycle (in most cases in one or two days), the progress of which can be shown easily on a dashboard.

  • Designing. During the daily stand-up meeting, it is decided whether or not a design session is required. This time-boxed design session addresses the design or a single smart use case. Most project will organize this design session directly after the daily stand-up. On a typical time scale, if the stand-up runs from 10:00 to 10:15, the design session runs from 10:15-11:00.

    During such sessions all roles that need to deliver input to this particular use case participate. Of course also the developer and tester are present, so all roles create a homogeneous view of the smart use case at hand.

IMG_0247[4]

  • Smart testing. Working with user stories will normally not result in a very efficient test approach, as user stories do not add structure to the project. Smart describes a standardized approach on functional testing in agile projects of course based on smart use cases.
  • Stabilizing iteration. Usually the last iteration of a Smart project or the last one to an upcoming release is used to round off remaining work items, build issues, bugs, and remaining features. This iteration is merely used to stabilize the solution. In Smart this iteration type if referred to as Finalize.

Blending Scrum and Smart

Besides defining an obvious project life cycle, these best practices from Smart blend in really well with the more lightweight approach of Scrum and extreme programming. This leads to the following best practices:

  • Initial backlog. The initial backlog of the project is filled with the work items Smart recommends, rather than assuming a user story filled backlog. When prioritizing work items for the first sprint in a mixed Scrum and Smart project, it is very likely that these are picked.

    As a result, after one or two iterations, a project plan for the remainder of the project is produced, containing at least an estimate, based on the smart use cases that are also defined during these iterations (of course without any analysis or design, just the diagrams, the ovals and the actors).

  • Iteration kick-off. After the initial work-items are cleared from the backlog, the smart use cases become the primary work item type in the project. During sprint kick-off a number of smart use cases is picked to implement in the next sprint.
  • Dashboard. The traditional Scrum task board is replaced by Smart’s agile dashboard, containing columns for the stages in the work item life cycle – In Iteration, Designing, Working, Testing, Rework, Accepted. If appropriate additional columns can be added, e.g. when testing is split up in Developer Testing and Customer Testing.

IMAGE_041[7]

  • Points. The progress in the project is not measured in story points, but rather in smart use case points.
  • Scrum meeting. The focus of the daily scrum meeting shifts a bit as it is also used to answer the question: what still needs to be done on the smart use case(s) we’re currently working on to get them accepted?
  • Design. Host the design sessions as Smart recommends, preferably right after the daily scrum meeting. 
  • Testing. As the work item life cycle clearly stipulates, functional testing, often done manual is all in a days work. The role of the testers here becomes imminent in the project.
  • Finalize. Projects have to decide when to apply a Finalize iteration to stabilize the solution and round up loose ends. Depending on the type of project, these iteration can be the very last sprint, but also can be very well aligned with the organizations release calendar.

This approach of mixing best practices, techniques and tools from Scrum, Smart over the past 12 years has proven to be very successful in a variety of projects and project types, including larger Java and .NET projects. service oriented projects, business intelligence projects, and even packaged implementations.

Moreover, when augmented with more technical best practices from extreme programming, such as refactoring, continuous integration, pair programming, and test driven development (smart use cases are a very good unit for unit testing code) projects are aligned to deliver on-time, on-budget, and with just-enough documentation and fitting (reusable) features. As former US president Bush used to say: failure is not an option.

De uiterste houdbaarheidsdatum van requirements

Posted on by
Reply

Vorige week gaf ik – voor de zoveelste keer – training in het identificeren en modelleren van smart use cases. Dit keer bevond ik me in de hippe ruimtes van Meeting Plaza Utrecht, boven het altijd sfeervolle Hoog Catharijne. Tijdens de goed verzorgde lunch werd het onderwerp al snel bepaald door de uiterste houdbaarheidsdatum. Van levensmiddelen, maar meer nog, van requirements.

Stickeren

In de horeca is het al jaren een goed gebruik, het stickeren van levensmiddelen, zo weet ik van televisieprogramma’s als Keuringsdienst Van Waren.. Een eenvoudige sticker vertelt wanneer het product is opengemaakt, en tot wanneer het houdbaar is. Is deze uiterste houdbaarheidsdatum verstreken, dan wordt het product weggegooid, onbruikbaar voor consumptie.

image

Maar dan. De uiterste houdbaarheidsdatum van requirements? Het onderwerp kwam ter tafel toen een van de cursisten vertelde op dit moment te werken aan de realisatie van een verzameling requirements uit een RFC die inmiddels twee jaar oud is. Twee jaar oude requirements? De kans is groot dat deze requirements inmiddels al behoorlijk beschimmeld zijn; wet- en regelgeving is gewijzigd, en de wensen van de gebruikers zijn ontegenzeggelijk veranderd. Als tijdens een gemiddeld project de requirements al 20-25% wijzigen, hoe vergaat het dan requirements die ergens op een plank liggen te verstoffen?

Requirements en kaas

Welbeschouwd zijn requirements te vergelijken met kaas. Je hebt jonge requirements, net rijp genoeg om te consumeren, jong belegen requirements die eigenlijk al hadden moeten worden gerealiseerd, en dan oude requirements, die opzichtig beginnen te brokkelen. Tenslotte zijn alle ongebruikte requirements overjarig. Wellicht smaakvol, maar ze vallen al uit elkaar op het moment dat ze worden gehanteerd.

image

En net als kaas die op een plank ligt te rijpen verdienen requirements dezelfde zorgzame aandacht willen ze na een of twee jaar nog consumeerbaar zijn. Ze moeten worden omgedraaid, geevalueerd en verzorgd. Gebeurt dit niet dan verschimmelen ze en moeten ze eenvoudigweg uit de handel worden genomen, ongeschikt voor comsumptie.

Ik denk dan ook dat het een goed idee is ook requirements te stickeren, net als alle andere bederfelijke waar. Wanneer zijn ze aangemaakt, en belangrijker nog, wanneer dienen de requirements gerealiseerd te zijn.

Maar wanneer zijn onze requirements eigenlijk bedorven? Een kritisch agile luisteraar zal wellicht zeggen dat requirements beginnen met rotten zodra ze zijn opgeschreven. Immers, voortschrijdend inzicht begint direct te werken. Wellicht is het goed een standaardtermijn voor bederf te hanteren, zeg een half jaar. En wellicht zijn requirements waarin de user interface speelt sneller bedorven. Die krijgen dan een sticker van drie of vier maanden. En wanneer requirements over hun uiterste houdbaarheidsdatum heen zijn? Gewoon weggooien!

YAGNI

Het is overigens goed mogelijk de uiterste houdbaarheidsdatum te rekken. Hier komt het bekende YAGNI-principe goed van pas. You aren’t gonna need it. Ofwel voorkom in projecten al het werk dat op dit moment nog niet nodig is. Doorvertaald naar requirements komt dit er op neer dat alhoewel het verstandig is aan het begin van een project vast te stellen welke requirements er moeten worden gerealiseerd, alle details  van deze requirements pas echt nodig zijn zodra de realisatie ervan aanvang neemt. En dat is pas veel later.

Dit verklaart ook deels het succes van agile, kort-iteratieve projecten. De details (analyse en ontwerp) van een requirement worden pas bepaald zodra deze tijdens een van de iteraties daadwerkelijk wordt gebouwd. Zo wordt voorkomen dat er vroeg in een project veel werk in requirements wordt gestoken die nooit worden gerealiseerd, zoals in watervalprojecten nog wel eens het geval is. En bovendien, wanneer de details bijvoorbeeld pas na een half jaar worden onderzocht, is het voortschrijdend inzicht van dat half jaar automatisch geborgd. Om in de metafoor te blijven, zo zijn requirements altijd vers.

Benieuwd overigens wat de uiterste houdbaarheidsdatum van deze post zal blijken te zijn.

Smart use case stereotypes in service oriented projects

Posted on by
Reply

Smart use cases are a great technique for specifying standardized requirements in many types of projects. Over the past few years we have smart use cases being modeled and written in projects using Java and .NET, as you might expect, but also in Sharepoint projects, business intelligence, service oriented projects and even SAP implementations.

Stereotypes drive standardization

Standardization of your requirements can be an important driver to simplify software development and software rejuvination projects. An important addition to the smart use case modeling technique is the use of smart use case stereotypes.

These stereotypes represent often occurring patterns of requirements. Well known our the stereotypes manage, that represents a maintenance use case on some domain object, or search, which helps users to find a particular domain object, guided by search criteria. Other known stereotypes include select, master-detail, view, and report. As you might expect, these stereotypes all deal with user interaction.

Over the years however, we have gathered quite a few stereotypes, also in other fields. We have described for instance stereotypes that deal with Extraction Transformation Load (ETL) processes in data warehousing projects, such as aggregate, calculate and load.

Stereotypes not only help to put focus in modeling workshops, they also facilitate more easy project estimates, and even allow for straightforward code generation and isolated testing. Even better, once you marked the stereotypes (and put them into a UML profile), it will allow you to create much richer use case diagrams, modeling in colour.

IMAG0505
Modeling in colour using (profiled) smart use case stereotypes

Slicing service oriented projects

More recently we have applied smart use cases to service oriented projects. These projects tend to be more complex than regular software development projects, and focus around more elaborate architectures Service oriented projects mostly include:

  • Flexible front-end features. These can be either web pages, mobile phone front ends, Windows native applications or even Flash or Silverlight applications.
  • Process-oriented middleware. Service oriented processes always implement business processes. These business processes or workflows are run in middleware, more specifically in an enterprise service bus (ESB), although having such a bus is not mandatory. There are many vendors supplying busses, such as IBM, SAP, Oracle and Microsoft.
  • Stable services. A very important part of service oriented projects consists of the discovery and realization of services. Most often these services are implemented on top of existing legacy or packaged systems.

These slices in service oriented project all serve particular means and responsibilities. The approach to modeling smart use cases in such projects offers quite a few benefits. Next to modeling the front-end use cases, smart use cases help to model the business processes, and discover the required services.

Stereotypes for service oriented projects

In recent projects, that involved such complex service oriented architectures, we have gained a lot of experience in identifying and modeling smart use cases. This week we have analized a number of such models from different projects. This results in a set of new smart use case stereotypes, specifically targeted at the processes that run in middleware, and the encapsulation and execution of services.

IMAG0506
One of the smart use case diagrams we’ve investigated

Next to our well-known front end smart use case stereotypes, the new service oriented stereotypes include the following: process, aggregate, dispatch, validate, read, write and inform. I will elaborate on these stereotypes in the next sections.

Stereotype process

A use case of stereotype process executes a business process. In most cases it delegates the execution of services to other use cases, often of types aggregate and dispatch.

The process use case is in the lead, and uses the post-conditions from called use cases to steer the process. This type of smart use cases is generally implemented in the enterprise service bus, such as BizTalk or SAP Xi.

Stereotype aggregate

An aggregate typed smart use cases generally is used to create a single response to a request.

The stereotype is called aggregate as these use cases trigger other smart use cases, othen of types dispatch and read, and aggregates the results from these use cases into a singel response.

Stereotype dispatch

Smart use cases of type dispatch are intended to link the aggregate or process types use cases to services that either require some mapping, or typically run outside the organization.

Mapping is often required, as the available services do not always deliver what is required by the calling use cases. The dipatch smart use cases performs the mapping (hence and forth) and relays the work to the actual service, that is often of type read or write.

Stereotype validate

Executing business processes often include specific validation services, for instance to see if an customer is allowed to add a particular product to their subscription (as in one of the projects we investigated). Smart use cases labeled with the validate stereotypes return a single answer, that can be either a yes or no response, or a single value from a limited list of possible codes.

In cases of more complex validation, for instance when match-making between different back-end or external systems is required, the validate use case relays fetching the required information to dispatch,  read or even aggregate smart use cases.

Stereotype read

Smart use cases with the read stereotype are the most basic services. Here one or more domain objects or entities are returned from a back-end system. This often includes compressing a whole hierarchy (such as with many SAP systems), such as a product hierarchy into a single returning message.

Stereotype write

In reverse, write typed smart use cases will pick up such a compressed hierarchy that is input to the use case, distribute the hierarchy into the back-end systems and persist it.

Stereotype inform

During the execution of a business process, the actual user of the whole process (being the actor of the user goal level use case initiating the process) needs to be informed of the status. The actor might get an email, such as in a subscription process to acknowledge successful subscribing, or be sent a letter. Other alternatives are of course also possible.

The inform use case is responsible for merging the text of the message being sent with the actual domain objects the use case model evolves around.

Service georienteerde projecten vormgeven met smart use cases [In Dutch]

Posted on by
Reply

This post was originally written to be published as a chapter in an upcoming book on IT architecture. The book will be presented at the Landelijk Architectuur Congres 2009 in Nieuwegein, The Netherlands. This post will likely also be published in two parts in Software Release Magazine.

Ondanks dat ik inmiddels al zo’n twintig jaar in dit vakgebied rondloop, blijven software development projecten uitdaginen opleveren. Zo werkte ik eerder dit jaar coach aan een agile project waarmee een grote logistieke onderneming nieuwe producten voor hun klanten ontsloot.

Alhoewel ik vooral als coach was ingezet op het begeleiden van het proces, was het project technologisch een hele kluif. Een Java portal als front end, orchestratie van processen in SAP middleware, back office systemen in PeopleSoft, SAP en .NET die moesten worden “verserviced”, en niet te vergeten een aantal interfaces naar externe systemen, waar we niet of nauwelijks invloed op konden uitoefenen. Al met al een typisch voorbeeld van een service georienteerd project. Dit type projecten kenmerkt zich door hun hoge complexiteit, en zijn daarom slecht in te schatten en te plannen. Alhoewel niet de oplossing voor alle uitdagingen, bestaat er een techniek die smart use cases wordt genoemd, die concreet en pragmatisch bijdraagt aan het beter inschatten, plannen, maar ook realiseren en testen van servicegeorienteerde projecten.

Service georienteerde projecten zijn complex

Iedereen die in dergelijke projecten heeft gewerkt, weet het inmiddels wel: service georienteerde architecturen maken het uitvoeren van dit soort projecten er niet makkelijker op. Dit soort projecten kenmerken zich een groot aantal organisatorisch, functioneel en technisch complicerende factoren:

  • Diverse stakeholders. Servicegeorienteerde projecten automatiseren in het algemeen bedrijfsprocessen, die meestal meerdere organisatorische eenheden en verschillende systemen doorsnijden. Dientengevolge zijn er vaak diverse stakeholders betrokken bij het project.

IMAG0071

Een servicegeorienteerd project kent vele stakeholders

  • Flexibele front end technologien. Voor het realiseren of uitbreiden van de front end(s) wordt vaak gebruik gemaakt van state-of-the-art, of zelfs bleeding edge technologie, waarover niet altijd evenveel kennis beschikbaar is in de organisatie.
  • Heterogene back end technologien. De diverse systemen die ontsloten dienen worden – verserviced – zijn gerealiseerd in allerhande technologien, al dan niet verouderd.
  • Externe interfaces. Niet zelden wordt ook gebruik gemaakt van systemen die extern zijn aan de organisatie. Op deze systemen kan het project meestal weinig invloed uitoefenen, hooguit zijn de interfaces bekend. Helaas zijn dit soort interfaces zelden stabiel, en aan wijzigingen onderhevig.
  • Diverse rollen. Opvallend aan service georienteerde projecten is dat er een breed scala aan rollen betrokken is. Zo zorgt de diversiteit aan technologie al voor een breed palet aan developers – zo is een SAP CRM consultant geen SAP XI developer, en een .NET developer niet per se ook een software architect. Maar ook andere traditionele en minder traditionele rollen al informatie-analisten, ontwerpes, user inferface designers, enterprise architecten, business consultants en last but not least project managers, vinden hun weg in dit type projecten.

Service georienteerde projecten zijn lastig te plannen

Een recent voorbeeld is een project voor een verzekeraar voor het realiseren van een nieuw hypotheekoffertesysteem. Belangrijkste streven bij dit project was het realiseren van straight-through processing (het zonder humane tussenkomst doorvoeren van hypotheekoffertes naar de back office) en het flexibel kunnen toevoegen van nieuwe hypotheekproducten.

Naast de haast traditionele handicaps als schuivende requirements, bleek gedurende het project dat de interfaces van externe systemen niet aansloten op de gegevens die nodig waren om de benodigde processen uit te voeren. Daarnaast bleek ook de gebruikersvriendelijkheid van de (gegenereerde) webpagina’s tot hoofdbrekens te leiden. Het project levert nu hopelijk ruim een jaar na dato op, en heeft ruim vier keer zoveel gekost als oorspronkelijk begroot.

Maar waarschijnlijk vertel ik u als lezer hiermee nog niets nieuws. Lastig is wel dat deze complexiteit voor uw project een aantal ondermijnende gevolgen kan hebben. Om u een indruk te geven laat ik er hier toch maar een paar de revue passeren:

  • Externe afhankelijkheden. Service georienteerde projecten zijn vrijwel zonder uitzondering afhankelijk van derden, ofwel partijen binnen de eigen organisatie die andere planningen er op nahouden, ofwel partijen buiten de eigen organisatie, die lastig beinvloedbaar zijn.
  • Moeilijk in te schatten. Wie al eens in een offertetraject voor een dergelijk project heeft geparticipeerd; het maken van een goede schatting is cruciaal maar extreem lastig.
  • Moeilijk te plannen. Lastige schattingen, diverse stakeholders, externe afhankelijkheden, en talrijke projectrollen maken het er niet makkelijker op voor de beoogd project manager om een goed planning voor het project af te leveren.
    Een ding is zeker: een traditionele lineaire aanpak, waarin flexibiliteit tot een minimum wordt beperkt, is uit den boze. Een service georienteerd project kent vele wendingen – steeds meer overigens naarmate het project langer duurt.

Het zal u niet verbazen dat met deze consequenties service georienteede projecten te vaak niet op tijd en op budget worden opgeleverd, of dat gaandeweg het project wordt besloten slechts een deel van de vereiste functionaliteit op te leveren. Tenslotte worden de beoogde uitgangspunten voor het project vaak niet gehaald. Denk daarbij aan het in service ontsluiten van legacy back end systemen, het realiseren  van hergebruik ten einde toekomstige projecten sneller te kunnen uitvoeren, het opbouwen van een repository van services or het snel en flexibel kunnen toevoegen van nieuwe producten en features.

Hoe complex is het project eigenlijk?

Zoals gezegd zijn service georienteerde projecten meestal lastig te schatten en derhalve nog lastiger te plannen. Een belangrijk vraag die bij aanvang van dit soort projecten dan ook dient te worden gesteld om een goede kosten-baten-analyse te kunnen maken is: hoe groot en complex is ons project nu eigenlijk?

Een belangrijk struikelblok bij het beantwoorden van deze op het oog eenvoudige vraag is dat er allerlei verschillende typen deliverables zijn te onderkennen in een service georienteerd project. Denk hierbij bijvoorbeeld maar aan webpagina’s, schermen, services, orchestratie, domeinobjecten, transacties. Dit maakt het “tellen” van de totale complexiteit van een project lastig. En zelfs wanneer al deze verschillend typen deliverables zouden kunnen worden geteld, dan nog ontbreken er de nodige ervaringscijfers, die de uiteindelijke complexiteit per type deliverable in uren kunnen helpen vertalen.

IMG_0242

Smart use cases modelleren in een servicegeorienteerd project

Het zou een belangrijk stap voorwaarts voor servicegeorienteerde projecten kunnen zijn wanneer alle (functionele) deliverables op een en dezelfde schaal konden worden uitgedrukt, waarbij de complexiteit van zowel de webpagina’s, schermen, orchestratie als services op eenzelfde manier wordt uitgedrukt, middels een enkele eenheid van schatten, en misschien zelfs wel een enkele eenheid van werk. Immers, zo kunnen makkelijker ervaringscijfers worden verzameld, die weer kunnen worden toegepast om volgende projecten binnen hetzelfde programma beter in te plannen. Deze eenheid van werk dient zich aan door smart use cases te introduceren in service georienteerde projceten.

Use cases

Laat ik bij het begin beginnen. Wat zijn eigenlijk use cases? Meestal wordt een use case aangemerkt als een beschrijving van het gedrag dat software vertoont als reactie op een verzoek dat stamt van buiten de software. Vrij vertaald beschrijft een use case wie met de software wat kan doen. Een use case realiseert een bepaald doel voor uitvoerder van de use case. In jargon wordt deze uitvoerder wel de actor genoemd. Zo’n actor hoeft overigens niet perse menselijk te zijn, maar kan bijvoorbeeld ook andere software zijn of zelfs een batchverwerking.

Het uitvoeren van de use case vindt plaats als een opeenvolging van een aantal stappen. Deze stappen vormen tesamen een of meerdere scenario’s die uitmonden of in het realiseren van het doel, of, wanneer er iets mis gaat, in een uitzonderingssituatie. Deze eindresultaten worden wel de postcondities van de use cases genoemd. Use cases worden veelal beschreven in documenten, al dan niet geformateerd in een voorgeschreven sjabloon.

ManageSite

Voorbeeld van een use case diagram

Daarnaast bestaat er een aardige, relatief informele en veel toegepast modelleertechniek, waarin actor als poppetjes worden gerepresenteerd, en use cases als ovaaltjes. Deze modelleertechniek, die het use case diagram wordt genoemd, wordt ondersteund door een breed scala aan geautomatiseerde gereedschappen.

Traditionele use cases

Traditioneel worden reguliere use cases gebruikt voor het beschrijven van de functionele requirements van een regulier project, uitgaande van het doel dat de gebruiker (of actor) wil bereiken door de use case uit te voeren. Traditioneel worden use cases beschreven in een document, dat naast het doel, het resultaat ook alle mogelijke scenario’s beschrijft aan de hand waarvan de use case kan worden doorlopen.

Een interessant voorbeeld van een dergelijk use case kwam ik tegen in een service georienteerde project bij een interrnationale bank, waar een use case Wijzigen Adres een document van vijfenzestig pagina’s besloeg, waarin twaalf schermen voorkwamen, tientallen scenario’s en waarin diverse services werden aangeroepen. Een ander gelijksoortig voorbeeld is een use case Uitvoeren Kwartaalfacturering van een pensioenfonds, waarbij circa 1.3 miljoen factuurregels werden berekend.

Alhoewel dergelijke use cases  in service georienteerde meestal de te realiseren bedrijfsprocessen beschrijven, zijn ze niet bijzonder geschikt als eenheid van werk en van schatten in dit type projecten. Traditionele use cases verschillen te veel in omvang en complexiteit, om ze met een gerust hart op een lineare schaal uit te drukken. Ter ondersteuning: het realiseren van de use case Uitvoeren Kwartaalfacturering vergde ruim anderhalf jaar, terwijl het in hetzelfde project slechts enkele dagen kostte de use case Inloggen Gebruiker in te voeren.

Daarbij komt nog het bezwaar dat deze wijze van benaderen van use cases niet bijdraagt aan het identificeren en realiseren van de gewenste services, en dat hergebruik slechts sporadisch en incidenteel tot stand komt.

Smart use cases

Toch hebben we in de afgelopen jaren ervaren dat use cases een heel nuttig vehikel kunnen zijn in servicegeorienteerde projecten. En niet alleen om projecten in te kunnen schatten, maar ook als eenheid van werk, en zelfs voor het identificeren en hergebruiken van services. Om deze nobele doelstellingen te bereiken maken we intensief gebruik van wat we in de loop der jaren smart use cases zijn gaan noemen – genoemd naar de agile methodiek Smart en goed beschreven in mijn boek Pragmatisch modelleren met UML. Een korte introductie.

Alistair Cockburn, autoriteit op het gebied van use cases, beschrijft in zijn boek Writing effective use cases een model waarin use cases in vijf verschillende niveau’s van granulariteit – zeg maar grootte en complexiteit – worden uitgedrukt.

image

Deze niveau’s zijn:

  • Cloud. Use cases op dit hoogste niveau representeren veelal groepen van samenhorende bedrijfsprocessen, zoals Verkopen Producten.
  • Kite. Op dit tweede niveau worden in de regel individuele bedrijfsprocessen geposteerd, vaak workflow georienteerd.
  • Sea. Dit is het niveau waar het om draait, en waar bijvoorbeeld ook Wijzigen Adres toe behoort. De kernvraag op dit niveau zou kunnen zijn: hangt de performance van mijn organisatie af van hoeveel van deze kan ik per dag uitvoeren? Als richtlijn: deze use cases komen nagenoeg overeen met wat ook wel als elementaire bedrijfsprocessen wordt geduid.
  • Fish. Use cases op fish niveau worden gebruikt om op zichzelfstaande, maar aan sea niveau ondersteunende functionaliteit te modelleren. Denk bijvoorbeeld aan Ophalen Abonnement of Selecteren Product.
  • Clam. Soms modelleren projecten te ver door, en worden de use cases te klein. Hier spreekt men over clam niveau.

Ondanks de beknoptheid van deze introductie, moge het duidelijk zijn dat cloud en kite niveau in servicegeorienteerde project met name terug te vinden zijn in de te automatiseren bedrijfsprocessen, de visie van het projec en wellicht de bedrijfsarchitectuur van de organisatie.

De use cases op het sea en fish niveau worden samen smart use cases genoemd. Deze twee niveau’s vormen zo een goede basis van gelijke granulariteit zowel voor het uitdrukken van functionaliteit die direct zichtbaar is voor de gebruiker, zoals Selecteren Product, maar ook voor het identificeren van services, en het aanleggen van een repository van deze services, zoals Ophalen Abonnement.

Smart use cases modelleren

Veel meer dan in traditionele use cases het geval is, gebruiken we voor het vormgeven van smart use cases de bijbehorende modelleertechniek.

Uitgaande van de lijst te realiseren bedrijfsprocessen op kite niveau, modelleren we een use case diagram per elementair bedrijfsproces, op sea niveau derhalve. Ieder use case diagram bevat:

  • Sea niveau use case. Een enkele use case die het elementair bedrijfsprocess representeert, weergegeven als een ovaal.
  • Actoren. Een of meerdere partijen die gebruik maken van deze use case, om daar hun doel mee te bereiken, weergegeven als poppetjes.
  • Fish niveau use cases. Nul, een of meerdere use cases die ondersteunend zijn aan de sea niveau use case, eveneens weergegeven als ovalen.

Onderstaande figuur bevat een goed voorbeeld van een dergelijke use case diagram .

Task

In dit use case diagram zijn de use cases Apply for Membership en Activate Membership sea nieuws use cases, de overige use cases zoals Send Confirmation en Validate Creditcard zijn fish niveau.

Om tot dit diagram te komen distilleren we normaliter de fish niveau use cases uit de sea niveau use case, door onszelf steeds opnieuw te vragen: wat is de volgende stap die we nemen bij het uitvoeren van deze use case? In sommige gevallen is het handig om deze stappen als individuele use cases op te nemen in het diagram, in andere gevallen weer niet. We hanteren hiervoor een set aan richtlijnen, zoals aan het identificeren van hergebruik – komen we deze use case mogelijk vaker tegen? Of denk het afhandelen van alle interactie rond een formulier of scherm, of het importeren en exporteren van bestanden.

Standaard typen smart use cases

Deze hierboven beschreven aanpak is inmiddels – met veel succes – toegepast in een diverse typen projecten, zoals reguliere webprojecten in .NET of Java, het implementeren van portals, business intelligence en zelfs pakketimplementaties.

Bij het uitvoeren van al deze projecten is vooral opgevallen dat steeds opnieuw dezelfde soorten smart use cases de revue passeren. Denk hierbij aan het selecteren, zoeken, of onderhouden van gegevens, het exporteren van een bestand, of het aggregeren van gegevens in een business intelligence situatie.

Deze standaardtypen use cases (in de wandelgangen stereotypen genoemd) helpen projecten enorm om de analyse van de requirements te versoepelen en standardiseren. Het jargon van smart use cases wordt tijdens workshops al snel overgenomen door opdrachtgever en gebruikers. “Ik stel voor dat hier hier een master-detail over klanten en orders gebruiken, met een search op producten”.

Belangrijk bijkomende voordelen van het toepassen van deze (of eigen) stereotypen is dat ook het schatten van de omvang van het project vergemakkelijkt, en dat ook de realisatie, inclusief testen, van dit soort standaard use cases eenvoudiger is. Immers, er is al eens eerder met hetzelfde bijltje gehakt. Een onderhouds-use case voor klanten verschilt niet wezenblijk van een onderhouds-use case voor producten.

Smart use cases modelleren in servicegeorienteerde projecten

Ook in servicegeorienteerde projecten hanteren we sinds enkele jaren smart use cases. Daarbij brengen we graag een tweedeling aan, we modelleren een front end use case diagram, en een service use case diagram.

Allereerst modelleren we een smart use case diagram vanaf de sea level use case die de interactie met de gebruikers en het elementaire bedrijfsproces vertegenwoordigt, zoals Aanvragen Subsidie. Daarbij identificeren we de bijbehorende fish level use cases, maar alleen  tot aan het aanroepen van de services of de orchestratie.

Smart use cases - Services

Use case diagram dat de interactie met de gebruikers modelleert tot aan de services.

In dit voorbeeld zijn alle gele use cases client facing, en representeren de rode use case de interactie met de service verlenende systemen.

Daarnaast modelleren we een tweede smart use case diagram, met de desbetreffende service, en alle achterliggende services als fish level use cases. In dit diagram beschrijft de sea level use case in het algemeen de orchestratie, en representeren de achterliggende fish level use cases de individuele services.

Smart use-case diagram - Leveren verlening VDU-ROS

Use case diagram dat het uitvoeren van de service Leveren Product modelleert.

In bovenstaand diagram  wordt de orchestratie verzorgd door de use case Leveren Product (via SAP middleware), en leveren de overige use cases services die door door Leveren Product worden geconsumeerd. In feite is deze use case een samengestelde service, die (letterlijk) wordt hergebruikt in het front end use case diagram, vergelijkbaar met de rode use cases in het voorgaande voorbeeld.

Het toepassen van een dergelijke aanpak biedt zeer concrete voordelen:

  • Eenduidig. Er is een eenduidige manier voor het beschrijven en modelleren van alle functionele onderdelen van het project, inclusief de schermen, orchestratie en services.
  • Gelijke granulariteit. Wanner het project de hierboven beschreven richtlijnen correct toepast, hebben alle use cases een vergelijkbare granulariteit – ze zijn allemaal ongeveer even groot, of zo u wilt, even klein.
  • Technologie-onafhankelijk. Smart use cases zijn te modelleren onafhankelijk van de platforms en technologie die wordt gebruikt. Bovenstaande voorbeelden kunnen evengoed in .NET en SAP worden gerealiseerd, als in in Java en Oracle.
  • Inschatbaar. De smart use cases, met daarbij de onderkende stereotypen, maken een goede eenheid voor het inschatten van servicegeorienteerde projecten. Hiervoor is een eenvoudige schaal gedefinieerd die wordt uigedrukt in smart use case punten.
  • Goede eenheid van werk.  Tenslotte, smart use cases vormen een goede eenheid van werk in projecten. In de regel is iedere use case los van de andere te ontwerpen, te ontwikkelen en vooral: individueel te testen. Met name dit laatste aspect zorgt ervoor dat de acceptatie van de te ontwikkelen en hergebruiken componenten vergemakkelijkt.
  • Hergebruik. Omdat smart use cases technologie-onafhankelijk zijn te modelleren en te beschrijven, biedt de techniek de mogelijkheid om een repository aan te leggen van gebruikte services, uitgedrukt in smart use cases.

Schatten met smart use cases

Omdat smart use cases zo eenduidig en technologie-onafhankelijk beeld geven van de functionaliteit van een project, is het een goede eenheid om de complexiteit en omvang van het project in te schatten. Hiervoor is een eenvoudige schaal gedefinieerd; de meetlat waarlangs alle smart use cases in een project wordt gelegd. Deze schaal is als volgt gedefinieerd:

  • 1 – Piece of cake. Eenvoudige use cases, zoals selecties uit standaardlijstjes, of eenvoudige onderhoud, zoals Onderhouden Contracttypen.
  • 2 – Moderate. Reguliere use cases, bijvoorbeeld voor selecties uit iets uitgebreidere lijstjes. Denk hierbij aan Selecteren Account Manager per Regio.
  • 3 – Average. De gemiddelde complexiteit, die meestal wordt gegeven voor regulier onderhoud, zoeken, of eenvoudige rapportages. Voorbeelden zijn Zoeken Boek, of Beheren Klant. Dit is tevens de default complexiteit.
  • 4 – Hard. Wordt gegeven bij lastiger onderhoud of rapportages. Ook eenvoudige services, meestal zonder het wegschrijven van gegevens, krijgen vaak deze complexiteit. Denk aan Ophalen Contract of Overzicht Orders per Klant.
  • 5 – Very difficult. Use cases met deze complexiteit worden als lastig beschouwd. Meestal zijn dit uitgebreide rapportages, grafieken, al dan niet met drill-down, of complexere services waarbij gegevens worden weggeschreven. Denk aan Vastleggen Abonnement.
  • 8 – Extreme, but known. Deze complexiteit wordt bewaard voor de zeer lastige use cases. Het betreft hier bijvoorbeeld complexe berekeningen of samengestelde services die vaak het uitvoeren van een proces voor hun rekening nemen. In business intelligence projecten wordt deze complexiteit vaak gegeven aan use cases die datatransformaties uitvoeren. Denk maar aan Berekenen Prepensioen.
  • 10 – Extreme and unknown. Deze hoogste complexiteit wordt uitgedeeld om twee redenen. Enerzijds voor use cases die bewezen lastig zijn, zoals het importeren en exporteren van bestanden en berichten. Anderzijds geven we deze complexiteit op het moment dat we wel weten dat de use case complex is, maar nog niet goed kunnen definieren hoe complex dit precies is. In deze gevallen verplichten we ons deze use case nog nader onder de loup te nemen. Vaak komen hier nog additionele use cases uit naar voren.

Met behulp van deze snel toepasbare schaal, en de vele standaardtypen use cases die we in veel projecten zijn tegengekomen en die al eerder langs deze maatlat zijn gelegd, kunnen we snel en betrouwbaar de complexiteit van een project inschatten. Dit maakt smart use case schattingen herhaalbaar, en bovendien kunnen er gemakkelijk ervaringscijfers uit worden gedistilleerd voor komende projecten. Dit laatste is met name in organisaties die servicegeorienteerd gaan werken belangrijk, omdat daar meerdere automatiseringprojecten uitvoeren binnen eenzelfde programma. “Ons huidige project beslaat 298 smart use case punten.”

Niet zelden komen dit soort schattingen tot stand tijdens workshops, waaraan alle betrokken partijen deelnemen, zoals de klant, de gebruikers, de architect, analisten, ontwikkelaars en ook de testers.

IMG_0224

Workshop waarin de complexiteit van smart use cases door het team wordt geschat

Tijdens dergelijke workshops krijgt het (toekomstige) projectteam een goed en vooral eenduidig beeld van het project en de complexiteit van de requirements. Met name voor de klant, die niet altijd een reeel beeld heeft hoe complex de realisatie van zijn of haar wensen eigenlijk is. “Oei. Dit wordt toch veel lastig en duurder dan we hadden verwacht,” is een veel gehoorde uitspraak, “misschien moesten we eens onderzoeken of er alternatieven zijn.”

Verlengen voordeeluren

Vooruit dan. Om mijn bovenstaande beweringen kracht bij te zetten een laatste anecdote. Tijdens een recent project bij een grote openbaar vervoersonderneming realiseerden we een aantal bedrijfsprocessen rondom een nieuw type abonnement. Deze processen waren uitgemodelleerd in smart use case diagrammen, zowel voor de front end als voor de services.

Ongeveer halverwege het project, terwijl we inmiddels al een deel van de processen hadden geimplementeerd als smart use cases, kwam de opdrachtgever schoorvoetend met een verzoek. “Zouden we, als we toch ook dit nieuwe type abonnement implementeren, ook eens kunnen kijken naar het verlengen van de voordeelurenkaarten?” Bijna verschoot de opdrachtgever hierbij van kleur.

Vrijwel onmiddelijk organiseerde de projectleider een workshop waarin het verlengen van voordeelurenkaarten onder de loup werd genomen. Na twee uur modelleren bleek dat bijna het gehele proces was te realiseren door hergebruik van smart use cases die we al hadden. We hoefden slechts vier nieuwe smart use cases toe te voegen, met een geschat totaal van 16 smart use cases punten. Het behoeft denk ik verder weinig uitleg dat de klant snel besloot het verlengen van de voordeelurenkaarten toe te voegen aan het project. Dit is hergebruik ten top.

Inzicht en overzicht

Servicegeorienteerde projecten kunnen, met name in grote organisaties, enorm bijdragen aan de effectiviteit en efficientie van de bedrijfsvoering. Een mooi voorbeeld hiervan maakte ik bij een bank mee. Wanneer een klant van deze bank het onzalige besluit nam om te verhuizen, moest dit oorspronkelijk in 36 verschillende systemen worden vastgelegd. Door steeds meer van deze systemen met behulp van services te ontsluiten, werd dit ogenschijnlijk eenvoudige bedrijfsproces in de loop van enkele jaren en projecten teruggebracht naar een enkele administratieve handeling.

Servicegeorienteerde projecten zijn echter ook zeer complex van aard. Bovengenoemde bank had een aantal projecten nodig om de beoogde verandering te bewerkstelligen. Alhoewel smart use cases, en de bijbehorende standaardtypen en schattingstechnieken natuurlijk niet alle problematiek van dit soort projecten tot nul reduceert, dragen ze zeer concreet bij aan het inzichtelijk maken van deze complexiteit, door een eenduidige eenheid van werk te introduceren, zowel voor de front ends, als voor de achterliggende orchestratie en services. Als klapper op de vuurpijl is deze uniforme eenheid van werk ook nog eens naar behoren in te schatten, en onafhankelijk te testen. Als ik het In een notedop zou moeten samenvatten: inzicht en overzicht. Precies dat wat veel servicegeorienteerde projecten ontberen.

Serviceorientatie vormgeven met smart use cases [In Dutch]

Posted on by
Reply

This post was originally written to be published as a chapter in an upcoming book on IT architecture. The book will be presented at the Landelijk Architectuur Congres 2009 in Nieuwegein, The Netherlands. This post will likely also be published in two parts in Software Release Magazine.

Ondanks dat ik inmiddels al zo’n twintig jaar in dit vakgebied rondloop, blijven software development projecten uitdaginen opleveren. Zo werkte ik eerder dit jaar coach aan een agile project waarmee een grote logistieke onderneming nieuwe producten voor hun klanten ontsloot.

Alhoewel ik vooral als coach was ingezet op het begeleiden van het proces, was het project technologisch een hele kluif. Een Java portal als front end, orchestratie van processen in SAP middleware, back office systemen in PeopleSoft, SAP en .NET die moesten worden “verserviced”, en niet te vergeten een aantal interfaces naar externe systemen, waar we niet of nauwelijks invloed op konden uitoefenen. Al met al een typisch voorbeeld van een service georienteerd project. Dit type projecten kenmerkt zich door hun hoge complexiteit, en zijn daarom slecht in te schatten en te plannen. Alhoewel niet de oplossing voor alle uitdagingen, bestaat er een techniek die smart use cases wordt genoemd, die concreet en pragmatisch bijdraagt aan het beter inschatten, plannen, maar ook realiseren en testen van servicegeorienteerde projecten.

Service georienteerde projecten zijn complex

Iedereen die in dergelijke projecten heeft gewerkt, weet het inmiddels wel: service georienteerde architecturen maken het uitvoeren van dit soort projecten er niet makkelijker op. Dit soort projecten kenmerken zich een groot aantal organisatorisch, functioneel en technisch complicerende factoren:

  • Diverse stakeholders. Servicegeorienteerde projecten automatiseren in het algemeen bedrijfsprocessen, die meestal meerdere organisatorische eenheden en verschillende systemen doorsnijden. Dientengevolge zijn er vaak diverse stakeholders betrokken bij het project.

IMAG00713

Een servicegeorienteerd project kent vele stakeholders

  • Flexibele front end technologien. Voor het realiseren of uitbreiden van de front end(s) wordt vaak gebruik gemaakt van state-of-the-art, of zelfs bleeding edge technologie, waarover niet altijd evenveel kennis beschikbaar is in de organisatie.
  • Heterogene back end technologien. De diverse systemen die ontsloten dienen worden – verserviced – zijn gerealiseerd in allerhande technologien, al dan niet verouderd.
  • Externe interfaces. Niet zelden wordt ook gebruik gemaakt van systemen die extern zijn aan de organisatie. Op deze systemen kan het project meestal weinig invloed uitoefenen, hooguit zijn de interfaces bekend. Helaas zijn dit soort interfaces zelden stabiel, en aan wijzigingen onderhevig.
  • Diverse rollen. Opvallend aan service georienteerde projecten is dat er een breed scala aan rollen betrokken is. Zo zorgt de diversiteit aan technologie al voor een breed palet aan developers – zo is een SAP CRM consultant geen SAP XI developer, en een .NET developer niet per se ook een software architect. Maar ook andere traditionele en minder traditionele rollen al informatie-analisten, ontwerpes, user inferface designers, enterprise architecten, business consultants en last but not least project managers, vinden hun weg in dit type projecten.

Service georienteerde projecten zijn lastig te plannen

Een recent voorbeeld is een project voor een verzekeraar voor het realiseren van een nieuw hypotheekoffertesysteem. Belangrijkste streven bij dit project was het realiseren van straight-through processing (het zonder humane tussenkomst doorvoeren van hypotheekoffertes naar de back office) en het flexibel kunnen toevoegen van nieuwe hypotheekproducten.

Naast de haast traditionele handicaps als schuivende requirements, bleek gedurende het project dat de interfaces van externe systemen niet aansloten op de gegevens die nodig waren om de benodigde processen uit te voeren. Daarnaast bleek ook de gebruikersvriendelijkheid van de (gegenereerde) webpagina’s tot hoofdbrekens te leiden. Het project levert nu hopelijk ruim een jaar na dato op, en heeft ruim vier keer zoveel gekost als oorspronkelijk begroot.

Maar waarschijnlijk vertel ik u als lezer hiermee nog niets nieuws. Lastig is wel dat deze complexiteit voor uw project een aantal ondermijnende gevolgen kan hebben. Om u een indruk te geven laat ik er hier toch maar een paar de revue passeren:

  • Externe afhankelijkheden. Service georienteerde projecten zijn vrijwel zonder uitzondering afhankelijk van derden, ofwel partijen binnen de eigen organisatie die andere planningen er op nahouden, ofwel partijen buiten de eigen organisatie, die lastig beinvloedbaar zijn.
  • Moeilijk in te schatten. Wie al eens in een offertetraject voor een dergelijk project heeft geparticipeerd; het maken van een goede schatting is cruciaal maar extreem lastig.
  • Moeilijk te plannen. Lastige schattingen, diverse stakeholders, externe afhankelijkheden, en talrijke projectrollen maken het er niet makkelijker op voor de beoogd project manager om een goed planning voor het project af te leveren.
    Een ding is zeker: een traditionele lineaire aanpak, waarin flexibiliteit tot een minimum wordt beperkt, is uit den boze. Een service georienteerd project kent vele wendingen – steeds meer overigens naarmate het project langer duurt.

Het zal u niet verbazen dat met deze consequenties service georienteede projecten te vaak niet op tijd en op budget worden opgeleverd, of dat gaandeweg het project wordt besloten slechts een deel van de vereiste functionaliteit op te leveren. Tenslotte worden de beoogde uitgangspunten voor het project vaak niet gehaald. Denk daarbij aan het in service ontsluiten van legacy back end systemen, het realiseren  van hergebruik ten einde toekomstige projecten sneller te kunnen uitvoeren, het opbouwen van een repository van services or het snel en flexibel kunnen toevoegen van nieuwe producten en features.

Hoe complex is het project eigenlijk?

Zoals gezegd zijn service georienteerde projecten meestal lastig te schatten en derhalve nog lastiger te plannen. Een belangrijk vraag die bij aanvang van dit soort projecten dan ook dient te worden gesteld om een goede kosten-baten-analyse te kunnen maken is: hoe groot en complex is ons project nu eigenlijk?

Een belangrijk struikelblok bij het beantwoorden van deze op het oog eenvoudige vraag is dat er allerlei verschillende typen deliverables zijn te onderkennen in een service georienteerd project. Denk hierbij bijvoorbeeld maar aan webpagina’s, schermen, services, orchestratie, domeinobjecten, transacties. Dit maakt het “tellen” van de totale complexiteit van een project lastig. En zelfs wanneer al deze verschillend typen deliverables zouden kunnen worden geteld, dan nog ontbreken er de nodige ervaringscijfers, die de uiteindelijke complexiteit per type deliverable in uren kunnen helpen vertalen.

IMG_02424

Smart use cases modelleren in een servicegeorienteerd project

Het zou een belangrijk stap voorwaarts voor servicegeorienteerde projecten kunnen zijn wanneer alle (functionele) deliverables op een en dezelfde schaal konden worden uitgedrukt, waarbij de complexiteit van zowel de webpagina’s, schermen, orchestratie als services op eenzelfde manier wordt uitgedrukt, middels een enkele eenheid van schatten, en misschien zelfs wel een enkele eenheid van werk. Immers, zo kunnen makkelijker ervaringscijfers worden verzameld, die weer kunnen worden toegepast om volgende projecten binnen hetzelfde programma beter in te plannen. Deze eenheid van werk dient zich aan door smart use cases te introduceren in service georienteerde projceten.

Use cases

Laat ik bij het begin beginnen. Wat zijn eigenlijk use cases? Meestal wordt een use case aangemerkt als een beschrijving van het gedrag dat software vertoont als reactie op een verzoek dat stamt van buiten de software. Vrij vertaald beschrijft een use case wie met de software wat kan doen. Een use case realiseert een bepaald doel voor uitvoerder van de use case. In jargon wordt deze uitvoerder wel de actor genoemd. Zo’n actor hoeft overigens niet perse menselijk te zijn, maar kan bijvoorbeeld ook andere software zijn of zelfs een batchverwerking.

Het uitvoeren van de use case vindt plaats als een opeenvolging van een aantal stappen. Deze stappen vormen tesamen een of meerdere scenario’s die uitmonden of in het realiseren van het doel, of, wanneer er iets mis gaat, in een uitzonderingssituatie. Deze eindresultaten worden wel de postcondities van de use cases genoemd. Use cases worden veelal beschreven in documenten, al dan niet geformateerd in een voorgeschreven sjabloon.

ManageSite3

Voorbeeld van een use case diagram

Daarnaast bestaat er een aardige, relatief informele en veel toegepast modelleertechniek, waarin actor als poppetjes worden gerepresenteerd, en use cases als ovaaltjes. Deze modelleertechniek, die het use case diagram wordt genoemd, wordt ondersteund door een breed scala aan geautomatiseerde gereedschappen.

Traditionele use cases

Traditioneel worden reguliere use cases gebruikt voor het beschrijven van de functionele requirements van een regulier project, uitgaande van het doel dat de gebruiker (of actor) wil bereiken door de use case uit te voeren. Traditioneel worden use cases beschreven in een document, dat naast het doel, het resultaat ook alle mogelijke scenario’s beschrijft aan de hand waarvan de use case kan worden doorlopen.

Een interessant voorbeeld van een dergelijk use case kwam ik tegen in een service georienteerde project bij een interrnationale bank, waar een use case Wijzigen Adres een document van vijfenzestig pagina’s besloeg, waarin twaalf schermen voorkwamen, tientallen scenario’s en waarin diverse services werden aangeroepen. Een ander gelijksoortig voorbeeld is een use case Uitvoeren Kwartaalfacturering van een pensioenfonds, waarbij circa 1.3 miljoen factuurregels werden berekend.

Alhoewel dergelijke use cases  in service georienteerde meestal de te realiseren bedrijfsprocessen beschrijven, zijn ze niet bijzonder geschikt als eenheid van werk en van schatten in dit type projecten. Traditionele use cases verschillen te veel in omvang en complexiteit, om ze met een gerust hart op een lineare schaal uit te drukken. Ter ondersteuning: het realiseren van de use case Uitvoeren Kwartaalfacturering vergde ruim anderhalf jaar, terwijl het in hetzelfde project slechts enkele dagen kostte de use case Inloggen Gebruiker in te voeren.

Daarbij komt nog het bezwaar dat deze wijze van benaderen van use cases niet bijdraagt aan het identificeren en realiseren van de gewenste services, en dat hergebruik slechts sporadisch en incidenteel tot stand komt.

Smart use cases

Toch hebben we in de afgelopen jaren ervaren dat use cases een heel nuttig vehikel kunnen zijn in servicegeorienteerde projecten. En niet alleen om projecten in te kunnen schatten, maar ook als eenheid van werk, en zelfs voor het identificeren en hergebruiken van services. Om deze nobele doelstellingen te bereiken maken we intensief gebruik van wat we in de loop der jaren smart use cases zijn gaan noemen – genoemd naar de agile methodiek Smart en goed beschreven in mijn boek Pragmatisch modelleren met UML. Een korte introductie.

Alistair Cockburn, autoriteit op het gebied van use cases, beschrijft in zijn boek Writing effective use cases een model waarin use cases in vijf verschillende niveau’s van granulariteit – zeg maar grootte en complexiteit – worden uitgedrukt.

image3

Deze niveau’s zijn:

  • Cloud. Use cases op dit hoogste niveau representeren veelal groepen van samenhorende bedrijfsprocessen, zoals Verkopen Producten.
  • Kite. Op dit tweede niveau worden in de regel individuele bedrijfsprocessen geposteerd, vaak workflow georienteerd.
  • Sea. Dit is het niveau waar het om draait, en waar bijvoorbeeld ook Wijzigen Adres toe behoort. De kernvraag op dit niveau zou kunnen zijn: hangt de performance van mijn organisatie af van hoeveel van deze kan ik per dag uitvoeren? Als richtlijn: deze use cases komen nagenoeg overeen met wat ook wel als elementaire bedrijfsprocessen wordt geduid.
  • Fish. Use cases op fish niveau worden gebruikt om op zichzelfstaande, maar aan sea niveau ondersteunende functionaliteit te modelleren. Denk bijvoorbeeld aan Ophalen Abonnement of Selecteren Product.
  • Clam. Soms modelleren projecten te ver door, en worden de use cases te klein. Hier spreekt men over clam niveau.

Ondanks de beknoptheid van deze introductie, moge het duidelijk zijn dat cloud en kite niveau in servicegeorienteerde project met name terug te vinden zijn in de te automatiseren bedrijfsprocessen, de visie van het projec en wellicht de bedrijfsarchitectuur van de organisatie.

De use cases op het sea en fish niveau worden samen smart use cases genoemd. Deze twee niveau’s vormen zo een goede basis van gelijke granulariteit zowel voor het uitdrukken van functionaliteit die direct zichtbaar is voor de gebruiker, zoals Selecteren Product, maar ook voor het identificeren van services, en het aanleggen van een repository van deze services, zoals Ophalen Abonnement.

Smart use cases modelleren

Veel meer dan in traditionele use cases het geval is, gebruiken we voor het vormgeven van smart use cases de bijbehorende modelleertechniek.

Uitgaande van de lijst te realiseren bedrijfsprocessen op kite niveau, modelleren we een use case diagram per elementair bedrijfsproces, op sea niveau derhalve. Ieder use case diagram bevat:

  • Sea niveau use case. Een enkele use case die het elementair bedrijfsprocess representeert, weergegeven als een ovaal.
  • Actoren. Een of meerdere partijen die gebruik maken van deze use case, om daar hun doel mee te bereiken, weergegeven als poppetjes.
  • Fish niveau use cases. Nul, een of meerdere use cases die ondersteunend zijn aan de sea niveau use case, eveneens weergegeven als ovalen.

Onderstaande figuur bevat een goed voorbeeld van een dergelijke use case diagram .

Task4

In dit use case diagram zijn de use cases Apply for Membership en Activate Membership sea nieuws use cases, de overige use cases zoals Send Confirmation en Validate Creditcard zijn fish niveau.

Om tot dit diagram te komen distilleren we normaliter de fish niveau use cases uit de sea niveau use case, door onszelf steeds opnieuw te vragen: wat is de volgende stap die we nemen bij het uitvoeren van deze use case? In sommige gevallen is het handig om deze stappen als individuele use cases op te nemen in het diagram, in andere gevallen weer niet. We hanteren hiervoor een set aan richtlijnen, zoals aan het identificeren van hergebruik – komen we deze use case mogelijk vaker tegen? Of denk het afhandelen van alle interactie rond een formulier of scherm, of het importeren en exporteren van bestanden.

Standaard typen smart use cases

Deze hierboven beschreven aanpak is inmiddels – met veel succes – toegepast in een diverse typen projecten, zoals reguliere webprojecten in .NET of Java, het implementeren van portals, business intelligence en zelfs pakketimplementaties.

Bij het uitvoeren van al deze projecten is vooral opgevallen dat steeds opnieuw dezelfde soorten smart use cases de revue passeren. Denk hierbij aan het selecteren, zoeken, of onderhouden van gegevens, het exporteren van een bestand, of het aggregeren van gegevens in een business intelligence situatie.

Deze standaardtypen use cases (in de wandelgangen stereotypen genoemd) helpen projecten enorm om de analyse van de requirements te versoepelen en standardiseren. Het jargon van smart use cases wordt tijdens workshops al snel overgenomen door opdrachtgever en gebruikers. “Ik stel voor dat hier hier een master-detail over klanten en orders gebruiken, met een search op producten”.

Belangrijk bijkomende voordelen van het toepassen van deze (of eigen) stereotypen is dat ook het schatten van de omvang van het project vergemakkelijkt, en dat ook de realisatie, inclusief testen, van dit soort standaard use cases eenvoudiger is. Immers, er is al eens eerder met hetzelfde bijltje gehakt. Een onderhouds-use case voor klanten verschilt niet wezenblijk van een onderhouds-use case voor producten.

Smart use cases modelleren in servicegeorienteerde projecten

Ook in servicegeorienteerde projecten hanteren we sinds enkele jaren smart use cases. Daarbij brengen we graag een tweedeling aan, we modelleren een front end use case diagram, en een service use case diagram.

Allereerst modelleren we een smart use case diagram vanaf de sea level use case die de interactie met de gebruikers en het elementaire bedrijfsproces vertegenwoordigt, zoals Aanvragen Subsidie. Daarbij identificeren we de bijbehorende fish level use cases, maar alleen  tot aan het aanroepen van de services of de orchestratie.

SmartusecasesServices

Use case diagram dat de interactie met de gebruikers modelleert tot aan de services.

In dit voorbeeld zijn alle gele use cases client facing, en representeren de rode use case de interactie met de service verlenende systemen.

Daarnaast modelleren we een tweede smart use case diagram, met de desbetreffende service, en alle achterliggende services als fish level use cases. In dit diagram beschrijft de sea level use case in het algemeen de orchestratie, en representeren de achterliggende fish level use cases de individuele services.

SmartusecasediagramLeverenverleningV

Use case diagram dat het uitvoeren van de service Leveren Product modelleert.

In bovenstaand diagram  wordt de orchestratie verzorgd door de use case Leveren Product (via SAP middleware), en leveren de overige use cases services die door door Leveren Product worden geconsumeerd. In feite is deze use case een samengestelde service, die (letterlijk) wordt hergebruikt in het front end use case diagram, vergelijkbaar met de rode use cases in het voorgaande voorbeeld.

Het toepassen van een dergelijke aanpak biedt zeer concrete voordelen:

  • Eenduidig. Er is een eenduidige manier voor het beschrijven en modelleren van alle functionele onderdelen van het project, inclusief de schermen, orchestratie en services.
  • Gelijke granulariteit. Wanner het project de hierboven beschreven richtlijnen correct toepast, hebben alle use cases een vergelijkbare granulariteit – ze zijn allemaal ongeveer even groot, of zo u wilt, even klein.
  • Technologie-onafhankelijk. Smart use cases zijn te modelleren onafhankelijk van de platforms en technologie die wordt gebruikt. Bovenstaande voorbeelden kunnen evengoed in .NET en SAP worden gerealiseerd, als in in Java en Oracle.
  • Inschatbaar. De smart use cases, met daarbij de onderkende stereotypen, maken een goede eenheid voor het inschatten van servicegeorienteerde projecten. Hiervoor is een eenvoudige schaal gedefinieerd die wordt uigedrukt in smart use case punten.
  • Goede eenheid van werk.  Tenslotte, smart use cases vormen een goede eenheid van werk in projecten. In de regel is iedere use case los van de andere te ontwerpen, te ontwikkelen en vooral: individueel te testen. Met name dit laatste aspect zorgt ervoor dat de acceptatie van de te ontwikkelen en hergebruiken componenten vergemakkelijkt.
  • Hergebruik. Omdat smart use cases technologie-onafhankelijk zijn te modelleren en te beschrijven, biedt de techniek de mogelijkheid om een repository aan te leggen van gebruikte services, uitgedrukt in smart use cases.

Schatten met smart use cases

Omdat smart use cases zo eenduidig en technologie-onafhankelijk beeld geven van de functionaliteit van een project, is het een goede eenheid om de complexiteit en omvang van het project in te schatten. Hiervoor is een eenvoudige schaal gedefinieerd; de meetlat waarlangs alle smart use cases in een project wordt gelegd. Deze schaal is als volgt gedefinieerd:

  • 1 – Piece of cake. Eenvoudige use cases, zoals selecties uit standaardlijstjes, of eenvoudige onderhoud, zoals Onderhouden Contracttypen.
  • 2 – Moderate. Reguliere use cases, bijvoorbeeld voor selecties uit iets uitgebreidere lijstjes. Denk hierbij aan Selecteren Account Manager per Regio.
  • 3 – Average. De gemiddelde complexiteit, die meestal wordt gegeven voor regulier onderhoud, zoeken, of eenvoudige rapportages. Voorbeelden zijn Zoeken Boek, of Beheren Klant. Dit is tevens de default complexiteit.
  • 4 – Hard. Wordt gegeven bij lastiger onderhoud of rapportages. Ook eenvoudige services, meestal zonder het wegschrijven van gegevens, krijgen vaak deze complexiteit. Denk aan Ophalen Contract of Overzicht Orders per Klant.
  • 5 – Very difficult. Use cases met deze complexiteit worden als lastig beschouwd. Meestal zijn dit uitgebreide rapportages, grafieken, al dan niet met drill-down, of complexere services waarbij gegevens worden weggeschreven. Denk aan Vastleggen Abonnement.
  • 8 – Extreme, but known. Deze complexiteit wordt bewaard voor de zeer lastige use cases. Het betreft hier bijvoorbeeld complexe berekeningen of samengestelde services die vaak het uitvoeren van een proces voor hun rekening nemen. In business intelligence projecten wordt deze complexiteit vaak gegeven aan use cases die datatransformaties uitvoeren. Denk maar aan Berekenen Prepensioen.
  • 10 – Extreme and unknown. Deze hoogste complexiteit wordt uitgedeeld om twee redenen. Enerzijds voor use cases die bewezen lastig zijn, zoals het importeren en exporteren van bestanden en berichten. Anderzijds geven we deze complexiteit op het moment dat we wel weten dat de use case complex is, maar nog niet goed kunnen definieren hoe complex dit precies is. In deze gevallen verplichten we ons deze use case nog nader onder de loup te nemen. Vaak komen hier nog additionele use cases uit naar voren.

Met behulp van deze snel toepasbare schaal, en de vele standaardtypen use cases die we in veel projecten zijn tegengekomen en die al eerder langs deze maatlat zijn gelegd, kunnen we snel en betrouwbaar de complexiteit van een project inschatten. Dit maakt smart use case schattingen herhaalbaar, en bovendien kunnen er gemakkelijk ervaringscijfers uit worden gedistilleerd voor komende projecten. Dit laatste is met name in organisaties die servicegeorienteerd gaan werken belangrijk, omdat daar meerdere automatiseringprojecten uitvoeren binnen eenzelfde programma. “Ons huidige project beslaat 298 smart use case punten.”

Niet zelden komen dit soort schattingen tot stand tijdens workshops, waaraan alle betrokken partijen deelnemen, zoals de klant, de gebruikers, de architect, analisten, ontwikkelaars en ook de testers.

IMG_02243

Workshop waarin de complexiteit van smart use cases door het team wordt geschat

Tijdens dergelijke workshops krijgt het (toekomstige) projectteam een goed en vooral eenduidig beeld van het project en de complexiteit van de requirements. Met name voor de klant, die niet altijd een reeel beeld heeft hoe complex de realisatie van zijn of haar wensen eigenlijk is. “Oei. Dit wordt toch veel lastig en duurder dan we hadden verwacht,” is een veel gehoorde uitspraak, “misschien moesten we eens onderzoeken of er alternatieven zijn.”

Verlengen voordeeluren

Vooruit dan. Om mijn bovenstaande beweringen kracht bij te zetten een laatste anecdote. Tijdens een recent project bij een grote openbaar vervoersonderneming realiseerden we een aantal bedrijfsprocessen rondom een nieuw type abonnement. Deze processen waren uitgemodelleerd in smart use case diagrammen, zowel voor de front end als voor de services.

Ongeveer halverwege het project, terwijl we inmiddels al een deel van de processen hadden geimplementeerd als smart use cases, kwam de opdrachtgever schoorvoetend met een verzoek. “Zouden we, als we toch ook dit nieuwe type abonnement implementeren, ook eens kunnen kijken naar het verlengen van de voordeelurenkaarten?” Bijna verschoot de opdrachtgever hierbij van kleur.

Vrijwel onmiddelijk organiseerde de projectleider een workshop waarin het verlengen van voordeelurenkaarten onder de loup werd genomen. Na twee uur modelleren bleek dat bijna het gehele proces was te realiseren door hergebruik van smart use cases die we al hadden. We hoefden slechts vier nieuwe smart use cases toe te voegen, met een geschat totaal van 16 smart use cases punten. Het behoeft denk ik verder weinig uitleg dat de klant snel besloot het verlengen van de voordeelurenkaarten toe te voegen aan het project. Dit is hergebruik ten top.

Inzicht en overzicht

Servicegeorienteerde projecten kunnen, met name in grote organisaties, enorm bijdragen aan de effectiviteit en efficientie van de bedrijfsvoering. Een mooi voorbeeld hiervan maakte ik bij een bank mee. Wanneer een klant van deze bank het onzalige besluit nam om te verhuizen, moest dit oorspronkelijk in 36 verschillende systemen worden vastgelegd. Door steeds meer van deze systemen met behulp van services te ontsluiten, werd dit ogenschijnlijk eenvoudige bedrijfsproces in de loop van enkele jaren en projecten teruggebracht naar een enkele administratieve handeling.

Servicegeorienteerde projecten zijn echter ook zeer complex van aard. Bovengenoemde bank had een aantal projecten nodig om de beoogde verandering te bewerkstelligen. Alhoewel smart use cases, en de bijbehorende standaardtypen en schattingstechnieken natuurlijk niet alle problematiek van dit soort projecten tot nul reduceert, dragen ze zeer concreet bij aan het inzichtelijk maken van deze complexiteit, door een eenduidige eenheid van werk te introduceren, zowel voor de front ends, als voor de achterliggende orchestratie en services. Als klapper op de vuurpijl is deze uniforme eenheid van werk ook nog eens naar behoren in te schatten, en onafhankelijk te testen. Als ik het In een notedop zou moeten samenvatten: inzicht en overzicht. Precies dat wat veel servicegeorienteerde projecten ontberen.