К этапам разработки программы относятся

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

Иерархия процессов

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

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

1. Продуктовая аналитика.
2. Спецификация и вайрфреймы.
3. Оценка и планирование.
4. Дизайн.
5. Программирование.
6. Тестирование.
7. Запуск.

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

ИСТОРИЯ СОЗДАНИЯ И РАЗВИТИЯ ПРОГРАММЫ Intercepter-NG | СОФТ | РАЗРАБОТКА

Продуктовая аналитика

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

1. сегментировать целевую аудиторию (ЦА);
2. определить популярные модели взаимодействия пользователей с аналогичными сервисами;
3. изучить конкурентоспособность продукта;
4. сформулировать уникальное торговое предложение (УТП);
5. построить гипотезы, объясняющие мотивы поведения посетителей;
6. сформировать критерии минимально жизнеспособного продукта (minimum viable product, MVP).

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

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

Срок исполнения этапа зависят от масштаба, предметной области и бизнес-целей проекта. В среднем аналитика занимает около месяца или 100 часов работы.

Спецификация и вайрфреймы

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

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

Хотя детали спецификации могут меняться вместе с новой задачей, «ядро» требований остается постоянным. Его составляющие:

Стадии и этапы разработки программ

1. введение — цели, термины, представление ЦА, масштаб проекта;
2. описание — видение и функциональность программы, детальная классификация пользователей, операционная среда, стандарты, предположения и зависимости;
3. требования к внешним интерфейсам — пользовательскому (UX), программному, оборудования и коммуникаций;
4. нефункциональные требования — производительность, конфиденциальность данных и безопасность системы, критерии качества продукта;
5. прочее — глоссарий, каталог моделей процессов, перечень базовых задач.

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

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

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

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

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

Оценка и планирование

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

1. демонстрация структуры продукта (общий объем работ);
2. расписание участия в проекте профильных специалистов;
3. стоимость работ;
4. сроки реализации;
5. оценка вероятности наступления рисковых ситуаций с перечнем мер по предотвращению и ликвидации последствий.

Срок исполнения: три дня.

Дизайн

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

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

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

Срок исполнения: работы над визуальной частью ПО занимают, в среднем, две недели или 80 часов работы.

Программирование

Задача этапа — написание кода, построение архитектуры, Back-end и Front-end разработка. Для комплексных и сложных проектов используется тактика MVP.

Существует два вида реализации приложения:

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

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

Сроки исполнения: от 160 часов работы (от одного месяца).

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

Задача этапа — тестирование мобильного приложения с целью выявления недостатков и ошибок.

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

Цель проверки продукта на стабильность, совместимость и безопасность достигается привлечением специалиста-тестировщика, который проверяет функциональность UI/UX, выясняет качество и порядок запросов разрешений, устанавливает отказоустойчивость баз данных и т. д.

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

Сроки исполнения: от 40 часов работы или от одной недели.

Запуск приложения

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

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

Выводы

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

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

Источник: www.sostav.ru

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

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

Что такое методологии разработки программного обеспечения?

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

Общие методологии разработки программного обеспечения

Вот 11 наиболее распространенных методологий разработки программного обеспечения:

Программы для Windows, мобильные приложения, игры — ВСЁ БЕСПЛАТНО, в нашем закрытом телеграмм канале — Подписывайтесь:)

1. Проворный

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

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

2. DevOps

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

3. Водопад

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

Шесть этапов методологии водопада:

1. Требования: это этап концептуализации, на котором разработчики определяют ожидания от проекта и функции разрабатываемого продукта.
2. Дизайн системы: на этом этапе разработчики определяют архитектуру программного обеспечения и другие требования к системе.
3. Реализация: Разработчики разрабатывают программное обеспечение отдельными модулями, тестируя каждый на предмет изолированной функциональности.
4. Интеграция и тестирование: разработчики объединяют блоки и проверяют интегрированную систему на наличие недостатков или ошибок.
5. Развертывание: Программное обеспечение становится доступным на рынке или для использования клиентами.
6. Техническое обслуживание: разработчики устраняют или устраняют проблемы, которые становятся известными во время фактического использования.

4. Спираль

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

Четыре этапа спиральной методологии:

1. Планирование: разработчики определяют свои цели на данном этапе разработки.
2. Анализ рисков. Разработчики прогнозируют риски и пытаются разработать для них решения.
3. Инжиниринг: разработчики проектируют и разрабатывают продукт на основе предыдущих этапов.
4. Оценка: разработчики оценивают состояние проекта и строят планы на следующую итерацию.

5. Быстрое применение

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

РАД состоит из четырех этапов:

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

6. Метод разработки динамических систем

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

