Программная инженерия вопросы к экзамену

1. Цели и задачи технологий разработки ПО. Особенности современных крупных проектов разработки ПО.

2. Понятие программная инженерия. Основные, вспомогательные и организационные процессы программной инженерии.

3. Структурный подход к проектированию ПО. Сущность структурного подхода.

4. Объектно-ориентированная разработка программ. Объектно-ориентированные языки программирования. Объектно-ориентированные методологии разработки программных систем.

5. Каскадная модель жизненного цикла ПС: содержание этапов, область применения, достоинства и недостатки.

6. Эволюционная модель жизненного цикла ПС: последовательность действий, область применения, достоинства и недостатки.

7. Спиральная модель разработки ПО: содержание этапов создания ПС, область применения, достоинства и недостатки.

8. Инкрементальная модель разработки ПО. Развитие инкрементального подхода. XP-процессы.

9. Понятие программного проекта. Управление программным проектом. План и содержание его разделов. Составление сетевого графика работ.

11. Состав и структура коллектива разработчиков программного продукт, их функции. Составление расписания (PERT-диаграммы)

12.  Управление документацией разработки программного продукта.

13. Рациональный Унифицированный Процесс. Динамические аспекты процессов: структура ЖЦ, стадии, итерации и контрольные точки.

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

15. Внешнее описание программного средства и спецификация. Виды требований к ПО: системные, функциональные, характеристики качества.

16. Методы определения и формализация требований к ПО.

17.  Понятие качества ПО и его многоуровневая модель.  Характеристики и атрибуты качества.

18. Разработка требований к ПО: формирование и анализ, документирование, аттестация. Управление.

19. Алгоритмическая декомпозиция. Модульное программирование. Характеристики программного модуля. 

20. Модели архитектур с различными способами обмена данными: репозиторий, «клиент-сервер».

21. Архитектуры с различными моделями управления.

22. Событийно-управляемые архитектуры.

23. Модели архитектур с различными подходами к обработке данных: непрерывная обработка, каналы и фильтры.

24. Объектно-ориентированная декомпозиция. Общая характеристика объектов. Виды отношений между объектами. Агрегация.

25. Абстрагирование. Общая характеристика классов. Виды отношений между классами. Ассоциации классов. Наследование. Полиморфизм. Агрегация.

26. Повторное использование компонентов. Инкапсуляция. Интерфейсы. Компонентная объектная модель (СОМ).

27. Принципы проектирования пользовательского интерфейса.

28. Структурное тестирование. Покрытие операторов, ветвей, условий.

29. Функциональное тестирование. Метод эквивалентного разбиения, граничных значений, причинно-следственных (функциональных) диаграмм.

30.Тестирование интеграции компонентов ПО: нисходящее и восходящее. Понятие драйвер и заглушка. Стохастическое тестирование.

31. Разработка программной документации. С-документация и П-документация.

32.Отладка ПО: цели и методы. 

33. Управление конфигурацией ПО. Системы контроля версий. Регрессионное тестирование.

34. Аттестация ПО. Оценка качества ПО.

35. Инструментальные средства разработки ПО. Автоматизация разработки ПО. CASE-средства.

36. Сопровождение ПО. Основные подходы: с целью исправления ошибок, адаптации и изменения функциональных возможностей. Решение проблемы эволюции ПО – рефакторинг, реинженерия, реверсная инженерия.

ПРОГРАММНАЯ
ИНЖЕНЕРИЯ

Вопросы
для подготовки к экзамену для студентов
очной формы обучения

1. Предпосылки
   появления «Программной инженерии» как
   дисциплины

2. Определения
   «Программной инженерии» как дисциплины

3. Этапы развития
   программной инженерии

4. Жизненный цикл
   ПО.

5. Модели программного
   процесса ЖЦ ПО: сравнительнаяхарактеристика

6. Модель RAD:
   краткая характеристика

7. Модель RUP: краткая
   характеристика

8. Методы программной
   инженерии (примеры, краткая характеристика)

9. DFD, IDEF0, UML в
   программной инженерии

10. Диаграмма Вариантов
    использования: основные компоненты и
    принципы построения

11. Основные
    отличительные характеристики Диаграмм
    вариантов использования на системном
    и бизнес уровне.

12. Диаграмма
    Деятельности: основные компоненты и
    принципы построения

13. ER- диаграммы в
    нотации Баркера. Основные понятия и
    обозначения

14. Первая нормальная
    форма (основные понятия, примеры)

15. Вторая нормальная
    форма (основные понятия, примеры)

16. Третья нормальная
    форма (основные понятия, примеры)

17. Архитектура ПО.
    Принципы разработки архитектуры
    ПО(множественность точек зрения)

18. Требования к ПО.
    Свойства требований.

19. Варианты формализации
    требований к ПО

20. Цикл разработки
    требований к ПО.

21. Структурированный
    язык запросов баз данных SQL. Синтаксис
    запросов
    SELECT, DELETE,
    INSERT,UPDATE.

22. Технология ADO
    Net. Объектная модель ADO Net.

