Begreppet mjukvarans livscykel. Livscykel för mjukvarusystem

Anteckning.

Introduktion.

1. Programvarans livscykel

Introduktion.

Riley-programmeringsprocesssteg

Introduktion.

1.1.1. Formulering av problemet.

1.1.2. Lösningsdesign.

1.1.3. Algoritmkodning.

1.1.4. Programstöd.

1.1.5. Programvarudokumentation.

Slutsats till klausul 1.1

1.2. Bestämning av LCPO enligt Lehman.

Introduktion.

1.2.1 Systemdefinition.

1.2.2. Genomförande.

1.2.3. Service.

Slutsats till klausul 1.2.

1.3. Faser och arbete av LCPO enligt Boehm

1.3.1. Cascade modell.

1.3.2. Ekonomisk motivering av kaskadmodellen.

1.3.3. Förbättring av kaskadmodellen.

1.3.4. Bestämning av livscykelfaser.

1.3.5. Huvudarbete i projektet.

Litteratur.

Introduktion

Den industriella användningen av datorer och den växande efterfrågan på program har inneburit att brådskande utmaningar ökar avsevärt mjukvaruutvecklingsproduktivitet, utveckling av industriella metoder för planering och programdesign, överföring av organisatoriska, tekniska, tekniska, ekonomiska och sociopsykologiska tekniker, mönster och metoder från sfären för materialproduktion till sfären för datoranvändning. Ett komplext tillvägagångssätt till processerna för mjukvaruutveckling, drift och underhåll, lade han fram ett antal angelägna problem, vars lösning kommer att eliminera flaskhalsar i programdesign, minska slutförandetiden för arbetet, förbättra urvalet och anpassningen av befintliga program, och kanske fastställa ödet för system med inbyggda datorer.

I praktiken att utveckla stora mjukvaruprojekt finns det ofta ingen enhetligt tillvägagångssätt till bedömningen av arbetskostnader, arbetstider och materialkostnader, vilket hindrar ökningen av produktiviteten för programvaruutveckling och i slutändan en effektiv hantering av mjukvarans livscykel. Eftersom ett program av vilken typ som helst blir en produkt (förutom kanske utbildnings-, prototypprogram), bör tillvägagångssättet för dess produktion på många sätt likna tillvägagångssättet för produktion av industriprodukter, och programdesignfrågor blir oerhört viktiga. Denna idé är kärnan i B.W.s bok. Boehm "Software Engineering", som vi använde när vi skrev detta kursarbete. I den här boken hänvisar mjukvarudesign till processen att skapa en design för en mjukvaruprodukt.

1 Programvarans livscykel

INTRODUKTION

LCPO är en kontinuerlig process som börjar från det ögonblick ett beslut fattas om behovet av att skapa mjukvara och slutar i det ögonblick den helt tas ur tjänst.

Det finns flera tillvägagångssätt för att bestämma faserna och aktiviteterna i mjukvarans livscykel (SLC), steg i programmeringsprocessen, kaskad- och spiralmodeller. Men de innehåller alla gemensamma grundläggande komponenter: problembeskrivning, lösningsdesign, implementering, underhåll.

Den mest kända och kompletta är kanske strukturen i livscykelprocessen enligt Boehm, som inkluderar åtta faser. Det kommer att presenteras mer i detalj i framtiden.

Ett av de möjliga alternativen skulle kunna vara en beskrivning på toppnivå enligt Lehman, som inkluderar tre huvudfaser och representerar en beskrivning av livscykeln i det mest allmänna fallet.

Och för variation presenterar vi stegen i programmeringsprocessen som presenteras av D. Riley i boken "Using the Modula-2 Language". Denna idé, enligt min mening, är väldigt enkel och bekant, och låt oss börja med den.

1.1 Steg i Riley-programmeringsprocessen

Introduktion

Programmeringsprocessen omfattar fyra steg (Figur 1):

problemformulering, dvs. erhålla en adekvat förståelse för vilken uppgift programmet ska utföra;

utforma en lösning på ett redan uttalat problem (i allmänhet är en sådan lösning mindre formell än det slutliga programmet);

programkodning, dvs att översätta den designade lösningen till ett program som kan exekveras på en maskin;

programstöd, d.v.s. den pågående processen med att felsöka programmet och lägga till nya funktioner.

Ris. 1. Fyra programmeringssteg.

Programmering börjar från det ögonblick då användare, dvs. någon som behöver ett program för att lösa ett problem anger problemet systemanalytiker. Användaren och systemanalytikern definierar gemensamt problemformuleringen. Den senare sänds sedan algoritmist, som ansvarar för att utforma lösningen. En lösning (eller algoritm) representerar en sekvens av operationer, vars utförande leder till lösningen av ett problem. Eftersom algoritmen ofta inte är lämplig för exekvering på en maskin bör den översättas till ett maskinprogram. Denna operation utförs av kodaren. Underhållaren är ansvarig för efterföljande ändringar av programmet. programmerare. Och systemanalytikern, och algoritmen, och kodaren och den medföljande programmeraren - de är alla programmerare.

I fallet med ett stort programvaruprojekt kan antalet användare, systemanalytiker och algoritmer vara betydande. Dessutom kan det bli nödvändigt att återgå till tidigare steg på grund av oförutsedda omständigheter. Allt detta fungerar som ett ytterligare argument för noggrann mjukvarudesign: resultaten av varje steg ska vara fullständiga, korrekta och begripliga.

1.1.1 Problembeskrivning

Ett av de viktigaste stegen i programmering är att definiera problemet. Det fungerar som ett kontrakt mellan användaren och programmeraren/programmerarna. Liksom ett juridiskt dåligt utformat kontrakt är en dåligt skriven problemformulering värdelös. Med en bra problemformulering representerar både användaren och programmeraren tydligt och entydigt den uppgift som behöver utföras, d.v.s. i detta fall tas hänsyn till både användarens och programmerarens intressen. Användaren kan planera att använda programvara som ännu inte har skapats, baserat på kunskapen om vad den kan göra. En bra redogörelse för problemet tjänar som grund för bildandet av dess lösning.

Formulering av problemet (programspecifikation); betyder i huvudsak en korrekt, fullständig och begriplig beskrivning av vad som händer när ett specifikt program körs. Användaren ser vanligtvis på datorn som en svart låda: för honom spelar det ingen roll hur datorn fungerar, utan det viktiga är vad datorn kan som intresserar användaren. I det här fallet är huvuduppmärksamheten fokuserad på interaktionen mellan människan och maskinen.

Egenskaper för en bra problemformulering:

Noggrannhet, dvs. eliminera alla oklarheter. Det bör inte råda några frågor om vad programmets utdata kommer att vara för en given ingång.

Fullständighet, dvs. överväga alla alternativ för en given ingång, inklusive felaktig eller oavsiktlig inmatning, och bestämma lämplig utdata.

Klarhet, dvs. det måste vara begripligt för både användaren och systemanalytikern, eftersom problemformuleringen är det enda kontraktet mellan dem.

Ofta står kraven på noggrannhet, fullständighet och tydlighet i konflikt. Således är många juridiska dokument svåra att förstå eftersom de är skrivna på ett formellt språk, vilket gör att vissa bestämmelser kan formuleras med extrem precision, med undantag för eventuella mindre avvikelser. Exempelvis är vissa frågor i tentamen ibland så exakt formulerade att studenten lägger mer tid på att förstå frågan än att svara på den. Dessutom kanske studenten inte ens förstår huvudinnebörden av frågan på grund av det stora antalet detaljer. Den bästa formuleringen av problemet är en som uppnår en balans mellan alla tre kraven.

Standardform för problembeskrivning.

Tänk på följande problemformulering: "Mata in tre siffror och mata ut siffrorna i ordning."

Ett sådant uttalande uppfyller inte ovanstående krav: det är varken korrekt, fullständigt eller förståeligt. Ska siffror anges ett per rad eller alla siffror på en rad? Betyder uttrycket "i ordning" att ordna från störst till minst, från minst till störst, eller samma ordning som de introducerades.

