CC BY
86
УДК 681.3
МАТЕМАТИЧЕСКАЯ МОДЕЛЬ РАЗРАБОТКИ КОМПОНЕНТОВ КОРПОРАТИВНЫХ ИС
А.А. Рындин, С.В. Сапегин
В статье рассматривается корректность предпосылок, положенных в основу современных моделей разработки компонентов корпоративных ИС. Предлагается математическая модель разработки компонентов ИС на основе понятия жизненного цикла
Ключевые слова: разработка ПО, корпоративные ИС, жизненный цикл ПО
Проблема организации эффективного процесса построения корпоративных ИС является одной из наиболее интересных и сложных проблем в области информатики на протяжении нескольких последних десятилетий. Изучая подходы, применявшиеся в различное время для решения этой задачи, можно выделить следующие тенденции:
1. Формализованные методики разработки, подразумевающие четко запланированный процесс разработки, состоящий из последовательных этапов (IDEF, CDM), с течением времени были вытеснены более гибкими, настраиваемыми методиками, ориентированными на цикличную, спиральную модель разработки (RUP), а в дальнейшем — и на возможное отсутствие в явном виде фаз и стадий процесса разработки (XP, Scrum).
2. Несмотря на обилие экспериментов в области организации разработки ИС, десятки разнообразных подходов и методик, до сих пор, по самым оптимистичным экспертным оценкам только треть проектов в области IT можно считать успешно завершенными. Ни одна из существующих на данный момент методик разработки не в состоянии качественно переломить подобную ситуацию.
3. Для оценки эффективности тех или иных организационных решений обычно используются качественные, субъективные оценки. Это связано либо с несоответствием большинства результатов исследования построенных математических моделей эмпирическим данным, либо с сильной неопределенностью получаемых прогнозов, резко уменьшающих ценность применения соответствующих математических моделей.
Существование перечисленных тенденций обусловлено, прежде всего тем, что характер деятельности разработчика информационного обеспечения корпоративных систем достаточно специфичен по сравнению с другими видами человеческой деятельности. Это затрудняет использование опыта, накопленного в других отраслях, при организации процесса разработки ПО, а также, зачастую, меняет характер решаемых организационных задач. Более того, бурное распространение информационных технологий в различных отраслях человеческой деятельности в будущем может стимулировать обратный процесс - «перетекание» новых способов
Рындин Александр Алексеевич — ВГТУ д-р техн. наук, профессор, E-mail: ar@sb.vrn.ru Сапегин Сергей Владимирович — ВГУ, канд. техн. наук, доцент, E-mail: sapegin@cs.vsu.ru
организации человеческой деятельности из ГГ в другие отрасли промышленности и финансов вслед за прикладными информационными технологиями. Все это определяет большую актуальность исследований в области ГГ, направленных на разработку моделей и методов организации разработки компонентов ИС, способных повысить качество и эффективность создаваемых корпоративных информационных систем.
Среди особенностей процесса разработки компонентов ИС, определяющих его специфичный характер, можно выделить следующие:
1. Высокая степень новизны разрабатываемого продукта. Процесс разработки компонентов ИС практически всегда нацелен на решение каких-либо уникальных задач, достижения каких-либо уникальных свойств компонента. Тиражирование же компонентов, в отличие от тиражирования (серийного выпуска) объектов материального мира не несет в себе практически никаких затрат.
2. Быстрый темп развития информационных технологий. По оценкам экспертов за каждые 5 лет примерно половина технологий в области ГГ безвозвратно устаревает. Подобный темп развития отрасли делает невозможным эффективное среднесрочное планирование процесса развития корпоративных систем традиционными способами, не говоря уже о долгосрочном планировании.
3. Высокая степень неопределенности целей разработки ИС. Процесс построения корпоративных ИС на практике связан с постоянным уточнением функциональных требований к ее компонентам, вызванным как проблемой понимания между разработчиками и пользователями системы, так и представлениями пользователей о возможности использования компонентов ИС в своих бизнес-процессах.
4. Огромное количество методик, средств и решений в области разработки ИС, которые могут быть использованы при разработке каждого конкретного компонента. Это приводит к тому, что ни один специалист не в состоянии при решении задач сформировать в сознании адекватную картину наиболее эффективного решения. На практике разработчики пытаются найти интуитивный баланс между применением в решении поставленных задач уже освоенных технологий и поиском и апробацией новых; однако найти разумный баланс между ростом энтропии системы и потерей эффективности в разработке во многих случаях достаточно тяжело.
Перечисленные особенности серьезно
затрудняют использование методов и средств исследования процесса разработки ПО по аналогии с производством материальных продуктов. Построенные математические модели существенно расходятся с практикой, а используемые при производстве программных компонентов методики не имеют надлежащего математического обоснования.
Рассмотрим подробнее следующие постулаты, лежащие в основе традиционных методов описания процесса разработки ПО:
1. Существует некий фиксированный «идеальный» набор требований Sideal к разрабатываемому компоненту ПО, для которого можно за ограниченное время (в процессе проектирования) подобрать максимально близкий набор требований s
x , определяющий структуру и функциональные возможности разрабатываемого компонента.
Проведем приблизительную оценку трудоемкости достижения идеального набора требова-S
ний ideal . Структуру каждого набора требований к s
компоненту ИС i можно представить в виде:
S,= (1 + A(t ))• S,t,h + (1 + B(t (+ С )• S,u,,r +
+ SDU ) 1 *
s
где i, tech - технологии, используемые в работе компонента (включая технологии взаимодействия с другими компонентами системы);
s
i,user - пользовательские требования к компоненту;
A(t )B(t )- множители, характеризующие изменение требований к компоненту в течение его срока работы;
C - составляющая согласования требований к компоненту между различными пользователями компонента корпоративной ИС;
SD(t ) - набор требований, определяющих
процесс совмещения различной функциональности в компоненте (условие существования множителей A(t )B(t )).
Воспользуемся следующими статистическими данными:
1. Средний срок существования корпоративной ИС — 7 лет;
2. За каждые 5 лет устаревает примерно 50% технологий в сфере IT;
3. Средний срок работы квалифицированного специалиста на одном месте — 5 лет.
Исходя из этих данных, можно сделать вывод, что для обеспечения адекватности требованиям в течение среднего срока жизни компонента ИС (~ 7 лет > 5 лет) необходимо принимать во внимание 50%-ю смену используемых технологий и близкую к 100% смену состава его пользователей. Так как на момент проектирования невозможно сказать, какие именно технологии изменятся в будущем, каковы будут требования к функциональности новых Пользователей, а также каков будет набор структурных 12
изменений, необходимых для внесения новой функциональности, то налицо серьезная неопределенность в вопросах оценки полного объема требований к компоненту для обеспечения его успешной работы в течение всего его срока существования. Иными словами, реальный объем функциональных требований к компоненту всегда больше проектируемых и может отличаться от изначально предполагаемого в разы (это подтверждается мировым опытом разработки программных компонентов), что делает маловероятной возможность нахоже
дения набора требований x , максимально е
близкого к ideal при проектировании компонента.
2. Успешно разработанный и прошедший фазу внедрения компонент гарантированно используется в работе в течение срока своего существования.
Некорректность этого постулата вытекает из природы неопределенности набора требований к компоненту ИС в течение его предполагаемого срока существования (см. исследование первого постулата). Как правило, ожидаемый эффект от внедрения большинства ИТ-решений не превышает 15-20%, соответственно, вероятность того, что изменение е
набора требований x в процессе существования компонента приведет к полному нивелированию эффекта (или даже к отрицательному эффекту от работы с компонентом) достаточно велика.
3. Квалификация разработчика однозначно определяет его производительность и качество работы.
Этот постулат лежит в основе предположения о том, что процесс разработки программных
компонентов можно формализовать в степени, достаточной для получения математически обоснованных предсказуемых результатов. На нем базируется модель зрелости разработки
программного обеспечения CMM (Capable Mature Model), а также каскадный подход к
проектированию и разработке программных компонентов (CDM, IDEF и т.д.). Если представить структуру набора требований к разрабатываемому программному компоненту в виде
St=S0+Sx, (2)
е
где о - начальные требования к компоненту,
S
а x - неопределенность, возникающая в ходе разработки и использования компонента (см. постулат 1), то получается, что подобный подход
S
учитывает только характер о и не учитывает
S
роли x . Вместе с тем, в ходе развития технологий и роста сложности решаемых задач удельный вес
S
предполагаемой неопределенности x в проектах возрастает, что заставляет искать более приближенные к реальности модели разработки (RUP, XP, Scrum и т.д.), нацеленные на максимальное использование эффекта не столько от квалификации разработчика, сколько от его личностных особенностей, а также от характера межличностных взаимодействий в команде разработчиков.
Таким образом, практически все известные на данный момент математические модели организации процесса построения компонентов корпоративных ИС изначально базируются на достаточно сомнительных постулатах, что и определяет их низкую практическую ценность.
В качестве исходных предпосылок для моделирования процесса разработки компонентов корпоративных ИС рассмотрим следующие предположения:
1. Процесс разработки компонента корпоративной ИС неотделим от процесса его существования (жизненного цикла) в рамках системы. Иными словами, разработка компонента с той или иной степенью интенсивности ведется в течении всего времени его использования. В самом деле, учитывая неопределенность начальных требований, а также смену технологий и условий окружающей среды, фактическая работа над компонентом ведется практически до момента отказа от его использования.
2. Эффект от разработки компонента корпоративной ИС является функцией не прогнозируемого, а фактического времени его использования. Использование прогностических оценок в вычислении экономического эффекта от использования компонентов ИС обычно обусловлено традиционным подходом к определению рамок процесса их разработки (окончание процесса разработки приравнивается к началу фазы эксплуатации компонента). Статистические данные о фактическом использовании компонентов корпоративных ИС показывают на практике серьезные расхождения между их прогнозируемой и реальной полезностью.
3. Компоненты корпоративной ИС играют сервисную роль в реализации бизнес-процессов предприятия. Иными словами, компоненты, за исключением некоторых специфических ситуаций, не реализуют бизнес-процессы самостоятельно (как это предполагается в традиционных исследованиях), а являются лишь инструментами для реализации бизнес-процессов работниками предприятия. Соответственно, степень полезности компонентов для работы предприятия определяется не столько их прямым соответствием логике автоматизируемых бизнес-процессов, сколько возможностями по автоматизации деятельности исполнителей этой логики. Исходя их этого, можно сделать вывод о невозможности отделения конкретных пользователей ИС и их свойств от самой системы:
4. Пользователи корпоративной ИС являются не внешней средой по отношению к системе, а непосредственной ее составляющей. В существую-
Воронежский государственный технический университет Воронежский государственный университет
щих моделях влияние пользователей корпоративной системы на ее функциональность рассматривается в качестве исходных данных на этапе проектирования; как правило, без всякого анализа возможных тенденций развития пользовательских требований. Однако, анализ истории развития различных программных проектов показывает, что требования пользователей изменяются в течение всего срока использования программного компонента по следующим причинам:
а). меняются бизнес-процессы предприятия;
б). изменяются границы области применения программного компонента (вследствие изменения состава и структуры самой ИС);
в). изменяется степень изучения компонента пользователями;
Все три причины взаимосвязаны между собой, а процесс удовлетворения возникших требований часто носит характер цепной реакции (т.е. появление новой функциональности порождает появление очередных требований к компоненту).
Таким образом, предсказание характера развития набора требований к компоненту ИС невозможно без учета структуры и особенностей конкретного набора пользователей ИС.
Исходя из этих предпосылок, задачу разработки и использования программных компонентов корпоративных ИС можно представить в виде выражения
T
| f (S(t);F(t)) max, (3)
0
где S(t) — набор требований к компоненту ИС, F(t) — функциональность компонента, T — время существования компонента, f — функция, оценивающая соответствие функциональности компонента F(t) актуальным требованиям S(t). В качестве наиболее простого варианта функции f можно использовать выражение вида
f = ll(R(S(t ),F (t ))+l), (4)
где R — расстояние между множествами S(t) и F(t) в момент времени t.
Литература
1. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - Спб.: Символ-Плюс, 1999. - 304 с.
2. Макконнелл С. Сколько стоит программный проект. -М.: «Русская Редакция», Спб.: Питер, 2007. - 297 с.
3. http://www.gartner.com
THE MATHEMATICAL MODEL OF CIS COMPONENT DEVELOPMENT A.A.Ryndin, S.V. Sapegin
In article the correctness of the preconditions taken as a principle of modem models of working out of components of CIS is considered. The mathematical model of working out of components on the basis of concept of life cycle is offered Key words: software development, corporative IS, life cycle
