Підготовка документації на програмні засоби (ПС) у відповідності з наявними ГОСТами (документація)

У своїй доповіді я спираюся на:


1. Основні питання при розробці програмних засобів


Коли програміст-розробник отримує в тій чи іншій формі завдання на програмування, перед ним, перед керівником проекту і перед всією проектною групою постають питання:


Крім згаданих питань є й інші.

На ці та безліч інших питань колись відповідали державні стандарти на програмну документацію? комплекс стандартів 19-ї серії ГОСТ ЕСПД. Але вже тоді у програмістів була маса претензій до цих стандартам. Що-то потрібно дублювати в документації багато разів (як, здавалося – невиправдано), а багато чого не було передбачено, як, наприклад, відображення специфіки документування програм, що працюють з інтегрованою базою даних.

В даний час залишається актуальним питання про наявність системи, що регламентує документування програмних засобів (ПЗ).

2. Загальна характеристика стану


Основу вітчизняної нормативної бази в області документування ПС становить комплекс стандартів Єдиної системи програмної документації (ЕСПД). Основна і велика частина комплексу ЕСПД була розроблена в 70-е і 80-і роки. Зараз цей комплекс являє собою систему міждержавних стандартів країн СНД (ГОСТ), що діють на території Російської Федерації на основі міждержавної угоди по стандартизації.

Стандарти ЕСПД в основному охоплюють ту частину документації, яка створюється в процесі розробки ПС, і пов'язані, здебільшого, з документуванням функціональних характеристик ПС. Слід зазначити, що стандарти ЕСПД (ГОСТ 19) носять рекомендаційний характер. Втім, це відноситься і до всіх інших стандартів у галузі ПС (ГОСТ 34, Міжнародному стандарту ISO / IEC, та ін.) Справа в тому, що відповідно до Закону РФ "Про стандартизацію" ці стандарти стають обов'язковими на контрактній основі – тобто при посиланні на них у договорі на розробку (поставку) ПС.

Говорячи про стан ЕСПД в цілому, можна констатувати, що велика частина стандартів ЕСПД морально застаріла.

До числа основних недоліків ЕСПД можна віднести:


Отже, ЕСПД потребує повний перегляд на основі стандарту ISO / IEC 12207-95 на процеси життєвого циклу ПС про це стандарті далі буде сказано докладніше).

Треба сказати, що поряд з комплексом ЕСПД офіційна нормативна база РФ в області документування ПС та в суміжних областях включає ряд перспективних стандартів (вітчизняного, міждержавного і міжнародного рівнів).

Міжнародний стандарт ISO/IEC 12207: 1995-08-01 на організацію ЖЦ продуктів програмного забезпечення (ПЗ) – здавалося б дуже неконкретний, але цілком новий і почасти "модний" стандарт.

Стандарти комплексу ГОСТ 1934 на створення та розвиток автоматизованих систем (АС) – узагальнені, але сприймаються як дуже жорсткі за структурою ЖЦ та проектної документації. Але ці стандарти багатьма вважаються бюрократичними до шкідливості і консервативними до застарілості. Наскільки це так, а наскільки ГОСТ 34 залишається працюють з користю – корисно розібратися.

У своїй статті Є. З. Зіндер детально зупиняється на методиці Oracle CDM (Custom Development Method) з розробки прикладних інформаційних систем під замовлення – конкретний матеріал, деталізований до рівня заготовок проектних документів, розрахованих на пряме використання у проектах АС з опорою на інструментарій Oracle.

2.1. Короткий подання стандартів ЕСПД


Тим не менш, до перегляду всього комплексу, багато стандартів ЕСПД можуть з користю застосовуватися у практиці документування ПС. Ця позиція заснована на наступному:


При цьому стиль застосування стандартів може відповідати сучасному загальному стилю адаптації стандартів до специфіки проекту: замовник і керівник проекту вибирають доречне в проекті підмножина стандартів і ПД, доповнюють вибрані ПД потрібними розділами і виключають непотрібні, прив'язують створення цих документів до тієї схеми ЖЦ, яка використовується в проекті.

Стандарти ЕСПД (як і інші ГОСТи) поділяють на групи, пріведTнние в таблиці:


































Kод групи 

Найменування групи 

0 Загальні положення
1 Основоположні стандарти
2 Правила виконання документації розробки
3 Правила виконання документації виготовлення
4 Правила виконання документації супроводу
5 Правила виконання експлуатаційної документації
6 Правила поводження програмної документації
7 Резервні групи
8
9 Інші стандарти

Позначення стандарту ЕСПД будують за класифікаційною ознакою:

Позначення стандарту ЕСПД має складатися з:


