Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Андрей Сенченко

Страницы: « 1 2 3 4 5 6 »
16
Ну и бегло по остальному.

2. Ок.
3.1. Выше описал. Отдельная задача проще в реализации в BPMS.
3.2. Выше описал. С точки зрения "здравого смысла" - натянуто (на мой взгляд, тут нет ошибки. Подключение Ведущих - это нормальный рабочий процесс), но принимается потому что Вам виднее что считать ошибкой (я не иронизирую). С точки зрения "расово чистой нотации" ошибки тут нет. С точки зрения реализации в BPMS - лучше с конкретным разработчиком обсудить как ему проще. На мой взгляд - по завершении задачи на РП проверить все варианты на одном гейте. С ELMA я на практике не работал, возможно у них уже готовые триггера на этот случай есть. Допускаю.
3.3. Ок
3.4. Ок.
3.5. Тут мы опять возвращаемся к теме разных моделей для разных целей.
Если модель - только для Регламента, можно вообще убрать пул "Заказчик", поставить РП Пользовательскую задачу "Передать на рецензию и получить ответ от Заказчика" и нас реально слабо волнует как он это будет делать. Мы нашли жертву и ладно.
Если же модель пойдёт в BPMS - задачи Send и Receive лучше возложить не на РП, а на машину (отдельной дорожкой). А то будет бедный сидеть кнопки нажимать при наличии автоматизации.
3.6. Дело хозяйское.

17
Дальше.
Давайте разберем ещё выход по граничному событию. Уже с учётом того, что мы нацеливаемся на BPMS.

Я развернул подпроцесс "Анализировать концепт" для наглядности.

В портальной форме BPMS системы РП получает в читку очередной Концепт, что-то с ним делает (возможно даже читает), после чего или оставляет его как есть (для отправки на рецензию Заказчику) и или же вносит свои комментарии и выбирает куда эти замечания пойдут.
Варианта у нас 2
- БА на доработку
- ВБА на уточнение.
И здесь Вы создаёте отдельный поток, вырывающийся из процесса с триггера по данным. Как это реализовать программно ? Внутри процесса обработки Формы нужно будет встроить проверку выбора:
- БА на доработку - поставить в некое поле флаг "доработка", закомиттить и выйти из модуля, отдав управление на следующий гейт, который и разведет потоки по этому флагу.
- ВБА на уточнение. Тут даже не знаю. Нужно также записать куда-то данные, оборвать этот модуль (событие какое? в базе для статистики что писать ?) а затем ещё поймать чем-то эти данные в БД и утащить управление к ВБА.
На первый взгляд - так.

Теперь второй вариант Вашей схемы.
поставить в некое поле флаг "доработка БА" ИЛИ "доработка ВБА", закомиттить и выйти из модуля, отдав управление на следующий гейт, который и разведет потоки по этому флагу. Просто на гейте будет проверяться на 1 состояние больше.
Мне кажется, так проще.

...
Если бы мы делали модель исключительно для регламента - можно и так, доводы Ваши понятны. Но если схема пойдёт для BPMS - нужно подумать и о том, как это ляжет в код.

18
1. Ну автоматизировать так автоматизировать.
И пусть наши цели совпадают с планами руководства.
Тогда так. Под каждым Action будет лежать свой кусок кода, а к каждой "Пользовательской" задаче будет дополнительно привязана форма на портале. В этом случае, на мой чисто взгляд, схема для регламента и рабочая схема BPMS должны отличаться. Моделируя регламент, можно в целях упрощения схемы вообще и экономии места в частности объединить несколько похожих действий в 1 блок, ну комментарий там ещё добавить.
При переносе же на портал у Вас для "Разработать" (первичной постановки задачи) и "Доработать" (с комментариями и причинами сброса в доработку) будут сильно отличаться параметры, а соответственно лучше не мудрить в коде и на форме, а сделать 2 разных задачи.
Это же касается и граничных событий. Даже если Бизаги их и реализовали, что сомнительно, то далеко не факт, что оно реально работает и удобно. Потому что на программном уровне такой переход связан с кучей проблемок.

