Другой сложностью, возникающей при реализации такого рода систем, является динамическая конкретизация методов, содержащая в своей основе концепцию полиморфизма. К сожалению, механизм создания полиморфных функций, потенциально дающий большую мощь и экономию трудозатрат при создании методов, которые могут обрабатывать объекты гетерогенной природы за счет того, что тела функций конкретизируются только в момент выполнения программы, приводит к тому, что на стадии тестирования программы нельзя в полной мере обработать все возможные сценарии конкретизации полиморфных методов. За счет этого во время выполнения получаются непредсказуемые ошибки, которые могут сводить на нет всю работоспособность системы – приводить к зависаниям, потерям данных, непредсказуемости поведения программы и т. д. Естественно, это отрицательно сказывается на корпоративных бизнес-процессах.
Таким образом, объектно-ориентированная модель, разработанная на основе концепций объектно-ориентированного программирования, таит в себе большие опасности при производстве сложного, крупномасштабного программного обеспечения и в связи с концепцией полиморфизма. Нужно еще раз напомнить, что применение этой модели связано с существенными ограничениями, поскольку при отсутствии дисциплины, стандартов реализации кодирования, тестирования и документирования архитектура проекта получается некорректной и приходится постоянно ее менять. В этом случае паразитный процесс коррекции преобладает над основными процессами – проектированием и анализом. Таким образом, объектно-ориентированная модель, основанная на целом ряде интересных концепций – абстракции, наследования, полиморфизма, в больших проектах может приводить к вырождению этой модели в Build-and-fix.
Другие подходы к жизненному циклу включают в себя гибкие методологии, такие как Agile (рис. 3.10), Scrum (рис. 3.11), eXtreme Programming (рис. 3.12). Следует отметить, что направление этих подходов ортогонально моделям жизненного цикла. Они, в отличие от IBM Rational и MSF, применимы к проектам с большими неопределенностями, возможно, большими рисками, но меньшего масштаба, чем корпоративные информационные системы. С другой стороны, методологии – это параллельное направление проектирования систем, которое связано скорее с задачей проектного менеджмента, чем с задачей построения системной архитектуры.
Рис. 3.10. Жизненный цикл ПО, гибкие методологии, Agile
В заключение стоит еще раз отметить, что был рассмотрен ряд моделей – Build-and-fix, водопадная, быстрого прототипирования, инкрементальная, синхростабилизации, объектно-ориентированная, упоминалась эволюционная модель. Build-and-fix пригодна не для корпоративных проектов, а для небольших проектов с предсказуемым циклом развития и объемом порядка 1000 строк. Водопадная модель применима для корпоративных систем, обеспечивает четкую дисциплину проекта и хорошую управляемость, так как основана на большом количестве документов, которые производятся в ходе жизненного цикла, но в итоге из-за только одного прохода получившееся ПО может не соответствовать потребностям заказчика. Быстрое прототипирование несамостоятельно, в ряде случаев вызывает у разработчиков соблазн повторного использования быстро разработанного ненадежного, недокументированного кода. Способствует сопровождаемости и обеспечивает максимально ранний возврат инвестиций, так как приводит к консенсусу по поводу требований заказчика. Инкрементальная модель требует открытой архитектуры и может выродиться в Build-and-fix, но в целом удовлетворяет потребностям клиента из-за эволюционного процесса разработки продукта. Модель синхростабилизации обладает рядом преимуществ, но не получила широкого применения вне Microsoft. Спиральная модель пригодна в первую очередь для внутренних проектов, так как требует специфических знаний по оценке рисков. Объектно-ориентированная модель обеспечивает итерации и паралеллизм, но опять же при слабой дисциплине проекта может выродиться в модель Build-and-fix.
Рис. 3.11. Жизненный цикл ПО, гибкие методологии, Scrum
Рис. 3.12. Жизненный цикл ПО, гибкие методологии, eXtreme Programming (XP)
Глава 4
Выбор модели жизненного цикла корпоративных систем
В предыдущей главе были рассмотрены преимущества и недостатки основных моделей ЖЦ – Build-and-fix, водопадной (каскадной) модели, где проектирование корпоративных информационных систем происходит в один проход, модели быстрого прототипирования (несамостоятельной, так же как и Build-and-fix), инкрементальной, модели синхронизации и стабилизации Microsoft, которая в настоящее время смещается в сторону MSF, спиральной и объектно-ориентированной модели. Также были рассмотрены основные характеристики и особенности моделей, их основные достоинства и недостатки.