- •9. Использование itil для обеспечения качества при проектировании пс.
- •Стандарты iso, используемые при обеспечении качества процессов создания пс.
- •10 . Методология «6 сигма» и качество пс.
- •11. Cmmi и iso/iec 15504 – сходства и различия.
- •32. Документ "Программа-методика испытания программного средства". Содержание и сфера применения
- •34. Понятие метода и технологии проектирования программных средств
- •Требования к технологии
- •7 Стандартизация пс.
- •13. Достоинства и недостатки cmm/cmmi
- •24. Стадии разработки пс: технический проект.
- •19. Интеграция и установка пс.
- •23. Стадии разработки пс: рабочий проект.
- •18 Приёмка и сопровождение пс.
- •21. Подготовительные работы, анализ требований к системе, проектирование архитектуры системы на высоком уровне
- •17. Жизненный цикл пс (общие сведения).
- •20. Детальное проектирование, кодирование и тестирование пс.
- •25 . Стадии разработки пс: эскизный проект.
- •26. Стадии разработки пс: стадия разработки тз.
- •29. Основы качества пс.
- •31 . Структурное программирование
- •33. Программная инженерия. Понятие модели архитектуры по.
- •35. Основные понятия связанные с управлением требованиями
- •1) Финансовые
- •2) Временные
- •3) Кадровые
- •4) Аппаратурные
- •36. Характеристики качественных требований. По-разному определены различными источниками. Однако, следующие характеристики являются общепризнанными:
- •40. Виды испытаний пс.
- •22. Стадии разработки пс: внедрение.
- •37 Виды ресурсов жизненного цикла программных средств
- •1) Финансовые
- •2) Временные
- •3) Кадровые
- •4) Аппаратурные
32. Документ "Программа-методика испытания программного средства". Содержание и сфера применения
Настоящий стандарт устанавливает требования к содержанию и оформлению программного документа «Программа и методика испытаний», определенного ГОСТ 19.101-77. 1. Общие положения: 1.1. Структура и оформление документа устанавливается в соответствии с ГОСТ 19.105-78. Составление информационной части (аннотации и содержания) является необязательным. 1.2. Документ «Программа и методика испытаний» должен содержать следующие разделы: объект испытаний; цель испытаний; требования к программе; требования к программной документации; состав и порядок испытаний; методы испытаний. В зависимости от особенностей документа допускается вводить дополнительные разделы.
2. Содержание разделов: 2.1. В разделе «Объект испытаний» указывают наименование, область применения и обозначение испытуемой программы. 2.2. В разделе «Цель испытаний» должна быть указана цель проведения испытаний. 2.3. В разделе "Требования к программе" должны быть указаны требования, подлежащие проверке во время испытаний и заданные в техническом задании на программу. 2.4. В разделе "Требования к программной документации" должны быть указаны состав программной документации, предъявляемой на испытания, а также специальные требования, если они заданы в техническом задании на программу. 2.5. В разделе "Средства и порядок испытаний" должны быть указаны технические и программные средства, используемые во время испытаний, а также порядок проведения испытаний. 2.6. В разделе "Методы испытаний" должны быть приведены описания используемых методов испытаний. Методы испытаний рекомендуется по отдельным показателям располагать в последовательности, в которой эти показатели расположены в разделах "Требования к программе" и "Требования к программной документации". В методах испытаний должны быть приведены описания проверок с указанием результатов проведения испытаний (перечней тестовых примеров, контрольных распечаток тестовых примеров и т. п.). 2.7. В приложение к документу могут быть включены тестовые примеры, контрольные распечатки тестовых примеров, таблицы, графики и т. п.
1. Каскадная модель ЖЦ – основной особенностью каскадной модели ЖЦ является наличие ярко выраженной последовательности выполнения этапов разработки направленных на достижение конечного результата, при этом с любой стадией, как правило, можно вернуться на любую предшествующую стадию разработки. Выделяют следующие основные этапы каскадной модели ЖЦ:
- Системный анализ который задает место каждого компонента в компьютерной системе и взаимодействия компонентов друг с другом, на основании требований ко всем системным элементам, сформированным на основе изучения более общей системы;
- Анализ требований в ходе которого уточняется, детализируется функция программного средства, его характеристики и интерфейс. Кроме того на данном этапе осуществляется управление требованиями и выявлением требований которые уже отработаны в других проектах с целью применения уже готовых компонентов в новой системе
- Проектирование – в ходе которого формируется интегрированная системная модель будущего программного средства. Проектирование включает создание следующих представлений: Архитектура программного средства; Модульная структура программных средств – набор модулей; Алгоритмическая структура программного средства; Структура данных; Входной и выходной интерфейс; входные и выходные формы данных.
При проектировании разработанные выше требования транслируются в проектные модели которые должны быть логически связанны между собой и отражать различные аспекты одной и той же сущности, т.е сущность это определенная программа.
- Кодирование – перевод результатов проектирования в текст на языке программирования;
- Тестирование – состоит в выполнении определенных мероприятий направленных на выявление дефектов в функциях, логике и форме реализации программного средства;
- Сопровождение – состоит во внедрении всевозможных изменений в программные средства, изменения могут быть связанны с: Исправлением ошибок; Адаптацией к изменениям внешней для программы среды; Адаптацией программного средства к новому требованию заказчика. Достоинства каскадной модели ЖЦ: Позволяет планировать по времени все этапы проекта; Упорядочивает ход проектирования благодаря наличию строго оговоренных правил. Недостатки каскадной модели ЖЦ: Возможно организационные проблемы связанные с тем что реальные проекты часто требуют отклонения от сложившейся в последовательности шагов; Предполагается на начальном этапе наличия точной формулировки исходных требований к программным средствам, хотя на практике это трудно достижимо; Экономический – результаты проекта доступны заказчику только после его окончания.
Каскадная модель изначально разрабатывалась для решения различного рода инженерных задач и не потеряла своего значения для прикладной области до настоящего времени. Кроме того, каскадный подход хорошо зарекомендовал себя при разработке определенных информационных систем. В процессе создания ПС постоянно возникала потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений. В результате реальный процесс создания ПС принимал следующий вид:
Основным недостатком каскадного подхода является существенное запаздывание с получением результатов. Согласование результатов с пользователями производится только в точках, планируемых после завершения каждого этапа работ, требования к ИС «заморожены » в виде технического задания на все время ее создания. Таким образом, пользователи могут внести свои замечания только после того, как работа над системой будет полностью завершена. В случае неточного изложения требований или их изменения в течение длительного периода создания ПС пользователи получают систему, не удовлетворяющую их потребностям. Модели (как функциональные, так и информационные) автоматизируемого объекта могут устареть одновременно с их утверждением. Пример: Сложные расчетные программные комплексы и системы реального времени.
3. Испытание ПС процесс проведения комплекса мероприятий, исследующих пригодность ПС для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. Целью испытания является экспериментальное определение фактических (достигнутых) характеристик свойств испытываемого ПС и определение степени соответствия созданного комплекса программ техническому заданию, полученному от заказчика. Эти характеристики могут быть как количественными, так и качественными. Важно, чтобы на их основе можно было сделать вывод о пригодности данного ПС к использованию по своему назначению. Если вывод отрицательный, то образец ПС возвращается на доработку. Таким образом, перекрывается доступ недоброкачественной продукции к пользователю. Длительность испытания зависит от типа, конфигурации (сложности) ПС, а также от целей и степени автоматизации рассматриваемого технологического процесса. В подготовку испытаний ПС входят: — составление и согласование плана-графика проведения испытания; — разработка, комплектование, испытание и паспортизация программно-технических средств, используемых при испытаниях; — анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний; — анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС; — проверка и согласование с представителем Заказчика конструкторской документации на ПС, предъявляемой при испытаниях; — разработка, согласование и утверждение программ и методик испытаний; — аттестация специалистов на допуск к проведению испытаний; — приемка испытываемого опытного образца ПС на носителе данных и документации; — проведение мероприятий, направленных на обеспечение достоверности испытаний.
Можно определить следующие пять этапов испытания. 1. Обследование проектируемого ПС, анализ проектной документации. 2. Определение наиболее важных подсистем, функций и путей проектируемого ПС, подлежащих испытанию. 3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания. 4. Разработка (освоение) испытательных программно-технических средств, библиотек тестов и баз данных (если они требуются). 5. Непосредственное проведение испытаний, анализ результатов, принятие решения
Для повышения эффективности испытания, его ускорения и удешевления необходимо разработать научно обоснованные методы, средства и методики, позволяющие преодолеть недостатки подхода к испытанию, недооценку его роли в обеспечении требуемого уровня качества ПП, подмену испытаний процедурами типа проверки работоспособности на контрольном примере и т. п
По согласованию с разработчиком (заказчиком) устанавливается последовательность испытаний ПО с учетом следующих этапов: 1. Проверка документации. 2. Проверка разделения ПО и наличия защищенных интерфейсов (с использованием программных средств, в том числе на основе анализа исходного кода). 3. Проверка соответствия утвержденному типу (идентификация) (на основе анализа документации и с использованием программных средств, в том числе на основе анализа исходного кода). 4. Испытание (тестирование) ПО с целью установления правильности функционирования и определения его свойств и характеристик и тестирование обработки данных (с использованием аппаратных и программных средств, в том числе на основе анализа исходного кода). 5. Тестирование защищенности ПО и данных (с использованием программных средств, в том числе на основе анализа исходного кода).
Результаты испытаний ПО признаются положительными, если: - программа соответствует функциональным возможностям, описанным в документации, и выполняет в рамках тестовых заданий все функции, декларируемые в документации; - полученные значения параметров и характеристик программы при выполнении всех тестовых заданий удовлетворяют установленным критериям или находятся в допустимых пределах отклонений от них; - в программе реализованы необходимые методы защиты и идентификации в соответствии с требованиями; - программная документация соответствует требованиям нормативных документов.
Если в процессе выполнения какого-либо из тестовых заданий произойдет отказ программы, ее «зависание» или искажение результатов, то данное тестовое задание может быть модифицировано для подтверждения ошибки функционирования и повторено. Выявленные ошибки фиксируются в протоколе испытаний. По результатам испытаний ПО СИ составляется акт о результатах его исследования неотъемлемой частью которого является протокол испытаний. Дальнейшие разделы рекомендации конкретизируют виды испытаний (тестирования). Система сертификации программного обеспечения средств измерений и информационно-измерительных систем Правила функционирования