• Создание User-Friendly движка бизнес-процессов на основе Windows Workflow Foundation

      Постановка задачи




      Одной из неотъемлемых частей любой ECM-системы является управление бизнес-процессами, или workflow.

      Бизнес-процессы в каждой отдельной организации имеют множество нюансов. Они постоянно изменяются вследствие изменений внутри организации, изменений законодательства и т.д. Поэтому дешевле и логичнее к разработке бизнес-процессов привлекать либо аналитиков, либо программистов, специализирующихся на бизнес-логике. А значит, создание и изменение бизнес-процессов должно быть максимально простым и удобным.

      Так же при изменении процесса уже запущенные процессы должны корректно работать. Нельзя останавливать долгое и сложное согласование договора только потому, что теперь согласованный документ должен распечатать не инициатор согласования, а секретарь.

      Это диктует некоторые требования, которые предъявлялись к движку бизнес-процессов:
      • Процессы должны разрабатываться на основе высокоуровневых блоков. Примером такого блока может быть создание задания на согласование документа, старт подзадачи, выполнение произвольного куска кода и т.д.
      • При изменении схемы процесса нужно обеспечить возможность конвертации уже запущенных процессов на новую версию схемы.

      При разработке новой версии движка бизнес-процессов мы решили попробовать Windows Workflow Foundation (далее WF).
      Читать дальше →
    • Как мы практикуем коридорное тестирование

        Разработчики хотят делать понятные и удобные программные продукты.
        Но для нас и консоль, и горячие клавиши — вполне понятный и удобный интерфейс:
        image
        Если к программе можно написать плагин, то она удобная и расширяемая. Если можно поменять в конфиге цвет фона окна сообщения — гибкая. Нормальному же пользователю от такой гибкости ни тепло ни холодно, ему свои задачи надо решать, а не плагины писать.

        Раньше мы тестировали пользовательский интерфейс в процессе опытной эксплуатации (это когда новая версия устанавливается в нашей компании). У этого метода нашлись недостатки:
        • Пользователям некогда оформлять замечания к продукту. Особенно если это касается удобства использования программы, а не функционала.
        • Не понятно, насколько интуитивен интерфейс. Можно, конечно, проводить опросы, но они обычно малоинформативны.
        • Замечания поступают слишком поздно. У разработчика остается меньше времени на их исправление.

        Бороться с этими недостатками мы решили с помощью коридорного тестирования. Здесь мы хотим поделиться своим опытом.
        Читать дальше →