Teknisk dokumentation. Teknisk dokumentation Genomföra acceptansprov

Anteckning: En logisk fortsättning på föregående föreläsning. Problemet med praktisk tillämpning av GOST R ISO/IEC 12207 i organisationer och projekt diskuteras i detalj. I detta avseende studeras standarderna GOST R ISO/IEC 15271 och GOST R ISO/IEC 16326.

Från föregående föreläsning borde det vara uppenbart att implementering av GOST R ISO/IEC 12207 är en mycket svår uppgift. Först och främst är det inte klart vad det innebär att "implementera GOST R ISO/IEC 12207"? Kan det anses implementerat om några av organisationens processer sammanfaller med processerna i standarden, och andra inte? Kan en standard anses implementerad om vissa projekt genomförs i enlighet med den, och andra inte gör det? Den här listan med frågor kan fortsätta och fortsätta.

Det är ingen slump att efter GOST R ISO/IEC 12207 utvecklades standarden GOST R ISO/IEC 15271-02 (GOST 15271, 2002) specifikt för uppgiften att implementera den, som kallas "Riktlinjer för tillämpningen av GOST R ISO/IEC 12207”. Vi kommer nu att överväga det.

Standard GOST R ISO/IEC 15271

Innebörden av standarden avslöjas i dess inledande avsnitt.

"1.2. Användare av standarden.

Denna standard kan användas av personer (individer, organisationer) som vill tillämpa GOST R ISO/IEC 12207 vid implementering av kontrakt, oavsett projektets volym eller komplexitet, av en specifik organisation för egenkontroll eller förbättringsarbete livscykelprocesser mjukvaruverktyg.

Denna standard specificerar hur GOST R ISO/IEC 12207 kan användas i förhållande till olika typer av programvara och vilka processer som är lämpliga för varje fall.

Denna standard kompletterar GOST R ISO/IEC 12207, som inte bara är ett normativt dokument, utan också en standard för att hantera ett riktigt projekt. (Till exempel inträffar det sista fallet när GOST R ISO/IEC 12207 är en modell för att utföra en del av arbetet med förbättringsprocessen). Denna standard bör läsas som en helhet, men specifika avsnitt kan användas i enskilda fall."

GOST R ISO/IEC 15271-standarden består av 8 sektioner och 4 bilagor. Innehållssektionerna kallas enligt följande (numrering hämtad från texten):

• 4. Grundläggande koncept för utveckling av GOST R ISO/IEC 12207.
• 5. Implementering av GOST R ISO/IEC 12207.
• 6. Tillämpning i projekt.
• 7. Tillämpning i organisationer.
• 8. Ansökan livscykelmodeller system.

Avsnitt 4 är skrivet i stil med kommentarer och förtydliganden till texten i GOST R ISO/IEC 12207. De viktigaste förtydligandena gäller interaktionen av GOST R ISO/IEC 12207 med företagsstandarder i organisationen, distinktionen mellan begreppen " mjukvara” och ”system” och de resulterande distinktionerna mellan processer relaterade till programvara och system. Konceptet beskrivs i detalj kvalitetshantering, implementerad i GOST R ISO/IEC 12207. Generellt ger avsnittet intryck av en kort konceptuell översikt av GOST R ISO/IEC 12207, som påminner om en lärobok.

Avsnitt 5 presenterar ett allmänt tillvägagångssätt för implementering, kallat GOST R ISO/IEC 12207-implementeringsstrategin. En strategi, enligt standarden, är "en typisk implementeringsmetod som bör följas när man gör ändringar i en organisations aktiviteter eller projekt." Strategin genomförs som ett projekt bestående av obligatoriska steg, beskrivna informellt och utan koppling till organisationens processer. Dessa steg är följande:

• a) utveckling av en genomförandeplan;
• b) praktisk tillämpning av GOST R ISO/IEC 12207;
• c) ge stöd pilotprojekt(s);
• d) formalisering av genomförandemetoden;
• e) godkännande av implementeringsmetoden.

