Одна диаграмма заменяет сотню слов.\r
Тысяча слов заменяет сто диаграмм.\r
\r
\r
2 Varan: \r
Репликант, так вы - женщина? \r
\r
Если это не шутейный вопрос, то скажу: цитата цитатой, но в моих постах вроде неоднократно встречались глаголы в мужском роде (например, "согласен, не торопился"). В общем спасибо Cat2, т.к он меня авторитетно подтвердил как мужика. Однако, например, не знаю почему он уверен, что в реальной жизни я не женщина ведь "@#%$ мозги" в форуме может и женщина... :о)\r
\r
\r
2 vdimas: \r
Мой основной недостаток - эта наивная уверенность, что если речь идет об очевидных вещах, то собеседник обязательно сам додумает детали, которые я опускаю. \r
\r
Да уж, ты предлагаешь этому собеседнику додумывать, а додумывать, действительно, нужно, т.к вещи эти очевидные для тебя и, возможно, еще для кого-то, но не для всех. По поводу "очевидности": это отчасти напоминает ситуацию с описанием вариантов использования (ВИ), когда программисты хором советуют аналитику: "Ну, зачем описывать эти простые ВИ - тут и так все ясно", а спустя месяц начинается путаница (ведь все понимают простые и очевидные вещи по-своему) и вопросы к пользователям (в обход аналитика) по поводу этих "всем понятных" прецедентов :о)\r
\r
Разумеется, никто шизофренией при разработке не страдает, и не закладывает доп. возможности удовольствия ради. Мы все разработчики с немалым опытом. \r
\r
Закладывать доп.возможности или плодить ненужные диаграммы можно, например, не ради удовольствия, а ради ИМБУРДы (ИМитация БУРной Деятельности)...\r
\r
Во время разработки компонента, который является потенциальным претендентом на повторное использование, применяется некоторое другое видение этого компонента. Видение вне конкретного разрабатываемого продукта. В этом случае, требования к функциональному наполнению компонента складываются не только (и не столько) от роли, отведенной ему в конкретном месте применения, сколько из общих знаний/информации, накопленных о применении компонентов подобного рода. Мы же не в лесу живем... \r
\r
Совершенно согласен с твоим видением компонента, но ты, кажется, говорил о компоненте в конкретном продукте: "..Обычно это означает дополнительные трудозатраты по реализации дополнительной функциональности сверх предписанной в рамках конкретной системы.., " , т.е у тебя компонент не проектируется вне приложений , когда ты как проектировщик понял, что тебе необходим некий компонент для приложений определенного типа, а при создании приложения и для того, чтобы обеспечить функциональность "про запас" этого приложенияю Или нет?\r
\r
Репликант, ты сильно заблуждаешься, примеряя свой опыт на других разработчиков/программистов.\r
... \r
\r
Отнюдь! Не собираюсь я применять свой опыт, не зная досконально , что это был за проект(ы) и коллектив у тебя. Допустим, что это был заказчик или начальник ИТ-службы заказчика, имевший положительный опыт и твердую убежденность, что объектно-структурный подход или XP всегда хороши и у них нет недостатков - ему и не нужен ООАП, он его не понимает, он ему претит. Можно лишь сравнивать простые и понятные достоинства методов, например, в отрыве от конкретного проекта - просто взять некого программиста со знанием ER/UML нотаций и представить, что ему дается мн-во документов А и мн-во документов Б, а затем объективно сравнить, что ему не очень поможет и что, действительно, поможет. Я так и не услышал от тебя, что ты считаешь "самой-пресамой наилучшей документацией"\r
\r
.. Я работал бок-о-бок с коллегами из штатов, которые очень неплохо разбирались во всем этом, которые могли долго и красиво на эти темы говорить, и которые имели сертификаты по всему этому направлению (ООАП, UML)... \r
И тем более меня разочаровывала крайне низкая эффективность их труда (реальный "выхлоп"). \r
\r
А как ты оценивал эффективность их труда? Тем более если это явный "выхлоп", то встает законный вопрос: что делал главный/старший программист, а также руководитель проекта, к-рые попустительствовали этимм "выхлопам"?\r
\r
Знание нотации UML (что там, собственно, знать) не придает автоматически ума разработчику. Знания о том, как правильно делать ООА не добавит аналитического мышления в мозги индивидуума, сдавшего на сертификат по ООАП. \r
\r
Действительно, никому не нужен экзамен, проверяющий лишь знание нотации UML. Экзамен от ICE (IBM\'s Certification Exam) UML 486 или Brainbench по UML не только включает вопросы типа "диаграмма - какой код/сценарий", но также и вопросы по ООАП, текстовым ВИ и по ООП: \r
\r
This certification is not a knowledge certification but a certification that tests\r
the experience of working on the OOAD principles. There are lots of books available\r
in the market to teach you all the principles but that alone will not be enough\r
to prepare for this certification. OOAD Exam has many scenario based questions,\r
where in you will be provided with a particular design and you will be asked\r
questions based on their practical usage. ....\r
\r
Спасибо также, что ты напомнил, что картонка не заменит мозги и навыки, а то я уж намылился платить бабки и идти сдавать этот ООАП... :о))\r
\r
.. Use case нам заменяли словесные описания сценариев (которые, на мой взгляд, гораздо информативнее, и требуют меньше бумаги, отдаю словесному описание предпочтение до сих пор, ибо диаграммы use case - это скорее для клиентов и менеджеров). .. \r
\r
Как уже сказал funikovyuri - ВИ это есть описание прежде всего , но и диаграммы ВИ не "скорее для клиентов и менеджеров" (вот еще.. будет аналитик о них заботиться), т.к они в первую очередь для разработчиков (аналитиков, проектировщиков, программистов и т.д). Как ты наглядно покажешь ассоциации в пакете, где несколько ролей и несколько десятков ВИ? Только диаграммами ВИ.\r
И почему ты считаешь, что диаграммы требуют меньше бумаги? По опыту скажу, что если распечатать все диаграммы ВИ (включая диаграммы пакетов, иерархию актеров и т.д), например, для довольно простой и всем понятной программы типа "ФРИГАТ-Видеопрокат" (автоматизация всех операций видеопроката, включая фин.учет и ТМЦ, отчетность), то это где-то 20-30 страниц, а если распечатать полную (у Коберна это "fully dressed", т.е - это полное текстовое описание системы и к ней нужны только дополнительные системные требования (supplementary SRS) на 20 страниц) спецификацию всех ВИ (порядка 60 ВИ), то это 130-150 страниц A4 (Arial, 10pt, 1,5ln). Т.е "бумажная площадь" всех диаграмм не идет ни в какое сравнение с текстом\r
\r
.. Просто системный подход + case-средства это и есть RUP в его сегодняшнем виде... (ничто не ново под луной) \r
\r
Так я же и говорю, что скоро уже будем справлять 30-летие ООАП, 40-летие ВИ и 50-летие ООП! :о)\r
\r
когда я вижу их десятки и десятки, описывающих всякую ерунду - мне становиться стыдно за коллег \r
(расписанные на листах пояснения к вычислению результата выражения 2х2=4) \r
\r
Искренне сочувствую, что тебе пришлось смотреть на эту ерунду (сам такое дело видел), а главное не ясно почему за эту ерунду еще кто-то платит. А что хоть за ерунда описывалась?

2 Циничный Кот:
Самое интересное на это тоже есть народная пословица - 3.14#$%деть - не камушки ворочать.

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

.. В данное время наблюдаю абсолютно аналогичную ситуацию - чем более товарисч обвешан корочками, тем менее он врубается в происходящее.

Видимо, это вам просто попались такие "специалисты" с корочками (сертификатами?). Настоящего специалиста определяет не сертификат, а его реальные знания и навыки

2 Циничный Кот:
Именно. Реальные - а не набранные из различных книжонок сомнительного качества. И именно по этому вы к ним (специалистам) не относитесь... К сожалению...

Во-первых, к специалистам в чем? Если специалистам по болтовне, наездам и флейму каким являетесь вы, то - да, не отношусь. Эту вашу "квалификацию" я вам не раз уже доказывал. Да вы и сами признавались, что вы любитель этих дел...
Во-вторых, что значит "реальные знания"? Если это знания проверенные опытом, то я вам тоже не раз говорил, что та же официальная теория качества (с к-рой вы безуспешно пытаетесь спорить) успешно применяется в реальных условиях не только мной, бедным Репликантом в далекой России, а в тысячах ИТ-компаний по всему миру - это общеизвестный факт, с к-рым вы тоже пытаетесь спорить. У вас врожденная упрямость что ли?
В-третьих, я вам свою т.з аргументировал не только ссылясь на авторитетные (а не на сомнительные!) книги, а подробно объяснял все "на пальцах" и на конкретных примерах из жизни, т.е никакой black magic. Видимо, вам нужен сам "процесс", когда ваши оппоненты объсняют вам очевидные вещи по нескольку раз, а вы прикидываетесь (а, возможно, и не прикидываетесь) форумным шутом и дураком. Ради чего, ради дешевого удовольствия, как вы сами мне в этом признались?

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

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

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

2 Циничный Кот: \r
Не прошло и полгода, как у Репликанта сработало зажигание... Лучше поздно, чем никогда... \r
\r
О чем это вы, херр болтун?\r
\r
Кстати, просветите нас, необразованных деревенщин, что такое за зверь загадочный "официальная теория качества"???... \r
\r
Кого это "нас"? Если вы имеете в виду себя, то в топике Рассуждения о качестве в дурацкую погоду (стр.3-5) я уже рассказал вам более, чем достаточно о качестве\r
\r
И заодно, в чем ее официальность выражается - она комитетом по стандартизации каким-то принята, чи как???... Уж-жасно любопытно... \r
\r
Во-первых, ваш вопрос риторический также как и ваш спор ради спора, т.е опять это лишь ваша клоунада. Вот чуть более "крутая" аналогия вашего высказывания: "экономическая теория является неофициальной (и ва-а-апще это - бред сивой кобылы), т.к она - плод воспаленной фантазии узкой группы лиц и нет стандарта, описывающего ее.".\r
Во-вторых, вы заставляете меня повторяться, т.к я уже подробно отвечал вам на этот вопрос. В этом посте приведены определения качества из ИСО9000 (серия международных стандартов, являющихся национальными в десятках стран мира, например, Росии - ГОСТ ИСО 900х) и TQM (де-факто стандарт, набирающий все большую популярность). Про тот же ИСО9000 можно сказать, что он описывает практическое применение теории управления качеством по Демингу - это часть теории качества. То же самое и с TQM, использующей часть теории, но в виде других принципов Ишикавы, Джурана, Шиба и других\r
\r
Какие-то у вас пальцы... Растопыренные... \r
\r
О чем это вы?\r
\r
.. Мне объяснять на пальцах не надо, мне вполне достаточно ссылочки на правильную литературу. Желательно соответствующую каким-нибудь стандартам, а не только воспаленной фантазии автора. Есть у вас такое, нет???... Впрочем, я уже об этом чуть выше спросил... \r
\r
Про лит-ру я вам уже тоже объяснял. В книге от трех амигос из ЕА, к-рую вы цитировали приведено определение качества, к-рое приводил я, т.е официальное . Все, что там ниже - как раз и есть плод воспаленной фантазии авторов, т.к А) я вам это уже доказывал и вы никаких вразумительных аргументов не смогли привести, а лишь уходили от ответов на вопросы, Б) даже судя по приведенной вами цитате книга, очевидно, рассчитана на самую широкую аудиторию разработчиков (это - голая правда безо всякой претензии: отсюда и требуемый уровень подготовки - самый средний ), а не на тех, кто, действительно, знаком с методологиями, понимает их достоинства и следует процессу создания ПО, где, действительно, есть деятельности анализа/получения спецификаций и тестирования -или- тех, кто, действительно, занимается обеспечением качества, а не болтовней. Птичку видно по полету, а книгу - по стилю изложения и аргументации высказываний авторов. Про стандарты см.выше

2 Циничный Кот:
О разнице в датах: 29 мар 04 - 23 апр 04. Откуда даты взялись - догадайтесь без меня...

Признайтесь, что вы хотите этим сказать или смелости не хватает? Не надо тень на плетень наводить: "о разнице в датах", "догадайтесь"... :о\

>Во-первых, ваш вопрос риторический...
Понял, вопросов больше не имею...

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

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

Книги, на к-рые я ссылался, содержат информацию, не противоречающую стандарту и сама серия ИСО 9000, ее национальные предшественники (BS, DIN и другие) появились именно на основе работ и книг Деминга и других авторов, посвященных качеству. В этом тоже и заключается официальность теории качества , изложенной в книгах, на к-рые я ссылался. С другой т.з официальность заключается в том, что эту теорию, одну и ту же, преподают в учебных заведениях и компаниях, сертифицированных национальными и международными организациями, например, ISO, BSI и т.д, а также ассоциациями, объединяющими экспертов в области качества. Ну, и с последней и самой важной т.з для всех рядовых специалистов ее официальность заключается в том, что это одна и та же теория в подавляющем большинстве изданий, посвященных качеству, с ее везде одинаковыми определениями. Поэтому, как следствие, она считается таковой и используется теми, кто профессионально занимается качеством. Вы же ведете себя как дурачок , тупо хамя и подменяя термины (официальность вами спрашивалась для теории, а не для книги), но при этом вы сами, видимо, забыли такое общеупотребительное выражение как, например, "официальная документация" и, в частности, "официальная документация (от) Microsoft". Хотя документацию Microsoft, Borland, Sun и многих других компаний никакие органы по стандартизации (если имелись в виду они) не принимали в установленном порядке. Официальной эта документация называется и считается потому, что она выпущена самой компанией или с ее согласия