Swebok

1. Описывающие, как должна работать система или программный продукт, и какими свойствами или характеристиками она должна обладать

2. Полнота отдельного требования - свойство, означающее, что текст требования не требует дополнительной детализации, то есть в нем предусмотрены все необходимые нюансы, особенности и детали данного требования.

3. Существенно связано со свойствами ясности и полноты: если требование изложено на языке, понятном и одинаково воспринимаемом участниками процесса создания информационной системы, причем оно является полным, т.е. ни одна из важных для реализации деталей не упущена - значит, это требование можно проверить.

4. Требования

4.1. Основы требований

4.1.1. Определение требований

4.1.1.1. Требования

4.1.1.2. Уровни

4.1.1.2.1. Бизнес

4.1.1.2.2. Пользовательские

4.1.1.2.3. Функциональные

4.1.2. Требования к продукту или процессу

4.1.2.1. Продукт

4.1.2.2. Процесс

4.1.3. Функциональные и не функциональные

4.1.3.1. Функциональные

4.1.3.2. Не функциональные

4.1.3.3. Описывающие, что необходимо реализовать в продукте или системе, в т.ч. какие действия должны выполнять пользователи при взаимодействии с ними

4.1.4. Свойства

4.1.4.1. Полнота

4.1.4.1.1. Полнота системы требований - свойство, означающее, что совокупность артефактов, описывающих требования, исчерпывающим образом описывает все то, что требуется от разрабатываемой системы.

4.1.4.2. ясность

4.1.4.2.1. Требование, которое сформулировано ясно, может быть прослежено, начиная от того документа, где оно сформулировано впервые, вплоть до рабочих спецификаций.

4.1.4.3. Корректность и согласованность

4.1.4.3.1. Требования не должны противоречить, соответственно, требованиям своего уровня иерархии и требованиям "родительского" уровня.

4.1.4.4. Основные мероприятия по контролю и снижению риска – регламентация процесса создания ПО и его аудит. Заказчик регламентирует требования к проекту в зависимости от ценности конечного продукта для Заказчика, степени доверия Заказчика к разработчику, суммы подписанного контракта, увязки срока сдачи продукта в эксплуатацию с бизнес-рисками Заказчика и тд.

4.1.4.5. Верифицируемость

4.1.4.6. Необходимость и полезность при эксплуатации

4.1.4.6.1. Необходимость требований пользователя может вытекать из соответствующих бизнес-требований. Кроме того, требования пользователя могут мотивироваться эргономичностью продукта и особенностями функционирования его отдела (подразделения), недостаточно полно раскрытыми на предыдущем уровне иерархии требований.

4.1.4.7. Осуществимость

4.1.4.7.1. Требования на практике определяется разумным балансом между ценностью (степенью необходимости и полезности) и потребными ресурсами

4.1.4.8. Трассируемость

4.1.4.8.1. Повысить управляемость проектом: при изменении отдельно взятого требования становится понятно - какие из проектных, рабочих и других артефактов подлежат изменению

4.1.4.9. Упорядоченность по важности

4.1.4.9.1. Приоритет требования представляет собой количественную оценку степени значимости (важности) требования. Приоритеты требований обычно назначает представитель Заказчика.

4.1.5. Количественная оценка

4.1.5.1. Продукции, определение численных значений показателей качества продукции (См. Качество продукции). К. о. к. применяется для выбора оптимального варианта продукции из некоторого числа сравниваемых вариантов

4.1.6. Системные и программные требования

4.1.6.1. Системные

4.1.6.1.1. Описание примерных характеристик, которым должен соответствовать компьютер для того, чтобы на нём могло использоваться какое-либо определённое программное обеспечение.

4.1.6.2. Програмнные

4.1.6.2.1. Совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации.

4.2. Извлечение требований

4.2.1. Стратегия выявление требований

4.2.1.1. Интервьюирование

4.2.1.1.1. Подготовка

4.2.1.1.2. Проведение интервью

4.2.1.1.3. Завершение

4.2.1.2. Анкетирование

4.2.1.3. Наблюдение

4.2.1.3.1. Через наблюдение а возможно и участие аналитики получают информацию о происходящих день за днем операциях из первых рук. Во время наблюдения за работой системы часто возникают вопросы которые никогда бы не появились если бы аналитик только читал или разговаривал с экспертами

