Разработка и стандартизация программных средств и информационных технологий Пятовский Сергей Евгеньевич Кафедра 504 «Экономическая информатика» k504@mai.ru http://www.mai.ru/colleges/fac_5/kaf/k504 Общие положения о стандартах I.1. Основные определения. Классификация стандартов. I.2. Классификация ППП. I.2. Экономические критерии разработки и применения ПП. Разработка и стандартизация программных средств и ИТ II.1. Жизненный цикл программного средства, этапы разработки, стандарты в ИТ. II.2. Проектирование и разработка ППП. II.3. Проектирование управляющих модулей, внутренних системных средств ППП. II.4. Проектирование обслуживающих модулей ППП. Особенности документирования и применения ППП III.1. ППП, реализующие типовые процедуры обработки ЭИ на ЭВМ. III.2. Тестирование программных средств III.3. ППП, реализующие ЭММ. Разработка и стандартизация программных средств и информационных технологий Литература 1. Стандартизация разработки программных средств: уч. пособие // В.А.Благодатских, В.А.Волнин, К.Ф.Поскакалов; под ред. О.С.Разумова. – М.: Финансы и статистика, 2006. – 288 с. 2. Метрология, качество и сертификация программного обеспечения // Е.В.Ковалевская. – М.: МЭСИ, 2004. – 95 с. 3. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504-CMM). – М.: Книга и бизнес, 2001. – 348 с. 4. Практикум по проектированию программного обеспечения экономических информационных систем: уч. пособие // А.М.Вендров. – М.: Финансы и статистика, 2002. – 192 с. 5. Моделирование и анализ систем. IDEF-технологии: практикум // С.В.Черемных, И.О.Семенов, В.С.Ручкин. – М.: Финансы и статистика, 2002. – 192 с. 6. ISO 15504-1-9: 1998 : Оценка и аттестация зрелости процессов создания и сопровождения программных средств // А.С.Агапова. – Книга и бизнес, 2001. 7. Стандарты ЕСПД 8. ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств. 9. ГОСТ Р ИСО/МЭК 9126-93 Информационная технология. Оценка программной продукции. Характеристики качества и руководство по их применению. 10. ГОСТ Р ИСО/МЭК 12119-2000 Информационная технология. Пакеты программ. Требования к качеству и тестирование. Разработка и стандартизация программных средств и информационных технологий Цель курса Определить основные понятия в ИТ Ознакомиться с нормативно-правовыми актами (НПА) и видами стандартов для ПО Получить представление о международных и национальных организациях по разработке стандартов Курсовые работы Цель КР – реализация процессов ЖЦ программного средства, для которого предполагается возможность тиражирования и применение как ППП для решения набора экономических задач конечного пользователя. В КР реализуются процессы разработки, документирования, обеспечения качества, приемки работ, приемки изделия, управления проектом, согласно ГОСТ Р ИСО/МЭК 12207-99. КР пишется с ориентацией на получение отчуждаемого ПП, который может эксплуатироваться пользователем без участия разработчика, и сопровождение которого возможно посредником с консультациями разработчика. Этапы разработки программного продукта Этап I. Анализ требований к ПП с формированием ТЗ на разрабатываемое ПО. В ТЗ определяются: • назначение и область применения ПП; • основание для разработки; • требования заказчика к ПП; • требования по передаче программной продукции заказчику, ее оценки и установке на месте эксплуатации; • календарный план разработки с указанием сроков завершения этапов и работы в целом. В качестве заказчика в КР выступает юридическое лицо. Результат - определяется предварительная стоимость ПП или сумма договора на разработку в зависимости от вида создаваемого ПП. Приводится ее обоснование. Этапы разработки программного продукта Этап II. Проведение технологической подготовки разработки и ее планирование, выбор с кратким обоснованием: • средств программирования; • инструментальных средств, повышающих степень автоматизации и производительности труда разработчика в процессе формирования ПО, его корректировки, отладки и документирования; • средств управления процессом разработки; • определение состава работ по реализации проекта, последовательность их выполнения, сроки, исполнители и требуемые для них ресурсы, обеспечивающие выполнение работ. Результаты технологической подготовки представляются как набор детального календарного плана работ с указанием всех упомянутых характеристик и индивидуальных планов-заданий по исполнителям. Этапы разработки программного продукта Этап III. Проектирование архитектуры ПП: • разработка форм входной информации, применяя которые пользователь формирует исходные данные для работы ПП в целях решения задач, определенных в ТЗ; • разработка форм выходной информации, печатной и экранной, по задачам, выдаваемой пользователю в результате работы ПП; • разработка пользовательского интерфейса, который позволяет пользователю осуществить управление работой ПП при его эксплуатации; • разработка проектных решений по принципам реализации других требований заказчика к ПП, оговариваемых в ТЗ. Результаты работ по проектированию архитектуры ПП согласовываются с заказчиком и документируются в соответствии с ТЗ и стандартами на разработку программных средств. Этапы разработки программного продукта Этап IV. Разработка проекта ПП. • Проектирование структуры программного комплекса в части количества модулей, исходя из количества независимых действий пользователя при обращении к ПП (количества функций): просмотр и внесение изменений в существующую БД, реализация функциональных запросов пользователя к ПП и т.п. • Вместе со структурой программного комплекса определяется состав и структура БД. • Определение порядка взаимосвязи программных компонент в комплексе. Структуру комплекса представляется в виде графа, в котором каждый элемент соответствует программному модулю, компоненту БД, входному или выходному документу, а связи между элементами означают функциональные и информационные взаимосвязи между этими объектами. Результаты выполнения работ документируются в соответствии с ТЗ и стандартами на разработку программных средств. Этапы разработки программного продукта Этап V. Программная реализация и тестирование ПП. Пользователю необходимо предоставить возможность применять только средства интерфейса разработанного ПП: • стандарты на управляющее программное средство; • стандарты на разработку модулей обращения к БД; • стандарты на разработку модулей реализации функциональных работ пользователя. Результат выполнения работ приводится согласно стандартам в виде набора документов «Текст программы» для отдельных программных модулей в расчете на доступность понимания синтаксиса, семантики и прагматики ПО технологически подготовленным пользователем документа, даже когда пользователь не связан с программной реализацией. Этапы разработки программного продукта Этап VI. Подготовка программной документации, в которой необходимы два раздела, ориентированных на специалистов двух категорий: • Персонал разработки и сопровождения программного изделия. • Конечный пользователь ППП. Результат – пакет документов «Описание применения» и «Руководство пользователя». Этапы разработки программного продукта Этап VII. Представление материалов по управлению процессом разработки, связанным с обеспечением фактического выполнения календарного плана, утвержденного в ТЗ. Результат – указание фактических затрат ресурсов и причины их отклонения от предполагаемых. Формулируются предложения по корректировке цены поставки и сопровождения ПП в зависимости от результатов разработки. Варианты тем курсовых работ Этап разработки ПП Темы КР Этап I Анализ требований к ПП и ТЗ Этап II Планирование и технологическая подготовка разработки ПП Этап III Проектирование архитектуры ПП Этап IV Разработка проекта ПП Этап V Программная реализация и тестирование ПП Этап VI Разработка сопроводительной документации к ПП Этап VII Разработка документации по управлению проектом Дополнительные темы Разработка интерфейса АЭИС на примере среды разработки. Стандартизация и профили стандартов открытых систем. Показатели качества ПП. Методы формирования обратной связи между пользователем и приложением. Основные определения Стандартизация разработка и установление требований, норм, правил, характеристик, обязательных или рекомендуемых для выполнения, обеспечивающая права потребителей на качественный продукт Базовый стандарт нормативный документ, регламентирующий типовые требования, нормы и правила применительно к объекту стандартизации Прикладное программное обеспечение (ППО) ПО, выполняющее задачи, поставленные конечными пользователями Пакет прикладных программ (ППП) (software package) готовый исходный код нескольких приложений Жизненный цикл (ЖЦ) программного средства комплекс работ по созданию программного средства от момента принятия решения о начале разработки до окончания функционирования программного средства на объекте автоматизации Качество ПС совокупность признаков и характеристик продукции, отражающая способность удовлетворять установленным или предполагаемым потребностям Классификация стандартов География стандартов: Международные Национальные Отраслевые Внутрифирменные (ГОСТ 19.201-78 Техническое задание и др.) В зависимости от возникновения: Де-факто (SQL, SADT) Де-юре (OSI – Open Systems Interconnection reference model, Ethernet, POSIX, SQL) Стандарты на организацию жизненного цикла ПС: Стандарты обеспечения качества Стандарты надежности Стандарты разработки ПО Стандарты тестирования Стандарты документирования Стандарты интерфейса Стандарты программирования Стандарты обмена данными Классификация стандартов По моделям разработки: RUP TickiT CMM ORACLE: CDM PJM AIM BPR DWM IEEE Software Engineering Standards IEEE / EIA 12207 CleanRoom Software Engineering Model Разработка стандартов Международные организации: 1946 г. – Международная организация по стандартизации: вопросы стандартизации во всех областях, кроме электротехники и электроники 1881 г. – Международная электротехническая комиссия: вопросы стандартизации в области электротехники и электроники, радиосвязи и приборостроения 1987 г. – Объединенный технический комитет: объединенная деятельность ИСО и МЭК Российские организации: Государственный комитет РФ по стандартизации: федеральный орган исполнительной власти, осуществляющий межотраслевую координацию, а также функциональное регулирование в области стандартизации, метрологии и сертификации Технические комитеты по стандартизации: рабочие органы Государственного комитета РФ по стандартизации; специализируются в зависимости от объекта стандартизации International Organization for Standartization (ISO), International Electrotechnical Commission (IEC): стандарты ISO/IEC http://www.iso.org/iso/home.htm Руководство ISO/IEC рекомендует нормативные документы: • Стандарты: нормативные документы, разработанные на основе консенсуса, утвержденные признанным органом, направленные на достижение оптимальной степени упорядочения в определенной области • Документы технических условий: устанавливают технические требования к продукции, услуге, процессу • Своды правил: разрабатываются для процессов проектирования, монтажа, технического сопровождения объектов, конструкций, изделий • Регламенты: документ, содержащий обязательные правовые нормы ГОСТ Р ИСО/МЭК 12207-99 «Информационная технология. Процессы жизненного цикла программных средств» Процесс заказа. Определяет работы организации, которая приобретает систему, программный продукт или программную услугу. Процесс поставки. Определяет работы организации, которая поставляет систему, программный продукт или программную услугу. Процесс разработки. Определяет работы разработчика, то есть организации, которая проектирует и разрабатывает программный продукт. Процесс эксплуатации. Определяет работы организации, которая обеспечивает эксплуатационное обслуживание вычислительной системы в заданных условиях в интересах пользователей. Процесс сопровождения. Определяет работы организации, которая предоставляет услуги по сопровождению программного продукта, состоящие в контролируемом изменении программного продукта с целью сохранения его исходного состояния и функциональных возможностей. Данный процесс охватывает перенос и снятие с эксплуатации программного продукта. Российские стандарты Федеральный закон №184-ФЗ «О техническом регулировании» устанавливает правовые нормы: • Стандартизация. Осуществляется в целях: технической и информационной совместимости; сопоставимости результатов исследований (испытаний) и измерений, технических и экономико-статистических данных; взаимозаменяемости продукции. • Технические регламенты. Технические регламенты с учетом степени риска причинения вреда устанавливают минимально необходимые требования, обеспечивающие безопасность работ. • Подтверждение соответствия. Удостоверение соответствия продукции, процессов производства, эксплуатации, хранения, перевозки, реализации и утилизации, работ, услуг или иных объектов техническим регламентам, стандартам, условиям договоров. • Аккредитация органов по сертификации и испытательных лабораторий (центров). Подтверждение компетентности органов по сертификации и испытательных лабораторий (центров), выполняющих работы по подтверждению соответствия. • Государственный контроль (надзор) за соблюдением требований технических регламентов. • Информация о нарушении требований технических регламентов и отзыв продукции. • Информация о технических регламентах и документах по стандартизации. • Финансирование в области технического регулирования. Классификация стандартов ЕСПД ГОСТ 19.001-77 «Единая система программной документации» Код группы Наименование группы 0 Общие положения 1 Основополагающие стандарты 2 Правила выполнения документации разработки 3 Правила выполнения документации изготовления 4 Правила выполнения документации сопровождения 5 Правила выполнения эксплуатационной документации 6 Правила обращения программной документации 7 Резервные группы 8 9 Прочие стандарты Классификация Пакетов Прикладных Программ Приложения для ПК Текстовые редакторы, электронные таблицы, СУБД MSOffice Языки запросов / Генераторы отчетов Извлечение информации из БД EasyTrieve Intellect Query By Example SQL RPG-III Inquire Графические языки Извлечение информации из БД и представлении ее в графическом виде SyStat SAS Graph Harvard Graphics Генераторы приложений Модули кода, генерирующие другие приложения FOCUS DMS SAS Mapper Ideal Natural CSP ППП Готовый исходный код нескольких приложений MSA PayRoll Maxicalc AVP Sales/Use Tax AMAPS Языки высокого уровня Генерирование программного кода с меньшим количеством инструкций APL Nomad Жизненный цикл программного средства Каскадная модель (70-е гг.) Плюсы модели На каждом этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности Логичная последовательность этапов работ позволяет планировать сроки завершения всех работ и затраты Формирование требований к ПС Проектирование Реализация Минусы модели Реальный процесс не укладывается в жесткую схему Существенное отставание от графика из-за согласований с пользователем только в контрольных точках Фиксированное ТЗ на все время проекта Тестирование Ввод в эксплуатацию Эксплуатация и сопровождение Функциональная и информационная модели автоматизируемого объекта могут устареть одновременно со сдачей проекта Жизненный цикл программного средства Модифицированная каскадная модель (80-е гг.) Формирование требований к ПС Проектирование Реализация Тестирование Ввод в эксплуатацию Эксплуатация и сопровождение Функциональная и информационная модели автоматизируемого объекта могут устареть одновременно со сдачей проекта Жизненный цикл программного средства Спиральная модель (90-е гг.) Проектирование системной архитектуры Определение требований к ПС ВЕРСИЯ Реализация и тестирование Сопровождение ПС Интеграция Снятие с эксплуатации Основная проблема – определение момента перехода на следующий этап Этапы моделей жизненных циклов ПС Этап Состав работ Документы Формирование требований к ПС Выбрать и адаптировать стандарты и языки программирования, принятые в организации разработчика, с учетом требований к: • функционалу ПС, • эргономике ПС, включая требования к ручным операциям «человек-машина», • защите информации, • документации, • … и другим согласно специфике объекта автоматизации. ГОСТ Р ИСО/МЭК 9126 Корпоративная спецификация на разработку «Требования к программному средству» Проектирование системной и программной архитектур 1. Указать объекты технических и программных средств и ручных операций 2. Разработать проект пользовательских и административных интерфейсов 3. Разработать проект архитектуры базы данных 4. Разработать предварительную версию пользовательской документации 5. Разработать требования к тестированию ПС Корпоративная спецификация привязки системной и программной архитектур к объектам автоматизации Программная реализация ПС Разработать каждый программный модуль и базу данных Корпоративная спецификация на требования к программному коду, внешним и внутренним интерфейсам ПС Тестирование ПС Разработать процедуры испытаний и данные для тестирования каждого программного модуля и базы данных Корпоративная спецификация на проведение тестовых испытаний ПС Интеграция ПС с имеющимся ПО и внедрение ППО на объекте автоматизации Разработать план по вводу в эксплуатацию ППО на объекте автоматизации. Выполнить инициализацию ППО и БД на объекте заказчика. Договор на поставку, разработку, производство, эксплуатацию и сопровождение ППО. План по вводу в действие ППО. Сопровождение ППО Изменение существующего ПП при сохранении его целостности. Определение, какие документы и программные модули требуют изменения. Решение вопросов переноса и снятия ПП с эксплуатации. Договор на поставку, разработку, производство, эксплуатацию и сопровождение ППО. Качество программного средства ГОСТ Р ИСО/МЭК 9126-93 Качество ПС Характеристика – характеристики ПС, характеризующие их способность удовлетворять потребности пользователя Определение Примечание I. Функционал (Functionality) Функции, реализующие установленные или предполагаемые потребности Функционал определяет, что может сделать программа для удовлетворения потребностей пользователя II. Надежность (Reliability) Способность ПО сохранять уровень качества функционирования, при заданных условиях, определенный период времени Снижение надежности происходит из-за ошибок в требованиях, проекте и реализации III. Практичность (Usability) Объем работ, требуемый для использования ППО определенным или предполагаемым кругом пользователей В данном определении практичность отличается от требований эргономики IV. Эффективность (Efficiencies) Отношение уровня качества функционирования ППО к объему необходимых ресурсов Ресурсы также включают другие ПП и работу сопровождающего персонала V. Сопровождаемость (Maintainability) Объем работ, требуемых для проведения модификаций Модификация – исправления, усовершенствования, адаптация ПО к изменениям в условиях эксплуатации VI. Мобильность (Portability) Возможность переноса ППО из одного окружения в другое. Окружение – организационная, техническая, программная среда Модель процесса оценки качества ПС Качество ПС характеристики ПС, характеризующие их способность удовлетворять потребности пользователя Надежность ПС способность ПС сохранять качество функционала в течение периода эксплуатации ПС Метрика качества ПС количественный метод, который может быть применен для определения значения характеристики ПС Уровень ранжирования диапазон значений, позволяющий классифицировать ПС в соответствии с установленными потребностями. Ранжирование выполняется на уровнях пользовательруководитель-разработчик Критерии оценки качества ПС комплекс задокументированных критериев, используемый как основание для принятия решений о приемлемости качества ПС Модель процесса оценки качества ПС Потребности пользователя Спецификация требований качества Определение требований к качеству Выбор метрик Разработка ПО Измерения Административные требования Определение уровня ранжирования Ранжирование Определение критерия оценки Оценка Результат Уровни ранжирования ПС Уровень пользователей Уровень разработчика Интерес – область применения ПС, функционал ПС, производительность ПС. Заинтересованы в качестве промежуточной продукции так же, как в качестве конечного продукта. Оценка ПС – без изучения внутренних аспектов, программного кода и т.п. Согласно ЖЦ ПС, для одних и тех же характеристик ПС, но на разных этапах, используются различные метрики качества ПС Уровень руководителя Интерес – в общем качестве ПС, а не в отдельной характеристике. Оценка ПС – по критериям управляемости (плановая задержка, перерасход стоимости проекта и т.п.) в границах имеющихся ресурсов Планирование работ по разработке ПС Поставщик ПС – организация, заключившая договор с заказчиком на поставку ПП на условиях, оговоренных в договоре Заказчик ПС – организация, приобретающая ПП от поставщика Анализ требований к заказу с целью формирования структуры управления проектом и обеспечения необходимого качества ПС II. Выбор модели ЖЦ ПС. В модели ЖЦ выбрать и структурировать процессы, работы и задачи III. Сформулировать требования к планам реализации проекта согласно задач заказчика и обеспеченности ресурсами Анализ вариантов I. Разработка с применением ресурсов поставщика Передача разработки в аутсорсинг, на основе субподрядных договоров План управления проектом Приобретение готовых программных решений Содержание документа «Управление проектом по разработке ПС» I. Организационная структура проекта. Полномочия и обязанности участников проекта II. Среда разработки, эксплуатации и сопровождения ПС. Тестовые испытания, архивы, стандарты, процедуры, инструментарий III. Распределение заданий по процессам и работам ЖЦ согласно смет, составов исполнителей и графиков выполнения работ IV. Критерии оценки качества ПП. Планы по обеспечению качества V. Управление безопасностью, защитой и другими критическими требованиями к ПП. Паны по обеспечению безопасности и защиты VI. Управление субподрядчиками VII. Верификация и аттестация ПП VIII. График совместной работы с заказчиком над проектом IX. Управление критическими точками проекта (потенциальные технические, финансовые и иные затруднения в реализации проекта) X. Вопросы прав собственности, использования и распространения ПП XI. Обучение персонала Квалификационные испытания ПС ГОСТ Р ИСО/МЭК 12119-2000 Квалификационное испытание (qualification testing) – тестирование ПС, проводимое разработчиком для демонстрации того, что ПП удовлетворяет установленным требованиям и готов к использованию в среде эксплуатации. Результат квалификационных испытаний документально оформляется. Цели работ I. Установить, что реализация каждого требования к ИС соответствует установленным значениям, а система готова к поставке. II. Установить, что: • тестовое покрытие требований к ИС выполнено (функционал ИС соответствует заявленному в ТЗ) • система готова к эксплуатации и сопровождению III. Выполнить аудиторскую проверку ИС, т.е. установить соответствие ИС целям, планам и условиям Договора на разработку ПС IV. Определить, по необходимости, состав и сроки выполнения работ по доработке ПС Для тестирования ППП должны иметься в наличии все его поставляемые компоненты, а также нормативные документы, указанные в описании ПП. Если в описании продукта указана необходимость обучения работе с системой, тестировщик должен иметь доступ к учебным материалам и обучающим программам. Протоколы по каждому тесту должны содержать информацию, достаточную для повторения теста. Этапы тестовых испытаний ПС I. Описание продукта (структура документа) Описание ПП должно быть понятным, полным и простым 1) Описанию продукта д.б. присвоено индивидуальное обозначение как документу («Описание функциональных возможностей», «Формуляр продукта» и т.п. 2) Описание продукта должно определять продукт, - обозначение продукта должно включать наименование продукта, версию, дату выпуска и др. характеристики 3) Описание продукта должно содержать наименование и адрес по крайней мере одного поставщика 4) В описании продукта д.б. определены целевые рабочие задачи, которые могут выполнены продуктом 5) В описании продукта д.б. ссылки на нормативные документы (ГОСТы), которым удовлетворяет продукт 6) В описании д.б. определена система (технические и программные средства и их конфигурация), необходимая для ввода продукта в эксплуатацию (процессоры, сопроцессоры, объемы памяти, расширяющие платы, периферийное и сетевое оборудование, системные и др. ПС) 7) В описании д.б. определены все используемые интерфейсы, как внутрисистемные, так и межкомпонентные 8) В описании д.б. определен каждый физический компонент ПС (все печатные документы и носители данных) 9) В описании д.б. указано, кем будет выполнена инсталляция продукта, а также будет ли продукт поставлен на сопровождение исполнителем 10) В описании д.б. приведен обзор функционала продукта, в т.ч. по процедурам сохранения данных и криптозащите 11) … и другие данные согласно ГОСТ Р ИСО/МЭК 12119-2000 Этапы тестовых испытаний ПС II. Документация пользователя (структура документа) В документации пользователя должен быть исчерпывающе описан функционал системы: 1) Полнота: -граничные значения ПС, заданные в описании ПС, д.б. продублированы в документации пользователя -инструкция по инсталляции в случае, когда ПП допускает установку пользователем, включая размеры устанавливаемых файлов, дерево директорий с указанием назначения системных, служебных, пользовательских файлов, файлов БД и т.п. 2) Правильность: документация не должна содержать неоднозначных толкований и ошибок 3) Непротиворечивость: каждый термин должен иметь одно и то же определение во всем пакете документов 4) Понятность: документация д.б. понятна в среде эксплуатации ПС 5) Простота изучения: документация д.б. снабжена оглавлением, предметным указателем, в случае поставки на электронном носителе – понятной процедурой распечатки и т.д. Этапы тестовых испытаний ПС III. Программы и данные (структура документа) 1) - - 2) 3) Функционал: инсталляция, контрольные примеры и самотестирование реализация функций, - функционал, определенный в ТЗ и документации пользователя, должен выполняться в утвержденном заказчиком виде, в рамках граничных значений, установленных в документации пользователя правильность, - функционал должен выполняться методами, утвержденными в рабочей задаче; программы и данные должны соответствовать требованиям нормативных документов (ГОСТов) непротиворечивость, - данные не должны противоречить сами себе, а также описанию продукта и документации пользователя Надежность. ПС не должно приходить в состояние, когда пользователь не может его контролировать, а данные не должны повреждаться либо теряться. В частности, ПС должно обнаруживать нарушения синтаксических правил для исходных данных и не должно обрабатывать ошибочные исходные данные как допустимые исходные данные Практичность: понятность, простота обозрения, простота использования Содержание документа «Отчет о тестировании ПС» I. Обозначение продукта II. Вычислительные системы, использованные при тестировании (технические средства, программные средства и их конфигурация) III. Использованные документы IV. Результаты тестирования документации пользователя, программ и данных V. Перечень несоответствия требованиям VI. Перечень несоответствия рекомендациям либо формулировка того, что ПП не был протестирован на соответствие рекомендациям VII. Дата окончания тестовых испытаний Когда ПП тестируется повторно, все измененные части документов, функций и данных, а также части, на которые они могут влиять, тестируются как новый продукт. Все другие части ПС тестируются выборочно. Средства тестирования Тестирование – процесс исполнения программы с целью обнаружения ошибок Регрессивное тестирование – процесс повторного тестирования после внесения изменений в ПС QA (Quality Works) – интегрированная многоплатформенная среда (Windows, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris) для разработки автоматизированных тестов любого уровня, в т.ч. регрессивные тесты, для приложений с графическим интерфейсом пользователя. Тестирование возможно начать на любом этапе ЖЦ, планировать, управлять процессом тестирования, отображать изменения в приложении и повторно применять тесты. QA Partner QA Planner Agent – среда разработки, компиляции и выполнения тестов – модуль разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner – модуль, поддерживающий работу в сети QA: привязка к ЖЦ Создание плана тестирования Составление схемы тестовых требований и выделение уровней детализации: функциональная декомпозиция ПС – сколько и каких тестов необходимо для каждой функции и характеристики Соотнесение плана с тестами Создание управляющих предложений (скриптов) на языке 4Test и тесты, выполняющие требования плана Пометка и выполнение тестов Все результаты Получение отчетов о тестирования связаны с планом: тестировании и просмотр управление информации о результатами выполнении, объединение файлов результатов, разметка неудавшихся тестов, сравнение результатов с предыдущим тестированием и т.д.
