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

×


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

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


Сообщения - Shur

Страницы: « 1 2 3 4 5 6 7 8 9 10 11 12 13 »
121
Один и тот же процесс например отправки емайл письма по разному реализуется в различном ПО. Просто хочу сказать что не нужно все мешать в одной корзине.

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

Вопрос в там как конкретные задачи конкретных пользователей Заказчика выявить, формализовать в виде конкретных требований, и затем уже реализовать в разрабатываемом ПО.
А в самом деле - как выявить? Какие вопросы нужно задать, например?

122
Необходима разработка, ПО которое позволяет автоматизировать БИЗНЕС-ПРОЦЕССЫ закупки товара, отслеживания товара на складе, продажи товаров, управления отношением с клиентом и прочего. И уже в рамках этих конкретных процессов нужно выявлять конкретные цели и задачи конкретных пользователей.

 Скажу свою мысль проще: Невозможно разработать ПО, без знания и использования в качестве ориентира, существующих БИЗНЕС-ПРОЦЕССОВ организации.

Правильно ли я Вас понимаю: первичны бизнес-процессы, цели вторичны? Т.е. в жизни сначала появляется бизнес-процесс, и для порождения этого бизнес-процесса его создателям/пользователям цели не нужны?

Типичный вариант: Описание БП отсутствует как таковое вообще. Заказчик сам до конца не знает, что и как у него работает. В этом варианте и начинаются все описанные в дискуссии проблемы по выявлению целей и задач. Как раз именно таких проектов в ИТ сфере по разработке ПО большинство. Когда Заказчик со своей стороны не знает что и как у него работает ( в большей или меньшей степени), соответственно и не может четко сформулировать требования к ПО.  Разработчик же, тем более не знает как работает Заказчик, какие у него есть БП и что собственно от него хочет Заказчик.

Т.е. наличие описания бизнес-процесса уже гарантирует возможность укзания цели Заказчика ("чего хочет Заказчик")?

123
С одной стороны, есть проблема субъекта, работающего над проектом. Это вопрос о правильности постановки целей самим разработчиком (или командой проекта). И если рассматривать теоретические установки только в этой части, то у меня тут очень мало возражений. Цель, средства, результат - система организации работы над проектом должна быть хорошо проработана.

ИМХО важно учитывать, что цели есть как у субъекта-разработчика, так и у субъекта-заказчика и не стоит сводить заказчика исключительно к объекту воздействия разработчика. Т.к. заказчик субъектен, и скорее даже "субъекктивен", то его "тараканы", интуиция и пр., о чем Вы пишете ниже, способно преподнести немало сюрпризов разработчику при реализации проектов. ОБъект тем и отличается от субъекта, что субъект осознанно воздействует на объект, а объект- нет.


С другой стороны, есть объект, пользователь (заказчик). Проектируя компьютерную систему, мы, на самом деле, не знаем целей пользователей, их потребностей, мотивов, установок, стереотипов, ценностей, ... Мы не формируем цели пользователя, мы пытаемся их выявить для построения программы. Мы используем ту или иную специфическую методику, а сказать точнее, язык, для описания предполагаемых действий пользователя. В этом-то и состоит вопрос, а можем ли мы, в принципе, точно и полно выявить истинные цели пользователя?

Возможно, вы имели в виду, что мы не значем цели пользователя "до проектирования системы" ? Потому что проектирование без цели Заказчика ИМХО представить себе достаточно трудно (ну только если проектируем для себя, и то, для целей проектирования важно представлять себя как пользователя рефлексивно - в третьем лице).

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

Но мне, как дипломированному психологу, понятно и другое:
  • Человек не является константой, его цели, мотивы, интересы постоянно(!) меняются. Не только меняются, но и переструктурируются.
  • В иерархии целей человека, всегда найдутся надцели, находящиеся вовне. Вне компьютера, вне данной фирмы, вне рассматриваемой нами предметной области. И именно этой надцелью может определяться поведение и заказчика, и пользователя.
  • Разнообразие интересов (и целей) существует и у отдельного человека(!). Это тоже надо учитывать.
  • И последнее. А откуда вообще берется априори принимаемое утверждение, что человек обязательно действует целенаправленно. С чего это Вы так уверены, что заказчик (у которого получаем требования) или  пользователь (при работе за компьютером), что-то планируют в своей деятельности? А как же спонтанность, интуитивность, как же эмоции ..?

