Styra Krav

Share

|

Kontroll av krav kan vara den viktigaste aspekten av framgång i ett projekt och se till full användbarhet av de utvecklade systemet. Kontroll betyder inte att det finns aldrig några ändringar i den ursprungliga baselined krav. Det innebär att alla intressenter i projektet är informerade om och delaktiga i ett krav på kontroll process som eliminerar den enskilt största hotet mot alla system utvecklingsprojekt - krav smygande. Krav smygande kan och förmodligen bör ses som en skurkaktig sabotör som, som en kameleont, tar sig många olika färger. Denna skurk slår ut med endast ett syfte: få någon, om projektet, till alla som gör en förändring i baselined krav utan att bedöma effekterna och logisk disposition av förändringen och informera alla parter om behovet av förändring. För att eliminera krav krypande:

- Se till att det finns grundläggande krav.

- Har en kontrollmetod förändring i stället för att hantera alla typer av ändringar baselined krav.

- Se till att alla människor inblandade i projektet, både på publicering sidan och på utvecklingssidan, förstå processen och metoder för att baskraven och påverka förändring av baselined kraven. Kraven lista baslinjen inrättades efter kundens recension möte och bör ges en unik identifierare på den tiden. Det skall delas ut till alla deltagare som enda krav förteckning som skall användas som arbetet påbörjas design. Identifieringsdonet bör ha bestämmelser för att ange version eller upplaga eller release. Om en godkänd ändring har gjorts av kraven listan identifierare måste uppdateras och de ändrade kraven som delas ut till samtliga deltagare.

Kontroll av ändrade krav

Till exempel säga att eftersom utformningen av grafiska användargränssnitt (GUI) får igång, designer inser att det inte finns något krav på det grafiska gränssnittet för att tillhandahålla transport till frågan delsystem, en funktion formgivaren tror kommer att vara nödvändigt för användaren. Använda krav kontroll processen, inte för att lägga till konstruktören funktion (som skulle krypa kraven). Istället designer förbereder en incident / problem betänkande som konstaterar det faktum att det inte är ett krav för att GUI för att söka transport och meddelar vårdare av de krav listan, som kan vara kvalitetssäkring chefen, teknisk chef, projektledare , eller någon i konfigurationsstyrning. De uppgifter som formgivaren bedöms för projektets inverkan och bortskaffas på ett av följande sätt:

1. Förändringen är godkänd som en nödvändig del av det nuvarande systemet utvecklingsarbetet. I detta fall, och den budget som kommer att bedömas vid kollision. Om schemat måste bevaras, ledning beslut kommer ett måste göras för att lägga till en resurs för att göra programmeringen, vilket ökar timmar för en eller flera befintliga programmerare, eller underleverantörer som arbete. Om budgeten är redan nakna ben och tidsplanen måste vara uppfyllda, då de ökade timmarna mest sannolikt kommer att ingå i den nonpaid undanta anställda övertid kategori, men ledningen måste inse att de ökar pro tet risk.

2. Förändringen är godkänd som en ändring av det nuvarande systemet som skall genomföras i den första versionen av programvaran efter den första leveransen av systemet. En work-around eller inte behöva utvecklas för inledningen. Poängen är att se till att det finns en överenskommelse med kunden om vem som kommer att utveckla det arbete runt det skulle bli nödvändigt. Andra kritiska punkt som skall göras här är att den kontroll av förändringar register och processen hur de skall genomföras så att sådana artiklar som för detta inte faller genom sprickorna som utvecklas för nästa utgåva arbetar på.

3. Förändringen är godkänd som en potentiell framtida förbättring av det nuvarande systemet utan särskild tidsplan för genomförande. Liknande till ändringen godkänts som en förändring, förändring kontroll register måste vara exakta för att se till att beslutet är specifika för denna förändring är inte förlorat. Eftersom denna förändring inte kommer att bli en del av nästa utgåva kommer den att gå tillbaka till önskelista status och att genomgå hela processkrav. Anledningen till detta är att försäkra sig om att utvecklingen av denna förbättring är planerad till arbete och resultat inom ramen för alla andra befintliga arbete.

4. Förändringen avvisas. Detta stänger ute den incidentrapport. Inget arbete är planerat nu eller i framtiden. Det kan finnas många orsaker till denna typ av svar. Oavsett anledning, avslag åtgärder och skälet till avslaget skall registreras inom förändringen kontrollprocessen. Ett register över alla stängda ändringar är underhållas för att säkerställa korrekt projektet historia och för att ge bakgrunden till varför förändringen avslogs.

Närhelst någon mjukvaran släpps till kunden, utgivnings bör följa ett definierat förvaltningsprocessen release som inkluderar identifiering av alla komponenter som ingår i den versionen av programvaran samt komponenter som antas gälla (dvs system programvara). Denna identifiering även bör omfatta särskild händelse / rapporter problem som korrigeras av utsläpp och något arbete-arounds som tagits fram för de kända problem som finns i programvaran.

---