Hvordan kan man leve uden sporing?

Er det et nørdet spørgsmål? Ja, det ser måske sådan ud ved første øjekast; men det er i virkeligheden et meget alvorligt ledelsesmæssigt spørgsmål, som enhver projektleder og testleder bør stille sig selv og sine medarbejdere.

Siden jeg i begyndelsen af '90erne stiftede bekendskab med sporing på et projekt for Den europæiske Rumfartsorganisation (ESA), hvor sporing fra krav til design og testcases var et must, har jeg ikke kunnet komme i nærheden af et IT projekt uden at spørge efter sporingen. Desværre er svaret i mere end 90% af tilfældene noget i retning af: "Hvad er det?".

Svaret er så enkelt: "Registrering af relationer mellem alle de 'dimser', der bliver fremstillet." Hvad er det for et design element, der skal sørge for, at et krav bliver opfyldt? Hvad er det for en eller flere metoder eller services, der rent faktisk implementerer kravet? Og hvilke testcases bruges til at eftervise opfyldelsen?

Hvis man ikke har sporing, famler man rundt i blinde. Er kravet overhovedet kommet med i leverancen? Er det blevet testet? Hvor mange af kravene er testet, og hvilke er og hvilke er ikke?

Sporing er kedeligt. Ja måske, men det er der så meget, der er. F.eks. synes jeg madlavning er et rædselsfuldt spild af tid; men det er jo nødvendigt for familiens overlevelse (og heldigvis er det som regel min mand, der gør det). Sporing er også nødvendigt for at undgå store ekstraudgifter til implementering, af noget man 'har glemt', eller fejlrettelse af noget, man ikke fik testet i tide.

Jeg har én gang oplevet, at en kursist på et testkursus, gav udtryk for, at hun helt delte min opfattelse. Så jeg kunne godt tænke mig at spørge: er der andre derude, der heller ikke kan leve uden sporing?

Anne Mette Hasss billede

Kommentarer (11)

Lars Rossen

Jeg formoder at du ønsker sporing af krav og igennem dette har sporing af test, da jeg formoder at du ønsker test cases er baseret på krav (requirement based testing).
Hermed bliver sporing et krav til krav specifikationen (et meta krav :-))

Med moderne sammensatte applikationer (composite apps) kraever det at udviklings grupper kan holde styr på afhængighed grafen på tværs af projekter, samt at krav spores på tværs af en aplikations komponent til de underliggend systemer.
Jeg arbejder for tiden på at lave værktøj til at styre dette i store IT organisationer, og min erfaring er at du rammer plet med dit indlæg. Meget få udviklings organisationer har styr på dette.

Lars Rossen

Hej Anne Mette,
Det er en kæde af værktøj jeg arbejder på. Udgangspuntet er en reference arkitektur for hvordan IT arbejder, som vi har udarbejdet sammen med nogle af vores største kunder (Jeg arbejder for HP Software hvor jeg er CTO for den afdeling der "ejer" denne arkitektur). Hvis vi ser på IT har mange drift afdeliger en CMDB som giver en sporbarhed i de systemer der er i drift. Vi kalder det for en fysisk eller realiseret service model. Tilsvarende har nogle firmaer en model af deres forretnings processer som bliver veligeholdt af forretning enhederne. Disse modeller bruges til at udvikle og stille krav til IT systemerne. Fra en IT organisations synspunkt er der behov for at systematisk at "fange" disse modeller så de kan danne grundlag for en formel krav specikation. Vi kalder dette for en konseptuel model for hvad IT skal levere. Mellem dise to modeller sidder udviklings afdelingerne og arbejder på modeller som er mere specifikke end den konceptuelle model men ikke er en realiserede modeller. Vi kalder det den logiske (service) model. Hvis vi kan skabe sporbarhed mellem disse modeller er mange at de problemer du nævner meget nemmer at løse, og det giver desuden en mængde andre sporbarheds fordel some ikke har noget at gøre med krav og tests.
mvh
Lars

Jens Rasmussen

Sjovt, jeg skrev speciale om noget lignende, sporing af design decisions. Da de fleste organisationer bruger Word til dokumentation lavede jeg en plugin til Word, hvor man kan markere stykker tekst som en bestemt type (i dette tilfaelde: en domaenemodel for design decisions), og relatere disse til hinanden. Tilfaeldigvis var firmaet, der blev samarbejdet med ogsaa inden for rumfartsindustrien (Astron). For et overblik, se evt. http://www.cs.rug.nl/search/uploads/Publications/jansen2009esa.pdf

Jesper Louis Andersen

