Моделирование бизнес процессов техническое задание

О том, как качественно и понятно составить техническое задание рассказывает старший эксперт практики ERP SAP группы компаний Лига Цифровой Экономики, Екатерина Синица.

7611 просмотров
Типичные ошибки при составлении ТЗ

ТЗ предназначено для окончательного формулирования требований к продукту проекта, в нашем случае – к информационной системе (ИС). Большинство проблем, связанных с разработкой и согласованием ТЗ, вызвано неполным охватом всех видов требований при их анализе. Напомним, они делятся на функциональные (требования к тому, ЧТО должна делать ИС) и нефункциональные (требования к тому, КАК должна функционировать ИС).

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

Открытый вводный вебинар курса «Моделирование и оптимизация бизнес-процессов»

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

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

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

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

Урок 1 BPMN 2.0 Введение: Как моделировать бизнес процессы для разработки ИТ систем? 18+

1) Структурный анализ – моделирование структуры, понимание компонентов ИС и взаимосвязи между этими компонентами;

2) Анализ процессов – моделирование рабочего взаимодействия всех участников процесса, в котором предполагается задействовать ИС;

3) Функциональный анализ – моделирование всех возможных сценариев работы ИС и ее взаимодействия с акторами (пользователями) и смежными системами;

4) Информационный анализ – моделирование структуры данных (выделение объектов и их атрибутов, определение взаимосвязей между объектами) и потоков прохождения этих данных по процессам;

5) Анализ интерфейсов – моделирование (а в идеале прототипирование) пользовательских интерфейсов, проектирование рабочих мест пользователей.

Ошибки проектирования хорошо видны задолго до начала разработки, если мы пытаемся представить себе механизм их проверки. Неслучайно в ГОСТ 34.х документ «Программа и методика испытаний» является приложением к ТЗ. Настоятельно рекомендуется формировать сценарии тестирования ИС одновременно с фиксированием требований к этой ИС. Это позволит существенно повысить качество проектирования.

Как сделать ТЗ понятным для всех участников проекта

Отдельная большая проблема на этапе разработки ТЗ – это его согласование. заказчик, который не очень хорошо разбирается в технических аспектах ИС, скорее всего, будет испытывать большие опасения, подписывая обширное ТЗ. Опасения связаны с несколькими моментами:

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

2. Страх, что после утверждения ТЗ будет невозможно внести изменения в требования к результатам проекта. Чтобы снять эти опасения и иметь возможность делать проекты в постоянно меняющейся бизнес-среде, были сформулированы принципы гибкой разработки Agile Manifesto. Но не все заказчики знают эти принципы, и не все команды им следуют. Лучше в самом начале договориться с заказчиком о порядке управления изменениями в требованиях на протяжении всего проекта. Тогда и для вас, и для заказчика согласованное ТЗ станет основой, «печкой» для начала разработки ИС, но ни в коей мере не терминальным ограничением на ее функциональность.

3. Базовое недоверие к поставщику. Заказчик может бесконечно долго вычитывать и придираться к малейшим шероховатостям в тексте ТЗ только потому, что ему кажется, что исполнитель некомпетентен, неаккуратен и все сейчас сломает. Этот страх снимается только опытом взаимодействия с данным клиентом. Именно поэтому так важна лояльность старых заказчиков – с ними и ТЗ быстрее согласовываются, и проекты легче делаются. Работая с заказчиком впервые, не экономьте на прототипах – если он увидит, что вы и впрямь умеете делать крутые решения, доверие к вашей команде возрастет.

Подводные камни

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

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

Внутреннее согласование. Очень часто разработчиков и тестировщиков не приглашают к согласованию ТЗ. А это неправильно, потому что только эти специалисты смогут вовремя заметить существенные ошибки, которые заказчик, весьма вероятно, пропустит.

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

a. ГОСТ серии 34.х и 19.х;

b. Стандарты ИСО/МЭК по системной инженерии;

c. Методологии внедрения конкретного ПО (ASAP, MSF, RUP и т. д.);

d. Рекомендации Свода знаний по бизнес-анализу (BABOK).

Источник: vc.ru

Разработка информационной системы автоматизации бизнес процессов

