Здравствуйте, Nata1111, Вы писали:

N> И в догонку:

N>То что фирмы используют RUP и пр. вовсе не означает, что на выходе получится хороший безглючный продукт. Насмотрелась я уже на разработки крутейших фирм. То то утечки GDI ресурсов, то интерфейс нечитабельный при ACP, отличной от 1251. Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.

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

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

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

100% гарантии не дает, и не никогда не даст, ни одна из методологий...

Здравствуйте, Framer, Вы писали:

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

Если я правильно понял, что вы имели в виду, то у меня впечатление, что это обычное дело, когда мелкий заказчик не представляет четко, что ему надо. Сегодня ему надо "белый верх, черный низ", завтра наоборот. И никто заранее не знает, как лучше сделать. Это поиск.

Здравствуйте, Nata1111, Вы писали:

N>Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.

Полностью согласен !!!

По-моему, в таком случае главная "методика" — работать аккуратно и, если брать помощника — то тоже аккуратно работающего.

Здравствуйте, Dimentiy, Вы писали:

D>Здравствуйте, Nata1111, Вы писали:

N>>Я думаю, что качество разработки прежде всего определяется квалификацией разработчиков, а уж во вторую очередь методологиями.

D>Полностью согласен !!!

D>По-моему, в таком случае главная "методика" — работать аккуратно и, если брать помощника — то тоже аккуратно работающего.

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

Здравствуйте, ON, Вы писали:


ON>http://www.sei.cmu.edu/about/website/indexes/siteIndex/siteIndexTR.html
ON>там должно быть о Personal Software Process и вообще много вкусного для менеджеров

