М. Сидоров - ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
- Название:ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
- Автор:
- Жанр:
- Издательство:неизвестно
- Год:неизвестен
- 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
ВСТУП ДО ІНЖЕНЕРІЇ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Під час використання засобів на основі моделі COCOMO або COCOMO IT чинниками, що впливають на точність оцінювання вартості, є такі: правильний вибір конкретної реалізації моделі COCOMO; точність калібрування - відповідність установок початковим даним. У зв'язку з цим, для застосування засобів використовують персонал, який не мас прямого відношення до процесів проектування і розробки програмного забезпечення. Він формує специфікації проекту і параметри, необхідні для оцінки, які надаються співробітникам, які виконують оцінювання.
Ефективне застосування алгоритмічних моделей оцінювання вартості програмного забезпечення і заснованих на їх основі засобів оцінки віддають перевагу їх сумісному використанню з неалгоритмічними методами оцінювання. Так, алгоритмічні засоби оцінки можуть бути застосовані членами експертних комісій для аналізу проекту і формування власного оцінювання. Завдяки широким можливостям експорту даних і візуалізації, використання автоматизованих засобів оцінки вартості програмного забезпечення дає можливість формувати власні бази характеристик реалізованих проектів, а також створювати звіти, що ілюструють процес розробки проекту, що значно знижує трудовитрати, пов'язані з підготовкою звітності.
Параметри вартості, Параметр вартості (cost driver) - це суб'єктивна величина, яка оцінює різні тимчасові, якісні і ресурсні аспекти розробки програмного забезпечення. Кожен з параметрів може бути відкалібрований. Калібрування параметрів вартості - це коректування значень параметрів, що впливає на значення трудовитрат, а отже, на якийсь час і на вартість, оцінюючи програмний проект. При калібруванні за вказаними нижче сімнадцятьма параметрами вибирається оцінний рівень (дуже високий, високий, вище номінального, номінальний, нижче номінального, низький, дуже низький) параметра. У формулах цей рівень відбивається у вигляді коефіцієнта трудовитрат і, таким чином, на кожній стадії розробки проекту впливає на вартість і тривалість тієї або іншої стадії. Виділяють такі групи параметрів (табл.7.1): продукту (product factors), платформи (platform factors), персоналу (personnel factors) і проекту (project Jactors). У табл. 7.2 подано короткий опис кожного параметра.
Таблиця 7.1
| Продукт | Враховують характеристики того, що розробляється ПЗ (RELY. DATA, CPLX, RUSE, DOCU) |
| Платформа | Враховують характеристики програмно-апаратного комплексу, потрібного для функціонування ПЗ (TIME, STOR, PVOL) |
| Персонал | Враховують рівень знань і злагодженості роботи колективу програмістів (АСАР, РСАР, PCON, APEX, PLEX. LTEX) |
| Проект | Враховують вплив сучасних підходів і технологій, територіальну віддаленість членів колективу розробників і терміни виконання проекту (TOOL, SITE, SCED) |
Таблиця 7.2
| Параметр | Опис |
| RELY (Required Software Reliability) | Враховує ступінь виконання програмою певної дії протягом певного часу |
| DATA (Database Size) | Враховує вплив обсягу тестових даних на розробку продукту. Рівень цього параметра розраховується як співвідношення байт у тестованій базі даних до SLОС у програмі |
| CPLX (Product Complexity) | Включає п'ять типів операцій; управління, рахункові, пристрійно-залежні, управління даними, управління, призначене для користувача інтерфейсом, Рівець складності — це суб'єктивне середньозважене значення рівнів типів операцій |
| RUSE (Developed for Reusability) | Враховує трудовитрати (потрібні додатково для написання компонентів), призначені для повторного використання в даному або подальших проектах. Використовує такі оцінні рівні: «у проекті», «у програмі», «у лінійці продуктів», «у різних лінійках продуктів». Значення параметра накладає обмеження на параметри RELY і DOCU |
| DOCU (Documentation Match To Life-Cycle Needs) | Враховує ступінь відповідності документації проекту його життєвому циклу |
| TIME (Execution Time Constraint) | Враховує тимчасові ресурси, використовувані ПЗ при виконанні поставленого завдання |
| STOR (Main Storage Constraint) | Враховує відсоток використання сховищ даних |
| PVOL (Platform Volatility) | Враховує термін «життя» платформи (комплекс апаратного і ПЗ, який потрібний для функціонування того, що розробляється ПЗ) |
| АСАР (Analyst Capability) | Враховує аналіз, здатність проектувати, ефективність і комунікативні здібності групи фахівців, які розробляють вимоги і специфікації проекту. Параметр неповинен оцінювати рівень кваліфікації окремо взятого фахівця |
| РСАР (Programmer Capability) | Враховує рівень програмістів у колективі. При виборі значення для цього параметра слід звернути увагу на комунікативні і професійні здібності програмістів і на командну роботу в цілому |
| PCON (Personnel Continuity) | Враховує плинність кадрів у колективі |
| APEX (Applications Experience) | Враховує досвід колективу при роботі над додатками певною типу |
| PLEX (Platform Experience) | Враховує вміння використовувати особливості платформ, такі як: графічний інтерфейс, бази даних, мережевий інтерфейс, розподілені системи |
| LTEX (Language and Tool Experience) | Враховує досвід програмістів (мови, середовища та інструменти) |
| TOOL (Use Of Software Tools} | Враховує рівень використання інструментів розробки |
| SITE (Multisite Development) | Враховує територіальну віддаленість (від офісу до міжнародних офісів) членів команди розробинків і використовувані ними засоби комунікації (від телефону до відео конференц-зв'язку) |
| SCED (Required Development Schedule) | Враховує вплив тимчасових: обмежень, що накладаються на проект і на значення трудовитрат |
СПИСОК ЛІТЕРАТУРИ
1. Basilli V.R. Viewing Maintenance as Reuse-Oriented Software Development/V.R. Basilli //IEEE Software. 1990. - June. -P. 19-25.
2. Boehm B.W. Improving Software Productivity / B.W. Boe hm // Computer. - 1987. - Vol. 20, n.9. - P. 43 - 57.
3. Boehm B.W. Software Engineering Economics / B.W. Boehm - Englewood Cliffs, Ш.: Prentice-Hall, 1981. - 257 p.
4. Boehm B.W. Spiral Model of software Development and Enhancement / B.W. Boehm // Computer. - 1988, - May. - P. 71 - 73.
5. Bosch J. Design and use of software architectures / J. Bosch. -Addison Wesley, 2000. - 325 p.
6. Black R. Critical Testing Processes / R. Black. - Addіson-Wesley, 2003.
7. Вlum В.A. Taxonomy of Software Development Methods / B.A. Blum // Coinmunication of the ACM. - 1994. - Vol. 37, n. 11,-Р. 82 - 94.
Читать дальшеИнтервал:
Закладка:
![Леонид Сидоров - Проводник [СИ]](/books/1078401/leonid-sidorov-provodnik-si.webp)
