Кожни заболявания 

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. Иницииране на придобиване
  2. Изготвяне на оферти
  3. Изготвяне и коригиране на договора
  4. Надзор на доставчика
  5. Приемане и завършване на работите

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

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

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

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

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

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

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

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

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

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

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

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

  • Модел на задачата;
  • каскаден модел (или системен) (70-85);
  • спирален модел (настояще).

Модел на задачата

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

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

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

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

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

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

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

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

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

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

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

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

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

спираловиден модел

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 1. Формиране на изисквания към софтуера.
  • 2. Дизайн.
  • 3. Внедряване.
  • 4. Тестване.
  • 5. Въвеждане в експлоатация.
  • 6. Експлоатация и поддръжка.
  • 7. Извеждане от експлоатация.

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

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

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

изграждане на модели на дейността на организацията, което включва обработка на анкетни материали и изграждане на два вида модели:

модел „КАКТО Е“ („както е“), който отразява текущото състояние на нещата в организацията към момента на проучването и ви позволява да разберете как функционира организацията, както и да идентифицирате тесните места и да формулирате предложения за подобряване на ситуация;

модел "TO-BE" ("както трябва да бъде"), отразяващ идеята за новите технологии на организацията.

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

Преходът от модела „КАКТО Е“ към модела „ДА БЪДЕ“ може да се извърши по два начина:

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

Конструираните модели имат самостоятелно практическо значение. Например, моделът „AS-IS“ ви позволява да идентифицирате тесните места в съществуващите технологии и да предложите препоръки за решаване на проблеми, независимо дали се очаква по-нататъшно развитие на EIS на този етап или не. Освен това моделът улеснява обучението на служителите в конкретни области от дейността на организацията чрез използването на визуални диаграми (известно е, че „една снимка струва колкото хиляда думи“).

Етап на проектиране. Обикновено включва следните стъпки:

  • * разработване на системен проект. На този етап се дава отговор на въпроса: „Какво трябва да прави бъдещата система?“, а именно: архитектурата на системата, нейните функции, външни условия на работа, интерфейси и разпределение на функциите между потребителите и системата, изисквания за софтуерни и информационни компоненти, състав на изпълнители и график за разработка. В основата на системния проект са моделите на проектираните EIS, които са изградени на базата на модела "TO-BE". Документираният резултат от етапа е техническото задание;
  • * Изработване на технически проект. На този етап, на базата на системния дизайн, се извършва действителното системно проектиране, включително проектиране на системната архитектура и подробен дизайн. По този начин се дава отговор на въпроса: "Как да изградим система, така че да отговаря на предявените към нея изисквания?". В същото време моделите на проектираните EIS са усъвършенствани и детайлизирани до необходимото ниво.

Всеки етап може да изпълнява множество процеси, дефинирани в ISO/IEC 12207, и обратно, един и същ процес може да се изпълнява на различни етапи.

Към днешна дата следните два основни модела на жизнения цикъл на софтуера са станали най-широко използвани: каскаден модел (1970-1985) и спирален модел (1986-1990).

В хомогенни EIS от 70-те и 80-те години. приложният софтуер беше едно цяло. За разработването на този тип софтуер е използван водопаден подход (друго име е водопад) (фиг. 1.3). Основната характеристика на каскадния подход е следната: преходът към следващия етап се извършва само след като работата на текущия етап е напълно завършена и не се предвижда връщане към преминатите етапи. Всеки етап завършва с някои резултати, които служат като вход за следващия етап. Изискванията към разработения софтуер, определени на етапа на формиране на изискванията, са стриктно документирани под формата на техническо задание и са фиксирани за целия период на разработване на проекта. Всеки етап завършва с издаването на пълен набор от документация, достатъчна за разработката, която да бъде продължена от друг екип за разработка. Критерият за качество на разработката при този подход е точността на изпълнение на спецификациите на техническото задание.

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

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

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

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

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

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

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

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

  • 1. Потребителите не могат веднага да заявят всичките си изисквания и не могат да предвидят как те ще се променят по време на разработката.
  • 2. По време на разработката може да има промени във външната среда, които ще повлияят на изискванията към системата.

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

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

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

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

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

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

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

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

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

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

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

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

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

2) дизайн на софтуерната структура;

3) изпълнение;

4) изпитване;

5) въвеждане в експлоатация;

6) експлоатация и поддръжка;

7) извеждане от експлоатация.

Множество процеси, дефинирани в 1SO/IEC 12207, могат да бъдат изпълнени във всяка стъпка и обратно, един и същ процес може да бъде изпълнен в различни стъпки.

Съществуващ модели J C определя реда на изпълнение на стъпкитепо време на разработката и критерии за преходот етап на етап.

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

1)Каскаден модел(1970-1980) включва прехода към следващия етап след завършване на работата на предишния етап.

2)Модел стъпка по стъпкас междинен контрол (1980-1985) - итеративен модел на разработка на софтуер с вериги за обратна връзкамежду етапите.

3)спираловиден модел(1986-1990) прави акцент върху началните етапи от жизнения цикъл(анализ на изискванията, ТУ, идеен и работен проект).

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

Разбиване на цялата разработка на етапи;

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

Възможност за планиране на времето за завършване на цялата работа и съответните разходи;

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

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

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

Ориз. 4.1. Водопаден модел за разработка на софтуер

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

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


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

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

Ориз. 4.2. Модел с междинно управление

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

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

Ориз. 4.3. Спирален модел на жизнения цикъл

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

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

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

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

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

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

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

Други недостатъци на спиралния модел са:

Сложността на извършването на промени;

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

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

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

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

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

Една от основните концепции на методологията за проектиране на ИС е концепцията за жизнения цикъл на софтуера (LCS).

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

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

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

Най-пълният жизнен цикъл, технологията за разработване и осигуряване на качеството на PS са отразени в стандартите ISO (Международна организация по стандартизация - Международна организация за стандартизация). Стандартът ISO 12207:1995 – „Процеси на жизнения цикъл на софтуера” – най-пълно отразява архитектурата, работата, организацията и управлението на жизнения цикъл на ПС.

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

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

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

Въз основа на един и същи набор от основни стандарти могат да се формират различни профили за различни проекти.

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

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



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

Основният нормативен документ, регулиращ жизнения цикъл на софтуера, е международният стандарт ISO / IEC 12207 (ISO - Международна организация по стандартизация - Международна организация по стандартизация, IEC - Международна електротехническа комисия - Международна електротехническа комисия). Той дефинира структура на жизнения цикъл, която съдържа процесите, дейностите и задачите, които трябва да бъдат изпълнени по време на разработката на софтуер.

Структурата на жизнения цикъл на софтуера според стандарта ISO / IEC 12207 се основава на три групи процеси:

· основни процесиСофтуер за жизнения цикъл (придобиване, доставка, разработка, експлоатация, поддръжка);

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

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

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

Разработката на софтуер включва, обикновено:

· анализ;

· проектиране;

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

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

Тази фаза обикновено представлява 50% от разходите за PI и 32% от разходите за труд.

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

Включва:

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

Осигуряване на оперативна документация;

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

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

Фаза на поддръжканаричана още фаза на текущо развитие.

Състои се от идентифициране и отстраняване на грешки в програмите и промяна на тяхната функционалност.

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

Процес на поддръжка, ще продължи успоредно с дейността на ПИ.

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

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

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

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

Всеки процес се характеризира с:

определени задачи и методи за тяхното решаване,

първоначалните данни, получени на предишния етап,

резултати.

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

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

Стандартът ISO/IEC 12207 не предлага конкретен модел на жизнения цикъл и методи за разработка на софтуер. (Моделът на жизнения цикъл зависи от спецификата на ИС и от спецификата на условията, в които се създава и функционира последната). Неговите разпоредби са общи за всички модели на жизнения цикъл, методологии и технологии за разработка. Стандартът ISO/IEC 12207 описва структурата на процесите на жизнения цикъл на софтуера, но не уточнява подробно как да се внедри или изпълни действияи задачивключени в тези процеси.

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

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

· спираловиден модел (86-90).

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

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

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

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


Ориз. 1. Водопадна схема на разработка на софтуер

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

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

· Неадекватно управление на риска: Рисковете, свързани с проекта, се идентифицират в по-късните етапи на проекта.

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


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

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

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

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

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

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

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

Ориз. 3. Спирален модел на жизнения цикъл

При създаване на софтуер може да се използва „Модел на повторна употреба и обратно инженерство“.

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

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

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

Какъв е жизненият цикъл във формален смисъл?

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

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

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

Първоначални изисквания

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

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

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

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

  • ГОСТ 34.601-90;
  • ISO/IEC 12207:2008;
  • Oracle CDM.

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