Разработка информационной системы автоматизации бизнес-процессов управления терминальной сетью
Объектом автоматизации является бизнес-процессы по управлению терминальной сетью АТМ.

Сокращения

ИПТ – информационно-платежный терминал (киоск самообслуживания)

УС – устройство самообслуживания (АТМ, ИПТ)

М-ХД – хранилище мастер данных

МК – ООО «МультиКарта»

Заказчик – ООО «МультиКарта»

ГО – головная организация (Банка)

БФ – базовый филиал (Банка)

РОО – региональный офисный центр (Банка)

ОО – операционный центр (Банка)

ДО – дополнительный офис (Банка)

ТП – точка продаж (Банка), может быть уровня ГО, БФ, РОО, ОО, ДО

РЦ – региональный центр (Банка)

ОЦ – областной центра (Банка)

ГЦ – городской центр (Банка)

КЦ – клиентский цент (Банка)

Цель разработки и развития системы

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

Назначение системы

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

Сведения об условиях эксплуатации

В перспективе – десятки

Требования к общей архитектуре

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

Рис.1. Архитектура пилотного решения

Реализация должна включать

1. Обязательное использование BPM-движка

1. Пользовательский интерфейс (рабочие места сотрудников Банка и МК), состоящий из нескольких компонент:

1. стартовая страница пользователя (согласно роли)
2. модуль выполнения БП, интегрированный с BPM-движком, – для запуска и участие в БП, согласно назначенным ролям.
3. модуль пользовательского управления данными М-ХД (управление справочниками, значениями сущностей, созданных в ходе выполнения БП).
4. модуль статистики и отчетности для пользователей.

С учетом того, что одному пользователю системы (user id) может быть назначено несколько ролей (см. раздел «Требования к модели доступа»), то необходим механизм выбора пользователем исполняемой им в данный момент роли, а не заведение для каждой роли отдельного user id с необходимостью повторного входа под другим user id.

1. Пользовательский интерфейс (администратора системы), позволяющий:

1. управлять пользователями и группами пользователей

1. создаватьудалятьприостанавливать пользователей
2. сбрасывать пароли. Желательно иметь возможность указать «время жизни» пароля и его минимальную длину.
3. назначать пользователям права доступа к БП (запуск, участие)
4. редактировать справочники и сущности, хранимые в М-ХД
5. получать доступ к модулю статистики и отчетности
6. имеет значение гибкость выполнения настроек.

1. отображать ошибки выполнения БП
2. по запросу открывать логи BPM-сервера
3. отображать запущенные БП

1. Разработку БД (отдельной от БД BPM) для хранения мастер-данных (М-ХД), содержащую все основные сущности, переменные БП и справочники.

1. Слой доступа к данным (адаптер к М-ХД)

Требования к BPM-движку

• jBPM (Red Hat)
• RunaWFE
• Activiti (Alfresco)

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

Требования к дизайну и функциональности

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

• IE 9.0 и выше
• Firefox версия 28 3 и выше
• Google Chrome версия 32 4 и выше.

Требования к идентификации и аутентификации пользователей

• использование SSL-сертификатов 6 , выдаваемых пользователям центром сертификации МК. Наличие такого механизма на пилоте будет рассматриваться как преимущество.
• использование Reverse-Proxy, установленного на стороне Банка, выполняющего идентификациюаутентификацию в AD Банка по LDAP и затем «пробрасывающего» запрос для пользователей, прошедших аутентификацию в AD банка, на Web-сервер системы с передачей в URL ряда параметров (user ID, пр.). Система не проводит аутентификацию пользователя и полностью доверяет данным передаваемым со стороны Банка. Для идентификации сервера Банка используется SSL-сертификат, выдаваемый центром сертификации МК.

Требования к модулю пользовательского управления данными

• Реализует возможность непосредственного просмотра и добавленияудаленияредактирования данных М-ХД пользователями с учетом назначенных им ролям.
• Обязательной является

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

Требования к слою доступа к данным и адаптеру М-ХД

• Отделить механизмы управления данными от бизнес-логики
• Реализовать механизм адаптера для гибкого подключения к внешнему серверу М-ХД (конкретный интерфейс взаимодействия с выбранной реализацией сервера М-ХД)
• Обеспечить независимости приложения BPM от выбора реализации сервера М-ХД (в перспективе MDM-engine)
• Реализовать схему легирования действий пользователя на уровне адаптеров М-ХД, обеспечив тем самым требование (все действия и изменения данных должны быть явными и фиксированными)