Здесь я был краток. При желании можно рассмотреть указанные тезисы подробно, со ссылками на источники.

Люди тысячи строят корабли, более сотни лет делают сталь и машины, десятки лет самолеты и компьютеры. Все эти практки связаны с сознательной деятельностью человека. Причем, например, для создания  технических достижений их творцы часто десятилетиями шли к одной цели (есть много мемуаров и автобиографий, а плодами их трудов мы пользуемся и теперь). Конечно, можно обсуждать конкретные практики, конкретных субъектов и способы установления (верификации) их целей. Но подвергать сомнению возможность целенаправленной деятельности несколько странно. Ведь вряд ли Вы согласитесь, что когда Вы набирали этот пост Вы не дейстовали осознанно и даже не имели в виду достижение никакой цели этим действием?

124
С ходом дискуссии проблематика все больше размывается и тема становится пугающе большой.

Чтобы не тонуть в материале предлагаю тезисы соотносить с рамками контекстов. ИМХО можно рассматривать высказывания применительно к трем вложенным рамкам, ограничивающим контексты: Культура (наиболее общий контекст, в котором обсуждаются наиболее общие термины и понятия), рамка деятельности (с конкретизируемыми/измеримыми резцльтатми/показателеми), рамка бизнеса (допускает обсуждение в экономических показателях), рамка автоматизации.

Насколько я понял, Вы предполагали рассматривать формирование иерархи подцелей и задач в рамках автоматизации деятельности? И что можно логическими средствами установить внутреннюю непротиворечивость заявляемых Заказчиком целей на основе анализа этих целей и располагаемых средств (и ресурсов) для достижения этх целей путем их автоматизации.
И что в рассматриваемом подходе важно избежать при анализа выхода за рамки автоматизации (в более широкие рамки - бизнеса и культуры) для установления непротиворечивости целей?

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

126
2Boatman - предложение:
1. Может быть стоит отдельно изобразить на схемах иерархию результатов, отдельно иерархию задач и показать как одно отображается в другое?
На приведенных в статье "Что такое цель" схемах узлы графов названы в основном глаголами (исключение - узел "чашка"). Поэтому эти графы ИМХО в большей степени ассоциируются со структурой задач, а не структурами целей. Я помню, что Вы отстаиваете единство результата и средства его достижения (представленного глаголом соответствующего действия) в цели. Но может быть если отдельно изобразить структуру задач и структуру результатов (задач) и показать как именно они соединяются, смысл их взаимосвязи (упаковки в  "цели") станет более ясен? Цель в Вашем представлении можно было бы определить как отношение "средство-результат". Можно ли тогда упорядочивать эти отношения в иерархию (граф)? Т.е. существует ли тогда иерархия целей, как таковая?
2. Кстати интересный вопрос - почему стоит избегать "циклов" в графах целей и как именно можно такие проблемы "расшивать"?

