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

Лабораторная работа № 1

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

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

Теоретический материал

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

Современная технология проектирования программного обеспечения информационной системы [10] должна отвечать ряду требований: соответствовать стандарту ISO/IEC 12207 [4], гарантировать успешность проекта, возможность декомпозиции проекта, независимость проектных решений от средств реализации и поддержку комплексом согласованных CASE-средств автоматизации процессов.

Разработка программного продукта и программной документации должна пройти следующие стадии и этапы работ [10] согласно стандарту ISO/IEC 12207 [4].

Стадия 1. Формирование требований к ПО.

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

– Проведение обследования деятельности автоматизируемого объекта (организации).

– Построение моделей деятельности организации: модель «AS-IS» и модель «TO-BE».

Стадия 2. Проектирование.

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

– Разработка технического проекта.

Стадия 3. Реализация.

Стадия 4. Тестирование.

Стадия 5. Ввод в действие.

Стадия 6. Эксплуатация.

Стадия 7. Снятие с эксплуатации.

Под технологическим процессом обработки информации понимается определенный комплекс операций, выполняемых в определенной последовательности с использованием определенных методов обработки и инструментальных средств, охватывающих все этапы обработки данных, начиная с регистрации первичных данных и заканчивая передачей результатной информации пользователю для выполнения функций управления [8, 21]. Модели описывают процессы, являющиеся частью технологического процесса. Проведение обследования предметной области и построенные модели зависят от выбранной методологии: структурно-функциональная или объектно-ориентированная.

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

В рамках данной лабораторной работы необходимо ознакомиться с методом структурно-функционального анализа, получить начальные навыки работы в специализированных пакетах на примере построения диаграмм процессов, диаграмм потоков данных и структур данных при построении модели «AS-IS» (КАК-ЕСТЬ).

МЕТОД СТРУКТУРНОГО АНАЛИЗА

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

Для функционального моделирования процессов предметной области необходимо описать процессы (строятся диаграммы процессов), описываются структуры данных и порядок выполнения процессов (бизнес-логика). ВВС США предложили и реализовали Программу интегрированной компьютеризации производства ICAM (ICAM – Integrated Computer Aided Manufacturing), направленную на увеличение эффективности промышленных предприятий посредством широкого внедрения компьютерных (информационных) технологий.

Пример модели IDEF0

Постановка задачи.

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

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

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

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

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

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

Основные элементы модели формирования выписки.

Название проекта: Формирование выписки из учетной карточки студента в деканате ФМиИТ.

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

Точка зрения: документовед деканата.

Инструментарий: методология функционального моделирования IDEF0 и приложение BPwin.

Список данных:

– учетная карточка;

– сведения о студенте;

– заявление студента;

– декан факультета;

– документовед;

– учебный план;

– документооборот;

– сведения об успеваемости студента;

– темы курсовых работ;

– шаблон выписки;

– выписка.

В модели использованы функции:

Формирование выписки – A0;

Принять заявление на составление выписки – А1:

Выполнить проверку на полноту данных в заявлении – А11;

Зарегистрировать заявление студента – А12;

Получить резолюцию декана на заявлении – А13.

Выполнить сбор данных по успеваемости – А2:

Найти учетную карточку студента – А21;

Составить список изученных дисциплин и отчетностей – А22;

Уточнить темы курсовых работ – А23.

Подготовить выписку – А3:

Заполнить данными шаблон выписки – А31;

Проверить результат внесения данных – А32;

Распечатать выписку – А33;

Утвердить выписку у декана – А34.

Выдать выписку – А4:

Зарегистрировать выдаваемую выписку в журнале – А41;

Передать выписку студенту – А42.

Словарь.

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

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

Студент – обучаемый в учебном заведении.

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

Учетная карточка – документ, содержащий сведения о студенте, данные по успеваемости по семестрам. И т.д.

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

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

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

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

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

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

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

Готовая выписка подписывается деканом и выдается студенту.

В процессе нормализации данных структура используемых хранилищ при формировании выписки предлагается ввод вспомогательных хранилищ. Так, помимо сведений об успеваемости студента, данные об учебной группе студента предлагается хранить отдельно. Нормализованная диаграмма сущность-связь в нотации IDEF1X представлена на рисунке 1.6.

Технологии создания модели CASE-средствами BPwin и ERwin представлены в руководствах, поставляемых с пакетами, например, необходимые сведения представлены в руководстве для начала работы в пакете «BPwin Getting Started Guide».

Рисунок 1.4 - Контекстная диаграмма процесса состояния выписки из учетной карточки студента

 

Рисунок 1.5 - Диаграмма первого уровня процесса формирования выписки

Рисунок 1.6 - Нормализованная диаграмма «сущность-связь»

 

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

1. Что такое «консалтинг» и какова его основная задача?

2. Что такое «логистика» и «реинжиниринг»?

3. Какие модели жизненного цикла программного обеспечения известны? Укажите достоинства и недостатки каждой модели.

4. Компоненты и базовая нотация DFD–технологии.

5. Какие данные и диаграммы являются входом технологической операции «Построение диаграммы потоков данных».

6. Какие требования предъявляются к мини-спецификации?

7. Этапы построения моделей в DFD–технологии: основные виды и последовательности работ.

8. Система обозначений в IDEF0, IDEF1X (компоненты SADT).

Практическая работа

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

Средства выполнения задания: MS Visio, средства пакета MS Office и Design/IDEF 3.5, Visible Analyst, BPwin 2-4.1.

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

Практическое задание

1. Выполнить структурный анализ предметной области и проектирование системы одним из структурно-функциональных подходов для задач по вариантам;

2. Описать структуру внешних и внутренних данных в IDEF1X;

3. Оформить отчет по результатам.

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

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

Вариант 1. В отеле аниматоры проводят мероприятия с проживающими данного отеля. Их зарплата зависит от количества проведенных мероприятий и отзывах проживающих. Раз в месяц подводятся итоги и выплачиваются премии.

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

Точка зрения: Бухгалтерия.

Вариант 2. На складе торговой точки хранятся товары.

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

Точка зрения: Склад.

Вариант 3. Компания предоставляет своим клиентам услуги согласно заключаемым договорам. Вид услуги регламентирован законодательством и уставом компании. В составлении договора участвует юрист компании.

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

Точка зрения: Отдел рекламы.

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

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

Точка зрения: Регистратура.

Вариант 5. Отдел продаж крупной компьютерной компании осуществляет продажу компакт-дисков с учебными курсами как по безналу, так и при оплате наличными клиентам. Существует система скидок по типу клиента. Существует отчетная документация. Клиент обращается в отдел как лично, так и через Internet.

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

Точка зрения: Отдел продаж.

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

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

Точка зрения: Отдел связи с общественностью.

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

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

Точка зрения: Научно-исследовательский отдел.

Вариант 8. Книжный магазин принимает заказы от населения на издания с условием частичной предоплаты (от 10% до 50%). На формирование объема заказа в издательстве учитывается спрос издания среди населения по категории.

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

Точка зрения: Отдел заказов.

Вариант 9. Структура фирмы содержит подразделения, в которых работают сотрудники.

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

Точка зрения: Отдел кадров.

Вариант 10. Библиотека вуза включат издания различных лет. Каждые два года выполняется ревизия и списание пособий с учетом потребности в учебном процессе. Для преподавателей кафедр публикуются сводки и отчеты.

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

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

Вариант 11. Компьютерная компания предоставляет населению помимо Интернет–услуг сопровождение ПО и обслуживание ВТ. Для привлечения клиентов используется система скидок. За отчетный период клиентам выставляется счет с описанием оказанных услуг.

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

Точка зрения: Бухгалтерия.

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

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

Точка зрения: Организатор выставки.

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

Цель: определить действия, необходимые для ведения операций по недвижимости.

Точка зрения: Риэлтор.

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

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

Точка зрения: Редколлегия.

 

Структура отчета.

1. Постановка задачи.

2. Основные элементы модели процесса.

– название проекта;

– цель проекта;

– точка зрения;

– инструментарий;

– список данных;

3. Дерево функций.

4. Словарь.

5. Диаграммы процессов.

Лабораторная работа № 2

Диаграмма потоков данных

Цели: рассмотрение систем международных стандартов в области ПО и их применения при построении диаграмм описания документооборота и обработки информации.

Теоретический материал

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

Диаграмма потоков данных (Data Flow Diagram – DFD) – информационная модель, основными компонентами которой являются потоки данных, переносящие информацию от одного модуля к другому.

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

Логическая DFD показывает внешние по отношению к системе источник и потоки данных, идентифицирует логические функции (процессы) и группы элементов данных, определяет хранилища (накопители) данных [18], то есть диаграммы потоков данных ориентированы на задачи обработки данных [30].

Главная цель построения диаграмм потоков данных – раскрыть, как каждый процесс преобразует свои входные данные в выходные, указать отношения между этими процессами [12]. В основе DFD–технологии лежат три группы средств моделирования: функциональные диаграммы (диаграммы потоков данных – DFD), диаграммы «сущность-связь» (ER–диаграммы) и диаграммы моделирования поведения систем (STD) [12]. Диаграммы потоков данных просты, наглядны и понятны (рисунок 2.1).

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

Для построения диаграмм потоков данных используются нотации Гейна-Сарсона (Gane-Sarson) [10] или Йордана (Yourdon) [12].

Основные символы данных нотаций представлены в таблице 1 согласно принятым обозначениям, используемым в пакете MS Visio 2003.

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

 

Рисунок 2.1 - Пример диаграммы потоков данных

 

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

Таблица 1 -Основные символы DFD

 

Декомпозиция DFD осуществляется на основе процессов: каждый процесс может раскрываться с помощью DFD нижнего уровня. При детализации должны выполняться правила [10]:

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

Правило нумерации – должна поддерживаться иерархическая нумерация процессов.

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

При анализе составления модели «AS-IS» (КАК-ЕСТЬ) процесса составления выписки из учетной карточки студента было принято решение описать с помощью IDEF3 листовую функцию Выполнить сбор данных по успеваемости для изучения порядка обращения к системам хранения. Для этого были определены составляющие процессы, используемы хранилища и типы связей.

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

Результат построения диаграммы представлен на рисунке 2.2.

Нормализованная диаграмма «сущность-связь» в нотации IDEF1X может быть построена с помощью одного из пакетов IDEF3.5 (Meta Software Corporation) или ALLFusion ERwin (Computer Associates International, Inc.).

Исходя из существующей системы хранения данных об успеваемости, аналитиком предложена даталогическая модель данных, представленная на рисунке 2.2 [10, 13, 15].

Рисунок 2.2 -Схема бизнес-процесса «Выполнить сбор данных по успеваемости» в стандарте DFD

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

1. Каково назначение диаграмм потоков данных?

2. Какая система обозначений используется в пакете BPwin для построения диаграмм потоков данных?

3. Какие символы DFD используются?

Практическая работа

Цели: применение систем международных стандартов в области ПО при построении диаграмм описания документооборота на предприятии и обработки информации.

Средства выполнения задания: средства пакета MS Office и BPwin 4.1 (и выше).

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

Практическое задание

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

Лабораторная работа № 3

Теоретический материал

Успех в бизнесе часто зависит от того, насколько хорошо организованы бизнес-процессы, отвечающие стратегическим целям предприятия. STD (State Transition Diagrams) – диаграммы переходов состояний [12], применяются для моделирования поведения системы.

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

Описание бизнес-процессов организации – это процесс, который включает следующие этапы:

1 Построение моделей бизнес-процессов организации, в том числе моделей КАК–ЕСТЬ и КАК–ДОЛЖНО–БЫТЬ.

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

3 Управление документацией, в том числе, распространение документов между заинтересованными участниками, управление версиями документов, управление правами доступа к документам и др.

На рисунке 3.1 представлен порядок использования методологий моделирования.

Рисунок 3.1 - Временная шкала использования методологий моделирования [14]

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

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

Для иллюстрирования вызовов листовых функциональных блоков IDEF0 может быть применено построение IDEF3-моделей. Данные, полученные с использованием IDEF0-моделирования, используются на стадии разработки моделей IDEF3 и диаграмм потоков данных (DFD) [12].

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

Информационное наполнение диаграмм модели регламентировано стандартом «IDEF3 Process Description Capture Method Report».

Нотация IDEF3 была разработана с целью более удобного описания рабочих процессов (workflow), для которых важно отразить логическую последовательность выполнения процедур (рисунок 3.2).

Workflow – автоматизация бизнес-процессов или «полная или частичная автоматизация бизнес-процесса, при которой документы, информация или задачи передаются от одного участника к другому для выполнения действий, предусмотренных набором руководящих правил» (Workflow Management Coalition, “Terminology & Glossary”).

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

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

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

Рисунок 3.2 -Пример бизнес-процесса в нотации IDEF3

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

Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

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

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

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

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

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

Разрабатывать имитационные модели технологических процессов следует по принципу "КАК БУДЕТ, ЕСЛИ...".

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

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

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

Диаграммы, относящиеся к первому типу, называются диаграммами Описания Последовательности Этапов Процесса (Process Flow Description Diagrams, PFDD), а ко второму - диаграммами Состояния Объекта и его Трансформаций в Процессе (Object State Transition Network, OSTN).

Если диаграммы PFDD технологический процесс «С точки зрения наблюдателя», то другой класс диаграмм IDEF3 OSTN позволяет рассматривать тот же самый процесс «С точки зрения объекта». Состояния объекта и Изменение состояния являются ключевыми понятиями OSTN диаграммы. Состояния объекта отображаются окружностями, а их изменения направленными линиями. Каждая линия имеет ссылку на соответствующий функциональный блок UOB, в результате которого произошло отображаемое ей изменение состояния объекта.

Терминология моделей IDEF3

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

Действие (единица работы) – основной компонент модели описания последовательности этапов процесса (рисунок 3.3). Для представления существующего или определяемого взаимоотношения между действия используются связи. Возможны три вида связи: временное предшествование, объектный поток и нечеткое отношение.

Рисунок 3.3 - Обозначение единицы работы

Разбиение и слияние действий показываются при помощи соединений (узлов) типа соединительное «И», эксклюзивное «ИЛИ» и соединительное «И/ИЛИ» (Приложение А).

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

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

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

Пример модели IDEF3

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

На рисунке 3.5 представлено отображение процесса проверки выписки на наличие ошибок с точки зрения OSTN диаграммы (рисунок 3.2). На данной диаграмме рассматривается объект «выписка» и его трансформация в процессе подготовки выписки на основе списка изученных дисциплин в готовую выписку из учетной карточки студента.

Рисунок 3.5 - Пример OSTN диаграммы

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

1. Какие основные «строительные блоки» используются для построения диаграмм IDEF3?

2. В каких случаях строится перекресток ветвления «ИЛИ»?

3. Сколько типов диаграмм в стандарте IDEF3?

Практическая работа

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

Средства выполнения задания: средства пакета MS Office, BPwin 4.1 и выше, Visible Analyst.

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

Практическое задание

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

2. Дать предложения по автоматизации работ модели «КАК-ЕСТЬ» в виде модели «КАК-ДОЛЖНО-БЫТЬ» с использованием CASE-средства BPwin. Полученные диаграммы будут использоваться при выполнении последующих лабораторных работ.

Лабораторная работа № 4

Теоретический материал

На данный момент не является тайной, что для успешной конкуренции стало недостаточно просто укладываться в бюджет и сроки. Опыт софтверных компаний как зарубежных, так и отечественных, позволил сформулировать так называемое Правило «80/20»:

Правило «80/20»: успешность проекта на 80% определяется регламентом работ и только на 20% – применяемым инструментарием.

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

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

Объектно-ориентированный подход позволяет сократить время на разработку систем при условии повторного использования заготовок (шаблоны, паттерны).

Объектно-ориентированный анализ (ООА) – процесс п