М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
- Название:ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- ISBN:978-966-598-626-3
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ краткое содержание
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ Національний авіаційний університет
М. О. Сидоров
ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
Курс лекцій Київ
Видавництво Національного авіаційного університету «НАУ-друк» 2010
УДК 004.4(042.4) ББК з 973.20-018.2я7 С 347
Рецензент: S. А. Резніченко- канд.фіз.-мат.наук (Інститут програмних систем HAH України); В, А. Дерецький - канд.фіз.-мат.наук (Інститут програмних систем HAH України); В. А. Хоменко - канд.техн. наук, доц. (Національний авіаційний університет)
Затверджено методично-редакційною радою Національного авіаційного університету (протокол № 14 від 03.07.2008p.).
Сидоров М. О.
С 347 Вступ до інженерії програмного забезпечення : курс лекцій / М.О.Сидоров. - К.: Вид-во Нац. авіац. ун-ту «НАУ-друк», 2010. -112 с.
ISBN 978-966-598-626-3
У курсі лекцій викладено основні положення інженерії програмного забезпечення.
Для студентів напряму 6.050103 "Програмна інженерія".
УДК 004.4(042.4) ББК з 973.20-018.2я7
ISBN 978-966-598-266-3 © Сидоров М.О.. 2010
ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
,
де C j-ступінь виливу i-ї GSC. Останньою розраховується кількість повних функціональних точок: FP-UAF* VAF,
Існують додатки, під час оцінювання яких використання стандартних функціональних точок не ефективне. Ці застосування такі: управління процесом у реальному часі, математичні обчислення, симуляція, системні застосування, інженерні застосування, вбудовані системи. Перераховані застосування відрізняються високою інтенсивністю обчислень, часто заснованих на алгоритмах підвищеної складності. Для вирішення завдань розрахунку розміру вказаних застосувань у 1986 році організацією Software Productivity Research (SPR) була розроблена методика аналізу характерних точок ПЗ (feature points). Суть її полягає в тому, що оцінюється кількість алгоритмів у програмі і частково модифікується ступінь значущості (weighting values) для розрахунку FP. Ця методика вважається експериментальною.
7.2. Методи і моделі оцінювання вартості програмного забезпечення
Методи і моделі оцінювання вартості ПЗ можна розділити на дві групи: неалгоритмічні методи і алгоритмічні моделі. До неалгорит-мінних методів належать Price-to-win, оцінка ПЗ Паркінсона, експертна оцінка, оцінка за аналогією. До алгоритмічних моделей, належать SLIM і COCOMO.
Суть неалгоритмічних методів полягає в тому, що при оцінюванні вартості ПО використовуються певні схеми і принципи, а не математичні формули. Нижче проаналізуємо ці методи.
Price-to-win. Метод грунтується на принципі «клієнт, завжди має рацію». Суть методу полягає в тому, то незалежно від передбачуваних реальних витрат на розробку проекту, оцінка вартості ПО коригується відповідно до побажань замовника. Price-to-win фактично є політикою проведення переговорів з клієнтом, тому оцінювання часто застосовується компаніями, що не мають засобів для якісного оцінювання проектів. Застосування методу може мати для розробника певні негативні наслідки: брак ресурсів для виконання проекту, невиконання термінів здачі проекту і як результат — втрата контракту або банкрутство.
Оцінка за Паркінсоном. Метод грунтується на принципі «Обсяг роботи зростає так, як це потрібно, щоб зайняти час, виділений на її виконання». Принцип, пізніше названий «законом», був уперше висловлений С.Н. Паркінсоном і описував природу взаємодії бюрократичної системи в адміністративних інститутах, відображаючи процес неефективного використання ресурсів. У застосуванні до розробки програмних проектів закон Паркінсона використовується у вигляді такої схеми: щоб підвищити продуктивність праці розробника, слід зменшити час, відведений на розробку.
Експертна оцінка. Метод грунтується на принципі експертної оцінки і застосовується в таких проектах, що використовують нові технології, нові процеси або вирішальні інноваційні завдання. До процесу оцінювання залучаються інженери-розробники, які самі оцінюють частину проекту, що займається ними. Після цього скликаються збори, на яких результати окремих оцінок інтегруються в єдину, цілісну систему. Припущення, на яких грунтувалася оцінка окремих експертів, заносяться в протокол і відкрито обговорюються. При опитуванні експертів використовуються Дельфійськая методика або розширена методика, орієнтована на приведення експерті» до консенсусу. У результаті досягається баланс оцінки при інтеграції окремих компонентів у загальну систему. Далі йде чергова стадія компонентного оцінювання, і у межах збільшення кількості ітерацій точність оцінки збільшується.
Оцінка за аналогїєю - будучи різновидом експертної оцінки, часто виділяється в окремий метод. Метод ґрунтується на принципі аналогії, Оцінка аналогічно алгоритмічним моделям використовує емпіричні дані про характеристики завершених проектів. Головна відмінність полягає в тому, що алгоритмічні моделі використовують ці дані непрямим чином, наприклад, для калібрування параметрів моделей, а метод оцінювання ПО за аналогією за допомогою емпіричних даних дає змогу відібрати схожі проекти. Схема оцінки, заснована на вказаному принципі, складається з декількох етапів. На першому етапі здійснюється збір даних за проектом, що розробляється, У рамках життєвою циклу ПО оптимальними формами для цього с аналіз вимог і проектування. На основі експертної оцінки проводиться відбір характеристик ПО за якими порівнюватимуться проекти, Вибір характеристик залежить від типу додатка, середовища розробки і набору відомих параметрів додатка. Наступний етап включає пошук і аналіз проектів «аналогічних» ПО, що розробляються за вибраними характеристиками, Результатом цього етапу є, як правило, декілька проектів, що мають найменші відмінності в числових значеннях характеристик оцінки. Для відбору найбільш близьких проектів, що розробляються, може використовуватися метод вимірювання евклідової відстані в n-мірному просторі. Кожній характеристиці привласнюється значення ваги (множник), що визначає значущість характеристики для проекту, У спрощеному варіанті вага дорівнює одиниці, тобто всі характеристики проекту вважаються рівнозначними ПО за важливістю. Далі проекти і їх відповідні характеристики відображаються в n-мірному просторі, як точки (n дорівнює кількості змінних, для кожної змінної використовується своє вимірювання), після чого обчислюється евклідова відстань між відповідними точками:
де a і b- точки в просторі; a 1... a nі b 1... b n- координати точок у відповідних площинах.
Проекти, що мають найбільшу схожість, будуть розташовані щонайближче, тобто евклідова відстань у них буде найменшою. Останнім станом с експерт на оцінка проекту, що розробляється, в якій значення, взяті а аналогічного проекту, використовуються як база оцінки.
Моделі оцінювання вартості 173. Модель оцінювання вартості програмного забезпечення - цс одна або декілька функцій, які описують залежність між характеристиками проекту і витратами на його реалізацію. Моделі поділяють за типом використовуваних функцій на лінійні, мультиплікативні, статичні; за використанням історичних даних на емпіричні та аналітичні. Моделями, що часто реалізуються і є добре документованими, є моделі Путнема (статична, аналітична) і COCOMO (статична, емпірична).
Модель Путнема (SLIM). Найбільш поширена модель аналітичної групи. Створена для проектів обсягом понад 70 000 рядків коду, модель ґрунтується на твердженні, що витрати на розробку ПО розподіляються згідно з кривими Нордена-Рейлі, які є графіками функцій, що розподіляє робочу силу за часом. Загальний вигляд подібної функції: де v - набуте значення; t- час, a v 0і t p- параметри, що визначають функцію. Для великого значення t крива прагне до параметра v 0, який називається cost scale factor parameter, функція зростає найшвидше при t = t pОсновною причиною такої поведінки моделі було те, що спочатку дослідження Нордена ґрунтувалися не на теоретичній основі, а на спостереженнях за проектами, не пов'язаними з ПО (машинобудування, будівництво). Тому немає наукового підтвердження, що програмні проекти потребують такого ж розподілу робочої сили. Навпаки, часто кількість людино-годин, потрібних проекту, може різко змінитися, зробивши оцінку непридатною до використання. Після ряду емпіричних спостережень Путнем виразив робоче рівняння моделі у формі:
Интервал:
Закладка: