Процессы разработки и выпуска программного продукта.

Специфицирование и планирование

Процесс разработки начинается с создания концептуального описания будущего продукта, задающего «по-крупному» его об­раз, видение (этот документ так и называется «vision statement») в контексте требований рынка. Главным действующим липом на этом этапе является «менеджер по продукту» (product manager) — специалист-маркетолог, знающий ситуацию на рынке и запросы потенциальных пользователей. Его задача — донести до менед­жеров по разработке ПО потребительские свойства будущего продукта, т. е. указать, какие цели и требования пользователей необходимо удовлетворить, какие для этого заложить функцио­нальные возможности (product features) и в каком порядке в со­ответствии с существующими приоритетами следует их ранжи­ровать.

На основе функциональной спецификации менеджеры по разработке, постоянно консультируясь с проектировщиками, на­чинают на модульной основе создавать горизонтальную архитек­туру продукта. Главное, что на этой стадии все основные функции ПО разбиваются на несколько групп (обычно три-четыре груп­пы). Соответственно, формируется столько же подпроектов, ра­бота над которыми будет вестись последовательно. Разбиение производится на основе уже имеющейся классификации функ­ций по степени важности. Наиболее важные ('/₃ от общего коли­чества, если групп всего 3) попадают в первый подпроект; другие, менее приоритетные, реализуются в рамках второго подпроекта, и наконец, прочие, наименее значимые функции выполняются в последнем подпроекте. Каждый подпроект заканчивается выпус­ком промежуточной «контрольной» версии продукта

Выпуск продукта

Выпуск продукции происходит в лабораториях. Первая лаборатория была открыта в 1989 г

В этих лабораториях работают более ста сотрудников (usability engineers), имеющих не только компьютерное образова­ние, но и обладающих знаниями в специальных областях психо­логии и эргономики. Кроме того, непосредственно разработчи­кам, особенно отвечающим за интерфейсную часть, вменено в обязанность периодически присутствовать на тестовых экспери­ментах. Что касается контингента испытателей, то их стремятся подбирать так, чтобы они представляли все категории потенци­альных пользователей — для этого накоплена и постоянно по­полняется обширная база данных.

Эксперименты проводятся не только в корпоративных лабо­раториях, но и «на выезде» в офисах, школах и университетах, по месту жительства возможных потребителей. Кроме того, в по­следней фазе разработки — фазе стабилизации — прошедшие всестороннее внутреннее тестирование «beta» версии отправля­ются для опытной эксплуатации к партнерам корпорации, при­надлежащим к категориям OEM и ISV; здесь задействованы и многочисленные добровольцы-индивидуалы. После этого ком­пания приступает к подготовке выпуска «финальной» версии продукта («golden master» discs), а также необходимой докумен­тации. Но даже после выпуска «финальной» версии работа над продуктом не прекращается. Уже установилась традиция в сред­нем через 12 месяцев выпускать исправленную и дополненную версию, а через 24 месяца — радикально переработанную (с большим количеством новых функций и измененной архитек­турой). Небезынтересно отметить, что работа отвечающих на те­лефонные звонки и другие обращения о помощи инженеров службы поддержки финансируется за счет бюджета команд раз­работчиков данного продукта; поэтому последние заинтересова­ны в постоянной минимизации дефектов в каждой последующей версии сравнительно с предыдущей.

Процесс разработки.

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

Разработчики выполняют проектирование, кодирование и отладку своегокода.

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

В конце каждого подпроекта — после истечения срока па­раллельной работы команд над реализацией назначенных им функций — предусмотрен специальный период «буферное вре­мя» (buffer time), в течение которого разрешаются всякие не пре­дусмотренные планом, но неизбежно возникающие проблемы, особенно вызванные оперативно вносимыми изменениями в спецификации и взаимозависимостью функций, над которыми работали разные команды. Этот период используется и как три­виальное продление периода разработки подпроекта, потому что выходы за пределы временного графика наблюдаются почти все­гда. Для проектов из разряда приложений буферное время зани­мает 20—30 % от всей продолжительности подпроекта, а для сис­темных программ — 50 %. Только после этого выпускается оче­редная «контрольная» версия (milestone release), с которой активно работают пользователи.