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

×


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

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


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

2236
Моделироваение/проектирование - это все равно что програмирование!
Т.е. есть задача - ее решить можно 20 способами програмирования!
То же самое можно сказать относительно кулинарного искусства, воспитания детей, и т.д. :) Я не думаю, что множественность методов решения задачи можно считать хорошими критериями для сходства дисциплин.

Моделирование направлено на изучение, описание, понимание проблемы и продумывание, детализацию и описание решения. Программирование - на реализацию решений. Разница примерно такая, как между Советом в Филях и Бородинским сражением.

2237
Да я понимаю, что предлагал. Просто надо как-то выделить четче темы. Может как-нибудь так?
Теория
Практика
Инструменты
Это будут борды, а в них реализовать несколько категорий?
Это совсем другое! Теорию, практику и инструменты имеет смысл различать уже в рамках какой-либо дисциплины, посвящённой решению какой-либо задачи, ведению какой-либо деятельности.

Как минимум из предложенного ранее мной списка я думаю точно стоит выделить (в смысле я готов их вести и развивать):
  • Постановка задачи (Целеполагание)
  • Моделирование бизнеса
  • Требования к ПО
  • Анализ и проектирование систем
  • Архитектура ИС
  • Процессы разработки ПО (Инженерия ПО?)
  • Управление проектами

2238
Вообще надо все-таки переименовать категории в соотвествии с целями обсуждения.
Что где и как обсуждается?
Может сделать категорию - Вопросы проектирования или Этапы жизненного цикла?
А то у нас одно и тоже в разных местах, уже и искать сложно
Вообще я уже предлагал реорганизацию по областям знаний или дисциплинам )

2239
О Сайте и Форуме / Разделы Форума №2
« : 27 Декабря 2006, 19:37:10 »
Давайте уже что-ли перейдём в другую тему "Начальная фаза проекта: Целеполагание".

Модератор: Еще раз обсудим разделы

2240
Не могу согласиться. На мой взгляд, одна из важнейших характеристик организации, как системы - это самостоятельные цели не являющиеся суммой целей функционеров.
Тогда пожалуйста определение слова "функционер" и примеры целей организации в студию )

2241
Я перескажу Коберна: он предлагает вводить актера таймер  (или планировщик ОС) для периодических событий. Время все же слишком расплывчатое определение, к тому же у него нет цели.
Я бы ещё рассуждал так - таймер - это объект, а время - это абстрактное понятие. Абстрактное понятие не вступает во взаимодействие и не имеет целей.
Цитировать
Про бизнес-цели согласен - ИМХО это цель бизнеса в целом (предприятия, организации) в противовес цели конкретного действующего лица.
Ну не знаю, не знаю. Я предпочитаю бизнес-цели тоже сопоставлять конкретным людям, представляющим интересы организации, как они их понимают. Потому как у организации самой по себе целей скорее всего нет, кроме традиционных термодинамических или эгрегорных - минимизация внутренней энергии, сохранение равновесия или максимальное расширение.

2242
О Сайте и Форуме / Активный логотип
« : 26 Декабря 2006, 17:49:39 »
Можно сделать лого на форуме активной ссылкой, ведущей на главную страницу сайта, как это принято в (негласных) стандартах эргономики сайтов?

2243
Чтобы ускорить взаимодействие, предлагаю обменяться списком околопрофессиональных проблем и задач, которые перед вами сейчас стоят.

2244
Цитата: Roman Tsvetkov
как Роль м.б. задачей,  дисциплиной или  видом деятельности ?!
В общем случае (вне RUP'а даже), "роль" - это, если вы приглядитесь, есть именованная совокупность всего того, что перечислено, отличающаюся от других совокупностей более или менее определённым образом. Например, если некто закупает продукты, собирает рецепты, придумывает их, подвергает продукты термической и мехнической обработке с целью получения пищи, то может мы придумаем какой-то более простой идентификатор, чем фраза, описывающая его деятельность, например, скажем, "повар"?

2245
ну, раз раздел называется RUP, то о нем и речь..
если Вы смотрите Пуск-> Программы -> Rational Software -> Rational Unified Process -> Glossary, то там чуть другие определения, походу. Вы не могли бы сказать, где Вы видели ЭТИ определения ?  как Роль м.б. задачей,  дисциплиной или  видом деятельности ?!
Ну я в принципе разобрался, на досуге напишу..
Я смотрю в своей голове )

