30 Особенности объектного подхода к разработке внешнего описания пс
Внешнее описание оказывается более емким, чем при структурном подходе. Определение требований: неформальное описание модельного мира, который пользователь собирается изучать.
Спецификация требований: создается формальное описание моделируемого мира, состояще из трех частей: - объектной модели; - динамической модели; - функциональной модели.
Объектная модель определяет то, с чем случается, динамическая - когда это случается, функциональная - что случается.
Объектная модель показывает статическую объектную структуру моделируемого мира. Она включает определение используемых классов модельного мира, отношения между этими классами, а также определение используемых объектов этих классов и отношений между этими объектами.
Класс объекта = имя + список артибутов + список операций
Каждый атрибут представляется некоторым именем и может принимать значения определенного типа. АТрибут класса выражает некоторое простое свойство объектов этого класса. Операции отражают другие свойства объектов, как простые, так и ассоциативные. В объектной модели отношения между объектами выражаются отношениями между классами. При этом, как правило, используются одноместные и двуместные отношения. Одноместные отношения называют атрибутами, между двумя и более объектами - связями, а их обобщения - ассоциацией. Ассоциации играют важую роль в объектной модели - они определяют допустимые связи между объектами.
Виды ассоциаций: 1) взаимодействие состояний объектов - объекты классов в таком отношении могут быть параметрами некоторых операций; 2) агрегирование (структурирование) - объект одного из классов, находящийся в таком отношении, включает или может включать в себя часть объектов другого из этих классов; 3) абстрагирование (порождение) - один из классов, находящихся в таком отношении, наследует свойства другого из этих классов и может обладать другими дополнительными свойствами.
Обычно используют графические языки спецификации (UML). Классы объектов обозначаются в нем прямоугольниками, а отношения - линиями и надписями.
Для описания декомпозиции используются отношения агрегирования. Например, программа может состоять из нескольких модулей.
Динамическая модель необходима, если в объектной модели имеются активные объекты.
Под состоянием объекта понимается совокупность значений атрибута и представление текущих связей этого объекта с другими объектами. Состояние объекта связывается с интервалом времени между некоторыми двумя событиями. В динамической модели для каждого класса активных объектов строится своя диаграмма состояний. Она представляет собой граф, вершинами которого являются состояния, а дугами - переходы между ними, обозначаемые именами событий. Некоторые переходы могут быть связаны с условиями, разрешающими переходы. Каждое условие указываетя на дуге, переходом по которой управляет это условие. Операция, связанная с событием, обозначает реакцию объекта на это событие и считается, что она происходит мгновенно. Такая операция называется действием. Операция, связанная с состоянием и выполняемая в рамках временного интервала, с которым связано это состояние, называется деятельностью. Таким образом, диаграмма состояний описывает поведение одного класса объектов.
Функциональная модель показывает, как вычмсляются выходные значения их входных без порядка их выполнения. Она определяет все операции, условия и ограничения, используемые в объектной и динамической модели. Для определения крупных операций в функциональной модели используются потоковые диаграммы. Основные понятия потоковой диаграммы - процессы, объекты, потоки данных.
Потоковая диаграмма - это граф, вершинами которого являются объекты или процессы, а дугами - потоки данных. Процессы преобразуют данные, представляют внутренние операции. Объекты могут быть пассивными (хранилище данных) и активными (агенты).
32 Источники ошибок в ПС: интеллектуальные возможности человека, модель перевода информации. Причины появления ошибок.
Интеллектуальные возможности человека
Дейкстра выделил три интеллектуальные возможности человека, используемые при разработке ПС:
Способность к перебору;
Способность к абстракции;
Способность к математической индукции.
1 — Возможность последовательно переключать внимание с одного объекта на другой, позволяя узнавать искомый предмет. Эта способность ограничена. Средний человек может перебрать до 1000 предметов.
Средство преодоления ограниченности — 2. Можно объединить предметы и экзамепляры в одно понятие, заменить множество одних, элементом другого рода.
3 — позволяет справляться с бесконечными последовательностями. Под системой понимают совокупность взаимодействующих, т.е. находящихся друг с другом в отношениях, элементов, поэтому программное средство рассматривают, как систему.
Понять систему — значит осмысленно перебрать пути взаимодействия между ее элементами.
Различают простые и сложные системы. В простой можно перебрать все пути взаимодействия элементов системы, в сложной — нет.
При разработке ПС программист не всегда может знать о связях между элементами, поэтому полезно уметь оценить сложность системы по числу элементов — числу потенциальных взаимодействий n.
n < 7 — система простая (малая).
Малая всегда простая, большая может быть простой или сложной.
Задача технологии программирования — научиться делать большие программы простыми.
Неправильный перевод, как причина ошибок в программных средствах.
При разработке и использовании ПС мы многократно имеем дело с преобразованием информации из одной формы в другую.
Рисунок
Модель перевода
Рисунок
Человек получает информацию с помощью читающего механизма R;
Он записывает полученную информацию в памяти M;
Выбирает из памяти преобразованную информацию и информацию, описывающую процесс преобразования, выполняет перевод и посылает результат пишущему механизму W;
С помощью W фиксирует представление Б.
На каждом из этих шагов он может совершать различные ошибки:
Ошибки в описании задачи;
Ошибки в выборе алгоритма;
Ошибки анализа — неполный учет всевозможных ситуаций;
Ошибки общего характера: низкая квалификация программиста;
Ошибки документации.
Методы обнаружения ошибок:
Проверка перед монитором;
Проверка исходных данных;
Искажение данных аппаратными средствами
Ошибки перезаписи при копировании данных до входа в вачислительную систему;
Стандартные ошибки;
Неправильное размещение данных;
Введение некомпетеными пользователями.
Метод последовательных исключений — снижение области поиска.
Ошибки выполнения:
Определения данных;
Передачи;
Преобразования;
Перезаписи;
Неправильные данные.
Логические;
Неприемлемый подход;
Неверный алгоритм;
Неверная структура данных;
Другие;
Кодирования;
Проектирования;
Некорректная работа с переменными;
Некорректные вычисления;
Ошибки интерфейсов;
Неправильная реализация алгоритма;
Другие.
Накопления погрешностей;
Игнорирование ограничений разрядной сетки;
Игнорирование способов уменьшения погрешностей.
Причины появления ошибок:
Технологические — включающие возможности описания задачи и ее решения;
Организационные — распределение рабочей нагрузки, доступность информации средств связи и ресурсов;
Психологические — желание сотрудничать, распределение ролей, микроклимат в коллективе;
Индивидуальные — квалификация, талант, личные качества.
33 Основные понятия отладки и тестирования. Различие между отладкой и тестированием. Преимущество тестирования сверху вниз. Проверка программ в нормальных, экстремальных и исключительных ситуациях.
Отладка ПС - это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами:
Отладка = Тестирование + Поиск ошибок + Редактирование
В зарубежной литературе отладку часто понимают только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых устанавливается при тестировании. Иногда тестирование и отладку считают синонимами. В нашей стране в понятие отладки обычно включают и тестирование, поэтому мы будем следовать сложившейся традиции.
Тестирование – процесс многократного повторения программы с целью обнаружения ошибок. Тестирование – составная часть отладки.
Отладка имеет место тогда, когда программа со всей очевидностью работает неправильно. Поэтому отладка начинается всегда в предвидении отказа программы. Если же оказывается, что программа работает верно, то она тестируется. Часто случается так, что после прогона тестов программа вновь подвергается отладке. Таким образом, тестирование устанавливает факт наличия ошибки, а отладка выявляет ее причину.
Основная цель выделения отладки и тестирования как отдельных этапов создания программы заключается в том, чтобы обратить внимание обязательности обеих стадий и на необходимость специального планирования временных затрат по каждой из них в отдельности.
Нельзя гарантировать, что тестированием можно установить наличие каждой имеющейся в ПС ошибки. Поэтому возникает две задачи. Первая задача: подготовить такой набор тестов и применить к ним ПС, чтобы обнаружить в нем по возможности большее число ошибок. Однако чем дольше продолжается процесс тестирования (и отладки в целом), тем большей становится стоимость ПС. Отсюда вторая задача: определить момент окончания отладки ПС (или отдельной его компоненты). Признаком возможности окончания отладки является полнота охвата пропущенными через ПС тестами (т.е. тестами, к которым применено ПС) множества различных ситуаций, возникающих при выполнении программ ПС, и относительно редкое проявление ошибок в ПС на последнем отрезке процесса тестирования. Последнее определяется в соответствии с требуемой степенью надежности ПС, указанной в спецификации его качества.
При нисходящем тестировании окружение в качестве отладочных содержит отладочные имитаторы (заглушки) некоторых еще не отлаженных модулей. Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов.
На практике в окружении отлаживаемого модуля могут содержаться отладочные модули обоих типов, если используется смешанная стратегия тестирования.
Достоинства восходящего тестирования:
Простота подготовки тестов;
Возможность полной реализации плана тестирования модуля.
Недостатки восходящего тестирования:
Тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя;
Большой объем отладочного программирования;
Необходимость специального тестирования сопряжения модулей.
Достоинства нисходящего тестирования:
Большинство тестов готовится в форме, рассчитанной на пользователя;
Во многих случаях относительно небольшой объем отладочного программирования;
Отпадает необходимость тестирования сопряжения модулей.
Недостатком нисходящего тестирования является то, что тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно - оно является результатом применения уже отлаженных модулей к тестовым данным или данным, выдаваемым имитаторами.
Проверка программы в нормальных, экстремальных и исключительных ситуациях.
Случаи, когда программа должна работать со всеми данными, чрезвычайно редки.
Проверка в нормальных условиях должна показать, что программа выдает правильные результаты для хар-й совокупности данных.
Проверка в экстремальных условиях включает граничные значения области измерения входных переменных, которые должны восприниматься программой, как правильные данные.
В исключительных ситуациях значения за допустимым диапазоном.
Наихудшая ситуация — когда программа воспринимает неверные результаты, как правильные и выдает неверный, но правдоподобный результат. Программа должна отвергать данные, которые она не в состоянии обработать правильно.
34 Основные принципы тестирования программ. Заповеди по тестированию, предложенные Г. Майерсом. Методы тестирования, два подхода к тестированию.
Тестирование ПС - это процесс выполнения его программ на некотором наборе данных, для которого заранее известен результат применения или известны правила поведения этих программ. Указанный набор данных называется тестовым или просто тестом. Таким образом, отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки.
Тестирование – процесс многократного повторения программы с целью обнаружения ошибок. Тестирование – составная часть отладки.
Заповеди, предложенные Майерсом, по тестированию ПС.
Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу;
Заповедь 2. Хорош тот\ тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы;
Заповедь 3. Готовьте тесты как для правильных, так и для неправильных данных;
Заповедь 4. Документируйте пропуск тестов через компьютер; детально изучайте результаты каждого теста; избегайте тестов, пропуск которых нельзя повторить;
Заповедь 5. Каждый модуль подключайте к программе только один раз; никогда не изменяйте программу, чтобы облегчить ее тестирование;
Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).
Существуют следующие методы тестирования ПС:
Статическое тестирование – ручная проверка программы за столом.
Детерминированное тестирование – при различных комбинациях исходных данных.
Стохастическое – исходные данные выбираются произвольно, на выходе определяется качественное совпадение результатов или примерная оценка.
Имеется два подхода к тестированию:
Структурное тестирование – метод «белого ящика», тестируется логика программы, внутренняя структура программы.
Функциональное тестирование – метод «черного ящика»- тестируется спецификация, т.е. вход/выход без учета знаний о ее структуре.
Структурное тестирование
При данном подходе считается, что текст программы виден (белый ящик).
Тестируются блоки ветвлений, циклы и т.д.
Существует несколько типов структурного тестирования:
покрытие операторов;
покрытие решений;
покрытие решений / условий;
комбинаторное покрытие условий;
тестирование циклов.
Функциональное тестирование
При данном подходе считается, что текст программы не виден, и программа рассматривается как черный ящик, т.е. известны входные и выходные условия, а также общая схема работы. Программа проверятся по ее спецификациям.
Существуют несколько видов функционального тестирования:
эквивалентные классы;
анализ граничных значений;
тестирование на предельных нагрузках;
тестирование на предельных объемах;
тестирование защиты;
эксплуатация системы самим разработчиком (если возможно);
опытная эксплуатация.
35 Тестирование модулей: тестирование путей, структур управления, ветвлений, специальных значений (примеры).
Тестирование путей — самая подробная проверка — должны быть выялены всевозможные пути прохождения по модулю;
рисунок
Тестирование структуры управления;
При тестировании управляющих структур считается, что одного прохода по циклу достаточно.
Тестирование ветвлений — анализируются точки ветвления управляющего графа;
Тестирование специальных значений — деление на ноль, потеря значимости и так далее;
36 Автономная отладка ПС. Комплексная отладка ПС.
В нашей стране различаются два основных вида отладки (включая тестирование): автономную и комплексную отладку ПС.
Автономная отладка ПС означает последовательное раздельное тестирование различных частей программ, входящих в ПС, с поиском и исправлением в них фиксируемых при тестировании ошибок. Она фактически включает отладку каждого программного модуля и отладку сопряжения модулей.
Автономная отладка ПС - последовательное раздельное тестирование различных частей программ с поиском и исправлением в них фиксируемых при тестировании ошибок. Комплексная отладка - тестирование ПС в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах.
При автономной отладке тестируется всегда некоторая программа (тестируемая программа), построенная специально для тестирования отлаживаемого модуля. В процессе автономной отладки ПС производится наращивание тестируемой программы отлаженными модулями (интеграция программы).
При восходящем тестировании окружение содержит только один отладочный модуль, головной в тестируемой программе - ведущий (или драйвер). Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля, осуществляет обращение к отлаживаемому модулю и выдает необходимые сообщения.
При нисходящем тестировании окружение в качестве отладочных содержит отладочные имитаторы (заглушки) некоторых еще не отлаженных модулей. Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов.
На практике в окружении отлаживаемого модуля могут содержаться отладочные модули обоих типов, если используется смешанная стратегия тестирования.
Достоинства восходящего тестирования:
Простота подготовки тестов;
Возможность полной реализации плана тестирования модуля.
Недостатки восходящего тестирования:
Тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя;
Большой объем отладочного программирования;
Необходимость специального тестирования сопряжения модулей.
Достоинства нисходящего тестирования:
Большинство тестов готовится в форме, рассчитанной на пользователя;
Во многих случаях относительно небольшой объем отладочного программирования;
Отпадает необходимость тестирования сопряжения модулей.
Недостатком нисходящего тестирования является то, что тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно - оно является результатом применения уже отлаженных модулей к тестовым данным или данным, выдаваемым имитаторами.
Прежде всего, необходимо организовать отладку программы таким образом, чтобы как можно раньше были отлажены модули, осуществляющие ввод данных. Пока модули, осуществляющие ввод данных, не отлажены, тестовые данные поставляются некоторыми имитаторами: они либо включаются в имитатор как его часть, либо вводятся этим имитатором.
При нисходящем тестировании некоторые состояния информационной среды, при которых требуется тестировать отлаживаемый модуль, могут не возникать при выполнении отлаживаемой программы ни при каких входных данных. Чаще же пользуются модифицированным вариантом нисходящего тестирования, при котором отлаживаемые модули перед их интеграцией предварительно тестируются отдельно.
Однако, представляется более целесообразной другая модификация нисходящего тестирования: после завершения нисходящего тестирования отлаживаемого модуля для достижимых тестовых состояний информационной среды следует его отдельно протестировать для остальных требуемых состояний информационной среды.
Часто применяют также комбинацию восходящего и нисходящего тестирования, которую называют методом сандвича. Сущность этого метода заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования, пока эти два процесса тестирования не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой программы.
Весьма важным при автономной отладке является тестирование сопряжения модулей.
При нисходящем тестировании тестирование сопряжения осуществляется попутно каждым пропускаемым тестом, что считают достоинством нисходящего тестирования. При восходящем тестировании обращение к отлаживаемому модулю производится не из модулей отлаживаемой программы, а из ведущего отладочного модуля.
Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага.
Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тесты для каждой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия.
Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты.
Шаг 3. Проверьте текст модуля, чтобы убедиться, что для каждого цикла существуют тесты, обеспечивающие, по крайней мере, три следующие ситуации: тело цикла не выполняется ни разу, тело цикла выполняется один раз и тело цикла выполняется максимальное число раз. Добавьте недостающие тесты.
Шаг 4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие тесты.
Комплексная отладка означает тестирование ПС в целом с поиском и исправлением фиксируемых при тестировании ошибок во всех документах (включая тексты программ ПС), относящихся к ПС в целом. К таким документам относятся определение требований к ПС, спецификация качества ПС, функциональная спецификация ПС, описание архитектуры ПС и тексты программ ПС.
Тестирование при комплексной отладке - применение ПС к конкретным данным, которые могут возникнуть у пользователя, но, возможно, в моделируемой (а не в реальной) среде.
Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная отладка каждой подсистемы.
Тестирование внешних функций. Целью тестирования является поиск расхождений между функциональной спецификацией и совокупностью программ ПС. Несмотря на то, что все эти программы автономно уже отлажены, указанные расхождения могут быть.
Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Завершенность ПС проверяется уже при тестировании внешних функций.
Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также выявление неудобств, возникающих при применении ПС. Этот этап непосредственно предшествует подключению пользователя к завершению разработки ПС (тестированию определения требований к ПС и аттестации ПС).
Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему. Особенность этого вида тестирования заключается в том, что его осуществляет организация-покупатель или организация-пользователь. Обычно производится с помощью контрольных задач - типовых задач, для которых известен результат решения.
37 Необходимость коллективной разработки ПО. Метод бригады главного программиста. Состав бригады. Обязанности главного программиста.
Если
Некоторые задачи очень сложны , чтобы справиться с ними нужно решить много подзадач. К моменту формирования исходной задачи решение этих подзадач не найдено. Человек последовательно занимающийся этими задачами не закончит их в срок.
Некоторые задачи очень объемные Прогнозируемые задачи можно закончить раньше если работать параллельно
Некоторые задачи требуют кооперации программистов, обладающих специальными знаниями
Задача может потребовать коллективного решения.
Миллс «Бригада главного программирования»
Создается группа из 5 10 человек Бригада состоит и з главного програмера , помошника главного програмера , секретарь (библиотекарь) , программисты исполнители. Идея — работает как один программист высокой квалификации.
Главный програмер несет 100% ответственность за проектирование ПС. Распределяет работу, принимает решения. Отвечает за успех .Пишет важные процедуры и функции, определенные спецификацией для остальных модулей,ю объединяет результаты в единое целое. Руководство персоналом, соблюдение условий контракта, регулирование отношений с заказчиком .Решает когда и сколько программистов может понадобиться.
38 Функции заместителя главного программиста. Работа членов бригады. Работа секретаря (библиотекаря). Преимущества и трудности бригадного подхода.
Заместитель: По мастерству не уступает главному программисту – он не должен быть 2 лидером в бригаде
Исполнители – выполняют работу порученную главным программистом.
Библиотекарь: Отвечает за ведение всей документации – бумажные и электронные варианты.. В библиотеке хранятся записи, показывающие текущее состояние программ . Секретарь ведет журнал разработки, фиксирует все этапы разработки, сообщения , замечания, фиксирует распоряжении главного програмера , участвует в тестировании системы, полноправный член бригады. Выполняет большую часть канцелярской работы, входящую в обязанности программистов , что позволяет их более эффективно использовать.
+
Уменьшение времени разработки;
Менее квалифицированные програмеры могут участвовать в больших проектах , овладеть навыками;
Освобождении программистов от канцелярской работы.
-
<>
Бригада главного программиста используется при разработке средних размеров работ;
Главный программист у необходимо уметь управлять бригадой, рационально использовать свой время, обеспечивать техническое преимущество преред заказчиком. Должен вести проект. Оценивать работк других сотрудников бригады – таких найти НЕЛЕГКО!
39 Процессы управления разработкой программного средства. Организация коллективов для создания больших комплексов програм.
Управление разработкой ПС – действия, направленные на необходимые условия для работы коллектива разработчиков., на планирование и контроль её деятельности с целью обеспечения требуемого качества , выполнения сроков и бюджетов разработки – управление программным проектом.
К необходимым условиям работы коллектива относятся : помещения, аппаратно-програмные средства документация, материально-финансовое обеспечение
Планирование и контроль предполагает разбиение всего процесса разработки на отдельные конкретные задания , подбор и расстановка исполнителей, установление сроков и порядка выполнения работ , оценка качества выполнения каждой работы. Финальной частью является проведение аттестации(сертификации ) , которой завершаетсмя стадия разработки ПС
Общие процессы по управления разработкой
Составлении плана проспекта по разработке -как выполнить разработку? Для кого?
Планирование составления расписания по разработке ПС Распределения работ между исполнителями по врнмени в рамках намеченных сроков и имеющихся ресурсов
Управления издержками по разработке ПС.
Основными источниками издержек явл:
Затраты на ппаратное оборудование;
На вербовку и обучение персонала;
На зарплату.
Текущий контроль и документирование деятельности коллектива;
Подбор и оценка персонала коллектива разработчиков. Формирование коллектива.
40 Структура управления разработкой программного средства. Планирование и составления расписаний по разработке ПС.
Картинка
Директор принимает заказы – проекты , участвует в обсуждении оганизационных требований к программному проекту.
Менеджер сфер разработок отвечает за управление разработкой ПС определенного типа.
Менеджер проекта отвечает за составлении расписания , управляет работой лидера бригады разработчиков.
Оптимальный коллектив 8 -10 человек.
Менеджер по качеству – подчиняется директору.
Планирование и составление расписаний
Составление расписаний заключается:
Разделение всей работы на самостаячтельно выполняющиеся задания;
Составлении сетевого графика выполения задания;
Составление гистограммы выполднения заданий;
Расстановка исполнителей заланий.
41 Аттестация ПС. Проблемы оценки квалификации отдельных специалистов в коллективе. Прикладное тестирование специалистов.
Аттестация ПС завершающий этап разработки ПС, авторитетное подтверждение качества ПС.
Для аттестации создаются аттестационные комиссии из экспертов представителей заказчика и разработчика. Эта комиссия проводит испытания с целью получения информации о ПС.
Испытания – процесс проведения комплексных мероприятий и пригодность ПС для успешной эксплуатации требований заказчика.
Решение записываются в документе , подписываемом всем и членами.
Проблемы оценки отдельных специалистов Трудно выделить отдельный вклад каждого в разраб. ПС Трудно оценить труд специалистов по конечному продукту и индивидуально.
В коллективе индивидуальные характеристики усредняются.
Учет средний квалификации коллектива используются годы работы.
Отсутствуют методы измерения квалификации специалиста
Прикладное тестирование специалистов
При приеме на работу проходят :
психологическое тестирование
персонально тестирование
42 Документация, создаваемая и используемая в процессе разработки программных средств. Документация по сопровождению ПС.
Документальное обеспечение ПО важно не только для последующей эксплуатации разработанных систем ПО, но и для процесса проектирования. Документация должна создаваться по ходу проектирования, часть ее разрабатывается и используется непосредственно в процессе проектирования персоналом групп разработки, на различных этапах создания проекта.
При разработке ПС создается и используется большой объем разнообразной документации. Она необходима как средство передачи информации между разработчиками ПС, как средство управления разработкой ПС и как средство передачи пользователям информации, необходимой для применения и сопровождения ПС. На создание этой документации приходится большая доля стоимости ПС.
Эту документацию можно разбить на две группы:
документы управления разработкой ПС;
документы, входящие в состав ПС.
Документы управления разработкой ПС (software process documentation) управляют и протоколируют процессы разработки и сопровождения ПС, обеспечивая связи внутри коллектива разработчиков ПС и между коллективом разработчиков и менеджерами ПС (software managers) - лицами, управляющими разработкой ПС. Эти документы могут быть следующих типов:
планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения ПС;
отчеты об использовании ресурсов в процессе разработки. Создаются менеджерами;
стандарты. Эти документы предписывают разработчикам, каким принципам, правилам, соглашениям они должны следовать в процессе разработки ПС. Эти стандарты могут быть как международными или национальными, так и специально созданными для организации, в которой ведется разработка ПС;
рабочие документы. Это основные технические документы, обеспечивающие связь между разработчиками. Они содержат фиксацию идей и проблем, возникающих в процессе разработки, описание используемых стратегий и подходов, а также рабочие (временные) версии документов, которые должны войти в ПС;
заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками.
Документы, входящие в состав ПС (software product documentation), описывают программы ПС как с точки зрения их применения пользователями, так и с точки зрения их разработчиков и сопроводителей (в соответствии с назначением ПС). Здесь следует отметить, что эти документы будут использоваться не только на стадии эксплуатации ПС (в ее фазах применения и сопровождения), но и на стадии разработки для управления процессом разработки (вместе с рабочими документами) - во всяком случае, они должны быть проверены (протестированы) на соответствие программам ПС. Эти документы образуют два комплекта с разным назначением:
пользовательская документация ПС (П-документация);
документация по сопровождению ПС (С-документация).
Документация по сопровождению ПС (system documentation) описывает ПС с точки зрения ее разработки. Эта документация необходима, если ПС предполагает изучение того, как оно устроено (сконструировано), и модернизацию его программ. Сопровождение - это продолжающаяся разработка. Поэтому в случае необходимости модернизации ПС к этой работе привлекается специальная команда разработчиков-сопроводителей. Этой команде придется иметь дело с такой же документацией, которая определяла деятельность команды первоначальных (основных) разработчиков ПС, - с той лишь разницей, что эта документация для команды разработчиков-сопроводителей будет, как правило, чужой (она создавалась другой командой). Чтобы понять строение и процесс разработки модернизируемого ПС, команда разработчиков-сопроводителей должна изучить эту документацию, а затем внести в нее необходимые изменения, повторяя в значительной степени технологические процессы, с помощью которых создавалось первоначальное ПС.
Документацию по сопровождению ПС можно разбить на две группы:
документация, определяющая строение программ и структур данных ПС и технологию их разработки;
документация, помогающая вносить изменения в ПС.
Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС. Она включает следующие документы:
внешнее описание ПС (Requirements document);
описание архитектуры ПС, включая внешнюю спецификацию каждой ее программы (подсистемы);
для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;
для каждого модуля - его спецификация и описание его строения;
тексты модулей на выбранном языке программирования;
документы установления достоверности ПС, описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС.
Документы установления достоверности ПС включают, прежде всего, документацию по тестированию (схема тестирования и описание комплекта тестов).
Документация второй группы содержит руководство по сопровождению ПС, которое описывает особенности реализации ПС (в частности, трудности, которые пришлось преодолевать) и как учтены возможности развития ПС в его строении (конструкции). В нем также фиксируются, какие части ПС являются аппаратно- и программно-зависимыми. Общая проблема сопровождения ПС - обеспечить, чтобы все его представления шли в ногу (оставались согласованными), когда ПС изменяется. Чтобы этому помочь, связи и зависимости между документами и их частями должны быть отражены в руководстве по сопровождению, и зафиксированы в базе данных управления конфигурацией.
43 Пользовательская документация ПС.
Пользовательская документация ПС (user documentation) объясняет пользователям, как они должны действовать, чтобы применить разрабатываемое ПС. Она необходима, если ПС предполагает какое-либо взаимодействие с пользователями. К такой документации относятся документы, которыми должен руководствоваться пользователь при инсталляции ПС (при установке ПС с соответствующей настройкой на среду применения ПС), при применении ПС для решения своих задач и при управлении ПС (например, когда разрабатываемое ПС будет взаимодействовать с другими системами). Эти документы частично затрагивают вопросы сопровождения ПС, но не касаются вопросов, связанных с модификацией программ.
В связи с этим следует различать две категории пользователей ПС: ординарных пользователей ПС и администраторов ПС.
Ординарный пользователь ПС (end-user) использует ПС для решения своих задач (в своей предметной области). Это может быть инженер, проектирующий техническое устройство, или кассир, продающий железнодорожные билеты с помощью ПС. Он может и не знать многих деталей работы компьютера или принципов программирования.
Администратор ПС (system administrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ. Например, он может регулировать права доступа к ПС между ординарными пользователями, поддерживать связь с поставщиками ПС или выполнять определенные действия, чтобы поддерживать ПС в рабочем состоянии, если оно включено как часть в другую систему.
Состав пользовательской документации зависит от аудиторий пользователей, на которые ориентировано разрабатываемое ПС, и от режима использования документов. Под аудиторией здесь понимается контингент пользователей ПС, у которого есть необходимость в определенной пользовательской документации ПС. Удачный пользовательский документ существенно зависит от точного определения аудитории, для которой он предназначен. Пользовательская документация должна содержать информацию, необходимую для каждой аудитории. Под режимом использования документа понимается способ, определяющий, каким образом используется этот документ. Обычно пользователю достаточно больших программных систем требуются либо документы для изучения ПС (использование в виде инструкции), либо для уточнения некоторой информации (использование в виде справочника).
В соответствии с работами можно считать типичным следующий состав пользовательской документации для достаточно больших ПС:
общее функциональное описание ПС дает краткую характеристику функциональных возможностей ПС. Предназначено для пользователей, которые должны решить, насколько необходимо им данное ПС;
руководство по инсталляции ПС предназначено для администраторов ПС. Оно должно детально предписывать, как устанавливать системы в конкретной среде, файлы, представляющие ПС, и требования к минимальной конфигурации аппаратуры;
инструкция по применению ПС предназначена для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для ее изучения;
справочник по применению ПС предназначен для ординарных пользователей. Содержит необходимую информацию по применению ПС, организованную в форме удобной для избирательного поиска отдельных деталей;
руководство по управлению ПС предназначено для администраторов ПС. Оно должно описывать сообщения, генерируемые, когда ПС взаимодействует с другими системами, и как должен реагировать администратор на эти сообщения. Кроме того, если ПС использует системную аппаратуру, этот документ может объяснять, как сопровождать эту аппаратуру.
Разработка пользовательской документации начинается сразу после создания внешнего описания. Качество этой документации может существенно определять успех ПС. Она должна быть достаточно проста и удобна для пользователя (в противном случае, это ПС вообще не стоило создавать). Поэтому, хотя черновые варианты (наброски) пользовательских документов создаются основными разработчиками ПС, к созданию их окончательных вариантов часто привлекаются профессиональные технические писатели.
44 Стандартизация программной документации. ЕСПД. Классификация и обозначение стандартов ЕСПД. Назначение ЕСПД, область распространения ЕСПД.
Назначение ЕСПД
Единая система программной документации - комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ н программной документации.
В стандартах ЕСПД устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ, что обеспечивает возможность:
унификации программных изделий для взаимного обмена программами и применения ранее разработанных, программ в новых разработках;
снижения трудоемкости и повышения эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий;
автоматизации изготовления и хранения программной документации.
Сопровождение программы включает анализ функционирования, развитие и совершенствование программы, а также внесение изменений в нее с целью устранения ошибок.
Область распространения и состав ЕСПД
Правила и положения установленные в стандартах ЕСПД, распространяются на программы и программную документацию для вычислительных машин, комплексов и систем независимо от их назначения и области применения.
В состав ЕСПД входят:
основополагающие и организационно-методические стандарты;
стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;
стандарты, обеспечивающие автоматизацию разработки программных документов.
Разработка организационно-методической документации, определяющей и регламентирующей деятельность организаций по разработке, сопровождению и эксплуатации программ, должна проводиться на основе стандартов ЕСПД.
Классификация и назначение стандартов ЕСПД
Стандарты ЕСПД подразделяют на группы:
Код 0 - Общие положения
Код 1 - Основополагающие стандарты
Код 2 - Правила выполнения документации разработки
Код 3 - Правила выполнения документации изготовления
Код 4 - Правила выполнения документации сопровождения
Код 5 - Правила выполнения эксплуатационной документации
Код 6 - Правила обращения программной документации
Код 7 - Резервные группы
Код 8 - (хер знает, здесь ниче не было написано)
Код 9 - Прочие стандарты
Обозначения стандартов ЕСПД строят по классификационному признаку. Обозначение стандарта ЕСПД должно состоять из:
цифр 19, присвоенных классу стандартов ЕСПД;
одной цифры (после точки), обозначающей код классификационной группы стандартов;
двузначного числа, определяющего порядковый номер стандарта в группе;
двузначного числа (после тире), указывающего год регистрации стандарта.
Пример обозначения стандарта «Единая система программной документации. Общие положения» - Рисунок
45 Виды программных документов. Виды эксплутационных документов. Схемы алгоритмов.
Виды программных документов
Спецификация
Текст программы
описание программы
программа и методика испытаний
техническое задание
пояснительная записка
эксплуатационные документы (описание и применение)
Руководство системного программиста
руководство программиста
руководство оператора
Руководство системному программисту
Общие сведения о программе, структура программы (составные части, связи, объем памяти и т.п.)
Настройка программы (конкретное применение составляющих технических средств)
Проверка программы, контрольные примеры, дополнительные возможности, сообщения системному программисту, тексты сообщений.
Руководство программиста
Назначение, условия применения программы, характеристика ПС. Обращение к программе, способы передачи управления, вызов программы, входные, выходные данные, сообщение программисту.
Руководство оператора
Назначение программы. Условия выполнения программы, минимальный состав аппаратуры и программных средств для работы. Выполнение программы, действия оператора для выполнения программы, сообщения оператору.
Схемы алгоритмов
Схемы алгоритмов, программ, данных, систем состоят из имеющих заданное значение символов, краткого пояснительного текста и соединяющих линий. Схемы могут исполняться на различных уровнях детализации, причем число уровней зависит от размеров и сложности задач обработки данных. Уровень детализации должен быть таким, чтобы различные части и взаимосвязь между ними были понятны в целом.
Большааая картинка
46 Стадии разработки программной документации. Техническое задание. Требования к содержанию и оформлению.
|
Техническое задание |
Обоснование необходимости разработки ПС. |
Постановка задачи. Сбор исходных материалов, выбор обоснованных критериев качества, обоснование необходимости проведения научно-иссл. работ. |
|
|
Научно иссл. работы. |
Определение структуры входных-выходных данных. Предварительный выбор методов решения задач. Обоснование применения ранее разработанных программ, определение требований к техническим средствам, обоснование принципиальной возможности решения поставленной задачи. |
|
|
Разработка и утверждение ТЗ. |
Определение требований к ПС. Разработка технико-экономического обоснования. Определение сроков разработки. Выбор языка программирования. Определение необходимости проведения научно-иссл. работ на последующих стадиях. Согласование ТЗ. |
|
2. Эскизный проект. |
1. Разработка эскизного проекта |
Предварительная разработка структуры входных, выходных данных, уточнение методов решения задачи, общего описания алгоритма, решение задачи технико-экономического обоснования. |
|
|
2. Утверждение эскизного проекта |
Разработка пояснительной записки. Согласование утверждений эскизного проекта. |
|
3. Технический проект |
1. Разработка технического проекта |
Разработка структуры вход.-выход. Данных, алгоритма, разработка архитектуры прогр. Средства, окончательное определение конфигурации тех. средств. |
|
|
2. утверждение технического проекта |
Разработка плана мероприятий по разработке и внедрению ПС, разработка пояснительной записки, согласование утверждения тех. проекта. |
|
4. Рабочий проект |
1. Разработка ПС |
Программирование и отладка |
|
|
2. Разработка программной документации |
Разработка ПД в соответствии с требованиями ГОСТ |
|
|
3. Испытания ПС |
Разработка согласования утверждения программы и методики испытания, проведение предварительных, госуд. Испытаний, корректировка программ и программной документации по результатам испытаний. |
|
5. Внедрение |
Подготовка и передача программ. |
Эксплуатация, сопровождение, оформление акта о передачи программ. |
ТЗ. Требования к содержанию и оформлению.
Введение – наименование, краткая хар-ка области применения.
Основание для разработки. Должны быть указаны док-ты, на основании которых ведется разработка
Назначение разработки:
функциональное
эксплуатационное назначение ПС
требования к ПС
Разделы:
требования к функциональным характеристикам (состав функц, организ. Входных-выходн данных)
требования к надежности
условия эксплуатации (количество и квалификация персонала)
требования к техническим средствам
требования к информации и прогр. совместимость
специальные требования
Состав программной документации
Технико-экономические показатели
Этапы разработки (сроки)
Порядок контроля и приемки
47 Программа и методика испытаний. Текст программы, описание программы, пояснительная записка, описание применения (документация).
Программа и методика испытаний
Разделы:
Объект испытаний
цель испытаний
требования к ПС
состав программной документации
средства и порядок испытаний (технические, программные средства, используемые во время испытаний)
методы испытаний
описаний используемых методов
Определены описания проверок с указанием результатов, перечень тестовых примеров и т.д.
Текст программы
Это символическая запись на выбранном языке программирования с комментариями.
Описание программы
Разделы:
общие сведения (обозначения, язык, функциональное назначение, классы решаемых задач, ограничения, описание логической структуры, алгоритмы, используемые методы разработки, структура программы с описанием ф-й, составных частей, связей между ними, связи программы с другими программами, используемые технические средства, вызов и загрузка, входные данные, характер организации, выходные данные).
Пояснительная записка
Разделы:
Введение
Назначение, область применения, технические характеристики, постановка задачи, описание применяемых математических методов, описание алгоритма, возможное взаимодействие программы с другими программами, входные, выходные данные.
Ожидаемые технико-экономические показатели, источники, используемые при разработке.
Руководство системному программисту
Общие сведения о программе, структура программы (составные части, связи, объем памяти и т.п.)
Настройка программы (конкретное применение составляющих технических средств)
Проверка программы, контрольные примеры, дополнительные возможности, сообщения системному программисту, тексты сообщений.
Руководство программиста
Назначение, условия применения программы, характеристика ПС. Обращение к программе, способы передачи управления, вызов программы, входные, выходные данные, сообщение программисту.
Руководство оператора
Назначение программы. Условия выполнения программы, минимальный состав аппаратуры и программных средств для работы. Выполнение программы, действия оператора для выполнения программы, сообщения оператору.
48 Руководство системному программисту, руководство программисту, руководство оператору.
Руководство системному программисту
Общие сведения о программе, структура программы (составные части, связи, объем памяти и т.п.)
Настройка программы (конкретное применение составляющих технических средств)
Проверка программы, контрольные примеры, дополнительные возможности, сообщения системному программисту, тексты сообщений.
Руководство программиста
Назначение, условия применения программы, характеристика ПС. Обращение к программе, способы передачи управления, вызов программы, входные, выходные данные, сообщение программисту.
Руководство оператора
Назначение программы. Условия выполнения программы, минимальный состав аппаратуры и программных средств для работы. Выполнение программы, действия оператора для выполнения программы, сообщения оператору.
49 Общая характеристика состояния применения ЕСПД. Межгосударственные стандарты.
Общая характеристика состояния ЕСПД
Основу отечественной нормативной базы в области документирования ПС составляет Единое Средство Программной Документации. Разработана в 70-80е гг. Сейчас это комплекс представляет собой межгосударственные стандарты стран СНГ.
Стандарт ЕСПД охватывает документацию, которая создается в процессе разработки, связана с документированием функциональных характеристик программного средства.
Носят рекомендательный характер.
В соответствии с законом РФ о стандартизации эти стандарты становятся обязательными на контрактной основе (при ссылке в договоре). Большая часть стандартов ЕСПД морально устарела.
Недостатки ЕСПД:
Ориентация на единственную каскадную модель жизненного цикла
отсутствие четких рекомендаций по документированию характеристик качества
Отсутствие системной связки с другими отечественными стандартами по жизненному циклу и документированию продукции в целом.
Нечетко выраженный подход к документированию ПС как товарной продукции
Отсутствие рекомендации по самодокументированию (справка)
Отсутствие рекомендации по составу, содержанию и оформлению перспектив документов по ПС.
ЕСПД нуждается в полном пересмотре на основании стандартов ISO.
Другие межгосударственные стандарты:
Обеспечение систем обработки информации – программные термины и определения. Стандарт устанавливает термины и определения систем обработки данных, применяемых во всей документации и литературе.
Система обработки информации, документы на машинных носителях. Данные, порядок выполнения, распространяются не только на конструкторские, технологические и другие документы на магнитных носителях.
Государственные стандарты:
ГОСТ Р. Информационные технологии, руководство по управлению документами ПО, устанавливает рекомендации по эффективному управлению документацией для руководителя;
ГОСТ Р. Информационная технология, оценка программной продукции, характеристики качества и руководства по их применению.
Хар. Качества – набор свойств программной продукции, по которым качество описывается и оценивается (надежность, практичность, эффективность, мобильность, сопровождаемость).
ГОСТ Р. Система обработки информации, документация пользователя и информация на упаковке для потребителей программных пакетов.
ГОСТ Р. Информационная технология, программные конструктивы и обозначения для их представления, описывает представление процедурных алгоритмов.
50 Основные понятия и показатели надежности ПС. Надежность технических средств и ПО.
Надежность ПО – это свойство системы выполнять заданные функции, сохраняя во времени значения установленных эксплутационных показателей в заданных пределах, соответствующих заданным режимам и условиям исполнения. Потеря надежности связывается с появлением отказов в работе. Другими словами надежность ПО – это вероятность того, что программа какой-то период времени будет работать без сбоев с учетом степени их влияния на выходные результаты.
Под показателем надежности принято понимать величину или совокупность величин, характеризующих качественно или количественно степень приспособленности систем к выполнению поставленной задачи. Имеются три вида показателей надежности сложных систем: качественные, порядковые и количественные.
Качественные показатели надежности не могут быть выражены в виде числа и не содержат информации, позволяющей обосновать предпочтение одного из нескольких конкурирующих вариантов системы при их сравнении. Качественные показатели указывают на какие-либо свойства системы. Качественные показатели дают возможность отличать системы друг от друга.
Порядковые показатели надежности содержат информацию, позволяющую обосновать предпочтение одного из вариантов системы при их сравнении без количественной оценки степени предпочтения. Порядковые показатели дают возможность расположить в ряд по степени возрастания надежности исследуемые варианты системы, но не позволяют оценить, на какую величину отличается достигнутый уровень надежности рассматриваемых вариантов.
Количественные показатели надежности выражают надежность в виде числа. Они определяются путем непосредственных статистических наблюдений на основе обработки результатов применения или испытания систем. А также путем аналитических расчетов или моделирования процесса функционирования систем.
В первых работах по теории надежности ПО заимствованы основные положения теории аппаратной надежности. В ряде исследований вопроса надежности ПО показатель надежности рассматривался как функция времени наработки. ПО не изменяется существенно по мере наработки, а изменяется в результате устранения ошибок.
51 Дестабилизирующие факторы и методы обеспечения надежности ПС.
При строго фиксированных исходных данных программа исполняется по определенному маршруту, выдает определенные результаты. Многочисленные варианты использования программы с различными входными данными представляются для внешнего наблюдателя как случайные.
Дефекты работы ПС, не имеющие злоумышленных источников, появляются как случайные, имеют разную природу и последствия. Они могут приводить к последующим нарушениям работоспособности и к отказам ВС.
Объекты уязвимости
Вычислительный процесс
БД
Объектный код программы
Информация для потребителя
Дестабилизирующие факторы и угрозы надежности
Внутренние
Ошибки проектирования
ошибки в алгоритмах
ошибки программирования
недостаточное качество средств защиты
Внешние
ошибки персонала
искажение инф-ии в каналах связи
сбои и отказы аппаратуры
изменение конфигурации системы
Методы предотвращения внутренних угроз надежности
предотвращение ошибок и проектирование в CASE-системах
систематическое тестирование
обязательная сертификация
Оперативные методы повышения надежности
временнАя избыточность
программная избыточность
информационная избыточность
Последствия нарушения надежности
разрушение ВП
разрушение информации в БД
разрушение текстов программ
разрушения информации для потребителя
52 Модели надежности ПО.
Термин «модель надежности ПО» относится к математической модели, построенной для надежности ПО от некоторых определенных параметров.
Значение параметров предполагается известным либо они могут быть измерены в ходе наблюдений или экспериментального исследования процесса работы ПО.
Модели надежности ПО подразделяются на
аналитические
эмпирические
Аналитические модели дают возможность рассматривать количественные показатели надежности, основываясь на данных поведения программы в процессе тестирования.
Эмпирические модели базируются на анализе структурных особенностей программы, рассматривают зависимость показателей надежности от числа межмодульных связей, отношение количества прямолинейных участков программы к количеству точек ветвления. Часто эмпирические модели не дают конечных результатов показателей надежности. Эти модели позволяют выявить взаимодействие между сложностью ПС и надежностью.
Эти модели можно использовать на этапе проектирования, когда осуществлена разбивка на модули, известна структура ПС.
53 Аналитические модели надежности (динамические).
Аналитические модели дают возможность рассматривать количественные показатели надежности, основываясь на данных поведения программы в процессе тестирования.
В динамических моделях поведение ПС (появление отказа) рассматривается во времени.
Для использования динамических моделей необходимо иметь данные о появлении отказов во времени.
Если фиксируются интервалы каждого отказа, то получается непрерывная картинка появления отказов во времени (группа динамических моделей с непрерывным временем).
Может фиксироваться количество отказов за произведенный интервал времени.
Поведение ПС может быть представлено только в дискретных точках (группа динамических моделей с дискретным временем).
Классификация динамических аналитических моделей:
дискретные
модель Шумана
модифицированная модель Шумана
модель La Padula
Модель Шика, Вольвертона
непрерывные
модель Дженинского-Моранды
модель Мусса
модель переходных вероятностей
54 Аналитические модели надежности (статические).
Аналитические модели дают возможность рассматривать количественные показатели надежности, основываясь на данных поведения программы в процессе тестирования.
В статических моделях появление отказа не связывают со временем, а учитывают зависимость ошибок от числа тестовых прогонов (по области ошибок), или зависимость кол-ва ошибок от характеристики входных данных (по области данных).
Классификация статических аналитических моделей надежности
по области ошибок
модель Миллса
модель Липова
простая интуитивная модель
модель Каркорена
по области данных
модель Нельсона
55 Эмпирические модели надежности.
Эмпирические модели базируются на анализе структурных особенностей программы, рассматривают зависимость показателей надежности от числа межмодульных связей, отношение количества прямолинейных участков программы к количеству точек ветвления. Часто эмпирические модели не дают конечных результатов показателей надежности. Эти модели позволяют выявить взаимодействие между сложностью ПС и надежностью.
Классификация эмпирических моделей надежности
модель сложности
модель определения времени доводки программы