Моделі життєвого циклу

Основа розробки програмного забезпечення

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

Існує декілька моделей життєвого циклу (ЖЦ), кожна з яких визначає різну методологію створення систем. Всі без виключення моделі ЖЦ включають в себе п’ять етапів і зв’язків між ними з подальшим описанням дій, моделей і результатів кожного етапу. Наведемо назву і короткий зміст кожного етапу у відповідності з ГОСТ 19.102–77.

1. Технічне завдання:

– постановка задачі;

– вибір критеріїв ефективності;

– проведення попередніх науково-дослідницьких робіт (НДР);

– розробка ТЗ.

2. Ескізний проект:

– структура вхідних і вихідних даних;

– уточнення методів розв’язання;

– загальний алгоритм;

– розробка документації ескізного проекту.

3. Технічний проект:

– уточнення структури вхідних і вихідних даних;

– розробка алгоритмів;

– форми даних;

– семантика і синтаксис мови;

– структура програми;

– конфігурація технічних засобів;

– план робіт.

4. Робочий проект:

– програмування і налагодження;

– розробка документів;

– підготовка і проведення випробувань;

– коректування програми і документів по висновкам випробувань.

5. Впровадження:

– передача програми і документів для супроводження;

– оформлення акта;

– передача в Фонд алгоритмів і програм (ФАП).

Історично в ході розвитку теорії проектування програмного забезпечення і по мірі його ускладнення сформувались чотири моделі ЖЦ.

Першою по часу появи і самою поширеною є каскадна модель.

Рис. 2.5. Каскадна модель життєвого циклу ПЗ

Каскадна модель характеризується наступними основними особливостями:

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

– закінченням кожного попереднього етапу до початку наступного;

– відсутністю часового перекриття етапів (наступний етап не починається, поки не завершиться попередній);

– відсутність (або певні обмеження) повернення до попередніх етапів;

– наявність результату тільки в кінці розробки.

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

Наступною стадією розвитку теорії проектування ПЗ стала Ітераційна модель ЖЦ, чи так звана поетапна модель з поетапним контролем. Основною її особливістю є наявність зворотних зв’язків між етапами, внаслідок цього з’являється можливість проведення перевірок і коректувань ІС на кожній стадії розробки. В результаті трудомісткість налагодження порівняно з каскадною моделлю суттєво знижується. Ітераційність моделі проявляється в обробці помилок, виявлених поетапним контролем. Якщо на деякому етапі в ході поетапної перевірки знайдена помилка, допущена на більш ранній стадії розвитку, необхідно повторити весь цикл робіт цієї стадії. При цьому аналізуються причини помилки і коректуються у випадку необхідності початкові дані етапу чи його зміст (послідовність дій).

Рис 2.6. ітераційна модель життєвого циклу ПЗ

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

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

2.3.4. Rational Objectory Process – модель життєвого циклу (методологія об’єктно–орієнтованого програмування)

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

– модель життєвого циклу;

– дії;

– нотація мови.

2.3.5. Життєвий цикл UML[2] (Rational Objectory Process)

Фірма Rational Software, яка розробила мову UML, запропонувала також і свою модель ЖЦ, яка називається Rational Objectory Process (ROP). Означена технологія прямого перекладу не має, так як rational в даному випадку використовується в значенні «раціональний» і як назву фірми одночасно, по-друге слова objectory в англійській мові не існує, його лінгвістичне утворення аналогічне слову repository (накопичувач).

Перечислимо основні властивості ROP-технології.

Rational Objectory Process – ітеративний процес, під час якого відбувається послідовне уточнення результатів.

Rational Objectory Process направлений саме на створення моделей, а не на розробку будь-яких інших елементів проекту (наприклад, текстових документів).

Дії Rational Objectory Process визначаються в першу чергу блоками використання (use case).

Rational Objectory Process розбитий на цикли, кожен з яких, в свою чергу, складається з чотирьох фаз:

– початкова стадія (Inception);

– розробка (Elaboration);

– конструювання (Construction);

– впровадження в експлуатацію (Transition).

Результатом роботи кожного циклу є своя версія програмної системи.

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

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

Закінченням початкового етапу можуть служити наступні результати:

– початковий проектний словник термінів;

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

– початкова модель варіантів використання;

– початковий бізнес-план;

– план проекту, який зображає стадії та ітерації;

– один або декілька прототипів.

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

Самим важливим результатом стадії розробки є описання базової архітектури майбутньої системи. Ця архітектура включає:

– модель предметної області, яка служить відправним пунктом для формування основних абстракцій предметної області;

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

