9.5. ПРОЕКТИРОВАНИЕ ТЕСТОВ БОЛЬШИХ ПРОГРАММ

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

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

            При восходящем тестировании для каждого модуля необходима ведущая программа. Это монитор или драйвер, который подает тесты в соответствии со спецификациями тестов. Ряд фирм выпускает промышленные драйверы или мониторы тестов.

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

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

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

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

            Метод большого скачка — каждый модуль тестируется автономно. По окончании автономного тестирования всех модулей, модули просто интегрируются в готовую программную систему. Как правило, этот метод нежелателен. Однако если программа мала и хорошо спроектирована по сопряжениям, то метод большого скачка вполне приемлем. 

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

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

9.6. КРИТЕРИИ ВЫБОРА НАИЛУЧШЕЙ СТРАТЕГИИ РЕАЛИЗАЦИИ

            Критериями выбора наилучшей стратегии реализации программы являются:

            → время до полной сборки программы;

            → время реализации скелета программы;

            → имеющийся инструментарий тестирования;

            → мера параллелизма ранних этапов реализации;

            → возможность проверки любых путей программы данными из заглушек;

            → сложность планирования и соблюдения графика реализации;

            → сложность тестирования.

            9.7. СПОСОБЫ И ВИДЫ ТЕСТИРОВАНИЯ ПОДПРОГРАММ. ПРОЕКТИРОВАНИЕ ТЕСТОВ

            Существуют два способа тестирования: публичный и приватный.

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

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

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

            Так, фирма «Microsoft» использует все перечисленные выше подходы для тестирования своих продуктов. С ее сайтов всегда можно бесплатно загрузить большое количество продуктов, проходящих публичное бета-тестирование. Однако их появлению предшествует многомесячный процесс приватного тестирования. Фирма «Microsoft» проводит политику открытого набора приватных бета-тестировщиков, при которой каждый желающий может сообщить корпорации о своем желании принять участие в тестировании того или иного продукта. На самом деле круг приватных бета-тестеров Microsoft очень узок, и шанс, что вас включат в их число, невелик. Тем не менее он существует, а попадают в список бета-тестеров практически пожизненно.

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

            Визуальный контроль — это проверка текстов «за столом», без использования компьютера.

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

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

Статический контроль — это проверка текста подпрограммы (без выполнения) с помощью инструментальных средств.

            Первой, наиболее известной формой статического контроля является синтаксический контроль программы с помощью компилятора, при котором проверяется соответствие текста программы синтаксическим правилам языка программирования.

            Сообщения компилятора обычно делятся на несколько групп в зависимости от уровня тяжести нарушения синтаксиса языка программирования:

            1) информационные сообщения и предупреждения, при обнаружении которых компилятор, как правило, строит корректный объектный код и дальнейшая работа с программой (компоновка, выполнение) возможна (тем не менее сообщения этой группы должны тщательно анализироваться, так как их появление также может свидетельствовать об ошибке в программе — например, из-за неверного понимания синтаксиса языка);

            2) сообщения об ошибках, при обнаружении которых компилятор пытается их исправить и строит объектный код, но его корректность маловероятна и дальнейшая работа с ним, скорее всего невозможна

            3) сообщения о серьезных ошибках, при наличии которых построенный компилятором объектный код заведомо некорректен и его дальнейшее использование невозможно;

            4) сообщения об ошибках, обнаружение которых привело к прекращению синтаксического контроля и построения объектного кода.

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

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

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

            → использование в программе неинициализированных переменных (т. е. переменных, не получивших начального значения);

            → наличие в программе описаний элементов, переменных, процедур, меток, файлов, в дальнейшем не используемых в ее тексте;

            → наличие в тексте подпрограммы фрагментов, никогда не выполняющихся;

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

            → наличие в тексте подпрограммы заведомо бесконечных циклов.

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

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

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

            1) проведение дополнительных форм статического контроля после завершения компиляции и только для синтаксически корректных программ;

            2) максимальное использование результатов компиляции и линковки программы и, в частности, информации, включаемой в листинг компилятора и линкера;

            3) вместо полного синтаксического разбора текста проверяемой программы необходимо построение для нее списка идентификаторов и списка операторов с указанием всех их необходимых признаков.

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

            Четвертой формой статического контроля программ является их верификация, т. е. аналитическое доказательство их корректности.

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

            Динамический контроль программы — это проверка правильности программы при ее выполнении на компьютере, т. е. тестирование. Минимальное автономное тестирование подпрограммы должно обеспечивать прохождение всех путей вычислений.

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

            — по внешним спецификациям модуля подготовьте тесты для каждой ситуации и каждого недопустимого условия;

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

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

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

9.8. ПРОЕКТИРОВАНИЕ КОМПЛЕКСНОГО ТЕСТА

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

            → работоспособности;

            → стрессов;

            → предельного объема вводимых данных;

            → конфигурации различных технических средств;

            → совместимости;

            → защиты;

            → требуемой памяти;

            → производительности;

            → настройки;

            → надежности;

            → средств восстановления при отказе;

            → удобства обслуживания;

            → программной документации;

            → психологических факторов;

            → удобства эксплуатации.

9.9. СРЕДСТВА АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ

Генераторы тестов (automatic unit test) случайным образом генерируют данные.

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

ВЫВОДЫ

            • Тестирование программ — главное, что определяет важнейшее качество программ — надежность.

            • На тестирование расходуется основная часть средств и времени проекта.

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

            • Аксиомы тестирования определяют основные цели и принципы тестирования.

            • Если из текста исключить отладочные печати, то существенно усложнится сопровождение.

            • Существуют два крайних подхода к проектированию тестов: стратегия «черного ящика» и стратегия «белого ящика». Бесполезно следовать только одному подходу. Необходимо строить стратегию тестирования только на основе сочетания подходов.

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

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

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

            — Метод сандвича — по этому методу реализация и тестирование ведутся одновременно сверху и снизу, и два этих процесса встречаются в заранее намеченной временной точке.

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

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

Глава 10 . МЕНЕДЖМЕНТ ПРОГРАММНЫХ РАЗРАБОТОК

10.1. УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОГРАММНЫХ СИСТЕМ

            Управление разработкой программных систем (software management) — это деятельность, направленная на обеспечение необходимых условий для работы коллектива разработчиков программного обеспечения (ПО), на планирование и контроль деятельности этого коллектива с целью обеспечения требуемого качества ПО, выполнения сроков и бюджета разработки ПО. Часто эту деятельность называют также управлением программным проектом (software project management). Здесь под программным проектом (software project) понимают всю совокупность работ, связанную с разработкой ПО, а ход выполнения этих работ называют развитием программного проекта (software project progress).

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

            Хотя виды деятельности по управлению разработкой ПО могут быть весьма разнообразными, в зависимости от специфики разрабатываемого ПО и организации работ по его созданию можно выделить некоторые общие процессы (виды деятельности) по управлению разработкой ПО:

            — составление плана-проспекта по разработке ПО;

            — планирование и составление расписаний по разработке ПО;

            — управление издержками по разработке ПО;

            — текущий контроль и документирование деятельности коллектива по разработке ПО;

            — подбор и оценка персонала коллектива разработчиков ПО.

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

            → для внешнего заказчика;

            → для других подразделений той же организации;

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

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

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

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

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

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

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

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

            Различают два вида таких стандартов:

            → стандарты ПО (программного продукта);

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

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

            10.2. СТРУКТУРА УПРАВЛЕНИЯ РАЗРАБОТКОЙ ПРОГРАММНЫХ СРЕДСТВ

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

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

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

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

Менеджер проекта осуществляет планирование и составление расписаний работы бригад по разработке соответствующего программного средства.

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

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

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

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

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

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

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

            Администратор базы данных разработки (librarian) отвечает за сопровождение всей документации (включая версии программ), возникающей в процессе разработки программной подсистемы, и снабжает членов бригады информацией о текущем состоянии разработки. Эта работа выполняется с помощью соответствующей инструментальной компьютерной поддержки. В зависимости от объема и характера порученной работы в бригаду могут быть включены дополнительные члены:

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

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

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

            → тестировщик, готовящий подходящий набор тестов для отладки разрабатываемой программной подсистемы;

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

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

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

10.3. ПОДБОР КОМАНДЫ

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

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

            Разработчики отвечают за исследования, проект и создание программного обеспечения, включая альфа-тестирование своей работы.

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

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

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

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

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

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

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

10.4. МЕТОДОЛОГИЯ УПРАВЛЕНИЯ ПРОЕКТОМ

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

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

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

            Определенная методология разработки программного обеспечения устраняет разногласия и отсутствие связи между членами команды разработчиков и между программистами и конечными пользователями.

            Новые люди «безболезненно» подключаются к проекту на любой стадии разработки.

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

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

10.5. СОСТАВЛЯЮЩИЕ МЕТОДОЛОГИИ РАЗРАБОТКИ

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

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

            Четкая формулировка цели должна отвечать на вопросы: «Что система должна делать?»; «Была ли четко сформулирована цель создания системы?», «Знает ли конечный пользователь, что система действительно должна делать?» Конечно, очень важно найти истинную цель приложения, чтобы иметь возможность определить границы проекта. Это необходимо сделать настолько быстро, насколько возможно.

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

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

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

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

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

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

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

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

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

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

10.6. АНАЛИЗ ПОЖЕЛАНИЙ И ТРЕБОВАНИЙ ЗАКАЗЧИКА

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

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

            Наиболее важная цель, которой необходимо достигнуть на этом первом этапе, — это найти и понять, что же НА САМОМ ДЕЛЕ ХОЧЕТ ПОЛЬЗОВАТЕЛЬ. Иной раз сделать это не так просто, поскольку пользователь не всегда точно представляет, ЧТО он действительно хочет получить. Банальным примером могут служить пользователи, заказывающие, например, одновременно несколько больших задач типа «Учет заработной платы», «Ведение складского учета», «Составление табеля» и т. п., называя все это «Бухгалтерией». Если проигнорировать данный этап, то проект может в конце концов быть осужден на большое количество доработок, достраивание кода «на коленке» и непременное сидение программистов по выходным, чтобы сделать клиенту действительно то, что он хочет и что не было оговорено заранее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.7. АНАЛИЗ ТРЕБОВАНИЙ К ПРОЕКТУ

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

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

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

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

            Главная цель этого этапа — удостовериться в том, что вы понимаете потребности пользователя и приоритеты направлений разработки.

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

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

10.8. ТРЕБОВАНИЯ ПОЛЬЗОВАТЕЛЯ

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

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

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

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

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

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

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

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

10.9. ТЕХНИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

            Техническое проектирование — это мост между функциональной спецификацией и фактической стадией кодирования. Часто команда разработчиков пытается сократить и объединить стадию разработки функциональной спецификации и техническое проектирование и разработать один документ. Это ошибка.

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

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

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

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

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

10.10. РЕАЛИЗАЦИЯ

            Обычно на этапе кодирования всплывают все неприятные проблемы, которые только можно себе представить. Чем больше проект, тем больше проблем. Вот почему первые три шага так важны.

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

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

            10.11. СИСТЕМНОЕ ТЕСТИРОВАНИЕ

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

            — системный тест или лабораторные испытания;

            — опытная эксплуатация;

            — приемочный тест.

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

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

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

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

10.12. ПРИЕМОЧНЫЙ ТЕСТ

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

10.13. ПОСЛЕРЕАЛИЗАЦИОННЫЙ ОБЗОР

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

            → Что мы делали правильно?

            → Что мы делали неправильно?

            → Какие стадии были наиболее полезными, а какие ненужными?

            → Отсутствовало ли что-нибудь на какой-либо стадии разработки, что бы помогло усовершенствовать программный продукт?

10.14. СОПРОВОЖДЕНИЕ ПРОГРАММ

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

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

            ВЫВОДЫ

            • Разработка программных систем — сложное мероприятие. Можно выделить следующие общие процессы по управлению разработкой ПО: составление плана-проспекта по разработке ПО — планирование и составление расписаний по разработке ПО; управление издержками по разработке ПО; текущий контроль и документирование деятельности коллектива по разработке ПО; подбор и оценка персонала коллектива разработчиков ПО.

            • Обычно в организации одновременно разрабатывается несколько программных проектов. Для оптимального качества и скорости работы необходимо верно структурировать управление организацией.

            • Каждая разработка проекта собирает вокруг себя команду специалистов (команду проекта), состоящую из конечного пользователя; разработчиков; начальника отдела; начальника отдела информационных систем; ответственного за гарантию качества; группы, ответственной за бета-тестирование.

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

            • Разница между понятиями «желание заказчика» и «конечный продукт> обычно очень велика. Мостом для их соединения должен быть первичный этап обследования проекта и составление технического задания на данный проект. Эта задача делится на три стадии: изучение требований заказчика, уточнение функциональной специфики задачи и техническое проектирование задачи. Если говорить о требованиях пользователя, то их необходимо соблюдать неукоснительно.

            • Техническое проектирование — своего рода мост между функциональной спецификацией и фактической стадией кодирования. Это крайне важная стадия и халатно к ней относиться нельзя.

            • Системное тестирование может состоять из трех отдельных фаз: системный тест или лабораторные испытания; опытная эксплуатация; приемочный тест.

            • Сопровождение — нелюбимая программистами, но необходимая часть, дающая возможность для усовершенствования продукта.

Приложение 1. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ ПРОГРАММ ПО ГОСТ 19.102 — 77

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

Приложение 2 .ПРИМЕР ВЫПОЛНЕНИЯ УЧЕБНОГО ТЕХНИЧЕСКОГО             ЗАДАНИЯ

1. ВВЕДЕНИЕ

1.1. Наименование программного изделия

Полное наименование программы — «Простейший редактор

текстовых файлов MS DOS». Краткое наименование программы — редактор.

1.2Область применения

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

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

1.1. Документ, на основании которого ведется разработка

            Разработка ведется на основании задания на курсовое проектирование по дисциплине «Технология программирования».

1.2. Организация, утвердившая этот документ, и дата его утверждения.

            Задание утверждено на заседании кафедры САП Р и ПК 04.01.98 и выдано преподавателем кафедры Петровым В.В.

1.3. Наименование темы разработки

Наименование темы разработки — EDIT.

2. НАЗНАЧЕНИЕ РАЗРАБОТКИ

            Разработка является аттестационной при подготовке бакалавра.

4. ТРЕБОВАНИЯ К ПРОГРАММЕ

            4.1. Требования к функциональным характеристикам

            4.1.1. Состав выполняемых функций

            4.1.1.1. Редактор должен обеспечить корректировку уже имеющихся на диске и создание новых текстовых файлов MS DOS в диалоговом режиме работы.

            4.1.1.2. Внешний вид программы должен соответствовать макетам экранов и сценарию работы, представленным в ПРИЛОЖЕНИИ 1.

            4.1.1.3. Список управляющих клавиш программы редактора и кодов символов, заносимых в текстовый файл, должен соответствовать ПРИЛОЖЕНИЮ 2.

            4.1.1.4. При запуске редактора командой MS DOS ЕО1ТЕХЕ, с указанием через символ пробела имени редактируемого файла, программа редактора должна обеспечить загрузку редактируемого файла. Программа редактора должна запускаться командой MS DOS EDIT.ЕХЕ и без указания имени редактируемого файла.

            4.1.1.5. В любой момент работы программы при нажатии клавиши <Fl> должны выводиться тексты помощи со списком всех возможных команд редактора на данный момент.

            4.1.1.6. Программа должна обеспечить вывод на принтер содержимого текстового файла стандартными символами принтера с числом строк на странице, заданным пользователем.

            4.1.2. Организация входных и выходных данных

            Организация входных и выходных файлов редактора должна соответствовать

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

4.1.3. Временные характеристики и размер занимаемой памяти

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

            4.2. Требования к надежности

            4.2.1. Требования к надежному функционированию

            Программа должна нормально функционировать при бесперебойной работе ЭВМ. При возникновении сбоя в работе аппаратуры восстановление нормальной работы программы должно производиться после:

            1) перезагрузки операционной системы;

            2) запуска исполняемого файла программы; повторного выполнения действий, потерянных до последнего сохранения информации в файл на магнитном диске.

            Уровень надежности программы должен соответствовать технологии программирования, предусматривающей:

            1) инспекцию исходных текстов программы;

            2) автономное тестирование модулей (методов) программы;

            3) тестирование сопряжений модулей (методов) программы;

            4) комплексное тестирование программы.

            4.2.2. Контроль входной и выходной информации

            Программа должна контролировать выбор пользователем пункта меню «Выход» и предупреждать его о потере «несохраненных изменений».

            4.2.3. Время восстановления после отказа

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

            1) времени перезапуска пользователем операционной системы;

            2) времени запуска пользователем исполняемого файла программы;

            3) времени повторного ввода потерянных данных.

            4.3. Условия эксплуатации

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

            4.4. Требования к составу и параметрам технических средств

            Программа должна корректно работать на следующем или совместимом с ним оборудовании:

            1) ПЭВМ IBM РС модели 300 GL;

            2) принтере Epson Stylus 800+ модели P780B.

            4.5. Требования к информационной и программной совместимости

            4.5.1. Требования к информационным структурам на входе и выходе

            Требования к информационным структурам на входе и выходе определены в пункте (см. п. 4.1.2.).

            4.5.3. Требования к методам решения

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

            4.5.4. Требования к языкам программирования

            Язык программирования выбирается разработчиком без согласования с заказчиком.

            4.5.5. Требования к программным средствам, используемым программой

            Для работы программы необходима операционная система MS-DOS версии 6.22.

            4.6. Требования к маркировке и упаковке

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

4.1. Требования к транспортированию и хранению

            Условия транспортирования и хранения дискеты должны соответствовать подразделу (см. подраздел 4.6.).

5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

            Состав программной документации должен включать следующие документы:

            1) технический проект программы по ГОСТ 19.404 — 79 в машинописном исполнении;

            2) описание программы по ГОСТ 19.402 — 78 на машинном носителе;

            3) текст программы по ГОСТ 19.401 — 78 на машинном носителе;

            4) руководство программиста по ГОСТ 19.504 — 79 на машинном носителе в виде файла             README.ТХТ.

            Пояснительная записка «технический проект программы» должна содержать следующие разделы:

            1) Раздел «ВХОДНЫЕ ДАННЫЕ» (Характер, организация и предварительная подготовка входных данных);

            2) Раздел «ВЫХОДНЫЕ ДАННЫЕ» (Характер и организация выходных данных);

            3) Раздел «ОПИСАНИЕ ЛОГИЧЕСКОЙ СТРУКТУРЫ»;

            4) Раздел «ИСПОЛЬЗУЕМЫЕ ТЕХНИЧЕСКИЕ СРЕДСТВА» (Типы Э ВМ, на которых возможно выполнение программы; устройства ЭВМ, используемые при выполнении программы);

            5) Раздел «ВЫЗОВ И ЗАГРУЗКА» (Виды носителей программы, их используемый объем; способы вызова программы с соответствующих носителей данных; входные точки в программу — запуск программы);

            6) Раздел «ПЛАН МЕРОПРИЯТИЙ ПО РАЗРАБОТКЕ И ВНЕДРЕНИЮ ПРОГРАММЫ» (План мероприятий разрабатывается для реализации программы коллективом программистов — два человека. Планом должны быть предусмотрены контрольные временные точки реализации, например, через каждые десять дней или неделю, в течение которых происходит интеграция разработанных модулей и тестирование уже разработанной части программы. Приводится состав тестов и принципы их подготовки для тестирования уже созданного фрагмента программы для каждой из контрольных точек).

            Раздел «ОПИСАНИЕ ЛОГИЧЕСКОЙ СТРУКТУРЫ» при технологии структурного программирования должен включать следующие материалы:

            1) описание связей программы с другими программами;

            2) описание внутренних массивов и переменных, которые используются в межмодульном обмене данными;

            3) схема иерархии программы (приводится рисунок или рисунки); 

            4) расшифровка наименований модулей (приводится таблица с перечнем наименований модулей в алфавитном порядке с указанием выполняемой каждым модулем функции);

            5) описание функционирования программы с учетом ее модульного деления (приводится словесное описание выполнения программы с учетом вызовов модулей);

            6) описание модулей программы (подраздел заполняется на основе паспортов модулей).

6. ТЕХНИКО-ЭКОНОМИЧЕСКИЕ ПОКАЗАТЕЛИ

            Технико-экономические показатели должны определяться заказчиком без участия исполнителя.

7. СТАДИИ И ЭТАПЫ РАЗРАБОТКИ

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

            1) разработка, согласование и утверждение технического проекта программы с пояснительной запиской — 5 недель;

            2) разработка рабочего проекта программы с комплексным тестированием — 6 недель;

            3) приемка-сдача с исправлением обнаруженных недостатков в программе и программной документации — 2 недели;

            4) внедрение.

8. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ

            8.1. Виды испытаний

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

проводиться в организации заказчика с привлечением сторонних экспертов. Проверочные тесты должны готовиться заказчиком.

            8.2. Общие требования к приемке

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

            Приложение 3. ФОНД ЭВРИСТИЧЕСКИХ ПРИЕМОВ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1. ВЫБОР СТРАТЕГИИ ПРОЕКТИРОВАНИЯ ПРОГРАММ

            1.1. Заменить восходящий способ проектирования программ нисходящим.

            1.2. Инверсия приема.

            1.3. Использовать комбинированный (восходяще-нисходящий) способ проектирования. В данном случае главная часть программы разрабатывается нисходящим способом, а отдельные модули и подсистемы — восходящим.

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

2. ВЫБОР ПОДХОДА В ПРОГРАММИРОВАНИИ (методологии проектирования)

            2.1. Заменить методологию, ориентированную на обработку (модульное программирование; функциональная декомпозиция; проектирование с использованием потока данных; структурное проектирование; технология структурного анализа проекта SADT; проектирование, основанное на использовании структур данных; методология Джексона; методология Уорнера и др.), на методологию, ориентированную на данные (абстракции данных Дейкстры, объектно-ориентированная методология; методология, ориентированная на проектирование концептуальных баз данных и др.).

            2.2. Инверсия приема.

3. ВЫБОР ЯЗЫКА

            3.1. Выбрать более «любимый» язык программирования.

            3.2. Выбрать язык программирования, специально предназначенный для решения конкретной проблемы.

            3.3. Заменить проблемно-ориентированный язык на объектно-ориентированный.

            3.4. Инверсия приема.

            3.5. Заменить язык высокого уровня языком низкого уровня. 3.6. Инверсия приема.

            3.7. Использовать в проекте два и более языков программирования.

            3.8. Подключать объектный код (откомпилированный с помощью компилятора другого языка программирования или ассемблер) с помощью директивы компилятора.

            3.9. Использовать встроенный ассемблер системы программирования.

