Квайн на Ассемблере? Это просто

Известно, что квайн (куайн) — программа, результатом работы которой является вывод текста самой программы. При этом предполагается, что обращения к файлу, содержащему программу, не происходит.

Квайны могут быть составлены практически на всех языках программирования за исключением, быть может, некоторых экзотических. Рассмотрим задачу составления квайна на ассемблере, предполагая, что программа должна быть Win32 приложением и должна выводить свой текст в окно.

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

push 48 (или же push 30h),

так и с использованием директивы определения данных db

db 06Ah,030h (или же db 106,48).

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

Исходник 1

.386 .model flat,stdcall .code q: db 16-ричные коды инструкций и данных .... db 16-ричные коды инструкций и данных end q 

(используется ассемблер MASM). Трудность в том, что напрямую написать такой квайн почти невозможно — это фактически программирование в машинных кодах. Однако начать можно с записи программы с помощью обычной ассемблерной мнемоники — см. приводимый ниже исходник 2. Важно при этом, что при компиляции исходников 1 и 2 получается один и тот же машинный код.

Исходник 2

; @echo off  ; ml /c /coff quine.cmd ; pause ; if errorlevel 1 goto exit  ; link /subsystem:windows /section:.text,RW quine.obj ; pause ; del quine.obj ; goto exit  .386 .model flat,stdcall option casemap:none  include		\masm32\include\windows.inc  bStr		= 25						; кол-во байтов, определяемых в одной строке квайна qLen		= len * 5 + (len / bStr + 1) * 4 + len1 + 10	; размер исходника квайна stLen		= (qLen / 1000h + 1) * 1000h			; выделяемая в стеке память под исходник  .code  ; *** Часть 1 - формирование в стеке текста исходника ***  start:		cld 		mov edx,[esp]		; ссылка вглубь kernel32.dll - для части 2 		sub esp,stLen		; выделение области в стеке 		mov edi,esp 		mov stAddr,edi 		lea esi,text 		xor ecx,ecx 		mov cl,len1 rep 		movsb			; копирование преамбулы '.386 .model flat ...'  		lea esi,start 		mov bl,bStr cycl:		mov eax,ecx		; генерация текста. Конец строки? 		div bl 		or ah,ah 		jnz comma 		mov ax,0A0Dh		; да - перевод строки и вставка директивы db		 		stosw 		mov eax,'  bd' 		stosd 		dec edi 		jmp j1 comma:		mov al,','		; нет - вставка запятой, разделителя байтов 		stosb j1:		mov al,'h'		; формирование 16-ричного представления байта - суффикс h 		shl eax,16 		lodsb 		mov ah,al 		and al,0Fh 		cmp al,10 		sbb al,69h 		das			; младшая половина байта 		xchg al,ah 		shr al,4 		cmp al,10 		sbb al,69h 		das			; старшая половина 		shl eax,8 		mov al,'0'		; префикс 0 		stosd 		inc ecx 		cmp ecx,len 		jb cycl  		mov ax,0A0Dh		; концовка квайна 'end q' 		stosw 		mov eax,' dne' 		stosd 		mov eax,'q' 		stosd  ; *** Часть 2 - нахождение адресов API функций ***  		xor dx,dx c2:		cmp word ptr [edx],'ZM'	; MZ-заголовок модуля kernel32? 		je c1 c3:		sub edx,10000h 		jmp c2 c1:		mov ecx,[edx+3Ch] 		cmp dword ptr [edx+ecx],'EP' ; PE-заголовок? 		jne c3  		mov ecx,[edx+ecx+78h] 		add ecx,edx		; адрес таблицы экспорта kernel32 		push ecx 		mov eax,[ecx+20h] 		add eax,edx		; адрес таблицы адресов имен функций 		xor ebx,ebx 		xor ecx,ecx cycl2:		mov esi,[eax+4*ebx] 		add esi,edx 		lea edi,GPAname 		mov cl,len2 repe		cmpsb			; поиск строки GetProcAddress 		je found 		inc ebx 		jmp cycl2  found:		pop ecx 		mov eax,[ecx+24h] 		add eax,edx 		mov bx,[eax+2*ebx]	; ординал функции GetProcAddress 		mov eax,[ecx+1ch] 		add eax,edx 		mov ebx,[eax+4*ebx] 		add ebx,edx 		mov edi,edx		; EBX - адрес GetProcAddress 					; EDI - база модуля kernel32 (а затем - user32)   		xor ecx,ecx		; нахождение адресов остальных функций 		mov cl,tlen 		lea esi,tbl  cycl3:		cmp cl,tlen-tlen2	 		jne j2  		push ecx 		push offset DLLname 		call eax		; загрузка user32.dll с помощью вызова LoadLibrary 		pop ecx 		mov edi,eax  j2:		dec cl 		push ecx 		push [esi+4*ecx] 		push edi 		call ebx		; получение адресов функций с помощью GetProcAddress 		pop ecx 		mov [esi+4*ecx],eax  		or cl,cl 		jnz cycl3  ; *** Часть 3 - вывод исходника в окно MessageBox ***  		push NULL 		call dword ptr _GetModuleHandle 		mov hInst,eax  		call dword ptr _GetCurrentThreadId  		push eax 		push NULL 		push offset hProc 		push WH_CBT			; установка хука на системные окна 		call dword ptr _SetWindowsHookEx 		mov hook,eax  		push MB_OK 		push offset capt 		push stAddr 		push 0 		call dword ptr _MessageBox	; окно с текстом квайна  		push 0 		call dword ptr _ExitProcess  ; ***  hProc		proc code:dword,wParam:dword,lParam:dword	; обработчик хука 		local coord:RECT  		pusha 		cmp code,HCBT_ACTIVATE		; активация окна? 		jne exit  		push 0FFFFh 		push wParam 		call dword ptr _GetDlgItem 		mov ebx,eax			; хэндл текстового поля  		lea eax,coord 		push eax 		push ebx 		call dword ptr _GetClientRect	; координаты текстового поля 		add coord.right,20  		push NULL 		push NULL 		push WM_GETFONT 		push ebx 		mov edi,_SendMessage 		call edi			; текущий шрифт текста 		mov esi,eax  		push SW_HIDE 		push ebx 		call dword ptr _ShowWindow	; скрытие текста  		push NULL 		push hInst 		push 0FFFFh 		push wParam 		push coord.bottom 		push coord.right 		push coord.top 		push coord.left 		push WS_CHILD+WS_VISIBLE+ES_MULTILINE+ES_READONLY 		push stAddr 		push offset cname 		push WS_EX_WINDOWEDGE 		call dword ptr _CreateWindowEx	; окно EDIT вместо STATIC 						; для того, чтобы из него можно было копировать  		push NULL 		push esi 		push WM_SETFONT 		push eax 		call edi			; установка шрифта  		push hook 		call dword ptr _UnhookWindowsHookEx ; снятие хука 		popa 		xor eax,eax 		ret  exit:		popa 		push lParam 		push wParam 		push code 		push hook 		call dword ptr _CallNextHookEx	; на следующий обработчик 		ret hProc		endp  ; *** инициализированные данные  capt		db 'Quine',0			; заголовок окна GPAname		db 'GetProcAddress',0 len2		equ $ - GPAname  GDIname		db 'GetDlgItem',0		; имена используемых функций GCRname		db 'GetClientRect',0 SMname		db 'SendMessageA',0 SWname		db 'ShowWindow',0 CWEname		db 'CreateWindowExA',0 UWHEname	db 'UnhookWindowsHookEx',0 CNHEname	db 'CallNextHookEx',0 SWHEname	db 'SetWindowsHookExA',0 MBname		db 'MessageBoxA',0 LLname		db 'LoadLibraryA',0 GMHname		db 'GetModuleHandleA',0 GCTIname	db 'GetCurrentThreadId',0 EPname		db 'ExitProcess',0  DLLname		db 'user32.dll',0 cname		db 'EDIT',0			; класс окна  text		db '.386',13,10,'.model flat,stdcall',13,10,'.code',13,10,'q:' ; преамбула квайна len1		equ $ - text  tbl			label dword		; таблица смещений имен функций, динамически заменяемых на адреса  _GetDlgItem		dd offset GDIname	; функции из user32.dll _GetClientRect		dd offset GCRname _SendMessage		dd offset SMname _ShowWindow		dd offset SWname _CreateWindowEx		dd offset CWEname _UnhookWindowsHookEx	dd offset UWHEname _CallNextHookEx		dd offset CNHEname _SetWindowsHookEx	dd offset SWHEname _MessageBox		dd offset MBname  tbl2			label dword _LoadLibrary		dd offset LLname	; функции из kernel32.dll _GetModuleHandle	dd offset GMHname _GetCurrentThreadId	dd offset GCTIname _ExitProcess 		dd offset EPname tlen2			equ ($-tbl2) / 4  tlen			equ ($-tbl) / 4		; размер таблицы  len		equ $ - start			; размер кода  ; *** неинициализированные данные, в квайн не попадающие  hInst		dd ?				; хэндл модуля hook		dd ?				; хэндл хука stAddr		dd ?				; адрес текста квайна в стеке  end start  :exit 

