
- •Звіт з навчальної практики: «Конструювання програмного забезпечення»
- •План контролю якості
- •Задіяні документи:
- •Управління:
- •Документація
- •Мінімальні вимоги до документації:
- •Стандарти, практики, домовленості і метрики.
- •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 Повідомлення користувачу
- •Висновок:
План управління конфігураціями (scmp)
1. Введення
Даний План управління конфігураціями ПЗ (SCMP) описує, як ведеться робота з артефактами гри Final Fantasy.
1.1. Скорочення
CI - Configuration Item. Елемент конфігурації - будь-який елемент, відстежувати системою управління конфігураціями.
СМ - Configuration Management. Управління конфігураціями - процес підтримки релевантних версій артефактів проекту.
SCMP - Software Configuration Management Plan. Даний документ.
1.2. Терміни
Затверджений CI - CI, підписаний керівництвом проекту.
Артефакт - остаточний або проміжний матеріал проекту (наприклад, документ, вихідний код, об'єктний код, результат тесту).
Головний файл - спеціальним чином побудований файл для даного проекту, визначається в розділі 3.1.2.
2. Управління конфігураціями
2.1. Організація
Спеціальний інженер, що виділяється відділом контролю якості, буде назначений провідним конфігурацію на весь час проведення даного проекту.
2.2. Відповідальність за управління конфігураціями
2.2.1. Ведучий конфігурацію
Ведучий конфігурацію відповідає за організацію та управління конфігурацією. Якщо це можливо, ведучий конфігурацію повинен обговорювати плани управління конфігураціями з командою розробників до того, як ці плани вводяться в дію. Ведучий конфігурацію підтримує даний документ (SCMP). Ведучий конфігурацію відповідає за установку і супровід інструментів управління конфігураціями, визначених у розділі 2.3. Архівація даних повинна проводитися відповідно до корпоративної інструкцією 12345.
Ведучий конфігурацію відповідає за налаштування, супровід та резервне копіювання використовуваних інструментів управління конфігураціями. Він повинен також розробити план дій на випадок, якщо використовувані інструменти виявляться не підтримуваними (наприклад, з вини постачальника).
Додаткові обов'язки ведучого конфігурацію описані в розділах 3.3, 3.4, 3.5 і 3.6.
2.2.2. Лідер проекту
Лідер проекту і керівник проекту можуть виконувати функції ведучого конфігурації тільки у виняткових обставинах. Вони зобов'язані знати всі відповідні засоби доступу до документів під час проведення проекту. Лідер проекту зобов'язаний перевірити, що архівування даних ведеться в відповідно із інструкцій, згаданої в розділі 2.3.
Додаткові обов'язки лідера проекту описані в розділах 3.3 і 3.4.
2.2.3. Розробники
Кожен розробник зобов'язаний виконувати правила управління конфігураціями, опубліковані провідним конфігурацію. Розробники також зобов'язані слідувати документом 56789 «Посадові обов'язки інженерів». Додаткові обов'язки розробника описані в розділі 3.
2.3. Застосовувані політики, директиви та процедури
1. Управління конфігураціями для даного проекту повинно здійснювати відповідно до вказівок з управління конфігураціями, викладений в корпоративному документі 7890 версії 6 від 17.01.13
2. У відповідності з політикою поліпшення процесу розробки потрібно проводити оглядові наради по ходу і в кінці проекту, і всі запропонувати по поліпшенню повинні фіксуватися з метою використання їх в організації. Дані наради потрібні для підготовки підрозділу розробки до сертифікації по СММ рівня 5. Результати самооцінки повинні бути відправлені керуючому, відповідальному за покращення процесу, не пізніше трьох тижнів після того, як відбулася нарада. Всі розділи, в яких вказані можливі поліпшення, повинні містити відповідний матеріал і конкретні приклади.
3. Всі поточні та попередні версії CI повинні зберігатися.
4. До головного файлу (визначений в розділі 3.1.2) має доступ тільки ведучу конфігурацію, а в його відсутність - начальник відділу.
5. Паролі управління конфігураціями повинні змінюватися відповідно до прийнятих корпоративними правилами безпеки з наступним додаванням: ніякої пароль не повинен змінюватися, поки лідер проекту, керівник проекту та відповідальний за якість не сповіщені про вимірюванні і не підтвердили отримання сповіщення.
6. Лідер проекту та начальник відділу повинні завжди мати повний доступ до всіх документів, які зачіпає управління конфігураціями. Кожні два тижні лідер проекту повинен надавати форму http://www.ultracorp.division3.accessVerification своєму начальникові для верифікації прав доступу.
7. У проекті Зустріч буде використовуватися засіб SuperCMTool версії 3.4, що поставляється компанією SuperCMTool.
8. Архівація повинна проводитися у відповідності з правилами відділу, документи 123456.
3. Види діяльності
3.1. Визначення конфігурації
3.1.1. Визначення елементів конфігурації
Лідер проекту несе відповідальність за визначення всіх елементів конфігурації. Розробники, бажаючі визначити новий CI, повинні отримати згоду лідера проекту по електронній пошті або іншим способом. Якщо лідер проекту недоступний протягом більш ніж одного робочого дня, провідний конфігурацію має право включити в конфігурацію пропонований елемент.
3.1.2. Іменування елементів конфігурації
Ведучий конфігурацію несе відповідальність за маркування всіх CI. Погодження про імена наступне.
Версія проекту Final Fantasy |
Версія SRS |
Версія SDD |
Final Fantasy 1.01 |
1.4.8 |
1.3. |
Final Fantasy 2.0 |
1.5 |
1.4. |
3.1.3. Отримання елементів конфігурації
Для модифікації CI розробник повинен взяти CI за допомогою процедури checkout інструменту SuperCMTool. Відзначимо, що SuperCMTool пропонує користувача заповнити спеціальну форму і вказати, на який термін береться CI. Ця інформація запам'ятовується і надається іншим користувачам, бажаючим взяти даний CI на модифікацію. Будь-який бажаючий взяти даний CI повинен домовитися з поточним власником CI про передачу засобами SuperCMTool. Ні за яких обставин розробники не повинні передавати один одному CI прямо, в обхід SuperCMTool. Для будь-якого розробника будь CI повинен бути доступний на читання в будь-який час.