Системы резервного копирования

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

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

MSWord можно настроить и на автоматическое сохранение версий при каждом закрытии документа после редактирования

Служба «теневого» копирования

В WindowsServer 2003 реализована служба «теневого» копирования – ShadowCopies, одинаково подходящая и для целей автоматизации резервного копирования, и для организации контроля версий

ShadowCopies обладает способностью сохранять «снимки» состояния дисковых томов в момент своего запуска.Все изменения, вносимые в содержимое тома после старта и до завершения копирования, фиксируются в журнале транзакций файловой системы.Физическая запись внесенных изменений производится после окончания процедуры копирования. Однако, контроль версий не является главной задачей службы «теневого» копирования, , из-за чего в данном вопросе ей недостает гибкости. В частности, нельзя обслуживать отдельные разделяемые папки, невозможно принудительно сохранить вариант документа в определенный момент времени (только по расписанию) и т.д.

Системы документооборота

Механизмы контроля версий – это почти обязательный атрибут систем документооборота и современных groupware-пакетов, например WindowsSharePointServices

Системы контроля версий с открытым кодом

Широкое распространение программных продуктов с открытым исходным кодом (Opensource) не могло не затронуть и систем контроля версий

Система контроля изменений

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

Билет

Понятие сборки, манифест сборки. Сборка приложения, системы автоматизации сборки.

ОТВЕТ

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

Манифест сборки

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

Имя сборки

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

· «дружественного» текстового имени,

· номера версии,

· идентификатора регионального стандарта,

· идентификатора разработчика

Первая часть имени сборки (атрибут Name) является обязательной и, обычно, содержит имя файла, в котором находится манифест сборки.Идентификатор регионального стандарта (атрибут CultureInfo) применяется только в т.н. сателлитныхсборках, которые могут хранить только ресурсные данные, но не код

Создание сборок представляет собой сложный процесс, включающий большой перечень задач, в том числе:

· компиляцию модулей с исходным кодом,

· генерацию части исходных кодов из декларативного описания;

· генерацию документации по исходным кодам проекта;

· генерацию дескрипторов развертывания по исходным кодам проекта

· конфигурирование проекта под различные версии библиотек;

· перекодирование и архивирование файлов;

· создание инсталлятора

Следует также иметь в виду, что сборка, может иметь специальное назначение (например, демоверсия приложения), что потребуется учитывать при ее создании 

Системы сборки

Для автоматизации процесса сборки приложения разработаны различные программные средства, т. н. системы сборки. Наиболее известными из них являются make (в различных вариантах gmake, nmake), Ant (для Java-проектов), NAnt (для.NET-проектов) и др.

 

БИЛЕТ

Утилита NAnt, файл сборки и его структура. Цели, зависимость целей, описание целей.

ОТВЕТ

NAnt — это свободное (opensource) инструментальное ПО для автоматизации процесса сборки приложений.

Файл сборки

представляющий собой XML-файл, в котором с помощью специальных тегов описываются действия при сборке. Файл сборки соответствует одному проекту.Файл сборки проекта состоит из заданий или целей (targets)

Атрибуты проекта

Для проекта дополнительно могут быть определены:

цель по умолчанию (defaulttarget), которая выполняется при отсутствии других целей;

базовый каталог (basedirectory), используемый в качестве рабочего при сборке приложения

Цель

Цель идентифицируется именем – nameи может иметь дополнительные атрибуты:

· depends – список имен целей, от которых зависит данная;

· if – условие, при котором должно выполняться задание;

· unless – условие, при котором данное задание должно игнорироваться;

· description – краткое описание цели 

Зависимости целей

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

Зависимости

В следующем примере задачи должны выполняться в последовательности Aà Bà Cà D:

< target name=" A" />

< target name=" B" depends=" A" />

< target name=" C" depends=" B" />

< target name=" D" depends=" C, B, A" />

Билет

Документирование процесса разработки. Типы документов управления

Ответ

