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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

СТБ ИСО/МЭК 12207-2003. Информационная технология. Процессы жизненного цикла программных средств. Это общепринятый стандарт, в котором описываются основные понятия жизненного цикла программного продукта, прикладное применение стандарта, основные процессы жизненного цикла, вспомогательные процессы жизненного цикла и организационные процесс жизненного цикла. Данный стандарт является аутентичным аналогом международного стандарта ISO/IEC 12207: 1995. Именно отсюда можно взять все основные понятия, а так же этапы жизненного цикла программного продукта.

Фатрелл Р., Шафер Д., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. М., 2003. Эта книга посвящена вопросам, возникающим на различных стадиях подготовки программных проектов, начиная с разработки программного обеспечения и завершая рассмотрением каких-либо юридических вопросов, связанных с процессом создания и внедрения программ. Материалы книги соответствуют сертификационным программам менеджмента качества программных проектов Института качества программного обеспечения. Книга очень полезна, так как именно благодаря ей можно больше узнать о том, как улучшить качество и уменьшить сроки выполнения и расходы на этапах разработки и внедрения проектов.

Добрынин А. С. О формировании комплекса инструментальных средств ИТ-провайдера для построения расписаний процесса внедрения сервиса / А. С. Добрынин, С. М. Кулаков, В. В. Зимин, Н. Ф. Бондарь // Научное обозрение. 2013. № 8. С. 93-101. В статье рассматривается механизм решения задачи построения расписаний процесса внедрения сервиса с использованием инструментальных средств провайдера, построенных на базе спектра технологий. Данная статья необходима для понятия вышеописанного механизма. Статья написана доктором технических наук, и опубликована в научно-техническом журнале.

Таким образом, все приведенные источники верифицированы, а значит их можно спокойно использовать – это статьи из научных электронных библиотек, напечатанных в специализированных научных журналах, к примеру – в журналах ВАК, используются также различные ГОСТЫ и несколько учебных пособий.

1. Жизненный цикл и существующие стратегии разработки программного продукта

1.1. Понятие программного продукта

Программный продукт – это комплекса взаимосвязанных программ для решения определенной проблемы (задачи) массового спроса, подготовленный к реализации. [1] В данной работе речь пойдет о мобильных приложениях. Это тоже программные продукты. Они могут создаваться как индивидуально – разработка под заказ, так и для массового распространения среди пользователей. Отличительной особенностью любого программного продукта должна быть их системность – функциональная полнота и законченность реализуемых функций обработки, которые применяются в совокупности [5].

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

1.2. Понятие жизненного цикла

Под термином жизненного цикла программного продукта принято понимать совокупность процессов и этапов развития организмов живой природы, технических систем, продуктов производства от моментов зарождения или появления потребности их создания и использования до прекращения функционирования или применения. [1] Говоря другими словами, это ряд событий, происходящих с системой с момента создания и до конца его разработки и внедрения.

Модель жизненного цикла программного продукта зависит от специфики, масштаба и сложности проекта, а так же тех условий, в которой система создается и функционирует [6]. На каждой стадии такого цикла могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207 [1], и наоборот – один и тот же процесс может выполняться на различных стадиях.

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

В стандарте СТБ ИСО/МЭК 12207-2003 [1] в качестве одной из основных задач подготовки процесса разработки ПС и систем регламентирована задача выбора модели жизненного цикла разработки с учетом особенностей конкретного проекта. В стандарте ГОСТ Р ИСО/МЭК ТО 15271-2002 [2] определено три основных стратегии разработки программных продуктов и систем. К ним относятся каскадная, инкрементная и спиральная стратегии.

1.3. Основные стратегии разработки программных продуктов

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

Рисунок 1 –Водопадная модель жизненного цикла.

Она была предложена в 1970 году Уинстоном Ройсом, и предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. [2] Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Можно выделить следующие этапы проекта в соответствии с этой моделью:

1. Формирование требований;
2. Проектирование;
3. Реализация;
4. Тестирование;
5. Внедрение;
6. Эксплуатация и сопровождение.

Так же можно выделить ряд достоинств и недостатков такой модели. К преимуществам можно отнести:

1. Полная согласованная документация на каждом этапе;
2. Легко определить сроки и затраты на проект.

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