Uppenbarligen svarar inte ett sådant uttalande på många frågor. Om vi ​​tar hänsyn till svaren på alla frågor, kommer problemformuleringen att bli mångsidig och svår att förstå. Därför föreslår D. Riley att du använder ett standardformulär för att ställa in problemet, vilket säkerställer maximal noggrannhet, fullständighet, tydlighet och inkluderar:

uppgiftens namn (schematisk definition);

allmän beskrivning (kort sammanfattning av uppgiften);

fel (ovanliga inmatningsalternativ anges uttryckligen för att visa användare och programmerare vilka åtgärder maskinen skulle vidta i sådana situationer);

exempel (ett bra exempel kan förmedla kärnan i problemet och även illustrera olika fall).

Exempel. Redogörelse av problemet i standardformulär.

NAMN

Sorterar tre heltal.

BESKRIVNING

Inmatning och utdata av tre heltal, sorterade från minsta till största tal.

Tre heltal anges, ett tal per rad. Ett heltal är en eller flera på varandra följande decimalsiffror, som kan föregås av ett plustecken "+" eller ett minustecken "–".

De tre heltal som anges skrivs ut, alla tre skrivs ut på samma rad. Intilliggande nummer separeras med ett mellanslag. Siffror visas från minsta till största, från vänster till höger.

1) Om mindre än tre siffror anges väntar programmet på ytterligare inmatning.

2) Andra ingångslinjer än de tre första ignoreras.

Livscykelär en modell för att skapa och använda ett mjukvarusystem. Det återspeglar de olika tillstånden i ett mjukvarusystem, från det ögonblick som behovet av detta mjukvarusystem uppstår och beslutet att skapa det fattas, och slutar med att mjukvarusystemet dras ur drift helt.

Den internationella standarden ISOIES 12207 definierar ett livscykelramverk som innehåller de processer, aktiviteter och uppgifter som måste utföras under skapandet av mjukvara. Enligt denna standard är mjukvarans livscykel baserad på tre grupper av processer:

de viktigaste livscykelprocesserna, det vill säga förvärv, leverans, utveckling, drift och underhåll;

hjälpprocesser som säkerställer genomförandet av huvudprocesserna, det vill säga dokumentation, verifiering, certifiering, kvalitetsbedömning och andra;

organisatoriska processer, det vill säga projektledning, skapande av projektinfrastruktur och utbildning.

Utveckling omfattar allt arbete med att skapa mjukvara i enlighet med specificerade krav. Detta inkluderar utarbetande av design- och driftdokumentation, förberedelse av material som är nödvändigt för att testa funktionalitet och kvalitet hos mjukvaruprodukter.

Huvudstadier i utvecklingsprocessen:

analys av kundkrav;

design;

genomförande (programmering).

Driftprocessen innefattar arbete med att sätta programvara i drift, inklusive konfigurering av arbetsstationer, utbildning av personal, lokalisering av driftsproblem och eliminering av orsakerna till att de uppstår, modifiering av mjukvara inom fastställda regelverk och utarbetande av förslag till systemmodernisering.

Varje process kännetecknas av vissa uppgifter och metoder för att lösa dem, samt initiala data och resultat.

Programvarans livscykel är som regel iterativ till sin natur, det vill säga stadier implementeras, med början från de tidigaste, som upprepas cykliskt i enlighet med förändrade krav på yttre förhållanden och införandet av restriktioner.

Livscykelmodeller för programvara

Det finns flera livscykelmodeller som bestämmer ordningen för genomförandet av utvecklingsstadier och kriterierna för övergång från steg till steg. Hittills har två livscykelmodeller blivit mest utbredda: kaskad Och spiral.

I tidigare existerande homogena informationssystem var varje applikation en enda helhet. För att utveckla sådana applikationer användes en vattenfalls livscykelmodell, även kallad klassisk eller vattenfall.

Vid användning av vattenfallsmodellen sågs utvecklingen som en sekvens av etapper, där övergången till nästa lägre etapp skedde först efter att allt arbete i det aktuella skedet var helt avslutat. Innebörden är att i vattenfallsmodellen börjar utvecklingen på systemnivå och fortsätter genom analys, design, kodning, testning och underhåll.

Figur 1 – Huvudstadier i utvecklingen av en kaskadmodell

1. Systemanalys specificerar varje elements roll i ett datorsystem och interaktionen av element med varandra. Eftersom mjukvara betraktas som en del av ett större system, börjar analysen med att fastställa kraven för alla systemelement. Behovet av systemanalys visar sig tydligt när programvarans gränssnitt med andra element bildas, d.v.s. med hårdvara eller databaser. I samma skede börjar lösningen på projektplaneringsproblem. Under projektplaneringen bestäms volymen av projektarbetet och dess risk, de erforderliga arbetskostnaderna, arbetsuppgifter och ett arbetsschema bildas.

Kravanalys avser ett enda programvaruelement. I detta skede förtydligas och detaljeras funktionerna för varje element, dess egenskaper och gränssnitt. I samma skede slutförs lösningen på projektplaneringsproblemet.

2. Design består av att skapa:

mjukvaruarkitekturer;

modulär mjukvarustruktur;

algoritmisk struktur för programvaran;

data struktur;

input/output gränssnitt (input/output data former).

När man löser designproblem ägnas den största uppmärksamheten åt kvaliteten på den framtida mjukvaruprodukten.

3. Kodning eller utveckling består av att översätta designresultat till programkod.

4. Testning är exekveringen av ett program för att identifiera defekter i funktioner, logik och implementeringsform av en mjukvaruprodukt.

5. Underhåll är att göra ändringar i operativsystemet för att:

Bug fixar;

anpassning till förändringar i miljön utanför programvaran;

förbättring av mjukvara i enlighet med kundens krav.

Fördelar med att använda kaskadmodellen:

ger en plan och tidsplan för alla stadier av projektet, vilket effektiviserar utvecklingen;

vid varje steg genereras en komplett uppsättning designdokumentation, kontrollerad för fullständighet och konsekvens;

de stadier av arbete som utförs i en logisk sekvens gör det möjligt att planera tidpunkten för slutförandet av allt arbete och motsvarande kostnader.

Kaskadmodellen har visat sig väl i konstruktionen av informationssystem, för vilka det i början av utvecklingen är möjligt att ganska noggrant formulera alla krav i systemet, till exempel komplexa beräkningssystem, olika realtidssystem, etc. .

Nackdelar med kaskadmodellen:

verkliga projekt kräver ofta avvikelser från standardsekvensen av steg;

Kaskadmodellen är baserad på den exakta formuleringen av de initiala mjukvarukraven, men i verkligheten, i ett antal fall, i början av projektet, bestäms kundens krav endast delvis;

resultatet av projektet är tillgängligt för kunden först efter avslutat arbete.

På grund av behovet i processen att skapa programvara för att ständigt återgå till tidigare stadier och förtydliga eller revidera tidigare fattade beslut, kan den verkliga mjukvaruutvecklingsprocessen baserad på vattenfallsmodellen representeras av följande diagram (Fig. 2).

Figur 2 – Mjukvaruutvecklingsprocess baserad på vattenfallsmodellen

Programvarans livscykelstandarder

• GOST 34.601-90
• ISO/IEC 12207:1995 (rysk motsvarighet - GOST R ISO/IEC 12207-99)

Metoder för mjukvaruutveckling

• Rational Unified Process (RUP).
• Microsoft Solutions Framework (MSF). Innehåller 4 faser: analys, design, utveckling, stabilisering, involverar användning av objektorienterad modellering.
• Extrem programmering ( Extrem programmering, XP). Metodiken bygger på lagarbete och effektiv kommunikation mellan beställare och entreprenör genom hela IP-utvecklingsprojektet. Utvecklingen sker med successivt förfinade prototyper.

Standard GOST 34.601-90

GOST 34.601-90-standarden tillhandahåller följande steg och steg för att skapa ett automatiserat system:

1. Kravbildning på högtalare
   1. Besiktning av anläggningen och motivering av behovet av att skapa ett kärnkraftverk
   2. Utformning av användarkrav för högtalare
   3. Utarbetande av en rapport om arbetets slutförande och en ansökan om utveckling av en kärnkraftverk
2. Utveckling av AC-konceptet
   1. Studerar objektet
   2. Utför det nödvändiga forskningsarbetet
   3. Utveckling av AC-konceptalternativ och val av AC-konceptalternativ som uppfyller användarnas krav
   4. Gör en rapport om utfört arbete
3. Teknisk uppgift
   1. Utveckling och godkännande av tekniska specifikationer för skapandet av kärnkraftverk
4. Preliminär design
   1. Utveckling av preliminära designlösningar för systemet och dess delar
5. Tekniskt projekt
   1. Utveckling av designlösningar för systemet och dess delar
   2. Utveckling av dokumentation för högtalarsystemet och dess delar
   3. Utveckling och utförande av dokumentation för leverans av komponenter
   4. Utveckling av projekteringsuppgifter i angränsande delar av projektet
6. Arbetsdokumentation
   1. Utveckling av arbetsdokumentation för kärnkraftverket och dess delar
   2. Utveckling och anpassning av program
7. Driftsättning
   1. Förbereda ett automationsobjekt
   2. Personalträning
   3. Komplett uppsättning högtalare med medföljande produkter (mjukvara och hårdvara, mjukvara och hårdvara, informationsprodukter)
   4. Bygg- och installationsarbeten
   5. Driftsättning fungerar
   6. Genomföra preliminära tester
   7. Genomför provdrift
   8. Genomföra acceptanstest
8. AC-stöd.
   1. Utföra arbeten i enlighet med garantiåtaganden
   2. Service efter garantitiden

Skiss, teknisk design och arbetsdokumentation är den konsekventa konstruktionen av fler och mer exakta designlösningar. Det är möjligt att utesluta "Sketch Design"-stadiet och enskilda arbetsstadier i alla stadier, att kombinera stegen "Teknisk design" och "Arbetsdokumentation" till en "Technical Detailed Design", för att utföra olika steg och arbeta parallellt , och att inkludera ytterligare sådana.

Denna standard är inte helt lämplig för den aktuella utvecklingen: många processer återspeglas inte tillräckligt och vissa bestämmelser är föråldrade.

ISO/IEC 12207/ standard och dess tillämpning

ISO/IEC 12207:1995-standarden "Informationsteknik - Programvarulivscykelprocesser" är det huvudsakliga regulatoriska dokumentet som reglerar sammansättningen av mjukvarans livscykelprocesser. Den definierar en livscykelstruktur som innehåller de processer, aktiviteter och uppgifter som måste slutföras under skapandet av programvara.

Varje process är uppdelad i en uppsättning åtgärder, varje åtgärd i en uppsättning uppgifter. Varje process, aktivitet eller uppgift initieras och exekveras av en annan process efter behov, och det finns inga förutbestämda exekveringssekvenser. Kopplingarna mellan indata bevaras.

Programvarans livscykelprocesser

• Grundläggande:
  • Förvärv (åtgärder och uppgifter för kunden som köper programvaran)
  • Leverans (åtgärder och uppgifter för leverantören som förser kunden med en mjukvaruprodukt eller tjänst)
  • Utveckling (åtgärder och uppgifter utförda av utvecklaren: skapande av programvara, förberedelse av design- och driftsdokumentation, förberedelse av test- och utbildningsmaterial, etc.)
  • Drift (operatörens handlingar och uppgifter - organisationen som driver systemet)
  • Underhåll (åtgärder och uppgifter som utförs av den medföljande organisationen, det vill säga supporttjänsten). Support - göra ändringar i mjukvara för att korrigera fel, förbättra produktiviteten eller anpassa till ändrade driftsförhållanden eller krav.
• Extra
  • Dokumentation (formaliserad beskrivning av information som skapats under mjukvarans livscykel)
  • Konfigurationshantering (tillämpning av administrativa och tekniska procedurer under hela mjukvarans livscykel för att bestämma status för programvarukomponenter och hantera dess ändringar).
  • Kvalitetssäkring (ger garantier för att informationssystemet och dess livscykelprocesser uppfyller specificerade krav och godkända planer)
  • Verifiering (avgör att mjukvaruprodukter som härrör från någon åtgärd helt uppfyller kraven eller villkoren som ställts av tidigare åtgärder)
  • Certifiering (fastställer fullständigheten av överensstämmelsen med de specificerade kraven och det skapade systemet med deras specifika funktionella syfte)
  • Gemensam bedömning (bedömning av status för arbetet med projektet: kontroll av planering och förvaltning av resurser, personal, utrustning, verktyg)
  • Revision (avgör efterlevnad av krav, planer och avtalsvillkor)
  • Problemlösning (analys och lösning av problem, oavsett ursprung eller källa, som upptäcks under utveckling, drift, underhåll eller andra processer)
• Organisatorisk
  • Kontroll (åtgärder och uppgifter som kan utföras av vilken part som helst som hanterar dess processer)
  • Skapande av infrastruktur (val och underhåll av teknik, standarder och verktyg, val och installation av hårdvara och mjukvara som används för utveckling, drift eller underhåll av programvara)
  • Förbättring (bedömning, mätning, kontroll och förbättring av livscykelprocesser)
  • Utbildning (inledande utbildning och efterföljande fortlöpande personalutveckling)

Varje process inkluderar ett antal åtgärder. Till exempel omfattar förvärvsprocessen följande aktiviteter:

1. Initiering av förvärv
2. Utarbetande av anbudsförslag
3. Förberedelse och justering av kontrakt
4. Övervakning av leverantörsverksamhet
5. Acceptans och slutförande av arbete

Varje aktivitet innehåller ett antal uppgifter. Till exempel bör utarbetandet av anbudsförslag inkludera:

1. Bildande av systemkrav
2. Generera en lista över mjukvaruprodukter
3. Fastställande av villkor och avtal
4. Beskrivning av tekniska begränsningar (systemoperativmiljö etc.)

Stadier av mjukvarans livscykel, relationer mellan processer och stadier

Programvarans livscykelmodell- en struktur som bestämmer sekvensen av utförandet och relationerna mellan processer, handlingar och uppgifter under hela livscykeln. Livscykelmodellen beror på projektets särdrag, skala och komplexitet och de specifika förutsättningarna under vilka systemet skapas och fungerar.

GOST R ISO/IEC 12207-99-standarden erbjuder inte en specifik livscykelmodell. Dess bestämmelser är gemensamma för alla livscykelmodeller, metoder och tekniker för att skapa IP. Den beskriver strukturen för livscykelprocesser utan att specificera hur man ska implementera eller slutföra de aktiviteter och uppgifter som ingår i dessa processer.

Programvarans livscykelmodell inkluderar:

1. Etapper;
2. Resultat av arbete i varje steg;
3. Nyckelhändelser är punkterna för slutförande av arbetet och beslutsfattande.

Skede- en del av processen för att skapa programvara, begränsad av en viss tidsram och slutar med lanseringen av en specifik produkt (modeller, programvarukomponenter, dokumentation), bestäms av de krav som specificeras för detta steg.

I varje steg kan flera processer som definieras i GOST R ISO/IEC 12207-99-standarden utföras, och vice versa kan samma process utföras i olika steg. Relationen mellan processer och stadier bestäms också av den mjukvarulivscykelmodell som används.

Livscykelmodeller för programvara

En livscykelmodell är en struktur som definierar sekvensen av utförande och relationer mellan processer, handlingar och uppgifter som utförs under hela livscykeln. Livscykelmodellen beror på informationssystemets särdrag och de specifika förhållanden under vilka det senare skapas och verkar

Hittills har följande huvudlivscykelmodeller blivit mest utbredda:

• Problemmodell;

• kaskadmodell (eller system) (70-85);

• spiralmodell (nuvarande).

Problemmodell

När man utvecklar ett system "bottom-up" från enskilda uppgifter till hela systemet (uppgiftsmodell) går ett enhetligt tillvägagångssätt för utveckling oundvikligen förlorat, och problem uppstår i informationskopplingen av enskilda komponenter. Som regel, när antalet uppgifter ökar, ökar svårigheterna, och det är nödvändigt att ständigt ändra befintliga program och datastrukturer. Hastigheten i utvecklingen av systemet saktar ner, vilket bromsar utvecklingen av själva organisationen. Men i vissa fall kan denna teknik vara att rekommendera:

