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

×


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

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


Сообщения - Denis Beskov

901
Что важно:

1. Вы вообще молодец, что решились выразить и описать своё мнение.

2. Было бы ещё лучше, если бы вы назвали себя и дали контакты. А то получается, что у какого-то анонима есть мнение. И что?

902

Вы уж если комментировать собрались, прочитайте весь текст, а не первые 2 предложения.
Зачем тратить своё время, если невооружённым глазом видно, что вы ошибаетесь в фундаментальных вещах?

Цитировать
А по поводу определений, рекомендую прочитать для начала хотя бы первый абзац вот отсюда:
http://ru.wikipedia.org/wiki/%D0%A3%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5_%D1%82%D1%80%D0%B5%D0%B1%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%D0%BC%D0%B8
1. В википедии представлены не согласованные мнения экспертов, а мнения гиковской толпы. Хотите, завтра в этой статье будет написано нечто совсем иное?

2. Согласованные мнения экспертов тоже устаревают.

903
Цитировать
в общем случае присутствуют следующие основные шаги:

...

2. сбор требований заказчика по автоматизации бизнес-процесса;
Собирать можно только то, что где-то лежит готовое. Обычно требования не лежат готовыми, их нужно выявлять, помогая ЗЛ осознавать их деятельность, интересы, намерения. Кроме заказчика есть и другие источники требований, прежде всего — потенциальные пользователи.

Цитировать
3. структурирование требований к системе автоматизации;
Вроде в заголовке было ПО, почему вдруг здесь система автоматизации?

Цитировать
4. детализация требований;
А как же моделирование и анализ, как средства обеспечения качества требований (прежде всего — полноты и непротиворечивости)?

Цитировать
5. утверждение требований в виде документа Техническое задание;
Это в общем-то случае? В общем случае происходит согласование принятых решений относительно назначения, внешнего устройства и поведения системы/продукта. Эти решения могут лечь просто протоколом встречи (во внутренней разработке), строками в бэклог и т.д., а не только в ТЗ.

Цитировать
6. управление изменениями требованиями на этапах разработки, тестирования и эксплуатации системы.

Шаги 1-5 — вообще не про управление. Они про создание требований. Это всё равно, что включать работы по производству автомобиля в понятие «управление
автомобилем».

Управление требованиями — это прежде всего управление рамками, приоритетами и статусом готовности требований, а потом уже трассировками и изменениями.

Вы сначала вообще разберитесь, о чём пишете.

904
Аня, ты хочешь, чтобы мы помогали тебе отмазываться?

Если у тебя вопрос практический  — зачем ТЕБЕ это знать — то тут мы не поможем )

Если вопрос теоретический «для чего вообще может понадобиться оценка трудоёмоксти аналитику», то у меня встречный вопрос — а зачем это тебе?

Обычно эта оценка нужна для управления требованиями как части управления ходом создания продукта (рамки, очерёдность).

905
Непонятно, зачем частному лицу 1 лицензия на промышленную СУТ.

906
создает дизайн системы, в рамках верхнеуровневой архитектуры, заданной архитектором
Максим, можно ссылку на такое классическое определение? Классическое для какой культуры?

Почему ты считаешь, что разработка use case'ов — это бизнес-анализ?

908
Условия получения ответа на этот вопрос описаны мной во втором посте обсуждения.

909
Спустя 5 лет-то? Ну наверняка где-то какая-то удалённая работа есть.

910
Максим, аналитик отвечает за проектирование ВНЕШНИХ свойств системы. Архитектор, разработчик — ВНУТРЕННЕГО устройства.

Внешние свойства описываются логикой взаимодействия, НФТ и пользовательским интерфейсом.

Часто, особенно для заказных систем, внутренней разработки описать логику взаимодействия трудно без предварительного/параллельного анализа бизнес-процессов.

Второй необязательной деятельностью является сущностное моделирование.

Часто ещё аналитик описывает внутренние алгоритмы, но на языке предметной области, а не платформы разработки.

Иногда проектирует ИС как ИС, а не просто ПО, но такое редко кому достаётся по ряду причин.

Резюмируя, типовыми объектами работы аналитика являются, по мере убывания частоты:
1. Внешнее поведение системы
2. Алгоритмы (бизнес-правила)
3. Внешний облик системы
4. Устройство предметной области
5. Процесс, который строится или меняется при создании/доработке этой программной системы
6. Организационно-техническая система (бизнес)

Собственно 1, 3 и 4, 5 — это то, что больше всего обсуждалось на конференции. Всё разумно.

911
Отчёт Макса Цепкова: http://blogs.uml2.ru/post/LAF-2012

912
Примеры / Re: include в use case
« : 18 Июня 2012, 12:36:58 »
Если вы сами задаётесь вопросами при рисовании диаграммы, то что будут делать ЧИТАТЕЛИ вашей диаграммы?

913
Наш с Сашей Байкиным совыпусник кафедры САПР (РК-6) факультета Робототехника и комплексная автоматизация Бауманки, в настоящий момент гендиректор Mail.ru, решил вернуться к истокам и основал инвестиционный фонд, который будет финансировать проекты по созданию персональных роботов: http://techcrunch.com/2012/06/15/mail-ru-ceo-starts-25-million-fund-to-spark-personal-robotics-start-ups/

914
Zoho Creator

Sparx вообще не про это

915
Обучение / Re: Переквалификация
« : 04 Июня 2012, 00:02:08 »
Начните хотя бы с IDEF0. Я читаю этот курс студентам второго курса и использую на практике, он дает очень хороший результат.
Напишите плс где-нибудь, для каких задач IDEF0 (или курс, я не понял, что именно) даёт хороший результат.