WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!

Pages:     | 1 || 3 | 4 |

«Эд - ДЕНЬГИ Создание команды разработчиков программного обеспечения Москва 2002 Р У С УДК 004.45 32.973.26-018.2 С16 Э. ...»

-- [ Страница 2 ] --

Прежде, чем новые приемы, нужно извлечь из имеющихся Один из самых вающих аспектов разработки ПО — внедрение новых приемов, в то время как команда исполь зует все имеющихся. В вашей команде так быть не За правильное использование имею щихся приемов отвечают менеджеры и ведущие специ алисты. потерять участников команды, санкционируя добавление новых технологических и игнорируя те, что Если что ни один из имеющихся документированных при емов не полностью, созовите собрание группы и представляют ли ценность. Да — оставьте их и используйте все Нет — от лишних технологических приемов. Что толку дер жать приемы развесив их по как картины? Они только портят Суть в следующем: нужно внедрить минимальный набор технологических приемов, необходимый для выполнения работы и следить за тем, чтобы группа ос воила их в совершенстве. Не следует осваивать новые приемы, если вы сами не что будут задей ствованы в полной мере. Группа должна знать: уж если вы что-то сделать, то сделаете это Глава 4. Ранжирование сотрудников и корпоративная культура • отдельного специалиста и всей команды Обычно новые приемы чтобы удовлетворить потребности всей команды. Одна ко порой новые приемы вводятся, лишь чтобы чить жизнь нескольким людям или даже одному чело веку. В этих случаях надо все затраты и выгоды. Если для внедрения этого приема придется просить группу сделать что-то сверх заплани рованного с затратами, нужно быть ренным, что польза для немногих участников группы стоит затрат, на которые придется пойти остальным, Если они несоизмеримы, от нового приема следует от казаться, в противном случае надо разъяснить причины всем, кого коснется внедрение приема и кому придется вкладывать в него свое время и силы, чтобы его стопроцентное Из собственного опыта Как-то раз в было предложено при регистрации ошибки сопровождать ее сведениями о программ но-аппаратной конфигурации на котором она была должно быть полез ным для тех, кто смог бы легче находить типы ошибок с его помощью и прекрасно подходит для разнородных сред или и случае команд, разработчи ки рассредоточены. Однако это стало бы пре пятствием для остальных участников группы, которым приходится вводить вручную и без оши бок. Но нашу среду нельзя назвать ни разнородной, ни географически рассредоточенной, ли новый прием ценность для компа нии? Иногда — да, когда инфор мация позволит легче устранять ошибки, но число таких ошибок не превышает 5-Ю в месяц. Однако затраты на ввод этой информации, который должны выполнять Часть 1. Люди, организация и методы на протяжении внутреннего цикла раз работки (особенно когда приходилось регистрировать до 10 ошибок в день), не стоили потенциальной пользы. Кро ме того, большинство ошибок воспроизводилось на лю бой машине, в противном случае было нетрудно связать ся с офисом, откуда поступило сообщение об ошибке, и выяснить необходимую информацию о конфигурации.

Отвергнув это предложение и множество ему подоб ных, нам удалось поддерживать накладные расходы низ кими и в полной мере имеющийся арсенал технологических приемов, Типичные проблемы и их решение Далее обсуждается ряд проблем и вопросов, никающих при использовании описываемых здесь а также их решения.

Проблемы с ранжированием • Не держите в секрете Не скрывайте факт, что в компании ведется ранжирование сотрудни ков, хотя вывешивать транспарант с рангами на виду у всех тоже не стоит. Людям важно знать, что их личный вклад востребован, будет оценен по достоинству и его учтут при распределении различных привилегий и ком пенсаций.

• Не затрудняйте переход из одного круга в другой стройте преград между внешним, сред ним и внутренним кругами. способом перехода в круги должно быть повышение лич ного вклада, а единственной причиной перевода в низшие — недостаточный вклад. Кроме того, обязатель но нужно отмечать стабильные результаты переводом из внешнего круга в средний, а хроническое снижение 4. Ранжирование сотрудников и корпоративная культуре качества работы — из внутреннего круга во Как при переходе из одно го круга в другой нужно обсудить это с ним, Позитивные переходы должны быть отмечены и поощ рены. Негативные переходы тоже следует отметить и с глазу на • Не заводите фаворитов Не допускайте использова ния рангов для фаворитов и не пугайте со средством быть основан исключительно на личном вкладе работ ника. Если из группы не вносит вклад с остальными, он должен в благ с остальными, и точка. вы в состо янии пойти такое решение, вовсе отказать ся от ранжирования.

• честно считают сплошным обманом. может быть в том. что ранее этим людям уже приходилось сталкиваться с не (см. обсуж дение фаворитизма выше). Но с другой ран жирование никогда не бывает если под чест ностью понимать уравниловку. Ранжирование всех, но помочь при распределении ресур сов основе размера личного вклада, отметить выда ющиеся достижения и дальнейшие хи. В мире, где ресурсы нужно найти спо соб ресурсов, и, вероятно, ничего чем на основе вклада в продукта или работу коллектива.

с культурой • можно Одна из самых проблем с культурой — в ее • Часть 1. Люди, организация и методы Корпоративная культура и компа ний особенно непоколебимой. Хотя изменить культуру может быть трудно, это вполне возможно, если руководство всерьез на это решилось. Кроме того, в от дельных часто складывается собствен ная микрокультура, в рамках корпоративной культуры, изменить которую сравнительно легко.

Если организация растет По мере роста организации очень важно прививать корпоративную культуру новым работникам. Особенно часто быстрый рост штата отме чается в начинающих компаниях, поэтому там следует особенно тщательно следить за сохранением основных корпоративных ценностей. Для этого следует не вать о таких вопросах:

КТО МЫ?

чем мы почему мы делаем свое дело лучше, чем кто-либо другой?

Ф чем мы отличаемся от других?

ф что мы ценим?

Проследите, чтобы работники компании знали ответы на эти вопросы и эти знания передавались но вичкам. Будет ли это собрание с участием участника группы администраторов или просто с кол легами по команде — вопросы культуры непременно следует обсуждать в открытую и со всей которой они заслуживают.

Инструмен программы Часть 1. Люди, и методы компании мы использовали лишь те инстру средства, которые были жизненно необходимы для нашей работы и вписывались в стиль работы. Из всех доступных инструментов мы большего всего применяли и на систему управ ления исходным кодом и систему проблем и неисправностей (поиска Возможность приспо сабливать эти продукты к нуждам уско рить работу — команда использовала их почти каждый день.

Средства исходным кодом Ваш исходный код — это второй наиболее важный актив проекта, после конечно. Следовательно, во всех про ектах, связанных с разработкой ПО, даже в тех, где задей всего один человек, должна быть цело стность исходного кода. В течение цикла разработки вам потребуется проверять, обновлять, контролировать и пере сматривать изменения в исходном коде. С ростом коли чества людей, работающих над проектом, и сложности проекта эти требования станут еще более критичными. Мы рассмотрим основные возможности программного обеспе чения по исходным кодом и обсудим рые простые приемы, позволяющие максимально увели чить его полезность.

О чем пойдет речь Продукты по управлению исходным кодом хранят файлы с кодом, отслеживают их версии, управляют файлами, со ставляющими проект, и функции.

• файла и его настоящих и будущих версий Система управления исходным кодом будет обслуживать все порученные ей файлов. Она сможет выдать любую файла, размещенную в Глава 5. программы системе. Эта необходима, если вы собира етесь строить приложение на основе предыдущих сий, и особенно важна при одновременном создании нескольких версий одной программы.

Отслеживание истории для каждого файла При любых изменениях в файлах система исходным кодом внесет нужные сведения в историю изменений;

дату, время, пользователя и обычно неболь шое примечание пользователя о природе изменения и его масштабе. Часто эти комментарии — единственное, чем вы располагаете. информация поможет новым разработчикам в проект.) Группирование файлов С ростом сложности проекта возникает необходимость группировать файлы: по на значению (например, по или подсисте мам) или по функциям (например, тестовые задания, спецификации и документация).

связанных с конкретным выпус ком программного продукта Система управления ис ходным кодом позволит пользователям пометить опре деленные версии файлов всего Это позволяет четко маркировать или вать файлы, составляющие определенный ПО.

и разблокировка файлов В процессе работки доступ к рабочему набору файлов требуется более чем одному человеку. Если какой-то файл не ис пользуется кем-то еще, система управления исходным кодом заблокирует файл и выдаст его пользователю для работы. Это действие предотвратит изменение и воз можную порчу файла другими пользователями. Когда тот, кому выдан файл, завершит свою работу и тит файл в систему, файл будет разблокирован, и по явится доступа и выдачи этого файла дру гим пользователям. Иногда двум разработчикам Часть Люди, организация и методы один файл. Для та ких случаев имеется обойти блокировку файла, но тогда координировать все изменения придет ся вам. Наиболее изощренные продукты по управлению исходным кодом обеспечивают множественную выда чу файлов, автоматически совмещая изменения, сделан ные двух файлах. Однако это может быть так что разработчиков выполняют операции по слиянию (контролируют этот процесс).

Что туда входит всех файлов и ной с — это страшная (но головная боль при разработке ПО. В не было созда вать инфраструктуру или сложные процессы для поддержки грамотного документооборота. Поэтому мы ре шили просто поместить все файлы и документы проекта в систему управления кодом. Это были:

• исходные файлы;

• файлы заголовков;

файлы библиотек;

• сценарии компоновки;

• результаты результаты компоновки;

инструменты и файлы для установки программ;

• инструменты и файлы для • спецификации проекта;

• планы проекта (ПО, документации и тестирования);

документация;

• тестовые задания и сценарии;

• тестовые модули разработчиков.

Глава 5. Инструментальные программы Из собственного опыта Мы думали, что поместили нужные файлы систему однако забыли о тестовых модулях, создан ных Тестовые модули — это программы для проверки функциональности продукта.

Разработчики запускают их в процессе разработки, что бы убедиться, что все еще работает. Тестовые модули особенно полезны при добавлении новых воз можностей и исправлении ошибок. Разработчики со стажем имеют в своем арсенале десятки маленьких про грамм, осуществляющих проверку условий и эти программки никогда не входят в офици альные тестирования. Если бы эти тесты хранились например, в системе управления ным кодом, мы бы могли запускать их как часть нашего набора тестов контроля качества. Кроме того, эти тесты могли бы риск добавления новых оши бок неопытными работающими над хрупкими или сложными частями кола.

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

Зачем это нужно При помещении всех файлов проекта в систему управления исходным кодом вы получаете большие преимущества. Во первых, неважно, что это за файл и когда вы подключились к работе над проектом, — вы почти наверняка найдете нуж файл в системе управления кодом, а это весьма ценно. Разработчик сможет найти планы ния, технический писатель — функциональные специфика ции, а новый сотрудник — нужную информацию без Часть 1. Люди, организация и знакомства с историей создания проекта. Во вторых, храня все файлы проекта в системе управления ис ходным кодом, вы сможете использовать функции марки ровки и блокирования файлов, управления версиями и ве дения истории.

в была возможность отслеживать изменения в планах, тестовых сценариях и документации для всего проекта. К тому же мы могли помечать целые на боры тестовых сценариев и пользовательской документа ции для каждого внутреннего этапа и для каждого основно го или неосновного выпуска. Мы могли с до сим вола воссоздать все файлы (не только файлы исходного кода) любого выпуска в истории проекта.

Особо отмечу включение в систему NuMega средств сборки: компиляторов, компоновщиков, заголовков и т. д.

Четкое управление этими средствами критично для обслу живания сборочной среды проекта. Официальная сбороч ная среда была всегда доступна в системе ис ходным кодом. Все разработчики и машины, на которых собирался проект, должны были использовать один и тот же набор файлов. Без исключений.

Так как для сборки продукта мы не полагались на ло кальные файлы (не содержащиеся в системе управления версиями), мы задействовали идентичную сборочную сре ду во всем проекте. Этот простой подход сэкономил нам немало времени. До применения такой системы мы посто янно сталкивались с проблемами при сборке из-за несов местимости между компиляторами разработчиков или ис кали труднонаходимые ошибки во время выполнения, вы званные несоответствием или заголовков.

И последнее (но не менее ценное) преимущество — централизация файлов в системе управления исходным кодом обеспечивает простое резервное копирование все го проекта. Одной командой мы могли создать резервную Глава 5. Инструментальные программы копню просто скопировать весь проект на другой диск или другую машину.

Каковы их технологические возможности Помимо функциональных возможностей, описанных нее, команда в нуждалась в поддержке пяти жизнен но необходимых технологических возможностей. Хотя они специфичны для наших продуктов и компании, многие из них стандартны для большинства проектов в отрасли. Это:

• управление разработкой нескольких редакций продукта;

управление разработкой нескольких версий одной ре дакции;

• применение общих компонентов, как в рамках одного, так и нескольких проектов компании;

• компоновка продукта на основе самого свежего набо ра файлов с исходным кодом (или на основе другого набора исходных файлов);

• поддержка локальных сборок для отдельных разработ чиков.

Как ими управлять Одна из главных задач в управлении по разработ ке ПО — это контроль сложности проекта. Труднее всего справляться с исходным кодом и управлением конфигура цией. Хотя решение было не оно все рав но работало и помогло нам без особых проблем уклады ваться в сроки.

Мы использовали систему управления исходным кодом Visual Source Safe компании Microsoft. Она предостав ляет нужные нам основные функции, и у нее цена — как раз для Хотя обсуждение выходит за рамки я расскажу о том, как мы приспособили этот продукт под наши нужды.

Часть и методы структуры Мы структурировали наши по двум простым эле ментам: частям и продуктам. — это ис пользуемый для компоновки программного продукта, Частями могут владеть не чле нами работающей над проектом. Они могут об новлять свои части собственному (однако графику, отличному от графика всего проекта. Продук том являлся конечный пакет, продаваемый пользователям.

Он складывался из для этого продукта частей и файлов. Храня в одном месте части и продукты, мы мог ли собирать различные редакции наших программ и одно временно поддерживать параллельных направ в разработке. Например, возможность выпускать ис или пакеты продолжая направлять все силы на разработку нового кода, была необходима и для поддержки, и для получения прибыли от следующих про дуктов.

Структура и хранилища исходного кода Все файлы, используемые при разработке наших продуктов, были рассортированы по трем папкам;

• Product Name — для файлов, относящихся к • Environment — для файлов среды + Imports — для сторонних файлов.

Папка Product Name содержала создаваемые нами фай лы, необходимые для сборки, тестирования и написания документации к продукту (табл. 5-1). Б ней были подката логи Branch для каждого варианта, над которым мы тали. В подкаталоге Parts хранились стандартные и совме стно используемые компоненты, включаемые в продукт. И, наконец, для каждой продукта имелся подкаталог Product. В каждой папке Product содержались необходимые для продукта части. Чтобы эта структура работала, нужно Глава 5. Инструментальные программы строго об именах и не нарушать структуру. Координация изменений в частях и продуктах также была критичной, 5-1. структура папки «Название продукта».

Имя файла и уровень Содержание относящиеся к продукту Branch Различные направления в Parrs Совместно используемые в продукт Исходный код для Parts (при совместно используется с Doc Исходные Исходные файлы справочной системы Исходный код программы установки Patch Исходный код вставок Setup Исходный код установщика Samples Исходный код с Tests Исходный код тестов, тестовые задания Редакции продукта Product Name (по одной паке на каждую редакцию) Output Область для программ, созданных в других Исходный код продукта (при необходимости совместно использу ется с Doc Файлы документации к продукту с /Parts/Doc) Help Файлы системы продук та (совместно используется с /Parts/Help) Imports Импорт (совместно используется с Часть Люди, организация и Табл.

Имя файла и уровень Содержание Install для используется с /Parts/Install) Samples Примеры для продукта (совместно используется с /Parts/Samples) Tests Тестовые задания, тестовые сцена (совместно используется Из собственного опыта Когда пришел NuMega, для одного из продуктов было создано три каталога по именам разработчиков: Bill и Matt. Так как каждый работал над своим собственным они могли изменения, повреждая чу жих файлов. Однако там было мало общего кода (одна большая структура данных для основных подсистем). Но работало! нам нужно было увеличить коман ду разработчиков, и мы уже не могли обойтись без темы управления кодом. Такая система лила усложнить проект, удерживая его под контролем. Без я просто не могу ПО для разработчиков.

В папке хранятся файлы, использу командой разработчиков, но не являющиеся частью конечного продукта. Это начиная с инструментов и ути лит и заканчивая кода и шаблонами для проекта. Папка Environment содержит файлы среды, среду с точки зрения разработчика, а также с точки тестирования и документации. В NuMega мы хотели создать общую среду для команд разработчиков, и потому для этой мы создали раздел F:

хранилище исходного кода. Вот примерный список талогов, которые могут в этом разделе ходного кода (табл. 5-2), Глава 5. программы Табл. 5-2. Примерная структура папки Environment.

Имя файла и уровень Содержание Dev ПО среды и инструмен тальных средств Bin Исполняемые модули (подкаталог для каждого инструмента) Src Исходный код для этих тов (подкаталог для каждого) Doc Документация для тов (подкаталог для каждого) Etc Прочие файлы Test средства и файлы для тестирования Bin Исполняемые модули Исходный код и документация для этих инструментов Doc Документация по среде тестирования Et< Прочие файлы Documentation Документация по среде проекта Templates проекта, шаблоны доку ментации и справочники по стилям Планы и спецификации проекта, заданий и документации Process Технологические документы •• Прочие не вошедшие предыдущие В Imports файлы или набо ры из сторонних продуктов Сами сторонние продукты в этой папке не там были только библиотеки и заголовки. В результате в разделе Imports совсем немного изменений. Однако так как эта область использовалась для хранения сторонних продуктов, было очень важно не вносить без четкого Часть Люди, организация и методы и связей с элементами, на которые эти из менения могли бы подействовать.

Табл. Примерная структура папки Imports.

Имя файла и уровень Содержание Библиотеки и RogueWave Библиотеки и заголовки ObjeccSpacc С компиляции, библиотеки и Visual С Shield Библиотеки и Shield Прочие Папки для каждого инструмента или библиотеки В мы писали сценарий сборки продукта на выде ленной Сценарий должен был выбирать нужные для сборки файлы из системы управления исходным кодом. Эта информация как сами средства компоновки, так и исходные файлы, заголовки и необходимые Для ведения процесса компиляции мы выбрали — попу лярное средство управления компоновкой. Nmake сначала собирает части продукта, а компонует оконча тельные файлы продукта.

Сценарий компоновки в качестве данных при нимал метку сборки, позволяло нам ные версии продукта. Так как мы маркировали и отбирали и средства сборки, и файлы продукта, то таким образом мы среды.

компоновки также стандартные переменные и макросы, так что мы собирали все части и про дукты одного вызова. То, что наша Глава 5.

и разработчики использовали и те же компоновки, позволяло файлы проек та просто и без ошибок.

автоматическая система — ходимое условие разработки. Затраты времени и сил на то, чтобы заставить работать, своего сто ят. Этот и другие вопросы применения технологического ПО обсуждаются главе 7.

Устранение проблем и неисправностей Разработка ПО — это динамичный процесс с интенсивным обменом информацией между его участниками. При рабо те над проектом очень определить фор мальные методы поиска и проблем, ностей и которые постоянно появляются. Приме нение специальных продуктов для устранения проблем и неисправностей — один из лучших выходов. В оставшейся части объясняется, как эффективно та кие продукты.

О чем пойдет речь ПО для устранения проблем и позволяет справляться с бесконечными ошибками и всплывающими на поверхность в процессе разработки. Эти программы позволяют обновлять, устанавливать приоритет, сортиро вать и пересматривать информацию, полученную в цикле разработки проекта. Они являются важной частью любого проекта независимо от его размера. Никто не в состоянии запомнить все ошибки проблемы, которые следует шить. И если они не протоколируются, не пересматривают ся и для них не приоритет, качественного продукта не создать.

to Часть 1. Люди, организация и методы Что туда входит В NuMega использовали систему устранения проблем и не исправностей для хранения любых постоянных или вре менных данных о проекте, которые только можно было представить. Туда входили все программные ошибки (в том числе функциональные, затрагивающие производитель ность, процесс установки и параметры, а также все ошиб ки при сборке) и решения или предложения по улучшению проекта, его настоящих и будущих версий. Здесь действует простой, но очень важный принцип: все данные должны храниться в одном месте. Не следует держать их в храни лище, не обеспечивающем совместное ре зервное копирование и простой доступ. (Поэтому сообще ния электронной почты не подходят!) Я бы не советовал писать собственные программы по ус транению проблем и так как хватает раз личных коммерческих программных по разум ным Например, PVCS Tracker, Rational и др. Хотя вам потребу ется самим определить, какая из них отвечает вашим по требностям, я настоятельно рекомендую принять реше ние в пользу покупки. Ведь вы не обязаны тратить время на создание собственных инструментов, ваше дело — по ставлять ПО.

Рассмотрим пример. Разработчик замечает, что произ водительность в одной из частей приложения здорово сни зилась, и сообщает об этом по электронной почте в конфе ренцию разработчиков. А дальше? Кто заметит сообщение, а кто и нет. Даже если кто-то находит неполадку, ее нужно запротоколировать и устранить, иначе о проблеме просто забудут. Послать сообщение по электронной почте — не плохо, но не зафиксировать наличие неисправности Глава 5. Инструментальные программы беда. То предложений по выпуску. Есть вероятность, что на предложение никто не откликнется, и если электронной почты было послано без токолирования, то не будет и никакой истории работы над предложением.

Как это работает пример показывает, насколько важно автома тизировать элементарный обмен информацией между чле нами команды. Запомните: инструмент должен работать на вас, и никак иначе. Вам нужно информацией про сто и без лишних формальностей. В то же время вы долж ны следить за соблюдением дисциплины и не допускать небрежности. Для этих целей используется система устра нения проблем и Сконфигурируйте ее чтобы собирать основные данные о проекте:

текущее проблемы: открытая или закрытая;

• дата возникновения, изменения и решения;

текстовое описание проблемы;

• номер выпуска/сборки программы, в которой обнару жена проблема;

• имя человека, описавшего • имя человека, работающего над проблемой в настоящее время;

• состояние проблемы: расследуется, требуется больше ин формации, ожидается решена и т. д.;

приоритет высокий;

выпуск, в котором присутствует проблема;

• статут процедуры контроля качества;

количество попыток неуспешного решения проблемы;

• список к отчету проблеме или неисправ ности.

Часть 1. Люди, организация и методы Посмотрим, как мы использовали ПО для устранения проблем и неисправностей в Из собственного опыта Когда я начинал работать в NuMega, и другие раз личные неисправности фиксировались на доске (если вообще фиксировались). Они оставались там до тех пор, пока не были исправлены, а затем их просто стирали. Ког да доска заполнялась полностью, новые записи втискива ли в уголок или, чтобы освободить место, стирали другие ошибки. Эта система работала для одного-двух человек, но истории работы над ошибками не было.

С ростом организации становилось очевидно, что нам требуется автоматизированное решение. Если бы мы в то время не перешли к нему, то не смогли бы успешно вырастить свою команду. Хотя поиск инструмента, спо собного решить наши проблемы, и не был сложен, спо соб его использования часто становился предметом спо ра. В конце концов мы выяснили, что для группы нашего размера куда важнее выполнять на всего не сколько функций, чем пытаться делать все, что мы можем только представить.

Для ошибок — одно хранилище У нас было простое правило: обо всех ошибках системе устранения неполадок. Если их там значит, их не существует. Это здорово упростило управление мероп риятиями по исправлению ошибок. Сплетни, кулуарные разговоры и сообщения электронной почты не годятся в качестве методов протоколирования ошибок. Скажем, если информация о неисправности приходит от службы техни ческой поддержки, управления продуктом, отдела продаж — словом, от кого угодно, то эта информация не признавалась официально до ее ввода в систему. С ростом ком Глава 5. Инструментальные большая часть по протоколированию оши бок ложилась на плечи службы технической поддержки, но идея оставалась той же.

Как далеко это заходит? Значит ли это, что если у одного разработчика возникла проблема с API, который реализо вал другой разработчик, то ее сразу же нужно запротоколи ровать? Вовсе нет. Разработчики могут решить проблему друг с другом самостоятельно, и тогда ее не нужно прото колировать. Однако если решение проблемы займет неко торое время и требует наблюдения (что особенно важно), то необходимо занести ее в систему и описать, чтобы не забыть о ее существовании. Эти правила распространяют ся на всех членов команды и на все отделы.

Другое преимущество от протоколирования неполадок — возможность отчитываться о них, Как здорово пойти на текущее совещание с полным списком всех крупных непо ладок и людей, над ними работающих! Это эффективный способ фокусировать внимание в процессе разработки на важных вопросах. Заявивший об ошибке будет польщен тем, что ее признали и она обсуждается. А тот, кто назначен для ее поймет, что теперь не отвертеться, изменениями Как было сказано в начале этого раздела, процесс управле ния изменениями может осуществляться при помощи сис темы устранения проблем и неисправностей. Так как серьезные проблемы запротоколированы, вы можете соста вить список необходимых исправлений. После того, как по конкретной неисправности принято решение, просто вне сите информацию об исправлении в историю. Возмож ность пересматривать прошлые решения и причины их принятия — большой плюс. Это позволит избежать отгово рок типа не помню* или меня не было на том совещании». Все просто, понятно и под контролем.

L Часть Люди, организация и методы Приоритеты но основе Хотя классификация «низкий, средний и высокий» часто полезна при назначении проблемам приоритетов, же в одной категории оказываются десятки и даже сотни ладок. Чего не хватает в таких приоритетах, так это элемен та времени. Очень часто есть ошибки с высоким приори тетом, которые нужно срочно исправить к бета-версии, а есть такие таким же приоритетом), что могут до последнего выпуска, поскольку они очень сложны или требуют дополнительного исследования.

Рассмотрите включение поля «Исправить к дате* для установления приоритетов на основе критерия Значения, помещаемые в это поле, могут браться на ве внутреннего графика выпуска проекта, например, здесь может быть определенный этап, бета-версия или кандидат на выпуск. Чтобы определиться с задайте себе вопросы: «эту проблему нужно решить к пу 2 или бета-версии «что, если мы выпустим продукт сейчас, а ошибку исправим в следующем С течением цикла разработки следует назначать для каждой ошибки конкретный срок исправления. Поступая так, вы без труда получите текущий список неисправностей для любого выпуска, в том числе для следующего.

Проверяйте и ошибки Одна из главных задач, выполняемых при контроле каче ства, — проверка того, что ошибки на самом деле лены. На этом этапе мы убеждаемся в том, что разработчик действительно осознал и провел количество испытаний. ошибка исправлена и соот ветствующие изменения внесены в исходный код, разработ чик устанавливает поля «Контролю качества: под на а статус — на процеду ра контроля После того, как система контроля Глава 5. программы качества проверила исправление ошибки, ус танавливает ее статус Проблема может быть зак рыта только системой контроля качества после соответ ствующей проверки.

по выпуску Когда мы сталкивались с неполадкой, которую следует опи сать в замечаниях по выпуску или файле Read Me, мы изме няли ее статус на «Release Notes», но ее открытой.

В примечаниях по выпуску описываются известные пробле мы, способы их обойти и информация, появившаяся в пос ледний момент и не попавшая в официальную документа цию. Когда наступал момент выпуска бета-версии или окон чательной версии, было очень просто составить список проблем, о которых следует указать в замечаниях по выпус ку. И только после того, как проблему разрешили, мы окон чательно ее закрывали.

Используйте стандартные запросы Чтобы осуществлять полноценный поиск по базе данных проекта, важно иметь стандартных запросов. Эти запросы должны использоваться совместно и быть доступ ны всем членам команды;

важно, что у каждого будет оди наковая картина данных. Хотя частные запросы хороши для редких и особых требований, их не следует использовать для заданий членам команды. Риск непра вильного составления запроса или указания неиспользуе мого более поля достаточно велик. В таблице представле ны наиболее важные запросы.

Запрос Позволяет Все открытые ошибки менеджеру проекта и руководству оценить проект в целом Все открытые ошибки команде увидеть, какие ошибки для конкретного этапа остаются открытыми в проекте для заданного этапа [ Часть 1. Люди, организация и методы Запрос Все открытые ошибки каждому человеку просмотреть для конкретного человека свой текущий список Все открытые ошибки каждому просмотреть для конкретного этапа свой список ошибок для и человека этапа Все открытые ошибки команде тестировщиков с полем «Контролю качества: просмотреть свой план = «Истина» тестирования Все открытые ошибки менеджеру и с полем Предложения» = пересмотреть текущие ния по изменениям Другие способы применения Далее приведены другие важные способы информации, попадающей в базу проблем и неис правностей. Эта информация поможет менеджеру проекта и руководству оценить мероприятия по проекту на макро уровне, а также другие проблемы, съедающие значительную часть времени. В цикле разработки команда а может, и тысячи ошибок и проблем, и поэтому по нимание того, что же все-таки происходит с течением вре мени, может быть очень Интенсивность и устранения ошибок Интенсивность возникновения — это мера того, сколько новых или неисправностей было обнаружено за определенный период времени. Интенсивность возникно вения взлетает вверх в начале проекта, но с течением вре мени снижается. Интенсивность устранения — это мера того, сколько ошибок или неисправностей закрыто за оп период Она снижается по мере уст ранения ошибок. Ниже показана возникно вения и устранения ошибок — для проекта эти данные гут быть весьма полезны (рис. и 5-2).

Глава 5. программы Количество ошибок Время ошибок Устранено Рис. Интенсивность возникновения и ошибок в начале проекта.

Количество ошибок Этап Обнаружено ошибок Устранено ошибок Рис. 5-2. возникновения и устранения ошибок в моменты, когда проект близится к завершению определенного этапа.

Как соотносятся интенсивность возникновения и уст ранения ошибок? В начале проекта вы столкнетесь с мас сой новых проблем, которые обнаруживаются (открывают ся) быстрее, чем устраняются (закрываются). По ходу ра боты интенсивность возникновения по к интенсивности устранения перестанет расти и снизится.

так как проблемы закрываться быст рее, чем новые обнаруживаться. Особого внимания ;

: i Часть 1. и методы требуют резкие скачки, которые могут проявляться в опре деленный Рассмотрите зафиксирован ную в этот период, чтобы определить, не она ли породила еще большее количество новых Обычно, когда близится завершение внутреннего эта па, выпуск бета-версии и кандидата на выпуск, интенсив ность устранения выше интенсивности возникновения.

Если это не так, то новых проблем появляется больше, чем решается, а это не то, что вы бы хотели видеть, ясь к периоду стабилизации или выпуску.

устранения поможет вам определить эффективность обнаружения причин возникновения непо ладки, а также примерный срок устранения кото рые могут появиться в будущем. Скажем, если интенсив ность устранения в течение двух последних недель состав лял 10 ошибок в день, это может быть большим успехом.

Если у вас открытых ошибок, то вполне закономерно ожидать, что все они будут устранены приблизительно в течение следующих 10 дней. Эта цифра конечно же не точ на (для исправления какой-нибудь неполадки может потре боваться и неделя), но она позволяет понять, чего вам сле дует ожидать при наличии большого количества оставших ся ошибок.

изменении Количество также может о многом поведать.

Количество изменений показывает число обновлений ин формации о неполадке. Причина обновления не имеет чения. Большое число — верный знак того, что не все идет так гладко. Так, оставшаяся неполадка может исследоваться многими людьми, и ни один из них не уста новит причину ее возникновения. Возможно, ее передава ли из отдела технической поддержки к разработчикам, от — к разработчикам или между двумя I Глава 5. программы туда и обратно. Наблюдение за количеством из менений информации об ошибках поможет определить те, что требуют внимания со стороны ведущих специалистов и менеджера проекта.

Счетчик неудачных исправлений Еще один хороший способ оценки нестабильности проек та — счетчик неудачных исправлений для всех ошибок, ко торые считались но на самом деле лены не были. При устранении неполадки от команды требуется подтверждение того, что ошибка действительно исправлена. Если проблема все еще существу ет или исправление не принято, ей возвращается статус от крытой, а значение поля «Исправлено устанавли вается в 1. Если снова не могут подтвердить устранения неполадки, значение счетчика увеличивается до 2 или 3. Это сигнализирует о серьезности проблемы и го ворит о необходимости вмешательства ведущих специали стов или менеджера проекта.

Дополнительные средства Хотя средства управления исходным кодом и устранения проблем были стержнем процесса разработки в мы использовали и другие инструменты.

Отладчики Одним из наиболее важных для наших раз работчиков был разработанный NuMega неве роятно мощный отладчик для Windows — Он за гружается при запуске системы как драйвер устройства на уровне ядра и предоставляет беспрецедентные сти управления и наблюдения за процессами приложения и системы. Команда разработ чиков часто использовала SoftlCE для разрешения наиболее сложных проблем при отладке.

.

Часть 1. Люди, организация и методы Средства анализа производительности и полноты Мы часто использовали средства анализа производительно сти, в том числе наши продукты и для настройки производительности собира емых приложений. Мы поняли, что эти инструменты нуж но использовать регулярно в течение цикла разработки, а не в самом конце, когда времени на оптимизацию или уст ранение проблем не хватает. Анализ производительности проекта по завершении определенного этапа или при вы пуске бета-версии предупреждает проблемы и часто крывает ошибки, которые могут проявляться в коде до самого выпуска. Не пока вы столкнетесь с проблема ми а начинайте сразу применять сред ства анализа производительности.

Мы также поняли, что эти средства работают наиболее если проект специально разрабатывается с учетом анализа производительности и полноты. Собирая такие приложения, мы интегрируем их с нашими тестовы ми заданиями для раннего обнаружения проблем с произ водительностью или для лучшей оценки полноты наших тестовых заданий, Средства написания сценариев и автоматизации тестирования Так как наши планы тестирования требовали максимально возможной автоматизации, мы всегда интересовались ин струментами, способными нам в этом помочь. Наиболее важными были средства сценариев (Perl, команд ные файлы DOS и т. п.) и средства автоматизации тестиро вания. В то время Visual Test был доступен по разумной цене и предлагался взыскательным и раз работчикам. С его помощью мы тестировали пользователь ский интерфейс, но в подавляющем большинстве меропри ятий по автоматизации полагались на средства написания сценариев.

Глава 5. Инструментальные программы Из собственного опыта Когда мы создавали группу разработки ПО, проверяюще го исправность кода, члены команды не были до конца уверены в его значимости. Но с продвижением проекта, когда команда начала применять собственный продукт на собственном коде, стало ясно, что если разработчики блочно тестировали свой код с полнотой 80%, то качество продукта заметно повышалось.

Типичные проблемы и их решение Далее обсуждается ряд проблем и вопросов, никающих при использовании описываемых здесь а также их решения.

Проблемы с инструментами Отбор нужных Одна из главных оши которую допускают команды разработчиков, — иг нужных инструментов. Я убежден в том, что система управления исходным кодом и система транения проблем и неисправностей необходимы, В равной степени для команды разработчиков важны средства отладки, поиска ошибок, оптимизации произ водительности и проверки полноты. Они помогут ре шить многие уникальные проблемы, всплывающие на поверхность в процессе разработки.

Все, что может ускорить и автоматизировать цикл разработки, критично для графика. Слишком часто графики сбиваются, так как сложные ошибки или проблемы с производительностью вносятся в процес се разработки, но не выявляются на раннем этапе.

да они обнаружены, людям без посторонней помощи устранить их практически невозможно. Времени искать нужные инструменты в Интернете просто не Убе дитесь, что определились с инструментами, которые i Часть Люди, и методы вам понадобятся, интегрировали их в процесс разра ботки и обучили работе с ними.

па пути Одно из глав ных искушений в разработки — замена того, что вы используете сейчас, новой версией или инстру ментом от другого Последствия решения обычно не просчитывают. Я не могу предста вить себе смены управления исходным кодом или проблем и неисправностей без значи тельного сдвига графиков. Обычно лучше дойти до ко нечного выпуска с тем, что у вас имеется, нежели менять это на полпути.

Проблемы управления исходным кодом • Структура проекта С ростом проекта структура си стемы исходным кодом становится очень важной. Хотя здесь я предлагаю стандартный способ работы, не забудьте спланировать систему в ствии с нуждами вашего проекта. Вы должны принять, во внимание фактор одновременного выпуска несколь ких версий (пакеты обновлений, сокращенные и пол ные а потребности разработчиков, фактор обучения пользователей, ческий фактор и технологические потребности.

• Содержание Не обманывайте себя, думая, что ный код — это всего лишь набор контроля над изменениями. Как было отмечено управления требует великое множество файлов и ментов — не ограничивайтесь преимуществами ля над изменениями только для исходного кода. Даже если придется людей, отвечающих за кон троль качества или обучение пользователей, время дет потрачено не зря.

I Глава 5. Инструментальные программы Конфликты файлов Типичный случай: раз работчику X был выдан файл, и поэтому разработчик Y не может его взять для внесения важных изменений.

Такие конфликты из-за файлов способны над проектом. Предусмотрите способ быстрого внесения исправлений или изменений.

Лучший способ решить эту проблему — предотвра тить ее появление. Подумайте, можете ли вы разделить наиболее на несколько файлов, основываясь на логических подсистемах, ком понентах и классах. Разбивка содержимого файлов уменьшает вероятность конфликтов.

Когда разделить содержимое файлов невозможно, например из-за жесткой связи между блоками, следует разработать политику, предусматривающую возврат файлов в течение определенного количества часов пос ле выдачи. Также в случае недоступности файлов про граммисты могут работать над их копиями, а не над оригиналами. Ставший доступным файл можно взять на короткий срок, быстро обновить и возвратить на место.

В большинстве систем управления исходным кодом поддерживается файлов. Это позволяет совме стить в файлах, Хотя обычно эта функция работает не позволяйте операцию слияния проводить автоматически. Вы должны что проверили все изменения, сделанные в файле. Если в нашей системе управления исходным кодом поддерж ка слияния реализована плохо, можете воспользовать ся такими редакторами кода, как Visual Slick Edit и Code Write. Они помогут выявить различия визуально и про верить результат перед его реальным осуществ лением.

I Часть 1. Люди, организация и методы • Маркировка Одно достоинств системы уп равления — маркировки набора файлов, включенных в выпуск. Не забывайте проделывать этот этап работы каждого пуска, в том па основных уровнях, по при выпуске бета-версий и т. д.

Метки должны не только для фай лов с исходным кодом. Помечайте файлы-сборки, уста новочные файлы документации, файлы контро ля качества — словом, все включенные в выпуск Метка должна информативной и согла шениям об именах, принятым для проекта.

Из опыта Однажды у работала команда, которая свою поиска ошибок во время разработки. Спус тя некоторое время они пришли к выводу, что им следу ет переключиться на использование продукта, так как в нем были новые возможности. Они запустили и загрузили ПО. К сожалению, недели работы с продуктом они обнаружили, что там нет поддержки некоторых а производительность программы Им было к щей системе, но так как в новой версии не было предус мотрено процедуры автоматического обратного перехо да, им вручную записи об ошибках и неполадках, с момента перехода.

Проблемы поиска ошибок и неисправностей Обеспечение ных в системе должно быть приоритетной задачей.

Если вы не будете доверять в системе, то не станете ее использовать, и она потеряет свою значи мость. Очень важно правила обеспечения \.

Глава 5. Инструментальные целостности в большинстве на процессе разработки. Так, никогда не должны с которые «закрыты», но для них установлен статус Чтобы отображать работу над ошибками, нужно со вре изменять статус ошибок. Также убедитесь, что вы вводите правильные значения в поля об этапе, информацию о выпуске и т. д.). Какими бы ни были у методы целостности, допускайте или ших данных, иначе команда будет при данным а вся система пере внушать доверие и станет бесполезной, Лучший способ избежать проблем с целостностью данных — это убедиться в том, что команда осознает важность этих и может обнаруживать и проблемы самостоятельно. Собственная за работает если вы продемонстрируете реаль ную значимость этих для команды. Не забудьте также периодически данные и дать результаты с командой, Я показал некоторые способы моделирования клю цикла разработки с применением средств устранения проблем и неисправностей. Одна ко стоит увлекаться и все, что только может подойти для вашей команды. Вместо этого опре делите ключевые потребности для процесса разработ ки и выберите простые средства для их реализации.

] системы контроля качества Часть организация и методы роблемы с контролем качества могут разрушить про ект: сорвать сроки или испортить продукт что по требители не смогут им пользоваться. Какой бы ни была ваша компания — начинающей или транснациональной вы должны эффективно балансировать меж ду качеством продукта и временем его представления на рынке. Успех или неудача зависят именно от этого.

В этой главе мы рассмотрим основы системы контро ля качества в динамичной среде с ограниченными ресур сами, обычной для современных проектов по разработке ПО. Мы остановим свое внимание на том, что, когда, как и кто должен тестировать. Затем я продемонстрирую общее решение и расскажу о некоторых простых и эффективных приемах управления тестированием.

Основные принципы Начнем с принципов работы системы контроля качества.

Лейтмотив — обеспечение качества непосредственно в процессе разработки. Продукту нельзя придать качество позже без значительных затрат денег, сил и времени. Созда ние качественного продукта основывается на четырех про стых принципах:

• тестирование продукта осуществляется параллельно с процессом его разработки;

• качество продукта улучшается регулярно при заверше каждого планового этапа разработки;

• необходимо максимально автоматизи ровать;

качество является частью культуры и технологии, Параллельное тестирование В среде с ограниченным временем поиск и устранение про блем в кратчайшие сроки с момента их появления — усло вие необходимое. Раньше узнаешь о проблеме — раньше I Глава Основы системы контроля качество Ваша задача — тестировать функции программы сразу после их окончательного создания. Это и называет ся параллельным Чтобы его осу вы должны иметь средства автоматизированно го тестирования или ресурсы для проведения ручных тес тов, доступные в момент реализации новых функций. Если реализация функции запланирована на конец пятой неде ли, то команда испытателей должна быть готова протести на шестой. Это правило следует применять ко всем основным Хотя автоматизированное тес тирование предпочтительнее, к запланированному ту должны готовы и ресурсы для ручного проведения этой операции.

Ниже представлен идеальный график параллельного тестирования набора функций программы (табл. 6-1). За метьте, что разработка и тестирование идут максимально плотно друг за другом. Реализация функции завершается в конце неделе, команда испытателей готова приступить к в начале следующей. Хотя разработчики от ветственны и за создание кода, и за его базовое тестирова ние, команда в заданный период проверя ет функцию по максимуму. Так как разработчики и тести должны работать над функцией вместе, их называют Разработчики и несут обоюдную ответ за своевременное обеспечение качества. В та кой системе реализация функции не завершается написа нием кода. Функция считается законченной, если она проверена и соответствует заданным критериям. Разработчики и тестировщики должны вать, что для работы над функцией они долж ны работать вместе, У каждой группы задачи (написа кода, тестирование, т. п.), но чтобы сделать всю работу, они действовать сообща.

Часть и методы Нельзя переходить к следующей если текущий набор функций не проработан окончательно и не стабили зирован.

Табл. 6-1. работы оперативной команды над функциями А, В и С.

работ По графику По графику разработки 1 Разработка Написание кода Планирование функции А тестов для функций Неделя 2 Разработка Завершение кода Планирование функции А для функций Неделя 3 Разработка Написание кода Тестирование функции В функции А Неделя 4 Разработка Завершение кода функции В функции А (или планирование тестов для функции В) Неделя 5 Разработка Написание кода Тестирование функции С функции В Неделя 6 Тестирование и Тестирование устранение непо- функций ладок в функциях Аи В Неделя 7 Стабилизация Тестирование и Тестирование непо- совместной ладок в функциях работы функций Неделя 8 Разработка Завершение кода Планирование функции С тестов для С Запомните: должно разрабатываться функций не более, чем вы можете обеспечить их сотрудни ками. Иначе говоря, число оперативных команд должно числе функций, для которых допустима параллельная работа (разработка и те Глава 6. Основы системы контроля больше, чем разработчиков, или наоборот, то при использовании такой модели разработки команда счи тается несбалансированной, и вам следует набрать дополни тельный персонал в те области, где испытывается дефицит.

Наконец обратите внимание, что я добавил в график работ фазы стабилизации и интеграции. Эти фазы позво ляют команде укрепить программу по завершении ключе вых этапов, прежде чем продолжить работу над оставшей ся частью проекта. Необходимость стабилизации и интег рации мы рассмотрим в следующем разделе. О том, как встроить периоды стабилизации и интеграции в график работ, см. главу Стабилизация и интеграция Через каждые 4-6 недель команда должна отводить I -2 не дели (в зависимости от сложности проекта) на тестирова ние, стабилизацию и интеграцию функций, к данному моменту. Такие периоды стабилизации и интегра ции идут на пользу команде, функциональности и качеству.

Вы можете завершить незаконченное тестирование, начать интегральную проверку функциональности и определить проблемы, которые следует решить, прежде чем продол жить работу над проектом. Не обращайте особого внима ния на мелкие неисправности и детали. Просто перед на чалом очередной стадии убедитесь, что структурно и фун кционально проект находится в хорошем состоянии.

В течение этого периода члены команды должны на правлять свои усилия только на стабилизацию и интегра цию. Не работайте над новыми функциями, кодом или чем то еще до тех пор, пока вы не будете уверены в стабильно сти того, что уже построено.

Периоды стабилизации и интеграции также позволяют сопоставить фактическое продвижение проекта с заплани рованным. Если проект хорошо спланирован, вы будете ) Часть 1. организация и методы точно знать, на какой неделе, какая функция будет заверше на. Укладываетесь ли вы в график? Можно ли использовать определенные в намеченный срок? Эта информа ция необходима для чтобы не дать проекту выйти из колеи. Повторю, что о календарном планировании подроб но говорится в главе а сейчас просто запомните, что вам нужно заранее определить периоды, во время которых вся команда, работающая над проектом, будет концентриро ваться на стабилизации и интеграции программы.

Автоматизация Максимально возможная автоматизация процесса тестиро вания — ключ к параллельному тестированию (и раннему обнаружению ошибок). предоставит вам следующие преимущества.

• Сокращение внутреннего цикла тестирования матизация помогает выполнять тесты быстро. Для па раллельного тестирования вы должны будете в течение всего цикла разработки иметь постоянную возмож ность тестировать большие части продукта за короткий промежуток времени. Ручное тестирование требует мас су времени, больших трудовых затрат и не слишком надежно. Его нельзя выполнять каждую ночь после оче редной сборки. — единственный способ добиться максимальной эффективности от параллель ного тестирования.

• Сокращение потребностей в персонале Автоматиза ция значительно сокращает расходы на рабочую силу.

стоимость выполнения автоматизиро ванного тестового задания ничтожна по сравнению с ценой выполнения этой операции вручную.

• Проверка внесенных в последний Изменения, которые вносятся последнюю минуту, избежньт, и четкие автоматизированные тестовые зада • !б Глава 6. Основы системы контроля качества незаменимы для проверки того, что эти изменения не к серьезным проблемам. Выпол нять вручную все обязательные тесты после внесения лишь нескольких изменений дорого и порой просто не возможно,. для новых выпус ков С каждым новым выпуском команда должна быть уверена в том, что функции из предыдущих все еще Если вам снова предстоит вручную все функции из прошлого выпуска, у не останется ресурсов для тестирования но вых функций в том же объеме. С течением времени чис ло тестов, которые нужно выполнить вручную, станет огромным. Автоматизация тестирования функций пре дыдущих выпусков поможет решить эту проблему.

Из собственного опыта Однажды, в очередной раз сообщив боссу о продвижении проекта и заверив его в том, что все в порядке, я устано вил сборку и нажал на кнопку выполнить наиболее кри тичную функцию проекта». Она не работала.

что уже много сборка была сломанной, хотя боль шинство об этом не знало. По нашему графику мы уже давно прошли период разработки и тестирования этой и коль уж однажды она работала как часы, то должна была работать и сейчас. Сейчас мы поняли, что если наиболее критичная функция была неста бильна, то состояние остальных функций, которые тог да работали, сейчас также неизвестно. Все были так заня ты написанием нового кода и тестированием до функций, что никто не заметил того, что больше не работал. Бета-версия была отложена на несколько недель.

В тот момент я и моя команда поняли всю важность автоматизации тестирования для нашего проекта. Мы на Часть 1. Люди, и методы писать автоматизированные регрессивные тесты для ключевых функций, запускать их каждый день и немед ленно устранять серьезные неполадки.

Чаще всего автоматизацию критикуют из-за времени, необходимого для создания хороших тестовых заданий. Да, тестовые задания требуют материальных и трудовых затрат, но, созданные на совесть, они приносят большие дивиден ды. Я рекомендую выделить нескольких специалистов по автоматизации, чьей задачей в цикле разработки будет только написание автоматизированных тестовых заданий, необходимое для поддержания адекватности те стов будущим выпускам, также является объектом нападок.

Особенно это относится к автоматизации тестирования пользовательского интерфейса. Если между выпусками в вашем пользовательском интерфейсе происходят серьез ные изменения, то тестовые сценарии могут не работать и потребовать больших усилий для их совершенствования, По этой причине при автоматическом сле дует сосредоточиться на функциях, не относящихся к пользовательскому интерфейсу. Автоматизируйте тестиро вание ключевых функций, а не деталей пользовательского интерфейса.

Отличная идея — строить продукт, изначально рассчи танный на тестирование. Если вы минимизируете свою за висимость от пользовательского интерфейса и создадите альтернативные способы ввода данных и просмотра выход ных данных, то будете защищены от изменений в интер фейсе. Например, рассмотрите возможность использова ния файлов, записей реестра, параметров командной стро ки и СОМ-интерфейсов передачи входных данных. Для вывода данных вы можете использовать текстовые файлы, распечатку значений переменных или готовые компонен ты, специально предназначенные для этой цели. Я не гово I Глава 6. Основы системы контроля рю о том, что пользовательский интерфейс не должен быть — просто приоритетным должно быть автоматизированное тестирование ключевых функций Однако если вы решили автоматизировать тести рование пользовательского интерфейса, начните с «контакт тестирования. При этом, чтобы проверить функцио нальность всего интерфейса, вызываются и закрываются все диалоговые окна.

Из опыта Работая в над 5, мы знали, что команда, создающая внутренние компоненты, значитель но опережает команду, занятую интер фейсом. И мы должны были быть в том, что смо жем тестировать продукт, даже если у нас не будет пользо вательского интерфейса месяц или больше.

отвечающая за компоненты, разрабатывала простые драйверы, вызывавшие подсистему с данными, необходимыми для работы. Используя эти драйверы, мы могли тестировать продукт и убедиться, что он тверд, как скала, задолго до того, как пользовательский интерфейс был готов, Помимо раннего тестирования продукта, драйверы предоставляли надежный и простой способ ав томатизированного тестирования подсистем разных вы пусков.

процессы и культура У вас есть опыт создания качественного ПО? Ваши логические процессы производительны и эффективны или они обычно занимают кучу времени и ресурсов? Учитыва ется ли вопрос качества каждым человеком, участвующим в разработке ПО? Как далеко вы готовы пойти, чтобы обес печить качество? О качестве заботится каждый или есть та кие, которые говорят;

«это не мой Часть 1. Люди, и методы Эти вопросы могут определить, насколько группа ус пешна в качественного ПО. Иногда говорят, что высшее руководство не брать на себя обязательства, необходимые для создания качественных продуктов. С дру гой стороны, они, может быть, и хотят поставлять каче ственный продукт, но не уверены в том, что у команды есть для этого эффективная система. Они считают, что ние количества процессов контроля качества всего лишь приведет к дополнительным затратам времени и повысит расходы без улучшения продукта. Одной из задач этой кни ги является определение конкретного набора процессов контроля качества, которые позволят поставлять лучшие продукты в кратчайшие сроки, насколько это возможно.

Однажды обзаведясь системой, в которой вы уверены, вы вероятнее всего станете поддерживать и постоянно исполь зовать именно ее.

Из собственного опыта В проекта определял качество как глав ный приоритет для каждого члена команды. Он устанав ливал продукт и использовал его почти ежедневно, фик сировал ошибки и обсуждал обнаруженные неполадки со своей командой на совещании, в обеденное время и встреч в коридоре. Это подгоняло всю команду, и каждый ее участник включался в работу. и оцен кой результатов занимались все. Все осознали: ошибки — это зло, и с ними надо бороться. Мы давали всем понять, что до самого конца проекта о качестве будут помнить и не забудут после продажи продукта.

когда и как тестировать только если понятно, какую часть продукта, когда и как тестировать. Вроде вопросы но если вы работаете в жестком графике и с Глава 6. системы контроля качества людскими то вам терять время, тестируя объект слишком глубоко слишком поверхностно. Нужно сосредоточиться на ьерке в следующих ключевых областях продукта:

процедуре установки;

функциональных • интеграции функций;

• производительности.

Тестирование в этих областях должно происходить по стоянно в течение всего цикла разработки. Однако для эф фективного выполнения процедуры вам нужно знать, когда и как проводить тесты в каждой из этих областей, Короче говоря, для каждого крупного мероприятия в про цессе разработки вы должны обладать набором хорошо определенных процессов и процедур, которые будут отлав ливать проблемы. Эти процессы и процедуры в себя следующие компоненты.

• Входные тесты Проверяют перед подтверждени ем внесенных изменений.

Ежедневные базисные тесты Выполняются для каж дой сборки программы.

• Тесты по завершении функции Проверяют функцию сразу же после завершения работы над ней.

• Тесты при стабилизации и Проверяется интеграция функций через определенные интервалы времени.

• и кандидаты выпуск Произ водится внешнее тестирование продукта через опреде ленные интервалы времени.

В оставшейся части этой главы мы поговорим об этих пяти ключевых разновидностях тестирования.

I.

Часть 1. Люди, организация и методы Позволяет разработчикам проверить важные функции в локальной сборке перед помещением кода в основную базу Хорошие тесты должны обладать:

• между всеми машинами;

• простотой запуска и выполнения:

проверять ключевые или подсистемы продукта.

Входные тесты ценность для случаев, когда вы вносите исправления в критичную или сложную часть системы. Если входной тест выполняется неудачно, вы можете самостоятельно найти и устранить неполадку. Вы не нарушите остальных разработчи ков, которые могут взять исходные файлы с пос ле внесения этих файлов вами в систему. Также входные тесты предотвращают внесение критических ошибок в сборку и сбой базисного тесга.

Ежедневное базисное тестирование Еще один способ реализации стратегии «тестировать как можно помимо входных тестов, базисные тесты. Так как вы строите продукт каждый то и тестировать его нужно ежедневно. Базисные тесты — это основной набор автоматизированных регрессивных тестов, проверяющих, что ключевые функции продукта ра ботают. Они обеспечивают создание сборки и гарантию того, что за прошедшие 24 часа не было значительных ухудшений. С добавлением новых ключевых компонентов базисные тесты также следует улучшать и рас ширять.

Из собственного опыта Продукт BoundsChecker компании хорошо стен за свою способность находить утечки памяти в при ложениях C/C++. Ежедневные базисные тесты для этой '.

Глава 6. Основы системы контроля программы включали в себя приложение в ко тором было множество утечек памяти, а также других от вратительных Мы использовали эту программу пример для генерации ошибок, которые должен был уметь искать. Если BoundsChecker находил не все ошибки в программе-примере, тогда по определению сборка считалась плохой. Нам нравилось получать по ут рам «еще дымящийся отчет о тесте» с результатами про верки сборки минувшей ночи. Такой процесс позволял нашему проекту почти всегда быть стабильным и работа ющем, поскольку наши базисные тесты сразу находили критические проблемы.

Заметьте: ежедневные базисные тесты не имели сво ей целью проверку незначительных таких как проверка работоспособности предварительного про смотра перед печатью, или вызов справочной системы по нажатию клавиши — все это легко проверить вручную.

Мы концентрировались на ключевых функциях проекта.

Как и ежедневная данные о базисных тестах (предоставляемая Б виде отчетов) совместно используют ся всей командой так, что каждому понятно, есть ли в про дукте проблемы или нет. Если руководители разработ чиков и должны провести расследование, быстро определить причину проблемы и назначить спе циалиста для ее разрешения. Для этого специалиста раз решение данной проблемы должно быть наивысшим при оритетом, Тестирование реализованной функции Итак, ваша задача — каждую функцию, как только работа над ней будет завершена. Для каждой важной функции должны быть назначены разработчик и щик, которые вместе будут отвечать за своевременную и качественную поставку этой функции. Такое назначение Часть Люди, организация и методы будет способствовать совместной работе, обмену цией и а успех или неудача разделятся поровну. Для каждой функции должны быть заготовлены тесты, но вы также должны быть готовы, понадобится, протестировать их вручную. В плане контроля качества быть изложена вся инфор мация так. чтобы было абсолютно когда и как те стируется каждая функции Основные усилия отвечающей за контроль каче ства, на ключевых функций. Их можно тестировать как так и вручную, но это надо делать сразу как разработчик Чем тестирование тем вы оцените та и, если обнаружатся проблемы, начнете их решать.

почти всегда будут находить Для их в графике разработки быть от ведено некоторое время в период разработки компонента или в ближайшем стабилизации. Я советую выде лять времени в обоих периодах. Скажем, в ном задании должен быть предусмотрен один день как раз для устранения то есть 20% «лишнего времени*.

К сожалению, установки — самая «забытая» любого продукта. Люди думают о том, что установка — это функция и поэтому не ей должного внимания. вы не протестируете процеду ру установки, можете пожалеть: этот компонент програм мы используют все. способ создать лепное первое — это разработать отличную процедуру установки. пользователь с первых минут недоволен программой.

:

Глава 6. Основы системы контроля качества Как и для остальных компонентов, для провер ки процедуры установки нужно выделить оперативную команду. То есть задача создания и проверки процедуры ус тановки назначается технологам и тестировтпикам. Эта за дача должна входить в план проверки качества и выпол няться регулярно течение цикла разработки. Помните, что обычно установка — очень сложная часть программы, она требует безупречной работы на самых разных конфигура циях. И здесь тестирование незаменимо.

Вот список основных тестов процедуры установки, ко торые должны быть для продукта, рый вы собираетесь поставить.

• Проверка на всех ных системах, поддерживаемых вашей программой.

• Сервисные пакеты со всеми па кетами ОС, поддерживаемых вашей Проверка установки продукта на ОС, где не установлены предыдущие версии программы.

• «Грязная» установка Проверка установки продукта на ОС с установленными предыдущими версиями про граммы.

• Конфигурации продукта проце дурой установки различных продукта.

Функции установки Проверка собствен ных процедуры установки кнопка кнопка «Назад», и т. д.), процедуры удаления продукта.

Хотя хорошая процедура установки прежде всего пред назначена для вы тоже увидите, что она иг важную роль в ускорении работы по контролю качества.

Так как команда тестировщиков должна работать с самой сборкой программы, у вас постоянно должна 6 — деньги Часть 1. Люди, организация и методы быть надежная процедура которую они будут использовать. Ведь вы не хотите, чтобы команда тратила время на редактирование реестра, копирование файлов, ре дактирование параметров конфигурации и т. д. Вам направить их тестирование продукта, а не на руч ные в которых легко могут появиться ошибки, Надежная и простая в использовании уста будет полезна для всех членов команды, а не только для Каждый сможет установить продукт для своих собственных целей. Техническим писателям потре буется установка для создания описания функций продук та, — для отслеживания проблем с производительностью и оценки пользовательского интер фейса. Ваша команда должна работать с продуктом, а не бороться с его установкой, Из собственного опыта Не о удаления! В NuMega команды раз работчиков и тестировщиков оценили значимость про цедуры удаления. Ведь она позволяет получить чистую систему и не тратить время на ручное удаление реестра и файлов из системного каталога.

Тестирование при стабилизации и интеграции До этого момента в цикле разработки тестирование было направлено на проверку отдельных функций. Но в период стабилизации и интеграции внимание уделяется:

• завершению всех тестов отдельных функций;

• интеграции функций;

• проверке текущей производительности и нагрузки;

• исправлению всех ошибок, проек та или архитектурных проблем;

тестированию бета-версий и кандидатов на выпуск.

i Глава 6. Основы системы контроля качества Завершение каждого из этих очень важно для начала работы над следующей частью проекта. Давайте под робнее рассмотрим каждый из них.

тестирования отдельных функций номер один — тестов, которые мог ли быть отложены. Это вполне когда оперативной команде для всех тестов требуется больше времени, даже после 4-6 недель упорной работы.

Используйте это время для всех тестов, кото рые еще не были выполнены, так вы сможете поддерживать параллельное до самого конца проекта.

интеграции Тестирование интеграции должно быть определено забла говременно как часть плана тестирования. Лучший способ сделать это — создать набор примеров использования, предпочтительно с точки зрения пользователя, описываю щих, как различные функции должны работать вместе. Пе ред тестированием вы должны быть уверены, что заданные функции находятся в рабочем состоянии и в принципе мо гут использоваться вместе. Именно сейчас время их совмест ной проверки, и если они не станут работать, то настанет время ошибок.

производительности и нагрузки Хотя конечный продукт нельзя оценить до тех пор, пока вся система не будет собрана воедино, для оценки прогресса или его в цикле разработки могут проводиться наблюдения и предварительные измерения.

Не забудьте создать набор тестов, которые будут слу жить в качестве эталонных тестов для продукта, и выпол нять их регулярно в цикле разработки. Выполняйте стрес совые тесты и оценивайте производительность системы по завершении определенных этапов и в моменты I Часть 1. организация и методы и интеграции. Именно для этого разработка разби та на этапы. Выполнение тестов в эти моменты — лучший способ ошибок и их исправления до того, как вы продолжите строить ваш продукт на фундамен те, содержащем ошибку.

Из собственного опыта Во время разработки одной из главных проблем была производительность. Ничего не стоило полностью поменять характеристики сти добавив несколько строчек кода в критич ные Чтобы обнаружить источник проблем с мы несколько вых приложений, которые нагружали BoundsChecker до предела. Одно из таких приложений называлось Torture.

Оно создавало 256 параллельных потоков и запрашива ло и освобождало десятки тысяч блоков памяти куче. В течение всего периода разработки мы запускали Torture (и подобные программы), чтобы определить, не снизи лась ли производительность продукта. Так как мы хотели видеть результат сразу, мы стали каждую ночь запускать Torture как часть наших автоматических регрессивных те стов и сравнивать производительности. С та ким уровнем контроля мы обычно могли определять сни жение производительности в сборке предыдущего дня.

Весьма неплохо!

Коррекция после тестирования Период и интеграции также позволяет ис править серьезные ошибки до перехода к следующему па бору функций. функций и их интеграции выявит множество а это то, что нужно. Вы сможете заранее устранить эти ошибки, что увеличит дуктивность дальнейшей работы. Но время на поиск и ис правление этих ошибок должно быть учтено в графике.

1 Глава 6. Основы системы контроля качества после Когда период и подходит к кон не забудьте результаты и произвести изменения.

Усовершенствовать ли аппаратную часть? Нужно лучше те стировать Требуется ли лучшее API? Больше людей? Какие бы изменения ни требовалось провести, это нужно сделать Это также подходящий момент что имеет смысл улучшить во время следующего периода стабилиза ции и интеграции. Смотрите на фазу стабилизации и интег рации как на проверку ПО и команды, которая его создает.

Бы должны оценить производительность и и людей и провести все необходимые изменения.

Пример тестирования простой пример, чтобы показать, все эти области вместе. Допустим, вы создаете и проходите фазу стабилизации и интеграции, Вы уверены в работоспособности определенных Скажем, вам нужно только создание, редактирование и покупателей. Но чтобы заставить эти функции работать, нужно Их работа затрагивает зовательский интерфейс, Web-сервер, зве нья и базу данных. Все эти компоненты взаимосвязаны. В этом случае проверка интеграции может состоять из таких заданий:

+ попытаться добавить покупателя;

• некорректное добавление покупателя (проверка полей);

повторное добавление одного и того же покупателя;

• редактирование сведений о полей, ни одного поля);

• сведений о несуществующем покупателе;

• некорректное редактирование сведений о покупателе;

Часть 1. Люди, и методы • удаление покупателя;

• удаление несуществующего покупателя.

Завершив тестирование интеграции, вы обладать сведениями о приложения. Как долго добавить покупателя? А удалить? Получить сообщение об Хотя может быть несколько причин плохой про изводительности, если вы не можете быстро добавить по купателя в маленькой базе данных, возможно, имеется про блема, требующая дополнительного исследования. Есть ли проблемы с драйверами БД? Может быть, у вас плохая струк тура БД? Нет ли претензий к промежуточному уровню? Что бы это проверить, через определенное время нужно прово дить мониторинг, устанавливать планку производительно сти для основных транзакций и регулярно сравнивать чтобы знать, что вы на верном пути, Задача тестирования интеграции — убедиться в том, что к завершению первого этапа функциональность продукта удовлетворительна. Если это так, вы готовы приступить к следующему крупному этапу. Если нет, скажем, вы не можете добавить, отредактировать или удалить покупателя, витесь и исправьте все, что мешает двигаться вперед.

Тестирование бета-версий и на выпуск Тестирование и кандидата на выпуск — ключе вой этап проекта. Бета-тест — это возможность дать там проверить и оценить ваше ПО за месяцы выпус ка или применения в реальной рабочей среде. В большин стве проектов во второй половине цикла разработки предусматривается 2-3 бета-периода. Во время каждого такого периода привлекаются десятки или сотни, а иногда тысячи пользователей. Кандидат на выпуск является последней сборкой продукта, и он еще важнее.

Если последний тестирования завершился без серьез ных проблем, то он представляет ПО, которое вы намере I Глава системы контроля качества предоставить потребителям. (Подробно о бета-те стировании см. главу о тестировании кандидатов на пуск — главу 14.) Одна из главных задач при работе с бета-версиями и кандидатами на выпуск — определить, что следует протес тировать в сборке, прежде чем предоставить ее сторонним организациям. Конечно, вы не сможете заново протестиро вать весь продукт. Полное тестирование и доводка продук та займет месяцы, если не годы. Вместо этого вам нужно составить очень конкретный и хорошо продуманный план, который будет выполнен в очень сжатые сроки. (Для боль шинства небольших и средних проектов норма составляет дней.) В планы тестирования бета-версий и кандида тов на выпуск нужно включить:

• выполнение всего набора автоматических тестов;

• выполнение набора ручных тестов, включая:

нормальную установку/проверку лицензии (полно стью вручную);

тестирование базовых функций продукта (полнос тью вручную);

тестирование производительности и нагрузки (пол ностью вручную);

* проверку на всех поддерживаемых платформах;

другие специфические разделы проекта, Этот список послужит вам отправной точкой, но для каждого пункта вы должны определить конкретный сценарий тестирования. И если все эти тесты будут успеш но пройдены, вы выпустите вашу программу. Если вы не можете успешно выполнить тесты, устраните неполадки и повторите процесс.

Одна из черт грамотного цикла тестирования бета-вер сии или кандидата на выпуск заключается в его Часть 1. Люди, организация и методы Вы должны знать, сколько времени займет выпол нение автоматических и ручных тестов. Имея эту информа цию, вы сможете точно предсказать, сколько времени зай мет тестирование следующей или кандидата на выпуск. Зная, сколько времени нужно для тестирования дру гой сборки, вы сможете оценить риск и стоимость дополнительных изменений.

Кто должен тестировать?

За тестирование должны все участники проекта, не взирая на лица и отведенные им роли. При использова нии продукта с любой целью и в любой форме делать это надо с критической точки зрения. Кем бы вы ни были: ме неджером проекта, радостно рассматривающим новую функцию, автором руководства пользователя, как будет работать пример, или специалистом по устанавливающим продукт для верки пользовательского — вы должны отсле искать и сообщать о проблемах качества.

Имея сжатые сроки и ресурсы, трудно ожидать, что одна группа сможет провести всю работу по тестированию, особенно если учитывать, что в командах дефицит кадров проявляется чаще всего.

Так что убедитесь в что ваши разработчики, кие писатели, инженерные психологи, менеджер менеджер проекта, вице-президент или студенты, проходя щие летнюю практику, будут искать проблемы каждый раз, когда они используют продукт для своих нужд. Любой це ной заставьте их сообщать о найденных проблемах.

В период стабилизации и интеграции к тестированию приступает вся команда разработчиков — это коллективная работа. Появляется шанс где команда находится в данный момент и сколько еще нужно сделать. Обычно ру ководитель группы качества выполняет зада \ Глава 6. Основы системы контроля качества распределяя ответственность за тестирование между всеми членами команды. Большую часть работа проводится в областях, где автоматические тестовые зада ния справляются плохо, Также сотрудников просят «сыграть роль пользователя» для ключевых частей продукта.

команда, работавшая над продуктом в течение всего цикла разработки, просто незаменима. Это то, что должно стать частью культуры и одним из ваших основных техно логических процессов.

Эту идею можно развить еще дальше — самим исполь зовать собственные программы. Такой подход называют своей он хорошо известен в отрасли и может оказаться очень ценным. Для опре деления и разрешения проблем с нужно де лать ничего, кроме как свои программы в реальной работе. Даже если в рамках вашей команды раз работчиков продукт применить попробуйте попро сить нескольких опытных пользователей ровать с программой. То, что они найдут, для вас сюрпризом.

В определенный крайне необходимо четко раз обязанности от обязанностей других членов команды (прежде всего в том, что касается тестирования. Чтобы люди концентриро вались на своих прямых задачах, необходимо разделение труда.

Разработчики влияют на качество продукта больше все го. В конце концов они ближе всего к коду, и риск внесения ошибок исходит прежде всего от них. Чтобы га отлов «жучков» до того, как команда тестиров щиков увидит функциональный должны его тес в процессе написания. Хороший разработчик ускорит работу тестировщиков, предоставляя им надежные функции. И наоборот, плохой разработчик затормозит ра 1 !

Часть 1. Люди, организация и методы боту им компоненты с таким ко личеством ошибок, что о тестировании уже и речи не бу дет. Для нет ничего более неприятного, чем находить массу очевидных проблем, которые разработчик мог найти сам всего за минут работы.

Из опыта В мы готовили вторую бета-версию Bounds Checker 3- Для оценки продвижения проекта мы устраи вали ежедневные Кэрол, наш ведущий специ алист по контролю качества (в то время команда тести ровщиков состояла из нее одной), настойчиво повторяла, что сборка была крайне Она сказала, что боль ше не будет зря тратить время на ее и ос танется дома до тех пор, пока разработчики не приведут все в порядок, и быстро ушла.

Я готов был зааплодировать. Не потому, что нра вилось состояние — Кэрол дала понять раз работчикам, что в их обязанности входит тести рование программ и самостоятельная работа над пробле мами кода. До команды разработчиков это дошло. Мы согласились и занимались тестированием и исправлени ями в программе, пока не почувствовали, что готовы по звать Кэрол. Это заняло около двух дней.

В отношении тестирования разработчики имеют ряд обязанностей:

• анализ плана тестирования;

• тестирование на уровне модулей (работает ли функция в ситуаций);

• предварительное тестирование (работа ет ли функция в связке с другими);

• или устранение всех обна руженных в когда они сами ее использовали.

! < !

Глава 6. Основы системы контроля качества Команда, отвечающая контроль качества, пропуска ет эту простейшую работу. Считается, что на таком уровне полностью проведено разработчиками до передачи функционального блока тестировщикам. Конеч но же, не слепо верят в то, что все абсолют но верно, они просто предполагают, что качество продук та находится на уровне, достаточном для того, чтобы при няться за свою работу.

Далее команда, отвечающая за контроль качества, про водит тестирование продукта на другом уровне. Она сосре доточивается на:

планировании тестов;

• автоматизации создания тестов;

автоматизации тестирования;

• тестировании функций в различных комбинациях;

• тестировании процедуры установки;

• интеграции и связи с системой;

• тестировании производительности и нагрузки;

ручном тестировании (функций, для которых неприме нимо автоматическое тестирование);

• диагностике проблем и их протоколировании;

• проверке исправлений и ошибок.

Хотя все эти обязанности привычны для тестировщи ков, последняя может быть менее знакомой.

ошибки должен проводить только тестировщик — член оперативной команды. Задача разработчика — исправить ошибку в коде, занести исправление в систему управления исходным кодом и обновить статус ошибки на в системе устранения неполадок. Но пересмотр всех исправленных ошибок и проверка того, что они действи тельно исправлены, входит в обязанности I • Часть 1. Люди, организация и методы Только после такой проверки ошибка считается официаль но Другие критичные моменты для контроля качества Почти каждая столкнется с рядом вопросов.

Это проблема па разных платформах, долж роль и использование ручного тестирования, а также инфраструктура, отвечающая потребностям проекта.

Матрица тестирования Одной из функций контроля качества, занимающей массу времени, является тестирование продукта на широком спектре ПО. Сегодня тов поддерживают работу под нескольких ОС в различных конфигурациях. Тестировать продукт на всех (если речь идет о ручном тестировании) — гиблое К счастью, существует способ здорово облегчить эту Если у вас есть надежные автоматические тестовые задания для проверки важнейших функций, можете задей ствовать их все для всех конфигураций, которые решили поддерживать.

Из собственного опыта В мы решили проблему тестирования на несколь ких конфигурациях путем распределения их между раз работчиками и Один получил Microsoft Windows 95, другой — Microsoft Windows 98, третий Microsoft Windows NT и еще один — Microsoft Win dows NT 4.0. От каждого требовалось выполнить тест на своей ОС в надежде как можно раньше — в процессе работки — обнаружить Таким простым способом мы почти сразу находили проблемы на всех платформах.

Глава 6. Основы системы контроля Ручное тестирование Я столько внимания уделил что у некоторых из вас мог возникнуть вопрос: стоит ли вообще использовать ручные тесты? но нужно пони мать, где их применять. Ручные тесты используются в дующих случаях, • ключевых функций в случаях, когда автоматические тесты запаздывают или вовсе не Что, если у вас нет времени или для написания всех тестов, а команда разработчиков уже выдает вам готовую функцию? В та ком случае нужно приступить к ручному тестированию, чтобы оценка функции проходила согласно графику.

Раннее обнаружение ошибок и их устранение остается главной задачей.

• Для редко изменяемых, некритичных функций Иног да значимость автоматического тестирования проиг рывает простоте и быстроте ручных тестов. Если не большую функцию легко протестировать и в ней не предвидится изменений, лучше пропустить ческие тесты и направить свои усилия на серь езные задачи, Когда все трещит по Когда сроки а вам нужно быстро провести массу тестов, многие лю бят приглашать дополнительных испытателей, часто это оказываются люди, у которых опыт работы с про дуктом небольшой или вовсе. Для эффек тивного выполнения такой задачи следует иметь четкий план ручного тестирования. В нем нужно описать важ нейшие части продукта, которые требуется обследовать, и те моменты, которые нужно проверить наиболее тельно. Это просто распределить обязаннос ти по тестированию всего продукта, и вы будете ! I -' Часть организация и методы что самые критичные части продукта вошли в пла ны тестирования.

Но помните: нельзя быть зависимым от ручного тести рования. Его наращивание потребует больших затрат, а те стирование параллельно с разработкой продукта становит ся Оборудование для тестирования В проектах с жесткими рамками нужно быть уверенным, что работа команды не замедляется из-за недо статка элементарного аппаратного или программного обеспечения. В разных командах и проектах требования к оборудованию будут заметно меняться, поэтому пере числены основные требования к оборудованию.

• компьютера каждого Один будет использоваться для производственных нужд: элек тронной почты, отчетов о неполадках, автоматизации разработки и т. д., а остальные для тестирования. Нуж но иметь возможность в любой момент менять конфи гурацию тестовых компьютеров. Хорошо, если один из них представляет машину конечного пользователя, • 2 на разработчика Помните: раз работчики тоже занимаются Один ком пьютер им нужен для разработки, другой — для тести рования, Разработчики могут переконфигурировать его при «охоте на жучков», и это не помешает их основной работе. Повторю: хорошо, если одна машина представ ляет компьютер конечного пользователя.

• Доступная библиотека программ ПО, которое требуется для разработки или тестирования, должно быть постоянно Для быстрого и простого до ступа сотрудников к инструментам, продуктам и ОС, необходимым для работы, удобен дисковод с автомати I Глава 6. Основы системы контроля ческой сменой компакт-дисков. Конечно, придется по заботиться о наличии лицензий, но избавление сотруд ников от хождения по коридорам в поисках нужного диска того стоит.

Тестовая Великая Стойка с тесто выми компьютерами, которых установлены различ ные ОС, с различными языками и сервисными пакета ми здорово упростит работу по контролю качества для всей команды. Тестовая лаборатория хороша и для ус тановки сложной среды тестирования, сборка и на стройка которой отнимает массу времени.

Конечно, следование этим рекомендациям увеличит расходы на аппаратное и программное обеспечение, но дополнительные расходы обернутся приростом произво дительности и качества.

Из собственного опыта На заре у пас не было постоянно доступной биб лиотеки программ, а охота за компакт-дисками здорово раздражала и отнимала драгоценное время. Часто наши планы требовали поддержки самой последней ОС или компилятора Microsoft. К мы участвовали в тес их и регулярно получали обнов ления. Жаль, что только на одном компакт-диске. Когда требовалась последняя Windows или Visual Studio, начиналась охота за диском.

Если везло, мы находили человека с диском, который нам но чаще всего мы слышали: «Я отдал его тому — и идти по следу. я ходил так от одного к другому и только пятый человек в цепочке что этого диска в глаза не видел!) Если такой не работал, мы писали сообщение по электронной почте и с надеждой ответа, а это время занимались чем-то другим.

Часть 1. Люди, организация и методы После того, как нескольких месяцев мы столкнулись с десятками таких мы оконча тельно поняли, что нужно решать, тем более что наша компания росла. Решением стала ком пакт-дисков. Это сработало, но только после того, как мы перепели все в режим онлайнового доступа. Наши попыт ки создать традиционную не увенчались ус пехом, как люди, бравшие компакт-диски, никогда не их на место, и мы задавались вопросом:

«У кого диск?» Типичные проблемы и их решение Далее обсуждается ряд типичных и вопросов, воз никающих при использовании описываемых здесь методик, а также их решения.

Нехватка ресурсов Нехватка ресурсов (здесь я имею в ресурсы человечес кие), вероятно, является наиболее частой проблемой сис темы качества, и, честно говоря, она гораздо сложнее, чем может казаться. Если для качества у вас нет необходимых ресурсов, прежде всего определите, в чем проблема. Если вам не хватает ресурсов для осуществления контроля качества, а рабочие места ос таются вакантными, значит, вы проблемы с набором персонала, обратитесь к главе 1 за дополнитель ными разъяснениями. Если сотрудники, отвечающие за кон троль качества, из-за работы или сокраще ния графиков уже работают на стоит рассмотреть возможность привлечения прежде чем пойти на этот шаг, у вас должны быть полностью гото вы планы тестирования. Важно, чтобы временные сотруд ники выполняли план, а его.

Глава 6. Основы контроля качества Если работы просто больше, чем ваши мо гут выполнить, а вы хотите поставить качественный про дукт, существует только два выхода;

• пересмотреть графики, чтобы отвечали ограниче ниям, накладываемым разрабатываемыми функциями и возможностями персонала;

* пересмотреть функциональность программы, чтобы она отвечала ограничениям графика и возможностям персонала.

В первом случае вы распределяете работу по качества между членами команды. Это обычно отодвигает сроки, так как каждому приходится выполнять дополни тельную Однако вы знаете, что держите планку ка чества и в то же время обеспечиваете работу следуете графику и реализуете нужную функциональность, чем такой обратите внимание на дух, сроки и текущее дел, а также последствия задержки выпуска.

Во втором случае вы сохраняете график (что часто очень критично) и продукта (что менее важно), Причина, по которой этот путь является успешным, заклю чается в том, что общая нагрузка на всю команду и общий риск проекта снижаются. Поскольку исключенные функции нужно разрабатывать, тестировать и описывать, произ водство продукта идет быстрее. Прежде чем пойти на такой шаг, внимательно изучите функции и их важность для ус пеха продукта. Я пришел к что раньше выпу стить продукт с несколькими хорошими функциями, чем поздно поставить то же самое, но с дополнительными можностями. (В главе я расскажу о приоритетах в выбо ре функций в подобных ситуациях.) ! :

Часть Люди, организация и методы Недостаточная подготовка Многие проекты не с той ноги» и, честно говоря, обречены с самого начала, так как члены команды просто к ним не готовы. У вас должны быть основные сред ства автоматизации и оборудование, о которых говорилось выше. Все это потребуется почти с самого начала разработ ки. Если вы будете писать планы или ждать поставки нуж ного оборудования в процессе разработки, вы уже опозда ете и не сможете делать то, что от вас требуется — тести После того как масштаб необходимых ресурсов для осу ществления контроля качества становится понятен, ды часто начинают рассматривать возможность добавления ресурсов в проект. Если это сотрудники, работающие по или перешедшие из других отделов, то скорее всего у них не будет специальных знаний о продук те. Они не смогут применять автоматические тесты можно, потому что ни одного не будет написано) или вы полнять ручные, как у них не будет контрольного списка или материалов, описывающих, что следует проделать.

