Разработка модуля интеграции SAP
Интегрируемые системы и подходы к их интеграции. Методы передачи данных между информационными системами: обмен плоскими файлами, общая база данных, интеграционная шина. Особенности использования SAP.NET Connector. Проектирование функционала модуля.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 26.08.2017 |
| Размер файла | 2,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Переменная reqJson имеет класс ViewStructureRequest, описывающий структуру запроса:
class ViewStructureRequest
{
public long ViewId { get; set; }
public ViewDataPageRequest DataRequest { get; set; }
}
public class ViewDataPageRequest
{
public long ViewId { get; set; }
public int StartIndex { get; set; }
public int EndIndex { get; set; }
public IEnumerable<SortColumn> Sortings { get; set; }
public TableFilter Filter { get; set; }
public IEnumerable<ViewFilterModel> Params { get; set; }
}
Теперь, получив данные по КУН, необходимо подготовить их для передачи в хранилище системы SAP R/3:
public class SapDataStructure
{
public DataTable SapDataTable = null;
public SapDataStructure()
{
DataTable tDataTable = null;
DataColumn tDataColum = null;
tDataTable = new DataTable("CUN_DATA_TABLE");
tDataColum = new DataColumn();
tDataColum.ColumnName = "NUM_CARD";
tDataColum.DataType = Type.GetType("System.String");
tDataColum.Caption = "№ карточки";
tDataColum.ReadOnly = true;
tDataTable.Columns.Add(tDataColum);
tDataColum = new DataColumn();
tDataColum.ColumnName = "STAD_FAIL";
tDataColum.DataType = Type.GetType("System.String");
tDataColum.Caption = "Стадия отказа";
tDataColum.ReadOnly = true;
tDataTable.Columns.Add(tDataColum);
…
SapDataTable = tDataTable;
}
}
private static void PrepareDataCunTransfer()
{
DataRow DataRow = null;
SapDataTransferStructure = new SapDataClass.SapDataStructure();
dynamic CunData = gclCunClass.Data.InitialData.Data;
foreach (var DataItem in CunData)
{
DataRow = SapDataTransferStructure.SapDataTable.NewRow();
DataRow["NUM_CARD"] = (string)DataItem["№ карточки"];
DataRow["STAD_FAIL"] = (string)DataItem["Стадия отказа"];
…
SapDataTransferStructure.SapDataTable.Rows.Add(DataRow);
}
}
Теперь необходим метод, который бы помещал полученные данные в контейнер и отправлял их, вызывая BAPI в SAP R/3 по указанным параметрам:
public static void CallRfcCUN(string NameFunction, RfcDestination SapRfcDest, RfcRepository SapRfcRep, SapDataClass.SapDataStructure SapDataTransferStructure)
{
IRfcFunction lFunction = SapRfcRep.CreateFunction(NameFunction);
IRfcTable SapTable = lFunction.GetTable("Itab");
foreach (DataRow DataRow in SapDataTransferStructure.SapDataTable.Rows)
{
SapTable.Append();
if (DataRow["NUM_CARD"] != DBNull.Value)
{
SapTable.SetValue("ZZCUN", DataRow["NUM_CARD"]);
}
if (DataRow["STAD_FAIL"] != DBNull.Value)
{
SapTable.SetValue("STAGE_CANCEL", DataRow["STAD_FAIL"]);
}
…
}
lFunction.Invoke(SapRfcDest);
}
Таким образом, было спроектировано интеграционное решение: структура данных, функционал и архитектура. Также разработан его основной функционал с помощью объектно-ориентированного языка программирования C#.
Заключение
Любая достаточно крупная компания не может ограничиться использованием единственного программного продукта для своей деятельности, поэтому рано или поздно встает проблема интеграции корпоративных систем. Сегодня достаточно много готовых интеграционных решений, предоставляемых различными компаниями, но зачастую их цена оказывается велика. Таким образом, компании склоняются к собственной разработке интеграционных решений.
В рамках данной работы была поставлена цель автоматизировать процесс отслеживания неисправных изделий в системе SAP R/3 с помощью ее интеграции с системой «База производства ВОГ». Для достижения цели были выполнены нижеперечисленные задачи.
1. Изучена проблема интеграции КИС и методы ее решения. Методы сравнены между собой, и было принято решение использовать подход централизованного брокера сообщений.
2. Проанализирована деятельность предприятия, а также ее информационная среда, включающая в себя интегрируемые системы SAP R/3 и «База производства ВОГ».
3. Проанализированы процессы планирования производством и исследования неисправных изделий. Определена потребность результата исследования неисправных изделий - КУН для процесса планирования потребности в материалах.
4. Проанализирована структура данных КУН в МУННС. Спроектирована структура данных, которые будут передаваться в SAP R/3. Спроектирован основной функционал модуля и архитектура всего интеграционного решения. Разработан основной функционал интеграционного модуля.
Процесс внедрение данного интеграционного решения уже начат, но не может быть закончен в полной мере до тех пор, пока в системе «База производства ВОГ» не будет реализована электронная подпись карточек учета неисправностей. На данный момент эти документы не имеют экономической силы и не могут быть использованы для учета в системе SAP R/3.
Основные обозначения и сокращения
1. БД - база данных.
2. ВОГ - волоконно-оптический гироскоп.
3. ИС - информационная система.
4. КУН - карточка учета неисправностей.
5. ПНППК - ПАО «Пермская научно-производственная приборостроительная компания».
6. ПО - программное обеспечение.
7. СУБД - система управления базой данных.
Библиографический список
1. ПР-001. Руководство по качеству. Нормативная документация ПАО «Пермская научно-производственная приборостроительная компания». - 2015.
2. СТП-065. Технология исследования изделий, отказавших у потребителя или в процессе производства. Нормативная документация ПАО «Пермская научно-производственная приборостроительная компания». - 2015.
3. Абрамов В.В. Механизмы интеграции систем. // ГОУВПО «Мордовский государственный университет им. Н. П. Огарева». Саранск: МГУ им. Н.П.Огарева, 2010.
4. Вичугова А.А., Вичугов В.Н., Дмитриева Е.А., Цапко Г.П. Методы и средства интеграции информационных систем в рамках единого информационного пространства проектирования//Вестник науки Сибири. - 2012. - №5 (6) - С.113-117.
5. Дикерсбах Й.Т., Келлер Г. Планирование и управление производством с помощью решений SAP ERP. СПб: Эксперт РП, 2011.
6. Захаров А. Управление производственными потоками с использованием ERP-системы SAP при изготовлении машиностроительной продукции // Журнал «Умное производство». - 2010. - №12.
7. Использование типа dynamic (Руководство по программированию на C#) // Сеть разработчиков MSDN [Электронный ресурс]. URL: https://msdn.microsoft.com/ru-ru/library/dd264736.aspx (дата обращения: 13.04.2017).
8. Когаловский М.Р. Методы интеграции данных в информационных системах // Институт проблем рынка РАН. М.: РАН, 2010.
9. Кожухова О.А., Кукаревцев В.В. Внедрение и использование ERP-систем на предприятии // Актуальные проблемы авиации и космонавтики. - 2011. - №7 - С.448-449.
10. Кусов А.А. Проблемы интеграции корпоративных информационных систем // УЭкС. - 2011. - №28. - С.103-109.
11. Степанов Д.Ю. Способы интеграции корпоративных информационных систем. // Естественные и технические науки. - 2014. - №1 (69). - С. 207-213.
12. Франгулова Е.В. Классификация подходов к интеграции и интероперабельности информационных систем // Вестник АГТУ. Серия: Управление, вычислительная техника и информатика. - 2010. - №2. - С.176-180.
13. Черняк Л. Интеграция данных: синтаксис и семантика // Открытые системы. СУБД. - 2009. - №10.
14. Щекочихин О.В., Шведенко П.В., Анализ уровней интеграции компонентов гетерогенных информационных систем // Международный журнал «Программные продукты и системы». - 2016. - №4. - С.73-77.
15. De R.B. SAP PI for Beginners [Электронный ресурс]// Blog SAP. URL: https://blogs.sap.com/2013/05/21/sap-pi-for-beginners/ (дата обращения: 13.04.2017).
16. Gupta H. Transfer Data from .NET to SAP using SAP Dot NET connector 3.0. [Электронный ресурс] // Blogs SAP. URL: https://blogs.sap.com/2013/09/13/transfer-data-from-net-to-sap-using-sap-dot-net-connector-30/ (дата обращения: 13.04.2017).
17. Reddy A.K. SAP R/3 Architecture Explained. [Электронный ресурс]// SAPNuts.com. URL: https://www.sapnuts.com/courses/core-abap/sap-intro/sap-r-3-architecture.html (дата обращения: 13.04.2017).
18. SAP .NET Connector 3.0 Overview. [Электронный ресурс]// Logosworld. URL: http://logosworld.com/docs/SAP/Connector (дата обращения: 13.04.2017).
19. The JSON Data Interchange Format. [Электронный ресурс]// ECMA-404. URL: http://www.json.org/json-ru.html (дата обращения: 13.04.2017).
20. Top 10 ERP Systems Ranking Report for 2017. [Электронный ресурс]// ERP News. URL: http://www.erpnews.com/top-10-erp-report-2017/ (дата обращения: 13.04.2017).Приложение А
Архитектура единой ИС «ПНППК»
Рисунок А.1. Архитектура единой ИС"ПНППК"
Приложение Б
Декомпозиция процесса «Исследование изделия, отказавшего у потребителя или в процессе производства»
Рисунок Б.1. Декомпозиция процесса исследования отказавших изделий
Приложение В
Структура таблицы «КУН.Карточка» в МУННС
Таблица В.1. Поля таблицы "КУН.Карточка"
|
Группа полей |
Поле |
Тип поля |
|
|
№ Карточки |
Строка |
||
|
Тип КУН |
Справочник |
||
|
№ системы |
Справочник |
||
|
№ прибора |
Справочник |
||
|
№ блока |
Справочник |
||
|
№ базового элемента |
Справочник |
||
|
Дата изготовления |
Дата |
||
|
Дата отказа |
Дата |
||
|
Изделие поступило |
из |
Справочник |
|
|
Изделие поступило |
от |
Справочник |
|
|
Изделие поступило |
по документу |
Справочник |
|
|
Изделие поступило |
дата документа |
Дата |
|
|
Изделие поступило |
приемный акт № |
Строка |
|
|
Изделие поступило |
дата приемного акта |
Дата |
|
|
Дата начала эксплуатации |
Дата |
||
|
Гарантийный срок эксплуатации |
Вещественное число |
||
|
Тип стадии отказа |
Справочник |
||
|
Стадия отказа |
Справочник |
||
|
Наработка, час. |
Целое число |
||
|
Восстановлен в эксплуатирующей организации |
дата восстановления |
Дата |
|
|
Восстановлен в эксплуатирующей организации |
№ изделия |
Справочник |
|
|
Восстановлен в эксплуатирующей организации |
Замена по документу |
Справочник |
|
|
Восстановлен в эксплуатирующей организации |
№ документа |
Строка |
|
|
Внешний воздействующий фактор |
Справочник |
||
|
Проявление дефекта |
Справочник |
||
|
Описание проявления дефекта |
Текст |
||
|
Дефект при первом включении |
Строка |
||
|
Ответственный за программу исследований |
Справочник пользователей |
||
|
Доп. разработчик программы исследований |
Справочник пользователей |
||
|
Ответственный за выполнение программы исследований |
Справочник пользователей |
||
|
Доп. исполнитель программы исследований |
Справочник пользователей |
||
|
Программа исследований |
Таблица |
||
|
Исследованием установлено |
Текст |
||
|
Рекомендации |
Текст |
||
|
Причина отказа (заключение) |
Текст |
||
|
Перечень вышедших из строя деталей |
Текст |
||
|
Классификация дефекта |
Справочник |
||
|
Виновник |
Завод |
Справочник |
|
|
Виновник |
Человек |
Справочник |
|
|
Виновник |
Комментарий |
Текст |
|
|
Ответственный за разработку мероприятий |
Справочник |
||
|
Доп. разработчик мероприятий |
Справочник |
||
|
Мероприятия по устранению дефектов |
Таблица |
||
|
Ответственный за выполнение мероприятий |
Справочник пользователей |
||
|
Доп. исполнитель мероприятий |
Справочник пользователей |
Приложение Г
Перечень API в системе «База производства ВОГ»
1. Login
Авторизация в системе.
Описание метода: Метод позволяет узнать свой AuthToken, для дальнейших вызовом методов API. Данный токен не изменяется до тех пор, пока не измениться пароль пользователя.
Тип метода: POST.
Вызов метода: http://[сервер]:[порт]/api/login/login
Тело запроса:
{ "Login": "1",
"Password": "пароль" }
Описание параметров запроса:
· Login - табельный номер или логин пользователя
· Password - пароль пользователя
Результат запроса:
{
"IsValid": true,
"Account": {
"Id": 1,
"Login": "user",
"Number": 1,
"AccessToken": "abcdef…",
…
}
}
2. TableDataPage
Описание метода: Получение записей таблицы.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/tabledatapage
Тело запроса:
{
"TableId": 83,
"StartIndex": 0,
"EndIndex": 1000
}
Описание параметров запроса:
· TableId - идентификатор таблицы, из которой нужно получить данные
· StartIndex - индекс первой строки
· EndIndex - индекс последней строки
Результат запроса:
{
"Data": [
{
"SysId": 114,
"SysStatusId": 626,
"SysStatusId_fk": "Нововведения",
"SysInsUserId": 1,
"SysInsUserId_fk": "admin",
"SysInsDate": "2015-03-03T16:22:08.9",
"SysUpdUserId": 1,
"SysUpdUserId_fk": "admin",
"SysUpdDate": "2016-08-31T10:45:28.67",
…
},
...
],
"DenyColumns": [
{
"RowId": 114,
"DenyColumns": [
26845
]
},
...
],
"TotalRows": 764,
"StartRowIndex": 0,
"RowColors": []
}
3. TableStructure
Описание метода: Получение метаданных и данных таблицы.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/TableStructure
Тело запроса:
{
"TableId": 83,
"DataRequest": {
"TableId": 83,
"StartIndex": 0,
"EndIndex": 1000
}
}
Описание параметров запроса:
· TableId - идентификатор таблицы, из которой нужно получить данные
· DataRequest - объект, который содержит список параметров для получения данных. Если передать null, то метод вернет только метаданные таблицы.
· StartIndex - индекс первой строки
· EndIndex - индекс последней строки
4. AddRow
Описание метода: Добавление записи в таблицу.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/addrow
Тело запроса:
{
"TableId": 83,
"Row": {
"1110": "Новая запись",
"-1": 626,
"26678": 2
}
}
Описание параметров запроса:
· TableId - идентификатор таблицы, в которую выполняется вставка строки
· Row - объект строки, хранящий пары id столбца и значение ячейки.
Результат запроса:
{
"ErrorMessage": null,
"SysId": 866,
"Columns": {
"1110": "Новая запись",
"26678": 2
}
}
5. AddCellFile
Добавляет файлы к ячейке записи.
Вызов метода http://{serverName}/api/TableData/AddCellFile
Метод необходимо вызывать перед вызовом addrow.
Тип метода POST, заголовок AuthToken - аксесс токен пользователя, получаемый им при логине в систему, Content-Type:multipart/form-data;. В теле запроса надо послать содержимое файла. В результате выполнения запроса будет получен ответ, содержащий id файла в системе (например: "с4a89cebe7624e4e94ed8e8d65g41e4b").
Далее данный файл можно указать в методе addrow для ячеек типа файл.
{"Row" : {"1110" : "тестовое предложение" , "2108" : null , "13189" : { "с4a89cebe7624e4e94ed8e8d65g41e4b" : "3.jpg" } ,"-1" : 649 } , "SysId" : null , "tableId" : 83 }.
Все остальные параметры метода addrow останутся неизменными. Метод addrow может принимать произвольное количество файлов.
6. EditRow
Описание метода: Редактирование записи в таблице.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/editrow
Тело запроса:
{
"SysId": "866",
"TableId": 83,
"Row": {
"1110": "Тест"
}
}
Описание параметров запроса:
· TableId - идентификатор таблицы, в которую выполняется вставка строки
· Row - объект строки, хранящий пары id столбца и значение ячейки.
· SysId - id строки, которую изменяем
Результат запроса:
{
"ErrorMessage": null,
"SysId": 866,
"Columns": null
}
7. FkValuesForColumn
Описание метода: Получает список значений из управляющей таблицы. Учитывает логику ограничений по статусам на внешние ключи, т.е. показывает те же данные что и стандартный веб интерфейс.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/tabledata/fkvaluesforcolumn
Тело запроса:
{
"ColumnId": 26678,
"QueryText": "и"
}
Описание параметров запроса:
· ColumnId - id столбца, для которого нужно запросить список значений.
· QueryText - текст по которому фильтруются допустимые значение. Если указать пустой текст, то получим все записи.
Результат запроса:
{
"ColumnId": 26678,
"Values": [
{
"Key": 2,
"Value": "ЗФиОП"
}
]
}
Описание параметров результата запроса:
· Key - значение внешнего ключа (управляющий столбец).
· Value - значение для отображения в списках (столбец для отображения).
8. ViewDataPage
Описание метода: Получение записей табличного отчета.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/view/viewdatapage
Тело запроса:
{
"ViewId": "12762",
"StartIndex": 0,
"EndIndex": 1000,
"Sortings": [
{
"ColumnName": "WhiteZoneBuild",
"SortDirection": -1,
"SortType": 0
}
],
"Filter": {
"GroupType": 0,
"GroupItems": [
{
"GroupType": 0,
"GroupItems": [
{
"GroupType": null,
"GroupItems": null,
"ColumnId": 101889,
"Value": 2,
"Type": 1
}
]
}
]
},
"Params": [
{
"ParamId": 364,
"Values": [],
"DateValue": "2016-10-01T00:00:00.000Z"
},…
]
}
Описание параметров запроса:
· ViewId - id отчета, из которой нужно получить данные.
· StartIndex - индекс первой строки
· EndIndex - индекс последней строки
· Sortings - параметры для сортировки данных
· Filter - параметры для фильтрации данных
· Params - параметры отчета
Результат запроса:
{
"Data": [
{
"numberBuild": "7883-ааа",
"SysInsDateBuild": "2016-10-26T14:31:01.613",
"GrayZoneBuild": 2.22014,
"WhiteZoneBuild": 123,
"WorkTimeBuild": 123,
"CountReassBuild": 2,
"SysInsDateCheck": "2016-10-27T17:55:14.777",
"GrayZoneCheck": 1.375,
"WhiteZoneCheck": -1.3689,
"WorkTimeCheck": 0.0061,
"CountReassCheck": 1
},
...
],
"DenyColumns": null,
"TotalRows": 6,
"StartRowIndex": 0,
"RowColors": []
}
Описание параметров результата запроса:
· Data - данные отчетов.
9. ViewStructure
Описание метода: Получение метаданных и данных отчета.
Тип метода: POST. В заголовке запроса указывать AuthToken - аксесс токен пользователя.
Вызов метода: http://[сервер]:[порт]/api/viewstructure
{
"ViewId": "1",
"DataRequest": {
"ViewId": "1",
"StartIndex": 0,
"EndIndex": 100,
"Sortings": null,
"Filter": null,
"Params": []
}
}
Описание параметров запроса:
· ViewId - id отчета.
Приложение Д
Техническое задание
1. Введение
1.1. Наименование системы
Наименование программы - «Модуль интеграции систем SAP R/3 и «База производства ВОГ».
1.2. Краткая характеристика области применения
Программа предназначена для интеграции систем в информационной среде Заказчика.
2. Основания для разработки
Разработка ведется на основании протокола № 66/68-238-п совещания по организации взаимодействия SAP R/3 и базы производства ВОГ от 24.10.2016 г.
Протокол согласован с заместителем генерального директора по науке (директором научно-технического центра) ПАО «Пермская научно-производственная приборостроительная компания» А.В. Субботиным и утвержден директором по ИТ М.И. Заком, именуемым в дальнейшем Заказчиком, того же предприятия.
3. Назначение разработки
3.1. Функциональное назначение
Программа должна интегрировать системы SAP R/3 и База производства ВОГ в части отслеживания неисправных изделий.
3.2. Эксплуатационное назначение
Программа должна эксплуатироваться системами SAP R/3 и База производства ВОГ в автоматическом режиме.
Конечными пользователями должны являться пользователи систем SAP R/3 и База производства ВОГ.
4. Требования к программе
4.1. Требования к функциональным характеристикам
4.1.1. Требования к составу выполняемых функций
Программа должна выполнять перечисленные ниже функции:
a. Функция вызова API система База производства ВОГ.
b. Функция вызова BAPI системы SAP R/3.
c. Функция преобразования данных.
4.1.2. Требования к организации входных данных
Входные данные должны быть организованы в виде строк, содержащих логины и пароли ответственного за интеграцию от систем SAP R/3 и База производства ВОГ.
4.1.3. Требования к организации выходных данных
Выходные данные должны быть организованны в виде строк в консоли, сообщающих об успешном выполнении этапа передачи данных.
4.1.4. Требования к временным характеристикам
Программа должна выполнять один цикл передачи данных не более чем за 5 минут.
4.2. Требования к надежности
4.2.1. Требования к обеспечению надежного (устойчивого) функционирования программы
Надежное (устойчивое) функционирование программы должно быть обеспечено выполнением совокупности организационно-технических мероприятий, перечень которых приведен ниже:
1. Организацией бесперебойного питания технических средств.
2. Регулярным выполнением требований ГОСТ 51188-98. Защита информации.
3. Испытания программных средств на наличие компьютерных вирусов.
4. Регулярной проверкой целостности информационной базы и восстановления ее в случае необходимости.
4.2.2. Время восстановления после отказа
Время восстановления после отказа, вызванного сбоем электропитания технических средств (иными внешними факторами), не фатальным сбоем операционной системы, не должно превышать времени, необходимого на перезагрузку операционной системы и запуск программы, при условии соблюдения условий эксплуатации технических и программных средств.
Время восстановления после отказа, вызванного неисправностью технических средств, фатальным сбоем (крахом) операционной системы, не должно превышать времени, требуемого на устранение неисправностей технических средств и переустановки программных средств.
4.2.3. Отказы из-за некорректных действий оператора
Отказы программы вследствие некорректных действий пользователя исключены.
4.3. Условия эксплуатации
4.3.1. Климатические условия эксплуатации
Климатические условия эксплуатации, при которых должны обеспечиваться заданные характеристики, должны удовлетворять требованиям, предъявляемым к техническим средствам в части условий их эксплуатации.
4.3.2. Требования к видам обслуживания
См. Требования к обеспечению надежного (устойчивого) функционирования программы.
4.3.3. Требования к численности и квалификации персонала
Минимальное количество персонала, требуемого для работы программы - 2 штатные единицы - ответственный за интеграцию и системный администратор.
Системный администратор должен иметь высшее профильное образование.
Ответственный за интеграцию должен быть знаком с процессом интеграции, знать возможные причины отказа модуля интеграции и способы устранения его неисправностей.
4.4. Требования к составу и параметрам технических средств
В состав технических средств должен входить IBM-совместимая серверная машина с характеристиками не хуже стандартных персональных компьютеров Заказчика, на которых ведется разработка.
4.5. Требования к информационной и программной совместимости
4.5.1. Требования к информационным структурам и методам решения
Требования к информационным структурам на входе и выходе, а также к методам решения не предъявляются.
4.5.2. Требования к исходным кодам и языкам программирования
Исходные коды программы должны быть реализованы на языке C#. В качестве интегрированной среды разработки программы должна быть использована среда Microsoft Visual Studio 2015.
4.5.3. Требования к программным средствам, используемым программой
Системные программные средства, используемые программой, должны быть представлены лицензионной локализованной версией операционной системы Windows 7.
4.5.4. Требования к защите информации и программ
Защита модуля должна обеспечиваться комплексом программно-технических средств и поддерживающих их организационных мер.
Защита модуля должна обеспечиваться на всех технологических этапах обработки информации и во всех режимах функционирования, в том числе при проведении ремонтных и регламентных работ.
Программно-технические средства защиты не должны существенно ухудшать основные функциональные характеристики модуля.
4.6. Требования к маркировке и упаковке
Требования к маркировке и упаковке не предъявляются.
4.7. Требования к транспортированию и хранению
Требования к транспортированию и хранению не предъявляются.
4.8. Специальные требования
Специальные требования не предъявляются.
5. Требования к программной документации
1.1. Предварительный состав программной документации
Состав программной документации должен включать в себя:
1. Техническое задание.
2. Программу и методики испытаний.
3. Руководство системного администратора.
4. Акт о выполнении работ.
6. Технико-экономические показатели
Ориентировочная экономическая эффективность не рассчитывается.
Предполагаемое число использований программы в год - 365 сеансов.
7. Стадии и этапы разработки
7.1. Стадии разработки
Разработка должна быть проведена в шесть стадий:
1. Разработка технического задания.
2. Проектирование интеграционного решения.
3. Разработка интеграционного модуля.
4. Внедрение интеграционного модуля.
7.2. Этапы разработки
На стадии разработки технического задания должен быть выполнен этап разработки, согласования и утверждения настоящего технического задания.
На стадии проектирования интеграционного решения должны быть проанализированы структуры поступающих и отправляемых данных, а также смоделирован функционал интеграционного модуля.
На стадии разработки интеграционного модуля должен быть разработан интеграционный модуль, выполняющий функции, описанные на этапе проектирования.
На стадии внедрения интеграционный модуль должен быть размещен на сервере Заказчика.
8. Порядок контроля и приемки
8.1. Виды испытаний
Приемо-сдаточные испытания буду проводится на объекте Заказчика после выполнения всех параллельных работ не позднее 01.08.2017.
Размещено на Allbest.ru
Подобные документы
Постановка задачи для модуля 1С. Бухгалтерия 3.0. Анализ существующих разработок в области интегрирования данных. Информационное обеспечение модуля "Связь 1С Предприятия 8.2. с "Казначейством". Программное и технологическое обеспечение данного модуля.
курсовая работа [1,5 M], добавлен 10.06.2013Технико-экономические характеристики предметной области по учету готовой продукции на ОАО "ММК". Постановка задачи для модуля 1С. Бухгалтерия 3.0. Информационное обеспечение модуля "Связь 1С Предприятия 8.2. с "Казначейством". Оценка трудоемкости работы.
дипломная работа [1,1 M], добавлен 06.06.2013Проектирование программного модуля: сбор исходных материалов; описание входных и выходных данных; выбор программного обеспечения. Описание типов данных и реализация интерфейса программы. Тестирование программного модуля и разработка справочной системы.
курсовая работа [81,7 K], добавлен 18.08.2014Анализ модуля интеграции на предприятии "Вазаро". Оценка электронной коммерции и интернет-магазинов в частности. Реализация необходимых изменений в модуле интеграции "1С: Предприятие" и интернет-магазина. Расчет стоимости и прибыльности модернизации.
дипломная работа [2,8 M], добавлен 03.07.2014Краткая характеристика PI System и контура управления tic-104. Анализ и планирование требований к модулю tic-104. Проектирование модуля tic-104. Внедрение модуля в приложение PI ProcessBook. Доступ к данным временных рядов PI. Модульная база данных.
курсовая работа [38,1 K], добавлен 09.05.2011Разработка модуля для вычисления значения функции, который впоследствии подключается к программе ввода исходных данных с контролем допусимого значения в таблицу. Проектирование модуля для работы со строками и для обработки массивов текстовой информации.
курсовая работа [17,8 K], добавлен 24.09.2010Анализ предметной области. Средства и технологии разработки программного обеспечения. Требования к аппаратным и операционным ресурсам. Создание навигационного меню. Структура данных таблиц. Разработка интерфейса модуля. Сортировка и фильтрация данных.
дипломная работа [3,7 M], добавлен 12.05.2018Разработка функциональной и структурной схемы программного средства. Реализация основного модуля программы. Реализация модуля печати и модуля обновлений. Изучение взаимодействия информационных технологий, методов их интеграции и обмена данными.
дипломная работа [3,2 M], добавлен 27.10.2017Освоение методов манипуляции параметрами SVG изображений при помощи JavaScript и возможности по анимации в современных браузерах. Интерфейс и структура модуля визуализации данных. Определение аномальных данных и их определение, реализованные типы.
курсовая работа [1,7 M], добавлен 20.05.2014Выбор методологии проектирования и разработка информационной системы "Расчёт зарплаты" для предприятия ОАО РТП "Авторемонтник". Архитектурное проектирование базы данных информационной системы и разработка её интерфейса. Тестирование программного модуля.
дипломная работа [2,3 M], добавлен 25.05.2014
