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

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

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. Составление технического задания и выбор методологии

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

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