Техническа документация. Техническа документация Провеждане на приемни изпитвания

Анотация: Логично продължение на предишната лекция. Подробно е разгледан проблемът за практическото приложение на GOST R ISO/IEC 12207 в организации и проекти. В тази връзка се изучават стандартите GOST R ISO/IEC 15271 и GOST R ISO/IEC 16326.

От предишната лекция трябва да стане очевидно, че внедряването на GOST R ISO/IEC 12207 е много трудна задача. Първо, не е ясно какво означава „прилагане на GOST R ISO/IEC 12207“? Може ли да се счита за внедрено, ако някои от процесите на организацията съвпадат с процесите на стандарта, а други не? Може ли един стандарт да се счита за внедрен, ако някои проекти се изпълняват в съответствие с него, а други не? Този списък с въпроси може да продължи безкрайно.

Не е случайно, че след GOST R ISO/IEC 12207 стандартът GOST R ISO/IEC 15271-02 (GOST 15271, 2002) е разработен специално за задачата за неговото прилагане, която се нарича „Ръководство за прилагане на GOST R ISO/IEC 12207”. Сега ще преминем към разглеждането му.

Стандарт GOST R ISO/IEC 15271

Значението на стандарта е разкрито в неговия уводен раздел.

"1.2. Потребители на стандарта.

Този стандарт може да се използва от субекти (лица, организации), които желаят да прилагат GOST R ISO/IEC 12207 при изпълнение на договори, независимо от обема или сложността на проекта, от конкретна организация за самонаблюдение или работа по подобряване процеси в жизнения цикълсофтуерни инструменти.

Този стандарт определя как GOST R ISO/IEC 12207 може да се използва по отношение на различни видове софтуер и какви процеси са подходящи за всеки случай.

Този стандарт допълва GOST R ISO/IEC 12207, който е не само нормативен документ, но и стандарт за управление на реален проект. (Например, последният случай възниква, когато GOST R ISO/IEC 12207 е модел за извършване на част от работата на процеса на подобряване). Този стандарт трябва да се чете като цяло, но специфични раздели могат да се използват в отделни случаи."

Стандартът GOST R ISO/IEC 15271 се състои от 8 раздела и 4 приложения. Разделите със съдържание се наричат ​​както следва (номерирането е взето от текста):

• 4. Основни концепции за развитие на GOST R ISO/IEC 12207.
• 5. Прилагане на GOST R ISO/IEC 12207.
• 6. Приложение в проекти.
• 7. Приложение в организации.
• 8. Приложение модели на жизнения цикълсистеми.

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

Раздел 5 представя общ подход към внедряването, наречен стратегия за внедряване на GOST R ISO/IEC 12207. Стратегията, според стандарта, е „типичен метод за внедряване, който трябва да се следва при извършване на промени в дейностите или проекта на организацията“. Стратегията се изпълнява като проект, състоящ се от задължителни стъпки, описани неформално и без никаква връзка с процесите на организацията. Тези стъпки са както следва:

• а) разработване на план за изпълнение;
• б) практическо приложение на GOST R ISO/IEC 12207;
• в) предоставяне на подкрепа пилотен проект(с);
• г) формализиране на начина на изпълнение;
• д) утвърждаване на начина на изпълнение.

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

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

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

• проекти за прилагане на GOST R ISO/IEC 12207;
• проект за обучение на всички нови служители в процесите на GOST R ISO/IEC 12207;
• проект за въвеждане на промени в изпълняваните процеси във връзка с промени в организационната структура на организацията; и така нататък.

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

Повече подробности за използването на GOST R ISO/IEC 12207 в проекти са описани в раздел 6 „Прилагане в проекти“. Стандартът предлага да се класифицират проектите и за тази цел се въвежда нова концепция - " модел на жизнения цикълсистеми" (списък на типичните модели е даден в Приложение C). Какво представлява моделът не е официално дефинирано. По-късно в раздел 8 се посочва, че "общите модел на жизнения цикълсистемите са разделени на етапи (етапи) с последващо адаптиране на всеки от тях към модели на жизнения цикълспецифична система" (следва списък на етапите). Разглеждат се общо три такива модела: каскаден, инкрементален, еволюционен. Техните предимства и недостатъци се анализират, след което процесите на GOST R ISO/IEC 12207 се "наслагват" върху структурата на моделите. В резултат на това тези процеси получават допълнителни свойства, например многократно повторение в жизнения цикъл или времево припокриване с други процеси аспекти на проекти Ето един типичен пример.

„6.1.3. Характеристики на системата

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

Примерен списък с характеристики на системно ниво (свързани със софтуера и подлежащи на разглеждане) включва:

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

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

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

Централната част на много краткия раздел 7 „Прилагане в организации” е следният текст.

"7.2. Възможности за приложение

Причините, поради които GOST R ISO/IEC 12207 се прилага в организациите, могат да бъдат следните:

• проверка на съвършенството на съществуващ метод. Това обикновено е случаят, когато методът е разработен от самата организация или тя е избрала и модифицирала съществуващ метод;
• практическо приложение на този метод за предотвратяване на риска, свързан с навлизането в нови пазарни сектори с по-строги изисквания, свързани с потенциален риск;
• разработване на нов метод, например за посрещане на нуждите на нова организация. Организациите, създадени чрез сливане или бизнес сътрудничество, могат да бъдат обхванати. Това може да е необходимо за поддържане на някои модели на процеси за предоставяне на специфична работа;
• Управление на внедряването на нова технология, като автоматизиране на ръчни процеси или промяна на методите, използвани за внедряване на софтуерен продукт. GOST R ISO/IEC 12207 установява критерии, които могат да се използват за наблюдение на съвършенството на съответния метод преди или след промяна в технологията;
• оценка на вътрешните възможности на страната по отношение на изпълнението на критериите на договора, например като страна, участваща в състезателния (тръжен) процес;
• идентифициране на етапи, които могат да доведат до разработването на по-напреднали програми, като одит в съответствие с GOST R ISO/IEC 12207 и използване на самия процес на подобрение."

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

И накрая, раздел 8 „Приложение модели на жизнения цикълсистеми" съдържа доста неясни определения" модели на жизнения цикълсистеми" и " модели на жизнения цикълсофтуер" и се опитва да установи съответствие между тях. Тъй като няма точни дефиниции, е невъзможно да се прецени резултатите.

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

Стандарт GOST R ISO/IEC 16326

Друг опит за формализиране на процеса на прилагане на GOST R ISO/IEC 12207 беше направен в стандарта GOST R ISO/IEC 16326 „Указания за използване на GOST R ISO/IEC 12207 в управлението на проекти“ (GOST 16326, 2002). Демонстрира опит за обединение процеси в жизнения цикълот GOST R ISO/IEC 12207 с процеси за управление на проекти от популярния методически справочник PMBOK 1 PMBOK - Съвкупност от знания за управление на проекти(PMBOK, 2009) и стандарта ISO 10006 (руската версия на стандарта се съдържа в (GOST 10006, 2005)). Това е показано схематично на фиг. 4.1 дадени в стандарта.

Ориз. 4.1.

Обхватът на потребителите на стандарта е доста точно определен в раздел 1.1.

„1.1. Обхват от потребители

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

• администратори, отговорни за организацията и непрекъснатото подобряване процеси в жизнения цикълсофтуер съгласно GOST R ISO/IEC 12207;
• администратори, отговорни за приложението процеси в жизнения цикълсофтуер съгласно GOST R ISO/IEC/12207 на ниво проектиране;
• организации или лица, които са подизпълнители при изпълнението на SCP ( Управление на софтуерни проекти. - АБ).

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

• участва в софтуерни проекти, но не и в AP ( Администратори на проекти. - АБ);
• които са администратори на несофтуерни проекти, но свързани с AP софтуер."

Сравнително краткият основен текст (раздел 6 „Ръководство“ заема само 9 страници от общо 35) е последователен коментар на процес 7.1 „Управление“ от GOST R ISO/IEC 12207 от гледна точка на PMBOK. Стилът на коментара е неформален, аргументите са предимно със съветнически характер. Коментарът не надхвърля обикновения здрав разум и не съдържа нищо ново. Като цяло това е полезно четиво за мениджъри (в терминологията на преводачите - „администратори“) на проекти, но нищо повече.

Приложение А е една голяма таблица, демонстрираща връзките между основните процеси на GOST R ISO/IEC 12207 и дейностите на процеса „Управление“, извикан от тях. Всички тези връзки се съдържат в основната част на стандарта GOST R ISO/IEC 12207; комбинирането им в една таблица не добавя никаква нова информация.

Приложение B е точно същата таблица, свързваща зони на процеси и отделни процеси от PMBOK с дейностите на процеса „Управление“ от GOST R ISO/IEC 12207.

Подобна таблица, където групи процеси в смисъла на PMBOK се използват вместо области, е дадена в Приложение C. Приложения B и C всъщност обобщават всичко, което беше казано в раздел 6 на стандарта. Не е ясно защо е необходимо това да се представя под формата на таблици. Тези таблици не предоставят никаква допълнителна информация, демонстрирайки само факта, че има връзки между PMBOK и GOST R ISO/IEC 12207. Статусът на двете приложения обаче е „референтен“, така че те може да не са имали независима стойност.

Друга обобщена таблица е представена в Приложение D. Тя показва връзките между три източника: GOST R ISO/IEC 12207, PMBOK и стандарта ISO 10006. Веднага ще отбележа, че последният е преведен на руски език едва през 2005 г.; в резултат на това терминологията, използвана в приложение D към стандарта GOST R ISO/IEC 16326 2002, се различава от по-късния. Както и в предишните случаи, смисълът на представянето на тези връзки в компактна таблична форма е неясен. Освен това общият обем на Приложения A-D надвишава повече от два пъти обема на основния раздел 6 „Наръчник“.

Според мен GOST R ISO/IEC 16326-2002 не се различава по форма и цел от GOST R ISO/IEC 15271-2002. И двамата страдат от излишък от разсъждения, които са правилни „като цяло“ и се основават само на здравия разум. Тези аргументи са очевидни за всеки, който има практически опит в управлението на проекти, и едва ли изглеждат разумни за тези, които нямат такъв опит. За разлика от GOST R ISO/IEC 15271-2002, стандартът GOST R ISO/IEC 16326-2002 е по-формален, но практическото значение на предложения формализъм не е ясно.

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

В допълнение към тези, обсъдени по-горе, GOST R ISO/IEC 12207 е родил редица стандарти, които подробно описват съдържащите се в него процеси в жизнения цикъл. Те включват, например, GOST R ISO/IEC 15910-2002 „Процесът на създаване на потребителска документация за софтуер“ (GOST 15910, 2002) и GOST R ISO/IEC 14764-2002 „Поддръжка на софтуер“ (GOST 14764, 2002) . Някои подобни стандарти на ISO все още не са преведени на руски; Вероятно в бъдеще броят на рускоезичните стандарти GOST R ISO, пряко свързани с GOST R ISO/IEC 12207, ще се увеличи.

Базово ниво съгласно GOST R ISO/IEC 12207-2010

или, които са били официално прегледани и впоследствие служат като основа за по-нататъшно развитие и които могат да бъдат променяни само чрез официални и контролирани промени [от точка 4.6 на GOST R ISO/IEC 12207-2010]

Валидиране съгласно GOST R ISO/IEC 12207-2010

Потвърждение (въз основа на представяне на обективни доказателства), че предвидената цел или приложение са изпълнени. Забележка - Валидирането в контекста е набор от действия, които гарантират и осигуряват увереност, че е в състояние да реализира своята цел, настояща и бъдеща [от клауза 4.54 на GOST R ISO/IEC 12207-2010]

Проверка съгласно GOST R ISO/IEC 12207-2010

Потвърждение (въз основа на предоставяне на обективни доказателства), че посочените изисквания са напълно изпълнени. ЗАБЕЛЕЖКА: Проверката в контекст е набор от действия, които сравняват резултат от жизнения цикъл с изискваните характеристики за този резултат. Резултатите от жизнения цикъл могат да бъдат (но не се ограничават до) определени изисквания, описание и директно [от клауза 4.55 на GOST R ISO/IEC 12207-2010]

Осигуряване на качеството съгласно GOST R ISO/IEC 12207-2010

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

1. Има вътрешни и външни гаранции за качество:
   1. вътрешно осигуряване на качеството: в рамките на осигуряването на качеството осигурява увереност;
   2. Външно осигуряване на качеството: В договорни ситуации осигуряването на качеството осигурява увереност на другите.
2. Някои дейности по осигуряване на качеството и осигуряване на качеството са взаимосвързани.
3. Освен ако изискванията за качество не отговарят напълно на нуждите, осигуряването на качеството не може да осигури необходимата увереност.

[от клауза 4.34 GOST R ISO/IEC 12207-2010]

