Hvordan vurdering av potensielle leverandører påvirker programvareutvikling og standardisering

I arbeidet med å vurdere potensielle leverandører er det viktig å etablere et rammeverk som er både kulturelt uavhengig og anvendelig på tvers av ulike domener og organisasjoner. Hensikten er å tillate eksisterende modeller å fortsette å bli brukt, samtidig som det gis et felles rammeverk for å rapportere og spore resultater fra forskjellige modeller og metoder. Uavhengig av om organisasjoner bruker betegnelsen "SPICE" eller et mer kjent merkenavn, er det sannsynlig at prosessvurdering vil bli brukt på en internasjonal skala.

Et annet eksempel er et energiselskap som bruker standardene for utvikling av programvare til kjernekraftverk og utfører årsaksanalyse helt ned på standardene selv når en feil oppdages. Til tross for slike suksesser har SESC-samlingen sine utfordringer. Den har blitt utviklet bit for bit over en periode på tjue år, og har derfor blitt kritisert som ad hoc. For å møte disse utfordringene startet SESC en reorganisering av sine standarder i 1993, med mål om å sikre at de svarer på behovene til programvareingeniører.

Som en del av denne omorganiseringen ble flere viktige dokumenter utviklet: SESC Survey som identifiserte 220 eksisterende og pågående normative dokumenter utviklet av 46 organisasjoner om programvareutvikling, og SESC Master Plan som identifiserte 18 kundeklasser for programvareutviklingsstandarder. Planen inneholdt 370 forventninger for hver kundeklasse, 165 mål for programvareutviklingsstandarder, og 222 potensielle emner for fremtidige standarder.

I 1995 ble SESC Strategy Statement utarbeidet, hvor programvareutvikling ble satt i kontekst med tilknyttede disipliner som kvalitetsstyring og systemteknikk, inkludert tverrgående disipliner som sikkerhet og pålitelighet. Denne strategiplanen etablerte en felles organisasjon for alle SESC-standarder, og fastslo at standardene bør anvendes av prosjekter som samhandler med kunder, bruker ressurser og utfører prosesser for å produsere produkter.

SESCs arbeid er koordinert med ISO/IEC JTC1/SC7 gjennom ANSI Technical Advisory Group. Denne koordineringen innebærer at et mulig resultat kan være en revisjon av SESC-samlingen slik at en kjernegruppe av standarder kan brukes til å legge til detaljer i prosessrammeverket 12207. Noen organisasjoner, allerede under juridisk og regulatorisk press, har valgt å bruke SESC-samlingens standarder for å markere sin overholdelse. I fremtiden vil det trolig bli mer attraktivt for organisasjoner å oppnå standardiserte "merker" som indikerer at de følger de internasjonale livssyklusprosessene (12207), standardene som beskriver disse prosessene (SESC), og at de har en modenhet i anvendelsen av prosessene (SPICE).

Videre bør en effektiv livssyklusmodell inkludere praksis for gjenbruk på alle nivåer, ettersom gjenbruk kan forekomme i enhver fase av programvareutvikling. Et viktig aspekt ved tradisjonelle livssyklusmodeller er adskillelsen mellom design og implementering. I et miljø for gjenbruk av komponenter er disse stadiene tett knyttet sammen. Gjenbruk av komponenter blir langt enklere dersom komponentene er i maskinlesbart format, noe som er avgjørende for organisering og gjenfinning av materialet, samt for integrering i programvareteknologiske støtteverktøy.

En av de største hindringene for gjenbruk i programvareutvikling er mangfoldet av eksisterende livssyklusmodeller og språk. Selv innen et spesifikt domene, som programvare for produksjon eller helsevesen, er det viktig at aktørene i feltet enes om standarder. Denne enigheten om standarder er et kjennetegn på et profesjonelt fellesskap og vil være assosiert med spesifikke merker som signaliserer overholdelse av profesjonelle normer. Programvareleverandører vil tjene disse merkene for å vise at de følger anerkjente standarder.

Endtext

Hvordan verktøy for gjenbruk kan forbedre programvareutvikling og effektivisere grensesnitt

