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

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

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

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

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

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

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

¦ проект приложения сложен, не совсем ясен или и то и другое;
¦ группа разработчиков незнакома с прикладной областью;
¦ проект сопряжен с высоким риском;
¦ долговременная предсказуемость проекта не играет особой
роли;
¦ затраты на изменение требований, проекта приложения и кода
скорее всего будут низкими.
Как бы то ни было, итеративные подходы эффективны гораздо
чаще, чем последовательные. Вы можете адаптировать
предварительные условия к своему конкретному проекту, как
считаете нужным, сделав их более или менее формальными или
полными. Мы подробнее обсудим разные подходы к крупным и
небольшим (или формальным и неформальным) проектам в главе 27.
Суть предварительных условий конструирования в том, что вам
следует сначала определить, какие из них уместны для вашего
проекта. В некоторых проектах предварительным условиям
уделяется слишком мало времени, что приводит к дестабилизации
на этапе конструирования и препятствует планомерному развитию
проекта, хотя этого можно было избежать. В других проектах
слишком много работы выполняется наперед; программисты,
работающие над такими проектами, слепо следуют требованиям и
планам, которые впоследствии оказываются неудачными, и это
также может снижать эффективность конструирования.
Итак, изучив табл. 3-2, вы определили, какие предварительные
условия уместны для вашего проекта, поэтому в оставшейся части
главы я расскажу, как определить, были ли выполнены отдельные
предварительные условия конструирования.
3.3. Предварительные условия, связанные с определением
проблемы
Ыт ограничения и условия описываются как "коробка", то
хитрость в том, чтобы найти именно коробку... Не думайте о
неано глобальном - найдите коробку.
Эндп Хат и Дэйв Томас {Andy Hwtmd От Штт)
Первое предварительное условие, которое нужно выполнить перед
конструированием, - ясное формулирование проблемы, которую
система должна решать. Это еще иногда называют "видением
продукции", "формулированием точки зрения", "формулированием
задачи" или "определением продукции". Я буду называть это
условие "определением проблемы". Так как книга посвящена
конструированию программ, прочитав этот раздел, вы не
научитесь разрабатывать определение проблемы, но узнаете, как
определить, есть ли
оно вообще и станет ли оно надежной основой конструирования.
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные
условия
35
Определение проблемы - это просто формулировка сути проблемы
без каких- либо намеков на ее возможные решения. Оно может
занимать пару страниц, но обязательно должно звучать как
проблема. Фраза "наша система Gigatron не справляется с
обработкой заказов" звучит как проблема и является хорошим ее
определением. Однако фраза "мы должны оптимизировать модуль
автоматизированного ввода данных, чтобы система Gigatron
справлялась с обработкой заказов" - плохое определение
проблемы. Оно похоже не на проблему, а на решение.
Определение проблемы предшествует выработке детальных
требований, которая является более глубоким исследованием
проблемы (рис. 3-4).

Рис. 3-4. Определение проблемы - фундамент всего процесса
программирования
Проблему следует формулировать на языке, понятном
пользователю, а сама проблема должна быть описана с
пользовательской точки зрения. Обычно проблему не следует
формулировать в компьютерных терминах, потому что оптимальным
ее решением может оказаться не компьютерная программа.
Допустим, вы нуждаетесь в вычислении годовой прибыли.
Вычисление квартальной прибыли вы уже компьютеризировали. Если
вы застрянете на программировании, то решите, что в имеющееся
приложение нужно просто добавить функцию вычисления годовой
прибыли со всеми вытекающими отсюда последствиями: затратами
на оплату труда разработчиков и т. п. Если же вы малость
подумаете, то просто чуть поднимете зарплату секретарю,
который будет один раз в год суммировать четыре числа на
калькуляторе.
Исключения из этого правила допустимы, если проблема связана с
компьютерами: программы компилируются слишком медленно, или
инструменты программирования полны ошибок. В подобных случаях
проблему можно сформулировать в компьютерных, привычных для
программистов терминах.
Не имея хорошего определения проблемы, можно потратить усилия
на решение не той проблемы (рис. 3-5).
36 ЧАСТЬ I Основы разработки ПО



Рис. 3-5. Прежде чем стрелять, убедитесь в том, что знаете,
куда целитесь
Неудачное определение проблемы грозит пустой тратой времени
на ре- > шение не той проблемы. Разумеется, нужную проблему вы
при этом тоже не решите.
3.4. Предварительные условия, связанные с выработкой
требований
Требования подробно описывают, что должна делать программная
система, а их выработка - первый шаг к решению проблемы.
Выработка требований также известна как "разработка
требований", "анализ требований", "анализ", "определение
требований", "спецификация", "функциональная спецификация".
Зачем нужны официальные требования?
Предыдущая << 1 .. 18 19 20 21 22 23 < 24 > 25 26 27 28 29 30 .. 426 >> Следующая