Hva er de grunnleggende forventningene til standarder for programvaregjenbruk, og hvilken rolle spiller de i standardiseringsprosessen?

Standarder for programvaregjenbruk har blitt en uunnværlig del av programvareutviklingsprosessen, ettersom de er med på å sikre kvalitet, pålitelighet og kostnadseffektivitet. I utgangspunktet er forventningene til standardene ganske tydelige: de skal hjelpe utviklere å lage programvare som er både funksjonell og lett å tilpasse og vedlikeholde. Forventningene fra brukerne av programvaren, som utviklere, programvareadministratorer og kjøpere, inkluderer blant annet korrekthet, mulighet for modifikasjon, og pålitelig ytelse. Bruken av standarder skal sørge for at programvaren møter spesifikke operasjonelle, funksjonelle og ytelsesmessige krav, samtidig som den skal være enkel å verifisere.

Den Master Plan for Software Engineering Standards (SESC, 1993) gir en detaljert oversikt over hvilke forventninger brukere har til standardene. For eksempel skal programvaren kunne tilby en standardisert løsning på velkjente problemer, som er både korrekt og pålitelig. I tillegg skal den være brukervennlig og tilrettelegge for lett vedlikehold og modifikasjon. For å oppnå dette kreves det at standardene fremmer gjenbrukbare programvareprosesser og at de gjør det mulig å estimere tid og budsjett for vedlikeholdsarbeid.

I et slikt system spiller flere forskjellige typer standarder en viktig rolle. For eksempel kan standarder for domenenanalysemetoder eller metoder for å identifisere muligheter for gjenbruk hjelpe til med å adressere behovene for korrekt kategorisering og identifisering av programvarekomponenter som kan gjenbrukes. På samme måte kan standarder for produksjon av gjenbrukbare programvarekomponenter, dokumentasjon og sertifisering av programvare bidra til å oppfylle de spesifikke behovene til både utviklere og programvarekjøpere.

Det finnes også en rekke roller som ulike typer standarder kan spille. Noen standarder fokuserer på selve produksjonen av programvarekomponentene, mens andre kan være rettet mot dokumentasjonen som beskriver disse komponentene. For eksempel kan standarder som gjelder dokumentasjon bidra til at programvarekomponentene blir lettere å forstå og integrere i eksisterende systemer. På samme måte kan standarder som omhandler sertifisering gi kjøpere en trygghet i at programvaren de anskaffer oppfyller nødvendige kvalitetskrav.

Brukere av programvare forventer at standardene skal sikre at programvaren er kategorisert på en nyttig måte, og at den gir en korrekt løsning på kjente problemer. Standardene bør også legge til rette for at programvaren kan endres innenfor definerte rammer for å imøtekomme spesifikke krav, uten å gå på bekostning av ytelse eller pålitelighet. I tillegg skal de tillate at programvaren kan vedlikeholdes og videreutvikles på en planmessig måte, som tar hensyn til både eksisterende funksjoner og eventuelle nye krav.

For programvarekjøpere er det viktig at standardene omfatter prosesser for evaluering og valg av programvare, samt at de gir klare retningslinjer for programvarens funksjoner og egenskaper. Dette inkluderer detaljer om hvilke krav som stilles til programvarens drift, funksjonalitet og ytelse, samt eventuelle begrensninger og forskjeller mellom ulike versjoner av programvaren. Standardene bør også beskrive hvordan nødvendige programvaremiljøer er definert, slik at potensielle forbedringer kan identifiseres og implementeres effektivt.

Et sentralt aspekt for programvareadministrasjonsledere er at standardene bør gi retningslinjer for å vurdere verdien av programvaren som en ressurs. Dette innebærer at det må finnes pålitelige kostnadsmodeller som kan hjelpe til med å avgjøre om det er mer økonomisk å modifisere eksisterende programvare eller erstatte den med en ny løsning. Videre bør standardene bidra til å identifisere potensielle gevinster ved gjenbruk av eksisterende programvarekomponenter og sørge for at det finnes felles metoder for identifisering og merking av komponenter som kan brukes på nytt.

Når det gjelder eksisterende dokumenter og standarder som kan bidra til standardiseringsprosessen, er det flere faktorer som bør vurderes. Disse inkluderer relevansen av dokumentene for programvaregjenbruk, deres påvirkning på praksis i programvareutvikling, samt dokumentenes normative karakter. Dokumentene kan klassifiseres etter hvordan de kan bidra til standardisering: som grunnleggende dokumenter, normative råd, nyttig informasjon eller som dokumenter som ikke er relevante for standardiseringen.

Relevansen av dokumentene vurderes ut fra deres betydning for programvaregjenbruk og hvor godt de kan bidra til å møte brukerforventningene. Påvirkningen vurderes ved å se på hvor mye dokumentene allerede har blitt akseptert i programvareutviklingsmiljøer, og hvor effektivt de har bidratt til å forbedre praksis på området. Dokumentenes normative karakter vurderes ut fra hvor mye de tilbyr av retningslinjer og ikke bare informasjon, og deres aktualitet vurderes på grunnlag av hvor relevant de er i dagens programvareutvikling. Kvaliteten på dokumentene vurderes etter klarhet og nøyaktighet i beskrivelsene.

For å oppsummere er det klart at standarder for programvaregjenbruk spiller en nøkkelrolle i å sikre kvalitet, effektivitet og pålitelighet i programvareutviklingen. Disse standardene gir utviklere, kjøpere og forvaltere av programvare nødvendige verktøy for å sikre at programvaren oppfyller kravene til både funksjonalitet og vedlikehold. Ved å bruke eksisterende dokumenter og standarder som grunnlag kan man videreutvikle et robust system som fremmer gjenbruk og reduserer kostnadene knyttet til programvareutvikling.

Hvordan bygge et strukturkart fra et dataflytdiagram og utvikle programenheter i pseudo-kode

Dataflytdiagrammer er et verktøy som viser hvordan data transformeres mens det beveger seg fra én systemkomponent til en annen. Når et slikt diagram er laget, kan det brukes til å bygge et strukturkart som gir en hierarkisk oversikt over systemets programenheter. Strukturdiagrammer er nyttige for systemdesign da de gir en klar fremstilling av hvordan programvaren skal brytes ned i separate moduler og hvordan disse modulene igjen kan deles videre til mindre enheter, helt til informasjonen i modulene blir lett håndterbar.

Et godt eksempel på bruken av dette verktøyet kan ses i et Office Information Retrieval System (OIRS). Dette systemet kan være designet til å utføre flere funksjoner som å arkivere dokumenter, hente frem dokumenter basert på forespørsler, vedlikeholde indekser, og til og med slette dokumenter. Et første dataflytdiagram for et slikt system kan avsløre de nødvendige modulene som håndterer hver input og output, og vise hvordan brukerens kommandoer fører til databaseforespørsler som genererer output-meldinger og data.

Strukturdiagrammet bygger videre på dette diagrammet ved å pålegge et hierarkisk rammeverk. Dette gjør det enklere å avgjøre hvilke deler av systemet som kan utvikles uavhengig, og gir et overordnet bilde av hvordan de forskjellige komponentene i systemet henger sammen. I OIRS-eksempelet vil for eksempel moduler som håndterer databasetilgang og dokumentbehandling kunne utvikles separat, mens deres samhandling kan defineres i det overordnede strukturdiagrammet.

Når programdesignen er på plass, kan man gå videre til implementeringen, som innebærer oversettelsen av designet til faktisk kode. Det er viktig at implementeringen nøyaktig reflekterer designet, og at det er mulig å spore alle beslutninger som ble tatt under designfasen. Dette kan sikres ved hjelp av veldefinerte designnotasjoner som også kan spesifisere retningslinjer for hvordan designkonstruksjoner skal oversettes til kode.

Valget av programmeringsspråk spiller en viktig rolle i implementeringsprosessen. Språkets evne til å støtte robust og feilfri programvare er avgjørende. For eksempel kan språk som Ada tilby mekanismer for å unngå feil gjennom typekontroll og generiske prosedyrer som gjør det lettere å bygge komponenter som er fleksible og gjenbrukbare. Språk som også støtter god feilhåndtering gjennom unntak, kan bidra til å sikre stabilitet og pålitelighet i systemet.

En annen viktig praksis innen programvareutvikling er informasjonsskjuling. Dette refererer til ideen om å skjule kompleks implementasjonsinformasjon, mens grensesnittet til en komponent forblir synlig og veldefinert. Dette konseptet er godt illustrert gjennom objektorientert programmering, hvor objekter representerer dataenheter, og deres interne tilstand kan endres gjennom veldefinerte operasjoner uten at man trenger å kjenne til detaljene i hvordan endringene skjer. Denne tilnærmingen gir fleksibilitet, da det gjør det mulig å bytte ut funksjonelt like objekter uten å måtte endre andre deler av systemet.

Testing og dokumentasjon er også uunnværlige deler av programvareutviklingsprosessen. Testing kan deles inn i funksjonell testing, som fokuserer på å validere at komponentene fungerer som forventet under realistiske forhold, og strukturell testing, som benytter kunnskap om komponentens struktur for å utforme testdata. Kvalitetssikring bør ikke vente til koden er ferdig; testing må være en kontinuerlig prosess som er integrert i hver fase av utviklingssyklusen.

Dokumentasjon er kanskje den viktigste komponenten av programvareutviklingens livssyklus. Den gir nødvendige detaljer både for utviklingsprosessen og for vedlikeholdet etter at systemet er tatt i bruk. Dokumentasjonen skal ikke bare fange tekniske detaljer om hvordan systemet er bygget, men også sikre at det er mulig for andre utviklere å forstå og vedlikeholde systemet på sikt. Dette er et arbeid som bør sees på som en egen disiplin innen programvareutvikling, og som i mange organisasjoner krever dedikerte team.

I store organisasjoner som IBM, for eksempel, ble rollen som teknisk skribent i 1979 omdøpt til 'informasjon utvikler'. Dette gjenspeiler den økte viktigheten av dokumentasjon og hvordan den har blitt en integrert del av produktutviklingen. Informasjonsutviklere arbeider ikke bare med å dokumentere produkter, men har også ansvar for å utvikle detaljerte retningslinjer og veiledninger som kan brukes av både utviklingsteamet og sluttbrukerne.

Endtext