Стандартная ситуация: выдается задание на анализ объекта (документа, программы с документацией, программы как черного ящика, интернет-сервиса, процесса) - необходимо сформулировать цели и критерии анализа, этот анализ провести (либо четко поставить задачу специалистам), результаты интерпретировать и донести в понятной форме заказчику.
В такой работе много сложностей и подводных камней: объект объемен, сложен, не описан, ведет себя недетерминированно. С ними придется бороться, однако и сама работа аналитика зачастую порождает новые проблемы: генерация больших объемов текста в результате "копания" без четкого виденья цели , перелопачивание описаний объекта исследования с генерацией собственных описаний не интересных ни инженерам (они и так это знают) ни специалистам-исследователям (для них слишком мало информации, она не трассируется на исходный объект) может "съесть" массу времени. Кроме того сам аналитик по ходу исследования может начать ходить по кругу - в ситуации когда в системе сотни компонентов и необходимо выделить и классифицировать все их возможные воздействия друг на друга - типичная общая задача в анализе безопасности систем.
Как начать решение таких задач, какой выбрать инструмент? Очевидно текстовое описание слишком тяжеловесно и трудно модифицируемо при последующих уточнениях. Точное описание в машиночитаемом виде - отличная промежуточная форма, но начать её делать сразу - не всегда хватит отваги. В этот самый момент отчаянья нужно расслабиться и попробовать сформулировать задачи, знания об объекте в виде который будет легко воспринимать не только погруженному в "раскопки" аналитику, но и заказчику, а также всем заинтересованным лицам.
Структурная диаграмма (structure) - отображение частей целого, разделения на компоненты. Удобна для именования компонентов, выделения схожих и однотипных компонентов (можно выделить формой и цветом). На этой диаграмме можно обозначить взаимосвязи (каналы взаимодействия) между системами и компонентами, но нужно стараться не перегрузить информацией. Если сделана удачно - видно, например, как распланировать работы параллельно, либо - какие компоненты могут быть исключены из рассмотрения.
Иерархическая диаграмма (hierarchy) - она же организационная (часто полезна для представления плана коммуникаций в проекте, анализа подчиненности заинтересованных лиц). Альтернативные варианты применения - простой вариант объектной модели (дабы не забивать голову не-программистам) - дабы подчеркнуть степени уточнения методов, или наличия информации о свойствах у объектов описанных более детально.
Блок-схема (flowchart) - описание действий, позволяет удобно отделить основной сценарий от альтернативных, отобразить циклические операции, точки принятия решения. Казалось бы - тривиальный инструмент, в крови у программистов со средней школы, но как показывает практика для специалистов-гуманитариев не очевиден и может ускорить процесс разработки, например, шаблонов договоров.
Диаграмма последовательности (sequence) - элемент uml, удобный и весьма полезный и вне унифицированного языка моделирования. Крайне удобен для отображения обмена между несколькими сущностями (собственно выявления упущенных сущностей в цепочке передачи- например нарушителя ИБ), перечисления элементарных сообщений для последующего анализа - что может пойти не так если его не случится, оно будет модифицировано, задержится и т.д. Крайне удобный метод отображения сетевых протоколов и аналогичных концепций.
А как же mindmap? - соглашусь, удобный инструмент на этапе начального сбора информации, когда ее нет в явном виде, либо при мозговом штурме - выработке плана действий, но в целом, в классическом виде - это скорее промежуточный инструмент, удобный для работы в команде, но не вне её - "не разогретому" читателю без помощи создателя, "непричёсанный" майндмэп будет фрустрировать. Если конечно мы не говорим о стилизации под майндмэп - вот классический пример майндмапа доведенного до структурного, упорядоченного списка (структурной диаграммы), т.е. по сути майндмапом уже не являющимся. Можно сравнить с также аккуратным и структурированным, но не столь упорядоченным вариантом.
Остались за кадром более специфичные и "узкие" инструменты - gap, fishbone, gant, pert, представления характерные для анализа данных - графики, а также способы представления текстовой информации в структурированном виде - таблицы, outline. Если решаемая задача выглядит как очевидно удобная для их применения - стоит попробовать, вероятно затраты на объяснения принципа диаграммы на совещании окупятся в дальнейшем, не стоит разве что изнурять заказчиков десятками различных типов представлений.
В такой работе много сложностей и подводных камней: объект объемен, сложен, не описан, ведет себя недетерминированно. С ними придется бороться, однако и сама работа аналитика зачастую порождает новые проблемы: генерация больших объемов текста в результате "копания" без четкого виденья цели , перелопачивание описаний объекта исследования с генерацией собственных описаний не интересных ни инженерам (они и так это знают) ни специалистам-исследователям (для них слишком мало информации, она не трассируется на исходный объект) может "съесть" массу времени. Кроме того сам аналитик по ходу исследования может начать ходить по кругу - в ситуации когда в системе сотни компонентов и необходимо выделить и классифицировать все их возможные воздействия друг на друга - типичная общая задача в анализе безопасности систем.
Как начать решение таких задач, какой выбрать инструмент? Очевидно текстовое описание слишком тяжеловесно и трудно модифицируемо при последующих уточнениях. Точное описание в машиночитаемом виде - отличная промежуточная форма, но начать её делать сразу - не всегда хватит отваги. В этот самый момент отчаянья нужно расслабиться и попробовать сформулировать задачи, знания об объекте в виде который будет легко воспринимать не только погруженному в "раскопки" аналитику, но и заказчику, а также всем заинтересованным лицам.
Структурная диаграмма (structure) - отображение частей целого, разделения на компоненты. Удобна для именования компонентов, выделения схожих и однотипных компонентов (можно выделить формой и цветом). На этой диаграмме можно обозначить взаимосвязи (каналы взаимодействия) между системами и компонентами, но нужно стараться не перегрузить информацией. Если сделана удачно - видно, например, как распланировать работы параллельно, либо - какие компоненты могут быть исключены из рассмотрения.
Иерархическая диаграмма (hierarchy) - она же организационная (часто полезна для представления плана коммуникаций в проекте, анализа подчиненности заинтересованных лиц). Альтернативные варианты применения - простой вариант объектной модели (дабы не забивать голову не-программистам) - дабы подчеркнуть степени уточнения методов, или наличия информации о свойствах у объектов описанных более детально.
Блок-схема (flowchart) - описание действий, позволяет удобно отделить основной сценарий от альтернативных, отобразить циклические операции, точки принятия решения. Казалось бы - тривиальный инструмент, в крови у программистов со средней школы, но как показывает практика для специалистов-гуманитариев не очевиден и может ускорить процесс разработки, например, шаблонов договоров.
Диаграмма последовательности (sequence) - элемент uml, удобный и весьма полезный и вне унифицированного языка моделирования. Крайне удобен для отображения обмена между несколькими сущностями (собственно выявления упущенных сущностей в цепочке передачи- например нарушителя ИБ), перечисления элементарных сообщений для последующего анализа - что может пойти не так если его не случится, оно будет модифицировано, задержится и т.д. Крайне удобный метод отображения сетевых протоколов и аналогичных концепций.
А как же mindmap? - соглашусь, удобный инструмент на этапе начального сбора информации, когда ее нет в явном виде, либо при мозговом штурме - выработке плана действий, но в целом, в классическом виде - это скорее промежуточный инструмент, удобный для работы в команде, но не вне её - "не разогретому" читателю без помощи создателя, "непричёсанный" майндмэп будет фрустрировать. Если конечно мы не говорим о стилизации под майндмэп - вот классический пример майндмапа доведенного до структурного, упорядоченного списка (структурной диаграммы), т.е. по сути майндмапом уже не являющимся. Можно сравнить с также аккуратным и структурированным, но не столь упорядоченным вариантом.
Остались за кадром более специфичные и "узкие" инструменты - gap, fishbone, gant, pert, представления характерные для анализа данных - графики, а также способы представления текстовой информации в структурированном виде - таблицы, outline. Если решаемая задача выглядит как очевидно удобная для их применения - стоит попробовать, вероятно затраты на объяснения принципа диаграммы на совещании окупятся в дальнейшем, не стоит разве что изнурять заказчиков десятками различных типов представлений.
