Глава 1. качество и метрики программного обеспечения. — КиберПедия 

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

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

Глава 1. качество и метрики программного обеспечения.

2019-12-17 1512
Глава 1. качество и метрики программного обеспечения. 0.00 из 5.00 0 оценок
Заказать работу

Оглавление

Введение. 3

Глава 1. качество и метрики программного обеспечения. 4

1.1 Понятие качества. 4

1.2 метрики.. 5

1.3 основные направления применения метрики.. 9

1.4 Метрические шкалы.. 10

Глава 2. метрология программного обеспечения.. 11

2.1 метрики сложности программ.. 11

2.2 Объектно-ориентированные метрики.. 12

2.3 Альтернативные подходы к измерению качества.. 13

2.4 Вычисление метрик сложности.. 15

заключение.. 16

Список использованных источников и литературы.. 17

 


Введение

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

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


 

Глава 1. качество и метрики программного обеспечения.

Понятие качества.

На протяжении многих лет отдельные авторы и целые организации определяли термин “качество” по-разному. Фил Кросби в 1979 году дал определение качеству как “соответствие пользовательским требованиям”. Уотс Хемпфри описывает качество как “достижение отличного уровня пригодности к использованию”. Компания IBM, в свою очередь, ввела в оборот фразу “качество, управляемое рыночными потребностями”. Критерий Бэлдриджа для организационного качества использует похожую фразу - “качество, задаваемое потребителем”, рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества. Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ИСО 9001 как “степень соответствия присущих характеристик требованиям”.

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

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

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

Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств.

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

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

Метрики

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

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

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

Согласно стандарту метрики, определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе функционирования (внешние метрики) продукта.

Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества.

В исследовании метрик ПО различают два основных направления:

-поиск метрик, характеризующих наиболее специфические свойства программ, т.е. метрик оценки самого ПО;

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

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

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

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

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

Существует три типа метрик:

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

-метрики процесса, которые используются при измерении свойства процесса ЖЦ создания продукта.

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

Метрики программного продукта включают

-внешние метрики, обозначающие свойства продукта, видимые пользователю;

-внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта - это метрики:

-надежности продукта, которые служат для определения числа дефектов;

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

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

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

Внутренние метрики продукта включают:

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

-метрики сложности, необходимые для определения сложности продукта;

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

Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.

Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта.

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

-требований;

-сценариев и действующих лиц;

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

-параметров и операций объекта и др.

Стандарт ISO/IEC 9126-2 определяет следующие типы мер:

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

-мера времени (функционирования системы, выполнения компонента и др.);

-мера усилий (производительность труда, трудоемкость и др.);

-мера учета (количество ошибок, число отказов, ответов системы и др.).

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

-общее число объектов и число повторно используемых;

-общее число операций, повторно используемых и новых операций;

-число классов, наследующих специфические операции;

-число классов, от которых зависит данный класс;

-число пользователей класса или операций и др.

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

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

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

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

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

-общее время разработки и отдельно время для каждой стадии;

-время модификации моделей;

-время выполнения работ на процессе;

-число найденных ошибок при инспектировании;

-стоимость проверки качества;

-стоимость процесса разработки.

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

Метрические шкалы

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

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

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

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

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

-Абсолютная шкала указывает на фактическое значение величины.

Метрики сложности программ

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

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

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

· метрики размера программ

· метрики сложности потока управления программ

· и метрики сложности потока данных программ

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

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

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

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

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

Вычисление метрик сложности

Verisoft Complexity Measures Tool - коммерческий продукт с достаточно внушительной ценой в 1200 евро. Поддерживаются только языки C/C++ и Java.

С помощью этого продукта можно рассчитывать следующие метрики: SLOC, цикломатическую сложность, метрики Холстеда, индекс сопровождаемости. Имеет графический интерфейс, позволяет формировать отчеты в текстовой форме или HTML.

Borland Together - коммерческий инструмент UML-моделирования, дополненный возможностями вычисления метрик исходного кода. Цена зависит от редакции (начиная с $200).

Поддерживается обширное число различных метрик, значительная часть которых - объект-но-ориентированные: SLOC, количественные метрики классов (число атрибутов, классов, конструкторов, операций), цикломатическая сложность, метрики сложности классов (LOCOM1, LOCOM2, LOCOM3, WMPC1, WMPC2, NORM), метрики связности, Холстеда, наследования, полиморфизма, процентные соотношения, максимальные значения.

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

