 |
|
|
| Hur hantera ändrade krav? |
| Av: Anders | 30/11/2004 klockan 10:51 |
Hur jobbar ni med kravhantering och kravuppföljning?
Innan man startar ett projekt måste ju x antal personer vara överens om vilka krav man ska uppfylla och vilka krav som prioriteras framför andra osv. När man väl har allas signatur på detta går man vidare i projektet.
Problemet är ju att kraven ständigt förändras när man itererar igenom design, programmering, testning osv.
Ska man skriva en kravspec innan projektet börjar och sedan en ny kravspec när projektet är i hamn och sedan gör kravuppfölning mot den nya kravspecen (Dvs, mäta om man lyckades uppnå kraven)?
Detsamma gäller även annan dokumentation som designspecifikationer osv, även dessa ska i vår organisation godkännas innan dom kan börja tillämpas... problemet är ju att även detta ändras under resans gång och går då inte att användas i projektets slut för att se om man utförde enligt den godkända planen.
Vad jag söker efter är en approach där man kan tillgodo se organisationens krav på godkänande av vissa dokument och möjligheten att följa upp om man har gjort ett bra jobb samtidigt som man tillåter flexibilitet när man hela tiden plockar på sig ny kunskap som förändrar dokumenten i fråga.
Puh, långt inlägg, några idéer? |
Joakim svarade 30/11/2004 klockan 16:21 |
Hehe, först och främst nej, skriv inte spec:n när produkten är färdig, det blir inte bra :-)
Det här med kravhantering är något exceptionellt komplicerat. Nästan all problem kan dock härledas till hur man angriper problemet, vilket förstås också är din fråga. Nästan alltid finns det dock ett bakomliggande kompetensgap inom organisationen. T.ex. så vet faktisk få vad ett krav är, de flesta anser att lösningar är krav. Anledningen tilll detta att en lösning för kunden/användaren är ett krav på utvecklaren, d.v.s. att ett krav kan vara en lösning för vissa och vice versa. Detta är dock obra och kan i sin kärna endast åtgärdas genom en kompetensökning hos de som samlar in och beskriver kraven, samt för dessa vidare till produktspecifikationer.
Att processen måste vara iterativ är självklart. Många utvecklingsprocesser strider dock mot detta tänk. Även kompletterande s.k. gate-modeller kan utgöra problem om dessa gates placeras på fel ställer och tillämpas fel i processen (verkar som om Ni har något liknande på plast (alt. en vattenfallsmodell).
Den viktigaste riktlinjen i det hela är att kraven alltid ska vara helt designoberoende. D.v.s. att man ska när och hur som helst kunna ändra i produkten/lösningen utan att kravbilden påverkas.
När det kommer till designspecifikationer så kan de förstås vara helt färdiga innan någon implementation påbörjas. Genom att använda sig av protoyper, en iterativ designprocess, en interdiciplinär utvecklingsgrupp, samt användarmedverkar så kan man fastställa hela designen innan den implementeras. Detta är dock mycket ovanligt och sällan att rekommendera under kommersiell produktutveckling. Det är ofta bättre att specifisera ramverket först, utifrån kraven givetvis, förfina det med så mycket detaljer som möjligt, iterativt etc. som nämnt ovan, för att sedan påbörja implementeringen. Under implementeringen så kommer det förstås att behövas kompletteras med en hel del detaljer men då utifrån den redan påbörjade designspecifikationen och kravbilden.
Att sedan få acceptans av användarna för produkten ska inte förvillas med krav, om inte denna acceptans har kunnat omvandlas till krav gnom t.ex. konkurrentstudier eller liknande (t.ex. icke-funktionella krav). Användartesta utmed vägens gång men gör detta utifrån designen, som alltså ska vara kravoberoende. Visst upptäcker man nya krav först när en prototyp finns på plats, men om detta kan göras gentemot tidiga prototyper (innan implementation alltså) så behöver inga omfattande förändringar av dokumentationen göras (lägg helt enkelt en gate efter första design-svängen, inte direkt efter kravspec:ningen, eller låt helt enkelt en passage av an gate trots vetskapen av att kravspec:en måste uppdateras).
Om inte utvecklingsprocessen förändras så kommer det aldrig att fungera smidigt. Detta kräver nästan alltid en komptensförändring som i sin tur kräver en attitydförändring hos någon högt uppsatt. Denna attitydförändring lär sannolikhetsmässigt inte inträffa annat än av slump (läs: inte under din livstid). Synd men sant - välkommen till skärselden.
Ett långt inlägg igen. |
Joakim svarade 30/11/2004 klockan 16:22 |
| Blev många felstavningar i föregående inlägg. :-[ Jag ber om ursäkt. |
Anders svarade 01/12/2004 klockan 09:37 |
Tyckte ditt svar lät hoppfullt tills jag läste; "Denna attitydförändring lär sannolikhetsmässigt inte inträffa annat än av slump (läs: inte under din livstid). Synd men sant - välkommen till skärselden." ;-)
Du har helt rätt, vi saknar nog definitionen av vad ett krav egentligen är. Där måste vi nog bli bättre, förmodligen kan en sådan enkel sak lösa mycket.
Det låter smart att faktiskt inte "signa" kravspecen förrän man har tagit en eller ett par turer i designfasen, förmodligen får man väl ändå införa någonslag preliminärt godkännande så att man vet att man inte är helt ute och cyklar innan man går in i designfasen.
Man kan ju faktiskt se det så att vattenfallsmodellen i sig gör att man måste lägga oerhört mycket krut på analys och design så att man vet att man är på rätt spår innan man går vidare till nästa steg.
Tack för ett bra inlägg! |
Karl Bengtsson svarade 01/12/2004 klockan 11:02 |
Det finns väl olika sorters krav. Användarnas krav, beställarnas krav, och markandsmässiga krav finns där redan från början. Först efter en ordentlig analys av användarnas perspektiv och en omvandling av dessa till en grundläggande interkationsstruktur, så kan man skapa de systemkrav och applikationskrav som ligger till grund för implementationen.
På NITA:s seminarium, som diskuterats i ett annat forum, presenterade Erik Markensten från Antrop intressant material som har att göra med detta. Kolla på: http://www.nita.uu.se/presentation/index.html |
Joakim svarade 02/12/2004 klockan 06:19 |
Jo, det finns alltid ett antal intressenter som alla tillför krav.
Karl Bengtsson ovan påtalar just också att det blir en hierarki av vad man inom utvecklarorganisationen benämner som krav. Emellan dessa nivåer av krav förekommer alltid en designaktivitet (ofta dock tyvärr impilcit). Denna designaktivitet (Karl nämner t.ex. skapandet av en "grundläggande interaktionsstruktur") utgår basen för nästa nivås krav (som i sin tur ofta beskrivs av en annan grupp människor, med ett annat intresse, än de som beskrev den föregånde nivån av krav). Att samtliga nivåer av beskrivningar hänvisas till som krav är ett terminologiskt problem som i sin tur ofta medför om inte annat kommunikationssvårigheter och tankemässiga problem i projektet/organisationen. Det kan mycket väl finnas direkta krav på design, t.ex. att en viss text måste finnas i mjukvarans about box (ett internt krav dock) men att hänvisa till designbeslut som krav är aldrig bra då det blir svårt att över tid urskilja vad som faktiskt är ett krav och vad som är design. En ofta förekommande rekommendation inom vår yrkesgrupp är att låta designdokumentet vara styrande gentemot implmentationen och att validera designen gentemot användaren och verifiera den därefter gentemot vad som implementerats. Detta utan att prata om krav på en annan nivå än som kan härledas från de olika intressenterna direkt (varpå också allt som benämns som krav också är krav i ordets rätta bemärkelse).
För att ändra trådens karaktär något så blev jag mycket skeptisk till vad som framfördes på Nitas seminarie vad gäller beställarkompetens. Ska inte säga mer om detta här - kanske kan bli en ny tråd. |
Emeli svarade 02/12/2004 klockan 11:05 |
| Nu blev jag nyfiken. Vad blev du (och ni andra!) skeptiska till ang. beställarkompetensen? |
Joakim svarade 03/12/2004 klockan 07:25 |
| Så som det framställdes på seminariet så handlade beställarkompetens i praktiken om skapandet av en "interaktionsarkitekt". Som för de flesta beställande organisationer givetvis måste vara en konsult då systembeställningar sker så pass sällan. M.a.o. så de enda kompetensen en beställare behöver är vetskapen om att han behöver konsulthjälp, d.v.s. i princip samma utgångspunkt som idag (bara att benämningen på konsulten är en annan, samt att ansvaret för produktens användbarhet övergår till den beställande organisationen istället för att vara placerad hos den utvecklande organisationen (den utvecklande organisationen borde för den delen enligt mig fortfarande ha det primära ansvaret)). Denna framställning av vad beställarkompetens är kan självklart ha varit felaktig, eller att min tolkning av vad som framfördes också kan ha varit felaktig. |
|
|
Forumet är inte längre aktivt.
|
|
|
|
|