4. ПРЕОБРАЗОВАНИЕ АРХИТЕКТУРЫ, ИЛИ СТРУКТУРЫ ПРОГРАММНОЙ СИСТЕМЫ

            4.1. Увеличить число модулей системы.

            4.2. Инверсия приема.

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

            4.4. Инверсия приема.

            4.5. Заменить глобальные переменные локальными переменными.

            4.6. Инверсия приема.

            4.7. Произвести декомпозицию модуля на несколько. Данный прием позволяет распределить выполняемые функции между отдельными функциями.

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

            4.9. Оформить модули, связанные между собой единой логикой, в библиотеку.

            4.10. Использовать в проектировании системы стандартные модули системы программирования.

            4.11. Использовать библиотечные модули, разработанные другими программистами.

5. ПРЕОБРАЗОВАНИЕ СТРУКТУРЫ МОДУЛЯ

            5.1. Заменить линейную структуру команд циклической. (Повышает компактность кода программы.)

            5.2. Инверсия приема.

            5.3. Заменить ветвящуюся структуру циклической.

            5.4. Инверсия приема.

            5.5. Заменить ветвящуюся структуру if— then — else вариантом оператора case.

            5.6. Заменить ветвящуюся структуру case цепочкой операторов if — then.

            5.7. Инверсия приема.

            5.8. Заменить цикл repeat — until циклом while.

            5.9. Инверсия приема.

            5.10. Заменить цикл repeat — until циклом for.

            5.11. Инверсия приема.

            5.12. Заменить цикл while циклом for.

            5.13. Инверсия приема.

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

            5.15. Использовать рекурсию.

            5.16. Заменить подпрограмму-процедуру подпрограммой-функцией. Данный прием позволяет получить дополнительный параметр, выдаваемый подпрограммой (например, код ошибки).

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

            5.18. Полностью исключить или минимизировать использование оператора goto. Улучшает структуру программы, ее читабельность и логику.

            5.19. Использовать оператор goto для быстрой передачи управления. Позволяет быстро без привлечения дополнительных средств передавать управление другому процессу. Следует применять только в тех случаях, когда переход является наиболее лаконичным, простым и ясным средством.

            5.20. Использовать процедуру exit для выхода из подпрограммы. Позволяет обходиться без оператора goto и без усложнения логики подпрограммы.

            5.21. Использовать директиву компилятора для безболезненного использования процедур в качестве функций и функций в качестве процедур.

            5.22. Использовать процедурный тип данных.

            5.23. Использовать указатели на процедуры и функции.

            5.24. Увеличить размерность массива.    

            5.25. Инверсия приема.

            5.26. Использовать тип данных множество set вместо массивов.

            5.27. Инверсия приема.

            5.28. Замена записи фиксированной длины записью с вариантом.

            5.29. Инверсия приема.

            5.30. Заменить обычные строки (тип String) строками с нулевым окончанием.

            5.31. Инверсия приема.

            5.32. Использовать оператор with для упрощения работы с записями.

            5.33. Использовать преобразование типов данных. 5.34. Использовать типизированные константы.

            5.35. Давать переменным, константам и типам данных содержательные обозначения.

            5.36. Широко использовать комментарии для пояснения вычислительных алгоритмов.

6. ОРГАНИЗАЦИЯ И ХРАНЕНИЕ ДАННЫХ

            6.1. Заменить типизированный файл не типизированным файлом.

            6.2. Инверсия приема.

            6.3. Заменить типизированный файл текстовым файлом.

            6.4. Инверсия приема.

            6.5. Заменить не типизированный файл текстовым файлом.

            6.6. Инверсия приема.

            6.7. Заменить носитель данных.

            6.8. Проводить сортировку данных с целью облегчения поиска.

            6.9. Использовать индексированные массивы данных для организации поиска по вторичным ключам.

            6.10. Исключить избыточность данных.

            6.11. Декомпозировать данные на несколько файлов.

            6.12. Объединить данные в один файл данных.

