Как небольшой группе воспользоваться методами разработки программного обеспечения, характерными для крупных компаний? Малые группы определенно нуждаются в таких методах, но часто лишены богатства инфраструктуры и эффектов масштаба, присущих большим организациям. В малом коллективе обычно нет ни отдельной группы контроля качества, ни специального парка компьютеров для тестирования, а зачастую даже своего системного администратора. Основательное введение в эти проблемы содержится в отчете Института программной инженерии [1], посвященном совершенствованию рабочих процессов в малочисленных коллективах.

За прошедшие восемь лет число разработчиков в компании Kitware выросло с двух до тридцати. Мы производим коммерческие программные продукты как с закрытым, так и с открытым кодом. Некоторые из них целиком разрабатываются силами компании, другие являются плодом совместных усилий со смежниками, разбросанными по всему миру. В небольших проектах могут быть заняты один-два человека, в крупных — свыше тридцати. Таким образом, приемлемый для нас подход к разработке должен охватывать крупные проекты, насчитывающие тысячи исходных файлов, но иметь достаточно низкие накладные расходы в малых проектах. С учетом этих требований, а также необходимости кроссплатформенной разработки для Windows, Linux и Mac OS, нетрудно прийти к выводу, что любое жизнеспособное решение должно обладать немалой гибкостью.

Наш подход к разработке направлен на решение части упомянутых проблем. Он сложился в ходе работы над такими проектами, как Visualization Toolkit [2] и Insight Segmentation and Registration Toolkit [3], а также над популярными инструментами категории Open Source с тысячами исходных файлов и множеством территориально распределенных разработчиков. Мы также применяли свой подход при работе над ParaView, свободно распространяемой системой визуализации для научных приложений, и закрытой медицинской системой визуализации объемных изображений VolView.

Истоки методологии

В 1999 году американская Национальная медицинская библиотека объявила конкурс на разработку свободно распространяемого комплекта инструментов регистрации и сегментации, который в итоге стал известен под названием ITK [3]. Первоначально в группу разработчиков вошли три коммерческих (GE, Kitware и MathSoft) и три академических партнера (университеты штатов Северная Каролина, Теннесси и Пенсильвания). Перед большим, географически распределенным коллективом была поставлена трудная задача: на языке C++ разработать свободно распространяемый кроссплатформенный комплект инструментов для научных исследований и разработок, который вобрал бы в себя передовые достижения в алгоритмах обработки медицинских изображений.

Перед началом проекта мы изучили все доступные инструменты. Мы также изучили новейшие тенденции в области разработки программного обеспечения. Методики экстремального программирования [4] и разработки, основанной на тестировании (test-driven development) [5], подсказали много хороших идей и помогли нам усовершенствовать свои процессы. Особый интерес представляло требование удобства тестируемости (testability), заимствованное из экстремального программирования. Инструментарий ITK должен был поддерживать множество платформ, к нему планировалось привлечь большое число разработчиков. Принципы экстремального программирования также стимулировали использование стандартов кодирования и коллективное владение кодом. Борьба за качество по методологии Six Sigma привела нас к использованию таких метрик, как ежедневный анализ покрытия кода в ходе тестирования. Во многом наш подход напоминает процесс Agile Unified Process [6] — и для того, и для другого характерны упрощенность, итеративность, инкрементальность и независимость от конкретных инструментов.

Детали процесса разработки

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

Мы старались упростить процесс, чтобы он хорошо сочетался с методами «скорой» разработки, а среди используемых в нем инструментальных средств большую часть составляли инструменты с открытым кодом. Для общения и документирования первоначально использовались программные средства Mailman для организации списков рассылки, Doxygen для автоматического документирования исходного кода и phpBugTracker для выявления ошибок; все они доступны на сайте sourceforge.net. В последние годы мы также используем wiki [7], еще один мощный инструмент коммуникаций. Для контроля изменений мы выбрали систему CVS (Concurrent Versions System) из-за удобства ее клиент-серверной модели, исключающей блокировки [8]. Для процесса сборки в начале работы над проектом ITK не было никаких инструментов, способных строить сложные программы на C++ для всех поддерживаемых платформ, поэтому мы разработали собственный инструмент под названием CMake [9]. Для автоматического тестирования было решено разработать другой инструмент, получивший название Dart. Мы выработали методику совместного использования всех этих инструментов, а недавно приступили к созданию нового инструментария CPack, задача которого — облегчить процесс выпуска версий. Используемая нами методика доказала свою гибкость и адаптируемость к новым инструментам по мере их появления.

