Основные принципы моделирования АИС

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

Общесистемные принципы создания АС определены РД 50-680-88. Создание АС должно осуществляться на основе принципов системности, совместимости, стандартизации (унификации), развития (открытости) и эффективности.

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

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

Принцип стандартизации (унификации) состоит в том, что подсистемы и компоненты системы должны быть по возможности типовыми. Этот принцип должен реализовываться путем:

создания единой базы данных;

использования единого информационного обеспечения;

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

Принцип развития (открытости) состоит в том, что АС должна создаваться как развивающаяся система, допускающая пополнение, совершенствование и обновление подсистем и компонентов. Этот принцип должен реализовываться за счет открытой структуры всех подсистем АС. Развитие системы будет осуществляться путем пополнения ее новыми подсистемами и компонентами, модернизации действующих подсистем и компонентов, обновления используемых средств вычислительной техники более совершенными.

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

Основные положения по созданию и функционированию АС приведены в приложении 2 РД 50-680-88.

Процесс создания АС представляет собой совокупность упорядоченных во времени, взаимосвязанных, объединенных в стадии и этапы работ, выполнение которых необходимо и достаточно для создания АС, соответствующей заданным требованиям. Стадии и этапы создания АС в общем случае приведены в ГОСТ 34.601-90. Стадии работ:

формирование требований к АС;

разработка концепции АС;

техническое задание;

эскизный проект;

технический проект;

рабочая документация;

ввод в действие;

сопровождение АС.

Содержание работ на каждой стадии и этапе приведено в приложении 1 ГОСТ 34.601-90, перечень организаций, участвующих в работах по созданию АС–в приложении 2 этого ГОСТ.

ГОСТ 34.602–89 устанавливает состав, содержание, правила оформления, порядок разработки, согласования и утверждения документа “Техническое задание на создание (развитие или модернизацию) автоматизированной системы”. Проект ТЗ на АС разрабатывает организация-разработчик системы-с участием заказчика на основании технических требований (заявки, тактико-технического задания и т.п.). При необходимости, разработчик ТЗ и заказчик осуществляют согласование проекта ТЗ с органами государственного надзора и заинтересованными организациями. Утверждение ТЗ осуществляют руководители предприятий (организаций) разработчика и заказчика АС.

ГОСТ 34.201–89 определяет виды, наименования, комплектность и обозначение документов, разрабатываемых на стадиях создания АС (в общем случае), а РД 50-34.698-90–требования к содержанию этих документов. Необходимо помнить, что в ТЗ на АС разработчик и заказчик всегда должны уточнять окончательный состав документов по конкретной АС.

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

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

фонда информации;

системы классификации и кодирования информации;

системы документации.

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

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

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

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

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

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

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

Порядок придания юридической силы выходным документам системы подробнее рассмотрен в разделах 3.4 и 3.5 настоящего пособия и определен рядом нормативных документов:

Государственный стандарт Российской Федерации ГОСТ Р 6.30-97 "Унифицированная система организационно-распорядительной документации. Требования к оформлению документов";

Государственный стандарт Российской Федерации ГОСТ 6.10.4-84 "Придание юридической силы документам на машинном носителе и машинограмме, создаваемым средствами вычислительной техники. Основные положения";

Методические рекомендации по оформлению документов на основе ГОСТ Р 6.30-97 "Унифицированная система организационно-распорядительной документации. Требования к оформлению документов", разработанные Всероссийским научно-исследовательским институтом документоведения и архивного дела (ВНИИДАД), 1998.

Современное ОПО обеспечивает автоматическую запись фамилии (по паролю) разработчика электронного документа, даты его создания или корректировки. В некоторых АС эти реквизиты автоматически распечатываются в выходных документах.

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

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

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

Решения по всем вышеназванным вопросам должны быть отражены на концептуальном уровне уже на стадии разработки ТЗ на АС.

На последующих стадиях создания АС (эскизного, технического проектирования, разработки документации и т.д.) разработчик и привлеченные организации реализуют решения, принятые в ТЗ, с участием и под контролем заказчика.

На стадиях эскизного и технического проектирования должны быть выполнены, как правило, следующие работы:

принятие окончательных решений по составу подсистем и задач АС;

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

принятие окончательных решений по организациям–поставщикам СПО, содержанию адаптации СПО, оформление хозяйственных договоров на адаптацию программ с оформлением технических заданий;

адаптация СПО;

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

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

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

разработка эксплуатационных документов системы и ее частей;

разработка схем монтажа технических средств;

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

оформление документов на поставку недостающих программно-технических средств.

На стадии ”Ввод в действие” должны быть выполнены следующие работы:

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

подготовка персонала;

комплектация программно-технических средств, расширение объемов оперативной и внешней памяти ранее приобретенных ПК;

создание систем управления, защиты и доступа АРМ;

строительно-монтажные работы;

пусконаладочные работы;

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

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

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

проведение приемочных испытаний, оформление акта о приемке АС в постоянную эксплуатацию.

На стадии ”Сопровождение системы” должны быть выполнены следующие работы:

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

послегарантийное обслуживание в случае обнаружения недостатков.

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

Продолжительность опытной эксплуатации с момента подписания акта сдачи системы должна быть не менее 3 месяцев.

Состав приемочной комиссии по приемке АС в целом утверждается руководителем организации-заказчика.

.До ввода в действие АС необходимо выполнить следующие основные организационные мероприятия:

назначить ответственного исполнителя работ для создания и ввода в действие АС;

ввести в штатное расписание системного программиста и инженера по автоматике и телемеханике (или оформить хозяйственные договора со сторонними специалистами) для создания и обеспечения качественной подготовки ЛВС к вводу в действие;

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

решить вопросы финансирования работ.

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

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

годовой экономический эффект;

расчетный коэффициент эффективности капитальных затрат на разработку и внедрение АСУ;

срок окупаемости капитальных затрат на разработку и внедрение АСУ.

К основным частным показателям экономической эффективности относят:

годовую экономию;

снижение издержек производственно-хозяйственной деятельности на объекте управления в результате разработки и внедрения АСУ;

повышение производительности труда;

экономию по видам ресурсов;

высвобождение работающих;

повышение качества выпускаемой продукции.

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

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

6. Порядок проектирования АИС
7Cтадии проектирования АИС.

Итак, мы выбрали метод, которым будем руководствоваться при проектировании автоматизированной информационной системы. Теперь нам необходимо спланировать комплекс работ по созданию нашей системы в соответствии с типовыми этапами разработки АИС, краткая характеристика которых приведена в табл.1., а последовательность трансформации бизнес модели в объекты базы данных на рис.1.

Таблица 1.Этапы проектирования АИС и их характеристики.

№	Наименование этапа	Основные характеристики
	Разработка и анализ бизнес - модели	Определяются основные задачи АИС, проводится декомпозиция задач по модулям и определяются функции с помощью которых решаются эти задачи. Описание функций осуществляется на языке производственных (описание процессов предметной области), функциональных (описание форм обрабатываемых документов) и технических требований (аппаратное, программное, лингвистическое обеспечение АИС). Метод решения: Функциональное моделирование. Результат: 1.Концептуальная модель АИС, состоящая из описания предметной области, ресурсов и потоков данных, перечень требований и ограничений к технической реализации АИС. 2.Аппаратно-технический состав создаваемой АИС.
	Формализация бизнес - модели, разработка логической модели бизнес -процессов.	Разработанная концептуальная модель формализуется, т.е. воплощается в виде логической модели АИС. Метод решения: Разработка диаграммы "сущность-связь" (ER (Entity-Reationship) - CASE- диаграммы). Результат: Разработанное информационное обеспечение АИС: схемы и структуры данных для всех уровней модульности АИС, документация по логической структуре АИС, сгенерированные скрипты для создания объектов БД.
	Выбор лингвистического обеспечения, разработка программного обеспечения АИС.	Разработка АИС: выбирается лингвистическое обеспечение (среда разработки - инструментарий), проводится разработка программного и методического обеспечения. Разработанная на втором этапе логическая схема воплощается в реальные объекты, при этом логические схемы реализуются в виде объектов базы данных, а функциональные схемы - в пользовательские формы и приложения. Метод решения: Разработка программного кода с использованием выбранного инструментария. Результат: Работоспособная АИС.
	Тестирование и отладка АИС	На данном этапе осуществляется корректировка информационного, аппаратного, программного обеспечения, проводится разработка методического обеспечения (документации разработчика, пользователя) и т.п. Результат: Оптимальный состав и эффективное функционирование АИС. Комплект документации: разработчика, администратора, пользователя.
	Эксплуатация и контроль версий	Особенность АИС созданных по архитектуре клиент сервер является их многоуровневость и многомодульность, поэтому при их эксплуатации и развитии на первое место выходят вопросы контроля версий, т.е. добавление новых и развитие старых модулей с выводом из эксплуатации старых. Например, если ежедневный контроль версий не ведется, то в как показала практика, БД АИС за год эксплуатации может насчитывать более 1000 таблиц, из которых эффективно использоваться будет лишь 20-30%. Результат: Наращиваемость и безизбыточный состав гибкой, масштабируемой АИС