23. Подсоединенные
    объекты– общая характеристика.

24. Отсоединенные
    (автономные) объекты– общая характеристика.

25. Работа с подключенными
    классами ado .net . Класс Connection.

26. Защита сведений
    о соединении (Connection) с помощью построителей
    строк подключения.

27. Защита сведений
    о соединении (Connection) с помощью использования
    файлов конфигурации.

28. Работа с подключенными
    классами ado .net . Класс Command.

29. Работа с подключенными
    классами ado .net . Класс DataReader.

30. Работа с подключенными
    классами ado .net . Класс Parameter.

31. Работа с автономными
    объектами. Класс DataSet, DataTable, DataRow – общая
    характеристика.

32. Возможности поиска
    и фильтрации объекта DataTable.

33. Объект DataView:
    создание, свойства, методы.

34. Объект DataAdapter –
    создание, использование метода Fill.

35. Передача обновлений
    в базу данных с помощью объекта
    DataAdapter.

36. Создание
    пользовательского интерфейса посредством
    связывания с данными. Объект BindingSource и
    простая привязка данных.

37. Создание
    пользовательского интерфейса посредством
    связывания с данными. Объект BindingSource и
    сложная привязка данных.

38. Создание
    пользовательского интерфейса посредством
    связывания с данными. Объект
    BindingNavigator,
    его свойства и методы

39. Создание отчетов
    приложений средствами ReportViewer.

40. Создание отчетов
    приложений в формате MS
    Excel средствами COM-объектов
    в Visual
    Studio.

Соседние файлы в папке Экзамен

• #
• #
• #
• #

Подборка по базе: Практические задания по дисциплине ИСТОРИЯ И КУЛЬТУРА СТРАН АНГЛ, манипуляции к экзамену.docx, Основы использования и конфигурирования 1С Предприятие Вопросы.o, Кушнир_ответы на вопросы_1 раздел.docx, Отчет по лабораторной работе №10 По дисциплине.docx, Задание к семинару №2 по дисциплине Введение в профессиональную , ВОПРОСЫ К ЭКЗАМЕНУ ПО ИСТОРИИ-1.doc, ИТОГОВЫЙ КОНТРОЛЬ ПО ДИСЦИПЛИНЕ рус яз.docx, Вопросы к экзамену по ТСП.doc, Контрольная работа по дисциплине ‘Экономический анализ’_ Контрол

Вопросы к экзамену по дисциплине «Программная инженерия»

Теоретический вопрос

1. Сущность программной инженерии (ПИ). Связь c computer science. Особенности в сравнении и другими инженерными дисциплинами. Свод знаний и ПИ SWEBOK

Программирование и программная инженерия – это ремесленный и технологический подходы в разработке ПО, а поскольку результатом является программный код, то в производстве программного кода. В программировании-ремесле важны инструменты, приемы, навыки и опыт, в программной инженерии – технологии (нормативы, организация, контроль процесса труда и качества продукта).

В данном случае имеет место не противопоставление, а скорее взаимное дополнение деятельностей, в которых участвует программист. Все, что направлено на сам код, является элементами ремесла. Все, что направлено на взаимодействие с другими участниками процесса, управляющей средой, – инженерия.

Отношения достаточно специфические. Самое главное, что научные знания в этой области не содержат фундаментальных или рамочных законов, которые имеют место в естественных науках – фундаментальных и прикладных. Например, архитектура моста может быть какой угодно, но сопромат позволяет оценить запас прочности конструкции.

В программной инженерии невозможно проверить проект на прочность или получить его фундаментальную характеристику типа массы до тех пор, пока он не будет введен в эксплуатацию. Отсутствие таких законов должно компенсироваться тестированием проекта и его компонент на всех этапах разработки.

Что касается отдельных компонент компьютерной архитектуры, организации вычислительных процессов и конкретных областей приложений, то из компьютерных наук вполне могут быть полезны:

• теория информации;
• теория алгоритмов – доказательство принципиальной невозможности существования алгоритмов и соответственно разработки программ для решения определенного рода задач (алгоритмическая неразрешимость);
• структуры данных и алгоритмы, дискретная математика, теория графов – типовые способы организации данных, эффективные способы работы с ними, решение частных задач путем сведения их к стандартным математическим представлениям и решениям;
• трудоемкость и эффективность алгоритмов – оценка эффективности алгоритмов и программ «в перспективе» в зависимости от роста объемов входных данных, масштабирование;
• математические основы предметной области (например, обработка сигналов, криптография) – методы и алгоритмы решения задач в конкретной предметной области, наукоемкое ПО;
• формальные языки и трансляторы – эффективное использование языков и средств разработки на основе понимания принципов их работы: синтаксис и семантика формальных языков, формальные модели (автоматы, стековые автоматы), описания, «зашитые» в код, и метасистемы.

Знания компьютерных наук обеспечивают качество ПО, но не гарантируют успех его разработки.
Общее в проектной деятельности всех видов:

• получение продукта с гарантированным функционалом, качеством и другими свойствами, с известными сроками исполнения и в рамках отработанного технологического процесса;
• общие принципы управления проектом (менеджмент), изложенные в своде знаний по управлению проектами (PMBOK) [37].

