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

×


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

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


Сообщения - Сергей()

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 »
1
Если же Вы говорите серьезно, может быть обоснуете?

2
Нет и не может быть таких программных продуктов. По простой фундаментальной причине. Даже по двум причинам:
1) ...
2) Менеджеры не понимают, что одна из основных задач менеджеров - добиться простаивания сотрудников.

PS. Диаграмма Ганта становится тыквой в момент нажатия кнопки "Save". Забудьте про эту диаграмму. Совсем.

Мне кажется, Вы это говорите несерьезно.

Да, программы подобного рода часто "подводят" наши ожидания.
Очень часто менеджеры "злые" на эти программные продукты.

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

Видимо, на данном историческом этапе разработчики пока не смогли запрограммировать этот алгоритм.

3
Здравствуйте!

Иногда MS Project при расчете расписания проекта (при выравнивании загрузки ресурсов) ведет себя непредсказуемо:
вроде бы нормальное расписание ломается, и найти причину этой "поломки" и исправить расписание очень трудно.
Из-за этого есть очень горячее желание попробовать какое-то другое ПО аналогичного назначения.

Посоветуйте, пожалуйста, какие есть программные продукты, которые "умеют" хорошо рассчитывать загрузку ресурсов?
С учетом: сложных зависимостей между задачами, ограничений, разных календарей ресурсов и т. д.

4
Первое, что смущает: это стрелка от "Пропуск информации в канал" к "Информационному каналу".
Обычно актер является инициатором взаимодействия с моделируемой системой.
А здесь сама система (фильтр) инициирует передачу данных в канал.
Нет ли в этом ошибки?

Второй момент.
ВИ "Контроль корректности" - это как бы внутренний процесс, "невидимый" для внешних актеров.
По идее его не нужно отображать на диаграмме.
Однако, без него не будет понятен смысл.
Как правильно: отображать или нет этот ВИ?

5
Здравствуйте!
Задачка вроде простая, но поставила в тупик.

Нужно сделать диаграмму Use Cases для фильтра сообщений, которые могут поступать от некоторого источника в канал передачи этих сообщений.
Логика простая:
1) Фильтр принимает сообщение от источника информации.
2) По заданным в нем правилам определяет - является ли данное сообщение корректным
3) Если сообщение корректное - передает его дальше в канал передачи
4) Если сообщение некорректное - выдает ошибку источнику.

Посмотрите, мою схему.
Подскажите, пожалуйста, что сделано не правильно?
Как будет правильней?


6
Оказалось, это проблема именно в конкретной версии PowerDesigner.
На другой, более новой версии этой ошибки нету: все линии-связи рисуются правильно.

7

Оказывается, эта проблема наблюдается только для линии типа Use Case Assosiation.
Для других линий, если задать им формат такой как на рисунке, то линии можно конфигурировать по любому.

А вот для Use Case Assosiation, даже если указать такой же тип линии, то PowerDesigner всегда рисует линию автоматически.
Может это недоработка какая-то в самом PowerDesigner?

8
Здравствуйте!

Кто хорошо знает PowerDesigner, подскажите, пожалуйста:
как можно отменить автоматическое рисование "маршрута" (траектории, расположения) линии-связи между двумя объектами?

Сейчас когда от одного объекта к другому тянешь линию-связь, PowerDesigner автоматически делает ее "маршрут".
Очень часто эти "маршруты" неудобны.
При попытке изменить "маршрут" линии и сдвинуть ее, она скачком перескакивает на другой маршрут.
При перетаскивании объекта - линии, ведущие к нему и от него, могут перескочить совсем в другие места, чем было перед этим.

Можно ли изменить это поведение PowerDesiner?
Если да, то как?

9
Если масштаб уже выставлен на минимум, то ответ очевиден: никак.
Печально :(

Попробуй на диаграмме зажать Ctrl и покрутить колесиком мыши.
А так сработало!
Спасибо.

А вообще лучше декомпозировать на несколько вложенных диаграмм, а общую диаграмму распечатать и использовать как плакат на стену)))
Да там диаграмма в общем-то небольшая.
Всего 7 элементов действий, вершины начало-конца, 3 условия, и 6 "слияний".
Но и это не помещается на одном экране.

10
Здравствуйте!

Сделал в EA диаграмму.
Диаграмма достаточно большая, не вмещается на одной "странице" экрана.

