Читать онлайн «Основы проектирования корпоративных систем». Страница 21

При этом синхронизация и стабилизация, естественно, присутствуют при производстве каждого релиза. Синхронизация включает проверку спецификаций, т. е. описание функциональности, ограничений, концептуальной схемы программного продукта. Далее происходит сборка: индивидуальные модули, разработанные программистами, объединяются в частичный или полный продукт, осуществляется достаточно частое и интенсивное тестирование, поскольку релизы выпускаются довольно быстро. Кроме того, происходит второй важный процесс – стабилизация: все ошибки, которые найдены тестами, должны быть устранены. При этом заметим, что есть два основных способа устранения ошибок: локализация ошибки и исправление ее непосредственно в том месте, где она допущена (внутри модуля или на стыке модулей), и «обход» ошибки – внесение изменений в другую, не связанную непосредственно с ошибочной часть продукта, призванный «компенсировать» ошибку в данной части продукта.

Итак, синхронизация и стабилизация – два взаимосвязанных процесса, которые необходимо последовательно выполнять при изготовлении релиза программного продукта. При этом финальным этапом для каждого релиза является заморозка – сохранение всей метаинформации (конфигурации) данного релиза в форме файлов, версий этих файлов, даты, времени, ответственного, т. е. всей конфигурации, описывающей финальный срез, работоспособный в соответствии с предъявляемыми к нему требованиями. По сути, это тоже можно рассматривать как продукт, готовый к передаче, но не являющийся полнофункциональным.

Рассмотрим преимущества, которые связаны с моделью Microsoft. Это, во-первых, частое и раннее тестирование. Чем это полезно? Уже говорилось о том, что ошибки в продукте нужно выявлять как можно раньше. Чем позже выявляется ошибка, тем большую работу по ее устранению придется провести, поскольку может случиться так, что ошибка, даже будучи локализованной в одном из модулей, все же влияет на работу соседних модулей, на определенные компоненты проекта, на продукт в целом. Кроме того, она влияет на документацию проекта: придется дорабатывать не только код, но и документацию, причем документацию не только на этот код, но и к проекту, которая описывает модуль, его работу, взаимодействие с другими модулями – диаграммы классов, возможно, диаграммы взаимодействия. Ведь ошибку в логике работы модуля верхнего уровня, который отвечает за общую бизнес-логику работы системы, можно локализовать, но после этого ее устранение потребует достаточно радикальной перестройки значительной части структуры программного обеспечения, большого количества классов и документации к ним. Поэтому, конечно, частое и максимально раннее тестирование – весьма позитивный подход и потенциальное преимущество модели Microsoft.

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

Еще одним преимуществом является постоянная интероперабельность программного обеспечения. Она обеспечивается тем, что модули продукта, как правило, начиная с некоторого этапа тестируются в сборе. Всегда существует работающая версия ПО, или частичный продукт, который проходит тестирование, или полномасштабный, но не полнофункциональный продукт в рамках некоторого релиза. То есть достаточно легко можно протестировать межмодульное взаимодействие, что критически важно при производстве корпоративного программного обеспечения, так как корпоративные системы объединяют огромное количество модулей, взаимодействующих сложным образом. Достаточно сказать, что только в программном продукте Oracle Applications насчитывается около двух десятков того, что называют модулями, т. е. подсистем, которые предназначены для учета, планирования и управления различными видами ресурсов – людскими, производственными, документами. Эта система уже сама по себе достаточно сложна, но в ней и каждый модуль весьма сложен и является, по сути, отдельной системой, состоящей из большого количества подсистем, которые в свою очередь декомпозируются на классы. Таким образом, в целом обеспечить работоспособность такого рода систем с полным удовлетворением требованиям ТЗ практически не представляется возможным.

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

Таким образом, потенциально эта модель жизненного цикла перспективна, однако сложна и поэтому достаточно редко применяется для реализации больших корпоративных систем вне Microsoft. Ее важный недостаток – это то, что нужно уделять много времени синхронизации и стабилизации, т. е. тестированию и устранению тех ошибок, которые найдены тестами, особенно при не совсем хорошей дисциплине проекта или неполном представлении о процессах MSF. По сути, здесь имеется паразитный процесс. После известных событий 11 сентября компания Microsoft поставила безопасность приоритетом № 1 при производстве ПО. И любое ПО, которое производится сейчас, должно соответствовать внутренней модели жизненного цикла, принятой в Microsoft, которая называется SDL (security development lifecycle). При этом декларируется и поддерживается принцип «secure by design» – безопасность уже исходя из подхода к проектированию: сама модель проектирования строится таким образом, чтобы ПО было безопасным. Таким образом, паразитные процессы могут влечь положительные эффекты: увеличение стабильности, надежности, предсказуемости, масштабируемости создаваемого ПО, а для корпоративных систем это критически важные аспекты.