Сергей Зыков - Основы проектирования корпоративных систем

Еще нужно отметить как недостаток то обстоятельство, что ряд продуктов требует, к сожалению, сразу полнофункционального решения, причем это может быть связано во многом и с пожеланиями заказчика. Ряду заказчиков нужен сразу полнофункциональный интернет-магазин, который включает в себя и 3D-витрину, и возможность оплаты кредитной картой, и различные системы электронной оплаты. В некоторых случаях было бы полезно отслеживание доставки (оно реализовано, например, в таких службах, как DHL, это удобно и полезно). Но здесь все зависит от ТЗ и требований к продукту. Если продукт сразу требует полной функциональности, наверное, подойдет какая-то другая модель (может быть, каскадная), которая позволяет реализовать все за один проход. Конечно, и риски в этом случае будут выше, но о них речь пойдет далее, в связи со спиральной моделью, которая специфически их учитывает и призвана с ними бороться. Если же говорить об инкрементальной модели, то нужно отметить, что не для каждого продукта и корпоративной системы она годится.

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

Еще важное замечание: ряд продуктов (это может быть связано с заказчиками или конъюнктурой рынка, конкуренцией на рынке) требует революционного изменения самой концепции, основополагающих решений, которые закладываются в функциональные требования, план проекта и задание на релиз. Если заказчик меняет требования слишком часто, внезапно и значительно и нет возможности эти требования с ним согласовать и прийти к достаточно эволюционному их изменению, то получается, что каждый раз нужно не просто переработать значительную часть продукта, а, по сути, создать новый. Тем самым практически происходит переход к модели Build-and-fix. То есть нужно заново создать существенно отличающийся от предыдущего релиза продукт. При этом очень плохо, что в отличие от Build-and-fix, приходится заново осуществить полный жизненный цикл для каждого релиза: полностью описать требования в виде ТЗ, вести проектирование, т. е. создать огромное количество диаграмм прецедентов, диаграмм потоков данных, сценариев использования, которые их конкретизируют, диаграмм классов – сначала предварительных, а затем детальных, где заново оговариваются все начальные значения переменных, атрибуты и методы, взаимодействие между классами, методы-аксессоры, все существенные локальные и глобальные переменные, все алгоритмы, их реализация, структуры данных и т. д. Ведется тестирование: разрабатывается план тестирования – как продукт будет тестироваться, в каком порядке, какие тесты будут созданы для передачи продукта. Также можно сказать о пользовательской документации, документации для администраторов: продукт нужно будет по-другому устанавливать и настраивать, он будет иметь другой интерфейс, пользователи будут вынуждены работать с ним совершенно иначе, коды ошибок и вся остальная информация изменятся. И всю эту документацию также будет необходимо переделать. То есть речь идет о достаточно сложном варианте Build-and-fix, который подразумевает еще и полномасштабную документацию, отработку всех этапов жизненного цикла ПО. Поэтому такое производство, конечно, влечет огромное количество накладных расходов и является экономически нецелесообразным, и в условиях продукта, который быстро выходит за рамки исходной концепции, инкрементальная модель является недопустимой – будь то корпоративные или более простые системы.

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

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

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