Таким образом, данная модель может применяться только для создания небольших систем.

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

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

Рисунок 2 –Поэтапная модель с промежуточным контролем.

Альтернативой последовательной модели является модель итеративной и инкрементальной разработки [2]. Она предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектов в целом.

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

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

1. Очень долгое время отсутствует целостное понимание возможностей и ограничений проекта;
2. При итерациях приходится отбрасывать часть сделанной ранее работы.
3. Снижается добросовестность специалистов при выполнении работ.

И все же, в современном мире варианты итерационного подхода реализованы в большинстве современных методологий разработки. Рассмотрим еще одну возможную модель жизненного цикла – спиральная модель [2].

Рисунок 3 – Спиральная модель.

Эта модель была разработана в середине 1980-х годов Барри Боэмом. Основывается она на классическом цикле Деминга PDCA (plan-do-check-act) – это повторяющийся процесс принятия решения, представляющий собой простейший алгоритм действий руководителя по управлению процессом и достижению его целей. Начинается такой цикл с планирования – установления целей и процессов, необходимых для достижения целей, планирование работ по достижению целей процесса и удовлетворение возможного пользователя, а также планирование выделения и распределения необходимых ресурсов. Следующий этап – выполнение запланированных работ. После него идет проверка – сбор информации и контроль результата на основе ключевых показателей эффективности, получившегося в ходе выполнения работы, выявление и анализ отклонений, установление причин отклонений. Завершающий этап такого цикла – воздействие, то есть принятие мер по устранению причин отклонений от запланированного результата, изменение в планировании и распределении ресурсов. При использовании такой модели жизненного цикла программного продукта создается несколько итераций, в данном случае это витки спирали, методом прототипирования [6]. Каждая такая итерация соответствует созданию фрагмента или версии программного продукта. Далее уточняются цели и характеристики проекта, оценивается качество полученных результатов и планируется работа следующей итерации.

Во время работы с каждой итерацией проводится оценка следующего:

1. Риск превышения сроков и стоимости программного продукта;
2. Необходимость выполнения еще одной итерации;
3. Степень полноты и точности понимания требований к системе;
4. Целесообразность прекращения проекта.

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

1. Дефицит специалистов;
2. Нереалистичные сроки и бюджет;
3. Реализация несоответствующей функциональности;
4. Разработка неправильного пользовательского интерфейса;
5. Ненужная оптимизация и оттачивание деталей;
6. Непрекращающийся поток изменений;
7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию;
8. Недостатки в работах, выполняемых внешними ресурсами (по отношению к программному продукту);
9. Недостаточная производительность итоговой системы;
10. Разрыв в квалификации специалистов разных областей.

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

1.4. Возможные классификации проектов разработки

ГОСТ Р ИСО/МЭК ТО 12182-2002 [4] содержит схему классификации программных средств по 16 видам, каждый в свою очередь подразделяется на классы. Эта классификация имеет общий характер и поэтому не может использоваться для обоснования выбора модели жизненного цикла программного продукта.

Институтом качества программного обеспечения SQI (Software Quality Institute, США) разработана схема классификации проектов разработки для выбора конкретной модели жизненного цикла. [5] В основе данной классификации лежат четыре категории критериев. Ниже представлено описание каждого из них.

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

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

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

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

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

1. Масштаб продукта проекта (размер или сложность программного продукта проекта);
2. Стабильность продукта проекта (эволюция программного продукта проекта);
3. Критичность продукта проекта (степень влияния на общество повреждений программного продукта проекта).

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

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

1.5. Модели полного жизненного цикла

Многие формализованные подходы, в частности спиральная и каскадная, предусматривают последовательное прохождение программного продукта по определенным этапам жизненного цикла [6]:

1. Постановка задачи;
2. Анализ рисков;
3. Анализ требований;
4. Построение проектных спецификаций;
5. Проектирование;
6. Реализация;
7. Тестирование;
8. Ввод в эксплуатацию и сопровождение;
9. Вывод из эксплуатации.

Как понятно из описания, такие модели получаются очень большие, даже громоздкие, что создает проблемы на практике в условиях изменений требований. Зачастую снижение производительности коллектива разработчиков влечет за собой изменение графика работ и увеличение бюджета проекта. Сама идеология предварительного алгоритмического проектирования изначально предполагает отсутствие гибкости, разработчики не могут оперативно реагировать на изменения требований заказчика. К сожалению, многие коллективы разработчиков считают, что процесс создания программного обеспечения пока еще является недостаточно всеобъемлющим и формализованным, тем самым они способствуют неконтролируемому росту разнообразных стандартов проектирования, диаграмм, нотаций и спецификаций. Так, например, стандарт UML 2.0 (Unified Modeling Language) [6] предусматривает возможность использования 14 типов диаграмм, из которых на практике обычно используется не больше половины.

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

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

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

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

1.6. Гибкие методики разработки программного продукта.

К гибким методики относят такие известные методики, как Crystal [7], Scrum [8], XP [7]. Что же это такое и чем они лучше?

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

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

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

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

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

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

2. Этапы разработки мобильных приложений

Разработка мобильного приложения с самого начала и до релиза, в среднем, включает в себя оценку, аналитику, дизайн, разработку, тестирование, багфиксинг, релиз и поддержку после релиза [1]. Все эти этапы различны по времени, затраченном на их выполнение. Какой-то этап может занимать всего считанные дни, а другой и через 3 месяца все еще может находиться в процессе работы. Также на количество этапов влияет объем проектируемого продукта и существующих вводных данных. Поэтому такое количество этапов нужно уже планировать на конкретном примере. В данный момент просто возьмем среднее их значение.

2.1. Составление технического задания и выбор методологии

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

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

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

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

2.2. Планирование и оценка

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

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

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

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

2.3. Аналитика

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

После проведения данного этапа на выходе формируются:

1. Спецификация функциональных требований;
2. Спецификация нефункциональных требований;
3. Основа графического интерфейса;
4. План проекта;
5. Детальный бюджет.

2.4. Дизайн приложения

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

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

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

После проведения данного этапа на выходе формируются:

1. Карта экранов;
2. Дизайн приложения.

2.5. Разработка

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

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

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

В нативной разработке обычно применяются такие языки, как Java и Kotlin для Android, Objective-C и Swift для iOS. В кроссплатформенных решениях могут применяться React Native и NativeScript.

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

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

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

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

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

3. Тестирование и ввод в эксплуатацию мобильного приложения

3.1. Тестирование

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

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

Сам этап тестирования можно разделить еще на несколько этапов.

3.1.1. Определение необходимых типов тестирования мобильным приложений

Перед началом тестирования любого мобильного приложения необходимо определить, что именно в данном мобильном приложении необходимо протестировать:

1. Набор функциональности;
2. Удобство использования;
3. Совместимость;
4. Производительность;
5. Безопасность.

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

1. Выяснить, какие устройства будут поддерживать приложение;
2. Определить, какая версия операционной системы будет самой ранней из тех, что поддерживаются приложением;
3. Выявить наиболее популярные модели мобильных устройств у целевой аудитории;
4. Определить набор неосновных (дополнительных) устройств с экранами разных размеров, потенциально поддерживаемых приложением;
5. Решить, будут ли использованы для тестирования физические устройства или их эмуляторы.

3.1.2. Тестовые случаи и разработка сценариев тестирования приложения

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

В дополнение к таким функциональным тестовым случаям, необходимо еще охватить и проверить некоторые отдельные моменты:

1. Особенность использования батареи;
2. Скорость работы приложения;
3. Требования к данным;
4. Объем используемой памяти.

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

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

3.1.3. Ручное и автоматическое тестирование

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

3.1.4. Тестирование юзабилити и бета-тестирование

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

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

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

1. Совместимость;
2. Пользовательский интерфейс;
3. Интерфейс;
4. Внешние факторы;
5. Доступность.

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

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

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

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

3.1.5. Тестирование производительности

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

На данном этапе тестирования необходимо проверить работу приложения, изменяя такие показатели, как соединение – 2G, 3G на Wi-Fi, проверить скорость отклика, потребление заряда батареи, стабильность работы и т.д. Рекомендуется проверять мобильное приложение на предмет масштабируемости и наличие возможных проблем с производительностью.

В рамках этого этапа важно пройти нагрузочное тестирование мобильного приложения.

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

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

Список того, что обязательно нужно протестировать в приложении:

