Реферат по теме анализ рисков при разработке программного продукта

Обновлено: 06.07.2024

Каждый день мы сталкиваемся с различными рисками… Вы когда-нибудь задумывались о том, что может произойти, пересекая улицу на красный свет? К примеру, вы можете стать участником ДТП – это результат риска, на который вы пошли в данном случае. Давайте поговорим сегодня на тему оценки рисков в IT и управления этими рисками.

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

Спойлер! В конце статьи будут советы и случаи из практики нас и наших друзей-партнеров ;-) Приятного чтения.

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

А вы задумывались о том, что может случиться в ходе выполнения проекта? Каждый из вас может составить перечень рисков, в котором вы участвуете. Почему? Потому, что…

Не существует проекта без риска

Давайте начнем с определения риска. Термин относится к:

· событию, которое еще не произошло,

· событию, которое можно предотвратить,

· событию негативного или позитивного характера,

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

Говоря об управлении рисками IT проекта, важно обозначить возможные источники этих рисков. Когда мы можем распределить возможные риски по категориям, то их поиск и управление становится намного проще. Тем не менее, категории должны отражать природу взятого проекта. В риск-менеджменте в контексте IT, можно выделить три больших вида рисков.

· внешний риск 🎩 – результат влияния клиента,

· внутренний риск 🔧 – результат самого процесса разработки ПО,

· персональный риск 👥 – результат усилий, качества и вовлеченности отдельных участников команды в проект.

Основываясь на моем собственном опыте в качестве QA специалиста и советах, полученных от коллег из PM отдела, я составила список семи наиболее распространенных рисков при управлении проектом в разработке ПО, дополненный их последствиями и возможными решениями. Назовем это фреймворком IT риск-менеджмента. Давайте обсудим относящиеся к нему стратегии управления рисками.

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

· перегруженные (или недогруженные) спринты,

· брошенные незавершенные задачи,

· полная или частичная переделка приложения,

· изменения в расписании,

· незавершенные или растянутые спринты,

· внезапная необходимость добавления большего количества людей в команду.

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

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

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

Слово “команда” относится к каждому участнику проекта – клиенту, проджект-менеджерам, разработчикам, тестировщикам, дизайнерам, аналитикам.

· задержки сроков выполнения,

· негативное влияние на мотивацию других членов команды.

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

Коммуникация необходима для эффективной работы во время проекта по разработке ПО. Какие последствия влечет за собой слабая коммуникация?

· пробелы в знаниях,

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

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

Что такое проектная документация? Продукт с минимальным функционалом (MVP), описания задач в JIRA и выделенное место для проекта в Confluence – всё это очень важно для успеха проекта.

· команда, зря тратящая время на повторяющиеся вопросы касаемо базовой информации о проекте,

· отсутствие хороших контрольных показателей для использования членами команды как во время проекта, так и после него,

· недостаточные знания членов команды, присоединившихся к проекту на пол пути.

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

Согласно лучшим практикам Agile: “работающее ПО важнее детальной документации”. Тем не менее, не надо считать документацию малозначительным элементом. Как же лучше решить эту проблему?

Отведите некоторое время на написание документации с самого начала. В таком случае, у вас не будет никаких отговорок. Используйте такие инструменты, как JIRA, Confluence или QA Touch – они действительно облегчают работу. Также существует много более специализированных инструментов, которые помогут вам написать документацию для ИПП и других отчетных материалов по проекту. Определите какая информация должна всегда быть доступной. Хорошее место для ее хранения – Confluence. Это система, позволяющая найти всю базовую проектную документацию, членов команды, их роли и другую важную информацию по свойствам проекта, его среды, описания пользователей и перечня функций.

Постоянно используйте специальные условные обозначения для обозначения и описания задач. Помните, документация не должна быть объемной. Ее задача – всестороннее описание проекта простым и понятным языком.

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

· задержки сроков выполнения задач,

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

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

Заказчик не отвечает? Вы уже пытались с ним связаться несколько раз? Скорее всего клиент в отпуске, но не удосужился оповестить других членов команды.

· задержки проекта по срокам из-за молчания клиента,

· демотивация других членов команды.

Покажите клиенту как важно для вас поддерживать хорошие отношения с ним с самой первой встречи. Обозначьте какие решения всегда должны быть приняты совместно и какие – разработчиками/проджект-менеджерами самостоятельно. Когда вы отправляете email с запросом к клиенту, обозначьте почему задержка с ответом может повлечь за собой проблемы (например, трудности с оказанием услуги в срок). Если ни один из способов достучаться до клиента не работает, проджект-менеджер должен принять меры для улучшения коммуникации с заказчиком.

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

· задержки реализации проекта,

· незавершенная задача, мешающая выполнению остальных задач,

· плохая рабочая атмосфера.

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

Давайте поговорим о том, почему не надо быть как этот парень 🙂

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

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

Существует много инструментов и техник, улучшающих процесс идентификации рисков:

✅ детальный анализ целей проекта,

📝 контрольные списки, опирающиеся на опыт предыдущих проектов,

🌐 мозговой штурм – обычный разговор между всеми членами команды может сотворить чудеса.

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

Что вы думаете о процессе управления рисками, представленном в этой статье? Как я говорила ранее, не существует проекта по разработке ПО без рисков. Важно понять, что риск – это нормальное явление в сфере IT. Поэтому нет смысла их бояться. Если вы…

· проводите регулярные собрания,

· незамедлительно решаете проблемы,

· ищите, делитесь, документируете и понимаете информацию и данные,

· мотивируете всех членов команды внутри вашей организации,

… вы добьетесь успеха с большой долей вероятности.

А на сладкое - комментарии специалистов из сферы Digital, ежедневно сталкивающихся с вопросом оценки и предотвращения IT рисков

Могу сказать, что подход к рискам сильно зависит от размера проекта, от того, что за команда, какие уже отношения с заказчиком и от кучи других факторов.

Но, универсального рецепта нет и если пытаться предотвратить все риски - можно запараноить и закрыться дома в кладовке, не желая выходить на улицу

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

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

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

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

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

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

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

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

выявление и анализ требований;
проектирование программного обеспечения;
программирование;
тестирование программного обеспечения.

Выявление и анализ требований

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

1. Двусмысленные требования

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

Проектирование

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

1. Сложность архитектуры программного обеспечения

2. Неудобный пользовательский интерфейс

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

3. Неправильная структура базы данных

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

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

4. Неоптимальный выбор структур данных

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

5. Неоптимальный выбор языка программирования

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

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

Программирование

Основные риски на этапе программирования описаны ниже.

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

2. Нечитаемый код

Последствие этого риска – трудность в изменении и сопровождении программного обеспечения.

3. Создание программных закладок

Программная закладка – это внесенные в программное обеспечение функциональные объекты, которые при определенных условиях (входных данных) инициируют выполнение не описанных в документации функций, позволяющих осуществлять несанкционированные воздействия на информацию [1].
На этапе разработки программистам достаточно легко внедрить в код системы программную закладку. В настоящее время известно 30 публичных случаев обнаружения программных закладок. В большинстве случаев закладки успешно использовались злоумышленниками и были обнаружены уже после активации.

Ошурков Вячеслав Александрович 1 , Макашова Вера Николаевна 1
1 Магнитогорский государственный технический университет

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

Oshurkov Vyacheslav Aleksandrovich 1 , Makashova Vera Nikolayevna 1
1 Magnitogorsk State Technical University

Abstract
This article is dedicated resource risks in projects of software development. The analysis we have identified specific for this project resource risks highlighted standards and methods of minimization of resource risks, and develop a response plan resource risks in projects of software development.

Более 85% опрашиваемых российских организаций, занимающиеся разработкой программных продуктов, учитывают ресурсные риски при разработке проекта [4]. Несмотря на это, больше половины проектов по разработке программного продукта завершаются провалом. Связанно это с отсутствием опыта управления ресурсными рисками. Ниже приведены цифры, свидетельствующие об актуальности проблемы: [7]:

- компании, у которых высокая зрелость, завершают 73% проектов в срок и 69% проектов в рамках запланированного бюджета, и лишь 10% закрываются до завершения;

- компании, у которых средняя зрелость, завершают уже 56% проектов в срок и 58% в рамках бюджета, а 11% проектов закрывается до завершения;

- компании, зрелость которых определена как низкая, завершают уже менее половины проектов в срок – 42%, 44% в рамках бюджета, и 13% заканчиваются до запланированного ранее завершения.

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

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

Аналитики.
Программисты.
Верстальщики.
Тестировщики.

Основными причинами ресурсных рисков в проектах по разработке программного продукта являются [9]:

- недостатки координации работ и слабое регулирование основных ресурсов в проекте;

- ошибки в назначении ресурсов проекта на задачи;

- низкая продуктивность ресурсов;

- ошибки, присущие расписанию при планировании проекта;

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

Взяв за основу иерархическую структуру проекта по разработке программного продукта (см. табл. 1) и ресурсы проекта (см. табл. 2) выделим ресурсные риски.

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

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

Цель большинства проектов в программной инженерии – дать пользу пользователям, как правило, за счет новых функций, повышения эффективности или использования инноваций. Руководители программных проектов согласятся с тем, что поиск таких возможностей идет рука об руку с неизвестностью. Поскольку риски присутствуют во всех программных проектах, необходимо, чтобы заинтересованные стороны усердно работали над выявлением, пониманием и смягчением любых рисков, которые угрожают успеху проекта. Наш опыт подсказывает, что основополагающей успеха для большинства проектов, имеющих ограничения по времени и стоимости, является управленческая деятельность, во главу которой поставлено снижение рисков (а также конкурентоспособная идея продукта, стратегическое планирование и отзывы пользователей).

Что такое риск в разработке программного обеспечения?

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

Что такое управление рисками?

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

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

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

Пять типов рисков при управлении программными проектами

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

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

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

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

План управления рисками

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

Мониторинг и нивелирование последствий

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

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

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

Читайте также: