|
@@ -0,0 +1,549 @@
|
|
|
|
|
+ Тест по МДК 02.02 <<Инструментальные средства разработки ПО>>
|
|
|
|
|
+
|
|
|
|
|
+С точки зрения пользователя программного обеспечения качество последнего заключается в
|
|
|
|
|
+легкости эксплуатации
|
|
|
|
|
+
|
|
|
|
|
+модификации
|
|
|
|
|
+
|
|
|
|
|
+Безотказности
|
|
|
|
|
+
|
|
|
|
|
+Производительности
|
|
|
|
|
+
|
|
|
|
|
+воспроизводимости
|
|
|
|
|
+Когда система передана заказчику, начинается этап
|
|
|
|
|
+кодирования
|
|
|
|
|
+
|
|
|
|
|
+тестирования
|
|
|
|
|
+
|
|
|
|
|
+Эксплуатации
|
|
|
|
|
+
|
|
|
|
|
+верификации
|
|
|
|
|
+
|
|
|
|
|
+анализа
|
|
|
|
|
+Среди уровней абстракции стадий проектирования различают
|
|
|
|
|
+способы проектирования
|
|
|
|
|
+
|
|
|
|
|
+специфика дизайна системы
|
|
|
|
|
+
|
|
|
|
|
+детальное кодирование
|
|
|
|
|
+
|
|
|
|
|
+атрибуты и требования приложений
|
|
|
|
|
+
|
|
|
|
|
+стандарты разработки
|
|
|
|
|
+Для достижения модульности программного обеспечения программный инженер должен проектировать модули стараясь обеспечить следующие типы связности
|
|
|
|
|
+высокую межмодульную
|
|
|
|
|
+
|
|
|
|
|
+высокую внутримодульную
|
|
|
|
|
+
|
|
|
|
|
+Инкапсуляцию
|
|
|
|
|
+
|
|
|
|
|
+низкую межмодульную
|
|
|
|
|
+
|
|
|
|
|
+низкую внутримодульную
|
|
|
|
|
+Недостаток использования оценки работы по размеру кода связан с
|
|
|
|
|
+квалификацией разработчиков
|
|
|
|
|
+
|
|
|
|
|
+сложностью подсчета
|
|
|
|
|
+
|
|
|
|
|
+сложностью реализации
|
|
|
|
|
+
|
|
|
|
|
+его субъективностью
|
|
|
|
|
+
|
|
|
|
|
+Относительностью
|
|
|
|
|
+Стратегии тестирования - это в технологии проектирования
|
|
|
|
|
+формы поиска ошибок
|
|
|
|
|
+
|
|
|
|
|
+формы стимулирования разработчиков
|
|
|
|
|
+
|
|
|
|
|
+формальные требования к программному обеспечению со стороны пользователя
|
|
|
|
|
+
|
|
|
|
|
+предписанные заказчиком правила оценки программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+определенные критерии выбора значимых контрольных примеров
|
|
|
|
|
+UML - это
|
|
|
|
|
+оболочка высокоуровневого языка программирования
|
|
|
|
|
+
|
|
|
|
|
+группа разработчиков программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+язык моделирования программных систем
|
|
|
|
|
+
|
|
|
|
|
+формат общения <<разработчик>> -- <<заказчик>>
|
|
|
|
|
+
|
|
|
|
|
+методика построения модулей
|
|
|
|
|
+При тестировании методом черного ящика используются следующие критерии
|
|
|
|
|
+покрытия операторов
|
|
|
|
|
+
|
|
|
|
|
+синтаксического управляющего тестирования
|
|
|
|
|
+
|
|
|
|
|
+покрытия ребер
|
|
|
|
|
+
|
|
|
|
|
+покрытия условий
|
|
|
|
|
+
|
|
|
|
|
+управления логическими спецификациями
|
|
|
|
|
+
|
|
|
|
|
+графа причин и следствий
|
|
|
|
|
+Отношение обратное отношению Mi IS_COMPONENT_OF Mj выглядит как
|
|
|
|
|
+Mi COMPRISES Mj
|
|
|
|
|
+
|
|
|
|
|
+Mj COMPRISES Mi
|
|
|
|
|
+
|
|
|
|
|
+Mi IMPLEMENTS Mj
|
|
|
|
|
+
|
|
|
|
|
+Mj COMPRISES Mi
|
|
|
|
|
+
|
|
|
|
|
+Mi USES Mj
|
|
|
|
|
+Часть процесса изготовления программного обеспечения, связанная с поддержкой и контролем взаимосвязей рабочих продуктов различных версий конечного продукта называется
|
|
|
|
|
+равлением коллективом
|
|
|
|
|
+
|
|
|
|
|
+управлением качеством
|
|
|
|
|
+
|
|
|
|
|
+управлением продажами
|
|
|
|
|
+
|
|
|
|
|
+управление конфигурацией
|
|
|
|
|
+
|
|
|
|
|
+управлением данными
|
|
|
|
|
+Предусмотрение изменений - это принцип, который влияет на такие качества программного обеспечения как
|
|
|
|
|
+детерминированность реализации
|
|
|
|
|
+
|
|
|
|
|
+понятность
|
|
|
|
|
+
|
|
|
|
|
+повторную применимость
|
|
|
|
|
+
|
|
|
|
|
+прозрачность
|
|
|
|
|
+
|
|
|
|
|
+способность модификации
|
|
|
|
|
+Прием инженерии программного обеспечения - это
|
|
|
|
|
+строгий, систематизированный, упорядоченный подход к заказчику
|
|
|
|
|
+
|
|
|
|
|
+систематизированная, упорядоченная ротация исполнителей
|
|
|
|
|
+
|
|
|
|
|
+техническая реализация проекта командой
|
|
|
|
|
+
|
|
|
|
|
+конструктивный подход к разработке
|
|
|
|
|
+
|
|
|
|
|
+общая руководящая стратегия, направляющая выполнение проектной и конструкторской
|
|
|
|
|
+С точки зрения пользователя программного обеспечения качество последнего заключается в
|
|
|
|
|
+Надежности
|
|
|
|
|
+
|
|
|
|
|
+легкости использования
|
|
|
|
|
+
|
|
|
|
|
+Производительности
|
|
|
|
|
+
|
|
|
|
|
+реализуемости
|
|
|
|
|
+
|
|
|
|
|
+воспроизводимости
|
|
|
|
|
+Программное сопровождение подразделяют на три категории
|
|
|
|
|
+изменяющее
|
|
|
|
|
+
|
|
|
|
|
+Корректирующее
|
|
|
|
|
+
|
|
|
|
|
+формирующее
|
|
|
|
|
+
|
|
|
|
|
+Настраивающее
|
|
|
|
|
+
|
|
|
|
|
+Совершенствующее
|
|
|
|
|
+Метод восходящей разработки.
|
|
|
|
|
+модули программы программируются независимо друг от друга
|
|
|
|
|
+
|
|
|
|
|
+программируются модули программы с модулей самого нижнего уровня
|
|
|
|
|
+
|
|
|
|
|
+программируются модули программы с модулей самого верхнего уровня
|
|
|
|
|
+
|
|
|
|
|
+модули программы программируются друг за другом
|
|
|
|
|
+
|
|
|
|
|
+строится модульная структура программы в виде
|
|
|
|
|
+Для корректного эволюционирования программного обеспечения необходимо
|
|
|
|
|
+документировать все изменения вносимые в спецификации программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+окупить инвестиции сделанные в разработку программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+постоянно анализировать затраченные ресурсы
|
|
|
|
|
+
|
|
|
|
|
+выпускать как можно больше новых версий программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+регистрировать статистику работы программного обеспечения
|
|
|
|
|
+С точки зрения менеджера программного проекта процесс разработки программного обеспечения должен быть
|
|
|
|
|
+легко управляемым
|
|
|
|
|
+
|
|
|
|
|
+незатратным по времени
|
|
|
|
|
+
|
|
|
|
|
+Продуктивным
|
|
|
|
|
+
|
|
|
|
|
+финансоемким
|
|
|
|
|
+
|
|
|
|
|
+Предсказуемым
|
|
|
|
|
+Основная сложность в работе руководителя представляет из себя
|
|
|
|
|
+человеческие взаимоотношения и их психология
|
|
|
|
|
+
|
|
|
|
|
+распределение бюджета на реализацию аппаратной, материальной, социальной частей проекта
|
|
|
|
|
+
|
|
|
|
|
+приведение в соответствие амбиций менеджеров их квалификации
|
|
|
|
|
+
|
|
|
|
|
+принятие решений о наиболее оптимальном использовании ограниченных ресурсов для достижения взаимоисключающих целей
|
|
|
|
|
+
|
|
|
|
|
+кадровое обеспечение
|
|
|
|
|
+Тестирование выполнения программы без знания того, как она спроектирована и запрограммирована называют тестированием методом
|
|
|
|
|
+белого ящика
|
|
|
|
|
+
|
|
|
|
|
+черного ящика
|
|
|
|
|
+
|
|
|
|
|
+темной комнаты
|
|
|
|
|
+
|
|
|
|
|
+методом <<орел-решка>>
|
|
|
|
|
+
|
|
|
|
|
+прозрачного ящика
|
|
|
|
|
+Соглашение между программистом использующим данный объект и программистом создавшим его называется
|
|
|
|
|
+спецификацией пользователя
|
|
|
|
|
+
|
|
|
|
|
+спецификацией разработки
|
|
|
|
|
+
|
|
|
|
|
+спецификацией модуля
|
|
|
|
|
+
|
|
|
|
|
+спецификацией требований
|
|
|
|
|
+
|
|
|
|
|
+спецификацией проекта
|
|
|
|
|
+Процесс обнаружения и исправления ошибок называют
|
|
|
|
|
+
|
|
|
|
|
+верификацией
|
|
|
|
|
+
|
|
|
|
|
+Отладкой
|
|
|
|
|
+
|
|
|
|
|
+тестированием
|
|
|
|
|
+
|
|
|
|
|
+интерпретацией
|
|
|
|
|
+
|
|
|
|
|
+компиляцией
|
|
|
|
|
+Первичной целью любого инженерного продукта является его
|
|
|
|
|
+консолидированность
|
|
|
|
|
+
|
|
|
|
|
+безопасность
|
|
|
|
|
+
|
|
|
|
|
+надежность ПО
|
|
|
|
|
+
|
|
|
|
|
+соответствие требованиям заказчика
|
|
|
|
|
+
|
|
|
|
|
+корректность
|
|
|
|
|
+Если планируется использовать абстрактные объекты в распределенном приложении, существует два способа повышения эффективности доступа к ним
|
|
|
|
|
+распределение частей абстрактного объекта на нескольких машинах
|
|
|
|
|
+
|
|
|
|
|
+тиражирование распределенного объекта на нескольких компьютерах
|
|
|
|
|
+
|
|
|
|
|
+использование нескольких компьютеров как один
|
|
|
|
|
+
|
|
|
|
|
+создание виртуальных пользователей
|
|
|
|
|
+
|
|
|
|
|
+создание виртуальных частных сетей
|
|
|
|
|
+Контрольный пример, который имеет высокий потенциал обнаружения ошибок называется
|
|
|
|
|
+потенциальный
|
|
|
|
|
+
|
|
|
|
|
+Значимый
|
|
|
|
|
+
|
|
|
|
|
+классный
|
|
|
|
|
+
|
|
|
|
|
+формальный
|
|
|
|
|
+
|
|
|
|
|
+реальный
|
|
|
|
|
+Назначение методологии инженерии программного обеспечения состоит в том, чтобы
|
|
|
|
|
+обеспечении применения эффективных методов и приемов проектирования
|
|
|
|
|
+
|
|
|
|
|
+обеспечивать своевременное завершение проекта
|
|
|
|
|
+
|
|
|
|
|
+направлять действия пользователя программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+выдвигать определенный подход к решению проблемы путем отбора используемых методов и приемов проектирования
|
|
|
|
|
+
|
|
|
|
|
+указывать основные пути достижения целей разработчикам программного обеспечения
|
|
|
|
|
+Главное преимущество модульности заключается в том, что она позволяет применить принцип разделения на задачи на двух этапах
|
|
|
|
|
+при работе с элементами каждого модуля проекта
|
|
|
|
|
+
|
|
|
|
|
+при работе с общими характеристиками всех модулей
|
|
|
|
|
+
|
|
|
|
|
+при работе всей группы разработчиков
|
|
|
|
|
+
|
|
|
|
|
+при работе каждого сотрудника группы разработчиков
|
|
|
|
|
+Если дефекты программного обеспечения могут быть устранены применяемыми усилиями, то о таком программном обеспечении говорят как о
|
|
|
|
|
+Ремонтопригодном
|
|
|
|
|
+
|
|
|
|
|
+способном к эволюции
|
|
|
|
|
+
|
|
|
|
|
+вариативном
|
|
|
|
|
+
|
|
|
|
|
+сепарабельном
|
|
|
|
|
+
|
|
|
|
|
+корректном
|
|
|
|
|
+Программную инженерию Д. Парнас определил как
|
|
|
|
|
+<<форму коллективного мышления>>
|
|
|
|
|
+
|
|
|
|
|
+<<проектирование и программирование программного обеспечения не выходя из дому>>
|
|
|
|
|
+
|
|
|
|
|
+<<социализацию коллективных структур>>
|
|
|
|
|
+
|
|
|
|
|
+<<коллективное проектирование многовариантного программного обеспечения>>
|
|
|
|
|
+
|
|
|
|
|
+проектирование инструментов для разработок ПО
|
|
|
|
|
+CASE-технология это программный комплекс, автоматизирующий весь технологический процесс
|
|
|
|
|
+анализа сложных программных систем
|
|
|
|
|
+
|
|
|
|
|
+проектирования сложных программных систем
|
|
|
|
|
+
|
|
|
|
|
+обучения утилизации сложных программных систем
|
|
|
|
|
+
|
|
|
|
|
+обучения эксплуатации сложных программных систем
|
|
|
|
|
+
|
|
|
|
|
+разработки и сопровождения сложных программных систем
|
|
|
|
|
+Если отношение Mi r Mj не выполняется, то говорят, что это отношение
|
|
|
|
|
+рефлексивное
|
|
|
|
|
+
|
|
|
|
|
+сходимое
|
|
|
|
|
+
|
|
|
|
|
+Нерефлексивное
|
|
|
|
|
+
|
|
|
|
|
+несходимое
|
|
|
|
|
+
|
|
|
|
|
+пассивное
|
|
|
|
|
+Среди типов стандартной архитектуры различают
|
|
|
|
|
+транспонируемый
|
|
|
|
|
+
|
|
|
|
|
+Регулируемый
|
|
|
|
|
+
|
|
|
|
|
+<<классной доски>>
|
|
|
|
|
+
|
|
|
|
|
+Конвейерный
|
|
|
|
|
+
|
|
|
|
|
+на событиях
|
|
|
|
|
+К качествам характеризующим информационные системы относят
|
|
|
|
|
+планирование времени выполнения запросов
|
|
|
|
|
+
|
|
|
|
|
+поддержку целостности данных
|
|
|
|
|
+
|
|
|
|
|
+доступность данных
|
|
|
|
|
+
|
|
|
|
|
+производительность транзакций
|
|
|
|
|
+
|
|
|
|
|
+наличие сетевого сервиса
|
|
|
|
|
+
|
|
|
|
|
+безопасность работы с огромными массивами данных
|
|
|
|
|
+Общность - это фундаментальный принцип заключающийся
|
|
|
|
|
+в интегрированном подходе к разработке программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+в возможности решить более общую задачу и не акцентировать внимание на мелочах
|
|
|
|
|
+
|
|
|
|
|
+стремление не выделяться в коллективе
|
|
|
|
|
+
|
|
|
|
|
+в создании продуктов-модулей, которые можно использовать в разных конфигурациях
|
|
|
|
|
+
|
|
|
|
|
+в обобщении различных взглядов группы разработчиков на решение задачи
|
|
|
|
|
+Некорректное промежуточное состояние, в которое программа может войти во время выполнения называется
|
|
|
|
|
+Неисправностью
|
|
|
|
|
+
|
|
|
|
|
+выходным листингом
|
|
|
|
|
+
|
|
|
|
|
+Абзацем
|
|
|
|
|
+
|
|
|
|
|
+Сбоем
|
|
|
|
|
+
|
|
|
|
|
+аварийной ситуацией
|
|
|
|
|
+Укажите компоненты <<программы-максимума>>, требований предъявляемых программному инженеру
|
|
|
|
|
+знание алгоритмов программирования
|
|
|
|
|
+
|
|
|
|
|
+умение переходить от одного уровня абстракции к другому
|
|
|
|
|
+
|
|
|
|
|
+умение переключаться от одной стадии проекта к другой
|
|
|
|
|
+
|
|
|
|
|
+профессиональное владение языками программирования
|
|
|
|
|
+
|
|
|
|
|
+владение культурой речи
|
|
|
|
|
+Описательные спецификации могут быть
|
|
|
|
|
+последовательными
|
|
|
|
|
+
|
|
|
|
|
+параллельными
|
|
|
|
|
+
|
|
|
|
|
+логическими
|
|
|
|
|
+
|
|
|
|
|
+алгебраическими
|
|
|
|
|
+
|
|
|
|
|
+мультипликативными
|
|
|
|
|
+Термин <<проект>> в инженерии программного обеспечения используется для обозначения
|
|
|
|
|
+команды разработчиков
|
|
|
|
|
+
|
|
|
|
|
+свода правил
|
|
|
|
|
+
|
|
|
|
|
+архитектуры ПО
|
|
|
|
|
+
|
|
|
|
|
+результата проектирования
|
|
|
|
|
+
|
|
|
|
|
+процесса разработки ПО
|
|
|
|
|
+С точки зрения разработчика программного обеспечения качество последнего заключается в
|
|
|
|
|
+расширяемости
|
|
|
|
|
+
|
|
|
|
|
+тестируемости
|
|
|
|
|
+
|
|
|
|
|
+производительности
|
|
|
|
|
+
|
|
|
|
|
+переносимости
|
|
|
|
|
+
|
|
|
|
|
+легкости применения
|
|
|
|
|
+К моделям организации работ относятся:
|
|
|
|
|
+Виртуальная модель
|
|
|
|
|
+
|
|
|
|
|
+Модель потока работ (workflow model)
|
|
|
|
|
+
|
|
|
|
|
+Модель потоков данных (data flow model)
|
|
|
|
|
+
|
|
|
|
|
+Ролевая модель
|
|
|
|
|
+
|
|
|
|
|
+Кластерная модель
|
|
|
|
|
+Метод нисходящей разработки
|
|
|
|
|
+строится модульная структура программы в виде дерева
|
|
|
|
|
+
|
|
|
|
|
+переходят к программированию какого-либо другого модуля только в том случае, если уже запрограммирован модуль, который к нему обращается
|
|
|
|
|
+
|
|
|
|
|
+модули программы программируются независимо друг от друга
|
|
|
|
|
+
|
|
|
|
|
+программируются модули программы с модулей самого нижнего уровня
|
|
|
|
|
+
|
|
|
|
|
+программируются модули программы, начиная с модуля самого верхнего уровня (головного)
|
|
|
|
|
+Методы и технологии реинжиниринга и обратного инжиниринга программного обеспечения нацелены на
|
|
|
|
|
+реструктурирование унаследованного программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+модификацию унаследованного программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+тестирование унаследованного программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+раскрытие структуры унаследованного программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+оптимизацию унаследованного программного обеспечения
|
|
|
|
|
+Набор версий программного обеспечения часто называют
|
|
|
|
|
+системой
|
|
|
|
|
+
|
|
|
|
|
+формой
|
|
|
|
|
+
|
|
|
|
|
+Линейкой
|
|
|
|
|
+
|
|
|
|
|
+представителями
|
|
|
|
|
+
|
|
|
|
|
+Семейством
|
|
|
|
|
+<<Понятность>> -качество программного обеспечения, подразделяемое на
|
|
|
|
|
+жесткую понятность
|
|
|
|
|
+
|
|
|
|
|
+внутреннюю понятность
|
|
|
|
|
+
|
|
|
|
|
+межпроектное взаимодействие внутри одной группы разработок
|
|
|
|
|
+
|
|
|
|
|
+логическую понятность
|
|
|
|
|
+
|
|
|
|
|
+внешнюю понятность
|
|
|
|
|
+
|
|
|
|
|
+способность программного обеспечения к взаимодействию с другим программным обеспечением
|
|
|
|
|
+
|
|
|
|
|
+понятность требований заказчика
|
|
|
|
|
+Описательные спецификации описывают
|
|
|
|
|
+желательный результат системы
|
|
|
|
|
+
|
|
|
|
|
+желательных пользователей системы
|
|
|
|
|
+
|
|
|
|
|
+желательное поведение системы
|
|
|
|
|
+
|
|
|
|
|
+желательные свойства системы
|
|
|
|
|
+
|
|
|
|
|
+желательную платформу
|
|
|
|
|
+Управление конфигурацией - это дисциплина обеспечивающая
|
|
|
|
|
+возможность переделки программного обеспечения при изменении требований к его функциям или обнаружении ошибки
|
|
|
|
|
+
|
|
|
|
|
+непротиворечивое представление программного обеспечения даже при внесении в него изменений
|
|
|
|
|
+
|
|
|
|
|
+работу аппаратной конфигурации компьютера при установке этого программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+успешное продолжение проекта даже при полной смене команды
|
|
|
|
|
+
|
|
|
|
|
+управление составом группы разработчиков
|
|
|
|
|
+Способами изменения программного обеспечения являются
|
|
|
|
|
+Настройка
|
|
|
|
|
+
|
|
|
|
|
+полиморфизм
|
|
|
|
|
+
|
|
|
|
|
+наследование
|
|
|
|
|
+
|
|
|
|
|
+инкапсуляция
|
|
|
|
|
+
|
|
|
|
|
+Усовершенствование
|
|
|
|
|
+Верифицируемость программного продукта предполагает
|
|
|
|
|
+возможность контроля соответствия продукта требованиям
|
|
|
|
|
+
|
|
|
|
|
+единообразие пользовательского интерфейса
|
|
|
|
|
+
|
|
|
|
|
+мгновенную реакцию на изменение внешней среды
|
|
|
|
|
+
|
|
|
|
|
+достаточность тестирования свойств системы
|
|
|
|
|
+
|
|
|
|
|
+формальное описание устойчивости
|
|
|
|
|
+Среди ниже перечисленных укажите характеристики распределенных систем
|
|
|
|
|
+работоспособность системы при разрыве соединения в сети
|
|
|
|
|
+
|
|
|
|
|
+работоспособность системы при поломке отдельного компьютера сети
|
|
|
|
|
+
|
|
|
|
|
+виртуальность предоставляемых серверами ресурсов
|
|
|
|
|
+
|
|
|
|
|
+образовательный ценз персонала
|
|
|
|
|
+UML - это универсальный язык
|
|
|
|
|
+Конструирования
|
|
|
|
|
+
|
|
|
|
|
+Спецификации
|
|
|
|
|
+
|
|
|
|
|
+Визуализации
|
|
|
|
|
+
|
|
|
|
|
+форматирования
|
|
|
|
|
+
|
|
|
|
|
+компьютерной имитации
|
|
|
|
|
+
|
|
|
|
|
+Документирования
|
|
|
|
|
+К факторам внешней понятности относят
|
|
|
|
|
+удобство эксплуатации продукта
|
|
|
|
|
+
|
|
|
|
|
+логистика
|
|
|
|
|
+
|
|
|
|
|
+квалификация пользователей
|
|
|
|
|
+
|
|
|
|
|
+предсказуемость результатов работы
|
|
|
|
|
+
|
|
|
|
|
+Тестируемость
|
|
|
|
|
+Об изменяемой, но скрытой информации модуля говорят, что
|
|
|
|
|
+она является шифром модуля
|
|
|
|
|
+
|
|
|
|
|
+она допускает непосредственное извне изменение иформации
|
|
|
|
|
+
|
|
|
|
|
+она разработана неверно
|
|
|
|
|
+
|
|
|
|
|
+она скрывает все существующие возможности модуля
|
|
|
|
|
+
|
|
|
|
|
+она инкапсулирована в реализации модуля
|
|
|
|
|
+Интероперабельностью называют
|
|
|
|
|
+реализацию кода на PHP
|
|
|
|
|
+
|
|
|
|
|
+переносимость программного обеспечения с платформы на платформу
|
|
|
|
|
+
|
|
|
|
|
+способность программного обеспечения к взаимодействию с другим программным обеспечением
|
|
|
|
|
+
|
|
|
|
|
+реализацию кода на разных машинах
|
|
|
|
|
+Надежность программного обеспечения как инженерного продукта
|
|
|
|
|
+включает в себя понятие корректности программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+является обязательным требованием
|
|
|
|
|
+
|
|
|
|
|
+гарантирует безотказность программного обеспечения
|
|
|
|
|
+
|
|
|
|
|
+величина вероятностная
|
|
|
|
|
+
|
|
|
|
|
+гарантирует окупаемость вложений
|
|
|
|
|
+Программный модуль - это
|
|
|
|
|
+средство популяризации приемов программирования
|
|
|
|
|
+
|
|
|
|
|
+средство борьбы со сложностью программ
|
|
|
|
|
+
|
|
|
|
|
+средство борьбы с дублированием в программировании
|
|
|
|
|
+
|
|
|
|
|
+фрагмент описания вычислительного процесса
|
|
|
|
|
+
|
|
|
|
|
+средство борьбы с неадекватностью в программировании
|
|
|
|
|
+
|
|
|
|
|
+
|
ypv