Мы должны отслеживать дефекты в вещах кроме кода? [закрытый]
Вы можете попробовать этот подход: https://github.com/Midnighter/nadist , в качестве альтернативы вы можете использовать _chk_weights с nan_screen=True, как описано здесь в метапертуре здесь https: / /github.com/scipy/scipy/issues/3870, надеюсь, это поможет.
Я обнаружил, что Midnighter ранее опубликовал ту же проблему в стеке потока: Рассчитать попарно расстояние в scipy с отсутствующими значениями . Там есть некоторые другие решения, но, поскольку он перешел к его цитонизации, держу пари, что они были не лучшими.
9 ответов
Да, отследите их всех.
Документация, документы дизайна, требования, и т.д.
Я также как удивлен как Вы, когда я слышу "аргументы" против него.
По крайней мере система слежения должна смочь определить, где дефект был найден и какая часть процесса это было введено.
Обычно системы отслеживания ошибок имеют предположение, что они - список вещей, которые должны быть починены или реализованы. Отслеживание ошибок в требованиях или другой документации (например, списки задач) не кажется, что это - то же самое. Это - больше вопрос ведения учета, таким образом, можно отклониться проблемы и оценить при создании меньшего количества из них.
Я отслеживаю их, но за пределами нашей системы отслеживания ошибок.
Да, определенно. Артефакты, окружающие Ваш код - модели, спецификации, doco, информация о требованиях, варианты использования, и т.д. - могут все содержать ошибки, которые влияют на сам код.
Хорошо понятное дело... что-либо, что можно улучшить, сделать, что может для улучшения!
При обработке всего этого, поскольку отслеживание ошибок имеет смысл - мнение будет варьироваться, как Вы отмечаете - но использование одной системы слежения дало бы когерентное большое изображение всего этого, позвольте задачам быть присвоенными и т.д. Возможно, демонстрация, показ слайдов или что-то нацеленное на использование этих систем способами вне отслеживания кода первоисточника - изображения убеждают больше, чем слова.
Я обычно отслеживал источник всех дефектов. Они могут быть зафиксированы в коде, но они не обязательно становятся вызванными этим.
Неправильное требование, неправильно интерпретируемое требование, плохой дизайн, разработчик brainf*rt, плохая документация, неправильно тестирует, пропуская тест, устаревший тест, код, который не делает то, что разработчик делает, инструмент/ошибка компилятора (очень редкий, по моему мнению), проблема системы сборки....
Мне они весь "система, не делает то, что клиент хочет, чтобы она сделала", и все указывают, что что-то должно быть изменено, чтобы заставить ее сделать то, что клиент хочет, чтобы она сделала. Утверждение, является ли это дефектом или функцией, или ошибкой исходного кода или некоторой другой проблемой, отвлекает от решения проблем мне.
Одна важная персона, которую никто, кажется, не упомянул, должна запустить базу данных неприятных запахов и прерываний для использования при выполнении экспертных оценок.
Это - неоценимый ресурс для коллег, на самом деле выполняющих обзор.
Это определенно окупается в долгосрочной перспективе. Это должно также быть живым документом, базой данных, и т.д. который добавляется к как:
- ошибки исправлены
- поскольку коллеги выполняют обзоры, и
- поскольку новая кровь прибывает для присоединения к обеспечению команды (команд) с ними новые знания и опыт.
HTH.
удачи,
Ограбить
aboslutely., если Ваш процесс чувствует себя достаточно хорошо вперед для прослеживания источника, переходят на сторону orgin великого. это помогает клиентам, и разработчики квалифицируют ограничения, в которых они работают.
клиент: разработайте робот для подстригания травы, где все травинки должны быть сокращены к точной универсальной длине
разработчик: мы будем использовать смонтированный перпендикуляр ножниц предназначенного для левой руки детского сада для земли, гарантируют четкие/точные сокращения
QA: сокращения точны.
клиент: почему роботу требуются 6 дней для подстригания травы. нам нужно в в 30 минут или меньше!
ясно отслеживание источника дефекта производительности может помочь в прессовании переговоров и улучшении продвижения процесса.
Мы отслеживаем ошибки в программном обеспечении, ошибки в документах, ошибки в рисунках и запросы на новые возможности все использование того же инструмента дорожки.