А.М. Вендров - Объектно-ориентированный анализ и проектирование, страница 2

Затем архитектор мог бы проверитьнебоскреб и сравнить его с техническими требованиями. Если бы онразрушился или не смог пройти проверку, архитектор мог бы его снести иубрать обломки - мгновенно и опять же без затрат. Стал бы этотархитектор тратить много времени на формальную проверкусогласованности проекта с физическими законами? Или хотя бы пытатьсяисследовать и понять эти законы? Вряд ли. Он, вероятно, смог быполучить результаты быстрее путем многократного строительства,проверки и сноса небоскреба, каждый раз внося исправления в чертеж. Вмире, где строительство и разрушение бесплатны, выбирается метод проби ошибок, а фундаментальные исследования остаются на будущее.ПО разрабатывается именно в таком мире.

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

Но рост сложностисовременных программных систем подводит нас к жесткому пределу. Запределами определенного уровня сложности создание качественныхархитектур методом проб и ошибок становится невозможным.8Объективная потребность контролировать процесс разработкисложных систем ПО, прогнозировать и гарантировать стоимостьразработки, сроки и качество результатов привела в конце 60-х годовпрошлого века к необходимости перехода от кустарных к индустриальнымспособам создания ПО и появлению совокупности инженерных методов исредств создания ПО, объединенных общим названием "программнаяинженерия" (software engineering).

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

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

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

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

В соответствии с моделью СММ (Capability Maturity Model)Института программной инженерии (Software Engineering Institute, SEI), вхорошо подготовленной (зрелой) организации персонал обладаеттехнологией и инструментарием оценки качества процессов создания ПОна протяжении всего жизненного цикла ПО и на уровне всей организации.Процессы выстраиваются таким образом, чтобы обеспечить реальныесроки создания ПО.При решении проблемы повышения эффективности создания ПОосновное внимание уделяется, как правило, процессу разработки ПО, чтовызвано естественным желанием разработчиков и заказчиков экономитьсредства с самого начала проекта (особенно в условиях ограниченныхфинансовых возможностей и высокой конкуренции). В то же времябольшинство крупномасштабных проектов создания ПО характеризуетсядлительным жизненным циклом (10-15 лет), в котором на стадию создания(разработки) приходятся только первые 3-4 года, а остальное времяэксплуатации созданной системы – на стадию сопровождения.Под сопровождением в общем случае понимается внесение измененийв эксплуатируемый программный продукт в целях исправленияобнаруженных ошибок (корректирующее сопровождение), повышенияпроизводительности и улучшения эксплуатационных характеристиксистемы (совершенствующее сопровождение), а также адаптации кизменившейся или изменяющейся среде (адаптирующее сопровождение).При этом более 50% общего объема работ по сопровождению приходитсяна совершенствующее сопровождение.

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

Так, по оценкам компании Hewlett-Packard, в 1994 г. от60% до 80% ее разработчиков были заняты сопровождением ПО, а в10отчетах федеральных служб США ранее отмечалось, что насопровождение уходит от 50% до 80% рабочего времени программистов.По мере развития новых технологий стало ясно, что суммарныезатраты на сопровождение и создание новых версий могут значительнопревосходить затраты на разработку первой версии ПО. Действительно,если разработка первой версии сложного ПО продолжается 3 года, апоследующая его эксплуатация и создание версий происходит в течении10 лет, то можно ожидать, что суммарные затраты на этих интервалахвремени соизмеримы. Даже при предположении, что сопровождением иразработкой новых версий будет занята половина специалистов,осуществивших создание первых версий, суммарные затраты на этиработы превысят первичные.

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

"Тяжелый" процесс обладаетследующими особенностями:• необходимость документировать каждое действие разработчиков;• множество рабочих продуктов (в первую очередь - документов),создаваемых в бюрократической атмосфере;• отсутствие гибкости;• детерминированность (долгосрочное детальное планирование ипредсказуемость всех видов деятельности, а также распределениечеловеческих ресурсов на длительный срок, охватывающийбольшую часть проекта.Альтернативой "тяжелому" процессу является адаптивный (гибкий)процесс, основанный на принципах "быстрой разработки ПО", интенсивноразвиваемых в последнее десятилетие.В начале 2001 года века ряд ведущих специалистов в областипрограммной инженерии (Алистер Коберн, Мартин Фаулер, ДжимХайсмит, Кент Бек и другие) сформировали группу под названием AgileAlliance. Слово agile (быстрый, ловкий, стремительный) отражало в целомих подход к разработке ПО, основанный на богатом опыте участия вразнообразных проектах в течение многих лет. Этот подход под названием11"Быстрая разработка ПО" (Agile software development) базируется начетырех идеях, сформулированных ими в документе "Манифест быстройразработки ПО" (Agile Alliance's Manifesto) и заключающихся вследующем [6]:• индивидуумы и взаимодействия между ними ценятся вышепроцессов и инструментов;• работающее ПО ценится выше всеобъемлющей документации;• сотрудничество с заказчиками ценится выше формальныхдоговоров;• реагирование на изменения ценится выше строгого следованияплану.Центральными для быстрой разработки ПО являются простые, нодостаточные правила выполнения проекта, а также ориентация на людей икоммуникацию.Быстрота предполагает маневренность, характеристику, которая внастоящее время становится более важной, чем когда-либо.Распространение ПО в Интернете еще больше усилило конкуренциюмежду программными продуктами.