Как уменьшить масштаб так, ее можно было просмотреть целиком?

Внизу есть кнопки масштаба (-) (+).
Но "минус" у меня уже сдвинут до предела, дальше не сдвигается.

11
Не так. АС не состоит из видов обеспечения.
А я не говорил про "виды обеспечения".
Раз есть виды, значит есть конкретные элементы, которые можно по определенному признаку разделить на эти виды.
Вот про эти конкретные элементы АС я и говорил в определении "обеспечения".
То есть я имел ввиду, что (повторю свое определение):
обеспечение - это конкретные элементы системы, их совокупность.


Каждый из  видов обеспечения отражает, как систему можно описать с перечисленных  позиций: какая математика ... какая информация ...
Ещё раз: виды обеспечения - это не структура, это точки зрения.
Согласен.
Виды обеспечения - это "группировка" конкретных элементов системы с определенной точки зрения.


Так будет правильно?

12
Деление по видам обеспечения, по подсистемам и компонентам не следует смешивать.
Да, я это понимаю, что это разные вещи. Поэтому-то и поднял этот вопрос.

Кстати, термина "подсистема" в ГОСТ 34.003-90 не определено ))
Зато есть понятие "Функциональная подсистема АСУ "(ФП АСУ) по ГОСТ 24.701-86
Значит, скорее всего когда упоминается «подсистема», имеется ввиду именно «функциональная подсистема».

То есть получается так.
Обеспечение – это все, из чего состоит система, конкретные элементы системы.
Подсистема (функциональная подсистема) – это совокупность элементов АСУ (конкретных элементов обеспечения), которые выполняют конкретную функцию системы, то есть выделенных по функциональному признаку.
Компонент – это совокупность элементов АСУ (конкретных элементов обеспечения), объединенных по любому другому не-функциональному признаку.

Согласны?

Должностные инструкции не являются частью системы и не относятся к системе. Это документы организации, в которых указываются обязанности СОТРУДНИКА. Не надо пытаться использовать  для них 34 серию ГОСТ.
В лучшем случае в них может быть ссылка на инструкции к тому ПО, которым сотрудник должен пользоваться при выполнении своих должностных обязанностей…
Мы в них пропишем ссылку на «Порядок выполнения бизнес-процесса ХХХ».
Вот этот порядок наверно будет частью системы?

Разницу понимаете? Пользователь - это роль. Разные сотрудники могут авторизоваться в системе с одной и той же ролью пользователя, при этом они могут быть сотрудниками с разными…
Да, это понятно.

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

Если, чтоб работало, то в ТЗ я бы записал требование к должностным инструкциям. Что они должны быть созданы в рамках проекта. Перечислить какие инструкции должны быть и т.д. (желательно).
Да, так мы и задумывали.
Чтобы наша АС работала, эти инструкции должны быть.

Вернее, сами инструкции уже есть.
Мы впишем в ТЗ требование, что в них нужно внести изменения, необходимые для работы нашей АС.
Как я писал выше, мы в инструкции вставим ссылку на "Порядок выполнения бизнес-процесса ХХХ".

После изменения должностных инструкций, придется повторно ознакомить с ними сотрудников.


13
2. АС в числе прочих компонент включает персонал - как пользователей, так и эксплуатационный (т.е. тех, кто обеспечивает функционирование).
Материал, являющийся контентом пользовательских инструкций (или должностными в вашем конкретном случае) относится к методическому (иногда к организационному) обеспечению АС.
Чисто на интуитивном уровне это понятно.

Но вот что значит "обеспечивает функционирование"?
Где граница между самим "функционированием" и "обеспечением функционирования"?
По каким признакам разделить - это подсистема, это компонент системы, а это обеспечение системы?

14
Статья называется О формализации процесса разработки программного обеспечения.
А как связаны между собой SOLID-принципы и процесс разработки ПО?
Ведь SOLID-принципы, насколько я знаю, имеют отношение чисто к построению программного кода.
И с процессом разработки ПО не связаны.

15
Есть прекрасный справочник по определениям ГОСТ. :)
...
Прекрасен он, в частности, тем, что эти определения практически бесполезны, так как допускают разнообразные толкования.
Вы очень точно сказали!
Вот именно после прочтения этих определений, я и создал данную тему.
Так как по этим определениям я так и не смог понять: чем же являются упомянутые должностные инструкции - компонентом, подсистемой или обеспечением АС.

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 »