• Extremt brådskande (problemen måste lösas på något sätt; då måste allt göras igen);

• Experiment och anpassning av kunden (algoritmerna är inte tydliga, lösningarna hittas genom försök och misstag).

Den allmänna slutsatsen är att det är omöjligt att skapa ett tillräckligt stort och effektivt informationssystem på detta sätt.

Cascade modell

Cascade modell livscykel föreslogs 1970 av Winston Royce. Det tillhandahåller sekventiell implementering av alla stadier av projektet i en strikt fastställd ordning. Övergången till nästa steg innebär ett fullständigt slutförande av arbetet i föregående steg (Fig. 1). De krav som fastställs vid kravbildningsstadiet är strikt dokumenterade i form av tekniska specifikationer och registreras för hela utvecklingen av projektet. Varje steg kulminerar i släppet av en komplett uppsättning dokumentation som är tillräcklig för att utvecklingen ska kunna fortsätta av ett annat utvecklingsteam.

De positiva aspekterna med att använda kaskadmetoden är följande:

• vid varje steg genereras en komplett uppsättning designdokumentation som uppfyller kriterierna för fullständighet och konsekvens;

• de stadier av arbete som utförs i en logisk sekvens gör det möjligt att planera slutförandetiden för allt arbete och motsvarande kostnader.

Projektstadier enligt vattenfallsmodellen:

1. Utformning av krav;
2. Design;
3. Genomförande;
4. Testning;
5. Genomförande;
6. Drift och underhåll.

Ris. 1. Kaskadutvecklingsschema

Kaskadmetoden har visat sig väl i konstruktionen av informationssystem, för vilka alla krav i början av utvecklingen kan formuleras ganska exakt och fullständigt för att ge utvecklare friheten att implementera dem så bra som möjligt från en teknisk synpunkt. se. Komplexa beräkningssystem, realtidssystem och andra liknande uppgifter faller inom denna kategori. Men i processen att använda detta tillvägagångssätt upptäcktes ett antal av dess brister, främst orsakade av det faktum att den verkliga processen att skapa system aldrig helt passade in i ett så stelbent schema. Under skapelseprocessen fanns det ett ständigt behov av att återgå till tidigare skeden och förtydliga eller revidera tidigare fattade beslut. Som ett resultat tog själva processen för att skapa programvara följande form (bild 2):

Ris. 2. Verklig mjukvaruutvecklingsprocess med hjälp av ett vattenfallsschema

Den största nackdelen med kaskadmetoden är den betydande förseningen i att erhålla resultat. Samordning av resultat med användare utförs endast på punkter som är planerade efter slutförandet av varje steg i arbetet "fryst" i form av tekniska specifikationer under hela tiden för dess skapande. Således kan användare lämna sina kommentarer först efter att arbetet med systemet är helt slutfört. Om kraven ställs felaktigt eller de ändras under en lång period av mjukvaruutveckling, får användarna ett system som inte uppfyller deras behov. Modeller (både funktionella och informativa) av det automatiserade objektet kan bli inaktuella samtidigt med deras godkännande. Kärnan i ett systematiskt förhållningssätt till IS-utveckling ligger i dess nedbrytning (nedbrytning) i automatiserade funktioner: systemet är uppdelat i funktionella delsystem, som i sin tur är indelade i underfunktioner, indelade i uppgifter, och så vidare. Partitioneringsprocessen fortsätter ner till specifika procedurer. Samtidigt har det automatiserade systemet en helhetssyn där alla komponenter är sammankopplade. Den här modellens främsta fördel är alltså dess systematiska utveckling, och dess främsta nackdelar är att den är långsam och dyr.

Spiral modell

För att övervinna dessa problem föreslogs det spiralmodell livscykel (Figur 3), som utvecklades i mitten av 1980-talet av Barry Boehm. Den är baserad på de inledande stadierna av livscykeln: analys och design. I dessa skeden testas genomförbarheten av tekniska lösningar genom att skapa prototyper.

Prototyp- en operativsystemkomponent som implementerar individuella funktioner och externa gränssnitt. Varje iteration motsvarar skapandet av ett fragment eller en version av programvaran, där målen och egenskaperna för projektet förtydligas, kvaliteten på de erhållna resultaten bedöms och arbetet med nästa iteration planeras.

Varje iteration representerar en komplett utvecklingscykel, vilket resulterar i lanseringen av en intern eller extern version av en produkt (eller en delmängd av den slutliga produkten) som förbättras från iteration till iteration för att bli ett komplett system.

Varje varv av spiralen motsvarar skapandet av ett fragment eller en version av programvaran, där målen och egenskaperna för projektet förtydligas, dess kvalitet bestäms och arbetet med nästa varv av spiralen planeras. Således fördjupas projektets detaljer och konsekvent specificeras, och som ett resultat väljs ett rimligt alternativ som förs till genomförande.

Utveckling genom iterationer återspeglar den objektivt existerande spiralcykeln för att skapa ett system. Ofullständigt slutförande av arbetet i varje steg gör att du kan gå vidare till nästa steg utan att vänta på att arbetet är färdigt i det nuvarande. Med en iterativ utvecklingsmetod kan det saknade arbetet slutföras i nästa iteration. Huvuduppgiften är att visa systemanvändare en fungerande produkt så snabbt som möjligt och därigenom aktivera processen med att förtydliga och komplettera krav.

Huvudproblemet med spiralcykeln är att bestämma övergångsögonblicket till nästa steg. För att lösa det är det nödvändigt att införa tidsbegränsningar för varje steg i livscykeln. Övergången går som planerat, även om inte allt planerat arbete är slutfört. Planen upprättas utifrån statistiska data som erhållits från tidigare projekt och utvecklarnas personliga erfarenheter.

Figur 3. Spiralmodell av livscykeln för en IC

Ett möjligt tillvägagångssätt för mjukvaruutveckling inom spirallivscykelmodellen är RAD-metoden (Rapid Application Development), som nyligen har blivit utbredd. Denna term hänvisar vanligtvis till en mjukvaruutvecklingsprocess som innehåller 3 element:

• ett litet team av programmerare (från 2 till 10 personer);

• kort men noggrant utarbetat produktionsschema (från 2 till 6 månader);

• en upprepad cykel där utvecklare, när applikationen börjar ta form, begär och implementerar i produkten de krav som fåtts genom interaktion med kunden.

Programvarans livscykel enligt RAD-metoden består av fyra faser:

• kravdefinition och analysfas;

• designfas;

• genomförandefas;

• genomförandefas.

Vid varje iteration utvärderas följande:

• risk för att överskrida projektdeadlines och kostnader;
• behovet av att utföra ytterligare en iteration;
• graden av fullständighet och noggrannhet för förståelse av systemkrav;
• möjligheten att avsluta projektet.

Fördelar med den iterativa metoden:

• Iterativ utveckling förenklar i hög grad att göra ändringar i projektet när kundernas krav förändras.
• När man använder spiralmodellen integreras enskilda delar av informationssystemet gradvis till en enda helhet. Med ett iterativt tillvägagångssätt sker integration praktiskt taget kontinuerligt. Eftersom integrationen börjar med färre element är det mycket färre problem under implementeringen (enligt vissa uppskattningar, när man använder vattenfallsutvecklingsmodellen, står integrationen för upp till 40 % av alla kostnader i slutet av projektet).
• Iterativ utveckling ger större flexibilitet i projektledning, vilket gör det möjligt att göra taktiska förändringar av den produkt som utvecklas.
• Det iterativa tillvägagångssättet förenklar återanvändningen av komponenter (implementerar en komponentbaserad metod för programmering). Det beror på att det är mycket lättare att identifiera gemensamma delar av ett projekt när de redan är delvis utvecklade än att försöka identifiera dem redan i början av projektet. Att analysera designen efter några inledande iterationer avslöjar vanliga, återanvändbara komponenter som kommer att förbättras i efterföljande iterationer.
• Spiralmodellen möjliggör ett mer pålitligt och stabilt system. Detta beror på att när systemet utvecklas upptäcks och korrigeras fel och svagheter vid varje iteration. Samtidigt kan kritiska effektivitetsparametrar justeras, vilket i fallet med en kaskadmodell endast är möjligt innan systemet implementeras.
• Det iterativa tillvägagångssättet gör det möjligt att förbättra utvecklingsprocessen – analysen som görs i slutet av varje iteration gör att vi kan bedöma vad som behöver förändras i utvecklingsorganisationen och förbättra det vid nästa iteration.