4.2.1.4. Самостоятельное описание требований

4.2.1.4.1. Документы - источник информации, они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов - способ получить представление о системе и сформулировать вопросы к экспертам.

4.2.1.5. Совместный семинар

4.2.1.5.1. Первое правило мозгового штурма - "полный запрет на любую критику". Всякое высказанное мнение представляет ценность, а полное отсутствие запретов позволяет полноценным образом подключить творческую фантазию.

4.2.1.6. разработка + проведение переговоров и нахождение компромисса

4.2.1.7. Прототипирование

4.2.2. Прототипирование - ключевая стратегия выявления требований в большинстве современных методологий. Программный прототип - "зеркало", в котором видно отражение того, как понял Исполнитель требования Заказчика.

4.2.3. Источники требований

4.2.3.1. Заказчик

4.2.3.2. Группа работников предприятия

4.2.3.3. Документация

4.2.3.4. Важные работники предприятия

4.2.3.5. Прототип

4.2.3.5.1. Программный прототип это зеркало в котором видно отражение того как понял исполнитель требования заказчика

4.3. Процесс работы

4.3.1. Модель процесса определения требований

4.3.1.1. Это схема процессов жц которые выполняются от начала проекта до тех пор пока не будут определены и согласованы требования

4.3.2. Участники процессов

4.3.2.1. Пользователи

4.3.2.1.1. могут описать задачи которые он будет решать

4.3.2.2. Заказчики

4.3.2.2.1. целевой рынок ПО

4.3.2.3. Аналитики

4.3.2.4. Регуляторы

4.3.2.4.1. делают все по закону

4.3.2.5. Инженеры по ПО

4.3.3. Управление и поддержка процессов

4.3.3.1. Распределение ресурсов

4.3.3.2. Инициация и определение содержания

4.3.3.3. Управление в программной инженерии

4.3.4. Качество процессов

4.3.4.1. Покрытие работы с требованиями с точки зрения стандартов и моделей услуг процесса

4.3.4.2. Измерение и количественная оценка

4.3.4.3. Планирование и реализация процесса улучшения

4.4. Анализ требований

4.4.1. Классификация требований

4.4.1.1. Функциональные и не функциональные требования

4.4.1.1.1. Функциональные требования описывают функции, которые должно выполнять разрабатываемое ПО.Нефункциональные требования — требования, определяющие свойства, которые система должна демонстрировать, или ограничения, которые она должна соблюдать, не относящиеся к поведению системы. Например, производительность, удобство сопровождения, расширяемость, надежность, факторы эксплуатации.

4.4.1.1.2. Требования к процессу как и на каком ПО разработчик будет выполнять работу. К продукту описывает эксплуатационные свойства программного продукта. Эта требования к производительности системы обьему необходимой памяти надежности переносимости системы на разные платформы и удобство в эксплуатации

4.4.1.2. Внутрикорпоративные стандарты и регламент

4.4.1.3. Требование к процессу или продукту

4.4.2. Концептуальное моделирование

4.4.2.1. Природа проблемы

4.4.2.2. Экспертиза и опыт инженеров

4.4.2.3. Требования заказчика к процессу

4.4.2.4. Доступность методов и инструментов

4.4.2.5. Культура разработки

4.4.3. Сбор требований

4.4.4. Архитектурное проектирование и распределение требований

4.4.4.1. Стандарт ISO12207

4.4.4.2. Модель Захмана

4.4.4.3. TOGAF

4.5. Спецификация требований

4.5.1. Определение системы

4.5.2. Спецификация системных и программных требований

4.5.2.1. Терминологические неопределенности

4.5.2.2. Отсутствие о представления классификации требований

4.5.2.3. Фокусировка на деталях пользовательского интерфейса

4.5.2.4. Излишние акцентирование внимания на деталях реализации

4.5.2.5. Слабая формализация бизнес-процессов

4.6. Проверка требований

4.6.1. Прототипирование

4.6.1.1. Смещение внимания с целевых функций прототипа и как следствие неудовлетворение пользователей

4.6.1.2. Превращение прототипа в реальную систему

4.6.2. Утверждение модели

4.7. Проектирование соображений

4.7.1. Интерактивная природа процесса

