73 подписчика

Аналитика в ИТ ч.1

6 февраля 20246 фев 2024

8 мин

Оглавление

Преамбула.
Введение.
Управление проектом или процессом?

Преамбула.

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

Введение.

Эта статья для вас, если вы новичок\самоучка в аналитике, если вы столкнулись со схожей проблемой, что и в преамбуле, а также со следующими:

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

Список проблем можно продолжать...

Управление проектом или процессом?

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

Деятельность - любая осмысленная активность человека или организации (объекты) по воздействию на субъекты для удовлетворения своих неэкономических потребностей. Отсутствие планирования или на уровне "повторить завтра, а завтра будет видно надо ли послезавтра". "Проекты" по поддержке и доработке существующей системы, управляемые по Agile\Scrum.

Проект - временное предприятие, нацеленное на создание уникального продукта, результата, услуги, ограниченное сроками и иными ресурсами проекта (ресурсно запланированная деятельность). Имеет начало и конец, средний горизонт планирования. Целью управления проектом является достижение результата в заданные сроки с учётом ограничений по ресурсам. Критерием эффективности является достижение целей проекта. Проекты, управляемые по Waterfall (Водопад, "разработка по ГОСТ 34 \19, РД 50").

Процесс - повторяемая последовательность действий по преобразованию информации и\или комплектующих\сырья\материалов (входы процесса) в результат (выход процесса). Циклический характер, поэтому нет окончания процесса - есть переход к новому циклу. Планирование на любой горизонт, наличие планов с разной степенью детализации, минимально на 2 цикла вперёд (т.к. процесс по сбору обратной связи в целях постоянного улучшения распространяется не только на опытную эксплуатацию, но и на штатную и является входом следующего цикла). Управление процессом это поддержание постоянного изменения процесса и его результата с целью улучшение качества результата, результативности и эффективности процесса. Критерии эффективности основаны на чётких, измеряемых и оцениваемых количественно показателях. Учитывается цикл жизни продукта. В "проектах" по разработке и существенной переработке существующей системы, управляемых по Agile\Scrum планирование только на один ближайший цикл.

Примечание 2: для того, чтобы избежать проблем 1-4, 6 - нужно понимать жизненный цикл продукта\услуги\программного обеспечения\процесса\проекта и что делают люди после вас, чтобы ваши выходы соответствовали их ожиданиям от их входов.

Ссылка на курс обучения по гибким процессным методологиям будет в конце статьи.

Системный и бизнес анализ.

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

Бизнес анализ — деятельность, которая делает возможным проведение изменений в организации (инкремент в Agile\Scrum), приносящих пользу заинтересованным сторонам (владельцы процессов, бизнес заказчики, функциональные заказчики, государство, спонсор и прочие стейкхолдеры), путём выявления потребностей (требований) и обоснования решений, описывающих возможные пути реализации изменений. Может включать в себя верхнеуровневый системный анализ, анализ бизнес-процессов, верхнеуровневый анализ данных, анализ потоков информации, анализ производственных и логистических цепочек, продуктовый анализ, финансовый анализ и т.д.

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

Примечание 3: часто ограничиваются выявлением потребностей (или трансляцией их от заинтересованных сторон в формате удобном для разработки), что является ошибкой и приводит к проблемам 2-8.

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

Выходы бизнес анализа передаются на архитектурное и системное проектирование (здесь проводится расширенный системный анализ).

Примечание 4: ошибкой является не учитывать НПА и не включать их в документ в удобном для прослеживания и декомпозиции требований формате, что приводит к проблемам 2,4,5,7,8.

Примечание 5: ошибкой является при выявлении бизнес требований и ограничений не учитывать информационные системы при определённом уровне автоматизации и тем более цифровизации (приводит к проблемам 1-5,7), т.к. большая часть бизнес правил реализована в процессах информационных систем. Данный факт усложняет исследуемую систему и требует применения современного системного анализа уже на этапе бизнес анализа.

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

Классический системный анализ - методология решения комплексных проблем развития промышленности, транспорта, обороны, образования и других областей, а также проблем построения организаций, т.е. методология решения сложных проблем с целью принятия решения. Впервые системный анализ получил распространение в США в 50-е годы в форме совокупности системных теорий, концепций и разработок, объектами которых выступала практическая управленческая деятельность. В 50-60-е получил развитие в СССР в качестве исследования операций и системотехники и после углубления понятия и определения, строение и функционирование систем, классификация, модели, закономерности и т. д.) получил общенаучный характер.

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

Общая теория систем - представляет собой логико-математическую область исследований, задачей которой является формулирование и выведение общих принципов, применимых к системам вообще. Не учитывает принцип целостности системы и высокую сложность внутренних элементов, поэтому имеет ограниченное применение. Сформулирована Л. фон Берталанфи в 1947 году, а в настоящее время распространены следующие системные теории: теория на базе теории множеств М. Месаровича; теория в форме алгебраических систем; теория в форме параметрических систем.

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

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

1. Объекты и взаимосвязи, для которых в скобках указаны буква латинского алфавита присутствуют в уравнениях общей теории систем.

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

3. Взаимосвязь совокупности носителя системы (N) (вкл. базу системы и систему) и внешней среды системы (V) с этапами жизненного цикла системы обусловлена взаимным влиянием системы на носитель системы и внешнюю среду в зависимости от этапа жизненного цикла как системы, так и её носителя и внешней среды.На каждом этапе жизненного цикла системы могут различаться её границы, носитель, база и внешняя среда.

4. Взаимосвязь этапов жизненного цикла системы с состояниями совокупности N (вкл. S и B) и V обусловлено зависимостью состояний AS IS ("как есть") и TO BE ("как будет") от текущего и будущего этапа жизни системы, прогнозируемого времени существования системы на том или ином этапе, а также необходимостью отображения промежуточного состояния системы между AS IS и TO BE ввиду сложности изменений.

5. Принцип целостности системы учтён выделением пунктиром слабых (внешнее влияние на систему) и сплошной линией сильных взаимосвязей (внутренние), что соответствует системному подходу и сервис ориентированной архитектуре системы.