Зберігання елементів конфігурації

↑

▷ Содержание

⇐ ПредыдущаяСтр 33 из 38Следующая ⇒

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

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

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

Існують наступні види конфігураційних бібліотек:

· бібліотека поточного процесу розробки,

· бібліотека базових продуктів,

· архіви.

· бібліотеки/репозиторії конфігураційних елементів

Добре організована бібліотека є базою для УКПЗ. Вона повинна значно полегшувати пошук, читання, вставку, заміну і видалення.

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

Всі інтерфейси компонентів повинні бути помічені в наступній чурзі:

· назва проекту,

· ідентифікатор конфігураційного елементу,

· дата і час запису даних в репозиторій,

· короткий опис або характеристика.

Контроль зміни конфігурації

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

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

Зміни повинні бути перевірені перед внесенням інших змін. Зміни повинні документуватися, наприклад, в бланк змін.

Опис статусу конфігурації

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

Потрібно зберегти статус елементів конфігурації. У особливих випадках слід зберегти базиси. Таблиця показує розробку ПЗ, розбиту по віхах розробки. Кожна колонка представляє етап в розвитку ПЗ.

Таблиця - документ статусу конфігурації. Туди можна ввести і інші бланки запису статусів, якщо вони легкі для розуміння і внесення змін.

Статус конфігурації повинен оновлюватися і бути завжди доступним для команди проекту. Якщо програма не працює, але працювала зв день до цього, буде висунутим питанням: "Що змінилося?"

SPMP - план управління проекту розробки ПЗ Software Project Management Plan
SCMP - план управління конфігурації ПЗ, Software Configuration Management Plan
SVVP – план перевірки і затвердження ПЗ, Software Verification and Validation Plan
SQAP - план перевірки гарантії якості ПЗ, Software Quality Assurance Plan
URD - документ користувацьких вимог, User Requirements Document
SRD - документ вимог ПЗ, Software Requirement Document
ADD - документ аналізу-розробки, Analysis-Design Document
DPD - докладний документ проекту, Детальний документ проекту
SID - документ установки ПЗ, Software Installation Document

Перегляди

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

· Ідентифікатор інтерфейсу компонентів

· Місцезнаходження дефекту

· Опис дефекту

· Запропонований спосіб виправлення дефекту

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

Реліз

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

Релізи повинні бути добре описані, документовані і затверджені менеджерами проекту, управлінням підприємства і клієнтом. Елементи конфігурації повинні зберігатися в бібліотеці/репозиторії. Позначення і реєстрація повинні відповідати домовленості позначень. Наприклад, конфігурація SME 1.0 може не бути релізом, у відмінності від SME 1.4.

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

План управління конфігурації ПЗ

УКПЗ повинне бути сплановане, з чого випливає план управління конфігурації ПЗ (SCMP, Software Configuration Management Plan).

Процес ділиться на частини, кожна з яких повинна мати наступні певні характеристики:

· організація управління конфігурації,

· процедури визначення конфігурації,

· процедури управління змінами,

· процедури реєстрації статусу конфігурації,

· інструменти, техніки і методи управління конфігурації,

· процедури контролю постачальника,

· процедури зберігання конфігураційних документів.

Процедури повинні бути визначені перед початком написання коду і документації. ПУКПЗ повинен визначати можливі елементи конфігурації і їх опис.

Вміст ПУКПЗ (відповідно ANSI/IEEE std 828-1990)

Познавательные статьи:



Техника прыжка в длину с разбега

Организация работы процедурного кабинета

Области применения синхронных машин

Оптимизация по Винеру и Калману