Introduktion til Systemudvikling Peter Carstensen

1. Introduktion tilSystemudvikling Peter Carstensen

2. Systemudvikling - kommunikation og samarbejde Indhold: • En case fra det virkelige liv • Kompleksitet i systemudviklingen • Behov for styring og interaktion • Tilgange til - og metoder for - systemudvikling • Kommunikationsudfordringer ? • Den professionelle systemudvikler?

3. Systemudvikling i praksis ”Det fungerer fint når vi er to - når vi bliver fire er det noget rod !” Et feltstudie med fokus på: - Softwareudvikling i en fremstillingsvirksomhed - Samordning og koordinering af arbejdet - De hjælpemidler der blev brugt til at støtte processen

4. Foss Electric A/S • Designer og producerer instrumenter til kvalitetsmåling af landbrugsprodukter • Mest til måling af mælkeprodukter: - fedtindhold, proteintal, bakterier, urea-stof, etc. • Kunderne er laboratorier, slagterier, mejerier, mv. • Ca. 700 ansatte - worldwide • Meget stor andel af verdensmarkedet -> konkurrerer i høj grad med sig selv • Satser på: - højt kompetence-niveau - en matrix-organisation - "Concurrent engineering"

5. S4000 - projektet • Analytisk test af rå-mælk (fx. fedt, protein, urea, etc.) • Stærkt forøgede krav til hastighed og funktionalitet. • 200.000 liner software (C-kode). Konfiguration, kontrol, og brug via et Windows user interface. (Intel-baseret 486 PC build-in) • 8000 komponenter: Kabinet, pipette unit, transport- bånd, PC, anden hardware, flow-system, og målingsenhed • Op til 50 folk på en gang. • Version 1 tog ca. 2 1/2 år at udvikle • Fire design discipliner: • Mekanisk design • Elektronisk design • Software design • Kemisk design • Andre involverede: • Teknisk tegning • Proces planlægning • Model shop • Produktion • Marketing • Kvalitetssikring • Kvalitetskontrol • Samling (assembly) • Teknisk dokumentation • Management

6. En S4000 !!

7. Karakteristika ved udviklingen (af software) • Op til 12 software designere involveret - nogen udskiftning undervejs • Mange aktører (mere end 25) involveret i aftestningen - flere forskellige perspektiver • Alle software designerne producerede programmer som skulle spille sammen med software som andre lavede. • Kemikerne var ikke helt sikre på de formler mv. der skulle bruges for at beregne de forskellige kvalitetsværdier som S4000’eren skulle kunne beregne! • Ca. 200.000 liner kode (25 applikationer) • Mange forskellige interagerende komponenter i hardwaren. Forskellige hardware designere havde ansvaret for disse • Mange designaktiviteter blev udført parallelt • Kravene var ikke præcist specificerede -->> • Hardware design og funktionalitetskrav skiftede hen gennem processen • Mangel på standarder og fælles metoder • Ny platform (Windows)

8. Karakteristika ved udviklingen (2) Helt overordnet blev gjort følgende: - Kravene til S4000 blev formuleret af projektlederen, et par udviklere samt marketingsfolk - Krav til sw blev formuleret af de to første sw-folk på projektet - i et 180 siders dokument - Overordnet design blev lavet af tre sw-folk - i et 120 siders dokument - De forskellige sw-dele blev fordelt imellem sw-folkene - Ind imellem checkede de om komponenterne passede sammen - det gjorde de ikke! - De sidste 1,5 år blev der arbejdet i 4-6 ugers cykler. - De sidste 1,5 år var der ingen IT-projektleder. - Der blev etableret en del roller undervejs: platform master, spec-team, tester, etc. • Et komplet overblik over modul-modul og sw-hw afhængigheder eksisterer ikke - software er abstrakte strukturer -> umulige at overskue "at a glance" • Sw-designerne var ikke fortrolige med behovet for at få samordnet og koordineret aktiviteterne - støtte til dette (klassifikationer, formularer, roller, etc.) skulle udvikles og implementeres -->> Det var uhyre komplekst - krævede meget kommunikation, ledelse, koordinering, kontrol, integration !

