Организационные процессы жизненного цикла программных средств
Принципы проектирования пользовательских интерфейсов
| Принцип | Описание |
| Учет знаний пользователя | В интерфейсе необходимо использовать термины и понятия, взятые из опыта будущих пользователей системы. |
| Согласованность | Интерфейс должен быть согласованным в том смысле, что однотипные (но различные) операции должны выполняться одним и тем же способом. |
| Минимум неожиданностей | Поведение системы должно быть прогнозируемым. |
| Руководство пользователя | Интерфейс должен предоставлять необходимую информацию в случае ошибок пользователя и поддерживать средаства контекстно-зависимой справки |
| Учёт разнородности пользователей | В интерфейсе должны быть средства для удобного взаимодействия с пользователями, имеющий разный уровень квалификации и различные возможности |
Взаимодействие с пользователем
Разработчику интерфейса пользователя надо решить две главные задачи, каким образом пользователь будет вводить данные в систему и как данные будут представлены пользователю. Необходимо использовать различные стили взаимодействия для управления разными системными объектами.
Все виды взаимодействия можно отнести к одному из 5 основных стилей взаимодействия:
Непосредственное манипулирование.
Выбор из меню.
Заполнение форм.
Командный язык.
Естественный язык.
Преимущества и недостатки стилей взаимодействия пользователя с системой
| Стиль взаимодействия | Основные преимущества | Основные недостатки | Примеры приложений |
| Прямое манипулирование | Быстрое и интуитивно понятное взаимодействие. Легок в изучении | Сложная реализация. Подходит только там, где есть зрительный образ задач и объектов | Видеоигры, системы автоматического проектирования |
| Выбор из меню | Сокращение количества ошибок пользователя. Минимальный ввод с клавиатуры. | Медленный вариант для опытных пользователей. Может быть сложным, если меню состоит из большого количества вложенных пунктов. | Главным образом системы общего назначения |
| Заполнение форм | Простой ввод данных. Легок в изучении | Занимает пространство на экране. | Системы управления запасами, обработка финансовой информации. |
| Командный язык | Мощный и гибкий | Труден в изучении. Сложно предотвратить ошибки ввода. | ОС, библиотечные системы. |
| Естественный язык | Подходит неопытным пользователям. Легко настраивается. | Требует большого ручного набора | Системы расписания, системы хранения данных WWW |
Модель с разделенными интерфейсом командного языка и графическим интерфейсом, лежащая в основе некоторых операционных систем
(в частности, Linux)
Представление информации
В любой информационной системе должны быть средства для представления данных пользователям. Хорошим тоном при проектировании систем является отделение представления данных от самих данных.
После того, как представление данных в системе отделено от самих данных, изменения в представлении данных на экране пользователя происходит без изменения самой системы.
Основные принципы и методы объектно-ориентированного анализа и проектирования.
Основная идея объектно-ориентированного анализа и проектирования (object-oriented analysis and design) состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов (понятий и сущностей). В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов (или понятий) в терминах предметной области. В процессе объектно-ориентированного проектирования определяются логические программные объекты, которые будут реализованы средствами объектно-ориентированного языка программирования. Эти программные объекты включают в себя атрибуты и методы. И, наконец, в процессе конструирования (construction) или объектно-ориентированного программирования (object-oriented programming) обеспечивается реализация разработанных компонентов и классов.
Рассмотрим вкратце некоторые основные принципы объектно-ориентированного анализа и проектирования, в дальнейшем мы дадим более точные определения и более полную расшифровку всех рассмотренных терминов.
С начала производится так называемый анализ требований (requirements analysis) во время которого выделяются основные процессы, происходящие в моделируемой системе и их формулировка в виде прецедентов. Прецедент (precedent)- это текстовое описание процессов, происходящих в предметной области.
Шаг второй. Объектно-ориентированный анализ предметной области (object-oriented domain analysis). Задача этого шага в определении видов деятельности участников процесса и составлении концептуальной модели (conceptual model), которая отражает различные категории элементов предметной области. Причем не только виды деятельности участников, но и все относящиеся к делу понятия.
Шаг третий. Разбираемся, кто, чем занимается. Эта деятельность и называется объектно-ориентированным проектированием (object-oriented design), при котором основное внимание сосредоточено на распределении обязанностей. Распределение обязанностей (responsibility assignment) означает выделение задач и обязанностей различных программных объектов в приложении.
Наиболее важным моментом объектно-ориентированного анализа и проектирования является квалифицированное распределение обязанностей между компонентами программной системы. Дело в том, что единственный вид деятельности, без которого невозможно обойтись. К тому же он оказывает определяющее влияние на робастность, масштабируемость, расширяемость и возможность повторного использования компонентов. Обязанности объектов и их взаимодействия изображаются с использованием диаграмм классов (design class diagram) и диаграмм взаимодействий (collaboration diagram).
21.
Абстрагирование
Абстрагирование является одним из главных способов, используемых для решения сложных задач. Хоаре предположил, что "абстрагирование заключается в нахождении сходств между определенной совокупностью объектов, ситуаций или процессов, имеющих место в реальности, и в принятии решений на основе этих сходств, отвлекаясь на время от имеющихся отличий между этими объектами". Шоу определил это понятие так: "Упрощенное описание или изложение системы, при котором одни свойства и детали выделяются, а другие опускаются. Хорошей является такая абстракция, при которой подчеркиваются существенные для рассмотрения и использования детали и опускаются, те которые на данный момент несущественны и отвлекают внимание". Берзинс, Грей и Науман добавили к этому следующее: "Абстракцией является только такая идея, которая может быть изложена, понята и проанализирована независимо от механизма ее реализации". Суммируя:
Абстракция - это такие существенные характеристики некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют особенности данного объекта с точки зрения дальнейшего рассмотрения и анализа.
Типизация
Концепция типизации строится на понятии типов абстрактных данных. По определению Дейтча: "Тип - это точное определение свойств строения или поведения, которое присуще некоторой совокупности объектов"
Типизация - это ограничение, накладываемое на класс объектов и препятствующее взаимозамене различных классов ( или сильно сужающее возможность такой взаимозамены).
Типизация позволяет выполнять описание абстракций таким образом, что реализуется поддержка проектных решений на уровне языка программирования.
Иерархия, наследование
Абстракция - вещь полезная, но всегда, кроме самых простых ситуаций, число абстракций в системе намного превышает возможности их одновременного контроля. Ограничения доступа позволяет в какой-то степени устранить это препятствие, убрав из поля зрения внутреннее содержание абстракций. Модульность также упрощает задачу, объединяя логически связанные абстракции в группы. Но этого оказывается недостаточно.
Значительное упрощение в понимании сложных задач достигается за счет образования иерархической структуры из абстракций.
Иерархия - это ранжированная или упорядоченная система абстракций.
Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу).
22. Унифицированный язык моделирования (UML)
Свою историю унифицированный язык объектно-ориентированного моделирования ведет с конца 80х – начала 90х годов. Собственно создание UML началось в 1994 году. В это время Грэйди Буч (Grady Booch) и Джеймс Рэмбо (James Rambaugh) начали объединять несколько методов объектно-ориентированного моделирования в фирме Rational Software. И уже в 1995 году была представлена спецификация метода, названного Unified Method. Первая версия UML была принята консорциумом OMG (Object Management Group) в январе 1997 года. Утвержденная же в сентябре версия UML 1.1 была принята на вооружение основными компаниями – производителями программного обеспечения, такими, как Microsoft, IBM, Hewlett-Packard и производителями CASE-средств, которые реализовали поддержку UML в своих программных продуктах (Paradigm Plus, Microsoft Visual Modeler for Visual Basic, Delphi и др.)
Авторы и разработчики UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и других систем различной природы. UML определяет нотацию и метамодель. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования.
Универсальный язык объектного моделирования UML не зависит от языков программирования и, вследствие этого, может поддерживать любой объектно-ориентированный язык программирования. Он является открытым и позволяет расширять ядро.
Визуальные модели широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. В практике эксплуатации программных информационных систем постоянно приходится решать такие задачи как перераспределение вычислений и данных, обеспечение проведения параллельных вычислений, репликация баз данных, обеспечение безопасности доступа к информационным системам, оптимизация балансировки нагрузки систем, устойчивость к сбоям и многое другое.
Языки и методы моделирования состоят, как правило, из следующих составных частей:
1. Концепции моделирования, их семантика.
2. Визуальное представление элементов моделирования
3. Правила применения элементов моделирования.
Первый компонент – это элементы модели, второй – нотация и третий – принципы использования.
Одной из важных проблем, решаемых при применении визуальных методов моделирования, является все возрастающая сложность систем и проектов. Наступает момент, когда становится невозможным представить всю систему в целом, появляется отрывочность знаний о системе, и происходит потеря управления.
Второе значительное достоинство – упрощение общения заказчика и разработчика. Это связано как с повышенной наглядностью модели, так и с ее гибкостью и динамичностью.
Само собой, решаются вопросы уменьшения времени, затрачиваемого на разработку проекта, его стоимости и повышения качества.
Декомпозиция систем
При проектировании сложных информационных систем требуется, для обеспечения наглядности и во избежание потери управления, разбиение системы на части, которые затем рассматриваются отдельно. Различают два вида декомпозиции:
· Структурная
· Объектная
В первом случае система представляется в виде блок-схем, где узлы – это функции, а связи между ними изображают движение данных. При объектной, или компонентной декомпозиции в системе выделяются объекты, взаимодействующие между собой по принципу “клиент-сервер”. Вот в этом случае и применяется UML для моделирования систем.
Диаграммы в UML
Вот основные типы диаграмм, представленные в UML:
1. Диаграммы использования
2. Диаграммы классов
3. Диаграммы поведения
4. Диаграммы реализации
Диаграммы использования описывают функциональность системы. Это изображается в виде так называемых случаев использования (use case), которые определяют взаимодействие пользователя с системой. Они рисуются в виде овалов.
Диаграммы классов представляют статическую структуру классов. Применение – формирование программного кода на заданном языке программирования.
Диаграммы поведения описывают динамику системы.
* *
Методы проектирования с использованием UML
В Microsoft Visual Studio 6.0 реализованы несколько видов нотации для изображения диаграмм классов, как “старые” - нотации Буча и ОМТ, так и новая – UML. Генерация программного кода производится на языках C++, Visual Basic, Java. Код содержит определения классов и их взаимодействия, но не методы. Это метод прямого проектирования.
При использовании обратного проектирования диаграмма классов строится по готовому программному коду.
Не стоит путать понятия нотация и методология проектирования. UML – это лишь нотация, которая требует стандартизирования и она уже является стандартом. Методологии же невозможно привести к единому стандарту, да и вряд ли это необходимо. Нотацию UML можно использовать в рамках различных методологий.
В настоящее время консорциум Object Management Group рассматривает возможность внедрения новой версии UML 1.3 как нового стандарта визуального моделирования.
23. Стандарты
1.ГОСТ Р ИСО/МЭК 9294-93. Информационная технология. Руководство по управлению документированием программного обеспечения.
2.ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции, характеристика качества и руководство по их применению.
3.ГОСТ Р ИСО/МЭК 9127-94. Системы обработки информации. Документация пользоввателя и информация на упаковке для потребительских программных пакетов.
4.ГОСТ Р ИСО/МЭК 8631-94. Информационная технология. Программные конструктивы и условные обозначения для их представления.
5.ГОСТ Р ИСО/МЭК 12119:1994. Информационная технология. Пакеты программных средств. Требования к качеству и испытания.
6.ГОСТ Р ИСО/МЭК 12207-99. Процессы жизненного цикла программных средств.
24. Международные стандарты ISO серии 9000 и стандарты в системе сертификации ГОСТ Р.[/B]
Основное преимущество международных стандартов ISO серии 9000, заключается в их универсальности. Они не устанавливают абсолютных критериев качества для отдельного вида продукции или услуг, а только задают основную методологию функционирования и саморегулирования системы качества с учетом изменения запросов потребителя.
Кроме того, многие организации требуют наличие сертификата соответствия систем качества у поставщиков продукции. Из чего можно сделать вывод, что системы качества по стандартам ISO серии 9000 внедряются для того, чтобы дать предприятиям большую уверенность в поставщиках, а потребителям в качестве приобретаемых товаров.
Сертификация Систем Менеджмента Качества по стандартам ISO серии 9000 не является обязательным требованием к производителям. И даже в странах, где развитие промышленности находится на более высоком уровне сертификация по этим стандартам, обязательна только в отраслях, где от обеспечения соответствующего уровня качества продукции зависит безопасность людей. Однако, именно наличие сертификата ISO 9000, является залогом конкурентоспособности компании не только на национальном, но и на международном уровне.
Международные стандарты ISO серии 9000 получили признание во многих странах с развитой рыночной экономикой, и с 2001 г. на территории Российской Федерации действует аутентичная данным стандартам серия стандартов ГОСТ Р ИСО 9001-2001 версии 2001 г.
Стандарты семейства ISO 9000
ISO 9000:2000 Системы менеджмента качества (в России действует, как стандарт ГОСТ Р ИСО 9000-2001). Основные положения и словарь - введение в СМК и словарь терминов;
ISO 9001:2000 Системы менеджмента качества (в России действует, как стандарт ГОСТ Р ИСО 9001-2001). Требования. Устанавливает минимально необходимый набор требований к Системам Качества и применяется для достижения целей сертификации и проверок;
ISO 9004:2000 Системы менеджмента качества (в России действует, как стандарт ГОСТ Р ИСО 9004-2001). Рекомендации по улучшению деятельности. Содержит методические указания по разработке и внедрению Систем Менеджмента Качества, которые ориентированы на высокую эффективность деятельности компаний;
ISO 19011:2000 Рекомендации по аудиту систем менеджмента качества и/или охраны окружающей среды (в России действует как ИСО/ПМС 19011:2002). Содержит рекомендации по проведению проверок Систем Менеджмента Качества и Экологического Менеджмента, управлению программами аудитов;
ISO 10012 Обеспечение качества измерительного оборудования.
25 вопрос, если еще нужен
Спецификация качества определяет основные ориентиры (цели), которые на всех этапах разработки ПС так или иначе влияют при принятии различных решений на выбор подходящего варианта. Однако, каждый примитив качества имеет свои особенности такого влияния, тем самым, обеспечения его наличия в ПС может потребовать своих подходов и методов разработки ПС или отдельных его частей. Кроме того, отмечалась также противоречивость критериев качества ПС и выражающих их примитивов качества: хорошее обеспечение одного какого-либо примитива качества ПС может существенно затруднить или сделать невозможным обеспечение некоторых других из этих примитивов. Поэтому существенная часть процесса обеспечения качества ПС состоит из поиска приемлемых компромиссов. Эти компромиссы частично должны быть определены уже в спецификации качества ПС: модель качества ПС должна конкретизировать требуемую степень присутствия в ПС каждого его примитива качества и определять приоритеты достижения этих степеней.
Множество характеристик качества программных средств можно разделить на две принципиально разли-чающихся группы:
- функциональные характеристики (функциональ-ность) - определяющие назначение, свойства и задачи, решаемые комплексом программ для основных пользова-телей, отличающиеся очень широким спектром и разно-образием, состав и специфику которых трудно унифици-ровать и можно категоризировать только по большому количеству классов и свойств ПС;
- конструктивные характеристики качества, номенк-латура которых может быть унифицирована, адаптирова-на и использована для описания остальных, внутренних и внешних, стандартизируемых характеристик качества, поддерживающих реализацию основных, функциональ-ных требований к качеству объектов и процессов ЖЦ программных средств.
Номенклатура второй группы этих характеристик от-носительно не велика, и стандартами рекомендуется в составе: корректности, защищенности, надежности, ре-сурсной эффективности, практичности, сопровождаемо-сти и мобильности.
Две группы характеристик качества ПС - Надежность и Эффективность в наибольшей степени доступны коли-чественным измерениям. Для них в таблице 3 представ-лены примеры возможных мер и шкал измерения основ-ных количественных атрибутов субхарактеристик качест-ва. Они могут служить ориентирами при выборе и уста-новлении требуемых значений этих показателей качества в спецификациях ПС.
Надежность: свойства комплекса программ обеспечи-вать достаточно низкую вероятность потери работоспо-собности - отказа в процессе функционирования ПС в реальном времени. Стандартом ISO 9126:2 рекомендуется анализировать и учитывать четыре субхарактеристики и до 16-ти количественных атрибутов надежности, в том числе степень покрытия тестами структуры программ. Надежность функционирования ПС наиболее полно ха-рактеризуется устойчивостью или способностью к безот-казному функционированию и восстанавливаемостью работоспособного состояния после произошедших сбоев или отказов. В свою очередь устойчивость зависит от уровня не устраненных дефектов и ошибок (завершен-ность) и способности ПС реагировать на их проявления так, чтобы это не отражалось на показателях надежности. Последние, определяются эффективностью контроля данных, поступающих из внешней среды и от средств обнаружения аномалий функционирования ПС. В реаль-ных условиях по различным причинам исходные данные могут попадать в области значений, не проверенные при разработке и испытаниях, а также не заданные требова-ниями спецификации и технического задания, вызываю-щие сбои и отказы. При этом не корректная программа может функционировать совершенно надежно. Следова-тельно, надежность функционирования программ являет-ся понятием динамическим, проявляющимся во времени, и существенно отличается от понятия статической кор-ректности программ.
Завершенность: свойство ПС не попадать в состояния отказов вследствие ошибок и дефектов в программах и данных. Количество или плотность проявления скрытых и не обнаруженных дефектов и ошибок непосредственно отражается на длительности нормального функциониро-вания комплекса программ между сбоями и отказами. Завершенность можно характеризовать наработкой (дли-тельностью) на отказ при отсутствии автоматического восстановления - рестарта, измеряемой обычно часами. На эту субхарактеристику надежности влияют только отказы, вследствие проявившихся дефектов. Они могут быть обусловлены не полным тестовым покрытием при испытаниях компонентов и ПС в целом, а также недоста-точной завершенностью их тестирования.
Устойчивость к дефектам и ошибкам: свойство ПС автоматически поддерживать заданный уровень качества функционирования в случаях проявления дефектов и ошибок или нарушения установленного интерфейса. Для этого в ПС должна вводиться временная, программная и информационная избыточность, реализующая оператив-ное обнаружение дефектов и ошибок функционирования, их идентификацию и автоматическое восстановление (рестарт) нормального функционирования ПС. Эффек-тивное, оперативное устранение проявления дефектов, ошибок и некорректного взаимодействия с операционной и внешней средой определяют субхарактеристику - ус-тойчивость комплексов программ. Относительная доля вычислительных ресурсов, используемых непосредствен-но для быстрой ликвидации последствий отказов и опе-ративного восстановления нормального функционирова-ния ПС (рестарт) отражается на повышении надежности программ. Наработка на отказ при наличии оперативного рестарта определяет значение устойчивости.
Восстанавливаемость: свойство ПС в случае отказа возобновлять требуемый уровень качества функциониро-вания, а также поврежденные программы и данные. По-сле отказа ПС иногда бывает неработоспособно в течение некоторого периода времени, продолжительность которо-го определяется его восстанавливаемостью. Для этого необходимы вычислительные ресурсы и время на выяв-ление и прерывание неработоспособного состояния, ди-агностику причин отказа, а также на реализацию процес-сов восстановления. Основными показателями процесса восстановления являются его длительность и вероятност-ные характеристики. Восстанавливаемость характеризу-ется также полнотой восстановления нормального функ-ционирования программ в процессе ручного или автома-тического их перезапуска - рестарта. Перезапуск должен обеспечивать возобновления нормального функциониро-вания ПС, на что требуются ресурсы ЭВМ и время, кото-рые можно характеризовать относительной величиной (% от общих ресурсов). Поэтому полнота и длительность восстановления после сбоев и отказов определяет надеж-ность ПС и его функциональную пригодность для ис-пользования по прямому назначению.
Доступность или готовность: свойство ПС быть в со-стоянии выполнять требуемую функцию в данный мо-мент времени при заданных условиях использования. Внешне, доступность может оцениваться относительным временем, в течение которого ПС находится в работоспо-собном состоянии, в пропорции к общему времени при-менения. Следовательно, доступность - комбинация за-вершенности (от которой зависит частота отказов), ус-тойчивости к ошибкам и восстанавливаемости, которые в совокупности обусловливают длительность простоя для рестарта после каждого отказа, а также длительности наработки на отказ. Для определения этой величины из-меряется время работоспособного состояния комплекса программ между последовательными отказами. Обобще-ние характеристик отказов и восстановления производит-ся в критерии коэффициент готовности. Этот показатель отражает вероятность иметь восстанавливаемые про-граммы и данные в работоспособном состоянии в произ-вольный момент времени.
27-29
Термин модель надежности программного обеспечения, как правило, относится к математической модели, построенной для оценки зависимости надежности программного обеспечения от некоторых определенных параметров. Значения таких параметров либо предполагаются известными, либо могут быть измерены в ходе наблюдений или экспериментального исследования процесса функционирования программного обеспечения. Данный термин может быть использован также применительно к математической зависимости между определенными параметрами, которые хотя и имеют отношение к оценке надежности программного обеспечения, но тем не менее не содержат ее характеристик * в явном виде. Например, поведение некоторой ветви программы
>юдмножесгве наборов входных данных, с помошью которых ветвь контролируется, существенным образом связано с на-;ностью программы, однако характеристики этого поведения I могут быть оценены независимо от оценки самой надежности. I Другим таким параметром является частота ошибок, которая по-] зволяет оценить именно качество систем реального времени, фун-юнирующих в непрерывном режиме, и в то же время получать ько косвенную информацию относительно надежности про-| граммного обеспечения (например, в лредпотожении экспонен-1ального распределения времени между отказами).
Одним из видов модели надежности программного обеспече-1Я, которая заслуживает особого внимания, является так назы-1емая феноменологическая, и и эмпирическая, модель. При разработке моделей такого типа предполагается, что связь между надежностью и другими параметрами является статической. С помощью подобного подхода пытаются количественно оценить шрактеристики программного обеспечения, которые свидетельствуют либо о высокой, либо о низкой его надежности. Так, например, параметр сложность программы характеризует степень уменьшения уровня ее надежности, поскольку усложнение программы всегда приводит к нежелательным последствиям, в том числе к неизбежным ошибкам программистов при составлении программ и трудности их обнаружения и устранения. Иначе говоря, при разработке феноменологической модели надежности программного обеспечения стремятся иметь дело с такими параметрами, соответствующее изменение значений которых должно приводить к повышению надежности программного обеспечения [54].
Рассмотрим классификацию моделей надежности ПС, приведенную на рис. 4.3. Модели надежности программных средств (МНПС) подразделяются на аналитические и эмпирические. Аналитические модели дают возможность рассчитать количественные показатели надежности, основываясь на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели). Эмпирические модели базируются на анализе струк-| турных особенностей программ. Они рассматривают зависимость ;азателей надежности от числа межмодульных связей, количе-а циклов в модулях, отношения количества прямолинейных | участков программы к количеству точек ветвления и т.д. Часто
Эмпирические модели не дают конечных результатов показателей надежности, однако они включены в классификационную схему, гак как развитие этих моделей позволяет выявлять взаимосвязь между сложностью ПС и его надежностью. Эти модели можно использовать на этапе проектирования ПС, когда осуществлена разбивка на модули и известна его структура.
Аналитические модели представлены двумя группами: динамические модели и статические. В динамических МНПС поведение ПС (появление отказов) рассматривается во времени. В статических моделях появление отказов не связывают со временем, а учитывают только зависимость количества ошибок от числа тесто-иых прогонов (по области ошибок) или зависимость количества ошибок от характеристики входных данных (по области данных).
Для использования динамических моделей необходимо иметь
/(анные о появлении отказов во времени. Если фиксируются ин
тервалы каждого отказа, то получается непрерывная картина
появления отказов во времени (группа динамических моделей с
непрерывным временем). Может фиксироваться только число
отказов за произвольный интервал времени. В этом случае пове
дение ПС может быть представлено только в дискретных точках
(группа динамических моделей с дискретным временем). Рассмот
рим основные предпосылки, ограничения и математический ап
парат моделей, представляющих каждую группу, выделенную по
схеме. ,лм
Аналитические модели надежности ис-
Аналитическое моделирование надежности ПС включает четыре шага:
определение предположений, связанных с процедурой тес
тирования ПС;
разработка или выбор аналитической модели, базирующей
ся на предположениях о процедуре тестирования;
выбор параметров моделей с использованием полученных
данных;
применение модели — расчет количественных показателей
надежности по модели.
Динамические модели надежности.
где N — число ошибок, первоначально присутствующих в программе; С — коэффициент пропорциональности.Наиболее вероятные значения величин N и С (оценка максимального правдоподобия) можно определить на основе данных, полученных при тестировании. Для этого фиксируют время выполнения программы до очередного отказа t\, ti, h, ... , tk-
Значения N и с предлагается получить, решив систему урав-| нений:
Поскольку полученные значения N и С — вероятностные , точность их зависит от количества интервалов тестирования (ил1Ц количества ошибок), найденных к моменту оценки надежности, асимптотические оценки дисперсий авторы предлагают опреде-, лить с помощью следующих формул:
Чтобы получить числовые значения Я,, нужно подставить вместо N и С их возможные значения N и С . Рассчитав К значений но формуле (11) и подставив их в формулу (10), можно определить вероятность безотказной работы на различных временных интервалах. На основе полученных расчетных данных строится график зависимости вероятности безотказной работы от времени.
Модель Шика - Волвертона. Модификация модели Джелин-ского - Моранды для случая возникновения на рассматриваемом интервале более одной ошибки предложена Волвертоном и Шиком. При этом считается, что исправление ошибок производится лишь после истечения интервала времени, на котором они возникли. В основе модели Шика - Волвертона лежит предположение, согласно которому частота ошибок пропорциональна не только количеству ошибок в программах, но и времени тестирования, т.е. вероятность обнаружения ошибок с течением времени возрастает. Частота ошибок (интенсивность обнаружения ошибок) Я, предполагается постоянной в течение интервала времени t\ и пропорциональна числу ошибок, оставшихся в программе по истечении (f-l)-ro интервала; но она пропорциональна также и суммарному времени, уже затраченному на тестирование (включая среднее время выполнения программы в текущем интервале):
В данной модели наблюдаемым событием является число ошибок, обнаруживаемых в заданном временном интервале, а не время ожидания каждой ошибки, как это было для модели Джелин-ского - Моранды. В связи с этим модель относят к группе дискретных динамических моделей. Модель Муса. Модель Муса относят к динамическим моделям непрерывного времени. Это значит, что в процессе тестирования фиксируется время выполнения программы (тестового прогона) до очередного отказа. Но считается, что не всякая ошибка ПС может вызвать отказ, поэтому допускается обнаружение более одной ошибки при выполнении программы до возникновения очередного отказа.
Считается, что на протяжении всего жизненного цикла ПС может произойти Мо отказов и при этом будут выявлены все No ошибки, которые присутствовали в ПС до начала тестирования.
Общее число отказов Мо связано с первоначальным числом ошибок No соотношением
(14)
где
В — коэффициент уменьшения числа ошибок.
30-32
Отладка = Тестирование + Поиск ошибок + Редактирование.
В зарубежной литературе отладку часто понимают [10.1-10.3] только как процесс поиска и исправления ошибок (без тестирования), факт наличия которых устанавливается при тестировании. Иногда тестирование и отладку считают синонимами [10.4,10.5]. В нашей стране в понятие отладки обычно включают и тестирование [10.6 -10.8], поэтому мы будем следовать сложившейся традиции. Впрочем совместное рассмотрение в данной лекции этих процессов делает указанное разночтение не столь существенным. Следует однако отметить, что тестирование используется и как часть процесса аттестации ПС (см. лекцию 14).
При автономной отладке каждый модуль на самом деле тестируется в некотором программном окружении, кроме случая, когда отлаживаемая программа состоит только из одного модуля. Это окружение состоит [10.8] из других модулей, часть которых является модулями отлаживаемой программы, которые уже отлажены, а часть - модулями, управляющими отладкой (отладочными модулями, см. ниже). Таким образом, при автономной отладке тестируется всегда некоторая программа, построенная специально для тестирования отлаживаемого модуля. Эта программа лишь частично совпадает с отлаживаемой программой, кроме случая, когда отлаживается последний модуль отлаживаемой программы. По мере продвижения отладки программы все большую часть окружения очередного отлаживаемого модуля будут составлять уже отлаженные модули этой программы, а при отладке последнего модуля этой программы окружение отлаживаемого модуля будет целиком состоять из всех остальных (уже отлаженных) модулей отлаживаемой программы (без каких-либо) отладочных модулей, т.е. в этом случае тестироваться будет сама отлаживаемая программа. Такой процесс наращивания отлаживаемой программы отлаженными и отлаживаемыми модулями называется интеграцией программы [10.1].
Отладочные модули, входящие в окружение отлаживаемого модуля, зависят от порядка, в каком отлаживаются модули этой программы, от того, какой модуль отлаживается и, возможно, от того, какой тест будет пропускаться.
При восходящем тестировании (см. лекцию 7) это окружение всегда будет содержать только один отладочный модуль (кроме случая, когда отлаживается последний модуль отлаживаемой программы), который будет головным в тестируемой программе и который называют ведущим (или драйвером [10.1]). Ведущий отладочный модуль подготавливает информационную среду для тестирования отлаживаемого модуля (т. е. формирует ее состояние, требуемое для тестирования этого модуля, в частности, может осуществлять ввод некоторых тестовых данных), осуществляет обращение к отлаживаемому модулю и после окончания его работы выдает необходимые сообщения. При отладке одного модуля для разных тестов могут составляться разные ведущие отладочные модули.
При нисходящем тестировании (см. лекцию 7) окружение отлаживаемого модуля в качестве отладочных модулей содержит имитаторы всех модулей, к которым может обращаться отлаживаемый модуль, а также имитаторы тех модулей, к которым могут обращаться отлаженные модули отлаживаемой программы (включенные в это окружение), но которые еще не отлажены. Некоторые из этих имитаторов при отладке одного модуля могут изменяться для разных тестов.
На самом деле в окружении отлаживаемого модуля во многих случаях могут содержаться отладочные модули обоих типов по ниже следующим соображениям. Как восходящее, так и нисходящее тестирование имеет свои достоинства и свои недостатки.
К достоинствам восходящего тестирования относятся
простота подготовки тестов и
возможность полной реализации плана тестирования модуля.
Это связано с тем, что тестовое состояние информационной среды готовится непосредственно перед обращением к отлаживаемому модулю (ведущим отладочным модулем). Недостатками восходящего тестирования являются следующие его особенности:
тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программ);
большой объем отладочного программирования (при отладке одного модуля часто приходится составлять для разных тестов много ведущих отладочных модулей);
необходимость специального тестирования сопряжения модулей.
К достоинствам нисходящего тестирования относятся следующие его особенности:
большинство тестов готовится в форме, рассчитанной на пользователя;
во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко - для всех, тестов);
отпадает необходимость тестирования сопряжения модулей.
Недостатком нисходящего тестирования является то, что тестовое состояние информационной среды перед обращением к отлаживаемому модулю готовится косвенно - оно является результатом применения уже отлаженных модулей к тестовым данным или данным, выдаваемым имитаторами. Это, во-первых, затрудняет подготовку тестов, требует высокой квалификации исполнителя-тестовика, а во-вторых, делает затруднительным или даже невозможным реализацию полного плана тестирования отлаживаемого модуля. Указанный недостаток иногда вынуждает разработчиков применять восходящее тестирование даже в случае нисходящей разработки. Однако чаще применяют некоторые модификации нисходящего тестирования, либо некоторую комбинацию нисходящего и восходящего тестирования.
Исходя из того, что нисходящее тестирование, в принципе, является предпочтительным, остановимся на приемах, позволяющих в какой-то мере преодолеть указанные трудности. Прежде всего необходимо организовать отладку программы таким образом, чтобы как можно раньше были отлажены модули, осуществляющие ввод данных, - тогда тестовые данные можно готовить в форме, рассчитанной на пользователя, что существенно упростит подготовку последующих тестов. Далеко не всегда этот ввод осуществляется в головном модуле, поэтому приходится в первую очередь отлаживать цепочки модулей, ведущие к модулям, осуществляющим указанный ввод (ср. с методом целенаправленной конструктивной реализации в лекции 7). Пока модули, осуществляющие ввод данных, не отлажены, тестовые данные поставляются некоторыми имитаторами: они либо включаются в имитатор как его часть, либо вводятся этим имитатором.
При нисходящем тестировании некоторые состояния информационной среды, при которых требуется тестировать отлаживаемый модуль, могут не возникать при выполнении отлаживаемой программы ни при каких входных данных. В этих случаях можно было бы вообще не тестировать отлаживаемый модуль, так как обнаруживаемые при этом ошибки не будут проявляться при выполнении отлаживаемой программы ни при каких входных данных. Однако так поступать не рекомендуется, так как при изменениях отлаживаемой программы (например, при сопровождении ПС) не использованные для тестирования отлаживаемого модуля состояния информационной среды могут уже возникать, что требует дополнительного тестирования этого модуля (а этого при рациональной организации отладки можно было бы не делать, если сам данный модуль не изменялся). Для осуществления тестирования отлаживаемого модуля в указанных ситуациях иногда используют подходящие имитаторы, чтобы создать требуемое состояние информационной среды. Чаще же пользуются модифицированным вариантом нисходящего тестирования, при котором отлаживаемые модули перед их интеграцией предварительно тестируются отдельно (в этом случае в окружении отлаживаемого модуля появляется ведущий отладочный модуль, наряду с имитаторами модулей, к которым может обращаться отлаживаемый модуль). Однако, представляется более целесообразной другая модификация нисходящего тестирования: после завершения нисходящего тестирования отлаживаемого модуля для достижимых тестовых состояний информационной среды следует его отдельно протестировать для остальных требуемых состояний информационной среды.
Часто применяют также комбинацию восходящего и нисходящего тестирования, которую называют методом сандвича [10.1]. Сущность этого метода заключается в одновременном осуществлении как восходящего, так и нисходящего тестирования, пока эти два процесса тестирования не встретятся на каком-либо модуле где-то в середине структуры отлаживаемой программы. Этот метод позволяет при разумном подходе воспользоваться достоинствами как восходящего, так и нисходящего тестирования и в значительной степени нейтрализовать их недостатки. Этот эффект является проявлением более общего принципа: наибольшего технологического эффекта можно добиться, сочетая нисходящие и восходящие методы разработки программ ПС. Именно для поддержки этого метода и предназначен архитектурный подход к разработке программ (см. лекцию 7): слой квалифицированно разработанных и тщательно оттестированных модулей существенно облегчает реализацию семейства программ в соответствующей предметной области и их последующую модернизацию.
Весьма важным при автономной отладке является тестирование
сопряжения модулей. Дело в том, что спецификация каждого модуля программы, кроме головного, используется в этой программы в двух ситуациях: во-первых, при разработке текста (иногда говорят: тела) этого модуля и, во-вторых, при написании обращения к этому модулю в других модулях программы. И в том, и в другом случае в результате ошибки может быть нарушено требуемое соответствие заданной спецификации модуля. Такие ошибки требуется обнаруживать и устранять. Для этого и предназначено тестирование сопряжения модулей. При нисходящем тестировании тестирование сопряжения осуществляется попутно каждым пропускаемым тестом, что считают самым сильным достоинством нисходящего тестирования. При восходящем тестировании обращение к отлаживаемому модулю производится не из модулей отлаживаемой программы, а из ведущего отладочного модуля. В связи с этим существует опасность, что последний модуль может приспособиться к некоторым "заблуждениям" отлаживаемого модуля. Поэтому приступая (в процессе интеграции программы) к отладке нового модуля приходится тестировать каждое обращение к ранее отлаженному модулю с целью обнаружения несогласованности этого обращения с телом соответствующего модуля (и не исключено, что виноват в этом ранее отлаженный модуль). Таким образом, приходится частично повторять в новых условиях тестирование ранее отлаженного модуля, при этом возникают те же трудности, что и при нисходящем тестировании.
Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага [10.1].
Шаг 1. На основании спецификации отлаживаемого модуля подготовьте тест для каждой возможности и каждой ситуации, для каждой границы областей допустимых значений всех входных данных, для каждой области изменения данных, для каждой области недопустимых значений всех входных данных и каждого недопустимого условия.
Шаг 2. Проверьте текст модуля, чтобы убедиться, что каждое направление любого разветвления будет пройдено хотя бы на одном тесте. Добавьте недостающие тесты.
Шаг 3. Убедитесь по тексту модуля, что для каждого цикла существует тест, для которого тело цикла не выполняется, тест, для которого тело цикла выполняется один раз, и тест, для которого тело цикла выполняется максимальное число раз. Добавьте недостающие тесты.
Шаг 4. Проверьте по тексту модуля его чувствительность к отдельным особым значениям входных данных - все такие значения должны входить в тесты. Добавьте недостающие тесты.
Как уже было сказано выше, при комплексной отладке тестируется ПС в целом, причем тесты готовятся по каждому из документов ПС [10.8]. Тестирование этих документов производится, как правило, в порядке, обратном их разработке (исключение составляет лишь тестирование документации по применению, которая разрабатывается по внешнему описанию параллельно с разработкой текстов программ; это тестирование лучше производить после завершения тестирования внешнего описания). Тестирование при комплексной отладке представляет собой применение ПС к конкретным данным, которые в принципе могут возникнуть у пользователя (в частности, все тесты готовятся в форме, рассчитанной на пользователя), но, возможно, в моделируемой (а не в реальной) среде. Например, некоторые недоступные при комплексной отладке устройства ввода и вывода могут быть заменены их программными имитаторами.
Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная отладка каждой подсистемы. Ошибки реализации архитектуры могут быть связаны прежде всего с взаимодействием этих подсистем, в частности, с реализацией архитектурных функций (если они есть). Поэтому хотелось бы проверить все пути взаимодействия между подсистемами ПС. Но так как их может быть слишком много, то желательно бы протестировать хотя бы все цепочки выполнения подсистем без повторного вхождения последних. Если заданная архитектура представляет ПС в качестве малой системы из выделенных подсистем, то число таких цепочек будет вполне обозримо.
Тестирование внешних функций. Целью тестирования является поиск расхождений между функциональной спецификацией и совокупностью программ ПС. Несмотря на то, что все эти программы автономно уже отлажены, указанные расхождения могут быть, например, из-за несоответствия внутренних спецификаций программ и их модулей (на основании которых производилось автономное тестирование) внешней функциональной спецификации ПС. Как правило, тестирование внешних функций производится так же, как и тестирование модулей на первом шаге, т.е. как черного ящика.
Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Ясно лишь, что далеко не каждый примитив качества ПС может быть испытан тестированием (об оценке качества ПС см. следующую лекцию). Завершенность ПС проверяется уже при тестировании внешних функций. На данном этапе тестирование этого примитива качества может быть продолжено если требуется получить какую-либо вероятностную оценку степени надежности ПС. Однако, методика такого тестирования еще требует своей разработки. Точность, устойчивость, защищенность, временная эффективность, в какой-то мере - эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств могут тестироваться. Каждый из этих видов тестирования имеет свою специфику и заслуживает отдельного рассмотрения. Мы здесь ограничимся лишь их перечислением. Легкость применения ПС (критерий качества, включающий несколько примитивов качества, см. лекцию 4) оценивается при тестировании документации по применению ПС.
Тестирование документации по применению ПС. Целью тестирования является поиск несогласованности документации по применению и совокупностью программ ПС, а также неудобств применения ПС. Этот этап непосредственно предшествует подключению пользователя к завершению разработки ПС (тестированию требований к ПС и аттестации ПС), поэтому весьма важно разработчикам сначала самим воспользоваться ПС так, как это будет делать пользователь [10.1]. Все тесты на этом этапе готовятся исключительно на основании только документации по применению ПС. Прежде всего, должны тестироваться возможности ПС как это делалось при тестировании внешних функций, но только на основании документации по применению. Должны быть протестированы все неясные места в документации, а также все примеры, использованные в документации. Далее тестируются наиболее трудные случаи применения ПС с целью обнаружить нарушение требований относительности легкости применения ПС.
Тестирование определения требований к ПС. Целью тестирования является выяснение, в какой мере ПС не соответствует предъявленному определению требований к нему. Особенность этого вида тестирования заключается в том, что его осуществляет организация-покупатель или организация-пользователь ПС [10.1] как один из путей преодоления барьера между разработчиком и пользователем (см. лекцию 3). Обычно это тестирование производится с помощью контрольных задач - типовых задах, для которых известен результат решения. В тех случаях, когда разрабатываемое ПС должно придти на смену другому варианту ПС, который решает хотя бы часть задач разрабатываемого ПС, тестирование производится путем решения общих задач с помощью как старого, так и нового ПС с последующим сопоставлением полученных результатов. Иногда в качестве формы такого тестирования используют опытную эксплуатацию ПС - ограниченное применение нового ПС с анализом использования результатов в практической деятельности. По-существу, этот вид тестирования во многом перекликается с испытанием ПС при его аттестации (см. лекцию 14), но выполняется до аттестации, а иногда и вместо аттестации.
Дисциплина: «Разработка и стандартизация программных средств и информационных технологий»
Нормативные документы по стандартизации, виды стандартов и организации, разрабатывающие стандарты.
Основные задачи проектирования программных средств. Программные средства для разработки программ.
Группа проекта. Состав и функциональные обязанности.
Жизненный цикл программного средства.
Основные процессы жизненного цикла программных средств.
Вспомогательные процессы жизненного цикла программных средств.
Организационные процессы жизненного цикла программных средств.
Модели жизненных циклов программных средств. Стратегии конструирования ПС.
Основные понятия инженерии программного обеспечения.
Процесс создания систем. Основные требования и этапы.
Современные тенденции в программной инженерии. CALS-технология.
Тяжеловесные и облегченные процессы создания систем. Экстремальное программирование.
Архитектура программных систем. Классы архитектур программных средств, примеры.
Концепции и этапы архитектурного проектирования. Архитектурные модели.
Процессы управления программным проектом. Планирование проекта.
Управление рисками в процессе управления программным проектом.
Оценка проекта на основе метрик. LOC-метрики и FP-метрики.
Классификация требований к программному обеспечению. Разработка требований.
Проектирование пользовательских интерфейсов. Стили взаимодействия пользователя с системой.
Основные принципы и методы объектно-ориентированного анализа и проектирования.
Основные понятия абстрагирования, типизации, наследования и иерархии объектов.
Унифицированный язык моделирования UML как язык спецификации, проектирования и документирования. Основные характеристики и назначение языка.
Стандарты документирования программных средств. ЕСПД.
Международные стандарты ISO серии 9000 и стандарты в системе сертификации ГОСТ Р.
Характеристики качества программных средств. Основные мероприятия по обеспечению качества программного средства.
Основные понятия и показатели надежности программных средств.
Динамические модели надежности программного обеспечения.
Статические модели надежности программного обеспечения.
Эмпирические модели надежности программного обеспечения.
Основные принципы и формы тестирования программных средств.
Тестирование модулей. Комплексное тестирование программных средств.
Основные этапы тестирования программных средств.
страница 1страница 2страница 3
скачать
Другие похожие работы: