1. Записывайте сценарии использования мобильных устройств. Не существует лучшего способа, чем описание на бумаге каждого возможного пользовательского сценария из подготовленного вами списка. Чем более подробно описаны сценарии, тем лучше. Определите круг потенциальных пользователей мобильного приложения. Определите, какие устройства они могут иметь при себе. Определите, какие задачи они смогут решать при помощи данного программного обеспечения. Определите где и когда они могут использовать ваше мобильное приложение. Определите длительность и частоту возможных сеансов взаимодействия с устройством. Запись всей этой информации на бумаге обострит ваше мышление и позволит получить конкретные отзывы от других участников рабочей группы, потенциальных пользователей приложения и других заинтересованных сторон. Не менее важно указать также то, для выполнения чего ваше мобильное приложение не предназначено. Тем самым будут полностью определены границы и сфера применения вашего мобильного приложения
2. Определите, какая часть системы перемещается на устройство. Будет очень неплохо, если вы предварительно разделите приложение на части, соответствующие серверу, устройству и настольному компьютеру, если это только возможно. Это позволит вам получить хорошее представление о запросах вашего мобильного приложения в отношении обработки, хранения и обмена данными.
3. Создайте начальный прототип. Располагая современным инструментарием RAD (Rad Application Development — быстрая разработка приложений), можно сравнительно легко создавать начальные прототипы того, что вы задумали. Создание прототипов — отличная вещь. Подготовка и выполнение прототипов на устройстве поможет вам лучше изучить возможности и ограничения выбранного вами оборудования и выявить проблемы проекта, которые вы могли упустить. Помимо этого, наличие выполняющегося прототипа сделает возможной оценку дееспособности определенных вами сценариев использования приложения
4. Проанализируйте, подходит ли разработанный вами пользовательский интерфейс прототипа для выбранного целевого устройства. Создание прототипа приложения ясно покажет вам, каким образом приложение будет представлять данные и взаимодействовать с пользователем. Не каждое приложение подойдет для любого устройства. Прототип продемонстрирует вам, как именно будут выглядеть и работать определенные вами сценарии использования приложения на физическом оборудовании устройства. В зависимости от полученных при этом результатов может потребоваться уточнение сценариев, изменение парадигмы пользовательского интерфейса и даже выбор другого целевого мобильного устройства.
5. Используя опыт работы с прототипом, уточните модель данных приложения. Работа с прототипом приложения должна помочь вам лучше понять, с какими типами данных придется иметь дело приложению, и в каких условиях будет осуществляться отправка и получение этих данных. У вас будет достаточно информации для того, чтобы определить, необходимо ли использовать локальную базу данных, и какой тип локального хранилища может потребоваться. Как и в случае пользовательского интерфейса, потребности вашего приложения в данных могут вынудить вас к пересмотру решения о выборе целевого оборудования на основании доступности баз данных или требований к хранению данных.
6. Проанализируйте, реализуемы ли для выбранного целевого устройства заложенные в прототипе приложения допущения, касающиеся вопросов обмена информацией. Критически оцените потребности вашего мобильного приложения в обмене информацией и взаимодействии с другими системами. Требуется ли высокоскоростной доступ в сеть? Существует ли необходимость в роуминге? Смогут ли соединение с сетью и синхронизация данных через настольный или переносной компьютер в достаточной мере удовлетворить потребности вашего мобильного приложения в обмене информацией?
7. Приступите к разработке программного обеспечения! Вооружившись тщательно продуманным списком пользовательских сценариев, первоначальным представлением о том, каким должно быть подходящее разбиение приложения на отдельные части, и ценными сведениями, полученными в процессе апробирования экспериментальной модели приложения, вы будете вполне готовы приступить к его разработке.
Каждый из нас должен оставлять за собой право проснуться назавтра поумневшим по сравнению с сегодняшним днем. Очень важно, чтобы к тому моменту, когда вы будете приступать к непосредственной разработке вашего мобильного приложения, у вас имелся хорошо продуманный план действий. Кроме того, необходимо понимать, что в процессе разработки приложения будут выясняться новые факты, которые могут заставить вас пересмотреть и скорректировать первоначальный план. Важно не только представлять себе в общих чертах, как должно работать приложение, но и ориентироваться на конкретные сценарии, наполняющие это представление содержанием. Без этого вы рискуете прийти к тому, что конечный результат будет подобен кухонному комбайну, который готовит ужасный кофе, печет рыхлый хлеб и плохо справляется с мытьем посуды. У вас должна быть ясная картина того, для чего именно предназначено и, что не менее важно, для чего не предназначено ваше приложение. Если имеющийся план требует изменений — измените его, но сфера применения и соответствующие сценарии использования вашего мобильного приложения в любом случае должны быть определены.
ГЛАВА 7
Шаг 1: начинайте с анализа проблем производительности и никогда не упускайте их из виду
per• form• ance [pr fáwrmns] производительность: эффективность выполнения кем-то или чем-то определенной работы
(Encarta 2004, Dictionary)
Наилучший способ удерживать курс — это не сбиваться с него. Если вы оступились — остановитесь, сделайте шаг назад и продолжите движение в нужном направлении.
Автор данной главы
Введение
Как указано в приведенной выше выдержке из словаря, производительность — это не просто скорость, но эффективность выполнения. Считаться полезным может лишь код, который выполняется эффективно. Производительность вашего мобильного приложения будет первым и главным критерием, по которому пользователи будут судить о его качестве и эффективности. Хотя высокая производительность приложения сама по себе не может гарантировать его успешности, однако если она не обеспечена — все ваши усилия заведомо обречены на неудачу.
Экономика учит нас тому, что избыток капитала создает благоприятные условия для инвестиций и развития. По сути дела, производительность является тем избыточным капиталом, который вы должны вложить в разработку и развитие вашего мобильного приложения. Обеспечив высокую производительность, вы сможете добавлять новые возможности, испытывать новые модели и расширять сферу применения приложения. Эту свободу вам обеспечат излишки капитала, образуемого избытком производительности по сравнению с ее минимально необходимым уровнем. Если же ваше мобильное приложение будет обладать низкой производительностью, то вы сами себя загоните в угол, и стиль разработки программного кода проекта будет напоминать жизнь от получки до получки. В условиях, когда производительность приложения низка или ее едва хватает, вы будет вынуждены довольствоваться имеющимися возможностями и тратить все свое время на "латание дыр" и внесение исправлений, чтобы приложение вообще могло работать, и конечный результат будет не более чем посредственный. При этом речь идет не том, что некоторым частям приложения требовалось бы уделить более пристальное внимание, и не об ошибках, которые могут допускаться разработчиками из-за небрежности, отсутствия плана или недостатка дисциплины в работе. Производительность — вот что является решающим фактором!
Следует также отметить, что производительность — понятие субъективное. Бесполезно доказывать кому-то, что приложение работает нормально, если ваш оппонент утверждает, что с его точки зрения оно работает слишком медленно. Это все равно как если бы вы пытались убедить того, кто совершает пробную поездку на старомодном "универсале", что двигатель и коробка передач в этой машине почти такие же, как в спортивном автомобиле, и что следует обращать внимание не на внешний вид, а на объективные характеристики. Если покупателю автомобиль кажется тихоходным, то таковым он его и будет воспринимать. Понятие "высокой" производительности связано не с быстродействием отдельных частей, а с субъективной оценкой поведения всей системы в целом.