
- •1.Огляд технологій програмування. Життєвий цикл програмного забезпечення.
- •2.Тестування програмного забезпечення.
- •3.Уніфікований процес розробки програмного забезпечення (rup).
- •Жизненный цикл разработки
- •1. Начало
- •4.Екстремальне програмування. Основні принципи.
- •5.Основи мови uml. Сутності uml.
- •6.Шаблони проектування (патерни), їхні види й використання при розробці архітектури програмного забезпечення.
- •2. Уточнение
- •3. Построение
- •4. Внедрение
- •7.Розмірно-орієнтовані метрики. Функціонально-орієнтовані метрики.
- •Функционально-ориентированные метрики
- •8.Конструктивна модель вартості сосомо.
- •9.Класичні метрики складності, зв’язності й зчеплення.
- •11.Автоматизація ole. Сервери ole. Доступ до сервера автоматизації на прикладі редактора ms Word і табличного процесора ms Excel.
- •10.Основи com. Об'єкт com. Інтерфейси com. Сервери com. Фабрика класу. Інтерфейс Iunknown.
5.Основи мови uml. Сутності uml.
UML – это стандартизованный язык для создания рабочих чертежей программирования. UML это язык для
-Визуализации,
-Спецификации,
-Конструирования,
-Документации артефактов программной системы.
В UML задействованы три типа блоков: 1.Сущность (things)
2.Отношение (relationships) (зависимость, ассоциация, обобщение, реализация).
3.Диаграмма (diagrams).
Cущности являются основой модели, отношения обеспечивают их привязку друг к другу, а диаграммы группируют наборы сущностей.
В UML представлены четыре типа сущностей:
-Структурные
-Поведенческие
-Групповые
-Аннотационные.
7 типов структурных сущностей:
1.Класс-это набор объектов которые используют одни и те же атрибуты, операции, отношения и семантику.
2.Интерфейс-это набор операций которые специфицируют услуги класса или компонента. Т.е. интерфейс описывает поведение элемента.
3.Cотрудничество-определяет взаимодействия и является сообществом ролей и других элементов, которые работают вместе для обеспечения некоторого совместного поведения, которое больше, чем совокупность всех элементов. Класс может участвовать в нескольких сущностях сотрудничества.
4.Актёр-пользователь системы – набор согласованных ролей.
5.Cценарий использования (Use Case) описывает набор последовательностей действий, которые выполняются системой и дают результат с конкретным значением для конкретного участника (actor).
5.Активный класс- это класс, объекты которого владеют одним или более процессами и могут инициировать управляющие воздействия.
6.Компонент-физическая и перемещаемая часть системы, которая удовлетворяет и обеспечивает реализацию набора интерфейсов.
7.Узел- физич. элемент, который существует в момент исполнения действий системы и представляет вычислительный ресурс, содержащий некоторую память и способность к обработке данных.
Поведенческие сущности (динамические составляющие UML-модели).
1.Взаимодействие включает набор сообщений, передаваемых внутри набора объектов.
2.Машина состояний – поведение, кот-е определяет последов-ть состояний объекта или взаимодействия, выполняемые в ходе его существ-ия в ответ на события.
Групповые сущности это “ящики”, на кот-е может быть осуществлена декомпозиция модели. Пакет- это механизм общего назначения для организации элементов в виде единой группы.
Аннотационные сущности - поясняющая и комментирующая часть UML. Типом ан. сущности является примечание.
6.Шаблони проектування (патерни), їхні види й використання при розробці архітектури програмного забезпечення.
Кооперации (сотрудничества) являются средством представления комплексных решений в разработке ПО на высшем, архитектурном уровне. Кооперации содержат две составляющие — статическую (структурную) и динамическую (поведенческую). Статическая составляющая кооперации задает структуру классов,интерфейсов, компонентов. Динамическая составляющая определяет поведение элементов. Настраиваемые кооперации называют паттернами (образцами). Паттерн является решением типичной проблемы в определенном контексте. Паттерны рассматриваются как крупные строительные блоки. Их использование приводит к существенному сокращению затрат на анализ и проектирование ПО. Паттерны — это наборы готовых решений, предлагающиеся к повторному использованию. Паттерн Наблюдатель задает между объектами такую зависимость «один-ко-многим», при которой изменение состояния одного объекта приводит к оповещению и обновлению всех зависящих от него объектов. Паттерн Компоновщик обеспечивает представление иерархий часть-целое, объединяя объекты в древовидные структуры. Паттерн Команда выполняет преобразование запроса в объект. Шаблон не может участвовать в большинстве обычных отношений между классами. Существует всего два вида отношений, в которых он может участвовать – связи между шаблоном и классом, порожденным от него подстановкой параметров, и направленные ассоциации. Направленная ассоциация должна идти в направлении от шаблона.
По степени подготовленности к тестированию:
-
Тестирование по документации
-
Тестирование ad hoc или интуитивное тестирование
Уровни тестирования
-
Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.
Интеграционное тестирование — тестируются интерфейсы между компонентами,
-
подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.
-
Системное тестирование — тестируется интегрированная система на её соответствие требованиям.
-
Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.
-
Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
-
Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.
-
Создается экономическое обоснование (business case).
-
Определяются основные требования, ограничения и ключевая функциональность продукта.
-
Создается базовая версия модели прецедентов.
-
Оцениваются риски.
При завершении начальной фазы оценивается достижение вехи целей жизненного цикла, которое предполагает соглашение
заинтересованных сторон о продолжении проекта.