Управління вимогами на базі стандартів, Комерція, Різне, статті

Автори: Роман Алфімов ®, Світлана Краснікова ®, Олена Золотухіна ®.

Олена Золотухіна є сертифікованим фахівцем з рішенням IBM Rational і викладає в Навчально-консалтинговий центр компанії “Інтерфейс”


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


Проблеми при виконанні проектів створення автоматизованих систем (АС) можуть виникати через неформального збору інформації, передбачуваної функціональності АС, помилкових або неузгоджених нефункціональних вимог до системи, а також нерегламентованої процедури їх зміни. Організація управління вимогами, перш за все, спрямована на дезавуювання таких проблем за рахунок удосконалення способів збору, документування, погодження та модифікації вимог до системи, відстеження вимог від зацікавлених осіб та з інших джерел, що їх породжують. Регламентація процедур управління вимогами повинна забезпечити високу якість роботи з ними в проектах, пов’язаних з розробкою, супроводом, створенням АС, розробкою їх організаційно-методичного забезпечення, а також впровадження готових систем за рахунок зменшення типових помилок при роботі з вимогами. Істотний момент пропонованої методики – використання міжнародних і вітчизняних стандартів в галузі управління життєвим циклом (ЖЦ) АС, що дозволяє практично без адаптації застосовувати методики в рамках вже існуючих, добре зарекомендували себе на практиці процесах розробки. В якості інструментального засобу, що підтримує моделювання вимог на основі UML 2.0., авторами використовується продукт Enterprise Architect компанії Sparx System.


Підготовка до управління вимогами


Під управлінням вимогами зазвичай розуміється систематичний підхід до виявлення, документування, планування реалізації вимог і відстеження їх змін [1-3, 4]. Методика покликана регламентувати наступні процедури роботи з вимогами: виявлення, документування, верифікація та затвердження вимог, планування реалізації та відстеження змін вимог.


Методика передбачає дві стадії: підготовку керування вимогами і безпосередньо управління ними. Процес підготовки управління вимогами представлений на рис. 1, а його опис в таблиці 1.


Таблиця 1. Опис процесу підготовки керування вимогами



























































Вхідна / Вихідна інформація


Крок процесу


Учасник


Бізнес
правила


01


Інформація від зацікавлених осіб (замовники, менеджер проекту) /


Етапи життєвого циклу системи


Визначення етапів ЖЦ системи, на якому буде організована робота з вимогами


Фахівець з управління вимогами


ГОСТ 34.601-90,


ГОСТ 19.102-77,


ГОСТ Р ІСО / МЕК 12207-99,


RUP [3]


02


Етапи ЖЦ / Шаблони документів


Підготовка шаблонів документів для кожного етапу


Фахівець з управління вимогами


ГОСТ 34.602-89,


ГОСТ 19.201-78,


РД 50-34.698-90,


RUP [3]


03


Шаблони документів / Коди типів вимог


Кодування типів вимог в документах


Фахівець з управління вимогами


ГОСТ 34.602-89,


ГОСТ 19.201-78,


РД 50-34.698-90,


RUP [3]


04


Коди типів вимог / Атрибути типів вимог


Визначення атрибутів типів вимог


Фахівець з управління вимогами


Типові атрибути згідно RUP [3]


05


Коди типів вимог / Залежності між типами вимог


Завдання залежностей між типами вимог


Фахівець з управління вимогами


Виконується для кожного конкретного проекту. Крок процесу може бути пропущений


06


Залежності між типами вимог, типи вимог з атрибутами, шаблони документів / План управління вимогами


Розробка плану управління вимогами


Фахівець з управління вимогами


ГОСТ 34.601-90,


ГОСТ 19.102-77,


ГОСТ 2.503-90,


RUP [3]


07


Інформація від зацікавлених осіб за процедурами роботи з вимогами / Процедура виявлення вимог, аналізу, верифікації та затвердження


Розробка процедур виявлення, верифікації, затвердження, зміни вимог


Фахівець з управління вимогами


ГОСТ 34.602-89,


ГОСТ 19.201-78,


РД 50-34.698-90,


ГОСТ 2.503-90,


RUP [3]


08


ГОСТ 34.602-89, ГОСТ 19. 201 -78/Шаблон моделі та його опис


Створення шаблону моделі вимог і його опис


Фахівець з управління вимогами


ГОСТ 34.602-89,


ГОСТ 19. 201-78



Рис. 1. Процес підготовки керування вимогами

