СУЧАСНІ ІНФОРМАЦІЙНІ ТЕХНОЛОГІЇ / 3.Програмне забезпечення
К. т. н. Радельчук Г. І.
Хмельницький національний
університет, Україна
ПОРІВНЯЛЬНИЙ АНАЛІЗ СУЧАСНИХ
МЕТОДОЛОГІЙ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Розробка програмного
забезпечення (ПЗ) – це вид діяльності та процес, спрямований на створення та
підтримку працездатності, якості та надійності ПЗ, використовуючи технології, методологію та практики з інформатики, керування
проектами, математики, інженерії та інших
областей знання. Як і інші традиційні інженерні дисципліни, розробка ПЗ має справу з
проблемами якості, вартості та надійності. Деякі програми містять мільйони
рядків вихідного коду, які, як очікується, повинні правильно виконуватися в
умовах, що змінюються. Складність ПЗ порівнянна зі складністю найбільш складних
сучасних машин (таких, наприклад, як літаки).
У зв’язку з цим,
незважаючи на розвиток програмної інженерії, частка провальних
програмних проектів (ПП) все ще залишається високою. Серед усіх можливих причин
провалів ПП найбільш суттєвими є наступні [1]: неконкретне та неповне
формулювання вимог до ПЗ; недостатня зацікавленість користувача у роботі над
проектом; відсутність необхідних ресурсів; незадовільне планування та безграмотне
управління ПП; часта зміна вимог та специфікацій; новизна та недосконалість
використовуваної технології; недостатня підтримка вищим керівництвом; недостатньо
висока кваліфікація розробників, відсутність у них необхідного досвіду.
“Важкі” методології розробки
ПЗ, що базуються на класичних моделях життєвого циклу ПЗ (водоспадна та
спіральна), не можуть забезпечити повноцінного функціонування програмного
проекту, в ході якого потрібно швидко реагувати на зміни вимог і проектних рішень.
Безліч
обмежень у “важких” методологіях
привели до того, що компанії-розробники багато в чому стали
схожими на гігантські бюрократичні системи. Наявність великої кількості
формальних процедур і правил суттєво звужує свободу
дій кожного програміста, перетворює його у гвинтик у величезній і
неповороткій машині. Кинути виклик подібним перевантаженим формальностями
підходам і покликані сучасні методології розробки ПЗ.
Аналіз
останніх досліджень показав, що на сьогоднішній день існує достатня кількість розвинених методологій
створення ПЗ, які добре стандартизовані та практично опробувані. Серед них
можна виділити наступні:
-
швидка розробка додатків Rapid Application Development (RAD);
-
Rational Unified Process (RUP);
-
Microsoft Solutions Framework (MSF);
-
гнучкі (Agile) методології.
Швидка розробка додатків RAD – концепція створення ПЗ, що приділяє
особливу увагу швидкості й зручності програмування, створенню технологічного
процесу, який дозволяє програмістові максимально швидко розробляти ПЗ. RAD розвинута в рамках спіральної моделі життєвого
циклу (ЖЦ) ПЗ. Метод грунтується на послідовності ітерацій еволюційної системи (або
прототипів), критичний аналіз яких обговорюється із замовником. У процесі
такого аналізу формуються вимоги до продукту. Розроблення кожного інтегрованого
продукту чітко обмежується певним періодом часу, що, як правило, становить 60
днів [2]. На відміну від традиційного підходу, при якому
використовувалися специфічні засоби створення прототипів, які не призначені для
побудови реальних програм (прототипи
викидалися після того, як була виконана задача усунення неясностей у проекті), в RAD кожний
прототип розвивається в частину майбутньої системи.
У RAD-підході виділяються такі фази: фаза аналізу і планування
вимог; фаза проектування; фаза побудови; фаза впровадження.
-
інструментарій має бути націлений на мінімізацію
часу розробки;
-
створення прототипу для уточнення
вимог замовника;
-
циклічність розробки (кожна нова версія продукту грунтується на оцінці
результату роботи попередньої версії замовником);
-
мінімізація часу розробки версії за
рахунок перенесення вже готових модулів і додавання функціональності в нову
версію;
-
команда розробників повинна тісно
співпрацювати, кожний учасник повинен бути готовий
виконувати декілька обов’язків;
-
управління проектом повинне
мінімізувати тривалість циклу розробки.
Модель RAD має такі переваги:
- час циклу розроблення для всього проекту
можна скоротити завдяки використанню потужних інструментальних засобів;
- потрібна менша кількість фахівців,
оскільки розроблення системи виконують зусиллями команди, обізнаної у
предметній галузі;
- зменшуються витрати на розроблення завдяки
скороченому часу ЖЦ і вдосконаленій технології, а також меншій кількості розробників;
- зменшуються витрати та ризики, пов’язані з дотриманням графіка;
- забезпечується ефективне використання
засобів, які є в наявності;
- до складу кожного часового блоку входить аналіз,
проектування та впровадження;
- основну увагу перенесено з документації на
код, при цьому діє принцип “одержуєте те, що бачите”;
- існує можливість зробити швидкий
початковий огляд продукту;
- залучення замовника на постійній основі
мінімізує ризик його невдоволеності розробленим продуктом; окрім того, це
гарантує, що система буде відповідати комерційним потребам, а сам програмний
продукт буде надійним в експлуатації.
Модель RAD має такі недоліки:
- якщо користувачі не можуть постійно брати
участь у процесі розроблення протягом усього життєвого циклу, це може негативно
позначитися на кінцевому продукті;
- під час застосування цієї моделі необхідна
достатня кількість висококваліфікованих розробників, що вміють користуватися
обраними інструментальними засобами для прискорення часу розроблення;
- виникає потреба в
системі, яка може бути змодельована коректним чином;
- використання моделі може виявитися
невдалим у випадку, якщо відсутні придатні для повторного використання
компоненти;
- для реалізації моделі потрібні розробники та
замовники, готові до швидкого виконання дій із жорсткими часовими обмеженнями;
- команди, які розробляють комерційні
проекти за допомогою моделі RAD, можуть “затягувати” розроблення
програмного продукту настільки, що його своєчасне постачання кінцевому
користувачеві буде під загрозою;
- існує ризик, що роботу над проектом не
буде завершено; у зв’язку із
цим менеджер проекту повинен співробітничати як з командою розробників, так і з
замовником, що дозволить уникнути появи замкнутого циклу.
RAD-підхід доцільно застосовувати, коли чітко визначені пріоритетні напрями
розробки проекту: необхідне виконання проекту в стислі терміни; нечітко
визначені вимоги до ПЗ; проект виконується в умовах обмеженості бюджету;
головним чинником є інтерфейс користувача; можливе розбиття проекту на
функціональні компоненти; низька обчислювальна складність ПЗ.
Проте, методологія
RAD не може претендувати на універсальність; вона підходить, насамперед, для відносно невеликих проектів, які
розробляються для конкретного замовника. У проектах, де вимоги до програмного продукту
чітко визначені і не повинні змінюватись, залучення замовника до процесу
розробки не потрібне і ефективнішою може бути ієрархічна розробка (каскадний
метод). Те ж саме стосується проектів ПЗ, складність яких визначається
необхідністю реалізації складних алгоритмів, а роль інтерфейсу користувача є
незначною. Не підходять для розробки за методологією RAD додатки, від яких залежить безпека людей (наприклад,
керування літаком або атомною електростанцією), оскільки інтерактивний підхід
припускає, що перші декілька версій не будуть повністю працездатні, що в даному
випадку виключається.
Методологія RUP описує абстрактний загальний
процес, на основі якого організація або проектна команда повинні створити
спеціалізований процес, орієнтований на її потреби. RUP включає інтегрований пакет методик, технологій та
програмних засобів. Сутність роботи в рамках RUP – це створення й супровід моделей на базі Unified
Modeling Language (UML).
В основі RUP лежать наступні
принципи:
- рання ідентифікація і
безперервне усунення основних ризиків;
- концентрація на виконанні
вимог замовника до виконуваної програми (аналіз і побудова моделі варіантів
використання);
- очікування змін у
вимогах, проектних рішеннях і реалізації;
- компонентна архітектура,
що реалізовується і тестується на ранніх стадіях проекту;
- постійне забезпечення
якості на всіх етапах розробки ПЗ;
- робота над ПЗ у
згуртованій команді, ключова роль в якій належить архітекторам.
Згідно методології RUP загальний ЖЦ системи
складається з декількох циклів-ітерацій, кожний з яких містить чотири фази:
початок (Inception); розробка (Elaboration); побудова (Construction); впровадження (Transition). Для кожної фази методологія
задає склад і послідовність робіт, а також правила їхнього виконання; розподіл
повноважень серед учасників проекту (ролі); склад і шаблони формованих
проміжних і підсумкових документів; порядок контролю та перевірки якості. Кожна фаза може бути розбита на етапи (ітерації), у
результаті яких випускається версія для внутрішнього або
зовнішнього використання. Проходження крізь ці чотири фази називається циклом розробки; кожний цикл завершується генерацією чергової версії системи. Якщо після цього робота над проектом
не припиняється, то отриманий продукт продовжує розвиватися і знову пройде ті ж фази [3].
В кінці кожної ітерації
(яка в ідеалі продовжується від 2 до 6 тижнів) проектна команда повинна досягти
запланованих на дану ітерацію цілей, створити або доопрацювати проектні артефакти
і отримати проміжну, але функціональну версію кінцевого продукту. Ітеративна
розробка дозволяє швидко реагувати на зміну вимог, виявляти та усувати ризики
на ранніх стадіях проекту, а також ефективно контролювати якість створюваного
продукту.
Процес RUP – процес, керований на основі варіантів використання. Це
означає, що як метод опису функціональних вимог до системи, а також як природна
одиниця для подальшого планування і оцінки виконання робіт, застосовуються
сценарії використання. Сценарії використання дозволяють легко виявляти реальні
потреби майбутніх користувачів ПЗ і відстежувати повноту опису їх вимог. Крім
того, використання завершених сценаріїв, як одиниць виміру прогресу, допомагає
уникнути неадекватної оцінки ступеня виконання проекту виконавцем.
Методологія RUP має наступні переваги.
RUP дозволяє компанії-розробникові налаштовувати весь
процес розробки ПЗ. На відміну від більшості сучасних методологій або вимог до
процесу розробки, орієнтованих на строго визначений рівень формалізації процесу
(як правило, або дуже високий, або, навпаки, дуже низький), RUP дозволяє отримати саме
той рівень формалізації, який необхідний в проекті.
При розробці ПЗ для
державних підприємств і у низці інших ситуацій компанії-розробникові доводиться
виконувати формальні вимоги вітчизняних і міжнародних стандартів (ГОСТи серій
19 і 34, ISO/IEC 12207:1995 та ін.). В цьому випадку можна нанаштувати RUP на досить високий рівень
формалізації процесу. Більше того, при використанні інструментальних засобів IBM Rational нескладно розробити шаблони
документів, які створюватимуться автоматично за допомогою IBM Rational SODA на основі стандартних
моделей та артефактів і відповідати вимогам стандартів.
Використання RUP з
досить високим рівнем формалізації процесу також може допомогти
компанії-розробникові виконувати вимоги сертифікації CMM (Capability Maturity Model). Оскільки RUP є добре документованим
процесом, впровадження RUP допоможе компанії досягти рівнів 2 і 3 СММ. У ще більшій
мірі RUP може допомогти при
впровадженні CMMI,
оскільки CMMI
більшою мірою відповідає сучасному ітераційному підходу до розробки ПЗ.
З іншого боку, при
використанні RUP в
невеликих колективах для розробки не критичного ПЗ можна вибрати досить низький
рівень формалізації, який не гальмуватиме розробку необхідністю формування і
ретельного оформлення багатьох артефактів, що не роблять реального впливу на
якість проектування та реалізації ПЗ.
До недоліків RUP можна віднести те, що широкі можливості налаштування не
роблять впровадження RUP простим. Ефективному
використанню RUP перешкоджає дуже
багато складнощів. Часто послідовність фаз
“Початок–Розробка–Побудова–Впровадження” помилково інтерпретують як фази
“Аналіз–Дизайн–Реалізація–Впровадження” з моделі водоcпаду, і це практично
зводить нанівець всі переваги RUP. Для значної кількості
людей виявляється незвичною концепція документування вимог у вигляді варіантів
використання UML.
В результаті специфікація вимог, створена проектною командою, може виявитися
абсолютно невиразним документом, який ніхто не читатиме. Окрім того, для
повноцінного впровадження RUP компанія-розробник
повинна витратити значні кошти на навчання співробітників. При цьому спроба
обійтися своїми силами швидше за все буде приречена на невдачу – необхідно
шукати фахівця з відповідним досвідом або залучати консультантів.
Методологія RUP підходить, насамперед, для масштабних і довгострокових проектів.
Методологія MSF – це набір рекомендованих
концепцій і моделей, які дозволяють розробляти і впроваджувати ПЗ на основі
технологій і інструментальних засобів Microsoft. MSF є однією з інтерпретацій спіральної моделі розробки
додатків і базується на практичних результатах організації розподілених
обчислень і застосування технологій “клієнт-сервер” компанії Microsoft, її партнерів і
замовників [4].
Головною метою методології MSF, як і будь-якої іншої, є створення робочого додатку
вчасно і в рамках встановленого бюджету. MSF пропонує практики планування,
розробки і впровадження інформаційних технологій, що добре себе
зарекомендували. В той же час MSF не є простим набором інструкцій, яким належить слідувати
беззастережно, – цей процес є досить гнучким та розширюваним.
MSF є
добре збалансованим набором методик організації процесу розробки ПЗ, який може
бути адаптований під потреби практично будь-якого колективу розробників. MSF містить не лише рекомендації загального характеру, але і
пропонує модель колективу розробників, визначає взаємини всередині колективу,
гнучку модель проектного планування, заснованого на управлінні проектними
групами, а також набір методик для оцінки ризиків.
MSF складається з двох моделей і трьох дисциплін.
а)
моделі: модель проектної групи; модель процесів;
б)
дисципліни: дисципліна управління проектами; дисципліна управління ризиками; дисципліна
управління підготовкою.
Модель проектної групи MSF описує новаторський підхід
Microsoft до організації персоналу, що працює над проектом, і його діяльності з
метою максимізації успішності проекту. Ця модель визначає ролеві кластери, їх
області компетенції і зони відповідальності, а також рекомендації членам
проектної групи, що дозволяють їм успішно здійснити свою місію по втіленню
проекту в життя. Відповідно до моделі MSF проектні групи
будуються як невеликі багатопрофільні команди, члени яких розподіляють між
собою відповідальність і доповнюють області компетенцій один одного. Це дає
можливість чітко сфокусувати увагу на потребах проекту. Проектну групу об’єднує
єдине бачення проекту, прагнення до втілення його в життя, високі вимоги до
якості роботи і бажання самоудосконалюватися.
До проектної групи входять такі ролеві кластери:
- управління програмою (Program Management);
- розробка (Development);
- тестування (Testing);
- управління випуском (Logictics Management);
- навчання користувача (User Education);
- управління продуктом (Product Management).
Вони відповідальні за
різні області компетенції і пов’язані з ними цілі та задачі, але за успіх
проекту відповідальна вся команда. Звісно, модель проектної групи MSF не забезпечує успіху
сама по собі. Є багато інших чинників, які визначають успіх або невдачу
проекту, але структура проектної групи, безумовно, вносить суттєвий вклад.
Процес розробки за MSF є ітеративним, в якому кожна ітерація включає наступні основні фази:
1) Вироблення концепції (Envisioning);
2) Планування (Planning);
3) Розробка (Developing);
4) Стабілізація (Stabilizing);
5) Впровадження (Deploying).
Кожна фаза циклу
закінчується головною віхою (контрольною точкою), кожна з яких має свою назву: “концепція продукту затверджена”, “плани продукту затверджені”, “розробка
завершена”, “готовність
рішення затверджена”, “впровадження
завершене”.
Віха є точкою синхронізації досягнутих результатів і очікувань замовника, а
також аналізу проектного середовища.
MSF рекомендує починати розробку ПЗ з побудови, тестування і впровадження його
базової функціональності. Далі до рішення додаються нові можливості. Не
дивлячись на те, що для малих проектів може бути достатнім випуск однієї
версії, рекомендується створення для одного рішення низки версій. Із створенням
нових версій еволюціонує функціональність рішення.
Ітеративний підхід до процесу розробки вимагає використання гнучкого
способу ведення документації. “Живі” документи (Living Documents) повинні змінюватися по мірі еволюції проекту разом із змінами вимог до
кінцевого продукту.
В рамках MSF пропонується низка шаблонів
стандартних документів, які є артефактами кожної стадії розробки продукту і
можуть бути використані для планування і контролю процесу розробки.
Таким чином, методологія MSF розрахована на створення
готового продукту, що відповідає бізнес-інтересам замовника, чіткий розподіл
відповідальності між учасниками проекту, управління ризиками та точну
розстановку пріоритетів. Це робить
методологію МSF оптимальною для великих проектів, що вимагають дотримання
балансу між ресурсами, часом розробки і можливостями проектної команди.
Враховуючи успішність
корпорації Microsoft в галузі розробки ПЗ, її методики, практики і досвід в області
проектування, розробки, впровадження і супроводу IT-проектів заслуговують на увагу
програмістів. Методологію MSF можна використовувати як ефективний інструмент,
підходячи до нього з творчою винахідливістю і свідомістю. Однак, не слід сприймати
MSF як догму або панацею. Її
можна адаптувати під свої потреби або використовувати лише фрагменти чи
концепції, які можуть бути застосовні в конкретному проекті.
Agile-методології –
це сімейство процесів розробки програмних продуктів, орієнтованих на
використання ітеративної технології з динамічним формуванням і
уточненням системи вимог на кожному витку ітерації. Вони встановлюють першорядною цінністю
безпосередньо розробку ПЗ, а всі інші види діяльності (написання проектної документації, підтримка моделей архітектури
ПЗ тощо) є другорядними. Метою гнучких методів є розробка ПЗ в строк, в рамках
встановленого бюджету і, найважливіше, створення ПЗ саме таким, яким його хоче
бачити замовник [5].
Основні принципи гнучкої
розробки ПЗ викладені в Agile Manifesto [6]. Маніфест гнучкої розробки
складається з чотирьох пунктів, кожний з яких є альтернативою. Це дозволяє, з
погляду авторів Маніфесту, краще зрозуміти, з яким вибором команді доводиться
стикатися в процесі розробки ПЗ, і який шлях є ближчим до цінностей гнучкої
розробки:
Люди та співпраця важливіші за процеси та інструменти.
Працюючий продукт важливіший за вичерпну документацію.
Співпраця із замовником важливіша за обговорення умов
контракту.
Готовність до змін важливіша за дотримання плану.
Тобто, хоча, цінності, що справа (характерні для водоспадної моделі ЖЦ), важливі, в Agile-методологіях більше цінується
те, що зліва.
Гнучкий
підхід до розробки ПЗ використовує наступні основні методології: екстремальне
програмування (eXtreme
Programming, XP); Scrum; Feature Driven Development (FDD); Dynamic System Development Method (DSDM); сімейство
методологій Crystal.
Основними спільними
особливостями гнучких методологій є:
- орієнтованість на людей –
як розробників, так і замовників; вважається, що уміння зібрати в проектній
команді “правильних” людей визначає успіх або невдачу проекту в значно більшій
мірі, ніж будь-які процеси або технології;
- використання усних
обговорень замість формальних специфікацій скрізь, де це можливо; обговорення
мають бути головним способом комунікації як із замовником, так і всередині
проектної команди;
- ітеративна розробка з
якомога коротшою (в розумних межах) тривалістю ітерації, при цьому в результаті
кожної ітерації випускається повноцінна працююча версія продукту;
- очікування змін (в
гнучкому процесі проектна команда не намагається зафіксувати вимоги на початку
проекту і потім жорстко слідувати певному плану – зміни можуть бути зроблені
навіть на найпізнішому етапі проекту).
Основна ідея всіх гнучких моделей полягає в тому, що використовуваний в
розробці ПЗ процес повинен бути адаптивним. Вони декларують своєю
вищою цінністю орієнтованість на людей і їх взаємодію, а не на процеси і
засоби. По суті, гнучкі методології – це не так методології, як набір практик,
які можуть (або не можуть) дозволити добиватися ефективної розробки ПЗ,
грунтуючись на ітеративності, інкрементності, самокерованості команди та
адаптивності процесу. Таким чином, суть гнучких
методологій полягає у відмові від всього
зайвого, що не відноситься безпосередньо до створення якісного ПЗ, а за основу
беруться лише найефективніші методи створення ПЗ.
Головна перевага гнучких
методологій – здатність компанії-розробника працювати в нестабільній предметній
області, своєчасно реагуючи на часті зміни у вимогах та потребах замовника
впродовж всього процесу розробки ПЗ. Керування змінами вимог грунтується на
ітераційній розробці, завдяки якій вимоги аналізуються й уточнюються на початку
кожного циклу. Отже, вимоги, які є гнучкими і змінюваними в часі, більше
відповідатимуть потребам замовника, а безперервна інтеграція сприятиме
підвищенню якості продукту.
Наступна перевага гнучких
методологій – зменшення ризиків проекту і підвищення його ефективності через
тісну взаємодію із замовником, безперервне тестування і прозорі комунікації.
Безперервне інтегрування і тестування продукту впродовж ЖЦ сприяють зниженню
інтенсивності дефектів і ранній ідентифікації проблем. Самоорганізація команд зумовлює спроби поліпшити
комунікацію в межах команди, що сприяє скороченню тривалості процесу
приймання рішень. Інкрементна розробка і формування спільного для
замовника і розробника бачення того, що має розроблятися, допомагає
зосередитися на найбільш вагомих задачах.
Ще одна перевага, яка досягається завдяки ітераційному
процесу розробки ПЗ, – скорочення
часу до випуску продукту. Загальним для методологій є наголос на постачанні працюючого коду, отриманого в кожній ітерації,
хоча методології відрізняються встановленою тривалістю ітерацій,
складом і послідовністю вирішуваних у них задач. Теоретично, переданий код міг би одразу використовуватися замовником без очікування
завершення проекту.
Загальна перевага всіх гнучких методологій – задоволеність замовників, в основі якої
лежить щоденна взаємодія з ними розробників. Контролюючи еволюцію
змін вимог до продукту, розробники навчаються точно інтерпретувати вимоги і точніше реалізовувати їх у коді. Інший аспект
задоволеності замовників – орієнтація на першочергову реалізацію найбільш значущих (цінних) для замовників
функцій продукту, заснована на переоцінюванні пріоритетів проекту в
кінці кожної ітерації.
Разом з тим гнучкі
методології мають і певні недоліки. Так, їх впровадження у поточний процес розробки
ПЗ спричинює організаційні проблеми компанії-розробника: необхідність
реформування організаційної культури (перехід до роботи в командах); залучення
замовника до процесу розробки (запровадження нових правил комунікації,
переосмислення ролі замовника); спротив персоналу до змін (перехід від
документо-орієнтованої розробки до гнучкої, необхідність оновлення знань);
складність розподілу ресурсів і встановлення балансу між інвестиціями і
прибутком у проекті.
Оскільки вимоги в гнучких
методологіях є “полегшеними” й керованими локально в межах кожної ітерації,
можуть з‘явитись проблеми щодо їх стабілізації, правильного тлумачення. Можливі
також проблеми, пов’язані з уривчастістю архітектури, ускладненням рефакторингу
тощо.
Загалом використання
гнучких методологій не рекомендоване для виконання крупних проектів (з
чисельністю персоналу більше 40 осіб) через труднощі організації безпосередньої
комунікації членів команди “віч-на-віч”. Ці
методології не застосовні також для розробки ПЗ, до якого висуваються
високі вимоги надійності і безпеки.
Таким чином, при всіх
достоїнствах гнучкої розробки ПЗ цей підхід не є універсальним і
застосовний тільки в проектах певного класу. Крім того, її ефективне
використання можливе лише за умови, що розробники ПЗ володіють дуже високою
кваліфікацією і значним досвідом.
Отже, саме вибір
методології розробки ПЗ має ключове значення для подальшого успіху проекту. Щоб
повною мірою задовольнити всі вимоги клієнта, ІТ-компаніям слід підбирати оптимальну методологію розробки для кожного конкретного випадку: в залежності від поставленого завдання треба визначити ті сучасні
технології розробки, застосування яких буде найбільш доцільним і ефективним. При виборі методології
розробки ПЗ слід також керуватися тим, що складність методології порівнянна зі
складністю структури програмного продукту, і невиправдана для продукту даної
складності складність методології лише невиправдано збільшить вартість розробки
ПЗ.
Не існує
якоїсь однієї, єдино правильної методології, оптимальної для будь-якого
проекту. У кожному конкретному випадку правильний вибір методології розробки
залежить від низки чинників: масштабу проекту; критичності
проекту; кількості і розподілу повноважень учасників проекту; ступеня новизни проекту; очікуваної тривалості проекту; вимог
замовника.
Зазвичай, вибір між традиційними і гнучкими методологіями
значною мірою визначається бажаним ступенем формалізації процесу розробки ПЗ. Для великих, розрахованих на тривалий термін проектів,
як правило, рекомендуються більш адекватні методології з вищим ступенем формалізації, в той час як для менш
масштабних проектів, розрахованих на оперативну реалізацію,
підходять менше формалізовані гнучкі методи розробки.
Систематичний, обгрунтований підхід до вибору і
використання сучасних методологій може скоротити час і підвищити якість
розробки ПЗ, забезпечити високий ступінь його незалежності від конкретних
розробників, а також знизити витрати на розробку і супровід ПЗ.
Література
1.
Вендров А. М. Современные технологии создания программного обеспечения
[Электронный ресурс] / А. М. Вендров // Портал “CITFORUM”. – Режим доступа: http://citforum.ru/programming/application/program/index.shtml#v
2.
СОУ-Н ДКА 0061:2012. Настанова Державного
космічного агентства України. Галузева система управління якістю. Процеси
життєвого циклу програмного забезпечення програмно-технічних комплексів
критичного призначення. – К.: ДКА
України, 2012. – 111 с.
3.
Якобсон А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. – Спб.: Питер, 2002. – 496 с.
4.
Хаф Л. Методологии
разработки ПО. Часть 5. Microsoft Solutions Framework [Электронный ресурс] / Л. Хаф. // Компьютер Пресс. – №
7. – 2004. – Режим доступа: www.compress.ru/Archive/CP/2004/7/29/
5. Вольфсон Б. Гибкие
методологии разработки [Электронный ресурс] / Б. Вольфсон // Электронная
библиотека adm-lib.ru. – Режим
доступа: http://adm-lib.ru/books/10/Gibkie-metodologii.pdf
6.
Manifesto for Agile Software Development [Электронный ресурс] //
Веб-портал agilemanifesto.org. – Режим доступу: http://www.agilemanifesto.org/