Основы проектирования корпоративных систем. Раздел I. Модели, методологии и архитектуры разработки корпоративных систем (С. В. Зыков, 2012)

В представленной монографии описана разработка корпоративных информационных систем, даны понятия информационных систем вообще и корпоративных в частности, а также то, для чего, собственно, нам необходимы эти знания и как их применять непосредственно в разработке.

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

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

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

Цель курса – формирование целостной концепции проектирования и реализации, иными словами, разработки, корпоративных приложений в современных условиях. Будет применяться подход Карнеги-Мелонского университета к дисциплине «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, нельзя назвать корпоративными. Они не приводят к решениям корпоративного типа[1].

Таким образом, существует целая иерархия подходов к разработке систем. При этом то, что называется моделями ЖЦ (каскадная, спиральная модель) и методологии (такие как 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, представляет собой несколько сотен первичных сущностей. Для того чтобы охватить их взглядом, требуется очень серьезная фундаментальная предметная подготовка, аналитический взгляд, профессионализм и использование специализированных средств автоматизированного проектирования. Кроме того, существует целый ряд ограничений, которые связаны с людскими ресурсами. Естественно, человеку охватить такое количество сущностей и грамотно строить процессы проектирования, разработки, которые включают и тестирование, постановку задачи, анализ и спецификацию требований, естественно, очень сложно. Эти процессы нужно грамотно координировать, чтобы команда давала отдачу от того, что используется такой большой коллектив, и не появлялись чрезмерные затраты на обучение все новых и новых членов команды по мере того, как проект расширяется и в него вовлекаются новые силы и средства.

Кроме того, обучение тормозит процессы разработки. Нужно понимать, что в разработке новой системы в рамках существующего корпоративного программного комплекса заказчик зачастую не может остановить свои ключевые бизнес-процессы. И пусть ценой дополнительных затрат унаследованные системы, работающие на мейнфреймах или устаревших архитектурах, все же обеспечивают поддержку этих бизнес-процессов. И при интеграции новых систем в существующую программную среду заказчика необходимо обеспечить корректность и адекватность этой интеграции и функционирование расширенного комплекса новой системой. Это нужно сделать для того, чтобы этот новый комплекс позволял извлечь больше информации, консолидировать данные и в итоге давал возможность руководству получить аналог приборной панели, на которой оно сможет видеть результаты, достигнутые компанией по финансам, по кадрам, по материальным и производственным ресурсам. Результаты можно будет представить в виде срезов, проекций с детализацией до отдельных стран, компаний, подразделений и сотрудников, и это позволит плавно масштабировать и анализировать эти результаты, строить тренды, прогнозы перспектив развития.

Целями разработки являются снижение или оптимизация ресурсов – многофакторная оптимизация, которая связана с людскими ресурсами, оптимизацией стоимости и длительности времени графика, плюс функциональные ограничения – ограничения на ту функциональность, которую необходимо и желательно реализовать в рамках программного проекта.

В чем состоит современный подход к решению всех этих проблем? Проблемы, связанные с важностью, высокотехнологичностью и ограничениями, которые диктует рынок: конкурентная среда, время, которое жестко ограничивает регламенты проектирования корпоративных систем, и ряд других проблем, которые усугубляются корпоративным характером информационных систем, сложностью и большим объемом приложений. Конечно, можно прибегнуть к методам анализа и систематизации тех знаний, которые уже существуют, и которые были получены имперически при разработке первых подобных проектов, подобного класса и масштаба. И здесь на помощь приходит программная инженерия, то есть целый ряд дисциплин, которые связаны с процессами управления проектированием программных систем, построением архитектурных основ такого рода информационных систем и, конечно, разработки, проектированию и реализации, включая тестирование и сопровождение, то есть управление ЖЦ такого рода программных систем и их комплексов.

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

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

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

Процитируем В.А. Липаева – патриарха отечественной программной инженерии. В книге «Программная инженерия» он привел следующее определение: «Под программной инженерией понимается комплекс задач, методов, средств и технологий создания, то есть проектирования и реализации сложных, расширяемых, тиражируемых, высококачественных программных систем, возможно включающих базы данных»[2]. Каждое слово в этом определении в полной мере применимо к корпоративным системам.

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

Некоторые из примеров таких решений – Microsoft Dynamics, Oracle Applications и т. д. Под высоким качеством понимается и масштабируемость – плавное снижение производительности при достаточно резком увеличении интенсивности нагрузки на систему. Кроме того, нужно сказать, что эти системы должны быть надежными, вести себя предсказуемо, быть эргономичными, сопровождаемыми, т. е. должны быть настроены на то, чтобы обеспечивать достаточно гибкое и относительно эволюционное взаимодействие с пользователем на этапе опытной и промышленной эксплуатации. В определении также речь идет о проектировании и реализации, т. е. уже о полном жизненном цикле ПО. Важным дополнением является то, что информационные системы включают в ряде случаев базы данных. Если мы говорим о корпоративных системах, базы данных, как правило, являются неотъемлемой, важной частью этих систем. Другое дело, что эти базы данных могут строиться на различных принципах, являться гетерогенными, включать объектные составляющие, т. е. быть не чисто реляционными. Последние версии СУБД Oracle называются объектно-реляционными. Есть СУБД нового поколения, такие как O2, Orion и др., которые используют не только реляционные, но и другие, более новые объектно-ориентированные модели.

В корпоративных информационных системах необходимо разделять понятия программного проекта и программного продукта. В настоящем издании речь пойдет в основном о программных продуктах, т. е. о взгляде на ЖЦ с точки зрения системного архитектора. А с точки зрения программного проекта – это взгляд менеджера проектов, когда речь идет об управлении проектной командой, проектами, взаимодействием людей в проекте, сроками, стоимостью. С другой стороны, если говорить о программной инженерии, то речь может идти о разработке продукта для конкретного заказчика, но преимущественно и предпочтительно планировать все процессы и технологии, связанные с разработкой таким образом, чтобы по возможности обеспечить производство продукта, нацеленного на более широкую аудиторию потребителей, а в идеале сделать его коробочным или тиражируемым. Целесообразно обеспечить высокий процент повторного многократного использования элементов проекта – это и код, и документация, и структура СУБД, и программная архитектура, с тем чтобы при доработке проекта для «похожего» заказчика было затрачено минимум времени, средств и людских ресурсов.

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

Чем характеризуется программный продукт? Во-первых, как правило, он имеет определенную коммерческую ценность. Это значит не то, что не существует условно бесплатных программных продуктов, а что этот продукт решает конкретную задачу конкретного класса пользователей, потребителей продукта. Таким образом, продукт может называться рыночным и быть предложен рынку для удовлетворения его определенных потребностей и решения конкретных бизнес-задач. Какие примеры программного продукта можно привести? Часто это физические объекты, скажем, информационные носители (DVD, CD и т. д.), но это могут быть и нематериальные соглашения, такие как лицензия, соглашение о партнерстве и пр. Еще одним примером может выступать услуга по внедрению, сопровождению, консалтингу и т. д.

Программные продукты можно классифицировать по разным основаниям. Один из видов классификации – масштаб использования: это и личное использование, и некоммерческое, и коммерческое как коробочный продукт для широкого класса организаций и предприятий. Другой способ классификации – цель использования. Это может быть специализированное ПО, нацеленное на решение достаточно узкой задачи, например расчетное ПО для решения астрономических задач, лазерной дальнометрии, или ПО более общего назначения, такое как операционная система, офисные продукты и т. п. Еще один вид классификации – степень открытости. При этом можно говорить о компонентной ориентированности, скажем, API, библиотеки, такие как, например, библиотека классов Enterprise Libraries, которая используется для надстройки над. NET для построения Microsoft-продуктов корпоративного типа, библиотека классов для построения офисных приложений и т. д. или готовые продукты.

Любая разработка ПО происходит согласно жизненному циклу и включает последовательное прохождение стадий ЖЦ, о которых мы уже упоминали и которые в широком смысле начинаются с концепции или базовой идеи и заканчиваются выводом из эксплуатации.

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

Каждый этап ЖЦ завершается разработкой некоторой части системы – она может быть полнофункциональной или не совсем полнофункциональной. Это зависит от конкретной модели ЖЦ. Каждый этап завершается производством документации, которая включает более глобальные артефакты, такие как план проекта, план тестирования, план реализации, план сопровождения, или более узкие документы, такие как сценарии использования, руководство администратора, краткое руководство пользователя, основные требования к проекту или более детальные требования в форме технического задания. Объем, характер и масштаб документации зависят от характера и масштаба программного продукта. Конечно, для каждого этапа производства ПО должны быть четко определены начальные и конечные временные точки, а также известны элементы, которые должны быть переданы следующему этапу, с точки зрения кода, документации, базы знаний. На практике все обстоит сложнее, но в любом случае, если мы говорим о технологии проектирования ПО, то каждый этап ЖЦ с определенностью завершается производством некоторого нового продукта и новой документации к нему.

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

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

У этих разных сторон зачастую совершенно различные цели и ожидания от продукта, от того, какую функциональность он должен реализовывать, и от проектных ограничений и по срокам, и по стоимости, и по функциональности и даже различное понимание определенных терминов и особенностей. Ведь заказчик смотрит на процесс производства ПО, достаточно хорошо понимая свои производственные потребности, но он может не вполне владеть особенностями производства ПО, которые приняты у разработчиков. И в этой связи даже разумные взгляды, подходы и отношения к ЖЦ, к тем требованиям и ограничениям, которые имеются у заказчика и разработчика и различных представителей заказчика и разработчика на различных уровнях, могут приводить к значительному увеличению сроков и стоимости проекта. Большое значение имеет согласование этих подходов между разработчиком и заказчиком: нужно прийти к некоему общему пониманию, прежде всего ограничений проекта. И надо помнить, что заказчик тут стремится ограничить проект снизу, заявить о том, что количество пользователей не может быть меньше, чем некое число, и т. д. А разработчик должен прийти к соглашению с заказчиком (к юридическому документу, техническому заданию, списку-требованию или какому-то иному документу). Разработчик при этом стремится ограничить проект сверху (количество пользователей, пропускная способность), т. е. показать, что технологии, которые используются, и бюджет, который заложен в проект, не могут обеспечить производительность более установленного предела.

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

Какой же целью задаются разработчики? Главная цель – это создать хороший продукт. (Что такое «хороший», будет расшифрованно далее, а также какие именно факторы разработки ПО должны в первую очередь приниматься во внимание.)

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

Нужно сказать, что продукт и проект – это различные понятия и, вообще говоря, те стадии, которые учитывают ЖЦ продукта несколько шире и включают в себя оценку возможности создания этого проекта и концептуальную основу проекта, идею, с которой он начинается. ЖЦ проекта во многом завершается при передаче в эксплуатацию каждого конкретного релиза этого продукта. ЖЦ продукта включает и сопровождение, и эксплуатацию, и вывод из эксплуатации.

Если говорить подробнее об экономике ЖЦ программного продукта, то нужно сказать, что он проходит целый ряд стадий и эти стадии вносят различный вклад в прибыль и динамику продаж. И если на стадии создания и вывода на рынок проект преимущественно находится в минусе по прибылям, то после вывода на рынок, когда наблюдается рост и зрелость, прибыль становится положительной. В период зрелости, как правило, прибыль имеет отрицательный прирост, но положительное значение. В районе упадка наблюдается уже существенное падение и невысокое значение как прибыли, так и продаж с точки зрения их динамики. Все это характерно как для коробочного продукта, когда речь идет о количестве инсталляций, так и в случае, когда взаимодействие осуществляется с конкретным заказчиком, с учетом всех классов пользователей продукта.

Можно рассмотреть более подробно экономику ЖЦ на основе сопоставления критериев развития, скорости роста бизнеса и доли рынка, которую занимает программный продукт. Здесь, в начале пути, нужны инвестиции, поскольку неизвестно о дальнейшей судьбе программного продукта. Затем программный продукт выходит на рынок, приносит доход и, наконец, прибыль, и это без существенных затрат на поддержку продаж. Через некоторое время наступает этап, когда доходы относительно невысоки и продажи влекут за собой существенные затраты.

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

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

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

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

Следующая стадия – подготовка проектных спецификаций. Она происходит на основе описания требований, т. е. тех документов, которые получены на предыдущей стадии ЖЦ. Эта и следующие стадии являются в основном прерогативой разработчика. Хотя в ряде методологий проектирования и реализаций программных комплексов, таких гибких, как Agile, X P, Scrum, заказчик участвует на всех этапах ЖЦ ПО. Для больших корпоративных систем, как правило, разработка ведется по методологиям RUP или MSF, и там основным действующим лицом является разработчик. Проектные спецификации содержат описания всей функциональности проекта и всех основных ограничений, желательно выраженных количественно. Здесь уже можно ограничить и программное обеспечение, и технологии, которые будут использованы, и архитектуру (например, сделать выбор между платформами Java или. NET). Необходимо четко ограничить количество одновременных пользователей, количество подключений, транзакций и их интенсивность, пропускную способность канала и ряд других параметров. При этом методологию или модель разработки ПО – каскадную, эволюционную, спиральную или иную – следует выбрать как можно раньше, поскольку выбор методологии или модели ЖЦ определяющим образом сказывается на сроках, стоимости и успехах проекта. Проектные спецификации должны ограничивать сроки и стоимость проекта исходя из договоренностей, которые достигли разработчик и заказчик на предыдущем этапе.

Далее на основе проектных спецификаций производится детальное проектирование, которое описывает программную архитектуру с учетом всех компонентов проекта. В случае объектно-ориентированного подхода это модули и интерфейсы между ними, компоненты и средства их взаимодействия в условиях той программной среды, которой располагает заказчик. Однако в больших корпоративных системах всегда присутствует некоторое количество взаимодействующих систем, которые уже работают у заказчика, и, как правило, разработчики приходят к заказчику с предложениями, которые учитывают эти условия программной и аппаратной среды. У заказчика может быть множество серверов, например серверы баз данных, кэш-серверы, серверы безопасности, серверы, отвечающие за телекоммуникации, и пр. Детальное проектирование также выполняется разработчиком. Кроме написания программной архитектуры, детальное проектирование на выходе дает документы, которые описывают все программные модули корпоративного комплекса.

После детального проектирования и ревизии проекта, т. е. проверки спецификаций на внутреннюю корректность, полноту, непротиворечивость, целостность и на соответствие техническому заданию, можно переходить к реализации, т. е. созданию кода программного продукта и соответствующей документации.

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

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

В первый раз ПО разворачивается у заказчика на его реальном программном и аппаратном окружении и реальных данных в тех объемах, которые определяются условиями эксплуатации корпоративных программных комплексов заказчика. Если все приемочные тесты, которые производятся заказчиком, успешны, т. е. продукт ведет себя надежно, корректно, соответствует функциональным требованиям, вписывается в программно-аппаратное обеспечение заказчика, то происходит передача программного продукта вместе с документацией заказчику и наступает фаза эксплуатации. Эта фаза относительно ЖЦ называется фазой сопровождения.

С точки зрения экономики сопровождение – самый затратный этап ЖЦ (порядка ²/₃ стоимости всего проекта) как по времени, так и по средствам. Нужно понимать, что сопровождение необходимо для любого ПО. Цель при разработке – не просто передача программного продукта заказчику, а продолжение продуктивных отношений с этим заказчиком. Задачами сопровождения программного продукта являются ликвидация ошибок, которые остались в программном продукте, коррекция проектных спецификаций, улучшение производительности и учет особенностей новой программной и аппаратной среды заказчика, если таковые имеются. Сопровождение включает следующие виды:

• корректирующее сопровождение (устранение существующих в продукте ошибок без изменения проектных спецификаций);

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

• адаптивное сопровождение (адаптация продукта к новой программно-аппаратной среде).

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

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

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

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

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

И еще один вид сопровождения связан с миграцией существующего программного окружения в новую среду. Под программным окружением мы понимаем все множество информационных систем, имеющееся у заказчика, которое как раз и перемещается (например, под управлением новой ОС, нового сервера БД и т. д.). Здесь речь идет уже о том, что необходимо обеспечить интеграцию существующих программных продуктов у заказчика с теми новыми возможностями, которые дают новые программные или аппаратные системы, на которые переходит заказчик. Следует разрабатывать программные продукты таким образом, чтобы они были сопровождаемыми. Сопровождение – это необходимый этап ЖЦ любого проекта, каким бы малым он ни был и какие бы ни были отношения с заказчиком. Почему сопровождение так важно? Во-первых, оно позволяет выстроить продуктивные, долговременные отношения с заказчиком, поскольку именно этот этап, ради которого собственно и создается ПО, этап промышленной эксплуатации, как правило, является достаточно продолжительно (обычно несколько лет). Именно на этом этапе взаимодействие с заказчиком приносит дополнительные доходы за счет всех вышеописанных вариантов сопровождения. Вторым важным аспектом является то, что сопровождение дает возможность перейти к программному продукту, который можно использовать повторно. То есть тот программный продукт, который делался для конкретного заказчика, наверняка, если он хорошо сопровождается, может быть после небольших доработок предложен другому заказчику. Чем правильнее проходит этап сопровождения, тем больше вероятность того, что выпущенный продукт будет устраивать большое количество заказчиков, а в перспективе может быть реализован как коробочный продукт. В этой связи даже для небольших продуктов сопровождение важно. Следующей стадией является вывод из эксплуатации. Это не самая интересная, может быть, не самая радостная стадия, поскольку ПО верой и правдой служило заказчику достаточно долгое время, к нему уже привыкли, сложились внутренние регламенты, существуют документы, процедуры, пользователям понятно это ПО, они уже достаточно хорошо в нем ориентируются. Но в ряде случаев приходится заказчику сделать вывод о том, что снятие с эксплуатации необходимо. Почему это может быть так? Потому что ПО, в отличие, например, от архитектурных сооружений, морально устаревает достаточно быстро, так как стремительно меняются программные и аппаратные платформы, и в ряде случаев заказчику становится уже невыгодно осуществлять дорогостоящее сопровождение того решения, которое было разработано. Приходится переходить на новое ПО, поддерживающее совершенно новую функциональность, реализация которой слишком дорогостоящая для текущей эксплуатируемой версии. При этом если ряд функций ПО и данные являются еще необходимыми, то важно при миграции обеспечить экспорт данных в новое приложение. Этот процесс непрямолинейный и непростой. Но крайне нежелательно, особенно на уровне КИС с большим количеством важных данных и важностью динамики этих данных, терять эти данные и параметры. Вывод из эксплуатации возможен только на основе взвешенного решения, которое включает оценку стоимости. Стоимость замены ПО включает целый ряд факторов: стоимость смены технологий (стоимость нового ПО, стоимость лицензий), стоимость разработки и поддержки приложений на основе нового ПО, затраты на обучение персонала, потеря производительности труда персонала в переходный период, поскольку с новым ПО всегда достаточно сложно работать. В ряде случаев вывод из эксплуатации осуществляется вынужденно (например, при обнаружении существенной несовместимости).

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

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

Существует классический подход к разработке ПО на основе структурного анализа и проектирования (structural analysis and development), которое не учитывает ряд аспектов, в частности, в ряде случаев специфику компонентов или модулей кода и выбор языка программирования сложно осуществить до завершения проектных спецификаций (при объектном подходе, например, это можно сделать). Неструктурные аспекты, динамические аспекты проектирования здесь тоже не учитываются. Кроме того, достаточно сложно осуществить столь масштабное повторное использование кода, как это делается в объектно-ориентированной модели и в подходе, связанном с объектно-ориентированным анализом и проектированием. Нужно сказать, что повторное использование кода – это, пожалуй, важнейшая цель организации ЖЦ ПО. Проблема здесь в том, что ножницы между возможным повторным использованием не только кода, но и других артефактов проекта (документация) составляют до половины стоимости проекта. На этом можно существенно экономить во времени, средствах и людских ресурсах. Но это довольно сложно сделать, так как повторное использование требует хорошей дисциплины проекта, грамотного использования специфических средств. Мы должны к этому стремиться, ряд моделей ЖЦ учитывает это в достаточно большой степени. Кроме того, нужно понимать, что границы фаз ЖЦ могут изменяться и даже перекрываться, в том числе динамически по мере изменения требований в зависимости от модели ЖЦ (например, это имеет место в объектно-ориентированной модели).

В связи с тем что ЖЦ продукта проходит ряд стадий, очевидна необходимость проводить вывод из эксплуатации и переходить к новой версии.

Достаточно интересным является взгляд на вклад различных фаз ЖЦ программных проектов в сроки и стоимость. Анализ произведен на основе целого ряда проектов (порядка 1000), которые велись компанией HP и др. Очевидно, что сопровождение составляет львиную долю стоимости и сроков проекта. При этом такие стадии, как кодирование, даже вместе с тестированием, и анализ требований, даже вместе с изготовлением спецификаций, занимают относительно небольшую долю стоимости. Можно сделать ряд интересных выводов на основе анализа этой динамики. Основные затраты выделяются на сопровождение. Особенно это важно для корпоративных проектов, которые являются долгосрочными и включают большое количество компонентов, которые нужно объединять, интегрировать и поддерживать совместно, что вызывает дополнительные сложности. Кроме того, программные средства, которые увеличивают расширяемость применения ПО, более эффективны, чем все попытки рефакторинга улучшения кода. Еще один интересный вывод состоит в том, что фазы перед кодированием и после него составляют порядка 30 % затрат, а собственно кодирование при этом составляет всего 5 %. То есть то, что называется программированием, для больших проектов отнюдь не является затратной частью. Обрамляющие стадии (тестирование и коррекция спецификаций) обеспечивают существенное улучшение качества ПО и его соответствие требованиям. Нужно сказать, что правильная постановка обрамляющих стадий очень важна и ускоряет кодирование.

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

Каждая фаза ЖЦ ПО включает три важных составляющих – процессы, методы и средства. Под процессами понимают задачи, которые необходимо реализовать, они отличаются и, по сути, не зависят друг от друга. Методы – это относительно формальное описание каждой задачи процесса. Средства – автоматический инструментарий типа CASE-средств для поддержки процессов и методов.

Ниже перечислены основные виды моделей ЖЦ, которые будут подробнее рассмотрены в следующих главах: это прежде всего модель Build-and-fix – «кодируй и фиксируй», по сути, она близка к модели проб и ошибок; затем – водопадная модель, которая дает возможность за один проход ЖЦ построить полномасштабное программное обеспечение; модель быстрого прототипирования, которая, как правило, объединяется с другими моделями; инкрементальная модель с последовательным наращиванием функциональности; модель синхронизации и стабилизации, или модель Microsoft; спиральная модель, в которой очень важна оценка рисков и которая тоже подразумевает циклическую обработку продукта по мере его движения к пользователю; объектно-ориентированная модель с перекрытием ряда фаз и во многом циклическим или итерационным развитием.

Какие общие черты можно выделить в перечисленных моделях ЖЦ? Как правило, они включают все его стадии, за исключением модели Build-and-fix. Кроме того, предполагается несколько итераций по разработке продукта, за исключением каскадной модели. Как правило, стадии ЖЦ четко различимы, кроме объектно-ориентированной модели, где они могут объединяться. Некоторые отдельные модели, связанные с некоторыми методологиями проектирования, такие как модель синхронизации и стабилизации, связаны с методологией MSF. RUP поддерживает каскадные и спиральные сценарии жизненного цикла и т. д.

Грамотное применение модели ЖЦ требует высокой организационной зрелости команды и серьезной дисциплины проекта с точки зрения стандартов документирования, кодирования, использования специализированных CASE-средств и т. д. Если такие знания недостаточны, то объектно-ориентированная модель может выродиться в такую модель, как Build-and-fix, т. е. можно потерять все преимущества модели и увеличить затраты.

Таким образом, универсальной модели ЖЦ не существует, все определяется характером и масштабом проекта. Каждая модель имеет свои преимущества и свои недостатки. Об этом мы поговорим подробнее в следующей главе.

Что определяют модели ЖЦ программных продуктов? Во-первых, характер и масштаб проекта. В этой связи, как только при анализе и спецификации требований и ограничений определены основные границы проекта и продукта, в идеале следует определиться с совокупностью моделей, которые будут выбраны. Здесь критичны объем продукта, сроки и проектные риски. Скажем, спиральная модель существенно связана с использованием рисков, поэтому ее имеет смысл применять в случаях, когда необходим анализ рисков. Модели определяют экономику проекта, в том числе и скорость возврата инвестиций. В случае если нет острой необходимости применять модель полного ЖЦ, можно сэкономить на отдельных стадиях, например если не нужно разрабатывать документацию в полном объеме. Модель определяет степень сопровождаемости: в ряде моделей мы можем получить продукт, который будет более сопровождаемым. Модели ЖЦ определяют также перспективы развития – насколько можно будет удовлетворить будущие запросы клиента. Также модели ЖЦ определяют общую структуру проекта с точки зрения его эволюционного или революционного совершенствования: потребуются ли радикальные изменения или можно ограничиться архитектурой, в которой проект будет стабильно эволюционировать. Модели определяют скорость поиска и устранения ошибок, например, модель синхронизации и стабилизации нацелена на частое раннее тестирование. Некоторые модели, как уже отмечалось, способствуют хорошему управлению рисками проекта. Кроме того, отдельные модели подразумевают изготовление прототипов (модель быстрого прототипирования, инкрементальная модель), другие требуют изготовления готового продукта сразу же.

Какие особенности ЖЦ можно выделить уже в первом приближении для конкретных моделей? Модель Build-and-fix – это модель неполного ЖЦ, которая пригодна для малых проектов (≈1000 строк) и абсолютно непригодна для больших и сложных проектов с большим потенциалом развития. Водопадная, или каскадная, модель обеспечивает хорошую обратную связь с ранними стадиями ЖЦ, поскольку завершается подготовкой документов, которые позволяют перейти к следующей стадии. Без этих документов, без корректного закрытия предыдущей стадии невозможно начало следующей. Быстрое прототипирование – несамостоятельная модель, не приводящая к созданию надежного кода. Инкрементальная модель всегда дает возможность получить на каждом этапе готовый продукт, пусть и неполнофункциональный. Модель синхронизации и стабилизации, или модель Microsoft, нацелена на раннее выявление ошибок. Спиральная модель подразумевает несколько итераций и нацелена на анализ рисков. Объектно-ориентированная модель – это итеративное проектирование с перекрытием фаз и наложением их друг на друга.

Уже говорилось о том, что цена поиска ошибок экспоненциально растет по мере продвижения к завершению, поэтому ошибки нужно обнаруживать как можно раньше. Для этого существуют специальные методы, которые содержатся на всех стадиях жизненного цикла и включают процессы, методы и средства.

Кратко остановимся на преимуществах и недостатках различных моделей ЖЦ.

Модель Build-and-fix хороша для небольших проектов, которые не требуют сопровождения, но абсолютно непригодна для корпоративных или вообще нетривиальных проектов объемом более 1000 строк.

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

Модель быстрого прототипирования вызывает соблазн повторного использования кода, который не является достаточно протестированным, хорошо задокументированным и который, вообще говоря, следует заново реализовать как ненадежный. Но эта модель позволяет выявить соответствие ПО требованиям клиента, т. е. обеспечить анализ требований и выявление наиболее важных для клиента.

Инкрементальная модель способствует хорошей сопровождаемости за счет того, что получается достаточно плавный путь перехода от одной версии к другой. Эта модель способствует раннему возврату инвестиций, но требует открытой архитектуры, которая поддерживает такое эволюционное совершенствование программного продукта, и может выродиться в модель Build-and-fix.

Модель синхронизации и стабилизации удовлетворяет будущим потребностям клиента и обеспечивает высокую интеграцию компонентов, но достаточно сложна, поскольку требует интенсивного тестирования. Поэтому она не получила широкого применения вне Microsoft.

Спиральная модель объединяет характеристики перечисленных выше моделей, но желательно использовать ее во внутренних проектах, поскольку она требует тщательного анализа рисков, и ряд допущений, связанных с рисками, может не быть передан внешнему разработчику.

Объектно-ориентированная модель требует дисциплины, может выродиться в модель проб и ошибок и обеспечивает итеративную разработку и параллелизм взаимодействия между фазами.

На что влияет выбор модели ЖЦ? На скорость разработки, время выхода проекта на рынок, качество и стоимость продукта, стратегию управления изменениями и рисками, отношения с заказчиком на стадии сопровождения.

Окончательные выводы, которые можно сделать по моделям ЖЦ: выбор модели определяет основные критические параметры проекта – это успех проекта в целом, архитектура проекта, его бюджет, в каких случаях можно сэкономить. Модель должна быть адекватна опыту проектной команды с точки зрения знаний предметной области и знания конкретных технологий, CASE-средств, документирования, подходов к документированию и т. д. Серьезные модели, такие как спиральная или объектно-ориентированная, требуют определенной дисциплины и зрелости. В противном случае они вырождаются в модель проб и ошибок. Универсальной модели не существует. Выбор модели определяется исключительно характером и масштабом проекта. Ряд моделей можно комбинировать. У каждой модели есть свои преимущества и недостатки, которые обнаруживаются и имеют смысл только в контексте проекта, с учетом его особенностей.

Еще несколько слов о том, что помогает в программной инженерии, в изготовлении корпоративных решений. Это CASE-средства и CASE-технологии. ПО имеют целый ряд аспектов. ПО в малом можно рассматривать как искусство программирования или разработку отдельных модулей, отдельных фрагментов кода. ПО в большом можно понимать как software engineering, это технологии программирования, обеспечение жизненного цикла ПО с теми этапами и теми моделями, о которых было сказано выше. И еще один аспект – это командная работа ПО в массе, поддержка коллективной разработки, что очень важно для корпоративных информационных систем, в разработке которых участвуют целые коллективы разработчиков и тратят массу времени на взаимодействие, интеграцию, совместную разработку, командную работу.

Одним из важных CASE-средств, которое мы будем рассматривать, является Visual Studio.NET от Microsoft. О нем мы будем говорить в дальнейшем. Существует большое количество других CASE-средств: линейка Rational, которая поддерживает RUP. CASE-средства помогают во всех трех аспектах – и узко при кодировании, и при оптимизации ЖЦ, и при командной работе.

CASE-средства в первом приближении делятся на CASE-средства верхнего уровня (front-end), т. е. соответствуют первичным стадиям ЖЦ, и нижнего уровня (back-end), соответствующие стадиям ЖЦ, начиная с реализации. Важно отметить, что существуют конвейерные средства, такие как линейка Rational, Microsoft Visual Studio.NET, которые представляют собой среды, т. е. наборы определенного инструментария или своего рода конвейеры для выполнения связанных операций компиляции, тестирования, интеграции, редактирования кода, изготовления проектной документации, диаграммирования и т. д.

CASE-технологии дают неоспоримое преимущество при изготовлении больших программных систем. Но при своем применении они требуют определенных условий, таких как организационная зрелость команды, знание стандартов (UML, XML), знание самого средства. Кроме того, CASE-средства применимы для больших проектов корпоративных систем. Для небольших проектов стоимость CASE-средств и обучения им неоправданно высока. В результате успешного применения CASE-средств можно получить существенный рост производительности труда разработчиков и, в результате, если мы говорим о проекте в целом, существенное снижение сроков и стоимости программного проекта.

Какие метрики ПО применяются при контроле за ЖЦ программного проекта? Для проекта в целом это сроки, стоимость и функциональность – так называемый проектный треугольник компромиссов. В ряде случаев имеет смысл проводить анализ cost-benefit, т. е. анализ тех преимуществ, которые получает заказчик в зависимости от тех или иных вложений. Таким образом, этот треугольник имеет смысл рассматривать во взаимосвязи его основных характеристик и параметров. Наконец, для конкретных стадий ЖЦ (скажем, тестирования и сопровождения) можно выделить специфические метрики. Вообще говоря, для каждого этапа они свои. В случае тестирования можно использовать такие метрики, как сложность отдельного модуля, количество строк (обычно это тысячи строк), количество различных операторов или операндов, которые используются в том или ином модуле или фрагменте кода, относительное количество ошибок, которые выявлены на 1000 строк кода. Для стадии сопровождения это отслеживание и исправление допущенных ранее ошибок, поскольку не все ошибки проекта могут быть выявлены непосредственно на стадии реализации и до передачи заказчику. Нужно анализировать общее количество сбоев, коммуникацию или взаимодействие по ним. Здесь работают такие метрики, как состояние сбоев и отчетов. Кроме того, выявление источника и определенное состояние дискуссии, результаты (удалось устранить этот сбой, насколько он серьезный), а также метрики предыдущих стадий. Важные выводы, которые можно сделать, сводятся к тому, что решение принимается менеджером проекта: стоит ли прекратить тестирование, передать в эксплуатацию или нет? И, как правило, простые метрики являются достаточным.

В данной главе более подробно изложен материал о моделях жизненного цикла, которые в той или иной мере применимы к корпоративным информационным системам.

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

Рис. 3.1. Модель Build-and-fx жизненного цикла ПО

Каскадная (водопадная) модель, представленная на рис. 3.2, является в полной мере применимой для корпоративных информационных систем, но имеет ряд ограничений. В частности, как и многие модели, которые применимы для КИС, она требует дисциплины и организованности, хорошего знания CASE-средств, так как нужно быстро и организованно создавать диаграммы, проводить сетевые совещания, конференции, достаточно быстро вести тестирование различными методами. Кроме того, нужно производить документацию в соответствии со стандартами, которые приняты по договоренности с заказчиком внутри компании как руководство к действию, как шаблоны для реализации документации, которая тоже является важной частью продукта. Продукт – это не только код, но и огромное количество документации, необходимое, чтобы обеспечить его грамотное и стабильное сопровождение. Документация тем более полезна для чтения чужого кода, поскольку персонал сопровождения как раз и работает с чужим кодом, ища в нем ошибки. Это будет рассмотрено более подробно далее, когда речь пойдет о стадии сопровождения. Пока следует отметить, что документация критически важна для каскадной модели, потому что, проверяя ее на адекватность и сопоставляя с ТЗ или другим вариантом требований к продукту, которые согласованы с заказчиком и утверждены как юридический документ, разработчики отчитываются по продукту и закрывают каждую стадию жизненного цикла.

Рис. 3.2. Каскадная модель жизненного цикла ПО

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

Естественно, большую систему сложно реализовать за один проход, хотя при правильной постановке задачи и хорошем подходе к документированию и проектированию это оказывается возможным, например, в проектах, которые реализуются по каскадной модели большей частью для госструктур, таких как министерства обороны (и в США, и в России). Другие модели жизненного цикла, о которых речь пойдет далее, предусматривают либо итерации с возвратным уточнением функциональности продукта, либо другой способ циклического прохождения по стадиям жизненного цикла. Эти модели в определенном смысле более легки с точки зрения дисциплины проекта и в ряде случаев не требуют полной функциональности, производства полного продукта с документацией в полном объеме на каждую стадию.

Рис. 3.3. V-модель жизненного цикла ПО на базе каскадной модели

Рис. 3.4. Быстрое прототипирование – модель жизненного цикла ПО

Рис. 3.5. «Зубья акула» – модель жизненного цикла ПО на базе модели быстрого прототипирования

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.6. Инкрементальная модель жизненного цикла ПО

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

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

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

Рис. 3.7. Эволюционная модель жизненного цикла ПО

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

1) определить цели – продукт, деловые цели, понять ограничения, предложить альтернативы;

