5-software_engineering_maintenance (1133545), страница 7
Текст из файла (страница 7)
выше 3.2.1) Планирование релизов/версий (уровень программного обеспечения) Планирование обработки конкретных запросов на изменение (уровень запроса)Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru16Основы программной инженерии (по SWEBOK)Программная инженерия. Сопровождение программного обеспечения.На уровне индивидуального запроса, работы по планированию проводятся вместе с проведениеманализа влияния (см. 2.1.3). В свою очередь, планирование релизов/версий требует от персоналасопровождения выполнения задач: Получения и сбора информации о датах размещения индивидуальных запросов и отчетов Достижения соглашения с пользователями о содержании (функциональности, поведении ит.п.) последующих релизов/версий программного обеспечения Идентификации потенциальных конфликтов и возможных альтернатив <реализациинеобходимых запросов> Оценки рисков для <функционирования> текущего релиза и разработки плана “отката” нанемодифицированный (текущий, до внесения изменений, касающихся рассматриваемогозапроса) вариант системы, в случае возникновения проблем, связанных с модификацией Информирования всех заинтересованных лицНесмотря на то, что разработка программных системы, обычно, занимает от несколько месяцев (чтоболее типично) до нескольких лет, сопровождение (как деятельность по поддержке использования) иактивная эксплуатация систем занимает несколько лет, а то и более* (5-10-...).
Проведение оценкиресурсов – неотъемлемая часть планирования. Ресурсы, необходимые для сопровождения должныбыть оценены и заложены в бюджет еще при разработке системы. Планирование работ посопровождению должно начинаться одновременно с принятием решения о создании системы исогласоваться с целями обеспечения качества (отмечается в IEEE 1061-98 Standard for a SoftwareQuality Metrics Methodology).* эта оценка согласуется и с опытом Сергея Орлика, когда в начале 90-х он принималнепосредственное участие в проектировании и разработке системы автоматизации добровольногомедицинского страхования (в одной из крупнейших российских страховых компаний), выведенной, вдальнейшем, из эксплуатации на рубеже 2000 года, то есть система функционировала около 7 лет, анекоторые ее фрагменты как самостоятельные приложения и того дольше.
Многие банковскиеприложения, особенно, на западе, в первых своих версиях были разработаны еще в середине 80-х, анекоторые ИТ-системы в мире были созданы (в своем изначальном варианте) и в 70-е годы, что, вчастности, привело к усиленному вниманию к проблеме 2000 года (Y2K problem).Вначале необходимо определить концепцию сопровождения. Такой документ, например, постандарту ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance) должен касатьсяследующих вопросов: Содержания деятельности по сопровождению Адаптации процесса сопровождения Идентификации организации, которая будет заниматься сопровождением Оценки стоимости сопровожденияПосле разработки концепции деятельности по сопровождению должен быть сформировансоответствующий план сопровождения. Этот план должен подготавливаться одновременно сразработкой программной системы.
План должен определять как пользователи будут размещатьсвои запросы на модификацию (изменения) или сообщать об ошибках, сбоях и проблемах. Вопросампланирования уделяют специальное внимание уже упоминавшиеся стандарты IEEE 1219 (Standardfor Software Maintenance) и ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance).Стандарт ISO/IEC 14764 предоставляет специальные рекомендации (guidelines) по организацииплана сопровождения.Наконец, на уровне бизнес-вопросов, структура, отвечающая за сопровождение, должна проводитьобщую деятельность по бизнес-планированию, касающееся бюджетирования, финансовогоменеджмента и управления человеческими ресурсами, так же, как и любое другое (в том числе,профильное, если речь идет о потребителях ИТ) подразделение организации/компании.Необходимые знание в области управления также затрагиваются в области знаний SWEBOK“Связанные дисциплины”.3.2.4 Конфигурационное управление (Software configuration management)Стандарт IEEE 1219, посвященный организации сопровождения программного обеспечения,определяет конфигурационное управление как критически важный элемент процессаCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru17Основы программной инженерии (по SWEBOK)Программная инженерия.
Сопровождение программного обеспечения.сопровождения. Процедуры конфигурационного управления должны обеспечивать проверку,аттестацию и аудит на всех шагах, требуемых для идентификации, авторизации, реализации ивыпуска программного продукта.Более того, недостаточно просто отслеживать запросы на изменения и сообщения о проблемах(modification requests, problem reports).
Должны быть контролируемы и сам программный продукт, илюбые изменения (не только в коде, но документации, спецификациях и т.п., то есть любых активахпродукта и проекта, прим. автора). Такой контроль устанавливается реализацией и строгимследованием утвержденным процессам конфигурационного управления (software configurationmanagement, SCM). Область знаний “Конфигурационное управление” подробно описывает иобсуждает процессы, в соответствии с которыми, размещаются, оцениваются и утверждаютсязапросы на изменения. В ряде отдельных аспектов и характеристик, конфигурационное управлениепри сопровождении и разработке несколько отличается, что должно контролироваться уже наоперационном уровне.
Реализация SCM-процесса обеспечивается разработкой и следованиемплану конфигурационного управления и соответствующим процедурам (operating procedures).Организация, подразделение или группа сопровождения (в лице представителей) участвует в работечасто формируемого органа Configuration Control Board, отвечающего за рассмотрение и принятие вработу запросов на изменения. Основной целью такого участия является, по мнению SWEBOK,определение содержания следующих релизов/версий.3.2.5 Качество программного обеспечения (Software quality)Недостаточно, всего лишь, надеяться, что в процессе и результате сопровождения, качествопрограммного обеспечения будет повышаться.
Для поддержки процесса сопровождения должныпланироваться и реализовываться соответствующие процедуры и процессы, направленные наповышение качества. Работы и техники по обеспечению качества (Software Quality Assurance, SQA),проверке и аттестации (V&V, verification and validation), обзору, анализу и оценке (review), а такжеаудиту, должны отбираться в контексте взаимодействия и согласования со всеми другимипроцессами, направленными на достижение желаемого уровня качества.
SWEBOK, основываясь настандарте ISO/IEC 14764 (Standard for Software Engineering - Software Maintenance), рекомендуетадаптировать соответствующие процессы, техники и активы, относящиеся к разработкепрограммного обеспечения. К ним, например, относятся документация по тестированию ирезультаты тестов. Дополнительные подробности можно найти в соответствующей области знаний“Качество программного обеспечения” (Software Quality).4.
Техники сопровождения (Techniques for Maintenance)Данная секция вводит некоторые общепринятые техники, используемые в процессе сопровожденияпрограммных систем.4.1 Понимание программных систем (Program Comprehension)Для реализации изменений программисты тратят значительную часть времени на чтение иформирование понимания программного продукта. Средства работы с кодом являются ключевыминструментом для решения этой задачи.
Четкая, однозначная и лаконичная документацияобеспечивает адекватное понимание программных систем.4.2 Реинжиниринг* (Reengineering)Реинжиниринг определяется как детальная оценка (examination) и перестройка программногообеспечения для формирования понимания, воссоздания (на уровне модели и, в ряде случаев,требований) и дальнейшей реализации его <функций> в новой форме (например, с использованиемновых технологий и платформ, при сохранении существующей и расширением и облегчениемвозможностей добавлений новой функциональности). Отмечается, что в индустрии существуютразличные позиции в отношении реинжиниринга – одни считают, что реинжиниринг являетсянаиболее радикальной и затратной формой изменений программных систем, другие, что такойподход может применяться и для не столь кардинальных изменений (например, как сменаплатформы или архитектуры).
Реинжиниринг, обычно, провидится не столько для улучшениявозможностей сопровождения (maintainability), сколько для замены устаревшего программногообеспечения. В принципе, реинжиниринг можно рассматривать как самостоятельный проект,Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru18Основы программной инженерии (по SWEBOK)Программная инженерия. Сопровождение программного обеспечения.включающий в себя, как отмечает SWEBOK, формирование концепции, применениесоответствующих инструментов и техник, анализ и приложения опыта проведения реинжиниринга, атакже оценку рисков и преимуществ, связанных с такими работами.Необходимо отметить, что реализация продукта в новом качестве (форме) при сохранении основнойфункциональности оригинального продукта, является неотъемлемой и определяющей частьюреинжиниринга, в отличие от обратного инжиниринга, рассматриваемого ниже и являющегосяважной составной частью реинжиниринга.4.3 Обратный инжиниринг* (Reverse engineering)“Обратный” инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) илиэто процесс анализа программного обеспечения с целью идентификации программных компонент исвязей между ними, а также формирования представления о программном обеспечении, сдальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