1. Тестирование процесса установки;
2. Тестирование возможных обновлений;
3. Эксплуатационное тестирование;
4. Тестирование процесса регистрации и авторизации;
5. Тестирование функций, специфических для устройств;
6. Тестирование отправки и получения сообщений об ошибках;
7. Низкоуровневое тестирование ресурсов: использование памяти, автоматическое освобождение ресурсов и т.д.
8. Тестирование сервисов: функционирование как в режиме онлайн, так и в автономном режиме.

3.1.6. Аттестационное тестирование и тестирование безопасности приложения

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

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

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

Кроме всего вышеперечисленного, есть ряд вопросов, на которые стоит ответить, чтобы понимать, насколько защищено разрабатываемое мобильное приложение:

1. Есть ли у приложения сертификаты безопасности?
2. Использует ли приложение безопасные сетевые протоколы?
3. Существуют ли какие-либо ограничения, например, количество входа в систему до блокировки пользователей?

3.1.7. Тестирование устройства

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

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

1. Важная информация, выявленная в результатах проведенных испытаний;
2. Информация о качестве проводимого тестирования;
3. Сводная информация о качестве тестируемого мобильного приложения;
4. Статистика, полученная из отчета об различных инцидентах;
5. Информация о видах тестирования и времени, затраченном на каждый из них.

Также следует указать в отчете, что:

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

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

3.2. Добавление приложения в магазин

Когда серия тестов и доработок приложения завершены, а вся команда разработчиков одобряют полученный результат, именно тогда приходит время добавления приложения в соответствующие магазины. Это может быть - Apple App Store, Google Play или любой другой сервис по желанию клиента.

Итак, в итоге получаем публикацию приложения в магазине.

3.3. Дальнейшая техническая поддержка и маркетинговое продвижение приложения

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

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

В итоге, в последней главе были рассмотрены завершающие этапы жизненного цикла программного продукта – это тестирование и ввод в эксплуатацию, а также последующее сопровождение.

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

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

ЗАКЛЮЧЕНИЕ

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

Библиография

Описание нормативно-правовых актов

1. СТБ ИСО/МЭК 12207-2003. Информационная технология. Процессы жизненного цикла программных средств.
2. ГОСТ Р ИСО/МЭК ТО 15271-2002. Информационная технология. Руководство по применению
3. ГОСТ Р ИСО/МЭК 12207 Процессы жизненного цикла программных средств.
4. ГОСТ Р ИСО/МЭК ТО 12182-2002. Информационная технология. Классификация программных средств.

Описание книг одного-трех авторов

1. Фатрелл Р., Шафер Д., Шафер Л. Управление программными проектами: достижение оптимального качества при минимуме затрат. М., 2003.
2. Рассел Дж. Жизненный цикл программного обеспечения / Дж. Рассел // Bookvika Publishing, 2012. 89 с.

Описание книг на иностранном языке

1. Мартин Р. С. Agile software development / Р. С. Мартин, Дж. В. Ньюкирк, Р. С. Косс // Principles, Patterns and Practicies Principles, Patterns and Practicies. М. : Вильямс, 2004. 752 с.
2. Cohn Mike. Scrum: Succeedind with Agile: Software Development Using Scrum (Addison-Wesley Signature Series). М.: Вильямс, 2011. 576 с.

Описание учебных пособий

1. Зимин В. В. Основы управления жизненным циклом сервиса систем информатики и автоматизации (лучшие практики ITIL): учеб. пособие / В. В. Зимин, А. А. Ивушкин, С. М. Кулаков, К. А. Ивушкин. Кемерово: Кузбассвузиздат, 2013. 500 с.

Описание статьи из периодического издания

1. Добрынин А. С. О формировании комплекса инструментальных средств ИТ-провайдера для построения расписаний процесса внедрения сервиса / А. С. Добрынин, С. М. Кулаков, В. В. Зимин, Н. Ф. Бондарь // Научное обозрение. 2013. № 8. С. 93-101.
2. Койнов Р. С. Об использовании принципа согласованного управления в задачах внедрения ИТ-сервиса / Р. С. Койнов, А. С. Добрынин, С. М. Кулаков, В. В. Зимин // Вестн. развития науки и образования. 2013. № 6. С. 23-27.