Главная страница | Контакты | Случайная страница Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

ПРОГРАММНАЯ ИНЖЕНЕРИЯ

Объективная потребность контролировать процесс разработ­ки сложных систем ПО, прогнозировать и гарантировать стои­мость разработки, сроки и качество результатов привела в конце 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 гг., в понятие сопровождения ПО входило только исправление ошибок и устранение мелких замечаний пользователей. Технология сопровождения представ­лялась достаточно простой и сравнительно