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