В этом случае лучший способ продвижения — зас их «играть пользователей». Хотя такой подход час то дает неплохие результаты, не злоупотребляйте им или используйте его как способов описан ных в этой главе.

Отсутствие автоматизации Надеюсь, к данному стало абсолютно понятно, как важны тесты в работе по контролю ства. Без автоматизации объем ручной работы и персонала взлетят до небес, что заметно сдвинет ваши гра фики. Очень важно, чтобы команды, отвечающие за конт роль качества, и разработчики писали так много I Глава 6. Основы системы тестов, как это и. конечно, меньше, чем в рекомендациях, приведенных мной.

Ненадлежащее исполнение обязанностей Проблемы с качеством не всегда являются результатом иг норирования приемов и концепции контроля качества. Это может быть следствием ненадлежащего исполнения обя занностей. Если вам беседовать с менеджера ми или ведущими специалистами о качества в та ком проекте, они, вероятно, постарались наговорить мно го всего о том, что нужно сделать. Но когда вы видите их проекты, то что ничего не делается. Создание качественного продукта требует усилий: сосредоточенно сти, активного участия, исполнительности. Это теорети выкладки — все члены команды должны действовать активно и увлеченно, Неправильная расстановка акцентов Я настоятельно рекомендую тестировать продукты снача ла вширь, а затем вглубь. Убедитесь, что все основные функции реализованы и нормально работают, прежде чем тратить время на второстепенные функции. Конечно, как я говорил ранее, расставить приоритеты в тестиро вании функций. Однако очень часто команды тратят слиш ком времени на мелкие детали какой-то в то как оставшаяся часть продукта разваливается, Возьмите в качестве примера постройку здания. Какой смысл полировать все до блеска в вестибюле, когда лифты не работают!