PSP/TSP — это действительно вкусно для менеджеров, но для программеров как показывает практика не очень . Внедрена эта шняга у нас на работе. По полной программе, с выпиской специально обученых тренеров из штатов. Уже год с ней работаем. У меня даже сертефикат от Карнеги-Меллонского института есть, что я типа специально обученный PSP программер (никому не пожелаю через это пройти — ужас какой-то

Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.

> Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне
Методологий. Если интересно, могу рассказать подробнее, почему. Как
сертифицированный PSP программер.

Очень интересно, расскажите, пожалуйста.

Еще столкнулась со следующей проблемой:

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

Вопрос: кто как хранит наработки, чтобы в любой момент времени можно было легко найти нужное?

Здравствуйте, ZORK, Вы писали:

[]

Планы нужно составлять вечером, а не утром. Как говориться, готовь сани летом.

Здравствуйте, Nata1111, Вы писали:

N>У меня точность оценки временных затрат — по Бруксу (т.е в 2-3 раза дольше А есть какой-либо софт, которым ведут эти метрики?

Тогда Вам должно быть особенно легко прогнозировать время работы. Просто свою оценку умножайте на PI

Здравствуйте, Gaperton, Вы писали:

G>Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.

Просим, просим!!!!

Здравствуйте, Gaperton, Вы писали:

G>Здравствуйте, ON, Вы писали:


G>Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.

Ай-ай-ай, зачем секреты выдавать

Здравствуйте, Nata1111, Вы писали:


N>Вопрос: кто как хранит наработки, чтобы в любой момент времени можно было легко найти нужное?

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

Здравствуйте, DemAS, Вы писали:

DAS>Здравствуйте, Nata1111, Вы писали:


N>>Вопрос: кто как хранит наработки, чтобы в любой момент времени можно было легко найти нужное?

DAS> Стараюсь все это иерархично организовывать и храню в виде chm. Всегда можно взять с собой и для того, чтобы просмотреть все это не нужно специфичного софта.

А я вот все по старинке. Пытаюсь все в голове удержать.
Тоже можно всегда с собой взять и вообще никакого софта не нужно

Здравствуйте, <Аноним>, Вы писали:

А>А я вот все по старинке. Пытаюсь все в голове удержать.
А>Тоже можно всегда с собой взять и вообще никакого софта не нужно

Ага. Многие и проектную документацию так ведут — в голове.

Простой пример — вы писали проект на Java. А потом в течении 2-3 лет работали над проектом С++. Не уверен, что через эти 2-3 года у тебя в голове останется все то, что было ранее.

Здравствуйте, DemAS, Вы писали:

DAS>Здравствуйте, <Аноним>, Вы писали:

А>>А я вот все по старинке. Пытаюсь все в голове удержать.
А>>Тоже можно всегда с собой взять и вообще никакого софта не нужно

DAS> Ага. Многие и проектную документацию так ведут — в голове.

DAS> Простой пример — вы писали проект на Java. А потом в течении 2-3 лет работали над проектом С++. Не уверен, что через эти 2-3 года у тебя в голове останется все то, что было ранее.

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

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

Если я неверно понял вопрос, то пусть Nata1111 прояснит, что она имела ввиду...

P.S. Прошу прощения, анонимом был я...

Здравствуйте, bkat, Вы писали:

B>Вопрос немного об ином был. Я так понял, что вопрос был не о проектной документации,
B>а о знаниях, которые очень часто бывает ненужны в конкретный момент времени,
B>но могут в любой момент пригодиться. Например, паттерн "одиночка".
B>Как бы мне его так задокументировать, что бы в нужный момент его быстро найти и адекватно использовать?

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

B>Если я неверно понял вопрос, то пусть Nata1111 прояснит, что она имела ввиду...

Да-да, именно то, что Вы описали. У меня уже целый CD всяких полезностей. И вот допустим, мне сейчас нужна конкретная функция, и я точно знаю, что она у меня где-то есть. Делаю поиск по разным ключевым словам — и облом! Хоть в базу данных заноси местоположение и краткое описание. Для статей действительно помогает компиляция в chm, а вот для кода вряд ли.

G>Так вот, если кратко, то PSP это наверное самая маразматичная из известных мне Методологий. Если интересно, могу рассказать подробнее, почему. Как сертифицированный PSP программер.

Рассказываю.
PSP? Что-ж это, блин, такое?
Методика прогнозирования сроков, контроля за выполнением и контроля качества продукта для одного разработчика.
1) Все время потраченное на разработку замеряется для каждой фазы активности (компиляция, планирование, дизайн, кодирование, отладка, и еще там кое что свое) и записывается.
2) Размеры кода в LOC (Lines of code) планируются и записываются для каждой задачи (интерес представляет количество измененных и добавленных строк). Замеряется также фактический размер после закрытия задачи.
3) Все баги (дефекты) записываются, включая ошибки компиляции. Замеряется время, потраченное с обнаружения до исправления каждого дефекта.
4) После закрытия задачи считаются следующие метрики: кол-во измененных и добавленных строк кода, плотность дефектов на 1000 строк кода (в разрезах по фазам внесения/устранения), производительность строк/час.

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

