Анализ практики проектирования программного обеспечения АСУП. Часть 1

автор публикации: Мадорская Ю.М.,
к.т.н., доцент СПбГПУ,

Этапы и данные проектирования.

Разработка ПО АСУП чаще всего начинается с этапа сбора (формирования) требований к системе – этапа постановки задачи автоматизации. И хотя данный этап чаще всего выделяют как внешний по отношению к этапу проектирования, с уверенностью можно сказать, что принятие проектных решений начинается уже на этом этапе.  В рамках этого этапа производится  описание предметной области автоматизации — бизнес-процессов предприятия [15], [42], [22], [40], подлежащих автоматизации, связанных с ними понятий и их характеристик. Это описание является по сути описанием требований верхнего уровня или, как еще называют, исходных требований к ПО АСУП.

Описания такого рода структурируются относительно бизнес-процессов и связанных с ними понятий предметной области. При этом разрабатываются так называемые функциональные модели деятельности, например, в виде иерархии диаграмм потоков данных с разработанными для всех процессов нижнего уровня подробными спецификациями на структурированном естественном языке или в виде иерархии SADT-диаграмм. Так же разрабатываются  информационные модели, как правило, с использованием нотации “сущность-связь” [16].

Это подтверждают и самые последние исследования в области анализа практики описания бизнес-процессов [91]: «анализ бизнес-процессов обычно структурируется относительно трех различных представлений – процессного, ресурсного и объектного представления».

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

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

В связи с этим  задача учета правил и их связей с бизнес-процессами и понятиями предметной области автоматизации приобретает огромное значение для решения задачи формирования оценки изменений ПО АСУП.

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

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

Описание проектных решений, определяющих логическую модель реализации требований, чаще всего структурируется относительно функций системы и способов представления данных в системе – логической модели данных. Проектные решения данного уровня могут быть представлены функциональной моделью будущей системы в соответствии с одним из общеупотребительных стандартов (например, IDEF0 или IDEF3), и информационной моделью, например, в соответствии со стандартом IDEF1X [16].

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

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

Далее, на основе созданных описаний производится непосредственная разработка ПО АСУП. Реализация ПО АСУП представляет собой конечный программный код и спецификацию схем данных в хранилищах и  не считается описанием требований и проектных решений.

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

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

Далее Анализ практики проектирования программного обеспечения АСУП. Часть 2

Профессиональная система для проектирования программного обеспечения и управления требованиями

;-)Любое копирование и публикация материала допускается только с письменного разрешения автора.
Для ссылки в научной работе  правильно использовать:
Мадорская Ю. М., Метод оценки сложности модификации программного обеспечения АСУП: дис. … канд. техн. наук: 05.13.06/ Мадорская Юлия Михайловна; Санкт-Петербургский государственный политехнический университет; науч. рук. Курочкин М. А. — СПб., 2011. — 205 с. : ил.- Библиогр.: с. 138-148.

Литература

[15] Елиферов В. Г. Бизнес-процессы: Регламентация и управление: Учебник /В. Г. Елиферов, В. В. Репин. – М.: ИНФРА-М, 2006. – 319 с.

[16] Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов/ Г. Н. Калянов. –  М.: Финансы и статистика, 2006. – 240 с.

[22]  Кульга К. С. Модели и методы создания интегрированной информационной системы для автоматизации технической подготовки и управления машиностроительным производством:  автореф. дис. докт. техн. Наук  / К. С. Кульга. –  УФА.: ГОУ ВПО  УГАТУ, 2009. –32 с.

[40]  Черемных С.В. и др. Моделирование и анализ систем. IDEF-технологии: практикум / С.В. Черемных, И.О. Семенов, В.С. Ручкин. –М.: Финансы и статистика, 2002. –192 с.

[42] Яковлев Н. Н. Системная модель комплекса требований к автоматизированной информационной системе на основе семантический аннотации:  автореф. дис. канд. техн. наук  / Н. Н. Яковлев. –  УФА.: ГОУ ВПО  УГАТУ, 2010. –32 с.

[91] Pedrinaci C., Domingue J. , Medeiros A.K. A Core Ontology for Business Process Analysis // Proceedings of 5th European Semantic Web Conference, 2008. – P. 49-64.

Присоединиться в facebook или linkedin

Комментарии

комментарии

Комментарии закрыты.