Лабораторна робота №1

Методології розробки програмного забезпечення. Технологія Rational Unified Proccess (RUP). Технологія МSF.

Мета роботи: ознайомитися з основними методологіями розробки програмного забезпечення. Розглянути особливості технологій RUP та MSF, їх основні принципи та засоби для практичного застосування.

Задачі лабораторної роботи: за варіантом завдання попередньо сформувати перелік вимог користувача до програмного продукту.

1. Теоретичні відомості

Аналіз вимог

Ф. Брукс у своєму класичному есе наступним чином охарактеризував роль вимог в розробці ПЗ: «Найжорсткіше і єдине правило побудови систем програмного забезпечення (ПЗ) – вирішити точно, що ж будувати. Ніяка інше частина концептуальної роботи не є такою складною, як з‘ясування деталей технічних вимог, в тому числі й взаємодія з людьми, з механізмами та з іншими системами ПЗ. Ніяка інша частина роботи так не шкодить результатам, якщо вона виконана погано. Помилки ніякого іншого етапу роботи не виправляються так тяжко».

Наука виділення і формалізації якісних (іноді кажуть " гарних", " правильних") вимог носить багато в чому емпіричний характер. Однак, на практиці розробки програмних систем накопичилися певні уявлення про те, які властивості повинні мати вимоги до програмної системи. Це:

· повнота,

· ясність,

· коректність,

· узгодженість,

· верифікованість,

· необхідність,

· корисність при експлуатації,

· здійснюваність,

· кодифікованість,

· трассуємість,

· впорядкованість по важливості й стабільності,

· наявність кількісної метрики.

Більшість з цих властивостей розкрито у першому розділі стандарту IEEE. Розглянемо ці властивості детальніше.

Повнота. Як відомо з теорії штучного інтелекту, неповнота – одне з фундаментальних властивостей людського знання. При створенні програмних систем нам приходиться мати справу з характеристиками ще неіснуючої системи. Ідея про те, що необхідно сформулювати всі вимоги повністю, тобто вичерпним чином, до початку проектування, а тим більше - реалізації системи, відійшла у минуле разом з так званим каскадним підходом [3.2], який підтримував послідовну модель реалізації системи. Спіральний [3.2] підхід, на якому базується більшість сучасних методологій, передбачає поетапне виділення й деталізацію вимог на всьому протязі циклу розробки системи.

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

Вимогу повноти можна розглядати в двох аспектах: повнота окремої вимоги і повнота системи вимог.

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

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

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

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

К.Вігерс [3.3] дає наступну пораду по підвищенню ясності документів: " Пишіть документацію просто, коротко й точно, застосовуючи лексику, зрозумілу користувачам".

Ще одною стороною поняття " ясність вимог" є його прослідковуваність (див. також поняття трасуємості далі по тексту). Вимога, яка сформульована ясно, може бути прослідкована, починаючи від того документу, де вона сформульована вперше, і до робочих специфікацій.

Коректність і узгодженість (непротирічність). Коректність – одна з найваж­ливіших властивостей вимог. К. Вігерс у [2] вводить поняття коректності вимоги через точність опису функціональності. У цьому сенсі коректність в певній мірі конкуує з повнотою. Але є й відмінність: якщо властивість повноти має скоріше якісний характер: абсолютна повнота є недосяжним ідеалом, до якого можливо наближатися, то властивість коректності носить оціночний характер і задає дихотомію: кожна з вимог або коректна, або ні. Крім того, можна говорити про взаємну коректність вимог чи узгодженість (непротирічність): якщо дві вимоги вступають у конфлікт, значить – як мінімум одна з них некоректна. В іерархії вимог можна виділити вертикальну й горизонтальну узгодженість. Іншими словами, вимоги не мають протирічити, відповідно, вимогам свого рівня ієрархії й вимогам " батьківського" рівня. Так, вимоги користувачів не мають протирічити бізнес-вимогам, а функціональні вимоги – вимогам користувача.