Ок, Смотрим официальный глоссарий:
Цитировать
actor (class)
Defines a set of actor instances, in which each actor instance plays the same role in relation to the system.

(UML) A coherent set of roles that users of use cases play when interacting with these use cases. An actor has one role for each use case with which it communicates.

actor (instance)
Someone or something, outside the system that interacts with the system.

role
A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization.

(UML) The named specific behavior of an entity participating in a particular context. A role may be static (for example, an association end) or dynamic (for example, a collaboration role).

Так всё-таки вас UML-ные термины интересовали или RUP-овские?

2246
Вот такой вопрос возник:
Какие диаграммы, по методологии UML, лучше всего использовать для описания бизнес-процессов?
А почему именно UML, это что, самоцель?

Цитировать
Ну понятно, что фундаментальные
1. диграмма ВИ, она хорошо подточена под бизнес...
Это в каком смысле?

2247
В РУПе есть понятия:

  • Заинтересованное лицо (Stakeholder) - Объект, обладающий интересами относительно рассматриваемой системы или её области дейстельности.
  • Субъект, Актёр, Деятель (Actor) - Внешние автономные объекты + Сама система, вступающие во взаимодействие с целью достижения определённых целей Заинтересованных лиц.
  • Роль (Role) - под ней понимается набор областей ответственности, дисциплин, задач, видов деятельности и артефактов в процессе разработки ПО, которые принимают на себя Разработчики системы.

Вне РУПа может быть что угодно )

2248
Чтобы использовать анализ, надо иметь, что анализировать. То есть нужна СИСТЕМА. При этом она должна быть такой, которую будут в состоянии исследовать студенты почти самостоятельно. Естественно, решение уравнения не нужно, с другой стороны экономические и бизнес-системы недоступны в рамках семестрового курса. Остаются технические и научные системы, которые описаны достаточно точно и четко.
Да, нужен объект исследования. И на мой вгляд, работа с новыми нечёткими системами - это соль работы аналитика - прийти туда, где мало кто может изложить целостное видение и "разложить по полочкам". Если дать студенту уже формализованную систему, то он с неопределённостью работать не научится, исхо.

Я бы делал так - команде из 4- человек давал Пр.Обл. типа работы местного отделеания Почты или Магазина, Библитотеки. Дать им теорию с целями, разобрать достаточное количество примеров, рассмотреть достоинства/недостатки, показать имитационные модели, рассказать про методы сбора и формализации знаний и запустить "в поле". ДЛя этого конечно нужно иметь контакты с "экспертами" Магазина. И постоянно мониторить ход работ, помогая со всеми тупиками и затыками.

2249
Цитата: Galogen
Цель - построить модель функционирования системы, сформулировать функциональные требования, построить инфологическую модель. Пощупать ее в акцессе.
Вот я чего у вас не вижу - так это чёткого перехода от моделирования AS-IS к TO-BE - как этот процесс происходит? Как меряется корректность и точность модели AS-IS, как оценивается её полезность? Как провести имитационное моделирование, что оно может показать? Если мы хотим изменить систему (реинжиринг) и/или заменить механизмы выполнения некоторых её функций, то с какой целью? Каких показателей мы хотим добиться? Сколько вариантов автоматизации/реорганизации данной системы существует? Как выбрать из них подходящий? Только потом уже можно говорить о функциональных требованиях к вновьсоздаваемой системе. Не понимаю, что вам даёт инфологическая модель в эксессе. Какие выводы на её основе можно сделать?

Цитировать
Вообще идея была - дать в одном семестре структурный методв, а в другом объектный -и чтобы студенты сделали вывод, что лучше и когда
А что, есть варианты, кроме того, что структурно-функц. методы лучше подходят для описания бизнеса, а объектные - технических систем, причём скорее ПО, чем аппаратных? :)

2250
Galogen

Извините за резкость)

Вот то-то и оно, что у СompAssoc никакого "полного цикла" не наблюдается - мы с bas'ом искали у них RMS-инструмент - не нашли, у Microsoft тоже не всё гладко.