Этапы процесса создания программ

Содержание

Scrum является одним из возможных способов реализации гибкой (Agile) методологии разработки. В отличие от каскадной модели жизненного цикла ПО, отличительной особенностью Scrum является итеративность.

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

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

Владелец продукта(Product owner) представляет интересы конечного пользователя.
Скрам-мастер (Scrum master) следит за соблюдением принципов Scrum-разработки, координирует процесс, проводит ежедневные собрания (Scrum Meetings).
Скрам-команда(Scrum team) участвует в разработке продукта. В скрам-команду входят программисты, тестировщики, аналитики и прочие специалисты.

Итак, давайте рассмотрим основные этапы разработки, характерные для Scrum.

Урок 2. Этапы разработки ПО

Шаг 1. Создание бэклога продукта

Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story). Каждой истории соответствует уникальный ID. Вот пример пользовательских историй из бэклога продукта, использованного во время работы над XB Staff Manager:

ID	User Story
a-001	Как менеджер, я хочу добавлять, удалять, редактировать задачи, чтобы управлять занятостью сотрудников
a-002	Как менеджер, я хочу добавлять новые задачи и изменять продолжительность, а также конечную и начальную даты текущих задач с помощью drag-and-drop
a-003	Как менеджер, я хочу назначать сотрудникам 2 типа задач: -Part-time task -Full-time task чтобы обозначить постоянную/временную занятость сотрудника

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

Важность (Importance). Степень важности задачи по мнению владельца продукта. Описывается произвольным числом.
Предварительная оценка (Initial estimate). Предварительная оценка объема работ. Измеряется в story point’ах.
Как продемонстрировать (How to demo). Описание способа демонстрации завершенной задачи.

Помимо этих обязательных полей, при необходимости могут быть добавлены дополнительные:

Как делают игры | Все этапы создания игр — подробно

Категория (Track) служит для того, чтобы владелец продукта мог выбрать все пункты определенной категории и установить им низкий или высокий приоритет. Примером такой категории может быть «Панель управления».
Компоненты (Components) состоит из списка компонентов продукта, которые будут изменены во время работы над историей. Такими компонентами могут быть модули приложения, как например, аутентификация или поиск.
Инициатор запроса (Requestor) -заказчик, заинтересованный в реализации определенной функциональности. Это поле необходимо, если нужно держать заказчика в курсе текущего положения дел.
ID в системе учёта дефектов (Bug tracking ID) содержит ссылки на обнаруженные дефекты, относящиеся к истории с определенным ID.

После того, как составлен бэклог проекта, можно приступить к следующему шагу — планированию спринта.

Шаг 2. Планирование спринта и создание Бэклога спринта

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

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

Во время планирования спринта команда выбирает самые приоритетные пользовательские истории из бэклога продукта и решает, каким образом будут решаться поставленные задачи. Истории, выбранные для реализации в течение данного спринта составляют Бэклог спринта (Sprint backlog). Количество историй, попадающих в бэклог спринта зависит от их длительности в story point’ах, присвоенных каждой истории на этапе предварительной оценки. Это количество выбирается так, чтобы каждая история была успешно реализована к концу спринта.

Шаг 3. Работа над спринтом. Scrum meetings

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

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

scrum board

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

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

Шаг 4. Тестирование и демонстрация продукта

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

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

Шаг 5. Ретроспектива. Планирование следующего спринта

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

Заключение

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

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

Об авторе
Последние статьи

Источник: xbsoftware.ru

Создание мобильных приложений

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

Тенденции рынка

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

Наглядная статистика

Уже привычной для всех тенденцией является то, что хоть в Google Play и больше потенциальных покупателей, продажи в App Store идут значительно лучше. Но, статистики продаж за 2018 год показала, что за этот год рост продаж в Google Play был выше, чем в App Store: 27,3% против 20,4% соответственно. Общую же картину за все года это сильно не изменило – оборот App Store все еще в 2 раза выше.

