Är du säker på att du har rätt? 0 0 © 1 9 9 9 I E E E N o v e m e r / D e c e m b e r 1 9 9 I E E E S o f t w a r 5 1 ver åren har det funnits ett brett intresse för att skapa standarder för programvaruteknik. En auktoritativ undersökning upptäckte cirka 315 standarder, guider, handböcker och andra normativa dokument som upprätthålls av 46 olika organisationer (se sidmenyn "Källor för Software Engineering Standards"). 1 Icke desto mindre har utnyttjandet av de tillgängliga standarderna varit något nedslående. Hoppfulla användare rapporterar om svårigheter att hitta de standarder som passar deras särskilda situation bland de många tillgängliga. De rapporterar också att detaljerade skillnader mellan standarder gör det svårt att tillämpa dem på ett enhetligt sätt. På ett område där två standarder överlappar varandra kan till exempel var och en betona ett annat tillvägagångssätt eller använda olika terminologi. Vi behöver en strategi för att hantera en standardsamling som betonar integreringen av de olika standarderna. Sedan 1991 har vi som arbetar med IEEE Computer Society's Software Engineering Standards Committee gjort ansträngningar för att hantera standardiseringsinsamlingen för att främja enhetlighet. Även om colJames W. Moore, The Mitre Corporation En integrerad samling av Software Engineering Standards IEEE Soft ware Engineering Standards Committee har vidtagit avsiktliga åtgärder för att förena och integrera sin samling av mjuk ware engineering standarder. Uppmuntrande resultat är uppenbara i sin senaste publikation, som är organiserad kring en enda arkitektur för SESC-samlingen. Lection har fördubblats i storlek, vi har avsevärt förbättrat dess integrationsgrad. Processen är ännu inte avslutad, men betydande framsteg har gjorts, vilket kulminerade i offentliggörandet av 1999 års fyra volymer av SESC-standarder som paketerats i enlighet med de integrerande principerna för insamlingen. Den här artikeln förklarar principerna för SESC-samlingen och beskriver våra framsteg mot att integrera de olika standarderna i den. För vissa kan värdet av att använda standarder för programvaruteknik vara uppenbart - de bidrar till disciplinerad praxis, därför förbättrar de produktkvaliteten. Även om dessa skäl på ett giltigt sätt förklarar hur standarder används i programvaruteknikhantverk, karakteriserar de inte standardernas unika bidrag till yrket. För detta måste vi titta på värdet av standarder för dem som köper och säljer programvarutekniska varor och tjänster. Många varor och tjänster kan köpas tryggt efter en enkel undersökning eller efter att ha studerat leverantörens produktlitteratur. Komplexiteten hos programvaruprodukter leder dock till ett behov av en mer grundlig analys. Vare sig köps som en färdig produkt eller som en kontrakterad utveckling, inköps- eller acceptansbeslutet är komplicerat eftersom viktiga egenskaper effektivt kan döljas från undersökning tills ovanliga omständigheter eller förändrade användningsmönster avslöjar dem. Standarder kan ge stöd och kan skydda köparen genom att ♦ ge en vokabulär för kommunikation mellan köparen och säljaren; ♦ tillhandahålla objektiva kriterier för annars vaga påståenden om produktens natur; ♦ definiera metoder för att karakterisera gäckande egenskaper, såsom tillförlitlighet; och ♦ säkerställa säljaren att särskilda kvalitetssäkringsmetoder tillämpades. Fördelarna med standarder för att skydda säljaren är förmodligen underskattad i programvaruteknik samhället. Ur denna synvinkel är standarder viktiga, inte för att de representerar bästa praxis, utan för att de representerar tillräckligt god praxis. Domstolarna betraktar i allmänhet tillämpningen av standarder som viktiga bevis för att ingenjörer utför sitt arbete med tillbörlig omsorg och ansvar. Om en ingenjör stäms för vårdslöshet eller vårdslöshet, kan han eller hon åberopa de normer som användes när han eller hon utförde arbetet för att visa att det utfördes i enlighet med kodifierad yrkespraxis. Genom att tillhandahålla viktiga fördelar för både köparen och säljaren stöder programvarutekniska standarder framväxten av en programvaruteknik profession som kännetecknas av konsensually validerad Software Engineering standarder avser ansvarsfull praxis för programvaruteknik. De hanterar ofta processer, men ibland behandlar de generiska produktegenskaper eller stödjande resurser. Ämnena i standarderna inkluderar fraser som är bekanta med storskaliga programutvecklare konfigurationshantering, kvalitetssäkring, verifiering, validering, och så vidare. Standarderna behandlar i allmänhet inte specifika programmeringsspråk eller -teknik. De discipliner som anges i standarderna överskrider i allmänhet den specifika teknikens livslängd. Tre standarder i USA är inte strikt delegerade som det är i många andra länder. Över 500 organisationer i USA gör standarder av något slag. Två organisationer som nämns i denna artikel är Electronic Industries Alliance och Institutet för elektriska och elektroniska ingenjörer. EIA har spelat en viktig roll i att "demilitarisera" de standarder för komplex mjukvaruutveckling som ursprungligen skrevs för användning i försvarsindustrin. IEEE Computer Societys Software Engineering Standards Committee hanterar världens mest omfattande samling av programvarutekniska standarder (nästan 50), som utvecklats sedan 1979. SESC fungerar som en utvecklare av dessa standarder, men också som en integratör av specifikationer och standarder som utvecklats av andra organisationer. Den har antagit, ibland med ändringar, standarder som utvecklats av organisationer som ISO/IEC JTC1/SC7 och Project Management Institute. Normer för ansvarsfullt uppförande. Med sådana tydliga fördelar, skulle du förvänta dig en nästan universell tillämpning av standarder för programvaruteknik. Tyvärr är detta svårt på grund av den stora mängden tillgänglig och ibland inkonsekvent information. I början av 1990-talet inrättade SESC en planeringskommitté för att inleda de långsiktiga insatser som krävs för att integrera insamlingen. Kommittén studerade kundens behov 2 och undersökte befintliga standarder, 3 drar slutsatsen att det inte fanns någon brist på tillgängliga råd för praxis av programvaruteknik. Det fanns dock inget tydligt sätt för användarna att välja de råd som var lämpliga för deras behov. Dessutom utgjorde den individuellt optimerade karaktären hos varje standard hinder för att välja ut och tillämpa dem tillsammans. Den programvarutekniska gemenskapen behövde en integrerad samling standarder som kunde tillämpas unisont och från vilka användarna enkelt kunde välja lämpliga standarder. Med denna information var vi redo att utveckla en integrerande arkitektur för SESC-samlingen, kallad Vision 2000. 4 Den senast publicerade utgåvan av SESC-samlingen 5 återspeglar Vision 2000-arkitekturen, som omfattar tre viktiga organisationskriterier (se figur 1 ). Begreppet det första organisationskriteriet, normativa nivåer, är att olika standarder bör ge olika nivåer av rådgivning - ibland detaljerade, ibland allmänna-för olika användningsområden. Det andra organisationskriteriet, objekt för programvaruteknik, erkänner att programvarutekniska standarder behandlar fyra olika objekt: kund, process, produkt och resurs. Det tredje organisationskriteriet är relationer till andra discipliner. SESC Software Engineering Collection är placerad inom ramen för andra standarder som valts från programvaruteknik, kvalitetshantering och olika systemtekniska discipliner. Vi lånade begreppet normativa nivåer från andra framgångsrika standardsamlingar. Det översta skiktet innehåller standarder för terminologi och andra nyckelbegrepp. Sådana standarder är i allmänhet icke-preskriptiva; de innehåller helt enkelt definitioner, taxonomier eller annat referensmaterial som kan användas i andra standarder i insamlingen. Den IEEE programvara engineering vokabulär, IEEE Std. 610.12 omfattas av denna kategori. Nästa lager är också icke-preskriptivt, ockuperat av en eller några dokument som fungerar som en övergripande guide till resten av samlingen. Dokumentet förklarar samlingens arkitektur och de viktigaste sambanden mellan standarderna inom den. Vi bestämde oss för att fylla detta lager genom att godkänna och godkänna en lärobok i stället för att skriva en standard. 6 Det tredje skiktet innehåller standarder som ger en användare riktlinjer eller principer. Principer är användbara eftersom det är svårt att skriva detaljerade standarder som täcker alla tänkbara användningsområden. I en specifik situation, om detaljerna inte verkar tillämpliga, kan en användare tillämpa principerna istället. När det gäller SESC-insamlingen finns det för närvarande inga principer för dokument som behandlar resurser och produkter. Delar av IEEE/EIA 12207 fyller dock denna roll för standarder som handlar om kunder och processer. Det fjärde skiktet, elementstandarder, är det som är mest bekant för standardanvändare. Den innehåller dokument med krav på överensstämmelse inom olika viktiga områden. De flesta av SESC-samlingens standarder är grupperade i detta lager. Det femte skiktet innehåller bestämmelser för tillämpning N o v e m b e r / D e c e m b e r 1 9 9 9 I E E E S o f t w a r e guider. Ibland behöver användarna kompletterande dokument för att beskriva hur man tillämpar en elementstandard i särskilda situationer. Dessa dokument är ofta vägledningar men kan vara standarder som bygger på krav på överensstämmelse från lämpliga standarder. Till exempel har vi en elementär standard på en kvalitetssäkringsplan för programvara och en applikationsguide som beskriver den övergripande disciplinen för SQA-planering. Det nedre skiktet ses som en verktygslåda med detaljerade tekniker. Standarderna i detta skikt är "subrutiner" som någon av de andra standarderna kan åberopa för att ställa krav på ett visst område. Ett exempel från SESC-samlingen är IEEE Std. 1044 om klassificering av programavvikelser. Föremålen för programvaruteknik är ett resultat av den abstrakta modellen av programvaruteknik som beskrivs i figur 2. Denna modell centrerar sig på programvaruteknikprojektet som brännpunkt för tillämpning av standarder för programvaruteknik. I detta avseende använder ett projekt resurser för att utföra processer för att producera produkter för en kund. Modellen är instruktiv i att tillhandahålla fyra viktiga ämnesområden som kan behandlas enligt standarder: kund, process, produkt och resurs. Vi organiserade de fyra volymerna av 1999 års standardutgåva enligt de fyra objekten. Programvaruteknik existerar inte isolerat från andra discipliner. Dess syfte är att tillämpa principerna för matematik, ingenjörsvetenskap och datavetenskap på olika tillämpningsområden. Dessutom ärver det principer från mer allmänna discipliner som systemteknik, kvalitetsstyrning och projektledning. Dess arbete påverkas också av övergripande discipliner som tillförlitlighet, säkerhet och trygghet. Särskilt i denna tid av betoning på processförbättringar har vi inte råd att våra standarder är oförenliga med nära relaterade standarder från andra discipliner. Det skulle vara tragiskt om standarderna för bästa praxis inom programvaruteknik var nyckfullt oförenliga med, till exempel, standarderna för kvalitetsstyrning. Där förhållandet är starkt och där det finns lämpliga standarder har vi därför valt några nyckelstandarder från andra discipliner som integrationsmål. Till exempel tillhandahåller ISO 9000-3 en bro mellan programvaruteknik och den berömda ISO 9000-serien av kvalitetsstyrningsstandarder, och Project Management Institute's Guide to the Project Management Body of Knowledge (PMBOK) beskriver allmänna principer för projektledning som SESC-standarder anpassade till ämnet programvaruprojektledning (http://www. pmi.org/publictn/pmboktoc.htm). Genom att anta eller på annat sätt erkänna nyckelstandarder från relaterade discipliner undviker vi behovet av att på nytt uppfinna nyckelprinciper. Inte alla integrerande standarder i SESC-samlingen lånas från andra discipliner. IEEE/EIA 12207, Software Life Cycle Processes, är ett paraply för alla kunder och processstandarder i SESC-samlingen. IEEE/EIA 12207 är ett antagande av en ISO/IEC-standard från 1995 med samma namn och nummer. Den internationella standarden etablerar en gemensam ram för programvara under hela dess livscykel från befruktning till pension, och den tar upp den organisatoriska kontexten för dessa programvaruprocesser både ur systemets tekniska synvinkel och ur företagets affärssynvinkel. Standarden anses allmänt utgöra en grund för världshandeln med programvarutjänster. Antagandet av standarden slutförs eller pågår i de flesta av världens största länder. ISO/IEC 12207-standarden förbättrades jämfört med tidigare standarder inom liknande områden. Viktigast av allt är att det definieras på processen snarare än på förfarandenivå. I stället för att ange de steg-för-steg-krav som kännetecknar ett förfarande beskriver man det fortsatta ansvar som måste uppnås och upprätthållas under processens gång. Standarden tar upp de funktioner som ska utföras snarare än de organisationer som kommer att utföra dem. (Till exempel, standarden beskriver en kvalitetssäkringsprocess; detta innebär inte att ett överensstämmande företag måste es- Gäller FIGURE 2. Föremålen för programvaruteknik, föreslår en kategorisering av standarder inom ämnesområdena kund, process, produkt, och resurs. upprätta en kvalitetssäkringsavdelning.) Standarden beskriver programvaruutveckling, underhåll och drift inom ramen för systemet och fastställer därmed effektivt det minimisystemkontext som är nödvändigt för programvaruprocesser. Tre kategorier beskriver ISO/IEC 12207-processerna: ♦ Primära processer utförs av parter som initierar eller utför viktiga roller i programvarans livscykel. De omfattar både affärsverksamhet (förvärv och leverans) och tekniska roller (utveckling, drift och underhåll). ♦ Stödprocesser bidrar till genomförandet av andra processer som en integrerad del med tydliga mål. De omfattar dokumentation, konfigurationshantering, kvalitetssäkring, verifiering, validering, gemensam granskning, revision och problemlösning. ♦ Organisatoriska processer existerar till sin natur utanför det enskilda projektets räckvidd, men projektet använder sig av dem. De omfattar förvaltning, infrastruktur, förbättring och utbildning. IEEE/EIA 12207.0 lägger till ett förord och vissa bilagor till texten i den internationella standarden. Två andra vägledningsdelar lades till i standarden: IEEE/EIA 12207.1 ger vägledning om de data som produceras genom livscykelprocesserna och korshänvisas till bestämmelserna i 12207.0 och IEEE/EIA 12207.2 ger vägledning om genomförandeprocesser genom att citera den fullständiga texten 12207.0 och tvärgående vägledande anmärkningar. 12207.1 beskriver uppgifter men inte dokument. Den beskriver 84 olika informationsobjekt, som användaren väljer och paket i dokument som är lämpliga för projektet. Fyrtio av uppgifterna har specifika krav på innehåll (men inte format), medan de övriga 44 uppgifterna klassificeras som en av sju olika typer av data som har allmänna innehållskrav. En 12207.1 användare kan använda den som vägledning, vilket innebär att den antas helt enkelt ge goda råd. Å andra sidan innehåller 12207.1 också frivilliga bestämmelser om överensstämmelse som gör det möjligt för användarna att åberopa standarden om de vill göra starka påståenden om arten av de uppgifter som deras processer producerar. Användaren kan hävda att ett eller flera dokument överensstämmer med 12207.1 genom att tillhandahålla en kartläggning från dokumenten till de valda informationsobjekten. Kartläggningen ska visa att dokumentet uppfyller allmänna och specifika innehållskrav, fångar upp de uppgifter som krävs enligt de korsrefererade bestämmelserna 12207.0 och uppfyller vissa allmänna krav för behandling av uppgifter. 12207.1 innehåller också hänvisningar till andra IEEE-standarder som kan vara till hjälp vid tillämpningen av bestämmelserna om uppgifter. Till exempel kan en användare välja att anta IEEE Std. 1016, Beskrivningar av programvarudesign, för att närmare ange de databestämmelser som avser informationsobjektet för beskrivningen av programvaruobjektet. I den andra riktningen har SESC kompletterat var och en av de ovannämnda IEEE-standarderna med en innehållskarta som beskriver i vilken utsträckning standarden uppfyller uppgiftskraven i 12207.1. Inom de närmaste åren kommer SESC att se över innehållet i varje standard så att den direkt genomför de relevanta bestämmelserna i 12207.1. IEEE/EIA 12207 spelar också en viktig roll i principskiktet i SESC-arkitekturen. Antagandet av IEEE/EIA 12207 kompletterade var och en av de 17 processerna med en beskrivning av målen. I ovanliga fall, där de mer detaljerade 12207 kraven är olämpliga för adoption, kan en organisation istället välja att anta processerna på målnivå. På det hela taget har vi antagit en politik som utnämner 12207 som en strategisk och integrerande standard för insamlingen. Alla relevanta standarder i SESC-samlingen kommer att ses över för att förbättra deras överensstämmelse med 12207; i synnerhet kommer många av dem att beskriva processerna i 12207-ramen. Ur användarens synvinkel kommer IEEE/EIA 12207 att fungera som en enda ingångspunkt till alla processstandarder för IEEE:s programvarutekniksamling. Vi använder också IEEE/EIA 12207 som utgångspunkt för att formulera nya processer. Till exempel IEEE Std. 1517, Software Reuse Processes, lägger till tre återanvändningsspecifika processer till dem av 12207, och den planerade IEEE 1540 standard (fortfarande under utveckling) kommer att lägga till en programvara riskhantering process. Alla SESC-standarder är tillgängliga för enskilda inköp från IEEE (http://standards. I E E S o f t w a r e Standarden behandlar de funktioner som ska utföras snarare än de organisationer som kommer att utföra dem. Detta anslag är avsett att täcka utgifter för tjänstemän och tillfälligt anställda som arbetar inom politikområdet Sysselsättning, socialpolitik och lika möjligheter för kvinnor och män i enlighet med bestämmelserna i Europaparlamentets och rådets förordning (EU, Euratom) nr 966/2012 av den 25 oktober 2012 om finansiella regler för unionens allmänna budget och om upphävande av rådets förordning (EG, Euratom) nr 1605/2002 (EUT L 298, 26.10.2012, s. 1). Vartannat år har vi samlat våra standarder och tillsammans publicerat dem i en volym som liknar en större stads telefonkatalog. När det totala antalet sidor närmar sig 2.400 behövde 1999 års upplaga ett nytt tillvägagångssätt. De fyra objekten i Vision 2000 arkitektur föreslog en fyra-volym förpackningar, med varje volym som innehåller standarder avseende kund, produkt, process, eller resurs. Vi buntade ihop standarderna från terminologiskiktet till kundvolymen och standarderna från teknikskiktet till resursvolymen. Vi gjorde guiden till samlingen tillgänglig till ett rabatterat pris när den köptes med fyrvolymsutgåvan. Vi utelämnade också från utgåvan några stora standarder avsedda för specifika målgrupper, vilket gör dem tillgängliga för köp separat. Naturligtvis var det inte praktiskt att publicera flera kopior av standarder som legitimt passar in i mer än en kategori. Därför var det nödvändigt att tvinga varje standard till en enda kategori för publiceringsändamål. Vår motivering till dessa beslut förklaras nedan. Eftersom IEEE/EIA 12207 är paraplystandarden för både process- och kundinteraktion, var dess placering ett av de svåraste besluten vid utformningen av utgåvan. Vi bestämde oss för att placera alla tre delarna av standarden i kundvolymen så att volymen skulle vara fristående ur program förvärvarens synvinkel. De som önskar en mer detaljerad standard för programvaruförvärv kan också hitta IEEE Std. 1062 i denna volym. Ett annat viktigt beslut var att behandla systemingenjörer som en del av kundens uppsättning för programvaruteknik. Säkerligen, IEEE/EIA 12207 har denna åsikt när det behandlar programvarukrav som härrör från en viktig systemkontext. Så, alla standarder som involverar systemet sammanhang av mjukvaruutveckling är i denna volym: ♦ IEEE Std. 1220, Process för systemteknik, ♦ IEEE Std. 1228, Programvarusäkerhetsplaner, ♦ IEEE Std. 1233, specifikation av systemkrav och ♦ IEEE Std. 1362, Begreppet verksamhet. För att komplettera sin fristående karaktär, innehåller denna volym ordförrådsstandard från terminologiskiktet i samlingen, IEEE Std. Detta beslut träder i kraft den tjugonde dagen efter det att det har offentliggjorts i Europeiska unionens officiella tidning. Även om vi placerade IEEE/EIA 12207 i utgåvans kundvolym, placerade vi en annan viktig paraplyprocessstandard i processvolymen; IEEE Std. 1074 vänder sig till processarkitekten och tillhandahåller byggstenar för konstruktionsprocesser som uppfyller kraven i 12207 eller andra standarder. Du hittar standarder i denna volym som ger ytterligare detaljer om många av de tekniska processer och aktiviteter 12207: ♦ Generellt sett hittar du standarder relaterade till systemtekniska processer på annat håll-många av dem i kundvolymen. IEEE Std. 830 gällande kravspecifikationer för programvara finns i resursvolymen. Vissa utvecklare, särskilt de i försvarsgemenskapen, kan vara intresserade av att använda EIA/IEEE JStd-016 för att vägleda sin programvaruutvecklingsprocess. Vi beslutade att utelämna denna standard från fyrvolymsutgåvan av flera skäl: den håller för närvarande på att revideras; den är redan fristående och användarna behöver inte det andra materialet från denna volym; och den är stor och skulle ha ökat volymens pris betydligt. EIA/IEEE J-Std-016 kan köpas separat från antingen IEEE eller EIA. Trenden inom programvaruteknik under de senaste 15 åren har varit att fokusera på att utvärdera och förbättra processer. Vi får dock inte glömma att syftet med alla tekniska insatser är att skapa en produkt. Denna volym innehåller standarder som är användbara för produktutvärdering av programvara. Tyvärr, till skillnad från kunden och processvolymer, finns det ingen standard som tillhandahåller principer för att fungera som ett enande paraply för de andra. Den närmaste kandidaten skulle vara IEEE Std. 1061, som ger en metodik för kvalitetsmått för programvara. IEEE Std. 982.1 är en lexikon över mått som kan användas för att mäta programvarans tillförlitlighet och relaterade egenskaper. IEEE Std. 1465 är en tillämpning av ISO/IEC 12119 och ger kvalitetskrav för programvarupaket-det vill säga färdigförpackade programvaruprodukter. Eftersom användardokumentation är en viktig komponent i en programvaruprodukt, IEEE Std. 1063 ingår i denna volym, även om andra dokumentationsstandarder förekommer på annat håll. Alla standarder som fokuserar på processerna för att säkerställa produktkvaliteten visas på annat håll i utgåvan. Termen resurs är avsiktligt bred, omfattar allt som kan användas eller konsumeras när man utför en programvaruprocess eller skapar en programvaruprodukt. Följaktligen har vi inkluderat en mängd olika standarder i denna volym. Det är därför kanske inte förvånande att det inte finns någon paraplystandard för att tillhandahålla allmänna principer på detta område. Denna volym innehåller den så kallade "IDEF"notational standards-("Integrerad definition,"ett modellering språk, kombinerar grafik och text, används för att analysera och definiera systemfunktioner och krav). Integreringsnivån bland IEEEs standarder för programvaruteknik är ännu inte perfekt. Eftersom varje enskild standard revideras, på en cykel på ungefär fem år, kommer den att ändras för att passa bättre med IEEE/EIA 12207 och med de andra standarderna i samlingen. Naturligtvis fortsätter IEEE-kollektionen att växa i takt med att ytterligare ämnen behandlas. Vi samarbetar också med en lämplig internationell standardiseringskommitté för att uppmuntra utvecklingen av ISO/IEC 12207 i en riktning som överensstämmer med behoven hos SESC:s användare. N o v e m e r / D e c e m b e r 1 9 9 9 I E E S o f t t w a r 5 7
Föremålen för programvaruteknik, föreslår en kategorisering av standarder inom ämnesområdena kund, process, produkt, och resurs REF.
An integrated collection of software engineering standards
{'venue': 'IEEE Software', 'journal': 'IEEE Software', 'mag_field_of_study': ['Computer Science']}