- •Введение
- •Практическая работа №1. Тема: технология программирования. Основные понятия и подходы.
- •1.1. Назначение технологии программирования
- •1.2. История развития технологии программирования
- •1.2.1. Дореволюционный период
- •1.2.2. «Революция в программировании»
- •1.2.3. Послереволюционный период
- •1.3. Типы программных проектов
- •1.4. Составные части технологии программирования
- •1.5. Проект, продукт, процесс и персонал
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме.
- •Практическая работа №2. Тема: приемы обеспечения технологичности программных продуктов.
- •2.1. Циклический характер разработки
- •2.2. Основные понятия технологии программирования
- •2.2.1. Процессы и модели
- •2.2.2. Фазы и витки
- •2.2.3. Вехи и артефакты
- •2.2.4. Заинтересованные лица и работники
- •2.3. Выявление и анализ требований
- •2.3.1. Требования к программному обеспечению
- •2.3.2. Схема разработки требований
- •2.3.3. Управление требованиями
- •2.4. Архитектурное и детальное проектирование
- •2.4.1. Архитектурное проектирование
- •2.4.2. Детальное проектирование
- •2.5. Реализация и кодирование
- •2.6. Тестирование и верификация
- •2.6.1. Процесс контроля качества
- •2.6.2. Методы «белого ящика» и «черного ящика»
- •2.6.3. Инспектирование и обзоры
- •2.6.4. Цели тестирования
- •2.6.5. Верификация, валидация и системное тестирование
- •2.7. Сопровождение и продолжающаяся разработка
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме.
- •Практическая работа №3. Тема: определение требований к программному обеспечению и исходных данных для его проектирования. Модели процесса разработки.
- •3.1. Водопадные и конвейерные модели
- •3.2. Спиральные и инкрементные модели
- •3.4. Конструирование модели процесса
- •3.4.1. Выявление требований к процессу
- •3.4.2. Используемые фазы, вехи и артефакты
- •3.4.2.1. Фаза «Анализ»
- •3.4.2.2. Фаза «Проектирование»
- •3.4.2.3. Фаза «Реализация»
- •3.4.2.4. Фаза «Стабилизация»
- •3.4.2.5. Фаза «Внедрение»
- •3.4.3. Выбор архитектуры процесса.
- •3.4.3.1. Типы проектов
- •3.4.3.2. Модель процесса сверх легкого проекта
- •3.4.3.3. Модель процесса легкого проекта
- •3.4.3.4. Модель процесса тяжелого проекта
- •3.4.3.5. Модель процесса сверх тяжелого проекта
- •3.4.3.6. Занятость исполнителей
- •3.4.4. Порядок проведения типового проекта
- •3.4.4.1. Этап 1. Подготовка к проекту
- •3.4.4.2. Сбор и анализ предварительной информации
- •3.4.4.3. Формирование бригады проекта
- •3.4.4.4. Подготовка исходных документов
- •3.4.4.5. Этап 2. Работа над проектом
- •3.4.4.6. Процедура выполнения фазы проекта
- •3.4.4.7. Подготовка результирующих материалов вех
- •3.4.4.8. Этап 3. Завершение проекта
- •3.4.4.9. Архивирование результатов работы
- •3.4.4.10. Подведение итогов проекта
- •3.4.5. Документированные процедуры
- •3.4.5.3. Проверка качества материалов
- •3.4.6. Выводы
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме
- •Практическая работа №4. Тема: анализ требований и определение спецификаций программного обеспечения при структурном подходе.
- •4.1. Спецификации программного обеспечения при структурном подходе
- •4.2. Определение понятий и видов требований
- •Виды требований
- •4.1.2. Анализ и сбор требований
- •4.1.3. Инженерия требований по
- •4.2. Трассирование требований
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме
2.7. Сопровождение и продолжающаяся разработка
Сопровождение программного продукта включает в себя все действия, выполняемые с приложением после поставки продукта заказчику.
Сопровождение программы - это процесс изменения программной системы или компонента после поставки с целью исправления ошибок, повышения производительности или иных параметров, а также для адаптации к изменившимся условиям.
По различным оценкам сопровождение программы составляет от 40% до 90% стоимости всего жизненного цикла приложения. Можно возразить, что в указанное выше определение сопровождения включены усовершенствования, которые лучше было бы считать продолжающейся разработкой.
Продолжающаяся разработка - это разработка новых и переработка имеющихся функций программы в процессе эксплуатации.
В любом случае, объем работ по сопровождению программ обычно достаточно велик. Было подмечено любая программа, адаптацией которой к изменяющимся условиям никто не занимается, с течением времени неизбежно теряет свою ценность. Другими словами, если приложение остается неизменным, польза от него постепенно убывает. Чтобы представить, какие проблемы возникают при сопровождении программ, вообразите приложение настолько большое, что ни один человек не может знать всех его функций и особенностей. Большую проблему в сопровождении таких программ создает эффект «ряби», возникающей при внесении изменений. Когда множество относительно безвредных изменений производятся одновременно в «удаленных уголках» больших приложений, эти изменения могут приводить к повреждению приложения как целого.
Можно упорядочить проблемы, связанные с сопровождением программ, разделив их на три категории.
Проблемы управления: трудность выявления прибыли на инвестированный капитал.
Проблемы обработки: для обслуживания потока запросов на сопровождение требуется жесткая координация.
Проблемы технического характера: трудность учета всех результатов изменений; высокая стоимость тестирования по сравнению с пользой от отдельных изменений.
Следует различать работы по сопровождению, направленные на устранение дефектов (fixing) и на усовершенствование (enhancing) приложения. Различные исследования показали, что 60-80% работ обычно относится к усовершенствованию приложения, а не к исправлению его недостатков.
Последовательность обработки запросов на сопровождение состоит из анализа, проектирования, реализации и тестирования, точно так же, как и обычная разработка. Существенным отличием является необходимость анализа влияния изменений на артефакты. Согласно исследованию Вейсса, 19% дефектов в приложениях образуются на этапе определения требований, 52% — на этапе проектирования и лишь 7% — в процессе программирования. Многие другие авторы утверждают, что доля дефектов, вызванных неправильной формулировкой требований, должна быть еще выше и составляет до 30%.
В то же время практика показывает, что стоимости устранения дефектов, допущенных при разработке требований, при проектировании и при реализации относятся как 10 : 3 : 1. Это эффект нетрудно объяснить: устранение ошибки в требованиях повлечет изменение всех артефактов проекта. Устранение ошибки кодирования потребует изменить лишь один программный модуль.