Структурное кодирование, критерии качества программных средств

Общая характеристика и основные структуры кодирования. Качество программного обеспечения, показатели в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126, характеристика по функциональным возможностям. Основные критерии и процесс оценки качества программного обеспечения.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 25.02.2012
Размер файла 219,5 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Челябинский Юридический Колледж

Отделение права и ИТ

Кафедра «Информатики и ВТ»

КУРСОВАЯ РАБОТА

По дисциплине: «Технология разработки программных продуктов»

По теме: Структурное кодирование, критерии качества ПС

Челябинск

2011

Введение

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

Идеи структурного программирования появились в начале 70-годов в компании IBM, в их разработке участвовали известные ученые Э. Дейкстра, Х. Милс, Э. Кнут, С. Хоор.

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

Целью курсовой работы является: изучение структурного кодирования и выделение критериев качества ПС.

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

Изучение теоретических основ структурного кодирования,

Изучение и анализ методов структурирования программ и программных модулей,

Рассмотрение основных структурных блоков;

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

Рассмотрение факторов качества;

Рассмотрение процесса оценки качества ПС.

При написании работы автор опирался на труды отечественных и зарубежных ученых Ахо А., Ульман Дж., Братчиков И.Л., Гулидов А.И., Наберухин Ю.И., Дейкстра Э., Ершов А.П., Кнут Д., Майерс Г., Мендельсон Э., Рудаков А. В., Тыугу, Э.Х., Хьюз Дж., Мичтом Дж.

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

1. Структурное кодирование

1.1 Сущность понятия

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

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

1.2 Общая характеристика структурного кодирования

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

В качестве методики структурного программирования Э. Дейкстра предложил пользоваться лишь конструкциями цикла и условного оператора, изгоняя go to как концептуально противоречащее этому стилю.

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

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

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

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

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

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

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

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

К структурным операторам добавляются либо циклы, либо рекурсии.

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

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

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

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

Первым обратил внимание на необходимость введения призраков для логического и концептуального анализа программ Г.С. Цейтин в 1971 г. В Америке это "независимо" открыли заново в 1979 г., хотя упомянутая статья Цейтина была опубликована на английском языке в общедоступном издании. Даже название сущностям было дано то же самое... Этому важнейшему и традиционно игнорируемому понятию посвящена отдельная лекция в курсе "Основания программирования".

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

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

Для структурного программирования весьма важно требование:

Все структуры подчиняются структуре информационного пространства.

Это общее требование конкретизируется в следующие.

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

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

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

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

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

Все подпорки строго локализованы в том месте, где их вынуждены ввести. Желательно даже обозначать их по-другому, чем идеальные сущности, например, оставляя мнемонические имена лишь для идеальных сущностей, а подпорки именовать джокерами типа x или i. Необходимо строго следить за тем, чтобы подпорки не искажали идеальную структуру программы.

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

1.3 Основные структуры

Структурное программирование - методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70-х годах XX века Э. Дейкстрой, разработана и дополнена Н. Виртом.

В соответствии с данной методологией

Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:

последовательное исполнение - однократное выполнение операций в том порядке, в котором они записаны в тексте программы;

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

цикл - многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).

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

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

Разработка программы ведётся пошагово, методом «сверху вниз».

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

В развитии процедурного программирования большую роль сыграли принципы структурного программирования, которым мы должны следовать при написании процедур VB5. Будем рассматривать программу как некоего исполнителя, решающего определенную задачу. Когда программа уже написана, наша исходная задача оказывается разбитой на множество подзадач, каждая из которых решается элементарным (базовым) исполнителем-инструкцией. Отсюда возникает следующий подход, называемый методикой программирования сверху вниз: мы разбиваем задачу на подзадачи со своими промежуточными исполнителями (фрагментами кода с одним входом и одним выходом, обобщенно называемыми "процедурами"); после этого с каждой подзадачей делаем то же самое и так до тех пор, пока не достигнем уровня базовых исполнителей (инструкций). Теоретической основой такой методики является возможность представления любого алгоритма структурной блок-схемой.

На рисунке 1.1 изображена сеть с тремя типами узлов.

Рисунок 1.1 - Сеть с тремя типами узлов

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

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

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

Рисунок 1.2 - Элементарные блок-схемы

Композиция (а): <Процедура 1>

<Процедура 2>

Ветвление (б): если <условие>

<Процедура 1>

иначе

<Процедура 2>

Цикл I (в):пока <условие> делать

<Процедура>

Цикл II (г): делать

<Процедура>

пока <условие>

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

<Процедура 2> пуста: если <условие> <Процедура>

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

2. Критерии качества ПС

2.1 Качество программного обеспечения

Качество программного обеспечения - характеристика программного обеспечения (ПО) как степени его соответствия требованиям. При этом требования могут трактоваться довольно широко, что порождает целый ряд независимых определений понятия. Чаще всего используется определение ISO 9001, согласно которому качество есть «степень соответствия присущих характеристик требованиям».

Качество кода может определяться различными критериями. Некоторые из них имеют значение только с точки зрения человека. Например, то, как отформатирован текст программы, совершенно не важно для компьютера, но может иметь серьёзное значение для последующего сопровождения. Многие из имеющихся стандартов оформления кода, определяющих специфичные для используемого языка соглашения и задающие ряд правил, улучшающих читаемость кода, имеют своей целью облегчить будущее сопровождение ПО, включающее отладку и обновление. Существуют и другие критерии, определяющие, «хорошо» ли написан код, например, такие, как структурированность - степень логического разбиения кода на ряд управляемых блоков.

Читаемость кода

Лёгкость поддержки, тестирования, отладки, исправления ошибок, изменения и портируемости

Низкая сложность кода

Низкое использование ресурсов: памяти и процессорного времени

Корректная обработка исключительных ситуаций

Малое число предупреждений при компиляции и линковке

Методы улучшения качества кода: рефакторинг.

2.2 Факторы качества

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

Некоторые из факторов качества - таблица 2.1.

Таблица 2.1 - Факторы качества ПС

Фактор

Характеристика

Понятность

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

Полнота

Все необходимые части программы должны быть представлены и полностью реализованы.

Краткость

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

Портируемость

Лёгкость в адаптации программы к другому окружению: другой архитектуре, платформе, операционной системе или её версии.

Согласованность

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

Сопровождаемость

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

Тестируемость

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

Удобство использования

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

Надёжность

Отсутствие отказов и сбоев в работе программ, а также простота исправления дефектов и ошибок

Эффективность

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

2.3 Показатели качества ПО в ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126

Показатели качества ПО устанавливают ГОСТ 28195 Оценка качества программных средств. Общие положения и ГОСТ Р ИСО/МЭК 9126 Информационная технология. Оценка программной продукции. Характеристика качества и руководства по их применению. Одновременное существование двух действующих стандартов, нормирующих одни и те же показатели, ставит вопрос об их гармонизации. Ниже кратко рассмотрим каждый из перечисленных стандартов.

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

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

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

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

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

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

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

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

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

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

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

Сопровождаемость - набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций).

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

Все приведенные характеристики являются наборами атрибутов и, следовательно, должны уточняться на множестве соответствующих подхарактеристик. ГОСТ Р ИСО/МЭК 9126 не устанавливает соответствующих показателей, но в рекомендуемом приложении А к этому стандарту дается пример (качественная модель) таких подхарактеристик, называемых комплексными показателями. В качестве примера приведем комплексные показатели для некоторых характеристик.

2.4 Комплексные показатели для характеристик

Характеристика «Функциональные возможности»:

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

2. Правильность - атрибуты ПО, относящиеся к обеспечению правильности или соответствия результатов или эффектов.

3. Способность к взаимодействию - атрибуты ПО, относящиеся к способности его взаимодействовать с конкретными системами.

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

5. Защищенность - атрибуты ПО, относящиеся к его способности предотвращать несанкционированный доступ, случайный или преднамеренный, к программам и данным.

Характеристика «Эффективность»:

1. Характер изменения во времени - атрибуты ПО, относящиеся к временам отклика и обработки и к скорости выполнения его функций.

2. Характер изменения ресурсов - атрибуты ПО, относящиеся к объему используемых ресурсов и продолжительности такого использования при выполнении функций.