Utveckling av en implementeringsplan innefattar att fastställa tillämpningsområdet för GOST R ISO/IEC 12207. Omfattningen kan till exempel vara en grupp av avdelningar eller projekt i en organisation. Du kan också definiera tillämpningsområdet som en uppsättning nyckelprocesser för organisationen, som kommer att ersättas av processer från GOST R ISO/IEC 12207. Implementeringsplanen i sig bestämmer sammansättningen av de projekt som genomförs under genomförandet (det kan finnas flera av dem). Det säger sig självt att när man utvecklar en implementeringsplan bestäms de nödvändiga resurserna: ekonomiska, mänskliga, tekniska, etc.

I praktisk tillämpning, som man kan förvänta sig, föreslås det att använda anpassningsprocessen som beskrivs i själva GOST R ISO/IEC 12207.

Strategin i sig väcker inga frågor - en sådan sekvens av steg kan vara ganska effektiv under specifika förhållanden, men det är värt att notera att den formella projektmetoden för implementeringen av GOST R ISO/IEC 12207 bygger på en förenklad förståelse av den verkliga situation. Med hänsyn till att en organisations processer (liksom dess organisationsstruktur) ständigt förändras, anser jag att det metodologiskt vore mer korrekt att betrakta implementeringen av en standard som en pågående process, snarare än som ett tidsbegränsat projekt. Denna process övervakar förändringar i organisationens processer och initierar enskilda projekt, till exempel:

• projekt för tillämpning av GOST R ISO/IEC 12207;
• ett projekt för att utbilda alla nya anställda i processerna enligt GOST R ISO/IEC 12207;
• ett projekt för att införa förändringar i genomförda processer i samband med förändringar i organisationens organisationsstruktur; och så vidare.

Tillvägagångssättet för implementering av GOST R ISO/IEC 12207 som en process, särskilt om det är avsett att börja med dess tillämpning i projekt eller enskilda avdelningar i organisationen, kommer att tillåta att koncentrera ansvaret för det övergripande resultatet i händerna på processägaren , kommer att göra det möjligt att etablera generell resultatuppföljning etc. Självklart bör genomförandet följas av stöd till de genomförda processerna, vilket också naturligt är organiserat som en process.

Mer information om användningen av GOST R ISO/IEC 12207 i projekt beskrivs i avsnitt 6 "Tillämpning i projekt". Standarden föreslår att klassificera projekt och för detta ändamål introducerar ett nytt koncept - " livscykelmodell system" (en lista över typiska modeller ges i bilaga C). Vad en modell är definieras inte formellt. Senare anges i avsnitt 8 att "den allmänna livscykelmodell system är indelade i stadier (stadier) med efterföljande anpassning av var och en av dem till livscykelmodeller specifikt system" (följande är en lista över steg). Totalt övervägs tre sådana modeller: kaskad, inkrementell, evolutionär. Deras fördelar och nackdelar analyseras, och sedan "överlagras" processerna i GOST R ISO/IEC 12207. om modellernas uppbyggnad Som ett resultat av detta får dessa processer ytterligare egenskaper, till exempel upprepad upprepning i livscykeln eller tidsöverlappning med andra processer. Dessutom innehåller avsnittet en mängd rekommendationer av varierande grad av användbarhet aspekter av projekt Här är ett typiskt exempel.

"6.1.3. Systemegenskaper

Delsystemen och systemkonfigurationselementen måste definieras på lämplig detaljnivå. Det är nödvändigt att bestämma systemets egenskaper, särskilt de som är relaterade till programvaran. När man bestämmer dessa egenskaper är det nödvändigt att notera vilka av dem som är kritiska under driften av systemet.

En vägledande lista över egenskaper på systemnivå (relaterade till programvaran och föremål för övervägande) inkluderar:

• inter-system och intra-system gränssnitt;
• användargränssnitt;
• inverkan av programvarufel på skyddet och systemsäkerhet;
• bedömning av datorkraft och tidsbegränsningar;
• Tillgänglighet för program som genomförs med tekniska medel;
• Tillgång till lämpliga datorer.