В жизненном цикле DSDM есть четыре фазы:

1. Технико-экономическое обоснование и бизнес-исследование: разработчики определяют требования и определяют подходящий метод для проекта.
2. Функциональная модель и итерация прототипа: разработчики создают прототипы, демонстрирующие функциональность.
3. Итерация проектирования и сборки: разработчики совершенствуют прототипы, пока не создадут приемлемую функциональную модель.
4. Внедрение: пользователи проходят обучение, и программное обеспечение входит в операционную среду.

7. Прототип

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

В методологии прототипа есть шесть этапов:

1. Сбор и анализ требований: разработчики определяют ожидания пользователей и определяют требования к приложениям.
2. Быстрый дизайн: разработчики создают быстрый дизайн приложения, чтобы дать представление о его возможностях и создать основу для прототипов.
3. Создание прототипа: разработчики создают рабочую модель приложения на основе быстрого дизайна.
4. Оценка пользователей: разработчики представляют прототип клиенту или представителям пользователей, которые оставляют отзывы.
5. Уточнение: разработчики улучшают прототип до тех пор, пока он не удовлетворит ожидания клиента или пользователей.
6. Внедрение и обслуживание: Разработчики тестируют приложение, запускают его и выполняют плановое обслуживание.

8. Экстремальное программирование

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

XP — это итеративная методология, каждая итерация которой состоит из четырех этапов:

1. Планирование: разработчики и клиент обсуждают видение и цели продукта.
2. Проектирование: разработчики определяют код перед его написанием, стремясь к простоте.
3. Кодирование: разработчики пишут код и переделывают его структуру, чтобы добиться простоты, влияя на функциональность.
4. Тестирование: разработчики проверяют код на функциональность. Часто эта фаза происходит одновременно с фазой кодирования.
5. Слушание: разработчики получают обратную связь от клиента и вносят соответствующие изменения.

9. Разработка, ориентированная на функции

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

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

FDD придерживается пяти шагов при разработке наборов функций в короткие сроки. Эти:

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

10. Совместная разработка приложений

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

• Исполнительный спонсор: руководитель, принимающий решения, который может поделиться подробностями о ресурсах.
• Менеджер проекта: отвечает за особенности проекта, такие как координация и планирование.
• Клиент и конечные пользователи: предоставление информации о потребностях и ожиданиях
• Фасилитатор: модерирует сессию, улаживает споры и гарантирует, что участники решают все вопросы.
• Scribe: Записывает детали сеанса.

11. Рациональный унифицированный процесс

Rational Unified Process, или RUP, — это гибкая методология, которая делит разработку на четыре фазы:

1. Начало: Разработчики определяют осуществимость проекта и ресурсы, которые им могут понадобиться для его реализации.
2. Разработка: разработчики прогнозируют стоимость проекта и определяют потенциальное использование программного обеспечения.
3. Конструкция: разработчики проектируют, создают и тестируют программное обеспечение.
4. Переход: Программное обеспечение входит в рабочую среду. На основе любых отзывов разработчики вносят коррективы.

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

• Бизнес-моделирование: описание процесса и ролей
• Анализ и дизайн: объяснение того, как реализовать цели
• Реализация: определение и выполнение задач
• Тестирование: оценка осуществимости или функциональности
• Развертывание: Запуск усилий или продукта

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

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

Понимание потребностей клиента или пользователя

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

Учитывайте характеристики проекта

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

Определите, насколько гибкими вы можете быть

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

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

Методологии разработки программного обеспечения: понятие, принципы, методы и этапы разработки

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

Что это?

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

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

Конкретные продукты реализуются через методологию разработки программного обеспечения. Она будет определять, каким образом специалист станет выполнять свою работу. Сегодня подобных методологий множество — основные мы рассмотрим по ходу материала. Что же влияет на выбор из них одной-единственной? Выделяется размер команды, сложность и специфика определенного проекта, зрелость и стабильность процессов в компании-работодателе, личные предпочтения создателя ПО.

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

Прогнозируемые методологии

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

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

Адаптивные методологии

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

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

Гибкие методологии

Гибкие методологии разработки программного обеспечения — англ. Agile software development. Отсюда второе название: agile-методы.

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

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

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

Итерация здесь — миниатюрный программный проект, включающий в себя все задачи по обеспечению функционального мини-прироста. Как то: планирование, анализирование требований, проектирование, программирование, тестирование разработки, документирование. Конечно, отдельной итерации здесь недостаточно для выпуска конечного продукта. Здесь подразумевается другое.

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

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

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

Agile Manifesto

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

Agile Manifesto был разработан и принят 1-13 февраля 2001 года в лыжном комплексе в горах Юты. Содержит в себя 4 главные идеи и 12 принципов командной работе без единого практического совета.

