Технологии коллективной разработки массового ПО
SPIRIT
Компания SPIRIT является поставщиком функционально законченных, оттестированных и интегрированных программных продуктов для международных компьютерных и телекоммуникационных лидеров (в схеме B2B, business-to-business). Клиентами SPIRIT являются более десять мировых гигантов со штаб-квартирами в Северной Америке и Японии, в частности — NEC, Toshiba, Atmel, Nortel Networks, Furuno, JRC, Sony, Namco, Mitsui, Leica, Samsung и другие. Клиенты SPIRIT поставляют программный код SPIRIT на массовый компьютерный рынок под своим (мировым) именем, что накладывает исключительно высокие требования к качеству и надежности данного программного кода. Покупая аппаратные решения NEC, Toshiba, Atmel, Nortel Networks и других производителей, пользователи приобретают программные продукты от SPIRIT под маркой NEC, Toshiba, Atmel или Nortel Networks. Так SPIRIT реализует свою миссию «Русскую техническую мысль — людям всего мира (в продуктах лидеров компьютерной и коммуникационной индустрии)». Таким образом, ПО SPIRIT пользуются миллионы людей в более чем 50 странах мира. В SPIRIT работает более 50 постоянных разработчиков и большое количество контракторов (временных сотрудников), 100% проектов выполняются для зарубежного рынка. В SPIRIT — шесть основных лабораторий, специализирующихся на DSP (факс-модемы и обработка речи), GPS и Computer Vision. О том, как организован процесс создания ПО в SPIRIT, мы попросили рассказать руководителя Web-лаборатории Раджа Пономаренко.
КомпьютерПресс: Компания SPIRIT известна как поставщик ПО для мирового рынка и солидных заказчиков. В связи с этим нашим читателям было бы весьма интересно узнать, как построен производственный процесс разработки ПО. Какие требования предъявляются рынком? Как организуется процесс выполнения заказа? Какие ресурсы задействованы в этом процессе?
Радж Пономаренко: Начинается все с этапа формулировки требований к продукту.
Техническое задание (ТЗ) может быть представлено заказчиком (это бывает редко), но чаще ТЗ пишет команда SPIRIT в диалоге с заказчиком. В этом случае клиент выполняет по отношению к SPIRIT такую же роль, какую в обычной компании, разрабатывающей массовый софт, осуществляет отдел маркетинга по отношению к отделу разработки. Этап написания и согласования ТЗ является наиболее важным в любом техпроцессе, поскольку известно, что, чем раньше заложена ошибка, тем дороже обходится ее исправление.
В ТЗ полезно четко согласовать, как будут проходить приемка и тестирование, то есть описать конкретные количественные характеристики и методики их оценки и проверки. Обычно для коммуникационного софта требуется глубокое тестирование как на симуляторе канала, так и «в поле». «В поле» — это когда технические специалисты SPIRIT, выполняя работу для Nortel, например, проводят пару месяцев в Columbia Telecom или China Telecom, покупающих оборудование Nortel с софтом SPIRIT.
На этапе ТЗ обычно оговариваются средства разработки. Что касается наиболее типичных для SPIRIT продуктов (а это в основном так называемое math-intensive-программирование), в основном используется C с ассемблерными вставками. Ассемблер требуется для решения Real-time-задач, где необходим высокий уровень оптимизации не на уровне только кода, но и на уровне процессора. SPIRIT является единственным в России авторизованным поставщиком программного обеспечения для Texas Instruments, и DSP-процессоры TI C54x часто являются удобной платформой для разработки.
Для внутреннего применения на промежуточном этапе используются Borland Delphi, С++, MathCAD, Matlab, Labview и множество других систем.
Следующий этап предполагает составление календарного плана и определение порядка сдачи. На этом этапе в основном используется MS Project.
КП: Как определяется состав исполнителей, необходимый для выполнения и руководства проектом?
Р.П.: Опыт SPIRIT показывает, что достаточно важно при организации способа общения с заказчиком обеспечить принцип «равного с равным» — с точки зрения уровня восприятия проекта. Иначе люди начинают говорить на разных языках. Обычно если проект небольшой, то общаются два человека: так называемый менеджер по продукту со стороны SPIRIT и представитель заказчика. Менеджер по продукту — это человек, который отвечает не только за выполнение проекта, но и за то, чтобы клиент остался доволен.
Менеджер по проекту непосредственно общается с разработчиками — с группой ведущих программистов, каждый из которых руководит группой программистов, работающих в рамках некоторого специализированного направления.
Проект разбивается на максимально независимые части, во главе которых как раз и находятся ведущие программисты. В зависимости от типа проекта это может быть, например, группа алгоритмистов, группа системщиков и пр.
КП: А как происходит состыковка частей, которые производят отдельные подразделения?
Р.П.: Каждая из групп создает часть продукта, которая на каждом этапе стыкуется с разработками других групп. При разработке используется продукт Source Safe (входит в стандартную поставку MS Visual C) — продукт группы Version Control, который позволяет отслеживать целостность проекта. Source Safe, во-первых, отслеживает все изменения и сохраняет их и, во-вторых, гарантирует целостность проекта при его изменении. Использование Source Safe позволяет отслеживать, кто и когда внес те или иные изменения, и «откатиться» на эту стадию разработки вплоть до начала проекта.
КП: Какую документацию требуют представлять заказчики на разрабатываемый продукт и насколько трудоемко создание сопроводительной документации?
Р.П.: Качество продукта и степень его отторжимости очень сильно зависит от качества документированности. SPIRIT имеет опыт поставки клиентам продукта с объемом исходных текстов более миллиона строк. Понятно, что клиент не сможет понять и поддерживать такой продукт, если нет соответствующей документации. Документирование проекта нужно не только заказчику, но и разработчику. Причем если рассматривать влияние документального сопровождения на скорость выполнения проекта, то становится очевидно, что в начале скорость разработки замедляется, однако впоследствии она увеличивается за счет экономии времени на выяснение проблем и стыковки и взаимозаменяемости разработчиков. Отсутствие документации может просто погубить проект.
КП: Предъявляет ли заказчик требование к соблюдению каких-то стандартов на написание кода?
Р.П.: Клиент может сам спускать четкие стандарты на написание кода, причем иногда эти стандарты требуют весьма подробного соблюдения инструкций на оформление кода и описание алгоритма. Иногда наличие внешних стандартов, которым надо следовать, может сильно увеличить объем работ.
КП: В случае если клиентом не оговорены специальные стандарты на оформление кода и алгоритма, видимо, существует некий внутренний стандарт, регламентирующий эти правила?
Р.П.: Да, конечно, существует внутренний стандарт SPIRIT, который включает требования к оформлению алгоритма, кода и документации.
Известно, что языки высокого уровня содержат массу возможностей реализации тех или иных конструкций, причем не все они безопасны.
Оформление программ также может быть сделано по-разному, и, конечно, читаемость программ упрощается, когда есть некий единый стиль оформления и программирования.
Аналогичные требования формулируются для оформления алгоритма. Этим, кстати, SPIRIT отличается от многих других фирм. Мы оформляем алгоритмы не менее тщательно, чем тексты самих программ. Например, рекомендуется оформлять блок схемы с помощью такого продукта, как MS Visio, требуется определенный уровень детализации и т.д.
Определенные стандарты существуют на тестирование, и основной принцип при тестировании заключается в том, чтобы отлаживал программу не тот отдел, который ее пишет. Другими словами, в «высокоразвитых» коллективах программистов эффективно работает разделение труда. Например — алгоритмист, кодировщик, тестер, библиотекарь, коммуникатор. В крупных проектах группа тестирования обычно создается на постоянной основе и включает специалистов, которые ничем другим не занимаются. Группа тестирования взаимодействует с каждым из ведущих программистов, как показано на схеме типичной структуры исполнителей по проекту в SPIRIT. Причем еще на этапе технического задания определяются программы, которые будут использоваться для тестирования. Особенно актуально тестирование математической библиотеки. Иногда такая задача по своей сложности превосходит задачу ее создания.
Обязательно ведутся журналы обнаруженных проблем, и в журнале есть графа, в которой записывается, будет ли вообще решаться та или иная проблема, а если будет, то на какой стадии.
КП: Сколько времени занимает тестирование?
Р.П.: В среднем тестирование занимает столько же времени, сколько и разработка. Причем чем больше продукт, тем больше (не в абсолютном, а в относительном плане) уходит времени на тестирование. Замечания рынка (через клиента) принимаются и в течение всего периода поддержки, который обычно длится один год после сдачи продукта клиенту.
КП: Я думаю, нашим читателям, многие из которых — будущие программисты-профессионалы, интересно услышать ответ на вопрос, какие средства разработки стоит изучать в первую очередь, чтобы стать перспективным специалистом и иметь возможность работать в престижной компании, такой, например, как SPIRIT.
Р.П.: Если говорить о текущем моменте, можно утверждать, что сегодня везде нужны специалисты со знанием Java и люди, умеющие пользоваться разного рода Интернет-приложениями.
Если думать о завтрашнем дне, то лучше изучать какую-либо прикладную область математики и программирование как науку, тогда вы будете не так зависеть от текущей моды. Опыт же кодирования придет сам. По-видимому, я не открою Америки, если скажу, что помимо навыков кодирования необходимы фундаментальное изучение математики и хорошее знание английского языка.
КомпьютерПресс 12'2000