Егор, здесь крайне желательно слушать не меня одного, а найти ещё 2-3 человек. Потому что выше я написал как бы делал я. Могут быть и другие варианты.
А уж если выбрана Bizagi - то рекомедую сразу к Белайчуку.
http://mainthing.ru/ru/
http://bpmnforum.ru/forum/2
Ну и на тренинг желательно сходить. Ибо зачем время терять? Стартовый задел у Вас хороший, нужно прокачивать.
http://bpmntraining.ru/

По остальному вечерком отвечу. Ну или днём если время будет.
С мобильника печатать такие объёмы лень.

19
Также рекомендую посмотреть бесплатные моделлеры с валидацией диаграммы.
Из того, чем лично пользовался - Bizagi Modeller и Bonita BPM примерно одинаковы по функциональности и вполне достойны.

20
Егор,
1.
Давайте сразу отсечём один момент. Схема составляется только для того чтобы лечь Регламентом на полку или предполагается перенос в работку в Bizagi Studio или что-то подобное? Если планируется запуск BPMS - сразу избавляйтесь от граничных событий. Нет их там.
 
2.
Давайте сразу учиться хорошему тону. Action на любой схеме, а уж тем более в BPM - это действие, которое кто-то (или что-то) должен (должно) выполнить. Вы для этой схемы кто ? Автор или сторонний наблюдатель ? Автор. Значит это Вы говорите кто и что должен делать. Соответственно нужно использовать глаголы повелительного наклонения.  Не "Разработка" и "Доработка", а "Разработать" и "Доработать".
Неопределенные формы глаголов допустимы только в объявлении пулов и лэйнов - там идёт общее описание процесса.

3.
По схеме наконец.
1. Руководитель проекта возвращает концепт на этап начальной разработки. На самом деле это не так - там будет 1 или несколько этапов доработки. Стоит сделать отдельную задачу.
2. Выход сообщением из анализа документа РП непонятен. РП то продолжает работать с документом или нет ? Если продолжает - может возникнуть любопытный казус, который опишу ниже.
3. А Ведущему БА мы верим на слово ? Результат его работы на анализ к РП не возвращается ? Сразу на Заказчика ? В общем, так действительно может быть, я просто спросил на всякий случай.
4. Возвращаясь к п.2. - ЕСЛИ сообщение на ВБА пошло, а РП продолжил работать - он перешлёт документ Автору на гейте "не согласован". В итоге Автор получит 2 экземпляра Концепта: отклоненный РП и обработанный ВБА. И с каким из них он продолжит работать? В общем, не зная реального процесса, предполагать сложно, но на мой взгляд у Вас там должно стоять граничное событие "Эскалация" или "Ошибка", а внутри - обрыв основной ветки.
5. Отправка - получение на заказчика. Вы не получили ответа. Я вообще не понял как система дала Вам воткнуть сообщение из внешнего пула в "Пользовательскую" задачу (неужто это Visio ?), но там должно стоять "Получить ответ" типа "Входящее сообщение", и только потом - пользовательская "Анализировать". А вместе с Получением ответа стоит сразу предусмотреть параллельную ветку с таймером - что делать если не получено.
6. Концепт, отклоненный Заказчиком, уходит на БА. Это точно так ? Вариант передачи на ВБА не рассматривается ?

21
Для всех / Re: Выбор UML диаграммы
« : 13 Ноября 2015, 16:38:51 »
Дуэль на картинках? :)
Просим топикстартера дать более подробное описание задачи и предлагаем варианты?

Ну можно и так назвать.
Главное дождаться собственно задачи. Пропал наш топикпастер :)

22
Задачи студентов / Re: activity diagram оцените
« : 13 Ноября 2015, 15:50:38 »
1.
Инструмент, в котором Вы работаете поддерживает дорожки для Активити ?
Разбейте действия по дорожкам (клиент, система).
2.
Научитесь описывать действия глаголами повелительного наклонения.
Не "кто-то делает, а я со стороны смотрю", а я говорю кому-то "делай", ставлю задачу.
3.
Ветвление по условию на старте процесса - так не бывает. Точнее, бывает, но это не тот случай.
Условие всегда проверяет результат какого-то действия. В данном случае это действие - система предлагает пользователю авторизоваться (см скрепку 1)

4.
Второе условие по ветке "да" - "использовать сохраненные ..." тоже висит в воздухе. Это же решение. Реакция. На что ? Пользователю должно быть что-то предложено.