Специфика программной инженерии:

• основанием программной инженерии является информатика, а не естественные науки;
• основной акцент делается на дискретной, а не на непрерывной математике;
• концентрация на абстрактных / логических объектах вместо конкретных / физических артефактов;
• отсутствие производственной фазы в традиционном смысле в форме «проектирование – изготовление»;
• сопровождение программного обеспечения в основном связано с продолжающейся разработкой или эволюцией, а не с традиционным физическим износом;
• нематериальный характер продукта, нулевые затраты на тиражирование, аналогии с интеллектуальной собственностью;
• отсутствие аналогов изделия в окружающем мире. На ранних стадиях разработки – создание программных прототипов как материальных аналогов проекта;
• отсутствие охватывающих объективных законов и невозможность теоретического расчета и проверки. Работоспособность проекта проверяется тестированием готового продукта или верификацией артефактов разработки;
• затраты на непосредственное производство «материальных ценностей», т. е. конструирование кода составляют 20–25 % стоимости проекта;
• материальная основа проекта – программный код является гибкой субстанцией, допускающей в любой момент внешнее качественное усовершенствование и коренную перестройку – рефакторинг и реинжиниринг.

1. Жизненный цикл (ЖЦ) программного продукта и проекта. «Легкие» и «тяжелые» модели процессов разработки ПО. Этапы и технологические процессы (дисциплины) ЖЦ. Результаты этапов и основные документы. Каскадная, итеративная и спиральная модели.

Жизненный цикл (ЖЦ) – период существования ПО (ПС), включающий разработку, эксплуатацию и сопровождение программного продукта, охватывающий жизнь системы от установления требований к ней до прекращения ее использования.

Модель жизненного цикла – описание структуры и ключевых идей организации жизненного цикла. Модель ЖЦ определяет характерные черты, которые объединяют родственные методологии.

Технологические процессы ЖЦ (из RUP):

• Моделирование предметной области;
• Управление требованиями;
• Анализ и проектирование;
• Реализация (конструирование)
• Тестирование;
• Распространение ПО (установка, обучение);

Вспомогательные:

• Управление проектом (организация, менеджмент);
• Управление конфигурацией (сопровождение);
• Управление средой разработки;

Каскадная модель ЖЦ

Каскадная модель предполагает однократное последовательное выполнение всех технологических процессов (рис. 1.4). Принятое решение на определенном этапе не может быть отменено по результатам последующих этапов, все непринципиальные ошибки исправляются тестированием. Несмотря на свою архаичность, каскадная модель в целом или на отдельных этапах применяется в крупных проектах, а также при передаче отдельных компонент на стороннее исполнение – аутсорсинг. Например, конструирование и тестирование отдельного приложения могут быть переданы после завершения этапа анализа и проектирования системы на стороннюю разработку.

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

Итеративная модель ЖЦ

Итерация – шаг разработки, завершающийся получением согласованных артефактов системы – программного прототипа, релиза, моделей и документов. Важным здесь являются логическая завершенность и согласованность артефактов, создающих целостность – модель или работающий проект.

Инкремент – добавление функциональности, не сопровождаемое качественными изменениями свойств системы, чистая «дельта» функционала. Итеративная модель предполагает, что разработка проекта идет в виде последовательности итераций. Итерация связана с понятием эволюции проекта. Под эволюцией понимается качественное изменение свойств проекта – модели или реализации. Итерация с точки зрения эволюции может быть двух видов:

• чистый инкремент: детализация требований, функциональности, архитектуры и их реализация в коде;
• эволюция требований, функциональности, архитектуры, которая сопровождается реинжинирингом кода и других артефактов, т. е. качественной перестройкой системы. При этом ревизия может распространяться от функциональности отдельных компонент до общих принципов организации системы вплоть до бизнес-требований и архитектуры.

Окончание итерации согласованными артефактами позволяет приступить к их тестированию и верификации. Это, в свою очередь, позволяет снизить неопределенность в трудоемкости и сроках исполнения и оценить возникающие риски (рис. 1.5).

Спиральная модель

Спиральная модель [5] является расширением итеративной: итерация является эволюционной и предполагает глубокую ревизию всех артефактов и свойств системы (рис. 1.6).

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

Все методологии и связанные с ними артефакты (модели, стандарты, фреймворки) можно позиционировать по двум качественным осям (рис. 1.7):

• используемая модель жизненного цикла: каскадная или итерационная;
• степень тяжеловесности и формализации: легкие (неформальные) и тяжеловесные (формальные).

Вторая ось касается нескольких аспектов разработки:

• степень охвата жизненного цикла: легковесные – тяжеловесные процессы. Некоторые деятельности могут отсутствовать в методологии, если они в малой степени присутствуют в проектах, например, в связи с его масштабом. Они пускаются на самотек или просто на оговариваются в методологии;
• уровень формализации документов: низкий – высокий. Используются канонические, стандартные формы артефактов и документов, либо их формат и содержание не оговариваются;
• степень формализации взаимоотношений исполнителей: низкая (гибкие) – высокая (традиционные). Практикуются формальные документированные взаимоотношения либо стимулируются неформальные коммуникации и создание доверительной атмосферы.

