Ітераційні моделі розробки програмного забезпечення. Переваги та недоліки.
Описані моделі процесу створення ПЗ мають свої переваги і недоліки. При створенні великих систем, як правило, доводиться використовувати різні підходи до розробки різних частин системи, тобто в цілому до розробки системи застосовуються гібридні (змішані) моделі. Тому важливу роль відіграє можливість виконувати окремі процеси розробки підсистем і весь процес створення ПЗ ітераційно, коли у відповідь на зміни вимог повторно виконуються певні етапи створення системи (найчастіше етапи проектування та кодування).
Представлено 2 гібридні ітераційні моделі, що поєднують кілька різних підходів до розробки ПЗ і розроблені спеціально для підтримки ітераційного способу створення ПЗ.
Модель покрокової розробки, де процеси специфікації вимог, проектування та написання коду розбиваються на послідовність невеликих кроків, які ведуть до створення ПЗ.
Спіральна модель розробки, в якій весь процес створення ПЗ, від початкового ескізу системи до її кінцевої реалізації, розгортається по спіралі.
Істотною відмінністю ітераційних моделей є те, що тут процес розробки специфікації протікає паралельно з розробкою самої програмної системи. Більш того, в моделі покрокової розробки повну системну специфікацію можна отримати тільки після завершення самого останнього кроку процесу створення ПЗ. Очевидно, що такий підхід входить в протиріччя з моделлю придбання ПЗ, коли повна системна специфікація є складовою частиною контракту на розробку системи. Тому, щоб застосовувати ітераційні моделі для розробки великих систем, які замовляються "серйозними" організаціями, наприклад державними агентствами, необхідно змінювати форму контракту, на що такі організації йдуть з великими труднощами.
Модель покрокової розробки програмного забезпечення. Переваги та недоліки.
У каскадної моделі створення ПЗ визначення вимог здійснюється спільно з замовником до початку проектування системи, точно так само системна архітектура повинна бути створена до початку безпосередньої реалізації (кодування) системи. Зміни у вимогах, зроблені на етапі написання коду, ведуть до необхідності виконання повторних робіт з проектування та кодування системи. Разом з тим до достоїнств каскадної моделі можна віднести простоту управління процесом створення ПЗ (в рамках даної моделі), а також наявність окремих етапів проектування та реалізації, що призводить до створення цілком працездатних систем, в яких враховані всі зміни в специфікації, зроблені вже під час самого процесу розробки ПЗ. На відміну від каскадної, в еволюційній моделі можна відкласти прийняття остаточних рішень про специфікації і структурі системи, однак це може призвести до створення погано структурованої системи, яка буде також важка в супроводі.
Модель покрокової розробки знаходиться десь між цими моделями і об'єднує їх гідності. Ця модель (рис. 6) була запропонована Миллсом (Mills, [240]) як спроба зменшити кількість повторно виконуваних робіт у процесі створення ПЗ і збільшити для замовника часовий період остаточного прийняття рішення про всі деталі системних вимог.
У процесі покрокової розробки замовник спочатку в загальних рисах визначає ті сервіси (функціональні можливості), які повинні бути присутніми в створюваної системи. При цьому встановлюються пріоритети, тобто визначається, які сервіси більш важливі, а які - менш. Також визначається кількість кроків розробки, причому на кожному кроці повинен бути отриманий системний компонент, який реалізує певну підмножину системних функцій. Розподіл реалізації системних сервісів по кроках розробки залежить від їх пріоритетів. Сервіси з більш високими пріоритетами реалізуються першими.
Послідовність кроків розробки визначається заздалегідь до початку їх виконання. На перших кроках деталізуються вимоги для сервісів, потім для їх реалізації (на наступних кроках) використовується один з відповідних способів розробки ПЗ. У ході їх реалізації аналізуються і деталізуються вимоги для компонентів, які будуть розроблятися на більш пізніх етапах, причому зміна вимог для тих компонентів, які вже знаходяться в процесі розробки, не допускається.
Після завершення кроку розробки отримуємо програмний компонент, який передається замовнику для інтегрування в підсистему, що реалізовує певний системний сервіс. Замовник може експериментувати з готовими підсистемами і компонентами для того, щоб уточнити вимоги, пропоновані до наступних версіями вже готових компонентів або до компонентів, які розробляються на наступних кроках. По завершенні чергового кроку розробки отриманий компонент інтегрується з раніше виробленими компонентами; таким чином, після кожного кроку розробки система набуває все більшої функціональну завершеність. Загальносистемні функції в цьому процесі можуть реалізуватися відразу або поступово, у міру розробки необхідних компонентів.
У описуваної моделі не передбачається, що на кожному кроці використовується один і той же підхід до процесу розробки компонентів. Якщо створюваний компонент має добре розроблену специфікацію, то для його створення можна застосувати каскадну модель. Якщо ж вимоги визначені нечітко, можна використовувати еволюційну модель розробки.
Процес покрокової розробки має цілий ряд переваг.
1. Замовнику немає необхідності чекати повного завершення розробки системи, щоб отримати про неї уявлення. Компоненти, отримані на перших кроках розробки, задовольняють найбільш критичним вимогам (оскільки мають найбільший пріоритет) і їх можна оцінити на самій ранній стадії створення системи.
2. Замовник може використовувати компоненти, отримані на перших кроках розробки, як прототипи і провести з ними експерименти для уточнення вимог до тих компонентів, які будуть розроблятися пізніше.
3. Даний підхід зменшує ризик загальносистемних помилок. Хоча в розробці окремих компонентів можливі помилки, але ці компоненти повинні пройти відповідне тестування та атестацію, перш ніж їх передадуть замовнику.
4. Оскільки системні сервіси з високим пріоритетом розробляються першими, а всі наступні компоненти інтегруються з ними, неминуче виходить так, що найбільш важливі підсистеми піддаються більш ретельному всебічному тестуванню та перевірці. Це значно знижує ймовірність програмних помилок в особливо важливих частинах системи.
Разом з тим при реалізації покрокової розробки можуть виникнути певні проблеми. Компоненти, одержувані на кожному кроці розробки, мають відносно невеликий розмір (звичайно не більше 20 000 рядків коду), але повинні реалізувати яку-небудь системну функцію. Відобразити безліч системних вимог до компонентів потрібного розміру досить складно. Більш того, багато системи повинні мати набором базових системних властивостей, які реалізуються спільно різними частинами системи. Оскільки вимоги детально не визначені до тих пір, поки не будуть розроблені всі компоненти, буває вельми складно розподілити загальносистемні функції по компонентах.
В даний час запропонований метод так званого екстремального програмування (extreme programming), який усуває деякі недоліки методу покрокової розробки. Цей метод заснований на покрокової розробці малих програмних компонентів, що реалізують невеликі функціональні вимоги, постійному залученні замовника в процес розробки та знеособленому програмуванні (див. Главу 23). У статті [31] описаний метод екстремального програмування і наведено кілька звітів про його успішне застосування, проте подібні звіти можна привести для всіх основних методів розробки ПЗ.
Спіральна модель розробки програмного забезпечення. Переваги та недоліки.
Процес розробки вимог.
Методи інженерії програмного забезпечення.
Інструменти інженерії програмного забезпечення.
Инструменты
Программные инструменты предназначены для обеспечения процессов жизненного цикла программного обеспечения. В свою очередь, методы программной инженерии представляют соответствующие нотации, словари, процедуры и рекомендации по оценке проверки процесса и получаемого в его результате продукта.
Инструменты подразделяются на:
Инструменты для работы с требованиями:
Инструменты, применяемые для извлечения, анализа, специфицирования и проверки программных требований;
Инструменты трессировки требования, применяемые для предоставления отношений между требованиями различного уровня в системе.
Инструменты проектирования и конструирования, к ним относят инструменты, используемые для создания и проверки программного дизайна.
К инструментам конструирования относят инструменты, используемые для производства и трансляции программного представления, необходимого для машинного выполнения. К таким инструментам относятся:
Редакторы, применяемые для создания модификации исходного кода;
Компиляторы и генераторы кода, выполняющие покомандную трансляцию исходного кода;
Интерпретаторы, обеспечивающие выполнение программ посредством эмуляции;
Отладчики, предоставляющие средства для отладки исходного кода.
Дополнительно в не данной классификации следует выделить следующие инструменты:
Интегрирующие средства разработки;
Программные библиотеки и библиотеки компонент;
Программные платформы (java, Microsoft Net);
Платформа облачных вычислений;