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

Жизненный цикл разработки приложений: мечты и реальность

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

Чем же обусловлено недоверие многих руководителей проектов к инструментам, позволяющим автоматизировать многие этапы работы возглавляемых ими коллективов? На мой взгляд, тому есть несколько причин. Первая из них заключается в том, что очень часто применяемые компанией средства плохо интегрируются между собой. Рассмотрим типичный пример: для моделирования применяется Rational Rose, для написания кода - Delphi Professional, для проектирования данных - CA AllFusion Modelling Suite; средства интеграции этих продуктов или вообще отсутствуют для данной комбинации их версий, или некорректно работают с русским языком, или просто не приобретены. А в результате диаграммы прецедентов и иные модели, созданные с помощью Rose, становятся не более чем картинками в проектной документации, а модель данных главным образом служит источником ответа на вопросы типа: «Зачем это поле вообще нужно в той таблице?» И даже такие простые части приложения, как русские эквиваленты имен полей базы данных, пишутся участниками проекта как минимум три раза: один раз - при документировании модели данных или приложения, второй раз - при написании кода пользовательского интерфейса, а третий - при создании файла справочной системы и руководства пользователя.

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

Третья причина, по которой средства поддержки жизненного цикла программного обеспечения применяются далеко не везде, где они могли бы принести пользу, заключается в крайней ограниченности их выбора. На российском рынке активно продвигаются главным образом две линейки продуктов: инструменты IBM/Rational и инструменты Computer Associates (главным образом линейка продуктов AllFusion Modelling Suite), во многом ориентированные в данный момент на определенные виды моделирования, а не на постоянный процесс синхронизации кода, базы данных и моделей.

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

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

1. Средства управления требованиями должны упростить создание модели приложения и модели данных.

2. На основании этих моделей должна генерироваться значительная часть кода (желательно не только клиентского, но и серверного).

3. Значительная часть документации должна генерироваться автоматически, причем на языке той страны, для которой предназначено данное приложение.

4. При создании кода приложения в моделях должны происходить автоматические изменения, а при изменении модели должна происходить автоматическая генерация кода.

5. Код, написанный вручную, не должен исчезать при изменениях в модели.

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

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

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

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

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

Продукты Borland с точки зрения руководителя проекта

омпания Borland является одним из самых популярных производителей средств разработки: уже двадцать лет ее продукты пользуются заслуженной любовью разработчиков. До недавнего времени эта компания предлагала главным образом широкий спектр средств, предназначенных непосредственно для создателей кода приложений, - Delphi, JBuilder, C++Builder, Kylix (обо всех этих продуктах мы неоднократно писали в нашем журнале). Однако успех компании на рынке во многом определяется тем, насколько она следует тенденциям его развития и насколько понимает нужды тех, кто является потребителем ее продукции (в данном случае - компаний и отделов, специализирующихся на разработке приложений).

Именно поэтому в настоящее время стратегия развития средств разработки Borland предполагает поддержку полного жизненного цикла приложений (Application Lifecycle Management, ALM), включающего определение требований, проектирование, разработку, тестирование, внедрение и сопровождение приложений. Об этом свидетельствует прошлогоднее приобретение корпорацией Borland ряда компаний - BoldSoft MDE Aktiebolag (ведущего поставщика новейшей технологии разработки приложений Model Driven Architecture), Starbase (поставщика средств конфигурационного управления программными проектами), TogetherSoft Corporation (поставщика решений в области проектирования программного обеспечения). За время, прошедшее с момента приобретения этих компаний, было проделано много работы, в плане интеграции этих продуктов между собой. В результате эти продукты уже удовлетворяют потребностям руководителей проектов, связанным с возможностью организации итеративной коллективной разработки. Ниже мы обсудим, что именно предлагает сейчас компания Borland руководителям и другим участникам проектов, связанных с разработкой программного обеспечения (многие из описанных ниже продуктов и технологий интеграции были представлены этой компанией на прошедших в ноябре конференциях для разработчиков в Сан-Хосе, Амстердаме и Москве).

Управление требованиями

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

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

Для управления требованиями в арсенале Borland имеется продукт Borland CaliberRM, по сути представляющий собой платформу для автоматизации процесса управления требованиями, предоставляющую средства отслеживания изменений (рис. 2).

CaliberRM интегрируется со многими средствами разработки производства как компании Borland, так и других производителей (например, Microsoft), вплоть до встраивания списка требований в среду разработки и генерации заготовок кода при переносе мышью пиктограммы требования в редактор кода. Кроме того, на его основе можно создавать собственные решения - для этого существует специальный набор инструментов CaliberRM SDK.

Отметим, что этот продукт применяется для управления требованиями не только к программному обеспечению, но и к другим продуктам. Так, известны случаи его успешного применения в автомобильной промышленности для управления требованиями к различным узлам автомобилей (в том числе автомобилей «ягуар»). Кроме того, по уверению Джона Харрисона (Jon Harrison), менеджера, отвечающего за линейку продуктов JBuilder, применение CaliberRM при создании Borland JBuilderX значительно упростило процесс разработки этого продукта.

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

Проектирование приложений и данных

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

Для проектирования приложений и данных компанией Borland предлагается продукт Borland Together (рис. 3), представляющий собой платформу для анализа и проектирования приложений, интегрирующуюся с различными средствами разработки как компании Borland, так и других производителей (в частности, Microsoft). Указанный продукт позволяет осуществлять моделирование и проектирование приложений и данных; при этом степень его интеграции со средствами разработки на данный момент такова, что изменения модели данных приводят к автоматическому изменению кода приложения, равно как и изменения в коде приводят к изменению в моделях (данная технология интеграции инструментов моделирования и средств разработки получила название LiveSource).

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

