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

Ну вот есть станарт, его адаптировать надо - и от этого будет зависеть как применять.

Это, кстати, одно из первых требований стандарта 12207

Я смогу перевести бабушку, вполне случайно, так что полностью удовлетворю все её требования по переводу: скорость движения, давление на руку, конечній пункт (другая сторона).

То есть у неё будут невысокие требования - я окажу услуги согласно её требованиям, то есть окажу качественную услугу, соответсвующую требованиям + в нужное время, в нужном месте.

Я потому и усомнился в качестве, так как требования бабушки Вы ведь не узнали? Просто повели ее в неизвестном (удача - если совпало :)) направлении. Ваше качество будет очень субъективное. Бабушка может думать совсем по-другому. Услуга только тогда будет считаться качественной, если представлены объективные доказательства. Предположем, что Вы получили вознаграждение от бабушки в сумме $50, это уже объективное доказательство ее удовлетворенности. Но ведь случайно такого не бывает?

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

Хотелось бы узнать о подводных камнях этого вида тестирования. На что обращать внимание в первую очередь? Тестирование, это по сути дела сравнение ЧТО ЕСТЬ и ЧТО ДОЛЖНО БЫТЬ... Но в этом случае нет эталона, с чем можно было бы провести сравнение... В общем, хотелось бы услышать ваше мнение!

Вобщем-то, действительно. Не с чем сравнивать, значит нечего и тестировать. Зачем "испытывать тех. задание"? :)
Мне кажется дальнейшая разработка - и есть испытание ТЗ :). Слава богу (многие крестятся), что оно вообще есть. :).
Хотя если под тестированием ТЗ понимать его оценку. Тогда оцените требования ТЗ, как это предлагает ГОСТ
Критерии:
1 учет потребностей заказчика;
2 соответствие потребностям заказчика;
3 тестируемость;
4 выполнимость проектирования системной архитектуры;
5 возможность эксплуатации и сопровождения.

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

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

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

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

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

Конечно одного ТЗ недостаточно.
Но здесь появляется следующий вопрос: Что нужно, чтобы создать качественный продукт? Естественно,
следовать требованиям ГОСТ (и/или какой-нибудь авторитетной модели), в том числе и требованиям к процессам.
Но это все проблема тех или иных артефактов, скажет сомневающийся :).
А вот еще одно предложение
"Процессный" ГОСТ требует выполнения в ходе проекта постоянных действий по оценке продукта и процесса разработки с привлечением заказчика. Попробуйте без V&V создать качественный продукт или оказать качественную услугу!

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

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

Не думал, что эти Имена нужно озвучивать :)
По стандартам и моделям: начиная с ИСО 9000 и далее, 12207, 12119, 9126, рекомендации по стандартизации 50.1.*, ГОСТ 19.*,34.*, 28195 и т.д (далеко не полный список, мне достаточно только этих).
Возможно, СММ ( а уж CMMI - просто песня) даже лучше, но, увы, сначала хотим достигнуть "показателей, позволяющих летать на самолете, а уж потом на космическом корабле".

Кто-нибудь может ответить на любой из этих трёх вопросов?

Могу ответить на первый и третий
Во-первых, давайте говорить не "ГОСТ гарантирует", а "выполнение требований ГОСТ гарантирует", так проще, понятней и правильней, ГОСТ сам по себе ничего не гарантирует :).
Во-вторых, основной принцип системы менеджмента качества ИСО - ориентация на потребителя. Поэтому ГОСТ требует, чтобы значения характеристик качества должны быть приемлемы для потребителя. Это значит, что если потребитель требует количественных метрик, они должны быть посчитаны, если ему достаточно простых оценок типа "круто/не круто", продукт должен быть оценен с учетом этого представления. ИСО 9001 не поможет в измерении качества продукта, а вот ИСО 9126 очень даже поможет.
Что же касается третьего вопроса, то это частный случай первого, но довольно интересный.
Была такая хорошая статья в ОС

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

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

С удовольствием отвечаю (возможно, пока я отвечаю, Алексей перестанет лениться и ответит на мои вопросы)

1. В своей жизни я встретил (:)) только процессно-ориентированный подход (который ориентирован на результат), вот я и подумал, что если он требует результаты, то, возможно, новейший современный подход Алексея будет свободен от этого недостатка. (Но, вообще-то, это была такая серьезная шутка :))
2. Я привык сомневаться в словах (будь они мои или чьи-то еще), но свои слова я стараюсь подкрепить аргументами, который любой может оспорить, и не ссылаюсь на мифических авторитетов. Нет, я так не считаю, скорее всего я даже ошибаюсь и очень хочу разобраться, но наверное так и умру еретиком на костре ортодоксов :).
3. Во всей теме я видел только один подход - ИСО, других просто не видел, возможно, они есть, возможно, даже есть тот, который упоминает Алексей. Подход ИСО -универсальный, так как он таким и задумывался, возможно, получился не очень удачным (раз возникли такие споры), а мне нравится. Масштаб и направленность каких проектов следовало упомянуть?
Мне в дискуссии этой приходится сложно, с одной стороны есть сильная теория функционального моделирования, сторонником которой я являюсь. С другой стороны - Алексей с её практическим применением, но который не желает признавать ее корней. И вот я мечусь в поисках правды, безудержно впадаю в ересь, и нет никаких возможностей спасти мою мятущуюся душу!!!

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

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

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

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

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

И не увидите, Вы же внедрили и 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 гарантирует качество продукта или процесса его создания? Выполнение требований ГОСТ гарантирует.

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

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

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

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

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

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

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

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

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

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

Viktor, мне, честно говоря, казалось что то что вы тут называете процессом, на самом деле есть activity в RUPе. То есть, я всегда себе представлял так, что activity это элементарное действие, которое совершается в рамках одной роли, имеет на входе некий набор артифактов, а на выходе - другой набор. Например, один round тестирования есть деятельность, выполняемая тестировщиком, имеющая на входе partial test plan, а на выходе - баги и логи исполнения тестов. Понятно, что одна activity может включать в себя другие, но в общем случае activity выполняется в рамках одной роли.  Так, тест-менеджер на входе в цикл тестирования опять-таки имеет master (system) test plan и test strategy в процессе распределяет выполнение тестов и получает логи исполнения (а так же баги), а на выходе выдаёт отчёт о проведённом тестировании.

Я и сам до этого разговора так думал, однако это, как мне показал Алексей, не совсем так.
Т.е. подход в RUP другой - не процессный, мне сложно это объяснить, так как у меня нет примеров полноценной разработки по RUP.
Но то что вы говорите про Вашу организацию - этот к чему я стремился у себя, а Алексей показал, что это искажение RUP (здесь под RUP я понимаю не просто методологию разработки, а некий стандарт, правила).
В статье рассказывается как сглаживаются эти грани, но слово грубо (roughly) в определении process мне не нравится. Кстати, еще одна оценка RUP для процессно-ориентированного подхода - слабый (weak)

Тестер - друг человека!

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

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

Что такое ИСО 12207, к сожалению, не знаю (я собственно, управлением качеством не занимаюсь - я тестировщик). Вы не могли бы привести ссылочки и название этого документа?

Мы сертифицированы по ISO 9001:2000 (уточнил).

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

work - работа?

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

PS. фишку можно аргументировать :)

Подпроцесс (discipline)
A discipline is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping of activities into disciplines is mainly an aid to understanding the project from a 'traditional' waterfall perspective - typically, for example, it is more common to perform certain requirements activities in close coordination with analysis and design activities. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule.

Поясняю, из ссылки только что выдернул

Process. An ISO 12207 process corresponds roughly to the RUP
concept of a Discipline, but there are more processes in ISO 12207
than there are Disciplines in the RUP.

Качество обеспечивается, когда процессный подход накладывается на деятельностный! (или наоборот?)

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

Слава Богу!!! А то я уж испугался :)

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

Где практики? Дайте нам объективные доказательства :)

PS. Сейчас почитаю
12207 и RUP

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

Цель процесса тестирования - снижение риска, связанного с отказом системы в самый неподходящий для продавца продукта момент!!!
Этот риск очень значим для продаж - лучшие идеи, заложенные в некачественном продукте, уйдут в качественные конкурентные! Теряется лицо!
Тестеровщик - ликвидатор риска, очень большой друг менеджера проекта!
Разработчик - враг МП (:)), вносит неопределенность в процесс управления рисками

Алексей, я прав?

В целом да, но в частностях... Разработчик -- враг МП?
Хм... Впрочем, в этом что-то есть. :)

Цель процесса тестирования, конечно, не снижение риска. Это цель деятельности, в которую тестирование включено как составная часть. Если, скажем, тестировщик найдёт ошибку, но она не будет исправлена, то риск от этого нисколько не уменьшится -- система упадёт там же и тогда же. Да, управлять рисками станет легче, ибо появляется большая определённость. Именно поэтому тестировщик -- друг МП. А вообще-то у него ещё много друзей :)

Разработчик, конечно, вносит неопределённость, но неопределённость -- это не самое страшное. Риск полного невыполнения проекта, то есть несоздания продукта, у которого вероятность наступления 100% -- вот что появляется, если разработчик не будет делать своё дело. Так что эта неопределённость, которую он вносит, просто цветочки по сравнению с той определённостью, которая наступит иначе :)

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

Кстати, Алексей, снижение рисков - не это ли тот основополагающий принцип, которым Вы руководствуететесь в своих проектах?

Цель процесса тестирования - снижение риска, связанного с отказом системы в самый неподходящий для продавца продукта момент!!!
Этот риск очень значим для продаж - лучшие идеи, заложенные в некачественном продукте, уйдут в качественные конкурентные! Теряется лицо!
Тестеровщик - ликвидатор риска, очень большой друг менеджера проекта!
Разработчик - враг МП (:)), вносит неопределенность в процесс управления рисками

Алексей, я прав?

Ох и люблю я цитаты!

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

Хорошо, отдаю Вам должное, я провокационно ввел первые три (process, thread, task)
(Они используются, но для других целей :), да?)
Поэтому, пойманный за руку, должен согласиться, что RUP не использует "процессный" подход
RUP использует какой-то другой подход, discipline-ный, что это значит надо будет как-нибудь обсудить :)

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

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

Вообще-то я это вопрос не задавал.

Никаких претензий :)

А Вы, кстати, знаете на него ответ?

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