Om ett system innehåller många delsystem eller konfigurationsobjekt måste de helt täckas av arbete på systemnivå från utvecklingsprocessen. Alla krav på gränssnitt och montering (integration) av system måste beaktas. För ett litet system kanske en så strikt sekvens av åtgärder inte är nödvändig."

Den ungefärliga och vaga formuleringen i ovanstående stycke är karakteristisk för hela standarden som helhet.

Den centrala delen av det mycket korta avsnittet 7 ”Tillämpning i organisationer” är följande text.

"7.2. Användningsmöjligheter

Anledningarna till att GOST R ISO/IEC 12207 implementeras i organisationer kan vara följande:

• kontrollera perfektion av en befintlig metod. Detta är vanligtvis fallet när metoden utvecklades av organisationen själv eller den valde och modifierade en befintlig metod;
• praktisk tillämpning av denna metod för att förhindra risker förknippade med inträde på nya marknadssektorer med strängare krav förknippade med potentiell risk;
• utveckla en ny metod, till exempel för att möta behoven i en ny organisation. Organisationer som skapats genom en sammanslagning eller affärssamarbete kan omfattas. Detta kan vara nödvändigt för att stödja vissa processmodeller för att tillhandahålla specifikt arbete;
• Hantera implementeringen av ny teknik, såsom att automatisera manuella processer eller ändra metoderna som används för att implementera en mjukvaruprodukt. GOST R ISO/IEC 12207 fastställer kriterier som kan användas för att övervaka förträffligheten hos den relevanta metoden före eller efter en förändring av tekniken;
• bedömning av partens interna kapacitet när det gäller att uppfylla kontraktskriterierna, till exempel som en part som deltar i den konkurrensutsatta (anbuds)processen;
• identifiera milstolpar som kan leda till utveckling av mer avancerade program, såsom revision i enlighet med GOST R ISO/IEC 12207 och att använda själva förbättringsprocessen."

Även i den totala avsaknaden av materiella invändningar är det fortfarande omöjligt att betrakta denna text som en standard. Mest av allt påminner den om en utbildningsmanual och kommer troligen att efterfrågas som sådan, men en sådan text kan inte användas som en vägledning till handling vid implementering av GOST R ISO/IEC 12207 i en organisation.

Slutligen avsnitt 8 "Ansökan livscykelmodeller system" innehåller ganska vaga definitioner" livscykelmodeller system" och " livscykelmodeller programvara" och försöker upprätta en överensstämmelse mellan dem. Eftersom det inte finns några exakta definitioner är det omöjligt att bedöma resultaten.

Generellt sett ger GOST R ISO/IEC 15271-standarden intrycket av att vara ett rent hjälpdokument i förhållande till GOST R ISO/IEC 12207, som lider av ungefärlighet och ett överflöd av vardagsmat. Det är olämpligt för praktiska chefer – det finns för mycket abstrakta resonemang och för lite specificitet. För studenter och specialister som studerar IT-hanteringsprocesser saknar den en bred syn på ämnet (det är trots allt begränsat av GOST R ISO/IEC 12207) och är överbelastad med onödiga tekniska detaljer. Ändå är förtrogenhet med GOST R ISO/IEC 15271 användbar, eftersom den visar tankeriktningen hos specialister inom IT-hanteringsområdet och visar var och hur moderna standarder utvecklas. Jag skulle se det som ett interimistiskt arbetsdokument, om än i form av en standard, men mer avsett för diskussion bland en intresserad publik av IT-ledningsspecialister.

Standard GOST R ISO/IEC 16326

Ett annat försök att formalisera processen för att tillämpa GOST R ISO/IEC 12207 gjordes i GOST R ISO/IEC 16326-standarden "Guidelines for the use of GOST R ISO/IEC 12207 in project management" (GOST 16326, 2002). Det visar ett försök att enas livscykelprocesser från GOST R ISO/IEC 12207 med projektledningsprocesser från den populära metodologiska referensboken PMBOK 1 PMBOK - Project Management Body of Knowledge(PMBOK, 2009) och ISO 10006-standarden (den ryska versionen av standarden finns i (GOST 10006, 2005)). Detta visas schematiskt i fig. 4.1 anges i standarden.

