Журнал Компьютерра - Журнал «Компьютерра» №46 от 15 декабря 2005 года

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

Но прежде чем обсуждать эти тенденции, хотелось бы вернуться на тридцать лет назад. Вот выдержка из отчета НАТО 1969 года, посвященного разработке ПО. «Главные проблемы в системе разработки программного обеспечения состоят в следующем:

n недостаточное управление требованиями, увлечение производством кода в ущерб дизайну ПО;

n ошибки в оценках, недостаток мониторинга процессов, разобщенность программистов;

n низкая продуктивность, отсутствие оценочных факторов, низкая надежность (ошибки);

n слишком сильная привязка к оборудованию, невозможность повторного использования кода;

n высокая стоимость разработки».

Звучит знакомо, не правда ли? Уже предпринимались попытки решения этих проблем путем смены парадигмы программирования. В истории можно выделить несколько моделей: стиль IBM (совершенствование классической схемы; 1960-70-е годы), японский стиль («фабрики ПО», стабильные команды программистов, отлаженные процедуры, максимальное повторное использование кода; 1970-80-е) и стиль, предлагаемый SEI[SEI - Software Engineering Institute] (главным образом состоит в предварительном ранжировании требований к разработке и контроле соответствия этим требованиям на каждом этапе, с 80-х; в настоящее время предлагается уже пятая версия документа).

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

Внутри нее можно выделить следующие процессы: спиральная разработка архитектуры (от ядра системы к подключаемым модулям), постоянный выпуск прототипов (для контроля функциональности), выпуск наравне с бетами регулярных стабильных версий (для контроля ошибок), применение нисходящего программирования в микромасштабах (особенно для систем реального времени), набирающее популярность экстремальное программирование[Очень рекомендую посетить сайт www.xprogramming.ru] (постоянное взаимодействие с заказчиком; воплощение прежде всего тех функций, которые именно сейчас нужны пользователям; написание одного и того же кода парой программистов: один пишет - другой смотрит, потом меняются). На рисунке видно, как соотносятся эти методики.

Итак, прогресс в области разработки программного обеспечения, несмотря на проблемы, сходные с проблемами конца 60-х, не стоит на месте. Мною проводились ежегодные исследования - какие методики применяют те или иные компании при разработке ПО. Были изучены корпоративные стандарты большинства крупных мировых компаний-разработчиков софта. В Индии: Motorola MEI, Infosys, Tata, Patni; в Японии: Hitachi, NEC, IBM Japan, NTT Data, SRA, Matsushita, Omron, Fuji Xerox, Olympus; в США: IBM, HP, Agilent, Microsoft, Siebel, AT amp;T, Fidelity, Merrill Lynch, Lockheed Martin, TRW, Micron Tech; в Европе: Siemens, Nokia, Business Objects, и многих других. В результате можно выявить несколько основных тенденций. Так, почти все из перечисленных компаний постоянно выпускают бета-версии, регулярно изменяют и дополняют документы, описывающие базовую архитектуру будущего ПО. Все проводят тестирование нового куска кода в рамках всего проекта (так называемый регрессионный анализ, который можно сравнить с порядком, установленным на конвейере компании Toyota, - если кто-либо из рабочих заметил дефект, он обязан остановить движение всего конвейера), чтобы не потерять достигнутой стабильности и функциональности.

Однако видны и различия. В первую очередь выделяется Индия, где высок процент применения парного программирования, всегда имеется детальное описание проекта (для сравнения, в США только 30% проектов имеют этот документ), относительно низкий уровень применения генераторов кода. Япония в этом плане не слишком отличается от Индии. В Европе же гораздо чаще применяют методику микроциклов, больше развит выпуск бета-версий с независимым бета-тестированием. Таким образом, очевидна тенденция перевода «человекоемких» технологий в страны с дешевой рабочей силой и активное применение новых «технологических» (вроде кодогенераторов) решений вкупе со стремлением к сокращению сроков разработки в европейских странах.