История
Некоторые из вас помнят Borland еще с тех пор, когда она выпустила первый turbo-компилятор для языка Паскаль. Для молодого же поколения программистов напомню, почему и при каких обстоятельствах "Борланд" стала легендой для разработчиков по всего мира.
Первым легендарным продуктом "Борланд" был Turbo-Pascal, созданный - точнее, лицензированный у немецкого разработчика Андерса Хейлсберга - в 1983 году. Впоследствии Андерс стал ведущим разработчиком "Борланд" и был архитектором всех версий Turbo-Borland и первых версий Delphi. Первая версия была очень быстрой, однако еще не использовала многих возможностей, появившиеся позже.
Следующим прорывом была настоящая оконная среда разработки, IDE и технология подстрочной компиляции. Идея была гениальной: поскольку ввод пользователя в тысячи и миллионы раз медленнее работы даже среднего процессора - получалось, что в момент ввода программы компьютер практически простаивал на 99%. Борланд изменила ситуацию: в момент, когда курсор покидает строку, среда разработки, IDE, частично компилировала эту строку независимо от остальных. В частности, в фоновом режиме проверялся синтаксис, строились таблицы символов. В момент, когда курсор покидал процедуру, компилятор производил оптимизацию на уровне процедуры, связывая коды для каждой отдельной строки в согласованный ассемблерный код. В результате, когда пользователь нажимал собственно Компилировать, результат появлялся немедленно - в отличие от других, пакетных компиляторов. До этого компиляция занимала несколько минут, а в некоторых случаях даже часов.
Дополнительно использовалось еще и инкрементное связывание: поскольку за один раз вы изменяете незначительное количество модулей, можно избежать полной "перелинковки" приложения и просто дополнить исполнимый файл новой версией модуля и перевести на него указатель в таблице модулей. Конечно, при этом старая версия оставалась на своем месте, так что с точки зрения дискового пространства это не самый оптимальный вариант, но для быстрой отладки он вполне подходит. Для последующего получения оптимизированной версии был придуман "чистильщик" - процесс, который удалял не используемые процедуры, на которые нет ссылок из call list. Таким образом, удалось удалять лишний код даже из статически слинкованных библиотек и отдельные не использующиеся методы классов.
Эти идеи были развиты "Борланд" - и вскоре появились Turbo Basic, Turbo Prolog и Turbo C. На сегодня идею предварительного синтаксического разбора, "подстрочной компиляции" и инкрементной линковки используют практически все IDE.
По мере развития объектной библиотеки Borland Object Pascal был задуман и затем реализован проект визуальной среды разработки для Windows, известный теперь как Delphi. Собственно, название это происходит от фразы: "If you want to talk to [the] Oracle, go to Delphi" и было предложено одним из ведущих разработчиков - Денни Торпом (Danny Thorpe). Таким образом особо подчеркивалось, что система с самого начала поддерживает набор объектов для связи с базами данным Oracle SQL - а в то время это было уникальной возможностью для разработки SQL-приложений с удобным интерфейсом пользователя.
Идея Delphi тоже получила стремительное продолжение - появился целый ряд последующих удачных релизов, а также других продуктов, построенных по аналогии, таких, например, как CBuilder, JBuilder и, наконец, Kylix.
Казалось бы: чего еще можно пожелать компании, которая ассоциируется с самыми передовыми продуктами, самыми смелыми инновациями и счастливыми моментами в жизни тысяч программных разработок? Оказывается, возможности развития еще есть - хотя и не в совсем привычной для Borland плоскости.
Время связывать все воедино
Основная проблема разработки во всем мире - высокий, критически высокий процент "брака" и, соответственно, низкий процент выхода конкурентоспособной продукции. Статистика гласит: из четырех проектов по создания программных продуктов один так и не будет завершен, перестав на каком-то из этапов получать финансирование. Еще два проекта находятся не в лучшем положении: деньги на завершение находятся, однако продукт, полученный в результате, оказывается неконкурентоспособным - то есть он просто не обладает необходимыми пользователю характеристиками, и эта ситуация не разрешается в приемлемый срок. И только около 25% программ доходят до рынка и занимают свое место в "потребительской корзине".
Было проведена масса исследований и результат уже ни у кого не вызывает сомнений: причина подобной ситуации - в недостаточном планировании, недостаточном исследовании целей разработки и неудовлетворительном производственном цикле. И именно на создание бесперебойного "конвейера" при создании ПО нацелены все новые разработки Борланд - как собственные, так и приобретенные в результате слияния компаний.
Процесс должен быть периодическим
Неверное представление о жизни (и о работе в частности) исподволь закладывается в нас еще во время обучения в вузе. Современная система обучения предполагает "однопроходный" подход: начало - прослушал курс - сдал зачет - конец. На самом же деле ситуация "конец" в реальной жизни не наступает никогда. Или, если выражаться точнее, является крайне нежелательной - для разработчика она означает завершение жизненного цикла продукта и уход его с рынка (или снятие с эксплуатации у заказчика). Нормальной должна быть ситуация, когда после определения требований к системе, анализа, разработки, реализации и тестирования (в том числе и в процессе эксплуатации) возникали бы новые требования на основе реакции пользователей - и, соответственно, цикл повторялся бы снова.
На уровне участников процесса (актантов) каждый специалист должен обладать хорошо формализованным интерфейсом: получать входные данные и генерировать нужный результат, вне зависимости от действий соседних участков.
Суть идеи - в разграничении полномочий и независимости операций: согласно Унифицированному Процессу, реализация и даже тестирование должны начинаться так же скоро, как скоро появляются первые данные от архитекторов. В результате запросы на исправления (Requests for Change) будут генерироваться на самых ранних этапах (в результате тестирования) и проходить с самого начала через цепочку анализа, реализации и снова тестирования. К тому времени как система начнет эксплуатироваться у заказчика, нормальный производственный цикл уже будет приведен в действие.
Таким образом, это не уход от решения проблем, но распределение их на более ранние периоды разработки - так сказать, "по небольшой проблеме каждый день". При этом становится невозможной ситуация "все деньги мы потратили, но ничего не получилось" - всегда можно контролировать количественные параметры прогресса. В худшем случае остается выбор: либо завершить работу на раннем этапе, частично защитив инвестиции, либо довести разработку до промежуточного финиша (например, создав рабочую библиотеку компонент, которую можно использовать в другом проекте или продавать независимо). По крайней мере, в результате использования Унифицированного Процесса будет создана уникальная база знаний (например, в виде UML-диаграмм) в предметной области, что само по себе является ликвидным активом.
Итак, задача сводится к организации циклического, формализованного и автоматизированного процесса разработки. Именно для организации такого процесса "Борланд" тщательно подобрала и доработала ряд продуктов, которые теперь составляют основу новых сред разработки.
CaliberRM: анализируй
В основе всех новых (или приобретенных) продуктов Borland лежит ряд эвристик, сгенерированных в университете Carnegie-Mellon, с которым у этой компании давние и прочные связи. Основной тезис всех исследований можно сформулировать таким образом: "чем больше будет думаться в начале, тем меньше придется переделывать в конце". Было исследовано достаточное количество проектов на предмет "предварительного изучения требований и количества последующих переделок в системе". В численном выражении это выглядит приблизительно так: если затраты на определение предварительных требований составляют 5-6%, то переделки обычно обходятся в сумму на уровне 70-80%! Если же на начальном уровне затратить около 15% ресурсов на определение и формализацию требований, то уровень переделок составит приблизительно 30-40%.
Конечно, на самом деле за всем этим стоят вполне конкретные и более осмысленные числовые величины, но общий смысл ясен: сроки разработки можно сократить, а стоимость снизить, если больше времени уделить предварительному планированию.
На этапе определения требований к системе важно придать полученным от пользователя сведениям формальный и детерминированный вид. Также важно разделить полномочия: отдельный человек или система собирает желаемые требования, Change Requests, такие как исправление ошибок или добавление/модификация функциональности и интерфейса. Команда архитекторов принимает решение по каждой позиции: реализовать ли в ближайшем багфиксе, отложить ли до новой версии или же вообще "до лучших времен". Ясно, что с точки зрения каждого пользователя его требования - самые важные. И если не создать барьер между пользователем и разработчиком, то последний может быть просто блокирован запросами на изменение, далеко не все из которых стоят внимания.
Для сбора и формализации требований к программному продукту (но фактически это может быть использовано и для любых других систем) предназначен новый (для "Борланд") инструмент - CaliberRM. В названии присутствует RM, что означает Requirement Manager - то есть система для учета, классификации и отслеживания жизненного цикла требований. Естественно, такой инструмент работает в сетевом окружении и предназначен для групповой работы с общим репозитарием. Также совершенно в духе времени существует несколько методов доступа к информации: отдельные инструменты, интегрированные в IDE "всплывающие" модули, межплатформенный графический интерфейс Java, доступ через веб-браузер.