2) оценить альтернативы – анализ риска, прототипирование;

3) разработать продукт – детальный проект, код, unit test, интеграция;

4) спланировать следующий цикл – оценка клиентом, планирование проектирования, поставка клиенту, внедрение.

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

Рис. 3.8. Спиральная модель жизненного цикла ПО

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

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

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

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

Достаточно интересным является понятие видения (концепции) продукта, с этого вообще и начинается разговор о нем. Сначала должна появиться некоторая неформальная идея того, чем этот продукт будет принципиально отличаться от существующих, какие преимущества он принесет при реализации. При этом в ходе работы по этой модели, как и всегда, производится последовательная детализация программного продукта, и, естественно, видение является наиболее абстрактным представлением о нем. До того как начать разрабатывать продукт на основе этого представления, пусть даже неформализованного, готовится более точный документ, который описывает проектные спецификации. После этого происходит формирование проектной команды, готовится график работ: какие виды деятельности какой из ролей будут реализованы, на какой стадии, сколько это займет времени, какие будут вехи, результаты на каждом этапе изготовления продукта. Нужно заметить, что очень часто при разработке продуктов Microsoft проектная команда набирается именно под данный проект. И люди, которые участвуют в проекте на различных ролях – разработчиков, проектировщиков, документаторов, тестировщиков, встречаются только в тот период, когда изготавливают продукт. После этого часто бывает, что далее продукт существует независимо от них. Поэтому еще раз хочется подчеркнуть важность программной документации для обеспечения преемственности продуктов внутри линейки продуктов. У Microsoft, например, это линейки ОС Windows, приложений MS Office и др.

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

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

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

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

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

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

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

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

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

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

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

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

Еще одна модель – наиболее интересная и динамичная – это объектно-ориентированная модель. Речь пойдет о той ее разновидности, которую называют фонтанной. Это название будет понятно, если посмотреть на схему взаимодействия фаз этой модели.

В чем ее особенности? Если все предыдущие модели содержат изолированные, четко отделенные стадии жизненного цикла (анализ требований, спецификация требований, предварительное и первичное проектирование, детальное и окончательное проектирование, реализация и тестирование, сборка и интеграционное тестирование, тестирование продукта, приемочное тестирование и передача заказчику, сопровождение, вывод из эксплуатации), особенно четко это представлено в водопадной модели (пока нет подписи на документе, что предыдущая стадия завершена в соответствии с принятыми стандартами качества, следующая стадия не может быть начата), то в объектно-ориентированной модели принято достаточно интенсивное взаимодействие между различными фазами жизненного цикла. Более того, имеет место перекрытие фаз: перекрываются объектно-ориентированный анализ и спецификация требований, иногда – объектно-ориентированный анализ и проектирование (вместе это называется «object-oriented analysis and design», что, вообще говоря, в других моделях является разными фазами). В отличие от других моделей она не разделяет данные и действия: внутри класса атрибуты и методы равноправно взаимодействуют внутри класса. Во многом именно поэтому взаимодействие фаз и является важной особенностью объектно-ориентированного подхода.

