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

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

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

• Требования к клиенту. Со временем клиент может запросить новые функции или функции в программном обеспечении.

• Модификации хоста. Если изменяется какое-либо оборудование и / или платформа (например, операционная система) целевого хоста, то для сохранения адаптивности необходимы изменения программного обеспечения.

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

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

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

Модификации хоста. Если изменяется какое-либо оборудование и / или платформа (например, операционная система) целевого хоста, то для сохранения адаптивности необходимы изменения программного обеспечения.

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

Типы обслуживания

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Деятельность по обслуживанию

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

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

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

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

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

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

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

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

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

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

• Управление техническим обслуживанием. Управление конфигурацией является неотъемлемой частью технического обслуживания системы. Это помогает инструментам контроля версий управлять версиями, полу-версиями или исправлениями.

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

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

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

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

Системное тестирование — Интеграционное тестирование проводится среди вновь созданных модулей. Интеграционное тестирование также проводится между новыми модулями и системой. Наконец, система тестируется в целом, следуя процедурам регрессивного тестирования.

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

Доставка — после приемочного тестирования система развертывается по всей организации с помощью небольшого пакета обновлений или новой установки системы. Окончательное тестирование проводится на стороне клиента после доставки программного обеспечения.

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

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

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

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

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

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

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

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

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

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

Обратный инжиниринг

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

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

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

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

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

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

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

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

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

Повторное использование компонентов

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

пример

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

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

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

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

Существует совершенно новая вертикаль, которая основана на повторном использовании программного компонента и известна как компонентная разработка программного обеспечения (CBSE).

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

• Уровень приложения — когда все приложение используется в качестве подсистемы нового программного обеспечения.

• Уровень компонента — где используется подсистема приложения.

• Уровень модулей — где функциональные модули используются повторно.

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

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

Уровень компонента — где используется подсистема приложения.

Уровень модулей — где функциональные модули используются повторно.

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

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

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

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

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

Укажите компоненты. Изучая дизайн программного обеспечения, разработчики разделяют всю систему на более мелкие компоненты или подсистемы. Один полный дизайн программного обеспечения превращается в набор огромного набора компонентов, работающих вместе.

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

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