Posibniki.com.uaІнформатикаАвтоматизоване проектування інформаційних системТема 3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ВИМОГАМИ


< Попередня  Змiст  Наступна >

Тема 3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ВИМОГАМИ


3.1. КЕРУВАННЯ ВИМОГАМИ ЯК ОБЄКТ АВТОМАТИЗАЦІЇ

 

Дослідження «Хаос», проведене у 1995 році компанією Standish Group, визначило три головні чинники, що призводять до запізнення завершення проектів ІС, перевищення бюджетів і неадекватної реалізації: брак вхідної інформації від кінцевих користувачів, неповні вимоги і специфікації та їх змінення впродовж реалізації проекту. Подолати ці проблеми є завданням дисципліни керування вимогами.

Стандарт IEEE визначає вимоги як:

— умови або можливості, необхідні користувачеві для вирішення проблем або досягнення цілей;

— умови або можливості, що їх повинні мати системи або системні компоненти для виконання контракту або задоволення стандартів, специфікацій або інших формальних документів;

— документоване подання описаних умов або можливостей. Керування вимогами (requirements management) — це систематичний підхід до виявлення, організації, документування і відстежування вимог до системи. Належне виконання цієї дисципліни допомагає перевірити правильність системи, керувати змінами, аналізувати статус проекту. Але як формулювання вимог, так і робота з ними в подальшому пов’язана з численними проблемами. Слід також зазначити, що, незважаючи на важливість дисципліни, в багатьох проектах на виконання відповідних робіт витрачається замало часу.

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

— користувацькі вимоги (user requirements) — опис природною мовою (із додаванням пояснювальних діаграм) функцій, що виконуються системою, та обмежень, що накладаються на неї. Це опис високорівневих, узагальнених вимог, призначений для менеджерів і фахівців організаціїзамовника, кінцевих користувачів системи, менеджерів субпідрядних організацій, розробників системної архітектури. Можливі проблеми: відсутність чіткого і недвозначного викладення, змішування та об’єднання вимог;

— системні вимоги (функціональна специфікація, system requirements) — деталізований опис системних функцій та обмежень, що є підґрунтям для укладання угоди між замовником і розробником і зорієнтований на фахівців організаціїзамовника, кінцевих користувачів системи, розробників системної архітектури, розробників системи. Специфікація системних вимог може складатися на основі різних системних моделей, таких як об’єктна модель або модель потоків даних. Для запису часто використовується природна мова, але для запобігання двозначностям застосовують також структуровану природну мову із використанням стандартних форм і шаблонів, мови опису програм (PDL), графічні нотації (SADT, діаграми прецедентів), математичні специфікації (системи нотацій, ґрунтовані на математичних концепціях, таких як теорія кінцевих автоматів або теорія множин);

— проектна системна специфікація (software design specification) — узагальнений опис структури системи, який стане основою для деталізованого проектування системи та її подальшої реалізації. Ця специфікація доповнює й деталізує специфікацію системних вимог. Її читачами є фахівці організаціїзамовника (можливо), розробники системної архітектури, розробники системи.

За змістом розрізняють:

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

Багато проблем, що виникають під час розроблення системи, пов’язано з неточністю і «розмитістю» специфікацій вимог. Трактування таких формулювань розробниками не завжди збігається з очікуваннями замовника. Такі ситуації призводять до фіксації нових вимог і внесення змін до системи, що, своєю чергою, призводить до затримки розробки та її подорожчання. На практиці для великих і складних систем украй важко розробити комплексну й несуперечливу специфікацію функціональних вимог. Причиною є і складність самої системи, і неузгодженість опорних поглядів на те, що вона має робити. Ця неузгодженість може виявитись на будьякому етапі життєвого циклу і в системну специфікацію доведеться вносити зміни;

