Концепцията за жизнения цикъл на софтуера. Жизнен цикъл на софтуерните системи

Анотация.

Въведение.

1. Жизнен цикъл на софтуера

Въведение.

Стъпки на процеса на програмиране на Riley

Въведение.

1.1.1. Формулиране на проблема.

1.1.2. Дизайн на решение.

1.1.3. Алгоритъм за кодиране.

1.1.4. Програмна поддръжка.

1.1.5. Софтуерна документация.

Заключение към клауза 1.1

1.2. Определяне на LCPO според Lehman.

Въведение.

1.2.1 Дефиниция на системата.

1.2.2. Внедряване.

1.2.3. Обслужване.

Заключение към клауза 1.2.

1.3. Фази и работа на LCPO по Boehm

1.3.1. Каскаден модел.

1.3.2. Икономическа обосновка на каскадния модел.

1.3.3. Усъвършенстване на каскадния модел.

1.3.4. Определяне на фазите на жизнения цикъл.

1.3.5. Основна работа по проекта.

Литература.

Въведение

Индустриалната употреба на компютри и нарастващото търсене на програми поставиха спешни предизвикателства, които трябва значително да се увеличат производителност при разработване на софтуер, разработване на индустриални методи за планиране и проектиране на програми, прехвърляне на организационни, технически, технически, икономически и социално-психологически техники, модели и методи от сферата на материалното производство към сферата на използването на компютър. Комплексен подходкъм процесите на разработка, експлоатация и поддръжка на софтуер, той изложи редица належащи проблеми, чието решение ще премахне пречките в програмния дизайн, ще намали времето за завършване на работата, ще подобри избора и адаптирането на съществуващи програми и може би ще определи съдбата на системите с вградени компютри.

В практиката на разработване на големи софтуерни проекти често няма единен подходдо оценка на разходите за труд, срокове за работа и разходи за материали, което възпрепятства увеличаването на производителността на разработката на софтуер и в крайна сметка ефективното управление на жизнения цикъл на софтуера. Тъй като програма от всякакъв тип се превръща в продукт (с изключение, може би, на образователни, прототипни програми), подходът към нейното производство трябва в много отношения да бъде подобен на подхода към производството на промишлени продукти и въпросите за програмния дизайн стават изключително важни. Тази идея е в основата на книгата на B.W. Boehm „Софтуерно инженерство“, който използвахме при писането на тази курсова работа. В тази книга софтуерният дизайн се отнася до процеса на създаване на дизайн за софтуерен продукт.

1 Жизнен цикъл на софтуера

ВЪВЕДЕНИЕ

LCPO е непрекъснат процес, който започва от момента, в който се вземе решение за необходимостта от създаване на софтуер и завършва в момента, в който той бъде напълно премахнат от обслужване.

Има няколко подхода за определяне на фазите и дейностите на жизнения цикъл на софтуера (SLC), стъпките на процеса на програмиране, каскадни и спирални модели. Но всички те съдържат общи фундаментални компоненти: изявление на проблема, дизайн на решение, внедряване, поддръжка.

Най-известната и пълна може би е структурата на процеса на жизнения цикъл според Boehm, която включва осем фази. Той ще бъде представен по-подробно в бъдеще.

Един от възможните варианти може да бъде описание от най-високо ниво според Lehman, което включва три основни фази и представлява описание на жизнения цикъл в най-общия случай.

И за разнообразие представяме стъпките на процеса на програмиране, представени от Д. Райли в книгата „Използване на езика Modula-2“. Тази идея според мен е много проста и позната и нека започнем с нея.

1.1 Стъпки в процеса на програмиране на Riley

Въведение

Процесът на програмиране включва четири стъпки (Фигура 1):

постановка на проблема, т.е. получаване на адекватно разбиране за това каква задача трябва да изпълнява програмата;

проектиране на решение на вече заявен проблем (като цяло такова решение е по-малко формално от окончателната програма);

програмно кодиране, т.е. преобразуване на проектираното решение в програма, която може да се изпълнява на машина;

програмна поддръжка, т.е. текущия процес на отстраняване на неизправности в програмата и добавяне на нови функции.

Ориз. 1. Четири стъпки на програмиране.

Програмирането започва от момента, в който потребител, т.е. някой, който се нуждае от програма за решаване на проблем, заявява проблема системен анализатор.Потребителят и системният анализатор съвместно определят формулировката на проблема. След това последният се предава алгоритмист, който отговаря за проектирането на решението. Решението (или алгоритъмът) представлява последователност от операции, чието изпълнение води до решение на даден проблем. Тъй като алгоритъмът често не е подходящ за изпълнение на машина, той трябва да бъде преведен в машинна програма. Тази операция се извършва от енкодера. Поддръжката носи отговорност за последващи промени в програмата. програмист. И системният анализатор, и алгоритмистът, и енкодерът, и придружаващият го програмист – всички те са програмисти.

В случай на голям софтуерен проект броят на потребителите, системните анализатори и алгоритмистите може да бъде значителен. Освен това може да се наложи да се върнете към предишни стъпки поради непредвидени обстоятелства. Всичко това служи като допълнителен аргумент за внимателен дизайн на софтуера: резултатите от всяка стъпка трябва да бъдат пълни, точни и разбираеми.

1.1.1 Постановка на проблема

Една от най-важните стъпки в програмирането е дефинирането на проблема. Функционира като договор между потребителя и програмиста(ите). Подобно на зле изготвен от правна гледна точка договор, лошо написаната декларация за проблема е безполезна. С добра формулировка на проблема и потребителят, и програмистът ясно и недвусмислено представят задачата, която трябва да бъде изпълнена, т.е. в този случай се вземат предвид интересите както на потребителя, така и на програмиста. Потребителят може да планира да използва софтуер, който все още не е създаден, въз основа на знанието за това какво може да прави. Доброто изложение на проблема служи като основа за формулиране на неговото решение.

Формулиране на проблема (програмна спецификация); по същество означава точно, пълно и разбираемо описание на това, което се случва, когато се изпълнява конкретна програма. Потребителят обикновено гледа на компютъра като на черна кутия: за него няма значение как работи компютърът, а важното е какво може да направи компютърът, което интересува потребителя. В този случай основното внимание е насочено към взаимодействието на човека с машината.

Характеристики на добра формулировка на проблем:

точност, т.е. елиминиране на всяка неяснота. Не трябва да има съмнение какъв ще бъде изходът на програмата за даден вход.

Пълнота, т.е. разглеждане на всички опции за даден вход, включително погрешно или непреднамерено въвеждане, и определяне на подходящия изход.

Яснота, т.е. то трябва да бъде разбираемо както за потребителя, така и за системния анализатор, тъй като формулировката на проблема е единственият договор между тях.

Често изискванията за точност, пълнота и яснота са в конфликт. По този начин много правни документи са трудни за разбиране, тъй като са написани на официален език, което позволява определени разпоредби да бъдат формулирани с изключителна точност, изключвайки всякакви незначителни несъответствия. Например някои въпроси в изпитните работи понякога са формулирани толкова точно, че студентът прекарва повече време в разбиране на въпроса, отколкото в отговор. Освен това ученикът може дори да не разбере основното значение на въпроса поради големия брой подробности. Най-добрата формулировка на проблема е тази, която постига баланс и на трите изисквания.

