Компонентно-орієнтована модель конструювання ПЗ

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

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

Переваги моделі (у порівнянні з спіральною моделлю):

1. Зменшення на 30% часу розробки ПП.

2. Зменшення вартості програмної розробки до 70%.

3. Збільшення в 1,5 рази продуктивності розробки.

Недоліки моделі:

1. Відсутня достатня статистика ефективності моделі.

2. Підвищені вимоги до замовника.

3. Труднощі контролю та керування часом розробки.

 

Важковагові та полегшені процеси

Існує дві родини процесів розробки ПЗ:

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

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

 

XP процес

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

Основна мета XP процесу – усунути високу вартість змін (УПЗ).

4 базові дії:

Кодування.

Тестування.

Робота з замовником.

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

Динамізм забезпечується за допомогою наступних характеристик:

1. Неперервний зв'язок з замовником та у групі.

2. Простота – завжди приймається мінімальне рішення.

3. Швидкий обернений зв'язок (досягається за допомогою модульного та функціонального тестування).

4. Сміливість у проведенні профілактики можливих проблем.

Базис з XP складає 12 методів:

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

2. Small releases - часта зміна версій. Швидкий запуск у виробництво системи. Нові версії реалізуються у дуже короткому двотижневому циклі.

3. Metaphar – метафора. Вся розробка проводиться на основі простої загальнодоступної історії про те, як працює вся система.

4. Simple Design – просте проектування. Проектування виконується настільки просто наскільки можливо у даний момент.

5. Testing – тестування. Неперервне написання тестів для модулів, які повинні виконуватися бездоганно. Замовники пишуть тести для перевірки завершеності функцій.

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

7. Pair programming – парне програмування. Весь код пишеться двома програмістами, які працюють за одним комп’ютером.

8. Colective ownership – колективне володіння кодом. В будь-який розробник може покращити код системи у будь-який час.

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

10. 40-hour week – 40 год. тиждень. Розробники працюють не більше 40 годин на тиждень.

11. On-line cuslomer – локальний замовник. В групі весь час повинен знаходиться представник замовника. Готовий співпрацювати з розробником.

12. Coding Standards – стандарти кодування. Повинні дотримуватися правила, які забезпечують однакові представлення програмного коду у всіх частинах ПС (програмні системи).

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

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

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

Основним засобом XP є метрика.

Середовище метрик – це велика візуальна діаграма. За звичай використовується 3-4 метрика, які бачить вся група.

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

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

У склад ітерації входить 3 фази:

1. Дослідження – пошук нових історій, які повинні виконати система.

2. Блокування – вибір для реалізації конкретної підмножини з всіх можливих вимог.

3. Регулювання – проведення розробки та втілення плану у життя.

XP рекомендує: перша реалізація повинна тривати 2-6 місяців, тривалість інших реалізацій близько 2-х місяців; кожна ітерація триває 2 тижні, чисельність групи розробників не перевищує 10 чоловік.