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

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

...

следующие варианты применения мобильности:

• при полной несовместимости платформ может потребоваться разработка всего комплекса программ заново (возможно, с использованием имеющихся спецификаций требований и методов реинжениринга);

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

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

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

Задачи и объекты, связанные с мобильностью ПС и БД в системах и подлежащие рассмотрению при выборе методов и средств обеспечения переносимости, включают:

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

• языки программирования и инструментальные средства, поддерживающие создание переносимых ПС и БД систем и средства программной инженерии — CASE-системы;

• языки баз данных и системы управления базами данных;

• форматы данных, форматы внешних электронных сообщений;

— форматы переносимых электронных документов. Эффективность выбора и выделения компонентов для повторного

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

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

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

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

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

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

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

Процессы переноса программных средств и баз данных регламентируются рядом процедур и документов, стандартизированных в ISO 14764 (п. 8.5), который детализирует требования к процессам переноса, определенным в базовом стандарте на жизненный цикл ПС (см. ISO 12207, п. 5.5.5). Специалисты, которые проводят перенос по рекомендациям этих стандартов, должны разработать план переноса, известить пользователей, обучить персонал, выдать предупреждения о завершении переноса, оценить влияние новой версии и внешней среды и архивировать соответствующие данные. Если систему или программный продукт (включая данные) переносят из старой в новую эксплуатационную среду, следует обеспечить, чтобы программный продукт и данные были корректно изменены при переносе. Для этого необходимо решить следующие основные задачи: определить все добавляемые или изменяемые программные компоненты, продукты или данные; проверить соответствие реализации конкретных задач спецификациям требований заказчика на перенесенную версию ПС и БД.

Для контроля переноса системы необходимо разработать, документально оформить и выполнить план переноса программного продукта. К планируемым работам могут быть привлечены пользователи. В содержание плана должны быть включены:

— анализ и формирование требований к результатам переноса;

• разработка (или приобретение) инструментальных средств для выполнения переноса;

• настройка программного продукта и данных к новым условиям и среде эксплуатации;

• выполнение процессов переноса;

• верификация и тестирование результатов переноса;

• обеспечение последующей поддержки прежней среды и программного продукта.

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

Сопроводитель должен также представить пользователям план процедуры и график (Программу) переноса и решить следующие задачи:

• определить все компоненты, затрагиваемые переносом;

• отработать обратную связь и информацию с заказчиком и пользователями;

• определить специфику пользователей;

• опубликовать график (Программу) переноса.

Для плавного перехода в новую среду пользователями параллельно могут выполняться работы в прежней и новой среде с соответствующими версиями ПС и БД. Сопроводитель должен выполнить следующие работы по обучению персонала:

• определить требования по обучению для реализации переноса;

• запланировать реализацию требований по обучению переноса;

• выполнить проверку результатов обучения после выполнения переноса;

• обновить и откорректировать планы обучения.

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

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

Отчетными результатами работ по переносу ПС и БД являются:

• перенесенный программный продукт на новой платформе;

• план реализации переноса;

• инструментальные средства для переноса;

• извещения о намерениях по переносу;

• уведомление о завершении переноса;

• архивные данные процессов и результатов переноса. Предельным по сложности и трудоемкости случаем является перенос

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

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

При анализе баз данных, как объектов переноса, целесообразно рассматривать два компонента: системы управления данными (СУБД) и

совокупность данных, упорядоченных по некоторым правилам. Простейший вариант переноса информации БД на иную аппаратную платформу реализуется, когда на обеих платформах имеются апробированные СУБД одного типа и версий. При этом считается, что отсутствуют дополнительные технические ограничения для размещения всей информации БД и нет необходимости изменять и адаптировать ее структуру на новой аппаратной платформе. В этом случае основные работы сводятся к переносу всего объема информации БД и к испытаниям после этого, функционирования СУБД на новой платформе, на соответствие документации исходной версии СУБД с перенесенной информацией. При этом трудоемкость и длительность создания БД на новой платформе определяются в основном работами по переносу информации БД и испытаниями новой системы.

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

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

• форматная совместимость характеризуется степенью соответствия данных в БД анализируемых платформ требованиям стандартов на форматы представления данных для документальных, фактографических, словарных или иных баз данных;

• лингвистическая совместимость определяется степенью использования в рассматриваемых БД единых лингвистических средств (классификаторов, рубрикаторов, словарей), формализованных соответствующими стандартами;

— физическая совместимость заключается в степени соответствия кодировки информации БД одинаковым стандартам на машиночитаемые носители информации.

Если одновременно с информацией БД переносятся полностью программные средства СУБД, то это обеспечивает сохранение функций управления данными. Однако может потребоваться перенос информации БД на иную аппаратную платформу с другим типом СУБД. Тогда задача переноса усложняется.

Для средних и крупных проектов системный анализ переноса целесообразно завершать оценкой суммарной трудоемкости и длительности переноса программного продукта и их сопоставлением с полной разработкой ПС и БД при некотором использовании алгоритмического и системного задела. Кроме того, полученный комплекс программ следует оценивать по использованию памяти и производительности новой ЭВМ. Такую оценку необходимо проводить с учетом возможного тиража ПС и перспективы длительной его эксплуатации. Ориентация на снижение затрат при переносе программ зачастую отражается значительными потерями в эффективности эксплуатации системы вследствие увеличения объема программ в объектном коде и снижения их производительности, особенно когда программный продукт длительно используется на многих экземплярах ЭВМ в реальном времени.

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

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

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

При анализе затрат на сопровождение и мониторинга программных средств целесообразно рассматривать следующие сценарии:

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

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

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

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

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

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

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

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

• оценки размера — масштаба (числа строк) предполагаемого изменения текста разрабатываемых новых программ, с учетом размера готовых повторно используемых компонентов и характеристик возможного языка программирования;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

продолжение следует...

Продолжение:

Часть 1 15 СОПРОВОЖДЕНИЕ И МОНИТОРИНГ ПРОГРАММНЫХ СРЕДСТВ
Часть 2 15.3. Задачи и процессы переноса программ и данных на иные
Часть 3 15.4. Ресурсы для обеспечения сопровождения и мониторинга программных средств -
Часть 4 - 15 СОПРОВОЖДЕНИЕ И МОНИТОРИНГ ПРОГРАММНЫХ СРЕДСТВ