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

Проектирование информационных систем

Информационная система (ИС) — совокупность средств обработки информации и персонала, объединенных для достижения определенных целей. С точки зрения автоматизации информационные системы можно классифицировать на: автоматизированные, ручные и автоматические. Наиболее распространены на современных предприятиях и в организациях автоматизированные системы.

Под автоматизированной информационной системой понимается организационно-техническая система, использующая автоматизированные информационные технологии в целях обучения, информационно-аналитического обеспечения научно-инженерных работ и процессов управления (computer-aided information system).

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

На текущем этапе развития общества с его развитыми информационными технологиями Вам не составит труда создать информационную систему, состоящую к примеру, из одной ПЭВМ, одного пользователя и типового набора программного обеспечения. Вопрос состоит в том, насколько правильно Вы ее создадите, будет ли ИС отвечать требованиям руководящих документов Российской Федерации в области безопасности информации. Центр комплексной защиты информации «Indefo» осуществляет проектирование автоматизированных информационных систем в соответствии с требованиями нормативных и методических документов Российской Федерации в области стандартизации и информационной безопасности.

Сотрудники центра комплексной защиты информации «Indefo» осуществляют проектирование:

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

Разработка и оформление проектной документации осуществляется в соответствии с действующими нормативными документами Российской Федерации в области стандартизации и безопасности информации.

Проектирование информационной системы ОАО Сталинград

Главная > Реферат >Информатика

Федеральное агентство по образованию

Омский государственный институт сервиса

Кафедра высшей математики и информатики

К защите допущен (а) Защищено с оценкой

«___» ___________2006г «____________»

по курсу: Проектирование информационных систем

на тему: «Проектирование информационной системы

Выполнил: студент гр. 62ПИ:

Проверила: Морарь Е.В

1. Обследование ОАО «Сталинград» 3

1.1. Функции предприятия 3

1.2. Должностные инструкции 4

2. Техническое задание 5

2.1. Общие сведения 5

2.2. Характеристика объекта автоматизации 6

2.3. Назначение и цели создания АИС 6

2.4. Основные требования к системе 6

2.5. Состав, содержание и организация работ по созданию АИС 10

2.6. Порядок контроля и приёмки системы: . 10

3. Пояснительная записка 10

3.1. Общие положения 10

3.2. Основные технические решения 11

3.3. Описание процесса деятельности 11

4. Схема функциональной структуры 11

4.1. Элементы функциональной структуры АС 11

4.2. Информационные связи с внешней средой 12

4.3. Информационные связи между элементами АС 12

5. Общее описание системы 13

6. Модель ОАО «Сталинград» AS-IS 14

7. Модель ОАО «Сталинград» TO-BE 16

8. Описание информационного обеспечения системы 17

8.1. Состав информационного обеспечения 17

8.2. Организация сбора и передачи информации 17

8.3. Организация внемашинной информационной базы 18

Основным направлением деятельности организации является производство и реализация цементобетонной продукции. ОАО «Сталинград» является предприятием цементобетонной промышленности.

Целью данной работы является разработка проекта ИС предприятия ОАО «Сталинград».

Для достижения поставленной цели необходимо решить следующие задачи:

Провести предпроектное обследование предметной области

Построить модель предметной области «как есть» и выявить существующие недостатки.

Построить модель «как будет» и предложить рекомендации по устранению выявленных недостатков предприятия.

Описать техническое задание.

Разработать интерфейс пользователя в виде совокупности входных и выходных форм для выбранной СУБД.

Для создания модели деятельности предприятия будем использовать CASE-средство BPwin 4.0. В модели будут созданы контекстная диаграмма деятельности, диаграммы декомпозиции первого, второго и третьего уровней, диаграмма организационно-штатной структуры, диаграмма Swim Lane и дерево узлов.

Для создания интерфейса пользователя используется интегрированная среда разработки Borland Delphi.

1. Обследование ОАО «Сталинград»


1.1. Функции предприятия

Производство тротуарной плитки

Производство тротуарных бордюров

Реализация произведенной продукции

1.2. Должностные инструкции

В соответствии с Федеральным законом от 26.12.1995 г. № 208 – ФЗ «Об открытых акционерных обществах» высшим органом управления ОАО «Сталинград» является общее собрание акционеров.

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

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

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

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

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

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

2. Техническое задание


2.1. Общие сведения

Полное наименование автоматизированной информационной системы (АИС): открытое акционерное общество «Сталинград».

Условное обозначение системы: АИС ОАО «Сталинград». Основание для создания АИС: Должностные инструкции, технико-экономическое обоснование, журнал по технике безопасности, гражданский кодекс РФ.

Наименование разработки: Деятельность компании ОАО «Сталинград».

Сроки начала и окончания работы по созданию АИС:

Начало разработки: 1.09.2009

Окончание разработки: 29.12.2009

2.2. Характеристика объекта автоматизации

Описание состава объекта автоматизации: Предприятие цементобетонной промышленности по производству и реализации цементобетонной продукции.

Характеристики входных и выходных потоков: В качестве входных «ресурсов» выступают документация, информация, кадры. Выходом (результатом) является готовая продукция, документы.

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

2.3. Назначение и цели создания АИС

Назначение АИС: Определение функций деятельности ОАО «Сталинград» (функции управления и функции основной деятельности компании).

Основная цель создания АИС: Автоматизация процессов предприятия.

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

2.4. Основные требования к системе

2.4.1. Требования к системе в целом

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

АИС ОАО «Сталинград» Уровень 0. АИС ОАО «Сталинград» Уровень 1.

АИС управления предприятием;

АИС основной деятельности;

АИС обеспечения предприятия.

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

Источник — АИС управления компанией

Приемник — АИС основной деятельности и АИС обеспечения.

Требования к характеристикам взаимосвязей создаваемой системы со смеж­ными системами, требования к ее совместимости, способы обмена информации

Отдел работы с персоналом

Принимает информацию о направлении на работу

через поток Кадры предприятия

Принимает информацию о приказах о приёме на работу

через поток Приказы о приёме на работу

Принимает информацию о правилах производства

через поток Правила и процедуры

Принимает информацию о документах

через поток Документация

Сотрудники, работающие с клиентами

Принимают информацию от клиентов

через поток Информация

через поток Документы и отчёты

Требования к численности и квалификации персонала системы и режиму его работы: персонал должен иметь навыки работы с ПК, специальным ПО.

Требования к показателям назначения:

Требования к надежности: система отказоустойчива

Требования к безопасности: парольная защита

Требования к функционированию АИС: обеспечение эффективной бесперебойной работы системы.

Требования к эргономике и технической эстетике:

Требования к транспортабельности для подвижных АС:

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

Требования к сохранности информации: информация должна сохраняться автоматически каждую минуту времени.

Требования к средствам защиты от внешних воздействий:

Требования к патентной чистоте:

Требования к стандартизации и унификации:

2.4.2. Требования к функциям

АИС управления предприятием Уровень 2.

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

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

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

Работа с персоналом

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

Маркетинг и развитие

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

АИС основной деятельности Уровень 2

Покупка необходимого сырья

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

Производство цементобетонной продукции

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

  Договор о целевом обучении 2018

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

АИС обеспечения Уровень 2

Отдел обеспечения сырьем

Имеет функции: обеспечение производства необходимым сырьём (песок, цемент, пластификатор, щебень).

Имеет функции: Проведение ремонта, проверка состояния предприятия, проведение санитарных мероприятий, проверка соблюдения санитарных норм.

Отдел содержания склада

Имеет функции: Приём продукции на склад, отпуск продукции со склада, проведение ревизий на складе.

Требования к качеству выполнения функции АИС

Перечень функций управления и решаемых задач:

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

Работа с персоналом

Маркетинг и развитие

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

Функции основной деятельности:

Покупка необходимого сырья. Входные параметры – список необходимого сырья, информация, документация. Выходом является необходимое сырье и документация.

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

Реализация цементобетонной продукции. Входные параметры – заказы клиентов, информация, документация. Выходом является готовая продукция и документация

Отдел обеспечения сырьём.

Отдел содержания предприятия.

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

2.4.3. Требования к видам обеспечения АИС

Требования к математическому обеспечению:

Требования к информационному обеспечению: возможность работать в любой операционной системе; используемые средства проетирования — BPWIN

Перечень входных потоков:

Информация (заказы клиентов),

Перечень выходных потоков:

Заявка на производство.

