- •Звіт з навчальної практики: «Конструювання програмного забезпечення»
- •План контролю якості
- •Задіяні документи:
- •Управління:
- •Документація
- •Мінімальні вимоги до документації:
- •Стандарти, практики, домовленості і метрики.
- •6. Огляди та аудити
- •6.1. Мета
- •План управління конфігураціями (scmp)
- •2.1. Організація
- •2.2.2. Лідер проекту
- •2.2.3. Розробники
- •2.3. Застосовувані політики, директиви та процедури
- •3.2. Контроль конфігурації
- •3.2.1. Запит на зміни
- •3.2.3. Схвалення або несхвалення змін
- •3.2.4. Реалізація змін
- •3.3. Визначення статусу конфігурації
- •3.4. Аудити та огляди конфігурації
- •3.5. Управління інтерфейсом
- •3.6. Контроль постачальників та субпідрядників
- •Розклад
- •5. Ресурси
- •6. Супровід
- •План управління програмним проектом (spmp) для відеогри Final Fantasy
- •1. Введення
- •1.1. Огляд проекту
- •1.2. Результуючі артефакти проекту
- •1.3. Розвиток spmp
- •1.4. Посилальні матеріали
- •1.5. Абревіатури
- •2. Організація проекту
- •2.1. Модель процесу
- •2.2. Організаційна структура
- •3.4. Механізми моніторингу та контролю
- •3.5. План розстановки кадрів
- •8.Звіти про проблеми і корекційна діяльність
- •9.Інструменти, технології та методики
- •10. Контроль програмного коду
- •11. Контроль носіїв
- •12. Контроль постачальників
- •13. Збір, супровід та зберігання протоколів
- •14. Навчання
- •15. Управління ризиками
- •Специфікація вимог до програмного забезпечення (srs) для відеоігри Final Fantasy, частина 1
- •Введення
- •Загальний опис
- •3.2.1.1. Case-діаграма героя
- •3.2.1.2. Case-діаграма монстра
- •5. Проектна документація
- •1.1. Мета
- •1. Введення
- •1.1. Мета
- •1.2. Опис проекту
- •5.1.2. Інтерфейс пакету Персонажі FinalFantasy
- •6.1.3. Клас Зовнішніх персонажів(монстрів)
- •6.1.4 Клас артефактів
- •6.2. Детальне проектування даних
- •Розробка коду програми.
- •7. Документація по тестуванню програмного продукту гри «Final Fantasy».
- •8. Експлуатаційна документація
- •Характеристика програмного засобу
- •2.3. Робота з програмним засобом
- •3.4 Повідомлення користувачу
- •Висновок:
8.Звіти про проблеми і корекційна діяльність
Форма звіту про виявлений дефект у програмному забезпеченні, яку повинна використовувати команда проекту Final Fantasy, представлена на рис. 2.19. Для заповнення цієї форми розробники використовують спеціальний додаток describeDefect. Номер дефекту визначається автоматично, і додаток гарантує заповнення всіх необхідних полів.
1. Номер дефектe: |
2. Хто знайшов: |
3. Зачіпає документи: |
|
Зачіпає вихідний код* |
4. Пакет(и) |
5. Клас(и) |
6. Метод(и) |
7. Серьезность: |
8 Тип: |
9. Фаза з'являння** |
|
Вим □ Арх □ Дет. проект. □ |
Peaіліз. □ Интегр.О |
10. Детальний опис: |
|
11. Рішення: |
12. Статус відкритий/закритий: |
13. Підписи: опис і план інспектування: |
|
14. Код рішення і план тестування інспектовані: |
|
15. Зміни одобрено: |
|
Рис. 2.19. Форма звіту про дефект
Розрізняються наступні значення рівня серйозності дефектів.
♦ Серйозний дефект: наявність такого дефекту тягне невиконання вимог до програмного забезпечення.
♦ Тривіальний дефект: такий дефект не впливає на виконання чи супроводу додатка.
♦ Незначний дефект: дефект, який не відноситься до двох попередніх категорій.
У разі виявлення тривіального дефекту розробник не зобов'язаний створювати звіт про дефект - досить послати повідомлення по електронній пошті тому, хто найбільш ймовірно може усунути цей дефект.
У документах зустрічаються дефекти наступних типів: відсутність матеріалу, неясність, неоднозначність, неповнота, повтор (в тому ж документі або в іншому) і протиріччя.
У вихідному коді зустрічаються наступні типи дефектів: синтаксичні, логічні, помилки в даних (тобто змінна приймає неприпустиме значення) і порушення режиму безпеки (тобто можливий недопустимий обхід правил безпеки).
Відповідальний за якість (а в подальшому команда з контролю якості) створює і підтримує базу даних дефектів, в якій зібрані звіти про дефекти, що описують всі проблеми, невідповідності і аномалії проекту Final Fantasy. Відповідальний за якість повинен забезпечити систематичну фіксацію знайдених дефектів за зазначеною формою, направлення їх на розгляд та усунення. Направління дефектів на розгляд повинно проводитися відповідно до SCMP.
Після третьої ітерації при виявленні дефекту відповідальний за якість направляє звіт до Ради з контролю змін (ССВ - Change Control Board). На перших трьох ітераціях відповідальний за конфігурацію буде виконувати функції команди з контролю якості, а лідер проекту буде виконувати функції Ради з контролю змін відповідно до SPMP. ССВ оцінює отриманий звіт про дефект і призначає йому один з пріоритетів: Негайно, Обов'язково або Не обов'язково. Потім ССВ призначає команду розробників проекту Зустріч, команду з контролю якості або команду з управління конфігураціями відповідальної за вирішення проблеми. ССВ також визначає термін вирішення проблеми, грунтуючись на пріоритеті проблеми та результати аналізу попередніх звітів про дефекти. Після того як проблема, поставлена в звіті про дефект, вирішена, команда з контролю якості інспектує рішення, а відповідальний за якість інформує ССВ про результати інспекціювавання. Якщо необхідно, процес повторюється.