Критерии качества работы с требованиями(Прочитано 28753 раз)
Re: Критерии выявления Ответ #15 : 17 Мая 2009, 15:57:08
Считаю, что критерии успешности сбора требований:
  • Инвестору/владельцу бюджета/владельцу проекта понятно в первом приближении, "что, как и для кого" предлагается сделать, сколько вложить и за сколько это окупится
  • Архитектору понятно, что проектировать, разработчикам - что разрабатывать, менеджеру проекта - как разбить функциональность по итерациям, когда, в каком порядке и что выдавать, тестировщикам - как понять, что изделие работает правильно, тех. писателям - как объяснить, как изделием пользоваться
  • Продавцам понятно, как изделие продавать (и у них это получается), инженерам понятно - как это внедрять (и они не краснеют перед представителями заказчика), заказчики готовы сотрудничать, покупают тех. поддержку.


По-моему, критерий прост. Аналитик - часть команды. Если он смог понять, что нужно потребителям и донести это до остальных, и остальные не подкачали - решение на базе продукта покупают и используют. А если сделали не то, что было нужно - это сразу видно.
Вот как раз разрыв между 1 и 2 критерием получается. Заказчику понятно, что будет сделано, и Архитектору понятно - что делать, но... к сожалению, Архитектор понял совсем по другому нежели Заказчики, и мы получаем ситуацию описанную в самом конце :(
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Критерии выявления Ответ #16 : 17 Мая 2009, 18:21:12
Чтобы этого не происходило, показывают, обсуждают и согласуют друг с другом артефакты. Как вариант - просят "рассказать своими словами, как понял, что сделать нужно".

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

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

А сильная формализация требований и процесса работы с ними IMHO может такому взаимодействию между людьми только мешать. Чем больше и сложнее документ - тем хуже его читают и понимают.



Re: Критерии выявления Ответ #17 : 17 Мая 2009, 18:57:20
Саша,

Это все понятно, просто вопрос был про критерии. А твои критерии, к сожалению, не подходят :(
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Re: Критерии выявления Ответ #18 : 18 Мая 2009, 00:13:11
IMHO исходная тема несколько надуманная, как уже было отмечено ранее выступившими коллегами. Скорее всего это от желания застраховаться от недостаточной компетенции, типа придет дядя с линейкой и всех проверит. Поэтому присоединюсь к авторам, высказавшимся в дуже - учиться надо...

А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
В данном случае: М - модель, описанная требованиями, S - предметная область, A - оценка трудоемкости реализации, например.

Вторая цитата:
Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели.
Вот Вам и критерий.

Лью воду...



Re: Критерии выявления Ответ #19 : 18 Мая 2009, 03:18:02
А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
В данном случае: М - модель, описанная требованиями, S - предметная область, A - оценка трудоемкости реализации, например.
Хороший пример, спасибо. Мне кажется, оценка трудоемкости реализации не может выступать в качестве точности модели, а служит показателем того сколько требуется усилий аналитика определенной квалификации на построение модели с заданной точностью "А".

Вторая цитата: Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то мы говорим, что модель не достигла своей цели. Вот Вам и критерий.
Как нам понять, что мы достигли заданного уровня точности?
Моделью для разрабатываемой системы являются классы требований (бизнес-требования, пользовательские, функциональные и т.п.) и их представление (диаграммы), точность характеризуется собираемостью требований того или иного класса и написанием тех или иных диаграмм, их детализацией. Формально, требование о нагрузочном тестировании написано, считается, что мы построили модель необходимого качества, так? Hо реально, требование не отражает действительность.
Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?
Суха мой друг теория везде, а древо жизни пышно зеленеет [Гёте]



Re: Критерии выявления Ответ #20 : 18 Мая 2009, 12:09:08
А то теме... В одной научной книжке про модели было написано следующее:
М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А.
Написано в книжке Дэвида А. Марка и Клемента МакГоуэн "Методология структурного анализа и проектирования SADT", а именно Методология структурного анализа и проектирования SADT. Глава 1. Системы и модели/ 1.2. Модель отвечает на вопросы



Re: Критерии выявления Ответ #21 : 18 Мая 2009, 12:39:02
Что хочется увидеть, например, такой критерий - "требование не должно содержать сущностей, которые могут быть уточнены" - вместо "одновременного сеанса работы на 20 АРМ", использовать "одновременный ввод данных в зону актирования". Или это совсем не обязательно?

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



Re: Критерии выявления Ответ #22 : 18 Мая 2009, 12:43:05
Хороший пример...

Как нам понять...

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

По второму.
Тупо задавайте вопросы: а как происходит то-то и то-то? куда пойдет такая-то информация? какие связи будут задействованы в таком-то случае? и т.д.
Конечно для этого желательно знать минимум две предметных области: конкретную, для которой делается система, и область разработки ПО. Как раз требование о необходимости нагрузочного тестирования в первопричине может иметь источники в опыте работы во второй из этих предметных областей. Вряд ли заказчик настолько хорошо осознает зачем это надо, скорее положится на Вас как на специалистов в своем деле.
Так что не надо ждать от заказчика формулировки всего-всего-всего, нужно и свою голову тоже включать и предлагать ему не набор диаграмм и документации, а РЕШЕНИЕ!

И, наконец, последнее.
Если Вы ждете критериев, типа упомянутого (не содержать того, что можно уточнить), то скажу, что это недостижимо. Как Вы определите, в свою очередь, могут быть сущности еще уточнены или нет?

Так что, нет ничего обязательного в этой деятельности, есть наборы практик, инструментов, которые будучи использованы грамотно и по своему назначению с большей вероятностью приведут к успешному результату. Однако если те же практики и инструменты использовать формально (типа, вот какую крутую методологию мы используем со всеми ее элементами и закорючками), то можно и самому запутаться и задачу не решить, соответственно, результат получится прямопротивоположный.
Я, кстати, видел много случаев, когда человек, с виду не владеющий методологиями, вполне последовательно и качественно решал именно задачу. На вопрос "а ведь Вы использовали такие-то элементы такой-то методологии" он отвечал что-то в духе "а выручалочка-то вот она где", постукивая себя по лбу.

Поэтому не увлекайтесь формализмом - решайте задачу!
« Последнее редактирование: 18 Мая 2009, 14:28:44 от Водолей »
Лью воду...



Re: Критерии выявления Ответ #23 : 18 Мая 2009, 12:44:30
To Galogen
Это разве важно? Гораздо важнее уметь правильно и по месту применить :о))

