ІТ бізнес-аналітик та системний аналітик — це різноманітні й складні ролі, де ви можете використовувати безліч професійних інструментів для підвищення ефективності та якості ваших результатів.
У першій частині цієї статті я розповів про п’ять найпоширеніших інструментів бізнес-аналітика. Ця частина містить ще п’ять інструментів на початковому рівні, які допоможуть вам розпочати свій професійний шлях.
Отже, ця стаття містить наступне:
- State machine diagram
- Activity diagram
- User interface flow
- Functional decomposition diagram
- High-level architecture diagram
Розберімо кожний детальніше.
State machine diagram
У проектуванні ІТ-систем група значень атрибутів і зв’язків елемента* разом — це стан. Діаграма станів — це діаграма, яка описує, як ці стани змінюються за правилами та умовами ІТ-системи.
*кожен елемент може мати стан, який має поведінку: об’єкт, актор, підсистема тощо.
Переваги використання діаграми станів полягають у наступному:
- Дає високорівневий огляд поведінки системи.
- Робить видимим життєвий цикл об’єкта.
Основні частини діаграми станів
- Стан. Група значень атрибутів та зв’язків елемента.
- Подія. Подія запускає зміну одного або декількох станів. Це може бути певний час, виклик процесу, сигнал від іншої системи/модуля або умова.
- Перехід. Показує зв’язок між двома або більше станами. На діаграмі це лінія між переходами, позначена подією.
- Дія. Дія — це компонент із точки зору користувача для взаємодії або спільної роботи зі станом.
Діаграма станів — Джерело: Sparx Enterprise Architect
Activity diagram
Діаграми діяльності часто використовуються під час аналізу бізнес-процесів. Це як потік даних або блок-схема, що визначає ряд дій у системі.
Отже, по суті, діаграма діяльності — це ще одна діаграма бізнес-аналізу, але з іншої перспективи.
Основні частини діаграми діяльності:
- Початкова і кінцева точка.
- Стан діяльності. Не потребує пояснень. Візуально представляє один крок діяльності.
- Шляхи дій. Ілюструють потік дій за допомогою ліній.
- Об’єкти. Об’єкти — це речі, на які можуть впливати дії або навпаки. Дія може змінювати або створювати об’єкт, або об’єкт може змінювати стан дії.
- Рішення. Якщо дія має більш ніж один наступний хід, то перед альтернативними шляхами дії потрібно намалювати прямокутник.
- Синхронізація. Вузол вилки або вузол з’єднання. Вузол розгалуження розбиває один вхідний шлях на декілька. Вузол з’єднання об’єднує декілька шляхів в один.
- Часові події. Якщо подія вимагає часу або зупиняє потік на деякий час, використовуйте символ пісочного годинника.
Діаграма діяльності для бізнес-аналізу — Приклад торгового автомата — Повна роздільна здатність: https://ibb.co/WD6k2Pc
User interface flow (task flow, wire flow) diagram
User interface flow — це дуже простий тип діаграми. Він фокусується на взаємодії з користувачем і показує, як різні графічні інтерфейси з’єднуються для візуалізації конкретного варіанту використання або шляху користувача.
Переваги використання UI flow:
- Розробка шляхів продукту клієнту з точки зору кінцевого користувача.
- UX/UI дизайнери можуть легко зрозуміти зв’язок між різними частинами програмного забезпечення, що полегшує створення прототипів. Тому прототип має набагато кращу візуалізацію та інтерактивність.
User interface flow допоможе вам:
- Розповісти про шлях, який проходить користувач.
- Знайти відсутні важливі кроки в процесі.
- Отримати зворотній зв’язок від зацікавлених сторін.
- Надати підтримку UX/UI дизайнерам.
User interface flow — Приклад входу користувача в систему — Повна роздільна здатність: https://ibb.co/DwYF3sF
Маю зазначити, що наведений вище приклад є спрощеною версією, яку ви можете створити, але існують більш професійні та детальні user flow diagrams. Створення більш складних версій залежить від бажань клієнта, дедлайну, вашої компетентності та стилю візуалізації.
Буде корисно: Вебінар “Артефакти бізнес аналітика: темплейти та приклади”
Щоб охопити всі аспекти, ось ще один приклад user interface flow diagram, створений за допомогою Wireflow (замість UML або BPMN для різноманітності):
Дещо складніший user flow — Джерело: https://www.justinmind.com/blog/user-flow-tools/
Functional decomposition diagram (FDD)
Особисто мені подобається цей тип діаграм на етапах підготовки, проектування та складного пошуку та усунення несправностей. Вона проста для розуміння, легка у використанні й дуже інформативна для всіх зацікавлених сторін проекту.
Функціональна декомпозиція — це метод аналізу, який розбиває складний процес на окремі елементи меншого розміру. Тобто діаграма функціональної декомпозиції — це візуальне представлення ієрархії окремих елементів.
Перш ніж розпочати розробку проекту/системи, ви повинні чітко усвідомити завдання, які має виконувати ваша система або компонент.
До теми – Інструменти ІТ бізнес-аналітика для аналізу та специфікації Бізнесу/Системи – Частина I
Де вона може бути застосована?
- Аналіз бізнес-процесів;
- Функціональний аналіз;
- Вирішення складних, багаторівневих проблем;
- Розробка та підготовка ІТ-проектів та багато іншого.
Діаграма функціональної декомпозиції має кілька переваг у контексті розробки ІТ-проектів:
- Для менеджерів проектів: дозволяє масштабувати, відстежувати та вимірювати робочі зусилля.
- Для аналітиків: допомагає спростити проблему проектування.
- Допомагає визначити та впорядкувати вимоги та функції, які повинна виконувати система.
- Легко переглянути функціональні вимоги до системи та виявити будь-які очікування, які могли залишитися поза увагою під час інтерв’ю/обговорень.
- Для розробників: допомагає розбити систему на менші частини.
Функціональна декомпозиція визначає функції, види діяльності, процеси або дії, які повинен виконувати компонент або модуль програмного забезпечення. — https://binaryterms.com/
Функціональна декомпозиція проста, але може бути каверзною. Почніть із найважливішої, загальної функції вашого продукту, а потім розбийте її на підкомпоненти. Повторюйте до тих пір, поки не отримаєте потрібну деталізацію.
Діаграма функціональної декомпозиції — Повна роздільна здатність:https://ibb.co/DGMX0sD
High-level IT architecture diagram
Високорівневі або концептуальні діаграми ІТ-архітектури часто використовуються для презентації запропонованого рішення клієнтам.
Це не є типовим завданням ІТ-бізнес-аналітика, але як консультант і перша людина, що контактує з бізнесом, ви, імовірно, здатні розуміти й презентувати не тільки процеси, а й технічні системні концепції, проектні плани й майже все, що стосується інформаційних систем, принаймні на концептуальному рівні. Ви працюєте в галузі інформаційних технологій, тому переконайтеся, що ви розумієте основні концепції ІТ-мереж, архітектури програмного забезпечення та принципи ІТ-безпеки, щоб представити замовнику технічне підґрунтя бажаного рішення в доступному для сприйняття форматі.
Залежно від характеру рішення, це може бути архітектура ІТ-інфраструктури або схема архітектури програмного забезпечення.
Приклад високорівневої архітектури застосунку — Повна роздільна здатність: https://ibb.co/DGMX0sD
Підсумок
Сподіваюся, ця стаття була для вас корисною.
Наостанок я хочу дати одну практичну пораду: нема сенсу використовувати ці інструменти тільки тому, що так прийнято. Використовуйте їх тоді, коли це доцільно, якщо цього вимагає клієнт або якщо візуалізація допоможе вам краще розібратися.
Хорошим ІТ-бізнес-аналітиком вас робить не використання інструментів чи знання їх у деталях. Це робить вас хорошим “тренером”. Зрештою, найважливіше — це додана вартість, якість продукту та задоволеність клієнтів.
Оригінальна стаття – IT Business Analyst tools for Business/System analysis and specification, переклад Зеленська Софія, ревью – Іван Вільчавський, зображення від Luca Bravo з сайту Unsplash