7060

Качество программного продукта

Реферат

Информатика, кибернетика и программирование

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

Русский

2013-01-14

73 KB

111 чел.

Качество программного продукта

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

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

Критериями качества ПП являются:

  •  функциональность;
  •  надежность;
  •  легкость применения;
  •  эффективность;
  •  сопровождаемость;
  •  мобильность.

Функциональность – это способность ПП выполнять набор функций, определенных его внешними спецификациями.

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

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

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

Обращаю ваше внимание на то, что тестирование программ более объемно, чем мы с вами рассматривали. Тестирование включает три аспекта проверки программ: на правильность ( именно этому аспекту были посвящены лекции по тестированию); на вычислительную сложность и на эффективность реализации. Проверка вычислительной сложности заключается в экспериментальном анализе сложности программы или экспериментальном сравнении двух или нескольких алгоритмов, решающих одну и туже задачу. Этой проблемой, в основном, занимается вычислительная математика. Проверка эффективности реализации направлена на отыскание способа заставить правильную программу (правильную в смысле удовлетворения первому аспекту проверки) работать быстрее или расходовать меньше памяти. “Или” здесь свидетельствует о том, что показатели объема используемой памяти и времени выполнения противоречивы! Короткая программа иногда выполняется дольше более длинной программы! / /.

Предлагаю Вам самостоятельно найти самый быстрый вариант вычисления  корней квадратного уравнения и доказать это/4//

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

Мобильность – это способность ПП быть перенесенным из одной вычислительной среды (окружения) в другую, в частности, с одной ЭВМ на другую (применяют термин “перенос с одной платформы на другую”.

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

Принципы модульного программирования.

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

Что в теории понимается под модулем? Модуль – это замкнутая программа, которую можно вызвать из другого модуля и самостоятельно откомпилировать. Другое определение: программный модуль – это любой фрагмент описания процесса, оформляемый как самостоятельный программный продукт, пригодный для использования в описаниях процесса.

Модуль – это программа, обладающая тремя основными атрибутами:

  1.  он выполняет одну или несколько функций;
  2.  модуль реализует некоторую логику (алгоритм).
  3.  используется в одном или нескольких контекстах.

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

Например: модуль с функцией “удалить пробелы из литерной строки” может использоваться в контексте  “сжать сообщение для телеобработки”.

Или модуль, вычисляющий сумму:

может использоваться в контекстах “вычисление зарплаты всех сотрудников” или “определение пробега всех автомобилей”. В этом случае содержательный смысл слагаемых ai различный.

Основная причина по которой разрабатываемое ПО разбивается на модули – борьба со сложностью ПО.

Принципы модульного программирования позволяют получать программные комплексы минимальной сложности. Эти  принципы следующие:

а) усиление внутренних связей в каждом модуле (иначе принцип называется повышением прочности модуля);

б) ослабление взаимосвязи между модулями (иначе этот принцип называется ослаблением сцепления модулей).

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

Для качественной характеристики модулей введены 7 классов прочности модулей и 5 видов сцепления модулей. Класс прочности является мерой связи предложений внутри модуля. Сцепление модулей – это мера зависимости между модулями.

Классы прочности модулей

Назовем эти классы в порядке возрастания прочности. Вы должны понимать, что чем к большему по номеру классу относится конкретный программный модуль, тем он “доброкачественнее”.

Чтобы отнести модуль к тому или иному классу, нужно проанализировать выполняемую им функцию (или функции).

1. Прочность по совпадению.

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

Например модуль вычисления суммы  ,  может использоваться в разных контекстах, и в зависимости от контекста изменяется и смысл связей между предложениями модуля.

Основная проблема с модулями такого класса – это необходимость тщательной проверки, не теряется ли смысл обработки данных при каждом новом использовании модуля.

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

Пример: библиотека стандартных программ, реализующих численные методы.

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

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

Например: autoexec.bat.

Обычно это первые или последние модули в программных комплексах, на которые возлагаются операции инициализирования и завершения.

Для таких модулей основная проблема состоит в том, что они неявно связаны с другими модулями и при изменениях прочных по классу модулей часто возникают ошибки, когда эти связи не учитываются.

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

5. Коммуникационно-  прочный модуль.

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

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

6. Информационная прочность – модуль выполняет несколько функций над одной и той же строкой данных, но каждая функция представляется отдельным входом в модуль.

7. Функциональная прочность – это когда модуль выполняет одну функцию – это то, к чему следует стремиться при проектировании модульной структуры ПО. Информационно - прочные модули следует рассматривать как физическое соединение нескольких функционально – прочных модулей.   

Модуль может соответствовать описанию нескольких типов прочности. В этом случае принято его относить к высшему типу прочности, определению которой он удовлетворяет.

Сцепление модулей

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

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

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

1. Сцепление по содержимому – модуль ссылается на данные (содержимое) другого модуля. Большинство языков программирования высокого уровня делает такое сцепление практически невозможным.

2. Сцепление по общей области – модули ссылаются на одну и ту же глобальную структуру данных.

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

3. Сцепление по управлению – один модуль управляет функционированием другого. При этом в вызываемый модуль передается значение управляющей переменной.

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

4. Сцепление по формату – модули ссылаются на одну и ту же структуру данных. Если модуль А вызывает модуль В и передает ему запись анкетных данных служащего и при этом как А так и В чувствительны к изменению структуры или формата записи, то А и В сцеплены по формату.

Такого сцепления, по возможности, следует избегать, поскольку оно создает ненужные связи между модулями.

5. Сцепление по данным – передаваемые параметры – простые  (неструктурированные) данные.

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

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

В литературе /1/ предлагается для оценки приемлемости программного модуля использовать следующие характеристики:

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

Размер модуля измеряется числом содержащихся в нем программных операторов или команд. Рекомендуется создавать программные модули размером от нескольких десятков до нескольких сотен операторов.

Прочность и сцепление как основополагающие принципы модульного программирования пояснены выше.

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

Вывод: Подытожим обсуждение модульного программирования перечислением принципов Хольта:

1.Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры.

2.Хороший модуль снаружи проще, чем изнутри.

3.Хороший модуль проще использовать, чем построить.

Модульный стиль программирования

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

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

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

•  большой объем текста программы затрудняет ее понимание;

•  всякий раз после изменения программы ее необходимо перекомпилировать, затрачивая определенное время;

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

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

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

Модули в зависимости от способа подключения к главному модулю делятся на исходные и загрузочные. Загрузочные модули в свою очередь подразделяются на модули, полученные после этапа трансляции и компиляции исходного текста программы. Откомпилированные модули делятся на статические, которым выделяется в памяти сегмент данных, и динамические, которым память выделяется динамически лишь на этапе выполнения программы. Динамические модули еще называют динамически связывающими библиотеками (DLL - Dynamic Link Library).

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

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

Основной недостаток такого метода разработки модульной структуры программы следующий. Каждый разрабатываемый модуль подчиняется некоторым глобальным для него принципам функционирования и структурам информации, уточнение которых при восходящей разработке откладывается на более поздние этапы разработки. На первый взгляд кажется, что в этом нет ничего плохого: задача в процессе разработки уточняется. Однако на практике это приводит к частому перепрограммированию модулей нижнего уровня, когда на более высоких уровнях разработки модульной структуры программы производятся значительные изменения глобальных принципов или информации. Кроме этого, при восходящем тестировании, как уже говорилось ранее, приходится создавать вызывающую программу драйвер или отлаживающий модуль, что приводит к значительному объему отладочного материала, который, однако, не гарантирует отладку модуля именно в том режиме, в котором он будет использоваться в рабочей программе.

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

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

Процедурное и функциональное программирование

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

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

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

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

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

Var x,y,z,t: Real; {Процедурный стиль}

Begin

х:=5.5;  y:=Sin(x);  z:=Abs(y);  t:= Ln(z);  Writeln(t);

End.

         Begin   {Функциональный стиль)  Writeln(Ln(Abs(Sin(5.5)); End.

Основными недостатками процедурного и функционального программирования являются:

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

Рекомендуемая литература

1. Майерс Г. Надежность программного обеспечения. М.: Мир, 1980. – с.92-113.

2. Кабальнов Ю.С., Лебедев В.А., Осипова Г.В. Языки и технологии программирования.: Учебное пособие/ Уфимск. Гос. Авиац. Техн. ун-т. – Уфа, 2000. – С. 35-108.

3. Бежанова М.М., Ильин В.П. Некоторые вопросы технологии разработки ППП / в сборнике Пакеты прикладных программ. Функциональное наполнение. –М.: Наука 1986. (алгоритмы и алгоритмические языки).

4. Острейковский В.А. Информатика: Учеб. для вузов. – М.: Высш. Шк., 1999. – 511 с.

5.


 

А также другие работы, которые могут Вас заинтересовать

5411. Облік грошових коштів на рахунках у банку 29.77 KB
  Облік грошових коштів на рахунках у банку Порядок відкриття рахунків, вибір банку. Закриття рахунків клієнтів банків. Документальне оформлення банківських операцій. Синтетичний та аналітичний облік операцій на поточному рахун...
5412. Статические характеристики транзистора 684.5 KB
  Статические характеристики транзистора 1. Краткое содержание лекции Статическим называется режим, при котором в схеме отсутствуют источник сигнала и нагрузка, а присутствуют только источники питания. Входная характеристика - зависимость входн...
5413. Створення та редагування математичних та економічних формул у Word. Друк документів у WORD 44.51 KB
  Створення та редагування математичних та економічних формул у Word. Друк документів у WORD Мета: Ознайомлення із способами створення та редагування формул у Word. План лекції: MicrosoftEquation 3.0 - редактор формул. Вирівнюва...
5414. Загальна характеристика технічних засобів навчання 72.5 KB
  Загальна характеристика технічних засобів навчання. План. 1. Загальна характеристика технічних засобів статичної проекції. 2. Характеристика носіїв інформації статичної проекції. 3. Характеристика апаратури статичної проекції. 4. Методика використан...
5415. Культура на українських землях у найдавніші часи 219.5 KB
  Культура на українських землях у найдавніші часи План Культура первісного суспільства як історичний тип. Культурний розвиток первісного суспільства. Культура найдавніших державних утворень на українських землях. ...
5416. Нормативный аспект культуры речи 208 KB
  Нормативный аспект культуры речи Понятие о языковой норме Языковая норма (норма литературная) — это правила использования речевых средств в определенный период развития литературного языка, т. е. правила произношения, словоупотребления, и...
5417. Поняття, особливості, види, класифікація правовідносин 66.5 KB
  Поняття, особливості, види, класифікація План Поняття правовідносин по соціальному забезпеченню Особливості соціально забезпечувальних правовідносин Класифікація за видам забезпечення Правовідносини за терміном дії Прав...
5418. Системи когенерації енергії 904 KB
  Системи когенерації енергії Основні терміни і визначення Калорія - традиційна позасистемна одиниця вимірювання, що дорівнюєенергії, необхідній для нагрівання 1 г води на 1° С. 1 кал ...
5419. Державне управління та економіко-правовий механізм природокористування і охорона навколишнього природного середовища 177.5 KB
  Державне управління та економіко-правовий механізм природокористування і охорона навколишнього природного середовища План Поняття і зміст державного управління природокористуванням Принципи управління в галузі охорони навколишнього приро...