Ris. 4.1.

Utbudet av användare av standarden är ganska exakt definierat i avsnitt 1.1.

"1.1. Omfattning av användare

Denna standard är avsedd för enheter som använder eller planerar att använda GOST R ISO/IEC 12207 i programvaruprojekt, oavsett deras omfattning, skapade produkter, metodik, volym eller komplexitet. Standarden är i första hand avsedd för projektadministratörer som ansvarar för efterlevnad av ledningsprocesser med GOST R ISO/IEC 12207:

• administratörer med ansvar för organisation och ständiga förbättringar livscykelprocesser programvara enligt GOST R ISO/IEC 12207;
• administratörer som ansvarar för ansökan livscykelprocesser programvara enligt GOST R ISO/IEC/12207 på designnivå;
• organisationer eller personer som är underleverantörer i implementeringen av SCP ( Programvaruprojektledning. - AB).

Överväganden för individer inkluderar:

• involverad i mjukvaruprojekt, men inte AP ( Projektadministratörer. - AB);
• som är administratörer för icke-mjukvaruprojekt, men associerade med AP-programvara."

Den relativt korta huvudtexten (avsnitt 6 "Guide" tar bara upp 9 sidor av totalt 35) är en sekventiell kommentar till process 7.1 "Management" från GOST R ISO/IEC 12207 ur PMBOK-synpunkt. Kommentarstilen är informell, argumenten är mestadels av rådgivande karaktär. Kommentaren går inte längre än vanligt sunt förnuft och innehåller inget nytt. I allmänhet är detta användbar läsning för chefer (i terminologin för översättare - "administratörer") av projekt, men inget mer.

Bilaga A är en stor tabell som visar sambanden mellan huvudprocesserna i GOST R ISO/IEC 12207 och aktiviteterna i "Management"-processen som kallas från dem. Alla dessa länkar finns i huvuddelen av GOST R ISO/IEC 12207-standarden; att kombinera dem till en tabell lägger inte till någon ny information.

Bilaga B är exakt samma tabell som länkar processområden och individuella processer från PMBOK med aktiviteterna i "Management"-processen från GOST R ISO/IEC 12207.

En liknande tabell, där processgrupper i PMBOK-bemärkelse används istället för områden, ges i bilaga C. Bilagorna B och C sammanfattar egentligen allt som sades i standardens avsnitt 6. Varför det var nödvändigt att presentera detta i form av tabeller är oklart. Dessa tabeller ger ingen ytterligare information, och visar bara det faktum att det finns kopplingar mellan PMBOK och GOST R ISO/IEC 12207. Statusen för båda bilagorna är dock "referens", så de kanske inte har haft något oberoende värde.

En annan sammanfattande tabell presenteras i bilaga D. Den visar sambanden mellan tre källor: GOST R ISO/IEC 12207, PMBOK och ISO 10006-standarden. Jag kommer omedelbart att notera att den senare översattes till ryska först 2005; som en följd av detta skiljer sig den terminologi som används i bilaga D till GOST R ISO/IEC 16326 2002-standarden från den senare. Liksom i tidigare fall är innebörden av att presentera dessa samband i kompakt tabellform oklar. Dessutom överstiger den totala volymen av Bilagorna A-D volymen i huvudavsnitt 6 "Manual" med mer än två gånger.

Enligt min åsikt är GOST R ISO/IEC 16326-2002 inte annorlunda i form och syfte från GOST R ISO/IEC 15271-2002. Båda lider av ett överflöd av resonemang som är korrekta "i allmänhet" och enbart baserat på sunt förnuft. Dessa argument är uppenbara för alla som har praktisk erfarenhet av projektledning, och verkar knappast rimliga för dem som inte har sådan erfarenhet. Till skillnad från GOST R ISO/IEC 15271-2002 är GOST R ISO/IEC 16326-2002-standarden mer formell, men den praktiska innebörden av den föreslagna formalismen är inte klar.

Ur praktisk tillämpning i utformningen av IT-relaterade affärsprocesser är båda standarderna i stort sett värdelösa. Å andra sidan kan de vara efterfrågade när man implementerar komplexa projekt som inkluderar, tillsammans med en studie av IT-förvaltningspraxis, analys av projektledning och kvalitetshantering.

Utöver de som diskuterats ovan har GOST R ISO/IEC 12207 gett upphov till ett antal standarder som beskriver de som finns i den livscykelprocesser. Dessa inkluderar till exempel GOST R ISO/IEC 15910-2002 "Processen att skapa användardokumentation för programvara" (GOST 15910, 2002) och GOST R ISO/IEC 14764-2002 "Underhåll av programvara" (GOST 14764, 2002) . Vissa liknande ISO-standarder har ännu inte översatts till ryska; Det är troligt att antalet ryskspråkiga GOST R ISO-standarder som är direkt relaterade till GOST R ISO/IEC 12207 kommer att öka i framtiden.

Baslinje enligt GOST R ISO/IEC 12207-2010

eller, som formellt har granskats och därefter fungerar som grund för vidareutveckling, och som endast kan ändras genom officiella och kontrollerade ändringar [från klausul 4.6 i GOST R ISO/IEC 12207-2010]

Validering enligt GOST R ISO/IEC 12207-2010

Bekräftelse (baserat på uppvisande av objektiva bevis) på att det avsedda syftet eller tillämpningen har genomförts. Notera - Validering i sammanhang är en uppsättning åtgärder som garanterar och ger förtroende för att den kan förverkliga sitt syfte, nuvarande och framtida [från klausul 4.54 i GOST R ISO/IEC 12207-2010]

Verifiering enligt GOST R ISO/IEC 12207-2010

Bekräftelse (baserat på tillhandahållande av objektiva bevis) på att de angivna kraven har uppfyllts fullt ut. OBS Verifiering i sammanhang är en uppsättning åtgärder som jämför ett livscykelresultat med de egenskaper som krävs för det resultatet. Resultaten av livscykeln kan vara (men är inte begränsade till) specificerade krav, beskrivning och direkt [från klausul 4.55 i GOST R ISO/IEC 12207-2010]

Kvalitetssäkring enligt GOST R ISO/IEC 12207-2010

Alla planerade och systematiska aktiviteter som utförs inom ramen och demonstreras på ett lämpligt sätt för att ge tillräckligt förtroende för att kunden är helt nöjd.

1. Det finns både interna och externa kvalitetsgarantier:
   1. intern kvalitetssäkring: inom gränserna för kvalitetssäkring ger förtroende;
   2. Extern kvalitetssäkring: I avtalssituationer ger kvalitetssäkring förtroende eller till andra.
2. Vissa kvalitetssäkrings- och kvalitetssäkringsaktiviteter är relaterade till varandra.
3. Om inte kvalitetskraven helt uppfyller behoven kan kvalitetssäkring inte ge den nödvändiga säkerheten.

[från klausul 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Sammanfattning av livscykelprocesser

Det finns två viktiga processindelningar i denna standard. Avsnitt 6 tillhandahåller systemkontexten för att driva en fristående programvaruprodukt eller -tjänst, eller programvarusystem. Avsnitt 7 innehåller specifika programvaruprocesser för användning vid implementering av en mjukvaruprodukt eller tjänst som är någon del av ett större system.

För att underlätta den samtidiga användningen av denna internationella standard ges motsvarande processer i klausul 6 samma underklausulbeteckningar.

I allmänhet är uppsättningen av processer som presenteras i denna standard skräddarsydd för programvaran eller indata till resultaten av de processer som tillhandahålls. Många processer liknar programvaruspecifika processimplementationer, men de behåller viktiga skillnader baserat på mål, resultat och målgrupper. Användare av både denna standard och denna standard bör se till att granska förklaringarna och anteckningarna i varje sådan specifik process.

Avtalsprocesser definierar de aktiviteter som krävs för att utveckla avtal mellan två organisationer. Om en förvärvsprocess implementeras ger den möjlighet att göra affärer med leverantören av de produkter som tillhandahålls för användning i operativsystemet, systemstödtjänster eller systemelement som utvecklats som en del av projektet. Om en leveransprocess implementeras ger den möjlighet att genomföra ett projekt där resultatet är en produkt eller tjänst som levereras till den förvärvande parten.

Avtalsprocesserna i denna standard är alltså inriktade på programvaruavtalsprocesser från .

Organisatoriska projektstödsprocesser hanterar organisationers förmåga att förvärva och leverera produkter eller tjänster genom projektinitiering, support och ledning. Dessa processer tillhandahåller de resurser och infrastruktur som behövs för att stödja projekt och säkerställa att organisatoriska mål och etablerade avtal uppfylls. De gör inte anspråk på att vara en komplett uppsättning affärsprocesser som implementerar hanteringen av en organisations affärsaktiviteter.

Projektorganisatoriska stödprocesser inkluderar:

a) Process för hantering av livscykelmodeller;

B) infrastrukturhanteringsprocess;

c) Process för projektportföljförvaltning;

d) hantering av mänskliga resurser.

e) kvalitetsledningsprocess.

I allmänhet är de projektorganisationsstödprocesser som tillhandahålls av denna standard processer fokuserade på programvara från motsvarande uppsättning processer i .

I denna standard är projektet valt som underlag för att beskriva processerna kring planering, utvärdering och kontroll. Principerna förknippade med dessa processer kan tillämpas på alla områden av organisationsledning.

Det finns två kategorier av projektprocesser. Projektledningsprocesser används för att planera, utföra, utvärdera och hantera ett projekts framsteg. Projektstödsprocesser säkerställer att specialiserade ledningsmål uppfylls. Båda kategorierna av projektprocesser beskrivs nedan.

Projektledningsprocesser används för att skapa och utveckla projektplaner, utvärdera faktiska framsteg och framsteg mot planer och hantera projektframsteg fram till slutförande. Individuella projektledningsprocesser kan anropas när som helst i livscykeln och på vilken nivå som helst i projekthierarkin som svar på projektplaner eller inträffande av oförutsedda händelser. Projektledningsprocesser tillämpas på en nivå av rigoritet och formalisering beroende på risken och komplexiteten i projektet:

a) projektplaneringsprocess;

b) projektledning och utvärderingsprocessen.

Projektstödsprocesser utgör en specifik uppsättning uppgifter som syftar till att uppnå specifika ledningsmål. Alla dessa processer är uppenbara i hanteringen av varje initierad aktivitet, nedstigande från organisationen som helhet ner till en separat livscykelprocess och dess uppgifter:

a) Beslutshanteringsprocess;

b) Riskhanteringsprocess;

c) konfigurationshanteringsprocess;

d) Process för informationshantering;

e) mätprocess.

I allmänhet är de projektstödsprocesser som presenteras i denna standard identiska med de projektstödsprocesser som anges i , med undantag för vissa skillnader i form av deras presentation. I vissa fall kan programvarustödsprocesser ha relationer med projektstödsprocesser.

Tekniska processer används för att definiera systemkrav, omvandla kraven till en användbar produkt, tillåta fortlöpande kopiering av produkten (vid behov), applicera produkten, tillhandahålla de tjänster som krävs, upprätthålla tillhandahållandet av dessa tjänster och ta bort produkten från cirkulation när den används inte för att tillhandahålla tjänsten.

