Сергей Зыков - Основы проектирования корпоративных систем
Таким образом, потенциально эта модель жизненного цикла перспективна, однако сложна и поэтому достаточно редко применяется для реализации больших корпоративных систем вне Microsoft. Ее важный недостаток – это то, что нужно уделять много времени синхронизации и стабилизации, т. е. тестированию и устранению тех ошибок, которые найдены тестами, особенно при не совсем хорошей дисциплине проекта или неполном представлении о процессах MSF. По сути, здесь имеется паразитный процесс. После известных событий 11 сентября компания Microsoft поставила безопасность приоритетом № 1 при производстве ПО. И любое ПО, которое производится сейчас, должно соответствовать внутренней модели жизненного цикла, принятой в Microsoft, которая называется SDL (security development lifecycle). При этом декларируется и поддерживается принцип «secure by design» – безопасность уже исходя из подхода к проектированию: сама модель проектирования строится таким образом, чтобы ПО было безопасным. Таким образом, паразитные процессы могут влечь положительные эффекты: увеличение стабильности, надежности, предсказуемости, масштабируемости создаваемого ПО, а для корпоративных систем это критически важные аспекты.
Циклы сборки и тестирования при этом подходе должны происходить достаточно часто, в ряде случаев – еженедельно. Это говорит о том, что нужно успевать не только добавлять новую функциональность, но и строить промежуточные сборки к релизам достаточно часто, не только вносить новую функциональность и проектировать в соответствии с новой функциональностью программный продукт, внося изменения в диаграммы, документацию, программный код, но и успевать тщательным образом по соответствующей методике специальными средствами всеобъемлюще тестировать продукт, находить ошибки и исправлять их. Поэтому при коротких промежутках между сборками нужно успевать за счет высокой производительности труда и точного знания методологии Microsoft производить эти циклы тестирования. Иначе можно не успеть добавить новую функциональность в каждую сборку, а в итоге – в релиз и непроизводительно терять время на тестирование. Ввиду этого достаточно редко можно говорить о том, что большие корпоративные системы производятся по методологиям синхроста-билизации и MSF вне стен корпорации Microsoft. К сожалению, сегодня преимущества этой методики достаточно сложно воплотить в жизнь, потому что они требуют высокой специализированной подготовки и, как следствие, дорогих кадров.
Вернемся к спиральной модели, которая представляется в виде четырех стадий (определить – оценить – разработать – спланировать), а графически – чаще всего в виде спирали. Следует обратить внимание, что эта модель во многом схожа с эволюционной моделью, с моделями, которые включают итерации (например, инкрементальной), но, что очень важно, и принципиально отлична от других моделей тем, что на каждой стадии появляется операция, принципиально отличная от других моделей, – оценка рисков. При этом важно отметить, что для ряда моделей возможно комбинирование. Комбинирование оправдано прежде всего с той моделью жизненного цикла, которая не является самостоятельной, это модель быстрого прототипирования. И здесь видно, что на втором этапе происходит анализ и оценка рисков и прототипирование. Когда вы будете заниматься разработкой ПО, нужно помнить, что быстрое прототипирование приходит на помощь не только когда нужно быстро обсудить альтернативы продукта с заказчиком, но и как средство относительно дешевого и простого изготовления продукта, который ведет себя в достаточной мере похоже на готовый продукт с точки зрения функциональности, но ограничен по надежности, устойчивости, безопасности, документации и работать как полноценная корпоративная система не может. Поэтому достаточно интересным является подход, когда на ряде этапов объединяют серьезные большие корпоративные модели жизненного цикла ПО (спиральную, эволюционную) с быстрым прототипированием. Это удобно, потому как в достаточно короткие сроки и с небольшими трудозатратами можно ликвидировать проектные риски, которые возникают, можно проверить и уточнить с заказчиком те или иные возможности программного продукта и те или иные функции, которые более или менее критичны для их включения в последующие релизы или даже версии программного продукта и потребуют отдельного проектирования, договора с заказчиком, ТЗ и т. д. В результате быстрый прототип дает возможность разрешить отдельные риски и вместо директивного прекращения производства программного продукта (как могло бы произойти при разработке по спиральной модели) все же завершить его, пусть и с ограниченной функциональностью.
Еще более детально остановимся на преимуществах и недостатках спиральной модели. В основе спиральной модели лежит тот самый классический жизненный цикл из каскадной модели, к которому добавлен анализ рисков. Риски проекта следует классифицировать, т. е. разделить их на наиболее критичные (которые могут привести к невозможности продолжать проект), наименее критичные (которые можно не учитывать на определенных витках спиральной модели) и промежуточные. Нужно разрешить самые серьезные риски проекта, т. е. найти способ эти риски уменьшить, сделать их приемлемыми для тех рамок проекта (по срокам, стоимости, функциональности), которые заданы заказчиком и разработчиками (у разработчиков тоже существуют ограничения на проектные команды, некоторые представители команд могут быть заняты в разных проектах). При этом существенно, что невозможность устранить риски на каком-то этапе проекта вынуждает этот проект завершить. Быстрое прототипирование – возможно, в несколько шагов – может прийти на помощь в этой модели для снижения как рисков, так и стоимости. Более того, оно может даже дать возможность завершить проект тогда, когда в иных условиях такой возможности бы не было. Вообще говоря, спиральная модель, в отличие от модели Microsoft, может включать и достаточно большое количество итераций (не обязательно три-четыре).
Чем хороша спиральная модель? Прежде всего, если ПО производится на основе этой модели, то за счет прототипирования, если оно применяется, за счет анализа и оценки рисков возможно повторное использование продукта. То есть сам подход к жизненному циклу обеспечивает плавное движение продукта по этому жизненному циклу, плавный переход к его сдаче заказчику. Таким образом обеспечивается возможность повторного использования продукта, даже в условиях изначально высоких проектных рисков. Поскольку анализ рисков происходит изначально, можно ограничиться в ряде случаев упрощенной схемой тестирования. С другой стороны, можно достаточно корректно обосновать, в каких случаях и в какой мере это тестирование проводить, когда завершится тестирование и продукт перейдет к заказчику – исходя из применяемой технологии анализа рисков. На основе анализа рисков получается еще целый ряд метрик, которые дают возможность оценить продукт с точки зрения его качества, надежности, полноты документации, чтобы его можно было передать заказчику. Кроме того, можно относительно гладко перейти к сопровождению продукта за счет того, что продукт последовательно приближается к «боевому» решению в ходе достаточно большого количества витков спирали, каждый из которых подтверждается и уточняется очередной итерацией оценки рисков. То есть имеет место цикличность. В этой связи, несмотря на большие затраты из-за оценки рисков, обеспечивается относительно недорогое сопровождение, а оно является наиболее затратной частью жизненного цикла, принимая на себя около 2/3 всех затрат. Таким образом, на полном жизненном цикле – с учетом сопровождения – может быть получена экономия. По сути, все недостатки, присущие этой модели, вытекают из того, что требуются большие затраты на оценку риска. Во-первых, она применима преимущественно для внутренних проектов – таких, которые ведутся в пределах одного подразделения, разными структурами одной корпорации или структурами, которые имеют давнюю историю партнерских отношений и тесные взаимосвязи. Это происходит потому, что требуется предварительная оценка рисков и представителям разработчика часто необходима полная информация о производственных процессах заказчика, которые могут эти риски повлечь. Эта информация часто относится к категории коммерческой тайны и далеко не всегда может быть в достаточной мере передана разработчику. Поэтому если проект внутренний, эта проблема снимается. Конечно, спиральная модель может быть принципиально применима и для относительно небольших проектов, но, учитывая существенную затратность оценки рисков, она в первую очередь используется для больших корпоративных проектов. Что еще очень важно: она требует опыта оценки рисков. То есть либо в команде разработчика должны быть опытные специалисты по оценке рисков (с умением приоретизировать сложную структуру рисков по целому ряду критериев, особенно в корпоративных системах), либо этих специалистов следует привлекать извне.
