РЕЦЕНЗИИ
Вигерс К. Разработка требований к программному обеспечению. Пер. с англ. М.: ИТД "Русская Редакция", 2004. - 576 с.
Обсуждая фундаментальные основы современных технологий разработки ПО, Эдвард Йодан в своей классической книге "Структурное проектирование и конструирование программ" (М.: "Мир", 1979) называет несколько свойств, которые должны характеризовать понятие "хорошая программа". Главное среди них - "она работает согласно спецификациям". Наверное, это положение не требует особых пояснений. Конечно, важны и проблемы эффективности кода, и надежности, и гибкости сопровождения, а также выполнение проекта в рамках отведенного бюджета и пр. Но самое важное - программа должна выполнять задачу, определенную заказчиком.
Сложность программных проектов неизменно растет, и соответственно увеличиваются затраты не только на собственно выполнение тех или иных работ по созданию продуктов, но и на управление всем этим производственным комплексом. Именно поэтому в последние годы проблема создания ПО так активно рассматривается в рамках единого взаимосвязанного цикла Application Life Management (управление жизненным циклом программ), одним из компонентов которого является управление требованиями к ПО (Requirement Management).
Тут нужно отметить, что еще несколько лет назад этот вид работ обычно относили к начальному этапу создания ПО и называли "определением требований" (Requirement Define). Однако сейчас общепризнанным является то, что речь идет именно об управлении требованиями как о процессе, сопровождающем полный цикл жизни ПО. При этом в данной проблеме можно выделить несколько существенных моментов: требования динамично меняются на протяжении всего периода разработки и эксплуатации программных продуктов. Дело тут не только в изменении намерений заказчика, уточнении набора функций и т. д. Довольно часто оказывается, что необходимость коррекции исходного задания определяется технологическими проблемами, которые возникают уже в ходе самой разработки; в процессе разработки занято много специалистов, и всех нужно своевременно информировать об изменениях; прямого взаимодействия "заказчик - программисты", как правило, уже давно нет на практике. Связь осуществляется через довольно длинную цепочку "заказчик - руководитель проекта - руководитель группы - программист", и нужно обеспечить, чтобы исходные требования заказчиков были адекватно переданы исполнителями. Другими словами, все участники проекта должны говорить на одном языке, понимать друг друга.
Вот все эти вопросы и рассматриваются в рецензируемой книге. Это перевод второго издания английского варианта, дополненного новыми главами о роли аналитика требований, о важности бизнес-правил, а также описанием специфики взаимодействия с разработчиками из сторонних организаций.
Книга состоит из 23 глав, объединенных в четыре части: "Требования к продукту: что, почему и кто" (главы 1-4), "Разработка требований к ПО" (главы 5-17), "Управление требованиями к ПО" (главы 18-21) и "Особенности реализации процесса построения требований" (главы 22 и 23). Наверное, вряд ли имеет смысл комментировать отдельные разделы этой работы. Могу только сказать, что она представляет интерес для всех специалистов, кто так или иначе вовлечен в процесс создания ПО. Конечно, в первую очередь речь идет об аналитиках и разработчиках, непосредственно занятых формированием требований. Но с книгой полезно познакомиться и менеджерам проектов, дизайнерам, программистам, тестерам, а также маркетологам и менеджерам по продажам продуктов. Нужно упомянуть и еще один сегмент читательской аудитории: клиентов, для которых создается ПО. Весь материал изложен в довольно традиционной для американских авторов манере доверительного общения с читателем, когда общие философские размышления сопровождаются примерами из практики и весьма конкретными рекомендациями.
В книге неоднократно подчеркивается, что процесс управления требованиями к ПО в чем-то очень похож на тот, что имеет место при создании других "несофтверных" продуктов, но в то же время в нем много отличий. Специфика создания ПО (мы сейчас не будем отвлекаться на обсуждение этой бесконечной темы) отражается, в частности, в том, что, несмотря на рост критичности ПО с точки зрения его потребителей, заказчики и исполнители уделяют явно недостаточное внимание разработке технических заданий: именно просчеты, допущенные на стадии формирования требований, являются причиной 40-60% дефектов в проектах. Решение же проблемы - в повышении затрат на выполнение такого рода работ, в том числе формализованными методами. Стоит, наверное, привести основные рекомендации автора, сформулированные в заключительной части книги: вовлекать представителей клиентов как можно раньше и шире; разрабатывать требования итеративно и поступательно; представлять требования различными способами, чтобы удостовериться, что их все понимают; убедиться, что все группы заинтересованных лиц считают требования полными и корректными; контролировать внесение изменений в требования.
После изучения основного содержания читатели смогут проверить, как они усвоили материал, с помощью набора вопросов, приведенных в первом приложении. Наверняка будут полезны и сведения, приведенные в трех других приложениях (описание моделей управления качеством, руководство по решению проблем с разработкой требований и примеры документирования), а также довольно подробный словарь терминов. Отдельно стоит сказать о впечатляющем библиографическом списке (к сожалению, только англоязычном), в котором представлено около 200 современных работ по проблематике разработки ПО.