Перелік документів ЕСПД


  1. ГОСТ 19.001-77 ЕСПД. Загальні положення.
  2. ГОСТ 19.101-77 ЕСПД. Види програм і програмних документів.
  3. ГОСТ 19.102-77 ЕСПД. Стадії розробки.
  4. ГОСТ 19.103-77 ЕСПД. Позначення програм і програмних документів.
  5. ГОСТ 19.104-78 ЕСПД. Основні написи.
  6. ГОСТ 19.105-78 ЕСПД. Загальні вимоги до програмних документів.
  7. ГОСТ 19.106-78 ЕСПД. Вимоги до програмних документів, виконаним друкованим способом.
  8. ГОСТ 19.201-78 ЕСПД. Технічне завдання. Вимоги до змісту та оформлення.
  9. ГОСТ 19.202-78 ЕСПД. Специфікація. Вимоги до змісту та оформлення.
  10. ГОСТ 19.301-79 ЕСПД. Порядок і методика випробувань.
  11. ГОСТ 19.401-78 ЕСПД. Текст програми. Вимоги до змісту та оформлення.
  12. ГОСТ 19.402-78 ЕСПД. Опис програми.
  13. ГОСТ 19.404-79 ЕСПД. Пояснювальна записка. Вимоги до змісту та оформлення.
  14. ГОСТ 19.501-78 ЕСПД. Формуляр. Вимоги до змісту та оформлення.
  15. ГОСТ 19.502-78 ЕСПД. Опис застосування. Вимоги до змісту та оформлення.
  16. ГОСТ 19.503-79 ЕСПД. Керівництво системного програміста. Вимоги до змісту та оформлення.
  17. ГОСТ 19.504-79 ЕСПД. Керівництво програміста.
  18. ГОСТ 19.505-79 ЕСПД. Керівництво оператора.
  19. ГОСТ 19.506-79 ЕСПД. Опис мови.
  20. ГОСТ 19.508-79 ЕСПД. Керівництво з технічного обслуговування. Вимоги до змісту та оформлення.
  21. ГОСТ 19.604-78 ЕСПД. Правила внесення змін у програмні документи, що їх друкарським способом.
  22. ГОСТ 19.701-90 ЕСПД. Схеми алгоритмів, програм, даних і систем. Умовні позначення і правила виконання.
  23. ГОСТ 19.781-90. Забезпечення систем обробки інформації програмне.

Терміни та визначення

З усіх стандартів ЕСПД зупинимося тільки на тих, які можуть частіше використовуватися на практиці.

Першим вкажемо стандарт, що можна використовувати для формування завдань на програмування.

ГОСТ (СТ РЕВ) 19.201-78 (1626-79). ЕСПД. Технічне завдання. Вимога до змісту та оформлення. (Перевидано в листопаді 1987р з изм.1).

Технічне завдання (ТЗ) містить сукупність вимог до ПС і може використовуватися як критерій перевірки та приймання розробленої програми. Тому досить повно складене (з урахуванням можливості внесення додаткових розділів) і прийняте замовником і розробником, ТЗ є одним з основоположних документів проекту ПС.

Технічне завдання повинно містити наступні розділи:


Залежно від особливостей програми або програмного вироби допускається уточнювати зміст розділів, вводити нові розділи або об'єднувати окремі з них.

Наступний стандарт
ГОСТ (СТ РЕВ) 19.101-77 (1626-79). ЕСПД. Види програм і програмних документів (Перевидано в листопаді 1987р з изм.1).
Встановлює види програм і програмних документів для обчислювальних машин, комплексів і систем незалежно від їх призначення і області застосування.

Види програм











Вид програми 

Визначення 

Компонент Програма, що розглядається як єдине ціле, що виконує закінчену функцію і застосовувана самостійно або в складі комплексу
Комплекс Програма, що складається з двох або більше компонентів і (або) комплексів, що виконують взаємозв'язані функції, і вживана самостійно або в складі іншого комплексу

Види програмних документів





























Вид програмного документа 

Зміст програмного документа  

Специфікація Склад програми та документації на неї
Відомість власників оригіналів Перелік підприємств, на яких зберігають оригінали програмних документів
Текст програми Запис програми з необхідними коментарями
Опис програми Відомості про логічну структуру та функціонування програми
Програма та методика випробувань Вимоги, які підлягають перевірці при випробуванні програми, а також порядок і методи їх контролю
Технічне завдання Призначення і область застосування програми, технічні, техніко-економічні та спеціальні вимоги, які пред'являються до програми, необхідні стадії і терміни розробки, види випробувань
Пояснювальна записка Схема алгоритму, загальний опис алгоритму та (або) функціонування програми, а також обгрунтування прийнятих технічних і техніко-економічних рішень
Експлуатаційні документи Відомості для забезпечення функціонування та експлуатації програми

Види експлуатаційних документів





























Вид експлуатаційного документа 

Зміст експлуатаційного документа 

