- •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. Короткий звіт
4. Модель якості iso-9126
Ця модель якості припускає, що є шість груп, що беруться до уваги при оцінці якості: функціональність, надійність, практичність, ефективність, ремонтопридатність, виносливість.
Під функціональністю ми розуміємо задоволення вимог, тобто придатність, точність, сумісність і безпека операцій.
Під надійністю розумієтся, що програма достатньо продуманна, функціонуватиме в межах необхідної допустимої похибки і відновлюватиметься при збої.
Практичність розуміється як раціональність і простота системи. Систему потрібно розробляти для користувача, якого потім буде легко навчити нею користуватись.
Ефективність означає, що час, потрібний для реалізації запиту, прийнятний і що ресурси середовища, в якому система працює, використовуються раціонально.
Ремонтопридатність означає можливість введення змін, виконання перевірки, гарантуючи стабільність і доступність.
Виносливість означає, що система працюватиме на різних платформах.
5. Управління якістю
Метою управління якістю є задоволення клієнта. Клієнт вирішує, чи потрібна йому програма. Це відноситься до внутрішніх і зовнішніх клієнтів. Повинні бути сформовані відповідні стандарти, у відповідності до пропозицій керівника розробки, який визначає ступені значущості і може переконати членів команди у важливості відповідних стандартів. Неможна говорити про якість без позитивного враження про проект, мотивації і відповідного навчання.
В управлінні якістю ми беремо до уваги два поняття: процесовий підхід і системний підхід. У процесовому підході розглядаються окремі кроки, аналізуються взаємозв'язки між процесами. У системному підході необхідне розуміння системи і всього виробництва. Необхідна якість програми забезпечується, якщо обидва підходи задоволено і вони доповнюють один одного. Тому ми повинні зосередитися на кроках, не забуваючи про системне бачення.
Якість забезпечується, якщо члени команди добре навчені і їх навики розвиваються (але не шляхом революції). Необхідний відповідний, повний збір інформації. Без цього зворотного зв'язку не можна вносити зміни.
Співпраця також є чинником управління якістю. Близькі відносини з клієнтами і відповідне визначення потреб дуже важливі.
Гарантія якості програмного забезпечення
Гарантія якості програмного забезпечення - "плановий і систематичний набір необхідних дій для оцінки відповідності програми вимогам".
Гарантія якості програмного забезпечення (SQA, software quality assurance) визначає, чи задовольняють плани стандарти, чи слідують процедури планам, чи реалізовуються продукти згідно планам.
Перевірити все неможливо. Тому є особливо важливі ділянки, які визначаються і контролюються.
У SQA план всіх дій повинен бути встановлений. Він назваєтся "план гарантії якості програмного забезпечення".
Ризик втрати якості
Загальний критерій - ризик втрати якості. Чинниками, які можуть викликати втрату, є: інноваційний проект, його складність, нестача знань та досвіду персоналу, неформальні (створені спонтанно і непродумано) процедури, незрілість виробника.
Щоб мінімізувати ризик SQA, персонал повинен бути залучений у виробництво на найраніших стадіях. Він повинен перевірити вимоги користувача, плани, процедури і документи. Згода з існуючими процедурами повинна бути перевірена, оскільки ціна помилки, виявленої за пізно, може бути дуже великою.
Завдання гарантії якості програмного забезпечення
Завдання розглядаються на двох рівнях: на рівні компанії і проектному рівні. На рівні компанії це постійна підтримка системи, спостереження, стандартне визначення і схвалення виробництва.
На проектному рівні завдання містять в собі: задоволення стандартам, огляди проектів, тестування, інспекції, оцінку виробничих планів, перевірку конфігурації управління і залучення організаційної комісії.
У великих проектах, де є спеціальні посади для гарантії якості, персонал SQA відповідальний за багато дій, наприклад, за організацію проекту, за життєвий цикл, за відповідні призначення завдань. Завдання повинні обговорюватися з відповідальним супервізором.
Важливе завдання в SQA - підготовка, вміст і організація документації.
Збір, організація і використання вимірювань також є важливим завданням.
Також повинні враховуватися завдання, що мають відношення до процесів перегляду, тестування, перевірка, реєстрація проблем і реакція на них.
Є і інші завдання, які потрібно взяти до уваги:
Відповідні інструменти, техніка і методи, контроль стану програмного забезпечення (відповідні бібліотеки, безпека), перевірка відповідності програмного забезпечення стандартам, реєстрація всіх дій в проекті, перевірка підготовки персоналу і визначення небезпек.
Для того, щоб реалізувати вище перелічені завдання, задаються критерії і будуються моделі. Вартість, робоче навантаження, відповідне вживання заходів, забезпечення надійності, продуктивності, визначення структур і зрілість проекту оцінюється на основі критеріїв і моделі.
Групи SQA
Завдання SQA можуть бути розбиті на наступні групи:
-
атестація системи перед постачанням
-
стандартне примушення в зборі даних і їх зберіганні
-
перегляд і атестація документації
-
розробка системної архітектури і стандартів програмування
-
перегляд проекту з точки зору його завершеності
-
тестування нової зміненої системи
-
розвиток стандартів менеджменту
-
навчання
Вимірювання грають важливу роль. Проте, їх сприймають як одну з додаткових дій, а не основу гарантії якості.