Интеграционные взаимодействие БП и модулей веб-интерфейса с М-ХД должно осуществляться только с использованием слоя доступа.

Требования к М-ХД

• Обеспечивает централизованное хранение, обработку и выдачу мастер-данных (для BPM, для экспорта во внешнюю систему Банка) – справочников и сущностей БП.
• «Фильтрация» данных для выдачи пользователям, согласно их привязке к иерархической структуре Банка.

На пилоте допустима собственная реализация М-ХД с целью сокращения сроков и стоимости разработки.

Примечание: дальнейшие шаги по развитию (после пилота):

• Принятие решения – выбор Enterprise системы MDM-engine (миграция на нее) или использование InHouse-системы
• Ведение версионности выбранных объектов учета и справочников

• Реализация слоя «адаптеров» и DAO
• Реализация слоя ESB
• Подключение новых абонентов системы (Producer/Subscriber)

Требования к модели доступа

• Доступ к функциональности системы должен быть реализован посредством мандатного доступа (согласно ролям пользователей и назначенным правам на разделы интерфейса).
• Доступ к объектам системы (контент справочников и сущностей, хранимых в М-ХД) – посредством объектного доступа.

Предлагается модель назначение прав: «User – Роль – ТП».

При этом одному User может быть назначено несколько ролей в одном ТП. User может иметь разные роли в разных ТП:

«user Ivanov – роль «руководитель в ТП» – ТП37012 (ДО)»

«user Ivanov – роль «менеджер проекта в ТП» – ТП37012 (ДО)»

«user Ivanov – роль «руководитель в ТП» – ТП44123 (ОО)»

«user Ivanov – роль «руководитель в ТП» – ТП55000 (ОО)»

• Назначение пользователям прав на БП, но не на контент справочников М-ХД
• Исполнение БП и их задач согласно назначенным ролям

• Предоставление «фильтрованных» данных, согласно уровню привязки роли к территориальной структуре Банка.

доступ к объектам системы предоставляется по принципу «сотруднику вышестоящей точки филиальной структуры доступны объекты ее нижестоящих веток».

Запросы к М-ХД (типа Get) должны содержать назначенный для исполняемой пользователем роли номер ТП, чтобы М-ХД, формируя ответ по объектам подлежащим фильтрации, произвел фильтрацию согласно правам, назначенной роли.

Например, если система (BPM, модуль пользовательского управления данными) запрашивает список АТМ (УС), то М-ХД должен вернуть только те АТМ, которые доступны выполняемой роли согласно уровню привязки роли и АТМ к «ТП».

Пример структуры филиальной сети пилотного Банка и предлагаемой модели доступа приведен на рис.2. У другого Банка филиальная сеть может иметь другую структуру, см. рис.3.

Рис.2. Модель доступа для филиальной структуры пилотного Банка

Рис.3. Модель доступа для филиальной структуры другого Банка

Требования к документации на этапе пилота

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

Требования к журналированию действий пользователя

Состав работ на пилоте, этапы и сроки

• Пользовательского интерфейса
• Унифицированного слоя доступа к данным
• М-ХД
• Процедуру загрузки данных в М-ХД из БД Банка 7 , т.н. Начальная загрузка данных и справочников (Initial Load).
• Бизнес-процесса «Установка нового УС в новое МУ» (далее БП1) согласно Приложению 1
• Бизнес-процесса «Утилизация УС» (далее БП2) согласно Приложению 2
• Бизнес-процесса «Перемещение бу УС в новое МУ» (далее БП3) согласно Приложению 3

• полностью или частично реализованный веб-интерфейс пользователя с модулем выполнения БП1 и модулем пользовательского управления данными М-ХД
• полностью или частично реализованный БП1, интегрированный с М-ХД через унифицированный слой доступа
• М-ХД в объеме требуемом для демонстрируемого БП1

Порядок контроля на этапе ведения разработки