Стандартна форма на изложение на проблема.

Помислете за следното изложение на проблем: „Въведете три числа и изведете числата по ред.“

Такова твърдение не отговаря на горните изисквания: то не е нито точно, нито пълно, нито разбираемо. Наистина, трябва ли числата да се въвеждат по едно на ред или всички числа на един ред? Дали изразът "по ред" означава подреждане от най-голямото към най-малкото, от най-малкото към най-голямото или същия ред, в който са въведени.

Очевидно подобно твърдение не отговаря на много въпроси. Ако вземем предвид отговорите на всички въпроси, тогава изложението на проблема ще стане многословно и трудно за разбиране. Затова Д. Райли предлага да се използва стандартна форма за поставяне на проблема, която гарантира максимална точност, пълнота, яснота и включва:

име на задачата (схематично определение);

общо описание (кратко резюме на задачата);

грешки (необичайните опции за въвеждане са изрично изброени, за да покажат на потребителите и програмистите какви действия би предприела машината в такива ситуации);

пример (добрият пример може да предаде същността на проблема и също така да илюстрира различни случаи).

Пример. Изложение на проблема в стандартна форма.

ИМЕ

Сортиране на три цели числа.

ОПИСАНИЕ

Вход и изход на три цели числа, сортирани от най-малкото към най-голямото число.

Въвеждат се три цели числа, по едно на ред. Цяло число е една или повече последователни десетични цифри, които могат да бъдат предшествани от знак плюс „+“ или знак минус „–“.

Трите въведени цели числа се отпечатват, като и трите се отпечатват на един ред. Съседните числа са разделени с интервал. Числата се показват от най-малкото към най-голямото, отляво надясно.

1) Ако са въведени по-малко от три числа, програмата изчаква допълнително въвеждане.

2) Входни редове, различни от първите три, се игнорират.

Жизнен цикъле модел за създаване и използване на софтуерна система. Той отразява различните състояния на софтуерната система, като се започне от момента, в който възниква необходимостта от тази софтуерна система и се вземе решение за нейното създаване, и се стигне до пълното изтегляне на софтуерната система от експлоатация.

Международният стандарт ISOIES 12207 дефинира рамка на жизнения цикъл, съдържаща процесите, дейностите и задачите, които трябва да бъдат изпълнени по време на създаването на софтуер. Съгласно този стандарт жизненият цикъл на софтуера се основава на три групи процеси:

основните процеси на жизнения цикъл, т.е. придобиване, доставка, развитие, експлоатация и поддръжка;

спомагателни процеси, които осигуряват изпълнението на основните процеси, тоест документиране, проверка, сертифициране, оценка на качеството и други;

организационни процеси, т.е. управление на проекти, създаване на проектна инфраструктура и обучение.

Разработката включва цялата работа по създаване на софтуер в съответствие с определени изисквания. Това включва изготвяне на проектна и експлоатационна документация, подготовка на материали, необходими за тестване на функционалността и качеството на софтуерните продукти.

Основни етапи на процеса на разработка:

анализ на изискванията на клиента;

дизайн;

изпълнение (програмиране).

Процесът на експлоатация включва работа по въвеждане в експлоатация на софтуера, включително конфигуриране на работни станции, обучение на персонал, локализиране на оперативни проблеми и отстраняване на причините за възникването им, модифициране на софтуера в рамките на установените разпоредби и изготвяне на предложения за модернизация на системата.

Всеки процес се характеризира с определени задачи и методи за решаването им, както и с изходни данни и резултати.

Жизненият цикъл на софтуера по правило има итеративен характер, т.е. изпълняват се етапи, започвайки от най-ранните, които се повтарят циклично в съответствие с променящите се изисквания на външните условия и въвеждането на ограничения.

Модели на жизнения цикъл на софтуера

Има няколко модела на жизнения цикъл, които определят реда на изпълнение на етапите на разработка и критериите за преминаване от етап на етап. Към днешна дата най-разпространени са два модела на жизнения цикъл: каскадаИ спирала.

В съществуващите преди това хомогенни информационни системи всяко приложение беше едно цяло. За разработването на такива приложения е използван модел на жизнения цикъл на водопада, наречен още класическиили водопад.

Когато се използва моделът на водопада, развитието се разглежда като последователност от етапи, като преходът към следващия по-нисък етап се извършва само след като цялата работа на текущия етап е напълно завършена. Изводът е, че в модела на водопада разработката започва на системно ниво и преминава през анализ, проектиране, кодиране, тестване и поддръжка.

Фигура 1 – Основни етапи на разработване на каскаден модел

1. Системният анализ определя ролята на всеки елемент в компютърната система и взаимодействието на елементите един с друг. Тъй като софтуерът се разглежда като част от по-голяма система, анализът започва с определяне на изискванията за всички елементи на системата. Необходимостта от системен анализ ясно се проявява, когато се формира интерфейсът на софтуера с други елементи, т.е. с хардуер или бази данни. На същия етап започва решаването на проблемите с планирането на проекта. При планирането на проекта се определят обемът на работата по проекта и неговият риск, необходимите разходи за труд, формират се работни задачи и работен график.

Анализът на изискванията се отнася до един софтуерен елемент. На този етап се изясняват и детайлизират функциите на всеки елемент, неговите характеристики и интерфейс. На същия етап е завършено решението на проблема с планирането на проекта.

2. Дизайнът се състои в създаване на:

софтуерни архитектури;

модулна структура на софтуера;

алгоритмична структура на софтуера;

структури от данни;

входно/изходен интерфейс (форми за входно/изходни данни).

При решаването на дизайнерски проблеми основно внимание се обръща на качеството на бъдещия софтуерен продукт.

3. Кодирането или разработката се състои от превеждане на резултатите от дизайна в програмен код.

4. Тестване е изпълнение на програма за установяване на дефекти във функциите, логиката и формата на изпълнение на програмния продукт.

5. Поддръжката е извършване на промени в операционния софтуер с цел:

изчистване на бъгове;

адаптиране към промени във външната за софтуера среда;

подобряване на софтуера в съответствие с изискванията на клиента.

Предимства на използването на каскадния модел:

дава план и график за всички етапи на проекта, като по този начин рационализира напредъка на разработката;

на всеки етап се генерира пълен комплект проектна документация, проверена за пълнота и последователност;

етапите на работа, извършени в логическа последователност, позволяват да се планира времето за завършване на цялата работа и съответните разходи.

Каскадният модел се е доказал добре при изграждането на информационни системи, за които в самото начало на разработката е възможно доста точно да се формулират всички изисквания в системата, например сложни изчислителни системи, различни системи в реално време и др. .

Недостатъци на каскадния модел:

реалните проекти често изискват отклонения от стандартната последователност от стъпки;

каскадният модел се основава на точната формулировка на първоначалните софтуерни изисквания, но в действителност в редица случаи в началото на проекта изискванията на клиента са само частично определени;

резултатите от проекта са достъпни за клиента само след приключване на цялата работа.

Поради необходимостта в процеса на създаване на софтуер постоянно да се връща към предишни етапи и да изяснява или преразглежда предварително взети решения, реалният процес на разработка на софтуер, базиран на водопадния модел, може да бъде представен чрез следната диаграма (фиг. 2).

Фигура 2 – Процес на разработка на софтуер, базиран на модела на водопада

Стандарти за жизнения цикъл на софтуера

ГОСТ 34.601-90
ISO/IEC 12207:1995 (руски еквивалент - GOST R ISO/IEC 12207-99)

Методологии за разработка на софтуер

Рационален унифициран процес (RUP).
Microsoft Solutions Framework (MSF). Включва 4 фази: анализ, проектиране, развитие, стабилизиране, включва използването на обектно-ориентирано моделиране.
Екстремно програмиране ( Екстремно програмиране, XP). Методологията се основава на екипна работа и ефективна комуникация между клиента и изпълнителя през целия проект за развитие на IP. Разработката се извършва чрез последователно усъвършенствани прототипи.

Стандарт GOST 34.601-90

Стандартът GOST 34.601-90 предвижда следните етапи и етапи на създаване на автоматизирана система:

Формиране на изисквания към ораторите
1. Обследване на съоръжението и обосновка на необходимостта от създаване на атомна електроцентрала
2. Формиране на потребителски изисквания към високоговорителите
3. Изготвяне на доклад за изпълнение на работата и заявка за разработване на АЕЦ
Развитие на AC концепцията
1. Проучване на обекта
2. Извършване на необходимата изследователска работа
3. Разработване на варианти за концепция за климатик и избор на вариант за концепция за климатик, който отговаря на изискванията на потребителите
4. Изготвяне на протокол за извършената работа
Техническо задание
1. Разработване и одобряване на технически спецификации за създаване на атомни електроцентрали
Идеен проект
1. Разработване на идейни проектни решения за системата и нейните части
Технически проект
1. Разработване на проектни решения за системата и нейните части
2. Разработване на документация за системата за високоговорители и нейните части
3. Разработване и изпълнение на документация за доставка на компоненти
4. Разработване на задания за проектиране в съседни части на проекта
Работна документация
1. Разработване на работна документация за АЕЦ и нейните части
2. Разработване и адаптиране на програми
Въвеждане в експлоатация
1. Подготовка на обект за автоматизация
2. Обучение на персонала
3. Пълен комплект високоговорители с доставени продукти (софтуер и хардуер, софтуерни и хардуерни системи, информационни продукти)
4. СМР
5. Пусконаладъчни работи
6. Провеждане на предварителни тестове
7. Провеждане на пробна експлоатация
8. Провеждане на приемни тестове
AC поддръжка.
1. Извършване на работа в съответствие с гаранционните задължения
2. Следгаранционен сервиз

Скица, технически проекти и работна документация са последователното изграждане на все по-точни проектни решения. Възможно е да се изключи етапът „Ескизен проект“ и отделните етапи на работа на всички етапи, да се комбинират етапите „Технически проект“ и „Работна документация“ в „Технически работен проект“, да се извършат различни етапи и да се работи паралелно , и да включва допълнителни.

Този стандарт не е напълно подходящ за текущите разработки: много процеси не са достатъчно отразени и някои разпоредби са остарели.

Стандарт ISO/IEC 12207/ и неговото приложение

Стандартът ISO/IEC 12207:1995 „Информационни технологии – Процеси на жизнения цикъл на софтуера“ е основният нормативен документ, регулиращ състава на процесите на жизнения цикъл на софтуера. Той определя структура на жизнения цикъл, съдържаща процесите, дейностите и задачите, които трябва да бъдат изпълнени по време на създаването на софтуер.

Всеки процес е разделен на набор от действия, всяко действие на набор от задачи. Всеки процес, дейност или задача се инициира и изпълнява от друг процес според нуждите и няма предварително определени последователности за изпълнение. Връзките между входните данни се запазват.

Процеси на жизнения цикъл на софтуера

Основен:
- Придобиване (действия и задачи на клиента, закупуващ софтуера)
- Доставка (действия и задачи на доставчика, който доставя на клиента софтуерен продукт или услуга)
- Разработка (действия и задачи, изпълнявани от разработчика: създаване на софтуер, подготовка на проектна и експлоатационна документация, подготовка на тестови и обучителни материали и др.)
- Експлоатация (действия и задачи на оператора - организацията, управляваща системата)
- Поддръжка (действия и задачи, изпълнявани от придружаващата организация, т.е. службата за поддръжка). Поддръжка - извършване на промени в софтуера с цел коригиране на грешки, подобряване на производителността или адаптиране към променени работни условия или изисквания.
Помощни
- Документация (формализирано описание на информацията, създадена по време на жизнения цикъл на софтуера)
- Управление на конфигурацията (прилагане на административни и технически процедури през целия жизнен цикъл на софтуера за определяне на състоянието на софтуерните компоненти и управление на неговите модификации).
- Осигуряване на качеството (предоставяне на гаранции, че информационната система и процесите на нейния жизнен цикъл отговарят на определени изисквания и одобрени планове)
- Проверка (определяне, че софтуерните продукти, произтичащи от някакво действие, напълно отговарят на изискванията или условията, наложени от предишни действия)
- Сертифициране (определяне на пълното съответствие на зададените изисквания и създадената система с тяхното специфично функционално предназначение)
- Съвместна оценка (оценка на състоянието на работата по проекта: контрол на планирането и управлението на ресурси, персонал, оборудване, инструменти)
- Одит (определяне на съответствие с изискванията, плановете и условията на договора)
- Решаване на проблеми (анализ и разрешаване на проблеми, независимо от техния произход или източник, които са открити по време на разработка, експлоатация, поддръжка или други процеси)
Организационни
- Контрол (действия и задачи, които могат да се изпълняват от всяка страна, управляваща нейните процеси)
- Създаване на инфраструктура (избор и поддръжка на технология, стандарти и инструменти, избор и инсталиране на хардуер и софтуер, използвани за разработване, експлоатация или поддръжка на софтуер)
- Подобряване (оценка, измерване, контрол и подобряване на процесите на жизнения цикъл)
- Обучение (първоначално обучение и последващо продължаващо развитие на персонала)

Всеки процес включва редица действия. Например, процесът на придобиване обхваща следните дейности:

Иницииране на придобиване
Изготвяне на тръжни предложения
Изготвяне и коригиране на договора
Надзор на дейността на доставчика
Приемане и завършване на работата

Всяка дейност включва редица задачи. Например подготовката на офертите трябва да включва:

Формиране на системни изисквания
Генериране на списък от софтуерни продукти
Установяване на условия и споразумения
Описание на техническите ограничения (операционна среда на системата и др.)

Етапи от жизнения цикъл на софтуера, връзки между процеси и етапи

Модел на жизнения цикъл на софтуера- структура, която определя последователността на изпълнение и връзките между процесите, действията и задачите през целия жизнен цикъл. Моделът на жизнения цикъл зависи от спецификата, мащаба и сложността на проекта и конкретните условия, в които системата е създадена и функционира.

Стандартът GOST R ISO/IEC 12207-99 не предлага конкретен модел на жизнения цикъл. Неговите разпоредби са общи за всички модели на жизнения цикъл, методи и технологии за създаване на IP. Той описва структурата на процесите от жизнения цикъл, без да уточнява как да се изпълняват или изпълняват дейностите и задачите, включени в тези процеси.