Теперь, что касается собственно процесса. Так как цена исправления дефекта тем больше чем бельше промежуток времени между его внесением и исправлением (это в целом верно), методы PSP направлены на раннее обнаружение внесенных дефектов. Здесь и начинаются странности PSP.
1) Нам призванна помочь техника review (поиск ошибок методом пристального взгляда), основанная на чеклистах (список часто (!) встречающихся ошибок, снабженных _механическим_ правилом их выявления). Во время review вы должны взять cheklist и пройтись по коду/дизайну целенаправленно поискав там ошибки из чеклиста. Так как все ошибки записываются, из них типа легко составить чеклист. А ошибки, по статистике, часто повторяются! Т. е. программер туп, и склонен постоянно наступать на одно и те же грабли. Причем туп настолько, что учится без этих чеклистов не в состоянии.
2) review для кода делается ***перед*** компиляцией! И вы должны найти и записать синтаксические ошибки, в числе прочих. Потом тулза вам покажет корелляцию (или ее полное отсутствие по всем группам, как у нас) между синтаксическими и прочими ошибками. Да, все ошибки компиляции тоже фиксируются, и считается процент отлова этих ошибок на review. Это должно показать качество code review, что типа в той же пропорции выловлены риальные ашипки, чиста. Если есть корелляция, которой у нас нет. Но это не повод, чтоб в сердце мужчины закралась ненужная грусть. Ответ PSP тренера на ответ программера на письмо PSP тренера:
>> The PSP data issues for this week:
>> Task #xyz: review is done after compile. Is there a specific reason for that?
> Yes. And you know them.
I don't. Last week when we talked you said you would follow the process.
>> The PSP calls for code reviews before the first compile.
>> The reasons are as follows.
>> *Review time is about the same, whether done before or after compile.
Can you explain, what's wrong with this point?
>> *Code reviews will find syntax defects that the compiler misses.
Can you explain, what's wrong with this point?
>> *Code reviews of compiled code tend to be much less effective.
>> Once a clean compile occurs, it is very difficult for a developer to convince himself/herself to do a thorough code review. Psychologically, a programmer will feel that the code is fine and there is no need for a code review. Because of this, many defects will slip though to inspection and unit test. There is conclusive industrial evidence that the code reviews are more effective when performed before compilation.
>> *The compiler is equally effective before or after reviews.
Can you explain, what's wrong with this point?
>> *Compile can be used as quality check for review.
>> A compiler is fully-automated and is the only truly objective measure of the effectiveness of your code review. Otherwise, there is no easy way to determine quickly if your code review worked well.
> Ravings. Gibberish. Nonsense. Bosh. Rubbish. In that order.
Developer should follow the defined process unless there is a compelling reason to change the process.

И это только начало. Продолжение следует.

Ну вот, добрался домой. Продолжим.

Зададимся вопросом, что же нового есть собственно в PSP.
Идея сбора метрик? Нет, это придумал вовсе не старина Хамфри (автор PSP). Все метрики, которые мы должны собирать, стары как мир. Если разобраться по сути, то они добавили только чеклисты и review (хотя и тут не уверен до конца, но скорее всего так). Процесс разработи по PSP выглядит слежующим образом:
1) Planning
Планируем размер в LOC с разбиением по мелким (!) задачам, тулза выдает прогноз по времени на основании персональной статистики, учитывая тенденцию программера к overestimate и underestimate. Задача должна занимать от 3 до 5 дней, не больше. Т. е. мы должны сделать подробную декомпозицию ***перед*** началом High Level дизайна. Кстати, эта фаза не должна занимать много времени! Крутись как хочешь.
2) High level design. Дизайн в обычном понимании этого слова.
3) HLD Review. Начинаем ловить дефекты. Отмечаем их в тулзе. Потраченное время тоже отмечаем. Дефекты ловим по чеклисту!
4) Detailed Design. Сюрприз! Все привыкли считать это кодированием, а это таки дизайн!
Это: определения всех типов (классов), тела функций на псевдокоде будьте любезны! Ошибка в алгоритме сортировки — не предусмотрели граничные условия — это ошибка дизайна, а не реализации.
5) DD Review
(!!!) Отлаживаем алгоритмы на псевдокоде в Exeleвских таблицах (т. е. в уме), как студенты-первокурсники! Этого, правда, никто не делает. А так, — стандартно: чеклисты.
6) Coding — здесь все ясно, хотя есть нюанс. Дело в том, что после 2-х дизайнов список задач, стотавленный на фазе 1 может измениться, причем серьезно. И не торопитесь окинуть свой код взглядом с птичьего полета, с целью понять, что же за фигню вы написали (что многие делают с периодичностью 5 минут). Этого делать нельзя ни в коем случае (но все делают — куда деваться-то), иначе поплывут статистики! Только в пункте 7)
7) Code Review. Взял чеклист составленный из предыдущих ошибок, и вперед!
8) Compilation. Отмечаем ошибки компиляции. Считаем, какой процент из них мы отловили на предыдущей фазе. Сокрушаемся и качаем головой. Да, хреновый у нас review yield!
9) Testing. Отмечаем все ошибки, и время которое потрачено на исправление. Если суммарное время на исправление сильно меньше времени тестирования — вздрючат.
10) Postmortem. Вбиваем в тулзу всякую шнягу, чтобы ей было приятно (риальное кол-во строк кода). Иначе вздрючат .

