Сопровождение программного обеспечения после разработки: Что дальше?

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

Что такое сопровождение программного обеспечения?

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

4 различных типа сопровождения программного обеспечения

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

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

Переход проекта из стадии разработки в стадию сопровождения

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

• Выбор надежных руководителей - Руководители проектных групп, такие как руководители разработки, бизнес-аналитики и другие заинтересованные стороны, поддерживают связь с руководителями групп сопровождения. Знание того, к кому можно обратиться за советом и принятием решения, может снизить риски и способствовать плавному переходу. Руководители групп должны обсуждать, как новое программное приложение повлияет на текущие соглашения об уровне обслуживания (SLA) или изменит их.
• Подготовить бюджет на переход - Компании должны помнить о необходимости составления бюджета на переход от разработки к сопровождению в рамках проекта. С этим не следует спешить или упускать из виду. Компания должна убедиться в том, что все заинтересованные стороны осознают необходимость разработки надежной стратегии поддержки. Этот бюджет может также покрыть потребность в дополнительных сотрудниках после завершения внедрения.
• Начинать заблаговременно - при передаче проектов из разработки в сопровождение следует избегать "метода "бросил и убежал". Компании Dev должны позволять группам сопровождения следить за работой групп разработки задолго до того, как они завершат выполнение задачи, привлекать их к участию в совещаниях и важных коммуникациях, а также информировать всех о важных решениях. Команды разработчиков будут лучше понимать текущее состояние существующей архитектуры и смогут принимать более взвешенные решения, если члены групп сопровождения будут использовать программные приложения, которые присутствуют с самого начала.
• Коммуникация - компании должны помнить, что сотрудники отдела технического обслуживания могут не до конца понимать, почему они принимают определенные решения, имеют определенные приоритеты или придерживаются определенных ожиданий. Обслуживающий персонал может лучше поддерживать программное обеспечение и проявлять сочувствие и ответственность при ответах на будущие вопросы конечных пользователей, сообщая им такие подробности.
• Документация - Процедура поддержки в значительной степени опирается на документацию. Для того чтобы направлять будущие работы по поддержке, квалифицированные технологические специалисты учатся предвидеть особенности документирования. Они должны учитывать пожелания конечных пользователей, которые могут искать обоснования для создания тех или иных функций или возможностей, а также обоснование принятых решений.

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

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

Передача знаний

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