«

»

Янв 28

Каскадная модель. V-модель. А есть ли разница?



Водопад… Каскадная модель разработки ПО и модель тестирования.

V-модель…

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

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

С ходу можно ответить о том, что их различает, о том, что их объединяет?

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

Представьте себе каучуковый шарик «попрыгунчик». Мячик, который от малейшего толчка начинает двигаться. Отскакивает от стен, пола, потолка, ног и рук. Отскакивает от всего того, что попадается ему на пути.

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

Водопад – падение воды в реке с уступа.

Здесь мы работаем как ученые, которые дотошно фиксируют всю информацию.

Бросив наше ПО  в воды водопада, мы отправляем его в одну сторону. Вода не стоит на месте. Нет движения воды – нет водопада. Нет прогресса.

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

Мяч проходит одну веху, скачет ко второй, на горизонте маячит третья – и так, до самой финальной вехи, до падения с высоты 807 метров (высота свободного падения воды в водопаде Salto Ángel). Это падение и есть финальная стадия, последняя веха процесса каскадной разработки: Эксплуатация и сопровождение.

Все, после этого – нет легкого и приемлемого пути назад. Но наш мир подвержен изменениям, подвержен желанию что-то изменить. Например, поставить подсветку и посмотреть, как в ней будет «играть» наш проект, набрав соответствующую скорость.

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

Сбегав 2-3 раза на высоту под один километр, затаскивая мячик на гору, и сбрасывая по новой – начинаешь думать о том, что «видимо что-то случилось», думаешь о том, что надо как-то оптимизировать подходы, для достижения того же результата. Пытаться как-то автоматизировать описанный путь поможет минимизировать только усталость и время, но нерациональность данного подхода останется. Чем выше водопад (длительнее каждый этап каскадной модели) – тем очевиднее нерациональный расход средств.

 

 

Писатели фантасты давно придумали телепортирование. Это выход. Был бы, не будь это фантастикой. 😉

Сомнительный драйв в ситуации, признаюсь честно, но можно улучшить ситуацию!

Давайте посмотрим на V-модель.

Всё наше действие похоже на игру Сквош.

Корт для Squash

Сбросив мячик с одной части V  модели (‘\’), мы в начале заставляем его также скакать по вехам, но…

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

Корректировку мы проводим ракеткой – частью ‘/’  модели. Двигаемся вместе с мячом, смотрим на его траекторию и готовимся его встретить, отбить и погнать дальше по модели. Нам нет необходимости фиксировать все подробно. Мы живем игрой. Главное для нас не излишняя фиксация результатов удара, а победное очко – эксплуатация и сопровождение.

 

Да, по сути, V-модель является разновидностью модели водопада для ученых-практиков. Основной фокус модели водопада – это документация и проектные артефакты, в итоге получается весомая научная статья.

Основной фокус V-модели это правильность и корректность.  В итоге получается то, что больше соответствует потребности большинства читателей.

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

«История — сокровищница наших деяний, свидетельница прошлого, пример и поучение для настоящего, предостережение для будущего». ©Сервантес

Поделиться в соц. сетях

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Яндекс

3 комментария

  1. novak che

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

    P.S. Кстати, я считаю, что совершенно напрасно на английской википедии объединили две статьи про V-модель.

    1. Сергей Атрощенков

      Почему Вы считаете, что объединение статей на Wiki сделано напрасно?

      Я полагаю, что у любой модели в области Software Development:
      Объект моделирования: процесс разработки
      Цель моделирования: сдать проект в срок, с правильной реализацией того что надо, и в рамках заранее определенного бюджета.
      Да, без конкретной задачи это выглядит как шарики в вакууме 🙂

      1. novak che

        Потому как в рамках системной инженерии рассматривается более общий случай V-модели как модели жизненного цикла продукта — а там всё сложили в одно. Можно, конечно, рассматривать и модель разработки (откуда сам подход V-модели, насколько я понял, и пришёл), но тогда нужно и цели формулировать исходя из объекта моделирования. И если у какого-то проекта есть цель уложиться в срок, то у моделирования может быть цель показать, выделить отдельные процессы, оптимизировать их, учитывая опыт схожих моделей, рассмотреть воздействие каких-либо изменений и т.д.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Вы можете использовать эти теги HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>