Виконання оцінки в ході керівництва проектом розробки програмного забезпечення концерну суперавто

ДЕРЖАВНА освітня установа вищої професійної освіти
Ставропольський ДЕРЖАВНИЙ АГРАРНИЙ УНІВЕРСИТЕТ
Курсова робота
на тему: «Виконання оцінки в ході керівництва проектом розробки програмного забезпечення концерну" суперавто "»
З дисципліни «Розробка і стандартизація програмних засобів та інформаційних технологій»
Виконала студентка 4 курсу, 7 групи
Спеціальність: Прикладна інформатика
(В галузі економіки)
Тарасова Анастасія Сергіївна
Перевірив: д.т.н., доц. кафедри
Прикладної інформатики
Канівець В.Ю.
Ставрополь, 2006

Введення
Відомо, що основним завданням перших трьох десятиліть комп'ютерної ери було розвиток апаратних комп'ютерних засобів. Сучасний персональний комп'ютер тепер має продуктивність великої ЕОМ 80-х років. Зняті практично всі апаратні обмеження на вирішення завдань. Решту обмежень припадають на частку ПЗ.
Надзвичайно актуальними стали наступні проблеми:
1. апаратна складність випереджає наше вміння будувати ПЗ, що використовує потенційні можливості апаратури;
2. наше вміння будувати нові програми відстає від вимог до нових програм;
3. нашим можливостям експлуатувати існуючі програми загрожує низька якість їх розробки.
Ключем до вирішення цих проблем є грамотна організація процесу створення ПЗ, реалізація технологічних принципів промислового конструювання програмних систем (ПС).
Комп'ютерні науки взагалі і програмна інженерія зокрема - дуже популярні і стрімко розвиваються галузі знань. Обгрунтування просте: людське суспільство XXI століття - інформаційне суспільство. Про це говорять цифри: у провідних країнах зайнятість населення в інформаційній сфері становить 60%, а в сфері матеріального виробництва - 40%. Саме тому спеціальності напряму «Комп'ютерні науки та інформаційні технології» гарантують придбання найбільш престижних, дефіцитних і високооплачуваних професій. Так вважають в усіх розвинутих країнах світу. Адже не даремно стверджують: «Хто володіє інформацією - той володіє світом!»
Тому зрозуміло те пильну увагу, яку приділяє комп'ютерному утворення світове співтовариство, зрозуміло прагнення уніфікувати і упорядкувати знання, необхідні фахівцеві цього напрямку. Одними з результатів такої роботи є міжнародний стандарт з комп'ютерного утворення Computing Curricula 2001 - Computer Science і міжнародний стандарт з програмної інженерії IEEE / ACM Software Engineering Body of Knowledge SWEBOK 2001.
Для проведення успішного проекту потрібно зрозуміти обсяг майбутніх робіт, можливий ризик, необхідні ресурси, майбутні завдання, прокладаються віхи, необхідні зусилля (вартість), план робіт, яким необхідно дотримуватися. Керівництво програмним проектом забезпечує таке розуміння. Воно починається перед технічною роботою, продовжується в міру розвитку ПЗ від ідеї до реальності і досягає найвищого рівня до кінця робіт.
Перед плануванням проекту слід:
1. встановити цілі та проблемну область проекту;
2. обговорити альтернативні рішення;
3. виявити технічні й управлінські обмеження.
При плануванні програмного проекту треба оцінити людські ресурси (в людино-місяцях), тривалість (у календарних датах), вартість (у тисячах доларів). Зазвичай виходять з минулого досвіду. Якщо новий проект за розміром і функцій схожий на попередній проект, цілком імовірно, що будуть потрібні такі ж ресурси, час і гроші.
У даній роботі використовуються розмірно-орієнтовані метрики за-трат. Розмірно-орієнтовані метрики прямо вимірюють програмний продукт і процес його розробки. Грунтуються розмірно-орієнтовані метрики на LOC-оцінках (Lines Of Code). LOC-оцінка - це кількість рядків у програмному продукті. Мета цієї діяльності - сформувати попередні оцінки, які дозволять:
• пред'явити замовнику коректні вимоги по вартості і витрат на розробку програмного продукту;
• скласти план програмного проекту.
У курсовій роботі для оцінювання витрат використовується також модель COCOMO II. Автор оригінальної моделі - Баррі Боемі. СОСОМО II - авторитетна і багатопланова модель, що дозволяє вирішувати найрізноманітніші завдання управління програмним проектом. Фактори витрат роблять істотний вплив на вихідні параметри програмного проекту.
У курсовій роботі для оцінки програмного продукту використовується модель етапу постархітектури, що є подмоделей СОСОМО II. Модель етапу постархітектури використовується в період, коли вже сформована архітектура і виконується подальша розробка програмного продукту.
Далі наведена попередня оцінка програмного проекту на основі LOC-метрик; розрахунки витрат на розробку ПЗ, вартості проекту, тривалості його розробки на основі моделі етапу постархітектури конструктивної моделі вартості СОСОМО II.

Завдання № 1
Виконати попередню оцінку програмного проекту на основі LOC - метрик.
Надійшло замовлення на розробку ПЗ від концерну «суперавто». Слід створити ПЗ для робочої станції дизайнера автомобіля. Виконуючи попередню оцінку програмного проекту на основі LOC - метрик, будемо виходити з початкових даних оцінки проекту (табл.1) і даних з метричного базису фірми (табл.2).
Таблиця1 - Початкові оцінки проекту
Таблиця 2 - Дані з метричного базису фірми

Вихідні формули для розрахунку показників:
QUOTE (1)
QUOTE (2)
QUOTE (3)
QUOTE (4)
Тепер ми маємо всі необхідні дані для завершення розрахунків. Заповнимо до кінця таблицю оцінки нашого проекту (табл. 3).
Таблиця 3 - Попередня оцінка програмного проекту

Функція	Краща (LOC)	Ймовірна (LOC)	Гірша (LOC)	Очікувана (LOC)	Уд. Ст-ть ($ / LOC)	Ст-ть ($)	Пріозводі ність (LOC / люд.-міс.)	Витрати (люд.-міс.)
Супі	700	1500	2650	1558	18	28050	489	3
А2Г	2900	3200	7400	3850	22	84700	245	16
А3Г	300	5100	8600	4883	22	107433	193	25
УБС	2800	3800	4100	3683	16	58933	243	15
КДГ	4050	5900	6500	5692	24	136600	125	45
УП	2000	2250	3100	2350	26	61100	137	17
МПА	5900	8500	9100	8167	16	130667	351	23
Разом:				30183		607483		145

З таблиці. 3 видно, що найбільшу питому вартість має рядок функції управління периферією (потрібні специфічні і конкретні знання з різноманітних периферійних пристроїв), найменшу питому вартість - рядок функції управління для користувача інтерфейсом (застосовуються широко відомі рішення). Також слід зауважити, що, незважаючи на те, що функція управління для користувача інтерфейсом має найнижчу вартість, вона ж має найвищу продуктивність. Абсолютно протилежними властивостями володіє функція управління периферією.
Попередня оцінка програмного продукту дає нам наступні результати: очікувана кількість рядків програмного продукту склало
30183 LOC, вартість продукту становитиме 607483 $, а витрати - 145 чол. - Міс.
Завдання № 2
Використовуючи модель етапу пост - архітектури конструктивної моделі COCOMO II визначити:
· Витрати на розробку ПЗ;
· Вартість проекту;
· Тривалість розробки проекту.
Надійшло замовлення на розробку ПЗ від концерну «суперавто». Слід створити ПЗ для станції дизайнера автомобіля.
Автоматична генерація коду та повторне використання компонентів не передбачаються.
Середня заробітна плата в команді передбачається 6200 $ в місяць. Також відомі оцінка масштабних факторів (табл.4) і оцінка пост - архітектурних факторів витрат (табл.5).
Таблиця 4 - оцінка масштабних факторів

Масштабний фактор Wi	Значення
PREC	3
FLEX	1
RESEL	4
TEAM	3
PMAT	1
У	1,13

Знаючи оцінку пост - архітектурних факторів витрат для проекту, в табл. 5 внесемо значення множників формувачів витрат для кожної функції. У табл. 5 також вкажемо множник поправки ( ), Який визначається за формулою:

де:
EM _i - формувач витрат.
Таблиця 5 - Оцінка пост - архітектурних факторів витрат

Фактор	Опис	Оцінка	Множник
RELY	Необхідна надійність ПЗ	Номінальна	1
DATA	Розмір бази даних	Низька	0.93
CPLX	Складність продукту	Дуже висока	1.3
RUSE	Необхідна повторна використовуванність	Низька	0.91
DOCU	Документування життєвого циклу	Номінальна	1
TIME	Обмеження часу виконання	Висока	1.1
STOR	Обмеження оперативної пам'яті	Висока	1.06
PVOL	Мінливість платформи	Номінальна	1
ACAP	Можливості аналітика	Низька	1.22
PCAP	Можливості програміста	Низька	1.16
AEXP	Досвід роботи з додатком	Номінальна	1
PEXP	Досвід роботи з платформою	Низька	1.12
LTEX	Досвід роботи з мовою і утилітами	Номінальна	1
PCON	Безперервність персоналу	Висока	0.92
TOOL	Активне використання програмних утиліт	Висока	0.86
SITE	Мультісетевая розробка	Низька	1.1
SCED	Необхідний графік розробки	Номінальна	1
Множник поправки Мр			1.77

Використовуючи модель етапу пост-архітектури конструктивної моделі вартості СОСОМО II, визначимо:
- Витрати на розробку ПЗ;
- Вартість проекту;
- Тривалість розробки проекту.
Зробимо розрахунок витрат на розробку ПЗ, застосовуючи формулу (6):
^{, (6)}
де:
А = 2,5 (const)
B - показник ступеня;
(7)
де:
- Масштабний фактор, зазначений у табл. 4;
: PREC (передбачуваність) - відбиває досвід організації в реалізації проектів даного типу;
: FLEX (гнучкість розробки) - відбиває ступінь гнучкості процесу розробки;
: RESL (ризик) - відображає ступінь виконуваного аналізу ризику;
: TEAM (зв'язаність групи) - відображає, наскільки добре розробники групи знають один одного і наскільки вдало разом працюють;
: PMAT (зрілість процесу) - означає зрілість процесу в організації;
- Коефіцієнт, що враховує можливі зміни вимог;

^{, (8)}
де BRAK - відсоток коду, відкинутого (модифікованого) через зміну вимог;
, ⁽⁹⁾
де:
- Розмір нового, створюваного програмного коду;
; (10)
, (11)
де:
KASLOC - кількість рядків повторно використовуваного коду, який повинен бути модифікований;
AT - відсоток автоматично генерується коду;
АА - фактор, що відображає рішення про те, чи може програмне забезпечення бути повторно використовуваним;
SU - фактор, заснований на вартості додається програмного забезпечення;
D М - відсоток модифікуються проектних модулів;
СМ - відсоток модифікує програмного коду;
IM - відсоток витрат, необхідних для підключення повторно використовуваного програмного забезпечення;
М p - множник поправки, зазначений у табл. 5;
ВИТРАТИ _auto - Витрати на автоматичну генерацію коду;

, (12)
де ATPROD - продуктивність автоматичної генерації коду.
Виходячи з того, що автоматична генерація коду та повторне використання його компонентів не передбачаються, маємо: = 0 і . Розрахунок витрат наведено в табл. 6:
Таблиця 6 - Розрахунок витрат програмного проекту

A	2,5
Розмір new = KLOC ожид	30,183
Розмір reuse	0
Розмір (KLOC)	30,183
Розмір В (KLOC)	47,00
B	1,13
М р	1,77
Brak	5
K req	1,05
Витрати auto	0
Витрати (осіб / міс.)	218

Зробимо розрахунок вартості розробки програмного проекту, скориставшись формулою (13). Результати обчислень вартості зведемо в табл. 7.
Вартість = , (13)
де - Середня заробітна плата в команді.
Таблиця 7 - Розрахунок вартості програмного проекту

Витрати (чол. / міс.)	218
Робочий коефіцієнт	6700
Вартість, $	1460600

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

Витрати (люд.-міс.)	218,00
Необхідний графік розробки (SCED)	1,00
У	1,13
Витрати 0,33 +0,2 * (B-1, 01)	6,73
Тривалість (люд.-міс.)	0,20

Таким чином, можна зробити висновок, що витрати на розробку ПО складають 218,00 (чол.-міс.), Вартість проекту дорівнює 1460600 $, а тривалість розробки даного проекту склала 0,20 (міс.), тобто 6 днів. Такі стартові умови програмного проекту.
Завдання № 3
Визначення виграшу (програшу) у вартості проекту на розробку програмного забезпечення концерну "суперавто" за допомогою моделі СОСОМО II та з урахуванням зміни зарплати і можливостей співробітників. Замовник вирішив підвищити зарплату розробників. Причина - підвищення кваліфікації аналітика і програміста. У підсумку зарплата співробітників підвищується до 7000 $. Оцінки їх Можливість стають номінальними, тобто EM _ACAP = EM _PCAP = 1. Потрібно визначити виграш (програш) у вартості проекту.

Враховуючи зміни оцінки можливостей аналітика і програміста, зробимо розрахунок множника поправки (формула 5). Отримані дані внесемо в табл. 9.
Таблиця 9 - Оцінка пост-архітектурних факторів витрат з урахуванням змін можливостей аналітика і програміста

Фактор	Опис	Оцінка	Множник
RELY	Необхідна надійність ПЗ	Номінальна	1
DATA	Розмір бази даних	Низька	0.93
CPLX	Складність продукту	Дуже висока	1.3
RUSE	Необхідна повторна використовуванність	Низька	0.91
DOCU	Документування життєвого циклу	Номінальна	1
TIME	Обмеження часу виконання	Висока	1.1
STOR	Обмеження оперативної пам'яті	Висока	1.06
PVOL	Мінливість платформи	Номінальна	1
ACAP	Можливості аналітика	Номінальна	1
PCAP	Можливості програміста	Номінальна	1
AEXP	Досвід роботи з додатком	Номінальна	1
PEXP	Досвід роботи з платформою	Низька	1.12
LTEX	Досвід роботи з мовою і утилітами	Номінальна	1
PCON	Безперервність персоналу	Висока	0.92
TOOL	Активне використання програмних утиліт	Висока	0.86
SITE	Мультісетевая розробка	Низька	1.1
SCED	Необхідний графік розробки	Номінальна	1
Множник поправки Мр			1.25

Користуючись формулами (5-13), аналогічно виробляємо розрахунок витрат та вартості програмного продукту, зі зміненим сценарієм розробки. Наслідком такого рішення є зміна множника поправки Мр = 1,25, а також витрат і вартості:
ВИТРАТИ = 154 чол.-міс.;
ВАРТІСТЬ = 1078000 $;
Отримані значення витрат відображено в табл. 10.

Таблиця 10 - Розрахунок витрат проекту Програми з урахуванням змін можливостей аналітика і програміста
Отримані значення вартості, а також зміни у вартості у зв'язку з урахуванням зміни обмеження оперативної пам'яті (виграш у вартості = 1078000 - 1460600 = -382600 ($)) відображені в табл. 11.
Таблиця 11 - Розрахунок вартості розробки проекту і змін у вартості з урахуванням змін можливостей аналітика і програміста
Таким чином, замовник, підвищуючи заробітну плату розробників проекту до 7000 $, одержує вартість проекту 1078000 $, ця вартість на багато нижче вартості, яка була отримана при первісній заробітної плати 6700 $. Різке зниження вартості проекту відбувається за рахунок зменшення значень множників можливостей аналітика і програміста. Наслідком такого рішення є зниження множника поправки Мр = 1,25, а також витрат і, отже, вартості. Тобто замовник з таким сценарієм розробки залишається у виграші.

Завдання № 4
Визначення виграшу (програшу) у вартості проекту на розробку програмного забезпечення концерну "суперавто" за допомогою моделі СОСОМО II та з урахуванням зміни обмеження пам'яті ОЗУ. Розробник запропонував наростити пам'ять - купити за 1100 $ чіп ОЗУ місткістю 96 Кбайт (замість 64 Кбайт). Це змінює обмеження пам'яті. У результаті фактор STOR стає номінальним. Потрібно визначити виграш або програш у вартості проекту. Таким чином, EM _STOR = 1. Враховуючи зміни оцінки в обмеження оперативної пам'яті, зробимо розрахунок множника поправки (формула 5). Отримані дані внесемо в таблицю 12.
Таблиця 12 - Оцінка пост-архітектурних факторів витрат з урахуванням зміни оцінки обмеження оперативної пам'яті

Фактор	Опис	Оцінка	Множник
RELY	Необхідна надійність ПЗ	Номінальна	1
DATA	Розмір бази даних	Низька	0,93
CPLX	Складність продукту	Дуже висока	1,3
RUSE	Необхідна повторна використовуванність	Низька	0,91
DOCU	Документування життєвого циклу	Номінальна	1
TIME	Обмеження часу виконання	Висока	1,1
STOR	Обмеження оперативної пам'яті	Номінальна	1
PVOL	Мінливість платформи	Номінальна	1
ACAP	Можливості аналітика	Низька	1,22
PCAP	Можливості програміста	Низька	1,16
AEXP	Досвід роботи з додатком	Номінальна	1
PEXP	Досвід роботи з платформою	Низька	1,12
LTEX	Досвід роботи з мовою і утилітами	Номінальна	1
PCON	Безперервність персоналу	Висока	0,92
TOOL	Активне використання програмних утиліт	Висока	0,86
SITE	Мультісетевая розробка	Низька	1,1
SCED	Необхідний графік розробки	Номінальна	1
Множник поправки Мр			1,67

Користуючись формулами (5-10), аналогічно виробляємо розрахунок витрат та вартості програмного продукту, зі зміненим сценарієм розробки. Наслідком такого рішення є зниження множника поправки M _p = 1,67, а також витрат і вартості:
ВИТРАТИ = 206 чол.-міс.;
ВАРТІСТЬ 2 = 1380200 $;
Таблиця 13 - Розрахунок витрат проекту Програми з урахуванням зміни обмеження оперативної пам'яті
Отримані значення вартості, а також зміни у вартості у зв'язку з урахуванням зміни обмеження оперативної пам'яті (виграш у вартості = 1380200 - 1460600 = -80400 ($)) відображені в таблиці 14.
Таблиця 14 - Розрахунок вартості розробки проекту і змін у вартості з урахуванням зміни обмеження оперативної пам'яті
Таким чином, розробник, пропонуючи наростити пам'ять ОЗУ до 96 Кбайт замість 64 Кбайт, провокує зменшення вартості проекту. Таке зниження вартості проекту відбувається за рахунок зменшення значення множника обмеження оперативної пам'яті. Наслідком такого рішення є зменшення множника поправки Мр = 1,67, а також витрат і, отже, вартості. Тобто замовник, прийнявши пропозицію розробника з таким сценарієм розробки, зможе заощадити 80400 $.
Завдання № 5
Визначення виграшу (програшу) у вартості проекту на розробку програмного забезпечення концерну "суперавто" за допомогою моделі СОСОМО II та з урахуванням зміни досвіду роботи з мовою і утилітам, а також зміни активного використання програмних утиліт. Замовник запропонував використовувати новий, більш дешевий мікропроцесор (дешевше на 1000 $).
При цьому досвід роботи з мовою і утилітами, а також активне використання програмних утиліт знижується до дуже низького. Необхідно визначити виграш або програш у вартості проекту. Досвід роботи з його мовою і утилітами знижується до дуже низького і EM _LTEX ⁼ 1,22, а розроблені для нього утиліти (компілятори, асемблери і отладчики) примітивні і ненадійні (в результаті фактор TOOL знижується від високого до дуже низького і EM _{ТОО L} = 1,24).
Розрахуємо множник поправки (формула 5).
Таблиця 15 - Оцінка пост - архітектурних факторів витрат з урахуванням змін досвіду роботи з утилітами та мовою, а також змін активного використання програмних утиліт

Фактор	Опис	Оцінка	Множник
RELY	Необхідна надійність ПЗ	Номінальна	1
DATA	Розмір бази даних	Низька	0.93
CPLX	Складність продукту	Дуже висока	1.3
RUSE	Необхідна повторна використовуванність	Низька	0.91
DOCU	Документування життєвого циклу	Номінальна	1
TIME	Обмеження часу виконання	Висока	1.1
STOR	Обмеження оперативної пам'яті	Висока	1.06
PVOL	Мінливість платформи	Номінальна	1
ACAP	Можливості аналітика	Низька	1.22
PCAP	Можливості програміста	Низька	1.16
AEXP	Досвід роботи з додатком	Номінальна	1
PEXP	Досвід роботи з платформою	Низька	1.12
LTEX	Досвід роботи з мовою і утилітами	Дуже низька	1.22
PCON	Безперервність персоналу	Висока	0.92
TOOL	Активне використання програмних утиліт	Дуже низька	1.24
SITE	Мультісетевая розробка	Низька	1.1
SCED	Необхідний графік розробки	Номінальна	1
Множник поправки Мр			3.11

Користуючись формулами (5-10), аналогічно виробляємо розрахунок витрат та вартості програмного продукту, зі зміненим сценарієм розробки.
Наслідком такого рішення є зростання множника поправки Мр = 3,11, а також витрат і вартості:
ВИТРАТИ = 384 чол.-міс.;
ВАРТІСТЬ 3 = 2572800 $;
Отримані значення вартості, а також зміни у вартості у зв'язку з урахуванням зміни обмеження оперативної пам'яті (програш у вартості = 2572800 - 1460600 = 1112200 ($)) відображені в таблиці 16.
Таблиця 16 - Розрахунок змін у вартості з урахуванням змін досвіду роботи з утилітами та мовою, а також змін активного використання програмних утиліт

Вартість 3 ($)	Вартість ($)	Зміна вартості ($)
2572800	1460600	1112200

Таким чином, замовник, запропонувавши замінити мікропроцесор дешевшим (на 1000 $), спричинив збільшення вартості проекту на 1112200 $.
Такий підйом вартості проекту відбувається за рахунок збільшення значень множників LTEX і TOOL.
Отже, збільшення множника поправки Мр = 3,11 спричинило зростання також витрат і, отже, вартості. Такий сценарій розробки призводить замовника до програшу.

Висновок
Сучасна програмна інженерія (Software Engineering) - молода і швидко розвивається галузь знань і практик. Вона орієнтована на комплексне вирішення завдань, пов'язаних з розробкою особливого різновиду складних систем - програмних систем.
Програмні системи - самі незвичайні і дивні створіння рук людських. Вони не мають фізичних тіл, їх не можна помацати, відчути одним з людських почуттів. Вони не піддаються фізичному зносу, їх не можна виготовити в звичайному інженерному сенсі, як автомобіль на заводі. І разом з тим розробка програмних систем є найскладнішою з завдань, які доводилося коли-небудь вирішувати людині-інженеру.
Сучасне суспільство впадає у все більшу залежність від програмних технологій. Програмні інженери стали більш затребуваними.
Базис сучасної програмної інженерії утворюють такі складові:
q процеси конструювання ПЗ;
q метричний апарат, який забезпечує вимірювання процесів та продуктів;
q апарат формування вихідних вимог до розробок;
q апарат аналізу й проектування ПЗ;
q апарат візуального моделювання ПЗ;
q апарат тестування програмних продуктів.
У даному курсовому проекті знайшов застосування процес планування проекту, у складі якого виконання попередньої оцінки проекту на основі LOC-метрик.
Для оцінювання витрат у курсовому проекті використовується найбільш популярна модель - СОСОМО II.
На підставі виконаних вище оцінок, модно зробити висновки:
1) фактори витрат роблять істотний вплив на вихідні параметри програмного проекту;
2) модель СОСОМО II пропонує широкий спектр чинників витрат, що враховують більшість реальних ситуацій в «життя» програмного проекту;
3) модель СОСОМО II забезпечує переклад якісного обгрунтування рішення менеджера на кількісні "рейки", тим самим підвищуючи об'єктивність прийнятого рішення.
Дотримуючись висновку 1, при виборі сценарію розробки програмного забезпечення, необхідно враховувати аналіз чутливості програмного проекту, вироблений в 3, 4, і 5 розділах курсового проекту, а саме:
- Використовуючи сценарій зниження заробітної плати розробників проекту, замовник ризикує, оскільки використовує працю робітників нижчої кваліфікації, робоча сила яких виявляється дешевше, але швидкість і якість виконання проекту гальмується, тобто від процесу розробки ПЗ з'являється негативний ефект, що проявляється в подорожчанні вартості даного проекту ;
- Дотримуючись нарощування оперативної пам'яті, замовник виявляється у виграшній ситуації, так як обмеження пам'яті ОЗУ знижується, вивільняються вільні кілобайти, які можуть стати в нагоді у виконанні ще кількох завдань при розробці проекту;
- Використовуючи варіант здешевлення вартості мікропроцесора, замовник тим самим прокладає шлях до зниження такого активного використання програмних утиліт, як хотілося б кваліфікованим розробникам, при цьому зменшується досвід роботи з мовою і утилітами, а вже наслідком всього цього є збільшення вартості всього проекту в цілому.

Список використаної літератури
1. Технології розробки програмного забезпечення: Підручник / С. Орлов. - СПб.: Пітер, 2002. - 464 с.
2. Боемі б.у. Інженерне проектування програмного забезпечення. М.: Радіо і зв'язок, 1985. 511 с.
3. Липаев В.В. Налагодження складних програм: Методи, засоби, технологія. М.: Вища школа, 1993. 384 с.
4. Майерс Г. Мистецтво тестування програм. М.: Фінанси і статистика, 1982. 176с.
5. Орлов С.А. Принципи об'єктно-орієнтованого та паралельного програмування на мові Ada 95. Рига: TSI, 2001. 327 с.
6. Чеппел Д. Технології ActiveX і OLE. M.: Російська редакція, 1997. 320 с.