Měli bychom začít definovánímŽivotní cyklus softwaru(Software Life Cycle Model) je časový úsek, který začíná okamžikem rozhodnutí o vytvoření softwarového produktu a končí okamžikem jeho úplného stažení z provozu. Tento cyklus je proces budování a vývoje softwaru.
Modely životního cyklu softwaru
Životní cyklus lze znázornit ve formě modelů. V současnosti jsou nejběžnější:kaskádové, přírůstkové (etapový model se středním ovládáním ) a spirálamodely životního cyklu.
Kaskádový model
Kaskádový model(angl. model vodopádu) je model procesu vývoje softwaru, jehož životní cyklus vypadá jako tok, který postupně prochází fázemi analýzy požadavků, návrhu. implementace, testování, integrace a podpora.
Proces vývoje je realizován pomocí uspořádané sekvence nezávislých kroků. Model zajišťuje, že každý následující krok začíná po dokončení předchozího kroku. Ve všech krocích modelu jsou prováděny pomocné a organizační procesy a práce, včetně projektového řízení, hodnocení a řízení kvality, ověřování a certifikace, konfiguračního managementu a tvorby dokumentace. V důsledku dokončení kroků se tvoří meziprodukty, které nelze v následujících krocích měnit.
Životní cyklus se tradičně dělí na následující hlavníetapy:
- Analýza požadavků,
- Design,
- kódování (programování),
- Testování a ladění,
- Provoz a údržba.
Výhody modelu:
- stabilita požadavků během celého životního cyklu vývoje;
- v každé fázi je vytvořen kompletní soubor projektové dokumentace splňující kritéria úplnosti a konzistence;
- určitost a srozumitelnost kroků modelu a jednoduchost jeho aplikace;
- etapy práce prováděné v logickém sledu umožňují naplánovat načasování dokončení všech prací a odpovídající zdroje (peněžní, materiální a lidské).
Nevýhody modelu:
- složitost jasně formulovaných požadavků a nemožnost jejich dynamické změny v průběhu celého životního cyklu;
- nízká flexibilita v řízení projektů;
- posloupnost lineární struktury vývojového procesu v důsledku návratu k předchozím krokům k řešení vznikajících problémů vede ke zvýšení nákladů a narušení harmonogramu práce;
- nevhodnost meziproduktu k použití;
- nemožnost flexibilního modelování unikátních systémů;
- pozdní detekce problémů souvisejících se stavbou v důsledku současné integrace všech výsledků na konci vývoje;
- nedostatečná účast uživatele na tvorbě systému - na samém začátku (při vývoji požadavků) a na konci (při akceptačních testech);
- uživatelé se nemohou přesvědčit o kvalitě vyvíjeného produktu až do konce celého procesu vývoje. Nemají možnost hodnotit kvalitu, protože nevidí hotový produkt vývoje;
- uživatel nemá možnost si postupně na systém zvyknout. Proces učení nastává na konci životního cyklu, kdy již byl software uveden do provozu;
- každá fáze je předpokladem pro provedení následných akcí, což činí takovou metodu riskantní volbou pro systémy, které nemají analogy, protože. není vhodný pro flexibilní modelování.
Je obtížné implementovat model životního cyklu vodopádu kvůli složitosti vývoje PS bez návratu k předchozím krokům a změně jejich výsledků, aby se eliminovaly vznikající problémy.
Rozsah kaskádového modelu
Omezení rozsahu kaskádového modelu je dáno jeho nedostatky. Jeho použití je nejúčinnější v následujících případech:
- při vývoji projektů s jasným, neměnnýmživotní cyklus požadavky srozumitelné implementačními a technickými metodikami;
- při vývoji projektu zaměřeného na vybudování systému nebo produktu stejného typu, jaký dříve vyvinuli vývojáři;
- při vývoji projektu souvisejícího s vytvořením a vydáním nové verze stávajícího produktu nebo systému;
- při vývoji projektu souvisejícího s převodem stávajícího produktu nebo systému na novou platformu;
- při provádění velkých projektů zahrnujících několik velkých vývojových týmů.
inkrementální model
(postupný model se středním ovládáním)
inkrementální model(angl. přírůstek- zvýšení, přírůstek) znamená vývoj softwaru s lineárním sledem fází, ale v několika přírůstcích (verzích), tzn. s plánovanými vylepšeními produktu, dokud se životní cyklus vývoje softwaru chýlí ke konci.
Vývoj softwaru se provádí v iteracích se zpětnovazebními smyčkami mezi fázemi. Mezietapové úpravy umožňují zohlednit skutečné vzájemné ovlivňování výsledků vývoje v různých fázích, životnost každé z fází se prodlužuje po celou dobu vývoje.
Na začátku práce na projektu jsou stanoveny všechny základní požadavky na systém rozdělené na více a méně důležité. Poté je vývoj systému prováděn inkrementálně, aby vývojář mohl využít data získaná při vývoji softwaru. Každý přírůstek by měl do systému přidat určitou funkcionalitu. V tomto případě vydání začíná komponentami s nejvyšší prioritou. Když jsou části systému definovány, vezměte první část a začněte ji podrobně popisovat pomocí nejvhodnějšího postupu. Zároveň je možné zpřesnit požadavky na další části, které byly zmrazeny v aktuálním souboru požadavků této práce. V případě potřeby se můžete k této části vrátit později. Pokud je díl hotový, je doručen klientovi, který jej může využít při své práci. To zákazníkovi umožní ujasnit si požadavky na následující komponenty. Poté vyvinou další část systému. Klíčovými kroky v tomto procesu jsou jednoduchá implementace podmnožiny softwarových požadavků a zdokonalování modelu v řadě po sobě jdoucích vydání, dokud není software plně implementován.
Životní cyklus tohoto modelu je typický pro vývoj komplexních a komplexních systémů, u kterých existuje jasná vize (jak ze strany zákazníka, tak ze strany vývojáře), jaký by měl být konečný výsledek. Vývoj verzí se provádí z různých důvodů:
- nedostatek schopnosti zákazníka okamžitě financovat celý nákladný projekt;
- nedostatek potřebných zdrojů pro developera k realizaci složitého projektu v krátké době;
- požadavky na postupnou implementaci a vývoj produktu koncovými uživateli. Zavedení celého systému najednou může způsobit odmítnutí jeho uživatelů a pouze „zpomalit“ proces přechodu na nové technologie. Obrazně řečeno, nemohou jednoduše „strávit velký kus, takže se musí rozdrtit a dát po částech“.
Výhody a omezenítohoto modelu (strategie) jsou stejné jako u kaskády (klasický model životního cyklu). Ale na rozdíl od klasické strategie může zákazník vidět výsledky dříve. Na základě výsledků vývoje a implementace první verze může mírně změnit požadavky na vývoj, upustit od něj nebo nabídnout vývoj pokročilejšího produktu s uzavřením nové smlouvy.
výhody:
- náklady vzniklé v důsledku měnících se požadavků uživatelů jsou sníženy, re-analýza a shromažďování dokumentace jsou výrazně sníženy ve srovnání s vodopádovým modelem;
- je snazší získat zpětnou vazbu od klienta o provedené práci - klienti mohou vyjádřit své připomínky k hotovým dílům a mohou vidět, co již bylo hotovo. Protože první části systému jsou prototypem systému jako celku.
- zákazník má možnost rychle získat a osvojit si software – zákazníci mohou získat skutečné výhody ze systému dříve, než by to bylo možné u vodopádového modelu.
Nevýhody modelu:
- manažeři musí neustále měřit průběh procesu. v případě rychlého vývoje se nevyplatí vytvářet dokumenty pro každou minimální změnu verze;
- struktura systému má tendenci se zhoršovat, když jsou přidávány nové komponenty - neustálé změny narušují strukturu systému. Aby k tomu nedocházelo, je nutný dodatečný čas a peníze na refaktorizaci. Kvůli špatné struktuře je pozdější úprava softwaru obtížná a nákladná. A přerušený životní cyklus softwaru vede k ještě větším ztrátám.
Schéma neumožňuje rychle zohlednit vznikající změny a vyjasnění softwarových požadavků. Koordinace výsledků vývoje s uživateli se provádí pouze v bodech plánovaných po dokončení každé etapy práce a obecné požadavky na software jsou fixovány formou technického úkolu po celou dobu jeho tvorby. Uživatelé tak často dostávají software, který neodpovídá jejich skutečným potřebám.
spirálový model
Spirálový model:Životní cyklus - při každém otočení spirály se vytvoří další verze produktu, upřesní se požadavky projektu, určí se jeho kvalita a naplánuje se práce na další zatáčku. Zvláštní pozornost je věnována počátečním fázím vývoje - analýze a návrhu, kde se testuje proveditelnost určitých technických řešení a odůvodňuje se tvorbou prototypů.
Tento model je procesem vývoje softwaru, který kombinuje návrh a etapové prototypování, aby spojil výhody konceptů zdola nahoru a shora dolů, s důrazem na počáteční fáze životního cyklu: analýzu a návrh.Výrazná vlastnost Tento model věnuje zvláštní pozornost rizikům ovlivňujícím organizaci životního cyklu.
Ve fázích analýzy a návrhu je pomocí vytváření prototypů prověřována proveditelnost technických řešení a míra uspokojení potřeb zákazníka. Každé otočení spirály odpovídá vytvoření funkčního fragmentu nebo verze systému. To vám umožní ujasnit si požadavky, cíle a charakteristiky projektu, určit kvalitu vývoje a naplánovat práci na další zatáčku spirály. Dochází tak k prohloubení a důsledné konkretizaci detailů projektu a ve výsledku je vybrána rozumná varianta, která odpovídá skutečným požadavkům zákazníka a je přivedena k realizaci.
Životní cyklus na každém otočení spirály - lze použít různé modely procesu vývoje softwaru. Konečným výsledkem je hotový výrobek. Model kombinuje schopnosti prototypového modelu amodel vodopádu. Vývoj po iteracích odráží objektivně existující spirálový cyklus tvorby systému. Neúplné dokončení práce v každé fázi vám umožňuje přejít do další fáze, aniž byste čekali na úplné dokončení práce na aktuální fázi. Hlavním úkolem je co nejdříve ukázat uživatelům systému funkční produkt, a tím aktivovat proces upřesňování a doplňování požadavků.
Výhody modelu:
- umožňuje rychle ukázat uživatelům systému funkční produkt, čímž aktivuje proces upřesňování a doplňování požadavků;
- umožňuje změny požadavků během vývoje softwaru, což je typické pro většinu vývojů, včetně standardních;
- model poskytuje možnost flexibilního návrhu, protože ztělesňuje výhody kaskádového modelu a současně jsou povoleny iterace ve všech fázích stejného modelu;
- umožňuje získat spolehlivější a stabilnější systém. Jak se software vyvíjí, jsou chyby a slabiny nalezeny a opraveny v každé iteraci;
- tento model umožňuje uživatelům aktivně se podílet na plánování, analýze rizik, vývoji a také na provádění evaluačních aktivit;
- snížit riziko zákazníka. Zákazník může dokončit vývoj neperspektivního projektu s minimálními finančními ztrátami;
- zpětná vazba od uživatelů k vývojářům se provádí s vysokou frekvencí a na začátku modelu, což zajišťuje vysokou kvalitu požadovaného produktu.
Nevýhody modelu:
- pokud je projekt nízkorizikový nebo malý, model může být drahý. Hodnocení rizik po každé spirále je drahé;
- Životní cyklus modelu má komplikovanou strukturu, takže jeho aplikace vývojáři, manažery a zákazníky může být obtížná;
- spirála může pokračovat donekonečna, protože reakce každého zákazníka na vytvořenou verzi může generovat nový cyklus, který zpožďuje dokončení projektu;
- velký počet mezicyklů může vést k nutnosti zpracovat další dokumentaci;
- použití modelu může být nákladné a dokonce nedostupné, protože čas. výdaje na plánování, přesměrování, provádění analýzy rizik a prototypování mohou být nadměrné;
- může být obtížné definovat cíle a milníky indikující připravenost pokračovat ve vývojovém procesu na příští a
Hlavním problémem spirálového cyklu je určení okamžiku přechodu do další fáze. K jeho vyřešení jsou pro každou z etap zavedeny časové limity.životní cyklus a přechod probíhá podle plánu, i když nejsou dokončeny všechny plánované práce.Plánováníje vyrobena na základě statistických údajů získaných v předchozích projektech a osobních zkušeností vývojářů.
Rozsah spirálového modelu
Použití spirálového modelu se doporučuje v následujících případech:
- při vývoji projektů využívajících nové technologie;
- při vývoji nové řady produktů nebo systémů;
- při vývoji projektů s očekávanými významnými změnami nebo doplnění požadavků;
- pro realizaci dlouhodobých projektů;
- při vývoji projektů, které vyžadují prokázání kvality a verzí systému nebo produktu v krátkém časovém období;
- při vývoji projektů. u kterých je nutné kalkulovat náklady spojené s posouzením a řešením rizik.
V tomto standardu PS (resp software) je definován jako soubor počítačových programů, postupů a případně související dokumentace a dat. Proces je definován jako soubor vzájemně souvisejících akcí, které transformují některá vstupní data na výstupní data (G. Myers tomu říká překlad dat). Každý proces je charakterizován určitými úkoly a metodami jejich řešení. Každý proces je zase rozdělen do sady akcí a každá akce je rozdělena do sady úkolů. Každý proces, akce nebo úloha je podle potřeby iniciována a vykonávána jiným procesem a neexistují žádné předem určené sekvence provádění (samozřejmě při zachování spojení vstupních dat).
Je třeba poznamenat, že v Sovětském svazu a poté v Rusku byla tvorba softwaru (softwaru) zpočátku, v 70. letech minulého století, regulována normami GOST ESPD (Unified System for Program Documentation - GOST 19.XXX). série), které byly zaměřeny na třídu relativně jednoduché programy malého objemu vytvářené jednotlivými programátory. V současné době jsou tyto normy koncepčně i formálně zastaralé, jejich platnost skončila a jejich použití je nevhodné.
Procesy tvorby automatizovaných systémů (AS), které zahrnují i software, jsou regulovány normami GOST 34.601-90 "Informační technologie. Soubor norem pro automatizované systémy. Etapy tvorby", GOST 34.602-89 "Informační technologie. A soubor standardů pro automatizované systémy. Technický úkol pro vytvoření automatizovaného systému“ a GOST 34.603-92 „Informační technologie. Typy testů automatizovaných systémů". Mnohá ustanovení těchto norem jsou však zastaralá, jiná nejsou reflektována natolik, aby mohla být použita pro seriózní projekty na tvorbu PS. Proto je vhodné v domácím vývoji používat moderní mezinárodní normy.
V souladu s normou ISO / IEC 12207 jsou všechny procesy životního cyklu softwaru rozděleny do tří skupin (obr. 5.1).
Rýže. 5.1.
Ve skupinách je definováno pět hlavních procesů: akvizice, dodávka, vývoj, provoz a údržba. Osm dílčích procesů zajišťuje provádění hlavních procesů, jmenovitě dokumentace, správa konfigurace, zajištění kvality, ověřování, validace, společné hodnocení, audit, řešení problémů. Čtyři organizační procesy zajišťují správu, budování infrastruktury, zlepšování a učení.
5.2. Hlavní procesy životního cyklu PS
Akviziční proces se skládá z činností a úkolů zákazníka nakupujícího software. Tento proces zahrnuje následující kroky:
- zahájení akvizice;
- příprava návrhů aplikací;
- příprava a úprava smlouvy;
- dohled nad činností dodavatele;
- přijetí a dokončení práce.
Zahájení akvizice zahrnuje následující úkoly:
- určení zákazníkem jeho potřeb při pořizování, vývoji nebo zlepšování systému, softwarových produktů nebo služeb;
- rozhodování o akvizici, vývoji nebo vylepšení stávajícího softwaru;
- kontrola dostupnosti potřebné dokumentace, záruk, certifikátů, licencí a podpory v případě nákupu softwarového produktu;
- příprava a schválení akvizičního plánu včetně systémových požadavků, typu smlouvy, odpovědnosti stran atd.
Nabídky musí obsahovat:
- Požadavky na systém;
- seznam softwarových produktů;
- podmínky akvizice a dohody;
- technická omezení (například na operační prostředí systému).
Nabídky jsou v případě výběrového řízení zasílány vybranému dodavateli nebo více dodavatelům. Dodavatel je organizace, která uzavře se zákazníkem smlouvu na dodávku systému, softwaru nebo softwarové služby za podmínek uvedených ve smlouvě.
Příprava a úprava smlouvy zahrnuje následující úkoly:
- stanovení postupu při výběru dodavatele zákazníkem včetně kritérií pro hodnocení návrhů možných dodavatelů;
- výběr konkrétního dodavatele na základě analýzy návrhů;
- příprava a závěr dodavatelské smlouvy;
- provádění změn (v případě potřeby) smlouvy v procesu její realizace.
Činnost dodavatele je kontrolována v souladu s opatřeními stanovenými v procesech společného posuzování a auditu. Během přejímacího procesu jsou připraveny a provedeny potřebné zkoušky. Dokončení díla dle smlouvy se provádí v případě splnění všech podmínek převzetí.
Proces dodání zahrnuje činnosti a úkoly prováděné prodejcem, který dodává zákazníkovi softwarový produkt nebo službu. Tento proces zahrnuje následující kroky:
- zahájení dodávky;
- příprava odpovědi na nabídky;
- příprava smlouvy;
- plánování smluvních prací;
- provádění a kontrola smluvních prací a jejich hodnocení;
- dodání a dokončení prací.
Zahájení dodávky spočívá ve zvážení nabídek dodavatelem a rozhodnutí, zda bude souhlasit se stanovenými požadavky a podmínkami nebo nabídne své (odsouhlasené). Plánování zahrnuje následující úkoly:
- rozhodování dodavatele o provedení díla vlastními silami nebo se zapojením subdodavatele;
- vývoj dodavatelem plánu řízení projektu obsahující organizační strukturu projektu, vymezení odpovědnosti, technické požadavky na vývojové prostředí a zdroje, řízení subdodavatelů atd.
Proces vývoje zajišťuje činnosti a úkoly prováděné vývojářem a pokrývá práci na vytváření softwaru a jeho komponent v souladu se stanovenými požadavky. Jedná se o přípravu projektové a provozní dokumentace, přípravu podkladů nutných pro výkonnostní zkoušky a kvalitu softwarových produktů, materiály potřebné pro organizaci školení zaměstnanců atp.
Proces vývoje zahrnuje následující kroky:
- přípravné práce;
- analýza požadavků na systém;
- návrh architektury systému;
- Analýza požadavků na software;
- Návrh softwarové architektury;
- detailní návrh softwaru;
- kódování a testování softwaru;
- integrace softwaru;
- testování kvalifikace softwaru;
- systémová integrace;
- kvalifikační testování systému;
- instalace softwaru;
- přijetí softwaru.
Přípravné práce začínají výběrem modelu životního cyklu softwaru vhodného pro rozsah, význam a složitost projektu. Činnosti a úkoly vývojového procesu by měly být v souladu se zvoleným modelem. Developer musí vybrat, přizpůsobit se podmínkám projektu a použít standardy, metody a metody dohodnuté se zákazníkem. vývojové nástroje a také sestavit pracovní plán.
Analýza požadavků na systém zahrnuje určení jeho funkčnosti, vlastní požadavky, požadavky na spolehlivost, bezpečnost, požadavky na externí rozhraní, výkon atd. Systémové požadavky jsou hodnoceny na základě kritérií proveditelnosti a ověřitelnosti během testování.
Návrh architektury systému spočívá v určení komponent jeho vybavení (hardwaru), softwaru a operací prováděných personálem obsluhujícím systém. Architektura systému musí být v souladu se systémovými požadavky a uznávanými konstrukčními standardy a postupy.
Analýza požadavků na software zahrnuje stanovení následujících charakteristik pro každou softwarovou komponentu:
- funkčnost, včetně výkonnostních charakteristik a provozního prostředí komponenty;
- externí rozhraní;
- specifikace spolehlivosti a bezpečnosti;
- ergonomické požadavky;
- požadavky na používaná data;
- požadavky na instalaci a přijetí;
- požadavky na uživatelskou dokumentaci;
- požadavky na provoz a údržbu.
Softwarové požadavky jsou hodnoceny na základě kritérií shody s požadavky na systém jako celek, proveditelnosti a ověřitelnosti během testování.
Návrh softwarové architektury zahrnuje následující úlohy pro každou softwarovou komponentu:
- transformace softwarových požadavků do architektury, která na vysoké úrovni definuje strukturu softwaru a skladbu jeho komponent;
- Vývoj a dokumentace programových rozhraní pro software a databáze (DB);
- vývoj předběžné verze uživatelské dokumentace;
- vývoj a dokumentace předpokladů pro testy a plán integrace softwaru.
Detailní návrh softwaru zahrnuje následující úkoly:
- popis softwarových komponent a rozhraní mezi nimi na nižší úrovni, dostatečné pro následné kódování a testování;
- vývoj a dokumentace podrobného návrhu databáze;
- aktualizace (v případě potřeby) uživatelské dokumentace;
- vývoj a dokumentace požadavků na testování a plánu testování softwarových komponent;
Kódování a testování softwaru zahrnuje následující úkoly:
- kódování a dokumentace každé součásti softwaru a databáze, stejně jako příprava sady testovacích postupů a dat pro jejich testování;
- testování každé součásti softwaru a databáze na shodu s požadavky na ně, následované dokumentací výsledků testů;
- aktualizace dokumentace (v případě potřeby);
- aktualizace plánu integrace softwaru.
Softwarová integrace zajišťuje sestavení vyvinutých softwarových komponent v souladu s plánem integrace a testování pro agregované komponenty. Pro každou z agregovaných komponent jsou vyvinuty testovací sady a testovací procedury, které testují každou z kompetencí v následném testování způsobilosti. Kvalifikační požadavek je soubor kritérií nebo podmínek, které musí být splněny, aby se kvalifikoval. software jako vyhovující svým specifikacím a připravené k použití v terénu.
Kvalifikační testování softwaru provádí vývojář za přítomnosti zákazníka (
Provozní proces pokrývá činnosti a úkoly organizace provozovatele provozujícího systém. Operační proces zahrnuje následující kroky.
Přípravné práce, které zahrnují provádění následujících úkolů operátorem:
- plánování činností a prací prováděných během provozu a stanovování provozních standardů;
- stanovení postupů pro lokalizaci a řešení problémů vznikajících při provozu.
- Provozní testování prováděné pro každou další edici softwarového produktu, po kterém je tato edice převedena do provozu.
- Vlastní provoz systému, který je prováděn v prostředí k tomu určeném v souladu s uživatelskou dokumentací.
- analýza problémů a požadavků na úpravu softwaru (analýza zpráv o vzniklém problému nebo požadavku na úpravu, posouzení rozsahu, nákladů na úpravu, výsledného efektu, posouzení proveditelnosti úpravy);
- úprava softwaru (provádění změn součástí a dokumentace softwarových produktů v souladu s pravidly procesu vývoje);
- ověření a přijetí (ve smyslu integrity upravovaného systému);
- převod softwaru do jiného prostředí (konverze programů a dat, paralelní provoz softwaru ve starém a novém prostředí po určitou dobu);
- vyřazení softwaru z provozu rozhodnutím zákazníka za účasti provozní organizace, servisní služby a uživatelů. Softwarové produkty a dokumentace zároveň podléhají archivaci v souladu se smlouvou.
Anotace.
Úvod.
1. Životní cyklus softwaru
Úvod.
Kroky procesu programování Riley
Úvod.
1.1.1. Formulace problému.
1.1.2. Návrh řešení.
1.1.3. Kódování algoritmů.
1.1.4. Programová podpora.
1.1.5. Softwarová dokumentace.
Závěr k odstavci 1.1
1.2. Definice ZhTsPO podle Lehmana.
Úvod.
1.2.1 Definice systému.
1.2.2. Implementace.
1.2.3. Servis.
Závěr k bodu 1.2.
1.3. Fáze a práce programu životního cyklu podle Boehma
1.3.1. kaskádový model.
1.3.2. Ekonomické zdůvodnění kaskádového modelu.
1.3.3. Vylepšení kaskádového modelu.
1.3.4. Definice fází životního cyklu.
1.3.5. Základní práce na projektu.
Literatura.
Úvod
Průmyslové využití počítačů a rostoucí poptávka po programech kladou naléhavé úkoly pro výrazný nárůst produktivitu vývoje softwaru, vývoj průmyslových metod pro plánování a navrhování programů, přenos organizačních, technických, technických, ekonomických a sociálně psychologických metod, vzorů a metod ze sféry materiálové výroby do sféry počítačů. Komplexní přístup do procesů vývoje, provozu a údržby softwaru klade řadu naléhavých problémů, jejichž řešením se odstraní „úzká místa“ při navrhování programů, zkrátí se doba dokončení, zlepší se výběr a přizpůsobení stávajících programů a možná určí osud systémů s vestavěnými počítači.
V praxi vývoje velkých softwarových projektů často neexistuje jednotný přístup k hodnocení mzdových nákladů, termínů práce a materiálových nákladů, což brání zvýšení produktivity vývoje softwaru a v konečném důsledku i efektivnímu řízení životního cyklu softwaru. Vzhledem k tomu, že se program jakéhokoli typu stává produktem (snad kromě vzdělávacích, maketových programů), přístup k jeho výrobě by měl být v mnoha ohledech podobný přístupu k výrobě průmyslových produktů a otázky návrhu softwaru se stávají extrémně důležité. . Tato myšlenka je základem B.U. Boehm "Engineering Software Design", který jsme použili při psaní této semestrální práce. V této knize se návrhem softwaru rozumí proces vytváření návrhu softwarového produktu.
1 Životní cyklus softwaru
ÚVOD
LCPE je nepřetržitý proces, který začíná okamžikem rozhodnutí o nutnosti vytvořit software a končí okamžikem jeho úplného vyřazení z provozu.
Existuje několik přístupů k definování fází a činností životního cyklu softwaru (SLLC), programovacích procesních kroků, vodopádových a spirálových modelů. Všechny ale obsahují společné základní komponenty: prohlášení o problému, návrh řešení, implementace, údržba.
Nejznámější a nejúplnější je snad struktura životního cyklu podle Boehma, která zahrnuje osm fází. Podrobněji bude představen později.
Jednou z možných variant může být popis horní úrovně podle Lehmana, který zahrnuje tři hlavní fáze a představuje popis programu životního cyklu v nejobecnějším případě.
A zde jsou pro změnu kroky programovacího procesu prezentované D. Rileyem v knize „Using the Modula-2 Language“. Tato myšlenka je podle mého názoru velmi jednoduchá a známá a začneme s ní.
1.1 Kroky procesu programování Riley
Úvod
Proces programování zahrnuje čtyři kroky (obr. 1):
prohlášení o problému, tzn. získání dostatečné představy o tom, jaký úkol by měl program vykonávat;
navržení řešení již nastoleného problému (obecně je takové řešení méně formální než konečný program);
programové kódování, tj. překlad navrženého řešení do programu, který lze spustit na stroji;
programová podpora, tzn. pokračující proces oprav chyb v programu a přidávání nových funkcí.
Rýže. 1.Čtyři kroky programování.
Programování začíná od okamžiku, kdy uživatel, tj. někdo, kdo potřebuje program k vyřešení problému, představuje problém systémový analytik. Uživatel a systémový analytik společně definují prohlášení o problému. Ten se pak přenese algoritmista kdo je zodpovědný za návrh řešení. Řešení (neboli algoritmus) je posloupnost operací, jejichž provedení vede k vyřešení problému. Protože algoritmus často není uzpůsoben k provádění na počítači, měl by být přeložen do strojového programu. Tuto operaci provádí kodér. Správce je odpovědný za následné změny programu. programátor. A systémový analytik, algoritmus, kodér a doprovodný programátor – všichni jsou programátoři.
V případě velkého softwarového projektu může být počet uživatelů, systémových analytiků a algoritmů významný. Kromě toho může být nutné vrátit se k předchozím krokům kvůli nepředvídaným okolnostem. To vše slouží jako další argument ve prospěch pečlivého návrhu softwaru: výsledky každého kroku by měly být úplné, přesné a srozumitelné.
1.1.1 Popis problému
Jedním z nejdůležitějších kroků při programování je nastavení problému. Funguje jako smlouva mezi uživatelem a programátorem (programátory). Stejně jako právně špatně zpracovaná smlouva je špatné prohlášení o poslání k ničemu. S dobrým zadáním problému uživatel i programátor jasně a jednoznačně představují úkol, který má být proveden, tzn. v tomto případě jsou brány v úvahu zájmy uživatele i programátora. Uživatel může naplánovat použití softwaru, který ještě nebyl vytvořen, na základě znalostí, které může. Dobré vyjádření problému slouží jako základ pro formování jeho řešení.
Formulace problému (specifikace programu); v podstatě znamená přesný, úplný a srozumitelný popis toho, co se stane, když je konkrétní program spuštěn. Uživatel se na počítač obvykle dívá jako na černou skříňku: nezáleží mu na tom, jak počítač funguje, ale je důležité, aby počítač uměl to, co uživatele zajímá. Důraz je kladen na interakci mezi člověkem a strojem.
Charakteristika dobrého prohlášení o problému:
Přesnost, tj. vyloučení jakékoli nejednoznačnosti. Nemělo by být pochyb o tom, jaký bude výstup programu pro daný vstup.
úplnost, tj. zvážení všech možností pro daný vstup, včetně chybného nebo neočekávaného vstupu, a určení vhodného výstupu.
Jasnost, tj. měl by být srozumitelný jak uživateli, tak systémovému analytikovi, protože prohlášení o problému je jedinou smlouvou mezi nimi.
Často jsou požadavky na přesnost, úplnost a jasnost v rozporu. Mnohé právní dokumenty jsou tedy obtížně srozumitelné, protože jsou psány formálním jazykem, který umožňuje formulovat určitá ustanovení s maximální přesností, s vyloučením i těch nejnepatrnějších nesrovnalostí. Například některé otázky na zkouškových písemkách jsou někdy formulovány tak přesně, že student tráví více času pochopením otázky, než jejím zodpovězením. Student navíc nemusí vůbec pochopit hlavní smysl otázky kvůli velkému množství detailů. Nejlepší problémové prohlášení je takové, které dosahuje rovnováhy všech tří požadavků.
Standardní forma prohlášení o problému.
Zvažte následující prohlášení problému: "Zadejte tři čísla a vytiskněte čísla v pořadí."
Takové prohlášení nesplňuje výše uvedené požadavky: není ani přesné, ani úplné, ani srozumitelné. Opravdu, měla by být čísla zadávána jedno na řádek, nebo všechna čísla na jednom řádku? Znamená výraz „v pořadí“ řazení od největšího k nejmenšímu, od nejmenšího k největšímu nebo stejné pořadí, v jakém byly uvedeny?
Je zřejmé, že takové tvrzení na mnoho otázek neodpovídá. Vezmeme-li v úvahu odpovědi na všechny otázky, pak se problémové prohlášení stane rozvláčným a těžko srozumitelným. D. Riley proto navrhuje pro zadání problému použít standardní formulář, který zajišťuje maximální přesnost, úplnost, přehlednost a obsahuje:
název úlohy (definice schématu);
obecný popis (stručné vyjádření úkolu);
chyby (neobvyklé možnosti vstupu jsou výslovně uvedeny, aby uživatelům a programátorům ukázaly akce, které stroj v takových situacích provede);
příklad (dobrý příklad může sdělit podstatu problému, stejně jako ilustrovat různé případy).
Příklad. Vyjádření problému ve standardním formuláři.
TITUL
Seřaďte tři celá čísla.
POPIS
Vstup a výstup tří celých čísel, seřazených od nejmenšího po největší.
Zadávají se tři celá čísla, jedno číslo na řádek. V tomto případě je celé číslo jedna nebo více po sobě jdoucích desetinných číslic, kterým může předcházet znaménko plus „+“ nebo znaménko mínus „-“.
Vyjdou tři zadaná celá čísla, přičemž všechna tři se zobrazí na stejném řádku. Sousední čísla jsou oddělena mezerou. Čísla se zobrazují od nejmenšího po největší, zleva doprava.
1) Pokud zadáte méně než tři čísla, program čeká na další zadání.
2) Jiné vstupní řádky než první tři jsou ignorovány.
3) Pokud některý z prvních tří řádků obsahuje více než jedno celé číslo, program se ukončí a vydá zprávu.
Anotace.
Úvod.
1. Životní cyklus softwaru
Úvod.
Kroky procesu programování Riley
Úvod.
1.1.1. Formulace problému.
1.1.2. Návrh řešení.
1.1.3. Kódování algoritmů.
1.1.4. Programová podpora.
1.1.5. Softwarová dokumentace.
Závěr k odstavci 1.1
1.2. Definice ZhTsPO podle Lehmana.
Úvod.
1.2.1 Definice systému.
1.2.2. Implementace.
1.2.3. Servis.
Závěr k bodu 1.2.
1.3. Fáze a práce programu životního cyklu podle Boehma
1.3.1. kaskádový model.
1.3.2. Ekonomické zdůvodnění kaskádového modelu.
1.3.3. Vylepšení kaskádového modelu.
1.3.4. Definice fází životního cyklu.
1.3.5. Základní práce na projektu.
Literatura.
Úvod
Průmyslové využití počítačů a rostoucí poptávka po programech kladou naléhavé úkoly pro výrazný nárůst produktivitu vývoje softwaru, vývoj průmyslových metod pro plánování a navrhování programů, přenos organizačních, technických, technických, ekonomických a sociálně psychologických metod, vzorů a metod ze sféry materiálové výroby do sféry počítačů. Komplexní přístup do procesů vývoje, provozu a údržby softwaru klade řadu naléhavých problémů, jejichž řešením se odstraní „úzká místa“ při navrhování programů, zkrátí se doba dokončení, zlepší se výběr a přizpůsobení stávajících programů a možná určí osud systémů s vestavěnými počítači.
V praxi vývoje velkých softwarových projektů často neexistuje jednotný přístup k hodnocení mzdových nákladů, termínů práce a materiálových nákladů, což brání zvýšení produktivity vývoje softwaru a v konečném důsledku i efektivnímu řízení životního cyklu softwaru. Vzhledem k tomu, že se program jakéhokoli typu stává produktem (snad kromě vzdělávacích, maketových programů), přístup k jeho výrobě by měl být v mnoha ohledech podobný přístupu k výrobě průmyslových produktů a otázky návrhu softwaru se stávají extrémně důležité. . Tato myšlenka je základem B.U. Boehm "Engineering Software Design", který jsme použili při psaní této semestrální práce. V této knize se návrhem softwaru rozumí proces vytváření návrhu softwarového produktu.
1 Životní cyklus softwaru
ÚVOD
LCPE je nepřetržitý proces, který začíná okamžikem rozhodnutí o nutnosti vytvořit software a končí okamžikem jeho úplného vyřazení z provozu.
Existuje několik přístupů k definování fází a činností životního cyklu softwaru (SLLC), programovacích procesních kroků, vodopádových a spirálových modelů. Všechny ale obsahují společné základní komponenty: prohlášení o problému, návrh řešení, implementace, údržba.
Nejznámější a nejúplnější je snad struktura životního cyklu podle Boehma, která zahrnuje osm fází. Podrobněji bude představen později.
Jednou z možných variant může být popis horní úrovně podle Lehmana, který zahrnuje tři hlavní fáze a představuje popis programu životního cyklu v nejobecnějším případě.
A zde jsou pro změnu kroky programovacího procesu prezentované D. Rileyem v knize „Using the Modula-2 Language“. Tato myšlenka je podle mého názoru velmi jednoduchá a známá a začneme s ní.
1.1 Kroky procesu programování Riley
Proces programování zahrnuje čtyři kroky (obr. 1):
prohlášení o problému, tzn. získání dostatečné představy o tom, jaký úkol by měl program vykonávat;
navržení řešení již nastoleného problému (obecně je takové řešení méně formální než konečný program);
programové kódování, tj. překlad navrženého řešení do programu, který lze spustit na stroji;
programová podpora, tzn. pokračující proces oprav chyb v programu a přidávání nových funkcí.
Rýže. 1.Čtyři kroky programování.
Programování začíná od okamžiku, kdy uživatel, tj. někdo, kdo potřebuje program k vyřešení problému, představuje problém systémový analytik. Uživatel a systémový analytik společně definují prohlášení o problému. Ten se pak přenese algoritmista kdo je zodpovědný za návrh řešení. Řešení (neboli algoritmus) je posloupnost operací, jejichž provedení vede k vyřešení problému. Protože algoritmus často není uzpůsoben k provádění na počítači, měl by být přeložen do strojového programu. Tuto operaci provádí kodér. Za následné změny programu zodpovídá doprovodný programátor. A systémový analytik, algoritmus, kodér a doprovodný programátor – všichni jsou programátoři.
V případě velkého softwarového projektu může být počet uživatelů, systémových analytiků a algoritmů významný. Kromě toho může být nutné vrátit se k předchozím krokům kvůli nepředvídaným okolnostem. To vše slouží jako další argument ve prospěch pečlivého návrhu softwaru: výsledky každého kroku by měly být úplné, přesné a srozumitelné.
1.1.1 Popis problému
Jedním z nejdůležitějších kroků při programování je nastavení problému. Funguje jako smlouva mezi uživatelem a programátorem (programátory). Stejně jako právně špatně zpracovaná smlouva je špatné prohlášení o poslání k ničemu. S dobrým zadáním problému uživatel i programátor jasně a jednoznačně představují úkol, který má být proveden, tzn. v tomto případě jsou brány v úvahu zájmy uživatele i programátora. Uživatel může naplánovat použití softwaru, který ještě nebyl vytvořen, na základě znalostí, které může. Dobré vyjádření problému slouží jako základ pro formování jeho řešení.
Formulace problému (specifikace programu); v podstatě znamená přesný, úplný a srozumitelný popis toho, co se stane, když je konkrétní program spuštěn. Uživatel se na počítač obvykle dívá jako na černou skříňku: nezáleží mu na tom, jak počítač funguje, ale je důležité, aby počítač uměl to, co uživatele zajímá. Důraz je kladen na interakci mezi člověkem a strojem.
Charakteristika dobrého prohlášení o problému:
Přesnost, tj. vyloučení jakékoli nejednoznačnosti. Nemělo by být pochyb o tom, jaký bude výstup programu pro daný vstup.
úplnost, tj. zvážení všech možností pro daný vstup, včetně chybného nebo neočekávaného vstupu, a určení vhodného výstupu.
Jasnost, tj. měl by být srozumitelný jak uživateli, tak systémovému analytikovi, protože prohlášení o problému je jedinou smlouvou mezi nimi.
Často jsou požadavky na přesnost, úplnost a jasnost v rozporu. Mnohé právní dokumenty jsou tedy obtížně srozumitelné, protože jsou psány formálním jazykem, který umožňuje formulovat určitá ustanovení s maximální přesností, s vyloučením i těch nejnepatrnějších nesrovnalostí. Například některé otázky na zkouškových písemkách jsou někdy formulovány tak přesně, že student tráví více času pochopením otázky, než jejím zodpovězením. Student navíc nemusí vůbec pochopit hlavní smysl otázky kvůli velkému množství detailů. Nejlepší problémové prohlášení je takové, které dosahuje rovnováhy všech tří požadavků.
Standardní forma prohlášení o problému.
Zvažte následující prohlášení problému: "Zadejte tři čísla a vytiskněte čísla v pořadí."
Takové prohlášení nesplňuje výše uvedené požadavky: není ani přesné, ani úplné, ani srozumitelné. Opravdu, měla by být čísla zadávána jedno na řádek, nebo všechna čísla na jednom řádku? Znamená výraz „v pořadí“ řazení od největšího k nejmenšímu, od nejmenšího k největšímu nebo stejné pořadí, v jakém byly uvedeny?
Je zřejmé, že takové tvrzení na mnoho otázek neodpovídá. Vezmeme-li v úvahu odpovědi na všechny otázky, pak se problémové prohlášení stane rozvláčným a těžko srozumitelným. D. Riley proto navrhuje pro zadání problému použít standardní formulář, který zajišťuje maximální přesnost, úplnost, přehlednost a obsahuje:
název úlohy (definice schématu);
obecný popis (stručné vyjádření úkolu);
chyby (neobvyklé možnosti vstupu jsou výslovně uvedeny, aby uživatelům a programátorům ukázaly akce, které stroj v takových situacích provede);
příklad (dobrý příklad může sdělit podstatu problému, stejně jako ilustrovat různé případy).
Příklad. Vyjádření problému ve standardním formuláři.
TITUL
Seřaďte tři celá čísla.
POPIS
Vstup a výstup tří celých čísel, seřazených od nejmenšího po největší.
Zadávají se tři celá čísla, jedno číslo na řádek. V tomto případě je celé číslo jedna nebo více po sobě jdoucích desetinných číslic, kterým může předcházet znaménko plus „+“ nebo znaménko mínus „-“.
Vyjdou tři zadaná celá čísla, přičemž všechna tři se zobrazí na stejném řádku. Sousední čísla jsou oddělena mezerou. Čísla se zobrazují od nejmenšího po největší, zleva doprava.
1) Pokud zadáte méně než tři čísla, program čeká na další zadání.
Dne 1. března 2012 přijala Federální agentura pro technickou regulaci a metrologii Ruské federace normu GOST R ISO/IEC 12207-2010 „Informační technologie. Systémové a softwarové inženýrství. Procesy životního cyklu softwaru“, shodné s mezinárodní normou ISO/IEC 12207:2008 „Systémové a softwarové inženýrství – Procesy životního cyklu softwaru“.
Tato norma, používající zavedenou terminologii, vytváří společný rámec pro procesy životního cyklu softwaru, který lze použít jako vodítko v softwarovém průmyslu. Norma definuje procesy, činnosti a úkoly, které se používají při pořízení softwarového produktu nebo služby, jakož i při dodání, vývoji, zamýšleném použití, údržbě a ukončení výroby softwarových produktů.
Procesy životního cyklu softwaru
Norma seskupuje různé činnosti, které lze provádět během životního cyklu softwarových systémů, do sedmi skupin procesů. Každý z procesů životního cyklu v rámci těchto skupin je popsán z hlediska účelu a požadovaných výstupů, seznamů akcí a úkolů, které je třeba provést k dosažení těchto výsledků.
- dohodové procesy - dva procesy;
- procesy organizační podpory projektu - pět procesů;
- projektové procesy - sedm procesů;
- technické procesy - jedenáct procesů;
- procesy implementace softwaru - sedm procesů;
- procesy softwarové podpory – osm procesů;
- procesy opětovného použití softwaru – tři procesy.
- Hlavní:
- Akvizice (akce a úkoly zákazníka nakupujícího software)
- Dodávka (činnosti a úkoly dodavatele, který zákazníkovi dodává softwarový produkt nebo službu)
- Vývoj (akce a úkoly prováděné vývojářem: tvorba softwaru, vypracování projektové a provozní dokumentace, příprava testovacích a školicích materiálů atd.)
- Provoz (činnosti a úkoly provozovatele - organizace provozující systém)
- Údržba (úkony a úkoly prováděné doprovázející organizací, tj. údržbářskou službou). Údržba – provádění změn v softwaru za účelem opravy chyb, zlepšení výkonu nebo přizpůsobení měnícím se provozním podmínkám nebo požadavkům.
- Pomocný
- Dokumentace (formalizovaný popis informací vytvořených během životního cyklu softwaru)
- Správa konfigurací (aplikace administrativních a technických postupů v průběhu životního cyklu softwaru pro zjištění stavu softwarových komponent, řízení jeho úprav).
- Zajištění kvality (zajištění, aby IS a procesy jeho životního cyklu odpovídaly stanoveným požadavkům a schváleným plánům)
- Ověření (určení, že softwarové produkty, které jsou výsledkem nějaké akce, plně splňují požadavky nebo podmínky kvůli předchozím akcím)
- Certifikace (zjištění úplnosti shody zadaných požadavků a vytvořeného systému s jejich konkrétním funkčním účelem)
- Společné hodnocení (posouzení stavu prací na projektu: kontrola plánování a řízení zdrojů, personálu, vybavení, nástrojů)
- Audit (zjištění souladu s požadavky, plány a podmínkami smlouvy)
- Řešení problémů (analýza a řešení problémů, bez ohledu na jejich původ nebo zdroj, které se objeví během vývoje, provozu, údržby nebo jiných procesů)
- Organizační
- Management (činnosti a úkoly, které může provádět kterákoli strana řídící jejich procesy)
- Vytvoření infrastruktury (výběr a údržba technologie, standardů a nástrojů, výběr a instalace hardwaru a softwaru používaného k vývoji, provozu nebo údržbě softwaru)
- Zlepšení (posuzování, měření, kontrola a zlepšování procesů životního cyklu)
- Školení (úvodní školení a následný průběžný rozvoj zaměstnanců)
Každý proces zahrnuje řadu činností. Například proces akvizice zahrnuje následující kroky:
- Zahájení akvizice
- Příprava nabídek
- Příprava a úprava smlouvy
- Dohled dodavatele
- Převzetí a dokončení práce
Každá akce obsahuje řadu úkolů. Příprava nabídek by měla například zahrnovat:
- Tvorba požadavků na systém
- Vytvoření seznamu softwarových produktů
- Stanovení podmínek a dohod
- Popis technických omezení (prostředí provozu systému atd.)
Fáze životního cyklu softwaru, vztah mezi procesy a fázemi
Model životního cyklu softwaru- struktura, která určuje posloupnost provádění a vztah procesů, akcí a úkolů v průběhu životního cyklu. Model životního cyklu závisí na specifikách, rozsahu a složitosti projektu a konkrétních podmínkách, ve kterých systém vzniká a funguje.
Norma GOST R ISO/IEC 12207-2010 nenabízí konkrétní model životního cyklu. Jeho ustanovení jsou společná pro všechny modely životního cyklu, metody a technologie pro vytváření IP. Popisuje strukturu procesů životního cyklu, aniž by specifikoval, jak implementovat nebo vykonávat činnosti a úkoly zahrnuté v těchto procesech.
Model životního cyklu softwaru zahrnuje:
- etapy;
- Výsledky práce v každé fázi;
- Klíčové události - body dokončení práce a rozhodování.
