Hoorcollege SDM1

21 Maart 2006Mario van Vliet

- 1 -

Data

• 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 -

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

- 5 -

Content

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

- 6 -

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)

- 7 -

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

- 8 -

Engineering of component-based systems

Fase 1DefiniërenInformatie-

systeem

Fase 1DefiniërenInformatie-

systeem

Fase 2OntwerpenInformatie-

systeem

Fase 2OntwerpenInformatie-

systeem

Fase 3RealiserenInformatie-

systeem

Fase 3RealiserenInformatie-

systeem

Fase 4Invoeren

Informatie-systeem

Fase 4Invoeren

Informatie-systeem

Fase

nS

tap

pen

Docu

men

ten

VaststellenSysteem Behoeften

Definitie studie

Requirements Analyse

FunctioneelOntwerp

Functionele Specificatie

Haalbaarheids-studie

HaalbaarheidsRapport

Technisch Ontwerp

Technische Specificatie

Nee

Ja Component Based Development

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?

- 9 -

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!

- 10 -

Domain Engineering

Domain Analysis

Domain Analysis

SoftwareArchitectureDevelopment

SoftwareArchitectureDevelopment

ReUsableComponent

Development

ReUsableComponent

Development

DomainModel

DomainModel

StructuralModel

StructuralModel

Component

LibraryRepositoryReUsable

Components

Component Based Development

AnalysisAnalysis Architecture Design

Architecture Design

ComponentCompositie

ComponentCompositie

ComponentUpdate

ComponentUpdate

ComponentAdaptatie

ComponentAdaptatie

ComponentKwalificatie

ComponentKwalificatie

ComponentEngineering

ComponentEngineering

TestenTesten

ApplicatieSoftware

Component

Implementatie

CBSE

- 11 -

Domain Engineering

• Belangrijkste functies:– 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?

- 12 -

Domain Engineering

• Verspreiden– 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

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

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

People- Motivation- Education- Experience/Training

- Application domain- Process- Platform- Language

- Development Team- Productivity

- 13 -

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.

- 14 -

Standaardpakketten

• Wat zijn standaardpakketten?

• Recente ontwikkelingen

• Verschil implementatie ‘maatwerk’ versus implementatie ‘standaardpakketten’

• Toekomstige ontwikkelingen

- 15 -

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.

- 16 -

Systeem ontwikkeling versus pakketimplementatie

Mate van reengineering / bedrijfswaarde

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)

1 op 1reengineering

obv pakket innovatie

Implementatiesnelheid

BPR

Verschil

Quality Management, Risico Management, Project Management, Human Factors etc. Wat Blijft

?

- 17 -

Impact Cancel Delays On-time EarlyWorst Case 40% 45% 15% 0%Best Case 1% 2% 78% 19%

Impact Cancel Delays On-time EarlyWorst Case 45% 45% 10% 0%Best Case 1% 2% 79% 18%

Management Factors Impact on Project Outcomes Use of formal project estimating Use of structured project planning Formal tracking and measurement Quality control

Impact Cancel Delays On-time EarlyWorst Case 15% 75% 10% 0%Best Case 1% 22% 62% 15%

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

Source: Software Productivity Research

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

Pakket Implementatie benchmarks:

1. Procesdenken

2. Geïntegreerde benadering

3. Verandermanagement

4. Verbeteragenda

5. Value propositie

6. Snelheid

Kernconcepten van pakketimplementatiemethoden

People Process

Technology

1. Procesdenken

2. Geïntegreerde benadering

3. Verandermanagement

4. Verbeteragenda

5. Value propositie

6. Snelheid

Kernconcepten van pakketimplementatiemethoden

People Process

Technology

- 20 -

Procesdenken

Beleid

Klantorderfulfillment

Produktie

Inkoop

Support

Megaprocessen Hoofdprocessen

strategie enbeleid

Produkt en pro-ces ontwerp

marketing

produktieplanning enbewaking

leveranciersselectie encontracten

produktontwerp

financiën

account mgten verkoop

orderverwerking

facturering endeb.bewaking

after salessupport

produktie onderhoud

distributie

materiaalverwerving

crediteurenbewaking enbetalingen

vendorrating

procesontwerp

personeel ITkwaliteit, arboen milieu

- 21 -

Procesdenken - Denken vanuit uw klanten

- 22 -

Proces modelleren - Business thread/scenario’s versus functionele organisaties

business scenario verkooporder binnenland

business scenario verkooporder export order invoer

lang

(extra data)

reserverenorder

uitgebreid krediet controleren

Voorbereiden

+

verzamelengenereren export documenten

genereren

export factuur

betalingen verwerken

order invoer kort

normaal controleren

genereren pakbon

genereren

factuur

oplossingsobjecten

business transacties

order invoer

reserverenorder

controleren krediet

genereren documenten

genereren factuur

betalingen verwerken

Process thread: verkooporder voorbereiden+

verzamelen

expeditie facturatie

verkoop

orderbeheer

Functionele

Organisatie

Geïntegreerde benadering

Technologie

Mensen

Proces

Snelheid

Infrastructuur

Opdeling

Timeboxing

Gezamenlijke Sessies

High Performance Teams

Prototyping

Iteraties

- 25 -

Hoofdfasering Pakket implementatie

1. Ontwikkelen blauwdruk/

pakketselectie

2.Ontwerpen PMT

3. Realiseren PMT

6. Ondersteunen Technische Infrastructuur

4. Invoeren PMTOpstellen

verbeter-agenda

5. Bewaken Projecten

7. Opbouwen kennis

- 26 -

Fase 1: Ontwikkelen blauwdruk /pakketselectie

1.1

Op

stel

len

pro

ject

def

init

ie

1.2 Ontwikkelen proces-model huidige situatie

1.3 Analyseren huidigesituatie

1.4 Ontwikkelen Blauwdruk

Bepalen KFK’s

Bepalen keuze

Opstellen longlist

Opstellen shortlist

1.5 selectie/fit analyse

1.6

Def

inië

ren

ko

sten

/bat

en/r

isic

o’s

+

op

stel

len

pla

n v

oo

r fa

se 2

- 27 -

Fase 2: Ontwerpen PMT

Referentie-modellen

2.1 OntwikkelenDetail ProcesModel o.b.v.

Blauwdruk en Pakket

2.2 InrichtenSimulatie-omgeving

2.3 PackageWalkthrough

Voorbereiding Globale Toetsing

2.5 Voeren contractonderhandelingen

2.4 Ontwikkelen realisatieplan

- 28 -

Fase 3: Realiseren PMT

3.3 Toetsen oplossing

in Conference Room Pilot (CRP)

3.4 Rapportage

3.5 Ontwikkelen trainingsmateriaal en -programma

3.1 Uitwerken procesmodel

3.2 Uitwerken IT component

3.6 Opstellen plan invoeringsfase

Diverse iteraties

Projectaanpak fase 3: Realiseren PMT

3.3 Toetsen oplossing

in Conference Room Pilot (CRP)

3.4 Rapportage

3.5 Ontwikkelen trainingsmateriaal en -programma

3.1 Uitwerken procesmodel

3.2 Uitwerken IT component

3.6 Opstellen plan invoerings fase

Diverse iteraties

Configureren van ontwikkel- en CRP-omgeving Uitwerken planning iteraties Ontwikkelen maatwerk Ontwikkelen interfaces Ontwikkelen conversie programmatuur

3.2 Uitwerken IT-component

- 30 -

Fase 4: Invoeren PMT

4.2 Trainen eindgebruikers

4.3 Dataconversie

4.4 Uitfaseren legacy systems

4.5 Monitoren Implementatie

4.1 Voorbereideninvoeringsstap

4.6

Liv

e g

aan

4.7

Po

st im

ple

men

tati

e

- 31 -

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

- 32 -

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.