Еще важной особенностью выступает итеративная смена фаз. Изготовление продукта – процесс циклический, который может требовать и в ряде случаев требует возврата на предыдущие фазы. То есть фазы объектно-ориентированного проектирования часто включают в себя фазы объектно-ориентированного анализа. Скажем, анализ сценариев использования связан с объектным моделированием и производится на основе диаграмм прецедентов, которые являются продуктом проектирования.

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

Рис. 3.9. Объектно-ориентированная модель жизненного цикла ПО

Чем хороша объектно-ориентированная модель? Она хорошо ложится в доминирующий сегодня подход – ООП, который разработан для многих языков, начиная со Smalltalk и Simula-67, которые привели к созданию таких современных языков, как C++, Java, C# – родной язык. NET, основной для разработки корпоративных приложений. Таких языков достаточно много, и они весьма распространены. Поэтому объектно-ориентированная модель находит весьма широкое применение при производстве корпоративных систем. Чем это обусловлено? Тем, что объектно-ориентированный подход позволяет строить сколь угодно сложные системы за счет наследования и абстракции, того, что можно детализировать предметную область сколь угодно плавно. На основе примитивных классов небольшого размера можно представить грубую модель предметной области любой сложности.

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

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

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

Другие подходы к жизненному циклу включают в себя гибкие методологии, такие как Agile (рис. 3.10), Scrum (рис. 3.11), eXtreme Programming (рис. 3.12). Следует отметить, что направление этих подходов ортогонально моделям жизненного цикла. Они, в отличие от IBM Rational и MSF, применимы к проектам с большими неопределенностями, возможно, большими рисками, но меньшего масштаба, чем корпоративные информационные системы. С другой стороны, методологии – это параллельное направление проектирования систем, которое связано скорее с задачей проектного менеджмента, чем с задачей построения системной архитектуры.

