ответы на билеты, страница 3

Для обеспечения качества и надежности ПС стандартами рекомендуется формулировать

требования:

• к объекту разработки на данном этапе — к его программным и информационным компонентам, а также к интерфейсу между ними и внешней средой;

• к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа;

• к методам и характеристикам средств автоматизации выполнения работ, обеспечивающим необходимую надежность функционирования и качество ПС;

• к методам и средствам контроля, измерения и документирования качества процессов и результатов выполненных работ.

БИЛЕТ 15. УРОВНИ РАНЖИРОВАНИЯ ПС

Уровень пользователей

Интерес – область применения ПС, функционал ПС, производительность ПС.
Оценка ПС – без изучения внутренних аспектов, программного кода и т.п.

Уровень разработчика

Заинтересованы в качестве промежуточной продукции так же, как в качестве конечного продукта.
Согласно ЖЦ ПС, для одних и тех же характеристик ПС, но на разных этапах, используются различные метрики качества ПС

Уровень руководителя

Интерес – в общем качестве ПС, а не в отдельной характеристике.
Оценка ПС – по критериям управляемости (плановая задержка, перерасход стоимости проекта и т.п.) в границах имеющихся ресурсов

БИЛЕТ 16. ПЛАНИРОВАНИЕ РАБОТ ПО РАЗРАБОТКЕ ПС. АЛЬТЕРНАТИВЫ МОДЕЛИ ВЗАИМОДЕЙСТВИЯ «ПОСТАВЩИК-ЗАКАЗЧИК».

Поставщик ПС – организация, заключившая договор с заказчиком на поставку ПП на условиях, оговоренных в договоре
Заказчик ПС – организация, приобретающая ПП от поставщика

1. Анализ требований к заказу с целью формирования структуры управления проектом и обеспечения необходимого качества ПС

2. Выбор модели ЖЦ ПС. В модели ЖЦ выбрать и структурировать процессы, работы и задачи

3. Сформулировать требования к планам реализации проекта согласно задач заказчика и обеспеченности ресурсами

БИЛЕТ 17. СОДЕРЖАНИЕ ДОКУМЕНТА «УПРАВЛЕНИЕ ПРОЕКТОМ ПО РАЗРАБОТКЕ ПС»

1. Организационная структура проекта. Полномочия и обязанности участников проекта

2. Среда разработки, эксплуатации и сопровождения ПС. Тестовые испытания, архивы, стандарты, процедуры, инструментарий

3. Распределение заданий по процессам и работам ЖЦ согласно смет, составов исполнителей и графиков выполнения работ

4. Критерии оценки качества ПП. Планы по обеспечению качества

5. Управление безопасностью, защитой и другими критическими требованиями к ПП. Паны по обеспечению безопасности и защиты

6. Управление субподрядчиками

7. Верификация и аттестация ПП

8. График совместной работы с заказчиком над проектом

9. Управление критическими точками проекта (потенциальные технические, финансовые и иные затруднения в реализации проекта)

10. Вопросы прав собственности, использования и распространения ПП

11. Обучение персонала

БИЛЕТ 18. КВАЛИФИКАЦИОННЫЕ ИСПЫТАНИЯ ПС СОГЛАСНО ГОСТ ИСО/МЭК 12119.

Квалификационное испытание (qualification testing) – тестирование ПС, проводимое разработчиком для демонстрации того, что ПП удовлетворяет установленным требованиям и готов к использованию в среде эксплуатации.

Результат квалификационных испытаний документально оформляется.

Цели работ

1. Установить, что реализация каждого требования к ИС соответствует установленным значениям, а система готова к поставке.

2. Установить, что:

   • тестовое покрытие требований к ИС выполнено (функционал ИС соответствует заявленному в ТЗ)

   • система готова к эксплуатации и сопровождению

   • Выполнить аудиторскую проверку ИС, т.е. установить соответствие ИС целям, планам и условиям Договора на разработку ПС

   • Определить, по необходимости, состав и сроки выполнения работ по доработке ПС

Для тестирования ППП должны иметься в наличии все его поставляемые компоненты, а также нормативные документы, указанные в описании ПП. Если в описании продукта указана необходимость обучения работе с системой, тестировщик должен иметь доступ к учебным материалам и обучающим программам.

Протоколы по каждому тесту должны содержать информацию, достаточную для повторения теста.

БИЛЕТ 19. ЭТАПЫ ТЕСТОВЫХ ИСПЫТАНИЙ ПС

I. Описание продукта (структура документа)

• Описание ПП должно быть понятным, полным и простым

