- •Введение
- •Практическая работа №1. Тема: технология программирования. Основные понятия и подходы.
- •1.1. Назначение технологии программирования
- •1.2. История развития технологии программирования
- •1.2.1. Дореволюционный период
- •1.2.2. «Революция в программировании»
- •1.2.3. Послереволюционный период
- •1.3. Типы программных проектов
- •1.5. Проект, продукт, процесс и персонал
- •Вопросы для рассмотрения.
- •1.4. Составные части технологии программирования
- •Рекомендуемая литература по теме.
- •Практическая работа №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. Трассирование требований
- •Вопросы для рассмотрения.
- •Рекомендуемая литература по теме
3.4.2.3. Фаза «Реализация»
Фаза реализации (кодирования) имеет основную веху, которая называется «код готов». Хотя на этой фазе создается основной отчуждаемый результат проекта (код приложения), доля фазы реализации составляет не более 20% всех ресурсов проекта. Веха «код готов» означает, что все специфицированные функции запрограммированы, и работоспособность приложения в целом продемонстрирована на нескольких примерах.
Замечание по конструированию. Многочисленные исследования показывают, что чем крупнее проект, тем меньшую долю в нем занимает собственно кодирование.
Указанная величина 20% является ориентировочным показателем для типичного проекта. Промежуточные вехи фазы реализации зависят от типа проекта и используемого инструментального программного обеспечения. Они включают в себя:
Логический проект. Модель объектов (служб) приложения. Спецификация интерфейсов услуг (методов и свойств), предоставляемых службами (объектами).
Схема базы данных. Фиксация представления данных проекта. В случае использования стандартной реляционной СУБД — определение структуры таблиц и связей между ними.
Дизайн интерфейса. Фиксация внешнего вида статической части графического интерфейса (форм и диалоговых окон). Фиксация состава команд меню и языка пользователя, если он предусматривается проектом.
Физический проект. Упаковка служб в компоненты, описание протоколов взаимодействия компонент для распределенных приложений.
Если какие-то промежуточные вехи фазы реализации являются внешними (например, логический проект), то они относятся к внешним спецификациям и выполняются на стадии планирования.
3.4.2.4. Фаза «Стабилизация»
Фаза стабилизации (тестирования) заканчивается главной вехой, которая называется выпуск (release). Достижение этой вехи характеризуется наличием полного и подготовленного к тиражированию (копированию, передаче заказчику) комплекта отчуждаемых материалов проекта, которые были специфицированы на фазе планирования. Основной деятельностью на фазе стабилизации являются тестирование и отладка, то есть выявление и устранение ошибок. Различаются следующие виды комплексного тестирования:
Тестирование устойчивости (reliability). Целью этого вида тестирование является выявление не перехватываемых ошибок времени выполнения, т.е. тесты устойчивости нацелены на то, чтобы "сломать" приложение. Типичными приемами, применяемыми при тестировании устойчивости, являются ввод данных, выходящих за пределы области допустимых значений, нарушение порядка действий, предусмотренных сценарием, создание ситуаций, нарушающих количественные ограничения.
Тестирование функциональности (functionality). Целью этого вида тестирования является проверка того, что для допустимых (правильных) входных данных получаются допустимые (правильные, корректные, удовлетворительные, соответствующие спецификациям) результаты. Ожидаемые правильные результаты для каждого теста функциональности должны быть получены заранее независимо от тестируемого приложения. Типичным приемом является ввод предельных (находящихся на границе области допустимых значений) данных.
Тестирование применимости (usability). Целью этого вида тестирования является проверка того, что предусмотренные способы использования приложения являются удовлетворительными для пользователя при выполнении типичных сценариев работы. При тестировании применимости проверяются, например, следующие параметры: реактивность, защищенность данных, способность к восстановлению после ошибки, понятность интерфейса и др. Фаза стабилизации имеет промежуточные вехи, которые являются обязательными, если выпуск соответствующих материалов предусмотрен проектом.
Нет известных ошибок. Все тесты, предусмотренные планом тестирования, не выявляют ошибок. Все найденные и зафиксированные в базе данных ошибки помечены как исправленные.
Исходные тексты готовы. Все исходные тексты программ проверены на соответствие принятой дисциплине программирования (комментарии, имена объектов, структура текста). Некоторые советы, касающиеся хорошего стиля программирования, приведены ниже в разделе Дисциплина программирования.
Документация. Эксплуатационная (пользовательская) документация (электронная и печатная) готова к тиражированию, т. е. проверена ответственным редактором, техническим редактором и корректором, корректура внесена и проведена сверка. Если заказчик согласен, то выпуск пользовательской документации может быть перенесен на фазу опытной эксплуатации.
Замечание по конструированию. Техническая подготовка документации (так называемая предпечатная подготовка) и само тиражирование (если оно предусмотрено планом) в ответственных проектах может выполняться специалистами, не входящими в состав команды проекта, поэтому оно не упоминается в описании процесса.