Anteckning.

Introduktion.

1. Programvarans livscykel

Introduktion.

Riley-programmeringsprocesssteg

Introduktion.

1.1.1. Formulering av problemet.

1.1.2. Lösningsdesign.

1.1.3. Algoritmkodning.

1.1.4. Programstöd.

1.1.5. Programvarudokumentation.

Slutsats till klausul 1.1

1.2. Bestämning av LCPO enligt Lehman.

Introduktion.

1.2.1 Systemdefinition.

1.2.2. Genomförande.

1.2.3. Service.

Slutsats till klausul 1.2.

1.3. Faser och arbete av LCPO enligt Boehm

1.3.1. Cascade modell.

1.3.2. Ekonomisk motivering av kaskadmodellen.

1.3.3. Förbättring av kaskadmodellen.

1.3.4. Bestämning av livscykelfaser.

1.3.5. Huvudarbete i projektet.

Litteratur.

Introduktion

Den industriella användningen av datorer och den växande efterfrågan på program har inneburit att brådskande utmaningar ökar avsevärt mjukvaruutvecklingsproduktivitet, utveckling av industriella metoder för planering och programdesign, överföring av organisatoriska, tekniska, tekniska, ekonomiska och sociopsykologiska tekniker, mönster och metoder från sfären för materialproduktion till sfären för datoranvändning. Ett komplext tillvägagångssätt till processerna för mjukvaruutveckling, drift och underhåll, lade han fram ett antal angelägna problem, vars lösning kommer att eliminera flaskhalsar i programdesign, minska slutförandetiden för arbetet, förbättra urvalet och anpassningen av befintliga program, och kanske fastställa ödet för system med inbyggda datorer.

I praktiken att utveckla stora mjukvaruprojekt finns det ofta ingen enhetligt tillvägagångssätt till bedömningen av arbetskostnader, arbetstider och materialkostnader, vilket hindrar ökningen av produktiviteten för programvaruutveckling och i slutändan en effektiv hantering av mjukvarans livscykel. Eftersom ett program av vilken typ som helst blir en produkt (förutom kanske utbildnings-, prototypprogram), bör tillvägagångssättet för dess produktion på många sätt likna tillvägagångssättet för produktion av industriprodukter, och programdesignfrågor blir oerhört viktiga. Denna idé är kärnan i B.W.s bok. Boehm "Software Engineering", som vi använde när vi skrev detta kursarbete. I den här boken hänvisar mjukvarudesign till processen att skapa en design för en mjukvaruprodukt.

1 Programvarans livscykel

INTRODUKTION

LCPO är en kontinuerlig process som börjar från det ögonblick ett beslut fattas om behovet av att skapa mjukvara och slutar i det ögonblick den helt tas ur tjänst.

Det finns flera tillvägagångssätt för att bestämma faserna och aktiviteterna i mjukvarans livscykel (SLC), steg i programmeringsprocessen, kaskad- och spiralmodeller. Men de innehåller alla gemensamma grundläggande komponenter: problembeskrivning, lösningsdesign, implementering, underhåll.

Den mest kända och kompletta är kanske strukturen i livscykelprocessen enligt Boehm, som inkluderar åtta faser. Det kommer att presenteras mer i detalj i framtiden.

Ett av de möjliga alternativen skulle kunna vara en beskrivning på toppnivå enligt Lehman, som inkluderar tre huvudfaser och representerar en beskrivning av livscykeln i det mest allmänna fallet.

Och för variation presenterar vi stegen i programmeringsprocessen som presenteras av D. Riley i boken "Using the Modula-2 Language". Denna idé, enligt min mening, är väldigt enkel och bekant, och låt oss börja med den.

1.1 Steg i Riley-programmeringsprocessen

Programmeringsprocessen omfattar fyra steg (Figur 1):

problemformulering, dvs. erhålla en adekvat förståelse för vilken uppgift programmet ska utföra;

utforma en lösning på ett redan uttalat problem (i allmänhet är en sådan lösning mindre formell än det slutliga programmet);

programkodning, dvs att översätta den designade lösningen till ett program som kan exekveras på en maskin;

programstöd, d.v.s. den pågående processen med att felsöka programmet och lägga till nya funktioner.

Ris. 1. Fyra programmeringssteg.

Programmering börjar från det ögonblick då användare, dvs. någon som behöver ett program för att lösa ett problem anger problemet systemanalytiker. Användaren och systemanalytikern definierar gemensamt problemformuleringen. Den senare sänds sedan algoritmist, som ansvarar för att utforma lösningen. En lösning (eller algoritm) representerar en sekvens av operationer, vars utförande leder till lösningen av ett problem. Eftersom algoritmen ofta inte är lämplig för exekvering på en maskin bör den översättas till ett maskinprogram. Denna operation utförs av kodaren. Den medföljande programmeraren ansvarar för efterföljande ändringar av programmet. Och systemanalytikern, och algoritmen, och kodaren och den medföljande programmeraren - de är alla programmerare.

I fallet med ett stort programvaruprojekt kan antalet användare, systemanalytiker och algoritmer vara betydande. Dessutom kan det bli nödvändigt att återgå till tidigare steg på grund av oförutsedda omständigheter. Allt detta fungerar som ett ytterligare argument för noggrann mjukvarudesign: resultaten av varje steg ska vara fullständiga, korrekta och begripliga.

1.1.1 Problembeskrivning

Ett av de viktigaste stegen i programmering är att definiera problemet. Det fungerar som ett kontrakt mellan användaren och programmeraren/programmerarna. Liksom ett juridiskt dåligt utformat kontrakt är en dåligt skriven problemformulering värdelös. Med en bra problemformulering representerar både användaren och programmeraren tydligt och entydigt den uppgift som behöver utföras, d.v.s. i detta fall tas hänsyn till både användarens och programmerarens intressen. Användaren kan planera att använda programvara som ännu inte har skapats, baserat på kunskapen om vad den kan göra. En bra redogörelse för problemet tjänar som grund för bildandet av dess lösning.

Formulering av problemet (programspecifikation); betyder i huvudsak en korrekt, fullständig och begriplig beskrivning av vad som händer när ett specifikt program körs. Användaren ser vanligtvis på datorn som en svart låda: för honom spelar det ingen roll hur datorn fungerar, utan det viktiga är vad datorn kan som intresserar användaren. I det här fallet är huvuduppmärksamheten fokuserad på interaktionen mellan människan och maskinen.

Egenskaper för en bra problemformulering:

Noggrannhet, dvs. eliminera alla oklarheter. Det bör inte råda några frågor om vad programmets utdata kommer att vara för en given ingång.

Fullständighet, dvs. överväga alla alternativ för en given ingång, inklusive felaktig eller oavsiktlig inmatning, och bestämma lämplig utdata.

Klarhet, dvs. det måste vara begripligt för både användaren och systemanalytikern, eftersom problemformuleringen är det enda kontraktet mellan dem.

Ofta står kraven på noggrannhet, fullständighet och tydlighet i konflikt. Således är många juridiska dokument svåra att förstå eftersom de är skrivna på ett formellt språk, vilket gör att vissa bestämmelser kan formuleras med extrem precision, med undantag för eventuella mindre avvikelser. Exempelvis är vissa frågor i tentamen ibland så exakt formulerade att studenten lägger mer tid på att förstå frågan än att svara på den. Dessutom kanske studenten inte ens förstår huvudinnebörden av frågan på grund av det stora antalet detaljer. Den bästa formuleringen av problemet är en som uppnår en balans mellan alla tre kraven.

Standardform för problembeskrivning.

Tänk på följande problemformulering: "Mata in tre siffror och mata ut siffrorna i ordning."

