Кто-либо работает с Единицами функциональности?
Поскольку ваш create PropertyChangedEventHandler не является частью реального интерфейса INotifyPropertyChanged, привязка не распознает, что было вызвано событие уведомления, поэтому оно не вытаскивает новое значение из TotalPacketsSent. Чтобы сделать обновление привязки, попробуйте что-то вроде этого: Поместите в класс WiresharkFile:
private static WiresharkFile This;
public WiresharkFile()
{
This = this;
}
private static volatile int _totalPacketsSent;
public static int TotalPacketsSent
{
get { return _totalPacketsSent; }
set
{
_totalPacketsSent = value;
OnStaticPropertyChanged(This);
}
}
- Код обработчика:
protected static void OnStaticPropertyChanged(object sender, [CallerMemberName]string propertyName = null)
{
var baseObservable = sender as BaseObservableObject;
if(baseObservable == null) return;
baseObservable.OnPropertyChanged(propertyName);
}
, на мой взгляд, вам не нужен PropertyChangedEventHandler событие в классе BaseObservableObject.
приветствует,
5 ответов
Mike Cohn в его Гибкая Оценка и Планирование полагает, что кадр/с является большим, но трудным разобраться. Он (очевидно), рекомендует использовать историю основанная на точках оценка вместо этого. Я склонен соглашаться с этим как с каждым новым проектом, я вижу преимущества Гибкого подхода все больше.
<час>1) действительно ли это - довольно точный способ сделать оценки? (Я весьма разумен здесь, но просто хочу знать по сравнению с другими методами оценки)
, Насколько точность оценки идет, функциональные точки очень хороши. По моему опыту, они являются великими, но дорогими с точки зрения усилия, включенного, если Вы хотите, делают это правильно. Не то, чтобы много проектов могли предоставить фазу разработки для разбираний в основанных на FP оценках.
2) И усилие требуется стоящий преимущества, Вы выходите из него?
футы в секунду являются большими, потому что они официально распознаны ISO, который дает Вашим оценкам большое доверие. Если Вы работаете над большим проектом для крупного клиента, могло бы быть полезно вложить капитал в официально выглядящие подробные оценки. Но если уровень неуверенности будет большим для запуска с (как другая интеграция поставщиков, унаследованная система, свободные требования и т.д.), то Вы не будете получать в какой-либо степени точность так или иначе так обычно, необходимо просто принять это и повторить оценки позже. Если имеет место, что более дешевый способ сделать оценки (пользовательские истории и точки истории) лучше.
3), Какой тип Единиц функциональности Вы используете?
, Если я понимаю эту часть Вашего вопроса правильно, мы раньше делали оценки на основе Характерных точек, но постепенно отодвигаемый от них почти весь проекты ожидают для тех с особым упором на внутреннюю функциональность.
4) Вы используете какие-либо инструменты для того, чтобы сделать это?
Excel является большим со всеми формулами, которые Вы могли использовать. Используя электронные таблицы Google вместо Excel помогает, если Вы хотите сделать это совместно.
существует также большой инструмент, встроенный к архитектор Sparx Предприятия, который позволяет Вам делать оценки на основе Вариантов использования, которые могли использоваться для оценок FP также.
Я был IFPUG Сертифицированный специалист по Единице функциональности с 2002-2005, и я все еще использую их для оценки бизнес-приложений (веб-и толстый клиент). Мой опыт главным образом с меньшими проектами (1 000 FP или меньше).
я обосновался на Единицах функциональности после использования Точек Варианта использования и Строк Кода. (Я активно работал с методами оценки для 10 + годы теперь).
Некоторые вопросы о Единицах функциональности:
1) действительно ли это - довольно точный способ сделать оценки? (Я весьма разумен здесь, но просто хочу знать по сравнению с другими методами оценки)
Трудно для ответа быстро, поскольку это зависит от того, где Вы находитесь в жизненный цикл (от gleam-in-the-eye до сделанного). Также необходимо понять, что существует больше к оценке, чем точность.
Их самая большая сила - это, когда вместе с историческими данными, они держат хорошо под давлением от лиц, принимающих решения. Путем разделения объема проекта от производительности (h/FP), они приводят к намного более конструктивным переговорам. (Я сначала занялся основанной на метриках оценкой, когда я, веб-программист, должен был убедить персонального друга основателя своей компании и генерального директора возвращаться к своим инвесторам и говорить им, что дата, которую он обещал, была недосягаема. Все мы знали, что это было, но это была история проекта и функциональная калибровка (точки варианта использования собственной разработки в то время), который на самом деле убедил его.
Их преимущество является самым большим рано в жизненный цикл, когда необходимо оценить выполнимость проекта, прежде чем команда была даже собрана.
Вопреки общему убеждению, это не занимает у этого много времени для предложения полезного количества, если Вы знаете то, что Вы делаете. Рядом с типов основной информации (логические файлы) выведенный на начальной встрече клиентов и средней производительности нашей команды, я мог придумать грубое количество (но не более грубый, чем все другие неизвестные на том этапе) и полезная оценка днем.
Метод функциональных точек Объединения с Упрощенным Семинаром Требований и у Вас есть большой подход установки проекта.
, Как только вещи становились серьезными, и мы назначили команду, мы будем тогда использовать Покер Планирования и некоторые другие методы оценки, чтобы придумать независимое число и сравнить два.
2) И усилие требуется стоящий преимущества, Вы выходите из него?
Абсолютно. Я нашел, что подготовка количества отличный способ рассмотреть требования пользовательского уровня цели для непротиворечивости и полноты, в дополнение ко всем другим преимуществам. Это было даже в установке Гибких проектов. Я часто находил подразумеваемые истории, которые пропустил клиент.
3), Какой тип Единиц функциональности Вы используете?
CPM IFPUG (считающий Руководство Методов) 4.2
4) Вы используете какие-либо инструменты для того, чтобы сделать это?
шаблон электронной таблицы Excel мне дал человек, который обучил меня. Вы вставляете файл или атрибуты транзакции, и он делает весь поиск по таблице для Вас.
Как заключительное примечание, НИКАКАЯ оценка не так точна (или более точно, точна), как бухгалтеры хотели бы по причинам, которые были хорошо зарегистрированы во многие другие места. Таким образом, необходимо выполнить проекты способами, которые могут разместить это (три аплодисментов для Гибкого).
, Но оценки все еще жизненно важная часть поддержки принятия решений в деловой среде, и я никогда не хотел бы быть без своих единиц функциональности. Я подозреваю людей, которые называют их "фантазией", никогда не видели их правильно используемый (и я видел их сверхраздутый и неправильно используемый в гротесковой манере, верьте мне).
не понимают меня превратно, FP имеют произвольное чувство им время от времени. Но, для перефразирования Churchill Единицы функциональности являются худшим известным методом оценки раннего жизненного цикла, за исключением всего другие.
Большой hacknot в режиме офлайн теперь, но это находится в книжной форме. У него есть эссе по единицам функциональности: http://www.scribd.com/doc/459372/hacknot-book-a4 , завершая они - фантазия (который я согласовываю с).
у Joel на программном обеспечении есть разумная звуковая альтернатива, названная основанное на доказательстве планирование , что [по крайней мере 114] звуки как он могли бы работать....
Из того, что у меня есть исследование о Единице функциональности (один из моего учителя был высоко вовлечен в процесс теории единицы функциональности), и он не смог ответить на все наши ответы. Сбой единицы функциональности во многих путь, потому что это - не потому что Вы имеете что-то чтение или пишете, что можно оценить правильно. У Вас мог бы быть результат 450 точек функций и некоторые из них, единица функциональности возьмет ответ 1 часа, некоторые займут 1 неделю. Это - метрика, которую я никогда не буду использовать снова.
- No, потому что какое-то конкретное требование может иметь произвольное усилие на основе того, насколько точный (или неточный) автор требования, и уровень опыта эксперта единицы функциональности.
- No, потому что администрирование неточных дериваций абстрактной функциональности не приводит ни к какой надежной оценке.
- Ни один, если я могу помочь ему.
- Инструменты? Для единиц функциональности? Как насчет Excel? Или Word? Или Блокнот? Или Edlin?