Et problem for mange virksomheder er at de ikke er modne nok til overhovedet at spore krav gennem deres udvikling! De aner ikke engang at der er krav, og hvis de endelig definerer krav, så ændrer de jævnligt kravene.

Men måske det netop ville være godt at få sporbarhed ind i sådanne virksomheder og så plotte hvordan det går med at spore mod kodelinier (og test) der dækker kravet. Når man så ændrer i et krav bliver det pludselig synligt i plottet at dette sætter projektet tilbage i tid :) Det kunne være godt til at opdrage med.

Bemærk også at sporing (tracing) har en anvendelse i forbindelse med software. Det meste af den debugging jeg laver foregår med sporingsværktøjer, der filtrerer hændelser i systemet og nedskriver dem, fordi systemerne helst ikke må stoppes og de har komplekse interaktioner modulerne imellem. Det er bedre end at have loglinier ud over hele koden og så bare lave dynamisk forløbssporing. Men ok, samtidigheden i de systemer er som regel også godt over 2000-3000 :)

Lars Kruse

Sindsygt spændende diskussion!

Vi (Praqma) har indgået et samarbejde med Datalogisk Institut Københavns Universitet (DIKU) og sammen med en professor derfra arbejder vi i øjeblikket på en ansøgning til at være vært for en erhvervsPhD (3år) for en af vores egne dygtige medarbejder.

Pointen er at der findes tonsvis af litteratur om emnet, og det diskuteres livligt indenfor academia, men der findes reelt ingen konkret implemnatation af et værktøj, framework eller platform som kan favne fra 'Product Spec' til 'Release note' - og alt derimellem.

Vores vision er at skabe en open soruce platform som kan udvides med plugins og som kan administrere sporbarhed - ikke bare mellem krav (det findes allerede) eller mellem opgaver og kode (det findes også allerede) men mellem alle tænkelige artefakter.

Faktisk er vi også på udkig leder vi efter sponsorere, som mod at få løbende adgang til platformen og resultaterne og deltage i en referencegruppen omkring denne PhD kunne tænke sig at spæde til. Vi forestiller os at virksomheder der arbejder indefor regulerede miljøre (FDA, Solvency II, ISO, Safety critical osv) vil får instant value for money ved at gå med i sådan et projekt.

Læs meget gerne vores oplæg til DIKU her: http://blueprints.praqma.net/research/traceability

Feed-back er meget velkomment.

Jens Rasmussen

Hej Lars,

Under User Scenarios bliver der beskrevet en model med diverse entiteter. Hvad bestaar detailed design spcifications og tasks af?

I de ovenfornaevnte projekt, som mit speciale var en del af, er brugt en model, hvor design decisions er det centrale element. Det viste sig at tage meget laengere tid end forventet at udarbejde denne model. Se figur 8.1 for modellen i artiklen 'Lessons learned': http://www.cs.rug.nl/paris/papers/AKM09a.pdf

Lars Kruse

Hej Jens

En Detailed Design spec kunne konkret være et word eller Doxygen dokument og en task kunne være er record i en database.

...Ikke at det gør det nemmere!

Vores forestilling er at vi gerne vil bidrage til at løse denne kompleksitet gennem en realtiv simpel core-platform som kan extendes gennem plugin teknologi.

Vi har meget stor respekt for at design og senere representation af modellen i systemet er meget komplekst. Men vore tilgang er at det skal løses med en divide-and-conquer strategi.

Umiddelbart tænker jeg at de problemstillinger som vi vil kigge på er hvordan det her kan gøres brugbart for industrien (se f.eks. http://www.isr.uci.edu/tech_reports/UCI-ISR-06-16.pdf).

Vi vil gerne samarbejde med virksomheder som konkret har dette problem inde på livet - og bringe værdi til dem. Da der er tale om en erhvervsPhD er der et formelt krav om det produkt der skabes i løbet af de 3 år skal have kommerciel værdi. Det er ikke tilstrækkeligt i en ErhvervsPhD blot at producere ny viden.

Dit speciale lyder spændende! ..er det publiceret?

Jens Rasmussen

Hej Lars,

Jeg har lige skimmet artiklerne, hseke05 nævner ikke de tools, jeg har hørt om ikke (men der er også sket en del siden '05).

Den anden virker til at være fokuseret på at holde design dokumenter konsistent med data om requirements/artefakter, og traceability i mindre grad.

Mit speciale var lavet under et project, der hedder GRIFFIN (a grid for information about architectural knowledge). Der er nogle interessante artikler, og her et ph.d-projekt om architectural knowledge. Der er en demo af et tool til Word, jeg lavede, og et andet til Excel her.

Jeg fandt en fin samling artikler om traceability her. Se også [Tang]

Log ind eller opret en konto for at skrive kommentarer

IT Businesses