Принцип работы ясен из приведенных в тексте комментариев. Отметим только, что программа состоит из трех частей. В первой части в стеке формируется текст квайна (т.е. исходник 1). Количество байтов, определяемых одной директивой db (следовательно, и ширина строк квайна), задается константой bStr — она установлена равной 25-и. Поскольку во время компиляции не импортируются какие-либо API функции, то во второй части динамически определяются адреса ряда функций. Вначале это адрес функции GetProcAddress, получаемый трассировкой таблицы экспорта модуля kernel32.dll. Затем — адреса остальных функций, получаемых с помощью GetProcAddress. Наконец, в третьей части осуществляется вывод квайна в окно MessageBox. Поскольку по умолчанию выводимый текст статический и его нельзя куда-либо скопировать, дополнительно устанавливается хук, позволяющий копировать текст из окна. Возможны другие варианты третьей части квайна — например, с помощью создания очереди сообщений и написания оконной функции.

Итак, исходник 2 (не являющийся квайном) необходимо сохранить в пакетном файле quine.cmd и запустить его — получается исполняемый файл quine.exe. Далее запускается quine.exe, и из появившегося окна следует, выделив мышью, скопировать текст в файл quine.asm. Исполняемый файл можно удалить. Таким образом, в quine.asm — полноценный квайн (см. исходник 1). Транслируется он с помощью

ml /c /coff quine.asm

а линкуется с помощью

link /subsystem:windows /section:.text,RW quine.obj

(в секцию кода должна быть разрешена запись). Размер len секции кода составил 820 байт.

Отладку программы я производил турбо дебаггером, но при этом дополнительно включал строку

invoke ExitProcess,0

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

include \masm32\include\kernel32.inc
includelib \masm32\lib\kernel32.lib

Иначе дебаггер зависает — по-видимому, из-за отсутствия таблицы импорта в исполняемом файле.

ссылка на оригинал статьи http://habrahabr.ru/post/217375/

Как перейти от Цели подразделения техподдержки к показателям, понятным сотрудникам

Задача:

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

Исходные установки и упрощения:

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


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

Обоснование (теория):

Целевой показатель от бизнеса – минимизация потерь от инцидентов и несвоевременно завершенных запросов на обслуживание.

Попробуем определить, что влияет на целевой показатель:

На этом теоретические изыскания закрываем и пытаемся обработать их плоды.

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

Как помочь определить приоритеты или как оценивать скорость потерь C:

В абсолютных величинах задача не подъемная (да, и не особо нужная), поэтому предлагается вариант использования оценок, заключающийся в том, что считаем стоимость пропорциональной нашей оценке:

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

Что же делать с этой оценкой Oi? Разлагать на более понятные и легко оцениваемый параметры, от которых в реальности и зависят потери:

Собственно по оценке стоимости потерь — это все. В итоге непонятную стоимость свели к «широко известной» схеме экспертных оценок.

Пример параметров (частично взято из ITIL):

  1. Степень влияния – степень потери от штатного функционирования на элементарном объекте\услуге.
  2. Критичность потери – относительная оценка величины потерь на одном элементарном объекте\услуге из-за проблемы.
  3. Масштаб проблемы – количественная оценка элементарных объектов, пострадавших от проблемы.

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

Вроде бы ничего нового в ходе рассуждений не изобрели, но когда по этому пути рассуждений проводится сотрудник, то его мировоззрение: «зачем все это» и «почему все именно так», может кардинально меняться.

Также вышеизложенное можно использовать для автоматизации определения приоритетов заявок.

Надеюсь изложенные мысли окажутся полезными.

ссылка на оригинал статьи http://habrahabr.ru/post/217651/

Математика для тестировщиков

Доклад Никиты Налютина на конференции SQA Days – 13, 26-27 апреля 2013 г. Санкт-Петербург, Россия

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


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

В тестирование я пришел одиннадцать лет назад из разработки. Начинал как тестировщик-автоматизатор, занимался тестированием авиационного софта. Если вы летаете на самолетах Airbus, наверное, две или три системы, стоящие сегодня на их борту, проходили через мои руки. После этого работал в разных предметных областях: занимался тестированием трейдинговых систем в Deutsche Bank, немного поработал в замечательной компании Undev. Сейчас работаю в компании Experian, где я занимаюсь тест-менеджментом по России, странам СНГ и Европе. Кроме непосредственно тестирования за последние одиннадцать лет получилось сделать много разных интересных вещей. Преподаю в трех отечественных университетах. Не спрашивайте, как у меня это получается – сам не знаю. В 2007 году удалось выпустить книгу по верификации и тестированию, при поддержке компании Microsoft. Говорят, что получилось неплохо.

О чем сегодня пойдет речь? Зачем нам нужна математика в тестировании. Почему мы не можем тестировать без математики. В каких случаях такой вариант возможен, а в каких нет. На нескольких примерах посмотрим, как математику можно применять на практике. Как и куда стоит смотреть, когда мы начинаем тестировать что-то новое.

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

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

На самом деле со времен М.В. Ломоносова в жизни изменилось не так много, как могло бы показаться. Ум в порядок приводить нужно всем, и тестировщикам в частности. Тестировщикам нужны и специальные инструменты. Аль-Капоне использовал револьвер и доброе слово, тестировщикам я бы предложил использовать математику и доброе слово. С помощью математики и доброго слова с разработчиками можно сделать много разных интересных вещей.

