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

Предпосылка - интеграция управления рисками в SDLC | Комплект 1
В этой статье мы обсудим этап проектирования системы и разработки SDLC.
3. Дизайн системы:
Это вторая фаза SDLC, на которой необходимо установить системную архитектуру и удовлетворить все задокументированные требования.
На этом этапе система (операции и функции) подробно описывается с использованием макетов экрана, псевдокода, бизнес-правил, диаграмм процессов и т. Д.
Поддержка деятельности по управлению рисками -

• Точная классификация критичности активов
• Точно определены запланированные меры

Он включает в себя серию из семи мероприятий:

1. Изучить документ требований - разработчикам очень важно участвовать в изучении документа требований, чтобы гарантировать понятность требований, перечисленных в документе требований.

   Факторы риска -
   RD непонятен разработчикам: разработчикам необходимо участвовать в фазе определения и анализа требований, иначе они не будут иметь хорошего понимания системы, которую предстоит разработать. Они не смогут приступить к проектированию, твердо понимая требования системы. Следовательно, вы создадите дизайн для системы, отличный от предполагаемого.

2. Выбор метода архитектурного проектирования - это метод разложения системы на компоненты. Таким образом, это способ определения компонентов программной системы. Существует множество методов архитектурного проектирования, таких как структурированный объектно-ориентированный подход, разработка системы Джексона и формальные методы. Но стандартного архитектурного метода проектирования не существует.

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

3. Выбор языка программирования. Деятельность - Выбор языка программирования должен осуществляться параллельно с архитектурным методом. Поскольку язык программирования должен быть совместим с выбранным архитектурным методом.

   Факторы риска -
   Неправильный выбор языка программирования: неправильный выбор языка программирования может не поддерживать выбранный архитектурный метод. Это может снизить ремонтопригодность и портативность системы.

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

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

   • Сложная система: если разрабатываемая система очень большая и сложная, это создаст проблемы для разработчиков. поскольку разработчики запутаются и не смогут понять, с чего начать и как разложить такую большую и сложную систему на компоненты.
   • Сложный дизайн: для большой сложной системы это может быть возможно из-за путаницы и отсутствия достаточных навыков, разработчики могут создать сложный дизайн, который будет трудно реализовать.
   • Компоненты большого размера: в случае компонентов большого размера, которые в дальнейшем можно разложить на подкомпоненты, могут возникнуть трудности при реализации, а также возникнут трудности с назначением функций этим компонентам.
   • Отсутствие экспертных знаний для повторного использования: Отсутствие надлежащих экспертных знаний для определения компонентов, которые могут быть повторно использованы, представляет серьезный риск для проекта. Поскольку разработка компонентов с нуля занимает много времени по сравнению с их повторным использованием. Таким образом задерживается завершение проекции.
   • Меньше повторно используемых компонентов: неправильная оценка повторно используемых компонентов на этапе анализа приводит к двум серьезным рискам для проекта: во-первых, задержка в завершении проекта, а во-вторых, превышение бюджета. Разработчики будут удивлены, увидев, что часть кода, который считался готовым, необходимо переписать с нуля, что в конечном итоге приведет к перерасходу бюджета проекта.

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

6. Определение проектной деятельности - Эта деятельность включает в себя следующие основные задачи:
   1. Идентифицировать компоненты и определить поток данных между ними
   2. Для каждого идентифицированного компонента укажите его функцию, ввод данных, вывод данных и использование ресурсов.

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

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

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

7. Документирование проектной деятельности - на этом этапе подготавливается проектная документация (DD). Это поможет контролировать и координировать проект на этапе реализации и на других этапах.
   Факторы риска -
   • Неполный DD: проектный документ должен быть достаточно подробным, с подробным объяснением каждого компонента, подкомпонентов, подкомпонентов, чтобы разработчики могли работать независимо над разными модулями. Если в DD нет этой возможности, программисты не могут работать самостоятельно.
   • Несогласованный DD: Если одна и та же функция выполняется более чем одним компонентом. Тогда в этом случае это приведет к дублированию проектного документа и, в конечном итоге, к несогласованному документу.
   • Неясный DD: Если проектный документ четко не определяет компоненты и написан на необычном естественном языке, тогда разработчикам может быть сложно понять предлагаемый дизайн.
   • Большой DD: проектный документ должен быть достаточно подробным, чтобы перечислить все компоненты, полную информацию о функциях, вводе, выводе, необходимых ресурсах и т. Д. Он не должен содержать ненужной информации. Программистам будет сложно понять большой дизайн-документ.

4. Развитие:
Этот этап включает фактическое кодирование программного обеспечения в соответствии с согласованными требованиями между разработчиком и клиентом.
Поддержка деятельности по управлению рисками -
На этом этапе реализуются все разработанные элементы управления.

Этот этап включает два этапа: кодирование и модульное тестирование.

1. Работа по кодированию - этот шаг включает написание исходного кода для разрабатываемой системы. На этом этапе разрабатываются пользовательские интерфейсы. Затем каждый разработанный модуль тестируется на этапе модульного тестирования.
   Факторы риска -
   • Нечеткий проектный документ: Если проектный документ большой и неясный, программисту будет сложно понять документ и выяснить, с чего начать кодирование.
   • Отсутствие независимой рабочей среды: из-за нечеткой и неполной проектной документации команде разработчиков сложно назначить независимые модули для работы.
   • Разработан неправильный пользовательский интерфейс и пользовательские функции: Неполная, непоследовательная и нечеткая проектная документация приводит к неправильно реализованным пользовательскому интерфейсу и функциям. Плохой пользовательский интерфейс снижает приемлемость системы в реальных условиях для клиентов.
   • Язык программирования несовместим с архитектурным дизайном: выбор архитектурного метода определяет только выбор языка программирования. Они должны быть выбраны последовательно, иначе в случае несовместимости язык программирования может не работать с выбранным методом.
   • Повторяющийся код: в больших проектах возникает необходимость переписывать один и тот же фрагмент кода снова и снова. Это отнимает много времени, а также увеличивает количество строк кода.
   • Модули, разработанные разными программистами: В больших проектах модули делятся между программистами. Но у разных программистов разный стиль и образ мышления. Это приводит к непоследовательному, сложному и неоднозначному коду.

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

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

   • Отсутствие полностью автоматизированных инструментов тестирования: даже сегодня модульное тестирование не полностью автоматизировано. Это делает процесс тестирования скучным и однообразным. Тестировщики не утруждают себя созданием всех возможных тестовых случаев.
   • Код непонятен рецензентам: во время модульного тестирования разработчики должны проверять и вносить изменения в код. Если код непонятен, обновить код будет очень сложно.
   • Кодирование драйверов и заглушек: во время модульного тестирования модулям требуются данные из другого модуля или необходимо передавать данные другому модулю. Поскольку ни один модуль сам по себе не является полностью независимым. Заглушка - это кусок кода pf, который заменяет модуль, принимающий данные от тестируемого модуля. Драйвер - это фрагмент кода, который заменяет модуль, который передает данные тестируемому модулю. Написание драйверов и заглушек требует много времени и усилий. Поскольку они не будут поставляться с окончательной системой, они считаются дополнительными.
   • Плохая документация тестовых примеров: тестовые случаи должны быть задокументированы должным образом, чтобы их можно было использовать в будущем.
   • Группа тестирования не имеет опыта: группа тестирования не обладает достаточным опытом для работы с автоматизированными инструментами и для написания короткого и лаконичного кода для драйверов и заглушек.
   • Плохое регрессионное тестирование: регрессионное тестирование означает повторный запуск всех успешных тестовых случаев при внесении изменений. Это экономит время и усилия, но это может занять много времени, если все тестовые примеры выбраны для повторного запуска.

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