Если проанализировать критерии входа/выхода для фаз, мы поймем что имеем дело с классической waterfall моделью, где фазы привязанны к виду активности (все что они несут про возможность использования PSP с инкрементальными моделями — очередной случай так называемого вранья). Что нам известно про waterfall? Если кратко, что сейчас не имеет смысла его использовать (ссылки на литературу могу привести отдельно, не помню сейчас).

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

Здравствуйте, Gaperton, Вы писали:

Всё таки позволю себе вступиться за процесс, хотя я _НЕ_ЯВЛЯЮСЬ_ его сторонником

G>1) Planning
G>Планируем размер в LOC с разбиением по мелким (!) задачам, тулза выдает прогноз по времени на основании персональной статистики, учитывая тенденцию программера к overestimate и underestimate. Задача должна занимать от 3 до 5 дней, не больше. Т. е. мы должны сделать подробную декомпозицию ***перед*** началом High Level дизайна. Кстати, эта фаза не должна занимать много времени! Крутись как хочешь.

это не совсем верно , на этом этапе _НЕ_ДЕЛАЕТСЯ_ планирование задач. Здесь мы планируем время которое будет потрачено на работу над требованиями и HLD. После HLD _ВСЕГДА_ следует перепланирование, мало того если во время рабаты над любой из фаз возникает необходимость корректировки планов, то это должно делать, если это не делается то проблема не в м(М)етодологии , а в чём то в другом .

Чеклисты — опять же, при review/inspection они используются только в качестве подмоги и использование здравого смысла не исключается, если это не так, то смотри выше .


G>2) High level design. Дизайн в обычном понимании этого слова.
G>3) HLD Review. Начинаем ловить дефекты. Отмечаем их в тулзе. Потраченное время тоже отмечаем. Дефекты ловим по чеклисту!


G>4) Detailed Design. Сюрприз! Все привыкли считать это кодированием, а это таки дизайн!
G>Это: определения всех типов (классов), тела функций на псевдокоде будьте любезны! Ошибка в алгоритме сортировки — не предусмотрели граничные условия — это ошибка дизайна, а не реализации.
G>5) DD Review
G>(!!!) Отлаживаем алгоритмы на псевдокоде в Exeleвских таблицах (т. е. в уме), как студенты-первокурсники! Этого, правда, никто не делает. А так, — стандартно: чеклисты.
пугаешь и сам же говоришь что это не так

G>6) Coding — здесь все ясно, хотя есть нюанс. Дело в том, что после 2-х дизайнов список задач, стотавленный на фазе 1 может измениться, причем серьезно. И не торопитесь окинуть свой код взглядом с птичьего полета, с целью понять, что же за фигню вы написали (что многие делают с периодичностью 5 минут). Этого делать нельзя ни в коем случае (но все делают — куда деваться-то), иначе поплывут статистики! Только в пункте 7)
G>7) Code Review. Взял чеклист составленный из предыдущих ошибок, и вперед!
G>8) Compilation. Отмечаем ошибки компиляции. Считаем, какой процент из них мы отловили на предыдущей фазе. Сокрушаемся и качаем головой. Да, хреновый у нас review yield!

да, review после компиляции действитльно не совсем естествено , но каким способом можно опредилить качество проделанного review как можно раньше?