Приведенные комплексные показатели в свою очередь формируются на основе показателей нижележащего уровня. ГОСТ Р ИСО/МЭК 9126 не устанавливает этих показателей, так как современное состояние соответствующих моделей, терминов, определений не позволяет включить их в рассматриваемый международный стандарт.

В СССР действовал и продолжает действовать в РФ ГОСТ 28195-89. Этот стандарт устанавливает четырехуровневую модель оценки качества ПС. Характеристики верхних двух уровней (называемые фактор и критерий) устанавливаются в основном тексте документа. В таблице 2.1. показаны факторы и критерии качества ПО согласно ГОСТ 28195.

Таблица 2.2 - Факторы и критерии качества ПО согласно ГОСТ 28195

Наименование факторов и критериев качества ПО и их обозначение

Характеризуемое свойство

1. Надежность ПО (Н)

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

1.1. Устойчивость функционирования (Н1)

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

1.2. Работоспособность (Н2)

Способность ПО функционировать в заданных режимах и объемах обрабатываемой информации в соответствии с программными документами при отсутствии сбоев технических средств.

2. Сопровождаемость (С)

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

2.1. Структурность (С1)

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

2.2. Простота конструкции (С2)

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

2.3. Наглядность (С3)

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

2.4. Повторяемость (С4)

Степень использования типовых проектных решений или компонентов, входящих в ПО.

3. Удобство применения (У)

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

3.1. Легкость освоения (У1)

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

3.2. Доступность эксплуатационных программных документов (У2)

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

3.3. Удобство эксплуатации и обслуживания (У3)

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

4. Эффективность (Э)

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

4.1. Уровень автоматизации (Э1)

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

4.2. Временная эффективность (Э2)

Способность ПО выполнять заданные действия в интервал времени, отвечающий заданным требованиям.

4.3. Ресурсоемкость (Э3)

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

5. Универсальность (Г)

5.1. Гибкость (Г1)

Возможность использования ПО в различных областях применения.

5.2. Мобильность (Г2)

Возможность применения ПО без существенных дополнительных трудозатрат на ЭВМ аналогичного класса.

5.3. Модифицируемость (Г3)

6. Корректность (К)

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

6.1. Полнота реализации (К1)

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

6.2. Согласованность (К2)

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

6.3. Логическая корректность (К3)

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

6.4. Проверенность (К4)

Полнота проверки возможных маршрутов выполнения программы в процессе тестирования.

2.5 Основные критерии

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

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

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

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

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

Программа является защищенной, если она сохраняет работоспособность при возникновении сбоев (режим реального времени, программа большого времени выполнения).

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

Программа является эффективной, если объем требуемых для ее работы ресурсов ЭВМ не превышает допустимого предела.

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

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

2.6 Процесс оценки качества

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

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

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

Критерий и метрика характеризуется двумя числовыми параметрами - количественным значением и весовыми коэффициентами (Vij). Сумма весовых коэффициентов показателей уровня (l) относящихся к i-му показателю вышестоящего уровня (l-1), есть величина постоянная. Сумма весовых коэффициентов (Vij) принимается равной 1.

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

При сопоставление характеристик стандартов ГОСТ Р ИСО/МЭК 9126 и ГОСТ 28195 следует учесть несоответствие используемой терминологии. Например, подхарактеристика 1.4 ГОСТ Р ИСО/МЭК 9126 называется также, как критерий 6.2 ГОСТ 28195 - согласованность. Однако в первом документе имеется в виду согласованность ПО со стандартами и другими нормативными документами, а во втором - однозначное, непротиворечивое описание и использование тождественных объектов, функций, терминов, определений, идентификаторов и т.д. в различных частях программных документов и текста программы. Точное сопоставление характеристик и подхарактеристик первого из обсуждаемых стандартов с факторами и критериями второго оказывается, как правило, невозможным.

Таким образом, на сегодняшний день действуют два нормативных документа по оценке качества ПО - ГОСТ 28195 и ГОСТ Р ИСО/МЭК 9126. Первый содержит рекомендуемый (и возможно - неполный) перечень метрик, однако ориентирован на представление разработчика. Второй - более соответствует взглядам пользователя, но для его применения требуется разработка модели качества ПС, включающая метрики и методы оценивания и ранжирования с указанием применимости на стадиях ЖЦ продукта.

