Книги
чёрным по белому
Главное меню
Главная О нас Добавить материал Поиск по сайту Карта книг Карта сайта
Книги
Археология Архитектура Бизнес Биология Ветеринария Военная промышленность География Геология Гороскоп Дизайн Журналы Инженерия Информационные ресурсы Искусство История Компьютерная литература Криптология Кулинария Культура Лингвистика Математика Медицина Менеджмент Металлургия Минералогия Музыка Научная литература Нумизматика Образование Охота Педагогика Политика Промышленные производства Психология Путеводители Религия Рыбалка Садоводство Саморазвитие Семиотика Социология Спорт Столярное дело Строительство Техника Туризм Фантастика Физика Футурология Химия Художественная литература Экология Экономика Электроника Энергетика Этика Юриспруденция
Новые книги
Цуканов Б.И. "Время в психике человека" (Медицина)

Суворов С. "Танк Т-64. Первенец танков 2-го поколения " (Военная промышленность)

Нестеров В.А. "Основы проэктирования ракет класса воздух- воздух и авиационных катапульных установок для них" (Военная промышленность)

Фогль Б. "101 вопрос, который задала бы ваша кошка своему ветеринару если бы умела говорить" (Ветеринария)

Яблоков Н.П. "Криминалистика" (Юриспруденция)
Реклама

Совершенный код. Мастер-класс - Макконнелл С.

Макконнелл С. Совершенный код. Мастер-класс — М.: Русская редакция, 2005. — 896 c.
ISBN: 5-469-00822-3
Скачать (прямая ссылка): soversheniykodmasterklass2005.djvu
Предыдущая << 1 .. 316 317 318 319 320 321 < 322 > 323 324 325 326 327 328 .. 426 >> Следующая

позже. Мы восполним недостачу при кодировании и тестировании".
Ну, это вряд ли. В одном обзоре, охватывающем более 300
программных проектов, был сделан вывод, что задержки и
отклонения от графика обычно увеличиваются по мере приближения
к концу проекта (van Genuchten, 1991). Проекты не восполняют
потерянное время позже - они отстают еще больше.
Увеличить команду Согласно закону Фреда Брукса (Fred Brooks)
ввод дополнительных людей на последних стадиях проекта
приводит к задержке его выпол-
660 ЧАСТЬ VI Системные вопросы
нения (Brooks, 1995). Это все равно, что подливать масло в
огонь. Объяснение Брукса выглядит убедительно: новым людям
требуется время на ознакомление с проектом. Их обучение
отнимет время у обученных работников. А само увеличение числа
участников увеличивает сложность и количество вариантов
взаимодействий в проекте. Брукс подчеркивает: то, что одна
женщина может родить ребенка через девять месяцев, не значит,
что девять женщин могут родить ребенка через месяц.
Несомненно, предупреждающий закон Брукса следует принимать во
внимание гораздо чаще, чем это делается. Существует тенденция
бросать людей на проект и надеяться, что они выполнят его
вовремя. Менеджеры должны понимать, что разрабатывать ПО не то
же самое, что ковать железо: большее число работников не
обязательно означает больший объем выполненной работы.
В то же время простое утверждение, что подключение
программистов к работе над тормозящим проектом задерживает его
еще больше, маскирует тот факт, что при некоторых
обстоятельствах подобные меры способны ускорить работу. Как
Брукс отмечает в анализе своего закона, подключение людей к
программному проекту не поможет, если задачи в этом проекте
нельзя разбить на составные части и выполнять их независимо.
Но если задачи делятся на части, вы можете распределить их
между разными людьми, даже недавно включившимися в работу.
Другие исследователи смогли формально определить
обстоятельства, при которых вы можете подключать людей к
проекту на поздних стадиях и не вызывать еще большую его
задержку (Abdel-Hamid, 1989; McConnell, 1999).
Дополнительные сведения Аргу- Сократить проект О таком мощном
способе, как сокра-
менты в защиту реализации толь- щение проекта, часто
забывают. Если вы исключаете какую-
ко наиболее необходимой функ- то функцию, вы избавляетесь от
проектирования, кодирова-
щщяьности см. в главе 14 "fea- ния, отладки, тестирования и
документирования этой функ-
ture-Set Control" книги "Rapid Ds* ции а также от создания
интерфейса между этой и други-
wtopment" (McConnell, 1996). ми функциями
При первоначальном планировании продукта разделите его
возможности на категории "должны быть", "хорошо бы сделать" и
"необязательные". Если вы отстаете, расставьте приоритеты в
категориях "необязательные" и "хорошо бы сделать" и отбросьте
те, что имеют меньшее значение.
При невозможности отмены каких-то функций вы можете
представить более дешевую версию той же функциональности. Так,
вы можете сдать версию вовремя, не обеспечив при этом
максимальной производительности. Или в этой версии менее
важная функциональность будет реализована лишь в общих чертах.
Вы можете решить отбросить требования к скорости выполнения,
так как медленную версию сделать проще. Или можете решить
отбросить требования к объему памяти, поскольку версию,
интенсивно использующую память, сделать быстрее.
Повторно оцените время разработки для менее важных функций.
Какую функциональность вы можете предоставить за два часа, два
дня или две недели? Какую выгоду вы получите от двухнедельной
версии в отличие от двухдневной и чем двухдневная версия будет
отличаться от двухчасовой?
ГЛАВА 28 Управление конструированием 661
Дополнительные ресурсы, посвященные оценке ПО
Далее приведены ссылки на дополнительную литературу,
посвященную вопросу оценки ПО.
Мр://сс2е, сот/2871
Boehm, Barry, et al. Software Cost Estimation with Cocomo II.
Boston, MA: Addison-Wesley, 2000. Здесь описана оценочная
модель Cocomo II - несомненно, самая популярная на сегодняшний
день.
Boehm, Barry W. Software Engineering Economics. Englewood
Cliffs, NJ: Prentice Hall, 1981. Эта более старая книга
содержит исчерпывающее толкование вопросов оценки программных
проектов, более общее, чем в новой книге Бома.
Humphrey, Watts S. Л Discipline for Software Engineering.
Reading, MA: Addison-Wesley, 1995. В главе 5 этой книги
описывается Метод зондирования Хамфри (Humphrey's Probe
method) - способ оценки объема работ с точки зрения отдельного
программиста.
Conte, S. D., Н. Е. Dunsmore and V. Y. Shen. Software
Engineering Metrics and Models. Menlo Park, CA:
Benjamin/Cummings, 1986. Глава 6 содержит хороший обзор мето-
дик оценки, включая историю оценки, статистические модели,
теоретически обоснованные модели и составные модели. Книга
также демонстрирует использование каждого способа оценки для
набора проектов и сравнивает полученные расчетные значения с
Предыдущая << 1 .. 316 317 318 319 320 321 < 322 > 323 324 325 326 327 328 .. 426 >> Следующая