5.
Ветка "Регистрация" - отдельный процесс, после которого клиент вернётся на логин.
Рвите и рисуйте на новой диаграмме.

6.
... дальше запутался.
8-12 действий на диаграмме. Больше - плохо.
Начните с диаграммы верхнего уровня, на которой будут только основные блоки
Логин/Регистрация
Действия в профиле
Создание заказа
Утверждение заказа
Распечатка заказа.
...
а уже отдельные шаги - вынесите в декомпозицию.

7.
Внутри ветки регистрации профиля у Вас заложен бесконечный цикл. Пользователь не может уйти из регистрации пока не введет "все правильные данные". В общем меня бы как пользователя такая система дико выбесила. Кнопку "послать всё на фиг до завтра" предусмотреть надо.





23
Для всех / Re: Выбор UML диаграммы
« : 12 Ноября 2015, 20:26:57 »
А так это похоже на попытку изобрести свою нотацию с использованием элементов UML sequence diagram.
Это действительно попытка описать (не изобрести) простую нотацию.

Изобретение собственных нотаций - это вообще вполне нормальная практика на мой взгляд. Просто потому что универсальной нотации нет, а сколько людей- столько и остального.
Особенно это касается случаев устойчивых отношений бизнес-заказчиков и ИТ (характерно для "внутренних" ИТ-отделов и "старых добрых незаменимых" вендоров).
У меня у самого есть достаточно функциональный Набор элементов Visio (составлен из ряда стандартных и собственных иконок путём скрещивания правил BPMN и Функциональной блок-схемы с применением положительных свойств EPC).
Набор включает в себя:
Собственно элементы блок-схемы Visio
Элементы BPMN (гейты, старты, стопы с расширяющими иконками)
Иконки пользователей (одиночных и группы)
Иконки группы "компьютеры"
Иконки группы "транспорт"
Иконки документов (офис и прочее)
Хороший набор, позволяющий очень быстро набросать схему процесса для формального утверждения с пользователями, не искушенными в IDEF UML EPC BPM (далее по списку) и передачи в разработку с комментариями простым текстом.
Для небольших локальных задач - идеальная штука, а готовой нотации, включающей в себя все достоинства других, нет и не будет. Потому что сколько людей - столько и достоинств.

Но в данном конкретном случае я готов бодаться довольно долго.
Задача находится на уровне BPMN, ну или Activity-диаграммы UML. Там просто всё для этого есть.
Поэтому попытки изобрести некую новую сущность безусловно любопытны, но не более.
Повторюсь. В рамках данного конкретного вопроса.

24
Для всех / Re: Выбор UML диаграммы
« : 12 Ноября 2015, 16:55:56 »
Ну или вот ещё пример (скрепка).

Схема чисто саннидэй. По хорошему, нужно отобразить на ней проверки и ответы статусами "упешно/нет", но ни Sparx ни StarUml не предлагают готовых элементов "ветвление" для этой диаграммы (панель на скрине).

Какой тут бест-практис то ? :))))

25
Для всех / Re: Выбор UML диаграммы
« : 12 Ноября 2015, 15:24:27 »
А чего, на твой взгляд, не хватает, чтобы было понятнее?

Григорий,

Изобразите пожалуйста пару гейтов "и/или" в Вашем варианте.

Давайте предположим, что "Снять деньги со счёта" не получилось по причине недостатка средств.
А потом ещё изобразим реакцию Получателя на отказ.

Интерес не праздный.
У меня реально ступор с этой диаграммой и именно из-за гейтов.

В скрепке - схема, которая реально лучше смотрелась бы на диаграмме последовательностей, но я пока не нашёл честного способа разделить потоки на условиях

26
Заменить "информационную систему" на "отчёт" и убрать не нужные разделы?

Ну именно так.

Берёте шаблон:

1.   Назначение и цели создания.
1.1.   Назначение.
Указать общий вид автоматизируемой деятельности и перечень автоматизируемых объектов (процессов, задач).
1.2.   Цели создания.
Указать измеримые показатели, которые должны быть достигнуты в результате внедрения.
2.   Характеристики объекта автоматизации.
2.1.   Краткие сведения об объекте автоматизации.
Описать объект автоматизации – процесс или группу процессов, для которых предназначена разрабатываемая система.
2.2.   Сведения об условиях эксплуатации.
Указать особые условия (например. календарный или температурный режим работы), если они существуют.
2.3.   Существующее программное обеспечение.
Описать программное обеспечение в основной и смежной областях автоматизируемого процесса, участвующее в изменениях.
2.4.   Существующее техническое обеспечение.
Описать техническое обеспечение автоматизируемого процесса.
2.5.   Описание процессов в рамках автоматизации.
Привести общее описание процессов.
3.   Требования к системе.
3.1.   Требования к системе в целом.
3.1.1.   Требования к структуре и функционированию системы.
3.1.1.1.   Перечень и назначение подсистем.
Указать основные характеристики подсистем, требования к числу уровней иерархии и степени централизации системы.
3.1.1.2.   Требования к связи внутренних подсистем.
Указать требования к способам и средствам связи для информационного обмена между компонентами системы.
3.1.1.3.   Требования к связи с внешними системами.
Указать требования к характеристикам взаимосвязей создаваемой системы со смежными системами, требования к ее совместимости, в том числе указания о способах обмена информацией (автоматически, пересылкой документов, по телефону и т. п.).
3.1.1.4.   Требования к режимам функционирования.
Указать  требования к режимам функционирования системы.
3.1.1.5.   Требования к диагностированию системы.
Указать требования по диагностированию системы.
3.1.1.6.   Требования к развитию и модернизации.
Указать перспективы развития, модернизации системы.
3.1.2.   Требования к персоналу.
3.1.2.1.   Требования к численности.
Указать требования к численности пользователей системы.
3.1.2.2.   Требования к квалификации.
Указать требования к квалификации персонала, порядку его подготовки и контроля знаний и навыков.
3.1.2.3.   Требования к режиму работы.
Указать требуемый режим работы пользователей системы.
3.1.3.   Показатели назначения.
3.1.3.1.   Требования к степени приспособляемости.
Указать требуемую степень приспособляемости системы к изменению процессов и методов управления, к отклонениям параметров объекта управления.
3.1.3.2.   Требования к пределы модернизации и развития.
Указать допустимые пределы модернизации и развития системы.
3.1.3.3.   Требование к сохранению целевого назначения
Указать вероятностно-временные характеристики, при которых сохраняется целевое назначение системы.
3.1.4.   Требования к надежности.
3.1.4.1.   Перечень аварийных ситуаций, по которым должны быть регламентированы требования надежности.
Установить конечный перечень аварийных ситуаций, которые могут оказать существенное воздействие на результаты работы системы в целом.
3.1.4.2.   Требования к надежности системы и ее подсистем в целом и ее подсистем.
Установить измеримые требования к реакции системы на перечисленные аварийные ситуации.
3.1.4.3.   Требования к надежности технических средств и программного обеспечения.
Установить измеримые требования к надежности по всем видам технических средств и программного обеспечения, заявленных в разделе «Характеристики объекта автоматизации».
3.1.4.4.   Требования к методам оценки и контроля показателей надежности.
Описать контролируемые методы оценки установленных показателей надежности.
3.1.5.   Требования безопасности.
Требования по обеспечению безопасности при монтаже, наладке, эксплуатации, обслуживании и ремонте технических средств системы (защита от воздействий электрического тока, электромагнитных полей, акустических шумов и т. п.), по допустимым уровням освещенности, вибрационных и шумовых нагрузок.
3.1.6.   Требования к эргономике и технической эстетике.
Определить показатели системы, задающие необходимое качество взаимодействия человека с машиной и комфортность условий работы персонала.
3.1.7.   Требования к транспортабельности для подвижных АС.
Конструктивные требования, обеспечивающие транспортабельность технических средств системы, а также требования к транспортным средствам.
3.1.8.   Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы.
3.1.8.1.   Условия и регламент (режим) эксплуатации.
Указать условия, которые должны обеспечивать использование технических средств (ТС) системы с заданными техническими показателями, в том числе виды и периодичность обслуживания ТС системы или допустимость работы без обслуживания;
3.1.8.2.   Требования к помещению.
Указать предварительные требования к допустимым площадям для размещения персонала и ТС системы, к параметрам сетей энергоснабжения и т. п.
3.1.8.3.   Требования к обслуживающему персоналу
Указать требования по количеству, квалификации обслуживающего персонала и режимам его работы.
3.1.8.4.   Требования к условиям обслуживания технических средств.
Указать требования к составу, количеству, размещению и условиям хранения комплекта запасных частей, расходных материалов и т.д.
3.1.8.5.   Требования к регламенту обслуживания.
Установить периодичность, состав работ и формы отчетности о проведенном обслуживании
3.1.9.   Требования к защите информации от несанкционированного доступа.
Указать требования, установленные внутренними стандартами и регламентами.
3.1.10.   Требования по сохранности информации при авариях.
Указать перечень событий: аварий, отказов технических средств (в том числе - потеря питания) и т. п., при которых должна быть обеспечена сохранность информации в системе.
3.1.11.   Требования к защите от влияния внешних воздействий.
Указать требования по стойкости, устойчивости и прочности к внешним воздействиям (среде применения), в том числе требования к радиоэлектронной защите средств системы.
3.1.12.   Требования к патентной чистоте.
Указать перечень стран, в отношении которых должна быть обеспечена патентная чистота системы и ее частей.
3.1.13.   Требования по стандартизации и унификации.
Зафиксировать показатели, устанавливающие требуемую степень использования стандартных, унифицированных методов реализации функций (задач) системы, поставляемых программных средств, типовых математических методов и моделей, типовых проектных решений, унифицированных форм управленческих документов, установленных ГОСТ 6.10.1, в соответствии с областью их применения, требования к использованию типовых автоматизированных рабочих мест, компонентов и комплексов.
3.1.14.   Дополнительные требования.
Допускается удалить часть или все подразделы для описания общего требования.
3.1.14.1.   Требования к оснащению системы устройствами для обучения персонала и документацией на них.
Требования не предъявляются.
3.1.14.2.   Требования к сервисной аппаратуре, стендам для проверки элементов системы.
Требования не предъявляются.
3.1.14.3.   Требования к системе, связанные с особыми условиями эксплуатации
Требования не предъявляются.
3.1.14.4.   Специальные требования по усмотрению разработчика или заказчика системы.
Требования не предъявляются.
3.2.   Требования к функциям и задачам, выполняемым системой.
3.2.1.   Перечень функциональных подсистем.
Указать перечень подсистем и схему их взаимодействия.
Указать по каждой подсистеме перечень функций, задач или их комплексов (в том числе обеспечивающих подсистем), подлежащих автоматизации.
При создании системы в две или более очереди - перечень функциональных подсистем, отдельных функций или задач, вводимых в действие в 1-й и последующих очередях.
3.2.2.   Временные регламенты.
Для каждой подсистемы, функции и задачи (комплекса задач) указать временной регламент выполнения.
3.2.3.   Требования к качеству реализации функций.
Указать требования к форме представления выходной информации, характеристики необходимой точности и времени выполнения, требования одновременности выполнения группы функций, достоверности выдачи результатов.
3.2.4.   Перечень и критерии отказов.
Для каждой функции, по которой задаются требования по надежности, указать перечень отказов и их критерии.
3.3.   Требования к видам обеспечения
3.3.1.   Математическое обеспечение.
Указать требования к составу, области применения (ограничения) и способам, использования в системе математических методов и моделей, типовых алгоритмов и алгоритмов, подлежащих разработке
3.3.2.   Информационное обеспечение.
Допускается удалить часть или все подразделы для описания общего требования.
3.3.2.1.   Требования к составу, структуре и способам организации данных в системе.
Требования не предъявляются
3.3.2.2.   Требования к информационному обмену между компонентами системы.
Требования не предъявляются
3.3.2.3.   Требования к информационной совместимости со смежными системами;
Требования не предъявляются   
3.3.2.4.   Требования по использованию государственных классификаторов, унифицированных документов и внутренних классификаторов.
Требования не предъявляются
3.3.2.5.   Требования по применению систем управления базами данных;
Требования не предъявляются
3.3.2.6.   Требования к структуре процесса сбора, обработки, передачи данных в системе и представлению данных;
Требования не предъявляются
3.3.2.7.   Требования к защите данных от разрушений при авариях и сбоях в электропитании системы;
Требования не предъявляются
3.3.2.8.   Требования к контролю, хранению, обновлению и восстановлению данных;
Требования не предъявляются
3.3.2.9.   Требования к процедуре придания юридической силы документам, продуцируемым техническими средствами АС (в соответствии с ГОСТ 6.10.4).
Требования не предъявляются
3.3.3.   Лингвистическое обеспечение.
Указать требования к применению в системе языков программирования высокого уровня, языков взаимодействия пользователей и технических средств системы, а также требования к кодированию и декодированию данных, к языкам ввода-вывода данных, языкам манипулирования данными, средствам описания предметной области (объекта автоматизации), к способам организации диалога.
3.3.4.   Программное обеспечение.
Допускается удалить часть или все подразделы для описания общего требования.
3.3.4.1.   Перечень сторонних программ и собственных разработок, используемых модифицируемых при автоматизации процесса.
Требования не предъявляются
3.3.4.2.   Требования к независимости программных средств от используемых СВТ и операционной среды.
Требования не предъявляются
3.3.4.3.   Требования к качеству программных средств, а также к способам его обеспечения и контроля
Требования не предъявляются
3.3.4.4.   Требования по необходимости согласования вновь разрабатываемых программных средств с фондом алгоритмов и программ.
Требования не предъявляются
3.3.5.   Техническое обеспечение.
Допускается удалить часть или все подразделы для описания общего требования.
3.3.5.1.   Требования к видам технических средств.
Указать требования к видам технических средств, в том числе к видам комплексов технических средств, программно-технических комплексов и других комплектующих изделий, допустимых к использованию в системе
3.3.5.2.   Требования к характеристикам технических средств.
Указать требования к функциональным, конструктивным и эксплуатационным характеристикам средств технического обеспечения системы.
3.3.6.   Метрологическое обеспечение.
Допускается удалить часть или все подразделы для описания общего требования.
3.3.6.1.   Предварительный перечень измерительных каналов.
Требования не предъявляются.
3.3.6.2.   Требования к точности измерений параметров и (или) к метрологическим характеристикам измерительных каналов.
Требования не предъявляются.
3.3.6.3.   Требования к метрологической совместимости технических средств системы
Требования не предъявляются.
3.3.6.4.   Перечень управляющих и вычислительных каналов системы, для которых необходимо оценивать точностные характеристики;
Требования не предъявляются.
3.3.6.5.   Требования к метрологическому обеспечению.
Указать требования к метрологическому обеспечению технических и программных средств, входящих в состав измерительных каналов системы, средств, встроенного контроля, метрологической пригодности измерительных каналов и средств измерений, используемых при наладке и испытаниях системы.
3.3.6.6.   Вид метрологической аттестации с указанием порядка ее выполнения и организаций, проводящих аттестацию.
Требования не предъявляются.
3.3.7.   Организационное обеспечение.
Допускается удалить часть или все подразделы для описания общего требования.
3.3.7.1.   Требования к структуре и функциям подразделений, участвующих в функционировании системы или обеспечивающих эксплуатацию.
Требования не предъявляются.
3.3.7.2.   Требования к организации функционирования системы и порядку взаимодействия.
Требования не предъявляются.
3.3.7.3.   Требования к защите от ошибочных действий персонала системы.
Требования не предъявляются.
3.3.8.   Методологическое обеспечение.
Указать  требования к составу нормативно-технической документации (перечень применяемых при ее функционировании стандартов, нормативов, методик, регламентов и т. п.).
3.4.   Состав и содержание работ по созданию системы.
Допускается удалить часть или все подразделы для описания общего требования.
3.4.1.1.   Перечень стадий и этапов работ по созданию системы и сроки их выполнения.
Заполнить в соответствии с ГОСТ 24.601.
3.4.1.2.   Перечень организаций - исполнителей работ
Указать перечень организаций и ссылки на документы, подтверждающие согласие этих организаций на участие в создании системы, или запись, определяющую ответственного (заказчик или разработчик) за проведение этих работ.
3.4.1.3.   Перечень документов, предъявляемых по окончании соответствующих стадий и этапов работ.
Заполнить в соответствии с ГОСТ 34.201-89.
3.4.1.4.   Вид и порядок проведения экспертизы технической документации.
Указать стадии, этапы, объем проверяемой документации и организацию - эксперт.
3.4.1.5.   Программу работ, направленных на обеспечение требуемого уровня надежности разрабатываемой системы.
Заполнить при необходимости.
3.4.1.6.   Перечень работ по метрологическому обеспечению.
Заполнить требования на всех стадиях создания системы с указанием их сроков выполнения и организаций-исполнителей (при необходимости).
3.5.   Порядок контроля и приемки системы.
Допускается удалить часть или все подразделы для описания общего или расширенного требования.
3.5.1.1.   Виды, состав, объем и методы испытаний системы и ее составных частей.
Указать виды испытаний в соответствии с действующими нормами, распространяющимися на разрабатываемую систему.
3.5.1.2.   Общие требования к приемке работ по стадиям.
Перечень участвующих сотрудников, место и сроки проведения, порядок согласования и утверждения приемочной документации.
3.5.1.3.   Статус приемочной комиссии.
Например. Государственная, межведомственная, ведомственная.
3.6.   Требования к порядку ввода системы в эксплуатацию.
Привести перечень основных мероприятий и их исполнителей, которые следует выполнить при подготовке объекта автоматизации к вводу системы в действие.
3.6.1.1.   Изменения в поступающей и выходной информации.
Описать мероприятия по приведению поступающей в систему и выходной информации в соответствие с требованиями, предъявленными к информационному и лингвистическому обеспечению системы.
3.6.1.2.   Подготовка технических и программных средств.
Указать перечень изменений
3.6.1.3.   Изменения методов управления на объекте автоматизации.

