Вы знаете, что в мире около 30% проектов по разработке программного обеспечения закрываются до завершения, около 50% завершаются с двойным превышением бюджета и только 20% можно считать успешными? Вы можете себе представить, чтобы 30% зданий никогда не были достроены? На самом деле интересно было бы взглянуть на Минск в таком случае: наверное, впечатляющее зрелище...

В чем же причина такого плачевного положения в отрасли разработки ПО? Вот три наиболее часто встречающихся фактора, которые создают проблемы в проектах:

• Недостаток исходной информации от клиента: 13% всех проектов
• Неполные требования и спецификации: 12% проектов
• Изменение требований и спецификаций: 12% проектов

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

Как обычно, русскоязычная техническая литература отстает от англоязычной на несколько лет, хотя в последнее время разрыв немного сокращается. Поэтому первая приличная книга, посвященная управлению требованиями, появилась только в 2002 году. Книга называется "Принципы работы с требованиями к программному обеспечению", а ее авторами являются Дин Леффингуэлл (Dean Leffingwell), вице-президент компании Rational Software, и Дон Уидриг (Don Widrig) - независимый консультант, который, впрочем, тоже связан с Rational. Даже не стоит говорить о привычной отвратительной полиграфии. К счастью, сама книга настолько хороша, что ее следовало бы прочитать, даже если бы ее издали на туалетной бумаге.

Читать действительно интересно. Не то чтобы стиль был уж совсем легким и простым, но все же авторы постарались не усложнять то, что можно было усложнить. Хороший перевод тоже благоприятно отражается на восприятии информации. Авторы отлично знают, что такое управление требованиями, как лучше структурировать информацию и как подавать ее читателю - а это самое главное. В итоге книга получилась целостной и понятной - отличный учебник для системного аналитика.

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

Анализ проблемы

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

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

Понимание потребностей пользователей

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

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

Выявление требований - сложный процесс. Тем ценнее методики выявления требований, описанные в книге:

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

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

Определение системы

В этом разделе подробно описывается, как документировать требования. Недостаток раздела в том, что документирование требований рассматривается в контексте методологии RUP (Rational Unified Process). Конечно, многие мысли и замечания можно использовать в любом процессе, но их придется вылавливать самостоятельно. Положительная сторона в том, что даны шаблоны документов, которые лучше помогают понять механизм документирования требований.

Управление масштабом проекта

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

Уточнение определения системы

Требования к ПО для разработчиков несколько отличаются от требований клиентов. Для разработчиков важны детали, поэтому итоговый документ SRS (System Requirements Specification) содержит функциональные требования (то, что должна делать система), нефункциональные требования (производительность, надежность и т.п.) и ограничения проектирования (платформы, СУБД и т.п.).

Есть в книге уникальная деталь. Шестая часть начинается на странице 293 и мирно следует до страницы 320, а затем... неожиданно вместо 321 страницы находится страница 289, причем с абсолютно идентичным содержанием! А еще через четыре страницы шестая часть начинается вновь:). В итоге в книге полностью отсутствуют главы 32 и 33, которые должны были быть посвящены проверке правильности системы. Это не просто ложка, это настоящий черпак дегтя от киевского издательства...

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

Отличительной особенностью книги является ориентированность на Rational Unified Process, что и понятно, так как оба автора имеют к компании Rational прямое отношение. Несмотря на это, книга полезна всем без исключения, потому что анализ проблемы и методы выявления требований универсальны.

Михаил ДУБАКОВ