LakeStyle < Main

Main Web>LakeStyle (2008-08-12, JakobBjoern) (raw view)
---+!! Introduktion til Lakestyle

%TOC%
 
---++ Indledning
Lakestyle er en ramme for Virksomhedens systemudvikling. 

Lakestyle indeholder en række overordnede Policies og Procedurer baseret på CMMI samt beskrivelser af og skabeloner til de forskellige Arbejdsprodukter (AP'er), man kan komme ud for at skulle fremstille i løbet af et projekt. Der er også vejledninger til både AP'er og arbejdsgange samt eksempler på, hvordan andre har lavet den slags AP'er.

---++ Indhold:
Lakestyle består af:
   * Arbejdsproduktdefinitioner beskriver resultater af aktiviteter.
   * Vejledninger og Checklister foreslår måder at gøre det på.
   * Policies fortæller, hvad vi vil.
   * Procedurer fortæller, hvordan vi gør det.
   * Standarder fortæller om begreber og navne. 

Derudover er Lakestyle et værktøj til at opsamle og udnytte erfaringer.

I det følgende vil de enkelte elementer af Lakestyle blive introduceret.


---++ Arbejdsprodukter (AP). 
Måden, man udnytter AP'erne på, er, at man ved passende lejligheder gennemgår oversigten over AP'er og beslutter sig for hvilke af dem, man har tænkt sig at producere i dette projekt. Resultatet kaldes en AP-liste. Det er langtfra alle AP'er, der forekommer i alle projekter, men der er nogle af dem, der er obligatoriske. 

Nogle af de situationer, hvor man typisk vil se på sin AP-liste er:
   * Skrivning af tilbud
   * Opstart
   * Start af design
   * Start på ny release
   * Før aflevering
   * Før første build

Man skal *altid* producere en AP-liste ved opstart / kick-off for projektet. Det kaldes en AP-workshop. AP-listen tjener også som plan for Kvalitetsstyringen, idet man for hvert AP tager stilling til om og i givet fald hvordan, det pågældende AP skal kvalitetssikres (Review, test, godkendelse eller hvad det nu kan være).

Ud over at udelade nogle AP'er kan man også vælge at slå nogle af dem sammen. Det vil som regel være et antal dokumenter, som man samler i et dokument, hvor de enkelte AP'er så bliver til afsnit i dokumentet.

Nogle af AP'erne er obligatoriske. De skal altid laves, medmindre man har så god en grund til at lade være, at man kan få den ansvarlige for det pågældende AP til at acceptere at udelade den.

Der findes vejledning til afholdelse af en AP-workshop.

Når man ved hvilke AP'er, man har tænkt sig at udvikle, har man også et godt overblik over, hvilke aktiviteter, der skal med i projektet. Listen over aktiviteter er det, der ofte kaldes en Work Breakdown Structure (WBS), og når aktiviteterne forsynes med ressourcer og tidspunkter, bliver de til en projektplan (Detaljeret tidsplan). 

Det er ikke sådan, at man udvikler et AP en gang for alle. Ofte vil AP'et udvikle sig gradvis i løbet af projektet. AP'et fungerer så som et repository for den information, man indsamler undervejs, og som et sted at dokumentere sine overvejelser.

Til beskrivelsen af et AP kan der knytte sig tre slags eksempler:
   * eksempler, som er AP'er, der er udviklede med afsæt i ressourcerne i Lakestyle
   * eksempler til inspiration, som er AP'er, der ikke har trukket på Lakestyle, men som kan bruges til at få gode ideer fra
   * Best Practice, som er et fremragende eksempel på, hvordan det kan gøres. Best Practice vil altid være forsynet med kommentarer om, hvorfor netop det er blevet valgt som Best Practice.

---++ Skabeloner
Til de fleste AP'er - i hvert fald til dem, der er dokumenter - er der tilknyttet en skabelon. Den skal bruges!

Den indeholder det fulde sæt af afsnit, man kan få brug for, men det er ikke alle afsnit, der skal med hver gang. Det tilpasser man til sit eget behov. Under de forskellige afsnit er der vejledende tekst, der forklarer, hvad tanken er med det pågældende afsnit. Den er i kursiv med blåt. Det kan f. eks. være: %BLUE% "Formålet med vedligeholdelsesdokumentationen er at ......" %ENDCOLOR% 
Den vejledende tekst skal slettes, når man er færdig med at bruge den.

Der er også afsat pladsholdere med rød skrift som f. eks. %RED% < Projektnavn > %ENDCOLOR%. Det skal så udskiftes med det, der er relevant for projektet, i dette tilfælde projektets navn.

Der er også afsat plads til dokumentinformationer (ændringshistorik, referencer, ordforklaringer, information om kvalitetssikring (Review og audit etc.).  Det udfyldes i det omfang, man har brug for det.

Skabelonerne er udformede som Word-skabeloner (.dot), og når man er begyndt at skrive på dem, skal de saves som dokumenter (.doc) og navngives i overensstemmelse med Standard for Dokumentnavne.

Der hører også en folderstruktur til Lakestyle. Den kopierer man over på sig egen server og anvender kopien til lagring af AP'erne efterhånden, som man begynder at udvikle dem.

---++ Vejledninger  
Der er vejledninger til de fleste AP'er. De fortæller om måder at udvikle det pågældende AP på og vil typisk have afsnit om :
   * Arbejdsmetode
   * Validering og Verificering
   * Tips og gode råd

Der findes også vejledninger, der ikke knytter sig direkte til et AP, men beskriver et område mere generelt. Det kan f. eks. være en tutorial i risikostyring.

Indholdet af vejledningen er ment som en hjælp, og der er ingen tvang til at gøre arbejdet på netop den måde.

---++ Policies
Policies angiver de overordnede retningslinjer for, hvordan udviklingen skal foregå;. De indeholder ikke detaljerede beskrivelser af fremgangsmåder, men angiver hensigten med aktiviteterne. Policies kan betragtes som "Lovens ånd".

---++ Procedurer 
Procedurer angiver den måde, ting skal gøres på. De beskriver et antal opgaver, der skal udføres. De fleste af opgaverne handler om udvikling af obligatoriske AP'er og skal derfor udføres, mens de øvrige opgaver kan udelades eller modificeres i den udstrækning, det ikke strider mod en Policy. Procedurer kan ses som "Lovens Bogstav".

---++ Checklister 
Checklisterne er til for at hjælpe de involverede i projektet til at huske alt det, der skal huskes. De er til brug internt i projektet og behøver ikke at blive anvendt som leverancer til kunden eller lignende.

---++ Standarder 
Der er to type standarder: Lakesides interne standarder (Navngivning af dokumenter etc.) og eksterne, internationale standarder som f. eks. CMMI. 
De interne standarder skal naturligvis overholdes, mens de internationale standarder primært er til orientering.




-- Main.JakobBjoern - 12 Aug 2008
Topic revision: r1 - 2008-08-12 - JakobBjoern
Main
Webs
Main
Sandbox
TWiki
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback