Страница:
Внутри нее можно выделить следующие процессы: спиральная разработка архитектуры (от ядра системы к подключаемым модулям), постоянный выпуск прототипов (для контроля функциональности), выпуск наравне с бетами регулярных стабильных версий (для контроля ошибок), применение нисходящего программирования в микромасштабах (особенно для систем реального времени), набирающее популярность экстремальное программирование[Очень рекомендую посетить сайт 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&T, Fidelity, Merrill Lynch, Lockheed Martin, TRW, Micron Tech; в Европе: Siemens, Nokia, Business Objects, и многих других. В результате можно выявить несколько основных тенденций. Так, почти все из перечисленных компаний постоянно выпускают бета-версии, регулярно изменяют и дополняют документы, описывающие базовую архитектуру будущего ПО. Все проводят тестирование нового куска кода в рамках всего проекта (так называемый регрессионный анализ, который можно сравнить с порядком, установленным на конвейере компании Toyota, — если кто-либо из рабочих заметил дефект, он обязан остановить движение всего конвейера), чтобы не потерять достигнутой стабильности и функциональности.
Однако видны и различия. В первую очередь выделяется Индия, где высок процент применения парного программирования, всегда имеется детальное описание проекта (для сравнения, в США только 30% проектов имеют этот документ), относительно низкий уровень применения генераторов кода. Япония в этом плане не слишком отличается от Индии. В Европе же гораздо чаще применяют методику микроциклов, больше развит выпуск бета-версий с независимым бета-тестированием. Таким образом, очевидна тенденция перевода «человекоемких» технологий в страны с дешевой рабочей силой и активное применение новых «технологических» (вроде кодогенераторов) решений вкупе со стремлением к сокращению сроков разработки в европейских странах.
Япония, со своей традиционной методикой разработки ПО, стоит как бы в стороне, однако можно отметить высокий уровень организации бизнес-процессов, что отличает ее от Индии. Поэтому Япония имеет одно важное преимущество перед другими мировыми центрами разработки: при очень высоком уровне производства кода (почти 500 тысяч строк в месяц на человека, тогда как в Европе 436 тысяч, в Индии — всего 209 тысяч) поддерживается минимальный уровень ошибок — меньше 0,02 (!) ошибочных строчек на тысячу (в США — 0,4, в Индии — 0,26). Добиваются они этого активным повторным использованием уже отлаженного кода и наличием детальных описаний проектов.
Анализируя результаты работы компаний, исповедующих различные подходы к организации процесса, можно выделить следующие факты. Компании, выпускающие первый прототип, обладающий всего лишь 20% функциональности, в итоге уменьшали количества ошибок на 27%. Далее, регрессионное тестирование снижает количество ошибок на 36%, уточнение архитектуры конечного продукта на каждом этапе дает 55% снижения. Кстати, ранний выпуск работающих прототипов повышает общую производительность программистов на 35%. А если прототипы выпускаются ежедневно, то она вырастает почти вдвое — вот какой эффект имеет осязаемость результатов своего труда!
Итак, по разным оценкам, более 60% программного обеспечения создается на основе новых методов организации рабочего процесса. Только в 36% случаев применяется нисходящее программирование с детально проработанным планом и подробными спецификациями до начала его реализации. Можно смело утверждать, что мир разработки ПО окончательно изменился и большинство компаний применяют смесь из обычного программирования и итеративных методик. Это свидетельствует о том, что ориентация софтверных фирм на рынок «вообще» сменилась ориентацией на решение задач конкретного пользователя.
При сегодняшнем росте сложности разрабатываемого ПО неизбежен и рост удельного количества ошибок в нем, поэтому стремление к постоянному наращиванию скорости производства кода уже не может являться главной целью. Удивительно низкий уровень ошибок японских производителей при сохранении традиционного подхода вряд ли может быть применим в других регионах, так как для этого необходимо перенести туда и японский менталитет. Качество же индийского кода, продолжая расти, все-таки пока остается на недостаточном для современных задач уровне.
Canon G2 и Sony S85 )». При интерпретации приведенных в статье результатов не забывайте, что указываемые 1400—1600 штрихов на длинную сторону матрицы 1/1,8” надо делить на два (см. врезку)]. Похожий на правду результат также приведен, например, в тесте передовой для своего времени камеры Olympus Camedia E-10 , которая имеет Мп матрицу размером 2/3”. Для нее фотографирование миры показало разрешение в привычных для нас единицах лишь чуть больше 100 лин./мм. Лучший результат получен на Olympus Camedia C-5050[Журнал «foto&video» №5, май 2003 г.] — при матрице 1/1,8” разрешение по короткой стороне составило 1800 двойных штрихов, что дает 170 лин./мм.
Итак, прогресс в области разработки программного обеспечения, несмотря на проблемы, сходные с проблемами конца 60-х, не стоит на месте. Мною проводились ежегодные исследования — какие методики применяют те или иные компании при разработке ПО. Были изучены корпоративные стандарты большинства крупных мировых компаний-разработчиков софта. В Индии: Motorola MEI, Infosys, Tata, Patni; в Японии: Hitachi, NEC, IBM Japan, NTT Data, SRA, Matsushita, Omron, Fuji Xerox, Olympus; в США: IBM, HP, Agilent, Microsoft, Siebel, AT&T, Fidelity, Merrill Lynch, Lockheed Martin, TRW, Micron Tech; в Европе: Siemens, Nokia, Business Objects, и многих других. В результате можно выявить несколько основных тенденций. Так, почти все из перечисленных компаний постоянно выпускают бета-версии, регулярно изменяют и дополняют документы, описывающие базовую архитектуру будущего ПО. Все проводят тестирование нового куска кода в рамках всего проекта (так называемый регрессионный анализ, который можно сравнить с порядком, установленным на конвейере компании Toyota, — если кто-либо из рабочих заметил дефект, он обязан остановить движение всего конвейера), чтобы не потерять достигнутой стабильности и функциональности.
Однако видны и различия. В первую очередь выделяется Индия, где высок процент применения парного программирования, всегда имеется детальное описание проекта (для сравнения, в США только 30% проектов имеют этот документ), относительно низкий уровень применения генераторов кода. Япония в этом плане не слишком отличается от Индии. В Европе же гораздо чаще применяют методику микроциклов, больше развит выпуск бета-версий с независимым бета-тестированием. Таким образом, очевидна тенденция перевода «человекоемких» технологий в страны с дешевой рабочей силой и активное применение новых «технологических» (вроде кодогенераторов) решений вкупе со стремлением к сокращению сроков разработки в европейских странах.
Япония, со своей традиционной методикой разработки ПО, стоит как бы в стороне, однако можно отметить высокий уровень организации бизнес-процессов, что отличает ее от Индии. Поэтому Япония имеет одно важное преимущество перед другими мировыми центрами разработки: при очень высоком уровне производства кода (почти 500 тысяч строк в месяц на человека, тогда как в Европе 436 тысяч, в Индии — всего 209 тысяч) поддерживается минимальный уровень ошибок — меньше 0,02 (!) ошибочных строчек на тысячу (в США — 0,4, в Индии — 0,26). Добиваются они этого активным повторным использованием уже отлаженного кода и наличием детальных описаний проектов.
Анализируя результаты работы компаний, исповедующих различные подходы к организации процесса, можно выделить следующие факты. Компании, выпускающие первый прототип, обладающий всего лишь 20% функциональности, в итоге уменьшали количества ошибок на 27%. Далее, регрессионное тестирование снижает количество ошибок на 36%, уточнение архитектуры конечного продукта на каждом этапе дает 55% снижения. Кстати, ранний выпуск работающих прототипов повышает общую производительность программистов на 35%. А если прототипы выпускаются ежедневно, то она вырастает почти вдвое — вот какой эффект имеет осязаемость результатов своего труда!
Итак, по разным оценкам, более 60% программного обеспечения создается на основе новых методов организации рабочего процесса. Только в 36% случаев применяется нисходящее программирование с детально проработанным планом и подробными спецификациями до начала его реализации. Можно смело утверждать, что мир разработки ПО окончательно изменился и большинство компаний применяют смесь из обычного программирования и итеративных методик. Это свидетельствует о том, что ориентация софтверных фирм на рынок «вообще» сменилась ориентацией на решение задач конкретного пользователя.
При сегодняшнем росте сложности разрабатываемого ПО неизбежен и рост удельного количества ошибок в нем, поэтому стремление к постоянному наращиванию скорости производства кода уже не может являться главной целью. Удивительно низкий уровень ошибок японских производителей при сохранении традиционного подхода вряд ли может быть применим в других регионах, так как для этого необходимо перенести туда и японский менталитет. Качество же индийского кода, продолжая расти, все-таки пока остается на недостаточном для современных задач уровне.