Gooi de specificaties maar over de muur !

Anton Greve

Stop proza over de muur te gooien !

Wat is er eigenlijk anders?

• Problemen rondom ICT Offshoring & Outsourcing niet anders dan vroeger

• Eigenlijk de “normale” problemen van ICT projecten + extra problemen:–meer partijen, contracten – communicatie – taal, afstand–het proces, de manier van werken

Terug in de tijd

• We wilden we toen, wat willen we nu? • De business wil :

–goedkoper – snellere time to market –meer kwaliteit

• Er is weinig veranderd

• Vroeger, nu … dezelfde problemen

Vraag: wat bereiken wij met sourcing?

• Goedkoper? … dat is nog maar de vraag

• Sneller ? … dat is nog maar de vraag

• Meer kwaliteit? … dat is nog maar de vraag

Waar staan we ?

Nog steeds:uitloop, overschrijding en ontevreden

business!Na 30 jaar innoveren…

HOW COME ?

Project faal factoren(The Standish Group)

Probleem factoren IT projecten 1. Ontbreken input van gebruikers 12,80%2. Incomplete Requirements & Specificaties 12,30%3. Wijzigende Requirements & Specificaties 11,80%4. Te weinig Executive Support 7,50%5. Technology Incompetentie 7%6. Gebrek aan Resources  6,40%7. Niet realistische verwachtingen  Business 5,90%8.Onduidelijke Business doelstellingen 5,30%9. Onrealistische Tijd Frames  4,30%10. Nieuwe Technologie 3,70%11. Other 23%

30 jaar speciferen

30 jaar specificeren

30 jaar specificeren

30 jaar Schommels

ICT-oplossingen

Business vraag

Optelsom

• 50-60 % problemen vindt oorzaak in voortraject

• 40-50% van de kosten behelst het voortraject

?

Conclusie:

• Er zit veel oplossend vermogen in:–voortraject – communicatie business naar ICT en

omgekeerd–onduidelijke goals, requirements en

specificaties–onduidelijk voortbrengingsproces

Focus laatste 10 jaar

• Nieuwe technologie• Ontwikkelstraten• Code generatie • Uitbestedingsprocessen

Onvoldoende :

innovatie voortraject

Kunnen we zo wel outsourcen?

• Word document

Outsourcing maakt het erger

• Afstand, taalproblemen, cultuurverschillen

• Iteratief ontwikkelen• Contracten, changes etc…

EN ………• De oorspronkelijke problemen worden

daarmee niet opgelost

Conclusie:

We moeten het voortraject aanpakken!

Focusverschuiving

• Van: kwaliteit programmatuur, tooling, technologie, development proces en uitbesteding.

• Nu naar: …….

Voortraject en integratie processen

1. Stoppen met proza

2. Naar centrale registratie en management van informatie-elementen: stakeholder, rol, business doel, feature, business rule, requirement en hun onderlinge relaties

3. Integreer voortraject met OTAP omgeving

4. Integreer voortbrengingsprocessen

Requirements Engineering invoeren

• Analoog aan de Industriële Productontwikkeling (NASA, Siemens, Boeing)

• Product Life Cycle Management• Beheer daarmee de levenscyclus van

software producten

Hoe doe je dat?

ARE

Stap 1: van proza naar informatie

• Knip het proza op in informatie-elementen (stakeholder, requirement, goal, business rule ..) Maak een informatiemodel

• Leg logische relaties tussen alle elementen

Information Modelclass ARE Data Mo...

Stakeholder

Requirement

Functionele Requirement

Niet-functionele Requirement

Randv oorwaarde

Use Case

Use Case Realisatie

TestontwerpActor

Business Object

Bedrij fsregel

Architectuur

- DeploymentView: Architectuur- ImplementationView: Architectuur- LogicalView: Architectuur- ProcessView: Architectuur

(Technisch)Probleem

Wijziging

Bev inding

In plaats van proza

Stakeholder Dir. ExploitatieBusiness Goal Doorstroom aan kassa moet korterFeature Betalen met Credit Card (CC)Use Case Betalen met CC Requirement Moet met MasterCard kunnenRequirement Transactiedatum < Einddatum CC

Stap 2: creëer het integratieplatform

• Selecteer daarvoor een tool• Implementeer informatiemodel• Leg de informatie en relaties daarin

vast i.p.v. proza• Maak het platform toegankelijk voor

alle stakeholders

ARE Transparant Integratieplatform

Stap 3: genereer werkproducten

• Stel de systeemontwikkelingsmethodiek vast (bijv. RUP)

• Definieer de werkproducten (in RUP bijv.: Vision doc , Use Case Spec)

• Implementeer ze in je integratieplatform• Genereer je werkproducten uit het

integratieplatform

Stap 4: creëer transparantie

• Door vastlegging en beheer op één plaats. Door de relaties ontstaat traceability. Vereenvoudigde impactanalyse .

• Creëer interfaces naar OTAP • Gebruik in alle

voortbrengingsprocessen

ARE – informationflow versus paperflow

pkg Traceability

Vision

+ Functionele Requirement+ Niet Functionele Requirement+ Randvoorwaarde+ Requirement+ Stakeholder

Use Case Model

+ Actor+ Use Case

Business Object Model

+ Bedrijfsregel+ Business Objects+ Stakeholder

Use Case Specification

+ Actor+ Use Case

Use Case Realization

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Traceability

+ BusinessObjects-Stakeholders+ Changes-Requirements+ Changes-UseCases+ Requirements-UseCases+ Stakeholders-Changes+ Stakeholders-Requirements+ UseCases-Bevindingen+ UseCases-Realization+ UseCases-TestCases

Acceptatie Test Plan

+ Testontwerp

Testontwerp

+ TestontwerpSoftware Architecture Document

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Wijzigingsvoorstel

+ Wijziging

Bevindingen

+ Bevinding

Acceptatiebevindingen

+ Bevinding

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»«use»

pkg RUP op M...

Acceptatie Test Plan

+ Testontwerp

Testontwerp

+ Testontwerp

Use Case Model

+ Actor+ Use Case

Use Case Realization

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Use Case Specification

+ Actor+ Use Case

Vision

+ Functionele Requirement+ Niet Functionele Requirement+ Randvoorwaarde+ Requirement+ Stakeholder

Business Object Model

+ Bedrijfsregel+ Business Objects+ Stakeholder

Navigation Map

Glossary

Requirements Werkproduct volgen RUP op MaatOverige RUP op Maat Werkproducten

Legend

Bevindingen

+ Bevinding

Software Architecture Document

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Data Model

Design Model

Acceptatiebevindingen

+ BevindingWijzigingsvoorstel

+ Wijziging

class ARE Data Mo...

Stakeholder

Requirement

Functionele Requirement

Niet-functionele Requirement

Randvoorwaarde

Use Case

Use Case Realisatie

TestontwerpActor

Business Object

Bedrijfsregel

Architectuur

- DeploymentView: Architectuur- ImplementationView: Architectuur- LogicalView: Architectuur- ProcessView: Architectuur

(Technisch)Probleem

Wijziging

Bevinding

Resultaat

• Inzicht in requirements overal

• Traceerbaarheid

• Easy impactanalyses

• Eenvoudiger Changemanagement

• Eenvoudiger Configuratiemanagement

• Transparantie in alle deelprocessen

• Interface voor communicatie Business en ICT

• PLCM !!!

Innoveer het voortbrengingproces • Knip de proza op in stukken

(Requirements Engineering )• Kies een integratieplatform • Ontwerp en implementeer traceerbaarheid • Genereer werkproducten • Integreer change – configuratie

management ea processen• Maak de business part of the proces • Doe aan Software Product Life Cycle

management

pkg RUP op M...

Acceptatie Test Plan

+ Testontwerp

Testontwerp

+ Testontwerp

Use Case Model

+ Actor+ Use Case

Use Case Realization

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Use Case Specification

+ Actor+ Use Case

Vision

+ Functionele Requirement+ Niet Functionele Requirement+ Randvoorwaarde+ Requirement+ Stakeholder

Business Object Model

+ Bedrijfsregel+ Business Objects+ Stakeholder

Nav igation MapGlossary

Requirements Werkproduct

RUP op Maat Werkproduct

ARE informatie element

Legend

Bev indingen

+ Bevinding

Software Architecture Document

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Data Model

Design Model

Acceptatiebev indingen

+ BevindingWijzigingsv oorstel

+ Wijziging

Traceabilitypkg Traceability

Vision

+ Functionele Requirement+ Niet Functionele Requirement+ Randvoorwaarde+ Requirement+ Stakeholder

Use Case Model

+ Actor+ Use Case

Business Object Model

+ Bedri jfsregel+ Business Objects+ Stakeholder

