Подведя итоги рассмотрения моделей жизненного цикла
в кризисных условиях, мы рассмотрели две модели
циклического характера, это объектно-ориентированные
модели, инкрементальная модель.
Попробуем остановиться, с акцентировать внимание
на тех особенностях и проблемах, которые несут эти модели.
Когда мы можем ими пользоваться, и в чем собственно возникают
подводные камни или проблемы при реализации жизненного
цикла по этим моделям. Ну, если мы начнем с инкрементальной
модели, преимущества понятны. Это быстрый и плавный ввод
функциональности, плавное знакомство заказчика с
теми возможностями, которые несет систем, возможность
поработать с этой системой на ранних стадиях, когда
у нас реализована только основное функциональное
ядро. Достаточно быстрый возврат инвестиций, что
предельно важно в кризисных условиях.
С другой стороны эта модель подходит только для эволюционирующих
продуктов, для революционных продуктов, для продуктов,
которые быстро выходят за рамки первоначальной
концепции, такая модель не подходит. И в этом случае
модель вырождается в Build-and-Fix, code a bit, test a bit (CABTAB) или модель
«проб и ошибок». К сожалению, здесь, в работе, с моделью
«проб и ошибок», мы получаем уже не адекватные финансовые
затраты, да, наверное, и временные затраты, при
повторной многократной разработки программного
продукта, не в форме матрешек, которые вставлены одна
в другую, а в форме проектирования, реализации, интеграции,
тестирования и передачи заказчику, вот такой большой
матрешки, каждый раз, которая обнимает всю функциональность
необходимую для реализации. То же самое, то есть ту же
самую схему code a bit, test a bit (CABTAB) или Code-and-Fix, Build-and-Fix
«пробы и ошибки», мы получим и для другой модели, которая
была рассмотрена для объектно-ориентированной модели, в том случае если
разработка будет вестись недостаточно дисциплинированна,
без соблюдения стандартов, и тот самый параллелизм
дает нам возможность тонко настроить процессы производства,
существенно сэкономить на времени ввода в эксплуатацию
программной системы и получить, вообще говоря, продукт
достаточного качества, будут сведены на нет. Получится,
что разработчики будут работать, в целом дольше,
поскольку одна часть команды будет ожидать рабочих продуктов
от другой части, для того что бы, скажем, произвести
интеграцию, и во время ее не получит. В итоге мы можем
получить, что сроки сдачи буду сорваны, время, по
сколько будет потрачено, значительно больше, чем
планировалось, вызовет определенные простои и
потери финансовых средств, и потери людских ресурсов.
Это может негативно сказаться на нашей антикризисной
разработке. Таким образом, каждая модель
не является «серебреной пулей» и накладывает, кроме
того, определенные обязательства на команду разработчиков
при, в том числе и антикризисной разработке программных
систем.