Все новости от 26 февраля 2004 г.

Продолжаем изучение программирования для Microsoft .NET

Вигерс К. Разработка требований к программному обеспечению. Пер. с англ. М.: ИТД "Русская Редакция", 2004. -- 576 с.

Обсуждая фундаментальные основы современных технологий разработки ПО, Эдвард Йодан в своей классической книге "Структурное проектирование и конструирование программ" (М.: "Мир", 1979) называет несколько свойств, которые должны характеризовать понятие "хорошая программа".

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

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

Именно поэтому в последние годы проблема создания ПО так активно рассматривается в рамках единого взаимосвязанного цикла Application Life Management (управление жизненным циклом программ), одним из компонентов которого является управление требованиями к ПО (Requirement Management).

Тут нужно отметить, что еще несколько лет назад этот вид работ обычно относили к начальному этапу создания ПО и называли "определением требований" (Requirement Define).

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

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

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

• в процессе разработки занято много специалистов, и всех нужно своевременно информировать об изменениях;

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

  Другими словами, все участники проекта должны говорить на одном языке, понимать друг друга.

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

Книга состоит из 23 глав, объединенных в четыре части: "Требования к продукту: что, почему и кто" (главы 1--4), "Разработка требований к ПО" (главы 5--17), "Управление требованиями к ПО" (главы 18--21) и "Особенности реализации процесса построения требований" (главы 22 и 23).

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

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

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

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

Стоит, наверное, привести основные рекомендации автора, сформулированные в заключительной части книги:

• вовлекать представителей клиентов как можно раньше и шире;

• разрабатывать требования итеративно и поступательно;

• представлять требования различными способами, чтобы удостовериться, что их все понимают;

• убедиться, что все группы заинтересованных лиц считают требования полными и корректными;

• контролировать внесение изменений в требования.

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

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

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

Обсуждение и комментарии

	Денис - dennytbsoft.ru 27 Feb 2004 6:26 PM
Все хорошо, только причем тут .Net? Разработчикам, использующим другие инструменты, не нужно управлять требованиями? :)