4.7.2. Управление изменениями

4.7.3. Атрибуты требований

4.7.3.1. Приемочный тест

4.7.4. Трассировка требований

4.7.5. Измерение требований

5. Самый малозатратный для аналитика способ извлечения информации, он же - и наименее эффективный. Обычно применяется как дополнение к другим стратегиям выявления требований.

6. Содержит вопросы формулирования требований к проекту, т е к тому, как Разработчик будет выполнять работы по созданию целевой системы. Заказчик, вступая в договорные отношения с Разработчиком, несет различные риски, главным из которых является риск получить продукт с опозданием, либо ненадлежащего качества.

7. Проектирование программного обеспечение

7.1. Основы проектирования

7.1.1. Общие концепции проектирования

7.1.1.1. Принципы проектирования, являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения.

7.1.1.2. К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения.

7.1.2. Контекст программного дизайна

7.1.2.1. Для понимания роли проектирования программного важно понимать контекст, в котором осуществляется проектирование и используются его результаты.

7.1.3. Процесс проектирования

7.1.3.1. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.

7.1.4. Техники применения

7.2. Ключевые вопросы проектирования

7.2.1. Параллелизм в проектировании

7.2.1.1. Эта тема охватывает вопросы, подходы и методы организации процессов, эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.

7.2.2. Контроль и обработка событий

7.2.2.1. В самом названии данной темы заложен комплекс обсуждаемых вопросов. Данная тема касается и неявных методов обработки событий, часто реализуемых в виде функции обратного вызова, как одной из фундаментальных концепций обработки событий.

7.2.3. Ошибки обработка исключений и защищенность от сбоев

7.2.4. Взаимодействие и представление

7.2.4.1. Тема касается вопросов представления информации пользователям и взаимодействия пользователей с системой, с точки зрения реакции системы на действия пользователей.

7.2.5. Сохраняемость данных

7.2.5.1. Обработка и сохранение необходимых данных

7.3. Структура и архитектура ПО

7.3.1. Архитектурные структуры и точки зрения

7.3.1.1. Любая система может рассматриваться с разных точек зрения – например, поведенческой структурной логической физической, реализации и т.п.

7.3.2. Шаблоны проектирования

7.3.2.1. Общее решение общей проблемы в заданном контексте

7.3.3. Архитектурные стили

7.3.3.1. Архитектурный стиль, по своей сути, мета-модель или шаблон проектирования макро-архитектуры - на уровне модулей, "крупноблочного" взгляда.

7.3.4. Свойства программ и фреймворков

7.3.4.1. Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов на основе общего дизайна.

7.4. Анализ качества и оценка программного дизайна

7.4.1. Атрибуты качества

7.4.1.1. Существует целый спектр различных атрибутов, помогающих оценить и добиться качественного дизайна. Эти атрибуты могут описывать многие характеристики системы и элементов дизайна как такового – “тестируемость”, “переносимость”, “модифицируемость”, “производительность”, “безопасность” и т.п.

7.4.2. Анализ качества

7.4.3. Измерения

7.4.3.1. Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного дизайна, например, размера проекта, структуры (ее сложности) или качества (например, в контексте требований, предъявляемых к производительности).

7.5. Нотации проектирования ПО

7.5.1. Структурные описания

7.5.1.1. Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна. Чаще всего они касаются основных компонентов и связей между ними

7.5.2. Поведение описания

7.5.2.1. Следующие нотации и языки используются для описания динамического поведения программных систем и их компонентов. Многие из этих нотаций успешно используются для проектирования деталей дизайна, но не только для этого.

7.6. Стратегии и методы проектирования

7.6.1. Общие стратегии

7.6.1.1. Существуют различные общие стратегии, помогающие в проведении работ по проектированию.

7.6.2. Функционально-ориетированный

7.6.2.1. Это один из классических методов проектирования, в котором декомпозиция сфокусирована на идентификации основных программных функций и, затем, детальной разработке и уточнении этих функций “сверху-вниз”.

7.6.3. Проектирование на основе структур данных

7.6.3.1. Концентрация на структурах данных, управляемых системой

7.6.4. Компонентное проектирование

7.6.4.1. Программные компоненты являются независимыми единицами, которые обладают однозначно-определенными интерфейсами и зависимостями (связями) и могут собираться и развертываться независимо друг от друга.

