2. Стандарти, правила і порядок здійснення дій проекту

• Стандарти проекту

• Стандарти документу

• Термінологія

• Стандарти програмування

• Засоби розробки ПЗ

ЧАСТИНА II – ВИЗНАЧЕННЯ СКЛАДОВИХ

n [ІДЕНТИФІКАТОР СКЛАДОВОЇ]

n.1. Тип n.2. Ціль n.3. Функція n.4. Підкомпоненти n.5. Зв'язки n.6. Інтерфейси n.7. Ресурси n.8. Посилання n.9. Трансформація n.10. Дані

Додаток A. Початковий текст програми.

Додаток B. Матриця зв'язків вимог і компонентів програмного забезпечення.

Якість DPD

Модифікованість документа

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

Еволюція документа

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

Відповідальність за документ

Міра відповідальності повинна бути однозначно визначена. Зазвичай відповідальний - програміст, який створює програмне забезпечення.

Середовище документа

Оригінал документа повинен бути добре захищений. Інші версії повинні бути похідними від оригіналу.

Інші рекомендації по ДДП

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

Етап реалізації

Серед основних результатів етапу реалізації є:

• розширений документ з вимогами,

• розширений проект, який в даний момент завершується документацією,

• код з перевіреними модулями,

• звіт про перевірені модулі.

Етап тестування

Серед головних результатів етапу тестування є:

• покращені код, проект, модель і специфікація вимог,

• звіт про тести з їх результатами.

Етап установки

Серед головних результатів етапу установки є:

• покращені код, проект, модель і специфікація вимог.

Якість програмного забезпечення

Стандарти і система якості

Стандарти - загальні правила якості, яким продукт повинен відповідати.

Стандарти повинні бути визначені і задокументовані.

Гарантія якості програмного забезпечення (SQA, software quality assurance) визначає, чи задовольняють плани стандарти, чи слідують процедури планам, чи реалізовуються продукти згідно планів.

Важливе завдання в SQA - підготовка і організація документації.

План гарантії якості ПЗ (SQAP)

План гарантії якості ПЗ (SQAP, Software Quality Assurance Plan) повинен змінюватися протягом життєвого циклу програми. Першу версію потрібно завершити до кінця формулювання вимог.

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

Зміст плану гарантії якості ПЗ залежить від розміру проекту.

Секції ПГЯПЗ

ПГЯПЗ повинен бути зрозумілим, несуперечливим і підлягати змінам. Він повинен бути розглянутий і схвалений контролюючим органом. Цей документ може розповсюджуватися в електронній формі.

ПГЯПЗ повинен бути створений для наступної фази після завершення попередньої.

Зміст ПГЯПЗ

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

Організаційна інформація

a - резюме (максимум - 200 слів)

b - зміст

c - стан документації

d - зміни, починаючи з останньої версії

Тіло документа

1. Ціль

Секція повинна бути описана стисло: завдання ПГЯПЗ, тип читача.