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

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

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

До найбільш відомих моделей важкої розробки відноситься раціональний уніфікований процес (Rational Unified Process, RUP), методологія Microsoft Solution Framework (MSF) тощо.

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

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

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

До моделей ЖЦ ПЗ, що підтримують Agile-технології, належать метод екстремального програмування (eXtreme Programming, XP), методи Crystal Clear, Feature-Driven Development (розробка, керована функціями системи), DSDM (Dynamic Systems Development Method, метод розробки динамічних систем) та ін. Основні принципи гнучкої розробки ПЗ зафіксовані в Мані­фесті проекту Agile Developer, що з'явився у 2000 році.

Загальні риси гнучких методологій наступні:

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

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

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

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

9.4.2. Методологія RUP

Методологія Rational Unified Process (RUP) є розробкою компанії Rational. Ця компанія довгий час успішно займається створенням CASE-засобів, використовуваних на різних етапах життєвого циклу продукту від аналізу до тестування і документування. Технологія RUP універсальна, масштабована і налаштовується на застосування в конкретних умовах. Модель життєвого циклу RUP є досить складною ітеративно-інкремент-ною моделлю, що детально відпрацьована, з елементами каскадної моделі.

Основними характеристиками RUP є наступні:

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

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

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

Основними принципами RUP є:

ітераційна розробка;

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

орієнтація на архітектуру.

Слід розглянути ці принципи детальніше.

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

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

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

RUP створювався за методикою, використовуваною в процесі проек­тування ПЗ. Зокрема, моделювання проводилося за допомогою Software Process Engineering Metamodel (SPEM) - стандарту моделювання процесів, заснованого на Unified Modeling Language (UML). У моделі ЖЦ RUP є два виміри (рис. 25): динамічне і статичне.

Дисципліни (процеси)

Бізнес-моделювання Визначення вимог Аналіз і проектування

Реалізація

Тестування Розгортання

Управління конфігураціями і змінами

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

Динамічна структура RUP складається з чотирьох фаз:

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

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

фаза побудови (Construction). Основна мета цієї фази -детальне прояснення вимог і розробка системи, що задовольняє їх, на основі спроектованої раніше архітектури;

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

Фази можуть підрозділятися на ітерації. Перехід з фази на фазу можливий лише після виконання завдань фази і є контрольною точкою -віхою (milestone) - процесу.

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

До основних дисциплін належать:

моделювання предметної області (бізнес-моделювання, Business Modeling). Цілі цієї діяльності - зрозуміти бізнес-контекст, в якому повинна буде працювати система (і переконатися, що всі зацікавлені особи розуміють його однаково), зрозуміти можливі проблеми, оцінити їх можливі розв'язання і наслідки для бізнесу організації, в якій працюватиме система;

визначення вимог (Requirements). Цілі - зрозуміти, що повинна робити система, визначити межі системи і основу для планування проекту і оцінок ресурсовитрат у ньому;

аналіз і проектування (Analysis and Design). Розробка архітектури системи на основі ключових вимог, створення проектної моделі, наведеної у вигляді діаграм UML, що описують продукт з різних точок зору;

реалізація (Implementation). Розробка початкового коду, компонент системи, тестування та інтеграція компонент;

тестування (Test). Загальна оцінка дефектів продукту, його якості в цілому, оцінка ступеня відповідності початковим вимогам;

розгортання (Deployment). Цілі - розгорнути систему в її робочому оточенні і оцінити її працездатність.

До допоміжних дисциплін відносяться:

управління конфігураціями і змінами (Configuration and Change Management). Визначення елементів, що підлягають зберіганню і правилпобудови з них узгоджених конфігурацій, підтримка цілісності поточного стану системи, перевірка узгодженості змін, що вносяться;

управління проектом (Project Management). Включає планування, управління персоналом, забезпечення зв'язків з іншими зацікавленими особами, управління ризиками, відстеження поточного стану проекту;

середовище проекту (Environment). Настроювання процесу під конкретний проект, вибір і зміна технологій і інструментів, використовуваних у проекті.

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

Для забезпечення інструментальної підтримки всіх процесів життєвого циклу розробки і супроводу ПЗ RUP пропонує спеціалізовані інструментальні засоби IBM Rational (рис. 26).

RequisitePro - дозволяє створювати і оновлювати керовані ним вимоги безпосередньо в програмі або за допомогою редактора Microsoft Word. Для зміни вимог досить відредагувати вміст документа, при цьому сам засіб допоможе відновити, проаналізувати й об'єднати необхідні вимоги.

Software Modeler - засіб, що замінив компоненту Rational Rose® XDE, яка раніше використовувалася. Побудоване на платформі Eclipse, вона успішно використовувалося в сімействі продуктів IBM WebSphere® як основа для інтегрованого середовища розробки (IDE) WebSphere Stu­dio Application Developer. Rational Software Modeler надає користувачу інтерфейс для моделювання додатка до початку написання програмного

коду.

Application Developer - надає середовище IDE для перетворення моделей в програмний код і фінальні додатки. Rational Application Develo­per також забезпечує користувачів інтегрованим середовищем для тестування готового додатка.
ClearCase - забезпечує управління конфігурацією бази коду і моделей. WebSphere Studio Application Developer і Rational Rose XDE, взаємодіючи з Rational ClearCase, здатні забезпечити всю команду розробників механізмами управління всіма аспектами процесу розробки.

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

PurifyPlus - забезпечує поточний аналіз додатка, що дозволяє простежити, як він використовує ресурси пам'яті. "Витік" пам'яті та інші проблеми такого роду є одним з найпоширеніших дефектів в додатках, за винятком друкарських помилок і помилок в програмному коді, які повинні усуватися за допомогою тестування і спеціальних методик, використовуваних під час застосування інструментальних засобів Ra­tional. Інтеграція цього інструменту з середовищем WebSphere Studio Application Developer забезпечує користувачів інформацією про елементи додатка, що викликають ті або інші проблеми.TestManager - надає єдиний інтерфейс для тестування набору параметрів додатка, дозволяючи проводити це тестування в автоматичному режимі, що особливо важливо, якщо розробка виконується на різних платформах.

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

 

9.4.3. Методологія Microsoft Solution Framework

Методологія Microsoft Solution Framework (MSF) є розробкою компанії Microsoft, призначеної для вирішення широкого кола завдань. Технологія масштабована, тобто налаштовується на вирішення завдань будь-якої складності колективом будь-якої чисельності. Методологія MSF схожа з методологією RUP: модель ЖЦ ІС включає фази та ітерації розробки, заснована на об'єктно-орієнтованому моделюванні. Однак модель MSF більшою мірою, ніж RUP, орієнтована на розробку бізнес-додатків, що відбите в її основних концепціях.

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