Компьютерные технологии сопровождения жизненного цикла сложных технических объектов

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

Рис. 1. Стадии ЖЦ изделий

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

· Второй фактор научно-технического прогресса привел к использованию в проектировании новой методологии, названной за рубежом Concurrent Engineering (параллельное или совмещенное проектирование) [7].

На рисунке 1 представлены стадии ЖЦ сложных изделий. На рисунке 1а показана организация жизненного цикла изделия при последовательной технологии, а на рисунке 1б – ЖЦ изделия при параллельной технологии. Тем самым обосновано название технологии. В [9] декларируется повышение качества изделий, сокращение модификаций конструкций изделия на стадиях его изготовления (в 2-3 раза) и экономия времени от идеи до рынка (на 25-50%) при использовании С-технологии.

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

Приведем основные особенности таких изделий, условно ограниченных в пространстве и времени совокупности технических средств, имеющих единое целевое назначение, а также следующие признаки:

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

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

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

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

Рис. 2. Общая схема жизненного цикла объекта новой техники

 

Рис. 3. Детальная схема ЖЦ с отображением малого цикла

Преобразование сложного изделия во времени происходит в рамках ЖЦ, объединяющих три крупные фазы [13]: проектирование по техническому заданию (Т3), постройку и программированную эксплуатацию (ПЭ). На рисунках 2 и 3 представлены схемы структур жизненных циклов объекта новой техники. На рисунке 2 показано, что общая тенденция ЖЦ заключается в минимизации временных затрат на первые два этапа, и в максимизации сроков эксплуатации сложного объекта. Для обеспечения этого необходимо при его проектировании учитывать условия и факторы его функционирования. В этом и заключается основная идея программированности эксплуатации. Прежде всего каждый новый вид техники проектируется и создается для функционирования во взаимодействии с другими видами техники, образуя единую систему. Подробно о технологии построения и использования программированных ЖЦ сложных объектов см. [10-13]. На рисунке 3 детальная схема ЖЦ демонстрируется с отражением малого ЖЦ.

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

Эта основная интегральная цель делится на следующие подцели:

Ø разделение обобщающего процесса на основные этапы (фазы);

Ø обеспечение непрерывности фаз в рамках обобщающего процесса;

Ø определение основных характеристик фаз процесса;

Ø исследование взаимного влияния этапов друг на друга;

Ø использование интегрального критерия эффективности ЖЦ (функционала от частных критериев фаз);

Ø обеспечение управления реализацией фаз ЖЦ.

Возможность управления и интеграции обусловили создание программируемых ЖЦ.

В [12] дано следующее определение ЖЦ применительно к объектам проектирования (ОП): упорядоченная совокупность изменений состояния ОП между начальным и конечным называется ЖЦ ОП. При этом начальное состояние ОП связывается с моментом возникновения замысла (идеи) или начала финансирования процесса его создания; конечное – с моментом его элиминации (прекращения деятельности в связи с физическим или моральным старением, замены, преобразования в качественно новый объект).

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

Первый класс составляют относительно небольшие программы, создаваемые одиночками или небольшими коллективами (3 –5) специалистов, которые:

· создаются преимущественно для получения конкретных результатов автоматизации научных исследований или для анализа относительно простых процессов самими разработчиками программ;

· не предназначены для массового тиражирования и распространения как программного продукта на рынке, их оценивают качественно и интуитивно преимущественно как “художественные произведения”;

· не имеют конкретного независимого заказчика-потребителя, определяющего требования к программам и их финансирование;

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

· не подлежат независимому тестированию, гарантированию качества и/или сертификации.

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

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

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

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

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

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

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

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

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

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

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

Рисунок 1

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

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

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