Технические риски обычно приводят к отказу функциональности и производительности. Давайте рассмотрим наиболее распространенные примеры технических рисков и стратегии снижения рисков проекта:
Выбор стека технологий и группы внедрения, вероятно, является наиболее важным решением, которое вы принимаете на этапе исследования проекта. Каждая команда обладает базовыми знаниями или опытом в конкретных областях, технологиях или решениях. Чрезмерное внимание к некоторым популярным технологиям является одним из самых популярных рисков пользовательского программного обеспечения.
Решение: нет необходимости слишком зацикливаться на популярных технологиях. Вместо этого вам нужно указать проблему, которую вы пытаетесь решить — например, повышенную безопасность, связь в режиме реального времени или мобильное реагирование — и выбрать стек технологий, который подходит для решения этой проблемы.
Большинство рисков связано с интеграцией со сторонними системами, плагинами или системами управления контентом. Если эти технологии и инструменты популярны и хорошо известны вашей команде, риск достаточно низок. Популярные библиотеки часто поддерживаются сильным сообществом, поэтому решения новых проблем можно найти быстро.
Решение: просто убедитесь, что все инструменты имеют правильные и обновленные спецификации. Добавьте приличный буфер к оценке на случай, если будут обновления, с которыми разработчики еще не работали.
Если технология новая, риск может увеличиться многократно. Неразумно думать, что команда справится с рисками интеграции программного обеспечения так же быстро, как с известными.
Решение: Вам потребуется хотя бы базовая спецификация новой технологии. Проверьте, требуется ли какая-либо оплата за поддержку, и включите цену в оценку. Удвойте время на проектное обучение и документируйте все возникающие проблемы.
Взять на себя текущий проект с существующим исходным кодом — очень рискованная сделка. Команде необходимо исследовать исходный код, оценить его качество и определить элементы, которые следует подвергнуть рефакторингу для повышения эффективности. Команда также должна изучить проект с точки зрения пользователя, чтобы понять поток в целом.
Решение: запросить всю существующую документацию; попытаться исследовать вопросы, которые усложнили работу в какой-то момент. Используйте любую возможность, чтобы поговорить с предыдущей командой и обсудить детали. Возможно, имеет смысл выполнить анализ исходного кода, прежде чем делать оценку, так как вы никогда не узнаете, с какими трудностями столкнетесь впоследствии.
Естественно, риски присутствуют в каждом проекте, поэтому следует отметить способы управления распространенными рисками при создании ПО:
Вот несколько примеров снижения рисков в программных проектах:
1 часть. Как управлять рисками при разработке ПО
Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…
Вызов внешних действий - это возможность действия, выходящего за рамки возможности работы с БД через…
После выполнения действий в SQL на клиенте иногда возникает необходимость что-то обновить или сделать. Для…
Вы можете обратиться к внешним API через использование Внешних действий (код apirequest, использование описано в…
В системной таблице as_trace хранятся данные по работе приложения. Поле code определяет тип события: DBLREQ…
Рассмотрим механизм анализа ошибок, как это всё работает, и как его использовать. Когда происходит ошибка…