Situationsbestemt metodevalg Hvordan får vi i en konkret situation valgt og tilrettet en udviklingsproces  Astrid Lumbye 2002 Objektorienteret systemudvikling

Situationsbestemt valg Sker udfra projektets karakteristika der omfatter følgende grupper strategier for udviklingsprocessen, f.eks. brugerinddragelse, dedikeret udvikling hvad processen skal optimeres udfra, f.eks. Økonomisk forudseelighed (estimerbarhed) projektets specifikke risici standardkarakteristika, f.eks. størrelse og lokation af projektgruppe, kritiskhed af fejl m.m. Valget danner udgangspunkt for den projektspecifikke tilretning  Astrid Lumbye 2002 Objektorienteret systemudvikling

Situationsbestemt tilpasning Projektstyring Projektmodeller Framework Projektkarakteristika Kvalitetssikring Test og Systemudvikling Projektets proces Behov Produkt Produkt- aflevering Aftale Projektets model  Astrid Lumbye 2002 Objektorienteret systemudvikling

Situationsbestemt tilpasning Hovedgrupper af standard karakteristika Produktfaktorer f.eks. Krav til software "reliability" (kritiskhed af fejl) Platformsfaktorer Personnelle faktorer f.eks. Kvalifikationer indenfor analyse, design og programmering Erfaring med værktøjer og sprog Projektfaktorer f.eks. Projektgruppestørrelse Brug af udviklingssoftware (automatiseringer og værktøjsunderstøttelse f.eks. generatorer, udviklingsmiljøer og CASE) Projektgruppens placering (rækker fra fysisk"multisite" til fælles projektgrupperum)  Astrid Lumbye 2002 Objektorienteret systemudvikling

Situationsbestemt tilpasning Eksempler på betydende karakteristika projekttype (f.eks. Nyudvikling, videreudvikling/systemfornyelse) projektstørrelse (antal mennesker) systemtype (f.eks. administrativt datatungt) udviklingsmiljø(er)/arkitektur Tilpasningen indebærer valg af projektmodel udvælgelse af produkter udvælgelse af aktiviteter valg af ressourcetyper (profiler)  Astrid Lumbye 2002 Objektorienteret systemudvikling

Situationsbestemt tilpasning Karakteristika for udviklingsmiljøer/arkitektur Systemtyper standalone client/server distribuerede systemer Udviklingsmiljøtyper “total” håndkodning komponentbaseret udvikling framework-/genereringsbaseret udvikling customisering af standardsystem Ny/kendt teknologi Struktur/funktionalitet, ikke længere et problem da al funktionalitet er fordelt i strukturen. Opgaven opdeles derfor udfra strukturen. Grænsefladen har kun sekundærrolle her, kun operationskald skal tilføjes på grænsefladen, og det kan hvem som helst gøre udfra tidligere dokumentation - anbefaling - enten ”operationskalds ansvarlig” laver alle, eller hver prototypeprogrammør tilføjer egne kald. Hvor startes - afhængigt af subprojektering, størrelse af klasser , afhængighed mellem klasser …… Iterationer - kun ved fejl i programmer eller subprojecter….. Teamwork Så længe kontrakten mellem anvender og implementør overholdes er teamwork på implementationsniveau ikke nødvendigt, men … Koordineringe af hvornår hvad er færdigt er væsentligt aht. Især whiteboxtest for anvender og integrationstest.  Astrid Lumbye 2002 Objektorienteret systemudvikling

Eksempler på tilretning Projektet kan have specielle behov f.eks. Minimering af risici mht. arkitektur medfører anvendelse af arkitektur-prototyper Specifikke krav til dokumentationen udvælge netop de nødvendige modelleringsteknikker Krav om brugerinddragelse i kravanalyse medfører f.eks. udstrakt anvendelse af grænseflade-prototyping Krav om hurtig/billig systemudvikling begrænse antallet af milepæle/låsninger af modeller og begrænse vedligeholdet af disse modeller aflevering i delleverancer  Astrid Lumbye 2002 Objektorienteret systemudvikling

