Вопрос 28. Принципы и методы проектирования систем доу

Общая концепция моделирования систем документационного обеспечения управления

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

В процессе разработки проектировщики сталкиваются с рядом проблем.

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

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

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

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

Структурный анализ (СА) – это метод исследования системы, который начинает с ее общего обзора и затем детализируется, приобретая иерархическую структуру со все большим числом уровней. СА предусматривает разбиение системы на уровни абстракции с ограниченным числом элементов на каждом из уровней (обычно от 3 до 6-7). На каждом уровне выделяются лишь существенные для системы детали. Данные рассматриваются в совокупности с операциями, выполняющимися над ними. Используются строгие формальные правила записи элементов информации, составления спецификации системы и последовательное приближение к конечному результату.

Методология СА базируется на ряде общих принципов. В качестве двух базовых принципов используется принцип декомпозиции и принцип иерархического упорядочивания.

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

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

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

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

• Интерфейсы и распределение функций между человеком и системой;

• Требования к программным и информационным компонентам системы, необходимые аппаратные ресурсы, требования к базе данных, физические характеристики компонентов системы, их интерфейсы.

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

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

1. Методы изучения и анализа фактического состояния объекта или технологии позволяют выявить узкие места в исследуемых процессах и включают:

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

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

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

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

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

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

2. Методы формирования заданного состояния. Основываются на теоретическом обосновании всех составных частей и элементов системы исходя из целей, требований и условий заказчика. К данным методам относятся:

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

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

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

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

3. Методы графического представления фактического и заданного состояний предусматривают использование для наглядного представления процессов обработки информации в форме блоксхем, графиком прохождения документов и т.д. Графические методы являются составной частью любого проекта и необходимы для практической работы, т.к. выполняют роль вспомогательного средства при описании внедрения новых технологий. Наиболее известные – блок-схемный метод, методы стрелочных диаграмм, сетевых графиков, таблиц последовательности операций прохождения процессов. Различия выражаются в степени их реализации на ПЭВМ, наглядности и глубине отражаемых процессов.

После стадии предпроектного обследования следует этап проектирования. Эту стадию делят на 2 этапа:

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

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

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

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

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

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

В области автоматизации проектирования за последние десятилетие сформировалось новое направление – CASE Расширение областей применения ЭВМ, возрастающая сложность инфосистем, повышающиеся к ним требования привели к необходимости индустриализации технологий их создания. Важное направление в развитии технологий составили разработки интегрированных инструментальных средств, базирующихся на концепциях жизненного цикла и управления качеством автоматизированных систем, представляющих собой комплексные технологии, ориентированные на создание сложных автоматизированных систем и поддержку их полного жизненного цикла или ряда его основных этапов дальнейшее развитие работ в этом направлении привело к созданию ряда концептуально целостных, оснащенных высокоуровневыми средствами проектирования и реализации вариантов, доведенных по качеству и легкости тиражирования до уровня программных продуктов технологических систем, которые получили название CASE-систем или CASE-технологий (Computer-Aided Software/System Engineering).

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

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

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

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

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

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

• Улучшают качество создаваемых АС за счет средств автоматического контроля;

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

• Ускоряют процесс проектирования и разработки системы;

• Освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки;

• Поддерживают развитие и сопровождение разработки АС;

• Поддерживают технологии повторного использования компонентов разработки.

Большинство CASE-технологий основано на научном подходе, получившем название «методология/метод/нотация/средство». Методология формулирует руководящие указания для оценки и выбора проекта разрабатываемой АС, шаги работы и их последовательность, а также правила применения и назначения методов.

Архитектура систем документационного обеспечения управления

Декомпозиция системы автоматизации управленческой деятельности – деление системы на ряд задач (модулей), каждый из которых моделирует определенную сферу управленческой деятельности. Таким образом, происходит разбиение СА на автоматизируемые функции: система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом автоматизируемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.

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

Классификация методов декомпозиции: системный метод и структурный метод.

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

• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;

• DFD (Data Flow Diagrams) диаграммы потоков данных;

• ERD (Entity- Relationship Diagrams) диаграммы «сущность- связь»;

На стадии проектирования системы модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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

Организационная и функциональная структуры систем автоматизированного управления.

Организационная структура САУ включает совокупность следующих подсистем:

• Информационная

• Лингвистическая

• Техническая

• Программная

• Математическая

• Правовая

• Эргономическая

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

Функциональная структура САУ - набор функциональных подсистем, состав которых зависит от типа основной деятельности, объектов (экон., производств., административ. и т.д.), сферы их функциональной направленности, уровней управленческой деятельности.

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

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

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