Моделът на жизнения цикъл на софтуера включва:

Етапи;
Резултати от работата на всеки етап;
Ключовите събития са точки на завършване на работа и вземане на решения.

сцена- част от процеса на създаване на софтуер, ограничен от определена времева рамка и завършващ с пускането на конкретен продукт (модели, софтуерни компоненти, документация), определен от изискванията, определени за този етап.

На всеки етап могат да се изпълняват няколко процеса, определени в стандарта GOST R ISO/IEC 12207-99, и обратно, един и същ процес може да се извършва на различни етапи. Връзката между процесите и етапите също се определя от използвания модел на жизнения цикъл на софтуера.

Модели на жизнения цикъл на софтуера

Моделът на жизнения цикъл е структура, която определя последователността на изпълнение и връзките на процесите, дейностите и задачите, изпълнявани през целия жизнен цикъл. Моделът на жизнения цикъл зависи от спецификата на информационната система и конкретните условия, в които тя се създава и функционира

Към днешна дата най-разпространени са следните основни модели на жизнения цикъл:

Проблемен модел;

каскаден модел (или система) (70-85);

спирален модел (настояще).

Проблемен модел

При разработването на система "отдолу-нагоре" от отделни задачи към цялата система (модел на задачата) неизбежно се губи единен подход към развитието и възникват проблеми в информационната връзка на отделните компоненти. Като правило, с увеличаване на броя на задачите, трудностите се увеличават и е необходимо постоянно да се променят съществуващите програми и структури от данни. Скоростта на развитие на системата се забавя, което забавя развитието на самата организация. В някои случаи обаче тази технология може да бъде препоръчителна:

Изключителна спешност (проблемите трябва да бъдат решени по някакъв начин; тогава всичко ще трябва да се направи отново);

Експеримент и адаптиране на клиента (алгоритмите не са ясни, решенията се намират чрез проба и грешка).

Общият извод е, че по този начин е невъзможно да се създаде достатъчно голяма, ефективна информационна система.

Каскаден модел

Каскаден моделжизненият цикъл е предложен през 1970 г. от Уинстън Ройс. Той предвижда последователно изпълнение на всички етапи на проекта в строго фиксиран ред. Преходът към следващия етап означава пълно завършване на работата на предишния етап (фиг. 1). Изискванията, определени на етапа на формиране на изискванията, са строго документирани под формата на технически спецификации и се записват за цялото развитие на проекта. Всеки етап завършва с издаването на пълен набор от документация, достатъчна да позволи разработката да бъде продължена от друг екип за разработка.

Положителните аспекти на използването на каскадния подход са следните:

на всеки етап се генерира пълен набор от проектна документация, която отговаря на критериите за пълнота и последователност;

етапите на работа, извършени в логическа последователност, позволяват да се планира времето за завършване на цялата работа и съответните разходи.

Етапи на проекта според модела на водопада:

Формиране на изисквания;
Дизайн;
внедряване;
Тестване;
внедряване;
Експлоатация и поддръжка.

Ориз. 1. Каскадна схема на развитие

Каскадният подход се е доказал добре при изграждането на информационни системи, за които още в началото на разработката всички изисквания могат да бъдат формулирани доста точно и пълно, за да се даде свободата на разработчиците да ги реализират възможно най-добре от техническа гледна точка. изглед. Сложни изчислителни системи, системи в реално време и други подобни задачи попадат в тази категория. Въпреки това, в процеса на използване на този подход бяха открити редица негови недостатъци, причинени главно от факта, че реалният процес на създаване на системи никога не се вписва напълно в такава твърда схема. По време на процеса на създаване имаше постоянна необходимост от връщане към предишни етапи и изясняване или преразглеждане на взети по-рано решения. В резултат на това действителният процес на създаване на софтуер прие следната форма (фиг. 2):

Ориз. 2. Реален процес на разработка на софтуер с помощта на водопадна схема

Основният недостатък на каскадния подход е значителното забавяне на получаването на резултати. Съгласуването на резултатите с потребителите се извършва само в точки, планирани след завършване на всеки етап от работата; изискванията към информационните системи се „замразяват“ под формата на технически спецификации за цялото време на тяхното създаване. По този начин потребителите могат да правят своите коментари едва след като работата по системата е напълно завършена. Ако изискванията са неточно посочени или се променят в продължение на дълъг период от разработка на софтуер, потребителите в крайна сметка получават система, която не отговаря на техните нужди. Моделите (както функционални, така и информационни) на автоматизирания обект могат да остареят едновременно с тяхното одобрение. Същността на системния подход към развитието на ИС се състои в нейното разлагане (разбиване) на автоматизирани функции: системата се разделя на функционални подсистеми, които от своя страна се разделят на подфункции, подразделят се на задачи и т.н. Процесът на разделяне продължава до конкретни процедури. В същото време автоматизираната система поддържа холистичен поглед, в който всички компоненти са взаимосвързани. Така основното предимство на този модел е системното му развитие, а основните му недостатъци са, че е бавен и скъп.

Спирален модел

За да се преодолеят тези проблеми, беше предложено спираловиден моделжизнен цикъл (Фигура 3), който е разработен в средата на 80-те години от Бари Бьом. Базира се на началните етапи от жизнения цикъл: анализ и проектиране. На тези етапи осъществимостта на техническите решения се тества чрез създаване на прототипи.

Прототип- операционен софтуерен компонент, който реализира отделни функции и външни интерфейси. Всяка итерация съответства на създаването на фрагмент или версия на софтуера, при което се изясняват целите и характеристиките на проекта, оценява се качеството на получените резултати и се планира работата на следващата итерация.

Всяка итерация представлява пълен цикъл на разработка, водещ до пускането на вътрешна или външна версия на продукт (или подмножество от крайния продукт), който се подобрява от итерация на итерация, за да стане цялостна система.

Всеки оборот на спиралата съответства на създаването на фрагмент или версия на софтуера, където се изясняват целите и характеристиките на проекта, определя се неговото качество и се планира работата на следващия оборот на спиралата. Така се задълбочават и последователно уточняват детайлите на проекта и в резултат се избира разумен вариант, който се довежда до изпълнение.

Развитието чрез итерации отразява обективно съществуващия спирален цикъл на създаване на система. Непълното завършване на работата на всеки етап ви позволява да преминете към следващия етап, без да чакате пълното завършване на работата на текущия. С итеративен метод на разработка, липсващата работа може да бъде завършена в следващата итерация. Основната задача е да се покаже на потребителите на системата работещ продукт възможно най-бързо, като по този начин се активира процесът на изясняване и допълване на изискванията.

Основният проблем на спиралния цикъл е определянето на момента на преход към следващия етап. За решаването му е необходимо да се въведат времеви ограничения за всеки етап от жизнения цикъл. Преходът протича по план, дори ако не е завършена цялата планирана работа. Планът е изготвен въз основа на статистически данни, получени в предишни проекти и личен опит на разработчиците.

Фигура 3. Спирален модел на жизнения цикъл на IC

Един възможен подход към разработката на софтуер в рамките на спиралния модел на жизнения цикъл е методологията RAD (Rapid Application Development), която напоследък стана широко разпространена. Този термин обикновено се отнася до процес на разработка на софтуер, съдържащ 3 елемента:

