Шрифт
Source Sans Pro
Размер шрифта
18
Цвет фона
© Зыков С.В., 2012
© Оформление. Издательский дом Высшей школы экономики, 2012
Все права защищены. Никакая часть электронной версии этой книги не может быть воспроизведена в какой бы то ни было форме и какими бы то ни было средствами, включая размещение в сети Интернет и в корпоративных сетях, для частного и публичного использования без письменного разрешения владельца авторских прав.
Предисловие
Монография преследует несколько взаимосвязанных целей. Прежде всего, это систематизация знаний из областей, связанных с проектированием крупномасштабных, распределенных программных комплексов, состоящих из разнородных компонентов. На основе проведенной систематизации открывается возможность классификации программных систем с последующим методологическим обобщением для жизненного цикла исследуемого класса программных комплексов, которые как по характеру, так и по масштабу своего применения вполне соответствуют термину «корпоративные».
Современные корпоративные системы – это петабайты (тысячи терабайт) данных, как минимум, удвоение объема информации каждые пять лет, необходимость адаптации к требованиям бизнеса практически «на лету», архитектурная и структурная разнородность компонентов и, конечно, глобальная распределенность. В подобных условиях обобщения до уровня технологических схем и инструментальных средств, как правило, не приводят к адекватной интеграции гетерогенных приложений в унифицированные, крупномасштабные программные системы. Поэтому для управления жизненным циклом корпоративных программных комплексов необходимо прежде всего получить адекватное обобщение на уровне математических моделей с последующей конкретизацией представлений на уровне системной архитектуры, информационных технологий, а также конкретных инструментальных и программных средств и, наконец, практических внедрений.
Предлагаемое в настоящей работе методологическое обобщение включает весь спектр возможных (и, как оказывается, необходимых) уровней представления данных в корпоративных программных комплексах в ходе их разработки. К таковым следует отнести прежде всего уровни:
1) математического моделирования концептуального представления;
2) анализа и проектирования архитектурной схемы;
3) реализации, интеграции и адаптации/расширения программных систем.
Естественно, все перечисленные уровни необходимы, взаимозависимы и взаимосвязаны: математические модели адекватно поддержаны промышленными технологиями, инструментально-программными средствами и приводят к отраслевым внедрениям гетерогенных корпоративных программных комплексов с практически приемлемыми эксплуатационными характеристиками.
Для построения генерализации корпоративных программных комплексов на уровне моделей – как для представления данных, так и для манипулирования ими – потребовался творческий синтез основных положений целого ряда математических теорий, связанных с объектными моделями. В основе рассматриваемых моделей лежит так называемый аппликативный подход к вычислениям, при котором в фокусе внимания находится операция приложения функции к аргументу. Дальнейшее развитие созданной методологии разработки программных систем корпоративного типа – поддержка разработанных моделей программными технологиями, системными архитектурами и инструментальными средствами.
Структура книги во многом является отражением именно такого, методологически последовательного и концептуально наполненного подхода к организации жизненного цикла прикладных корпоративных систем – от моделей до примеров внедрения. Именно таким образом – путем последовательного уточнения – и происходит разработка прикладных систем, при этом окончательный вид конкретной детализации каждого элемента обобщенной методологии зависит от характера и масштаба приложений.
Автор выражает искреннюю благодарность ведущим экспертам университета Carnegie Mellon (G. Taran, N. Bier и др.), а также профессорам С.М. Авдошину (НИУ ВШЭ) и В.Э. Вольфенгагену (МИФИ, МФТИ) за методическую помощь при подготовке монографии.
Отдельно следует отметить целый ряд студентов НИУ ВШЭ и МФТИ (в первую очередь К. Лузгину, Е. Первушину, А. Ядройцева, а также многих других), ассистировавших при предварительном редактировании теста и активно способствовавших выходу в свет настоящей публикации.
Автор полагает, что книга окажется полезной системным аналитикам и архитекторам, разработчикам крупномасштабных приложений, а также студентам, аспирантам и другим категориям исследователей корпоративных программных систем и комплексов.
Раздел I. Модели, методологии и архитектуры разработки корпоративных систем
Глава 1. Введение в разработку корпоративных систем
В представленной монографии описана разработка корпоративных информационных систем, даны понятия информационных систем вообще и корпоративных в частности, а также то, для чего, собственно, нам необходимы эти знания и как их применять непосредственно в разработке.
Основные понятия, которые будут представлены далее, – это информационная система и корпорация, т. е. большое, территориально распределенное предприятие с общими задачами, для которого развитие информационных систем, их жизненного цикла происходит несколько иначе, чем информационных систем во обще. В монографии будет рассказано о жизненном цикле информационных систем, относящихся к классу корпоративных приложений, а также основных методологических подходах к их проектированию, реализации и разработке.
Предметом исследования выступают корпоративные информационные системы. Здесь значимо каждое слово. И корпоративная специфика – специфика крупных распределенных предприятий, и понятие системы, т. е. достаточно сложной совокупности различных компонентов, и, конечно, собственно информационной системы как вполне определенного подвида. Назначение данной книги состоит в том, чтобы: дать базовые, фундаментальные представления о предмете, продемонстрировать применение моделей к разработке корпоративных систем, правда, не совсем в математическом понимании этого слова; ввести основные понятия, обозначить их взаимосвязи и применение к корпоративной специфике, описать современную теорию и практику разработки корпоративных приложений.
Будут описаны приложения, т. е. специфичные информационные системы, которые играют существенную прикладную роль. Будет говориться как о практическом аспекте разработки этих приложений, массе аспектов, которые связаны с жизненным циклом системы, во взаимосвязи этапов развития и проектирования и реализации такого рода информационных систем, так и о теоретическом минимуме, который необходим для правильного понимания того, откуда эти системы возникли, как они развиваются, работают и почему нам необходимо планомерно их расширять, создавать и развивать.
Цель курса – формирование целостной концепции проектирования и реализации, иными словами, разработки, корпоративных приложений в современных условиях. Будет применяться подход Карнеги-Мелонского университета к дисциплине «Software engineering» (программная инженерия), в том смысле, что некоторые его математические модели будут далее упомянуты. В целом необходимо сосредоточиться на теории, которая адекватно поддерживает практику, и именно в том необходимом объеме, который поможет правильно составить систему понятий. А также придерживаться этой системы в соответствии с той многочисленной литературой, которая имеется по предмету, для того чтобы иметь возможность грамотно и с хорошим теоретическим обоснованием говорить о таком непростом и многообразном предмете, как корпоративные информационные системы.
Кроме того, речь пойдет о разработке хорошего стиля проектирования систем. Под хорошим стилем нужно понимать многофакторную оптимизацию, т. е. достаточно сложный процесс – совокупность процессов, которые сопровождают развитие информационных систем. В любом проекте по разработке корпоративных систем имеет место треугольник компромиссов: функциональность, стоимость, временные затраты. То есть существует ряд ограничений, которые необходимо учитывать, и для создания хорошего продукта следует уметь находить компромисс.
Кроме того, когда речь пойдет о жизненном цикле программных систем, этапах их развития, проектирования, реализации, внедрения и сопровождения, будут описаны практические примеры их внедрения, а также даны необходимые знания, которые требуются для получения основных навыков, характеризующих такого важного специалиста в разработке корпоративных информационных систем, как системный архитектор – человек, который отвечает за проектирование информационных систем с технологической точки зрения.
Естественно, предмет, имеющий технический характер и нацеленный на разработку приложений, прикладных систем, предназначен преимущественно для студентов и магистрантов, которые специализируются на разработке приложений.
Необходимая основа – некоторое понимание моделей, на которых базируется объектный подход к проектированию и реализации программных систем. С математической точки зрения моделью объекта может являться функция. Часто речь будет идти о λ-исчислении и других моделях об исчислении функций, которые представляют собой фундамент моделирования, в том числе информационных систем, и вообще фундамент для объектных моделей. Что касается основ проектирования и программирования – желательны знания в области объектно-ориентированного подхода к проектированию и разработке приложений и основ технологий Microsoft, в частности Microsoft.NET.
В конце книги будут даны некоторые практические решения: на базе группы компаний «Итера» и на основе технологий Microsoft, в том числе программного обеспечения Microsoft Dynamics. Будет использована открытая информация, которая имеется на сайтах Microsoft, связанных с Dynamics, а также другие открытые источники информации.
Во введении говорится о корпорации как о большой распределенной группе компаний с общими задачами, о программных системах, приложениях как конкретизации этого понятия для решения тех или иных прикладных задач, о жизненном цикле этих систем – от анализа и проектирования до реализации, внедрения, сопровождения и вывода из эксплуатации. Также речь идет о документации, которая сопровождает этот жизненный цикл и без которой, собственно говоря, программный продукт, передаваемый заказчику, таковым не является. Рассказано, что такое методология, как можно ее понимать в узком и широком смысле. Обсуждены основные этапы жизненного цикла программных систем, в том числе соответствующие жизненному циклу корпоративных систем, и, кроме того, представлены основные методологии разработки прикладных программных систем.
Описание корпоративных информационных системах следует начать с понятия корпораций. Под корпорацией понимается крупная (от 1000 сотрудников), территориально распределенная (часто по всему земному шару) глобальная, трансконтинентальная производстенная структура, т. е. бизнес-структура, которая нацелена на производство продукции. Достаточно большие корпорации, например нефтегазовые, – Газпром, известная крупная и распределенная структура реального сектора экономики, TNK-BP, где объединены ресурсы как отечественных, так и зарубежных производителей нефти и газа, и нефтегазовая группа компаний «Итера», объединяющая порядка 150 компаний в 24 странах мира с общей численностью персонала 10 тыс. человек. Несмотря на распределенность структуры, у корпорации, как правило, есть единый центр управления и общие бизнес-цели и задачи.
Следует отметить, что корпорацию можно понимать и шире. Можно относить к корпорациям и не вполне производственные, но тем не менее распределенные и объединенные общими бизнес-целями структуры. С точки зрения корпоративных информационных систем это вполне допустимый угол зрения. Так, в качестве примера корпоративной структуры можно рассматривать Минпромэнерго, научно-исследовательские учреждения, такие как ИПУ РАН, который включают не менее 10 филиалов по России, университеты, такие как МИФИ, НИУ ВШЭ. ВШЭ имеет около 20 различных площадок только в Москве, МИФИ является также достаточно распределенной структурой с точки зрения как студенческого городка, так и распределенности по территории России. Все эти и другие аналогичные структуры вполне можно отнести к корпорациям.
Теперь остановимся на программных системах. Они представляют собой совокупность программ под общим управлением, т. е. примерно так же, как и корпорация как группа компаний – это совокупность взаимодействующих программ. При этом программная система предназначена для решения либо некой замкнутой задачи, либо целого ряда взаимосвязанных задач. И если мы говорим о корпоративной системе, там таких задач достаточно много: это учет, планирование и управление различного рода ресурсами, прежде всего людскими, финансовыми и специфическими производственными ресурсами, основными средствами, процессом производства и целым рядом других процессов.
Приложения – это несколько более узкая сущность, нежели просто программа. Они предназначены для решения функциональных задач по обработке информации в рамках той или иной предметной области. Приложение так или иначе связано с предметной областью. Поэтому если говорить о корпоративных приложениях, корпоративных системах, то речь пойдет о решении функциональных бизнес-задач корпорации с помощью специализированных в каждом случае прикладных программ.
Некоторые отрасли и задачи, такие как планирование, управление, организация, учет, уже были перечислены. Конечно, в масштабе корпорации все эти контуры управления имеет смысл рассматривать не изолированно, а интегрированно. Таким образом, получаются интегрированные или согласованные программные системы, и открывается возможность консолидации данных и построения консолидированных отчетов, например, по персоналу в рамках корпорации в целом, отдельных ее компаний, более мелких подразделений, или такой же детализации, скажем, связанной с финансовой отчетностью и отчетностью по другим производственным ресурсам.
В любой информационной системе, и корпоративной в том числе, каждое приложение, которое функционирует в рамках этой системы, проходит определенные этапы своего становления и развития. Как правило, последовательность этих этапов остается неизменной. Хотя в зависимости от методологий проектирования и разработки применяемых корпоративных систем эта последовательность может претерпевать незначительные изменения, существует ряд этапов и фазы, которые определяют жизненный цикл программных систем. Первым этапом является постановка задачи, т. е. определение характера и масштаба того программного решения, которое будет разработано. Следующий этап связан с анализом требований, которые выдвигает заказчик к программной системе, с анализом того, насколько эти требования адекватны, корректны, полны, непротиворечивы, насколько они соответствуют характеру и масштабу проблемы и полно и точно описывают ту предметную область и задачу, которую должно решать программное обеспечение. Исходя из анализа требований строятся проектные спецификации – это следующий этап жизненного цикла программных систем. На основе проектных спецификаций в форме диаграмм, сценариев использования, т. е. определенных достаточно формально изложенных текстовых данных и технического задания в том числе, происходит проектирование программной системы. Это следующий этап жизненного цикла – построение в некотором абстрактном виде, прежде всего в форме диаграмм, основных функций, которые эта система будет реализовывать. По сути, речь идет о поэтапной детализации от абстрактного представления к конкретному в ходе развития системы вдоль ее жизненного цикла.
После проектирования, т. е. после того, как все основные объекты, которые будут реализованы в рамках информационной системы, получили свои очертания и становится известно, какими характеристиками они будут обладать, как будут взаимодействовать друг с другом, начинается этап реализации. Это – программирование, кодирование отдельных частей программной системы, которая декомпозирована на них в ходе этапа проектирования. Реализацию сопровождает тестирование программного продукта, которое призвано ответить на вопрос, насколько это программное обеспечение корректно, нет ли в нем внутренних ошибок. Еще один важный вопрос, на который должно ответить тестирование, – в какой мере разработанное программное обеспечение соответствует тем проектным спецификациям и требованиям, которые были к нему сформулированы. Если тестирование не выявляет существенного количества критического уровня ошибок, то можно переходить к фазе передачи заказчику, когда на основе специально созданной серии приемочных тестов осуществляют приемку и передачу в эксплуатацию созданной программной системы или компонента корпоративной информационной системы.
После передачи заказчику наступает фаза сопровождения, которая собственно и является основной, наиболее важной, значимой и затратной частью жизненного цикла (ЖЦ) программной системы. Нужно понимать, что ЖЦ – это процесс прежде всего непрерывный, т. е. переход от стадии к стадии обязан происходить и происходит достаточно плавно, каждая предыдущая стадия является основой для последующей, в том числе и документация, которая выступает достаточно важной составляющей по программному продукту, во многих случаях является «сырьем» для начала и успешного завершения следующей стадии. Жизненный цикл – процесс замкнутый, потому как достаточно сложно переходить с одной стадии к другой, миновав промежуточную. Если говорить о корпоративных системах, то, как правило, это не вполне корректный переход. Кроме того, еще одна важная особенность жизненного цикла – его итеративность, т. е. то, что жизненный цикл происходит итерационно.
В ряде моделей жизненного цикла приходится иметь дело с последовательным приближением решения к цели. На определенном этапе получается не полномасштабный с точки зрения функциональности программный продукт, но продукт, который в полной мере уже можно назвать продуктом в том смысле, что он проходит все перечисленные стадии и после того, как передан на сопровождение в виде первичном, ограниченном по функциональности, продолжает развиваться и эволюционировать – начиная с коррекции анализа требований и проектных спецификаций. То есть происходит повторное проектирование и, по сути, повтор всего ЖЦ. Жизненный цикл нужно понимать как процесс или смену фаз, которая происходит во времени последовательно. Фазы, естественно, взаимосвязаны. Важная взаимосвязь между фазами определяется проектной документацией и документацией по программному продукту.
Если говорить о процессе разработки информационной системы, в том числе и корпоративной, то, по сути, в широком смысле речь идет о полном жизненном цикле. В разработке корпоративных информационных систем предполагается, что речь идет о жизненном цикле от начала до завершения в широком смысле. Однако если говорить более узко, то можно рассматривать лишь ту часть жизненного цикла, которая связана с кодированием и программированием, но в случае корпоративных систем это является слишком ограниченным подходом. Какие стадии связаны непосредственно с кодированием или программированием? Это проектирование системы, когда речь уже идет о построении скелета реализации, некоего наброска основы разрабатываемой программной системы, т. е., по сути, речь идет уже о работе с 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 в своей совокупности представляют уже несколько петабайт, т. е. крайне большой объем информации. В этой связи корпоративные информационные системы представляют собой достаточно сложный объект для исследования. Такие системы достаточно быстро растут: за пять лет объемы данных примерно удваиваются. То есть можно говорить о быстром росте объемов данных, в этой связи еще сложнее становится управлять такими большими программными комплексами.
Это только некоторые аспекты. Вообще разработка информационных систем – это многоаспектный процесс. В течение разработки информационная система проходит целый ряд стадий, связанных с так называемым жизненным циклом. Это и анализ и спецификация требований, и проектирование – первичное и детальное, и реализация, тестирование, интеграция, передача заказчику в эксплуатацию, сопровождение. То есть это достаточно сложный процесс последовательно сменяющих друг друга стадий. Тем не менее этот процесс является замкнутым и итерационным: ряд стадий при отдельных подходах, скажем, при спиральной, эволюционной, инкрементной моделях, последовательно повторяется. Конечно, для того чтобы говорить о корпоративных системах, нужно достаточно детально и полно представлять себе все этапы этого жизненного цикла, взаимодействие этих этапов и ту документацию, которая производится на каждом этапе и является во многом основой такого (в том числе документального) взаимодействия. При каскадном подходе нельзя перейти к следующему этапу, если предыдущий этап документально не закрыт и на соответствующем документе, который подтверждает корректность и финализацию этого этапа, не появляется подпись ответственного лица. В этой связи нужно представлять себе всю схему ЖЦ, для того чтобы корректно выбрать модели, методы и средства, которые включают в себя те методологии проектирования КИС, о которых мы будем говорить дальше.
Остановися подробнее на жизненном цикле ПО (ЖЦ ПО). В начале главы уже были упомянуты его основные этапы. Фазы, которые связаны с разработкой программных систем, включают: анализ и спецификацию требований к программному продукту, проектирование программного продукта – первичное и детальное, уточненное, реализацию и тестирование элементов или модулей отдельного программного продукта, интеграцию или сборку этих модулей в частичный или полный программный продукт вместе с интеграционным тестированием, передачу заказчику после приемочных тестов, промышленную или опытную эксплуатацию, которая называется сопровождением и занимает по времени и средствам основную часть жизненного цикла, и, наконец, вывод из эксплуатации. Для реализации этого жизненного цикла применяются различные модели, методы и инструментальные средства. Подробнее рассмотрим основные этапы ЖЦ.
Прежде всего определим, что такое ЖЦ и в чем состоят его особенности для систем корпоративного типа. Ведь речь идет о действительно больших системах, которые включают терабайты данных разных степеней структурированности, географически распределены по земному шару и между которыми нужно наладить взаимодействие для получения консолидированной отчетной информации по основным видам корпоративных ресурсов. Будут рассмотрены основные этапы ЖЦ: анализ и спецификация требований, эскизное и детальное проектирование, реализация и тестирование, сопровождение и вывод из эксплуатации – и экономическая специфика этапов ЖЦ ПО. При этом будет упомянуто не только о стоимости затрат, но и об их структуре, на основе анализа большого количества проектов, который был произведен в частности компанией HP и другими компаниями, здесь будут приведены оценки, сделанные Карнеги-Мелонским университетом. И, что очень важно, будет рассмотрена связь этапов ЖЦ с различными моделями.
Модели, методы и инструментальные средства – это, так сказать, три кита, три основных составляющих, на которых стоит все проектирование, разработка корпоративных, в том числе информационных, систем. Эффективная разработка немыслима без использования средств автоматизированного проектирования, или CASE-средств. При описании производства как промышленного процесса необходимо упомянуть о тех метриках, которые позволяют определить и ограничить программный продукт и приходить к определенным выводам на основании анализа этих метрик. Это позволит ответить на вопросы: следует ли уже прекратить сборочное тестирование и начинать тестирование продукта, достаточно ли качественным является этот продукт, не превосходит ли существующее количество ошибок некое пороговое значение.
Как оценить сложность ПО? Достаточно ли, скажем, для этого ограничиться количеством строк кода? Или существуют другие метрики оценки? Например, количество операторов, операндов и т. д. Как пользоваться этими метриками и насколько они эффективны? Ведь процесс производства ПО должен быть конвейерным, таким, чтобы методологии и модели работали для большого количества программных продуктов и проектирование проводилось по единообразной схеме.
Итак, в чем заключается жизненный цикл программного обеспечения, какие имеются у него составляющие, в чем состоит его экономика, инструментарий и метрики.
В разработке ПО существуют определенные сложности и проблемы, которые нужно решать со стороны как разработчика, так и системного архитектора и даже руководителя программного проекта. Необходимо достичь определенного уровня качества, которое связано с теми метриками, о которых уже было сказано: порог ошибок, интерфейс пользователя, эргономичность, масштабируемость, количество одновременных пользователей, количество транзакций, время реакции системы и объем БД. Программный продукт должен удовлетворять этим метрикам при определенном дефиците ресурсов, имеющем место в любом проекте и который в любом случае достаточно жестко контролируется в ходе программных проектов. Это возрастающая сложность программных систем. Корпоративные системы – это десятки взаимодействующих систем, каждая из которых объединяет зачастую сотни первичных сущностей и часто терабайты данных, т. е. это очень сложные программные системы, которые достаточно быстро растут и которым необходимо взаимодействовать друг с другом.
В ходе выполнения программных проектов приходится часто сталкиваться с нехваткой ресурсов: людских, временных, финансовых. Происходит постоянное взаимодействие с заказчиком, который часто изменяет требования, и в ряде случаев, эти изменения могут носить для разработчика достаточно сложный и плохо предсказуемый характер, иногда эволюционный, иногда революционный. При этом необходимо, в зависимости от пути или степени изменения этих сложностей и требований, корректировать модели ЖЦ и, соответствующим образом, очередность стадий ЖЦ программных продуктов.
Еще один важный аспект – это проектная команда, взаимодействие большого количества участников. Под участниками в ряде случаев понимаются представители не только разработчика, но и заказчика, которые входят в состав software quality assurance – группы контроля качества продукта. Если даже исключить их из рассмотрения, а в ряде методологий, в особенности гибких (Agile, X P, Scrum), эти представители присутствуют и играют достаточно активную роль, то в любом случае на стороне разработчика есть целая проектная команда (может быть не одна), работу которой нужно координировать. В больших программных системах это большой объем человеко-часов и большое количество исполнителей с разными мотивациями, целями и задачами. В этом смысле, при большом количестве участников, необходимо управлять процессом, привлекая к этому CASE-средства (автоматизированного проектирования) – это тоже достаточно сложно. При этом важной проблемой является моральное устаревание программного обеспечения.
В следующих главах будет подробнее изложено о понятии Software Engineering (программная инженерия), которое возникло в конце 1960-х гг. на конференции NATO, когда обсуждалась аналогия между любым процессом промышленного производства (в частности, строительством мостов) и строительством программного обеспечения, программной архитектурой. Вообще достаточно часто в литературе, связанной с ПО, возникают аналогии между архитектурным строительством сооружений, зданий, мостов и программными проектами. В отношении Software Engineering – тут не все так просто. Ряд методов, которые работают в первом случае, не подходят для программной инженерии. Программное обеспечение морально устаревает – и это происходит достаточно быстро. Посмотрим, например, на скорость смены ОС Windows – это происходит примерно раз в 5 лет, может и чаще. В то же время многие дома и мосты морально не устаревают гораздо дольше, в течение сотен лет. Таким образом, проблемы разработки ПО во многом более динамичны, чем проблемы целого ряда отраслей реального сектора экономики. Кроме того, разработка ПО растет высокими темпами. Для ряда компаний это направление является единственным, основным, определяющим. Необходимо успеть до того, как выйдут на рынок продукты конкурентов, опередить их и обеспечить высокое качество продукции, совместив его с достаточно быстрым вводом в эксплуатацию. Кроме того, это очень большое количество новых отраслей народного хозяйства. Достаточно сказать о такой новой отрасли, как нанотехнологии – это очень быстрая, конкурентная отрасль, которая затрагивает целый ряд промышленных технологий и направлений, требует оперативного знакомства предметных экспертов и системных аналитиков с совершенно новыми понятиями. Таким образом, получается достаточно большое количество взаимосвязанных и взаимодополняющих проблем, которые существенно осложняют разработку ПО, особенно в корпоративных системах.
Графическое представление ограничений на разработку приложений можно описать следующим образом. Это некоторая модификация традиционного проектного треугольника, который связан с затратами времени, средств и функционала. Приблизительно можно увидеть это как три оси. Где-то внутри этого треугольника находится оптимальное сочетание этих параметров, которое и удается обеспечить при адекватном сочетании моделей, методов и средств проектирования корпоративных информационных систем и программных приложений в целом.
Какие ограничения можно увидеть при разработке приложений, в том числе корпоративных? На процессы разработки воздействует целый ряд факторов. Это, конечно, объем кода, который можно измерить в тысячах строк. Корпоративные продукты – это десятки, сотни тысяч строк и более, в зависимости от характера и масштаба этих систем. Это, конечно, очень большая сложность. Каждый отдельно взятый модуль таких систем, как, например, Oracle Applications, представляет собой несколько сотен первичных сущностей. Для того чтобы охватить их взглядом, требуется очень серьезная фундаментальная предметная подготовка, аналитический взгляд, профессионализм и использование специализированных средств автоматизированного проектирования. Кроме того, существует целый ряд ограничений, которые связаны с людскими ресурсами. Естественно, человеку охватить такое количество сущностей и грамотно строить процессы проектирования, разработки, которые включают и тестирование, постановку задачи, анализ и спецификацию требований, естественно, очень сложно. Эти процессы нужно грамотно координировать, чтобы команда давала отдачу от того, что используется такой большой коллектив, и не появлялись чрезмерные затраты на обучение все новых и новых членов команды по мере того, как проект расширяется и в него вовлекаются новые силы и средства.
Кроме того, обучение тормозит процессы разработки. Нужно понимать, что в разработке новой системы в рамках существующего корпоративного программного комплекса заказчик зачастую не может остановить свои ключевые бизнес-процессы. И пусть ценой дополнительных затрат унаследованные системы, работающие на мейнфреймах или устаревших архитектурах, все же обеспечивают поддержку этих бизнес-процессов. И при интеграции новых систем в существующую программную среду заказчика необходимо обеспечить корректность и адекватность этой интеграции и функционирование расширенного комплекса новой системой. Это нужно сделать для того, чтобы этот новый комплекс позволял извлечь больше информации, консолидировать данные и в итоге давал возможность руководству получить аналог приборной панели, на которой оно сможет видеть результаты, достигнутые компанией по финансам, по кадрам, по материальным и производственным ресурсам. Результаты можно будет представить в виде срезов, проекций с детализацией до отдельных стран, компаний, подразделений и сотрудников, и это позволит плавно масштабировать и анализировать эти результаты, строить тренды, прогнозы перспектив развития.
Целями разработки являются снижение или оптимизация ресурсов – многофакторная оптимизация, которая связана с людскими ресурсами, оптимизацией стоимости и длительности времени графика, плюс функциональные ограничения – ограничения на ту функциональность, которую необходимо и желательно реализовать в рамках программного проекта.
В чем состоит современный подход к решению всех этих проблем? Проблемы, связанные с важностью, высокотехнологичностью и ограничениями, которые диктует рынок: конкурентная среда, время, которое жестко ограничивает регламенты проектирования корпоративных систем, и ряд других проблем, которые усугубляются корпоративным характером информационных систем, сложностью и большим объемом приложений. Конечно, можно прибегнуть к методам анализа и систематизации тех знаний, которые уже существуют, и которые были получены имперически при разработке первых подобных проектов, подобного класса и масштаба. И здесь на помощь приходит программная инженерия, то есть целый ряд дисциплин, которые связаны с процессами управления проектированием программных систем, построением архитектурных основ такого рода информационных систем и, конечно, разработки, проектированию и реализации, включая тестирование и сопровождение, то есть управление ЖЦ такого рода программных систем и их комплексов.
