Checklista med kravkategorier
!Checklista med kravkategorier
Det finns en mängd sätt att ställa krav på underhållbarhet. Här presenterar vi 10 kategorier som man kan ställa krav inom. Alla sätt passar inte för alla system och för de flesta system behöver långt ifrån alla kravkategorier användas. Vi rekommenderar att använda listan som en checklista. Gå igenom varje kategori och tänk efter om det finns något som är relevant för systemet att ställa krav på inom kategorin. Välj "era" kategorier utifrån typ av förvaltningsorganisation, etc.
1. __Dokumentation.__ Dokumentation över hur systemet är designat och implementerat kan vara mycket värdefull när man ska utföra underhåll på systemet. Man kan ställa krav på dokumentationen, till exempel genom att ange vad som ska dokumenteras, hur det ska beskrivas (notationer, språk) och tekniska format för den.
2. __Arkitektur och design.__ Systemets arkitektur och dess design påverkar underhållbarheten och därför kan det vara relevant att ställa krav på dessa. Vissa arkitekturer och designmönster hävdas ge högre underhållbarhet, som t.ex. abstract factory pattern. Att konsekvent använda samma mönster i olika delar av systemet kan öka underhållbarheten.
3. __Källkod.__ Krav på att systemets källkod ska följa kodningsstandarder och krav på kommentarer i källkoden kan ha en positiv påverkan på underhållbarheten. En viktig faktor som påverkar underhållbarheten är källkodens komplexitet. Komplexitetsmetriker kan användas för att specificera en acceptabel nivå.
4. __Tredjepartsprodukter.__ Många produkter från tredjepartsleverantörer behövs för att skapa IT-system, till exempel programmeringsspråk, databaser och operativsystem. Ibland kan det vara relevant att ställa krav på sådana produkter för att förbättra underhållbarheten. Om underhållsorganisationen består av erfarna Java-programmerare är det relevant att kräva att systemet skrivs i språket Java.
5. __Testfall.__ Att ha en uppsättning regressionstestfall kan vara ett sätt att minska risken att introducera fel när systemet förändras. Därför kan det vara relevant, av underhållbarhetsskäl, att kräva att sådana testfall levereras med systemet.
6. __Körande system.__ Det kan vara relevant att ställa krav på hur det körande systemet får påverkas av förändringar. Sådana krav kan specificera vilken grad av tillgänglighet man kräver av systemet när förändringar görs.
7. __Underhållsorganisation.__ Ett sätt att hantera förvaltningen är att låta någon annan göra det, det vill säga att kräva att systemet levereras med underhållstjänster. Krav kan ställas på hur sådana tjänster ska vara utformade.
8. __Process.__ Man kan ställa krav på processen som ska användas för att utveckla systemet. Antingen genom att kräva att någon utvecklingsprocess som hävdas ge lägre underhållskostnader används (exempelvis Extreme Programming), eller genom att ställa krav på enskilda aktiviteter, som till exempel inspektioner med fokus på underhållbarhet.
9. __Systemövergripande.__ Det går att ställa systemövergripande krav på hur underhållbart systemet ska vara. Exempel på sådana krav är hur mycket arbete som får krävas för olika typer av förändringar.
10. __Ägande.__ För att över huvud taget kunna utföra förändringar i systemet är det viktigt att ha legala möjligheter att göra det. Krav kan ställas på att källkod och dokumentation ska ägas av kunden eller att licensrättigheter åtminstone tillåter förändringar.




Kommentarer
Absolut intressant ämne! Jo handboken är mitt fram, innehållsförteckning på förstasidan och bläddra framåt och bakåt är inte heller någora problem. Så jag håller inte med om att det skulle vara speciellt rörigt.
Användbarheten skulle dock öka om vi kunde få innehållsförteckningen i ett block till vänster.
EDIT: hittade just förteckningen i ett block till höger. Mittåt. Medlemskonventblocket borde inte ersätta sektionens navigering, irriterande och förvirrande.