Рис. 3.10. Жизненный цикл ПО, гибкие методологии, Agile

В заключение стоит еще раз отметить, что был рассмотрен ряд моделей – Build-and-fix, водопадная, быстрого прототипирования, инкрементальная, синхростабилизации, объектно-ориентированная, упоминалась эволюционная модель. Build-and-fix пригодна не для корпоративных проектов, а для небольших проектов с предсказуемым циклом развития и объемом порядка 1000 строк. Водопадная модель применима для корпоративных систем, обеспечивает четкую дисциплину проекта и хорошую управляемость, так как основана на большом количестве документов, которые производятся в ходе жизненного цикла, но в итоге из-за только одного прохода получившееся ПО может не соответствовать потребностям заказчика. Быстрое прототипирование несамостоятельно, в ряде случаев вызывает у разработчиков соблазн повторного использования быстро разработанного ненадежного, недокументированного кода. Способствует сопровождаемости и обеспечивает максимально ранний возврат инвестиций, так как приводит к консенсусу по поводу требований заказчика. Инкрементальная модель требует открытой архитектуры и может выродиться в Build-and-fix, но в целом удовлетворяет потребностям клиента из-за эволюционного процесса разработки продукта. Модель синхростабилизации обладает рядом преимуществ, но не получила широкого применения вне Microsoft. Спиральная модель пригодна в первую очередь для внутренних проектов, так как требует специфических знаний по оценке рисков. Объектно-ориентированная модель обеспечивает итерации и паралеллизм, но опять же при слабой дисциплине проекта может выродиться в модель Build-and-fix.

Рис. 3.11. Жизненный цикл ПО, гибкие методологии, Scrum

Рис. 3.12. Жизненный цикл ПО, гибкие методологии, eXtreme Programming (XP)

В предыдущей главе были рассмотрены преимущества и недостатки основных моделей ЖЦ – Build-and-fix, водопадной (каскадной) модели, где проектирование корпоративных информационных систем происходит в один проход, модели быстрого прототипирования (несамостоятельной, так же как и Build-and-fix), инкрементальной, модели синхронизации и стабилизации Microsoft, которая в настоящее время смещается в сторону MSF, спиральной и объектно-ориентированной модели. Также были рассмотрены основные характеристики и особенности моделей, их основные достоинства и недостатки.

Сначала обсудим выбор модели жизненного цикла для интернет-магазина, например магазина музыкальных инструментов, этнических редкостей из Африки, книжного магазина. С точки зрения продуктовой линейки особой специфики здесь нет, потому рассмотрим пример выбора модели жизненного цикла при разработке интернет-магазина вообще.

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

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

Теперь посмотрим, как осуществляется выбор модели жизненного цикла программных решений и обоснование пригодности каждой модели для реализации проекта.

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

Исходя из этих предпосылок перечислим модели. Build-and-fix – модель неполного жизненного цикла, которая содержит краткое описание стадий ЖЦ: первичное проектирование и анализ упрощены, документация присутствует не в полном объеме. Водопадная (каскадная) модель – один проход по всем стадиям жизненного цикла, жесткое документальное согласование каждого этапа с возможностью продолжения или прекращения работы. Модель быстрого прототипирования – несамостоятельная, может применяться как вспомогательная для уточнения технических характеристик. Инкрементальная модель, модель Microsoft (синхростабилизации); объектно-ориентированная модель, где есть взаимодействие и даже перекрытие этапов.

Какие модели можно исключить и почему? Модель Build-and-fix имеет смысл исключить сразу, если решение будет расширяться, а проект необходимо сопровождать. Конечно, этот проект может выйти за рамки 1000 строк, что является пределом для этой модели. Кроме того, программный продукт – законченное решение, включающее помимо кода множество документации: техническое задание (или другой документ со спецификацией требований), большое количество сценариев использования (десятки, сотни страниц), диаграмм, описывающих динамику поведения системы (переходов состояния, потоков данных, последовательности, взаимодействия, классов). Таким образом, модель Build-and-fix существенно ограничена и для данного проекта неприменима.

Водопадная модель требует от заказчика достаточно глубокого знания технических данных, потому что необходимо в один проход жизненного цикла реализовать всю функциональность продукта, следовательно, она не подходит.

Инкрементальная модель тоже не подходит, потому что одно из важных условий состоит в том, что заказчик планирует сразу получить пусть не очень сложный, но работоспособный магазин, поэтому полумеры с точки зрения функциональности его не устраивают. Кроме того, продукт планируется расширять, поэтому использовать эту модель также нельзя. Может быть, если бы развитие было более плавным или удалось договориться о том, чтобы на первом этапе значительную часть функциональности оставить за бортом, модель была бы пригодна. Как вариант ее, наверное, рассматривать можно, но с точки зрения характера задачи это не оптимальный выбор.

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

Нельзя сказать, что инкрементальная модель или модель синхростабилизации не подходит, но существуют ограничения, из-за которых можно лишь с оговорками применять их в данном случае.

Какие модели могут быть использованы вполне, но с некоторыми замечаниями? Модель быстрого прототипирования будет в это случае вполне уместна. Естественно, не как самостоятельная, а как сопровождающая некоторую более серьезную модель. Она применима, потому что у заказчика нет в полной мере четкого представления о функционале и недостает технических знаний, чтобы очертить требования и оговорить функциональность, которая должна быть реализована. Поэтому очень сложно организовать диалог разработчика с заказчиком: они фактически говорят на разных языках. В этом случае на помощь приходит прототип, который как раз и проявит ту функциональность, о которой, возможно, мечтал заказчик, но не формулировал ее явно в силу ограниченности своих технических знаний. С другой стороны, она даст основания разработчику для того, чтобы корректно проектировать и реализовывать программный продукт, избавит разработчика и заказчика от непроизводительных потерь времени, людских ресурсов и средств. Для создания быстрых прототипов подходят технологии Microsoft (Visual Studio). Там существуют хорошие конструкторы визуальных форм и отчетов. Возможно достаточно быстро представить заказчику вариант интерфейса, включая командные кнопки, меню в стиле Windows, привычном заказчику, и обсудить с ним детали будущей реализации, на основе которых можно четче сформулировать технические требования и, что очень важно, определить окончательный выбор модели, поскольку все еще есть различные варианты.

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

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

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

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

Рис. 4.1. Интерфейс интернет-магазина

Итак, имеется экранная форма с каталогом продукции и списком продуктов. Например, выбран там-там. Имеется его фотоизображение, у него есть некое описание, более подробное, чем название, цена, указанная в условных единицах, вес в килограммах. Существует корзина, куда можно добавлять элементы из каталога. В корзине уже лежат два там-тама и дудочки в количестве трех штук. С помощью командных кнопок пользователь может выбрать вид доставки, осуществить удаление одного элемента из корзины или очистить ее целиком, может перейти к оформлению заказа, т. е. получить некий отчет о поступлении заказа в производство. Заказ получает номер, имеет общую стоимость и общий вес. Отдельно оплачивается стоимость доставки в зависимости от ее способа. Кроме того, есть кнопка «история заказов», которая говорит о том, что есть некая база данных или файл, где хранятся сведения о заказах, которые пользователи осуществляли ранее. Возможно, в зависимости от истории заказов пользователям будут предоставлены некоторые преимущества, например скидки или льготы по доставке. Далее происходит вычисление общей стоимости заказа. Есть кнопки, связанные со служебными функциями: кнопки регистрации, входа, помощи. Есть форма регистрации пользователя в системе. По логину система получает информацию о предыдущих заказах пользователя и может отслеживать свои взаимоотношения с клиентом.

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

Дальнейшие шаги сводятся к составлению списка требований и ограничений. Нужно кратко описать основную функциональность, которую будет реализовывать наш продукт. После этого будут проходить стадии жизненного цикла продукта, которые детализируют это начальное описание сценариями использования, рядом других диаграмм, а в итоге – кодом и документацией. Для начала необходимо составить список основных требований и ограничений. При этом при разговоре с заказчиком следует выразить ему в виде вопросов свои сомнения по поводу предметной области или технических характеристик продукта. Например, должна ли система функционировать 24 часа в сутки или достаточно какого-то фиксированного времени, аналогичного часам работы обычных магазинов? Должна ли система представлять всю продукцию, которая есть у заказчика, или это должны быть только малогабаритные предметы? Нужны ли резервные копии базы данных, да и нужна ли в системе вообще база данных? Может, достаточно хранить информацию в виде файлов. Это определяется количеством пользователей. Если история заказов все-таки должна где-то храниться, то правильнее будет включить базу данных в системную архитектуру.

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

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

Наименование продукта должно описываться текстовым полем ограниченной длины (например, 50 символов). Описание должно быть текстовым полем большей длины, по которому пользователь может понять, подходит ему товар или нет. Также должно быть изображение – обычное, цветное, статическое, объема порядка сотен килобайт. Возможно, одной фотографии будет недостаточно (это тоже можно обсудить с заказчиком). Поскольку в требованиях также говорится о доставке заказа, нужно определить такое понятие, как вес, потому что он выступает определяющим условием для типа и стоимости доставки. И, конечно, у продукта должна присутствовать цена. Это атрибут не конкретного экземпляра, а всего типа продуктов. Еще нужен некий внутренний код (артикул) для идентификации продукта (это тоже наводит на мысль об использовании СУБД).

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

