Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
ЛЕКЦІЯ №8
Тема: Аналіз проблемної області в процесі розробки ПЗ.
Роль аналізу в життєвому циклі розробки ПЗ
План лекції
Роль процесу управління вимогами при розробці складних програмних систем
На тепер розроблено безліч технологій ведення проектів по створенню програмних рішень. Незалежно від підходу, який використовується, на початковому етапі життєвого циклу будь-якого проекту проводиться обстеження проблемної області, формування і узгодження вимог до майбутньої системи. Розробка вимог є однією з ключових складових проектування автоматизованих систем. Етапу формування вимог передує етап обстеження об'єкту автоматизації. В процесі обстеження необхідно якнайповніше і однозначно визначити і зафіксувати потреби майбутніх користувачів. За результатами обстеження складаються вимоги до системи. На підставі виділених вимог визначається її функціональність.
Розробляти ПЗ можна за допомогою різних методологій. Як завжди, коли існує можливість вибору, неминуче виникає відповідальність за його результат. Невірно вибрана методологія може привести до перевитрати ресурсів, до затягування термінів виконання проекту і навіть до його повного провалу.
Виділяють ітеративний та каскадний підходи до розробки систем.
У чистому вигляді каскадний підхід означає виконання ряду фаз в певному порядку: аналіз вимог, проектування, виконання/інтеграція, тестування.
Перевагами каскадного підходу вважаються:
1) мінімальний об'єм переробок написаного коду;
2) можливість ретельно спроектувати архітектуру системи;
3) однократне тестування системи.
На відміну від каскадного, при ітеративному підході розробка розбивається на декілька ітерацій, і в ході кожної з них виконуються практично всі типи робіт, і в результаті створюється реально працююча система з функціональними можливостями, що постійно удосконалюються. Практично на всіх ітераціях виконується і аналіз вимог, і проектування, і тестування. Так, в найпершій ітерації, ще до виявлення всіх вимог, може початися розробка прототипу, на якому перевіряються основні архітектурні рішення. У процесі деталізації вимог на окремі підсистеми або компоненти на подальших ітераціях паралельно здійснюється проектування і кодування. Розроблені проекти підсистем і компоненти збираються в єдину систему (не чекаючи завершення розробки всіх підсистем), і починається їх системне тестування (тестування цих модулів повторюється в ході подальших ітерацій). В процесі розробки завжди з'являються додаткові вимоги замовника або змінюються сформульовані ними раніше. Також з'являються нові обмеження, пов'язані з прийнятими технічними рішеннями, або навпаки, нові можливості операційних систем, баз даних та іншого готового програмного забезпечення (далі – ПЗ).
На практиці багато груп застосовують модифікований каскадний підхід, розбиваючи проект на декілька частин, які називаються фазами або стадіями. Це допомагає спростити інтеграцію, дозволяє раніше почати тестування, відслідковувати стадії реалізації проекту. При такому підході код програм розбивається на частини і дозволяє заздалегідь випробувати найризикованіші та проблемні області, і на основі відгуків користувачів (зворотному зв'язку) змінювати план проекту.
Для проекту модернізації ДПА України було вибрано змішаний підхід з використанням стандартів MIL-STD-498 “Розробка та документування програмного забезпечення”, ДСТУ 3918-1999 (ISO/IEC 12207:1995) “Інформаційні технології. Процеси життєвого циклу програмного забезпечення”, ISO/IEC TR 15504 “Інформаційні технології. Оцінка процесів життєвого циклу програмного забезпечення”.
З метою створення в Україні стабільної податкової системи, яка сприятиме ефективному функціонуванню економіки та запровадженню прозорих процедур адміністрування податків, Державною податковою адміністрацією України у рамках довгострокового проекту “Програма модернізації державної податкової служби України” створюється інтегрована автоматизована інформаційна система (далі - ІАІС) як сукупність інформації, економіко-математичних методів та моделей, технічних, програмних, технологічних засобів та спеціалістів, що призначена для обробки податкової інформації та прийняття управлінських рішень
Розробка системи складається з таких етапів:
- аналіз системних вимог та розробка документів вищого рівня;
- аналіз та розробка деталізованих вимог до системи/підсистеми;
- проектування та кодування.
На тепер Проект модернізації знаходиться на завершальній стадії першого етапу.
Визначення вимог
Детальніше зупинимось на процесі визначення вимог.
Вимога — це будь-яка умова, якій повинна відповідати система, що розробляється, або програмний засіб. Такою вимогою може бути і можливість, якою система повинна володіти, і обмеження на її продуктивність або призначений для користувача інтерфейс, і нормативні вимоги, яким вона повинна задовольняти.
IEEE Standard Glossary of Software Engineering Terminology визначає вимоги як:
– умови або можливості, які необхідні користувачеві для вирішення проблем або досягнення цілей;
– умови або можливості, якими повинна володіти система або системні компоненти, щоб виконати контракт або задовольняти стандартам, специфікаціям або іншим формальним документам;
– документоване представлення умов або можливостей для п. 1 і 2.
Управління вимогами – необхідна умова успішної розробки програмного забезпечення. Правильно визначені вимоги є гарантією того, що система задовольнятиме вимогам зацікавлених в її розробці осіб.
Вимоги до ПЗ діляться на дві категорії:
– вимоги призначені для користувача (загальні, які описують систему на вищому рівні), що підлягають обговоренню і узгодженню із замовником;
– детальні вимоги, призначені для розробників.
Вимоги до ПЗ оформлюються у вигляді окремого документа. Кожна з вимог вищого рівня породжує одну або декілька детальних вимог, в якій заявлена функціональність деталізується до рівня класів, властивостей і методів. Між вимогами вищого рівня та детальними вимогами організовуються зв'язки. Цей підхід забезпечує послідовне накопичення і уточнення вимог на кожному етапі проекту, аналіз, формалізацію і подальший їх контроль при розробці програмного забезпечення, а також ефективне управління змінами вимог впродовж всього життєвого циклу проекту.
Якими ж характеристиками повинні володіти вимоги?
Правильні вимоги характеризуються:
повнотою – вимога повинна описувати всю функціональність, яку необхідно реалізувати;
коректністю – вимога повинна точно описувати бажану функціональність. Для дотримання коректності необхідний зв'язок з джерелами вимог, наприклад, з побажаннями користувачів. Вимоги до ПЗ, які конфліктують з “батьківськими” вимогами, не можна вважати коректними. Остаточну оцінку вимог на коректність повинні виконувати кінцеві користувачі;
виконуваністю – вимога повинна бути реалізована за даних умов і обмежень системи та операційного середовища. Взаємодія розробників з аналітиками дозволить розробникам реально оцінити можливість реалізації вимог з технічної точки зору. Розробка прототипу системи дозволить перевірити виконання вимоги;
необхідністю – вимога повинна відображати можливість, яка дійсно необхідна користувачам, або яка потрібна для відповідності зовнішнім системним вимогам або стандартам. Крім того, вимога повинна формулюватися особою, яка має повноваження на прийняття рішення;
пріоритетністю – вимоги повинні мати пріоритети для визначення послідовності їх реалізації;
однозначністю – вимоги повинні трактуватися однаково всіма користувачами. Документація повинна бути написана просто, коротко і точно, застосовуючи лексику, зрозумілу користувачам. Всі терміни необхідно заносити в словник;
можливістю бути перевіреними – необхідно розробити декілька тестів або застосувати інші прийоми для перевірки, щоб встановити, чи дійсно в продукті реалізована кожна вимога. Неповні, неузгоджені, нездійсненні або двозначні вимоги не перевіряються.
Процес управління вимогами здається нескладним лише на перший погляд. Серед головних причин складності можна виділити такі:
– велике число потенційних “зацікавлених осіб”, характерне для проектів розробки ПЗ, вимоги яких потрібно виявити і зафіксувати;
– різноманітність типів вимог, кожен з яких вимагає специфічного опису, своїх атрибутів і деталізації. Наприклад, побажання зацікавлених осіб, функціональні і не функціональні вимоги до системи і т.п.;
– необхідність створення і підтримки складної ієрархічної структури;
– необхідність трасувати вимоги, тобто виявляти і фіксувати взаємозв'язок між вимогами різних типів;
– вимоги міняються в ході виконання проекту. Причин для цього багато і більшість з них не зводяться до помилок розробників.
Часто в процесі розробки програмного продукту виникають ситуації, коли не виконуються роботи у встановлені терміни, що призводить до збільшення вартості проекту.
Причини можуть бути такі:
Усунення помилок у процесі визначення вимог на стадії супроводу готового ПЗ обходиться значно дорожче, ніж на стадії специфікації вимог. В результаті помилки у вимогах, що виявляються на пізніх фазах проекту, “з'їдають” 30 — 40% загальної вартості бюджету проекту.
З метою уникнення проблемних ситуацій під час розробки програмного забезпечення необхідно в процесі управління вимогами дотримуватися виконання таких дій:
1) визначення основної версії вимог (моментальний зріз вимог для конкретної версії продукту);
2) перегляд пропонованих змін до вимог і оцінка їх доцільності до прийняття;
3) включення схвалених змін до вимог в проект встановленим способом;
4) узгодження плану проекту з вимогами;
5) обговорення нових зобов'язань, основаних на оцінці впливу зміни до вимог;
6) відстеження окремих вимог до їх дизайну, вихідного коду і варіантів тестування;
7) відстеження статусу вимог та дії пов’язані з їх змінами впродовж всього проекту.
Крім того, процес управління вимогами включає такі кроки:
побудову і деталізацію моделі сценаріїв використання системи, що розробляється.
Отже, на тепер ми знаходимося на завершальній стадії першого етапу.
Детальніше зупинимось на процесі визначення вимог в рамках Проекту модернізації. З цією метою на основі Стратегічного плану, попередньої організаційної структури та шляхом вдосконалення існуючих бізнес-процесів було розроблено Концепцію операційної діяльності (далі - ConOps) – документ, що містить опис операційної та управлінської діяльності державної податкової служби України. Цей документ є результатом реінжинірингу процесів функціонування ДПС та основою для усіх подальших робіт зі створення інформаційної системи. На основі ConOps розроблено документи “Вимоги вищого рівня до системи”, де визначено вимоги до інформаційної системи, що розроблятиметься в межах Проекту.
Процес визначення вимог до сегмента складається з таких кроків:
1) огляд документів вищого рівня;
2) визначення та документування вимог вищого рівня;
3) аналіз вимог вищого рівня;
4) документування вимог вищого рівня до сегмента.
Кожна вимога містить посилання на конкретний крок, або процес/підпроцес ConOps.
З метою полегшення управління вимогами в Посібнику з операційного керівництва Проектом модернізації було задокументовано принципи ідентифікації, формулювання тексту вимог та формування трасувальних таблиць.
Ідентифікація вимог надає змогу відслідковувати (трасувати) вимоги з часу створення до перетворення в конкретний програмний код, посібники користувача, архітектуру системи тощо.
Код кожної вимоги формується таким чином:
<Код підсистеми (сегмента)/процесу>-<Тип вимоги>-<Номер вимоги>,
де <Код підсистеми (сегмента) /процесу > - скорочена назва підсистеми (сегмента) або процесу, для якого визначається вимога. Наприклад, HR01 – вимога до процесу 01 підсистеми людських ресурсів; номер процесу може бути опущений, якщо вимога стосується всієї підсистеми або сегмента.
<Тип вимоги> - одна літера, що ідентифікує тип вимоги (таблиця 1).
<Номер вимоги> - порядковий номер вимоги. Кожен тип вимог у рамках однієї підсистеми має власну нумерацію вимог.
|
Таблиця 1 - Коди типів вимог |
|
|
Тип вимоги |
Ідентифікатор вимоги |
|
Вимоги до режимів |
M |
|
Функціональні вимоги |
F |
|
Вимоги до зовнішніх інтерфейсів |
E |
|
Вимоги до внутрішніх інтерфейсів |
I |
|
Вимоги до даних |
D |
|
Вимоги до адаптації системи |
A |
|
Вимоги до безпеки |
G |
|
Вимоги до конфіденційності та захисту інформації |
S |
|
Вимоги до оточення |
V |
|
Вимоги до комп’ютерних ресурсів |
B |
|
Вимоги до якісних характеристик системи |
Q |
|
Обмеження щодо дизайну |
C |
|
Вимоги до персоналу |
H |
|
Вимоги до навчання |
T |
|
Вимоги до матеріально-технічного забезпечення |
L |
|
Інші вимоги |
O |
|
Вимоги до упаковки |
P |
Текст вимоги повинен складатися з таких частин, що слідують у такому порядку:
<Суб’єкт> <Дієслово, що описує дію> <Дієслово> <Об’єкт> <Оператор або кваліфікація>,
де <Суб'єкт> - об'єкт, до якого буде застосовано вимогу.
Фактично, у кожній вимозі повинна бути визначена відповідь на запитання: "Хто має виконувати роботу?".
<Дієслово, що описує дію> - Дієслово, що використовується для зазначення того, наскільки дана вимога є важливою та які варіанти щодо аналізу вимог має Виконавчий керівник Проекту.
<Дієслово (дієслівний вираз)> - описання того, що саме повинен робити суб’єкт.
<Об'єкт> - описує об’єкт, над яким виконується дія.
Трасувальні таблиці формуються для всіх вимог одночасно та використовуються для відстеження взаємозв’язку між ідентифікаторами вимог та ідентифікаторами посилання на джерело.
Формуються дві трасувальні таблиці:
трасувальна таблиця, за допомогою якої слід відстежувати взаємозв’язок між ідентифікаторами посилання на джерело, на підставі якого формується вимога, та ідентифікаторами вимог. Ідентифікатори посилання на джерело слід розміщувати у порядку зростання;
трасувальна таблиця, за допомогою якої слід відстежувати взаємозв’язок між ідентифікаторами вимог та ідентифікаторами посилання на джерело. Ідентифікатори вимог слід розміщувати у порядку зростання.
Після визначення вимог вищого рівня до всіх сегментів ConOps ДПС розробники формують документ “Вимоги вищого рівня до системи” та передають його до підрозділу забезпечення якості.
В процесі розробки цього документу виникло ряд проблем:
- організаційна. Важко погоджувати такий документ зі всіма зацікавленими сторонами. Крім того, Проектом передбачено створення в І фазі системи податкового блоку, системи управління документами, то в першу чергу було здійснено збір вимог, їх організація та документування для цих сегментів. Тому було прийнято рішення розробляти такий документ до кожного сегменту окремо. Це також полегшило супроводження документу, у разі внесення змін до одного з сегментів ConOps. Однак, стало важче вносити зміни в однотипні вимоги до різних сегментів, оскільки зв’язку між ними визначено не було;
- часова. В зв’язку з тим, що було проведена реструктуризація Проекту, було частково внесено зміни у всі сегменти ConOps, що в свою чергу викликало внесення змін до вимог вищого рівня. Було призупинено частину закупівель, внесено зміни в архітектурні рішення. Це привело до внесення змін у вимоги вищого рівня.
Якщо дотримуватись вибраної методології розробки систем, то, відповідно до обраних стандартів, наступним кроком має стати розробка документу з огляду вимог вищого рівня до системи, проведення формального огляду технічних рішень на нараді з огляду вимог до системи вищого рівня, за позитивними результатами якої приймається рішення про встановлення функціональної базової лінії.
Наступним етапом буде розробка разом з визначеними підрядниками детальних вимог. Для ефективного управління такою кількістю вимог необхідно передбачити використання відповідного засобу.
На цей час ринок засобів управління вимогами представлений такими продуктами: Rational RequisitePro, Telelogic DOORS (компанія IBM); Borland CaliberRM (компанія Borland); Sparx RaQuest (компанія Sparx System).
Це системи управління вимогами, що розроблені з метою підвищення якості розробки програмних продуктів. Призначені для покращення взаємодії між учасниками проекту, спрощення аналізу впливу та процесу передачі інформації у сфері управління змінами початкових вимог, автоматизують процес збору, трасування, аналізу та управління змінами вимог.
Отже, правильний підхід до управління вимогами – запорука успішності будь-якого проекту.
Питання для самоперевірки
Лавріщева К.М. Програмна інженерія – К., 2008. – 319с.
Липаев В.В. выбор и оценивание характеристик качества пограмных средств. Методы и стандарты. — М.: СИНТЕГ, 2001. — 228 с.
Якобсон А., Буч Г.и др. Унифицированный процесс разработки программного обеспечения. — СПб.: Питер, 2002. — 496 с