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

Общие факторы:

-процедура управления разработкой ПО;

-подготовка и повышение квалификации персонала;

- языки программирования.

Конструктивные факторы:

- размер, стоимость и сложность разрабатываемой системы;

- структурное построение;

- наличие опыта разработки.

Технологические факторы:

- качество программирования;

- принятие конструктивных решений;

- сложность и объем программы;

- степень выполнения требований на разработку.

Организационные факторы:

-защищенность информации;

- микроклимат в коллективе;

- степень информированности и обученности персонала.

Эксплуатационные факторы:

-полнота и качество документации;

-степень адаптации документации;

-простота изучения и использования;

-качество обучения пользователей;

-степень использования стандартов

на эксплуатацию.

Рис. 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. Укажите характерные случаи возникновения ошибок в программном обеспечении АИС и пути их устранения.