И что комании дает подобная оценка четырех PA? Не совсем понятно. Иными словами какие цели преследовали?

Вопрос хороший, формулировка - не очень. :)

Оценка ничего не дает кроме подтверждения, например, соответствия чему-то. В данном случае потверждено, что в рамках оцениваемого unit'а (!) компания умеет управлять проектами, разрабатывать требования и их реализовывать. Может пока это не имеет характер твердо установленых процессов, но может быть этого компании и достаточно? Кроме того компания получила оценку того, что из себя представляет ново внедряемая методология управления проектами с точки зрения CMMI.

Что касается первого уровня, то описание в модели таково: "A performed process is a process that accomplishes the work necessary to produce work products.". Для сравнения то, что подразумевается под вторым уровнем: "A managed process is a performed process that is planned and executed in accordance with policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated
for adherence to its process description."

PS. Можно найти результаты, где Capability Level 0. Вот где люди расчитывали на что-то, а оказалось...

Я собственно почему спросил: мы как суплаеры со статусом "геграфически удаленная команда" уже второй год учавствуем в проекте подготовки компании заказчика (соответственно и нас тоже) к получению 2-го уровня CMMI-SW. На моей памяти было уже 3 (три) SCAMPI B :) Все измотаны этими постоянными граблями на которые наступает PAT (формально являющийся экспертным) со стороны Заказчика. И вот после очередного SCAMPI на котором сказали что вроде как все артефакты есть и они косистентны, но вот беда эти процессы not alive (никто из опрошенных pm не сумел доказать что он пользуется или знает зачем тот или иной документ создается) я подумал о том, что может быть стоит попробовать проходить аттестацию попроцессно. Углубиться в Continuous еще не успел, подумал может быть Вы подбросите мыслишку :)

Три SCAMPI B и все относительно одного target level? Это сильно, однако... SCAMPI B - это, все-таки, readiness check перед Class A. Столько раз "проверяться"? :(
Кстати, формально (исходя из требований к SCAMPI B) все и не должно устно потверждаться (хотя, конечно, чтобы снизить риски, лучше иметь побольше affirmation). Честно говоря, если люди не могут рассказать - как они "производят" тот или иной артефакт, это действительно плохой симптом. Хотя тут еще многое зависит и от жесткости оценки.
Continuous использовать можно, но если важен и maturity level 2 (как еще и "бирка"), то тут это не поможет. Continuous помогает (как то, что используется для итогового оценивания) когда:
а) для организации действительно важно проверить (и потвердить) уровень конкретных, наиболее критичных для нее областей;
б) у организации просто нет возможности продемонстрировать из того, что включено в maturity level N (ну нет, например, тестирования своего);
в) что-то еще своеобразное.
Мне кажется, что в Вашем случае (если важен maturity level 2) надо, все-таки, действительно стараться реально устранить выявленные проблемы и... провести SCAMPI B относительно всех областей второго уровня, либо пару SCAMPI B, разделив scope по областям разных категорий (как они в Continuous категоризируются). Ну и :) можно обратиться за услугами (консультациями) к нам...

Саш, поздравляю тебя :) Главное, что бы клиенты поперли табуном! :-D

***у организации просто нет возможности продемонстрировать из того, что включено в maturity level N (ну нет, например, тестирования своего);

И что? CMMI гибкая штука, раз нет тестирования, значит данный раздел должен быть подтвержден аутсорсовой документацией, результаты тестирования то для багфиксинга то должны быть откуда то, вобщем проблем то - пшик...

Главное другое, ты надеюсь своим первым клиентам, красивый "сертификат" выдал, что бы с ним торжественно все сфотографировались и с не меньшим торжеством на стену повесили в рамочке? ;-)

Спасибо за поздравления!

По поводу "табуна"... надо стать хорошим "ковбоем", чтобы всех поймать. Надо бы на техасщину какую-нибудь съездить - посмотреть на натуральных ковбоев. :)

А вот по поводу "раз нет тестирования, значит данный раздел должен быть подтвержден аутсорсовой документацией" не совсем корректно. Оцениваются процессы конкретного юнита. Если в юнит включен и аутсорсер, тогда да, вариант предложенный проходит. А вот если вся верификация (гипотетически) на стороне, то, что в конкретном юните оценивать? Управление поставщиком это будет, а не верификация. Напомню, кстати, что в CMMI-DEV в понятие product включается и service.

***А вот если вся верификация (гипотетически) на стороне, то, что в конкретном юните оценивать? Управление поставщиком это будет, а не верификация.

Да я в общем об этом же, и на твою же фразу - "у организации просто нет возможности продемонстрировать из того, что включено в maturity level N (ну нет, например, тестирования своего);".
То есть если у компании аутсорсят тестинг, это не повод отказываться от матюрити левела :)

"это не повод отказываться от матюрити левела" - так если компания не может прдемонстрировать реализацию практик области Verification, то как она "подтвердит" уровень зрелости три и выше?

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

Тут какое-то недопонимание, видимо. :( Нельзя подтвердить что-то через что-то другое. И почему CMMI непригодна, если нет верификации?

Реальный пример: крупная западная корпорация все разрабатывает сама. Но вот тестирование своего любимого продукта она отдает в Россию. Нет у западной корпорации процессов, связанных с тестированием вообще. И что - она (корпорация) не может претендовать на внедрение практик CMMI? Почему? Корпорация спокойно внедряет 16 из 18 областей 3 уровня (исключаем Verification и Validation, предположим) и "сертифицируется" по Continuos на Capability Level 3 для каждой из областей 3 уровня. Едва ли не главное для такой организации - это область Supplier Agreement Management. Там есть две практики (SP 2.2 Monitor Selected Supplier Processes и SP 2.3 Evaluate Selected Supplier Work Products), которые как раз и говорят о том, что поставщика продуктов (услуг) весьма полезно контролировать. В данном контексте - это, например, и проверка того: как верифицируется продукт и какие измерения получаются (то же количество дефектов).
Так что никаких противоречий здесь нет. Более того - могу с уверенностью сказать, что по такой схеме работают даже в такой отрасли как авиационное ПО.