Надежность программного обеспечения электронно-вычислительных машин
Ознакомление с историей возникновения термина надежности программных средств. Исследование исправления ошибок системой — плодотворного метода проектирования надежных систем аппаратного обеспечения. Анализ мультипроцессорной системы с виртуальной памятью.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 17.03.2016 |
| Размер файла | 84,2 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Национальный Авиационный Университет
Курсовой проект
По дисциплине: «Основы теории надежности, эксплуатация и ремонт РЭА»
Тема: «Надежность программного обеспечения электронно-вычислительных машин»
Выполнила: студентка группы 403 ФЭТ Груй Е.О.
Проверил: Соломенцев А. В.
Киев 2001
Содержание
Основные понятия и определения
Показатели надежности
Четыре подхода к надежности
Обнаружение ошибок
Исправление ошибок и устойчивость к ошибкам
Изоляция ошибок
Литература
1. Основные понятия и определения
Термин надежность программных средств (НПС) возник по аналогии с понятием надежности технических изделий. Однако аналогия ограничивается формой проявления программных и технических отказов, выражающихся в утрате исследуемым объектом работоспособности. Несмотря на внешнее сходство проявления отказов аппаратуры и дефектов ПС механизмы их формирования имеют различную природу. Для программного обеспечения фундаментальной является идея проектных дефектов, а теория надежности техники учитывает в основном отказы из-за износа, старения или других физических, химических и механических причин изменяющих характеристики устройств во времени. Если в аппаратуре в момент проявления отказа происходят некоторые изменения (поломка, короткое замыкание, исчезновение контактов и т. д.), то программа остается такой же, как и была до момента обнаружения ошибки (дефекта). На принятом в данной работе уровне описания (без учета свойств технических носителей информации) программы не имеют физического износа или старения, т.е. не изменяют своих свойств во времени.
Тем не менее, один из подходов к термину надежности ПС, основан на теории надежности технических изделий. Наиболее показательно в этом отношений определение надежности как свойства системы программного обеспечения (ПО) сохранять в течение требуемого интервала времени способность правильно выполнять заданные спецификацией правила переработки информации в реальных условиях эксплуатации.
Другой подход к термину надежность ПС отражает стремление к расширительному толкованию надежности ПС и в значительной степени отождествляет понятия надежности и качества. В соответствии с этим подходом программа обладает свойством надежности, если можно предполагать, что она будет «удовлетворительно выполнять необходимые функции» или «удовлетворять ожидания пользователя».
Третий подход связывает свойства надежности ПС с наличием в программе ошибок, оставшихся после завершения его отладки, тестирования и испытаний. В этом случае под надежностью программ понимается единичный показатель, характеризующий свойство ПС проявлять в процессе эксплуатации оставшиеся в нем ошибки. Таким образом, данный подход, в отличие от предшествующего, сужает характеристику надежности до понятия корректности ПС, так как, в соответствии с указанным определением корректная программа считается абсолютно надежной.
Известен также подход к надежности ПС с использованием количественной меры этого свойства. При этом надежность программ чаще всего определяется как вероятность пребывания ПС в работоспособном состоянии при его функционировании. Наиболее краткое толкование термина надежность ПС в соответствии с последним подходом следующее: «Надежность ПС - это вероятность безотказного выполнения прогонов программ». Однако данное определение не раскрывает полностью физической сущности указанного свойства, а лишь задает один из возможных способов измерения его уровня.
Известен подход к надежности программного обеспечения, учитывающий специфику ПС как продукции производственно-технического назначения. Согласно такому подходу, надежность ПС - комплексное свойство, состоящее как и в случае технических объектов из набора характеристик. Это - корректность, устойчивость, восстанавливаемость и исправляемость ПС.
В зависимости от области приложения ПС влияние каждого из перечисленных свойств на интегральную характеристику надежности может быть различным. Так, для критичных к простоям вычислительным средствам (ВС) определяющим компонентом является восстанавливаемость ПС. (Иногда свойство восстанавливаемости программ полностью отождествляется с их надежностью). Однако наиболее общими из перечисленных составляющих надежности ПС следует считать корректность и устойчивость программ, так как остальные свойства, хотя и характеризуют потери от отказов ПС, но в большей мере зависят от внешних факторов, связанных с организацией функционирования ВС и обеспечением его поддержки. Эти две группы свойств проявляются в разномасштабных по времени процессах. Корректность и устойчивость ПС связаны с выполнением прогонов программы, т. е. процессами, измеряемыми, как правило, интервалами от долей до десятков (сотен) секунд. Восстанавливаемость и исправляемость (модифицируемость) обычно связаны с процессами, продолжительность которых составляет часы, сутки, месяцы и т. д. Поэтому в дальнейшем основное внимание уделяется свойствам корректности и устойчивости ПС. Тогда понятие надежность программного средства определим как его комплексное свойство правильно и своевременно выполнять предусмотренные спецификацией функции в процессе взаимодействия с операционной средой.
В понятие операционной среды функционирования ПС входит совокупность технических средств вычислительной системы, обрабатываемой информации и человека как эргатического элемента, реализующего диалог с ВС при выполнении вычислительного процесса.
Надежность аппаратуры определяется во многом случайными событиями, надежность программного обеспечения - скрытыми в нем ошибками.
Кривая надежности аппаратуры имеет характерные участки: участок, где отказы вызваны дефектами производства и сборки; период постоянной частоты отказов в течение времени полезной работы; период старения с резким ростом частоты отказов.
Кривая, описывающая изменение надежности программного обеспечения, отражает предположение, что при исправлении обнаруженных ошибок не вносятся новые. Это предположение обычно не справедливо.
Термин ошибка. Согласно одному из известных определений, программное обеспечение содержит ошибку, если его поведение не соответствует спецификациям. Это определение страдает существенным недостатком: неявно предполагается, что спецификации корректны. Такое предположение если и бывает справедливым, то редко; подготовка спецификаций -- один из основных источников ошибок. Если поведение программного продукта не соответствует его спецификациям, ошибка, вероятно, имеется. Однако, если система ведет себя в соответствии со спецификациями, мы не можем утверждать, что она не содержит ошибок.
Второе известное определение гласит, что программное обеспечение содержит ошибку, если его поведение не соответствует спецификациям при использовании в установленных при разработке пределах. В действительности это определение еще хуже первого. Если система случайно используется в непредусмотренной ситуации, ее поведение должно оставаться разумным. Если это не так, она содержит ошибку. Рассмотрим авиационную систему диспетчеризации, которая прослеживает и координирует движение самолетов над некоторым географическим районом. Предположим, что, согласно спецификациям, система должна управлять движением до 200 самолетов одновременно. Но однажды по непредвиденным обстоятельствам в районе появился 201 самолет. Если поведение системы неразумно -- скажем, она забывает об одном из самолетов или выходит из строя,-- система содержит ошибку, хотя она используется вне пределов, установленных при проектировании.
Согласно третьему возможному определению, ошибка имеется тогда, когда программное обеспечение ведет себя не в соответствии с официальной документацией и поставленными пользователю публикациями. К несчастью, это определение также страдает несколькими изъянами. Возможны ситуации, когда программное обеспечение ведет себя в соответствии с официальными публикациями, но ошибки все-таки имеются, так как они содержатся и в программе, и в публикациях. Другая проблема возникает вследствие тенденции описывать в руководствах для пользователей только ожидаемую и планируемую работу с системой. Предположим, что мы имеем руководство для пользователей системы разделения времени, в котором говорится: «Чтобы дать новую команду, нажмите один раз клавишу «внимание» и напечатайте эту команду». Предположим, что пользователь случайно нажимает клавишу «внимание» дважды и система программного обеспечения выходит из строя, потому что ее разработчики не предусмотрели такой ситуации. Система, очевидно, содержит ошибку, но мы не можем утверждать, что она ведет себя не в соответствии с публикациями.
Согласно последнему определению, которое также иногда используется, ошибка определяется как неспособность системы действовать в соответствии с исходным контрактом или перечнем требований пользователя. Хотя это определение лучше трех предыдущих, оно также не без недостатков. Если, согласно требованиям пользователя, система должна обеспечивать среднее время между отказами из-за ошибки в программном обеспечении на уровне 100 часов, а для действующей системы этот показатель равен 150 часам, система все же имеет ошибки (поскольку ее среднее время между отказами конечно), даже несмотря на то, что она превышает требования пользователя. Кроме того, письменно зафиксированные требования пользователя редко детализированы настолько, чтобы описывать желаемое поведение программного обеспечения при всех мыслимых обстоятельствах.
Есть, однако, разумное определение ошибки в программном обеспечении, разрешающее перечисленные выше проблемы:
В программном обеспечении имеется ошибка, если оно не выполняет того, что пользователю разумно от него ожидать. Отказ программного обеспечения -- это проявление ошибки в нем.
Я предвижу две разные реакции на это определение. Реакцией пользователя будет: «Точно!» Разработчик программного обеспечения может возразить: «Определение непрактично. Откуда мне знать, что пользователю разумно ожидать?» Дело в том, что если разработчик программного обеспечения хочет спроектировать удачную систему, то он всегда должен понимать, что именно ее пользователям «разумно ожидать».
Слово «разумно» употреблено в определении для того, чтобы исключить ситуации, когда, например, к терминалу информационно-поисковой системы публичной библиотеки подходит человек и просит определить объем своего вклада в местном банке. Под «пользователем» понимается любой человек, вводящий информацию в систему, исследующий выходные данные или взаимодействующий с системой каким-то иным образом. Большая система программного обеспечения (прикладные программы, операционная система, компиляторы, обслуживающие программы и т. д.) будет иметь много различных пользователей, в частности общающихся с системой через удаленные терминалы или по почте (зачастую это лица, не знакомые с вычислительными машинами или программированием). Кроме них, пользователями будут программисты (как системщики, так и прикладники) и операторы системы.
Еще одна особенность надежности программного обеспечения: ошибки в программном обеспечении не являются внутренним его свойством. Это значит, что, как бы долго и пристально мы ни разглядывали (или тестировали, или «доказывали») программу (либо программу и ее спецификации), мы никогда не сможем найти в ней все ошибки. Мы можем обнаружить некоторые ошибки (например, бесконечный цикл), но, по самой природе ошибок в программном обеспечении, мы никогда не можем рассчитывать найти их все. Коротко говоря, наличие ошибок -- функция как самого программного обеспечения, так и ожиданий его пользователей.
2. Показатели надежности
Под показателем надежности принято понимать величину или совокупность величин, характеризующих качественно или количественно степень приспособленности систем к выполнению поставленной задачи при применении по назначению. В практике проведения исследований вводятся в рассмотрение три вида показателей надежности сложных систем: качественные, порядковые и количественные.
Качественные показатели надежности -- это такие показатели, которые не могут быть выражены в виде числа и не содержат информации, позволяющей обосновать предпочтение одного из нескольких конкурирующих вариантов системы при их сравнении. Качественные показатели надежности указывают на то, что рассматриваемая система обладает каким-либо свойством для выполнения поставленной задачи. Качественные показатели дают возможность отличать системы друг от друга, но не позволяют сравнивать их по степени выполнения поставленной задачи, т. е. по надежности. Качественные аспекты и характеристики неизбежны при анализе любых систем, и их всегда необходимо учитывать. Однако часто при проведении исследований надежности анализ ограничивается исключительно качественными показателями. Такой подход сужает сферу применения методов исследования надежности систем и ограничивает значимость полученных результатов с помощью этой теории.
Порядковые показатели надежности -- это такие показатели, которые содержат информацию, позволяющую обосновывать предпочтение одного из вариантов системы при их сравнении без количественной оценки степени предпочтения. Порядковые показатели дают возможность расположить в ряд по степени возрастания надежности исследуемые варианты системы, но не позволяют оценить, на какую величину отличается достигнутый уровень надежности рассматриваемых вариантов. В результате исследования можно построить доминирующую последовательность вариантов системы путем их ранжирования, т. е. установления порядкового номера или ранга применительно к каждому варианту системы, указывающего его место среди других вариантов.
Количественные показатели надежности -- это такие показатели, которые содержат информацию, обеспечивающую оценку степени предпочтения одного варианта системы по отношению к другому при применении по назначению. Количественные показатели выражают надежность в виде числа: при помощи количественных показателей надежность измеряется или оценивается в принятой шкале оценок в абсолютных или относительных единицах. Количественные показатели определяются путем непосредственных статистических наблюдений на основе обработки результатов применения или испытания систем, а также путем аналитических расчетов или моделирования процесса функционирования систем. Они являются основными показателями надежности, обобщающими наиболее ценную информацию о степени приспособленности систем к применению по назначению.
В первых работах по теории надежности программного обеспечения заимствованы основные положения теории аппаратурной надежности и применена известная экспоненциальная формула функции надежности, выражающая вероятность безотказной работы за некоторый промежуток времени t. В ряде исследований вопроса надежности ПО показатель надежности рассматривался как функция времени наработки. Характерно, что ПО не изменяется существенно по мере наработки, а изменяется в результате устранения ошибок. Кроме того, вероятность отказа в работе не имеет прямого отношения к времени наработки. Зависимости для оценки надежности ПО могут быть непосредственно получены на основе свойств программы и элементарных понятий статистики.
В качестве исходных предпосылок используются следующие утверждения:
1) в результате выполнения программы для каждого множества входных данных получаем однозначный выходной результат;
2) множество входных данных определяет все вычисления, выполняемые программой;
3) каждая ошибка в программе вызывает сбои для некоторой части входных данных;
4) пропуск программы с некоторым подмножеством входных данных представляет собой единичное наблюдение ее действия.
Тогда вероятность Р появления сбоя есть вероятность того, что множество входных данных , выработанное для пропуска программы, таково, что порождает сбои. Р может быть выражено через вероятность выбора для работы множеств и переменную
=0, если выходной результат верен для ;
=1, в противном случае.
Вероятность безотказной работы ПО будет представлена как
(2.1)
где п -- число всевозможных входов ПО.
Надежность R для некоторого рабочего участка может быть определена как
(2.2)
Для получения вероятности отказа ПО экспериментальным путем можно применить следующий подход. Если испытывается определенное ПО относительно п различных входов и относительно l из них имеют место отказы, то вероятность отказа ПО оценивается как
(2.3)
При равномерном распределении испытуемых входов во входном множестве и при достаточно большом п
(2.4)
В обычном ПО входы во входном множестве вряд ли распределяются однородно, можно говорить только о некотором используемом множестве входов. В связи с этим устранение ошибок будет производиться именно в используемом множестве и таким образом вероятность отказа в этом множестве ниже, чем в полном множестве входов.
Далее рассмотрим входное множество и используемое множество . Вероятность отказа в определяется во время программирования, а вероятность отказа в определяется в соответствии с устранением ошибок. Предположим, что и как вероятности отказа в и соответственно постоянны. Тогда можно записать на основе эксперимента:
(2.5)
Предполагая, что т причин отказа устранено, можно записать значение вероятности отказа после устранения ошибок для некоторой промежуточной точки:
(2.6)
Здесь может быть получено на основании зависимости (2.5).
При полном устранении всех ошибок ПО становится надежным, т. е.
и (2.7)
Однако в процессе устранения ошибок могут быть внесены новые ошибки. Допускается, что если новые ошибки могут возникать с одинаковой вероятностью во входном множестве, то вероятность ошибок, возникающих в используемом множестве, может быть представлена в виде отношения .
Если предположить, что устранение одной ошибки вызывает К новых ошибок, то вероятность отказа после устранения m ошибок может быть представлена так.
(2.8)
Точка пересечения двух линий отражает состояние, когда за счет внесения дополнительных ошибок надежные характеристики программы не улучшаются, несмотря на то, что имеет место обнаружение и устранение ошибок. Однако в фактически отлаживаемой программе значение К. изменяется в окрестности точки пересечения и, следовательно, предполагается, что линии становятся кривыми (пунктир на рисунке) .
Программное обеспечение становится совершенным тогда, когда
(2.9)
т. е. в точке, где прямая линия b пересекает горизонтальную ось.
Наличие представленного выше механизма обеспечивает возможность предсказания развития процесса устранения ошибок. С точки зрения надежности ПО, чем меньше значение , тем быстрее можно провести устранение ошибок и тем выше будет надежность. Из уравнения (2.9) следует, что
(2.10)
Эту величину можно назвать «индексом оставшихся ошибок». Если степень устранения ошибок находится в диапазоне, обозначенном прямой линией Ь, то можно вычислить ряд количественных параметров надежности ПО и дать гарантию возможности его использования по назначению.
В качестве технических требований на разработку надежного ПО рекомендуются следующие критерии:
корректность программного обеспечения -- число серьезных ошибок в программе и время, необходимое для их устранения;
обслуживаемость системы -- степень влияния ошибок программного обеспечения на обслуживаемость системы;
безотказность системы -- частота системных отказов, вызываемых ошибками программного обеспечения.
С учетом сложившейся практики выбора критериев оценки надежности необходимо принимать во внимание следующее:
1) разработанное программное обеспечение в начальной стадии эксплуатации может потребовать менее жестких критериев и большего времени для его совершенствования;
2) после выпуска новой версии некоторое время потребуются также менее строгие критерии качества ПО;
3) имеют место разбросы, вызываемые различием в условиях применения и использования ПО;
4) эффективность работ по исправлению ошибок, проводимых разработчиками ПО, зависит от частоты проявления ошибок, что в свою очередь зависит от информации, поступающей от пользователя;
5) необходимость соблюдения ограничений по быстродействию и производительности, если таковые диктуются пользователем.
Таким образом, надежность ПО представляется через определение вероятности отказа в отношении входного множества данных и через наблюдение интенсивности изменения вероятности отказа по мере устранения ошибок. Приведенные показатели в силу их количественной интерпретации могут быть использованы в качестве стандартных оценок программного обеспечения.
3. Четыре подхода к надежности
Все принципы и методы обеспечения надежности в соответствии с их целью можно разбить на четыре группы: предупреждение ошибок, обнаружение ошибок, исправление ошибок и обеспечение устойчивости к ошибкам. К первой группе относятся принципы и методы, позволяющие минимизировать или вообще исключить ошибки. Методы второй группы сосредоточивают внимание на функциях самого программного обеспечения, помогающих выявлять ошибки. К третьей группе относятся функции программного обеспечения, предназначенные для исправления ошибок или их последствий. Устойчивость к ошибкам -- это мера способности системы программного обеспечения продолжать функционирование при наличии ошибок.
Предупреждение ошибок
К этой группе относятся принципы и методы, цель которых -- не допустить появления ошибок в готовой программе. Большинство методов концентрируется на отдельных процессах написания программы и направлено на предупреждение ошибок в этом процессе. Их можно разбить на следующие категории:
1. Методы, позволяющие справиться со сложностью, свести ее к минимуму, так как это -- главная причина ошибок.
2. Методы достижения большей точности.
3. Методы улучшения обмена информацией.
4. Методы немедленного обнаружения и устранения ошибок. Эти методы направлены на обнаружение ошибок, не откладывая до тестирования программы после ее написания.
Должно быть очевидно, что предупреждение ошибок -- оптимальный путь к достижению надежности программного обеспечения. Лучший способ обеспечить надежность -- прежде всего не допустить возникновения ошибок. Гарантировать отсутствие ошибок, однако, невозможно никогда. Другие три группы методов опираются на предположение, что ошибки все-таки будут.
Обнаружение ошибок
Если предполагать, что в программном обеспечении какие-то ошибки все же будут, то лучшая (после предупреждения ошибок) стратегия -- включить средства обнаружения ошибок в само программное обеспечение.
Большинство методов направлено по возможности на незамедлительное обнаружение сбоев. Немедленное обнаружение имеет два преимущества: можно минимизировать как влияние ошибки, так и последующие затруднения для человека, которому придется извлекать информацию об этой ошибке, находить ее место и исправлять.
Исправление ошибок
Следующий шаг -- методы исправления ошибок; после того как ошибка обнаружена, либо она сама, либо ее последствия должны быть исправлены программным обеспечением. Исправление ошибок самой системой -- плодотворный метод проектирования надежных систем аппаратного обеспечения. Некоторые устройства способны обнаружить неисправные компоненты и перейти к использованию идентичных запасных. Аналогичные методы неприменимы к программному обеспечению вследствие глубоких внутренних различий между сбоями аппаратуры и ошибками в программах. Если некоторый программный модуль содержит ошибку, идентичные «запасные» модули также будут содержать ту же ошибку.
Другой подход к исправлению связан с попытками восстановить разрушения, вызванные ошибками, например искажения записей в базе данных или управляющих таблицах системы. Польза от методов борьбы с искажениями ограниченна, поскольку предполагается, что разработчик заранее предугадает несколько возможных типов искажений и предусмотрит программно реализуемые функции для их устранения. Это похоже на парадокс, поскольку, если знать заранее, какие ошибки возникнут, можно было бы принять дополнительные меры по их предупреждению. Если методы ликвидации последствий сбоев не могут быть обобщены для работы со многими типами искажений, лучше всего направлять силы и средства на предупреждение ошибок. Вместо того чтобы, разрабатывая операционную систему, оснащать ее средствами обнаружения и восстановления цепочки искаженных таблиц или управляющих блоков, следовало бы лучше спроектировать систему так, чтобы только один модуль имел доступ к этой цепочке, а затем настойчиво пытаться убедиться в правильности этого модуля.
Устойчивость к ошибкам
Методы этой группы ставят своей целью обеспечить функционирование программной системы при наличии в ней ошибок. Они разбиваются на три подгруппы: динамическая избыточность, методы отступления и методы изоляции ошибок.
1. Истоки концепции динамической избыточности лежат в проектировании аппаратного обеспечения. Один из подходов к динамической избыточности -- метод голосования. Данные обрабатываются независимо несколькими идентичными устройствами, и результаты сравниваются. Если большинство устройств выработало одинаковый результат, этот результат и считается правильным. И опять, вследствие особой природы ошибок в программном обеспечении ошибка, имеющаяся в копии программного модуля, будет также присутствовать во всех других его копиях, поэтому идея голосования здесь, видимо, неприемлема. Предлагаемый иногда подход к решению этой проблемы состоит в том, чтобы иметь несколько неидентичных копий модуля. Это значит, что все копии выполняют одну и ту же функцию, но либо реализуют различные алгоритмы, либо созданы разными разработчиками. Этот подход бесперспективен по следующим причинам. Часто трудно получить существенно разные версии модуля, выполняющие одинаковые функции. Кроме того, возникает необходимость в дополнительном программном обеспечении для организации выполнения этих версий параллельно или последовательно и сравнения результатов. Это дополнительное программное обеспечение повышает уровень сложности системы, что, конечно, противоречит основной идее предупреждения ошибок -- стремиться в первую очередь минимизировать сложность.
Второй подход к динамической избыточности -- выполнять эти запасные копии только тогда, когда результаты, полученные с помощью основной копии, признаны неправильными. Если это происходит, система автоматически вызывает запасную копию. Если и ее результаты неправильны, вызывается другая запасная копия и т.д. Этот подход страдает большинством перечисленных ранее недостатков. Кроме того, вполне вероятно, что если ресурсы при работе над проектом фиксированы, то при реализации «запасных» версий проектированию и тестированию будет уделено меньше внимания, чем можно было бы уделить, если бы реализовывалась лишь одна копия и динамическая избыточность не использовалась.
2. Вторая подгруппа методов обеспечения устойчивости к ошибкам называется методами отступления или сокращенного обслуживания. Эти методы приемлемы обычно лишь тогда, когда для системы программного обеспечения существенно важно благопристойно закончить работу. Например, если ошибка оказывается в системе, управляющей технологическими процессами, и в результате эта система выходит из строя, то может быть загружен и выполнен особый фрагмент программы, призванный подстраховать систему и обеспечить безаварийное завершение всех управляемых системой процессов. Аналогичные средства часто необходимы в операционных системах. Если операционная система обнаруживает, что она вот-вот выйдет из строя, она может загрузить аварийный фрагмент, ответственный за оповещение пользователей у терминалов о предстоящем сбое и за сохранение всех критических для системы данных.
3. Последняя подгруппа -- методы изоляции ошибок. Основная их идея -- не дать последствиям ошибки выйти за пределы как можно меньшей части системы программного обеспечения, так чтобы если ошибка возникнет, то не вся система оказалась неработоспособной; отключаются лишь отдельные функции в системе либо некоторые ее пользователи. Например, во многих операционных системах изолируются ошибки отдельных пользователей, так что сбой влияет лишь на некоторое подмножество пользователей, а система в целом продолжает функционировать. В телефонных переключательных системах для восстановления после ошибки, чтобы не рисковать выходом из строя всей системы, просто разрывают телефонную связь. Другие методы изоляции ошибок связаны с защитой каждой из программ в системе от ошибок других программ. Ошибка в прикладной программе, выполняемой под управлением операционной системы, должна оказывать влияние только на эту программу. Она не должна сказываться на операционной системе или других программах, функционирующих в этой системе.
Из этих трех подгрупп методов обеспечения устойчивости к ошибкам только третья, изоляция ошибок, применима для большинства систем программного обеспечения.
Важное обстоятельство, касающееся всех четырех подходов, состоит в том, что обнаружение, исправление ошибок и устойчивость к ошибкам в некотором отношении противоположны методам предупреждения ошибок. В частности, обнаружение, исправление и устойчивость требуют дополнительных функций от самого программного обеспечения. Тем самым не только увеличивается сложность готовой системы, но и появляется возможность внести новые ошибки при реализации этих функций. Как правило, все рассматриваемые методы предупреждения и многие методы обнаружения ошибок применимы к любому программному проекту. Методы исправления ошибок и обеспечения устойчивости применяются не очень широко. Это, однако, зависит от области приложения. Если рассматривается, скажем, система реального времени, то ясно, что она должна сохранить работоспособность и при наличии ошибок, а тогда могут оказаться желательными и методы исправления и обеспечения устойчивости. К системам такого типа относятся телефонные переключательные системы, системы управления технологическими процессами, аэрокосмические и авиационные диспетчерские системы и операционные системы широкого назначения.
4. Обнаружение ошибок
Если мы исходим из предположения, что в программном обеспечении будут ошибки, то, очевидно, в первую очередь следует принять меры для их обнаружения. Более того, если необходимо принимать дополнительные меры (например, исправлять ошибки или их последствия), то все равно сначала нужно уметь обнаруживать ошибки.
Меры по обнаружению ошибок можно разбить на две подгруппы:
пассивные попытки обнаружить симптомы ошибки в процессе «обычной» работы программного обеспечения и активные попытки программной системы периодически обследовать свое состояние в поисках признаков ошибок.
Пассивное обнаружение ошибок
Меры по обнаружению ошибок могут быть приняты на нескольких структурных уровнях программной системы. Нас интересуют меры по обнаружению симптомов ошибок, предпринимаемые при переходе от одной компоненты к другой, а также внутри компоненты. Все это, конечно, применимо также к отдельным модулям внутри компоненты.
Разрабатывая эти меры, мы будем опираться на следующие положения:
1. Взаимное недоверие. Каждая из компонент должна предполагать, что все другие содержат ошибки. Когда она получает какие-нибудь данные от другой компоненты или из источника вне системы, она должна предполагать, что данные могут быть неправильными, и пытаться найти в них ошибки.
2. Немедленное обнаружение. Ошибки необходимо обнаружить как можно раньше. Это не только ограничивает наносимый ими ущерб, но и значительно упрощает задачу отладки.
3. Избыточность. Все средства обнаружения ошибок основаны на некоторой форме избыточности (явной или неявной).
Конкретные меры обнаружения сильно зависят от специфики прикладной области. Однако некоторые идеи можно почерпнуть из следующего списка:
1. Проверяйте атрибуты любого элемента входных данных. Если входные данные должны быть числовыми или буквенными, проверьте это. Если число на входе должно быть положительным, проверьте его значение. Если известно, какой должна быть длина входных данных, проверьте ее.
2. Применяйте «тэги» в таблицах, записях и управляющих блоках и проверяйте с их помощью допустимость входных данных. Тэг -- это поле записи, явно указывающее на ее назначение.
3. Проверяйте, находится ли входное значение в установленных пределах. Например, если входной элемент -- адрес в основной памяти, проверяйте его допустимость. Всегда проверяйте поле адреса или указателя на нуль и считайте, что оно неверно, если равно нулю. Если входные данные -- таблица вероятностей, проверьте, находятся ли все значения между нулем и единицей.
4. Проверяйте допустимость всех вариантов значений. Если входное поле -- код, обозначающий один из десяти районов, никогда не предполагайте, что если это не код ни одного из районов 1, 2, ..., 9, то это обязательно код района 10.
5. Если во входных данных есть какая-либо явная избыточность, воспользуйтесь ею для проверки данных.
6. Там, где во входных данных нет явной избыточности, введите ее. Если ваша система использует крайне важную таблицу, подумайте о включении в нее контрольной суммы. Всякий раз, когда таблица обновляется, следует просуммировать (по некоторому модулю) ее поля и результат поместить в специальное поле контрольной суммы. Подсистема, использующая таблицу, сможет теперь проверить, не была ли таблица случайно испорчена,-- для этого только нужно выполнить контрольное суммирование.
7. Сравнивайте, согласуются ли входные данные с какими-либо внутренними данными. Если на входе операционной системы возникает требование освободить некоторый блок памяти, она должна убедиться, что этот блок в данный момент действительно занят.
Когда разрабатываются меры по обнаружению ошибок, важно принять согласованную стратегию для всей системы (т. е. применить идею концептуальной целостности). Действия, предпринимаемые после обнаружения ошибки в программном обеспечении (например, возврат кода ошибки), должны быть единообразными для всех компонент системы. Это ставит вопрос о том, какие именно действия следует предпринять, когда ошибка обнаружена. Наилучшее решение -- немедленно завершить выполнение программы или (в случае операционной системы) перевести ЦП в состояние ожидания. С точки зрения предоставления человеку, отлаживающему программу, например системному программисту, самых благоприятных условий для диагностики ошибок немедленное завершение представляется наилучшей стратегией. Конечно, во многих системах подобная стратегия бывает нецелесообразной (например, может оказаться, что приостанавливать работу системы нельзя). В таком случае используется метод регистрации ошибок. Описание симптомов ошибки и «моментальный снимок» состояния системы сохраняется во внешнем файле, после чего система может продолжать работу. Этот файл позднее будет изучен обслуживающим персоналом. Такой метод использован в операционной системе OS/VS2MVS фирмы IBM. Каждая компонента содержит программу восстановления, которая перехватывает все случаи ненормального завершения и программные прерывания в этой компоненте и регистрирует данные об ошибке во внешнем файле.
Всегда, когда это возможно, лучше приостановить выполнение программы, чем регистрировать ошибки (либо обеспечить как дополнительную возможность работу системы в любом из этих режимов). Различие между этими методами проиллюстрируем на способах выявления причин возникающего иногда скрежета вашего автомобиля. Если автомеханик находится на заднем сиденье, то он может обследовать состояние машины в тот момент, когда скрежет возникает. Если же вы выбираете метод регистрации ошибок (записывая скрежет на магнитофон), задача диагностики будет значительно сложнее.
Пример: система PRIME
Система PRIME -- это мультипроцессорная система с виртуальной памятью, разработанная в Калифорнийском университете в Беркли. Один из процессоров системы выделен в качестве центрального процессора и содержит центральный управляющий монитор (ССМ -- central control monitor) -- управляющую программу, которая распределяет страницы памяти и пространство на диске, назначает программы другим процессорам (проблемным процессорам) и регулирует пересылки всех межпроцессорных сообщений. Расширенный управляющий монитор (ЕСМ -- extended control monitor) -- это реализованная микропрограммно управляющая программа, постоянно присутствующая в каждом процессоре и управляющая диспетчеризацией процессов, операциями ввода-вывода и посылки/получения.
Защита данных -- одна из основных целей системы. В этом направлении в системе PRIME сделан шаг вперед по сравнению с большинством других систем: в дополнение к обеспечению защиты в нормальных условиях ставится цель гарантировать защиту даже при наличии отдельной ошибки в программном обеспечении или отдельного сбоя аппаратуры. Меры по обнаружению ошибок составляют основу метода достижения этой цели. программный мультипроцессорный виртуальный
Во время разработки системы PRIME были явно выделены все принимаемые операционной системой решения, ошибки в которых могут привести к тому, что данные одного пользователя станут доступными другому пользователю или его программе. Были реализованы средства обнаружения ошибок для каждого из этих решений.
Многие из них представляют собой комбинацию аппаратных и программных средств. Например, всякий раз, когда процессу пользователя выделяется терминал, ССМ запоминает идентификатор этого процесса в регистре терминала. Когда ЕСМ посылает данные на терминал, тот всегда сравнивает хранимый идентификатор с идентификатором при посланных данных. Последнее гарантирует, что отдельная ошибка в программном обеспечении или сбой аппаратуры не приведут к печати данных не на том терминале.
Система PRIME содержит механизм посылки/получения, который позволяет процессу одного пользователя послать сообщение процессу другого пользователя. Для этого процесс-отправитель передает своему ЕСМ это сообщение и идентификатор процесса-получателя. ЕСМ добавляет идентификатор отправителя и передает сообщение ССМ. Тот передает сообщение ЕСМ процессора, содержащего процесс-получатель, а ЕСМ наконец передает сообщение указанному процессу пользователя. В этой последовательности выполняются три проверки с целью обнаружения ошибки. ССМ проверяет, правильный ли идентификатор процесса-отправителя добавлен ЕСМ; он может это сделать, поскольку известно, какому пользователю выделен процессор. ЕСМ адресата проверяет, тому ли процессору ССМ направил сообщение; он выполняет это, сравнивая идентификатор процесса в сообщении с идентификатором процесса, которому в данный момент выделен процессор. Третья проверка делается для обеспечения сохранности сообщения при транзите. ЕСМ-отправитель формирует для сообщения контрольную сумму и передает ее вместе с сообщением. ЕСМ-получатель вычисляет контрольную сумму доставленного сообщения и сравнивает с извлеченной из сообщения.
Система PRIME.
В качестве примера другой проверки отметим, что ССМ распределяет свободные страницы памяти между процессами пользователей и хранит список свободных страниц. Когда страница больше не нужна ЕСМ, он помечает ее и сообщает ССМ, чтобы тот включил ее в список свободных. Получая очередную выделенную страницу, ЕСМ проверяет пометку на ней, чтобы убедиться, что страница действительно свободна. Эта избыточность может быть использована для обнаружения ошибок, потому что список свободных страниц обрабатывается ССМ, а помечают страницы другие процессоры.
Активное обнаружение ошибок
Не все ошибки можно выявить пассивными методами, поскольку эти методы обнаруживают ошибку лишь тогда, когда ее симптомы подвергаются соответствующей проверке. Можно делать и дополнительные проверки, если спроектировать специальные программные средства для активного поиска признаков ошибок в системе. Такие средства называются средствами активного обнаружения ошибок.
Активные средства обнаружения ошибок обычно объединяются в диагностический монитор: параллельный процесс, который периодически анализирует состояние системы с целью обнаружить ошибку. Большие программные системы, управляющие ресурсами, часто содержат ошибки, приводящие к потере ресурсов на длительное время. Например, управление памятью операционной системы сдает блоки памяти «в аренду» программам пользователей и другим частям операционной системы. Ошибка в этих самых «других частях» системы может иногда вести к неправильной работе блока управления памятью, занимающегося возвратом сданной ранее в аренду памяти, что вызывает медленное вырождение системы.
Диагностический монитор можно реализовать как периодически выполняемую задачу (например, она планируется на каждый час) либо как задачу с низким приоритетом, которая планируется для выполнения в то время, когда система переходит в состояние ожидания. Как и прежде, выполняемые монитором конкретные проверки зависят от специфики системы, но некоторые идеи будут понятны из примеров. Монитор может обследовать основную память, чтобы обнаружить блоки памяти, не выделенные ни одной из выполняемых задач и не включенные в системный список свободной памяти. Он может проверять также необычные ситуации: например, процесс не планировался для выполнения в течение некоторого разумного интервала времени. Монитор может осуществлять поиск «затерявшихся» внутри системы сообщений или операций ввода-вывода, которые необычно долгое время остаются незавершенными, участков памяти на диске, которые не помечены как выделенные и не включены в список свободной памяти, а также различного рода странностей в файлах данных.
Иногда желательно, чтобы в чрезвычайных обстоятельствах монитор выполнял диагностические тесты системы. Он может вызывать определенные системные функции, сравнивая их результат с заранее определенным и проверяя, насколько разумно время выполнения. Монитор может также периодически предъявлять системе «пустые» или «легкие» задания, чтобы убедиться, что система функционирует хотя бы самым примитивным образом.
Пример: программа обнаружения разрушений, разработанная фирмой TRW
Система защиты ресурсов фирмы IBM -- это экспериментальная модификация операционной системы OS/360 для изучения проблем, связанных с системами защиты. Используя ее, корпорация TRW разработала монитор, действующий в заранее установленные интервалы времени и пытающийся обнаружить признаки того, что программа пользователя нарушила правила защиты.
Этот монитор проверяет много различных условий. Большинство из них характерно именно для OS/360 и поэтому интересны не для всех. В качестве некоторых примеров, можно, однако, указать, что монитор определяет, вся ли управляющая информация OS/3CO о задачах пользователя хранится в защищенной области памяти. Монитор также проверяет, всели программы пользователя выполняются в режиме задачи и вся ли память пользователя защищена от выборки соответствующим ключом защиты. Монитор контролирует правильность соблюдения очереди ожидающими операциями ввода-вывода и гарантирует, что точки входа для всех прерываний являются соответствующими входами OS/360 и что вся память супервизора надлежащим образом защищена. Как только обнаруживается какое-то несоответствие, немедленно выдается сообщение оператору.
5. Исправление ошибок и устойчивость к ошибкам
Имея средства обнаружения ошибок в программном обеспечении, естественно предпринять следующий шаг, попробовать создать средства, нацеленные на исправление обнаруженных ошибок. По существу, термин «исправление ошибок» в применении к программному обеспечению означает ликвидацию ущерба, нанесенного ошибкой, а не исправление самой ошибки. Исправление ошибки в аппаратуре (например, автоматическим переключением на запасное устройство) -- вполне жизнеспособный прием, но пытаться исправить настоящую ошибку в программном обеспечении без участия человека бесполезно. Самое большее, что можно сделать в этом случае,-- свести на нет ущерб, нанесенный ошибкой. Самое большее, что можно сделать по части устойчивости к ошибкам, -- либо сделать нанесенный ущерб незаметным, либо изолировать его лишь в рамках части системы.
Хотя методы исправления/устойчивости и имели ограниченный успех в нескольких системах, в большинстве случаев их лучше избегать. Число возможных ошибок в большой системе так велико, что может считаться практически бесконечным. Разрабатывая методы исправления/устойчивости, мы вынуждены пытаться предугадать лишь несколько типов ошибок, чтобы реализовать средства, предназначенные для борьбы с ущербом от этих ошибок. В лучшем случае наша система будет исправлять ничтожный процент своих потенциальных ошибок. К тому же эти средства сами довольно сложны, так что благодаря им исходное количество ошибок в системе только возрастет. Более того, они сами будут, несомненно, содержать ошибки. Наконец, если некоторые средства исправления/устойчивости все-таки заработают, они тем самым станут маскировать ошибки (делая их менее заметными), и последние, возможно, никогда не будут устранены обслуживающим персоналом, а это -- явно нежелательное следствие.
Однако самым сильным доводом против исправления ошибок и обеспечения устойчивости остается следующий аргумент. Поскольку все равно необходимо заранее предвидеть несколько возможных ошибок, обычно лучше при проектировании и тестировании направлять все усилия на их устранение.
Пример: система обслуживания телефонных станций TSPS фирмы «Белл»
Система TSPS фирмы «Белл» демонстрирует некоторые примеры методов исправления ошибок и обеспечения устойчивости. Система предназначена для обслуживания телефонной сети, поэтому на нее накладываются строгие требования в отношении постоянной готовности: суммарное время простоя системы из-за отказов не должно превышать двух часов за 40 лет. В TSPS полный выход системы из строя -- серьезное событие, в то время как такие случайные сбои, как разрыв телефонной связи, вполне допустимы. Отметим, что во многих системах требования прямо противоположны. Например, в системе обработки банковских чеков выход системы из строя менее серьезен, чем ошибка в данных.
В TSPS применяются и пассивные, и активные методы обнаружения ошибок и средства исправления ошибок для сокращения числа сбоев системы. Основной принцип состоит в обнаружении определенных типов ошибок по возможности раньше, поскольку в противном случае их воздействие быстро распространится по всей системе и система в конце концов выйдет из строя. При" исправлении последствий этих ошибок утрата некоторых данных допустима, если такова цена за сохранение работоспособности системы.
Телефонная сеть представлена таблицами в основной памяти, которые хранятся как множество связанных линейных списков. Например, каждый блок имеет свой тэг, последний блок определяется по двум признакам, и в поле состояния каждого блока в этом списке должно быть установлено значение «активно». Монитор (называемый в TSPS audit program) периодически просматривает списки. Если обнаруживается противоречие, например в поле СЛЕДУЮЩИЙ некоторого блока указан неправильный адрес (что обнаруживается по несоответствию тэга блока, находящегося по этому адресу), то список обрывается после последнего правильного блока и в каждом правильном блоке значение бита L (от английского слова lost -- потеряно) устанавливается равным 1. Другая компонента монитора периодически просматривает последовательно блоки всех линий. Если бит L блока равен 0 (что значит, что он «потерян»), блок включается в список незанятых линий соответствующего типа. Эти действия могут привести к разрыву телефонной связи, но сохраняют работоспособность всей системы.
Многие линии имеют также в своих блоках бит «тайм-аут». Монитор использует этот бит, чтобы определить, не была ли линия занята в течение необычно долгого периода времени. Если это так, то после дополнительных проверок линия может быть переведена в свободное состояние. Если монитор обнаруживает, что система находится в хаотическом состоянии, он имеет возможность запустить ее заново. Монитор также регистрирует все обнаруженные ошибочные ситуации для последующей отладки.
Механизм исправления ошибок в TSPS ежедневно исправляет довольно много ошибок. Установка TSPS после трех лет работы выполняет в среднем от 10 до 100 реальных исправлений в день и примерно раз в два месяца -- автоматический повторный запуск.
6. Изоляция ошибок
В большой вычислительной системе изоляция программ является ключевым фактором, гарантирующим, что отказы в программе одного пользователя не приведут к отказам в программах других пользователей или к полному выводу системы из строя. Основные правила изоляции ошибок перечислены ниже. Хотя в формулировке многих из них употребляются слова «операционная система», они применимы к любой программе (будь то операционная система, монитор телеобработки или подсистема управления файлами), которая занята обслуживанием других программ.
1. Прикладная программа не должна иметь возможности непосредственно ссылаться на другую прикладную программу или данные в другой программе и изменять их.
2. Прикладная программа не должна иметь возможности непосредственно ссылаться на программы или данные операционной системы и изменять их. Связь между двумя программами (или программой и операционной системой) может быть разрешена только при условии использования четко определенных сопряжении и только в случае, когда обе программы дают согласие на эту связь.
3. Прикладные программы и их данные должны быть защищены от операционной системы до такой степени, чтобы ошибки в операционной системе не могли привести к случайному изменению прикладных программ или их данных.
4. Операционная система должна защищать все прикладные программы и данные от случайного их изменения операторами системы или обслуживающим персоналом.
5. Прикладные программы не должны иметь возможности ни остановить систему, ни вынудить ее. изменить другую прикладную программу или ее данные.
6. Когда прикладная программа обращается к операционной системе, должна проверяться допустимость всех параметров. Более того, прикладная программа не должна иметь возможности изменить эти параметры между моментами проверки и реального их использования операционной системой.
7. Никакие системные данные, непосредственно доступные прикладным программам, не должны влиять на функционирование операционной системы. Например, OS/360 хранит некоторые блоки, управляющие распределением памяти, в областях основной памяти, доступных прикладным программам. Ошибка в прикладной программе, вследствие которой содержимое этой памяти может быть случайно изменено, приводит в конце концов к сбою системы.
...Подобные документы
Программное обеспечение как продукт. Основные характеристик качества программного средства. Основные понятия и показатели надежности программных средств. Дестабилизирующие факторы и методы обеспечения надежности функционирования программных средств.
лекция [370,1 K], добавлен 22.03.2014Постановка проблемы надежности программного обеспечения и причины ее возникновения. Характеристики надежности аппаратуры. Компьютерная программа как объект исследования, ее надежность и правильность. Модель последовательности испытаний Бернулли.
реферат [24,8 K], добавлен 21.12.2010Проблема надежности программного обеспечения, ее показатели и факторы обеспечения. Методы контроля процесса разработки программ и документации, предупреждение ошибок. Этапы процесса отладки ПО, приемы структурного программирования и принцип модульности.
презентация [379,5 K], добавлен 30.04.2014Действия, которые выполняются при проектировании АИС. Кластерные технологии, их виды. Методы расчета надежности на разных этапах проектирования информационных систем. Расчет надежности с резервированием. Испытания программного обеспечения на надежность.
курсовая работа [913,7 K], добавлен 02.07.2013Надежность системы управления как совокупность надежности технических средств, вычислительной машины, программного обеспечения и персонала. Расчет надежности технических систем, виды отказов САУ и ТСА, повышение надежности и причины отказов САУ.
курс лекций [228,2 K], добавлен 27.05.2008Написание программы, реализующей работу мультипроцессорной системы с общей памятью, которая обрабатывает очереди заявок переменной длины. Анализ типовой архитектуры мультипроцессорной системы. Описание процедур и переменных, используемых в программе.
курсовая работа [158,4 K], добавлен 21.06.2013Модель надежности программного средства как математическая модель для оценки зависимости надежности программного обеспечения от некоторых определенных параметров, анализ видов. Общая характеристика простой интуитивной модели, анализ сфер использования.
презентация [151,1 K], добавлен 22.03.2014Надежность как характеристика качества программного обеспечения (ПО). Методика расчета характеристик надежности ПО (таких как, время наработки до отказа, коэффициент готовности, вероятность отказа), особенности прогнозирования их изменений во времени.
дипломная работа [1,2 M], добавлен 01.06.2010Основные составляющие функциональной надежности программных средств: безотказность, работоспособность, защищенность. Рассмотрение характеристик, которые позволяют оценивать программные средства с позиции пользователя, разработчика и управляющего проектом.
презентация [220,5 K], добавлен 16.10.2013Концепция построения виртуальной лаборатории (ВЛ) "Программирование микроконтроллерных систем". Принцип построения лабораторного практикума. Архитектура аппаратного обеспечения ВЛ. Аппаратные способы реализации генератора сигналов произвольной формы.
магистерская работа [669,4 K], добавлен 29.06.2009Структуры вычислительных машин и систем. Фон-неймановская архитектура, перспективные направления исследований. Аналоговые вычислительные машины: наличие и функциональные возможности программного обеспечения. Совокупность свойств систем для пользователя.
курсовая работа [797,5 K], добавлен 05.11.2011Основные виды программного обеспечения: системное (операционные, сервисные и диагностические системы, инструментальные средства) и прикладное (текстовые, табличные, математические процессоры, графические редакторы). Классификация операционных систем.
презентация [282,5 K], добавлен 13.08.2013Ошибки, которые воздействуют на программное обеспечение и методы прогнозирования программных отказов. Анализ моделей надежности программного обеспечения и методика оценки ее надежности. Экспоненциальное распределение. Методика оценки безотказности.
курсовая работа [71,5 K], добавлен 15.12.2013Исследование объектно-ориентированного подхода к проектированию программного обеспечения будильника. Модель программного обеспечения. Взаимодействие между пользователями и системой. Диаграммы и генерация программного кода при помощи средств Rational Rose.
курсовая работа [355,8 K], добавлен 26.09.2014Изучение основных видов угроз программного обеспечения. Выявление наиболее эффективных средств и методов защиты программного обеспечения. Анализ их достоинств и недостатков. Описания особенностей лицензирования и патентования программного обеспечения.
курсовая работа [67,9 K], добавлен 29.05.2013Запросы клиента по области возможных запросов к серверу. Программа для прогнозирования поведения надежности программного обеспечения на основе метода Монте-Карло. Влияние количества программ-клиентов на поведение программной системы клиент-сервера.
контрольная работа [705,3 K], добавлен 03.12.2010Функции операционной системы как совокупности программных средств, осуществляющих управление ресурсами электронно-вычислительных машин. Предназначение Windows, Linux и Mac. Особенности реализации алгоритмов управления основными ресурсами компьютера.
реферат [22,5 K], добавлен 16.03.2017Информатизация России. Рынок программных средств. Основные задачи стандартизации, сертификации и лицензирования в сфере информатизации. Совокупность инженерных методов и средств создания программного обеспечения. Жизненный цикл программного обеспечения.
лекция [352,8 K], добавлен 09.03.2009Методика исследования и анализа средств аудита системы Windows с целью обнаружения несанкционированного доступа программного обеспечения к ресурсам вычислительных машин. Анализ угрозы информационной безопасности. Алгоритм работы программного средства.
дипломная работа [2,9 M], добавлен 28.06.2011Классификация служебных программных средств. Файловая структура операционных систем. Основы графического интерфейса пользователя Windows XX. Анализ алгоритмов решения задач. Описание процесса разработки программного обеспечения и результатов работы.
курсовая работа [2,4 M], добавлен 14.11.2016