5.2.2 Обобщение на процесите на жизнения цикъл

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

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

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

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

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

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

Процесите за организационна поддръжка на проекта включват:

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

Б) процес на управление на инфраструктурата;

в) процес на управление на портфолиото от проекти;

г) процес на управление на човешките ресурси;

д) процес на управление на качеството.

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

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

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

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

а) процес на планиране на проекта;

б) управление на проекта и процес на оценка.

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

а) процес на управление на решения;

б) процес на управление на риска;

в) процес на управление на конфигурацията;

г) процес на управление на информацията;

д) процес на измерване.

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

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

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

Техническите процеси се състоят от следните процеси:

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

б) анализ на системните изисквания (специален случай на процеса на анализ на изискванията);

C) проектиране на системна архитектура (специален случай на процеса на проектиране на архитектурата, даден в);

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

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

f) процес на тестване за квалификация на системата (процес, който допринася за постигане на резултатите от процеса на проверка, даден в );

G) процесът на инсталиране на софтуера (процесът, който допринася за постигане на резултатите от процеса на прехвърляне, описан в);

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

i) процеса на работа на софтуера (специален случай на процеса на работа, даден в);

j) процес на поддръжка на софтуер (специален случай на процеса на поддръжка, даден в );

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

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

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

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

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

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

B) процес на проектиране на софтуерната архитектура;

в) подробен процес на проектиране на софтуера;

г) процес на проектиране на софтуер;

д) процес на интегриране на софтуера;

f) процес на тестване на квалификацията на софтуера.

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

а) процес на управление на софтуерната документация;

б) процес на управление на конфигурацията на софтуера;

в) процес на осигуряване на качеството на софтуера;

г) процес на проверка на софтуера;

д) процес на валидиране на софтуера;

f) процес на одит на софтуера;

g) процес на одит на софтуера;

З) процесът на решаване на проблеми в софтуера.

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

Процесите за повторно използване на софтуера са:

а) процес на проектиране на домейн;

б) процес на управление на повторната употреба на активи;

C) процесът за управление на повторната употреба на програмата.

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

2) Осигурява максимална гъвкавост– много процеси и задачи са проектирани по такъв начин, че да могат да бъдат адаптирани в съответствие с конкретни проекти за ИС. Адаптирането се свежда до елиминиране на процеси, дейности и задачи, които не са приложими към конкретен проект.

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

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

5) Ценността на стандарта е, че той съдържа набори от задачи, качествени характеристики, критерии за оценка и др., предоставяйки цялостно покритие на дизайнерските решения.

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

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

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

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

Извършване на дейности и задачи, подходящи за даден софтуерен проект.

Комплексни стандарти GOST 34.

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

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

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

Според GOST разработването на автоматизирана система е разделено на следните стъпки и етапи:

Етап 1 формиране на изисквания към ораторите:

Етап а: проверка на съоръжението и обосновка на необходимостта от разработване на автоматизирана система;

Етап b: формиране на изискванията на клиента за автоматизирана система;

Етап c: изготвяне на доклад за извършената работа и изготвяне на заявка за изготвяне на технически спецификации.

Етап 2 развитие на концепцията:

а: изследване на обекта;

б: извършване на необходимите изследвания;

в: разработване на варианти за концепцията на АЕЦ, отговарящи на изискванията на клиента;

г: разработване на отчет за извършената работа.

Етап 3 разработване и одобряване на технически спецификации за създаване на атомни електроцентрали.

Етап 4 разработване на идеен проект на АЕЦ:

а: разработване на предварителни проектни решения за цялата система като цяло и за отделните й компоненти;

б: разработване на документация.

Етап 5 разработване на технически проекти:

а: разработване на проектни решения за цялата система и нейните части;

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

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

Етап 6 разработване на техническа документация:

а: разработване на работна документация за системната част;

b: разработване или адаптиране на софтуер.

Етап 7въвеждане в експлоатация на разработената система:

а: подготовка на обекта за автоматизация за внедряване на автоматизирани системи;

б: обучение на персонала;

в: софтуерно и хардуерно оборудване на говорителите;

г: монтажни работи;

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

д: предварителни тестове;

g: пробна експлоатация;

h: тестове за приемане.

Етап 8 ескорт:

а: извършване на работа в съответствие с гаранционните задължения;

b: следгаранционен сервиз.