* PDFBook/Экспорт в Word — мы пока про такие «фишки» не задумывались. Сейчас у нас выгрузка в ворд решает только одну задачу — отослать заказчику спецификации, получить от него реакцию в виде комментариев в тексте.
Про публикацию наших разработок — вот пока не спросили, не задумывались. В принципе не жалко. Сегодня еще раз посмотрел на «доработанный» нами PDFBook. Оказалось, общих вещей (для PDF и DOC) там очень мало, так что имеет смысл вынести наш экспорт в ворд вообще в отдельный плагин, а PDFBook оставить оригинальный. В ближайшие дни это сделаем, и куда-нибудь выложу. Думаю, польза будет всем :)
* PlantUML — насчет удобств могу рассуждать только в сравнении с Визио. Других вариантов «текстового» описания UML не пробовал.
Удобства:
1) простой, понятный язык. Даже наглядный — всякие стрелочки, кружочки.
Поэтому легко запоминается синтаксис.
2) без формализма (фанатизма). Не надо как-то специально описывать сущности. Они создаются при появлении в тексте.
Например: Child --|> Parent
сразу нарисует два прямоугольника-класса со стрелкой-наследованием.
Неудобства:
1) прожорливость реализации. PlantUML — это ява-приложение, которое на выходе дает опять-таки текстовое описание графа, которое подается на вход Graphviz. И вся эта цепочка запускается соответственно из PHP. Поэтому страница с 4 и более диаграммами сохраняется сильно долго.
2) непредсказуемость размещения блоков диаграммы. Нет никакой возможности «подсказать», что этот класс я хочу видеть наверху, а эти три — под ним. Часто по смыслу хочется расположить их иначе, чем предлагается программой.
Сообщения об ошибках — конечно не верх информативности, но максимум раза с третьего :) найти причину можно. Просто пишется строка, где по мнению программы есть ошибка. Без подробностей.
> мы сделали специальный режим просмотра с регулярным автообновлением
Можно ли об этом поподробнее? Как это реализовано? Как выглядит?
Про покрытие тестами мы пока только мечтаем. В этом плане есть некая… безсистемность.
Относительно связей — в тесткейсах (мы используем Testopia) есть специальное поле для ссылки на документ. В частности — на спецификацию. Обратных связей (спец -> тест) нет.
А как вы это делаете? Может, посоветуете где почитать?
Как раз это я и называю — задача затруднена. Не невозможна в принципе, а решается с помощью других инструментов, призванных компенсировать недостатки основного.
Вы совершенно правы в своих замечаниях. И если бы стояла задача довести описанный инструментарий до возможности его постоянного использования в крупных проектах, наверняка возникла бы необходимость в таких вот дополнительных средствах — системы контроля версий, продвинутый поисковый движок и пр. И это бы тоже работало.
Но мы сделали только несколько шагов в этом направлении и свернули с половины пути. Мы начали с самых простых средств, которые могли себе представить. Потому что, как правильно заметил г-н. beskov, это лишь средства. А цель была шире — запустить сам процесс написания спецификаций. Как писать, что писать, и в последнюю очередь — в чем писать.
Научились (ну я надеюсь). При этом попутно мы поняли, а чего собственно, мы хотим от нашего идеального инструмента, что было удобно а чего не хватало. И эти знания послужили основой для следующего витка инструментария.
Сейчас это вики. Соответствующим образом настроенная под наши задачи. О чем скоро я надеюсь рассказать.
Эта беда нас миновала. Мы принципиально следуем правилу не писать развесистых документов. Одна задача — один документ. 10 страниц для спецификации — уже слишком много. Средний объем спецификации — 5 страниц. При этом половина из них — это всякие рисунки: диаграммы классов или эскизы экранов.
Разница есть. Если плясать от моих требований к инструменту, то бумага и карандаш решают только одно — удобство правки. Удобство чтения (с моим-то почерком) страдает. не говоря уже о поиске.
* PDFBook/Экспорт в Word — мы пока про такие «фишки» не задумывались. Сейчас у нас выгрузка в ворд решает только одну задачу — отослать заказчику спецификации, получить от него реакцию в виде комментариев в тексте.
Про публикацию наших разработок — вот пока не спросили, не задумывались. В принципе не жалко. Сегодня еще раз посмотрел на «доработанный» нами PDFBook. Оказалось, общих вещей (для PDF и DOC) там очень мало, так что имеет смысл вынести наш экспорт в ворд вообще в отдельный плагин, а PDFBook оставить оригинальный. В ближайшие дни это сделаем, и куда-нибудь выложу. Думаю, польза будет всем :)
* PlantUML — насчет удобств могу рассуждать только в сравнении с Визио. Других вариантов «текстового» описания UML не пробовал.
Удобства:
1) простой, понятный язык. Даже наглядный — всякие стрелочки, кружочки.
Поэтому легко запоминается синтаксис.
2) без формализма (фанатизма). Не надо как-то специально описывать сущности. Они создаются при появлении в тексте.
Например: Child --|> Parent
сразу нарисует два прямоугольника-класса со стрелкой-наследованием.
Неудобства:
1) прожорливость реализации. PlantUML — это ява-приложение, которое на выходе дает опять-таки текстовое описание графа, которое подается на вход Graphviz. И вся эта цепочка запускается соответственно из PHP. Поэтому страница с 4 и более диаграммами сохраняется сильно долго.
2) непредсказуемость размещения блоков диаграммы. Нет никакой возможности «подсказать», что этот класс я хочу видеть наверху, а эти три — под ним. Часто по смыслу хочется расположить их иначе, чем предлагается программой.
Сообщения об ошибках — конечно не верх информативности, но максимум раза с третьего :) найти причину можно. Просто пишется строка, где по мнению программы есть ошибка. Без подробностей.
> мы сделали специальный режим просмотра с регулярным автообновлением
Можно ли об этом поподробнее? Как это реализовано? Как выглядит?
Относительно связей — в тесткейсах (мы используем Testopia) есть специальное поле для ссылки на документ. В частности — на спецификацию. Обратных связей (спец -> тест) нет.
А как вы это делаете? Может, посоветуете где почитать?
Вы совершенно правы в своих замечаниях. И если бы стояла задача довести описанный инструментарий до возможности его постоянного использования в крупных проектах, наверняка возникла бы необходимость в таких вот дополнительных средствах — системы контроля версий, продвинутый поисковый движок и пр. И это бы тоже работало.
Но мы сделали только несколько шагов в этом направлении и свернули с половины пути. Мы начали с самых простых средств, которые могли себе представить. Потому что, как правильно заметил г-н. beskov, это лишь средства. А цель была шире — запустить сам процесс написания спецификаций. Как писать, что писать, и в последнюю очередь — в чем писать.
Научились (ну я надеюсь). При этом попутно мы поняли, а чего собственно, мы хотим от нашего идеального инструмента, что было удобно а чего не хватало. И эти знания послужили основой для следующего витка инструментария.
Сейчас это вики. Соответствующим образом настроенная под наши задачи. О чем скоро я надеюсь рассказать.
Вариант №2 таки планировался. Как раз про вики. Сейчас пишется.