2. Важность тестирования

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

• бизнес-причины: намного проще конкурировать на рынке ПО той фирме, которая выпускает качественное ПО.

• предпочтения пользователей: от качества ПО зависят такие важные для пользователя факторы как безопасность личных данных, денежных операций и т.п.

• объективные факторы: наконец, есть области, в которых от качества ПО зависит жизнь людей (иногда – сотен, тысяч и даже миллионов).

3. Модели жизненного цикла по

Водопадная модель

Водопадная(каскадная) модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков. Основная идея: долгосрочное планирование. Хорошо работает для мелких проектов.

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

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

Концепция V-образной модели была разработана Германией и США в конце 1980-х годов независимо друг от друга:

• Немецкая V-модель была разработана аэрокосмической компанией IABG в Оттобрунне рядом с Мюнхеном в содействии с Федеральным департаментом по закупке вооружений в Кобленце, для Министерства обороны Германии. Модель была принята немецкой федеральной администрацией для гражданских нужд летом 1992.

• Американская V-Model (VEE) была разработана национальным советом по системной инженерии (международным — с 1995 года) для спутниковых систем, включая оборудование, программное обеспечение и взаимодействие с пользователями.

V- образная модель была создана с целью помочь работающей над проектом команде в планировании с обеспечением дальнейшей возможности тестирования системы. В этой модели особое значение придается действиям, направленным на верификацию и аттестацию ИС. Она демонстрирует, что тестирование производится на ранних этапах ЖЦ разработки. План испытания, приемки заказчиком разрабатывается на этапе планирования, компоновочного испытания системы – на фазах анализа, разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между прямоугольниками V-образной модели.

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

Основная идея: планирование целей и результатов «стадии на подъёме» при проработке «стадий на спуске».

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

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

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

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

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

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

Модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называют итеративной моделью и инкрементальной моделью.

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно.

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

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

Основная идея: повторение небольших, простых для понимания и управления циклов работы над проектом. Ближе всего к гибким методологиям, но направлена на крупнобюджетные проекты, т.к. очень дорога в «обслуживании».

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

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

RUP

Rational Unified Process (RUP) — методология разработки программного обеспечения, созданная компанией Rational Software.

В основе RUP лежат следующие основные принципы:

• Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

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

• Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

• Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

• Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

• Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

Жизненный цикл разработки

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

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