Заключение

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

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

Достоинства структурного кодирования:

- повышается надежность программ (благодаря хорошему структурированию при проектировании, программа легко поддается тестированию и не создает проблем при отладке);

- повышается эффективность программ (структурирование программы позволяет легко находить и корректировать ошибки, а отдельные подпрограммы можно переделывать (модифицировать) независимо от других);

- уменьшается время и стоимость программной разработки;

- улучшается читабельность программ.

Также при выполнении курсовой работы были рассмотрены критерии качества ПС.

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

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

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

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

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

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

Список литературы

1. Ахо А., Ульман Дж. «Теория синтаксического анализа, перевода и компиляции» в 2 тт., том 1., М., Мир, 1978.

2. Гринфилд Д., Шорт К., Кук С. Фабрики разработки программ (Software Factories): потоковая сборка типовых приложений, моделирование, структуры и инструменты. - М.: «Диалектика», 2006. - С. 592.

3. Дейкстра Э. Заметки по структурному программированию.- М.:Дрофа, 2006, - 455 с.

4. Ершов А.П. Введение в теоретическое программирование.- М.:РОСТО, 2008, - 288 с.

5. Захарова И.Г. Информационные технологии в образовании: Учеб. пособие для студ. высш. пед. учеб. заведений. - М.: Издательский центр «Академия», 2003. - 192 с.

6. Кнут Д. Искусство программирования для ЭВМ, т.1. М.: 2006, 735 с.

7. Коган Д.И., Бабкина Т.С. «Основы теории конечных автоматов и регулярных языков. Учебное пособие» Издательство ННГУ, 2002. - 97 с.

8. Майерс Г. Надежность программного обеспечения.- М.: Дрофа, 2008, - 360 с.

9. Мендельсон Э. Введение в математическую логику, М.: Инси, 2001, - 320 с.

10. Рудаков А. В. Технология разработки программных продуктов. М.: Издательский центр "Академия", 2006. - 306 с.

11. Свешникова Е.Ю. Анализ режимов детерминированного хаоса в переходных процессах электроэнергетических систем. М.: Издательство «Агат», 2008. - 181 с.

12. Соммервилл И. Инженерия программного обеспечения.- 6-е изд. - М.: «Вильямс», 2002. - С. 642.

13. Тыугу, Э.Х. Концептуальное программирование. - М., 2001 - 256 с.

14. Хопкрофт Дж., Мотвани Р., Ульман Дж. «Введение в теорию автоматов, языков и вычислений» - М.: Издательство ВИЛЬЯМС, 2002. - 527 с.

15. Хьюз Дж., Мичтом Дж. Структурный подход к программированию. - М.: Мир, 2000, - 278 с.

Размещено на Allbest.ru


Подобные документы

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

    реферат [26,7 K], добавлен 10.10.2014

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

    лекция [370,1 K], добавлен 22.03.2014

  • Основные международные стандарты в области информационных технологий. Международный стандарт ISO/IEC 9126. Качество и жизненный цикл. Характеристика внутренних и внешних атрибутов качества. Анализ функциональных возможностей программного обеспечения.

    доклад [94,4 K], добавлен 13.06.2017

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

    презентация [114,7 K], добавлен 14.08.2013

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

    контрольная работа [606,0 K], добавлен 28.10.2010

  • Развитие аппаратных компьютерных средств - задача первых трех десятилетий компьютерной эры. Процесс тестирования как составляющая процесса обеспечения качества разработки ПО. Принципы и критерии, предъявляемые к тестированию программного обеспечения.

    курсовая работа [319,5 K], добавлен 25.05.2009

  • Информатизация России. Рынок программных средств. Основные задачи стандартизации, сертификации и лицензирования в сфере информатизации. Совокупность инженерных методов и средств создания программного обеспечения. Жизненный цикл программного обеспечения.

    лекция [352,8 K], добавлен 09.03.2009

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

    дипломная работа [656,8 K], добавлен 27.11.2012

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

    презентация [151,1 K], добавлен 22.03.2014

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

    курсовая работа [974,0 K], добавлен 21.12.2016

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.