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

×


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

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


Сообщения - Григорий Печенкин

31
Действительно, использование диаграммы вариантов использования здесь довольно сомнительно, поскольку закрепляет ответственности действующих лиц, а не ответственности системы по отношению к действующим лицам. Вообще тут нет описания использования и взаимодействия, а только описание ответственностей класса.

Конечно, никто не запрещает использовать нотацию таким образом. но тогда нужно оговариваться, что это не совсем UML. А какое-то свое собственное изобретение.

В этом же сообщении указана ссылка на выступление Гришы на конференции. Гриша, похоже тебе стоит включить диаграмму в свою копилку :). В ней тараканов в 10 раз больше, чем в диаграмме вариантов использования из методички известного вуза в твоем выступлении, по которой и на мой взгляд делаешь серьезную ошибку, уличая автора в смертных грехах смешивания уровней ВИ.


Это не UML и не диаграмма вариантов использования, но это прекрасная визуализация.

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

Об этом я говорил на Analyst Days в этом году. Видео пока нет, выложена только презентация. http://analystdays.ru/ru/talk/45843 Слайд 31 иллюстрирует один из первых зафиксированных случаев использования этой диаграммы в истории.

Я вообще об этом, по-моему, на каждом углу твержу, но меня не понимают. Ну ничего, мы разрушим эту монополию. :)
Поэтому решительно предлагаю эту диаграмму переименовать, а выражение "диаграмма вариантов использования" забыть, как страшный сон.
http://visic.info/pictures/roles-n-goals/61/

32
Приглашаем Веб-аналитика, Москва kkosti1973@yandex.ru

Ну и каша же в голове у работодателя.
https://ru.wikipedia.org/wiki/Веб-аналитика

33
Здраствуйте, у меня возникла проблема с созданием UML диаграмм... Я пишу бакалавр на тему Development of Information System for Transport and Freight. Саму систему я уже написал на пхп языке, но вот с проектированием беда. К сообщению прикладываю скриншоты case diagram, базы данных и самого сайта фотки

Сначала написать систему, а потом её спроектировать  - это по-нашему! :)

PHP же объектно-ориентированный язык вообще-то. Вы с использованием классов систему писали? Можно сгенерировать диаграмму классов прямо из кода - например, с помощью Enterprise Architect.

34
Так аналитика или писателя?
(Как говорилось в одном старом анекдоте, а если ко мне сзади швабру привязать, то я вам тут ещё и полы помою.)

35
Тип который написал книжку Основы uml. Хочется спросить основы для кого? для программистов? тогда понятно зачем расписывать программный код на нескольких листах.
Но если это основы для широких масс, то где простые примеры без словосочетаний..типа ассоциация-это непрерывная линия между двумя классами, направленная от исходного к целевому классу. Только что такое класс, и как понять какой целевой а какой нет автор не удосужился объяснить.

UML ориентирован в первую очередь на программистов, что бы там ни говорили про его универсальность.

37
А почему тема так называется?

38
Для всех / Re: Вопрос в тесте
« : 02 Марта 2017, 14:51:35 »
Ну зачем в IT-индустрии люди, не понимающие, что такое требования, и зачем они нужны?

39
Для всех / Re: Вопрос в тесте
« : 02 Марта 2017, 10:37:08 »
Здравствуйте, дорогие форумчане! И снова обращаюсь к Вам за помощью.

и каждый раз как первый

Не даёт мне покоя преподаватель с своими тестами, предмет для меня не основной и от аналитики я далёк. Помогите, пожалуйста, с тестами!)

Вы на медицинском учитесь? Действительно, чего это он...

Вариантов ответа может быть несколько. Заранее спасибо!!!

И вам спасибо!

40
А что это за сердитый мужчина на заставке? Я его прямо боюсь :)

41
ТЗ обычно разрабатывается до начала создания продукта и содержит, в основном, бизнес-требования.
А пользовательские истории - это, с одной стороны, пользовательские требования довольно низкого уровня, а с другой - элемент управления требованиями. Включение их в ТЗ не имеет смысла, их место в бэклоге, который можно считать "рабочим документом" команды разработки.

Посмотрите, например, на "Электронный журнал".

Вот ТЗ со структурой, примерно соответствующей ГОСТ 34 (уровень бизнес-требований): http://eljur.ru/elektronnyj-zhurnal-sootvetstvuet-trebovaniyam-ministerstva-obrazovaniya-i-nauki
Вот довольно детальный перечень функций: http://eljur.ru/vse-funkcii-elektronnogo-zhurnala-dlya-shkol

Вполне можно предположить, что разработка велась с использованием практик Agile - итерациями и по бэклогам, включающим пользовательские истории. Но с их помощью только реализуются функции, которые, в свою очередь, реализуют требования, перечисленные в ТЗ. ТЗ живёт долго, на протяжении всей жизни продукта, а пользовательские истории - как бабочки-однодневки: написали, реализовали и выбросили.

42
https://www.wunderlist.com/ru/ (пользуюсь постоянно для личных задач)
https://asana.com (пользуюсь иногда для задач, которыми можно делиться)

43
что то не открывается страница с классификацией....

Странно, у меня открывается. Вот цитата оттуда:

Цитировать
Уровни сложности
Сложность запроса определеяет, насколько серьезна проблема и как данный инцидент должен быть приоритезирован. Сложность инцидентов будет классифицированна в соответствии с следующими определениями:

Сложность 1 “Критичная”
Когда данный инцидент останавливает критически важные бизнес процессы заказчика и обходной путь не доступен, то такой кейс должен быть приоритезирован выше остальных и работы должны начаться немедленно.
Например: База данных недоступна, не работают алгоритмы закрытия периодов в финансовых системах и т.д.

Сложность 2 “Высокая”
Когда инцидент уменьшает функциональность критически важных бизнес процессов заказчика и обходной путь невозможен.
Например: Повторяющаяся ошибка, проблемы с платежами одному сотруднику \ клиенту, ошибка расчетов и т.д.

Сложность 3 “Средняя ”
Когда приложение вызывает ошибку, которая уменьшает, но не запрещает доступ пользователям. Т.е. пользователи могут работать, но нуждаются в поддержке и помощи.
Например: Небольшие ошибки, которые имеют небольшое влияние на пользователей.

Сложность 4 “Низкая”
Когда инцидент по сути является заявкой на изменение. Т.е. запрашиваемой функциональности в системе раньше не было. Такой кейс должен быть занесен в систему с низким приоритетом.

44
Википедия -- такая википедия. Докладчикам на тему, почему UML вредно учить, рекомендую включить картинку в свои подборки "смешных диаграмм".

Ну так у меня примерно пол-доклада и состояло из смешных диаграмм.
https://www.greesha.ru/speeches/почему-uml-это-плохой-выбор-для-обучения/

45
А зачем два поста с одной и той же вакансией?