Разработка программного обеспечения может быть разной. Перед тем, как создать новый продукт, важно не только продумать саму идею проекта, но и определиться с методом его реализации. В этом помогут методологии. Знать их полезно не только программисту, но и тестировщику, т. к. методологии разработки ПО спрашивают практически на любом собеседовании.
В современных источниках полно данных о том, что это такое, а также как их отличать друг от друга. Однако новичкам бывает трудно разобраться в методах разработки и их особенностях. В данной статье соответствующая тема окажется максимально раскрыта. Основной упор сделан на так называемый Agile.
Жизненный цикл софта
Во время разработки программного обеспечения владелец продукта должен понимать, что у контента есть жизненный цикл. Это – этапы, которые проходит софт от начала создания до конца разработки и релиза. Обычно это: подготовка, проектирование, создание, поддержка. Каждый шаг способен делиться на несколько более мелких.
Наиболее подробно жизненный цикл ПО выглядит так:
- подготовка;
- проектирование;
- обдумывание дизайна;
- кодирование;
- тестирование;
- документирование;
- внедрение;
- поддержка.
Каждый шаг – это отдельная задача, которая помогает решать поставленные проблемы. Для разработки продуктов они крайне важны.
Примеры с жизненным циклом
Каждый этап разработки предусматривает свои особенности. Далее будет приведен пример жизненного цикла онлайн магазина в Сети. Он выглядит следующим образом:
- Подготовка. Человек решает запустить собственный магазин по продажам книг в интернете. Он анализирует потенциальных конкурентов. После – собирает данные о трафике, функциональных возможностях.
- Проектирование. Тот, кто решил выпустить в свет интернет-магазин, собрал команду или выбрал подрядчика для реализации задачи. С ними он проговорил архитектуру и внешний вид (дизайн) продукта.
- Создание. Это – этап заключения договора с разработчиками. Они стали реализовывать дизайн и прописывать кодификацию будущего магазинчика.
- Поддержка. Здесь происходит подписание акта приемки-передачи итогового продукта, а также расчет с разработчиками. Магазин размещен на реальных серверах и открыл свои двери для покупателей. Посетители не только приобретают продукцию, но и сообщают об обнаруженных ошибках/неполадках. Программисты оперативно исправляют жалобы, делая интернет-проект стабильно функционирующим.
Модель разработки – это то, что описывает стадии жизненного цикла продукта. А еще – что происходит на каждом из пройденных шагов.
Методология – это набор методов, которые отвечают за реализацию разработки. Сюда относят правила, принципы, техники создания программного обеспечения, которые делают процесс более грамотным и эффективным.
Какие есть модели разработки
Планирование алгоритма по созданию качественного программного обеспечения – это уже половина успеха итогового продукта. Для того, чтобы у заказчиков и программистов в ходе сотрудничества было меньше проблем, были придуманы разнообразные методы написания ПО. Каждый обладает собственными преимуществами и недостатками, которые должен оценить разработчик для конкретного заказа.
Среди подходов к созданию программных продуктов выделяют следующие варианты:
- code and fix – кодирование и устранение ошибок;
- v-model – подход, реализуемый посредством тестирования;
- incremental model – инкрементная модель;
- waterfall – «водопад», каскадный прием;
- iterative – итеративная;
- spiral – спиральный вариант;
- chaos model – «хаотичная» модель;
- prototype – прототипная.
Грамотный выбор метода написание продукта – это гарант качества результата при хорошо подобранной команде. На практике среди перечисленных подходов выделяют 5 основных: V-образную, каскадную, итерационную, инкрементную и спиральную. Работающий в команде разработчик человек должен хорошо разбираться в этих приемах. Именно они будут рассмотрены далее более подробно.
Водопадный подход
Для создания качественного ПО нужно хорошо разбираться не только в языках программирования, но и в методах коддинга. Первый вариант – это схема «водопад».
Впервые метод появился в 1970-х годах. Базируется на поэтапном выполнении: каждая следующая стадия начинается лишь после того, как заканчивается предыдущий шаг. При грамотной реализации «водопад» послужит наиболее быстрой, качественной и простой моделью.
Выше показана наглядная схема соответствующего приема. Запутаться в нем невозможно. «Водопад» — это четкий план, которого стоит придерживаться во время процесса разработки.
Преимущества
У каждого рассматриваемого варианта есть свои сильные и слабые стороны, начиная с самого начала продумывания итогового продукта. Waterfall – прием, который встречается на практике весьма часто.
Он имеет следующие преимущества:
- можно быстро и легко осуществлять контроль за процессом;
- «водопад» позволяет определять стоимость всего проекта на первых порах;
- после заключения договора development осуществляется «от и до», без остановок и тормозов;
- для проверки работоспособности кода нет необходимости в найме опытных и дорогостоящих тестировщиков.
Проверка полученных результатов при «водопаде» может осуществляться даже новичками путем изучения подробной технической документации.
Недостатки
Waterfall – это лучший по скорости метод по созданию программных продуктов. Но он имеет ряд недостатков:
- тестинг проводится на последних этапах создания ПО;
- комментарии по доработкам и полученному результату удастся дать только в самом конце процесса;
- написание кода осуществляется по технической документации, что несколько задерживает разработку.
Такой прием не лучшим образом подходит для сложных и крупных продуктов. Связано это с тем, что при обнаружении ошибки, ее исправление окажется долгим и дорогостоящим. А если у заказчиков в процессе создания контента появятся пожелания или критика, то разрабам предстоит переписывать почти всю кодификацию.
«Водопад» сгодится для космической и медицинской отраслей, где уже есть база документации. Основная задача для успешной реализации проекта по подобному принципу – это написание подробных требований к разработке. В процессе осуществления тестинга должно быть минимум ошибок или полное их отсутствие.
Через тестирование
Роль выбора метода по созданию ПО становится для программистов основополагающей. Когда решается этот вопрос, нужно оценивать преимущества и недостатки каждого подхода. Есть моделька V-образного типа. Это – следующее популярное направление.
Появилось оно в 1980-х годах. Усовершенствованная каскадная модель. В ней заказчик вместе с командой программистов одновременной составляет требование к системе, после чего описывает процесс тестирования. Требования выдвигаются для каждого этапа работки.
Выше – схема, объясняющая принцип работе соответствующего приема.
Среди преимуществ – это качество разработки. При помощи V-образа появляется возможность свести ошибки архитектуры продукта к минимуму.
Недостатки
Многим нравится разработка через тестирование. Но это – вариант, который сгодится для проектов, где на передовую выходит надежность. Связано это с недостатками метода:
- требуется грамотно подобранная команда тестировщиков;
- нужен немалый бюджет, особенно для крупных проектов;
- дороговизна исправления обнаруженных в ходе тестинга ошибок.
Подойдет для решения ПО, предназначенного для отслеживания поведения пациентов в клиниках, а также при разработке систем безопасности для транспортных средств. Это – только несколько примеров. В них сведение рисков на нет важнее, чем стоимость корректировки обнаруженных багов.
Инкрементная модель
Некоторые программисты создают программные продукты по частям. Здесь на помощь приходить Increment Model. Она – одна из самых старых. Начинается история такого подхода в 1930-х годах.
Чтобы лучше понять принцип работы такого приема, лучше рассмотреть наглядный пример. Нужно создать новую социальную сеть. Тогда по Increment Model разработка будет осуществляться так:
- Заказчик принял решение о создании социальной сети. Он составил подробное ТЗ. Разработчики изучили документацию и предложили дополнительные функции для будущей социалки. Пример – введение страницы с личной информацией, а также чаты. После – провести тестинг на потенциальной целевой аудитории.
- Команда разработчиков создает продукт и демонстрирует его заказчику. Далее – осуществляет запуск на рынок. Если и заказчиков, и посетителей все устраивает – работа над пилотным проектом продолжается. Она будет проводиться по частям.
- Программисты параллельно создают инструментарий для выгрузки фотографий, обмена файлами и прослушивания музыки. Также осуществляется реализация иных важных для социальной сети функций. Инкремент за инкрементом они начнут совершенствовать продукт, позволяя приблизиться к заданному ТЗ.
Предложенная схема наглядно дает понять, как работает инкрементная модель в программировании.
Преимущества
К сильным сторонам процесса относят:
- отсутствие необходимости крупных финансовых вложений на первоначальном этапе;
- быстрый фидбэк от потенциальной целевой аудитории;
- корректировка багов более дешевая, чем в предыдущих вариантах.
Здесь конечным результатом удастся насладиться в кратчайшие сроки. Но для успешного старта придется хорошенько подумать над техническим заданием. Если оно составлено без конкретики, разработчики не смогут воспользоваться инкрементным подходом.
Недостатки
Хотя Increment Model может показаться идеальным вариантом, особенно если успех проекта находится под вопросом, она тоже имеет ряд недочетов:
- возможные конфликты между разработчиками и программистами;
- разрабы будут доделывать мелочи, вместо того, чтобы в первую очередь подумать над основным функционалом.
Если в компании две команды программеров, они могут по-своему смотреть на реализацию всего ПО, а также его интерфейса. Иногда прийти к общему мнению не получается. Из-за этого каждая команда будет переделывать функционал и интерфейс «под себя». А это может сказываться на сроках сдачи результата.
Продолжение статьи читайте здесь.
Хотите освоить современную IT-специальность? Огромный выбор курсов по востребованным IT-направлениям есть в Otus!
