Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

Липаев В.В. Программная инженерия

.pdf
Скачиваний:
722
Добавлен:
02.05.2014
Размер:
10.14 Mб
Скачать

Лекция 15. Сопровождение и мониторинг программных средств

комплекса программ, как в любой профессиональной деятельности, необ­ ходимо сначала провести реалистическую оценку возможного изменения масштаба проекта — поставленных целей, ресурсов проекта и выделен­ ного времени. Задача управления масштабом состоит в задании базовых требований, которые включают разбитое на компоненты ограниченное множество дополнительных функций и требований, намеченных для реа­ лизации в конкретной версии проекта. Базовый уровень изменений масш­

таба ПС долж:ен обеспечивать:

приемлемый для заказчика минимум дополнительных функций и требований к версии программного продукта;

разумную вероятность успеха с точки зрения возможностей кол­ лектива сопровождения и разработчиков модификаций за требуемое время.

Потребность в ресурсах, объем реализуемых функций и требования спецификаций для модификаций в наибольшей степени зависят от допус­ тимого размера масштаба и сложности модификаций сопровош^даемого ПС, Основная цель оценки изменений масштаба ПС — подгото­ вить возможность принять обоснованное решение о допустимости даль­ нейшего мониторинга и сопровождения проекта в область системного анализа, разработки требований и проектирования модификаций и новых версий программного продукта. Если оказывается, что рассчитанные пер­ вично масштаб и требуемые ресурсы для изменений ПС не могут быть обеспечены заказчиком для продолжения сопровождения, то возможны кардинальные решения: либо изменение некоторых выделяемых ресурсов, либо прекращение мониторинга и модификации данного программного продукта.

Для уменьшения возмо:и€ных методических ошибок оценок ресур­ сов для сопровождения и модификации ПС следует начинать с прогнози­ рования размеров изменений или новой версии программного продукта, достоверность и ошибки которых могут быть обусловлены следующими

факторами:

проблема, цель и новые дополнительные функции ПС могут быть недостаточно хорошо поняты разработчиками модификаций и/или заказ­ чиками из-за того, что некоторые существенные факторы были упущены или искажены из-за предвзятого к ним отношения;

специалисты-оценщики масштаба изменений версии ПС могут до­ пустить значительные ошибки при попытке описания того, насколько боль-

500

15.4. Ресурсы для обеспечения сопровождения и мониторинга программных средств

шими могут быть изменения системы или комплекса программ до этапа разработки концепции или предварительного проекта модификации;

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

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

Затраты на сопровождение ПС можно оценивать потребностью трудовых и временных ресурсов для его обеспечения и для реализации. Эти затраты состоят из двух связанных частей: затрат на реализацию соответствующих характеристик качества, обеспечивающих эффективное сопровождение программных продуктов, и затрат при использовании этих характеристик в процессе эксплуатации комплекса программ. Обыч­ но совершенствование качества и повышение затрат на реализацию харак­ теристик способствует снижению затрат при их эксплуатации. Последние трудно оценить априори, так как они зависят от внешней среды и активно­ сти применения конкретного ПС, а не от его свойств и требуемого каче­ ства. (По некоторым оценкам, количество специалистов, участвующих в сопровождении на расширение функциональности и улучшение качества ПС (~ 40%) и на устранении дефектов (==15%), что превышает количество специалистов, занятых созданием новых программ (~ 45%)).

Стоимость и длительность сопровождения компонентов или комп­ лекса программ может определяться контрактом между заказчиком и по­ ставщиком по прецедентам аналогичных проектов с учетом изменяющей­ ся конъюнктуры. Затраты на обеспечение и реализацию сопровождения программ определяются длительностью цикла жизни комплекса программ; его мобильностью, уровнем автоматизации технологии разработки и тира­ жом программ. Для их оценивания, прежде всего, необходимо выделять основные виды затрат при сопровождении конкретного комплекса про­ грамм и наиболее существенные факторы, которые на них влияют. Такой анализ может дать ориентиры для прогнозирования общих затрат на сопровождение и для оценивания этой характеристики в конкретных

501

Лекция 15. Сопровождение и мониторинг программных средств

проектах ПС. При этом важно учитывать соотношение затрат на разра­ ботку и на сопровождение в течение цикла жизни всего тиранка ПС.

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

При системном анализе затраты на сопровождение можно считать аддитивными и включающими составляющие:

затраты на обнаружение и устранение ошибок и дефектов в каж­ дой версии ПС;

затраты на доработку и совершенствование программ, формирова­ ние и испытание новых модернизированных версий ПС;

затраты на тиражирование каждой новой версии и ее внедрение в эксплуатируемых и новых системах.

Доля каждой составляющей в общих затратах на сопровождение мо­ жет значительно изменяться в зависимости от особенностей сферы приме­ нения и жизненного цикла конкретного ПС. Для долгоживущих (-10 лет), тиражируемых (1000—100 000 экземпляров) ПС доминирующими обычно являются затраты на модернизацию и доработку версий программ. Затра­ ты на модернизацию зависят от тиража косвенно, вследствие расширения условий применения конкретного ПС и увеличения потока запросов пользо­ вателей на развитие программ. Так же косвенно влияет тираж на запросы для устранения выявленных ошибок.

502

15.4. Ресурсы для обеспечения сопровождения и мониторинга программных средств

Затраты на обнаружение и устранение дефектов и ошибок в про­ грамме определяются двумя факторами: затратами на обнаружение каж­ дой ошибки и затратами на устранение выявленных ошибок при формиро­ вании очередной версии. Чем меньше ошибок в программе, тем труднее они обнаруживаются, т.е. тем выше затраты на выявление каждой ошибки. Затраты на устранение ошибок и корректировку программ пропорцио­ нальны числу дефектов, выявленных между очередными версиями. При сопровождении непрерывно требуются затраты для контроля состояния версий программ и обеспечения их сохранности. По опыту работ, широко тиражируемый комплекс программ объемом ~ 10^ строк, может требовать непрерывных усилий коллектива в составе десятка и более специалистов для устранения ошибок, корректировок версий и документации.

Затраты на совершенствование и модернизацию программ близки по содержанию (но не по величине) к затратам на их первичную разработ­ ку. Модернизация обычно производится поэтапно. Для каждой новой эта­ лонной версии изменяется (разрабатывается) только некоторая часть от всего объема ПС. Эта часть при вводе очередной версии может составлять 10—20% от объема всего комплекса. Сложность связей в ПС приводит к тому, что удельные затраты на изменяемые программы при модернизации каждой версии могут быть в 2—3 раза больше, чем затраты на создание программ такого же объема при первичном проектировании. Эта величина зависит от того, насколько путем стандартизации архитектуры и интер­ фейсов при системном проектировании предусматривались перспективы совершенствования ПС. Для выполнения этих работ иногда используется коллектив специалистов, осуществивших первичную разработку. Такая организация наиболее характерна для уникальных, заказных ПС. В этих случаях первичную разработку и модернизацию трудно разделить. Для широко тиражируемых ПС на сопровождение часто выделяется специаль­ ный коллектив, не проводивший первичную разработку. В этих случаях этапы разработки и сопровождения, а также сопутствующие им затраты можно разделить более четко.

Затраты на тираэ§€ирование каждой новой версии включают сово­ купные затраты на производство экземпляров программного продукта, их инсталляцию в объектных ЭВМ и освоение для нормальной эксплуатации. Затраты на тиражирование версий при сопровождении практически про­ порциональны произведению числа версий и их тиража. Вследствие этого

503

Лекция 15. Сопровождение и мониторинг программных средств

даже относительно малые затраты на каждый экземпляр при внедрении новой версии могут приобретать большое значение в жизненном цикле всей серии версий программного продукта.

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

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

На основе анализа и оценивания рассчитанных характеристик ресур­ сов для сопровождения следует выполнять заключительное технико-эко­ номическое обоснование необходимости сопровождения конкретного программного продукта и определять:

целесообразно ли продолжать работы по сопровождению и мони­ торингу конкретного программного продукта или следует его прекратить вследствие недостаточных ресурсов специалистов, времени или большой трудоемкости разработки модификаций;

при наличии достаточных ресурсов следует ли провести маркетин­ говые исследования для определения рентабельности создания очередной версии программного продукта и поставки ее на рынок;

504

15.4.Ресурсы для обеспечения сопровождения и мониторинга программных средств

достаточно ли полно и корректно формализованы концепция и требования к модификациям версий программного продукта, на основе которых проводились экспертные оценки и расчеты затрат, или их следует откорректировать и выполнить повторный анализ с уточненными исход­ ными данными;

есть ли возможность применить готовые повторно используемые компоненты ПС, в каком объеме относительно размера комплекса про­ грамм и рентабельно ли их применять в конкретной версии программного продукта или весь проект целесообразно разрабатывать как полностью новый.

Л Е К Ц И Я 16

УПРАВЛЕНИЕ КОНФИГУРАЦИЕЙ В ЖИЗНЕННОМ ЦИКЛЕ ПРОГРАММНЫХ

СРЕДСТВ

16.1. Процессы управления конфигурацией программных средств

Цель управления конфигурацией при разработке и сопровождении

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

изменения взаимодействия компонентов ПС.

объектов — модулей и компонентов ПС разного уровня интегра­ ции, подвергающихся корректировкам (систему идентификации и адреса­ ции изменений в комплексе программ и в документах);

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

ив пространстве элементов версий комплекса программ (типы, содержа­ ние и взаимосвязь корректировок);

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

506

16.1. процессы управления конфигурацией программных средств

Процесс управления конфигурацией (стандарт ISO 12207, п. 6.2), является процессом применения административных и технических проце­ дур на всем протяжении ЖЦ программных средств для: обозначения, оп­ ределения и установления состояния базовой версии программных про­ дуктов в системе; управления изменениями и выпуском объектов; описа­ ния и сообщения о состояниях объектов и заявок на внесение изменений в них; обеспечения полноты, совместимости и правильности объектов; уп­ равления хранением, обращением и поставкой объектов. Этот процесс включает: подготовку процесса; определение конфигурации; контроль кон­ фигурации; учет состояний конфигурации; оценку конфигурации; управ­ ление выпуском и поставку программного продукта. Все основные и вспо­ могательные процессы подлежат адаптации и конкретизации примени­ тельно к характеристикам определенного проекта

Стандарт ISO 15846 обобщает, детализирует и развивает основные концептуальные положения, представленные в стандарте ISO 12207. Шесть разделов (6-й — 11-й) начинаются с цитирования соответствующих шести базовых требований раздела 6.2 стандарта ISO 12207. В каждом из них излагаются подробные рекомендации по реализации его базовых требова­ ний по управлению конфигурацией ПС. Существенным достоинством стан­ дарта ISO 15846 является подробное и систематичное изложение практи­ ческих рекомендаций по управлению конфигурацией сложных комплек­ сов программ, которые целесообразно использовать в крупных современных реальных проектах систем.

В процессе проектирования ПС должна быть формализована и доку­ ментально зафиксирована коррелированная с Концепцией сопровождения

(см. лекцию 15) Концепция

организации конфигурационного управления

проектами программных

средств, содержащая в основе:

ожидаемую длительность поддержки развития и модификации кон­ кретного проекта ПС;

масштаб и уровень предполагаемых изменений и модификаций;

возможное число и периодичность выпуска базовых версий про­ граммного продукта;

организационные основы процессов сопровождения и конфигура­ ционного управления программным средством;

требования к документированию изменений и базовых версий ПС;

507

Лекция 16. Управление конфигурацией в жизненном цикле программных средств

— КТО будет осуществлять управление конфигурацией — покупа­ тель, разработчик или специальный персонал поддержки ЖЦ ПС.

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

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

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

Средства и методы УК должны быть ориентированы на координиро­ ванное развитие мно:н€ества версий ПС и их компонентов, каждая из

508

16.1. Процессы управления конфигурацией программных средств

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

Цели и задачи концепции управления конфигурацией сложных программных средств

Организация специалистов и процессов управления конфигурацией программных средств

Конфигурационная идентификация и учет версий компонентов и программных средств

Управление запросами на изменения версий компонентов, программных средств и данных

Реализация корректировок версий компонентов, программных средств и данных

Контроль корректности конфигураций версий компонентов, программных средств и данных

Сборка и формирование базовых версий единиц конфигурации программного продукта

Создание отчетов о состоянии и изменениях конфигурации версий программного продукта

Постановка и выпуск базовых версий единиц конфигурации программного продукта

Архивирование и тиражирование базовых версий программного продукта и документов

Финансирование управления конфигурацией сложных программных средств

Рис. 16.1

509