Жизнен цикъл на процеса на развитие. Жизнен цикъл на софтуерните системи
В общия случай софтуерната система, в допълнение към самите програми, съдържа и хардуер и обикновено се счита за заобиколена от други софтуерни и хардуерни системи.
Жизненият цикъл на софтуерната система обикновено се разбира като целия период на съществуване на софтуерна система, започвайки от момента, в който е разработена първоначалната концепция на системата и завършва, когато системата стане остаряла. Концепция "жизнен цикъл""използва се, когато се очаква софтуерната система да има доста дълъг живот, за разлика от експерименталното програмиране, при което програмите се изпълняват няколко пъти и не се използват отново.
Жизненият цикъл традиционно се моделира като определен брой последователни етапи (или етапи, фази). Понастоящем няма общоприето разделяне на жизнения цикъл на софтуерната система на етапи. Понякога етапът е подчертан като отделна точка, понякога е включен като неразделна част от по-голям етап. Действията, извършвани на един или друг етап, могат да варират. Няма еднаквост в наименованията на тези етапи. Затова първо ще се опитаме да опишем някакъв обобщен жизнен цикъл на софтуерна система и след това ще демонстрираме няколко примера за различни жизнени цикли, като посочим аналогии от този обобщен цикъл.
Етапи на жизнения цикъл на софтуера
Жизненият цикъл на софтуера е периодът на разработка и експлоатация на софтуера, който обикновено включва следните етапи: -1- възникване и изследване на идея; -2- анализ и проектиране на изискванията; -3- програмиране; -4- тестване и отстраняване на грешки; -5- въвеждане на програмата в действие; -6- експлоатация и поддръжка; -7- край на операцията.
Трябва да се отбележи, че разделянето на жизнения цикъл на етапи понякога помага да се скрият някои важни аспекти на създаването на софтуер; Това е особено вярно по отношение на такъв необходим процес като итеративното изпълнение на различни етапи от жизнения цикъл, за да се коригират грешки, да се променят решенията, които се оказаха неправилни, или да се вземат предвид промените в общите изисквания към системата.
Примери за описания на жизнения цикъл
Нека разгледаме няколко описания на жизнения цикъл на софтуера, които ще служат като вид коментар на етапите на обобщения жизнен цикъл.
Във вътрешните нормативни документи (например GOST ESPD) е прието следното разделение на етапи, което е дадено с посочване на аналози от списъка, даден в началото на раздела:
разработване на технически спецификации (етап 1 и 2);
технически проект (трети етап до 3.2.1 включително);
работен проект (3.2.2, 4.2.1 и отчасти 4.2, 4.3);
пилотно внедряване (4.2 и 4.3);
въвеждане в експлоатация за търговска експлоатация (етап 5);
промишлена експлоатация (етап 6).
Такова описание се основава на технологията за разработка на хардуер и следователно не отчита напълно всички отличителни характеристики на софтуерния дизайн. По-подходящото описание на жизнения цикъл на софтуера изглежда е 12 етапа, които са много подобни на етапите на обобщения жизнен цикъл (виж Фигура 1.1). В скоби след името на фазата е посочен аналог от обобщения цикъл. Почти всички етапи завършват с проверка на резултатите, получени на съответния етап.
Ориз. 1.1 Пример за жизнения цикъл на софтуерни системи
Иницииране и планиране на проекта (етап 1). Определят се необходимите действия, планове и организация на управлението на проекта. Определят се мерки за осигуряване на непрекъснато изпълнение на фазите на жизнения цикъл.
Анализ на целевите изисквания (2.1). Определят се общите характеристики на системата, на които тя трябва да отговаря, без да се отчитат средствата за изпълнение. Установява се какво трябва да прави системата и как трябва да го прави.
Анализ на системните изисквания (2.2). Той описва как трябва да бъдат удовлетворени заявките на потребителя, по отношение на специфични функционални концепции, описани са действията на предложената система, съхранените данни, използвания интерфейс - всичко това без да се взема предвид физическата реализация. Тества се пригодността на тези специфични концепции.
Проектиране на системата (3.1). Структурата на системата или, с други думи, нейната архитектура е установена по отношение на основните компоненти на тази система и тяхното предвидено изпълнение (хардуер, софтуер, използване на околната среда и т.н.). Установени са изисквания за всеки компонент, както и стратегия за тестване и интеграция.
Предварителен софтуерен дизайн (3.2.1). Определяне на конкретни софтуерни компоненти, които ще бъдат разработени и внедрени в крайната система. Проверка на съответствието на този набор от компоненти с общите софтуерни изисквания. Определяне на функционални, експлоатационни и тестови изисквания за всеки конкретен компонент.
Детайлен софтуерен дизайн (3.2.2). По отношение на използваните софтуерни конструкции е направено описание на това как ще бъде разработен всеки конкретен компонент. Описани са начините на използване на всеки компонент в системата.
Софтуерно кодиране и тестване (4.1.1 и 4.1.2). Създаване, тестване на отделни модули, документиране и приемане на софтуерни компоненти, изграждащи софтуерната система.
Софтуерна интеграция (част 4.2). Тестване на производителността и функционалната пълнота на софтуерните части на системата в предвидима среда (хардуер и среда).
Системна интеграция (4.3). Тестване на производителността и функционалната пълнота на части от цялостната система като цяло.
Приемане и предаване на системата (5). Системата се приема от клиента и системата му се доставя.
Експлоатация и поддръжка на системата (6). Пускане на последващи версии или версии на системата, необходимостта от които възниква поради отстраняване на дефекти, тестване на променени изисквания и др.
Завършване на проекта (7). Формиране на посторигинален модел на проектни действия с анализ на предимствата, недостатъците и т.н. и използването им като основа за подобряване на процеса на разработка.
Като следващ пример, помислете за непълен жизнен цикъл на софтуера, без етапи на работа и поддръжка (вижте фиг. 1.2). Тази опция не фиксира последователността от фази или етапи, а по-скоро предлага списък от действия, които трябва да бъдат извършени през целия жизнен цикъл на софтуера. Тези действия могат да бъдат разбити или, обратно, групирани в различни етапи, в зависимост от конкретните условия. Можем да разграничим следните етапи от жизнения цикъл на софтуерните системи (в скоби, както преди, са аналози от модела на обобщения цикъл):
етап на планиране, който определя и координира дейностите по разработване на софтуерната система (етап 1);
етап на разработка, на който се създава софтуерна система:
формулиране на проблема (етап 2),
дизайн (3),
кодиране (4.1.1),
получаване на изпълним код (4.1.1, 4.3);
интегриран етап, който осигурява корекция, проверка и определяне на пълнотата на софтуерната система, както и нейното освобождаване. Този етап включва проверка, наблюдение на конфигурацията на системата, оценка на качеството и проверка на взаимодействието между етапите. От името на този етап става ясно, че той се изпълнява заедно с други етапи през целия жизнен цикъл на системата.
Ориз. 1.2 Възможност за опростен жизнен цикъл на софтуерна система.
Липсата на интегриран етап в общия жизнен цикъл не означава, че проверката се извършва само когато това е ясно посочено в името на етапа (например 4.2.1 и 4.2). Всеки етап може да се счита за завършен само когато резултатите, получени на този етап, се считат за задоволителни и за това е необходимо да се проверяват резултатите на всеки етап. В обобщения жизнен цикъл някои проверки са подчертани като отделни елементи, за да демонстрират увеличения обем, сложност и важност на тези проверки.
Последователността на етапите на жизнения цикъл на различните софтуерни системи се определя от такива характеристики като функционалност, сложност, размер, стабилност, използване на предварително получени резултати, разработваната стратегия и хардуер.
На фиг. 1.3. показва последователността от етапи на разработка на софтуер за отделни компоненти на една софтуерна система с различни жизнени цикли.
Ориз. 1.3 Последователност от етапи на разработка на софтуерни компоненти
За компонент W, от набора от системни изисквания за един продукт, се формира подмножество от изисквания, свързани с този компонент, тези изисквания се използват при формирането на проект за софтуерен компонент, този проект се внедрява в изходния код и след това компонентът е интегриран с хардуера. Компонент X показва използването на предварително разработен софтуер. Компонент Y показва използването на проста единична функция, която може да бъде кодирана директно въз основа на софтуерните изисквания. Компонент Z показва използването на прототипната стратегия. Обикновено целите на прототипирането са да се разберат по-добре софтуерните изисквания и да се намалят техническите рискове и рисковете за разработка при създаването на крайния продукт. Първоначалните изисквания се използват като основа за получаване на прототип. Този прототип се преобразува в среда, типична за специфичното използване на системата за разработка. Резултатът от трансформацията са прецизирани данни, които се използват за създаване на крайния софтуерен продукт.
Почти всички етапи от жизнения цикъл се комбинират с проверка.
Жизнен цикъл на софтуера
Една от основните концепции на методологията за проектиране на ИС е концепцията за жизнения цикъл на софтуера (SOLC).
J C– това е модел на различни състояния на софтуерен продукт, като се започне от момента, в който възникне нуждата от този софтуерен продукт и се стигне до момента, в който той излезе от употреба за всички потребители.
Жизненият цикъл на базите данни все още не е регулиран от стандарти - съществуващите стандарти се отнасят само до жизнения цикъл на софтуера.
Стандартите за жизнения цикъл на PS могат да се използват като директиви, насоки или консултативни документи.
Жизненият цикъл, технологията за разработване и осигуряване на качеството на софтуера са най-пълно отразени в стандартите ISO (International Standards Organisation). Стандартът ISO 12207:1995 – “Процеси на жизнения цикъл на софтуера” – най-пълно отразява архитектурата, работата, организацията и управлението на жизнения цикъл на софтуера.
Моделите на жизнения цикъл на софтуера, действително използвани в компаниите, наскоро се промениха спрямо тези, дадени в стандартите във връзка с въвеждането и развитието на обектно-ориентиран анализ и методи за бързо разработване на софтуер, CASE системи и езици от четвърто поколение. Новите модели намаляват работата по директното създаване на софтуерни компоненти и детайлизират работата по системен анализ и проектиране на софтуерни системи и бази данни.
Като цяло, когато създавате PS проекти и осигурявате техния жизнен цикъл, препоръчително е да използвате извадка от целия набор от представени стандарти (както международни, така и национални) и да запълните съществуващите пропуски в стандартизацията с де факто стандарти и ведомствени регулаторни документи.
Профиле набор от няколко основни стандарта и други нормативни документи, предназначени да реализират дадена функция или група от функции.
Въз основа на един и същи набор от основни стандарти могат да се формират различни профили за различни проекти.
При сертифициране на информационни системи сертификацията за съответствие с профила се обособява като специален вид тест. И тук трябва да се има предвид, че в международната IP стандартизация е възприето строго тълкуване на понятието профил - смята се, че само международни и национални одобрени стандарти могат да бъдат в основата на профил (тоест използването на де фактически стандарти и нормативни документи на компаниите не се допуска).
На базата на конкретния профил се предвижда изготвяне на документация. Освен това за всеки етап от жизнения цикъл е написана собствена документация, която от своя страна е разделена на видове, в зависимост от това за кои специалисти е създадена.
Жизненият цикъл на софтуера е непрекъснат процес, който започва от момента на вземане на решение за необходимостта от неговото създаване и завършва в момента на пълното му изтегляне от експлоатация.
Основният нормативен документ, регулиращ жизнения цикъл на софтуера, е международният стандарт ISO /IEC 12207 (ISO - Международна организация по стандартизация, IEC - Международна електротехническа комисия). Той определя структурата на жизнения цикъл, съдържаща процесите, дейностите и задачите, които трябва да бъдат изпълнени по време на създаването на софтуера.
Структурата на жизнения цикъл на софтуера според стандарта ISO / IEC 12207 се основава на три групи процеси:
· основни процесиЖизнен цикъл на софтуера (покупка, доставка, разработка, експлоатация, поддръжка);
· спомагателни процесиосигуряване на изпълнението на основни процеси (документация, управление на конфигурацията, осигуряване на качеството, проверка, сертифициране, оценка, одит, решаване на проблеми);
· организационни процеси(управление на проекта, създаване на инфраструктура на проекта, дефиниране, оценка и подобряване на самия жизнен цикъл, обучение).
развитиевключва цялата работа по създаване на софтуер и неговите компоненти в съответствие с определени изисквания, включително изготвяне на проектна и експлоатационна документация, подготовка на материали, необходими за тестване на функционалността и подходящото качество на софтуерните продукти, материали, необходими за организиране на обучение на персонала и др.
Разработката на софтуер включва, обикновено:
· анализ;
· дизайн;
· реализация (програмиране).
Фазата на разработка започва с проучване на осъществимостта на проекта и след това го превежда от потребителските изисквания във форма, която може да бъде внедрена на компютри.
Тази фаза обикновено представлява 50% от разходите за проектиране и 32% от разходите за труд.
Експлоатациязапочва, когато продуктът е предаден на потребителя, в употреба и в употреба.
Включва:
Работа по въвеждане в експлоатация на софтуерни компоненти, включително конфигуриране на база данни и потребителски работни станции;
Осигуряване на оперативна документация;
Провеждане на обучение на персонала и др., както и директна експлоатация, включително локализиране на проблеми и отстраняване на причините за възникването им,
Модифициране на софтуер в рамките на установените нормативи, изготвяне на предложения за подобряване, развитие и модернизация на системата.
Фаза на поддръжканаричана още фаза на текущо развитие.
Състои се от идентифициране и отстраняване на грешки в програмите и промяна на тяхната функционалност.
Практиците признават, че тази част от жизнения цикъл (LC) трябва да се вземе предвид от момента, в който започне разработката, за да се подобри дизайнът в съответствие с нуждите на потребителя.
Процес на поддръжка, ще продължи успоредно с дейността на ПИ.
Структурата на разходите за труд за различните видове поддържащи дейности е такава, че около 78% от времето се изразходва за промяна на функционалността на софтуера, а 17% за идентифициране на грешки.
Управление на конфигурациятае един от спомагателните процеси, които поддържат основните процеси от жизнения цикъл на софтуера, предимно процесите на разработка и поддръжка на софтуера. При създаването на сложни проекти на ИС, състоящи се от много компоненти, всеки от които може да има разновидности или версии, възниква проблемът да се вземат предвид техните връзки и функции, да се създаде единна структура и да се осигури развитието на цялата система. Управлението на конфигурацията ви позволява да организирате, систематично да отчитате и контролирате промените в софтуера на всички етапи от жизнения цикъл. Общи принципи и препоръки за отчитане на конфигурацията, планиране и управление на конфигурацията на софтуера са отразени в проекта на стандарт ISO 12207-2.
Осигуряване на качеството на проектасвързани с проблеми при верификация на софтуера, проверка и тестване. Проверкае процес на определяне дали текущото състояние на развитие, постигнато на даден етап, отговаря на изискванията на този етап. Прегледви позволява да оцените съответствието на параметрите на разработка с първоначалните изисквания. Проверката частично съвпада с тестване, което е свързано с идентифициране на разликите между реални и очаквани резултати и оценка на съответствието на характеристиките на софтуера с първоначалните изисквания. В процеса на изпълнение на проекта важно място заемат въпросите за идентифициране, описание и контрол на конфигурацията на отделните компоненти и на цялата система като цяло.
Управление на проектисвързани с проблемите на планирането и организирането на работата, създаването на екипи за развитие и наблюдението на времето и качеството на извършената работа. Техническата и организационна поддръжка на проекта включва избор на методи и инструменти за изпълнение на проекта, определяне на методи за описание на междинни състояния на развитие, разработване на методи и инструменти за тестване на софтуер, обучение на персонала и др.
Всеки процес се характеризира с:
конкретни задачи и методи за тяхното решаване,
първоначалните данни, получени на предишния етап,
резултати.
Резултатите от анализа са функционални модели, информационни модели и съответните им диаграми. Софтуерът за жизнен цикъл носи итеративен характер: Резултатите от следващия етап често причиняват промени в дизайнерските решения, разработени на по-ранни етапи.
Модели на жизнения цикъл на софтуера
Стандартът ISO/IEC 12207 не предоставя конкретен модел на жизнения цикъл и методи за разработка на софтуер. (Моделът на жизнения цикъл зависи от спецификата на информационната система и конкретните условия, в които същата се създава и функционира). Неговите разпоредби са общи за всички модели на жизнения цикъл, методологии и технологии за разработка. Стандартът ISO/IEC 12207 описва структурата на процесите на жизнения цикъл на софтуера, но не уточнява подробно как да се внедри или изпълни действияИ задачивключени в тези процеси.
Към днешна дата най-разпространени са следните два основни модела на жизнения цикъл:
· каскаден модел (70-85);
· спираловиден модел (86-90).
В първоначалния хомогенен IS всяко приложение беше едно цяло. За разработването на този тип приложение използвахме каскаден метод. Неговата основна характеристика е разделянето на цялото развитие на етапи, като преходът от един етап към следващия се извършва едва след като работата по текущия е напълно завършена (фиг. 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 OS подобни тенденции могат да се видят с просто око. Малко вероятно е днес да има поне един потребител, използващ системи като модификации 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-ия кадър, когато информацията се въвежда в съзнанието на потребителя независимо от него).
Разбира се, подобни технологии са забранени в света, но много от нас дори не осъзнават, че те все още могат да бъдат използвани и да повлияят на подсъзнанието по определен начин. Просто погледнете цената на „зомбирането“ от новинарски канали или интернет сайтове, да не говорим за използването на по-мощни средства, като излагане на инфразвук (това беше използвано в една оперна постановка), в резултат на което човек може да изпита страх или неподходящи емоции.
Връщайки се към софтуера, струва си да добавим, че някои програми използват звуков сигнал при стартиране, за да привлекат вниманието на потребителя. И както показват изследванията, такива приложения са по-жизнеспособни от други програми. Естествено, жизненият цикъл на софтуера също се увеличава, независимо каква функция му е била първоначално възложена. И, за съжаление, много разработчици използват това, което поражда съмнения относно законността на такива методи.
Но не е за нас да съдим това. Възможно е в близко бъдеще да бъдат разработени инструменти за идентифициране на такива заплахи. Засега това е само теория, но според някои анализатори и експерти остава много малко до практическото приложение. Ако вече създават копия на невронните мрежи на човешкия мозък, тогава какво да кажем?
Жизненият цикъл на софтуера включва шест етапа:
- анализ на изискванията;
– определяне на спецификациите;
- дизайн;
– кодиране;
– тестване;
– съпровод.
Анализ на изискванията. Той е изключително важен при разработването на софтуер. Грешките, допуснати на този етап, дори ако следващите етапи са извършени безупречно, могат да доведат до факта, че разработеният софтуерен продукт няма да отговаря на изискванията на практиката и обхвата на неговото приложение. За да създадете конкурентни продукти на този етап, трябва да получите ясни отговори на следните въпроси:
– Какво трябва да прави програмата?
– Кои са реалните проблеми, за чието решаване трябва да помогне?
– Какви са входните данни?
– Какви трябва да бъдат изходните данни?
– С какви ресурси разполага дизайнерът?
Дефиниране на спецификации. Спецификация– точно и пълно формално описание на свойствата, характеристиките и функциите на програма, елемент от данни или друг обект. До известна степен този етап може да се разглежда като формулиране на изводи, произтичащи от резултатите от предходния етап. Програмните изисквания трябва да бъдат изразени като набор от спецификации, които изрично определят характеристиките на изпълнение на бъдещата програма. Такива характеристики могат да включват скорост на изпълнение, количество консумирана памет, гъвкавост на използване и т.н.
Дизайн. На този етап се създава цялостната структура на програмата, която трябва да отговаря на спецификациите; определят се общите принципи на управление и взаимодействие между отделните компоненти на програмата.
Кодиране. Състои се от превод на структури, написани на език за проектиране, в език за програмиране.
Тестване. На този етап се извършва цялостна проверка на програмите.
Ескорт.Това е работният етап на системата. Колкото и сложно да е програмното тестване, за съжаление в големите софтуерни системи е изключително трудно да се премахнат абсолютно всички грешки. Отстраняването на грешките, открити по време на работа, е основната задача на този етап. Това обаче не е всичко, което се постига по време на поддръжката. Анализът на операционния опит на програмата, извършен по време на поддръжката, ни позволява да открием „тесни места“ или неуспешни дизайнерски решения в определени части на софтуерния пакет. В резултат на такъв анализ може да се вземе решение за извършване на работа за подобряване на разработената система. Поддръжката може също да включва консултации, обучение на потребители на системата, бързо предоставяне на информация на потребителите за нови версии на системата. Качеството на фазата на поддръжка до голяма степен определя търговския успех на софтуерния продукт.
Тестване. Има три аспекта за проверка на програма:
– коректност;
– ефективност на изпълнението;
– изчислителна сложност.
Валидирането гарантира, че програмата прави точно това, за което е проектирана. Математическото съвършенство на един алгоритъм не гарантира правилността на преобразуването му в програма. По същия начин, нито липсата на диагностични съобщения на компилатора, нито разумният вид на получените резултати предоставят достатъчна гаранция за коректността на програмата. Обикновено валидирането включва разработване и изпълнение на набор от тестове. Освен това, за да се изчислят програми, понякога е възможно да се сравнят получените решения с вече известно решение. Като цяло е невъзможно да се даде общо решение за проверка на коректността на една програма.
Тестването на изчислителната сложност, като правило, се състои от експериментален анализ на сложността на алгоритъм или експериментално сравнение на два или повече алгоритъма, които решават един и същ проблем.
Тестването на ефективността на внедряването е насочено към намиране на начин правилната програма да работи по-бързо или да използва по-малко памет. За да се подобри програмата, резултатите от внедряването се преглеждат по време на процеса на изграждане на алгоритъма. Без да разглеждаме всички възможни варианти и насоки за оптимизиране на програмите, тук ще представим някои полезни методи, насочени към увеличаване на скоростта на изпълнение на програмата.
Първият метод се основава на следното правило. Събирането и изваждането са по-бързи от умножението и делението. Аритметиката с цели числа е по-бърза от реалната аритметика. Така X+X е по-добро от 2*X, където * е знакът за умножение. Когато извършвате операции с цели числа, не забравяйте, че благодарение на използването на двоичната бройна система, умножението по кратни на две може да бъде заменено със съответния брой премествания наляво.
Вторият начин е да премахнете излишните изчисления.
Трети начин за тестване на ефективността на внедряване се основава на способността на някои компилатори да конструират код за оценка на булеви изрази, така че оценката да спре, когато резултатът стане очевиден. Например, в израза A или B или C, ако A е вярно, тогава променливите B и C вече не се проверяват. По този начин можете да спестите време, като поставите променливи A, B, C така, че първата променлива да е тази, която е най-вероятно да е вярна, а последната е тази, която е най-малко вероятно да е вярна.
Четвъртата техника е премахването на циклите.
Петата техника е разгръщането на цикли.
Това не е пълен списък с методи за оптимизация. Тук са дадени само най-очевидните от тях. Трябва също да се отбележи, че не винаги си струва да се увличате в преследването на скоростта, тъй като това най-често влошава четливостта на програмите. В случай, че печалбата е „незначителна“, едва ли си струва да я предпочитате пред яснотата и четливостта на програмата.
Софтуерът е набор от програми, предназначени за решаване на проблем. Жизненият цикъл на софтуера е периодът от време от момента, в който възниква необходимостта от създаване на софтуер, до момента, в който той бъде премахнат от експлоатация. Етапи от жизнения цикъл на софтуера, които могат да се появят последователно, паралелно или квазипаралелно:
1. развитие;
2. операция;
3. съпровод.
По време на фазата на поддръжка, като правило, се извършват следните видове работа:
- разширяване на функционалността на софтуера;
- модификация на съществуващи функции;
- Софтуерна модификация, свързана с хардуерна модификация;
- елиминиране на софтуерни грешки, които не са открити по време на разработката поради невъзможност за пълно тестване, а са се появили само по време на работа.
При извършване на разработката ясно се разграничават следните етапи:
- определяне на софтуерните изисквания, което включва събиране на необходимата информация.
- външен дизайн (информацията, съдържаща се в техническите спецификации, подлежи на анализ и стриктна формализация; основната цел на този етап е да даде на разработчика най-пълната и точна представа за това, което в крайна сметка трябва да се постигне). Не е задължително.
- вътрешен дизайн (информацията, получена на предишните етапи, се изяснява и се разработват структурите от данни, използвани в софтуера, определя се модулната структура на софтуера, правилата за взаимодействие на модулите в процеса на прехвърляне на контрол или обмен на информация и др. .).
- програмиране (кодиране).
- тестване и отстраняване на грешки. Тестването е процес на идентифициране на наличието на грешки в програмата. Дебъгване – тестване + диагностика и локализиране на грешки + отстраняване на грешки.
- софтуерно тестване. Тестването е специален вид тестване, чиято цел е да се идентифицират несъответствията между получения софтуер и изискванията на техническите спецификации.
Модели на жизнения цикъл на софтуера:
§ каскаден модел
§ спирален модел – при преминаване на едно завъртане на спиралата се получава софтуерна версия. След тестване се взема решение за разработване на следващата версия или да не се разработва, ако тази версия напълно отговаря на изискванията на техническите спецификации.
31. Технически спецификации (GOST 19.201 – 78). Неговите основни раздели и тяхното съдържание.
В съответствие с този стандарт техническите спецификации включват следните раздели:
2. въведение;
3. основа за развитие;
4. цел на разработката;
5. изисквания към програмния продукт;
6. изисквания към документацията;
7. технико-икономически показатели;
8. етапи и стадии на развитие;
9. процедура за контрол и приемане
10. приложение.
Въведение:
§ Име;
§ кратко описание на областта на приложение на софтуера.
Основната цел на този раздел е да покаже уместността на това развитие и какво място заема това развитие сред подобните.
Причина за развитие:
§ наименование на документа, въз основа на който се извършва разработката;
§ организация, одобрила този документ;
§ име или символ на темата за разработка.
Такъв документ може да бъде план, заповед, договор и др.
Цел на разработката:
§ описание на функционалното и оперативното предназначение на тази система, като се посочва категорията на нейните потребители.
Изисквания към програма или софтуерен продукт.
Този раздел трябва да включва следните подраздели:
1. изисквания към функционалните характеристики;
2. изисквания за надеждност;
3. условия на експлоатация;
4. изисквания към състава и параметрите на техническите средства;
5. изисквания за информационна и софтуерна съвместимост;
6. изисквания за етикетиране и опаковане;
7. изисквания за транспортиране и съхранение.
8. специални изисквания.
Разделът с изисквания за функционални характеристики трябва да изброява всички функции и да описва състава, характеристиките и формите на представяне на първоначалните данни и резултати. В същия раздел, ако е необходимо, посочете критерии за ефективност (максимално време за реакция на системата, максимално количество използвана памет).
Разделът с изискванията за надеждност трябва да посочи нивото на надеждност на софтуера, което трябва да бъде осигурено по време на разработката. В системи с нормални изисквания за надеждност, т.е. тези, които не са свързани със системи, в които има риск за човешкия живот, допълнително посочват действия за развитие на системата, насочени към повишаване на надеждността на системата (създаване на резервни копия, блокиране на опасни действия).
В раздела условия на работа са посочени специални изисквания за условията на работа на софтуера (температура, влажност). Такива изисквания са необходими, когато софтуерът ще работи (работи) в условия, различни от центъра за разработка. Ако условията не се различават, те допълнително показват, че няма изисквания или пропускат този раздел напълно. Този раздел понякога посочва видовете необходими услуги и квалификациите на персонала по поддръжката.
В раздела изискванията за състава и параметрите на техническите средства посочват необходимия състав и основните характеристики на техническите средства. В този раздел обикновено се посочват две конфигурации на техническо оборудване: минимална и номинална.
В раздела за изисквания за информация и софтуерна съвместимост, ако е необходимо, можете да посочите методи за програмиране, среда за разработка и използвана операционна система. Ако се предполага, че софтуерът ще се използва с друг софтуер, тогава този раздел трябва да предостави списък на този софтуер и да опише подробно интерфейса за взаимодействие на ниво формати на данни и API функции.
Разделът с изискванията за етикетиране и опаковане определя методите за маркиране и опаковане на софтуера.
Разделът с изисквания за транспортиране и съхранение определя условията за транспортиране, местата за съхранение, условията за съхранение и периодите на съхранение при различни условия.
Разделът със специални изисквания идентифицира изисквания, които не попадат в нито един от описаните по-горе раздели.
Изисквания към програмната документация.
Този раздел предоставя списък със софтуер и оперативна документация, които трябва да бъдат разработени заедно със софтуерния продукт. При необходимост се определят специални изисквания към структурата и състава на документите. Минимално количество документация: ръководство за потребителя.
Технико-икономически показатели.
Етапи и етапи на развитие.
В него се посочват етапите и етапите на развитие на извършваната работа, като се посочват срокове и изпълнители.
Процедура за контрол и приемане.
Той посочва процедурата за изпитване и общите изисквания за приемане.
Приложение:списък на изследователски проекти, обосновки, изчисления и други документи, които трябва да се използват за разработване.
В зависимост от характеристиките на разработвания софтуер е възможно да се изяснят описаните раздели, да се въведат нови или да се комбинират съществуващи.
32. Структурен софтуерен дизайн: метод на структурен анализ, проектиране на модулна структура.
Методът на структурния анализ се основава на редица общи принципи, изброени по-долу.
1. Принцип на разлаганеИ йерархично подреждане, което се състои в разделяне на голям и сложен проблем на множество по-малки независими подпроблеми, които са лесни за разбиране и решаване. Освен това може да се извърши декомпозиция за вече разпределени подзадачи. В резултат на такава последователна декомпозиция, определената система може да бъде разбрана и изградена според йерархични нива, всяко от които добавя нови детайли.
2. Принцип на абстракциясе състои в подчертаване на аспекти на системата, които са значими от някои позиции и абстрахиране от несъществуващи, за да се представи проблемът в удобна обща форма.
3. Принцип на формализиранесе крие в необходимостта от строг методически подход и решаване на проблеми.
4. Принципът на прикриванетосе състои в „скриване“ на информация, която не е съществена на определен етап: всяка част „знае“ само това, което е необходимо.
5. Принцип на пълнотае да се контролира наличието на ненужни елементи.
6. Принцип на последователностсе крие във валидността и последователността на елементите.
7. Принцип на логическата независимосте да се съсредоточи върху логическия дизайн, за да се гарантира независимост от физическото изпълнение.
8. Принцип на независимост на даннитее, че моделите на данни трябва да бъдат анализирани и проектирани независимо от техните процеси на логическа обработка, както и от тяхната физическа структура и разпределение в паметта на компютърната система.
9. Принцип на структуриране на даннитее, че данните трябва да бъдат структурирани и йерархично организирани.
Ръководейки се от всички принципи в тяхната цялост, на етапа на спецификация е възможно да се разбере какъв ще бъде разработваният софтуер, да се открият грешки и недостатъци, което от своя страна ще улесни работата на следващите етапи от жизнения цикъл.
За целите на специфицирането на системите в структурния анализ се използват три групи инструменти, илюстриращи:
* функции, които системата трябва да изпълнява;
* връзки между данните;
* зависимо от времето поведение на системата (аспекти в реално време).
За тази цел:
* DFD (Data Flow Diagrams) – диаграми на потока от данни заедно с речници на данни и спецификации на процеси;
* ERD (Entity–Relationship Diagrams) – диаграми entity–relationship;
* STD (State Transition Diagrams) – диаграми за преход на състояния.
DFD показва източници на данни и приемници, външни за системата, идентифицира логически функции (процеси) и групи от елементи на данни, които свързват една функция с друга (нишки), и идентифицира хранилища (хранилища за данни), до които има достъп. Структурите на потока от данни и дефинициите на техните компоненти се съхраняват в речник на данни. Всяка логическа функция може да бъде детайлизирана от DFD от по-ниско ниво. Когато подробностите са изчерпани, те преминават към описание на логиката с помощта на спецификация на процеса.
Структурата на всяко хранилище е описана с помощта на ERD. В случай на реално време, DFD се допълва с помощта на описание на зависимо от времето поведение на системата, което се описва с помощта на STD. Тези връзки са показани на фигурата.
Връзка между инструментите за структурен анализ
Проектиране на модулна конструкция.Модулът е отделна, функционално завършена софтуерна единица, която може да се използва самостоятелно или да бъде част от програма. Софтуерът е създаден на базата на модулна структура, състояща се от отделни модули.
Предимствата на разработването на софтуер чрез модули включват следното:
- Дизайнът на софтуера е опростен, тъй като сложен и голям проблем е по-лесен за разбиране, като се раздели на отделни функционални части.
- Това дава възможност за организиране на сътрудничество между големи екипи от разработчици, тъй като всеки програмист се занимава с независима част от софтуера - модул или група от модули.
- Програмите за отстраняване на грешки са опростени, тъй като ограниченият достъп до модула и недвусмислеността на неговото външно поведение елиминират влиянието на грешки в други модули върху неговото функциониране.
- Надеждността на програмите се увеличава, тъй като сравнително малкият размер на модулите и, като следствие, тяхната ниска сложност, позволяват по-пълна проверка на тях.
За проектиране и документиране на модулна структура се използват структурни карти на Константин, които са модел на връзките между софтуерните модули.
Структурната карта е насочена графа. Възлите на структурните карти съответстват на модули и области с данни, а дъгите изобразяват извиквания между модули. В този случай цикличните и условните повиквания се моделират от специални възли, прикрепени към дъги.
Елементи на структурни карти.
Основният елемент на структурната карта е модул. Има различни видове модули:
1. Самият модул се използва за представяне на обработващия софтуерен фрагмент и за локализирането му върху диаграмата.
2. Подсистема – набор от предварително дефинирани модули. Може да се използва повторно произволен брой пъти на всякакви диаграми.
3. Библиотеката се различава от подсистемата по това, че е дефинирана извън контекста на системата.
4. Областта за данни се използва за обозначаване на модули, съдържащи области на глобални (разпределени) променливи.
Видове модули на структурни карти.
Когато се изграждат структурни карти, добавянето на модули и свързването им заедно се извършва с помощта на потоци, които демонстрират йерархия от повиквания. Има последователни и паралелни разговори. Когато се извикват последователно, модулите могат да се извикват в произволен ред или едновременно.
Условните и итерационните възли се използват за моделиране на условни и циклични повиквания.
Изображения на условни и итеративни повиквания.
Типични модулни структури.В зависимост от задачите, решени от разработчика и от избрания метод на проектиране, модулният софтуер може да има една от следните основни структури: монолитен - модулен; последователно - модулни; модулно – йерархичен; модулно - хаотично.
а - монолитен; b - последователен; в - йерархичен; g – хаотично.
Монолитно-модулната структура включва голям софтуерен модул, който реализира повечето от функциите, възложени на програмата. От тази част има малък брой обаждания към други софтуерни модули с много по-малък размер. Такава структура носи всички недостатъци на принципа на немодулното програмиране: трудно е да се разбере, тества и поддържа.
Последователната модулна структура включва няколко модула, които последователно предават контрол един на друг. Тази структура е проста и интуитивна, но може да се приложи само за сравнително прости задачи.
Модулно-йерархичната структура включва софтуерни модули, разположени на различни нива на йерархията. Модулите от горно ниво управляват работата на модулите от по-ниско ниво. Тази структура е най-предпочитана и ви позволява да създавате доста сложни програми.
Модулни - хаотични структури. Такива програми са трудни за тестване и поддръжка. Тази структура е допустима само в системи в реално време със строги пространствено-времеви характеристики, когато е невъзможно да се постигнат с помощта на програми с различна структура.
Общи правила за структурно проектиране на софтуер.В началните етапи на разработката на софтуера се формират неговата структура и общи правила за взаимодействие на компонентите, които са както следва:
- софтуерната структура и правилата за форматиране на описанието на всеки софтуерен модул трябва да бъдат унифицирани;
- всеки модул се характеризира с функционална завършеност, автономност и независимост в дизайна от модулите, които го използват и които извиква;
- прилагат се стандартни правила за организиране на връзки между модула за управление и информация (данни) и други модули;
- Софтуерът е разработен под формата на набор от програмни модули, малък брой оператори (до 100), свързани по йерархичен начин;
- не трябва да има ефект след следващото изпълнение на програмата при следващи изпълнения;
- регламентирано е използването на локални променливи и компютърни регистри.