Стадія розробки займає приблизно п’яту частину часу створення проекту, результатом якої є:

– оцінка часу реалізації кожного варіанту використання;

– ідентифікація всіх найбільш серйозних ризиків і можливості їх ліквідації.

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

При цьому необхідно відмітити наступне:

– ітерації є інкрементними у відповідності з виконуваною функцією. Кожна ітерація додає наступні конструкції до варіантів використання, реалізованим під час попередніх ітерацій;

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

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

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

– бета-тестування, яке дозволяє переконатись, що нова система відповідає очікуванням користувачів;

– паралельне функціонування з існуючою (legacy) системою, яка підлягає поступовій заміні;

– оптимізацію продуктивності;

– навчання користувачів і спеціалістів служби супроводження.

2.3.6. Специфікування і планування

Процес розробки починається зі створення концептуального описання майбутнього продукту, який «грубо» задає його образ, бачення (цей документ так і називається «vision statement») в контексті вимог ринку. Головною діючою особою на цьому етапі є «менеджер по продукту» (product manager) – спеціаліст-маркетолог, який знає ситуацію на ринку і запити потенційних користувачів. Його задача – донести до менеджерів по розробці ПЗ користувальні властивості майбутнього продукту, тобто вказати, які цілі і вимоги користувачів необхідно задовольнити, які для цього закласти функціональні можливості (product features) і в якому порядку у відповідності з існуючими пріоритетами слід їх аранжувати.

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

На зміну функціональності будуть впливати і зовнішні фактори, в тому числі ті реальні і потенціальні ринкові продукти, які так чи інакше конкурують з цим ПЗ. Функціональність залежить від таких факторів, як недостатність ресурсів, відставання від графіка чи просто недоліки в реалізації, які неможливо чи нема часу виправляти. В цьому розумінні корпоративна культура компанії Microsoft не припускає будь-яких комплексів: тут без вагань «ріжуть по живому», залишаючи пріоритет вчасному виходу продукту на ринок. Статистичні дані по основним продуктам Microsoft показує, що в середньому біля 25 % функціональних особливостей вихідної специфікації щезають до моменту випуску продукту; якщо враховувати те, що внесено, то кінцева функціональність буде відрізнятись від початкової на 30 % і більше.

На основі функціональної специфікації менеджери по розробці, постійно консультуючись з проектувальниками, починають на модульній основі створити горизонтальну архітектуру продукту. Головне, що на цій стадії всі основні функції ПЗ розбиваються на декілька груп (зазвичай три-чотири групи). Відповідно, формується стільки ж під проектів робота над якими будуть вестись послідовно. Розбиття проводиться на основі класифікації функцій по ступені важливості. Найбільш важливі (1/3 від загальної кількості, якщо груп всього 3) попадають в перший підпроект; другі, менш пріоритетні, реалізуються в рамках другого під проекту, і насамкінець, решту, найменш значимі функції виконуються в останньому проекті. Кожен підпроект закінчується випуском «контрольною» версією продукту (milestone release).

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

Слід звернути увагу на досить спрощений підхід до розробки архітектури програмного продукту: по суті, саме поняття архітектури зводиться до допоміжного інструментарію, підлеглого інтересам організаційного планування і управління. Добре структурована архітектура продукту є необхідною умовою успішної розробки і подальшого розвитку. Саме тому авторитети в області Software Engineering, наприклад Граді Буч [3], розглядає архітектуру, яка розглядає логічну і фізичну структури програмної системи, як основу вище лежачих стратегічних і тактичних проектних рішень в цілях побудови якісного продукту.

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

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

Розробники виконують проектування, кодування і налагодження свого коду. Зазвичай ніякої особливої проектної документації не ведеться – на фірмі здавна вважається, що її ведення наклало б зайве обмеження на динаміку розробки. Функції документації виконує сам код; при цьому він містить мало коментарів, що завжди і було самою відмінною особливістю хакерів. Для прикладу, коментарії в коді Excel склали лише біля 1 % всього загального об’єму. З урахуванням того, що команді надана можливість, щоб не сказати – обов’язок, не розглядати початкову специфікацію як догму, а навпаки, оперативно відкликатись на пропозиції по її зміні, що поступають ззовні чи генеруються всередині неї, в кінці виявляється що єдиним джерелом для розуміння реалізації функції є цей самий скупо прокоментований код. А віддуватись приходиться місцевим «технічним писарям», і варто дивуватись кількістю погано документованих (і зовсім не документованим) можливостей, якими традиційно славиться курівництво Microsoft. Слід відмітити, що при даному підході до кодування складно використовувати таку сучасну техніку, як «інспекція коду», яка дозволяє різко збільшити кількість знаходження дефектів при скороченні затрат і зусиль на тестування [13].

Команди і окремі розробники, маючи значну свободу в процесі реалізації підпроекту, повинні тим не менш дотримуватись декількох жорстких правил, які необхідні для синхронізації паралельної роботи, що, власне, і дозволяє їм функціонувати як єдиному злагодженому колективу, здатному відносно швидко і дешево справитись з масштабним проектом. Як скоро іде робота над єдиним проектом, то розроблюваний продукт завжди існує у вигляді доступної всім командам централізованої бази даних, яка містить «контрольну» (еталонну) версію файлів з вихідним кодом (master version). Діючий в Microsoft механізм роботи з єдиним проектом зазвичай називають «зборкою» (build), що має на увазі періодичне виконання процедури генерування нової версії продукту з частково чи повністю завершених розробниками компонентів. Ця процедура дозволяє, не очікуючи кінця розробки, одразу ж побачити, як реалізовані окремі функції працюють в контексті всього продукту, і оперативно виявляти і коректувати проблеми.

Прийнята в Microsoft технологія має на увазі щоденне виконання процесу зборки (daily build), який складається з декількох кроків. Перш за все, будь-який розробник має можливість «скачати» (check out) необхідні йому для роботи файли із загальної бази. Після цього він має повну свободу по внесенню в цей код змін, необхідних для реалізації і налаштування тієї функції, за яку він відповідає. В будь-який момент розробник може виконати свою збірку (private build) та згенерувати таким чином персональну версію продукту (private release).

Приблизно половину свого робочого часу розробник тратить на написання коду; іншу половину використовує на тестування, налагодження і пряме спілкування з користувачами продукту. При цьому неможна сказати, що типічний майкрософтовський розробник використовує в своїй роботі сучасні методи та інструменти. Так, більшість продовжують використовувати Unix Source Control System просто тому, що звикли до цієї системи. Це і відображення того факту, що корпоративний менеджмент вважає, що краще тратити час безпосередньо на розробку, ніж на освоєння нового інструментарію. Зате немало важливо, що майже всі команди фізично зосереджені в одному місці (в корпоративному корпусі в Редмонді), використовують загальні мови програмування (в основному це С і С++), більш того – загальний «фірмовий» стиль кодування і стандартизовані засоби розробки. Це допомагає паралельно працюючим командам в обговоренні проектних ідей і рішень, тому що повністю автономної роботи команд над загальним проектом досягнути неможливо.

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

По крайній мірі, двічі в тиждень розробник повинен вбудовувати (check in) розроблений «персональний» код у спільну базу, де знаходиться поточна «еталонна» версія (це можна робити кожен день). При цьому він проводить компіляцію і компоновку з обов’язковим виконанням регресійного тесту, який дозволяє перевірити реакцію загальної «зборки» на новий код. У випадку виявлення при цьому будь-якого дефекту розробник зобов’язаний тут же його «зафіксувати» (М. Кусумано, є автором книг про японські промислові технології, що отримали світову відомість, зауважує тут подібність з діючим в збірковому цеху корпорації «Тойота» правилом, яке вимагає негайної зупинки конвеєра будь-яким працівником, якщо він знайшов дефект в автомобілі).

Операцію по вбудовуванню свого коду в загальну еталонну базу розробники мають право виконувати до певного зазначеного моменту; потім в діло вступає спеціально навчений розробник (project build master), який кожен день генерує повну «зборку» продукту на основі поточної еталонної версії початкового коду всього продукту. Ця процедура дотримується «сценарію зборки» (build script) у вигляді автоматично виконуваної послідовності команд і включає кроки по повній компіляції коду і отримання як наслідок одного або декількох виконуваних файлів. При цьому можуть створюватись різні «бібліотечні файли», які дозволяють кінцевим користувачам налаштувати продукт у відповідності зі своєю специфікацією. Таким чином, кожен день відбувається випуск внутрішньої версії продукту (internal release). Вся ця технологія, направлена на періодичну інтеграцію функцій і «стабілізацію» коду в його поточному стані, дозволяє реалізувати такий базисний принцип, як постійна наявність у всіх необхідних версіях «готового» (нехай не повністю) продукту, який можна показати замовнику.

2.3.8. Випуск продукту і механізми зворотного зв’язку

