Раздел 1. Общие сведения

Здесь указывается:

полное наименование системы и ее условные обозначения,

шифр темы разработки и шифр (номер) договора,

наименования или кредиты предприятия -- разработчика и заказчика,

перечень документов, на основании которых создается система, кем и когда они утверждены,

плановые сроки начала и окончания работ по созданию системы,

сведения об источниках и порядке финансирования работ,

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

по изготовлению и наладке отдельных средств и комплексов систем.

Раздел 2. Назначение и цели создания или развития системы

2.1 Назначение системы

Указывается тип автоматизирования.

-- например, направление проектирования, размещение рекламы,

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

Кроме того, для АСОИУ указывается перечень автоматизированных объектов управления и управляемых объектов.

-- например, АРМ оператора целом промывки деталей

2.2 Цели создания

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

Понятие цели. Свойства цели. (№21 -- 1 к.р.)

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

Например, "Наша цель -- коммунизм!"

Свойства целей:

• адекватность - означает соответствие цели требованиям, предъявляемым к управляемому процессу.

Например, неразумно требовать какую-то сверхвысокую скорость работы системы, в которой участвует человек.

• инвариантность -- независимость целей от интервала времени исполнения управляющего процесса

Пример: цель -- выиграть спортивный матч...

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

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

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

Непосредственно достижимые цели, которые обеспечиваются достижением задач АСОИУ. К ним относятся:

• повышение качества принимаемых решений за счет повышения точности решения и снижения количества ошибочных решений

• повышение оперативности, своевременности, частоты, принимаемых решений

• снижение затрат на принятие решения

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

• критерий результативности -- определяется тем влиянием результата, которое оказывает система на другие системы и внешнюю среду

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

• критерий оперативности

Понятие требования, типы требований. (№22 -- 1 к.р.)

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

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

Нефункциональные требования не определяют поведение системы, но описывают атрибуты системы или системного окружения ("в каких условиях она должна это делать, что должна учитывать").

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

Требования к системе в целом. (№23 -- 1 к.р.)

В подразделе 4.1 (требования к системе в целом) указывают:

-Требования к структуре и функционированию системы

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

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

-Требования к характеристиками взаимосвязи создаваемой системы со смежными системами.

-Требования к совместимости.

-Требования к режимам функционирования системы.

-Требования по диагностированию системы.

-Перспективы развития и модернизации системы.

Требования к функциям (задачам), выполняемым системой. (№24 -- 1 к.р.)

В подразделе «Требование к функциям (задачам)», выполняемым системой, приводят:  1) по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих взаимодействие частей системы), подлежащих автоматизации;  при создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях;  2) временной регламент реализации каждой функции, задачи (или комплекса задач);  3) требования к качеству реализации каждой функции (задачи или комплекса задач), к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов;  4) перечень и критерии отказов для каждой функции, по которой задаются требования по надежности.

Управления требованиями(№25)

Управление требованиями к программному обеспечению (англ. software requirements management) — процесс, включающий идентификацию, выявление, документирование, анализ, отслеживание, приоритезацию требований, достижение соглашения по требованиям и затем управление изменениями и уведомление соответствующих заинтересованных лиц. Управление требованиями — непрерывный процесс на протяжении всего проекта разработки программного обеспечения.

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

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

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

Функциональная модель АСОИУ.(№26 -- 1 к.р.)

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

Разработка функциональной модели включает в себя:

-Определение выполняемых системных функций и перечня решаемых задач. (Функции -- то для чего служит система, что исполняет, задачи -- что она решать для исполнения функций)

-Оптимизация структуры создаваемой системы (Например, если самыми разными отделами решается одна и та же задача, то, возможно, ее стоит выделить в отдельное исполнение и назначить отдельных людей.)

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

-Разделение функций и задач между персоналом и вычислительными средствами.

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

-Описание в самом общем виде алгоритмов и процедур обработки информации в создаваемой системе. (Нотация BPMN немного ближе к алгоритмической строгости, чем ARIS)

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

-стремление максимально формализовать и автоматизировать функции системы, насытив ее техническими средствами для сбора, передачи и обработки информации. :Это может привести к тому, что созданная модель окажется неадекватной действительности. В лучшем случае такая крайность приводит к излишним затратам и созданию малоэффективной АСОИУ. В худшем -- дискредитирует саму идею применения средств вычислительной техники для управления в рассматриваемой системе.

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

Информационно-логическая модель.(№27 -- 1 к.р.)

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

-источники информации

-входные, выходные, основные и промежуточные массивы информации

-процедуры обработки и преобразования информации

-процедуры выработки решений

-потребители информации

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

Описание и анализ потоков информации с использованием графов. (№28 -- 1 к.р.)

Основным носителем информации в информации в организационных системах являются документы. Документы как для системы в целом, так и в рамках отдельных подсистем можно разделить на входные, выходные и промежуточные. Между документами основными отношениями часто являются отношения вхождения и порядка. Отношения вхождения означает, что некоторый документ X_{j} формируется на основе докуметов:  . Отношение порядка   означает, что документ   может быть сформирован только тогда, когда закончится формирование  . Потоки информации в информационных системах образуются также движением реквизитов, показателей, различных сообщений данных. Поэтому говоря об элементах потоков информации будем иметь ввиду все вышеперечисленное. Элементам потока информации можно поставить в соответствие вершины графов   -- соединяются дугой от   к , если   является входом для  (т.е. включается в него или обязательно для его формирования). Полученный граф называют информационным графом. Матрицу смежности его будем обозначать  . Наличие такой матрицы смежности позволяет использовать строгие процедуры обработки. Будем последовательно находить степень матрицы смежности. Будем формировать матрицу смежности   до тех пор, пока не окажется, что  , а   -- такая ситуация возможна, если информационный граф не имеет замкнутых контуров (циклов с учетом направления). В противном случае нулевая матрица не будет получена никогда и показателем того, что есть контуры, будет неравенство нулевой матрицы матрице  , где  -- число вершин. ... определяется матрицей достижимости: 

Бизнес-классы в проектировании (№29)

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

..??, работник,

или функции:

проведение аттестации, ..??.

Такие классы, соответствующие объектами и процессам предметной области, будем называть бизнес-классами. Бизнес-класс предполагает вовлеченность в те или иные

?? обработки информации предметной области

или бизнес-процессы.

?? обозначают термином бизнес-логика.

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

...?? предметной области в процессах обработки информации.

Свойства бизнес-классов подразделяются на 3 группы:

сохраненяемые свойства -- им соответствуют свои поля в оперативных и справочных БД.

вычисляемые свойства -- их значения рассчитываются на основе оперативных справочных таблиц по мере необходимости в процессе реализации бизнес-логики

статистические свойства -- они сохраняются в таблицах подготовки отчестности -- предвычисленные

..?? за период

??..

ODB- классы (№30)

С т.з. реализацией бизнес-классы могут быть:

ODB-классами

--классы, для которых есть соответствующие таблицы в БД

не-ODB-классы

--служат для группировки функционала других классов (как первой, так и второй группы).

Рассмотрим ODB-класс: Во многих ситуациях каждому объекту предметной области соответствует таблица в БД и свой ODB-класс. Все действия, за исключением специально обоснованных случаев с объектами предметной области желательно осуществлять только по свойствами

??

и методов, соответствующих ODB-классов. Указанными действиями является организация ODB-класса и

??

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

Возможности каждого ODB-класса для получения или обновления значений свойств можно разделить на 3 группы:

стандартные механизмы ODB для получение свойст из таблиц (речь идет о сохраняемых свойствах).

получение сохраняемых свойств характерно для

??? и классификаторов,

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

?? свойств на основе оперативных таблиц и классификаторов. Эти метожы могут использовать как и SQ-запросы, так и более сложные

???

методы для

??

статистических свойств из таблиц подготовки отчетности на заданный период.

Бизнес-логика реализуется посредством методов бизнес-классов. Частным методом такой реализации является перекрытие виртуальных методов событий стандартных ODB-классов (update, delete и т.п.), которые вызываются автоматически для проверки

??

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

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

??,

но кроме них практически всегда будут использоваться чисто служебные

??,

не имеющие аналогов в предметной области.

::??сетевые протоколы, математические подсистем, видео-протоколы.

//Мы рассмотрели ряд вопросов, в число которых входит:

??,

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

Информационное обеспечение, основные вопросы проектирования информационного обеспечения.(№31 -- 1 к.р.)

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

-нормативно-справочную информацию -- в том числе, классификаторы информации

-массивы данных, необъодимых для решения задач

-унифицированные документы, используемые в АСОИУ

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

-принципы организации информационного обеспечения системы

-обоснование выбора носителей данных и принципы распределения информации по типам носителей

-виды и методы контроля информации в маршрутах обработки данных

-решения, обеспечивающие информационную совместимость с другими системами -управления, источниками и потребителями информации

Вопросы организации, сбора и передачи информации включают:

-проработку перечная источников и носителей информации с указанием оценки интенсивности объема потоков информации

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

Структура информационного обеспечения. (№32 -- 1 к.р.)

В ходе проектирования ИО, выполняемого совместно с пользователями-экономистами, осуществляются следующие работы:

• определяются состав показателей, необходимый для решения экономических задач, их объемно-временные характеристики и информационные связи;

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

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

• ведется организация информационного фонда; определяются состав базы данных и его организация; проектируются формы вывода результатов обработки.

Информационная база, виды файлов в информационной базе. (№33 -- 1 к.р.)

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

по этапам обработки выделяют:

-входные

-базовые

-результат

по типам носителей:

-на промежуточных (для каких-либо архивных копий или для, например, обновлений)

-на основных носителей

по составу информации:

-файлы с опреративной информацией

-файлы с постоянной информацией

по назначению:

-разделение по типу функциональных подсистем

по типу логической организации:

-файлы с линейной

-с иерархической структурой записи

-реляционные

-табличная (без применения реляционных механизмов)

по способу физической организации

-файлы с последовательным

-индексным

-и прямым способом доступа

Способы организации информационной базы. (№34 -- 1 к.р.)

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

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

Централизация управления данными и их интеграция тоже имеет ряд проблем:

-необходимость усиления контроля вводимых данных

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

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