Верифікованість (придатність до перевірки). Ознаки (властивості) вимог, що розглядаються, неможна вважати незалежними. В математичній статистиці такі ознаки називають корельованими. Так, властивість верифікованості істотно пов‘язана з властивстю ясності й повноти: якщо вимога представлена на мові, зрозумілій та однаково сприймається учасниками процесу створення інформаційної системи, до того ж вона є повною, тобто ні одна з важливих для реалізації деталей не упущена – значить, цю вимогу можна перевірити. При цьому в ході перевірки у сторін (прймаючої і виконавшої роботу) не повинно виникнути нерозв‘язаних протиріч в оцінках. Оскільки добре зформульовані вимоги складають основу успішного створення системи – роль верифікованості важко переоцінити. Вимоги до системи є основою контракту меж Замовником та Виконавцем і якщо дані вимоги неможливо перевірити – значить і контракт не має ніякого сенсу, і як наслідок, успіх чи поразка проекту будуть залежати тільки від емоційних оцінок сторін та їх здатності домовитися, а це – надто непевна основа для здійснення робіт.

Необхідність та корисність при експлуатації є одним із самих суб‘єктивних і складно перевіюваних властивостей вимог.

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

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

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

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

Здійсненність (виконуваність) є в деякій степені конкуруючою по введеним вище двом властивостям.

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

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

Виконуваність вимог на практиці визначається розумним балансом між цінністю (ступенем необхідності й корисності) і потрібними ресурсами. Так, якщо вартість контракту на розробку інформаційної системи складає $10000, а витрати на виконання нової вимоги, що виникла в момент, коли проект виконаний наполовину, оцінюється в $4000, чи є воно невиконуваною? Скоріше, так, якщо Виконавець доведе Замовнику новизну вимоги (вимога не входила в узгоджені специфікації) і складність її виконання. Але, якщо вимога є критично важливою, необхідною, а вийшла з поля зору при підписанні контракту Замовник готовий виділити додатково фінансування, а Виконавець – трудові ресурси – значить, вимога виконувана. Таким чином, вимогу здійсненності у ряді випадків також варто вважати суб‘єктивною, а критерії її оцінки лежать в області домовленостей між Замовником та Виконвацем.

Відмінною ілюстрацією балансування між цінністю й виконуваністю вимог є так званий трикутник компромісів.

Рис. 3.1. Трикутник компромісів..

В якості роз’яснення до рис. 3 можна навести цитату з " білих сторінок", розміщених Microsoft у відкритому доступі.

Добре відомий взаємозв‘язок між ресурсами проекту (людськими й фінансовими), його календарним графіком (часом) і реалізаційними можливостями (рамками). Ці три змінні утворюють трикутник, показаний на рис. 3. Після досягнення рівноваги в цьому трикутнику змінення на будь-яких з його сторін для підтримки балансу вимагає модифікацій на іншій (двох інших) сторонах і/чи на початково зміненій стороні.

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

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

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

Інша мета трасування – підвищити керованість проектом: при зміненні окремо взятої вимоги стає зрозумілим - які з проектних, робочих і інших артефактів треба змінити.

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

Стабільність вимог характеризує прогнозну оцінку незмінності вимог в часі.

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

Яких вимог не має бути

У відповідності до нормативів [5], специфікація вимог не повинна містити деталей проектування чи реалізації (крім відомих обмежень). Іншими словами, вимоги мають відповідати на питання: " що має робити система", абстрагуючись від питання " як вона це має робити". Прагнення приймати детальні проектні рішення на етапі аналізу вимог - одна з типових " ловушок", типових для недосвідчених команд розробників. Варіантів реалізації завжди більше, ніж один, а для прийняття зваженого рішення потрібна максимально повна інформація. Тому етапи роботи з вимогами, проектування й реалізації плануються почергово, хоча можуть бути частково розпаралелені в рамках ітераційного підходу до створення програмних систем.

Як і ким використовуються вимоги?

ü Фахівці з АВ – постановка задачі, визначення рамок проекту;

ü Представник Замовника - постановка задачі, визначення рамок проекту, контроль роботи Виконавця, прийомка результатів роботи;

ü Архітектор системи – розробка архітектури, проектування підсистем;

ü Програміст - розробка програмного коду;

ü Тестувальник – складання тест-плану, тестових сценаріїв;

ü Менеджер проекту - планування й контроль виконання робіт.

Джерела вимог

§ Федеральне й муніципальне галузеве законодавство (конституція, закони, розпорядження)

