Программная инженерия

Объективная потребность контролировать процесс разработки сложных систем ПО, прогнозировать и гарантировать стоимость разработки, сроки и качество результатов привела в конце 60-х годов прошлого века к необходимости перехода от кустарных к индустриальным способам создания ПО и появлению совокупности инженерных методов и средств создания ПО, объединенных общим названием «программная инженерия» (software engineering ). Впервые термин software engineering был использован как тема исторической конференции Научного комитета NATO в 1968 г. Спустя семь лет, в 1975 г., в Вашингтоне была проведена первая международная конференция, посвященная программной инженерии, тогда же появилось первое издание, посвященное программной инженерии, — IEEE Transactions on Software Engineering. Программная инженерия определяется, с одной стороны, как совокупность инженерных методов и средств создания ПО а, с другой стороны, как дисциплина, изучающая применение строгого систематического количественного (т.е инженерного) подхода к разработке, эксплуатации и сопровождению ПО.

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

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

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

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

В то же время попытки чрезмерной формализации процесса, а также прямого заимствования идей и методов из других областей инженерной деятельности (строительства, производства) привели к ряду серьезных проблем. После двух десятилетий напрасных ожиданий повышения продуктивности процессов создания ПО, возлагаемых на новые методы и технологии, специалисты в индустрии ПО пришли к пониманию, что фундаментальная проблема в этой области — неспособность эффективного управления проектами создания ПО. Невозможно достичь удовлетворительных результатов от применения даже самых совершенных технологий и инструментальных средств, если они применяются бессистемно, разработчики не обладают необходимой квалификацией для работы с ними, и сам проект выполняется и управляется хаотически, в режиме «тушения пожара». Бессистемное применение технологий создания ПО, в свою очередь, порождает разочарование в используемых методах и средствах (анализ мнений разработчиков показывает, что среди факторов, влияющих на эффективность создания ПО, используемым методам и средствам придается гораздо меньшее значение, чем квалификации и опыту разработчиков). Если для управления проектами и внедрения технологий не создается необходимой инфраструктуры и не обеспечивается техническая поддержка, то на выполнение проектов затрачивается существенно больше времени и ресурсов по отношению к планируемым (да и само планирование ресурсов выполняется «потолочным» методом»). Если в таких условиях отдельные проекты завершаются успешно, то этот успех достигается за счет героических усилий фанатично настроенного коллектива разработчиков. Успех, который держится исключительно на способностях отдельных организаторов «вытаскивать» проекты из прорывов, не дает гарантии устойчивой производительности и качества при создании ПО. Постоянное повышение качества создаваемого ПО и снижение его стоимости может быть обеспечено только при условии достижения организацией необходимой технологической зрелости, создании эффективной инфраструктуры как в сфере разработки ПО, так и в управлении проектами. В соответствии с моделью СММ (Capability Maturity Model) Института программной инженерии (Software Engineering Institute, SEI), в хорошо подготовленной (зрелой) организации персонал обладает технологией и инструментарием оценки качества процессов создания ПО на протяжении всего жизненного цикла ПО и на уровне всей организации. Процессы выстраиваются таким образом, чтобы обеспечить реальные сроки создания ПО.

При решении проблемы повышения эффективности создания ПО основное внимание уделяется, как правило, процессу разработки ПО, что вызвано естественным желанием разработчиков и заказчиков экономить средства с самого начала проекта (особенно в условиях ограниченных финансовых возможностей и высокой конкуренции). В то же время большинство крупномасштабных проектов создания ПО характеризуется длительным жизненным циклом (10 — 15 лет), в котором на стадию создания (разработки) приходятся только первые 3—4 года, а остальное время эксплуатации созданной системы (стадия сопровождения и развития) распределяется, по оценкам Института программной инженерии (Software Engineering Institute, SEI), примерно поровну на следующие стадии:

· начальную стадию сопровождения, связанную с устранением ошибок и доработками, возникшими из-за неучтенных или вновь возникших требований пользователей;

· стадию «зрелого» сопровождения, характеризующуюся относительно полным удовлетворением основных потребностей пользователей, но в то же время связанную с накоплением ряда проблем, а именно:

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

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

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

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

Под сопровождением в общем случае понимается внесение изменений в эксплуатируемый программный продукт в целях исправления обнаруженных ошибок (корректирующее сопровождение), повышения производительности и улучшения эксплуатаци­онных характеристик системы (совершенствующее сопровождение), а также адаптации к изменившейся или изменяющейся среде (адаптирующее сопровождение). При этом более 50% общего объема работ по сопровождению приходится на совершенствующее сопровождение. В общих затратах различных организаций и предприятий на ПО доля затрат на сопровождение составляет от 60% до 80% (эта доля является максимальной для крупных государственных учреждений и частных компаний), и величина этих затрат продолжает расти. Негативными последствиями такого роста являются: 1) неудовлетворенность пользователей из-за большого времени, затрачиваемого на внесение изменений в ПО; 2) снижение качества ПО и 3) сокращение объема новых разработок в будущем, поскольку все большее количество разработчиков вынуждено переключаться на сопровождение. Так, по оценкам компании Hewlett-Packard, в 1994 г. от 60% до 80% ее разработчиков были заняты сопровождением ПО, а в отчетах федеральных служб США ранее отмечалось, что на сопровождение уходит от 50% до 80% рабочего времени программистов. Перечисленные тенденции отражены на рис. В.З.

Рис. В.З. Тенденции изменения соотношения стоимости аппаратуры и ПО

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

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

По данным SEI, в последние годы до 80% всего эксплуатируемого ПО разрабатывалось вообще без использования какой-либо дисциплины проектирования, методом «code and fix» (кодирования и исправления ошибок). Одна из причин — упомянутое выше стремление сэкономить на стадии разработки, не затрачивая времени и средств на внедрение технологического процесса создания ПО. Эти затраты до недавнего времени были довольно значительными и составляли, по различным оценкам, более $100 тыс. и около трех лет на внедрение развитой технологии, охватывающей большинство процессов жизненного цикла ПО, в многочисленной команде разработчиков (до 100 чел.). Причина — в «тяжести» технологических процессов. «Тяжелый» процесс обладает следующими особенностями:

· необходимость документировать каждое действие разработчиков;

· множество рабочих продуктов (в первую очередь — документов), создаваемых в бюрократической атмосфере;

· отсутствие гибкости;

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

Для того чтобы проиллюстрировать насколько «тяжелыми» могут быть формальные процессы, эксперт в области использования метрик Каперс Джонс подсчитал, что процесс разработки ПО по стандарту DOD-2167A Министерства обороны США требует 400 слов в документации на английском языке для каждой строки исходного кода. Так, если создается среднее приложение размером 50 000 строк исходного кода, потребуется наличие армии технических специалистов для создания 20 миллионов слов документации с описанием того, что делает код, как он функционирует и почему это происходит именно так.

Альтернативой «тяжелому» процессу является адаптивный (гибкий) процесс, основанный на принципах «быстрой разработки ПО», интенсивно развиваемых в последнее десятилетие.