7.6.5. Другие методы

8. Понимание программных систем

9. Основы поддержки и эксплуатации

10. Техники

10.1. Обратный инжиниринг

10.1.1. “Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) или это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга).

10.2. Получение и сбор информации

11. Процесс

11.1. Процессы сопровождения

11.1.1. Эта секция включает концепции и терминологию, формирующие основы понимания роли и содержания работ по сопровождению программных систем.

11.2. Уникальные работы

11.2.1. Передача

11.2.2. Анализ влияния

11.3. Работы по сопровождению

11.3.1. Конфигурационное управление

11.3.2. Качество программного обеспечения

11.4. Работы по планированию сопровождению

11.4.1. Идентификация постоянных конфликтов

11.4.2. Достижения соглашения с пользователем

11.4.3. Оценка рисков

12. Тестирование

12.1. Основы тестирования

12.1.1. Связь тестирования с другой деятельностью

12.1.2. Терминология тестирования

12.1.2.1. Определения и термины

12.1.3. Ключевые вопросы

12.1.3.1. Критерии отбора тестов, критерии уместности тестов тестов, правила прекращения тестирования

12.2. Уровни тестирования

12.2.1. Приемочное тестирование

12.2.1.1. Соответствует ли система требованиям заказчика

12.2.2. Модульное тестирование

12.2.2.1. Тестирование отдельного элемента системы

12.2.3. Интеграционное тестирование

12.2.3.1. Выяляет конфликт между компонентами сис.

12.2.4. Системное тестирование

12.2.4.1. Тест всей системы. Проводится последней

12.3. Метрики, связанные с тестированием

12.3.1. Плотность дефектов

12.3.1.1. Доля дефектов отдельного модуля

12.3.2. Плотность дефектов после вставки

12.3.3. Доля отклонения дефектов

12.3.4. Эффективность тестирования

12.3.5. Доля покрытия требований

12.3.6. Плотность покрытия требований

12.3.7. Доля повторно открытых дефектов

12.3.7.1. Оценка качества разработки и исправления дефектов

12.4. Техники тестирования

12.4.1. Техники базирующиеся на природе приложения

12.4.1.1. Особое тестирование именно для заданного типа приложения.

12.4.2. Тестирование ориентированные на дефекты

12.4.2.1. Нахождение непредусмотренных ошибок.

12.4.3. Техники, базирующиеся на интуиции и опыте

12.4.3.1. Нахождение ошибок в подобных системах.

12.4.4. Техники, базирующиеся на спецификции

12.4.4.1. Согласование клиента и заказчика о функциональности продукта

12.4.5. Техники, базирующиеся на условиях использования

12.4.5.1. Тестирование в реальных условиях

12.4.6. Выбор и комбинации различных техник

12.5. Процесс тестирования

12.5.1. Практические соображения

12.5.2. Тестовые работы

13. Конструирование

13.1. Основы конструирования

13.1.1. Минимизация сложности

13.1.1.1. Легче отобразить как работает кнопка, и что она делает

13.1.2. Ожидание изменений

13.1.3. Конструирование с возможностью проверки

13.1.3.1. Строить надо так, чтобы можно было быстро и легко чинить

13.1.4. Стандарты в конструировании

13.1.4.1. Стандарты при конструировании

13.1.4.1.1. 1. Коммуникационные методы (стандарты форматов документов и оформления содержания) 2. Языки программирования и соответствующие стили кодирования (есть JAVA, есть документация JDK – Java Development Kit и стиль кодирования Java Style Guide) 3. Платформы (стандарты программных интерфейсов для вызовов функций операционной среды, такие как прикладные программные интерфейсы платформы Windows - Win32 API, Application Programming Interface или .NET Framework SDK, Software Development Kit) 4. инструменты (средства конструирования, UML)

13.2. Управление конструированием

13.2.1. Изменение в конструировании

13.2.1.1. Модели конструирования определяют комплекс операций, включающих последовательность, результаты (например, исходный код и соответствующие unit-тесты) и другие аспекты, связанные с общим жизненным циклом разработки.

13.2.2. Планирования конструирования

13.2.2.1. Выбор методологии; ISO, ГОСТ для помощи

13.3. Практические соображения