7. ЭКОНОМИЯ РЕСУРСОВ ПРОГРАММЫ

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

            7.2. Использовать директивы встроенного ассемблера.

            7.3. Использовать абсолютную адресацию данных через директиву absolute и стандартные массивы Mem, MemW, MemL.

            7.4. Использовать непосредственное обращение к портам через стандартные массивы Port, PortW, Рог(1.

            7.5. Использовать систему прерываний через функции модуля DOS — Intr и MsDOS.

            7.6. Использовать профилировку кода программ с помощью программ-профилировщиков.

            7.7. Заменить статические переменные и массивы динамическими.

            7.8. Использовать оверлейную организацию программ.

            7.9. Объединить оверлейные файлы в один исполняемый файл типа *.ЕХЕ.

            7.10. Разбить программу на резидентную часть (TSR) и подгружаемые части.

            7.11. Использовать дополнительную память компьютера (ехpanded memory).

            7.12. Использовать расширенную память компьютера (extends ded memory).

            7.13. Использовать защищенный режим работы процессора (protected mode).

            7.14. Использовать режим виртуального процессора 8086.

8. ОФОРМЛЕНИЕ ВАРИАНТА (ВЕРСИИ) ПРОГРАММЫ

            8.1. Размножение окрестности (копирование старого варианта в отдельный файл). Крайне неэффективный метод из-за загромождения дискового пространства.

            8.2. Замена вызова старой процедуры на вызов новой также неэффективна, так как старые процедуры также подключаются к объектному коду программы, что приводит к загромождению программы.

            8.3. Использовать оператор выбора. Те же ограничения.

            8.4. Комментирование измененного кода программы.

            8.5. Использование директив компилятора {$IFDEF <условие>} и ($IFOPT <опция>).

9. ТЕСТИРОВАНИЕ ПРОГРАММ

            9.1. Заменить восходящее проектирование тестов нисходящим.

            9.2. Инверсия приема.

            9.3. Использовать метод большого скачка.

            9.4. Использовать метод «сандвича»

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

            9.6. Использовать генератор входных данных.

10. ОТЛАДКА ПРОГРАММ

            10.1. Использовать встроенный отладчик системы (трассировка программы).

            10.2. Использовать директивы компилятора {$D} и {$L} при компиляции модулей с целью иметь непосредственный доступ к переменным и процедурам модуля.

            10.3. Использовать отладочную печать. Выводить значения отдельных ключевых переменных и массивов непосредственно на экран или во внешний файл на диске.

            10.4. Вставить «заглушки» на те модули программы, которые не подвергаются в настоящий момент отладке.

            10.5. Использовать процедуру halt в случае исключительной ситуации.

            10.6. Использовать возвращение функцией или процедурой специального значения в случае исключительной ситуации.

            10.7. Использовать код возврата в виде отдельной глобальной переменной.

11. ОРГАНИЗАЦИЯ ДИАЛОГА С ПОЛЬЗОВАТЕЛЕМ

            11.1. Заменить горизонтальное меню вертикальными меню.

            11.2. Инверсия приема.

            11.3. Использовать скроллинг меню.

            11.4. Заменить выпадающее меню всплывающим меню.

            11.5. Инверсия приема.

            11.6. Организовать меню, активизирующееся по горячим клавишам.

            11.7. Использовать кнопки и панели диалога.

            11.8. Организовывать громоздкие экранные формы в виде многостраничных форм.

            11.9. Использовать скроллинг экранных форм.

            11.10. Использовать всплывающие экранные формы.

            11.11. Использовать гипертекстовую систему в качестве системы помощи.