Что не относится к программному обеспечению при моделировании

Обновлено: 30.06.2024

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СИСТЕМЫ МОДЕЛИРОВАНИЯ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Текст работы размещён без изображений и формул.
Полная версия работы доступна во вкладке "Файлы работы" в формате PDF

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

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

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

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

Смоделировать будущее программное обеспечение. Этот шаг может быть осуществлён при помощи CASE средств, таких как MS Project, Power Builder, Rational Rose. На этом этапе создатель системы разрабатывает проект программного средства. Здесь он должен предусмотреть все заданные требования, описание системы, надёжность и безопасность системы, эффективность и удобство использования. В проектировании должны применяться только современные методы разработки

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

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

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

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

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

Рассмотрим несколько моделей разработки систем:

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

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

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

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

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

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

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

Моделирование может применяться во всех перечисленных моделях разработки.

Моделирование может производиться и на этапе постановки задачи, как заказчиком, так и разработчиком. Здесь спектр задач моделирования весьма велик. Например, заказчик предъявил особые требования к дизайну сайта и сделал макеты страниц в системе Axure RP Pro. Если есть готовая модель web-страниц, то нет необходимости перечислять требования к дизайну страниц в техническом задании, достаточно просто сослаться на модель.

На этапе анализа требований моделирование – хороший способ обезопасить себя как заказчика, ведь некоторые детали можно уточнить у заказчика. Примером может служить случай, когда дизайн сайта описан в словесной форме и, чтобы уточнить, что именно имел в виду заказчик, можно воспользоваться системой Axure RP Pro 7.0. Также необходимо поступать и с графическим интерфейсом программ, ведь графическая часть плохо описывается словесно. Если предметом разработки является компьютерная игра, то, возможно необходимы 3D модели элементов игры.

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

UML (Unified Modeling Language) — унифицированный язык моделирования, активно применяется при объектно-ориентированном анализе. Цель UML наглядное проектирование архитектуры программного продукта. В стандарт UML входят следующие виды диаграмм:

- диаграмма вариантов использования;

- диаграмма компонентов и другие.

Рисунок 2. Пример диаграммы вариантов использования.

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

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

В процессе тестирования и внедрения также могут использоваться системы моделирования.

Одна из таких систем - Rational Method Composer. Этот продукт является инструментом для создания, изменения и развёртывания процессов разработки. RMS включает в себя базу знаний, являющуюся основой для моделирования процессов. RMC разрабатывался как система управления содержанием (content management system), предоставляющая единую структуру управления и отображения всей базы знаний процессов организации. Все содержание баз знаний процессов может быть опубликовано в виде html-файлов и выложено на веб-сервера для распределенного использования.

Другим известным средством моделирования является BOUML. Оно предназначено для автоматизации построения программного обеспечения, а также для генерации кодов на различных языках и выпуска проектной документации. Принцип его работы заключается в построении диаграмм и далее по ним определять и генерировать код на C + +, Java, PHP, Python и IDL. Эти диаграммы определяют логическую и физическую структуру модели.

Ещё одно средство моделирования Vantage Team Builder (Westmount I-CASE). Этому средству свойственно проектирование диаграмм потоков данных, структур данных , проектирование диаграмм архитектуры системы – SAD, генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур, программирование на языке C со встроенным SQL, управление версиями и конфигурацией проекта, многопользовательский доступ к репозиторию проекта, генерация проектной документации по стандартным и индивидуальным шаблонам.

Среди систем моделирования также числится Designer/2000 компании Oracle. Данный продукт компании Oracle, возможно, наиболее полно поддерживает все этапы создания приложений обработки данных. Однако, следует оговориться, что, в отличие от других средств, он поддерживает практически одну целевую СУБД - Oracle Server (имеется еще возможность генерации скриптов на ANSI SQL). То же самое касается и средств создания пользовательсокго интерфейса. Хотя возможна генерация прототипов программ для языков Visual Basic, C, Java, полностью все возможности Designer/2000 реализуются только при использовании его вместе со средством разработки Oracle Developer/2000.

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

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

Список литературы:

