Анализ граничных значений - Лекция, раздел Программирование, Учебное пособие про этапы разработки программного обеспечения Как Показывает Опыт, Тесты, Исследующие Граничные Условия, Приносят Большую П...
Как показывает опыт, тесты, исследующие граничные условия, приносят большую пользу, чем тесты, которые их не исследуют. Граничные условия — это ситуации, возникающие непосредственно на границах, а также выше или ниже границ входных и выходных классов эквивалентности. Анализ граничных значений отличается от эквивалентного разбиения в двух отношениях:
1. Выбор любого элемента в классе эквивалентности в качестве представительного при анализе граничных значений осуществляется таким образом, чтобы проверить тестом каждую границу этого класса.
2. При разработке тестов рассматривают не только входные условия (пространство входов), но и пространство результатов (т.е. выходные классы эквивалентности).
Трудно описать «кухню» анализа граничных значений, так как это требует определенной степени творчества и специализации в рассматриваемой проблеме (следовательно, анализ граничных значений, как и многие другие аспекты тестирования, в значительной мере основывается на способностях человеческого интеллекта). Тем не менее приведем несколько правил этого метода.
1. Построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области, если входное условие описывает область значений. Например, если правильная область входных значений есть –1.0…+1.0, то написать тесты для ситуаций –1.0, 1.0, –1.001 и 1.001.
2. Построить тесты для минимального и максимального значения условий и тесты, большие и меньшие этих значений, если входное условие удовлетворяет дискретному ряду значений. Например, если входной файл может содержать от 1 до 255 записей, то получить тесты для 0, 1, 255 и 256 записей.
3. Использовать правило 1 для каждого выходного условия. Например, если программа вычисляет ежемесячный расход и если минимум расхода составляет $0,00, а максимум — $1165,25, то построить тесты, которые вызывают расходы с $0,00 по $1165,25. Кроме того, построить, если это возможно, тесты, которые вызывают отрицательный расход и расход больше $1165,25. Заметим, что важно проверить границы пространства результатов, поскольку не всегда границы входных областей представляют такой же набор условий, как и границы выходных областей (например, при рассмотрении подпрограммы вычисления синуса). Не всегда также можно получить результат вне выходной области, но тем не менее стоит рассмотреть эту возможность.
4. Использовать правило 2 для каждого входного условия. Например, если система информационного поиска отображает на экране терминала наиболее релевантные рефераты в зависимости от входного запроса, но никак не более четырех рефератов, то построить тесты, такие, чтобы программа отображала нуль, один и четыре реферата, и тест, который мог бы вызвать выполнение программы с ошибочным отображением пяти рефератов.
5. Если вход или выход программы есть упорядоченное множество (например, последовательный файл, линейный список, таблица), то сосредоточить внимание на первом и последнем элементах этого множества.
6. Попробовать свои силы в поиске других граничных условий.
Чтобы проиллюстрировать необходимость анализа граничных значений, можно использовать программу анализа треугольника, приведенную в п. 6.2.1. Для задания треугольника входные значения должны быть целыми положительными числами и сумма любых двух из них должна быть больше третьего. Если определены эквивалентные разбиения, то целесообразно определить одно разбиение, в котором это условие выполняется, и другое, в котором сумма двух целых не больше третьего. Следовательно, двумя возможными тестами являются 3—4—5 и 1—2—4. Тем не менее здесь есть вероятность пропуска ошибки. Иными словами, если выражение в программе было закодировано как A+B³C вместо A+B>C, то программа ошибочно сообщала бы нам, что числа 1—2—3 представляют правильный равносторонний треугольник. Таким образом, существенное различие между анализом граничных значений и эквивалентным разбиением заключается в том, что анализ граничных значений исследует ситуации, возникающие на границах и вблизи границ эквивалентных разбиений.
В качестве примера для применения метода анализа граничных значений рассмотрим следующую спецификацию программы.
MTEST есть программа, которая сортирует различную информацию об экзаменах. Входом программы является файл, названный OCR, который содержит 80-символьные записи. Первая запись представляет название; ее содержание используется как заголовок каждого выходного отчета. Следующее множество записей описывает правильные ответы на экзамене. Каждая запись этого множества содержит «2» в качестве последнего символа. В первой записи в колонках 1—3 задается число ответов, оно принимает значения от 1 до 999. Колонки 10—59 включают сведения о правильных ответах на вопросы с номерами 1—50, любой символ воспринимается как ответ. Последующие записи содержат в колонках 10—59 сведения о правильных ответах на вопросы с номерами 51—100, 101—150 и т.д. Третье множество записей описывает ответы каждого студента; любая запись этого набора имеет число «3» в восьмидесятой колонке. Для каждого студента первая запись в колонках 1—9 содержит его имя или номер (любые символы); в колонках 10—59 помещены сведения о результатах ответов студентов на вопросы с номерами 1—50. Если в тесте предусмотрено более чем 50 вопросов, то последующие записи для студента описывают ответы 51—100, 101—150 и т.д. в колонках 10—59. Максимальное число студентов — 200. Форматы входных записей показаны на рис. 6.8.
| Название
|
| Число вопросов
|
| Правильные ответы:
1—50
|
|
|
| 1 3
| 4 9
| 10 59
| 60 79
|
|
|
| Неправильные ответы:
51—100
|
|
|
|
|
|
|
|
|
| Идентификатор
студента
| Ответы студента:
1—50
|
|
|
|
|
|
|
|
|
|
| Ответы студента:
51—100
|
|
|
|
|
|
|
|
|
| Идентификатор
студента
| Ответы студента:
1—50
|
|
|
Рис. 6.8 — Структуры входных записей для программы MTEST
Выходными записями являются:
1) отчет, упорядоченный в лексикографическом порядке идентификаторов студентов и показывающий качество ответов каждого студента (процент правильных ответов) и его ранг;
2) аналогичный отчет, но упорядоченный по качеству;
3) отчет, показывающий среднее значение, медиану и среднеквадратическое отклонение качества ответов;
4) отчет, упорядоченный по номерам вопросов и показывающий процент студентов, отвечающих правильно на каждый вопрос.
Конец спецификации.
Начнем методичное чтение спецификации, выявляя входные условия. Первое граничное входное условие есть пустой входной файл. Второе входное условие — карта (запись) названия; граничными условиями являются отсутствие карты названия, самое короткое и самое длинное названия. Следующими входными условиями служат наличие записей о правильных ответах и наличие поля числа вопросов в первой записи ответов. 1—999 не является классом эквивалентности для числа вопросов, так как для каждого подмножества из 50 записей может иметь место что-либо специфическое (т.е. необходимо много записей). Приемлемое разбиение вопросов на классы эквивалентности представляет разбиение на два подмножества: 1—50 и 51—999. Следовательно, необходимы тесты, где поле числа вопросов принимает значения 0, 1, 50, 51 и 999. Эти тесты покрывают большинство граничных условий для записей о правильных ответах. Однако существуют три более интересные ситуации — отсутствие записей об ответах, наличие записей об ответах типа «много ответов на один вопрос» и наличие записей об ответах типа «мало ответов на один вопрос». Например, число вопросов 60 и имеются три записи об ответах в первом случае и одна запись об ответах во втором. Таким образом, определены следующие тесты:
1. Пустой входной файл.
2. Отсутствует запись названия.
3. Название длиной в один символ.
4. Название длиной в 80 символов.
5. Экзамен из одного вопроса.
6. Экзамен из 50 вопросов.
7. Экзамен из 51 вопроса.
8. Экзамен из 999 вопросов.
9. 0 вопросов на экзамене.
10. Поле числа вопросов имеет нечисловые значения.
11. После записи названия нет записей о правильных ответах.
12. Имеются записи типа «много правильных ответов на один вопрос».
13. Имеются записи типа «мало правильных ответов на один вопрос».
Следующие входные условия относятся к ответам студентов. Тестами граничных значений в этом случае, по-видимому, должны быть:
14. 0 студентов.
15. 1 студент.
16. 200 студентов.
17. 201 студент.
18. Есть одна запись об ответе студента, но существуют две записи о правильных ответах.
19. Запись об ответе вышеупомянутого студента первая в файле.
20. Запись об ответе вышеупомянутого студента последняя в файле.
21. Есть две записи об ответах студента, но существует только одна запись о правильном ответе.
22. Запись об ответах вышеупомянутого студента первая в файле.
23. Запись об ответах вышеупомянутого студента последняя в файле.
Можно также получить набор тестов для проверки выходных границ, хотя некоторые из выходных границ (например, пустой отчет 1) покрываются приведенными тестами. Граничными условиями для отчетов 1 и 2 являются:
- 0 студентов (так же, как тест 14);
- 1 студент (так же, как тест 15);
- 200 студентов (так же, как тест 16);
24. Оценки качества ответов для всех студентов одинаковы.
25. Оценки качества ответов всех студентов различные.
26. Оценки качества ответов некоторых, но не всех студентов одинаковы (для проверки правильности вычисления рангов).
27. Студент получает оценку качества ответа 0.
28. Студент получает оценку качества ответа 100.
29. Студент имеет идентификатор наименьшей возможной длины (для проверки правильности упорядочивания).
30. Студент имеет идентификатор наибольшей возможной длины.
31. Число студентов таково, что отчет имеет размер, несколько больший одной страницы (для того чтобы посмотреть случай печати на другой странице).
32. Число студентов таково, что отчет располагается на одной странице.
Граничные условия отчета 3 (среднее значение, медиана, среднеквадратическое отклонение):
33. Среднее значение максимально (качество ответов всех студентов наивысшее).
34. Среднее значение равно 0 (качество ответов всех студентов равно 0).
35. Среднеквадратическое отклонение равно своему максимуму (один студент получает оценку 0, а другой — 100).
36. Среднеквадратическое отклонение равно 0 (все студенты получают одну и ту же оценку).
Тесты 33 и 34 покрывают и границы медианы. Другой полезный тест описывает ситуацию, где существует 0 студентов (проверка деления на 0 при вычислении математического ожидания), но он идентичен тесту 14.
Проверка отчета 4 дает следующие тесты граничных значений:
37. Все студенты отвечают правильно на первый вопрос.
38. Все студенты неправильно отвечают на первый вопрос.
39. Все студенты правильно отвечают на последний вопрос.
40. Все студенты отвечают на последний вопрос неправильно.
41. Число вопросов таково, что размер отчета несколько больше одной страницы.
42. Число вопросов таково, что отчет располагается на одной странице.
Опытный программист, вероятно, согласится с той точкой зрения, что многие из этих 42-х тестов позволяют выявить наличие общих ошибок, которые могут быть сделаны при разработке данной программы. Кроме того, большинство этих ошибок, вероятно, не было бы обнаружено, если бы использовался метод случайной генерации тестов или специальный метод генерации тестов. Анализ граничных значений, если он применен правильно, является одним из наиболее полезных методов проектирования тестов. Однако он часто оказывается неэффективным из-за того, что внешне выглядит простым. Необходимо понимать, что граничные условия могут быть едва уловимы и, следовательно, определение их связано с большими трудностями.
Все темы данного раздела:
Этапы разработки программного обеспечения
Естественно, что отдельный человек не в состоянии полностью осмыслить и построить программное обеспечение большой системы. Для управления ходом разработки больших программных систем выделяются шест
Анализ требований, предъявляемых к системе
На первом этапе, часто неоправданно опускаемом, определяются требования, которые позволяют получить приемлемое решение проблемы. На этом этапе формулируются целевое назначение и основные свойства р
Определение спецификаций
На этапе определения спецификаций осуществляется точное описание функций, реализуемых ЭВМ, а также задаются структура входных и выходных данных, методы и средства их размещения. Определяются алгори
Проектирование
На стадии проектирования разрабатываются алгоритмы, задаваемые спецификациями, и формируется общая структура вычислительной системы. При этом система разбивается (при необходимости) на составные ча
Кодирование
Данный этап является наиболее простым, а его реализация существенно облегчается при использовании алгоритмических языков высокого уровня. Кодирование — это этап разработки программного обеспечения,
Тестирование
Этап тестирования обычно в финансовых затратах составляет половину расходов на создание системы. Плохо спланированное тестирование приводит к существенному увеличению сроков разработки системы и яв
Эксплуатация и сопровождение
С учетом затрат на эксплуатацию и сопровождение временные затраты на разработку программной системы можно представить так (рис. 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 — Участие группы выпуска документации в фазовых обзорах
Фаза
Фазовы
Новости и инфо для студентов