Anton Greve (Antares), Regie van Sourcing
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Anton Greve (Antares), Regie van Sourcing

on

  • 670 views

Presentatie bij conferentie Regie van Sourcing. Organisatie IT Executive, 22 april 2009 ...

Presentatie bij conferentie Regie van Sourcing. Organisatie IT Executive, 22 april 2009
TITEL: Gooi specificaties maar over de muur
DOOR: Anton Greve
De ICT focust zich al decennia op besparingen in het bouwtraject. De keuze voor outsourcing is dan snel gemaakt. Maar daarmee nemen de problemen met organisatie, communicatie en de semantiek
van specificaties alleen maar toe. We blijven focussen op innovaties in het bouwtraject, terwijl 50 procent van de kosten inmiddels
betrekking heeft op het voortraject. Waar productieorganisaties als NASA en Philips al lang traceability van requirements implementeerden om hun producten beter te specifi ceren en wijzigingen beter te
managen, wordt ook nu ook de administratieve ICT langzaam wakker.
De grootste kansen voor procesverbetering,
besparing en versnelling ligt in het voortraject. De sleutel heet Requirement Engineering.
Anton Greve is ICT ondernemer en directeur Innovatie bij Antares in Utrecht.

Statistics

Views

Total Views
670
Views on SlideShare
667
Embed Views
3

Actions

Likes
0
Downloads
13
Comments
0

2 Embeds 3