Общение и документирование

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

Списки рассылки. Списки рассылки оказались незаменимым средством связи между разработчиками и пользователями. Менеджер списков рассылки Mailman — простой, легкий в управлении Web-инструмент для их создания и обслуживания. Каждый проект обычно имеет список рассылки для разработчиков и список рассылки для пользователей. Рассылка для разработчиков содержит детальные обсуждения проблем проекта. Рассылка для пользователей позволяет им задавать вопросы о работе программ. Пользователи часто помогают друг другу, поэтому разработчики обычно подписываются также и на рассылку для пользователей и даже поправляют советы, кажущиеся им неудачными. На начальных этапах проекта, когда у создаваемого программного продукта ещё нет пользователей, эта рассылка не нужна; когда же проект достигает определенного уровня зрелости, для пользователей имеет смысл создать отдельную рассылку.

Списки рассылки удобны также и потому, что они порождают доступный для поиска архив, который служит источником документации и содержит самые свежие сведения об использовании создаваемого продукта. Таким образом, списки почтовой рассылки — это каналы коммуникаций, благодаря которым по мере развития системы разработчики могут быстро реагировать на изменение условий наподобие появления новой версии операционной системы или компилятора.

Wiki. Превосходное дополнение к спискам рассылки — Web-сайт, который сообщество разработчиков может совместно редактировать. Это позволяет легко документировать обсуждения в списке рассылки. Например, рассмотрим ситуацию, в которой выпуск новой версии компилятора приводит к ошибке компиляции, если в процессе сборки не указать специальный флаг. Первый «счастливец», столкнувшийся с этой проблемой, направит её описание в рассылку для остальных пользователей. Кто-то из разработчиков найдёт обходной путь, объявит об этом в рассылке и попросит пользователя его проверить. Как только тот убедится в правильности предложенного решения, кто-нибудь внесёт поправку в wiki, которая при этом станет частью документации. Мы используем свободно распространяемый инструментарий MediaWiki с открытым кодом.

Doxygen. Наряду с экстремальным программированием мы включили в процесс разработки идеи литературного программирования (Literate Programming). Уэйн Суал поясняет: «Обычно в литературных программах исходный код и документация объединяются в одном файле. Затем инструменты литературного программирования обрабатывают файл и выдают либо удобочитаемую документацию, либо компилируемый исходный код» [10].

Инструмент Doxygen использует простой язык разметки комментариев в исходном коде на языках C++ или Cи и генерирует обширную документацию для кода. Поскольку документация генерируется автоматически, она может обновляться каждую ночь, чтобы соответствовать самой последней версии кода в системе контроля изменений. Программисты обычно не любят писать документацию, зато любят писать код. Если документация разрабатывается параллельно процессу написания кода, намного вероятнее, что она останется актуальной и будет соответствовать коду.

Система регистрации ошибок.

Ещё один мощный инструмент — система регистрации ошибок. Она позволяет разработчикам и пользователям сообщать о выявленных ошибках и других проблемах, а также служит местом для хранения запросов на реализацию тех или иных функций, не давая о них забыть. Мы выбрали Web-систему phpBugTracker, поскольку она легко устанавливается, имеет понятный пользовательский интерфейс и легко справляется с многочисленными проектами. При занесении в систему проблема получает уникальный идентификатор, и ей могут быть присвоены степень серьёзности и приоритет. Администратор системы регистрации ошибок может дать избранным разработчикам дополнительные привилегии, позволяющие изменять статус проблемы и предлагать варианты её решения. К описанию проблемы можно приложить файлы, скажем, с тестовыми примерами или исправлениями в исходном коде. Инициатор сообщения о проблеме и разработчик, назначенный ответственным за её решение, по электронной почте уведомляются об изменении статуса проблемы, что позволяет установить диалог между ними.

