Об’єктно-орієнтований аналіз і проектування

Лекція №1. Основи програмної інженерії

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

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

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

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%. Останніми роками процентне співвідношення трьох перерахованих категорій проектів трохи змінюється в кращу сторону.

Роки
1995	1998	2000	2004
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. Системи повинні бути легко супроводжуваними і масштабованими.