- •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. Короткий звіт
4.Концептуальне моделювання
Важливий шлях обмеження кризи ПЗ - це розробка концептуальної моделі.
Люди,що проектують і програмують повинні концептуалізувати проблему. Базовий процес розробки завершується в людській голові і не вимагає використання якоїсь мови програмування. Зміст концептуального моделювання і концептуальної моделі полягає в обдумуванні і представленні по'язаного з розробкою ПЗ. Такі моделі відображають реальні процеси моделювання інформації, процеси обробки інформації, структуру даних і програм.
Малюнок 1.5.1. Концептуальне моделювання.
Життєві цикли програмного забезпечення
Існують наступні моделі розробки ПЗ: класична модель водоспаду, покрокова модель, збірка по частинах, модель спіралі та ін.
Розробка і експлуатація ПЗ - процес, який повинен бути систематизований. Для того ,щоб це відбулося потрібно сформулювати безлічі моделей циклу життя програмного забезпечення. Ці моделі представляють етапи життя програмного забезпечення, визначають дії, що проводяться на конкретному етапі, розписують черговість виконання цих етапів. Цикли життя програмного забезпечення дають змогу планувати роботу, ведучи послідовне планування і контролюють виконання.
Модель водоспаду
Модель водоспаду, відома також як каскадна модель або лінійна модель, є класичною моделлю циклу життя програми. Модель була запропонована по аналогії з методами, що використовуються в інших технічних дисциплінах, наприклад в проектуванні будівель. Конструкція моста починається з визначення основних інструментів, потрібних для його будівництва, а потім формулюється деталі для того, щоб досягти цілі. Наступний крок - спроектувати міст. За цим слідує будівництво і тестування. Останній етап полягає в підтримці будови.
Малюнок 2.2.1. Каскадна модель життєвого циклу програмного забезпечення.
Каскадна модель вводить наступні цикли розробки програмного забезпечення:
етап визначення вимог ( формулюються цілі і деталі для майбутньої системи)
етап проектування ( деталі проекту розвиваються для того, щоб забезпечити відповідні вимоги)
етап реалізації/написання коду і тестування модулів ( реалізується і тестується дизайн в даному програмному середовищі)
етап тестування ( відбувається об'єднання модулів і тестування всієї системи)
етап підтримки ( замовник використовує продукт, а виробник його підтримує, вносить зміни і розширює функціональність).
Існують іншші розбиття циклів. Ці розбиття можуть враховувати більше або менше деталей. Але найважливішим залишається - лінійність цього процесу. Під лінійністю розуміємо послідовне виконання етапів.
У каскадній моделі представлені такі етапи:
стратегічний етап ( здійснюється перед формальним ухваленням рішень. На цьому етапі ухвалюються деякі стратегічні рішення про майбутню роботу. Цей етап вимагає як мінімум найзагальнішого формулювання вимог).
етап аналізу ( будується логічна модель системи).
етап документації ( готується призначена для користувача документація. Документація виготовляється паралельно з ПЗ. Цей етап може починатися одночасно з формулюванням вимог. Вважається, що інструкція користувача є хорошою документацією для вимог. Останнні зміни в документації відбуваються установки).
етап установки ( система передається користувачеві).
Переваги і недоліки моделі
Основна перевага каскадної моделі - керованість. Модель полегшує планування і моніторинг.
Серед недоліків є наступні:
Необхідність дотримуватись встановленого порядку проведення робіт.
Програмісти віддають перевагу вільнішому стилю роботи.
Підвищення ціни наслідків помилок, зроблених на різних етапах. Помилки,
зроблені на етапі формулювання вимог, будуть виявлені лише на етапі перевірки або навіть на етапі підтримки. Вартість цих помилок може значно перевищити вартість помилок, зроблених протягом етапу реалізації.
Довгий період, протягом якого немає контакту з клієнтом. Тільки стратегічний етап, формулювання вимог і етапу аналізу здійснюються за участю клієнта.
Дизайн, реалізація і тестування повністю покладаються на компанію. Тому існує ризик втрати зацікавленості клієнта.