3.6.1.4.   Организационные изменения.
Описать расширение функций и обучение существующего персонала или создание необходимых для функционирования системы подразделений и служб. Сроки и порядок комплектования штатов и обучения персонала.
3.7.   Требования к документированию.
Привести согласованный разработчиком и заказчиком системы перечень подлежащих разработке комплектов и видов документов, соответствующих требованиям ГОСТ 34.201-89 или внутренним регламентам. При отсутствии государственных стандартов, определяющих требования к документированию элементов системы, в раздел включают требования к составу и содержанию таких документов.
3.8.   Источники разработки.
В разделе должны быть перечислены документы и информационные материалы (технико-экономическое обоснование, отчеты о законченных научно-исследовательских работах, информационные материалы на отечественные, зарубежные системы-аналоги и др.), на основании которых разрабатывалось ТЗ и которые должны быть использованы при создании системы.

И вперёд.
Ненужное - удалить.
Нужное - добавить.
ГОСТ это допускает.

Рекомендация.
Так как ТЗ на отдельный отчет на практике никогда не оформляется по ГОСТ-34 (он слишком громоздок для этого), то единственная видимая цель подобного подметания плаца ломом - оценить Вашу способность думать о задаче всесторонне.
Так что постарайтесь заполнить максимальное количество пунктов.

