Разработка системы управления требованиями в проектах с государственным заказчиком

Двирник С.И.

Выпускник группы ITM-15

Школа ИТ-менеджмента

РАНХиГС при Президенте РФ

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

На ранних этапах развития программирования считалось, что на начальных стадиях разработки, при анализе будущей системы, можно полностью описать требования, которые остаются неизменными на стадии проектирования и программирования, где разработчики просто контролируют выполнение в разрабатываемом программном обеспечении.  Это предположение нашло отражение в одной из первых методологий разработки ПО - «модели водопада». К сожалению, практика показала, что все обстоит намного сложнее. Даже при самом тщательном предпроектном анализе в процессе разработки обнаруживаются дополнительные требования, а существующие требования зачастую подвергаются корректировке, изменяющей их до полной неузнаваемости. Самым простым объяснением этому факту является то, что пользователи зачастую не понимают или не знают всех своих потребностей и обнаружение истинных потребностей пользователей происходит после того, как они начинают работать с разработанной для них системой.

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

В общем виде процесс управления требованиями включает:

-  отслеживания связей требований,

- отслеживание состояний требований,

- отслеживание версий требований,

- управления изменениями требований.

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

Кроме того,часто сами методы организации работы как со стороны разработчика, так и со стороны заказчика создают дополнительные преграды для успешного завершения разработки. И как нам кажется, проекты с участием крупных госзаказчиков являются одним из таких примеров, где сам принцип работы обостряет все проблемы, так и так возникающие при работе с требованиями. Этому способствуют следующие факторы:

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

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

- Разработка ведется в соответствии с ГОСТами 34 серии, из-за чего у заказчика складывается ощущение, что после того, как он сформулировал требования, его участие в разработке больше не требуется, что приводит к практически полному отсутствию контактов между разработчиками и конечными пользователями продукта и неизбежно -  к большому количеству допущений и предположений на этапе разработки решения.

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

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

Где же решение проблемы?

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

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

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

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

Проведенная работа подтвердила, что принципы управления требованиями легко адаптируются под проекты любой сложности, но при этом главным риском при внедрении таких систем остается человеческий фактор, а именно:сопротивление сотрудников нововведениям как из-за нежелания делать «лишнюю», как им кажется, работу на низовых уровнях, так и из-за ощущения, что «за нами устанавливают контроль» на уровне руководителей. И, как в том числе показывает данное исследование, без учета этого фактора никакая система управления требованиями работать не будет.