У процесі розробки постійно використовують декілька метрик. Хоча у відповідності із загальною корпоративною філософією тут не придають такого значення кількісним індикаторам, як, наприклад, в Motorola чи HP, чия корпоративна культура передбачає значно більш «вибудувані» процеси розробки. Тим не менш кожний день відслідковують процес «щоденних збірок» продукту саме на основі метрик, які показують, скільки нових «багів» виявлено, скільки, навпаки, виправлено, і на кінець, скільки всього залишається «активних» дефектів.

У кінці кожного підпроекту – після закінчення строку паралельної роботи команд над реалізацією назначених їм функцій – передбачений спеціальний період «буферний час» (buffer time), під час якого вирішуються всілякі не передбачені планом, але постійно виникаючі проблеми, особливо визвані оперативно внесені зміни в специфікації і взаємозалежність функцій, над якими працювали різні команди. Цей період використовується як і тривіальне продовження періоду розробки підпроекту, тому що виходи за межі часового графіку спостерігаються майже завжди. Для проектів з розряду додатків буферний час займає 20–30% від всієї протяжності проекту, а для системних програм – 50 %.

Важливим механізмом, який забезпечує зворотній зв’язок з потенційним користувачами продукту на протязі всього процесу розробки, включаючи навіть період розробки над першим підпроектом, є інститут лабораторій користувача (Usability Lab). Перша така лабораторія була відкрита в 1989 р. і мала чотири тестових комплекти, кожен з яких включає розділені напівпрозорим дзеркалом кімнати: тестову (test room), де користувач має можливість «пограти» з продуктом, і спостерігальницьку (observation room), де знаходиться співробітник, в його функції входить відслідкування всіх деталей роботи користувача. Через три роки була введена в дію ще одна лабораторія з п’яти тестовими комплексами; в 1995 р. добавили лабораторію яка отримала назву Microsoft Home, і не випадково: щоб заставити користувачів відчувати себе в буквальному розумінні «як дома», в ній створена домашня обстановка, включаючи кухню, столову і дитячу. На кінець, в 1996 р. з’явилась лабораторія з п’ятьма тестовими комплектами, включаючи спеціальне енергономічне обладнання.

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

Головне, що вимірюється і виражається в спеціальних метриках, – це легкість освоєння продукту і зручність роботи з ним. Згадуються дві метрики: перша показує процент користувачів, яким вдалось без звернення до керівництва виконати деяку осмислену дію; друга метрика виражає процент коректних кроків на шляху виконання задачі, зроблених з першої спроби. Дослідним шляхом встановлено, що для більшості продуктів на ранній стадії розробки друга метрика (correct first-try rate) виконуються в районі 60 %; стараються добитись 90 %.

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

Експерименти проводяться не тільки в корпоративних лабораторіях, а і на «виїздах» в офісах, школах та університетах, по місцю проживання все можливих користувачів. Крім того, в останній фазі розробки – фазі стабілізації – «beta» версії, які пройшли усесторонні внутрішні перевірки, відправляються для дослідної експлуатації до партнерів корпорації, які належать до категорій ОЕМ і ISV; тут задіяні і численні добровольці-індивідуали. Після цього компанія приступає до підготовки випуску «фінальної» версії продукту («golden master» discs), а також необхідної документації. Але навіть після випуску «фінальної» версії робота над продуктом не зупиняється. Встановилась традиція в середньому через 12 місяців випускати виправлену і доповнену версію, а через 24 місяці – радикально перероблену (з великою кількістю нових функцій і зміненою архітектурою). Варто відмітити, що робота інженерів служби підтримки фінансується за рахунок команд розробників даного продукту; тому останні зацікавлені в постійній мінімізації дефектів в кожній наступній версії порівняно з попередньою.

Контрольні запитання.

1. Розкажіть про особливості створення програмного продукту.

2. Що таке життєвий цикл програмного забезпечення?

3. Які основні властивості каскадної (ітераційної) моделі життєвого циклу?

4. З яких етапів складається модель життєвого циклу UML?

5. Яка вартість виправлення помилок в ПЗ на різних стадіях його розробки?

6. Що таке «управління вимогами»?

7. Яка суть аналізу проблеми?

8. Які види обмежень на створюване ПЗ потрібно виявити в процесі роботи над вимогами?

9. Які існують методи виявлення вимог до ПЗ?

[1] В історичній послідовності розвитку програмних засобів першими з’явились вузько орієнтовані додатки («програма, призначена для обчислення числа π з точністю до 200 знаку»), потім – системи програмування (раніше їх версії називались системами автоматизації програмування), потім – операційні системи.

[2] Unified Modeling Language – уніфікована мова моделювання.

Дата добавления: 2014-01-04