Validating sending mail messages in smart use case unit tests

Posted on February 12, 2013 by shoogend

When building applications with the Adf framework, smart use cases are implemented in task classes. Quite regularly mail messages are sent from tasks. To do so we use the MailManager class. Using this class mail messages are usually build up as in the following code example.

To send mail messages, the MailManager plugs in an implementation of the IMailProvider interface. Currently, Adf provides two mail providers, the obvious implementation SmtpMailProvider, and the DummyMailProvider, which creates the mail messages and dumps it in a specified directory.

Smart use cases, implemented in task classes, are always unit tested. Here, each of the public methods of the tasks are tested using the Adf.Test libraries from the framework. A number of test methods is usually implemented to test all possible scenario’s of going through the smart use cases. In the following code example, such as method is shown.

In this example, the Init() method of the task is called. After it is called the test framework can perform any number of checks. In this example, all validations should succeed, and the Status property of the Account domain object should be set to Unverified. The last validation ViewIsActivated will check if the accompanying (web, Windows RT) page or Windows form is presented to the user.

Recently, we have added new features to also validate whether a task has sent the mail message it was supposed to send. To provide for this functionality, we’ve added a TestMailProvider to the Adf.Test libraries. In your test project, this mail provider needs to be plugged in to the MailManager, as follows in code (or in the app.config file).

This will ensure that any mail messages being send by the tasks, is sent through the TestMailProvider. The test mail provider will, similar to the DummyMailProvider, place mail messages in a specified directory, but foremost it will also notify the TestManager that a message was sent.

Next, when unit testing the method that either sends, or doesn’t send the mail messages, you will be able to verify this, as in the following code example.

You can use the MailIsSent or the MailIsNotSent methods for this means.

Reaching post-conditions in tasks

Posted on December 6, 2012 by shoogend

Implementing use cases in Adf.Net is covered by the task pattern. Each smart use case in the model is implemented as a descendant of the Task class in Adf.Net.

The task pattern consists of three major parts:

Starting the task, either using a parameterized Init() method, or the default Start() method.
After a task calls another task, and this second task is finished, control goes back to the calling task, using any of the specific ContinueFrom() methods, or the default Continue() method.
When a task reaches any of the post-conditions of a task, the task needs to be ended, usually through the Ok() or Cancel() method.

In this specific post I’ll look at reaching the post-conditions. In the pattern, the Task class itself acts as the layer super type and implements a number of method to end itself. A use case can have multiple post-conditions. Some of them are positive, some can be negative. And sometimes a specific case needs to be addressed.

When a reaches it positive post-condition, it is a best practices to end it using the Ok() method. This method takes a params object[] p, which allows you to pass back results from the task to the calling task, using the following signature.

public virtual void OK(params object[] p);

A similar method Cancel() exists for task that end in a negative post-condition, usually because the user cancels the interaction:

public virtual void Cancel(params object[] p);

But, Adf.Net also supplies a similar method Error(), to allow tasks to finish with an error, possibly technical.

Under the covers, these three methods call on another method, which is called Finish(). This method takes care of passing back an instance of TaskResult. This result also gets posted back to the calling task, so it knows how the called task has ended. As in the following example, you could also use Finish() yourself.

if (persoon.IsNullOrEmpty())
{
    ValidationManager.AddError(GEENPERSOONGESELECTEERD);
    Finish(TaskResult.Error);
}

Please note that the code above is equal to the following code.

if (persoon.IsNullOrEmpty())
{
    ValidationManager.AddError(GEENPERSOONGESELECTEERD);
    Error();
}

By default, TaskResult has the following values in Adf.Net: Ok, Cancel, Error.

However, as TaskResult is implemented using the descriptor pattern, additional project specific value can be added easily, by inheriting from TaskResult, and added the specific values. Thus you would be able to end your task in more project specific ways, such as in the code example below.

if (persoon.IsNullOrEmpty())
{
    ValidationManager.AddError(GEENPERSOONGESELECTEERD);
    Finish(Dashboard8TaskResult.Aborted);
}

Agile business intelligence

Posted on October 28, 2012 by shoogend

Het besparen van kosten is een veelgenoemde aanleiding voor Business Intelligence (BI) projecten. Zo wilde een bekende overheidsinstantie weten hoe effectief de bestrijding van uitkeringsfraude was. Het onderzoeken van mogelijke fraude kost de instantie geld, maar het vinden van fraudeurs levert echter direct geld op. En dus ging zoekt de instantie naar de optimale verhouding tussen het aantallen onderzoeken en het aantal opgespoorde fraudes. Kortgezegd wilde men met zo min mogelijk onderzoeken zoveel mogelijk fraudeurs vinden.

Deze doelstelling is archetypisch voor BI-projecten. Hoewel de doelstellingen vaak concreet zijn te definiëren, is het realiseren ervan niet altijd evident. Welke rapportages moeten worden ontwikkeld? Wat staat daar op? Welke bronsystemen moeten worden geraadpleegd? Vaak wanneer het project eenmaal loopt, doen zich doorlopend nieuwe inzichten voor. Bijvoorbeeld over het ontbreken van benodigde informatie in bronsystemen. En anders doet de opdrachtgever wel inspiratie op voor nieuwe wensen en eisen uit feedback over opgeleverde rapportages en analyses. BI-projecten kenmerken zich vaak door onvolledige requirements en doorlopend voortschrijdend inzicht.

Op het gebied van aanpakken voor systeemontwikkeling hebben zich de laatste jaren enorme veranderingen voorgedaan. Steeds meer organisaties en projecten stappen over op een nieuwe generatie aanpakken, die voortschrijdend inzicht niet langer schuwen, maar juist omarmen. Ook kenmerkt deze nieuwe generatie aanpakken zich door multidisciplinaire samenwerking en het frequent in korte iteraties opleveren van software. In één woord: agile. De vraag is nu of en hoe deze aanpakken ook een positieve bijdrage kunnen leveren aan het uitvoeren van BI-projecten.

Wat kenmerkt BI-projecten?

De doelstellingen van BI-projecten zijn altijd direct business gerelateerd. Denk bijvoorbeeld aan het minimaliseren van verzekeringsfraude of het behouden van klanten. Tijdens een project worden analyses en rapportages gedefinieerd die ondersteunen bij het beheersen en optimaliseren van de bedrijfsprocessen van de opdrachtgever. Deze rapportages en analyses worden – meestal dagelijks – gevoed uit een datawarehouse. Kenmerkend voor dit type projecten is dat vaak lastig is vast te stellen welke concrete bijdrage deze analyses en rapportages uiteindelijk leveren. Neem voorbeeld de eerdergenoemde overheidsinstantie, waar niet op voorhand was uit te drukken hoeveel geld men kon besparen bij het vinden van de optimale verhouding tussen het aantal onderzoeken en het aantal gevonden fraudeurs. Uiteindelijk bleek in dit voorbeeld pas na afloop van het project dat de resultaten nog beter waren dan van te voren was geschat.

Hoewel vroegtijdig in projecten nog is vast te stellen welke analyses en rapportages benodigd zijn, is de exacte invulling hiervan nauwelijks concreet te formuleren. Wat wil de opdrachtgever nu echt zien in zijn rapporten? Neem als voorbeeld een rapportage over de verhouding tussen inkomende en uitgaande berichten bij een telecom-operator. Pas toen de opdrachtgever het rapport onder ogen kreeg, bleken er diverse soorten inkomende berichten te zijn, die ook weer gekoppeld zijn aan diverse soorten uitgaande berichten. Een typisch voorbeeld van voortschrijdend inzicht.

Een interessant fenomeen is ook het extractie-, transformatie- en laadproces (ETL). Hierbij worden in een aantal stappen de gegevens uit bronsystemen verzameld, geïntegreerd en geaggregeerd tot een formaat dat voor de rapportages en analyses benodigd is. In de meeste BI-projecten beslaat dit type werk circa tachtig procent van de ontwikkeltijd.

Toch blijft dit werk meestal helaas onzichtbaar voor de opdrachtgever. Deze concentreert zich – terecht – vooral op de op te leveren rapportages en analyses. Maar doordat de bulk van het werk in een BI-project op ETL is gefocust, worden meestal ook de fasen van een dergelijk project rond ETL ingericht. Dat wil zeggen dat eerst alle extracties worden ontwikkeld, aansluitend de transformaties, om vervolgens alle gegevens te laden. Pas nadat dit is gelukt worden de rapportages en analyses gedefinieerd, zoals weergegeven in onderstaande afbeelding.

Het gevolg hiervan is dat pas in deze laatste fase van het project iets wordt opgeleverd waarmee de opdrachtgever aan de slag kan. Dit heeft een belangrijk nadeel. Voor de opdrachtgever blijft het project lang onder water. Pas nadat veel tijd en geld is geïnvesteerd, kan de opdrachtgever feedback geven op de geproduceerde rapportages en analyses. Bovendien is de ETL dan al mind of meer volledig opgeleverd. Aanpassingen aan rapportages en analyses zijn nu lastig te realiseren. Ook is het niet uitgesloten dat als gevolg van deze feedback sommige stappen uit de ETL overbodig blijken. In dit geval is er zelfs werk voor niets uitgevoerd. Ten slotte komt het voor dat voor de gewenste rapportages en analyses gegevens nodig zijn die niet direct uit de bronsystemen zijn af te leiden. Aanvullende gegevens worden dan vaak handmatig toegevoegd tijdens de ETL. Vaak worden hiervoor gaandeweg het project kleine administratieve applicaties ontwikkeld. Nog los van het feit dat deze applicaties door de verkeerde ontwikkelaars worden ontwikkeld – BI-ontwikkelaars in plaats van softwareontwikkelaars – worden deze hiaten meestal pas laat in het BI-project ontdekt. Met alle gevolgen van dien. Zo uitgevoerd zijn veel BI-projecten duurder dan strikt noodzakelijk.

Wat kenmerkt agile?

In software development is afgelopen jaren een nieuwe generatie aan aanpakken ontstaan, die de best practices van eerdere generaties koppelen aan een sterk iteratief en coöperatief karakter. Deze aanpakken, zoals DSDM, extreme programming (XP), Scrum en Smart kenmerken zich in:

Korte iteraties. Project worden uitgevoerd in korte iteraties, variërend van twee weken tot een maand. Tijdens ieder van deze iteraties wordt een klein deel van de software geanalyseerd, ontworpen, gebouwd, getest en zelfs opgeleverd aan de opdrachtgever. Pas bij de start van een iteratie wordt vastgesteld welke functionaliteit tijdens de komende iteratie wordt gerealiseerd. Projecten verkorten zo de feedback lus met hun opdrachtgever. Dit verbetert de kwaliteit van de ontwikkelde software in hoog tempo. Dit in tegenstelling tot traditionele projecten, waar de software in een big bang wordt opgeleverd aan het eind van het project.
Compacte eenheid van werk. Om dit te kunnen bereiken hanteren projecten een eenduidige en kleine eenheid van werk. Er worden altijd meerdere workitems opgeleverd per iteratie. Individuele workitems leveren direct waarde opleveren voor de opdrachtgever.
Snel en frequent opleveren van software. Tijdens agile projecten wordt ook al tijdens de eerste iteraties workitems opgeleverd aan de opdrachtgever, al dan niet direct in productie. Dit zorgt ervoor dat mogelijke problemen, bijvoorbeeld rond architectuur of infrastructuur, al snel in het project boven water komen.
Incorporeren voortschrijdend inzicht. Anders dan in traditionele projecten, waar voortschrijdend inzicht zoveel mogelijk wordt uitgebannen, is het in agile projecten mogelijk en zelfs gebruikelijk nieuwe en wijzigende requirements direct mee te nemen. Dit kan doordat steeds bij de start van een nieuwe iteratie wordt vastgesteld welke workitems worden gerealiseerd. Nieuwe workitems kunnen nu al worden meegenomen, ten faveure over al eerder benoemde workitems.
Nauwe samenwerking klant en opdrachtnemer. Het snel en frequent opleveren van software in korte iteraties vraagt een intensieve samenwerking tussen opdrachtgever en opdrachtnemer. Er vindt bij voorkeur op dagelijkse basis overleg plaats, bijvoorbeeld om de nieuwe te realiseren workitems te analyseren.
Geïntegreerde testen. Omdat software frequent en al vroegtijdig wordt opgeleverd in projecten, is het testen van de workitems van cruciaal belang vanaf dag één in een project.

Scrum

Van alle agile aanpakken is Scrum verreweg de populairste. Niet zelden wordt Scrum met agile vereenzelvigd. De helderheid van de aanpak maakt Scrum een goed uitgangspunt voor projecten.

Een Scrum-project begint zodra de lijst met workitems is vastgesteld. Dit heet de product backlog. Meestal omvat deze een verzameling user stories. De backlog wordt vastgesteld door de vertegenwoordiger van de opdrachtgever, de product owner.

Iteraties, hier sprints genoemd, duren in de regel twee tot vier weken. Bij de start van een sprint wordt tijdens de sprint planning meeting door de product owner samen met het team de te realiseren user stories vastgesteld. Het team verdeelt deze in taken en schat de hoeveelheid werk hieraan in uren in. Op basis hiervan en op basis van de snelheid in vorige sprints en de samenstelling van het team in de komende iteratie wordt bepaald hoeveel stories er in de sprint passen. Deze stories worden op de sprint backlog geplaatst. Aan het einde van een sprint vindt de sprint review meeting plaats, waarin de gerealiseerde work items worden geëvalueerd. Aansluitend vindt de retrospective plaats, waarin het team de werkwijze evalueert en verbetert.

Scrum kent slechts een beperkt aantal rollen. Het werk wordt gedaan door het team, dat in de regel vijf tot negen personen telt en waarvan de individuele rollen niet zijn beschreven. De product owner vertegenwoordigt in het project de klant. Een Scrum Master coacht de product owner en het team. De voortgang in het project wordt bewaakt op een eenvoudig dashboard.

De eenvoud en populariteit van Scrum maken de aanpak een goed raamwerk voor startende projecten. De toegepaste terminologie uit de aanpak werkt aanstekelijk. Scrum is eenvoudig toe te passen en kan gemakkelijk waar nodig worden uitgebreid met technieken uit andere agile aanpakken.

Smart

In onze ervaring kan Scrum voor BI-projecten goed worden gestructureerd met elementen uit andere agile aanpakken, in dit geval Smart. Deze van origine Nederlandse agile aanpak kent meerdere typen iteraties. Bij de start van een project wordt de backlog gevuld met work items die voorwaardelijk zijn om software te realiseren. Denk aan het vaststellen van stakeholders en doelstellingen, het modelleren van bedrijfsprocessen, rapportages en analyses in smart use cases, het maken van een schatting op basis van deze smart use cases, het opstellen van een base line architectuur, het inrichten van de ontwikkelomgeving en het maken van een projectplan. Deze workitems worden gerealiseerd tijdens de voorbereidende iteraties Propose en Scope. De iteratie Propose mondt uit in een eerste projectvoorstel. Scope eindigt met het opleveren van het projectplan.

