Hoorcollege SDM1
-
Upload
tamekah-fitzgerald -
Category
Documents
-
view
58 -
download
0
description
Transcript of Hoorcollege SDM1
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.