Лекція 1. Менеджмент програмних проектів

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

1.1. Моделі розробки додатків

1.1.1. Модель водоспаду

1.1.2 Спіральна модель

1.1.3 Універсальний процес

1.1.3.1. Етапи

1.1.3.2. Фази

1.1.3.3. Ітерації

1.2 Компромісний трикутник

1.3. Принципи моделі процесу розробки

1.4. Рекомендації з організації випуску версій продукту

2. Склад проектної команди та обов’язки її членів

3. Ролі членів групи в моделі процесу розробки

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

Для успішного керування проектами розробки програмного забезпечення потрібні дві важливих якості. Перше – строгість – необхідно для постійного контролю стану проекту. Друге – гнучкість – потрібно для успішної адаптації до неминучих несподіванок. Більша частина цієї лекції присвячена моделі процесу розробки додатків MSF (MSF Process Model for Application Development), або, коротше, моделі процесу розробки. Модель процесу MSF – це не детальна інструкція, а структурний каркас, на базі якого організації можуть створювати конкретні способи рішення своїх завдань. Модель процесу розробки – складова частина цієї структури, що описує життєвий цикл проекту розробки програмного забезпечення. Вона дозволяє проектній групі створювати продукт у постійному контакті із замовником і адаптувати процес відповідно до його побажань. Крім того, цей метод здатний забезпечувати найшвидшу реалізацію ключових складових проекту. Модель процесу розробки додатків MSF – гнучкий компонент загальної моделі процесу MSF. с успіхом застосовуваний в індустрії розробки програмного забезпечення для підвищення керованості проектів, мінімізації ризиків, підвищення якості продукції й прискорення розробки.

1.1. Моделі розробки додатків

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

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

1.1.1. Модель водоспаду

Як показано на рис. 1.1. модель водоспаду представляє процес розробки у вигляді строго впорядкованої послідовності етапів. До них відносяться:

• збір вимог до системи й програмного забезпечення;

• аналіз;

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

• кодування й тестування модулів;

• інтеграція системи;

• тестування додатка в цілому;

• передача в експлуатацію.

Збір вимог

Аналіз

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

Кодування та

тестування модулів

Інтеграція системи

Інтегральне тестування

Приймання

Рис. 1.1. Модель водоспаду

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

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

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

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

• Неадекватне керування ризиками – ризики, пов'язані із проектом, виявляються на пізніх стадіях виконання проекту.

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

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

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