3. Документація по супроводу програмних засобів.

Документація по супроводу ПС (system documentation) описує ПС з погляду її розробки. Ця документація необхідна, якщо ПС припускає вивчення того, як воно влаштована (сконструйована), і модернізацію його програм. Як вже наголошувалося, супровід  це розробка, що продовжується. Тому у разі потреби модернізації ПС до цієї роботи притягується спеціальна команда розробників-супровідників. Цій команді доведеться мати справу з такою ж документацією, яка визначала діяльність команди первинних (основних) розробників ПС,  з тією лише різницею, що ця документація для команди розробників-супровідників буде, як правило, чужий (вона створювалася іншою командою). Щоб зрозуміти будову і процес розробки модернізованого ПС, команда розробників-супровідників повинна вивчити цю документацію, а потім внести до неї необхідні зміни, повторюючи в значній мірі технологічні процеси, за допомогою яких створювалося первинне ПС.

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

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

2. документацію, що допомагає вносити зміни до ПС.

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

• Зовнішній опис ПС (Requirements document).

• Опис архітектури ПС (description of the system architecture), включаючи зовнішню специфікацію кожної її програми (підсистеми).

• Для кожної програми ПС  опис її модульної структури, включаючи зовнішню специфікацію кожного включеного в неї модуля.

• Для кожного модуля  його специфікація і опис його будови (design description).

• Тексти модулів на вибраній мові програмування (program source code listings).

• Документи встановлення достовірності ПС (validation documents), що описують, як встановлювалася достовірність кожної програми ПС і як інформація про встановлення достовірності зв'язувалася з вимогами до ПС.

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

Документація другої групи містить

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

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

Вправи до лекції 13.

13.1. Що таке менеджер програмного засобу?

13.2. Що таке ординарний користувач програмного засобу?

13.3. Що таке адміністратор програмного засобу?

13.4. Що таке керівництво по інсталяції програмного засобу?

13.5. Що таке керівництво по управлінню програмним засобом?

13.6. Що таке керівництво по супроводу програмного засобу?

Литература к лекции 13.

13.1. Ian Sommerville. Software Engineering. - Addison-Wesley Publishing Company, 1992. P.

2. ANSI/IEEE Std 1063-1988, IEEE Standard for Software User Documentation.

3. ANSI/IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.

4. ANSI/IEEE Std 1016-1987, IEEE Recommended Practice for Software Design Description.

5. ANSI/IEEE Std 1008-1987, IEEE Standard for Software Unit Testing.

6. ANSI/IEEE Std 1012-1986, IEEE Standard for Software Verification and Validation Plans.

7. ANSI/IEEE Std 983-1986, IEEE Guide for Software Quality Assurance Planning.

8. ANSI/IEEE Std 829-1983, IEEE Standard for Software Test Documentation.