http://www.it-executive.nl 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Anton Greve (Antares), Regie van Sourcing Presentation Transcript

  • 1. Gooi de specificaties maar over de muur ! Anton Greve
  • 2. Stop proza over de muur te gooien !
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. Waar staan we ? Nog steeds: uitloop, overschrijding en ontevreden business! Na 30 jaar innoveren… HOW COME ?
  • 7. 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%
  • 8. 30 jaar speciferen
  • 9. 30 jaar specificeren
  • 10. 30 jaar specificeren
  • 11. 30 jaar Schommels ICT-oplossingen Business vraag
  • 12. Optelsom • 50-60 % problemen vindt oorzaak in voortraject • 40-50% van de kosten behelst het voortraject ?
  • 13. Conclusie: • Er zit veel oplossend vermogen in: – voortraject – communicatie business naar ICT en omgekeerd – onduidelijke goals, requirements en specificaties – onduidelijk voortbrengingsproces
  • 14. Focus laatste 10 jaar • Nieuwe technologie • Ontwikkelstraten • Code generatie • Uitbestedingsprocessen Onvoldoende : innovatie voortraject
  • 15. Kunnen we zo wel outsourcen? • Word document
  • 16. Outsourcing maakt het erger • Afstand, taalproblemen, cultuurverschillen • Iteratief ontwikkelen • Contracten, changes etc… EN ……… • De oorspronkelijke problemen worden daarmee niet opgelost
  • 17. Conclusie: We moeten het voortraject aanpakken!
  • 18. Focusverschuiving • Van: kwaliteit programmatuur, tooling, technologie, development proces en uitbesteding. • Nu naar: …….
  • 19. 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
  • 20. Requirements Engineering invoeren • Analoog aan de Industriële Productontwikkeling (NASA, Siemens, Boeing) • Product Life Cycle Management • Beheer daarmee de levenscyclus van software producten
  • 21. Hoe doe je dat? ARE
  • 22. 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
  • 23. Information Model class ARE Data Mo... Stakeholder Business Obj ect Bedrij fsregel Wij ziging Niet-functionele Requirement Requirement Randv oorw aarde Functionele Requirement Use Case Testontw erp Bev inding Actor Architectuur Use Case Realisatie - DeploymentView: Architectuur - ImplementationView: Architectuur - LogicalView: Architectuur - ProcessView: Architectuur (Technisch)Probleem
  • 24. In plaats van proza Stakeholder Dir. Exploitatie Business Goal Doorstroom aan kassa moet korter Feature Betalen met Credit Card (CC) Use Case Betalen met CC Requirement Moet met MasterCard kunnen Requirement Transactiedatum < Einddatum CC
  • 25. 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
  • 26. ARE Transparant Integratieplatform
  • 27. 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
  • 28. 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
  • 29. ARE – informationflow versus paperflow
  • 30. class ARE Data Mo... Stakeholder Business Object Bedrijfsregel Wijziging Niet-functionele Requirement Requirement Randvoorwaarde Functionele Requirement Use Case Testontwerp Bevinding Actor Architectuur Use Case Realisatie - DeploymentView: Architectuur - ImplementationView: Architectuur - LogicalView: Architectuur - ProcessView: Architectuur (Technisch)Probleem pkg Traceability pkg RUP op M... Vision Vision Business Object Model Wijzigingsvoorstel Business Object Model + Functionele Requirement Acceptatie Test Plan + Functionele Requirement + Niet Functionele Requirement + Bedrijfsregel + Wijziging + Bedrijfsregel + Testontwerp + Niet Functionele Requirement + Randvoorwaarde + Business Objects + Business Objects + Requirement + Stakeholder + Randvoorwaarde + Stakeholder + Stakeholder + Requirement + Stakeholder Acceptatiebevindingen Use Case Model Wijzigingsvoorstel + Bevinding + Actor + Wijziging + Use Case «use» «use» Use Case Model «use» Navigation Map Bevindingen + Actor + Bevinding Use Case Specification + Use Case + Actor + Use Case «use» Design Model Traceability «use» Testontwerp Use Case Specification Software Architecture Document + BusinessObjects-Stakeholders Use Case Realization + Testontwerp + Actor + Changes-Requirements + DeploymentView + DeploymentView + Changes-UseCases + Use Case + ImplementationView Data Model + ImplementationView + Requirements-UseCases + LogicalView + LogicalView + Stakeholders-Changes «use» + ProcessView + ProcessView + Stakeholders-Requirements + UseCases-Bevindingen + UseCases-Realization + UseCases-TestCases Glossary «use» «use» «use» Testontwerp Software Architecture Document Acceptatie Test Plan + Testontwerp «use» Bevindingen Use Case Realization + DeploymentView + Testontwerp + ImplementationView + Bevinding + DeploymentView + LogicalView + ImplementationView Legend + ProcessView + LogicalView Acceptatiebevindingen Requirements Werkproduct volgen RUP op Maat + ProcessView + Bevinding Overige RUP op Maat Werkproducten
  • 31. Resultaat • Inzicht in requirements overal • Traceerbaarheid • Easy impactanalyses • Eenvoudiger Changemanagement • Eenvoudiger Configuratiemanagement • Transparantie in alle deelprocessen • Interface voor communicatie Business en ICT • PLCM !!!
  • 32. 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
  • 33. pkg RUP op M... Vision Business Obj ect Model Acceptatie Test Plan + Functionele Requirement + Bedrijfsregel + Testontwerp + Niet Functionele Requirement + Business Objects + Randvoorwaarde + Stakeholder + Requirement + Stakeholder Acceptatiebev indingen Wij zigingsv oorstel + Bevinding + Wijziging Use Case Model Nav igation Map Bev indingen Glossary + Actor + Bevinding + Use Case Testontw erp Use Case Specification Softw are Architecture Document + Testontwerp + Actor + DeploymentView + Use Case + ImplementationView + LogicalView + ProcessView Data Model Use Case Realization + DeploymentView + ImplementationView Design Model + LogicalView + ProcessView Legend Requirements Werkproduct RUP op Maat Werkproduct ARE informatie element
  • 34. Traceability pkg Traceability Vision Business Obj ect Model + Functionele Requirement Wij zigingsv oorstel + Niet Functionele Requirement + Bedrijfsregel + Wijziging + Randvoorwaarde + Business Objects + Requirement + Stakeholder + Stakeholder Use Case Model + Actor + Use Case «use» «use» «use» Use Case Specification + Actor + Use Case «use» Traceability «use» + BusinessObjects-Stakeholders Use Case Realization + Changes-Requirements + Changes-UseCases + DeploymentView + Requirements-UseCases + ImplementationView + Stakeholders-Changes + LogicalView «use» + Stakeholders-Requirements + ProcessView + UseCases-Bevindingen + UseCases-Realization + UseCases-TestCases «use» «use» «use» Testontw erp Softw are Architecture Document Acceptatie Test Plan + Testontwerp «use» Bev indingen + DeploymentView + Testontwerp + ImplementationView + Bevinding + LogicalView + ProcessView Acceptatiebev indingen + Bevinding
  • 35. Resume • Focusverschuiving • Requirements Engineering • Integreer processen • (Software) Product Life Cycle Management
  • 36. 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
  • 37. RE werkt !! Onderzoek naar successen van projectmanagementtools Standish (2001) RM tools hebben het meest invloed op het projectsucces
  • 38. Sloop de muur! REQUIREMENTS ENGINEERING !
  • 39. • VRAGEN ??
  • 40. Statistieken - Standish PROJECT SUCCES TOP TIEN Executive Support 18 User Involvement 16 Experienced Project Manager 14 Clear Business Objectives 12 Minimized Scope 10 Standard SW Infrastructure 8 Firm Basic Requirements 6 Formal Methodology 6 Reliable Estimates 5 Other 5 Reden van mislukt projecten (Standish 1995) Incomplete requirements 13,1 Lack of user involvement 12,4 RM tools hebben het meest Unrealistic explectations 9,9 invloed op het projectsucces Changing requirements/specs 8,7 Didn't need it any longer 7,5 (Standish 2001) 51,6
  • 41. 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
  • 42. ARE in OTAP
  • 43. Waarschijnlijke Oorzaken • De specificaties zijn onvoldoende duidelijk • Het specificatie proces • Voortschrijdende inzichten - changes • Communicatie business – ICT en omgekeerd
  • 44. ICT uitbesteden omdat .. • Kosten te hoog • Uit de hand lopen van projecten • Time to market • Business – ICT afstemming • Politiek
  • 45. • EINDE
  • 46. Famous examples… 1984: The IBM PCjr was a precursor to modern laptop 2005: De ontwikkeling van het NVIS computers, but it was a stagneerde in 2005 omdat de noodzakelijke financial failure. The koppeling van de bestanden 2008: Net als zoveel andere van instanties, keyboard was too small for overheidsprojecten pakt de invoering zoals het Ministerie van Justitie en de IND, normal sized fingers. People van de OV-chipkaart veel duurder uit. hoge eisen stelt aan de integriteit en de did not like them and they did beveiliging van informatie-uitwisseling. kost volgens het Algemeen Het systeem not buy them Dit blijkt complexer dan was voorzien. Er 100 miljoen euro extra Dagblad nu al bovenop de geraamde 250 miljoen en is inmiddels een doorstart gemaakt met de dat bedrag zal nog flink gaan stijgen. verdere ontwikkeling. Kost 24,3 miljoen, daarvan 4,7 miljoen vanwege haperende Onder meer toegangspoortjes, problemen met de zijn te danken aan de wijziging op privacy en het rumoer over de biometrische passport gegevens, beveiliging van de pas.
  • 47. Outline • Wat is er anders ? • Enige Statistiek , Oorzaak en gevolg • Noodzaak tot verbetering • Focus verschuiving • Oplossing • Vragen
  • 48. 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
  • 49. 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
  • 50. 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 ??
  • 51. Inderdaad …. • Uitbesteden !! • Eerst : bij derden binnen t land • Toen bij derden buiten t land (prijs) • Maar lost t iets op ??
  • 52. IT project landschap • IT project gebruikt verschillende platformen in het voortbrengingproces van software – Business Analyse en het OTAP model
  • 53. IT project’s landscape • These platforms are not sufficiently integrated • These platforms are not sufficiently integrated what results in: what results in: – Information loss at transition points – Information loss at transition points – Misinterpretation of information – Misinterpretation of information • Lost/misintrepreted information leads to: • Lost/misintrepreted information leads to: – Insufficient product quality – Insufficient product quality – Delays in development (re-work) – Delays in development (re-work) – Increased development costs – Increased development costs
  • 54. 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
  • 55. What’s the problem? Defects in the information flow (gaps, misinterpretations, etc) across platforms cause product quality problems, cost overruns, and product delays.
  • 56. Hoe gaat dat in z’n werk • ICT projecten overschrijden in tijd en of geld • ICT geeft schuld aan Business en omgekeerd • Externe toeleveranciers krijgen ALTIJD de schuld Dit is al jaren aan de gang en t verbetert niet echt !!
  • 57. ARE Tools ARE Tools support ARE Process through: • Assessing Requirements Quality • Requirements Modeling • Requirements Management • Application Lifecycle Management
  • 58. Feit 2: Veelzijdige rol van requirements Tests Implementatie Project Management Requirements Risico Design Management Gebruikers documentatie
  • 59. Feit 3: Hedendaagse praktijk Specificatie OTAP
  • 60. Resultaat • Verkeerde implementatie • Ontevreden gebruikers • Onvolledige en inconsistente documentatie • Slecht inzicht in de consequenties van wijzigingsvoorstellen
  • 61. ARE biedt Link & Transparantie • Identificeerbare stukjes informatie, die gelinkt zijn met elkaar • Voortraject gelinkt aan de OTAP informatie • Transparante informatie voorzieningen aan alle stakeholders
  • 62. ARE integreert Stakeholders ARE Feature Requirement UC Model UC Description Specificatie OTAP ARE maakt de samenhang van omgevingen mogelijk!
  • 63. 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
  • 64. Requirements Management Traceability Scheme
  • 65. Example of Requirements 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 
  • 66. Change Management • Veranderingen in requirements zijn onvermijdelijk • Het project moet zijn ingericht om wijzigingsvoorstellen zo goed mogelijk te kunnen analyseren.
  • 67. 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
  • 68. Integratie met IDE Integratie Oracle Enterprise Architect: Oracle: Requirements Implementatie van •Tabellen Architecture •Tabel definitie •Tabel relaties •Procedures Design •Scherm prototypes •Views Testen •UI Model Unit Tests
  • 69. Change Management In action • Hoe zijn de veranderingsvoorstellen bewaard? • Hoe kan de technische analyse ondersteund worden door een tool
  • 70. Vragen ?
  • 71. De realiteit … • Is t wel echt goedkoper ? • Time to market ? • Waar is de materie/domein kennis gebleven ? • Kan ik straks nog terug ?