Методы и инструментальные средства проектирования систем документооборота программных проектов

• Автор: Хлытчиев, Олег Игоревич
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2008
• Место защиты: Москва
• Количество страниц: 208 с. : ил.

Введение
Глава 1. Исследование подходов к разработке систем документооборота программных проектов

1.1 Стандарты, регламентирующие деятельность компанииразработчиков ПО

1.1.1 Процессы и документы по стандартуГОСТ Р ИСО .

1.1.2 Процессы и документы по стандарту КТ8.И

1.1.3 Процессы и документы по стандартам АБ и А

1.1.4 Процессы и документы согласно модели зрелости СММ

1.2 Понятие информационной системы предприятия

1.3 Подходы к построению систем документооборота

1.4 Методы и средства описания деятельности предприятия

1.4.1 Язык функционального описания ЮЕНО.

1.4.2 яисчисленне язык описания параллельных процессов
1.4.3 Программные средства построения функциональных ЮЕБО моделей
1.5 Цель и задачи диссертационного исследования.
1.6 Выводы.
Глава 2. Метод построения объектной модели системы документооборота
2.1 Метод построения объектной модели типов документов и моделей их ЖЦ
2.1.1 Ограничения ЮЕГО модели
2.1.2 Понятие типа документа и его ЖЦ
2.1.3 1 редставлсиие ЮЕЬО модели в виде ориентированного графа
2.1.4 Суть мегода построения объектной модели типов документов и их ЖЦ по процессному описанию компании
2.1.5 Алгоритм выделения основных объектов на основе ЮЕГО модели компании
2.1.6 Алгоритмы построения ЖЦ типов документов на основе процессных описаний компании
2.2 Предварительный анализ метода построения объектной модели типов документов и их ЖЦ.
2.2.1 Теорема о соответствии и непротиворечивости
2.2.2 Построение процессной модели по документам и ихЖЦ
2.2.3 Описание ЮЕГО диаграмм при помощи яисчисления.
2.2.4 Алгоритм преобразования описаний на языке лисчисления.
2.2.5 Использование лисчислсння для задания настроек системы документооборота.
2.2.6 Обобщенная процессная модель системы менеджмента качества компании, занимающейся разработкой ПО
2.2.7 Модель типового ЖЦ документа системы менеджмента качества
2.3 Модель документооборота ООО ДС БАРС
2.3.1 Схема взаимодействия процессов ООО ДС БАРС
2.3.2 Процессная модель взаимодействия работ, документов и ресурсов ООО ДС БАРС.
2.4 Выводы
Глава 3. Построение инструментального средства автоматизации разработки систем документооборота.
3.1 Средства импорта диаграмм из ЮЕРО.ЕтТоо
3.2 База данных инструмента ЮиМ.
3.3 Архитектура инструмента ЮМ
3.4 Представление полученной в результате преобразования объектной модели
3.5 Выводы
Глава 4. Разработка системы документооборота ООО ДС БАРС
4.1 ЖЦ разрабатываемой системы
4.2 Система документооборота САДО
4.2.1 Требования и цели прототипа системы документооборота
4.2.2 Архитектура системы документооборота САДО.
4.2.3 Интерфейс системы документооборота САДО.
4.2.4 Проблемы внедрения и поддержки системы документооборота САДО
4.3 Полнофункциональная система .
4.3.1 Разработка требований.
4.3.2 Общая архитектура системы документооборота
4.3.3 Основы пользовательского интерфейса.
4.3.4 Три уровня представления информации в системе
4.3.5 Особенности реализации типов документов.
4.3.6 Задание типов документов
4.3.7 Некоторые количественные характеристики системы
4.4 Выводы.
Глава 5. Анализ предложенного метода и инструментального средства разработки систем документооборота и эксплуатационные характеристики реализованной системы документооборота
5.1 Использование построенного средства автоматизации I.
5.1.1 Исходные данные.
5.1.2 Тестирование импорта моделей инструментом I
5.1.3 Преобразование моделей
5.1.4 Оценка разработанного метода и его применимость.
5.2 Эксплуатация разработанной системы документооборота
5.2.1 Сбор информации по системе документооборота САДО
5.2.2 Первые результаты опытной эксплуатации подсистемы управления
ресурсами системы документооборота .
5.3 Выводы
Заключение
Список использованных источников


Система документооборота, обладающая такой функциональностью способна обеспечить работу с любыми документами, требуемыми рассмотренными в работе международными, государственными и отраслевыми стандартами, а так же позволит построить связанный набор документации компании для поддержки необходимых для сс функционирования процессов. Важно понимать, что нельзя получить систему, которая будет удовлетворять всем потребностям вечно. Наступит момент, когда будет необходимо чтото изменить пли добавить в систему. Расширяемая архитектура системы позволить не внедрять сразу во все процессы новую систему, а выполнить это постепенно. Тогда можно решить наиболее актуальные проблемы относительно быстро. Гибкость и модульность информационной системы является ее важным и неотъемлемым свойством. Консорциум разработал и стандарты на интерфейсы основных модулей и на внешние интерфейсы. Наличие таких интерфейсов позволяет использовать разные модули разных поставщиков и интегрировать их для совместной работы. В простые системы документооборота вся функциональность жестко заложена производителем, а компании для внедрения будет достаточно установить полученное программное обеспечение. Можно купить готовую настраиваемую систему. В ходе внедрения такая система будет настроена под конкретные нужны в рамках доступных для настройки возможностей. Большие н сложные информационные системы обычно состоят из модулей, и при внедрении сначала выбираются необходимые модули, а затем производится их настройка. В этом случае можно более точно отразить процессы компании в функциональность системы. С другой стороны увеличивается время на внедрение. Иной вариант это разработать систему под конкретное предприятие. В этом случае система будет полностью удовлетворять всем нуждам компании, но только в случае их четкого определения и ценой длительной разработки и немалых материальных затрат. Какой подход бы ни был выбран, при построении системы документооборота необходимо иметь конкретные требования к ней. Эти требования могут быть получены извне по отношению к компании для ненастраиваемой системы, взяты из описания деятельности предприятия или специально разработаны при проектировании системы. При построении требований следует принимать во внимание определенные аспекты. Вопервых, это стандарты, регламентирующие деятельность предприятия. Это и отраслевые стандарты и стандарты качества и другие. Вовторых, любое предприятие имеет свой накопленный технологический опыт, который следует использовать. Само предприятие к моменту разработки и внедрения информационной системы уже функционирует по определенным правилам, на предприятии могут уже устояться определенные процессы. Дополнительно следует не забывать о наличии готовых решений в области автоматизации и необходимости интеграции разрабатываемой системы е этими решениями рисунок 1. Рисунок 1. Факторы, к. Для средних и крупных компаний, накопивших определенный опыт работы, наиболее предпочтителен вариант настройки системы под процессы компании. Ненастраиваемые продукты используют в основном небольшие компании, которые не имеют четко выраженных процессов и обладают небольшим опытом. Это позволяет им легко перейти на жесткую технологию, предлагаемую разработчиком информационной системы. Далее в данной работе, такие компании рассматриваться не будут, т. Крупные предприятия, в основном, используют большие модульные информационные системы, хорошо зарекомендовавшие себя на рынке, таких как БАР , МБ Ахара . Основная проблема для них это грамотная настройка системы под конкретные процессы компании. Для средних предприятий цена таких систем слишком высока, но, с другой стороны, использовать готовые не настраиваемые продукты они уже не могут. Такие компании встают перед выбором настраиваемых систем среднего ценового класса или самостоятельной разработкой системы заказом разработки. Требования к информационной системе сформулировать достаточно сложно. Несмотря на то, что они, в основном, вытекают из функционирования процессов предприятия, четкая их формализация часто не оправдана и может привести к документу такой сложности, по которому не каждый разработчик сможет построить требуемую систему . Тем не менее, очень важно иметь определенные требования, и оформить их достаточно точно.