Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Swebok создатель Mind Map: Swebok

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

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

2.1. Полнота отдельного требования - свойство, означающее, что больше не требуется внесение каких-либо деталей

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

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

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

2.2.1.2. Уровни

2.2.1.2.1. Бизнес

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

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

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

2.2.2.1. Продукт

2.2.2.2. Процесс

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

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

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

2.2.3.2.1. Как должна работать и какими свойствами обладает

2.2.3.3. Что необходимо реализовать в продукте или системе, какие действия должны выполнять пользователи при взаимодействии с ним

2.2.4. Основные мероприятия по контролю и снижению риска - регламентация процесса создания ПО и его аудит

2.2.5. Свойства

2.2.5.1. Полнота

2.2.5.1.1. Свойство означающее, что требуется от разрабатываемой системы

2.2.5.2. Ясность

2.2.5.2.1. Требование, которое сформулировано ясно

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

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

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

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

2.2.5.5.1. Необходимость требований может вытекать из соответствующих бизнес-требований

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

2.2.5.6.1. Требования определяются балансом между ценностью и потребными ресурсами

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

2.2.5.7.1. При изменении отдельного требования становится ясно, какие из артефактов подлежат изменению

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

2.2.5.8.1. Предоставляет количественную оценку степени значимости требования

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

2.2.6.1. Продукции, определение численных значений показателей качество продукции .

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

2.2.7.1. Системные

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

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

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

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

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

2.3.1.1. Интервьюривание

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

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

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

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

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

2.3.1.3.1. Аналитики получают информацию в день операции из первых рук

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

2.3.1.4.1. Документы-источник информации, чтение документов-способ получить сведения о системе

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

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

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

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

2.3.2. Прототипирование-ключевая стратегия выявления требований в большинстве современных методологий.

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

2.3.3.1. Заказчик

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

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

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

2.3.3.5. Прототип

2.3.3.5.1. Зеркало , в котором видно как исполнитель понял заказчика

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

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

2.4.1.1. Схема процессов ЖЦ, которые выполняются от начала до конца проекта

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

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

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

2.4.2.2. Заказчики

2.4.2.2.1. Целевой рынок ПО

2.4.2.3. Аналитики

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

2.4.2.4.1. Делают все по закону

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

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

2.4.3.1. Разделение ресурсов

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

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

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

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

2.4.4.2. Измерение и кол-нная оценка

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

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

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

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

2.5.1.1.1. Функциональные - описывают функции, которые должно выполнять разрабатываемое ПО

2.5.1.1.2. Требования к процессу как и на каком ПО разработчик будет выполнять работу

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

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

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

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

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

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

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

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

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

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

2.5.4.1. Стандарт ISO 12207

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

2.5.4.3. TOGAF

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.1.2.1. Важно понимать контекст, в котором осуществляется проектирование и используется его результатов

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

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

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

6.2. Как предотвратить сбои или, если сбой все же произошел, обеспечить дальнейшее функционирование системы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.5.3. Измерения

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

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

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

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

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

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

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

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

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

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

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

7.1.1. Результат состоит в передачи в эксплуатацию программного продукта, удовлетворяющего требованиям пользователя

7.2. Процесс

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

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

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

7.2.2.1. Передача

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

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

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

7.2.3.2. Качество ПО

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

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

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

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

7.3. Техники

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

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

7.3.2.1. Определяется как детальная оценка и перестройка ПО для формирования понимания

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

7.3.3.1. Это процесс анализа ПО с целью идентификации программных компонентов и связей между ними

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.3.7. Качество

9.3.8. Интеграции

10. Большинство программных систем изменяются с течением времени. Изменения - это часть программной среды

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

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

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

11.1.1.1. Как быстро инженер по сопровождению может понять где необходимо внести исправления

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

11.1.2.1. Стоимость повторения полного набора тестов для основных модулей системы

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

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

11.1.3.2. Описывает как проводить полный анализ возможных последствий и влияний изменений

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

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

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

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

11.2.1.1. Описывают как продемонстрировать возврат инвестиций

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

11.2.3. Процесс

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

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

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

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

11.2.5.1. Суть заключается в передаче работ, в первую очередь вспомогательных "на сторону"