Вы находитесь на странице: 1из 18

Инструментальные средства ИС

ИС- это комплекс средств, обеспечивающих получение, накопление,


обработку и представление информации.
Информационные системы
Инструментальные средства делятся на:
-инструменты разработки;
-инструменты пользователя.
Инструментарий разработки включает в себя аппаратные средства,
программные средства, методические средства, технологические средства и
математические средства.
Аппаратным средством, обеспечивающим информационные процессы,
относится - устройство ввода, вывода, аналитической обработке, хранения,
передачи по линиям связи, аппаратное устройство защиты.
Программное средство условно делится на три класса:
-системы программ;
-прикладные программы;
-инструментальные программы.
1уровень: Оператор
2уровень: Технический секретарь
3уровень: Программисты, системные администраторы и т.д.
ИС включает в себя следующие категории обеспечения
1. Информационное обеспечение- совокупность проектных решений по
объектам, размещению, форме организации информации,
циркулирующей из информационной системы.
2. Лингвистическое обеспечение- совокупность языковых средств для
формализации естественного языка, построение и сочетание
информационной единице в ходе общения пользователей со средствами
вычислительной техники.
3. Техническое обеспечение- совокупность аппаратного обеспечения
реализующая информационные процессы.
4. Программное обеспечение- совокупность программ, реализующих
функции и задачи ИС, а также обеспечив работу комплексов
технических средств.
5. Математическое обеспечение- совокупность математических методов
людей и алгоритмов обработки информации.
6. Организационное обеспечение- комплекс документов, состоит в
процентном проектировании ИС утверж. и положенных в основу
эксплуатации.
7. Правовое обеспечение- совокупность правовых норм,
регламентирующих правоотношение при создании и внедрении в ИС.
8. Эргономическое обеспечение- совокупность методов и средств,
используемых на разных этапах разработки ИС для создания
оптимальных условий высококачественной, высокоэффективной и
безошибочной деятельности человека, а также быстрейшего
восстановления ИС.
Инструментальные средства ИС- решают целый спектр задач, охватывающих
все этапы жизненного цикла ПО в среде данных задач выделяют задачу,
связанную с обеспечением возможной работы с неоднородными в единой
концептуальной модели данных на всем протяжении жизненного цикла.
Проблема интеграции неоднородных информационно-вычислительных
ресурсов может быть рассмотрена в трех контекстах:
1. Повторное использование (Reusability), существующих и доступных
ресурсов.
2. Облегчение разработки корпоративных ИС – определенные компоненты
которые создаются разными территориально-распределенными
группами, каждая их которых в силу исторических причин использует
наиболее эпичную для него технологию.
3. Связан с унаследованием системы (Legacy system).
Инструментальные разработки требований
Основные виды работ при анализе требований:
-исходная постановка задач;
-сбор и исследование информации.
Виды информации для выполнения анализов:
1. Данные о предметной области в целом;
2. Данные о существующих аналогов;
3. Данные о специфике предприятия заказчика (специфика бизнес-
процесса, данные об унаследовательности ПО используемое
аппаратным ПО, политика безопасности организации, уровень
квалификации персонала).
Виды работы:
1. Выбор приоритетных критерий качества;
2. Определение входных хранимых и выходных данных;
3. Формулизации требований.
Основной формой представления требований является техническое задание и
варианты использования. Техническое задание является частью соглашения
между заказчиком и его разработчиком продукта.
Существует два разных стандарта ТЗ. Любой гост нужно методическое
пособие.
1. ГОСТ 19.201-78 ЕСПД.ТЗ. Требование к содержанию и оформлению.
2. ГОСТ 34.602-89. Информационная технология. ТЗ на создание
автоматизированной системы.
Согласно первому госту ТЗ содержит следующие разделы:
1. Введение (указывается наименование, краткая характеристика области
применения программного продукта и объекта в котором используют
программный продукт).
2. Основание для разработки (указываются документы на основании
которых ведется разработка, организация, утвердившая документы,
дата утверждения, наименование или условная тема разработки).
3. Назначение разработки (функциональное и эксплуатационное
назначение).
4. Требование к программному продукту (требование к функциональным
характеристикам, требование к надежности, к состоянию и параметрам
технических средств, к информационной и программной
совместимости).
5. Требование к программной документации (указывается
предварительный состав программной документации).
6. Технико-экономические документации (указывается ориентировочно-
экономическая предполагаемая годовая
потребность, преимущество разработки по сравнению аналогами
7. Стадии и этапы разработки (включают в себя необходимые этапы
разработки, перечень программных документаций, которые должны
быть разработаны, а также сроки разработки и исполнения).
8. Порядок контроля и приемки (указываются виды испытаний и
требование к приемке работы).
9. Приложения (они содержат перечень научно-исследовательских и
других работ, обосновывающих разработку, схемы алгоритмов,
таблицы, описание, расчеты, и др. документы, которые могут быть
использованы при разработке).
Варианты использования — USE Cases- это формальное описание
взаимодействия системы и пользователей при решении конкретной задачи.
Виды применения вариантов использования:
1. Как инструмент фиксации функциональных требований на этапе
анализа;
2. Как источник информации о постановке задачи для выполнения
проектирования и программной реализации системы;
3. Как инструмент создания сценариев тестирования;
4. Как источник информации для написания пользовательской
документации.
Инструментальные средства
Инструментальные средства, применяемые при разработке требований
решения следующих задач:
-обновление и синхронизация документов;
-доведение изменений до всех членов команды;
-хранение дополнительной информации для каждого требования;
-определить взаимосвязи между требованиями и другими элементами
системы;
-отслеживание состояния отдельных требований;
-управление наборами требований, запланированных для различных выпусков
и связанных продуктов;
-автоматизация многократного копирования текста исходной спецификации
требований для каждого элемента программного продукта;
-модификация требований несколькими участниками проекта;
-обеспечение удобного места хранения требований, которые были
предложены, но отклонены или удаленных требований;
-создание и отслеживание моделей анализа;
-обнаружение пропущенных, дублирующихся или не нужных требований.
Инструменты анализа бизнес-процессов
Методология IDEF0 – понимается описание системы в виде графических
нотаций предназначенных для решения задач бизнеса и разработку
информационных систем для организации.
Процесс моделирования какой-либо системы в IDEF0 начинается с
определения контекста т.е наиболее абстрактного уровня описания системы в
целом. В контекст входит определение субъекта моделирования т.е самой
системы, цели и точки зрения на модель.
Основу методологии IDEF0 составляет графический язык, описание бизнес-
процессов. Модель представляет собой совокупность и иерархически
упорядочную и взаимно-связанную диаграмму.
Вершина этой структуры представляет собой самое общее описание системы
и ее взаимодействия с внешней средой, называется эта вершина контекстной
диаграммой. После описания в целом идет декомпозиция. В соот. такие
диаграммы называются диаграммами декомпозиции. После каждого сеанса
декомпозиции проводится экспертиза на соответствие реальных бизнес-
процессов, построенных реально. Основное сущ. в синтаксисе графической
нотации IDEF0 является работа Activity.
При работе IDEF0 диаграммами должно выполняться условие их
разборчивости и удобочитаемости. Суть ограничения заключается в том, что
на любой диаграмме декомпозиции не должно быть блоков меньше 2 и больше
6.
Требование стандартов IDEF0
1. В левом верхнем углу всегда главный элемент т.е главная работа
(контекстная диаграмма всегда состоит из одного блока).
2. Все работы должны иметь входящие и исходящие стрелки. При этом
элементы и механизмы могут отсутствовать.
3. Каждый последовательный блок диаграммы располагается правее и
ниже предыдущего.
4. Пересечение стрелок или дуг должно быть минимальное количество.
Каждая дуга обозначается существительным.
Программное обеспечение для составления диаграмм IDEF0:
1. BPWin
2. Allfusion Basiness Modeler
3. Visio
4. Ramus
Типы связей между блоками
Дуналированные стрелки означают что данные передаваемые с помощью этих
стрелок не рассматриваются на родительской диаграмме или на дочерней
диаграмме.
Метод IDEF3 предназначен для моделирования последовательности
выполнения действий и взаимозависимости между ними. IDEF3 может быть
использована для детализации IDEF0. Результатом моделирования является
документирование технологических или информационных процессов где
важна последовательность выполнения процесса. Диаграмма IDEF3
отображает действие в виде прямоугольника, а связи являются
однонаправленными и организуются слева на право.
Типы связей IDEF3:
1. Временной предшествование обозначаются простой стрелкой
применятся, когда исходное действие должно завершаться прежде чем
конечное действие сможет начаться.
2. Объектный поток обозначается стрелкой с двойным наконечником.
3. Нечетное отношение обозначаются пунктирной стрелкой.
Завершение одного действия может инициировать начало выполнения сразу
нескольких других действий и наоборот, определяет действие может
требовать завершение нескольких других действий до начала выполнения.
Типы перекрестков
Асинхронное И (Asynchronous AND)
Асинхронное И- выходной процесс запустится если завершились все входные
процессы.
Синхронное И- выходной процесс запустится если завершились одновременно
все входные процессы. А после завершения входного запустятся все выходные
процессы одновременно.
Асинхронное ИЛИ (Asynchoronous OR)
Асинхронное ИЛИ. Выходной процесс запустится если завершится один или
несколько входных процессов. После завершения входного процесса
запустится один или несколько выходных процессов.
Синхронное ИЛИ (Synchronous OR)
Синхронное ИЛИ. Выходной процесс запустится если завершились один или
несколько входных процессов одновременно. После завершения входного
процесса запустится один или несколько выходных процессов одновременно.
Исключающее ИЛИ (XOR Exclusive OR)
Исключающее ИЛИ. Выходной процесс запустится если завершился только
входной процесс. После завершения входного процесса запустится только
один выходной процесс.
Правила создания перекрестков
1. Каждому перекрестку слияния должен предшествовать перекресток
крепления.
2. Перекресток слияния И не может следовать за перекрестком ветвления
синхронного, асинхронного или искл. ИЛИ.
3. Перекресток слияния искл. ИЛИ не может следовать за перекрестком
ветвления И.
4. Перекресток имеющий одну стрелку на входе должен иметь две или
более стрелок на выходе.
5. Перекресток не может быть одновременно перекрестком ветвления и
перекрестком слияния.
Правила использования единиц работы
1. В блок может входить и из блока может выходить только одна связь, для
отображения множества входов и выходов используются перекрестки.
2. Разрешается множественная декомпозиция работ для одной и той же
работы может быть создано несколько диаграмм декомпозиции.
3. Номер работы выглядит так: А10.1.2 где А10 – это номер родительской
работы; 1 – это номер декомпозиции; 2 – это номер на текущей
диаграмме.
Методология DFD (Delta Form Diagram)
Цель методологии продемонстрировать как каждый процесс преобразует свои
входные данные в выходные. DFD может отображать не только
информационные потоки но и материальные. Также, как и в других моделях
эта модель может поддерживать декомпозицию.
Типы структурных элементов:
1. Процессы (функции, операция, действие) – которые обрабатывают и
изменяют информацию.
2. Потоки данных – обозначаю взаимодействие процессов с внешним
миром и между собой.
3. Хранилище данных – представляет собой собственно данные, к которым
осуществляется доступ.
4. Внешние сущности, которые определяют внешние элементы
участвующие в процессе обмена информации с системой (например,
заказчик, персонал, клиент, банк и т.д.).
Первым шагом при построении иерархии DFD является построение
контекстной диаграммы. На каждой диаграмме изображают от 3 до 7
процессов.
Методология BPMN
Язык описание бизнес – процессов BPMN использует следующие базовые
объекты:
1. Event – это событие которое произошло в описании процесса, оно может
быть начальным, конечным или промежуточным. Например, вход.
Зновок. Клиента, отправка документа на печать.
2. Activity – это действия которые должны быть выполнены на
определенном этапе бизнес – процесса. Действия могут быть
представлены в виде процесса т.е. крупного действия требования
декомпозиции и задачи элементарного действия которая не может быть
детализирована.
3. Gateway – это контрольный узел который используется в случае
условного ветвления бизнес – процесса.
4. Flow – это поток сообщений показывает порядок выполнения действий.
Называется Message Flow и обозначает сообщение которыми
обмениваются участники бизнес – процесса.
5. Pool – это объект описывающий какой-то один процесс на диаграмме.
Pool может содержать дорожки, которые указывают участников
процесса.
6. Data Object – объекты данных – это элемент который показывает какие
данные и элементы нужны для того чтобы какое-либо действие
запустилось или представляет собой результаты какого-либо действия.
7. Message - сообщения – элемент необходим чтобы показать
коммуникацию между двумя участниками процесса.
Артефакты – это объекты, не являющиеся действиями и не связанные с
действиями на прямую. Например, документы, данные которые не влияют на
выполнение процессов непосредственно.
Управление IT – проектами
Проектное управление – это комплекс организационных, технологических и
методических мероприятий для управления проектной деятельности, а также
мониторинга и контроля ее исполнения.
Инструменты проектного управления:
-методологические инструменты (PMI, Microsoft Solution Frame work,
PRINCE2, ГОСТ ISO-10006-2003, Quality Management Systems-GUIDelines For
quality management in projects.
ГОСТ – R54.869 – 2011 – Проектный менеджмент. Требование к управлению
проекта.
ГОСТ – R54.870 – 2011 – Проектный менеджмент. Требование к управлению
портфеля проекта.
ГОСТ – R54.871 – 2011 – Проектный менеджмент. Требование к управлению
программой.
Проект – это комплекс работ, направленный на достижение уникального
результата в рамках временных и стоимостных ограничений.
Программа проектов – это ряд связанных друг с другом проектов, управление
которыми координируется для достижения лучшей степени управляемости.
Портфель проекта – это набор проектов программ проектов и других работ
которые находятся в компетенции одного центра ответственности и
выполняются на общем пуле ресурсов для обеспечения выполнения
стратегических целей компании.
Задача – это выделенный этап работ по проекту с определенными значениями
атрибута.
Риск – это атрибут задачи, который показывает неблагоприятного развития
событий в том числе невыполнение задач.
Риски делятся на:
1. Стратегические;
2. Маркетинговые;
3. Финансовые;
4. Управленческие;
5. Организационные;
6. Временные;
7. Технологические.
Для каждого риска приводят следующую информацию:
1. Описание;
2. Причины;
3. Эффект влияния на результаты проекта;
4. Степень серьезности;
5. Вероятность возникновения (%);
6. Вероятность предварительного обнаружения;
7. Способы смягчения;
8. Предлагаемые решения.
Веха – контрольная точка значений, ключевой момент выполнения проекта.
Обозначающий переход на новый этап.
Базовый план – это план проекта на конкретную дату с заданными
плановыми показателями.
Критический путь проекта – это временная последовательность выполнения
его важнейших критических задач, которые должны быть завершены строго
в соответствии с календарным планом.
Сетевой график – это модель выполнения проекта, отражающая
технологическую зависимость и последовательность выполнения его задач.
Диаграмма Ганта – это календарный план проекта, в виде ленточной
диаграммы показывающая распределенную во времени последовательность
действий.
Суп – это информационная система управления проектами, представляющая
собой программное средство для планирования работ по проектам и
мониторинга их использования с целью прогнозирования варианта развития
событий и принятие управленческих решений.
Основные предназначения СУП
1. Структуризация текущей деятельности по взаимосвязанным проектам;
2. Визуализация порядка выполнения работ;
3. Распределение ответственности между участками проекта;
4. Оперативный мониторинг состояния проекта;
5. Анализ проектных риск;
6. Сквозной контроль затрат и инвестиций между проектами и внутри них.
7. Автоматизация процесса;
8. Единое информационное пространство управления, обеспечивающее
планирование и мониторинг хранения файлов, учет рабочего времени, а
также хранение материалов по дискуссии и совещанием.
Критерии выбора СУП:
1. Наличие средств функциональных возможностей стратегическое и
оперативное планирование, управление задачами, проектами,
портфелем проектов, учет затрат и поступлений, а также планфактный
анализ выполнения работ.
2. Возможность взаимодействия участников проекта и поддержка
проектного документооборота.
3. Обеспечение веб – доступа
4. Совместная работа нескольких участников проекта в режиме реально
времени.
5. Удобство и быстрота развертывания.
6. Надежность.
7. Наличие методической базы.
8. Наличие поддержки и сопровождение от компании разработчика.
9. Цена.
Примеры СУП:
-Microsoft Pro
-Адванта
-Мега план
СУП Адванта обеспечивает:
1. Простоту развертывания.
2. Сама серверная часть этой системы может быть расположена на облаке,
и на локальном сервере предприятия.
3. Отсутствие высоких требований программно-аппаратного окружения.
4. Все основные функциональные возможности.
5. Наличие инструментов гибкой настройки под специфику конкретных
проектов.
6. Использование СУБД Postgre SQL.
7. Большое количество методических материалов от компании
разработчиков.
8. Круглосуточная линия поддержки от компании разработчиков.
Виды IT – проектов
В зависимости от поставленной цели IT – проекта его можно отнести к
следующим категориям:
1. Проекты разработки и развитие ПО.
2. Проекты внедрения ПО.
3. Инфраструктурные и организационные проекты, направленные на
изменение существующих решений.
Методология разработке ПО – это единая система принципов, понятий,
методов и средств, определяющих стиль организации процессов создания
эффективного программного продукта.
Все методологии разработки делятся на две категории:
1. Формальные (прогнозируемые) – основаны на детальном жестком
планировании.
2. Адаптивные (гибкие) – предполагают не полноту требований и их
постоянное изменение. Примеры: экстремальное программирование
(XP), SCRUM KANBAN, DSDAM (Dynamic system development metod),
RUP (Rational Unified Process) и т.д.
Проекты внедрения особенно многомодульных корпоративных ИИС являются
наиболее затратными и сложными в организационном плане. На практике
различают следующие стратегии внедрения крупных ИС:
1. Большой взрыв – полномасштабный единовременный ввод в
эксплуатацию.
2. Поэтапный ввод в эксплуатацию (отдельными модулями либо по
подразделению).
3. Пилотное внедрение – ввод новой ИС в эксплуатацию в отдельном
структурном подразделении.
4. Программно-зависимые поэтапные модели внедрения от вендеров
(предприятий производителей и поставщиков IT-продуктов и услуг.
Проблемы, возникающие при внедрении корпоративных ИС:
1. Технологические проблемы;
2. Организационные проблемы;
3. Личные проблемы.
Управление изменениями IT – это структурный подход к переводу объектов
(программного, аппаратного, и информационного обеспечения из текущего
состояния в желаемое будущее состояние. Управление изменениями включает
следующие процедуры:
1. Обоснование изменений
2. Возникновение и регистрация изменений в IT-структуре.
3. Оценка воздействия от предполагаемых изменений и поиск вариантов
соблюдения, вариантов баланса между необходимостью изменений и
потенциально вредным воздействием.
4. Разработка бизнес – обоснований.
Тестирование
Тестирование – это процесс выявления ошибок в программе приводящий к
несоответствиям результатов вычисления и ожидаемых реакций системы
на воздействие пользователя или других систем.
Согласно стандарту IEEE – 829 – 1983г. (Standart For Software Test
Documentation) тестирование представляет собой процесс анализа ПО
направленный на выявление отличий между его реально существующими
и требуемыми свойствами, а также на оценку свойств ПО.
Объектами тестирования является:
-исходные тексты программ;
-исполняемые модули;
-документация.
Тест – это эксперимент, выполняемый над программой для которого
определены критерии успешности.
Тестовые данные подготавливаются в результате внешней и внутренней
спецификации ПО и направлены на обеспечение проведения
экспериментов.
Тестовая процедура (сценарий) – это спецификация проведения
эксперимента которая описывает порядок ввода тестовых данных и
критерии успешности.
Три принципа тестирования:
1. Необходимо создавать тесты, которые с высокой вероятностью находят
ошибки;
2. Необходимо привлекать для тестирования сторонних специалистов;
3. Тесты должны приводится регулярно на основании регламента
тестирования.
Основные проблемы организации тестирования:
1. Невозможно создать набор тестов для исчерпывающей проверки
сложной системы.
2. Не редко отсутствует эталон, которому должны соответствовать
результаты системы.
3. Отсутствует практически пригодные формальные критерии качества
тестирования.
Критерии качества тестирования:
Критерии качества называют критериями покрытия, поскольку они
показывают степень охвата тех или иных аспектов программного продукта
при тестировании. Критерии покрытия делятся на две группы:
-критерии покрытия структуры;
-критерии покрытия поведения.
Критерии покрытия поведения – указывают на полноту функционального
тестирования. Покрытие поведения считается полным если при тестировании
каждая функциональная возможность задействована хотя бы один раз.
Критерии покрытия структуры – включают оценку полноты покрытия
подпрограмм, операторов, маршрутов и данных.
Полнота покрытия операторов:
1. Критерии достигают 100% если при тестировании были выполнены все
операторы программы хотя бы один раз. Инструментальным средством
оценки полноты покрытия оператора является Rational Pure Coverage.
2. Полнота покрытия маршрутов – можно достигнуть 100% полноты
покрытия маршрутов если отработали все возможные маршруты
программ, определенные оператором ветвления и циклов. Но
достигнуть 100% маршрута не реально, обычно достигается 60%, и 90%
при использовании инструментов автоматизации.
3. Полнота покрытия данных – критерии достигают 100% если при
тестировании были проверены все возможные входные данные, во всех
возможных сочетаниях.
Основные виды тестирования:
1. Дымовое тестирование – это быстрое тестирование системы при
котором проверяются несколько ключевых возможностей;
2. Автономное тестирование – заключается в изолированной проверки
каждого отдельного компонента программы, модуля или
подпрограммы. Этот вид тестирования является самым крайним и
выполняется самим программистом;
Комплексное тестирование – это исследование программы целиком,
проверяется взаимодействие частей программы и их взаимное влияние;
3. Тестирование белого и черного ящика;
4. Альфа и Бетта тестирование.
α – тестирование – это деятельность организации разработчика по
тестированию ПО своими силами;
β – тестирование – выполняется силами большого количества
пользователей, которые не являются сотрудниками организации.
5. Регрессионное тестирование – это повторное тестирование всей
программы после внесения изменений в ее часть. При тестировании
недостаточно проверить только добавленные или измененные части
системы, необходимо определить их влияние на работу, надежность,
производительность ранее написанного кода.
Регрессионное тестирование требует много ресурсов в связи с этим его
стараются проводить автоматизировано с использованием программных
систем автоматизирование автономного тестирования.
6. Функциональное тестирование – это такой вид тестирования, при
котором проверяются только функциональные возможности системы.
Не функциональные характеристики проверке не подвергаются
поскольку они считаются не системно-образующие.
7. Нагрузочное тестирование (стрессовое) – применяется для тестирования
производительности системы.
8. Тестирование уязвимости – такой вид тестирования используется не
очень часто, направлен на проверку эффективности используемых
программ механизмов, защиты информации, и к ошибкам персонала.
Методы, используемые для тестирования
1. Инспекция кода – это статический метод тестирования, выполняемый
вручную. Выполняется сквозной просмотр текста непосредственно
разработчиком или группой специалистов с целью поиска нарушений
логике и типовых ошибок. Эффективность данного тестирования от 60%
до 90%. Успех метода основан на том, что большинство ошибок
является шаблонами, а также некоторые ошибки при проведении
экспериментов могут быть выявлены только при особом сочетании
условий, а при инспектировании кода их выявить гораздо легче.
Недостатком метода является трудоемкость и невозможность
формализации.
2. Многократная разработка – идея такой разработки состоит в том, что
можно сравнивать работу нескольких вариантов программы при одних
и тех же условиях.
От такого метода отказались из-за его чрезвычайной затратности.
3. Классы эквивалентности и граничные условия – в тестировании
программного обеспечения приходится принимать решение о том
следует ли использовать тот или иной тестовый набор или в этом нет
необходимости поскольку требуется с одной стороны минимизировать
набор тестов с целью сокращения времени и с другой стороны
обеспечить достаточную полноту тестирования. При формировании
набора тестов обязательно следует включать у него тесты двух типов:
-тесты которые, не обладая самостоятельной ценностью дают
представление о целом классе программы;
-тесты пограничные (для формирования образцовых тестов) –
применяется метод эквивалентных разбиений, он состоит в разбиении
значений входных данных на классы эквивалентности, затем из этого
класса выбирается значение представителей.

Для проверки граничных значений используется метод анализа граничных


значений классов эквивалентности.

Средства автоматизации тестирования


Виды инструментальных средств тестирования:
1. Система учета и отслеживание дефектов – все дефекты и отчеты о
проблемах, выявленных в течении жизненных циклов, должны
соблюдаться до своего закрытия.
2. Генераторы тестовых данных – генерируют большие объемы тестовых
данных для заданных свойств.
3. Система выявления ошибок времени выполнения – данные инструменты
способны выявлять такие прогоны как перевыполнение стека, утечки
памяти, решение по недопустимому адресу.
4. Система анализа покрытия – регистрирует покрытие операторов или
маршрутов позволяет визуально оценить полноту покрытия.
5. Система тестирований пользовательского интерфейса – данные
инструменты могут записывать и воспроизводить скрипты,
имитирующие действие пользователя.

Организация тестирования
Согласно регламенту, в команде тестирования специалистов делят на тест –
инженеров и тестеров.
Тест-инженер – это наиболее квалифицированный специалист, который
понимает предметную область, владеет навыками планирования
тестирования, а также навыками разработки тестов.
Тестер – выполняет все пункты плана по тестированию. Для систематического
тестирования тестовый инженер подготавливает тестовые сценарии и
соответствующие тестовые данные. Тестовые сценарии создаются на основе
вариантов использования. Обычно сценарий тестирования подготавливают
виды таблицы со столбиками:
-исходные данные;
-действия;
-ожидаемый результат;
-фактический результат.
Для того чтобы максимально сократить время подготовки тестовых данных
желательно принять следующие меры:
1. Воспользоваться генератором тестовых данных;
2. Подготовить тестовые данные проектных групп;
3. Привлечь пользователей к подготовке тестовых данных;
4. Выделить тестовые данные из имеющихся внешних файлов.
Классификация ошибок
1. Несерьезности - включают в себя ошибки с низкой серьезностью, с
высокой серьезностью.
2. По видам, деятельности, которые привели к возникновению ошибки.
2.1 ошибки анализа;
2.2 ошибки проектирования;
2.3 ошибки документации;
2.4 ошибки программной реализации (ошибки пользовательского
интерфейса, ошибки вычислений, ошибки использования методов,
ошибки взаимодействия с устройствами и программами, ошибки
синхронизации, ошибка неверного использования в памяти).4
Конфигурирования ИС
Конфигурирование – это процесс настройки ИС с целью ее адаптации
специфики области внедрения. В процессе конфигурации выполняются
следующие действия:
- изменение объектной модели программы;
- определение авторизации пользователей;
- настройка интерфейса;
- создание типовых объектов данных т.е. справочников, шаблонов, отчетов;
- настройка вариантов развертывания.
Этапы и объекты конфигурирования
1. изменение объектной модели (объектом является модель данных).
2. Авторизация пользователя (объектом является пользователь).
3. Настройка интерфейса (объектом является графический интерфейс,
формы ввода данных, информационные сообщения, пункты меню и др.).
4. Создание типовых объектов данных (объектом является диаграммы
процессов, шаблоны отчетов, объектные справочники).
5. Расширение функциональных возможностей (объектом является
программная реализация функциональных модулей интеграция с
другими ИС).
6. Настройка вариантов развертывания (объектом является параметр
систем служб и сервисов).
Объектная модель или модель данных
Главный объект конфигурирования, смысловое ядро системы которое
реализует ее бизнес-логику и определяет поведение остальных объектов
конфигурации.
Характеристики объектной модели
1. Она отражает существенные для разрабатываемой системы понятия и
объекты реального мира.
2. Описывает структуру объектов, составляющих систему их атрибуты,
операции и взаимовлияние.
3. Объектная модель является абстрактной понятием.
4. Объектная модель как правило реализуется OML – диаграммы.
Справочник – это хранилище сущностей в едином контексте, совокупность
объектов с однотипным набором характеристик и методов их обработки.
Основной задачей конфигурирования ИС является – адаптация ее объектной
модели, которая приводит к созданию новых и изменению существующих
справочников, а также установки связей и иерархии между справочниками.

Оценить