Подготовка

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

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

Весь рынок мобильных гаджетов можно условно разделить на две ведущие платформы: Android и IOS. Тут все относительно просто:

Устройств на базе Android значительно больше, чем на базе конкурентов, но платежеспособность пользователей этих устройств относительно низкая;
Устройства на базе IOS продаются в меньших объемах и значительная их часть в России приходится на Питер, Москву и московскую область.

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

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

Цена разработки: самостоятельно vs заказ у фрилансеров

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

Выберите одну ведущую операционную систему, под которую продукт будет написан. Это позволит уменьшить расходы минимум в два раза.

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

Бесплатные способы создать приложение

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

Совсем бесплатным этот способ не назвать – заплатить всё-таки придется. Но это будет в разы дешевле, чем заказывать работу у профессиональной команды разработчиков.

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

Такие сервисы предлагают гибридные и нативные решения. Впоследствии, зачастую можно выкупить у сервиса код программы и заниматься ей самостоятельно, или оплатить поддержку и сервис сам будет заниматься всем продвижением (в этом случае придется оплатить аккаунт в App Store или Google Play)

Заказ разработки приложения

Если вы уже подготовились и у вас есть четкое понимание того, какое приложение вы хотите, можно приступать к переговорам с потенциальным исполнителем.

Непосредственно перед самими переговорами не помешает заключить договор о неразглашении. Этим вы защитите свою идею от недобросовестного исполнителя.
Составление ТЗ (технического задания). На этом этапе важно участие заказчика. В идеале для самого заказчика хорошо подготовится к этому моменту, и иметь не просто некую абстрактную идею в уме, а по возможности детальный набросок основных окон программы. На основе работы, проделанной заказчиком, специалисту будет проще объяснить, что и как лучше реализовать на практике. Составление ТЗ требует работы специалиста, по этому эта услуга платная.
По достижении договоренности исполнитель должен предоставить смету на выполнение работ, в которой прописаны все работы, необходимые часы на выполнение задач и стоимость часа. В некоторых случаях смета не составляется, и речь идет только о стоимости часа работы специалиста. Внимание! Часы в смете необходимы для подсчета общей стоимости работ и могут быть распределены между специалистами. Конечные сроки выполнения всего заказа рассчитываются отдельно.

Этапы

Что нужно для создания любого мобильного продукта? Обычно оно проходит в несколько основных этапов. Этапы создания:

Схематический набросок: какие окна будет видеть пользователь, как между ними перемещаться, и какой в них будет размещен функционал.
Дизайн.
Разработка.
Тестирование.
Поддержка.

Проектирование и дизайн

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

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

Разработка

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

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

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

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

Тестировать совместимость с конкретными мобильными устройствами на iOS легче и быстрее, чем на Android в силу специфики разработки ПО для платформ Apple. Смартфонов на базе Android около 80% от всего рынка, у них множество производителей и разнообразная архитектура — требуется время на то, что бы выяснить, как приложение будет вести себя на различных конфигурациях железа.

Поддержка

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

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

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

Специфика

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

Этапы разработки программного обеспечения

• Спецификации – это описатели отдельных
стадий ЖЦПО и проекта в целом. Согласно
принятой терминологии в рамках учебного
процесса полная документация программы
содержит:
• – внешнюю спецификацию (анализ
требований и разработка ТЗ);
• – внутреннюю спецификацию (проект
программы);
• – спецификацию этапа реализации (код
программы).
3

4. Международные стандарты при разработке ПО

• 1. ISO/IEC 12207:1995 – базовый стандарт,
регламентирующий процессы ЖЦПО;
• 2. ISO/IEC 9126–1991 – базовый стандарт по
показателям и метрикам характеристик
качества ПО;
• 3. ISO/IEC 15504–98 – SPICE – стандарт
оценки процессов ЖЦПО.
4

5. Стандарты Российской Федерации

