ОПИ-2. Министерство науки и образования рф
 Скачать 1.52 Mb.
|
|
ТЕМА 8. СОПРОВОЖДЕНИЕ ПО Автор данного перевода SWEBOK с замечаниями и комментариями - Сергей Орлик. Оригинальный перевод доступен в блоге Сергея Орлика http://sorlik.blogspot.com/ Сопровождение программного обеспечения в SWEBOK определяется как вся совокупность деятельности, необходимой для обеспечения эффективной (с точки зрения затрат) поддержки программных систем. Эти работы выполняются как перед вводом системы в эксплуатацию, так и после этого. Предварительные работы включают планирование деятельности по сопровождению системы, а также организацию перехода к ее полнофункциональному использованию. Если новая система должна заменить старую систему, предназначенную для решения тех же задач, просто на новом уровне эффективности, стоимости использования, новых функциональных возможностей, в этом случае важно обеспечить плавный переход со старой системы на новую, максимально естественный для пользователей. С этим связано не только планирование, например, переноса информации, хранимой в соответствующих базах данных, но и обучение пользователей, подготовка, настройка и проверка “боевой” конфигурации, определение последовательности операций, организация и обучение службы поддержки (help-desk) и т.п. Область знаний “Сопровождение программного обеспечения” связана с другими аспектами программной инженерии. По сути, описание этой области знаний непосредственно пересекается со всеми другими дисциплинами. Определения и терминология (Definitions and Terminology) Сопровождение программного обеспечения определяется стандартом IEEE Standard for Software Maintenance (IEEE 1219) как модификация программного продукта после передачи в эксплуатацию для устранения сбоев, улучшения показателей производительности и/или других характеристик (атрибутов) продукта, или адаптации продукта для использования в модифицированном окружении. Интересно, что данный стандарт также касается вопросов подготовки к сопровождению до передачи системы в эксплуатацию, однако, структурно это сделано на уровне соответствующего информационного приложения, включенного в стандарт. В свою очередь, стандарт жизненного цикла 12207 (IEEE, ISO/IEC, ГОСТ Р ИСО/МЭК) позиционирует сопровождение как один из главных процессов жизненного цикла. Этот стандарт описывает сопровождение как процесс модификации программного продукта в части его кода и документации для решения возникающих проблем <при эксплуатации> или реализации потребностей в улучшениях <тех или иных характеристик продукта>. Задача состоит в модификации продукта при условии сохранения его целостности. Международный стандарт ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) определяет сопровождение программного обеспечения в тех же терминах, что и стандарт 12207, придавая особое значение работам по подготовке к деятельности по сопровождению до передачи системы в реальную эксплуатацию, например, вопросам планирования регламентов и операций по сопровождению. Природа сопровождения (Nature of Maintenance) Сопровождение поддерживает функционирование программного продукта на протяжении всего операционного жизненного цикла, то есть периода его эксплуатации. В процессе сопровождения фиксируются и отслеживаются запросы на модификацию (также называемые “запросами на изменения” – change requests, в частности, в контексте конфигурационного управления), оценивается влияние предлагаемых изменений, модифицируется код и другие активы (артефакты) продукта, проводится необходимое тестирование и, наконец, выпускается обновленная версия продукта. Кроме того, проводится обучение пользователей и обеспечивается их ежедневная поддержка при работе с текущей версией продукта. В SWEBOK отмечается, что сопровождение, с точки зрения операций отслеживания и контроля, обладает большим содержанием, чем разработка (в общем понимании). С точки зрения автора, объем и активность операций по контролю разработки в большой степени зависит от сложившихся практик, внутрикорпоративных регламентов и требований, а также применяемых методологий и концепции управления (в частности – проектного менеджмента). Так или иначе, отслеживание и контроль – ключевые элементы деятельности по сопровождению программного обеспечения (как и других ИТ-активов предприятия). Стандарт 12207 определяет понятие “maintainer” - в соответствующем ГОСТ он именуется как “персонал сопровождения”, подразумевая организацию, выполняющая работы по сопровождению. SWEBOK использует данный термин, также, и в отношении лиц (individuals), проводящих определенные работы по сопровождению, в отличие, например, от разработчиков, занимающихся реализацией системы в программном коде. Стандарт жизненного цикла 12207 также идентифицирует основные работы по сопровождению: реализация процесса <сопровождения>, анализ проблем и модификаций (изменений), реализаций модификаций, обзор (оценка)/принятие <решений> по сопровождению, миграция (с одной версии программного продукта на другую, с одного продукта на другой) и вывод системы из эксплуатации. Эти работы описываются далее в теме 3.2 “Работы по сопровождению” (Maintenance Activities). Специалисты по сопровождению (персонал сопровождения) могут получать знания о программном продукте непосредственно от разработчиков. Взаимодействие с разработчиками и раннее привлечение этих специалистов помогает уменьшить усилия, необходимые для адекватного сопровождения программной системы. По мнению автора, передача знаний персоналу сопровождения, его обучение, должно начинаться не позднее начала опытной эксплуатации продукта. В противном случае, усилия на одновременную поддержку прикладной системы и обучение соответствующих специалистов не только превысит реально допустимые нормы загрузки персонала (как группы или службы сопровождения и техподдержки, так и разработчиков системы), но снизит эффективность поддержки пользователей на критически важном этапе первоначального использования новой системы. По опыту автора и результатам обсуждения этого вопроса с сотрудниками внутрикорпоративных ИТ-департаментов, обычно, в зависимости от сложности системы, пик нагрузки на службу сопровождения приходится в течении первых 2 - 6 недель, с момента передачи системы в реальную эксплуатацию, тем более, при отказе от использования старой системы или ее предыдущей версии. SWEBOK отмечает, что, в некоторых случаях, инженеры (создававшие систему) не могут быть привлечены к обучению и поддержке персонала сопровождения. Особенно часто это касается тиражируемых или “коробочных” систем. Это создает дополнительные трудности для специалистов, обеспечивающих сопровождение. В то же время, инженеры, занимающиеся технической поддержкой (несколько боле узкий круг в команде сопровождения, включающей менеджеров, администраторов и других специалистов), должны (в зависимости от типа продукта) иметь доступ к активам проекта (например, описанию его внутренней архитектуры), включая код, документацию и т.п. Именно таким образом начинает формироваться информационная инфраструктура службы технической поддержки и сопровождения у производителей программных продуктов. Практика показывает, что инженеры по технической поддержке производителя программного обеспечения (не только “коробочного”, но и создаваемого и настраиваемого интеграторами, обладающими собственными программными решениями) должны не просто иметь доступ ко всем ключевым активам проекта (код, документация, спецификации требований, внутренние модели и т.п.), но в их обязанности входит создание “патчей” (patch – “заплата”), исправлений ошибок и, в особых случаях, такие изменения, до выпуска новой версии продукта, создаются с привлечением непосредственно разработчиков продукта (групп и подразделений R&D – Research and Development). При этом, разработчики продукта информируются о найденных ошибках и, в случае нахождения соответствующих решений специалистами технической поддержки, такие решения передаются разработчикам с тем, чтобы те либо включили такие изменения в новую версию программного продукта (безусловно, в случае успешного прохождения всех необходимых тестов), либо нашли более адекватное решение в контексте новой функциональности либо тех изменений, которые включены в новую версию продукта. В обязанности инженеров службы сопровождения, в общем случае, входит: проверка пользовательского сценария, приводящего к сбою; идентификация причин сбоя, т.е локализация ошибки/причин ее появления; предоставление соответствующих исправлений или, при невозможности создания таковых на данном этапе либо в заданные сроки – предоставление обходного пути решения проблемы для достижения требуемых бизнес-задач (такие обходные пути, обычно, называют “workaround”); журналирование всех работ и операций; помещение описания проблемы и ее решения в базу знаний службы сопровождения; передача всей информации разработчикам; своевременное информирование пользователя о статусе запроса и некоторые другие работы, содержание которых может варьироваться, в зависимости от регламентов и корпоративных стандартов в конкретной организации, либо параметров контракта на сопровождение и техническую поддержку, если таковой есть. Потребность в сопровождении (Need for Maintenance) Сопровождение необходимо для обеспечения того, чтобы программный продукт на протяжении всего периода эксплуатации удовлетворяет требованиям пользователей. Деятельность по сопровождению применима для программного обеспечения, созданного с использованием любой модели жизненного цикла и методологии разработки. На первый взгляд, это утверждение SWEBOK может показаться тривиальным. Однако, обратитесь к своему опыту разработки и использования различного программного обеспечения. Наверняка, Вы найдете случаи из собственной практики или практики коллег, когда столь очевидное утверждение хорошо бы донести до разработчика того или иного программного продукта. Изменения программной системы могут быть обусловлены как действиями по корректировке ее поведения или несвязанные с необходимостью корректировки (подразумевая уже не исправление ошибок, а, например, повышение производительности или расширение функциональности). В общем случае, работы по сопровождению должны проводиться для решения следующих задач: устранение сбоев; улучшение дизайна; реализация расширений (функциональных возможностей); создание интерфейсов взаимодействия с другими (внешними) системами; адаптация (например, портирование) для возможности работы на другой аппаратной платформе (или обновленной платформе), применения новых системных возможностей, функционирования в среде обновленной телекоммуникационной инфраструктуры и т.п.; миграции унаследованного (legacy) программного обеспечения; вывода программного обеспечения из эксплуатации. Деятельность персонала сопровождения включает четыре ключевых аспекта: поддержка контроля (управляемости) программного обеспечения в течение всего цикла эксплуатации: поддержка модификаций программных систем; совершенствование существующих функций; предотвращение падения производительности программной системы до неприемлемого уровня. Автор убежден, что говоря о предотвращении деградации производительности, мы должны понимать, что это, при всем желании совершенствования системы, может делаться и за счет обновления мощности аппаратной части и/или соответствующей телекоммуникационной инфраструктуры, если это более обосновано, чем модификация самой программной системы. На самом деле это вопрос того, что окажется дешевле (и менее рискованно), т.е. связано с затратами/ стоимостью соответствующих работ, оборудования и поддержки обновленного системного окружения (что, к сожалению, часто также не учитывается даже при более-менее сложившейся практике сопровождения). Приоритет стоимости сопровождения (Majority of Maintenance Costs) Работы по сопровождению потребляют если не большую (как отмечает SWEBOK), то значительную часть финансовых ресурсов жизненного цикла программного обеспечения. Общее понимание сопровождения подразумевает лишь устранение сбоев. Однако, исследования и опросы на протяжении многих лет показывают, что более 80% усилий по сопровождению связаны не столько устранением сбоев, сколько с другими работами, не связанными с исправлением дефектов. Многие менеджеры по сопровождению объединяют в отчетности вопросы расширения функциональности и исправления ошибок в поддерживаемых программных системах. Такое смешение качественно различных работ приводит к неправильному представлению о реальной, на самом деле, не столь высокой стоимости сопровождения в части устранения дефектов. Понимание различных категорий работ в рамках деятельности по сопровождению помогает понять структуру реальных затрат. Кроме того, понимание факторов, влияющих на возможности сопровождения системы, помогают не только сохранять необходимый уровень затрат, но и снижать их. Существуют как технические, так и другие (например, организационные, являющиеся, по мнению автора, наиболее сильно влияющими на объем затрат) факторы, оказывающие влияние на стоимость сопровождения, в целом: тип приложения; новизна программного обеспечения; наличие и квалификация персонала по сопровождению; длительность использования программной системы; характеристики и специфика аппаратной части (а также телекоммуникационной инфраструктуры); качество дизайна (например, модульность или масштабируемость), кода, документации и соответствующих работ по тестированию системы. Эволюция программного обеспечения (Evolution of Software) В 1969 году Леман (см. рекомендуемую литературу к данной секции SWEBOK) впервые связал деятельность по сопровождению и вопросы эволюции программного обеспечения. Результаты более чем 20-ти летних исследований во главе с Леманом привели к формулированию ряда важных положений, ключевое из которых утверждает, что деятельность по сопровождению, по-сути, представляет собой эволюционную разработку программных систем. Принятию тех или иных решений в процессе сопровождения, помогает понимание того, что происходит с программной системой в процессе ее эксплуатации. Существующее (особенно, корпоративное) программное обеспечение никогда не бывает полностью завершенным и продолжает эволюционировать в течение всего срока эксплуатации. В процессе эволюционирования, программная система становится все более сложной до тех пор, пока не предпринимаются специальные усилия (в том числе, в рамках специального проекта по модификации) по уменьшению его сложности. В то же самое время, если можно выделить тенденции развития программной системы и ее поведение достаточно стабильно, его эволюционирование можно измерить. Последние годы делаются попытки разработать соответствующие модели оценки усилий по сопровождению. В результате уже создаются определенные средства (численные и инструментальные) управления работами по сопровождению, ряд из которых приводится в ссылках к данной секции SWEBOK. Категории сопровождения (Categories of Maintenance) Многие источники, в частности, стандарт IEEE 1216, определяют три категории работ по сопровождению: корректировка, адаптация и совершенствование. Такая классификация была обновлена в стандарте ISO/IEC 14764 Standard for Software Engineering - Software Maintenance введением четвертой составляющей. Таким образом, сегодня говорят о четырех категориях сопровождения: Корректирующее сопровождение (corrective maintenance): “реактивная” модификация программного продукта, выполняемая уже после передачи в эксплуатацию для устранения сбоев; Адаптирующее сопровождение (adaptive maintenance): модификация программного продукта на этапе эксплуатации для обеспечения продолжения его использования с заданной эффективностью (с точки зрения удовлетворения потребностей пользователей) в изменившемся или находящемся в процессе изменения окружении; в первую очередь, подразумевается изменение бизнес-окружения, порождающее новые требования к системе; Совершенствующее сопровождение (perfective maintenance): модификация программного продукта на этапе эксплуатации для повышения характеристик производительности и удобства сопровождения; Профилактическое сопровождение (preventive maintenance): модификация программного продукта на этапе эксплуатации для идентификации и предотвращения скрытых дефектов до того, когда они приведут к реальным сбоям. ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) классифицирует адаптивное и совершенствующее сопровождение как работы по расширению (функциональности) продукта. Этот стандарт также объединяет корректирующую и профилактическую деятельность в общую категорию работ по корректировке системы. Профилактическое сопровождение (новейшая категория работ по сопровождению) наиболее часто проводится для программных систем, связанных с вопросами безопасности (людей). Таблица . Категории сопровождения программного обеспечения. КАЧЕСТВО ПРОГРАММНЫХ СРЕДСТВ В современном мире разработка ПО превратилась в одну аз самых дорогостоящих индустрии и любые узкие, места в технологическом процессе его создания могут привести к нежелательным результатам. Удлинение сроков разработки ПО чревато удорожанием конечного продукта, а не выявленные в ходе тестирования ошибки приводят как минимум к снижению его производительности. Примитивные ошибки, невнятные сообщения и неряшливый интерфейс раздражают пользователей, которые в итоге выбирают более качественный продукт конкурента, а фирма рискует потерять не только клиентов, но и свою долю рынка. Итак, качество ПО приобретает первостепенное значение. Но как оценить это самое качество и в чем его измерить? Можно ли создать "добротный" программный продукт, пользуясь убогими инструментальными средствами? Ответам на поставленные вопросы, а также описанию инструментария, позволяющего оценивать качество ПО, и посвящен следующий раздел курса. ОСНОВНЫЕ ПОНЯТИЯ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ Системы качества. Качество функционирования. Качество в использовании. Основные факторы качества. Имеется множество определений фундаментальной категории - качество, которые, по существу, сводятся к совокупности технических, технологических и эксплуатационных характеристик продукции или процессов, посредством которых они способны отвечать требованиям потребителя и удовлетворять его при применении. В соответствии со стандартами |