Hoorcollege SDM1 Mario van Vliet 21 Maart 2006 - 1 -

Colleges worden gegeven op de volgende data: 21 Maart 4 April (Gastcollege: IT Projectmanager op een Philips project) 18 April 9 Mei 23 Mei 6 Juni - 2 - 2

Onderwerpen die in SDM1 aan bod komen Projectmanagement Metrics Component Based Development : vandaag Projectplanning Business Planning Technical Planning Rollen van Projectmanager Qualitymanager Contract Owner Public Relations Manager Director Planningsmethodieken PERT CPM Work Breakdown structure Gantt-charts Quality Management Risk Management - 6 -

Component Based Development Mario van Vliet

Content Component Based Software Engineering (CBSE): Wat is het? Domain Engineering ReUse Component Based Development Standaardpakketten Slotopmerkingen

Waar denk je aan bij Component Based Development ? ReUse Snelheid van ontwikkeling Kopen, niet ontwikkelen (‘Commercial off-the-shelf’ (COTS)) Van programmeren naar componeren Van ontwerpen naar selecteren Kostenefficient Onderhoud van de componenten (bibliotheek)

Component Based Software Engineering: een definitie ‘Component Based Software Engineering (CBSE) is changing the way software systems are developed. CBSE embodies the ‘buy, don’t build’ philosophy…… CBSE shifts the emphasis from programming software to composing software systems. Implementation has given way to integration as the focus. At its foundation is the assumption that there is sufficient commonality in many large software systems to justify developing reusable components to exploit and satisfy that commonality’ Clements 1995

Engineering of component-based systems Fasen Fase 1 Definiëren Informatie- systeem Fase 2 Ontwerpen Informatie- systeem Fase 3 Realiseren Informatie- systeem Fase 4 Invoeren Informatie- systeem Vragen: Is COTS beschikbaar voor het invullen van de requirement ? Zijn intern ontwikkelde modules beschikbaar voor het invullen van de requirement ? Zijn de interfaces voor de beschikbare componenten compatible voor de architectuur van het systeem dat gebouwd gaat worden? Stappen Vaststellen Systeem Behoeften Definitie studie Requirements Analyse Functioneel Ontwerp Functionele Specificatie Haalbaarheids- studie Haalbaarheids Rapport Nee Technisch Ontwerp Technische Specificatie Ja Component Based Development Documenten

Engineering of component-based systems Indien antwoord ja dan: wordt de engineering van component based development opgestart. Dat moet invulling geven aan de volgende aspecten: Identificeren van de componenten die kandidaat zijn voor implementatie; Kwalificeren van de interfaces van de componenten; Adapteren van de componenten in de architectuur; Updaten van de componenten ten gevolge van veranderingen in de requirements. CBSE Process: Domain Engineering: Library Functie Component Based Development: Implementatie Functie Formeel onderscheid maken tussen het onderhouden van de ‘standaard’ componenten en de geïmplementeerde componenten. Bij updates zijn de standaard componenten leidend!

CBSE Domain Engineering Component Based Development Domain Analysis Software Architecture Development ReUsable Component Model Structural Library Repository Components Component Based Development Analysis Architecture Design Component Compositie Update Adaptatie Kwalificatie Engineering Testen Applicatie Software Implementatie

Domain Engineering Belangrijkste functies: Analyse Analyse, Constructie en Verspreiding Analyse Selecteren functie of object, definiëren taxonomy, indentificeren common features, indentificeren speciale relaties, deriveren functional model, definiëren domein taal ReUse: Is de functionaliteit nodig voor toekomstige implementaties? Wat is de graad van herbruikbaarheid (commonality)? Is er duplicatie van de functies in het domein? Is de component hardware dependent? Is het ontwerp optimaal voor toekomstige implementaties? Kunnen we een non-reusable component herparameteriseren zodat het reusable wordt? Is het nuttig een component te decomponeren cq. herparameteriseren voor reuse?

Domain Engineering Verspreiden Product/Technology Process People Characteriseren per component: 1: Niet relevant voor Reuse 2: Relevant voor reuse alleen onder ongebruikelijke omstandigheden 3: Relevant: Het component kan toegepast worden voor Reuse, ondanks verschillen 4: Duidelijk relevant: Het component kan toegepast worden, maar gebruik zal inefficient zijn 5: Duidelijk relevant: Het gebruik van de component is ineffectief en wordt niet aangeraden Product/Technology Requirements Stability Concurrent Software Memory Constraints Application Size User Interface Complexity Programming Languages Safety/Reliability Lifetime Requirements Product Quality Product Reliability Process Process Model Process Conformance Project Environment Schedule Constraints Budget Constraints Productivity People Motivation Education Experience/Training Application domain Process Platform Language Development Team Productivity

Component Based Development Component Kwalificatie Waarborg dat het component de: gewenste functie uitvoert; ‘past’ in de architectuur en; het de karacteristieken uitvoert die gewenst zijn (performance, stabiliteit en usability). Component Adaptatie Waarborg dat de component makkelijk integreert in de architectuur: consistente methode van resource management voor alle componenten; common activiteiten voor bv data management voor alle componenten; interfaces tussen componenten en met de buitenwereld zijn op een consistente manier ontwikkeld. Component Compositie Common Architecture Environment Data Exchange model; Automation; Structured Storage; Underlying Object Model.

Standaardpakketten Wat zijn standaardpakketten? Recente ontwikkelingen Verschil implementatie ‘maatwerk’ versus implementatie ‘standaardpakketten’ Toekomstige ontwikkelingen

Wat zijn standaardpakketten? Standaard software ontwikkeld voor specifieke bedrijfprocessen; ‘Buy don’t build’ (niemand is volledig uniek); Onderhoudbaarheid; Schaalvoordelen; Sterke ontwikkeling laatste jaren (verschuiving van maatwerk naar standaardpakketten); ‘Enabler’ van procesmatig werken (BPR); ‘Best practice’ bedrijfsprocessen ingebouwd; Gestart in de ERP omgeving (‘Enterprise Resource Planning’) = primaire bedrijfsprocessen, uitgebreid naar allerlei andere omgevingen (b.v. planningspakketten, HR-pakketten, consolidatiepakketten, seismologische pakketten, GIS pakketten …… ); Grote verandering in methode implementatie van softwaresystemen.

Systeem ontwikkeling versus pakketimplementatie Mate van reengineering / bedrijfswaarde Verschil 1 op 1 reengineering obv pakket innovatie Maak maximaal gebruik van pakket bij realisatie toekomstvisie (bedrijfs gedreven, beperkt door technologie) Ga uit van huidige situatie, alleen wijzigingen voorzover pakket dit vereist (technologie gedreven) Ontwerp en realisatie toekomstvisie zonder beperkingen (bedrijfsgedreven, echte innovatie, verandert denken en handelen van mensen) Implementatiesnelheid BPR Quality Management, Risico Management, Project Management, Human Factors etc. Wat Blijft?

Pakket Implementatie benchmarks: Management Factors Impact on Project Outcomes Use of formal project estimating Use of structured project planning Formal tracking and measurement Quality control Human Factors Impact on Project Outcomes Experienced management Experienced staff Experienced clients Key specialists available Technical Factors Impact on Project Outcomes Effective technologies Adequate tool suites Stable requirements More than 50% component reuse Conclusie: bij implementatieprojecten vormen het management en de menselijke/sociale factoren de belangrijkste risico’s; technologie factoren kunnen vertragend werken, maar leiden minder tot stopzetten Source: Software Productivity Research

Kernconcepten van pakketimplementatiemethoden 1. Procesdenken Geïntegreerde benadering 3. Verandermanagement 4. Verbeteragenda 5. Value propositie 6. Snelheid Relatie Fusion concepten en PER concepten 1. procesdenken procesmodelleren (current state, future state) processenklantgericht (klant van de klant) invullen 2. geïntegreerde benadering pakket enabeler 3. verbeteragenda en value propositions focus op waardetoevoeging focus op business case (= kosten/baten/risico analyse) 4. management van verandering relatie PER en BCI 5. snelheid kwaliteit, doorlooptijd en kosten

Kernconcepten van pakketimplementatiemethoden 1. Procesdenken Geïntegreerde benadering 3. Verandermanagement 4. Verbeteragenda 5. Value propositie 6. Snelheid Relatie Fusion concepten en PER concepten 1. procesdenken procesmodelleren (current state, future state) processenklantgericht (klant van de klant) invullen 2. geïntegreerde benadering pakket enabeler 3. verbeteragenda en value propositions focus op waardetoevoeging focus op business case (= kosten/baten/risico analyse) 4. management van verandering relatie PER en BCI 5. snelheid kwaliteit, doorlooptijd en kosten