На самом деле интересный вопрос: почему мы не пользуемся математикой в нашей повседневной деятельности. Ответ прост – мы ее просто не любим. Простая статистика: возьмем запрос в Google “Я ненавижу …». И получим:
• 703 тысячи ответов: Я ненавижу «Звездные Войны»
• 701 тысяча ответов: я ненавижу математику
Математика уступает только Звездным Войнам! Неплохо, правда? Если эту ненависть несколько декомпозировать, то можно выделить три блокера, не дающие нам использовать математику.

Первый блокер – математика в тестировании это формальное доказательство правильности программ, которое плохо работает на практике. Эта область науки довольно хорошо развита и широко известна в узких кругах. Настолько широко, что сразу же приходит на ум многим тестировщикам, стоит с ними заговорить о математике в тестировании. Следующая мысль – «это слишком высокие материи, они не работают на практике». Так вот…

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

Второй блокер — для того, чтобы математические методы работали, необходимо составление подробных спецификаций. Тоже далеко не так. Вас никто не заставляет писать подробную спецификацию и доказывать, что программа работает правильно. Вам не требуется подробной математической модели всей системы, с которой работаете. Можно пользоваться математикой, как небольшим удобным инструментом.

Достаточно идей в голове и небольшого упорядочивания этих идей, т.е. аналитических способностей.

И самым известный блокер, это мысль о том, что

математика — это что-то очень сложное

Это неправда. Я своими глазами видел факультатив по математической логике для учащихся 5-го класса, ребята сидели и решали довольно сложные логические задачи. А вы, тестировщики, хуже пятиклассников? Мне кажется, что нет.

Если попробовать разобраться в том, как думают математики, то результат будет довольно интересным. Всем известный Дональд Кнут в свое время написал статью «Algorithmic Thinking and Mathematical Thinking» (http://www.jstor.org/discover/10.2307/2322871?uid=3738936&uid=2&uid=4&sid=21103388081621). В ней он выделил несколько типов мышления математиков – алгоритмического мышления и математического мышления.

Все эти типы мышления применимы и для тестировщиков:

• отражение действительности
В самом деле, вы своими тестами отражаете действительность, показывая, насколько правильно работает система.

• сведение к простому случаю
Все мы пытаемся писать тесты, чтобы они были максимально простыми и, при этом, отсутствовала необходимость их переусложнять.

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

• абстрактные рассуждения
Все мы строим некоторую абстрактную модель системы у себя в голове, а потом тестируем ее.

• изменяющееся состояние системы
Как минимум, у нас есть два состояния системы: все работает или все сломано. Обычно таких состояний несколько больше, и в ходе тестирования мы изменяем состояние системы.

Если эта таблица вас не убедила, можно посмотреть на результаты исследования И.Я. Каплуновича (Каплунович И.Я. Содержание мыслительных операций в структуре пространственного мышления // Вопросы психологии. 1987. №6), который занимается исследованиями в области психологии преподавания. В своих исследованиях он выделяет пять категорий мышления.

И.Я. Каплунович считает, что от нашего рождения и до момента математической грамотности, т.е. до момента, когда наши аналитические способности уже хорошо развины, проходит пять стадий. Начинаем с топологического уровня, где наши неупорядоченные мысли начинают укладываться в некоторую структуру. Двигаемся дальше, на четвертом уровне начинаем измерять, на пятом – оптимизировать.
Вам ничего это не напоминает? Правильно – пять уровней CMMI: первый уровень – только собрались, управляем. Второй-третий – добиваемся повторяемости и управляемости, четвертый – измеряем, пятый – оптимизируем. В самом деле похоже.

Если немного отвлечься от высоких материй, то можно сказать, что все идеи, которые выдвигают математики и хорошие инженеры – все они, по большому счету, созданы ленью.
Нам лень тратить много времени и долго решать задачи, поэтому мы садимся и придумываем что-нибудь интересное, быстро решаем задачу и начинаем заниматься другими задачами. Инженеры редко любят подход «Долго, дорого, скучно», математики тоже. В тест-дизайне лень отлично работает – мы можем лениться долго и со вкусом, а главное – результативно.
Давайте попробуем разобраться на нескольких примерах, кто, как и где может применять математику в тест-дизайне.

Начнем с самой очевидной области, с математической логики. С того как мы можем применять матлогику, чтобы оптимизировать покрытие кода нашей системы, не забывая при этом о том, что мы любим лениться. Вот небольшой пример: обычный «if» с двумя ветвями и длинная формула в условии.

Мой преподаватель по геометрии в десятом классе называл длинные-длинные формулы «крокодилами». Вот такой крокодил встретился у нас в коде. Для того чтобы покрыть обе ветви кода, нужно разобраться в структуре формулы, нужно разобраться, какие значения принимают переменные х1, х2, х3, х4. Можно, но как-то очень не хочется. Возникает вопрос: что мы можем сделать? Можно лениться непродуктивно и, забыв матлогику, протестировать этот код полным переобором. Получится 16 тестов. «Долго, дорого, скучно». Ну и просто не хочется.
Пытаемся уменьшить количество тестов – применяем MC/DC (11-12 тестов), решаем, что нам хватит покрытия по ветвям – получаем два теста…
А дальше – внезапно вспоминаем булеву алгебру. После преобразования исходного выражения получаем, что на значение истинности влияет только переменная x3. В результате мы получаем не только простой способ сгенерировать тесты (в однои x3 = true, в другом x3 = false), но и получаем повод пообщаться с разработчиком. Ведь это довольно странно, когда в коде есть довольно сложное логическое выражение, а на деле оно зависит только от одной переменной, возможно здесь где-то ошибка.

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

Попробуем разобрать следующий вопрос – состояние системы и тестирование изменяющихся состояний. Обычно состояний значительно больше, чем просто «работает» и «не работает», я несколько слукавил в начале выступления.

Например, ниже вы видите часть состояний, которые проходит биржевой ордер – заявка на покупку или продажу акций. Для того, чтобы сделка совершилась, заявка должна пройти несколько состояний. Сначала заявка создана, затем она подтверждается биржей, затем совершается множество мелких сделок на покупку и в конце-концов покупается или продается необходимое количество акций. Все состояния биржевого ордера отражаются в торговых системах, все переходы и состояния нужно проверять. На самом деле все несколько сложнее, но сейчас это не важно.
Обычно проверяются либо все состояния, либо все переходы, либо и то и другое вместе. Полное покрытие достижимо, но традиционно – «Долго, дорого, скучно». Попробуем облегчить себе жизнь и немного полениться. Как?


Вы наверняка слышали о задаче коммивояжера – задаче оптимизации на графах. Есть связанный с этой задачей алгоритм де Бройна.

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

Первые два пути достаточно короткие. Начинаем строить третий путь и получаем очень-очень длинный.


А теперь представим такую ситуацию. У вас есть три тестировщика. Первый выполняет первый тест, второй – второй тест, третий – третий тест. Первые двое заканчивают работу очень быстро, а вот последний сидит очень долго. А если это автотесты? Третий тест очень долго работает, результаты вы получается с большой задержкой.
Если применить алгоритм де Бройна, можно разрезать третью последовательность на несколько более коротких и хорошо распараллелить выполнение. Мы получаем пять тестов вместо трех, но при условии их параллельного выполнения, тестирование завершается намного быстрее.




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


Третий пример. Есть базовое понятие в тестировании – класс эквивалентности. Казалось бы, что можно здесь придумать нового?

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

Вполне реальный пример. Есть система, которая сохраняет в базу данных строки от 0 до 5 Мб длиной. В требованиях записано, что время на сохранение этой строки должно быть примерно одинаковым. Классический подход к тестированию дает нам три теста: пустая строка, строка 5 Мб и средняя строка в 2.5 Мб. Проверили, время сохранения одинаковое и укладывается в допустимую погрешность. Все хорошо.

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

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

Если применить теорию измерений, то можно сделать поиск аномальных зон более упорядоченным. Для получения базового предстваления можно воспользоваться хотя бы определениями из ГОСТ Р 50779. Термины, определенные в этом ГОСТе, можно использовать в качестве отправных точек для дальнейших поисков в спецлитературе и извлечь из теории измерений именно те знания, которые нужны именно вам.
Попробуем получить полезную информацию об аномалиях в нашем случае. Есть интервал с известными граничными значениями (минимум, максимум, середина). Есть некоторая неточная информация о том, что мы можем считать аномальной зоной. Строим функцию распределения вероятности того, что данное значение вызовет проблемы – например, что строка указанной длины будет сохраняться долго. Для примера возьмем нормальное распределение. Узкий и острый купол означает высокую уверенность в том, что эта зона аномальная, широкий купол означает низкую уверенность, например, в силу того, что у нас мало данных по этим значениям. Дальше начинаем применять выборочное тестирование и генерировать строки разной длины, «пристреливаясь». Там где купол более узкий «стреляем» тестами более кучно, там где более широкий – более широко, пытаясь нащупать более точную закономерность.

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

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

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

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

Но работает этот метод не всегда. Пусть наша система становится все сложнее и сложнее…

Сложнее и сложнее….

И становится сложной настолько, что начинает нравиться фанатам «Теории большого взрыва».

Хватит ли нам pair-wise для того чтобы хорошо оттестировать сложную систему с большим количеством входных параметров? Этот вопрос интересовал многих ученых и даже американский Национальный институт стандартов и технологий (NIST).

Под эгидой NIST существует проект ACTS, в рамках которого ведутся исследования в области комбинаторного тестирования. Согласно их исследованиям, pair-wise находит ошибки в 65-97% случаев. Если мы начинаем комбинировать не пары параметров, а тройки или четверки, т.е. использовать k-way тестирование, то мы получаем большее количество тестов, но и вылавливаем больше ошибок.

Используя знания о том, что на pair-wise свет клином не сошелся, мы можем выбрать устраивающий нас уровень покрытия и устраивающее нас количество тестов.
Здесь нам опять приходит на помощь математика, и мы можем воспользоваться результатами труда исследователей в проекте NIST ACTS.

Основа для pair-wise – это ортогональные матрицы, содержащие n-ки (пары, тройки, четверки, …) значений одинаковое количество раз.

Вместо ортогональных матриц в NIST предлагают использовать покрывающие матрицы (http://math.nist.gov/coveringarrays/coveringarray.html). Такие матрицы отличаются от ортогональных тем, что каждый набор значений встречается хотя бы один раз, а не «одинаковое количество раз». В данном случае тестов получается чуть меньше, в покрывающих матрицах могут образовываться некорректные тест-кейсы, но в целом само тестирование проходит значительно быстрее. На сайте NIST ACTS можно даже найти генераторы покрывающих матриц и уже рассчитанные матрицы для заданного количества входов и количеств их значений. Таким образом мы снова упрощаем себе жизнь при помощи математики, разобравшись один раз в комбинаторном тестировании и продолжая лениться.

При использовании покрывающих матриц можно уйти от pair-wise к k-way, не сильно увеличивая количество тестов.
Таким образом, мы поговорили о совсем небольшом наборе математических методов, которые можно сравнительно легко использовать при тестировании. В некоторые из них можно даже не погружаться очень глубоко.

На этом заканчивается та часть выступления, которая предназначена для инженеров по тестированию. Но тестирование на этом не кончается, есть еще и тест-менеджмент. Есть там и своя математика.

В тест-менеджменте очень много разных областей и везде можно найти нужные и полезные математические методы. Есть даже несколько ярких представителей российского IT-сообщества, всячески продвигающих математику.

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

Дабы не уподобляться герою с картинки, стоит все же иногда впитывать те знания, которые вам дают в университете. Далеко не все из них – ненужный хлам, есть там и что-то полезное. Запоминайте хотя бы названия, потом почитаете, когда понадобится. Ну и не забывайте приводить ум в порядок – структурированное сознание – превыше всего.

Структура знаний в области Software Engineering – достаточно хорошо проработанная тема. Например, в США существует две крупных организации. Одна из них – это ACM, Association for Computing Machinery. Она занимается публикациями результатов исследований в области Computer Science и Software Engineering, организует интересные конференции, так или иначе связанные с теоретическим IT, является учредителем премии Тьюринга – аналогом Нобелевской премии для IT-исследований.
Помимо всего прочего, ACM публикует т.н. Curricula – высокоуровневые учебные планы, которые содержат информацию о том, чему надо учить студентов IT-специальностей, и что они должны знать на выходе из университета. Так, на слайде приведен набор математических дисциплин, необходимых для хорошего IT-специалиста. Обратите внимание на то, что там присутствует математическая экономика. Со временем вы, как тестировщики, начнете задумываться и об экономической составляющей тестирования – сколько оно стоит, что выгоднее – тестировать или нет. Здесь вам придут на помощь остаточные (или не остаточные) университетские знания.

Вторая крупная организация, которая выдает рекомендации, что должен знать выпускник – IEEE – Institute of Electrical and Electronics Engineers. Они публикуют Своды знаний (Body of Knowledge), в том числе Software Engineering Body of Knowledge, третья версия которого на момент доклада была в состоянии беты. В этом документе выпускнику университета рекомендуется уже несколько больший набор математических дисциплин.

Образование в области тестирования не ограничивается университетами. Можно обучаться и самому. Например, подготовиться к сдаче сертификационных экзаменов Quality Assurance Institute – там чуть больше базовых и теоретических вещей, чем в экзаменах ISTQB. Можно (и нужно) следить за международными конференциями по тестированию. Например, на конференции ICST очень хорошее сочетание теоретических и практических докладов. Есть www.arxiv.org – здесь всегда можно найти свежие статьи в самых разных областях, в числе и относящиеся к исследованиям в области тестирования. На scholar.google.com тоже всегда можно найти что-то интересное. Учиться можно и нужно всегда, главное постепенно учиться искать нужную информацию.

Если учиться (а может быть даже и учить) понравилось, то можно подумать и над тем, чтобы сделать исследования своим основным занятием.

Для этого в первую очерень надо ответить на вопрос «зачем?”. Ответ на этот вопрос у всех разный, но отвечать на него нужно, чтобы не потерять интерес к исследованиям.

Уходя в науку, вы обычно выбираете себе направление исследований, то, что вас заботит больше всего. Для меня в свое время любимой темой стало управление конфигурациями и методы оценки состояния разработки программных систем. Ваша любимая тема может быть совсем иной. Но если вы еще не знаете чем заниматься – посмотрите, про что пишут коллеги. В науке тоже есть своя мода – мода на исследования. Так, например, в конце 2012 года на одной из американских конференций были назаны наиболее популярные темы для исследований, приведенные на слайде ниже.


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

Интересные исследования ведутся и в России, несколько фамилий приведены на слайде выше, я тоже пока не потерял интереса к исследованиям.
Ниже приведены ссылки, где можно посмотреть документы, на которые я ссылался.

Отдельное спасибо хочу сказать создателям Футурамы и Теории большого взрыва, как за иллюстрации, так и за возможность наблюдать за героями в течение нескольких лет.

На этом мой доклад завершен, я готов ответить на ваши вопросы.

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

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

Вопрос.
А откуда вы взяли эти точки, когда тестировали нагрузку?

Ответ.
Была статистика проблем с производительностью из данных реальной эксплуатаци, плюс были некоторые экспертные оценки того, на каких параметрах система может начать падать.

Вопрос.
Есть ли у тебя какая-то статистика по тому, где и насколько широко применяются в компаниях те методы, о которых ты рассказал?

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

Вопрос.
У вас был слайд о диаграммах состояний системы. У вас были состояния, которые вы условно назвали плохими и, используя эти новые состояния, возможно придется все полностью переписать или нет?

Ответ.
Здесь все зависит от того, как мы пользуемся алгоритмом. В самом крайнем случае мы можем ничего не знать, о том, какая логика стоит за переходами между состояниями. В этом случае длинная цепочка переходов будет разрезана алгоритмом на несколько коротких, часть из которых может оказаться бессмысленной. Именно поэтому те цепочки переходов, которые получены после разрезания, нужно оценить на разумность и выбрать именно те, которые важны для тестирования. Бессмысленные (но возможные) пути изменения состояний системы могут привести нас к пониманию, что нужно часть системы переписать.

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

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

ссылка на оригинал статьи http://habrahabr.ru/company/sqalab/blog/217743/

Традиционный пост к Первому апреля

Как водится, запускаю собирательный пост про найденные на просторах сети первоапрельские шутки.
В Новосибирске часы перевалили за полночь, и главный новостной портал города предложил перейти жителям на подножный корм. А какие нововведения обнаружили вы? Оставляйте в комментариях, тема будет дополнена в течение дня.

ngs.ru предлагает есть мышей и тараканов:

ссылка на оригинал статьи http://habrahabr.ru/post/217739/

Чего я хочу от инструментов разработки требований. Затычки, костыли и грабли СУТ

Публикуем доклад Печенкина Григория с предыдущей конференции Analyst Days 2013.

Аннотация:

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

Видео доклада:

Презентация:

www.slideshare.net/VLDCORP/ss-21934097

Вступление

Мы рассмотрим затычки, костыли и грабли систем управления требованиями (СУТ) для того, чтобы понять, чего я хочу от систем управления требованиями. В начале сделаю 2 объявления.
В одном из анонсов доклада, который предварительно рассылался, говорилось о том, что будет сделан фундаментальный обзор СУТ. Обзора не будет. На самом деле была такая идея: несколько реальных задач СУТ пропустить через несколько систем, но когда я за это взялся, то понял, что сильно переоценил свои силы (позже я скажу, почему). Хорошая новость в том, что у меня есть, куда вас послать :).

В прошлом году в Киеве проходила конференция REQ Labs, где отлично была реализована идея: аналитические поединки. На конференции присутствовали три эксперта, которые, в отличие от меня, хорошо знают СУТ, потому что они постоянно ими пользуются и проводят тренинги. В процессе работы конференции перед экспертами ставилась реальная задача работы с требованиями, и они демонстрировали, как это делается в разных системах. Было предложена работа с тремя системами: RequisitePro, Enterprise Architect, Sybase PowerDesigner. Если этот вопрос кого-то заинтересовал, видеозапись есть на сайте компании REQ Labs (http://www.req-labs.ru/conf2012/agenda/530/).

Второе объявление (см. скриншот 2 презентации) уже относится к анонсу, который я напечатал в программе.

А именно, я написал, что аналитики самый угнетенный класс среди IT-специалистов, потому что у них нет хороших инструментов. Но в процессе написания доклада я понял, что у аналитиков наоборот, слишком много хороших игрушек, в которые никто больше просто не хочет играть. Проблема в этом, и о ней сейчас будет вестись речь. Я расскажу, почему возникла идея доклада, и какая проблема возникла перед аналитиками.
Я не являюсь профессиональным аналитиком. Я был программистом, потом менеджером, сейчас моя должность называется – аналитик – и, получается, я с чистой совестью могу сказать, что стал аналитиком. Но был период, когда я раз в год менял работу. Работал в трех разных местах. В одной компании я работал техническим директором. Компания была небольшая, всего пять человек. В другой компании – она была больше и состояла из тридцати человек – я руководил направлением. Сейчас я работаю на проекте по разработке банковской системы. И каждый раз заказчик (работодатель) передо мной ставил проблему внедрения системы управления требованиями (СУТ) и требовалось выбирать, какие инструменты использовать. Статья посвящена именно теме, с какими проблемами мне пришлось столкнуться, и выводам, к которым я пришел в процессе данной работы.
В основном на проектах пользуются такими СУТ: Excel Word, Polarion, Enterprise Architect, TFS, Wiki, Caliber, Jira.

Во многих компаниях до сих пор используется пакет MS Office для разработки и управления требованиями. К тому же, сейчас все больше распространяется Sharepoint, т.к. он позволяет внести некоторый порядок в хаос документов Office, плюс есть возможность вести версионный контроль и сравнение. Данная система позволяет на базе существующих наработок компании, которые они вели до этого в Word и Excel, организовать что-то похожее на СУТ. И плюс добавляют к этому веб-интерфейс, в котором можно программировать (сейчас, я знаю, программисты Sharepoint являются самыми востребованными и самыми высокооплачиваемыми, и если вы не знали, то рекомендую изучить эту программу на всякий случай). Рассмотрим и другие системы.

Средства визуального моделирования

У всех на слуху программа Sparx Enterprise Architect, который позволяет моделировать всё, что угодно. Специализированные средства разработки – IBM Rational RequisitePro, есть и другие. Перечисленные инструменты предназначены именно для разработки требований.
Есть также инструменты командной работы – ALM (Application Lifecycle Management). Сейчас очень активно набирает популярность MS TFS (Team Foundation Server). Я сам его очень люблю и работаю с ним постоянно. Это разработка компании Microsoft — система управления «всем» в команде, другими словами, инструмент командного взаимодействия.
Средства Wiki также набирают популярность. Wiki обычно интегрируют с task-tracker’ами, самой распространенной из которых является система Jira. Я работаю в компании, где используется средство Confluence Wiki в связке с TrackStudio. Есть еще варианты, например MediaWiki с Bugzilla.
На самом деле, что из этого списка предназначено для управления требованиями? Чтобы ответить на этот вопрос, нужно ответить еще на один вопрос: в чем разница между разработкой и управлением требованиями.

Разработка или управление

Вы, наверное, слышали о модели зрелости CMMI (Capability Maturity Model Integration). В данной модели управление требованиями относится ко второму уровню, а разработка требований – к третьему уровню, т.е. разработка требований – это процесс более высокого уровня, соответствующего более зрелому процессу в компании.
На самом деле, это вообще разные процессы. Разработка – это то, чем занимаются аналитики (или люди, которых обычно называют аналитиками). А управление – это то, чем обычно занимаются менеджеры: взаимосвязь требований с разными рабочими артефактами: тест-кейсы, задачи, код, и др. В конечном итоге, они увязывают всё, что разрабатывает команда, с требованиями. На их основе отслеживаются статусы, трассировки и т.д.
С моей точки зрения, все эти процессы неразделимы (хоть и в CMMI это не совсем так). Проблема в том, что для аналитиков создаются инструменты именно для разработки требований, а для остальной команды – инструменты для управления требованиями. В попытке их состыковать и происходят проблемы. Прежде чем мы перейдем к аналитике, давайте определимся с терминами: грабли, костыли, затычки.

Определения

Что такое «грабли»? Граблями я называю какие-то элементы, унаследованные из других отраслей, применение которых создает проблемы. К примеру (этот пример сейчас не очень актуален, но 10 лет назад, когда все разработки велись в Word – это было очень актуально), требованиям присваивается какой-то идентификатор (средствами Word в тексте), на который мы в другом месте ссылаемся, потом изменяем исходный текст, вследствие чего меняется и номер, и дальше вся структура связей ломается. Надеюсь, что у вас нет таких проблем.
На текущий момент базы данных справились с этой проблемой: более или менее. Все мы знаем, что идентификатор присваивается сейчас по-другому. Этот случай я привел в качестве примера граблей. На самом деле, в других отраслях такую идентификацию используют и сейчас: юристы, бухгалтера, когда оформляют договор, потом к нему дополнительное соглашение, которое ссылается на какой-то пункт договора. Или, например, выходит Закон или изменения к Закону, ссылаясь на определенный пункт к Закону. В реальном мире это работает, но попытка применить это в IT – это перенос старого опыта или грабли, на которые кто-то наступил и наступает вновь.
Что такое «костыли»? Это очень распространенный термин в IT – подпорки или временные решения. Как пример, любая интеграция одной системы с другой является костылем: одна система не способна что-то решать, другая система тоже не может делать что-то, и для того чтобы их сынтегрировать, приходится строить костыли.

Что такое «затычки»? Затычки возникают в случаях, когда программа должна выполнять определенные действия сама, но перекладывает эти действия на вас. Очень распространенное явление. Все юзабилити состоит из затычек. Существует даже анекдот про «узбекский вирус».

Анекдот. По электронной почте к вам приходит письмо, в котором написано: «Здравствуйте, я «узбекский вирус». Мой разработчик не успел меня дописать, поэтому, пожалуйста, отправьте меня по всей адресной книге и отформатируйте диск С. Спасибо.»

Многие программы ведут себя именно так, но мы просто к этому привыкли и даже не обращаем на это внимания. Итак, я дал определения терминам, продолжим дальше тему.

Как требования разрабатываются сейчас

Я предлагаю рассмотреть пример проекта, над которым работаю в данный момент, – это проект внутренней разработки. Я разрабатываю требования в Confluence Wiki (после того, как не смог выбрать нормальный инструмент в рамках своего исследования).
Для примера я выбрал достаточно примитивный старый вариант. Для разработчика я даю такую страничку: контекст в составе диаграммы вариантов использования инструмента (для того чтобы они понимали, для чего этот проект создается). Потом текстом описываются какие-то конкретные требования.

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

Опыт показал, что вот такая страничка для разработчиков – это нормально. Они понимают, что они делают панель, которая будет выглядеть примерно так (в примере предложен не реальный интерфейс, а прототип), перечислены фактические требования, что они должны сделать, и некоторые контекстные представления в виде диаграммы.
Конечно, возникает вопрос: «В какой программе, кроме Wiki такое представление можно сделать еще?» Word мало чем отличается. Но позже вам станет понятней, почему я выбрал именно Wiki.

Участники процессов управления требованиями

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

1. Аналитик хочет вводить требования в виде текста

Хочу обратить внимание, что не все аналитики хотят разрабатывать требования в виде текста – в данном случае это мое личное предпочтение. Большинство аналитиков с текстом работать не любят и предпочитают работать с визуальными моделями, особенно те, кто работает в Enterprise Architect. Объясняю, почему мне удобней работать в виде текста: в таком виде мне удобней работать с командой – они понимают контекст.

2. Разработчик хочет понимать контекст

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

Текст или база данных?

Есть противоестественный способ представления информации – это база данных. Нужно отметить, что СУТ появились только тогда, когда появились базы данных, где можно разложить все по полочкам и отслеживать жизнь каждого элемента. Но вот здесь и противоречие: люди работают с текстами, а хранить их нужно в базе, приводит многих к легкой шизофрении.

Поэтому в большей части СУТ склоняются к текстовому представлению СУТ, как это организовано в Wiki и Word, т.к. они работают с текстами, а системы профессиональные чаще склоняются к базам данных.
К чему это приводит? Допустим, мне нужно добавить требование. То, что я сейчас расскажу, многие из слушателей воспринимают, как что-то естественное, потому что других способов не знают. Когда вы создаете новое требование, вас просят ввести его в диалоговое окно. На слайде представлено диалоговое окно из Enterprise Architect, потому что он не ориентирован на работу с текстом и там это может быть оправдано.

Диалоговые окна

Следующий скриншот из TFS, здесь иначе. У меня был знакомый, привыкший работать в Word, который категорически отказывался работать в TFS-системе. Эта система позволяет использовать разные шаблоны проектирования (Scrum, MSF): появляются требования, баги, change request, и др. В каждом случае свой жизненный цикл.
А в чем смысл? Когда ставится шаблон по умолчанию, там каждый вновь созданный артефакт имеет статус proposed. Я не знаю, зачем это было сделано, наверное, с точки зрения CMMI это было нужно. Суть в том, что когда человек добавляет новое требование, ему нужно еще раз зайти в диалоговое окно и еще раз поменять статус. Таким образом, он в диалог заходит два раза (конечно, шаблон настраивается и это можно убрать). Суть в том, что нужно каждый новый элемент вводить в диалоговое окно, а некоторые системы еще заставляют все атрибуты ручками выставлять – это своего рода барьер для внедрения СУТ.

3. Аналитик не хочет делать ничего лишнего

Я не хочу вводить каждый абзац в отдельном окне (а тем более повторять одни и те же действия для каждого из них). Я не хочу вручную выставлять все статусы и постоянно переключаться между мышкой и клавиатурой (всем известен синдром запястного канала). Это всё выбивает аналитика из потока.

Надеюсь, что слушатели понимают, о чем я говорю. Когда ты сидишь и генеришь поток из текста требований, а тут: создал окно, мышкой двинул, потом еще раз и т.д. Это очень мешает работать и очень утомляет. Поэтому я считаю, систему диалоговых окон одним из примеров затычек, когда система на вас перекладывает свое внутреннее устройство: вот у меня есть база данных и изволь каждую запись сохранять отдельно.

4. Аналитик хочет включать в требования визуальные модели и изображения

Еще один пример. Я считаю мощнейшим средством представления требований – визуальные диаграммы. Без этого просто никак не получается.

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

Смысл в том, что для того, чтобы картинку с требованиями вставить в Wiki, мне приходится сначала ее экспортировать в какой-то файл jpg-png-bpm и т.п., и только потом вставить его туда. И я всегда еще (вдруг у кого-то возникнет желание поменять что-то без меня) туда вставляю ссылку на использованное средство и ссылку на файл. По-моему опыту, ни у кого и никогда не возникает желание установить программу, чтобы поменять картинку. На самом деле таких программ на удивление много.

5. Аналитик: не хочу выполнять экспорт моделей в jpg-png-bmp-итп

Он не хочет запускать руками свои редакторы и хранить модели в отдельных файлах.

И если вы работаете с Wiki, то вам приходится в таком виде вставлять изображения. Это огромная проблема. Я не хочу, как аналитик этого делать. Я не хочу запускать другие редакторы. Я не понимаю, почему это не реализовано в среде разработки требований. Это прекрасно реализовано в MS Office, когда вы рисуете диаграмму в Visio, а потом вставляете ее в MS Office, после чего вы ее тут же можете править, не выходя из Word.
Другими словами — это костыль.

6. Аналитик — не программист и не хочет описывать картинки в виде кода

Другой вариант интересен для тех, кто разрабатывает требования в Wiki (Media Wiki, и др.). Для них будет понятен следующий скриншот. Это плагины к Wiki, которые позволяют создавать диаграммы в виде текста или в виде рисунка: PlantUML – более простой плагин и позволяет рисовать обычные диаграммы, а GraphViz – более широкого назначения, там есть возможность рисовать любые диаграммы, но язык программирования более сложный (похожий на ассемблер). На самом деле это очень удобная программа с точки зрения представления информации. Вы можете менять свои диаграммы, не используя какое-то внешнее средство, более того, вы можете отслеживать изменения (это теоретически, потому что практически я ни разу не видел, чтобы это было сделано).

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

Вообще это можно рассматривать по-разному. Можно рассматривать как затычку, потому что я не вижу никаких проблем, почему нельзя сделать редактор непосредственно на вебе. Его можно рассматривать и как костыль, потому что я хочу в Wiki включать изображения и диаграммы, но у меня нет других средств, и приходится пользоваться этим.

Кто-то помнит, что такое OLE?

Когда появился Windows 3.0 или Windows 95 и OLE продвигалась компанией Microsoft именно как возможность встраивать один документ в другой: как я уже сказал, создаем диаграмму в Visio, потом вставляем в Word и далее редактируем уже в Word. Я до сих пор не понимаю, почему в WEB нет такого стандарта. Что-то есть в Word, что-то есть во Flash, но единого способа нет. Вы понимаете, о чем я говорю? Вы заходите на веб страничку и прямо на ней редактируете и что-то рисуете. У меня большие надежды на HTML5, потому что там уже появлялось что-то до этого, но опять же не понимаю, по каким причинам это еще не стало мейнстримом.

Существует сервис draw.io, который позволяет это делать очень удобно и красиво, но при этом диаграммы хранятся на их сервере, вы их можете вставить в свои странички, но не у себя. Возможно, это скоро изменится. Именно поэтому сейчас Microsoft Office так популярен – там все эти проблемы интеграции решены давно и удобно, и, кроме того, существует множество наработок.

7. Аналитик хочет знать, что изменилось в требованиях и моделях

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

Я не хочу запускать сторонние программы, а сравнивать двоичные файлы бессмысленно. Что нам предлагают собственно системы управления требованиями, которые я упоминал вначале? Все, кто презентует СУТ, считают своим преимуществом экспорт в Word. На это есть несколько причин, это очень востребовано, в том числе потому, что Word позволяет сравнивать тексты.

С картинками вообще все плохо. Если необходимо сравнить две картинки, то вам нужно решать задачу «Найди 10 отличий» – т.е. сравнивать визуально. Других способов нет.

8. Аналитик хочет обсуждать требования так, чтобы результаты обсуждений всегда были под рукой

Аналитику приходится обсуждать требования. Самые привычные способы — в Word и по почте. Еще можно собрать совещание или распечатать на бумаге и поехать к нему в гости с пачкой бумаг.
Это всё достает. Я не хочу таскать пачки. Я не хочу никуда ехать. И кроме того, я хочу в процессе обсуждения вносить правки.

Такую возможность предоставляет Wiki.

9. Аналитик не хочет тягать с собой пачки бумаги и не хочет никуда ехать

Он хочет вносить изменения в требования прямо в процессе обсуждения.
У нас на летнем аналитическом фестивале (www.lafest.ru), который я все время рекламирую, выступала технический директор фирмы Human Factor Labs Елена Журавлева. Она рассказывала, как они ведут требования в Confluence. У них заказчики очень разные, в том числе и государственные, в том числе и крупные банки. И когда я пытался выпытать у нее, как же они экспортируют все это в Word, чтобы с ними согласовывать. Она сказала, что они ничего не экспортируют, а берут страничку и они (заказчики) сами с ней работают.

Люди к хорошему привыкают очень быстро. Главное, чтобы им кто-то показал это хорошее, но, к сожалению, наша система управления требованиями, кроме Word и Wiki, специально настроенная, этого делать не умеет. Что мы используем? Единственный способ – по почте.

Я взял картинку из Интернета, т.к. свою не смог — там слишком много конфиденциальной информации. Что видим: начинают вносить комментарии к каждому слову, в каждой строчке. Все это быстро вырастает в разноцветную «лапшу». Один абзац и к нему пятьдесят комментариев от разных специалистов. Потом что делает аналитик? Перечитывает все это, выбрасывает и как-то переписывает. Т.е. все эти обсуждения – костыль.
Или второй вариант, который еще хуже. Едет к заказчику, где все обсуждает, зачеркивает на бумаге. А потом с этим возвращается в офис, обрабатывает и выбрасывает, потому что с тем, что было по результатам обсуждения, работать невозможно.

10. Аналитик хочет связывать требования друг с другом

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

Иерархия в моделях

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

Матрица трассировки

Посмотрите на следующий скриншот. С этим кто-нибудь работает? Да, для планирования тестирования, отслеживания изменений.

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

11. Разработчик хочет знать, какие требования ему нужно реализовать, а менеджер проекта — какие требования еще не реализованы

Мы говорили об управлении требованиями, а именно о связывании требований друг с другом. Это один момент. Но вся мощь системы управления командной работой заключается в том, что она позволяет связывать разные артефакты. Разработчик видит, какие требования ему нужно реализовать в зависимости от поставленных задач. Менеджер проекта хочет знать, что там осталось в проекте невыполненного и хочет знать (это особенно актуально, когда много клиентов), что уже установлено у заказчика. Сначала вы посылаете ему версии из разных веток, а потом приходят запросы, и вы пытаетесь понять, что у него уже есть. В частности, в банковской сфере я постоянно с этим сталкивался: нужно определить, какие требования в текущей версии у клиента уже реализованы, а какие нет. СУТ позволяет на этот вопрос ответить.

12. Тестировщик хочет знать, какие требования не протестированы

А тестировщику нужно знать тест-кейсы, которые ему осталось выполнить.

В этом и состоит задача СУТ: все процессы построены вокруг управления требованиями, когда требуется отследить те самые связи между артефактами.
Лучше всего это сделано в TFS, который позволяет связать что угодно, с чем угодно, каким угодно способом, но при этом интерфейс выглядит вот так.

Связи между артефактами

Т.е. если вы хотите связать одну сущность с другой, вам нужно ввести ее номер. А 2 цветных блока в нижней части окна они глумливо называют визуализацией. Т.е. TFS как-бы говорит: у нас, знаете ли, реляционная база данных, поэтому все реляции опишите ручками. Это не нормально.
Например, в программе Enterprise Architect это реализовано визуально: у вас есть два квадратика и вы протягиваете между ними стрелочку.
Это затычки, причем та самые, которые ведут себя, как «узбекский вирус». С одной стороны, есть богатая возможность установки производных связей, а с другой стороны, слабый интерфейс создания таких связей.

13. Заказчик хочет, чтобы его требования были поняты правильно

Он хочет знать, что сделано с его требованиями.

Мы уже говорили о согласовании требований.

Я постоянно это повторяю.

Для того чтобы общаться с заказчиком, мы постоянно используем экспорт в MS Office, потому что мы считаем, что заказчик дурак (хотя иногда это действительно так), но в целом, это приводит к проблемам. Это сигнал о том, что хватит использовать затычки.

Итог: какой инструмент использовать?

В общем, я всё вышесказанное представил как диаграмму вариантов использования СУТ, чтобы подытожить тему разговора. На самом деле вариантов может быть гораздо больше.

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

Смотрим варианты.

Знаете, что это? Это продукт Rational (инструмент управления требованиями IBM Rational RequisitePro, картинку взял из Интернета), предназначенный для всего: для тестирования, для требований. Проще говоря, как в поговорке: коготок увяз – всей птичке пропасть. Все они интегрированы между собой, кое-что интегрируется и с чем-то другим (но это, в нашем случае, грабли).
Есть еще один вариант – Confluence (программа Atlassian Confluence) – магазин плагинов: возьми кубики и собери то, что тебе нужно.

Подытожим проблему.

Команда хочет использовать игрушки аналитиков

Интересно, удавалось кому-нибудь загнать программистов в Enterprise Architect с моделями работать? Чем все закончилось? Конечно, программисты бывают разные.
Но что я хочу сказать: обучить всю команду инструментам, предназначенным для аналитиков – не правильный подход. С другой стороны, если мы попытаемся загнать аналитика в TFS – как вы помните, он может работать только с текстами. Значит, пропадает вся связь с визуальными диаграммами и возникает проблема связей, о которой я говорил.

Хотя есть опыт лаборатории Касперского – они соединили TFS с Enterprise Architect, но это на самом деле мало, кто может себе позволить, т.к. в данном случае получается очень дорогой проект.
Известно, что интеграция всегда получается уникальной и аналитик не может перенести свой инструментарий в новый проект. У нас в компании, например, на поддержке связки Confluence с Track Studio работает специальная команда, которая называется «Группа поддержки корпоративного портала», где человек пять и это самые квалифицированные специалисты. Т.е. это дорого обходится.

Мечты

В качестве итога хочется помечтать. Хорошо бы взять все лучшее из всех инструментов и свести все в одном инструменте.

Я попытался создать оптимальную систему требований к документам. Точнее, данные требования к системе родились в клубе системного анализа.
• Генерация документов в разных форматах
• Совместная удалённая работа
• Учёт влияния и трассировка
• Версионный контроль
• Интеграция с инструментами моделирования
• Внешние надстройки

Однако, в процессе работы над своим докладом я эти требования исправил.
Требования к системе документирования разработки и управления требованиями
Генерация документов в разных форматах Удобное для всех представление требований
• Совместная удалённая работа, в том числе с заказчиками
Учёт влияния и трассировка Связанность моделей и артефактов
Версионный контроль Отслеживание изменений
Интеграция с инструментами моделирования Встроенные инструменты моделирования
Внешние надстройки Готовность к использованию из коробки

И хочу показать, что получилось.
1. Ввод требований
Вот я ввожу текст в Confluence. Почему я должен вводить данные в какую-то форму? Можно же машину это делать.

Исходя из форматов вводимых требований, машина сама должна раскладывать записи в базу данных. Пусть тут будет возможность коррекции, если я считаю, что она что-то сделала неправильно, я нажму Backspace, и она уберет запись. Похожие системы есть: Rational RequisitePro (в качестве средства ввода текста здесь использует MS Word) – здесь требования набираются в виде текста, которые попадают в базу данных с граблями и косяками, что даже на демонстрации видно. Технических проблем это реализовать я не вижу.

2. Установка иерархии и взаимосвязей
После ввода текста система сама должна строить связи исходя из структуры. Понятно, что потребуется создать макет связей, шаблон. Я по шаблону в Confluence ввожу требования, а в базу данных запись попадает сразу со всеми связями, как показано на диаграмме скриншота. Я не вижу в этом никаких проблем. Конечно, это надо программировать.

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

Почему веб?

4. Отображение изменений
Если мы уж храним диаграммы в виде записи в базе данных, как правило, запись хранится в XML. XML – это текст, откуда мы всегда можем вычленить все изменения. Почему это нельзя показать на диаграмме я не понимаю. Пример: на скриншоте показаны две версии диаграммы, где я сразу могу показать, что изменилось в последней модели, по сравнению с предыдущими версиями.

5. Согласование с заказчиком
Спрашивается, а зачем вообще нужен текст? Но идея в том, что мы оставляем текст в качестве основного способа ведения требований. Давайте работать с этим текстом и дайте такую возможность заказчику: пусть он смотрит требования и ставит в пунктах, где согласен: like (пусть «лайкает»).
На самом деле это очень удобно. Вместо того чтобы ехать к нему с распечаткой требований в Word, вы даете ему вот такую страничку в Wiki. У него свой интерфейс для работы с текстом и он отмечает: согласовал – не согласовал. Если нужно обсудить – пожалуйста, отметил, что нужно обсудить и тут же обсуждаем. Как это выглядит в современных средствах управления требованиями в TFS? Длинные и скучные обсуждения.

6. Средство для менеджеров

С текстом можно делать всё, что угодно. Понятно, что можно настроить представление в зависимости от того, кто смотрит. Например, для менеджеров проектов.

Сначала он назначает, в какой релиз это требование пойдет, а потом следит за изменением статусов. Таких примеров можно привести много.

7. Создание связей.

Что такое создание связей? В данном случае я попытался продемонстрировать, как требования создать с тестовыми сценариями. Т.е. тестировщик работает с контекстом требований (в текстовом виде) и тут же может создавать необходимые связи (они сразу же ложатся в базу данных).
Понятно, что для этого нужна хорошо проработанная модель изначально. Иногда нужно связать что-то с чем-то, чтобы в конечном итоге ваш проект не страдал.

8. Визуализация связей

Данную картинку я взял из Интернета. Смысл ее вот в чем: вместо того, чтобы, как в TFS, все реляции забивать руками, связи показывать визуально.

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

Т.е. я хочу инструмент для всей команды, но так все, чтобы все, что наработано в других игрушках аналитиков, было удобно и для него. С моей точки зрения, все предпосылки для создания такого инструмента есть. Как только такой инструмент появится, он сразу, по-моему, получит высокую популярность. Может быть, они уже и появились, тогда скажите о них. (Данная избушка на скриншоте символизирует, чтобы веб повернулся к аналитикам лицом).

На этом все. Спасибо всем.

Встретить Григория можно на следующей конференции Analyst Days в Москве 24 мая.

ссылка на оригинал статьи http://habrahabr.ru/company/sqalab/blog/217737/