Содержание к диссертации
Введение
ГЛАВА 1. Современные методы управления конфигурациями при разработке встроенных программных систем 9
1.1. Процессы разработки встроенных систем 9
1.2. Общая характеристика процесса управления конфигурациями 16
1.3. Требования отраслевых и международных стандартов к процессу управления конфигурациями 19
1.3.1 Процессы управления конфигурациями по ГОСТР 51904-2002 21
1.3.2, Процессы управления конфигурациями по DO-178В 24
1.3.3 Процессы управления конфигурациями по ISO 9001:2000/ISO 10007 26
1.3.4 Процессы управления конфигурациями по AS 9100В / AS 9006В 28
1.3.5 Сравнительная характеристика требований DO-178В, ISO 9001:2000/ISO 10007 и AS 9100В 30
1.4. Компоненты современных систем управления конфигурациями 33
1.5. Современные модели процесса управления конфигурациями 38
1.6. Цель и задачи диссертационного исследования-. 49
ГЛАВА 2. Теоретические аспекты метода управления конфигурациями при разработке встроенных систем 52
2.1. Построение математической модели конфигураций объектов разработки ВС .52
2.1.1 Основные определения 52
2.1.2 Структура конфигурации как формальная теория 54
2.1.3 Древовидные конфигурации как модель формальной теории 56
2.1.4 Процесс создания конфигурации при помощи правил вывода 58
2.2. Построение математической модели вычисления состояний объектов конфигурации 62
2;2.1 Основные определения алгебраической модели вычисления состояний конфигураций 62
2.2.2 Вычисление состояний ОК 65
2.2.3 Типизация конфигураций 72
2.3. Эвристический метод оценки степени завершенности конфигурации 75
2.4. Выводы по главе 77
ГЛАВА 3. Проектирование инструментальных средств управления конфигурациями ...80
3.1. Реляционная модель обобщенного объекта конфигурации 80
3.2. Объект конфигурации как абстрактный класс данных 83
3.3. Жизненный цикл разработки и сопровождения системы управления конфигурациями 88
3.4. Проектирование и реализация системы DMS 90
3.4.1 Общая характеристика системы DMS 90
3.4.2 Инструментальные средства реализации 93
3.4.3 Особенности применения метода вычисления состояний конфигураций в системе DMS 93
3.4.4 Особенности реализации системы DMS 97
3.5. Выводы по главе 107
ГЛАВА 4. Экспериментальная проверка и внедрение разработанных методов и инструментальных средств 109
4.1. Экспериментальная проверка эвристического метода оценки степени завершенности конфигурации COEF 109
4.2. Внедрение, опытная и промышленная эксплуатация системы на предприятии ООО «ДС «БАРС» 114
4.2.1 Методика внедрения и сопровождения системы 119
4.2.2 Процесс внедрения 122
4.2.3 Общая статистика работы системы DMS на предприятии ООО «ДС «БАРС» 124
4.2.4 Общие выводы по внедрению 134
4.3. Внедрение системы DMS в учебный процесс кафедры кибернетики МИФИ... 134
4.3.1 Цели и задачи внедрения 135
4.3.2 Особенности методики внедрения и сопровождения в ходе учебного процесса 135
4.3.3 Результаты внедрения 136
4.4. Выводы по главе 139
Заключение 141
Литература
- Требования отраслевых и международных стандартов к процессу управления конфигурациями
- Основные определения алгебраической модели вычисления состояний конфигураций
- Жизненный цикл разработки и сопровождения системы управления конфигурациями
- Внедрение, опытная и промышленная эксплуатация системы на предприятии ООО «ДС «БАРС»
Введение к работе
Актуальность. В процессе разработки программных систем образуется множество взаимосвязанных между собой результатов проекта проекта — требований, исходных текстов, объектных файлов, описаний тестов и т.п. Согласованные совокупности таких объектов принято называть конфигурациями, а процесс поддержания их изменений и целостности в течение жизненного цикла проекта — управлением конфигурациями.
Процесс управления конфигурациями в различных отраслях регламентируется такими международными стандартами, как DO-178B [67], AS9100B [3], AS9006B [2], ISO10007 [43], ISO/IEC TR 15846 [47], ISO/IEC 15408 [45], IEEE 1042 [40] и пр. Более того, его применение строго обязательно при разработке высококритичных систем, к надежности которых предъявляются повышенные требования, в частности - при разработке авиационных встроенных систем для гражданской авиации.
В ходе разработки высококритичных программных систем основная функция процесса управления конфигурациями заключается в предотвращении неконтролируемого развития проекта и обеспечения гарантии того, что все изменения, вносимые в проект, учитываются и санкционируются в соответствии с принятой технологией разработки. Управление конфигурациями обеспечивает поддержку эволюции и целостности продукта путем идентификации его элементов, управления изменениями, а также при помощи прослеживаемости, аудитов состояния и контроля статуса конфигурации.
В процессе эволюции проекта документы вступают в различные типы отношений, которые в общем случае представимы в виде ориентированного графа. Однако традиционная структура документации проекта представляет собой отношение частичного порядка и фактически задает структуру дерева объектов.
Задачи управления и вычисления состояний конфигураций призваны поддержать функции управления проектом, деятельность коллектива исполнителей и группы сопровождения. На базе механизма вычисления состояний решаются задачи оценки сроков проекта, выявления узких мест, вычисления экономических показателей проекта, прогноза выполнимости проекта, контроля соблюдения технологии.
Анализ наиболее развитых инструментальных систем управления конфигурациями показывает, что почти все они обеспечивают решение задач идентификации, управления изменениями, создания базовых версий.
Однако даже в самых развитых системах в полном объеме не реализована инструментальная подцержка процесса вычисления состояний — этот процесс до сих пор поддерживается при помощи организационных процедур и регламентов.
Увеличение размеров проектов разработки программных систем приводит к резкому возрастанию трудозатрат на оценку состояния проекта и отдельных его частей. В таких условиях необходимо обеспечивать не только организационную, но и инструментальную поддержку процесса вычисления состояний конфигураций. Работа посвящена разработке методов и программных средств, обеспечивающих возможность инструментальной поддержки процесса вычисления состояний конфигураций.
Целью работы является построение методов, моделей и программных средств управления конфигурациями, учитывающих взаимосвязи между объектами конфигураций в процессе вычисления и оценки их состояния. Использование результатов исследования должно обеспечить соответствие инструментальных средств поддержки разработки требованиям современных стандартов создания высококритичного программного обеспечения, а также сократить временные и ресурсные затраты на управление проектом при классической схеме разработки встроенных программных систем.
Для достижения этой цели в работе решены следующие задачи:
- исследованы современные модели и методы управления конфигурациями при разработке встроенных систем, стандарты, регламентирующие процесс управления конфигурациями, существующие системы управления конфигурациями с целью выявления основных характеристик объектов конфигураций, необходимых для вычисления состояний их конфигураций;
- предложено и построено исчисление для задания структуры конфигурации, основанное на натуральном выводе Генцена и соответствующая ему модель конфигураций;
- построена и исследована модель вычисления состояний ОК и конфигураций, основанная на натуральной семантике;
- предложен эвристический подход к оценке близости конфигурации к моменту изменения состояния и исследована его адекватность;
- разработана обобщенная архитектура объектов конфигураций в терминах реляционного и объектно-ориентированного подхода с использованием паттернов проектирования;
- разработана Web-ориентированная система, включающая в себя элементы управления конфигурациями: определение структуры объектов- конфигурации и вычисление состояний;
- разработанные методы и программные средства экспериментально проверены.
Методы исследования. При разработке математического аппарата в диссертационной работе используются методы теории графов, теории аксиоматических систем и формального вывода, математической логики. При разработке программного обеспечения (ПО) используются методы объектно-ориентированного, Web-ориентированного и клиент-серверного программирования, а также паттерны проектирования.
Научная новизна работы. Научная новизна работы заключается в следующем:
— выполнен анализ современного программно-информационного обеспечения для управления конфигурациями при разработке встроенных программных систем, отраслевых стандартов управления конфигурациями, выявлено сходство процессов управления конфигурациями при их применении для управления проектом и общего управления документооборотом, что позволило сформировать общую структуру разрабатываемого программного обеспечения;
- предложена модель определения структуры конфигурации и вычисления состояния объектов конфигураций (ОК), основанная на математическом аппарате формального вывода;
- доказаны следствия теорем об индуктивных определениях и bar-индукции, подтверждающие возможность задания конфигурации в виде формулы формальной теории и включения конфигураций, а также теорема о свертке структуры конфигурации.
— предложен эвристический метод оценки степени завершенности работ над конфигурацией, что дает возможность приближенной» оценки трудоемкости при планировании работ в проектах по разработке ПС.
Практическая ценность. Разработанные методы синтеза и анализа структуры, конфигураций используются для создания обобщенной архитектуры объектов конфигураций, а также при разработке методики внедрения и сопровождения системы управления конфигурациями на предприятии.
Внедрение и сопровождение программных средств на предприятия авиационной отрасли ООО «ДС «БАРС» в течение более чем 3 лет позволило отметить значительное повышение эффективности работы персонала по сравнению с предыдущими системами. Программная система соответствует требованиям стандартов качества ISO 9001:2000 и AS 9100В, что было подтверждено при сертификации предприятия на соответствие этим стандартам.
Методы вычисления состояний объектов конфигураций, предложенные в работе, использовались в ЗАО «ACT» при выполнении работ по проектам Федеральной службы по экологическому, технологическому и атомному надзору.
Внедрение программной системы в учебный процесс кафедры №22 «Кибернетика» МИФИ для обеспечения проектного документооборота при выполнении студентами учебного коллективного курсового проекта по курсу «Технология программирования» позволило значительно повысить эффективность и оперативность обмена между студентами запросами на изменение и отчетами о проблемах. Также система позволила отслеживать состояние работ в студенческом проекте и служила общим репозиторием управляющих документов. По итогам внедрения отмечается значительное увеличение степени достоверности данных об индивидуальном вкладе каждого студента в коллективный учебный проект, что позволило более справедливо оценивать их работу. Кроме того повысилась оперативность получения преподавателем информации о состоянии выданных заданий и статуса проекта в целом.
Положительный опыт использования программной системы подтвержден соответствующими актами о внедрении.
На защиту выносятся:
- исчисление для задания структуры конфигураций, основанное на натуральном выводе Генцена и соответствующая ему модель конфигураций;
- метод вычисления состояний конфигураций, основанный на натуральном выводе Генцена и построенный в терминах операционной семантики;
- доказательства теорем о принадлежности конфигураций к классу индуктивно определяемых понятий и возможности» формульного задания структуры конфигурации, а также теоремы о свертке структуры конфигурации;
- эвристический подход для оценки степени близости конфигурации к моменту изменения состояния и оценки степени завершенности работ над конфигурацией;
- обобщенная архитектура объектов управления конфигурациями;
- программная реализация системы управления документами, включающая в себя средства вычисления состояний конфигураций документов, технология ее сопровождения и внедрения.
Апробация работы. Теоретические положения и практические результаты докладывались на следующих конференциях, семинарах и выставках:
- Научная сессия МИФИ 2003-2008 (г. Москва, 2003 - 2008 гг.) [105, 125, 127-129, 131, 132, 134,138, 147];
- XII-XVI Международные научно-технические семинары «Современные технологии в задачах управления, автоматизации и обработки информации» (г. Алушта, 2003 - 2007 гг.) [126,130, 133,135,137];
- InterSystems-Симпозиум 2004, 2005 (г. Москва, 2004 - 2005 гг.) (см. приложение 11);
- IV и V Открытая всероссийская конференция «Преподавание ИТ в России» (Москва, 2006 г., Тверь, 2007 г.) [148, 150];
- XV Всероссийская научно-практическая конференция «Проблемы информационной безопасности в системе высшей школы» (г. Москва, 2008 г.) [139].
Публикации. По теме диссертации и смежным темам опубликовано
- 2 печатные работы в реферируемых журналах, рекомендованных ВАК для публикации результатов кандидатских и докторских диссертаций [136, 149]
- 2 учебных пособия [145, 146]
- 18 тезисов докладов в сборниках научных трудов конференций [105, 125-139, 147, 148]
Структура и объем работы. Диссертация содержит 4 главы, введение и заключение, 53 рисунка, 16 таблиц, 11 приложений. Общий объем без приложений: 149 стр. (с приложениями 226 стр.). Список использованных источников содержит 152 наименования.
Требования отраслевых и международных стандартов к процессу управления конфигурациями
При разработке систем различного типа (информационных, встроенных, систем реального времени, систем безопасности) технологические требования могут различаться и освещать те или иные аспекты процесса разработки. Тем не менее, обычно внедрение технологии в разработку имеет в качестве цели обеспечение повторяемости результатов и гарантию качества разрабатываемой системы. Это послужило предпосьшкой к созданию документов, определяющих требования к технологии разработки систем международных и отраслевых стандартов качества (например, [2, 3, 43, 67, 104, 103, 116]). В этих стандартах определяются критерии качества, специфичные для каждого из этапов жизненного цикла продукции. Основное назначение стандартов качества — определение требований к технологическим процессам, в т.ч. процессам разработки, соблюдение которых позволяет гарантировать постоянный с точки зрения выбранных критериев уровень качества создаваемых систем.
Неизбежные различия в процессах разработки и эксплуатации систем в разных отраслях послужили предпосылкой создания отраслевых стандартов — стандартов, регламентирующих процессы разработки и сертификации систем, предназначенных для узкоспециального использования (авиационные двигатели, системы информационной безопасности), например DO-178B [67], NSA DBMS Basic Protection Profile [75].
Поскольку область применения стандартов качества достаточно широка (от отдельной отрасли до общей применимости), основным объектом их рассмотрения являются не конкретные методики разработки, а общие технологические процессы.
Большинство стандартов являются ориентированными на процессы, не зависящие напрямую от конкретного жизненного цикла системы. Для каждого. процесса определяются цели и описываются средства удовлетворения этих целей. Для данных жизненного цикла в стандартах представляется описание, которое показывает, что цели удовлетворены.
Основной процесс, рассматриваемый стандартами - выпуск продукции. В, случае разработки программных систем этот процесс — разработка программного обеспечения (вне зависимости от жизненного цикла системы). Процесс разработки обычно декомпозируют на более мелкие подпроцессы.
Подпроцессы могут быть отнесены к трем категориям: процесс планирования программного обеспечения, процессы разработки программного обеспечения, которые обычно включают разработку требований к программному обеспечению, проектирование программного обеспечения, кодирование и комплексирование программного обеспечения; и процессы обеспечения целостности, которые включают в. себя верификацию программного обеспечения, гарантию качества программного обеспечения, управление конфигурациями программного обеспечения и взаимодействие при сертификации.
Процессы поддержания целостности остаются активными в ходе всего жизненного цикла программного обеспечения, в их число входит и процесс управления4 конфигурациями.
Основная задача данного процесса - обеспечение структурной целостности разрабатываемой системы. Структурная целостность достигается при помощи контроля всех компонент, входящих в конфигурацию системы, обеспечения их физической сохранности, контроля и управления изменениями компонент системы.
Применение процесса управления конфигурациями является основным требованием при разработке систем, к их надежности (т.е., согласно ГОСТ 13377-75 [101] и ГОСТ 27.002 [102] - свойству объекта выполнять заданные функции, сохраняя во времени значения установленных эксплуатационных показателей в заданных пределах, соответствующих заданным режимам и условиям использования, технического обслуживания, ремонта, хранения и транспортирования) которых предъявляются повышенные требования, в частности при разработке бортовых авиационных систем, информационных систем большого масштаба, систем безопасности (например, DO-178В [67], NSA DBMS Basic Protection Profile [75]).
В 2002 году Госстандартом России был принят стандарт, регламентирующий требования к разработке и документированию встроенных систем [103].
Процесс управления конфигурации согласно этому стандарту относится к группе интегральных процессов, которые необходимы для обеспечения корректной реализации и качества вьшолнения процессов разработки, и их выходных данных. Интегральные процессы вьшолняются одновременно с процессами разработки- и обеспечивают непрерывную поддержку разработки.
Основные цели процесса управления конфигурациями состоят в том, чтобы обеспечить: - определяемую и управляемую конфигурацию ПО на протяжении всего жизненного цикла; - целостность при тиражировании исполняемого объектного кода для производства ПО или, в случае необходимости, его повторной генерации для проведения исследований или модификации; - управление входными и выходными данными процесса в течение жизненного цикла, что гарантирует непротиворечивость и повторяемость работ в процессах; - контрольную точку для, проверки, оценки состояния и контроля изменений посредством управления элементами конфигурацией определения базовой линии;. - контроль над тем, чтобы дефектам и ошибкам было уделено внимание, а изменения были зарегистрированы, утверждены и реализованы; - оценку соответствия программного средства требованиям; - надежное физическое архивирование, восстановление и сопровождение элементов конфигурации.
Поддержание процесса управления конфигурацией согласно ГОСТ Р 51904-2002 требует выполнения в ходе проекта следующих работ: - идентификация конфигурации; - контроль конфигурации; - определение базовых линий; - управление отчетностью о дефектах; - контроль и просмотр изменений; - отчет о состоянии конфигурации; - архивирование и получение документов; - контроль загрузки ПО; - контроль среды жизненного цикла ПО.
Цель идентификации заключается в однозначной маркировке каждого элемента конфигурации и последующих версий, чтобы установить базис для управления и ссылок на элементы конфигурации. Для этого определяется схема идентификации, определяющая правила маркировки различных типов элементов конфигурации, их версии, ревизии, статуса.
Основные определения алгебраической модели вычисления состояний конфигураций
Построение модели структуры конфигурации будем вести согласно общему подходу к построению формализованных теорий, определенному в книге А.А. Френкеля и И. Бар-Хиллела [152]. При этом к составным частям формальной системы, определенной указанным подходом, добавим понятие функции над термами формальной системы.
Формальная система определяется шестью составными частями:
а) Множество исходных символов А, составляющих алфавит формальной системы. Данный класс разделяется на подклассы: переменные, константы и вспомогательные символы. Множество исходных символов должно быть эффективно перечислимо, т.к. необходимо за конечное число шагов определять, является ЛИ СИМВОЛ ВХОДЯЩИМ В алфавит.
Алфавит А формальной модели конфигураций состоит из следующих компонент: — элементарные ОК, обозначаемые малыми латинскими буквами с индексами: ах,...,ап,Ьх,...; — операции над ОК: операция параллельного включения элементов v и операция последовательного включения элементов л; — сигнатуры функций-конструкторов для создания конфигураций, обозначаемые заглавными латинскими буквами С, возможно с индексами, например: Cx,CDoc,CA; — скобки (,), [, ] для задания структуры конфигураций. Конечная последовательность символов алфавита составляет выражение, т.е. Е = А .
б) Множество-термов Т — подмножество множества выражений, определяемых некоторым набором заданных правил. — каждый элементарный ОК есть терм; — если ах,...,ап — термы, то С(ах,...,ап) -терм; — если ах,а2—термы, то (а, л а2), и (ах v а2) - термы; - каждый элементарный OK может входить в терм не более чем один раз; - никаких других термов, кроме определенных выше, не существует.
в) Множество формул F — подмножество множества выражений, элементы.которого могут быть получены применением правил вывода. Формулы определяются над термами. - всякий терм есть формула; - (А{ л А ) и (Al v А ) есть формулы, если Ах иА2 - формулы.
г) Множество операций и функций О:
- Операция параллельного включения OK Av В, где А и В — термы. Частными случаями? применения:этой операции являются: параллельное.объединение элементарного ОК и конфигурации С van параллельное объединение элементарных ОК в, конфигурацию a, vа2. Результат выполнения операции - конфигурация, задаваемая термом As/ ВєТ;
- Операция последовательного включения ОК АлВ, где АиВ - термы. Частными, случаями применения этой операции являются операция последовательного объединения элементарного ОК и конфигурации С л а и функция, последовательного объединения элементарных ОК, образующая новую конфигурацию а}ла2. Результат выполнения операции - конфигурация, задаваемая термом АлВеТ;
-Функция-конструктор создания конфигурации: G(ax,...,an),, где: av...,an — упорядоченное множество ОК, входящих в конфигурацию. Возвращаемое значение функции - конфигурация, задаваемая термом С(а1}...,ап)єТ, включающим в себя символы, о,-,---, - элементарные OK, v,л - операции над ОК и скобки..
г) Множество аксиом D — подмножество множества формул, служащее основой для правил вывода: Если множество аксиом конечно, то оно задается при помощи перечисления выражений, определяемых некоторым набором заданных правил. В данном случае множество аксиом совпадает с множеством элементарных ОК, т.е. начальными посылками для процесса вывода служат только ОК, все взаимосвязи задаются структурой правил вывода.
д) Множество правил вывода R, содержащее набор правил, согласно каждому из которых множество некоторых формул, составляющих посылку правила, влекут некоторую формулу, составляющую заключение правила: Конечная последовательность формул F называется выводом, если- каждая: формула в данной, последовательности является либо аксиомой либо является членом Г, либо непосредственно выводима из формул, предшествующих ей;в последовательности Г.Формула называется доказуемой, если существует вывод, последней формулой которого она является.
Правила вывода в предлагаемой модели разделены на две группы — правила состояния конфигураций и правила структуры конфигураций. Для. построения правил вывода структуры конфигураций используется; аппарат натурального вывода Генцена [143]. Введем следующие правила вывода, основанные на натуральном выводе: А В а В . (у) (Л) Aw В ал(ВУ
Где а, с—элементарные ОК, а А, В -термы, сверху над чертой приведены посылки правила вывода под чертой — заключение правила вывода.
Для упрощения вида формул, задающих конфигурации, обозначим а v Ъ как а + b, а алЬкак ab. Процесс построения конфигураций с использованием правил структуры конфигураций рассмотрен в разделах 2.1.3-2.1.3.
Правила состояния конфигураций предназначены для описания процесса вычисления состояния конфигурации по состояниям входящих в:нее ОК. В общем виде правило записывается как Ffa] = a, F[x2] = a2 ... F[xn] = gn F[G(xi,x2,...,xn)] = f(al,a2,...,an) т.е. для определения значения искомой характеристики (состояния) F конфигурации С(х1,х2,...,хп) необходимо получить значения состояния F входящих в нее ОКХ,,Л:2,...,Л;П,. равные ах,а2,...,ап. Далее, если полученные характеристики удовлетворяют посылкам правила, то можно получить значение характеристики для заключения как результат применения некоторой функции /(а},а2,...,ап). Процесс вычисления состояний конфигураций с использованием правил структуры конфигураций рассмотрен в разделе 2.2.
Жизненный цикл разработки и сопровождения системы управления конфигурациями
Этап анализа включает в себя три подэтапа. На этапе анализа существующих практик управления конфигурациями составляется общая схема бизнес-процессов предприятия, выделяются информационные потоки, проводимые при помощи обмена документами, роли пользователей, задействованных при обмене документами. Также определяются типы документов, используемые на предприятии, их идентификация, жизненный цикл, методы хранения и разграничения доступа. В результате данного анализа определяются требования к объекту конфигурации, предназначенному для хранения и обработки в рамках системы.
На этапе анализа предыдущих систем проводится исследование свойств систем, ранее применявшихся для управления конфигурациями, выявляются их недостатки и намечаются пути решения.
Для сбора первичных пожеланий по улучшению из будущих пользователей новой системы отбирается фокус-группа, охватывающая разные уровни организационной структуры предприятия, после чего в процессе собеседования протоколируются и группируются по типам пожелания по улучшению.
Разработку системы планировалось вести поэтапно, плавно наращивая ее функциональности в соответствии с постепенно уточняемыми требованиями пользователей. С связи с этим для процесса разработки был выбран жизненный цикл, относящийся к спиральному типу, при этом на каждом витке спирали разрабатывается полнофункциональный прототип системы, реализующий функциональность, в которой возникла необходимость пользователей при использовании прототипа, разработанного на предыдущем этапе. Спираль охватывает этапы «Разработка», «Внедрение», «Сопровождение» жизненного цикла. В зависимости от объема работ, выполняемых на каждом витке, отдельные части этапов могут быть пропущены.
После четкого выявления разбиения системы на отдельные подсистемы, на каждом витке спирали разрабатывается одна подсистема, а этапы жизненного цикла проходятся полностью. Таким образом, благодаря данному типу ЖЦ реализуется этапность разработки и облегчается согласованность с реальными потребностями заказчика. При этом допускается одновременное выполнение финальных этапов одного из витков и начальных этапов следующего за ним витка разными членами коллектива разработчиков.
При первичной разработке системы по результатам анализа разрабатывается концепция новой системы: подходы к автоматизации процессов документооборота, общая структура хранилища данных, общие схемы интерфейса пользователя. После этого разработка системы ведется по классической цепочке — разработка требований, разработка архитектуры, кодирование, тестирование, документирование.
Все этапы процесса разработки регламентируются соответствующими стандартами: 1. Стандарт на оформление требований. 2. Стандарт на кодирование. 3. Стандарт на интерфейс пользователя. 4. Шаблон документации пользователя.
При тестировании системы могут использоваться общие подходы к тестированию, изложенные в работе [145].
Все указанные стандарты разрабатываются или дорабатываются перед началом каждого витка спирали/жизненного цикла разработки и регламентируют деятельности разработчиков на всех стадиях ЖЦ.
На этапе внедрения системы вначале разрабатывается методика внедрения, подробно описывающая работы, выполняемые в ходе данного этапа, выполняется установка системы и переносятся данные из предыдущих систем.
Для практической проверки походов, изложенных выше, должна быть разработана система управления конфигурациями. С учетом дальнейшего внедрения и применения системы на практике были определены следующие необходимые ее свойства: - каждый документ в системе должен быть представлен в виде объекта конфигурации (ОК), т.е. иметь уникальный идентификатор и состояние, а также набор атрибутов, достаточный для хранения данных документа; - в системе должны присутствовать средства определения модели поведения (жизненного цикла) документов и конфигураций, а также средства вычисления состояний документов и конфигураций; - система должна предоставлять средства навигации по базе документов для пользователя; - система должна запрещать одновременное редактирование одного документа несколькими пользователями; - система должна иметь Web-интерфейс и должна быть построена по клиент-серверному принципу; - система должна; иметь возможность интеграции с операционной средой выполнения— ПО сервера, сетевым ПО предприятия и т.п.
Для упрощения именования, системы ей было присвоено название DMS (Documentation Management System);
Было принято решение опробовать, при реализации: системы, DMS следующие: механизмы управления конфигурациями - динамическое управление; жизненными циклами документов, отслеживание изменений документов системы и определение связей между документами;
С технологической точкшзрения в жизненный цикл разработки системы DMS были заложены некоторые особенности, связанные с повышением; общего технологического уровня разработки- как уже было сказано, были приняты стандарты на разработку и составлены требования к пользовательскому интерфейсу (в виде диаграмм использования):
1) Было принято решение разработать стандарты на оформление требований; и кодирование в.виде единого стандарта на разработку cncTeMbiiDMS (приложение ,2),,при-; этом стандарты могли носить рекомендательный; характер; но быть достаточными; для; регламентации процесса разработки системы. При; этом в оформлении? требований; регламентировались только общие принципы построения UML-диаграмм системы, а. стандарт на кодирование включал только общие рекомендации по оформлению исходных текстов, и не содержал строгих указаний по оформлению структурных единиц кода.
2) Было принято решение об отказе от разработки макета пользовательского интерфейса, поскольку при его построении использовались общие концепции, применявшиеся при разработке системы автоматизации работы группы технической поддержки (TSA) [105]. Функциональный состав интерфейса должен быть оформлен в виде UML-диаграмм использования системы. Коррекцию интерфейса планировалось проводить по результатам анализа замечаний, поступивших от пользователей при эксплуатации системы. .
3) Разработку бизнес-логики системы и хранилища документов было решено вести с. использованием инструментальных средств СУБД Cache. За счет этого планировалось обеспечить одновременный доступ к системе множества пользователей, организовать единое целостное хранилище документов и реализовать средства разграничения доступа к документам.
Внедрение, опытная и промышленная эксплуатация системы на предприятии ООО «ДС «БАРС»
Перед внедрением системы DMS на предприятии ООО «ДС «БАРС» была разработана методика внедрения, утвержденная руководством предприятия и включающая в себя последовательность процедур внедрения. Процедуры были разбиты на следующие стадии: 1. Установка системы на сервер предприятия в двух установках — пробной и рабочей. 2. Перенос части документов системы САДО в пробную среду DMS. 3. Обучение пользователей 4. Опытная эксплуатация экспериментальной системы обученными пользователями. 5. Перенос всех документов системы САДО в рабочую среду DMS. 6. Окончательный ввод системы DMS в промышленную эксплуатацию. 7. Сопровождение системы 8. Вывод системы из эксплуатации
В настоящее время выполнены все стадии, кроме вывода системы из эксплуатации. Это связано с тем, что в планах предприятия пока не предусматривается замены для разработанной системы.
В ходе внедрения выполняется- установка системы и переносятся данные из предыдущих систем. Система устанавливалась в двух вариантах: пробном и рабочем. Пробный вариант предназначен для первичного обучения пользователей и использования в качестве «полигона» для испытания пользователями возможностей системы. Рабочий вариант представляет собой официальную версию системы, в которой хранятся реальные рабочие документы. Необходимость в установке двух версий системы была выявлена при анализе опыта внедрения системы САДО; На этапе внедрения системы САДО значительное число отрицательных отзывов пользователей было связано с невозможностью создания пробных версий документов при ознакомлении с ее возможностями.
После установки системы проводится обучение пользователей, один из основных документов при этом - руководство пользователя системы DMS, приведенное в Приложении 5. Основные моменты, рассмотренные в руководстве, включают в себя: 1. Описание требований к настройке клиентского рабочего места. 2. Описание базовых принципов построения интерфейса пользователя. 3. Описание процедур создания документов. 4. Описание процедур поиска документов. 5. Описание процедур редактирования документов. 6. Описание процедур работы с состояниями документов и ведения журнала. 7. Описание процедур работы с почтовыми уведомлениями. 8. Описание типичных сценариев работы с системой.
Кроме полного руководства пользователя существует также краткое руководство, включающее в себя описание основных действий при работе с системой. Данное руководство пользователя написано в соответствии с теми отчетами о проблемах, которые были созданы на основе вопросов, чаще всего задаваемых пользователями.
Было принято решение об исключении из руководства пользователя описания интерфейса администратора системы. Вместо этого был разработан документ, включающий краткий перечень способов выполнения типичных административных действий - удаления неактуальных документов, добавления пользователей, изменения пароля пользователя.
Затем в два этапа проводится собственно обучение пользователей: на первом этапе пользователям читаются общие лекции по использованию системы в их повседневной практике, на втором — проводятся индивидуальные занятия с начальниками отделов и руководителями групп предприятия.
Во время индивидуальных занятий собираются отзывы пользователей, которые затем анализируются. Отзывы пользователей являются основой для составления запросов на изменение. Изменения могут быть внесены в систему на текущем витке жизненного цикла, отложены до начала разработки следующей версии системы или отклонены.
По результатам анализа устраняются проблемы в системе или планируются работы по дальнейшему ее улучшению. По окончанию анализа отзывов система вводится в промышленную эксплуатацию.
После дальнейших модернизаций системы обучение пользователей проводится только по специальному запросу от них (все изменения в системе отражаются в документации), а внедрение системы проводится в рамках процесса «Сопровождение».
На этапе сопровождения выполняется постоянный сбор информации о работе системы - как автоматизированный (сбор информации о состоянии системы и о ее сбоях), так и ручной — сбор пожеланий по улучшениям и проблемам от пользователей. В результате анализа собранной информации планируются изменения системы: определяется влияние изменений на систему, выполняется разработка требований, кода, документации. После этого пользователи оповещаются о скором внедрении обновленной версии системы и система вводится в эксплуатацию.
Отличительная особенность жизненного цикла проекта, проявляющаяся на этапе внедрения - тесное взаимодействие коллектива разработчиков с пользователями на всех его этапах. На этапе разработки требований к системе требования согласовываются с пользователями и уточняются согласно их рекомендациям и пожеланиям.
Особое внимание уделяется макетированию пользовательского интерфейса, пожелания пользователей учитываются при дальнейшей разработке системы. Для облегчения понимания пользователями основных концепций работы системы, макетирование производится с использованием реальных данных, полученных предварительно от пользователей.
На этапе опытной эксплуатации взаимодействие с пользователями расширяется путем проведения обучения их работе с системой и сбором замечаний касательно общих принципов работы системы. Запросы на изменение, формируемые во время опытной эксплуатации, могут затрагивать большую часть системы, поэтому все потенциальные проблемы желательно решать на предыдущих этапах коррекции.
