Руководство по стилю программирования и конструированию по
 Скачать 7.6 Mb.
|
|
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 27 Табл. 3-1. Средняя стоимость исправления дефектов в зависимости от времени их внесения и обнаружения Время обнаружения дефекта Время внесения Выработка Проектирование Тестирование После дефекта требований архитектуры Конструирование системы выпуска ПО Выработка 1 3 5–10 10 10–100 требований Проектиро- — 1 10 15 25–100 вание архи- тектуры Конструи- — — 1 10 10–25 рование Источник: адаптировано из работ «Design and Code Inspections to Reduce Errors in Program Development» (Fagan 1976), «Software Defect Removal» (Dunn, 1984), «Software Process Improvement at Hughes Aircraft» (Humphrey, Snyder, and Willis, 1991), «Calculating the Return on Investment from More Effective Requirements Management» (Leffingwell, 1997), «Hughes Aircraft’s Widespread Deployment of a Continuously Improving Software Process» (Willis et al., 1998), «An Economic Release Decision Model: Insights into Software Project Management» (Grady, 1999), «What We Have Learned About Fighting Defects» (Shull et al., 2002) и «Balancing Agility and Discipline: A Guide for the Perplexed» (Boehm and Turner, 2004). Эти данные говорят, например, о том, что дефект архитектуры, исправление ко- торого при проектировании архитектуры обходится в $1000, может во время те- стировании системы вылиться в $15 000 (рис. 3-1). Этап внесения дефекта Выработка требований Проектирование архитектуры Конструирование Этап обнаружения дефекта Выработка требований Проектирование архитектуры Конструирование Т естирование системы После выпуска ПО Затраты Рис. 3-1. С увеличением интервала между моментами внесения и обнаружения дефекта стоимость его исправления сильно возрастает. Это верно и для очень последовательных проектов (выработка требований и проектирование на 100% выполняются заблаговременно), и для очень итеративных (аналогичный показатель равен 5%) 2 8 ЧАСТЬ I Основы разработки ПО В большинстве проектов основная часть усилий по исправлению дефек- тов все еще приходится на правую часть рис. 3-1, а значит, на отладку и переделывание работы уходит около 50% времени типичного цикла раз- работки ПО (Mills, 1983; Boehm, 1987; Cooper and Mullen, 1993; Fishman, 1996; Haley, 1996; Wheeler, Brykczynski, and Meeson, 1996; Jones, 1998; Shull et al., 2002; Wiegers, 2002). В десятках компаний было обнаружено, что политика раннего исправле- ния дефектов может в два и более раз снизить финансовые и временные затраты на разработку ПО (McConnell, 2004). Это очень веский довод в пользу как можно более раннего нахождения и решения проблем. Тест готовности руководителя Если вам кажется, что ваш руководитель понимает важность выполнения предва- рительных условий до начала конструирования, попросите его пройти следую- щий тест, чтобы убедиться в этом. Какие из этих утверждений являются самоисполняющимися пророчествами? 쐽 Предлагаю приступить к кодированию прямо сейчас, потому что нам предстоит потратить много времени на отладку. 쐽 Мы не выделили много времени на тестирование, поскольку не ожидаем об- наружить много дефектов. 쐽 Мы изучили требования и проект приложения так хорошо, что я не представ- ляю, какие крупные проблемы могут у нас возникнуть во время кодирования или отладки. Все эти высказывания — самоисполняющиеся пророчества. Стремитесь к тому, чтобы исполнилось последнее. Если вы еще не уверены, что предварительные условия актуальны для вашего проекта, следующий раздел поможет вам принять окончательное решение. 3.2. Определите тип ПО, над которым вы работаете Обобщая 20 лет исследований разработки ПО, Кейперс Джонс, руководитель ис- следовательских работ в компании Software Productivity Research, заявил, что он и его коллеги сталкивались с 40 разными методами сбора требований, 50 вари- антами проектирования ПО и 30 видами тестирования, применявшимися в про- ектах, реализуемых более чем на 700 языках программирования (Jones, 2003). Разные типы проектов призывают к разным сочетаниям подготовки и конструи- рования. Каждый проект уникален, однако обычно проекты подпадают под общие стили разработки. Вот три самых популярных типа проектов, а также оптималь- ные в большинстве случаев методы работы над ними (табл. 3-2): ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 29 Табл. 3-2. Оптимальные методы работы над программными проектами трех популярных типов Тип ПО Встроенные системы, Системы целевого от которых зависит Бизнес-системы назначения жизнь людей Типичные Интернет-сайты. Встроенное ПО. Авиационное ПО. приложения Сайты в интрасетях. Игры. Встроенное ПО. Системы управле- Интернет-сайты. ПО для медицинских ния материально- Пакетное ПО. устройств. техническим Программные Операционные снабжением. инструменты. системы. Игры. Web-сервисы. Пакетное ПО. Системы управле- ния информацией. Системы выплаты заработной платы. Модели жизнен- Гибкая разработка Поэтапная поставка. Поэтапная поставка. ного цикла (экстремальное Эволюционная Спиральная программирование, поставка. разработка. методология Scrum, Спиральная Эволюционная разработка на осно- разработка. поставка. ве временных окон и т. д.). Эволюционное. прототипирование. Планирование Инкрементное пла- Базовое заблаговре- Исчерпывающее и управление нирование проекта. менное планирование. заблаговременное Планирование тести- Базовое планирова- планирование. рования и гарантии ние тестирования. Исчерпывающее качества по мере Планирование планирование тести- надобности. гарантии качества рования. Неформальный по мере надобности. Исчерпывающее пла- контроль над Формальный контроль нирование гарантии изменениями. над изменениями. качества. Тщательный контроль над изменениями. Выработка Неформальная Полуформальная спе- Формальная специ- требований спецификация цификация требований. фикация требований. требований. Обзоры требований Формальные инспек- по мере надобности. ции требований. ( см. след. стр.) 3 0 ЧАСТЬ I Основы разработки ПО Табл. 3-2. (окончание) Тип ПО Встроенные системы, Системы целевого от которых зависит Бизнес-системы назначения жизнь людей Проектирова- Комбинация Проектирование Проектирование ние проектирования архитектуры. архитектуры. и кодирования. Неформальное деталь- Формальные инспек- ное проектирование. ции архитектуры. Обзоры проекта Формальное деталь- по мере надобности. ное проектирование. Формальные инспек- ции детального проекта. Конструирова- Парное или индиви- Парное или индиви- Парное или индиви- ние дуальное программи- дуальное программи- дуальное программи- рование. рование. рование. Неформальная про- Неформальная проце- Формальная процеду- цедура регистрации дура регистрации кода. ра регистрации кода. кода или ее отсутст- Обзоры кода по мере Формальные инспек- вие. надобности. ции кода. Тестирование Разработчики тести- Разработчики тестируют Разработчики тести- и гарантия руют собственный код. собственный код. руют собственный качества Предварительная Предварительная разра- код. разработка тестов. ботка тестов. Предварительная Тестирование отдель- Отдельная группа разработка тестов. ной группой прово- тестирования. Отдельная группа дится в малом объеме тестирования. или не проводится Отдельная группа вообще. гарантии качества. Внедрение Неформальная проце- Формальная процедура Формальная процеду- приложения дура внедрения. внедрения. ра внедрения. Работая над реальными проектами, вы столкнетесь с бесчисленными вариация- ми на три темы, указанные в таблице, однако можно сделать и некоторые общие выводы. При разработке бизнес-систем предпочтительно использовать высоко- итеративные подходы, при которых планирование, выработка требований и про- ектирование архитектуры перемежаются с конструированием, тестированием си- стемы и гарантией качества. Системы, от которых зависит жизнь людей, требуют более последовательных подходов, поскольку стабильность требований — одно из условий высочайшей надежности системы. Влияние итеративных подходов на предварительные условия Кое-кто утверждает, что при использовании итеративных методов не нужно осо- бо возиться с предварительными условиями, но эта точка зрения неверна. Итера- ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 31 тивные подходы ослабляют следствия неадекватной подготовки, но не устраня- ют их. Давайте изучим табл. 3-3, в которой приведены данные о проектах, в нача- ле которых не были выполнены предварительные условия. Первый проект выпол- няется последовательно, при этом дефекты обнаруживаются только на этапе тес- тирования; второй выполняется итеративно, и разработчики находят дефекты по мере работы. В первом случае основной объем работы по исправлению дефектов откладывается на конец проекта, что приводит к росту расходов (табл. 3-1). При итеративном подходе дефекты исправляются по мере развития проекта, что по- зволяет снизить общие расходы. Табл. 3-3 и 3-4 приведены исключительно в ил- люстративных целях, однако соотношение затрат при этих двух общих подходах хорошо подтверждается исследованием, описанным выше. Табл. 3-3. Влияние невыполнения предварительных условий на последовательный и итеративный проекты Подход 1: последовательный Подход 2: итеративный подход подход без выполнения без выполнения предварительных условий предварительных условий Степень Затраты Затраты Затраты Затраты завершенности на работу на исправление на работу на исправление проекта дефектов дефектов 20% $100 000 $0 $100 000 $75 000 40% $100 000 $0 $100 000 $75 000 60% $100 000 $0 $100 000 $75 000 80% $100 000 $0 $100 000 $75 000 100% $100 000 $0 $100 000 $75 000 Затраты на исправ- $0 $500 000 $0 $0 ление дефектов в конце проекта СУММА $500 000 $500 000 $500 000 $375 000 ОБЩАЯ СУММА $1 000 000 $875 000 Итеративный проект с сокращенной программой выполнения предварительных условий или без нее отличается от аналогичного последовательного проекта двумя аспектами. Во-первых, при итеративном подходе затраты на исправление дефек- тов обычно ниже, потому что дефекты выявляются раньше. И все же это проис- ходит в конце каждой итерации, и исправление дефектов требует повторного проектирования, кодирования и тестирования фрагментов ПО, что делает затра- ты более крупными, чем они могли бы быть. Во-вторых, при итеративных подходах затраты распределяются по всему проекту, а не группируются в его конце. В конце концов и при итеративных, и при после- довательных подходах общая сумма затрат окажется похожей, но в первом случае она не будет казаться столь крупной, потому что будет уплачена по частям. 3 2 ЧАСТЬ I Основы разработки ПО Адекватное внимание к выполнению предварительных условий позволяет снизить затраты независимо от типа используемого подхода (табл. 3-4). Итеративные подходы обычно по многим параметрам лучше последовательных, однако итера- тивный подход, при котором пренебрегают предварительными условиями, может в итоге оказаться гораздо дороже, чем должным образом подготовленный после- довательный проект. Табл. 3-4. Влияние выполнения предварительных условий на последовательный и итеративный проекты Подход 3: последовательный Подход 4: итеративный подход подход с выполнением с выполнением предварительных условий предварительных условий Степень Затраты Затраты Затраты Затраты завершенности на работу на исправление на работу на исправление проекта дефектов дефектов 20% $100 000 $20 000 $100 000 $10 000 40% $100 000 $20 000 $100 000 $10 000 60% $100 000 $20 000 $100 000 $10 000 80% $100 000 $20 000 $100 000 $10 000 100% $100 000 $20 000 $100 000 $10 000 Затраты на исправ- $0 $0 $0 $0 ление дефектов в конце проекта СУММА $500 000 $100 000 $500 000 $50 000 ОБЩАЯ СУММА $600 000 $550 000 Эти данные наводят на мысль, что большинство проектов не являются ни полностью последовательными, ни полностью итеративными. Опре- делять требования или выполнять проектирование на 100% наперед не- практично, однако обычно определение самых важных требований и архитектур- ных элементов на раннем этапе оказывается выгодным. Одно популярное практическое правило состоит в том, что- бы заблаговременно определить около 80% требований, предусмотреть время для более позднего определения до- полнительных требований и выполнять по мере работы си- стематичный контроль изменений, принимая только самые важные требования. Возможен и другой вариант: вы можете определить заранее 20% только самых важных требований и разрабатывать оставшуюся часть ПО небольшими фрагментами, определяя дополнительные требования и дорабаты- вая проект приложения по мере прогресса (рис. 3-2 и 3-3). Перекрестная ссылка Об адапта- ции подхода разработки к про- граммам разных размеров см. главу 27. ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 33 Время Выработка требований Проектирование архитектуры Детальное проектирование Конструирование Гарантия качества/Тестирование системы Рис. 3-2. Этапы работы над проектами — даже самыми последовательными — обычно несколько перекрываются Выработка требований Проектирование архитектуры Детальное проектирование Конструирование Гарантия качества/Тестирование системы Время Рис. 3-3. В других случаях этапы перекрываются на всем протяжении проекта. Понимание степени выполнения предварительных условий и соответствующая адаптация проекта — одно из условий успешного конструирования Выбор между итеративным и последовательным подходом Степень, в которой предварительные условия должны быть выполнены наперед, зависит от типа проекта (табл. 3-2), формальности проекта, технической среды, возможностей сотрудников и бизнес-модели проекта. Вы можете выбрать более последовательный подход (при котором вопросы решаются заблаговременно), если: 쐽 требования довольно стабильны; 쐽 проект приложения прост и относительно понятен; 쐽 группа разработчиков знакома с прикладной областью; 쐽 проект не связан с особым риском; 3 4 ЧАСТЬ I Основы разработки ПО 쐽 важна долговременная предсказуемость проекта; 쐽 затраты на изменение требований, проекта приложения и кода скорее всего окажутся высокими. Более итеративный подход (при котором вопросы решаются по мере работы) можно предпочесть, если: 쐽 требования относительно непонятны или вам кажется, что они могут оказать- ся нестабильными по другим причинам; 쐽 проект приложения сложен, не совсем ясен или и то и другое; 쐽 группа разработчиков незнакома с прикладной областью; 쐽 проект сопряжен с высоким риском; 쐽 долговременная предсказуемость проекта не играет особой роли; 쐽 затраты на изменение требований, проекта приложения и кода скорее всего будут низкими. Как бы то ни было, итеративные подходы эффективны гораздо чаще, чем после- довательные. Вы можете адаптировать предварительные условия к своему кон- кретному проекту, как считаете нужным, сделав их более или менее формальны- ми или полными. Мы подробнее обсудим разные подходы к крупным и неболь- шим (или формальным и неформальным) проектам в главе 27. Суть предварительных условий конструирования в том, что вам следует сначала определить, какие из них уместны для вашего проекта. В некоторых проектах предварительным условиям уделяется слишком мало времени, что приводит к дестабилизации на этапе конструирования и препятствует планомерному разви- тию проекта, хотя этого можно было избежать. В других проектах слишком мно- го работы выполняется наперед; программисты, работающие над такими проек- тами, слепо следуют требованиям и планам, которые впоследствии оказываются неудачными, и это также может снижать эффективность конструирования. Итак, изучив табл. 3-2, вы определили, какие предварительные условия уместны для вашего проекта, поэтому в оставшейся части главы я расскажу, как определить, были ли выполнены отдельные предварительные условия конструирования. 3.3. Предварительные условия, связанные с определением проблемы Первое предварительное условие, которое нужно выполнить перед конструированием, — ясное формулирование пробле- мы, которую система должна решать. Это еще иногда назы- вают «видением продукции», «формулированием точки зре- ния», «формулированием задачи» или «определением про- дукции». Я буду называть это условие «определением про- блемы». Так как книга посвящена конструированию про- грамм, прочитав этот раздел, вы не научитесь разрабатывать определение проблемы, но узнаете, как определить, есть ли оно вообще и станет ли оно надежной основой конструирования. Если ограничения и условия описываются как «коробка», то хитрость в том, чтобы найти именно коробку… Не думайте о чем-то глобальном — найдите коробку. Энди Хант и Дэйв Томас (Andy Hunt and Dave Thomas) ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные условия 35 Определение проблемы — это просто формулировка сути проблемы без каких- либо намеков на ее возможные решения. Оно может занимать пару страниц, но обязательно должно звучать как проблема. Фраза «наша система Gigatron не справ- ляется с обработкой заказов» звучит как проблема и является хорошим ее опре- делением. Однако фраза «мы должны оптимизировать модуль автоматизирован- ного ввода данных, чтобы система Gigatron справлялась с обработкой заказов» — плохое определение проблемы. Оно похоже не на проблему, а на решение. Определение проблемы предшествует выработке детальных требований, которая является более глубоким исследованием проблемы (рис. 3-4). Будущие улучшения Тестирование системы Конструирование Проектирование архитектуры Выработка требований Определение проблемы Рис. 3-4. Определение проблемы — фундамент всего процесса программирования Проблему следует формулировать на языке, понятном пользователю, а сама про- блема должна быть описана с пользовательской точки зрения. Обычно проблему не следует формулировать в компьютерных терминах, потому что оптимальным ее решением может оказаться не компьютерная программа. Допустим, вы нужда- етесь в вычислении годовой прибыли. Вычисление квартальной прибыли вы уже компьютеризировали. Если вы застрянете на программировании, то решите, что в имеющееся приложение нужно просто добавить функцию вычисления годовой прибыли со всеми вытекающими отсюда последствиями: затратами на оплату труда разработчиков и т. п. Если же вы малость подумаете, то просто чуть поднимете зарплату секретарю, который будет один раз в год суммировать четыре числа на калькуляторе. Исключения из этого правила допустимы, если проблема связана с компьютера- ми: программы компилируются слишком медленно, или инструменты програм- мирования полны ошибок. В подобных случаях проблему можно сформулировать в компьютерных, привычных для программистов терминах. Не имея хорошего определения проблемы, можно потратить усилия на решение не той проблемы (рис. 3-5). 3 6 ЧАСТЬ I Основы разработки ПО Рис. 3-5. Прежде чем стрелять, убедитесь в том, что знаете, куда целитесь Неудачное определение проблемы грозит пустой тратой времени на ре- шение не той проблемы. Разумеется, нужную проблему вы при этом тоже не решите. 3.4. Предварительные условия, связанные с выработкой требований Требования подробно описывают, что должна делать программная система, а их выработка — первый шаг к решению проблемы. Выработка требований также известна как «разработка требований», «анализ требований», «анализ», «определение требований», «спецификация», «функциональная спецификация». Зачем нужны официальные требования? Важность явного набора требований объясняется несколькими причинами. Явные требования помогают гарантировать, что функциональность системы опре- деляется пользователем, а не программистом. Если требования сформулированы явно, пользователь может проанализировать и утвердить их. Если явных требова- ний нет, программисту обычно самому приходится вырабатывать их во время про- граммирования. Явные требования позволяют не гадать, чего хочет пользователь. Кроме того, наличие явных требований помогает избегать споров. Требования позволяют определить функциональность системы до начала программирования. Если вы не согласны с другим программистом по поводу каких-то аспектов про- граммы, вы можете разрешить споры, взглянув на написанные требования. Внимание к требованиям помогает свести к минимуму изменения сис- темы после начала разработки. Обнаружив при кодировании ошибку в коде, вы измените несколько строк, и работа продолжится. Если же во время кодирования вы найдете ошибку в требованиях, придется изменить про- ект программы, чтобы он соответствовал измененным требованиям. Возможно, при этом придется отказаться от части старого проекта, а поскольку в соответ- ствии с ней уже написан некоторый код, на реализацию нового проекта уйдет больше времени, чем могло бы. Вы также должны будете отказаться от кода и те- стов, на которые повлияло изменение требований, и написать их заново. Даже код, оставшийся нетронутым, нужно будет заново протестировать для гарантии того, что изменение не привело к появлению новых ошибок. |