Об одном подходе к выполнению программных проектов

Сегодня на рынке ПО действует множество компаний от мелких фирм до крупных корпораций, технология работы которых, несмотря на то, что все они выпускают один продукт - программы, зависит как от самого проекта, так и от условий бизнеса предприятия. Возможно, российским читателям будет интересно узнать о том, как организована работа отделения CAM корпорации Unigraphics Solutions, ранее известной как EDS Unigraphics.

Корпорация Unigraphics Solutions специализируется на интегральных решениях в области СAD/CAM/CAE, а с появлением продуктов типа IMAN и в сфере PDM [1]. Как видно из рис. 1, подразделения компании (разработка и маркетинг) расположены по всему земному шару. Конкретно за создание программного продукта отвечают центры в St.Lois (США) - штаб-квартира и координация работ, Cypress (США) - основная концепция и идеология системы, Кэмбридж (UK) - разработка и развитие библиотеки Parasolid и системы IMAN силами группы из 70 человек (наукоемкие и сложные продукты естественно лучше разрабатывать, опираясь на потенциал научных центров). В промышленных районах Бостона и Детройта работают отделения корпорации, специализирующиеся на решении задач изготовления оснастки, прессов, литья. Имеются группы, постоянно работающие со стратегическими партнерами: Сиэтл (Boeing) и Детройт (General Motors), Япония - Fujitsu. Кроме того, бригады программистов сосредоточены в Израиле и Индии. Таким образом, структура распределенной работы позволяет организовать непрерывное производство программ 24 часа в сутки. На разработку новых решений отпущено 50 млн. долл. в год и, как следствие, версии системы UG появляются примерно два раза в год, что, кроме включения (в среднем 150) новых функций, подразумевает перенос на платформы DEC, Sun, SGI, IBM, HP и Intel.

В Германии находится 6 офисов - в Кельне сосредоточена разработка части интегрированной системы UG, отвечающей за CAM [2]. Здесь работает 400 программистов, консультантов и менеджеров, координирующих деятельность 35-40 групп по CAM.

Источники вдохновения

Обо всех пожеланиях, поступающих от клиентов, сотрудники местного офиса корпорации докладывают на ежегодной конференции локальных пользователей. В результате отбираются предложения по новым версиям, которые делегатами от локальных групп выносятся на европейскую и мировую конференции корпорации и, после утверждения, реализуются в модулях системы UG.

В ходе конференции обсуждаются все, даже самые невероятные, на первый взгляд, идеи. Мало того, атмосфера открытости при принятии решения о необходимости тех или иных изменений в системе базируется на дискуссии вокруг вопроса: какую бы систему CAD/CAM/CAE вы как пользователь выбрали, если бы начали свой бизнес сегодня? Бывают случаи, когда постоянные клиенты делают свой виртуальный выбор в пользу альтернативных систем автоматизации.

Однако, если говорить точнее, у корпорации имеется четыре источника вдохновения:

• конференции;
• запросы крупных стратегических клиентов: GM, Opel, Siemens и др.;
• научные исследования;
• специфические требования отдельных групп пользователей из определенных отраслей (часто небольшие изменения оказываются полезными для всех клиентов).

Перед принятием решения о начале разработки проводится оценка ресурсов, необходимых для реализации новых предложений. Утвержденный на конференции план по подготовке программных решений становится законом для разработчиков.

Развертывание работ над проектом

После принятия решения о начале работ по пакету новых предложений происходит следующее:

• сортировка предложений по сложности и времени их реализации;
• разработка плана реализации, консолидация ресурсов;
• определение принципиальных требований, архитектуры решения;
• формирование спецификаций для кодировщиков программ.

Изначально модульная архитектура пакета UG и наличие общего, унифицированного интерфейса позволяют группе подготовки решения независимо экспериментировать с новыми предложениями. С помощью макросов всегда можно сделать прототип новой функции, провести его тестирование при участии клиентов и затем подготовить отчет. Результаты работы данной группы рассматривает технологический совет, который имеется для каждой отрасли, где применяется система UG (аэрокосмическая, автомобильная промышленность, товары народного потребления, машиностроение, медицина, электроника). Окончательное решение о сроках и контрольных датах принимается советом коллективно - для подразделения CAM это 6 человек.

Затем требуется оценить возможности имеющегося инструментария для решения вновь поставленных задач. Выбор инструментария для разработки осуществляется в центре, в г. Cypress. Основной комплект включает язык программирования Си, ОС Unix/Motif, а теперь и NT. Даже если программист или консультант предложит какой-нибудь "суперинструментарий", его, скорее всего, однозначно не примут или, в лучшем случае, только рассмотрят. Базовые средства разработки обязаны быть предсказуемыми и не должны повышать риска выполнения проекта. В этом смысле работа с продуктами MS из-за их нестабильности в ряде случаев представляла для корпорации проблему. При оценке инструмента всегда должна быть уверенность в его перспективности.

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

