Коли програміст отримує завдання на розробку програми, перед ним, перед керівником проекту та перед усією проектною групою постають питання:
- що має бути зроблено, окрім програми?
- яка документація має бути написана?
- що передавати користувачам, а що? службі супроводу?
- як управляти процесом розробки?
- що має входити до технічного завдання?
Окрім згаданих питань є й багато інших.
На ці питання колись відповідали державні стандарти на програмну документацію - комплекс стандартів 19-ї серії ГОСТ ЕСПД. Але вже тоді програмісти мали багато претензій до цих стандартів. Щось потрібно було невиправдано дублювати в документації багато разів, а багато не було передбачено, наприклад, відображення специфіки документування програм, що працюють з базою даних.
До сьогодні залишається актуальним питання про наявність системи стандартів, що регламентують документування програм, що розробляються.
2. Загальна характеристика стану
Основу вітчизняної нормативної бази у галузі документування програм складає комплекс стандартів Єдиної системи програмної документації (ЄСПД). Основна і більшість цього комплексу була розроблена в 70-80-ті роки. На даний момент цей комплекс є системою міждержавних стандартів країн СНД, що діють на території Російської Федерації на основі міждержавної угоди зі стандартизації.
Стандарти ЄСПД охоплюють частину документації, що створюється у процесі розробки програми, і пов'язані з документуванням функціональних характеристик. Не слід забувати, що стандарти ЕСПД (ГОСТ 19) мають рекомендаційний характер. Втім, це стосується й інших стандартів у галузі розробки програм таких, як: ГОСТ 34, Міжнародного стандарту ISO/IEC та ін. Відповідно до Закону РФ «Про стандартизацію» ці стандарти стають обов'язковими тільки на контрактній основі – тобто за посиланням на них у договорі на розробку програми.
Говорячи про стан ЄСПД загалом, можна констатувати, що більшість стандартів морально застаріла.
До основних недоліків ЕСПДможна віднести:
- орієнтацію на єдину, "каскадну" модель життєвого циклу програми;
- відсутність чітких рекомендацій щодо документування характеристик якості;
- відсутність зв'язків з іншими діючими вітчизняними системами стандартів, наприклад, ЕСКД;
- погано виражений підхід до документування програми як товарної продукції;
- відсутність рекомендацій щодо внутрішнього документування, як екранні меню, довідка по роботі з програмою ітд.;
- відсутність рекомендацій щодо складу, змісту та оформлення документів на програму, узгоджених з міжнародними та регіональними стандартами.
З цього виходить, що ЄСПД потребує повного перегляду на основі стандарту ІСО/МЕК 12207-95 (про цей стандарт далі буде розказано докладніше).
Варто зауважити, що крім ЄСПД в офіційній нормативній базі РФ в галузі документування програм і в суміжних областях є ряд перспективних стандартів, наприклад:
- міжнародний стандарт ISO/IEC 12207: 1995-08-01організацію життєвого циклу продуктів програмного обеспечения.
- Стандарти комплексу ГОСТ 34створення та розвиток автоматизованих систем.
2.1. Короткий опис наявних стандартів ЄСПД
Навіть не зважаючи на свої недоліки, багато стандартів ЄСПД можуть з користю застосовуватися для документування програм через те, що:
- стандарти ЄСПД вносять характерний лад у процес документування програм;
- передбачений стандартами ЕСПД склад програмних документів можна змінювати вносячи до комплекту документації додаткові види документів.
- стандарти ЄСПД дозволяють змінювати структуру та зміст виходячи з конкретних вимог замовника та користувача.
При цьому замовник та керівник проекту обирають доречне у проекті підмножину стандартів та документації, доповнюють їх потрібними розділами (виключають непотрібні) та прив'язують створення цих документів до тієї схеми, яка використовується у проекті.
Стандарти ЄСПД поділяють на групи, наведені у таблиці:
Позначення стандарту ЄСПД будують за класифікаційною ознакою:
Позначення стандарту ЄСПД має складатися з:
- числа 19 (наданих класу стандартів ЕСПД);
- однієї цифри (після точки), що означає код класифікаційної групи стандартів, зазначеної таблиці;
- двозначного числа (після тире), що вказує на рік реєстрації стандарту.
Перелік документів ЄСПД:
- ГОСТ 19.001-77 ЕСПД. Загальні положення.
- ГОСТ 19.101-77 ЕСПД. Види програм та програмних документів.
- ГОСТ 19.102-77 ЕСПД. Стадії розробки.
- ГОСТ 19.103-77 ЕСПД. Позначення програм та програмних документів.
- ГОСТ 19.104-78 ЕСПД. Основні написи.
- ГОСТ 19.105-78 ЕСПД. Загальні вимоги до програмних документів
- ГОСТ 19.106-78 ЕСПД. Вимоги до програмних документів, виконаних друкованим способом.
- ГОСТ 19.201-78 ЕСПД. Технічне завдання. Вимоги до змісту та оформлення.
- ГОСТ 19.202-78 ЕСПД. Специфікація. Вимоги до змісту та оформлення.
- ГОСТ 19.301-79 ЕСПД. Порядок та методика випробувань.
- ГОСТ 19.401-78 ЕСПД. Текст програми. Вимоги до змісту та оформлення.
- ГОСТ 19.402-78 ЕСПД. Опис програми.
- ГОСТ 19.404-79 ЕСПД. Пояснювальна записка. Вимоги до змісту та оформлення.
- ГОСТ 19.501-78 ЕСПД. Формуляр. Вимоги до змісту та оформлення.
- ГОСТ 19.502-78 ЕСПД. Опис застосування. Вимоги до змісту та оформлення.
- ГОСТ 19.503-79 ЕСПД. Керівництво системного програміста. Вимоги до змісту та оформлення.
- ГОСТ 19.504-79 ЕСПД. Керівництво програміста.
- ГОСТ 19.505-79 ЕСПД. Керівництво оператора.
- ГОСТ 19.506-79 ЕСПД. Опис мови.
- ГОСТ 19.508-79 ЕСПД. Посібник з технічного обслуговування. Вимоги до змісту та оформлення.
- ГОСТ 19.604-78 ЕСПД. Правила внесення змін до програмних документів, що виконуються друкованим способом.
- ГОСТ 19.701-90 ЕСПД. Схеми алгоритмів, програм, даних та систем. Умовні позначення та правила виконання.
- ГОСТ 19.781-90. Забезпечення систем опрацювання інформації програмне.
терміни та визначення
З усіх стандартів ЄСПД ми зупинимося на тих, що можуть частіше використовуватись у практиці розробки програми.
Першим стандартом, який можна використовувати для формування технічних завдань на програмування є ГОСТ (СТ РЕВ) 19.201-78 (1626-79). ЕСПД.
(Технічне завдання. Вимога до змісту та оформлення.).
Технічне завдання на розробку програми містить сукупність вимог до програми і може використовуватися як набір критеріїв, необхідних для перевірки та приймання розробленої програми. Тому досить повно складене технічне завдання є одним із первісних документів проекту.
У технічне завдання розробки програми необхідно включити такі разделы:
- Вступ;
- основи розробки;
- призначення розробки;
- вимоги до програми чи програмного виробу;
- вимоги до програмної документації;
- техніко-економічні показники;
- стадії та етапи розробки;
- порядок контролю та приймання;
- різні програми (за потребою).
Залежно від особливостей програми, можна уточнити зміст розділів, ввести нові розділи або об'єднати наявні.
Другим стандартом є ДЕРЖСТАНДАРТ (СТ РЕВ) 19.101-77 (1626-79). ЕСПД.
Види програм та програмних документів).
Цей стандарт встановлює види програм та програмних документів для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування.
Види програм:
Види програмних документів:
| Вид програмного документа | Зміст програмного документа |
| Специфікація | Склад програми та документації на неї |
| Перелік підприємств, на яких зберігають оригінальні програмні документи | |
| Текст програми | Запис програми з необхідними коментарями |
| Опис програми | Відомості про логічну структуру та функціонування програми |
| Вимоги, що підлягають перевірці під час випробування програми, а також порядок та методи їх контролю | |
| Технічне завдання | Призначення та сфера застосування програми, технічні, техніко-економічні та спеціальні вимоги до програми, необхідні стадії та терміни розробки, види випробувань |
| Пояснювальна записка | Схема алгоритму, загальний опис алгоритму та (або) функціонування програми, а також обґрунтування прийнятих технічних та техніко-економічних рішень |
| Експлуатаційні документи | Відомості для забезпечення функціонування та експлуатації програми |
Види експлуатаційних документів:
| Вид експлуатаційного документа | Зміст експлуатаційного документа |
| Перелік експлуатаційних документів на програму | |
| Формуляр | Основні характеристики програми, комплектність та відомості про експлуатацію програми |
| Опис застосування | Відомості про призначення програми, галузі застосування, застосовувані методи, клас вирішуваних завдань, обмеження для застосування, мінімальну конфігурацію технічних засобів |
| Відомості для перевірки, забезпечення функціонування та налаштування програми на умови конкретного застосування | |
| Керівництво програміста | Відомості щодо експлуатації програми |
| Керівництво оператора | Відомості для забезпечення процедури спілкування оператора з обчислювальною системою у процесі виконання програми |
| Опис мови | Опис синтаксису та семантики мови |
| Відомості для застосування тестових та діагностичних програм при обслуговуванні технічних засобів |
Залежно від способу виконання та характеру застосування програмні документи поділяються на оригінали, дублікати та копії (ГОСТ 2.102-68), призначені для розробки, супроводу та експлуатації програми.
Види програмних документів, що розробляються на різних стадіях, та їх коди:
| Код виду документа | Вид документа | Стадії розробки | |||
| Ескізний проект | Технічний проект | Робочий проект | |||
| компонент | комплекс | ||||
| - | Специфікація | - | - | ! | + |
| 05 | Відомість власників оригіналів | - | - | - | ? |
| 12 | Текст програми | - | - | + | ? |
| 13 | Опис програми | - | - | ? | ? |
| 20 | Відомість експлуатаційних документів | - | - | ? | ? |
| 30 | Формуляр | - | - | ? | ? |
| 31 | Опис застосування | - | - | ? | ? |
| 32 | Керівництво системного програміста | - | - | ? | ? |
| 33 | Керівництво програміста | - | - | ? | ? |
| 34 | Керівництво оператора | - | - | ? | ? |
| 35 | Опис мови | - | - | ? | ? |
| 46 | Посібник з технічного обслуговування | - | - | ? | ? |
| 51 | Програма та методика випробувань | - | - | ? | ? |
| 81 | Пояснювальна записка | ? | ? | - | - |
| 90-99 | Інші документи | ? | ? | ? | ? |
Допускається об'єднувати окремі види документів (за винятком відомості експлуатаційних документів та формуляра), при цьому необхідність об'єднання цих документів зазначається у технічному завданні. Об'єднаному документу надають найменування та позначення одного з документів, що об'єднуються. В об'єднаних документах мають бути наведені відомості, які необхідно включити до кожного об'єднаного документа.
…………………………………………………………
ГОСТ 19.102-77. ЕСПД. Стадії розробки.
Встановлює стадії розробки програм та програмної документації для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування.
Стадії розробки програми, етапи та зміст робіт
| Стадії розробки | Етапи робіт | Зміст робіт |
| Технічне завдання | Обґрунтування необхідності розробки програми | Постановка задачі. Збір вихідних матеріалів. Вибір та обґрунтування критеріїв ефективності та якості програми, що розробляється. Обґрунтування необхідності проведення науково-дослідних робіт. |
| Науково-дослідні роботи | Визначення структури вхідних та вихідних даних. Попередній вибір методів розв'язання задач. Обґрунтування доцільності застосування раніше розроблених програм. Визначення вимог до технічних засобів. Обґрунтування принципової можливості вирішення поставленого завдання. |
|
| Розробка та затвердження технічного завдання | Визначення вимог до програми. Розробка техніко-економічного обґрунтування розробки програми. Визначення стадій, етапів та термінів розробки програми та документації на неї. Вибір мов програмування. Визначення необхідності проведення науково-дослідницьких робіт на наступних стадіях. Погодження та затвердження технічного завдання. |
|
| Ескізний проект | Розробка ескізного проекту | Попередня розробка структури вхідних та вихідних даних. Уточнення методів розв'язання задачі. Розробка загального опису алгоритму розв'язання задачі. Розробка техніко-економічного обґрунтування. |
| Затвердження ескізного проекту | Розробка пояснювальної записки. Узгодження та затвердження ескізного проекту |
|
| Технічний проект | Розробка технічного проекту | Уточнення структури вхідних та вихідних даних. Розробка алгоритму розв'язання задачі. Визначення форми подання вхідних та вихідних даних. Визначення семантики та синтаксису мови. Розробка структури програми. Остаточне визначення конфігурації технічних засобів. |
| Твердження технічного проекту | Розробка плану заходів щодо розробки та впровадження програм. Розробка пояснювальної записки. Узгодження та затвердження технічного проекту. |
|
| Робочий проект | Розробка програми | Програмування та налагодження програми |
| Розробка програмної документації | Розробка програмних документів відповідно до вимог ГОСТ 19.101-77. | |
| Випробування програми | Розробка, узгодження та затвердження програми та методики випробувань. Проведення попередніх державних, міжвідомчих, приймально-здавальних та інших видів випробувань. Коригування програми та програмної документації за результатами випробувань. |
|
| Впровадження | Підготовка та передача програми | Підготовка та передача програми та програмної документації для супроводу та (або) виготовлення. Оформлення та затвердження акта про передачу програми на супровід та (або) виготовлення. Передача програми до фонду алгоритмів та програм. |
Примітки:
- Допускається виключати другу стадію розробки, а в технічно обґрунтованих випадках – другу та третю стадії. Необхідність проведення цих стадій зазначається у технічному завданні.
- Допускається об'єднувати, виключати етапи робіт та (або) їх зміст, а також запроваджувати інші етапи робіт за погодженням із замовником.
ГОСТ 19.103-77 ЕСПД. Позначення програм та програмних документів
Код країни-розробника та код організації-розробника надають у встановленому порядку.
- Реєстраційний номер надається у порядку зростання, починаючи з 00001 до 99999, для кожної організації-розробника.
- Номер видання програми чи номер редакції. номер документа цього виду, номер частини документа надаються у порядку зростання з 01 до 99. (Якщо документ складається з однієї частини, то дефіс та порядковий номер частини не вказують).
- Номер редакції специфікації та відомості експлуатаційних документів на програму мають збігатися з номером видання цієї програми.
ГОСТ 19.105-78 ЕСПД. Загальні вимоги до програмних документів
Цей стандарт встановлює загальні вимоги до оформлення програмних документів для обчислювальних машин, комплексів та систем, незалежно від їх призначення та сфери застосування та передбачених стандартами Єдиної системи програмної документації (ЄСПД) для будь-якого способу виконання документів на різних носіях даних.
Програмний документ може бути представлений на різних типах носіїв даних та складається з наступних умовних частин:
титульний;
інформаційної;
Основний.
Правила оформлення документа та його частин на кожному носії даних встановлюються стандартами ЄСПД на правила оформлення документів на відповідних носіях даних.
ГОСТ 19.106-78 ЕСПД. Вимоги до програмних документів, виконаних друкованим способом
Програмні документи оформлюють:
- на аркушах формату А4 (ГОСТ 2.301-68) під час виготовлення документа машинописним чи рукописним способом;
- допускається оформлення на аркушах формату А3;
- при машинному способі виконання документа допускаються відхилення розмірів аркушів, що відповідають форматам А4 та А3, що визначаються можливостями технічних засобів, що застосовуються; на аркушах форматів А4 та А3, що передбачаються вихідними характеристиками пристроїв виведення даних, при виготовленні документа машинним способом;
- на аркушах типографічних форматів під час виготовлення документа друкарським способом.
Розташування матеріалів програмного документа здійснюється у наступній послідовності:
Титульна частина:
- лист затвердження (не входить до загальної кількості листів документа);
- титульний лист (перший лист документа);
- анотація;
- лист змісту;
- текст документа (з малюнками, таблицями тощо)
- перелік термінів та їх визначень;
- перелік скорочень;
- додатки;
- предметний покажчик;
- перелік посилальних документів;
- лист реєстрації змін.
Перелік термінів та їх визначень, перелік скорочень, додатків, предметних покажчиків, перелік посилальних документів виконуються за потреби.
Наступний стандарт орієнтований документування результуючого продукту розробки:
ГОСТ 19.402-78 ЕСПД. Опис програми
Склад документа «Опис програми» у своїй змістовній частині може доповнюватись розділами та пунктами, почерпнутими із стандартів для інших описових документів та посібників: ГОСТ 19.404-79 ЄСПД. Пояснювальна записка, ГОСТ 19502-78 ЕСПД. Опис застосування, ГОСТ 19.503-79 ЕСПД. Посібник системного програміста, ГОСТ 19.504-79 ЕСПД. Посібник програміста, ГОСТ 19.505-79 ЕСПД. Керівництво оператора.
Існує також група стандартів, що визначає вимоги до фіксації всього набору програм та ПД, які оформляються для передачі ПС. Вони породжують лаконічні документи облікового характеру і можуть бути корисними для впорядкування всього господарства програм та ПД (адже часто потрібно просто навести елементарний порядок!). Існують і стандарти, що визначають правила ведення документів у «господарстві» ПС.
Потрібно також виділити
ГОСТ 19.301-79 ЕСПД. Програма та методика випробувань, що (в адаптованому вигляді) може використовуватися для розробки документів планування та проведення випробувальних робіт з оцінки готовності та якості ПС.
Зрештою, останній за роком прийняття стандарт.
ГОСТ 19.701-90 ЕСПД. Схеми алгоритмів, програм, даних та систем. Позначення умовні графічні та правила виконання.
Він встановлює правила виконання схем, що використовуються для відображення різних видів завдань обробки даних та засобів їх вирішення та повністю відповідає стандарту ISO 5807:1985.
Поряд з ЄСПД на міждержавному рівні діють ще два стандарти, які також відносяться до документування ПС і прийняті не так давно, як більшість ГОСТ ЄСПД.
ГОСТ 19781-90 Забезпечення систем опрацювання інформації програмне. Терміни та визначення. Розроблено натомість ГОСТ 19.781-83 та ГОСТ 19.004-80 та встановлює терміни та визначення понять у галузі програмного забезпечення (ПЗ) систем обробки даних (СОД), що застосовуються у всіх видах документації та літератури, що входять до сфери робіт зі стандартизації або використовують результати цих робіт .
ГОСТ 28388-89 Системи обробки інформації. Документи на магнітних носіях. Порядок виконання та звернення. Поширюється як на програмні, а й у конструкторські, технологічні та інші проектні документи, виконувані на магнітних носіях.
2.2. Стандарти комплексу ГОСТ 34
ГОСТ 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-х роках склалося становище, у якому у різних галузях і сферах діяльності використовувалася погано узгоджена чи неузгоджена НТД – «нормативно-технічна документація». Це ускладнювало інтеграцію систем, забезпечення їхнього ефективного спільного функціонування. Діяли різні комплекси та системи стандартів, що встановлюють вимоги до різних видів АС.
Практика застосування стандартів показала, що в них застосовується по суті (але не за суворими визначеннями) єдина система понять, є багато загальних об'єктів стандартизації, проте вимоги стандартів не узгоджені між собою, є відмінності за складом та змістом робіт, відмінності за позначенням, складом, змісту та оформлення документів та ін.
Звісно, ця ситуація частково відбивала і природне різноманіття умов розробки АС, цілей розробників, застосовуваних підходів і методик.
У цих умовах можна було провести аналіз такого різноманіття і далі вчинити, наприклад, одним із двох багато в чому протилежних способів:
- Виробити одну узагальнену понятійну та термінологічну систему, загальну схему розробки, загальний набір документів із їх змістом та визначити їх як обов'язкові для всіх АС;
- Визначити також одну загальну понятійну та термінологічну систему, узагальнений комплекс системних вимог, набір критеріїв якості, але надати максимальну свободу у виборі схеми розробки, складу документів та інших аспектів, наклавши лише мінімум обов'язкових вимог, які б дозволяли:
- визначати рівень якості результату;
- вибирати ті конкретні методики (з їх моделями ЖЦ, набором документів та ін.), які найбільше підходять до умов розробки та відповідають використовуваним Інформаційним Технологіям;
- працювати, таким чином, із мінімальними обмеженнями ефективних дій проектувальника АС.
Розробники комплексу стандартів 34 вибрали спосіб, близький до першого із зазначених вище, тобто пішли шляхом, ближчим до схем конкретних методик, ніж до стандартів типу ISO12207. Тим не менш, завдяки спільності понятійної бази стандарти залишаються застосовними у широкому діапазоні випадків.
Ступінь адаптивності формально визначається можливостями:
- опускати стадію ескізного проектування та об'єднувати стадії «Технічний проект» та «Робоча документація»;
- опускати етапи, об'єднувати та опускати більшість документів та їх розділів;
- вводити додаткові документи, розділи документів та роботи;
- динамічно створюючи т. зв. ЧТЗ – приватні технічні завдання – досить гнучко формувати ЖЦ АС; як правило, цей прийом використовується на рівні великих одиниць (підсистем, комплексів), заради яких вважається виправданим створювати ЧТЗ, проте немає жодних істотних підстав сильно обмежувати цей спосіб керування ЖЦ.
Стадії та етапи, що виконуються організаціями – учасниками робіт зі створення АС, встановлюються у договорах та технічному завданні, що близьке до підходу ISO.
Введення єдиної, досить якісно певної термінології, наявність досить розумної класифікації робіт, документів, видів забезпечення та ін безумовно корисно. ГОСТ 34 сприяє більш повній та якісній стиковці дійсно різних систем, що особливо важливо в умовах, коли розробляється все більше складних комплексних АС, наприклад типу CAD-CAM, які включають до свого складу АСУТП, АСУП, САПР-конструктора, САПР-технолога, АСНІ та ін. системи.
Визначено кілька важливих положень, що відображають особливості АС як об'єкта стандартизації, наприклад: «загалом АС складається з програмно-технічних (ПТК), програмно-методичних (ПМК) комплексів та окремих компонентів організаційного, технічного, програмного та інформаційного забезпечення».
Поділ понять ПТК та АС закріплював принцип, за яким АС є не «ІС з БД», але:
- «Організаційно-технічна система, що забезпечує вироблення рішень на основі автоматизації інформаційних процесів у різних сферах діяльності (управління, проектування, виробництво і т. д.) або їх поєднаннях» (РД 50-680-88), що особливо актуально в аспектах бізнес -реінжинірингу;
- «Система, що складається з персоналу та комплексу засобів автоматизації його діяльності, що реалізує інформаційну технологію виконання встановлених функцій» (ГОСТ 34.003-90).
Ці визначення вказують на те, що АС – це насамперед персонал, який приймає рішення та виконує інші керуючі дії, підтриманий організаційно-технічними засобами.
Ступінь обов'язковості:
колишня повна обов'язковість відсутня, матеріали ГОСТ34, по суті, стали методичною підтримкою, причому частіше для замовників, які мають у стандарті набір вимог до змісту ТЗ та проведення випробувань АС. При цьому користь ГОСТ34 може багаторазово зрости у разі більш гнучкого використання при формуванні профілю ЖЦ АС.
Ключовим документом взаємодії сторін є ТЗ – технічне завдання створення АС. ТЗ є основним вихідним документом для створення АС та його приймання, ТЗ визначає найважливіші точки взаємодії замовника та розробника. При цьому ТЗ розробляє організація-розробник (ГОСТ 34.602-89), але формально видає ТЗ розробнику замовник (РД 50-680-88).
2.3. Державні стандарти РФ (ГОСТ Р)
У РФ діє ряд стандартів щодо документування ПС, розроблених з урахуванням прямого застосування міжнародних стандартів ИСО. Це? найсвіжіші за часом прийняття стандарти. Деякі їх безпосередньо адресовані керівникам проекту чи директорам інформаційних служб. Водночас вони невиправдано мало відомі серед професіоналів. Ось їхнє уявлення.
ГОСТ Р ІСО/МЕК 9294-93Інформаційна технологія. Посібник з управління документуванням програмного забезпечення. Стандарт повністю відповідає міжнародному стандарту ІСО/МЕК ТО 9294:1990 та встановлює рекомендації щодо ефективного управління документуванням ПС для керівників, які відповідають за їх створення. Метою стандарту є надання допомоги у визначенні стратегії документування ПС; виборі стандартів із документування; вибір процедур документування; визначення необхідних ресурсів; складання планів документування.
ГОСТ Р ІСО/МЕК 9126-93Інформаційна технологія. Оцінка програмної продукції. Характеристики якості та посібника з їх застосування. Стандарт повністю відповідає міжнародному стандарту ІСО/МЕК 9126:1991. У його контексті під характеристикою якості розуміється «набір властивостей (атрибутів) програмної продукції, якими її якість описується і оцінюється». Стандарт визначає шість комплексних характеристик, які з мінімальним дублюванням описують якість ПЗ (ПЗ, програмної продукції): функціональні можливості; надійність; практичність; ефективність; супроводжуваність; мобільність. Ці характеристики утворюють основу для подальшого уточнення та опису якості ПС.
ГОСТ Р ІСО 9127-94Системи опрацювання інформації. Документація користувача та інформація на упаковці для споживчих програмних пакетів. Стандарт повністю відповідає міжнародному стандарту ISO 9127:1989. У контексті цього стандарту під споживчим програмним пакетом (ПП) розуміється «програмна продукція, що спроектована і продається для виконання певних функцій; програма та відповідна їй документація, упаковані для продажу як єдине ціле». Під документацією користувача розуміється документація, яка забезпечує кінцевого користувача інформацією щодо встановлення та експлуатації ПП. Під інформацією на упаковці розуміють інформацію, яку відтворюють на зовнішній упаковці ПП. Її метою є надання потенційним покупцям первинних відомостей про ПП.
ГОСТ Р ІСО/МЕК 8631-94Інформаційна технологія. Програмні конструктиви та умовні позначення для їх подання. Описує представлення процедурних алгоритмів.
2.4. Міжнародний стандарт ISO/IEC 12207: 1995-08-01
Першу редакцію ISO12207 підготовлено у 1995 році об'єднаним технічним комітетом ISO/IEC JTC1 «Інформаційні технології, підкомітет SC7, проектування програмного забезпечення».
За визначенням, ISO12207 – базовий стандарт процесів ЖЦ ПЗ, орієнтований різні (будь-які!) види і типи проектів АС, куди ПЗ входить як частина. Стандарт визначає стратегію та загальний порядок у створенні та експлуатації ПЗ, він охоплює ЖЦ ПЗ від концептуалізації ідей до завершення ЖЦ.
Дуже важливі ЗАУВАЖЕННЯ СТАНДАРТУ:
- Процеси, що використовуються під час ЖЦ ПЗ, повинні бути сумісні з процесами, що використовуються під час ЖЦ АС. (Звідси зрозуміла доцільність спільного використання стандартів на АС та ПЗ.)
- Додавання унікальних чи специфічних процесів, дій та завдань має бути обумовлено у контракті між сторонами. Договір розуміється у сенсі: від юридично оформленого договору до неформального угоди, угода то, можливо визначено і єдиною стороною як завдання, поставлене себе.
- Стандарт принципово не містить конкретних методів дій, тим більше – заготівлі рішень чи документації. Він описує архітектуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати послуги та завдання, включені до процесів, не призначений для розпорядження імені, формату або точного вмісту одержуваної документації. Рішення такого типу приймаються таким, що використовує стандарт.
ВИЗНАЧЕННЯ СТАНДАРТУ:
- Система – це об'єднання одного чи більше процесів, апаратних засобів, програмного забезпечення, обладнання та людей для забезпечення можливості задоволення певних потреб чи цілей.
- Модель життєвого циклу– структура, що містить процеси, дії та завдання, що здійснюються в ході розробки, функціонування та супроводу програмного продукту протягом усього життя системи, від визначення вимог до завершення її використання.
Безліч процесів і завдань сконструйовано так, що можлива їхня адаптація відповідно до проектів ПЗ. Процес адаптації є процесом виключення процесів, видів діяльності та завдань, не застосовних у конкретному проекті. Ступінь адаптивності: максимальна - Вимога кваліфікації– набір критеріїв або умов (кваліфікаційні вимоги), які мають бути задоволені для того, щоб кваліфікувати програмний продукт як підпорядкований (задовольняючий умовам) його специфікації та готовий для використання в цільовому навколишньому середовищі.
Стандарт не наказує конкретну модель ЖЦ або метод розробки ПЗ, але визначає, що сторони-учасники використання стандарту відповідальні за вибір моделі ЖЦ для проекту ПЗ, за адаптацію процесів та завдань стандарту до цієї моделі, за вибір та застосування методів розробки ПЗ, за виконання дій та завдань, що підходять для проекту ПЗ.
Стандарт ISO12207 рівносильно орієнтований на організацію дій кожної з двох сторін: постачальник (розробник) та покупець (користувач); може бути однаково застосований, коли обидві сторони – з однієї організації.
Кожен процес ЖЦ поділено на набір дій, кожна дія – на набір завдань. Дуже важлива відмінність ISO: кожен процес, дія чи завдання ініціюється і виконується іншим процесом у міру необхідності, причому немає заздалегідь визначених послідовностей (звісно, при збереженні логіки зв'язків за вихідними даними задач тощо).
У стандарті ISO12207 описано:
- 5 основних процесів ЖЦ ПЗ:
- Процес придбання. Визначає дії підприємства-покупця, яке набуває АС, програмний продукт чи сервіс ПЗ.
- Процес постачання. Визначає дії підприємства-постачальника, що забезпечує покупця системою, програмним продуктом чи сервісом ПЗ.
- Процес розробки. Визначає дії підприємства-розробника, яке розробляє принцип побудови програмного виробу та програмний продукт.
- Процес функціонування. Визначає дії підприємства-оператора, що забезпечує обслуговування системи (а не лише ПЗ) у процесі її функціонування на користь користувачів. На відміну від дій, які визначаються розробником в інструкціях з експлуатації (ця діяльність розробника передбачена у всіх трьох стандартах, що розглядаються), визначаються дії оператора з консультування користувачів, отримання зворотного зв'язку та ін., які він планує сам і бере на себе відповідно обов'язки.
- Процес супроводу. Визначає дії персоналу супроводу, який забезпечує супровід програмного продукту, що являє собою управління модифікаціями програмного продукту, підтримку його поточного стану та функціональної придатності, включає інсталяцію та видалення програмного виробу на обчислювальній системі.
- 8 допоміжних процесів, які підтримують реалізацію іншого процесу, будучи невід'ємною частиною всього ЖЦ програмного виробу, та забезпечують належну якість проекту:
- рішення проблем;
- документування;
- управління конфігурацією;
- гарантування якості, що використовує результати інших процесів групи забезпечення якості, до якої входять:
- процес верифікації;
- Процес атестації;
- процес спільної оцінки;
- Процес аудиту.
- 4 організаційні процеси:
- процес управління;
- процес створення інфраструктури;
- Процес удосконалення;
- Процес навчання.
До них примикає особливий процес адаптації, який визначає основні дії, необхідні адаптації стандарту до умов конкретного проекту.
Під процесом удосконалення тут розуміється не удосконалення АС чи ПЗ, а поліпшення самих процесів придбання, розробки, гарантування якості тощо, реально здійснюваних у створенні.
Яких-небудь етапів, фаз, стадій не передбачено, що дає ступінь адаптивності, що описується нижче.
«Динамічний» характер стандарту визначається способом визначення послідовності виконання процесів та завдань, при якому один процес за потреби викликає інший або його частину.
- виконання процесу придбання в частині аналізу та фіксації вимог до системи або програмного забезпечення може викликати виконання відповідних завдань процесу розробки;
- у Процесі поставки постачальник повинен керувати субпідрядниками відповідно до Процесу придбання та виконувати верифікацію та атестацію за відповідними процесами;
- супровід може вимагати розвитку системи та ПЗ, що виконується за процесом розробки.
Такий характер дозволяє реалізовувати будь-яку модель ЖЦ.
При виконанні аналізу вимог до ПЗ передбачено 11 класів характеристик якості, які використовуються пізніше за гарантування якості.
При цьому розробник повинен встановити та документувати як вимоги до програмного забезпечення:
- Функціональні та можливі специфікації, включаючи виконання, фізичні характеристики та умови середовища експлуатації, за яких одиниця програмного забезпечення має бути виконана;
- зовнішні зв'язки (інтерфейси) з одиницею програмного забезпечення;
- Вимоги кваліфікації;
- Специфікації надійності, включаючи специфікації, пов'язані з методами функціонування та супроводу, впливу навколишнього середовища та ймовірністю травми персоналу;
- Специфікації захищеності,
- Людські фактори специфікацій з інженерної психології (ергономіки), включаючи пов'язані з ручним управлінням, взаємодією людини та обладнання, обмеженнями на персонал та областями, що потребують концентрованої людської уваги, які є чутливими до помилок людини та навчання;
- Визначення даних та вимог бази даних;
- Настановні та приймальні вимоги програмного продукту, що постачається в місцях функціонування та супроводу (експлуатації);
- документація користувача;
- Робота користувача та вимоги виконання;
- Вимоги до сервісу користувача.
- (Цікаво та важливо, що ці та аналогічні характеристики добре кореспондуються з характеристиками АС, що передбачаються у ГОСТ 34 за видами забезпечення системи.)
Стандарт містить дуже мало описів, спрямованих на проектування БД. Це можна вважати виправданим, оскільки різні системи та різні прикладні комплекси ПЗ можуть не тільки використовувати вельми специфічні типи БД, але й не використовувати
Отже, ISO12207 має набір процесів, дій та завдань, що охоплює найбільш широкий спектр можливих ситуацій за максимальної адаптованості.
Він показує приклад того, як має будуватися добре організований стандарт, що містить мінімум обмежень (принцип «немає однакових проектів»). При цьому детальні визначення процесів, форм документів тощо доцільно виносити до різних функціональних стандартів, відомчих нормативних документів або фірмових методик, які можуть бути використані або не використані в конкретному проекті.
Тому центральним стандартом, положення якого беруться за початковий «стрижневий» набір положень у процесі побудови профілю стандартів ЖЦ для конкретного проекту, корисно розглядати саме ISO12207. Цей «стрижень» може задавати модель ЖЦ ПЗ та АС, принципову схему гарантування якості, модель управління проектом
Практики використовують ще один шлях: самі перекладають та використовують у своїх проектах сучасні стандарти на організацію життєвого циклу програм та їх документування. Але цей шлях страждає як мінімум на той недолік, що різні переклади та адаптації стандартів, зроблені різними розробниками та замовниками, відрізнятимуться масою деталей. Ці відмінності неминуче стосуються як найменувань, а й їх змістовних визначень, введених і які у стандартах. Отже, цьому шляху неминуче постійне виникнення плутанини, але це протилежно цілям як стандартів, а й будь-яких грамотних методичних документів.
Наразі у ВНДІ стандартів підготовлено пропозиції щодо вдосконалення та розвитку комплексу стандартів із документування ПС.
Єдина система документації програмної продукції - ЕСПД - відноситься до ГОСТ класу 19 і поділяється на 10 груп:
1. Основні стандарти.
2. Правила виконання документації опрацювання.
3. Правила виконання документації виготовлення.
4. Правила виконання документації супроводу.
5. Правила виконання експлуатаційної документації.
6. Правила звернення програмної документації.
Стандарт із номером 0 містить загальні положення, стандарти 7 та 8 є зарезервованими і до номера 9 відносяться інші стандарти, що не увійшли до перших 6.
Це короткі описи ГОСТів класу 19, для детальнішого ознайомлення з ними необхідно звернутися до довідників.
- ГОСТ 19.001-77 – єдина система програмної документації.
- ГОСТ 19.101-77 – види програм та програмних документів.
- ГОСТ 19.102-77 - стадії розробки програм та програмної документації.
- ГОСТ 19.105-78 – вимоги до оформлення програмних документів, комплексів та систем незалежно від їх призначення та сфери застосування. ГОСТ 19.105-78 містить повний перелік документації, що має супроводжувати закінчений програмний продукт.
Перелік документації, що декларується ГОСТ 19.105-78:
1. Документи, що містять відомості, необхідні розробки програмного продукту, його виготовлення.
1.1. Специфікація - склад програми та документації на неї.
1.2. Відомість власників оригіналів – перелік підприємств, у яких зберігаються оригінали програмної документації.
1.3. Текст програми – записування тексту програми з необхідними коментарями.
1.4. Опис програми – відомості про логічну та функціональну структуру програми.
1.5. Програма та методика випробувань – вимоги, що підлягають перевірці під час випробування програми, порядок та методи їх контролю.
1.6. Технічне завдання – призначення та сфера застосування програми, технічні та спеціальні вимоги, необхідні стадії та терміни розробки, види випробувань.
2. Документи, які використовуються під час експлуатації програмного продукту.
Відомість експлуатаційних документів – список експлуатаційних документів на програму.
Формуляр – основні характеристики програми, комплектність, загальні відомості щодо експлуатації програми.
Опис застосування – відомості про призначення програми, сфери застосування, клас вирішуваних завдань, обмеження на застосування, необхідна конфігурація технічних засобів.
Посібник системного програміста – відомості для перевірки та забезпечення функціональності, налаштування програми.
Посібник програміста – відомості щодо експлуатації налаштованої програми.
Керівництво оператора – відомості задля забезпечення процедури спілкування оператора з ЕОМ у процесі виконання програми.
Опис мови – опис синтаксису та семантики мови, що використовується у програмі.
Посібник із технічного обслуговування – відомості для застосування тестових програм під час обслуговування технічних засобів.
Інші ГОСТи класу 19:
- ГОСТ 19.201-78 – порядок побудови та оформлення технічного завдання на розробку програми чи програмного виробу.
- ГОСТ 19.202-78 - форма та порядок складання специфікації на програмні продукти, що визначаються у ГОСТ 19.101-77.
- ГОСТ 19.301-79 - програма та методика випробувань програмних продуктів.
- ГОСТ 19.401-78 - порядок побудови та оформлення тексту програми при розробці програмних продуктів.
- ГОСТ 19.402-78 - Опис програми.
- ГОСТ 19.403-79 - форма заповнення та зміст відомості власників оригіналів, що визначається в ГОСТ 19.105-78.
- ГОСТ 19.404-79 - форма заповнення та зміст пояснювальної записки, що визначається в ГОСТ 19.105-78.
- ГОСТ 19.501-78 - форма заповнення та зміст формуляру на програмний продукт, що визначається в ГОСТ 19.105-78.
- ГОСТ 19.502-78 - форма заповнення та зміст опису застосування, що визначається в ГОСТ 19.105-78.
- ГОСТ 19.503-79 - форма заповнення та зміст керівництва системного програміста, що визначається у ГОСТ 19.105-78.
- ГОСТ 19.504-79 - форма заповнення та зміст керівництва програміста, що визначається у ГОСТ 19.105-78.
- ГОСТ 19.505-79 - форма заповнення та зміст керівництва оператора, що визначається у ГОСТ 19.105-78.
- ГОСТ 19.506-79 - форма заповнення та зміст опису мови, що визначається в ГОСТ 19.105-78.
- ГОСТ 19.507-79 - форма заповнення та зміст відомості експлуатаційних документів, що визначається у ГОСТ 19.105-78.
- ГОСТ 19.508-79 - форма заповнення та зміст посібника з технічного обслуговування, що визначається у ГОСТ 19.105-78.
- ГОСТ 19.701-90 – схеми алгоритмів, програм, даних та систем.
Г О С У Д А Р С Т В Е Н І Й С Т А Н Д А Р Т С Ю Ю З А С С Р
|
Єдина система програмної документації |
ГОСТ 19.101-77(СТ РЕВ 1626-79) |
ВИДИ ПРОГРАМ І ПРОГРАМНИХ ДОКУМЕНТІВ |
|
United system for program documentation. Types of programs and program documents |
Дата введення з 01.01.80
Цей стандарт встановлює види програм та програмних документів для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування.
Стандарт повністю відповідає СТ РЕВ 1626-79.
1. ВИДИ ПРОГРАМ
1.1. Програму (за ГОСТ 19781-90) допускається ідентифікувати та застосовувати самостійно та (або) у складі інших програм.
1.2. Програми поділяють на види, наведені у табл. 1
Таблиця 1
1.3. Документація, розроблена на програму, може використовуватися для реалізації та передачі програми на носіях даних, а також виготовлення програмного виробу.
1.2,1.3.
2. ВИДИ ПРОГРАМНИХ ДОКУМЕНТІВ
2.1. До програмних відносять документи, що містять відомості, необхідні для розробки, виготовлення, супроводу та експлуатації програм.
2.2. Види програмних документів та їх зміст наведено у табл. 2.
Таблиця 2
| Вид програмного документа | Зміст програмного документа |
|---|---|
| Специфікація | Склад програми та документації на неї |
| Перелік підприємств, на яких зберігають оригінальні програмні документи | |
| Текст програми | Запис програми з необхідними коментарями |
| Опис програми | Відомості про логічну структуру та функціонування програми |
| Вимоги, що підлягають перевірці під час випробування програми, а також порядок та методи їх контролю | |
| Технічне завдання | Призначення та сфера застосування програми, технічні, техніко-економічні та спеціальні вимоги до програми, необхідні стадії та терміни розробки, види випробувань |
| Пояснювальна записка | Схема алгоритму, загальний опис алгоритму та (або) функціонування програми, а також обґрунтування прийнятих технічних та техніко-економічних рішень |
| Експлуатаційні документи | Відомості для забезпечення функціонування та експлуатації програми |
(Змінена редакція, Зм. № 1).
2.3. Види експлуатаційних документів та їх зміст наведено табл.3.
Таблиця 3
| Вид експлуатаційного документа | Зміст експлуатаційного документа |
|---|---|
| Перелік експлуатаційних документів на програму | |
| Формуляр | Основні характеристики програми, комплектність та відомості про експлуатацію програми |
| Опис застосування | Відомості про призначення програми, галузі застосування, застосовувані методи, клас вирішуваних завдань, обмеження для застосування, мінімальну конфігурацію технічних засобів |
| Відомості для перевірки, забезпечення функціонування та налаштування програми на умови конкретного застосування | |
| Керівництво програміста | Відомості щодо експлуатації програми |
| Керівництво оператора | Відомості для забезпечення процедури спілкування оператора з обчислювальною системою у процесі виконання програми |
| Опис мови | Опис синтаксису та семантики мови |
| Відомості для застосування тестових та діагностичних програм при обслуговуванні технічних засобів |
(Змінена редакція, Зм. № 1).
2.4. Залежно від способу виконання та характеру застосування програмні документи поділяються на оригінал, дублікат та копію (ГОСТ 2.102-68), призначені для розробки, супроводу та експлуатації програми.
2.5. Види програмних документів, що розробляються на різних стадіях, та їх коди наведені в таблиці click . 4.
Таблиця 4
| Код виду документа | Вид документа | Стадії розробки | |||
|---|---|---|---|---|---|
| Ескізний проект | Технічний проект | Робочий проект | |||
| компонент | комплекс | ||||
| - | Специфікація | - | - | ||
| 05 | Відомість власників оригіналів | - | - | - | |
| 12 | Текст програми | - | - | ||
| 13 | Опис програми | - | - | ||
| 20 | Відомість експлуатаційних документів | - | - | ||
| 30 | Формуляр | - | - | ||
| 31 | Опис застосування | - | - | ||
| 32 | Керівництво системного програміста | - | - | ||
| 33 | Керівництво програміста | - | - | ||
| 34 | Керівництво оператора | - | - | ||
| 35 | Опис мови | - | - | ||
| 46 | Посібник з технічного обслуговування | - | - | ||
| 51 | Програма та методика випробувань | - | - | ||
| 81 | Пояснювальна записка | - | - | ||
| 90-99 | Інші документи | ||||
Умовні позначення:
- Документ обов'язковий;
- Документ обов'язковий для компонентів, що мають самостійне застосування;
- необхідність складання документа визначається на етапі розробки та затвердження технічного завдання;
- - Документ не складають.
2.2-2.5. (Змінена редакція, Зм. № 1).
2.6. Допускається поєднувати окремі види експлуатаційних документів (за винятком відомості експлуатаційних документів та формуляра). Необхідність об'єднання цих документів зазначається у технічному завданні. Об'єднаному документу надають найменування та позначення одного з документів, що об'єднуються.
В об'єднаних документах мають бути наведені відомості, які необхідно включати до кожного документа, що об'єднується.
2.7. На етапі розробки та затвердження технічного завдання визначають необхідність складання технічних умов, що містять вимоги до виготовлення, контролю та приймання програми.
Технічні умови розробляють у стадії «Робочий проект».
2.8. Необхідність складання технічного завдання на компоненти, не призначені для самостійного застосування, та комплекси, що входять до інших комплексів, визначається за погодженням із замовником.
(Запроваджено додатково, Зм. № 1).
Перевидання (Листопад 1987 р.) із Зміною № 1, затвердженим у червні 1981 р. (ІУС 9-81)
Нагору
ГОСТ 19.105-78* (Загальні вимоги до програмних документів)
З цього ГОСТу ми отримуємозагальні вимоги щодо оформлення програмних документів.Нижче наведено найважливіші розділи.
- Цей стандарт встановлює загальні вимоги до оформлення програмних документів для обчислювальних машин, комплексів та систем, незалежно від їх призначення та сфери застосування та передбачених стандартами Єдиної системи програмної документації (ЄСПД) для будь-якого способу виконання документів на різних носіях даних.
- Програмний документ складається з наступних умовних частин:
- титульний;
- інформаційної;
- Основний;
- реєстрації змін.
- Титульна частина складається з листа затвердження та титульного листа. Правила оформлення листа затвердження та титульного листа встановлюються згідно з ГОСТ 19.104-78.
- Інформаційна частинаповинна складатися з анотації та змісту.
- Необхідність включення інформаційної частини до різних видів програмних документів встановлена відповідними стандартами ЄСПД на ці документи.
- В інструкції наводять відомості про призначення документа та короткий виклад його основної частини.
- Зміст включає перелік записів про структурні елементи основної частини документа, до кожного з яких входять:
- позначення структурного елемента (номер розділу, підрозділу тощо);
- найменування структурного елемента;
- адреса структурного елемента на носії даних (наприклад, номер сторінки, номер файлу тощо).
- Склад та структура основної частини програмного документа встановлюються стандартами ЄСПД на відповідні документи.
- Частина реєстрації змін(Має бути присутнім у кожному програмному документі)
- Про кожну зміну програмного документа у цій частині робиться запис відповідно до вимог ГОСТ 19.603-78.
==================================
ГОСТ 19.106-78* (Загальні вимоги до програмних документів, виконаних друкованим
способом)
З цього ГОСТу ми отримуємозагальні правила для друкованого способу виконанняпрограмних документів. Нижче наведено найважливіші розділи.
- Цей стандарт встановлює правила виконання програмних документів для обчислювальних машин, комплексів та систем незалежно від їх призначення та сфери застосування та передбачених стандартами Єдиної системи програмної документації (ЕСПД) для друкованого способу виконання.
- Стандарт не розповсюджується на програмний документ «Текст програми».
- Склад та структура програмного документа встановлюється за ГОСТ 19.105-78.
- Програмний документ виконуютьна одній стороні листа, через два інтервали; допускається через один або півтора інтервали.
- Програмні документи оформлюють:
- на аркушах формату А4 (ГОСТ 2.301-68) - під час виготовлення документа машинописним чи рукописним способом (форма 1). Дозволяється оформлення на аркушах формату А3.
- Матеріали програмного документа розташовують у наступній послідовності:
- титульна частина:
- лист затвердження (не входить до загальної кількості листів документа);
- титульний лист (перший лист документа);
- інформаційна частина:
- анотація;
- лист змісту;
- основна частина:
- текст документа (з малюнками, таблицями тощо);
- додатки;
- перелік термінів, перелік скорочень, перелік малюнків, перелік таблиць, предметний покажчик, перелік посилальних документів;
- частина реєстрації змін:
- лист реєстрації змін.
- Анотацію розміщують на окремій (пронумерованій) сторінці із заголовком «АННОТАЦІЯ» та не нумерують як розділ.
- В інструкції вказують видання програми, коротко викладають призначення та зміст документа. Якщо документ складається з кількох частин, в інструкції вказують загальну кількість елементів.
- Зміст документа розміщують на окремій (пронумерованій) сторінці (сторінках) після анотації, забезпечують заголовком «ЗМІСТ», не нумерують як розділ та включають до загальної кількості сторінок документа.
- Заголовки розділів пишуть великими літерами і розміщують симетрично щодо правої та лівої меж тексту.
- Заголовки підрозділів записують з абзацу малими літерами (крім першої великої).
- Перенесення слів у заголовках не допускаються. Точку наприкінці заголовка не ставлять.
- Відстань між заголовком та наступним текстом, а також між заголовками розділу та підрозділу має бути рівна:
- при виконанні документа машинописним способом – двом інтервалам.
- Для розділів та підрозділів, текст яких записують на одній сторінці з текстом попереднього розділу, відстань між останнім рядком тексту та наступним заголовком має бути рівна:
- при виконанні документа машинописним способом – трьом машинописним інтервалам.
- Розділи, підрозділи, пункти та підпункти слід нумерувати арабськими цифрами з точкою.
- У межах розділу має бути наскрізна нумерація за всіма підрозділами, пунктами та підпунктами, що входять до цього розділу.
- Нумерація підрозділів включає номер розділу та порядковий номер підрозділу, що входить до цього розділу, розділені точкою (2.1; 3.1 тощо).
- За наявності розділів та підрозділів до номера підрозділу після точки додають порядковий номер пункту та підпункту (3.1.1, 3.1.1.1 тощо).
Приклад структури тексту програмного документа та нумерації його розділів, підрозділів, пунктів та підпунктів. 
- Текст документа має бути коротким, чітким, що унеможливлює неправильне тлумачення.
- Терміни та визначення повинні бути єдиними та відповідати встановленим стандартам, а за їх відсутності - загальноприйнятим у науково-технічній літературі, та наводитися у переліку термінів.
- Необхідні пояснення тексту документа можуть оформлятися виносками.
- Виноска позначається цифрою зі дужкою, винесеними на рівень лінії верхнього обрізу шрифту, наприклад: «друкар 2) ...» або «папір 5) ».
- Якщо виноска відноситься до окремого слова, знак виноски міститься безпосередньо у цього слова, якщо ж до пропозиції загалом, то в кінці речення. Текст виноски розташовують наприкінці сторінки та відокремлюють від основного тексту лінією довжиною 3 см, проведеною у лівій частині сторінки.
- Ілюстрації, якщо їх у цьому документі більше однієї, нумерують арабськими цифрами в межах документа.
- Формули в документі, якщо їх більше однієї, нумеруються арабськими цифрами, номер ставлять праворуч сторінки, в дужках лише на рівні формули.
- Значення символів та числових коефіцієнтів, що входять до формули, мають бути наведені безпосередньо під формулою. Значення кожного символу друкують з нового рядка в тій послідовності, як вони наведені у формулі. Перший рядок розшифрування повинен починатися зі слова «де», без двокрапки після нього.
- У програмних документах допускаються посилання на стандарти (крім стандартів підприємств), технічні умови та інші документи (наприклад, документи органів державного нагляду, правила та норми Держбуду СРСР). При посиланнях на стандарти та технічні умови вказують їхнє позначення.
- Посилатися слід на документ в цілому або на його розділи (із зазначенням позначення та найменування документа, номера та найменування розділу або додатка). При повторних посиланнях на розділ або програму вказують лише номер.
- У примітках до тексту та таблиць вказують лише довідкові та пояснювальні дані.
- Одна примітка не нумерується. Після слова "Примітка" ставлять крапку.
- Декілька приміток слід нумерувати по порядку арабськими цифрами з точкою. Після слова «Примітка» ставлять двокрапку.
- Скорочення слів у тексті та написах під ілюстраціями не допускаються.
- Ілюстрований матеріал, таблиці чи текст допоміжного характеру допускається оформляти як додатків.
- Кожна програма повинна починатися з нової сторінки із зазначенням у правому верхньому кутку слова «ДОДАТОК» і мати тематичний заголовок, який записують симетрично тексту великими літерами.(У результаті, для створення проекту, нам знадобиться лише аркуш реєстрації змін).
- Цей стандарт встановлює правила внесення змін до програмних документів, передбачених стандартами Єдиної системи програмної документації (ЄСПД) та виконаних друкованим способом.
Нагору
==================================
КУЛЬТУРА РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Будь-яке програмне забезпеченнявід простого Web-сайтудо потужних систем управління базами даних, є високотехнологічним виробом і має відповідати таким критеріям:
- надійності;
- адекватну обробку позаштатних ситуацій;
- легкої модернізованості.
Програми можуть задовольняти цим вимогам тільки при ретельному дотриманні всієї технології розробки програмного забезпечення.
Загальні етапи розробки програм:
- визначення вимог до програми;
- розробка технічного завдання;
- розробка проекту програми;
- кодування програми;
- складання програми;
- тестування програмних модулів;
- дослідна експлуатація програми;
- доведення програмного забезпечення;
- введення програми у постійну експлуатацію;
- підтримка програми;
- визначення вимог до нової версії програми;
Для визначення вимог до програмирозробнику необхідно отримати відповідь на запитання: "Наскільки замовник зацікавлений у розробці програми?"
Якщо замовник не готовий брати активну участь у зустрічах та нарадах з розробником або каже, що для виконання роботи є інші кандидати, роботу над програмою слід завершити вже на цій стадії.
Якщо наміри замовника серйозні, то визначення вимог до програми, найімовірніше, питання не однієї зустрічі (наради), на яких необхідно з'ясувати та уточнити питання:
- Яка(і) мета(-и) програми?
- Коло користувачів програми.
- Нормативна (правова, довідкова) база, яку спираються процеси, алгоритмизируемые у програмі.
- Можливість та необхідність подальшого розвитку програми.
- Контактна особа, уповноважена вирішувати всі питання від імені замовника.
- Наявність матеріалів, які є або замовник планує підготувати для використання у програмі (Цей пункт особливо важливий для розробки Web-сайтів).
Розробка технічного завданняв ідеалі має здійснюватися замовником. На практиці це часто робить розробник через відсутність у замовника кваліфікованих фахівців, які обізнані в галузі розробки програмного забезпечення. Технічне завдання, зазвичай, розробляється з урахуванням ГОСТу 19.201-78 «ЕСПД. Технічне завдання. Вимоги до змісту та оформлення». У разі розробки технічного програмного забезпечення у складі автоматизованих систем застосовується ГОСТ 34.602-89 Інформаційна технологія. Технічне завдання створення автоматизованої системи».
Технічне завдання проходить процедуру погодження між замовником та розробником після перевірки правильності його оформлення службою нормоконтролю розробника.
На основі затвердженого технічного завдання розробляється проектна документація (проект). Зміст проекту залежить від типу програмного забезпечення та традицій підприємства розробника.
Обов'язковими складовими проекту мають бути:
- пояснювальна записка (за ГОСТом 19.404-79 «ЄСПД. Пояснювальна записка. Вимоги до змісту та оформлення»).
- опис програми (за ГОСТом 19.402-78 «ЄСПД. Опис програми»).
- перелік термінів, що використовуються у проекті. Для веб-сайтів до складу проекту включаються:
- ескіз дизайну сайту;
- перелік матеріалів, що використовуються у складі сайту;
- структура баз даних (у разі наявності таких)
Для програм, що працюють з базами даних, структура їх є обов'язковою складовою.
Проект є документом, на основі якого розробляється програма, та будь-які зміни у структурі та функціях програми без внесення змін до проекту неприпустимі. Саме проект є документом, на основі якого надалі проводиться аналіз програми та підготовка випуску наступних версій.
Для здійснення кодування програмипроектувальник видає завдання програмісту кодування модулів програми. У завданні визначаються вимоги до структури вхідних та вихідних даних модуля, до назв змінних, що використовуються у модулі, до алгоритму обробки даних модулем, до прийомів програмування (у разі потреби). Програмний код супроводжується докладним коментарем, від якості якого залежить можливість випуску наступних версій програми.
Ретельно в коді повинен бути описаний зміст вхідних та вихідних даних кожного модуля, а також зміст та функції самого модуля. Це важливо для успіху складання програми.
За стадію складання програмивідповідає керівник проекту. У цій стадії програма формується як єдине ціле. Оскільки всі складові програми створювалися різними програмістами, ця стадія особливо важлива усунення розбіжностей і несумісності всіх створених модулів.
Тестування програмипровадиться наступним чином:
- Визначається набір апаратури для тестування.
- Розробляються сценарії (контрольні приклади) для тестування.
- На основі сценаріїв перевіряється робота програми у штатному режимі (перевіряється правильність виконання тих функцій, які програма має виконувати).
- Перевіряється робота програми в позаштатних режимах (перевіряється, чи стійко працює програма в режимах, які можуть виникати лише при порушенні користувачами правил експлуатації програми, наприклад, введення букв у цифрове поле).
- Проводиться тестування на зручність управління програмою та якість інтерфейсів.
- Дані тестування та його результати обробляються та оформлюються відповідно до ГОСТу 34.603-92 «Інформаційна технологія. Види випробувань автоматизованих систем.
- У міру виявлення помилок останні виправляються і тестування проводиться повторно.
- Після виправлення помилок програма передається в дослідну експлуатацію.
Замовнику на стадії дослідної експлуатаціїпередається програма та обов'язковий пакет документації:
- відомість експлуатаційних документів (за ГОСТом 19.507-79 «ЄСПД. Відомість експлуатаційних документів»)
- формуляр (за ГОСТом 19.501-78 «ЕСПД. Формуляр. Вимоги до змісту та оформлення»)
- опис застосування (за ГОСТом 19.502-78 «ЄСПД. Опис застосування. Вимоги до змісту та оформлення»)
- керівництво системного програміста (за ГОСТом 19.503-79 «ЄСПД. Керівництво системного програміста. Вимоги до змісту та оформлення»)
- керівництво оператора (за ГОСТом 19.505-79 «ЄСПД. Керівництво оператора. Вимоги до змісту та оформлення»).
Залежно від виду завдання додатково можуть передаватися:
- керівництво програміста (за ГОСТом 19.504-79 «ЄСПД. Керівництво програміста. Вимоги до змісту та оформлення»)
- керівництво з т/о (за ГОСТом 19.508-79 «ЄСПД. Посібник з технічного обслуговування. Вимоги до змісту та оформлення»).
На стадії дослідної експлуатаціїпрограми фіксуються зауваження замовника та виявлені помилки.
На основі цього проводиться доведення програмного забезпечення, тобто усунення зауважень та помилок, і програма передається замовнику в постійну експлуатацію.
Підтримка програмив залежності від її складності здійснюється або замовником або розробником. Підтримка полягає у виконанні наступних видів робіт:
- консультації;
- обслуговування апаратних засобів, на яких використовується програма;
- перевірка та аналіз баз даних;
- верифікація правильності технологій обробки даних;
- документування та аналіз нових вимог до програми.
Останній пункт і є основою для початку розробки нової версії програми.
Тільки грамотний процес розробки програм забезпечує їх високу якість та довге життя!
Технології
