Introduktion til Systemudvikling

Præsentationer af emnet: "Introduktion til Systemudvikling"— Præsentationens transcript:

1 Introduktion til Systemudvikling
Peter Carstensen Welcome

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. 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 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 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?

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) => 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 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

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

20 Kruchten symptomer:

21 Kruchten - årsager:

22 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)