§ Нормативне забезпечення організації (регламенти, положення, устави, накази)

§ Поточна організація діяльності об’єкта автоматизації

§ Моделі діяльності (діаграми бізнес-процесів)

§ Уявлення і очікування споживачів та користувачів системи

§ Журнали використання існуючих програмно-апаратних систем

§ Конкуруючі програмні продукти

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

Таблиця 1.1

Методи виявлення вимог

· Інтерв‘ю, опитування, анкетування

· Мозговий штурм, семінар

· Спостереження за виробничою діяльністью, «фотографування» робочого дня

· Аналіз нормативної документації

· Аналіз моделей діяльності

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

· Аналіз статистики використання попередніх версій системы

Перевірка вимог:

ü Всі вимоги мають піддаватися перевірці. Найбільш загальновідома методика перевірки — тести. Якщо перевірка тестами неможлива, тоді має використовуватися інший метод перевірки (аналіз, демонстрація, огляд чи огляд дизайну).

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

Нефункціональні вимоги, які не піддаються перевірці на програмному рівні, все ж мають бути збережені як документація намірів клієнта. Такі вимоги до продукту можуть бути перетворені у вимоги до процесу. Складні вимоги безпеки авіаційного програмного забезпечення можуть задовільнитися при використанні спеціального процесу розробки (наприклад, DO-178B).

Технологія Rational Unified Process (RUP).

У специфікаціях Rational Unified Process при класифікації вимог використовується модель FURPS+ з посиланням на стандарт IEEE Std 610.12.1990.

Акронім FURPS позначає наступні категорії вимог:

· Functionality (Функціональність)

· Usability (Застосовуваність)

· Reliability (Надійність)

· Performance (Продуктивність)

· Supportability (Експлуатаційна придатність).

Символ " +" розширяє FURPS-модель, додаючи до неї:

· обмеження проекту,

· вимоги виконання,

· вимоги до інтерфейсу,

· фізичні вимоги,

частина з яких вже була розглянута вище.

Окрім того, в специфікаціях RUP виділяються такі категорії вимог, як

· вимоги, що вказують на необхідність узгодженості з деякими юридичними й нормативними актами;

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

· вимоги к документування.

Організація роботи з вимогами на прикладі MSF

У MSF для позначення ролі учасників команди програмного проекту використовується поняття ролевих кластерів [4.9].

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

Шість ролевих кластерів моделі проектної групи – це:

Ø " Управління продуктом" (product management),

Ø " Управління програмою" (program management),

Ø " Розробка" (development),

Ø " Тестування" (test),

Ø " Задовільнення споживача" (user experience)

Ø " Управління випуском" (release management).

Вони відповідальні за різні області компетенції (functional areas) і пов‘язані з ними цілі й задачі.

MSF організований на базі комбінації каскадної та спіральної моделей. Окрема стадія роботи вміщує 5 фаз:

· Envisioning (розробка концепції),

· Planning (планування),

· Developing (розробка),

· Stabilizing (стабілізація),

· Deploying (впровадження).

У фазі розробки концепції робота з вимогами найбільш інтенсивна (табл. 1.2).

Таблиця 1.2.

Як видно з таблиці, всі 6 кластерів працюють зі своїми групами вимог.

Продовжується детальна робота з вимогами й на наступній фазі – фазі планування (табл. 1.3):

Таблиця 1.3.

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

Таблиця 1.4.

Таблиця 1.5.

Збір та формування вимог впливає на стадії розробки технічного завдання та глосарію:

Роль глосарію при аналізі вимог.

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

Завдання до лабораторної роботи.

Студент отримує завдання на проведення підготовчого етапу розробки автоматизованої інформаційної системи.

Варіанти завдань:

За варіантом завдання:

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

2) на основі п. 1 попередньо сформувати перелік вимог, та доповнити їх у відповідності з типом програмної системи,

3) виявити та запропонувати варіанти усунення протиріч у вимогах користувача (матриця аналізу вимог),

4) розподілити вимоги користувача по групах функціональних і нефункціональних вимог, для 3-х функціональних вимог побудувати HIPO-діаграми,

5) оцінити якість вимог за переліком критеріїв (табл. 1.1).

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