V-модель применима сегодня в сфере ИТ

V-модель применима сегодня в сфере ИТ

http://ru.wikipedia.org/wiki/V-Model

http://en.wikipedia.org/wiki/V-Model_(software_development)

http://habrahabr.ru/post/144686/

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

Одной из начальных концепций, созданных и применяемых первыми  специалистами в сфере ИТ, была V-модель. Она была создана для обеспечения проектных групп механизмом, при помощи которого они могли бы:

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

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

Диаграмма V-модели: логическая структура

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

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

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

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

Горизонтальные  стрелки: Три горизонтальных стрелки используются для пояснения того, что должна существовать взаимосвязь между этапом разработки (определение требований и проектирование) в модели и этапом тестирования, которое должно проводиться для проверки того, что производимое приложение соответствует утвержденным требованиям и конструкции. Эти горизонтальные линии были помечены как "Проверка/тестирование".

V-модель: принципы

V-модели присущи следующие  принципы.

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

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

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

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

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

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

Последовательность  действий V-модели: семь шагов

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

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

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

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

Шаг 5: На этом уровне (Тестирование компонентов) проектная группа отвечает за три важнейших функции. Первая – выполнение действий фазы тестирования компонентов согласно заранее установленному плану тестирования компонентов (устанавливается на шаге 3). Вторая – выявление и фиксация расхождений между "заранее заданными ожидаемыми результатами" и "реальными результатами тестирования" для всех без исключения компонентов/программ. Третья  – обеспечение выполнения всех заранее установленных контрольных примеров для компонентов и получения всех ожидаемых результатов. Этот шаг будет повторяться один или несколько раз группой разработчиков и группой тестировщиков, чтобы обеспечить задание и успешное тестирование всех соответствующих требований. После завершения этого этапа проектная группа перейдет к шагу 6.

Шаг 6: На этом уровне (Комплексное тестирование) проектная группа отвечает за три важнейших функции. Первая  – выполнение действий фазы комплексного тестирования согласно плану (установленному на шаге 2). Вторая   –  выявление и фиксация расхождений между "заранее заданными ожидаемыми результатами" и "реальными результатами тестирования" для всех без исключения подсистем. Третья   –  обеспечение выполнения всех заранее установленных контрольных примеров и получения всех ожидаемых результатов. Этот шаг будет повторяться один или несколько раз группой разработчиков и группой тестировщиков, чтобы обеспечить задание и успешное тестирование всех соответствующих требований. После завершения этого этапа проектная группа перейдет к шагу 7.

Шаг 7: На этом уровне (Приёмочные испытания) проектная группа отвечает за три важнейших функции. Первая  –  выполнение действий фазы приемочных испытаний согласно плану (установленному на шаге 1). Вторая – выявление и фиксация расхождений между "заранее заданными ожидаемыми результатами" и "реальными результатами тестирования" для приложения. Третья  – обеспечение выполнения всех заранее установленных контрольных примеров и получения всех ожидаемых результатов. Этот шаг будет повторяться один или несколько раз группой разработчиков и группой тестировщиков, чтобы обеспечить задание и успешное тестирование всех соответствующих требований. После завершения этого этапа проектная группа закончит свою работу, и приложение будет внедрено в производственную среду.

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

Применимость: V-модель дает организациям и проектным группам руководство по выполнению и завершению проектов последовательным и воспроизводимым образом. Применение принципов V-модели гарантирует выявление и фиксацию требований пользователей. Утвержденные требования могут быть переведены в функции готового приложения, (и) приложение отражает требования пользователей.

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

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

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

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