13.3.1. Проектирование в конструировании

13.3.1.1. Дополнение вовремя конструирования

13.3.2. Языки конструирования

13.3.3. Кодирование в конструировании

13.3.4. Практика конструирования программного обеспечения показывает активное применение следующих соображений и техник.

13.3.5. Тестирование

13.3.5.1. При конструировании используются две формы тестирования, проводимого инженерами, непосредственно создающими исходный код.

13.3.6. Повторное использование

13.3.6.1. Повторное использование кода, предназначенного для подобной системы

13.3.7. Качество

13.3.7.1. Существует ряд техник, предназначенных для обеспечения качества кода, выполняемых по мере его конструирования. Основные техники обеспечения качества, используемые в процессе конструирования, включают:

13.3.7.1.1. Модели конструирования

13.3.8. Интеграция

13.3.8.1. Одна из ключевых деятельностей, осуществляемых в процессе конструирования, - интеграция отдельно сконструированных операций классов, компонентов и подсистем . В дополнение к этому, некоторые программные системы нуждаются в специальной интеграции с другим программным и аппаратным обеспечением. к обсуждаемым интеграционным вопросам конструирования относятся:

13.3.8.1.1. планирование последовательности, в которой интегрируются компоненты; обеспечение поддержки создания промежуточных версий программного обеспечения; задание “глубины” тестирования (в частности, на основе критериев “приемлемого” качества) и других работ по обеспечению качества интегрируемых в дальнейшем компонент; наконец, определение этапных точек проекта, когда будут тестироваться промежуточные версии конструируемой программной системы.

14. Большинство программных систем изменяются с течением времени. Причин этому – множество. Ожидание изменений является одной из движущих сил конструирования программного обеспечения. Изменения это часть программной среды.

15. Ключевые вопросы поддержки и эксплуатации

15.1. Технические вопросы

15.1.1. Ограниченное понимание

15.1.1.1. Ограниченное понимание подразумевает как быстро инженер по сопровождению может понять где необходимо внести исправления или изменения в код системы, которую он не разрабатывал.

15.1.2. Тестирование

15.1.2.1. Стоимость повторения полного набора тестов для основных модулей системы может быть существенным как по времени, так и по стоимости.

15.1.3. Анализ влияния

15.1.3.1. Анализ влияния описывает как проводить (в частности, с точки зрения эффективности затрат) полный анализ возможных последствий и влияний изменений, вносимых в существующую систему.

15.1.4. Возможность сопровождения

15.1.4.1. Легкость сопровождения, расширения, адаптации и корректировки для удовлетворения заданных требований.

15.2. Управленческие вопросы

15.2.1. Согласование с организационными целями

15.2.1.1. Организационные цели описывают как продемонстрировать возврат инвестиций от деятельности по сопровождению программного обеспечения.

15.2.2. Проблемы кадрового обеспечения

15.2.2.1. Данная тема касается вопросов привлечения и удержания квалифицированного персонала по сопровождению.

15.2.3. Процесс

15.2.3.1. Процесс (в общем случае, жизненный цикл, прим. автора) является набором работ (activities), методов, практик и, своего рода, трансформаций, которые используются людьми для разработки и сопровождения программных систем и ассоциированных с ними продуктов.

15.2.4. Организационное аспекты сопровождения

15.2.4.1. В первую очередь, организационные вопросы подразумевают какая организация будет отвечать и/или какие функции необходимо выполнять для обеспечения деятельности по сопровождению.

15.2.5. Аутсоурсинг

15.2.5.1. Заимствованный термин “аутсоурсинг” уже прижился не только в среде ИТ-менеджеров, он стал частью современного бизнеса и управленческих практик. Суть его заключается в передаче работ, в первую очередь, вспомогательных (непрофильных для организации) “на сторону”.

16. Поддержка при эксплуатации

16.1. Реинжиниринг

16.1.1. Реинжиниринг определяется как детальная оценка (examination) и перестройка программного обеспечения для формирования понимания.

16.1.1.1. Результат усилий по разработке программного обеспечения состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователей. Соответственно, в процессе эксплуатации продукт будет изменяться или эволюционировать. Связано это с обнаружением при реальном использовании скрытых дефектов, изменениями в операционном окружении, необходимостью покрытия новых требований и т.п.