1. Ключевые вопросы поддержки и эксплуатации
1.1. Технические вопросы
1.1.1. Ограниченное понимание
1.1.1.1. Инженер по сопровождению исправляет ошибки в чужом коде системы и тд.
1.1.2. Тестирование
1.1.2.1. Тестирование основных модулей системы.
1.1.3. Анализ влияния
1.1.3.1. Полный анализ возможных последствий и влияний изменений, вносимых в существующую систему.
1.1.4. Возможность сопровождения
1.1.4.1. Процесс улучшения, оптимизации и устранения дефектов после передачи в эксплуатацию.
1.2. Реализация решения
1.2.1. Проблемы обеспечения качества
1.2.1.1. Привлечения и удержания квалифицированного персонала по сопровождению.
1.2.2. Процесс
1.2.2.1. Процесс определяется как совокупность взаимосвязанных действий, преобразующих некоторые входные данные в выходные.
1.2.3. Организационное аспекты сопровождения
1.2.3.1. В первую очередь, организационные вопросы подразумевают какая организация будет отвечать и/или какие функции необходимо выполнять для обеспечения деятельности по сопровождению.
1.2.4. Аутсоурсинг
1.2.4.1. Передача организацией, на основании договора, определённых видов или функций производственной предпринимательской деятельности другой компании, действующей в нужной области.
2. Тестирование
2.1. Основы тестирования
2.1.1. Связь тестирования с другой деятельностью
2.1.2. Ключевые вопросы
2.1.2.1. Критерии отбора тестов/критерии.
2.2. Уровни тестирования
2.2.1. Приемочное тестирование
2.2.1.1. Проверяет поведение системы на предмет удовлетворения требований заказчика.
2.2.2. Модульное тестирование
2.2.2.1. Этот уровень тестирования позволяет проверить функционирование отдельно взятого элемента системы.
2.2.3. Интеграционное тестирование
2.2.3.1. Данный уровень тестирования является процессом проверки взаимодействия между программными компонентами/модулями.
2.2.4. Системное тестирование
2.2.4.1. Системное тестирование охватывает целиком всю систему.
2.3. Метрики(это показатели, которые отражают различные характеристики продукта.), связанные с тестированием
2.3.1. Плотность дефектов
2.3.2. Плотность дефектов после вставки
2.3.3. Доля отклонения дефектов
2.3.4. Эффективность тестирования
2.3.5. Доля покрытия требований
2.3.6. Плотность покрытия требований
2.3.7. Доля повторно открытых дефектов
2.4. Техники тестирования
2.4.1. Техники базирующиеся на природе приложения
2.4.1.1. В зависимости от технологической или архитектурной природы приложений, могут также применять специфические техники, важные именно для заданного типа приложения.
2.4.2. Тестирование ориентированные на дефекты
2.4.3. Техники, базирующиеся на спецификции
2.4.4. Техники, базирующиеся на условиях использования
2.4.4.1. Базируется на условиях использования системы.Тестирование для оценки надёжности системы должно проводиться в таком тестовом окружении, которое максимально приближено к реальным условиям работы системы.
2.4.5. Выбор и комбинации различных техник
2.5. Процесс тестирования
2.5.1. Практические соображения
2.5.2. Тестовые работы
3. Конструирование
3.1. Основы конструирования
3.1.1. Уменьшение сложности
3.1.1.1. Основной причиной того, почему люди используют компьютеры в бизнес-целях, являются ограниченные возможности людей в обработке и хранении сложных структур и больших объемов информации, в частности, на протяжении длительного периода времени.
3.1.2. Ожидание изменений
3.1.3. Конструирование с возможностью проверки
3.1.3.1. Построение программных систем должно помогать вести поиск проблем и сбоев.
3.1.4. Стандарты в конструировании
3.1.4.1. Стандарты, которые напрямую применяются при конструировании, включают себя 4 пункта
3.1.4.1.1. 1. Коммуникационные методы (например, стандарты форматов документов и <оформления> содержания) 2. Языки программирования и соответствующие стили кодирования. 3. Платформы. 4.Инструменты ( UML)
3.2. Управление конструированием
3.2.1. Изменение в конструировании
3.2.1.1. Модели конструирования определяют комплекс операций связанные с общим жизненным циклом разработки.
3.2.2. Планирования конструирования
3.2.2.1. Выбор метода (методологии) конструирования
3.3. Практические соображения
3.3.1. Проектирование в конструировании
3.3.1.1. Некоторые проекты предполагают больший объем работ по проектированию именно на стадии конструирования;
3.3.2. Языки конструирования
3.3.3. Кодирование в конструировании
3.3.4. При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код
3.3.5. Тестирование
3.3.5.1. При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код.
3.3.6. Повторное использование
3.3.6.1. Во введении в стандарт IEEE Std. 1517-99 “IEEE Standard for Information Technology – Software Lifecycle Process – Reuse Processes” “Реализация повторного использования программного обеспечения подразумевает и влечёт за собой нечто большее, чем просто создание и использование библиотек активов.
3.3.7. Качество
3.3.7.1. Основные техники обеспечения качества, используемые в процессе конструирования, включают:
3.3.7.1.1. Модели конструирования
3.3.8. Интеграция
3.3.8.1. Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - интеграция отдельно сконструированных операций классов, компонентов и подсистем . В дополнение к этому, некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением. к обсуждаемым интеграционным вопросам конструирования относятся:
3.3.8.1.1. планирование последовательности, в которой интегрируются компоненты; обеспечение поддержки создания промежуточных версий программного обеспечения; задание “глубины” тестирования (в частности, на основе критериев “приемлемого” качества) и других работ по обеспечению качества интегрируемых в дальнейшем компонент; наконец, определение этапных точек проекта, когда будут тестироваться промежуточные версии конструируемой программной системы.
4. Проектирование программного обеспечение
4.1. Основы проектирования
4.1.1. Общие концепции проектирования
4.1.1.1. Архитектурные стили
4.1.1.1.1. Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда.
4.1.1.2. Принципы проектирования, являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения.
4.1.1.3. К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения.
4.1.2. Контекст программного дизайна
4.1.2.1. Для понимания роли проектирования программного важно понимать контекст, в котором осуществляется проектирование и используются его результаты.
4.1.3. Процесс проектирования
4.1.3.1. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.
4.1.4. Техники применения
4.2. Ключевые вопросы проектирования
4.2.1. Контроль и обработка событий
4.2.1.1. В самом названии данной темы заложен комплекс обсуждаемых вопросов. Данная тема касается и неявных методов обработки событий, часто реализуемых в виде функции обратного вызова, как одной из фундаментальных концепций обработки событий.
4.2.2. Взаимодействие и представление
4.2.2.1. Тема касается вопросов представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей.
4.2.3. Сохраняемость данных
4.2.3.1. Именно сохраняемость, а не сохранность, так как тема касается не доступа к базам данных, как такового, а также не гарантий сохранности информации. Суть вопроса – как должны обрабатываться “долгоживущие” данные.
4.3. Структура и архитектура ПО
4.3.1. Архитектурные структуры и точки зрения
4.3.1.1. Любая система может рассматриваться с разных точек зрения – например, поведенческой структурной логической физической, реализации и т.п.
4.3.2. Шаблоны проектирования
4.3.2.1. общее решение общей проблемы в заданном контексте”
4.3.3. Свойства программ и фреймворков
4.3.3.1. Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов на основе общего дизайна.
4.4. Анализ качества и оценка программного дизайна
4.4.1. Атрибуты качества
4.4.1.1. Существует целый спектр различных атрибутов, помогающих оценить и добиться качественного дизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”, “безопасность” и т.п.
4.4.1.1.1. В индустрии распространены многие инструменты, техники и практики, помогающие добиться качественного дизайна:
4.4.2. Анализ качества
4.4.3. Измерения
4.4.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности).
4.5. Нотации проектирования ПО
4.5.1. Структурные описания
4.5.1.1. Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонент и связей между ними
4.5.2. Поведение описания
4.5.2.1. Следующие нотации и языки используются для описания динамического поведения программных систем и их компонентов. Многие из этих нотаций успешно используются для проектирования деталей дизайна, но не только для этого.
4.6. Стратегии и методы проектирования
4.6.1. Общие стратегии
4.6.1.1. Существуют различные общие стратегии, помогающие в проведении работ по проектированию.
4.6.2. Функционально-ориетированный
4.6.2.1. Это один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”.
4.6.3. Проектирование на основе структур данных
4.6.3.1. В данном подходе фокус сконцентрирован в большей степени на структурах данных, которыми управляет система, чем на функциях системы.
4.6.4. Компонентное проектирование
4.6.4.1. Программные компоненты являются независимыми единицами, которые обладают однозначно-определенными (well-defined) интерфейсами и зависимостями (связями) и могут собираться и развертываться независимо друг от друга.
5. Требования
5.1. Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.
5.2. Основы требований
5.2.1. Определение требований
5.2.1.1. Требования
5.2.1.2. Уровни
5.2.1.2.1. Бизнес
5.2.1.2.2. Пользовательские
5.2.1.2.3. Функциональные
5.2.2. Требования к продукту или процессу
5.2.2.1. Продукт
5.2.2.2. Процесс
5.2.3. Функциональные и не функциональные
5.2.3.1. Функциональные
5.2.3.2. Не функциональные
5.2.3.2.1. Описывающие, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать
5.2.4. Свойства
5.2.4.1. Полнота
5.2.4.2. ясность
5.2.4.2.1. Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.
5.2.4.3. Корректность и согласованность
5.2.4.3.1. Требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня.
5.2.4.4. Верифицируемость
5.2.4.5. Осуществимость
5.2.4.6. Упорядоченность по важности
5.2.4.6.1. Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика.
5.2.5. Количественная оценка
5.2.6. Системные и программные требования
5.2.6.1. Системные
5.2.6.1.1. Описание примерных характеристик, которым должен соответствовать компьютер для того, чтобы на нём могло использоваться какое-либо определённое программное обеспечение.
5.2.6.2. Програмнные
5.2.6.2.1. Совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.
5.3. Извлечение требований
5.3.1. Стратегия выявление требований
5.3.1.1. Интервьюирование
5.3.1.1.1. Подготовка
5.3.1.1.2. Проведение интервью
5.3.1.1.3. Завершение
5.3.1.2. Анкетирование
5.3.1.3. Наблюдение
5.3.1.3.1. Через наблюдение а возможно и участие аналитики получают информацию о происходящих день за днем операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы которые никогда бы не появились если бы аналитик только читал или разговаривал с экспертами
5.3.1.4. Самостоятельное описание требований
5.3.1.4.1. Документы - источник информации, они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов - способ получить представление о системе и сформулировать вопросы к экспертам.
5.3.1.5. Совместный семинар
5.3.1.5.1. Первое правило мозгового штурма - "полный запрет на любую критику". Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.
5.3.1.6. разработка + проведение переговоров и нахождение компромисса
5.3.1.7. Прототипирование
5.3.2. Источники требований
5.3.2.1. Заказчик
5.3.2.2. Группа работников предприятия
5.3.2.3. Документация
5.3.2.4. Важные работники предприятия
5.3.2.5. Прототип
5.4. Процесс работы
5.4.1. Модель процесса определения требований
5.4.1.1. Это схема процессов жц которые выполняются от начала проекта до тех пор пока не будут определены и согласованы требования
5.4.2. Участники процессов
5.4.2.1. Пользователи
5.4.2.2. Заказчики
5.4.2.3. Аналитики
5.4.2.4. Инженеры по ПО
5.4.3. Управление и поддержка процессов
5.4.3.1. Распределение ресурсов
5.4.3.2. Инициация и определение содержания
5.4.3.3. Управление в программной инженерии
5.4.4. Качество процессов
5.4.4.1. Покрытие работы с требованиями с точки зрения стандартов и моделей услуг процесса
5.4.4.2. Измерение и количественная оценка
5.4.4.3. Планирование и реализация процесса улучшения
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.3. Архитектурное проектирование и распределение требований
5.5.3.1. Стандарт ISO12207
5.5.3.2. Модель Захмана
5.5.3.3. TOGAF
5.6. Спецификация требований
5.6.1. Определение системы
5.6.2. Спецификация системных и программных требований
5.6.2.1. Терминологические неопределенности
5.6.2.2. Отсутствие о представления классификации требований
5.6.2.3. Фокусировка на деталях пользовательского интерфейса
5.6.2.4. Излишние акцентирование внимания на деталях реализации
5.6.2.5. Слабая формализация бизнес-процессов
5.7. Проверка требований
5.7.1. Прототипирование
5.7.1.1. Смещение внимания с целевых функций прототипа и как следствие неудовлетворение пользователей
5.7.1.2. Превращение прототипа в реальную систему
5.7.2. Утверждение модели
5.8. Проектирование соображений
5.8.1. Интерактивная природа процесса
5.8.2. Управление изменениями
5.8.3. Атрибуты требований
5.8.3.1. Приемочный тест
5.8.4. Трассировка требований
5.8.5. Измерение требований
6. Поддержка при эксплуатации
6.1. Основы поддержки и эксплуатации
6.1.1. Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. Соответственно, в процессе эксплуатации продукт будет изменяться или эволюционировать. Связано это с обнаружением при реальном использовании скрытых дефектов, изменениями и тд.
6.2. Процесс
6.2.1. Процессы сопровождения
6.2.1.1. Целью процесса является изменение существующего программного продукта при сохранении его целостности. Данный процесс охватывает вопросы переносимости и снятия программного продукта с эксплуатации. Процесс заканчивается снятием программного продукта с эксплуатации.
6.2.2. Уникальные работы
6.2.2.1. Передача
6.2.2.2. Анализ влияния
6.2.3. Работы по сопровождению
6.2.3.1. Учет изменений
6.2.3.2. Качество программного обеспечения
6.2.4. Работы по планированию сопровождению
6.2.4.1. Достижения соглашения с пользователем
6.2.4.2. Оценка рисков
6.3. Техники
6.3.1. Понимание программных систем
6.3.2. Реинжиниринг
6.3.2.1. Реинжиниринг определяется как детальная оценка (examination) и перестройка программного обеспечения для формирования понимания.
6.3.3. Обратный инжиниринг
6.3.3.1. Исследование готового продукта с целью понять принцип его работы.
6.3.4. Получение и сбор информации