Модели разработки web приложений

Модели разработки web приложений

Здесь рассказывается, как создавать Web-приложения в среде групповой разработки. Рекомендуется изолированная модель и поясняется, почему ее следует предпочесть альтернативным подходам.

Существует три основных модели разработки Web-приложений:

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

В рамках этой модели вы разрабатываете программное обеспечение (редактируете, отлаживаете и запускаете его) в полной изоляции на своем компьютере и используете локальный Web-сервер (http://localhost). Доступ к исходным файлам осуществляется через базу данных Microsoft ® Visual SourceSafe ™ (VSS), размещенную на общем сетевом диске. Вы можете как разрешить, так и запретить разработчикам одновременно снимать с контроля (check out) один и тот же файл. Дополнительную информацию см. в разделе Снятие файла с контроля несколькими разработчиками одновременно в главе 6 «Работа с Visual SourceSafe».

Частично изолированная модель

В рамках этой модели для разработки и отладки приложения используется общий Web-сервер (http://remoteserver). Вы регистрируете и снимаете с контроля файлы через базу VSS на общем сетевом диске. Ваша рабочая копия проекта размещается на общем Web-сервере в определенной папке, являющейся корневой папкой Microsoft Internet Information Server (IIS). За каждым разработчиком закрепляется собственная папка проекта на общем Web-сервере.

Примечание При первом получении Web-проекта от VSS, Microsoft Visual Studio ® .NET не позволяет разместить рабочие файлы в папке, уже содержащей другой Web-проект.

Если включена функция VSS, отвечающая за снятие файла с контроля несколькими пользователями одновременно (multiple checkout feature), разработчики могут снимать с учета и редактировать один и тот же файл, но единовременно только один разработчик может отлаживать приложение на Web-сервере. Это связано с тем, что при отладке приложения IIS блокируется. Таким образом, другие Web-запросы к любым другим приложениям не обслуживаются.

Неизолированная модель

В рамках этой модели для разработки и отладки приложения используется общий Web-сервер (http://remoteserver). Однако у вас нет собственных копий рабочих файлов, и все разработчики используют один и тот же виртуальный корневой каталог на сервере, например http://remoteserver/projectname.

При сохранении изменений в файл версия файла в памяти вашего компьютера пересылается на сервер по протоколу Hypertext Transfer Protocol (HTTP). Существующая серверная копия перезаписывается. Когда вы последовательно регистрируете изменения с помощью встроенных сервисов контроля версий Visual Studio .NET, для обновления копии файла в базе данных VSS используется Microsoft FrontPage ® Extensions.

Все три модели показаны на рис. 2.1.

Developer 1 — Разработчик 1
Developer 2 — Разработчик 2
VSS — VSS
Common Web Server — Общий Web-сервер
VS NET — VS .NET
Web application — Web-приложение

Рис. 2.1. Модели Web-разработки

Используйте изолированную модель разработки

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

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

Принятие изолированной модели дает следующие преимущества.

• Вы и ваши коллеги — члены группы разработчиков ведете разработку независимо друг от друга, используя отдельные (локальные) экземпляры Web-приложения.
• Вы можете разрабатывать и отлаживать приложение, не мешая другим разработчикам.
• В данной модели предусмотрена наилучшая поддержка контроля за исходным кодом (по сравнению с неизолированной моделью, использующей FrontPage Extensions).
• Она немного быстрее работает в локальной сети (LAN) (по сравнению с FrontPage Extensions).

Избегайте частично изолированных и неизолированных моделей

Применение частично изолированной и неизолированной моделей в среде командной разработки затруднено. По возможности их следует избегать.

Недостатки частично изолированной и неизолированной моделей

Частично изолированная и неизолированная модели имеют следующие недостатки:

• Очень легко повлиять на работу другого разработчика, не заметив этого. Так, при отладке приложения отладчик блокирует общий Web-сервер и мешает другим разработчикам.
• В неизолированной модели разработчики могут мешать друг другу еще и потому, что для одного Web-приложения существует только одна DLL отделенного кода (code behind DLL).
• Возможности контроля исходного кода в FrontPage Extensions (не интегрируемого с VSS) ограничены. В неизолированной модели все разработчики работают с копией, размещенной на Web-сервере. Функции контроля за исходным кодом, встроенные в FrontPage Extensions, предлагают модель разработки «выигрывает версия, зарегистрированная последней». Допустим, пользователи A и B снимают с учета один и тот же файл почти одновременно, пользователь A вносит изменения и сохраняет их чуть раньше. Когда пользователь B делает то же самое, изменения, внесенные пользователем A, теряются.

Единственная ситуация, где вам, видимо, придется использовать неизолированную или частично изолированную модель, возникает, когда Web-приложение требует специфические ресурсы, доступные только на общем Web-сервере. Вы можете столкнуться с такой ситуацией при разработке приложения, использующего Microsoft .NET Passport.

Если вы вынуждены применять FrontPage Extensions, то можете настроить Visual Studio .NET на использование этого режима для всех новых Web-проектов и изменить режим для текущего Web-проекта.

Чтобы настроить Visual Studio .NET на использование FrontPage Extensions

1. В меню Tools выберите Options.
2. Щелкните папку Projects.
3. В папке Projects щелкните WebSettings.
4. В правой секции окна выберите FrontPage Extensions.
5. Щелкните OK для сохранения изменений.

Чтобы сменить режим доступа для текущего Web-проекта

1. Щелкните правой кнопкой мыши проект в Solution Explorer и выберите Properties.
2. Раскройте папку Common Properties и щелкните Web Settings.
3. Измените параметр Web Access Mode.
4. Щелкните OK для сохранения изменений.

Дополнительные сведения о разработке Web-проектов с контролируемым исходным кодом в Visual Studio .NET см. по ссылке Web Projects and Source Control Integration in Visual Studio .NET.

Источник

Методы разработки веб-приложений и сайтов — каскадные, agile, scrum

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

«Водопад» или каскадная модель (Waterfall Model)

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

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

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

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

V-образная модель (V-Model)

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

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

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

Инкрементная модель (Incremental Model)

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

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

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

Быстрая разработка приложений или «RAD Model»

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

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

Гибкая модель разработки (Agile Model)

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

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

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

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

Источник