Управление рисками для разработки программного обеспечения

Управление рисками — это система выявления, решения и устранения проблем, которые могут нанести ущерб стоимости, графику или техническому успеху проекта или моральному духу команды проекта.

«Завтрашние проблемы — это сегодняшние риски». Поэтому «риск» четко определяется как проблема, которая может нанести некоторый ущерб или угрожать графику проекта, но еще не возникла.

Если вы не возьмете на себя инициативу по управлению рисками, вы столкнетесь с рисками.

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

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

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

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

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

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

Профилактические действия

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

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

Профилактические действия

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

2.  Ловушка 80/20  . Когда менеджер проекта или разработчик говорит, что задача выполнена на 80%, нужно быть осторожным. Потому что оставшиеся 20% могут занять 80% времени, а могут и никогда не завершиться.

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

Профилактические действия:

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

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

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

5.  Вопросы удобства использования. Удобство  использования программного обеспечения включает в себя множество факторов, например, является ли программное обеспечение эффективным, простым в освоении, легким для запоминания, приятным и нелегким для ошибок. Часто из-за плохого юзабилити программного обеспечения пользователи недовольны и даже отсеиваются рынком. При разработке проекта следует уделять внимание вопросам удобства использования, чтобы избежать рисков, связанных с удобством использования программного обеспечения.

Заключение

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