Каскадна модель

1.2.2. Неминучі повернення на попередні стадії в каскадній моделі

1.1. Визначення проекту і проектування. Основні особливості і проблеми сучасних програмних проектів

Основою проектування програмного забезпечення (ПЗ) є системний підхід. Системний підхід - це методологія дослідження об'єкту будь-якої природи як системи. Система - це сукупність взаємозв'язаних частин, які працюють спільно для досягнення деякого результату. Визначальна ознака системи - поведінка системи в цілому не може бути зведене до сукупності поведінки частин системи.

Програмне забезпечення - це система, яка включає: комп'ютерні програми; документацію; дані, необхідні для коректної роботи програм.

Проектування ПЗ - це процес створення специфікацій ПЗ на основі початкових вимог до нього.

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

ПЗ можна розбити на два класи: «мале» і «велике».

«Мале» програмне забезпечення має наступні характеристики:

Ø вирішує одну нескладну, чітко поставлену задачу;

Ø розмір початкового коду не перевищує декількох сотень рядків;

Ø швидкість роботи ПЗ і необхідні йому ресурси не грають великої ролі;

Ø збитки від неправильної роботи не мають великого значення;

Ø модернізація ПЗ, доповнення його можливостей потрібна рідко;

Ø зазвичай, розробляється одним програмістом або невеликою групою (5 або менш людей);

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

«Велике» програмне забезпечення має 2-3 або більше характеристик з наступного переліку:

Ø вирішує сукупність взаємозв'язаних завдань;

Ø використання приносить суттєву вигоду;

Ø зручність його використання грає важливу роль;

Ø обов'язкова наявність повної і зрозумілої документації;

Ø низька швидкість роботи приводить до втрат;

Ø збої, неправильна робота, завдає відчутного збитку;

Ø програми в складі ПЗ під час роботи взаємодіє з іншими програмами і програмно-апаратними комплексами;

Ø працює на різних платформах;

Ø потрібний розвиток, виправлення помилок, додавання нових можливостей;

Ø група розробників складається більше ніж з 5 чоловік.

Далі розглядається проектування «великого» ПО, оскільки створення «малого» не викликає великих труднощів, не вимагає спеціальної технології і інструментів.

Класифікація програмних проектів за розміром групи розробників і тривалістю проекту:

Ø невеликі проекти - проектна команда менше 10 чоловік, термін від 3 до 6 місяців;

Ø середні проекти - проектна команда від 20 до 30 чоловік, тривалість розробки проекту 1-2 року;

Ø великомасштабні проекти - проектна команда від 100 до 300 чоловік, тривалість розробки проекту 3-5 років;

Ø гігантські проекти - армія розробників від 1000 до 2000 чоловік і більш (включаючи консультантів і співвиконавців), тривалість розробки проекту від 7 до 10 років.

З кінця 60-х років минулого століття до сьогоднішніх днів триває так звана «криза ПЗ». Виражається вона в тому, що великі проекти виконуються з перевищенням кошторису витрат і/або термінів відведених на розробку, а розроблене ПЗ не володіє необхідними функціональними можливостями, має низьку продуктивність і якість. За наслідками досліджень американської індустрії розробки ПЗ, виконаних в 1995 році Standish Group (www.standishgroup.com), тільки 16% проектів завершилися в строк, не перевищили запланований бюджет і реалізували всі необхідні функції і можливості. 53% проектів завершилися із запізненням, витрати перевищили запланований бюджет, необхідні функції не були реалізовані в повному об'ємі. 31% проектів були анульовані до завершення.

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

Роки
31% анулюються до завершення	28%	23%	18%
53% перевищують обумовлені терміни та заплановані витрати і не реалізують у повному обсязі бажані функції	46%	49%	53%
16% завершаються у термін	26%	28%	29%

Причини невдач:

Ø нечітке і неповне формулювання вимог;

Ø недостатнє залучення користувачів до роботи над проектом;

Ø відсутність необхідних ресурсів;

Ø незадовільне планування і відсутність грамотного управління проектом;

Ø часта зміна вимог і специфікацій;

Ø новизна і недосконалість використовуваної технології;

Ø недостатня підтримка з боку вищого керівництва;

Ø недостатньо висока кваліфікація розробників, відсутність необхідного досвіду.

При плануванні проектів часто з тих або інших причин встановлюються нездійсненні терміни, закладаються недостатні ресурси. Таким чином, виникають безнадійні проекти (death march projects). Ознаки безнадійного проекту:

Ø план проекту стислий більш ніж наполовину у порівнянні з нормальним розрахунковим планом;

Ø кількість розробників зменшена більш ніж наполовину у порівнянні з дійсно потрібним для проекту заданого розміру і масштабу;

Ø бюджет і пов'язані з ним ресурси урізані наполовину;

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

Іншою причиною невірного планування є помилка щодо продуктивності проектувальників. У великому проекті загальна продуктивність групи розробників не дорівнює сумі продуктивностей окремих членів групи (порахованої начебто вони працювали поодинці). Згідно Бруксу у книзі «Мифический человеко-месяц»

Ø найчастіша причина провалу - брак часу;

Ø іноді роботи не можна прискорити, не зіпсувавши результат;

Ø людино-місяць - небезпечна помилка, оскільки передбачається, що кількість людей і місяці можна поміняти місцями;

Ø розділення завдання між декількома людьми викликає накладні витрати;

Ø якщо проект не укладається в строк, то додавання людей затримає його ще більше;

Ø «срібної кулі» немає!

Останнє положення стосується технології розробки. Брукс стверджує, що технології, яка дозволяє на порядок підвищити продуктивність розробників, не існує. Тобто, не можна вважати, що яка-небудь новітня технологія розробки дозволить здійснити проект в 10 разів швидше.

Особливості сучасних проектів ПЗ:

Ø складність - невід'ємна характеристика створюваного ПО;

Ø відсутність повних аналогів і висока частка ПЗ, яке розробляється з нуля;

Ø наявність успадкованого ПЗ і необхідність його інтеграції з розроблюваним ПЗ;

Ø територіально розподілене і неоднорідне середовище функціонування;

Ø велика кількість учасників проектування, роз'єднаність і різнорідність окремих груп розробників за рівнем кваліфікації і досвіду.

Розробка ПЗ має наступні специфічні особливості:

Ø неформальний характер вимог до ПЗ і формалізований основний об'єкт розробки - програми;

Ø творчий характер розробки;

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

Ø при своєму використанні (експлуатації) ПЗ не витрачається і не зношується;

Ø «невідчутність», «легкість» ПЗ, що підштовхує до безвідповідального перероблення, оскільки легко стерти і переписати, чого не зробиш при проектуванні будівель і апаратури.

Шляхом виходу з кризи ПЗ стало створення програмної інженерії (software engineering). Інженерія ПЗ (software engineering) - сукупність інженерних методів і засобів створення ПЗ. Фундаментальна ідея програмної інженерії: проектування ПЗ є формальним процесом, який можна вивчати і удосконалювати.

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

Етапи становлення і розвитку SE:

Ø 70-і і 80-і роки - систематизація і стандартизація процесів створення ПЗ (структурний підхід);

Ø 90-і роки - початок переходу до складального, індустріального способу створення ПЗ (об'єктно-орієнтований підхід).

Програмна інженерія застосовується для задоволення вимог замовника ПЗ. Основні цілі програмної інженерії:

1. Системи повинні створюватися в короткі терміни і відповідати вимогам замовника на момент впровадження.

2. Якість ПЗ повинно бути високою.

3. Розробка ПЗ повинна бути здійснена в рамках виділеного бюджету.

4. Системи повинні працювати на устаткуванні замовника, а також взаємодіяти з наявним ПЗ.

5. Системи повинні бути легко супроводжуваними і масштабованими.

1.2. Життєвий цикл програмного забезпечення. Стандарти, які регламентують життєвий цикл

Основним поняттям програмної інженерії є поняття життєвого циклу ПЗ. Життєвий цикл ПЗ (software lifecycle) - це період часу, який починається з моменту ухвалення рішення про необхідність створення ПЗ і закінчується у момент його повного вилучення з експлуатації.

Основний нормативний документ, який регламентує ЖЦ ПЗ - стандарт ISO/IEC 12207: 1995 “Information Technology - Software Life Cycle Processes”. У рамках технологій створення ПЗ поняття ЖЦ уточнюється, але вказані стандарти не порушуються.

З погляду статичної структури ЖЦ є сукупністю процесів ЖЦ.

Процес ЖЦ - набір взаємозв'язаних дій, які перетворюють деякі вхідні дані і ресурси у вихідні.

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

Ø основні (придбання, постачання, розробка, експлуатація, супровід);

Ø допоміжні (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, сумісна оцінка, аудит, розв’язання проблем);

Ø організаційні (управління, створення інфраструктури, удосконалення, навчання).

Для ознайомлення приведемо зміст процесів ЖЦ.

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

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

Процес розробки включає наступні дії: підготовчу роботу; аналіз вимог до ПЗ; проектування архітектури ПЗ; детальне проектування ПЗ; кодування ПЗ; тестування ПЗ; інтеграцію ПЗ; встановлення ПЗ; приймання ПЗ. Дійові особи: розробник, замовник. Завдання розробки: вибір моделі ЖЦ ПЗ і узгодження із замовником; визначення вимог до ПЗ (функціональних і нефункціональних); визначення складу компонентів ПЗ і створення документації по кожному компоненту; моделювання і специфікація компонент ПЗ; планування інтеграції компонент; створення початкових текстів компонент; пошук і виправлення помилок у початкових текстах і документації; збирання ПЗ; розгортання ПЗ; оцінка результатів.

Процес експлуатації включає наступні дії: підготовчу роботу; експлуатаційне тестування; експлуатацію; підтримку користувачів. Дійові особи: оператор (організація, яка експлуатує ПЗ), користувачі. Завдання експлуатації: вироблення плану експлуатації і експлуатаційних стандартів; складання процедур локалізації і розв’язання проблем експлуатації; пошук помилок у ПЗ перед введенням в експлуатацію його нових версій; надання допомоги користувачам і консультування.

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

Процес документування включає наступні дії: підготовчу роботу; проектування і розробку документації; випуск документації; супровід.

Процес управління конфігурацією включає в себе наступні дії: підготовчу роботу; створення бази знань про ПЗ (конфігурації); контроль за конфігурацією; облік стану конфігурації; оцінку конфігурації; управління випуском і постачання ПЗ. Конфігурація ПЗ - це сукупність відомостей про його функціональні і фізичні характеристики на всіх стадіях ЖЦ ПЗ. Основне завдання управління конфігурацією: організація, систематичний облік і контроль внесення змін в ПЗ.

Процес забезпечення якості включає наступні дії: підготовчу роботу; забезпечення якості продукту; забезпечення якості процесу; забезпечення інших показників якості ПЗ.

Завдання забезпечення якості: гарантована відповідність ПЗ вимогам замовника, зафіксованих в договорі; гарантовану відповідність процесів ЖЦ ПЗ, методів розробки, кваліфікації персоналу встановленим стандартам.

Процес верифікації включає наступні дії: підготовчу роботу; верифікацію. Основне завдання верифікації - перевірка відповідності розроблених програм у складі ПЗ їх специфікаціям.

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

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

Процес аудиту полягає у визначенні повноти відповідності проекту умовам договору.

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

Процес управління включає наступні дії: підготовчу роботу; планування; виконання і контроль; перевірку і оцінку; завершення. Завдання управління: перевірка достатності наявних ресурсів; складання графіків робіт; оцінка витрат; виділення ресурсів; розподіл відповідальності; оцінка ризиків.

Процес створення інфраструктури полягає у виборі і підтримці технології розробки ПЗ, стандартів і інструментальних засобів; виборі і встановленні апаратних і програмних засобів, необхідних для розробки, експлуатації і супроводу ПЗ.

Процес удосконалення передбачає оцінку, вимірювання, контроль і удосконалення процесів ЖЦ ПЗ. Основне завдання удосконалення - підвищення продуктивності праці.

Процес навчання включає наступні дії: підготовчу роботу; розробку учбових планів, курсів, матеріалів; реалізацію планів навчання. Завдання навчання: первинне навчання персоналу; підвищення кваліфікації персоналу.

Процеси ЖЦ ПЗ взаємозв'язані.

Динаміку, тобто розвиток ЖЦ у часі визначає модель життєвого циклу.

Модель ЖЦ ПЗ - це структура, яка визначає послідовність виконання і взаємозв'язку процесів, дій і завдань впродовж всього ЖЦ.

У будь-якій моделі ЖЦ розглядається як сукупність стадій ЖЦ.

Стадія ЖЦ - це частина ЖЦ обмежена часовими рамками, після закінчення якої досягається певний важливий результат у відповідності до вимог для даної стадії ЖЦ.

Моделі ЖЦ:

Ø каскадна (водоспад);

Ø еволюційна;

Ø заснована на формальних перетвореннях;

Ø ітераційні (покрокова і спіральна).

Дата добавления: 2014-01-07