Dit artikel is het tweede in een reeks van twee artikelen. In het eerste artikel (gepubliceerd in de Computable van 19 mei 2006) geeft de auteur zijn inzichten over het gebruik van 3GL (Generation Language) en 4GL programmeertalen. In dit tweede artikel werkt hij schattingen uit van de productiviteit.
Productiviteit is een hulpmiddel om tot budgetten voor it-ontwikkeling te komen. Een budget kan men vereenvoudigd als volgt berekenen:
Omvang project x productiviteit x gemiddeld uurtarief = budget
Deze formule abstraheert van vaste kosten, zoals hardware en licenties. Functiepuntanalyse is een (ISO-) standaard om de omvang van software te schatten. Het gaat het bestek van dit artikel te buiten om functiepuntanalyse te behandelen. De uitstekende website van de NESMA geeft veel informatie over dit onderwerp (www.nesma.org). Om tot een budget te komen heeft men dan nog een productiviteit in uren per functiepunt nodig en de gemiddelde arbeidskosten in euro/uur.
Productiviteit van 4GL
Productiviteiten zijn een heikel thema; de onderlinge vergelijkbaarheid is moeilijk. Er is geen definitie welke activiteiten moeten meetellen onder de noemer ‘softwareontwikkeling’. Alleen codering, ontwerp en codering? In specifieke omstandigheden kunnen sommige activiteiten niet nodig zijn of gereduceerd worden. Voorbeelden: bij herbouw van een bestaande applicatie kan men het zonder requirements-analyse stellen. Een intern project kan zonder gebruikersdocumentatie wellicht toch goed functioneren.
Afgezien van de definitie van te meten activiteiten zijn productiviteiten zeer afhankelijk van de omstandigheden. Is het projectteam voor de eerste keer bij elkaar als team? Is er sprake van nieuwe of bestaande techniek? Is het de eerste keer dat het projectteam de gekozen techniek gebruikt of is deze al jaren bekend?
Op basis van over een periode van tien jaar opgedane ervaring zijn door de auteur kengetallen vastgesteld aan de hand van achteraf analyseren van planning en realisatie van uitgevoerde projecten. Het gaat daarbij om projectteams die steeds waren samengesteld uit een min of meer vaste groep medewerkers en om de technologie Progress 4GL. Die technologie ontwikkelt zich in steeds nieuwe versies, maar bestaat in de basis circa 25 jaar. Het gaat dus om een stabiele ontwikkelomgeving.
Afbeelding 1 geeft een overzicht van alle activiteiten in een ‘turn key’ softwareontwikkeling, vanaf de opdracht tot aan de acceptatie. Het geeft daarom het hoogst denkbare getal weer. Alle elementen van systeemontwikkeling worden meegenomen in de beoordeling en afweging van de productiviteit. (Zie afbeelding 1)
De productiviteit van 10 uur per functiepunt is gebaseerd op het gebruik van de Progress 4GL ontwikkeltaal en -omgeving en de Progress RDBMS. Met andere 4GL-producten zou men tot vergelijkbare productiviteiten moeten kunnen komen. Het betreft ontwikkeling van ‘business’ applicaties zoals een financieel pakket of een systeem voor voorraadbeheer.
Voor softwareontwikkeling met 3GL’s is een vergelijkbaar overzicht mogelijk. Een aantal factoren daarin is geschat. Er zijn minder projecten voor vergelijkbare ontwikkeling van ‘business’ software met 3G’s, precies om het verschil in productiviteit waar het hier over gaat. 3GL is minder productief, dus duurder en dus minder in gebruik voor ‘business applications’.
Productiviteit van 3GL
Men kan bij QSM (www.qsm.com) vinden dat 3GL’s ongeveer tweemaal zo veel SLOC (Source Lines Of Code) vereisen als 4GL’s. Dat komt neer op de halve productiviteit of de dubbele tijd om even veel functiepunten te realiseren. Zoals eerder opgemerkt gaat het hier om sterk vereenvoudigde conclusies uit een complexe realiteit; het is alles wat we hebben op dit complexe vakgebied. Velen zijn het niet eens met de conclusie van halve productiviteit en geven ervaringen dat de gerealiseerde productiviteit in 3GL-projecten veel slechter is. Hier nemen wij de bevindingen van QSM over.
Er is een aantal ‘grote’ 3GL’s. Dit artikel neemt C# als uitgangspunt, de taal die aan de basis ligt van het .NET-platform van Microsoft. Afbeelding 2 geeft een inschatting van de productiviteit in een op C# gebaseerd ontwikkelproject, uitgedrukt in percentages van de eerder weergegeven productiviteit voor 4GL. Afbeelding 1 geeft een beeld waar meer aan de hand is dan alleen de halve productiviteit voor de codering. Er is aanmerkelijk meer technisch design nodig. Eerder in dit artikel is toegelicht dat 3GL’s op een lager niveau werken met een beperkt aantal elementaire opdrachten. Dat geeft een grote flexibiliteit; de keerzijde daarvan is meer design om in die grotere flexibiliteit aan te geven wat de bedoeling is en wat niet. Meer code betekent op zich al meer testen. Dit overzicht veronderstelt een meer dan evenredig hogere testinspanning. 3GL is minder toegankelijk – moeilijker te lezen – en zal om die reden meer fouten bevatten die testen en correctie behoeven. Tenslotte zal meer externe consultancy nodig zijn wegens de als geheel de complexere techniek in een 3GL-gebaseerd project. Activiteiten als ‘requirements’, ‘technical doc’ en ‘user/help doc’ staan los van de gebruikte techniek en zullen niet wijzigen. (Zie afbeelding 2)
Wie de tabel narekent, ziet dat die niet lijkt niet te kloppen; dat is schijn. Een aantal activiteiten wordt berekend als een percentage van andere activiteiten; daarnaast is er de projectparameter om 3GL op 4GL te baseren. Voorbeeld: ‘corrections’ is gedefinieerd als 20% van ‘development’. Aan de 3GL kant is de berekening dan als volgt: 6,00 x 20% x 150% = 1,80.
De rekenregels zijn als volgt:
Corrections: percentage (4) x (3)
Testplan/testing: percentage (5) x (1+2+3+4)
Consultancy: als Testplan/testing
Project Management: percentage (9) x (1+2+3+4+5+6+7+8)
Ontwikkeling met een 3GL vergt op zichzelf twee keer zoveel tijd als met 4GL. Een project op basis van een 3GL-product vergt circa 85% extra inspanning ten opzichte van een 4GL-project.
Gemengd gebruik van 4GL en 3GL
De wens om een 3GL-taal te kiezen als basis voor softwareontwikkeling van een ‘businessapplicatie’ heeft meestal een commerciële achtergrond. Men wenst te voldoen aan offertes van klanten die voorschrijven dat de te kiezen applicatie bijvoorbeeld op .NET is gebaseerd. Dit artikel laat in het midden of het verstandig is dat klanten naast functionele eisen ook technische eisen stellen; het is een realiteit waarmee softwareontwikkeling moet leven. Een andere commerciële reden kan zijn dat men een ‘rijke’ user interface wenst aan te bieden met meer ‘toeters en bellen’ dan men met een 4GL denkt te kunnen realiseren.
Dit levert een moeilijk op te lossen dilemma op. Met een 3GL kan men de rijke UI realiseren, zij het met lage productiviteit en dus relatief hoge ontwikkelkosten. Met een 4GL is de ontwikkeling sneller – ‘time to market’ is vaak belangrijk – en goedkoper. De UI zal echter beperkter zijn en het is de vraag wat het effect is op de verkoopskansen.
Een interessante uitweg uit dit dilemma is gemengd gebruik van 4GL en 3GL, 4GL voor de logica van het product en 3GL voor de user interface. Hier is nu de gecombineerde productiviteit aan de orde.
Bij gemengd gebruik is er sprake van activiteiten op basis van 4GL, op basis van 3GL en activiteiten die los staan van technologie. Dit artikel heeft eerder productiviteiten voor puur 4GL en puur 3GL weergegeven. Om de vergelijkbaarheid te bevorderen gebruikt onderstaand overzicht voor een combinatie van 4GL en 3GL de volgende methode. Het overzicht splitst de diverse activiteiten over algemeen, bedrijfslogica en user interface. De kolommen ‘project %’ geven de effecten van de verschillende productiviteit van 4GL en 3GL. (Zie afbeelding 3)
De conclusie van bovenstaand overzicht is dat softwareontwikkeling met gebruik van 4GL voor de bedrijfslogica en 3GL voor de user interface circa 40% meer inspanning vraagt dan een ontwikkeling met alleen een 4GL-product. Dat is de prijs voor de ruimere mogelijkheden om een rijke user interface te realiseren. Dat mag veel lijken, maar het is nog altijd een stuk minder dan de 85% extra inspanning die hier geschat wordt voor puur 3GL. Het is aan de ontwikkelorganisatie om te analyseren of de extra inspanning in extra verkopen kan worden teruggewonnen.
Betrouwbaarheid van schattingen
De berekeningen in dit artikel zijn gebaseerd op een aantal jaren systematisch vergelijken van de realisatie van projecten met de van tevoren opgestelde planningen en op ervaringen in lopende projecten met de mix van 4GL en 3GL die in dit artikel is toegelicht. Dit artikel concludeert dat het gebruik van alleen een 3GL tool circa 180% inspanning vraagt in vergelijking met het gebruik van een 4GL tool. Het gebruik van een mix van 3GL voor een ‘thin client UI’ en 4GL voor de business logic zou circa 140% inspanning vragen ten opzichte van alleen 4GL.
Het gebruik van 3GL bergt een aanmerkelijk groter risico in zich dan 4GL. Hoe meer werk er is en hoe meer mogelijkheden de gebruikte taal biedt, des te groter is de kans dat een verkeerde weg wordt ingeslagen die weer moet worden gecorrigeerd. Dat het werken met een 3GL meer risico’s brengt dan een 4GL vindt steun in de cijfers van QSM (www.qsm.com). QSM geef niet alleen een gemiddelde productiviteit over alle projecten die men heeft geanalyseerd, maar ook een hoog en laag cijfer. Daarbij valt op dat de spreiding tussen hoog en laag voor de weergegeven 4GL-producten veel geringer is dan voor de 3GL-producten. Voor de 4GL-producten verschillen de hoge en lage waarden een factor 2, voor de 3GL-producten is die factor 6-7.
Dat komt overeen met geluiden uit de markt dat de productiviteit van 3GL-producten veel slechter zou zijn dan door QSM aangegeven. Slechte projecten vallen meer op dan goede en met een 3GL kan een slecht project opvallend veel slechter dan gemiddeld zijn.
De 140% voor de mix 3G/4GL zal niet veel lager kunnen. Wellicht dat de realisatie van een eenvoudige en zeer consistente UI door een organisatie met zeer sterk ontwikkeld ontwikkelmanagement 130% kan bereiken, maar dan is het wel op. Het risico van afwijking aan de bovenkant is veel groter. Met ontoereikend ontwikkelmanagement kan de 180% voor 3GL alleen gemakkelijk vele malen worden overschreden en hoeft 880% niet te verbazen.
Een waarschuwing is hier op zijn plaats. De productiviteit van 3GL en 4GL loopt op zich uiteen. Dat is echter niet bepalend voor het succes van een project. Effectief dan wel ontoereikend ontwikkelmanagement zal een veel grotere invloed hebben op de productiviteit in ontwikkelprojecten. De effecten in een 3GL-project kunnen daarbij veel groter worden dan bij gebruik van 4GL.
Waar gaat het naar toe
De toekomst is onbekend, maar een ‘educated guess’ is op zijn plaats. 3GL-producten zullen geen algemene acceptatie verwerven zolang ze meer inspanning en dus meer geld vergen dan 4GL-ontwikkeling. Java was 10 jaar geleden de grote belofte die de softwareontwikkeling zou veroveren. Nu, 10 jaar later, is het nog steeds een belofte. Dat heeft weinig te maken met de technische mogelijkheden en kwaliteiten van Java en zeer veel met de bijbehorende productiviteit en kosten.
‘Niets voor niets’ is een goede zegswijze in het Nederlands. Hogere productiviteit is alleen te bereiken door specialisatie. Er moeten frameworks komen die ondersteuning bieden voor veel gebruikte operaties door herbruikbare componenten te bieden die men alleen hoeft aan te roepen. Een logische volgende stap is om nieuwe opdrachten in de 3GL te definiëren die feitelijk de component uit het framework aanroepen. De onderdelen uit het framework zijn dan metaoperaties in de 3GL geworden. Dat moet bekend klinken; eerder is toegelicht dat dat precies de ontwikkeling is die heeft geleid tot de huidige 4GL’s. De 4GL’s die zelf met een 3GL worden ontwikkeld zijn een verzameling metaoperaties waarbij de gebruiker niet langer ziet dat die metaoperaties eigenlijk in 3GL geschreven herbruikbare componenten zijn.
Wil een ontwikkelomgeving die nu als 3GL moet worden ingedeeld qua productiviteit, concurrerend worden met 4GL, dan moet die 3GL dezelfde ontwikkeling doormaken als de huidige 4GL’s eveneens hebben doorgemaakt. ‘De geschiedenis herhaalt zich’. De specialisatie met metaoperaties betekent dat algemene inzetbaarheid en flexibiliteit van 3GL verloren gaan. Het is dan ook niet waarschijnlijk dat een 3GL zelf in een 4GL zal veranderen. Het traditionele toepassingsgebied van de 3GL zou verloren gaan. Als een 3GL de strijd om de productiviteit wil aangaan, is het waarschijnlijker dat een nieuwe 4GL taal uit de 3GL zal ontstaan die qua syntax en dergelijke overeenkomsten vertoont. De fundamentele keuze en afweging tussen productiviteit en flexibiliteit blijft behouden. Dat is maar goed ook, want er zijn vele verschillende toepassingen van software en daar zijn verschillende ontwikkeltechnieken voor nodig
Ondertussen staat de software-industrie op het punt van ontwikkeltechnologie eigenlijk stil. Voor mij is dat een raadsel in een zo dynamische industrie. De 4GL-omgevingen zijn alle ontstaan in de tachtiger en negentiger jaren van de vorige eeuw. De 3GL’s die algemeen in gebruik zijn, zijn eveneens 15-20 jaar oud of een recente combinatie van bestaande talen (C#). Er is geen zicht op de volgende stap die men 5GL zou kunnen noemen. De software-industrie blijft steken in de technologie. Er komt wel steeds nieuws, maar in de fundamentele combinatie van productiviteit, kosten en kwaliteit verandert niet veel. Software ontwikkelen blijft een moeizaam proces dat veel geld kost; vervolgens kost het nog veel meer tijd en geld om de ontwikkelde software op een goed kwaliteitsniveau te krijgen. Het wordt hoog tijd dat iemand een briljant idee heeft dat de basis kan vormen van 5GL-producten die een grote stap voorwaarts zouden moeten zijn in productiviteit, en kwaliteit en de kosten en het tempo van softwareontwikkeling naar een volgend niveau zouden moeten tillen.
Tot die tijd moeten we roeien met de riemen die we hebben. Dit artikel beoogt een globaal beeld te geven van de inspanningen die met de huidige ontwikkeltechnologie gemoeid zijn. In die huidige technologie is een combinatie van 4GL en 3GL een interessant compromis van een goede productiviteit en een hoog ambitieniveau.
André Hartman, Progress Software Nederland
Dit artikel geeft persoonlijke inzichten. Progress Software is op geen wijze gebonden door de inhoud van dit artikel. De auteur dankt collega en vriend Wim Martens voor het kritisch lezen dat tot verduidelijking heeft geleid.