Наличие хорошей системы регистрации ошибок — это ещё не всё. Для того чтобы этот инструмент оставался полезным, кто-то должен им управлять, а группа разработчиков должна периодически собираться и «сортировать» проблемы, то есть пересматривать их приоритеты и перераспределять их по соответствующим категориям или исполнителям. Сортировка обычно происходит перед выпуском новой версии на общем собрании группы (либо в одном месте, либо посредством телефонной или видеоконференции). Без такого внимания список ошибок может быстро превратиться в перечень дел, которые никогда не будут сделаны.

Контроль изменений

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

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

Для нашего процесса разработки лучше подходит режим параллельного редактирования. Он допускает определенную свободу в выборе местоположения, так что разработчики могут править код, находясь и в самолете, и дома. Среди такого рода инструментов для контроля изменений самой популярной является система CVS, построенная на основе клиент-серверной архитектуры. Файлы проекта хранятся на сервере, а клиент может соединиться с ним и извлечь копию файла с блокировкой изменений со стороны других клиентов. Клиент может запросить любую версию файла в системе. CVS позволяет также маркировать и «разветвлять» файлы. Маркер — это символическое имя для группы файлов, представляющей собой «мгновенный снимок» проекта на данный момент времени. Ветвление позволяет вести разработку по нескольким направлениям одновременно и независимо. Изменения, внесённые в одну из ветвей, не затрагивают другие ветви. Специальная ветвь, которую мы называем «главным деревом» или стволом, является основной ветвью разработки, из которой файлы извлекаются по умолчанию. Более новый инструментарий, Subversion, имеет несколько преимуществ перед системой CVS и может использоваться вместо нее. В частности, Subversion поддерживает протокол HTTP/HTTPS и позволяет перемещать и переименовывать папки, а ветвление и маркировка не требуют больших вычислительных затрат.

Когда настаёт время выпускать новую версию продукта, один из разработчиков назначается менеджером выпуска. Он просит разработчиков поместить все финальные редакции в репозитарий, который затем блокирует, оставляя лишь за собой право доступа на запись. Затем менеджер выпуска тестирует систему, и если запланированные функции присутствуют в полном объёме, создаёт отдельную ветвь для выпуска. В дальнейшем менеджер выпуска применяет исправления только к этой ветви. CVS можно настроить таким образом, чтобы запретить внесение изменений в ветвь другим разработчикам, которые могут вернуться к главному дереву и начать разработку следующей версии программного продукта.

Управление сборкой

Важной, но часто недооцениваемой частью любого программного проекта является управление процессом сборки, в котором группа файлов исходного кода преобразуется в библиотеки и приложения для конечного пользователя. В системе программирования для этой цели обычно предусмотрен набор инструментов, состоящий из компиляторов, специализированных генераторов, компоновщиков и архиваторов. Координация работы этих инструментов между всеми компьютерами и разработчиками довольно трудна и отнимает много времени. Инструменты и способы их использования сильно изменяются от платформы к платформе, поэтому управление процессом сборки одновременно для Windows, Unix и Mac OS представляется весьма затруднительным.

До появления инструмента CMake разработчики Kitware в среде Unix использовали утилиту autoconf, а в Windows — специализированный (с учётом особенностей Visualization Toolkit) генератор make-файлов для nmake. Make-файлы составлялись вручную с включением сгенерированных списков исходных файлов. Этот процесс был чреват ошибками и имел ряд ограничений, поэтому лишь немногие из разработчиков умели вносить изменения в сборку.

На вход инструмента поступают простые файлы сценариев на языке CMake. В соответствии с этими сценариями производится внутренний анализ системы и составляется описание процесса построения исполняемых программ, библиотек и прочих необходимых целевых файлов. В отличие от многих других кросс-платформенных инструментов сборки, CMake предназначен для использования совместно с собственной сборочной средой путём генерации файлов управления сборкой для «родных» инструментов, хорошо знакомых разработчикам. Это важно для небольших компаний, поскольку внедрение унифицированных инструментов требует затрат на обучение и может вызвать негодование у разработчиков, вынужденных использовать сборочную среду, навязанную требованиями корпоративных стандартов. Крупные организации имеют возможность содержать отдельные группы, занимающиеся процессом сборки. Со своей стороны, автоматизируя большую часть связанной с ним работы, CMake позволяет и небольшим коллективам успешно разрабатывать переносимое программное обеспечение. С помощью небольшого сценария можно описать сборку исполняемой программы на нескольких платформах.

CMake активно разрабатывался с 1999 года и превратился в мощный инструмент общего назначения с растущей пользовательской базой. Недавно сообщество разработчиков графической оболочки K Desktop Environment выбрало его для замены autoconf и Scons (KDE — один крупнейших проектов категории Open Source). В настоящее время CMake является зрелым, полнофункциональным инструментом, позволяющим полностью контролировать процесс сборки и способным заменить отдельную группу сборщиков, имеющуюся во многих крупных организациях. Простой синтаксис языка CMake позволяет любому разработчику легко создавать необходимые для проекта исполняемые программы и библиотеки.

Тестирование

Тестирование — ключевой этап в производстве надежного и эффективного программного обеспечения.

Типы тестов. Испытания программного комплекса могут проходить в различных формах. На самом нижнем уровне находятся так называемые «дымовые» тесты (грубая проверка работоспособности простым запуском), которые просто проверяют, что программное обеспечение компилируется без ошибок. Какими бы простыми они не казались, при широком разнообразии платформ и возможных конфигураций «дымовые» тесты выявляют больше проблем, чем любой другой тип испытаний. Другая форма применения подобных тестов — проверка безаварийности работы. Она может оказаться удобной, когда разработчик не хочет тратить время на создание сложных тестов, но желает выполнить некоторые из простых. Эти простые тесты часто представляют собой маленькие программы, прогон которых позволяет проверить не только успешность сборки, но и возможность загрузки всех необходимых общих библиотек (в проектах, где они используются) и способность к безаварийной работе по меньшей мере части кода.

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

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

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

Для проведения тестирования мы используем целый ряд инструментов. Первый из них — программа CTest, которую компания Kitware поставляет в комплекте с инструментом CMake. Программа CTest считывает файлы описаний тестов, обычно генерируемые CMake, и позволяет пользователю выполнить все или некоторые из тестов, подготовленных для проекта. Типичный рабочий цикл выглядит так: в исходный код вносятся изменения, производится сборка, выполняется CTest для проверки прохождения подготовленных тестов, после чего изменения передаются в систему контроля изменений. В проектах с большим числом тестов, для выполнения которых может потребоваться несколько часов, мы обычно ограничиваемся их подмножеством, отобранным методом сопоставления шаблонов, или используем достаточно большой шаг для пропуска тестов (скажем, выполняем из них каждый десятый). Важно обеспечить некий базовый уровень тестирования перед передачей кода в общий репозитарий, который не заставлял бы разработчиков ожидать дольше нескольких минут. Более полное тестирование проводится с помощью автоматизированных инструментов.

При автоматизированном тестировании CTest выполняется на клиентской машине, однако результаты пересылаются в базу данных Dart, открытого инструментария для составления отчетов о тестировании, разработанного в исследовательском центре GE Global Research и основанного на Web-технологиях. CTest обычно выполняется ночью под управлением утилиты cron или планировщика заданий и проделывает весь цикл работ по извлечению файлов, сборке и тестированию. Как правило, один клиент за ночь тестирует несколько проектов или ветвей и отправляет записи в Dart, которая, в свою очередь, работает на сервере и принимает результаты от многих клиентов. Один сервер может обслуживать одновременно много программных проектов и позволяет быстро выявить проблемы сборки и тестирования на нескольких тестовых платформах. На рис. 1 показана приборная панель Dart для CMake. В каждой строке суммируются результаты тестирования для отдельного клиента. Гиперссылки позволяют разработчикам углубиться внутрь, чтобы увидеть сообщения, относящиеся к любой сборке, включая предупреждения или ошибки, а также выходные данные любых тестов. Как правило, клиенты (обычно работая ночью) направляют скоординированные данные для приборной панели, основанные на одной и той же версии исходного кода, так что результаты клиентов можно сравнить между собой. Постоянная готовность Dart к приему данных позволяет в наиболее крупных проектах непрерывно отображать состояния сборки и тестирования на некоторых клиентах по мере изменения исходного кода в течение дня. Иногда это помогает находить и устранять межплатформенные проблемы непосредственно в день их появления.

В дополнение к результатам сборки и тестирования Dart принимает данные и выдает отчеты о тестовом покрытии кода и о результатах динамического анализа. Показатель тестового покрытия кода позволяет быстро оценить объем кода, прошедшего процесс тестирования. В клиентской программе для проведения тестирования на платформе Linux его можно легко настроить, изменяя флаги компиляции для одного из ночных прогонов (например, с помощью утилиты gcov). CTest автоматически обнаружит файлы покрытия, проанализирует их и отправит в Dart, где разработчики смогут их рассмотреть во всех подробностях. Для динамического анализа мы обычно используем бесплатный Linux-инструментарий valgrind. Он также легко настраивается, для этого обычно достаточно незначительно изменить флаги компиляции и указать CTest местоположение valgrind. Динамический анализ отчетов о тестировании позволяет выявить такие ошибки, как запись за границами массива, чтение данных из неинициализированной памяти и т.п. Также полезными средствами динамического анализа являются Purify и Bounds Checker.

С помощью инструментов Dart, CTest, CMake, valgrind, gcc и gcov формирование зрелого процесса тестирования происходит довольно быстро — при наличии опыта обычно можно управиться за день. После этого проблемой становится доступ к тестовым платформам, т. е. к комбинации аппаратных средств, операционной системы и компилятора. Для проектов категории Open Source, которые компилируются многими людьми, широкое разнообразие испытательных платформ является обязательным. Даже в закрытых проектах полезно иметь доступ к нескольким платформам: к примеру, один отдельно взятый компилятор может не распознать все проблемы в исходном коде. В небольшом коллективе доступ к этим ресурсам может оказаться трудным и дорогим. В Kitware у нас на 30 разработчиков есть около 30 выделенных тестовых компьютеров. Это достаточно дорого, но, к счастью, существует несколько способов снижения затрат. Для клиентов Windows можно использовать подписку MSDN, чтобы по весьма низким ценам приобрести операционную систему и компиляторы для выделенных тестовых платформ. Все основные инструменты, которые мы используем в Linux, бесплатны. Некоторые производители, в частности корпорация Intel, предоставляют скидку на оборудование, приобретаемое для разработки и тестирования. Мы также используем предоставляемый компаниями IBM и HP доступ к тестовым платформам для тестирования в средах AIX и HP-UX, которыми не располагаем сами.

Выпуск новой версии

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

Построение стабильной ветви исходного кода для новой версии — лишь часть проблемы; затем надо сформировать программный пакет, готовый к выпуску. Существует два типа выпусков: исходный код и двоичный исполняемый код. Мы обычно создаем выпуски для трех основных платформ: Windows, Unix и Mac. Они отличаются друг от друга способами упаковки исходных и двоичных кодов. Инсталляционные программы для Windows мы создаем с помощью инструментария NSIS (Nullsoft Scriptable Install System); в Unix используем архивы tar; а для Mac выпускаем установочные диски DMG.

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

Полезные уроки

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

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