V, Основы технологии разработки программ Часть Люди, организация и методы борка и установка ПО — постоянно задача. По сути она стала настолько трудоемкой, что для ее решения особая дисциплина — технология разработки законченного программного продукта. Эта тех нология является для своевременного выпуска продукта. В этой главе я расскажу об основах технологии разработки ПО и ее применении в повседневной работе.

Какой бы ни была ваша организация, большой или ленькой, вы должны возможность на регулярной ос нове собирать и устанавливать ваше ПО. Однако слишком часто команды разработчиков неделями и даже месяцами не могут собрать или свою собственную про грамму. того, никто из них не отвечает за проблемы со сборкой и процедурой установки, так что эта проблема тормозит процесс разработки. Из-за того, что проект невоз можно собрать или установить, могут появиться проблемы любого рода, что вызовет задержки. Если вы не знаете точ но реальное состояние вашей программы, потому что не можете увидеть или использовать ее, значит, вы действуете вслепую. Чтобы советами, данными в кни ге, вы должны в обязательном порядке иметь возможность собирать и устанавливать ПО.

Технологи по разработке ПО Это члены команды, работающей над проектом, которые имеют необходимые работы с процессами и техно логиями сборки и установки ПО. Хотя технологи могут вы полнять множество обязанностей, в контексте нашего об суждения выделим наиболее важные:

• определение, создание и сопровождение сборочной среды продукта;

определение, создание и процедуры установки продукта;

Глава Основы технологии разработки программ • создание и пакетов лений или сервисных пакетов;

• проведение модульного и ме роприятий по качества процедуры разработка инструментов, сценариев и разработки ПО;

• сборочной среды (сборочной тории).

Для выполнения этих задач технологи должны быть включены в работающую над проектом, с самого начала до конца. Они должны создать план сборки и про цедуры установки в соответствии с требованиями проекта, как они понимаются в настоящий момент. Им следует уча ствовать в совещаниях по проекту точно так же, как и ос тальным членам команды.

Из опыта В не было технологов, функции ре ализации готового продукта выполняла команда. Снача ла она состояла из инженера по поддержке и специалис та по инженерной психологии. Что бы вы ни думали, они по совместительству составляли великолепную команду и больше года отлично решали технологические проблемы.

Талантливые люди могут брать на себя много задач! Но однажды они позвонили мне из лаборатории (на самом деле это небольшая где боролись со сложной сборкой и сценарием установки. Сообщение было недвусмысленным: С нас хватит! Найми технолога!» В небольших группах отдельный постоянный технолог не нужен. Вместо него эти обязанности могут выполнять члены команды по совместительству. Но со време нем сложность ПО и размер команды разработчиков воз Часть 1. организация и методы растают, и отдельные технологи. еще позже — централизованная структура, занимающаяся технологией создания готового продукта. Не надо предполагать, что эта функция не или ее качество не имеет значения толь ко потому, что в начале ее не потребует рабо ты с постоянной занятостью.

Сборки Сборка является результатом компиляции всего исходного кода продукта. Для корректного построения вашего ПО, интеграция должна быть обеспечена на самом элементар ном уровне — на исходного кода. Целостность ис ходного кода должна быть совершенной: ошибки компиля ции и компоновки недопустимы, В сложных проектах со вершенства добиться тяжело из-за массы связей между модулями исходного кода. регулярно собирать свою программу и нужно.

Почему они важны Способность собирать ПО является определяющей для по ставки программ в срок. Одна из наиболее часто возника ющих проблем при ПО — заставить все части ра ботать вместе. Если о ней забыть до окончания проекта, то потом решение проблемы займет недели или месяцы рабо ты. В худшем случае потребуется переопределение каких то API и функций. А это, естественно, означает появление никем не задержек.

Из собственного опыта Когда я пришел в единственным человеком, спо собным собрать продукт целиком, был один из талантли вейших инженеров — Питрек. Даже когда команда и продукты еще были небольшими, среда разработки была чрезвычайно сложной. Только Мэт знал, что делать. Что бы собрать программу он свой кабинет и [ Глава 7. Основы технологии программ вал дверь. Он как помешанный колдовал над тремя разны ми компиляторами и дюжиной сценариев, ре дактировал конфигурационные и другие файлы. Затем, после 3-4 часов интенсивной работы, он взмахивал волшебной палочкой, и обычно у нас появлялась гото вая сборка. Мы предполагали, что он не нашел никаких проблем.

об успехе всегда ведь по теря нашего ведущего на полдня всего лишь для сборки лишала нас возможности использо вать модель параллельной разработки. Так что нужно было как можно скорее такой порядок вещей.

При регулярном создании сборок разработчики могут проверять интеграцию кода. Интерфейсы API, файлы заго ловков, параметры, типы данных и макросы — все должны быть в полностью рабочем состоянии, иначе сборка прой дет некорректно. Сбой при сборке заставит разработчиков общаться друг с другом и при необходимости изменять Но ведь это именно то, что вам нужно: искать и устранять проблемы на раннем а не в самом конце, скажем, за день до того, когда от вас требуется бета-версия.

Как их создавать Далее ряд рекомендаций о том, как сделать зада чу создания сборки более простой и эффективной.

Утилита Поддерживает набор сборки и отношений в грамме для всего приложения или Описав эти правила, Make может какие образы необходимо собрать и какие исходные файлы должны быть откомпили рованы или скомпонованы.

Make существует уже десятилетий, все нача лось в UNIX, а затем она появилась практически на всех ос Часть 1. организация и методы тальных платформах. В многих лет ее улучшали, и последняя версия — — входит в состав Visual Studio. Обязательно изучите Make в вашей разработки и используйте ее для автоматизации за дач сборки ПО.

Номера сборок Разработчики используют номера для иденти фикации сборок. Номер сборки — это монотонно возрас тающая целая величина, ни разу не повторяющаяся в исто рии создания приложения. Номер увеличивается на базо вых уровнях, этапах и в каждом последующем выпуске ПО.

Когда сборка происходит просто, в вашей среде разработки и тестирования, вероятно, будет большое число разных Со временем возможность идентифи кации определенной сборки, установленной на машине, а также программных компонентов, сопровождающих ее, становится очень значимой. Также это относится к иденти фикации сборок, в которых появились или были устране крупные неисправности. После того, как программа вы пущена для потребителей, возможность идентифицировать определенную сборку станет еще критичнее.

Номер увеличивается па единицу каждый раз при созда нии очередной сборки. Обычно увеличение номера проис ходит в самом начале процедуры сборки, затем он помеща ется в рабочие файлы, и все компоненты могут включать его в свой состав или ссылаться на него. Обычно номер сборки указывается в окне, вызываемом командой About меню Help, так что все пользователи могут видеть, с какой сборкой работают.

Сборочные машины и лаборатории Сборочная среда — это набор приложений, инструментов, библиотек и компиляторов, нужных для компиляции и ком поновки ПО. Часто лучше всего установить эту среду на не Глава 7. Основы разработки программ скольких сборочных машинах, которыми и управляют исключительно по раз ПО, изменения на этих машинах недопустимы.

обеспечить и регулярное копирование дисков этих чтобы восстановление было простым и быстрым. А чтобы избавиться от неожиданных трудно стей, не забудьте установить антивирусное ПО.

С ростом числа ваших сборочных машин потребуется целая лаборатория. Лаборатория полезна, когда собирать действительно большие про или большое количество программ (возможно, по ночам). Сборочная лаборатория поможет наши машины и предотвратить посторонние вмешатель ства, способные привести к сбою.

и сбои О завершении сборки команду надо оповестить.

может быть послано в список рассылки всей команды про екта или для этих целей может быть создан свой список рассылки.

Оповещение всех участников команды особенно цен но, если появляется сбой. Когда такое происходит, очень важно, чтобы ведущий разработчик или сотрудник такого же уровня ошибок и определил приро ду проблемы. Он отвечать за решение проблемы до тех пор, пока для ее решения не будет назначен конкретный специалист.

Созданная сборка должна быть помещена на сетевой диск с совместным доступом, где она будет проверена при помо щи автоматических тестов, созданных командой тестиро вания. Проверка — очень этап, так как наличие го товой сборки еще означает, что продукт в рабочем со Часть Люди, организация и методы стоянии. Вы только то, что можете компилировать и компоновать все нужные файлы.

Один из лучших способов проверить сборку — устано вить и запустить базисные тесты (см. о них главу 6).

Для эффективного управления этим процессом для сборок следует завести два каталога.

Самая последняя сборка В этом каталоге хра нится самая последняя сборка программы. Однако она может и не устанавливаться или не работать • Последняя сборка (LKGB) Здесь хранится ледняя хорошая сборка. в том, что текущая сборка находится в хорошем состоянии (она установи лась и прошла тесты), скопируйте содержи мое каталога в каталог Для своей работы должна про изводить установку из каталога I.KGB. Обычно команда, от вечающая за контроль качества, перемещает последнюю в сразу после ее проверки. Если в последней сборке обнаружены проблемы, команда все равно может работать, так как сборка в каталоге LKGB является рабочей.

Штрафы и Как я говорил в главе Л, в решили обойтись без большого числа технологических приемов (процессов). Но к процессам, которые у нас имелись, мы относились очень серьезно и следовали им. Сборка являлась одним из них. Мы решили, что если кто-то ломает сборку, то на следующее утро он покупает пончики на всю команду. Такая простая, но эффективная стратегия подчеркнула необходимость работы над сборкой должным образом и установила нака зание за ее порчу. В тех командах, где не было технологов, сборку брал на себя обязанности по техноло гической поддержке до следующего сбоя.

L Глава 7. Основы технологии разработки программ Другим способом важность процесса сбор ки является его измерение. Следите за тем, сколько раз за период времени в сборке происходит сбой, возможно, за тем, из-за сбои происходят чаще всего. Знание того, что за процессом сборки наблюдают, подстегивает людей к самодисциплине при сдаче исходных файлов. Также вы можете наблюдать за тем, сколько команда рабо тает, не ломая сборку, и предложить стимулы для достиже ний в этой области. В больших организациях поду мать об организации соревнования с другими командами.

сдачи и сборки Чтобы не сломать сборку, ответьте на следующие вопросы.

Когда я должен мой код? Сдавайте свою часть кода, когда у нас есть что добавить к проекту. Это может быть сосем простое скажем, набор заглу шек или очень сложное, например, крупный компо нент. Но вы должны сдавать свой код часто. Смысл в том, чтобы как можно раньше заставить работать код, со зданный разными людьми.

• могу быть в том, что не испорчу сборку?

Если возможно, для проверки кода осуществите локаль ную сборку программы. Вы как обычно берете код из системы исходным кодом, интегрируете ваш код и возвращаете его в систему. В проектов эта процедура выполняется и это от личный способ гарантировать что вы не испортите сборку. Дополнительно, чтобы убедиться в отсутствии новых ошибок, можно запустить входные тесты (см, главу 6).

Процедура установки Процедура установки важна не только для потребителя про ектах в последнюю очередь, от чего может пострадать весь Часть 1. организация и методы проект. Здесь я расскажу, почему процедура установки так важна и как строить процедуру установки параллельно раз работке ПО.

Почему это важно Процедура установки служит для выполнения двух важных функций. Во-первых, она заставляет команду думать об ус тановочной среде, которая требуется для продукта. Проце дура установки требует от вас знания состава приложения:

образов, библиотек, компонентов, файлов справки, библио тек типов и т. д.. Также она заставляет вас определить няющую среду, в том числе поддержку драйверов баз дан ных, стандартных компонентов и операционных систем.

Если вы сохраните компоненты продукта целыми и акту альными, вы сможете избежать проблем в дальнейшем.

Во-вторых, при наличии у членов команды имеется простой доступ к самым последним сбор кам Им не нужно запоминать все ненужные подробности по поводу установки программы, такие как местоположение файлов, процедур компонен тов, команд запуска, параметров реестра и т. д. Они могут просто установить продукт и его для своих целей. Примеры использования перечислены далее.

• Разработчики смогут увидеть свои со сто роны официальной сборки и оценить проблемы, ис пользуя ту же процедуру установки, что и вся команда.

• будут устанавливать программу обыч ным образом и тестировать ее на наличие проблем. Ра ботать с последней сборкой будут как автоматические регрессивные тесты, так и вся команда, которая будет тестировать последнюю сборку. Это обеспе чивает тестирование самой последней и наиболее ста бильной версии программы. Единая официальная Глава 7. Основы технологии разработки программ упрощает и работоспособности компо То, что удается компо нент работать на своей машине, не имеет значения, если компонент работает в официальной сборке.

Если в официальной сборке компонент, установленный при помощи текущей процедуры установки, не зарабо тал, значит, он не работает вообще, Для составления документации техничес ким писателям нужно видеть, использовать и программу. Доступ к сборке, которую можно устано вить, заметно ускоряет их работу, так как новые возмож ности, добавленные разработчиками в сборку, видны и могут быть документированы на следующий день.

По мере развития сборки специалисты по инженерной психологии смотрят за тем, как ин терфейс продукта претворяется в оценивают его и дают рекомендации. Без сборки у пси хологов нет простого доступа к компонентам, с которы ми они должны работать. В итоге проколы и несогла проекта обнаруживаются в процессе разра ботки слишком поздно.

расширяются возможности менеджера проекта. Наличие официальной сборки обеспечивает отличное видение текущего состояния проекта. Состо яние компонентов, параметров производительности, справочной системы и т. д. пере стает быть секретом.

И, имея процедуру установки на раннем эта пе, расширяется обратная связь с другими группами, такими как менеджеры продукта, специалисты по тех поддержке и отдел продаж. Каждая из этих групп даст отзывы о продвижении продукта, а также сможет отловить несколько ошибок.

Часть Люди, организация и методы Как ее создавать Хотя конкретные детали по применению от личаются для разных продуктов и подход к процедуре установки всегда одинаков. Вы начинаете ние процедуры установки в самом начале проекта и со вре менем ее.

в создании процедуры установки — конструи рование скелета. Задача проста: сделать так, чтобы первый набор файлов в каталог установки, Если даже программа может сделать как выве сти на экран надпись «Hello World», для нее нужно создать процедуру установки. не должна сложной, но вам по крайней мере на которой начнется строительство.

Мышцы С продвижением проекта строительство продолжится на основе простой структуры, созданной вами, путем ния сложных и утонченных элементов. Смысл в том.

бы процедуру параллельно разработке проекта, т. е. сначала вы строите скелет, а со временем наращиваете его. Скажем, завершены новые компоненты, включена под держка новых ОС или баз данных, упрощен текст — вам нужно добавить новые файлы и изменить процедуру согласно новым требованиям.

Я не предлагаю проводить эту работу на сиюминутной — это вызовет только беспорядок. Следует добавлять компоненты в процедуру установки лишь по необходимо сти. Ваша задача — написать план разработки процедуры обеспечивающий включение компонентов и поддержки, необходимой для разработки и тестирования. план должен помочь вам найти равно между двумя ежедневного внесения Глава 7. Основы разработки программ и продукта в соот ветствие с Это файлов, поставляемый В процес се создания комплекта процедура установки с файлами. Результатом часто является набор файлов, не представляющих того, что реаль но будет помещено на систему пользователя. Хорошо бы что применяется в процессе создания комплекта и что на выходе. Неплохо разработать и тест, про наличие нужного файлов с приблизитель но правильной датой и размером. Для этого могут быть полезны автоматически проверяющие содержимое комплекта.

Сбор всего вместе Когда у вас есть сборки и процедура установки, следует со брать все вместе в автоматизированный конвейерный про Процесс быть создан в самом начале проек та, возможно, это должно быть первой задачей.

Главные шаги цикла сборки таковы:

• сборка образов;

создание комплекта:

тестирование комплекта;

• отправка сообщения о теста или сбое:

• запуск базисных тестов для сборки:

тест пройден удачно, копирование в каталог LKGB;

• о прохождении базисного теста или о сбое.

Ежедневные комплекты и тесты процесс сборки, создания комплектов и тести рования задает темп реализации проекта. Эти — [ Часть 1. Люди, и методы надо еженощно, а чтобы точно понять состояние проекта, — результаты просматривать каждое утро. Только тогда вы сможете грамотные решения о ходимых изменениях. Без этих процессов вы будете дей ствовать вслепую и никогда не узнаете, собирается ли про ект воедино (и вообще сможет ли он заработать), пока не будет слишком поздно, и вы ничего не сможете поделать.

Все, что вам останется, — сдвинуть график.

Убеждение В организациях, где уже приняли эти правила, люди что сборки, установки и базисные тесты могут выполнять ся ежедневно. Но в других организациях сотрудники могут отнестись к этому скептично. Обычно они слишком заня ты, у них нет ресурсов, и они противятся выполнению лиш ней работы. У кого есть время на эту ерунду? Я бывал в та ких фирмах и знаю, что это сложно. Но выгода огромна, и вы можете внедрить эти принципы. Я рекомендую сначала убедить команду в этих идеях, а затем реализовывать их за шагом: сначала создавать рабочие сборки, затем дуры установки и, наконец, базисные тесты.

Из собственного опыта Вначале принцип ежедневной сборки был новым для на шей компании. Мы были небольшой командой, и запус кать процесс сборки было сложно. Не хвата ло поддержки, достать сборочную среду, машины и нала дить процессы было тяжело.

Однажды я спросил, была ли сегодняшняя сборка пешной. Коллега ответил: «Ты что, что мы дол жны создавать эту сборку КАЖДЫЙ день?» Да, каждый день. Это часть нашей модели разработки, и это критич но для способа, которым мы работаем.

Спустя годы смешно оглядываться на те Сейчас ежедневные сборки — часть культуры, чему никто Глава 7. Основы технологии программ не сопротивляется. Это само и когда в сборке происходит сбой, мы видим справедливый гнев всей команды.

Типичные проблемы и их решение Далее обсуждается ряд типичных проблем и вопросов, никающих при использовании описываемых здесь а также их решения.

Отсутствие по разработке ПО Не забудьте учесть в планах и графике вашего проекта ме роприятия по технологическому обеспечению. Некоторые команды не учитывают значительный объем работ в этом направлении. В результате их часто ожидают сюрпризы и необходимость корректировки графиков.

Недостаточная Автоматизация сборки, создания комплектов и тестирова ния очень важна. Выполнение этих задач вручную потребу ет много и которые могут быть на что-то другое.

Запоздалая процедура установки Некоторые команды часто строят исполняемые файлы, но не создают программу установки до самого конца проекта, Такой подход ухудшит видение проекта, а преимущество простого вытекающее из ранней процедуры уста новки, теряется всеми членами команды. Столь же часто члены команды обнаруживают, что создание процедуры ус тановки гораздо больше времени и она более слож ная, чем думали а ее отладка еще вре мени. К сожалению, поздняя разработка чего-либо, в том числе процедуры установки, добавляет риск и способна на рушить график.

Часть 1. Люди, организация и методы Дисциплина создание комплектов и тестирование требует много сил. Если дисциплина в команде недостаточ но высока или проблемы остаются неразрешенными, вы не сможете воспользоваться преимуществами, о которых мы говорили ранее. У команды должна быть культура решения проблем. Каждый член команды должен быть дисциплини рован и бороться с проблемами с момента их появления.

УЛИРОВАНИЕ И s Требования Часть 2. Формулирование и планирование проекте этой главе процесс формулирования требований к программному продукту. Каждый член команды разработчиков должен четко представлять, какую программу нужно создать, для чего она предназначена и ка ее возможности — иначе у вашего проекта не будет ни единого шанса на успех. Проще всего добиться этого пони мания с помощью четко и строго лируемого набора требований. Но не менее важна ность улучшения программного продукта и переработки некоторых его Проект должен допускать по степенное улучшение программы вплоть до добавления одних функций и удаления других. Эти две потребности — строгий контроль и свобода развития — часто выглядят вза имоисключающими, поэтому рассмотрим каждую из них.

Для первой требуется четко сформулированный, под робный и строгий список требований, оговаривающий практически все особенности продукта. Его дополняет жестко заданный набор процессов, управляющих внесе нием изменений, Проблема этого метода заключается в трудности создания такого списка требований, особенно при работе в новых, неразработанных областях. Кроме того, он с трудом обеспечивает постепенное улучшение продукта и организацию обратной связи. Даже создать подробный список требований было бы возможно, то в письменной форме он часто терял бы свою однозначность, а поддерживать его в актуальном виде было бы довольно трудно, Второй подход утверждает, что достаточно лишь со здать простой список требований в общей формулировке.

Идея в том, чтобы дать разработчикам принимать решения о основных функций продукта во вре мя его разработки. Более динамичная среда позволит раз работчикам оперативно воплощать новые идеи и адекват но на потребности рынка. Однако этот подход ;

Глава 8. Требования полон неопределенности и риска: трудно ра бочий процесс, а управлять еще труднее. Это также не гативно сказывается на тестировании и создании докумен тации, так как до самого выпуска, т. е. до выяснения истин ной картины функциональности продукта, сведений о продукте для начала работы будет недостаточно, У каждого подхода свои преимущества, но какой же из них выбрать? Нужно еще до начала написания кода, устано вить требования, но при этом иметь воз можность вносить контролируемые изменения во время цикла разработки. Давайте обсудим процесс управления требованиями, который позволит их сбалансировать, Центральная идея проекта В начале работы над каждым выпуском нужно добиться простого и ясного видения проблемы, при котором задачи и приоритеты проекта стали бы очевидными для всех его участников;

критически важно объединить их усилия и га рантировать, что группа будет работать сообща.

Атрибутом хорошего видения проблемы является цен тральная идея (лейтмотив проекта), которая сплотит груп пу и даже всю компанию воедино. Она должна не только направлять усилия при разработке, но и способствовать позиционированию, сбыту и продвижению продукта на Вокруг нее должны объединиться все группы, обес печивающие коммерческий успех продукта.

Хотя у крупных проектов может быть несколько таких идей, распыляться все же не стоит. Основная идея проекта должна быть сформулирована кратко и ясно, в ней должен быть призыв к превосходству в одной-двух областях. Вы брать ее нелегко, обычно такая идея является результатом тщательного анализа рынка и состояния бизнеса в данной области. что достижение поставленной основной идеей, принесет значительную прибыль.

I Часть 2. и планирование проекта Мы в NuMega всегда пытались сделать выпуск каждого продукта волнующим претендуя на самый корот кий его создания, либо на первенство в использовании новых технологий, вплоть до того, что целью ряда наших проектов было получение премий в нашей отрасли. Вот ряд идей, которые в прошлом позволили эффективно объеди нить наши усилия по разработке:

закрыть на рынок новым конкурентам, предоста вив программистам на языке C/C++ продукт с самым полным набором функций по обнаружению ошибок;

• создать продукт для анализа производительности, са мый простой в эксплуатации во всей отрасли, и добить ся признания этого факта;

создать самый мощный и функционально насыщенный отладчик ядра Windows NT.

Мы руководствовались этими идеями при выборе функ ций продукта и в процессе их реализации. Они также иг рали главную роль, когда приходилось идти на компромисс.

Например, если приходилось выбирать одну из двух взаи моисключающих возможностей, достаточно было одного взгляда на центральную идею проекта, чтобы стало ясно, какую из них выбрать.

Поиск и решение пользовательских проблем Сформулировав центральную идею проекта, надо точиться на потребностях пользователя. На этом этапе про цесса формулирования требований следует рассматривать те проблемы, что необходимо решить пользователю, а не конкретные действия, которые он хотел бы выполнять.

Возьмем в качестве примера одну из формулировок идеи проекта из предыдущего раздела. Если нужно предоставить программистам на C/C++ наиболее полный продукт для обнаружения ошибок, то надо выяснить, какие ошибки яв ляются наиболее распространенными и труднее всего !

Глава 8.

даются обнаружению. Вот еще один пример: если нужен самый простой в использовании продукт для анализа про изводительности, нужно понять, какие о произво дительности критичны для пользователей и в каком виде они хотели бы их получить.

Чтобы понимать пользовательские проблемы, важно поддерживать обратную связь с клиентами для проверки сделанных предположений, Лучший способ убедиться в разумности своих планов и преодолеть внутренние разно гласия — иметь обратную связь, заслуживающую доверия.

Из собственного опыта При работе над 3.0 было много прений вокруг набора функций продукта. Несколько недель об суждения этого предмета, порой доходившего до жарких споров, прошли без видимого прогресса. Было принято совместное соглашение оставить этот чтобы из бежать возобновления споров. Чтобы выйти из тупика и поднять боевой дух группы, мы решили пригласить груп пу заказчиков и потенциальных пользователей на вече ринку с угощением и раздачей призов. Там мы продемон стрировали разные идеи о возможных функциях про граммы и попросили приглашенных высказать свое мнение. На основе информации извне стало намного лег че прийти к компромиссу и выработать у кото рого были неплохие шансы на успех.

Формулирование требований Когда установлено общее видение проекта и достигнуто понимание пользовательских проблем, пора переходить к определению требований. Как сформулировать насколько подробными должны быть формулировки и как ничего не Часть 2. Формулирование и планирование проекта Общие и частные требования Один из лучших способов дать четкое описание набора требований к проекту — представить его в виде схемы. Са мый высокий уровень схемы занимают общие требования.

Они объединяют совокупности частных требований, рые, таким образом, можно обсуждать, оценивать, сравни вать и утверждать как единое целое. Нужно иметь возмож ность анализа общих требований и обладать совершенным пониманием их основных целей. Общих требований не должно быть много, так как каждое в свою очередь генерирует ряд второстепенных требований. Например, в случае компании, которой надо адаптировать имеющееся приложение обработки заказов для работы в Интернете, пяти общих требований:

• разработать интерфейс на базе браузера;

• повысить производительность до уровня, приемлемого для • организовать рассылку уведомлений о выполнении за казов по электронной почте;

добавить к программе новые возможности, которые по высят производительность пользователей;

• предусмотреть применение в будущем в качестве кли ентской платформы карманных компьютеров.

Каждое общее требование должно подразделяться на несколько частных, С последними могут быть связаны и другие требования, конкретизирующие или поясняющие функциональность требований более высокого уровня. В результате может принять такой вид:

Общее требование Частное требование Частное требование нижнего уровня Частное требование нижнего уровня 1 Глава 8.

Частное требование Частное требование нижнего уровня Частное требование нижнего уровня 2. Ниже приводится пример некоторых общих и частных тре бований, организованных в соответствии с вышеописан ной структурой.

Разработать интерфейс на базе браузера для приложения по обработке заказов.

Функциональные требования.

При размещении заказа:

Ввести для каждого заказа следующую информацию (по пунктам).

Проверить идентификатор покупателя.

заказ.

Проверить статус заказа.

Сгенерировать подтверждение заказа.

Обеспечить поддержку следующих браузеров:

Microsoft Internet Explorer версии X.

Netscape версии Y.

Производительность должна быть приемлема для Web пользователя.

Требования ко времени реакции системы:

Размещение заказа должно занимать менее Удаление заказа должно занимать менее 6 секунд.

Проверка статуса заказа должна занимать менее 4 секунд, Подтверждение заказа должно занимать менее получаса, Облегчить использование приложения с помощью новых возможностей:

Часть 2. и планирование проекта заказ нескольких товаров в одном заказе.

Разрешить пользователю просмотр его идентификатора покупателя.

Как из этого каждое общее требование включает набор поддерживающих его которые конкретизируют или разъясняют содержание Каждое поддерживающее требование сформулирова но просто и ясно, что позволяет легко проследить его реа лизацию в данном выпуске ПО. Следует расширять степень детализации спецификации пока не будут опи саны все ключевые элементы функциональности и вы не останетесь довольны созданным описанием.

Полнота требований Определение требований должно быть полным. Рассмотри те все аспекты нового выпуска, даже те, что нельзя свести к набору частных требований. Далее приводится список об щих категорий требований, применимый практически ко всем проектам по созданию программ. Я не предлагаю ис пользовать этот список в том виде, в каком он представлен хотя возможно и такое;

однако при составлении соб ственного списка требований рассмотрите каждую из сле дующих категорий.

• и проекта Каждый участник должен понять ключевые задачи и функции проекта, прежде чем приступать к работе. Эти задачи и функции ляют сущность программного продукта и будут направ лять его разработку, а также по тестированию к обучению пользователей.

• Хотя при работе над пользовательским интерфейсом придется дать ответ на два важных вопроса: «Как пользователю выполнить дей ствие и «Как должна выглядеть функция лучше не пытаться формализовать их, так как это слишком Глава 8.

описание, тестирование и реализацию после довательных Вместо этого надо разработать визуальную модель приложения с помощью различных методик конструирования прототипов пользовательс кого интерфейса. Эта модель и будет спецификацией требований к пользовательскому интерфейсу. (Подроб об этот см. главу 9. Там же я об эффектив ных способах формулирования и анализа требований к пользовательскому интерфейсу программного про дукта.) При наличии конкретной платформы, техно логий или связанных с бизнесом ограничений, влия ющих на структуру интерфейса, важно оговорить их заранее.

Среда Необходимо описание программной и аппарат ной среды, в которой будет работать продукт. В описа нии должны быть четко указаны конкретные версии существующего ПО с учетом новых выпусков, которые могут стать доступными к окончанию работы над про ектом. Не забывайте о проблемах, связанных с глобали зацией;

поддержке ОС, местных языков, валют и разли чий в часовых поясах.

Определите потребности, связанные с интеграцией и возможностью взаимодействия с суще ствующими программами и оборудованием. При ходимости интеграции новой с существую щими решениями, следует указать способ ее осуществ ления и поддерживаемые версии программного и аппаратного обеспечения.

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

Следует подумать и о времени реакции системы в зависи мости от типов нагрузки и потребностей пользователей.

Часть 2. Формулирование и планирование проекта Установка ПО. В опреде лении требований должны по действия, которые должен выполнить пользова чтобы установить ПО, а также действия самой про граммы установки, необходимые для завершения про цесса Кроме того, платформы, кото рые должна поддерживать программа установки.

* к тестированию продукта не только способствовать существенному повы работы, но и принести допол нительные выгоды. Так, если в программе установки режим, не требующий ручного ввода ин формации, можно будет автоматически устанавли вать и тестировать все ежедневные сборки программы.

Не исключено, что программный продукт поддерживать набор API, позволяющих группе, испытания, читать любые двоичные файлы, ис пользуемые или генерируемые Это по зволит сравнивать файлы, полученные в результате скольких испытаний программы с последовательно измененными Также можно заставить программу вести протокол внутренних который будет полезен при но воспроизводимых сбоев в работе программы.

Детализация требований одна которую придется решить, — ко подробно нужно формулировать требования. Разумеет ся, в данном случае задача в том, чтобы было как можно требование, тем легче следить за ходом его реализации. Чем больше тов определено больше параллелизма в те разработчиков и групп, за обучение пользователей и выпуск программного продукта, Глава 8. Требования так как тогда им проще понять, какой продукт создастся, Однако часто подробно документировать очень трудно и даже невозможно, так как приходится ра ботать в незнакомых областях (так чаще всего и бывает при работе программными проектами). Как правило, что бы понять, что именно пытаются создать та, приходится и испробо вать много новых идей. Бывает и так, что поставленная вовсе недостижима. Ниже я способ, согласовать потребности в эксперименте и в документировании требований к проекту.

Недостаточно подробное определение обычно являет следствием понимания. Если недостаю щие сведения относятся к или другим вопросам бизнеса, то разработчики мало чем помогут — это работа менеджера проекта и менеджера по Однако при нехватке сведений о функциях, когда неясно, как работает та или иная функция, откуда рется информация или чего хочет пользователь, можно создать прототип пользовательского интерфейса, иллюст рирующий вид этих функций. Если недостающая информация технических может ли программный продукт выполнять те или иные действия, можно провести анализ технической мости, а затем создать прототип. Вот как свести воедино информацию из реального мира, рабо и творческий процесс в процесс формулирования бований, прежде чем перейти к планированию (рис.

Главная идея в том, чтобы заранее выяснить места риска и до начала работы над проектом разрабо тать решения потенциальных проблем. Анализ мости и прототипы интерфейса помо гут понять суть оценить потребности и снизить общий риск. Эти методики обеспечивают процесс | Часть 2. и планирование требований обратной с внешним миром и составлять более детальные планы, Черновик Моделирование областей Разработка модели риска использования 1 Обновление требований и приведение их к окончательному виду Составление плана проекта Одновременное утверждение требований Рис. Связь между требованиями, практичностью и созданием прототипа.

О базовых методиках анализа технического риска и создания прототипов пользовательского интерфейса, а так же их использование формулирования оптимальных требований см. главы 9 и 10.

Pages:     | 1 || 3 | 4 |



© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.