Методы и модели проектирования современных информ.систем (лаб

УДК 004.43

Лапшина, М.Л., Лапшин Д.Д. «Методы и модели проектирования современных информационных систем» [Текст]: методические указания к лабораторным работам для студентов по направлению подготовки 09.04.02 – Информационные системы и технологии / М.Л. Лапшина, Д.Д. Лапшин; М-во образования и науки РФ, ФГБОУ ВО «ВГЛТУ им. Г.Ф. МОРОЗОВА». – Воронеж, 2016. – 76 с.

Методические указания разработаны в соответствии с решением кафедры вычислительной техники и информационных систем

Составитель: д.т.н., профессор каф. ВТ и ИС М.Л. Лапшина

Методические указания утверждены на заседании кафедры ВТ и ИС 13.01.2016 г., протокол № 7.

2

пользование средств быстрой разработки с использованием объектно-

ориентированного подхода и библиотек готовых компонент третьих фирм.

Стадия внедрения. На этой стадии производится опытная эксплуата-

ция системы, выявление и исправление ошибок, обучение пользователей (по-

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

сение изменений согласно предложениям, внесенным пользователями.

Стадия промышленной эксплуатации. Когда все подсистемы отла-

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

разрабатывалась.

Стадия модернизации. По прошествии некоторого времени, когда ус-

ловия ведения бизнеса меняются, встает вопрос внесения изменений в экс-

плуатируемую систему. Если система была спроектирована с учетом после-

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

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

полняется два вида работ: прежде всего – это элементарное наведение поряд-

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

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

Process Reengineering). В конечном итоге речь идет об автоматизации, по-

скольку в современном мире трудно придумать эффективные бизнес-

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

5

Стадия проектирования информационных систем На стадии проек-

тирования выполняется ряд обязательных этапов. Обследование деятельно-

сти предприятия. На этом этапе осуществляется: определение организаци-

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

определение основных задач деятельности предприятия;

проведение опросов сотрудников с целью построения функцио-

нальной модели деятельности «как есть» и, в случае эксплуатации какой-

либо ИС, модели логической организации данных.

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

информационные потоки (как электронные, так и на традиционных носите-

лях) между ними и внутри них. Длительность этапа зависит как от размеров предприятия, так и от количества системных аналитиков, участвующих в проекте, и на практике составляет 1-2 недели. В некоторых случаях обследо-

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

деятельность которых достаточно консервативна. Для динамичных организа-

ций такие сроки чреваты тем, что к концу обследования аналитики будут об-

ладать устаревшей информацией. По окончании обследования строится и со-

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

Разработка системного проекта. Предварительным этапом здесь яв-

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

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

разработка структурной функциональной модели деятельности (методологии

IDEF0, DFD – средства BPwin, Design/IDEF и др.);

разработка информационной модели предприятия (методологии

IDEF1X, ERD – средства ERwin, Database Designer, Design/IDEF, S-Designеr);

разработка событийной модели предприятия (метод динамиче-

ского функционального анализа на основе сетей Петри различного вида).

6

Построение модели «как должно быть» является изменением техноло-

гий и переосмыслением бизнес-процессов (BPR). Создание системного про-

екта (модели требований к будущей системе) является первой фазой разра-

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

полную функциональную модель требований к будущей системе;

комментарии к функциональной модели (спецификации процес-

сов нижнего уровня в текстовом виде);

пакет отчетов и документов по функциональной модели, вклю-

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

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

концептуальную модель интегрированной базы данных (пакет

диаграмм);

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

предложения по штатной структуре для поддержки системы.

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

увидеть и скорректировать будущую систему до того, как она бу-

дет реализована физически;

уменьшить затраты на разработку и внедрение системы;

оценить разработку по времени и результатам;

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

казчиками, пользователями, разработчиками);

улучшить качество разрабатываемой системы.

Системный проект полностью независим и отделяем от конкретных

разработчиков.

7

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

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

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

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

CASE-технологии. CASE-технология представляет собой совокуп-

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

томатизации. CASE-технология – это инструментарий для системных анали-

тиков, разработчиков и программистов, заменяющий бумагу и карандаш компьютером, автоматизируя процесс проектирования и разработки ПО.

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

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

можностями.

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

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

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

страничные описания), позволяющими заказчику участвовать в процессе раз-

работки, а разработчикам – общаться с экспертами предметной области, раз-

делять деятельность системных аналитиков, проектировщиков и программи-

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

9

Единая БД проекта. Основа CASE-технологии – использование базы данных проекта (репозитория) для хранения всей информации о проекте, ко-

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

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

Интеграция средств. На основе репозитория осуществляется интегра-

ция CASE-средств и разделение системной информации между разработчи-

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

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

Поддержка коллективной разработки и управления проек-

том. CASE-технология поддерживает групповую работу над проектом, обес-

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

екта для их развития и/или модификации, а также планирование, контроль,

руководство и взаимодействие, т.е. функции, необходимые в процессе разра-

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

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

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

телей и устраивает его.

10