Na deze inleidende iteraties wordt de backlog gevuld met de gemodelleerde smart use cases, die de standaard eenheid van werk zijn in Smart. De smart use cases worden gerealiseerd tijdens een of meerdere releases. Een release bestaat uit een reeks van Realize iteraties, gevolgd door een Finalize iteratie. Tijdens Realise iteraties worden de smart use cases gerealiseerd, getest en geaccepteerd. Iedere release wordt afgesloten door een Finalize iteratie, waarin de nadruk nog sterker ligt op testen en op het stabiliseren van de code.

Iedere iteratie heeft in Smart dezelfde opbouw. De iteratie start met een kick-off Plan en eindigt met de retrospective Evaluate. Daartussen worden de work items gerealiseerd tijdens Build.

In Smart telt het team meerdere rollen. De belangrijkste zijn projectsponsor, gebruiker, domeinexpert, ontwikkelaar, tester en coach. Smart doet het goed in langlopende, vaak wat complexere projecten zoals BI-projecten, waarin het meer structureren van rapportages en analyses in smart use cases beter past dan eerdergenoemde user stories. Smart use cases zijn direct gerelateerd aan de bedrijfsprocessen van de opdrachtgever. Bovendien worden ze gemodelleerd en geschat op basis van een reeks aan standaardtypen, zogenaamde stereotypes. Er zijn al stereotypes beschreven voor bijvoorbeeld stappen in ETL, rapportages en analyses.

Snel en frequent opleveren

Het snel en frequent opleveren van voor de opdrachtgever relevante software is een aspect van agile dat in BI bijzonder goed van pas komt. In plaats van de verticale fasering van traditionelere BI-projecten, kiezen we ervoor om het realiseren van analyses en rapporten juist horizontaal in te steken. Niet langer worden eerst alle extracties en aansluitend de transformaties en het laden van de gegevens opgeleverd om pas daarna de rapportages en analyses te ontwikkelen.

Liever ontwikkelen we per rapport of analyse. Hierbij kiest de opdrachtgever steeds welke rapporten of analyses de hoogste prioriteit hebben, en werkt het team uitsluitend aan de minimale set aan smart use cases die nodig zijn voor om deze te realiseren. Deze representeren de benodigde extracties en transformaties en natuurlijk het rapport zelf. Deze kanteling van werkzaamheden maakt directe feedback van de opdrachtgever mogelijk. Belangrijk bijkomend voordeel is dat de rapporten en analyses direct kunnen worden aangewend om de bedrijfsprocessen van de opdrachtgever te verbeteren. Soms al enkele weken na de start van het BI-project. Zo toont het project al op heel korte termijn benefits.

Zo wordt voortschrijdend inzicht nu eens niet uitgebannen, zoals traditionele, maar worden nieuwe inzichten direct meegenomen. Hoewel in principe tijdens een lopende iteratie de scope niet wijzigt, kunnen nieuwe requirements al tijdens een eerstvolgende iteratie op de rol worden gezet. Zodra de opdrachtgever de eerste versie van een rapportage of analyse onder ogen krijgt, formuleert hij direct zijn feedback, die dan vrijwel direct wordt geïmplementeerd – denk daarbij bijvoorbeeld aan het realiseren van data entry voor ontbrekende gegevens.

Compacte eenheid van werk

Kort gezegd is een BI-project uit te drukken in drie typen ontwikkelwerk: datamodellering en ETL, het definiëren van analyses en rapporten en het ontwikkelen van aanvullende data entry applicaties. In Smart is de smart use case de leidende eenheid van werk. Zowel voor het modelleren van bedrijfsprocessen en requirements, en voor het schatten, realiseren en testen van voor de gebruiker relevante functionaliteit. Voor het modelleren van smart use cases beschikken we over richtlijnen, die ertoe bijdragen dat smart use cases een lage granulariteit kennen en al tijdens Propose en Scope zijn te modelleren. Er is bovendien een groot aantal stereotypes beschreven die het modelleren, schatten en realiseren standaardiseren en vergemakkelijken. Voorbeelden hiervan zijn manage voor data entry, search voor het zoeken naar record of file import.

Hoewel afkomstig uit reguliere software development, blijken smart use cases ook prima aan te wenden voor agile BI-projecten. Wat betreft het definiëren van rapportages en het ontwikkelen van aanvullende data entry ligt dit voor de hand, omdat dergelijk werk niet wezenlijk verschilt van reguliere software development. Maar ook voor het vaststellen van analyses en zelfs voor het uitvoeren van ETL zijn use cases stereotypes vastgesteld, zoals collect, integrate en aggregate.

Smart use cases worden al vroeg in een agile BI-project gemodelleerd, tijdens Propose en Scope. Daarbij worden de smart use cases slechts geïdentificeerd en geschat. Details worden pas uitgewerkt tijdens latere iteraties. Aansluitend worden Realize en Finalize iteraties ingepland. Tijdens deze iteraties ligt de focus op het realiseren van individuele rapportages, op basis van de hiertoe benodigde smart use cases voor ETL, eventuele data entry en de definitie van het rapport.