Tekniska processer definierar de aktiviteter som gör det möjligt att implementera organisations- och designfunktioner för att optimera fördelarna och minska riskerna till följd av tekniska beslut och åtgärder. Dessa aktiviteter gör det möjligt för produkter och tjänster att ha egenskaperna aktualitet och tillgänglighet, kostnadseffektivitet, funktionalitet, tillförlitlighet, underhållbarhet, produktivitet, anpassningsförmåga och andra kvalitetsegenskaper som krävs av förvärvande och stödjande organisationer. Det gör det också möjligt för produkter och tjänster att uppfylla civilrättsliga förväntningar eller krav, inklusive hälsa, säkerhet, säkerhet och miljöfaktorer.

Tekniska processer består av följande processer:

a) fastställande av rättighetsinnehavarnas krav (ett specialfall av processen för att fastställa rättighetsinnehavarnas krav som anges i);

b) Systemkravsanalys (ett specialfall av kravanalysprocessen).

C) systemarkitekturdesign (ett specialfall av arkitekturdesignprocessen som anges i);

D) implementeringsprocess (ett specialfall av systesom ges i och vidareutvecklas i avsnitt 7 i denna standard som);

e) Systemintegrationsprocess (ett specialfall av integrationsprocessen som anges i);

f) System(en process som bidrar till att uppnå resultaten av verifieringsprocessen som anges i ).

G) installationsprocessen för programvaran (den process som bidrar till att uppnå resultaten av överföringsprocessen som beskrivs i);

H) stödprocess för programvaruacceptans (processen som bidrar till att uppnå resultaten av överföringsprocessen som beskrivs i );

i) programvarans driftprocess (ett specialfall av driftprocessen som anges i);

j) Programvaruunderhållsprocess (ett specialfall av underhållsprocessen som anges i );

k) Processen för återtagande av programvara från cirkulation (ett specialfall av processen för återkallande och avskrivning som anges).

I allmänhet är de tekniska processer som presenteras i denna standard programvaruorienterade specialfall eller bidrag till resultaten av de tekniska processer som presenteras i . De flesta av dem liknarser, men behåller viktiga skillnader, till exempel systemkravsanalys och programvarukravsanalys utgår från olika utgångspunkter och har olika syften.

Mjukvaruimplementeringsprocesser används för att skapa ett specifikt systemelement (komponent) gjort i form av ett mjukvaruverktyg. Dessa processer omvandlar specificerade beteenden, gränssnitt och implementeringsbegränsningar till åtgärder som resulterar i ett systemelement som uppfyller de krav som härleds från systemkraven.

En speciell process är processen att implementera programvara, vilket uttrycker en specifikt mjukvarufunktion i implementeringsprocessen som anges i.

Programimplementeringsprocessen inkluderar flera speciella processer på lägre nivå:

a) processen för att analysera programvarukrav;

B) designprocess för mjukvaruarkitektur;

c) den detaljerade mjukvarudesignprocessen;

d) mjukvarudesignprocess;

e) process för mjukvaruintegrering;

f) process för testning av programvarakvalifikationer.

Programvarustödsprocesser tillhandahåller en specifikt fokuserad uppsättning aktiviteter som syftar till att utföra en specialiserad mjukvaruprocess. Alla stödjande processer hjälper processen att implementera programvara som helhet med ett distinkt syfte, vilket bidrar till framgången och kvaliteten på mjukvaruprojektet. Det finns åtta sådana processer:

a) hanteringsprocess för mjukvarudokumentation;

b) hanteringsprocess för mjukvarukonfiguration;

c) Process för kvalitetssäkring av programvara;

d) mjukvaruverifieringsprocess;

e) process för mjukvaruvalidering;

f) revisionsprocess för programvara;

g) revisionsprocess för programvara;

H) processen att lösa problem i programvara.

Processgruppen för återanvändning av programvara består av tre processer som stödjer en organisations förmåga att återanvända komponenter av programvara över projektgränser. Dessa processer är unika eftersom de till sin natur används utanför gränserna för ett specifikt projekt.

Processer för återanvändning av programvara är:

a) domändesignprocess;

b) process för hantering av återanvändning av tillgångar;

C) processen för att hantera programåteranvändning.

1) Låter dig implementera vilken livscykelmodell som helst- detta är möjligt, eftersom Standarden ger ett sätt att definiera ordningen för utförande av processer och uppgifter, där en process kan anropa en annan process eller delar av den.

2) Ger maximal flexibilitet– många processer och uppgifter är utformade på ett sådant sätt att de kan anpassas efter specifika IS-projekt. Anpassning handlar om att eliminera processer, aktiviteter och uppgifter som inte är tillämpliga på ett specifikt projekt.

3) Standarden innehåller i grunden ingen beskrivning av specifika handlingsmetoder, speciellt blanks, lösningar eller dokumentation, den beskriver bara arkitekturen för mjukvarans livscykelprocesser, men specificerar inte i detalj hur man utför eller implementerar de uppgifter som ingår i processerna.

4) Standarden innehåller väldigt få beskrivningar av databasdesign- detta är motiverat, eftersom olika IS och olika mjukvarusystem kan inte bara använda specifika typer av databaser, utan heller inte använda databaser alls.

5) Värdet av standarden är att det innehåller uppsättningar av uppgifter, kvalitetsegenskaper, utvärderingskriterier m.m., som ger en omfattande täckning av designlösningar.

6) Även om standarden inte föreskriver användningen av en specifik livscykelmodell eller utvecklingsmetod, fastställer den att projektparterna är ansvariga för följande:

val av en livscykelmodell för projektet som utvecklas;

anpassning av processer och uppgifter i standarden till den valda modellen;

val och tillämpning av metoder för mjukvaruutveckling;

Utföra aktiviteter och uppgifter som är lämpliga för ett givet programvaruprojekt.

GOST 34 komplexa standarder.

Det var tänkt som en omfattande uppsättning sammanlänkade intersektoriella dokument.

Objekt för standardisering: automatiserade system av olika slag och alla typer av deras komponenter.

GOST-standarder anger stadierna och faserna av arbetet för att skapa ett automatiserat system, men ger inte uttryckligen bestämmelser om end-to-end-processer som äger rum under implementeringen av livscykeln.

Enligt GOST är utvecklingen av ett automatiserat system uppdelat i följande steg och steg:

Steg 1 bildning av krav på högtalare:

Steg a: inspektion av anläggningen och motivering av behovet av att utveckla ett automatiserat system;

Steg b: bildande av kundkrav för ett automatiserat system;

Steg c: utveckling av en rapport om utfört arbete och utarbetande av en ansökan för utveckling av tekniska specifikationer.

Steg 2 konceptutveckling:

a: studie av föremålet;

b: utföra nödvändig forskning;

c: utveckling av alternativ för NPP-konceptet som uppfyller kundernas krav;

d: Utarbetande av en rapport om utfört arbete.

Steg 3 utveckling och godkännande av tekniska specifikationer för skapandet av kärnkraftverk.

Steg 4 utveckling av en preliminär design av kärnkraftverket:

a: utveckling av preliminära designlösningar för hela systemet som helhet och för dess individuella komponenter;

b: utveckling av dokumentation.

Steg 5 teknisk projektutveckling:

a: utveckling av designlösningar för hela systemet och dess delar;

b: utveckling av dokumentation för det automatiserade systemet och delsystem som ingår i det;

c: utveckling och utförande av dokumentation för leverans av produkter för färdigställande av kärnkraftverk eller utveckling och utförande av tekniska krav för utveckling av dessa produkter.

Steg 6 utveckling av teknisk dokumentation:

a: utveckling av arbetsdokumentation för systemdelen;

b: mjukvaruutveckling eller anpassning.

Steg 7sätta det utvecklade systemet i drift:

a: förbereda automationsobjektet för implementering av automatiserade system;

b: personalutbildning;

c: utrusta högtalarna med mjukvara och hårdvara;

d: installationsarbete;

d: driftsättning;

e: preliminära tester;

g: provdrift;

h: acceptansprov.

Steg 8 eskort:

a: utförande av arbete i enlighet med garantiåtaganden;

b: service efter garantitiden.