Источники вдохновения
Развертывание работ над проектом
Команда разработчиков
Формирование спецификаций, организация работ и контроль
Спецификация на программный проект
Литература

Сегодня на рынке ПО действует множество компаний от мелких фирм до крупных корпораций, технология работы которых, несмотря на то, что все они выпускают один продукт - программы, зависит как от самого проекта, так и от условий бизнеса предприятия. Возможно, российским читателям будет интересно узнать о том, как организована работа отделения 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.

Picture 1.

Рисунок 1.
Исследовательские подразделения корпорации

В Германии находится 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. Библиография


Литература

  1. В. Абакумов. Система сопровождения проектных данных IMAN. Открытые системы. # 5,1996, с. 62-65
  2. С. Бормалев, С. Червонных. Практическое применение UG в авиастроении. Открытые системы. # 2, 1997, с.43-46

Поделитесь материалом с коллегами и друзьями