Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Виталий Григораш от 09 Февраля 2010, 15:31:21
-
Существуют ли инструменты (методы, техники), которые на ранних этапах проекта позволяют предсказать и оценить процент неучтенных требований?
-
У нас есть табличка с взаимосвязами (что без чего работать не будет) по которой можно выявить ключевые неучтенные требования.
-
У нас есть табличка с взаимосвязами (что без чего работать не будет) по которой можно выявить ключевые неучтенные требования.
меня больше интересует "тыкание пальцем в небо", которое может быть обосновано какими-либо показателями, например, компетентностью аналитика, масштабом проекта, спецификой предметной области, особенностями заказчика и тп...
Все таки анализ покрытия это больше механизм оценки качества требований.
-
Существуют ли инструменты (методы, техники), которые на ранних этапах проекта позволяют предсказать и оценить процент неучтенных требований?
Смотря с какой точностью. ;D
(http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/70000/5000/900/75988/75988.strip.gif)
-
Смотря что считать "ранними этапами":)
Если проект новый на 100% (компнда, клиент) - проще кинуть монетку.
-
Виталий, а на базе чего ты планируешь этот прогноз.
Просто, ты начинаешь скажем проект, и уже через неделю его начала хочешь знать каков ожидается % неучтенных требований? Как это можно сделать? Назови любую цифру в пределах от 0 до 100 - вдруг попадешь!
То есть для прогнозирования нужны какие-то данные. Результаты например предыдущих проектов, или результаты чужих проектов. Тут нужна определенная представительная выборка (генеральной называется)
Далее можно уже посмотреть в сторону вариационных временных рядов например, подумать об апостериорной вероятности, что-нибудь от Байеса позаимствовать, натравить на все это нейронную обученную сеть.
Если исходить из ранних результатов проекта - ну скажем были выявлены требования и были пропущены, что показала вторая итерация, то можно начать экстраполяцию разными методами, исходя из этих результатов.
На каждой следующей итерации добавлять результаты предыдущих всех - типичная ситуация прогноза и коррекции. Можно установить некие закономерности, используя детерминатный анализ, регрессионный анализ и т.п. штуки
Другой вариант - это использование некоторых эмпирических данных (вопрос есть ли они?) с последующей коррекцией по ходу итераций
-
Если проект новый на 100% (компнда, клиент) - проще кинуть монетку.
Монетка это тоже инструмент, только им надо уметь пользоваться :)
-
Виталий, а на базе чего ты планируешь этот прогноз.
Просто, ты начинаешь скажем проект, и уже через неделю его начала хочешь знать каков ожидается % неучтенных требований? Как это можно сделать? Назови любую цифру в пределах от 0 до 100 - вдруг попадешь!
То есть для прогнозирования нужны какие-то данные. Результаты например предыдущих проектов, или результаты чужих проектов. Тут нужна определенная представительная выборка (генеральной называется)
Далее можно уже посмотреть в сторону вариационных временных рядов например, подумать об апостериорной вероятности, что-нибудь от Байеса позаимствовать, натравить на все это нейронную обученную сеть.
Если исходить из ранних результатов проекта - ну скажем были выявлены требования и были пропущены, что показала вторая итерация, то можно начать экстраполяцию разными методами, исходя из этих результатов.
На каждой следующей итерации добавлять результаты предыдущих всех - типичная ситуация прогноза и коррекции. Можно установить некие закономерности, используя детерминатный анализ, регрессионный анализ и т.п. штуки
Другой вариант - это использование некоторых эмпирических данных (вопрос есть ли они?) с последующей коррекцией по ходу итераций
Эд, я пока ничего не планирую, просто захотелось узнать. Статистика по предыдущим проектам - тоже механизм. Способы ее обработки это уже другой уровень абстракции :)
Просто статистику такую почти никто не собирает и мало кто делает анализ проектов после их завершения (удачного или не очень :))
-
Самый простой механизм - это собирать данные по завершенным проектам и мерить отношение первоначальных требований к конечным.
-
Эд, я пока ничего не планирую, просто захотелось узнать. Статистика по предыдущим проектам - тоже механизм. Способы ее обработки это уже другой уровень абстракции :)
Просто статистику такую почти никто не собирает и мало кто делает анализ проектов после их завершения (удачного или не очень :))
Тогда ответ на твой вопрос очевиден - ткни пальцем в небо, результат тот же!
-
Существуют ли инструменты (методы, техники), которые на ранних этапах проекта позволяют предсказать и оценить процент неучтенных требований?
Для какой цели нужна такая оценка?
-
Для какой цели нужна такая оценка?
Для исследовательской, а далее для сокращения тех самых неучтенных требований
-
У нас в компании согласно статистике средний проект обычно оказывается недооцененным на 30%. Из них, полагаю, 20% - это из-за бестолковой организации и разных форс-мажорных обстоятельств. А 10% - это как раз то, о чем вы спрашивали.
При планировании работ следует иметь в виду, объем требований в поцессе реализации увеличится примерно на 10% от оценки, так как при разработке обязательно будут всплывать разные нюансы. Это при условии, что заказчик имеет достаточно систематизированное представлеие о реализуемой системе, а аналитик по максимуму использует аналогии и не является изобретателем велосипеда.
Если одно из этих условий нарушается - умножаем наш процент на 2. Если оба условия нарушены - умножаем на 4.
Надеюсь, что смогла вам немного помочь.
-
Мне кажется, что знания в начале проекта о том, какой процент требований окажется неучтенным практически ничего не дает, да и вряд ли поможет улучшить навыки/избежать ошибок. Это скорее поможет в каком-то виде учесть риски, не более того. Да и то для учета этих рисков можно взять какую-то примерную цифру вроде 30% и от нее исходить, так как более точно и не надо для рисков.
На мой взгляд, что действительно может помочь улучшить качество требований, улучшить процессы связанные с анализом и повысить профессиональные навыки, так это сбор некоторого набора метрик во время проекта и их тщательный анализ во время и после проекта.
У меня была идея собирать следующие метрики:
1. Кол-во требований в начале проекта с разбивкой по типам
2. Кол-во требований которые были добавлены во время проекта, опять же с разбивкой по типам
3. Кол-во требований которые были изменены во время проекта и почему(выделить некий ряд основных причин)
4. Кол-во требований которые были удалены/отменены во время проекта и почему. Если у требований есть оценки трудоемкости (с точки зрения имплементации разработчиками), то наверное это тоже может быть интересным для анализа – посмотреть не только количественно, но еще и объемно.
5. Кол-во дефектов от тестировщиков связанных с требованиями (если есть возможность то и линковать дефекты непосредственно к требованиям)
6. Так же можно попросить разработчиков и тестировщиков выставлять оценки требованиям по какой-нибудь простой шкале от 1 до 5 или от 1 до 3
Посмотреть какие конкретно требования были изменены наибольшее кол-во раз, проанализировать почему именно эти требования были изменены больше всего?
Еще нашел интересные идеи про синтаксический анализ самих требований на предмет различных слов и выражений влияющих на качество, таких как "может", "много", "мало", "быстро" и т.д.
Еще будет интересно сравнить размер требования в строках и оцененный разработчиками effort по имплементации этого требования в жизнь, думаю в большинстве случаев здесь должна быть прямая взаимосвязь и если требование краткое, а разработка занимает несколько дней или недель, то тут явно что-то не так с полнотой описания.
А вы собираете какие-нибудь метрики связанные с требованиями?
-
На мой взгляд, что действительно может помочь улучшить качество требований, улучшить процессы связанные с анализом и повысить профессиональные навыки, так это сбор некоторого набора метрик во время проекта и их тщательный анализ во время и после проекта.
А вы собираете какие-нибудь метрики связанные с требованиями?
Пока не собираем, но планируем. Часть метрик можно вытащить из базовых версий требований, например в Sparx EA.
Также кроме количественных показателей интересно собирать качественные показатели, которые описать количественно без перевода в отн. единицы не получится. В дополнении к метрикам самих требований, можно собирать метрики в процессе согласования, оценивать стоимость согласования, время и другие показатели.
-
Это скорее поможет в каком-то виде учесть риски, не более того. Да и то для учета этих рисков можно взять какую-то примерную цифру вроде 30% и от нее исходить, так как более точно и не надо для рисков.
Риск помимо процентной оценки должен быть идентифицирован и описан. Если просто сказать - у нас будет 30% рисков, то это точно ничего не даст, кроме дискуссий :)
-
Я имел ввиду, что знание о том, что у нас заведомо будет 30% неучтенных требований из практической значимости дает только возможность учесть риск "Риск: Порядка 30% требований не было учтено, что скорее всего приведет к изменению начального объема работ на Х человеко-дней. Влияние: Х дней команды. Действие: Необходимо запланировать ревью требований тогда-то, необходимо заложить резерв в план проекта на анализ и имплементацию неучтенных требований в размере Х дней команды." Ну или что-то в этом роде. Тоесть это знание помогает для планирования, но не для улучшения :-)
-
Еще нашел интересные идеи про синтаксический анализ самих требований на предмет различных слов и выражений влияющих на качество, таких как "может", "много", "мало", "быстро" и т.д.
Я бы еще добавил к этому списку слова "все" и "любой". Количество последующих изменений прямо пропорционально количеству этих слов.
Еще будет интересно сравнить размер требования в строках и оцененный разработчиками effort по имплементации этого требования в жизнь, думаю в большинстве случаев здесь должна быть прямая взаимосвязь и если требование краткое, а разработка занимает несколько дней или недель, то тут явно что-то не так с полнотой описания.
ИМХО, тоже очень хороший показатель.
-
Читали про "синдром неоткрытых руин" у Леффингуэлла? Вот это оно самое.