- •Вопросы к экзамену по курсу "Технология программирования"
- •История развития языков программирования высокого уровня.
- •Архитектура языков программирования (три поколения).
- •Архитектура объектно-ориентированных языков программирования.
- •Сложность, присущая по (основные причины). Проблемы, возникающие при создании сложных систем.
- •Структура сложных систем (пять признаков). Примеры сложных систем (выделить признаки).
- •Основные понятия: метод, методология, технология. Классификация методов проектирования пс. Общая характеристика методов проектирования.
- •Эволюция программного продукта. Основные определения, понятия, отличительные черты.
- •Понятие «модуль» в программировании. Различные виды модулей при использовании основных методов проектирования пс.
- •Case – технологии (инструменты, системы, средства). Эволюция case – средств, их классификация, характеристики современных case – инструментов. Перспективы развития.
- •Роль case – инструментов в объектно-ориентированной методологии разработки пс. Связь case – технологии с методами быстрой разработки приложений (rad).
- •Классификация средств разработки (case - инструментов).
- •Жизненный цикл по (жц). Структура жц, основные фазы жц.
- •Организация процесса разработки пс (методы, средства, процедуры).
- •Модели процесса разработки пс (каскадная, спиральная)
- •Модели процесса разработки пс (компонентно-ориентированная, инкрементная, rad – модель).
- •Тяжеловесные и облегченные процессы разработки пс.
- •Унифицированный процесс разработки пс.
- •Iconix – процесс.
- •Scrum – процесс.
- •Артефакты
- •Встречи
- •Планирование спринта происходит в начале итерации(не более 4-8 часов), выбирается что будет сделано и обсуждается как это будет сделано.
- •Митинг Происходит каждый день в течение спринта(не более 15 минут), ищутся ответы на вопросы: что сделано? Что надо сделать? Какие есть проблемы?
- •Демонстрация проходит в конце спринта(не более 4-8 часов), показывается инкремент.
- •Прототип системы (достоинства и недостатки макетирования).
- •Масштаб проекта и риски
- •Содержание основных рабочих процессов по созданию по (анализ требований, системный анализ, проектирование).
- •Содержание основных рабочих процессов по созданию по (кодирование, тестирование).
- •Изменения в процессе эволюции программных систем, стоимость каждого вида изменения (в смысле затрат).
- •Организационные процессы (распределение ресурсов, управление проектом, организация коллектива разработчиков).
- •Документирование программного продукта. Различные виды документов, их содержание.
- •Виды документов при использовании объектно-ориентированной методологии разработки пс.
- •Временные затраты на реализацию этапов разработки по. Особенности распределения ресурсов при использовании объектно-ориентированной методологии.
- •Методы и средства структурного анализа.
- •Диаграммы потоков данных с расширениями для реального времени.
- •Пример банковской задачи (провести анализ).
- •Средства структурного проектирования (карты Константайна).
- •Методы проведения анализа объектно-ориентированных систем.
- •Типовая и структурная иерархии в объектно-ориентированной методологии.
- •Унифицированный язык моделирования пс (uml). Словарь, достоинства и возможности
- •Механизмы расширения в uml.
- •Диаграммы классов (точки зрения).
- •Отношения в диаграмме классов.
- •Классы ассоциаций.
- •Диаграммы вариантов использования, реализации вариантов использования.
- •Диаграммы взаимодействий.
- •Диаграммы пакетов и компонентов.
- •Диаграммы состояний.
- •Диаграммы активности (деятельностей).
- •Каркасы и паттерны.
- •Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.
- •Критерии тестирования стратегии "черного ящика".
- •1. Эквивалентное разбиение (самый популярный критерий из-за простоты)
- •2. Анализ граничных условий.
- •3. Метод функциональных диаграмм
- •Классический процесс тестирования по.
- •Тестирование модулей (блоков) программы. Тестирование интеграции.
- •Тестирование правильности (функциональное тестирование). Системное тестирование.
- •Особенности тестирования объектно-ориентированных программ. Тестирование классов.
- •Тестирование взаимодействия классов и функционирования компонентов.
- •Вопросы автоматизации тестирования. Инструменты тестирования.
Артефакты
Product backlog — это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story) или элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.
Sprint Backlog — содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.
Burndown chart — показывает, сколько уже исполнено и сколько ещё остаётся сделать.
Встречи
Планирование спринта происходит в начале итерации(не более 4-8 часов), выбирается что будет сделано и обсуждается как это будет сделано.
Митинг Происходит каждый день в течение спринта(не более 15 минут), ищутся ответы на вопросы: что сделано? Что надо сделать? Какие есть проблемы?
Демонстрация проходит в конце спринта(не более 4-8 часов), показывается инкремент.
Прототип системы (достоинства и недостатки макетирования).
Программный прототип (макет) - это ранняя реализация системы, в которой демонстрируют только часть ее функциональных возможностей.
Прототип создается с целью помочь разработчикам и пользователям (заказчикам) лучше понять друг друга, лучше понять требования к системе. Например, после того, как пользователь увидел хоть что-то, он, добавит требования к системе более осознанно.
Выделяются следующие прототипы: отбрасываемые, эволюционирующие, операционные, вертикальные, горизонтальные, интерфейсные и алгоритмические.
“отбрасываемые” прототипы создаются, чтобы опробовать какое-либо архитектурное решение.
“Эволюционирующий” – прототип постепенно развивается до конечного продукта.
“Горизонтальный” означает, что в интерфейсе изначально заложены почти все функциональные возможности системы. А “вертикальный” прототип реализует мало функций, но делает их качественно.
Достоинства прототипов:
Обеспечивают определение более полных требований к ПО.
Обеспечивают снятия неопределенностей.
Недостатки макетирования:
Заказчик может принять макет за продукт(«немножко подправьте и всё»)
Разработчик может принять макет за продукт(в прототипе может использоваться неоптимальный язык программирования, алгоритмы, про которые потом можно забыть…)
Масштаб проекта и риски
Масштаб проекта определяется следующими тремя переменными:
Набором функций, которые необходимы пользователю.
Ресурсами, которыми располагает проект.
Временем, которое выделено на реализацию.
Если объем работ, необходимый для реализации функций системы, равен имеющимся ресурсам, умноженным на выделенное время, то проект имеет достижимый масштаб.
Под риском понимается вероятность того, что реализация функции окажет негативное влияние на график и бюджет. Если функция с высоким риском является всего лишь полезной, то ее можно удалить.
Таким образом, своевременное выявление риска, а так же принятие соответствующих мер позволяют предотвратить срыв проекта.
Каждый выявленный риск должен с радостью восприниматься командой проекта, т. к. в этом случае с ним можно начать хоть что-то делать. Настоящей проблемой являются риски, которые не удалось выявить. Такие риски похожи на мины, которые ждут своего часа и цели. Для выявления рисков в команде должен быть человек со скептическим складом ума.