47383 (Компания Borland Software Corporation)

История

Некоторые из вас помнят 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, доступ через веб-браузер.

Рассмотрим несколько подробнее функции CaliberRM, поскольку этот инструмент может быть полезен не только в разработке программных продуктов, но также и в любой другой отрасли.

Система состоит из двух компонент - клиентской и серверной части. Прежде чем начать работу, в вашей сети необходимо установить, как минимум, один сервер, доступный всем заинтересованным сторонам,- хотя он и использует в своей работе SQL-сервер, но для пользователей методом доступа является специальный метод CORBA IIOP для доступа к объектной базе данных. Сервер Caliber является сервером CORBA, а в качестве реализации CORBA в него встроен Borland VisiBroker. Настройки параметров сервера Caliber производятся через Control Panel.

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

Записи пользователей содержат информацию о пользователе, которая впоследствии может быть использована системой: например, адрес электронной почты - для автоматических рассылок и нотификаций по событиям, связанным с тем или иным проектом. Для более эффективного управления пользователи подключаются к группам.

Главной сущностью CaliberRM является проект. С ним связано текстовое описание, список групп, имеющих доступ к проекту, глоссарии и сроки завершения. Важной частью являются связи проекта с другими инструментами, такими как Borland Together, Test Director, SELECT, SCM или Caliber RBT. Быстрый переход между данными в различных системах, отслеживание связей и их автоматическая синхронизация (traceability), является ключевым качеством CaliberRM, существенно влияющим на качество получаемых результатов и общую производительность.

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

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

Очень важным - при правильном использовании - является пункт Дискуссия. Это то место, куда все заинтересованные пользователи пишут свои posts, то есть замечания и соображения. Сообщения поступают в общую очередь, и желающие могут обсудить отдельные сообщения, подобно тому, как это происходит в группах новостей.

Для каждого из требований ведется история изменений, реализованная очень изящно: при каждом сохранении элемента требования порождается новая версия, снабженная комментарием и пометками о том, кто и когда внес изменение. На любом этапе вы можете "откатиться" и восстановить в памяти все стадии эволюции отдельного требования или всего проекта.