127
     Статья "Что такое цель" (http://boatman.h18.ru/cgi-bin/page.pl?1goal_000.page) достаточно сумбурно изложена. Много понятий перемешаны и некоторые моменты притянуты за уши. Похвально желание изложить свои собственные мысли, наблюдения и опыт, просто ИМХО иногда надо четко формализовать и разделять ключевые понятия. Это в анализе основа основ.

Пожалуйста, не могли бы Вы конкретизировать Ваши замечания, какие именно понятия нужно более отчетливо разделить (чтобы они не "перемешивались")?
Какие именно моменты являются в данной статье лишними ("притянуты за уши")?

Да и кстати в тексте смешаны понятия ЦЕЛЬ, СРЕДСТВО и ПРОЦЕСС.

Не могли бы Вы уточнить, в каком именно фрагменте текста такое смешение происходит (т.е., например, когда автор пишет "процесс", а подразумевает "цель"?

Интересен взгляд "свежевого" участника обсуждения, пожалуйста, не могли бы Вы уточнить, что именно Вы имели в виду?

128
.....
Трудность моя вот в чём: при попытке перевода фраз, включающих work products, я не могу найти более адекватного термина, чем "артефакты" (и я заметил, что это не только моя проблема).

Если work products это более широкое понятие, чем artifacts, то что ещё, помимо артефактов, входит в work products? Насколько существенна эта иерархия для OpenUp? И если не существенна, стоит ли тащить всё это многообразие терминов в перевод, или стоит махнуть разок бритвой Окамма и отсечь ненужные (в данной конкретной модели) сущности?
Или при этом пострадает расширяемость модели?

ИМХО "work products" можно перевести как "результат(ы) деятельности". Артефакт хотя и является  результатом деятельности, но деятельности не обязательно рассматриваемой (проектируемой).
Например, в UML artifact- A physical piece of information that is used or produced by a development process etc. Т.е. артефакт может быть не только результатом деятельности, но и средством достижения этого результата.

129
activity - слово "деятельность" вряд ли подходит хотя бы по той причине, что в русском языке для него нет множественного числа (activities). То же относится к "активности". Может, "действие"? Тогда Activity Diagram получится "Диаграма действий" - коряво как-то. imho, наиболее точный из "прямых" переводов - "вид деятельности". Это, конечно, не очень хорошо делать при переводе из одного слова два, зато полученное сочетание довольно точно передаёт суть термина, легко склоняется и встраивается в другие словосочетания (диаграмма видов деятельности).
Может, "работа"? Или "вид работы"? Тогда роли будут характеризоваться выполняемыми видами работ, соответствующая диаграмма будет называться "диаграммой видов работ".


Перевод activity как действие (action) плохо согласуется с некторыми важными значениями термина activity (да и action также).  Словарь Merriam Webster для activity дает (в том числе) такие значения:
3a) a process (as digestion) that an organism carries on or participates in by virtue of being alive
3b) a similar process actually or potentially involving mental function; specifically : an educational procedure designed to stimulate learning by firsthand experience.

Т.е. важно, что понятие activity ассоциируется с проявлениями жизни (физиологии) и/или разумной деятельности человека.

Ср. с значениями action:

3a)  the style of movement of the feet and legs (as of a horse)
3c) : a function of the body or one of its parts
7a) : an operating mechanism
7b) : the manner in which a mechanism or instrument operates.

Т.е. значения activity связаны с проявлениями субъектной, связанной с конкретным лицом (actor) практики. В русском языке термин "деятельность" имеет близкое значение (связанное с разумными проявлениями жизни человека), не в последнюю очередь благодаря теории деятельности, активно развивавшейся в отечественной школе психологии. А для action более логичным представляется оставить значение, асооцированное скорее с автоматическими (и/или бессознательными) движениями, и переводить как действие .

А множественное число activities вполне можно перевести как "виды деятельности" .  Диаграмму Activity diagram можно перевести как "Диаграмму деятельности" (множественное число не потребуется).

130
Потому мне кажется тут надо сначала все-таки уяснить - есть такое понятие - аналитическая деятельность. Чем она например отличается от научной деятельности, от решения сложной практической или теоретической задачи. Можно ли сказать, что для решения например такой задачи (пишу примерное ее изложение дабы не подводить коллег с известного сайта): известно что некий террорист летал в течение 1 месяца, известно что, он встречался с неким человеком. известно, что их встреча была продолжительной не менее 12 часов кряду, известно, что это человек мог летат только под вымышленным именем, известно, что этих имен неболее 3, известно, что в конце месяца первым рейсом он должен был прилететь в город Н. Узнать возможных претендентов и выбрать из них того, кто имел самый минимальный налет общего времени?
Задача не полная, но как образец. Можно ли считать, что если задача будет решена, то человек обладает аналитическими способностями? Можно ли считать, что он большой знаток SQL (задачу нужно решить только с использованием SELECT и только в виде одного запроса объемом не менее 8кб и скоростью срабатывания не менее такого то числа)?

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

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

Обсуждение вопроса о сущности и оценке работы аналитика (к вопросу об отличии от научной и пр.) периодически ведется в разных темах данного форума. Может быть стоит разделить обсуждение требований к работе аналитика (возможно, в чтом числе, под углом зрения обучения) от собственно проблем тестирования и оценки (какие тесты удовлетворение каким требованиям тестируют)  и вести их в разных темах?
Достаточно ли различных или даже противоречивых взглядов высказано в данной теме, чтобы сделать их предметом новой темы?