Кроме общесистемного инструментария разработчики корпорации имеют доступ к библиотеке общих функций. Используется три уровня библиотек:

• для всех разработчиков;
• для работающих над проектами в рамках одной прикладной области;
• локально для одной команды, работающей над одним проектом;

Обычно раз в сутки происходит обновление библиотеки общих функций. Этим занимаются консультанты и менеджеры проектов из центра в Cypress.

Команда разработчиков

В корпорации имеется список требований, в соответствии с которыми менеджер проекта может перемещать специалиста по служебной лестнице:

1. Стажер (Associated)
2. Специалист
3. Старший специалист
4. Ведущий специалист
5. Консультант

Первые три ступени не требуют высшего образования, сотрудники данного уровня выполняют всю работу по кодированию и разработке программ. Квалификация, соответствующая уровням 4 и 5 позволяет специалистам принимать участие в проектировании, тестировании и разработке архитектуры системы.

Вознаграждение программиста обычно не зависит от качества программы (точнее сказать, ее кода) или от того, сколько времени заняла работа. Считается, что суперпрограммы (выполненные с опережением графика, короткие или работающие намного быстрее, чем было предусмотрено заданием) - это недостаток. Требует выполнять работу в точном соответствии со спецификацией. Иначе повышается риск выполнения проекта: перенос на другие платформы, внесение изменений, устойчивость программы. Кодирование - вовсе не творческая работа - это чистое ремесло, поэтому неудивительно, что на его выполнение отводится только 5% от всего времени работы над проектом.

Однако это не означает, что стимулов к работе нет - специалиста качественно и в срок выполняющего все задания, имеющего соответствующее образование переводят в консультанты или менеджеры проекта. А вот з/п менеджера уже зависит непосредственно от результатов выполнения проекта: сроки, тестирование, соответствие спецификациям.

Формирование спецификаций, организация работ и контроль

Все спецификации на новые функции унифицированы (врезка), что позволяет достаточно просто оценить результат и проверить соответствие программы исходным требованиям.

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

Обычно на разработку новой функции отводится от 1 до 6 месяцев. При этом каждые две недели составляется отчет в произвольной форме о ходе продвижения работ (для кодировщиков из Индии - еженедельно). Иногда бывают и ошибки в планировании реального времени разработки - известно время выполнения каждой операции, используются усредненные показатели производительности, поэтому общее время разработки заранее известно. Однако, если программа закончена раньше, скучать не приходится - имеется несколько уровней важности работы и заданий всегда много.

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

Спецификация на программный проект

1. Введение

Версия и имя проекта. Общее описание: требования к функциональности (что должно и чего не должно быть); особые требования, высказанные потенциальными пользователями, параметры производительности; место данного проекта, относительно других; требования к системным инструментальным средствам, предъявляемые данным проектом.

2. Описание функциональности

Изложения функций программы; описание структуры данных, их взаимоотношений и порядок использования; общая архитектура проекта и его концепция; функции каждого модуля; внутренние вызовы функций и передача данных через общие структуры; примеры использования новой функциональности, специфические случаи и ожидаемые результаты.

3. Взаимодействие

Описание всех диалогов с пользователем; последовательность действий при диалоге; если необходимо, сравнение с уже существующим, аналогичным диалогом в предыдущих версиях; порядок включения новой функции в уже существующую систему; описание возможных модификаций имеющихся диалогов; ограничения на ввод и значения по умолчанию; описание сообщений об ошибках.

4. Переменные окружения

Описание переменных, которые необходимо изменить/установить в файле unigraphics.def; объяснение значений этих переменных.

5. Языковые интерфейсы

5.1 GRIP
Описание порядка использования вызовов внутреннего языка: перечень констант и переменных, новые требования и сообщения.

5.2 Пользовательские функции
Полное описание аргументов; специфические требования к компиляторам; возможность использования внутренних функций извне.

6. Требования к тестированию

Перечень параметров или их комбинаций, которые должны или не должны быть протестированы (типы объектов, аппаратная конфигурация, файловая система, размеры файлов и т. п.). Имеются ли модули или функции которые должны или не должны тестироваться вместе с проектом. Имеется ли часто повторяемый код, выполняемый при разных входах в программный модуль (GRIP, пользовательские функции). Если да, то его рекомендуется включить в библиотеки или/и тестовый модуль.

7. Другие моменты

7.1 Производительность
Косвенные факторы, которые могут влиять на производительность; как быстродействие данного модуля соотносится с общими требованиями к продукту.
7.2 Расширения в будущем
7.3 Смежные прикладные области
Перечисление прикладных областей, знакомство с которыми необходимо при выполнении данного проекта.
7.4 Архитектура
Соответствует ли данный проект требованиям к архитектуре, принятой в корпорации?

8. Участие пользователей

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

9. Участие по специфическим запросам

10. Библиография

Литература