Eksempel - arkitekturprototype Anvendes til at afprøve arkitekturen tidligt i et projekt ved ny/ukendt teknologi/arkitektur Kan anvendes til enten bare at få ”hul igennem” eller til at få bygget ”skelettet” af applikationen Igangsætning Implementering Design Analyse Afgrænse og definere Iteration 2 Iteration 1 Er typisk første iteration eller de første iterationer i et inkrementelt udviklingsforløb  Astrid Lumbye 2002 Objektorienteret systemudvikling

Eksempel - opdeling af projektet An D I Sekventielt delprojekt Delprojekt 1 A D I Iterationer i delprojekt 1 2 3 4 Delprojekt Parallelle delprojekter  Astrid Lumbye 2002 Objektorienteret systemudvikling

Objektorienteret systemudvikling Formål med opdeling Delprojekter adressering af risici store systemer krav om hurtige leverancer Subsystemer mange udviklere krav om uafhængige leverancer (moduler) krav om fleksible løsninger (plug and play) Fordele ved disse arbejdsformer er kontinuerlig tilretning af i projektet systemud-viklingsprocessen baseret på egne erfaringer kort reaktionstid på ændrede vilkår  Astrid Lumbye 2002 Objektorienteret systemudvikling

Delprojekter og subsystemer Opdeling i delprojekter kræver at klassemodellen er inddelt i uafhængige dele (subsystemer) for at udviklingen kan blive effektiv Jagttegn Personoplysninger Person «interface» Riffelprøve Bueprøve Prøve BeståedePrøver 1..1 prøve jagttegn 1..* personoplysninger person 0..* HUSK delprojekter må ikke være afhængige af hinanden!  Astrid Lumbye 2002 Objektorienteret systemudvikling

Eksempel - videreudvikling Udgangspunktet det eksisterende system Typen af videreudvikling facelifting ændring i eksisterende funktionalitet tilføjelse af ny funktionalitet Strategier produktstrategien og kundens IT-strategi Tag ikke flere nye ting i brug i et videre-udviklingsprojekt end produktet, situationen og bemandingen kan bære Videreudvikling tager udgangspunkt i den aktuelle situation Beskriver processen omkring udvikling af releases: Alle SMR (fejl og ændringsønsker) registreres i LECs SMR værktøj. Med regelmæssige mellemrum vurderes de i relation til de releases, som er fastlagt i grundlag for videreudvikling. I forbindelse med vurderingen er der 2 sæt kriterier: Dels deres forretningsmæssige relevans, dels hvorledes de passer ind i de allerede fastlagte releases. Releases udvikles præcis som LEC udviklingsprojekter, dvs. alle SMR udvikles samlet. Der gives en løbende status på fremdrift.  Astrid Lumbye 2002 Objektorienteret systemudvikling

Situationsbestemt tilpasning Fremgangsmåde Identificer projektets karakteristika Planlæg processen vælg projektmodel udvælg produkter udvælg aktiviteter Brug kvalitetssikring/andres erfaringer At planlægge processen er en forudsætning for at kunne planlægge og estimere projektet Produkter, proces, størrelse, kompleksitet, bemanding, m.m.  Astrid Lumbye 2002 Objektorienteret systemudvikling

Objektorienteret systemudvikling Husk Projektstyring Systemudvikling Projekt Videre-udvikling Aftale-indgåelse Bruger-tilslutning Kvalitetssikring Test Projekt-model Samlet overblik over ’apparatet’. Når man snakker systemudvikling, taler man som regel om de faglige aktiviteter som analyse, programmering, test. I virkeligheden indgår der en lang række andre faktorer, som ofte har stor indflydelse på, om man får succes eller fiasko. På LEC har man gennem årene gjort et stort stykke arbejde for at samle erfaringerne op og samle dem i procedurer. Denne slide viser nogle af de vigtigste procedurer til at håndtere de forhold der ligger ud over selve systemudviklingen. To nyeste skud på stammen er kravstyring og videreudvikling, som jeg kommer tilbage til. I midten har vi så SU-aktiviteterne. Som det vil fremgå af det følgende, så går udviklingen i retning af at samle de forskellige typer af systemudvikling i en fælles, generisk model, som så indeholder specialiseringer, hvor det er nødvendigt. Argumentet er, at lighederne mellem de forskellige typer af systemudvikling er større end forskellene. Der er altid behov for tilpasning!  Astrid Lumbye 2002 Objektorienteret systemudvikling