Re[2]: Разработка при ограниченном человекоресурсе.
От: Maxim S. Shatskih Россия  
Дата: 23.11.07 13:59
Оценка:
G>Вот, собственно. Каждый показатель из пяти может быть ограничен. Собственно, у тебя ошибка — Сроки должны в знаменателе стоять.

Ага, я просто неверно употребил слово "Сроки". В моей формуле имелось в виду — ЖесткостьТребованийПоСрокам, которая, понятно, имеет размерность ( время^-1 ).

G>Кроме того, формула не учитывает влияние такого важного фактора, как применение интеллектуальной собственности сторонних производителей


Мне это пришло в голову при написании исходного поста, но я понял, что у меня крайне малый опыт такого использования, и потому мне почти нечего сказать на эту тему.

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

G>Хочу на всякий случай пояснить значение термина "качество" в управлении проектами, чтобы под ним не понимали черт знает что.


Ага, тут уже посчитали спагетти-код низким "качеством".

G>Defects/KLOC. "Жертвовать качеством" — это означает экономить на тестировании, откладывая его на поздние этапы, не более того.


Я это и имел в виду. На тестировании, на аккуратном кодировании (скажем, нет нормальной обработки ошибок).

G>Можно. См правило "квадрат риск-приоритет", которое вполне указывает конкретно, продумывание чего можно посылать.


Низкий приоритет и высокий риск?

G>+1. Ты о предварительном проектировании, конечно.


И о кодировании тоже. Если при кодировании не думают о corner cases, об обработке ошибок и нештата — то все это потом неизбежно всплывет в тестировании или у кастомера. Причем некоторые баги имеют очень высокую цену поиска.

G>Можно съекономить на тестировании режимов работы юнитов, которые не задействованы в системных сценариях, разрешенных к тестированию. А вот Ассерты — это хорошо, это дешево.


Даже в релизе ассерты можно оставить. Естественно, они иначе реализуются — например, в виде сообщения в UI или в event log такого же вида, как и невозможность открыть указанный файл. Internal Error %d. У микрософта в компиляторе такое

Если потом тестеры или кастомер на нее жалуются — то я уже знаю, что у меня где-то _баг_, который поймался на ассерте.

G>+1 Они у нормальных людей всегда идут за борт ИМХО.


Ну как же... бывают люди, которые от этого просто в восторге, или, например, в восторге от предельно строгого следования ООП или еще какой парадигме. Время разработки от такого подхода раздувается в разы.
Занимайтесь LoveCraftом, а не WarCraftом!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.