Руководство пользователя программного изделия

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

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

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

В руководство целесообразно включать иллюстрации в виде эк­ранов с описанием особенностей манипуляций на клавиатуре.

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

Руководство пользователя содержит следующие разделы:

• общие сведения;

• описание применения;

• требования к процедурам.

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

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

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

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

Затем должны быть описаны требования, предъявляемые к каж­дому выходному документу или экрану, указаны: способ использо­вания и частота выдачи, способ представления (носитель), инструк-

65 ции по сохранению, распространению и т.д. В этом разделе должны быть представлены описания всех выходных форм и экранов с объ­яснением каждого конкретного раздела формы- По каждому типу результатов работы изделия должны быть представлены образцы с примерами результатов.

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

Глава 9. Отладка программ

Трудности отладки

Отладка (debugging) — процесс нахождения местоположения ошибок в программе и их исправление. Процесс отладки начинает­ся после обнаружения факта ошибки в результате тестирования и осуществляется в два этапа.

Первый этап — установление причины ошибки и ее локализа­ция (определение ее местоположения в программе); второй — ис­правление ошибки и проверка правильности работы программы.

Таким образом, основным средством обнаружения ошибок при отладке является тестирование. Тестирование и отладка при этом обычно проводятся одновременно. Принято выделять три стадии тестирования для:

• обнаружения ошибки в программе;

• установления местонахождения ошибки;

• подтверждения правильности работы программы после прове­денной корректировки.

Как показывает опыт разработки программного обеспечения, трудоемкость отладки превышает суммарную трудоемкость разра­ботки алгоритма, программирования (кодирования) и тестирова­ния. Затраты времени на отладку составляют (по результатам ряда исследователей) от 50 до 80% общего времени разработки програм­мы, поэтому отладку иногда называют искусством обнаружения местоположения ошибок в программе.

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

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

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

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

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

1. Компилятор не выдает сообщений об ошибках, но программа не компилируется.

2. Программа откомпилирована, но при выполнении не выдает никаких результатов.

3. Программа откомпилирована, но при выполнении происхо­дит преждевременный останов. '

4. Программа зацикливается.

5. Программа выдает неверные результаты.

Средства и методы отладки

Отладка начинается после обнаружения ошибки. Существуют следующие средства обнаружения причины ошибки и ее локализа­ции:

1. Листинг исходного кода.

2. Подробная спецификация программы.

3. Детальный алгоритм программы, представленный в виде блок-схемы, схемы действий, таблицы решений и т.п.

4. Выходной листинг.

5. Анализ последовательности выполнения операторов и оценка ожидаемых значений переменных.

6. Отслеживание обращений к подпрограммам.

7. Дампы памяти.

Эти средства предполагают проведение внимательного анализа программы за столом.

Существенную помощь в отладке оказывают инструментальные средства:

• отладочные компиляторы применительно к языку программи­рования;

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

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

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

• генераторы тестовых данных, формирующие тестовые наборы данных в соответствии со спецификациями, задаваемыми пользова­телем;

• специальные он-лайновые отладчики, обеспечивающие авто­матизацию рестартов, остановов и прерываний программы, про­смотр работы отдельных операторов и т.п.;

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

• CASE-средства для построения схем потоков данных, моделей данных, схем алгоритмов и т.п.;

• автоматизированные рабочие места программистов, включаю­щие большинство из перечисленных средств.

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

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

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

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

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

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

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

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

4. Инверсное прослеживание логики программы. Для неболь­ших программ анализ логики выполнения программы в обратном направлении оказывается довольно эффективным способом обнару­жения ошибки. Отладка начинается с точки программы, где обна­ружен неверный результат или произошел останов программы. На основе полученных в этой точке значений переменных необходимо определить, исходя из логики программы, какие результаты долж­ны были быть при правильной работе программы. Последователь­ное продвижение к началу программы позволяет достаточно бы­стро и точно определить место (и причину возникновения) ошибки, т.е. место между оператором, где результат выполнения программы соответствовал ожидаемому, и оператором, в котором появились расхождения.