Создание кода приложения

Создание кода приложения — область, в которой компания Borland специализируется в течение всех 20 лет своего существования. Сегодня Borland производит средства разработки для платформ Windows, Linux, Solaris, Microsoft .NET, а также для ряда мобильных платформ. Мы уже неоднократно писали о средствах разработки этой компании, и в данной статье повторяться не будем. Отметим лишь, что последние версии средств разработки этой компании (Borland С#Builder, Borland C++BuilderX, Borland JBuilderX), а также ожидаемая вскоре новая версия одного из самых популярных в нашей стране средств разработки, Borland Delphi 8 для Microsoft .NET Framework, позволяют осуществить тесную интеграцию средств моделирования Together и средств управления требованиями CaliberRM с их средами разработки. О Delphi 8 мы обязательно расскажем в отдельной статье в следующем номере нашего журнала.

Тестирование и оптимизация

Тестирование — абсолютно необходимая составляющая создания качественного программного обеспечения. Именно на этом этапе проверяется, удовлетворяет ли приложение сформулированным требованиям к нему, а в код приложения (а нередко и в модели, и в базы данных) вносятся соответствующие изменения. На этапе тестирования обычно требуется применение средств анализа и оптимизации производительности приложений, и для этой цели применяется Borland Optimizeit Profiler. Сегодня данный продукт наряду с этим интегрируется в среды разработки последних версий средств разработки Borland, а также в среду Microsoft Visual Studio .NET (рис. 4).

Внедрение

Внедрение программного обеспечения - одна из наиболее важных составляющих успеха проекта. Оно должно осуществляться таким образом, чтобы на этапе опытной эксплуатации продукта в него можно было вносить изменения без серьезных затрат и потерь, легко увеличивать количество пользователей без снижения надежности. Поскольку в настоящее время внедрение приложений происходит в условиях применения компаниями различных технологий и платформ и эксплуатации определенного количества уже имеющихся приложений, при внедрении может оказаться важной способность осуществления интеграции нового приложения с унаследованными системами. Для этой цели компанией Borland предлагается ряд технологий межплатформенной интеграции (таких как Borland Janeva, позволяющих осуществить интеграцию.NET-приложений с приложениями, основанными на технологиях CORBA и J2EE).

Управление изменениями

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

Для решения данной задачи можно применять Borland StarTeam (рис. 5) — масштабируемое средство управления конфигурациями программного обеспечения, которое сохраняет в централизованном репозитарии все необходимые данные и оптимизирует взаимодействие сотрудников, ответственных за выполнение различных задач. Этот продукт предоставляет команде участников проекта разнообразные средства для публикации требований, управления задачами, планирования, работы, обсуждения изменений, контроля версий, организации документооборота.

Особенностями данного продукта являются тесная интеграция с другими продуктами Borland, поддержка распределенных команд разработчиков, взаимодействующих через Интернет, наличие нескольких типов клиентских интерфейсов (в том числе Web-интерфейса и Windows-интерфейса), поддержка многих платформ и операционных систем, наличие StarTeam Software Development Kit (SDK), представляющего собой прикладные программные интерфейсы для создания решений на базе StarTeam, средства защиты данных на стороне клиента и сервера, средства доступа к репозитариям Merant PVCS Version Manager и Microsoft Visual SourceSafe, средства интеграции с Microsoft Project, средства визуального представления данных, создания отчетов и поддержки принятия решений.

Вместо заключения

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

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

Безусловно, в процессе разработки программного обеспечения найдется место искусству талантливых программистов и профессиональному мастерству других участников процессов создания программного продукта, однако сегодня стало ключевым осознание того факта, что в этой деятельности нет места для бессвязности, недокументированности и диктата индивида. Одной из наиболее заметных тенденций первого десятилетия этого века в индустрии создания программных систем стало появление ALM (Application Lifecycle Management, ALM) - управления жизненным циклом приложений .

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

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

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

Эксперт в области ИТ Д. Чеппел предостерегает от упрощенного взгляда на ALM, которое часто отождествляют лишь с жизненным циклом разработки программного обеспечения (Software Development LifeCycle, SDLC): инициацией, итеративным циклом разработки, выпуском релиза продукта и внедрением. Дисциплина ALM охватывает более широкий круг задач, рассматривая все аспекты существования такого корпоративного ресурса, как приложения. По определению Д. Чеппела, жизненный цикл приложения включает в себя все этапы, на которых организация так или иначе вкладывает средства в этот ресурс - от исходной идеи программного решения до утилизации отслужившего свой срок ПО .

Предельно детализируют это определение в НР - по версии компании, цикл составляет лишь один из этапов полноценной модели

АЬМ - этап доставки приложения (рис. 3.14), а кроме него есть еще планирование, эксплуатация и вывод из эксплуатации . Цикл замкнут: до момента, когда организация приходит к окончательному выводу о ненужности приложения, оно продолжает совершенствоваться. Грамотная реализация АЬМ направлена в том числе на то, чтобы продлить срок эффективной работы программного решения и, как следствие, обеспечить сокращение затрат на покупку или создание принципиально новых программных продуктов.

Анализ потребностей бизнеса

Приоритетность и инвестиции

Уор4дленне ШШДоиШ „Мониторинг программ

Совершенствование

Планирование

Руководящие решения

Исправление

ошибок

Мониторинг

настройка

жизненный ЦИКЛ приложения

Практики

Соответствие

требованиям

Повторное

ислопкюванис

Инициация

терации разработки

Доставка

Вывод из экс плуатации

Выпуск

недрение

Рис. 3.14. Модель ALM

Д. Чеппел развертывает картину жизненного цикла в линейную, выделяя три основные области ALM: руководство (governance), разработка (development) и эксплуатация (operations). Соответствующие этим областям процессы протекают, перекрываясь, от зарождения идеи нового приложения или модернизации существующего к этапу его развертывания и до полного завершения функционирования.

Руководство в ALM реализуется на протяжении всего жизненного цикла приложения и включает в себя все процессы и процедуры, которые относятся к принятию решений и управлению проектом. Главная задача здесь - обеспечение соответствия приложения тем или иным целям бизнеса, что определяет значимость этого компонента ALM. К процессам руководства, Д. Чеппел относит разработку детального инвестиционного предложения (бизнес-кейс, содержащий анализ затрат, выгод и рисков, связанных с будущим приложением), которое предшествует стадии разработки; управление разработкой с помощью методов и средств управления проектами и портфелями (Project Portfolio Management, PPM); управление работающим приложением в рамках управления портфелем приложений предприятия (Application Portfolio Management, АРМ).

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

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

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

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

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

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

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

Изначально одними из немногих новаторов, которые поняли важность ALM и изменили свои стратегии выпуска продуктов в сторону явной ее поддержки, были Borland и IBM Rational. Отреагировав на очевидные возможности, к победившей концепции ALM примкнули и другие компании: Microsoft, Telelogic, Mercury, Serena, Compuware, CollabNet и Mercury . Сегодня ALM - это установившаяся тенденция и растущая индустрия, признанная аналитиками. Производители решений ALM предоставляют различные средства и технологии для поддержки процесса разработки ПО. Эти средства выходят далеко за рамки традиционных инструментов для повышения производительности отдельного разработчика. Они направлены на предоставление методик и инструментов, ориентированных на коллективную работу по созданию ПО. Чтобы создать жизнеспособное решение для ALM, производители должны учитывать потребности расширенной группы разработчиков ПО и включать в свои продукты роли, которые участвуют в более широком процессе.

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

Сегодня возникают новые требования к ALM, и определяющую роль в этом играет широкое распространение скорых (agile) методов разработки. Несколько лет назад создатель одной из наиболее известных скорых методик Scrum Д. Сазерленд заявил о грядущей тотальной адаптации идей скорой разработки. Это казалось преувеличением, но прогноз оказался верным. По данным совместного исследования аналитиков Capgemini Group и подразделения HP Software&Solutions, в 2010 г. свыше 60% компаний уже использовали или планировали использовать разработку в стиле agile, а среди участников опроса Forrester лишь 6% признались, что пока еще только присматриваются к скорым методам, все же остальные применяют их в той или иной степени, причем 39% считают свои реализации вполне зрелыми .

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

Осознание остроты проблемы и тенденция поиска средств ее решения даже породили новый термин DevOps, применяемый для обозначения концепций и технологий улучшения взаимодействия между разработкой и эксплуатацией. Основные надежды на реализацию этих идей аналитики возлагают на ALM-среды нового поколения, которые на деле, а не в теории обеспечат интеграцию ключевых этапов жизненного цикла приложений. Создаваемые приложения сегодня во многих случаях композитны и интегрируют на сервисных принципах компоненты, реализованные на разных языках программирования для разных платформ, а также код внешних систем и унаследованные решения. Для управления их жизненным циклом среда ALM должна поддерживать различные среды разработки и платформы выполнения (например, NET и J2EE), а также обеспечивать возможность контроля исходного кода, лицензирования и статуса разработки внешних компонентов приложения.

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

Линейка продуктов Rational для поддержки различных этапов жизненного цикла ПО всегда выделялась широтой и фокусом на интегрированность модулей между собой. Аналитики Butler Group оценили комплекс решений IBM Rational Software and Systems Delivery как наиболее полный из представленных на рынке по спектру реализованных компонентов ALM. Этот комплекс включает в себя продукты для управления портфелями проектов, проектирования и разработки на базе моделей, управления требованиями, управления конфигурациями и изменениями, управления качеством, управления сборками и релизами; оркестровки процессов жизненного цикла ПО и обеспечения отчетности и документации по этим процессам. Слово Systems в названии появилось после приобретения компании Telclogic, решения которой ориентированы на поддержку процессов системной инженерии и теперь интегрированы в портфель Rational. Их включение в ALM-среду IBM отражает тенденцию сближения процессов разработки ПО и систем и формирования для них единой среды управления жизненным циклом.

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

Ядром Jazz является платформа Jazz Foundation, объединяющая сервер Jazz Team Server и ряд дополнительных модулей интеграции. Jazz Team Server демонстрирует новый для ALM подход к интеграции компонентов для разных этапов жизненного цикла (рис. 3.15, ). Если традиционно такая интеграция базировалась на точечной связи между отдельными продуктами, то в Jazz реализована открытая распределенная сервисная архитектура на базе стандарта REST, которая обеспечивает простое взаимодействие инструментальных компонентов между собой (своего рода ALM Web). Интерфейс RESTful позволяет представлять в виде сервисов данные и функциональность разнообразных модулей. Использование подхода на базе стандартов Web обеспечивает хорошую масштабируемость Jazz, делая платформу универсальным решением, способным поддерживать задачи ALM в небольших командах и в крупных коллективах разработчиков .

Project and Team Structure

Event Notification

Jazz Team Server

j* ;

Requirements Items and relationships IlJ Event history,

Use " cases ...... Item history trends

Builds Source code. Test-cases Test results

				Visual Studio
Client Platform		Client Platform		Client Platform

Security and Access

Рис. 3.15. Интегрированная корпоративная платформа управления жизненным циклом приложений

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

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

Платформа Jazz обеспечивает интеграцию со средой разработки Eclipse, предоставляя ряд представлений и проекций. Некоторыми компонентами Jazz поддерживаются также веб-клиенты. Платформой Jazz предоставляются два значимых представления для Eclipse: Team Central и Team Artifacts. Оба представления служат для сбора информации и могут дополняться компонентами платформы Jazz. Разработки Eclipse, некоторые компоненты платформы Jazz позволяют пользователям обращаться к серверу Jazz непосредственно из веб-обозревателя .

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

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

Система RTC реализует управление конфигурациями ПО, управление задачами и сборками, а также планирование итераций и отчетность по проекту, обеспечивает определение различных типов процессов разработки и интегрируется с другими продуктами Rational для поддержки полного жизненного цикла ПО. В 2009 г. IBM также выпустила Rational Quality Manager (портал для управления тестированием на базе Jazz) и инструмент управления эффективностью Rational Insight, реализованный для платформы Jazz с использованием аналитических технологий Cognos и предназначенный для задач высокоуровневого управления портфелями проектов разработки.

Широкие возможности в области интеграции IBM Rational Team Concert делают данный инструмент абсолютно уникальным. Среди существующих интеграций следует отметить следующее.

• 1. Интеграцию с IBM Rational Requirements Composer в рамках совместной разработки приложений (Collaborative application lifecycle management, или CALM), которая позволяет связывать рабочие задания с требованиями, порожденными или измененными на основе этих заданий, и наоборот, требования с заданиями, созданными для планирования работ по реализации данных требований.
• 2. Интеграцию с IBM Rational Quality Manager в рамках совместной разработки приложений (Collaborative application lifecycle management), на основе чего становится возможным организовать дефект-трекинг по результатам выполненных тестов в ходе тестирования выпускаемых программных продуктов.
• 3. Интеграцию с IBM Rational ClearQuest для синхронизации рабочих заданий и запросов на изменения, определенных в классическом средстве управления разработкой IBM Rational ClearQuest.
• 4. Интеграцию с IBM Rational ClearCase для синхронизации артефактов версионного и конфигурационного управления между двумя указанными средствами.

Открытая архитектура Jazz Integration Architecture, лежащая в основе IBM Rational Team Concert, позволяет вести дополнительную разработку новых механизмов интеграции с другими системами, которые могут быть развернуты и активно использоваться в организации. Одним из вариантов интеграции с данными системами может являться использование продукта RTC Email Reader от компании «Финэко Софт», который обеспечивает синхронизацию рабочих заданий IBM Rational Team Concert в соответствии с email-сообщениями предопределенного формата. При этом возможна и обратная синхронизация благодаря встроенной подсистеме оповещений IBM Rational Team Concert.

Надо также отметить, что управление версиями и конфигурациями на базе IBM Rational Team Concert может быть организовано практически в любом проекте, даже если среда разработки (IDE) не имеет непосредственной интеграции с этим инструментом. Это становится возможным благодаря совместному использованию «толстого клиента» IBM Rational Team Concert и неинтегрируемого IDE. Так, если для Eclipse IDE, IBM Rational Software Architect, IBM Rational Application Developer и Microsoft Visual Studio такие интеграции существуют, то уже, например, с Delphi придется дополнительно использовать «толстый клиент» IBM Rational Team Conceit, что не представляет больших трудностей.

И т.д..

«Управление жизненным циклом» сводится к необходимости освоения привычных для системной инженерии практик:

• управление информацией («нужная информация должна быть у нужных заинтересованных сторон вовремя, и в доступной для её использования форме»),
• управление конфигурацией («проектная информация должна соответствовать требованиям, информация «как построено» должна соответствовать проекту, в том числе проектным обоснованиям, физическая система должна соответствовать информации «как построено», а разные части проекта при этом должны соответствовать друг другу», иногда часть этой практики назвают «управление изменениями »).

СУЖЦ vs PLM

По-новому сформулированная СУЖЦ не использует PLM как обязательный класс программных средств, вокруг которого такая система строится. В крупных инженерных проектах обычно используется сразу несколько (чаще всего существенно "недоосвоенных") PLM разных вендоров, и при создании СУЖЦ речь идёт обычно уже об их межорганизационной интеграции. Конечно, при этом решаются и вопросы, как интегрировать в СУЖЦ информацию и тех систем, которые еще не имеют связи с какой-то из PLM систем расширенного предприятия. Термином «расширенное предприятие» (extended enterprise) обычно называют созданную посредством системы контрактов организацию из ресурсов (людей, инструментов, материалов) участвующих в конкретном инженерном проекте различных юридических лиц. В расширенных предприятиях ответ на вопрос, в какую именно PLM интегрируются данные какой именно из систем CAD /CAM /ERP /EAM /CRM /и т.д.. становится нетривиальным: владельцам разных предприятий не предпишешь использовать программные средства одного поставщика.

А поскольку PLM-система всё-таки являтся программными средствами, а "система управления" из СУЖЦ явно понимается в том числе как "система менеджмента", то термин СУЖЦ подразумевает явно и организационный аспект, а не только аспект информационных технологий. Тем самым фраза "использование PLM для поддержки системы управления жизненным циклом" вполне осмыслена, хотя может запутывать при дословном переводе в ней “PLM” на русский.

Тем не менее, понимание "системы управления жизненным циклом", когда ею занимаются специалисты из IT-служб, немедленно нивелируется назад к "только софту", подозрительно напоминающему программные средства PLM. И после этого переупрощения начинаются трудности: «коробочная» система PLM от какого-то поставщика программных средств автоматизации проектирования обычно сразу представляется конструктивно, как набор программных модулей из каталога этого поставщика, вне связи с поддерживаемыми инженерными и менеджмерскими функциями, и рассматривается как тройка из следующих компонент:

• датацентрический репозиторий данных жизненного цикла,
• «система документооборота» (workflow engine) для поддержки «управления»,
• «портал» для просмотра содержимого репозитория и состояния документооборота.

Назначение СУЖЦ

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

Главная идея любой современной СУЖЦ - это использование аккуратного и непротиворечивого представления системы и окружающего её мира в неизбежно разнородных и изначально несовместимых между собой компьютерных системах расширенной организации. Использование виртуальных макетов, информационных моделей, датацентрических репозиториев проектной информации обеспечивает выявление коллизий при "сооружении в компьютере", "виртуальной сборке", а не при выносе чертежей и других моделей проекта в материальную реальность в ходе действительного сооружения «в металле и бетоне» и пуска в эксплуатацию.

Идея СУЖЦ не имеет тем самым отношения к разнообразным «автоматизациям проектирования», прежде всего – к «порождающему проектированию » (generative design) и «порождающему производству » (generative manufacturing). СУЖЦ озабочена более не синтезом, а анализом: обнаруживает и/или предотвращает коллизии в результатах проектирования отдельных подсистем, когда их будут собирать вместе по самым разным технологиям:

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

Моделеориентированный подход

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

Модель данных может быть разработана в соответствии с каким-то языком, например:

• в терминах стандарта описания метода разработки ISO 24744),
• метамодель (в терминах консорциума стандартизации OMG),
• модель данных/справочные данные (в терминах стандарта интеграции данных жизненного цикла ISO 15926).

