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

5. Разработайте файл контекстной помощи для Вашей программы. Современные средства программирования позволяют организовать вызов нужного места (топика) Help-файла с каждого экрана. (Обычно это достигается указанием параметра Help_ID). Расскажите в подсказке, для какой задаче нужен данный экран, что нужно сделать для ее решения. Опишите назначения органов управления.

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

8. Тестирование программных продуктов

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

Тестирование программ

Цель тестирование программы – убедится в том, что Ваша программа:

־  не «зависает» при работе под операционными системами, указанными в техническом задании;

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

־  устойчива к вводу данных (в том числе и некорректных);

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

Пример: расчет корней квадратного уравнения

Как же должна быть устроена программа, чтобы пройти все перечисленные проверки? Рассмотрим типовые приемы написания надежных программ на примере простенькой программки расчета корней квадратного уравнения вида:

aX2+bX+c=0.

Как известно, наличие корней этого уравнения определяется знаком дискриминанта:

D=b2-4ac.

Если D>=0 корни можно вычислить по формулам:

X1=(-b + √(D))/(2a)

X2=(-b - √(D))/(2a).

Алгоритм вычисления корней будет выглядеть так:

1)  Вводим значения коэффициентов a, b и c.

2)  Вычисляем дискриминант D.

3)  Если D<0 выводим сообщение «Действительных корней нет» и заканчиваем вычисления. Иначе вычисляемX1 и X2.

Достаточно ли этого алгоритма для надежной работы программы? Давайте попробуем «завесить» нашу программу. Введем a=0 и в качестве b и c любые числа. Дискриминант будет положительным. Программа попытается вычислить корни, но… «зависнет» (или сообщит об ошибке) при попытке деления на ноль!

Вы можете возразить: «Но если a=0, у нас не квадратное, а линейное уравнение. И считать корень нужно по другой формуле!». Но наша программа должна быть устойчива к вводимым данным. Это означает, что какие бы мы числа, на вводили в качестве исходных данных, программа должна работать правильно!

Что же, нам придется улучшить наш алгоритм. Перед тем, как вычислить дискриминант, проверим: a=0? И если да, будем вычислять корень линейного уравнения по формуле:

X=-c/b.

Теперь все в порядке? Давайте введем a=0 и b=0. Очевидно, программа опять зависнет и нам еще раз нужно уточнять алгоритм. Введем еще одну проверку: если a=0, то b=0?. Если оба коэффициента равны нулю, а третий не равен, такой набор чисел не может быть коэффициентами квадратного уравнения. Действительно: подставляя эти числа в общий вид уравнения, получим:

0*X2+0*X+c=0.

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

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

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

Советы молодому программисту

Правила написания надежных программ

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

a.  Если в Вашей программе есть деление, проверьте, не равняется ли нулю знаменатель

b.  Если требуется извлечь квадратный корень, проверьте: не отрицательное ли у Вас подкоренное выражение

c.  Если Вы хотите распечатать Ваши результаты, проверьте, доступен ли принтер

d.  …

4.  Всегда проверяйте результат выполнения операций

a.  Если Вам нужно извлечь данные из БД, проверьте, а действительно ли нужные Вам данные имеются в базе

b.  Проверяйте, справились ли со своей задачей команды: «открыть файл», «вызвать программный модуль» и т. д.

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

5.  Обеспечение защиты от ошибок оператора

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

b.  Предусмотрите «откат» к предыдущему состоянию. Выполнив действие, пользователь может обнаружить, что оно ошибочно. Поэтому не спешите что ни будь удалять или изменять безвозвратно. Создайте временную версию Вашего объекта и сделайте изменения на ней. А предыдущую версию пока сохраните. Если пользователь поймет, что выполнил неверное действие, Ваша программа всегда сможет вернуться к предыдущей версии.

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

Методики тестирования программ

Как проверить соответствие нашей программы предъявленным к ней требованиям? Рассмотрим типичные методы проверки.

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

Правильность работы. Для проверки этого требования используются различные методы:

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

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

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

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

Тестирование данных

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

Цели тестирования данных

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

Рассмотрим основные свойства информации, которые подлежат тестированию.

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

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

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

Актуальности данных. Данные устаревают. Поэтому необходима специальная проверка соответствия хранимых данных теперешнему состоянию объектов реального мира.

Методики тестирования данных

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

Оценка целостности и непротиворечивости данных

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

Таблица 8.1

Виды информационных ошибок

Пример

Вид ошибки

Примечание

Петров № 22

Ошибка в значении признака

Номер паспорта не может быть таким коротким

В записи не указаны фамилия и отчество человека

Неполная запись

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

. Пол мужской

Противоречивая запись

Характеристики одной записи противоречат друг другу

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