Мы пришли к выводу, что для небольшой компании ключевым звеном является автоматизация. Все загружены работой, и методика разработки часто становится одним из первых мест, где разработчики начинают срезать углы. Автоматизация общепринятых стандартов кодирования средствами текстового редактора и контроль за их соблюдением путем автоматизированной проверки при отправке в репозитарий снимает с разработчиков большую часть этой нагрузки. То же самое можно сказать и о тестировании. Если процесс создания, выполнения и анализа тестов недостаточно прост для разработчиков, они просто не будут им заниматься. Инструменты Dart и CTest позволяют, взглянув на Web-страницу, быстро оценить состояние проекта, а затем при необходимости углубиться внутрь для поиска источника любой проблемы.

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

Для поддержки процесса разработки мы создали собственные инструменты, но такой вариант обычно мало подходит для маленьких групп. CMake, CTest и CPack стали результатом шестилетних усилий, и их создание было бы невозможным без поддержки и финансирования со стороны многих ведомств, а также без дополнений, комментариев и поправок со стороны сообщества Open Source. Для небольших компаний обычно единственный жизнеспособный вариант — использование результатов крупных государственных или открытых проектов. Поскольку большая часть наших достижений в области разработки является открытой, другие небольшие группы безусловно могут внедрить у себя наш процесс разработки с умеренными начальными затратами.

Система wiki оказалась мощным средством обучения. До ее появления новые сотрудники часто обращались к более опытным специалистам с вопросами о том, как выполнить ту или иную задачу. Чтобы не отвлекаться, эксперты могут поместить свои знания в корпоративную систему wiki, где каждый может с ними ознакомиться.

***

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

Даже небольшая организация, располагая довольно скромными ресурсами, может воспользоваться преимуществами целого ряда промышленных методов разработки программного обеспечения. С помощью этих методов нам удалось добиться значительно большей степени кроссплатформенности. Многие из упомянутых нами инструментов могут эффективно использоваться при внедрении официальных процедур, отвечающих требованиям Комиссии по продуктам питания и лекарственным средствам США. Например, регистрация ошибок и контроль изменений — два ключевых аспекта политики, обычно необходимых для соблюдения стандартов FDA QSR 820 и ISO 13485. Располагая обширным арсеналом разнообразных инструментов, небольшой коллектив вполне способен выпускать высококачественные, надежные программы в кратчайшие сроки.

Литература

1. S. Garcia, C. Graettinger, K. Kost, eds., Proc. 1st Int’l Research Workshop for Process Improvement in Small Settings. Tech. report CMU/SEI-2006-SR-001, 2006.
2. W. Schroeder, K. Martin, B. Lorensen, The Visualization Toolkit: An Object Oriented Approach to Computer Graphics. 4th ed., Kitware, 2006.
3. L. Ibanez et al., The ITK Software Guide. Kitware, 2003.
4. K. Beck, Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999.
5. D. Astels, Test Driven Development: A Practical Guide. Prentice Hall, 2003.
6. K. Aguanno, ed., Managing Agile Projects. Multi-Media Publications, 2005.
7. B. Leaf, W. Cunningham, The Wiki Way: Quick Collaboration on the Web. Addison-Wesley, 2001.
8. K. Fogel, M. Bar, Open Source Development with CVS. 3rd ed., Paraglyph Press, 2003.
9. K. Martin, B. Hoffman, Mastering CMake: A Cross-Platform Build System. 3rd ed., Kitware, 2006.
10. W. Sewell, Weaving a Program: Literate Programming in Web. Van Nostrand Reinhold, 1989.

Кен Мартин (ken.martin@kitware.com) — вице-президент компании Kitware, ведущий архитектор продуктов Visualization Toolkit и CMake; Билл Хоффман (bill.hoffman@kitware.com) — вице-президент компании Kitware, руководитель проекта CMake.

---

Ken Martin, Bill Hoffman. An Open Source Approach to Developing Software in a Small Organization. IEEE Software, January/February 2007. IEEE Computer Society, 2007. All rights reserved. Reprinted with permission.