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