- •Вопросы к экзамену по курсу "Технология программирования"
- •История развития языков программирования высокого уровня.
- •Архитектура языков программирования (три поколения).
- •Архитектура объектно-ориентированных языков программирования.
- •Сложность, присущая по (основные причины). Проблемы, возникающие при создании сложных систем.
- •Структура сложных систем (пять признаков). Примеры сложных систем (выделить признаки).
- •Основные понятия: метод, методология, технология. Классификация методов проектирования пс. Общая характеристика методов проектирования.
- •Эволюция программного продукта. Основные определения, понятия, отличительные черты.
- •Понятие «модуль» в программировании. Различные виды модулей при использовании основных методов проектирования пс.
- •Case – технологии (инструменты, системы, средства). Эволюция case – средств, их классификация, характеристики современных case – инструментов. Перспективы развития.
- •Роль case – инструментов в объектно-ориентированной методологии разработки пс. Связь case – технологии с методами быстрой разработки приложений (rad).
- •Классификация средств разработки (case - инструментов).
- •Жизненный цикл по (жц). Структура жц, основные фазы жц.
- •Организация процесса разработки пс (методы, средства, процедуры).
- •Модели процесса разработки пс (каскадная, спиральная)
- •Модели процесса разработки пс (компонентно-ориентированная, инкрементная, rad – модель).
- •Тяжеловесные и облегченные процессы разработки пс.
- •Унифицированный процесс разработки пс.
- •Iconix – процесс.
- •Scrum – процесс.
- •Артефакты
- •Встречи
- •Планирование спринта происходит в начале итерации(не более 4-8 часов), выбирается что будет сделано и обсуждается как это будет сделано.
- •Митинг Происходит каждый день в течение спринта(не более 15 минут), ищутся ответы на вопросы: что сделано? Что надо сделать? Какие есть проблемы?
- •Демонстрация проходит в конце спринта(не более 4-8 часов), показывается инкремент.
- •Прототип системы (достоинства и недостатки макетирования).
- •Масштаб проекта и риски
- •Содержание основных рабочих процессов по созданию по (анализ требований, системный анализ, проектирование).
- •Содержание основных рабочих процессов по созданию по (кодирование, тестирование).
- •Изменения в процессе эволюции программных систем, стоимость каждого вида изменения (в смысле затрат).
- •Организационные процессы (распределение ресурсов, управление проектом, организация коллектива разработчиков).
- •Документирование программного продукта. Различные виды документов, их содержание.
- •Виды документов при использовании объектно-ориентированной методологии разработки пс.
- •Временные затраты на реализацию этапов разработки по. Особенности распределения ресурсов при использовании объектно-ориентированной методологии.
- •Методы и средства структурного анализа.
- •Диаграммы потоков данных с расширениями для реального времени.
- •Пример банковской задачи (провести анализ).
- •Средства структурного проектирования (карты Константайна).
- •Методы проведения анализа объектно-ориентированных систем.
- •Типовая и структурная иерархии в объектно-ориентированной методологии.
- •Унифицированный язык моделирования пс (uml). Словарь, достоинства и возможности
- •Механизмы расширения в uml.
- •Диаграммы классов (точки зрения).
- •Отношения в диаграмме классов.
- •Классы ассоциаций.
- •Диаграммы вариантов использования, реализации вариантов использования.
- •Диаграммы взаимодействий.
- •Диаграммы пакетов и компонентов.
- •Диаграммы состояний.
- •Диаграммы активности (деятельностей).
- •Каркасы и паттерны.
- •Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.
- •Критерии тестирования стратегии "черного ящика".
- •1. Эквивалентное разбиение (самый популярный критерий из-за простоты)
- •2. Анализ граничных условий.
- •3. Метод функциональных диаграмм
- •Классический процесс тестирования по.
- •Тестирование модулей (блоков) программы. Тестирование интеграции.
- •Тестирование правильности (функциональное тестирование). Системное тестирование.
- •Особенности тестирования объектно-ориентированных программ. Тестирование классов.
- •Тестирование взаимодействия классов и функционирования компонентов.
- •Вопросы автоматизации тестирования. Инструменты тестирования.
Модели процесса разработки пс (компонентно-ориентированная, инкрементная, rad – модель).
Модель процесса разработки ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует.
Любая модель процесса разработки ПО должна определять кто (какой член команды), что делает (какие действия), а также когда (действия по отношению к другим действиям) и как (детали и этапы действий) делает для достижения цели (цель – создание качественного продукта).
Модель ЖЦ ПО включает в себя:
Стадии;
Результаты выполнения работ на каждой стадии;
Ключевые события — точки завершения работ и принятия решений.
Компонентно-ориентированная модель является развитием спиральной модели. В этой модели конкретизируется содержание квадранта конструирования. Оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов (такие компоненты хранятся в библиотеке).
Инкрементная модель
Впервые эту модель предложил Кратчен в 1995 году. Затем Ройс слегка усовершенствовал ее в 1998 году.
В начале процесса конструирования определяются почти все пользовательские и системные требования. Затем конструирование выполняется в виде последовательности итераций. На первой итерации реализуется часть запланированных функций (возможностей) – самых важных (базовых) или самых рискованных (с высоким уровнем риска. Следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система (реализует все запланированные функции).
Каждая итерация основывается на функциональных возможностях предыдущей итерации. Инкрементная модель обеспечивает на каждом инкременте работающий продукт, который реализует часть функциональных требований. Каждая итерация может рассматриваться как “мини-водопад”.
RAD (от англ. rapid application development — быстрая разработка приложений) — - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.
RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех месяцев путем использования инкрементного прототипирования с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях – обследование организации, выработка требований к системе. Последнее из указанных свойств подразумевает полное выполнение требований заказчика как функциональных, так и нефункциональных, с учетом их возможных изменений в период разработки системы, а также получение качественной документации, обеспечивающей удобство эксплуатации и сопровождения системы. Это означает, что дополнительные затраты на сопровождение сразу после поставки будут значительно меньше. Таким образом, полное время от начала разработки до получения приемлемого продукта при использовании этого метода значительно сокращается.
Принципы RAD технологии направлены на обеспечение трех основных ее преимуществ – высокой скорости разработки, низкой стоимости и высокого качества. Достигнуть высокого качества программного продукта весьма непросто и одна из главных причин возникающих трудностей заключается в том, что разработчик и заказчик видят предмет разработки (ПО) по-разному.
Инструментарий должен быть нацелен на минимизацию времени разработки.
Создание прототипа для уточнения требований заказчика.
Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком.
Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию.
Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей.
Управление проектом должно минимизировать длительность цикла разработки.
Принципы RAD применяются не только при реализации, но и распространяются на все этапы жизненного цикла, в частности на этап обследования организации, построения требований, анализ и дизайн.
Технология быстрой разработки приложений (RAD) позволяет обеспечить:
быстроту продвижения программного продукта на рынок;
интерфейс, устраивающий пользователя;
легкую адаптируемость проекта к изменяющимся требованиям;
простоту развития функциональности системы.