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

×


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

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


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

16
Работа / Re: Разработчик отчетов на JasperReports
« : 17 Октября 2017, 18:07:45 »
А при чём здесь форум аналитиков?

17
Вот ещё статья Михаила Острогорского, простым языком о компонентах, подсистемах и видах обеспечения.
http://philosoft-services.com/gost34asconcept.zhtml

18
Следует ли ожидать появления различных конфессий и сект, претендующих на единственное толкование "истинного UML" , и обкладывающих друг друга анафемами? ;)

19
Но сейчас пока вопрос более узкий: "инструкции - это компонент системы? или обеспечение? или подсистема? и почему?"

Есть прекрасный справочник по определениям ГОСТ. :)

http://tdocs.su/8473
Цитировать
Компонент автоматизированной системы (АС) (Automated system component) по ГОСТ 34.003-90
Часть АС, выделенная по определенному признаку или совокупности признаков и рассматриваемая как единое целое

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

Насколько я знаю сложившуюся практику, компонентами АС принято называть составляющие программного и технического обеспечения. Документация - составная часть АС сама по себе. А требования к тому, что должно содержаться в документации, размываются по разным разделам ТЗ, как я тут уже писал - в частности, в требованиях к методическому и организационному обеспечению. А на состав и содержание документации есть отдельные стандарты:

http://www.rugost.com/index.php?option=com_content&view=article&id=91:34201-89&catid=22&Itemid=53
http://www.rugost.com/index.php?option=com_content&view=article&id=98:50-34698-90&catid=22&Itemid=53

ГОСТы - это такое болото: чем дальше лезешь, тем больше вязнешь.

20
Под АС понимается всё перечисленное и не перечисленное (например, железо).

Справочные данные - информационное обеспечение.
Обязанности сотрудников - организационное обеспечение.
Методы работы сотрудников - методическое обеспечение.

Вот только зачем вам всё это...

21
На сайте Вебурситета открыт сезон онлайн-курсов по моделированию для аналитиков с разным уровнем подготовки.


Курс Объектно-ориентированный анализ на языке UML для аналитиков, уже имеющих опыт моделирования, проводит Николай Киреев. Начало курса 17 сентября.

Курс Моделирование бизнес-процессов в нотации BPMN проводит Наталья Желнова. Начало 10 октября.

Курс Введение в корпоративную архитектуру для аналитиков, архитекторов и всех, кто хочет познакомиться с языком ArchiMate, проводит Александр Байкин. Начало 18 октября.

Курс Введение в моделирование для аналитиков для тех, кто только начинает разрабатывать визуальные модели, провожу я, Григорий Печенкин. Начало 25 сентября.


Все курсы проводятся онлайн, в формате вебинаров. Все курсы включают практику моделирования и домашние задания. Подробное описание курсов и стоимость участия смотрите по приведенным ссылкам.

22
Доброй ночи, форумчане!
Закончил вышку в Вышке по экономической специальности. Не подскажите, где можно закончить курсы/школы /дистанциооные курсы в Москве по аналитике?  ;)

Вы имеете в виду бизнес-анализ (BA) или бизнес-аналитику как подвид BI?

23
Здравствуйте подскажите пожалуйста, какие есть методы проведения эффективных интервью? Что это за методы? Речь как я понимаю не идет о анкетировании, собеседовании. опросах и т.д.

Ну вы же их и перечислили. Литературы для аналитиков по этой теме я не встречал. Но есть практикумы, например: http://user_interview.tilda.ws

24
А зачем тебе состояние Не подтвержден, да еще с принудительным событием Закрыть ? Ест вероятность передумать? Тогда почем переход исключительно в закрыт?

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

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

Если между состояниями возможны другие пути перехода, то имеет смысл сделать из них отдельную диаграмму состояний.

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


А вообще, ваш случай прекрасно ложится на область применения VISIC :)
Сценарий взаимодействия можно изобразить схемой "бассейн", состояния и переходы - схемой "гирлянда".

26
Есть книга «Управление проектом на одной странице» Кларка Кэмпбелла. Там приводится что-то очень похожее.

Таблички и планы можно строить разные, но основная работа PM состоит не в этом. Если эти таблички помогают менеджеру – хорошо. Если он вместо работы с людьми строит красивые таблички – ничего хорошего.

27
Я предлагаю изобрести ещё какой-нибудь язык для тутошней планеты-форума. Чтобы мои (хотя бы) реплики не кастировались по воле составителей ответов на них.

В смысле, в цитатах? Или был отредактирован какой-то ваш пост?
Спрашиваю, потому что я иногда по ошибке нажимаю кнопку "Редактировать" вместо "Цитировать", и мог непреднамеренно что-то удалить.

Чем не устраивает диаграмма классов как основа "муже-яйцевых" аналитических схем? Тем, что она будет понятна помимо аналитиков ещё и архитекторам, и программистам, и, страшно подумать, каким-то прогам? 

Да всем устраивает, если с её помощью аналитики общаются с архитекторами и программистами и друг друга понимают.

Всё, что я здесь (и в других местах) говорю о неприменимости UML, касается общения аналитиков с заказчиками и простыми пользователями. Там тоже очень нужна визуализация, но использование UML не решает проблему недопонимания, а усугубляет её. То есть ваша метафора работает в другую сторону: с ними ведётся общение на строительном жаргоне вместо обычного русского языка.

28
Для изобретённой "мужико-яйцевой" схемы можно воспользоваться подмножеством диаграмм классов UML, в него она впишется без нарушения стандарта. Можно даже сделать профиль, и "мужико-яйцевые" схемы начнут понимать UML-инструменты, умеющие профили. Но почему-то это не годится, а годится декларировать, мол, язык негодный.

Кто сказал, что язык негодный? UML - отличный язык! Для архитекторов и программистов.

29
Такая визуализация должна просто сопровождаться легендой.
Овал - интерес
Человечек - тип субъекта в племени
Стрелка с полым треугольником - специализация

А без легенды непонятно? В специальных пояснениях нуждается только стрелка.

30
Ну вот, задвигалось. Благодарю за участие в теме.
Для обозначения ответственностей есть стандартная нотация: http://yuml.me/1f7de978
И есть методика, поясняющая, что исполнитель внутри [бизнес-]системы и элемент контекста [бизнес-]системы aka actor -- не одно и то же. Но зачем, всё это, если можно изобрести какую-то мимикрию под стандартные обозначения и связывать с ними свои собственные смыслы? Красоту подобных визуализаций может оценить лишь тот, кто входит в соответствующее "языковое гетто".

В этой стандартной нотации для "ответственностей" всё прекрасно: и скобочки после ответственностей, и горизонтальные чёрточки, делящие прямоугольник на три части (а зачем посередине пустая, кстати?), а особенно прекрасны интуитивно понятные любому человеку правила написания: МолодойВоин, охотитьсяНаЗверя.

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

"Вот за это они нас и не любят." (c)