Именно такой переход к структурно представляемым моделям, существующим уже на ранних стадиях проектирования и называется «Системной инженерией на основе моделей » (MBSE, model-based systems engineering). Снимать коллизии при помощи компьютерной обработки данных становится возможным уже на самых ранних стадиях жизненного цикла, еще до появления полноценных 3D моделей конструкции.

СУЖЦ должна:

• обеспечивать механизм передачи данных из одного приложения CAD/CAM/ERP/PM/EAM/и т.д. в другое – причем в электронном структурированном виде, а не в виде «пачки электронной бумаги». Передача данных из одной инженерной информационной системы (с четким пониманием откуда, куда, когда, что, зачем, как) - это часть обеспечиваемой СУЖЦ функциональности. Тем самым СУЖЦ должна поддерживать workflow (ход работ, который частично выполняется людьми, а частично компьютерными системами).
• контролировать версии , то есть предоставлять функцию управления конфигурацией - как моделей, так и физических частей системы. СУЖЦ поддерживает таксономию требований разного уровня и предоставляет средства для проверки коллизии разноуровневых проектных решений и их обоснований с этими требованиями. В ходе инженерной разработки любое описание системы, любая её модель изменяются и дополняются многократно, и существуют поэтому во множестве альтернативных версий разной степени правильности, и в разной мере соответствующих друг другу. СУЖЦ должна гарантировать, что для текущей работы используется только правильное сочетание этих версий.

