Анализ требований и проектирование ИТ решений

Последнее время у меня получаются сообщения из серии о единстве и борьбе противоположностей. Управление изменения Standard+Case approach о взаимопроникновении кейс-менеджмента и традиционного подхода к управлению бизнес-процессами, Что такое DevOps о взаимодействии разработки и эксплуатации ИТ-решений и т.д.

Не стану нарушать традицию и сегодняшнее сообщение об анализе требований с одной стороны и проектировании ИТ решений с другой. Казалось бы, эти функции должны быть очень схожи между собой по подходам и методологии, но на практике различия между ними могут быть существенными. Значительно больше, чем между 1-ым и 2-ым уровнем поддержки в ITSM или между разработкой и эксплуатацией. Практически все традиционные методологии развития ИТ решений ориентированы на подход «сверху вниз». Сначала собираем требования, потом проектируем, реализуем, тестируем, развертываем, уходим на следующую итерацию, добавляем новые требования и т.д. без конца. Архитектура больше ориентирована на восходящий подход (bottom-up approach). У нас есть варианты решений(паттерны), мы прикладываем их к задаче и выбираем тот, который подходит наилучшим образом (см. Еще несколько слов о проектировании). Преимущество первого подхода в полноте реализации требований. Сила второго – в простоте, рациональном использовании ресурсов, более высокой вероятности достижения ожидаемого результата.

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

Я думаю, что значительная часть того, что я пишу в своем блоге предназначено не столько для архитекторов, а скорее для системных аналитиков. Ну а по-хорошему к любой информационной системе должен прилагаться некоторый аналитический framework, помогающий осуществлять её настройку и развитие. Что об этом думает мой уважаемый читатель?

Анализ требований и проектирование ИТ решений: 3 комментария

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *