1.А на докладе я ответила, что при наведении на каждую ветку подсвечивается информация. Если это крупные ветви (не извещения-контракты), то "ценовой диапазон", за который она отвечает.
1.Б критерии Вы не забудите, т.к. они отображаются в фильтрах справа от дерева, см. слайды презентации, где дерево в ИС.
С полной версией дерева нужно работать для общего понимания. А если вас интересуют конкретные контракты, то, как я и рассказывала на докладе https://conf.uml2.ru/class/mnogomernyi-analiz-dannykh-s-risk-monitoringom--opyt.html , лучше воспользоваться фильтрами и сократить количество веточек-контрактов до хотя бы сотен, а лучше - десятков.
Я вызывала Яндекс в Ярославле: водитель подъехала за 500 метров и сказал идти к нему по проливному дождю. На мою просьбу подъехать к указанному месту он сказал «а не буду» и отказался от заказа, в результате С МЕНЯ сняли 50 руб. Просту «супер»! В убере такого нет, но убера в Ярославле нет в принципе (обычно пользуюсь в Москве). Вот подскажите мне, пожалуйста, что с такими водителями делать?
Про репозиторий — это коллекция объектов, в данном случае «строительных блоков». Поддерживается и обновляется в wiki, это достаточно удобный инструмент для команды.
Статья касается в основном методологических вопросов. Средства автоматизации данной методологии выходят за рамки этой статьи. В настоящее время функции автоматизированы частично.
Да, РП — это один из инструментов, который не отменяет использование других (спеки и т.д.). В моей практике именно на РП удобно быстро «прокликать» систему по use case и просмотреть ее, ведь при самостоятельном тестировании возникают проблемы в сложности получения нужных данных. Т.о. некоторые моменты просто не видны разным людям или их получение весьма трудоемко.
Большой поток изменений меняет достаточно сильно систему, всё «собрать» в одном месте, конечно, сложно. РП ориентировано, конечно, на фронт и всегда несколько упрощено, как и любая модель отличается от моделируемого объекта.
У меня базовое образование МГУ + магистратура Физтеха по специальности «Аналитик больших систем» факультета информационных бизнес-систем. Так что да, я этому обучалась + практика проектов, конечно.
Анализ требований (составление таблицы) занял 2-3 дня. Работа над таблицей до ее «зеленого» внешнего вида заняла примерно полтора месяца.
Далее при каждом релизе идет итерация, очень удобно. Важно понимать, что это — «живая» система, для которой характерен постоянный поток новых требований и изменений.
Это интересная идея)) и цветом прямоугольников обозначать риск-мониторинг/включение в проверки?
Отвечая по пунктам:
1.А на докладе я ответила, что при наведении на каждую ветку подсвечивается информация. Если это крупные ветви (не извещения-контракты), то "ценовой диапазон", за который она отвечает.
1.Б критерии Вы не забудите, т.к. они отображаются в фильтрах справа от дерева, см. слайды презентации, где дерево в ИС.
С полной версией дерева нужно работать для общего понимания. А если вас интересуют конкретные контракты, то, как я и рассказывала на докладе https://conf.uml2.ru/class/mnogomernyi-analiz-dannykh-s-risk-monitoringom--opyt.html , лучше воспользоваться фильтрами и сократить количество веточек-контрактов до хотя бы сотен, а лучше - десятков.
О, интересно! Не видела раньше
Например
Статья касается в основном методологических вопросов. Средства автоматизации данной методологии выходят за рамки этой статьи. В настоящее время функции автоматизированы частично.
Большой поток изменений меняет достаточно сильно систему, всё «собрать» в одном месте, конечно, сложно. РП ориентировано, конечно, на фронт и всегда несколько упрощено, как и любая модель отличается от моделируемого объекта.
Анализ требований (составление таблицы) занял 2-3 дня. Работа над таблицей до ее «зеленого» внешнего вида заняла примерно полтора месяца.
Далее при каждом релизе идет итерация, очень удобно. Важно понимать, что это — «живая» система, для которой характерен постоянный поток новых требований и изменений.