«Риски» - это (в основном) либо плохое управление, либо плохой дизайн. Там мало или нет теории вероятностей.
Сначала начните с любого профиля "риска" для любого проекта разработки программного обеспечения. Стандартные списки участия пользователей, спонсорства, требований, тестирования, обязательств и т. Д. И т. Д. Ничего из этого не меняется.
Веб-SaaS не добавляет никаких новых рисков для управления или пользователей. Пользователи все еще лгут, у менеджеров все еще есть нереальные графики, клиенты требуют нереальных цен.
Вы должны дать время, чтобы изучить технологию. Это не «риск», это стоимость.
Если вы раньше не использовали каркас, постройте в нем что-нибудь маленькое, что вы выбросите. «Самопроверка» или «проверка концепции» или «демонстрация». То, что вы не будете пытаться развить в окончательный производственный код. Это не область риска. Если вы не сделаете что-то маленькое и выбросите его, вы будете бороться с этой технологией и не сможете выполнить ее вовремя и в рамках бюджета.
Если у вас нет надежной модели безопасности, планируйте тратить много времени на вопросы безопасности. Существует множество сценариев угроз, множество технических пробелов, которые становятся дырами в безопасности, и, возможно, какое-то нежелательное программное обеспечение, которое не учитывает ваши варианты использования.
Каждый любит притворяться, что безопасность - это легко. "Это просто пароли, верно?"
Дайте себе достаточно времени на проект, чтобы составить список реальных угроз и выработать решения. В основном это просто - используйте SSL и дайджест-проверку подлинности и надлежащие методы кодирования, чтобы предотвратить все уязвимости OWASP. Но в вашей ситуации могут быть странные вещи.
Если вы не оставите время для обеспечения архитектурной поддержки безопасности на всех уровнях (база данных, веб-сервер, приложение, рабочие процедуры и т. Д.), Вы создадите программное обеспечение с дырами в безопасности.
Если у вас нет юридически обязывающих целей производительности, предоставьте себе время для тестирования производительности, поиска проблем и их устранения. Тестирование производительности не является двухнедельным усилием после сборки программного обеспечения и перед использованием приемочного тестирования. Тестирование производительности - это постоянная борьба с множеством настраиваемых элементов.
Конфигурирование всех различных компонентов сложно; это занимает много времени и требует хорошего симулятора нагрузки. Если вы не позволите себе потратить время на настройку конфигурации всех элементов (обратный прокси-сервер, веб-сервер, приложения, база данных), вы получите программное обеспечение, которое масштабируется неправильно.
Кроме того, дайте время на разработку (и перепроектирование) схемы сообщений. Если вы используете веб-сервисы RESTful, вам потребуется более одной попытки определить ресурсы соответствующим образом. Если вы используете SOAP / XML, вам потребуется много времени, чтобы получить сообщения и права WSDL. Здесь вы будете принимать прискорбные решения, поэтому оставьте себе время сожалеть о них и исправить их, изменив сообщения.
Оставьте много времени для модульного тестирования и создания пригодного для использования пакета модульных тестов. Тестирование веб-сервисов может раздражать, потому что у вас есть надлежащие автономные модульные тесты, а также простые интеграционные тесты веб-сервисов, которые должны быть частью единого комплексного пакета.
Вы захотите создать набор тестов, который позволит вам заполнить базу данных известным приспособлением, запустить ваши серверы, выполнить некоторые клиентские запросы, завершить работу серверов и утилизировать базу данных. Звучит сложно, но вы действительно захотите, когда начнете первый раунд серьезного рефакторинга.
Это не «риски». Это тяжелые вещи, для которых вам нужно оставить время. В частности, вам нужно оставить время для переделки. В первом проекте вы будете принимать решения, которые не являются оптимальными. Вам нужно время, разрешение и техническая поддержка, чтобы разоблачить их.