
- •Критерии качества программного средства. Определение качества по в стандарте iso 9126. Многоуровневая модель качества по. Оценочные характеристики качества программного продукта
- •Жизненный цикл программного продукта, фазы жизненного цикла.
- •Этапы классического жизненного цикла, их содержание.
- •3 Билет
- •1.Фаза разработки, этапы процесса разработки.
- •2.Стратегии конструирования по: линейная, инкрементная, эволюционная
- •4 Билет
- •Стандарт iso/iec 12207-95: основные определения – система, модель жизненного цикла, квалификационные требования. Основные процессы, их содержание, работы и задачи процесса разработки.
- •5 Билет
- •Стандарт iso/iec 15504 (spice): оценка возможностей разработчика. Связь этого стандарта с моделью зрелости предприятия sei cmm. Ответ
- •6 Билет
- •Прогностические модели процесса разработки: каскадная, rad, спиральная. Ответ
- •7 Билет
- •8 Билет
- •11 Билет
- •Анализ предметной области: цели и задачи. Модели предметной области. Формальные определения. Классификация моделей.
- •Методология idef0, синтаксис idef0-моделей. Ответ
- •Idef0-модели состоят из трех типов документов:
- •12 Билет
- •Диаграммы потоков данных (dfd-диаграммы) и диаграммы потоков работ (idef3-диаграммы), их использование при моделировании предметной области.
- •13 Билет
- •Объектно-ориентированный анализ предметной области. Методика определения границ системы и ключевых абстракций. Пример проведения анализа. Функциональные и нефункциональные требования к системе.
- •14 Билет
- •Функциональные требования к системе. Способ их представления в виде uml-диаграммы. Пример диаграммы с использованием отношений «расширяет» и «включает».
- •Понятие прецедента и сценария
- •15 Билет
- •Концептуальная модель системы: концептуальные классы, системные события и системные операции. Способ их представления в виде uml-диаграмм. Пример концептуального описания прецедента.
- •16 Билет
- •Диаграммы взаимодействия как элементы концептуальной модели. Синтаксис диаграмм взаимодействия.
- •17 Билет
- •Проектирование программных средств. Цели и задачи этапа проектирования. Понятие модели проектирования, ее отличия от концептуальной модели. Стадии проектирования, их краткая характеристика.
- •18 Билет
- •Задачи, решаемые на стадии эскизного проектирования. Понятие архитектуры пс.
- •Проблема выбора архитектуры. Влияние архитектуры на качественные характеристики пс.(?)
- •19 Билет
- •Понятие модуля и модульного программирования. Преимущества модульного подхода к разработке по.
- •Модули как средство физического структурирования по. Свойства модулей.(?)
- •20 Билет
- •Задачи, решаемые на стадии детального проектирования. Цели и задачи проектирования пользовательского интерфейса. Ответ
- •21 Билет
- •Понятие шаблона. Классификация шаблонов. Стандарт описания шаблонов. Ответ
- •22 Билет
- •Идентификация методов программных классов. Диаграммы классов, способы отображения отношений ассоциации и зависимости. Пример диаграммы классов.
- •23 Билет
- •Тестирование и отладка программного средства. Стадии тестирования и их характеристика. Основные принципы тестирования. Тесты и тестовые наборы. Понятие тестового покрытия.
- •24 Билет
- •Отладочное тестирование.(?)
- •Соотношение структурного и функционального подходов. Примеры реализации.
- •25 Билет
- •Интеграционное тестирование. Виды интеграционного тестирования. Критерии полноты тестовых наборов.
- •Регрессионное тестирование. Критерии завершения отладочного тестирования.
- •26 Билет
- •1.Системное тестирование. Виды системного тестирования. Критерии полноты тестовых наборов Ответ
- •27 Билет
- •28 Билет
- •29 Билет
- •30 Билет
- •1.Понятие версии программного продукта и системы контроля версий. Модели версионирования, их сравнение.
- •31 Билет
- •32 Билет
- •33 Билет
- •34 Билет Документирование процесса разработки. Типы документов управления Ответ
- •35 Билет Документирование программного продукта. Документация сопровождения, ее назначение и состав. Пользовательская документация, ее назначение и состав. Ответ
30 Билет
1.Понятие версии программного продукта и системы контроля версий. Модели версионирования, их сравнение.
Ответ
Системой контроля версий проектов называется комплекс программного обеспечения, назначением которого является централизованное хранение и обработка всех или большей части файлов, из которых состоит проект некоего программного продукта
Под проектом понимается совокупность файлов, включающая:
исходные тексты на различных языках программирования;
исполняемые, ресурсные и библиотечные файлы, необходимые для сборки программного продукта;
исходные тексты файлов справки;
сценарии программ инсталляции;
сопроводительная документация проекта
Версией проектаназывается уникальный идентификатор, обозначающий конечную или промежуточную стадию разработки, на которой была произведена сборка программного средства
Схема контроля версий проекта
Основной задачей системы управления версиями является обеспечение совместного редактирования и использования информации с возможностью разрешения конфликтных ситуаций. Для этого могут использоваться те или иные модели версионирования
Модель Блокирование-Изменение-Разблокирование
Эта модель запрещает одновременное редактирование файла несколькими клиентами. Перед началом редактирования клиент должен заблокировать файл. Тогда доступ к этому файлу других клиентов станет возможен только после снятия блокировки
Пример работы модели
Недостатки модели
Требует повышенного внимания службы администрирования ввиду возможности сохранения блокировки при некорректном завершении клиентом редактирования файла
Приводит к замедлению процесса разработки из-за частых блокировок, выполняемых и в случаях, когда в этом нет необходимости
Блокирование может вызвать ложное чувство безопасности в ситуации, когда два клиента редактируют разные, но зависящиедруг от друга файлы
Модель Копирование-Изменение-Слияние
Каждый клиент связывается с хранилищем проекта и создает персональную рабочую копию - локальное отражение файлов и каталогов хранилища. После этого клиенты работают одновременно и независимо друг от друга, изменяя свои личные копии . По завершении редактирования личные копии сливаются в новую, итоговую версию. Обычно система управления версиями помогает в слиянии, но за его корректное выполнение отвечает человек
Пример работы модели
Пользователь Гарри попытался записать в хранилище исправленный им файл А после того, как пользователь Салли уже зафиксировала там свои итоги редактирования этого файла
Система сообщила Гарри, что его файл устарел
Пример работы модели
Гарри попросил систему обновить его копию файла А. SVN копирует измененный Салли файл А в рабочее пространство Гарри. Создается обновленный файл А с включением изменений, сделанных каждым из пользователей
31 Билет
Система Subversion, ее архитектура. Хранилище, его структура, правки. Команды SVN для работы с хранилищем. Понятия рабочей копии и служебного каталога. Сценарий объединения правок. Конфликты и способы их разрешения.
Ответ
Subversion (SVN)
обеспечивает лучшее управление изменениями структуры каталогов;
более эффективно хранит двоичные файлы;
имеет стандартную возможность возврата к состоянию проекта на определенный момент времени
Subversion — централизованная система (в отличие от распределённых систем, таких, как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере .
Архитектура Subversion
Модель работы
Клиенты копируют файлы из хранилища, создавая локальные рабочие копии, затем вносят изменения в рабочие копии и публикуют эти изменения в хранилище. Несколько клиентов могут одновременно обращаться к хранилищу. При сохранении новых версий используется дельта-компрессия: система находит отличия новой версии от предыдущей и записывает только их, избегая дублирования данных
. Хранилище Представляет собой последовательность фиксированных состояний размещенной в ней файловой системы Хранилище создается с помощью входящей в состав поставки Subversion утилиты SvnAdmin путем выполнения команды: svnadmincreate<путь к репозиторию>
Импорт в хранилище
Сразу после создания хранилище не содержит ничего, кроме пустого корневого каталога
Первоначальное заполнение хранилища осуществляется командой
svnimport<дерево><URLхранилища> -m “Initialimport”
В качестве первого аргумента этой команды задается путь к поддереву, которое будет загружено в репозиторий . В частности, это может быть папка, содержащая некоторый проект. Вторым аргументом команды импорта является URL-адрес, который используется для доступа к хранилищу
Доступ к хранилищу
Получить доступ к хранилищу Subversion можно различными способами – на локальном диске или через ряд сетевых протоколов .
соответствие разных URL-схем возможным методам доступа
Файловая система хранилища
Как правило, хранилище Subversion содержит файлы нескольких проектов. Каждый проект представляется в виде подкаталога файловой системы хранилища . При таком подходе, пользовательская рабочая копия обычно соответствует отдельному подкаталогу хранилища .
На рисунке показано хранилище, содержащее два программных проекта: calc и paint
Правки
Каждое новое состояние файловой системы хранилища называется правкой. Каждая правка получает уникальный номер, на единицу больший номера предыдущей правки. Начальная правка вновь созданного хранилища получает номер 0 и не содержит ничего, кроме пустого корневого каталога
Последовательность правок
Глобальность правок
Номера правок в Subversion являются глобальными, т.е. относятся ко всем, а не только к отдельно взятым файлам. Каждый номер правки соответствует целому дереву, отдельному состоянию хранилища после зафиксированного изменения
Просмотр списка файлов
Список файлов того или иного проекта из репозитория можно просмотреть с помощью команды
svnlist<URL каталога хранилища> -v
Флаг –v указывает на необходимость вывода полной информации о правке, включая ее номер, дату создания и т.д.
Смешивание правок
Следует иметь в виду, что рабочие копии не всегда соответствуют какой-то одной правке в хранилище; они могут содержать файлы из разных правок . Пусть, например, первый разработчик получил рабочую копию из хранилища, у которого самая последняя правка имеет номер 4
4 calc/Makefile
4 calc/integer.c
4 calc/button.c
На данный момент рабочий каталог полностью соответствует правке 4 в хранилище
Допустим, что разработчик внес изменения в файл button.c и зафиксировал эти изменения.При отсутствии других фиксаций будет создана правка под номером 5, и теперь его рабочая копия выглядит следующим образом
4 calc/Makefile
4 calc/integer.c
5 calc/button.c
Предположим, что после этого второй разработчик фиксирует изменения integer.c, создавая правку 6
Если первый разработчик актуализирует свою рабочую копию, то она станет выглядеть так
6 calc/Makefile
6 calc/integer.c
6 calc/button.c
Изменения, внесенные в integer.c вторым разработчиком будут отражены в рабочей копии первого разработчика, как и его собственные, сделанные в файле button.c
Текст Makefile в правках 4, 5 и 6 идентичен, однако Subversion проставляет номер правки 6 для рабочей копии Makefile, чтобы показать что файл не устарел . Таким образом, после выполнения обновления первым разработчиком его рабочей копии, она будет полностью соответствовать текущему состоянию хранилища
Фиксация локальных изменений
После внесения изменений в файл рабочей копии разработчик может зафиксировать внесенные изменения, выполнив команду
svncommit<параметры><путь к файлу>
Например
svn commit -F msgfoo.c
В результате в хранилище создается новая правка
Рабочие копии
Рабочая копия – это моментальный «снимок» состояния хранилища или некоторой его части, сохраненный на компьютере клиента. Рабочая копия представляет собой обычное дерево каталогов, содержащее набор различных файлов. Файлы рабочей копии могут произвольным образом редактироваться разработчиком, оставаясь недоступными другим участникам группы. После внесения изменений в файлы рабочей копии и проверки их корректности разработчик может записать свою версию в хранилище, т.е. опубликовать
Если другие участники проекта производили редактирование тех же файлов и уже опубликовали свои изменения, Subversion предоставляет возможность для объединения этих изменений с рабочей копией данного разработчика
Служебный каталог
Рабочая копия содержит дополнительные файлы, созданные и обслуживаемые Subversion, которые используются при выполнении слияний. В частности, каждый каталог рабочей копии содержит подкаталог с именем .svn который называется служебным каталогом рабочей копии . Файлы в служебном каталоге помогают определить какие файлы рабочей копии содержат неопубликованные изменения, и какие файлы устарели по отношению к файлам других участников
Конфликтная ситуация
Коллективная работа над проектом требует наличия специальных средств поддержки и обеспечения безопасности данных. Конфликтная ситуация, когда два или более разработчиков параллельно редактируют один и тот же файл, внося в него те или иные изменения
Системы резервного копирования
Прообразом систем контроля версий являлись системы резервного копирования файлов
Подобные системы существовали и как отдельные продукты и как компоненты, интегрированные в различные программные средства.Например, возможность резервного копирования имеется в MicrosoftWord и с ее помощью можно вручную «зафиксировать» текущее состояние документа
MSWord можно настроить и на автоматическое сохранение версий при каждом закрытии документа после редактирования
Служба «теневого» копирования
В WindowsServer 2003 реализована служба «теневого» копирования – ShadowCopies , одинаково подходящая и для целей автоматизации резервного копирования, и для организации контроля версий
ShadowCopies обладает способностью сохранять «снимки» состояния дисковых томов в момент своего запуска.Все изменения, вносимые в содержимое тома после старта и до завершения копирования, фиксируются в журнале транзакций файловой системы.Физическая запись внесенных изменений производится после окончания процедуры копирования. Однако, контроль версий не является главной задачей службы «теневого» копирования, , из-за чего в данном вопросе ей недостает гибкости. В частности, нельзя обслуживать отдельные разделяемые папки, невозможно принудительно сохранить вариант документа в определенный момент времени (только по расписанию) и т.д.
Системы документооборота
Механизмы контроля версий – это почти обязательный атрибут систем документооборота и современных groupware-пакетов, например WindowsSharePointServices
Системы контроля версий с открытым кодом
Широкое распространение программных продуктов с открытым исходным кодом (Opensource) не могло не затронуть и систем контроля версий
Система контроля изменений
Система контроля изменений позволяет хранить версии только одного файла, поэтому управлять несколькими файлами приходится вручную. Для обеспечения возможности коллективной работы используется механизм блокировок