Ett sådant uttalande uppfyller inte ovanstående krav: det är varken korrekt, fullständigt eller förståeligt. Ska siffror anges ett per rad eller alla siffror på en rad? Betyder uttrycket "i ordning" att ordna från störst till minst, från minst till störst, eller samma ordning som de introducerades.

Uppenbarligen svarar inte ett sådant uttalande på många frågor. Om vi ​​tar hänsyn till svaren på alla frågor, kommer problemformuleringen att bli mångsidig och svår att förstå. Därför föreslår D. Riley att du använder ett standardformulär för att ställa in problemet, vilket säkerställer maximal noggrannhet, fullständighet, tydlighet och inkluderar:

uppgiftens namn (schematisk definition);

allmän beskrivning (kort sammanfattning av uppgiften);

fel (ovanliga inmatningsalternativ anges uttryckligen för att visa användare och programmerare vilka åtgärder maskinen skulle vidta i sådana situationer);

exempel (ett bra exempel kan förmedla kärnan i problemet och även illustrera olika fall).

Exempel. Redogörelse av problemet i standardformulär.

NAMN

Sorterar tre heltal.

BESKRIVNING

Inmatning och utdata av tre heltal, sorterade från minsta till största tal.

Tre heltal anges, ett tal per rad. Ett heltal är en eller flera på varandra följande decimalsiffror, som kan föregås av ett plustecken "+" eller ett minustecken "–".

De tre heltal som anges skrivs ut, alla tre skrivs ut på samma rad. Intilliggande nummer separeras med ett mellanslag. Siffror visas från minsta till största, från vänster till höger.

1) Om mindre än tre siffror anges väntar programmet på ytterligare inmatning.

2) Andra ingångslinjer än de tre första ignoreras.

3) Om någon av de tre första raderna innehåller mer än ett heltal, avslutas programmet och visar ett meddelande.

INPUT ERROR - Endast ett heltal tillåtet per rad.

ingång ® – 3

Detta programmeringssteg är det svåraste. I detta skede måste problemformuleringen omvandlas till en algoritm. Därför måste algoritmdesignern ha tillräcklig erfarenhet av programmering och närma sig varje nytt problem baserat på en fast etablerad designmetodik. Tyvärr innehåller alla stora program numera buggar, vilket leder till dåliga projekt. Dåliga konstruktioner är i sin tur en följd av problemens komplexitet och användningen av otillräckliga konstruktionsmetoder. För att undvika fel i program måste algoritmer använda noggrant utformade designprocedurer baserade på slutledningsregler.

Det finns två huvudsakliga slutledningsmodeller:

Den första modellen är känd som deduktiv slutledning. Denna form av logiskt tänkande förevigades av den berömda detektiven Sherlock Holmes. Deduktiv logik tillämpar allmänna regler på specifika fall. Till exempel kunde Holmes härleda det specifika uttalandet "The Butler is a murderer" från den mer allmänna kunskapen "The Blonde Killer" och "The Butler är den enda blonda mannen som kan misstänkas."

Den andra modellen är induktiv utgång, vilket är motsatsen till deduktiv slutledning. Induktiv logik drar allmänna slutsatser från enskilda fall. Till exempel kan induktiv slutledning användas för att motivera den allmänna slutsatsen "solen går upp i öster" baserat på många individuella observationer att solen alltid har gått upp i öster.

Dessa två slutledningsprocesser är − avdrag(från allmänt till specifikt) och induktion(från särskilt till allmänt) - är nära besläktade med de två mest använda designmetoderna: "uppifrån och ner" Och "ner upp". Precis som deduktion börjar top-down design med ett stort problem som bryts ner i delproblem. Till exempel måste konstruktören av ett nytt kyl-frysskåp, baserat på en initial uppsättning enhetsspecifikationer (d.v.s. problemformuleringen), ta fram detaljerade konstruktioner och specifikationer för den slutliga produkten (d.v.s. designen).

Om han använder en top-down designmetod kan ett enda designproblem delas upp i två mindre delproblem: (1) design av kylenheten och (2) design av frysen.

Du kan dock använda bottom-up-designmetoden och börja med att designa kylkompressorn och sedan kylrören, enheten eller kylrummet. I det här fallet kommer detta val att medföra vissa begränsningar för hela projektet.

Designerns uppgift är att skapa en algoritm som fungerar som en länk mellan problemformuleringen och programmet redo för exekvering. Verifieringen av den skapade algoritmen, det vill säga hur väl den återspeglar formuleringen av problemet, utförs av en systemanalytiker. På grund av detta måste både systemanalytikern och designern kunna läsa och förstå algoritmen. Varje algoritm är skriven på något pseudospråk . Algoritmer, även kallade pseudokoder, kan inte köras på någon dator.

Kodarens uppgift är att översätta algoritmen till ett program. För att skapa ett komplett, korrekt och begripligt program krävs lämpliga metoder för att skriva program. Till exempel är kulinariska recept vanligtvis skrivna på naturliga språk som engelska, franska, ryska eller japanska. Program är skrivna på programmeringsspråk. För närvarande kan inget av de naturliga språken användas som programmeringsspråk eftersom de är för komplexa för att "förstås" av maskiner. Till skillnad från naturliga språk skapas programmeringsspråk specifikt för att representera en lösning på ett problem som kan utföras av en dator.

Kodaren måste se till att programmet matchar pseudokoden innan det avslutas. Sedan måste systemanalytikern, algoritmen och, viktigast av allt, användaren testa och bekräfta att det fungerar korrekt. Efter detta kan vi anta att programmet är redo att överföras till användaren komplett med all nödvändig dokumentation.

Men programmering slutar inte där; följd av ackompanjemangssteg. Faktum är att det kan finnas fel i programmet, antingen på grund av en otillräcklig problembeskrivning eller på att projektet inte uppfyller problemformuleringen eller att programmet inte överensstämmer med projektet. Oavsett anledning har användaren rätt att kräva att programmet anpassas eftersom han inte föreställt sig att programmet skulle fungera på detta sätt. Felkorrigering är en av huvuduppgifterna för programunderhåll. En annan lika viktig uppgift för programunderhåll är dess modifiering, det vill säga att lägga till nya funktioner i programmet eller ändra befintliga. Användaren kan ändra kraven för driften av programmet, vilket i sin tur kommer att leda till behovet av att skriva om det. Komplexiteten i programunderhållet beror på vilken typ av ändringar som behöver göras: i värsta fall kan programmet behöva göras om helt från produktion till kodning. Vanligtvis ägnas mer tid åt att underhålla ett program än att skapa det.

Den sista delen av programmeringsprocessen är dokumentation. Den innehåller ett brett utbud av beskrivningar som underlättar programmeringsprocessen och berikar det resulterande programmet. Kontinuerlig dokumentation bör vara en integrerad del av varje programmeringssteg. Problembeskrivning, designdokument, algoritmer och program - allt detta är dokument. Intern dokumentation som ingår direkt i programmet gör koden lättare att läsa. Syftet med en utbildningsmanual (en annan form av dokumentation) är att lära användaren hur man använder ett nytt program; Referensmanualen ger en beskrivning av programvarukommandona.

Slutsats till klausul 1.1.

Enligt modellen som presenteras i detta kapitel kan programmering delas in i fyra steg: definiera problemet, designa lösningar, koda programmet och underhålla programmet. Dessutom inkluderar modellen att dokumentera programmet som aktiviteter som måste utföras under hela programmeringsprocessen.

Programmeringsmodellen är byggd specifikt för att lösa stora problem, eftersom de är intressanta för datavetare. Men i praktiken är det viktigt att använda noggrant utvalda ingenjörstekniker för programdesign, oavsett storleken på problemen: de färdigheter som förvärvats för att lösa mindre problem kan förstärkas och framgångsrikt implementeras för att lösa större problem.

definitioner;

genomförande;

service.

1.2.1 Systemdefinition

