какая модель подходит для неограниченно больших систем

Методологии разработки ПО

Водопад или Каскадная модель

Каскадная модель ( waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки. Каскадная модель подходит для больших проектов с большими сроками, большими штатами, большим функционалом: сложные системы в банковской сфере, большие интернет-магазины, проекты с большим числом пользователей и так далее. ТЗ для таких проектов может занимать тысячи страниц, но для разработчиков такой процесс фактически идеален: все описано, всё завизировано и утверждено, сделано максимально всё, чтобы понять как должна работать система.

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

Минус системы: при необходимости изменений возникает большой объём «бюрократических» работ: согласование и утверждение со всеми заинтересованными лицами.

Итеративный процесс

Итеративная разработка — это выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка ( plan-do-check-act cycle).

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

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

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

Затраты на проект распределяются равномерно, а не в конце проекта. Это важно для Заказчика.

Итеративный процесс имеет несколько видов: Agile, XP, Kanban, RUP и другие.

Agile/Scrum

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

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

Работа организуется по следующему принципу:

Менеджер проектов — Product owner

Ключевой человек в технологии Scrum. Он закрывает команду от Клиента. Если Клиент — корпоративный, то с его стороны участвует несколько (до нескольких десятков) сотрудников. Доступ этих сотрудников к разработке напрямую должен быть исключён. Это делает Product owner.

Product owner выстраивает взаимодействие с Клиентом. Если Product owner «прогнётся» под наплывом требований со стороны Заказчика, Scrum становится бесполезен. Задача очень трудная, для человека с крепкой психикой.

Product owner говорит со всеми менеджерами, директорами, аналитиками и так далее и вырабатывает понимание того как должна работать создаваемая система. И он отвечает за продукт. Он знает ответы на все вопросы по продукту, что позволяет разработчикам чувствовать стабильность при работе, что завтра не поменяются требования и не придётся всё переделывать.

Для команды Product owner формирует ранжированный список «хотелок» (Product backlog) из которого и формируется список задач на конкретный цикл (Sprint backlog).

Список задач — Product backlog

Список потребностей, сценариев использования описываются в таблице Product backlog. Список линейный, приоритезированный, предварительно оценённый на трудозатраты по простейшей схеме: простой, средний, сложный.

Product backlog позволяет легко проверять работу менеджеров: скорость работы, возможные проблемы. В том числе и в плане работы с клиентами: если Клиент не может высказать внятно свои потребности (составить backlog), то, возможно, есть смысл сменить методику работы с ним.

Планирование цикла — Sprint planing meeting

Срок собрания — не более одного дня. Команда с подачи Product owner’а отбирает задачи из Product backlog, оценивает их во временных единицах (как правило, это человеко-часы) на выполнение. Оценка проводится в «игровой форме» (Planning poKer), при большом разногласии в оценке может проводиться в несколько туров с периодами обсуждения.

Задачи конкретного цикла — Sprint backlog

Отобранный из Product backlog список задач на данную итерацию (Sprint). Задачи отбираются с учётом выделенного времени на Sprint и выставленных каждой задаче временных оценок.

Цикл разработчки — Sprint

Небольшой по срокам (1-4 недели) цикл разработки. Разработка ведётся на основе Sprint backlog. Учёт работы можно вести по аналогии с доской Kanban:

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

Примечание: Учёт скорости нужно вести систематически, от Sprint’а к Sprint’у. Это позволяет прогнозировать сроки релизов и оптимизировать процесс разработки.

Команда — Team

В Scrum’е нет личности. Работа — коллективная, ответственность коллективная. Это порождает как преимущества, так и проблемы. Есть сотрудники — таланты, которые просто не могут работать в команде, но они нужны. Есть просто недобросовестные товарищи. И со всеми нужно работать.

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

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

Считается, что если Sprint провален, то провалила вся команда. Но в реальности провалы бывают из-за конкретного человека. Как быть в такой ситуации?

Но если команда — настоящая, слаженная команда, то этот принцип работает просто великолепно.

Управляющий процессом — Scrum master

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

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

Ежедневное планирование — Daily standup meeting

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

Условие готовности задачи — Definition of Done

Очень важно правильно определиться с этими условиями. Они должны быть чётко оговорены: проверено тестировщиками, проверено безопасниками, проверено сисадминами, проверено Product owner’ом и так далее.

Демонстрация результатов — Sprint review

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

Внутрикомандная оценка этапа — Sprint retrospective

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

Плюсы и минусы технологии

Плюсы:

Минусы:

Канбан

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

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

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

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

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

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

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

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

Continuous Integration

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

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

Требования к производству по практике Continuous Integration

Читайте также

Планирование trello pivotaltracker Отчётность времени weworked timecamp toggl & teamweek Прототипирование Wireframe.cc RealtimeBoard MockFlow MockingBird Balsamiq Divshot Cacoo Placehold.it Color Scheme Designer…

Как регламентировать перекуры в течение рабочего дня? Можно ли разрешать опаздывать к началу рабочего дня? Можно ли чатится во время…

Вам нравится, когда у маркетинга и продаж развязаны руки? Когда они жгут по полной и продажи прут? Когда целевая аудитория…

Источник

Модели разработки ПО

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

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

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

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

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

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

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

Каскадная модель (waterfall)

Рис. 1.2. Каскадная (водопадная) модель

Особенности каскадной модели:

— высокий уровень формализации процессов;
— большое количество документации;
— жесткая последовательность этапов жизненного цикла без возможности возврата на предыдущий этап.
Минусы:
• Waterfall-проект должен постоянно иметь актуальную документацию. Обязательная актуализация проектной документации. Избыточная документация.
• Очень не гибкая методология.
• Может создать ошибочное впечатление о работе над проектом (например, фраза «45% выполнено» не несёт за собой никакой полезной информации, а является всего лишь инструментов для менеджера проекта).
• У заказчика нет возможности ознакомиться с системой заранее и даже с «Пилотом» системы.
• У пользователя нет возможности привыкать к продукту постепенно.
• Все требования должны быть известны в начале жизненного цикла проекта.
• Возникает необходимость в жёстком управлении и регулярном контроле, иначе проект быстро выбьется из графиков.
• Отсутствует возможность учесть переделку, весь проект делается за один раз.
Плюсы:
• Высокая прозрачность разработки и фаз проекта.
• Чёткая последовательность.
• Стабильность требований.
• Строгий контроль менеджмента проекта.
• Облегчает работу по составлению плана проекта и сбора команды проекта.
• Хорошо определяет процедуру по контролю качества.

«Водоворот» или каскадная модель с промежуточным контролем

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

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

Итеративная модель

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

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

Спиральная модель жизненного цикла программного обеспечения

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

Преимущества модели:

V модель — разработка через тестирование

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

V-модель обеспечивает поддержку в планировании и реализации проекта. В ходе проекта ставятся следующие задачи:
• Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения и риски в проекте на ранних стадиях и улучшает качество управления проектов, уменьшая риски.
• Повышение и гарантии качества: V-Model —стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость.
• Уменьшение общей стоимости проекта: ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты.
• Повышение качества коммуникации между участниками проекта: универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком.

Модель на основе разработки прототипа

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

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

Классификация прототипов:

Вкратце можно выразить суть моделей разработки ПО таблицей 1.3.

Таблица 1.3.— Сравнение моделей разработки ПО

Источник

🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект

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

Основные методологии разработки ПО

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

Каскадная модель (waterfall)

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

Плюсы и минусы подхода

Каким проектам подходит

Каскадная модель – хороший вариант, если выполняются эти условия:

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

V-образная модель SDLC

V-образная модель – это своего рода другая версия каскада, но в её основе лежит контроль качества каждой фазы. Например, когда группа разработчиков собирает требования к проекту, QA-специалисты пишут приемочные тесты на основе этих сценариев. Точно так же на этапе проектирования системы создаются сценарии тестирования и так далее. После написания кода команда QA проверяет продукт на соответствие заранее написанным тестам (правая часть буквы «V»).

Каким проектам подходит

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

Модель эволюционного прототипирования

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

Каким проектам подходит

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

Итеративная и инкрементальная модель

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

Каким проектам подходит

Модель будет эффективна в следующих случаях:

Спиральная модель

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

Затем, на основе отзывов пользователей и заинтересованных сторон, планируется следующая итерация.

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

Каким проектам подходит

Спиральная модель подходит для:

Microsoft, IBM и Tata Consultancy используют спиральную модель.

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

Вопреки распространённому мнению Agile не является ни структурой, ни методологией. Это философия с набором принципов, ориентированных на ускорение процесса разработки программного обеспечения, обеспечение 100% удовлетворённости клиентов и предоставление высококачественных решений в быстро меняющейся среде. Фактически, существует 12 принципов гибкой разработки, которые сводятся к следующим ценностям:

Scrum

Скрам-проекты разбиты на спринты. Спринт – это небольшой объём работы, который необходимо выполнить в течение определённого периода времени. Обычно заказчику доставляется часть проекта, которая была завершена во время спринта (инкремент продукта, от англ. increment). Скрам подразумевает активное общение и сотрудничество между всеми участниками проекта. Наряду с ежедневными 15-минутными встречами разработчиков, есть также:

Сердце процессов Scrum – это backlog, своего рода список задач, которые необходимо сделать для завершения проекта. По мере того, как проект продвигается, и команда узнаёт о нём больше, они редактируют бэклог продукта, добавляя, удаляя и переупорядочивая его элементы. Тем не менее, нельзя сделать что-то, если этого нет в очереди продукта.

Но на самом ли деле всё так гладко и красиво в Agile? Посмотрим на его основные варианты использования, а также на плюсы и минусы.

Примеры использования

Большинство современных проектов требуют определённого уровня «маневренности», особенно когда:

Резюме

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

Вот несколько советов как подходить к разработке на примере реального проекта EPAM Anywhere :

Источник