Kontrollere Krav

Share

|

Kontrollere kravene kan være det viktigste med å oppnå suksess på et prosjekt og sikre full brukbarheten av de utviklede systemet. Kontroll betyr ikke at det er aldri noen endringer i den opprinnelige baselined krav. Det betyr at alle interessenter i prosjektet er informert om og involvert i et krav kontroll prosess som eliminerer den største trusselen mot ethvert system utviklingsprosjektet - krav snikende. Krav snikende kan og sannsynligvis bør sees som en ond sabotør som, som en kameleon, tar på mange forskjellige farger. Dette skurk slår ut med kun ett formål: få noen, for alle på prosjektet, gjøre en endring i baselined kravene uten å vurdere virkningen og logisk disponering av endringen og informere alle parter om behovet for endring. For å eliminere krav snikende:

- Sørg for at det opprinnelige krav.

- Ha en endring kontroll metode i stedet for å håndtere alle typer modifisering baselined krav.

- Sørg for at alle mennesker er involvert i prosjektet, både på publisering side og på utviklingen siden, forstår prosessen og metoder brukt til baseline krav og påvirke bytte til baselined krav. Kravene listen grunnlinjen er etablert etter kunden anmeldelsen møte og bør gis en unik identifikator på det tidspunktet. Det må bli distribuert til alle deltakerne som eneste krav listen skal brukes som design arbeidet starter. Identifikatoren skal ha bestemmelser om indikerer versjonen eller utgave. Hvis en godkjent endringen er gjort i henhold til kravene listen, må identifikatoren være oppdaterte og reviderte krav listen distribuert til alle deltakerne.

Kontrollere Change of Requirements

For eksempel, si at som utformingen av det grafiske brukergrensesnittet (GUI) sparkes i gang, innser designeren at det ikke er krav om GUI å skaffe transport til søket delsystemet, en funksjon designeren mener vil være avgjørende for brukeren. Bruke kravene styre prosessen, ikke designeren ikke legge funksjonen (som kunne krype kravene). I stedet forbereder designer en hendelse / problem rapport som bemerker at det ikke er et krav for GUI til søket transport og varsler vokter kravene listen, som kan være kvalitetssikring leder, engineering manager, prosjektleder eller noen i konfigurasjonsstyring. Informasjonen gitt av designeren er vurdert for prosjektet innvirkning og avhendes på en av følgende måter:

1. Endringen er godkjent som en nødvendig komponent i dagens system utviklingsinnsats. I dette tilfellet vil tidsplanen og budsjettet bli vurdert for påvirkning. Hvis tidsplanen må opprettholdes, vil en ledelse vedtak må gjøres om å legge en ressurs til å gjøre programmeringen, økende timer for én eller flere eksisterende programmerere, eller kontrahering at stykke arbeid. Hvis budsjettet er allerede på nakne bein og planen må være oppfylt, deretter økte timer mest sannsynlig vil bli inkludert i nonpaid frita arbeidstakeren overtid kategorien, men ledelsen må innse at de har økt pro sjektet risiko.

2. Endringen er godkjent som en endring av dagens system skal gjennomføres i første programvaren utgivelse etter at første levering av systemet. En work-around kanskje eller kanskje ikke trenger å være utviklet for første implementeringen. Poenget er å sørge for at det er enighet med kunden om hvem som skal utvikle work-around den burde være nødvendig. Den andre kritiske punktet for å bli gjort her er at endringen kontroll-poster og prosessen for å bruke dem må iverksettes slik at elementer som dette ikke faller gjennom sprekkene som utvikling for neste utgivelse sparkes i gang.

3. Endringen er godkjent som en potensiell fremtidig forbedring av dagens system uten en konkret tidsplan for gjennomføringen. I likhet med endringen godkjent som en endring, må endringen kontrollen postene være presis for å sikre at beslutningen er spesifikk for denne endringen er ikke tapt. Siden denne endringen ikke vil bli en del av neste versjon, vil den gå tilbake til ønskeliste status og bli gjennomført gjennom hele kravene prosessen. Grunnen til dette er å gjøre sikker på at utviklingen av dette ekstrautstyret er planlagt for arbeid og levering innen konteksten av alle andre eksisterende arbeid.

4. Endringen er avvist. Dette stenger ute hendelsen rapporten. Ingen jobb er planlagt nå eller for fremtiden. Det kan være mange årsaker til denne typen svar. Uansett årsak, bør avvisningen handlingen og årsaken til avslaget registreres i endring kontroll prosessen. En registrering av alle lukkede endringer opprettholdes for å sikre nøyaktig prosjektet historie og å gi begrunnelsen på hvorfor endringen ble avvist.

Når alle programvare er gitt til kunden, skal utgivelsen følge en definert release management prosess som inkluderer spesifikke identifikasjon av alle komponentene som er inkludert i programvaren løslate samt komponenter som antas å være til stede (dvs. system software). Denne identifikasjonen også bør omfatte de spesifikke hendelsen / problemet rapporter som ble korrigert av utslipp og eventuelle omgåelsesprosedyre som ble utviklet for de kjente problemene som finnes i programvaren.

---