Видове софтуер и актуализации

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

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

Пример, базиран на FL Studio

Първоначално виртуалното студио-секвенсор FL Studio се наричаше Fruity Loops. Жизненият цикъл на софтуера в първоначалната му модификация е изтекъл, но приложението е донякъде трансформирано и е придобило сегашния си вид.

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

  • създаване на барабанен модул, подобен на ритъм машини като Yamaha RX, но използващ еднократни семпли или WAV последователности, записани на живо в студия;
  • интеграция в операционни системи Windows;
  • възможност за експортиране на проекта във формати WAV, MP3 и OGG;
  • съвместимост на проекта с допълнителното приложение Fruity Tracks.

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

В тази връзка, на етапа на тестване и отстраняване на грешки, разработчиците трябваше да следват пътя на немската корпорация Steinberg и да приложат поддръжка на режим Full Duplex в изискванията за основния звуков драйвер. Качеството на звука е станало по-високо и ви позволява да променяте темпото, височината и да прилагате допълнителни FX ефекти в реално време.

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

Това не беше ограничено. На етапа на управление на проекта беше въведена поддръжка за свързване на плъгини във формат VST (първо втората, а след това третата версия), веднъж разработен от Steinberg. Грубо казано, всеки виртуален синтезатор, който поддържа VST-хост, може да се свърже с програмата.

Не е изненадващо, че скоро всеки композитор може да използва аналози на "железните" модели, например пълните набори от звуци на някога популярния Korg M1. Освен това. Използването на модули като Addictive Drums или универсалната добавка Kontakt направи възможно възпроизвеждането на живи звуци на реални инструменти, записани с всички нюанси на артикулация в професионални студия.

В същото време разработчиците се опитаха да постигнат максимално качество, като създадоха поддръжка за драйвери ASIO4ALL, които се оказаха с глава и рамене над режима Full Duplex. Съответно битрейтът също се увеличи. Към днешна дата качеството на експортирания аудио файл може да бъде 320 kbps при честота на дискретизация 192 kHz. Това е професионален звук.

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

Перспективи за развитие

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

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

Дори в случая с Windows подобни тенденции могат да се видят с невъоръжено око. Малко вероятно е днес да има поне един потребител, използващ системи като модификации 3.1, 95, 98 или Millennium. Техният жизнен цикъл приключи след пускането на XP версията. Но сървърните версии, базирани на NT технологии, все още са актуални. Дори Windows 2000 днес е не само много актуален, но дори надминава най-новите разработки в някои инсталационни или защитни параметри. Същото важи и за системата NT 4.0, както и за специализирана модификация на Windows Server 2012.

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

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

Някои допълнителни въпроси

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

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

Но в компютърните технологии днес се дава предпочитание на разработването на автоматизирани системи за управление (ACS), които се използват в производството. Дори операционните системи, в сравнение със специализираните програми, губят.

Същите базирани на Visual Basic среди остават много по-популярни от Windows системите. И изобщо не говорим за приложен софтуер за UNIX системи. Какво мога да кажа, ако почти всички комуникационни мрежи на същите Съединени щати работят изключително за тях. Между другото, системи като Linux и Android също първоначално са създадени на тази платформа. Следователно най-вероятно UNIX има много повече перспективи от другите продукти, взети заедно.

Вместо общо

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

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

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

Въпреки че не винаги разбират същността на програмирането, те очевидно са в състояние да определят моделите на жизнения цикъл на софтуера и продължителността на тяхното използване, въз основа на световните тенденции в тази област. Ефективното управление често дава по-осезаеми резултати. Да, поне PR технологии, реклама и т.н. Потребителят може да не се нуждае от приложение, но ако се рекламира активно, потребителят ще го инсталира. Това вече е, така да се каже, подсъзнателно ниво (същият ефект на 25-ия кадър, когато информацията се вкарва в съзнанието на потребителя независимо от самия него).

Разбира се, подобни технологии са забранени в света, но много от нас дори не осъзнават, че те все още могат да бъдат използвани и да въздействат на подсъзнанието по определен начин. Какво струва „зомбирането“ на новинарски канали или интернет сайтове, да не говорим за използването на по-мощни средства, като излагане на инфразвук (това беше използвано в една оперна постановка), в резултат на което човек може да изпита страх или неадекватни емоции.

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

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