G>9) Testing. Отмечаем все ошибки, и время которое потрачено на исправление. Если суммарное время на исправление сильно меньше времени тестирования — вздрючат.
не замечал , в конце концов все основные ошибки по идее должны были найдены раньше и если это не так, то есть повод задуматься: а что же буде дальше

G>10) Postmortem. Вбиваем в тулзу всякую шнягу, чтобы ей было приятно (риальное кол-во строк кода). Иначе вздрючат .
если не вколотил данные, то как планировать в будущем основывая на "накопленном" опыте?

G>Если проанализировать критерии входа/выхода для фаз, мы поймем что имеем дело с классической waterfall моделью, где фазы привязанны к виду активности (все что они несут про возможность использования PSP с инкрементальными моделями — очередной случай так называемого вранья). Что нам известно про waterfall? Если кратко, что сейчас не имеет смысла его использовать (ссылки на литературу могу привести отдельно, не помню сейчас).
я думаю, что это не совсем так, что мешает человеку совершать все перечисленные операции на каждом витке спирали? ведь PSP/TSP не процесс/модель раработки-развития-сопровождения программных продуктов, а средство для планирования, прогнозирования и анализа качества проведённых работ.

А вообще при использовании PSP/TSP, как в прочем и любой другой технологии на первом месте находится человечиский фактор . Любую хорошую идею можно извернуть так, что мало не покажеться, а можно ведь и наоборот .

Что каксается меня, то PSP прсто немного утомляет , хотя любой труд он вреден для здоровья и тут ничего не поделаешь , разве что почаще

Здравствуйте, sardonyx, Вы писали:

S>Здравствуйте, Gaperton, Вы писали:

S>Всё таки позволю себе вступиться за процесс, хотя я _НЕ_ЯВЛЯЮСЬ_ его сторонником

G>>1) Planning
G>>Планируем размер в LOC с разбиением по мелким (!) задачам, тулза выдает прогноз по времени на основании персональной статистики, учитывая тенденцию программера к overestimate и underestimate. Задача должна занимать от 3 до 5 дней, не больше. Т. е. мы должны сделать подробную декомпозицию ***перед*** началом High Level дизайна. Кстати, эта фаза не должна занимать много времени! Крутись как хочешь.

S>это не совсем верно , на этом этапе _НЕ_ДЕЛАЕТСЯ_ планирование задач. Здесь мы планируем время которое будет потрачено на работу над требованиями и HLD. После HLD _ВСЕГДА_ следует перепланирование, мало того если во время рабаты над любой из фаз возникает необходимость корректировки планов, то это должно делать, если это не делается то проблема не в м(М)етодологии , а в чём то в другом .

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

S>Чеклисты — опять же, при review/inspection они используются только в качестве подмоги и использование здравого смысла не исключается, если это не так, то смотри выше .
Есть такое дело. Только вот тут как раз начинает действовать человеческий фактор. Если ты эту "подмогу" не используешь, получишь гнездюлей от манагера. А вот за отсутствие здравого смысла на инспекции тебя не накажут. Что и подтверждается качеством и количеством issues на реальных инспекциях. Али что не так?

G>>2) High level design. Дизайн в обычном понимании этого слова.
G>>3) HLD Review. Начинаем ловить дефекты. Отмечаем их в тулзе. Потраченное время тоже отмечаем. Дефекты ловим по чеклисту!


G>>4) Detailed Design. Сюрприз! Все привыкли считать это кодированием, а это таки дизайн!
G>>Это: определения всех типов (классов), тела функций на псевдокоде будьте любезны! Ошибка в алгоритме сортировки — не предусмотрели граничные условия — это ошибка дизайна, а не реализации.
G>>5) DD Review
G>>(!!!) Отлаживаем алгоритмы на псевдокоде в Exeleвских таблицах (т. е. в уме), как студенты-первокурсники! Этого, правда, никто не делает. А так, — стандартно: чеклисты.
S>пугаешь и сам же говоришь что это не так
Да не пугаю, а рассказываю как нас учили. ты же сам знаешь
Аутентичный PSP это то чему учат, а не то на чем работают.