1. Унифицированный процесс UP. Фазы жизненного цикла: исследование, анализ, реализация, внедрение. Содержание и результаты фаз. Итерация и ее рабочие потоки: требования, анализ, проектирование, реализация, тестирование, их содержание.
2. Фаза исследования. Основные дисциплины и артефакты. Дисциплина «анализ предметной области», бизнес-анализ. Функциональные диаграммы. Диаграммы потоков данных, деятельности. Моделирование предметной области.
3. Фаза анализа и проектирования. Дисциплина «анализ требований». Способы извлечения и фильтрации требований. Бизнес-требования, бизнес-требования, системные требования, функциональные требования. Разработка и управление требованиями. Документ «спецификация требований к ПО». Диаграммы прецедентов.
4. Фаза анализа и проектирования. Понятие архитектуры, ее многомерность. Основные методы проектирования и их особенности: структурное, функциональное, объектно-ориентированное, компонентное, проектирование на основе структур данных. Классы анализа. Виды классов: граница, управление, сущность. Диаграммы устойчивости. Архитектурные аспекты технологического процесса проектирования (по SWEBOK)
5. Фаза анализа и проектирования. Дисциплина проектирование (design). Ключевые моменты проектирования по SWEBOK: параллелизм, контроль и обработка событий, распределение компонентов, обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости, взаимодействие и представление (MVC), сохраняемость данных (доступность «долгоживущих» данных).
6. Фаза анализа и проектирования. Многоуровневая архитектура клиент-серверных приложений. Тонкие и толстые клиенты. Локальное и сетевое взаимодействие слоев через интерфейсы и протоколы. Совместное использование кода различными типами клиентов.
7. Фаза анализа и проектирования Проектирование графического интерфейса (GUI). Основные аспекты. Архитектурное проектирование, основанное на GUI. Факторы, характеризующие GUI: производительность, человеческие ошибки, обучение, субъективное восприятие, запоминание, поиск, визуализация, навигация
8. Виды моделей. Сущность UML как средства моделирования. Структура UML, статическая и динамическая составляющие модели. Составные элементы: сущности, отношения, диаграммы. Виды сущностей: структурные сущности – класс, интерфейс, кооперация, прецедент, активный класс, компонент, узел; поведенческие сущности – взаимодействия, деятельности, автоматы; группирующая сущность – пакет, аннотационная сущность – примечание.
9. UML. Виды отношений: зависимость, ассоциация, агрегация, композиция, включение, обобщение, реализация. Отношения. Связи – отношения между объектами. Направленность связи, Сообщения. Диаграммы объектов. Ассоциации – отношения между классами. Свойства ассоциации: имя, кратность, навигация, атрибуты. Рефлексивные ассоциации, деревья и сети. Классы атрибутов ассоциаций (классы-ассоциации). Зависимости. Зависимости использования «use», «call», «parameter», «send» и «instantiate». Зависимости абстракции. Зависимости доступа.
10. UML. Принятые деления: классификатор-экземпляр, интерфейс-реализация. Расширения: ограничения, стереотипы. Классификация диаграмм. Диаграммы классов (объектов). Диаграммы взаимодействий, коммуникационные диаграммы.
11. UML. Диаграммы деятельности. Технология сетей Петри. Параллелизм. Поток управления, узел действия, ребро, узел управления, объектный узел, буферизация и в объектном узле. Объектные узлы – параметры, состояния объектных узлов. Контакты. Прерывающие ребра. Контакты исключений. Потоки объектов. Их аналоги в программировании
12. UML. Диаграммы состояний. Конечные автоматы.
13. Экстремальное и гибкое программирование. Манифест экстремального программирования (XP). Гибкие (agile) технологии. SCRUM. Agile UP, ICONIX.
14. SCRUM как технологический фреймворк.. Терминология. Спринт. Митинг. Собственник проекта. Команда. SCRUM-мастер. Беклог проекта и спринта. Планирование спринта. Диаграмма сгорания. Оценка трудоемкости. Покер-планирование.
15. Оценка программного кода. Метрики кода. Метрики количественные, сложности потока управления и потока данных, метрики ООП, прагматические метрики. Средства оценки качества программного кода.
16. Метрика проекта. Оценка сроков на основании трудоемкости (по Боэму). Оценка на основе собственного опыта. Метод PERT. Оценка на основе функциональных точек. Оценка по отраслевым данным. Метод COCOMO II
17. Управление проектами как инженерная дисциплина. Особенности управления программными проектами. Роль и место УПП в программной инженерии (ПИ). Компоненты организационного (менеджмент) и технологического (исполнение) планирования в УПП.
18. Определение и характеристики риска. Шкалы оценивания последствий и вероятности. Способы идентификации. Реакция на риски. Наиболее вероятные риски по Боэму и Архипенкову. Качественные оценки рисков. Количественные оценки: анализ чувствительности, дерево решений, имитационное моделирование. Управление, направленное на снижение рисков. Вероятностный характер оценивания, его природа. Последствия «агрессивного» планирования. Исходные данные для оценивания, характеристики проекта, используемые в оценивании. Оценка сроков на основании трудоемкости (по Боэму).
19. Понятие программной ошибки. Философия ошибок. Классификационные характеристики ошибок. Отладка, инспекция и тестирование как этапы поиска ошибок Ошибки вычислений и преобразований. Ошибки структурирования кода. Ошибки форматов входных данных. Ошибки форматов внутренних данных и соглашений по данным. Ошибки сборки, конфигурирования, размещения. Ошибки использования ресурсов. Ошибки, связанные с ограничениями по ресурсам. Ошибки реактивности и производительности. Ошибки параллелизма и синхронизации. Ошибки распределенных систем и протоколов. Ошибки пользовательского интерфейса.
20. Структурное тестирование. Тестирование операторов, условий (решений) и путей. Комбинационное тестирование. Пример. Функциональное тестирование. Классы эквивалентности по входным данным. Проектирование тестового покрытия. Классы эквивалентности по граничным условиям. Примеры.
21. Отладка и инспекция программного кода. Сущность отладки. Приемы отладки. Инспекция как неформальный анализ программного кода. Логический и временной анализ. Методы инспектирования. TDD – разработка, управляемая тестированием.
22. Шаблоны_проектирования._Производящие_шаблоны_builder,_factory,_prototype,_singleton._Шаблоны_проектирования._Структурные_шаблоны_adapter,_bridge,_composite,_decorator,_faсade,_flyweight,_proxy’>Шаблоны проектирования. Производящие шаблоны builder, factory, prototype, singleton. Шаблоны проектирования. Структурные шаблоны adapter, bridge, composite, decorator, faсade, flyweight, proxy
23. Шаблоны проектирования. Поведенческие шаблоны command, iterator, mediator, snapshot, observer, state, strategy, method template, visitor.
24. Шаблоны проектирования. Системные шаблоны model-view-controller (MVC), session, transaction
25. Шаблоны проектирования. Шаблоны параллелизма Single Threaded Execution, Two-phase Termination, Asynchronous Task, Lock Object, Read/Write Lock, Scheduler, Double Buffering, Producer-consumer
26. Управление проектом. Функциональная, проектная и матричная структура организации, разрабатывающей ПО. Подбор команды проекта. Функциональная организация команды. Функциональная классификация участников проекта, возможности совмещения функций.

Практический вопрос

Для произвольно выбранного варианта лабораторных работ выполнить черновую разработку одной из компонент:

1. Модель классов предметной области
2. Диаграмма состояний одной из сущностей

Критерии оценки ответа на вопрос 2

1.В диаграмме должны быть все сущности, указанные в варианте

2.Отношения и их кратность должны быть протестированы в возможных сценариях

3.Для поливариантых отношений должны быть использованы интерфейсы/абстрактные классы

4.В диаграммах классов и состояний должны быть учтены границы проекта и его видение

5.В модель предметной области не включаются отношения между сущностями, если они не сохраняются в системе

6.Диаграмма классов предметной области описывает содержание системы, а не ее поведение, физическую конфигурацию и т.п.

7.В модель предметной области не включаются временные сущности и отношения

Требования к содержанию

Предметная область, как и любая другая система, в методологии ООП описывается в виде структурной и поведенческой компонент (статика и динамика системы).

Описание структуры начинается с установления бизнес-сущностей и структурных отношений (связей: ассоциаций и генерализации/наследования). В UML такому представлению соответствует диаграмма классов, здесь она называется диаграмма классов предметной области.Если быть совсем точным, то диаграмма классов модели предметной области. Бизнес-сущности заносятся в глоссарий.

Замечание по теме.При описании связей бизнес-сущностей необходимо учитывать особенности поведения системы. При выполнении сценариев системы необходимые сущности должны быть достижимы по связям-ассоциациям. Например, билет в театр может быть куплен в кассе, забронирован по сети, оплачен через платежную систему. Во всех трех случаях необходимы его ассоциации с различными бизнес-сущностями (касса/смена, клиент, аккаунт в платежной системе). Поэтому вопрос, что определять в первую очередь, структуру или процессы, описывающие поведение, остается открытым.

Модель предметной области в бизнес-аналитике тесно связана с системной аналитикой (управление требованиями). При внедрении система сама становится частью бизнес-процесса, структура предметной области адекватно в ней отображается. Поэтому модель предметной области (в частности, диаграмма классов) преобразуется в модель анализа. Возможные варианты такого преобразования:

бизнес-процессы не меняются, часть их переходит в безбумажные технологии, часть физических процессов отслеживается системой путем фиксации их текущего состояния в бизнес-объектах и БД;

бизнес-процессы оптимизируются с учетом технологий и решений, предоставляемых системой;

система создает собственную модель бизнес-процессов, опираясь на существующие аналоги.

Типичные ошибки при разработке диаграммы классов предметной области:

