![](/user_photo/2706_HbeT2.jpg)
- •VIII. Розробка інтернет-програм
- •IX. БдБ і БдС системи
- •X. Реалізація
- •XI. Тестування
- •Введення в розробку програмного забезпечення
- •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. Документ з вимогами
- •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)
- •Формулювання вимог
- •Проект структури даних
- •Гіпертекстовий проект
- •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 Управління конфігурацією
- •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. Короткий звіт
6. Стандарти якості
Стандарт IEEE-730 надає загальні критерії оцінки якості. Він містить: точку зору аналізу, посилання, виробників, управління інформаційною системою, документацію, стандарти розробки, перегляд, управління конфігурацією програмного забезпечення, звіти про проблеми і відновлення, запобіжні заходи, використані методи і інструменти, управління кодом, сховища даних, кодову підтримку.
Мал. 14.7.1. Стандарти якості.
Стандарт IEEE-730 було удосконалено і уточнено стандартом IEEE-983.
Модель якості програмного забезпечення
Модель якості програмного забезпечення зображена на малюнку 14.7.2.
Мал. 14.7.2. Модель якості програмного забезпечення.
7. Незрілість і зрілість виробництва
Незрілість визначається наступними чинниками:
-
імпровізація у виробничому процесі,
-
процес вказаний, але специфікація не використовується,
-
не дотримання бюджету і графіку,
-
недостатня функціональність,
-
низька якість продукції,
-
немає об'єктивних критеріїв.
Зрілість виробництва визначається наступними чинниками:
-
здатність використовувати сучасне програмне забезпечення (здатність всієї організації, а не окремого співробітника),
-
процес визначений, відомий і вдосконалений,
-
робота планується і контролюється,
-
розподілені ролі і відповідальність,
-
існує об'єктивна, якісна і кількісна оцінка.
CMM – модель технологічної зрілості організації
Робота по вимірюванню можливостей виробників програмного забезпечення була ініційована в Департаменті Оборони США в сімдесятих роках. Інститут Розробки Програмного Забезпечення ввів модель технологічної зрілості організації - CMM (Capability Maturity Model).
Модель технологічної зрілості організації стала дуже популярною. Модель припускає, що вищого рівня культури процесу можливо досягти, тільки тоді, якщо зрозуміти відповідні чинники. Вона використовує поняття глобального управління якістю (TQM, Total Quality Management). Є п'ять рівнів технологічної зрілості організації:
Мал. 14.8.1. Модель технологічної зрілості організації
.
У моделі технологічної зрілості організації розрізняють 5 наступних рівнів:
-
початковий рівень – 1 (хаотичний процес),
-
ітеративний рівень – 2 (індивідуальний процес),
-
визначений рівень – 3 (постанова обробки процесів),
-
рівень управління – 4 (процес + зворотний зв'язок для процесу),
-
рівень оптимізації – 5 (процес + зворотний зв'язок для вдосконалення процесу).
Процеси класифікуються, грунтуючись на детальній анкеті, що завершується інтерв'ю і зборами матеріалів. Кожен рівень характеризується ключовою областю процесу (KPA, Process Key Area).
Наприклад, для другого рівня визначають наступні KPA: управління вимогами, проектне планування, трасованість, управління підзапитами, гарантія якості і управління конфігурацією. П'ятий рівень має наступну ключову областю процесу: захист від дефектів, управління змінами, управління змінами апаратури.
Важлива причина, яка робить модель технологічної зрілості організації популярною - рівень номер 3, який дозволяє укладати контракти з Департаментом Захисту США. Практика показує, що дістатися до рівня 3 для багатьох компаній просто неможливо. До рівня номер 5 належать тільки декілька компаній: IBM, яка виробляє програмне забезпечення для НАСА і Motorola.