Procesdenken Beleid Klantorder fulfillment Produktie Inkoop Support Megaprocessen Hoofdprocessen strategie en beleid Produkt en pro- ces ontwerp marketing produktie planning en bewaking leveranciers selectie en contracten produkt ontwerp financiën account mgt en verkoop order verwerking facturering en deb.bewaking after sales support onderhoud distributie materiaal verwerving crediteuren bewaking en betalingen vendor rating proces personeel IT kwaliteit, arbo en milieu 1 Procesdenken In tegenstelling tot het denken in afdelingen (voorbeeld inkoop) 6 megaprocessen Enterprise model (standaard nadere onderverdeling hoofdprocessen, vervolgens procesdecompositie A4 onschatbare waarde om het geheel te overzien, makkelijk praatplaatje Geeft inzicht in wat voor een soort bedrijf het is Ter bepaling scope Matrix afd-procesmodel, geeft inzicht wie doet wat en welke mensen bij het project betrokken moeten worden proces walk through, loop letterlijk door het proces, geeft inzicht Business process dient onderscheiden te worden van hierarchische of organisatorische structuren. Zijn business process laat zien hoe de organisatie waardetoevoeging levert. Hoge niveaus: management, handling Lage niveaus: werkwoord Mega Process, Major process, meerdere subprocess, activiteiten (een persoon, een plaats, een operational mode: batch/online/manual)

Procesdenken - Denken vanuit uw klanten Klant gericht denken Processen Taking a business process approach implies adopting the customer's point of view. Business processes are the structure by which an organization does what is necessary to produce value for its customers. Because they are the final arbiters of business process performance, customers should be represented throughout all phases of a business process management program. The customer's point of view should predominate within the design of the business process, as well as in the overall design of any corresponding applications. Each step in the business process should add value, and then pass a result on to the next step. For each step, the next step is a customer. A well-designed business process makes products whose utility for the customer is clear, or provides services of manifest value. Value propositions Value propositions are customer-centered. When a customer is thinking about making a commitment to a new project, he or she will ask the question: "What's in it for our company?" or "How will our business benefit?" The project team is responsible for providing the customer with complete value propositions. This means identifying the performance issues, what opportunities exist to address the issues, and what potential answers exist to realize the benefits from the opportunity. The value proposition is not complete without all of this information. For example: If the customer reduces total product lead time by 50%, then inventory (and associated costs) can potentially be reduced by 2x. If ABC Company improves its product distribution channels by 2x, then distribution costs can potentially be reduced by 10x. If you improve the data processing technology to industry norms, then the customer will provide response to inquiries potentially 50% faster, resulting in improved customer satisfaction. If the XYZ company implements Total Quality Management (TQM) philosophies, then the quality of your product or service can be enhanced by as much as 3x.

Proces modelleren - Business thread/scenario’s versus functionele organisaties expeditie facturatie verkoop orderbeheer Functionele Organisatie business transacties order invoer reserverenorder controleren krediet genereren documenten genereren factuur betalingen verwerken Process thread: verkooporder voorbereiden+verzamelen business scenario verkooporder binnenland business scenario verkooporder export order invoer lang (extra data) reserverenorder uitgebreid krediet controleren Voorbereiden + verzamelen genereren export documenten genereren export factuur betalingen verwerken order invoer kort normaal controleren genereren pakbon factuur oplossingsobjecten

Geïntegreerde benadering c h n o l g ie Mensen P r s 2 Geïntegreerde benadering Denkkader in iedere fase van een project, bij iedere stap denk aan alle drie, natuurlijk afhankelijk van problematiek nadruk ene keer meer op mensaspect, andere keer op techniek of processen. Het mensaspect wordt nogal eens vergeten. Bemanning project Process: business consultants (logistiek, financieel , application consultants Techniek: application consultants, technical infrastructure consultants Mens: verander management consultants

Snelheid Timeboxing Prototyping Infrastructuur Gezamenlijke Sessies Opdeling Timeboxing Gezamenlijke Sessies High Performance Teams Prototyping Iteraties infrastructure technische infrastructuur die het mogelijk maakt snel met elkaar te kunnen communiceren efficiente projectorganisatie met duidelijke communicatei en beslissingslijnen voorbeelden: aparte projectkamer met pc netwerk en lotus notes database, modelleringshulpmiddelen partitioning opdelen project dat wat pararallel kan worden uitgevoerd parallel uitvoeren, voorbeeld debiteuren crediteuren parallel timeboxing doorlooptijd staat vast, resultaat niet, beter een acceptabele oplossing dan geen optimale oplossing joint sessions doel: met belangrijkste betrokkene samen komen tot overeenstemming over eindresultaten voordelen: acceptatie van eindresultaten via samenwerking, efficient gebruik van tijd van betrokkenen goed voor team-building, gebruik bij start van project (bijvoorbeeld opstellen verbeteragenda, bepalen scope) Facilitated sessions high performance teams alle disciplines bij elkaar, samenstelling teams van korte duur om snelle slagen te kunnen maken, daarna weer ontbinden iteration doelstelling: meerdere malen dezelfde volgorde van stappen uitvoeren, maar iedere cyclus weer een detailniveau dieper van grof naarfijn werken prototying het abstract gemodelleerde concreet maken met een werkend voorbeeld, (PER al in een heel vroeg stadium het pakket introduceren), gebruiker en ontwikkelaar van gedachtewereld en taal snel naar elkaar toe laten komen

6. Ondersteunen Technische Infrastructuur Hoofdfasering Pakket implementatie Opstellen verbeter- agenda 5. Bewaken Projecten 1. Ontwikkelen blauwdruk/ pakketselectie 2.Ontwerpen PMT 3. Realiseren PMT 4. Invoeren PMT 6. Ondersteunen Technische Infrastructuur In versie 4.1 is een aparte view (wordt weliswaar ook fase genoemd) gedefinieerd, genaamd ‘Learning Solutions’ Deze view biedt een ingang naar de verschillende typen trainingen die in het gehele traject plaatsvinden. Voorbeelden: Core Team Training Acceptance Testing Training Train the Trainer Technical Training End User Training Help Desk Training 7. Opbouwen kennis

Fase 1: Ontwikkelen blauwdruk /pakketselectie 1.5 selectie/fit analyse 1.1 Opstellen project definitie Bepalen KFK’s Opstellen longlist Opstellen shortlist 1.6 Definiëren kosten/baten/risico’s + opstellen plan voor fase 2 Bepalen keuze In deze fase wordt na het vastleggen en analyseren van de huidige situatie een blauwdruk vastgelegd van de toekomstige situatie en vindt de pakketselectie plaats (dan wel de fit-analyse wanneer de pakketkeuze bij voorbaat vast staat). In de blauwdruk worden de toekomstige processen, de organisatie kenmerken, het besturingsmodel en de daaruit voortvloeiende automatiseringswensen vastgelegd. Steeds meer wordt bij het ontwerpen van de blauwdruk gebruik gemaakt van best practices (“Kunnen we gebruik maken van geslaagde elders doorgevoerde concepten?”) en benchmark gegevens (“Waar scoren wij slecht op in vergelijking met onze concurrent?”). Moret & Ernst Young beschikt over een uitgebreide database met benchmarkgegevens en best practices om hierin te ondersteunen. De tijd en aandacht die aan deze eerste fase wordt besteed varieert in de praktijk aanzienlijk, en hangt onder meer af van de volgende factoren: de mate waarin prestatieverbeteringen wenselijk zijn; de mate waarin reeds duidelijkheid bestaat omtrent de gewenste situatie (de blauwdruk); de eventuele tijdsdruk in situaties waarbij er een deadline is waarop de implementatie afgerond moet zijn. vergelijking met PER-US 1.1 komt overeen met onderdelen van Phases: Program and Life Cycle Management Improvement Portfolio Development 1.2 Ontwikkelen proces- model huidige situatie 1.3 Analyseren huidige situatie

2.5 Voeren contractonderhandelingen Fase 2: Ontwerpen PMT Referentie- modellen Voorbereiding Globale Toetsing 2.1 Ontwikkelen Detail Proces Model o.b.v. Blauwdruk en Pakket 2.2 Inrichten Simulatie- omgeving 2.3 Package Walkthrough 2.4 Ontwikkelen realisatieplan In het ontwerptraject worden de processen vastgelegd. Tevens wordt bepaald welke systeemfuncties deze procesflows ondersteunen. Resultaat van deze fase is een ontwerp waarbij aangegeven is hoe processen worden ondersteund door het systeem en door wie (rollen) deze worden uitgevoerd. Tevens levert deze fase het inzicht op met betrekking tot: de interfacing met andere applicaties; de maatwerk specificaties; de conversiestrategie; de eisen aan de technische infrastructuur. Veelal zal de procesflow worden beïnvloed door bijvoorbeeld: de klantgroep, markt, leveranciers, geografische segment, distributiekanaal of het product/service. Het is van belang om dit in een vroeg stadium in kaart te brengen en de eisen aan deze flows vast te leggen. Zo niet, dan zal dit pas naar boven komen in de testfase, dan wel het ‘live’ gaan. De voor het bedrijf kritische processen worden met het systeem in een workshop doorlopen. Als de resultaten bevredigend zijn wordt definitief gekozen voor het pakket en worden de contractonderhandelingen afgerond. Met name het inzicht in de maatwerkspecificaties is van groot belang voor de contractonderhandelingen met de leverancier. 2.5 Voeren contractonderhandelingen

3.5 Ontwikkelen trainingsmateriaal Fase 3: Realiseren PMT Diverse iteraties 3.3 Toetsen oplossing in Conference Room Pilot (CRP) 3.1 Uitwerken procesmodel 3.2 Uitwerken IT component 3.4 Rapportage 3.6 Opstellen plan invoeringsfase Het realiseren van de uiteindelijke oplossing zal in één of meerdere iteratiestappen plaatsvinden. Iedere iteratiestap zal bestaan uit voorbereiding, integrale toetsing en rapportage. Allereerst zal het ontwerp worden ontwikkeld. Dit ontwerp is een samenhangend geheel van procesbeschrijvingen, organisatiestructuur en rolbeschrijvingen, systeemfuncties, aanpassingen aan het pakket, systeem configuratie, interfaces, procedures, conversie software etc.. Deze stap is in PER-NL onderverdeeld in een proces/organisatie gedeelte en een softwaregedeelte. Vervolgens wordt in de conference roompilot door middel van scripts de gerealiseerde oplossing plenair getoond. Eventuele alternatieven worden uitgewerkt, waarbij de impact van deze mogelijke oplossingen wordt geëvalueerd. De voorgestelde oplossing wordt goedgekeurd, dan wel afgekeurd waarbij de uitwerking van de oplossing in een volgende iteratie-stap zal plaatsvinden. 3.5 Ontwikkelen trainingsmateriaal en -programma

3.5 Ontwikkelen trainingsmateriaal Projectaanpak fase 3: Realiseren PMT Diverse iteraties 3.1 Uitwerken procesmodel 3.3 Toetsen oplossing in Conference Room Pilot (CRP) 3.2 Uitwerken IT component 3.4 Rapportage 3.6 Opstellen plan invoerings fase 3.2 Uitwerken IT-component 3.5 Ontwikkelen trainingsmateriaal en -programma Configureren van ontwikkel- en CRP-omgeving Uitwerken planning iteraties Ontwikkelen maatwerk Ontwikkelen interfaces Ontwikkelen conversie programmatuur Hier hoort ook integration testing bij: testen van interface tussen maatwerk en applicatie testen van interface tussen maatwerk en externe applicaties testen oplevering volgens specificaties Integration test wordt in principe niet door de ontwikkelaar maar door een test team gedaan

4.2 Trainen eindgebruikers Fase 4: Invoeren PMT 4.1 Voorbereiden invoeringsstap 4.3 Dataconversie 4.4 Uitfaseren legacy systems 4.6 Live gaan 4.7 Post implementatie 4.5 Monitoren Implementatie Voorbereiding start met het opbouwen van een team op de site bestaande uit kern team en site mensen. Eindgebruikerstraining kan in principe zo snel mogelijk beginnen. De live-omgeving wordt ingericht, waarbij ook de dataconversie dient te worden uitgevoerd. Tevens dient een plan te worden gemaakt welke legacysysteems op welk moment worden uitgefaseerd en dient dit met gebruikers te worden gecommuniceerd. In deze fase is beschikking over een aantal checklisten o.a. om te controleren of het moment van live gaan daar is. 4.2 Trainen eindgebruikers

Fase 6: Ondersteunen Technische Infrastructuur 6.1 Identificeren technologie infrastructuur behoefte 6.2 Verkrijgen technologie infrastructuur 6.3 Implementeren en testen technologie infrastructuur 6.4 Onderhouden en registreren technologie infrastructuur

Slotopmerkingen CBSE/standaardpakketten veranderen een implementatie van ‘programmeren naar componeren’ en van ‘ontwerpen naar selecteren’; Integratie van modules binnen bestaande architectuur wordt steeds belangrijker: interfaces; Maatwerk rondom de standaardapplicaties cq. module wordt complexer en moet worden geïntegreerd; Aspecten met betrekking tot wat is leidend, mijn ‘requirement’ of het ‘pakket’ worden belangrijke issues; Management en ‘human factors’ blijven de belangrijkste aspecten voor het welslagen van een implementatie.