• 1. Соответствующие ISO стандартам
ГОСТ Р ИСО/МЭК – 12207, ГОСТ Р ИСО/МЭК 9126–93.
• 2. Группа стандартов ГОСТ 19.ххх. Из них широко
применяются:
• – ГОСТ 19.701–90 ЕСПД – схемы алгоритмов,
программ, данных, систем; условные обозначения и
правила.
• – ГОСТ 19.102–77 – стадии разработки.
• 3. Группа стандартов ГОСТ 34.ххх. В определенной
степени соответствует ISO/IEC 12207.
5

6. Качество программ

• Качество – объективная характеристика товара (продукта,
услуги), показывающая степень удовлетворенности
потребителя.
• Со своей стороны каждый товар имеет объективные, присущие
ему свойства, или характеристики. Некоторые свойства могут
иметь количественную оценку – показатель.
• Показатель – мера степени, в которой товару присуще
свойство (характеристика).
• С точки зрения потребителя, некоторые свойства более
значимы, другие – менее. Выделив значимые свойства
(характеристики) и их показатели, потребитель формирует
некоторый комплексный показатель качества или метрику
качества.
6

7. Показатели качества программ

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

8. Показатели качества ПО

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

9. Модель ЖЗПО в учебном процессе

10. Постановка задачи

• На этапе постановки задачи осуществляется анализ
требований и в результате формируется корректно
сформулированное техническое задание (ТЗ).
Техническое задание является словесным
описанием и должно быть кратким, точным, четким
и емким. ТЗ содержит:
• 1. Описание сути задачи.
• 2. Описание требуемого интерфейса.
• 3. Пример работающей модели задачи.
Документом являются внешние спецификации
программы.
10

11. Внешние спецификации

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

12. Связь ТЗ и внешних спецификаций

13. Разделы внешней спецификации

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

14. Разделы внешней спецификации

• Внешняя спецификация данных содержит:
описание данных программы как объектов
внешнего мира;
• описание входных данных;
• описание выходных данных;
• внешнюю вычислительную модель –
модель преобразования входных данных в
выходные
14

15. Описание данных

Объект
Свойства объекта
Характеристики
свойства
Связь между
объектами и внутри
объектов
Объекты
внешнего
мира
Свойства объектов,
значимые с точки
зрения решаемой
задачи
Для каждого
свойства
указываются
область
определения и
ограничения
Связь внутри
объекта может быть
аналитической или
логической
Связи между
объектами являются
вычислительными
моделями задачи
15

16. Функциональные спецификации

• функции интерфейса;
• функции ввода исходных данных;
• функции обработки и вычисления
результатов
• функции вывода
16

17. Спецификация интерфейса

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

18. Спецификация внешнего тестирования

• Содержит данные для тестирования
программы (по данным) и данные для
тестирования внешней спецификации (по
функциям и интерфейсу).
18

19. Проектирование

• Разрабатываются модели;
• Проектируются процедуры и
соответствующие алгоритмы;
Документом являются внутренние
спецификации: данные, модели, алгоритмы,
данные для автономного тестирования.
19

20. Кодирование

• Выбор языка и среды программирования.
• Кодирование алгоритмов.
• Автономная отладка и тестирование.
Документом является отлаженный и
протестированный код программы.
20

21. Внедрение

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

22. Способы описания алгоритма

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

23. Блок-схема

• Блок-схема – это графическое изображение
алгоритма в виде плоских геометрических
фигур (блоков), соединенных линиями.
Внутри блока записывается действие,
которое нужно выполнить, или условие,
которое необходимо проверить.
• . Существует государственный стандарт
(ГОСТ 19.791–90 ЕСПД), содержащий
перечень правил построения блок-схем.
23

24. Основные блоки

25. Основные блоки

26. Структурный подход к программированию

• Используются типовые алгоритмические
структуры, имеющие один вход и один
выход:
• Следование;
• Ветвление;
• Цикл
26

Источник: ppt-online.org