О нормах времени на ПО...

[Yuri L.Kazadaev]

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

Как-то Andrey V Khavryutchenko написал:
>Тебе нужно показывать документ со _своей_ производительностью,
>желательно соотнесенной с количеством ошибок, обнаруженых за
>определенный срок, и функциональностью конечного продукта. Если это
>не убеждает, то это дает повод задуматься, нужен ли такой
>заказчик/работодатель?

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

А вот George Seriakov писал:
> Либо документ на основе среднепотолочных производительностей, то с
>детальной раскладкой трудоемкости продукта на его архитектуру. Если ты умеешь
>проектировать архитектуру до кодирования, конечно :-)).

Вот это дельная мысль. Так именно и было расписано в том Постановлении,
что я упоминал в своем первом письме в конфу. Но оно уже не действует,
и компы там только ЕС ЭВМ и СМ ЭВМ, а персоналок тогда вообще не было.

Может кто еще что подскажет или откопает где бумажку с нужными данными.
Я как-то послал письмо по своему министерству Главному спецу по ВТ, но
что-то оттуда молчек пока. Может кто подкинет если не сам документ, то
"мыльный" адрес, где можно поинтересоваться этими делами, ведь эту
конфу не все ж читают.

У нас в стране куча программеров и все ваяют чего-то. Так что, все так
дружно и хорошо живут со своими заказчиками и начальниками?! Что-то
мало вериться...
Так что пишите, если что у кого есть что сказать по этому поводу...

Юрий Л.Казадаев
ro...@crhtep.phtula.mednet.com

[Andrey V Khavryutchenko]

"Yuri L.Kazadaev" <ro...@crhtep.phtula.mednet.com> writes:

> Привет All-ам!
> Прочитал письмена по поводу моего вопроса о нормах времени на ПО,
> но, как говориться, "а воз и ныне там". Странно, да неужели перед
> этим никто не сталкивается сейчас!? Ведь начальство и раньше любило
> наезжать, а тем более сейчас, с большим процентом всяких частных
> фирм.

[skip]

> У нас в стране куча программеров и все ваяют чего-то. Так что, все так
> дружно и хорошо живут со своими заказчиками и начальниками?! Что-то
> мало вериться...

На частных фирмах на администратора/программиста, по моему опыту и
опыту всех моих знакомых, не наезжают. И, обычно, живут хорошо и
дружно, т.к. от них бывает много зависит.

А в случае конфликта -- выставляют четко сформулированые /* :) */
претензии. Вот, на прежнем моем месте мы не смогли уладить конфликт,
в результате чего я сменил место работы.

> Так что пишите, если что у кого есть что сказать по этому поводу...

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

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

--
SY, Andrey V Khavryutchenko

'Sides, if talent never saved bad management how is any software ever
written. ;) -- ni...@access.digex.net (Nigel Tzeng)

[vrud...@onestone.de]

In article <AAJ71...@crhtep.phtula.mednet.com>,
ro...@crhtep.phtula.mednet.com wrote:

> У нас в стране куча программеров и все ваяют чего-то. Так что, все так
> дружно и хорошо живут со своими заказчиками и начальниками?! Что-то
> мало вериться...

Ваяют, а не производят. В том то и беда.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading

[Alexey N. Donskoy]

Добрый день!

А не расширить ли нам Subj Юрия Л.Казадаева в направлении:
"КАК НАЙТИ ВЫГОДНОГО ЗАКАЗЧИКА (работодателя)" и "КАК ПРОДАВАТЬ СВОЙ ПРОДУКТ"?
Может быть, кто-то из профессиональных разработчиков поделится know how ;-)
Какова эффективность:
- личных связей/знакомств;
- активного поиска в Internet;
- пассивной рекламы в Internet (собственного сайта);
- чего-либо другого?

Мне кажется, это в данной конференции не будет оффтопиком,
а будет с благодарностью принято читателями.

[skip]

> >определенный срок, и функциональностью конечного продукта. Если это
> >не убеждает, то это дает повод задуматься, нужен ли такой
> >заказчик/работодатель?
>
> Но это, по-моему, вообще совет из области фантастики.

Прикинул и я разные нефантастические варианты:

а) работодатель <-> программист. Тогда варианты:
- можно с шефом поговорить, но толку все равно не будет, поскольку денег нет
и не будет, и от шефа это не зависит (например, в медицине), а работать надо
(не закрывать же контору из-за того, что программист по нормам времени
не укладыается ;-)
- с шефом говорить бесполезно, т.к. за дверью толпа молодых безработных
программистов, и все хотят на это место, хоть на какую-то, но зарплату...

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

ИМХО, все это - единственно реальные жизненные ситуации (если не
рассматривать исключения, которые достигаются только по блату). Таким образом,
обычному программисту (не гению и не предпринимателю) остается только:
- делать за малые деньги непропорционально большую работу;
- поддерживать штаны разовыми заказами типа установки какому-нибудь лоху
Windows-95 с MS Офисом;
- перестать быть программистом и становиться предпринимателем.

P.S. для Юрия:

> Вот это дельная мысль. Так именно и было расписано в том Постановлении,
> что я упоминал в своем первом письме в конфу. Но оно уже не действует,
> и компы там только ЕС ЭВМ и СМ ЭВМ, а персоналок тогда вообще не было.

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

--
С уважением, Алексей Донской
--
E-mail: al...@chavb.chuvashia.su
http://www.chuvashia.su/timer

[michael]

Hi, all!

> Опусы Донского.

>
> Добрый день!
>
> А не расширить ли нам Subj Юрия Л.Казадаева в направлении:
> "КАК НАЙТИ ВЫГОДНОГО ЗАКАЗЧИКА (работодателя)" и "КАК ПРОДАВАТЬ СВОЙ ПРОДУКТ"?
> Может быть, кто-то из профессиональных разработчиков поделится know how ;-)
> Какова эффективность:
> - личных связей/знакомств;
> - активного поиска в Internet;
> - пассивной рекламы в Internet (собственного сайта);
> - чего-либо другого?

Из всех сиих пунктов роль играет только первый (для большинства
разработчиков).

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

А почему бы, имея только на прокорм не взяться за повышение квалификации?
Сегодня вообще не имеет смысла ставить вопросы о стандартах, нормах
времени и т.п.
Потому что завтра все будет по-другому (лучше или хуже -- другой спич).
А толпы безработных программистов -- это лапша, которую придумали кадровые
отдела предприятий.
Я ищу на работу программера уже около 2 лет. Перебрал больше 25 человек.
Из них стОящих только 3 человека, но их не устроила зарплата в 2 мулика.
(Подработка запрещена -- гос. контора у меня).
Остальные -- от летчика ("Я умею на самолетах летать и запросто научусь
программировать за неделю, хотя компутер вижу второй раз в жизни,
а первый раз видел его в телевизоре") до специалистов, только что окончивших
университет. Стоящих спецов дай бог 5 процентов от всех выпускников.
А мне бы надо, чтобы программер разбирался классно в Юниксе, а еще бы в
Оракле под Юниксом (немаловажное примечание -- под НТ и валенок сваяет
чего-нить на SQL), а еще в ИНете+Java+HTML+WWW, а еще в настройке Юниксовой
почты и при всем при том чтобы не просто программировал, но и умел
проектировать (последнее оказалось самым большим требованием, как оказалось).
Все писали что-нибудь типа бухгалтерии или склада. А о серьезных
интегрированных продуктах никто и не мечтает нынче (кроме меня).

> ИМХО, все это - единственно реальные жизненные ситуации (если не
> рассматривать исключения, которые достигаются только по блату). Таким образом,
> обычному программисту (не гению и не предпринимателю) остается только:
> - делать за малые деньги непропорционально большую работу;
> - поддерживать штаны разовыми заказами типа установки какому-нибудь лоху
> Windows-95 с MS Офисом;
> - перестать быть программистом и становиться предпринимателем.

Еще раз хочу подчеркнуть мысль -- надо заниматься самосовершенствованием,
чтобы завтра переплюнуть всю эту программистскую шушеру, изучившую один язык
(пусть даже С++ или Java).

Michael V. Tokarev.

[vrud...@onestone.de]

In article <AAasc...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:
>
> Hi, all!
>
> > Опусы Донского.

...

> > Какова эффективность:
> > - личных связей/знакомств;
> > - активного поиска в Internet;
> > - пассивной рекламы в Internet (собственного сайта);
> > - чего-либо другого?
>
> Из всех сиих пунктов роль играет только первый (для большинства
> разработчиков).

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

> А почему бы, имея только на прокорм не взяться за повышение квалификации?

Надо еще найти того, кому она нужна. Я вот тут разговаривал с людьми.
-А знаете ли Вы ООП?
-Да. А у вас какой из подходов применяется Шлейер-Мелора или Буча?
-Э-э-э. А-а-а. Ну Вы присылайте резюме, а мы посмотрим.

> Я ищу на работу программера уже около 2 лет. Перебрал больше 25 человек.
> Из них стОящих только 3 человека, но их не устроила зарплата в 2 мулика.

...

> Стоящих спецов дай бог 5 процентов от всех выпускников.
> А мне бы надо, чтобы программер разбирался классно в Юниксе, а еще бы в
> Оракле под Юниксом (немаловажное примечание -- под НТ и валенок сваяет
> чего-нить на SQL), а еще в ИНете+Java+HTML+WWW, а еще в настройке Юниксовой
> почты и при всем при том чтобы не просто программировал, но и умел
> проектировать (последнее оказалось самым большим требованием, как
> оказалось).

А что, если попробовать научить?

> Michael V. Tokarev.

Regards!

Vit

[michael]

Hi!

> Автор -- Vit.

> In article <AAasc...@tokareff.pgu.karelia.su>,
> mic...@tokareff.pgu.karelia.su wrote:
> >
> ...
> > > Какова эффективность:
> > > - личных связей/знакомств;
> > > - активного поиска в Internet;
> > > - пассивной рекламы в Internet (собственного сайта);
> > > - чего-либо другого?
> >
> > Из всех сиих пунктов роль играет только первый (для большинства
> > разработчиков).
>
> Беда в том, что заказчики не умеют второго, не читают третьего и не
> представляют себе четвертого. Они где-то бродять, но никак не могут найти
> того, кто им сделает хорошо.

Да не бродят они, а сидят и ждут, чтобы им кто-нить все сделал причем за пару
недель. И ведь находятся такие программисты-доброхоты.
И даже им -- специалистам-программистам -- трудно объяснить, что накопленные
ими модули или библиотеки, позволяющие им бацать на потоке софт приводят к
двум отрицательным результатам:
1. А-а-а, значит любой софт (или почти любой) может быть сваян за неделю!
А мои программисты просят от месяца до полугода (дармоеды). Уволить и
заплатить тому, кто за пару недель подсунет готовую уже программку
(и не важно, что она не адаптирована под конкретные цели, не обслуживается
в дальнейшем, потому что денег уже никто не даст ....).
2. Стоимость такого софта -- копейки и не надо объяснять почему,
а результат -- как у Майкрософта -- все универсально и ничего не работает
(с проф. точки зрения, ессессно).

> > А почему бы, имея только на прокорм не взяться за повышение квалификации?
>
> Надо еще найти того, кому она нужна. Я вот тут разговаривал с людьми.
> -А знаете ли Вы ООП?
> -Да. А у вас какой из подходов применяется Шлейер-Мелора или Буча?
> -Э-э-э. А-а-а. Ну Вы присылайте резюме, а мы посмотрим.

Так об этом и идет разговор -- сейчас заказчик и (частенько тупой)
руководитель не готов воспринять новые подходы, технологии и новые
затраты на это все тоже. Поэтому и надо _сейчас учиться_ (чтобы не отстать от
толпы программеров или обогнать их всех).
А через 3-4 года уже можно и начинать копаться как свинья в апельсинах --
поехать за рубЬеж или пойти в банк или стать ученым или...

>
> > Я ищу на работу программера уже около 2 лет. Перебрал больше 25 человек.
> > Из них стОящих только 3 человека, но их не устроила зарплата в 2 мулика.
> ...
> > Стоящих спецов дай бог 5 процентов от всех выпускников.
> > А мне бы надо, чтобы программер разбирался классно в Юниксе, а еще бы в
>

> А что, если попробовать научить?

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

> Vit

Michael.

[Arthur Ponomarenko]

michael wrote:
> А толпы безработных программистов -- это лапша, которую придумали кадровые
> отдела предприятий.

Абсолютно согласен. ПРОФФЕСИОНАЛ всегда найдет работу.

> Я ищу на работу программера уже около 2 лет. Перебрал больше 25 человек.
> Из них стОящих только 3 человека, но их не устроила зарплата в 2 мулика.

[поскипано]

> А мне бы надо, чтобы программер разбирался классно в Юниксе, а еще бы в

> Оракле под Юниксом (немаловажное примечание -- под НТ и валенок сваяет
> чего-нить на SQL), а еще в ИНете+Java+HTML+WWW, а еще в настройке Юниксовой
> почты и при всем при том чтобы не просто программировал, но и умел
> проектировать (последнее оказалось самым большим требованием, как оказалось).
>

> Michael V. Tokarev.

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

--
Пономаренко Артур
mailto:art...@rinet.ru
ph: 238-19-88

[vrud...@onestone.de]

In article <ABzrv...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:

> > Беда в том, что заказчики не умеют второго, не читают третьего и не
> > представляют себе четвертого. Они где-то бродять, но никак не могут
> > найти того, кто им сделает хорошо.
>
> Да не бродят они, а сидят и ждут, чтобы им кто-нить все сделал причем за
> пару недель. И ведь находятся такие программисты-доброхоты.

Недавно разговаривал с немцем, который пытается открыть производство софта в
России. Если бы Вы знали КАК он искал и что он нашел! Вообщем те кто ему нужен
бродят по совершенно другим тропам и та информация, которую ему удалось
получить, попала к нему совершенно случайно.

> И даже им -- специалистам-программистам -- трудно объяснить, что накопленные
> ими модули или библиотеки, позволяющие им бацать на потоке софт приводят к
> двум отрицательным результатам:

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

> Так об этом и идет разговор -- сейчас заказчик и (частенько тупой)
> руководитель не готов воспринять новые подходы, технологии и новые
> затраты на это все тоже. Поэтому и надо _сейчас учиться_ (чтобы не отстать
> от толпы программеров или обогнать их всех).
> А через 3-4 года уже можно и начинать копаться как свинья в апельсинах --
> поехать за рубЬеж или пойти в банк или стать ученым или...

Должен Вас огорчить. И заказчик и руководитель не изменятся ни через 3 ни
через 6 лет, ни по эту ни по ту сторону рубежа. Никогда они не будут
тратиться на новые подходы и технологии, если им (повторяю не Вам, а им) не
видна выгода от этих затрат. Конечно есть модные штучки, как CMM (на котором
уже ни одна солидная фирма пролетела) или глюкало от Rational по имени Rose
(которое на самом деле не поддерживает UML 1.1 ). Но это уже маркетинговая
политика фирм производителей. За рубежом не так много мест, где нужны знания
новейших технологий, а не знание примитивных вещей. В банках требуется не так
много программистов, которые к тому же должны обладать или очень
спецефическими знаниями, или очень хорошими знакомствами. На счет "стать
ученым или ..." не знаю.

Второй прос КАК учиться? Количество книг, которые необходимо прочитать для
того, чтобы быть на уровне - огромно. И большинство из них не переведено. А
купить их можно только за приличные деньги, а читать их надо уже вчера.
Единственная реальная возможность для России, когда фирма создает свою
библиотеку, понимая, что деньги на покупку литературы окупаются с лихвой.

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

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

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

Почему? Полный курс обучения в университете/институте не более шести лет.
Умный человек, у которого есть высшее образование в другой области, может
научиться программировать за 6 месяцев, думать за год-полтора и выполнять
анализ и дизайн верхнего уровня за 2-3 года. Так что при небольшой текучести
кадров уже лет через 6 уровень работников получается офигенно высоким.
Проблема, конечно в том, чтобы найти тех людей, которых можно научить, а не
тех, кто сегодня знает больше, чем тот, кому не довелось работать в этой
области.

> Michael.

Regards!

Vit

PS.: И из секретарш получаются великолепные аналитики :-)

[michael]

Hi!

Только одно замечание хочется ишо сказать.

> > > А что, если попробовать научить?
> >
> > Именно об этом и начиналась дискуссия у нас с Георгием с год назад.
> > Я говорил, что надо самому учить спецов и это, похоже, почти единственный
> > путь к повышению общего образования. А оттуда уж пойдут и руководители и
> > программеры и т.д. Но мы до того уже не доживем.
>
> Почему? Полный курс обучения в университете/институте не более шести лет.
> Умный человек, у которого есть высшее образование в другой области, может
> научиться программировать за 6 месяцев, думать за год-полтора и выполнять
> анализ и дизайн верхнего уровня за 2-3 года. Так что при небольшой текучести
> кадров уже лет через 6 уровень работников получается офигенно высоким.
> Проблема, конечно в том, чтобы найти тех людей, которых можно научить, а не
> тех, кто сегодня знает больше, чем тот, кому не довелось работать в этой
> области.

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

И если мы все скопом навлимся, тогда что-то сдвинется с места.
Я уже здесь приводил результаты своих педагогических утех.
Кстати, один из студентов подумывает пойти в аспирантуру по соответствующей
теме. А он дальше будет еще учить.
ВО перспективка!!!

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

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

Michael V. Tokarev

[George Seriakov]

Привет!

On Mon, 02 Mar 1998 11:34:31 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

>-А знаете ли Вы ООП?
>-Да. А у вас какой из подходов применяется Шлейер-Мелора или Буча?
>-Э-э-э. А-а-а. Ну Вы присылайте резюме, а мы посмотрим.

Живая картинка: Козлинский на выставке. Осматривает I-CASE. Спрашивает
демонстратора: "А какие методики кроме Yourdon-а поддерживаются?". Демонстатор
огрошенно: "А разве есть еще какие-то?" "Да, еще примерно тринадцать". Мы
(сотрудники Козлинского) тихо радуемся.

Кроме Ш-М и Буча я знаю еще ОО методики Кода-Йордана и HOOD.
---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On 27 Feb 1998 18:44:32 +0300, in relcom.comp.software-eng "Alexey N. Donskoy"
<al...@chavb.chuvashia.su> wrote:

>"КАК НАЙТИ ВЫГОДНОГО ЗАКАЗЧИКА (работодателя)" и "КАК ПРОДАВАТЬ СВОЙ ПРОДУКТ"?
>Может быть, кто-то из профессиональных разработчиков поделится know how ;-)

>Какова эффективность:
> - личных связей/знакомств;
> - активного поиска в Internet;

Чистопольский работает (~ал) вот этими способами. См. его резюмы в
инете, его базар в ньюсах, интервью с ним еще было перед новым годом в
"ИнфорБизнесе".

> - пассивной рекламы в Internet (собственного сайта);

его же замечание, что с сайта приходят в основном халявщики.

> С уважением, Алексей Донской

---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On Tue, 03 Mar 98 09:04:45 +0300, in relcom.comp.software-eng michael
<mic...@tokareff.pgu.karelia.su> wrote:

>> Беда в том, что заказчики не умеют второго, не читают третьего и не
>> представляют себе четвертого. Они где-то бродять, но никак не могут найти
>> того, кто им сделает хорошо.

>Да не бродят они, а сидят и ждут, чтобы им кто-нить все сделал причем за пару
>недель.

Просто поиск и проталкивание заказов - это работа не программиста (и
не руководителя проекта), а специального человека.

>> > А почему бы, имея только на прокорм не взяться за повышение квалификации?

>> Надо еще найти того, кому она нужна. Я вот тут разговаривал с людьми.

>Так об этом и идет разговор -- сейчас заказчик и (частенько тупой)

>руководитель не готов воспринять новые подходы, технологии и новые
>затраты на это все тоже.

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

>> А что, если попробовать научить?

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

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

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

>Michael.

---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On Tue, 03 Mar 1998 06:13:12 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

>Недавно разговаривал с немцем, который пытается открыть производство софта в
>России. Если бы Вы знали КАК он искал и что он нашел!

Ну и как?

>Я тут потихоньку начал собирать иллюзии и с той и с другой стороны. Ваше
>мнение тоже к ним относится.

Списочек можешь представить?

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

Знаем, плавали.

>Должен Вас огорчить. И заказчик и руководитель не изменятся ни через 3 ни
>через 6 лет, ни по эту ни по ту сторону рубежа. Никогда они не будут
>тратиться на новые подходы и технологии, если им (повторяю не Вам, а им) не
>видна выгода от этих затрат.

Или видна невыгода от имеющегося положения вещей.

>Второй прос КАК учиться? Количество книг, которые необходимо прочитать для
>того, чтобы быть на уровне - огромно.

Более того - некоторые знания могут быть переданы только
непосредственным контактом учителя с учеником.

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

Нигде не видел такого.

>Почему? Полный курс обучения в университете/институте не более шести лет.
>Умный человек, у которого есть высшее образование в другой области, может
>научиться программировать за 6 месяцев, думать за год-полтора и выполнять
>анализ и дизайн верхнего уровня за 2-3 года. Так что при небольшой текучести
>кадров уже лет через 6 уровень работников получается офигенно высоким.

Резонно. Осталось только обеспечить стимулы для такого непрерывного
поступательного движения.

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

Проблема в том, чтобы выгода такого научения была общеочевидна.

>Vit

---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On Tue, 03 Mar 98 16:19:09 +0300, in relcom.comp.software-eng michael
<mic...@tokareff.pgu.karelia.su> wrote:

>> > Именно об этом и начиналась дискуссия у нас с Георгием с год назад.

...

>> Почему? Полный курс обучения в университете/институте не более шести лет.

...

>Я так говорил, потому что надо, чтобы эти недоросли, научившись,
>дошли до руководящих постов.

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

