Билет 1, 17 Стандарты еспд гост 19. 00177 Общие положения
 Скачать 259.58 Kb.
|
|
Билет №1, 17 1. Стандарты ЕСПД: ГОСТ 19.001-77 Общие положения ГОСТ 19.002-80 Схемы алгоритмов и программ. Правила выполнения ГОСТ 19.003-80 Схемы алгоритмов и программ. Обозначения условные графические ГОСТ 19.004-80 Термины и определения ГОСТ 19.005-85 Р-схемы алгоритмов и программ. Обозначения условные графические и правила выполнения ГОСТ 19.101-77 Виды программ и программных документов ГОСТ 19.102-77 Стадии разработки ГОСТ 19.103-77 Обозначение программ и программных документов ГОСТ 19.104-78 Основные надписи ГОСТ 19 105-78 Общие требования к программным документам ГОСТ 19.106-78 Требования к программным документам, выполненным печатным способом ГОСТ 19.201-78 Техническое задание. Требования к содержанию и оформлению ГОСТ 19.202-78 Спецификация. Требования к содержанию и оформлению ГОСТ 19.301-79 Программа и методика испытаний. Требования к содержанию и оформлению ГОСТ 19.401-78 Текст программы. Требования к содержанию и оформлению ГОСТ 19.402-78 Описание программы. Требования к содержанию и оформлению ГОСТ 19.403-79 Ведомость держателей подлинников ГОСТ 19.404-79 Пояснительная записка. Требования к содержанию и оформлению ГОСТ 19.501-78 Формуляр. Требования к содержанию и оформлению ГОСТ 19.502-78 Описание применения. Требования к содержанию и оформлению ГОСТ 19.503-79 Руководство системного программиста. Требования к содержанию и оформлению ГОСТ 19.504-79 Руководство программиста. Требования к содержанию и оформлению ГОСТ 19.505-79 Руководство оператора. Требования к содержанию и оформлению ГОСТ 19.506-79 Описание языка. Требования к содержанию и оформлению ГОСТ 19.507-79 Ведомость эксплуатационных документов ГОСТ 19.508-79 Руководство по техническому обслуживанию. Требования к содержанию и оформлению ГОСТ 19.601-78 Общие правила дублирования, учета и хранения ГОСТ 19.602-78 Правила дублирования, учета и хранения программных документов, выполненных печатным способом ГОСТ 19.603-78 Общие правила внесения изменений ГОСТ 19.604-78 Правила внесения изменений в программные документы, выполненные печатным способом ГОСТ 19.701-90 Схемы алгоритмов, программ, данных и систем. Условные Обозначения и правила выполнения 2. Тестирование чёрного ящика или поведенческое тестирование — стратегия (метод) тестирования функционального поведения объекта (программы, системы) с точки зрения внешнего мира, при котором не используется знание о внутреннем устройстве (коде) тестируемого объекта. Иначе говоря, тестированием чёрного ящика занимаются тестировщики, не имеющие доступ к исходному коду приложения. Под стратегией понимаются систематические методы отбора и создания тестов для тестового набора. Стратегия поведенческого теста исходит из технических требований и их спецификаций. В этом методе программа рассматривается как чёрный ящик. Целью тестирования ставится выяснение обстоятельств, в которых поведение программы не соответствует спецификации. Для обнаружения всех ошибок в программе необходимо выполнить исчерпывающее тестирование, то есть тестирование на всевозможных наборах данных. Для большинства программ такое невозможно, поэтому применяют разумное тестирование, при котором тестирование программы ограничивается небольшим подмножеством всевозможных наборов данных. При этом необходимо выбирать наиболее подходящие подмножества, подмножества с наивысшей вероятностью обнаружения ошибок. Свойства правильно выбранного теста[править | править код] 1. Уменьшает более чем на одно число других тестов, которые должны быть разработаны для разумного тестирования. 2. Покрывает значительную часть других возможных тестов, что в некоторой степени свидетельствует о наличии или отсутствии ошибки до и после ограниченного множества тестов. Приёмы тестирования чёрного ящика 1. Эквивалентное разбиение. 2. Анализ граничных значений. 3. Анализ причинно-следственных связей. 4. Предположение об ошибке. Билет 2, 20. Метод пошагового тестирования предполагает, что модули тестируются не изолированно друг от друга, а подключаются поочередно для выполнения теста к набору уже ранее оттестированных модулей. Пошаговый процесс продолжается до тех пор, пока к набору оттестированных модулей не будет подключен последний модуль. Восходящее тестирование. Программное обеспечение собирается и тестируется снизу вверх. Только модули самого нижнего уровня тестируются изолированно, автономно. Затем тестируются модули, непосредственно вызывающие их, которые тестируются не автономно, а вместе с уже проверенными модулями. И так, пока не будет достигнута вершина. В последнюю очередь тестируется программное обеспечение в целом. Нисходящее тестирование. Программное обеспечение собирается и тестируется сверху вниз. Изолированно тестируется только головной модуль. Затем с ним соединяются один за другим модули, непосредственно вызываемые им, и тестируется полученная комбинация. Так до тех пор, пока не будут собраны и проверены все модули. После завершения комплексного тестирования приступают к оценочному тестированию, целью которого является тестирование программы на соответствие основным требованиям. Эта стадия тестирования особенно важна для программных продуктов, предназначенных для продажи на рынке. Оценочное тестирование, которое также называют «тестированием системы в целом», включает следующие виды: • тестирование удобства использования - последовательная проверка соответствия программного продукта и документации на него основным положениям технического задания; • тестирование на предельных нагрузках - проверка выполнения программы на возможность обработки большого объема данных, поступивших в течение короткого времени; • тестирование удобства эксплуатации - анализ психологических факторов, возникающих при работе с программным обеспечением; это тестирование позволяет определить, удобен ли интерфейс, не раздражает ли цветовое или звуковое сопровождение и т. п.; • тестирование защиты - проверка защиты, например от несанкционированного доступа к информации; • тестирование производительности - определение пропускной способности при заданной конфигурации и нагрузке; • тестирование требований к памяти - определение реальных потребностей в оперативной и внешней памяти; • тестирование конфигурации оборудования - проверка работоспособности программного • тестирование совместимости - проверка преемственности версий: в тех случаях, если очередная версия системы меняет форматы данных, она должна предусматривать специальные конвекторы, обеспечивающие возможность работы с файлами, созданными предыдущей версией системы; • тестирование удобства установки - проверка удобства установки; • тестирование надежности - проверка надежности с использованием соответствующих математических моделей [63]; • тестирование восстановления - проверка восстановления программного обеспечения, например системы, включающей базу данных, после сбоев оборудования и программы; • тестирование удобства обслуживания - проверка средств обслуживания, включенных в программное обеспечение; • тестирование документации - тщательная проверка документации, например, если документация содержит примеры, то их все необходимо попробовать; • тестирование процедуры - проверка ручных процессов, предполагаемых в системе. 2.Схема сертификации является определяющей частью процедуры сертификации, характеризующей необходимый уровень доказательности соответствия продукции установленным требованиям. Схема сертификации может содержать одно или несколько предпринимаемых действий (модулей), результаты которых используют для принятия органом по сертификации общего решения о соответствии (несоответствии) продукции установленным требованиям. Такими действиями в общем случае могут считаться: - анализ представленной документации; - исследования, испытания продукции; - оценка производства (системы качества); - инспекционный контроль. Билет №3,30 Задание 1. Руководство пользователя — документ, назначение которого — предоставить людям помощь в использовании некоторой системы. Документ входит в состав технической документации на систему и, как правило, подготавливается техническим писателем. Большинство руководств пользователя помимо текстовых описаний содержат изображения. В случае программного обеспечения, в руководство обычно включаются снимки экрана, при описании аппаратуры — простые и понятные рисунки. Используется стиль и язык, доступный предполагаемой аудитории, использование жаргона сокращается до минимума либо подробно объясняется. Типичное руководство по эксплуатации содержит: · Аннотацию, в которой приводится краткое изложение содержимого документа и его назначение · Введение, содержащее ссылки на связанные документы и информацию о том, как лучше всего использовать данное руководство · Страницу содержания · Главы, описывающие, как использовать, по крайней мере, наиболее важные функции системы · Глава, описывающая возможные проблемы и пути их решения · Часто задаваемые вопросы и ответы на них · Где ещё найти информацию по предмету, контактная информация · Глоссарий и, в больших документах, предметный указатель Все главы и пункты, а также рисунки и таблицы, как правило, нумеруются, с тем, чтобы на них можно было сослаться внутри документа или из другого документа. Нумерация также облегчает ссылки на части руководства, например, при общении пользователя со службой поддержки Задание 2. В стандартах и моделях жизненного цикла ПС с различной глубиной определено содержание этапов и частных работ при создании и модификации компонентов и ПС в целом. Для планирования и управления обеспечением качества и надежности ПС эти модели служат структурной базой объектов, работ и документов при детализации и реализации требований к показателям качества ожидаемых результатов. Необходимая надежность объектов формируется и обеспечивается в процессе выполнения частных работ каждого этапа и окончательно удостоверяется испытаниями и документами при их завершении. Для обеспечения качества и надежности ПС стандартами рекомендуется формулировать требования: – к объекту разработки на данном этапе – к его программным и информационным компонентам, а также к интерфейсу между ними и внешней средой; – к процессу, технологии и организации выполнения совокупности работ и документов каждого этапа; – к методам и характеристикам средств автоматизации выполнения работ, обеспечивающим необходимую надежность функционирования и качество ПС; – к методам и средствам контроля, измерения и документирования качества процессов и результатов выполненных работ. Билет№4,25. Задание 1. Качество программного обеспечения — способность программного продукта при заданных условиях удовлетворять установленным или предполагаемым потребностям (ISO/IEC 25000:2014). Стандарт ISO/IEC 25010:2011 (ГОСТ Р ИСО/МЭК 25010-2015)]определяет модель качества продукта, которая включает восемь характеристик верхнего уровня: · функциональная пригодность; · уровень производительности; · совместимость; · удобство использования (юзабилити); · надёжность; · защищённость; · сопровождаемость; · переносимость (мобильность). В этом стандарте модель качества продукта (англ. software product quality model) рассматривается отдельно от субъективного качества в использовании, которое может сильно отличаться для различных стейкхолдеров. Модель качества в использовании (англ. quality in use model) включает следующие характеристики верхнего уровня[8]: · результативность; · производительность; · удовлетворённость; · свобода от риска; Задание 2. Тестирование методом белого ящика. Проверка белого ящика-подробное исследование внутренней логики и структуры кода. Тестирование с использованием белого ящика также называется тестированием стекла или открытым тестированием. Чтобы выполнить тестирование белого ящика в приложении, тестер должен знать внутреннюю работу кода. Тестер должен заглянуть внутрь исходного кода и выяснить какое устройство/блок кода ведет себя некорректно. + Белого ящика: Поскольку тестер знает исходный код, становится очень легко узнать какоцй тип данных может помочь в эффективном тестировании приложения Это помогает в оптимизации кода Дополнительные строки кода могут быть удалены, что может привести дефектам Благодаря знаниям тестера о коде максимальный охват достигается при написании сценария - Белого ящика: 1. В связи с тем, что для тестирования белых ящиков требуется квалифицированный тестер, затраты увеличены 2. Иногда невозможно заглянуть в каждый уголок и угол, чтобы обнаружить скрытые ошибки, которые могут создавать проблемы, т.к многие пути будут не проверены Билет№5,27 Задание 1. Сбои аппаратуры. В большинстве случаев они обрабатываются самой аппаратурой, либо за счет резервирования, либо с помощью встроенных систем функционального контроля. Некоторые сбои, однако, нельзя обработать только аппаратными средствами, они требуют помощи со стороны программного обеспечения. Возможности, которые часто бывают необходимы в программных системах для борьбы со сбоями аппаратуры: 1. Повторное выполнение операций. 2. Восстановление памяти. 3. Динамическое изменение конфигурации. 4. Восстановление файлов.. 5. Контрольная точка/рестарт. 6. Предупреждение отказов питания +7. Регистрация ошибок. Задание 2. Модели надежности программных средств (МНПС) подразделяются на аналитические и эмпирические. Аналитические модели дают возможность рассчитать количественные показатели надежности, основываясь на данных о поведении программы в процессе тестирования (измеряющие и оценивающие модели). Эмпирические модели базируются на анализе структурных особенностей программ. Они рассматривают зависимость показателей надежности от числа межмодульных связей, количества циклов в модулях, отношения количества прямолинейных участков программы к количеству точек ветвления и т.д. Часто эмпирические модели не дают конечных результатов показателей надежности, однако они включены в классификационную схему, так как развитие этих моделей позволяет выявлять взаимосвязь между сложностью ПС и его надежностью. Эти модели можно использовать на этапе проектирования ПС, когда осуществлена разбивка на модули и известна его структура. БИЛЕТ № 6,24 Задание 1 Единая система программной документации (ЕСПД) — комплекс государственных стандартов Российской Федерации, устанавливающих взаимосвязанные правила разработки, оформления и обращения программ и программной документации. В стандартах ЕСПД устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ. Система сертификации ГОСТР – это единственная в России государственная система сертификации для обязательной оценки соответствия. Система сертификации – это понятие, которое охватывает отработанные методы и процедуры проведения сертификационной экспертизы и группу организаций, которые осуществляют свою деятельность при помощи этих методов и процедур. Задание 2 1. Синтаксические ошибки. 2. Ошибки в структуре программы. 3. Ошибки, возникающие во время выполнения программы. 4. Логические ошибки или ошибки алгоритма. Предупреждение ошибок - К этой группе относятся принципы и методы, цель которых – не допустить появления ошибок в готовой программе. Должно быть очевидно, что предупреждение ошибок – оптимальный путь к достижению надежности программного обеспечения. Лучший способ обеспечить надежность – прежде всего не допустить возникновения ошибок. Если в программе возможно появление нескольких ошибок, их можно обработать, предварительно определив их код и в зависимости от кода применить тот или иной метод. Билет 8,29 Задание 1 Цель тестирования - проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы Тестирование - это одна из техник контроля качества, включающая в себя активности по планированию работ, проектированию тестов, выполнению тестирования и анализу полученных результатов. Качество - это совокупность характеристик программного обеспечения, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Виды тестирования: Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях. Инсталляционное тестирование (Installation testing). В процессе такого тестирования проверяется корректность установки и деинсталляции программного продукта в среде максимально приближенной к эксплутационной. Проверка правильности установки программного продукта должна быть обязательным элементом проекта по тестированию любого продукта. Дымовое тестирование (проверка на дым, Smoke testing). Первый прогон программы (после написания или после внесения существенных изменений). Как правило, используется для определения, готова ли программа для проведения более обширного тестирования. Основная цель такого тестирования - выявление проблем «лежащих на поверхности» – тестируется чаще всего основная бизнес логика программы. Функциональное тестирование (Functional testing). Под данным типом тестирования подразумевается проверка соответствия продукта функциональным требованиям и спецификациям. Регрессионное тестирование (Regression testing). Повторное тестирование после внесения изменений в программное обеспечение или в его окружение (в новой версии приложения), которое используется длятого чтобы убедиться в том, что функции, которые работали в предыдущей версии системы, по-прежнему работоспособны, а найденные дефекты успешно. Целью регрессионного тестирования является выявление проблем, которые могли возникнуть в результате изменений и проверка исправления найденных ранее дефектов. Интеграционное тестирование (Integration testing). Проверка скомбинированных компонентов прикладной программы с целью определения корректности их совместного функционирования Конфигурационное тестирование (Configuration testing). Конфигурационное тестирование – тестирование работы на различных платформах. Различные варианты аппаратной конфигурации, версии операционной системы и окружения. Место тестирования в процессе разработки программного обеспечения: При разработке по место для тестирования находится сразу после кодирования и выполнения какого-либо проекта. Инструментарий специалиста по тестированию: Необходимые компиляторы и ассемблеры; редакторы текстов; компоновщики или редакторы связей (linkers). Часто используемые утилиты автоматической сборки проекта; отладчики; программы создания файлов помощи (документации). программы создания инсталляторов. Специализированные дизассемблеры; Декомпиляторы. Интегрированные среды разработки Интегрированные среды разработки содержат большую часть из приведенных выше программ и позволяют упростить процесс создания приложений. Задание 2 Документирование и стандартизация Программная и эксплуатационная документация может использоваться для изготовления и сопровождения программного изделия, для его тестирования (испытания), для его эксплуатации. Документирование должно начинаться одновременно с разработкой продукта или даже раньше. В процессе разработки создаются следующие основные программные документы: Текст программ — запись программы с необходимыми комментариями. Описание программы — сведения о логической структуре и функционировании программы. Программа и методика испытаний — требования, подлежащие проверке при испытании программы, а также порядок и методы их контроля. Пояснительная записка — схема алгоритма, общее описание алгоритма и/или функционирование программы, а также обоснование принятых технических и экономических решений. Эксплуатационные документы: Руководство пользователя — сведения о назначении программы, области применения, применяемых методах, ограничениях при применении, конфигурации технических средств; сведения для обеспечения процедуры общения пользователя с вычислительной системой в процессе выполнения программы. Создается на основе документов «Описание применения» и «Руководство оператора», описанных в ЕСПД. Руководство системного администратора — сведения для обеспечения установки, функционирования и настройки программ на условиях конкретного применения. Создается на основе документа «Руководство системного программиста», описанного в ЕСПД. Единая система программной документации(билет 6). В стандартах ЕСПД устанавливают требования, регламентирующие разработку, сопровождение, изготовление и эксплуатацию программ, что обеспечивает возможность: унификации программных изделий для взаимного обмена программами и применения ранее разработанных программ в новых проектах; снижения трудоемкости и повышения эффективности разработки, сопровождения, изготовления и эксплуатации программных изделий; автоматизации изготовления и хранения программной документации. Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Основная и большая часть комплекса ЕСПД была разработана в 70-е и 80-е гг. Сейчас этот комплекс представляет собой систему межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации. Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. Следует отметить, что стандарты ЕСПД (ГОСТ 19) носят рекомендательный характер. Говоря о состоянии ЕСПД в целом, можно констатировать, что большая часть стандартов ЕСПД морально устарела. Наряду с ЕСПД на межгосударственном уровне действуют еще два стандарта, также относящихся к документированию ПС и принятых не так давно, как большая часть ГОСТ ЕСПД. БИЛЕТ 10,16 Задание 1 Стандартизация – это деятельность, направленная на разработку и установление требований, норм, правил, характеристик как обязательных для выполнения, так и рекомендуемых, обеспечивающая право потребителя на приобретение товаров и надлежащего качества за приемлемую цену, а также право на безопасность и комфортность труда. Цель стандартизации - достижение оптимальной степени упорядочения в той или иной области посредством широкого и многократного использования установленных положений, требований, норм для решения реально существующих, планируемых или потенциальных задач. |