Б. Я. Советов, С. А. Яковлев Моделирование систем: учебник для вузов, 3-е издание перераб. и доп. – М.: Высш. шк., 2001. – 343 стр.:ил.

А. О. Шульгин Особенности жизненного цикла автоматизированной информационной системы ВУЗа.

Жизненный цикл программного обеспечения (материал из википедии)

Екатерина Лаврищева, Владимир Петрухин, Методы и средства инженерии программного обеспечения

6. Моделирование процессов разработки ПО и создание сайтов процессов с помощью Rational Method Composer

Понятие

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

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

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

Оборудование

Какие бывают типы программного обеспечения: характеристика программ

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

Однако ничего не активизируется просто так. Все действует под влиянием операционной системы. Кажется, что ОС совершенно не нужна — можно ведь запускать все напрямую. Иногда этот метод тоже применяется. Так работают станки ЧПУ, крупные автоматы производств, ЭВМ, другие серьезные механизмы, когда нужно постоянно повторять один и тот же алгоритм.

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

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

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

Какие основные виды ПО бывают по назначению

Программное обеспечение, установленное на ПК, делится на 3 разновидности:

прикладное;
системное;
инструментальное.

Системное

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

Таким ПО считается:

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

Прикладное

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

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

Инструментальное

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

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

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

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

Эта статья — начало большого цикла статей о разработке ПО, который включит в себя:

Общая информация о разработке ПО

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

Э. Деминг — американский учёный, статистик и консультант по менеджменту. Больше всего известен благодаря усовершенствованному циклу Шухарта, после этого названному циклом Деминга;
Дж. Джуран — американский специалист в области качества, академик Международной академии качества (МАК). Автор множества книг по менеджменту и теории качества. Дж. Джуран первым обосновал переход от контроля качества к управлению качеством;
Ф. Кросби — бизнесмен и автор нескольких книг по теории качества, который внес вклад в теорию менеджмента и практики менеджмента качества. В 1979 году Кросби основал консалтинговую компанию по управлению финансами Philip Crosby Associates, Inc.

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

К ключевым процессам разработки ПО относятся:

Анализ — часть процесса разработки программного обеспечения, включающая в себя сбор требований к программному обеспечению (ПО), их систематизацию, выявление взаимосвязей и документирование;
Проектирование — процесс создания проекта программного обеспечения (ПО);
Программирование — процесс создания компьютерных программ;
Документирование — печатные руководства пользователя, диалоговая (оперативная) документация и справочный текст, описывающие, как пользоваться программным продуктом;
Тестирование —- процесс исследования, испытания программного продукта, цель которого — проверка соответствия между реальным поведением программы и её ожидаемым поведением на конечном наборе тестов, выбранных определенным образом.

К основным типам рисков разработки ПО относятся:

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

Итеративный метод

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

План;
Реализация;
Тестирование;
Анализ.

Преимущества итеративного подхода:

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

Недостатки итеративного подхода:

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

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

анализ;
проектирование;
реализацию;
тестирование;
интеграцию;
поддержку.

Первым описание модели считают статью, опубликованную У. У. Ройсом в 1970 году.

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

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

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

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

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

Подробное документирование всех этапов;
возможность определить четкие сроки и бюджет;
прозрачность разработки для всех участников.

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

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

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

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

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

Преимущества спиральной модели:

подробный анализ рисков;
подробная документация процесса разработки ПО;
возможность вносить изменения на каждом этапе разработки;
быстрое создание MVP(Минимально готовый продукт).

Недостатки спиральной модели:

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

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

V-Model

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

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

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

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

Недостатки V-модели похожи на недостатки каскадной модели, к ним можно отнести:

отсутствие гибкости;
недостаточный анализ рисков;
невозможность внести изменение на текущем этапе и продолжить дальше разработку.

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

Резюме

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

Для более подробного изучения моделей можно изучить данную литературу:

Richard W. Selby. Software Engineering: Barry W. Boehm's Lifetime Contributions to Software Development, Management, and Research.
Эрик Брауде. Технология разработки программного обеспечения
Мартин Фаулер.Рефакторинг.
Стив Макконнелл. Совершенный код

Для авторов

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

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