диаграмма классов предметной области описывает содержание системы, а не ее поведение. Поэтому сущности типа «оформление заказа», «приобретение билета» сюда не относятся.

в модель предметной области не включаются временные сущности и отношения, например: данные об отчете, если он только генерируется и выводится, но не хранится в архиве отчетов в виде файла;

в модель предметной области не включаются отношения между сущностями, если они не сохраняются в системе, не используются в описании ее поведения. Например, зритель, покупающий билет в кассе, взаимодействует с системой опосредованно через кассира, данные о нем в этом случае не сохраняются, поэтому отношения клиент — кассир (касса, смена) в модели отсутствуют.

При наличии различных вариантов реализации отношения между бизнес-сущностями оно должно устанавливаться между сущностью и интерфейсом или абстрактным классом. Например: билет может быть продан через кассу, забронирован через интернет, либо оплачен через платежные системы. Отношение устанавливается между сущностями билет — способ продажи как интерфейс или абстракция, от которой наследуются сущности через кассу, бронирование, через платежную систему.

Варианты заданий к практическому вопросу – предметная область проектирования.

1. Система продажи билетов в кинотеатре. Клиент, кассир, смена, билетер, администратор, планирование сеансов, продажа билетов кассиром, бронирование и продажа через Интернет, финансовые отчеты, план зала.

8.Система продажи театральных билетов. Приложение кассира — множество точек продажи, приложение распространителя, бронирование через Интернет, связь с платежными системами, план зала (мета-уровень описания), спектакли, репертуар.

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

10.Система автоматизированного заказа такси через Интернет. Серверное приложение для автоматического распределения заказов с учетом нагрузки, web-приложение и мобильное приложение для клиентов, приложение водителя, приложение администратора для форсмажорных и конфликтных ситуаций. Автоматическое распределение заказов на основе расстояния для клиента и других критериев, предложение свободных заказов водителю, голосование за заказ, мониторинг прохождения заказа. Виды адресов с привязкой к GPS-координатам: почтовый, место, корпоративный (фирма, организация).

11.Система ведения корпоративной адресной базы для мобильных клиентов. Типы адресов: служебный — подразделение, корпус, кабинет, домашний — почтовый. Типы контактов: электронная почта, телефон, социальная сеть, адрес. Административная структура организации. Хранение списка контактов, обмен контактами, иерархическая многомерная адресная книга с каталогами (тегами), общая и личная адресные книги.

12.Мессенджер мобильных клиентов аналогичный WhatsUp. Регистрация по номеру мобильного телефона. Передача сообщений, файлов, синхронизация адресных книг, иерархическая многомерная адресная книга с каталогами (тегами), поиск по общей адресной книге, личная адресная книга с собственной системой каталогов (тегов)

13.Мессенджер с прямой связью клиентов. Сервер контактов, регистрация, сохранение IP-адресов клиента и статистики пребывания, авторизация с сообщением текущего IP-адреса, дозвон по списку IP-адресов, прямая связь с передачей сообщений и файлов, локальные адресные книги, обмен адресами.

14.Система заказных грузоперевозок по городу. Клиент, диспетчер, магазин, водитель. Прием и оформление заказов, отчеты и сопроводительные документы, распределение заказов диспетчером. Два вида заказов: точка-точка и развоз товаров со склада по клиентам. Приложение водителя: просмотр заказов, мониторинг проведения заказа, планирование последовательности исполнения для развоза, времени доставки. Приложение диспетчера: прием и оформление заказа, распределение, планирование доставки. Параметры заказа – вес и габариты грузов. Транспортные средства и водители. Оплата доставки авансом и при выполнении заказа.

15.Система продажи билетов на междугородные автобусы. Планирование рейсов, расписание, чартерные рейсы, типы автобусов, планы рассадки, водители, кассиры, смены, визуализация рассадки, приобретение билетов в кассе и в кассовых терминалах, бронирование через Интернет, сводные отчеты по маршруту и дате.

16.Система мониторинга междугородных автобусных перевозок. Карта автодорог, маршрут, график движения по маршруту, планирование рейсов, GPS-навигация транспортных средств, отслеживание графика движения по маршруту, обработка аварийных ситуаций.

17.Система планирования междугородных транспортных перевозок. Транспортные средства — тип, тоннаж, вместимость. Населенные пункты, дорожная сеть, прием заявок, поиск подходящего транспорта с учетом его местонахождения и порожнего прогона, составление маршрута, оформление и проводка заявок, отчеты по периоду времени, транспортному средству, водителю.

18.Система мониторинга междугородных транспортных перевозок Населенные пункты, дорожная сеть, маршрут, планирование движения по маршруту, GPS-навигация транспортных средств, отслеживание графика движения по маршруту, обработка аварийных ситуаций, отслеживание заправки, отчеты по расходу топлива и рабочему времени водителей.

19.Справочная система наличия товаров. Многоуровневая система категорий и марок товара. Мета-система классификационных признаков и их значений, например, вес, цвет, производитель, объем памяти, наличие GPS и т.п.. Торговые сети, торговые точки с привязкой к GPS-координатам. Ассортимент в торговой точке, количество товара. Приложение пользователя: поиск по местоположению, по условиям, сформированным для признаков. Приложение торговой точки – редактирование ассортимента. Приложение администратора – редактирование категорий и марок, классификационных признаков.

20.Логистическая система интернет-магазина с пунктами выдачи и доставкой по городу. Прием заказов, оформление заявок поставщикам, уведомление клиентов, отслеживание работы курьеров, отчеты по пунктам выдачи. Многоуровневая система категорий и марок товара. Мета-система классификационных признаков и их значений, например, вес, цвет, производитель, объем памяти, наличие GPS и т.п.. Наличие товара на складе. Отслеживание балансов по каждому виду товара: заказано, наличие на складе, в заявках к поставщикам. Принятие товара на складе, формирование комплектов заказов для пунктов выдачи и курьеров.

21.Система электронного документооборота учебного процесса в ВУЗе. Структура учебного заведения, факультеты, кафедры, группы, студенты, преподаватели. Сторонние организации. Приказы о зачислении/отчислении, назначении тем выпускных и курсовых работ, распределение на практику, распоряжения по подразделениям. Прохождение приказа: создание, визирование, утверждение, нумерация, рассылка.

22.Система книговыдачи школьной библиотеки с использованием QR-кодов. Систематический и алфавитный каталог книг с учетом экземпляров, рекомендованные учебники по предметам, структура учебного процесса: класс, ученик, предметы, преподаватели, сторонние лица. Формирование комплектов учебников, выдача литературы на абонемент. QR-коды читательских билетов, экземпляров книг, выдача и прием, ведение формуляра с историей, уведомление о просрочках.

23.Система книговыдачи библиотеки с использованием QR-кодов. Алфавитный каталог книг с учетом экземпляров, многомерный иерархический тематический каталог или система тегов. Выдача литературы на абонемент. QR-коды читательских билетов, экземпляров книг, ведение формуляра с историей, уведомление о просрочках. Ведение очередей на дефицитные книги — артефакты, уведомления об очередности.

24.Система управления кафе/баром. План зала, закрепление официантов за столиками, планирование смен. Меню – категории, позиции, описание, привязка к кухне или бару. Проведение заказа: закрепление столика за официантом, выбор по меню, частичный заказ, заявки в бар и на кухню, повторение заказа, итоговый расчет. Приложение посетителя, официанта, бармена – планшет, администратора – desktop.

25.Система бронирования мест для клубных мероприятий. План концертов. Анонсы. Стоимость столиков. План зала — мета-уровень описания, настройка под конкретный клуб. Билеты – столики, танцпол. Электронная предоплата. Бронирование. Приложение кассира. Мобильное или web-приложение клиента.

26.Система бронирования мест в гостинице. Мета-уровень описания конкретной гостиницы – расположение и типы номеров, поэтажные планы, список услуг, фото общие и отдельных номеров, расценки. Бронирование через интернет, визуализация свободных/занятых, расчет стоимости, квитанции, отчеты по периодам. Бронирование индивидуальное и групповое. Балансы по занятым, свободным и забронированным номерам по датам и категориям. Заселение, продление проживание, дополнительные услуги, частичный и итоговый расчет.

27.Система планирования взаимосвязанных работ. Учет сотрудников и их занятости запланированными работами. Определение работ в виде цепочек заданий с параллельными ветвями. Распределение заданий по работникам с учетом их занятости. Сдвиг сроков зависимых работ при задержке выполнения одной из них. Приложения сотрудника, руководителя подразделения, генерация отчетов.

28.Система мониторинга обслуживания по заявкам. Система с предварительным сбором заявок и обслуживанием. Категории и виды работ, исполнители, возможность выполнения ими работ по категориям и видам (квалификация). Прием заявок, планирование исполнения, распределение по исполнителям. Оперативное планирование времени исполнения заявок, отслеживание времени исполнения, коррекция времени при задержках с уведомлением клиентов, отказы. Мобильный клиент сотрудника, приложение диспетчера.

29.Система поддержки технологии SCRUM для удаленной работы. Поддержка основных элементов технологии SCRUM — исполнители (команда), лидер, собственник проекта, истории пользователей (задачи), спринты, беклоги, мониторинг исполнения задач, диаграммы сгорания. Митинги, покер-планирование в режиме чата.

30.Система многомерной организации документов. В качестве документов могут выступать короткие заметки (записи в БД), файлы документов, изображений, звуковых. Поддерживается дерево редактирования версий файла. Создается произвольное количество систем классификаций (каталогов ссылок на файлы) по набору ключевых параметров, например, изображения могут классифицироваться по размеру, цветовой палитре, содержанию, наличию определенных предметов, звуковые файлы по исполнителю, стилю, наличию музыкальных инструментов.

Вся размещенная на ресурсе информационная продукция предназначена для детей, достигших возраста шестнадцати лет (16+)

Вопросы на экзамен по курсу «Введение в программную инженерию»

Работа добавлена на сайт samzan.net: 2015-07-05

