Разработка программного модуля регистрации документов
Проектирование модуля регистрации документов. Анализ предметной области, спецификация требований. Построение диаграммы прецедентов Анализ архитектуры модуля в "OpenText Content Server 16.2". Разработка программы регистрации документов, ее тестирование.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 25.08.2017 |
| Размер файла | 1,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
2. Загрузить на «FTP» сервер пакет, в котором присутствует документ с такой же ревизией и статусом, что и один из документов шага 1.
3. Нажать «Download from FTP»
1. Исходящий пакет документов создан.
2. Пакет загружен.
3. Получена соответствующая ошибка.
4. Пакет удален из папки «Incoming Packets».
5. Пакет присутствует в дереве в папке «Rejected».
В ходе проведения тестирования, отклонений от тестового сценария не выявлено. Контрольный пакет документов был обнаружен на этапе проверки атрибутов пакета документов и перемещён в каталог отклонённых пакетов документов.
В комплексе с проверкой статуса пакета документов проходит валидация ревизий документов. Ревизии также проверяются у одноимённых документов, если таковые существуют. Для проведения тестирования валидации ревизий входящих пакетов документов, проведён полный цикл согласования, созданного пакета документов. Созданный пакет прошёл процедуру согласования и каждый документ получил ревизию.
Рассматриваемый пакет документов не был изменён, для того чтобы пройти действия, указанные в тестовом сценарии в таблице 3.5.
В ходе тестирования валидации ревизии документов, не было выявлено непредсказуемого поведения программного модуля.
Таким образом, выявлено, что ошибок, связанных с согласованными документами, в программном коде функций валидации входящих пакетов документов, в ходе первичного тестирования, не найдено. Доработки функций валидации ревизии и статуса документов, в рамках выпускной квалификационной работы, не будет.
Таблица 3.5. Валидация ревизий документов
|
Шаги сценария: |
Ожидаемые результаты: |
|
|
1. Провести полный жизненный цикл с корректным пакетом. 2. Загрузить на «FTP» сервер пакет в котором присутствует документ с такой же ревизией и статусом, что и один из документов шага 1. 3. Нажать «Download from FTP» |
1. Исходящий пакет документов создан. 2. Пакет загружен. 3. Получена соответствующая ошибка. 4. Пакет удален из папки «Incoming Packets». 5. Пакет присутствует в дереве в папке «Rejected». |
Заключительным тестовым сценарием проверки функционала по работе с входящими пакетами документов, является сценарий проверки запуска маршрута согласования документов.
В рамках рассматриваемого функционала необходимо провести тестирование как серверной части программного модуля, так и клиентской. В ходе тестирования процесса запуска маршрута согласования выявлено следующее: расположение блоков веб-интерфейса не соответствует прототипу, из-за проблемы с отображением данных в веб-интерфейсе, запуск маршрута согласования является невозможным, список документов не соответствует составу пакета документов.
Для проведения теста в системе был зарегистрирован корректный пакет документов. Зарегистрированный пакет документов содержит более одного документа, что позволяет протестировать функции отображения атрибутов нескольких документов и обширного числа самих документов. Также, это позволяет протестировать функционал запуска пакетного маршрута согласования документов и присвоения ему атрибутов из категорий документов.
В соответствии с тестируемым функционалом, создан тестовый сценарий, при помощи которого удалось выявить выше описанные ошибки в работе программного модуля. Тестовый сценарий представлен в таблице 3.6.
Таблица 3.6. Тестирование запуска маршрута согласования
|
Шаги сценария: |
Ожидаемые результаты: |
|
|
1. В папке «Documents to proceed» нажать «Make Transmittal». 2. Выбрать пользователей для каждой роли. («Approver» и «Endorser» должны быть разными пользователями). 3. Определить контрольный срок рассмотрения. 4. Нажать «send». |
1. Ошибок нет. Открылся первый шаг запуска процесса согласования входящего пакета документов. 2. Значения атрибутов на первом шаге соответствуют значениям, указанным в ведомости. 3. Атрибуты изменены. 4. Входящий пакет документов создан. 5. Открылась папка «Documents to proceed». |
В заключение тестирования функционала обработки входящих пакетов документов, выявлено, что программный модуль регистрации документов нуждается в доработке. Также необходимо доработать разметку и логику сценария веб-интерфейса запуска маршрутов согласования.
Заключительным этапом тестирования является проверка функционала регистрации исходящего пакета документов.
В качестве контрольных пакетов документов для тестирования процесса регистрации исходящих пакетов документов выступают документы, прошедшие процесс согласования на предыдущих этапах тестирования.
Во время тестирования функционала регистрации исходящих пакетов документов, происходит тестирование как веб-интерфейсов, так и программного кода серверной части программного модуля.
Тестирование регистрации исходящих пакетов документов подразделяется на два этапа: тестирование обычного пакета документов и тестирование пакета документов с комментариями согласующих. Описание тестового сценария представлено в таблице 3.7.
Таблица 3.7. Тестирование создания исходящего пакета документов
|
Шаги сценария: |
Ожидаемые результаты: |
|
|
1. Открыть «DashBoard». Отметить документ в статусе «Reviewed» и нажать «Create Outgoing Packet». 2. Нажать «Generate Number». 3. Нажать «Next». 4. Нажать «Add Document». 5. Нажать «Next». 6. Добавить «Recipient». 7. Нажать «Send». |
1. Открылся мастер регистрации исходящего пакета документов. 2. Сгенерировался «Transmittal number». 3. Открылся второй шаг создания исходящего пакета документов. 4. Открылся третий шаг создания исходящего пакета документов. 5. В списке присутствуют подгруженные документы. 6. «Recipient» добавлен. 7. Произошел переход на «Dashboard». 8. В папке «Outgoing Packets (TE)» на «FTP» сервере появился исходящий пакет документов. |
По завершении тестирования процесса регистрации исходящего пакета документов выявлено следующее: отображение интерфейса редактирования формы не соответствует прототипу, запрограммированные сценарии в веб-интерфейсе редактирования состава документов работают не корректно (документы не добавляются в список, список не масштабируется относительно кол-ва объектов), уведомление о регистрации исходящего пакета документов не отсылается, пакет документов не выгружается на «FTP» сервер.
Исходя из выше перечисленных неисправностей, можно заключить, что основной функционал процесса регистрации исходящего пакета документов работает и необходима доработка лишь косвенных фрагментов программного модуля.
Процесс регистрации исходящего пакета документов с комментариями происходит однотипно, за исключением того, что в состав пакета документов входят комментарии согласующих, и процесс регистрации происходит с учётом параметров исходящего пакета документов с комментариями. Тестовый сценарий представлен в таблице ниже.
Таблица 3.8. Тестирование создания исходящего пакета документов с листом комментариев
|
Шаги сценария: |
Ожидаемые резальтаты: |
|
|
1. Открыть «DashBoard». Отметить документ в статусе «Reviewed» и нажать «Create Outgoing Packet». 2. Нажать «Generate Number». 3. Нажать «Next». 4. Нажать «Add Document». 5. Нажать «Next». 6. Добавить «Recipient». 7. Нажать «Send». |
1. Открылся мастер регистрации исходящего пакета документов. 2. Сгенерировался «Transmittal number». 3. Открылся второй шаг создания исходящего пакета документов. 4. В списке документов присутствует лист с комментариями. 5. Открылся третий шаг создания исходящего пакета документов. 6. «Recipient» добавлен 7. Произошел переход на «Dashboard». 8. В папке «Outgoing Transmittals (TO)» на «FTP» сервере появился исходящий пакет документов. |
В ходе тестирования регистрации исходящего пакета документов с файлом комментариев выявлены те же ошибки, что и без файла с комментарием. Из этого следует, что в доработке процесса регистрации исходящего пакета документов с комментариями нет необходимости.
В завершение тестирования программного модуля необходимо составить таблицу выявленных неисправностей, для последующей доработки. Стоит отметить, что ключевые функции разработанного функционала прошли тестирование без выявления непредсказуемого поведения. Следовательно, можно утверждать, что проект программного модуля разработан достаточно информативно, для реализации разработки для платформы «OpenText Content Server 16.2». Доработки, которые необходимо провести по результатам тестирования перечислены в таблице 3.9.
Таблица 3.9. Результаты тестирования
|
Номер ошибки: |
Ошибка: |
Объект программного модуля: |
Веб-интерфейс: |
|
|
1 |
Не корректная проверка наличия документов во входящем пакете документов. |
Метод «PacketValidation» |
- |
|
|
2 |
Отображение блоков редактирования атрибутов маршрута согласования не соответствует прототипу. |
Метод «SendForReview» |
«SendForReview.html» |
|
|
3 |
Элементы редактирования формы с атрибутами не соответствую прототипу. |
- |
«FormCustomView.html» |
|
|
4 |
Добавленные документы не отображаются в веб-интерфейсе. |
- |
«AddDocs.html» |
|
|
5 |
Список документов не масштабируется. |
- |
«AddDocs.html» |
|
|
6 |
Уведомления о регистрации исходящего пакета документов не приходят на электронный адрес. |
Обработчик событий «ReturnToFtp» |
- |
|
|
7 |
Пакет документов не выгружается на «SFTP» сервер. |
Обработчик событий «ReturnToFtp» |
- |
Таким образом, проведено тестирование функционала программного модуля и выявлены объекты, нуждающиеся в доработке.
Доработка программного модуля регистрации документов
Жизненный цикл дополнительного функционала системы управления проектно-технической документацией проходит по «V-образной» модели жизненного цикла программного обеспечения. Модель изображена на рисунке 3.3.
Рисунок 3.3. Модель жизненного цикла ПО
В ходе написания данной работы описываются лишь некоторые пункты жизненного цикла системы управления проектно-технической документацией ввиду узкой определённости цели работы.
Исходя из используемой модели жизненного цикла программного обеспечения каждая доработка программного модуля после тестирования проходит этап по проверке соответствия проекту разрабатываемого программного решения. Далее происходит исправление программного кода и повторное тестирование.
В соответствии с моделью, каждая доработка должна соответствовать новой версии модуля. Иначе, проведение процесса доработки программного модуля является малоэффективным с точки зрения использования временных затрат и управления обновлениями системы.
Доработки программного модуля осуществляются в хронологическом порядке в соответствии с таблицей ошибок, представленной в предыдущем параграфе.
Первая доработка связана с методом «PacketValidation». Для обнаружения ошибки непосредственно в программном коде, проведён повторный запуск тестового сценария в режиме отладки сервиса.
Ошибка в проверке состава входящего пакета документов заключается в специфике именования объектов платформы «OpenText Content Server 16.2». Непредсказуемое поведение было устранено путём изменения подхода к выбору именной части документов.
Изменения программного кода модуля сохранены в новой версии модуля. Новая версия присваивается модулю аналогично процедуре установки модуля, но обновление модуля происходит после соответствующих манипуляций на странице администратора сервиса.
Следующая неисправность касается отображения блоков редактирования атрибутов в веб-интерфейсе запуска маршрута согласования документов.
В ходе отладки метода «SendForReview» неисправностей программного кода не обнаружено. Таким образом следует, что неисправности отображения блоков не зависят от передаваемых веб-интерфейсу данных.
Выяснено, что неправильное отображение блоков редактирования данных зависит от несоответствия стилей веб-интерфейса стилям платформы. Неисправность устранена путём присвоения элементам веб-интерфейса стандартных стилей платформы. Все изменения также были сохранены в новой версии модуля.
Наиболее трудоёмкой доработкой функционала является исправление недоработок веб-интерфейса редактирования формы с атрибутами пакетов документов. Трудоёмкость доработки заключается в диагностике кода разметки и сценария веб-страницы. Диагностика веб-интерфейса не возможна при помощи отладки программного модуля так, как редактирование формы происходит при помощи стандартного функционала.
Неисправности выявлены в скрытии стандартного функционала представления редактирования формы и в вызове стандартного функционала через разработанные элементы представления.
В качестве доработки представления выступает редактирование верхнего колонтитула: убран вызов функции отображения стандартного верхнего колонтитула. Для доработки вызова стандартных функций, изменены алгоритмы генерирования параметров. После повторного тестирования, непредсказуемого поведения не обнаружено.
Следующие две неисправности касаются редактирования состава исходящего пакета документов во время его регистрации. Обе неисправности происходят в одном веб-интерфейсе и заключаются в некорректной работе со списком документов.
Отладка обработчика событий, запускающего веб-страницу, не выявила непредсказуемого поведения функции. Из отладки программного кода сценария веб-страницы выявлены ошибки в вызове стандартных функций выбора документов и в определении стилей списка документов. Неисправности доработаны путём исправления ошибок в алгоритмах добавления документов в список и присваиванием свойств масштабируемости элементам списка документов.
Заключительные доработки, которые необходимо предпринять на данном этапе касаются обработчика событий «ReturnToFtp». Так, как обработчик событий выполняется на серверной части сервиса, то детализация ошибки происходит при помощи запуска соответствующих тестовых сценариев в режиме отладки сервиса.
Последние две ошибки, указанные в таблице 3.9 находятся в одной части обработчика событий, соответственно, присутствует возможность их одновременного исправления.
Для диагностики проблемы с отправкой уведомлений получателю, первым делом, заменён шаблон уведомления о регистрации исходящего пакета документов на упрощённый вариант, включающий в себя лишь адресат, которому отправляется уведомление. Так, как уведомление дошло до адресата, следовательно, причиной возникновения непредсказуемой ситуации является шаблон уведомления. Из шаблона уведомления решено убрать программный код сценария электронного письма, поскольку обработчик писем принимает программный код сценарных языков программирования веб-страниц как атрибуты и параметры, передаваемые при заполнении шаблона.
Неисправность в выгрузке исходящих пакетов документов удалось выявить сразу на этапе отладки соответствующего функционала. Ошибка заключается в формате пути на «SFTP» сервер, передаваемом из базы данных. Для исправления ошибки, было заменено значение в базе данных.
Таким образом, в заключительной главе проведено тестирование программного модуля регистрации документов и исправлены недоработки, выявленные при тестировании. Создано семь версий программного модуля, в соответствии с количеством доработок.
Заключение
В ходе написания выпускной квалификационной работы были приобретены навыки анализа, проектирования и разработки программных модулей платформы «OpenText Content Server 16.2». В частности, приобретены навыки проектирования процессов при помощи языка моделирования UML и разработки на языках программирования «OScript» и «JavaScript».
В основной части выпускной квалификационной работы были решены задачи, представленные во введении.
Проанализирована предметная область и созданы функциональные требования. Функциональные требования в дальнейшем были специализированы при помощи описания сценариев вариантов использования.
Задача построения диаграммы прецедентов была решена на этапе анализа. На основе сценариев прецедентов созданы связи между ними и актерами. Конечная диаграмма прецедентов отобразила концептуальное поведение проектируемого модуля регистрации документов.
Созданы диаграммы активности, являющиеся декомпозицией прецедентов в рамках их поведения. Диаграммы активности помогли смоделировать приблизительное поведение самих прецедентов.
Построены схемы последовательности, с помощью которых определены основные субъекты, отвечающие за работу программного модуля регистрации документов и взаимодействие с пользователем.
При помощи обобщения диаграмм последовательности, была сгенерирована схема классов. Схема классов показывает смоделированное желаемое поведение модуля регистрации документов и его составляющих.
Последним этапом проектирования было проектирование веб-интерфейсов и таблиц базы данных для модуля регистрации документов. На прототипах веб-интерфейсов изображены методы взаимодействия пользователя с модулем регистрации документов.
Разработан программный модуль регистрации документов в соответствии с архитектурой платформы «OpenText Content Server 16.2».
Разработаны хранимые процедуры, распределяющие нагрузки на программный модуль регистрации документов.
Разработаны веб-интерфейсы, в стандартном стиле, осуществляющие взаимодействие между пользователем и сервисом.
Разработанный программный модуль протестирован и доработан до седьмой версии.
Задача описания процесса разработки программного модуля регистрации документов в ходе написания выпускной квалификационной работы является завершённой.
Данная работа используется на демонстрационном стенде компании ООО «Парма-Телеком» и может быть в дальнейшем использована в различных проектах выше указанной компании.
Библиографический список
1. M. Isaeva, H. Young Paperless university - how we can make it work? 2016 15th International Conference on Information Technology Based Higher Education and Training (ITHET)
2. Open Text Corporation LiveLinkSdk - LiveLink Module Development Guide. 2008.
3. Open Text Corporation Open Text Content Server User Online Guide. 2010.
4. Алан Купер Психбольница в руках пациентов// М.: Символ-Плюс, -2004, -336с.
5. Алексеев А.П. Введение в Web-дизайн: учебное пособие// М.: СОЛОН-ПРЕСС, -2008, -384с.
6. Вора П. Шаблоны проектирования веб-приложений/ Пер. с англ. Райтман М. А. М.: Эксмо, -2011.
7. Белли Л. Изучаем SQL: Учеб. пособие. СПб: Питер, 2012. - 401с.
Приложение
Рисунок А.1.
Рисунок B.1. Диаграмма активности "Запустить маршрут согласования"
Рисунок B.2. Диаграмма активности "Зарегистрировать исходящий пакет документов"
Рисунок B.3. Диаграмма активности "Получить список контрактов"
Рисунок B.4. Диаграмма активности "Отправить пакет документов подрядчику"
Рисунок B.5. Диаграмма активности "Получить пользователей для рассмотрения пакета документов"
Рисунок B.6. Диаграмма активности "Зарегистрировать входящий пакет документов"
Рисунок B.7. Диаграмма активности "Пройти валидацию"
Рисунок B.8. Диаграмма активности "Установить сроки рассмотрения"
Рисунок C.1. Диаграмма последовательности "Загрузить пакет документов"
Рисунок C.2. Диаграмма последовательности "Запустить процесс рассмотрения документов"
Рисунок C.3. Диаграмма последовательности "Регистрация исходящего пакета документов"
Рисунок C.4. Диаграмма последовательности "Редактировать атрибуты исходящего пакета документов"
Рисунок C.5. Диаграмма последовательности "Редактировать состав пакета документов"
Рисунок C.6. Диаграмма последовательности "Зарегистрировать пакет документов"
Рисунок C.7. Диаграмма последовательности "Отправить пакет документов подрядчику"
Рисунок C.8. Диаграмма последовательности "Получить пользователей для рассмотрения документов"
Рисунок C.9. Диаграмма последовательности "Установить сроки рассмотрения"
Рисунок C.10. Диаграмма последовательности "Пройти валидацию"
Рисунок C.11. Диаграмма последовательности "Получить список контрактов"
Размещено на Allbest.ru
Подобные документы
Новые направления в развитии информационных систем. Концепция ERP, система universal accounting. Разработка первичных документов регистрации контрактов. Интерфейс документов начисления доходов от предоставленных услуг. Общий вид программного кода.
магистерская работа [3,0 M], добавлен 12.11.2013Проектирование модуля программы 1С: "Поступление и выбытие удобрений", позволяющего вносить данные о клиентах, складах, контролировать поставки удобрений. Анализ предметной области и построение функциональной модели программы, ее отладка и тестирование.
курсовая работа [1,6 M], добавлен 24.02.2015Структурная диаграмма программного модуля. Разработка схемы программного модуля и пользовательского интерфейса. Реализация программного модуля: код программы; описание использованных операторов и функций. Вид пользовательской формы с заполненной матрицей.
курсовая работа [215,3 K], добавлен 01.09.2010Анализ требований к программному продукту. Требования к информационной и программной совместимости. Проектирование архитектуры программного продукта. Виды программ и программных документов. Общие сведения о С++. Технология разработки программного модуля.
дипломная работа [1,2 M], добавлен 05.08.2011Разработка структурной диаграммы программного модуля. Представление схемы для основных расчетов выбранного приложения для создания прямоугольной матрицы. Особенности создания пользовательского интерфейса. Тестирование и отладка спроектированного модуля.
курсовая работа [648,4 K], добавлен 27.05.2015Разработка средствами языка PHP и Фреймворка Yii системы регистрации и аутентификации пользователей на сайте. Проектирование приложения с помощью языка UML, построение диаграммы прецедентов. База данных приложения. Страница регистрации пользователей.
отчет по практике [1,1 M], добавлен 15.09.2014Проектирование программного модуля: сбор исходных материалов; описание входных и выходных данных; выбор программного обеспечения. Описание типов данных и реализация интерфейса программы. Тестирование программного модуля и разработка справочной системы.
курсовая работа [81,7 K], добавлен 18.08.2014Постановка задачи для модуля 1С. Бухгалтерия 3.0. Анализ существующих разработок в области интегрирования данных. Информационное обеспечение модуля "Связь 1С Предприятия 8.2. с "Казначейством". Программное и технологическое обеспечение данного модуля.
курсовая работа [1,5 M], добавлен 10.06.2013Сравнительный анализ технологий тестирования. Разработка программного модуля "Интеллектуальная обучающая система для широкого перечня курсов". Обоснование необходимости и важности этапа отладки в процессе разработки данного программного обеспечения.
дипломная работа [101,2 K], добавлен 17.06.2011Регистрация документов как один из видов документационного обеспечения деятельности организации. Формы автоматизации регистрации документов. Функции систем автоматизации делопроизводства и документооборота.
реферат [23,8 K], добавлен 21.03.2006
