Этапы проектирование бизнес системы

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

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

Проблемой маленьких команд или проектов является то, что не все методологии написанные и публикуемые в сети к ним применимы. И команды зачастую не состоят из “ветеранов проектирования” — потому что те просто “не по карману” стартапам и частным командам.

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

Этапы проектирования дома. Урок 6: организация работы над проектом.

Шаг 1: Основной процесс

Любое решение строится вокруг какого-то процесса — например совершение покупки, или подача заявки, даже публикация поста. Здесь речь идет не только о последовательности действий пользователей — участников будущей системы, но и про внутренние процессы: проверки одной системой, регистрация другой, подготовка публикации и так далее.

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

Здесь можно не бояться добавлять детали не только на текущем уровне детализации, но и возвращаться на “верхний уровень” — добавлять большие блоки и детализировать их. Например:

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

Ввиду того, что на данном этапе отсутствует структура как таковая, я предлагаю использовать простой текстовый редактор например https://docs.google.com/, потому что любой другой инструмент, требующий более структурированного подхода, на текущем этапе будет только ограничивать свободу мысли. Например, если, для того чтобы добавить простую функцию, надо переработать структуру документа, мозг подсознательно начнет оценивать целесообразность затрат и многие мысли не будут зафиксированы. А в IT фраза «Дьявол кроется в деталях» может запомниться как очень дорогой урок.

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

Шаг 2: Участники процесса

После того, как список действий определен, становится возможным понять кто и какое действие выполняет. То есть для каждого шага мы определяем исполнителей, кто должен или может делать какое-то действие в рамках процессов.

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

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

Шаг 3: Диаграмма процесса

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

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

Несмотря на определенные неудобства, я рекомендую использовать https://app.diagrams.net/, ввиду того, что этот инструмент бесплатный и предоставляет очень много шаблонов, которые окажутся очень полезными для новичков.

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

• Действия
• Связ
• Условий

Остальное — оставим корпоративщикам.

В итоге получается диаграмма, которую можно согласовать с клиентом.

Шаг 4: Наборы данных

Диаграмма помогает понять “кто?”, “что?” и “когда?”, однако не отвечает на вопрос “с чем?”.

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

Здесь есть следующие понятия:

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

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

Этот шаг, выполненный для всех действий позволит сформировать общее понимание всей модели данных с Бизнес-перспективы.

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

Шаг 5: Модель данных

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

В качестве инструментов можно использовать все тот же https://app.diagrams.net/, однако для случае, когда связей много а модели простые, я бы предложил использование https://start.jhipster.tech/jdl-studio/ который является окном в мир кодогенераторов и hgjfrnbdyjuj прототипирования и точно заслуживает отдельной статьи. Здесь мы только поскребем по поверхности и используем бесплатный инструмент JDL-studio.

Синтаксис достаточно простой, разобраться может любой новичок минут за 5, тем более что все изменения применяются сразу и диаграмма моделей перестраивается.

Шаг 6: Интерфейсные модули

Теперь мы должны вернуться к самому первому документу и извлечь из него данные в следующем формате:

Либо, как делается в корпоративных проектах, ввиду сложной иерархии:

Где, для каждого раздела необходимо расписать набор из:

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

Эта структура позволяет дать более-менее структурированное понимание функций системы “from user perspective”, что очень удобно дизайнерам.

Шаг 7: Прототипирование

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

Здесь есть множество решений платных и бесплатных, сложный и простых, интерактивных и нет.

На собственном опыте, принимая во внимание распространенность, бесплатность и интерактивность я бы порекомендовал https://www.figma.com/. Единственное, что он не умеет (хотя бы из коробки) — это давать возможность заполнять текстовые поля в режиме Презентации.

Важно упомянуть — что работа с Figma станет гораздо удобнее при использовании готовых шаблонов и наборов компонентов, доступных в сети.

Мобильные прототипы можно “скачать” и посмотреть как они выглядят на устройстве (обязательно делайте эту проверку)

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

Шаг 8: Проектирование API

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

Более того, проектирование API критично еще и потому, что структура API — это контракт между разработчиками разных компонентов, например Front-end и Back-end систем. И управляемость совместной разработки напрямую зависит от того, насколько детально прописаны API-calls, и насколько полно они удовлетворяют вызывающую и принимающую сторону.

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