Представим основные идеи этой современной методологии разработки программного обеспечения:

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

Также в рамках Agile Manifesto были обозначены следующие принципы деятельности разработчиков:

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

Waterfall Model

От манифеста гибкой методологии разработки программного обеспечения переходим к новому типу. Waterfall Model — «водопад» или каскадная модель. Одна из самых старых методологий. Подразумевает последовательное прохождение этапов разработки программного обеспечения, каждый из которых должен закончится до того, как начнется следующий.

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

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

Специалисты советуют использовать методологию «водопад» в следующих случаях:

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

V-Model

Стадии разработки программного обеспечения тут также последовательны. Эту особенность V-Model «унаследовала» от «водопада». Особенно хороша для тех систем, где требуется бесперебойное функционирование. Хороший пример: создание прикладного ПО для клиник, используемого для непрерывного наблюдения за пациентами.

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

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

Когда необходимо использовать данную методологию для разработок:

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

Incremental Model

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

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

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

Опишем случаи, когда использование Incremental Model будет обоснованным:

• Четко определенные и понятные требования к конечному продукту.
• Допускается доработка некоторых деталей с течением времени.
• Есть несколько рисковых целей.
• Необходим ранний вывод ПО на рынок.

RAD Model

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

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

Процесс разработки программного обеспечения здесь включает в себя несколько этапов:

1. Бизнес-моделирование. Это определение информационных потоков между спектром подразделений.
2. Моделирование сведений. Данные, собранные на первом этапе, используются для определения сущностей, необходимых для циркуляции информации.
3. Моделирование процесса. Во время этой фазы информационные потоки связывают определенные объекты для достижения цели разработки.
4. Сборка приложения. Тут используются средства автосборки для преобразования моделей проектирования в код.
5. Тестирование. Проверка новых компонентов и интерфейсов.

Использовать такой метод разработки программного обеспечения следует только в том случае, когда в команде есть высококвалифицированные и «узкие» специалисты. Бюджет проекта определенно большой: нужно оплатить работу профессионалов, стоимость готового инструментария автоматизированной сборки.

Модель выбирают при уверенном знании целевого бизнеса в тех случаях, когда нужно представить готовый продукт в короткие сроки — за 2-3 месяца.

Iterative Model

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

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

Чем-то создание ПО здесь напоминает сотворение картины: сначала делается набросок, затем он заполняется цветами, добавляются детали, насыщенность, переходы оттенков, последние штрихи — и процесс завершен.

Чем-то напоминает инкрементную модель? Давайте рассмотрим разницу. По инкрементной методологии продукт составляется из частей, а функционал ПО складывается, что называется, по кусочкам. Но при этом каждая часть — уже целостный элемент. А «кусочки» в итерационной модели не обладают самостоятельностью.

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

Следовательно, проект еще не завершен.

Применение итеративной модели оправдано в следующих случаях:

• Требования к конечной версии разработки понятны и четко определены.
• Проект очень масштабный.
• Основная задача заранее определена. Но ее детали допустимо совершенствовать, изменять в процессе работы.

Spiral Model

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

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

• Планирование.
• Анализирование рисков.
• Конструирование.
• Оценка итогов. Если она положительная, то разработчик переходит к новому «витку» проекта.

Спиральную модель не стоит использовать для маленьких бюджетных проектов. Напротив, она более подходит для масштабных и дорогих. Отличный пример применения методологии — для разработки системы банковского документооборота. Здесь большое внимание уделяется не столько самому программированию, сколько анализу каждого уже произведенного «витка».

LD

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

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

XP

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

• «Игра в планирование». В начале работ представлен лишь приблизительный план. С каждым витком разработки его четкость увеличивается.
• Высокая частота релизов. Это значит, что новая версия будет иметь лишь небольшие отличия от предыдущей, но на ее выпуск затрачивается самый минимум времени.
• Контакт с клиентом. Для следующих данной методологии важно быстро удовлетворять все требования заказчика — оперативно реагировать на все его замечания и пожелания.
• Рефакторинг. Качество кода улучшается без уменьшения его функциональности.
• Стандартное выполнение кода. На лицо или следование общим правилам, или отсутствие разногласий в процессе разработки.
• Коллективная ответственность. Да, каждый из членов команды занят определенным участком работ. Но за общий результат ответственен уже весь коллектив.

FDD

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

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

Ценность методологии и в том, что она четко регламентирует продолжительность процессов. При этом на организационные вопросы в каждом цикле не должно затрачиваться более 25 % времени. Остальные 75 % — сугубо на разработку, сборку, тестирование функционала.

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

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