Відомість експлуатаційних документів Перелік експлуатаційних документів на програму
Формуляр Основні характеристики програми, комплектність і відомості про експлуатацію програми
Опис застосування Відомості про призначення програми, області застосування, застосовувані методи, класі вирішуваних завдань, обмеження для застосування, мінімальної конфігурації технічних засобів
Керівництво системного програміста Відомості для перевірки, забезпечення функціонування та налаштування програми на умови конкретного застосування
Керівництво програміста Відомості для експлуатації програми
Керівництво оператора Відомості для забезпечення процедури спілкування оператора з обчислювальною системою в процесі виконання програми
Опис мови Опис синтаксису і семантики мови
Керівництво з технічного обслуговування Відомості для застосування тестових і діагностичних програм при обслуговуванні технічних засобів

Залежно від способу виконання та характеру застосування програмні документи поділяються на оригінал, дублікат і копію (ГОСТ 2.102-68), призначені для розробки, супроводу та експлуатації програми.

Види програмних документів, що розробляються на різних стадіях, та їх коди






















































































































Код виду документа  Вид документа  Стадії розробки 
Ескізний проект  Технічний проект  Робочий проект 
компонент  комплекс 
Специфікація ! +
05 Відомість власників оригіналів ?
12 Текст програми + ?
13 Опис програми ? ?
20 Відомість експлуатаційних документів ? ?
30 Формуляр ? ?
31 Опис застосування ? ?
32 Керівництво системного програміста ? ?
33 Керівництво програміста ? ?
34 Керівництво оператора ? ?
35 Опис мови ? ?
46 Керівництво з технічного обслуговування ? ?
51 Програма та методика випробувань ? ?
81 Пояснювальна записка ? ?
90-99 Інші документи ? ? ? ?
















Умовні позначення:

+

– Документ обов'язковий;

!

– Документ обов'язковий для компонентів, що мають самостійне застосування;

?

– Необхідність складання документа визначається на етапі розробки і затвердження технічного завдання;
– Документ не складають.

Допускається об'єднувати окремі види експлуатаційних документів (за винятком відомості експлуатаційних документів та формуляра). Необхідність об'єднання цих документів вказується в технічному завданні. Об'єднаному документу привласнюють найменування і позначення одного з об'єднуваних документів. У об'єднаних документах мають бути наведені відомості, які необхідно включати в кожен поєднуваний документ.

ГОСТ 19.102-77. ЕСПД. Стадії розробки.


Встановлює стадії розробки програм і програмної документації для обчислювальних машин, комплексів і систем незалежно від їх призначення і області застосування

Стадії розробки, етапи і зміст робіт












































Стадії розробки 

Етапи робіт 

Зміст робіт 

Технічне завдання Обгрунтування необхідності розробки програми Постановка завдання.
Збір вихідних матеріалів.
Вибір і обгрунтування критеріїв ефективності та якості розроблюваної програми.
Обгрунтування необхідності проведення науково-дослідних робіт.
Науково-дослідні роботи Визначення структури вхідних та вихідних даних.
Попередній вибір методів рішення завдань.
Обгрунтування доцільності застосування раніше розроблених програм.
Визначення вимог до технічних засобів.
Обгрунтування принципової можливості вирішення поставленої задачі.
Розробка та затвердження технічного завдання Визначення вимог до програми.
Розробка техніко-економічного обгрунтування розробки програми.
Визначення стадій, етапів і термінів розробки програми та документації на неї.
Вибір мов програмування.
Визначення необхідності проведення науково-дослідних робіт на подальших стадіях.
Узгодження та затвердження технічного завдання.
Ескізний проект Розробка ескізного проекту Попередня розробка структури вхідних та вихідних даних.
Уточнення методів розв'язання задачі.
Розробка загального опису алгоритму розв'язання задачі.
Розробка техніко-економічного обгрунтування.
Затвердження ескізного проекту Розробка пояснювальної записки.
Узгодження та затвердження ескізного проекту
Технічний проект Розробка технічного проекту Уточнення структури вхідних та вихідних даних.
Розробка алгоритму рішення задачі.
Визначення форми представлення вхідних і вихідних даних.
Визначення семантики та синтаксису мови.
Розробка структури програми.
Остаточне визначення конфігурації технічних засобів.
Затвердження технічного проекту Розробка плану заходів щодо розробки та впровадження програм.
Розробка пояснювальної записки.
Узгодження та затвердження технічного проекту.
Робочий проект Розробка програми Програмування та налагодження програми
Розробка програмної документації Розробка програмних документів відповідно до вимог ГОСТ 19.101-77.
Випробування програми Розробка, узгодження і затвердження програми та методики випробувань.
Проведення попередніх державних, міжвідомчих, приймально-здавальних та інших видів випробувань.
Коригування програми і програмної документації за результатами випробувань.
Впровадження Підготовка і передача програми Підготовка і передача програми і програмної документації для супроводу і (або) виготовлення.
Оформлення і затвердження акту про передачу програми на супровід і (або) виготовлення.
Передача програми до фонду алгоритмів і програм.

Примітки:


  1. Допускається виключати другу стадію розробки, а в технічно обгрунтованих випадках – другу і третю стадії. Необхідність проведення цих стадій вказується в технічному завданні.
  2. Допускається об'єднувати, виключати етапи робіт та (або) їх зміст, а також вводити інші етапи робіт за погодженням із замовником.

ГОСТ 19.103-77 ЕСПД. Позначення програм і програмних документів


Код країни-розробника і код організації-розробника присвоюють в установленому порядку.


ГОСТ 19.105-78 ЕСПД. Загальні вимоги до програмних документів


Цей стандарт встановлює загальні вимоги до оформлення програмних документів для обчислювальних машин, комплексів і систем, незалежно від їх призначення і сфери застосування і передбачених стандартами Єдиної системи програмної документації (ЕСПД) для будь-якого способу виконання документів на різних носіях даних.

Програмний документ може бути представлений на різних типах носіїв даних і складається з наступних умовних частин:
титульної;
інформаційної;
основною.

Правила оформлення документа і його частин на кожному носії даних встановлюються стандартами ЕСПД на правила оформлення документів на відповідних носіях даних.

ГОСТ 19.106-78 ЕСПД. Вимоги до програмних документів, виконаним друкованим способом


Програмні документи оформляють:


Розташування матеріалів програмного документа здійснюється в наступній послідовності:


титульна частина:


  • лист твердження (не входить в загальну кількість аркушів документа);
  • титульний аркуш (перший аркуш документа);

інформаційна частина:


  • анотація;
  • лист змісту;

основна частина:


  • текст документа (з малюнками, таблицями тощо)
  • перелік термінів і їх визначень;
  • перелік скорочень;
  • додатки;
  • предметний покажчик;
  • перелік документів, які документів;

частина реєстрації змін:


  • лист реєстрації змін.

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

Наступний стандарт орієнтований на документування результуючого продукту розробки:

ГОСТ 19.402-78 ЕСПД. Опис програми


Склад документа "Опис програми" в своїй змістовній частині може доповнюватися розділами і пунктами, почерпнутими із стандартів для інших описових документів і керівництв: ГОСТ 19.404-79 ЕСПД. Пояснювальна записка, ГОСТ 19.502-78 ЕСПД. Опис застосування, ГОСТ 19.503-79 ЕСПД. Керівництво системного програміста, ГОСТ 19.504-79 ЕСПД. Керівництво програміста, ГОСТ 19.505-79 ЕСПД. Керівництво оператора.

Є також група стандартів, що визначає вимоги до фіксації всього набору програм і ПД, які оформляються для передачі ПС. Вони породжують лаконічні документи облікового характеру і можуть бути корисні для впорядкування всього господарства програм і ПД (адже дуже часто потрібно просто навести елементарний порядок!). Є і стандарти, що визначають правила ведення документів у "господарстві" ПС.

Треба також виділити

ГОСТ 19.301-79 ЕСПД. Програма та методика випробувань, який (в адаптованому вигляді) може використовуватися для розробки документів планування та проведення випробувальних робіт з оцінки готовності та якості ПС.

Нарешті, останній по року прийняття стандарт.

ГОСТ 19.701-90 ЕСПД. Схеми алгоритмів, програм, даних і систем. Позначення умовні графічні та правила виконання.

Він встановлює правила виконання схем, що використовуються для відображення різних видів задач обробки даних і засобів їх вирішення і повністю відповідає стандарту ІСО 5807:1985.

Поряд з ЕСПД на міждержавному рівні діють ще два стандарти, також відносяться до документування ПС і прийнятих не так давно, як більша частина ГОСТ ЕСПД.

ГОСТ 19781-90 Забезпечення систем обробки інформації програмне. Терміни та визначення. Розроблено заміну ГОСТ 19.781-83 та ГОСТ 19.004-80 і встановлює терміни та визначення понять у галузі програмного забезпечення (ПЗ) систем обробки даних (СОД), що застосовуються у всіх видах документації та літератури, що входять до сфери робіт зі стандартизації або використовують результати цих робіт.

ГОСТ 28388-89 Системи обробки інформації. Документи на магнітних носіях даних. Порядок виконання та обігу. Поширюється не тільки на програмні, але й на конструкторські, технологічні та інші проектні документи, що їх на магнітних носіях.

2.2. Стандарти комплексу ГОСТ 1934


