VII Международная студенческая научная конференция Студенческий научный форум - 2015

Сопровождение всегда признавалось одним из основных этапов жизненного цикла программного обеспечения. Уже к середине 70-х годов было признано, что сопровождение – это этап, занимающий более 50% затрат на разработку и внедрение программного средства (ПС).

От эффективности работ на этапе поддержки и сопровождения зависит непрерывность бизнес-процессов и сохранность корпоративной информации, необходимой для жизнедеятельности компаний.

Для сложных программных систем, предполагающих длительное применение и сопровождение множества версий, существует острая необходимость в регламентировании их жизненно

Инструменты сопровождения существующего программного обеспечения, согласно SWEBOK можно поделить две категории:

– инструменты облегчения понимания (демонстрации), служащие для помощи в понимании человеком программ, например, различные средства визуализации;

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

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

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

Обратный инжиниринг (часто путаемый с реинжинирингом, в том числе, в понимании SWEBOK) или это процесс анализа программного обеспечения с целью идентификации программных компонент и связей между ними, а также формирования представления о программном обеспечении, с дальнейшей перестройкой в новой форме (уже, в процессе реинжиниринга). Обратный инжиниринг является пассивным, предполагая отсутствие деятельности по изменению или созданию нового программного обеспечения. Обычно, в результате усилий по обратному инжинирингу создаются модели вызовов (call graphs) и потоков управления (control flow graphs) на основе исходного кода системы. Один из типов обратного инжиниринга – создание новой документации на существующую систему (redocumentation). Другой из распространенных типов – восстановление дизайна системы (design recovery).

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

Формы и данные измерений в процессе сопровождения могут объединяться в единую программу - корпоративную программу количественных оценок, проводимых в отношении программного обеспечения. Многие организации используют популярный и практичный подход для измерений, базирующийся на оценке количества проблем и статуса их решений (issue-driven measurement). Идеи этого подхода систематизированы в проекте Practical Software and Systems Measurement (PSM). Существуют общие (для всего жизненного цикла) метрики и, соответственно, их категории, в частности, определяемые Институтом Программной Инженерии университета Карнеги-Меллон (Software Engineering Institute, Carnegie-Mellon University – SEI CMU): размер, усилия, расписание и качество. Применение этих метрик является хорошей отправной точкой для оценки работ со стороны организации, отвечающей за сопровождение.

Более детальное обсуждение вопросов измерений в отношении продуктов и процессов представлено в области знаний «Процесс программной инженерии» (Software Engineering Process). В свою очередь, вопросы организации программы измерений относятся к области знаний «Управление программной инженерией (Software Engineering Management).

Существуют различные методы внутренней оценки продуктивности (benchmarking) персонала сопровождения для сравнения работы различных групп сопровождения. Организация, ведущая сопровождение, должна определить метрики, по которым будут оцениваться соответствующие работы. Стандарты IEEE 1219 (Standard for Software Maintenance) и ISO/IEC 9126-01 (Software Engineering – Product Quality – Part 1: Quality Model, 2001г.) предлагают специализированные метрики, ориентированные именно на вопросы сопровождения и соответствующие программы.

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

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

Изменяемость (Changeability): оценка усилий, необходимых для проведения заданных модификаций.

Стабильность (Stability): оценка случаев непредусмотренного поведения системы, включая ситуации, обнаруженные в процессе тестирования.

Тестируемость (Testability): оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения.

Оценка эффективности реинжиниринга бизнес процессов проводится для определения степени достижения конечной цели с применением четырех следующих критериев: эффективности; своевременности; критерия качества; результативности

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

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

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

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

Код для цитирования: Скопировать