Методы и средства проектирования ИС и технологий
Поможем в ✍️ написании учебной работы
Поможем с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой

Методы и средства проектирования ИС и технологий

 

1. Назовите принципы системного подхода к созданию ИС.

Принцип системности.

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

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

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

Принцип развития (открытости)

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

Принцип современности

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

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

Принцип стандартизации (унификации)

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

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

Принцип эффективности

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

Какие виды ИС существуют?

Как классифицируются средства проектирования ИС?

Существует три основных метода проектирования ИС:

 

Каноническое проектирование.

 

Типовое проектирование.

 

Проектирование с помощью Case-технологий.

 

 

Типовое проектирование ИС.

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

Типовое проектное решение (ТПР)- это тиражируемое (пригодное к многократному использованию) проектное решение. Принятая классификация ТПР основана на уровне декомпозиции системы. Выделяются следующие классы ТПР:

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

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

· объектные ТПР - типовые отраслевые проекты, которые включают полный набор функциональных и обеспечивающих подсистем ИС.

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

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

Критерии оценки ППП делятся на следующие группы:

· назначение и возможности пакета;

· отличительные признаки и свойства пакета;

· требования к техническим и программным средствам;

· документация пакета;

· факторы финансового порядка;

· особенности установки пакета;

· особенности эксплуатации пакета;

· помощь поставщика по внедрению и поддержанию пакета;

· оценка качества пакета и опыт его использования;

· перспективы развития пакета.

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

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

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

Типовая ИС в специальной базе метаинформации - репозитории - содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария (например, SAP Business Engineering Workbench (BEW), BAAN Enterprise Modeler). Возможно также создание системы на базе типовой модели ИС из репозитория, который поставляется вместе с программным продуктом и расширяется по мере накопления опыта проектирования информационных систем для различных отраслей и типов производства.

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

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

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

Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия (BAAN Enterprise Modeler), либо путем автоматизированной адаптации этих моделей в результате экспертного опроса (SAP Business Engineering Workbench).

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

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

Модель бизнес-функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия (подробное описание см. в разделе "Анализ и моделирование функциональной области внедрения ИС").

Модель бизнес-процессов отражает выполнение работ для функций самого нижнего уровня модели бизнес-функций (подробное описание см. в разделе "Спецификация функциональных требований к ИС"). Для отображения процессов используется модель управления событиями (ЕРС - Event-driven Process Chain). Именно модель бизнес-процессов позволяет выполнить настройку программных модулей - приложений информационной системы в соответствии с характерными особенностями конкретного предприятия.

Модели бизнес-объектов используются для интеграции приложений, поддерживающих исполнение различных бизнес-процессов (подробное описание см. в разделе "Этапы проектирования ИС с применением UML").

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

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

Реализация типового проекта предусматривает выполнение следующих операций:

· установку глобальных параметров системы;

· задание структуры объекта автоматизации;

· определение структуры основных данных;

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

· описание интерфейсов;

· описание отчетов;

· настройку авторизации доступа;

· настройку системы архивирования.

CASE-технологии.

CASE-средства автоматизации – это методологий структурного системного анализа и проектирования ИС. Основные компоненты интегрированного CASE—пакета: 1) средства централизованного хранения всей информации о проектируемом программном обеспечении в течение всего жизненного цикла (репозитарий);2) средства ввода; 3) средства анализа; 4) средства вывода — требования к компонентам и к их поддержке.

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

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

Помимо перечисленных основополагающих принципов графической ориентации, интеграции и

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

CASE-средств лежат следующие положения:

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

2. Широкое использование базовых программных средств, получивших массовое распространение в других приложениях (БД и СУБД, компиляторы с различных языков программирования, отладчики, документаторы, издательские системы, оболочки экспертных систем и базы знаний, языки четвертого поколения и др).

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

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

5. Доступность для разных категорий пользователей.

6. Рентабельность.

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

Интегрированный CASE-пакет содержит четыре основные компонента:

1. Средства централизованного хранения всей информациио проектируемом ПО в течении всего

ЖЦ (репозитарий) являются основой CASE-пакета. Соответствущая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации. Репозитарий должен обеспечивать:

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

2. Средства ввода предназначеныдля ввода данных в репозитарий, а также для организации взаимодействия с CASE-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т.д.

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

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

Все перечисленные компоненты в совокупности должны:

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

Таким образом, CASE-систем – это метод и средство программной инженерии, необходимое для контроля процесса создания ИС, гарантированию достижений целей разработки и соблюдений различных ограничений (бюджетных, временных и пр.).

 

Жизненный цикл ИС.

DFD -диаграмма.

IDEF 0 диаграмма.

IDEF 3 - диаграмма.

Методы и средства проектирования ИС и технологий

 

1. Назовите принципы системного подхода к созданию ИС.

Принцип системности.

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

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

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

Дата: 2019-02-25, просмотров: 735.