De benodigde smart use cases worden zo snel mogelijk gerealiseerd en met de opdrachtgever afgestemd. Bijkomend voordeel is dat de onderliggende dataflows, die nu zijn uitgedrukt in smart use cases, goed individueel te testen zijn, en zelfs is door het modelleren van de use cases hergebruik van dataflows snel geïdentificeerd.

In BI-projecten is het snel en frequent opleveren van nieuwe rapportages en analyses van groot belang voor de opdrachtgever. Immers, ieder nieuwe rapportage kan direct worden benut in de praktijk en levert zo direct toegevoegde waarde aan het optimaliseren van de bedrijfsprocessen van de opdrachtgever. Daarnaast hebben BI-projecten veel baat bij het voortschrijdend inzicht dat ontstaat dankzij de korte iteraties in agile projecten. Beter dan dit uit te bannen, zoals traditioneel wordt getracht, is het om juist effectief gebruik te maken van deze inzichten en feedback.

Dashboards en burn-down-charts

Om agile projecten te beheersen en de voortgang te bewaken wordt in de regel gebruikt gemaakt van een tweetal pragmatische gereedschappen; een agile dashboard of taskboard en een burn-down-chart. Alle te realiseren workitems doorlopen een levenscyclus, die de stappen uit het realiseren ervan beschrijft, doorgaans in enkele dagen tijd. Voor smart use cases telt deze levenscyclus stappen als New, In Iteration, Working, Testing, Rework en Accepted. Doorgaans breiden projecten deze cyclus uit naar gelang de projectspecifieke werkwijze dit verlangt. De stappen in de levenscyclus van workitems of smart use cases vormen de kolommen op het dashboard of taskboard van een agile project.

De meeste agile projecten gebruiken voor dergelijke dashboards post-its aan de muur, of een online gereedschap. In een oogopslag is zo, ook voor de opdrachtgever, te zien wat de voortgang van de smart use cases is.

Omdat de omvang van smart use cases worden geschat in punten, is bij ieder statuswijziging snel na te gaan hoeveel werk nog nodig is om de onder handen zijnde rapportages en smart use cases te voltooien. Zodra een smart use cases is geaccepteerd, krijgt het team de bijbehorende punten. In agile BI-projecten is het daarbij belangrijk dat ook de “back end” smart use cases die stappen uit de ETL of data entry representeren door de opdrachtgever worden geaccepteerd. Dit kan bijvoorbeeld gebeuren met de opdrachtgever de resultaten van dergelijke use cases in de reporting tool te demonstreren.

Een burn-down-chart toont een dagelijkse momentopname van deze punten, uitgezet in de tijd. Met een eenvoudige extrapolatie is nu de verwachte einddatum van het project te calculeren.

In agile BI-projecten is het overigens niet alleen zeer zinvol een burn-down-chart te gebruiken voor het gehele project, maar ook om per te realiseren rapport en analyses deze voortgang te projecteren. Juist omdat de rapportages individueel worden opgeleverd, leveren deze laatstgenoemde burn-down-charts de opdrachtgever directe informatie over wanneer het nieuwe rapport is in te zetten in het besturen van zijn bedrijfsprocessen.

Snel resultaat

Agile aanpakken zoals Scrum en Smart spelen bijzonder goed in op de snel wijzigende en uitbreidende wensen en eisen van opdrachtgevers aan BI-projecten. Daarbij wordt in korte iteraties aan het “goed genoeg” opleveren van individuele rapporten en analyses gewerkt. Zo heeft de opdrachtgever al veel eerder profijt van zijn BI-project, en kan voortschrijdend inzicht sneller en goedkoper leiden tot een optimaal eindresultaat. Het toepassen van smart use cases biedt BI-projecten daarnaast een gestructureerde, maar vooral pragmatische manier om met eenzelfde eenheid van schatten, realiseren en testen te opereren, die bovendien direct te relateren is aan de bedrijfsprocessen van de opdrachtgever. De pragmatische gereedschappen die in agile projecten worden gebruikt om de voortgang te meten, zoals agile dashboards en burn-down-charts per rapport, bieden bovendien direct inzicht in de realisatie van de rapportages en analyses. Agile BI biedt daardoor snel resultaat met snel groeiende tevredenheid van de klant. En daar was het allemaal om te doen toch?

Dit artikel verschijnt in het themanummer Agile Datawarehousing van maandblad Informatie

Sander Hoogendoorn
Principal Technology Officer en Agile Thoughtleader Capgemini, auteur van de boeken Dit Is Agile (agile, Scrum, Smart) en Pragmatisch Modelleren met UML (smart use cases).

Sandra Wennemers
Principal Consultant en Data Warehouse Architect Capgemini

Zie ook www.smartusecase.com en www.ditisagile.nl

Agile anti-patterns. Yes you agile projects can and will fail too

Posted on May 8, 2012 by shoogend

Over the years I have noticed a lot of agile anti-patterns during projects. Wrongly used agile approaches, dogmatic use of agile approaches, agile-in-name-only. Recently I have presented a talk at a number of agile and software development conferences that demonstrates patterns of agile misuse. These conferences include Agile Open Holland (Dieren), Camp Digital (Manchester), GIDS (Bangalore), ACCU (Oxford) and Jazoon (Zurich). Anyway, here’s the slide deck. Enjoy.

Agile Anti-Patterns. Yes your agile projects can and will fail too.

View more PowerPoint from Sander Hoogendoorn

How to kill your estimates

Posted on April 14, 2012 by shoogend

It must have been about twenty five years ago. I was working for a large international consultancy firm. One of the reliable ones. The ones that you would think that had everything worked out. But I guess this was merely the product of my imagination.

At one time two colleagues and I were working on an estimate for a bid for a software development project. Now the three of us together, despite the fact that this occurred long time ago, had quite some years of experience in the field. So you would reckon we could come up with a decent estimate. And we did. In fact, we created two estimates. One by counting screens, based on a point scale and a real-life velocity. A very popular and suitable technique as we were building desktop applications. Next to that we created a work breakdown structure. Using both techniques we estimated ALL the work in the project, not just coding or coding and testing. Not much to our surprise the results from both estimates were comparable. Happy and confident with the result, we presented our estimates to the account manager in charge.

It was at this particular point in time, at that very instant, that my faith and trust in our industry vanished into thin air, not to return again. Not even more than glancing at the work we’d invested in our estimates, the account manager merely looked at the end result and added 20% to the overall price for the project. For contingency, he claimed.

Up to this deciding moment in my career I had never even heard of the word. Contingency. And still I refuse to stop and think what the impact of that little word is to this industry and probably others too. To sum it up, every confident estimate can be killed by (account) managers adding seemingly random percentages. Just because they don’t trust your estimates. Or they still remember the court cases from previous projects. Frightening all together.

Needless to say we lost the bid. Our competitors were less expensive.

History revisited

Now I wouldn’t write about this unfortunate event if I hadn’t met a similar situation only a few weeks ago. You might imagine we’ve learned a thing or two in the twenty five years since. Alas. We didn’t. And it’s industry wide I assume.

With a small team we had worked on an estimate for re-engineering a client/server desktop application to a .Net web application. We estimated based on smart use case points, a technique that we have used and refined over the years. A reliable estimation technique. The estimate resulted in just under 500 smart use case points, which is a measure for the size and complexity of the system. Given the fact that we have executed multiple similar projects successfully we were able to establish that it takes about 8 hours per smart use case point to realize the software. And yes, we have actually gathered metrics! These 8 hours include ALL work on the project, including project management, documentation, testing, setting up the development environment etc. Simple calculation tells us that we would need 4.000 hours to do the project. So this was what we coughed up for the responsible account manager.

Without so much as a blink of the eye an email came back from the account manager stating that he added 20% to our estimate, and that he would communicate this new number to the client. Leaving us with a lot of questions of course.

So the interesting question is: where does the 20% come from? You would expect that it originated from having evaluated software development projects for years and years, and comparing original estimates in those projects with the final outcome – given the fact that requirements change, teams change and technology changes. But to be quite honest, unfortunately I suspect this is not case. There’s but only a few organizations that actually measure like this. I assume. And then even if he had done that, would it be exactly 20%? Why not 17.6? Or 23.17? Exactly 20%? Or maybe the account manager knows his statistics. Statistics claim that developers estimate 20% too optimistic. As we developers are optimists. But this was a team estimate including all work on the smart use case on the backlog.

Yesterday’s weather

To cut to the chase, if a team estimates the amount of work in a project, especially on a relative scale, as an account manager this is what you should believe, as it is the best estimate available. This is the yesterday’s weather principle. The best way to predict today’s weather, is to look at the weather from the day before. No more, no less.

Adding 20% – or 10% or 15% – just as a rule of thumb is not based on any real-life experience. In my opinion such actions show that the account manager puts no trust in his own people, in his own organization. This would be similar to saying that if it was 10 degrees yesterday, we’ll just state that it will be 7 degrees today, without having looked at the weather forecast.

Restore trust

So what’s the message here? Please dear account managers, put some trust in the people who try to create as estimate as accurate as they can. Don’t add 20%, or 10% for that matter, just based on gut feeling. And more important, dear software developing organizations, start measuring your projects! Gather metrics so future estimates become much more accurate and realistic, and future project proposals and project will be less off target than so many projects I witness. And on the fly restore some of the trust so many people have lost in our industry. Let’s learn.

This post is published in SDN Magazine.

Death by Dogma versus Agile Assembly

Posted on November 4, 2011 by shoogend

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

View more presentations from Sander Hoogendoorn

Flower-Power Agile Fluffiness

Posted on September 8, 2011 by shoogend

To all the dear people in the agile community and to the faint-hearted: this will not be an easy blog post. There was a time when being a software developer was a decent craft, requiring decent craftsmanship and yes also a lot of creativity, some communication, some collaboration. Still it was a decent craft. The waterfall-ish methodologies we used weren’t extremely optimal, but at least software development was a craft. Similar to a carpenter who uses his tools to craft new furniture, or a industrial designer using his tools to come up with a new model Toyota – I know this is not the best example, but at least I now have the attention of the kind folks in the lean community. And then came agile.