I stedet for å fokusere på detaljene i den fysiske koden, gir verktøy som Architect utviklere muligheten til å designe og tilpasse brukergrensesnitt ved hjelp av grafiske verktøy. Grensesnittet kan tegnes direkte på skjermen, der brukeren kan dra og slippe elementer som tekstfelter, knapper og menyer for å skape den nødvendige strukturen. Etter at designet er ferdig, kan utvikleren tilpasse funksjonene til hvert enkelt element – for eksempel ved å spesifisere hva som skjer når en knapp trykkes eller ved å justere tekstformateringen.

Den største fordelen ved denne tilnærmingen er at den gjør det mulig å lage komplekse grensesnitt uten at utvikleren trenger å kjenne detaljene bak koden som gjør disse elementene funksjonelle. I stedet kan utvikleren bruke verktøy som Architect for å definere funksjonaliteten på et høyere nivå, slik at arbeidet kan konsentreres om spesifikke oppgaver relatert til applikasjonen. For eksempel kan en utvikler lage et grensesnitt for et program uten å måtte bekymre seg for hvordan vinduer åpnes eller hvordan knapper skal håndtere brukerens input.

Når grensesnittet er utformet, kan verktøyet generere en selvstendig C-kode som representerer det grafiske designet. Denne koden kan deretter brukes som grunnlag for videre utvikling, uten at utvikleren trenger å gjøre manuelle justeringer på koden. Denne tilnærmingen er både tidseffektiv og kostnadseffektiv, da den reduserer behovet for langvarig koding og testing.

En annen viktig funksjon ved verktøy som Architect er muligheten til å lage gjenbrukbare komponenter. Når et grensesnitt er laget, kan spesifikke deler av det – som for eksempel tittelen på et vindu – defineres som variabler. Dette gjør det mulig å lage flere instanser av samme grensesnitt med forskjellige verdier, uten å måtte opprette et nytt design fra bunnen av. Dette gjenbruksmønsteret er spesielt nyttig når det gjelder store applikasjoner som krever at flere lignende vinduer og dialogbokser opprettes.

Bruken av gjenbrukbare komponenter åpner også for at utviklere kan bygge et bibliotek av høynivåkomponenter som kan benyttes på tvers av prosjekter. Dette bidrar til å standardisere utviklingsprosessen og forbedre produktiviteten. Hvis et utviklingsselskap har et bibliotek med ofte brukte komponenter, som en filvelger, kan disse komponentene lastes inn i grensesnittgeneratoren etter behov, og dermed spare utviklerne for tid.

Når man ser på slike verktøy i et bredere perspektiv, er det viktig å merke seg at de ikke bare er et teknologisk hjelpemiddel, men også en viktig del av en større utviklingstrend mot systematisk gjenbruk i programvareutvikling. Gjenbruk av programvarekomponenter og grensesnitt har vist seg å kunne øke produktiviteten og kvaliteten på programvareutviklingen betraktelig, som demonstrert i flere vellykkede bedriftskasus.

For eksempel, ved å bruke et standardisert livssyklussystem, som det som ble brukt av Toshiba Fuchu Software Factory, har organisasjoner oppnådd betydelige produktivitetsgevinster. Fuchu rapporterer en årlig produktivitetsøkning på 14 % som et resultat av deres systematiske tilnærming til gjenbruk av programvarekomponenter. Dette ble ytterligere understøttet av etableringen av et omfattende bibliotek med gjenbrukbare programvaremoduler som ble brukt på tvers av ulike prosjekter. Det er også et felles trekk ved flere andre selskaper som GTE, Raytheon og NEC, som har benyttet gjenbruk for å redusere kostnader og forbedre produktiviteten.

Slike verktøy og teknikker er ikke bare for store organisasjoner som utvikler komplekse programvaresystemer. Også mindre utviklingsteam kan dra stor nytte av å implementere metoder for systematisk gjenbruk, enten det dreier seg om hele grensesnitt eller spesifikke funksjoner i applikasjoner. Ved å utnytte eksisterende komponenter og systemer kan utviklere fokusere mer på innovasjon og tilpasse løsningene til spesifikke behov.

I sum viser bruk av verktøy som Interface Architect at det er mulig å oppnå en mer strømlinjeformet, effektiv og kostnadseffektiv utviklingsprosess gjennom gjenbruk og modulære tilnærminger. Dette er en trend som ikke bare forbedrer den tekniske kvaliteten på programvaren, men også øker hastigheten på utviklingen og reduserer risikoen for feil. Det er viktig at utviklere og selskaper tar i bruk slike verktøy for å være konkurransedyktige i en stadig mer kompleks og kravstor programvareverden.

Hvordan kan vi organisere og vedlikeholde biblioteker og utdanningsobjekter på nett?

Indekseringen fungerer gjennom et system av meldinger og arbeidsrom, hvor hver rolle er ansvarlig for en spesifikk del av prosessen. Når en indekserer foreslår endringer til et indekseringsspråk, blir meldingen automatisk generert og videresendt til en ekspert på indekseringsspråk. Denne prosessen er automatisert, men samtidig kan menneskelig interaksjon spille en viktig rolle for å sikre at systemet fungerer optimalt. Vedlikeholdet av et bibliotek og indeksering på nett kan derfor være en kompleks og tidkrevende oppgave som krever både menneskelig innsats og teknologisk støtte.

I tillegg til indeksering, er det også behov for kvalitetssikring. En spesialist på kvalitetssikring sørger for at de ulike rollene som inngår i vedlikeholdsprosessen utfører sine oppgaver på en korrekt måte. Denne spesialisten samarbeider tett med andre aktører for å sørge for at alle trinn i prosessen er fullført med høy kvalitet. Et annet viktig aspekt ved vedlikehold av slike systemer er brukermonitorering. Hvordan blir biblioteket brukt, og hvilke behov har brukerne? Dette må kontinuerlig overvåkes og vurderes for å sikre at materialet er tilgjengelig og relevant for de som trenger det.

I tillegg til bibliotekets vedlikehold, er det pågangsmot fra forskjellige organisasjoner, som Educom, som jobber med å standardisere utdanningsteknologi. Educom har utviklet en metadata-spesifikasjon for å beskrive læringsressurser som er tilgjengelige eller katalogisert på nettet. Denne spesifikasjonen, IMS Metadata, har som mål å forbedre bruken av teknologi i utdanning ved å tilby en felles måte å beskrive læringsressurser på. Denne metadataen består av en ordliste med termer som beskriver ressurser, inkludert forfatter, kreditter, interaktivitet, læringsnivå og annet.

Videre er det viktig å forstå hvordan utdanningsobjekter kan deles og gjenbrukes i større skala, og hvordan felles plattformer kan fremme samarbeid og innovasjon i utdanningsfeltet. Apple Corporation har vært en pioner på dette området gjennom utviklingen av Educational Object Economy (EOE). EOE er et fellesskap der utdanningsressurser som for eksempel Java-applets kan deles, forbedres og utvikles videre av både utviklere, lærere og studenter. Ved å etablere et nettsted hvor medlemmer kan dele og legge til verdi til materialer, kan EOE bidra til å redusere duplisering av innsats og organisere tilgjengelige ressurser på en mer strukturert måte.

EOE har som mål å skape et dynamisk samfunn av skapere og brukere som samarbeider om å forbedre eksisterende materialer og utvikle nye, relevante ressurser for utdanning. Etter flere måneders drift hadde EOE allerede over 1 000 pekere til Java-applets, hvor en betydelig andel hadde kildekode tilgjengelig. Dette fellesskapet var en tidlig indikasjon på hvordan online-samfunn kan være et kraftig verktøy for å støtte utdanningsutvikling og innovasjon.

En utfordring for EOE og lignende initiativer er å skape en sterk og aktiv fellesskapsdynamikk som kan støtte opp om videre utvikling. Teknologien som trengs for å opprette en EOE-plattform er relativt enkel, men å bygge et bærekraftig og produktivt fellesskap er en langt større utfordring. Det er ikke bare snakk om å etablere teknologiske verktøy, men også om å skape et miljø hvor medlemmene er motiverte for å dele kunnskap, samarbeide og kontinuerlig forbedre tilgjengelige ressurser.

Hvordan Internasjonale Standarder på Programvarelivssykluser Former Global Programvareutvikling

Programvarelivssykluser er et fundamentalt aspekt ved utvikling og vedlikehold av programvare, og etablering av internasjonale standarder har vært avgjørende for å sikre at disse prosessene er konsistente og effektive på tvers av landegrenser. I denne sammenhengen spiller ISO en sentral rolle i utviklingen av standarder som styrer livssyklusene for programvare. ISO/IEC 12207 er en av de mest relevante internasjonale standardene for programvarelivssykluser, og har fått bred anerkjennelse over hele verden.

ISO (International Organization for Standardization) utvikler sine standarder gjennom tekniske komiteer som samarbeider med medlemslandene. En utkaststandard blir først fremmet av en teknisk komité og må godkjennes av minst 75% av medlemslandene for å bli en internasjonal standard. Når en standard er vedtatt, gir den et felles rammeverk som kan brukes på tvers av nasjonale og industrielle grenser. I tillegg til ISO, har andre organisasjoner som IEEE (Institute of Electrical and Electronics Engineers) og ANSI (American National Standards Institute) også hatt betydelig innflytelse på utformingen av livssyklusstandarder, med flere av deres egne spesifikasjoner og modeller.

ISO/IEC 12207 ble utviklet for å gi et universelt rammeverk som kan brukes i alle faser av programvareutvikling, vedlikehold og drift. Standarden spesifiserer ikke bare utviklingsprosesser, men også prosesser for anskaffelse, vedlikehold, drift og forsyning. I tillegg inkluderer den både primære og støttende prosesser samt organisasjonsprosesser som kan tilpasses ulike typer prosjekter og kontrakter. Det betyr at organisasjoner kan tilpasse standarden ved å fjerne oppgaver som ikke er relevante for deres spesifikke behov.

En utfordring med ISO 12207 er at det ikke inkluderer detaljerte beskrivelser for registrering av informasjon som er essensiell for programvareutvikling. Standarden gir heller ikke en klar overgangsvei for de som allerede benytter seg av andre nasjonale standarder, som for eksempel ANSI-016, som er en amerikansk standard for programvarelivssykluser. I USA har dette ført til utviklingen av en "US Industrial Implementation" av ISO 12207, som gjør det mulig for organisasjoner å tilpasse standarden og integrere den med andre eksisterende prosesser.

En av de mest kjente prosessene knyttet til ISO 12207 er Capability Maturity Model (CMM), utviklet av Software Engineering Institute ved Carnegie Mellon University. CMM begynte som et selvvurderingsverktøy, men ble senere brukt av det amerikanske forsvaret som et evalueringsverktøy for å vurdere potensielle leverandørers evne til å utvikle programvare. På samme måte som CMM har ISO/IEC JTC1 utviklet et prosjekt kalt SPICE (Software Process Improvement and Capability dEtermination) som har som mål å harmonisere eksisterende prosessvurderingsmetoder ved å etablere et felles rammeverk for vurdering av prosesskapabilitet på tvers av organisasjoner.

Standardene som har utviklet seg i løpet av de siste tiårene, har vært svært viktige for å bygge et felles språk og rammeverk for programvareutvikling på tvers av landegrenser. Spesielt for internasjonale prosjekter er det avgjørende at både utviklere og kunder har en felles forståelse av hvilke prosesser og metoder som benyttes i utviklingen og vedlikeholdet av programvaren. ISO 12207 har blitt et viktig verktøy for å standardisere disse prosessene, og mange nasjoner er i ferd med å adoptere denne standarden på nasjonalt nivå.

Det er viktig å merke seg at ISO 12207 ikke er en statisk standard, men en som kan tilpasses og endres etter behov. Det betyr at organisasjoner kan integrere den med sine egne spesifikke metoder og prosesser, og bruke den som et felles rammeverk for internasjonale kontrakter. Dette gjør at standarden er fleksibel og kan tilpasses ulike typer programvareutviklingsprosjekter, fra små start-ups til store, komplekse systemer.

Endelig bør leseren være oppmerksom på at implementeringen av ISO 12207 kan variere avhengig av hvilket land eller hvilken sektor man opererer i. For eksempel har det amerikanske forsvaret utviklet et spesifikt sett med krav for å kunne sertifisere prosesser som er i samsvar med ISO 12207. Andre nasjoner kan ha ulike tilnærminger og krav, og det er viktig å forstå hvilke spesifikke reguleringer som gjelder i det aktuelle markedet.