Тема 1. 8 разработка по. Подходы к разработке по.

1.Кодирование

На этапе разработки ПП выполняются следующие основные действия: кодирование; тестирование; разработка справочной си­стемы ПП; создание документации пользователя; создание вер­сии и инсталляции ПП,

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

При кодировании необходимо следовать стандарту на выбран­ный язык, например, для языка С — это ANSI С, а для C++ — ISO/IEC 14882 «Standart for the C++ Programming Language».

Кроме общепринятого стандарта на язык программирования в компании могут использоваться разработаны и свои дополнитель­ные требования к правилам написания программ. В основном они касаются правил оформления текста программы.

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

На этапе кодирования программист пишет программы и сам их тестирует. Такое тестирование называется модульным. Все воп­росы, связанные с тестированием ПП, рассмотрены в гл. 10, здесь же описана технология тестирования, которая применяется на этапе разработки ПП. Эта технология называется тестированием «стеклянного ящика» (glass box); иногда ее еще называют тестиро­ванием «белого ящика» (white box) в противоположность класси­ческому понятию «черного ящика» (black box).

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

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

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

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

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

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

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

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

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

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

Структурное тестирование является одним из видов тестирования «стеклянного ящика». Его главной идеей является правиль­ный выбор тестируемого программного пути. В противоположность ему функциональное тестирование относится к категории тестиро­вания «черного ящика». Каждая функция программы тестируется путем ввода ее входных данных и анализа выходных. При этом внутренняя структура программы учитывается очень редко.

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

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

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

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

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

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

У хорошо документированного ПП имеются следующие преимущества.

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

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

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

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