BoatmansHome: Заметки/ОКачестве1 ...

Boatmans Home Start | Каталог | Изменения | Комментарии | Пользователи | Регистрация | Вход  Пароль:  
Данные материалы созданы для размещения на сайте boatmanshome.ru. Во всех случаях, кроме явно оговоренных в теле материала, автор и обладатель исключительного права - Нужненко Сергей Александрович. Во всех случаях, кроме явно оговоренных в теле материала, для данных материалов разрешено размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях. Без согласования с правообладателем запрещается для данных материалов или любой части использование в коммерческих целях, а так же распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
 

Качество, и как с этим бороться


Оглавление


Одним из ключевых параметров проектного треугольника является качество. Правило проектного треугольника говорит нам, что нельзя поменять один параметр проекта, чтобы не изменились остальные.
Так вот, со стоимостью и сроками в роли параметров, кажется, все ясно. Как их измерить, и что значит, когда они изменились, наверное можно понять.
А вот что я имею ввиду, когда говорю «изменится объем» или «изменится качество» – это требует выяснений. Точнее, есть вопрос: а в чем авторы правила проектного треугольника предлагают измерять эти параметры?
Этот вопрос лишь кажется простым.


Так же для менеджеров продуктов/проектов и аналитиков рано или поздно встает вопрос: какими соображениями ограничить рамки продукта или системы и как требования внутри этих рамок приоритезировать.


Я, не претендуя на истину в последней инстанции, сегодня хочу обсудить вопросы измерения и планирования качества, применительно к ИТ системам.


Поскольку рука моя в последние недели неистово тянется к «гаечному ключу», обсуждение проведем в виде лабораторной работы.
Если у кого-то есть студенты и подходящий курс по управлению проектами или QA, можете предложить им это на практических занятиях. Публикация и обсуждение результатов приветствуется :)


Ниже я покажу некоторые подходы к измерению качества ПО и ROI автоматизации на конкретных лабораторных данных. Кому лень все это читать, в разделе «Расчеты» есть красивые графики, или можно сразу прыгнуть в раздел «Выводы».


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

Цели работы

1. Получить практический опыт измерения качества программной системы.
2. Экспериментально установить зависимость между вложениями в повышение качества и уровнем качества.
3. Экспериментально проверить действие принципа падающей отдачи.
4. Экспериментально проверить действие правила проектного треугольника с точки зрения изменения качества.
5. Предложить рекомендации по планированию оптимального уровня качества программной системы.

Теория

Цена и сроки

Пройдем по всем параметрам проектного треугольника.


(C) Для оценки размера программы кроме трудозатрат можно использовать строки кода или SLOC, количество которых хорошо кореллирует с трудозатратами.

(T) – Для нашего модельного случая будем считать, что сроки линейно связаны с трудозатратами, что верно для программ, написанных одним человеком за короткое время (меньше недели).

Качество

К измерению качетва есть несколько подходов.
Качество – это соответствие предмета поставки ожиданиям и требованиям потребителя.
Варианты измерения:


Для конструирования формулы качества на основе требований с учетом багов условимся, что у нас есть:


Общие положения для конструирования формулы:


В итоге можно предложить такую метрику:


В итоге формула у нас будет такая (все требоания одного веса, все баги тоже одного веса, отличного от веса требования):


Q(требования с учетом багов)=sum_по всем требованиям_(A/(A+B*X), где


Метрика качества на основе ценности.


В каждом состоянии программа создает какую-либо ценность.
Ограничимся в данной работе прямой экономией времени пользователей.


Таким образом метрику качества можно назначить достаточно просто


Q(по ценности)=А-В, где

Схема эксперитмента

Модельная ситуация


Вернемся в конец 1980х годов.
Учитель математики (Джон) гипотетической школы хочет автоматизировать свою работу по проверке контрольных работ, на которых ученики решают квадратные уравнения.
Год за годом такие контрольные проходят у параллели из 4х классов (в среднем по 25 учеников) 3 раза в год.
Каждый ученик получает по 20 примеров a*x^2+b*x+c=0 и сдает лист с решением.


В конце предыдущего учебного года школа купила современный компьютер IBM PC/AT с процессором intel 386sx и 2 Mb оперативной памяти под управлением операционной системы MS DOS с встроенным интерпретатором QBasic.
Окончив летние курсы по программированию на языке Basic, Джон решает автоматизировать свой труд. И пишет программу, постепенно совершенствуя ее.

Лабораторные инструменты

Чтобы не возиться с установкой MS DOS вместо qbasic будем использовать vbscript с интерпретатором cscript, позволяющим работу в режиме терминала.
Соответственно в моем случае это делалось на Windows 7.


При написании кода вместо удаления будем коментировать лишние строки кода, чтобы по количеству строк в файле было видно приращение новых строк (чтобы не возиться с VCS).
Считать будем физические строки кода, включая пустые. Учитывая, что программу пишет один человек в сжатые сроки, не меняя стиль программирования это допустимо.
Для написания кода я использую встроенный редактор Far manager, но можно обойтись и notepad(ом) с включенной строкой состояния (там показаны кооррдинаты курсора в файле).


Считать и строить графики будем в MS Excel.
Для эталонного измерения времени неавтоматизированной работы будем применять калькулятор Windows.

Порядок выполнения

Мы напишем несколько вариантов прграммы для решения квадратного уравнения с разным качеством. Определим уровень качества разными способами, сопоставим между сообй и соотнесем с количеством строк.


Уровень качества измерим по метрикам:


Измерим затраты на строку кода для назначения модельной себестоимости создания программы.

Лабораторные данные

Экономия рабочего времени


Для получения экономии времени ставим мысленно-натурный эксперимент.


Учитель берет стопку листов и пересчитывает результаты на калькуляторе, отмечает ошибки и ставит итоговый балл.
В четверти случаев пример решен неверно, что заставляет Джона пересчитывать дважды, проверяя, кто ошибся – он или ученик.
На пересчет каждого примера тратится 2 минуты (я проверял на калькуляторе руками). Или 25*4*3*20*2*1,25=15000 минут в год.


Вот бэклог из 12 требований, которые последвательно были реализованы.


1. Программа должна читать с консоли коэффициенты квадратного уравнения a*x^2+b*x+c=0 и выводить корни x1 и x2.
2. Программа должна корректно выводить сообщение “d<0” при отрицательном дискриминанте.
3. Программа должна корректно выводить сообщение об ошибке, если введено не число.
4. Программа должна иметь дружественный интерфейс, подсказывающий пользователю, что делать и помогающий ориентироваться в процессе работы.
5. Программа должна сообщать пользователю о своем назначении.
6. Нужны отступы между блоками описания программы, ввода коэффициентов и решением. Блоки ввода коэффициентов и решения надо озаглавить “Input a,b,c” b “Solution”.
7. Если x1=x2, нужно выводить одну строчку решения «x1=x2=...» вместо двух.
8. Возможность закольцевать работу, чтобы не запускать программу несколько раз.
9. Убрать прекращение работы программы, разрывающее цикл, при вводе некорректного номера.
10. Добавить возможность выхода в любой точке.
11. Возможность проверить коэффициенты (можно перевводить коэффициенты несколько раз в произвольном порядке) перед решением.
12. Исправить падение при а=0


Вот причины, по которым возникла необходимость улучшения.
1. Простая программа читающая коэффициенты и выдающая результаты сокращает время вычисления до 20 секунд, двойной пересчет при негативной оценке не нужен.
И теперь проверка занимает 25*4*3*20*20/60=2000 минут в год.


2. В 5 случаях из 20 у уравнения отрицательный дискриминант, программа падает, заставляя пересчитывать дискриминант на калькуляторе (1 мин+ 20 секунд работы программы).
Это дает поправку к предыдущей цифре 25*4*3*20*5/20*1=1500 минут в год.


3. В 1 из 50ти случаев ввода (а их 3 на прогон) Джон делает опечатку и программа падает, заставляя запускать себя заново и раздумывать о причине падения (+40 секунд на 50/3=16,7 прогонов).
Это дает поправку 25*4*3*20*3/50*40/60=240 мин.


4. Написав и отладив программу Джон проверил пару контрольных и пошел домой удовлетворенным. А на следующий день потратил 10 минут чтобы вспомнить, как ей пользоваться (и так в среднем (1–2)*4*3 раза в год).
Что дает поправку 10*1,5*4*3=180 мин в год.


5. Через месяц Джон забыл, которая из его программ делает то, что ему нужно и он искал нужный файл 20 минут (и так в среднем 3 раза в год).
Поправка – 20*3=60 минут в год.


6. При длительной проверке большой пачки работ текст на экране начинает сливаться в глазах, Джон ошибочно помечает каждый 30й пример правильным или неправильным и в половине случаев (когда он ошибочно занизил оценку) он тратит на выяснение ситуации с учениками и исправление балла в журнале 5 минут.
То есть тратится 25*4*3*20/30/2*5=500 минут в год.


7. В каждом 20-том примере x1=x2 и в каждой 10й такой ситуации Джон ошибочно отмечает пример неправильно решенным с последствиями из предыдущего абзаца.
То есть тратится 25*4*3*20/20/10/2*5=60 минут в год.


8. Поскольку запуск программы для каждого примера съедает по 5 секунд, Джон решил закольцевать алгоритм, чтобы можно было не перезапускать прграмму каждый раз. Это дает время цикла решения 15 секунд.
То есть теперь базовая цифра из п.1. уменьшилась 25*4*3*20*15/60=1500 минут в год.


9. Как уже выше было сказано, в 1 из 50ти случаев ввода (а их 3 на прогон), Джон делает ошибку, вводя буквы вместо чисел, и программа завершает работу (с корректным сообщением). Это создает затраты 5 сек на новый запуск (+5 секунд на 16,7 прогонов).
И дает поправку 25*4*3*20*3/50*5/60=30 минут в год.


10. Раз в 100 решений Джону нужно прервать проверку и запустить другую программу. Необходимость довводить все данные съедает 10 сек.
То есть тратится 25*4*3*20/100*10=600 секунд или 10 минут в год.


11. В каждом 50м случае ввода Джон делает опечатку при вводе чисел, ошибочно отмечает пример неправильным и это в половине случаев приводит к разборкам (по 5 минут). То есть 25*4*3*20*3/50/2*5=900 минут. Возможность исправлять введенные данные снизили бы последствия опечаток в числах до 10 сек на опечатку.
То есть тратится 25*4*3*20*3/50/2*10/60=30 мин в год.


12. Случаи с a=0 в контрольных не встречаются, но иногда при ошибке ввода данных (каждый 100 пример) это вызывает заминку на 1 минуту.
То есть тратится 25*4*3*20/100*1= 60мин в год.


Теперь складываем реальные затраты на автоматизированную проверку контрольных.
1. Все дополнения сюда входят. Затраты 2000 (проверка)+1500 (пересчет дискриминанта)+ 240 (ошибки ввода букв)+ 180 (впоминали, как это работает) + 60 (через месяц искали, которая программа наша)+500 (ошибочные отметки) + 60 (ошибки, когда x1=x2) + 10 (нет прерывания в середине) + 30 (опечатки в числах с ошибочными отметками примеров) + 60 (ошибки с a=0) = 4640 мин в год.


2. Уходят задержки из-за отрицательного дискриминанта.
Время автоматизированной деятельности 4640–1500=3140 мин в год.


3. Уходят затраты на ошибки с вводом не чисел.
Время автоматизированной деятельности 3140–240=2900 мин в год.


4. Уходят проблемы с вспоминанием, как пользоваться программой.
Время автоматизированной деятельности 2900–180=2720 мин в год.


5. Уходят проблемы с поиском нужной прграммы.
Время автоматизированной деятельности 2720–60=2660 мин в год.


6. Уходят ошибочные отметки из-за сливающегося текста.
Время автоматизированной деятельности 2660–500=2160 мин в год.


7. Уходят ошибки из-за x1=x2.
Время автоматизированной деятельности 2160–60=2100 мин в год.


8. После закольцовки аогоритма мы тратим не 20, а 15 мин. на цикл. Но с проблемами вылета из цикла при вводе не чисел (+30 мин).
Время автоматизированной деятельности 2100–2000+1500+30=1630 мин в год.


9. После исправления вылета из цикла при вводе не чисел уходит 30 минут затрат.
Время автоматизированной деятельности 1630–30=1600 мин в год.


10. Уходят затраты, связанные с невозможностью выйти в середине цикла (-10 мин).
Время автоматизированной деятельности 1600–10=1590 мин в год.


11. Уходят затраты с ошибками в числах и ошибочными пометками примеров неправильными (-30 мин).
Время автоматизированной деятельности 1590–30=1560 мин в год.


12. Уходят опечатки с а=0 (-60 мин).
Время автоматизированной деятельности 1560–60=1500 мин в год. (как и должно быть при качественной реализации требования 8).

Исходный код


Для реализации первого требования был написан следующий код длиной 13 строк.



В конечном итоге на 12й итерации получился следующий код, длиной 121 строка (включая закоментированные псевдоудаленные строки).



Исходный код по остальным итерациям лежит по адресу http://boatmanshome.ru/mat/quality1.zip (файлы a1.vbs-a12.vbs).
Запускать командой «cscript //nologo <your_file.vbs>" из командной оболочки cmd.


Затраты на строку кода удалось получить не в каждой итерации (так как о них не сразу вспомнили).
Ниже в таблице


file:tps.png


Таблица с расчетами лежит по адресу http://boatmanshome.ru/mat/quality1.xlsx (лист data1).


Среднее время на строку кода у нас получилось 2мин 36 сек. В модельном примере можно принять за достоверное время на строку кода равным 5 мин, учитывая ниже среднего уровень программирования Джона и то, что создание программы не делалось в сжатые сроки в лабораторных условиях.

Измерения качества

Качество, измеренное по 3 вариантам показано в таблице.
Колонка SLOC отражает число строк по итерациям.
SLOC add отражает приращение числа строк на данной итерации.


file:qm1.png

Расчеты

Таблица с расчетами лежит по адресу http://boatmanshome.ru/mat/quality1.xlsx (лист data).


В этой работе параметры качества КИ и КУБ с хорошей корреляцией растут линейно в зависимости от номера итерции так же, как и SLOC.


file:qm2.png file:qm3.png


Параметр КЭ (качество пропорциональное экономии от автоматизации) растет логарифмически c хорошей корелляцией.


file:qm4.png


Вообще-то существуют пределы оптимизации функции проверки контрольных работ (мы не сможем сэкономить больше 15000 мин. в год, которые исходно тратили), по этому строго говоря логарифмическая функция не подходит для моделирования кривой эффекта. Нам нужно ассимптотическое стремление к константе.
Приложив немного усилий по подбору зависимости, мы остановились на 1/sqrt(x).
Модельный параметр q=15000–5000/x^0,5.


( (21 Кб))


Теперь посмотрим ROI (за год) по каждому варианту, определяемое как (Экономия)/(SLOC*5мин).
И на add ROI, определяемое, как эффективность каждого инкремента (Экономия – Экономия пред шага)/(SLOC add*5).


file:roi1.png


Данные к этим графикам.


file:roi2.png

Выводы


Частные выводы:
1. Качество, измеренное «по галочкам» – по количеству реализованных требований не дает падающей отдачи качество/стоимость изменений на этих лабораторных данных. При этом, мы очевидно не приблизились к пределу, где сложность системы дает нелинейный рост стоимости внесения изменений. Так же эти параметры не дают связи с ценностью для пользолвателей и для приоритезации не пригодны.
2. Качество, измеренное по экономическому эффекту (экономии времени) на этих лабораторных данных показывает падающую отдачу со скоростью const-1/sqrt(x). С этой точки зрения можно видеть, что изменение качества, как стороны проектного треугольника будет нелинейно увеличивать стоимость/сроки.
3. Отдача с каждой итерацией падает в пределе как 1/x. Отдача от каждого следующего изменения падает еще быстрее.
4. Если следовать экономической логике, то вместо полировки данной программы мы должны были бы поискать возможности автоматизации с наиболее высоким ROI (например, проверку контрольных другого типа) и только потом можно возвращаться к полировке.
5. Это совпадает с внутренними ощущениями. Предыдущий пункт мы часто встречаем как в автоматизации бизнеса, так и для массового рынка ИТ продуктов. Вопросом для исследования в следующей лабораторной работе должны стать связь usability требований с количеством пользователей программы.
6. Исследованный пример относится к автоматизации предыдущего поколения. Аналог нашей программы любой подкованный пользователь сделает в MS Excel за 10 минут. Сегодняшняя автоматизация, похоже, уже не обладает такими возможностями по оптимизации затрат в сотни раз. И это нужно отдельно обсудить.


Обобщения и параллели:
1. Кривая падающей отдачи в зависимости от повышения уровня качества функций демонстрирует начинающим менеджерам продукта, в чем суть MVP и чем хороша сквозная приоритезация требований. Внутри лабораторной работы показаны практические подходы к назначению ценности требований, дающие сортировку бэклога продукта.
2. Похоже, сегодняшняя автоматизация в подавляющем большинстве случаев вышла из стадии прямой экономии с гигантскими ROI. Такие величины отдачи объясняют, в чем заключался ажиотаж вокруг ИТ прошлых лет, и почему сегодняшние ожидания могут часто быть раздуты. Современные ИТ пытаются выскрести последние единицы ROI и чаще всего отдача достигается комбинацией прямой экономии и нелинейными эффектами от повышения качества управления. И это тоже надо отдельно обсудить.


 
Много файлов (8).[Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]