 |
Классический жизненный цикл разработки ПО
|
|
|
|
Лекция №2. Тестирование как один из этапов жизненного цикла разработки программного обеспечения
Жизненный цикл разработки программного обеспечения
Жизненный цикл программного обеспечения (ПО) – период времени, который начинается с момента принятия решения о необходимости создания ПО и заканчивается в момент его полного изъятия из эксплуатации.
Жизненный цикл ПО представляет совокупность итерационных процедур, связанных с последовательным изменением состояния ПО.
Разработка – это только один из процессов, связанных с программной системой. Разработка также имеет свой жизненный цикл.
Жизненный цикл разработки ПО – период времени, начинающийся с формирования общего представления о разрабатываемой системе и его формализации в виде требований верхнего уровня и завершаемый вводом системы в эксплуатацию. Этап сопровождения программной системы также часто включают в жизненный цикл разработки ПО.
Модели жизненного цикла разработки
Коллективная разработка, в отличие от индивидуальной, требует четкого планирования работ и их распределения во время создания программной системы. Один из способов организации работ состоит в разбиении процесса разработки на отдельные последовательные стадии, после полного прохождения которых получается конечный продукт или его часть. Такие стадии и образуют жизненный цикл разработки ПО.
Любой этап жизненного цикла имеет четко определенные критерии начала и окончания. Состав этапов жизненного цикла, а также критерии, определяющие последовательность этапов жизненного цикла, задаются коллективом разработчиков и/или заказчиком. В настоящее время существует несколько основных моделей жизненного цикла, которые могут быть адаптированы под реальную разработку.
|
|
|
Модель жизненного цикла разработки ПО – структура, систематизирующая различные виды проектной деятельности, их взаимодействие и последовательность в процессе разработки ПО. Выбор той или иной модели зависит от масштаба и сложности проекта, предметной области, доступных ресурсов, планируемой частоты внесения изменений в систему, сроков разработки и других факторов.
Выбор модели жизненного цикла разработки ПО серьезно влияет на процесс тестирования, определяя выбор стратегии, расписание, необходимые ресурсы и т.д.
Классический жизненный цикл разработки ПО
Старейшей моделью процесса разработки ПО является классический жизненный цикл, который также называют каскадной или водопадноймоделью, подчеркивая, что разработка рассматривается как последовательность этапов, причем переход на следующий, иерархически нижний этап, происходит только после полного завершения работ на предыдущем этапе (рис. 1).
Рис. 1 Классический жизненный цикл разработки ПО
Подразумевается, что разработка начинается с заключения контракта с заказчиком (подготовка) и проходит через планирование, моделирование, конструирование и развертывание.
Подготовка обеспечивает активное взаимодействие с потенциальным заказчиком. Помимо оформления контракта, здесь собираются и формируются требования, определяющие характеристики и функции будущей программной системы. В процессе сбора требований необходим интенсивный диалог с заказчиком. Фактически эти требования определяют полное задание на разработку.
На этапе планирования проекта определяется объем будущих работ и их риск, необходимые трудозатраты, формируются рабочие задачи и расписание (план-график работ).
Моделирование включает в себя два действия – анализ требований и проектирование. Результаты этих действий – модели – обычно записываются на графическом языке моделирования, т.е. языке схем.
|
|
|
В ходе анализа требований происходит обработка набора требований к ПО, сформированных на этапе подготовки. Уточняются и детализируются функции, характеристики и интерфейс ПО. Все текстовые определения и модели документируются в спецификации анализа.
Проектирование состоит в создании представлений: архитектуры ПО; структурной и поведенческой организации частей архитектуры; входного и выходного интерфейса частей архитектуры (входных и выходных форм данных).
Архитектура ПО определяет организационную структуру программной системы, задает ее разбиение на части, связи между этими частями, механизмы взаимодействия и основные руководящие принципы для детализации дальнейшего проектирования системы.
Например, решение создавать программный продукт в виде системы, имеющей два уровня, каждый из которых содержит свои подсистемы, определенным образом сообщающиеся между собой, относится к архитектуре.
Исходные данные для проектирования содержатся в спецификации анализа. По сути, в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений.
Конструирование включает в себя кодирование и тестирование.
Кодирование, называемое также программированием или реализацией, состоит в переводе результатов проектирования в текст на языке программирования.
Тестирование – проверка соответствия программного кода требованиям, определенным на предыдущих этапах, включающая выполнение программы для выявления ошибок в функциях, логике и форме реализации программного продукта. Если ошибки выявлены, то запускается отладка, цель которой – устранить ошибки.
Развертывание включает в себя поставку разработанного продукта заказчику и сопровождение процесса эксплуатации этого продукта.
Сопровождение –это внесение изменений в эксплуатируемое ПО. Цели изменений: исправление ошибок; адаптация к изменениям внешней для ПО среды; усовершенствование ПО согласно требованиям заказчика.
Адаптация требуется, например, если заказчик хочет использовать продукт с другой операционной системой, а усовершенствование состоит или в расширении функциональности продукта, или в изменении каких-то характеристик (например, в ускорении реакции на запросы пользователей).
|
|
|
Сопровождение ПО заключается в повторном применении одного (или нескольких) из предшествующих шагов (этапов) жизненного цикла к существующему ПО, но не в разработке нового ПО. Такая возможность показана на рис. 1 стрелками обратных связей.
Достоинства классического жизненного цикла: дает план и временной график по всем этапам проекта, упорядочивает ход разработки.
Недостатки классического жизненного цикла:
– реальные проекты часто требуют отклонения от стандартной последовательности шагов;
– цикл основан на точной формулировке исходных требований к ПО (реально в начале проекта требования заказчика определены лишь частично);
– результаты проекта доступны заказчику только в конце работы;
– участие пользователей ПО либо не предусмотрено вообще, либо предусмотрено лишь косвенно на стадии однократного сбора требований.
Естественно, что в случае достаточно больших систем такой подход себя не оправдывает. Работа на каждом этапе занимает значительное время, а внесение изменений в первичные документы либо невозможно, либо вызывает лавинообразные изменения на всех других этапах.
Как правило, используется модификация каскадной модели, допускающая возврат на любой из ранее выполненных этапов. При этом фактически возникает дополнительная процедура принятия решения.
Если тест-кейсы обнаружили несоответствие реализации требованиям, то причина может находиться: в неправильном тесте; в ошибке кодирования (реализации); в неверной архитектуре системы; в некорректности требований к ПО и т.д. Все эти случаи требуют анализа, для того чтобы принять решение о том, на какой этап жизненного цикла надо возвратиться для устранения обнаруженного несоответствия.
Часть недостатков каскадной модели устраняет V-образный жизненный цикл – модель жизненного цикла, содержащая процессы двух видов: основные процессы разработки, аналогичные процессам каскадной модели, и процессы верификации, представляющие цепь обратной связи по отношению к основным процессам.
|
|
|
Таким образом, в конце каждого этапа жизненного цикла разработки, а зачастую и в процессе выполнения этапа, осуществляется проверка взаимной корректности требований различных уровней. Данная модель позволяет более оперативно проверять корректность разработки, однако, как и в каскадной модели, предполагается, что на каждом этапе разрабатываются документы, описывающие поведение всей системы в целом.
Макетирование
Достаточно часто заказчик не может сформулировать подробные требования по вводу, обработке или выводу данных для будущего программного продукта. С другой стороны, разработчик может сомневаться в приспосабливаемости продукта под операционную систему, форме диалога с пользователем или в эффективности реализуемого алгоритма. В этих случаях целесообразно использовать макетирование.
Макетирование (прототипирование) – это процесс создания модели требуемого программного продукта. Основная цель макетирования – снять неопределенности в требованиях заказчика.
Модель может принимать одну из трех форм:
1) бумажный макет или макет, выполненный на компьютере (изображает человеко-машинный диалог);
2) работающий макет (выполняет некоторую часть требуемых функций);
3) существующая программа (характеристики которой затем должны быть улучшены).
Как показано на рис. 2, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.
Рис. 2 Макетирование
Последовательность действий при макетировании представлена на рис. 3 в виде диаграммы деятельности языка UML.
Макетирование начинается со сбора и уточнения требований к ПО. Разработчик и заказчик встречаются и определяют все цели ПО, устанавливают, какие требования известны, а какие предстоит доопределить.
Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю. Быстрое проектирование приводит к построению макета. Макет оценивается заказчиком и используется для уточнения требований к ПО.
Рис. 3 Последовательность действий при макетировании
Итерации повторяются до тех пор, пока макет не выявит все требования заказчика и, тем самым, не даст возможность разработчику понять, что должно быть сделано.
Достоинство макетирования: обеспечивает определение полных требований к ПО.
Недостатки макетирования:
– заказчик, видя работающую версию системы, может потребовать быстро преобразовать ее в рабочий продукт, но при этом остаются нерешенными вопросы качества и удобства сопровождения;
|
|
|
– для быстрого получения работающего макета разработчик часто идет на определенные компромиссы (например, используя не самый подходящий язык программирования или неэффективный алгоритм), и, спустя некоторое время, может не исправить это в рабочем продукте, забыв о причинах, по которым выбранные изначально средства не подходят.
Спиральная модель
Спиральная модель – это классический пример применения эволюционной стратегии разработки. При использовании эволюционной стратегии система строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий.
Спиральная модель базируется на лучших свойствах классического жизненного цикла и макетирования, к которым добавляется новый элемент – анализ риска, отсутствующий в этих моделях.
Как показано на рис. 4, модель определяет четыре действия, представляемые четырьмя квадрантами спирали: подготовка – сбор требований и ограничений; планирование – формирование плана проекта и анализ риска; моделирование и конструирование – подготовка моделей и реализация продукта следующего уровня; развертывание – оценка заказчиком текущей версии продукта.
Рис. 4 Спиральная модель: начальный сбор требований проекта (1); та же работа, но на основе рекомендаций заказчика (2); планирование проекта и анализ риска на основе начальных требований (3); планирование и анализ риска на основе реакции заказчика (4); переход к комплексной системе (5); построение начального макета системы (6); построение версии системы следующего уровня (7); оценивание заказчиком (8).
В спиральной модели разработка системы происходит повторяющимися этапами – витками спирали – и отображается (рис. 4) движением по разворачивающейся спирали (по часовой стрелке), причем проект стартует в первом квадранте.
В конце каждого витка получается законченная версия системы, реализующая некоторый набор функций. Затем она предъявляется пользователю, на следующий виток переносится вся документация, разработанная на предыдущем витке, и процесс повторяется.
С каждой итерацией по спирали (продвижением от центра к периферии) строятся все более полные версии ПО. Таким образом, система разрабатывается постепенно, проходя постоянные согласования с заказчиком. На каждом витке спирали функциональность системы расширяется, постепенно дорастая до полной.
В каждом витке по спирали результаты анализа риска формируются в виде «продолжать, не продолжать». Если риск слишком велик, проект может быть остановлен. В большинстве случаев движение по спирали продолжается, с каждым шагом продвигая разработчиков к более общей версии системы.
Достоинства спиральной модели:
– наиболее реально (в виде эволюции) отображает разработку ПО;
– позволяет явно учитывать риск на каждом витке эволюции разработки;
– включает возможность оценки системы в итерационную структуру разработки;
Недостатки спиральной модели:
– повышенные требования к заказчику;
– трудности контроля и управления временем разработки.
С точки зрения тестирования и управления качеством повышенное внимание рискам является ощутимым преимуществом при использовании спиральной модели для разработки концептуальных проектов, в которых требования естественным образом являются сложными и нестабильными (могут многократно меняться по ходу выполнения проекта).
|
|
|