Use Case Specification

+ Actor+ Use Case

Use Case Realization

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Traceability

+ BusinessObjects-Stakeholders+ Changes-Requirements+ Changes-UseCases+ Requirements-UseCases+ Stakeholders-Changes+ Stakeholders-Requirements+ UseCases-Bevindingen+ UseCases-Realization+ UseCases-TestCases

Acceptatie Test Plan

+ Testontwerp

Testontwerp

+ TestontwerpSoftware Architecture Document

+ DeploymentView+ ImplementationView+ LogicalView+ ProcessView

Wijzigingsv oorstel

+ Wijziging

Bev indingen

+ Bevinding

Acceptatiebev indingen

+ Bevinding

«use»«use»

«use»

«use»

«use»

«use»

«use»

«use»

«use»«use»

Resume

• Focusverschuiving• Requirements Engineering• Integreer processen• (Software) Product Life Cycle

Management

Helpt dat ook bij sourcing?

• De belangrijkste FAALFACTOREN* zitten juist in het voortraject:1. Ontbreken input van gebruikers 12,80%

2. Incomplete Requirements & Specificaties 12,30%

3. Wijzigende Requirements & Specificaties 11,80%

4. Te weinig Executive Support 7,50%

• Juist bij sourcing is het voortraject meer complex en nog gevoeliger voor de faalfactoren

• Succesvolle sourcing vraagt dus om hoge kwaliteit voortraject * Standish report

RE werkt !!

RM tools hebben het meest invloed op het projectsucces

Onderzoek naar successen van projectmanagementtools Standish (2001)

Sloop de muur!

REQUIREMENTS ENGINEERING !

• VRAGEN ??

Statistieken -Standish

PROJECT SUCCES TOP TIENExecutive Support 18User Involvement 16Experienced Project Manager 14Clear Business Objectives 12Minimized Scope 10Standard SW Infrastructure 8Firm Basic Requirements 6Formal Methodology 6Reliable Estimates 5Other 5

Reden van mislukt projecten (Standish 1995)

Incomplete requirements 13,1

Lack of user involvement 12,4

Unrealistic explectations 9,9

Changing requirements/specs 8,7

Didn't need it any longer 7,5

51,6

RM tools hebben het meest invloed op het projectsucces (Standish 2001)

Ofwel het voortraject en de terugkoppeling

• Hoe lossen we dat op ?? • 1. Meer focus op voortraject • 2. Minder proza• 3. Meer proces-integratie • 4. Stoppen met over de muur

gooien

ARE in OTAP

Waarschijnlijke Oorzaken

• De specificaties zijn onvoldoende duidelijk

• Het specificatie proces • Voortschrijdende inzichten - changes• Communicatie business – ICT en

omgekeerd

ICT uitbesteden omdat ..

• Kosten te hoog• Uit de hand lopen van projecten • Time to market • Business – ICT afstemming • Politiek

• EINDE

Famous examples…

1984: The IBM PCjr was a precursor to modern laptop computers, but it was a financial failure. The keyboard was too small for normal sized fingers. People did not like them and they did not buy them

2005: De ontwikkeling van het NVIS stagneerde in 2005 omdat de noodzakelijke koppeling van de bestanden van instanties, zoals het Ministerie van Justitie en de IND, hoge eisen stelt aan de integriteit en de beveiliging van informatie-uitwisseling. Dit blijkt complexer dan was voorzien. Er is inmiddels een doorstart gemaakt met de verdere ontwikkeling. Kost 24,3 miljoen, daarvan 4,7 miljoen zijn te danken aan de wijziging op biometrische passport gegevens,

2008: Net als zoveel andere overheidsprojecten pakt de invoering van de OV-chipkaart veel duurder uit. Het systeem kost volgens het Algemeen Dagblad nu al 100 miljoen euro extrabovenop de geraamde 250 miljoen en dat bedrag zal nog flink gaan stijgen. Onder meer vanwege haperende toegangspoortjes, problemen met de privacy en het rumoer over de beveiliging van de pas.

Outline

• Wat is er anders ? • Enige Statistiek , Oorzaak en gevolg • Noodzaak tot verbetering • Focus verschuiving • Oplossing • Vragen

Requirements Development

• Focuses on:–discovering real requirements,–analysing them,–writing them down, –checking against quality criteria and

stakeholders expectations to finally –approving them as a project basis

Requirements Management

