Файл: Конспект лекций по дисциплине устройство и функционирование информационных систем.doc

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

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

Методики проектирования

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

Объектные методики рассматривают моделируемую организацию как набор взаимодействующих объектов - производственных единиц.

Функциональные методики, наиболее известной из которых является методика IDEF, рассматри­вают организацию как набор функций, преобразующий поступающий поток информации в выходной поток.

Функциональная методика IDEF0

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

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

Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.

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


Рисунок 11 - Функциональный блок
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональ­ным блоком или оказывает иное влияние на функцию

---

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

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

Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип деком­позиции применяется при разбиении сложного процесса на составляющие его функции.

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

Модель IDEF0 всегда начинается с представления системы как единого целого - одного функци­онального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой. В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).


Вопросы для самоконтроля:

1. 1   2   3   4   5   6   7   8   9   10   11

---

Что такое технология проектирования?

Какие требования предъявляются к технологии проектирования?

Какие виды методик проектирования Вам известны?

Какова цель функциональной методики проектирования?

Дайте определения основных понятий функциональной методики IDEF0.

Лекция 13. Моделирование бизнес-процессов с помощью AllFusion Process Modeler (BPWin 7.x)

План:

1. 
   Назначение AllFusion Process Modeler 7
   
2. 
   Работа с программой AllFusion Process Modeler 7
   

AllFusion Process Modeler 7 (ранее BPwin) - инструмент для моделирования, анализа, документирования и оптимизации бизнес-процессов. AllFusion Process Modeler 7 можно использовать для графического представления бизнес-процессов.

AllFusion Process Modeler 7 (BPwin) эффективен в проектах, связанных с описанием действующих баз предприятий, реорганизацией бизнес-процессов, внедрением корпоративной информационной системы.

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

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



 Рисунок 12 - Создание новой модели

От выбора типа модели зависит, в каких нотациях можно производить декомпозицию работ. Так, если выбрать тип Business Process (IDEF0), то в созданной модели можно производить декомпозицию работ в нотациях IDEF0, IDEF3 и DFD; если выбран тип Data Flow (DFD) — в нотациях DFD и IDEF3; если же выбран тип Process Flow (IDEF3) — то только в нотации IDEF3. После ввода имени модели и выбора ее типа программа сразу предложит задать параметры модели (рисунок 13):



Рисунок 13 - Окно задания свойств модели

• 
  General— автор модели и его инициалы;
  
• 
  Numbering — формат нумерации работ и диаграмм и порядок ее отображения на диаграммах;
  
• 
  Display — список элементов отображения на диаграммах;
  
• 
  Layout — параметры расположения;
  
• 
  ABC Units — единицы функционально-стоимостного анализа;
  
• 
  Page Setup — параметры страницы;
  
• 
  Header/Footer — параметры верхнего и нижнего колонтитула.
  

---

После задания свойств модели появляется главное окно программы (рисунок 14), состоящее из трех основных частей:



Рисунок 14 - Главное окно программы
1 - обозреватель модели (Model Explorer) — отображает структуру модели (имеющиеся диаграммы и их иерархию);

2 - основная часть — в ней отображаются диаграммы, с которыми ведется работа;

3 - панели инструментов, из которых наибольший интерес представляет панель инструментов Model Toolbox.

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



Рисунок 15 - Окно свойств работы
Далее необходимо разместить на диаграмме стрелки. Для этого следует нажать на Model Toolbox кнопку Precedence Arrow Tool (курсор примет форму крестика со стрелкой), щелкнуть по тому месту, откуда стрелка должна выходить и затем щелкнуть по тому месту, куда стрелка должна заходить (BPwin подсветит эти места при наведении на них курсора). Для задания названия стрелки нужно нажать на Model Toolbox кнопку Pointer Tool и затем дважды щелкнуть по стрелке. В появившемся окне Arrow Properties название работы вводится в поле Arrow Name или выбирается из списка имеющихся названий стрелок. После размещения стрелок на диаграмме можно проводить декомпозицию ее работ. Для этого следует нажать на Model Toolbox кнопку Go to Child Diagram и затем щелкнуть по работе, которую нужно декомпозировать. Появится окно, в котором необходимо выбрать, в какой нотации проводить декомпозицию и количество дочерних работ (рисунок 16).



 Рисунок 16 - Создание дочерней диаграммы
После создания дочерней диаграммы BPwin автоматически создаст указанное число работ и разместит граничные стрелки по краям диаграммы. Далее следует связать граничные стрелки с входами работ (при необходимости можно добавить новые граничные стрелки) и связать работы между собой. Дальнейшая декомпозиция работ проводится аналогичным образом.

---

Вопросы для самоконтроля:

1. Для чего предназначена программа AllFusion Process Modeler 7 (BPwin)?

2. В каких нотациях можно производить декомпозицию работ если выбрать тип модели Business Process (IDEF0)?

3. Какова последовательность работ при создании модели в AllFusion Process Modeler 7 (BPwin)?

Лекция 14. Стандарты оценки качества ИС и процесса ее разработки

План:

1. 
   Качество ПО
   
2. 
   Условия разработки качественного ПО
   
3. 
   Оценка качества разработанного ПО
   

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

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

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

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

Несомненно, что качество созданной АИС зависит от уровня знаний разработчиков в области технологий БД и СУБД, от степени понимания ими современных и будущих (перспективных) прикладных задач пользователей.

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

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

---