Архитектура СУЖЦ

Архитектурных решений для СУЖЦ может быть множество, одна и та же функция может быть поддержана различными конструкциями и механизмами работы. Можно выделить три вида архитектуры:

1. Традиционные попытки создать СУЖЦ – это обеспечить важнейшие передачи данных по принципу "точка-точка" между разными приложениями. При этом может быть использована какая-нибудь специализированная система поддержки workflow (BPM engine, «движок управления бизнес-процессами»), или система обработки событий (complex event processing engine). К сожалению, объем работы по обеспечению обменов «точка-точка» оказывается просто грандиозным: каждый раз требуются специалисты, разобравшиеся в обоих связываемых системах и методе передаче информации.
2. Использование стандарта интеграции данных ЖЦ ISO 15926 по методу «ISO 15926 outside», когда для каждого инженерного приложения разрабатывается адаптор в нейтральное представление, соответствующее стандарту. Тем самым, все данные получают возможность встретиться в каком-то приложении и коллизия между ними может быть обнаружена – но для приложения требуется разработать лишь один адаптер передачи данных, а не несколько таких адаптеров (по числу других приложений, с которыми нужно обеспечить связь).
3. PLM (Teamcenter, ENOVIA, SPF, NET Platform и т.д.) - используется стандартизованная архитектура, за тем лишь исключением, что используемая в каждой из этих PLM модель данных менее универсальна в плане отражения любой предметной области инжиниринга, а также не является нейтральным и доступным всем форматом. Так что использование ISO 15926 в качестве базового представления при передаче данных в СУЖЦ можно считать дальнейшим развитием идей, по факту реализованных в современных PLM.

По архитектуре управления конфигурацией , СУЖЦ можно разделить на три вида:

• «репозиторий» (актуальное хранение всех данных проекта в одном репозитории СУЖЦ, куда копируются данные оттуда, где они были разработаны),
• «регистр» (СУЖЦ поддерживает список адресов данных жизненного цикла в многочисленных репозиториях других САПР , систем инженерного моделирования, PLM , ERP и т.д.),
• «гибридная архитектура» -- когда часть данных копируется в центральный репозиторий СУЖЦ, а часть данных доступна из других мест по ссылкам.

Архитектора СУЖЦ должна также описывать:

• «портал» (в том числе «веб-портал»), его функциях и способ реализации. Само наличие портала позволяет успокоить топ-менеджеров демонстрируя отсутствие коллизий. К архитектурным решениям по «порталу СУЖЦ» предъявляются специфические требования.
• алгоритмы проверки целостности/непротиворечивости данных жизненного цикла, а также описание работы этих алгоритмов:
  • стандартный модуль в отдельном приложении, работающий над данными в репозитории этого приложения – будь это САПР или PLM ;
  • специально разработанное для СУЖЦ программное средство проверки коллизий, имеющее доступ к данным разных приложений, находящихся в центральном репозитории СУЖЦ;
  • специально разработанное программное средство, обращающееся через интернет по защищенному каналу к разным хранилищам данных , находящимся в разных организациях;
  • специально запрограммированные проверки с контролем коллизий при загрузке разных инженерных наборов данных в центральный репозиторий СУЖЦ;
  • комбинация из всех перечисленных методов – разных для разных типов коллизий; и т.д.
• способ взаимодействия пользователей СУЖЦ (инженеров-проектантов, закупщиков, монтажников, менеджеров проекта сооружения и т.д.), и как именно программное обеспечение СУЖЦ поддерживает это взаимодействие способом, предотвращающим появление коллизий. Стандарты системной инженерии (в частности, стандарт практик системной инженерии ISO 15288) требуют выбора вида жизненного цикла для инженерии сложных объектов и указания того, какие варианты практик системной инженерии будут использованы. Модель жизненного цикла является одним из основных артефактов, которые служат для организационных договоренностей по координации работ расширенной организации инженерного проекта. Скоординированные работы в ходе коллаборативной разработки (collaborative engineering) – это залог малого числа проектных коллизий. Как именно поддержит модель жизненного цикла СУЖЦ? Так, системы PLM обычно не находят место моделям жизненного цикла, и уж тем более моделям организации. Поэтому для СУЖЦ нужно искать другие решения по программной поддержке этих моделей.
• Организационный аспект перехода к использованию СУЖЦ . Переход к использованию СУЖЦ может вызвать существенное изменение в структуре и даже кадровом составе инжиниринговой компании: не всех землекопов берут в экскаваторщики, не всех извозчиков берут в таксисты.

Главное для СУЖЦ – насколько предлагаемое решение способствует раннему обнаружению, а то и предотвращению коллизий. Ежели речь заходит о чём-то другом (содержательный выбор вида жизненного цикла в соответствии с профилем риска проекта, управление старением, управление стоимостью и реформа сметной системы, освоение axiomatic design , сооружение с поставками «точно вовремя », порождающее проектирование и сооружение, а также многое-многое другое, также крайне полезное-современное-интересное), то это вопрос других систем, других проектов, других методов, других подходов. СУЖЦ должна хорошо делать своё дело, а не плохо решать огромный набор произвольно выбираемых чужих задач.

У архитектора СУЖЦ тем самым две основные задачи:

• породить некоторое количество лучших архитектур-кандидатов и их гибридов
• совершить многокритериальный выбор из этих архитектур.
  • содержательное рассмотрение (содержательность критериев выбора)
  • оформление результата (обоснование).

Критерии выбора архитектурного решения для СУЖЦ

1. Качество выполнения СУЖЦ своего основного предназначения: обнаружения и предотвращения коллизий Главный критерий: насколько может быть ускорен ход инженерных работ за счёт ускорения обнаружения или предотвращения коллизий при использовании предлагаемой архитектуры СУЖЦ? А если время работ не может быть сокращено, то насколько за то же время можно увеличить объем работ при использовании тех же ресурсов? Рекоммендуются следующие методологии:
   • Теория ограничений Голдратта (TOC, theory of constraints) – архитектура должна указывать, какие системные ограничения она снимает на критическом ресурсном пути инженерного проекта (не путать с критическим путём).
   • ROI (return on investments) для инвестиций в СУЖЦ на стадии оформления результата содержательного рассмотрения архитектур-кандидатов.
   Важно выбрать границы рассмотрения: общая скорость выполнения инжинирингового проекта может быть замерена только на границе рассматриваемой организационной системы. Границы какого-то одного юрлица могут не совпадать с границами расширенного предприятия, осуществляющего масштабный инженерный проект, а участвующее лишь на одной стадии жизненного цикла предприятие может неправильно оценить свою полезность и критичность для полного жизненного цикла системы и неправильно выбрать способ своей интеграции в СУЖЦ. Тогда может выясниться, что создание СУЖЦ не влияет на общие сроки и бюджеты проекта, ибо самые неприятные коллизии продолжат себя являть неадресованные новой СУЖЦ.
2. Возможность принятия инкрементального жизненного цикла разработки СУЖЦ Инкрементальным в ISO 15288 называется такой жизненный цикл, при котором функциональность пользователю выдаётся не сразу вся, а постадийно - но и вложения в разработку также происходят не одномоментно, а постадийно. Конечно, при этом нужно учитывать закон убывающей полезности: каждый инкремент СУЖЦ (каждый новый тип обнаруживаемых заранее коллизий) обходится дороже, а пользы от него всё меньше, пока продолжающаяся много лет разработка СУЖЦ не затухнет сама собой. Если выясняется, что для какой-то из предложенных архитектур нужно одномоментно вложить в создание СУЖЦ много денег, но пользу можно будет получить сразу в размере 100% и только через пять лет "под ключ", то это плохая архитектура. Если выясняется, что можно разработать и ввести в эксплуатацию какое-то компактное ядро СУЖЦ, и далее много-много однотипных модулей для разных типов коллизий с понятным механизмом их разработки (например, основанным на использовании ISO 15926), то это очень хорошо. Речь не столько о том, чтобы применять «гибкую разработку» (agile methodologies), сколько предусмотреть модульную архитектуру СУЖЦ и предложить план реализации приоретизированного списка модулей – сначала самых насущных, затем менее насущных, и т.д. Не путать с ICM (incremental commitment model), хотя смысл тут такой же: лучше та архитектура, при которой можно получить какую-то рассрочку платежей за систему, а нужную функциональность получать как можно раньше – чтобы пользу получить (хотя бы маленькую) пораньше, а платить за позднюю пользу попозже.
3. Принципиальная финансовая и интеллектуальная возможность освоить и поддерживать технологию Если посчитать траты не только на собственно СУЖЦ, но и на всю потребную для осуществления проекта кадровую и иную инфраструктуру, то нужно понять, сколько этих вложений в образование, компьютеры и организационные усилия останется плательщику и собственнику СУЖЦ, а сколько осядет вовне – у многочисленных контракторов, которые, конечно, будут благодарны сначала за получение ими «стипендии» на освоение новой технологии, а затем за сопровождение созданной ими системы. Новое обычно крайне затратно, и не потому что оно само дорого стоит, а потому что вызывает лавину вызываемых им изменений. Именно этот пункт у меня учитывает полную стоимость владения СУЖЦ, и этот же пункт включает рассмотрение полного жизненного цикла уже не инженерной системы с её предотвращаемыми коллизиями, но самой СУЖЦ.
4. Масштабируемость архитектуры СУЖЦ Этот критерий актуален для крупных инженерных проектов. Поскольку вы хотите, чтобы системой пользовались все тысячи сотрудников расширенной организации, она должна будет быстро расти до этих масштабов. Насколько "пилот" или "полигон" СУЖЦ смогут быстро вырасти без принципиальных архитектурных изменений? Скорее всего, они вырасти не смогут. Поэтому архитектурно нужен не "пилот" или "полигон", а сразу "первая очередь". Требование критерия масштабирования тесно пересекается с требованием критерия инкрементальности, но затрагивает чуть-чуть другой аспект - не столько растяжка создания СУЖЦ по времени, сколько возможность растяжки по накрываемому объему. Опыт показывает, что на тестовых объемах проектных данных справляются все системы, а вот на промышленных - не справляются. Как нелинейно будет расти стоимость аппаратуры и программных средств при росте объемов/скорости? Как долго будут отрабатывать регламенты, когда выяснится, что через какое-то рабочее место проходит бОльшее число данных, чем может быть осмысленно просмотрено одним человеком? Плохая масштабируемость может подстерегать не только с технической стороны архитектуры программно-аппаратного решения, но и со стороны финансовой его архитектуры. Так, небольшая цена на лицензию на каждое рабочее место СУЖЦ, или даже небольшая цена на каждое новое соединение на сервере-репозитарии могут превратить более-менее симпатичное решение для десяти рабочих мест в абсолютно финансово неподъемное для целевой тысячи рабочих мест.
5. Возможность учитывать неизбежные организационные проблемы в том числе отношение к любимым унаследованным (legacy) системам в расширенной организации. Как много предлагаемая централизованная или распределенная архитектура потребует "отдавать функций другим подразделениям", "отдавать наших данных" и вообще чего-то "отдавать" по сравнению с текущей ситуацией без СУЖЦ? Мейнфреймы массово проиграли соревнование мини-компьютерам, а те - персональным. Назад (к централизованным системам, каковой неизбежно представляется СУЖЦ) пути почти нет, ибо все данные лежат в отдельных приложениях, и вытащить эти данные в новые системы представляется сложнейшей организационной задачей. Как устроена архитектура СУЖЦ: она замещает текущие унаследованные инженерные приложения, она надстраивается над текущей IT-инфраструктурой, она устанавливается "задарма" разным службам? Сколько организационных/менеджерских/консультационных усилий потребуется для того, чтобы "пропихнуть" новую технологию? Сколько людей уволить, сколько найти и принять новых специалистов? Этот критерий организационной приемлемости тесно связан не только с централизацией/децентрализацией, но и с рассмотрением системы мотивации в расширенном предприятии, т.е. оценка архитектуры СУЖЦ по этому критерию далеко выходит за рамки узкого рассмотрения только СУЖЦ, но требует тщательного анализа принципов построения расширенной организации – вплоть до пересмотра принципов, лежащих в основе контрактов, по которым она создана. Но это и есть суть системного подхода: любая целевая система (в данном случае - СУЖЦ) рассматривается прежде всего не "вглубь, из каких частей", а "наружу, часть чего" - не ее конструкция и механизм работы интересны прежде всего, а поддерживаемая СУЖЦ функция предотвращения коллизий во внешней надсистеме - и цена, которую внешняя надсистема готова платить за эту новую функцию. Поэтому возможные архитектуры СУЖЦ и рассматриваются прежде всего не с точки зрения "приличных используемых технологий, например от поставщика программных средств XYZ" (это по умолчанию: все предлагаемые варианты архитектуры обычно приличны технологически, иначе они не варианты!), а с точки зрения вышеописанных пяти критериев.

Функции СУЖЦ

1. Предотвращение коллизий
   1. Управление конфигурацией
      1. Идентификация (классификации, кодировки)
      2. Учёт конфигурации (все возможные baseline - ConOp, Architecture, design, as built), в том числе передача данных в репозиторий СУЖЦ, в том числе поддержка workflow изменений, в том числе поддержка параллельного инжиниринга (работа в условиях неполных baseline)
      3. Версионирование (включая forks)
   2. Отсутствие ручного переввода данных (передача входных и выходных данных между уже имеющимися островками автоматизации, включая передачу данных из островков "подъема в цифру" старых проектных наработок)
   3. Конфигурация НСИ
   4. Система поддержки коллаборативного инжиниринга (видео-конференции, удаленные проектные сессии и т.д. - возможно, не та, которая используется для создания самой системы СУЖЦ)
2. Выявление коллизий
   1. Поддержка регистра проверяемых видов коллизий и соответствующих регистру технологий проверки
   2. Передача данных для проверки коллизий между островками автоматизации (без сборки в репозитории СУЖЦ, но средствами интеграционной технологии СУЖЦ)
   3. Прогон workflow проверки разных видов коллизий
      1. в репозитории СУЖЦ
      2. не в репозитории, но средствами интеграционной технологии СУЖЦ
   4. Запуск прогона workflow устранения найденной коллизии (рассылка уведомлений о коллизиях, ибо прогон workflow устранения – не забота СУЖЦ)
   5. Поддержка актуального списка неустранённых коллизий
3. Развиваемость (тут СУЖЦ рассматривается как автопоэтическая система, ибо «инкрементальность реализации» входит в число важнейших свойств самой СУЖЦ -- так что это функция самой СУЖЦ, а не функция обеспечивающей системы для СУЖЦ)
   1. Обеспечение коммуникации по поводу развития СУЖЦ
      1. Планирование работ развития СУЖЦ (roadmap , разработка плана мероприятий)
      2. Функционирование проектного офиса СУЖЦ,
      3. Ведение регистра видов проверок коллизий (сам регистр "хотелок" и roadmap реализации проверок)
      4. Орг-техническое моделирование (Enterprise Architecture) для СУЖЦ
      5. Инфраструктура коммуникации разработчиков СУЖЦ (интернет-конференции, видеосвязь, управление знаниями и т.д. -- возможно, не та, которая используется в ходе коллаборативного инжиниринга с использованием СУЖЦ)
   2. Единообразность технологии интеграции данных (например, технология ISO 15926)
      1. Использование нейтральной модели данных
         1. Поддержка библиотеки справочных данных
         2. Разработка справочных данных
      2. Технология поддержки адаптеров к нейтральной модели данных
   3. Единообразность технологии интеграции workflow/BPM (в масштабах расширенного предприятия)
4. Безопасность данных (в масштабах информационных систем, работающих в рамках СУЖЦ)
   1. Обеспечение единства доступа (один логин и пароль ко всем информационным системам, участвующим в workflow)
   2. Управление правами доступа к элементам данных
   3. Резервное копирование

Анализируя развитие рынка средств разработки за последние 10-15 лет, можно отметить общую тенденцию смещения акцентов от технологий собственно написания программ (которые с начала 90-х годов ознаменовались появлением RAD-инструментов - "быстрая разработка приложений") к необходимости комплексного управления всем жизненным циклом приложений - ALM (Application Lifecycle Management) .

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

· определение требований (Requirements);

· проектирование и анализ (Design & Analysis);

· разработка (Development);

· тестирование (Testing);

· развертывание и сопровождение (Deployment & Operations).

Каждый из этих этапов должен тщательно отслеживаться и контролироваться. Правильно организованная ALM-система позволяет:

· сократить сроки вывода продуктов на рынок (разработчикам приходится заботиться лишь о соответствии их программ сформулированным требованиям);

· повысить качество, гарантируя при этом, что приложение будет соответствовать потребностям и ожиданиям пользователей;

· повысить производительность труда (разработчики получают возможность делиться передовым опытом разработки и внедрения);

· ускорить разработку благодаря интеграции инструментов;

· уменьшить затраты на сопровождение, постоянно поддерживая соответствие между приложением и его проектной документацией;

· получить максимальную отдачу от инвестиций в навыки, процессы и технологии.

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

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

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

Еще одним серьезным игроком на поле средств разработки является корпорация Microsoft. Пока она не замахивается на создание собственной ALM-платформы; продвижение в данном направлении идет только в рамках сотрудничества с другими поставщиками, теми же Rational и Borland (обе они стали первыми участниками программы Visual Studio Industry Partner). В то же время созданное Microsoft ключевое средство разработки Visual Studio .NET постоянно расширяет функциональность за счет использования высокоуровневых средств моделирования и управления проектами, в том числе путем интеграции с Microsoft Visio и Microsoft Project.

Следует отметить, что на сегодняшний день практически все ведущие компании–разработчики технологий и программных продуктов (кроме перечисленных выше, можно назвать Oracle, Computer Associates и др.) располагают развитыми технологиями создания ПО, которые создавались как собственными силами, так и за счет приобретения продуктов и технологий, созданных небольшими специализированными компаниями. И хотя, подобно корпорации Microsoft, создание собственной ALM-платформы ими пока не планируется, выпускаемые этими компаниями CASE-средства находят широкое применение на отдельных этапах ЖЦ ПО.