Зміст
Введення
Класичний життєвий цикл
Макетування
Стратегії конструювання ПО
інкрементного модель
Висновок
Список літератури
Введення
Технологія конструювання програмного забезпечення (ТКПО) - система інженерних принципів для створення економічного ПЗ, яке надійно і ефективно працює в реальних комп'ютерах [64], [69], [71].
Розрізняють методи, засоби та процедури ТКПО.
Методи забезпечують вирішення наступних завдань:
В· планування та оцінка проекту;
В· аналіз системних і програмних вимог;
В· проектування алгоритмів, структур даних і програмних структур;
В· кодування;
В· тестування;
В· супровід.
Засоби (утиліти) ТКПО забезпечують автоматизовану чи автоматичну підтримку методів. З метою спільного застосування утиліти можуть об'єднуватися в системи автоматизованого конструювання ПЗ. Такі системи прийнято називати CASE-системами. Абревіатура CASE розшифровується як Computer Aided Software Engineering (Програмна інженерія з комп'ютерною підтримкою).
Процедури є "клеєм", який з'єднує методи і утиліти так, що вони забезпечують безперервну технологічний ланцюжок розробки. Процедури визначають:
В· порядок застосування методів і утиліт;
В· формування звітів, форм за відповідними вимогам;
В· контроль, який допомагає забезпечувати якість і координувати зміни;
В· формування "Віх", за якими керівники оцінюють прогрес.
Процес конструювання програмного забезпечення складається з послідовності кроків, що використовують методи, утиліти і процедури. Ці послідовності кроків часто називають парадигмами ТКПО.
Застосування парадигм ТКПО гарантує систематичний, впорядкований підхід до промислової розробки, використанню та супроводу ПЗ. Фактично, парадигми вносять в процес створення ПЗ організуючий інженерне початок, необхідність якого важко переоцінити.
Розглянемо найбільш популярні парадигми ТКПО.
Класичний життєвий цикл
Найстаршою парадигмою процесу розробки ПЗ є класичний життєвий цикл (автор Уїнстон Ройс, 1970) [65].
Дуже часто класичний життєвий цикл називають каскадної або водоспадні моделлю, підкреслюючи, що розробка розглядається як послідовність етапів, причому перехід на наступний, ієрархічно нижній етап відбувається тільки після повного завершення робіт на поточному етапі (рис. 1.1).
Охарактеризуємо зміст основних етапів.
Мається на увазі, що розробка починається на системному рівні і проходить через аналіз, проектування, кодування, тестування і супровід. При цьому моделюються дії стандартного інженерного циклу.
Системний аналіз задає роль кожного елемента в комп'ютерній системі, взаємодію елементів один з одним. Оскільки ПО є лише частиною великої системи, то аналіз починається з визначення вимог до всіх системним елементам і призначення підмножини цих вимог програмному "елементу". Необхідність системного підходу явно проявляється, коли формується інтерфейс ПЗ з іншими елементами (Апаратурою, людьми, базами даних). На цьому ж етапі починається рішення завдання планування проекту ПЗ. У ході планування проекту визначаються обсяг проектних робіт та їх ризик, необхідні трудовитрати, формуються робочі завдання і план-графік робіт.
Аналіз вимог відноситься до програмного елементу - програмному забезпеченню. Уточнюються і деталізуються його функції, характеристики та інтерфейс. Всі визначення документуються в специфікації аналізу. Тут же завершується вирішення задачі планування проекту.
Рис. 1.1. Класичний життєвий цикл розробки ПЗ
Проектування полягає в створенні уявлень:
В· архітектури ПЗ;
В· модульної структури ПЗ;
В· алгоритмічної структури ПЗ;
В· структури даних;
В· вхідного і вихідного інтерфейсу (вхідних та вихідних форм даних).
Вихідні дані для проектування містяться в специфікації аналізу, тобто в ході проектування виконується трансляція вимог до ПЗ у безліч проектних уявлень. При вирішенні завдань проектування основна увага приділяється якості майбутнього програмного продукту.
Кодування полягає в перекладі результатів проектування в текст на мові програмування.
Тестування - виконання програми для виявлення дефектів у функціях, логіці і формі реалізації програмного продукту.
Супровід - це внесення змін до експлуатоване ПО. Цілі змін:
В· виправлення помилок;
В· адаптація до змін зовнішнього для ПО середовища;
В· удосконалення ПО за вимогами замовника.
Супровід ПО складається в повторному застосуванні кожного з попередніх кроків (етапів) життєвого циклу до існуючої програмі, але не в розробці нової програми. Як і будь-яка інженерна схема, класичний життєвий цикл має гідності і недоліки.
Переваги класичного життєвого циклу: дає план і часовий графік по всіх етапах проекту, упорядковує хід конструювання.
Недоліки класичного життєвого циклу:
1. реальні проекти часто вимагають відхилення від стандартної послідовності кроків;
2. цикл заснований на точної формулюванні вихідних вимог до ПЗ (реально на початку проекту вимоги замовника визначені лише частково);
3. результати проекту доступні замовнику тільки в кінці роботи.
Макетування
Досить часто замовник не може сформулювати докладні вимоги по введенню, обробці або висновку даних для майбутнього програмного продукту. З іншого боку, розробник може сумніватися в приспосабливаемости продукту під операційну систему, формі діалогу з користувачем або в ефективності реалізованого алгоритму. У цих випадках доцільно використовувати макетування.
Основна мета макетування - зняти невизначеності у вимогах замовника.
Макетування (Прототипування) - це процес створення моделі необхідного програмного продукту.
Модель може приймати одну з трьох форм:
1. паперовий макет або макет на основі ПК (зображує чи малює людино-машинний діалог);
2. працюючий макет (Виконує деяку частину необхідних функцій);
3. існуюча програма (характеристики якої потім повинні бути поліпшені).
Як показано на рис. 1.2, макетування грунтується на багаторазовому повторенні ітерацій, в яких беруть участь замовник та розробник.
Рис. 1.2. Макетування
Послідовність дій при макетуванні представлена ​​на рис. 1.3.
Макетування починається зі збору й уточнення вимог до створюваного ПО. Розробник і замовник зустрічаються і визначають всі цілі ПО, встановлюють, які вимоги відомі, а які належить доопределить.
Потім виконується швидке проектування. У ньому увага зосереджується на тих характеристиках ПЗ, які повинні бути видимі користувачеві.
Швидке проектування приводить до побудови макета.
Макет оцінюється замовником і використовується для уточнення вимог до ПЗ.
Ітерації повторюються до тих пір, поки макет не виявить всі вимоги замовника і, тим самим, не дасть можливість розробнику зрозуміти, що повинно бути зроблено.
Гідність макетування: забезпечує визначення повних вимог до ПЗ.
Недоліки макетування:
В· замовник може прийняти макет за продукт;
В· розробник може прийняти макет за продукт.
Пояснимо суть недоліків. Коли замовник бачить працюючу версію ПО, він перестає усвідомлювати, що деталі макета скріплені "жувальною гумкою і дротом"; він забуває, що в гонитві за працюючим варіантом залишені невирішеними питання якості та зручності супроводу ПЗ. Коли замовнику кажуть, що продукт повинен бути перебудований, він починає обурюватися і ви...
