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

1. Частина 1 Лілія Хаф від редакції Вступ Етапи життєвого циклу ПО стратегія аналіз проектування...
2. Вступ
3. Етапи життєвого циклу ПО
4. стратегія
5. аналіз
6. проектування
7. Реалізація
8. тестування
9. Впровадження
10. Експлуатація та технічна підтримка
11. каскадна модель
12. Поетапна модель з проміжним контролем
13. спіральна модель

Частина 1

Лілія Хаф

від редакції

Вступ

Етапи життєвого циклу ПО

стратегія

аналіз

проектування

Реалізація

тестування

впровадження

Експлуатація та технічна підтримка

каскадна модель

Поетапна модель з проміжним контролем

спіральна модель

Нещодавно видавництво «Вільямс» випустило ряд книг ...

від редакції

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

Вступ

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

• необхідну функціональність системи і ступінь адаптації до постійно змінюваних умов її функціонування;

• необхідну пропускну здатність системи;

• необхідний час реакції системи на запит;

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

• простоту експлуатації і підтримки системи;

• необхідну безпеку.

Продуктивність є головним фактором, який визначає ефективність системи. Гарне проектне рішення - основа високопродуктивної системи.

Проектування інформаційних систем охоплює три основні області:

• проектування об'єктів даних, які будуть реалізовані в базі даних;

• проектування програм, екранних форм, звітів, які будуть забезпечувати виконання запитів до даних;

• облік конкретної середовища або технології: топології мережі, конфігурації апаратних засобів, використання архітектур «файл-сервер», «клієнт-сервер», паралельної обробки, розподіленої обробки даних і т.п.

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

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

Довгий час процес розробки ПО здійснювався відповідно до методиками, напрацьованими в інженерній галузі, - стандартна практика поетапного створення продукту, починаючи зі складання специфікацій і закінчуючи поставкою замовнику. Існують стандарти ГОСТ (Росія) і ISO (Європа, Росія), CMM (Capability Maturity Model - поширений в США), які регламентують цей процес.

Відомі кілька основних моделей життєвого циклу ПО.

Каскадна модель - перехід на наступний етап означає повне завершення робіт на попередньому етапі.

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

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

Активне програмування і його клони - найбільш популярним для даної моделі стало екстремальне програмування (extreme Programming, XP). Батьком-ідеологом XP вважають Кента Бека (Kent Beck). XP є досить молодий методологією, оцінки якої вельми суперечливі: від захоплених до різко негативних. Основними принципами є простота рішень і інтенсивна розробка малими групами, активне спілкування в групі і зворотний зв'язок з клієнтом, фактично залученим в процес розробки, а також певна частка куражу.

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

Етапи життєвого циклу ПО

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

стратегія

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

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

Визначення стратегії - це принципова відповідь на запитання на кшталт: «Чи будемо ми робити цей проект за такі-то гроші чи ні?» Або «Чи робимо ми в принципі цей проект з даними розробником?» Іншими словами, в результаті визначення стратегії розробник і замовник приймають рішення про продовження робіт на певних умовах з певними обов'язками сторін.

Слід виділити набір фактів, які повинні бути обов'язково відображені в заключному документі після проведення обстеження і аналізу діяльності підприємства:

• обмеження, ризики, критичні фактори, що впливають на проект;

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

• критичні терміни завершення етапів, форма здачі робіт, захист комерційної інформації;

• опис виконуваних системою функцій;

• інтерфейси і розподіл функцій між людиною і системою;

• вимоги до програмних і інформаційних компонентів ПЗ;

• наявність потенційного розвитку системи в майбутньому;

• те, що не буде реалізовано в рамках проекту.

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

аналіз

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

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

Аналітики збирають і фіксують інформацію в двох взаємопов'язаних формах:

• функції - інформація про події та процеси, які відбуваються в бізнесі;

• сутності - інформація про речі, які мають значення для організації і про які що-небудь відомо.

Раніше двома класичними результатами аналізу були: ієрархія функцій, яка розбиває процес обробки на компоненти ( «що робиться і з чого це складається»), і модель «сутність-зв'язок» (Entry Relationship model, ER-модель), яка описує сутності, їх атрибути і зв'язки (відношення) між ними. Ці результати є необхідними, але не достатніми. До достатнім результатами слід віднести діаграми потоків даних і діаграми життєвих циклів сутності, які описують динаміку системи. В даний час існує спосіб формалізації проекту - Unified Modelling Language (UML), що дозволяє формально описати різні сторони життєдіяльності розроблюваного проекту. Існує досить велика кількість ПО, що реалізує UML, наприклад Rational Rose, Microsoft Visio. Про UML ми розповімо в окремій частині цієї статті.

проектування

На етапі проектування формується модель даних. Проектувальники отримують вхідні дані аналізу. Кінцевим продуктом етапу проектування є схема бази даних (якщо така існує в проекті) або схема сховища даних (ER-модель) та набір специфікацій модулів системи (модель функцій).

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

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

Завданнями проектування є:

• розгляд результатів аналізу і перевірка їх повноти;

• семінари з замовником;

• визначення критичних ділянок проекту і оцінка обмежень проекту;

• визначення архітектури системи;

• прийняття рішення про використання продуктів сторонніх розробників, а також про способи інтеграції і механізмах обміну інформацією з цими продуктами;

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

• проектування процесів і коду: остаточний вибір засобів розробки, визначення інтерфейсів програм, відображення функцій системи на її модулі та визначення специфікацій модулів;

• визначення вимог до процесу тестування;

• визначення вимог безпеки системи.

Реалізація

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

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

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

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

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

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

Слід відзначити виняткову важливість обміну інформацією між проектувальниками, розробниками, тестувальниками: помилки повинні бути класифіковані відповідно до пріоритетів; для кожного класу помилок повинна бути визначена чітка структура дій: «що робити», «як терміново», «хто відповідальний за результат»; кожна проблема має відстежуватися проектувальником / розробником / тестувальником, що відповідає за її усунення. Те ж саме стосується ситуацій, коли порушуються заплановані терміни розробки, передачі модулів на тестування. Всі проблеми при взаємодії між групами можуть коштувати досить дорого.

тестування

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

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

• зберігання повідомлення про помилку (до якого компоненту системи відноситься помилка, хто її знайшов, як її відтворити, хто відповідає за її виправлення, коли вона повинна бути виправлена);

• система повідомлення про появу нових помилок, про зміну статусу відомих в системі помилок (повідомлення по електронній пошті);

• звіти про актуальні помилки по компонентах системи;

• інформація про помилку і її історія;

• правила доступу до помилок тих чи інших категорій;

• інтерфейс обмеженого доступу до системи bug tracking для кінцевого користувача.

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

Власне тести систем можна розділити на кілька категорій:

• автономні тести модулів; вони використовуються вже на етапі розробки компонентів системи і дозволяють відстежувати помилки окремих компонентів;

• тести зв'язків компонентів системи; ці тести також використовуються і на етапі розробки, і на етапі тестування, вони дозволяють відслідковувати правильність взаємодії та обміну інформацією компонентів системи;

• системний тест; ВІН є Основним крітерієм приймання системи; як правило, це група тестів, що включає і автономні тести, і тести зв'язків і моделі; даний тест повинен відтворювати роботу всіх компонентів і функцій системи; основна мета даного тесту - внутрішня приймання системи і оцінка її якості;

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

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

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

• відмова окремого компонента інформаційної системи;

• відмова групи компонентів інформаційної системи;

• відмова основних модулів інформаційної системи;

• відмова операційної системи;

• жорсткий збій (відмова харчування, жорстких дисків).

Ці тести дозволяють оцінити якість підсистеми відновлення коректного стану інформаційної системи і служать основним джерелом інформації для розробки стратегій запобігання негативним наслідкам збоїв при промисловій експлуатації. Як правило, цим класом тестів розробники традиційно зневажають, а потім змушені «лікувати» наслідки збоїв на промисловій системі.

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

Впровадження

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

Введення в експлуатацію проходить як мінімум три стадії:

• первісна завантаження інформації;

• накопичення інформації;

• вихід на проектну потужність (тобто власне перехід до етапу експлуатації).

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

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

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

Вихід системи на проектну потужність в хорошому варіанті - це доведення дрібних помилок і рідкісні серйозні помилки.

Експлуатація та технічна підтримка

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

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

каскадна модель

анная модель також носить назву «водоспад». Класичними представниками реалізації даної методології є стандарти ISO і CMM.

Модель передбачає наступні властивості взаємодії етапів:

• модель складається з послідовно розташованих етапів;

• кожен етап повністю закінчується до того, як почнеться наступний;

• етапи не перекриваються в часі: наступний етап не починається до тих пір, поки не завершиться попередній;

• повернення до попередніх етапів не передбачений або всіляко обмежений;

• виправлення помилок відбувається лише на стадії тестування;

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

Критерієм появи результату є відсутність помилок і точну відповідність продукту початкової специфікації.

Поетапна модель з проміжним контролем

анная модель ще відома як итерационная модель або «вир».

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

• модель складається з послідовно розташованих етапів (точно так само, як і «водоспад»);

• кожен етап має зворотний зв'язок з попередніми етапами;

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

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

• результат з'являється тільки в кінці розробки, як і в моделі «водоспад».

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

спіральна модель

оммерческімі представниками даної методології є RUP (Rational Unified Process), MSF (Microsoft Consulting Services), і про це буде розказано в наступних частинах цієї публікації.

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

Модель передбачає також властивості взаємодії етапів:

• модель складається з послідовно розташованих етапів (як і «водоспад») в межах одного витка спіралі;

• всередині витка спіралі етапи не мають зворотного зв'язку; аналіз результату здійснюється в кінці витка і ініціює новий виток спіралі;

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

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

• результат з'являється в кінці кожного витка спіралі і піддається детальному аналізу, аналізуються нові вимоги замовника та ініціюється новий виток спіралі;

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

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

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

КомпьютерПресс 7'2003