Современные информационные технологии/
3.Программное обеспечение

д.т.н. Рындин А.А., к.т.н. Сапегин С.В.

Воронежский государственный технический университет, Россия

Особенности жизненного цикла компонентов в составе современных программных комплексов

 

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

Рассмотрим постановку задачи о разработке программного компонента в общем виде. Структуру каждого набора требований к компоненту ИС  можно представить в виде:

                          (1)

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

1.     Время разработки компонента ПО ограничено.

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

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

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

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

,                                       (2)

где S(t) — набор бизнес-требований, F(t) — реализованная функциональность, T — время использования компонента, T0 – момент начала использования, f — функция, оценивающая соответствие функциональности компонента F(t) актуальным требованиям S(t), f[0,1]. В качестве простейшего, самого грубого варианта функции f можно использовать выражение вида

,                                               (3)

где D — мощность симметричной разности множеств S(t) и F(t) в момент времени t, |S(t)| - мощность множества S(t). Практика показывает, что зависимость расстояния между множествами S(t) и F(t) (т.е. степени соответствия функциональности компонента бизнес-требованиям) в случае процесса интенсивной (целенаправленной) разработки имеет S-образный характер. Это обусловлено тем, что в начале цикла разработки ресурсы затрачиваются не столько на реализацию бизнес-функций, сколько на выстраивание архитектуры ПС. Поэтому, варианты функции f, более соответствующие статистическим данным, следует искать среди семейств S-функций различной кривизны. Схематичный график функции f, иллюстри­рующий идеальный жизненный цикл такого компонента, представлен на рис. 1.

Рис. 1. Жизненный цикл компонента

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

1.        Снижение уровня используемой функциональности до некоего критического порога (служба становится фактически бесполезной в новых условиях);

2.        Несоответствие службы реалиям архитектуры (при смене операционной системы, модели данных, среды взаимодействия служб, стандартов и т.д.);

3.        Замена службы на новую версию, либо полное распределение функционала службы между другими, введенными в эксплуатацию, службами.

 

ЛИТЕРАТУРА:

1.     Вендров А.М. Проектирование программного обеспечения экономических информационных систем. — М.: Финансы и статистика, 2000.

2.      Мишенин А.И. Теория экономических информационных систем. — М.: Финансы и статистика, 2000. — 240 с..

3.     Jorge Dias Jr. A Software Architecture Process for SOA Definition. LAP: Lambert Academic Publishing, 2009, 160 p.