Загальна характеристика стану в області документування програмних засобів

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

Уміння створювати програмну документацію визначає професійний рівень програміста. Замовник не вникатиме в тонкощі і особливості навіть найчудовішої програми. Замовник спочатку читатиме документацію. Велику роль грає в цьому і психологічний чинник.

Грамотно складений (точніше, створений) пакет програмної документації позбавить вас від багатьох прикростей. Зокрема, позбавитися від настирних питань і необгрунтованих претензій можна, просто відіславши користувача до документації. Це стосується раніше усього найважливішого документу - Технічного завдання. Можна нагадати про багатомільйонний позов до компанії IBM, який пред'явило одне велике видавництво, не задоволене якістю обчислювальної техніки і програмного забезпечення. IBM суд виграла тільки завдяки тому, що пред'явила підписане обома сторонами Технічне завдання. Було це давно, ще в 70-х роках 20 віків, проте суті справи це не міняє. На заході важливість програмної документації зрозуміли давно, разом з програмним забезпеченням поставляється цілий пакет документації.

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

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

Що має бути зроблене, окрім власне програми?

Що і як повинно бути оформлено у вигляді документації?

Що передавати користувачам, а що - службі супроводу?

Як управляти усім цим процесом?

Що повинне входити в само завдання на програмування?

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

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

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

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

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

До складу ЕСПД входять:

· засадничі і організаційно-методичні стандарти;

· стандарти, що визначають форми і зміст програмних документів, вживаних при обробці даних;

· стандарти, що забезпечують автоматизацію розробки програмних документів.

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

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

· орієнтацію на єдину "каскадну" модель життєвого циклу ПС;

· відсутність чітких рекомендацій по документуванню характеристик якості ПС;

· відсутність системної ув'язки з іншими діючими вітчизняними системами стандартів по ЖЦ і документуванню продукції в цілому, наприклад ЕСКД;

· нечітко виражений підхід до документування ПС як товарної продукції;

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

· відсутність рекомендацій по складу, змісту і оформленню перспективних документів на ПС, узгоджених з рекомендаціями міжнародних і регіональних стандартів.

ЕСПД потребує повного перегляду на основі стандарту ИСО/МЭК 12207-95 на процеси життєвого циклу ПС.

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

· стандарти ЕСПД вносять елемент впорядкування в процес документування ПС;

· передбачений стандартами ЕСПД склад програмних документів зовсім не такий "жорсткий", як деяким здається: стандарти дозволяють вносити в комплект документацію на ПС додаткові види програмних документів (ПД), необхідних в конкретних проектах, і виключати багато ПД;

· стандарти ЕСПД дозволяють на додаток мобільно змінювати структури і зміст встановлених видів ПД виходячи з вимог замовника і користувача.

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

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

Міжнародний стандарт IS0/IЕС 12207:1995 на організацію ЖЦ продуктів програмного забезпечення (ПО), здавалося б, дуже неконкретний, але цілком новий і частково "модний" стандарт.

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

Дата добавления: 2014-01-04