Пять вещей, которые нужно знать заказчику
DESCRIPTION
Презентация Евгения Злобина, эксперта по построению процессов разработки программного обеспечения компании Microsoft.TRANSCRIPT
Евгений Злобин, 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