Итеративная модель - Allied Testing College

Lecture 2
1/23/2016 6:51:00 PM
Процесс разработки ПО.
Компоненты программного продукта. Состав команды по разработке ПО. Модели и стратегии разрабоки ПО.
Модели и стратегии разрабоки ПО
Коллективная разработка, в отличие от индивидуальной, требует четкого планирования работ и их распределения во
время создания программной системы. Один из способов организации работ состоит в разбиении процесса разработки
на отдельные последовательные стадии, после полного прохождения которых получается конечный продукт или его
часть. Такие стадии называют жизненным циклом разработки программной системы.
Определение: Жизненный цикл программного обеспечения – совокупность итерационных процедур, связанных с
последовательным изменением состояния программного обеспечения от формирования исходных требований к нему
до окончания его эксплуатации конечным пользователем.
Это своего рода «карта-путеводитель» для всех участников проекта, которая помогает им понять, не выходят ли они за
определенные для них границы.
На рис. 1 представлена простая обобщенная схема процесса:
Процесс
Фаза
Действие
Жизненный цикл
Спецификация
План
Разработка
проекта
Код
Показатель
LOC
Разработка
Тестирование
модуля
Планы
тестирования,
результаты
тестирования
Рис. 1. Обобщенная схема процесса
1
Эксплуатация
Тестирование
системы
Планы
тестирования,
результаты
тестирования
1/23/2016 6:51:00 PM
Lecture 2


ЧЕМ НАЧИНАЕТСЯ ЖИЗНЕННЫЙ ЦИКЛ?
ЧЕМ ЗАКАНЧИВАЕТСЯ ЖИЗНЕННЫЙ ЦИКЛ?
Как правило, жизненный цикл начинается с формирования общего представления о разрабатываемой системе и их
формализации в виде требований верхнего уровня. Завершается жизненный цикл разработки вводом системы в
эксплуатацию.
Однако, нужно понимать, что разработка – только один из процессов, связанных с программной системой, которая
также имеет свой жизненный цикл. В отличие от жизненного цикла разработки системы, жизненный цикл самой
системы заканчивается выводом ее из эксплуатации и прекращением ее использования.
 КАКИЕ ПЛЮСЫ ПРИМЕНЕНИЯ ЖИЗНЕННЫХ ЦИКЛОВ (ТО ЕСТЬ РАЗБИЕНИЯ НА СТАДИИ)?
Разработка и использование жизненого цикла помогает достичь следующих целей:
 Улучшение и обеспечение качества:
- определение промежуточных результатов обеспечивает возможность ускорить выполнение оценочных
процедур;
 Возможность проверки затрат на выполнение полного жизненного цикла:
- стандартизированные процедуры повышают степень «прозрачности» операций по определению затрат
и позволяют более эффективно распознавать возможные риски, связанные с затратами;
 Улучшается обмен информацией между различными сторонами, участвующими в процессе разработки;
происходит снижение зависимости клиента от подрядчика:
- использование определенных терминов уменьшает разногласия, возникающие между всеми
задействованными в проекте сторонами;
- промежуточные /
окончательные результаты стандартизируются таким образом, что другие
задействованные в проекте стороны или персонал других компаний могут в случае необходимости
подключиться к процессу разработки, не прилагая при этом больших дополнительных усилий.
Модели жизненного цикла
Модель жизненного цикла разработки ПО (Software Life Cycle Model, SLCM) схематически объясняет, каким образом
будут выполняться действия по разработке программного продукта, посредством описания «последовательности» этих
действий. Такая последовательность может быть или не быть линейной, поскольку фазы могут следовать друг за
другом, повторяться или происходить одновременно.
В первые годы практики программирования сначала записывался программный код, а затем происходила его
отладка. Общепринятым считалось правило начинать работу не с разработки плана, а с общего ознакомления с
продуктом. Без лишних формальностей можно было спроектировать, закодировать, отладить и протестировать ПО еще
до того, как оно будет готово к выпуску. Это напоминало процесс, изображенный на рис. 2.

КАКИЕ МИНУСЫ ТАКОГО ПОДХОДА?
В структуре такого процесса есть несколько "неправильностей" (или недостатков). Во-первых, поскольку
изначально не существовало официального проекта или анализа, невозможно было узнать о моменте завершения
процесса. Также отсутствовал способ определения соответствия требованиям относительно достижения качества.
Входы
Выходы
Кодирование и тестирование
Делать, пока не будет сделано
2
1/23/2016 6:51:00 PM
Lecture 2
Рис. 2. Модель процесса "делать, пока, не будет сделано”
Каскадная модель (Waterfall)
В 1970 году каскадная модель была впервые определена как альтернативный вариант метода разработки ПО по
принципу кодирование-устранение ошибок, который был широко распространен в то время. Это была первая модель,
которая формализовала структуру этапов разработки ПО, придавая особое значение исходным требованиям и
проектированию, а также созданию документации на ранних этапах процесса разработки.
Actually, the hardware oriented model adapted to software.
Начальный этап выполнения каскадной модели показан в левой верхней части рис. 3. Продолжение процесса
выполнения реализуется с помощью упорядоченной последовательности шагов. В модели предусмотрено, что каждая
последующая фаза начинается лишь тогда, когда полностью завершено выполнение предыдущей фазы Каждая фаза
имеет определенные критерии входа и выхода: входные и выходные данные.
Requirement
specification
• определение
требований
пользователя/заказчика
Functional
specification
• Определение функциональности
необходимой для достижения
требований пользователя
Technical
specification
• Определение технического дизайна
(архитектуры) для функциональности
утверждённой на стадии Functional
specification
Program
specification
• Определение детального дизайна
каждого модуля необходимого для
утверждённой функциональности
Coding
Testing
Рис. 3. Классическая каскадная модель
3
Lecture 2
1/23/2016 6:51:00 PM
В результате выполнения генерируются внутренние или внешние данные проекта, включая документацию и ПО.
Документы по анализу требований впоследствии передаются системным специалистам, которые в свою очередь
передают их разработчикам программных систем более высокого уровня. Разработчики передают детальные
технические характеристики программистам, которые уже предоставляют готовый код тестерам.
Переход от одной фазы к другой осуществляется посредством формального обзора. Таким образом, клиент
получает общее представление о процессе разработки, кроме того происходит проверка качества программного
продукта. Как правило, прохождение стадии обзора указывает на договоренность между командой разработчиков и
клиентом о том, что текущая фаза завершена и можно перейти к выполнению следующей фазы. Окончание фазы
удобно принимать за стадию в процессе выполнения проекта.
В результате завершения определенных фаз формируется базовая линия, которая в данной точке "замораживает"
продукты разработки. Если возникает потребность в их изменении, тогда для внесения изменений используется
формальный процесс изменений.
Попытки оптимизации каскадной модели привели к возникновению других циклов разработки ПО.
Отличительным свойством каскадной модели можно назвать то, что она представляет собой формальный метод,
разновидность разработки "сверху вниз", она состоит из независимых фаз, выполняемых последовательно, и
подвержена частому обзору.

КАКОВЫ ПРИЕМУЩЕСТВА WATERFALL?
Преимущества каскадной модели:
 модель хорошо известна потребителям, не имеющим отношения к разработке и эксплуатации программ, и
конечным пользователям (она часто используется другими организациями для отслеживания проектов, не
связанных с разработкой ПО);
 она проста и удобна в применении, так как процесс разработки выполняется поэтапно;
 она хорошо срабатывает тогда, когда требования к качеству доминируют над требованиями к затратам и
графику выполнения проекта;

КАКОВЫ МИНУСЫ WATERFALL?
Недостатки каскадной модели:
 в основе модели лежит последовательная линейная структура, в результате чего каждая попытка вернуться на
одну или две фазы назад, чтобы исправить какую-либо проблему или недостаток, приведет к значительному
увеличению затрат и сбою в графике;
 она не может предотвратить возникновение итераций между фазами, которые так часто встречаются при
разработке ПО, поскольку сама модель создается согласно стандартному циклу аппаратного инжиниринга;
 интеграция всех полученных результатов происходит внезапно в завершающей стадии работы модели. В
результате такого единичного прохода через весь процесс, связанные с интегрированием проблемы, как
правило, дают о себе знать слишком поздно. Следовательно, проявятся не обнаруженные ранее ошибки или
конструктивные недостатки, повысить степень риска при небольшом задаче времени на восстановление
продукта;
 пользователи не могут убедиться в качестве разработанного продукта до окончания всего процесса
разработки. Они не имеют возможности оценить качество, если нельзя увидеть готовый продукт разработки;
Область применения каскадной модели
Пример waterfall:
Предоположим что завод выпускает авиационные заклёпки. Проверка заклёпок происходитв конце конвеера на самом
заводе и часть из них отсеиваются как дефектные. Обычно процент брака невелик и не влияет на всё производство.
Часть заклёпок прошедших контроль можно выпускать в продажу.
Представим, что на этот же самолёт, который получил заклёпки, устанавливается программное обеспечение по
контролю за информацией, которая отображается пилоту. И если при тестировании обнаружено большое количество
ошибок
 ЧТО ПРОИЗОЙДЁТ? МОЖНО ЛИ ВЫПУСКАТЬ ПРОДУКТ?
4
1/23/2016 6:51:00 PM
Lecture 2
Из-за недостатков каскадной модели ее применение необходимо ограничить ситуациями, в которых требования
и их реализация максимально четко определены и понятны.
Если компания имеет опыт построения определенного рода системы — автоматизированного бухгалтерского учета,
начисления зарплаты, ревизии, компиляции, производства, — тогда в проекте, ориентированном на построение еще
одного продукта такого же типа, возможно, даже основанного на существующих разработках, можно эффективно
использовать каскадную модель
Другим примером надлежащего применения модели может служить создание и выпуск новой версии уже
существующего продукта, если вносимые изменения вполне определены и управляемы. Перенос уже существующего
продукта на новую платформу часто приводят в качестве идеального примера использования каскадной модели в
проекте.
V-образный жизненный цикл
V-образная модель была создана с целью помочь работающей над проектом команде в планировании с
обеспечением дальнейшей возможности тестирования системы. В этой модели особое значение придается
действиям, направленным на верификацию и аттестацию продукта. Она демонстрирует, что тестирование продукта
обсуждается, проектируется и планируется на ранних этапах жизненного цикла разработки. План испытания приемки
заказчиком разрабатывается на этапе планирования, а компоновочного испытания системы - на фазах анализа,
разработки проекта и т.д. Этот процесс разработки планов испытания обозначен пунктирной линией между
прямоугольниками V-образной модели.
V-образная модель, показанная на рис. 4, была разработана как разновидность каскадной модели, а значит,
унаследовала от нее такую же последовательную структуру. Каждая последующая фаза начинается по завершению
получения результативных данных предыдущей фазы. Модель демонстрирует комплексный подход к определению фаз
процесса разработки ПО. В ней подчеркнуты взаимосвязи, существующие между аналитическими фазами и фазами
проектирования, которые предшествуют кодированию, после которого следуют фазы тестирования. Пунктирные линии
означают, что эти фазы необходимо рассматривать параллельно.
Requirement specification
Acceptance testing
Functional specification
System testing
Technical specification
Integration testing
Unit testing
Program specification
Coding
Рис. 4. V –образная модель жизненного цикла разработки ПО
Стадии проходят последовательно – сверху вниз и затем снизу вверх.
5
Lecture 2










