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

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

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

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

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

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

Макконнелл С. Совершенный код. Мастер-класс — М.: Русская редакция, 2005. — 896 c.
ISBN: 5-469-00822-3
Скачать (прямая ссылка): soversheniykodmasterklass2005.djvu
Предыдущая << 1 .. 19 20 21 22 23 24 < 25 > 26 27 28 29 30 31 .. 426 >> Следующая

Важность явного набора требований объясняется несколькими
причинами Явные требования помогают гарантировать, что
функциональность системы определяется пользователем, а не
программистом. Если требования сформулированы явно,
пользователь может проанализировать и утвердить их Если явных
требований нет, программисту обычно самому приходится
вырабатывать их во время программирования Явные требования
позволяют не гадать, чего хочет пользователь.
Кроме того, наличие явных требований помогает избегать споров.
Требования позволяют определить функциональность системы до
начала программирования. Если вы не согласны с другим
программистом по поводу каких-то аспектов программы, вы можете
разрешить споры, взглянув на написанные требования.
^ Внимание к требованиям помогает свести к минимуму
изменения сис- J|l{^ темы после начала разработки. Обнаружив
при кодировании ошибку в коде, вы измените несколько строк, и
работа продолжится. Если же во время кодирования вы найдете
ошибку в требованиях, придется изменить проект программы,
чтобы он соответствовал измененным требованиям. Возможно, при
этом придется отказаться от части старого проекта, а поскольку
в соответствии с ней уже написан некоторый код, на реализацию
нового проекта уйдет больше времени, чем могло бы Вы также
должны будете отказаться от кода и тестов, на которые повлияло
изменение требований, и написать их заново. Даже код,
оставшийся нетронутым, нужно будет заново протестировать для
гарантии того, что изменение не привело к появлению новых
ошибок.
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные
условия
37
Как вы помните, исследования, проведенные во многих
организациях, сви-
хитектуры, обычно обходится втрое дороже, чем исправление
аналогичной ошибки, найденной на этапе выработки требований
(табл. 3-1). Такая же ошибка, обнаруженная при кодировании,
обходится дороже уже в 5-10, при тестировании системы - в 10,
а после выпуска программы - в 10-100 раз. В менее крупных про-
ектах с меньшими административными расходами последний
показатель ближе к 5-10, чем к 100 (Boehm and Turner, 2004).
Как бы то ни было, думаю, что дополнительные расходы нужны вам
меньше всего.
Адекватное определение требований - одно из важнейших условий
успеха проекта, возможно, даже более важное, чем использование
эффективных методов конструирования (рис. 3-6). Определению
требований посвящены многие хорошие книги, поэтому в
нескольких следующих разделах я не буду рассказывать, как
правильно определять требования, - вместо этого я расскажу,
как узнать, хорошо ли они определены, и как выжать максимум из
имеющихся требований.
Рис. з-б. Не имея грамотно определенных требований, вы можете
правильно представлять обгцую проблему, но упустить из виду ее
специфические аспекты
Миф о стабильных требованиях
Стабильные требования - Святой Грааль разработки ПО. Трвбоваиия
подобнь| воде 0пи.
При стабильных требованиях смена этапов разработки ар- ратьс"
на них легче, если они хитектуры, проектирования, кодирования
и тестирования заморожены.
спокойно. Это просто рай для разработчиков! Вы можете
точно планировать расходы и совсем не волнуетесь о том, что
реализация какой- то функции обойдется в 100 раз дороже из-за
того, что клиенту она придет в голову только после отладки.
Всем нам хотелось бы надеяться, что, как только клиент
утвердил требования, никаких изменений не произойдет. Однако
чаще всего клиент не может точно сказать, что ему нужно, пока
не будет написан некоторый код. Проблема не в том, что клиенты
- более низкая форма жизни. Подумайте: чем больше вы работаете
над проектом, тем лучше вы его понимаете; то же относится и к
клиентам. Про-

детельствуют о том, что при работе над крупными проектами
исправление ошибки в требованиях, обнаруженной на этапе
проектирования ар-

приложения происходит упорядоченно, предсказуемо и
Шит
38 ЧАСТЬ I Основы разработки ПО
цесс разработки помогает им лучше понять собственные
потребности, что часто приводит к изменению требований
(Curtis, Krasner and Iscoe, 1988; Jones 1998; Wiegers, 2003).
Если вы планируете жестко следовать требованиям, на самом деле
вы собираетесь не реагировать на потребности клиента.
Какой объем изменений типичен? Исследования, проведенные в IBM
и других компаниях, показали, что при реализации среднего
проекта тре
бования во время разработки изменяются примерно на 25%
(Boehrii, 1981; Jones, 1994; Jones, 2000), на что приходится
70-85% объема повторной работы над типичным проектом
(Leffingwell, 1997; Wiegers, 2003).
Возможно, вы считаете, что "Понтиак Ацтек" - самый
великолепный автомобиль из когда-либо созданных, являетесь
членом Общества Верящих в Плоскую Землю и каждые четыре года
совершаете паломничество в Розуэлл, штат Нью-Мексико, на место
приземления инопланетян. Если это так, можете и дальше верить
в то, что требования в ваших проектах меняться не будут. Если
Предыдущая << 1 .. 19 20 21 22 23 24 < 25 > 26 27 28 29 30 31 .. 426 >> Следующая