Комментарии на запись: Требования к ПИ и их отсутствие. http://blog.shumoos.com/archives/165 Блог об управлении, модульных тестах, аналитике и пр. Sun, 20 May 2012 18:22:44 +0000 http://wordpress.org/?v=2.0.4 от: serguei_tarassov http://blog.shumoos.com/archives/165#comment-238 Sun, 01 Mar 2009 15:20:15 +0000 http://blog.shumoos.com/archives/165#comment-238 Уважаемый тёзка, случайно набрел на ваш журнал. Много интересных материалов, они тематически перекликаются с тем, что я и мои коллеги пишем на <a href="http://arbinada.com" rel="nofollow">арбинаде</a>. Предлагаю каким-нибудь образом давать перекрестные ссылки :) Например, могу вставить ваш RSS в агрегатор новостей. По поводу требований к ПИ. Вам не кажется, что сейчас повсеместно формальные методы пытаются заменить т.н. "кейсами" ? Не только в ИТ, а вообще везде. Уважаемый тёзка, случайно набрел на ваш журнал. Много интересных материалов, они тематически перекликаются с тем, что я и мои коллеги пишем на арбинаде.
Предлагаю каким-нибудь образом давать перекрестные ссылки :)
Например, могу вставить ваш RSS в агрегатор новостей.

По поводу требований к ПИ. Вам не кажется, что сейчас повсеместно формальные методы пытаются заменить т.н. “кейсами” ? Не только в ИТ, а вообще везде.

]]> от: SALar http://blog.shumoos.com/archives/165#comment-225 Tue, 28 Oct 2008 09:29:58 +0000 http://blog.shumoos.com/archives/165#comment-225 > 99% руководителей вам скажут, что это просто “попадалово”. Более того, так обычно и бывает. > Сама идея то понятная - просто доведена до крайности. Не совсем так. Это бизнес требования, которые нужно трассироваться на стандарт проектирования и прототипы интерфейсов, а затем на методику тестирования. Но если на эти требования совсем забить, то получится как всегда. Еще момент. Лучше работать не с ограничениями, а с функцией потерь Тагути, но до этого нам пока как до луны. > 99% руководителей вам скажут, что это просто “попадалово”.
Более того, так обычно и бывает.

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

Еще момент. Лучше работать не с ограничениями, а с функцией потерь Тагути, но до этого нам пока как до луны.

]]> от: Dart http://blog.shumoos.com/archives/165#comment-224 Tue, 28 Oct 2008 07:44:25 +0000 http://blog.shumoos.com/archives/165#comment-224 Для того, чтобы выделенные жирным фразы попали в подписанный контракт нужен невероятный уровень доверия между заказчиком и исполнителем. 99% руководителей вам скажут, что это просто "попадалово". Либо нужно очень четко прописать методику тестирования. Особенно про три ошибки :). Я бы на месте заказчика с помощью этой фразы нашел бы способ не заплатить исполнителю. Посадил бы "своего" человека, который будет специально делать 4 ошибки в 10'000 платежек и выторговал бы себе скидку в NN% за доп. соглашение в котором этот пункт договора будет отменен :). Сама идея то понятная - просто доведена до крайности. Лучшим вариантом, на мой взгляд, является утверждение прототипа пользовательского интерфейса. Для того, чтобы выделенные жирным фразы попали в подписанный контракт нужен невероятный уровень доверия между заказчиком и исполнителем. 99% руководителей вам скажут, что это просто “попадалово”.
Либо нужно очень четко прописать методику тестирования. Особенно про три ошибки :) . Я бы на месте заказчика с помощью этой фразы нашел бы способ не заплатить исполнителю. Посадил бы “своего” человека, который будет специально делать 4 ошибки в 10′000 платежек и выторговал бы себе скидку в NN% за доп. соглашение в котором этот пункт договора будет отменен :) .
Сама идея то понятная - просто доведена до крайности.
Лучшим вариантом, на мой взгляд, является утверждение прототипа пользовательского интерфейса.

]]>