Визначення етапів ЖЦ системи, на яких буде організовано роботу з вимогами, залежить від вибору його моделі. Далі як приклад ми будемо орієнтуватися на визначення згідно ГОСТ 34.601-90 “Автоматизовані системи. Стадії створення.”, В якому робота з вимогами в рамках процедур, регламентованих методикою, здійснюється на наступних стадіях: формування вимог до АС, розробка концепції, технічне завдання і супровід АС.


Підготовка шаблонів документів виконується для кожного етапу ЖЦ. Склад документів, що оформляються для виділених етапів ЖЦ системи, наведено в таблиці 2. Частина документів, що створюються і супроводжуваних при управлінні вимогами, визначена відповідно до ГОСТ, а частина готується за спеціальними шаблонами, які розроблені безпосередньо авторами методики і створені на основі узагальнення робіт [1-3, 5]. В документах, які формуються з використанням підготовлених шаблонів, будуть фіксуватися різні типи вимог.


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


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


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


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


Наступним кроком процесу є розробка основних процедур управління вимогами: процедура виявлення вимог, процедура верифікації вимог, процедура зміни вимог. При цьому враховується інформація, що надійшла від заінтересованих осіб за даними процедурам, і вимоги ГОСТ 34.602-89, ГОСТ 19. 201 -78.


У висновку створюється шаблон моделі вимог та його опис. В якості опорних документів використовуються ГОСТ 34.602-89, ГОСТ 19. 201 -78.


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


Часто для серії типових проектів можуть застосовуватися подібні процедури, шаблони, ролі, однак ігнорування підготовчого етапу в “нетиповий” проекті може привести до використання неадекватних процедур управління вимогами, що часто позначається на якості кінцевого продукту, або породжує інші проблеми в проекті, наприклад, відсутність або неактуальність проектної документації. Розглянемо приклад. Для типових проектів, обмежених за термінами реалізації (зазвичай до 6 міс.), Наявність докладної документації не обов’язково. У разі короткострокового проекту, не відноситься до типового (наприклад, з причини його значущості і перспектив розвитку), недостатня документованість змін вимог недопустима, що повинно знайти своє відображення у відповідних процедурах процесу управління вимогами.


Якщо орієнтуватися на ГОСТ 34.601-90, то ми пропонуємо використовувати методику управління вимогами на наступних етапах ЖЦ (таблиця 2). У таблиці також перераховані документи, що рекомендуються для фіксування вимог. Частина документів, що створюються і супроводжуваних при управлінні вимогами, визначена відповідно до ГОСТ, а частина готується за спеціальними шаблонами, орієнтованим на застосування для широкого класу проектів.


Таблиця 2. Стадії та етапи створення АС і оформляються документи



































№ стадії створення АС


Стадії створення АС


Етапи створення АС


Документи


01


Формування вимог до АС


1.1. Обстеження об’єкта та обгрунтування необхідності створення АС.


1.2. Формування вимог користувача до АС.


Інтерв’ю замовників і користувачів про проблеми


02


Розробка
концепції


2.1. Вивчення об’єкта.


2.2. Проведення необхідних науково-дослідних робіт. 2.3. Розробка варіантів концепції АС, що задовольняє вимогам користувача.


2.4. Оформлення звіту про виконану роботу.


Концепція


03


Технічне
завдання


3.1. Розробка та затвердження технічного завдання на створення АС.


ТЗ по ГОСТ 34.602 -89;


Опис автоматизуються функцій РД 50-34.698-90 п. 2.5;


Словник термінів;


Модель вимог;


Опис моделі вимог



08


Супровід АС


8.1. Виконання робіт відповідно до гарантійних зобов’язань.


8.2. Післягарантійне обслуговування


Інтерв’ю замовників і користувачів про проблеми;


ТЗ по ГОСТ 34.602 -89;


Запит на зміну вимог;


Опис автоматизуються функцій РД 50-34.698-90 п. 2.5;


Словник термінів


Модель вимог


Опис моделі вимог


 Процес управління вимогами


На підставі регламентних процедур реалізується процес управління вимогами (рис. 2, таблиця 3).


Таблиця 3. Опис процесу управління вимогами
















































Вхідна / Вихідна інформація


Крок процесу


Учасник


Бізнес
правила


01


Методи виявлення вимог, результати обстеження об’єкта автоматизації, план управління вимогами / Список виявлених вимог


Виявлення вимог і їх структурування


Системний аналітик


Процедури виявлення вимог


02


Список виявлених вимог / Модель вимог і її опис


Моделювання вимог


