РОЗРОБКА ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

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

Програмне забезпечення розроблене на платформі Microsoft .NET Framework 3.5, мовою програмування С# в середовищі Microsoft Visual Studio 2008. Для доступу до баз даних використана технологія ADO.NET. У якості сервера баз даних слугує сервер MS SQL 2008.

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

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

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

 що насправді необхідно створити;

 як це можна реалізувати.

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

Ризики можна розділити на чотири категорії.

1 Ризики, пов’язані з вимогами. Які вимоги до системи? Велика небезпека полягає в тому, що буде розроблено зовсім не ту систему, яка виконуватиме зовсім не те, що потрібно користувачам.

2 Технологічні ризики. З якими технологічними ризиками доведеться зіткнутися? Чи дійсно дозволяє вибрана вами технологія реалізувати проект? Яким чином слід інтегрувати різні частини проекту?

3 Ризики, пов’язані з кваліфікацією персоналу. Чи є змога підібрати штат співробітників з необхідним досвідом і кваліфікацією?

4 Політичні ризики. Чи існують політичні сили, які можуть опинитися на вашому шляху і серйозно вплинути на виконання проекту?

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

Фаза дослідження повинна займати біля однієї п’ятої часу від загальної тривалості проекту. Основними ознаками завершення фази дослідження є наступні дві події:

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

 ідентифіковані всі найбільш серйозні ризики, а найважливіші з них зрозуміли настільки, що вам відомо, як з ними впоратися.

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

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

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

В ході планування краще розглядати дві групи осіб: клієнти і розробники.

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

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

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

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

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

Якщо велика частина часу роботи над проектом витрачається на ці варіанти використання, то необхідно виконати додаткове дослідження.

Наступний крок полягає в розподілі варіантів використання по ітераціях.

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

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

Ітерації на стадії побудови є як інкрементними (нарощуваними), так і такими, що повторюються.

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

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

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

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