Существуют вычисляемые поля: стоимость заказа, общее количество товаров, вес. Их не следует делать хранимыми, а имеет смысл вычислять.

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

В общей архитектуре системы имеется клиентская часть, которая уже была описана, и логика, а также есть некая часть, связанная с СУБД, где хранится каталог товаров и история заказов, плюс есть механизм, определяющий серверную часть реализации. Он работает с базой данных, извлекая из нее необходимую информацию, он передает эту информацию в интерфейс пользователя и содержит логику работы. Таким образом, это трехзвенная архитектура вида клиент – сервер. Далее нужно детализировать такие параметры, как тип СУБД (Oracle, Microsoft SQL Server и т. д. исходя из сроков реализации, объемов данных, используемой модели, интенсивности транзакций), язык и среда реализации (платформы Java или. NET, язык Java или C# исходя из опыта разработчиков и пожеланий заказчика; Java-решение может быть менее затратным), CASE-средства для создания, развития и поддержки продукта.

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

Порядок объема базы данных – сотни мегабайт. Если предусмотреть дополнительные или более высококачественные фотографии размером порядка мегабайта и если товаров порядка сотни, то размер БД будет порядка гигабайта. Сейчас это предварительные соображения, но в документ с требованиями необходимо внести данные о том, какого рода ограничение должно быть на объем данных сверху. Для определения интенсивности транзакций нужно сделать предположение, насколько сложные запросы к базе данных возможны, какова интенсивность транзакций, каков их механизм, какова пропускная способность интернет-канала, который будет узким местом в системе. Поэтому имеет смысл предусмотреть различные механизмы представления информации. Ряд пользователей будет заинтересован в более качественных фотоизображениях, поэтому необходимо оговорить тот порог, который предусматривается для пропускной способности, просто чтобы обезопасить себя от изменения факторов, за которые мы не можем отвечать. Если пропускная способность сети падает ниже возможностей модема, можно говорить о том, что система не сможет работать стабильно. Можно обсуждать с заказчиками скорость порядка десятков мегабит. В любом случае нужно четко описать и это количественное ограничение.

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

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

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

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

Каталог продукции. Это информация о продукции нашего магазина. Возможны разные варианты разграничения возможностей авторизованных и неавторизованных пользователей. Как вариант, возможность просмотра каталога товаров можно сделать доступной и для неавторизованных пользователей. Чтобы сделать заказ, им в любом случае необходимо авторизоваться.

Каталог продукции содержит список наименований, детальное описание продукта, изображение и цену. Нужно указать, всю ли линейку товаров поддерживает система и чем ее ассортимент ограничивается. Например, весь ассортимент продукции заказчика с ограничением на длину и вес.

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

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

Важным является понятие сессии: продукция в корзине пользователя хранится только в ходе одной сессии. Началом сессии можно считать вход в систему, концом – закрытие браузера или нажатие кнопки «Выход». Между этими двумя событиями происходит сессия. После окончания сессии пользователь становится неавторизованным и из корзины все удаляется.

Другое важное функциональное требование – способ оформления заказа. Естественно, оформление заказа возможно только после того, как пользователь выбрал необходимое количество товаров в корзине и нажал на кнопку «Оформить заказ». Таким образом, оформление заказа также доступно только для авторизованных пользователей – это явно указывается в документе. Заказ включает в себя всю продукцию из корзины и свойства доставки – эти атрибуты автоматически переносятся из корзины в заказ. Если нажата кнопка «Оформить заказ», он автоматически попадает в БД и не может быть отменен. Также важно, что после оформления заказа сессия продолжается, но вся продукция из корзины удаляется автоматически. Это тоже нужно явно отметить.

Список требований к системе по программным технологиям может выглядеть так:

Требования к системе: Технологии

• Интерфейс пользователя

Пользовательский интерфейс состоит из графического интерфейса пользователя и логической части

Графический интерфейс позволяет просматривать каталог и данные по каждой продукции отдельно; просматривать хронологию заказов; просматривать содержимое корзины, добавлять в нее продукцию и удалять продукцию из корзины как поштучно, так и всю сразу

Логическая часть пользовательского интерфейса формирует и передает запросы к базе данных, а также обновляет информацию в базе данных, формирует заказы

Пользовательский интерфейс реализован как Java-приложение (версия j2sdk 1.4.2). Графический интерфейс реализован с использованием Swing

Среда разработки – Idea 7.0.1

• База данных

Система хранит в базе данных всю статическую информацию: данные о каждой продукции (наименование, цена, вес, описание, указатель URL к графическому файлу), данные о цене доставки по земле и по воздуху, данные о заказах

В качестве СУБД используется PostgreSQL версии 8.2.4

• Обеспечение связи с базой данных

Для обеспечения связи с базой данных разработан модуль связи с БД. Модуль реализован на языке Java (версия j2sdk 1.4.2). Доступ к БД обеспечен с помощью JDBC (используется драйвер JDBC для PostgreSQL, postgresql-8.2-506.jdbc4.jar)

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

Теперь нужно сказать об используемых программных технологиях. На слайдах приводится один из возможных примеров. Исходя из того что будет выбрана объектно-ориентированная модель, выбирается объектно-ориентированный инструментарий на основе того, что магазин нужен не очень большой, но расширяемый, нужно выбрать инструментарий Java. Тогда возникают основные компоненты: СУБД, язык (логика программной работы и графический интерфейс), серверная часть (ее для простоты можно опустить) и технология связи с базой данных (при данном инструментарии это JDBC). При использовании тех или иных технологий также необходимо рассматривать ограничения. Сразу нужно сказать, что хорошим тоном является упоминание не только названий, но и версий продуктов, которые будут применяться, потому что можно протестировать совместимость этой версии как со средствами, которые имеются у пользователя, так и с элементами программного комплекса, которые мы планируем реализовать.

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

Что включает в себя графический интерфейс, мы можем определить на основе рис. 4.1. Графический интерфейс позволяет просматривать каталог продукции, данные по каждой позиции отдельно (здесь можно прямо указать соответствующий раздел технических требований). Кроме того, пользователь должен при помощи графического интерфейса иметь возможность отслеживать хронологию заказов, работать с корзиной (например, просто перебрасывать элементы каталога в корзину с помощью механизма drag&drop и посредством мыши и клавиатуры изменять количество элементов продукции в своем заказе), удалять и добавлять элементы в корзину.

Теперь опишем функционал логической части интерфейса пользователя. Логическая часть формирует запросы к БД (например, на языке SQL), передает их и получает ответ (с помощью JDBC). Кроме того, логическая часть позволяет обновлять информацию в БД и формировать заказы. Необходимо ограничить пользовательский интерфейс с учетом той программной платформы, которая используется, а также явно указать спектр версий, с которыми совместимо разрабатываемое ПО, для того чтобы не нести ответственность за тот широкий спектр версий Java, который потенциально может использовать заказчик.

Следует отметить, что графический интерфейс, который является частью решения, должен быть реализован с использованием технологий и библиотек Swing (здесь тоже лучше указать версию). Кроме того, среда разработки и средства также должны быть указаны: используем ли мы NetBeans, Eclipse или что-то другое. Например, в данном случае будем использовать среду разработки Idea 7.0.1. Это нужно четко указать для возможности дальнейших модификаций продукта.

Еще ряд важных технологических требований касается других элементов магазина. Во-первых, требования к БД. Прежде всего необходимо явно описать способ хранения данных. Так как объем хранимых данных достаточно велик, следует использовать СУБД, а не файлы. Программная система хранит в БД всю статическую информацию: каталог продуктов, заказы, служебная информация (имена и пароли пользователей, их адреса, ФИО). Что касается единиц продукции, нужно перечислить все атрибуты таблицы, где хранится каталог продукции: наименование, цена, вес, описание, указатель (URL) на изображение данного товара, цена доставки (по земле и по воздуху). Можно сослаться здесь на структуру данных о товаре из списка требований. Естественно, впоследствии при детализации требований необходимо в документации описать ER-диаграммы, которые будут описывать все структуры данных, поля и их типы, включая индексируемые, ключевые и т. д. Еще очень важно оговорить тип СУБД, ее название и версию: мы будем использовать реляционную СУБД PostgreSQL версии 8.2.4, и тогда у нас не возникнет сложностей с сопровождением и дополнительных конфликтов с заказчиков. Естественно, нужно обсудить с заказчиком используемый спектр программного обеспечения.

Третьей составляющей программной системы является обеспечение связи с БД. В данном случае, поскольку мы работаем с технологией Java, будем использовать JDBC. Мы четко указываем, что будем разрабатывать модуль связи с базой данных (отдельный класс). Отдельно указываем версию JDBC – 1.4.2 (как и версия Java). Далее указываем тот самый драйвер JDBC, который мы будем использовать. Естественно, он связан с PostgreSQL. Впоследствии у нас возникнет ряд документации по установке баз данных, да и всей программной среды. Будут указаны все каталоги, переменные окружения и т. д.

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

В предыдущих главах были описаны модели жизненного цикла корпоративных систем, основные этапы их существования, начиная от концептуальной идеи, формализации требований, проектирования, реализации, передачи в эксплуатацию или на стадию сопровождения (собственно то, ради чего весь этот жизненный цикл строится) и вывод из эксплуатации. Было описано, каким образом перечисленные этапы отражаются в различных подходах или моделях жизненного цикла. Некоторые модели включают все стадии (объектно-ориентированная модель), другие – (Build-and-fix) не все стадии жизненного цикла. Существуют модели, которые основаны на линейной смене фаз (каскадная или водопадная), другие поддерживают определенную итеративность или цикличность (объектно-ориентированная или спиральная модели). Ряд моделей позволяет рассматривать некоторые этапы жизненного цикла параллельно или во взаимодействии, это прежде всего объектно-ориентированная модель, в которой сочетаются анализ и проектирование. Существуют несамостоятельные модели, такие как модель быстрого прототипирования. Отсюда следует вывод, что ряд моделей можно комбинировать. Комбинировать следует прежде всего некоторые из моделей полного жизненного цикла (спиральная, каскадная) с моделью быстрого прототипирования. Это дает возможность существенно экономить сроки и стоимость внедрения, избежать существенных проектных ошибок, так как позволяет проявить функциональность программного продукта уже на ранних стадиях (анализ и спецификация требований, начальный этап проектирования), а также благодаря быстрому прототипу вместе с заказчиком определить, в том ли направлении мы двигаемся и правильно ли понимаем друг друга.

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

Методология – это параллельное направление (или ортогональное, еще одна ось, вдоль которой можно рассматривать жизненный цикл). Ранее уже упоминалось, что можно рассматривать программные проекты и программные продукты (их жизненный цикл отличается). В этой главе речь пойдет о программных продуктах, и акцент ставится больше на моделях, чем на методологиях. Но методологии полезны как набор практических приемов для достаточно эффективной реализации, в том числе и корпоративных приложений. Методологии, которые будут рассматриваться, могут включать различные модели. Например, методология Rational Unified Process может иметь в основе модель как каскадного жизненного цикла, так и спирального. То же можно сказать о методологии Microsoft Solution Framework (MSF). Методология с точки зрения жизненного цикла и точки зрения детализации этапов разработки информационных систем – это не столь формальный подход, как модели. В ряде случаев в зависимости от характера и масштаба проектов могут быть существенные коррективы. Rational Unified Process может становиться большим или малым (применяется более или менее развернутая схема разработки). В Microsoft Solution Framework также могут рассматриваться варианты более гибкого подхода (Agile) или подхода Formal (более полного). Желательно иметь в виду соотношение методологий и моделей.

Достаточно важно замечание по поводу характера и масштаба методологий. Существуют методологии, которые в полной мере подходят для проектирования корпоративных систем, и их можно назвать корпоративными (или тяжелыми). Они по аналогии с моделями описывают весь жизненный цикл, позволяют подготовить достаточно полную проектную документацию, хотя каждая из них является просто набором хороших приемов и в ряде случаев допускает упрощенный подход к проектированию и реализации информационных систем. И существуют более легкие (гибкие) методологии, которые не идеально подходят для больших корпоративных систем и могут использоваться при определенных условиях: при высоких рисках, высоких степенях неопределенности в проекте. Такие большие (тяжелые) методологии – это аналоги каскадной, спиральной моделей, не в том смысле, что эти модели там используются, а в том, что это достаточно полное представление жизненного цикла. Такими тяжелыми методологиями являются: Rational Unified Process и Microsoft Solution Framework. Rational Unified Process на сегодняшний день является методологией, которая представляется корпорацией IBM, Microsoft Solution Framework – корпорацией Microsoft. Интересно, что методология MSF возникла из модели синхронизации и стабилизации, и здесь имеются аналогии. Но если говорить о MSF как о методологии, речь пойдет скорее не о жизненном цикле программной системы, а о тех приемах и методах, которые нужны для поддержания этого цикла, для разработки, не только о программном продукте, но и о программном проекте (о ролях в проекте, их особенностях, взаимодействии персонала, проектной документации, которая поддерживает выполнение определенных видов деятельности).

Что касается легких или гибких методологий, будут рассмотрены в разной степени детализации Scrum, Agile, eXtreme Programming. Они являются наборами лучших практик, т. е. наборами рекомендаций о том, каким образом при высоких проектных неопределенностях и рисках вести разработку программных систем для того, чтобы обеспечить определенные качества результирующего программного продукта, если это вообще возможно, или прекратить разработку, если это невозможно, при этом уложившись в определенный бюджет и сроки.

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

Поговорим о методологии Rational Unified Process, которую кратко называют RUP. Она была разработана компанией Rational, затем унаследована корпорацией IBM и сегодня поддерживается достаточно большим количеством инструментальных средств линейки Rational, которые закрывают весь жизненный цикл программного обеспечения. Это и средства проектирования, и средства управления проектами, и целый ряд средств, которые нацелены на фазы разработки, тестирования, внедрения и сопровождения. В линейке более 10 средств, которые взаимодействуют друг с другом, призваны вести проектирование на основе RUP и поддерживают практически весь жизненный цикл программного обеспечения. Самое главное, что нужно отметить о подходе Rational Unified Process, – это то, что есть несколько важных направлений, которых он придерживается. Это прежде всего итеративность (последовательная доработка, примерно, по спиральной или инкрементальной модели). Оценка рисков является важной составляющей RUP (на самом деле всех методологий, особенно гибких). Кроме того, подход имеет в своей основе архитектурную центричность (основан на том, что в центре всего проекта находится архитектура и этап архитектурного проектирования), также применяются сценарии использования. Тут нет ничего удивительного. Сценарии использования применяются широко в языке UML, который поддерживает большинство CASE-средств. Прецеденты – это один из первых видов диаграмм UML, которые встречаются по пути жизненного цикла программных систем. На стадии первичного проектирования возникают прецеденты, и диаграммы прецедентов детализируются в ходе проектирования на сценарии использования. Сценарий использования, по сути, являет собой конкретизацию прецедента. То есть если имеется прецедент, который объединяет такие роли, как пользователь и система, и представляет собой вход в систему (регистрацию), то сценариев использования здесь может быть, как минимум, два – это успешная и неудачная регистрация. То есть сценарий использования детализирует возможные варианты прецедентов.

Кроме того, Rational Unified Process – это достаточно четко определенный и структурированый процесс, последовательные стадии, через которые проходит программное обеспечение по мере своего создания, и важно провести взаимосвязь с дисциплиной программной инженерии. Действительно, RUP вместе с MSF – это та методология, которая предназначена для производства больших, сложных систем, состоящих из ряда взаимодействующих компонентов, возможно включающих базы данных (т. е. корпоративных систем). Rational Unified Process имеет четкую структуру и как методология является достаточно жестким подходом.

Еще одна методология, о которой упоминалось раньше и которая тоже является достаточно жесткой, – это Oracle CDM, но сегодня она применяется нечасто. Она основана на вариации каскадной модели и вполне может быть использована для производства корпоративных приложений. Rational Unified Process – это технология разработки корпоративных информационных систем, которая основана во многом на процессах, она так же, как и жизненный цикл программного продукта, включает четыре стадии.

Очень важно, что RUP, MSF и методологии меньшего калибра основаны на процессах и описывают взаимодействия ролей тех людей, функциональных групп, которые участвуют в этих процессах. При этом процессы разбиваются на активность.

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

Рис. 5.1. RUP: основные вехи

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

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

Конец ознакомительного фрагмента.