— нефункціональні вимоги — опис характеристик системи та її оточення. Вони пов’язані з такими інтеграційними властивостями, як надійність, час відгуку або розмір системи. Крім цього, можуть визначатися обмеження на дії та функції системи — часові обмеження, обмеження на процес розробки системи, пропускну спроможність пристроїв введеннявиведення, формати даних тощо. Водночас нефункціональні вимоги можуть стосуватися не лише програмної системи, а й, зокрема, технологічного процесу розробки. Крім того, в специфікації можуть бути вказані CASEзасоби, за допомогою яких має проектуватися система, і наведений процес проектування, який слід виконати. Нефункціональні вимоги відображають користувацькі потреби й базуються на бюджетних обмеженнях, ураховують організаційні можливості компаніїрозробника і можливість взаємодії майбутньої системи з іншими, а також зовнішні чинники, такі як нормативні акти, правила техніки безпеки тощо. Багато з нефункціональних вимог стосується системи загалом, а не її окремих частин. Тому вони є більш критичними і значущими порівняно з функціональними вимогами — їх порушення може спричинити непрацездатність системи.

Основна проблема нефункціональних вимог полягає в тому, що їх виконання важко перевірити. Часто їх пишуть, щоби відобразити загальні цілі замовника, але їх реалізація може виявитись досить складною через нечіткість формулювань. Вирішенням проблеми може бути вираження вимог через кількісні показники, які можна об’єктивно виміряти, але на практиці це проблематично — деякі системні вимоги, зокрема зручність супроводу, взагалі неможливо виразити через кількісні показники, а для інших це не може зробити замовник. Крім того, витрати на об’єктивне вимірювання кількісних нефункціональних вимог може бути надто високим. Іншою проблемою може виявитися конфлікт нефункціональних вимог з іншими вимогами;

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

У плані розробки вимоги можна розрізнити на:

— постійні — вимоги відносно стабільні, які виникають, виходячи з основної діяльності компанії і стосуються безпосередньо предметної області майбутньої системи;

— змінювані — вимоги, які відображають зміни, виконані під час розроблення системи або після введення її в експлуатацію. Такі вимоги можна, з одного боку, поділити на непостійні (ті, що змінюються через зміни в оточенні системи) і неочікувані (ті, що виникають під час розроблення). З іншого боку, можна виокремити непрямі вимоги (вимоги як результат упровадження ІС, здатної змінити організаційні процеси і показати нові способи роботи, які призведуть до нових змін) і вторинні (ті, що залежать від особливостей даної системи або від бізнеспроблем організації).

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

Керування вимогами (у термінології деяких авторів — «розробка технічних умов») можна поділити на розробку вимог і власне керування ними (керування змінами вимог, рис. 3.1). Важливість цієї дисципліни для забезпечення успішності проекту, складність та велика трудомісткість, пов’язана з необхідністю оброблення великої кількості інформації, зумовлює застосування різноманітних інструментальних засобів. Під час розроблення невеликих програмних систем для підтримки процесу управління достатньо скористатися текстовими процесорами, електронними таблицями і простими базами даних. Однак для розроблення та керування вимогами до великих систем знадобляться спеціалізовані засоби підтримки.

Структура процесів керування вимогами


< Попередня  Змiст  Наступна >
Iншi роздiли:
3.3. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ЗМІНАМИ ВИМОГ
3.4. ХАРАКТЕРИСТИКА СУЧАСНИХ ЗАСОБІВ АВТОМАТИЗОВАНОГО КЕРУВАННЯ ВИМОГАМИ
3.5. КЕРУВАННЯ ВИМОГАМИ ЗА ДОПОМОГОЮ IBM RATIONAL REQUISITEPRO
Тема 4. АВТОМАТИЗОВАНА ПІДТРИМКА ПРИЙНЯТТЯ ПРОЕКТНИХ РІШЕНЬ
4.2. АВТОМАТИЗОВАНА ПІДТРИМКА ГРУПОВОГО ПРОЕКТУВАННЯ
Дисциплiни

Англійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki