Жизненный цикл ПО. Каскадная модель (Waterfall)

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

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

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

Давайте поочередно рассмотрим все этапы жизненного цикла:

1. Анализ требований

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

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

Видение проекта

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

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

Сбор требований

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

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

2. Проектирование программного обеспечения

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

Масштабы и границы проекта

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

https://invisionapp.com/
https://webflow.com/
https://moqups.com/

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

Спецификация требований программного обеспечения

Спецификация требований программного обеспечения (SRS) описывает требования, которым должно отвечать создаваемое программное обеспечение. Она должна быть логичной, последовательной, доступной и полной. Требования могут выражаться в разных формах, например, в виде традиционных утверждений долженствования (н-р, “Система Staff Manager должна поддерживать следующие браузеры: Google Chrome, Apple Safari, Mozilla Firefox, Opera, IE 8+”) или в виде пользовательских историй (н-р, “поскольку я являюсь менеджером, мне необходим доступ к персональной информации всех сотрудников”).
Существует большое количество шаблонов спецификаций. Выбор определенного шаблона зависит от специфики проекта. В большинстве случаев, спецификация включает в себя описание продукта, классы пользователей, функциональные и нефункциональные требования к разрабатываемому программному обеспечению. Иногда в шаблон также входит прототип. Главное — сделать спецификацию понятной, лаконичной и полезной для разработчиков.

Для создания прототипа вам необходимо выяснить следующее:

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

Мокапы (или прототипы) передаются UI/UX-дизайнерам, которые превращают их в красочные шаблоны.

3. Разработка программного обеспечения

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

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

4. Тестирование программного обеспечения

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

5. Техническая поддержка программного обеспечения

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

Заключение

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

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

Данная статья была подготовлена под руководством опытных бизнес-аналитиков компании ИксБи Софтваре.

бизнес-анализ, веб-разработка, Все статьи, Новости компании, разработка ПО

Поделиться в Facebook (0) Поделиться (0) Tweet Поделиться (0) Поделиться (0)

Пред. статьяСлед. статья

The following two tabs change content below.

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

Маркетолог ИксБи Софтваре с большим опытом в области интернет-маркетинга. Увлекается юзабилити и стремится создавать полезный контент, отвечающий интересам ИТ-аудитории.

Модели жизненного цикла программного обеспечения / Хабр

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

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

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

Эти модели можно разделить на 3 основных группы:

1. Инженерный подход
2. С учетом специфики задачи
3. Современные технологии быстрой разработки

Теперь рассмотрим непосредственно существующие модели (подклассы) и оценим их преимущества и недостатки.

Модель кодирования и устранения ошибок

Совершенно простая модель, характерная для студентов ВУЗов. Именно по этой модели большинство студентов разрабатывают, ну скажем лабораторные работы.

Данная модель имеет следующий алгоритм:

1. Постановка задачи
2. Выполнение
3. Проверка результата
4. При необходимости переход к первому пункту

Модель также ужасно устаревшая. Характерна для 1960-1970 гг., по-этому преимуществ перед следующими моделями в нашем обзоре практически не имеет, а недостатки на лицо. Относится к первой группе моделей.

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

Алгоритм данного метода, который я привожу на схеме, имеет ряд преимуществ перед алгоритмом предыдущей модели, но также имеет и ряд весомых недостатков.

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

• Последовательное выполнение этапов проекта в строгом фиксированном порядке
• Позволяет оценивать качество продукта на каждом этапе

Недостатки:

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

Относится к первой группе моделей.

Каскадная модель с промежуточным контролем (водоворот)

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

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

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

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

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

1. Прояснить не ясные требования (прототип UI)
2. Выбрать одно из ряда концептуальных решений (реализация сцинариев)
3. Проанализировать осуществимость проекта

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

1. Горизонтальные и вертикальные
2. Одноразовые и эволюционные
3. бумажные и раскадровки

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

Модель принадлежит второй группе.

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

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

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

• Быстрое получение результата
• Повышение конкурентоспособности
• Изменяющиеся требования — не проблема

Недостатки:

• Отсутствие регламентации стадий

Третьей группе принадлежат такие модели какэкстремальное программирование (XP), SCRUM, инкриментальная модель (RUP), но о них я бы хотел рассказать в отдельном топике.

Большое спасибо за внимание!

Методы управления ИТ-проектами – традиционные, называемые каскадными

3 года

Метки:Водопад управления

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

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

При выборе методики следует учитывать следующие факторы:

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

Традиция или современность?

По современным тенденциям методологии делятся на традиционные (каскадные) и современные (agile). Многие проекты, связанные с разработкой программного обеспечения, ценят гибкий подход, т. е. те, которые можно адаптировать к меняющимся обстоятельствам, не имеют жестких допущений, времени и бюджета. С другой стороны, традиционное управление проектами хорошо работает в условиях высокой предсказуемости, стабильности компании и осведомленности клиентов о собственных ожиданиях. И хотя баланс интересов в настоящее время склоняется в пользу первого метода, оба должны быть известны. Вначале будут обсуждаться традиционные методы. Это Waterfall, Prince2 или PMBOK.

WATERFALL

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

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

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

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

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

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

Недостатки:

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

Другие методологии, используемые компаниями и учреждениями для крупных проектов, включают PRINCE2, который подходит для проектов во многих различных отраслях, а не только в ИТ, и PMBOK, набор передовых практик управления в ИТ-проектах.

PMBOK/PMI

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

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

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

Сравнение PMBOK с PRINCE2 можно рассматривать как инструмент, дополняющий друг друга.

ПРИНЦ2

Так же, как Waterfall, PRINCE2 (проекты в контролируемых средах)  – это методология каскадного управления. Он основан на контролируемом управлении проектами, которое не оставляет ничего на волю случая. Как точная методология, PRINCE2 является отличным инструментом для запуска крупных и предсказуемых проектов.

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

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

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

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

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

%PDF-1.4
%
1 0 объект
>
эндообъект
11 0 объект
/Заголовок
/Предмет
/Автор
/Режиссер
/Ключевые слова
/CreationDate (D:20230329110110-00’00’)
/CrossMarkDomains#5B1#5D (elsevier. com)
/CrossMarkDomains#5B2#5D (sciencedirect.com)
/CrossmarkDomainExclusive (истина)
/CrossmarkMajorVersionDate (23 апреля 2010 г.)
/ElsevierWebPDFSpecifications (7.0)
/ModDate (D:20220119114113Z)
/doi (10.1016/j.scitotenv.2021.152574)
/роботы (без индекса)
>>
эндообъект
2 0 объект
>
эндообъект
3 0 объект
>
эндообъект
4 0 объект
>
эндообъект
5 0 объект
>
эндообъект
6 0 объект
>
эндообъект
7 0 объект
>
эндообъект
8 0 объект
>
транслировать
приложение/pdfdoi:10.1016/j.scitotenv.2021.152574

Science of the Total Environment, 812 (2022) 152574.

This entry was posted in Популярное