• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Угода позначень

Базис

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

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

Базиси не змінюються і служать основою для подальших розробок.

Ключові базові елементи - віхи управління проектом. Нові елементи визначаються (додаються) в процесі інтеграції нових компонентів.

Версії, варіанти

Термін "версія" (або варіант) використовується, щоб знайти схожі або майже однакові елементи, які відрізняються тільки в таких аспектах, як:

· кінцева платформа/конфігурація,

· протокол зв'язку, який взаємодіє із зовнішнім ПЗ,

· реалізація діагностування і тестування під час розробки ПЗ.

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

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

Наприклад, рядок SME/ANA/RD 3.2 означає: проект визначається як SME, пакет (завдання) - як ANA, RD означає документ вимог, 3-а версія, і 2-й перегляд.

Угода повинна:

· визначити назви елементів конфігурації,

· визначити людину, відповідальну за термінологію,

· визначити (якщо можливо) історію елементу.

Визначення конфігурації елементу

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

Конфігураційні елементи можуть містити інші елементи конфігурації системи. Ідентифікатори не міняються.

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

Конфігураційні елементи представляють проектну декомпозицію в завданнях.

Конфігурація повинна бути логічна і практична (проста для створення, копіювання, внесення змін і видалення). Відповідний рівень розбиття повинен бути вибраний для ідентифікації малих конфігураційних елементів. Дуже великими складно управляти, а дуже малих - контролювати і підтримувати. Ідентифікатор повинен містити ім'я, тип і версію інтерфейсу компонентів. Новий ідентифікатор не повинен змінювати старих.

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

Ідентифікатор повинен враховувати вид елементу. Трьома основними типами інтерфейсу компонентів є:

· початковий інтерфейс компонентів (наприклад, текст програми),

· вихідний інтерфейс компонентів (наприклад, двійковий код),

· інструмент для генерування вихідного елементу.

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

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

Відповідальність за конфігураційне число

Кожне конфігураційне число повинне мати не менше трьох рівнів відповідальності:

· відповідальність програміста,

· відповідальність менеджера по проектах,

· відповідальність органу контролю-перевірки.

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

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

Для більших проектів використовується бібліотекар.

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

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

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

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

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

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

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

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

· архіви.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читайте також:

1. Арабо-ізраїльська війна 1973 р. та Кемп-Девідська мирна угода.
2. Генеральна угода з по тарифам та торгівлі
3. Договори у рамках Світової організації торгівлі. Генеральна угода з тарифів і торгівлі товарами, основна мета та принципи ГАТТ
4. Зустрічна закупівля – це угода про взаємну купівлю. Вона має місце тоді, коли фірма погоджується придбати певний обсяг продукції для тієї країни, яка здійснила продаж.
5. Класифікація позначень
6. Колективний договір та угода. Трудовий договір.
7. Кредитна угода
8. Ліцензійні договори як угода між ліцензіаром і ліцензіатом на право використання об’єкта інтелектуальної власності.
9. Мадридська угода про міжнародну реєстрацію знаків 1891 м, і Протокол до нього 1989 р.
10. Мюнхенська угода і загарбання Чехословаччини
11. Опціонна угода
12. Перелік позначень, наведених у законі, що не можуть бути визнані як знак для товарів і послуг, поділяється на чотири групи.

Переглядів: 669