Дублирующиеся записи

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

У 876 человек указан один и тот же адрес места жительства

Противоречие между записями

Маловероятно, что в обычной квартире одновременно может проживать так много народу

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

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

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

Пример 2. Фамилия, имя и отчество являются необходимыми признаками для идентификации человека. Запрос на поиск записей, у которых отсутствует хотя бы один необходимый признак, выявит все неполные записи.

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

Оценка достоверности данных

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

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

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

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

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

9. Единая система программной документации

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

-  при написании кода программы (чтобы получилось то, чего мы хотели),

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

-  при сертификации (если мы хотим или Заказчик требует получить сертификат).

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

Для обеспечения сопоставимости и единства интерпретации программной документации в Советском Союзе была разработана Единая Система Программной Документации (ЕСПД). Ниже приводятся выдержки из головного стандарта системы: ГОСТ 19.001-77 «Общие положения», определяющего назначение, состав и область применения ЕСПД.

Назначение и цели ЕСПД

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

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

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

· автоматизации изготовления и хранения программной документации.

В понятие «сопровождение программы» включается:

·  анализ функционирования программы,

·  развитие и совершенствование программы,

·  внесение изменений в нее с целью устранения ошибок.

В состав ЕСПД входят:

· основополагающие и организационно-методические стандарты;

· стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;

· стандарты, обеспечивающие автоматизацию разработки программных документов.

Классификация и обозначение стандартов ЕСПД

Стандарты ЕСПД подразделяют на группы, приведенные в таблице 9.1.

Таблица 9.1

Группы стандартов ЕСПД

Код группы

Наименование группы

0

Общие положения

1

Основополагающие стандарты

2

Правила выполнения документации разработки

3

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

4

Правила выполнения документации сопровождения

5

Правила выполнения эксплуатационной документации

6

Правила обращения программной документации

7

Резервные группы

8

9

Прочие стандарты

Обозначения стандартов ЕСПД строят по классификационному признаку.

В обозначение стандарта ЕСПД должны входить:

· цифры 19, присвоенные классу стандартов ЕСПД;

· одна цифра (после точки), обозначающая код классификационной группы стандартов, указанной в п. 3.1;

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

· двузначное число (после тире), указывающее год регистрации стандарта.

Пример обозначения стандарта “ Единая система программной документации. Общие положения ”:

ГОСТ 19.001-77

| | || |

| | || | Год регистрации стандарта

| | || Порядковый номер стандарта в группе

| | | Классификационная группа стандартов

| | Класс (стандарты ЕСПД)

| Категория стандарта (государственный стандарт)

Изменение целей и назначения системы стандартов ЕСПД при переходе к рыночной экономике

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

В этих условиях изменяется роль стандартов ЕСПД. Их требования остаются обязательными только при определенных условиях[11] или в случае, если соблюдение требований стандарта упомянуто в договоре. В остальных случаях требования стандарта носят рекомендательный характер.

Стандарты, составляющие ЕСПД

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

Таблица 9.2

Перечень стандартов, входящих в

Единую Систему Программной Документации

ГОСТ

Название

19.001-77

Общие положения

19.002-80

Схемы алгоритмов и программ. Правила выполнения

19.003-80

Схемы алгоритмов и программ.
Обозначение условные графические

19.004-80

Термины и определения

19.101-77

Виды программ и программных документов

19.102-77

Стадии разработки

19.103-78

Обозначение программ и программных документов

19.104-78

Основные надписи

19.105-78

Общие требования к программным документам

19.106-78

Требования к программным документам,
выполненным печатным способом

19.201-78

Техническое задание.
Требования к содержанию и оформлению

19.202-78

Спецификация.
Требования к содержанию и оформлению

19.301-79

Программа и методика испытаний.
Требования к содержанию и оформлению

19.401-78

Текст программы.
Требования к содержанию и оформлению

19.402-78

Описание программы

19.403-79

Ведомость держателей подлинников

19.404-79

Пояснительная записка.
Требования к содержанию и оформлению

19.501-78

Формуляр

Требования к содержанию и оформлению

19.502-78

Описание применения
требования к содержанию и оформлению

19.503-79

Руководство системного программиста.
Требования к содержанию и оформлению

19.504-79

Руководство программиста.
Требования к содержанию и оформлению

19.505-79

Руководство оператора.
Требования к содержанию и оформлению

19.506-79

Описание языка.
Требования к содержанию и оформлению

19.507-79

Ведомость эксплуатационных документов

19.508-79

Руководство по техническому обслуживанию.
Требования к содержанию и оформлению

19.601-78

Общие правила дублирования, учета и хранения

19.602-78

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

19.603-78

Общие правила внесения изменений

19.604-78

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

Виды программной документации

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

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8