Мне нужно сообщить программисту, как работает моя сложная система. Каким образом это лучше сделать?
Я сообщаю алгоритм работы своей сложной системы в виде нарисованных логических схем (ни компилятора, ни имитатора, только моё понимание работы) При этом система достаточно сложная и зачастую алгоритм приходится корректировать => что-то теряется, забывается, не меняется, когда надо и т.д. Прошу! Подскажите среду (Simulink пробовал - слишком нагружен), в которой можно достаточно наглядно изобразить принцип работы системы (>50 входных параметров и еще больше выходных), при этом, чтобы это каким-то образом выполнялось. Буду рад любым предложениям. Если что-т не до конца понятно - опишу.
Разбейте общую схему на уровни. Общие планы и детализация. Предупредите разработчика о предстоящих изменениях, и попросите учесть это.
Если не известны сами изменения, тем не менее известен их характер. "Измениться может все" - это тоже можно смело документировать.
Графические форматы вас не спасут. Простой документ, написанный совместно с разработчиком, в беседе - да. Просто нанесите на бумагу то, что вы говорите вслух, в этом весь секрет. Судя по постановке задачи, сейчас вы этого не делаете.
Проблема с тем, что надо мной и разработчиком стоит малокомпетентный, который тоже любит контролировать каждый шаг. Максимальная формализация его конёк. И требования его тоже могут меняться. А мои изменения чаще связаны с не до конца продуманными последствиями тех или иных моментов алгоритма, поэтому предугадать невозможно.
Константин Гнидкин, поменять работу - самый хороший вариант. Микроменеджмент (когда шеф в попу лезет) - это очень вредно для всех.
Мои рекомендации по созданию иерархии требований, предпочтению текстового формата и проведению консультаций и интервью тем не менее остаются в силе. С плохими руководителями это тоже работает, потому что вообще хорошо работает.
Апдейты требований тоже документируйте. У вас получится толмуд, но вам будет комфортно с ним работать, и можно будет того идиота заткнуть бумажкой с его же подписью, в случае чего.
Хорошие люди из ELMA качественно перевели документацию стандарта по нотации и модели бизнес-процессов BPMN 2.0.
Используйте или Visio или хорошую бесплатную версию Innovator от MID.
Если научитесь использовать BPMN, то это будет существенным плюсом к вашим навыкам.
Sequence diagram - то, как обьекты и классы взаимодействуют на практике.
use case diagram - для более абстрактного представления архитектуры.
class diagram - уже для более детального разбора классов, взаимодействий и их параметров.
Так как я понимаю у вас слишком запутанная и большая архитектура, то можно разбить ее на модули. И предоставить частями. в сиквенс диаграммах, в тоже время полную версию на абстрактнорм уровне в юз-кейз диаграмме.
Во многих больших фирмах практикуют гибридные модели, где комбинируют несколько видов диграм из практики проектировки в одну (тут уж надо гуглить).