G>>6) Coding — здесь все ясно, хотя есть нюанс. Дело в том, что после 2-х дизайнов список задач, стотавленный на фазе 1 может измениться, причем серьезно. И не торопитесь окинуть свой код взглядом с птичьего полета, с целью понять, что же за фигню вы написали (что многие делают с периодичностью 5 минут). Этого делать нельзя ни в коем случае (но все делают — куда деваться-то), иначе поплывут статистики! Только в пункте 7)
G>>7) Code Review. Взял чеклист составленный из предыдущих ошибок, и вперед!
G>>8) Compilation. Отмечаем ошибки компиляции. Считаем, какой процент из них мы отловили на предыдущей фазе. Сокрушаемся и качаем головой. Да, хреновый у нас review yield!

S>да, review после компиляции действитльно не совсем естествено , но каким способом можно опредилить качество проделанного review как можно раньше?
А ЗАЧЕМ нам это определять как можно раньше? Что за маниакальные идеи? И как ты это определишь, у тебя может быть есть корелляция между ошибками компиляции и дефектами? У меня нет, и всей нашей группы не было, и у всех моих знакомых ее нет. Да и нет никаких разумных оснований, чтобы review yield, посчитанный таким образом имел какой-то смысл (даже при наличии корелляции) — ведь синтаксические ошибки в отличии от нормальных ловятся не напрягая мозгов. Совсем.

G>>9) Testing. Отмечаем все ошибки, и время которое потрачено на исправление. Если суммарное время на исправление сильно меньше времени тестирования — вздрючат.
S>не замечал , в конце концов все основные ошибки по идее должны были найдены раньше и если это не так, то есть повод задуматься: а что же буде дальше
И на курсах не замечал? Тебе повезло. А у нас задачи заворачивали. А еще да прибудет с нами сила отличать основные ошибки от второстепенных и не задумываться слишком много

G>>10) Postmortem. Вбиваем в тулзу всякую шнягу, чтобы ей было приятно (риальное кол-во строк кода). Иначе вздрючат .
S>если не вколотил данные, то как планировать в будущем основывая на "накопленном" опыте?
Никак. Это я стебусь.

G>>Если проанализировать критерии входа/выхода для фаз, мы поймем что имеем дело с классической waterfall моделью, где фазы привязанны к виду активности (все что они несут про возможность использования PSP с инкрементальными моделями — очередной случай так называемого вранья). Что нам известно про waterfall? Если кратко, что сейчас не имеет смысла его использовать (ссылки на литературу могу привести отдельно, не помню сейчас).
S>я думаю, что это не совсем так, что мешает человеку совершать все перечисленные операции на каждом витке спирали? ведь PSP/TSP не процесс/модель раработки-развития-сопровождения программных продуктов, а средство для планирования, прогнозирования и анализа качества проведённых работ.
А вот тут, батенька, вы и не правы. Откройте лежащую у вас (или не у вас на столе книжку про RUP и еще разок посмотрите их инкрементальный цикл разработки, и сравните. Waterfall не запрещает итерации. Он даже возвраты на фазу назад не запрещает. Проблема waterfall именно в том, что фазы привязаны к виду активности (чего нет в современных инкрементальных моделях), и ты не можешь начать следующую не закончив предыдущую. Что мы имеем и в PSP, причем персональное review выделено в отдельную фазу, что совсем противоестественно.

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

S>А вообще при использовании PSP/TSP, как в прочем и любой другой технологии на первом месте находится человечиский фактор . Любую хорошую идею можно извернуть так, что мало не покажеться, а можно ведь и наоборот .
Но некоторые хорошие и красивые идеи предрасположенны и сами подталкивают к тому, чтобы их извернули. А хорошо-ли это?