9.3. Питання для самоконтролю

1. З якою метою використовують прототипи?

2. Зробіть порівняльну характеристику основних прототипів (горизонтальний, вертикальний, еволюційний, паперовий тощо) у вигляді таблиці.

3. Наведіть приклади різних аспектів застосовності.

Тема №10. Документування вимог

10.1. Методичні вказівки до вивчення теми

Щоб вимоги, виявлені і описані (см 06-Выявление вимог і 08-Специфицирование вимог) прийняли силу угоди між замовником і розробником, їх необхідно оформити у вигляді документу. У вітчизняній практиці для цього зазвичай використовується документ «Технічне завдання» (ТЗ), у західній – «Software Requirements Specification» ( SRS – «специфікація програмних вимог»). По суті це один і той же документ, тому далі у тексті використовується термін «ТЗ» при розгляді різних шаблонів його побудови, як на основі ДСТУ, так і західних методологій і стандартів.

Документування вимог регламентоване російськими ГОСТ 19.201-78 «Технічне завдання, вимоги до змісту і оформлення» і ГОСТ 34.602-89 «Технічне завдання на створення автоматизованої системи» [4-5].

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

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

Структура тз за гост 34.602-89

До змісту даної теми не входить перерахування усіх правил і рекомендацій даного ГОСТ, студенти можуть ознайомитися з ним самостійно [1]. Далі перераховані розділи, передбачені у ГОСТ, і розглянуті основні моменти, на які слід звернути увагу.

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

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

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

Вимоги до системи - ключовий розділ цього документу, тому він буде розглянутий нижче, більше детально.

Розділ «Склад і зміст робіт із створення системи» описує процес створення системи, зокрема вибір методології, що визначає зміст стадій, етапів і фаз і його конкретизацію для проекту (кількість етапів і ітерацій, їх основний зміст, тощо).

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

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

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

У якості додатків ГОСТ 34.602-89 рекомендує використати розрахунок очікуваної ефективності системи і оцінку науково-технічного рівня системи.

ГОСТ 34.602-89 поділяє усі вимоги до системи на три класи:

• вимоги до системи в цілому;

• вимоги до функцій (завдань), що виконуються системою;

• вимоги до видів забезпечення.

Серед вимог до системи в цілому (системні вимоги) вказуються вимоги до:

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

• режимам функціонування системи;

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

• надійності;

• безпеки;

• ергономіки і технічної естетики;

• транспортабельності для мобільних систем;

• експлуатації, технічного обслуговування, ремонту і зберіганню компонентів системи;

• захисту інформації від несанкціонованого доступу;

• збереженню інформації при аваріях;

• захисту від впливу зовнішніх дій;

• патентній чистоті;

• стандартизації і уніфікації,

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

Вимоги стандарту до функцій (завдань), у сучасній інтерпретації, поділяються на: [3]

• перелік функціональних вимог в прив'язці до підсистем і черг автоматизації;

• часовий регламент реалізації функціональних вимог;

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

• перелік і критерії відмов для кожної функціональної вимоги, по якій були задані вимоги по надійності.

Вимоги до видів забезпечення. Серед видів забезпечення ГОСТ 34.602-89 вказує математичне, інформаційне, лінгвістичне, програмне, технічне, метрологічне, організаційне, методичне.