Шаг 5: пакетирование приложения для его установки
В случае мобильных устройств процесс пакетирования и установки приложения часто называют инициализацией, или подготовкой к работе. Этот шаг должен быть отнесен к категориям, числящимся под рубрикой "последние по порядку, но не менее важные", поскольку, как и все остальные шаги, его корректное выполнение также требует применения итеративного подхода. Следует обязательно продумать, какие компоненты должны быть развернуты, чтобы ваше приложение могло выполняться на целевых устройствах, каким образом пользователи должны это осуществлять и какие способы будут использоваться впоследствии для обновления приложения. Ниже приведен перечень вопросов, давая ответы на которые вам будет легче выработать стратегию инициализации вашего мобильного приложения:
■ Какие модули развертываются вместе с приложением? Представляет ли собой приложение единственный двоичный исполняемый файл или имеются дополнительные файлы данных, устанавливаемые вместе с ним, например, изображения, текстовые файлы или файлы баз данных? Должен ли и может ли любой из этих файлов быть включен в двоичный файл приложения в качестве ресурса для упрощения процесса развертывания? Требуются ли приложению другие библиотеки времени выполнения или компоненты, подлежащие установке вместе с ним на устройстве?
■ Какая процедура используется для развертывания приложения на устройстве? Устанавливается ли приложение на самом устройстве через сетевое соединение? Устанавливается ли оно через настольный компьютер, с которым устройство связано кабелем? Устанавливается ли оно с карты, вставляемой в устройство? Устанавливается ли приложение с одного устройства на другое посредством инфракрасного порта, облегчающего распространение приложения между равноправными устройствами?
■ Кто будет осуществлять развертывание приложения? Будут ли это делать конечные пользователи? Знакомы ли конечные пользователи с целевыми устройствами и процедурами инсталляции? Будут ли организации развертывать приложения на устройствах своих сотрудников? Будет ли приложение развертываться оператором мобильного телефона или загружаться из Web?
■ Как будут создаваться новые версии приложения? Будет ли приложение само проверять необходимость своего обновления за счет использования сетевого ресурса? Будет ли сервер сканировать устройства, чтобы определить, нуждаются ли они в установке новой версии? Будут ли новые версии приложения устанавливаться при помещении устройства в лоток ПК?
■ Могут ли возникнуть проблемы защиты приложения? При широком развертывании любого приложения всегда возникают вопросы, связанные с его защитой, которые обязательно следует рассмотреть. Должно ли приложение снабжаться цифровой подписью? Должны ли данные, с которыми работает приложение, быть тем или иным способом защищены? Что может произойти с данными, если устройство, на котором хранятся данные, будет утеряно или украдено?
Поскольку существует бесчисленное множество всевозможных мобильных устройств и разработанных для них сетевых моделей, ни на один из поставленных выше вопросов невозможно дать единственный правильный ответ. Какое решение будет наилучшим, зависит от типа устройства, способа его подключения к сети, опытности пользователя и политик, которые сетевые операторы могут использовать для контроля доступа к устройству.
План инициализации приложения следует записать на бумаге и добавить в список сценариев. Также крайне желательно включать разработку и проверку корректности процедуры пакетирования и установки приложения в реальных условиях в состав контрольных этапов начальных стадий проекта. Современные инструментальные среды разработки могут прекрасно справляться с задачей установки приложения на устройстве в целях тестирования, но при самостоятельной установке приложения конечными пользователями среда разработки для этих целей обычно не применяется. Как показывает практика, развертывание приложения конечными пользователями всегда является проблемой.
Хорошо известна старая, проверенная временем истина: "Лучше хорошо выполнить посредственный план, чем иметь самый хороший, детально проработанный план, который так и остается нереализованным". Эта истина применима и к разработке современного программного обеспечения. Что толку от того, что у вас имеются разработанные по всем правилам план и методология, если они недостаточно гибки, чтобы их можно было приспособить к реалиям итеративного характера получения конечного результата. "Для разных проектов разработки требуются разные уровни строгости и опыта" — вот лучшее руководство к пониманию того, какая степень формализации обернется наибольшей выгодой для проекта. Кроме того, следует быть постоянно готовым к любым неожиданностям. По мере того как вы будете разрабатывать и тестировать приложение, обязательно будут выявляться факторы, которые вынудят вас существенно изменять свои планы. Всегда учитывайте это и организуйте процесс разработки таким образом, чтобы он позволял справляться с подобными ситуациями. Итак, в хронологическом порядке:
1. Вооружитесь определенной методологией разработки и строго придерживайтесь ее. Одна из этих методологий была представлена в общих чертах в этой главе и рассматривается более подробно в последующих главах. Эта методология хорошо приспособлена для мобильных устройств. Если окажется, что ваши потребности несколько отличаются, можете изменить ее, но в любом случае вы должны действовать в соответствии с определенной методологией.
2. Подготовьте единственный основной документ проекта, который определяет ваши цели и позволяет отслеживать степень выполнения проекта. Уровень формализации этого документа будет зависеть от того, что собой представляет ваша организация. Если вы — индивидуальный разработчик, работающий автономно, то этот документ будет просто помогать вам отслеживать разработку высокоуровневых задач и сценариев, определять ваши контрольные точки в процессе решения этих задач, а также отслеживать невыполненные пункты, подлежащие дополнительному анализу; объем такого документа не должен превышать нескольких страниц. В случае если у вас крупная организация, этот документ может представлять собой официальный контракт между вами и другой организацией, в котором подробно описывается, что именно должно быть выполнено, и какие проектные решения были приняты, а также детализированы контрольные этапы проекта и его состояние на протяжении всего периода разработки. В соответствии с этим документом и должна осуществляться разработка, и вы все время должны поддерживать его "актуальность". Пусть это будет единственный документ, который представляет задачи вашего проекта и позволяет объективно оценивать этапы его выполнения.
3. Идентифицируйте контрольные точки, для которых четко определены критерии их выполнения. Это лучший способ помочь вам и участникам группы разработчиков быть честными перед самими собой при оценке результатов вашей работы. Набор четко определенных контрольных точек, которые позволяют оценивать степень завершения разработки приложения и решения поставленных задач, — бесценная вещь, независимо от того, работаете ли вы один или в составе большой организации. Достоинства контрольных точек (этапов) просто невозможно переоценить. Если вы не совсем хорошо представляете себе, какое количество контрольных точек является оптимальным, рекомендую начать с пяти. Если вам не удается разбить свой проект на пять поддающихся оценке шагов, то либо ваш проект настолько тривиален, что его можно выполнить буквально за пару дней, либо вы были недостаточно старательны при определении этапов. Пять шагов — это разумное количество для начала, которое позволит достаточно подробно анализировать степень вашего прогресса. В случае более крупных проектов может оказаться желательным дополнительное разбиение этих контрольных точек на ряд более мелких; в случае менее крупных проектов вы можете обойтись четырьмя контрольными точками, но старайтесь не использовать меньшее их количество. Введение контрольных точек выполняет три основные функции: 1) они позволяют вам объективно оценивать продвижение к намеченным целям; 2) они обеспечивают возможность пересмотра намеченных целей и контрольных точек в будущем с учетом всего нового, что вы узнаете в процессе работы над проектом; 3) завершение контрольной точки дает формальный повод критически проанализировать проведенную работу, подчистить код и скорректировать проект с учетом любых подходящих рационализаторских предложений. Без введения контрольных точек и доводки их конечных результатов существует риск того, что вы будете непрестанно заняты одним только написанием кода, и все ваши решения относительно этого будут носить исключительно тактический характер. Полученный код будет представлять собой сплошное "спагетти", сопровождение которого будет весьма затруднительным. Даты контрольных точек можно устанавливать, а можно и не устанавливать; чем многочисленнее группа разработчиков, тем большую значимость приобретает установление контрольных дат. Самое главное, чтобы все участники приходили к финишной линии текущей контрольной точки вместе, и только после этого переходили к выполнению очередной контрольной точки. Контрольные точки — ваши друзья, используйте их!
