ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

- розроблялося дуже велике за обсягом програмне забезпечення, характерним представником якою була тоді операційна система OS360 для ЕОМ серії IBM. Це програмне забезпечення містило більше 500 тис. операторів і розроблялося значним, для того часу, колективом розробників (близько 1000). Досвід цього проекту був узагальнений і став відомий;

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

- часті зриви термінів розробки і перевищення бюджету потре­ бували не тільки нового підходу до організації процесу розробки, але і нових методів і засобів, що забезпечують обґрунтований розрахунок параметрів проекту, які характеризували фінансування, терміни, об'єми програмного забезпечення, кількісний і якісний склад колективу розробників. Існуюча і широко використовувана одиниця вимірювання - «людино-місяць» не працювала на таких масштабних проектах;

- досвід розробки програмного забезпечення, який нагромаджений за цей період, показав, що все рідше розроблялися принципово нові проекти. Лише 15% усіх проектів потребували розробки «з нуля». Нині 85% належать до проектів, що повторюються. Тому актуальним стає використання досвіду, нагромадженого в програмному забезпеченні До того ж, поступово стало зрозуміло, що має вирішуватися завдання використання досвіду не лише безпосередньо програмування, у вигляді частин програм, але і досвіду результатів виконання інших процесів, наприклад, проектування. Для вирішення цього завдання в 1984 р. були широко розгорнені роботи з дослідження програмного забезпечення в аспекті повторного використання (reuse);

- техніка програмування і процеси, що були ефективні в 50-х і ранніх 60-х pp. XX ст. («програмування в малому») для розробки невеликих програм малими колективами, стали неефективними при розробці великого за обсягом, складного програмного забезпечення, що складається з мільйонів рядків коду, та вимагає декількох років роботи сотень фахівців різних спеціальностей. Були потрібні нові технології, що почали вважати «програмуванням у великому».

Почали з'являтися нові процеси, що потребували певної організації (табл.1.1). Таким чином, склалася ситуація, яка призвела до кризи в програмному забезпеченні і необхідності пошуку шляхів виходу з неї, так званої «срібної кулі». Виходом з цієї ситуації стало обговорення на конференції NATO в 1968 р. нової дисципліни, яку назвали «інженерія програмного забезпечення» (software engineering). До того ж, уперше акценти в методах, засобах і процесах розробки програмного забезпечення були зміщені: по-перше, з кодування програм на інші процеси їх розробки, а по-друге, з якісних аспектів у бік кількісних, інженерних. Окрім цього, додатковий стимул отримали ті, хто виконував наукові і практичні роботи з економічного напряму і менеджменту проектів програмного забезпечення.

Таблиця 1.1

Періоди розвитку	1960±5 років програмування "any-wich-way"	1970±5 років «програмування в малому»	1980±5 ро­ків «програму­вання у ве­ликому»
Об'єкти порівняння
Об'єкти	Маленькі програми	Алгоритми і програми	Системна структура
Дані	Неструктурована інформація	Структури даних	Бази даних
		і типи
Управління	Елементарне ро­зуміння діаграм управління	Програми виконуються і закін­чуються	Програми, що безпере­рвно вико­нуються
Простір етанів	Стан, що погано розуміється окре­мо від управління	Маленькі, прості	Великі,
			структуризовані
Організаційне управління	Немає	Індивідуальні зусилля	Колективні
			зусилля,
			супровід
Інструмент»	Асемблери	Компілятори, редактори, заван­тажувачі	Середовища, інтегровані інстру­менти

1.2. Інженерія програмного забезпечення - інженерна галузь

Інженерна галузь характеризується діяльністю, що ґрунтується на таких принципах:

- ефективність - результати отримують за допомогою заданих ресурсів, які відповідають висунутим вимогам і стандартам;

- практичність - результати мають конкретних замовників;

- фундаментальність - результати отримують на основі знань фундаментальних наук;