9. Interaktion med omverdenen

10. Opgave 1: Brug 10-15 minutter to-og-to på at overveje • Hvad har det her med formidling ogkommunikation at gøre? • Hvad mener I er de vigtigste egenskaber og kompetencer hos en professionel software-designer? • Hvad kan vi gøre for at styre og håndtere så komplekseprocesser?

11. Midler anvendt for håndtere processerne • Alle designere var placeret i samme rum. Software designerne var placeret ved siden af elektronik designerne • Overordnede og arbejdsplaner (delvist integreret med de samlede projektplaner) • Distribuerede ansvarsområder som afspejlede software arkitekturen • Møder - ad-hoc, uformelle, integrationsmøder, diagnose-møder, planlægningsmøder ... • Platforms perioder (Cykliske arbejdsperioder, eller -bølger) - 4 ugers arbejde - 1 uges integration, - linking rutiner, standard procedurerer, specifikke roller • Fejlrapporter + standard procedurer for deres anvendelse • Projekt planlægnings-spread-sheet • Etablering af forskellige roller som havde specifikke funktioner ift. at samordne aktiviteterne

12. Eksempel på en mekanisme til at håndtere processerne: Planlægningsark

13. Eksempel på en mekanisme til at håndtere processerne: Fejlrapporter Procedure: - rapportering - klassifikation - send til spec-team - diagnose - klassifikation - estimering af tid til at rette - indarbejdelse i planer - integration i fejllisterne / statistik - kopi -> centralt arkiv - original -> ansvarlig designer - rettelse af problem - original -> centralt arkiv - kopi -> platform master Forsimplet - forhandles og forandres løbende

14. Observationer (af processen) • En meget stor del af arbejdet blev brugt på at organisere, samordne og integrere • Kommunikation og forhandling var central • Software var meget vanskeligt at diskutere og koordinere, bl.a. fordi det er abstrakt og ikke "umiddelbart synligt". • En systemudviklingsprocess bevæger sig fra ”løse formuleringer” til en stærk grad af formalisering

15. Opsamling (1) Fra ”løse” krav til ”kørende kode” - formalisering Rationalitet: Parnas & Clements: Software udvikling kan aldrig blive en rationel proces, men det er en god idé at lade som om den er det! Naur: Intuition er vigtig. Integration: En meget stor del af software udvikling drejer sig om at få delene til at hænge sammen.

16. Opsamling (2) Kompleksitet og usikkerhed Mathiassen & Stage: En systematisk analytisk tilgang (for at reducere kompleksitet) introducerer nye kilder til usikkerhed. En eksperimentet tilgang (for at reducere usikkerhed) introducerer nye kilder til kompleksitet. Ikke noget teknologisk fix (Brooks) Kompleksitet og usikkerhed => flere aktører => øgede krav til samarbejde og samordning

17. Opsamling (3) Udviklingsprocessens forløb Forskellige typer af modeller for processen: Vandfald, Iteration, Inkrementel udvikling, Spiral modellen Forskellige metoder til systemudvikling. Drejer sig i høj grad om - styring, - kontrol, - overblik, - ensartet sprog.

18. Opsamling (4) Styring, ledelse og kommunikation Køber, bruger Ledelse ”SU-ledelse” Planer Estimater Integration Samordning Kommunikation Forhandling etc. etc. Medarbejdere

19. Opsamling (5) Samarbejde og koordination - Arbejde vs. samordning (Schmidt & Carstensen) - Kommunikation - Gensidig opmærksomhed - Koordinationsmekanismer (Carstensen)

20. Kruchten symptomer:

21. Kruchten - årsager:

22. Opgave 2: Kreuchten peger på følgende “best practises”: • Opgave: Diskutér i grupper: • Hvad betyder disse 6 overskrifter? • Hvordan blev de håndteret på Foss? • Kan I relatere dem til noget i kender fra egen hverdag? • Forbered helt kort at kunne fortælle de andre grupper jeressvar på hvert af de 6 punkter (2 minutter)