Уникальные работы (Unique activities)

Согласно [25] имеются следующие процессы, работы и практики, уникальные для деятельности по сопровождению:

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

- Принятие/отклонение запросов на модификацию (Modification Request Acceptance/Rejection) – деятельность по принятию решений о приёме и передаче в работу запросов на изменения, либо отклонении их. Такие решения могут приниматься на основе приоритетности, оценке обоснованности, отсутствии ресурсов, наличия утвержденного плана по реализации в следующей версии и т.п.

- Средства извещения персонала сопровождения и отслеживания статуса запросов на модификацию и отчетов об ошибках (Modification Request and Problem Report Help Desk) – функция поддержки конечных пользователей, инициирующая работы по оценке, анализу приоритетности и стоимости модификаций, связанных с поступившим запросом или сообщенной проблемой.

- Анализ влияния (Impact Analysis) – анализ возможных последствий изменений, вносимых в существующую систему.

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

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

Дополнительные работы, поддерживающие процесс сопровождения (Support activities)

Такие работы включают:

- планирование сопровождения;

- конфигурационное управление;

- проверка и аттестация;

- оценка качества программного обеспечения;

- различные аспекты обзора, анализа и оценки;

- аудит;

- обучение пользователей;

- обучение персонала сопровождения.

Рассмотрим подробнее каждую из этих работ:

1 Работы по планированию сопровождения

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

- Бизнес-планирование (организационный уровень).

- Планирование непосредственных работ по сопровождению.

- Планирование релизов/версий (уровень программного обеспечения).

- Планирование обработки конкретных запросов на изменение (уровень запроса).

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

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

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

- Идентификации потенциальных конфликтов и возможных альтернатив.

- Оценки рисков для функционирования текущего релиза и разработки плана «отката» на немодифицированный вариант системы, в случае возникновения проблем, связанных с модификацией.

- Информирования всех заинтересованных лиц.

Оценка ресурсов – важная неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должны быть заложены в бюджет еще при разработке системы. Планирование работ по сопровождению должно начинаться одновременно с принятием решения о создании системы и согласоваться с целями обеспечения качества (IEEE 1061-98 Standard for a Software Quality Metrics Methodology).

Началом работ по сопровождению должна явиться концепция сопровождения. Согласно стандарту ISO/IEC 14764 [10] она должна включать:

- содержания деятельности по сопровождению;

- адаптации процесса сопровождения;

- идентификации организации, которая будет заниматься сопровождением;

- оценки стоимости сопровождения.

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

На уровне бизнес-вопросов, структура, отвечающая за сопровождение, должна проводить общую деятельность по бизнес-планированию, касающееся бюджетирования, финансового менеджмента и управления человеческими ресурсами, так же, как и любое другое (в том числе, профильное, если речь идет о потребителях ИТ) подразделение организации/компании.

2) Конфигурационное управление (Software configuration management)

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

3) Качество программного обеспечения (Software quality)

Для поддержки процесса сопровождения должны планироваться и реализовываться соответствующие процедуры и процессы, направленные на повышение качества. Работы и техники по обеспечению качества (Software Quality Assurance, SQA), проверке и аттестации (V& V, verification and validation), обзору, анализу и оценке (review), а также аудиту, должны отбираться в контексте взаимодействия и согласования со всеми другими процессами, направленными на достижение желаемого уровня качества. Отдельно качество программного обеспечения рассмотрено в главе 4.

Методы сопровождения

Рассмотрим два наиболее распространённых методах сопровождения, применяемые сегодня на практике.

Реинжиниринг

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

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

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

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

- создание новой документации на существующую систему;

- восстановление дизайна системы и т.п.

К вопросам обратного инжиниринга, как и к вопросам реинжиниринга, также относятся работы по рефакторингу [41].

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

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

Конфигурационное управление

Работы по конфигурационному управлению программного обеспечения включают: управление и планирование процессов управления конфигурацией ПО (SCM), идентификацию программных конфигураций, контроль конфигураций, учет статусов конфигураций, аудит, а также управление выпуском (release management) и поставкой (delivery).

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

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

⇐ Предыдущая78910111213141516Следующая ⇒

Поделиться:

Популярное:

1. Самородные и уникальные элементы.