Главная страница Случайная страница
Разделы сайта
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника
Часть I. Процесс быстрого тестирования. • Успешное совершенствование процесса затрагивает людей, которые с ним свя заны
|
|
• Успешное совершенствование процесса затрагивает людей, которые с ним свя заны. Организация процесса того или иного процесса — это далеко не академи ческое или техническое мероприятие; она требует от персонала внести опре деленные коррективы в свои рабочие обязанности и заставляет руководство пересмотреть свои взгляды на то, что можно ожидать от подчиненных. Для то го чтобы любая инициатива, касающаяся улучшения процесса, оказалась ус пешной, в ее реализацию должны вносить посильный вклад все службы компа нии, от высшего руководства до исполнителей, занимающихся прогоном тес тов в испытательной лаборатории. Как только процесс будет определен, пер сонал, которому надлежит его использовать, должен пройти специальную под готовку, дабы достичь необходимого уровня согласованности и производи тельности.
Первый пункт, утверждающий, что процесс тестирования не является независи мым, очевиден на протяжении всего жизненного цикла разработки. В качестве' при мера взаимной функциональной зависимости рассмотрим процесс выявления и фор мулирования технических требований. Как уже говорилось в предыдущих главах, тестирование должно начинаться с проверки формулировок требований. Формули рование требований представляет собой широкую межфункциональную деятель ность, в которой принимают участие представители руководства высшего уровня, групп маркетинга, разработчиков, производителей и поддержки на стороне заказчи ка. Представители других групп, кроме группы маркетинга, могут не принимать уча стие в прямом обмене данными с заказчиком; в то же время совершенно ясно, что сформулированные требования оказывают влияние на работу всей группы разработ ки программного продукта.
Вторая особенность, связанная с тем, что эффективный процесс может строиться только постепенно, от стадии к стадии, рассматривается ниже, в контексте модели развития функциональных возможностей. Мы не будем исследовать все уровни и ключевые области процесса тестирования сквозь призму модели СММ, тем не менее, сосредоточимся на тех областях СММ, которые имеют отношение к принципам про цессам тестирования, которые рассматриваются в данной книге. Упомянутые выше модели развития подробно рассматриваются в [19], [41], [38] и [29].
Третий пункт показывает, каким путем достигается совершенствование процесса тестирования. Исследованию этих вопросов посвящена завершающая часть данной главы.
Модель развития функциональных возможностей программного обеспечения СММ
Институт технологий программного обеспечения SEI (Software Engineering Institute) — это проектно-исследовательская организация, основанная в 1984 году Ми нистерством обороны США и финансируемая федеральным правительством США. Она поддерживается университетом Карнеги-Меллон. Информацию, касающуюся института SEI и модели СММ, можно получить на Web-сайте института SEI по адресу: www. sei.cmu. edu.
Модель развития функциональных возможностей является основой, которая мо жет использоваться для получения оценки, в какой степени заданная организация
| Глава 6. Вопросы объединения процессов тестирования... |
способна изготовлять программное обеспечение. Она классифицирует процесс раз работки программного обеспечения по пяти уровням развития: начальный, повто ряемый, определяемый, управляемый и оптимизирующий. Краткие характеристики каждого из этих уровней приводятся в таблице 6.1.
Характеристики, перечисленные в таблице 6.1, описывают ключевые свойства уровней 1-5. Уровень детализации, предложенный в таблице 6.1, намеренно выбран низким. Подобный выбор обусловлен необходимостью дать общее представление об организациях, находящихся на каждом из пяти уровней. Например, организация, расположенная на уровне 1 модели СММ, т.е. на начальном уровне, разрабатывает программное обеспечение с использованием неопределенных и непланируемых про цессов. Скорее всего, эта организация не способна соблюдать сроки разработки, об наруживать и устранять все дефекты программного продукта перед его выпуском и укладываться в рамки сметной стоимости. Организации, достигшие уровня 2 модели СММ, вложили существенные средства в совершенствование реализуемых ими про цессов, и во время планирования, оценки и составления календарных планов руково дствуются четкими принципами управления ходом проектирования, тем самым дос тигая поставленных целей. Можно вполне рассчитывать на то, что организации вто рого уровня, по сравнению с организациями первого уровня, лучше справляются с задачами соблюдения срока разработки, обнаружения и исправления дефектов, рав но как и более точно управляют окончательной стоимостью проекта.
По сравнению с хаосом, присутствующим на уровне 1, уровень 3 привносит суще ственные улучшения. На уровне 3, т.е. на определяемом уровне, тестирующая органи зация, скорее всего, реализует большую часть методов, обсуждаемых в данной книге, а именно: управление требованиями, достоверные оценки, составление графиков работ, управление конфигурациями, а также инспекции и пересмотры. Согласно мо дели СММ, определяемый уровень представляет собой высокий уровень эффектив ности организации, однако управление процессом осуществляется скорее на основе качественных, а не количественных оценок. На этом уровне все еще не установлены надежные системы измерений, пригодные для оценки качества программного про дукта или эффективности процесса.
Два последних уровня модели СММ предусматривают плановые и текущие изме рения качества продукта и эффективности процесса. Основные различия между уровнями 4 и 5 заключаются в том, что основное внимание на уровне 5 уделяется не качеству программного продукта, а эффективности процессов. Продвижение к уров ню 5 означает, что организация собрала достаточное количество данных, позволяю щих ей воспользоваться средствами настройки своих процессов на достижение оп тимальной эффективности. Одним из ключевых свойств уровней 4 и 5 является при менение метрик тестирования. Использование упомянутых метрик подробно обсуж дается в главе 11.
В дополнение к описанию пяти уровней функционального развития организаций, занимающихся разработкой программного обеспечения, модель СММ определяет 18 областей обработки, распределенных по всем пяти уровням. Области КРА (Key Proc ess Areas— ключевые области обработки) для заданного уровня функционального развития суть полностью действующие процессы, которые в любой момент времени должны находиться в полной функциональной готовности. Они направлены на то, чтобы организация могла претендовать на соответствующий уровень.
152 Часть I. Процесс быстрого тестирования
Таблица 6.1. Характеристики модели развития функциональных возможностей
| Уровень | Наименование | |
| развития | уровня | Характеристики |
| Уровень 1 | Начальный | В большинстве случаев процесс не определен и не рассчитан |
| на серийное производство. Как правило, отсутствуют форма | ||
| лизованные процедуры, планы проектов, а сметы не состав | ||
| ляются. Если все же такие процедуры существуют, то отсутст | ||
| вует такой механизм управления, который обеспечил бы их | ||
| использование. В критических ситуациях формальные проце | ||
| дуры не используются. Контроль внесения изменений практи | ||
| чески отсутствует. Кодирование и тестирование выполняются | ||
| без определенного плана. Проекты, пересмотры и анализ ре | ||
| зультатов тестирования считаются непозволительной роско | ||
| шью. Руководство организации имеет смутное представление | ||
| о проблемах. | ||
| Уровень 2 | Повторяемый | Разработка ведется в соответствии с планом. Установлена |
| система управления проектом, обеспечивающая поддержку | ||
| планирования и отслеживания. Организована группа обеспе | ||
| чения качества, дающая гарантию руководству, что работа | ||
| ведется в рамках заданного процесса и в соответствии с пла | ||
| ном. Для программного обеспечения проводится контроль | ||
| внесения изменений. Сметные требования и требования со | ||
| блюдения графиков работ поддерживаются до тех пор, пока не | ||
| внедряются новые инструментальные средства и новые мето | ||
| ды, и если не предпринимаются крупные изменения внутри | ||
| самой организации. | ||
| Уровень 3 | Определяемый | В процессы, реализуемые на уровне 2, вносятся дополнитель |
| ные усовершенствования. Организуется группа поддержки | ||
| процесса, которая сопровождает совершенствование текущего | ||
| процесса. Определен жизненный цикл разработки, который | ||
| приводится к конкретным нуждам организации и к текущему | ||
| проекту. Постоянно применяется семейство методов проекти | ||
| рования, в числе которых методы формального проектирова | ||
| ния и методы тестирования. Организация, поднявшаяся до | ||
| этого уровня, приобретает фундамент, обеспечивающий серь | ||
| езное и долгосрочное развитие. Однако каким бы ни был эф | ||
| фективным этот уровень, он остается качественным уровнем. | ||
| На этом уровне существует мало средств для количественной | ||
| оценки того, что делается, и насколько эффективным оказы | ||
| вается процесс. | ||
| Уровень 4 | Управляемый | В дополнение к усовершенствованиям, внесенным на преды |
| дущем уровне, реализуется целый ряд измерений с целью | ||
| предоставления возможности выдать количественную оценку | ||
| стоимости и достоинств главного процесса. Устанавливается и | ||
| поддерживается база данных процесса. Отслеживается про | ||
| движение в направлении достижения целей качества для кон | ||
| кретных программных продуктов, причем соответствующие | ||
| сведения направляются руководству. Основное внимание на | ||
| этом, впрочем, как и на всех предыдущих уровнях, уделяется | ||
| качеству продукта. |
| Глава 6. Вопросы объединения процессов тестирования... | ||||
| Окончание табл. 6.1 | ||||
| Уровень | Наименование | |||
| развития | уровня | Характеристики | ||
| Уровень 5 | Оптимизирую- | На этом уровне происходит смещение акцентов. Основное | ||
| щий | внимание теперь уделяется не качеству программного продук |
та, но оптимизации процесса. На этом уровне становятся дос тупными данные, которые можно использовать для настройки самого процесса, т.е. можно не принимать во внимание огра ничения, накладываемые одним или двумя какими-либо проек тами. На оптимизирующем уровне организация получает в свое распоряжение средства, позволяющие выявлять и ис правлять наиболее слабые элементы процесса.
Например, названиями областей КРА для уровня 2 [38] являются:
• Управление требованиями
• Планирование проекта программного обеспечения
• Контроль и отслеживание разработки проекта программного обеспечения
• Управление договорами с субподрядчиками на разработку программного обес печения
• Обеспечение качества программного обеспечения
• Управление конфигурацией программного обеспечения.
Подробное описание областей КРА мы оставляем на публикации, посвященные моделям СММ. В то же время может оказаться полезным концептуальное отображе ние областей КРА уровня 2 на процессы тестирования, описание которых было дано в предыдущих главах настоящей книги. Попытка такого отображения предпринима ется в следующем разделе.
|
|