...
Пожалуйста, есть оценка использования ИС Дракон в коллективе.
От 09 Декабрь, 2010.
...
Ну что ж, сопоставим подходы:
Об успехе с т.зр. когнитивной эргономики можно говорить, когда есть результаты ИП-исследований, что та или иная форма описания повысила (или не понизила хотя бы
) понимаемость описания в команде (с передачами описаний людям, ранее бывшим "не в теме", в т.ч. "предметникам") на протяжении длительного времени (с возвращением к проекту после "откладывания в долгий ящик", с ведением версий, сопровождением). Когда преимущественно один человек и пишет, и читает - это лёгкий случай.
Цитата:
Добрый день Геннадий!
Обрисовываю картину:
...если программный код очень сильно разрастается, становится сложно в краткие сроки выискивать и исправлять ошибки. После знакомства с ДРАКОНом ситуация улучшилась - многие ошибки (как логические так и алгоритмические) выявляются уже на стадии прорисовки, плюс ко всему этому - код получается документированным и в нем становится проще разобраться.
Собственно для этого и начали пользоваться вашим редактором схем. В процессе активной работы с ним появилось желание изменить его для более быстрого и эффективного его использования.
Т.е. по всему вышесказанному: программа будет использоваться только в ограниченном кругу лиц для проектирования программного обеспечения.
Специализированные изменения вносить в программу совершенно не планируем - только изменения связанные с удобством и убыстрением работы с редактором
...
С уважением,
XXXX Дмитрий
Итак:
1. Все участники данной оценки - программисты (прямо указано на назначение - как и на ограниченность коллектива использующих описания) и их часто устроит всё, что хоть немного улучшит читаемость - уже говорил
здесь. Для "предметников" это не обязательно так.
2. Все "в темах" разработки (хотя и переключаются между проектами). Что облегчает задачу и делает сочинителей/читателей менее требовательными к качествам среды (особенно программистов с учётом п. 1).
3. Судя по "выискивать", используется "наивная отладка", применение которой с позиций гарантоспособности д.б. ограничено "некризисными" задачами. Что получается, если этому не следовать - см. вторую часть
этого сообщения.
4. Также высказана необходимость в эргономических улучшениях Ты-среды.
Т.о., никаких принципиальных расхождений со сказанным ранее мною.
Кроме того, исходное обсуждение посвящено использованию техноязыка (шире - визуализации профессиональных знаний). С этих позиций принципиально не только, чтобы среда визуализации была удобна (и по реализациям языков, и по работе) и для "непрограммистов" - но и чтобы она поддерживала естественную технологию коллективной работы "рецензирование-правки-принятие изменений". Об этом тоже сказал - а подробнее см.
в этом сообщении. Была и тема об
управлении версиями, в т.ч. в обучении. Можно реализовать и подобно офисным пакетам, можно использовать механизм областей... надо смотреть.