Профиль управления рисками для проектов веб-программного обеспечения?

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

Кто-нибудь знает подходящую модель профиля риска для такого проекта?

Спасибо,

Адриан

4 ответа

Решение

"Риски" - это (в основном) либо плохое управление, либо плохой дизайн. Там мало или нет теории вероятностей.

Во-первых, начните с любого профиля "риска" для любого проекта разработки программного обеспечения. Стандартный список пользователей: бай-ин, спонсорство, требования, тестирование, обязательства и т. Д. И т. Д. Ничего из этого не меняется.

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

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

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

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

    Всем нравится делать вид, что безопасность - это легко. "Это просто пароли, верно?"

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

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

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

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

  4. Также предоставьте время для разработки (и перепроектирования) схемы сообщений. Если вы используете веб-сервисы RESTful, вам потребуется более одной попытки определить ресурсы соответствующим образом. Если вы используете SOAP/XML, вам нужно будет уделить много времени получению сообщений и WSDL. Вы будете принимать прискорбные решения здесь, так что оставьте себе время сожалеть о них и исправить их, изменив сообщения.

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

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

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

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

Безопасность

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

Качественный

  • производительность - возвращаемые результаты соответствуют требуемой производительности
  • возвращать результаты в согласованном формате

техническое обслуживание

  • определенный путь обновления (связь, обратная совместимость и т. д.)

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

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

"Процесс Interdirect, состоящий из девяти шагов, чтобы избежать катастрофы веб-дизайна"

  1. Следуйте заранее определенной методологии доставки проекта.
  2. Начните с нового клиента / проекта вопросника / контрольного списка.
  3. Проведите "встречу открытия", чтобы проанализировать требования.
  4. Определите обязанности членов команды.
  5. Создайте документ с функциональной спецификацией.
  6. Попросите клиента подписать его и согласиться со спецификацией.
  7. Обеспечить постоянное постоянное общение с клиентами.
  8. Представьте выполненную работу на утверждение клиента как можно скорее.
  9. Создайте доверие клиентов с самого начала и сделайте его приоритетным.

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

Другие вопросы по тегам