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