И. Соммервилл - Инженерия программного обеспечения (1133538), страница 145
Текст из файла (страница 145)
В 1980-х годах было обнаружено (218), что во многих организациях по меньшей мере 50% всех средств, потраченных на программирование, влет на развитие уже существующих систем. В работе [235) опреде. лево похожее соотношение затрат на различные вцдь< сопровождения, при этом от 65 до 75% средств общего бюджета расходуется на сопровождение. Так как предприятия заменяют старые системы коммерческим ПО, например программами планирования ресурсов, эти цифры никак не будут >меньшаться.
Поэтому можно утверждать, что из. иепепие ПО все еще остается доминирующим в статье затрат организаций на про. граммное обеспечение. Соотношение между величинами средств на сопровождение и на разработку может быть разным в зависимости от предметной области, где эксплуатируется система. Для прпклалных систем, работающих в деловой сфере, соотношение затрат на сопровождение в основном сравнимо со средствами, потраченными на разработку. Для встроенных систем реалы<ого времени затраты па сопровождение могут в четыре раза превышать стоимость самой разработки. Высокие треГ><>ванна в отно<пепии производительности и 27. Модернизация программного обеспечения 557 надежности таких систем предполагают их жесткую структуру, которая труднее поддается модификации.
Можно получить значительную общую зкономию средств, если заранее потратить финансы и усилия на создание системы, не требующей дорогостоящего сопровождения. Весьма затратно проводить изменения в системе после ее поставки заказчику, поскольку для этого требуется хорошо знать систему и провести анализ реализации этих изменений. Поэтому усилия, потраченные во время разработки программы на снижение стоимости такого анализа, автоматически снизят н затраты на сопровождение. Такие текнолотин разработки ПО, как формирование четких требований, объектно.
ориентированное про. граммирование и управление конфигурацией, способствуют снижению стоимости сопровождения. На рис. 27З показано, как снижается стоимость сопровождения хорошо разработанных систем. Здесь при разработке системы 1 вьщелено дополнительно 325 000 длл облегчения процесса сопровождения. В рез>льтате эа время эксплуатации системы это помогло сэкономить около $100 000. Из сказанного следует, что увеличение средств па разработку системы пропорционально снизит затраты на ее сопровождение.
Система 1 Система 2 0 50 100 150 200 250 300 350 400 450 500 Я Расхоже иа разработку и Расхсяи иа ссярсвокдение Рис. 27З. Рпсходы кп Влзрабстяку и сопровождпше сисхмж Причиной высоких затрат на сопровождение является сложность модернизации сис.
темы после ее внедрения, поскольку расширить функциональные возможности намного легче в процессе создания системы. Ниже приведены ключевые факторы, которые онре. делают стоимость разработки и сопровождения и мотуг привести к подорожанию сопровождения. 1. Сэиитильнасэть хомлидырлзрпботчиков. Вполне естественно, что после внедрспнл системы команда разработчиков распадается, специалисты Гхулуг работать пал другими проектами. Новым членам команды пли же отдельпьпт специалистам, которые возьмут на себя дальнейшее сопровождение системы, будет трудно понять все ее особенности. Поэтому на понимание системы перед внесением в нее излтепений уходит много времени и средств. 2. Омэеиижвекиоаиь согласна каимвакту. Контракт на сопровождение обычно заключается отдельно от договора на разработку программы. Более того.
часто коптралт на сопровождение может получить фирма, сама не занилшющюшя разработкой. Вместе с фактором нестабильности команды это может стать причиной отсугствил в команде стимула создать легкоизменяемую, удобную в сопровождении систему. Если членам команды выгодно пойти кратчайшилт путем с минимальными затратами усилий, то вряд ли они откажутся от этого даже с риском повышения тюследующпх затрат на сопровождение. 558 пасть 'э11. Эволюция программного обеспечения 3.
Квалифнхлиал глг>!иплигэ>ов, Специалисты, занимающиеся сопровождением, часто ие знакомы с предметной областью, где эксплуатируется система. Сопро. волщснис не пользуетгя популярностью среди разработчиков. Это считается менее квалифицированной разработкой и часто поручается младшему персоналу. Более того, старые системы могут быть написаны на устаревших языках программирования, нс знакомых молодым специалистам и треб>ющих дополнительного извчеиия. 4.
Воз/>лил и сжрукюура ярогрлл>лм. С возрастом структура программ нарушается вслслствие частых изменений, поэтому нх становится сложнее понимать и изменять. Кроме того, многие наследуемые системы были созданы без использо. ванна современных технологий. Опи никогда нс отличались хорошей качественной структурой; изменения, сделанные в ннх, были направлены скорее на повышение эффективности функционирования, чем на повышение удобства сопровождения.
Документация иа старые системы часто бывает неполной либо вообще отсутствует. Первые трп проблемы объясняютсл тем, что многие организации все еще дела>ат рззлн шс мсжлу разработкой системы и се сопровождением. Сопровождение счита. стел >>елим ат»ростспеиным, поэтому нет никакого желанил инвестировать средства для снижения затрат на буду>иее сопровождение. Руководству органиэаций необходимо помнить, что у систем редко бывает четко определенный срок функинонирования, наоборот, опи могут находиться в экспл>атации в той либо иной форме неограниченное время.
Дилемма заюпочастся в следующем: илн созпавать системы и поддерживать пх до тех пор, нокз это возможно, и затем замснлть их новыми, или разрабатывать постоянно эволюппоипртющпе системы, которые мо>уг изменяться в соответствии с новыми трсбова. и нами. Их можно создавать на основе наследуемых систсл», лучшая структуру последних с помощью реинжениринга (см. главу 28), либо п>тел> изменения архитектуры этих систем, что полробпо рассматрп ваетсл в разделе 27.3. Послсдпая проблема, а имсппо нарушение структуры, является самой простой из них.
Технология реинжениринга поможет усовери>енствовзть струкзуру и новь>сить понимасмосп системы. В подходящих случалх адаптировать систему к новым аппаратна>м средствам может и преобразование зрхптелтуры (см. далее). Профилактические меры при сопровождении б>удуг полезна>, если возникнет необходимость усовершенствовать систему и сделать сс более удобн>я! для изменений. 27.2.1. Процесс сопровождения Процессы сопровождения ь>о»т быть самыми разными, что зависит от типа программного обсспсчепил, технологии его разработки, а также ог специалистов, которые непосредственно занимал>кь созданием системы.
Во многих организациях сопровождение носит неформальный характер. В большинстве случаев разработчики получают ин. >)а>рмаиию о проблемах системы от самих пользователей в устной форме. Другие же ком. панин имени формальный процесс сопровожлсния со структурировашюй документацией на кажльп! его этап. По па самом общем уровне любые процессы сопровождения имеют общие этапы, а име>шо: анализ изменений, планирование версий, реализация новой вор. син системы и поставка системы заказчику.
Процесс сопровождения начинается при наличии достаточного количества запросов иа изменения от пользователей, менеджеров или покупателей. Далее оцениваются ю>зможпыс изменения с тем, чтобы определить уровень л>одсрннзапни системы, а так. 27. Модернизация программного обеспечения 699 жс стоимость внедрения этих изменений. Если принимается решение о модернизации систсмы, начинается этап планирования новой версии системы.
Во время планирова. ния анализирустся возможность реализации всех необходимых изменений, будь то ис. правлснис ошибок, адаптацил или расширение функциональных возможностей системы. Только после этого принимается окончатсльнос рсшснис о том, какие именно изменения будут внесены в систему. Когда нзмснсния реализованы, выходит очередная версия систслеы. На рнс. 27.4, занмствованиолл из книги [13), представлен весь процесс модсрпнзации. Риг 27.4.
Схема процеееамодфпизонии В идеале процссс модернизации должон привести к изменению системной специ. фикацин, архитектуры и программной реализации (рис. 27.5). Новые требования должны отражать изменения, вносимые в систсму. Ввод в систему новых компонентов требует сс исрспросктированил, после чего необходимо повторное тестирование системы. Для анализа вносимых изменений при цсобходимости можно создать прототип системы. На этой стадии проводится подробный анализ изменений, нри котором могут выявиться тс послсдствил модсрнизации, которые нс были замечены при начальном анализе изменений. Риг. 275.
Выполнепиезодрлизации Иногда в экстренных случаях требуется быстрое внесение изменений, например по следующим причинам. ° Сбой в системе, вследствие чего возникла чрезвычайная ситуация, трсбующая экс- тренного вмсшатсльства для продольчсния нормальной работы системы. ° Измснспис рабочсго окружения системы с непредусмотренным влиянием на спетому.
° Неожиданные измснснил в деловой афере организации (из-за действий коилеурсль тов или из-за введения нового законодательства). В таких случаях быстрая реализация измснсний имост болыпую важность, чем четкое следование формальностям процесса модернизации системы. Вместо того чтобы изменять требования или структуру системы, лучше быстро внести коррективы в программ. пый код (рпс.
27.б). Олнако этот подход опасен том, что трсбовання, спстсмнэл архитск- 560 'Часть 1З11. Эволюция программного обеспечения тура и программный код постепенно теряют целостность. Этого трудно избежать, если принять во внимание необходимость быстрого выполнения задания, когда тщательная доработка системы откладывается на потом. Если разработчик, который изменил код, внезапно уходит из команды, то его коллеге будет сложно привести в соответствие еде. ланным изменениям спецификацию и структуру системы.
Запрем Аизииз Модифишшв Постеека иа изменения исадного кода исксдиого кода измененной системы Риг. 27.6. 17[иякгсс зксм)екнкой медеузкизлкии азгжккм Еще одна проблсма срочных изменений системы состоит в том, что из-за дефицита времени из двух возможных решений будет принято не самое лучшее (в аспекте сохранения структуры системы), а то, которое можно быстрее и эффективнее реализовать. В идеале после срочной коррекции кода системы запрос на изменения должен все еще оставаться в силе. Поэтому после тщательного анализа изменений можно отменить внесенные изменения и принять более оптимальное решение для иодерпизации системы. Однако иа практике такая возможность используется крайне редко, чаще всего в силу субъективных причин. 27.2.2. Прогнозирование сопровождения Менеджеры терпеть нс могут сюрпризов, особенно если онн выливаются в непредсказуемо высокие затраты. Поэтому лучше предусиотрсть заранее, какие изменения возможны в системс, с какими компонентами системы будет больше всего проблем при сопровождении, а также рассчитать общие затраты на сопровождение в течение определенного периода врелзенп.
11а рис. 27.7 представлены различные типы прогнозов, связанные с со. провожлснпсм, н показано, на какие вопросы они должны ответить. Прогнозирование количества запросов на изменения системы зависит от понимания взаимосвязей между системой и ее окружением. Некоторые системы находятся в доста. точно сложной взаимозависимости с внешним окружением и изменение окружения обязательно повлияет на систему. Для того чтобы правильно судить об этих взаимоотношениях, необходимо оценить следующие показатели.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
