Какие выводы мы можем сделать по итогам анализа вклада в жизненный цикл различных его стадий, с точки зрения сроков и стоимости. Прежде всего надо сказать, что львиная доля затрат в жизненном цикле это сопровождение, это примерно 2/3, порой до 70% и это при предсказуемой разработке. То есть, если разработка ведется анархично, мы рискуем потерять проект в целом или не завершить его в сроки или выйти существенно за рамки бюджета. С другой стороны, существенно отметить, что кодирование, как таковое вносит относительно небольшой вклад, порядка 5% в общий бюджет проекта. То есть любые ухищрения при кодировании, на самом деле не будут окупаться в значительной мере, даже если мы говорим о кризисе. Если же мы включаем в рассмотрение обрамляющие стадии, это тестирование и архитектурное проектирование, детальное проектирование, которое предшествует кодированию, то мы получим примерно 30%, то есть достаточно существенный вклад. Здесь надо сказать, что имеет смысл достаточно внимательно просмотреть те артефакты, которые будут создаваться и постараться, если это возможно, сэкономить на этих артефактах, еще раз достаточно внимательно проанализировав их состав. Кроме того, надо заметить, что те самые обрамляющие стадии, прежде всего тестирование, которое находится вокруг кодирования, они помогают нам существенно повысить качество программного продукта, поэтому надо внимательно анализировать, на чем именно имеет смысл экономить, а где, при каком скажем, пороге, остаточных ошибок, уже имеет смысл прекратить тестирование. Но до этого порога нам необходимо дойти, то есть обеспечить необходимое качество программного продукта. Надо заметить, что большинство существенных ошибок, которые приводят к значительным проблемам при сопровождении и реализации продукта, естественно происходит на ранних стадиях. То есть концептуальные ошибки дизайна, концептуальные ошибки архитектурного проектирования и еще раньше анализы и спецификация требований, могут приводить к тому, что значительною часть продукта придется доработать или переработать в соответствии с теми ошибками, с теми несоответствиями, которые были замечены. Это достаточно дорого и именно поэтому в кризис необходимо осуществить ревизию каждого этапа жизненного цикла и внимательно просмотреть, убедиться в том, что на самом деле мы ничего важного не упустили и с другой стороны ничего не дублируем, не повторяем, скажем, похожий код в двух различных модулях. То есть, не заставляем программистов заниматься кодированием и тестированием, по сути дела, однотипных модулей которые могут быть существенно упрощены и сведены, скажем, к одному модулю. Таким образом, можно сделать вывод о том, что грамотная постановка задачи, использование кейс средств, средств поддержки разработки, правильный выбор моделей жизненного цикла, выбор архитектурной схемы разработки, четкая ревизия проекта на всех стадиях, начиная от анализа, спецификаций и требований и заканчивая ревизией финальной, перед передачей продукта в эксплуатацию. Дисциплина, то есть соблюдение сроков и стандартов, передачи документации соседям по команде, и конечному пользователю, и разумная достаточность этой самой документации, которая сопровождает программный код. Это ключ к успеху проекта в кризис.