Now believe me, I don’t have anything against agile. I’ve been promoting agile and iterative approaches to software development since the mid-nineties, and haven’t done traditional projects ever since. Agile used to be about engineering. We were improving ourselves by using better techniques, continuous integration or continuous deployment, writing unit test, pair programming, writing smart use cases or user stories, using a bug tracker, burn-down charts and even post-its on the wall. So far, it’s still all in a days work. There was a time that as an analyst, a developer, or a tester you could be proud of being in an agile project.

But these days if I look at what’s going on at agile conferences, on twitter, in blog posts, literature and discussions on agile, Scrum, Lean, Kanban and whatever new flavors of the month are passing by, I get the feeling I’m no longer talking about craftsmanship but rather ending up in Disneyland or in San Francisco in the late sixties. I’ve got a feeling were not in Kansas anymore.

Agile coach at work.

Agile community anti-patterns

Certainly it’s a good thing everybody can join the agile community. But I witness a lot of repetitive behavior I strongly discourage. Let’s name this repetitive behavior agile community anti-patterns – not to confuse with agile anti-patterns. The latter merely describe failures in agile projects, and yes these do occur, while the former describe community failures. Let me sum some up for you – while on the fly breaking my first anti-pattern:

Metaphorizing
Zenify
Kindergarten Agile
Open Door Wisdom
Scrumdamentalism

Allow me to elaborate a bit on these agile community anti-patterns.

Metaphorizing

Although I’m not sure metaphorizing is a even good English word, I’m quite sure you get the meaning of it. Everything anybody comes up with these days about agile – or about what people think is agile – is immediately turned into a metaphor or is given a silly name.

Can we please stop talking about the Gemba Walk when we mean that it’s a good thing our manager stops by every now and then? This shouldn’t even have a name.

Japanese manager stopping by.

What does it mean when an agile specialist states that “you should verify the five why’s with the reverse loop”? And what about Feature Injection? According to a recent tweet “feature Injection is more about using examples to discover the relationships you need and missed or got wrong.” Call me old-fashioned but I totally miss what this is about.

Zenify

Yes, I know lean manufacturing started in Japan at Toyota. So there is a link between agile and Japan. But is that an argument to zenify software development?

Our new Feng Shui office space.

Why do we need to explain roles in a software development project as samurai, sensei or roshi. I thought product owner and agile coach were already abstract enough. What about re-arranging our office in a Feng Shui manner? Also the word kaizen seems to become very popular. Quoting a recent tweet: “Just write down small things on small papers. It’s your kaizen.” Although I’m all for small things what does this mean and why do I need to introduce this in my project?

Kindergarten Agile

Not sure about the average level of maturity of people in agile projects around the world, but in the projects I’ve been in the last decade or so, people where pretty mature. So why is it groups of sensible people at unconferences are discussing the Happiness Index of projects? To me this sounds much more like a weekly column in a women’s magazine than a solid engineering practice in a software development project.

And I for one certainly don’t want to have to pass a baton if the flow in my stand-up meeting or scrum isn’t achieved automagically. Still this was seriously recommended by one of the authorities in the agile community during a recent presentation at a conference.

Some tweets to further illustrate my point? If someone says “Add Ready for Celebration before the Done column on your wall board” should I start decorating the office? It makes you wonder how often his projects get things done. Even worse is “Make sure you don’t miss the agile elephant versus the waterfall elephant in the lobby.” which was tweeted from a recent agile conference. Where was this conference held? At the Toys-R-Us?

Participants at a recent agile conference strolling down the exhibition hall.

Open Door Wisdom

Often I see quotes coming from the agile community that are no more than open doors, and have been open doors in projects for decades and perhaps centuries, but that are treated by others in the community as sources of new and ultimate wisdom.

Recently a speaker at an agile conference claimed that “if your retrospectives don’t add value to your project, you should change your retrospectives.” Duh. The speaker got a loud applause from the audience, he is now considered an absolute guru, and his quote got tweeted and re-tweeted all over the world. This is not even an open door, it’s an open gate.

Scrumdamentalism

Now I’ve blogged about Scrumdamentalism before, but with the newer generations of agile converts, some communities are getting more and more populated by religious zealots who will treat their newly gained faith with deep fundamentalism. Any best practice from their own belief is treated as mandatory, while followers from other beliefs are often considered heretics. A recent blog post states that: “A technical project manager can be a good product owner if he sticks to managing the product backlog and abiding by the rules of Scrum.” I wasn’t aware that Scrum even had rules. You learn something new everyday.

And if Scrumdamentalism alone isn’t bad enough already, it is even enforced by the so-called leaders themselves, proven by the following horrible quote “the team needs to listen to god talk and follow the commandments” from one of the Great Leaders in this particular community. Dear agilists there is is no one-true-belief. There’s value in all of them. And also can we please abolish the function title Agile (or Scrum or Kanban or Lean) Evangelist. Moreover, people calling themselves Agile Sensei should be banned from conferences and projects if you ask me.

Flower-Power Agile Fluffiness

