151

ПО Аналитика / Re: Управление изменениями требований

« : 08 Апреля 2016, 16:31:59 »

Напомню, что есть инструменты, которые уже много лет помогают в ручном разборе (например, избавляют от копипаста и помогают контролировать проход по документу), типа https://www.visual-paradigm.com/tutorials/textualanalysis.jsp

Спасибо за ссылку. Идея отличная, но не уверен, что она получила широкое практическое применение. Вообще не вижу перспектив за продуктами типа confluence и плагинов к нему. Это безусловно лучше, чем word, но все равно не заменит "тяжелой" технологической системы.   

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

Я бы предложил не ждать милостей у природы, а самим взять их у неё.
В смысле, например, разработать плагин для Google Docs, который будет делать базовый разбор текста.

Разбор текста для чего? Лексических и семантических анализаторов как собак нерезанных. Писать их в научном плане крайне приятно - лет двадцать тому назад так приятно было свои языки и компиляторы писать. Один из наиболее качественных анализаторов  у ABBYY например. Поставляются они и в виде готовых решений, и библиотек. Так что средств, которые могут хапнуть кучу документов, расчитатать по ним семантические метрики, откластеризовать и построить разного вида представления, характеризующие семантические связи по этим документам как грязи. Вопрос в том, как это провязывать к технологической системе. Так что к проблеме надо заходить со стороны СУТ. Причем такой тяжелой и правильной типа Cradle.

Самое обидное, что тот же 3SL двинулся во вполне правильном направлении в Loader. Они word файлы распаковывают, а xml пишут в базу. То есть разобранный документ они из базы обратно легко восстанавливают в первоначальном виде (что кстати довольно прикольно - родной микрософтовский sharepoint хранит вордовые файли как бинарные обьекты и попыток не делает их распаковать и проанализировать, хотя я думаю можно было бы с этого разные сервисы приятные поиметь) . Но при этом лексической единицей у Loader остается абзац - по вордовому форматированию Loader устанавливает иерархию этих абзацев, а в итоге иеррархию требований.

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

А вот если иметь семантический граф или онтологию, то понимание изменений возможно даже на неоднородных источниках   

152

ПО Аналитика / Re: Управление изменениями требований

« : 08 Апреля 2016, 08:38:33 »

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

На данный момент меня интересуют механизмы быстрой формализации предметной области.

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

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

153

ПО Аналитика / Re: Управление изменениями требований

« : 07 Апреля 2016, 22:59:48 »

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

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

То-то я вокруг себя нередко вижу "аналитегов", способных мастерски исполнить соло на копках джиры, но неспособных объяснить, чем справочник отличается от классификатора ("да лан, не подкалывай - это же синонимы!").

А джира какое имеет отношение к инструментарию аналитика? Это багтрекер - инструмент техподдержки. Может даже инструмент управления требованиями, но уж никак не их разработки.

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

Если человек серьезно подходит к изучению инструментария, то он и про теорию не забудет.

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

Это как учет на бумажке вести или в ERP. Причем если EA с точки зрения управления требованиями - это что-то типа 1С ранних версий, то тот же Cradle - это SAP.

Думаю в ближайшее время уровень СУТ может выйти вообще на принципиально новый уровень, так как именно СУТ является идеальной площадкой для применения искусственного интеллекта. Мне понравилась идея Юлии Мадорской рассматривать матрицу трассировки как онтологическую модель. Если посмотреть на Loader из состава Cradle, который обеспечивает бесшовную интеграцию между документальным представлением требований и их репозитарием в Cradle, то легко увидеть, что следующим шагом будет семантический разбор нормативной и документальной базы проекта, автоматическое формирование глоссариев и онтологий, автоматическая викификация загружаемых документов.
При таких тенденциях заниматься разработкой требований без серьезного инструментария будет невозможно -  по сути разработка сведется к согласованию онтологий предметной области и разрабатываемой системы.

154

ПО Аналитика / Re: Управление изменениями требований

« : 07 Апреля 2016, 10:50:13 »

ну вооот. а теперь давайте посмотрим, в чём хранит документ Word

Docx - это упакованный xml.
https://habrahabr.ru/post/138666/

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

<w:t>{TEXT}</w:t>

При этом конструкций, отражающие семантические связи, между тэгами нет.

А если брать тот же xpdl или bpel, то они вообще исполняемы с помощью интерпретатора.

Тем не менее в критерий инструмент/не инструмент надо внести уточнение. Речь нужно вести не просто о базе данных как о атрибуте СУТ, а именно о репозитарии.

