Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ГЭ_У_Студентам / ТРПС_2010.doc
Скачиваний:
62
Добавлен:
05.06.2015
Размер:
4 Mб
Скачать

13.1- Организация коллективов программистов и разработчиков

Работа над крупными программными проектами - коллективная деятельность:

  1. Обеспечивается преемственность

  2. Вырабатываются общие универсальные стандарты разработки

  3. Облегчаются контакты.

  • БРИГАДА ГЛАВНОГО ПРОГРАММИСТА

Состав: Гл. Прогр-т, Зам-ль, программист. (10 – 12 чел)

Функции главного программиста: Руководство проектированием ПС, определение структуры ПС(построение диаграммы классов…), распределение и контрольработ, связь с заказчиком, написание наиболее важных/критичных методов, глобальное тестирование всей системы.

Функции зама: замещение главного, оппонирование в процессе создания ПО, коммуникация с другими бригадами.

Функции программистов: написание текста на псевдокоде, логика работы методов, программирование методов, тестирование элементов, участие в интеграции разных элементов в единое целое.

  • БРИГАДЫ БЕЗ ПЕРСОНАЛИЗАЦИИ ФУНКЦИЙ:

«Демократическая». На каждом этапе свой лидер, руководящий работой на своем этапе. Все функции те же самые.

  • ОБЪЕКТНО-ОРИЕНТЕРИРОВАННАЯ БРИГАДА (ДЛЯ КРУПНОГО ПРОЕКТА)

Архитектор системы, проектировщик классов, обычные программисты.

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

Проектировщик классов: основная задача – определение структуры классов, относящихся к какой-либо части ПС, их интерфейсов, и отношений между классами; определение всех атрибутов, свойств и методов, входящих в класс.

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

Порядок разработки ПС: определение должностей, определение структуры классов, построение отношений между классами на заданном уровне абстракции, планирование элементов реализации методов. Этапы повторяются на каждом уровне итерации ПС.

13.2- Организация коллективов программистов и разработчиков

14. Тестирование программного обеспечения. Автономное и комплексное тестирование см. Также распечатку гэ_г_тестирование, структуру ответа - лучше по ней

  • Тестирование – проверка работоспособности программы с целью обнаружения ошибок.

  • Тестовый набор – совокупность входных данных + ожидаемый результат.

  • Тестировщики: Программист> Руководитель разработки>Внешние организации> cпециальные внешние организации

  • Тестирование может осуществляться на нескольких уровнях:

СМ. РАСПЕЧАТКУ ГЭ_Г_ТЕСТИРОВАНИЕ,

- Тестирование всей программной системы

- Тестирование на уровне модулей или методов (выполняется самими разработчиком)

- Тестирование наиболее важных элементов (выполняется руководителем разработки , главным программистом)

  • СТРАТЕГИИ ТЕСТИРОВАНИЯ:

  1. Стратегия белого ящика

Имеются исходные тексты тестируемой ПС

2) Стратегия черного ящика

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

  • СТРАТЕГИЯ БЕЛОГО ЯЩИКА

  1. Подбираем тестовые наборы так, чтобы каждый оператор выполнился хотя бы 1 раз

  2. Подбираем тестовые наборы так, чтобы каждая линия передачи покрывалась хотя бы 1 раз

  3. Подбираем тестовые наборы так, чтобы каждый путь от входа к выходу проходился хотя бы 1 раз [Трудная задача]

Примеры…

Тестовые наборы нужно создавать в процессе программирования.

В основном используется 2 метод, но это не гарантирует полноту тестирования

При этом используется не слишком большое число тестов. Такое тестирование проводит разработчик программы.

  • СТРАТЕГИЯ ЧЕРНОГО ЯЩИКА

  1. Метод эквивалентных разделений.

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

Всё множество всех возможных входных данных может быть разделено на классы эквивалентности (поясните, что это такое), причем если тестовый набор из класса 1 обнаруживает ошибку 1, то и другой набор из класса 1 обнаружит эту ошибку. Если КЭ пересекаются, то кол-во тестовых наборов может быть сокращено (если не пересекаются, что число ТН = число классов).

Если удается выделить КЭ, то чаще всего достаточно взять по 1 набору из класса.

Разбить ошибки на непересекающиеся множества очень трудно.