>И если мы все скопом навлимся, тогда что-то сдвинется с места.
>Я уже здесь приводил результаты своих педагогических утех.

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

>Michael V. Tokarev

---
George Seriakov (seri...@aha.ru)

[vrud...@onestone.de]

In article <34faf91...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> >-А знаете ли Вы ООП?
> >-Да. А у вас какой из подходов применяется Шлейер-Мелора или Буча?
> >-Э-э-э. А-а-а. Ну Вы присылайте резюме, а мы посмотрим.
>
> Живая картинка: Козлинский на выставке. Осматривает I-CASE. Спрашивает
> демонстратора: "А какие методики кроме Yourdon-а поддерживаются?".
> Демонстатор огрошенно: "А разве есть еще какие-то?" "Да, еще примерно
> тринадцать". Мы (сотрудники Козлинского) тихо радуемся.

Маловато будет :-)

http://www.rhein-neckar.de/~cetus/oo_ooa_ood_methods.html

Methods
BON, BOOCH, BOOM,
Catalysis, Class Relation, Coad/Yourdon, COMMA, CRC, Convergent Engineering,
Demeter, DOORS, DOOS, EROOS, Fusion, Goofee, HOOD, Idea, ION,
Jacobson, MERODE, MOSES, O3ML, MWOOD, Objectory, Octopus,
OMT, OOAD/OOIE, OOBE, OOCL, OOram,
OOSC, OOSD, Open, OSA, OSM, ROOA, Scrum,
SDL, Shlaer & Mellor, SOMA, SOMT, SSDM, Syntropy

> Кроме Ш-М и Буча я знаю еще ОО методики Кода-Йордана и HOOD.

Что значит "знаю"? Вы с ними работаете? Со всеми одновременно?

И напоследок я хочу объяснить, что Ш-М предлагают код генерировать, а Буч -
писать ручками. В этом и заключается основное различие их подходов ;-)

> ---
> George Seriakov (seri...@aha.ru)

Regards!

Vit

[vrud...@onestone.de]

In article <AADD0...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:

> Только одно замечание хочется ишо сказать.

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

> дошли до руководящих постов. А на это уйдет ровно столько времени,
> что мы будем в лучшем случае на пенсии ловить рыбку и копаться
> в земельке на дачке.

А Вы то сами "до руководящих постов" добраться не можете?

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

> А насчет зарубежных спецов -- это зря (поскипаны те слова, к сожалению).
> Там есть очень продвинутые ребята (как и у нас).
> Но, во-первых, их там неизмеримо больше,

Очень сомневаюсь, что больше в процентном отношении.
Потом за кого считать продвинутого русского или китайца, работающего в
Америке?

> во-вторых, их практика уже позволяет говорить с цифрами на руках
> о всяких импрувментах, процессах, оптимизациях и т.п.
> И НЕ НА НАСовских проектах, а в обычных бизнес и не бизнес-приложениях.

Насчет "обычных", Вы IMHO сильно погорячились. Я вот все ищу информацию по
самостоятельным фирмам до 40 человек, и как-то не попадается ничего путного.
Не делают они цифр, тем более не публикуют.

> А он исследовал по-моему сотни проектов. Там есть интересные
> выкладки. Вот кто бы достал эту книжку?
> (Попробовать может ему запросик кинуть на электронный вариант, на-халяву...)

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

> Michael V. Tokarev

[vrud...@onestone.de]

In article <3502464a...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> >Недавно разговаривал с немцем, который пытается открыть производство софта
> >в России. Если бы Вы знали КАК он искал и что он нашел!
>

> Ну и как?

Старательно, ой старательно! Долго и тщательно :-) После того, как я сказал,
что объявления подобного рода часто появляются в ньюсах, он записал у себя
название этого сервиса Инета ("news") :-)

> >Я тут потихоньку начал собирать иллюзии и с той и с другой стороны. Ваше
> >мнение тоже к ним относится.
>

> Списочек можешь представить?

Попозже. Сейчас времени нет его в божеский вид привести.

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

> Знаем, плавали.

А как Вы определяете хилых и не хилых? И определяете ли вообще?

> >Должен Вас огорчить. И заказчик и руководитель не изменятся ни через 3 ни
> >через 6 лет, ни по эту ни по ту сторону рубежа. Никогда они не будут
> >тратиться на новые подходы и технологии, если им (повторяю не Вам, а им) не
> >видна выгода от этих затрат.
>

> Или видна невыгода от имеющегося положения вещей.

Выгода от имеющегося положения вещей видна всегда. "Сидят люди, чего-то
делают, чего-то у них получается, и это даже удается продать. Может быть это
можно делать дешевле и эффективнее, но очень сомнительно." Даже если все
катится под гору, всегда находится куча объективных причин.

> >Второй прос КАК учиться? Количество книг, которые необходимо прочитать для
> >того, чтобы быть на уровне - огромно.
>

> Более того - некоторые знания могут быть переданы только
> непосредственным контактом учителя с учеником.

Например?

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

> Нигде не видел такого.

Библиотеки или понимания, что деньги окупаются?

В той фирме, в которой я работал в России, были книги и о тулах, и о
библиотеках, и о методиках проектирования, и о SE. Мало, конечно, но читать их
было полезно.

> >... Так что при небольшой текучести

> >кадров уже лет через 6 уровень работников получается офигенно высоким.
>

> Резонно. Осталось только обеспечить стимулы для такого непрерывного
> поступательного движения.

Вот за объяснения того, как их обеспечить, мне и нравится то, что пишет Tom
DeMarco. Неужели у Вас на этот счет никаких идей нет? ;-)

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

> Проблема в том, чтобы выгода такого научения была общеочевидна.

Она никогда не будет общеочевидна. Или есть цель повышения эффективности
работы и ищутся средства, или этой цели нет, тогда никакие средства не
помогут.

> ---
> George Seriakov (seri...@aha.ru)

Regards!

Vit

[vrud...@onestone.de]

In article <34ff42ca...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> Чистопольский работает (~ал) вот этими способами. См. его резюмы в
> инете, его базар в ньюсах, интервью с ним еще было перед новым годом в
> "ИнфорБизнесе".

Не будете ли Вы так любезны дать URL?

> > - пассивной рекламы в Internet (собственного сайта);
>
> его же замечание, что с сайта приходят в основном халявщики.

"В основном" это сколько процентов?

[George Seriakov]

Привет!

On Wed, 04 Mar 1998 04:07:22 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

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

>> Знаем, плавали.

>А как Вы определяете хилых и не хилых? И определяете ли вообще?

А никак. Только когда обещают и не платят и только обещают (как это
по-русски! а ведь природные американцы!), возникает подозрение.

>> Или видна невыгода от имеющегося положения вещей.

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

Невыгода может выглядеть как срыв проектов и утеря рынка.

>Даже если все
>катится под гору, всегда находится куча объективных причин.

Те, кто не чешутся, уходят.

>> Более того - некоторые знания могут быть переданы только
>> непосредственным контактом учителя с учеником.

>Например?

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

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

>> Нигде не видел такого.

>Библиотеки или понимания, что деньги окупаются?

>В той фирме, в которой я работал в России, были книги и о тулах, и о
>библиотеках, и о методиках проектирования, и о SE. Мало, конечно, но читать их
>было полезно.

Библиотеки не видел. Тебе сильно повезло с фирмой - как она бишь -
"Рексофт?"

>> >... Так что при небольшой текучести

>> >кадров уже лет через 6 уровень работников получается офигенно высоким.

>> Резонно. Осталось только обеспечить стимулы для такого непрерывного
>> поступательного движения.

>Вот за объяснения того, как их обеспечить, мне и нравится то, что пишет Tom
>DeMarco. Неужели у Вас на этот счет никаких идей нет? ;-)

Идей масса. Расскажи, что пишет ДеМарко.
Кстати, никто не знает поподробнее об открытии Анкеем и IBS кафедры на
физтехе? Первичная информация была на www.algo.ru

>> Проблема в том, чтобы выгода такого научения была общеочевидна.

>Она никогда не будет общеочевидна. Или есть цель повышения эффективности
>работы и ищутся средства, или этой цели нет, тогда никакие средства не
>помогут.

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

[George Seriakov]

Привет!

On Wed, 04 Mar 1998 03:40:21 -0600, in relcom.comp.software-eng you wrote:

>In article <34faf91...@news.aha.ru>,

> seri...@aha.ru (George Seriakov) wrote:
>
>> >-А знаете ли Вы ООП?
>> >-Да. А у вас какой из подходов применяется Шлейер-Мелора или Буча?
>> >-Э-э-э. А-а-а. Ну Вы присылайте резюме, а мы посмотрим.
>>
>> Живая картинка: Козлинский на выставке. Осматривает I-CASE. Спрашивает
>> демонстратора: "А какие методики кроме Yourdon-а поддерживаются?".
>> Демонстатор огрошенно: "А разве есть еще какие-то?" "Да, еще примерно
>> тринадцать". Мы (сотрудники Козлинского) тихо радуемся.

>Маловато будет :-)

Имелись в виду структурные.

>http://www.rhein-neckar.de/~cetus/oo_ooa_ood_methods.html
>
>Methods

> Jacobson,

==OOSE. 1/3 от UML

> Objectory,

А это не технология организации ЖЗ от Rational?

> OMT,

1/3 от UML

>> Кроме Ш-М и Буча я знаю еще ОО методики Кода-Йордана и HOOD.

>Что значит "знаю"? Вы с ними работаете? Со всеми одновременно?

Не работаю. Мог бы. Наверное.

[Michael V. Tokarev]

Hi, Vit!

> In article <AADD0...@tokareff.pgu.karelia.su>,
> mic...@tokareff.pgu.karelia.su wrote:
>
> > Только одно замечание хочется ишо сказать.
> ...
> > Я так говорил, потому что надо, чтобы эти недоросли, научившись,
> > дошли до руководящих постов. А на это уйдет ровно столько времени,
> > что мы будем в лучшем случае на пенсии ловить рыбку и копаться
> > в земельке на дачке.
>
> А Вы то сами "до руководящих постов" добраться не можете?

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

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

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

> > во-вторых, их практика уже позволяет говорить с цифрами на руках
> > о всяких импрувментах, процессах, оптимизациях и т.п.
> > И НЕ НА НАСовских проектах, а в обычных бизнес и не бизнес-приложениях.
>
> Насчет "обычных", Вы IMHO сильно погорячились. Я вот все ищу информацию по
> самостоятельным фирмам до 40 человек, и как-то не попадается ничего путного.
> Не делают они цифр, тем более не публикуют.

А вот и пример. Работал когда в Мотороле, там процесс был круто поставлен.
Можно сказать -- Моторола -- это монстр. Но ведь мы забываем, что делаются
законченные проекты группами по 10 человек в среднем за год.
А это уже малые проекты по любой классификации.
Например программа управления контроллером в авто или в телефоне.
Тут НАСА и не пахнет.
В России такие стругали сотнями любые программистские коллективы,
а проектированием почти не пахло.

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

Это известно. Осталось только человеку с кредиткой (вам, например, (С))
оплатить эту книжечку для меня.
Я, видимо, даже возражать не стану.

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

Michael V. Tokarev

[vrud...@onestone.de]

In article <AAQIQ...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:

> > > Я так говорил, потому что надо, чтобы эти недоросли, научившись,

> > > дошли до руководящих постов. ...
...

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

Тогда о каких руководящих постах, до которых должны дойти недоросли, шла речь?

> > Насчет "обычных", Вы IMHO сильно погорячились. ...
...

> А вот и пример. Работал когда в Мотороле, там процесс был круто поставлен.
> Можно сказать -- Моторола -- это монстр.

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

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

> Но ведь мы забываем, что делаются
> законченные проекты группами по 10 человек в среднем за год.
> А это уже малые проекты по любой классификации.

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

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

> В России такие стругали сотнями любые программистские коллективы,
> а проектированием почти не пахло.

Сравните стоимость рабочего места (т.е. хард, софт и цену обучения).

Как сказал один директор про посудомоечную машину: "За эти деньги мы бы наняли
девочку, которая это все бы мыла"

> > Такие книжечки в Интернете обычно продаются. По кредитке можно купить, а
> > доставят курьерской почтой даже в Россию. Конечно в переводе книга стоит
> > где-то на порядок дешевле, чем оригинал, но если очень хочется...
>
> Это известно. Осталось только человеку с кредиткой (вам, например, (С))
> оплатить эту книжечку для меня.
> Я, видимо, даже возражать не стану.

Во-первых, в России кредитки ни чем не хуже, чем в Германии.

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

В-третьих, если очень хочется...

> А ведь мне, например, эта книжка нужна не деньги зарабатывать,
> а студов учить.

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

> Во всем цивилизованном мире для ученых и студентов подобные вещи
> делаются бесплатно.

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

> Michael V. Tokarev

[vrud...@onestone.de]

In article <34ff8365...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

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

...

> >А как Вы определяете хилых и не хилых? И определяете ли вообще?
>
> А никак. Только когда обещают и не платят и только обещают (как это
> по-русски! а ведь природные американцы!), возникает подозрение.

"Ой!Бли-и-ин!"
Так же и прогореть не долго. Дивлюся я на Вас и вашу контору.

> >Выгода от имеющегося положения вещей видна всегда. ...

>
> Невыгода может выглядеть как срыв проектов и утеря рынка.

Post factum - Да.

Только ситуация необратима. Начинать исправления надо будет уже вчера.

> >Даже если все
> >катится под гору, всегда находится куча объективных причин.
>
> Те, кто не чешутся, уходят.

Вместе с невыплаченными долгами. Кому от этого легче?

"Ну не шмогла я!" (С) Старая кляча из анекдота об ипподроме.

> >> Более того - некоторые знания могут быть переданы только
> >> непосредственным контактом учителя с учеником.
>
> >Например?
>
> Например, первые полгода моей работы у Козлинского он постоянно нас
> учил, что нужно сначала проектировать, а потом программировать.

Меня этому никто не учил, я до этого сам дошел. Своими шишками на лбу. Никто
не спорит с тем, что контакт при обучении эффективнее.

> ... Позже, когда стал перечитывать книжки,

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

Как сказал один товарищ: "Это не учителей мало, это учеников не хватает"

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

> Библиотеки не видел. Тебе сильно повезло с фирмой - как она бишь -
> "Рексофт?"

Да. Повезло мне и с фирмой и с ее партнером и с проектом, в котором я участие
принимал.

> >Вот за объяснения того, как их обеспечить, мне и нравится то, что пишет Tom
> >DeMarco. Неужели у Вас на этот счет никаких идей нет? ;-)
>
> Идей масса. Расскажи, что пишет ДеМарко.