131
2Galogen
Насчет разных логик:
Логика, как минимум включает понятия, которые используются для формулирования суждений. Даже в данном форуме имели место разные мнения по поводу понятий используемых в аналитической деятельности (например, по понятию цели). Есть практки, для которых достаточно знать, что цели просто есть. А есть практики, для которых, важно понимать, как эти цели получаются. Можно конечно, считать, что раз участники обсуждения говорят по русски и используют одни и те же слова, значит и логика у них одна. Но если используя одни и те же слова они получают разные суждения, я бы говорил, что они используют разную логику. И не в уничижительном смысле, а для обозначения масштабов различия взглядов участников обсуждения.

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

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

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


Вторая важная часть вопроса - что понимать под контекстом. Контекст Заказчика автоматизируемой системы (его дело, его бизнес)? Или контекст собственно реализации автоматизируемой системы (контекст автоматизированных систем, процессы, способы и средства их создания)?
В этом смысле разделы системного анализа, которые Вы процитировали, сами контекстами автоматизируемой предметной области не являются. Каждый из этих подходов является только средством для анализа реальной автоматизируемой деятельности Заказчика.
Под контекстом я подразумевал именно рельную практику,а не знания (информацию) о ней, которые могут быть несовершенны. Задание такого контекста в режиме лекции, тренинга или семинара всегда будет оставаться только приближением. Чем сложнее задача, тем сильнее последствия использования "кабинетного контекста".
Самый простой способ соотвествовоать "правде жизни" - работать в тестном (и частом) контакте с реальными практиками предметной области. Возможно, именно это является центральной изюминкой Agile-подходов?
Более сложный подход: пытаться формализовывать на концепутальном уровне различные практики предметных областей, но это проблематично сделать в обсуждении в форуме (опять же - нужны "живые" практики предметных областей)...

133
2Galogen
ИМХО обсуждать "что  такое аналитическая деятельность" рискованно вне контекста. Во внеконтекстной постановке определение аналитических способностей сводится к выявлению способностей к логическому рассуждению, мышлению в самом широком смысле этого слова. А это уже задача типа теста Тьюринга.
В "боевых условиях" есть возможность проверить аналитиков на практических задачах, в которых контекст задают (описывают) лица, реально заинтересованные в практическом решении этих задач. Логически мыслящий аналитик им нужен постольку, поскольку им нужен результат. Т.е. задать реальный контекст в практических задачах - не проблема.
Но в Вашей задаче выявления аналитических способностей с позиции преподавателя всё равно актуальна проблема задания контекста (хотя, наверное, это самая сложная часть этой задачи).  Возможно, для этого потребуется обозначить спектр макрозадач, задающих контекст аналитической деятельность. Т.е. показать как эта логика работает на практических задачах.

134
2 Galogen
Даже если соискатель-аналитик предложит решение задачи об избитом отце сыне профессора, можно ли обойтись без оценки решения? Ведь последнее предложение вашего поста - это фактически оценка решения задачи, фомулирование того, что Вы считаете наилучшим решением для данной задачи.
Вы не согласились с Ser, но и не опровергли его утверждение (о том, что решение вопроса может быть осуществлено "опытным путем" за счет получения дополнительной информации из конкретного контекста) . Сам факт Вашего несогласия с подходом Ser укзывает на то, что Вы признаете, что его точка зрения по обсуждаемому вопросу отличается от Вашей. Итого (если Ser не откажется от своего подхода и не примет Ваш) будем иметь по крайней мере две точки зрения на общий подход к способу выявления аналитических способностей (неявно подразумевающий их оценку).
 В подходе Ser есть очень важное зерно - требование быть способным самостоятельно очерчивать/уточнять рамки и содержание задачи в конкретном контексте, чего сложно добиться если человек привык только решать задачи, которые ему ставит кто-то другой.
ИМХО противопоставлять два подхода ("чисто логический" и "опытный" - от контекста)  имеет смысл не для выявления, какой из них более правильный, а для выяснения - не являются ли эти два подхода по крайней мере двумя разными аспектами аналитических способностей.
Возможно, различие подхода, который отстаиваете Вы в предыдущем посте, от указанного Ser связано с различием Ваших с Ser практик, с которыми Вы связываете свои аналитические интересы?

135
Существенна конечно, роль - работодатель в лице руководителя той или иной оргструкуры. Понятно, что тестовые задания будут готовиться с участием работодателя, но не только им.

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

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