466

Примеры / Re: Uml-модель экономической системы общества.

« : 06 Ноября 2009, 01:40:49 »

Давайте обсудим такой порядок работы:
   1.Основными действующими элементами эсо являются физические лица, юридические лица, институциональные сектора и отрасли общественного производства. 
   Я предлагаю сделать их материнскими классами, которые будут источниками самых разных дочерних классов, которых в эсо великое множество.
    Какие нам потребуются дочерние классы от материнского класса “физические лица”?
    Это класс банкиров, предпринимателей, наемных работников и госчиновников.
    Эти классы нам потребуются в первую очередь. Все другие могут вводиться по мере необходимости.
    Какие нам потребуются дочерние классы от материнского класса “юридические лица”?
   Это коммерческие организации и некоммерческие организации. Все остальные можно будет вводить по мере необходимости.
   Какие нам потребуются дочерние классы от материнского класса “институциональные сектора”?
   Это нефинансовые корпорации, финансовые корпорации, государственного управления, домашних хозяйств и некоммерческих организаций, обслуживающих домашние хозяйства. Других не будет.
   Какие нам потребуются дочерние классы от материнского класса “отрасли общественного производства”?
   Этих отраслей по общероссийскому классификатору видов экономической деятельности (ОКВЭД) тринадцать штук. Больше тоже не будет.
Это все основные действующие объекты эсо.
2.Вот все эти вышеперечисленные классы нарисовать на диаграмме классов.
3.Связать все эти классы товарно-денежными отношениями, зависимостями.

Нееее, не утерплю - тоже поумничаю немного на сон грядущий :о))

IMHO есть определенная неестественность в приведенном подходе (хотя я не настаиваю на правильности своего).
Сначала было бы неплохо сделать допущения (в качестве отправной точки) о масштабе системы: отдельно взятое государство, что-то меньшее (в терминах РФ - регион, например) и наоборот большее (Евросоюз, какой-то другой экономический или политический блок) или, как говорится, "в мировом масштабе".
Ну ладно, допустим как-то определились. Это границы системы.

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

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

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

Так или иначе получил я деньги, а дальше что? Могу потратить на блага (пожрать купить :о))), могу вложить в развитие ("теперь я в два раза счастливее, потому что у меня две коровы") или просто под матрас положить - т.е. тоже дофига вариантов. А вот чем они определяются? Я делаю такой вывод, что где-то "внутри" должен учитываться такой механизм как "мотивы" или "интересы". IMHO без него никак. И вот если количество вариантов сущность-отношения в различных комбинациях будет довольно большим, но, как видится, конечным, то с "мотивами" может промашка выйти - мало того, что их одновременно может быть много, так они еще и накладываются друг на друга, трансформируются по не вполне очевидным законам, плодятся, множатся.
И так с каждым индивидуумом. Очевидно, что в любой момент времени есть некоторое количество типовых сценариев, носят они вероятностный характер, типа того, что тот или иной выбирается с некоторой вероятностью в зависимости от доступного конкретному индивидууму "окружения",  а это пока тоже неясно что такое (для простоты наличие Интернета, газет, журналов, телефона, телеграфа, радио и телевидения, а также других сред распространения информации можно не учитывать).
Потом есть опять же очевидно вероятностный итог возникновения, трансформации и прекращения отношений, я уж не говорю о мотивах.

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

Так или иначе приходим к "эффекту бабочки".

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

Кто-то рискнёт замоделировать? :о))

467

Работа / Re: Знание английского языка

« : 05 Ноября 2009, 14:55:17 »

Именно!

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

468

Работа / Re: Знание английского языка

« : 05 Ноября 2009, 14:43:50 »

Элементарно, Ватсон! (с)

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

К чему это я?.. Полезно разрушать стереотипы ...

469

Реализация / Re: Создание технической документации для ПО

« : 05 Ноября 2009, 13:13:06 »

Но сами по себе, на чистой сознательности, программисты использовать его не будут. Нужно их, во-первых, убеждать (иногда металлической линейкой по рукам), а во-вторых, контролировать.

насколько я помню, никто подобного (про разбуженную сознательность) не утверждал :о))
и потом было интересно узнать про зависимость качества subj от силы убеждения (металлической линейкой по рукам)

470

Реализация / Re: Создание технической документации для ПО

« : 05 Ноября 2009, 12:13:38 »

Задача стоит в том чтобы новый человек прочитал некий документ в которм бы ему стала понятна работа как всей системы в целом, так и ее компонентов в частности если это необходимо (например при исправлении ошибки или дописании новых функций в каком-то конкретном модуле).

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

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

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