155

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 22:56:50 »

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

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

Сразу все не охватишь, начинаешь с того, что проще. Если что не так, то понимание приходит быстро по практическим результатам. 

156

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 22:18:53 »

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

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

В чем смысл этого противопоставления?

157

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 22:12:20 »

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

Предлагаю считать - xml однозначно конвертируется в реляционную СУБД и наоборот. Например bpm, bpmc, основанные на xml,  поддерживает bizagi modeler (хотя bizagi suite работает с  СУБД)

158

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 21:52:11 »

Я говорю о выборе аналитика, во что инвестировать своё время — А) в освоение новых инструментов или Б) в освоение технологий выполнения аналитических и проектных работ. Я считаю, что окупаемость от Б-варианта гораздо выше, чем А.

Вы уверены, что A и Б никак не взаимосвязаны? Что инструменты не создают предпосылки для новых технологий, а технологии не определяют необходимость в тех или иных инструментах?

159

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 21:30:19 »

Это вообще были не задачи, а ситуации, связанные с реализацией рисков. И кто писал про начинающего?

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

Т.е. вы считаете, что этот опыт не может быть формализован ни в какие чеклисты, шаблоны, технологию? Я считаю — может.

На 100% нет. Есть вещи, которые в технологию не транслируются. Чуйка, интуиция.

ничего не понял. word – тоже инструмент.

С некоторым допущением что-угодно можно считать чем угодно. И карандаш инструмент. И долото для наскальных рисунков тоже.

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

160

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 20:26:03 »

Потому что в большинстве случаев проблемы в качестве анализа возникают не из-за неприменения инструментов, а из-за невладения техниками работы с требованиями:
1. не учли всех ключевых заинтересованных лиц (как тут поможет ПО?)
2. записали хотелки заказчика как есть, не выяснив реальных проблем (как тут поможет ПО?)
3. не понаблюдали за реальной работой реальных пользователей (как тут поможет ПО?)
4. не обнаружили конфликта невысказанных интересов (как тут поможет ПО?)
5. навязали заказчику свои фичи или технологии (как тут поможет ПО?)

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

К вопросу - инструментарий или word имеет самое косвенное отношение. Совершенно непонятно, почему вместо критерия , оценивающего практический опыт аналитика вводится критерий владения/не владения инструментарием.

Почему от этих ошибок должен уберечь опыт технического писательства?

161

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 17:38:24 »

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

Возможно не так долго, как кажется.

У Юлии Мадорской есть отличное сравнение процесса перехода разработки требований в виде бумажки (пусть даже электронной) с ведением БАЗЫ требований в инструментарии с переходом от бумажного проектирования к autocad.

http://edu.reqcenter.pro/?p=4500

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

И произошло это лет за 10, не больше. Так и с документами требований - в ближайшее время они займут свое место рядом c теплым ламповым звуком, тканями с натуральными красителями и прочим винтажом.

162

ПО Аналитика / Re: Управление изменениями требований

« : 06 Апреля 2016, 02:12:59 »

Выложены материалы со встречи про инструменты в Лаборатории Касперского https://www.facebook.com/kaspercareer/posts/1288178701196559

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

Можно ли разрабатывать требования не ставя в качестве конечной цели получение документа?

163

ПО Аналитика / Re: Управление изменениями требований

« : 04 Апреля 2016, 15:05:57 »

"дабы дурь каждого видна была" (c)

В модельках она еще лучше проявляется:)

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

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

 

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

И я про то. Если стоит задача организовать тоталитарную секту аналитиков, то только каллиграфия. Никаких компьютеров

Другое дело какой-нибудь ЕА: скачал, поставил - и сразу же твори нетленку.

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

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

164

Работа / Re: Смена профессии. Хочу стать системным аналитиком

« : 01 Апреля 2016, 22:39:31 »

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

Википедия в принципе более-менее точно описывает

https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%BD%D1%8B%D0%B9_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA

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

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

165

ПО Аналитика / Re: Управление изменениями требований

« : 01 Апреля 2016, 21:21:32 »

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

А почему ворд? Давайте уж сразу - чернила и бумага . А лучше пергамент. Но не перебарщивать - заставлять новичков высекать диаграммы на скалах не будем. Но вменим в обязанность непременное изучение каллиграфии. Годам к 150 из них получатся отличные аналитики. Жаль только не каждый доживет до момента принесения практической пользы....

Он не создает рамок. Инструменты загоняют в рамки различных best practice.

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