:-( Это надо почти все книжки переводить. (Я их на немецком читаю)
Сначала была идея что-то выписать, теперь понял, что такое дело надо постоянно
под рукой иметь, так как нужно практически все. Так и заглохло.

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

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

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

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

Ох сказал бы я сейчас, да придется на другой раз отложить. :-(

Вобщем ситуация как в социалистической экономике. Все говорят о том, что нужны
профессионалы, а ищут работников для конвееров. Профессионалы, конечно, тоже
применяются, но редко и не эффективно. :-(

> ---
> George Seriakov (seri...@aha.ru)
>

Regards!

Vit

-----== Posted via Deja News, The Leader in Internet Discussion ==-----

[n...@pioneer.ru]

In article <AAQIQ...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:
>
> Во всем цивилизованном мире для ученых и студентов
> подобные вещи делаются бесплатно.

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

C уважением,
Николай Чувахин
n...@pioneer.ru
http://www.yi.com/home/ChuvakhinNikolai/

[michael]

Hi!

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

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

> > > Такие книжечки в Интернете обычно продаются. По кредитке можно купить, а
> > > доставят курьерской почтой даже в Россию. Конечно в переводе книга стоит
> > > где-то на порядок дешевле, чем оригинал, но если очень хочется...
> >
> > Это известно. Осталось только человеку с кредиткой (вам, например, (С))
> > оплатить эту книжечку для меня.
> > Я, видимо, даже возражать не стану.
>
> Во-первых, в России кредитки ни чем не хуже, чем в Германии.
>
> Во-вторых, если бы я мог так легко покупать книжечки, то я бы их в первую
> очередь себе бы покупал. Может быть выслал бы Вам ксерокопию, что дешевле
> значительно. Пока что приходится или пользоваться библиотекой, или покупать
> переводы на немецкий, которые хотя и хуже, но дешевле, чем оригиналы.

Смайлик в моих словах к ВАМ относился.
Я халявщик, но НИКОГДА не за чужой счет.
Если помните, я писал, что пусть бы Хамфри выслал мне книжку -- ведь она
у него уже набрана в каком-нить редакторе. То есть ему это не
стоило бы ни цента.
А знать о нем стало бы сразу куча народу.

> > А ведь мне, например, эта книжка нужна не деньги зарабатывать,
> > а студов учить.
>
> Не хотите ли Вы сами договориться с товарищем Интерфейсом, или еще кем-нибудь,
> кто плачется по поводу отсталости программистского сообщества, о том, что они
> договариваются с автором и дают Вам возможность эту книжку на русский
> перевести, после чего перевод этой книжки выпустить в России для просвещения
> "отсталого сообщества", по цене доступной нормальному российскому программеру.
> При грамотном подходе это мероприятие окупится уже только на рекламе.

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

> > Во всем цивилизованном мире для ученых и студентов подобные вещи
> > делаются бесплатно.
>

> :-/ Тут студенты в библиотеке только тем и занимаются, что книги и лекции
> копируют. За свои кровные. Некоторые книги им покупать все-равно приходится.
> Правда стипендия позволяет (тем у кого она есть). А ученые на покупку книг
> тоже фонды получают. Иногда могут скидки для университетов быть, но небольшие.

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

Michael V. Tokarev

[vrud...@onestone.de]

In article <AA8bi...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:

> Мне удалось насильно внедрять новые подходы, зато теперь без них
> никто у нас уже не мыслит жизни.

Вот это-то меня и интересуют. У меня есть серьезные подозрения, что кроме
кнута в этом процессе может участвовать и пряник. Вот его-то мне и надо
найти. А пока даже запаха его не встречал. :-(

> Смайлик в моих словах к ВАМ относился.

Я тупой. Пошлите-ка мне мейл с разъяснениями что за смайлик и каким боком он
ко мне должен быть приставлен.

> Я халявщик, но НИКОГДА не за чужой счет.
> Если помните, я писал, что пусть бы Хамфри выслал мне книжку -- ведь она
> у него уже набрана в каком-нить редакторе. То есть ему это не
> стоило бы ни цента.
> А знать о нем стало бы сразу куча народу.

А упущенную выгоду Вы учитываете? Он отдаст Вам, Вы кому-то еще, а там глядишь
и амерекосы доступ бесплатный получат. А копирайт редакции Вы учитывали?

Хотя, впрочем, статьи обычно на Сеть выставляют. Но вот книжки хорошие я не
встречал. В статьях можно то же самое найти, но в сжатой форме и по отдельным
вопросам.

...

> Осталось только мне избежать всех ошибок в переводах,
> которые могут испортить любую (тем более научную) книжку.

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

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

Судя по тому, что мене попадалось и в оригинале и в переводе, этого мнения
придерживаются отнюдь не все :-)

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

> Я имел в виду немалое число коммерческих продуктов и книг,
> которые успешно продаются коммерческим конторам и частично (или
> даже неограниченно) предоставляются в пользование ученым и их
> потомкам.

Бывает. Но отнюдь не так часто как хотелось бы. Обычн скидку предоставляют.
Процентов 50.

> Michael V. Tokarev

Regards!

Vit

>

[George Seriakov]

Привет!

On Thu, 05 Mar 1998 07:02:40 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

>> А никак. Только когда обещают и не платят и только обещают (как это
>> по-русски! а ведь природные американцы!), возникает подозрение.

>"Ой!Бли-и-ин!"
>Так же и прогореть не долго. Дивлюся я на Вас и вашу контору.

Она и прогорела (TSK Soft). (А ведь какой процесс разработки был
организован!)

>> Невыгода может выглядеть как срыв проектов и утеря рынка.

>Post factum - Да.
>Только ситуация необратима. Начинать исправления надо будет уже вчера.

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

>> Те, кто не чешутся, уходят.

>Вместе с невыплаченными долгами. Кому от этого легче?
>"Ну не шмогла я!" (С) Старая кляча из анекдота об ипподроме.

И такое бывает. Останется тот, кто сможет.

>> >> Более того - некоторые знания могут быть переданы только
>> >> непосредственным контактом учителя с учеником.

>> >Например?

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

>Меня этому никто не учил, я до этого сам дошел. Своими шишками на лбу. Никто
>не спорит с тем, что контакт при обучении эффективнее.

О! Да ты ценный кадр!!! А до чего ты еще сам дошел? Держи нас в курсе,
нам очень интересно (или, по крайней мере, мне одному).

>> Ну почему же? Уже (обще?)очевидно, что, имея MBA и вообще
>> бизнес-образование, можно получать гораздо большую зарплату.

>Сейчас попробую по памяти переврать одну книжицу:
>"В то время, как за лучших выпускников МБА идет острая борьба, те кто имеют
>средний бал долго ищут место." Так кажется.

За бугром. В совке это (МБА) очень облегчает трудоустройство. В
разнообразных видах торговли, разумеется.

[vrud...@onestone.de]

In article <3503e401...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> >> Невыгода может выглядеть как срыв проектов и утеря рынка.
>
> >Post factum - Да.
> >Только ситуация необратима. Начинать исправления надо будет уже вчера.
>
> Не обязательно необратима. Не обязателен полный крах, может быть
> достаточно явной угрозы. И, если на фирме тащат несколько проектов зараз,
> опят будет учтен по отношению ко всем.

Но этот-то уже не спасти.

У Вайнберга одна из глав начинается цитатой из "Алисы..." там где она говорит
Шалтаю-Болтаю, что тот может свалится. На что получает ответ, что во-первых,
такой вариант развития событий маловероятен, а, во-вторых, если это
произойдет, то все ресурсы будут брошены на восстановление ситуации. Таким же
образом работают многие менеджеры софтверных проектов. А потом "Вся
королевская конница, вся королевская рать..."

И просто поразительно насколько часто я видел подобное и сколько это стоит.
:-(

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

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

"А когда клиент уже совсем хорошенький, быстро подсовываете ему контракт на
подпись." (Л.Беликова. Из лекций ОПУП в ЛИТМО.) Вот так нас учили экономике
:-)

У меня приятель из местного университета сейчас будет сдавать экзамен по UML.
Очень модно стало спрашивать у кандидатов: "А знаете ли Вы UML?"
А вот я чем больше его использую, тем больше убеждаюсь, что нужны разные
специализированные языки, а не один универсальный, по недоразумению называемый
"интуитивно понятным".

> ---
> George Seriakov (seri...@aha.ru)

Regards!

Vit

-----== Posted via Deja News, The Leader in Internet Discussion ==-----

[Alexander V.Didytch]

Once upon the time vrud...@onestone.de wrote:

> с ЛЕМЪ ОПХЪРЕКЭ ХГ ЛЕЯРМНЦН СМХБЕПЯХРЕРЮ ЯЕИВЮЯ АСДЕР ЯДЮБЮРЭ ЩЙГЮЛЕМ ОН UML.
> нВЕМЭ ЛНДМН ЯРЮКН ЯОПЮЬХБЮРЭ С ЙЮМДХДЮРНБ: "ю ГМЮЕРЕ КХ бШ UML?"
> ю БНР Ъ ВЕЛ АНКЭЬЕ ЕЦН ХЯОНКЭГСЧ, РЕЛ АНКЭЬЕ САЕФДЮЧЯЭ, ВРН МСФМШ ПЮГМШЕ
> ЯОЕЖХЮКХГХПНБЮММШЕ ЪГШЙХ, Ю МЕ НДХМ СМХБЕПЯЮКЭМШИ, ОН МЕДНПЮГСЛЕМХЧ МЮГШБЮЕЛШИ
> "ХМРСХРХБМН ОНМЪРМШЛ".

лНФЕР С МХУ Х ЛНДМН, С МЮЯ ФЕ ЯРПСЙРСПМШИ ОНДУНД ГЮЙКЧВЮЕРЯЪ Б ОНЯРПНЕМХХER ЛНДЕКХ
Х DFD. нЯРЮКЭМШУ ОПНАКЕЛЮУ ЙПНЛЕ PSL (problem solve language) - ХГ
ЬЙНКЭМНЦН ЙСПЯЮ ХМТНПЛЮРХЙХ ЩРН РёЛМШИ КЕЯ Х ГКШЕ ОЮПРХГЮМШ.

с МЮЯ ОПНАКЕЛЮ ЯНЯРНХР Б РНЛ ВРН ОПНЖЕЯЯ ПЮГПЮАНРЙХ он РЪФЕКН МЮГБЮРЭ
stable process -- ГЮ ЩРХЛ ОПНЯРН Б ОПНЕЙРЮУ ОНВРХ МХЙРН МЕ ЯКЕДХР, Вё РЮЛ
МЕДЕКЭЙС МЕ ОНЯОХЛ Х ГДЕКЮЕЛ ВЕЦН-РН ЦКЧЙНБЮРНЕ.

ю ОН ОНБНДС UML БШ МЕ ОПЮБШ, НМ ЙЮЙ РЮЙНБНИ МЕ ОПЕДМЮГМЮВЕМ ДКЪ МЕОНЯПЕДЯРБЕММНЦН
ОПНЕЙРХПНБЮМХЪ (УНРЪ ЛНФМН Х МЕОКНУН) -- НМ ЩРН АЮГЮ ДКЪ ОНЯРПНЕМХЪ ДПСЦХУ,
ЯОЕЖХТХВЕЯЙХИ ДКЪ ЙЮФДНЦН problem domain ОПНАКЕЛ + НАЫЮЪ НЯМНБЮ ДКЪ
ОНМХЛЮМХЪ НАЭЕЙРМН-НПХЕМРХПНБЮММНЦН ОНДУНДЮ.

Sincerely, Alexander
---------

[Alexander V.Didytch]

Извините за неправильную кодировку -- попробую повторить:
vrud...@onestone.de wrote:

> У меня приятель из местного университета сейчас будет сдавать экзамен по UML.
> Очень модно стало спрашивать у кандидатов: "А знаете ли Вы UML?"
> А вот я чем больше его использую, тем больше убеждаюсь, что нужны разные
> специализированные языки, а не один универсальный, по недоразумению называемый
> "интуитивно понятным".

У них то может быть и модно, наши же даже и структурный подход почти не знают--
для них всё просто почитал Кальянова, Нарисовал ER модель (чем-то типа ERwin или
S-Designor),
добавил бизнес логики (BPwin), и еще DFD модель, и потом на школьном SPL написал
алгоритм -- всё простои легко, только почему то потом приходится по неделям не
спать
и исправлять ошибки из-за непонимания problem domain причём во всех проблемах
винят только одного человека -- программист всегда виноват.

Интересно, кто нибуть из руководителей слышал о понятии Stable Process и
нормальном
распределении ответсвенности между членами комманды ?!

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

Sincerely, Alexander

[michael]

Hi!

> In article <AA8bi...@tokareff.pgu.karelia.su>,
> mic...@tokareff.pgu.karelia.su wrote:
>
> > Мне удалось насильно внедрять новые подходы, зато теперь без них
> > никто у нас уже не мыслит жизни.
>
> Вот это-то меня и интересуют. У меня есть серьезные подозрения, что кроме
> кнута в этом процессе может участвовать и пряник. Вот его-то мне и надо
> найти. А пока даже запаха его не встречал. :-(

Я написал, что удалось их внедрять. Но не внедрить.
Короче, сейчас забахана база для собирания статистики (и здесь
неважно какая сфера деятельности -- софт или просто бизнес-процессы).
Все это настряпано на MS Acces.
Оболочка была выбрана исключительно из тех соображений, что чайники могут
на ней писать. Но даже и чайники за 3 года понаписали уже
очень неплохой софт (продуктом назвать не могу).
Осталось только насобирать статистику (для этого надо всего лет пяток :-) ).
А потом пойдет 3-5 уровень СММ -- управляемость-качество, прогноз-оптимизация.

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

Потом уже, когда некоторые подразделения видят, что они работают примерно
столько же, а по статистике сильно отстают (а в натуре -- просто
халявят при составлении отчетов и подсчете метрик), они начинают
чесать "репы" и думать что надо делать.
При этом чаще всего перепадает ото всех, естественно, стрелочнику --
тому, кто это все задумал сдуру и пытается сдвинуть с мертвой точки.
Я сам раз в жизни сломался на такой работе с отрицательным результатом.
Братишка мой недавно уволился. Та же ситуация, только еще банальнее --
ему не удалось даже доказать начальству, что целостность базы данных --
это НЕОБХОДИМЫЙ атрибут, без которого даже начинать ничего невозможно.

> > Смайлик в моих словах к ВАМ относился.
>
> Я тупой. Пошлите-ка мне мейл с разъяснениями что за смайлик и каким боком он
> ко мне должен быть приставлен.

Я еще тупее -- уже не помню о чем речь.

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

Это мне льстит!

А у меня еще вопросик. Но уже по другому поводу.

Хочу по емеле подписаться на новостные конференции в deganews.
Можно ли это сделать. Я полазал и нигде там на сервере не нашел.
Типа -- подписывайся и лазай туда.
А по Е-меле они не рассылают?

Спасибо,
Michael V. Tokarev.

[vrud...@onestone.de]

In article <35053D65...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> У них то может быть и модно, наши же даже и структурный подход почти не

> знают-- ...

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

> для них всё просто почитал Кальянова, Нарисовал ER модель (чем-то типа
> ERwin или S-Designor),
> добавил бизнес логики (BPwin), и еще DFD модель, и потом на школьном SPL
> написал алгоритм -- всё простои легко, только почему то потом приходится по
> неделям не спать и исправлять ошибки из-за непонимания problem domain причём
> во всех проблемах винят только одного человека -- программист всегда
> виноват.

Бывает хуже, когда в руки руководителю попадает книга "Управление проектом для
идиотов". С таких историй можно комиксы с Дильбертом рисовать в огромном
количестве. Совсем недавно слушал выступление одной тетки из отдела управления
кадрами Siemens-Nixdorf. Расхваливала она один tool, переодически повторяя,
что внедрение идет тяжело, люди мешают.

> А насчёт UML я с Вами не согласен -- ведь он предполагался не как еще одна
> методология - это основа для построения спецефичных для разных problem
> domain методологий и
> очень неплохая база для общего консенсуса по поводу обьектно-ориентированной
> паарадигмы.

Очень напоминает политику M$ по поводу консенсуса на единой платформе.

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

Язык предполагает методологию. Почитайте Шлейер-Мелор для UML. Им пришлось
много чего испоганить, чтобы подогнать. А дыры в UML тоже не маленькие.

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

Опять же моему приятелю демонстрировали какой-то новомодный tool CM. После
показа очередной фьючи, кажется изменение файла лежащего в проекте одним
пользователем, его спросили может ли это его любимый SNiFF+, на что он
ответил, что это во-первых не надо, а во-вторых за такое дело надо просто бить
по рукам.

> Sincerely, Alexander

Regards!

Vit

[vrud...@onestone.de]

Hi!

In article <AAIIL...@tokareff.pgu.karelia.su>,
mic...@tokareff.pgu.karelia.su wrote:

> Пряника (во всяком случае на первых этапах) быть не может категорически.
> Никто не хочет делать лишнюю работу да еще и бесплатно.

Бывает, что охотно делают. Даже бесплатно. Вот один любил софт ставить. Хлебом
не корми, дай чего-то проинсталировать :-)

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

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

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

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

> > > Смайлик в моих словах к ВАМ относился.

...

> Я еще тупее -- уже не помню о чем речь.

Ну и забудем. :-)

> А у меня еще вопросик. Но уже по другому поводу.
>
> Хочу по емеле подписаться на новостные конференции в deganews.
> Можно ли это сделать. Я полазал и нигде там на сервере не нашел.
> Типа -- подписывайся и лазай туда.
> А по Е-меле они не рассылают?

Думаю, что нет. Они же рекламу продают. Есть кто-то, кто предлагал рассылку,
причем к письму до 20% рекламной информации прицеплено. А потом это все-таки в
первую очередь поисковая машина. Хотя попробуйте у них напрямую
спросить. Авось подхватят.

> Спасибо,
> Michael V. Tokarev.

[George Seriakov]

Привет!

On Mon, 09 Mar 1998 03:31:40 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

>> >> Невыгода может выглядеть как срыв проектов и утеря рынка.

>> >Post factum - Да.
>> >Только ситуация необратима. Начинать исправления надо будет уже вчера.

>> Не обязательно необратима. Не обязателен полный крах, может быть

...

>Но этот-то уже не спасти.

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

>...говорит Шалтаю-Болтаю...

А ведь Кэррол написал это больше ста лет назад!

>> За бугром. В совке это (МБА) очень облегчает трудоустройство. В
>> разнообразных видах торговли, разумеется.

>Мода-с. Все равно на практике будут использоваться в основном возможности
>печени, а не головы.

Насчет печени - согласен. В совке. А когда нужно получить инвестиции
от буржуя, вместо печени - дипломы МБА.

[George Seriakov]

Привет!

On Thu, 05 Mar 1998 15:05:35 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

>Вот это-то меня и интересуют. У меня есть серьезные подозрения, что кроме
>кнута в этом процессе может участвовать и пряник. Вот его-то мне и надо
>найти. А пока даже запаха его не встречал. :-(

Хм, в хорошо организованном процессе работать _приятно_. Когда
начальник присылает тебе еженедельные (выполнимые) задания. Это ж его проблема
- что б потом все в систему собралось :-), а твое дело - картинки там
отрисовать, или код написать, или тесты написать...

[vrud...@onestone.de]

In article <3506c178...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

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

Могу точно сказать, что не только в совке. Такое возможно при любой ситуации,
когда тот, кто проект заказывает пускает на это дело не свои деньги. Очень
часто отчетность важнее результатов.

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

Блажен кто верует :-)

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

Если бы Вы только знали как просто надуть иностранца и как часто это делают
даже на просторах России...

> ---
> George Seriakov (seri...@aha.ru)

[vrud...@onestone.de]

Hi!

In article <3507c4ee...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> >Вот это-то меня и интересуют. У меня есть серьезные подозрения, что кроме
> >кнута в этом процессе может участвовать и пряник. Вот его-то мне и надо
> >найти. А пока даже запаха его не встречал. :-(
>
> Хм, в хорошо организованном процессе работать _приятно_. Когда

Это опыт или предположение?

> начальник присылает тебе еженедельные (выполнимые) задания. Это ж его
> проблема - что б потом все в систему собралось :-), а твое дело - картинки
> там отрисовать, или код написать, или тесты написать...

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

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

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

Один мужик рассказывал в английской тезке этой эхи о том, что его поставили
делать работу в одной области. Через несколько лет ему это надоело и он
попросил перевести его. Ему пообещали, потом учли, что он - превосходный
специалист, что он лучше всех разбирается в проблеме и оставили. И так
несколько раз. В результате он просто уволился со всеми своими знаниями.

А теперь я определю что же мне надо. Я ищу способы построения не хорошо
организованного процесса, а хорошо организующегоСЯ. Этакий странный аттрактор
(для тех, кто знает). Баланс свободы и самоорганизации. Любое планирование
в тех условиях, когда надо учитывать человеческий фактор имеет точность не
больше, чем точность предсказания поведения отдельного человека. Любой
организованный процесс надежен настолько, насколько хорошо учтены все
возможные варианты. А их много. Очень много.

Вот работаю я с Emacs, TeX себе поставил, так как Word'ы всяческие надоели.
Хорошо, ведь, получается. Только не очень эффективно. Вот это-то и надо
поправить.

> ---
> George Seriakov (seri...@aha.ru)

Regards!

Vit

PS.: Опять же Tom DeMarco пишет, что многие программисты не прикладывают
усилий к устранению ошибок на этапе кодирования потому, что для них очень
интересно и захватывающе охотиться за ошибками в процессе тестирования.
По-этому наилучшие результаты получаются, когда программист дает исходный код,
который он сам _ни_разу_ не скомпилировал, своему коллеге. Тот просматривает
текст, ища ошибки. Потом компилирует и тестирует, стараясь опять же найти как
можно больше ошибок. Экономия времени получается просто необычайная. Ну тех,
кто очень производитлен во введении ошибок в программу, просто переводят в
тестировщики. Их богатый опыт позволяет ловить гораздо больше ошибок, чем у
тех, кто ошибок при кодировании делает мало.

[Alexander V.Didytch]

vrud...@onestone.de wrote:

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

В чём я больше всего уверен что этот руководитель на себе прелелести этой
библеотеки неиспытывал и наверно был далёк от программирования. В своей жизни я
знал только
одного руководителя который реально программировал и имел предстваление о том
во что выливается то или иное проектное решение. Это "искусство" приходит только
с опытом иначе сложность задачи либо переоценивается и усложняется (как это люблю
делать я :) или просто профанируется и с логической точки зрения превращается в
нонсенс
+ очень чёткий АСУ-шный подход -- нужно автоматизировать так как это уже делается
руками
о комплексном подходе и улучшении всего управления предприятия имеются только
громкие
заявления и не только. Чисто прозаический вопрос -- сколько софтверных компаний
имеют в своём составе CIO (прозьба не путать с Технический Директор) ?

> Бывает хуже, когда в руки руководителю попадает книга "Управление проектом для
> идиотов". С таких историй можно комиксы с Дильбертом рисовать в огромном
> количестве. Совсем недавно слушал выступление одной тетки из отдела управления
> кадрами Siemens-Nixdorf. Расхваливала она один tool, переодически повторяя,
> что внедрение идет тяжело, люди мешают.

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

> > А насчёт UML я с Вами не согласен -- ведь он предполагался не как еще одна
> > методология - это основа для построения спецефичных для разных problem

> > domain методологий ...

>
> Очень напоминает политику M$ по поводу консенсуса на единой платформе.

> > Ведь ни для кого не секрет что в разных методологиях такие базовые понятия
> > как класс, тип и т.д. понимаются по разному.
>
> Язык предполагает методологию. Почитайте Шлейер-Мелор для UML. Им пришлось
> много чего испоганить, чтобы подогнать. А дыры в UML тоже не маленькие.

Язык предполагает методологию только на стадии Implementation. Интересно во чтобы
превратиласьстадия проектирования если бы я говорил что эта подсистема на C++,
метод этого класса на
PowerBuilder а вот этот интерфейс на VB.

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

Они писали и не раз - это не методология -- это философия проектирования --я за
единую основу понимания базовых понятий. Интересно что бы творилось в математике
если одинаковое количетво людей считало что 2x2=4 и такое же кол-во считало 2x2=5.

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

> Опять же моему приятелю демонстрировали какой-то новомодный tool CM. После
> показа очередной фьючи, кажется изменение файла лежащего в проекте одним
> пользователем, его спросили может ли это его любимый SNiFF+, на что он
> ответил, что это во-первых не надо, а во-вторых за такое дело надо просто бить
> по рукам.

И все эти tools продвигаются как самый крутой, самый умный самый мощный --
человеку вообще
делать ничего не придётся -- рисуй себе диаграмки и радуйся жизни -- @$#@$# но за
этими диаграмками стоит не просто рисунки а куча вложенной работы, понимания
предметной области
и существующих технологий программирования.

До сих пор помню слова одного из руководителей (где-то в середине 80-х) "Чё вам,
программистам,
кнопку нажал и всё готово" прошло больше 10 лет а отношение всё тоже.

Sincerely, Alexander
---
Мысли высказанные здесь ни что иное как мои личные мысли. Извините если задел
кого-то.

[Alexander V.Didytch]

George Seriakov wrote:

> Хм, в хорошо организованном процессе работать _приятно_. Когда

> начальник присылает тебе еженедельные (выполнимые) задания. Это ж его проблема
> - что б потом все в систему собралось :-), а твое дело - картинки там
> отрисовать, или код написать, или тесты написать...
>

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

И опять только у разработчика будет болеть голова о том как собрать систему ?
Я думаю что пряник ограничится только разговорами о этих goods.

Sincerely, Alexander

[vrud...@onestone.de]

In article <3507A409...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> В чём я больше всего уверен что этот руководитель на себе прелелести этой
> библеотеки неиспытывал и наверно был далёк от программирования. В своей

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

Вопрос не только в этом. У меня один знакомый попал в контору, которой
руководил вывший военный программист лет 45. Этот человек работал на том, что
знакомый видел только в музее и себя иначе, как вычислителем не называл. Я
зачастую могу определять по исходному коду параметры от программирования
далекие. Если люди знают только о функциональном подходе и на С++ пишут в
функциональном стиле, то и процесс у них будет построен на функциях. Если
комментарии туманны, то туманно и все управление процессом и т.д.. Отрасль
быстро меняется и те, кто не могут или не хотят воспринимать новое отстают.

> ... Чисто прозаический вопрос -- сколько софтверных компаний

> имеют в своём составе CIO (прозьба не путать с Технический Директор) ?

Стандартный случай. Для повышения качества надо иметь в штате QA. ОК!
Нанимаем, называем. Ничего, что опыта нет. Авось книжки почитает, разберется.
Вот так и появляются люди выполняющие обязанности о которых представления у
них нет. Да и у тех, кто их окружает, тоже.

> > ... Совсем недавно слушал выступление одной тетки из отдела управления

> > кадрами Siemens-Nixdorf. Расхваливала она один tool, переодически
> > повторяя, что внедрение идет тяжело, люди мешают.
>
> Ага, с начала надо на себе всё это испытывать -- а потом предлагать

> другим. ...

Вот они опробовали, а теперь решение на рынке предлагают. Уж больно процесс
красивый получается и интерфейс дружественный.

Ходит среди менеджеров идея, что те кто уволняются в результате нововведений -
люди ненужные, или вредные. Очень широко это распространено.

> > Язык предполагает методологию. Почитайте Шлейер-Мелор для UML. Им пришлось
> > много чего испоганить, чтобы подогнать. А дыры в UML тоже не маленькие.
>
> Язык предполагает методологию только на стадии Implementation.

Только, если это язык программирования. Если язык применяется на всех стадиях,
то он влияет на все стадии.

> Интересно во
> чтобы превратилась стадия проектирования если бы я говорил что эта

> подсистема на C++, метод этого класса на PowerBuilder а вот этот интерфейс
> на VB.

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

> Они писали и не раз - это не методология -- это философия проектирования --я
> за единую основу понимания базовых понятий. Интересно что бы творилось в
> математике если одинаковое количетво людей считало что 2x2=4 и такое же
> кол-во считало 2x2=5.

Вы смешиваете объективный закон и субъективное определение. Одни записывают
числа так "0.05", другие так "0.5е-1". В первом случае удобно складывать в
столбик, во втором сравнивать и умножать. Любое предложение "С завтрашнего дня
пишем так:..." бъет по многим областям применения. Можно делать Ш-М и на
UML, да мне исходная структура нравится больше. Квадратики и стрелочки можно и
по иному рисовать, а вот с именами и таблицами переходов получается грустно.

А дыр в UML достаточно, я уже не говорю о тех CASE, которые заявляют, что его
поддерживают.

> Sincerely, Alexander

Regards!

Vit

[Alexander V.Didytch]

vrud...@onestone.de wrote:

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

При чём за эти пять часов он мог сделать большую работу чем сделал раньше. А не
просто"ковырял" программы.

> Одной из основных причин неудачи одного известного мне великолепно и предельно
> точно :-) спланированного проекта являлось то, что забыли учесть, что люди
> иногда могут болеть или брать отпуск в неправильное время. И хорошо они на
> этом деле пролетели. Со свистом.

