І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 13

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

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

відкритий робочий простір (open workspace). Команда розміщується в одному, досить просторому приміщенні, для спрощення комунікації і можливості проведення колективних обговорень під час планування й ухвалення важливих технічних рішень;

зміна правил за потреби (just rules). Кожен член команди повинен прийняти перераховані правила, але в разі виникнення необхідності команда може змінити їх, якщо всі її члени прийшли до згоди з приводу цієї зміни.

Сфера застосування ХР: використовувані в XP техніки розраховані на використання в рамках невеликих команд (не більше 10 програмістів) і, як наслідок, невеликих проектів. Більший розмір команди руйнує необхідну для успіху простоту комунікації і робить неможливим застосування багатьох перерахованих прийомів.

Перевагами XP є:

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

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

нездійсненність у такому стилі досить великих і складних проектів;

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

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

Прикладом зазначених переваг і недоліків ХР може слугувати проект C3, який був розпочатий у січні 1995 року. Система створювалася мовою Smalltalk компанією, яка не впоралася із завданням. Якість програмного коду була настільки низькою, що Кент, якого запросила компанія, порадив почати все з початку. Проект почався з нуля тепер вже під його керівництвом і з березня 1996 року проходив з використанням цього методу. До сьогодні проект вийшов за межі бюджету і планів поетапної реалізації функцій. Команда розробників була скорочена. Протягом приблизно півроку після цього проект розвивався досить успішно. У серпні 1998 року з'явився прототип, який міг обслуговувати близько 10 000 службовців. Спочатку передбачалося, що проект завершиться в середині 1999 року і використовуватиметься для управління виплатами 87 000 службовцям компанії. Але він був зупинений в лютому 2000 року після 4-х років роботи з XP у зв'язку з повним недотриманням часових меж і бюджету. Створене ПЗ жодного разу не використовувалося для роботи з даними для більш ніж 10 000 службовців, хоча було показано, що воно впорається із даними 30 000 працівників компанії. Включений в команду проекту замовник звільнився через декілька місяців роботи за правилами методу ХР, не витримавши навантаження. Проект так і не отримав адекватної заміни до свого кінця.

Crystal Clear. Crystal - сімейство методологій, що визначають необхідний ступінь формалізації процесу розробки залежно від кількості учасників і критичності завдань. Ці методології розроблені Алістером Кок-берном (Alistair Cockburn) і називаються сімейством, оскільки автор переконаний, що різним проектам потрібні різні методології. Він увів наступ-ну градацію проектів: на одній осі відкладається кількість зайнятих у проекті людей, на іншій - критичність помилок. Кожна з методологій "сімейства" призначена для певної клітинки сітки. Таким чином, проект, в якому зайнято 40 осіб і в якому компанія може дозволити собі втратити певну суму, працюватиме за іншою методологією, ніж проект для 6 розробників, від якого залежить існування компанії.Методологія поступається XP за продуктивністю, зате максимально проста у використанні. Вимагає мінімальних зусиль для впровадження, оскільки орієнтована на людські звички. Вважається, що вона описує той природний порядок розробки ПЗ, який встановлюється в досить кваліфікованих колективах, якщо в них не займаються цілеспрямованим впровадженням іншої методології.

Основні характеристики методології:

ітеративна інкрементна розробка;

автоматичне регресійне тестування;

користувачі залучаються до активної участі в проекті;

склад документації визначається учасниками проекту;

як правило, використовуються засоби контролю версій коду.

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

Feature Driven Development. Методологія Feature Driven Develop­ment (функціонально-орієнтована розробка), яка має скорочену назву FDD, була розроблена Джефом Де Люка (Jeff De Luca) і визнаним авторитетом у галузі об'єктно-орієнтованих технологій Пітером Коадом (Peter Coad). Як і в решті адаптивних методологій, у ній робиться основний наголос на коротких ітераціях, кожна з яких слугує для опрацьовування певної частини функціональності системи. Згідно з FDD, одна ітерація триває два тижні.

Насправді використовуване в FDD поняття функції або властивості системи (feature) достатньо близьке до поняття прецеденту використання, використовуваного в RUP. Чи не найістотніша відмінність - це додаткове обмеження: "кожна функція повинна допускати реалізацію не більш ніж за два тижні". Тобто якщо сценарій використання досить малий, його можна вважати функцією. Якщо ж великий, то його треба розбити на декілька відносно незалежних функцій.

FDD включає п'ять процесів:

розробку загальної моделі;

складання списку необхідних функцій системи;

планування роботи над кожною функцією;

проектування функції;конструювання функції.

Перші три з них відносяться до початку проекту. Останні два -необхідно виконувати під час кожної ітерації. При цьому кожен процес розбивається на завдання і має критерії верифікації.

Розробники в FDD поділяються на "class owners" (власники класів) і "chief programmers" (старші програмісти). Старші програмісти залучають власників задіяних класів до роботи над черговою властивістю. Для порівняння, в XP немає персонально відповідальних за класи або методи. До роботи над будь-яким класом може залучатися будь-який із учасників розробки.

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

Dynamic System Development Method (DSDM) з'явився у Великобританії в 1994. Його заснував консорціум із 17 англійських компаній, які хотіли працювати з використанням RAD-технології і принципів ітеративної розробки. Зараз кількість його членів перевищує тисячу, причому багато хто з них перебуває за межами країни. Те, що DSDM розробляється цілим консорціумом, помітно відрізняє його від інших гнучких методологій. Ціла організація займається розробкою посібників з цієї методології, організацією навчальних курсів, програм акредитації тощо.

Проектування методологією DSDM починається з:

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

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

Далі процес ділиться на три взаємопов'язаних цикли:

цикл функціональної моделі відповідає за створення аналітичної

документації та прототипів;

цикл проектування і конструювання - за приведення системи в

робочий стан;

цикл реалізації забезпечує розгортання програмної системи. Базові принципи, на яких будується DSDM, - це:активна взаємодія з користувачами; часті випуски версій;

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

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

9.5. Аналіз вимог до програмного забезпечення

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


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

Усунення помилок у вимогах на стадії супроводу готового ПЗ коштує в декілька разів дорожче, ніж на стадії специфікації вимог (рис. 31). На виправлення помилок у вимогах, які виявляються на пізніх фазах проекту, витрачається 30 - 40% від загальної вартості бюджету проекту. Тому виявлення, аналіз та управління вимогами до програмного проекту є найважливішими завданнями проектної діяльності.

Програмна вимога (Software Requirement) - це можливість, яку будь-хто очікує від даного ПЗ. У стандарті IEEE Standard Glossary of Software Engineering Terminology, 1990 вимога визначається таким чином:

1.    Умова або можливість, необхідна користувачеві для вирішення завдань або досягнення мети.

2.    Умова або можливість, яку повинна мати система або її компонент, відповідні договору, стандарту, специфікації або іншому офіційному документу.

3.    Документоване подання умови або можливості, перераховані в попередніх пунктах.

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

організований підхід до управління вимогами;

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

об'єктивну оцінку реалізованого функціонала і отриманої продуктивності;

ранній прогноз різних невідповідностей і розбіжностей;

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

Вимоги, що висуваються до ПЗ, можна класифікувати наступним чином:

усвідомлені (відомі, висловлені) та неусвідомлені (забуті, невисловлені);функціональні (властивості продукту), які визначають, що повинен виконувати програмний продукт, і нефункціональні, такі, що мають відношення до якості самого ПЗ (до зовнішнього інтерфейсу, до продуктивності, до якості ПЗ, пов'язані з розробкою проекту);

замовника (С-вимоги) і розробника (D-вимоги);

бізнес-вимоги (вищий рівень), вимоги користувача (середній рівень), вимоги розробника (нижчий рівень).

Можна виділити три рівні вимог (рис. 32).

На верхньому рівні знаходяться бізнес-вимоги (business require­ments). Бізнес-вимоги відбивають високорівневі цілі організації. Їх формулюють топ-менеджери. Ці вимоги формулюються в документах "Бачення проекту" (Vision), "Глосарій проекту" (Glossary) та "Бізнес-правила" (Business Rules).

На середньому рівні знаходяться вимоги користувачів (user re­quirements). Вони описують цілі і завдання, які дозволить вирішити система користувачам. Ці вимоги описуються за допомогою документів: "Варіанти використання" (Use Case) та "Додаткові специфікації" (Supple­mentary Specifications).

На нижньому рівні знаходяться системні вимоги, які формулюються за допомогою функціональних вимог і нефункціональних вимог і містяться в документі Специфікації вимог до ПЗ (SRS).

Складність аналізу вимог обумовлена наступними основними при­чинами, такими як:

велика кількість осіб, зацікавлених у розроблюваному ПЗ, вимоги яких потрібно виявити і зафіксувати;

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

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

необхідність трасування вимог, тобто виявлення взаємозв'язку між вимогами різних типів;

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

супроводжуватися підтверджувальними тестами;

передбачатися проектом;

бути врахованими програмним кодом;

бути протестованими окремо;

бути протестованими разом з іншими вимогами;

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

Процес створення вимог згідно із SWEBOK включає наступні складові:

Requirements Elicitation (встановлення вимог);

Requirements Analysis(аналіз вимог);

Requirements Specification (специфікація вимог);

Requirements Validation (перевірка вимог).

Для роботи з вимогами і документами, в яких вони відбиваються, відстеження їх змін фірмою IBM був розроблений програмний продукт Rational RequisitePro.

У процесі документування вимог в RequisitePro розглядаються наступні їх характеристики:

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

І О Ушакова - Соціальні мережі як засіб впливу на взаємовідносини з клієнтами

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки