Обзор обслуживания программного обеспечения

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

Market Conditions - Политики, которые меняются с течением времени, такие как налогообложение и недавно введенные ограничения, такие как порядок ведения бухгалтерского учета, могут вызвать необходимость изменения.
Client Requirements - Со временем покупатель может запросить новые функции или возможности в программном обеспечении.
Host Modifications - Если какое-либо оборудование и / или платформа (например, операционная система) целевого хоста изменяются, необходимо внести изменения в программное обеспечение для сохранения адаптируемости.
Organization Changes - Если на стороне клиента происходит какое-либо изменение бизнес-уровня, такое как уменьшение силы организации, приобретение другой компании, организация, выходящая на новый бизнес, может возникнуть необходимость изменения исходного программного обеспечения.

Виды обслуживания

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

Corrective Maintenance - Сюда входят модификации и обновления, сделанные для исправления или исправления проблем, которые либо обнаруживаются пользователем, либо выводятся из отчетов об ошибках пользователя.
Adaptive Maintenance - Сюда входят модификации и обновления, применяемые для обеспечения актуальности программного продукта и адаптации к постоянно меняющимся технологиям и бизнес-среде.
Perfective Maintenance- Сюда входят модификации и обновления, сделанные для того, чтобы программное обеспечение можно было использовать в течение длительного периода времени. Он включает в себя новые функции, новые требования пользователей для улучшения программного обеспечения и повышения его надежности и производительности.
Preventive Maintenance- Сюда входят модификации и обновления для предотвращения будущих проблем с программным обеспечением. Он направлен на устранение проблем, которые на данный момент не являются существенными, но могут вызвать серьезные проблемы в будущем.

Стоимость обслуживания

Отчеты показывают, что стоимость обслуживания высока. Исследование по оценке обслуживания программного обеспечения показало, что стоимость обслуживания достигает 67% от стоимости всего цикла процесса программного обеспечения.

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

Факторы реального мира, влияющие на стоимость обслуживания

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

Конечные факторы программного обеспечения, влияющие на стоимость обслуживания

Структура программного обеспечения
Язык программирования
Зависимость от внешней среды
Надежность и доступность персонала

Мероприятия по техническому обслуживанию

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

Эти действия идут рука об руку с каждым из следующих этапов:

Identification & Tracing- Это включает в себя действия, относящиеся к идентификации требований модификации или обслуживания. Он создается пользователем, или система может сама сообщать через журналы или сообщения об ошибках. Здесь также классифицируется тип обслуживания.
Analysis- Модификация анализируется на предмет ее влияния на систему, включая последствия для безопасности. Если вероятное воздействие будет серьезным, ищется альтернативное решение. Затем набор необходимых модификаций материализуется в спецификации требований. Стоимость модификации / обслуживания анализируется и делается оценка.
Design- Новые модули, которые необходимо заменить или изменить, разработаны в соответствии со спецификациями требований, установленными на предыдущем этапе. Тестовые случаи созданы для проверки и проверки.
Implementation - Новые модули кодируются с помощью структурированного дизайна, созданного на этапе проектирования. Ожидается, что каждый программист будет проводить модульное тестирование параллельно.
System Testing- Интеграционное тестирование выполняется среди вновь созданных модулей. Также проводится интеграционное тестирование между новыми модулями и системой. Наконец, система тестируется в целом после процедур регрессионного тестирования.
Acceptance Testing- После внутреннего тестирования системы она проверяется на приемлемость с помощью пользователей. Если в этом состоянии пользователь жалуется на некоторые проблемы, которые он решит или планирует решить в следующей итерации.
Delivery- После приемочного испытания система развертывается по всей организации либо с помощью небольшого пакета обновлений, либо с помощью новой установки системы. Окончательное тестирование проводится на стороне клиента после доставки программного обеспечения.

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

Реинжиниринг программного обеспечения

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

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

Например, изначально Unix разрабатывался на ассемблере. Когда появился язык C, Unix была переработана на C, потому что работать на языке ассемблера было сложно.

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

Процесс реинжиниринга

Decideчто перепроектировать. Это все программное обеспечение или его часть?
Perform Обратный инжиниринг, чтобы получить спецификации существующего программного обеспечения.
Restructure Programесли необходимо. Например, преобразование функционально-ориентированных программ в объектно-ориентированные программы.
Re-structure data как требуется.
Apply Forward engineering концепции, чтобы получить переработанное программное обеспечение.

В реинжиниринге программного обеспечения используется несколько важных терминов.

Разобрать механизм с целью понять, как это работает

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

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

Реструктуризация программы

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

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

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

Форвард Инжиниринг

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

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

Возможность многократного использования компонентов

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

пример

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

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

В ООП объекты разрабатываются с учетом их специфики и имеют меньше шансов быть использованы в каком-либо другом программном обеспечении.

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

Возникла совершенно новая вертикаль, основанная на повторном использовании программных компонентов, известная как Component Based Software Engineering (CBSE).

Повторное использование может быть выполнено на разных уровнях

Application level - Когда все приложение используется как подсистема нового программного обеспечения.
Component level - Где используется подсистема приложения.
Modules level - Где повторно используются функциональные модули.

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

Процесс повторного использования

Могут быть применены два метода: либо поддержание требований одинаковыми и корректировка компонентов, либо сохранение компонентов одинаковыми и изменение требований.

Requirement Specification - Определяются функциональные и нефункциональные требования, которым должен соответствовать программный продукт, с помощью существующей системы, пользовательского ввода или того и другого.
Design- Это также стандартный этап процесса SDLC, где требования определяются на языке программного обеспечения. Создана базовая архитектура системы в целом и ее подсистем.
Specify Components - Изучая дизайн программного обеспечения, разработчики разделяют всю систему на более мелкие компоненты или подсистемы. Один законченный проект программного обеспечения превращается в совокупность огромного набора компонентов, работающих вместе.
Search Suitable Components - Репозиторий программных компонентов направляется разработчиками для поиска подходящего компонента на основе функциональности и предполагаемых требований к программному обеспечению.
Incorporate Components - Все согласованные компоненты упакованы вместе, чтобы сформировать их как законченное программное обеспечение.