1. Требования
1.1. Уровни
1.1.1. Бизнес
1.1.1.1. Зачем создаётся продукт, какие и чьи проблемы он решает, какие возможности он кому предоставляет, и, отчасти, как он будет создаваться.
1.1.2. Пользовательские
1.1.2.1. Кто и как взаимодействует с продуктом.
1.1.2.2. Как устроен продукт и его функционал.
1.1.3. Функциональные
1.2. Основы
1.2.1. Определение
1.2.1.1. Требования
1.2.1.1.1. Некоторые условия или свойства, которым должна соответствовать система.
1.2.1.2. Требования к продукту или к процессу
1.2.1.3. Функциональные и нефункциональные
1.2.1.4. Свойства
1.2.1.4.1. Полнота
1.2.1.4.2. Ясность
1.2.1.4.3. Корректность и согласованность
1.2.1.4.4. Верифицированность
1.2.1.4.5. Необходимость и полезность при эксплуатации
1.2.1.4.6. Осуществимость
1.2.1.4.7. Трассируемость
1.2.1.4.8. Упорядоченность
1.2.1.5. Количественная оценка
1.2.1.6. Системные и программные требования
1.3. Извлечение
1.3.1. Стратегия выявления требований
1.3.1.1. Интервьюирование
1.3.1.2. Анкетирование
1.3.1.3. Наблюдение
1.3.1.3.1. Через наблюдение а возможно и участие аналитики получают информацию о происходящих операциях. Во время наблюдения за работой системы часто возникают вопросы которые никогда бы не появились если бы аналитик только читал или разговаривал с экспертами
1.3.1.4. Самостоятельное описание требований
1.3.1.5. Совместный семинар
1.3.1.6. Прототипирование
1.3.2. Источники
1.3.2.1. Заказчик
1.3.2.2. Работники предприятия
1.3.2.3. Документация
1.3.2.3.1. Чтение документов - способ получить представление о системе и сформулировать вопросы к экспертам.
1.3.2.4. Важные работники предприятия
1.3.2.5. Прототип
1.4. Процесс работы
1.4.1. Модель процесса определения требований
1.4.1.1. Схема процессов ЖЦ, которые выполняются от начала проекта до тех пор пока не будут определены и согласованы требования
1.4.2. Участники процессов
1.4.2.1. Пользователи
1.4.2.2. Заказчики
1.4.2.3. Аналитики
1.4.2.4. Регуляторы
1.4.2.4.1. Согласуют с законом
1.4.2.5. Инженеры по ПО
1.4.3. Управление и поддержка процессов
1.4.3.1. Цель – обеспечение связи между процессами и деятельностью и вопросами использования проектных ресурсов – стоимостью, человеческими ресурсами, инструментами и т.д.
1.4.3.1.1. Распределение ресурсов
1.4.3.1.2. Инициация и определение содержания
1.4.3.1.3. Управление в программной инженерии
1.4.4. Качество процессов
1.4.4.1. Особое значение заключается в подчеркивании значимости работы с требованиями, ключевой роли этих процессов для определения стоимостных и временных ресурсов
1.4.4.1.1. Планирование и реализация процесса улучшения
1.4.4.1.2. Измерение и количественная оценка
1.4.4.1.3. Покрытие работы с требованиями с точки зрения стандартов и моделей услуг процесса
1.5. Анализ
1.5.1. Классификация требований
1.5.1.1. Требования к продукту или к процессу
1.5.1.2. Функциональные и нефункциональные
1.5.2. Концептуальное моделирование
1.5.2.1. Цель моделирования – понимание проблемы, задачи и методов их решения до того, как начнется решение проблемы
1.5.2.1.1. Факторы, влияющие на выбор модели, метода, детализации ее представления и т.д. :
1.5.3. Сбор требований
1.5.4. Архитектурное проектирование и распределение требований
1.5.4.1. Создание архитектуры программных решений. Инженеры действуют как архитекторы, потому как процессы анализа и выработки требований зависят от программных компонентов, создаваемых для решения поставленных задач, призванных добиться реализации поставленных целей
1.5.4.1.1. Стандарт ISO 12207
1.5.4.1.2. Модель Захмана
1.5.4.1.3. TOGAF
1.6. Спецификация
1.6.1. Определение системы
1.6.1.1. Описание системных требований вместе с необходимой информацией о бизнес-процессах, операционном окружении с точки зрения бизнес-процедур и организационных и других регламентов
1.6.2. Спецификация системных и программных требований
1.7. Проверка
1.7.1. Обзор требований
1.7.1.1. Ряд лиц, вовлеченных в проект, “вычитывают” требования в поисках различных несостыковок
1.7.2. Прототипирование
1.7.3. Утверждение модели
1.7.3.1. Связано с вопросами обеспечения приемлемого качества продукта
1.7.4. Приемочные тесты
1.8. Проектирование соображений
1.8.1. Интеративная природа процесса
1.8.1.1. Понимание и интерпретация требований продолжает эволюционировать и меняться в процессе проектирования и разработки ПО
1.8.2. Управление изменениями
1.8.2.1. Необходимость определения процедур для обработки изменений
1.8.3. Атрибуты требований
1.8.4. Трассировка требований
1.8.4.1. Обеспечение связи между требованиями и отслеживание источников требований
1.8.5. Измерение требований
2. Конструирование
2.1. Основы
2.1.1. Минимизация сложности
2.1.1.1. Основной причиной того, почему люди используют компьютеры в бизнес-целях, являются ограниченные возможности людей в обработке и хранении сложных структур и больших объемов информации, в частности, на протяжении длительного периода времени.
2.1.1.1.1. Придание большей значимости читаемости кода, простоте тестирования, приемлемому уровню производительности и удовлетворению заданных критериев
2.1.2. Ожидание изменений
2.1.2.1. ПО являются частью изменяющейся среды и должны меняться вместе с ней, а, иногда, и быть источником изменений самой среды
2.1.3. Конструирование с возможностью проверки
2.1.3.1. Построение программных систем должно помогать вести поиск проблем и сбоев, будучи прозрачной для применения проверки.
2.1.4. Стандарты в конструировании
2.1.4.1. Коммуникационные методы
2.1.4.2. Языки программирования и соответствующие стили кодирования
2.1.4.3. Программные платформы (Win32 API, .NET Framework SDK и т.д.)
2.1.4.4. Инструменты (UML, DFD и т.д.)
2.2. Управление
2.2.1. Модели конструирования - комплекс операций, включающих последовательность, результаты и другие аспекты, связанные с общим жизненным циклом разработки (водопадная, поэтапная модель ЖЦ, XP, Scrum и т.д.)
2.2.2. Измерения в конструировании
2.2.3. Планирования конструирования
2.2.3.1. Выбор метода (методологии) конструирования является ключевым аспектом для планирования конструкторской деятельности.
2.3. Практические соображения
2.3.1. Проектирование
2.3.1.1. На стадии конструирования приходится заниматься и вопросами детального дизайна системы. Такие проектные работы имеют стремление к следованию устойчивым ограничениям, навязываемым конкретными проблемами, решение которых должно быть обеспечено использованием конструируемого ПО
2.3.2. Языки конструирования
2.3.2.1. Конфигурационный - позволяет задавать параметры выполнения программной системы
2.3.2.2. Инструментальный – язык конструирования из повторно-используемых элементов
2.3.2.3. Язык программирования - содержит минимальный объем информации о конкретных областях приложения и процессе разработки, требуя больше всего усилий на изучение и наработку опыта для эффективного применения при решении конкретных задач.
2.3.3. Кодирование
2.3.4. Тестирование
2.3.4.1. Модульное тестирование
2.3.4.2. Интеграционное тестирование
2.3.5. Повторное использование
2.3.5.1. Практика повторного использования на основе интеграции процессов и деятельности по повторному использованию в сам жизненный цикл программного обеспечения
2.3.5.1.1. Выбор единиц (units), баз данных тестовых процедур и т.д.
2.3.5.1.2. Оценка потенциала повторного использования
2.3.5.1.3. Отслеживание информации и создание отчетности по повторному использованию
2.3.6. Качество
2.3.6.1. Основные техники обеспечения качества
2.3.6.1.1. Модульное и интеграционное тестирование
2.3.6.1.2. Разработка с первичностью тестов
2.3.6.1.3. Пошаговое кодирование
2.3.6.1.4. Использование процедур утверждений
2.3.6.1.5. Отладка
2.3.6.1.6. Технические обзоры
2.3.6.1.7. Статический анализ
2.3.7. Интеграция
2.3.7.1. Одна из ключевых деятельностей. некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением
3. Проектирование ПО
3.1. Основы проектирования
3.1.1. Общие концепции
3.1.1.1. Цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения
3.1.2. Контекст программного дизайна
3.1.2.1. В качестве контекста выступает жизненный цикл программной инженерии
3.1.3. Процесс проектирования
3.1.3.1. 1. Архитектурное проектирование – декомпозиция структуры и организации компонентов
3.1.3.2. 2. Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент
3.1.4. Техники применения
3.1.4.1. Абстракция - модель, упрощающую поставленную проблему до рамок, значимых для заданного контекста
3.1.4.2. Связанность и соединение
3.1.4.3. Декомпозиция и разбиение на модули
3.1.4.4. Инкапсуляция/сокрытие информации - группировка и упаковка элементов и внутренних деталей абстракции
3.1.4.5. Разделение интерфейса и реализации
3.1.4.6. Достаточность, полнота и простота - компоненты обладают всеми необходимыми характеристиками, определенными абстракцией, но не более
3.2. Ключевые вопросы
3.2.1. Параллелизм в проектировании
3.2.1.1. Вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности обработки информации
3.2.2. Контроль и обработка событий
3.2.3. Распределение компонентов
3.2.3.1. Один из важнейших вопросов данной темы – использование связующего программного обеспечения
3.2.4. Ошибки обработки исключений и защищенность от сбоев
3.2.5. Взаимодействие и представление
3.2.5.1. Представление информации пользователям и взаимодействие пользователей с системой, с точки зрения реакции системы на действия пользователей
3.2.6. Сохраняемость данных
3.2.6.1. Как должны обрабатываться “долгоживущие” данные
3.3. Структура и архитектура ПО
3.3.1. Архитектурные структуры и точки зрения
3.3.1.1. Структура - применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но отсутствуют в используемом представлении
3.3.2. Архитектурные стили
3.3.2.1. Шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда
3.3.3. Шаблоны проектирования
3.3.3.1. Определяют частные аспекты деталей архитектуры.
3.3.4. Свойства программ и фреймворков
3.4. Анализ качества и оценка программного дизайна
3.4.1. Атрибуты качества
3.4.1.1. Помогают оценить и добиться качественного дизайна архитектуры (концептуальная целостность дизайна, непротиворечивость, полнота, завершенность и т.д.)
3.4.2. Анализ качества
3.4.2.1. Обзор дизайна
3.4.2.2. Статический анализ
3.4.2.3. Симуляция и прототипирование
3.4.3. Измерения
3.4.3.1. Используются для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна (размер проекта, сложность структуры и т.д.)
3.5. Нотации проектирования ПО
3.5.1. Структурные описания
3.5.1.1. Графическое описание и представление структурных аспектов программного дизайна
3.5.2. Поведение описания
3.5.2.1. Описание динамического поведения программных систем и их компонентов
3.6. Стратегии и методы
3.6.1. Общие стратегии
3.6.1.1. “разделяй-и-властвуй” и пошаговое уточнение
3.6.1.2. проектирование “сверху-вниз” и “снизу-вверх”
3.6.1.3. абстракция данных и сокрытие информации
3.6.1.4. итеративный и инкрементальный подход
3.6.2. Функционально-орииентированный
3.6.2.1. Декомпозиция сфокусирована на идентификации основных программных функций и затем детальной разработке и уточнении этих функций “сверху-вниз”.
3.6.3. Проектирование на основе структур данных
3.6.3.1. Фокус по большей степени на структурах данных, которыми управляет система, чем на функциях системы
3.6.4. Компонентное проектирование
3.6.4.1. Программные компоненты являются независимыми единицами, которые обладают однозначно определенными интерфейсами и зависимостями и могут собираться и развертываться независимо друг от друга.
3.6.5. Другие методы
4. Поддержка при эксплуатации
4.1. Основы
4.1.1. Сопровождение - модификация ПО после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и т.д. или адаптации продукта для использования в модифицированном окружении.
4.1.1.1. Необходимо для обеспечения того, чтобы программный продукт на протяжении всего периода эксплуатации удовлетворяет требованиям пользователей.
4.1.1.2. Потребляют значительную часть финансовых ресурсов жизненного цикла программного обеспечения
4.1.2. Категории
4.1.2.1. Корректирующее - “реактивная” модификация ПО, после передачи в эксплуатацию для устранения сбоев
4.1.2.2. Адаптирующее - модификация ПО на этапе эксплуатации в измененном бизнес-окружении
4.1.2.3. Совершенствующее - модификация ПО на этапе эксплуатации для повышения производительности и удобства сопровождения
4.1.2.4. Профилактическое - модификация ПО на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, когда они приведут к реальным сбоям
4.2. Ключевые вопросы
4.2.1. Технические
4.2.1.1. Ограниченное понимание - как быстро инженер по сопровождению может понять, где необходимо внести исправления/изменения в код, который он не разрабатывал.
4.2.1.2. Организация работ по тестированию модификаций эксплуатируемых систем
4.2.1.2.1. Сложно найти время
4.2.1.2.2. Координация в проведении тестов
4.2.1.2.3. Распределение стоимости
4.2.1.3. Анализ влияния - как проводить полный анализ возможных последствий и влияний изменений, вносимых в существующую систему
4.2.1.4. Возможность сопровождения - легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований
4.2.2. Управленческие
4.2.2.1. Организационная цель - как продемонстрировать возврат инвестиций от деятельности по сопровождению
4.2.2.2. Привлечение и удержание квалифицированного персонала по сопровождению
4.2.2.3. Организационные вопросы подразумевают какая организация будет отвечать и/или какие функции необходимо выполнять для обеспечения сопровождения
4.2.2.4. Аутсорсинг - передача работ, в первую очередь вспомогательных, на сторону.
4.2.3. Оценка стоимости сопровождения
4.2.3.1. Понимание разницы в различных категориях сопровождения. Это необходимо для оценки соответствующих затрат
4.2.4. Измерения в сопровождении
4.2.4.1. Формы и данные измерений в могут объединяться в единую корпоративную программу количественных оценок, проводимых в отношении ПО
4.2.4.1.1. Анализируемость
4.2.4.1.2. Изменяемость
4.2.4.1.3. Стабильность
4.2.4.1.4. Тестируемость
4.3. Процесс
4.3.1. Процессы сопровождения
4.3.1.1. Реализация процесса
4.3.1.2. Анализ проблем и необходимых модификаций
4.3.1.3. Проведение модификаций
4.3.1.4. Оценка и принятие проведенных работ при сопровождении
4.3.1.5. Миграция
4.3.1.6. Вывод из эксплуатации
4.3.2. Уникальные работы
4.3.2.1. Передача - контролируемая деятельность по передаче ПО от разработчиков группе, отвечающей за дальнейшую поддержку
4.3.2.2. Анализ влияния - анализ возможных последствий изменений, вносимых в существующую систему
4.3.2.3. Принятие/отклонение запросов на модификацию
4.3.3. Работы по планированию сопровождения
4.3.3.1. Бизнес-планирование
4.3.3.2. Планирование работ по сопровождению
4.3.3.3. Планирование релизов/версий
4.3.3.3.1. Идентификация постоянных конфликтов
4.3.3.3.2. Достижения соглашения с пользователем
4.3.3.3.3. Оценка рисков
4.3.3.4. Планирование обработки запросов на изменение
4.3.4. Конфигурационное управление - критически важный элемент сопровождения
4.3.4.1. Проверка, аттестация и аудит на всех шагах, требуемых для идентификации, авторизации, реализации и выпуска ПО
4.3.5. Качество ПО
4.3.5.1. Должны планироваться и реализовываться соответствующие процедуры и процессы, направленные на повышение качества
4.3.5.2. Работы по обеспечению качества должны отбираться в контексте взаимодействия и согласования с другими процессами, направленными на достижение желаемого уровня качества
4.4. Практики
4.4.1. Понимание программных систем
4.4.2. Реинжиниринг - детальная оценка и перестройка ПО для формирования понимания, воссоздания и дальнейшей реализации функций в новой форме
4.4.2.1. В основном проводится для замены устаревшего ПО
4.4.3. Обратный инжиниринг - процесс анализа ПО с целью идентификации программных компонентов и связей между ними, а также формирования представления о ПО, с дальнейшей перестройкой в новой форме
4.4.3.1. Создание новой документации на существующую систему
4.4.3.2. Восстановление дизайна системы
5. Тестирование
5.1. Основы
5.1.1. Терминология тестирования
5.1.1.1. “Глоссарии терминов по программной инженерии” – IEEE Standard 610-90
5.1.1.2. Дефект - причины нарушения работы ПО
5.1.1.2.1. Сбой - наблюдаемый нежелательный эффект, вызываемый дефектом
5.1.2. Ключевые вопросы
5.1.2.1. Критерии отбора тестов/критерии адекватности тестов, правила прекращения тестирования
5.2. Уровни
5.2.1. Тесты "над чем-то" (над отдельным модулем, их группой или системой)
5.2.1.1. Модульное тестирование
5.2.1.2. Интеграционное тестирование
5.2.1.3. Системное тестирование
5.2.2. Тестирование целей (функциональных/нефункциональных требований)
5.2.2.1. Приемочное - проверяет поведение системы на предмет удовлетворения требований заказчика
5.2.2.2. Установочное - проверки процедуры инсталляции системы в целевом окружении
5.2.2.3. Альфа- и бета-тесты
5.2.2.4. Функциональные - проверка соответствия системы, предъявляемым к ней требованиям, описанным в спецификации поведенческих характеристик
5.2.2.5. Регрессионное - повторное выборочное тестирование системы или компонента для проверки сделанных модификаций
5.2.2.6. Тестирование производительности - проверка удовлетворения специфических требований, предъявляемых к параметрам производительности
5.2.2.7. Нагрузочное - выполнение программной системы c повышением нагрузки, вплоть до достижения запланированных характеристик и далее
5.2.2.8. Сравнительное
5.2.2.9. Восстановительное - проверка возможностей рестарта системы в случае непредусмотренной катастрофы, влияющей на функционирование операционной среды
5.2.2.10. Конфигурационное - проверка поведения и работоспособности системы в различных конфигурациях
5.2.2.11. Тестирование удобства и простоты использования
5.3. Техники
5.3.1. Техники, базирующиеся на интуиции и опыте
5.3.1.1. Специализированное тестирование - тесты основываются на опыте, интуиции и знаниях инженера, рассматривающего проблему с точки зрения имевшихся ранее аналогий.
5.3.1.2. Исследовательское тестирование - одновременное обучение, проектирование теста и его исполнение
5.3.2. Техники, базирующиеся на спецификции
5.3.2.1. Эквивалентное разделение - область приложения разделяется на коллекцию наборов, которые считаются эквивалентными с точки зрения рассматриваемых связей и характеристик спецификации.
5.3.2.2. Анализ граничных значений - использование тех величин, которые определяют предельные характеристики тестируемой системы
5.3.2.3. Таблицы принятия решений - логические связи между условиями и действиями
5.3.2.4. Тесты на основе конечного автомата - комбинация тестов для всех состояний и переходов между состояниями, представленных в соответствующей модели
5.3.2.5. Тестирование на основе формальной спецификации - тестирование на основе спецификации, определенной с использованием формального языка
5.3.2.6. Случайное тестирование - тесты генерируются случайным образом по списку заданного набора специфицированных характеристик
5.3.3. Техники, ориентированные на код
5.3.3.1. Тесты, базирующиеся на блок-схеме - набор тестов на основе покрытия всех условий и решений блок-схемы
5.3.3.2. Тесты на основе потоков данных - отслеживание полного жизненного цикла величин
5.3.3.3. Тестирование, ориентированное на дефекты
5.3.3.4. Предположение ошибок
5.3.3.5. Тестирование мутаций - тесты запускаются для оригинального и всех “мутировавших” вариантов тестируемой программы, определяются отличия между мутантами и исходным вариантом кода
5.3.3.5.1. Мутация – небольшое изменение тестируемой программы, произошедшее за счет частных синтаксических изменений кода
5.3.4. Техники, базирующиеся на условиях использования
5.3.4.1. Базируется на условиях использования системы. Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы.
5.3.5. Техники базирующиеся на природе приложения
5.3.5.1. В зависимости от технологической или архитектурной природы приложений, могут также применять специфические техники, важные именно для заданного типа приложения.
5.3.6. Выбор и комбинации различных техник
5.3.6.1. Функциональное и структурное
5.3.6.2. Определенное или случайное
5.4. Метрики, связанные с тестированием
5.4.1. Плотность дефектов
5.4.2. Плотность дефектов после вставки
5.4.3. Доля отклонения дефектов
5.4.4. Эффективность тестирования
5.4.4.1. Число тестов (данной техники), необходимых для обнаружения первого дефекта
5.4.5. Плотность покрытия требований
5.4.6. Доля повторно открытых дефектов
5.5. Процесс тестирования
5.5.1. Практические соображения
5.5.1.1. Программирование без персоналий - совместное стремление участников проекта для обеспечения необходимого качества продукта
5.5.1.2. Руководства по тестированию
5.5.1.3. Управление процессом тестирования - работы по тестированию должны быть организованы в единый процесс, на основе: людей, инструментов, регламентов и количественных оценок
5.5.1.4. Документация – составная часть формализации процесса тестирования
5.5.1.5. Формализация процесса тестирования может включать и организационную формализацию команд(ы) тестирования
5.5.1.6. Приятие решения об окончании тестирования также включает рассмотрение стоимости и рисков, связанных с потенциальными сбоями и нарушениями надѐжности функционирования тестируемой программной системы
5.5.2. Тестовые работы
5.5.2.1. Работы по тестированию должны планироваться заранее
5.5.2.2. Создание тестовых сценариев основывается на уровне и конкретных техниках тестирования
5.5.2.3. Окружение должно быть совместимо с инструментами программной инженерии
5.5.2.3.1. Окружение должно обеспечивать разработку и контроль тестовых сценариев, ведение журнала тестирования, и возможности восстановления ожидаемых и отслеживаемых результатов тестирования, самих сценариев
5.5.2.4. Результаты должны оцениваться, анализироваться
5.5.2.5. Дефекты должны анализироваться для определения момента и места первого появления данного дефекта в системе, какие типы ошибок стали причиной этих дефектов и когда они могли бы быть обнаружены впервые