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

СидRMagistr2015,

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

)))) Ну я имел ввиду наличие какой-нибудь описательной методики с софтом для отображения всего этого в виде сущностей и связей между ними - это как пример, эти сущности можно самому добавлять в общую схему и настраивать связи с остальными элементами интерфейса, заранее добавленными в общую схему в виде других сущностей, ну как-то так рисуется в моём представлении )))
А как на самом деле обстоят дела? Есть какой-нибудь инструмент или методика для решения подобной проблемы? Ну может какой-нибудь инструмент для описания "карты действия пользователей"... Что-то в этом роде....?

СидRMagistr2015,

Я обычно при разработке задаю себе и другим вопросы:
1) кому это надо?
2) зачем это надо?
3) что такое хорошо?
4) что такое плохо?
5) а что если какой-то $%& сделает то, что мы не предусмотрели?

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

Что касается модели поведения, я её обычно рисую на клочке бумаги в наиболее понятном для себя виде. Это если в голове не умещается.

Ясно, спасибо, не могли бы вы подсказать что-нибудь по разработке интерфейса пользователей, может там ответы есть....?

СидRMagistr2015,

А что там подсказать такого можно? Вопрос же сводится к защите от дурака. А это уже функциональная часть. Не мне решать, какие кнопки должны быть отображены/активны в вашей ИС в тот или иной момент времени, и насколько грубо система должна ругаться на пользователей за неадекватное поведение))

Кстати, ещё один момент, который автоматически даст ответы на кучу вопросов начиная от логики и заканчивая UI и юзабилити. Когда запилили фичу, начните ей активно пользоваться. Если подразумевается рутинная работа, попробуйте сделать однотипное действие 100 раз подряд. Ставьте различные и порой нестандартные задачи и сами попытайтесь их решить при помощи ИС. Если всё получится и ничего не взбесит, можно запускать в эксплуатацию)))

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

СидRMagistr2015,

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

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

СидRMagistr2015,

Мне такая проблема только предстоит, я и сам заранее ломаю голову, как это всё будет. Сейчас работаю один, начиная от совещаний с руководством и пользователями, и заканчивая собственно разработкой и поддержкой ИС. Всё в одном. Есть планы по расширению влияния нашей ИС, и проблема, когда несколько человек делают отдельные модули, тоже встанет остро)))
Случай из прошлого: работали мы как-то в паре с одним товарищем над всё той же системой, и дал нам ПМ задачки не зависимо друг от друга. И так получилось, что мы тронули один и тот же модуль, после чего пошло это всё дружно в продакшн, естественно, наложившись друг на друга. Тогда у заказчика работу целого отдела парализовали на полдня)))
Теперь по теме. Реально нужно программистам вкладывать в голову, как работает система. Начиная от текущего куска, и дальше вглубь по взаимосвязям с другими модулями. Пусть уделяют этому больше времени (будут собственными же юзерами, которым отвечатель-на-вопросы всегда поможет). Без понимания, как это всё работает сейчас и как должно работать в будущем, вообще нельзя писать или править код. Вопрос лишь в том, насколько глубоко нужно знать взаимосвязи для текущей задачи.
Ответы на вопросы - это самый простой и удобный способ (ИМХО). В документации всё равно не опишешь вообще всё, что там наворочено. А даже если опишешь, то программист может не понять или неправильно понять терминологию, какие-то фразы, а может просто не найти нужное только потому, что написано другими словами (опять же ИМХО).
Я на примере нашей ИС (медицинской) даже не представляю, сколько всего нужно засунуть в документацию, которой, кстати, тоже пока нет, и мы ещё мечтаем о специальном человеке, который всё опишет (и задаст по пути 100500 вопросов, на которые мне же и придётся отвечать... хнык!)
Вполне возможно, что проблему решит немножко другая организация работы. А именно - наличие 100% доступного отвечатель-на-вопросы-программистов, который знает всю систему и не выезжает на всяческие совещания, в командировки и т.д. Есть вопрос - получи ответ немедленно. Иначе работа программиста просто встаёт, он ждёт возврата отвечателя-на-вопросы, т.к. от его ответа зависит вообще всё.

Напиши мне, брат, мы вместе решим эту проблему
R-Magistr2015@yandex.ru
поделимся опытом и реализуем и твои и мою системы ))))

Напиши в теме что ты с форума )))

hVosttRMagistr2015,

Разрабатывать по принципу: всё, что явно не разрешено -- запрещено.

Ну мы в принципе так и делаем, поэтому приходится вешать ещё кучу проверок на кодд ))) Спасибо большое )))

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