Технологія розробки програмного забезпечення

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


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


Так, за даними американських дослідників, у 80ті роки тільки 14% проектів по створенню ПЗ завершувалися успішно (Мається на увазі не тільки задоволення вимог замовника, а й завершення у термін з дотриманням бюджету (Chaos Report)). Сьогодні, після кількох десятиліть еволюції мов програмування, інструментальних засобів розробки, практично необмеженої доступності машинного часу (в порівнянні із 70 і 80мі роками) відсоток успішно завершених проектів складає всього 26% (Дані були наведені на одному з семінарів Г. Бучем.).


У СРСР у виробництві ПЗ результати були значно краще і об'єктивними передумовами цього були такі моменти:



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


У будь-якому виробництві використовується технологія визначає кращі досяжні показники. У силу специфічності виробництва ПЗ (практично нульова вартість тиражування, дуже швидкий процес старіння і т. д.) технологія його створення дуже сильно зав'язана на людський ресурс і тому повинна включати в себе організаційний і управлінський аспекти. На сьогоднішній день у світі існує величезна кількість раз особистих процесів для створення ПЗ. Тим не менш, саме технологій, що розглядають повний життєвий цикл проекту розробки ПЗ, що поєднують в собі науковий підхід, серйозну базу досліджень і мають історію реального використання та адаптації, відносно небагато. З методологій і технологій, які отримали певне визнання на даний момент, можна назвати наступні: Datarun, CMM, Microsoft Solution Framework (MSF), Oracle Method, Rational Unified Process (RUP), SADT (IDEFx).


Особливе місце в цьому списку займає технологія компанії Rational Software. У методології, яка є складовою частиною технології Rational, застосований найбільш сучасний процесно-орієнтований підхід: так як розробка ПЗ є виробництвом, то, як і на всякому виробництві, при виявленні проблем у продукції (симптомів) необхідно в обов'язковому порядку коригувати процес (усувати причини). Особливістю технології є те, що в її створенні беруть участь провідні методисти в галузі розробки ПЗ, такі як Г. Буч (ООАП), Дж. Рамбо (OMT), А. Джекобсон (Objectory), які внесли вагомий внесок в теорію і практику розробки сучасного ПЗ. Крім того, ця технологія розвивалася і проходила перевірку за участю військового відомства США.


Симптоми і причини проблем


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


На думку автора, відділення симптомів від причин проблем, що виникають при розробці ПЗ, дуже істотно. Як показує практика, перелічені симптоми частіше трактуються як особливості, властиві розробці ПЗ в цілому, а не як наслідок неадекватності процесу розробки, так як при усуненні симптомів ефект може бути тільки тимчасовим. Наприклад, "пізніше визначення недоліків" – це лише симптом більш значної проблеми, такий як "неадекватне тестування". А "неадекватне тестування" пов'язане з використанням моделі "Водоспаду", в якій рішення цієї проблеми структурно виключено (тестування відбувається на дуже пізній стадії, коли корекція помилок нездійсненна без серйозної зміни термінів реалізації).


Перерахуємо деякі причини проблем:



Причини проблем і кращі практики


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


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


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


Практика № 1. Ітераційний процес розробки


Суть ітеративної практики може бути краще всього прокоментовано візуально (рис. 2).


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


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


Практика № 2. Управління вимогами


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


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


Говорячи про управління вимогами в підході Rational не можна не згадати про сценарії використання (Use Case). Сценарій є основним структуруючим елементом текстового опису проектованої системи, організованого у відповідності з цілями, переслідуваними користувачем при використанні цієї системи.


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


Практика № 3. Використання компонентної архітектури


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


Згідно з думкою авторів Software Architecture in Practice: "архітектура ПЗ – це така складова результатів розробки, яка дає найвищу віддачу від вкладень".


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


Найбільш поширеними платформами для побудови компонентної архітектури є:



Практика № 4. Візуальне моделювання


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


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


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


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


Практика № 5. Контроль якості


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


У багатьох організаціях тестування забирає 30 – 50% ресурсів на розробку. Тим не менше, кількість помилок у ПЗ, виявлених замовником, свідчить про те, що ПЗ недостатньо тестується до його постачання.


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


Дані, отримані Rational в результаті автоматизації процесу тестування у реального замовника, наступні: до автоматизації виконувалося 13000 тестів за допомогою шести чоловік за два тижні, після автоматизації були виконані ті ж тести за 6 годин за допомогою однієї людини.


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


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


Практика № 6. Управління змінами


Одним з ключових і складних понять в області розробки ПЗ є парадигма "Управління змінами". Rational виділяє такі основні проблеми:



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


Управління запитами на зміну (Change Request Management) відповідає інфраструктурі, необхідної для контролю над впливом на вартість і строки від необхідних виправлень для існуючого продукту.


У правління конфігурацією (Configuration Management) являє собою діяльність по визначенню конфігурацій, побудови, маркування та зберігання версій артефактів.


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


Безумовно, настільки короткий розгляд не може освітити всі аспекти застосування кращих практики показати всі взаємозв'язки між ними. Як можна побачити з таблиці 2, для усунення однієї причини проблеми задіюється декілька практик. Кращі практики формують основу для подісціплінного розгляду технології розробки ПЗ, представленого в Rational Unified Process (RUP).


Процес розробки


Будь-практик, прочитавши першу частину статті, скаже: "Теорія це добре, але від теорії до практики ще ой як далеко. Необхідно розвивати і впроваджувати процеси, пов'язані з перерахованими практиками, розробляти підтримуючі елементи і т. д. І це все величезна робота, яку теж необхідно робити …".


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


Для успішного застосування методології необхідно встановлення адекватного процесу розробки. І саме розгорнутий шаблон процесу разом з достатнім для його реалізації комплексом інструментарію пропонує Rational. Описані шість кращих практик лягли в основу Rational Unified Process (RUP).


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


Опис RUP


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


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


Фази


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


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


Моделі


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



У підході Rational для відображення моделей використовується Unified Modeling Language (UML). З точки зору процесу UML є стандартом опису для артефактів розробки та моделювання (семантичних моделей, синтаксичних нотацій і діаграм), тобто тієї інформації, яка необхідна для забезпечення взаємодії в процесі розробки та підтримки програмного забезпечення. UML не визначає, яким чином використовувати його можливості для отримання результату, які моделі повинні бути побудовані і в якій послідовності.


Дисципліни


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


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


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


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


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


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


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


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


Для вирішення цього завдання в RUP представлені готові до використання шаблони основних документів (MS Project, MS Word) для управління проектом, а також комплекс посібників для планування, кадрового забезпечення, виконання та контролювання проекту.


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


Люди


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


Для досягнення цієї мети доступні наступні можливості:



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


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


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*