Cтраница 3
Заметим, что при таком способе организации разработки АлСУ в некотором смысле стираются грани между задачами отдельных этапов, так как при выполнении каждого последующего этапа непосредственно или косвенно проверяется качество выполнения предыдущих этапов и при необходимости вносятся соответствующие коррективы. Так, например, при испытании программ проверяется не только качество программы, но и качество алгоритмов управления, а также ошибки, вносимые вычислительными средствами. [31]
Рассмотренная модель может применяться для определения времени испытаний программ с целью достижения заданного уровня надежности, а также для оценки числа оставшихся в программе ошибок. [32]
Рыночное тестирование проводится непосредственно в магазинах или на дому, то есть среди реальных покупателей, в момент, когда идет стимулирование. Подобно контрольным рыночным продажам, устраиваемым перед выпуском того или иного товара в обращение в национальном масштабе, испытания программы стимулирования осуществляются в географически ограниченной зоне или всего в нескольких магазинах этой зоны. [33]
Точно определить затраты на программирование нельзя. Примерная оценка этих затрат для каждого этапа разработки программ приведена в [90]: анализ задач - 20 %, разработка ( проектирование) программы - 20 %, запись и испытание программы - ( 25 - f - - f - 25) % 50 %, разработка сопровождающей программу документации - 10 % общих усилий. [34]
Разработка контрольного примера сводится к подготовке исходных данных, на которых можно было бы испытать программу или комплекс программ. В том случае, когда контрольный пример предназначается для проверки правильности результатов, получаемых с помощью программ, разработка контрольного примера не ограничивается лишь выбором данных, которые нужно использовать для испытания программ. Необходимо также вручную рассчитать ожидаемые промежуточные и / или окончательные результаты. Это не всегда возможно, если учесть сложность процедур обработки, реализуемых некоторыми программами. Тем не менее следует попытаться вручную определить ожидаемые вели чины некоторых наиболее важных результатов или хотя бы диапазоны возможных значений. [35]
При создании сложных КП основные технологические работы все больше перемещаются из области создания языков и трансляторов в область средств автоматизации отладки, испытаний и сопровождения. Для получения программ с допустимым минимумом невыявленных ошибок следует создавать средства автоматизации автономной и комплексной отладки, унифицированные методы и средства для имитации информации о внешних абонентах и для обработки результатов в процессе отладки и испытаний программ. Необходимо иметь методы и средства для автоматизированной оценки уровня отлаженности программ и их испытаний. [36]
В этой главе разрабатываются теоретико-функциональные основы доказательства правильности ( корректности) структурированных программ. Вообще корректные взаимосвязи элементов программы чрезвычайно важны, во-первых, во время чтения преграммы, когда необходима правильная ее интерпретация, во-вторых, когда при разработке программы стремятся достичь точного написания, в-третьих, когда на этапе испытания программы устанавливают правильность выполнения ею соответствующей функции. [37]
Критерий № 2 оценивает возможность программирования для неспециалиста по вычислительной технике; критерий № 3 - возможность реализации прикладных программ на вычислительных устройствах разного типа; критерий № 4 - высокое качество программ ( минимальное число ошибок и испытаний программ); критерий № 5 - удобство пользования документацией по разработанным программам; критерий № 6 - эффективность прикладных программ. [38]
Упорядочение и систематизация технологии поэтапного тестирования программ на базе автоматизированных инструментальных систем позволяет достигать высокой корректности и надежности программных комплексов. Особое значение для обеспечения качества имеет формализация и независимость тестирования при испытаниях программ. [39]
Априорно на базе представлений разработчика о динамике функционирования создаваемой программы может быть составлен первоначальный профиль программы. В профиле обычно содержится следующая информация: частота и длительность выполнения каждого оператора, вероятность выполнения каждого логического условия, предельные значения некоторых переменных, количество итераций в циклах. Эти данные для каждой программы могут получаться автоматически в процессе ее исполнения или обобщаться и уточняться по мере развития отладки и испытаний программ. [40]
Он позволяет работать в режимах опроса, пошагового исполнения программы пользователя без и с автоматическим контролем состояния МПС, эмуляции исполнения программы в реальном времени. В режиме опроса основная программа остановлена и управление по командам оператора передается диагностическим процедурам. В этом режиме оператор может изменять состояние микропроцессора. Режим эмуляции программы в реальном времени используется для испытаний программ при рабочих быстродействиях. Для поиска большинства ошибок применяется пошаговый режим. [41]
ЭВМ и увеличивается необходимость использования специальных технологических аппаратных средств. Такие средства подключаются к опытному образцу ЭВМ только временно, на период разработки программ. Они не нужны в каждом экземпляре серийно выпускаемых машин с данным К. Эти средства объединяются в специальные стенды для автоматизации программирования, отладки и испытаний программ. В качестве стендов для автоматизации проектирования могут применяться мощные универсальные ЭВМ с собственными периферийными устройствами. [42]
Программы с малой длительностью эксплуатации создаются в основном для решения научных и инженерных задач, для получения конкретных результатов вычислений. По существу, такие программы являются частью научно-исследовательской работы и не могут рассматриваться как отчуждаемые изделия и программные средства. Их жизненный цикл состоит из длительного интервала системного анализа и формализации проблемы, значительного этапа проектирования программ и относительно небольшого времени эксплуатации и получения результатов. Требования, предъявляемые к функциональным и конструктивным характеристикам, как правило, не формализуются, отсутствуют оформленные испытания программ, и показатели их качества контролируются только разработчиками в соответствии с неформальными представлениями. Сопровождение и модификация таких программ не нужны, и их жизненный цикл завершается после получения результатов вычислений. [43]
Таким образом, установлено, что программу в определенном смысле можно считать динамической системой. Такой подход в большей степени отражает суть взаимодействия программы с элементами вычислительной системы при ее функционировании. Анализируя приведенный на рис. 1.9 граф, можно установить, что вычислительный процесс при каждой реализации программы имеет свои особенности, а следовательно, и характеристики. Реальные программы обработки данных статистической отчетности характеризуются высокой сложностью и потенциально допускают множество траекторий счета, что в значительной степени усложняет отработку и испытание программ. Однако понятия о графах, фазовых траекториях счета и графах реализаций в определенной мере облегчают исследования функциональных характеристик алгоритмов и программ обработки данных статистической отчетности. [44]
Свойство марковских цепей переходить в конечном счете к состоянию равновесия позволяет снизить требования к оптимальности разработки алгоритма. Это допускается при условии, что между всеми этапами разработки установлены необходимые обратные связи, выполняющие функции саморегулирования. Поэтому необходимо уделять большое внимание не только качеству разработки исходного алгоритма, но и вопросам организации взаимодействия между соисполнителями всего проекта. Практика алгоритмизации и программирования сложных вычислительных систем показывает, что асимптотический характер приближения переходных вероятностей к единице требует введения этапа опытной эксплуатации системы и формирования специальных подразделений из высококвалифицированных программистов для выявления и устранения ошибок, оставшихся незамеченными при отладке и испытании программы. Заметим, что при таком способе организации разработки в некотором смысле стираются грани между задачами отдельных этапов, так как при выполнении каждого последующего этапа непосредственно или косвенно проверяется качество выполнения предыдущих этапов и при необходимости вносятся коррективы. Например, при испытании программ проверяется качество не только программы, но и алгоритмов, а также наличие ошибок, вносимых вычислительными средствами. [45]