Introduktion til Systemudvikling Peter Carstensen Welcome

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?

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

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"

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

En S4000 !!

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)

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 !

Interaktion med omverdenen

Opgave 1: Brug 10-15 minutter to-og-to på at overveje Hvad har det her med formidling og kommunikation 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å komplekse processer?

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

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

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

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

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.

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) => flere aktører => øgede krav til samarbejde og samordning

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.

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

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

Kruchten symptomer:

Kruchten - årsager:

Kreuchten peger på følgende “best practises”: 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 jeres svar på hvert af de 6 punkter (2 minutter)