- •I. Введення в розробку програмного забезпечення
- •1. Складність інформаційних систем
- •2. Розробка програмного забезпечення
- •4.Концептуальне моделювання
- •2. Модель водоспаду із зворотнім зв'язком
- •7.Модель спіралі
- •III. Етапи розробки програмного забезпечення
- •1. Стратегічний етап
- •2.2. Нефункціональні вимоги
- •4. Етап проектування
- •5. Етап реалізації
- •6. Етап тестування
- •7. Етап установки
- •8. Етап підтримки
- •IV. Стратегічний етап
- •1. Дії на стратегічному етапі
- •2. Співпраця з клієнтом
- •3. Область дії і контекст проекту
- •4. Стратегічні рішення
- •5. Оцінка різних варіантів рішеннь
- •6. Оцінка вартості рішень
- •7. Чинники успіху
- •8. Результати стратегічного етапу
- •9. Короткий звіт
- •V. Розпізнавання вимог і документація
- •1. Складнощі у формулюванні вимог
- •2. Методи ідентифікації вимог
- •3. Методи опису вимог
- •4. Типи вимог
- •5. Перевірка вимог
- •6. Документ з вимогами
- •7. Чинники успіху
- •8. Короткий звіт
- •VI. Розробка моделі
- •1. Потреба в розробці моделі
- •2. Аналітична модель
- •3. Дії на етапі аналізу
- •4. Функціональна декомпозиція
- •5. Методологія, що використовується в створенні аналітичної моделі
- •6. Документація вимог
- •7. Аналіз чинників успіху
- •8. Короткий звіт
- •VII. Етап проектування
- •1. Цілі проектування
- •Малюнок 7.2.1. Етап проектування.
- •2. Специфікація результатів аналізу
- •3. Дизайн інтерфейсу
- •4. Структуровані схеми/діаграми
- •5. Складова організації даних
- •6. Оптимізація проекту
- •7. Фізична структура системи
- •8. Правильність і якість проекту
- •9. Нефункціональні вимоги на етапі проектування
- •10. Результати етапу проектування
- •11. Детальний документ проекту
- •2. Стандарти, правила і порядок здійснення дій проекту:
- •12. Короткий звіт
- •VIII. Розробка інтернет-програм
- •1. Специфікація інтернет-програми
- •2. Методи розробки інтернет-програм
- •3. Об'єктно-орієнтована гіперсередовищна модель розробки (oohdm)
- •4. Метод розробки веб-сторінок (wsdm)
- •5. Мова веб-моделювання (WebMl)
- •6. Короткий звіт
- •IX. Бдб і бдс системи
- •1. Електронний бізнес
- •2. Інтернет-бізнес і електронний ринок.
- •3. Інтернет-магазин
- •4. Модель електронного бізнесу
- •1.Модель брокера
- •2.Модель, яка задовольняє індивідуальним потребам
- •3.Модель контактів
- •5. Платежі
- •6. Безпека
- •8. Моделювання систем бдб і бдс
- •9. Багатошарова архітектура програм
- •9. Cервіс-орієнтована архітектура (соа)
- •10. Короткий звіт
- •X. Реалізація
- •1. Характеристики етапу реалізації
- •2. Надійність програмного забезпечення
- •3. Похибка
- •4. Транзакції
- •5. Середовище реалізації
- •6. Чинники успіху і результати етапу реалізації
- •7. Короткий звіт
- •XI. Тестування
- •1. Етап тестування
- •2. Перевірка
- •Малюнок 11.3.1. Модель V-тестування.
- •3. Перегляди
- •4. Аудит
- •5. Інспекції
- •6. Види тестів
- •7. Процес тестування
- •8. Тестування надійності
- •9. Типи тестів на знаходження помилок
- •10. Програми-інструменти
- •11. Статичні тести
- •12. Підрахунок кількості помилок
- •13. Чинники успіху, успіх тестування
- •14. Короткий звіт
- •XII. Оцінка програмного забезпечення
- •1. Простановка розмірів проекту
- •2. Оцінка складності в проектах
- •3. Ефекти масштабування
- •4. Оцінка вартості програмного забезпечення
- •5. Конструктивна вартісна модель (cocomo)
- •6. Балова функціональна оцінка
- •7. Метод випадкового використання
- •8. Короткий звіт
- •XIII. Управління конфігурацією пз і версіями
- •1. Управління конфігурацією пз
- •2. Елементи конфігурації пз
- •3. Угода позначень
- •4. Зберігання елементів конфігурації
- •5. Перегляди
- •7. План управління конфігурації пз
- •I Вступ
- •II Управління
- •III Визначення конфігурації
- •IV Управління конфігурацією
- •V Реєстрація статусу конфігурації
- •4. Модель якості iso-9126
- •5. Управління якістю
- •6. Стандарти якості
- •7. Незрілість і зрілість виробництва
- •8. План гарантії якості пз (sqap)
- •9. Короткий звіт
- •XV. Управління проектом програмного забезпечення
- •1. Завдання управління проектом
- •2. Працівники виробництва програмного забезпечення
- •3. Характеристика хорошого розробника програмного забезпечення
- •4. Робота в команді
- •5. Управління підприємством по виробництву програмного забезпечення
- •6. Розвиток компанії по розробці програмного забезпечення
- •7. Документація проекту
- •8. Визначення продуктивності
- •9. Складання графіків проекту
- •10. Завдання управління проектом
- •11. Інтерфейс проекту
- •12. Планування проекту
- •13. Управління ризиком
- •14. Вимірювання процесів і продуктів
- •15. Короткий звіт
5. Конструктивна вартісна модель (cocomo)
Метод COCOMO (Constructive Cost Model) і інші методи, отримані від нього, використовують вимірювання, залежні від технології: кількість рядків початкового коду (source code line number, LOC).
Це вимагає підрахунок кількості команд і класифікує їх по наступних групах:
Органічні проекти. Цей клас містить в собі маленькі проекти, створені висококваліфікованими професіоналами. Домен, прикладні методи і інструменти добре відомі.
Напіввід'єднані проекти. Члени команди мають різні кваліфікації, і деякі компоненти домена не є добре відомими.
Дочірні проекти. Проекти розвивають системи з дуже складними вимогами. Домен, прикладні інструменти і методи не відомі. Більшість членів команди не мають досвіду в рішенні схожих проблем.
Метод COCOMO використовує наступну формулу:
Робоче навантаження [працівники * місяці] A * K бета * (експоненціальна залежність) , де K (описується як KDSI, кіло (тисяча) доставлених команд початкового коду (Kilo Delivered Source Code Instructions)). Це означає, що розмір початкового коду вимірюється в тисячах рядків. KDSI не містить коду, який не використала система. Значення а і b залежать від класу, до якого проект відноситься. Вони показані в таблиці.
Рівень складності проекту |
Робоче навантаження |
Просто |
2,4*K 1,05 |
Не просто |
3,0*K 1,12 |
Складно |
3,6*K 1,20 |
Таблиця 12.6.1. Робоче навантаження проти рівня складності.
Для маленьких проектів залежність робочого навантаження від KDSI майже лінійна. Динамічність і нелінійність зростає для коду великого розміру.
Мал. 12.6.1. Залежність робочого навантаження від KDSI.
Метод COCOMO припускає, що, знаючи робоче навантаження, ми можемо оцінити час, який дає приблизну оцінку для розміру команди і інших потрібних ресурсів. Спостереження показують, що завжди є оптимальний розмір команди для розробки проекту.
Наступні формули оцінюють розмір команди:
Простий проект: Час [місяці] = 2.5* робоче навантаження
Непростий проект: Час [місяці] = 2.5* робоче навантаження
Складний проект: Час [місяці] = 2.5* рабоче навантаження
Підрахунки потрібно скоректувати корегуючими чинниками.
Вони враховують наступні атрибути проекту:
Вимоги системної надійності,
Розмір бази даних проти розміру коду,
Складність системи: складність структур даних, алгоритмів, комунікації з іншими системами, паралельних обчислень,
Вимоги продуктивності системи,
Обмеження пам'яті,
Апаратура і програмне забезпечення, яке створюють середовище.
Недоліки методу COCOMO
Метод COCOMO має багато недоліків. Основний - те, що число рядків початкового коду відоме тільки тоді, коли він написаний. Тому оцінки зазвичай помилкові (до 100%). Оцінка залежить від технології і мови програмування. Один рядок в Smalltalk еквівалентний 30 рядкам в C. Для 4GL коефіцієнт може бути близько 1000:1. Концепція, розроблена на числі рядків початкового коду не задовольняє сучасне візуальне програмування.
Неправильний вибір модифікуючих чинників також може призвести до відмінностей між очікуваною і реальною вартістю проекту. Ідеальних методів не існує. Всі методи засновані на численних приблизних припущеннях. Проте, вони необхідні для таких проектів, оскільки вони кращі, ніж випадкові помилкові припущення.