Принципы тестирования - Лекция, раздел Программирование, Учебное пособие про этапы разработки программного обеспечения Сформулируем Основные Принципы Тестирования, Используя Главную Предпосылку На...
Сформулируем основные принципы тестирования, используя главную предпосылку настоящего раздела о том, что наиболее важными в тестировании программ являются вопросы психологии. Эти принципы интересны тем, что в основном они интуитивно ясны, но, в то же время, на них часто не обращают должного внимания.
Описание предполагаемых значений выходных данных или результатов должно быть необходимой частью тестового набора.
Нарушение этого очевидного принципа представляет одну из наиболее распространенных ошибок. Ошибочные, но правдоподобные результаты могут быть признаны правильными, если результаты теста не были заранее определены. Здесь мы сталкиваемся с явлением психологии: мы видим то, что мы хотим увидеть. Другими словами, несмотря на то, что тестирование по определению — деструктивный процесс, есть подсознательное желание видеть корректный результат. Один из способов борьбы с этим состоит в поощрении детального анализа выходных переменных заранее при разработке теста. Поэтому тест должен включать две компоненты: описание входных данных и описание точного и корректного результата, соответствующего набору входных данных.
Необходимость этого подчеркивал логик Копи: «Проблема может быть охарактеризована как факт или группа фактов, которые не имеют приемлемого объяснения, кажутся необычными или которые не удается подогнать под наши представления или предположения. Очевидно, что если что-нибудь подвергается сомнению, то об этом должна иметься какая-то предварительная информация. Если нет предположений, то не может быть и неожиданных результатов».
Следует избегать тестирования программы ее автором.
Этот принцип следует из обсуждавшихся ранее положений, которые определяют тестирование как деструктивный процесс. После выполнения конструктивной части, при проектировании и написании программы трудно быстро (в течение одного дня) перестроиться на деструктивный образ мышления. Многие, кому приходилось самому делать дома ремонт, знают, что процесс обрывания старых обоев (деструктивный процесс) нелегок, но он просто невыносим, если не кто-то другой, а вы сами первоначально их наклеивали. Вот так же и большинство программистов не могут эффективно тестировать свои программы, потому что им трудно демонстрировать собственные ошибки.
В дополнение к этой психологической проблеме следует отметить еще одну, не менее важную: программа может содержать ошибки, связанные с неверным пониманием постановки или описания задачи программистом. Тогда существует вероятность, что к тестированию программист приступит с таким же недопониманием своей задачи.
Тестирование можно уподобить работе корректора или рецензента над статьей или книгой. Многие авторы представляют себе трудности, связанные с редактированием собственной рукописи. Очевидно, что обнаружение недостатков в своей деятельности противоречит человеческой психологии.
Отсюда вовсе не следует, что программист не может тестировать свою программу. Здесь лишь делается вывод о том, что тестирование является более эффективным, если оно выполняется кем-либо другим. Заметим, что все наши рассуждения не относятся к отладке, т.е. к исправлению уже известных ошибок. Эта работа эффективнее выполняется самим автором программы.
Программирующая организация не должна сама тестировать разработанные ею программы.
Здесь можно привести те же аргументы, что и в предыдущем случае. Во многих смыслах проектирующая или программирующая организация подобна живому организму с его психологическими проблемами. Работа программирующей организации или ее руководителя оценивается по их способности производить программы в течение заданного времени и определенной стоимости. Одна из причин такой системы оценок состоит в том, что временные и стоимостные показатели легко измерить, но в то же время чрезвычайно трудно количественно оценить надежность программы. Именно поэтому в процессе тестирования программирующей организации трудно быть объективной, поскольку тестирование в соответствии с данным определением может быть рассмотрено как средство уменьшения вероятности соответствия программы заданным временным и стоимостным параметрам.
Как и ранее, из изложенного не следует, что программирующая организация не может найти свои ошибки; тестирование в определенной степени может пройти успешно. Мы утверждаем здесь лишь то, что экономически более целесообразно выполнение тестирования каким-либо объективным, независимым подразделением.
Необходимо досконально изучать результаты применения каждого теста.
По всей вероятности, это наиболее очевидный принцип, но и ему часто не уделяется должное внимание. В проведенных экспериментах многие испытуемые не смогли обнаружить определенные ошибки, хотя их признаки были совершенно явными в выходных листингах. Представляется достоверным, что значительная часть всех обнаруженных в конечном итоге ошибок могла быть выявлена в результате самых первых тестовых прогонов, но они были пропущены вследствие недостаточно тщательного анализа результатов первого тестового прогона.
Тесты для неправильных и непредусмотренных входных данных следует разрабатывать так же тщательно, как для правильных и предусмотренных.
При тестировании программ имеется естественная тенденция концентрировать внимание на правильных и предусмотренных входных условиях, а неправильным и непредусмотренным входным данным не придавать значения. Например, при тестировании задачи о треугольниках, приведенной в п. 6.2.1, лишь немногие смогут привести в качестве теста длины сторон 1, 2 и 5, чтобы убедиться в том, что треугольник не будет ошибочно интерпретирован как неравносторонний. Множество ошибок можно также обнаружить, если использовать программу новым, не предусмотренным ранее способом. Вполне вероятно, что тесты, представляющие неверные и неправильные входные данные, обладают большей обнаруживающей способностью, чем тесты, соответствующие корректным входным данным.
Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она то, что не должна делать.
Это логически просто вытекает из предыдущего принципа. Необходимо проверить программу на нежелательные побочные эффекты. Например, программа расчета зарплаты, которая производит правильные платежные чеки, окажется неверной, если она произведет лишние чеки для работающих или дважды запишет первую запись в список личного состава.
Не следует выбрасывать тесты, даже если программа уже не нужна.
Эта проблема наиболее часто возникает при использовании интерактивных систем отладки. Обычно тестирующий сидит за терминалом, на лету придумывает тесты и запускает программу на выполнение. При такой практике работы после применения тесты пропадают. После внесения изменений или исправления ошибок необходимо повторять тестирование, тогда приходится заново изобретать тесты. Как правило, этого стараются избегать, поскольку повторное создание тестов требует значительной работы. В результате повторное тестирование бывает менее тщательным, чем первоначальное, т.е. если модификация затронула функциональную часть программы и при этом была допущена ошибка, то она зачастую может остаться необнаруженной.
Нельзя планировать тестирование в предположении, что ошибки не будут обнаружены.
Такую ошибку обычно допускают руководители проекта, использующие неверное определение тестирования как процесса демонстрации отсутствия ошибок в программе, корректного функционирования программы.
Вероятность наличия необнаруженных ошибок в части программы пропорциональна числу ошибок, уже обнаруженных в этой части.
Этот принцип, не согласующийся с интуитивным представлением, иллюстрируется рис. 6.2.
Рис. 6.2 — Неожиданное соотношение числа оставшихся и числа обнаруженных ошибок
На первый взгляд он лишен смысла, но тем не менее подтверждается многими программами. Например, допустим, что некоторая программа состоит из модулей A и B. К определенному сроку в модуле A обнаружено пять ошибок, а в модуле B — только одна, причем модуль A не подвергался более тщательному тестированию.
Тогда из рассматриваемого принципа следует, что вероятность необнаруженных ошибок в модуле A больше, чем в модуле B. Справедливость этого принципа подтверждается еще и тем, что для ошибок свойственно располагаться в программе в виде неких скоплений, хотя данное явление пока никем еще не объяснено. В качестве примера можно рассмотреть операционные системы IBM S/370. В одной из версий операционной системы 47 % ошибок, обнаруженных пользователями, приходилось на 4 % модулей системы.
Преимущество рассматриваемого принципа заключается в том, что он позволяет ввести обратную связь в процесс тестирования. Если в какой-нибудь части программы обнаружено больше ошибок, чем в других, то на ее тестирование должны быть направлены дополнительные усилия.
Тестирование — процесс творческий.
Вполне вероятно, что для тестирования большой программы требуется больший творческий потенциал, чем для ее проектирования. Выше было показано, что нельзя дать гарантию построения теста, обнаруживающего все ошибки. В дальнейшем здесь будут обсуждаться методы построения хороших наборов тестов, но применение этих методов должно быть творческим.
Чтобы подчеркнуть некоторые мысли, высказанные в настоящем разделе, приведем еще раз три наиболее важных принципа тестирования.
Тестирование — это процесс выполнения программ с целью обнаружения ошибок.
Хорошим считается тест, который имеет высокую вероятность обнаружения еще не выявленной ошибки.
Удачным считается тест, который обнаруживает еще не выявленную ошибку.
Все темы данного раздела:
Этапы разработки программного обеспечения
Естественно, что отдельный человек не в состоянии полностью осмыслить и построить программное обеспечение большой системы. Для управления ходом разработки больших программных систем выделяются шест
Анализ требований, предъявляемых к системе
На первом этапе, часто неоправданно опускаемом, определяются требования, которые позволяют получить приемлемое решение проблемы. На этом этапе формулируются целевое назначение и основные свойства р
Определение спецификаций
На этапе определения спецификаций осуществляется точное описание функций, реализуемых ЭВМ, а также задаются структура входных и выходных данных, методы и средства их размещения. Определяются алгори
Проектирование
На стадии проектирования разрабатываются алгоритмы, задаваемые спецификациями, и формируется общая структура вычислительной системы. При этом система разбивается (при необходимости) на составные ча
Кодирование
Данный этап является наиболее простым, а его реализация существенно облегчается при использовании алгоритмических языков высокого уровня. Кодирование — это этап разработки программного обеспечения,
Тестирование
Этап тестирования обычно в финансовых затратах составляет половину расходов на создание системы. Плохо спланированное тестирование приводит к существенному увеличению сроков разработки системы и яв
Эксплуатация и сопровождение
С учетом затрат на эксплуатацию и сопровождение временные затраты на разработку программной системы можно представить так (рис. 2.5):
1) анализ требований;
2) определение специфик
Методы разработки программного обеспечения как научная дисциплина
Из приведенного нами обзора этапов разработки программного обеспечения ясно, что каждый этап разработки оказывает влияние на другие более ранние этапы (технология «синтез — анализ»). Так, процесс н
Методы управления разработкой
Руководитель проекта контролирует два основных ресурса — исполнителей и вычислительные средства. Следовательно, его основная цель — оптимизировать эти ресурсы. Успех разработки в сильной степени за
Выполнение проекта
Программное обеспечение обычно разбивают на три категории:
- управляющие программы (например, операционные системы — ОС);
- системные программы (например, компиляторы);
-
Методика инженерно-технической оценки затрат
Базовая методика оценки затрат заключается в следующем:
Шаг 1. Формируются общие требования к системе исходя из существующего технического задания. Потенциальных разработчиков информируют
Оценка на основе распределения Рэлея
В настоящее время некоторые результаты теории надежности аппаратных средств ЭВМ начинают использовать для оценки сроков и затрат при разработке программного обеспечения. Было установлено, что завис
Контрольные точки
Контрольные точки указывают на моменты завершения работ; они позволяют судить о состоянии разработки системы. Контрольные точки планируются руководителем проекта с целью осуществления контроля за р
Средства разработки
Компиляторы и отладочные средства известны уже достаточно давно. В настоящее время создано (и создается) ряд новых программных средств, помогающих разработке.
Среди таких средств следует
Надежность
Одним из основных параметров надежности разрабатываемой программной системы является концептуальная целостность, т.е. единообразие стиля и простота структуры. Обычно она достигается за счет минимиз
Методы проведения разработки программного обеспечения
Эти методы наиболее развиты, т.к. они относятся к области профессиональной деятельности программистов: кодирование, тестирование, отладка и др. Средства их проведения (решения) известны давно и дин
Язык определения задач и анализатор задач
Среди таких методов следует отметить разработку Мичиганского университета ISDOS, в состав которой входят две базовые составляющие:
1) язык описания задач PSL, предназначенный для отобр
Система структурного анализа и проектирования SADT
SADT — это аббревиатура марки фирмы Software Technology, представляет собой ручную графическую систему, предназначенную для проектирования больших программных комплексов. Графический язык системы S
Система SREM
Система SREM используется для автоматизации этапа анализа требований, предъявляемых к программному обеспечению. Она включает в себя язык определения требований (RSL), посредством которого устанавли
Методика Джексона
Разработанная М. Джексоном методика включает нисходящее проектирование, структурное программирование и структурный контрольный анализ. В соответствии с этой методикой строятся иерархически структур
Язык проектирования программ
При создании программ разработчики обычно используют два способа: либо составляют структурную схему программы, либо сразу пишут программу. Очевидно, что при втором способе структура программы навер
Нисходящее проектирование и нисходящая разработка
Язык программирования является лишь средством разработки проектов. Важное место в построении правильных проектов играет методология проектирования. При разработке программ на этапе проектирования о
Структурное проектирование
Одним из эффективных методов разработки программ является метод пошагового совершенствования. Использование PDL хорошо согласуется с этим методом. Программист обдумывает проект задачи все более дет
Обзор структур данных
Любая программа — это формальное описание решения некоторой задачи реального мира. Как часть этого решения конкретные данные тоже должны быть формализованы таким образом, чтобы программа могла пров
Очереди
Очередь — это упорядоченный список, в один конец которого элементы добавляются, а из другого изымаются (рис. 4.9, б). Очередь называют списком FIFO — Fist In, Fist Out (поступивший первым об
Множества
Множества — это совокупность переменных одного типа. Множество аналогично списку, за исключением того, что порядок расположения элементов не имеет значения. Множества обычно организуются как списки
Абстрактные конструкции
В современных языках программирования основное внимание уделяется структурам данных. Управляющие операторы остались почти такими же, какими они были в первых версиях языка ALGOL. Кроме использовани
Фиксированные типы данных абстрактного типа
Данный подход ориентирован на использование языков, «плохо» поддерживающих сложные структуры данных. При реализации такого подхода правильность проектирования программ зависит, главным образом, от
Размещение указателей
Используя переменные типа указатель, можно построить конструкцию, близкую к фиксированным данным абстрактного типа. Предполагается, что указатель указывает на область памяти, а формат этой памяти о
Защита данных от несанкционированного доступа
Этот способ организации данных подобен предыдущему, но содержит средства контроля для определения некорректных обращений. Для определения данных этого типа добавляется атрибут ENVIRONMENT (среда, о
Правильность программ
Одним из важных методов повышения эффективности проектирования программ является верификация программ или математическое доказательство того, что программа работает правильно. Для доказательства пр
Аксиомы
Для целей доказательства правильности программ к правилам исчисления предикатов следует добавить правила, необходимые для выполнения последовательности операторов программы. Эти правила, называемые
Доказательства правильности программ
Используя приведенные выше правила и аксиомы, можно осуществлять доказательство правильности программ. Рассмотрим следующую программу:
1. MULTIPLY (R,A,B);
2. declare X;
Психология и экономика тестирования программ
Тестирование как объект изучения может рассматриваться с различных, чисто технических, точек зрения. Однако наиболее важными при изучении тестирования представляются вопросы его экономики и психоло
Тестирование программы как черного ящика
Одним из способов изучения поставленного вопроса является исследование стратегии тестирования, называемой стратегией черного ящика, тестированием с управлением по данным или тестированием с управле
Тестирование программы как белого ящика
Стратегия белого ящика, или стратегия тестирования, управляемого логикой программы, позволяет исследовать внутреннюю структуру программы. В этом случае тестирующий получает тестовые данные путем
Ручное тестирование
В течение многих лет большинство программистов были убеждены в том, что программы пишутся исключительно для выполнения их на машине и не предназначены для чтения человеком, а единственным способом
Инспекции и сквозные просмотры
Инспекции исходного текста и сквозные просмотры являются основными методами ручного тестирования. Так как эти два метода имеют много общего, они рассматриваются здесь совместно. Различия между ними
Инспекции исходного текста
Инспекции исходного текста представляют собой набор процедур и приемов обнаружения ошибок при изучении (чтении) текста группой специалистов. При рассмотрении инспекций исходного текста внимание буд
Список вопросов для выявления ошибок при инспекции
Важной частью процесса инспектирования является проверка программы на наличие общих ошибок с помощью списка вопросов для выявления ошибок. Концентрация внимания в предлагаемом списке на рассмотрени
Ошибки обращения к данным
1. Существуют ли обращения к переменным, значения которым не присвоены или не инициализированы? Наличие переменных с не установленными значениями — наиболее часто встречающаяся программная ошибка,
Ошибки описания данных
1. Все ли переменные описаны явно? Отсутствие явного описания не обязательно является ошибкой, но служит общим источником беспокойства. Так, если в подпрограмме на Фортране используется элемент мас
Ошибки вычислений
1. Имеются ли вычисления, использующие переменные недопустимых (например, неарифметических) типов данных?
2. Существуют ли вычисления, использующие данные разного вида? Например, сложение
Ошибки при сравнениях
1. Сравниваются ли в программе величины, имеющие несовместимые типы данных (например, строка символов с адресом)?
2. Сравниваются ли величины различных типов или величины различной длины?
Ошибки в передачах управления
1. Если в программе содержится переключатель (например, вычисляемый оператор GO TO в Фортране или его аналог ON… GOTO в Бейсике), то может ли значение индекса когда-либо превысить число возможных
Ошибки интерфейса
1. Равно ли число параметров, получаемых рассматриваемым модулем, числу аргументов, передаваемых каждым из вызывающих модулей? Правилен ли порядок их следования?
2. Совпадают ли атрибуты (
Ошибки ввода-вывода
1. Являются ли правильными атрибуты файлов, описанных явно?
2. Являются ли правильными атрибуты оператора OPEN?
3. Согласуется ли спецификация формата с информацией в операторах в
Другие виды контроля
1. Если компилятор выдает таблицу перекрестных ссылок идентификаторов, проверьте величины, на которые в этом списке нет ссылок или есть только одна ссылка.
2. Если компилятор выдает список
Сквозные просмотры
Сквозной просмотр, как и инспекции, представляет собой набор процедур и способов обнаружения, осуществляемых группой лиц, просматривающих текст программы. Такой просмотр имеет много общего с проц
Оценка посредством просмотра
Последний ручной процесс обзора программы не связан с ее тестированием (т.е. целью его не является нахождение ошибок). Однако описание этого процесса приводится здесь потому, что он имеет отношение
Проектирование теста
Результаты психологических исследований, обсуждавшиеся в п. 6.2, показывают, что наибольшее внимание при тестировании программ уделяется проектированию или созданию эффективных тестов. Это связано
Покрытие решений
Более сильный критерий покрытия логики программы известен как покрытие решений, или покрытие переходов.
Согласно данному критерию должно быть записано достаточное число тестов, такое, что
Покрытие условий
Лучшим критерием по сравнению с предыдущим является покрытие условий. В этом случае записывают число тестов, достаточное для того, чтобы все возможные результаты каждого условия в решении выполняли
Комбинаторное покрытие условий
Критерием, который решает эти и некоторые другие проблемы, является комбинаторное покрытие условий. Он требует создания такого числа тестов, чтобы все возможные комбинации результатов условия в каж
Эквивалентное разбиение
В п. 6.2 отмечалось, что хороший тест имеет приемлемую вероятность обнаружения ошибки и что исчерпывающее входное тестирование программы невозможно. Следовательно, тестирование программы ограничива
Выделение классов эквивалентности
Классы эквивалентности выделяются путем выбора каждого входного условия (обычно это предложение или фраза в спецификации) и разбиением его на две или более групп. Для проведения этой операции испол
Построение тестов
Второй шаг заключается в использовании классов эквивалентности для построения тестов. Этот процесс включает в себя:
1. Назначение каждому классу эквивалентности уникального номера.
Анализ граничных значений
Как показывает опыт, тесты, исследующие граничные условия, приносят большую пользу, чем тесты, которые их не исследуют. Граничные условия — это ситуации, возникающие непосредственно на границах, а
Применение функциональных диаграмм
Одним из недостатков анализа граничных значений и эквивалентного разбиения является то, что они не исследуют комбинаций входных условий. Например, пусть программа MTEST из предыдущего раздела не вы
Предположение об ошибке
Замечено, что некоторые люди по своим качествам оказываются прекрасными специалистами по тестированию программ. Они обладают умением «выискивать» ошибки и без привлечения какой-либо методологии тес
Стратегия
Методологии проектирования тестов, обсуждавшиеся в этом разделе, могут быть объединены в общую стратегию. Причина объединения их теперь становится очевидной: каждый метод обеспечивает создание опре
Разбиение задачи на одинаковые по сложности части
Этот метод, как и первый, наиболее часто используется в программировании. Данный подход означает разделение задачи на подзадачи, равные примерно по сложности, для того чтобы перейти к решению значи
Рекурсия
Иногда возможно сформулировать решение задачи как известное преобразование другого, более простого, варианта той же задачи. Если этот процесс продолжить до тех пор, пока не получится нужное значени
Моделирование
Часто бывает невозможно получить точное решение задачи по соображениям стоимости, сложности или размера. Такие ситуации возникают при решении задач по управлению движением, экономическому прогнозир
Поиск в списках
Данный поиск проводится четырьмя различными способами: прямым, линейным, двоичным и хешированием.
Прямой поиск. При прямом поиске местоположение элемента определяется непосредственно с пом
Деревья поиска
Если данные организованы как структура дерева, алгоритм поиска сводится к алгоритму, просматривающему все узлы дерева. Для ведения поиска существуют два основных алгоритма поиска: поиск в глубину и
Стратегия распределения памяти
Одним из типов поиска являются задачи по распределению памяти (наиболее характерны они при создании ОС), однако во многих прикладных алгоритмах эти задачи возникают при создании прикладных программ
Сортировка
Сортировка — это процесс размещения элементов в списке в некоторой числовой или лексикографической последовательности (порядке). Различаются следующие виды сортировки.
Обменная сортировка.
Алгоритм выбора из конечного состояния
Часто задача может быть сведена к множеству действий, зависящих от текущего состояния программы. Такой способ решения задачи называется выбором из конечного состояния и обычно включает таблицу, опи
Сопрограммы
В некоторых системах две или более задач должны обрабатываться посегментно, причем каждый сегмент выполняется с различной скоростью (рис. 7.4).
Понятие изделия как средства общения
Действия при создании программного изделия по многим параметрам совпадают с действиями при создании технического изделия.
Изделие
Программа
Нисходящий анализ процесса управления проектированием программного изделия
Управление проектированием программного изделия включает в себя следующие функции:
- планирование;
- разработку;
- обслуживание;
- выпуск документации;
Организация взаимодействия
Если все взаимодействия хорошо определены, то и управление ими организовано должным образом. Если же взаимодействия плохо организованы, то даже при жесткой линейной структуре подчинения трудно буде
Установление целей, средства их достижения
Первым шагом процесса установления и достижения целей является подбор необходимого персонала. Когда в организации происходят изменения, соответственно меняется и ее персонал. Некоторые изменения пр
Подбор и обучение кадров
Поскольку разработка программных средств является достаточно сложной процедурой, то для ее реализации нужны специалисты высокой квалификации, т.е. для проектирования программного обеспечения необхо
Организация планирования разработок программного изделия
Планы создания программного изделия должны охватывать этапы разработки, документирования, испытаний, обучения пользователей, сопровождения. Отсутствие планов — основная причина переделки программ.
Виды планов
Самым главным охватывающим планом является целевая программа. Цель ее — максимизировать доход от капиталовложений. Целевая программа отвечает на вопрос, для чего предназначена та или иная деятельно
Декомпозиция планов
При планировании (создании планов) используется схема нисходящего планирования. Эта процедура называется декомпозицией планов:
- план создания семейства программных изделий;
- пла
Организационная структура группы планирования
Естественно, что различные виды планов соответствуют различным уровням руководства. В любой разрабатывающей организации должно быть создано специальное подразделение, единственной обязанностью кото
Планы, связанные с созданием программных изделий
При использовании нисходящего планирования осуществляется постепенный переход от общего к частному (от целевой программы к стратегическим и тактическим планам) и от глобального к локальному (от пла
Опытный образец изделия
Там, где существует хотя бы небольшая вероятность неудачи, план должен предусматривать возможность создания экспериментального изделия.
Опытный образец — это почти законченное изделие. Он
Организация планирования в фазе исследования
Фаза исследований начинается тогда, когда подтверждается необходимость создания программного изделия, и заканчивается тогда, когда утверждены технические требования (рис. 8.5).
Организация планирования в стадии анализа осуществимости
В момент времени, когда ресурсы распределены (начало фазы осуществимости), но соглашения о требованиях еще нет (конец фазы осуществимости), новое изделие рассматривается с учетом будущих условий ег
Организация планирования в фазах конструирования и кодирования
По окончанию фазы исследований группа планирования рассматривает и утверждает планы организации поддержки для каждого изделия или совокупности изделий. В течение всей фазы конструирования (проектир
Организация планирования в фазах оценки и использования
Следующий период жизненного цикла программного изделия связан с принятием решения о целесообразности широкого распространения изделия. Рекомендации дает группа испытаний, а если решение о выпуске п
Обязанности группы планирования при рассмотрении и утверждении планов разработки программного изделия
Разделение жизненного цикла программного изделия на фазы обеспечивает несколько контрольных точек, в которых изделие оценивается (см. рис. 8.5). Сознательные решения, принимаемые в конце каждой фаз
Организация разработки программного изделия
Под управлением проектом мы будем понимать управление достижением требований, предъявляемых к программному изделию на основании использования матричной структуры связи функций и проектов. В этой ма
Организация разработки программного изделия в фазе исследований
Затраты труда при реализации функций разработки отдельного программного изделия, согласно кривой Релея, имеют максимальное значение в фазах проектирования и программирования. Осуществление функций
Организация разработки программного изделия в фазе анализа осуществимости
Анализ осуществимости проводится одновременно всеми функциональными группами на основе изучения соглашения о требованиях. На этом этапе исследуется каждое предложение соглашения о требованиях. Руко
Организация разработки программного изделия в фазе конструирования (проектирования)
Основная цель проектирования заключается в выработке и анализе требований к программному изделию. Процесс декомпозиции проекта, начатый при составлении соглашения о требованиях, продолжается путем
Организация разработки программного изделия в фазе программирования
Рабочая нагрузка при выполнении функции разработки достигает наибольшей величины в фазе программирования. Основная задача организации разработки заключается в координации усилий большого числа сотр
Организация разработки программного изделия в фазе оценки
Фаза оценки открывается началом испытаний класса A, проводимых группой разработки. Испытания класса A — это всесторонняя проверка программного изделия, которая начинается после того, как все модули
Окончание проекта
Независимо от причин, вызвавших завершение проекта, группа разработки выпускает отчет, из которого могут почерпнуть опыт разработчики будущего проекта. Заключительный отчет составляется всеми участ
Участие группы разработки в фазовых обзорах
Группа разработки участвует в пяти из шести предусмотренных фазовых обзорах (табл. 8.4). В фазовом обзоре I эта группа дает первоначальную оценку стоимости проекта и составляет предварительный граф
Организация обслуживания разработки программного изделия
При любом способе организации разработки программного изделия необходима группа обслуживания, в функции которой входят:
· производственные операции — приобретение, эксплуатация и обслужива
Организационная структура группы обслуживания
Общий объем и номенклатура услуг, оказываемых в рамках функции обслуживания, определяют численный состав и внутреннюю структуру группы обслуживания. Как уже отмечалось, управление планами может зан
Организация обслуживания программного изделия в фазе исследования
В фазе исследований группа обслуживания занимается исключительно планированием своей работы на будущее, т.к. пока не будет доказана осуществимость проекта, т.е. пока не будут утверждены соглашения
Организация обслуживания в фазах анализа осуществимости и конструирования
В конце фазы исследований руководитель проекта передает на рассмотрение составленное им соглашение о требованиях. Администратор планирования проверяет его на совместимость с существующими планам
Организация обслуживания в фазе программирования и оценки
В фазах программирования и оценки группы разработки и испытаний требуют наибольшего внимания со стороны группы обслуживания, и, в первую очередь, это относится к обеспечению проводимых работ вычисл
Организация обслуживания в фазе использования
Пока программное изделие не будет передано всем пользователям, группа обслуживания проводит испытания класса C.
Использование программного изделия продолжается до тех пор, пока оно отвечае
Участие группы обслуживания в фазовых обзорах
В фазовом обзоре I группа обслуживания контролирует распределение бюджета проекта и обсуждает задачи, возлагаемые на нее после того, как проект минует фазу осуществимости. Основное внимание сосредо
Организация выпуска документации
Термины «документация» и «справочные материалы» относятся к печатной продукции, предназначенной для пользователей программного изделия. Термин «документы» используется по отношению к планам и специ
Организационная структура группы выпуска документации
Прежде всего очевиден тот факт, что большинство программистов не любит писать никаких бумаг, кроме программ, поэтому введение специальной группы для выполнения этих работ достаточно обосновано. Цен
Стандарты и практические руководства
Если не установить правила оформления документации, редакторы, художники и т.п., подобно программистам, будут действовать в зависимости от своих вкусов и наклонностей. Чтобы продукция имела професс
Организация выпуска документации в фазах исследований и анализа осуществимости
Группа выпуска документации начинает участвовать в работе над программным изделием в рамках фазового обзора I, выполняя предварительную оценку стоимости издания документации. Для этого приходится п
Организация выпуска документации в фазах конструирования и программирования
Активная работа группы выпуска документации начинается в этих фазах. В фазе конструирования создаются макеты будущей документации. План выпуска документации детализирует положения соглашения о треб
Организация выпуска документации в фазах оценки и использования
В начале фазы оценки группа выпуска документации заканчивает составление окончательных вариантов всей документации вместе с иллюстрациями. Рукописи направляются на рассмотрение другим группам. Груп
Участие группы выпуска документации в фазовых обзорах
До фазового обзора I в группу выпуска документации поступает запрос на проведение предварительных оценок необходимых ресурсов, на основании которых производится распределение бюджета. Утверждение с
Организация испытаний программных изделий
В широком смысле слова, под испытаниями понимают не отладку, призванную определить, почему в программе возникает та или иная ошибка и устранить ее причины, а процесс установления самого факта налич
Современное состояние методов обеспечения качества программного изделия
Группа испытаний оказывает значительное влияние на качественную сторону проектирования, используя такие воздействия на качественную сторону проектирования, как технические ревизионные комиссии, сог
Виды испытаний программного изделия. Стадии испытаний
В общем случае, испытания проводятся в несколько стадий, разделенных по времени.
К первой стадии относятся испытания класса A, которые проводятся в конце фазы программирования после того,
Режимы испытаний программ
Испытания различаются в зависимости от того, кто их проводит. Основная идея — независимость функции испытаний от функции разработки.
Режим I подразумевает полный цикл деятельности группы и
Категории испытания программного изделия
Стадии испытания указывают на время проведения проверок, а режимы определяют тех, кто проводит. Категории испытаний устанавливают характер и назначение тестов. Продуманное деление испытаний изделий
Организационная структура группы испытаний
Общее правило организации деятельности по обеспечению качества программного изделия заключается в установлении подотчетности соответствующих процедур как можно более высокому уровню руководства фир
Организация испытаний в фазах исследований и анализа осуществимости
В фазе исследований деятельность группы испытаний должна предусматривать интенсивное общение с другими группами для решения вопросов о том, какие режимы испытаний следует установить, когда начнутся
Организация испытаний в фазах конструирования и программирования
Составление плана испытаний является основной работой, которую выполняет группа испытаний в этой фазе. Обязательным условием завершения этой работы является утверждение соглашения о требованиях, и
Организация испытаний в фазе оценки
На этапе оценки уровень трудозатрат группы испытаний достигает максимума. Первая обязанность группы состоит в том, чтобы установить готовность изделия к испытаниям класса B. Группа разработки неред
Организация испытаний в фазе использования
В фазе использования группа испытаний осуществляет текущий контроль за проведением испытаний класса C. Роль группы испытаний состоит в том, чтобы убедиться, что выполнение контрольных проверок
Участие группы испытаний в фазовых обзорах
Группа испытаний участвует в пяти из шести фазовых обзорах (табл. 8.8).
Таблица 8.8 — Участие группы выпуска документации в фазовых обзорах
Фаза
Фазовы
Новости и инфо для студентов