CC BY
36
ТЕХНИЧЕСКИЕ НАУКИ
Release Process corporate ERP-system based on Microsoft Dynamics Axapta
Timofeev A.1, Kravchenko A.2 Процесс выпуска релизов корпоративной ERP-системы на базе Microsoft Dynamics Axapta Тимофеев А. А.1, Кравченко А. В.2
'Тимофеев Александр Андреевич / Timofeev Alexander - студент магистратуры, направление: прикладная информатика;
2Кравченко Анатолий Васильевич /Kravchenko Anatoly — кандидат технических наук, доцент, кафедра экономической информатики, факультет бизнеса, Новосибирский государственный технический университет, г. Новосибирск
Аннотация: в данной статье представлен процесс выпуска релизов корпоративной ERP -системы на базе Microsoft Dynamics Axapta. Предложены порядок выполнения работ и график формирования обновления системы.
Abstract: this article presents the release cycle of corporate ERP - system based on Microsoft Dynamics Axapta. A procedure of work and timetable for the formation of the system Upgrade.
Ключевые слова: релиз, регламент, модификации. Keywords: release, regulation, modification.
Релиз — это набор новых и/или изменённых конфигурационных единиц, в отношении которых осуществлено тестирование и которые рекомендованы для использования одновременно [1].
Целью процесса управления релизами является консолидация, структурирование и оптимизация всех изменений или обновлений, а также снижение риска при переводе сервиса на новый качественный уровень. Для достижения поставленной цели необходимо правильно распределить имеющиеся ресурсы и рассчитать баланс между сроками, которые отведены для внедрения всех обновлений, и временем, необходимым для подготовки внесения данных изменений [1].
Релиз корпоративной ERP - системы на базе Microsoft Dynamics Axapta складывается из выполненных заявок на изменение.
Формирование релиза включает этапы, представленные на рисунке 1. Все этапы строго регламентированы, за каждый этап назначено ответственное организационное подразделение.
Изменения в систему вносятся только по заявкам на изменение, согласованным с владельцами ресурсов.
К включению в релиз допускаются только модификации, прошедшие функциональное и нагрузочное тестирование программистом, тестировщиком и пользователем. По окончании тестирования пользователем подписывается соответствующий акт о том, что внесенные изменения соответствуют заявленным требованиям.
Порядок работ при выпуске релиза:
1. Выпуск релиза производится раз в неделю. Релиз устанавливается на промышленное приложение во время технологического перерыва, по четвергам, с 21:00 до 22:00 без отключения системы.
2. Выполненные и протестированные модификации накапливаются в системе на приложении для разработки.
3. Во вторник производится развертывание приложения для сборки релиза, которое является копией промышленного приложения. При этом в базе данных производится запись о новом релизе, содержащая дату и время выпуска релиза. А так же тип релиза, степень его влияния на работоспособность системы и перечень модификаций, запланированных для включения в релиз.
4. С 12:00 вторника по 17:00 среды производится сборка релиза, которая заключается в переносе модификаций на приложение для релиза путем построчного сравнения кода всех объектов, включенных в модификацию.
5. По окончании сборки релиза менеджер, ответственный за релиз объявляет сборку релиза оконченной. С этого момента релиз административно не доступен для переноса модификаций. В ночь со среды на четверг запускается синхронизация таблиц приложения и глобальная
компиляция всего релиза. Глобальная компиляция приложения длится 8-10 часов и заканчивается к 8 утра четверга. Данные операции являются необходимыми именно для системы Microsoft Dynamics AX и при использовании данной технологии другими системами могут быть исключены или заменены на другие работы.
6. В четверг утром ответственный менеджер релиза проверяет журнал компиляции системы на наличие ошибок. При отсутствии ошибок релиз передается в тестирование бизнес-аналитикам. При наличии ошибок производится их устранение и компиляция отдельно каждого объекта системы, в котором возникла ошибка.
7. В течение рабочего дня четверга отдел бизнес-анализа производит интеграционное и нагрузочное тестирование релиза. При наличии ошибок информация передается в отдел разработки, где программисты в сжатые сроки производят их исправление.
8. По окончании интеграционного тестирования производится нагрузочное тестирование, но только в том случае, если в системе были модификации, которые могли привести к снижению быстродействия системы.
9. Одновременно с интеграционным тестированием в обязательном порядке производится тестирование обновления данных, а так же проверка ключей доступа и настроек безопасности.
10. По окончании тестирования руководитель отдела бизнес-анализа сообщает менеджеру, ответственному за выпуск релиза об окончании тестирования. После чего они совместно принимают решение о переносе релиза на промышленное приложение.
11. Если в процессе интеграционного или нагрузочного тестирования релиза обнаружены ошибки, которые невозможно исправить, не срывая сроков выпуска релиза, менеджером по выпуску релиза и руководителем отдела бизнес-анализа принимается решение об отмене всего релиза или только модификации, из-за которой возникает ошибка.
12. Перед переносом релиза на промышленное приложение в обязательном порядке производится резервное копирование как баз данных системы, так и файлов приложения.
13. Менеджер релиза собирает перенесенные на релиз модификации в один проект, выгружает проект в текстовый файл и загружает данный файл на промышленное приложение без построчного сравнения кода. Отказ от сравнения кода обусловлен тем, что код уже был откомпилирован и проверен на релизе - абсолютной копии промышленного приложения.
14. После переноса производится синхронизация только тех таблиц, которые входят в проект релиза. Глобальная синхронизация и компиляция приложения не производится. Это позволяет избежать больших временных затрат на установку релиза и уменьшить время бездействия системы.
15. По окончании переноса производится настройка нововведенных параметров системы, обновление данных, настройка прав пользователей к новым объектам и сброс кэшированных данных пользователей.
16. По окончании настройки менеджер релиза сообщает в отдел сопровождения об окончании установки релиза в отдел сопровождения. Отдел сопровождения вкладывает на информационный портал обновленные инструкции по работе с системой и информирует пользователей о внесенных изменениях.
17. Менеджер релиза устанавливает в базе данных релиза статус «Завершен».
18. Отмена релиза при выявленных ошибках на промышленном приложении может быть произведена как полностью, так и частично. Регламентированное время на устранение ошибки 2 часа с момента фиксирования первого инцидента.
Рис. 1. Этапы формирования релиза Таблица 1. График обновления АСУП
№ п/п Этап Временные затраты Период
1 Сборка релиза На протяжении 12 часов система доступна для переноса модификаций Вторник с 12:00 - Среда до 17:00
2 Глобальная компиляция приложения для релиза 8-12 часов Среда с 17:00 - Четверг 8:00
3 Тестирование релиза 8 часов Четверг 8:00 - Четверг 17:00
4 Перенос на рабочее приложение 1-2 часа Четверг 21:00 - Четверг 23:00
5 Настройка системы, Информационное письмо пользователям От 0,5 часа до 4-х часов Пятница 8:00 - Пятница 12:00
Литература
1. Википедия. [Электронный ресурс]: Релиз (программное обеспечение). Режим доступа: https://ru.wikipedia.org/wiki/Релиз_(программное_обеспечение)/ (дата обращения: 26.04.2016).
Feedback as a tool to improve the efficiency of the work of the University in
the framework of the official Internet representation Shestopalova A.1, Akinchev A.2, Kamenev A.3, Meksheneva A.4, Artemov A.5,
Novikov S.6
Обратная связь как инструмент повышения эффективности работы университета в рамках официального Интернет-представительства Шестопалова А. Ю.1, Акинчев А. И.2, Каменев А. В.3, Мекшенева А. А.4, Артемов А. В.5, Новиков С. В.6
'Шестопалова Алина Юрьевна / Shestopalova Alina — студент магистратуры; 2Акинчев Андрей Игоревич / Akinchev Andrej — студент; 3Каменев Александр Владимирови ч /Kamenev Aleksandr — студент магистратуры; 4Мекшенева Алена Алексеевна /Meksheneva Alena — студент магистратуры; 5Артемов Андрей Владимирович / Artemov Andrej — кандидат технических наук, доцент,
кафедра программной инженерии; 6Новиков Сергей Владимирович /Novikov Sergey — кандидат технических наук, доцент, кафедра информационных систем, Орловский государственный университет им. И. С. Тургенева, г. Орёл
Аннотация: в статье обоснована необходимость использования обратной связи в рамках официального Интернет-представительства на примере подсистемы обратной связи в Интернет-представительстве ФГБОУВО «ОГУ имени И. С. Тургенева».
Abstract: the article substantiates the need for feedback as part of the official Internet representation by the example of the feedback subsystem of the Internet representation of Oryol State University named after I. S. Turgenev.
Ключевые слова: обратная связь, вуз, Интернет-представительство. Keywords: feedback, university, Internet representation.
Прежде всего, необходимо дать определение понятию обратная связь. Обратная связь - в широком смысле означает отзыв, отклик, ответную реакцию на какое-либо действие или событие. Также обратная связь - это инструмент управления персоналом и повышения эффективности управленческих процессов, который должен учитываться в каждом аспекте любой организации [1]. Для официального Интернет-представительства - инструмент, с помощью которого осуществляется информационный обмен между руководством университета и сотрудниками, студентами, абитуриентами, выпускниками, он позволяет получать актуальную информацию о последствиях принятых управленческих решений [2].
Современный уровень образования требует постоянного внедрения в учебный процесс информационных технологий и систем, способствующих упрощению взаимодействия учащихся с образовательной организацией [3].
Для руководства университета обратная связь - это инструмент, который позволяет:
• повысить продуктивность и результативность работы;
• прояснить цели и уточнить задачи, стоящие перед сотрудниками и преподавателями;
• скорректировать поведение студентов, сотрудников и преподавателей с целью более рационального использования возможностей;
• поддерживать положительную атмосферу в университете;
• выявить, что какой-либо процесс или инструмент не обеспечивает нужный результат;
• выявить сферы, требующие модернизации, изменения или развития, чтобы обеспечить устойчивый рост и прогресс университета.
Рассматривая обратную связь в рамках официального Интернет-представительства университета, следует упомянуть о лице, которое является непосредственным информатором,
