2 новичек: \r
Что и BPWin никто не использует ? \r
\r
Используют. Я, например, когда строил процессные модели организаций, но вообще у BPwinа есть много недостатков (была бы IDEF0/3 реализована в PowerDesigner я бы диск с BPwin в форточку выкинул нахрен). Только вы задавайте конкретные вопросы, хотя есть Форум по продуктам "Computer Associates" . Там традиционно околачиваются знатоки данного средства и вообще профессиональные бизнес-аналитики (несмотря на то, что форум Интерфейса очень неудобный и тормозной)\r
\r
2 vic123: \r
Словоблудие все эти ваши БИЗНЕС процессы. \r
\r
Грузчкик разгрузил - Кладовщик выдал. Весь тебе процесс. \r
\r
Это не процесс и даже не его описание. Потому что не ясно, что разгрузил грузчик. Прямую кишку, "Газель" или что? И что ему выдал кладовщик после этого? Так что видимо это ваши бизнес-процессы словоблудие . Хотя вы конечно имели в виду моделирование или модели бизнес-процессов. Лучше выражаться чуть-чуть более грамотно\r
\r
2 Модник: \r
не модно ). Больше Rational Rose используют \r
\r
А кому какое дело, что у дураков в моде ширинка на болтах? (русская народная поговорка) Интересно, откуда такая статистика? Не судите только по своей организации. Структурное моделирование (IDEF0/3) и средства для них традиционные лидеры рынка и какие-то средства типа Rose (хотя я ей сам пользуюсь каждый божий день), PowerDesigner вместе с очень модным ARISом и прочими для workflow моделирования пока отдыхают поскольку все организации и предприятия имеют именно структурно-процессную природу. Попробуйте также провести простейший функционально-стоимостный анализ (ABC), используя только Rose. В BPwin, EM/Tool, A0win и т.д стоимость и cost roll-up - это встроенные возможности, естественно вытекающие из используемой ими нотации\r
\r
2 Jinn, Varivan: \r
Лучше головы пока ничего не придумано для моделирования. Все эти средства хороши, но карандаш с бумагой прекрасно их заменяют. \r
\r
Голова - это очень хорошо, но CASE средства также необходимы. Так что не следует насаждать бессмысленный консерватизм, а то можно докатиться, что задницу начнем подтирать лопухом. Попробуйте показать ваши бумажки формата А4, рисованные от руки, аудитории из 10 человек чтобы на большом экране и все блоки были ровненькие и стрелочки прямые, или попробуйте подсчитать стоимость процесса, состоящего из 50 деятельностей :о)\r
\r
А если знаешь ЧТО рисовать, то можно рисовать в чем угодно, хоть в Word. Лично я visio использую, но только после бумажки и карандаша :) \r
\r
Есть такое понятие эффективность . По-вашему можно задницу и лопухом подтирать, и все будет хорошо что ли?\r
\r
2 Жучила: \r
Вся беда с этими моделями в том, что нельзя проверить их полноту и непротиворечивость формальными методами. \r
\r
В дополнение к тому, что уже сказал "папа Карло:"\r
1. Полнота или буря в стакане. Любая модель замкнута, т.е описывает систему обязательно\r
имеющую границы . Границы предполагают интерфейсы с другими системами, к-рые также\r
должны присутствовать в модели. Для системы в состоянии с постоянными границами\r
ее модель описывает эту замкнутую систему полно с заданной точностью, т.е без\r
необходимости знаний о других системах и на основе этой модели можно делать любые\r
суждения о системе непротиворечивые данной модели\r
\r
2. Непротиворечивость или слон из мухи. Любая модель является абстракцией \r
и создается с заданной точностью . Ровно с этой же точностью она и описывает\r
систему. Как автор так заказчик этой модели знают об этом, если они адекватны\r
\r
...SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Это назначение, называемое целью модели, вытекает из формального определения модели в SADT: \r
\r
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А. \r
\r
Таким образом, целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы неявно присутствуют (подразумеваются) в процессе анализа и, следовательно, они руководят созданием модели и направляют его. Это означает, что сама модель должна будет дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. .... \r
МЕТОДОЛОГИЯ СТРУКТУРНОГО АНАЛИЗА И ПРОЕКТИРОВАНИЯ (SADT), Глава 1. Системы и модели \r
\r
2 wara: \r
А для меня этот форум и есть институт. Только более эффективный. Поскольку связан с реальной жизнью. \r
\r
Не обращайте внимания. У вас есть замечательная черта, к-рой к сожалению нет у многих разработчиков - если они что-то не понимают или не знают, то боятся в этом признаться и тем более публично задать вопрос, к-рый раскроет всем их "унизительное и позорное" незнание. Они предпочтут перерыть Интернет и еще больше запутаться и убедить себя, что все это блин ненужная хреновина , чем попросить у профессионала объяснить все в нескольких предложениях :о)\r
\r
А адресочек "правильно отрисованного бизнесс-процесса" не могли бы подкинуть? \r
\r
Какого именно, т.е из какой области ФХД? Конкретные БП (деятельность торг.компании, закупка ТМЦ, бюджетирование и т.д) можно посмотреть на [http://www.finexpert.ru/content.asp?mID=65&ID=65]FINEXPERT.RU / Модели бизнес-процессов (треб.регистрация). Вот пара статей на Интерфейсе для общего знакомства:\r
\r
"Основные методологии обследования организаций. Стандарт IDEF0" (Гынадий Верников)\r

"Использование BPwin в консалтинговых проектах" (М.Сычевский)\r

"Новый менеджмент, или зачем нужен системный анализ на основе BPwin" (С.Роман)\r
\r
Это все в нотации IDEF0/3 соответственно, диаграммы в BPwin, а это официальное описание методов IDEF0 и IDEF3 и нотации (уже дал "Папа Карло"):\r

IDEF0 - Function Моdeling Method Overwiew \r

IDEF3 - Process Description Capture Method Overwiew \r

тут остальные стандарты этоцй серии: IDEF1X, IDEF5 и т.д в PDF. \r
\r
Задавайте вопросы, с удовольствием отвечу. Тем более самому тема БА и РБП интересна (хотя совсем нет времени ею заниматься) даже с точки зрения знакомства с типовыми БП \r
\r
2 папа Карло: \r
Абсолютно во всем согласен с вами, мистер Карло, только немного уточню:\r
\r
нда.... тул? можно использовать rational..... можно в визио IDEF0 рисовать.... \r
\r
в Rational Rose врядли удастся нарисовать IDEF0 или IDEF3 потому что там настоящих прямоугольников (c прямыми углами) нет для деятельностей и еще много чего полезного из нотации IDEF. Хотя кто-то на Yahoo CASE-Tools пытался страшно (у-у-ууу!!) извращаться, вводя свои картинки для стереотипов :о)

2 vic123: \r
Ну тогда уж давайте плясать от печки. Что именно вы понимаете под термином "БИЗНЕС-ПРОЦЕСС"? \r
\r
Я с удовольствием отвечу вам на вопросы по БП и их моделированию, но прежде чем отвечать на ваш вопрос я хотел бы узнать зачем вам это нужно, а то не хочется стать жертвой возможных ваших обвинений в насаждении "словоблудия" :о)\r
\r
2 Jinn: \r
Задницу можешь подтирать хоть сторублевкой, хоть наждачной бумагой, меня это не колышет :) \r
\r
Я свою ИТ-"задницу" как раз не подтираю указанными тобой материалами, а вот ты это похоже делаешь. Это если проводить параллели в области эффективности используемы средств системного проектирования бумага+карандаш (всегда) vs CASE-средство (почти всегда) и объективно считать, что самое эффективное средство - это нормальная туалетная бумага или биде (для ИТ сотрудниц), а самое неэффективное - это наждачка и казначейские билеты. Поясню: что касается бумаги и карандаша и чашки кофе в буфете, то я ими также пользуюсь и мне тоже нравится развалившись на кожанном диване в одиночестве почертить карандашиком, но только на самом начальном этапе проектирования (основные пакеты/подсистемы и пара десятков основных сущностей), а далее моделирование только в CASE средствах поскольку этот способ намного удобнее (по вполне объективным эргономическим критериям!!) и эффективнее , т.е быстрее и результат (модели) качественнее, чем в случае средства бумага+карандаш. Ну что, будешь спорить с большей эффективностью CASE-средств при полноценном владении ими ? :о}\r
\r
А вот полностью полагаться на CASE средства я все же не советовал бы. Они не учитывают многих нюансов, опыта предыдущего проектирования, СУБД etc. Все равно потом придется все доделывать ручками, что говорит о торжестве человеческого разума над глупой железякой :) \r
\r
А кто тут говорил, что надо использовать CASE-средства в 100% всех операций или что они генерят на 100% идеальный код? Я первым брошу в него виртуальный булыжник! Но про то, что все "придется все доделывать ручками" ты погорячился. Я доделываю только 5% (тонкий "тьюнинг" деклараций) кода Rationa Rose для VB и Delphi, а для MSSQL из под PowerDesigner вообще ничего не доделывается. Если не умеешь пользоваться CASE-средством и настраивать его для кодогенерации (многие только говорят, что знают тот же PowerDesigner или ERwin, а на деле они используют их только для создания диаграмм и неполноценной генерации) или оно тебе не подходит, а у тебя еще и нет выбора , то тут тебе можно только посочувствовать. Однако не стоит винить в этом все остальные средства и вообще CASE\r
\r
И времени уходит на процесс практически одинаково в конечном итоге. \r
\r
Это только твоя точка зрения. Бумага с карандашом - это для одной диаграммы с несколькими сущностями. Могу привести простые и понятные объективные критерии из к-рых, если ты конечно не уперся рогом только из принципа, ты поймешь, что CASE-средства намного эффективнее бумаги с карандашом\r
\r
Я и сам не против изобразить в каком либо CASE средстве готовую структуру. И себя проверить и другим показать. Но проект начинается с карандаша и бумаги. \r
\r
Готовую структуру чтобы только себя проверить или другим показать? Если ты только так используешь CASE-средства, то мне тут добавить нечего по поводу такой твоей "эффективности" их использования. Это же надо такие бабки платить чтобы использовать CASE-средства только для обратного инжиниринга или отображения законченного бумажного творчества. По поводу проекта и с чего он начинается читай мой пост папе Карло\r
\r
А эффективность подтирания задницы одинакова и от лопуха и от наждачки. Просто надо уметь использовать инструмент грамотно :) \r
\r
Ваше высказывание про "эффективность подтирания" и с лопухом и наждачкой чушь. Начнем с того, что после наждачки особенно с крупным зерном ты вообще не сможешь испражняться, если переусердствуешь с подтиранием и повредишь...\r
\r
2 папа Карло: \r
хмм.... интересно. я всегда считал что любой CASE tool всего лишь отражение, "юзер интерфейс" если хотите того как человек думает. \r
\r
Если точнее, то - это модели (визуальные) или диаграммы с объектами, к-рые и образуют эти модели. CASE tool или "юзер интерфейс" ничего не отражает, он только позволяет строить и работать с этими моделями\r
\r
Но проект начинается с карандаша и бумаги. \r
\r
Проект (в широком смысле этого слова) может начинаться с чего угодно тем более для разных его участников (ролей). Вообще в России он, как правило, начинается с распития бутылки конъяка и словестных соглашениях о взаимных доброжелательных намерениях... (руководство). Для более "мелких" участников проекта (менеджеров, аналитиков, программистов и т.д) на стороне исполнителя ИТ-проект начинается с Приказа "О начале проекта автоматизации конторы X". Я конечноу понимать, чтоу у каждого программиста с раздутым самомнением свой собственный Проектъ в общем "проекте" или я чего-то не понял в вашем высказывании, мистер Карло :о)\r
\r
CASE тулзы в проектировании не панацея, а всего лишь удобный инструмент с обычно фиксированной нотацией. Они позволяют всем "рисовать" одинаково. Ибо если каждый начнет рисовать в своей нотации и приносить листочки бумаги исчерканные карандашем на митинг, то это не все "поймут". \r
\r
Правильно, но такое классическое ИТ-понятие как формальная спецификация чего-либо, используемое не как панацея, а как просто более эффективное средство обмена информацией между участниками проекта ничего не говорит некоторым отъявленным консерваторам ("Jinn") со шкуркой в "заднице" или карандашом с кучей бумаг :о}

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 как у полуподвальной программистской конторы, но вот проекты они ловят не слабые, беря простым понтом и работая при этом по-старинке. В Интерфейсе точно ничего не изменилось (информация изнутри), по анализу содержимого сайта Аргуса - тоже самое. Руководство все то же и генеральная линия тоже :о}