Определение рисков для программных проектов

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

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

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

  • Событие с риском — Это событие повлияет на проект, если это произойдет.
  • Угроза — событие риска, которое окажет негативное влияние на объем, качество, график или бюджет проекта
  • Opportunity — Не все риски представляют собой угрозы, некоторые из них — это возможности, которые окажут положительное влияние на объем, качество, график или бюджет, если они произойдут. Угрозы следует избегать или их последствия уменьшаются, а возможности поощряются или их воздействие усиливается.
  • Вероятность . Вероятность того, что произойдет событие риска.
  • Impact — Обычно это относится к сравнительному кардинальному или порядковому рангу, присвоенному рисковому событию. Это может также относиться к абсолютной денежной стоимости, периоду времени, набору функций или уровню качества.
  • Допуск риска — Это относится к подходу вашей организации к риску. Это консервативно?
  • Порог риска . Толерантность к рискам вашей организации обычно выражается как кардинальный или порядковый компаратор с использованием вероятности событий риска и воздействия для производства компаратора. Риски, оценка вероятности / воздействия которых превышает этот порог, будут устранены или смягчены. Риски, оценка которых ниже порога, приемлемы.
  • Непредвиденность риска — это сумма, выделенная на проект с целью управления рисками. Его следует разделить на две суммы: одну для управления идентифицированными рисками и одну для управления неопознанными рисками или неизвестные неизвестные. Сумма может быть либо денежной суммой, либо количеством времени.

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

Общие риски

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

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

— Эти события риска должны быть захвачены менеджером проекта в начале любого мероприятия по идентификации риска, хотя они, вероятно, будут идентифицированы кем-то еще в команде. Предоставление им видимых для команды заранее любых упражнений по идентификации риска позволит избежать времени, затраченного на их вызывание, и может стимулировать размышление о связанных с этим рисках («….. что, если Джейн нужно было отозвать в проект с более высоким приоритетом, это также приводит к тому, что Фред теряется в проекте? »).

Организационные риски

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

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

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

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

Специфические риски SDLC

. Ваш проект разработки программного обеспечения будет подвергаться некоторым рискам и защищен от других, в зависимости от того, SDLC (жизненный цикл разработки программного обеспечения), который вы выбрали для своего проекта. Устранение рисков является важным фактором при выборе SDLC для проекта, и ваш проект должен выбрать SDLC, который позволяет избежать или уменьшить влияние наиболее вероятных в вашем случае рисков. С этой целью идентификация рисков и выбор SDLC подобны курице и яйцу: трудно определить, что на первом месте. Вот совет для секвенирования двух. Выберите SDLC на основе типа разрабатываемой системы программного обеспечения и организации, в которой вы ее разрабатываете (насколько опытна организация с задействованными инструментами и компонентами? Насколько они опытны в каждой SDLC? Каковы приоритеты проекта ?, и т. Д. ). После того, как вы определились с SDLC, вы можете определить связанные с ним риски, и если уровень риска, связанный с ним, превышает допустимую степень риска вашей организации, вы можете повторно посетить свой выбор.

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

Waterfall

Проекты, использующие методологию Waterfall для разработки, будут наиболее подвержены риску, влияющему на график, и это связано с тем, что в методе нет промежуточных контрольно-пропускных пунктов, чтобы ловить проблемы на ранней стадии сборки. Задержки с любой деятельностью, связанной с сбором требований к Тестированию приёма пользователей, задержит окончательную поставку для проекта. К событиям риска, которые относятся к категории «задержка», относятся: задержки из-за незнания с инструментами или компонентами (например, языки программирования, инструменты тестирования), задержки из-за недооценки усилий, задержки из-за неопытности и задержки в связи с отсутствием сроков выполнения требований .

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

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

Rapid Application Development (RAD)

Цель Rapid Application Development — сократить время, необходимое для разработки программного приложения. Основным преимуществом такого подхода является устранение запросов на изменение — теория состоит в том, что если вы обеспечите достаточно быстрый поворот, не будет необходимости в изменениях. Тем не менее, это обоюдоострый меч. Тот факт, что метод опирается на отсутствие запросов на изменение, серьезно ограничит возможность проекта по их размещению.

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

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

Scrum

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

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

Итерационные методы

Основными итерационными методами являются RUP (Rational Unified Process) и Agile. Эти методы принимают итеративный подход к проектированию и разработке, поэтому здесь сосредоточены. Этот метод предназначен для внесения изменений в проект, который требует динамический бизнес. Цикл определения требований, проектирования, сборки и тестирования выполняется итеративно с каждым циклом, охватывающим неделю (как долго эти циклы будут зависеть от методологии). Итеративная разработка позволяет проектной команде учиться на прошлых ошибках и эффективно внедрять изменения.

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

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

Активность конкретных рисков

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

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

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

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

Эксперты по предмету (МСП)

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

Семинары по риску

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

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

  1. Пригласите правильных МСП — вам необходимо охватить все этапы и все действия проекта.
  2. Общайтесь со всеми деталями проекта, о котором вы знаете. К ним относятся результаты, основные этапы, приоритеты и т. Д.
  3. Получите активную поддержку спонсора проекта. Это должно включать участие в семинаре, где это возможно.
  4. Пригласите хотя бы одно МСП для каждой области или этапа.
  5. Разделите группу на подгруппы по областям знаний или на этапе проекта, где у вас есть большое количество МСП.
  6. Убедитесь, что разные группы или МСП передают свои риски друг другу, чтобы поощрять новые способы взглянуть на их области.

Семинар по рискам не заканчивается идентификацией рисков.

Обзоры

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

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

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

Командные собрания

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

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

Возможно, вы захотите провести отдельные совещания по стратегии риска со своими МСП в тех случаях, когда команда недостаточно знакома с проектными рисками, чтобы сделать они активно участвуют в обновленном регистре рисков. Вы должны использовать этот подход в дополнение к своим командным встречам, когда ваш проект разработки программного обеспечения достаточно велик, чтобы требовать подпроектов. Просмотрите каждый активный риск в реестре и проанализируйте его для воздействия, которое имело на это время. Как правило, по мере приближения работы вероятность возникновения события риска и / или воздействия возрастает. Поскольку большая часть работы будет выполнена, вероятность и влияние будут уменьшаться.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *