Письмо 05 - Позднее обнаружение недоработок

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

Самая большая неприятность состоит в том, что недоработки предыдущего уровня обнаруживаются не на последующем уровне, а существенно позднее, например, на стадии опытной или рабочей эксплуатации.Например, на стадии опытной эксплуатации может всплыть ошибка в описания предметной области. Это означает, что часть проекта должна быть возвращена на начальный уровень работы. Можно только сожалеть о том, что такая ситуация не является экстраординарной. Дело в том, что в качестве экспертов, участвующих в описании предметной области, нередко выступают будущие пользователи системы, которые не всегда могут чётко сформулировать то, что они хотели бы получить. Если к этому добавить семантические различия у тех, кто ставит задачу и у тех, кто берётся за её решение, то проблема ещё более усложняется. И на это наслаивается возможная неадекватность инструментальных средств, ограниченность аппаратных средств и т.д. и т.п.

Есть и административные сложности при такой работе над проектом. Можно представить, что две смежные части проекта были возвращены на какой-то уровень для доработки. В каждом были сделаны определённые изменения. При этом одна часть подвергалась изменениям независимо от другой части. В результате может оказаться утраченной согласованная работа этих частей. Предположим, что существует две части проекта A0 и B0. Каждая из частей была переработана, и соответственно были получены новые версии: A1 и B1. При этом часть A1 может успешно работать частью B0, а часть B1 может не менее успешно взаимодействовать частью A0. Но нет никаких гарантий, что части A1 и B1 тоже будут успешно (бесконфликтно) взаимодействовать между собой. Реальные же проекты могут состоять не из двух, а из нескольких десятков частей (подсистем), что превращает администрирование таким проектом в очень непростую задачу. В свою очередь, сложность администрирования тоже является основой для ошибок. Теперь мы замкнули вертикальный цикл. В реальной жизни такая ситуация приводит к выпуску подверсий, исправлений, новых версий подсистем и т.п. Этот процесс, как правило, длится в течение всего жизненного цикла системы.