После передачи заказчику наступает фаза сопровождения, которая собственно и является основной, наиболее важной, значимой и затратной частью жизненного цикла (ЖЦ) программной системы. Нужно понимать, что ЖЦ – это процесс прежде всего непрерывный, т. е. переход от стадии к стадии обязан происходить и происходит достаточно плавно, каждая предыдущая стадия является основой для последующей, в том числе и документация, которая выступает достаточно важной составляющей по программному продукту, во многих случаях является "сырьем" для начала и успешного завершения следующей стадии. Жизненный цикл – процесс замкнутый, потому как достаточно сложно переходить с одной стадии к другой, миновав промежуточную. Если говорить о корпоративных системах, то, как правило, это не вполне корректный переход. Кроме того, еще одна важная особенность жизненного цикла – его итеративность, т. е. то, что жизненный цикл происходит итерационно.
В ряде моделей жизненного цикла приходится иметь дело с последовательным приближением решения к цели. На определенном этапе получается не полномасштабный с точки зрения функциональности программный продукт, но продукт, который в полной мере уже можно назвать продуктом в том смысле, что он проходит все перечисленные стадии и после того, как передан на сопровождение в виде первичном, ограниченном по функциональности, продолжает развиваться и эволюционировать – начиная с коррекции анализа требований и проектных спецификаций. То есть происходит повторное проектирование и, по сути, повтор всего ЖЦ. Жизненный цикл нужно понимать как процесс или смену фаз, которая происходит во времени последовательно. Фазы, естественно, взаимосвязаны. Важная взаимосвязь между фазами определяется проектной документацией и документацией по программному продукту.
Если говорить о процессе разработки информационной системы, в том числе и корпоративной, то, по сути, в широком смысле речь идет о полном жизненном цикле. В разработке корпоративных информационных систем предполагается, что речь идет о жизненном цикле от начала до завершения в широком смысле. Однако если говорить более узко, то можно рассматривать лишь ту часть жизненного цикла, которая связана с кодированием и программированием, но в случае корпоративных систем это является слишком ограниченным подходом. Какие стадии связаны непосредственно с кодированием или программированием? Это проектирование системы, когда речь уже идет о построении скелета реализации, некоего наброска основы разрабатываемой программной системы, т. е., по сути, речь идет уже о работе с CASE-средствами, со средствами автоматизированного проектирования программного обеспечения, которые обладают возможностями кодогенерации для некоторых стандартных компонентов, составляющих основу программной системы. Затем происходит реализация системы – кодирование. После этого реализация ведется вместе с тестированием, и после реализации фрагментов программной системы происходит их интеграция, сборка, которая также связана с тестированием, и передача заказчику. Может быть также стадия сопровождения.
Важный вывод, который можно сделать из сказанного, состоит в том, что для экономичной разработки корпоративных приложений в контексте корпоративных информационных систем, которые являются очень крупными и сложными, имеют большое количество взаимодействующих компонентов, необходимо представлять всю схему жизненного цикла, начиная от постановки задачи, анализа и спецификации требований и заканчивая передачей заказчику, сопровождением и выводом из эксплуатации. Только при полном понимании того, как организованы эти стадии, каждая из них, как они взаимодействуют, в рамках каких моделей они существуют, можно сформировать адекватное представление о функционировании этих систем, их разработке и понять, каким образом эту разработку сделать более экономичной. Этот аспект является крайне важным в проекте и вдвойне актуальным, учитывая текущую кризисную ситуацию, когда бюджеты на разработку систем урезаются. Можно найти возможность сэкономить, чтобы система стала ненамного хуже по таким показателям, как надежность, масштабируемость, вычислительная эффективность, эргономичность, функциональность, безопасность и сопровождаемость, документируемость, однако ее разработка заняла бы более короткое время или позволила высвободить людские ресурсы.
Еще одно важное определение – это методология разработки информационных систем – корпоративных и преимущественно ИС. Под методологией будем понимать подход, подразумевающий совокупность методов или практических приемов, нацеленный на завершение отдельно взятой фазы, или стадии, или ряда стадий, которые могут быть взаимосвязаны, жизненного цикла программного обеспечения.
Фазы ЖЦ ПО только что были перечислены – это анализ и спецификация требований, первичное детальное проектирование, реализация вместе с тестированием, интеграция или сборка, когда появляется сначала частичный, затем полный программный продукт, финальное тестирование продукта, приемочное тестирование и передача заказчику и, наконец, сопровождение и вывод из эксплуатации. В дальнейшем речь пойдет о практических приемах и более общих методах, которые необходимы для корректного завершения каждой из этих стадий в соответствии с различными подходами. При этом методология может включать применение моделей, методов и средств. Модели – более формальное представление элементов или этапов, необходимых для реализации действий по разработке ЖЦ программных систем. Это прежде всего математические или другие формальные модели, скажем, модель виртуальной машины, функционирующей в среде Microsoft.NET, во многом основана на абстрактной машине, разработанной Юрием Гуревичем (специалист Microsoft Research). Модель носит формальный характер – она является математической моделью, основанной на понятии "состояние".
Кроме того, методология может включать методы, т. е. техники, которые являются менее формализованными. Одним из примеров может являться подход Microsoft Solution Framework, который содержит так называемые вехи (milestones) и результаты (deliverables). Кроме того, методология может включать (и в случае корпоративных систем, как правило, включает) применение специфических инструментальных средств, которые поддерживают весь жизненный цикл ПО. Это и анализ и разработка требований, и проектирование, преимущественно в форме диаграммирования, составления различных UML-диаграмм, кодирование и тестирование, Microsoft использует целый ряд специальных средств тестирования при реализации подхода MSF – реализация, отладка. Одним из примеров является Microsoft Visual Studio.NET, также поддерживается командная работа на основе Teamsystem или Teamsuit. Примерами классов таких средств являются средства быстрого прототипирования (rapid application development), CASE-средства компьютерной поддержки и разработки программного обеспечения или автоматизированной поддержки разработки ПО. Системы управления корпоративным контентом и целый ряд классов других систем.
Продолжим описание методологий разработки информационных систем и попробуем сосредоточиться на их пригодности – пригодности рассматриваемых классов методологии разработки информационных систем в отношении корпоративных систем. Если говорить о международных стандартах или методологиях, то это прежде всего IDEF-диаграммы и подходы, связанные со стандартом ISO. Федеральные российские стандарты – это стандарты ГОСТ и ESPD. В НИУ ВШЭ есть внутренний стандарт для производства документации, он достаточно четко отслеживается, даже при создании студентами курсовых проектов документация готовится в этих форматах.
Существует также целый ряд корпоративных стандартов, которые используются иногда несколько шире, чем предполагают пределы этих корпораций, – Rational Unified Process (RUP), который используется в и за пределами IBM, MSF, используемый преимущественно в Microsoft. Есть подход, который используется внутри корпорации Oracle, – CDM (Custom Development Method), который тоже во многом является корпоративным и вне стен Oracle, как правило, не используется.
Перечисленные подходы RUP, MSF, CDM можно отнести к корпоративным: они достаточно всеобъемлющи, широки и действительно охватывают полный жизненный цикл программных систем корпоративного типа, вполне применимы и по качеству подготовки документации, и по характеру и масштабу процессов для получения полномасштабных корпоративных информационных систем. Другие подходы, такие как Agile, eXtreme Programming (XP), Scrum, являются в некотором смысле ограниченными, в частности потому, что не всегда поддерживают полномасштабную документацию, и выход по проекту в полном смысле этого слова не может быть назван корпоративным программным решением. Эти подходы хороши для проектов с большой неопределенностью, которые характеризуются высокими рисками, когда изначально традиционные методологии, перечисленные в разделе корпоративных, могут не вполне адекватно работать. На самом деле нет гарантии, что сработает и один из этих подходов, но все же они разрабатывались специально для того, чтобы вести такие высокорисковые, сложные и неопределенные проекты. Конечно, в полном смысле такие подходы, как Agile, X P, Scrum, нельзя назвать корпоративными. Они не приводят к решениям корпоративного типа.
Таким образом, существует целая иерархия подходов к разработке систем. При этом то, что называется моделями ЖЦ (каскадная, спиральная модель) и методологии (такие как RUP, XP) – это во многом параллельные направления разработки корпоративных информационных систем. То есть работая в рамках RUP или, скажем, MSF, можно вести проектирование ИС по спиральной или каскадной модели. Эти понятия не являются взаимоисключащими, скорее они дополняют друг друга. В этой связи модели и методологии являются понятиями ортогональными. Остановимся на тех методологиях, которые представляют основной интерес с точки зрения проектирования информационных систем и применимости для корпоративных ИС.
Первые подходы – это ГОСТ, ISO, т. е. стандарты. Это достаточно всеобъемлющий список документов, которые призваны поддерживать процессы проектирования и разработку программных продуктов корпоративного типа. Однако в практике проектирования часто это идет вразрез с интересами и требованиями заказчика, т. е. часто проектирование и подготовка полномасштабной документации по ГОСТ и ESPD являются избыточными, и западные стандарты ряд документов не поддерживает или поддерживает в ограниченном объеме.
В следующих главах будут более подробно рассмотрены RUP, MSF, CDM и гибкие методы Agile, X P, Scrum, которые в определенном смысле и в определенной степени могут применяться для корпоративных систем и при этом являются достаточно прагматичными. Если говорить о RUP, он может включать как каскадный, так и спиральный вариант проектирования с точки зрения модели жизненного цикла, но в целом он основан на итеративном подходе и включает быстрое прототипирование. Быстрое прототипирование, в принципе, можно выделить как модель жизненного цикла, но эта модель не является самостоятельной – она не поддерживает разработку боевого кода программной системы, т. е. не позволяет получить достаточно хорошо документированный и надежный код с точки зрения работоспособности и количества ошибок. Кроме того, этот код недостаточно масштабируем, он не рассчитан на большое количество одновременных пользователей и на те функциональные ограничения по количеству пользователей, по пропускной способности сети, по нагрузке на серверы программного обеспечения, по работе с базами данных, которые будут испытывать полномасштабные версии корпоративной информационной системы. Поэтому быстрое прототипирование достаточно хорошо как дополнительный подход, метод и модель жизненного цикла, который применяется в рамках RUP вместе с итеративным подходом. Этапы жизненного цикла здесь называются потоками. В явном виде выделяются роли. Ниже будет подробнее изложено об этом и о том, как производится документация, какие артефакты процессов, связанных с RUP, важны для ИС, корпоративных ИС.
Другой подход связан с синтезом каскадной и спиральной моделей – это MSF. Важные аспекты этого подхода – синхронизация и стабилизация. В основе проектирования программного обеспечения по этой схеме лежит процессный подход. Процессы, активности будут описаны подробнее в главе, которая будет посвящена этой тематике.
Еще один менее известный и используемый подход, более жесткий с точки зрения детерминированности и определенности этапов ЖЦ и связанный с каскадной моделью преимущественно – это Oracle CDM. Он используется для производства программных систем, в том числе и корпоративных программных систем, на основе продуктов Oracle – это Oracle Enterprise/Database Server, Oracle Business Suit, семейство модулей, которые предназначены для ERP, учета, планирования и управления корпоративными ресурсами: людскими, финансовыми и производственными ресурсами, прошлым документооборотом и целым рядом других ресурсов. При внедрении Oracle Applications сейчас вполне может использоваться этот подход. Также важно, что он включает прототипирование, это позволяет облегчить и удешевить процессы проектирования.
Гибкие методологии, о которых мы будем говорить отдельно, – Agile, X P, Scrum. Они основаны на итеративном подходе к ЖЦ, т. е. последовательном уточнении программного продукта по мере согласованием с пользователем требований к нему. Поскольку продукты, которые разрабатываются в рамках этих методологий, имеют изначально достаточно высокую степень неопределенности, в этой связи важно понятие рефакторинга, или последовательного улучшения кода. Также достаточно распространенное применение получили так называемые лучшие практики, или некоторые неформальные критерии и приемы разработки программного обеспечения. Неформальные потому, что сложно разработать количественные методы оценки этих критериев и в ряде подходов эти практики могут использоваться как в полном объеме, так и в некотором подмножестве. Эти подходы наиболее гибки.
Нужно заметить, что и MSF, и RUP имеют некий диапазон возможных вариаций для разработки программных систем того или иного класса и масштаба. То есть, в принципе, можно использовать MSF и RUP не только для корпоративных систем, но и с некоторыми ограничениями и упрощениями – для систем меньшего класса. Для этого также существуют специальные ограничения, специальные подходы – так сказать, урезанные, сокращенные методологии. Такие подходы позволяют сэкономить на жизненном цикле, на производственном процессе как по времени, так и по людским ресурсам, а в итоге – по стоимости.
Завершая рассказ о введении в корпоративные информационные системы, нужно сделать следующие основные выводы. Понятие системы возникает, когда речь идет о корпорации – большой, территориально распределенной производственной структуре с общими бизнес-задачами, но с различными направлениями деятельности, с различными языками реализации, т. е. требуется локализация для разных стран тех систем, которые внедряются. Вообще говоря, программное обеспечение, которое производится для корпорации, представляет собой комплекс систем, которые нацелены на анализ, учет, планирование и управление различными областями деятельности этой корпорации. При этом такой комплекс имеет достаточно сложную схему взаимодействия. Одним из возможных решений по объединению такого рода систем является корпоративный портал. Эти программные компоненты создаются на основе различных архитектурных подходов. Это могут быть мейнфреймы, системы на основе архитектуры файл – сервер, клиент – сервер, интернет-архитектуры, различных технологий баз данных, например Oracle, Microsoft и т. д. Это могут быть системы, которые хранят информацию различной степени структурированности: хорошо структурированные реляционные таблицы, слабо структурированные аудиовидеоданные, отсканированные документы с нечетко определенными полями и т. д. Поэтому схемы взаимодействия элементов этого комплекса достаточно сложны. И для того чтобы понимать важность этих задач, необходимо представлять себе сложность. Это терабайты информации, в ряде случаев – уже петабайт. Так, скажем, информационные системы корпорации Intel в своей совокупности представляют уже несколько петабайт, т. е. крайне большой объем информации. В этой связи корпоративные информационные системы представляют собой достаточно сложный объект для исследования. Такие системы достаточно быстро растут: за пять лет объемы данных примерно удваиваются. То есть можно говорить о быстром росте объемов данных, в этой связи еще сложнее становится управлять такими большими программными комплексами.
Это только некоторые аспекты. Вообще разработка информационных систем – это многоаспектный процесс. В течение разработки информационная система проходит целый ряд стадий, связанных с так называемым жизненным циклом. Это и анализ и спецификация требований, и проектирование – первичное и детальное, и реализация, тестирование, интеграция, передача заказчику в эксплуатацию, сопровождение. То есть это достаточно сложный процесс последовательно сменяющих друг друга стадий. Тем не менее этот процесс является замкнутым и итерационным: ряд стадий при отдельных подходах, скажем, при спиральной, эволюционной, инкрементной моделях, последовательно повторяется. Конечно, для того чтобы говорить о корпоративных системах, нужно достаточно детально и полно представлять себе все этапы этого жизненного цикла, взаимодействие этих этапов и ту документацию, которая производится на каждом этапе и является во многом основой такого (в том числе документального) взаимодействия. При каскадном подходе нельзя перейти к следующему этапу, если предыдущий этап документально не закрыт и на соответствующем документе, который подтверждает корректность и финализацию этого этапа, не появляется подпись ответственного лица. В этой связи нужно представлять себе всю схему ЖЦ, для того чтобы корректно выбрать модели, методы и средства, которые включают в себя те методологии проектирования КИС, о которых мы будем говорить дальше.
Остановися подробнее на жизненном цикле ПО (ЖЦ ПО). В начале главы уже были упомянуты его основные этапы. Фазы, которые связаны с разработкой программных систем, включают: анализ и спецификацию требований к программному продукту, проектирование программного продукта – первичное и детальное, уточненное, реализацию и тестирование элементов или модулей отдельного программного продукта, интеграцию или сборку этих модулей в частичный или полный программный продукт вместе с интеграционным тестированием, передачу заказчику после приемочных тестов, промышленную или опытную эксплуатацию, которая называется сопровождением и занимает по времени и средствам основную часть жизненного цикла, и, наконец, вывод из эксплуатации. Для реализации этого жизненного цикла применяются различные модели, методы и инструментальные средства. Подробнее рассмотрим основные этапы ЖЦ.