Требования к лингвистическому обеспечению: язык SQL

Требования к программному обеспечению: SQL Server

Требования к техническому обеспечению: аппаратное

Требования к метрологическому обеспечению:

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

2.5. Состав, содержание и организация работ по созданию АИС

Перечень стадий и этапов выполнения работ:

Проведение обследования деятельности предприятия.

Разработка системного проекта

Разработка системы автоматизации

2.6. Порядок контроля и приёмки системы: .

2.7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу в действие: .

2.8. Требования к документированию: .

Полное наименование: Техническое задание на проектирование автоматизированной информационной системы от 10.06.2009 НИР: не определены.

3. Пояснительная записка


3.1. Общие положения

Наименование системы: «ОАО «Сталинград»».

Документы, на основании которых проводится разработка:

— Гражданский кодекс РФ (от 12 августа 1996 года).

Документ: О создании АИС «ОАО «Сталинград »».

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

1.1. Проведение обследования — начало этапа: 01.06.2009г.

конец этапа: 01.09.2009г.

1.2. Создание модели АИС — начало этапа: 09.09.2009г.

конец этапа: 029.12.2009г.

3.2. Основные технические решения

Структура системы, подсистем

См. 3.4.1. Требования к системе в целом

Взаимодействие со смежными системами, обеспечение совместимости

См. 3.4.1. Требования к системе в целом

3.3. Описание процесса деятельности

Распространение информации о деятельности предприятия.

Распространение информации о продукции компании.

4. Схема функциональной структуры


4.1. Элементы функциональной структуры АС

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

Работа с персоналом

Маркетинг и развитие

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

Функции основной деятельности:

Покупка необходимого сырья. Входные параметры – список необходимого сырья, информация, документация. Выходом является необходимое сырье и документация.

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

Реализация продукции. Входные параметры – заказы клиентов, информация, документация. Выходом является готовая продукция и документация.

Отдел обеспечения сырьём.

Отдел содержания предприятия.

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

4.2. Информационные связи с внешней средой

Открытое акционерное общество «Сталинград» взаимодействует со смежными системами: клиентами.

Клиент подает заявку о намерении приобрести продукцию.

Осуществляется проверка, а затем внесение клиента в БД

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

Осуществляется погрузка продукции.

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

Также происходит взаимодействие с государственными органами (посредством инструкций и отчётов) и поставщиками.

4.3. Информационные связи между элементами АС

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

Проектирование информационных систем

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

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

Проектирование охватывает три базовых области будущей ИС:

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

Содержание и этапы проектирования

Поскольку процесс проектирования не имеет четких границ, его задачи прямо зависят от того, какую цель преследует заказчик. Цели и задачи находят отражение в Техническом задании на проектирование.

В общем виде в рамках проектирования:

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

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

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

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

Разработка информационной системы

Разработка информационной системы (ИС) начинается с переговоров между заказчиком и исполнителем.

Основными этапами разработки информационной системы являются:

  1. Предварительный этап
  2. Сбор требований
  3. Проектирование
  4. Реализация
  5. Подготовка ИС к эксплуатации
  6. Опытно-промышленная эксплуатация
  7. Сопровождение и развитие системы

Предварительный этап

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

В уставе проекта определяются принципиальные моменты, которые связаны с процессом разработки и внедрения ИС:

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

Попробуй обратиться за помощью к преподавателям

Сбор требований

На данном этапе проводится систематизация требований и пожеланий к разрабатываемой ИС, проводится анализ входной и выходной документации.

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

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

В результате проектирования оформляется технический (концептуальный) проект с описанием:

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

Задай вопрос специалистам и получи
ответ уже через 15 минут!

Этап выполнения требований к ИС, которые были изложены в Техническом задании и Техническом проекте. Выполняется разработка всех необходимых программных компонентов, создается структура базы данных, производится установка, настройка и тестирование всех компонентов ИС и т.п.

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

Подготовка ИС к эксплуатации

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

Опытно-промышленная эксплуатация

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

Сопровождение и развитие системы

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

Так и не нашли ответ
на свой вопрос?

Просто напиши с чем тебе
нужна помощь

Проектирование информационных систем

Процесс проектирования ИС и ИТ делится на три этапа:

Концептуальное проектирование – разработка модели предметной области:

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