Вопросы на экзамен по курсу «Введение в программную инженерию»

1.  Понятие программной инженерии. Основные определения: информатика, системотехника, бизнес-реинжиниринг. Программное обеспечение: определение, свойства.
2.  Процесс разработки программного обеспечения. Понятие процесса разработки ПО. Универсальный процесс. Текущий процесс. Конкретный процесс. Стандартный процесс. Совершенствование процесса. Pull/Push стратегии.
3.  Классические модели процесса: водопадная модель, спиральная модель. Фазы и виды деятельности.
4.  Рабочий продукт, дисциплина обязательств, проект. Понятие рабочего продукта, дисциплины обязательств, проекта. Управление проектами.
5.  Архитектура ПО. Понятие архитектуры ПО. Точка зрения и характеристики точек зрения. Множественность точек зрения при разработке ПО.
6.  Управление требованиями. Виды требований: функциональные требования, нефункциональные требования. Свойства требований: ясность и недвусмысленность, полнота и непротиворечивость, необходимый уровень детализации, прослеживаемость, тестируемость и проверяемость, модифицируемость. Формализация требований. Цикл работы с требованиями.
7.  Конфигурационное управление. Понятие конфигурационного управления. Управление версиями. Понятие «ветки» проекта. Управление сборками.
8.  Конфигурационное управление. Средства версионного контроля. Единицы конфигурационного управления. Понятие baseline.
9.  Тестирование. Стандартизация качества. Методы обеспечения качества ПО. Понятие тестирования. Тестирование черного ящика. Тестирование белого ящика.
10.  Инструменты тестирования. Критерии тестирования. Виды тестирования. Работа с ошибками. Средства контроля ошибок (bug tracking systems).
11.  Диаграммные техники в работе со знаниями. Случаи использования. Работа с требованиями. Случаи использования в управлении разработкой. Итеративный цикл автор/рецензент. Карты памяти.
12.  MSF. IT решение. Основные принципы MSF. Модель команды: основные принципы, ролевые кластеры. Масштабирование команды MSF. Модель процесса. Управление компромиссами.
13.  CMMI. Понятие CMMI. Уровни зрелости процессов по CMMI. Области усовершенствования.
14.  «Гибкие» (agile) методы разработки. Общее описание «гибких» методов разработки ПО. Extreme Programming: общее описание, основные принципы организации процесса.
15.  «Гибкие» (agile) методы разработки. Общее описание «гибких» методов разработки ПО. Scrum: общее описание, роли, практики.
16.  Обзор технологии Microsoft Visual Studio Team System (VSTS). Состав продукта: обзор, клиентская часть VSTS, серверная часть VSTS.
17.  VSTS: управление элементами работ (Work Items). Определение, свойства, жизненный цикл. Реквизиты. Средства использования (на примере элемента работы task). Доступ к элементам работы. Элементы работы при планировании. Элементы работы в дальнейшей разработке. Элементы работы в отчетах.
18.  VSTS: конфигурационное управление. Система контроля версий. Отслеживание изменений отдельных файлов. Правила внесения изменений. Управление ветками. Сохранение без внесения. Автоматические сборки.
19.  VSTS: тестирование. Система отслеживания ошибок. Создание описания ошибки. Связь изменений исходных текстов ПО и ошибок. Система оповещений. Модульные тесты. Пакеты тестов. Автоматическое тестирование Web-приложений.
20.  VSTS: поддержка различных моделей процесса. Поддержка шаблонов процесса. Инструменты настройки. Обзор существующих шаблонов. MSF for Agile Software Development. Scrum.

1. Главная
2. Структура университета
3. Информационный и электронный сервис
4. Студентам
5. Государственный экзамен
6. Вопросы к ГЭК
7. Вопросы к ГЭК по направлению 09.04.04. «Программная инженерия»

Дисциплина «Моделирование»

1. Понятие модели. Цели моделирования. Классификация моделей. 

2. Этапы разработки модели. Планирование и проведение экспериментов с моделью.

3. Метод Монте-Карло. Датчики случайных чисел. Моделирование случайных событий.

Дисциплина «Методология программной инженерии»

1. Профили стандартов жизненного цикла программного продукта. 

2. Системные основы программной инженерии. 

3. Методы планирования и управления ресурсами жизненного цикла программного обеспечения.

Дисциплина «Интеллектуальные системы»

1. Современное определение искусственного интеллекта? 

2. Особенности систем с элементами искусственного интеллекта, роль модуля моделирования и прогнозирования (предикции)?

3. Общая структура и математическая модель системы с элементами искусственного интеллекта?

Дисциплина «Процессы разработки программного обеспечения»

1. Охарактеризуйте стратегии разработки программных средств и систем и реализующие их модели жизненного цикла. 

2. Охарактеризуйте Case-технологии структурного анализа и проектирования программных средств. 

3. Охарактеризуйте методологию объектно-ориентированного анализа и проектирования сложных систем.

Дисциплина «Распределенные программно-информационные системы»

1. Модели и процессы управления программными проектами.

2. Методы планирования и управления ресурсами жизненного цикла программного обеспечения.