После разработки бизнес-модели предприятия и определения того, какие процедуры требуют изменения или улучшения, необходимо построить техническую модель сети. Техническая модель описывает в достаточно общих терминах, какое компьютерное оборудование нужно использовать, чтобы достичь целей, определенных в бизнес-модели. Чтобы построить техническую модель, нужно провести инвентаризацию существующего оборудования, определить системные требования, оценить сегодняшнее и завтрашнее состояния техники.
Инвентаризация проводится для того, чтобы точно знать, чем располагаете предприятие и что нужно приобрести. Для такой большой системы, как корпоративная сеть, очень важно, чтобы каждый элемент, будь то кабель или плата памяти, был промаркирован и учтен.
После инвентаризации существующей вычислительной системы необходимо определить требования к новой системе. Для определения технических параметров сети рассматриваются системные требования не с технической точки зрения, а с позиций руководителей, менеджеров и конечных пользователей.
Создание бизнес-модели
Для выяснения системных требований необходимо ответить на следующие вопросы:
- Что нужно соединять? С каким количеством людей и в пределах какой территории требуется общаться сотрудникам. Объем и распределение трафика поможет определить требуемую мощность компьютеров, а также типы и скорости коммуникационного оборудования и сервисов.
- Что из существующего аппаратного и программного обеспечения будет использоваться в новой системе? Какие системы нужно оставить в разрабатываемой корпоративной сети? Нужно ли эти системы соединять в сеть? Будут ли существующие системы нормально работать в новой сети? Существуют ли какие-либо стандарты предприятия, существуют ли преобладающие приложения? Какое оборудование и приложения нужно добавить, чтобы достигнуть поставленных производственных целей?
- Какие объемы информации будут передаваться по сети? Объем передаваемой информации определяет требуемую пропускную способность сети. Это определяется подсчетом количества пользователей сети, среднего количества выполняемых транзакций в день каждым из пользователей и среднего объема транзакции. Такой подсчет поможет определить технологию доступа к среде передачи данных (Ethernet, FDDI и т.д.) и требования к глобальным сервисам.
- Какое время реакции сети является приемлемым? Будут ли пользователи ждать одну секунду, полсекунды или две секунды? Такие измерения помогут определить требования к скорости оборудования, приложений и коммуникационных связей.
- В течение какого времени сеть существенно необходима для работы предприятия? Нужна ли сеть 24 часа в день и 7 дней в неделю или же только в течение 8 часов в день и 5 дней в неделю? Нужно ли увеличить сегодняшние параметры использования сети?
- Какие требования предъявляются к среднему времени устранения неисправностей? Как отражаются операции по обслуживанию и ремонту сети на эффективности ведения дел предприятием? Какие убытки понесет предприятие, если сеть будет неисправна в течение одного часа? Каков будет ущерб от простоя сети в течение двух часов?
- Каков планируемый рост системы? Каков текущий коэффициент использования сети и как он может измениться в течение ближайших 6 месяцев, одного года, двух лет? Даже если вы тщательно спланировали сеть, но не учли возможности ее роста и развития, то системные требования придется изменить и увеличить. Рост сети нужно планировать заранее, а не просто реагировать на фактический рост ее нагрузки.
Разработка технической модели
Бизнес модель разработка бизнес модели; основные компоненты бизнес модели
После того, как системные требования определены, нужно описать техническую модель корпоративной сети. На этом этапе нужно определить, каким образом предполагается удовлетворить производственные требования с технической точки зрения.
Например, если строится сеть для отдела закупок, то технология Fast Ethernet очевидно будет излишней, даже если в отделе обрабатывается большое число документов. В то же время в инженерном отделе технология Fast Ethernet будет более целесообразна, так как там имеют дело с большими файлами. Можно также рассмотреть целесообразность сети Ethernet с отдельными сегментами для каждого пользователя. Построение хорошей сети означает постоянное сопоставление технических новшеств и потребностей предприятия. Нужно использовать только такие технические решения, которые необходимы.
Необходимо сделать тщательный выбор между передовой технологией и технологией, проверенной временем. Например, Ethernet и TokenRing являются проверенными технологиями, а ATM — сравнительно новой. Не многие проектировщики хорошо с ней знакомы, а капиталовложения необходимо сделать значительные.
Далее нужно оценить, какое семейство технических средств удовлетворяет производственным потребностям. Здесь также определяются топология сети, коммуникационные связи и пропускная способность.
Далее нужно выяснить, какие технологии и технические средства станут доступными в ближайшее время, а также каковы долгосрочные перспективы этих новшеств. Необходимо оценить, сможет ли проектируемая сеть принять завтрашние технологические новинки.
Построение физической модели
После того, как для сети выбрана техническая модель, необходимо оценить, насколько она удовлетворяет производственным требованиям. Нужно вернуться к бизнес-модели и сопоставить ее требования с техническими решениями. Вряд ли технические решения будут полностью удовлетворять требованиям бизнес-модели, но к этому надо стремиться.
Например, если предприятии сотрудники часто перемещаются из отдела в отдел, то требованием бизнес-модели является высокая мобильность. Техническая модель должна в таком случае обеспечивать быстрое присоединение и отсоединение рабочей станции.
После того, как устанавливается факт, что техническая модель соответствует требованиям, нужно построить физическую модель. Физическая модель конкретизирует специфику технической модели. Физическая модель является очень подробным описанием сети, в то время как техническая модель использует для ее описания более общие термины.
Этап физического моделирования требует более детального знакомства с имеющимися продуктами. Здесь необходимо оценить свойства и функции подходящих продуктов и решить, какие из них наилучшим образом удовлетворяют требованиям разрабатываемой системы. На стадии физического моделирования точно описаываются, какие компоненты нужны, в каком количестве, где они будут расположены и как эти компоненты соединяются друг с другом в корпоративную сеть. Этот этап завершается разработкой технического задания.
Разработка технического задания
После того, как были разработаны бизнес-модель, техническая и физическая модели, необходимо разработать техническое задание. Техническое задание базируется в основном на информации, собранной на этапе анализа требований. Сложность проектируемой корпоративной сети и опыт предприятия определят глубину и широту охвата технического задания. Техническое задание может иметь объем и 5, и 50, и более страниц.
Как и на этапе анализа требований, техническое задание готовится самим предприятием сами или с помощью консультанта. Если привлекается консультант, то, очевидно, что техническое задание будут более полными и завершенными, чем если бы его готовило само предприятие. Техническое задание, подготовленное консультантом, должно включать полное описание проекта сети и список оборудования, которое нужно купить, так что поставщикам останется только назвать цену. Если предприятие само готовит техническое задание, то оно больше полагается на предложения системных интеграторов и меньше думать о стоимости.
В общем случае техническое задание должно содержать разделы:
Во введении дается обзор содержания технического задания. Оно коротко описывает предприятие, его сеть, производственные цели и примерные этапы установки сети.
Цели создания сети на предприятии
Этот раздел описывает, как предприятие представляет использование сети для решения производственных проблем.. Здесь следует также указать, имеется ли какой-либо проект автоматизированной информационной системы, связанный с данной сетью, но не отраженный в данном техническом задании.
Здесь отмечаются общие цели создания сети, полученные из анализа потребностей вашего предприятия. Например, предприятию нужны коммуникации со всеми подразделениями и филиалами, при этом нужно включить в сеть существующее оборудование и используемые в настоящее время приложения, новые приложения. Перечисляется используемое в настоящее время оборудование, типы и количество компьютеров каждого типа в каждом подразделении и филиале. Описывается кабельная система. Указываются существующие стандарты предприятия и определяются этапы внедрения.
Требования к предложениям системных интеграторов
В этом разделе необходимо указать, что хотелось бы увидеть в предложениях системных интеграторов. Это поможет сравнить в дальнейшем предложения разных системных интеграторов:
- Технические требования. Здесь можно указать требуемый перечень характеристик (название, номер модели, цена и т.п.) для программного и аппаратного обеспечения. Можно попросить также представить схему проектируемой сети, а также сроки поставки оборудования.
- Сведения о интеграторах. Наряду с техническими требованиями можно запросить сведения о самих интеграторах-поставщиках. В этом случае интеграторы должны включить в свои предложения описания своих предыдущих разработок, данных о сотрудниках, которые будут проектировать и устанавливать сеть, информацию о финансовом состоянии фирмы-интегратора, а также указать клиентов, для которых выполнялись аналогичные работы.
Требования к техническим аспектам сети
Этот раздел должен основываться на разработанной технической модели. Указываются, какие компоненты должна содержать сеть. Указываются требования к приложениям. Формулируется, прежде всего, требования, какие приложения нужны: электронная почта, база данных, средства автоматизации документооборота, средства коммуникации и д.р.
Устанавливаются требования к средствам коммуникаций. Нужно ли пользователям взаимодействовать с другими офисами, мейнфреймами, миникомпьютерами или другими источниками информации в режиме on-line. Определяется, есть ли у предприятия предпочтение по отношению к определенной клиентской операционной системе, к сетевой операционной системе или к пользовательскому интерфейсу.
Системные спецификации
Раздел системных спецификаций технического задания описывает технические спецификации компонентов сети:
- Уровень отделов. Техническое задание описывает спецификации для рабочих станций, принтеров, файл-серверов, приложений, утилит печати, коммуникационных утилит и утилит электронной почты. Если требуется высокая отказоустойчивость, то описываются желаемые компоненты для ее обеспечения, такие как зеркальные серверы, источники бесперебойного питания и устройства архивирования. Техническое задание должно определить требуемое среднее время безотказной работы компонентов сети.
- Уровни кампусов и предприятия. Техническое задание определяет требуемые характеристики мостов, маршрутизаторов, модемов, факс-серверов, шлюзов к миникомпьютерам и мейнфреймам, коммуникационных программ и программного обеспечения широкого применения, такого как электронная почта. Должно быть определено приемлемое среднее время доступности сети.
Сетевые проблемы
Этот раздел содержит информацию из физической модели сети:
- Сетевая операционная система. В техническом задании следует запросить системного интегратора определить тип корпоративной сетевой операционной системы, если на предприятии она не стандартизована. Системный интегратор должен обосновать свой выбор.
- Сетевое и коммуникационное оборудование.
- Межсетевое взаимодействие. Каким образом будут соединены сети отделов? Техническое задание требует от интегратора обоснования выбора метода межсетевого взаимодействия, а также выбора изготовителя оборудования.
- Глобальные связи. Какие глобальные связи будут использованы для соединения с другими офисами? В предложении должны быть описаны требования для каждого филиала, причем они должны быть обоснованы по характеристикам пропускной способности, стоимости и управляемости. Будут ли они публичными или частными сервисами?
- Удаленный доступ. В предложении интегратора должен быть описан способ удаленного доступа. Это особенно важно, если сотрудники предприятия используют ноутбуки или же много перемещаются и в то же время нуждаются в доступе к сети. Требуются ли только входящие соединения удаленного доступа или и исходящее также? Будут ли они использовать сети других корпораций?
- Безопасность. Какую схему безопасности необходимо использовать, чтобы защитить сеть от случайного или преднамеренного вторжения? Какая защита от вирусов предусмотрена в сети?
- Доступность сети. В течение какого времени сеть должна быть доступной? Какая избыточность оборудования предусматривается для обеспечения надежной работы сети в течение всего периода доступности? Какие требования предъявляются к среднему времени между отказами для наиболее ответственных компонентов сети? В течение какого времени поставщики должны устранять проблемы с их оборудованием?
- Управление сетью. Каким образом будет управляться сеть? Как будут устраняться неисправности? Какой инструментарий требуется для этого? Будет ли управление осуществляться удаленно? Сколько людей потребуется для управления сетью?
- Масштабируемость сети. В предложениях должно быть указано, как сеть сможет удовлетворять потребности предприятия в будущем. Для этого в техническом задании должна быть дана оценка возможного роста предприятия и корпоративной сети на год вперед. В предложениях, в свою очередь, должно быть указано, какое максимальное количество пользователей, серверов, мостов, маршрутизаторов и шлюзов сможет обслуживать данная сеть без значительного уменьшения производительности.
Кроме указанных разделов техническое задание содержит разделы инсталляция сети, обучение персонала и обслуживание сети.
Источник: studfile.net
Построение технической модели
После разработки бизнес-модели предприятия и определения того, какие процедуры требуют изменения или улучшения, необходимо построить техническую модель сети. Техническая модель описывает в достаточно общих терминах, какое компьютерное оборудование нужно использовать, чтобы достичь целей, определенных в бизнес-модели. Чтобы построить техническую модель, нужно проанализировать существующее оборудование, определить системные требования, оценить сегодняшнее и завтрашнее состояния техники.
10.2.3.1. Инвентаризация существующего оборудования и приложений
Не многие предприятия могут себе позволить роскошь построения корпоративной сети с нуля. Большинство же вместо этого строят свои компьютерные системы с использованием имеющегося оборудования, которое уже эксплуатируется какое-то время. Необходимо оценить, какое существующее оборудование продолжает иметь стратегическое значение для предприятия, а какое может быть безболезненно списано. Однако сначала необходимо все же определить, что же вы имеете.
Для каждого отдела и офиса необходимо провести инвентаризацию существующего компьютерного оборудования и выяснить, какое действительно используется. Например, действительно ли еще используются 286-е IBMPC-совместимые персональные компьютеры, сколько их? Сколько имеется других компьютеров? Выполняются ли какие-либо приложения мейнфреймом IBM 370?
Какие используются типы сетевого оборудования и протоколов, а также сетевых операционных систем: SNA, IPX/SPX, TCP/IP, NetWare, WindowsforWorkgroups, Unix, WindowsNT и т.п. Где это оборудование находится, и в каком оно состоянии? Есть ли экономический смысл продолжать эксплуатировать эту технику или же более эффективно перейти на новую технику? Например, если в программное обеспечение мейнфрейма вложено значительное количество денег, и система работает без проблем, то, очевидно, нет смысла ее заменять. В этом случае корпоративная сеть должна уметь взаимодействовать и с этим мейнфреймом.
После того, как проведена ревизия оборудования, необходимо проделать то же самое с приложениями. Необходимо выяснить:
Какие приложения используются в каждом офисе и отделе, сколько людей пользуются каждым приложением, и трафик какой интенсивности они создают? Могут ли эти приложения быть использованы в корпоративной сети? Где хранятся эти приложения и каким образом пользователи смогут получать к ним доступ в новой операционной среде? Существуют ли более эффективные приложения аналогичного назначения и захотят ли сотрудники перейти на них?
Инвентаризация — очень скучная процедура, но тем не менее ее нужно осуществить, чтобы точно знать, чем вы располагаете и что нужно приобрести. Для такой большой системы, как корпоративная сеть, очень важно, чтобы каждый элемент, будь то кабель или плата памяти, был промаркирован и учтен. Процесс инвентаризации можно и нужно автоматизировать. Существуют программы, которые могут автоматически исследовать состав аппаратного и программного обеспечения уже работающих в сети компьютеров.
В общем случае такие программы могут выяснить тип CPU, имеющуюся память, тип диска и свободное пространство на нем, имеющиеся дополнительные контроллеры — такие как сетевые адаптеры, факс-модемы и т.п. Для программного обеспечения можно узнать наименование и версию приложений, версии операционной системы, установленные сетевые драйверы.
Программы-исследователи создают базу данных подобной информации, которая может использоваться для справок или при устранении неисправностей. Администратор может периодически запускать исследовательскую программу и получать недельную, месячную или квартальную справку о текущем состоянии сетевых ресурсов.
10.2.3.2. Определение системных требований
После инвентаризации существующей вычислительной системы необходимо определить требования к новой системе. Для определения технических параметров сети рассматривайте системные требования не с технической точки зрения, а с позиций руководителей, менеджеров и конечных пользователей.
Для выяснения системных требований необходимо ответить на следующие вопросы:
Что нужно соединять? Требуется ли сотрудникам какого-либо подразделения общаться с небольшим (большим) количеством людей в пределах небольшой территории или же им нужно общаться с небольшим (большим) количеством людей в пределах географически обширной области?
Объем и распределение трафика поможет определить требуемую мощность компьютеров, а также типы и скорости коммуникационного оборудования и сервисов. Что из существующего аппаратного и программного обеспечения будет использоваться в новой системе? Какие системы нужно оставить в разрабатываемой корпоративной сети? Нужно ли эти системы соединять в сеть?
Будут ли существующие системы нормально работать в новой сети? Существуют ли какие-либо стандарты предприятия, существуют ли преобладающие приложения? Какое оборудование и приложения нужно добавить, чтобы достигнуть поставленных производственных целей? Какие объемы информации будут передаваться по сети?
Объем передаваемой информации определяет требуемую пропускную способность сети. По корпоративной сети будет передаваться больше или меньше информации? Определите это подсчетом количества пользователей сети, среднего количества выполняемых транзакций в день каждым из пользователей и среднего объема транзакции.
Такой подсчет поможет определить технологию доступа к среде передачи данных (Ethernet, FDDI, . ) и требования к глобальным сервисам. Какое время реакции сети является приемлемым? Будут ли пользователи ждать одну секунду, полсекунды или две секунды? Такие измерения помогут определить требования к скорости оборудования, приложений и коммуникационных связей.
В течение какого времени сеть существенно необходима для работы предприятия? Нужна ли сеть 24 часа в день и 7 дней в неделю или же только в течение 8 часов в день и 5 дней в неделю? Нужно ли увеличить сегодняшние параметры использования сети? Какие требования предъявляются к среднему времени устранения неисправностей?
Как отражаются операции по обслуживанию и ремонту сети на эффективности ведения дел предприятием? Потеряет ли предприятие 5 миллионов долларов или же 100 тысяч долларов, если сеть будет неисправна в течение одного часа? Каков будет ущерб от простоя сети в течение двух часов? Каков планируемый рост системы?
Каков текущий коэффициент использования сети и как он может измениться в течение ближайших 6 месяцев, одного года, двух лет? Даже если вы тщательно спланировали сеть, но не учли возможности ее роста и развития, то системные требования придется изменить и увеличить. Рост сети нужно планировать заранее, а не просто реагировать на фактический рост ее нагрузки.
Информация о работе «Корпоративные сети»
Раздел: Информатика, программирование
Количество знаков с пробелами: 515112
Количество таблиц: 3
Количество изображений: 0
Источник: kazedu.com
Какую методологию разработки выбрать для вашего проекта
За годы нашей работы мы сталкивались со всеми основными методологиями разработки ПО. Мы применяли каждую из них по отдельности, старались совмещать разные методы, использовали лучшие стороны различных подходов, чтобы удовлетворить потребности заказчиков. В этой статье рассмотрели основные методологии и обозначили плюсы и минусы каждой.
Agile (Гибкая модель разработки)
Agile разработка позволяет вносить изменения на каждом этапе проекта, адаптировать проект под требования владельца продукта, снижать финансовые риски и быстро запускать продукт на рынок.
Например, компания-ритейлер запускает портал для интернет торговли. В начале запускается каркас продукта (страница с товарами и корзиной) и тестируется на реальных пользователях, разработка продолжается без остановок, добавляются страницы с обзорами товаров. Обратная связь от пользователей позволяет исследовать поведение клиентов на практике и тестировать новые гипотезы (на сколько вырастут показатели после изменения ключевых запросов).
После запуска продукта проводятся первичные рекламные кампании и отслеживаются результаты через веб-аналитику. На заключительном этапе дорабатываются успешные гипотезы и отсеиваются неудачные.
Гибкая модель предоставляет возможность начать разработку сразу после согласования бизнес-модели, общей стратегии и функциональных требований. Каждый день команда разработчиков и заказчик (product owner) обсуждают текущие действия, проблемы и будущие изменения. Новые идеи анализируются и сразу же внедряются.
Преимущества
Постоянное взаимодействие с владельцем продукта. Можно отследить подходит ли продукт рынку, что требуется изменить и сразу внести необходимые изменения.
Эффективность работы. Сотрудники сами принимают решения относительно основных элементов работы. Документы и инструменты не определяют работу команды. Все процессы и структуры максимально упрощены. Команда концентрируется только на самых важных приоритетах в развитии проекта.
Быстрое выявление и устранение ошибок. Все возможные проблемы выявляются на ранних этапах и тут же устраняются. Это также позволяет избежать проблем с несовпадением ожидаемого и реального результата.
Недостатки
Опасность затягивания сроков. Постоянная обратная связь может оттягивать завершение проекта. Необходимо всегда учитывать происходящие изменения и адаптировать дедлайны под новые задачи.
Сложно оценить конечную стоимость продукта. Все новые и новые итерации расширяют бюджет и не позволяют точно спрогнозировать финальную сумму.
Подходит для новых технологичных проектов
Agile методология применяется в стартапах, где необходимо опередить конкурентов и выпустить продукт как можно быстрее, и в сфере новых технологий, где результаты разработки продукта нельзя предсказать заранее.
Например, когда банки обновляют программное обеспечение, они в первую очередь обсуждают все детали проекта вместе с представителями банка и разработчиками. Основная цель обсуждения — понять как пользователь будет взаимодействовать с системой. Разработчики прописывают каждую линию взаимодействия и тщательно подбирают функционал.
Когда этот процесс завершен, все члены команды уже понимают, что от них требуется. На следующей стадии происходит написание кода и проверка на ошибки. На момент завершения проекта все поставленные цели уже достигнуты.
Kanban
Подход к разработке ПО по методике Agile, который подразумевает открытость всех рабочих процессов и постоянное улучшение производительности. Каждый член команды выполняет индивидуальный набор задач.
Преимущества
Высокая концентрация на текущей работе. Команда фокусируется на конкретной задаче и направляет все усилия на ее решение. Приоритетность задач может меняться.
Быстрое устранение проблем. Все члены команды могут отслеживать прогресс и давать обратную связь, которая помогает оперативно исправлять ошибки.
Оптимизация издержек. Канбан позволяет анализировать и прогнозировать точное время, необходимое для реализации проекта.
Недостатки
Не удовлетворяет требованиям больших команд. Метод не предназначен для групп численностью больше 5 человек,и команд, где сотрудники не знают функции друг друга. В таких условиях невозможно эффективно контролировать реализацию проекта.
Scrum
Модель управления разработкой с гибкой организацией работы внутри команды, направленной на создание новых сложных продуктов. Scrum позволяет развивать проект в тесном сотрудничестве с заказчиком, постоянно корректируя характеристики продукта и показывая результат на каждом этапе разработки.
Преимущества
Эффективное взаимодействие между участниками проекта. Процесс принятия решений полностью зависит только от членов команды. Все внутренние процессы регулируют сами разработчики. Это позволяет всем участникам проекта четко понимать свои функции и задачи.
Минимум контроля и фокус на постоянные обновления. Весь процесс разбит на 30-дневные периоды с ежедневными собраниями. Любые изменения происходят очень быстро и не требуют лишних затрат и издержек.
Недостатки
Высокая стоимость разработчиков. Результат сильно зависит от профессионализма команды. Сотрудники должны обладать способностями к самодисциплине и самоконтролю.
Нежелательное расширение проекта. Отсутствие единого контроля за реализацией проекта может привести к увеличению бюджетных трат.
Недостаток гибкости в больших проектах. Потеря даже одного члена команды станет серьезной проблемой и снизит эффективность реализации проекта. Scrum и Kanban применяются в большинстве Agile проектов.
Waterfall (Каскадная модель или «водопад»)
Классическая поэтапная методология, в которой каждый следующий шаг начинается только после завершения предыдущего. В отличие от Agile каскадная модель не допускает изменений в этапах разработки.
Преимущества
Постоянный контроль процессов и предсказуемость. Цели и задачи проекта понятны для разработчиков и не вызывают дополнительных вопросов.
Оценка затрат и сроков до начала проекта. Все требования четко проговариваются на начальном этапе и не изменяются в течение всего процесса. Предсказуемость позволяет точно оценить будущие расходы.
Документация каждого этапа. Это позволяет создавать базу для других проектов и предоставлять отчетность заказчику в любое время.
Недостатки
Сложно исправить ошибки. Тестирование проходит только на последних этапах разработки, поэтому возможные недочеты необходимо предусмотреть заранее.
Отсутствие обратной связи от заказчика на протяжении большей части проекта. Заказчик принимает участие в обсуждении целей проекта и возвращается, чтобы оценить финальный результат, который может его полностью не удовлетворить.
Высокая стоимость исправлений. Любая ошибка приведет к необходимости переделывать весь проект. Избежать подобных проблем помогают сильные и дорогие бизнес-аналитики, которые способны точно перевести задачи бизнеса на ИТ язык.
Где применяется
Каскадная модель используется при реализации проектов по жизнеобеспечению, где любая ошибка может привести к фатальным последствиям. «Водопад» предпочитают также военные и воздушные организации, в которых необходимы строгие требования к выполнению проектов. Подобная модель может применяться при разработке программного обеспечения для дорожных светофоров. На начальном этапе проект необходимо согласовать с заказчиком и прописать всю документацию. После этого будет выбрана архитектура, создан код, проведено тестирование, осуществлена интеграция и проверка на ошибки. Каждый из этих этапов будет строго следовать один за другим.
V-model
Вид каскадной модели, в котором предусмотрено тестирование уже на ранних этапах реализации проекта. Модель приобрела особую популярность в сфере авионики (электронные системы на борту воздушного судна), где очень важно контролировать каждый отдельный шаг процесса разработки ПО.
Преимущества
Уменьшение рисков. Постоянное тестирование минимизирует возможность дорогостоящей ошибки.
Сокращение издержек. Цена всех стадий проекта легко прогнозируется и не изменяется.
Адаптивность для пользователей. V-модель четко фиксирует и реализует основные требования пользователей к разрабатываемому продукту.
Недостатки
Сложность исправления фундаментальных ошибок. Отсутствует конкретный механизм решения проблем, выявленных на этапе тестирования.
Недостаток гибкости в процессе разработки. Разработка начинается только после перехода к следующему этапу. Никаких предварительных шаблонов не предусмотрено. Это может затруднить понимание процесса для заказчика.
Где применяется
В сферах, где работа продукта не может быть остановлена. Например, разработка ПО для авиации представляет собой сложный документированный процесс, где каждый уровень тщательно прописывается и отслеживается любая ошибка. Тестирование начинается только после глубокого анализа требований, описанных в документах. Такой процесс занимает много времени и требует высокого уровня профессионализма от исполнителей.
RAD (rapid application development model или быстрая разработка приложений)
RAD позволяет быстро получить нужный результат в короткие сроки. Это достигается с помощью постоянного взаимодействия с заказчиком, своевременных уточнений требований и анализа результатов. Такая модель может использоваться при разработке платформы для анализа и обработки заказов на покупку товара (purchase order).
Быстрое создание первоначального прототипа обеспечивается с помощью тесного взаимодействия с департаментом закупок. После первого запуска необходимо сразу же познакомить пользователей с приложением. Это позволит выявить и исправить возможные ошибки и неточности.
Преимущества
Быстрое завершение проекта. Профессиональная команда, эффективные инструменты и создание прототипов обеспечивают высокую скорость реализации процесса разработки.
Минимальные бюджетные затраты. Элементы продукта разрабатываются и внедряются по отдельности. Это исключает ошибки, свойственные каскадной модели.
Вовлеченность заказчика. Заказчик становится активной частью проекта уже на ранних этапах разработки. Высокое качество. Оно обеспечивается за счет постоянного взаимодействия пользователей с будущими прототипами продукта.
Недостатки
Зависимость от заказчика. Заказчик и разработчики могут иметь разное представление о продукте.
Маленький и средний масштаб проектов. RAD сложно применить для больших проектов, где требуется усиленный контроль и нет возможности разделить процесс на маленькие части.
Где применяется
В проектах, где требуется закончить разработку в сжатые сроки. Так, когда финансовый отдел компании хочет получить удобную платформу для составления отчетов по командировкам, мы можем воспользоваться RAD методом. Вместе с сотрудниками компании мы создаем удобный прототип продукта и тут же тестируем его. Это позволяет всем пользователям быстро вносить изменения и улучшать платформу. Результатом такой разработки является значительное сокращение времени на обработку командировочных документов.
Spiral model
Удобная модель для анализа рисков. Идеально подходит для решения ключевых задач бизнеса, запуска нового продукта и проведения исследований.
Преимущества
Устранение рисков на ранних этапах реализации проекта. Этот шаг становится ключевым в данной модели.
Гибкость на всех этапах разработки. Возможность внесения изменений существует на протяжении всего проекта.
Недостатки
Длительная и дорогостоящая разработка. Спиральная модель требует больших временных и денежных затрат на осуществление основных принципов и привлечение квалифицированных специалистов.
Высокая зависимость результата от стадии анализа. Если на этом этапе будет допущена ошибка, то изменения проекта потребуют больших издержек.
Где применяется
В проектах, где необходимо анализировать большое количество рисков. Часто используется при разработке спутников и военных объектов.
Небольшой лайфхак
Выбор только одной методики не гарантирует успешное завершение проекта. Заказчик должен учитывать различные аспекты продукта при выборе того или иного вида разработки. Мы иногда совмещаем различные подходы для достижения желаемых результатов. Каждая из перечисленных методологий имеет свое назначение и сферу применения.
Наш опыт позволяет определять тип разработки, который подходит заказчику. Мы всегда готовы помочь в выборе оптимального подхода для решения задач вашего бизнеса.
Источник: stecpoint.ru