Системний аналітик


Шаблон моделі вимог і його опис


03


Список виявлених вимог / Документи з вимогами


Документування вимог


Системний аналітик,
Спеціаліст по вимогам


Шаблони документів


04


Документи з вимогами, модель вимог і її опис / Документи і моделі з вимогами верифіковані та затверджені


Верифікація та затвердження вимог


Експерт предметної області,


Рецензент


Процедура верифікації та затвердження вимог


05


Документи і моделі з вимогами верифіковані і затверджені / Базова версія вимог


Визначення базової версії вимог


Архітектор


Процедура верифікації та затвердження вимог (розділ, присвячений визначенню базової версії вимог)


06


Базова версія вимог / Змінені вимоги


Зміна вимог


Усі зацікавлені особи


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



Рис. 2. Процес управління вимогами


Приклад управління вимогами: виявлення


Вибір конкретного методу виявлення вимог (бізнес моделювання, інтерв’ювання, створення прототипів) залежить від типу проекту. Виявлення вимог проводиться системним аналітиком із залученням експертів по предметної області. Результатом цієї діяльності є вимоги, записані в узгодженому форматі та структуровані відповідно до своїх типами, як представлено в плані управління вимогами. Наприклад, виявлення функціональних вимог на основі опису бізнес-процесів проводиться наступним чином. Кожному бізнес-процесу ставиться у відповідність підсистема в системі, що розробляється, кожному кроку бізнес-процесу – функціональне вимогу. На рис. 3а представлений складу бізнес-процесів, а на рис. 3б – опис конкретного процесу “Зарахування студентів до університету”.


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


На основі складу і кроків бізнес-процесу, що підлягають автоматизації, будується матриця трасування (табл. 3, 4) ¸ яка дозволяє простежити зв’язку бізнес-процесів з реалізують їх підсистемами і конкретних кроків бізнес-процесів з функціональними вимогами, а також контролювати повноту і цілісність реалізації: кожному автоматизованих бізнес-процесах повинна бути поставлена ​​у відповідність підсистема (підсистеми), а підсистема повинна реалізовувати будь-який процес, відповідно.


Таблиця 3. Залежність підсистем від бізнес-процесів




























Бізнес-процес

Підсистема


1


Зарахування студента


Зарахування студента


2


Переклад студента


Переклад студента


3


Відрахування студента


Відрахування студента


4


Підготовка звітів


Підготовка звітів


5


Проведення сесії


Проведення сесії


Таблиця 4. Залежність функціональних вимог підсистеми “Зарахування студента” від кроків бізнес-процесу “Зарахування студента”



















Крок бізнес-процесу

Функціональне вимога


1


Формування списків груп


Формування списків груп


2


Заповнення особової картки студента


Ведення особистих карток студентів


3


Реєстрація видачі залікової книжки


Ведення журналу реєстрації видачі залікових книжок


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



Рис. 3. Приклад управління вимогами: виявлення a) Склад бізнес-процесів; б) Опис бізнес-процесу “Зарахування студентів до університету”




Рис. 4. Приклад управління вимогами: виявлення а) Склад підсистем; б) Склад функціональних вимог підсистеми “Зарахування студентів”


Висновок


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


Література


1.      Microsoft Solutions Framework 3.0 www.microsoft.com/rus/msdn/msf/default.mspx


2.      Oracle Custom Development Method (CDM)


3.      Rational Unified Process Version 2003.06.00


4. Карл Вігерс, Розробка вимог до програмного забезпечення. М.: “Російська Редакція”, 2004.


5. Липа В.В., Документування складних програмних засобів. М.: Сінтег, 2005.


Стандарти


1. ГОСТ 19.102-77 Єдина система програмної документації. Стадії розробки


2. ГОСТ 19.201-78 * Єдина система програмної документації. Технічне завдання. Вимоги до змісту та оформлення


3. ГОСТ 2.503-90 ЕСКД. Правила внесення змін


4. ГОСТ 34.601-90 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Автоматизовані системи. Стадії створення


5. ГОСТ 34.602-89 Інформаційна технологія. Комплекс стандартів на автоматизовані системи. Технічне завдання на створення автоматизованої системи


6. ГОСТ Р ІСО / МЕК 12207-99 Інформаційна технологія. Процеси життєвого циклу програмних засобів


7. РД 50-34.698-90 Методичні вказівки. Інформаційна технологія. Комплекс стандартів і керівних документів на автоматизовані системи. Автоматизовані системи. Вимоги до змісту документів

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*