Текст книги "Время — деньги. Создание команды разработчиков программного обеспечения"

Автор книги: Эд Салливан

сообщить о нарушении

Текущая страница: 11 (всего у книги 19 страниц)

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

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

Почему это важно

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

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

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

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

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

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

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

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

Как её создавать

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

Скелет

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

Мышцы

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

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

Комплект

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

Сбор всего вместе

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

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

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

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

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

• отправка сообщения о прохождении теста или сбое;

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

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

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

Ежедневные сборки, комплекты и тесты

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

Убеждение

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

Из собственного опыта

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

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

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

Типичные проблемы и их решение

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

Отсутствие технологов по разработке ПО

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

Недостаточная автоматизация

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

Запоздалая процедура установки

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

Дисциплина

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

Часть 2
Формулирование и планирование проекта.

Глава 8
Требования

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

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

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

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

Центральная идея проекта

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

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

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

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

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

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

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

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

Поиск и решение пользовательских проблем

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

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

Из собственного опыта

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

Формулирование требований

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

Общие и частные требования

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

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

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

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

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

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

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

• Общее требование 1

•• Частное требование 1

••• Частное требование нижнего уровня 1.1

••• Частное требование нижнего уровня 1.2

•• Частное требование 2

••• Частное требование нижнего уровня 2.1

••• Частное требование нижнего уровня 2.2

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

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

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

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

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

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

•• Удалить заказ.

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

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

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

•• Microsoft Internet Explorer версии X.

•• Netscape версии Y.

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

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

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

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

•• Проверка статуса заказа должна занимать менее 4 секунд.

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

• Облегчить использование приложения с помощью новых возможностей:

•• Разрешить заказ нескольких товаров в одном заказе.

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

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

Полнота требований

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

• Задачи и функции проекта

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

• Пользовательский интерфейс

Хотя при работе над пользовательским интерфейсом придётся дать ответ на два важных вопроса: «Как пользователю выполнить действие X?» и «Как должна выглядеть функция Y?», лучше не пытаться формализовать их, так как это слишком затруднит описание, тестирование и реализацию последовательных улучшений. Вместо этого надо разработать визуальную модель приложения с помощью различных методик конструирования прототипов пользовательского интерфейса. Эта модель и будет спецификацией требований к пользовательскому интерфейсу. (Подробнее об этот см. главу 9. Там же я расскажу об эффективных способах формулирования и анализа требований к пользовательскому интерфейсу программного продукта.) При наличии конкретной платформы, технологий или связанных с бизнесом ограничений, влияющих на структуру интерфейса, важно оговорить их заранее.

• Среда

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

• Интеграция

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

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

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

• Установка

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

• Тестирование

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

Детализация требований

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

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

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

Рис. 8-1. Связь между требованиями, практичностью и созданием прототипа.

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