Заключение

Весь этот процесс, в зависимости от сложности проекта, “размера” клиента и количества вовлеченных человек, занимает от одной до двух недель. Но эти затраты ничто по сравнению с теми, которые придется нести в случае, если это процесс не выполнять в каждом проекте. И, по опыту, они окупаются со 100% вероятностью.

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

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

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

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

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

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

Шаг 1: исследование предметной области

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

Шаг 2: выявление главных бизнес-целей у генерального директора предприятия

Диалоги с главным лицом компании получились полезными. Выявили и согласовали главные цели руководства. А именно:

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

Шаг 3: выявление задач будущих пользователей системы

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

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

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

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

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

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

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

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

Шаг 4: формирование информационной структуры

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

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

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

Шаг 5: разработка пользовательских сценариев

Создали базовые и вспомогательные сценарии для всех типов пользователей, шаблоны поведения.

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

Таких сценариев для MVP-версии наши специалисты описали несколько десятков. И даже при этом абсолютно все учесть на этом этапе не получилось. Остальное запланировали на следующие этапы развития проекта.

Шаг 6: создание структуры личного кабинета пользователя

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

Шаг 7: создание прототипа и технического задания

Для создания интерактивного прототипа будущей системы использовали инструмент Axure. После нескольких встреч согласовали этот прототип с руководством компании-заказчика и составили четкое и подробное ТЗ первого этапа работы, на основании которого можно заняться программной разработкой и последующим внедрением системы.

От начала до конца работы над проектом прошло три месяца.

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

• бизнес-аналитика
• разработка
• проектирование интерфейсов
• автоматизированные системы

• Разработка веб-сайтов
• Анализ и проектирование систем

Источник: habr.com

Проектирование информационной системы

Проектированием информационных систем называется многоступенчатый процесс их создания и/или модернизации путём применения упорядоченной совокупности методологий и инструментария. Проектирование (в отличие от моделирования) предполагает работу с пока несуществующим объектом и направлено на создание информационной системы в области:

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

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

• Цель проектирования информационной системы и связанные понятия
• Организация проектирования ИС
• Основные методологии проектирования ИС

Цель проектирования информационной системы и связанные понятия

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

• уровнем адаптивности к изменяемым условиям,
• пропускной способностью,
• временем системной реакции на запрос,
• уровнем безопасности,
• степенью простоты в эксплуатации.

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

Организация проектирования ИС

Организацию проектирования ИС принято разделять на 2 типа:

1. Каноническое проектирование отражает особенности технологии оригинального (индивидуального) процесса.
2. Типовое проектирование, для которого характерно типовое проектное решение (ТПР), тиражируется и пригодно к многократному использованию.

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

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

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

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

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

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

Декомпозиция может иметь несколько уровней, что позволяет выделить классы ТПР:

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

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

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

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

Основные методологии проектирования ИС

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

• SADT. Методология функционального моделирования работ, которая основана на структурном анализе и графическом представлении организации как системы функций. Тут выделяется функциональная, информационная и динамическая модели. В настоящее время методология известна как нотация (стандарт) IDEF0. Анализируемый процесс графически представляется в виде четырёхугольника, где сверху изображаются регламентирующие и управляющие воздействия, снизу – объекты управления, слева – входные данные, а справа – выходные.
• RAD. Методология быстрой разработки приложений. В RAD быстрая разработка приложений возможна за счёт применения компонентно-ориентированного конструирования. Методология применяется на проектах с ограниченным бюджетом, нечёткими требованиями к ИС, при сжатых сроках реализации. К ней прибегают, если пользовательский интерфейс можно продемонстрировать в прототипе, а проект разделить на функциональные элементы.
• RUP. В методологии RUP реализуются итерационный и наращиваемый (инкрементный) подходы. Построение системы происходит на базе архитектуры информационной системы, а планирование и проектное управление – на базе функциональных требований к ИС. Разработка общей информационной системы происходит итерациями, как комплекс отдельных небольших проектов со своими планами и задачами. Для итерационного цикла характерна периодическая обратная связь и адаптация к ядру ИС.

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

Отзывы, комментарии и обсуждения

Источник: finswin.com