Компания Док.Ру выиграла тендер на развитие АИС CMS – системы управления взаимоотношениями с клиентами. Система АИС CMS автоматизирует все бизнес процессы взаимоотношения с корпоративными клиентами:

продажа, подключение, отключение, изменение услуг, технологическая проработка заказов, заключение и сопровождение договоров. Она построена на технологии IBM Lotus Notes/Domino и интегрирована с целым рядом других автоматизированных систем (Inventory и биллингом).

Бизнес-задача

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

Организация процесса разработки программного обеспечения

На данный момент проект организован в соответствии с процедурами и практиками Док.Ру управления процессами развития компьютерных систем. Наши процедуры основываются на методологии RUP (Rational Unified Process) и PMBOK (Project Management Body of Knowledge).

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

С точки зрения планирования и управления командой: вся работа на проекте подчиняется гибкому плану с приоритезацией. Весь проект разбит на подпроекты и задачи. Каждый подпроект реализуется своей командой, включающей аналитика, разработчика и тестировщика. Управление требованиями в каждом конкретном подпроекте занимается аналитик. Планирование задач и ресурсов осуществляется руководителем проекта. Каждый подпроект на начальном этапе планирования идеологически имеет как минимум 2 итерации анализа-проектирования-разработки: разработку прототипа (первое приближение) и доводку. Данное решение было принято после 2-х проектов, в которых на финальном этапе перед сдачей проекта приходилось весьма существенно изменять требования, что приводило к получению результата, который заказчик не мог принять. В проекте, включающим 2 цикла разработки, существенно снижен риск не попасть в требования заказчика.

Каждый подпроект формально стартуется, формируется рабочая группа.

Аналитика включает в себя разработку Технического задания, которая включает в себя процесс сбора требований, их формализацию и согласования . Сбор требований происходит по отлаженной формальной процедуре, которая включает: установочную встречу, утверждения плана взаимодействия, проведение встреч согласно плану. Процесс аналитики после подписания ТЗ переходит в процесс управления требованиями и изменениями.

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

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

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

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