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

Текст из файла (страница 5)

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

Можно определить следующие шаги рабочего процесса определения требований*:

• Перечисление возможных требований;

• Осознание контекста системы;

• Определение функциональных требований;

• Определение нефункциональных требований.

Перечисление возможных требований

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

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

• состояние предложения (например, предложено, одобрено, включено в план, утверждено);

• трудоемкость в человеко-часах или стоимость реализации;

• приоритет (например, критический, важный или вспомогательный);

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

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

Осознание контекста системы

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

• Моделирование предметной области;

• Бизнес-моделирование.

Модель предметной области

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

Бизнес-модель

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

Определение функциональных требований

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

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

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

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

Определение нефункциональных требований

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

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

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

Характеристика моделей деятельности организации. Модель «как есть» (AS IS) и модель «как будет» (TO BE).

AS IS - модель «как есть», модель существующего состояния организации.

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

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

Проектирование информационных систем и управление процессами подразумевает построение модели AS IS и дальнейший переход к модели TO-BE, что является залогом автоматизации "правильных", усовершенствованных процессов.

TO BE (SHOULD-BE, AS-TO-BE) - модель «как должно быть».

Как правило, данная модель создается на основе AS IS, с устранением недостатков в существующей организации бизнес-процессов, а так же с их совершенствованием и оптимизацией. Это достигается за счет устранения выявленных на базе анализа AS IS узких мест.

В традиционном реинжиниринге именно на основе модели TO BE рекомендуется производить автоматизацию бизнес-процессов и проектировать КИС. Подразумевается, что это позволяет существенно снизить риск проявления автоматизации как исключительно источника затрат из-за автоматизации несовершенных процессов. Однако в настоящее время, в связи с возрастающей популярностью "эволюционного" реинжиниринга (см. CPI), снижается необходимость в долгой и трудоемкой подготовке модели TO BE.

Диаграммы стандарта IDEF0. Основные принципы построения.

Информационные технологии - Бизнес-процессы

Что такое IDEF0 диаграмма и как ее построить

Начнем с понятий.

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

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

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

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

Существует несколько классических, строго оговоренных видов моделей.

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

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

- все функции и интерфейсы представлены как блоки и дуги;

- место соединения дуги с блоком определяет тип интерфейса:

• управляющая информация входит в блок сверху,

• входная информация входит в блок слева,

• результаты выходят из блока справа,

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

Отдельные компоненты диаграммы могут быть более подробно расшифрованы на другой диаграмме. Общее число уровней детализации в модели не должно превышать 5-6.

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

Типы связей стандарта IDEF0.

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

Рассмотрим основные элементы графической нотации IDEF0 (рис. 6.1.).

Рис. 6.1. Элементы графической нотации IDEF0

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу), которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают 5 видов стрелок:

 вход (англ. input) – материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;

 управление (англ. control) – управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т. е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

 выход (англ. output) – материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

 механизм (англ. mechanism) – ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

Диаграммы стандарта IDEF3. Основные принципы построения.

СТАНДАРТ IDEF3 - это методология сбора данных о процессе, рассматривающая взаимодействие информационных потоков как логическую последовательность выполнения на основе причинно-следственных связей между ситуациями и событиями, предназначенная для разработки структурного представления знаний о системе, и описания изменения состояний объектов, являющихся составной частью описываемых процессов.
При помощи графической нотации IDEF3 описывается логика выполнения работ, очередность их запуска и завершения. Т.о. IDEF3 предоставляет инструмент для моделирования сценариев действий сотрудников организации, отделов, цехов и т.п., например порядок обработки заказа или события, на которые необходимо реагировать за конечное время, выполнение действий по производству товара им т.д.
IDEF3 рассматривает поведенческие аспекты существующих или проектируемых систем. Знания о процессах структурированы в виде контекстных сценариев, что делает IDEF3 удобным инструментом сбора данных для описания системы. IDEF3 аккумулирует в себе временные зависимости и связи между процессами, происходящими на предприятии. В результате создается структурированная база знаний для построения аналитических и проектировочных моделей. В отличие от других языков моделирования (таких, как SIMAN, SLAM, GPSS, WITNESS), которые строят прогностические математические модели, IDEF3 позволяет создавать структурные описания. Эти описания содержат информацию о том, что на самом деле происходит или будет происходить в системе, а также отражают точки зрения различных пользователей.
Описание процесса по нотации IDEF3 представляет собой структурированную базу знаний, которая состоит из набора диаграмм описания процесса, объектных диаграмм изменения состояний объектов и уточняющих форм. Цель такого описания может состоять как в документальном оформлении и распространении знаний о процессе, так и в идентификации противоречивости или несовместимости выполнения отдельных операций.
Для эффективного управления любым процессом, необходимо иметь детальное представление о его сценарии и структуре сопутствующего документооборота. Средства документирования и моделирования IDEF3 позволяют выполнять следующие задачи:

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

• анализировать существующие процессы и разрабатывать новые;

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

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

• содействовать принятию оптимальных решений при реорганизации процессов;

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

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

IDEF3-ДИАГРАММА

Характеристики

Список файлов ответов (шпаргалок)