Они еще могут и перерабатывать и им может на какоето время так надоедать то что
ониделают что их срочно надо переключать на что-то другое.

> А теперь я определю что же мне надо. Я ищу способы построения не хорошо
> организованного процесса, а хорошо организующегоСЯ. Этакий странный аттрактор
> (для тех, кто знает). Баланс свободы и самоорганизации. Любое планирование
> в тех условиях, когда надо учитывать человеческий фактор имеет точность не
> больше, чем точность предсказания поведения отдельного человека. Любой
> организованный процесс надежен настолько, насколько хорошо учтены все
> возможные варианты. А их много. Очень много.

Почитайте Гарри Боема W-approach to project management (точно уже не помню) там
многосказано о разных философиях в управлении. Также можно взять очень класную
книгу, жалко
щас не помню автора "The image of the Organization" -- как там по косточкам
разобрали подходы к
организации труда :-) .

А такой подход как вы описали уже есть у японцев (толи Z толи Y обзывается) -- там
каждый
заинтересован в результатах работы всей группы.

Жалко у нас из этого вышел коммунизм который с успехом провалился.

> Вот работаю я с Emacs, TeX себе поставил, так как Word'ы всяческие надоели.
> Хорошо, ведь, получается. Только не очень эффективно. Вот это-то и надо
> поправить.
>

Поздравляю - вы только что стали поклонником Good Enough approach.

> PS.: Опять же Tom DeMarco пишет, что многие программисты не прикладывают
> усилий к устранению ошибок на этапе кодирования потому, что для них очень
> интересно и захватывающе охотиться за ошибками в процессе тестирования.

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

Sincerely, Alexander
--
P.S. По поводу флейма о UML -- как раз Tom De Marco и говорил что нет
универсального подхода
к разработке -- есть только общая база для построения этих подходов. (он сам
когда-то в молодости
такой же и построил, если кто-то слышал о нём то расскажите пожалуйста)

[Andrey V Khavryutchenko]

>>>>> "vrudowit" == vrudowit writes:

vrudowit> А теперь я определю что же мне надо. Я ищу способы построения не
vrudowit> хорошо организованного процесса, а хорошо
vrudowit> организующегоСЯ. Этакий странный аттрактор (для тех, кто
vrudowit> знает). Баланс свободы и самоорганизации. Любое планирование в
vrudowit> тех условиях, когда надо учитывать человеческий фактор имеет
vrudowit> точность не больше, чем точность предсказания поведения
vrudowit> отдельного человека. Любой организованный процесс надежен
vrudowit> настолько, насколько хорошо учтены все возможные варианты. А их
vrudowit> много. Очень много.

Ты читал статью по поводу различия между "Cathedral" и "Baazar" development
style? Как насчет того, чтобы выделить из "базара" ту часть, которая
приложима для коммерческой разработки? BTW, мое желание _гарантировать_
свободу перетекания информации растет именно из моего (небольшого :( )
опыта работы в таких проектах.

vrudowit> Вот работаю я с Emacs, TeX себе поставил, так как Word'ы
vrudowit> всяческие надоели. Хорошо, ведь, получается. Только не очень
vrudowit> эффективно. Вот это-то и надо поправить.

А что не эффективно? BTW, можешь мои настройки глянуть на
http://www.kbi.kiev.ua/~akhavr/ Там еще совсем пусто, но это уже должно
быть. Правда в них наличествует некий бардак, особенно в части почты, но
это детали ;)

vrudowit> PS.: Опять же Tom DeMarco пишет, что многие программисты не
vrudowit> прикладывают усилий к устранению ошибок на этапе кодирования
vrudowit> потому, что для них очень интересно и захватывающе охотиться за
vrudowit> ошибками в процессе тестирования. По-этому наилучшие результаты
vrudowit> получаются, когда программист дает исходный код, который он сам
vrudowit> _ни_разу_ не скомпилировал, своему коллеге. Тот просматривает

А ты помнишь какая дискуссия была в c.s-e по поводу того, что код перед
review session стоит-таки компилировать. Не всякому человеку захочется
выполнять роль компилятора. Думаю, что я, в таком процессе, вначале бы
откомпиллил, а потом бы уже смотрел логику. Особенно при большом объеме
работы.

vrudowit> текст, ища ошибки. Потом компилирует и тестирует, стараясь опять
vrudowit> же найти как можно больше ошибок. Экономия времени получается
vrudowit> просто необычайная. Ну тех, кто очень производитлен во введении
vrudowit> ошибок в программу, просто переводят в тестировщики. Их богатый
vrudowit> опыт позволяет ловить гораздо больше ошибок, чем у тех, кто
vrudowit> ошибок при кодировании делает мало.

--
SY, Andrey V Khavryutchenko

[Andrey V Khavryutchenko]

>>>>> "Alexander" == Alexander V Didytch writes:

Alexander> vrud...@onestone.de wrote:
>> Все больше убеждаюсь, что это распространено повсеместно. Тут
>> пожаловался приятелю, что один руководитель выдвинул идею о том, что
>> классов должно быть как можно меньше, на что получил ответ о
>> христаматийном примере. Люди сделали давольно крутую библиотеку,
>> которая содержала 1 (один!) класс. :-) Для применения этой библиотеки
>> надо было перегружать виртуальные функции. А Вы говорите "подход"...

Alexander> В чём я больше всего уверен что этот руководитель на себе
Alexander> прелелести этой библеотеки неиспытывал и наверно был далёк от
Alexander> программирования. В своей жизни я знал только одного
Alexander> руководителя который реально программировал и имел
Alexander> предстваление о том во что выливается то или иное проектное
Alexander> решение. Это "искусство" приходит только с опытом иначе
Alexander> сложность задачи либо переоценивается и усложняется (как это
Alexander> люблю делать я :) или просто профанируется и с логической точки
Alexander> зрения превращается в нонсенс + очень чёткий АСУ-шный подход --
Alexander> нужно автоматизировать так как это уже делается руками о
Alexander> комплексном подходе и улучшении всего управления предприятия
Alexander> имеются только громкие заявления и не только. Чисто
Alexander> прозаический вопрос -- сколько софтверных компаний имеют в
Alexander> своём составе CIO (прозьба не путать с Технический Директор) ?

>> Бывает хуже, когда в руки руководителю попадает книга "Управление
>> проектом для идиотов". С таких историй можно комиксы с Дильбертом

>> рисовать в огромном количестве. Совсем недавно слушал выступление одной

>> тетки из отдела управления кадрами Siemens-Nixdorf. Расхваливала она
>> один tool, переодически повторяя, что внедрение идет тяжело, люди
>> мешают.

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

>> > А насчёт UML я с Вами не согласен -- ведь он предполагался не как еще
>> одна > методология - это основа для построения спецефичных для разных
>> problem > domain методологий ...
>>
>> Очень напоминает политику M$ по поводу консенсуса на единой платформе.

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

>> Язык предполагает методологию. Почитайте Шлейер-Мелор для UML. Им
>> пришлось много чего испоганить, чтобы подогнать. А дыры в UML тоже не
>> маленькие.

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

Alexander> Язык предполагает методологию только на стадии
Alexander> Implementation. Интересно во чтобы превратиласьстадия
Alexander> проектирования если бы я говорил что эта подсистема на C++,
Alexander> метод этого класса на PowerBuilder а вот этот интерфейс на VB.

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

А что ты понимаешь под "оберткой"? То, что говорять маркетологи от
Rational? Так это -- сразу в /dev/null

Alexander> Они писали и не раз - это не методология -- это философия
Alexander> проектирования --я за единую основу понимания базовых
Alexander> понятий. Интересно что бы творилось в математике если
Alexander> одинаковое количетво людей считало что 2x2=4 и такое же кол-во
Alexander> считало 2x2=5.

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

Alexander> Что самое противоное -- обе части были бы абсолютно правы
Alexander> каждый в своей аксиоматике. Так вот об этой аксиоматике они
Alexander> как правило договариваются сразу . В моделировании нехватает
Alexander> время чтобы нормально всё задокументировать, не то что забивать
Alexander> в документы семантику.

Ммм... не понял. Можешь уточнить, что ты имел в виду?

Alexander> До сих пор помню слова одного из руководителей (где-то в
Alexander> середине 80-х) "Чё вам, программистам, кнопку нажал и всё
Alexander> готово" прошло больше 10 лет а отношение всё тоже.

В алфавите всего 33 буквы. Почему же не каждый может написать хорошую
книгу? :)

[vrud...@onestone.de]

In article <x790qf3...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> vrudowit> А теперь я определю что же мне надо. Я ищу способы построения не
> vrudowit> хорошо организованного процесса, а хорошо
> vrudowit> организующегоСЯ. Этакий странный аттрактор (для тех, кто

> vrudowit> знает). Баланс свободы и самоорганизации. ...

> Ты читал статью по поводу различия между "Cathedral" и "Baazar" development
> style?

Угу. Именно по-этому я поредоставил первую удобоваримую версию текста о
разделенной разработке для комментирования ;-)
Кстати если кто-то хотел ее получить, а она от меня не пришла, то шлите мне
мыло, я пошлю. "Без-возд-мезд-но, тоесть даром" (С) Сова

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

Коммерция и базар вещи связаные очень интересно. Я тут (в Германии) посмотрел
как идет коммерческое использование Linux.

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

Во-вторых, люди, занимающиеся Linux объединены в союз и предлагают свои услуги
консультантов. Опять же книги пишут.

В-третьих, продаются решения на основе Linux, хорошо продаются.

Но вот рекламы им не хватает и тяжелых приложений тоже.

> BTW, мое желание _гарантировать_
> свободу перетекания информации растет именно из моего (небольшого :( )
> опыта работы в таких проектах.

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

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

> vrudowit> Вот работаю я с Emacs, TeX себе поставил, так как Word'ы
> vrudowit> всяческие надоели. Хорошо, ведь, получается. Только не очень
> vrudowit> эффективно. Вот это-то и надо поправить.
>
> А что не эффективно?

Результат / Затраты времени разработчиков

Другое дело, что время как-бы бесплатное и вроде-бы эффективность стремиться к
бесконечности. Но в коммерческом проекте время очень даже платное.

> BTW, можешь мои настройки глянуть на
> http://www.kbi.kiev.ua/~akhavr/ Там еще совсем пусто, но это уже должно

:-(
The system returned:

(113) No route to host

Да уж, пустовато ;-)

> быть. Правда в них наличествует некий бардак, особенно в части почты, но
> это детали ;)

Совершенно аналогично можно уже запоминать мой адрес
home.pages.de/~Vit
Там сейчас не то, чтобы пусто, там очень пусто. Но это дело поправимое.

> А ты помнишь какая дискуссия была в c.s-e по поводу того, что код перед
> review session стоит-таки компилировать. Не всякому человеку захочется
> выполнять роль компилятора. Думаю, что я, в таком процессе, вначале бы
> откомпиллил, а потом бы уже смотрел логику. Особенно при большом объеме
> работы.

Единственное, что я считаю разумным делать, это запускать спеллинг.
Естественно все должно через него проходить :-) Естественно и программа должна
быть соответствующая и вместо URL не предлагать URI.

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

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

Личный зачет:
Кто сделал меньше всего ошибок (складывается количество найденое партнером,
парой противника и стандартным тестом, если он есть),
нашел больше всего ошибок у партнера (процент найденых ошибок деленный на
количество ошибок найденой другой парой и стандартным тестом).

Командный зачет:
Скорость выполнения задания,
его качество (1/количество ошибок найденых парой противника и стандартным
тестом)
качество тестирования (количество найденых ошибок в задании, выполненном парой
противника [/ошибки найденые стандартным тестом, если таковой удалось
создать при подготовке])

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

> --
> SY, Andrey V Khavryutchenko

Regards!

[vrud...@onestone.de]

In article <35082591...@usa.net>,

"Alexander V.Didytch" <unknown....@usa.net> wrote:
>
>
> vrud...@onestone.de wrote:
>
> > _С_ хорошо организованным процессом работать приятно. Взял
> > прямоугольничек, на котором написано имя работника. Выделил задание. Пару
> > раз щелкнул мышкой. И готово. А нейдет-с. Неправильные какие-то работники
> > попадаются. Вчера он это
> > сделал за час, позовчера - за час, а сегодня пятый час и никакого
> > результата.
>
> При чём за эти пять часов он мог сделать большую работу чем сделал раньше. А
> не просто"ковырял" программы.

Да :-)
Например выяснил, что при запуске 128 копий редактора, отладчик уже не
загружается. Или подобрал пароль к хорошему порносайту. :-Р

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

> что они делают что их срочно надо переключать на что-то другое.

Самое обидное, что это нельзя запланировать. Иначе работать придется с
точностью +- проект. А все командные решения "До окончания проекта запрещено
брать больничный!" приводят к ужасным провалам.

> Почитайте Гарри Боема W-approach to project management (точно уже не помню)
> там многосказано о разных философиях в управлении. Также можно взять очень
> класную книгу, жалко щас не помню автора "The image of the Organization" --
> как там по косточкам разобрали подходы к организации труда :-) .

И первое не совсем то и второе тоже. Т.е. идея понятна, а как ее применить на
практике - не очень. Условия игры другие.

> А такой подход как вы описали уже есть у японцев (толи Z толи Y обзывается)
> -- там каждый заинтересован в результатах работы всей группы.

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

> > PS.: Опять же Tom DeMarco пишет, что многие программисты не прикладывают
> > усилий к устранению ошибок на этапе кодирования потому, что для них очень
> > интересно и захватывающе охотиться за ошибками в процессе тестирования.
>
> PSP об этом говорит немного в другом русле. Необходимо сделать всё возмодное

^^^^^^^^^^^^^

> чтобы"предугадать" количество ошибок и постараться их как можно

^^^^^^^^^^^

> минимизировать при этом
> разработчик может прекрасно предсказать сколько времени на это у него уйдёт.

^^^^^^^^^

Это все из серии "План пятилетки в три года!"

Вот по-этому мне PSP и не нравится. Он предназначен для применения на среднем
программисте, а я такого зверя еще не встречал.
"Покажите мне семью в которой 2.75 ребенка!"

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

> Sincerely, Alexander

> --
> P.S. По поводу флейма о UML -- как раз Tom De Marco и говорил что нет
> универсального подхода
> к разработке -- есть только общая база для построения этих подходов. (он сам
> когда-то в молодости
> такой же и построил, если кто-то слышал о нём то расскажите пожалуйста)

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

Regards!

Vit

PS.: Как бы Вы отнеслись к выдвижению на рынок M$ UP(rogramming)L?

PPS.: У Sh-M и Буча разное понимание того, что такое Software Arcitecture. И
договориться они не могут. О какой универсальности тут можно говорить?

[vrud...@onestone.de]

In article <x77m5z3...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> Погоди, а почему ты считаешь, что язык предполагает методологию? На
> русском можно писать и "Войну и Мир" и бульварные статьи. И пишутся они
> принципиально по разному.

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

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

http://www.projtech.com/cgi/uml_survey.cgi

> >> В принципе мне не нравится не сам UML. Худо-бедно можно его расширить,
> >> подогнать, выкинуть лишнее и сделать то что нужно для решения
> >> задачи. Мне не нравится обертка в которой ее продают.
>
> А что ты понимаешь под "оберткой"? То, что говорять маркетологи от
> Rational? Так это -- сразу в /dev/null

Ага :-)
Уничтожение бумаг перед попадением на стол начальника.
Каждое утро проверяешь есть ли на столе чего-нибудь этакое. Если есть "Уй!
Дайте почитать! У Вас наверно времени нет." И сразу бегом в машинку, которая
бумагу уничтожает. У меня как раз такая перед носом стоит. :-)

> UML -- это язык, а не философия. Точнее, настолько же философия, насколько
> ей является любой другой язык.

Вот именно.

> Это -- система базовых понятий и их

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

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

> взаимосвязь AKA "Семантика". Также это система записи этих понятий в виде,
> пригодном для коммуникации AKA "Notation" AKA синтаксис.

Вот смотрю я сейчас на диаграму, которая в Розе для С++ у меня нарисована и
думаю кому я больше верю тебе или своим глазам. Ну нету, например, в
"Notation" ни ключиков ни замочков. :-/

Другие производители, чтобы сделать что-то удобочитабельное подходят к делу
еще проще. В доке написано "В нотации UML это выглядит так, а тут на картинке
Вы видите, как мы исправили это безобразие, чтобы было понятно, читабельно и
работать с этим можно было бы по-человечески".

> --
> SY, Andrey V Khavryutchenko

Regards!

Vit

PS.: В Розе есть замечательная штука - исходный текст модели. Ничто не может
сравниться с ним по удобству чтения и редактирования, не смотря на всю его
кривизну. Еще бы emacs-mode и команды shell, и можно было бы вообще спокойно
работать без их кривого тула. :-)

[Alexander V.Didytch]

vrud...@onestone.de wrote:

> Вопрос не только в этом. У меня один знакомый попал в контору, которой
> руководил вывший военный программист лет 45. Этот человек работал на том, что
> знакомый видел только в музее и себя иначе, как вычислителем не называл. Я
> зачастую могу определять по исходному коду параметры от программирования
> далекие. Если люди знают только о функциональном подходе и на С++ пишут в
> функциональном стиле, то и процесс у них будет построен на функциях. Если
> комментарии туманны, то туманно и все управление процессом и т.д.. Отрасль
> быстро меняется и те, кто не могут или не хотят воспринимать новое отстают.
>

Сам себя часто на этом ловил когда совершал героический путь
BASIC=>Assembler=>Pascal=>Object Pascal=>C++.

Однако ходят слухи что отрасль замедляет свои темпы развития (у них за бугром
обьявляют
моратории на разработку нового софта до решения проблемы 2000).

> Стандартный случай. Для повышения качества надо иметь в штате QA. ОК!
> Нанимаем, называем. Ничего, что опыта нет. Авось книжки почитает, разберется.
> Вот так и появляются люди выполняющие обязанности о которых представления у
> них нет. Да и у тех, кто их окружает, тоже.

Да видно далеко буржуям до Total Quality Control. Хотя сами сюда приезжают и
лекциина эту тему читают.

> Ходит среди менеджеров идея, что те кто уволняются в результате нововведений -
> люди ненужные, или вредные. Очень широко это распространено.

По моему это из-за того что людям надоедает говорить о том что с их точки зрения
неправильно.И они начинают понимать что они ничего поменять не в состоянии. --
стандартная ситуация
в бывшем СССР (Я начальник ты дурак)

> > Язык предполагает методологию только на стадии Implementation.
>
> Только, если это язык программирования. Если язык применяется на всех стадиях,
> то он влияет на все стадии.

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

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

Меня когда-то мучал этот вопрос. Он сроден вопросу на который я так и не смог
получить вопросв конференции ООD: Если у меня есть свойства обьекта N штук которые
можно вынести в другие
обьекты то при каком N это необходимо делать ?.
Например: Обьект хар-зуется формой, цветом и т.д (напр Синий Шар).
Так вот оказалось что это можно было решить не только в ООP как множественное
наследование но и легко решалось и в обыкновенном структурном подходе списком
структур. Аналогично я почти
уверен что и виртуальное наследование реализуется примерно как
switch structType
1:..
2:...

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

> > Они писали и не раз - это не методология -- это философия проектирования --я
> > за единую основу понимания базовых понятий. Интересно что бы творилось в
> > математике если одинаковое количетво людей считало что 2x2=4 и такое же
> > кол-во считало 2x2=5.

>
> Квадратики и стрелочки можно и по иному рисовать, а вот с именами и таблицами
> переходов получается грустно.

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

> А дыр в UML достаточно, я уже не говорю о тех CASE, которые заявляют, что его
> поддерживают.

А где ж их нет ?

Sincerely, Alexander

[Alexander V.Didytch]

Andrey V Khavryutchenko wrote:

> >> Язык предполагает методологию. Почитайте Шлейер-Мелор для UML. Им
> >> пришлось много чего испоганить, чтобы подогнать. А дыры в UML тоже не
> >> маленькие.
>

> Погоди, а почему ты считаешь, что язык предполагает методологию? На
> русском можно писать и "Войну и Мир" и бульварные статьи. И пишутся они
> принципиально по разному.

Отлично сказано !

> UML -- это язык, а не философия. Точнее, настолько же философия, насколько

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

> взаимосвязь AKA "Семантика". Также это система записи этих понятий в виде,
> пригодном для коммуникации AKA "Notation" AKA синтаксис.

Причём довольно достаточная и саморасширяема.

> Alexander> Что самое противоное -- обе части были бы абсолютно правы
> Alexander> каждый в своей аксиоматике. Так вот об этой аксиоматике они
> Alexander> как правило договариваются сразу . В моделировании нехватает
> Alexander> время чтобы нормально всё задокументировать, не то что забивать
> Alexander> в документы семантику.
>
> Ммм... не понял. Можешь уточнить, что ты имел в виду?

Я имел ввиду что никто из нас не рисует диаграмму и не пишет под ней чтоон
считает что класс это множество обьектов или класс это реализация типа
или что он принимает и то и другое потому что в Шлейер-Мейлор я не помню чтобы
они писали что второе не верно.

> Alexander> До сих пор помню слова одного из руководителей (где-то в
> Alexander> середине 80-х) "Чё вам, программистам, кнопку нажал и всё
> Alexander> готово" прошло больше 10 лет а отношение всё тоже.
>
> В алфавите всего 33 буквы. Почему же не каждый может написать хорошую
> книгу? :)
>

(Рпавыаывовыалор оровар) вот я и написал очень хорошую книгу. Беда только
что она нравится только мне.

Sincerely, Alexander.

[Andrey V Khavryutchenko]

>>>>> "vrudowit" == vrudowit writes:

vrudowit> In article <x790qf3...@netmaster.compchem.kiev.ua>, Andrey V
vrudowit> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

[bazaar-style development]

>> BTW, мое желание _гарантировать_ свободу перетекания информации растет
>> именно из моего (небольшого :( ) опыта работы в таких проектах.

vrudowit> Ты не сможешь продавать библиотеку классов и разрабатывать ее
vrudowit> базарным методом одновременно. А вот продавать приложения на
vrudowit> основе этой библиотеки ты сможешь. И чем лучше библиотека
vrudowit> получится, тем лучше сможешь продавать. Беда только в том, что на
vrudowit> начальном этапе тебе придется вложить приличное количество
vrudowit> времени и денег. Не зря большинство подобных проектов начинается
vrudowit> или в университетах или в исследовательских лабораториях.

Т.е. только при бесплатных разработчиках?

Я хочу установить, только ли бесплатное рабочее время определяет успешный
результат проекта в стиле базара. Поскольку существуют (surprise! ;) ) и
неудачные проекты в этом стиле, то я думаю, что не это критично. В лучшем
случае большой массой бесплатных разработчиков обеспечивается быстрое
тестирование и затыкание мелких глюков, но успех/неуспех проекта определяет
не это.

Вопрос -- что?

vrudowit> Если у Sun и Netscape получится удачно разделить коммерцию и
vrudowit> базар, то в результате выйдет великолепная штука.

Истесстно..

>> BTW, можешь мои настройки глянуть на http://www.kbi.kiev.ua/~akhavr/ Там
>> еще совсем пусто, но это уже должно

vrudowit> :-( The system returned:

vrudowit> (113) No route to host

vrudowit> Да уж, пустовато ;-)

А это у нашего провайдера в четверг 12-го (а не в пятницу 13-го :) )
центральный роутер сгорел. Так что сидели мы два дня без связи. Сейчас
вроде починили...

>> А ты помнишь какая дискуссия была в c.s-e по поводу того, что код перед
>> review session стоит-таки компилировать. Не всякому человеку захочется
>> выполнять роль компилятора. Думаю, что я, в таком процессе, вначале бы
>> откомпиллил, а потом бы уже смотрел логику. Особенно при большом объеме
>> работы.

vrudowit> Единственное, что я считаю разумным делать, это запускать
vrudowit> спеллинг. Естественно все должно через него проходить :-)
vrudowit> Естественно и программа должна быть соответствующая и вместо URL
vrudowit> не предлагать URI.

Какой спеллинг?

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

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

Компилятор и человек эффективно находят разные ошибки.

vrudowit> А еще лучше предлагаю провести эксперимент. Выделяешь субботний
vrudowit> день. Находишь задания, которые можно часа за два
vrudowit> сделать. Разбиваешь людей по парам и вперед. Одна пара делает
vrudowit> самостоятельно. Вторая проверяет друг у друга после
vrudowit> компиляции. Третья - сразу после написания. И т.д.. Потом пары
vrudowit> обмениваются программами и начинают тестировать, стараясь найти
vrudowit> как можно больше ошибок в реализации другой парой такого же
vrudowit> задания.

6 человек, 5 часов, ой.... :) А какие результаты у DeMarco получились?

[Andrey V Khavryutchenko]

>>>>> "vrudowit" == vrudowit writes:

vrudowit> Самый красивый и удобный в применении язык описания процесса я
vrudowit> считаю Вайнберговские диаграммы воздействия (Wirkungsdiagramme -
vrudowit> нем.). Работает очень хорошо и позволяет разложить по полочкам
vrudowit> практически любую проблему управления и найти пути ее решения.

URL?

vrudowit> PS.: Как бы Вы отнеслись к выдвижению на рынок M$
vrudowit> UP(rogramming)L?

Резко отрицательно. Правда они и так это делают руками Rational.

vrudowit> PPS.: У Sh-M и Буча разное понимание того, что такое Software
vrudowit> Arcitecture. И договориться они не могут. О какой универсальности
vrudowit> тут можно говорить?

Для того, чтобы иметь возможность достичь понимания, нужно говорить на
одном языке. Например UML

[Alexander V.Didytch]

vrud...@onestone.de wrote:

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

Uuups ! У нас не стоит проблема общения между професором медицины и дворником.у
нас проблема общения людей занимающися SD. И UML даёт нормальную возмоджность
из обьекта "пиписка" зделать обьект "^#@@@#" для дворника и обьект типа "жалко
латыни
не знаю" для професора если это понадобится.

> > UML -- это язык, а не философия. Точнее, настолько же философия, насколько
> > ей является любой другой язык.
>

> Вот именно.

Хм...:) саморасширяемых (в понятии UML) языков я не знаю. Наверно из-за того что у
нихпредназначение разное -- UML -- больше тянет на представление знаний а язык
програмирования
на реализацию задания.

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

А что, с ER модялими и DFD или IDEF0 лучше ? Здесь я нарисовал эту стрелочку
потому чтотут уменя множественное связь а вот на этот кружочек не смотрите
потомучто я привык в 3НФ
думать.

> Ну, а если начальники и отдел маркетинга начнут читать "UML для идиотов", то
> это будет просто катастрофа:
> - Вот эту стену надо поставить около того стула. Окно должно освещать комнату,
> излучая световой поток в результате интерференции дневного освещения на
> плоскопараллельной пластине оконного стекла.
> - Ты мне своими словами объясни.
> - Ну я и говорю. Вот эту стену надо поставить...

Они покачто с трудом "Маркетинг для идиотов" плохо понимают, а когда поймут то UML
им нек чему будет + А кто собственно им будет подховывать например Collaboration
Diagram ? Им попроше
надо -- платёжку отдаём курьеру а тот её относит в банк.
Мне кажется мы путаем стадию анализа и проектирования.

> Вот смотрю я сейчас на диаграму, которая в Розе для С++ у меня нарисована и
> думаю кому я больше верю тебе или своим глазам. Ну нету, например, в
> "Notation" ни ключиков ни замочков. :-/
>

Так В UML и написано "its belongs to tools responsibility"

> Другие производители, чтобы сделать что-то удобочитабельное подходят к делу
> еще проще. В доке написано "В нотации UML это выглядит так, а тут на картинке
> Вы видите, как мы исправили это безобразие, чтобы было понятно, читабельно и
> работать с этим можно было бы по-человечески".
>

Так они при этом пишут что их продукт совместим с UML ? (тогда пришлось бы писать
что NT это полноценный UNIX)

Sincerely, Alexander
--
..and Bill Gates says, "Let's close all the windows, get out, get back
in, and see if that fixes it." -- by Charles Martin

[Alexander V.Didytch]

vrud...@onestone.de wrote:

> > При чём за эти пять часов он мог сделать большую работу чем сделал раньше. А
> > не просто"ковырял" программы.
>
> Да :-)
> Например выяснил, что при запуске 128 копий редактора, отладчик уже не
> загружается. Или подобрал пароль к хорошему порносайту. :-Р

Ага и в отчёте написал что создал 30 компонент и исправил 100 замечаний юзеров.
:)Хотя я имел ввиду не это

> Самое обидное, что это нельзя запланировать. Иначе работать придется с
> точностью +- проект. А все командные решения "До окончания проекта запрещено
> брать больничный!" приводят к ужасным провалам.

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

> Ну у Мамая в войске тоже такой подход был организован. Японцы несколько по
> иному относятся к той организации, на которую работают. Да и стоит организация
> японского подхода дорого. Потом на практике японский метод работы отличается
> от теории тоже хорошо.

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

> Это все из серии "План пятилетки в три года!"

Буржуи этого и хотят -- с наименьшими затратами по больше денег.

> Вот по-этому мне PSP и не нравится. Он предназначен для применения на среднем
> программисте, а я такого зверя еще не встречал.
> "Покажите мне семью в которой 2.75 ребенка!"

В своём отчёте они написали что уж очень он помагает.

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

Или у шефа настроение не на ком сорвать будет.:(

> PSP же говорит, "Вот твоя средняя плотность ошибок. Найди их и гуляй." Вот
> найдет товарищ половину ошибок. Поставит цифорку в формочку. Начальник галочку
> себе поставит. А на следующей неделе совершенно другой человек вдруг
> обнаружит, что программа падает.

Так хоть вероятность падения какак ни как будет.

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

> управления и найти пути ее решения.

А можно по подробней ?

> PS.: Как бы Вы отнеслись к выдвижению на рынок M$ UP(rogramming)L?

Мне всё равно кто б его выдвинул и зарабатывал на нём деньги. Главное чтобыон был
действитель UPL а не поделка под VB.

> PPS.: У Sh-M и Буча разное понимание того, что такое Software Arcitecture. И
> договориться они не могут. О какой универсальности тут можно говорить?

Я не имею ввиду стиль мышления о проблеме никто не запрещает Вам
в UML рисовать структурные диаграммы и менять местами стадии разработки системы.
Меня волнует общее понимание проблемы. Тоесть если я написал 2+2=4 то все б
поняли
что 2 это натуральное число а не какаето крокозябла.

Sincerely, Alexander.

[Andrey V Khavryutchenko]

>>>>> "vrudowit" == vrudowit writes:

vrudowit> In article <x77m5z3...@netmaster.compchem.kiev.ua>, Andrey V
vrudowit> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

>> Погоди, а почему ты считаешь, что язык предполагает методологию? На
>> русском можно писать и "Войну и Мир" и бульварные статьи. И пишутся они
>> принципиально по разному.

vrudowit> :-))) Ну нельзя приводить примеры, которые противоречат своим же
vrudowit> собственным высказываниям. -Французкий знаете хорошо? -"Войну и
vrudowit> Мир" читаю без словоря.

Не понял аналогии :( Объясни темному.

>> >> В принципе мне не нравится не сам UML. Худо-бедно можно его
>> расширить, >> подогнать, выкинуть лишнее и сделать то что нужно для
>> решения >> задачи. Мне не нравится обертка в которой ее продают.
>>
>> А что ты понимаешь под "оберткой"? То, что говорять маркетологи от
>> Rational? Так это -- сразу в /dev/null

vrudowit> Ага :-) Уничтожение бумаг перед попадением на стол начальника.
vrudowit> Каждое утро проверяешь есть ли на столе чего-нибудь этакое. Если
vrudowit> есть "Уй! Дайте почитать! У Вас наверно времени нет." И сразу
vrudowit> бегом в машинку, которая бумагу уничтожает. У меня как раз такая
vrudowit> перед носом стоит. :-)

Нет. Свобода информации. Начальник может читать все, что угодно. Но
тебе-то читать это не надо :)

>> UML -- это язык, а не философия. Точнее, настолько же философия,
>> насколько ей является любой другой язык.

vrudowit> Вот именно.

>> Это -- система базовых понятий и их

vrudowit> Причем базовые понятия определяются через базовые понятия. Когда
vrudowit> я читал доку, меня все никак не оставляло ощущение, что как
vrudowit> только я подойду к пользователю, всю эту конструкцию придется
vrudowit> выкинуть и говорить о том, что этот квадратик обозначает
vrudowit> платежную форму номер 9, этот человечек - курьера, а на все эти
vrudowit> слова обращать внимания не надо.

А где ты видел, чтобы _базовые_ понятия какой-либо системы определялись не
через себя?

Вот, мне сейчас в аспирантуре пудрят мозги философией. Преподаватель очень
обиделся, когда я сказал, что философия -- это не наука, потому, что
избегает определения своих базовых понятий :)

vrudowit> Ну, а если начальники и отдел маркетинга начнут читать "UML для
vrudowit> идиотов", то это будет просто катастрофа: - Вот эту стену надо
vrudowit> поставить около того стула. Окно должно освещать комнату, излучая
vrudowit> световой поток в результате интерференции дневного освещения на
vrudowit> плоскопараллельной пластине оконного стекла. - Ты мне своими
vrudowit> словами объясни. - Ну я и говорю. Вот эту стену надо
vrudowit> поставить...

На любом языке нужно учится говорить. Даже на русском, как ты
продемонстрировал в этом примере :-P

>> взаимосвязь AKA "Семантика". Также это система записи этих понятий в
>> виде, пригодном для коммуникации AKA "Notation" AKA синтаксис.

vrudowit> Вот смотрю я сейчас на диаграму, которая в Розе для С++ у меня
vrudowit> нарисована и думаю кому я больше верю тебе или своим глазам. Ну
vrudowit> нету, например, в "Notation" ни ключиков ни замочков. :-/

Это веяния a-la MS. Правда, в Notation есть места, разрешающие это.

vrudowit> PS.: В Розе есть замечательная штука - исходный текст
vrudowit> модели. Ничто не может сравниться с ним по удобству чтения и
vrudowit> редактирования, не смотря на всю его кривизну. Еще бы emacs-mode
vrudowit> и команды shell, и можно было бы вообще спокойно работать без их
vrudowit> кривого тула. :-)

Проблемма в том, что этот формат недокументирован :(

[Andrey V Khavryutchenko]

>>>>> "Alexander" == Alexander V Didytch writes:

Alexander> vrud...@onestone.de wrote:
>> > UML -- это язык, а не философия. Точнее, настолько же философия,
>> насколько > ей является любой другой язык.
>>

>> Вот именно.

Alexander> Хм...:) саморасширяемых (в понятии UML) языков я не
Alexander> знаю. Наверно из-за того что у нихпредназначение разное -- UML
Alexander> -- больше тянет на представление знаний а язык програмирования
Alexander> на реализацию задания.

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

[vrud...@onestone.de]

In article <350A83A9...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

--- Программиста работа достала.

> > Самое обидное, что это нельзя запланировать. Иначе работать придется с
> > точностью +- проект. А все командные решения "До окончания проекта
> > запрещено брать больничный!" приводят к ужасным провалам.
>
> Кое-как можно, например устраивая коллективные вечера за пивом где можно

> обсудить не только проблемы по работе или устраивая внутриколлективные
> семинары.

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

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

> Единственное чему можно радоваться так это тому что у нас свой личный

> подход к организации труда -- всё пофиг и "забей" на всё .

У Вас это где? ;-)

> > Это все из серии "План пятилетки в три года!"
>
> Буржуи этого и хотят -- с наименьшими затратами по больше денег.

Ну не растет кукуруза за Полярным кругом! Даже если компутер говорит, что
расти должна, она не хочет. Видимо ЭВМ надо взять помощьнее.

> > Вот по-этому мне PSP и не нравится. Он предназначен для применения на
> > среднем программисте, а я такого зверя еще не встречал.
> > "Покажите мне семью в которой 2.75 ребенка!"
>
> В своём отчёте они написали что уж очень он помагает.

Я еще не встречал ни одного отчета в котором бы говорилось. "Ну вот хотели, а
оно не вышло". Мне вот тут один написал, что ему очень-очень нравится, так как
это ТАК хорошо. Беда только одна, если он начинает это все выполнять ни на что
другое времени у него не остается. Об этом сказать как-то забывают.

У меня приятель рассказывал про аналогичный случай. Люди делают жутко
параллельный рассчет и вычисляют производительность, выкидывая все время,
которое тратится на коммуникацию между процессорами. Жуткие цифры получаются.

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

Позже.

> > PS.: Как бы Вы отнеслись к выдвижению на рынок M$ UP(rogramming)L?
>
> Мне всё равно кто б его выдвинул и зарабатывал на нём деньги. Главное

> чтобы он был действитель UPL а не поделка под VB.

Боюсь, что именно подделка и получится. Ну не выгодно делать чего-то другое.

> Я не имею ввиду стиль мышления о проблеме никто не запрещает Вам
> в UML рисовать структурные диаграммы и менять местами стадии разработки
> системы.

Вы пробовали, или Вам так кажется?

> Меня волнует общее понимание проблемы. Тоесть если я написал 2+2=4 то все б
> поняли
> что 2 это натуральное число а не какаето крокозябла.

Вот первокласник Вас поймет. А математик спросит про систему счисления.
Программист же просто ответит TRUE.

Для того и нужны разные языки, чтобы их трудно было спутать. Вы никогда не
пробовали одновременно писать программы на двух языках из разных групп,
синтаксис которых очень похож? Смею Вам доложить очень интересное занятие.

> Sincerely, Alexander.

Regards!

Vit

[vrud...@onestone.de]

In article <x7n2ett...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> [bazaar-style development]
...

> Т.е. только при бесплатных разработчиках?
>
> Я хочу установить, только ли бесплатное рабочее время определяет успешный
> результат проекта в стиле базара. Поскольку существуют (surprise! ;) ) и
> неудачные проекты в этом стиле, то я думаю, что не это критично.

Ой-ли. Они не "существуют", их очень много. Я думаю каждый хотел бы сделать
чего-нибудь этакое. И лишь у очень немногих дело дошло хотя бы до первой
версии.

Ну вот предположим сколько ты знаешь удачно сделаных в таком стиле
бухгалтерских программ?

> В лучшем
> случае большой массой бесплатных разработчиков обеспечивается быстрое
> тестирование и затыкание мелких глюков, но успех/неуспех проекта определяет
> не это.

Это. Успех проекта обеспечивает а) качество б) подгон под требования
пользователя. И то и другое стоят гораздо дороже, чем кодирование.

> Вопрос -- что?

Знания в предметной области и желание иметь подобное для себя бесплатно.

Опять же. Что делают люди. Компиляторы, редакторы, средства разработки,
обработки текста. Ученые делают разные красивые прикладухи (на деньги от
грантов). Редко-редко удается увидеть чего-то хорошее, сделанное в таком стиле
и не относящееся напрямую к категории науки и информатики. Т.е. некоторые
бухгалтера может быть и пытаются сделать что-то, но не получается.

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

Я видел прекрасную систему оптических расчетов. Она переплевывала все системы,
созданные хорошими мощьными коллективами по своим возможностям и удобству
работы. Ее написал один человек. Он был профессиональный оптик. Писал он на
Бейсике около 30 лет. Для того, чтобы это работало с нормальной скоростью,
нужен был МикроВакс.

> vrudowit> Единственное, что я считаю разумным делать, это запускать
> vrudowit> спеллинг. Естественно все должно через него проходить :-)
> vrudowit> Естественно и программа должна быть соответствующая и вместо URL
> vrudowit> не предлагать URI.
>
> Какой спеллинг?

Английского языка :-)

> Я имею в виду, что компилятор намного эффективнее обнаруживает
> синтаксические ошибки.

:-/

> И для этого его нужно использовать. Логические
> ошибки должен обнаруживать человек (используя по возможности средства
> автоматизации)

"Тот кто хочет, может есть руками, а я предпочитаю есть ротом" (С) Пеппи Д.-Ч.

Я предлагаю использовать голову.

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

> Компилятор и человек эффективно находят разные ошибки.

Одни и те же. Если считать все время вместе. Когда ошибки находит компилятор,
то их исправление не только эффективно помогает, но и помогает эффективно
изменять ошибки на более хитрые.

На память приходит случай, когда один деятель обозвал разные переменные num &
nNumber (я бы за такое убивал сразу). После того, как компилятор обругал его
по какой-то мелочи, он вставил приведение типов и изменил имя переменной.
Ошибку, которую он внес, искать пришлось часа 4.

> 6 человек, 5 часов, ой.... :) А какие результаты у DeMarco получились?

Разные ;-). У него статистические результаты, а тебе нужны свои и для
выяснения своих вопросов. А 6 человек на 5 часов на природу водку пьянствовать
не ой?

> --
> SY, Andrey V Khavryutchenko

Regards!

Vit, вспоминающий, как наша группа каждый раз, устав от фирменного праздника,
играла по сети в DOOM или что-нибудь такое же душевное.

[vrud...@onestone.de]

In article <x7lnudt...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> ----- Вайнберговские диаграммы воздействия ...
> URL?

:-(

Смог найти только его сайт.
http://www.geraldmweinberg.com/

> vrudowit> PPS.: У Sh-M и Буча разное понимание того, что такое Software
> vrudowit> Arcitecture. И договориться они не могут. О какой универсальности
> vrudowit> тут можно говорить?
>
> Для того, чтобы иметь возможность достичь понимания, нужно говорить на
> одном языке. Например UML

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

> --
> SY, Andrey V Khavryutchenko

-----== Posted via Deja News, The Leader in Internet Discussion ==-----

[vrud...@onestone.de]

In article <350A809C...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> Uuups ! У нас не стоит проблема общения между професором медицины и
> дворником.у нас проблема общения людей занимающися SD.

У Вас или у UML? Так-с читаем.

What is the Unified Modeling Language (UML)?

The Unified Modeling Language (UML) is a language for
specifying, visualizing, constructing, and documenting the
artifacts of software systems, as well as for business modeling
and other non-software systems. The UML represents a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
collection of best engineering practices that have proven
^^^^ ;-)
successful in the modeling of large and complex systems.
^^^^^ ой люди ругаются. :-)

> И UML даёт нормальную возмоджность
> из обьекта "пиписка" зделать обьект "^#@@@#" для дворника и обьект типа
> "жалко латыни не знаю" для професора если это понадобится.

Автоген тоже дает возможность вырезать гланды. Я уже почувствовал что мне не
нравиться в UML. Видимо в скором времени я смогу это четко сформулировать,
чтобы было понятно и остальным.

> > > UML -- это язык, а не философия. Точнее, настолько же философия,
> > > насколько ей является любой другой язык.
> >
> > Вот именно.
>

> Хм...:) саморасширяемых (в понятии UML) языков я не знаю. Наверно из-за того

Fort, Lisp ...
Тот же C++ - саморассширившийся C. Еще недавно все компиляторы строили сначала
сишный код, а потом его компилировали.

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

Пролог.

> А что, с ER модялими и DFD или IDEF0 лучше ? Здесь я нарисовал эту
> стрелочку потому чтотут уменя множественное связь а вот на этот кружочек не
> смотрите потомучто я привык в 3НФ думать.

Лучше. По крайней мере двойная стрелка воспринимается гораздо лучше, чем
"0...n". Я уже не говорю о "1,2,5-10,12,36" которые лучше на диаграмме не
показывать.

Если я вижу одно из знакомых обозначений, я понимаю, что человек будет
говорить в рамках определенного метода. Если я вижу незнакомое обозначение, я
готов в любой момент спросить: "А зачем Вы так сделали?" Заметьте, вопрос не
тождественен вопросу "Что это обозначает?"

> Мне кажется мы путаем стадию анализа и проектирования.

И в чем же именно? :-)

> Так В UML и написано "its belongs to tools responsibility"

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

> > Другие производители, чтобы сделать что-то удобочитабельное подходят к
> > делу еще проще. В доке написано "В нотации UML это выглядит так, а тут на
> > картинке Вы видите, как мы исправили это безобразие, чтобы было понятно,
> > читабельно и работать с этим можно было бы по-человечески".

> Так они при этом пишут что их продукт совместим с UML ? (тогда пришлось бы
> писать что NT это полноценный UNIX)

Ну и Rational пишет, что их Роза поддерживает UML. Врут гады. :-)

А про NT так и пишут, что это защищенная ОС, пригодная для того, чтобы на ней
работали службы Интернет.

> Sincerely, Alexander

Regards!

Vit

[vrud...@onestone.de]

In article <x7k99xt...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> >> Погоди, а почему ты считаешь, что язык предполагает методологию? На
> >> русском можно писать и "Войну и Мир" и бульварные статьи. И пишутся они
> >> принципиально по разному.
>

> > :-))) Ну нельзя приводить примеры, которые противоречат своим же

> > собственным высказываниям.
> > -Французкий знаете хорошо?

> > -"Войну и Мир" читаю без словоря.

>
> Не понял аналогии :( Объясни темному.

"Война и Мир" написана наполовину по-французски. Если эту половину убрать, то
получится понятнее, но это будет уже не "Война и Мир"

Потом в "Войне и Мире" словарь гораздо больше. Качество писателя напрямую
связано с количеством употребляемых им слов. Разные оттенки, разные интонации,
разная смысловая нагрузка. Дворник должен говорить, как дворник, профессор
медицины, как професор медицины, а король, как король. Иначе это не
литература.

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

> > Ага :-) Уничтожение бумаг перед попадением на стол начальника.

> > Каждое утро проверяешь есть ли на столе чего-нибудь этакое. Если

> > есть "Уй! Дайте почитать! У Вас наверно времени нет." И сразу

> > бегом в машинку, которая бумагу уничтожает. У меня как раз такая

> > перед носом стоит. :-)
>
> Нет. Свобода информации. Начальник может читать все, что угодно. Но
> тебе-то читать это не надо :)

То, что понравится моему начальнику, появится у меня на рабочем столе в
качестве стандарта.

> А где ты видел, чтобы _базовые_ понятия какой-либо системы определялись не
> через себя?

Язык программирования С.

> Вот, мне сейчас в аспирантуре пудрят мозги философией. Преподаватель очень
> обиделся, когда я сказал, что философия -- это не наука, потому, что
> избегает определения своих базовых понятий :)

!!!
Если преподаватель мог на такое обидеться, то он не философ. У нас мужик читал
курс лекций по метофилософии (правда читал отвратно). Так то, что философия -
это не наука, метофилософия доказывает. А насчет базовых понятий ты не прав. Я
бы сказал, что она только тем и занимается, что определяет базовые понятия.

> vrudowit> Ну, а если начальники и отдел маркетинга начнут читать "UML для

> vrudowit> идиотов", ...

> На любом языке нужно учится говорить. Даже на русском, как ты
> продемонстрировал в этом примере :-P

На языке надо учиться _думать_. У нас преподавательница английского так и
говорила:
"Пока вы не научитесь думать на английском, у вас с языком будут проблемы"

:-P

> vrudowit> Вот смотрю я сейчас на диаграму, которая в Розе для С++ у меня
> vrudowit> нарисована и думаю кому я больше верю тебе или своим глазам. Ну
> vrudowit> нету, например, в "Notation" ни ключиков ни замочков. :-/
>
> Это веяния a-la MS. Правда, в Notation есть места, разрешающие это.

Но единства формы и содержания нет. Как нет и универсальности. А это веяния не
M$, это горькая правда жизни. С языком должно быть удобно работать. Иначе он
умрет, как умер уже ни один искусственно созданый "универсальный" язык.
(обычный человеческий)

> vrudowit> PS.: В Розе есть замечательная штука - исходный текст

> vrudowit> модели. ...

> Проблемма в том, что этот формат недокументирован :(

Разобраться с форматом мне удалось быстрее, чем с нотацией UML. Что в
очередной раз доказывает. ;-)

> --
> SY, Andrey V Khavryutchenko

Regards!

Vit

PS.: "Да здравствует UML, новояз информатики!"

[vrud...@onestone.de]

In article <35092614...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> Сам себя часто на этом ловил когда совершал героический путь
> BASIC=>Assembler=>Pascal=>Object Pascal=>C++.

Все мы там были, но многие остановились.

> Однако ходят слухи что отрасль замедляет свои темпы развития (у них за
> бугром обьявляют
> моратории на разработку нового софта до решения проблемы 2000).

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

> Да видно далеко буржуям до Total Quality Control. Хотя сами сюда приезжают
> и лекциина эту тему читают.

В одной бумаге был график по введению softwaremetrics по годам. Количество
попыток и количество удачных случаев. За последние годы количество попыток
растет по экспоненте. Количество удачных случаев - линейно и давольно
медленно. А когда-то удачными были 90%...

Я все больше убеждаюсь, что новое вводится не столько из-за потребностей
улучшения, сколько из желания заработать деньги.

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

> > > Язык предполагает методологию только на стадии Implementation.
> >
> > Только, если это язык программирования. Если язык применяется на всех
> > стадиях, то он влияет на все стадии.
>
> Надеюсь Вы имеете ввиду только стадию проектирования.

Не надейтесь.

> Она ведь, как и жизненный
> цикл системы, не однородна + проблемы предметной области ( и другие
> политические факторы) должны определятьязык а не наоборот.

Может быть и должны, но язык определяет фильтры и описание. Англичанин думает
не так, как китаец. Человек, пишущий на Форте не так, как пишущий на Смолтоке.

> > Или виртуальное наследование поддерживается, или не поддерживается.

...

> Меня когда-то мучал этот вопрос. Он сроден вопросу на который я так и не
> смог получить вопросв конференции ООD: Если у меня есть свойства обьекта N
> штук которые можно вынести в другие
> обьекты то при каком N это необходимо делать ?.

IMHO когда это становится удобнее.

> Например: Обьект хар-зуется формой, цветом и т.д (напр Синий Шар).
> Так вот оказалось что это можно было решить не только в ООP как
> множественное наследование но и легко решалось и в обыкновенном структурном
> подходе списком структур. Аналогично я почти
> уверен что и виртуальное наследование реализуется примерно как
> switch structType
> 1:..
> 2:...

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

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

:-) Почитайте Ш-М на UML.

> > А дыр в UML достаточно, я уже не говорю о тех CASE, которые заявляют, что
> > его поддерживают.
>
> А где ж их нет ?

После заявления Б.Гейтса о том, что если бы автопромышленность развивалась так
же, как софт, то это стоило бы копейки и ехало на капле бензина,
Дженерал-Моторс ответило: "А хотели бы Вы чинить свой автомобиль 2 раза в
день?"

Скажем так у Ш-М дыр я не нашел. Есть многие места, которые мне не нравятся,
но они не принципиальны.

Есть много систем реального времени в которых до сих пор не обнаружено ни
одной ошибки.

> Sincerely, Alexander

Regards!

Vit

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <x7lnudt...@netmaster.compchem.kiev.ua>, Andrey V
v> PPS.: У Sh-M и Буча разное понимание того, что такое Software
v> Arcitecture. И договориться они не могут. О какой
v> универсальности тут можно говорить?

>> Для того, чтобы иметь возможность достичь понимания, нужно говорить на
>> одном языке. Например UML

v> Для того, чтобы достичь понимания, надо согласовать понятия. А
v> "универсальный" язык ухудшает восприятие специфики выразительных
v> средств. Если хотите понимать китайца, лучше выучить несколько слов
v> по-китайски, чем учить эсперанто.

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

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <x7n2ett...@netmaster.compchem.kiev.ua>, Andrey V
v> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

>> Я хочу установить, только ли бесплатное рабочее время определяет
>> успешный результат проекта в стиле базара. Поскольку существуют
>> (surprise! ;) ) и неудачные проекты в этом стиле, то я думаю, что не
>> это критично.

v> Ой-ли. Они не "существуют", их очень много. Я думаю каждый хотел бы
v> сделать чего-нибудь этакое. И лишь у очень немногих дело дошло хотя бы
v> до первой версии.

v> Ну вот предположим сколько ты знаешь удачно сделаных в таком стиле
v> бухгалтерских программ?

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

Выбирай на вкус :)

>> В лучшем случае большой массой бесплатных разработчиков обеспечивается
>> быстрое тестирование и затыкание мелких глюков, но успех/неуспех
>> проекта определяет не это.

v> Это. Успех проекта обеспечивает а) качество б) подгон под требования
v> пользователя. И то и другое стоят гораздо дороже, чем кодирование.

Хорошо. Предлагается такой сценарий для коммерческой разработки.

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

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

Возможные проблеммы?

>> Вопрос -- что?

v> Знания в предметной области и желание иметь подобное для себя
v> бесплатно.
[skip]
v> Я видел прекрасную систему оптических расчетов. Она переплевывала все
v> системы, созданные хорошими мощьными коллективами по своим возможностям
v> и удобству работы. Ее написал один человек. Он был профессиональный
v> оптик. Писал он на Бейсике около 30 лет. Для того, чтобы это работало с
v> нормальной скоростью, нужен был МикроВакс.

Я знаком с такими системами :) Вон, на той машине, с которой сейчас пишу,
крутится задачка по вычислительной химии. Написана парой из hard-core
химика-теоретика и такого-же химика-экспериментатора (правда, бывшего
экспериментатора). В код я предпочитаю не залазить :))) Для того, чтобы
ей пользоваться относительно свободно нужно поработать с ней года три
минимум. Однако, результаты она выдает такие, что на мировом рынке у
народа челюсть отваливается. Они только на паралельных машинах и на Креях
таким занимаются. И так, как мы задачу не ставим. И, естественно, об
индустриальном применении речь не идет... :)))

Так, увлекся.... ;)

v> Единственное, что я считаю разумным делать, это запускать
v> спеллинг. Естественно все должно через него проходить :-)
v> Естественно и программа должна быть соответствующая и вместо URL
v> не предлагать URI.
>> Какой спеллинг?

v> Английского языка :-)

Хм...

>> Я имею в виду, что компилятор намного эффективнее обнаруживает >

v> синтаксические ошибки.

v> :-/

Да/нет?

>> И для этого его нужно использовать. Логические ошибки должен
>> обнаруживать человек (используя по возможности средства
>> автоматизации)

[иносказания skipped]
v> Вот знающие (т.е. делавшие соответствующие опыты) люди говорят, что
v> если человек будет искать просто ошибки, то у него это будет
v> эффективнее, чем искать только логические или только синтаксические
v> ошибки. И я все больше убеждаюсь в их правоте.

Нужно искать _просто_ ошибки. Но ошибки бывают разные, и, соответственно,
разные средства находят их с разной эффективностью.

>> Компилятор и человек эффективно находят разные ошибки.

v> Одни и те же. Если считать все время вместе. Когда ошибки находит
v> компилятор, то их исправление не только эффективно помогает, но и
v> помогает эффективно изменять ошибки на более хитрые.

В модуле есть 1 синтаксическая ошибка и 1 логическая.

Принимается, что синтаксическая ошибка при первом просмотре не
обнаруживается

Твой вариант:
Человек просматривает код 1 раз и обнаруживает 1 логическую ошибку

Мой вариант:
Человек запускает компилятор и обнаруживает 1 синтаксическую ошибку
Человек просматривает код 1 раз и обнаруживает 1 логическую ошику

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

Итого, где эффективность выше, при условии, что
время работы компилятора << времени ручного просмотра кода?

>> 6 человек, 5 часов, ой.... :) А какие результаты у DeMarco
>> получились?

v> Разные ;-). У него статистические результаты, а тебе нужны свои и для
v> выяснения своих вопросов. А 6 человек на 5 часов на природу водку
v> пьянствовать не ой?

Мы не пьянствуем ;)

Так какие же результаты он получил?

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <350A809C...@usa.net>, "Alexander V.Didytch"
v> <unknown....@usa.net> wrote:

>> А что, с ER модялими и DFD или IDEF0 лучше ? Здесь я нарисовал эту
>> стрелочку потому чтотут уменя множественное связь а вот на этот
>> кружочек не смотрите потомучто я привык в 3НФ думать.

v> Лучше. По крайней мере двойная стрелка воспринимается гораздо лучше,
v> чем "0...n". Я уже не говорю о "1,2,5-10,12,36" которые лучше на
v> диаграмме не показывать.

Не показывай, в чем проблемма-то?

v> Если я вижу одно из знакомых обозначений, я понимаю, что человек будет
v> говорить в рамках определенного метода. Если я вижу незнакомое
v> обозначение, я готов в любой момент спросить: "А зачем Вы так сделали?"
v> Заметьте, вопрос не тождественен вопросу "Что это обозначает?"

Почему ты ставишь именно этот вопрос? Непонятна его логика и ожидаемый
ответ.

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

>> Мне кажется мы путаем стадию анализа и проектирования.

v> И в чем же именно? :-)

>> Так В UML и написано "its belongs to tools responsibility"

v> Ага. Вот жду кто же научится вместо прямых линий кривые рисовать (а то
v> при большом количестве классов в их мешанине не разобраться) и
v> черно-белые квадраты или с круглыми углами или с хорошо различимыми
v> признаками делать.

Не рисуй на одной диаграмме много классов. Больше десятка -- явно много.

[Andrey V Khavryutchenko]

Поменял сабжет обратно в нормальную кодировку

>>>>> "v" == vrudowit writes:

v> In article <x7k99xt...@netmaster.compchem.kiev.ua>, Andrey V
v> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

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

v> "Война и Мир" написана наполовину по-французски. Если эту половину
v> убрать, то получится понятнее, но это будет уже не "Война и Мир"

v> Потом в "Войне и Мире" словарь гораздо больше. Качество писателя
v> напрямую связано с количеством употребляемых им слов. Разные оттенки,
v> разные интонации, разная смысловая нагрузка. Дворник должен говорить,
v> как дворник, профессор медицины, как професор медицины, а король, как
v> король. Иначе это не литература.

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

v> То же самое относится и к моделированию. У меня серьезные сомнения в
v> том, что человек, не могущий разобраться с новыми обозначениями, может
v> понять новое применение старых. Вот у меня на новые обозначения никогда
v> много времени не уходило, а сама идея метода требовала на порядок
v> больше усилий.

>> > Ага :-) Уничтожение бумаг перед попадением на стол начальника. >
>> Каждое утро проверяешь есть ли на столе чего-нибудь этакое. Если > есть
>> "Уй! Дайте почитать! У Вас наверно времени нет." И сразу > бегом в
>> машинку, которая бумагу уничтожает. У меня как раз такая > перед носом
>> стоит. :-)
>>
>> Нет. Свобода информации. Начальник может читать все, что угодно. Но
>> тебе-то читать это не надо :)

v> То, что понравится моему начальнику, появится у меня на рабочем столе в
v> качестве стандарта.

Т.е. твое мнение начальника не интересует? Объясни ему, что это всего-лишь
красивые картинки и толку с них для разработки не больше чем от картин
Пикассо на стенах в комнате, где сидят разработчики :)

>> А где ты видел, чтобы _базовые_ понятия какой-либо системы определялись
>> не через себя?

v> Язык программирования С.

>> Вот, мне сейчас в аспирантуре пудрят мозги философией. Преподаватель
>> очень обиделся, когда я сказал, что философия -- это не наука, потому,
>> что избегает определения своих базовых понятий :)

v> !!! Если преподаватель мог на такое обидеться, то он не философ. У нас

Так он и не философ :) Он только работает в Институте философии и имеет
степень доктора философских наук :)))

v> мужик читал курс лекций по метофилософии (правда читал отвратно). Так
v> то, что философия - это не наука, метофилософия доказывает. А насчет
v> базовых понятий ты не прав. Я бы сказал, что она только тем и
v> занимается, что определяет базовые понятия.

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

v> Ну, а если начальники и отдел маркетинга начнут читать "UML для
v> идиотов", ...

>> На любом языке нужно учится говорить. Даже на русском, как ты
>> продемонстрировал в этом примере :-P

v> На языке надо учиться _думать_. У нас преподавательница английского так
v> и говорила: "Пока вы не научитесь думать на английском, у вас с языком
v> будут проблемы"

v> :-P

s/говорить/думать/

Сути дела это не меняет.

v> Вот смотрю я сейчас на диаграму, которая в Розе для С++ у меня
v> нарисована и думаю кому я больше верю тебе или своим глазам. Ну
v> нету, например, в "Notation" ни ключиков ни замочков. :-/

>> Это веяния a-la MS. Правда, в Notation есть места, разрешающие это.

v> Но единства формы и содержания нет. Как нет и универсальности. А это
v> веяния не M$, это горькая правда жизни. С языком должно быть удобно
v> работать. Иначе он умрет, как умер уже ни один искусственно созданый
v> "универсальный" язык. (обычный человеческий)

Что ты понимаешь под "единством формы и содержания"? Смысл модели-то не
поменялся от того, что выбраны другие иконки.

v> PS.: В Розе есть замечательная штука - исходный текст
v> модели. ...

>> Проблемма в том, что этот формат недокументирован :(

v> Разобраться с форматом мне удалось быстрее, чем с нотацией UML. Что в
v> очередной раз доказывает. ;-)

Ничего это не доказывает. С ASCII форматом люди разбираются еще быстрее --
похоже на печатную машинку :)

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

v> PS.: "Да здравствует UML, новояз информатики!"

Есть предложения лучше?

[George Seriakov]

Привет!

On Thu, 12 Mar 1998 04:13:41 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

>> Хм, в хорошо организованном процессе работать _приятно_. Когда

>Это опыт или предположение?

Опыт. Козлинский нас в GRS-е так и менеджерил. Самым кайфовым моментом
там было, когда он мне выдал свою старую методику трансформационного анализа,
и я по ней преобразовал потоковые диаграммы системы в структурную схему. Я не
так давно слышал выступление Новоженова, он там хорошо сказал, что сквозь этот
язык (Джава) прозрачно виден ассемлер. Так вот, после трансформации я стал
сквозь DFD прозрачно видеть код системы. Потом я ее всю один и запрограммил,
т.к. она была проработана до деталей - до архитектуры, прототипов функций и
внутренней логики работы процессов.

>Когда заведения для умственно отсталых выпускали своих питомцев в свет,
>директора советских предприятий устраивали соревнование. Кто больше заманит к
>себе. На конвеер. Улавливаете к чему я клоню?

Улавливаю. Но когда я кодировал вышеупомянутую систему (что было делом
почти механическим), я не чувствовал себя дауном на конвейере. Я испытывал
кайф примерно сравнимый с кайфом разогнаться на автомашине на прямом участке.
Педаль газа в пол - и 140!

>готово. А нейдет-с. Неправильные какие-то работники попадаются. Вчера он это
>сделал за час, позовчера - за час, а сегодня пятый час и никакого результата.

Значит, задача не разбита на прямые участки. Никто и не говорил, что
это просто. Хороших манагеров вообще мало.

>Одной из основных причин неудачи одного известного мне великолепно и предельно
>точно :-) спланированного проекта являлось то, что забыли учесть, что люди
>иногда могут болеть или брать отпуск в неправильное время. И хорошо они на
>этом деле пролетели. Со свистом.

Ну, бывает. Ты же сам назвал причину. Только, подозреваю, они б
пролетели и без внезапного болезни/отпуска. Судя по стилю планирования.
Я бы не стал "учитывать, что люди иногда могут болеть или брать
отпуск", а попытался бы 1) добиться заменимости людей на основе
документированности разработки, 2) заложился бы припланировании на две
неблагоприятных случайности.

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

Тебе повезло. Я _знаю_, что такое СА. Это такой аттрактор, на котором
траектории неустойчивы, что приводит к стохастичности и к тому, что он имеет
дробные размерности. Не думаю, что тебе нужен _стохастический_ процесс
разработки.
Теперь в твоих метафорах. В системе есть два аттрактора. Один -
программирование ad hoc, второй - организованный процесс разработки, он же
самоорганизующийся. У каждого аттрактора своя область притяжения. Второй
процесс самоорганизующийся, поскольку любое отклонение от оптимальной
организации приводит к излишней траче сил, к напрасной работе. Но и у первого
аттрактора тоже есть своя область притяжения.

>Vit

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

Мы в GRS-е сдавали код после первичного семантического контроля
способом компиляции. Далее шла инспекция, контроль стиля. Тестирование было
после интеграции, но помодульно, стеклянным ящиком.
---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On Tue, 10 Mar 98 17:56:18 +0300, in relcom.comp.software-eng michael
<mic...@tokareff.pgu.karelia.su> wrote:

