Как проектировать системы [часть 0]

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

«Просей то, что ты собираешься сказать, через три сита», — притча о Сократе

«Зависит от контекста», — неизвестный архитектор

Что объединяет все инженерные системы, когда-либо созданные человеком?

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

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

Тут важно понять, что мир вполне может существовать без IT в любых его проявлениях; однако в этом случае трудозатраты на поддержание существующих процессов вырастут настолько, что большинство этих процессов станут нецелесообразными. В этом состоит главная уязвимость постиндустриальной цивилизации: ведь если кому-то придёт в голову уронить мировую финансовую систему, то ему достаточно будет просто отнять excel у бухгалтеров…

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

Если продолжить теоретизировать в этом направлении, то можно составить «портрет» идеальной системы:

• Она предназначена для того, чтобы, в том или ином виде, быть полезной человеку

• Она обладает возможностями, достаточными для достижения этой полезности

• Она обладает свойствами, позволяющими реализовать эти возможности

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

Следует запомнить этот тезис, так как он будет проходить красной линией через всё дальнейшее повествование.

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

«Кому нужна эта система?»

«Чем она поможет этим людям?»

«Сколько мы потеряем, если откажемся от реализации?»

«Сколько мы заработаем, если реализуем её?», — вот те вопросы, на которые отвечает такой артефакт, как видение решения, и последний вопрос — наиглавнейший из них.

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

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

Мало понимать, что делает решение и для чего оно это делает; важно также знать, достаточно ли оно хорошо в этом.

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

Крайне важно обеспечивать преемственность всех артефактов. Они должны не противоречить друг другу, а быть построены вокруг общего смыслового ядра — архитектурной модели. Модель это сущность, хранящая информацию о ключевых свойствах существующей / проектируемой системы, а также методах и способах их достижения. Иначе говоря, модель это «карта» системы, позволяющая ориентироваться в ней и разбивающая её на умозрительные контексты. Модель вовсе не обязательно должна представлять из себя что-то вещественное — для простых решений вполне достаточно сформировать её образ в головах всех участников процесса реализации. Однако на практике чаще приходится иметь дело с материализованными моделями, представленными в различных нотациях. Далее мы обратимся к примеру моделирования в нотации C4.

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

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

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

• Видение определяет полезность системы

• Функциональные требования определяют её возможности

• Нефункциональные требования определяют её свойства

• Модель хранит информацию о системе

• Документация предоставляет «интерфейс доступа» к модели