1/23/2016 6:51:00 PM
Планирование проекта и требований (Requirement specification) – определяются системные требования, а
также то, каким образом будут распределены ресурсы организации с целью их соответствия поставленным
требованиям. (т.е определение нужд пользователся)
Анализ требований к продукту и его спецификации (Functional specification) – определение функционала
необходимого для достижения нужд пользователя
Архитектура или проектирование на высшем уровне (Technical specification) – определение технического
дизайна продукта (определение компонентов будущего продукта, свойств компонентов и взаимодействие
между компонентами). Техническая организация фукнционала определённого в Functional specification.
Детализированная разработка проекта (Program specification) – детальный дизайн каждого модуля или
компонента продукта
Разработка программного кода (Coding) – кодирование детального дизайна (спецификаций)
Модульное тестирование (Unit testing) - выполняется проверка каждого закодированного модуля на наличие
ошибок;
Интеграция и тестирование (Integration testing) - установка взаимосвязей между группами ранее поэлементно
испытанных модулей с целью подтверждения того, что эти группы работают также хорошо, как и модули,
испытанные независимо друг от друга на этапе поэлементного тестирования;
Cистемное Тестирование (System testing) - выполняется проверка функционирования программной системы в
целом (полностью интегрированная система), после помещения в ее аппаратную среду в соответствии со
спецификацией требований к ПО;
Приемочное тестирование (Acceptance testing) - проводиться заказчиком. Проверяется продукт на соответствие
желаемому результату.
КАКОВЫ ПРИЕМУЩЕСТВА V-MODEL?
Преимущества V-образной модели



в модели особое значение придается планированию, направленному на верификацию и аттестацию
разрабатываемого продукта на ранних стадиях его разработки. Фаза модульного тестирования подтверждает
правильность детализированного проектирования. Фазы интеграции и тестирования реализуют архитектурное
проектирование или проектирование на высшем уровне. Фаза тестирования системы подтверждает
правильность выполнения этапа требований к продукту и его спецификации;
модель определяет продукты, которые должны быть получены в результате процесса разработки, причем
каждые полученные данные должны подвергаться тестированию;
КАКОВЫ МИНУСЫ V_MODEL?
Недостатки V-образной модели




с ее помощью непросто справиться с параллельными событиями;
в ней не учтены итерации между фазами;
тестирование требований в жизненном цикле происходит слишком поздно, вследствие чего невозможно
внести изменения, не повлияв при этом на график выполнения проекта;
в модель не входят действия, направленные на анализ рисков.
С целью преодоления этих недостатков V-образную модель можно модифицировать, включив в нее итерационные
циклы, предназначенные для разрешения изменений в требованиях за рамками фазы анализа.
Область применения V-образной модели
6
Lecture 2
1/23/2016 6:51:00 PM
Подобно своей предшественнице, каскадной модели, V-образная модель лучше всего срабатывает тогда, когда вся
информация о требованиях доступна заранее.
V-образная модель — это отличный выбор для систем, в которых требуется высокая надежность, таких как
прикладные программы для наблюдения за пациентами в клиниках, а также встроенное ПО для устройств управления
аварийными подушками безопасности в автомобилях.
Итеративная модель
Entry
Requirements
Exit
Analysis &
Design
Evaluation
Coding &
Testing
Модель отображает базовую концепцию, которая заключается в том, что каждый цикл представляет собой набор
операций, которому соответствует такое же количество стадий, как и в модели каскадного процесса.
Каждый виток спирали соответствует созданию фрагмента или версии программного обеспечения, на нем уточняются
цели и характеристики проекта, определяется его качество и планируются работы следующего витка спирали. Таким
образом углубляются и последовательно конкретизируются детали проекта и в результате выбирается обоснованный
вариант, который доводится до реализации. Каждый виток разбит на 4 сектора:




Планирование требований (Requirements)
Выполняется определение целей, таких как рабочая характеристика, выполняемые функции, возможность
внесения изменений
Анализ и дизайн (Analysis & Design)
Выполняется определение и разрешение рисков (менеджмент рисков, методика экономически выгодного
выбора источников разрешения), определение технического дизайна итерации.
Кодирование и тестирование (Сoding & testing)
Типичные действия, выполняемые на этой стадии, могут включать в себя, разработку кода, проверку кода,
тестирование и компоновку продукта.
Оценка (Evaluation)
Оценка результатов, определение необходимости в следующей итерации
На каждом витке спирали могут применяться разные модели процесса разработки ПО. В конечном итоге на выходе
получается готовый продукт.
Основная проблема спирального цикла — определение момента перехода на следующий этап. Для ее решения
необходимо ввести временные ограничения на каждый из этапов жизненного цикла

КАКОВЫ ПЛЮСЫ ИТЕРАТИВНОЙ МОДЕЛИ?
Преимущества итеративной модели
7
Lecture 2




1/23/2016 6:51:00 PM
спиральная модель разрешает пользователям "увидеть" систему на ранних этапах, что обеспечивается
посредством использования ускоренного прототипирования в жизненном цикле разработки ПО;
обеспечивается определение непреодолимых рисков без особых дополнительных затрат;
в модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества
каскадной модели, и в тоже время, разрешены итерации по всем фазам этой же модели;
при использовании спиральной модели не нужно распределять заранее все необходимые для выполнения
проекта финансовые ресурсы;
Недостатки итеративной модели

Если проект имеет низкую степень риска или небольшие размеры, модель может оказаться дорогостоящей.
Оценка рисков после прохождения каждой спирали связана с большими затратами;
модель имеет усложненную структуру, поэтому может быть затруднено ее применение разработчиками,
менеджерами и заказчиками;
серьезная нужда в высокопрофессиональных знаниях для оценки рисков;
могут возникнуть затруднения при определении целей и стадий, указывающих на готовность продолжать
процесс разработки на следующей итерации;



Область применения итеративной модели



при разработке новой функции или новой серии продуктов;
когда требования слишком сложные;
когда нет смыла браться за выполнение долгосрочного проекта из-за потенциальных изменений, которые
могут произойти в экономических приоритетах, и когда такая неопределенность может вызвать ограничение
во времени;
для проектов, выполнение которых сопряжено со средней и высокой степенью риска;
в случае больших проектов;
при выполнении бизнес-проектов, а также проектов в области аэрокосмической промышленности, обороны и
инжиниринга, где использование спиральной модели уже получило популярность.



Состав команды по разработке ПО

КТО ДОЛЖЕН ВХОДИТЬ В СОСТАВ КОМАНДЫ?
0.
Заказчик - Эта роль принадлежит представителю организации, заказавшей разрабатываемую систему.
Обычно заказчик общается только с менеджерами проекта и специалистом по сертификации или
внедрению. Обычно заказчик имеет право изменять требования к продукту (только во взаимодействии с
менеджерами), читать проектную и сертификационную документацию, затрагивающую нетехнические
особенности разрабатываемой системы.
1.
Менеджер проекта (ProjectManager) - Эта роль обеспечивает коммуникационный канал между заказчиком
и проектной группой.
Менеджер проекта
 управляет ожиданиями заказчика
 разрабатывает и поддерживает бизнес-контекст проекта.
 Developing the project plan
 Managing the project team
 Managing the project risk
 Managing the project schedule
 Managing the project budget
8
Lecture 2
1/23/2016 6:51:00 PM
Его работа не связана напрямую с продажей продукта, он сфокусирован на продукте, его задача определить и обеспечить требования заказчика.
Менеджер проекта имеет право изменять требования к продукту и финальную документацию на продукт.
В задачи ProjectManager’a входит оперирование «ценой», «временем» и «качеством».
Часто ProjectManager’ом является представитель заказчика.
В компитенцию Project Manager’a входит принятие решения о закрытии/завершении проекта.
Понятие “ProjectManager” часто используется чтобы вобщем описать человека, принимающего
отвественность за проект и имеющего право завершить проект.
2.
Менеджер продукта (ProductManager)
Человек на этой роли управляет
 коммуникациями и взаимоотношениями в проектной группе, является в некотором роде
координатором

разрабатывает функциональные спецификации и управляет ими

ведет график проекта и отчитывается по состоянию проекта