27
Для всех / Re: Выбор UML диаграммы
« : 03 Ноября 2015, 12:22:15 »
<...>
Роли работают с разными сущностями в системах, среди которых можно выделить одну главную сущность - заявку Клиента.

Мое руководство хочет видеть действия этих ролей на одной схеме. Как это отобразить я ума не приложу. На диаграмме последовательности? Коммуникации?
<...>

Для графического отображения процессов этого уровня лучше всего подходит BPMN. Просто потому, что он и создавался под процессы этого уровня.

Если же всё упёрлось в UML - попробуйте перехитрить сами себя и сделать всё на Диаграмме Активностей. Тот же BPMN если не брать детали

29
Добрый день.

Вы явным образом привели копипаст (лучше было бы заскринить) из существующей системы. Соответственно, модель данных у Вас уже есть.
Что требуется то ?
1. Понять как это работает и модифицировать отображение не влезая в таблицы ?
2. Разработать новую систему хранения и отображения ?
3. ?

1. - очень сложно
3. - задайте свой вариант для обсуждения.
2. - в последние годы все стараются делать хранение древовидных структур так, чтобы потом их можно было без труда перепеарсить в XML.

В этом случае Вам нужны:
ID записи (уникальный, сплошная нумерация)
ID уровня записи (уровень вложенности сегмента)
ID родительского сегмента (ссылка)
остальное - по задаче, но я не вижу в ней сильных проблем - несколько полей со ссылками на классификаторы + продумать сами классификаторы.


30
Да нормально дружен.
Но "юрист защищающий сам себя ...." :)))

Спасибо,
я понял что штатного решения в Спарксе нет

Страницы: « 1 2 3 4 5 6 »