>> Вот это-то меня и интересуют. У меня есть серьезные подозрения, что кроме
>> кнута в этом процессе может участвовать и пряник. Вот его-то мне и надо
>> найти. А пока даже запаха его не встречал. :-(

>Пряника (во всяком случае на первых этапах) быть не может категорически.

На первых этапах, т.е. в области притяжения аттрактора процесса
разработки ad hoc.

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

Да. Без ключевого руководителя, сделавшего ставку на улучшение
процесса разработки дело с места не сдвинется.

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

Ну, не знаю. Может, одно подразделение (организованное) начнет
отличаться от другого тем, что начнет работать без авралов и срывов?

>Братишка мой недавно уволился. Та же ситуация, только еще банальнее --
>ему не удалось даже доказать начальству, что целостность базы данных --
>это НЕОБХОДИМЫЙ атрибут, без которого даже начинать ничего невозможно.

Может, это - черный список начать вести?

>Michael V. Tokarev.

---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On Thu, 12 Mar 1998 20:12:33 +0200, in relcom.comp.software-eng "Alexander
V.Didytch" <unknown....@usa.net> wrote:

>> Одной из основных причин неудачи одного известного мне великолепно и предельно
>> точно :-) спланированного проекта являлось то, что забыли учесть, что люди
>> иногда могут болеть или брать отпуск в неправильное время. И хорошо они на
>> этом деле пролетели. Со свистом.

>Они еще могут и перерабатывать и им может на какоето время так надоедать то что
>ониделают что их срочно надо переключать на что-то другое.

Именно это и должен делать правильный менеджер.

>Sincerely, Alexander

---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On Wed, 11 Mar 1998 03:06:13 -0600, in relcom.comp.software-eng
vrud...@onestone.de wrote:

>количестве. Совсем недавно слушал выступление одной тетки из отдела управления
>кадрами Siemens-Nixdorf. Расхваливала она один tool, переодически повторяя,
>что внедрение идет тяжело, люди мешают.

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

---
George Seriakov (seri...@aha.ru)

[vrud...@onestone.de]

In article <x7zpirs...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> Само собой. Но UML кроме синтаксиса (нотации) предоставляет еще и понятия,
> которыми он оперирует (семантика). До сих пор ни один метод не давал
> такой базы для нахождения общего понимания.

Я вот объяснял человеку некоторые особенности UML. После этого у меня очень
большие сомнения насчет "общего понимания" :-)

> (Может быть это есть в IDEFx,
> но (а) я этого не видел и (б) IDEFx не самодостаточен -- он не может
> описать свою семантику в своих-же терминах)

А ты уверен что это надо?

> --
> SY, Andrey V Khavryutchenko

-----== Posted via Deja News, The Leader in Internet Discussion ==-----

[Andrey V Khavryutchenko]

>>>>> "GS" == George Seriakov writes:

GS> Привет! On Thu, 12 Mar 1998 04:13:41 -0600, in
GS> relcom.comp.software-eng vrud...@onestone.de wrote:

>>> Хм, в хорошо организованном процессе работать _приятно_. Когда

>> Это опыт или предположение?

GS> Опыт. Козлинский нас в GRS-е так и менеджерил. Самым кайфовым
GS> моментом там было, когда он мне выдал свою старую методику
GS> трансформационного анализа, и я по ней преобразовал потоковые
GS> диаграммы системы в структурную схему. Я не так давно слышал
GS> выступление Новоженова, он там хорошо сказал, что сквозь этот язык
GS> (Джава) прозрачно виден ассемлер. Так вот, после трансформации я стал
GS> сквозь DFD прозрачно видеть код системы. Потом я ее всю один и
GS> запрограммил, т.к. она была проработана до деталей - до архитектуры,
GS> прототипов функций и внутренней логики работы процессов.

George, можешь подробнее описать эту методику? Или дать url?

GS> В системе есть два аттрактора. Один - программирование ad hoc, второй -
GS> организованный процесс разработки, он же самоорганизующийся. У каждого
GS> аттрактора своя область притяжения. Второй процесс самоорганизующийся,
GS> поскольку любое отклонение от оптимальной организации приводит к
GS> излишней траче сил, к напрасной работе. Но и у первого аттрактора тоже
GS> есть своя область притяжения.

Как ты считаешь, в каких координатах удобнее всего определять области
притяжения одного и второго аттрактора? Какие они?

[vrud...@onestone.de]

In article <x7wwdvs...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> v> Это. Успех проекта обеспечивает а) качество б) подгон под требования
> v> пользователя. И то и другое стоят гораздо дороже, чем кодирование.
>
> Хорошо. Предлагается такой сценарий для коммерческой разработки.
>
> Формируется группа специалистов в предметной области (на стороне
> исполнителя или на стороне заказчика), которая проверяет, насколько продукт
> соответствует реальным требованиям.
>
> Между этой группой (которая может состоять и из одного человека part-time)
> и разработчиками имеется широкий канал связи (т.е. они общаются часто и
> долго). Разработчики предоставляют этой группе снапшоты, скажем, каждую
> неделю.
>
> Возможные проблеммы?

"из одного человека part-time" ничего путного не выйдет. В том то и секрет
успеха, что а) специалистов много и б) они сами предлагают варианты решения
проблем.

Частое и долгое общение может занять все время.

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

> >> Я имею в виду, что компилятор намного эффективнее обнаруживает >
> v> синтаксические ошибки.
>
> v> :-/
>
> Да/нет?

Нет. Он не может понять логику программы.

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

Нужно искать все ошибки сразу. Это эффективнее. Предлагаю проверить.

> v> Одни и те же. Если считать все время вместе. Когда ошибки находит
> v> компилятор, то их исправление не только эффективно помогает, но и
> v> помогает эффективно изменять ошибки на более хитрые.
>
> В модуле есть 1 синтаксическая ошибка и 1 логическая.

...
for( int i = 0 ; i < XUZ ; i ++ ) {

...
if( in > 10 ) {
break ;
}
} // for
...

> Принимается, что синтаксическая ошибка при первом просмотре не
> обнаруживается

Почему? Нормально обнаруживается.

> Твой вариант:
> Человек просматривает код 1 раз и обнаруживает 1 логическую ошибку

in > 10

Нет такой переменной. "in" По логике быть не должно.

> Мой вариант:
> Человек запускает компилятор и обнаруживает 1 синтаксическую ошибку

in > 10

Исправляем "i > 10"
или еще хуже того вносим в оператор for.

> Человек просматривает код 1 раз и обнаруживает 1 логическую ошику

И не обнаруживает. Это была глобальная переменная n. Правильный вариант
n > 10

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

Эффективность выше в моем случае. В твоем не учитывается время тестирования +
время локализации + время исправления >> время неавтоматизированной проверки.

Важна не скорость нахождения отдельной ошибки, важно количество ошибок,
проверкой не найденных.

...

> >> 6 человек, 5 часов, ой.... :) А какие результаты у DeMarco
> >> получились?

...

> Так какие же результаты он получил?

Он об этих результатах книжки пишет. Некоторые отрывки я здесь уже
пересказывал.

> --
> SY, Andrey V Khavryutchenko

Regards!

Vit

[vrud...@onestone.de]

In article <35122076...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> > ... Совсем недавно слушал выступление одной тетки из отдела управления

> >кадрами Siemens-Nixdorf. Расхваливала она один tool, переодически повторяя,
> >что внедрение идет тяжело, люди мешают.
>
> Явление типичное - притяжение аттрактора 1 (неупорядоченная
> разработка). Для того, чтобы достичь зоны притяжения аттрактора 2
> (оптимальная
> разработка), нужно уйти довольно далеко от первого аттрактора.

Беда только в том, что система не ограничена только этими двумя аттракторами.
Уйдя давольно далекко от первого, можно достичь не второго, а коллапса. И
многие на этом деле пролетели. Я бы очень хотел посмотреть на статистику
экономических потерь в результате попыток введения CMM или ISO 9000

> ---
> George Seriakov (seri...@aha.ru)

[vrud...@onestone.de]

In article <x7soojsk...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

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

Ты это знаешь или тебе так кажется?

Есть такой язык, Ада называется. Вот у кого база, так база. А кроме вояк на
нем мало кто пишет. Почему? :-)

> v> То, что понравится моему начальнику, появится у меня на рабочем столе в
> v> качестве стандарта.
>
> Т.е. твое мнение начальника не интересует? Объясни ему, что это всего-лишь
> красивые картинки и толку с них для разработки не больше чем от картин
> Пикассо на стенах в комнате, где сидят разработчики :)

Читайте "Принцип Дилберта" - источник знаний о менеджменте.

> Тем не менее, как только определения даны, то вся система становится
> ясной.

Как там у Лема было:
Он снова пролистал энциклопедию и нашел "сикуление": "Сикуление - процесс в
котором применяются сикульки" и он попал в раздел "сикульки", с которого и
начал свой поиск.

> Тогда чем же занимаются философы?

Размышляют о смысле.

> v> Ну, а если начальники и отдел маркетинга начнут читать "UML для
> v> идиотов", ...
>
> >> На любом языке нужно учится говорить. Даже на русском, как ты
> >> продемонстрировал в этом примере :-P
>
> v> На языке надо учиться _думать_. У нас преподавательница английского так
> v> и говорила: "Пока вы не научитесь думать на английском, у вас с языком
> v> будут проблемы"
>
> v> :-P
>
> s/говорить/думать/
>
> Сути дела это не меняет.

Меняет.

"Передвинте стену к стулу!" - грамматически верное предложение.

> v> Разобраться с форматом мне удалось быстрее, чем с нотацией UML. Что в
> v> очередной раз доказывает. ;-)
>
> Ничего это не доказывает. С ASCII форматом люди разбираются еще быстрее --
> похоже на печатную машинку :)

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

> Информационная наполненость разная. Кроме того, в этом файле смешана
> информация о модели и диаграммах, на которых она изображена.

Ну кривой формат. Ничего сказать не могу. Кривой.

> v> PS.: "Да здравствует UML, новояз информатики!"
>
> Есть предложения лучше?

Есть. Для специальных целей использовать специальные языки.

> --
> SY, Andrey V Khavryutchenko

Regards!

[vrud...@onestone.de]

In article <350be46...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> >> Хм, в хорошо организованном процессе работать _приятно_. Когда

...

> Улавливаю. Но когда я кодировал вышеупомянутую систему (что было делом
> почти механическим), я не чувствовал себя дауном на конвейере. Я испытывал
> кайф примерно сравнимый с кайфом разогнаться на автомашине на прямом
> участке. Педаль газа в пол - и 140!

И как долго это продолжалось. Была ли другая работа кроме кодирования?

...

> Я бы не стал "учитывать, что люди иногда могут болеть или брать
> отпуск", а попытался бы 1) добиться заменимости людей на основе
> документированности разработки,

Сколько это стоит?

> 2) заложился бы припланировании на две
> неблагоприятных случайности.

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

> Тебе повезло. Я _знаю_, что такое СА. Это такой аттрактор, на котором
> траектории неустойчивы, что приводит к стохастичности и к тому, что он имеет
> дробные размерности. Не думаю, что тебе нужен _стохастический_ процесс
> разработки.

Он так и так стохастический. Я рассматриваю не повторение десятой версии
аналогичной разработки, а создание новой системы.

> Теперь в твоих метафорах. В системе есть два аттрактора. Один -
> программирование ad hoc, второй - организованный процесс разработки, он же
> самоорганизующийся.

Не факт. Или он самоорганизуется. Или шаг влево - шаг вправо...

> У каждого аттрактора своя область притяжения. Второй
> процесс самоорганизующийся, поскольку любое отклонение от оптимальной
> организации приводит к излишней траче сил, к напрасной работе.

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

> Но и у
> первого аттрактора тоже есть своя область притяжения.

Вот именно. И большинство проектов туда уходят.

> Мы в GRS-е сдавали код после первичного семантического контроля
> способом компиляции. Далее шла инспекция, контроль стиля. Тестирование было
> после интеграции, но помодульно, стеклянным ящиком.

Если не секрет что случилось с GRS и почему?

> ---
> George Seriakov (seri...@aha.ru)

[vrud...@onestone.de]

In article <x7wwdvs...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

Почему? Нормально обнаруживается.

in > 10

...

> >> 6 человек, 5 часов, ой.... :) А какие результаты у DeMarco
> >> получились?
...
> Так какие же результаты он получил?

Он об этих результатах книжки пишет. Некоторые отрывки я здесь уже
пересказывал.

> --
> SY, Andrey V Khavryutchenko

Regards!

[vrud...@onestone.de]

In article <x7u38zs...@netmaster.compchem.kiev.ua>,

Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> v> Лучше. По крайней мере двойная стрелка воспринимается гораздо лучше,
> v> чем "0...n". Я уже не говорю о "1,2,5-10,12,36" которые лучше на
> v> диаграмме не показывать.
>
> Не показывай, в чем проблемма-то?

В том, что показать надо, и чтобы понятно было.

> v> Если я вижу одно из знакомых обозначений, я понимаю, что человек будет
> v> говорить в рамках определенного метода. Если я вижу незнакомое
> v> обозначение, я готов в любой момент спросить: "А зачем Вы так сделали?"
> v> Заметьте, вопрос не тождественен вопросу "Что это обозначает?"
>
> Почему ты ставишь именно этот вопрос? Непонятна его логика и ожидаемый
> ответ.

Я получаю не определение из книжки, а логику применения данным конкретным
человеком.

> Не рисуй на одной диаграмме много классов. Больше десятка -- явно много.

Ты реальные проекты пробовал на UML делать?

[vrud...@onestone.de]

In article <350e1bf8...@news.aha.ru>,
seri...@aha.ru (George Seriakov) wrote:

> >Потом уже, когда некоторые подразделения видят, что они работают примерно
> >столько же, а по статистике сильно отстают (а в натуре -- просто
> >халявят при составлении отчетов и подсчете метрик), они начинают
> >чесать "репы" и думать что надо делать.
>
> Ну, не знаю. Может, одно подразделение (организованное) начнет
> отличаться от другого тем, что начнет работать без авралов и срывов?

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

> >Michael V. Tokarev.
>
> ---
> George Seriakov (seri...@aha.ru)

[Alexander V.Didytch]

vrud...@onestone.de wrote:

> --- Программиста работа достала.

Не работа а отсутвие пива по вечерам :-))

> > Кое-как можно, например устраивая коллективные вечера за пивом где можно
> > обсудить не только проблемы по работе или устраивая внутриколлективные
> > семинары.
>
> Если это планировать, то результат будет еще хуже. Как в Японии. Там решили,
> что нужно, чтобы работники проявляли индивидуальность и приказали (!) прити на
> работу в пятницу не в костюмах, а в свободной форме одежды. На следующий день
> поголовно весь персонал пришел как родные братья в серой спортивной
> форме. Это разные стили управления.

У нас бы все пришли небритые и в рваных джинсах.

> Вообщем мне жалко тех людей, которые работают под их руководством.

А что ? У них большинство книг написано мягко говоря для домохозяек. А тех кто
пишет
что-то серъёзнее (напр. Буч) называют научными маразматиками.

>
> > Единственное чему можно радоваться так это тому что у нас свой личный
> > подход к организации труда -- всё пофиг и "забей" на всё .
>
> У Вас это где? ;-)

В совке, где ж ещё.

> > > Это все из серии "План пятилетки в три года!"
> >
> > Буржуи этого и хотят -- с наименьшими затратами по больше денег.
>
> Ну не растет кукуруза за Полярным кругом! Даже если компутер говорит, что
> расти должна, она не хочет. Видимо ЭВМ надо взять помощьнее.

Для того чтобы получить тот-же результат.

> У меня приятель рассказывал про аналогичный случай. Люди делают жутко
> параллельный рассчет и вычисляют производительность, выкидывая все время,
> которое тратится на коммуникацию между процессорами. Жуткие цифры получаются.

Видимо люди жестоко увлеклись математикой.

> > > PS.: Как бы Вы отнеслись к выдвижению на рынок M$ UP(rogramming)L?
> >
> > Мне всё равно кто б его выдвинул и зарабатывал на нём деньги. Главное
> > чтобы он был действитель UPL а не поделка под VB.
>
> Боюсь, что именно подделка и получится. Ну не выгодно делать чего-то другое.

Это из области -- для системы масштаба предприятия необходимо поставить на
клиентскуючасть VB на сервер NT с MS SQL Server. И через несколько лет разработки
станет понятно
что всё необходимо культурненько соскребсти и в >NULL.

> > Я не имею ввиду стиль мышления о проблеме никто не запрещает Вам
> > в UML рисовать структурные диаграммы и менять местами стадии разработки
> > системы.
>
> Вы пробовали, или Вам так кажется?

Пробывал в области рисования ER-диаграмм и задания динамики системы.

> > Меня волнует общее понимание проблемы. Тоесть если я написал 2+2=4 то все б
> > поняли
> > что 2 это натуральное число а не какаето крокозябла.
>
> Вот первокласник Вас поймет. А математик спросит про систему счисления.
> Программист же просто ответит TRUE.

Прикладник да, системщик спросит про тип складываемых полей.

> Для того и нужны разные языки, чтобы их трудно было спутать. Вы никогда не
> пробовали одновременно писать программы на двух языках из разных групп,
> синтаксис которых очень похож? Смею Вам доложить очень интересное занятие.
>

Если Pascal и C++ то про что Вы говорите то это как-раз то чем Я сейчас занимаюсь.

Занятие "очень приятное" ;)

Sincerely, Alexander
--
..and Bill Gates says, "Let's close all the windows, get out, get back
in, and see if that fixes it." -- by Charles Martin

[Alexander V.Didytch]

vrud...@onestone.de wrote:

> Для того, чтобы достичь понимания, надо согласовать понятия. А "универсальный"
> язык ухудшает восприятие специфики выразительных средств. Если хотите понимать
> китайца, лучше выучить несколько слов по-китайски, чем учить эсперанто.
>

С начала неплохо было бы понять что он говорит а потом уточнять выразительность этих понятий.
Например на украинском слово "Бовдур" определяет нечто типа дурака а не умника. А степень
выразительности можно выяснить потом а не удивляться фразе. Я умный аблсолютный идиот.
Что и происходит между UML и S-M.

[Alexander V.Didytch]

Andrey V Khavryutchenko wrote:

> v> Для того, чтобы достичь понимания, надо согласовать понятия. А
> v> "универсальный" язык ухудшает восприятие специфики выразительных
> v> средств. Если хотите понимать китайца, лучше выучить несколько слов
> v> по-китайски, чем учить эсперанто.
>

> Само собой. Но UML кроме синтаксиса (нотации) предоставляет еще и понятия,
> которыми он оперирует (семантика). До сих пор ни один метод не давал

> такой базы для нахождения общего понимания. (Может быть это есть в IDEFx,

> но (а) я этого не видел и (б) IDEFx не самодостаточен -- он не может
> описать свою семантику в своих-же терминах)

Причём хочется сказать -- достаточно формальной и строгой семантики. (насчёт строгой пинать
ногами не надо:)).

Про IDEF и говорить не хочется -- малевалка для начальников цехов :). Хотя на начальных
стадиях разработки довольно помогает + семантику в IDEF кроме Activity и Events Flow я тоже не
встречал.

[Alexander V.Didytch]

Andrey V Khavryutchenko wrote:

> Alexander> знаю. Наверно из-за того что у нихпредназначение разное -- UML
> Alexander> -- больше тянет на представление знаний а язык програмирования
> Alexander> на реализацию задания.
>
> Я больше имел в виду не язык программирования, а естественный язык.

Я не специалист в области филологии но мне кажется что естественный язык
слишком не строг.

[Alexander V.Didytch]

vrud...@onestone.de wrote:

> Автоген тоже дает возможность вырезать гланды. Я уже почувствовал что мне не
> нравиться в UML. Видимо в скором времени я смогу это четко сформулировать,
> чтобы было понятно и остальным.

Я думаю что понял Вас. Однако когда нет ничего другого автогеном приходится тоже
иногдапользоваться. :) Проблема типа

Понимание => Решение проблемы должна сначала решаться на UML (чтобы до конца во
всём разобратья)

А потом уже пытаться сделать что-то другое если результаты "Решения" не
устраивают. Проблема
только в том что "неустраиваемость" появляется только на интуитивном уровне --
Опыт великое дело.
(Кто бы мне его занял ?)

> Fort, Lisp ...
> Тот же C++ - саморассширившийся C. Еще недавно все компиляторы строили сначала
> сишный код, а потом его компилировали.

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

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

Хм. В пректировании нигде не встречал необходимость пользоваться "Откатом".

> > А что, с ER модялими и DFD или IDEF0 лучше ? Здесь я нарисовал эту
> > стрелочку потому чтотут уменя множественное связь а вот на этот кружочек не
> > смотрите потомучто я привык в 3НФ думать.
>

> Лучше. По крайней мере двойная стрелка воспринимается гораздо лучше, чем
> "0...n". Я уже не говорю о "1,2,5-10,12,36" которые лучше на диаграмме не
> показывать.

А двойная стрелочка с разными типами штриховки в начале, середине и конце ?

> Если я вижу одно из знакомых обозначений, я понимаю, что человек будет

> говорить в рамках определенного метода. Если я вижу незнакомое обозначение, я
> готов в любой момент спросить: "А зачем Вы так сделали?" Заметьте, вопрос не

> тождественен вопросу "Что это обозначает?"

И Вы получите только частный ответ того что означает этот знак что может привестик
неверному пониманию других частей диаграммы.

> > Мне кажется мы путаем стадию анализа и проектирования.
>

> И в чем же именно? :-)

Мне кажется для Вас это один сплошной процесс, для меня он "многоступечатый"

> > Так В UML и написано "its belongs to tools responsibility"
>

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

Для этого необходимо пользоваться Refinement и не generalization и разбивать
системуна подсистемы (Packages) а не сливать всё в кучу. (Простите если очень
резко сказано)

> > Так они при этом пишут что их продукт совместим с UML ? (тогда пришлось бы
> > писать что NT это полноценный UNIX)
>
> Ну и Rational пишет, что их Роза поддерживает UML. Врут гады. :-)

Жить же за что-то надо.

> А про NT так и пишут, что это защищенная ОС, пригодная для того, чтобы на ней
> работали службы Интернет.
>

Только иногда на Microsoft достучаться нельзя.

[Alexander V.Didytch]

vrud...@onestone.de wrote:

> In article <x7k99xt...@netmaster.compchem.kiev.ua>,

> Andrey V Khavryutchenko <akh...@compchem.kiev.ua> wrote:
>
> >

> > Не понял аналогии :( Объясни темному.
>

> "Война и Мир" написана наполовину по-французски. Если эту половину убрать, то

> получится понятнее, но это будет уже не "Война и Мир"
>

> Потом в "Войне и Мире" словарь гораздо больше. Качество писателя напрямую
> связано с количеством употребляемых им слов. Разные оттенки, разные интонации,
> разная смысловая нагрузка. Дворник должен говорить, как дворник, профессор
> медицины, как професор медицины, а король, как король. Иначе это не
> литература.

Интересно как бы выглядели Ваши диаграмы если бы вы их вырисовывали в
интонацияхпользователей системы.

> То же самое относится и к моделированию. У меня серьезные сомнения в том, что
> человек, не могущий разобраться с новыми обозначениями, может понять новое
> применение старых. Вот у меня на новые обозначения никогда много времени не
> уходило, а сама идея метода требовала на порядок больше усилий.

А если новых обозначений слишком много ?.

> > Нет. Свобода информации. Начальник может читать все, что угодно. Но
> > тебе-то читать это не надо :)
>

> То, что понравится моему начальнику, появится у меня на рабочем столе в

> качестве стандарта.

И мною не одобряемое ?

> > А где ты видел, чтобы _базовые_ понятия какой-либо системы определялись не
> > через себя?
>

> Язык программирования С.

Можно ли пополнее ?

> > На любом языке нужно учится говорить. Даже на русском, как ты
> > продемонстрировал в этом примере :-P
>

> На языке надо учиться _думать_. У нас преподавательница английского так и
> говорила:
> "Пока вы не научитесь думать на английском, у вас с языком будут проблемы"
>

Но ведь надо с чего-то начинать и делать ошибки ? Или алфавит учится за 1 секунду
?

Sincerely, Alexander

> PS.: "Да здравствует UML, новояз информатики!"

Урра! Все на субботник по UML ?. :)

[Alexander V.Didytch]

Andrey V Khavryutchenko wrote:

> v> Ага. Вот жду кто же научится вместо прямых линий кривые рисовать (а то
> v> при большом количестве классов в их мешанине не разобраться) и
> v> черно-белые квадраты или с круглыми углами или с хорошо различимыми
> v> признаками делать.

>
> Не рисуй на одной диаграмме много классов. Больше десятка -- явно много.
>

В IDEF говорилось от 3 до 6. Причём на вопрос почему 6 отвечали -- потому что
это
просто правильное число.

Sincerely, Alexander

Andrey V Khavryutchenko wrote:

P.S. У меня была одна из таких диаграм -- повесил на стене чтобы все думали что
там нарисовано
нечто значимое и нифига не понимали при чём смешно было наблюдать за людьми
которые там пытались чего-то понять.

P.P.S. Через месяц за мной стало тоже интересно наблюдать.

[Alexander V.Didytch]

George Seriakov wrote:

> Привет!

>
>
> >Они еще могут и перерабатывать и им может на какоето время так надоедать то что
> >ониделают что их срочно надо переключать на что-то другое.
>
> Именно это и должен делать правильный менеджер.
>

Проблема в том как это сделать чтобы и овцы (программисы) были целы волки (менеджера)

были сыты. + Создать атмосферу в которой переключение с работы на работу не считалось
бы
чем-то плохим и не хорошим.

P.S. А как на Ваш взгляд можно установить "доверительные" отношения между
программистом и его
начальником ? У них только одна вещь общая -- вовремя здать систему.

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <x7soojsk...@netmaster.compchem.kiev.ua>, Andrey V
v> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

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

v> Ты это знаешь или тебе так кажется?

Ты видишь разницу? Хорошо, более точное утверждение:

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

v> Есть такой язык, Ада называется. Вот у кого база, так база. А кроме
v> вояк на нем мало кто пишет. Почему? :-)

Потому что стараниями DoD USA был создан закрытый рынок с высокой ценой
вхождения и без потенциала к расширению.

v> То, что понравится моему начальнику, появится у меня на рабочем столе в
v> качестве стандарта.
>> Т.е. твое мнение начальника не интересует? Объясни ему, что это
>> всего-лишь красивые картинки и толку с них для разработки не больше чем
>> от картин Пикассо на стенах в комнате, где сидят разработчики :)

v> Читайте "Принцип Дилберта" - источник знаний о менеджменте.

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

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

>> Тем не менее, как только определения даны, то вся система становится
>> ясной.

v> Как там у Лема было: Он снова пролистал энциклопедию и нашел
v> "сикуление": "Сикуление - процесс в котором применяются сикульки" и он
v> попал в раздел "сикульки", с которого и начал свой поиск.

/В моем переводе были сепульки :) /

Так, поехали в философию...

1. Источником знания человека об окружающем мире являются _только_ его
органы чувств.

2. Органы чувств человека поставляют неточную и неполную информацию.

3. Все умозаключения человека о внешнем мире могут строится только на этих
двух факторах.

Итак, на базе каких понятий ты хочешь строить язык для описания семантики
предметной области (т.е. для анализа и дизайна)?

Требования к нему:

1. Он должен быть похож на уже существующий, чтобы его было просто учить

2. Он должен достаточно отличаться от уже существующих, чтобы его не путали
с ними :)

3. Он должен иметь небольшое ядро основных понятий

4. Он должен уметь описать свою семантику

Итак?

>> >> На любом языке нужно учится говорить. Даже на русском, как ты >>
>> продемонстрировал в этом примере :-P
>>

v> На языке надо учиться _думать_. У нас преподавательница
v> английского так и говорила: "Пока вы не научитесь думать на английском,
v> у вас с языком будут проблемы"

>>
v> :-P
>> s/говорить/думать/ Сути дела это не меняет.

v> Меняет.

v> "Передвинте стену к стулу!" - грамматически верное предложение.

И что, ситуации, где оно было бы верным отсутствуют?

v> Разобраться с форматом мне удалось быстрее, чем с нотацией UML. Что в >

v> v> очередной раз доказывает. ;-)

>> Ничего это не доказывает. С ASCII форматом люди разбираются еще
>> быстрее -- похоже на печатную машинку :)

v> У меня есть подозрение, что английский более универсальный и
v> расширяемый, чем UML. Почему бы не писать все на нем.

Он менее однозначен, чем UML. Ты, например, его знаешь хуже :)

v> PS.: "Да здравствует UML, новояз информатики!"
>> Есть предложения лучше?

v> Есть. Для специальных целей использовать специальные языки.

Для каждого приложения создавать свой язык проектирования. Возврат к
временам ассемблеров на новом витке спирали. Нет, спасибо.

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <x7u38zs...@netmaster.compchem.kiev.ua>, Andrey V
v> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

v> Лучше. По крайней мере двойная стрелка воспринимается гораздо лучше,
v> чем "0...n". Я уже не говорю о "1,2,5-10,12,36" которые лучше на
v> диаграмме не показывать.
>> Не показывай, в чем проблемма-то?

v> В том, что показать надо, и чтобы понятно было.

Ну, тогда показывай :)

В других языках ты этого ведь сделать не можешь. (По крайней мере ни в
OMT, ни в Буче)

v> Если я вижу одно из знакомых обозначений, я понимаю, что человек будет
v> говорить в рамках определенного метода. Если я вижу незнакомое
v> обозначение, я готов в любой момент спросить: "А зачем Вы так сделали?"
v> Заметьте, вопрос не тождественен вопросу "Что это обозначает?"
>> Почему ты ставишь именно этот вопрос? Непонятна его логика и
>> ожидаемый ответ.

v> Я получаю не определение из книжки, а логику применения данным
v> конкретным человеком.

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

>> Не рисуй на одной диаграмме много классов. Больше десятка -- явно
>> много.

v> Ты реальные проекты пробовал на UML делать?

Да, хотя сквозной документации не удалость достичь. Несвязанные диаграммы
применяю постоянно.

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <x7zpirs...@netmaster.compchem.kiev.ua>, Andrey V
v> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

>> Само собой. Но UML кроме синтаксиса (нотации) предоставляет еще и
>> понятия, которыми он оперирует (семантика). До сих пор ни один метод
>> не давал такой базы для нахождения общего понимания.

v> Я вот объяснял человеку некоторые особенности UML. После этого у меня
v> очень большие сомнения насчет "общего понимания" :-)

Плохо объяснял :)

>> (Может быть это есть в IDEFx, но (а) я этого не видел и (б) IDEFx не
>> самодостаточен -- он не может описать свою семантику в своих-же
>> терминах)

v> А ты уверен что это надо?

Уверен, поскольку при разработке нужно, в первую очередь, описывать
семантику предметной области. А если язык для описания семантики не может
описать себя (чем не предметная область?), то на кой черт он нужен?

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <x7wwdvs...@netmaster.compchem.kiev.ua>, Andrey V
v> Khavryutchenko <akh...@compchem.kiev.ua> wrote:

v> Это. Успех проекта обеспечивает а) качество б) подгон под требования
v> пользователя. И то и другое стоят гораздо дороже, чем кодирование.
>> Хорошо. Предлагается такой сценарий для коммерческой разработки.
>>
>> Формируется группа специалистов в предметной области (на стороне
>> исполнителя или на стороне заказчика), которая проверяет, насколько
>> продукт соответствует реальным требованиям.
>>
>> Между этой группой (которая может состоять и из одного человека
>> part-time) и разработчиками имеется широкий канал связи (т.е. они
>> общаются часто и долго). Разработчики предоставляют этой группе
>> снапшоты, скажем, каждую неделю.
>>
>> Возможные проблеммы?

v> "из одного человека part-time" ничего путного не выйдет.

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

v> В том то и
v> секрет успеха, что а) специалистов много и б) они сами предлагают
v> варианты решения проблем.

v> Частое и долгое общение может занять все время.

Т.е. ты считаешь, что конечного пользователя к тестированию привлекать не
надо? А если и привлекать, то как можно позже? :)

Не согласен категорически.

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

Oops. Communication gap.

Snapshot -- текущий вид програмного продукта "как есть". С багами,
недоработками, etc. Т.е. то, что ты говоришь.

>> >> Я имею в виду, что компилятор намного эффективнее обнаруживает >
v> синтаксические ошибки.
>>
v> :-/
>> Да/нет?

v> Нет. Он не может понять логику программы.

Я что написал? с-и-н-т-а-к-с-и-ч-е-с-к-и-е. Логика и синтаксис -- разные
вещи.

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

v> Нужно искать все ошибки сразу. Это эффективнее. Предлагаю проверить.

v> Одни и те же. Если считать все время вместе. Когда ошибки находит
v> компилятор, то их исправление не только эффективно помогает, но и
v> помогает эффективно изменять ошибки на более хитрые.
>> В модуле есть 1 синтаксическая ошибка и 1 логическая.

Vit's code:
----------

...
for( int i = 0 ; i < XUZ ; i ++ ) {

...
if( in > 10 ) {
break ;
}
} // for
...

----------

Тогда бы давал не кусок абстактого кода, а, по крайней мере, функцию.

void f(int XUZ)
{
// ...
for( int i=0; i<XUZ; i++ ) {
// ...
if(in>10) {
break;
}
} // for
// ...
}

>> Принимается, что синтаксическая ошибка при первом просмотре не
>> обнаруживается

v> Почему? Нормально обнаруживается.

И где же она?

>> Твой вариант: Человек просматривает код 1 раз и обнаруживает 1
>> логическую ошибку

v> in > 10

v> Нет такой переменной. "in" По логике быть не должно.

>> Мой вариант: Человек запускает компилятор и обнаруживает 1
>> синтаксическую ошибку

v> in > 10

v> Исправляем "i > 10" или еще хуже того вносим в оператор for.

Это не синтаксическая ошибка, а логическая.

>> Человек просматривает код 1 раз и обнаруживает 1 логическую ошику

v> И не обнаруживает. Это была глобальная переменная n. Правильный вариант
v> n > 10

Место ошибки, btw, уже указал компилятор.

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

v> Эффективность выше в моем случае. В твоем не учитывается время
v> тестирования + время локализации + время исправления >> время
v> неавтоматизированной проверки.

А в случае неавтоматизированной проверки локализовать, исправлять и
тестировать уже не надо?

Ответ не принимается :)))

[Andrey V Khavryutchenko]

>>>>> "AVD" == Alexander V Didytch writes:

AVD> Andrey V Khavryutchenko wrote:
Alexander> знаю. Наверно из-за того что у нихпредназначение разное -- UML
Alexander> -- больше тянет на представление знаний а язык програмирования
Alexander> на реализацию задания.
>> Я больше имел в виду не язык программирования, а естественный язык.

AVD> Я не специалист в области филологии но мне кажется что естественный
AVD> язык слишком не строг.

Я тоже так считаю. Просто и естественный язык и язык моделирования
определяют какие-то базовые понятия и способы их комбинации. В этом смысле
UML -- философия. Но не больше.

[Andrey V Khavryutchenko]

>>>>> "AVD" == Alexander V Didytch writes:

AVD> P.S. У меня была одна из таких диаграм -- повесил на стене чтобы все
AVD> думали что там нарисовано нечто значимое и нифига не понимали при чём
AVD> смешно было наблюдать за людьми которые там пытались чего-то понять.

AVD> P.P.S. Через месяц за мной стало тоже интересно наблюдать.

И что, ты начал находить Великий Философский Смысл на ней? :)

У босса висит на стенке диаграмма, склееная из 6ти (или 8ми?) листов A4 (не
в UML! ;) Все никак не спрошу, что бы это значило :)

[vrud...@onestone.de]

In article <350D004C...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> > Fort, Lisp ...
> > Тот же C++ - саморассширившийся C. Еще недавно все компиляторы строили
> > сначала сишный код, а потом его компилировали.

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

Пролог можно написать на Форте. На С можно написать ОС. ;-)

> > > что у них предназначение разное -- UML -- больше тянет на представление
> > > знаний а язык програмирования на реализацию задания.
> >
> > Пролог.
>
> Хм. В пректировании нигде не встречал необходимость пользоваться "Откатом".

Неужели все проекты шли так, как решено с первого раза и ни разу не
приходилось возвращаться к альтернативному пути после неудачи?

> > Лучше. По крайней мере двойная стрелка воспринимается гораздо лучше, чем
> > "0...n". Я уже не говорю о "1,2,5-10,12,36" которые лучше на диаграмме не
> > показывать.
>
> А двойная стрелочка с разными типами штриховки в начале, середине и конце ?

Это надо уже смотреть на опыте. Думаю, что тоже лучше.

> > > Мне кажется мы путаем стадию анализа и проектирования.
> >
> > И в чем же именно? :-)
>
> Мне кажется для Вас это один сплошной процесс, для меня он "многоступечатый"

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

> > Ага. Вот жду кто же научится вместо прямых линий кривые рисовать (а то при
> > большом количестве классов в их мешанине не разобраться) и черно-белые
> > квадраты или с круглыми углами или с хорошо различимыми признаками делать.
>
> Для этого необходимо пользоваться Refinement и не generalization и разбивать
> системуна подсистемы (Packages) а не сливать всё в кучу. (Простите если
> очень резко сказано)

В теории это совершенно верно. Но домен в 20 классов уже плохо воспринимается.
А спокойно может быть и 30 и 40.

> > А про NT так и пишут, что это защищенная ОС, пригодная для того, чтобы на
> > ней работали службы Интернет.
> >
>
> Только иногда на Microsoft достучаться нельзя.

А это Вы зря. Когда к одному из мелкомягких серверов через дыру в firewall
можно было достучаться телнетом, многие радостно спешили воспользоваться этой
возможностью, чтобы прочитать сообщение о том, что они зашли на UNIX System 5.

> Sincerely, Alexander

[vrud...@onestone.de]

In article <350CFCB8...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> > Для того, чтобы достичь понимания, надо согласовать понятия. А

> > "универсальный"
> > язык ухудшает восприятие специфики выразительных средств. Если хотите
> > понимать

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

"Только тебя нам и не хватало!" Самое печальное, что такая ситуация
встречается давольно часто.

> Например на украинском слово "Бовдур" определяет нечто типа дурака а не
> умника. А степень
> выразительности можно выяснить потом а не удивляться фразе. Я умный
> аблсолютный идиот.

> Что и происходит между UML и S-M.

Так что же происходит между UML и S-M?

[vrud...@onestone.de]

In article <350D06BF...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> P.S. А как на Ваш взгляд можно установить "доверительные" отношения между
> программистом и его
> начальником ? У них только одна вещь общая -- вовремя здать систему.

Если это единственная вещь, которая у них общая, то никак. ;-)

[Alex V.]

> > Мы в GRS-е сдавали код после первичного семантического контроля
> > способом компиляции. Далее шла инспекция, контроль стиля. Тестирование
было
> > после интеграции, но помодульно, стеклянным ящиком.
>

Народ, если у вас там компилятор семантику контролировал, то зачем вы там
вообще существовали? Если он [компилятор] такой мудрый был, что логические
ошибки устранял,
то чем вы там занимались? Синтаксис проверяли? :) Настороили б компилер,
чтоб
он вам все сам писал, проверял да выпускал (с хелпом), и жили...

Alex V.

[George Seriakov]

Привет!

On 16 Mar 1998 10:05:54 +0200, in relcom.comp.software-eng Andrey V
Khavryutchenko <akh...@compchem.kiev.ua> wrote:

> GS> Опыт. Козлинский нас в GRS-е так и менеджерил. Самым кайфовым
> GS> моментом там было, когда он мне выдал свою старую методику
> GS> трансформационного анализа, и я по ней преобразовал потоковые
> GS> диаграммы системы в структурную схему. Я не так давно слышал

>George, можешь подробнее описать эту методику? Или дать url?

Трансформация описана в книжке Прессмана, сам видел. То, что давал
Козлинский, на УРЛах не лежит, и нигде я у буржуев такого не видел. Если
Козлинский разрешит (kal...@dol.ru), я напрягусь, и отреферирую соответсвующий
текст. ИМХО это полезно и в смысле закрепления приоритета на методику.

> GS> В системе есть два аттрактора. Один - программирование ad hoc, второй -

>Как ты считаешь, в каких координатах удобнее всего определять области
>притяжения одного и второго аттрактора? Какие они?

СММ не про это?

---
George Seriakov (seri...@aha.ru)

[George Seriakov]

Привет!

On 16 Mar 1998 17:43:59 GMT, in relcom.comp.software-eng "Alex V."
<vih...@usa.net> wrote:

>> > Мы в GRS-е сдавали код после первичного семантического контроля
>> > способом компиляции.

>Народ, если у вас там компилятор семантику контролировал, то зачем вы там

Уел. Конечно, имелся в виду контроль был синтаксический.

>Alex V.

---
George Seriakov (seri...@aha.ru)

[Andrey V Khavryutchenko]

>>>>> "v" == vrudowit writes:

v> In article <350D004C...@usa.net>, "Alexander V.Didytch"
v> <unknown....@usa.net> wrote:

>> > Лучше. По крайней мере двойная стрелка воспринимается гораздо лучше,
>> чем > "0...n". Я уже не говорю о "1,2,5-10,12,36" которые лучше на
>> диаграмме не > показывать.
>>
>> А двойная стрелочка с разными типами штриховки в начале, середине и
>> конце ?

v> Это надо уже смотреть на опыте. Думаю, что тоже лучше.

Одинаково для 0..1, 0..*. Вариант UML лучше для 1,2,5-10,12,36.

>> > Ага. Вот жду кто же научится вместо прямых линий кривые рисовать (а
>> то при > большом количестве классов в их мешанине не разобраться) и
>> черно-белые > квадраты или с круглыми углами или с хорошо различимыми
>> признаками делать.
>>
>> Для этого необходимо пользоваться Refinement и не generalization и
>> разбивать системуна подсистемы (Packages) а не сливать всё в
>> кучу. (Простите если очень резко сказано)

v> В теории это совершенно верно. Но домен в 20 классов уже плохо
v> воспринимается. А спокойно может быть и 30 и 40.

А при чем здесь это вообще?

Диаграмма захламлена? Структурируй ее, разбей на несколько диаграмм.

[vrud...@onestone.de]

In article <350D01F5...@usa.net>,
"Alexander V.Didytch" <unknown....@usa.net> wrote:

> Интересно как бы выглядели Ваши диаграмы если бы вы их вырисовывали в
> интонациях пользователей системы.

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

Если говорить точнее, то сложность в том, что UML не позволяет легко сделать
проекцию модели системы на модель пользователя. У него немного другие цели.

> > То, что понравится моему начальнику, появится у меня на рабочем столе в

> > качестве стандарта.
>
> И мною не одобряемое ?

"Если ты хочешь делать то, что тебе нравится - создавай свою фирму" (С) Один
Директор

> > > А где ты видел, чтобы _базовые_ понятия какой-либо системы определялись
> > > не через себя?
> >
> > Язык программирования С.
>
> Можно ли пополнее ?

Как определяется указатель?

> > На языке надо учиться _думать_. У нас преподавательница английского так и
> > говорила:

> > "Пока вы не научитесь думать на английском, у вас с языком будут проблемы"
> >
>
> Но ведь надо с чего-то начинать и делать ошибки ? Или алфавит учится за 1
> секунду?

Вот мы и подошли к сути вопроса. Большинство языков складывалось как результат
опыта работы, UML - создан искусственно людьми, специализирующимися на
обучении и популяризации ООП. Для целей обучения он и годиться больше всего.

Многие особенности реальной работы он учитывает плохо. В "лучшие практики
применения" вошел опыт M$, но не вошел опыт тех компаний, которые реально
успешно применяют OOP.

> Sincerely, Alexander

>
> > PS.: "Да здравствует UML, новояз информатики!"
>

> Урра! Все на субботник по UML ?. :)

UML стал таким же маркетинговым фактором, как ISO 9000 и CMM. У меня прияетель
сдает по нему экзамен. Кстати в России еще не появились объявления о работе,
где UML требуется знать?