Материал: Методы и модели проектирования соврем. ИС(ЛР, 09.05.01)

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6

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

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

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

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

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

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

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

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

диаграмм);

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

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

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

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

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

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

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

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

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

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

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

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

Разработка предложений по автоматизации предприятия. На осно-

вании системного проекта осуществляется:

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

ятия и способов взаимодействия между ними;

7

анализ применимости существующих систем управления пред-

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

выбору такой системы;

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

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

разработка требований к программным средствам;

разработка предложений по этапам и срокам реализации.

Разработка технического проекта. На данном этапе на основе сис-

темного проекта и принятых решений по автоматизации осуществляется про-

ектирование системы. Фактически здесь дается ответ на вопрос: «Как мы бу-

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

ваниям?». Этот этап разделяется на:

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

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

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

ду ними и внешними объектами;

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

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

При этом происходит расширение системного проекта:

за счет его уточнения;

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

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

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

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

8

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

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

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

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

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

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

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

можностями.

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

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

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

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

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

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

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

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

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

9

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Генерация документации. Вся документация по проекту генерируется автоматически на базе репозитория (как правило, в соответствии с требова-

ниями действующих стандартов). Несомненное достоинство CASE-

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

10

Источник: https://studfile.net/preview/16408801/