малък екип от програмисти (от 2 до 10 души);

кратък, но внимателно разработен производствен график (от 2 до 6 месеца);

повтарящ се цикъл, в който разработчиците, когато приложението започне да се оформя, изискват и внедряват в продукта изискванията, получени чрез взаимодействие с клиента.

Жизненият цикъл на софтуера според методологията RAD се състои от четири фази:

фаза на дефиниране и анализ на изискванията;

фаза на проектиране;

фаза на изпълнение;

фаза на изпълнение.

При всяка итерация се оценява следното:

риск от превишаване на сроковете и разходите по проекта;
необходимостта от извършване на друга итерация;
степента на пълнота и точност на разбиране на системните изисквания;
възможност за прекратяване на проекта.

Предимства на итеративния подход:

Итеративното развитие значително опростява извършването на промени в проекта, когато изискванията на клиента се променят.
При използването на спиралния модел отделните елементи на информационната система постепенно се интегрират в едно цяло. При итеративен подход интеграцията се извършва практически непрекъснато. Тъй като интеграцията започва с по-малко елементи, има много по-малко проблеми по време на нейното изпълнение (според някои оценки, когато се използва моделът на развитие на водопада, интеграцията представлява до 40% от всички разходи в края на проекта).
Итеративното развитие осигурява по-голяма гъвкавост в управлението на проекти, което прави възможно извършването на тактически промени в продукта, който се разработва.
Итеративният подход опростява повторното използване на компоненти (прилага базиран на компоненти подход към програмирането). Това е така, защото е много по-лесно да се идентифицират общите части на даден проект, когато те вече са частично разработени, отколкото да се опитвате да ги идентифицирате в самото начало на проекта. Анализирането на дизайна след няколко първоначални итерации разкрива общи компоненти за многократна употреба, които ще бъдат подобрени в следващите итерации.
Спираловидният модел позволява по-надеждна и стабилна система. Това е така, защото с развитието на системата грешките и слабостите се откриват и коригират при всяка итерация. В същото време критичните параметри на производителността могат да бъдат коригирани, което в случай на каскаден модел е възможно само преди системата да бъде внедрена.
Итеративният подход дава възможност за подобряване на процеса на разработка - анализът, извършен в края на всяка итерация, ни позволява да преценим какво трябва да се промени в организацията на разработката и да я подобрим при следващата итерация.

Анотация.

Въведение.

1. Жизнен цикъл на софтуера

Въведение.

Стъпки на процеса на програмиране на Riley

Въведение.

1.1.1. Формулиране на проблема.

1.1.2. Дизайн на решение.

1.1.3. Алгоритъм за кодиране.

1.1.4. Програмна поддръжка.

1.1.5. Софтуерна документация.

Заключение към клауза 1.1

1.2. Определяне на LCPO според Lehman.

Въведение.

1.2.1 Дефиниция на системата.

1.2.2. Внедряване.

1.2.3. Обслужване.

Заключение към клауза 1.2.

1.3. Фази и работа на LCPO по Boehm

1.3.1. Каскаден модел.

1.3.2. Икономическа обосновка на каскадния модел.

1.3.3. Усъвършенстване на каскадния модел.

1.3.4. Определяне на фазите на жизнения цикъл.

1.3.5. Основна работа по проекта.

Литература.

Въведение

1 Жизнен цикъл на софтуера

ВЪВЕДЕНИЕ

1.1 Стъпки в процеса на програмиране на Riley

Процесът на програмиране включва четири стъпки (Фигура 1):

Ориз. 1. Четири стъпки на програмиране.

Програмирането започва от момента, в който потребител, т.е. някой, който се нуждае от програма за решаване на проблем, заявява проблема системен анализатор.Потребителят и системният анализатор съвместно определят формулировката на проблема. След това последният се предава алгоритмист, който отговаря за проектирането на решението. Решението (или алгоритъмът) представлява последователност от операции, чието изпълнение води до решение на даден проблем. Тъй като алгоритъмът често не е подходящ за изпълнение на машина, той трябва да бъде преведен в машинна програма. Тази операция се извършва от енкодера. Придружаващият програмист носи отговорност за последващи промени в програмата. И системният анализатор, и алгоритмистът, и енкодерът, и придружаващият го програмист – всички те са програмисти.

1.1.1 Постановка на проблема

Характеристики на добра формулировка на проблем:

Стандартна форма на изложение на проблема.

Помислете за следното изложение на проблем: „Въведете три числа и изведете числата по ред.“

име на задачата (схематично определение);

общо описание (кратко резюме на задачата);

пример (добрият пример може да предаде същността на проблема и също така да илюстрира различни случаи).

Пример. Изложение на проблема в стандартна форма.

ИМЕ

Сортиране на три цели числа.

ОПИСАНИЕ

Вход и изход на три цели числа, сортирани от най-малкото към най-голямото число.

1) Ако са въведени по-малко от три числа, програмата изчаква допълнително въвеждане.

2) Входни редове, различни от първите три, се игнорират.

3) Ако някой от първите три реда съдържа повече от едно цяло число, тогава програмата излиза и показва съобщение.

ГРЕШКА ПРИ ВЪВЕЖДАНЕ - Допуска се само едно цяло число на ред.

вход ® – 3

Тази стъпка на програмиране е най-трудната. На този етап постановката на проблема трябва да се превърне в алгоритъм. Следователно дизайнерът на алгоритъма трябва да има достатъчно опит в програмирането и да подхожда към всеки нов проблем въз основа на твърдо установена методология на проектиране. За съжаление в днешно време всички големи програми съдържат грешки, което води до лоши проекти. Лошите проекти от своя страна са следствие от сложността на проблемите и използването на неадекватни методи за проектиране. За да избегнат грешки в програмите, алгоритмистите трябва да използват внимателно проектирани процедури за проектиране, базирани на правила за извод.

Има два основни модела за изводи:

Първият модел е известен като дедуктивно заключение.Тази форма на логическо мислене е увековечена от известния детектив Шерлок Холмс. Дедуктивната логика прилага общи правила към конкретни случаи. Например, Холмс може да изведе конкретното твърдение „Икономът е убиец“ от по-общите познания „Блондинката убиец“ и „Икономът е единственият рус мъж, който може да бъде заподозрян“.

Вторият модел е индуктивен изход,което е обратното на дедуктивното заключение. Индуктивната логика прави общи изводи от отделни случаи. Например, индуктивното заключение може да се използва за оправдаване на общото заключение „слънцето изгрява на изток“ въз основа на много индивидуални наблюдения, че слънцето винаги е изгрявало на изток.

Тези два процеса на извод са − приспадане(от общо към конкретно) и индукция(от специфични към общи) - са тясно свързани с двата най-широко използвани метода за проектиране: "отгоре надолу"И "надолу нагоре".Подобно на дедукцията, дизайнът отгоре надолу започва с голям проблем, който се разделя на подпроблеми. Например, дизайнерът на нов хладилник-фризер, въз основа на първоначален набор от спецификации на единица (т.е. постановката на проблема), трябва да изготви подробни проекти и спецификации за крайния продукт (т.е. дизайна).

Ако той използва метод за проектиране отгоре надолу, тогава един единствен проектен проблем може да бъде разделен на два по-малки подпроблема: (1) дизайн на хладилния модул и (2) дизайн на фризера.

Можете обаче да използвате метода на проектиране отдолу нагоре и да започнете с проектиране на хладилния компресор и след това на хладилните тръби, модула или хладилната камера. В този случай този избор ще наложи определени ограничения върху целия проект.

Задачата на дизайнера е да създаде алгоритъм, който действа като връзка между постановката на проблема и програмата, готова за изпълнение. Проверката на създадения алгоритъм, т.е. колко добре той отразява формулировката на проблема, се извършва от системен анализатор. Поради това както системният анализатор, така и дизайнерът трябва да могат да четат и разбират алгоритъма. Всеки алгоритъм е написан на някакъв псевдоезик . Алгоритмите, наричани още псевдокодове, не могат да се изпълняват на нито един компютър.

Работата на енкодера е да преведе алгоритъма в програма. За да създадете пълна, точна и разбираема програма, са необходими подходящи методи за писане на програми. Например кулинарните рецепти обикновено са написани на естествени езици като английски, френски, руски или японски. Програмите се пишат на езици за програмиране. Понастоящем нито един от естествените езици не може да се използва като език за програмиране, защото са твърде сложни, за да бъдат „разбрани“ от машините. За разлика от естествените езици, езиците за програмиране са създадени специално, за да представят решение на проблем, който може да бъде изпълнен от компютър.

Кодерът трябва да гарантира, че програмата съответства на псевдокода, преди да излезе. След това системният анализатор, алгоритмистът и, най-важното, потребителят трябва да тестват и потвърдят, че работи правилно. След това можем да приемем, че програмата е готова за прехвърляне към потребителя заедно с цялата необходима документация.

Програмирането обаче не свършва дотук; следван от акомпаниментна стъпка.Факт е, че в програмата може да има грешки, дължащи се или на неадекватно изложение на проблема, или на факта, че проектът не отговаря на изложението на проблема или програмата не съответства на проекта. Каквато и да е причината, потребителят има право да поиска настройка на програмата, защото не е предполагал, че програмата ще работи по този начин. Коригирането на грешки е една от основните задачи на поддръжката на програмата. Друга също толкова важна задача на поддръжката на програмата е нейната модификация, тоест добавяне на нови функции към програмата или промяна на съществуващи. Потребителят може да промени изискванията за работата на програмата, което от своя страна ще доведе до необходимостта от пренаписване. Сложността на поддръжката на програмата зависи от типа промени, които трябва да бъдат направени: в най-лошия случай може да се наложи програмата да бъде изцяло преработена от производство към кодиране. Обикновено се отделя повече време за поддръжка на програма, отколкото за нейното създаване.

Последната част от процеса на програмиране е документация.Той включва широк набор от описания, които улесняват процеса на програмиране и обогатяват получената програма. Непрекъснатото документиране трябва да бъде неразделна част от всяка стъпка на програмиране. Постановка на проблема, документи за проектиране, алгоритми и програми - всичко това са документи. Вътрешната документация, включена директно в програмата, прави кода по-лесен за четене. Целта на ръководството за обучение (друга форма на документация) е да научи потребителя как да използва нова програма; Справочното ръководство предоставя описание на софтуерните команди.

Заключение към клауза 1.1.

Според модела, представен в тази глава, програмирането може да бъде разделено на четири стъпки: дефиниране на проблема, проектиране на решения, кодиране на програмата и поддръжка на програмата. Освен това моделът включва документиране на програмата като дейности, които трябва да бъдат изпълнени през целия процес на програмиране.

Моделът за програмиране е създаден специално за решаване на големи проблеми, тъй като те представляват интерес за компютърните учени. На практика обаче е важно да се използват внимателно подбрани инженерни техники за проектиране на програми, независимо от размера на проблемите: уменията, придобити при решаването на по-малки проблеми, могат да бъдат подсилени и успешно приложени при решаването на по-големи проблеми.

дефиниции;

изпълнение;

обслужване.

1.2.1 Дефиниция на системата

Процесът на създаване на софтуер започва с практически изследвания, водещи до системен анализ, чиято задача е да определи общите изисквания към системата и програмите. Такъв анализ трябва преди всичко да установи реални нужди и цели и, ако е възможно, да идентифицира наличните методи за постигане на целта. Ако е необходимо, анализът може да се основава на математически или други формални схеми. Смята се, че при всеки подход посоченият анализ трябва да има определена структура и да се извършва в съответствие с някаква теория. Анализът и усъвършенстването, извършени съвместно с анализатори и потенциални потребители, трябва да доведат до разработването на окончателна спецификация на изискванията .

Процесът на писане на такава спецификация е насочен към получаване на коректна техническа спецификация, пълна в смисъл на отразяване на изискванията и съответстваща на определението за изпълнение. След подготовката на спецификациите е фазата дизайн,чийто смисъл е да идентифицира и структурира данните, да ги трансформира и организира прехвърлянето им. Освен това на тази фаза е необходимо да се постигне в известен смисъл оптимално разпределение на функциите на системата, да се избере алгоритъм и процедури, както и да се идентифицират компонентите на системата и връзката между тях.

След завършване дизайнможем да започнем изпълнениесистеми. На практика обаче фазите на проектиране и изпълнение се припокриват. По този начин, докато йерархичният процес на разделяне продължава, анализът на някои елементи на системата може да се счита за достатъчно пълен, за да се пристъпи към внедряване, докато други елементи изискват допълнително изясняване.

В процеса на внедряване е необходимо да се установи коректността на програмата. Съвременните процедури са до голяма степен базирани на тестове, въпреки че използването на методи за структурен контрол от край до край и валидиране на програми се е увеличило през последните години.

Във всеки случай, тестването чрез изпълнение на програма обикновено се извършва отдолу нагоре, първо на ниво блок (модулно или процедурно), след това функционално, компонент по компонент. Тъй като отделните компоненти се тестват, те се комбинират в система по време на процеса на нейното оформление, след което започва тестването на системата. В крайна сметка, след като качеството на функциониране на системата е независимо проверено и нейните параметри са оценени, тя се счита за готова за освобождаване.

1.2.3 Поддръжка

Процесът на поддръжка започва веднага след освобождаването на системата. Грешките трябва да бъдат идентифицирани и коригирани. Ако грешка възпрепятства нормалната работа на потребителя, дефектната програма може да бъде временно премахната от системата или могат да бъдат направени временни или постоянни корекции на някои или всички използвани системи. След това постоянната корекция или промяна може да бъде включена в нова версия на системата. За да се приспособят всички промени и техните комбинации, се създават множество версии на системни елементи. Основната задача става управлението на конфигурацията на системата. Решаваща роля в управлението на програмирането принадлежи на услугите за поддръжка, които автоматично събират и регулират всички промени в системата.

Заключение към клауза 1.2.

Метасистемата, в която се развива програмата, съдържа значително по-голям брой вериги за обратна връзка от посочените по-горе. Много дейности се припокриват, преплитат се по сложни начини и се повтарят систематично. Следователно моделът LCPO, представен от Boehm, е достатъчно обоснован.

1.3 Фази и работа на центровете на жизнения цикъл според Boehm

Каскадният модел е представен през 70-те - 80-те години. Това е удобно за хомогенен софтуер, когато всяко приложение е едно цяло.

Основни характеристики на модела:

Жизненият цикъл е разделен на етапи (фази);

Преминаване от етап на етап - само след пълно завършване на текущия етап;

Етапът завършва с издаването на пълен набор от документация, достатъчна, за да може работата да бъде завършена от друг екип за разработка.

Основни характеристики каскаден моделследното:

завършване на всяка фаза с проверка и валидиране, чиято цел е да се премахнат възможно най-много проблеми, свързани с разработването на продукта;

циклични повторения на изпълнените фази от възможно най-ранната фаза.

Фиг.2. Каскаден модел на LCPO.

В каскадния модел успешното завършване на една от фазите на жизнения цикъл означава постигането на съответната цел на инженерното програмиране (вижте параграф 2.4.). Към тези подцели трябва да добавите още две:

Подробна възможност за проектиране– получаване на пълни проверени спецификации и структури за управление и данни, интерфейсни връзки, характеристики, основни алгоритми и определяне на работните условия на всеки софтуерен компонент.

Кодируемост– получаване на пълен, проверен набор от програмни компоненти.

Основни предимства:

Оформяне на пълен комплект проектна документация в края на работата на етапа. Документацията отговаря на критериите за пълнота и изчерпателност;

Възможност за планиране на срокове и разходи. За редица софтуерни приложения този модел е приложим - това е за системи, за които на етапа на анализ е възможно точно и пълно формулиране на всички изисквания. Например сложни изчислителни програми.

Основни недостатъци:

Дълги срокове от анализа до завършване;

Софтуерните изисквания са „замразени“ под формата на технически спецификации до края на разработката.

1.3.2 Икономическа обосновка на каскадния модел

Без да се задълбочава в икономическия анализ, който Б.У. Boehm обръща много внимание в книгата "Софтуерно инженерство", нека просто кажем, че икономическата обосновка на водопадния модел, фокусиран върху последователното постигане на целите, се основава на две основни предпоставки:

За да се получи висококачествен софтуерен продукт (т.е. такъв, който напълно отговаря на всички цели на необходимия софтуерен продукт), във всеки случай е необходимо да се изпълняват всички подцели на всеки етап.

Всяко друго подреждане на подцелите води до създаването на софтуерен продукт с по-ниско качество.

1.3.3 Подобряване на каскадния модел

Нека разгледаме едно от подобренията на идеалния модел на водопада - поетапно развитие.

Стъпка по стъпка развитиее подобрение на итеративния метод на проектиране с прототипиране и наслоено развитие отгоре надолу. Този метод включва постепенно увеличаване на функционалността на софтуера по време на процеса на разработка.

Като усъвършенстван водопаден модел, постепенното развитие е успешно използвано за създаване както на много големи, така и на малки софтуерни продукти.

Основните предимства на разработката стъпка по стъпка пред абсолютно итеративната разработка и разработката ниво по ниво отгоре надолу са следните:

използването на последователни разширения на програмата осигурява много по-евтин начин за включване на потребителското изживяване в подобрен продукт, отколкото при повторното разработване;

Разширяването на функционалността е много по-лесно за тестване и е по-полезно от междинните продукти при многослойна разработка.

Стойността на постепенното развитие се състои главно в промяната на разпределението на разходите за труд за проекта. Вариант на каскадния модел за поетапно развитие е показан на фигура 3.

1.3.4 Дефиниране на фазите на жизнения цикъл

По-долу ще бъде дадена формулировката на крайните цели на всяка фаза за преход към следващата фаза. За поетапно развитие, дадените твърдения се отнасят до фазовите граници на всяка стъпка на разширяване.

Започнете фазата на планиране и анализ на изискванията.(Пълен концептуален преглед на LCPE.)

Получаване на одобрена и потвърдена системна архитектура, включително основни споразумения за разпределение на функциите между хардуера и програмите. Получаване на одобрено и потвърдено общо разбиране за функционирането на софтуера, включително основни споразумения за разпределението на функциите между лицето и системата.

Формиране на общ план за процеса на жизнения цикъл, определящ основните етапи, ресурси, отговорности, срокове и основни работи.

Завършете фазата на планиране и анализ на изискванията. Започнете фазата на проектиране на продукта.(Пълен преглед на софтуерните изисквания).

Изготвяне на подробен устройствен план: подробни показатели за изпълнение на етапите на развитие, планове за разпределение на ресурсите, схеми на организационната структура, отговорности, срокове, работи, методи и продукти.

Формиране на подробен план за ползване: точки от плана за развитие, чието съдържание е насочено към обучение, трансфер на програми, внедряване, експлоатация и поддръжка.

Формиране на подробен план за отстраняване на грешки на продукта - план за управление на хардуерната конфигурация, план за контрол на качеството, план за обща проверка и потвърждение.

Одобрена и валидирана спецификация на софтуерните изисквания: функционални, технически и интерфейсни спецификации, за които е доказано, че са пълни, последователни, проверими и осъществими.

Одобрено (официално или неофициално) споразумение за развитие въз основа на точките по-горе.

Завършете фазата на проектиране на продукта. Започнете фазата на подробен дизайн.(Завършване на анализа на резултатите от дизайна на продукта.)

Разработване на верифицирана спецификация за проект за софтуерен продукт:

формиране на йерархия от софтуерни компоненти, междублокови интерфейси за данни и управление;

формиране на физически и логически структури от данни до ниво отделни полета;

разработване на план за разпределение на изчислителните ресурси (време, памет, точност);

проверка на пълнотата, последователността, осъществимостта и валидността на изискванията.

Идентифициране и разрешаване на всички противоречия на развитието, които повишават степента на риск.

Разработване на предварителен етап на интеграция и отстраняване на грешки, план за ръководство за потребителя и тестове за приемане.

Завършете фазата на подробен дизайн. Започнете фазата на кодиране и офлайн отстраняване на грешки.(Завършване на контрол на проекта от край до край или критичен анализ блок по блок на проекта.)

Проверена подробна спецификация на всеки блок:

спецификация на всяка подпрограма, име, цел, предположения, измерения, последователност на извиквания, изходи за грешки, входни и изходни данни, алгоритми и логически дизайн;

описание на базата данни до ниво отделни параметри, символи и битове;

Проверка на пълнотата, последователността и съответствието със спецификациите на дизайна на системата и плановете за разпределение на ресурсите.

Одобрен план за изпитване за приемане.

Ръководства за потребителя, както и завършен предварителен план за интеграция и отстраняване на грешки.

Завършете фазата на копиране и отстраняване на грешки. Започнете фазата на интегриране и отстраняване на грешки.(Удовлетворете критериите за офлайн отстраняване на грешки.)

Проверка на работата на всички агрегати не само за номинални стойности, но и за изключителни и гранични стойности.

Проверка на всички входни и изходни опции, включително съобщения за грешки.

Изпълнение на всички оператори и всички клонове на контролния трансфер.

Проверка на съответствието със стандартите за програмиране.

Попълване на блок по блок документация на вътрешната структура.

Завършете фазата на интегриране и тестване. Започнете фазата на изпълнение.(Завършване на анализа на резултатите от теста за приемане.)

Проверка на съответствието с теста за приемане на програмата:

проверка на съответствието с изискванията на софтуера;

Демонстрация на приемливостта на експлоатационните характеристики, посочени в спецификациите, при необичайни условия.

Приемане на доставени софтуерни продукти, отчети, ръководства, бази данни, вътрешни структурни спецификации.

Завършете фазата на изпълнение. Започнете фазата на експлоатация и поддръжка.(Пълен преглед на приемането на системата.)

Проверка на задоволителни резултати от тестовете за приемане на системата.

Проверка дали системните изисквания са задоволителни.

Проверка на производствената готовност на софтуер, хардуер, инструменти за поддръжка и персонал.

Приемане на доставени и включени в системата продукти: хардуер, софтуер, документация, инструменти за обучение и поддръжка.

Завършване на всички посочени работи и въвеждане в експлоатация на системата.

Завършете фазата на експлоатация и поддръжка(чрез прекъсване).

Изпълнение на всички точки от плана за извеждане от експлоатация: прехвърляне на програми, документация, създаване на архив, преход към нова система.

1.3.5 Основна работа по проекта

Анализ на изискванията.

Продуктов дизайн.

Програмиране.

Планиране на отстраняване на грешки.

Проверка и потвърждение.

Управление на проекти.

Управление на конфигурацията и контрол на качеството.

И така, бяха разгледани три подхода за определяне на жизнения цикъл на софтуера. Според мен всички те имат право на съществуване, тъй като в една или друга степен отразяват практиката на програмиране. Освен това е лесно да се открият общи точки (поставя се задача - дефинира се система - анализират се изисквания; поддръжка на програмата - поддръжка - експлоатация и поддръжка).

Все пак трябва да се отбележи, че определението на Боем за фазите и работата на центъра на жизнения цикъл е най-обосновано, т.к. разчита на по-фокусиран подход в инженерното програмиране (насочен към получаване на висококачествен софтуерен продукт и реализиране на ефективен процес на разработка и поддръжка на софтуер) и е икономически оправдано.

Въз основа на този доклад става ясно колко е важно и необходимо да се познават нуждите на съвременния свят при създаването на софтуерен продукт (продукт). При изготвянето на програма за автоматизиране на всяка система е важно да се вземе предвид, че съвременният свят непрекъснато се променя, което означава, че програмата трябва да може да се променя.

Също така е важно, когато съставяте програма, да вземете предвид, че програмата трябва да бъде точна; завършена по съдържание и подходяща за работа както с малки, така и с големи проблеми в съответствие с предназначението си; ясен - за да може потребителят да работи с него спокойно и без затруднения. А също и за да може програмата лесно да се коригира или допълва по всяко време в съответствие с променящите се изисквания в съвременния свят.

Трябва да се помни, че доброто програмиране не означава кодиране на бързо решение с помощта на подходяща техника, а внимателно инструментирана инженерна процедура, която произвежда пълен, точен и лесно разбираем (ясен) софтуер.

1. B.U. Boehm, Софтуерно инженерство. М.: Радио и комуникации. 1985 г.

2. Д. Райли. „Използване на езика Modula-2.“ М.: Мир. 1993 г.

3. Ю.В. Иванов „Програми и техните жизнени цикли” (реферат по дисциплината „Софтуерна метрология”). 1998 г.

Здравейте, скъпи жители на Хабровск! Мисля, че ще бъде интересно някой да си спомни какви модели на разработка, внедряване и използване на софтуер са съществували преди, какви модели се използват основно сега, защо и какво всъщност представлява. Това ще бъде моята малка тема.

Всъщност какво е жизнен цикъл на софтуера- поредица от събития, които се случват със системата по време на нейното създаване и по-нататъшно използване. С други думи, това е времето от началния момент на създаване на всеки софтуерен продукт до края на неговото разработване и внедряване. Жизненият цикъл на софтуера може да бъде представен под формата на модели.

Модел на жизнения цикъл на софтуера- структура, съдържаща процеси на действие и задачи, които се изпълняват по време на разработването, използването и поддръжката на софтуерен продукт.
Тези модели могат да бъдат разделени на 3 основни групи:

Инженерен подход
Отчитайки спецификата на задачата
Съвременни технологии с бързо развитие

Сега нека да разгледаме съществуващите модели (подкласове) и да оценим техните предимства и недостатъци.

Модел на кодиране и отстраняване на грешки

Напълно семпъл модел, типичен за студенти. Именно според този модел повечето студенти развиват, да кажем, лабораторна работа.
Този модел има следния алгоритъм:

Формулиране на проблема
производителност
Проверка на резултата
Ако е необходимо, преминете към първа точка

Модел също ужасноостарял. Той е типичен за 60-70-те години на миналия век, така че практически няма предимства пред следващите модели в нашия преглед, но недостатъците са очевидни. Принадлежи към първата група модели.

Водопад модел на жизнения цикъл на софтуера (водопад)

Алгоритъмът на този метод, който показвам на диаграмата, има редица предимства пред алгоритъма на предишния модел, но също така има редица значителнонедостатъци.

Предимства:

Последователно изпълнение на етапите на проекта в строго фиксиран ред
Позволява ви да оцените качеството на продукта на всеки етап

недостатъци:

Няма обратна връзка между етапите
Не отговаря на реалните условия на разработка на софтуерен продукт

Принадлежи към първата група модели.

Каскаден модел с междинно управление (джакузи)

Този модел е почти еквивалентен по алгоритъм на предишния модел, но има обратна връзка с всеки етап от жизнения цикъл и води до много съществен недостатък: 10-кратно увеличение на разходите за разработка. Принадлежи към първата група модели.

V модел (тестова разработка)

Този модел има алгоритъм, по-близък до съвременните методи, но все пак има редица недостатъци. Това е една от основните практики на екстремното програмиране.

Модел, базиран на разработка на прототип

Този модел се основава на разработването на прототипи и прототипи на продукти.
Прототипиранеизползвани в ранните етапи от жизнения цикъл на софтуера:

Изясняване на неясни изисквания (прототип на потребителския интерфейс)
Изберете едно от редица концептуални решения (изпълнение на сценарии)
Анализирайте осъществимостта на проекта

Класификация на прототипите:

Хоризонтална и вертикална
Еднократна употреба и еволюция
хартия и сценарии

Хоризонталнапрототипи - моделира изключително потребителския интерфейс, без да засяга логиката на обработка и базата данни.
Вертикалнапрототипи - тестване на архитектурни решения.
Разполагаемпрототипи - за бързо развитие.
Еволюционенпрототипите са първото приближение на една еволюционна система.

Моделът принадлежи към втората група.

Спирален модел на жизнения цикъл на софтуера

Спираловидният модел е процес на разработка на софтуер, който комбинира както дизайн, така и поетапно създаване на прототипи, за да комбинира предимствата на концепциите отдолу нагоре и отгоре надолу.

Предимства:

Получете резултати бързо
Повишена конкурентоспособност
Промяната на изискванията не е проблем

недостатъци:

Липса на сценична регулация

Третата група включва такива модели като екстремно програмиране(XP) СКРЪМ, инкрементален модел(RUP), но бих искал да говоря за тях в отделна тема.

Благодаря ви много за вашето внимание!