
- •1. Что такое программная инженерия? Когда и как она возникла и что изучает?
- •2. С какими дисциплинами и как связана программная инженерия? Чем она отличается от программирования?
- •3. Что такое программное обеспечение (по)?
- •4.Перечислите и охарактеризуйте свойства пo.
- •5.Что такое процесс создания по? Расскажите о видах процессов.
- •6. Необходимость и способы совершенствовании процессов.
- •7. Что такое модели процессов, виды и фазы деятельности?
- •9. Расскажите о водопадной (каскадной) модели, ее достоинствах и недостатках.
- •10. Расскажите о спиральной модели, ее достоинствах и недостатках.
- •11. Что такое рабочий продукт? Для чего он нужен и как используется?
- •12. Что такое дисциплина обязательств?
- •13. Что такое проект? Что такое управление проектами и что оно включает?
- •14. Дайте определение архитектуре по. Расскажите о причинах множественности точек зрения при разработке по.
- •15. Как и для чего моделируются процессы обработки данных и по?
- •16. Что такое uml, для чего и как используется.
- •17. Расскажите о структуре и элементах языка uml.
- •18. Перечислите и кратко прокомментируйте статические диаграммы uml.
- •19. Перечислите и кратко прокомментируйте динамические диаграммы uml.
- •20. Что такое управления требованиями? Виды и свойства требований.
- •21. Формализация требований и работа с требованиями.
- •22. Что включает конфигурационное управление?
- •23. Что такое управление версиями, управление сборками и baseline продукта?
- •24. Как осуществляется управление качеством в программной и инженерии?
- •25. Методы обеспечения качества по.
- •26. Дайте определение тестирования. Перечислите и кратко охарактеризуете виды тестирования.
- •27. Что такое cmmi? Перечислите и охарактеризуйте уровни зрелости предприятий.
- •28. Расскажите об унифицированном процессе разработки по (rup).
- •29. Расскажите о гибких (agile) методах разработки. Положения Agile - манифеста. Экстремальное программирование.
- •30. Что такое Sсrum? Схема процесса, роли, практики.
- •31. Расскажите об msf. Основные принципы, история создания. Разновидности поддерживаемых процессов.
- •32. Модель команды в msf.
22. Что включает конфигурационное управление?
Конфигурационное управление подразумевает под собой комплекс методов, направленных на то, чтобы систематизировать изменения, вносимые разработчиками в программный продукт в процессе его разработки и сопровождения, сохранить целостность системы после изменений, предотвратить нежелательные и непредсказуемые эффекты, а также сделать процесс внесения изменений более формальным. Конфигурационное управление имеет дело с меняющимися в процессе продуктами, состоящими из наборов файлов. Такие продукты принято называть единицами конфигурационного управления. Вот примеры: 1) пользовательская документация; 2) проектная документация; 3) исходные тексты ПО; 4) пакеты тестов; 5) инсталляционные пакеты ПО; 6) тестовые отчеты.
У каждой единицы конфигурационного управления должно быть следующее: 1) Структура - набор файлов; 2)Ответственное лицо и, возможно, группа тех, кто отвечает за их содержание; 3)Практика конфигурационного управления - кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления версиями, правила именования и комментирования элемента в этой версии, дальнейшие манипуляции с ним там и пр; 4) Автоматическая процедура контроля целостности элемента.
Выделим две основные задачи в конфигурационном управлении - управление версиями и управление сборками.
23. Что такое управление версиями, управление сборками и baseline продукта?
Управление версиями:
Управление версиями файлов.
Управление версиями составных конфигурационных объектов.
Одновременно может существовать несколько версий продукта и соответственно разный набор исходных текстов. И в том и в другом случае в средстве управления версиями образуются разные ветки. Каждая ветка содержит полный образ исходного кода и других компонентов, находящихся в системе контроля версий. Каждая ветвь может развиваться независимо, а может в определенных точках интегрироваться с другими ветвями. В процессе интеграции изменения, произведенные в одной из ветвей, полуавтоматически переносятся в другую.
Управление сборками
Процедура сборки многократно в день выполняется каждым разработчиком на его собственном компьютере, с его собственной версией проекта. При этом отличается:
набор подпроектов, собираемых разработчиком; он может собирать не весь проект, а только какую-то его часть; другая часть либо им не используется вовсе, либо не пересобирается очень давно, а по факту она давно изменилась;
отличаются параметры компиляции.
При этом если не собирать регулярно итоговую версию проекта, то общая интеграция может выявить много разных проблем:
несоответствие друг другу различных частей проекта;
наличие специфических ошибок, возникших из-за того, что отдельные проекты разрабатывались без учете параметров компиляции
В связи с этим процедуру сборки проекта часто автоматизируют, то есть выполняют не из среды разработки, а из специального скирпта - build-скрипта. Этот скрипт используется тогда, когда разработчику требуется полная сборка всего проекта. А также он используется в процедуре непрерывной интеграции - то есть регулярной сборке всего проекта (как правило - каждую ночь). Как правило, процедура непрерывной интеграции включает в себя и регрессионное тестирование, и часто - создание инсталляционных пакетов
Baseline - это базовая, последняя целостная версия некоторого продукта разработки, например, документации, программного кода и т. д. Принятие такой версии сопровождается дополнительными действиями по оформлению, сглаживанию, тестированию, включению только законченных фрагментов и т.д. Это результат можно посмотреть, отдать тестеровщикам, передать заказчику и т. д. Baseline служит хорошим средством синхронизации групповой работы. Baseline может быть совсем простой - веткой в средстве управления версиями, где разработчики хранят текущую версию своих исходных кодов. Единственным требованием в этом случае может быть лишь общая компилируемость проекта. Но поддержка baseline может быть сложной формальной процедурой. Baseline может также поддерживаться непрерывной интеграцией. Важно, что Baseline не должна устанавливаться слишком рано.