В последнее время приходится часто наблюдать нигилистическое отношение к проектированию программно-аппаратных систем. Частично этому способствует широкое, но недостаточно осознанное распространение Agile методологий (см. О вреде Agile ). Значение и обоснование роли проектирования приведено в статье « Эффективность UML ». Здесь я хочу добавить личный опыт, хотя для «нигилистов» это, наверное, не аргумент – каждый хочет учиться на своих ошибках.
В начале 90-х участвовал в комплексной разработке информационных систем для Объединения «ГЖЕЛЬ» (фарфор). Тогда это был большой и богатый производственный комплекс, объединяющей 12 заводов. Работал в Совместном Российско-Британском предприятии «Комплекс-Бродвей Компьютерс Сайенс Сервисез». Среда разработки была по тем временам очень высокоуровневая – Dbase 4. В те времена это был модный класс технологий-методологий, именуемый Rapid Development (звучит похоже на Agile – не правдо?). Действительно, программисты получали начальный набор требований к разработке (типа Back Log). Дальше разрабатывали системы, с частыми релизами, с показом Заказчику. Подобно я делал АРМ (автоматизированное рабочее место) «Сбыт» (сбыт продукции – архи важно и эффектно для компании). Я очень старался, делал быстро, показывал заказчику часто, и через 3 месяца сдал. Все хорошо, но через полгода Заказчик решил отказаться от технологии Dbase 4 – уж больно медленно все работало, и требовало много вычислительных ресурсов. Нам поручили переделать системы по более эффективной с точки зрения производительности, быстродействия систем, требований к вычислительным ресурсам. Использовали библиотеки CodeBase для С и С++ для работы с базами данных (DBF), разработки пользовательских интерфейсов и отчетов. Помня эпопею с разработкой подсистемы «Сбыт» на основе высокоуровневых средств (Dbase 4), боялся, что займет много времени (с использованием низкоуровневых средств).
Однако это заняло 2 недели – т. е. в 6-7 раз быстрее.
В чем разница? Разница в том, что этап проектирования был уже сделан.
Вывод – качественное проектирование может сократить время разработки в разы (даже во много раз).
В 1996-1997 годах работал программистом в Центральном Телеграфе РФ (это не телеграммы – это одна из крупнейших телекоммуникационных компаний РФ (по крайней мере на то время), предоставляющая сотни видов услуг, организациям и физическим лицам). В я пришел в августе, нам сообщили что на разработку новой комплексной билингвой системы дается 3 месяца (технология Oracle DB, Developer 2000, PL/SQL), затем 1-2 месяца опытная эксплуатация, затем ввод в промышленную эксплуатацию. Нас 4-5 программистов. Казалось это нереально. Но нас успокоили – компания ФОРС за последние месяцы провело детальное проектирование системы (с использованием средств Designer 2000). Мы действительно сделали все в срок. Система заработала на всю страну.
В конце 90х участвовал в проекте по разработке информационной системы Федерального Казначейства РФ (работал в компании Avicomp Services AG). Это была глобальная система масштаба страны, обеспечивающее распределение и доведение до потребителей бюджетных средств страны, имеющая 3-и уровня – центральный, региональный, муниципальный. Огромное количество системных требований, сложная архитектура, особенно в части объектов данных, требовали высокой координации всех участников разработки, четких интерфейсов между подсистемами, модулями, компонентами. К тому же четкие сроки сдачи и бюджет. Никакой Agile и «коленочной» разработки быть не могло. Достаточно высокий уровень проектирования на основе технологий и методологий Oracle CDM/PJM, комплексное проектирование средствами Designer 2000. Проект был сделан, хотя и с напрягом, но в срок. Система была сдана и заработала на всю страну.
В 1999 и 2000 годах работал в Германии (в Кельне) в компании Telesens AG. Разрабатывали билингвою систему для Deutsche Telecom. Конечно, существенное проектирование было проведено – это системный анализ (требования) и детально прописана архитектура системы. Без детального проектирования объединить работу команд в разработку единой системы, с едиными замыслами и идеями, обеспечивающими конкурентные преимущества, было просто невозможно. В качестве инструментальных средств проектирования немцы использовали Rational Rose (UML). Меня назначили руководителем группы разработки – 4-5 человек (Team 4, я назывался группен ляйтер). Таких групп было – 4-5. Разрабатывали на С++ под Sun Solaris, БД Oracle. На уровне команд разработки были некоторые вольности. Некоторые команды только кодировали на основе информации из архитектурных документов, включающих UML и описания. Некоторые проводили детальный дизайн (проектирование) классов и компонент C++. Я, в своей команде решил делать так (используя тот-же Rational Rose). Полностью занялся проектированием классов и компонент. Программисты получали описания классов, методов, алгоритмов, реализующих методы.
В итоге – команды, где часть разработчиков (1-2 человека) занималась проектированием разрабатывала модули быстрее, качественнее (по результатам тестирования), предсказуемее (меньше рисков по срокам), чем команды, в которых все программировали.
Дополнительные плюсы у команд с проектированием – когда поручили документировать разработку – у нас уже все было (генерируемая документация), высокая взаимозаменяемость разработчиков, быстрое вхождение, кроме разработчика информацию о классах, компонентах модулях имеет проектировщик (как устроен модуль, какие компоненты, классы, интерфейсы, алгоритмы, объекты данных).
Другие важные аспекты технологии – комплексное управление конфигурациями и изменениями (Rational Clear Case, Clear Quest).
Как результат, комплексная биллинговая система была сделана в срок.
Далее вернулся и работал в Москве в Британской компании Protek LLC – разработка биллинговых систем. Проектирование при разработке конкурентных систем- продуктов – самая важная вещь. Это и тщательный анализ требований (системный анализ) для выявления важных для потребителей инновационных возможностей. Это инновационная архитектура, покрывающая функциональные и нефункциональные требования. Итеративный подход к разработке (в том числе Agile методологии) требуют быструю демонстрацию результатов и обратную «связь» от потенциальных заказчиков и заинтересованных лиц. На начальных, но самых важных при разработке программно-аппаратных продуктов этапах, модели систем (модели бизнес-процессов, требований, архитектур) являются самыми важными результатами – по сути прототипами системы, наряду с программными прототипами. Проектные документы (включая модели) обсуждаются между аналитиками, архитекторами, потенциальными заказчиками (в части покрытия бизнес-процессов и новых возможностей). Доказывать эффективность тех или иных решений всем заинтересованным участникам проекта необходимо до начала разработки, т.к. сколько-нибудь показательная разработка займет много времени и ресурсов, с очень высоким риском выброса в «корзину» как не эффективное решение. Использовался весь комплекс проектирования и инфраструктуры разработки Rational (включая Rational Rose UML).
Следующий, показательный момент – начало работы в компании ОАО АТС (Росэнерго) – 2004 год. ОАО АТС – Все-Российская оптовая биржа электроэнергии. Запускалась основная – биржевая система. Разработчики от субподрядной компании очень торопились, работали прямо по Agile – быстрые итерации с показом Заказчику (АТС), разумеется без какого-либо проектирования. И, кстати, сдали вовремя, биржа заработала. Далее надо было перенять их разработку для сопровождения и развития собственными силами (ИТ департамент 150 человек, включая программистов, аналитиков, службу эксплуатации, ….). Мне, и еще 2-м программистам поручили разобраться и взять на сопровождение. Срок – 3 месяца. Тут я впервые столкнулся с результатом Agile. Сопровождать систему мог только один человек – автор системы (от субподрядчика). Это был очень гениальный и эффективный человек (без кавычек) – раз мог такое сопровождать и развивать. Полагаю он мог перемножать 10ти значные числа в уме за несколько секунд, брать корни логарифмы больших чисел, и.т.д. Архитектура была проста (не вдаваясь в технологию разработки) – по сути это был один гигантский модуль, даже, можно сказать, одна процедура. Передача управления между частями через операторы «go to», все переменные глобальные, система много поточная (multi thread), потоки начинались и заканчивались в произвольных местах программы. Короче – «ужас», не для «слабонервных». В будущем еще не раз похожие вещи встречал в Agile командах.
Я, с коллегами, начали реинжиниринг системы, включая вычленение логической структуры, модели процессов, модели данных, модели системных требований с взаимной привязкой всех элементов проектирования. Делалось в Rational Rose по многопользовательской технологии с версионированием. За 3 месяца мы выполнили реинжиниринг и, как результат были в состоянии сопровождать систему, еще в течение 2-х месяцев система полностью была передана на сопровождение в ОАО АТС. Вскоре ее заново спроектировали и реализовали – систематично, архитектурно – как надо.
Следующий, показательный момент из недавнего прошлого. Это ИТ подразделение одной из крупнейших телекоммуникационных компаний России (может самая крупная), часто в рекламе на ТВ. Разработка новой единой биллинговой системы компании. Большая разработка – порядка 3-4 лет, задействовано порядка 100 человек, ежегодная стоимость - миллиарды. Методология Agile на основе Scrum. Проектирование тоже имеет место, и существенное. Есть аналитики, архитекторы, интеграторы, …. Есть технология проектирования на основе Sparx Enterprise Architect.
Проблема – влияние Agile на проектирование и разработку системы. Agile не предполагает глубокого анализа требований и проектирования архитектуры. Сразу в «бой» по задачам из backlog. Ни аналитики, ни архитекторы не «осознали» системы в целом – начали решать текущие задачи в не осознанной, не оптимальной последовательности. Результат:
• Решение отдельных задач – программные «заплатки»;
• Очень низкая степень повторного использования кода – нет часто используемых общих компонент;
• Разные команды разработки (и проектирования) реализуют похожие задачи.
Результат – провал и закрытие проекта после нескольких лет работы.