ГОСТ 34 замислювався в кінці 80-х років як всеосяжний комплекс взаємопов'язаних міжгалузевих документів. Мотиви і вийшли результати описані нижче в "особливості" ГОСТ 34. Об'єктами стандартизації є АС різних (будь-яких!) видів і всі види їх компонентів, а не тільки ПО і БД.

Комплекс розрахований на взаємодію замовника і розробника. Аналогічно ISO12207 передбачено, що замовник може розробляти АС для себе сам (якщо створить для цього спеціалізований підрозділ). Проте формулювання ГОСТ 34 не орієнтовані на настільки явне і, у відомому сенсі, симетричне відображення дій обох сторін, як ISO12207. Оскільки ГОСТ 34 в основному приділяє увагу вмісту проектних документів, розподіл дій між сторонами зазвичай робиться відштовхуючись від цього змісту.

З усіх існуючих і не реалізованих груп документів будемо грунтуватися тільки на Групі 0 "Загальні положення" і Групі 6 "Створення, функціонування та розвиток АС". Найбільш популярними можна вважати стандарти ГОСТ 34.601-90 (Стадії створення АС), ГОСТ 34.602-89 (ТЗ на створення АС) та методичні вказівки РД 50-34.698-90 (Вимоги до змісту документів). Стандарти передбачають стадії та етапи виконання робіт зі створення АС, але не передбачають наскрізних процесів у явному вигляді.

Для загального випадку розробки АС стадії і етапи ГОСТ 34 наведено в таблиці:


























1. ФТ – Формування вимог до АС. 1.1. Обстеження об'єкта та обгрунтування необхідності створення АС;
1.2. Формування вимог користувача до АС;
1.3. Оформлення звіту про виконану роботу та заявки на розробку АС (тактико-технічного завдання);
2. РК – Розробка концепції АС. 2.1. Вивчення об'єкта;
2.2. Проведення необхідних науково-дослідних робіт;
2.3. Розробка варіантів концепції АС, що задовольняє вимогам користувача
2.4. Оформлення звіту про виконану роботу
3. ТЗ – Технічне створення АС. 3.1. Розробка та затвердження технічного завдання на завдання.
4. ЕП – Ескізний проект. 4.1. Розробка попередніх проектних рішень по системі та її частин;
4.2. Розробка документації на АС і її частини.
5. ТП – Технічний проект. 5.1. Розробка проектних рішень по системі та її частин;
5.2. Розробка документації на АС та її частини;
5.3. Розробка та оформлення документації на постачання виробів для комплектування АС і / або технічних вимог (технічних завдань) на їх розробку;
5.4. Розробка завдань на проектування в суміжних частинах проекту об'єкта автоматизації.
6. РД – Робоча документація. 6.1. Розробка робочої документації на систему і її частини;
6.2. Розробка або адаптація програм.
7. ВД – Введення в дію. 7.1. Підготовка об'єкта автоматизації до введення АС в дію;
7.2. Підготовка персоналу;
7.3. Комплектація АС поставляються виробами (програмними та технічними засобами, програмно-технічними комплексами, інформаційними виробами);
7.4. Будівельно-монтажні роботи;
7.5. Пуско-налагоджувальні роботи;
7.6. Проведення попередніх випробувань;
7.7. Проведення дослідної експлуатації;
7.8. Проведення приймальних випробувань.
8. Сп – Супровід АС. 8.1. Виконання робіт відповідно до гарантійних зобов'язань;
8.2. Післягарантійне обслуговування.

Описано зміст документів, що розробляються на кожному етапі. Це визначає потенційні можливості виділення на змістовному рівні наскрізних робіт, виконуваних паралельно або послідовно (то тобто по суті – процесів), і складових їх завдань. Такий прийом може використовуватися при побудові профілю стандартів ЖЦ проекту, що включає погоджені підмножини стандартів ГОСТ 34 і ISO12207.

Головний мотив: розв'язати проблему "вавілонської вежі".

У 80-х роках склалося становище, при якому в різних галузях і сферах діяльності використовувалася погано узгоджена або неузгоджена НТД – "нормативно-технічна документація". Це ускладнювало інтеграцію систем, забезпечення їх ефективного спільного функціонування. Діяли різні комплекси і системи стандартів, що встановлюють вимоги до різних видів АС.

Практика застосування стандартів показала, що в них застосовується по суті (але не за суворими визначень) єдина система понять, є багато спільних об'єктів стандартизації, проте вимоги стандартів не узгоджені між собою, є відмінності по складу і змісту робіт, відмінності по позначенню, складу, змісту та оформлення документів та ін