Please people can we stop adding all this new age Flower-Power fluffiness to agile. In my opinion the agile community with all it’s great ideals and best practices is slowly degrading into a worldwide Luna park. My guess is I that it won’t be long before someone somewhere will suggest to add a psychotherapist to every software development project. “How do you feel about not being able to get your user story to the Ready for Celebration column?” Or plan a clown’s visit during retrospectives to increase the Happiness Index.

Agile retrospective with product owners present.

We are slowly becoming the laughing stock of the engineering world. I long for the time that we re-introduce engineering in our trade, and all go back to work again.

Scrumdamentalists and crusaders

Posted on June 29, 2011 by shoogend

After having promoted agile and iterative approaches to software development projects for over a decade, I finally find that, like Bob Dylan says, the times they are a-changing. And for the better. Many small and large organizations and enterprises are now turning towards agile approaches, often to compensate for years and years of failing projects. You might suggest that all’s well that ends well . But…

With the growing success of agile approaches new patterns and anti/patterns arise. Implementing agile well, although promoted as being easy by many, isn’t that easy. It’s actually quite hard to get it right. Implementing agile well is a learning process, just like learning to ride a bicycle well, or learning how to master a programming language. This is where coaching on the job can and should play an important role.

Pokemon Trainers and Jedi Knights

But good agile coaches are scarce these days. So many companies jump into this growing gap and send of there consultants to far away agile training courses. Inexperienced or at most with little experience these suddenly acclaimed Scrum Masters, Lean Certified Project Managers, Pokémon Trainers and Jedi Knights are now pushed into the marketplace.

Let me predict you that this explosion of these new gurus will lead to massive agile project failure. Allow me to explain. As with most religions, people just entering the new belief tend to be far more fundamentalistic and dogmatic about their new faith than people who have lived in the same religion for years. Newbies will apply the religion’s commandments far more literally than they are meant – as the elders know. And moreover, these newbies will see there new religion as the only true source of knowledge, denying the value in other religions.

In a sense you might say we’re in the Agile Middle Ages. The new agile fundamentalists are like crusaders, full of enthusiasm, heavily armed, not very adapted or open to the new world they travel too, but with an urge to strike down all non-believers.

Agile fundamentalist in the field

Scrumdamentalism illustrated

This fundamentalism is best witnessed in the Scrum community. Personally, I like Scrum a lot, but too often I see Scrum certified coaches making remarks about what is and what isn’t Scrum, and even worse: what is and what isn’t agile. Let me illustrate my statement with some real-life examples.

In many projects, especially the more enterprise projects, I prefer modeling smart use cases and use these as unit of work, estimation, development and testing way over the more unstructured user stories. At quite a few occasions Scrumdamentalists have come up to me and claim that you must use user stories, otherwise you’re not doing Scrum, but instead you are doing waterfall. Modeling doesn’t seem to be allowed anyway in a Scrum project, if I believe my Scrumdamentalists. Now I haven’t read the little Red Book of Scrum, but I’m pretty sure Scrum doesn’t really push user stories as being mandatory, nor forbids modeling.

Another great example followed a picture I tweeted of my current project’s dashboard during a week when our tester was on holiday. Clearly the list of work items to test was larger than the other columns. My picture led to a remarkable comment from a certified and even experienced Scrum Master that all team members should automatically take over each others work when someone is offline. And if we didn’t do that we were not doing agile, but were doing waterfall instead.

Yes I do consider that taking over each others work is good practice, but to a certain extent. I don’t know about your project, but in my project testing is serious business, with serious techniques, that requires serious expertise. Testers do totally different work than analysts or developers. I don’t see any of my C# developers creating process cycle tests or writing functional test cases. Or even worse, the other way around. Would you seriously consider a tester to learn how to write C# code, just because one of the developers spends a week on the beach? So I guess I’m in a waterfall project.

IMAG0024
A non-proper agile dashboard

And if you think this was the low point of my experiences, another Scrumdamentalist overlooked the picture I posted and noticed that my project has different and more stages a work item goes through than the task board he considered obligatory. We had stages such as developer testing, testing, accepting and approving, while he said that you only have to-do, working and done on a proper task board.

And dear people, is it really necessary to call an iteration a sprint, and a stand-up meeting a scrum to make my project successful?

Process fits project

I strongly believe that this agile fundamentalism and dogmatic thinking is going to stop progress and productivity. It ignores on of the basic principles that makes agile such a strong proposition – namely to improve on your process and techniques continuously to make the process fit your project, and not the other way around.

Dear people in the agile communities, please don’t try to become holier than the pope. Being agile means not trying to be dogmatic. We are not looking for the holy grail. There is no one true agile religion I’m afraid, there’s value in all of them. As the agile manifesto clearly states: we are uncovering better ways of developing software by doing it. So go out and explore.

How Smart Use Cases Can Drive Web Development. Video for session at DevDays 2011 [in Dutch]

Posted on May 9, 2011 by shoogend

as the Channel 9 website says: using real-life code examples Sander will demonstrate how to model, generate and build smart use cases and introduce the positive impact smart use cases have on your layered software architecture.

Anyway, here’s the video for my DevDays 2011 session:

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

Posted on March 15, 2011 by shoogend

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.

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.

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.

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.

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.

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.

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.

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..

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.

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.