Cтраница 3
Термины заболевание периферических дыхательных путей или заболевание малых дыхательных путей используются при описании анормального состояния дыхательных путей, диаметр которых составляет менее 2 - 3 мм. Данные о патологических локальных структурных изменениях и концепция, гласящая, что наблюдаемые изменения могут представлять собой начальную стадию развития хронического заболевания дыхательных путей, привели в конце 60 - х и в 70 - х годах к стремительному развитию функциональных тестов, предназначенных для изучения физиологических особенностей периферических дыхательных путей. Вследствие этого термин заболевание периферических дыхательных путей обычно используют по отношению к структурным нарушениям или функциональному дефекту. [31]
Проверяющие тесты состоят из примеров и подпрограмм. Принцип проверки основан на сравнении полученных и ожидаемых данных. Проверяющие тесты имеют следующее назначение: тест прямого управления для контроля правильности обмена данными и кодами внешних прерываний между ЭВМ комплекса с помощью средств прямого управления; тест устройства управления комплексом - для проверки функциональных состояний данного устройства; тесты общего поля внешней памяти на НМД и НМЛ - для контроля передачи данных при использовании общего поля памяти соответственно на НМД и НМЛ; тест адаптера канал-канал - для контроля передачи данных через адаптер канал-канал; тест готовности комплекса ВК-2Р-35 - для проверки готовности всех устройств, входящих в комплекс. Функциональный тест локального комплекса ЕС-7906 служит для проверки устройств, входящих в данный локальный комплекс. [32]
Процесс разработки ПО в ХР является итеративным. Этот процесс начинается с составления плана, в котором определяется, какие истории будут реализованы и каким образом команда разработчиков будет выполнять эту задачу. Пока идет разработка, заказчик придумывает функциональные тесты. В конце итерации тесты должны работать, а разработчики должны быть готовы к следующей итерации. [33]
Целью периодического мед-обследования, как правило, производимого раз в год, является, с одной стороны, контроль за общим физическим здоровьем рабочего, а с другой - выявление проблем, имеющих отношение к никелю. Обследование включает в себя обновление анамнеза информацией о недавно перенесенных заболеваниях и повторную оценку умения рабочего пользоваться личными средствами защиты органов дыхания для конкретного производственного процесса. Легочные симптомы выявляются на основе анализа стандартной анкеты для страдающих хроническим бронхитом. В некоторых странах узаконена рентгеноскопия грудной клетки, легочные функциональные тесты ( например, тест на жизненную емкость легких и измерение объема легких респирометром) проводятся на усмотрение врача-терапевта. [34]
Прежде всего большое внимание следует уделить профилактике ошибок. Первой серьезной мерой в этом направлении служит формализованный метод составления исходных описаний. Дисциплинируя труд постановщика задачи, он существенно упрощает взаимопонимание постановщика с программистом, сокращая вероятность ошибок на этом этапе. Чтобы повысить уверенность в правильности исходного описания, уже на этом этапе имеется возможность составить функциональный тест программируемой задачи. Этот же тест является основой для составления впоследствии полного теста программы. Функциональный тест представляет собой совокупность входных и выходных данных задачи, позволяющих полностью проверить алгоритм содержательных преобразований, заложенных в исходном описании. Такой тест составляется или автором исходного описания, или ( что желательнее) другим исполнителем-постановщиком на основании исходного описания. Функциональный тест можно рассматривать как описание задачи, составленное в терминах примеров реализации всевозможных входных информационных ситуаций, которые могут возникнуть в проектируемой задаче. При этом часто выявляются ошибки или недоработки в разработанном алгоритме задачи. Методика составления функционального теста подробно рассмотрена в следующем разделе. [35]
Полученные в результате сведения уже достаточны для выбора технических решений блоков доступа с передачей полномочий. Здесь наиболее важно решить вопросы выбора общей структуры блоков. Фактически на основе такой структуры создается функционально-логический проект комплекта микросхем или одной микросхемы. На этом этапе определяются: способ сборки блока; номенклатуры микросхем или кристаллов; нагрузочная способность каждой микросхемы; временная диаграмма, показывающая взаимодействие основных блоков; способы моделирования логики работы микросхем и блока в целом; система функциональных тестов для проверки работоспособности отдельных блоков и устройства в целом; средства для входного контроля блоков в условиях промышленного производства. Таков далеко не полный перечень мероприятий, связанных с изготовлением и серийным производством блоков доступа. [36]
Проверка программы выполняется следующим образом. На основании функционального теста составляются таблицы имитации для всех обрабатывающих модулей. Проектировать таблицы удобно в виде матрицы, в первом столбце которой записываются последовательные значения поля SOSMAS, а в остальных столбцах - значения элементов таблиц имитации для каждого из модулей. В каждой строке такой матрицы будут заполнены только два элемента - в столбце SOSMAS и для одного из модулей. Если окажется, что функциональный тест не позволяет проверить всех путей управляющего модуля, его надо расширить. [37]
Прежде всего большое внимание следует уделить профилактике ошибок. Первой серьезной мерой в этом направлении служит формализованный метод составления исходных описаний. Дисциплинируя труд постановщика задачи, он существенно упрощает взаимопонимание постановщика с программистом, сокращая вероятность ошибок на этом этапе. Чтобы повысить уверенность в правильности исходного описания, уже на этом этапе имеется возможность составить функциональный тест программируемой задачи. Этот же тест является основой для составления впоследствии полного теста программы. Функциональный тест представляет собой совокупность входных и выходных данных задачи, позволяющих полностью проверить алгоритм содержательных преобразований, заложенных в исходном описании. Такой тест составляется или автором исходного описания, или ( что желательнее) другим исполнителем-постановщиком на основании исходного описания. Функциональный тест можно рассматривать как описание задачи, составленное в терминах примеров реализации всевозможных входных информационных ситуаций, которые могут возникнуть в проектируемой задаче. При этом часто выявляются ошибки или недоработки в разработанном алгоритме задачи. Методика составления функционального теста подробно рассмотрена в следующем разделе. [38]
Наибольшие трудности возникают при проверке всей задачи. Если количество процедур в программе невелико, то можно попытаться произвести проверку управляющих модулей вместе со всеми обрабатывающими процедурами. Но в большинстве случаев необходимо постепенно наращивать программы, начиная с процедур ввода и добавляя процедуры снизу вверх по укрупненной структуре программы. Каждое такое расширение приводит к необходимости изменения логики управления в главном, а быть может, и в дополнительных управляющих модулях. И только при подключении всех процедур на верхнем уровне вместо имитатора появляется реальный модуль управления. Для проверки всей задачи используется полный функциональный тест, составление которого рассматривалось в предыдущем разделе. [39]
После того как все задачи распределены, программист, ответственный за задачу, оценивает ее на этот раз по числу идеальных дней программирования. Затем собираются оценки задан всех программистов команды, и если некоторые из них планируют затратить больше времени на реализацию, а другие меньше, нагрузка в команде перераспределяется соответствующим образом. В ходе итерации программисты реализуют свои задачи. По мере завершения задач их код интегрируется в общую систему и тестируется вместе с ней. Либо все тесты успешно проходят, либо код нельзя интегрировать в систему. В ходе итерации в общую серию тестов добавляются предоставляемые заказчиком функциональные тесты. [40]
Прежде всего большое внимание следует уделить профилактике ошибок. Первой серьезной мерой в этом направлении служит формализованный метод составления исходных описаний. Дисциплинируя труд постановщика задачи, он существенно упрощает взаимопонимание постановщика с программистом, сокращая вероятность ошибок на этом этапе. Чтобы повысить уверенность в правильности исходного описания, уже на этом этапе имеется возможность составить функциональный тест программируемой задачи. Этот же тест является основой для составления впоследствии полного теста программы. Функциональный тест представляет собой совокупность входных и выходных данных задачи, позволяющих полностью проверить алгоритм содержательных преобразований, заложенных в исходном описании. Такой тест составляется или автором исходного описания, или ( что желательнее) другим исполнителем-постановщиком на основании исходного описания. Функциональный тест можно рассматривать как описание задачи, составленное в терминах примеров реализации всевозможных входных информационных ситуаций, которые могут возникнуть в проектируемой задаче. При этом часто выявляются ошибки или недоработки в разработанном алгоритме задачи. Методика составления функционального теста подробно рассмотрена в следующем разделе. [41]