По многолетним наблюдениям организации проектирования программно-аппаратных систем в ИТ компаниях и крупных компаниях, организующих внутреннюю разработку, проектирование чаще рассматривается как часть процесса документирования систем. Часто используются развитые средства проектирования, тип Sparx Enterprise Architect (средство проектирования с использованием UML, BPMN и ряда неформальных нотаций), но в основном для «иллюстраций» проектной документации. Это, конечно, неплохо, но теряется главная идея систематического проектирования с использованием стандартных инструментов и нотаций – само проектирование систем – поддержка творческого процесса проектирования техническими средствами, коллективный творческий процесс.
К сожалению, в последнее время, многие разработчики программно-аппаратных систем, воспринимающие Agile методологию «буквально», стараются избегать процесс проектирования вообще, полагаясь на «быстрое» кодирование, демонстрацию системы овнеру и коррекцию требований к системе.
Проблема в том, что проектирование – объективный, неизбежный процесс при разработке программно-аппаратных систем. Разница в подходах:
• Системный подход, основанный на знаниях по разным аспектам проектирования. Моделирование является частью систематического подхода.
• Несистемный подход. Часто «в уме», в «разговорах», как правило не основывается на знаниях в областях проектирования. Очень нравиться «начинающим» программистам – они считают, что, научившись кодировать они уже достигли всего, никаких новых знаний и умений уже не надо (принцип, если я чего-то не знаю, то это не нужно и вредно).
По сути, проектирование систем, очень соответствует Agile концепции (если не относиться к некоторым методологиям «буквально»). Проектирование (может быть итеративным – «релизным») дает «быстрое» представление о будущей системе для различных групп заинтересованных лиц (заказчики, руководители проектов (спонсоры), аналитики, архитекторы, программисты, тестировщики, специалисты по внедрению, …). Обратная связь (корректирующая информация) приводит к уточнению модели системы, как следствие сокращение количества итераций по разработке (в частности программированию) системы. Учитывая, что проектирование системы – существенно более дешевый и быстрый процесс чем разработка (включая программирование), проектирование приводит к удешевлению и ускорению общего процесса разработки системы.
Много приходилось участвовать в проектировании систем с конца 1990х до настоящего времени. Сначала это был Oracle Designer 2000, потом Rational Rose (UML), средства проектирования IDEF, сейчас, в основном, Sparx Enterprise Architect (UML, BPMN, …). Проектирование включает много аспектов (соответственно роли проектировщиков), например:
• Бизнес анализ;
• Системный анализ;
• Архитектура;
• Дизайн программно-аппаратных компонентов;
• Сценарии тестирования.
Взаимосвязь моделей по всем аспектам проектирования является одной из основополагающих концепций наиболее распространенной методологии проектирования
TOGAF (IBM, Oracle, Мин обороны США, NASA, …). В терминах TOGAF это понятие Enterprise Continuum.
Бизнес анализ включает описание бизнес-процессов, бизнес-объекты данных, роли участников бизнес-процессов, и.т.д.. Сценарии бизнес-процессов, взаимосвязи сценариев бизнес-процессов, трансформация бизнес-объектов (входящие, промежуточные, исходящие) в рамках сценариев бизнес-процессов, связь между ролями участников бизнес-процессов и бизнес-процессами – все это трудно представить без корректной бизнес-модели. Если для незначительной по размерам бизнес области обойтись мез модели можно (но трудно), то для средней и большой бизнес области это практически невозможно (хотя на практике встречал «гениальных» людей, перемножающих 7 значные числа «на лету»).
По результатам бизнес-анализа выявляются проблемы и потребности бизнеса, которые могут служить входной информацией для следующего этапа проектирования – системного анализа. Модели бизнес-анализа позволяют отслеживать связи между бизнес-проблемами (потребностями) и другими аспектами бизнес проектирования (бизнес-процессами, бизнес-объектами, ролями, …), не позволяя им «подвисать» (не понятно откуда и для чего).
Проектирование требований к системе (систематическое или «умозрительное» бессистемное) без этапа бизнес анализа возможно если бизнес область хорошо известна разработчику. В противном случае на этапе системного анализа возникают большие риски:
• Разработчики системы не охватывают существенных проблем и потребностей бизнеса;
• Разрабатываемая система не «укладывается» в текущую или изменяемую (планируемую) бизнес среду (бизнес-процессы, бизнес объекты, роли, …).
В процессе системного анализа необходимо контролировать взаимосвязь (термин «трассируемость») между требованиями к разрабатываемой системе, проблемами/потребностями и другими объектами бизнес-анализа (бизнес-процессы, бизнес объекты, роли, …). Без моделирования требований к системе и объектов бизнес анализа отследить «трассируемость» сложно (для небольших систем) или невозможно (для больших).
Требования к системе, формируемые на стадии системного анализа, кроме «трассируемости» на объекты бизнес анализа должны учитывать другие существенные аспекты:
• Полнота требований. Должно быть ясно, откуда и как система получает исходные данные, как обрабатывает, куда и как передает. Не должно быть «темных пятен».
• Непротиворечивость требований;
• Отсутствие дублирования требований (прямое и косвенное);
• Однозначность требований;
• «Трассируемость» требований разных типов, разных уровней иерархии (функциональные, нефункциональные, ограничения проектирования, требования к объектам данных, роли пользователей, …). Значению связи между функциональными и нефункциональными требованиями большое значение придается в сервисно-ориентированной ИТ методологии
ITIL (международный стандарт), в частности аспект QoS (качество ИТ сервиса).
Без «понятного» моделирования требований обеспечить вышеуказанные аспекты системного анализа сложно или невозможно. Отсутствие моделирования приведет к высокому риску ошибок проектирования, как следствие большим издержкам на стадии разработки системы в виде переработок.
Далее процесс разработки архитектуры системы.
Для начала, необходимо контролировать «трассируемость» между объектами архитектуры (модули, компоненты (программные и аппаратные), алгоритмы, интерфейсы, фреймворки, …) и объектами системного анализа (требования (функциональные и нефункциональные), информационные сущности, роли, …). В противном случае система не решит поставленных задач (или решит «неудовлетворительно»). Опять-таки, без моделей отследить такую «трассируемость» сложно или невозможно.
Другие существенные аспекты архитектуры:
• Инфраструктура системы;
• Разбиение системы на компоненты.
Выбор программной (фреймворки) и аппаратной инфраструктуры системы «сильно» зависит от нефункциональных требований к системе и характера используемых компонент (программных и аппаратных). Необходимо внимательно контролировать эту зависимость.
Разбиение системы на компоненты (программные и аппаратные) имеет следующие аспекты:
• Максимизация повторного использования компонент существенно сокращает стоимость и срок разработки системы, повышает качество системы;
• Широкое использование стандартных («готовых») компонент;
• Горизонтальная и вертикальная компонентизация. При горизонтальной компонентизации, компоненты выполняют разные функции и мало взаимодействуют друг с другом. При вертикальной компонентизации, компоненты верхнего уровня используют компоненты более низких уровней (Типичный архитектурный шаблон – «архитектурные слои», например, слой пользовательского представления, бизнес логики, стандартных алгоритмов и общесистемных функций, внешних интерфейсов, данных, …).
Разбиение системы на компоненты, кроме возможности повторного использования компонент имеет другое, не менее важное значение – сокращение сложности, а следовательно стоимости и времени разработки системы, а также стоимости сопровождения и развития системы. Одна из наиболее распространенных моделей оценки сложности систем –
COCOMO оценивает сложность системы, в частности, по количеству строк кода. Между сложностью (стоимость и время разработки) и количеством строк кода – степенная зависимость (количество строк в степени > 1).
Тенденция к компонентизации систем привело некоторое время назад к «модной» парадигме –
микро-сервисная архитектура .
Спроектировать эффективную по структуре компонентную систему без использования моделей сложно (хотя есть и особо «гениальные» разработчики). Необходимо видеть эти компоненты, распределение функций между компонентами, связи компоненты, и.т.д.
О влиянии проектирования на стоимость, время разработки и качество программных систем, а также стоимость внедрения, сопровождения и развития систем можно обсуждать много. Не возражаю, что для небольших «коленочных» систем, мелких доработок, проектирование можно не проводить. Для средних и больших систем, «урезание» процесса проектирования, по многолетнему опыту во многих организациях, это путь к «провалу».
