М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
- Название:ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- 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
ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
де Size - розмір коду в LOC; С - технологічний фактор; Е- загальна вартість проекту в людино-годинах; t - очікуваний час реалізації проекту.
Технологічний фактор включає в себе характеристику проекту в таких аспектах: методи управління розуміння процесу, якість використаних методів інженерії ПО, рівень використаних мов програмування, рівень розвитку середовища, навички та досвід команди розробників, складність додатків.
Рівняння для загальної вартості Е мас вигляд:
де D 0- коефіцієнт, що виражає кількість необхідної робота (значення від 8 до 12 означає, що ПО повністю нове, з великою кількістю зв'язків; значення до 27 - потрібне перероблення наявного коду)- Зв'язуючи два рівняння, отримаємо таке
і
які показують, що витрати пропорційні розміру коду в степені 9/7 ≈ 1/286. Це досить близько до моделі Б. Боема, де даний чинник знаходиться у межах від 1,05 до 1,20 [10].
У 1991 році Путнемом була представлена альтернативна реалізація моделі, виконана за замовленням Quantitative Software Management (QSM) Inc. і застосована в комплексі SLIM Estimate для оцінювання вартості ПЗ [14]. Повне рівняння в цій реалізації виглядає як: Е = 12 5∙ B(SLOC/P) 3∙ (1/Schedule 4).
Якщо на загальний час реалізації проекту обмеження не накладаються, то можливе використання спрощеного рівняння
тут В - чинник спеціальних навичок; Р - чинник продуктивності; Schedule - час розробки ПЗ графіку (у місяцях), Рівняння може бути використане, якщо передбачувані витрата понад 20 люднно-місяцїв.
Використання наведених рівнянь потребує знання параметра Р. Для його визначення використовується спеціальна таблиця, що містить значення параметра Р, залежні від середовища застосування, що розробляється.
Модель COCOMO. Сім'ю моделей COCOMO було створено в 1981 році на основі бази даних про проекти консалтингової фірми TRW.
COCOMO є третьою моделлю, орієнтованою на використання в трьох фазах життєвого циклу ПО: базова (Basic) - застосовується на етапі вироблення специфікацій, вимог, розширена (Intermediate) - після визначення вимог до ПО; поглиблена (Advanced) - використовується після закінчення проектування ПЗ. У загальному вигляді рівняння моделей має вигляд:
де Е - витрати праці на проект (у людино-місяцях); S - розмір коду (у KLOC); EAF - чинник уточнення витрат (effort adjustment factor). Параметри a і b залежать від виду застосування, що розробляється, який може бути таким:
- відносно простий проект, робота над яким ведеться однорідною командою розробників, вимоги носять рекомендаційний характер, відсутня заздалегідь вироблена вичерпна специфікація (наприклад, нескладне прикладне програмне забезпечення);
- проект середньої складності, робота над яким ведеться змішаною командою розробників, Вимоги до проекту визначаються специфікацією, проте можуть змінюватися в процесі його розробки (наприклад, програмне забезпечення системи управління банківським терміналом);
- проект, який повинен бути реалізованій! у жорстких рамках заданих вимог (наприклад, програмне забезпечення системи управління польотами),
У базовій моделі чинник EAF береться рівним одиниці. Для визначення значення цього чинника в розширеній моделі використовується таблиця, що містить ряд параметрів, які визначають вартість проекту. Використовуючи поглиблену модель, спочатку виконують оцінювання з використанням розширеної моделі на рівні компонента, після чого кожен параметр вартості оцінюється для всіх фаз життєвого циклу ПЗ.
COCOMO II також є сімейством моделей і є розвитком базової (Basic) моделі COCOMO. COCOMO ІІ включає три моделі - створення додатків (Application Composition Model, ACM), ранній етап розробки (Early Design Model, EDM) і пост-архитектурна (Post Architecture Model, PAM).
ACM використовується на ранньому етапі реалізації проекту, для того, щоб оцінити таке: інтерфейс користувача, взаємодія з системою, продуктивність. За початковий розмір береться кількість екранів, звітів і 3GL-компонентів. Якщо припустити, що в проекті буде використано r % об'єктів з раніше створених проектів, кількість нових об'єктних точок у проекті (Object Points, OP) можна розрахувати як:
OP=(object роіnts)*(100-r)/100.
Тоді витрати можна розрахувати за формулою:
E=OP/PROD,
де PROD - табличне значення.
EDM - це високорівнева модель, якій потрібна порівняно неве-лика кількість початкових параметрів. Вона призначена для оцінювання доцільності використання тих або інших апаратних і програмних засобів у процесі розробки проекту. Для визначення розміру використовується функціональна точка (Unadjusted Function Point). Для її перетворення в LOC використовуються таблиці перетворень, Рівняння моделі раннього етапу розробки мас вигляд:
E=a∙LOC∙EAF,
де а - константа 2,45; EAF визначається так само, як і в оригінальній моделі COCOMO.
Параметри для EDM отримують комбінуванням параметрі» для постархітектурної моделі.
РАМ є найбільш деталізованою моделлю, яка використовується, коли проект повністю готовий до розробки, Для оцінювання вартості ПЗ за допомогою РАМ необхідний пакет опису життєвого циклу проекту, який містить докладну інформацію про чинники вартості і дозволяє провести точніше оцінювання. РАМ використовується на етапі фактичної розробки і підтримки проекту. Для оцінювання розмірів можуть використовуватися як рядки коду, так і функціональні точки з модифікаторами, що враховують повторне використання коду. Модель використовує 17 чинників вартості і 5 чинників, що визначають масштаб проекту (у моделі COCOMO масштаб визначався параметрами виду додатка). Рівняння РАМ має вигляд
а взято за 2,55, а,
де W i- параметри, що відображають властивості проекту, наприклад, схожість з раніше виконаними проектами, ризик вибору архітектури для реалізації, розуміння процесу розробки, спрацьованості команди розробників. Значення параметрів є табличними.
Интервал:
Закладка: