Конспект лекций (1158677), страница 10

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

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

Деятельности, выполняемые бизнес-разработчиком и рабочие документы,создаваемые им.Модель бизнес-анализа – это объектная модель, элементами которой являютсяисполнитель (business worker) и бизнес-сущность (business entity). Эта модель описываетвнутреннее устройство бизнес-процессов с точки зрения структуры и поведения. Но изэтой модели нельзя понять деловое окружение предприятия (что описано моделью бизнеспроцессов).Business worker –исполнитель, действующий в рамках бизнес-системы.

В отличие отделового действующего лица исполнитель работает на предприятии. Он имеет связивзаимодействия с другими исполнителями и манипулирует бизнес-сущностями, участвуяв реализациях бизнес-процессов. Представляется на диаграммах как класс со стереотипом«business worker».Деловая сущность (Business entity) – это ресурс (информационный, материальный,финансовый и т. д.), не инициирующий никаких взаимодействий, он может участвовать вомногих реализациях различных бизнес-процессов и является предметом различныхманипуляций со стороны исполнителей.На диаграммахпредставленклассомсо стереотипом «business entity».Модель бизнес-анализа включает РегистраторКоординатор багажав себя диаграммы разных видов:диаграммыклассов,отражающих структурные соединения, изкоторых следует как взаимосвязаныисполнители и деловые сущности (изБагажпримера следует, что исполнители двухразных классов могут взаимодействоватьмежду собой, что исполнитель первогокласса имеет доступ к деловым сущностямбагаж и Багажная бирка, а исполнительвторого класса – только к Багажу, чтоБагажная биркасущности связаны между собой.);5диаграммывзаимодействия(последовательности,кооперативные),: Регистраторописывающиереализациюодногоизсценариев бизнес-процесса, и служащие для: Пассажирмоделирования распределения обязанностей1: Оформить посадочный талон( )между исполнителями (например, диаграммапоследовательностиможетизображать2: Проверить правильность билета( )реализацию основного потока событий бизнеспроцесса Пройти регистрацию, и на ней видно3: Оформить багаж( )какимисообщениямиобмениваютсяэкземплярделовогодействующеголица и4: Зарезервировать место( )экземпляр исполнителя, а также видно,обработка каких сообщений входит в5: Напечатать посадочный талон( )ответственность исполнителя);диаграммысостоянийдля6: Принять посадочный талон и квитанцию( )моделированияжизненногоциклаэкземпляров того или иного исполнителя илиэкономического ресурса, т.

е. деловойсущности, (в примере видно, что экземплярделовой сущности Багаж меняет свои внутренниесостояния, принимая сообщения от исполнителей,Поставлен на весыизображенные как события «Поставлен на весы»,Определенвес«Прикреплена бирка» и т. д.).Ходбизнес-моделированиявцеломПрикреплена биркаотображает следующая диаграмма деятельности:ЗарегистрированПоставлен на транспортерНатранспортереПеренесен на багажную платформуНа багажнойплатформеДоставлен в самолетВ самолетеПри оценивании бизнеса создаются следующие документы:6 видение бизнеса; оценка организации.На основании этих документов принимается решение: либо моделировать толькопредметную область, либо осуществляется полное деловое моделирование.

Исследованиеавтоматизации процессов предпринимается, если создаваемое программное обеспечениедолжно автоматизировать бизнес, ранее ведущийся по старинке.Бизнес правила представляют собой ограничения, которые должны обязательновыполняться в ходе деловых процессов. Формулировки бизнес-правил составляютспециальный документ – Описание бизнес-правил. Каждое бизнес-правило должно такили иначе прослеживаться на диаграммах бизнес-модели. Например, бизнес-правило:Цена нетто = цена продукта * (1 + процент налога / 100) задает условие на структурныесвязи в модели бизнес-анализа, а именно: исполнитель, ответственный за расчет ценынетто должен иметь возможность получить все подставляемые в формулу значения.1..*Профиль клиентаЗаказ1Профиль регионаПродуктпродуктаСоответствующая диаграмма классов из модели бизнес-анализа должна быть проверена, ипри необходимости на нее должны быть добавлены дополнительные связи.

Напредставленной диаграмме видны «маршруты» получения цены продукта (Заказ ->Продукт.цена продукта); процента налога (Профиль клиента -> Профиль региона. процент налога).В связи с большим количеством типов возможных бизнес-правил вводят ихклассификацию: правила-ограничения:o управляющие воздействия и реакции на воздействия (например, бизнесправило: «При отмене заказа, если он еще не доставлен, то его следует отметить какзакрытый», здесь отмена заказа – управляющее воздействие, а закрытие отмененногозаказа – реакция);o операционные ограничения или предусловия и постусловия (например, бизнесправило: «Доставить заказ клиенту только при наличии адреса доставки» устанавливаетпредусловие для операции доставки заказа);o структурные ограничения (например, бизнес-правило «Заказ включает в себя покрайней мере одну позицию», устанавливает мощность связи между классами деловыхсущностей Заказ и Позиция заказа, такое бизнес-правило дополнительно отображается надиаграмме классов из модели бизнес-анализа в виде показателей мощности на полюсахассоциации, соединяющей упомянутые сущности); правила вывода и вычислительные правила (например, рассмотренная выше формуларасчета цены).Бизнес-разработчик должен учитывать все бизнес-правила и отслеживать ихвыполнение в модели бизнес-анализа.Модель бизнес-анализа может быть достаточно большой, что вызывает7необходимость ее структурировать.

Это осуществляется при помощи таких элементов какреализация бизнес-процесса (кооперация со стереотипом «business use case realization») ибизнес-система (пакет со стереотипом «business system»). Реализация бизнес-процессаописывает реализацию конкретного бизнес-процесса в рамках модели бизнес-анализа втерминах взаимодействия объектов (экземпляров исполнителей и деловых сущностей) и втерминах структурных связей между исполнителями и деловыми сущностями.

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

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

Бизнес-образец «Занятость».Проблема: описание различных форм занятости сотрудников внутри организации.Решение: занятость моделируется как контракт между личностью и организацией,указывающий выполняемые обязанности, контрактные условия, даты начала и концаработы. Личность характеризуется набором атрибутов (имя, адрес, дата рождения), можетзанимать более чем одну должность в организации.Employee ProfileEmploymentEmployee ProfileOrganization Profile+profile- Name- Address- Birthdate1..n1..nEmployment+employmentPositionPosition AssignmentEmployment- Start date- End datebased on employmentOrganization Profile- Name- Address- Purposeresponsible for position1..n1..nPosition AssignmentСовокупность участниковСтатическое8Positionпредставление(структурные связи)Это структурный бизнес-образец, в нем отсутствует динамическое представление.Литература к лекции 41.

Вендров А. М. Проектирование программного обеспечения экономическихинформационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.9Лекция 5. СПЕЦИФИКАЦИЯОБЕСПЕЧЕНИЮТРЕБОВАНИЙКПРОГРАММНОМУТребование – это условие, которому должно удовлетворять программноеобеспечение, или свойство, которым оно должно обладать, чтобы: удовлетворить потребность пользователя в решении некоторой задачи; удовлетворить требования контракта, спецификации или стандарта.Определение требований к ПО является составной частью процесса управлениятребованиями. Спецификация требований к ПО является основным документом,определяющим план разработки ПО.

Все требования, определенные в спецификации,делятся на функциональные и нефункциональные. Функциональные требованияопределяют действия, которые должна выполнять система, без учета ограничений,связанных с ее реализацией. Тем самым функциональные требования определяютповедение системы в процессе обработки информации. Нефункциональные требования неопределяют поведение системы, но описывают ее атрибуты или атрибуты системногоокружения. Можно выделить следующие типы нефункциональных требований: требования к применению определяют качество пользовательского интерфейса,документации и учебных курсов; требования к производительности накладывают ограничения на функциональныетребования, задавая необходимую эффективность использования ресурсов,пропускную способность и время реакции; требования к реализации предписывают использовать определенные стандарты, языкипрограммирования, операционную среду и др.; требования к надежности определяют допустимую частоту и воздействие сбоев, атакже возможности восстановления; требования к интерфейсу определяют внешние сущности, с которыми можетвзаимодействовать система, и регламент этого взаимодействия.Методы выявления требований: собеседование (интервьюирование); анкетирование; проведение совещаний; сессии по выявлению требований (мозговой штурм); раскадровка (storyboard); описание и анализ бизнес-процессов; ролевые игры; создание и демонстрация работающих прототипов.Этапы работы с требованиями: Определение типов требований и групп участников проекта, работающих с ними. Первичный сбор требований, их классификация и занесение в базу данныхтребований. Использование базы данных требований для управления проектом.Любое требование в базе проекта имеет следующие атрибуты: Приоритет (высокий, средний, низкий). Статус (предложено, одобрено, реализовано, верифицировано). Стоимость реализации (высокая, средняя, низкая – или числовое значение). Сложность реализации (высокая, средняя, низкая). Стабильность (высокая, средняя, низкая). Ответственный исполнитель.Хороший набор требований удовлетворяет следующим показателям качества (IEEE830-1998 «Recommended Practice for Software Requirements Specifications»):1Корректность или адекватность (соответствие реальным потребностям).Недвусмысленность (однозначность понимания).Полнота (отражение всех выделенных потребностей и всех возможных ситуаций, вкоторых придется работать системе). Непротиворечивость (согласованность между различными элементами). Упорядоченность по приоритету и стабильности. Проверяемость (выполнение каждого требования нужно должно проверятьсядостаточно эффективным способом – непроверяемые требования должны бытьудалены из рассмотрения или сведены к проверяемым вариантам). Модифицируемость (оформление в удобных для внесения изменений структуре истилях). Прослеживаемость в ходе разработки (возможность увязать требование сподсистемами, модулями и операциями, ответственными за его выполнение, и стестами, проверяющими его выполнение).Выявленные требования к ПО оформляются в виде ряда документов и моделей.

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

Список файлов лекций