P.S. В свое время мы использовали javadoc, который преобразует комментарии в исходном тексте в help-файлы. Можно начать с чего-то подобного.

471

Работа / Re: Знание английского языка

« : 05 Ноября 2009, 11:49:03 »

Ида, вы будете смеяться, но у нас из 6 студентов 6 не читают книг вообще - в принципе. Если им нужно что-то узнать, то они спрашивают у гугля. А потом лечат этим заказчиков. Недавно 3-х уволили, взяли новых, но картина не поменялась. Наверное, это просто новый тип мышления. Я даже уже свыкся с концепцией, что реально существует только то, что показывает первая страница поисковика. 

напоминает историю про мартышек, бананы и шланг с холодной водой

Например, есть лекции. Конспект сделан в виде некоторых тезисов с красивыми картинками и выжимками самой сути. Прошу почитать - проверю на следующем занятии, просто задаю вопросы и прошу на них ответить. Ноль. Говорю в следующий раз будет тоже самое. Реагируют пару человек.

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

IMHO только ставить оценки, влияющие на итоговый результат (зачет, допуск к экзамену). Возможно с тех пор, когда я учился, всё уже неузнаваемо изменилось, но итоговые оценки, насколько мне известно. никто еще не отменял.
Отменой лекций можно добиться только использования Википедии в качестве источника подготовки. (тут правда есть очевидный способ побороться - публиковать лекции на wiki :о))))

472

Для всех / Re: Кто я?

« : 03 Ноября 2009, 16:55:39 »

А сам процесс никого не интересует и даже никак не отслеживается.

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

473

Работа / Re: Знание английского языка

« : 03 Ноября 2009, 12:15:47 »

знать что-либо, вообще-то полезнее, чем не знать :о)) как известно язык - средство общения.

а насчет конкурентоспособности не надо так далеко ходить - достаточно сравнить уровень оплаты в наших объявлениях о вакансиях, там где требуется так называемый технический английский и там где fluent.

474

Работа / Re: Знание английского языка

« : 03 Ноября 2009, 10:25:38 »

Иностранный язык учить не нужно.

Если вместо специальности, то да - не нужно.

475

Системный Анализ и Требования / Re: Как мы играли в Управление требованиями по Agile

« : 02 Ноября 2009, 21:24:15 »

если к концу отведенного вам периода вы понимаете, что это плохо, то вы сэкономите в 8 раз больше.

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

476

Реализация / Re: Создание технической документации для ПО

« : 02 Ноября 2009, 13:20:55 »

Очень интересует вопрос организации процесса документирования разработки нового программного обеспечения (написания технической документации).

PS
Если я правильно понимаю то данный документ должен писаться всеми участниками проекта:

А у Вас есть кто-то (из тех, кто есть прямо сейчас), кто способен при каких-то условиях, например, снижение загрузки, написать искомый документ? Как Вы могли бы этот процесс контролировать (читай - заставлять)?

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

477

Системный Анализ и Требования / Re: Как мы играли в Управление требованиями по Agile

« : 02 Ноября 2009, 11:29:07 »

1 этап заключался в выделении бизнес-драйверов. Так я узнал совершенно новый термин. Оказывается всякие бизнес-цйели, требования или потребности принято называть емким словом бизнес-драйвер. Итак наша задача заключалась в поисках 3 таких бизнес-драйверов.

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

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

IMHO "бизнес-драйвер" определяет некий базовый интерес заинтересованных лиц (заказчика). Грубо говоря, отвечает на вопрос "Зачем вся эта хрень нужна?". Ответ типа "сделать решение" больше характерен для исполнителей и по большому счету соответствует сентенции "чтобы было" (... а там что хотите с этим, то и делайте, главное заплатите за него...)

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

478

UML SysML и пр. / Re: Контекстная диаграмма в UML

« : 26 Октября 2009, 11:48:20 »

я хочу показать только Систему и внешних актеров и потоки данных между ними.

что-то типа диаграммы А0 в IDEF0?
а что мешает ее нарисовать без использования UML?

479

Работа / Re: Начало карьеры

« : 26 Октября 2009, 10:29:45 »

в Самаре есть несколько компаний разработчиков, которые работают в области САПР. Плюс некоторое количество проектных институтов и крупных предприятий, правда там аналитики (в наших терминах) скорее всего не нужны.

а насчет "бизнесюков"... они в Самаре есть, несмотря на кризис, правда тоже есть сомнение, что им аналитики нужны. аналитик нужен с определенного уровня зрелости, а до этого эту работу может выполнять разработчик, да и вообще кто угодно.

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

480

Работа / Re: Начало карьеры

« : 25 Октября 2009, 22:22:27 »

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

P.S. если не секрет какой город?