2 папа Карло: \\r
...Это нормально. Их не переубедить. Трудно убедить другого человека когда аксиоматическая база разная. \\r
\\r
Ладно аксиоматическая база или система другая (даже ее можно заменить!), или диалект другой (ему тоже можно обучить), но вот действительно не переубедить, если человек туп , т.е не обучаем или уперт , т.е понятие эффективности для него просто неприемлимо по той или иной причине (лень, боязнь, принципиальность ради принципа). Тут даже медицина бессильна потому что мозги и совесть она пока пересаживать не умеет :о(\\r
\\r
Просто надо иметь соответствующий опыт чтобы осознать, надо иметь опят чтобы пытаттся понять других людей, то что они хотят сказать. \\r
\\r
Согласен, но какой мне, например, нужен опыт? Я часто работаю с людьми при общении с к-рыми у неопытного (в таком общении) и образованного человека в мозгу сразу возникает вопрос: "этот человек вообще хотя бы среднюю школу оканчивал?" Но здесь-то ведь собрались не заказчики и не пользователи! Здесь как никак люди с институтскими образованиями, к-рые считают себя гибкими в смысле освоения знаний ИТ-специалистами. Опыт: у них раздутое самомнение о собственном интеллекте или рационализме и этот т.н интеллект очень узкого применения (например, только написание программ). И как только попадается несложная проблема не из их привычной профессиональной сферы их узкоспециализированный интеллект и опыт уже непригодны\\r
\\r
Поэтому я положил на объяснение и пошел с тем народом пиво пить.... потом показал пару примеров почему не эффиктивно.... они почесали репу и сказали что об этом даже не задумывались..... Короче все всё делают по разному....... :) \\r
\\r
Это один из способов и не очень плохих, кстати. Я сам в начале карьеры так и делал, подготавливая людей во всех звеньях организации, к-рые могут хоть как-то повлиять на проект. Сейчас мне уже просто лень гонять пивко и рассказывать даже неглупым спецам про почти очевидные вещи. Потому что неизвестно сколько это времени может занять и 100% гарантии нет, что поймут и это сработает, а не согласятся и все равно будут делать по своему . У нас как правило метод "дачи по шапке" сверху. Т.е ведется информационная и моральная подготовка руководства заказчика, что эффективнее и перспективнее именно так, а ни эдак. Такое руководство полностью проникшись рационализмом и доверием - надежный гарант благоприятстования проводимым работам\\r
\\r
может вернуться... как никак проект начинается с распития бутылки коньяка, а коньяк я люблю :) \\r
\\r
К такому способу начинания проектов в Канаде или к чему? Хмм, если к способу, то не советую. Пусть уж лучше все по-деловому строго с пониманием взаимных прав и обязанностей, а то панибратство с заказчиком или еще хуже с пользователями порой играет против исполнителя. А конъячок можно и с коллегами или друзьями распить :о)\\r
\\r
2 Jinn: \\r
...Использовать для их повторной генерации CASE, с моей кочки зрения, так же неразумно как и тебе кажется неразумным использовать CASE для построения диаграмм. А вот то, что касается нестандартных ... Машина лишена абстрактного мышления, она не может его выдать. \\r
\\r
Ну и что, что повторная. Ты хочешь сказать, что ты ту же БД с первой генерации сразу в бой что ли пускаешь? Небось точно также как все нормальные разработчики отлаживаешь свои приложения/БД по нескольку раз. Далее: я не понял, а причем здесь нестандартные решения и использование CASE-средств? А это причем здесь: "Машина лишена абстрактного мышления..." - ты либо уже разговариваешь сам с собой либо ты спутал "навороченное" ПО типа ERP или прочего планирования с элементами искусственного интеллекта (ИИ) для принятия решений с CASE-средствами. Что ты хочешь сказать этим, что даже в случаях с использованием ИИ последнее решение всегда за человеком? Это ежу понятно. Тебе же "папо Карло" уже сказал, что CASE-средства только автоматизируют и ускоряют процессы анализа/проектирования. Не более того, никого из участников проекта они не заменят кроме других менее эффективных средств производства вроде твоих любимых бумага+карандаш\\r
\\r
В проектировании, на самом деле, нового выдумывать приходится мало - все уже сделано. Но собрать из готового - нужна голова, а не программное средство. Еще желателен опыт, причем не только разработок но и обыкновенный, житейский. \\r
\\r
А что ты все уводишь разговор в сторону головы? Никто здесь и не говорил, что CASE-средства заменяют голову. Моя голова мне дороже и важнее, чем любые CASE. Завтра они будут другими или вообще исчезнут, а голова и мои способности останутся при мне, разовьются и еще лучше - опыт прибавится. Ты опять не привел никаких аргументов против CASE-средств. Топчешься на месте :о}\\r
\\r
Ну а про архаичность средств ... Жил один известный академик, гениальный конструктор. Так он не пользовался таблицей логарифмом в собственных расчетах. И не по причине знания этих таблиц наизусть, а по причине умения их быстро вычислять. \\r
\\r
И что? Ты намекаешь на то, что ты тот самый академик, но только в проектировании в ИТ что ли и тебе калькуляйтер с логарифмами, т.е CASE-средства не нужны потому что ты все в уме проектируешь, а на бумаге только отображаешь готовую структуру? Отлично, но мы здесь говорим не про ИТ-"академиков", а про людей с обычными мозговыми способностями\\r
\\r
А про наждачку ты зря, при умелом ее применении задница будет целой и чистой :) Я же говорю - надо уметь пользоваться ;) \\r
\\r
Только тереть придется почти не касаясь кожи, бысто очищая и постепенно уменьшая при этом калибр зерна наждачки. Интересно, сколько людей так умеют делать без спецсредств и продолжительных тренировок? Не проще ли перейти на бумагу\\r
\\r
2 vic123: \\r
Насчет Бизнес Процессов. Я не совсем приемлю западную терминологию, где-то меня это коробит. \\r
\\r
Меня тоже! Я вообще как бы русофил, но в российской ИТ-индустрии уже традиционно сложилась своя даже не западная, а прозападная терминология. Можно конечно пытаться ее переделать и переть против этой системы, но стоит ли?\\r
\\r
Хоть убей, не вижу я БИЗНЕС-ПРОЦЕССА в автоматизации очистных сооружений. Процессы вижу, бизнеса нет. Лучше уж гнусный слэнг. \\r
\\r
Правильно, из одной крайности в другую! Обзови деятельность по очистке городских канализационных стоков бизнесом (относительно новое, но очень емкое и универсальное слово в русском языке, даже более универсальное, чем производство , например) и уже появятся бизнес-процессы. Почему? Потому что а) модно (да, приставка "бизнес" уже давно действует магически на нешибко просвященные руководящие мозги), б) понятно, что это за процессы. Да, именно процессы имеющие отношение к бизнесу , т.е производственные процессы, а не пищеварительные процессы в организме директора очистных сооружений\\r
\\r
Теперь о моделировании. Помнится меня учили, что есть такие науки предназначенные для моделирования процессов, Система Массового Обслуживания (СМО) с языком программирования GPSS, АСУ как наука. \\r
Там действительно моделируются процессы. \\r
\\r
Да, но только МСО или АСУ это, конечно, не науки, а пожалуй разделы или научные направления. Наука - это все-таки наука (например, физика), а не система уравнений Максвелла. И потом, что значит "там действительно моделируются". Вообще моделирование процессов в частности как инженерно-прикладное направление и область их применения ограничена только возможностями восприятия человека и объектами, к-рые она может описывать. Даже школьник может их моделировать, если ему объяснить нотацию (как) и семантику (для чего) и даже его школьника модели будут полноценными, если они выполнены по правилам и, например, с достаточной точностью\\r
\\r
...не более, чем некий инструментарий автоматизирующий рутину построения БЛОК-СХЕМЫ (помните такое понятие), но не создающий модель предприятия с его процессами, оценивающий эти процессы и наконец оптимизирующий эти процессы. \\r
\\r
А кто здесь, говорил, что CASE-средства и методологии анализа/проектирования сами по себе за людей создают модели? Я что-то не припоминаю. Конечно понятно, что еще нужны и бизнес-аналитики , т.е авторы этих моделей "AS-IS" или "TO-BE", а также еще и эксперты предметной области или прочие консультанты, к-рые эти модели построенные аналитиками будут верифицировать\\r
\\r
2 папа Карло, Jinn, Yossarian и Varivan: \\r
Господа, все это уже обсуждлось ровно полгода назад! Почитать антагонистический кутеж в исполнении еще незарегистрированных Yossarian, меня, а также tygra и других участников вы можете в Перспективы свободных художников в Москве (стр.2-4). Там все и про Индию, и про офшоры, про процессы производства ПО на западный манер, про кодеров с проектировщиками и т.д и т.п, Стоит ли повторять уже сказанное, а? Может что-нибудь новое, т.е старое, но еще необсужденное на SQL.RU обсудим? Например, менеджмент в ИТ-проектах и прочие управленческие "хреновины" чтобы было понятно широкой аудитории :о)

2 Yossarian:
Сказать мало. Надо еще процесс разработать, адаптировать под наши
российские реалии, перевести хотя бы... Полного и точного перевода
документов RUP на русский до сих пор НЕТ в свободном доступе. Куда всякие
Интерфейсы и Аргуссофты смотрят, я не знаю.

Во-первых, зачем переводить RUP вообще? Перевод даже очень хороший от ИТ-спеца, к-рый знаток темы и тот часто страдает неточностями. Кстати, читали: Using Structured Tools in Object-Oriented Development (by Prof. Efim Oykhman, Prof. Yurij Novozhenov) ? Зацените, очень короткий "труд" конца XX-го века от тов.Ойхмана et al. Они в Аргусе еще в 1998 начали "внедрять" RUP и до сих пор внедряют :о)

2 Yossarian: \r
С практической точки зрения - чтобы можно было документировать процесс \r
разработки для отечественного заказчика на русском языке. \r
\r
Процесс произовдства ПО и так документируется исполнителем для себя. А для заказчика не процесс, а артефакты-документы (описания UC, ТЗ, ТП и т.д), т.е то, что ему интересно почитать. Процесс ему наврядли интересен. Вы думаете, что кто-то из заказчиков читал ГОСТ ИСО-12207? Не думаю, хотя он на русском языке. На англоязычном Западе тот же RUP из заказчиков также никто не читает скорее всего и зачем его вообще читать? Для знакомства с процессом исполнителя, так он все равно отличается от RUP. Авторитет или реноме исполнителя, его прозрачность вот что пожалуй гарантирует эффективность его процесса и то, что ее можно оценить, если вы имели в виду эффективность. Читают же скорее опять же ТЗ, ТП и т.д, а они и так на русском языке. Если же заказчик пожелает разобраться в процессе исполнителя чтобы, например, сравнить его с типовыми только своими силам, то эта задача ему не по плечу. Без консультантов ему не обойтись. Профессиональным консультантам перевод RUP не нужен\r
\r
С теоретической- чтобы формировалась терминология, прогрессировало сознание разработчика \r
в правильную сторону. \r
\r
Возможно, но сомневаюсь. MSDN кажется не переведена на русский язык, однако средства разработки и продукты Майрософт используют не меньше. Говорят, что тот же руссифицированный Линукс от IP-labs или других российских контор имеет полностью руссифицированный интерфейс (сообщения, шел), а также полностью русский ман по системе (Иксы, шел, сетевые сервисы, администрировани и т.д и т.п) и стандартным средствам разработки, входящим в Линукс. То же касается и Оракла, у него есть русская документация, а вот русский BOL для MSSQL я не видел. Однако посмотрите как MS захватывает рынок. Для пользователя пожалуй сначала важнее характеристики средства разработки/продукта(!!), а уже потом документации по нему. Пример может быть не совсем корректный, но все же есть аналогия?\r
Далее: перевод или лучше сказать "перевод"? Посмотрите сколько книжек выпущено по ООАП, UML, RUP/ICONIX и смежным технологиям. Десятки. Я думаю вы уже оценили художественно-ориентированность перевода. Вот небольшой литературно-статейный анализ:\r
\r
* use case -> прецедент - %%% (Три амигос, "Унифицированный процесс\r
разработки.."; Ларман, "UML и шаблоны проектирования" и др.книжки от Addison-Wesley изд.\r
в "Вильямс"е и ДМК; официальный Интерфейс, большинство статей Инета),\r
вариант использования - %% (Фаулер, Скотт "UML Distilled" от Вендрова, книжки Вендрова;\r
серьезные статьи по ООАП), способ использования - %...\r
Лично я "за": "вариант использования" или "ВИ" (это даже короче, чем "прецедент").\r
Один матерый аналитик мне даже доказал почему это вариант самый корректный.\r
\r
* actor -> актант ! - % (Три амигос, "Унифицированный процесс разработки.."),\r
роль и исполнитель - %%% (книги от Addison-Wesley изд. в "Вильямс"е,\r
и ДМК; Интерфейс), действующее лицо - %% (Фаулер, Скотт "UML Distilled" от Вендрова и др. его книжки),\r
субъект , исполнитель - %% (Мацяшек "Анализ требований и проектирование..";\r
Заман, Амриш "..J2EE и UML" изд. в "Вильямс"е), актер - % (Ойхман, другие статьи),\r
пользователь - %...\r
Лично я "за": актера (просто удобнее говорить, например, "актер Бухгалтер делает то-то..") и роль\r
(корректный по смыслу вариант, но! может вызвать путаницу с ролями, например, ассоциаций)\r
\r
* analysis diagrams (RUP) / robustness diagrams (ICONIX) -> диаграммы (классов) анализа (Три амигос, "Унифицированный процесс разработки.."),\r
диаграммы устойчивости (Коналлен, "Разработка Web-приложений..." и др.книжки\r
от Addison-Wesley изд. в "Вильямс"), диаграммы пригодности (книги от ДМК)\r
Лично я "за": диаграммы анализа\r
\r
и т.д.... где %%% - степень частота использования (%%% - больше, % - меньше). Правда, "здорово"? Книги, выпущенные в одном издательстве содержат различные переводы одного и того же английского термина. Значит, а теперь еще нужно также "перевести" и RUP чтобы еще больше зашорить терминологическую базу? К тому же это стоит незначительных, но все же денег. Сделать это могут только энтузиасты или проплаченные гуру. IMHO корректную руссифицированную терминологию должно насаждать представительство Rational\r
или, например, тот же Интерфейс. Тем более, что есть очень простые методы. Однако им по барабану.\r
(Если есть желание основательно с обоснованиями пообсуждать терминологию UML/ООАП/RUP, то лучше в Обсуждение и Вопросы по ОБЪЕКТНО-ОРИЕНТИРОВАННЫМ МЕТОДАМ (ООАП / OOAD) и UML)\r
\r
Чтобы не было "гуру" RUP, а была просто общеизвестная \r
методология. Надо - применил. Не надо - не применил. \r
\r
Перевод к этому не имеет никакого отношения. Будем объективны? Я ответил выше по аналогии примером с MSDN и BOL. И потом ведь RUP и так общеизвестная методология в ИТ-среде. Я бы сказал, что уже более известная, чем более "древние" структурные методологии вроде SADT или SASD. А тому, кто клепает софт по-старинке перевод RUP не поможет. Далее: предвидя возможный вопрос "а как же те у кого плохо с английским?". С таких взятки гладки. Разработчик с плохим английским как "белая ворона", он не сможет поддерживать свой уровень, если ему вообще будет нужно его поддерживать с помощью импортной документации потому что ему надо будет каждую англоязычную документацию или статью переводить на русский, все англоязычные форумы, рассылки, новости для него будут бесполезны. Да, можно обойтись и российскими, но мне помнится как в бытность моей работы программистом БД мне на http://www.mailgate.org/comp/comp.databases.ms-sqlserver/index.html]www.mailgate.org[/ulr] или на dbforums.com очень часто давали гораздо более грамотный и быстрый ответ, чем на российских SQL.RU или Relib.com \r
\r
Спасибо, прочел, любопытно.... \r
\r
Да, может быть, но только я это вовсе не к структурным средствам, а к тому что такие якобы "монстры" отечественной ИТ-индустрии на поверку оказываются фуфлом с их якобы "реально" работающими "RUP-процессами" и прочими ИСО9001. Не следует уповать на всякие Аргусы и Интерфейсы в их якобы влиянии на ИТ-культуру. У них самих уровень менеджемента и использования CM/QMS как у полуподвальной программистской конторы, но вот проекты они ловят не слабые, беря простым понтом и работая при этом по-старинке. В Интерфейсе точно ничего не изменилось (информация изнутри), по анализу содержимого сайта Аргуса - тоже самое. Руководство все то же и генеральная линия тоже :о}