Методические указания по выполнению практических работ по профессиональному модулю

Цель: - составить запрос на сопровождение программного продукта - оценить качество сопровождения Теоретические сведения

жүктеу/скачать 5.65 Mb. бет 78/85 Дата 29.09.2023 өлшемі 5.65 Mb. #479244 түрі Методические указания

Цель: - составить запрос на сопровождение программного продукта - оценить качество сопровождения Теоретические сведения Качество сопровождения. Сопровождение нередко кажется тяжким грузом, но его можно рассматривать и как возможность продемонстрировать высокое качество обслуживания потребителей. Беннетт пишет, что такое отношение к сопровождению широко распространено в Японии. Качественное сопровождение можно считать необходимым условием для достижения постоянной удовлетворенности покупателя и для получения его будущих заказов. Некоторые предприятия выделяют сопровождение в самостоятельный вид деятельности, потому что оно может стать надежным долгосрочным источником дохода. Метрики сопровождения. Поскольку на сопровождение уходит значительная часть общей суммы трудозатрат за время жизни приложения (иногда для предприятий это оказывается неожиданностью), особенно важным становится наличие адекватной методики оценки затрат на сопровождение и доходов от него. Перечислим основные метрики сопровождения: ♦ количество строк сопровождаемого кода; ♦ трудозатраты на решение задач по сопровождению; ♦ количество дефектов. Прежде всего, следует определить цели сопровождения конкретного приложения, после чего выбрать дополнительные метрики, с помощью которых можно будет оценивать успех в достижении поставленных целей. Зависимость выбора метрик от поставленных целей демонстрирует табл. 1. Рассмотрим эти метрики более подробно. (1) Частота отказов. Отказы — это дефекты, обнаруженные во время тестирования или в процессе эксплуатации приложения. Вычисляется как отношение количества найденных дефектов к величине NCSLOC. Последняя аббревиатура расшифровывается как «тысяч строк исходного кода не считая комментариев». (30) Среднее время до отказа. Среднее время получения отказа после запуска приложения. Эта метрика требует введения определения отказа для тестируемого приложения. Определение зависит от того, что будет восприниматься потребителем как отказ. Отказом может считаться как аварийное завершение приложения, так и возникновение определенных конкретных проблем. Для финансового приложения как отказ может быть определена ошибка в вычислениях на величину не менее 1 доллара. Таблица 1. Выбор метрик в соответствии с целью сопровождения Применение метрик сопровождения. Доля комментариев в общем числе строк исходного кода позволяет предсказать масштаб трудозатрат на сопровождение (рис. 1). По сравнению с тремя другими модулями модуль «Запись неудачных дней» создаст больше всего трудностей при сопровождении из-за большой доли не комментированных строк и своего большого объема. Сопровождать модуль «Отчет о прибылях» будет проще всего, потому что он имеет наименьшие размеры и высокую долю комментариев. Долю комментариев можно вычислить при помощи специальной программы или путем изучения взятых наугад участков кода. Рис. 1. Оценка трудозатрат на сопровождение Для управления затратами на сопровождение полезны графики, аналогичные приведенному на рис. 2. В соответствии с этим графиком большое количество запросов на исправления и усовершенствования прибывает в первые два года, в результате чего на второй год эксплуатации возникает пик задержек выполнения запросов. Постепенно задолженность устраняется. Общий вид кривых на этом графике достаточно типичен, изменяется только масштаб по оси времени (годы, месяцы, недели). Рис. 2. Профиль количества запросов на устранение недостатков Для достижения эффективного распределения объема работ полезны графики, подобные рис. 3. На графике показано среднее количество недель ожидания решения по запросу на сопровождение. Время отсчитывается с момента поступления первого отчета. Для исправлений средний срок составляет около одной недели, а для усовершенствований — около четырех недель. Рис. 3. Пример профиля задержки до принятия решения о выполнении запроса Выделены основные параметры исходного кода, влияющие на удобство сопровождения приложения. Проведенное разбиение исходного кода по типам показано на рис. 4. Чем лучше система разбита на модули, тем проще ее сопровождать (рис. 5, Исходный код ► Управляющая структура ► Система). Чем лучше данные инициализируются, тем проще их сопровождать (рис. 5, Исходный код ► Информационная структура ► Компонент). К сожалению, усовершенствованные методы разработки систем обычно приводят к увеличению, а не к уменьшению затрат на сопровождение. Судя по всему, это связано с тем, что хорошо разработанные приложения проще изменять, поэтому мы чаще прибегаем к их адаптации к новым условиям. Рис. 4. Влияние параметров исходного кода на удобство сопровождения (1) Рис. 5. Влияние параметров исходного кода на удобство сопровождения (2) Формы и данные измерений в процессе сопровождения могут объединяться в единую программу корпоративную программу количественных оценок, проводимых в отношении программного обеспечения. Многие организации используют популярный и практичный подход для измерений, базирующийся на оценке количества проблем и статуса их решений (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): оценка усилий персонала сопровождения и пользователей по тестированию модифицированного программного обеспечения. Рассмотрим обработку запросов на сопровождение для игры Встреча. Запрос на сопровождение 4593. (Содержимое настоящего документа описано в таблицах раздела 10.4.). 1. Определение задачи. 1.1. Входные данные. Руководитель отдела маркетинга Мэри Краус определила, что механизм изменения значений характеристик двух встречающихся персонажей слишком сложен для среднего любителя компьютерных игр. 1.2. Процесс. Работа по этому запросу будет включена в выпуск 4. Запрос был принят к исполнению руководителем проекта 12 января 2000 года. Инженер Алан Оуэне оценивает стоимость исправления в 12 человеко-часов (включая все необходимые тесты) при условии, что регрессионное тестирование для данного запроса будет объединено с регулярным регрессионным тестированием, которое проводится каждые две недели. Запросу установлен приоритет 4 (из 5, где 5 — низший возможный приоритет). 1.3. Контроль. Запрос был внесен в хранилище запросов инженером А. Джонсом 13 января 2000 года. 1.4. Выходные данные. 13 января 2000 года инженер А. Джонс присвоил запросу номер 4593. Формулировка запроса такова. Упростить формулу вычисления значений характеристик персонажей при их контакте друг с другом указанным ниже способом. Значения специфичных для зоны характеристик для более слабого персонажа уменьшаются вдвое. (Под специфичными для зоны характеристиками понимаются характеристики, относящиеся к зоне, в которой происходит контакт.) Значения характеристик более сильного персонажа не изменяются. 1.5. Факторы качества. Факторы качества — полнота и ясность запроса на сопровождение. 1.6. Метрики. Запрос 4593 был оценен в процессе проверки службы сопровождения 22 января 2000 года и получил следующие баллы:. ♦ количество недочетов в запросе: 1;. ясность запроса: 8 (0 — непонятен, 10 — невозможно сказать яснее);. ♦ перекрытие запроса: 0 (0 — не перекрывается с другими запросами, 10 — включен в один или несколько незавершенных запросов);. ♦ оценка задержки запроса: 12 дней. [Примечание для студентов. Приведенные ниже сводные данные не следует повторять для каждого запроса.]. По всем незавершенным запросам получены следующие средние показатели:. ♦ среднее количество недочетов в запросе: 0,9 (групповой стандарт — 0,5);. ♦ средняя ясность запроса: 7,2 (групповой стандарт — 7);. ♦ среднее перекрытие запроса: 1,6 (групповой стандарт — 2,0);. ♦ средняя оценка задержки запроса: 18 дней (цель — 14). 2. Анализ задачи. 2.1. Входные данные. 1. Запрос на сопровождение 4593. 2. SRS версии 4.6.5 со следующими сведениями:. 3.2.К0.3.1. Вступление в контакт с внешним персонажем [важно]. При встрече двух персонажей более сильным считается тот, у которого больше сумма значений характеристик, специфичных для зоны контакта. Система передает половину значения каждой характеристики, специфичной для зоны контакта, от более слабого персонажа к более сильному. Предположим, что игрок встречается с внешним персонажем в зоне, где важны выносливость и сосредоточенность. Пусть р — значение выносливости игрока, и т. д. Предположим, что р + р > f + f . Тогда р = р + f /2, р = р + f /2. f = fa/2, f = f /2, где x — значение x после передачи характеристик. Рассмотрим пример с конкретными числами. Если значение выносливости игрока равно 7, а сосредоточенности — 19, тогда как для Фредди (внешнего персонажа) выносливость равна 11, а сосредоточенность — 0,1, то игрок будет сильнее. В результате контакта характеристики персонажей получат следующие значения: Игрок: выносливость 7 + 11/2 = 12,5; сосредоточенность 19 + 0,1/2 = 19,05 (отображается как 19,1). Фредди: выносливость 11/2 = 5,5; сосредоточенность 0, потому что 0,1/2 меньше 0,1. 2.2. Процесс. Возможность осуществления: данный запрос считается осуществимым, поскольку его влияние ограничено результатами контакта и жизнью игровых персонажей. Подробный анализ: единственный класс, который может быть изменен при выполнении запроса, — это Контакт. Объект Контакт вычисляет конечные значения характеристик персонажей, встретившихся друг с другом. Значения атрибутов объектов персонажей во время выполнения будут другими, но их код не требует изменения. В описании запроса приводится преобразование / = / /2, которое должно быть заменено на/ = / /2, потому что значение делится пополам, а не заменяется половиной другого значения. Уточнение документации: необходимо изменить одно требование в SRS. Другие требования остаются нетронутыми. Необходимо изменить руководство пользователя. 2.3. Контроль. Запрос обсуждался на собрании отдела сопровождения 3 апреля 1999 года и был классифицирован как запрос уровня 1 (технически простой). Для регрессионного тестирования были выбраны сегменты, задокументированные под номерами 7829 и 8924. Они не требуют изменений, за исключением таблиц ожидаемых результатов. [Примечание для студентов. Документация по тестированию в настоящем примере отсутствует.]. 2.4. Выходные данные. Одно требование в SRS было изменено так, как показано ниже (удаленные слова перечеркиваются, добавленные — подчеркиваются). 3.2.К0.3.1. Вступление в контакт с внешним персонажем [важно]. При встрече двух персонажей более сильным считается тот, у которого больше сумма значений характеристик, специфичных для зоны контакта. Система передаст полученные значения каждой характеристики, специфичной для зоны контакта, от более слабого персонажа к более сильному. Значения всех специфичных для зоны контакта характеристик более слабого персонажа уменьшаются вдвое. Предположим, что игрок встречается с внешним персонажем в зоне, где важны выносливость и сосредоточенность. Пусть р — значение выносливости игрока, и т. д. Предположим, что р +р > f +f . Тогда f £>=£„/3 ft =l f /2 I и f,.=[ i,J2 I. где x — значение x после передачи характеристик. Выражение I z I (операция округления вниз) означает наибольшее целое число. не превышающее z. Рассмотрим пример с конкретными числами. Если значение выносливости игрока равно 7, а сосредоточенности — 19, тогда как для Фредди (внешнего персонажа) выносливость равна 11, а сосредоточенность — 0,1, то игрок в рассматриваемой зоне будет сильнее. В результате контакта характеристики персонажей получат следующие значения:. Игрок: выносливость 7 + 11 /2 — 12,5; сосредоточенность 19 + 0,1/2 = 19,05 (отображается как Ю.Н.без изменений. Фредди: выносливость Lll/2j = 5; сосредоточенность L1/2J = 0. "В руководство пользователя необходимо внести следующие изменения... Vne приводятся). План реализации: данный запрос будет реализован инженером Т. Файном. Поскольку запрос приведет к значительным изменениям в стиле игры, он будет реализован и протестирован отдельно от всех прочих запросов. Существует некоторая неопределенность относительно того, как это изменение будет принято игроками, поэтому планируется проведение расширенного тестирования удобства и простоты использования. 2.5. Факторы качества. Принципиальным фактором качества является цельность анализа влияния. 2.6. Метрики. Количество часов на анализ влияния одного измененного или добавленного метода: 0,5. Степень изолированности от других запросов: 6,5 (абсолютно не изолирован — 0, полностью изолирован — 10). Примечание: этот запрос устранил дефект «f = /а/2» в первом требовании к контакту, в результате чего образовалось перекрытие с другим действием по сопровождению. Ожидаемое время подтверждения задачи: 12 дней фактического времени. Процент ошибок в документации: (еще не оценен). Трудозатраты: 2 человеко-часа. Фактическое время: 2 дня. Процент ошибок: (еще не оценен). В результате для полного набора незавершенных запросов получены следующие средние результаты. ♦ Среднее количество часов на анализ влияния одного измененного или добавленного метода: 0,9 (среднее по группе — 0,6). ♦ Средняя степень изолированности запросов друг от друга: 5,1 (групповой стандарт — 4,0). 3. Проектирование. 3.1. Входные данные. Запрос на сопровождение 4593. 3.2. Процесс. Требуется изменение SDD. Псевдокод функции executeO класса Контакт был изменен так, как показано ниже. 3.3. Контроль. Требуется инспектирование нового псевдокода. Дата инспектирования — 8 апреля 1999 года. 3.4. Выходные данные. Номер первой редакции SDD с этим запросом — 5.4.3. Приведенный ниже псевдокод должен быть включен в измененный метод execute О класса Контакт. Пусть asq[] - специфичные для зоны контакта характеристики. ПРИСВОИТЬ р сумму значений asq[] для игрока. ПРИСВОИТЬ f сумму значений asq[] для внешнего персонажа. ЕСЛИ р == f, контакт ничем не заканчивается. ЕСЛИ р > f. Уменьшить значения asq[] внешнего персонажа вдвое и применить к ним операцию округления вниз. ИНАЧЕ ЕСЛИ f > р. Уменьшить значения asq[] игрока вдвое и применить к ним операцию округления вниз. План тестирования должен быть изменен следующим образом: ... В связи с важностью данного запроса отдел маркетинга назначил тест удобства и простоты использования за номером 8902. Этот тест призван определить реакцию пользователей на вычисления по новым формулам. 3.5. Качество. Важнее всего то, как изменение будет принято игроками. Кроме того, важно проведение регрессионного тестирования, гарантирующего отсутствие ошибок в расчетах, а также отсутствие отрицательного влияния нововведения на другие функции игры. 3.6. Метрики. Количество замен в псевдокоде: 1. Процент ошибок в документации: подлежит оценке. Трудозатраты: 1 человеко-час. Фактическое время: 1 день. Процент ошибок: подлежит оценке. 4. Реализация. 4.1. Входные данные. SDD версии 5.4.2. Исходный код версии 11.3.7. 4.2. Процесс. Кодирование изменений по данному запросу было выполнено Б. Марксом. Несистемное тестирование произвел А. Антонини. 4.3. Контроль. Планы реализации и модульного тестирования были проверены 30 января 2000 года командой 5. 4.4. Выходные данные. Первая версия исходного кода с внесенными изменениями — 11.3.8. Отчет об инспектировании находится в архивах инспектирований и датирован 30 января 2000. Отчеты о тестировании находятся в пакетах документации тестирования 7820, 7621 и 8902. 4.5. Факторы качества. Применялись факторы качества SQAP проекта Встреча. 4.6. Метрики. 5. Системное тестирование. 5.1. Входные данные. SDD версии 5.4.2. SRS версии 4.6.5. Исходный код версии 11.3.8. 5.2. Процесс. Регрессионные тесты 7893.4, 23689.14, 21376.0 и 1237.46 пройдены. Новые регрессионные тесты, построенные для проверки новых расчетов, имеют номера 7893.5, 23689.15, 21376.1 и 1237.47 соответственно. Перечисленные далее тесты будут проведены для версии 11.3.2:... Удобство и простота использования конечного продукта будет оценено при помощи приведенной ниже процедуры, которая будет выполнена три раза. Полная документация тестирования сохранена за номером 89041.0. Из всего множества игроков будут случайным образом выбраны 100 человек, которые должны будут оценить текущую версию игры по десятибалльной шкале по следующим показателям: интерес, сложность, реалистичность и общее удовольствие. После этого им будет предоставлена измененная версия вместе с новым руководством пользователя. Они будут играть в измененную игру 10-15 часов в течение недели, после чего должны будут выполнить ту же оценку, что и ранее. Приведенная выше процедура должна быть повторена с другой выборкой, но в обратном порядке (сначала новая версия, потом старая). Отчет о результатах тестирования на удобство и простоту использования должен быть предоставлен в форме процентных различий между значениями перечисленных показателей для старой и новой версий. 5.3. Контроль. См. SCMP. 5.4. Выходные данные. Результаты тестирования будут сохранены в STD за номером 890451. 5.5. Факторы качества См. STD. 5.6. Метрики. См. STD. 6. Приемосдаточное тестирование. Выполнение запроса на сопровождение будет признано успешным, если для 400 потребителей будут получены следующие результаты. 1. Пройдены все регрессионные тесты (см. выше). 2. По всем категориям достигнуто увеличение показателей. По меньшей мере в двух категориях теста на удобство и простоту использования получено увеличение на 25 %. Ни по какой категории результат не может быть более чем на 3 % хуже, чем до внесения изменений. жүктеу/скачать 5.65 Mb. Достарыңызбен бөлісу: