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

Двирник С.И.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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