Как Вы измеряете маленький, большой, очень большой проект? [закрытый]
Вот пример:
def cal_hist(gray_img):
hist = np.zeros(shape=(256))
(h,w) = gray_img.shape
for i in range(w):
for j in range(h):
hist[gray_img[j,i]] += 1
return hist
img = cv2.imread("1.jpg",0)
plt.plot(cal_hist(img))
plt.show()
7 ответов
Я сказал бы, что это - количество требуемого усилия по разработке. Взятие команды шести разработчиков:
- Маленький проект - до 6 месяцев
- Большой проект - 6-18 месяцев
- Очень большой проект - 18 + месяцы
У всех будет различное мнение все же.
Править
Я думал о том, как те значения изменят для 1 разработчика "команду". Я думаю, что они были бы вроде:
- Маленький проект - до 1 месяца
- Большой проект - 1-3 месяца
- Очень большой проект - 3 + месяцы
Это, кажется, предполагает, что для небольших чисел разработчиков эмпирическое правило для размера проекта могло бы быть:
- Маленький проект - до 1 месяца на разработчика
- Большой проект - 1-3 месяца на разработчика
- Очень большой проект - 3 + месяцы на разработчика
Я сомневаюсь, что это масштабируется вне приблизительно 6 разработчиков, хотя, поскольку количество каналов передачи начинает перетаскивать на потенциальном времени разработки каждого человека. Эффективно ведя к меньшему количеству работы, сделанной в месяц на разработчика больше людей, Вы имеете в своей команде.
Я обычно измерял бы размер проекта на времени, которое потребуется для завершения, но другие люди могут отличаться.
Кривая обучения - количество времени, которое новый разработчик занимает для знакомства с кодом, прежде чем он сможет сделать что-то полезное для содействия ему.
Это могла быть комбинация вещей:
- оценка. единицы функциональности - размер кода
- точки интеграции - с внешними системами
- сложность приложения (веб-приложения обычно менее сложны, чем встроенные системы - сравнивает веб-сайт с программой для ракеты),
- деловые круги включили - одобрение необходимости небольшого изменения 20 подразделений могло быть большим усилием
Вышеупомянутое определило бы размер проекта - число людей определяет временную шкалу и добавляет сложность
Я не начал бы знать, как оценить строки кода, ожидаемые на проекте. Документация..., что это ;) Таким образом для меня, ни одной из тех вещей.
Я, вероятно, считал бы главные функциональные области и посмотрел бы на общее представление о количестве экранов/страницы и также общее представление о количестве таблиц базы данных. Сложность базы данных могла бы быть хорошим индикатором на большом количестве проектов, я думаю.
Это - своего рода левая идея, но когда я работаю над проектом, я предусматриваю его как являющийся
1) Дом = маленький проект
2) supermarkert = проект среднего размера
3) Аэропорт = большой проект
Вы отчасти знаете людьми вокруг Вас, что Вы и они делаете, и Ваши шансы на успех, которые из трех Вы идете.