Документы управления разработкой ПС (processdocumentation), протоколируют процессы разработки и сопровождения ПС. Они обеспечивают связи внутри коллектива разработчиков и между коллективом разработчиков и менеджерами, управляющими разработкой

Типы документов управления

· Планы, оценки, расписания. Эти документы создаются менеджерами для прогнозирования и управления процессами разработки и сопровождения.Отчеты об использовании ресурсов в процессе разработки. Также создаются менеджерами для контролирующих органов

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

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

· Заметки и переписка. Эти документы фиксируют различные детали взаимодействия между менеджерами и разработчиками

Билет

Документирование программного продукта. Документация сопровождения, ее назначение и состав. Пользовательская документация, ее назначение и состав.

Ответ

Документация по сопровождению ПС (systemdocumentation) описывает ПС с точки зрения ее разработки

Эта документация необходима, если предполагается изучение устройства ПС и модернизация его программ

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

Документация по сопровождению ПС можно разбить на две группы:

1. документация, определяющая строение программ и структур данных ПС и технологию их разработки;

2. документацию, помогающую вносить изменения в ПС

 

Документация первой группы содержит итоговые документы каждого технологического этапа разработки ПС и включает следующие документы:

· внешнееописаниеПС (Requirements document);

· описаниеархитектурыПС (description of the system architecture), включаявнешнююспецификацию каждой ее программы;

· для каждой программы ПС - описание ее модульной структуры, включая внешнюю спецификацию каждого включенного в нее модуля;

Кроме того,

· для каждого модуля - его спецификация и описание его строения (designdescription);

· тексты модулей на выбранном языке программирования (programsourcecodelistings);

· документы установления достоверности ПС (validationdocuments), описывающие, как устанавливалась достоверность каждой программы ПС и как информация об установлении достоверности связывалась с требованиями к ПС

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

Документация второй группы содержит Руководство по сопровождению ПС (systemmaintenanceguide), которое описывает:

· известные проблемы, связанные с ПС,

· какие части системы являются аппаратно- и программно-зависимыми,

· возможности дальнейшего развития ПС

Документы, входящие в состав ПС (productdocumentation), описывают ПС

1. с точки зрения его применения пользователями,

2. с точки зрения его разработчиков и сопроводителей (в соответствии с назначением ПС)

Эти документы используются не только на стадии эксплуатации ПС, но и на стадии разработки для управления процессом его разработки

Типы документов продукта

Эти документы образуют два комплекта с разным назначением:

1. пользовательская документация ПС (П-документация),

2. документация по сопровождению ПС (С-документация)

 

1. Пользовательская документация ПС (userdocumentation) объясняет пользователям, как они должны действовать, чтобы применить данное ПС

К этому типу документации относятся документы, которыми руководствуется пользователь: при

· при инсталляцииПС,

· при применении ПС для решения своих задач,

· при управлении ПС (например, когда данное ПС взаимодействует с другими системами).

Категории пользователей

Следует различать две категории пользователей ПС:

· ординарных пользователей ПС

·  администраторов ПС

Ординарный пользователь ПС (end-user) использует ПС для решения задач в своей предметной области и может не знать многих деталей работы компьютера или принципов программирования

Категории пользователей

Администратор ПС (systemadministrator) управляет использованием ПС ординарными пользователями и осуществляет сопровождение ПС, не связанное с модификацией программ

Например, он может

· регулировать права доступа к ПС между ординарными пользователями,

· поддерживать связь с поставщиками ПС,

· выполнять определенные действия для поддержания ПС в рабочем состоянии

Состав документации

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

Режим использования

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

Состав пользовательской документации

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

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

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

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

· Руководство по управлению ПС. Предназначено для системных администраторов и должно описывать сообщения, генерируемые при взаимодействии ПС с другими системами, а также способы реагирования на эти сообщения. Если ПС использует системную аппаратуру, то этот документ может объяснять, как сопровождать эту аппаратуру

Разработка пользовательской документации

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

· предписывается порядок разработки этой документации,

· формулируются требования к каждому виду пользовательских документов,

· определяются их структура и содержание

 

⇐ Предыдущая123456789

Поделиться: