емпіричної оцінки вартості.
2. Оцінка вартості супроводження програмного
забезпечення.III. Література.
- Главная
- Разное
- Бизнес и предпринимательство
- Образование
- Развлечения
- Государство
- Спорт
- Графика
- Культурология
- Еда и кулинария
- Лингвистика
- Религиоведение
- Черчение
- Физкультура
- ИЗО
- Психология
- Социология
- Английский язык
- Астрономия
- Алгебра
- Биология
- География
- Геометрия
- Детские презентации
- Информатика
- История
- Литература
- Маркетинг
- Математика
- Медицина
- Менеджмент
- Музыка
- МХК
- Немецкий язык
- ОБЖ
- Обществознание
- Окружающий мир
- Педагогика
- Русский язык
- Технология
- Физика
- Философия
- Химия
- Шаблоны, картинки для презентаций
- Экология
- Экономика
- Юриспруденция
Что такое findslide.org?
FindSlide.org - это сайт презентаций, докладов, шаблонов в формате PowerPoint.
Обратная связь
Email: Нажмите что бы посмотреть
Презентация на тему Основні технічні та управлінські проблеми супроводження програмного забезпечення
Содержание
- 2. Питання до розглядуКонфігураційне управління.Вартість супроводження. 1.
- 3. I. Конфігураційне управління
- 4. Задачі розробників-супроводжувачів програмного забезпеченняЗрозуміти систему.Розмістити інформацію в
- 5. Технічні особливості супроводження програмного забезпеченняІснують спільні технічні
- 6. Конфігураційне управлінняЗміни програмного забезпечення є неминучим процесом.Однією
- 7. Сфери конфігураційного управлінняКомп'ютерні програмивихідний кодрезультати виконанняДокументаціятехнічнакористувацькаДаніякі містяться в програмізовнішні дані (наприклад, файли і бази даних)
- 8. БазисиРобочий продукт стає базисом тільки після того,
- 9. Джерела змінНові ринкові умови призводять до змін
- 10. Запити на змінуЗапити можуть надходити від користувачів,
- 11. Прогнозування змінПрогнозування кількості змін потрібує розуміння зв’язку
- 12. Задачі конфігураційного управлінняІдентифікаціявідстеження змін для різних версій
- 13. Контроль версій. Основні терміниСутністьскладається з об'єктів на
- 14. Процес контролю змін - 1Запит на зміну
- 15. Процес контролю змін - 2Ордер обробки зміни(ECO
- 16. Процес контролю змін - 3Модифікований об'єкт перевіряється
- 17. Команда з конфігураційного управлінняАналітики.Програмісти.Програмний бібліотекар.
- 18. Рада управління змінамиПредставники замовника.Деякі члени команди конфігураційного управління.
- 19. Робота програміста - 1Проблема виявлена.Звіт про проблему
- 20. Робота програміста – 2Програміст або аналітикзнаходить джерело
- 21. Питання контролю змінСинхронізація (коли?)Ідентифікація (хто?)Визначення назв (що?)Аутентифікація
- 22. Конфігураційний аудит - 1Чи була зміна визначена
- 23. Конфігураційний аудит - 2Чи атрибути об'єкта конфігурації
- 24. Конфігураційний статус звітуЩо сталося?Хто це зробив?Коли це сталося?Що ще буде залежати від зміни?
- 25. II. Вартість супроводження
- 26. Кілька моделей виходу з різною успішністю і
- 27. Модель 1: Базова Застосовуємо наступні формули, щоб
- 28. Оцінки робіт©Ian Sommerville 1995
- 29. Органічний клас проекту, 32KLOCPM = 2.4 (32)
- 30. Модель 2: Середній крок I: отримуємо номінальну
- 31. Органічні проекти: маленька команда розробників; знайомі між
- 32. 4 групи факторів: Характеристики продукту: потрібна надійність,
- 33. 15 факторів, кожен оцінений за 6-бальною шкалою:
- 34. крок IV: оцінка відповідних ресурсів виглядатиме так: TDEV = ci (PMDEV)di COCOMO
- 35. 2. Оцінка вартості супроводження програмного забезпеченняОсновне питання:
- 36. Альтернативи: за Б.Бемом визначимо ACT (річний трафік
- 37. 2 рівень моделі: PMAM = ACT ×
- 38. Фактори, які впливають на продуктивність програмного забезпечення
- 39. Процесні фактори: аналіз, проектування, методи тестування, мови
- 40. Фактори вартості супроводженняПлинність кадрівнизька плинність означає зниження
- 41. Прогнозування супроводженняВизначити частини системи, що можуть викликати
- 42. Прогнозування супроводження
- 43. Метрики складності супроводженняПрогнозування супроводження може бути здійснене
- 44. Метрики процесу супроводженняПоказники супроводжуваностікількість запитів на коригуюче
- 45. Інструменти супроводженняТекстові редактори.Програми для порівняння файлів.Компілятори та
- 46. Скачать презентацию
- 47. Похожие презентации
Питання до розглядуКонфігураційне управління.Вартість супроводження. 1. Моделі емпіричної оцінки вартості. 2. Оцінка вартості супроводження програмного забезпечення.III. Література.
Слайд 2
Питання до розгляду
Конфігураційне управління.
Вартість супроводження.
1. Моделі
емпіричної оцінки вартості.
забезпечення.III. Література.
Слайд 4
Задачі розробників-супроводжувачів програмного забезпечення
Зрозуміти систему.
Розмістити інформацію в документації.
Постійно
тримати програмну документацію в актуальному стані.
Розширити існуючі функції.
Додати нові
функції.Пошук джерел помилок.
Виправлення помилок.
Відповідати на операційні запити.
Реструктуризація структури програми і та програмного коду.
Видалення застарілих частин структури і коду.
Управління змінами.
Слайд 5
Технічні особливості супроводження програмного забезпечення
Існують спільні технічні питання
як для розробки програмного забезпечення, так і для супроводження
конфігураційне
управління і контроль версій (CVS, RCS)Деякі технічні питання стосуються лише супроводження програмного забезпечення
визначити вартість внесення змін відповідно до запитів на зміни програмного забезпечення
Слайд 6
Конфігураційне управління
Зміни програмного забезпечення є неминучим процесом.
Однією з
цілей розробки програмного забезпечення є змінювати програмне забезпечення для
покращення його зрозумілості.Конфігураційне управління це вся інформація про контроль змін.
Кожен програміст повинен бути стурбовані тим, як зміни, внесені до робочих продуктів відстежуються і поширюються протягом усього проекту.
Для забезпечення якості супроводження повинен бути проведений аудит процесу змін.
Слайд 7
Сфери конфігураційного управління
Комп'ютерні програми
вихідний код
результати виконання
Документація
технічна
користувацька
Дані
які містяться в
програмі
зовнішні дані (наприклад, файли і бази даних)
Слайд 8
Базиси
Робочий продукт стає базисом тільки після того, як
буде розглянутий і затверджений.
Базис – етап розробки програмного забезпечення,
що визначає одну або кілька сфер конфігураційного управління.Після того, як базис буде визначено кожен запит зміни повинен бути оцінений і верифікований, перш ніж буде оброблений.
Слайд 9
Джерела змін
Нові ринкові умови призводять до змін вимог
до програмного забезпечення або бізнес-правил.
Новий користувач потребує зміни даних,
функціональність або послуг.Реорганізація бізнесу призводить до зміни в пріоритетах програмного проекту або структурі команди з розробки програмного забезпечення.
Зміни у фінансуванні та планах розробки призводять до перегляду вимог до системи.
Слайд 10
Запити на зміну
Запити можуть надходити від користувачів, клієнтів,
або керівників.
Запити на зміну повинні бути ретельно проаналізовані, як
частина процесу супроводження перш, ніж вони будуть реалізовані.Деякі запити на зміну повинні бути реалізовані в терміновому порядку в силу своєї природи
виправлення несправностей
зміни системного середовища
терміново бізнес-зміни
Слайд 11
Прогнозування змін
Прогнозування кількості змін потрібує розуміння зв’язку між
системою та її програмним середовищем.
Тісно пов'язані системи вимагають внесення
змін щоразу при зміні середовища їх функціонування.Фактори, що впливають на зв’язок системи та програмного середовища
кількість і складність інтерфейсів системи
кількість і волатильність системних вимог
бізнес-процеси, в яких використовується система
Слайд 12
Задачі конфігураційного управління
Ідентифікація
відстеження змін для різних версій SCI
Контроль
версій
контроль змін до і після користувацьких релізів
Управління змінами
можливість затверджувати
та пріоритезувати зміниАудит конфігурацій
забезпечити правильності внесення змін
Звітність
Оповіщення всіх користувачів системи про внесення змін
Слайд 13
Контроль версій. Основні терміни
Сутність
складається з об'єктів на однаковому
рівні перегляду
Варіант
набір із різних об’єктів на однаковому рівні перегляду
та співіснуючий із іншими варіантамиНова версія
виникає, коли основні зміни для одного або декількох об'єктів були проведені
Слайд 14
Процес контролю змін - 1
Запит на зміну подається
та оцінюється, щоб оцінити його технічні переваги і вплив
на інші об'єкти конфігурації і бюджет.Звіт по зміні містить результати оцінки, які генеруються.
Група контролю за змінами(ССА – Change control authority) приймає остаточне рішення про статус і пріоритет зміни базуючись на звіті.
Слайд 15
Процес контролю змін - 2
Ордер обробки зміни(ECO –
Engineering change order) створюється для кожної затвердженої зміни.
ECO описує
зміну, складає список обмежень, і визначає критерії для аналізу та аудитуОб'єкт, що буде змінений, перевіряється з базою даних проекту для отримання доступу до параметрів керування для об'єкта
Модифікований об'єкт піддається відповідним процедурам SQA і тестування.
Слайд 16
Процес контролю змін - 3
Модифікований об'єкт перевіряється механізмами
проектної бази даних і контролю версій, які використовуються для
створення наступної версії програмного забезпечення.Контроль синхронізації використовується для забезпечення того, щоб паралельні зміни, зроблені різними людьми зовсім не змінювали один одного.
Слайд 18
Рада управління змінами
Представники замовника.
Деякі члени команди конфігураційного управління.
Слайд 19
Робота програміста - 1
Проблема виявлена.
Звіт про проблему направляється
до групи конфігураційного контролю.
Група обговорює проблему
чи є проблема несправністю?
чи
є це покращенням?хто повинен за це платити?
Визначити рівень пріоритетності чи серйозності проблеми, і призначити відповідальних співробітників.
Слайд 20
Робота програміста – 2
Програміст або аналітик
знаходить джерело проблеми
визначає,
що необхідно, щоб її виправити
Програміст разом із програмним бібліотекарем
контролюють інсталяцію змін в операційну систему і в документацію.Програміст подає звіт по зміні, в якому задокументовані усі проведені зміни.
Слайд 21
Питання контролю змін
Синхронізація (коли?)
Ідентифікація (хто?)
Визначення назв (що?)
Аутентифікація (чи
вірно зроблено?)
Авторизація (хто погоджує?)
Маршрутизація (хто повідомив?)
Скасування (хто може зупинити
його?)Делегування (питання відповідальності)
Оцінювання (питання пріоритетності)
Слайд 22
Конфігураційний аудит - 1
Чи була зміна визначена ЕСО
зроблена без модифікацій?
Чи було проведено FTR (First Time Right),
щоб оцінити технічну правильність?Чи був дотриманий програмний процес і стандарти розробки програмного забезпечення?
Слайд 23
Конфігураційний аудит - 2
Чи атрибути об'єкта конфігурації відображають
зміни?
Чи були дотримані стандарти конфігураційного управління для запису та
звітності по змінам?Чи були всі пов'язані SCI правильно оновлені?
Слайд 24
Конфігураційний статус звіту
Що сталося?
Хто це зробив?
Коли це сталося?
Що
ще буде залежати від зміни?
Слайд 26 Кілька моделей виходу з різною успішністю і легкістю/важкістю
користування.
Розглянемо COCOMO (Модель витрат розробки).
Розкладемо програмне забезпечення на
достатньо малі частини, щоб мати можливість оцінити LOC (лінії коду). Визначення:
KDSI – кіло поставки інструкцій із вихідних даних (заявки)
не включаючи коментарі, тестові випробування, тощо.
PM - людиномісяці
3 рівня моделі COCOMO: Базовий, Середній та, Деталізований (про нього мова в лекції не йтиметься)
1. Моделі емпіричної оцінки вартості
Слайд 27
Модель 1: Базова
Застосовуємо наступні формули, щоб отримати
грубі оцінки
PM = 2.4(KDSI)1.05
TDEV = 2.5(PM)0.38 (хронологічні
місяці) COCOMO
Слайд 29
Органічний клас проекту, 32KLOC
PM = 2.4 (32) 1.05
= 91 людиномісяців
TDEV = 2.5 (91) 0.38 = 14
місяцівN = 91/14 = 6.5 людей
Вбудований клас проекту, 128KLOC
PM = 3.6 (128)1.2 = 1216 людиномісяців
TDEV = 2.5 (1216)0.32 = 24 місяців
N = 1216/24 = 51 людей
COCOMO приклади
©Ian Sommerville 1995
Слайд 30
Модель 2: Середній
крок I: отримуємо номінальну оцінку
у вигляді:
PMNOM = ai (KDSI)bi , де
COCOMO
Слайд 31 Органічні проекти: маленька команда розробників; знайомі між собою;
робота в одному приміщенні; великий досвід; нескладні вимоги.
Вбудовані
проекти: фірма, жорсткі обмеження (в т.ч. апаратного забезпечення), в основному малознайома територія. Напіврозподілені проекти: в обох випадках.
крок II: визначити оцінки факторів вартості:
З таблиці з 15 факторів, кожен оцінюється за 6-бальною шкалою.
COCOMO
Слайд 32
4 групи факторів:
Характеристики продукту: потрібна надійність, складність
продукту,
Характеристики апаратного забезпечення: обмеження: швидкодії підчас виконання програми,
пам’яті, середовища віртуальної машини, волатильності (апаратної та програмної), часу відновлення, Характеристики персоналу: аналітичні, програмістські навики, досвід розробки, досвід роботи з віртуальними машинами, досвід розробки на потрібних мовах програмування,
Характеристики проекту: сучасні методики програмування, використання інструментів розробки програмного забезпечення, реалістичний графік робіт.
COCOMO
Слайд 33
15 факторів, кожен оцінений за 6-бальною шкалою:
дуже
низький - низький - середній - високий – дуже
високий - критичнийвикористовуючи модель COCOMO рахуємо регулюючий фактор трудоємності (EAF):
крок III: середня оцінка трудоємності розробки матиме вигляд:
PMDEV = PMNOM * EAF
COCOMO
Слайд 35
2. Оцінка вартості супроводження програмного забезпечення
Основне питання: яка
кількість програмістів необхідна для супроводження системи програмного забезпечення?
Не складно
здогадатись, що відповідь матиме вигляд типу:
Слайд 36
Альтернативи: за Б.Бемом
визначимо ACT (річний трафік змін)
як частку заявок змін на рік:
1 рівень моделі:
PMAM = ACT × PMDEV
де AM = річне супроводження
Оцінка вартості супроводження програмного забезпечення
Слайд 37
2 рівень моделі:
PMAM = ACT × PMDEV
× EAFM
де EAFM може відрізнятися від EAF для
розробки з:різним персоналом
рівнем досвіду, мотивації, тощо
Оцінка вартості супроводження програмного забезпечення
Слайд 38 Фактори, які впливають на продуктивність програмного забезпечення (так
само на супроводження):
Людські фактори: розмір організації і досвід
розробки (супроводження).Проблемні фактори: складність проблеми і кількість змін в проектних обмеженнях і вимогах.
Оцінка вартості супроводження програмного забезпечення
Слайд 39 Процесні фактори: аналіз, проектування, методи тестування, мови програмування,
CASE інструменти, тощо.
Фактори продукту: потрібна надійність і продуктивність
системи. Ресурсні фактори: наявність CASE інструментів, ресурсів апаратного та програмного забезпечення.
Оцінка вартості супроводження програмного забезпечення
Слайд 40
Фактори вартості супроводження
Плинність кадрів
низька плинність означає зниження витрат
на супроводження
Договірна відповідальність
розробники можуть не мати договірних зобов'язань супроводжувати
розроблювану систему і розбудовувати її структуру для майбутніх змінКваліфікація персоналу
персонал супроводження часто недосвідчений і має обмежені знання про домени супроводження
Вік програми та структура
з часом структура програми погіршується, її стає важче розуміти і змінити
Слайд 41
Прогнозування супроводження
Визначити частини системи, що можуть викликати проблеми
і вимагати значні витрати на супроводження
Прийняття змін залежить від
супроводжуваності компонентів, які зачіпає змінаПроведення змін погіршує систему і знижує її супроводжуваність
Вартість супроводження залежить від кількості змін
Вартість зміни залежить від супроводжуваності
Слайд 43
Метрики складності супроводження
Прогнозування супроводження може бути здійснене шляхом
оцінки складності компонентів
Більшість зусиль спрямованих на супроводження впливає тільки
на невелику кількість компонентів системиСкладність супроводження залежить від
складності структури управління
складності структури даних
розміру модуля
Слайд 44
Метрики процесу супроводження
Показники супроводжуваності
кількість запитів на коригуюче супроводження
середній
час, необхідний для імпакт аналізу
середній час для реалізації запиту
на змінукількість розміщених запитів на зміни
Якщо який-небудь з цих показників збільшився, це може сигналізувати про зниження супроводжуваності
Слайд 45
Інструменти супроводження
Текстові редактори.
Програми для порівняння файлів.
Компілятори та редактори
зв’язків.
Програми для проведення дебагінгу (налагодження).
Генератори перехресних посилань.
Калькулятори підрахунку складності.
Контроль
бібліотек.CASE інструменти для всього життєвого циклу.