1. Разработчик предоставляет подробный план разработки с указанием сроков и ответственных. Преимуществом будет заведение задач данного плана в используемую разработчиком систему ведения проектов и предоставление доступа уполномоченным сотрудникам МК.
2. Разработчик ведет разработку на своем тестовом стенде, но уполномоченным сотрудникам МК предоставляет удаленный доступ к стенду, включающий доступ к среде исполнения разрабатываемых БП, к разрабатываемой БД М-ХД и репозиторию исходного кода (последнее по запросу).
3. На площадке МК также будет развернут тестовый стенд, отвечающий требованиям разрабатываемой платформы. С момента достижения значимых результатов (готовность прототипа к демонстрации) все значимые изменения в разрабатываемом проекте должны передаваться сотрудникам МК для установки на стенд МК.
4. МК будет принимать участие в процессе разработки («design review», «code review», «quality assurance») и тестировании. Разработчики должны оказывать поддержку уполномоченным сотрудникам МК.
5. МК оставляет за собой право привлекать для контроля третью сторону.

Порядок приёмки системы

Общие требования

Этап 1: предварительная приемка системы (необходимое условие подтверждения готовности к началу ОПЭ).

Этап 2: приемка системы по итогу ОПЭ и устранению критичных недостатков, выявленных в ходе ОПЭ (необходимое условие подтверждения готовности для начала тиражирования)

Требования к испытаниям системы по этапам

1. предварительные испытания системы, проведенные подрядчиком на своем тестовом стенде.
2. предварительные испытания системы, проведенные МК и подрядчиком, на тестовом стенде МК.

Этап 2 — приемка системы по итогу ОПЭ

1. нагрузочные испытания системы, проведенные совместно МК и разработчиком на тестовом стенде МК, близком по конфигурации к промышленному.
2. ОПЭ, проведенное на промышленном стенде МК с участием нескольких структурных подразделений выбранного Банка и МК.

Этап 3 — финальная приемка

Требования к приемочной документации по этапам проведения испытаний

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

• акты, содержащие результаты нагрузочного тестирования, содержащие выводы и план-график устранения замечаний.
• по итогу ОПЭ — акт, содержащий результаты, выводы и план-график устранения замечаний разработчиком.

Ввод системы в эксплуатацию

1. Доработать систему согласно планам-графикам устранения замечаний.
2. Оказать консультирование специалистам МК по прикладной настройке промышленного стенда
3. При необходимости провести донастройку прикладной части системы с выездом в офис МК в Москве.
4. При необходимости провести обучение нескольких сотрудников МК (до трех человек) основам администрирования системы – в офисе компании разработчика или офисе МК в Москве или СПб.

Требования к программному обеспечению

• Сервер БД

• Операционная система: Linux RHEL, Oracle Linux
• БД: Oracle

• Операционная система: Linux RHEL, Oracle Linux

• На стенде Исполнителя предоставляется Исполнителем
• На стенде Заказчика предоставляется Заказчиком

Приложение 1 к Техническому заданию

• Расчет скоринга по требуемой формуле на основе заполненных пользователем переменных
• Использование КЛАДР (загружаемый в справочники М-ХД)

Источник: rykovodstvo.ru

Разработка ТЗ на процессные приложения: когда BPMN-диаграммы недостаточно

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Комментарии

Вам так же понравится

Все шлюзы в BPMN с примерами

Как избежать неработоспособности API при изменениях? 8 пунктов, о которых стоит подумать

Время в BPMN: как отображать ограничения

Как выделять квадратики в BPMN

Автор

Привет! Я Денис Котов, проектирую процессы для банков и веду рассылку о BPM, BPMN и BPMS. Подписывайтесь!

Как передать информацию в BPMN

Разница между BPM движками и BPMS системами

Как и зачем переходить от статусов к процессам

Время в BPMN: как отображать ограничения

Пример процесса BPMN: Импорт заявок из маркетплейса в ERP

ИП Котов Денис Геннадьевич, ИНН 463312037917, ОГРНИП 318463200033865. Заполняя любую форму на сайте или поддоменах вы соглашаетесь с политикой конфиденциальности . И вот еще публичная оферта. И еще промокод на онлайн-курсы для внимательных — 10OFFBLOG

Привет!

Я Денис Котов. Я подготовил шпаргалку для начинающих в BPMN.

Больше 5000 человек начали моделирование процессов с этой шпаргалки.

Источник: bpmn2.ru