5-software_engineering_maintenance (1133545), страница 4
Текст из файла (страница 4)
область знаний Software Testing, тему 2.2.6Регрессионное тестирование) системы или его компонент для проверки того, что внесенныеизменения для привели к непреднамеренному изменению поведения программного обеспечения.Вопрос состоит в том, что часто сложно найти время для необходимого тестирования. Не меньшейпроблемой является и координации в проведении тестов различными членами группысопровождения, занимающимеся решением различных задач.
Если же система выполняеткритичные <для бизнеса> функции, временный вывод системы из эксплуатации (как говорят,перевод системы в offline) для выполнения тестов часто оказывается просто невозможен.Таким образом, одним из ключевых вопросов сопровождения является организация работ потестированию модификаций эксплуатируемых систем, вплоть до предварительного планирования иразработки регламентов, в соответствии с которыми, например, основываясь на оценке критичностизапросов на изменения (как дефектов, так и важных расширений – будь то новая функциональностьили необходимое расширение интеграционных возможностей), затрагиваемых модулях, персоналомсопровождения будут проводиться стандартные процедуры.
К таким процедурам, наравне сжурналированием запросов и проводимых работ, могут и, скорее, должны относиться: анализвлияния <изменений> (impact analysis – см. ниже), оценка рисков, тестирование (различнымиметодами, в различном объеме), выпуск предварительных версий патчей/обновлений вограниченное использование (если это позволяет спецификация системы), использование “клона”системы (развертывание ее на идентичном оборудовании в идентичной конфигурации) и т.п.2.1.3 Анализ влияния (Impact analysis)Анализ влияния описывает как проводить (в частности, с точки зрения эффективности затрат)полный анализ возможных последствий и влияний изменений, вносимых в существующую систему.Персонал сопровождения должен обладать необходимыми знаниями о специфике системы (видеальном случае, иметь полное представление о системе на уровне ее разработчиков) – еесодержании и структуре.
Инженеры используют эти знания для выполнения работ по анализувлияния, идентифицируя все системы* и программные продукты, на которые могут повлиятьизменения, вносимые в обслуживаемую программную систему. При этом, должны быть определеныриски, связанные с внесением обсуждаемых изменений.* Как мы видим из описания данных работ в SWEBOK, речь идет не только о компонентах системы,но и о ее окружении, включая другие системы, функционирующие в том же операционном/системномокружении.Запросы на изменения** (change requests - CR), иногда упоминаемые как запросы на модификацию(modification request - MR), часто также называемые отчетами о проблемах (problem report - PR),должны анализироваться и трансформироваться в термины программной системы. Эти шагивыполняются после того, как соответствующий запрос на изменение начинает обрабатываться врамках процесса управления изменениями или, как принято называть, конфигурационногоуправления, и фиксируется в системе конфигурационного управления (см.
область знанийConfiguration Management).** Обычно запросы на изменения разделяют на две категории – “пожелания” (suggestions),относящиеся к расширению системы, и “отчеты об ошибках” (defect или bug report), направляемыепользователями в службу сопровождения или инженерами по тестированию разработчикам.Цели анализа влияния могут быть сформулированы следующим образом: Определение содержания изменений для задания работ по планированию и реализацииCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия. Сопровождение программного обеспечения.Получение максимально возможной оценки ресурсов, необходимых для проведениясоответствующих работАнализ стоимости и выгоды от внесения запрошенных изменений (обычно касаетсяпожеланий, запросов на расширение системы)Обсуждение сложности вопросов, связанных с внесением соответствующих измененийСложность решения вопроса, поставленного соответствующим запросом на изменения, частоявляется основным фактором определения того, когда и как будет решена проблема.
Инженерыидентифицирую компоненты, в которые необходимо внести изменения. Обычно рассматриваетсянесколько вариантов решения проблемы и вырабатывается (также, обязательно, фиксируются всоответствующей системе обработки запросов на изменения) наиболее оптимальный путь еерешения.При этом, оптимальность пути не всегда означает наиболее ”красивое” технологическое решение.Иногда это может быть временное решение, может быть даже нарушающее архитектурные шаблонысистемы, однако, обоснованное с точки зрения сроков и стоимости его реализации.
В то же самоевремя, результаты анализа направляются разработчикам системы, обычно работающим надследующей версией, для включения соответствующего изменения уже в рамках принятого стилякодирования, соглашений, архитектурных шаблонов и т.п. Безусловно, такой путь многим можетпоказаться просто неэтичным, с точки зрения “настоящего” инженерного подхода.
Однако, еслиразработчики готовят следующую версию системы, затрагивая модуль, модифицируемый службойсопровождения, с точки зрения бизнес-решений, “некрасивый”, но быстрый путь достижениятребуемого поведения системы, в большинстве случаев, будет выглядеть более обоснованным, чемпринятие на себя персоналом сопровождения функций разработчиков системы. Иногда, еслитребуемое изменение не столь критично, чтобы решение было предоставлено “вчера” (хотяпользователи, практически всегда, именно так характеризуют свои запросы в терминах приоритета),логичным выглядит откладывание проведения соответствующих модификаций и передача этихработ непосредственно разработчикам. Как это часто можно услышать – “будет доступно вследующем релизе”.
Ничего не напоминает? Но, экономически, это часто бывает более чемоправдано.Если программное обеспечение изначально разрабатывалось с учетом дальнейшей поддержки, этоможет существенно облегчить анализ влияний, как одной из ключевых работ по сопровождению.2.1.4 Возможность сопровождения (Maintainability)Возможность сопровождения или сопровождаемость программной системы определяется, например,глоссарием IEEE (стандарт 610.12-90 Standard Glossary for Software Engineering Terminology,обновление 2002 года) как легкость сопровождения, расширения, адаптации и корректировки дляудовлетворения заданных требований.
Стандарт ISO/IEC 9126-01 (Software Engineering – ProductQuality – Part 1: Quality Model, 2001 г.) определяет возможность сопровождения как одну изхарактеристик качества.Для уменьшения стоимости дальнейшего сопровождения, на протяжении всего процесса разработкинеобходимо специфицировать, оценивать и контролировать характеристики, влияющие навозможность сопровождения. Если такие работы проводятся регулярно, это облегчает дальнейшеесопровождение, повышая его сопровождаемость (в частности, как характеристику качества). Частоэтого сложно добиться, потому, что, к сожалению, такого рода характеристики игнорируются приразработки.
Разработчики заняты другими запланированными работами и также часто пренебрегаюттребованиями, предъявляемыми к сопровождаемости системы.Одной из ключевых проблем сопровождения является отсутствие системной документации,мешающее формированию понимания системы и, как следствие, невозможности адекватногоанализа влияния. Эта и другие проблемы могут быть решены при использовании систематическогоподхода к построению зрелых процессов, применению соответствующих техник и автоматизациинеобходимых задач по поддержке жизненного цикла с помощью специализированныхинструментальных средств.2.2 Управленческие вопросы (Management Issues)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия.
Сопровождение программного обеспечения.2.2.1 Согласование с организационными целями (Alignment with organizational objectivies)Организационные цели описывают как продемонстрировать возврат инвестиций от деятельности посопровождению программного обеспечения.
Обычно, разработка ведется на проектной основе, сопределенными временными и бюджетными ограничениями. Главный акцент, при этом, делается навыпуске системы, отвечающей потребностям пользователей, в заданные сроки и в рамках бюджета.В отличие от этого, сопровождение системы преследует цели максимального продления срокаэксплуатации программного обеспечения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
