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