http://bpmnforum.ru/tags/%d1%80%d0%b0%d0%b7%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%ba%d0%b0-%d1%81%d0%be%d1%84%d1%82%d0%b0 bpmnforum.ru » Tag: разработка софта - Recent Posts ru-RU Wed, 13 May 2026 11:21:36 +0000 http://bbpress.org/?v=1.0.3 q http://bpmnforum.ru/search.php http://bpmnforum.ru/topic/140#post-1165 Втр, 05 Мар 2013 11:59:27 +0000 Ashatta 1165@http://bpmnforum.ru/ <p>Спасибо большое.</p> <p>Да, говоря о плюсах и минусах, я имела в виду также удобство пользования и, возможно, какие-то специфические особенности, в которых нуждается пользователь именно этой предметной области. </p> http://bpmnforum.ru/topic/140#post-1164 Втр, 05 Мар 2013 11:20:53 +0000 Юлия Вагнер 1164@http://bpmnforum.ru/ <p>Какие могут быть плюсы и минусы у редактора BPMN? Только полнота поддержки нотации.<br /> Участники этого форума в большинстве пользуются Bizagi Process Modeler <a href="http://bizagi.com/index.php?option=com_content&#038;view=article&#038;id=27&#038;catid=5&#038;Itemid=98" rel="nofollow">http://bizagi.com/index.php?option=com_content&#038;view=article&#038;id=27&#038;catid=5&#038;Itemid=98</a><br /> Он бесплатный, можете скачать и пользоваться. </p> http://bpmnforum.ru/topic/140#post-1163 Пон, 04 Мар 2013 10:26:31 +0000 Ashatta 1163@http://bpmnforum.ru/ <p>Здравствуйте. По долгу службы мне предстоит реализовать редактор для BPMN. В связи с этим хотелось бы иметь представление об уже существующих решениях. Но кто же может рассказать об этом лучше, чем те, кто пользуется этими инструментами в своей работе постоянно?<br /> В общем, я прошу у вас помощи. Не могли бы вы черкнуть сюда о ваших любимых/нелюбимых инструментах для моделирования, об их плюсах и минусах, о том, что бы хотелось изменить/добавить и тому подобное?<br /> Заранее благодарна за возможную помощь и прошу прощения, если сунулась со своим вопросом не по адресу. </p> http://bpmnforum.ru/topic/25#post-724 Срд, 18 Апр 2012 11:17:55 +0000 Юлия Вагнер 724@http://bpmnforum.ru/ <p>Леонид,<br /> 1. Подпроцесс "Обработка инцидента" - не совсем понятно, что там делается помимо проверки на существующий инцидент (предположим, что развели все-таки выходы - присоединить к существующему или это новый инцидент). А на выходе из этого подпроцесса стоит развилка "Способ решения". Значит подпроцесс "Обработка инцидента" должен давать ответ "Отказ", "Консультация" или "Разработка". Где это делается-то? Получается, что в подпроцессе Вы решаете один вопрос, а на выходе проверяете совсем другое?<br /> 2. Оценка возможности доработки делается в процессе "Исполнение доработки", а отказ в доработке вы делаете раньше этой оценки. Абсолютно нелогично. Либо отказали, даже не оценив, либо проделали какую-то кучу действий, передали в разработку, а потом оценили, что доработка невозможна.<br /> 3. Подпроцесс "Передача в разработку" возращает два варианта завершения: работа выполнена или не выполнена. Дальше вы шлете ответ заказчику в обоих случаях и ожидаете от него ответа? Т.е. если работа не выполнена, Вы ждете ответа "Решение помогло?" Это цинично :) А если они так же цинично ответят в случае отказа, что решение не помогло, то вы готовы повторить этот сценарий еще раз? (Типа, опять трясти надо? :) )<br /> 4. У Вас в процессе планирования есть задание "Решить о возможности доработки", после которой нет никакой проверки. Зачем решать о возможности, если решение заведомо положительное? Вероятно, имеется в виду планирование ресурсов и сроков? Тогда этот шаг надо объединить со следующим и не плодить заданий. </p> http://bpmnforum.ru/topic/25#post-694 Пон, 16 Апр 2012 19:20:28 +0000 Анатолий Белайчук 694@http://bpmnforum.ru/ <p>Эти процессы выбирают для практики представители крупных софтверных компаний. Можете не сомневаться - что есть и чего нет в готовых инструментах они знают отлично. </p> http://bpmnforum.ru/topic/25#post-676 Пон, 16 Апр 2012 16:06:26 +0000 pipec 676@http://bpmnforum.ru/ <p>А стандартные "молотки" чем не угодили? Инструментов под эту задачу, по-моему, немеряно всяких, толстых-тонких, платных-бесплатных. Или это просто потренироваться и попутно тридумать лисапед? </p> http://bpmnforum.ru/topic/25#post-239 Птн, 23 Сен 2011 08:31:05 +0000 Анатолий Белайчук 239@http://bpmnforum.ru/ <p>С первым замечанием согласен.</p> <p>"Анализировать инцидент" - это название подпроцесса, а не событие. Событие не подписано (это упущение), очевидно имеется в виду бизнес-исключение "инцидент является дубликатом".</p> <p>Но в любом случае согласен, лучше показать два разных завершения. </p> http://bpmnforum.ru/topic/25#post-213 Втр, 20 Сен 2011 12:36:16 +0000 Pavel-Smirnov 213@http://bpmnforum.ru/ <p>Если окажется, что связанная задача будет решена до выполнения активности &quot;прикрепить к существующему инциденту&quot;, то процесс зависнет. Поэтому лучше использовать гейт на проверку наличия (или отсутствия) решения по связанной задаче.</p> <p>А еще бы я разделил нормальное завершение (когда инцидент не анализируется) и завершение через прикрепленное событие-ошибку &quot;анализировать инцидент&quot;. Только в этом случае возможно будет разделить инциденты, которые решались &quot;готовым ответом&quot; от инцидентов, которые требовали анализа.</p> <p> [attachment=213,122] </p> http://bpmnforum.ru/topic/25#post-186 Птн, 10 Июн 2011 12:27:00 +0000 LeonidBatizhevsky 186@http://bpmnforum.ru/ <p>Версия 3 подоспела</p> <p> [attachment=186,99] [attachment=186,100] [attachment=186,101] </p> http://bpmnforum.ru/topic/25#post-180 Втр, 07 Июн 2011 15:13:39 +0000 alexsteptlt 180@http://bpmnforum.ru/ <blockquote><p><cite>Цитирую <a href="http://bpmnforum.ru/topic/25#post-172">alexsteptlt</a>:</cite><br /> 6. Закрытие инцидента: на данном этапе Консультант готовит ответ с решением по инциденту, а также, в случае, если были внесении изменения в ПО, готовит рассылку с изменениями. </p></blockquote> <p>После отправки уведомления клиенту о решении инцидента, консультант должен дождаться "угу" от Пользователя. Если в течении 5 дней "угу" не приходит, то инцидент автоматически закрывается, если приходит "не угу" то, инцидент повторно проходит все стадии (кроме самой регистрации). </p> http://bpmnforum.ru/topic/25#post-178 Втр, 07 Июн 2011 14:36:31 +0000 LeonidBatizhevsky 178@http://bpmnforum.ru/ <p>Добавили реакцию пользователя</p> <p> [attachment=178,92] </p> http://bpmnforum.ru/topic/25#post-177 Втр, 07 Июн 2011 13:45:38 +0000 LeonidBatizhevsky 177@http://bpmnforum.ru/ <p>Версия 2</p> <p> [attachment=177,89] </p> http://bpmnforum.ru/topic/25#post-173 Втр, 07 Июн 2011 11:28:51 +0000 alexsteptlt 173@http://bpmnforum.ru/ <p>Спроектированный процесс разработки и сопровождения ПО_V1</p> <p> [attachment=173,87] </p> http://bpmnforum.ru/topic/25#post-172 Втр, 07 Июн 2011 11:24:42 +0000 alexsteptlt 172@http://bpmnforum.ru/ <p>1. Целью процесса «Управление Инцидентами» ( Incident Management - IM ) является скорейшее восстановление нормального функционирования ПО и уровня сервиса, определенного в SLA, с минимальными возможными потерями для Заказчика и его Пользователей.<br /> 2. Процесс управления инцидентами состоит из следующих шагов:<br /> 1. Прием и регистрация инцидентов:<br />  заполнение формы в системе самим Пользователем;<br />  письмо по электронной почте;<br />  по телефону, факсу, ICQ, Skype и т.д. Примем и сортировку поступивших инцидентов осуществляет Диспетчер. Результат: зафиксированный в системе Инцидент, назначенный Консультант по инциденту.<br /> 2. Первичная идентификация и классификация инцидентов, начальная поддержка На данном этапе Консультант выполняет<br />  локализацию инцидента: повторение ошибки на тестовом примере, сопоставление и связка с другими инцидентами<br />  тип инцидента: консультация, задание, ошибка, доработка<br />  классификацию инцидента: приоритет, срочность выполнения и пр. Результат:<br />  если Консультанту известно готовое решение по инциденту, он консультирует Пользователя и переходит к закрытию инцидента;<br />  если Консультанту известен способ продолжить работу Пользователя до устранения сбоя, он консультирует Пользователя и передает инцидент в разработку;<br />  если инцидент определен как ошибка или задание (не требует анализа), Консультант передает его в разработку;<br />  если инцидент определен как доработка, Консультант передает его на на анализ<br /> 3. Анализ инцидента: На данном этапе Аналитик осуществляет анализ возможности и необходимости функциональной доработки ПО, в случае необходимости пишет постановку на доработку. Результат:<br />  постановка на доработку, и передача в разработку инцидента;<br />  в случае если Аналитику известен способ решения проблемы Пользователя без доработки, сообщает Консультанту, а тот, в свою очередь Пользователю и переходит к закрытию инцидента.<br /> 4. Разработка: на данном этапе Ответственный разработчик определяет ответственных за разработку инцидента (либо ошибки и задания автоматически попадают разработчикам по закрепленным за ними разделам), определяет возможность доработки новой функциональности в короткие сроки или передает инцидент в базу перспективных доработок. Разработчик выполняет доработку, устранение ошибки, выполняет сборку проекта и передает на тестирование, вносит запись в систему управления изменениями. Результат:<br />  исправленная ошибка, выполненная доработка;<br />  запись в системе управления изменениями;<br />  пополненная база задач на перспективную разработку.<br /> 5. Тестирование: на данном этапе тестировщик проверяет на тестовом ПО работоспособность доработок, в случае обнаружения ошибок возвращает на доработку, в случае успеха включает в новый билд и (если велика срочность исполнения инцидента) передает в службу сопровождения для рассылки изменений и закрытия.<br /> 6. Закрытие инцидента: на данном этапе Консультант готовит ответ с решением по инциденту, а также, в случае, если были внесении изменения в ПО, готовит рассылку с изменениями. </p>