- •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. Короткий звіт
I Вступ
-
Цілі. Коротко описує цілі ПУКПЗ (чому і для кого розробляється)
-
Границі. Коротко описує елемент конфігурації, його дії, організацію і життєвий цикл.
-
Посилання. Містить список всіх документів, з вказівкою їх назви, автора, дати, номера і т.д.
II Управління
Розділ описує організацію УКПЗ, дії і посади.
-
Організація. Цей підрозділ описує посади, які впливають на УКПЗ. Так само описуються менеджери за проектом, програмісти, персонал оцінки гарантії якості, відділи перегляду, ревізії і затвердження, їх взаємовідношення і зв'язки.
-
Розподіл відповідальності в УКПЗ. Описує функції, покладені на конкретні посади, наприклад, визначення інтерфейсу компонентів, зберігання, контроль змін, визначення стану. Привласнюються відповідальності за перегляд, схвалення і затвердження.
-
Управління зовнішнім інтерфейсом. Обговорюються процедури управління взаємодією зовнішньої апаратури і ПЗ.
-
Реалізація ПУКПЗ. Ключовими елементами ПУКПЗ є готовність системи УКПЗ, відділ перегляду, версії продукту і т.д.
-
Застосовані рекомендації, стратегії і процедури. Визначаються застосовні стратегії і дається їх інтерпретація.
III Визначення конфігурації
Угоди
Приймається угода про використання імен і міток.
Базиси
Для кожного базису визначається наступне:
-
ідентифікатор,
-
зміст. Наприклад, ПЗ, інструменти, тестування, звіти про несумісність, визначення проблем,
-
інтерфейси продукції,
-
перегляд і ухвалення,
-
спільна робота розробника і користувача в конкретном базисі.
IV Управління конфігурацією
-
Управління кодом і документом. Описує процедури управління бібліотекою коду і документації: бібліотека розробки ПЗ, головна бібліотека (базисів) і архіви.
-
Управління носіями. Описує які носії і коли використовуватимуться для зберігання інтерфейсів компонентів. Угода про привласнення міток, способи і місця зберігання інтерфейсів користувача і їх повторне використання.
-
Управління змінами
-
рівень затвердження змін. Визначає рівень повноважень для затвердження базисів (бібліотекар, менеджер проекту).
-
процедура змін. Описує процес внесень змін.
-
відділ перегляду (рада, комітет правління). Описує членів відділу перегляду, рівень повноважень, делегування нижньому рівню прав.
V Реєстрація статусу конфігурації
Визначає спосіб зберігання і обробки інформації про інтерфейс компонентів, звіти про їх стан.
VI Інструменти, техніка і методи в УКПЗ
Описує інструменти і методи, використані в УКПЗ.
VII Контроль постачальника
Описує завдання зовнішніх постачальників.
VIII Запис і зберігання документів
Визначає, які елементи конфігурації повинні зберігатися, в якій формі і як довго.
8. Короткий звіт
Цілями УКПЗ є планування, організація, контроль і координація всіх дій, які мають відношення до визначення, зберігання і зміни ПЗ в процесі його розробки, інтеграції і доставки користувачеві.
Кожен продукт повинен мати свою конфігурацію. Це критично важливо для фінальної версії продукту, її ефективності і підтримки.
XIV. Якість програмного забезпечення
Якість програмного забезпечення дуже важлива. Програмне забезпечення повинно відповідати очікуваним параметрам якості.
1. Якість програмного забезпечення.
Гарантія якості розуміється як переконання всіх зацікавлених в тому, що продукт виправдовує очікування, задовольняє стандарти і виконує необхідні функції.
Проблема якості містить в собі як кількісні заходи, так і суб'єктивні чинники. Висновки грунтуються на вимірюваннях деяких параметрів, як, наприклад, надійність, швидкість і т.д.
На жаль, об'єктивні вимірювання дуже важко зробити і навіть неможливо. Оцінити якість програми дуже важко, оскільки кількість і складність вимірювань можуть бути великими, програмне забезпечення має багатофункціональні властивості, а варіанти поведінки непередбачувані.
Критерії повинні бути визначені перед тим, як програма буде зроблена. Багато чинників не підлягають вимірюванню. Програмні продукти складно оцінити, оскільки важко ввести параметри вимірювання.
Програми можуть використовуватися в різних умовах і масштабі. Вимірювання, взяті в одному масштабі, можуть не відповідати їм в іншому. Також вони можуть бути дорогими, дуже тривалими або просто неможливими.
Важко об'єднати проведені вимірювання в одне ціле. Тому дуже велику роль відіграють спрощуючі методи. Ці методи вводять нові алгоритми, формули, обмеження і евристику.
2. TQM – управління за якістю
Поняття TQM було введене японцем Eiji Toyode для японської автомобільної промисловості в 1950. Первинна ідея полягала в тому, що задоволення клієнта - найголовніше, оскільки клієнт впливає на дохід підприємства.
TQM був остаточно сформульований американцями (W.Q. Deming, P. Crosby, J.M. Juran, A.V. Feigenbaum), японцями (E. Toyoda, М. Imai, K. Ishikawa), і британцем J. Oakland.
Кожен з вище названих авторів визначив власні принципи TQM. Всі вони слідують принципу Toyoda: "Якість - найголовніше для клієнта. Пам'ятаєте, що саме завдяки клієнтам компанія працює ". Тому виробник поганої продукції буде вигнаний з ринку.
3. Якість в ISO
Якість - термін, який залежить від середовища, культури і сприйняття групи. Якість розуміється дуже суб'єктивним чином. Тому складно дати чітке визначення якості.
Стандарти ISO - 9000 намагаються визначити термін "якість" і інші пов'язані з ним терміни. Стандарт визначає важливі поняття.
Список найголовніших понять:
Якість – всі характеристики і властивості, які визначають, на скільки продукт задовольняє призначені для користувача потреби.
Система якості - структура групи людей з відповідними розподіленими відповідальностями, процедурами, процесами і ресурсами. Структура гарантує контроль якості.
Управління якістю – всі функції, які дають оцінку якості.
Стандарти якості – всі директиви і дії, зроблені для того, щоб забезпечити якість продукту; формальний опис, даний менеджерами системи якості.
Перевірка якості - незалежне і систематичне дослідження, яке вирішує, чи відповідають дії і їх результати очікуванням, чи реалізовані ухвалені рішення і чи забезпечений відповідний рівень якості.
Стандарти і система якості
Стандарти - загальні правила якості, яким продукт повинен відповідати. Компанія робить ці наміри формальними.
Стандари повинні бути визначені і документовані. Повинні бути описані загальні і стратегічні цілі і зобов'язання компанії за якістю. Стандарти повинні знати і розуміти на всіх рівнях управління і серед всіх працівників.
Система якості - структура з розподіленою відповідальністю, використанням ресурсів для задоволення вимог якості, зразком якості; документованими процедурами для задоволення якості.
Якість програмного забезпечення
Якість - загальне поняття. Тому визначення повинне бути детальнішим. Ми представляємо два визначення якості програмного забезпечення.
Згідно стандарту ISO-9000-3:
Якість програмного забезпечення - характеристики і особливості системи, які визначають ступінь задоволення документованих або очікуівних потреб користувача.
Згідно стандарту IEEE-610-12:
Якість програмного забезпечення - ступінь відповідності програмного забезпечення необхідному набору характеристик.