Звичайно, ця ситуація частково відображала і природне розмаїття умов розробки АС, цілей розробників, застосовуваних підходів та методик.

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


  1. Виробити одну узагальнену понятійну та термінологічну систему, загальну схему розробки, загальний набір документів з їх змістом і визначити їх як обов'язкові для всіх АС;
  2. Визначити також одну загальну понятійну та термінологічну систему, узагальнений комплекс системних вимог, набір критеріїв якості, але надати максимальну свободу у виборі схеми розробки, складу документів та інших аспектів, наклавши тільки мінімум обов'язкових вимог, які дозволяли б:

    • визначати рівень якості результату;
    • вибирати ті конкретні методики (з їх моделями ЖЦ, набором документів та ін), які найбільш підходять до умов розробки і відповідають використовуваним Інформаційних Технологій;
    • працювати, таким чином, з мінімальними обмеженнями ефективних дій проектувальника АС.

Розробники комплексу стандартів 34 вибрали спосіб, близький до першого з зазначених вище, тобто пішли шляхом, більш близького до схем конкретних методик, ніж до стандартів типу ISO12207. Тим не менш, завдяки спільності понятійної бази стандарти залишаються застосовними в досить широкому діапазоні випадків.

Ступінь адаптивності формально визначається можливостями:


Стадії і етапи, що виконуються організаціями – учасниками робіт зі створення АС, встановлюються в договорах і технічному завданні, що близько до підходу ISO.

Введення єдиної, достатньо якісно певної термінології, наявність досить розумною класифікації робіт, документів, видів забезпечення і ін безумовно корисно. ГОСТ 34 сприяє більш повної та якісної стикуванні дійсно різних систем, що особливо важливо в умовах, коли розробляється все більше складних комплексних АС, наприклад, типу CAD-CAM, які включають до свого складу АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНИ та ін системи.

Визначено декілька важливих положень, що відображають особливості АС як об'єкта стандартизації, наприклад: "у загальному випадку АС складається з програмно-технічних (ПТК), програмно-методичних (ПМК) комплексів і окремих компонентів організаційного, технічного, програмного та інформаційного забезпечення ".

Поділ понять ПТК і АС закріплювало принцип, за яким АС є не "ІС з БД", але:


Ці визначення вказують на те, що АС – це, в першу чергу, персонал, який приймає рішення і виконує інші керуючі дії, підтриманий організаційно-технічними засобами.

Ступінь обов'язковості:

колишня повна обов'язковість відсутня, матеріали ГОСТ34 по суті стали методичною підтримкою, причому частіше для замовників, що мають у стандарті набір вимог до змісту ТЗ та проведення випробувань АС. При цьому користь ГОСТ34 може багаторазово зрости у разі їх більш гнучкого використання при формуванні профілю ЖЦ АС.

Ключовим документом взаємодії сторін є ТЗ – технічне завдання на створення АС. ТЗ є основним вихідним документом для створення АС і його прийому, ТЗ визначає найважливіші точки взаємодії замовника та розробника. При цьому ТЗ розробляє організація-розробник (за ГОСТ 34.602-89), але формально видає ТЗ розробнику замовник (по РД 50-680-88).

2.3. Державні стандарти РФ (ГОСТ Р)


У РФ діє ряд стандартів в частині документування ПС, розроблених на основі прямого застосування міжнародних стандартів ІСО. Це? "найсвіжіші" за часом прийняття стандарти. Деякі з них прямо адресовані керівникам проекту або директорам інформаційних служб. Разом з тим вони невиправдано мало відомі в середовищі професіоналів. Ось їх подання.

ДСТУ ISO / IEC 9294-93 Інформаційна технологія. Керівництво з управління документуванням програмного забезпечення. Стандарт повністю відповідає міжнародному стандарту ISO / IEC ТО 9294:1990 і встановлює рекомендації з ефективного управління документуванням ПС для керівників, відповідальних за їх створення. Метою стандарту є надання допомоги у визначенні стратегії документування ПС; виборі стандартів з документування; виборі процедур документування; визначенні необхідних ресурсів; складанні планів документування.

ДСТУ ISO / IEC 9126-93 Інформаційна технологія. Оцінка програмної продукції. Характеристики якості і керівництва щодо їх застосування. Стандарт повністю відповідає міжнародному стандарту ISO / IEC 9126:1991. У його контексті під характеристикою якості розуміється "набір властивостей (атрибутів) програмної продукції, за якими її якість описується й оцінюється". Стандарт визначає шість комплексних характеристик, які з мінімальним дублюванням описують якість ПС (ПЗ, програмної продукції): функціональні можливості; надійність; практичність; ефективність; сопровождаемость; мобільність. Ці характеристики утворюють основу для подальшого уточнення та опису якості ПС.

ДСТУ ISO 9127-94 Системи обробки інформації. Документація користувача та інформація на упаковці для споживчих програмних пакетів. Стандарт повністю відповідає міжнародному стандарту ІСО 9127:1989. У контексті цього стандарту під споживчим програмним пакетом (ПП) розуміється "програмна продукція, спроектована і продається для виконання певних функцій; програма і відповідна їй документація, упаковані для продажу як єдине ціле ". Під документацією користувача розуміється документація, яка забезпечує кінцевого користувача інформацією з установки та експлуатації ПП. Під інформацією на упаковці розуміють інформацію, відтворну на зовнішній упаковці ПП. Її метою є надання потенційним покупцям первинних відомостей про ПП.

ДСТУ ISO / IEC 8631-94 Інформаційна технологія. Програмні конструктиви і умовні позначення для їх подання. Описує подання процедурних алгоритмів.

2.4. Міжнародний стандарт ISO / IEC 12207: 1995-08-01


Перша редакція ISO12207 підготовлена в 1995 році об'єднаним технічним комітетом ISO / IEC JTC1 "Інформаційні технології, підкомітет SC7, проектування програмного забезпечення".

За визначенням, ISO12207 – базовий стандарт процесів ЖЦ ПЗ, орієнтований на різні (любие!) види ПО і типи проектів АС, куди ПО входить як частина. Стандарт визначає стратегію і загальний порядок у створенні та експлуатації ПЗ, він охоплює ЖЦ ПЗ від концептуалізації ідей до завершення ЖЦ.

Дуже важливі ЗАУВАЖЕННЯ СТАНДАРТУ:


  1. Процеси, що використовуються під час ЖЦ ПЗ, повинні бути сумісні з процесами, що використовуються під час ЖЦ АС. (Звідси зрозуміла доцільність спільного використання стандартів на АС і на ПЗ.)
  2. Додавання унікальних чи специфічних процесів, дій і завдань має бути обумовлено в контракті між сторонами. Контракт розуміється в широкому сенсі: від юридично оформленого контракту до неформального угоди, угода може бути визначено і єдиною стороною як завдання, поставлене самому собі.
  3. Стандарт принципово не містить конкретні методи дій, тим більше – заготовки рішень або документації. Він описує архітектуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати послуги та завдання, включені в процеси, не призначений для предпісиванія імені, формату або точного вмісту одержуваної документації. Рішення такого типу приймаються використовують стандарт.

ВИЗНАЧЕННЯ СТАНДАРТУ:


  1. Система – це об'єднання одного або більше процесів, апаратних засобів, програмного забезпечення, обладнання і людей для забезпечення можливості задоволення певних потреб чи цілей.
  2. Модель життєвого циклу – Структура, що містить процеси, дії і завдання, які здійснюються в ході розробки, функціонування та супроводу програмного продукту протягом всього життя системи, від визначення вимог до завершення її використання.
    Безліч процесів і завдань сконструйовано так, що можлива їх адаптація відповідно до проектів ПЗ. Процес адаптації є процесом винятку процесів, видів діяльності та завдань, не застосовних в конкретному проекті. Ступінь адаптивності: максимальна
  3. Вимога кваліфікації – Набір критеріїв або умов (кваліфікаційні вимоги), які повинні бути задоволені для того, щоб кваліфікувати програмний продукт як підпорядкований (задовольняє умовам) його специфікаціям і готовий для використання в цільової навколишньому середовищу.

Стандарт не наказує конкретну модель ЖЦ або метод розробки ПЗ, але визначає, що сторони-учасниці використання стандарту відповідальні за вибір моделі ЖЦ для проекту ПЗ, за адаптацію процесів і завдань стандарту до цієї моделі, за вибір та застосування методів розробки ПЗ, за виконання дій і завдань, що підходять для проекту ПЗ.

Стандарт ISO12207 рівносильно орієнтований на організацію дій кожної з двох сторін: постачальник (розробник) і покупець (користувач); може бути в рівній мірі застосований, коли обидві сторони – з однієї організації.

