Методології розробки програмного забезпечення: поняття, принципи, методи та етапи розробки

Опубликованно 26.08.2018 01:15

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

Почнемо статтю з визначення. Методологія розробки програмного забезпечення - це сукупність принципів, система ідей, понять, способів, методів і засобів, які в кінцевому підсумку визначатимуть стиль розробки ПО. Іншими словами, методологія тут - реалізація якого-небудь певного стандарту.

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

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

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

Прогнозовані методології

Що відноситься до даних методологій розробки програмного забезпечення? Це ті різновиди, які орієнтовані на детальне планування майбутнього. Завдання і ресурси відомі на всьому протязі терміну проекту. Звідси робоча команда буде важко реагувати на несподівані зміни.

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

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

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

Гнучкі методології

Гнучкі методології розробки програмного забезпечення - англ. Agile software development. Звідси друга назва: agile-методи.

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

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

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

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

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

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

Agile Manifesto

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

Agile Manifesto був розроблений і прийнятий 1-13 лютого 2001 року у лижному комплексі в горах Юти. Містить в себе 4 головні ідеї і 12 принципів командної роботи без єдиного практичного ради.

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

Також в рамках Agile Manifesto були позначені наступні принципи діяльності розробників: Задоволення запитів клієнта за рахунок безперебійної ранньої поставки цінного. Привітання змін вимог навіть по завершенні реалізації проекту. Адже саме це може підвищити його конкурентоспроможність. Часті постачання робочого ПО - кожну тиждень-місяць. У проекті зайняті мотивовані особистості, забезпечені комфортними умовами роботи, довірою і підтримкою. Щоденне тісну взаємодію між замовником і командою розробників. Кращим вимірювачем прогресу буде працює програмне забезпечення. Користувачі, спонсори і розробники мають підтримувати вибраний темп невизначений термін. Постійну увагу поліпшенню дизайну продукту, технічним вимогам. Простота виступає мистецтвом не займатися зайвою роботою. Постійна адаптація до мінливих умов діяльності. Розробники повинні постійно знаходити засоби підвищення ефективності своєї роботи, слідувати їм у подальшому. Waterfall Model

Від маніфесту гнучкої методології розробки програмного забезпечення переходимо до нового типу. Waterfall Model - "водоспад" або каскадна модель. Одна з найстаріших методологій. Передбачає послідовне проходження етапів розробки програмного забезпечення, кожен з яких повинен закінчиться до того, як почнеться наступний.

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

Якщо вибір такої моделі недостатньо обґрунтований для продукту, то на виході можна побачити з істотними недоліками. Адже про їх наявність дізнаються вже після закінчення робіт з-за суворої послідовності діяльності. Виправлення помилок тут виходить досить дорогим. Для початку виправлень доводиться чекати закінчення розробки.

Фахівці радять використовувати методологію "водоспад" в наступних випадках: Вимоги до проекту відомі, зрозумілі і фіксовані. Будь-яких суперечностей між ними немає. Немає проблем до залучення програмістів необхідної кваліфікації. Проект відносно невеликий.

V-Model

Стадії розробки програмного забезпечення тут також послідовні. Цю особливість V-Model "успадкувала" від "водоспаду". Особливо хороша для тих систем, де потрібно безперебійне функціонування. Хороший приклад: створення прикладного ПО для клінік, використовуваного для безперервного спостереження за пацієнтами. Або ж програмне забезпечення, яке керує механізмами подушок безпеки в транспортних засобах. Або додаток для мобільного оператора, покликаний економити витрати користувача на роумінг у поїздках за кордон.

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

Коли необхідно використовувати дану методологію для розробок: У випадках, де потрібна проведення ретельного тестування продукту. Для невеликих і середніх проектів з чітко визначеними вимогами. В умовах, коли доступні інженери, тестувальники конкретної кваліфікації. Incremental Model

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

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

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

Опишемо випадки, коли використання Incremental Model буде обґрунтованим: Чітко визначені і зрозумілі вимоги до кінцевого продукту. Допускається доопрацювання деяких деталей з плином часу. Є декілька ризикових цілей. Необхідний ранній висновок на ринок.

RAD Model

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

Процес розробки програмного забезпечення тут включає в себе кілька етапів: Бізнес-моделювання. Це визначення інформаційних потоків між спектром підрозділів. Моделювання відомостей. Дані, зібрані на першому етапі, використовуються для визначення сутностей, необхідних для циркуляції інформації. Моделювання процесу. Під час цієї фази інформаційні потоки пов'язують певні об'єкти для досягнення мети розробки. Складання програми. Тут використовуються засоби автоскладання для перетворення моделей проектування в код. Тестування. Перевірка нових компонентів і інтерфейсів.

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

Модель вибирають при впевненому знанні цільового бізнесу в тих випадках, коли потрібно представити готовий продукт в короткі терміни - за 2-3 місяці. Iterative Model

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

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

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

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

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

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

Spiral Model

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

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

Спіральну модель не варто використовувати для маленьких бюджетних проектів. Навпаки, вона більше підходить для масштабних і дорогих. Відмінний приклад застосування методології для розробки системи банківського документообігу. Тут велика увага приділяється не стільки самому програмування, скільки аналізу кожного вже виробленого "витка". LD

Так звана ощадлива розробка ПЗ. Є одним з відгалужень гнучкої методології, яку ми розібрали вище. Головне достоїнство LD: збереження високого морального і функціонального стану фахівців. Зокрема, це наступне: Заохочення кожного з працівників за особливо успішну діяльність. Поточні завдання проекту змінюються лише в разі крайньої необхідності або за бажанням замовника. Суворе виконання плану. Сверхработы тут вважаються ознакою втрати як часу, так і ресурсів. Впровадження в роботу загальній концепції діяльності: "Широко мислити, швидко помилятися, мало працювати, стрімко навчатися". XP

Вельми цікавий приклад - методологія так званого екстремального програмування. Що тут ховається? Це ведення розробки в умовах постійно змінюючихся вимог до продукту. Напрямок методології має такі відмінні риси: "Гра в планування". На початку робіт представлений лише приблизний план. З кожним витком розробки його чіткість збільшується. Висока частота релізів. Це означає, що нова версія буде мати лише невеликі відмінності від попередньої, але на її випуск витрачається мінімум часу. Контакт з клієнтом. Для наступних даної методології важливо швидко задовольняти всі вимоги замовника - оперативно реагувати на всі його зауваження і побажання. Рефакторинг. Якість коду поліпшується без зменшення його функціональності. Стандартне виконання коду. На обличчя або слідування загальними правилами, або відсутність розбіжностей у процесі розробки. Колективна відповідальність. Так, кожен з членів команди зайнятий певним ділянкою робіт. Але за загальний результат відповідальний вже весь колектив.

FDD

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

Цінність методології і в тому, що вона чітко регламентує тривалість процесів. При цьому на організаційні питання в кожному циклі не повинно витрачатися більше 25 % часу. Решта 75 % - суто на розробку, складання, тестування функціоналу.

На цьому закінчимо знайомство з основними розробками програмного забезпечення. Як ви переконалися, особливості кожної з них дозволяють вибрати відповідну методологію для успішної реалізації найбільш різнотипних проектів. Автор: Юлія Абдулбарова 6 Серпня, 2018

Категория: Техника