анализ информационных потребностей пользователей разрабатываемой системы.

Результат – концептуальная модель предметной области.

(«инфологическое проектирование», «инфологическая модель»)

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

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

В частности, модель предметной области разрабатываемой системы должна быть представлена в терминах логической модели данных выбранной СУБД.

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

Стадия физического проектирования системы заключается в

выборе способа организации базы данных в среде хранения выбранной СУБД и разработке спецификации внутренней схемы,

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

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

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

Общие требования к методологии и технологии проектирования

Методология проектирования составляет основу проекта любой ИС.

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

Технология проектирования, разработки и сопровождения ИС ‑ общие требования:

поддержка полного жизненного цикла;

достижение целей разработки ИС с заданным качеством и в установленное время;

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

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

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

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

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

стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

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

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

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

механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов и т.д.)

правила проверки проектных решений на непротиворечивость и т. д.

Стандарт оформления проектной документации должен устанавливать:

комплектность, состав и структуру документации на каждой стадии проектирования;

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

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

требования к настройке средств для подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

правила использования клавиатуры и мыши;

правила оформления текстов помощи;

перечень стандартных сообщений;

правила обработки реакции пользователя.

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

4. ОСНОВЫ АНАЛИЗА И ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

4.1. Особенности анализа и проектирования крупных систем

Тенденции развития современных информационных технологий приводят к постоянному возрастанию сложности разрабатываемых информационных систем. Для них характерны следующие особенности [14]:

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

— наличие совокупности тесно взаимодействующих компонентов (подсистем);

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

— необходимость интеграции существующих и вновь разрабатываемых подсистем;

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

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

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

— изменение или уточнение потребностей пользователей в процессе разработки и эксплуатации системы.

Непременным условием успешной реализации информационной системы является четкое и как можно более полное формирование требований на разработку системы, а также ее адекватное описание на стадии проектирования. Согласно [15]: «На обнаружение ошибок, допущенных на этапе анализа и проектирования, расходуется примерно в 2 раза больше времени, а на их исправление – примерно в 5 раз, чем на ошибки, допущенные на более поздних стадиях».

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

4.2. Документы, содержащие требования на разработку системы

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

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

Рис. 4.1. Пример календарного плана

Как было отмечено выше, техническое задание (ТЗ) является основным документом, определяющим требования и порядок создания (развития или модернизации) системы. Несмотря на то, что согласно [9, 13] ТЗ составляется после заключения договора, нередко оно должно быть подготовлено разработчиком еще до его подписания.

Состав, содержание, правила оформления этого документа устанавливаются ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы» [3]. ТЗ, как правило, содержит следующие разделы:

— общие сведения (наименование системы; наименование предприятий разработчика и заказчика с их реквизитами; перечень документов, на основании которых создается система, плановые сроки начала и окончания работы и т. д.);

— назначение и цели создания (развития) системы;

— характеристика объектов автоматизации;

o к системе в целом:

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

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

• требования к надежности;

• требования к эргономике и технической эстетике;

• требования к транспортабельности для подвижных АС;

• требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы;

• требования к защите информации от несанкционированного доступа;

• требования по сохранности информации при авариях;

• требования к защите от влияния внешних воздействий;

• требования к патентной чистоте;

• требования по стандартизации и унификации;

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

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

• временной регламент реализации каждой функции (задачи или комплекса задач);

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

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

o к обеспечению:

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

информационному – совокупности форм документов, классификаторов, нормативной базы и реализованных решений по объемам, размещению и формам существования информации;

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

  Квартира в наследство и брак

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

техническому – совокупности всех технических средств, используемых при функционировании системы;

метрологическому – совокупности норм, правил и методик выполнения измерений;

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

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

— состав и содержание работ по созданию системы;

— порядок контроля и приемки системы;

— требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;

— требования к документированию;

— источники разработки – документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

Техническое задание может включать приложения, например:

— расчет ожидаемой эффективности системы;

— оценку научно-технического уровня системы;

— перечень основных входных и выходных форм и т.д.

Рис. 4.2. Пример титульного листа и оглавления технического задания

Грамотно составленное ТЗ является залогом успешной реализации проекта. В некоторых организациях, обычно имевших «печальный» опыт недооценки этого важного документа, существует практика составления расширенного и более детального технического задания. Особое внимание при его подготовке следует уделить полному и точному описанию требований, полный перечень которых приведен в [3]. В противном случае разработчик может создать систему, которая не нужна заказчику или не соответствует всем его ожиданиям.

Наиболее полно и точно должны быть определены требования к системе в целом (требования к структуре и функционированию системы; к численности и квалификации персонала системы и режиму его работы; к защите информации от несанкционированного доступа; к патентной чистоте и др.) и ее функциям (требования к составу и назначению подсистем; к режимам функционирования системы и т. д.). Заказчик и разработчик должны определиться, какие функции будет выполнять система (какие задачи и как она будет решать), а какие – не будет.

Требования к видам обеспечения, в отличие от предыдущих, не должны быть слишком жесткими. Они должны быть составлены разработчиком так, чтобы у него была возможность для маневра. По возможности рекомендуется эти требования декларировать без указания конкретных способов и методов решения задач, языков программирования и СУБД, технических устройств и т. п. Например, «Формирование файлов исходных данных и результатов расчета интервалов должны выполняться в достаточном объеме и форматах, необходимых для их автоматического использования в АРМ инженера-графиста ГВЦ МПС РФ». В то же время для некоторых видов обеспечения или документированию у заказчика могут быть жесткие требования по их реализации, например:

— к математическому обеспечению — «Расчет движения поездов должен выполняться в соответствии с действующими Правилами тяговых расчетов»;

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

— к документированию — «Подлежащие разработке и сдаче комплекты и виды документов:

o Общая постановка задачи;

o Описание комплекса программ;

o Описание информационной технологии;

o Руководство пользователя;

o Руководство по инсталляции;

o Руководство администратора системы;

o Руководство администратора БД;

o Программа и методика испытаний;

o Руководство по организации сопровождения.»

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

4.3. Основные принципы проектирования

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

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

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

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

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

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

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

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

7. Принцип логической независимости заключается в концентрации внимания на логическом проектировании в целях обеспечения независимости от физической реализации.

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

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

10. Принцип информационной закрытости (инкапсуляции) (англ. encapsulation – изоляция, герметизация). Согласно этому принципу содержание внутреннего устройства элементов системы должно быть скрыто друг от друга. Этот принцип предписывает обмен информацией между элементами системы только в минимально необходимом объеме и ограничение доступа к операциям и данным каждого из них.

11. Принцип полиморфизма (англ. polymorphy) – принцип построения элементов модели таким образом, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Другое определение полиморфизма – это свойство родственных элементов решать сходные по смыслу проблемы разными способами.

4.4. Классификация моделей информационной системы

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

Классифицировать модели можно по следующим признакам.

1. По строгости описания:

неформальные – представлены в неструктурированном виде и дают общее представление о моделируемой системе. Недостаточно наглядны (особенно при сложном взаимодействии между объектами) и неприемлемы для какого-либо количественного анализа и обработки автоматическими средствами;

o описательные – модели, где сведения представлены с помощью специальных документов (бланки, формы, анкеты, таблицы и т. п.);

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

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

2. По степени физической реализации (логической независимости):

логические – описывают состав, структуру, состояние или поведение элементов системы без привязки к конкретным языкам или средам программирования, СУБД, техническим средствам и т. д. При разработке системы это обеспечивает гибкость в выборе и быстрый переход с одной программно-аппаратной платформы на другую;

физические – описывают элементы системы в соответствии с принятой физической реализацией этих элементов (языками программирования, СУБД, устройствами, и т. д.);

3. По степени отображения динамики происходящих процессов:

статические – описывают состав и структуру системы;

динамические – описывают поведение системы и/или ее отдельных элементов. Как правило, такие модели описывают порядок действий или состояния системы и переходы между ними. Другими словами, в этих моделях явно или не явно присутствует понятие времени;

4. По отображаемому аспекту:

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

информационные – описывают состав и структуру данных (реляционных БД, классов и др.). Относятся к статическим моделям;

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

компонентные – описывают состав и структуру программных и аппаратных средств. Относятся к статическим моделям;

смешанные – характеризуют сразу несколько аспектов системы (например, диаграммы потоков данных отображают работы, накопители данных, подсистемы) и т.д.

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