• Focuses on:– linking requirements with each other

and with other project information (e.g. project plans, designs, tests) –also called traceability

–managing changes to requirements and propagating updates throughout

–measuring the process

Wat is er gebeurd de afgelopen jaren

• De problemen met ICT-projecten bleven aanhouden

• De business is wijzer geworden• ICT – is – commodity ?? • ICT managers in verdrukking• Wat doe je dan als je t niet

meer weet ??

Inderdaad ….

• Uitbesteden !!• Eerst : bij derden binnen t

land • Toen bij derden buiten t land

(prijs)

• Maar lost t iets op ??

IT project landschap

• IT project gebruikt verschillende platformen in het voortbrengingproces van software – Business Analyse en het OTAP model

IT project’s landscape

• These platforms are not sufficiently integrated what results in:– Information loss at transition points

– Misinterpretation of information

• Lost/misintrepreted information leads to:– Insufficient product quality

– Delays in development (re-work)

– Increased development costs

• These platforms are not sufficiently integrated what results in:– Information loss at transition points

– Misinterpretation of information

• Lost/misintrepreted information leads to:– Insufficient product quality

– Delays in development (re-work)

– Increased development costs

Voortraject en sourcing

• Deze problematiek is er nog dus nog steeds

• In geval van sourcing ligt het nog wat complexer –Afstand–Communicatie (nog meer partijen) –Taal–Terwijl: we iteratief willen ontwikkelen

What’s the problem?

Defects in the information flow (gaps, misinterpretations, etc) across platforms cause product quality

problems, cost overruns, and product delays.

Hoe gaat dat in z’n werk

• ICT projecten overschrijden in tijd en of geld

• ICT geeft schuld aan Businessen omgekeerd

• Externe toeleveranciers krijgen ALTIJD de schuld

Dit is al jaren aan de gang en t verbetert niet echt !!

ARE Tools

ARE Tools support ARE Process through:

• Assessing Requirements Quality• Requirements Modeling• Requirements Management• Application Lifecycle Management

Feit 2:Veelzijdige rol van requirements

RequirementsRequirements

TestsTests

Project Management

Project Management

DesignDesign

ImplementatieImplementatie

RisicoManagement

RisicoManagement

Gebruikers documentatieGebruikers

documentatie

Feit 3:Hedendaagse praktijk

Specificatie OTAP

Resultaat

• Verkeerde implementatie• Ontevreden gebruikers• Onvolledige en inconsistente

documentatie• Slecht inzicht in de

consequenties van wijzigingsvoorstellen

ARE biedt Link & Transparantie

• Identificeerbare stukjes informatie, die gelinkt zijn met elkaar

• Voortraject gelinkt aan de OTAP informatie

• Transparante informatie voorzieningen aan alle stakeholders

ARE integreert

Specificatie OTAP

ARE maakt de samenhang van omgevingen mogelijk!

UC Model

Feature

Requirement

UC Description

Stakeholders ARE

RM Tools

• Om traceerbaarheid goed te kunnen implementeren is een RM tool noodzakelijk

• RM tool dient interfaces te hebben naar/van andere processen

• Bijvoorbeeld: Enterprise Architect van Sparx Systems

Requirements ManagementTraceability Scheme

Example ofRequirements Development

Example of a Vision development flow:• Clear, manageable steps• Dedicated activities within each step• Each step is accompanied by 

•guidelines and •how‐to instructions 

for faster delivery and more quality output 

Change Management• Veranderingen in

requirements zijn onvermijdelijk

• Het project moet zijn ingericht om wijzigingsvoorstellen zo goed mogelijk te kunnen analyseren.

Impact analyse

Voornamelijk 2 aspecten • Technische impact

–wat moet veranderd worden in het systeem

• Project impact –Wat kosten de technische veranderingen

en wat betekent dat voor het project

Integratie met IDE

Integratie Oracle

Enterprise Architect:RequirementsArchitectureDesignTesten

Oracle:Implementatie van•Tabellen •Procedures•Views•UI ModelUnit Tests

•Tabel definitie•Tabel relaties•Scherm prototypes

Change Management

In action• Hoe zijn de veranderingsvoorstellen

bewaard?• Hoe kan de technische analyse

ondersteund worden door een tool

Vragen ?

De realiteit …

• Is t wel echt goedkoper ? • Time to market ? • Waar is de materie/domein

kennis gebleven ? • Kan ik straks nog terug ?