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

Качество – это совокупность свойств и характеристик объекта, относящихся к его способности удовлетворять установленные и предполагаемые потребности. Под качеством программного обеспечения понимается совокупность показателей, характеризующих устойчивость работы, свойство интерфейса, а также способность программы удовлетворить потребности пользователя в обработке информации. Показателем качества программного продукта является наличие сертификата. Сертификация – это действие третьей стороны, доказывающее, что обеспечивается необходимая уверенность в том, что продукция или предоставляемая услуга соответствует стандарту. В стандарте ИСО 9000-3-91[24] предусмотрены показатели качества программного продукта, такие как надежность работы, удобство сопровождения и применения, эффективность программного продукта.

Надежность программного обеспечения является очень важным и ответственным параметром программного обеспечения. История помнит множество случаев, когда ненадежность программного обеспечения приводила к крупным последствиям. Неудачный исход первого полета на Венеру американской автоматической станции, из-за ошибки в списке операторов цикла на Фортране, остановка на несколько дней конвейера ВАЗа в 80-ых годах (была проведена информационная диверсия работником ВЦ), неудачная посадка американского космического корабля на Марс из-за ошибки в программе управления кораблем являются яркими примерами этого.

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

Проблема надежности программного обеспечения всегда была объектом пристального внимания программистов. Программисты на опыте убедились, что исправление ошибок занимает много времени при программировании. Надежность программного обеспечения зависит первую очередь от отсутствия программных ошибок. Характерными случаями возникновения программных ошибок являются [49]:

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

2. Программа работает с ошибками, если эксплуатируется за приделами определенных границ. Проблема определения границ таблиц являются не простым. Как определить границы таблицы, как постараться избежать ее переполнения? Например, АСУ-ВУЗ работает без ошибок, если количество студентов не более 10000 (потому что разработчики ПО - ВУЗа предположили, что никогда в ВУЗе не будет больше 100000 студентов и при использовании данного программного продукта в ВУЗе с количеством студентов более 10000 у системы появляются проблемы).

3. Ошибка имеет место тогда, когда работа программы не соответствует сопутствующей ей документации. (Как быть, если и в документации и в программе есть ошибки?).

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

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

Имеется множество факторов, определяющих надежность ПО. В.В.Шураков [49] выделяет следующие основные факторы надежности (рис.16).

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

Под признаком «где» мы подразумеваем классификацию среды фиксации ошибки: персонал (структуры, процедуры и т.д.), оборудование (ПЭВМ, связь), программное обеспечение.

 

 

 

Рис. 16. Факторы, влияющие на надежность программного обеспечения.

 

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

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

Признак «когда» классифицируется по стадиям разработки программы (экспериментальной, опытно-промышленной и промышленной эксплуатации программного продукта).

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

Если рассмотреть этапы разработки программного обеспечения, то можно выделить следующие источники ошибок [49]:

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

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

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

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

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

Одним из обязательных условий для обеспечения качества является тестирование программного продукта на контрольном примере с целью обнаружения ошибок. Правильность алгоритма и работы программ оценивается совпадением итоговых данных контрольного примера и результатов вычислений на ЭВМ. Исходные данные могут быть реальными или искусственно созданными числами. Практика показывает, что контрольный пример должен быть неотъемлемой частью постановки задачи, одним из ее разделов. Контрольный пример содержит: набор всех входных данных и нормативно-справочных данных, контрольные значения, накопленной и хранимой для других задач информации, формы выходных документов с данными, рассчитанными в полном соответствии с алгоритмом. Г.Майерс дает следующие советы по тестированию программ [30]:

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

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

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

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

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

6. Тестирование - процесс творческий, и тестирования большой программы требуется большой творческий потенциал. Удачным считается тот тест, который обнаруживает еще не выявленной ошибки.

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

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

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

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

2. На выделение классов эквивалентности путем выбора каждого входного условия на два и более групп входных данных (например, удовлетворяющих условию и не удовлетворяющих условию).

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

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

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

Вопросы для самопроверки

1. Определите этапы жизненного цикла АИС и опишите их сущность.

2. Опишите виды основных работ проводимых в предпроектном этапе создания АИС.

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

4. Опишите методику проведения исследования информационных потоков.

5. Опишите состав и содержание ТЭО на создание АИС.

6. Опишите состав и содержание ТЗ на создание АИС.

7. Опишите состав с содержание ТП на создание АИС.

8. Опишите сущность методики постановки задач, решаемых на АИС.

9. Укажите способы описания алгоритмов и опишите их сущность.

10. Опишите способы повышения достоверности функционирования алгоритмов.

11. Укажите этапы технологии разработки алгоритмов задач АИС и опишите их сущность.

12. Опишите состав с содержание РП на создание АИС.

13. Опишите порядок подготовки предприятия к внедрению АИС.

14. Опишите порядок проведения опытной эксплуатации АИС.

15. Укажите факторы, влияющие на надежность программного обеспечения АИС.

16. Укажите характерные случаи возникновения ошибок в программном обеспечении АИС и пути их устранения.

Глава 4.