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

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

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

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

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

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

Макконнелл С. Совершенный код. Мастер-класс — М.: Русская редакция, 2005. — 896 c.
ISBN: 5-469-00822-3
Скачать (прямая ссылка): soversheniykodmasterklass2005.djvu
Предыдущая << 1 .. 28 29 30 31 32 33 < 34 > 35 36 37 38 39 40 .. 426 >> Следующая

быстродействию всех классов, подсистем и функциональных
областей?
? Описывает ли архитектура способ достижения масштабируемости
системы?
? Рассмотрены ли вопросы взаимодействия системы с другими
системами?
? Описана ли стратегия интернационализации/локализации?
? Определена ли согласованная стратегия обработки ошибок?
? Определен ли подход к отказоустойчивости системы (если это
требуется)?
? Подтверждена ли возможность технической реализации всех
частей системы?
? Определен ли подход к реализации избыточной
функциональности?
? Приняты ли необходимые решения относительно "покупки или
создания" компонентов системы?
? Описано ли в спецификации, как повторно используемый код
будет адаптирован к другим аспектам архитектуры?
? Сможет ли архитектура адаптироваться к вероятным изменениям?
Общее качество архитектуры
? Все ли требования отражены в архитектуре?
? Является ли какая-нибудь часть системы чрезмерно или
недостаточно проработанной? Заданы ли явные ожидания по
этому поводу?
? Является ли вся архитектура концептуально целостной?
? Независим ли высокоуровневый проект системы от платформы и
языка, который будет использован для его реализации?
? Указаны ли мотивы принятия всех основных решений?
? Удовлетворяет ли вас - программиста, который будет
реализовывать систему, - разработанная архитектура?
3.6. Сколько времени следует посвятить
выполнению предварительных условий?
Перекрестная ссылка Объем времени, необходимый для работы над
предварительным* условиями, зависит от типа проекта. Об
адаптации предварительных условий к специфическому проекту см.
раздел 3.2.
Если требования нестабильны и вы работаете над крупным
формальным проектом, то для решения проблем с требованиями,
которые будут обнаружены на ранних этапах конструирования,
вам, вероятно, понадобятся услуги специалиста по анализу
требований. Предусмотрите консультации с ним и выделите ему
время на ревизию требований - и пригодная для работы версия
требований в ваших руках.
Время, уходящее на определение проблемы, выработку требований
и проектирование архитектуры ПО, зависит от особенностей
проекта. Как правило, если проект развивается без проблем,
работа над требованиями, архитектурой и предварительным
планированием поглощает 10-20% усилий и 20-30% времени
(McConnell, 1998; Kruchten, 2000). Эти показатели не включают
затраты на детальное проектирование - оно является частью
конструирования.
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные
условия
53
Если требования нестабильны и вы работаете над небольшим
неформальным проектом, вам, наверное, придется решать проблемы
с требованиями самостоятельно. Выделите время на грамотное
определение требований, чтобы их изменчивость как можно слабее
повлияла на конструирование.
Каким бы проект ни был - формальным или неформальным, - если
требования нестабильны, рассматривайте работу над ними как
отдельный проект. Оцените время, нужное для выполнения
оставшейся части проекта, после завершения работы над
требованиями. Это разумно: трудно ожидать, что вы сможете
составить график работы до того, как будете знать, что
создаете. Представьте, что вас хотят нанять для строительства
дома. Заказчик говорит: "Сколько будет стоить ваша работа?" Вы
обоснованно спрашиваете: "Что мне нужно построить?", на что
заказчик отвечает: "Я не могу сказать вам, но сколько это
будет стоить?" Что вы сделаете? Попрощаетесь с заказчиком и
отправитесь домой.
Ясно, что клиенты не попросят вас предъявить им счет, пока не
расскажут, какой дом надо построить. Им не нужно, чтобы вы
пришли с досками, молотком и гвоздями и начали тратить их
деньги до того, как архитектор завершит работу над чертежами.
Однако люди, как правило, разбираются в создании ПО хуже, чем
в лестницах и дверных проемах, поэтому ваши клиенты могут не
сразу понять, почему вы хотите сделать выработку требований
отдельным проектом. Возможно, вам придется объяснить им
причины этого.
Выделяя время на проектирование архитектуры ПО, поступайте так
же, как и при выработке требований. Если над данным типом ПО
вы еще не работали, выделите больше времени. Убедитесь, что
время на создание качественной архитектуры будет выделено не в
ущерб другим этапам. Если нужно, сделайте отдельным проектом и
работу над архитектурой.
Перекрестная ссылка 0 подходах к изменениям требований см.
подраздел "Что делать при изменении требований во время
конструирования орограм* мы?" раздела 3.4.
Дополнительные ресурсы
Ниже я привел список ресурсов, посвященных работе над
требованиями.
http://Gc2e.com/0344
http://GC2e.com/0351
Выработка требований
В следующих книгах вы найдете гораздо более подробную
информацию о выработке требований.
Wiegers, Karl. Software Requirements, 2d ed. Redmond, WA:
Microsoft Press, 2003. В этом практическом руководстве
описываются все детали выработки требований, в том числе сбор
информации о требованиях, их анализ, составление спецификации
Предыдущая << 1 .. 28 29 30 31 32 33 < 34 > 35 36 37 38 39 40 .. 426 >> Следующая