Конспект лекций по предмету «ПМ.01 РАЗРАБОТКА МОДУЛЕЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ КОМПЬЮТЕРНЫХ СИСТЕМ». Конспект лекций по предмету_ «ПМ.01 РАЗРАБОТКА МОДУЛЕЙ ПРОГРАММН. Конспект лекций по предмету ПМ. 01 Разработка модулей программного обеспечения для компьютерных систем

• Название: Конспект лекций по предмету ПМ. 01 Разработка модулей программного обеспечения для компьютерных систем
• Анкор: Конспект лекций по предмету «ПМ.01 РАЗРАБОТКА МОДУЛЕЙ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ КОМПЬЮТЕРНЫХ СИСТЕМ
• Дата: 02.09.2021
• Размер: 363 Kb.
• Имя файла: Конспект лекций по предмету_ «ПМ.01 РАЗРАБОТКА МОДУЛЕЙ ПРОГРАММН.doc
• Тип: Конспект; #228994
• страница: 3 из 3

Обеспечение качества программного средства

Общая характеристика процесса обеспечения качества программного средства.

Спецификация качества определяет основные ориентиры, которые на всех этапах разработки ПС так или иначе влияют при принятии различных решений на выбор подходящего варианта.

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

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

Обеспечение легкости применения программного средства.

П-документированость ПС определяет состав пользовательской документации

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

Обеспечение эффективности программного средства.

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

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

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

Обеспечение сопровождаемости.

С-документированность, информативность и понятность определяют состав и качество документации по сопровождению. Кроме того, относительно текстов программ (модулей) можно сделать следующие рекомендации.

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

Расширяемость обеспечивается созданием подходящего инсталлятора.

Структурированность и модульность упрощают как понимание текстов программ, так и их модификацию.

Аттестация программного средства

Назначение аттестации программного средства.

Аттестация ПС - это авторитетное подтверждение качества ПС. Обычно для аттестации ПС создается аттестационная комиссия из экспертов, представителей заказчика и представителей разработчика. Эта комиссия проводит испытания ПС с целью получения необходимой информации для оценки его качества. Под испытанием ПС мы будем понимать процесс проведения комплекса мероприятий, исследующих пригодность ПС для успешной его эксплуатации (применения и сопровождения) в соответствии с требованиями заказчика. Этот комплекс включает проверку полноты и точности программной документации, изучение и обсуждение других ее свойств, а также необходимое тестирование программ, входящих в состав ПС, и, в частности, соответствия этих программ имеющейся документации.

На основе информации, полученной во время испытаний ПС, прежде всего должно быть установлено, что ПС выполняет декларированные функции, а также должно быть установлено, в какой степени ПС обладает декларированными примитивами и критериями качества. Таким образом, оценка качества ПС является основным содержанием процесса аттестации. Произведенная оценка качества ПС фиксируется в соответствующем решении аттестационной комиссии.

Виды испытаний программного средства.

Известны следующие виды испытаний ПС, проводимых с целью аттестации ПС:

• 
  испытания компонент ПС;
  
• 
  системные испытания;
  
• 
  приемо-сдаточные испытания;
  
• 
  полевые испытания;
  
• 
  промышленные испытания.
  

Испытания компонент ПС - это проверка (тестирование) работоспособности отдельных подсистем ПС. Проводятся только в исключительных случаях по специальному решению аттестационной комиссии.

Системные испытания ПС - это проверка (тестирование) работоспособности ПС в целом. Может включать те же виды тестирования, что и при комплексной отладке ПС (см. лекцию 10). Проводится по решению аттестационной комиссии, если возникают сомнения в качестве проведения отладки разработчиками ПС.

Приемо-сдаточные испытания являются основным видом испытаний при аттестации ПС. Именно с этих испытаний начинает работу аттестационная комиссия. Эти испытания начинаются с изучения представленной документации, в том числе, и документации по тестированию и отладке ПС. Если в документации отсутствуют достаточно полные результаты тестирования ПС, аттестационная комиссия может принять решение о проведении системных испытаний ПС или о прекращении процесса аттестации с рекомендацией разработчику провести дополнительное (более полное) тестирование ПС. Кроме того, во время этих испытаний могут выборочно пропускаться тесты разработчиков, а также контрольные задачи пользователей и дополнительные тесты, подготовленные комиссией для оценки качества аттестуемого ПС.

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

Промышленные испытания ПС - это процесс передачи ПС в постоянную эксплуатацию пользователям. Представляет собой период опытной эксплуатации ПС пользователями со сбором информации об особенностях поведения ПС и ее эксплуатационных характеристиках. Это завершающие испытания ПС, которые проводятся по решению аттестационной комиссии, если на предшествующих испытаниях получена недостаточно полная или надежная информация для оценки качества аттестуемого ПС.

Методы оценки качества программного средства.

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

• 
  непосредственное измерение показателей примитива качества;
  
• 
  обработка программ и документации ПС специальными программными инструментами (процессорами);
  
• 
  тестирование программ ПС;
  
• 
  экспертная оценка на основании изучения программ и документации ПС.
  

Непосредственное измерение показателей примитива качества производится путем подсчета числа вхождений в тот или иной программный документ характерных единиц, объектов, конструкций и т.п., а также путем измерения времени работы различных устройств и объема занятой памяти ЭВМ при выполнении контрольных примеров. Например, некоторым показателем эффективности по памяти может быть число строк программы на языке программирования, а некоторым показателем эффективности по времени может быть время ответа на запрос. Использование каких-либо показателей для примитивов качества может определяться в спецификации качества ПС. Метод непосредственного измерения показателей примитива качества может сочетаться с использованием тестирования программ.

Для установления наличия у ПС некоторых примитивов качества могут использоваться определенные программные инструментальные средства. Такие программные инструменты обрабатывают тексты программ или программной документации с целью контроля каких-либо примитивов качества или получения некоторых показателей этих примитивов качества. Для оценки структурированности программ ПС, если они программировались на подходящем структурном диалекте базового языка программирования, достаточно было бы их пропустить через конвертер структурированных программ, осуществляющий синтаксический и некоторый семантический контроль этого диалекта и переводящий тексты этих программ на входной язык базового транслятора. Однако таким путем в настоящее время удается контролировать лишь небольшое число примитивов качества, да и то в редких случаях. В ряде случаев вместо программных инструментов, контролирующих качество ПС, полезнее применять инструменты, осуществляющие преобразование представления программ или программной документации. Таким, например, является форматер программ, приводящий тексты программ к удобочитаемому виду, - обработка текстов программ ПС таким инструментом может автоматически обеспечить наличие соответствующего примитива качества у ПС.

Для оценки некоторых примитивов качества ПС используется тестирование. К таким примитивам относится прежде всего завершенность ПС, а также его точность, устойчивость, защищенность и другие примитивы качества. В ряде случаев для оценки отдельных примитивов качества ПС тестирование применяется в сочетании с другими методами. Так для оценки качества документации по применению ПС тестирование применяется в сочетании с экспертной оценкой этой документации. Если при комплексной отладке ПС было проведено достаточно полное тестирование, то эти же тесты могут быть использованы и при аттестации ПС. В этом случае аттестационная комиссия может воспользоваться протоколами тестирования, проведенного при комплексной отладки. Однако и в этом случае необходимо выполнить какие-либо новые тесты или хотя бы повторно некоторые старые. Если же тестирование при комплексной отладке будет признано недостаточно полным, то необходимо провести более полное тестирование. В этом случае может быть принято решение о проведении испытаний компонент или системных испытаний ПС, а также о возврате ПС разработчикам на доработку. Весьма важно, чтобы для оценки ПС по критерию легкости применения было проведено (во время отладки и аттестации ПС) полное тестирование по тестам, подготовленным на основании документации по применению, а по критерию сопровождаемости - по тестам, подготовленным по каждому из документов, предлагаемых для сопровождения ПС.

Для оценки большинства примитивов качества ПС в настоящее время можно применять только метод экспертных оценок. Этот метод заключается в следующем: назначается группа экспертов, каждый из этих экспертов в результате изучения представленной документации составляет свое мнение об обладании ПС требуемым примитивом качества, а затем голосованием членов этой группы устанавливается оценка требуемого примитива качества ПС. Эта оценка может производиться как по двухбалльной системе ("обладает" - "не обладает"), так и учитывать степень обладания ПС этим примитивом качества (например, производиться по пятибалльной системе). При этом группа экспертов должна руководствоваться конкретизацией этого примитива и указанием о способе его оценки, сформулированными в спецификации качества аттестуемого ПС.