Интеграция управления рисками в SDLC | Комплект 1

Жизненный цикл разработки программного обеспечения (SDLC) - это концептуальная модель для определения задач, выполняемых на каждом этапе процесса разработки программного обеспечения. Хотя существуют различные модели для SDLC, но в целом SDLC состоит из следующих шагов:

1. Предварительный анализ
2. Системный анализ и определение требований
3. Системный дизайн
4. Разработка
5. Интеграция и тестирование системы
6. Монтаж, эксплуатация и приемочные испытания
7. Обслуживание
8. Утилизация

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

1. Предварительный анализ:
На этом этапе вам необходимо выяснить:

1. Цель организации
2. Характер и масштаб исследуемой проблемы
3. Предлагайте альтернативные решения и предложения после глубокого понимания проблемы и того, что делают конкуренты.
4. Опишите затраты и выгоды.

Поддержка деятельности по управлению рисками -

1. Установите процесс и ответственность за управление рисками
2. Документ Первоначально известные риски
3. Менеджер проекта должен расставить приоритеты по рискам

2. Системный анализ и определение требований:
Этот шаг очень важен для четкого понимания ожиданий и требований клиентов. Таким образом, очень важно проводить этот этап с максимальной осторожностью и уделять должное время, поскольку любая возможная ошибка приведет к сбою всего процесса. Ниже приводится последовательность шагов, выполняемых на этом этапе:

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

   Как правило, этот шаг включает следующие действия по управлению рисками.

   Поддержка деятельности по управлению рисками -

   1. Выявление активов, которые необходимо защитить, и определение их критичности с точки зрения конфиденциальности, целостности и доступности.
   2. Выявление угроз и связанных с ними рисков для этих активов
   3. Определите существующие меры безопасности, чтобы снизить эти риски

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

   Мы обсудим эти этапы более подробно, а также факторы риска, задействованные на этих этапах.

   1. Технико-экономическое обоснование - это первый и самый важный этап. Часто эта фаза проводится как отдельная фаза в больших проектах, а не как подэтап в фазе определения требований. Этот этап позволяет команде получить оценку стоимости и времени основных факторов риска для данного проекта. Вам может быть интересно, почему это так важно? Технико-экономическое обоснование помогает понять, стоит ли строить систему. Это помогает выявить основные факторы риска.

      Факторы риска -
      Ниже приводится список факторов риска для этапа технико-экономического обоснования:

      • Менеджер проекта часто ошибается в оценке стоимости, времени, ресурсов и объема проекта. Нереалистичный бюджет, время, недостаточные ресурсы и нечеткий масштаб часто приводят к провалу проекта.
      • Нереалистичный бюджет: как обсуждалось выше, неточная оценка бюджета может привести к тому, что у проекта закончатся средства на ранней стадии SDLC. Точная оценка бюджета напрямую связана с правильным знанием времени, усилий и ресурсов.
      • Нереалистичный график: неправильная оценка времени приводит к тому, что менеджеры проектов обременяют разработчиков своевременной сдачей проекта. Это ставит под угрозу общее качество проекта и, таким образом, делает систему менее безопасной и более уязвимой.
      • Недостаточно ресурсов: в некоторых случаях доступные технологии и инструменты не соответствуют требованиям проекта, либо имеющихся ресурсов (людей, инструментов, технологий) недостаточно для завершения проекта. В любом случае проект будет отложен или, в худшем случае, может привести к провалу проекта.
      • Неясный масштаб проекта: четкое понимание того, что проект должен делать, какие функции важны, какие функции являются обязательными, какие функции могут считаться дополнительными, очень важно для менеджеров проектов. Недостаточное знание системы может привести к провалу проекта.

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

      Факторы риска -

      • Неполные требования: в 60% случаев пользователи не могут изначально сформулировать все требования. Следовательно, требования имеют наиболее динамичный характер в полном процессе SDLC. Если какие-либо потребности пользователя, ограничения или другие функциональные / нефункциональные требования не удовлетворяются, то набор требований считается неполным.
      • Неточные требования: если набор требований не отражает реальных потребностей пользователей, то в этом случае требования считаются неточными.
      • Неясные требования: часто в процессе SDLC существует разрыв в коммуникации между пользователями и разработчиками. В конечном итоге это влияет на набор требований. Если требования, заявленные пользователями, непонятны аналитику и разработчикам, то эти требования считаются неясными.
      • Игнорирование нефункциональных требований: иногда разработчики и аналитики игнорируют тот факт, что нефункциональные требования имеют такое же значение, как и функциональные. В этой неразберихе они сосредотачиваются на том, что система должна делать, а не на том, какой она должна быть, например, масштабируемость, ремонтопригодность, тестируемость и т.
      • Конфликтующие требования пользователей: у нескольких пользователей в системе могут быть разные требования. Если не перечислить и не проанализировать внимательно, это может привести к несоответствию требований.
      • Золотое покрытие: очень важно вначале перечислить все требования. Добавление требований позже во время разработки может привести к угрозам в системе. Позолота - это не что иное, как добавление к системе дополнительных функций, которые ранее не рассматривались. Тем самым вызывая угрозы и делая систему уязвимой.
      • Нечеткое описание реальной операционной среды: Недостаточное знание реальной операционной среды приводит к определенным упущенным уязвимостям, поэтому угрозы остаются необнаруженными до более поздних стадий жизненного цикла разработки программного обеспечения.

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

      Факторы риска -
      Управление рисками на этом этапе имеет следующую задачу:

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

   4. Действия по проверке требований - это включает проверку требований, которые были собраны и проанализированы до сих пор, чтобы проверить, действительно ли они определяют, что пользователь хочет от системы.

      Факторы риска -

      • Неправильное понимание терминологии, относящейся к предметной области: разработчики и специалисты по приложениям часто используют терминологию, относящуюся к предметной области, или мы можем сказать технические термины, которые непонятны большинству конечных пользователей. Таким образом создается недопонимание между конечными пользователями и разработчиками.
      • Использование естественного языка для выражения требований. Естественный язык не всегда является лучшим способом выражения требований, поскольку у разных пользователей могут быть разные знаки и условные обозначения. Таким образом, желательно использовать формальный язык для выражения и документирования.

   5. Деятельность по документированию требований - эти шаги включают создание документа с требованиями (RD) путем записи всех согласованных требований с использованием формального языка. RD служит средством коммуникации между различными заинтересованными сторонами.

      Факторы риска -

      • Несогласованные данные требований и RD: Иногда это может случиться из-за сбоев в процессе сбора и документации, фактические требования могут отличаться от задокументированных.
      • Немодифицируемый RD: Если во время подготовки RD не рассматривается структурирование RD с ремонтопригодностью, то будет сложно редактировать документ в процессе изменения, не переписывая его.

      См. Другие этапы SDLC - Интеграция управления рисками в SDLC | Комплект 2