Processen att skapa programvara börjar med praktisk forskning som leder till systemanalys, vars uppgift är att fastställa de övergripande kraven för systemet och programmen. En sådan analys bör först och främst fastställa verkliga behov och mål och om möjligt identifiera tillgängliga metoder för att uppnå målet. Vid behov kan analysen baseras på matematiska eller andra formella scheman. Man tror att med vilket tillvägagångssätt som helst måste den specificerade analysen ha en viss struktur och utföras i enlighet med någon teori. Analys och förfining, utförd tillsammans med analytiker och potentiella användare, bör leda till utvecklingen av en slutlig kravspecifikation .

Processen att skriva en sådan specifikation syftar till att erhålla en korrekt teknisk specifikation, komplett i den meningen att den återspeglar kraven och överensstämmer med definitionen av implementeringen. Efter utarbetandet av specifikationer är fasen design, vars innebörd är att identifiera och strukturera data, omvandla dem och organisera deras överföring. Dessutom är det i denna fas nödvändigt att uppnå, i en viss mening, en optimal fördelning av systemets funktioner, välja en algoritm och procedurer och även identifiera systemkomponenter och förhållandet mellan dem.

Efter att ha genomfört design vi kan börja genomförande system. Men i praktiken överlappar design- och implementeringsfaserna. Allteftersom den hierarkiska uppdelningsprocessen fortskrider kan analysen av vissa delar av systemet anses vara tillräckligt komplett för att gå vidare till implementering, medan andra delar kräver ytterligare förtydligande.

Under implementeringsprocessen är det nödvändigt att fastställa programmets riktighet. Moderna procedurer är till stor del testbaserade, även om användningen av end-to-end strukturkontroll och programvalideringsmetoder har ökat under de senaste åren.

Hur som helst, testning genom programexekvering görs vanligtvis nerifrån och upp, först på blocknivå (modulär eller procedur), sedan funktionellt, komponent för komponent. När enskilda komponenter testas, kombineras de till ett system under dess layoutprocess, varefter systemtestningen påbörjas. I slutändan, efter att kvaliteten på systemets funktion har verifierats oberoende av varandra och dess parametrar har utvärderats, anses det vara redo för släpp.

1.2.3 Underhåll

Underhållsprocessen börjar omedelbart efter att systemet har släppts. Fel måste identifieras och rättas till. Om en bugg förhindrar normal användning av användaren, kan det felaktiga programmet tillfälligt tas bort från systemet, eller tillfälliga eller permanenta korrigeringar kan göras på några eller alla system som används. Den permanenta fixen eller ändringen kan sedan inkluderas i en ny version av systemet. För att tillgodose alla ändringar och deras kombinationer skapas flera versioner av systemelement. Huvuduppgiften blir systemkonfigurationshantering. En avgörande roll i programmeringshanteringen tillhör supporttjänster, som automatiskt samlar in och reglerar alla förändringar i systemet.

Slutsats till klausul 1.2.

Det metasystem som programmet utvecklas inom innehåller ett betydligt större antal återkopplingsslingor än vad som anges ovan. Många aktiviteter överlappar varandra, är sammanflätade på komplexa sätt och upprepas systematiskt. Därför är LCPO-modellen som presenteras av Boehm tillräckligt motiverad.

1.3 Livscykelcentras faser och arbete enligt Boehm

Kaskadmodellen introducerades på 70-80-talet. Det är bekvämt för homogen programvara, när varje applikation var en enda helhet.

Huvudegenskaper hos modellen:

Livscykeln är indelad i stadier (faser);

Övergång från steg till steg - först efter fullständigt slutförande av det aktuella steget;

Stadiet avslutas med att en komplett uppsättning dokumentation släpps, tillräckligt för att arbetet kan slutföras av ett annat utvecklingsteam.

Huvuddragen kaskadmodell det följande:

slutföra varje fas med verifiering och validering, vars syfte är att eliminera så många problem i samband med produktutveckling som möjligt;

cykliska upprepningar av genomförda faser från tidigast möjliga fas.

Fig.2. Kaskadmodell av LCPO.

I kaskadmodellen innebär ett framgångsrikt slutförande av en av faserna i livscykeln uppnåendet av motsvarande tekniska programmeringsmål (se avsnitt 2.4.). Till dessa delmål måste du lägga till ytterligare två:

Detaljerad designbarhet– erhållande av fullständiga verifierade specifikationer och kontroll- och datastrukturer, gränssnittsanslutningar, egenskaper, grundläggande algoritmer och bestämning av driftsförhållandena för varje programvarukomponent.

Kodbarhet– erhålla en komplett, verifierad uppsättning programkomponenter.

Huvudfördelar:

Bildande av en komplett uppsättning projektdokumentation i slutet av arbetet på scenen. Dokumentationen uppfyller kriterierna för fullständighet och fullständighet;

Förmåga att planera deadlines och kostnader. För ett antal mjukvaruapplikationer är denna modell genomförbar - det här är för system för vilka det i analysstadiet är möjligt att exakt och fullständigt formulera alla krav. Till exempel komplexa datorprogram.

Huvudsakliga nackdelar:

Långa ledtider från analys till färdigställande;

Programvarukraven ”fryss” i form av tekniska specifikationer fram till slutet av utvecklingen.

1.3.2 Ekonomisk motivering för kaskadmodellen

Utan att fördjupa sig i den ekonomiska analys som B.U. Boehm betalar mycket uppmärksamhet i boken "Software Engineering", låt oss bara säga att den ekonomiska motiveringen för vattenfallsmodellen, fokuserad på sekventiell måluppfyllelse, bygger på två huvudsakliga premisser:

För att erhålla en högkvalitativ mjukvaruprodukt (d.v.s. en som helt uppfyller alla målen för den erforderliga mjukvaruprodukten) är det i alla fall nödvändigt att implementera alla delmål i varje steg.

All annan beställning av delmål resulterar i skapandet av en mjukvaruprodukt av lägre kvalitet.

1.3.3 Förbättring av kaskadmodellen

Låt oss överväga en av förbättringarna av den ideala vattenfallsmodellen - steg-för-steg-utveckling.

Steg-för-steg utvecklingär en förbättring av den iterativa designmetoden med prototyper och skiktad top-down-utveckling. Denna metod innebär att programvarans funktionalitet stegvis ökar under utvecklingsprocessen.

Som en avancerad vattenfallsmodell har inkrementell utveckling framgångsrikt använts för att skapa både mycket stora och små mjukvaruprodukter.

De främsta fördelarna med steg-för-steg-utveckling jämfört med absolut iterativ utveckling och nivå-för-nivå top-down-utveckling är följande:

användningen av successiva förlängningar av programmet ger ett mycket billigare sätt att införliva användarupplevelsen i en förbättrad produkt än med omutveckling;

Utökad funktionalitet är mycket lättare att testa och är mer användbar än mellanprodukter i lagerutveckling.

Värdet av inkrementell utveckling ligger främst i att förändra fördelningen av arbetskostnaderna för projektet. En variant av kaskadmodellen med steg-för-steg-utveckling visas i figur 3.

1.3.4 Definition av livscykelfaser

Nedan ges formuleringen av de slutliga målen för varje fas för övergången till nästa fas. För steg-för-steg utveckling hänvisar de givna uttalandena till fasgränserna för varje expansionssteg.

Börja kravplanerings- och analysfasen.(Fullständig konceptuell genomgång av LCPE.)

Erhålla en godkänd och bekräftad systemarkitektur, inklusive grundläggande avtal om fördelning av funktioner mellan hårdvara och program. Erhålla en godkänd och bekräftad allmän förståelse av programvarans funktion, inklusive grundläggande överenskommelser om fördelningen av funktioner mellan personen och systemet.

Utformning av en översiktsplan för livscykelprocessen, som definierar huvudstadierna, resurser, ansvar, deadlines och huvudarbeten.

Genomför kravplanerings- och analysfasen. Börja produktdesignfasen.(Fullständig genomgång av mjukvarukrav).

Utformning av en detaljerad utvecklingsplan: detaljerade indikatorer för slutförandet av utvecklingsstadier, resursallokeringsplaner, organisationsstrukturdiagram, ansvar, deadlines, arbeten, metoder och produkter.

Utformning av en detaljerad plan för användning: punkter i utvecklingsplanen, vars innehåll är fokuserat på utbildning, överföring av program, implementering, drift och underhåll.

