Capgemini heeft voor Equihold een .Net-versie gemaakt van hun sport erp-programma 1-2Focus. Equihold is vanaf het begin niet tevreden over de software en spreekt uiteindelijk over slechte spaghetticode. Dat wordt ten stelligste ontkent door Capgemini. In mijn vorige artikel, ‘Capgemini 1-2Focus: installatietest’, heb ik beschreven dat het installeren van de 1-2Focus software weliswaar mogelijk is, maar het meestal moeizaam gaat en het niet iedereen zal lukken om de software te installeren. Maar als die horde is genomen, hoe stabiel en gebruiksvriendelijk is de software dan verder?
In het contract met Capgemini en bijbehorende documenten zijn voor 1-2Focus onder andere de volgende eisen en uitgangspunten vastgelegd.
– Het programma moet gebruiksvriendelijk zijn (be easy to deploy, be easy to upgrade).
– De software functionaliteit moet modulair in de markt gezet kunnen worden. Een versie waarbij niet alle modules geleverd zijn, moet dus gewoon kunnen werken.
– De software moet van hoge kwaliteit (high quality) zijn.
Bij het testen is bekeken of de software globaal voldoet aan de algemene eisen die aan software gesteld mogen worden.
De applicatie
De applicatie ziet eruit als een typische Microsoft Windows XP applicatie. Dat is te verwachten omdat het om een .Net-applicatie gaat, die met Microsoft tools gemaakt is. Er is een behoorlijke handleiding van 91 pagina’s. Bovendien kun je via de frequently asked questions (faq) een bijbehorend instructiefilmpje starten, zoals bij veel erp-programma’s.
Het hoofdmenu volgt grotendeels de bedoelde modulaire opbouw. De trainer krijgt de modules ‘Management’ voor rapporten en contacten, ‘Sport’ voor onder meer competitie, team(samenstelling), trainingen, agenda, wedstrijden, activiteit spelers en spelersevaluatie, ‘Wedstrijden’ voor onder andere video bibliotheek, actieschema ten behoeve van wedstrijdevaluatie, wedstrijden, presentatie van geselecteerde fragmenten en ‘Admin’ voor bijvoorbeeld het maken/aanpassen van formulieren, de back-up en rapportages.
Irriterende bugs
Je ziet meteen veel slordigheidjes als je door de menu’s heen loopt. Bij het programma was Nederlands als taal ingesteld, maar op veel delen van het programma moet je met de Engelse taal werken zonder dat dit voor de hand ligt. Zo is de submodule ‘Agenda’ grotendeels in de Engelse taal. De submodule ‘Training’ is ook grotendeels in het Engels. Het aanmaken van personeelsgegevens gaat deels in het Engels. Ook zijn er wat typefouten.
Als je eenmaal met de applicatie gaat werken, dan zie veel meer foutjes. Datums kun je niet altijd rechtstreeks intypen, maar moet je geheel of gedeeltelijk aanpassen via het bekende MS de mini agenda. Als je de geboortedatum moet invullen van iemand die decennia oud is; dan ben je even bezig met scrollen.
De submodule ‘Agenda’ laat je niet meteen een team selecteren waarvan je een activiteitenoverzicht wilt hebben. Je moet eerst de optie ‘Training Selectie’ afvinken en weer aanvinken, voordat je één of meerdere teams kunt selecteren.
Bij de submodule ‘Spelersactiviteit’ kun je aangeven dat een speler absent is vanwege ziekte. Maar je moet daarvoor een reden opgeven voordat dit opgeslagen kan worden. Als je niet weet waarom iemand ziek is, verzin dan maar wat.
De ‘Bibliotheek’ met standaard trainingssessies is leeg of niet benaderbaar. Dat was eerder niet zo.
Irritant is ook dat sommige foutmeldingen worden herhaald en sommige foutmeldingen ten onrechte worden getoond. Veel van die fouten staan in clusters. Bijvoorbeeld, het type actie (event) van een speler kan worden gedefinieerd via het ‘Actieschema’ (in de applicatie Event schema). Wijzig je een actietype in het actieschema, dan krijg je vier keer achter elkaar dezelfde foutmelding ‘Opslaan van het event is mislukt’, ook als achteraf blijkt dat de actieomschrijving wel is vastgelegd. De foutmelding moet je vier keer wegklikken. Één keer waarschuwen is voldoende zou je zeggen en uiteraard alleen als het echt nodig is. Bij het wijzigen van de voor- of achtergrondkleur in het actieschema krijg je dezelfde foutmelding en ook vier maal. Dat geldt ook voor het koppelen van een tegenactie (zoals storen) aan een actie. Ook het koppelen van een bepaalde standaardactie aan een hot key geeft ten onrechte weer vier keer de bekende foutmeldingen.
Het opslaan van een mutatie kan de ene keer via een te verschijnen opslaan button en de andere keer alleen via de menubalk. Dat is allemaal niet bepaald bevorderlijk voor de acceptatie van de software, maar het zijn nog geen echte afknappers. Die zijn er helaas wel.
Blocking bugs
De ‘Rapportageontwerper’ (Report Builder in de applicatie) van de managementmodule start niet op; meteen een blocking bug.
Bij jeugdvoetbal zijn er afwijkingen ten opzicht van de normale regels voor volwassenen, bijvoorbeeld qua aantal spelers (maximum en minimum), aantal te wisselen spelers en de speeltijd. Voor een oefenwedstrijd moet je vrijheid krijgen. En dus moet je de tijd zelf kunnen instellen. Maar dat lukt niet.
Als je een oefenpotje wilt agenderen, dan hoef je niet voldoende spelers ter beschikking te hebben, zoals bij een competitiewedstrijd, maar dat lukt niet.
Spelanalyse van wedstrijden en oefeningen is in de topsport van groot belang. Dat betekent dat acties aan videofragmenten gekoppeld worden, bij voetbal van aftrap, doelpunt of een rode kaart van spelers. Die acties worden in het actieschema vastgelegd. Je hebt standaard acties en lege acties die men zelf kan definiëren, de ‘Eigen acties’. Ik heb bijvoorbeeld de ‘Swalbe’ toegevoegd. Dit lukt niet bij elke installatie. Toen ik de volgende eigen actie toevoegde, ging de veldwaarde terug naar de oorspronkelijke staat. Toevallig kwam ik er achter dat als ik eerst de voorgrondkleur aanpaste, ik daarna alsnog een extra ‘Eigen actie’ kon definiëren voor ‘Op de voet trappen’. Ik wilde daarna nog eens op die manier ‘Tijdrekken’ toevoegen, maar dat lukte niet meer. Dus werking van deze bug is niet te voorspellen.
De actie die je aan een spelmoment wilt koppelen kun je aanklikken op een Notatiebord (in de applicatie Notation board) onder het venster voor het afspelen van de video. Dat is handig voor spelanalyse. En je kunt dit uiteraard ook doen met hotkeys die je zelf kunt definiëren. Maar hot keys aanpassen voor een ‘Eigen actie’, kan weer niet, net als nog een aantal andere opties ook niet bij zo’n actie aangepast kunnen worden.
De acties die je koppelt aan een speelmoment kunnen ook aan de plek van het speelveld worden gekoppeld. Ook dat is handig voor spelanalyse. Daarvoor wordt er een schema van het speelveld getoond. In de voetbalversie wordt echter een hockeyveld getoond en die heeft een duidelijk andere indeling dan een voetbalveld.
Voor de liefhebbers, de filmpjes van de genoemde bugs zijn te zien op de website van Capclaim, de juridische entiteit die strijd voert tegen Capgemini.
Voor de gebruikers waren niet alleen de bugs een groot probleem, de leading costumers hebben moeten ervaren dat sommige bugs na een update weer verschenen. Of dit komt door slecht versiebeheer van de source of door de complexiteit van spaghetticode, dat weet ik niet. Het zou niet mogen voorkomen.
Eindconclusie vanuit de gebruiker gezien
Versie 9 is de beste versie die door Capgemini is gemaakt. Toch blijkt het programma in de praktijk niet geschikt te zijn door vele hinderlijke fouten en doordat belangrijke functionaliteit niet beschikbaar is door technische fouten. Die fouten zijn vooral in de submodule ‘Actieschema’ te vinden. Zoveel ernstige fouten bij elkaar kun je als leverancier bij het testen onmogelijk over het hoofd hebben gezien. Capgemini heeft dus niet volgens afspraak de technische tests en functionele tests uitgevoerd. Het had moeten gebeuren en daar is ook voor betaald. De software is slechter dan alle Bèta software die ik in de loop der jaren heb getest. Versie 9 komt over als een Alfa-release, om aan een klant te laten zien wat de software kan gaan worden. Het is gewoon absurd dat Capgemini bij release 9 nog steeds geen stabiele en volledig functionele software heeft weten te bouwen.
Jaap van Belkum, zzp’er
ICT Faalindustrie?
Diverse experts hebben inzake het 1-2Fcousproject zich reeds eerder negatief uitgelaten over de kwaliteit van de code, de toepassing van Rational Unified Processing (RUP) in het ontwikkeltraject en het door Capgemini gevoerde project- en kwaliteitsmanagement en de bijbehorende transparantie van de communicatie. Achteraf is de mislukking goed te verklaren; een contract dat op twee tegenstrijdige gedachten stoelde, slecht projectmanagement, slecht kwaliteitsmanagement, slechte en verhullende communicatie, slechte invulling van de zorg naar de klant. Het eindresultaat is kreupele software waarmee niet gewerkt kan worden. En Capgemini eist nog meer geld voordat zij de bugs oplossen.; in die zin mag 1-2Focus crippleware genoemd worden.
Is dit een voorbeeld van falen, nee het gaat verder dan dat. Zo complex was de opdracht niet voor een bedrijf als Capgemini. Capgemini had meer dan voldoende expertise, capaciteit en ervaring in huis. Natuurlijk, Capgemini had nog heel weinig ervaring met offshoring, maar vanuit projectmanagement hadden die risico’s adequaat gedekt kunnen worden.
Helaas hebben ze de problemen naar het onervaren en kleine Equihold doorgeschoven. Tenslotte, wat wist Equihold van Rup en offshoring en hoeveel mankracht hadden zij om Capgemini te controleren? Dat was te weinig en daar is gebruik van gemaakt. De contractuele afspraken met betrekking tot Rup, softwarearchitectuur, kwaliteit, werkverdeling en dergelijke zijn niet of grotendeels niet nagekomen. Capgemini heeft de klant een lange tijd laten betalen voor producten en diensten die ze maar voor een deel hebben geleverd. Het is een keten van fouten.
Het hoogste management van Capgemini zegt dat de geleverde kwaliteit voldoet aan de norm van gemiddelde software, terwijl er aantoonbaar nog steeds blocking bugs inzitten. Misschien moeten zij zich eens afvragen, What business am I in? Het huidige verdienmodel van Capgemini werkt nog wel, maar hoe lang nog na al die negatieve publiciteit als je kampioen mislukte projecten bent? Om je bedrijf te kunnen continueren, heb je goodwill nodig. Een goede naam kun je niet kopen, maar moet je verdienen en blijven verdienen, zoals generaties van Capgemini Sogeti-medewerkers dat eerder hebben gedaan.
Zoveel mensen zoveel meningen, en als wat geld heb, dan koop je er wel wat meningen bij. Al dat getier met percentables over goto’s en een soort boolean algebra waarbij 2 + 1 = 2.. En hoeveel is dan C++, alsof dat er wat toe doet in de common business oriented langage. Richt zich op geld blijkbaar en van Gordon Ramsay’s methoden is ook niet iedereen fan. Daarna kijken we rijdende rechter die er straks geen bal van snapt en daar zult u het mee moeten doen.
@Louis Kossen, zoals ik Kurt al heb aangegeven, gaat het niet om een echt verschil van mening tussen SIG en SQMI. SIG heeft de IfSQ meting uit het oorspronkelijke SQMI report bekrachtigd. Er wordt om de resultaten van Ndpend meting heengelopen. Het is vooral een kwestie van niet reageren, niet rechtstreeks ingaan op argumenten.
Wat zou een rechter daarmee moeten? De rechter zal wel een deskundige hebben ingeschakeld om de vele ICT-argumenten te wegen om de juridische waarde daarvan te kunnen bepalen.
Maar de rechter zou als de rijdende rechter eens zelf kunnen gaan kijken naar de werking van 1-2Focus. Hoeft deze niet eens voor te gaan rijden. Een demonstratie van 1-2Focus, zou een destructie van Capgemini zijn.
@Felix, ik ben wat positiever over de kans dat de rechter de zaak juridisch adequaat kan beoordelen. De centrale stukken voor de rechtbank zijn door juristen opgesteld en het aantal verwijzingen naar de code is beperkt. En de rechtbank kan een deskundige inhuren; ze hebben wel vaker de inbreng van een of meer deskundigen nodig. Die deskundige(n) moet(en) de juiste deskundigheid hebben en neutraal zijn. Verder moet de rechter, in overleg met de deskundige, de juiste adviesopdracht meegeven.
@Jaap
Adviesopdracht?
Dat klinkt alsof er voorgesorteerd wordt op mediation, niet echt een duidelijke uitspraak en de Pyrrhus overwinning lijkt opeens aan de horizon op te komen. Daarmee komt dus de gewetensvraag naar boven wie nu uiteindelijk wie chanteert, vanuit alle analyses krijg ik de indruk dat de schuldvraag nog niet zo makkelijk te beantwoorden is en de eis betreffende vermeende winstderving ronduit exorbitant is.
@Ewout, waarom opeens wel mediation na al die keren / jaren dat dit niet acceptabel / mogelijk was. Capgemini wilde niet samen met Equihold kijken naar wat er mis is gegaan. Dat had een opmaat naar mediation kunnen zijn. Ik heb wel een idee waarom; Rene zal wel eens hetzelfde idee hebben.
Capgemini stelde juist dat er eerst circa driekwart miljoen aan (ingehouden) betalingen en rente betaald moet worden voordat er over het oplossen van de bugs gesproken kon worden (wat overigens niet meer ter zake doen is). Dat lijkt me geen goede basis voor mediation. Klinkt eerder naar Ransomeware.
Adviesopdrachten van de rechtbank voor deskundigen op het gebied van software-ontwikkeling en winstderving, acht ik wel mogelijk. Bij het laatste alleen nadat de rechter besloten heeft dat er door Capgemini een onrechtmatige daad is gepleegd; wat de laatste uiteraard ontkent.
Komt nog eens bij dat de software complexiteit klinkt alsof het een afstudeerproject van een handjevol informaticastudenten zou kunnen zijn maar de benchmarks aantonen dat zelfs dat niveau nog niet wordt gehaald.
@Jaap
Gezien je opmerking dat eerder al een poging tot mediation is gedaan neem ik aan dat door Equihold een ingebrekestelling is opgesteld waarin helder en specifiek alle geconstateerde tekortkomingen zijn opgesomd. Dit uiteraard op basis van een objectieve beoordeling van alle vooraf opgestelde criteria aangaande de kwaliteit.
Het Barbertje moet hangen aangaande de parallellen die telkens getrokken worden naar de maatschappelijke verontwaardiging over verspillingen van belastinggeld met ICT projecten bij de overheid is tenslotte een vorm van emotionele chantage. Het is niet mijn intentie om als advocaat van de duivel op te treden maar ondertussen leren ervaringen dat er sprake is van een systemische misvatting aangaande ICT.
Rene heeft het over ‘ontzorgen’ wat natuurlijk wel gekaderd moet worden, het uitvoerig stil blijven staan bij de onderhoudbaarheid van de code is namelijk irrelevant als je precies dat deel van de bedrijfsvoering uitbesteed hebt. Equihold ging met haaien zwemmen en moest zelf gehaaid genoeg zijn om tekortkomingen in de kennis aan te vullen. Afname van vlees bij dezelfde slager leidt tot een voor de hand liggend gezegde.
@Ewout, er is onder meer een ingebrekestelling ingediend. Er zijn diverse soorten gebreken geconstateerd. Het gaat onder meer om fouten op het gebied van de uitvoering van RUP, software architectuur, juistheid van de code, onderhoudbaarheid van de software en informatievoorziening/-plicht (deels werkzaamheden die ten onrechte niet zijn gedaan, deels werkzaamheden die verkeerd zijn uitgevoerd). Zijn de lijstjes compleet? Nee, want het kost te veel tijd om dat allemaal volledig uit te zoeken. Bijvoorbeeld de ene bug kan zich bijvoorbeeld achter de ander verschuilen. Dan moet je de grotendeels slecht leesbare code geheel gaan uitspitten. Er zijn zo’n 320.000 regels aan code, die veelal te lang zijn om goed leesbaar te zijn. Ga er maar aanstaan.
Maar je hoeft volgens de juristen ook niet alles 100% te documenteren; het beeld moet voor de rechter duidelijk zijn. Op Amerikaanse toestanden, met dossiers van meters hoog, zit niemand te wachten. Naar mijn mening heeft Equihold een goed overzicht geleverd, veel nauwkeuriger dan Capgemini. Wil de rechter meer materiaal, dan kan die dat krijgen.
Ten aanzien van de onderhoudbaarheid. Het is niet zo dat het onderhoud voor een bepaald bedrag is uitbesteed aan Capgemini. Dan zouden de fouten in de code en de slechte onderhoudbaarheid ten koste gaan Capgemini. Er was alleen een uurtje factuurtje contract voor de bouw. Equihold betaalde voor het verhelpen van de codefouten.
@Johan, volgens SIG kan per release 1/4 tot 1/3 deel van de code er uitgesloopt worden wegens duplicatie.
Als mij wordt gevraagd software te reviewen wil ik in eerste instantie de code niet eens zien.
Geef met eerst het design.
Als je het design reviewt, vind je al zoveel inconsistenties dat de code toch moet worden aangepast (om het vriendelijk te zeggen). Reviewen van de code voordat het design acceptabel is bevonden, is dan ook een zinloze tijdverspilling.
Het enige probleem is dat er meestal geen design is, omdat veel softwarici lijken te denken dat je de code zo wel kan intypen.
Veel documenten produceren à la RUP levert veel gespendeerde uren op, maar zegt niets over de kwaliteit van het design. Onlangs kreeg ik een design document van 47 pagina’s voor communicatie tussen twee apparaten. Absoluut onleesbaar, en door de vele cut-and-paste inconsistent in zichzelf, en nog inconsistenter met de design spec van de leverancier van een van de twee apparaten. Ik kon het document van 47 pagina’s samenvatten in een diagram op één A4-tje. Aan de hand van dit diagram is de software verder ontworpen, en het werkte vervolgens in één keer.
Als je software ontwerpt-en-reviewt totdat met erover tevreden is, en vervolgens codeert-en-reviewt totdat men tevreden is, dan is mijn ervaring dat de testers niets meer vinden. Maar waar gebeurt dat nog?
Ik las onlangs dat in de nucleaire en medische industrie software niet eens gecodeerd mag worden. Het moet in modellen worden ontworpen, vanwaaruit vervolgens de code wordt gegenereerd. Dit om zeker te zijn dat de documentatie consistent is en blijft met de code.
Als simpele regel voor de kwaliteit van de design documentatie stel ik altijd voor: “Als iemand een jaar later het systeem moet aanpassen (of reviewen), dan helpt de documentatie ons binnen 1 dag ‘up-and-running” te zijn.”
Wat betreft RUP: dit behandelt de performance requirements (-ilities zoals usability, availability, reliability, security, etc) als ‘supplemantary requirements’, die er ook nog bij horen, terwijl de performance requirements eigenlijk de essentie van het ontwikkelproject zijn.
De functionele requirements zijn alleen maar interessant om de scope van het project aan te geven. De functies worden immers allang door de gebruikers uitgevoerd. De enige reden waarom we een software ontwikkeling plegen, is om de gebruikers dat wat ze al doen, sneller, prettiger, betrouwbaarder, en dergelijke te doen uitvoeren. En RUP noemt dit de ‘bijkomende’ requirements (“O Ja, die moeten we ook nog opschrijven”).
De belangrijkste requirements zijn dus deze performance verbeteringen, die we altijd kwantitatief kunnen bepalen.
Voorbeeld: Nu kost het een gebruiker 1 uur om iets uit te zoeken, en met het nieuwe systeem kost het 15 sec. Daar kun je naar ontwerpen, en je kunt meten of het requirement is gehaald of niet. Als de essentiële requirements op deze wijze zijn opgesteld, dan is het eenvoudig om te bepalen of is geleverd of niet.