5-software_engineering_maintenance (1133545), страница 3

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

Текст из файла (страница 3)

Такое смешение качественноразличных работ приводит к неправильному представлению о реальной, на самом деле, не стольвысокой стоимости сопровождения в части устранения дефектов. Понимание различных категорийработ в рамках деятельности по сопровождению помогает понять структуру реальных затрат. Крометого, понимание факторов, влияющих на возможности сопровождения системы, помогают не толькосохранять необходимый уровень затрат, но и снижать их.Существуют как технические, так и другие (например, организационные, являющиеся, по мнениюавтора, наиболее сильно влияющими на объем затрат) факторы, оказывающие влияние настоимость сопровождения, в целом: тип приложения новизна программного обеспечения наличие и квалификация персонала по сопровождению длительность использования программной системы характеристики и специфика аппаратной части (а также телекоммуникационнойинфраструктуры) качество дизайна (например, модульность или масштабируемость), кода, документации исоответствующих работ по тестированию системыCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru6Основы программной инженерии (по SWEBOK)Программная инженерия.

Сопровождение программного обеспечения.1.5 Эволюция программного обеспечения (Evolution of Software)В 1969 году Леман (см. рекомендуемую литературу к данной секции SWEBOK) впервые связалдеятельность по сопровождению и вопросы эволюции программного обеспечения. Результаты болеечем 20-ти летних исследований во главе с Леманом привели к формулированию ряда важныхположений, ключевое из которых утверждает, что деятельность по сопровождению, по-сути,представляет собой эволюционную разработку программных систем. Принятию тех или иныхрешений в процессе сопровождения, помогает понимание того, что происходит с программнойсистемой в процессе ее эксплуатации.

Существующее (особенно, корпоративное) программноеобеспечение никогда не бывает полностью завершенным и продолжает эволюционировать втечение всего срока эксплуатации. В процессе эволюционирования, программная системастановится все более сложной до тех пор, пока не предпринимаются специальные усилия (в томчисле, в рамках специального проекта по модификации) по уменьшению его сложности.В то же самое время, если можно выделить тенденции развития программной системы и ееповедение достаточно стабильно, его эволюционирование можно измерить. Последние годыделаются попытки разработать соответствующие модели оценки усилий по сопровождению. Врезультате уже создаются определенные средства (численные и инструментальные) управленияработами по сопровождению, ряд из которых приводится в ссылках к данной секции SWEBOK.1.6 Категории сопровождения (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) классифицирует адаптивноеи совершенствующее сопровождение как работы по расширению <функциональности> продукта.Этот стандарт также объединяет корректирующую и профилактическую деятельность в общуюкатегорию работ по корректировке системы.

Профилактическое сопровождение (новейшая категорияработ по сопровождению) наиболее часто проводится для программных систем, связанных свопросами безопасности <людей>.“Проактивный” подход“Реактивный” подходКорректирующие работыПрофилактическоесопровождениеКорректирующеесопровождениеРаботы по расширениюСовершенствующеесопровождениеАдаптирующеесопровождениеТаблица 1. Категории сопровождения программного обеспечения.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия. Сопровождение программного обеспечения.2.

Ключевые вопросы сопровождения программного обеспечения (Key Issues in SoftwareMaintenance)Для обеспечения эффективного сопровождения программных систем необходимо решать целыйкомплекс вопросов и проблем, связанных с соответствующими работами. Необходимо понимать, чтопроцесс сопровождения предъявляет уникальные технические и управленческие требования кперсоналу, занимающемуся сопровождениям и, в первую очередь, специалистам-инженерам.Попытка найти дефект в продукте, содержащем 500 тысяч строк кода, написанных другимиинженерами – яркий пример сложностей, с которыми приходится сталкиваться инженерам посопровождению. Другой пример, уже организационный, постоянная борьба за ресурсы сразработчиками (это чаще всего проявляется в вопросах отвлечения разработчиков от текущейработы для помощи в решении проблем сопровождения, а также в конкуренции за приоритетыфинансирование разработки новой системы или сопровождения существующей).

Одновременноепланирование перспективной версии системы, реализация следующей версии и подготовкакритических патчей для текущей версии – еще один классический пример проблем, с которымиприходится сталкиваться в процессе эксплуатации программного обеспечения.Данная секция представляет некоторые технические и управленческие вопросы, связанные ссопровождением программных систем. Эти вопросы и проблемы сгруппированы в набор тем: Технические вопросы Управленческие вопросы Оценка стоимости Измерения2.1 Технические вопросы (Technical Issues)2.1.1 Ограниченное понимание (Limited understanding)Ограниченное понимание подразумевает как быстро инженер по сопровождению может понять гденеобходимо внести исправления или изменения в код системы, которую он не разрабатывал.Исследования показывают, что от 40 до 60 процентов усилий по сопровождению тратится на анализи понимание сопровождаемого программного обеспечения.

Формирование целостного взгляда осистеме представляет большое значение для инженеров. Этот процесс более сложен в случаеанализа текстового представления системы – ее исходного кода, особенно, когда процесс эволюциисистемы от сборки к сборки, от релиза к релизу, в нем никак не отмечен, не документирован и когдаразработчики не могут объяснить историю и структуру изменений, что, к сожалению, случаетсядостаточно часто.Для объектно-ориентированных программ качественно упрощает задачу понимания кодаиспользование UML-инструментария, способного на основе кода восстановить не только модельклассов, но и их взаимодействия в форме диаграмм классов (class diagram), коммуникаций илисотрудничества (collaboration в UML1.x, переименованная в communication в UML 2.0) и, особенно,последовательностей (sequence diagram), демонстрирующая структуру взаимных вызовов вовремени.

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

Если к этому добавить документированность (и доступность соответствующихактивов –спецификаций, моделей) архитектуры и ключевых технологических решений со стороныразработчиков системы – обсуждаемый вопрос, конечно, не становится тривиальным, однако,превращается во вполне решаемую задачу. Вообще говоря, использование соответствующихсредств автоматизации построения моделей по коду (задача обратного инжиниринга – reverseengineering) является обоснованной практикой изучения любой системы или фреймворка. Опытпоказывает, что при достаточной квалификации инженера, формирование общего архитектурногопредставления о системе (или фреймворке), понимания того, какие технологические и структурныеподходы и шаблоны использовались при ее построении, позволяет решать возникающие вопросыкорректировки кода и расширения функциональности системы, не нарушая общие принципы ееCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия.

Сопровождение программного обеспечения.построения, естественным образом обеспечивая ее эволюцию, без ущерба ее целостности. Притаком понимании, даже не заглядывая в код системы или фреймворка, инженер способен с оченьбольшой вероятностью предположить возможные причины сбоя, а, в общем случае, и любыхаспектов поведения системы. Тема обратного инжиниринга освещается SWEBOK каксамостоятельная техника сопровождения (4.3), однако, здесь показалось важным особоакцентировать на ней внимание именно в этой части обсуждения вопросов сопровождения.2.1.2 Тестирование (Testing)Стоимость повторения полного набора тестов для основных модулей системы может бытьсущественным как по времени, так и по стоимости. Для сопровождения системы особо значимымявляется выборочное регрессионное тестирование (см.

Характеристики

Список файлов книги