- •Алгоритм линейного поиска в одномерном массиве. Зависимость затрат на линейный поиск в среднем и в худшем случае от числа элементов массива. Улучшение линейного поиска: поиск с барьером.
- •Алгоритм двоичного поиска в одномерном отсортированном массиве. Зависимость затрат на двоичный поиск в среднем и в худшем случае от числа элементов массива.
- •3. Последовательная и связанная память. Представление линейных списков в последовательной и связанной памяти. Достоинства и недостатки того и другого представления.
- •Стеки и очереди в непрерывной памяти
- •Представление стека в связаннной памяти
- •Представление очереди в непрерывной памяти
- •Представление очереди в связаннной памяти
- •5. Понятие обхода дерева. Виды обходов двоичного дерева. Определение структуры двоичного дерева по двум заданным обходам. Рекурсивные алгоритмы обходов двоичных деревьев.
- •Примеры обходов должны различаться в ответах разных студентов
- •7. Деревья поиска. Алгоритм исключения узла из дерева поиска.
- •8 Понятие программного обеспечения, тенденции развития программного обеспечения.
- •It-услуги
- •9.1 Функциональная и объектно-ориентированные стратегии разработки по
- •Функционально-ориентированная стратегия разработки по (фос)
- •Объектно-ориентированная стратегия разработки по (оос)
- •10 - Основные принципы ооп
- •11.1 - Принципы отладки программных систем.
- •12.1 - Обобщенные и элементарные критерии качества программного обеспечения.
- •12.2 - Обобщенные и элементарные критерии качества программного обеспечения.
- •13.1- Организация коллективов программистов и разработчиков
- •13.2- Организация коллективов программистов и разработчиков
- •14. Тестирование программного обеспечения. Автономное и комплексное тестирование см. Также распечатку гэ_г_тестирование, структуру ответа - лучше по ней
- •14.2 - Тестирование программного обеспечения. Автономное и комплексное тестирование
- •Автономное и комплексное тестирование
- •14.3 - Тестирование программного обеспечения. Автономное и комплексное тестирование алгоритм тестирования подпрограммы / метода (модулей)
- •15.1 - Понятие класса и объекта. Конструкторы и деструкторы.
- •15.2 - Понятие класса и объекта. Конструкторы и деструкторы.
- •16 - Статические и виртуальные методы
13.1- Организация коллективов программистов и разработчиков
Работа над крупными программными проектами - коллективная деятельность:
Обеспечивается преемственность
Вырабатываются общие универсальные стандарты разработки
Облегчаются контакты.
БРИГАДА ГЛАВНОГО ПРОГРАММИСТА
Состав: Гл. Прогр-т, Зам-ль, программист. (10 – 12 чел)
Функции главного программиста: Руководство проектированием ПС, определение структуры ПС(построение диаграммы классов…), распределение и контрольработ, связь с заказчиком, написание наиболее важных/критичных методов, глобальное тестирование всей системы.
Функции зама: замещение главного, оппонирование в процессе создания ПО, коммуникация с другими бригадами.
Функции программистов: написание текста на псевдокоде, логика работы методов, программирование методов, тестирование элементов, участие в интеграции разных элементов в единое целое.

БРИГАДЫ БЕЗ ПЕРСОНАЛИЗАЦИИ ФУНКЦИЙ:
«Демократическая». На каждом этапе свой лидер, руководящий работой на своем этапе. Все функции те же самые.
ОБЪЕКТНО-ОРИЕНТЕРИРОВАННАЯ БРИГАДА (ДЛЯ КРУПНОГО ПРОЕКТА)
Архитектор системы, проектировщик классов, обычные программисты.
Архитектор Определяет общую структуру ПС (на уровне главных классов), продумывает функции всей ПС. Основная работа: анализ ПО, проектирование. На более низкие уровни не опускается. Связь с заказчиком и пользователями.
Проектировщик классов: основная задача – определение структуры классов, относящихся к какой-либо части ПС, их интерфейсов, и отношений между классами; определение всех атрибутов, свойств и методов, входящих в класс.
Обычный программист: Разрабатывает на языке псевдокода (спецификаций) тексты методов Программирует эти методы, тестирует их и отлаживает.(+см. Бригада главного программиста).
Порядок разработки ПС: определение должностей, определение структуры классов, построение отношений между классами на заданном уровне абстракции, планирование элементов реализации методов. Этапы повторяются на каждом уровне итерации ПС.
13.2- Организация коллективов программистов и разработчиков

14. Тестирование программного обеспечения. Автономное и комплексное тестирование см. Также распечатку гэ_г_тестирование, структуру ответа - лучше по ней
Тестирование – проверка работоспособности программы с целью обнаружения ошибок.
Тестовый набор – совокупность входных данных + ожидаемый результат.
Тестировщики: Программист> Руководитель разработки>Внешние организации> cпециальные внешние организации
Тестирование может осуществляться на нескольких уровнях:
СМ. РАСПЕЧАТКУ ГЭ_Г_ТЕСТИРОВАНИЕ,
- Тестирование всей программной системы
- Тестирование на уровне модулей или методов (выполняется самими разработчиком)
- Тестирование наиболее важных элементов (выполняется руководителем разработки , главным программистом)
СТРАТЕГИИ ТЕСТИРОВАНИЯ:
Стратегия белого ящика
Имеются исходные тексты тестируемой ПС
2) Стратегия черного ящика
Исходные тексты недоступны. Можем работать с программой, прогонять программу, задавать данные и получать результат. Доступен исполняемый код.
СТРАТЕГИЯ БЕЛОГО ЯЩИКА
Подбираем тестовые наборы так, чтобы каждый оператор выполнился хотя бы 1 раз
Подбираем тестовые наборы так, чтобы каждая линия передачи покрывалась хотя бы 1 раз
Подбираем тестовые наборы так, чтобы каждый путь от входа к выходу проходился хотя бы 1 раз [Трудная задача]
Примеры…
Тестовые наборы нужно создавать в процессе программирования.
В основном используется 2 метод, но это не гарантирует полноту тестирования
При этом используется не слишком большое число тестов. Такое тестирование проводит разработчик программы.
СТРАТЕГИЯ ЧЕРНОГО ЯЩИКА
Метод эквивалентных разделений.
Предполагаем что множество всех возможных ошибок может быть разделено на непересекающиеся множества.
Всё множество всех возможных входных данных может быть разделено на классы эквивалентности (поясните, что это такое), причем если тестовый набор из класса 1 обнаруживает ошибку 1, то и другой набор из класса 1 обнаружит эту ошибку. Если КЭ пересекаются, то кол-во тестовых наборов может быть сокращено (если не пересекаются, что число ТН = число классов).
Если удается выделить КЭ, то чаще всего достаточно взять по 1 набору из класса.
Разбить ошибки на непересекающиеся множества очень трудно.