P.S. А еще существуют цитатники великих и просто известных...
Лью воду...



Re: Критерии выявления Ответ #24 : 18 Мая 2009, 14:29:16
не туда наблюдаете :о))
Лью воду...



Re: Критерии выявления Ответ #25 : 02 Июня 2009, 19:23:12
А как Вам идея выставления оценок по требованию другими Аналитиками ревьюирами, Разработчиками, Тестерами, Внедренцами, Заказчиками и т.д.?
Что-то типа голосования за качество требование от 2 до 5. И делать это необязательным, а just for fun.

Из этого голосования можем получить вот что:
1. Кол-во обращений к Требованию
2. Ценность требования (если за требование проголосовали, то это действительно очень важное требование)
3. Среднюю оценку работы Аналитика за период.

Только данный механизм должен быть легок в использовании и скорее всего его имеет смысл использовать только в СУТ.
« Последнее редактирование: 02 Июня 2009, 19:24:59 от bas »
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



Вот еще некоторые мысли по оцениванию работы Аналитика:
http://www.requirementsnetwork.com/node/620
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



По поводу оценки требований другими участниками команды.

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

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

Тем более, возможность отрицательно оценивать требования может быть использована в "подковёрных играх": хочется избавиться от системного аналитика, у которого есть "особое мнение" - оцените все его требования плохо.

Зачастую самые ценные требования - самые неприятные, спорные (трудно изложить и придумать за разработчиков с архитекторами хорошее решение) и трудно реализуемые. А живой и актуальный draft лучше отлично сформулированного, но никому не нужного требования.

IMHO лучше уж учитывать результаты "разбора полётов", после того, как обнаруживается, что какая-то часть программы не делает того, что от неё ожидают. Но и тут дело может быть в требованиях, а может быть в тысяче других причин.
« Последнее редактирование: 11 Июня 2009, 00:43:03 от AlexTheRaven »




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19