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

К.т.н. Евланов М.В.

Харьковский национальный университет радиоэлектроники, Украина

Оценка объема работ по реализации описания архитектуры информационной системы

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

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

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

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

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

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

В общем случае любую связь между фреймами или между фреймом и интерфейсом можно описать выражением вида [4]:

, (1)

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

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

Для выделения таксономии фреймов введем формализованное описание связи вида «генерализация». Исходя из выражения (1), данная связь может быть описана следующим образом [4]:

, (2)

при выполнении для каждого дочернего фрейма условия [4]

, (3)

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

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

(4)

при выполнении условия

(5)

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

Оценкц объема работ по реализации описания рациональной архитектуры ИС с использованием онтологических точек предлагается осуществить путем модификации известного и апробированного на практике метода объектных точек [5]. Данный выбор обусловлен сравнительной простотой метода объектных точек и возможностью получения с его помощью достаточно точных оценок объема работ по созданию ПО ИС на ранних стадиях соответствующих IT-проектов. Для устранения невозможности оценки методом объектных точек объема работ по созданию ИО ИС предлагается рассматривать данный вид работ как программирование на языке PL/SQL (или аналогичному ему) БД со структурой, определяемой описанием рациональной архитектурой создаваемой ИС.

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

Использование процессного представления ФТ к ИС [1] позволяет определить термин «экран» метода объектных точек как совокупность структур данных, необходимых для выполнения следующих операций:

а) ввод данных, инициирующих выполнение процесса;

б) вывод результатов выполнения процесса на экран дисплея;

в) извлечение из БД используемых в процессе данных;

б) сохранение поступающих из процесса данных.

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

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

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

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

, (6)

, (7)

где - множество фреймов -ой онтологической точки, характеризующей -й экран -й ИТ-услуги; - множество фреймов -ой онтологической точки, характеризующей -й отчет -й ИТ-услуги; - идентификатор экрана ; - идентификатор отчета .

Значения функции (6) приведены в табл. 1. Значения функции (7) приведены в табл. 2.

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

Таблица 1 –

Значения функции оценки уровня сложности работ по созданию экрана программного модуля ИТ-услуги

Таблица 2 –

Значения функции оценки уровня сложности работ по созданию отчета программного модуля ИТ-услуги

. (8)

Значения функции (8) приведены в табл. 3.

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

Таблица 3 –

Значения функции оценки уровня сложности работ по созданию программного модуля ИТ-услуги

, (9)

а ее значения будут определяться верхней строкой значений табл. 1. Кроме того, для обмена данными между модулем и БД необходим экран, характеризующийся количеством всех онтологических точек данной ИТ-услуги и оцениваемый функцией (6). Наличие отчетов в этом случае должно быть особо оговорено в публикации ФТ.

Тогда по аналогии с методом объектных точек объем работ по созданию ИС на основе описания ее архитектуры можно оценить как объем работ по реализации новых онтологических точек следующим образом:

, (10)

где - коэффициент производительности исполнителей IT-проекта создания ИС (см. [5]); - оценка новых онтологических точек, определяемая по формуле

; (11)

- оценка онтологических точек ИТ-услуги, определяемая по формуле

; (12)

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

; (13)

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

Для расчета времени выполнения IT-проекта создания ИС на основе описания ее архитектуры можно в этом случае использовать формулу расчета затрат времени модели COCOMO II, которая имеет следующий вид [5]:

, (14)

где - время выполнения IT-проекта создания ИС, месяцы; - оценка совокупности драйверов масштаба и экономичности IT-проекта создания ИС, которая определяется по формуле

; (15)

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

Потребность в персонале для IT-проекта создания ИС на основе описания ее архитектуры можно оценить по формуле

. (16)

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

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

Литература

1. Левыкин, В.М. Паттерны проектирования требований к информационной системе: моделирование и применение [Текст] / В.М. Левыкин, М.В. Евланов, М.А. Керносов: монография. – Харьков: ООО «Компанія СМІТ», 2014. – 320 c.

2. Фримен, Э. Паттерны проектирования / Э. Фримен, Э. Фримен, К. Сьерра, Б. Бейтс. – СПб.: Питер, 2011. – 656 с.

3. Евланов, М.В. Унификация методов оценивания затрат на создание современных информационных систем [Текст] / М.В. Евланов, Е.И. Соловьева // Вісник Кременчуцького національного університету ім. Михайла Остроградського. – 2014. – Випуск 5/2014 (88). – С. 62-67.

4. Левыкин, В.М. Параллельное проектирование информационного и программного комплексов информационной системы / В.М. Левыкин. М.В. Евланов, В.С. Сугробов [Текст] // Радиотехника. – 2006. – Вып. 146. – С. 89-98.

5. COCOMO II Model Definition Manual [Электронный ресурс] // Сайт «Center for Systems and Software Engineering». – Режим доступа: ftp://ftp.usc.edu/pub/soft_engineering/COCOMOII/cocomo99.0/modelman.pdf. – Заголовок с экрана.