Сообщений в теме: 40

[Mike]

Перечитал тему. Не вижу, чем моё описание activity отличается от цитаты, которую приводил Алексей, и не виже никаких противоречий. Речь, я так понимаю, всё-таки идёт не о подходе а исключительно о терминологии (если Вы считаете, что это не так - пожалуйста, поясните в чём отличие "процессного" подхода от "деятельностно-ориентированного" :). Ну хорошо, называете вы, предположим, набор деятельностей, в которых задействованы роли тестировщика, тест-менеджера и тест-дизайнера процессом тестирования, и что от этого меняется в подходе? По-моему, ничего. Но, IMHO, удобнее работать именно с activities а не "процессами". То что вы называете процессами, как мне представляется, есть не более чем куски (ветки) Workflow.

[Viktor]

Перечитал тему. Не вижу, чем моё описание activity отличается от цитаты, которую приводил Алексей, и не виже никаких противоречий. Речь, я так понимаю, всё-таки идёт не о подходе а исключительно о терминологии (если Вы считаете, что это не так - пожалуйста, поясните в чём отличие "процессного" подхода от "деятельностно-ориентированного" :). Ну хорошо, называете вы, предположим, набор деятельностей, в которых задействованы роли тестировщика, тест-менеджера и тест-дизайнера процессом тестирования, и что от этого меняется в подходе? По-моему, ничего. Но, IMHO, удобнее работать именно с activities а не "процессами". То что вы называете процессами, как мне представляется, есть не более чем куски (ветки) Workflow.

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

[Undi]

Предположим, Вы тестируете  :)
По rup Вы никаких преобразований с программой не делаете :), просто итеративно программа с малой функциональностью становится программой с большей функциональностью :)

Т.е. в процессе тестирования программа обретает новую функциональность? :)

[Undi]

В тоже время в ней можно встретить некоторые довольно странные терминологические моменты (во всяком случае в версии 6, с которой я работаю). Например, к test planning они относят разработку не только дизайна тестов (тест-плана и пошаговой детализации), но и программирование тестов. При этом сам термин программирование они, в основном, используют в исключительно узком смысле как «ручное» кодирование с использование языка TSL, отдельно выделяя recording, хотя это также является программированием, только другим методом.

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

Подождите, Алексей, для участников поясните:
Разве process, thread, task, work, activity не синонимичны в RUPe?

Виктор, пожалуйста, можете ещё раз объяснить, что вы подразумеваете под "процессом", а так же "задачей" (task) и work (это вообще не знаю, как перевести)

То  что вы называете процессами, как мне представляется, есть не более чем куски (ветки) Workflow.

По-моему эта беседа похожа на дым: разносит ветром в абсолютно непредсказуемые направления...

Может, сделать по-другому?
Написать так:
я записываю в программе А "в поле Б ввести С, после этого нажать на кнопку Д" и называю это "процессом/задачей/тест-кейсом/простым кейсом (добавь свое).
Последовательность из действий X-Y-Z я называю тестированием/работой и т.д.

1. Можно видеть термины, которые действительно используются
2. Можно увидеть последовательность действий, выполняемую тестировщиками.
3. В результате можно выработать общую терминологию, что ранее хотел сделать Анатолий Мильнер в своей анкете.

[Viktor]

Предположим, Вы тестируете  :)
По rup Вы никаких преобразований с программой не делаете :), просто итеративно программа с малой функциональностью становится программой с большей функциональностью :)

Т.е. в процессе тестирования программа обретает новую функциональность? :)

На какие ши-ши?

[Undi]

На какие ши-ши?

К сожалению, я не всегда понимаю Ваши высказывания.

[Viktor]

На какие ши-ши?

К сожалению, я не всегда понимаю Ваши высказывания.

:(
The truth is ... (skipped) I'm tryin' real hard to be ...(skipped)
(С) Pulp Fiction

[barancev]

Не вижу, чем моё описание activity отличается от цитаты, которую приводил Алексей, и не виже никаких противоречий.

Я тоже не вижу :) По-моему всё абсолютно верно. Да, одна activity -- одна роль, на входе набор артефактов, на выходе набор артефактов, всё именно так.

Но, IMHO, удобнее работать именно с  activities а не "процессами".

Точно, удобнее. Чисто практически. Об этом и говорится, в частности, в определении discipline, данном в RUP -- строить schedule в терминах activities проще, чем в терминах процессов. Процессы трудно синхронизировать в milestones, если что-то пошло не очень гладко и один из процессов, например, отстаёт от плана, а остальные нет.

P.S. Прошу прощения за дикую русско-английскую смесь, только что "с баррикад", ещё не отошёл :)
Кстати, там, на баррикадах, С.И.Мильман в своей презентации привёл такие слова Джорджа Бокса:
"All models are wrong, but some are useful".
Если честно, знать не знаю, кто он такой этот Джордж Бокс, но я согласен с ним на все 100%.

[barancev]

И не увидите, Вы же внедрили и RUP и ИСО :)

Виктор, расскажите нам, что Вы такое видите, чего мы не видим? Интересно же :)

RUP -- это процесс, а ISO -- набор требований к процессу. Ничто не мешает сделать процесс, построенный на RUP так, чтобы он удовлетворял этим требованиям. Что Вас смущает в этом сочетании?

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

Это не RUP, это ересь какая-то! Магия и ересь :)

[Viktor]

И не увидите, Вы же внедрили и RUP и ИСО :)

Виктор, расскажите нам, что Вы такое видите, чего мы не видим? Интересно же :)

RUP -- это процесс, а ISO -- набор требований к процессу. Ничто не мешает сделать процесс, построенный на RUP так, чтобы он удовлетворял этим требованиям. Что Вас смущает в этом сочетании?

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

Это не RUP, это ересь какая-то! Магия и ересь :)

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

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

Давайте теперь и я Ваши, Алексей, слова надергаю.
RUP- процесс (в ед.числе), никто не спорит, а то что ISO - требования к процессам (многим), так там это написано, перечитайте
Вот тут намешали все понятия в кучу, хотя Вы же их разделяете
Вы говорите что discipline - это не процесс, хотя RUP говорит наоборот, правда добавляет слово "грубо", мне же это упрощение (для Вас усложнение, см. цитата про синхронизацию ниже) непонятно, зачем вообще нужно слово discipline? Вы его переводите как подпроцесс - Вам не нравится, мне нравится, никому не нравится, что это за зверь такой? Слон? За какую часть мы все держимся? Ну пусть я за хвост, так покажите мне его целиком. Вот, я немножко пощупал с Вашей стороны - действительно "грубо" похож на хвост.
И соглашаюсь с Вами хвост действительно похож на хобот, Ваша точка зрения в чем-то верна, и я понимаю что процессно-ориентированный подход, слишком дорого обходится в однодневных (имеется ввиду не один день, а просто их небольшое количество вплоть до 5 лет) проектах, в которых Вам доводилось участвововать.
А беспорядочно (прошу заметить, сначало хотел применить другое синонимичное слово)-ориентированный подход - очень даже поможет сэкономить. Удастся - хорошо, не удастся - господь с ним.

То что в RUPe идет первой строкой для Вас (вдруг) магия и ересь. Я приведу ее, а то опять передернут: Iterative Development. Для вас ересь, что тестирование - часть итеративного процесса разработки?
Магия, что в результате процесса разработки появляются программные продукты?
Может аист их приностит менеджеру проекта?

Вот Вы пишите

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

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

Они намеренно и сознательно сужают тему и выделяют деятельности по тестированию из всех остальных, пытаясь рассматривать их хотя бы в частично изоляции

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

Остальные упомянутые Вами термины (process, thread, task, work) в RUP не используются

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

Поэтому я бы сказал, что RUP эксплуатирует деятельностно-ориентированный подход

А ИСО - процессно-ориентированный и это термин определен в ИСО, а деятельностно-ориентированный подход это Ваш термин и это Ваша задача придумать 10 различий и мне показать

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

А заглянуть и убедиться трудно в ИСО9000? Я заглянул, убедился, что Вы абсолютно не правы, во теперь и Вам это будет известно
Да! Есть еще системный подход к управлению

Процессы трудно синхронизировать в milestones, если что-то пошло не очень гладко и один из процессов, например, отстаёт от плана, а остальные нет

Да, только ГОСТ требует(это четко зафиксировано) синхронизации и четко выполнения плана, прозрачности деятельности, а RUP - нет? (Я поставил здесь вопрос: разве RUP требует или предлагает какую-то другую синхронизацию?). Вообще трудно синхронизировать. Как же снизить риск перерасхода ресурсов и выхода за график, если не синхронизировать в вехах? А если кто не следует ГОСТу - так это его проблема и его заказчиков, и не объясняйте, что просто им этого не надо - не поверю заранее.

Качество обеспечивается, когда его обеспечивают

Каким образом без синхронизации в контрольных точках, Вы обеспечиваете качество?
Применение методологии RUP гарантирует качество продукта или процесса его создания? Выполнение требований ГОСТ гарантирует.

Если кому-то мои слова покажутся резкими, прошу меня извинить.

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

[barancev]

Анатолий нас уже осуждает за то, что мы устроили в этой теме, поэтому я уточню, о чём же мы спорим с таким пылом (ну или по крайней мере, кто о чем, а я об этом):
Имеет ли смысл выделять Testware Lifecycle из общего Software Lifecycle?
Ещё раз повторю свою точку зрения:
Можно выделять, но мне с практической управленческой точки зрения модели, проводящие такое выделение кажутся менее удобными. Но я не отрицаю, что для других целей (например, для обучения именно тестированию) такие модели могут быть более удобными.
И дальше, похоже, спор пошёл именно о том, кому как удобно, а как неудобно.
Ибо как ещё можно оценить, хорошая модель или плохая, не попытавшить применить её для решения тех или иных практических задач?

То что в RUPe идет первой строкой для Вас (вдруг) магия и ересь. Я приведу ее, а то опять передернут: Iterative Development. Для вас ересь, что тестирование - часть итеративного процесса разработки?
Магия, что в результате процесса разработки появляются программные продукты?

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

RUP- процесс (в ед.числе), никто не спорит, а то что ISO - требования к процессам (многим), так там это написано, перечитайте

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

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

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

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

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

Давайте, в самом деле, посмотрим, как происходит планирование и управление. Вот садится менеджер проекта (например, я), берёт, скажем, MS Project, и начинает рисовать. Что он рисует? Он рисует роли и деятельности. Но не процессы! Да, точки синхронизации могут быть. Но это не догма, а просто одно из средств планирования и управления. Я говорю, что вот к этому моменту вот эти несколько деятельностей должны завершиться. При этом некоторые другие могут протекать безотносительно к этой точке синхронизации. Это синхронизация деятельностей. Такая штука в RUP, конечно же есть, взгляните на диаграммы деятельностей.

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

Кратко просуммирую мою точку зрения на некоторые из остальных пунктов, по которым Виктор :

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

Да, только ГОСТ требует(это четко зафиксировано) синхронизации и четко выполнения плана, прозрачности деятельности, а RUP - нет? (Я поставил здесь вопрос: разве RUP требует или предлагает какую-то другую синхронизацию?).

Да, действительно, ГОСТ требует, и ISO требует, а RUP -- предлагает. Потому что это не стандарт.

Вообще трудно синхронизировать. Как же снизить риск перерасхода ресурсов и выхода за график, если не синхронизировать в вехах?

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

А если кто не следует ГОСТу - так это его проблема и его заказчиков, и не объясняйте, что просто им этого не надо - не поверю заранее.

Не хотите -- не верьте, но бывают такие заказчики. Не так давно представитель одной крупной российской компании, имеющей CMM Level 5 (обойдёмся без имён) рассказал, что даже у них бывают заказчики, которые хотят быстро и дёшево, пусть даже и не очень хорошо, так вот, некоторых посылают, но для некоторых специально организовываются так называемые non-CMM проекты. Гибче нужно быть, излишняя ортодоксальность и приверженность стандартам может и боком выйти, заказчик уйдёт.

Каким образом без синхронизации в контрольных точках, Вы обеспечиваете качество?

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

Применение методологии RUP гарантирует качество продукта или процесса его создания? Выполнение требований ГОСТ гарантирует.

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

[Viktor]

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

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

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

[barancev]

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

Теперь про вопросы и про мои ответы. Я бы расклассифицировал Ваши вопросы так (с примерами):

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

Если Вы предложите список вопросов, на которые можно дать простой ответ, например, такие "Применение методологии RUP гарантирует качество продукта или процесса его создания?", и поставите условие давать именно простые ответы, я их дам. Но вряд ли Вы будете удовлетворены, получив ответ "нет" на указанный вопрос :), Вы скажете, ага, значит RUP плохой, я же говорил, но я, отвечая "нет" имел в виду совершенно другое. Впрочем, как я уже сказал, ЭТОТ вопрос провокационный и он пойдёт в отдельую тему. Здесь его закрываем.

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

Для того, чтобы понять и использовать подход, основанный на деятельностях, а не на процессов, не нужно быть рупером. Пойдите к совим менеждерам и попросите показать сетевые диаграммы (или хотя бы диаграммы Гантта) и увидите набор деятельностей со связями, синхронизациями и прочим таким. И никаких процессов. Даже если есть глобальные точки синхронизации, всё равно процессов может не быть.

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

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

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

Тестирование в RUP -- это не деятельность. Слишком крупная единица. И как следствие -- неуправляемая и неизмеримая. Деятельности -- это, например, "Implement Test", "Execute Test Suite", "Analyze Test Failure", "Assess and Advocate Quality" и т.п.

[Viktor]

Ладно, останусь магом и еретиком. :), сейчас какую-нибудь цитатку подберу в подпись :), кстати, если у кого есть, с благодарностью приму.
Вот тут уже нам намекали, что мы говорим об одном и том же, теперь и я уже (в очередной раз) склоняюсь к тому, что (мой или ИСО, я всегда к нему аппелирую) "процесс" - это "деятельность" в Вашем (и RUP?) понимании. Так как "процесс" в Вашем понимании, ни как не вяжется с моими определениями, которые я уже приводил.
Вы упоминали М$Project, специально установил свежую версию с русским языком (что бы не было неточностей перевода), открыл диаграмму ГАНТА, посмотрел в справке - там представлены "зависимости задач", на худой конец "действий". Нет никаких "деятельностей".
Мой ПМ (странно, да?) вообще таких слов не говорит как "деятельность".
Поэтому и интересно мне что это за подход такой к моделированию ЖЦ? И в чем его отличия от процессно-ориентированного подхода?
Вот ближе Вас нет ко мне никаких менеджеров, поэтому, Вы уж простите, я Вас и террризирую :) (Это не опечатка, это что бы кое-кто не нервничал за пультом :))

[barancev]

"Деятельность" -- это так я говорю.
RUP естественно использует английский термин -- "activity".
MS Project использует термин "task", который локализаторы видимо перевели как "задача", но в литературе по менеджменту обычно используется термин "работа" и "зависимости работ" (не всякая работа -- задача :)).

Но ведь согласитесь, процессов там (в MS Project) не было, правда? Потому что это слишком сильная (и далёкая от реалий жизни) абстракция, чтобы пользоваться ею в повседневной жизни.

... теперь и я уже (в очередной раз) склоняюсь к тому, что (мой или ИСО, я всегда к нему аппелирую) "процесс" - это "деятельность" в Вашем (и RUP?) понимании.

Я в конце предыдущего сообщения приводил примеры деятельностей в понимании RUP, такие как например, "Implement Test", "Execute Test Suite", "Analyze Test Failure", "Assess and Advocate Quality". Вряд ли Вы согласитесь признать их "процессами" в понимании своём или ISO.

Ну, а на Ваш жирный вопрос я не могу ответить кратко да/нет. И развёрнутый ответ мне тоже не очень хочется давать, ленивый я. Кроме того, это будет уже не RUP, а моя убогая его интерпретация. Поэтому я предлагаю Вам самостоятельно ознакомиться с RUP и понять, чем он отличается от того процесса, который Вам привычен. Может оказаться, что ничем. И это будет означать просто-напросто, что к Вашему реальному процессу применимы обе модели. А может оказаться, что отличается, вот тогда Вы и скажете, чем. Кстати, не обязательно читать сам RUP, можно прочитать про USDP, тем более, что книжка про него переведена на русский язык (Унифицированный процесс разработки программного обеспечения, Якобсон, Буч, Рамбо). Суть одна и та же.

[Viktor]

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

[barancev]

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

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

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

Попробую снова вернуться к теме обсуждения, надеясь заслужить этим прощение Анатолия :)

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

[Undi]

Извините, что вмешиваюсь в вашу дискуссию. У меня вопросы к Виктору.
1. Почему Вы считаете, что при использовании одной модели "никто не будет спрашивать, где результаты моего труда, а особенно в самые неподходящие для меня моменты!!", а при использовании другой модели Вам эти вопросы задавать будут?
2. Почему Вы считаете, что правильно понимаете ISO, RUP и т.д.? (Я не говорю, что Вы не понимаете чего-то. Я только интересуюсь на чем основана такая безграничная уверенность).
3. Почему Вы считаете, что один (не важно какой) подход может быть универсальным? (Во всяком случае, впечатление сложилось именно такое). Почему нигде не упоминается масштаб и направленность проекта?

Повторюсь, выше изложены вопросы, а не утверждения. Мне интересно Ваше мнение в этом аспекте.

[barancev]

Анатолий, я рад, что наше реноме ещё не совсем упало в Ваших глазах, мы таки смогли вернуться к теме :)

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

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

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