Вычисляет SLOC, количественные метрики классов, цикломатическую сложность, метрики сложности классов (LOCOM1, LOCOM2, LOCOM3, WMPC, NORM, индекс специализации), метрики связности, уровень абстракции и некоторые другие.Достаточно функциональный продукт, который вполне может дать фору многим коммерческим аналогам.

заключение

 

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

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

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


 

Оглавление

Введение. 3

Глава 1. качество и метрики программного обеспечения. 4

1.1 Понятие качества. 4

1.2 метрики.. 5

1.3 основные направления применения метрики.. 9

1.4 Метрические шкалы.. 10

Глава 2. метрология программного обеспечения.. 11

2.1 метрики сложности программ.. 11

2.2 Объектно-ориентированные метрики.. 12

2.3 Альтернативные подходы к измерению качества.. 13

2.4 Вычисление метрик сложности.. 15

заключение.. 16

Список использованных источников и литературы.. 17

 


Введение

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

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


 

Глава 1. качество и метрики программного обеспечения.

Понятие качества.

На протяжении многих лет отдельные авторы и целые организации определяли термин “качество” по-разному. Фил Кросби в 1979 году дал определение качеству как “соответствие пользовательским требованиям”. Уотс Хемпфри описывает качество как “достижение отличного уровня пригодности к использованию”. Компания IBM, в свою очередь, ввела в оборот фразу “качество, управляемое рыночными потребностями”. Критерий Бэлдриджа для организационного качества использует похожую фразу - “качество, задаваемое потребителем”, рассматривая удовлетворение потребителя в качестве главного соображения в отношении качества. Чаще, понятие качества используется в соответствии с определением системы менеджмента качества ИСО 9001 как “степень соответствия присущих характеристик требованиям”.

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

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

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

Определение IEEE: Качество программного обеспечения - это степень, в которой оно обладает требуемой комбинацией свойств.

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

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

Метрики

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

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

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

Согласно стандарту метрики, определяются по модели измерения атрибутов ПО на всех этапах ЖЦ (промежуточная, внутренняя метрика) и особенно на этапе функционирования (внешние метрики) продукта.

Метрика качества программ - система измерений качества программ. Эти измерения могут проводиться на уровне критериев качества программ или на уровне отдельных характеристик качества.

В исследовании метрик ПО различают два основных направления:

-поиск метрик, характеризующих наиболее специфические свойства программ, т.е. метрик оценки самого ПО;

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

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

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

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

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

Существует три типа метрик:

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

-метрики процесса, которые используются при измерении свойства процесса ЖЦ создания продукта.

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

Метрики программного продукта включают

-внешние метрики, обозначающие свойства продукта, видимые пользователю;

-внутренние метрики, обозначающие свойства, видимые только команде разработчиков.

Внешние метрики продукта - это метрики:

-надежности продукта, которые служат для определения числа дефектов;

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

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

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

Внутренние метрики продукта включают:

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

-метрики сложности, необходимые для определения сложности продукта;

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

Внутренние метрики позволяют определить производительность продукта и являются релевантными по отношению к внешним метрикам.

Внешние и внутренние метрики задаются на этапе формирования требований к ПО и являются предметом планирования и управления достижением качества конечного программного продукта.

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

-требований;

-сценариев и действующих лиц;

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

-параметров и операций объекта и др.

Стандарт ISO/IEC 9126-2 определяет следующие типы мер:

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

-мера времени (функционирования системы, выполнения компонента и др.);

-мера усилий (производительность труда, трудоемкость и др.);

-мера учета (количество ошибок, число отказов, ответов системы и др.).

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

-общее число объектов и число повторно используемых;

-общее число операций, повторно используемых и новых операций;

-число классов, наследующих специфические операции;

-число классов, от которых зависит данный класс;

-число пользователей класса или операций и др.

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

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

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

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

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

-общее время разработки и отдельно время для каждой стадии;

-время модификации моделей;

-время выполнения работ на процессе;

-число найденных ошибок при инспектировании;

-стоимость проверки качества;

-стоимость процесса разработки.

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


Поделиться с друзьями:

Состав сооружений: решетки и песколовки: Решетки – это первое устройство в схеме очистных сооружений. Они представляют...

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

История создания датчика движения: Первый прибор для обнаружения движения был изобретен немецким физиком Генрихом Герцем...

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



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.115 с.