Кожен процес ЖЦ розділений на набір дій, кожна дія – на набір завдань. Дуже важлива відмінність ISO: кожен процес, дія або завдання ініціюється і виконується іншим процесом в міру необхідності, причому немає заздалегідь визначених послідовностей (природно, при збереженні логіки зв'язків за вихідними відомостями завдань і т. п.).

У стандарті ISO12207 описані:


  1. 5 основних процесів ЖЦ ПЗ:

    • Процес придбання. Визначає дії підприємства-покупця, яке набуває АС, програмний продукт або сервіс ПЗ.
    • Процес постачання. Визначає дії підприємства-постачальника, яке постачає покупця системою, програмним продуктом або сервісом ПЗ.
    • Процес розробки. Визначає дії підприємства-розробника, яке розробляє принцип побудови програмного виробу та програмний продукт.
    • Процес функціонування. Визначає дії підприємства-оператора, яке забезпечує обслуговування системи (а не тільки ПО) у процесі її функціонування в інтересах користувачів. На відміну від дій, які визначаються розробником в інструкціях з експлуатації (ця діяльність розробника передбачена у всіх трьох розглянутих стандартах), визначаються дії оператора з консультування користувачів, отримання зворотного зв'язку та інші, які він планує сам і бере на себе відповідно обов'язки.
    • Процес супроводу. Визначає дії персоналу супроводу, який забезпечує супровід програмного продукту, що являє собою управління модифікаціями програмного продукту, підтримку його поточного стану та функціональної придатності, включає в себе інсталяцію та видалення програмного виробу на обчислювальній системі.

  2. 8 допоміжних процесів, які підтримують реалізацію іншого процесу, будучи невід'ємною частиною всього ЖЦ програмного виробу, і забезпечують належну якість проекту ПЗ:

    • вирішення проблем;
    • документування;
    • управління конфігурацією;
    • гарантування якості, який використовує результати інших процесів групи забезпечення якості, до якої входять:

      • Процес верифікації;
      • Процес атестації;
      • Процес спільної оцінки;
      • Процес аудиту.

  3. 4 організаційних процесу:

    • Процес управління;
    • Процес створення інфраструктури;
    • Процес удосконалення;
    • Процес навчання.

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

Під процесом удосконалення тут розуміється не удосконалення АС або ПЗ, а поліпшення самих процесів придбання, розробки, гарантування якості і т. п., реально здійснюваних в організації.

Яких-небудь етапів, фаз, стадій не передбачено, що дає описувану нижчий ступінь адаптивності.

"Динамічний" характер стандарту визначається способом визначення послідовності виконання процесів і завдань, при якому один процес при необхідності викликає інший або його частину.

Приклади:


Такий характер дозволяє реалізовувати будь-яку модель ЖЦ.

При виконанні аналізу вимог до ПЗ передбачено 11 класів характеристик якості, які використовуються пізніше при гарантуванні якості.

При цьому розробник повинен встановити і документувати як вимоги до програмного забезпечення:


  1. Функціональні і можливі специфікації, включаючи виконання, фізичні характеристики і умови середовища експлуатації, при яких одиниця програмного забезпечення повинна бути виконана;
  2. Зовнішні зв'язки (інтерфейси) з одиницею програмного забезпечення;
  3. Вимоги кваліфікації;
  4. Специфікації надійності, включаючи специфікації, пов'язані з методами функціонування і супроводу, впливу навколишнього середовища та ймовірністю травми персоналу;
  5. Специфікації захищеності,
  6. Людські фактори специфікацій з інженерної психології (ергономіці), включаючи пов'язані з ручним управлінням, взаємодією людини і устаткування, обмеженнями на персонал та областями, які потребують в концентрованому людської уваги, які є чутливими до помилок людини і навчання;
  7. Визначення даних і вимог бази даних;
  8. Установчі та приймальні вимоги поставляється програмного продукту в місцях функціонування та супроводу (експлуатації);
  9. Документація користувача;
  10. Робота користувача та вимоги виконання;
  11. Вимоги сервісу користувача.



  1. (Цікаво і важливо, що ці та аналогічні характеристики добре кореспондуються з характеристиками АС, передбачуваними в ГОСТ 34 по видам забезпечення системи.)


Стандарт містить гранично мало описів, спрямованих на проектування БД. Це можна вважати виправданим, тому що різні системи і різні прикладні комплекси ПЗ не тільки використовувати вельми специфічні типи БД, але і не використовувати

Отже, ISO12207 має набір процесів, дій і завдань, що охоплює найбільш широкий спектр можливих ситуацій при максимальній адаптованості.

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

З цієї причини центральним стандартом, положення якого беруться за початковий "стрижневий" набір положень у процесі побудови профілю стандартів ЖЦ для конкретного проекту, корисно розглядати саме ISO12207. Цей "стрижень" може задавати модель ЖЦ ПЗ і АС, принципову схему гарантування якості, модель управління проектом

Практики використовують ще один шлях: самі перекладають і використовують у своїх проектах сучасні стандарти на організацію ЖЦ ПС та їх документування. Але цей шлях страждає як мінімум тим недоліком, що різні переклади та адаптації стандартів, зроблені різними розробниками і замовниками, будуть відрізнятися масою деталей. Ці відмінності неминуче стосуються не тільки найменувань, але і їх змістовних визначень, вводяться і використовуються у стандартах. Таким чином, на цьому шляху неминуче постійне виникнення плутанини, а це прямо протилежно цілям не лише стандартів, але і будь-яких грамотних методичних документів.

В даний час у ВНДІ стандартів підготовлені пропозиції щодо вдосконалення і розвитку комплексу стандартів з документування ПС.

Довідкова інформація


Для придбання стандартів в області документування рекомендуємо звертатися в наступні організації:

Схожі статті:


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

Трекбек і пінги

трекбеків / пінгів ще немає.

Відгуки

Для кого написана стаття? В Україні діють національні стандарти.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*