конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
 Скачать 14.87 Mb.
|
11.3. Загальна характеристика стану в області документування програмних засобів.Створення програмної документації - важливий етап, оскільки користувач починає своє знайомство з програмним продуктом саме з документації. Для чого призначений програмний продукт, як встановити програмний продукт, як почати з ним працювати - ось одні з перших питань, на які повинна відповідати програмна документація (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 на створення і розвиток автоматизованих систем - узагальнені, але сприймані як дуже жорсткі по структурі ЖЦ і проектній документації. Але ці стандарти багатьма вважаються бюрократичними до шкідливості і консервативними до застарівання. |