инициирует принятие критичных для хода проекта решений.
Менеджер программы имеет право изменять функциональные спецификации верхнего уровня, план-график
проекта, распределение ресурсов по задачам. Часто на практике роль менеджера проекта и менеджера
программы выполняет один человек.
В задачи ProductManager’aвходит создание specifications основываясь на requirements.
3.
Business Analyst
Отвечает за сбор документации по требованиям к продукту (requirements) и перевод их в функциональные
спецификации, которые могли бы быть закодированы программистами.
4.
Architect
Ключевая обязанность архитектора — проектирование архитектуры ПО, т.е. принятие ключевых проектных
решений относительно внутреннего устройства программной системы и её технических интерфейсов
В проектирование архитектуры ПО, которым занимается Architect входят следующие задачи:
 разбиение на технические подсистемы/слои/компоненты/модули
 выбор средств исполнения
 разработка ключевых технических сценариев взаимодействия компонентов
 определение форматов хранения и передачи данных, протоколов передачи данных
 разработка стандартов кодирования/проектирования
5.
Team Lead (есть как в development team так и в QA team)
Возглавляет комманду или часть команды, координатор и экпсерт.
 Распределение задач среди членов команды с учётом сроков
 Оценка запланированых ресурсов и координация выданными ресурсами
 Контроль исполнения поставленых задач
 Решение технических и организационных вопросов команды
 Обучение и инструктаж команды по продукту
 Построение репортов по выполненым задачам
6.
Developer
9
Lecture 2
1/23/2016 6:51:00 PM
Разработчик принимает технические решения, которые могут быть реализованы и использованы, создает
продукт, удовлетворяющий спецификациям и ожиданиям заказчика, консультирует другие роли в ходе
проекта. Он участвует в обзорах, реализует возможности продукта, участвует в создании функциональных
спецификаций, отслеживает и исправляет ошибки за приемлемое время. В контексте конкретного проекта
роль разработчика может подразумевать, например, инсталляцию программного обеспечения, настройку
продукта или услуги. Разработчик имеет доступ ко всей проектной документации, включая документацию по
тестированию, имеет право на изменение программного кода системы в рамках своих служебных
обязанностей.
7.
QA
Обеспечивает качество продукта заявленным требованиям.
Остновимся подробнее на должностях, которые могут присутствовать в QA:
Test Manager (test leader) – обладает знаниями и опытом по всем подходам тестирования, занимается
координацией процессов тестирования и управлением персоналом:
1.
2.
3.
4.
5.
6.
7.
8.
Распределение задач среди членов команды с учётом сроков
Оценка запланированых ресурсов и координация выданными ресурсами
Контроль исполнения поставленых задач
Решение технических и организационных вопросов команды
Обучение и инструктаж команды по продукту
Построение репортов по выполненым задачам
+Определение подходящих тестовых стратений и методо
+Определение необходимого тестового инструментария
Test designer (test analyst) – эксперт в методах тестирования и понимании спецификаций продукта. Обладает
практическим опытом в тестировании. В задачи входит:
1. Анализ и изучение спецификаций, структуры и компонентов для определения
возможностей/областей тестирования и создания тест-кейсов.
2. Создание спецификаций
3. Подготовка и запрос необходимых материалов для тестирования/создания тест кейсов (сценариев)
Test automator – обладает знаниями по основам тестирования, опытом в программировании и хорошим
знанием инструменов (tools) для тестирования, скриптинг языков. На проекте отвечают за
применение/разработку автоматических инструментов для тестирования продукта.
Test Administrator – экперт по установке/настройке тестовой среды. Координирует работы системных
администраторов
Tester – эксперт в выполнении тестов и создании репортов про результатам тестирования.
1. Изучение тест планов и тест кейсов
2. Применение автоматических инструментов в тестированиии
3. Исполнение тестов
4. Документирование результатов (репорт)
8. Ops (IT operations) – отвечают за техническую поддержку проекта : настройка серверов, подготовка среды
тестирования.
10