Опис дизайну програмного забезпечення (SDD)

SDD повинен описувати, як програмне забезпечення буде будуватися відповідно до вимог SRD. SDD повинен описувати компоненти й підкомпоненти розробки програмного забезпечення, включаючи бази даних і внутрішні інтерфейси. SDD може бути підготовлений як архітектура (верхній рівень SDD) і повинен бути в подальшому розширений для отримання докладних SDD (див. IEEE Std 1016 ™ -1998 [B11]).

4.3.2.3. Плани верифікації та валідації

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

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

4.3.2.4. Звіт з верифікації та валідації

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

4.3.2.5. Користувацька документація

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

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

4.3.2.6. План конфігураційного управління (SCMP)

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

4.3.3. Інші документи

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

1. План процесу розробки.

2. Опис стандартів розробки.

3. Опис інженерних методів / процедур / засобів.

4. План управління проектом (див. IEEE Std 1058 ™ -1998)

5. План обслуговування (див. IEEE Std 1219 ™ -1998)

6. Плани безпеки програмного забезпечення (див. IEEE Std 1228)

7. План інтеграції програмного забезпечення

4.4 Стандарти, практики, конвенцій, і метрики (див. розділ 4 SQAP)

4.4.1 Мета

 

Цей розділ повинен:

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

б) Положення про те, як повині контролюватися та гарантуватися відповідності між цими елементами.

4.4.2 Зміст

 

Питання, що розкриваються у змісті повинні включати основні технічні, дизайнерські і інші аспекти діяльності зокрема пов’язані із програмуванням, наприклад,
документація, змінна і іменування модулів, програмування, контроль якості і тестування.

а) Стандарти документації;

б) Стандарти дизайну;

в) Стандарти кодування;

г) Стандарти коментування;

е) Визначення стандартів і практик;

е) Обраний продукт забезпечення високої якості програмного забезпечення, гарантії та метрики даного процесу;

 

4.5 Тестування (розділ 5 SQAP)

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

4.6 Звітність проблем і коригувальних дій (розділ 6 SQAP)

Цей розділ повинен:

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

б) Вказати конкретні організаційні обов'язки, пов'язані із їх вирішенням.

 

4.7 Засоби, методи і методики (розділ 7 SQAP)

 

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

 

4.8 Контроль середовища (розділ 8 SQAP)

 

У цьому розділі зазначаються методи і засоби, які будуть використовуватися для:

 

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

б) Захист комп'ютерних програм на фізичних носіях від несанкціонованого доступу або випадкового пошкодження чи деградації на всіх етапах життєвого циклу програмного забезпечення. Також диний етап може бути забезпечений як частина SCMP.

 

4.9 Контроль розробника (розділ 9 SQAP)

 

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

У цьому розділі зазначаються також методи, які будуть використовуватися для забезпечення відповідності вимогам згідно стандарту. Якщо програма має бути розроблена відповідно контракту, то процедури перегляду договору і оновлення повинні бути описані.

4.10 Збір коментарів, їх підтримка і збереження (розділ 10 SQAP)

 

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

4.11 Навчання (розділ 11 SQAP)

Цей розділ визначає заходи з підготовки кадрів, необхідних для задоволення потреб SQAP.

4.12 Управління ризиками (розділ 12 SQAP)

 

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

 

Додаток Г. Методичні вказівки щодо складання плану впровадження та супроводу ПЗ

Впровадження ПЗ в експлуатацію та його супровід є останніми ключовими етапами життєвого циклу ПЗ. Етап впровадження, як правило, є найкоротшим за тривалістю серед всіх інших етапів, але потребує надзвичайного уважного планування і врахування багатьох факторів. Етап супроводу часто виявляється найбільш тривалим етапом життєвого циклу ПЗ і забезпечує підтримку функціонування та еволюцію програмного продукту. Зміст цих етапів докладно розкривається в стандартах ISO/IEC 12207 «Software Life Cycle Processes» («Процеси життєвого циклу ПЗ»), ISO/IEC 14764:2006 «Software Engineering – Software Life Cycle Processes – Maintenance» («Інженерія ПЗ – Процеси життєвого циклу ПЗ – Супровід») та IEEE 1219-1993 «IEEE Standard for Software Maintenance» («Стандарти IEEE для супроводу ПЗ»).

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

В залежності від масштабу програмної системи, плани її впровадження та супроводу можуть бути поєднані в одному документі або рознесені по різних документах. В мережі Інтернет існує ціла низка шаблонів для створення планів впровадження та супроводу. Зокрема, такі шаблони можна знайти в http://www.mysoftwaretemplates.com/software-development-templates/

Загальна структура плану впровадження програмного продукту:

1. Вступ (загальна інформація про призначення плану впровадження)

2. Ролі і відповідальності (перелік осіб, задіяних у впровадженні системи з їх ролями та обов’язками)

3. Часовий план (розклад впровадження системи із зазначенням всіх задач і відведеного на них часу)

4. Навчання персоналу (порядок і терміни навчання користувачів системи)

5. Робоче середовища (конфігурація обчислювального середовища для встановлення розробленої системи)

6. Процедура інсталяції (покроковий опис процедури розгортання системи в робочому середовищі з базовою перевіркою працездатності системи)

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

В процесі розробки плану впровадження необхідно звернути увагу на наступні діяльності:

• Виведення існуючої системи з експлуатації, якщо мова йде про заміну існуючої системи на нову;

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

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

• Інтеграція з зовнішніми сервісами, такими як сервіси географічних карт, сервіси оплати кредитними картками, сервіси валідації поштових адрес тощо;

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

• Навчання користувачів роботі з новою системою, що включає підготовку і проведення тренінгу, віддалено або на базі замовника чи розробника.

План супроводу в загальному випадку має таку структуру:

1. Вступ (загальна інформація про призначення плану супроводу)

2. Огляд системи (коротка характеристики програмної системи, її основні функції та задачі)

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

4. Персонал супроводу (особи, задіяні в роботах з супроводу, їх функції та обов’язки)

5. Процедури супроводу (докладний опис всіх процедур супроводу із висвітленням організаційних, технічних та економічних аспектів)

План супроводу повинен докладно висвітлювати всі процедури супроводу, прийняті для даного програмного продукту. Основними процедурами супроводу є:

• Звітування, аналіз, виправлення та відслідковування дефектів в програмній системі;

• Подання, реалізацію та відслідковування запитів на розширення функціональності системи;

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

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