Bildande av en detaljerad produktfelsökningsplan - hanteringsplan för hårdvarukonfiguration, plan för kvalitetskontroll, allmän verifiering och bekräftelseplan.

Godkänd och validerad programvarukravspecifikation: funktionella, tekniska och gränssnittsspecifikationer som har visat sig vara fullständiga, konsekventa, verifierbara och genomförbara.

Ett godkänt (formellt eller informellt) utvecklingsavtal baserat på punkterna ovan.

Avsluta produktdesignfasen. Börja den detaljerade designfasen.(Slutför analys av produktdesignresultat.)

Utveckling av en verifierad specifikation för ett programvaruproduktprojekt:

bildande av en hierarki av mjukvarukomponenter, interblock-gränssnitt för data och kontroll;

bildande av fysiska och logiska datastrukturer ner till nivån för enskilda fält;

utveckling av en plan för distribution av datorresurser (tid, minne, noggrannhet);

verifiering av kravens fullständighet, konsekvens, genomförbarhet och giltighet.

Identifiering och upplösning av alla utvecklingsmotsättningar som ökar riskgraden.

Utveckling av ett preliminärt steg för integration och felsökning, en användarmanualplan och acceptanstest.

Slutför den detaljerade designfasen. Börja kodnings- och offlinefelsökningsfasen.(Slutförande av projektkontroll från slut till slut eller kritisk blockanalys av projektet.)

Verifierad detaljerad specifikation för varje block:

specifikation av varje subrutin, namn, syfte, antaganden, dimensioner, anropssekvens, felutgångar, in- och utdata, algoritmer och logikdesign;

beskrivning av databasen ner till nivån av enskilda parametrar, symboler och bitar;

Verifiering av fullständighet, konsekvens och överensstämmelse med systemdesignspecifikationer och resursallokeringsplaner.

Godkänd acceptanstestplan.

Användarmanualer, samt en färdig preliminär integrations- och felsökningsplan.

Avsluta kopierings- och felsökningsfasen. Börja integrations- och felsökningsfasen.(Tillfredsställa kriterier för offlinefelsökning.)

Kontrollera driften av alla enheter inte bara för nominella värden, utan också för exceptionella och gränsvärden.

Kontrollera alla in- och utmatningsalternativ, inklusive felmeddelanden.

Utförande av alla operatörer och alla grenar av kontrollöverföring.

Kontrollera efterlevnad av programmeringsstandarder.

Slutförande av block-för-block-dokumentation av den interna strukturen.

Slutför integrations- och testfasen. Börja implementeringsfasen.(Slutförd analys av acceptanstestresultat.)

Kontrollera överensstämmelse med programmets acceptanstest:

kontrollera efterlevnad av programvarukrav;

Demonstration av acceptansen av de prestandaegenskaper som anges i specifikationerna under onormala förhållanden.

Godkännande av medföljande mjukvaruprodukter, rapporter, manualer, databaser, interna strukturspecifikationer.

Slutför implementeringsfasen. Börja drift- och underhållsfasen.(Fullständig granskning av systemacceptans.)

Kontrollera tillfredsställelsen av systemets acceptanstestresultat.

Verifiera att systemkraven är tillfredsställande.

Kontrollera produktionsberedskapen av mjukvara, hårdvara, underhållsverktyg och personal.

Acceptans av produkter som levereras och ingår i systemet: hårdvara, mjukvara, dokumentation, utbildning och underhållsverktyg.

Slutförande av alla specificerade arbeten och driftsättning av systemet.

Slutför drift- och underhållsfasen(genom avbrytande).

Uppfyllelse av alla punkter i avvecklingsplanen: överföring av program, dokumentation, skapande av ett arkiv, övergång till ett nytt system.

1.3.5 Huvudarbete med projektet

Kravanalys.

Produktdesign.

Programmering.

Felsökningsplanering.

Verifiering och bekräftelse.

Projektledning.

Konfigurationshantering och kvalitetskontroll.

Så, tre metoder för att bestämma mjukvarans livscykel övervägdes. Enligt min åsikt har de alla rätt att existera, eftersom de i en eller annan grad återspeglar praxis med programmering. Dessutom är det lätt att upptäcka gemensamma punkter (en uppgift är satt - ett system definieras - krav analyseras; programunderhåll - underhåll - drift och underhåll).

Det bör dock noteras att Boehms definition av livscykelcentrets faser och arbete är den mest motiverade, eftersom förlitar sig på ett mer fokuserat tillvägagångssätt inom teknisk programmering (som syftar till att erhålla en högkvalitativ mjukvaruprodukt och implementera en effektiv mjukvaruutvecklings- och underhållsprocess) och är ekonomiskt motiverad.

Baserat på denna rapport är det tydligt hur viktigt och nödvändigt det är att känna till den moderna världens behov när man skapar en mjukvaruprodukt (produkt). När man skapar ett program för att automatisera vilket system som helst är det viktigt att ta hänsyn till att den moderna världen ständigt förändras, vilket innebär att programmet måste kunna förändras.

Det är också viktigt, när man gör upp ett program, att ta hänsyn till att programmet måste vara korrekt; komplett till sitt innehåll och lämplig för att arbeta med både små och stora problem i enlighet med sitt syfte; tydlig - så att användaren kan arbeta med det lugnt och utan svårighet. Och även så att programmet enkelt kan korrigeras eller kompletteras när som helst i enlighet med de förändrade kraven i den moderna världen.

Man bör komma ihåg att bra programmering inte handlar om att koda en snabb lösning med någon lämplig teknik, utan om en noggrant instrumenterad ingenjörsprocedur som producerar komplett, exakt och lättförståelig (tydlig) programvara.

1. B.U. Boehm, Software Engineering. M.: Radio och kommunikationer. 1985.

2. D. Riley. "Använda Modula-2-språket." M.: Mir. 1993.

3. Yu.V. Ivanov "Program och deras livscykler" (abstrakt om disciplinen "Software Metrology"). 1998.

Hej kära invånare i Khabrovsk! Jag tror att det kommer att vara intressant för någon att komma ihåg vilka modeller för utveckling, implementering och användning av mjukvara som fanns tidigare, vilka modeller som främst används nu, varför och vad det faktiskt är. Det här blir mitt lilla ämne.

Egentligen, vad är det mjukvarans livscykel- en serie händelser som inträffar med systemet under dess skapande och vidare användning. Med andra ord, detta är tiden från det första ögonblicket för skapandet av en mjukvaruprodukt till slutet av dess utveckling och implementering. Programvarans livscykel kan representeras i form av modeller.

Programvarans livscykelmodell- en struktur innehållande åtgärdsprocesser och uppgifter som utförs under utveckling, användning och underhåll av en mjukvaruprodukt.
Dessa modeller kan delas in i tre huvudgrupper:

1. Ingenjörsmetod
2. Med hänsyn till uppgiftens detaljer
3. Modern teknik för snabb utveckling

Felkodnings- och elimineringsmodell

1. Formulering av problemet
2. Prestanda
3. Kontrollerar resultatet
4. Om det behövs, gå till den första punkten

Vattenfall programvara livscykelmodell (vattenfall)

Fördelar:

• Sekventiell implementering av projektstadier i strikt fastställd ordning
• Låter dig utvärdera produktens kvalitet i varje steg

• Ingen återkoppling mellan stegen
• Motsvarar inte verkliga villkor för utveckling av mjukvaruprodukt

Kaskadmodell med mellanstyrning (bubbelpool)

V-modell (testdriven utveckling)

Modell baserad på prototyputveckling

1. Förtydliga oklara krav (UI-prototyp)
2. Välj en av ett antal konceptuella lösningar (implementering av scenarier)
3. Analysera projektets genomförbarhet

1. Horisontell och vertikal
2. Engångs- och evolutionär
3. papper och storyboards

Modellen tillhör den andra gruppen.

Spiral programvara livscykelmodell

Fördelar:

• Få resultat snabbt
• Ökad konkurrenskraft
• Att ändra krav är inga problem

• Brist på scenreglering

Tack så mycket för din uppmärksamhet!