Пять вещей, которые нужно знать заказчику

Евгений Злобин, Microsoft [email protected]

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

О чем мы будем говорить

− Особенности типичной разработки корпоративного сайта

− Какие проблемы возникают?− “Пять” вещей которые должен

учитывать заказчик корпоративного сайта

− Возможные сценарии организации работ – Microsoft Application Lifecycle Management

− Вопросы

Особенности типичной разработки корпоративного сайта

− Область применимости: разработка сайта требующая интенсивного кодирования и дизайна.

− Что характерно для типичного процесса− Заказчик формулирует высокоуровневые

“хотелки”− Заказчик в лучшем случае контролирует

архитектуру и занимается тестированием/приемкой

− Заказчик считает, что исполнитель сделает, все что ему нужно Нет УПРАВЛЕНИЯ процессом разработки (ALM)

Какие проблемы возникают?

− Заказчик получает не то, что он хотел:− не качественное управление требованиями− Отсутствие взаимодействия/контроля за исполнителем

(в момент приемки понимаем, что ЭТО НЕ ТО, что мы хотели)

− Слабая сопровождаемость разработанного приложения: − Программный код не отторгается от исполнителя

(сложно передать другому исполнителю)− Программный код не кондиционный− Не используются методики контроля качества− Возможные проблемы с безопасностью кода

− Низкое качество разрабатываемого программного кода: ошибки проявляются в процессе эксплуатации

5 вещей которые …

− Управление требованиями очень важно – см. картинку. Важно понимать, что только вы знаете, что вы хотите. Нужно осуществлять регулярный (итерационный) контроль создаваемого продукта

− Исполнитель создающий для вас программный продукт не заинтересован в создании отторгаемой версии (больше затрат, могут поменять)

− Качество ваша забота, если в процессе эксплуатации “полезут” ошибки – плохо будет вам. Для исполнителя вложения в качество – это дополнительные расходы

− В договоре на создание продукта надо прописывать, что исполнитель предоставляет собираемый и самоверифицируемый код (unit test)

− Не функциональные требования к системе очень важны: безопасность, масштабируемость должны постоянно отслеживаться (по возможности на ранней стадии)

Возможные сценарии организации работ – Microsoft Application Lifecycle Management

− Использование процессного инструментария поддерживающего облачную модель (Team Foundation Services, Team Foundation Build)− Единый репозиторий для требований,

кода и ошибок− Отслеживание текущего статуса

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

прототипирования

Магический квадрант для средств управления конфигурациями и изменениями

Dashboard

Вопросы?

Visual Studio 2010