В чем заключается понятие сопровождения программного обеспечения
Обновлено: 02.07.2024
- Сопровожде́ние (поддержка) программного обеспечения — процесс улучшения, оптимизации и устранения дефектов программного обеспечения (ПО) после передачи в эксплуатацию.
Связанные понятия
Проектирование программного обеспечения — процесс создания проекта программного обеспечения (ПО), а также дисциплина, изучающая методы проектирования.
Документа́ция на программное обеспечение — печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст, описывающие, как пользоваться программным продуктом.
Ка́чество програ́ммного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014).
Процесс разработки программного обеспечения (англ. software development process, software process) — структура, согласно которой построена разработка программного обеспечения (ПО).
Непрерывная интеграция (CI, англ. Continuous Integration) — практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем. В обычном проекте, где над разными частями системы разработчики трудятся независимо, стадия интеграции является заключительной. Она может непредсказуемо.
Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации.
Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает.
Прототипи́рование программного обеспечения (от англ. prototyping) — этап разработки программного обеспечения (ПО), процесс создания прототи́па программы — макета (черновой, пробной версии) программы, обычно — с целью проверки пригодности предлагаемых для применения концепций, архитектурных и/или технологических решений, а также для представления программы заказчику на ранних стадиях процесса разработки.
Высокая доступность (англ. high availability) — характеристика технической системы, разработанной для избежания невыполненного обслуживания путём уменьшения или управления сбоями и минимизацией времени плановых простоев. Высокая доступность ожидается от систем жизнеобеспечения, здравоохранения и систем, от которых зависит благополучие общества в целом и экономического благополучия отдельных организаций.
Се́рвис-ориенти́рованная архитекту́ра (SOA, англ. service-oriented architecture) — модульный подход к разработке программного обеспечения, основанный на использовании распределённых, слабо связанных (англ. loose coupling) заменяемых компонентов, оснащённых стандартизированными интерфейсами для взаимодействия по стандартизированным протоколам.
Требования к программному обеспечению — совокупность утверждений относительно атрибутов, свойств или качеств программной системы, подлежащей реализации. Создаются в процессе разработки требований к программному обеспечению, в результате анализа требований.
Распределительная вычислительная среда (англ. Distributed Computing Environment, сокр. DCE) — система программного обеспечения, разработанная в начале 1990-х годов в Open Software Foundation, который представлял собой ассоциацию нескольких компаний: Apollo Computer, IBM, Digital Equipment Corporation и других. DCE предоставляет фреймворк и средства разработки клиент-серверных приложений.
Кодогенерация — часть процесса компиляции, когда специальная часть компилятора, кодогенератор, конвертирует синтаксически корректную программу в последовательность инструкций, которые могут выполняться на машине. При этом могут применяться различные, в первую очередь машинно-зависимые оптимизации. Часто кодогенератор является общей частью для множества компиляторов. Каждый из них генерирует промежуточный код, который подаётся на вход кодогенератору.
Политика безопасности организации (англ. organizational security policies) — совокупность документированных руководящих принципов, правил, процедур и практических приёмов в области безопасности, которые регулируют управление, защиту и распределение ценной информации.
Схема базы данных включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных.
Безопасность приложения ( англ. Application Security ) включает в себя меры, принимаемые для повышения безопасности приложения, часто путем обнаружения, исправления и предотвращения уязвимостей в безопасности. Для выявления уязвимостей на разных этапах жизненного цикла приложений, таких как проектирование, разработка, развертывание, обновление, обслуживание, используются различные методы.
Насыщенное интернет-приложение (англ. rich internet application, RIA) — это веб-приложение, загружаемое пользователем через интернет, предназначенное для выполнения функций традиционных настольных приложений и работающее на устройстве пользователя (не на сервере).
Визуальное программирование — способ создания программы для ЭВМ путём манипулирования графическими объектами вместо написания её текста. Визуальное программирование часто представляют как следующий этап развития текстовых языков программирования. Наглядным примером может служить утилита Визуальный Pascal или Microsoft Visual Studio, где редактируются графические объекты и одновременно отображается соответствующий текст программы. В последнее время визуальному программированию стали уделять больше.
Автоматизированное тестирование программного обеспечения — часть процесса тестирования на этапе контроля качества в процессе разработки программного обеспечения. Оно использует программные средства для выполнения тестов и проверки результатов выполнения, что помогает сократить время тестирования и упростить его процесс.
Ссы́лочная це́лостность (англ. referential integrity) — необходимое качество реляционной базы данных, заключающееся в отсутствии в любом её отношении внешних ключей, ссылающихся на несуществующие кортежи.
Покры́тие ко́да — мера, используемая при тестировании программного обеспечения. Она показывает процент исходного кода программы, который был выполнен в процессе тестирования.
Безопасность доступа к памяти — концепция в разработке программного обеспечения, целью которой является избежание программных ошибок, которые ведут к уязвимостям, связанным с доступом к оперативной памяти компьютера, таким как переполнения буфера и висячие указатели.
Защита памяти (англ. Memory protection) — это способ управления правами доступа к отдельным регионам памяти. Используется большинством многозадачных операционных систем. Основной целью защиты памяти является запрет доступа процессу к той памяти, которая не выделена для этого процесса. Такие запреты повышают надёжность работы как программ, так и операционных систем, так как ошибка в одной программе не может повлиять непосредственно на память других приложений. Следует различать общий принцип защиты.
Отказоустойчивый кластер (англ. High-Availability cluster, HA cluster — кластер высокой доступности) — кластер (группа серверов), спроектированный в соответствии с методиками обеспечения высокой доступности и гарантирующий минимальное время простоя за счёт аппаратной избыточности. Без кластеризации сбой сервера приводит к тому, что поддерживаемые им приложения или сетевые сервисы оказываются недоступны до восстановления его работоспособности. Отказоустойчивая кластеризация исправляет эту ситуацию.
Язы́к запро́сов — это искусственный язык, на котором делаются запросы к базам данных и другим информационным системам, особенно к информационно-поисковым системам.
Кросс-компиля́тор (англ. cross compiler) — компилятор, производящий исполняемый код для платформы, отличной от той, на которой исполняется сам кросс-компилятор. Такой инструмент бывает полезен, когда нужно получить код для платформы, экземпляров которой нет в наличии, или в случаях когда компиляция на целевой платформе невозможна или нецелесообразна (например, это касается мобильных систем или микроконтроллеров с минимальным объёмом памяти).
Уровень абстракции — один из способов сокрытия деталей реализации определенного набора функциональных возможностей. Применяется для управления сложностью проектируемой системы при декомпозиции, когда система представляется в виде иерархии уровней абстракции.
Автоматизация сборки — этап процесса разработки программного обеспечения, заключающийся в автоматизации широкого спектра задач, решаемых программистами в их повседневной деятельности.
Паке́т прикладны́х програ́мм (аббр. ППП, англ. application package) или паке́т програ́мм — набор взаимосвязанных модулей, предназначенных для решения задач определённого класса некоторой предметной области. По смыслу ППП было бы правильнее назвать пакетом модулей вместо устоявшегося термина пакет программ. Отличается от библиотеки тем, что создание библиотеки не ставит целью полностью покрыть нужды предметной области, так как приложение может использовать модули нескольких библиотек. Требования же.
Разделяемая память (англ. Shared memory) является самым быстрым средством обмена данными между процессами.
Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы, наборы из одного или более программных модулей вместе с соответствующими управляющими данными, процедурами использования и обработки.
Программное обеспечение для управления проектами — комплексное программное обеспечение, включающее в себя приложения для планирования задач, составления расписания, контроля цены и управления бюджетом, распределения ресурсов, совместной работы, общения, быстрого управления, документирования и администрирования системы, которое используются совместно для управления крупными проектами.
Открытая архитектура — архитектура компьютера, периферийного устройства или же программного обеспечения, на которую опубликованы спецификации, что позволяет другим производителям разрабатывать дополнительные устройства к системам с такой архитектурой.
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование.
Стати́ческий ана́лиз ко́да (англ. static code analysis) — анализ программного обеспечения, производимый (в отличие от динамического анализа) без реального выполнения исследуемых программ. В большинстве случаев анализ производится над какой-либо версией исходного кода, хотя иногда анализу подвергается какой-нибудь вид объектного кода, например P-код или код на MSIL. Термин обычно применяют к анализу, производимому специальным программным обеспечением (ПО), тогда как ручной анализ называют «program.
Опыт пользователя, опыт взаимодействия (англ. User eXperience, UX) — это восприятие и ответные действия пользователя, возникающие в результате использования и/или предстоящего использования продукции, системы или услуги (ISO 9241-210):2.
Модуль ядра, загружаемый модуль ядра (англ. loadable kernel module, LKM) — объект, содержащий код, который расширяет функциональность запущенного или т. н. базового ядра ОС. Большинство текущих систем, основанных на Unix, поддерживают загружаемые модули ядра, хотя они могут называться по-разному (например, kernel loadable module в FreeBSD и kernel extension в Mac OS X).
Двои́чная совмести́мость, бина́рная совмести́мость (англ. binary compatibility) — вид программной совместимости, позволяющий программе работать в различных средах без изменения её исполняемых файлов.
Мо́дульное программи́рование — это организация программы как совокупности небольших независимых блоков, называемых модулями, структура и поведение которых подчиняются определённым правилам. Использование модульного программирования позволяет упростить тестирование программы и обнаружение ошибок. Аппаратно-зависимые подзадачи могут быть строго отделены от других подзадач, что улучшает мобильность создаваемых программ.
Распределённая система — система, для которой отношения местоположений элементов (или групп элементов) играют существенную роль с точки зрения функционирования системы, а, следовательно, и с точки зрения анализа и синтеза системы.
Бухгалтерская система (система автоматизации бухгалтерского учёта, САБУ) — программное обеспечение, предназначенное для ведения бухгалтерского и фискального (направленного на удовлетворение требований государства по расчёту и уплате налогов) учёта.
Механизм копирования при записи (англ. Copy-On-Write, COW) используется для оптимизации многих процессов, происходящих в операционной системе, таких как, например, работа с оперативной памятью или файлами на диске (пример — ext3cow).
Система реального времени (СРВ) — это система, которая должна реагировать на события во внешней по отношению к системе среде или воздействовать на среду в рамках требуемых временных ограничений. Оксфордский словарь английского языка говорит об СРВ как о системе, для которой важно время получения результата. Другими словами, обработка информации системой должна производиться за определённый конечный период времени, чтобы поддерживать постоянное и своевременное взаимодействие со средой. Естественно.
Положение темы настоящей главы в контексте разработки программного обеспечения иллюстрирует рис. 10.1.
Рассмотрим типичную последовательность действий по обработке запроса на сопровождение (MR — maintenance request).
Сопровождение программного продукта включает в себя все действия, выполняемые с приложением после поставки продукта заказчику. В словаре IEEE [57].
сопровождение программы определяется как процесс изменения программной системы или компонента после поставки с целью исправления ошибок, повышения производительности или иных параметров, а также для адаптации к изменившимся условиям.
По различным оценкам сопровождение программы составляет от 40 до 90 % стоимости всего жизненного цикла приложения (например, [31], [89]). Можно возразить, что в указанное выше определение сопровождения включены усовершенствования, которые лучше было бы считать дополнительными разработками. В любом случае объем работ по сопровождению программ обычно достаточно велик. Наиболее значительные усилия в области сопровождения были затрачены на решение проблемы 2000 года (Y2K). Изменение приложений для работы с датами, относящимися к новому тысячелетию, потребовало огромного труда. Эти работы относятся именно к сопровождению программ, потому что их целью было сохранение функциональности существующих приложений.
♦ высокая стоимость тестирования по сравнению с пользой от отдельных изменений: идеальным было бы сосредоточенное тестирование, но оно стоит дорого. Невозможно полностью исключить регрессионное тестирование.
Руководство обычно гораздо сильнее интересуется процессом поставки приложений. Кроме того, затраты на сопровождение программы трудно классифицировать как прибыль на инвестированный капитал.
Раскроем этот момент подробнее. Предположим, что Военно-морской флот уведомляет нас (фирму-подрядчик) о том, что алгоритм согласования трех независимых источников навигационных данных работает неправильно. Необходимо оценить стоимость внесения исправлений. Пример расчета приведен в табл. 10.1. Затраты на изменение программы при стоимости одного человеко-часа $50-100 (с учетом пособий и т. п.) будут составлять, таким образом $5600-28 000. Разброс значений очень велик.
Если бы мы имели дело с одним конкретным изменением, проблемы были бы еще не так велики. Обычно организации сталкиваются с непрерывным потоком запросов на сопровождение. Большое количество изменений позволяет снизить стоимость каждого из них, но поток запросов создает повышенные требования к системе обработки. Усилия программистов, тестеров и разработчиков документации нужно координировать. Например, нужно ли обновлять SRS после обнаружения ошибки, после ее устранения, после тщательного тестирования или же, наконец, после объединения данного исправления с другими операциями, выполненными в рамках работ по сопровождению? В любом случае согласованность документации и исходного кода будет время от времени нарушаться. Без внимательного руководства эти кратковременные, казалось бы, несоответствия начнут размножаться, в результате чего документация перестанет соответствовать реальным функциям приложения, и никто не будет знать, что же на самом деле творится с приложением.
Суть в том, чтобы сделать изменения понятными и даже элегантными. Элегантность хорошо иллюстрирует следующий пример: можно увеличить полезное пространство в доме, пристроив к нему сарай, а можно сохранить цельность здания, увеличив его объем искусными архитектурными приемами. Пристройка может ухудшить внешний вид и структуру всего здания, а хороший архитектор всегда постарается этого избежать.
Пункт 2 состоит в принятии решения о масштабах затрат на сопровождение: главным образом речь идет о том, следует ли относить усовершенствования к работам по сопровождению. Возможные варианты рассматриваются в разделе 10.2.
Согласно пункту 3, вам предстоит выбрать, своими или наемными силами выполнять работы по сопровождению. Заключение контракта на сопровождение программы обладает преимуществами конкурентоспособной цены и дает возможность владельцу приложения сосредоточиться на других задачах. Недостаток в том, что ваши сотрудники постепенно теряют контроль над кодом приложения.
Следует различать работы по сопровождению, направленные на устранение дефектов (fixing) и на усовершенствование (enhancing) приложения. Различные исследования показали, что 60-80 % работ обычно относится к усовершенствованию приложения, а не к исправлению его недостатков (например, [89] и [38]).
Лиенц, Свенсон и др. [79] дополняют иерархию работ, разбивая каждую из определенных выше категорий на две (рис. 10.3).
Приспособление, или адаптация (adaptive maintenance), относится к исправлению недостатков, потому что функциональность приложения в результате не изменяется и никакого усовершенствования не происходит.
Необходимость упреждающего сопровождения (preventive maintenance) следует из наблюдений Лемаша [Lei, Le2]): без специальных поправок структура сопровождаемой программы постепенно усложняется и со временем становится настолько сложной, что стоимость ее изменения становится неприемлемой.
Рассмотрим пример одного из видов сопровождения применительно к игре Встреча. Пример исправления недостатков показан в запросе на сопровождение 78. Персоналу, который занимается сопровождением, нужно решить: кроется ли ошибка в методе adjustQual ity О или неправильно сформулированы требования к персонажам игры. На самом деле проблема именно в требованиях, которые гласят:.
♦ пользователь может установить для любой характеристики своего персонажа любое значение, не превышающее текущей суммы значений всех характеристик;.
Как следует из запроса 78, эти требования противоречивы и не могут быть удовлетворены одновременно. Поскольку проблема обнаружена в требованиях к программе, заказчик должен санкционировать внесение изменений. Можно, например, ослабить последнее требование (требование инвариантности суммы), записав его в форме.
В настоящем разделе рассмотрена разработка политики сопровождения программного средства. Данная политика ориентирована на людские и материальные ресурсы, необходимые для обеспечения сопровождения программного продукта. В качестве целей при планировании сопровождения должны быть использованы результаты анализа сопровождаемости. Этот анализ является исходным пунктом при разработке стратегии сопровождения. Политика сопровождения программного средства должна охватывать следующие элементы:
7.2 Концепция сопровождения
Описание концепции сопровождения должно быть первым шагом при разработке политики сопровождения программного средства. Концепция сопровождения должна быть разработана сразу же при первом выпуске исходного программного продукта.
Концепция сопровождения должна отражать:
- область сопровождения программного средства;
- практическое применение (адаптацию) данного процесса;
- определение организаций (лиц), ответственных за сопровождение;
- оценку стоимости сопровождения.
Примечание - Концепцию сопровождения документально оформляют в плане сопровождения.
7.2.1 Область сопровождения
Данная область должна отражать обязанности сопроводителя. Она должна определять, какую поддержку программного средства обязан обеспечить сопроводитель. Область сопровождения зачастую определяется наличием соответствующих бюджетных ограничений. Область сопровождения должна охватывать:
- типы выполняемого сопровождения;
- сопровождаемый уровень документов;
- реакцию (чувствительность) на сопровождение;
- обеспечиваемый уровень обучения персонала;
- обеспечение поставки продукта;
- организацию справочной службы ("горячей линии").
7.2.2 Практическое применение (адаптация) процесса
Концепция сопровождения должна отражать задачи сопровождения программного средства после его поставки. Во время сопровождения различные организации могут выполнять различные задачи. В концепции сопровождения следует попытаться определить эти организации. В концепции сопровождения также должен быть отражен применяемый процесс сопровождения.
7.2.3 Определение ответственных за сопровождение
Определение лиц (физических или юридических), отвечающих за сопровождение продукта, является важной частью концепции сопровождения. Это в равной степени справедливо и в случае внутреннего сопровождения в самой организации. При выполнении сопровождения по соглашению с третьей стороной (аутсорсинг) это должно быть отмечено в концепции сопровождения. В основных процессах заказа и поставки по ГОСТ Р ИСО/МЭК 12207 детально описаны услуги по заказу и поставке.
Назначение (выбор) сопроводителя должно быть основано на ряде факторов, включая:
- срок службы программного средства;
- размер долгосрочных затрат;
- размер первоначальных затрат;
- наличие соответствующего места;
- работоспособность программного продукта;
- программу (график) сопровождения;
- знание предметной области применения программного продукта.
7.2.4 Оценка стоимости сопровождения
Должна быть проведена оценка стоимости сопровождения. Стоимость должна зависеть от области сопровождения. Дополнительными факторами, подлежащими учету, являются стоимость:
- проезда до места расположения пользователя;
- обучения как сопроводителей, так и пользователей;
- СПИ и СТПС и их ежегодного сопровождения;
- персонала (зарплата и премии).
При разработке концепции сопровождения стоимость оценивают на основе ограниченных исходных данных. В дальнейшем эти оценки должны быть уточнены. В качестве исходных данных при оценке стоимости сопровождения могут быть использованы соответствующие архивные данные по аналогичным проектам.
7.3 Планирование сопровождения
Целью планирования сопровождения является подготовка плана работ по сопровождению и обеспечение заказа (закупки) ресурсов, необходимых для проведения этих работ после передачи программного продукта на сопровождение. Планирование начинается сразу после определения концепции сопровождения программного средства и завершается разработкой плана сопровождения, используемого сопроводителями в качестве основы при оказании соответствующих услуг по сопровождению программного средства.
7.3.2 План сопровождения
Планирование работ и задач по сопровождению начинается сразу после принятия описанной выше концепции сопровождения. Оно завершается созданием плана сопровождения. Данный план должен быть подготовлен сопроводителем во время разработки программного средства и включать в себя рассмотрение предложений пользователя по внесению изменений в программный продукт.
План сопровождения должен определять:
- причины необходимости сопровождения;
- исполнителей данных работ;
- роли и обязанности каждого субъекта, вовлеченного в сопровождение;
- как должны быть выполнены данные работы;
- какие имеются ресурсы для сопровождения;
- место проведения сопровождения;
- время начала сопровождения.
7.3.3 Рекомендации по плану сопровождения
В настоящем пункте приведены рекомендации по разработке плана сопровождения. В зависимости от объема работ по сопровождению должно быть принято решение о внесении тех или иных тем в конкретный план. Темы, подлежащие включению в план сопровождения:
1) описание сопровождаемой системы;
2) определение исходных состояний программного средства;
3) описание уровня требуемой поддержки;
4) определение организации, проводящей сопровождение;
5) описание любых условий (протоколов), согласованных между заказчиком и поставщиком;
b) концепция сопровождения:
1) описание концепции;
2) описание уровня поддержки системы;
3) установление периода поддержки;
4) адаптация (практическое применение) процесса сопровождения;
c) организационные работы и работы по сопровождению:
1) роли и обязанности сопроводителя до поставки программного продукта:
I) реализация процесса;
II) определение инфраструктуры процесса;
III) установление процесса обучения;
IV) установление процесса сопровождения;
2) роли и обязанности сопроводителя после поставки программного продукта:
I) реализация процесса;
II) анализы проблем и модификаций (изменений);
III) реализация (внесение) модификаций (изменений);
IV) рассмотрение и принятие модификаций (изменений);
V) перенос программного средства в новую среду;
VI) снятие программного средства с эксплуатации;
VII) решение проблем (включая справочную службу);
VIII) при необходимости - обучение персонала (сопроводителя и пользователя);
IX) усовершенствование процесса;
3) роль пользователя:
I) приемочные испытания;
II) взаимосвязи (интерфейсы) с другими организациями;
I) состав персонала для конкретного проекта;
2) программные средства:
I) определение программных средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);
3) технические средства:
I) определение технических средств, необходимых для поддержки эксплуатации системы (с учетом системных требований и требований к СПИ, СТПС и инструментальным средствам);
4) оборудование (аппаратура):
I) определение требований к оборудованию (аппаратуре) системы (помимо технических средств вычислительной техники);
I) план обеспечения качества;
II) план управления проектом;
III) план управления конфигурацией;
IV) документы разработки;
V) руководства по сопровождению;
VI) план проведения верификации;
VII) план проведения аттестации (валидации);
VIII) план тестирования, процедуры тестирования и отчеты о тестировании;
IX) план обучения;
X) руководство(а) пользователя;
7) другие требования к ресурсам (при необходимости);
e) процесс (как должна быть выполнена конкретная деятельность):
1) процесс, выполняемый сопроводителем (приводят общее описание процесса без детализации в плане сопровождения всего процесса);
2) процесс адаптации (практического применения сопровождения к условиям проекта);
1) определение уровня обучения, необходимого для сопроводителя и пользователей;
g) протоколы и отчеты по сопровождению:
1) перечень запросов пользователя на оказание услуг по сопровождению, предложение о модификациях или отчеты о проблемах;
2) состояния запросов (предложений, отчетов) по категориям;
3) приоритеты запросов (предложений, отчетов);
4) контрольные данные, собранные при работах по сопровождению.
7.4 Анализ ресурсов
Последним элементом стратегии сопровождения программного средства является анализ ресурсов. Сразу же после установления области сопровождения и организации, проводящей его, должны быть определены требования к персоналу сопровождения, среде сопровождения и финансовым ресурсам. Требования к ресурсам сопровождения программного средства обычно устанавливает заказчик при помощи поставщика (разработчика). При этом должны быть определены требования к ресурсам персонала сопровождения, среды и финансов.
7.4.1 Ресурсы персонала
Одной из главных частей планирования сопровождения программного средства является планирование требований к ресурсам сопровождения. Требования к персоналу являются основным фактором, определяющим стоимость сопровождения, но в то же время точная их оценка достаточно трудна. При оценке ресурсов для сопровождения программного средства обычно применяют два основных метода: параметрические модели и использование практических (опытных) знаний.
Для моделей требуются архивные практические данные. Лучшие результаты дает использование практических знаний при наличии соответствующих архивных опытных данных.
При этом предполагают, что для оценки сопровождения используют стандартную установленную методологию. Должно быть проведено отдельное исследование штатного состава персонала сопровождения на основе применения методологии определения ресурсов персонала и выдачи соответствующих результатов.
7.4.2 Ресурсы среды
При разработке и сопровождении программного средства проводят ряд специальных работ, для выполнения которых необходимы отдельные системы. Предполагают наличие отдельных сред программной инженерии (СПИ) и сред тестирования программного средства (СТПС). Сопроводитель должен помогать заказчику при создании плана для среды сопровождения. Данное требование является критичным при формировании среды сопровождения и должно быть учтено при предварительном планировании выделяемых фондов и финансовых средств для разработки и сопровождения программного продукта.
7.4.3 Финансовые ресурсы
Третьим и последним аспектом ресурсов являются финансовые ресурсы. Для обеспечения эффективного сопровождения программного продукта сопроводитель должен получить финансирование для:
- выплаты зарплаты персоналу;
- обучения персонала (2-3 недели в год на каждого человека);
- ежегодного возобновления лицензий на сопровождение программных средств;
Узбекское Агентство
Связи и Информатизации
Ташкентский Университет Информационных Технологий
Преподаватель дисциплины
Выдержки из лекций
Сопровождение программного обеспечения
Программные средства являются одним из наиболее гибких видов промышленных изделий и эпизодически подвергаются изменениям в течение всего времени их использования.
Иногда достаточно при корректировке программного обеспечения внести только одну ошибку для того, чтобы резко снизилась его надежность или его корректность при некоторых исходных данных.
Для сохранения и повышения качества программного обеспечения необходимо регламентировать процесс модификации и поддерживать его соответствующим тестированием и контролем качества. В результате программное изделие со временем обычно улучшается как по функциональным возможностям, так и по качеству решения отдельных задач.
Работы, обеспечивающие контроль и повышение качества, а также развитие функциональных возможностей программ, составляют процесс сопровождения.
В процессе сопровождения в программное обеспечение вносятся следующие изменения, значительно различающиеся причинами и характеристиками;
- исправление ошибок - корректировка программ, выдающих неправильные результаты в условиях, ограниченных техническим заданием и документацией. Исправление ошибок требуют около 20% общих затрат на сопровождение.
- регламентированная документами адаптация программного обеспечения к условиям конкретного использования, с учетом характеристик внешней среды или конфигурации аппаратуры, на которой предстоит функционировать программам. Адаптация занимает около 20% общих затрат на сопровождение.
- модернизация - расширение функциональных возможностей или улучшение характеристик решения отдельных задач в соответствии с новым или дополнительным техническим заданием на программное изделие. Модернизация занимает до 60% общих затрат на сопровождение.
Затраты на сопровождение программного обеспечения
Первый вид изменений (исправление ошибок) является непредсказуемым и его трудно регламентировать.
Остальные виды корректировок носят упорядоченный характер и проводятся в соответствии с заранее подготавливаемыми планами и документами. Эти корректировки в наибольшей степени изменяют программные изделия и требуют наибольших затрат.
Поэтому изменения, обусловленные ошибками, в большинстве случаев целесообразно по возможности накапливать и реализовывать их, приурочивая к изменениям, регламентированным модернизациями.
Однако некоторые ошибки вызывают необходимость срочного исправления программ. В этих случаях допустимо некоторое отставание корректировки документации при более срочном и регистрируемом исправлении самих программ.
Что делает сопровождение программного обеспечения крайне непривле кательным? Это плохо документированный код, недостаточно полное начальное проектирование и отсутствие внешней документации.
Если все этапы жизненного цикла разработки программного обеспечения выполнялись правильно, то сопровождение не будет вызывать серьезных проблем, а будет элементарной технической поддержкой и модификацией внедренного программного продукта.
Со временем, иногда через десятки лет, сопровождение программного обеспечения прекращается. Это может быть обусловлено: разработкой более совершенных программных средств; прекращением использования сопровождаемого программного продукта; нерентабельным возрастанием затрат на его сопровождение.
Отметим, однако, что программное изделие может долго применяться кем-либо и после прекращения его. сопровождения от лица разработчика, потому, что этот некто может плодотворно использовать программное изделие у себя самостоятельно, без помощи разработчика.
Для того чтобы со временем прийти к обоснованному решению о прекращении сопровождения программного обеспечения, необходимо периодически оценивать эффективность его эксплуатации, возможный ущерб от отмены сопровождения. В некоторых случаях решение о прекращении сопровождения принимается при противодействии со стороны отдельных пользователей.
Материал сайта является электронным пособием
по дисциплине "Технология Программирования"
в помощь студентам ТУИТ.
Читайте также: