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

Страницы:
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 

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

Модель життєвого циклу MSF є певним поєднанням каскадної і спіральної моделей. У ній поєднується простота управління каскадноїмоделі із гнучкістю спіральної. Перебіг життєвого циклу проекту має вигляд послідовності ітерацій на витках спіралі (рис. 27).
Час

 

Рис. 27. Схема моделі життєвого циклу Microsoft Solution Framework

Основні концепції і принципи моделі:

1.     Єдине бачення проекту. Усі зацікавлені особи й учасники проекту повинні чітко уявляти кінцевий результат, тобто мати єдине бачення (Shared Vision) проекту. Іноді єдина мета проекту вступає в конфлікт з інтересами деяких його учасників або учасники проекту мають вигоду тільки від однієї підсистеми проекту, яка стосується їх безпосередньо. Наприклад, на останніх етапах проекту дуже важко пояснити комірникові, навіщо потрібно вводити номер накладної на відпущений товар, тому що він йому не потрібен. Проте він потрібен бухгалтерії. Конфлікт виникає, тому що комірники думають про автоматизацію лише завдань складу, а не підприємства в цілому. Тому в життєвому циклі MSF виділяється фаза для забезпечення єдиного бачення проекту.

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

Для ефективного досягнення компромісів у перебігу всього життєвого циклу проекту рекомендується на початкових етапах зафіксувати пріоритети чинників проекту (табл. 5):

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

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

третій чинник приймається, тобто буде прийнятий відповідно до перших двох.

4.  
3. Гнучкість до змін. MSF ґрунтується на принципі проектних умов, що змінюються. Для цього є ефективний інструментарій, що дозволяє адекватно та своєчасно реагувати на зміни вимог до проекту впродовж життєвого циклу.Урахування бізнес-пріоритетів. Необхідно зосередитися на тому результаті й вигоді, яку очікує отримати від програмного продукту його споживач. Якщо це проект, призначений для управління організацією, то ключовою точкою тут буде бізнес-віддача (business-value). Якщо це персональні програми, наприклад комп'ютерна гра, то ключовою точкою тут буде віддача у вигляді емоційного задоволення споживача.

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

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

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

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

У методології MSF рекомендується виконувати:

поточні збирання програмних компонент проекту за допомогою щоденних білдів (daily builds);

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

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

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

вибір пріоритетів створення версій проекту з урахуванням ризиків;

здійснення частих ітерацій розробки;

чітка регламентація процедур контролю змін у проекті;

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

Підхід, заснований на фазах і віхах в життєвому циклі MSF, виявляється в наступному.

Модель життєвого циклу MSF орієнтована на віхи (milestones) -ключові точки проекту, що характеризують досягнення якого-небуть істотного результату. Результат у кожній вісі може бути оцінений і проаналізований. У моделі передбачається наявність основних віх (завершення головних фаз моделі) і проміжних, таких, що відбивають внутрішні етапи головних фаз (рис. 29).
У рамках однієї ітерації життєвий цикл розбивається на п'ять фаз: вироблення концепції (загального бачення), планування, розробки, тестування (стабілізації), впровадження. Розглянемо детальніше ці фази.

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

Планування - Planning. Ця фаза включає планування і проектування продукту. На основі аналізу вимог розробляється проект і основні архітектурні рішення, функціональні специфікації системи, плани й кален-дарні графіки, середовище розробки, тестування та пілотної експлуатації. Фаза складається з трьох етапів: концептуального, логічного і фізичного проектування. На етапі концептуального проектування проект розглядається з погляду вимог користувачів і бізнесу. Закінчується концептуальне проектування визначенням набору сценаріїв використання системи. При логічному проектуванні проект розглядається з погляду розробників (проектної команди), рішення подається у вигляді набору сервісів. На етапі фізичного проектуванняпроект розглядається з погляду програмістів, уточнюються використовувані технології та інтерфейси.

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

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

Розгортання - Deploying. Виконується встановлення рішення і необхідних компонентів оточення, проводиться його стабілізація в промислових умовах і передача проекту в руки групи супроводу. Крім того, аналізується проект в цілому на предмет рівня вдоволеності замовника.

9.4.4. extreme Programming та інші гнучкі методології

eXtreme Programming. Методологія eXtreme Programming, розроблена Kent Beck, Ward Cunningham, Iron Jeffries сьогодні є найбільш відомою серед гнучких методологій. Екстремальне програмування як метод гнучкого проектування вперше було використано в ході роботи над проектом C3 (Chrysler Comprehensive Compensation System - система обліку виплат працівникам компанії Daimler Chrysler).

eXtreme Programming - технологія, що активно розвивається останнім часом, призначена для вирішення відносно невеликих завдань, відносно невеликими колективами професійних розробників в умовах жорсткого обмеження часу. Екстремальне програмування виникло як еволюційний метод розробки ПЗ "від низу до верху": від розробників і тестерів, виснажених важким процесом, документацією, метриками та іншим формалізмом. Вони не заперечували дисципліни, але не бажали марного дотримання формальних вимог і шукали нові швидкі та гнучкі підходи до розробки високоякісних програм. Іноді саме поняття гнучкої методологіїототожнюють із XP. Модель життєвого циклу XP є ітераційно-інкрементною моделлю швидкого створення (і модифікації) протопопів продукту, що задовольняють чергову вимогу (User Story). До основних фаз моделі можна віднести (рис. 30): "вкидання" архітектури - початковий етап проекту, на якому створюється бачення продукту, ухвалюються основні рішення з архітектури і використовуваних технологій. Результатом початкового етапу є метафора (metaphor) системи, яка в достатньо простому і зрозумілому команді вигляді повинна описувати основний механізм роботи системи;

історії використання (User Story) - етап збирання вимог, записуваних на спеціальних картках у вигляді сценаріїв виконання окремих функцій. Історії використання є вимогами для планування чергової версії і одночасної розробки приймальних тестів (acceptance tests) для її

перевірки;

планування версії (релізу), яке проводиться на зборах за участю замовника шляхом вибору User Story, які увійдуть до наступної версії. Одночасно ухвалюються рішення, пов'язані з реалізацією версії. Мета планування - отримання оцінок того, що і як можна зробити за 1 - 3 тижні створення наступної версії продукту;

розробка версії (ітерації), яка проводиться відповідно до плану і включає тільки ті функції, які були відібрані на етапі планування;

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

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

Після завершення циклу здійснюється перехід на наступну ітерацію розробки.

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

живе планування (planning game). Його завдання - якнайшвидше визначити обсяг робіт, які потрібно зробити до наступної версії ПЗ. Рішення ухвалюється, по-перше, на основі пріоритетів замовника (тобто його потреб: що потрібно йому від системи для успішнішого ведення свого бізнесу) і, по-друге, на основі технічних оцінок (тобто оцінок трудомісткості розробки, сумісності з рештою елементів системи та ін.);

 

 

 

 

 

 

 

"Вкидання" архітектури

 

 

 

 

Ненадійні оцінки


 

 

 

 

 

 

 

Випуск релізуРис. 30. Схема моделі ЖЦ XPчаста зміна версій (small releases). Найперша дієва версія повинна з'явитися якнайшвидше і тут же повинна почати використовуватися. Наступні версії готуються через досить короткі проміжки часу (від декількох годин за незначних змін в невеликій програмі, до місяця - двох у випадку серйозної переробки великої системи);

метафора (metaphor) системи. Метафора в достатньо простому і зрозумілому команді вигляді повинна описувати основний механізм роботи системи. Це поняття нагадує архітектуру, але повинне набагато простіше, всього у вигляді однієї - двох фраз, описувати основну суть ухвалених технічних рішень;

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

розробка  на  основі  тестування  (test-driven development).

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

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

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

колективне володіння кодом (collective ownership). У будь-який момент будь-який член команди може змінити будь-яку частину коду. Ніхто не повинен виділяти свою власну сферу відповідальності, вся команда в цілому відповідає за весь код;постійна інтеграція (continuous integration). Система збирається

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

40-годинний робочий тиждень. Наднормова робота розглядається як ознака великих проблем у проекті. Не допускається наднормова робота

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

включення замовника в команду (on-site customer). У складі команди розробників постійно знаходиться представник замовника, який доступний протягом усього робочого дня і здатний відповідати на всі питання про систему. Його обов'язком є достатньо оперативні відповіді на питання будь-якого типу, що стосуються функцій системи, її інтерфейсу, необхідної продуктивності, правильної роботи системи в складних ситуаціях, необхідності підтримувати зв'язок з іншими додатками та ін.;

Страницы:
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 комп'ютерні науки