• Описанию продукта д.б. присвоено индивидуальное обозначение как документу («Описание функциональных возможностей», «Формуляр продукта» и т.п.

• Описание продукта должно определять продукт, - обозначение продукта должно включать наименование продукта, версию, дату выпуска и др. характеристики

• Описание продукта должно содержать наименование и адрес по крайней мере одного поставщика

• В описании продукта д.б. определены целевые рабочие задачи, которые могут выполнены продуктом

• В описании продукта д.б. ссылки на нормативные документы (ГОСТы), которым удовлетворяет продукт

• В описании д.б. определена система (технические и программные средства и их конфигурация), необходимая для ввода продукта в эксплуатацию (процессоры, сопроцессоры, объемы памяти, расширяющие платы, периферийное и сетевое оборудование, системные и др. ПС)

• В описании д.б. определены все используемые интерфейсы, как внутрисистемные, так и межкомпонентные

• В описании д.б. определен каждый физический компонент ПС (все печатные документы и носители данных)

• В описании д.б. указано, кем будет выполнена инсталляция продукта, а также будет ли продукт поставлен на сопровождение исполнителем

• В описании д.б. приведен обзор функционала продукта, в т.ч. по процедурам сохранения данных и криптозащите

… и другие данные согласно ГОСТ Р ИСО/МЭК 12119-2000

II. Документация пользователя (структура документа)

В документации пользователя должен быть исчерпывающе описан функционал системы:

• Полнота: граничные значения ПС, заданные в описании ПС, д.б. продублированы в документации пользователя

• инструкция по инсталляции в случае, когда ПП допускает установку пользователем, включая размеры устанавливаемых файлов, дерево директорий с указанием назначения системных, служебных, пользовательских файлов, файлов БД и т.п.

• Правильность: документация не должна содержать неоднозначных толкований и ошибок

• Непротиворечивость: каждый термин должен иметь одно и то же определение во всем пакете документов

• Понятность: документация д.б. понятна в среде эксплуатации ПС

• Простота изучения: документация д.б. снабжена оглавлением, предметным указателем, в случае поставки на электронном носителе – понятной процедурой распечатки и т.д.

III. Программы и данные (структура документа)

Функционал:

• инсталляция, контрольные примеры и самотестирование

• реализация функций, - функционал, определенный в ТЗ и документации пользователя, должен выполняться в утвержденном заказчиком виде, в рамках граничных значений, установленных в документации пользователя

• правильность, - функционал должен выполняться методами, утвержденными в рабочей задаче; программы и данные должны соответствовать требованиям нормативных документов (ГОСТов)

• непротиворечивость, - данные не должны противоречить сами себе, а также описанию продукта и документации пользователя

• Надежность. ПС не должно приходить в состояние, когда пользователь не может его контролировать, а данные не должны повреждаться либо теряться. В частности, ПС должно обнаруживать нарушения синтаксических правил для исходных данных и не должно обрабатывать ошибочные исходные данные как допустимые исходные данные

• Практичность: понятность, простота обозрения, простота использования

БИЛЕТ 20. СОСТАВ ДОКУМЕНТА «ОТЧЕТ О ТЕСТИРОВАНИИ ПС» СОГЛАСНО ПРИНЯТЫХ СТАНДАРТОВ.

1. Обозначение продукта

2. Вычислительные системы, использованные при тестировании (технические средства, программные средства и их конфигурация)

3. Использованные документы

4. Результаты тестирования документации пользователя, программ и данных

5. Перечень несоответствия требованиям

6. Перечень несоответствия рекомендациям либо формулировка того, что ПП не был протестирован на соответствие рекомендациям

7. Дата окончания тестовых испытаний

Когда ПП тестируется повторно, все измененные части документов, функций и данных, а также части, на которые они могут влиять, тестируются как новый продукт.

Все другие части ПС тестируются выборочно.

БИЛЕТ 21. ВИДЫ И СРЕДСТВА ТЕСТИРОВАНИЯ ПС. ЭТАПЫ ПРИМЕНЕНИЯ СРЕДСТВ ТЕСТИРОВАНИЯ СОГЛАСНО ВЫБРАННОЙ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА ПС

Тестирование – процесс исполнения программы с целью обнаружения ошибок

Регрессивное тестирование – процесс повторного тестирования после внесения изменений в ПС

QA (Quality Works) – интегрированная многоплатформенная среда (Windows, OS/2, Macintosh, VMS, HP-UX, AIX, Solaris) для разработки автоматизированных тестов любого уровня, в т.ч. регрессивные тесты, для приложений с графическим интерфейсом пользователя.

Тестирование возможно начать на любом этапе ЖЦ, планировать, управлять процессом тестирования, отображать изменения в приложении и повторно применять тесты.

QA Partner – среда разработки, компиляции и выполнения тестов

QA Planner – модуль разработки планов тестирования и обработки результатов. Для создания и выполнения тестов в процессе работы QA Planner вызывается QA Partner

Agent – модуль, поддерживающий работу в сети

БИЛЕТ 22. ТИПОВОЙ СОСТАВ ПРОГРАММНОЙ ДОКУМЕНТАЦИИ СОГЛАСНО ГОСТ 19.101.

БИЛЕТ 23. ТИПОВОЙ СОСТАВ ЭКСПЛУАТАЦИОННОЙ ДОКУМЕНТАЦИИ СОГЛАСНО ГОСТ 19.101.

БИЛЕТ 24. СТАНДАРТИЗАЦИЯ POSIX. СИСТЕМА СТАНДАРТОВ POSIX, ОСНОВНЫЕ СПЕЦИФИКАЦИИ.