По-моему, никакой количественной оценки не получится. Потому что на ноль делить нельзя.

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

IMHO, чтобы убедить заказчика, нужно непрерывно капать ему на мозги, приводя пункты 4.1-4.14 на человеческом языке в разных вариантах, подкрепляя примерами из жизни (причём из ЕГО жизни).

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

Эд, а может посмотришь, очень надо. А то я уже все перерыл

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

В том то и дело, что люди как-то работают, даже спеки пишут.... И надо именно показать разницу между тем что есть и как будет хорошо.

IMHO, чтобы убедить заказчика, нужно непрерывно капать ему на мозги, приводя пункты 4.1-4.14 на человеческом языке в разных вариантах, подкрепляя примерами из жизни (причём из ЕГО жизни).

Это хорошо делать находясь в компании, а из вне?

В том то и дело, что люди как-то работают, даже спеки пишут.... И надо именно показать разницу между тем что есть и как будет хорошо.
Это хорошо делать находясь в компании, а из вне?

Так может, и не надо тогда никакого процесса?

ИМХО стоит артикулированно отделить две ситуации:
1. Требования Заказчика ясны как пять копеек, а управление требованиями - возможность организации гибкого, но управляемого процесса разработки. По идее такое может потребоваться если компания пробует внедрять новую технологию разработки, что создает дополнительные риски управления проектом (в части понимания в любой момент что именно зачем делаем).
2. Заказчик сам не знает точно, что хочет (редкий Заказчик готов предъявить более-менее ИСЧЕРПЫВАЮЩИЙ список своих ключевых/целевых показателей). Тогда управление требованиями - способ поворачивать разработку вслед за полетом мысли Заказчика уже в процессе разработки, а также возможность оперативно предъявлять ему требования по пересмотру сроков и оценку увеличения стоимости разработки, буде он такие виражи будет закладывать . Для Заказчика пропагандируется гибкость разработки ("раз уж Вы сейчас не можете точно сформулировать требования..."). Для начальника - снижение рисков взять на себя невыполнимые обязательства по договору, возможность раннего выявления скрытых противоречий в требованиях Заказчика.

А №1 - такое вообще бывает???

А №1 - такое вообще бывает???

Я так понял, что у Вас как раз скорее первый, а не второй случай, потому и выделил .

А решил так потому что ключевые фразы Вашего предложения  "...уменьшить время, требуемое на процесс анализа",  "полно отвечающее всем требованиям Заказчика...", "...использовать требования и разработанные решения вторично...", "...планировать разработку ПО...", "...стратегические решения по совершенствованию существующего ПО...", "увеличит контроль над процессом анализа", "легко и быстро ввести нового человека (Аналитика, Архитектора, Разработчика и Тестировщика) в проект" и пр. смотрятся соблазнительно для человека, который находится в ситуации 1 (т.е. акцентируют в большей степени решение проблем взаимодействия внутри команды Исполнителя, и в меньшей - проблемы взаимодействия Заказчика и Исполнителя).

Эд, а может посмотришь, очень надо. А то я уже все перерыл

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

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

... а ты приходишь и говоришь - в 200 раз. А он - за счет чего??

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

Для убеждения заказчиков можно, имхо, использовать аналитические обзоры, как уже сказал Эдуард.
Например, те же всем известные данные Standish Group. Цифры приведенные Лиффингуэлом, не знаю как других, но меня почему убеждают и я ему верю.

Сами посмотрите сколько ресурсов  на практике у Вас уходит на то, чтобы передалать какое-то требование, которое не точно сформулировали или реализовать требвание, которое вообще забыли.

Юра,
Еще бы не плохо если бы ты сказал эти "мерительные" показатели, или сказал бы где почитать ...

Списка всех показателей на память не помню ... но например тот же PSP\TSP дает много метрик -- можно наковырять. Ряд KPI можно подсмотреть в COBIT.

еще можно посмотреть тут http://satc.gsfc.nasa.gov/support/PNSCQ_OCT98/requirements_testing_and_metrics.html

еще тут http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/11.pdf

Еще можно посмотреть эту книгу - Software Testing Fundamentals: Methods and Metrics
by Marnie L. Hutcheson ISBN:047143020X John Wiley & Sons © 2003 (408 pages)
Там есть раздел по метрикам относящихся к тестированию, но часть из них вполне применима как показатели качества ПО.

Еще можно кое-что выковырять отсюда Software Metrics: A Guide to Planning, Analysis, and Application
by C. Ravindranath Pandian   ISBN:0849316618
Auerbach Publications © 2004 (312 pages)

Далее, тут есть интересные моменты: Practical Measurement in the Rational Unified Process by Doug Ishigaki
Sr. Technical Marketing Engineer Rational Software and Cheryl Jones. Это из Rational Edge статья, кажись за 2003 год.

Еще, в догонку -- очень интересная вещь http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/12.pdf

Всем спасибо.

Попробую как-то сагрегировать высказанную выше ин-ю и напишу что получилось.