К дипломному проекту на тему

Вид материала

Диплом

Содержание 1.4 Моделирование бизнес процессов 1.5 Анализ аналогичных проектных решений.

Подобный материал:

• Реферат впояснительной записке к дипломному проекту на тему «11-этажный жилой дом, 1498.63kb.
• К дипломному проекту, 805.09kb.
• Пояснительная записка к дипломному проекту на тему, 85.86kb.
• К дипломному проекту, 501.1kb.
• Пояснительная записка к дипломному проекту Исполнитель, 97.94kb.
• Формат опису модуля, 38.32kb.
• Рекомендации к дипломному проекту (экономическая часть) Оглавление, 159.19kb.
• Роль бізнес-проекту, 105.24kb.
• Задание по дипломному проекту (заполняется совместно с руководителем). Отзыв руководителя, 434.54kb.
• Задачи дипломного проектирования Требования предъявляемые к дипломному проекту, 1174.55kb.

1.4 Моделирование бизнес процессов

Бизнес-моделирование (деловое моделирование) — деятельность по формированию моделей организаций, включающая описание деловых объектов (подразделений, должностей, ресурсов, ролей, процессов, операций, информационных систем, носителей информации и т.д.) и указание связей между ними. Требования к формируемым моделям и их соответствующее содержание определяются целями моделирования.

Бизнес – моделированием также называют дисциплину и отдельный подпроцесс в процессе разработки программного обеспечения, в котором описывается деятельность компании и определяются требования к системе — те подпроцессы и операции, которые подлежат автоматизации в разрабатываемой информационной системе.

В данной дипломной работе для моделирования бизнес процессов будет использоваться BPwin, ведущий инструмент визуального моделирования бизнес-процессов. Дает возможность наглядно представить любую деятельность или структуру в виде модели, что позволит оптимизировать работу организации, проверить ее на соответствие стандартам ISO9000, спроектировать организационную структуру, снизить издержки, исключить ненужные операции, повысить гибкость и эффективность. Являясь стандартом де-факто, BPwin поддерживает сразу три нотации моделирования: IDEF0, IDEF3 и DFD.

1.5 Анализ аналогичных проектных решений.

Информационно-управляющая система "Эрлан-2"


Информационно-управляющая система "Эрлан-2", предназначена для информационного сопровождения процессов технической эксплуатации авиационной техники. ИУС "Эрлан-2" представляет собой многофункциональный программный комплекс, разработанный с использованием современных информационных технологий на базе информационной системы предыдущего поколения ИУС "Эрлан-1" эксплуатирующаяся в настоящее время в 50-ти инженерно-авиационных службах.


Система предназначена для решения следующих основных задач:

1. планирование годовых налетов каждого ВС;
   
2. планирование отхода ВС на ремонт и формирование заявки на проведение ремонтов;
   
3. формирование годового плана проведения форм технического обслуживания (ТО);
   
4. планирование месячных налетов каждого ВС и корректировка годового плана ТО с определением конкретных дат отхода ВС на все формы ТО;
   
5. формирование оперативного плана (7 дней) использования авиационной техники с корректировкой дат ТО ВС;
   
6. обработки и анализа полетной информации;
   
7. учет наработки основных изделий (ОИ) (планер, двигатель и т.п.) и агрегатов,
   
8. установленных на борту.
   
9. контроль отработки ресурсов и других критических остатков;
   

Количество рабочих мест в системе не лимитируется в пределах возможности сетевой ОС. Количество рабочих мест в системе зависит от количества аэродромов базирования, их удаленности от центра технического обслуживания и размера парка самолетов.

Полная стоимость программного обеспечения включает стоимость серверной части ИУС (лицензия на серверную часть) и стоимость рабочих мест (клиентская лицензия). Стоимость серверной части ИУС рассчитывается в зависимости от набора подсистем с учетом размера и типажа парка ВС. Показатель размера парка ВС авиакомпании показан в таблице 1.


Таблица 1 - "Показатель размера парка авиакомпании"

Ni	Класс ВС	Максимальный взлетный вес в тоннах
		ВС российского производства	ВС иностранного производства и VIP	Вертолеты
N0	Широкофюзеляжный	более 150	более 50 тонн
N1	1-й класс	75-150	менее 50 тонн
N2	2-й класс	30-75
N3	3-й класс	10-30		1-го класса
N4	4-й класс	менее 10		др. классов
Nп	Приведенное число ВС: Nп = N0 x 2 + N1 x 1 + N2 / 2 + N3 / 3 + N4 / 6
K	Поправочный коэффициент: K = 0,5 + Nп / 10

Варианты оплаты ИУС "Эрлан-2"

1 Долгосрочная аренда. Периодические платежи (20% от полной стоимости в год) ежемесячно.

2 Финансовый лизинг.

Размеры ежегодных платежей в % от полной стоимости представлены в таблице 2.


Таблица 2 - Размеры ежегодных платежей (в % от первоначальной полной стоимости)

Год	1	2	3	4	5	Итого
%	32	29,6	27,2	24,8	22,4	136

Установка и внедрение ИУС "Эрлан-2"


Стоимость установки ИУС составляет 10 % от стоимости серверной части.

Стоимость внедрения ИУС составляет 20 % от полной стоимости.

Техническая поддержка ИУС "Эрлан-2".

Абонементное обслуживание. Периодические платежи (10 % в год от полной стоимости в год), ежемесячно.

Разовое обновление версий ПО. Клиентам, не заключившим договор на техническую поддержку, обеспечивается разовое обновление версий установленного ПО.


Стоимость обновления в % к полной стоимости ПО:


До 1 года эксплуатации (последней оплаченной версии) - бесплатно

До 2 лет эксплуатации - 20%

До 3 лет эксплуатации - 40%

До 4 лет эксплуатации - 60%

До 5 лет эксплуатации - 80%

После 5 лет эксплуатации - 100%


Проектируемая АС учета парка ВС, по сравнению с выше указанной системой ИУС "Эрлан-2", имеет более выгодный экономический аспект, поскольку требует меньше финансовых затрат. Кроме того, необходимо отметить, что в авиакомпании “ЮТэир” существуют подразделения, имеющее опыт по созданию и внедрению подобных систем. Так же следует отметить, что ИС сторонних разработчиков не учитывают особенности управления и распределение обязанностей между структурами внутри авиакомпании.


2. Постановка задачи


2.1 Цель автоматизации:


Проектируемая автоматизированная система эксплуатации воздушных судов разрабатывается для оптимизации парка и централизованного хранения, обработки и передачи информации.

Нет 2.2+++


2.3 Задачи автоматизации:

1. Создание БД для централизованного хранения, обработки и передачи информацию.
   
2. Достижение максимума эффективности парка ВС в процессе пассажирских перевозок.
   
3. Провести анализ экономического аспекта данного проекта.
   
4. Сделать выводы по данной работе.
   

2.4 Описание автоматизируемых функций.


В современных условиях, для эффективного управления процессом технической эксплуатации ВС на всех уровнях, необходима эффективная информационная система, построенная на едином информационном пространстве, в которой должны быть заинтересованы в равной степени все ее участники. Проектируемая АС эксплуатация ВС должна выполнять следующие функции:

1. получение оперативной информации о текущем и планируемом состоянии ВС, двигателей и комплектующих изделий, включающей формулярные данные, ресурсное состояние и движение;
   
2. получение информации, обладающей критичностью (минимальные остатки и переработка ресурсов, задержки вылетов, простой ВС по разным причинам и все виды информации с просроченными контрольными сроками, отсутствие, или критические остатки компонентов ВС на складах);
   
3. получение оперативной информации о содержании текущих и готовящихся производственных заданий;
   
4. получение оперативной информации о процессе подготовки производства (готовность комплектующих изделий, оборудования, расходных материалов и т.д.);
   
5. получение оперативных данных о состоянии эталонных и адаптивных регламентов и дополнениях к ним;
   
6. оперативное получение нормативно-справочной информации и ее изменений.
   
7. учет поступления и выдачи агрегатов и комплектующих изделий;
   
8. учет поступления и выдачи расходных материалов;
   
9. учет поступления и выдачи инструмента и оборудования;
   
10. отслеживание за контрольными сроками годности агрегатов, инструмента, оборудования и расходных материалов, находящихся в расходной кладовой (складах);
    
11. отслеживание неснижаемых запасов и обменного фонда агрегатов и комплектующих изделий;
    
12. отслеживание за движением изделий АТ, находящихся вне базы;
    
13. ведение нормативно-справочной информации;
    
14. формирование всех видов документов и отчетностей, предусмотренных для группы подготовки производства.
    

2.5 Анализ входной и выходной информации


Выходная информация может быть представлена в виде документов, кадров на экране монитора, информации в базе данных, выходного сигнала устройству управления.

В данной работе основной выходной информацией являются отчеты:

1. Справки о состоянии парка ВС и двигателей.
   
2. Справка о наработке ВС.
   
3. Налет ВС за период эксплуатации.
   
4. Двигатели.
   
5. Агрегаты.
   
   
   

Для каждого статистического отчёта должна существовать возможность указания отчетного периода. Выходные данные предоставлены в таблицах 3, 4.

В таблицах только справки о состоянии парка ВС и наработе ВС, опишите все 5 видов отчётов+++


Таблица 3 - Отчет Справки о состоянии парка ВС и двигателей

№	Название поля	Тип поля
1	Воздушное судно	Строковый
2	Дата выпуска	Время/Дата
3	Дата предыдущего КР	Время/Дата
4	Заводской номер	Числовой
5	Место предыдущего КР	Строковый
6	Срок удостоверение истекает	Время/Дата
7	Часы	Время/Дата
8	Посадки	Числовой
9	Двигатели
10	Тип двигателя	Строковый
11	Заводской номер	Числовой
12	Номер СУ	Строковый
13	Дата выпуска	Время/Дата
14	Дата предыдущего КР	Время/Дата
15	Место предыдущего КР	Строковый
16	Дата установки	Время/Дата
17	Часы	Время/Дата
18	Циклы	Числовой
19	Запуски	Числовой
20	Взлет	Числовой
21	Номинал	Числовой
22	Включение реверса	Числовой
23	(гг.мм.дд) Отчётный период? Тогда так и напишите+++.	Время/Дата

Таблица 4 - Справка о наработке ВС.

№	Название поля	Тип поля
1	Воздушное судно	Строковый
2	Дата выпуска	Время/Дата
4	Заводской номер	Числовой
5	Часы	Время/Дата
6	Посадки	Числовой
7	Ресурс назначенный	Числовой
8	Ресурс межремонтный	Числовой
9	Наработки с Н/Э	Числовой
10	Наработка ППР	Числовой
11	Дата последнего ремонта	Время/Дата
12	Место ремонта	Строковый
13	Наработка за месяц	Числовой
14	Двигатели
15	Тип двигателя	Строковый
16	Заводской номер	Числовой
17	Часы	Время/Дата
18	Циклы	Числовой
19	Ресурс назначенный	Числовой
20	Ресурс межремонтный	Числовой
21	Наработки с Н/Э	Числовой
22	Наработка ППР	Числовой
23	Дата последнего ремонта	Время/Дата
24	Место ремонта	Строковый

Входная информация – информация, образующаяся на входе любой системы или поступающая в систему извне. Информация может быть представлена в виде данных, документов, устных сообщений и пр. Цель любой системы – рациональная обработка входной информации для получения оптимальных управленческих решений в виде выходной информации. Входной документ – документ, составленный по определенной форме и содержащий данные, предназначенные для ввода информации в информационную систему.


Входными данными в АС будут являться данные о ВС. А именно паспорта воздушных судов, паспорта узлов и агрегатов, сопутствующая документация.

Источниками поступления информации являются паспорт ВС, документация на ВС, паспорта улов и агрегатов, документация улов и агрегатов. Входные данные предоставлены в таблица 5, 6, 7, 8.

Здесь нет информации о ремонтах, налёте, и др. Сравните с выходной информацией++++.


Таблица 5 – Технические характеристики ВС.

№	Название поля	Тип поля
1	Воздушное судно	Строковый
2	Заводской номер	Числовой
3	Дата выпуска	Время/Дата
4	Экипаж	Числовой
5	Пасажировместимость	Числовой
6	Грузоподъемность	Числовой
7	Длина	Числовой
8	Размах Крыла	Числовой
9	Высота	Числовой
10	Площадь крыла	Числовой
11	Коэффициент удлинения крыла	Числовой
12	База шасси	Числовой
13	Колея шасси	Числовой
14	Масса снаряженного	Числовой
15	Максимальная взлетная масса	Числовой
16	Максимальная стояночная масса	Числовой
17	Максимальная посадочная масса	Числовой
18	Максимальная масса без топлива	Числовой
19	Масса топлива во внутренних баках	Числовой
20	Объём топливных баков	Числовой
21	Силовая установка	Строковый
22	Мощность двигателей	Числовой
23	Тип двигателей	Строковый

Таблица 6 – лётные характеристики ВС.

№	Название поля	Тип поля
1	Максимальная скорость	Числовой
2	Практическая дальность	Числовой
3	Перегоночная дальность	Числовой
4	Практический потолок	Числовой
5	Нагрузка на крыло	Числовой
6	Тяговооруженность	Числовой
7	Длина разбега	Числовой
8	Длина пробега	Числовой

Таблица – 7 Двигатели.

№	Название поля	Тип поля
1	Производитель	Строковый
2	Тип двигателя	Строковый
3	Заводкой номер	Числовой
4	Дата выпуска
5	Тяга	Числовой
6	Масса	Числовой
7	Габариты (входной диаметр и длина по оси)	Строковый
8	Удельный расход топлива	Числовой
9	Расход воздуха	Числовой
10	Ресурс	Числовой
11	Степень повышения полного давления	Числовой
12	Температура газа перед турбиной	Числовой

Таблица 8 – Агрегаты.

№	Название поля	Тип поля
1	Производитель	Строковый
2	Заводской номер	Числовой
3	Шифр	Строковый
4	Дата выпуска	Время/Дата
5	Ресурс	Числовой

2.6 Требование к обеспечивающим подсистемам


Техническое обеспечение, представляет собой комплекс взаимосвязанных технических средств, обеспечивающих процессы сбора, регистрации, передачи, обработки, отображения и хранения информации.

Комплекс технических средств должен имеет возможность расширения (замены) состава технических средств, входящих в комплекс, для улучшения их эксплуатационно-технических характеристик по мере возрастания объемов обрабатываемой информации, количества абонентов, увеличения количества видов предоставляемых услуг абонентам, расширения функций системы.


Выбор целевой СУБД.


Цель данного этапа заключается в выборе системы, удовлетворяющей как текущим, так и будущим требованиям организации, при оптимальном уровне затрат, включающих расходы на приобретение СУБД, дополнительного аппаратного и программного обеспечения, а также расходы, связанные с переходом к новой системе и необходимостью переобучения персонала. Простейший подход к выбору нужной СУБД предусматривает оценку того, насколько функциональные возможности, предоставляемые СУБД, удовлетворяют существующим требованиям.

Система управления базами данных (СУБД) - это программный механизм, предназначенный для записи, поиска, сортировки, обработки (анализа) и печати информации, содержащейся в базе данных.

В настоящее время для построения информационных систем применяются различные системы управления базами данных (СУБД), различающиеся как своими возможностями, так и требованиями к вычислительным ресурсам.

Все их можно разделить по такому критерию как «Способ доступа». Таким образом можно выделить три основных типа СУБД:

• локальные
  
• файл-сервер
  
• клиент-сервер
  

Использование той или иной архитектуры накладывает сильный отпечаток на общую идеологию работы приложения и на программный код приложения.

При работе с «локальными» базами данных сами базы данных расположены на том же компьютере, что и приложения, осуществляющие доступ к ним. Работа с базой данных происходит в однопользовательском режиме. Приложение ответственно за поддержание целостности базы и за выполнение запросов к базе данных. Фактически, у «локальных» СУБД база данных понятие более логическое, чем физическое, поскольку под базой данных понимается набор отдельных таблиц, сосуществующих в едином каталоге на диске. Все это позволяет говорить о низком уровне безопасности – как с точки зрения хищения и нанесения вреда, так и с точки зрения внесения ошибочных изменений. В случае какого-либо критического сбоя велика вероятность повреждения, как отдельной таблицы, так и всей базы данных в целом.

Построение какой-либо информационной системы на основе такой БД не возможно, т.к. все данные в такой системе будут разрозненны. Такие СУБД более уместно использовать для построения таких приложений как справочники, каталоги и т.п. Для построения программы на основе «локальной» базы данных можно использовать Microsoft Access, SQLite, Firebird Embedded и др. Но есть и СУБД которые при расположении на файловом сервере предоставляют доступ группе пользователей. Такие СУБД называются «Файл-серверными».

Обработку запроса в такой СУБД можно разделить на три этапа:

• Запрос к базе данных
  
• Перекачка данных с блокировкой доступа других пользователей
  
• Обработка данных на компьютере пользователя
  

В архитектуре «файл-сервер» вся тяжесть выполнения запросов к базе данных и управления целостностью базы данных ложится на приложение пользователя. База данных на сервере является пассивным источником данных.

При такой схеме работы БД не оптимально расходуются ресурсы клиентского компьютера и сети. Например, если в результате запроса мы должны получить 2 записи из таблицы объемом 10000 записей, все 10000 записей будут скопированы с файл-сервера на клиентский компьютер, в результате возрастает сетевой трафик и увеличиваются требования к аппаратным мощностям пользовательского компьютера. Также возможно хранение локально копии базы.

После того как таблица скопирована или локальная копия базы обновлена, каждый пользователь имеет на своем компьютере локальную копию данных, время от времени обновляемых из реальной базы данных, расположенной на сетевом сервере. При этом изменения, которые каждый пользователь вносит в базу данных, могут быть до определенного момента неизвестны другим пользователям, что делает актуальной задачу систематического обновления данных на компьютере пользователя из реальной базы данных. Другой актуальной задачей является блокирование записей, которые изменяются одним из пользователей, это необходимо для того, чтобы в это время другой пользователь не внес изменений в те же данные.

Пожалуй, единственное преимущество такой архитектуры это низкая нагрузка на центральный процессор сервера. Но помимо одного плюса они имеют достаточное количество серьезных недостатков:

• Очень большая нагрузка на сеть, повышенные требования к пропускной способности. На практике это делает практически невозможной одновременную работу большого числа пользователей с большими объемами данных.
  
• Обработка данных осуществляется на компьютере пользователей. Это влечет повышенные требования к аппаратному обеспечению каждого пользователя. Чем больше пользователей, тем больше денег придется потратить на оснащение их компьютеров.
  
• Блокировка данных при редактировании одним пользователем делает невозможной работу с этими данными других пользователей.
  
• Безопасность. Для обеспечения возможности работы с такой системой Вам будет необходимо дать каждому пользователю полный доступ к целому файлу, в котором его может интересовать только одно поле.
  

Такую СУБД более целесообразно применять в приложениях с небольшим количеством таблиц, либо которые не нуждаются в большом количестве пользователей и большом количестве обрабатываемой информации. Примером такой СУБД могут служить Paradox, dBase, FoxPro, Visual FoxPro.

«Файл-серверная» архитектура начала свое моральное устаревание сразу же после появления «Клиент-серверных» СУБД.

Суть Архитектуры «клиент-сервер» чем-то схожа с «файл-сервер». Так же есть сервер и клиент. Но в случае «клиент-сервер» никакой перекачки данных не происходит. Поэтому обработка запроса сводится до двух этапов:

- SQL-запрос
- Передача ответа - результата обработки

Таким образом, снимается нагрузка с сети, и снижаются требования к рабочему месту клиента, т.к. клиентскому приложению посылается результат выполнения запроса и по сети "путешествуют" только те данные, которые необходимы клиенту, а выполнение запроса происходит там же, где хранятся данные (на сервере). Кроме того, sql-сервер, если это возможно, оптимизирует полученный запрос таким образом, чтобы он был выполнен в минимальное время с наименьшими накладными расходами. Всё это повышает быстродействие системы и снижает время ожидания результата запроса.

При выполнении запросов сервером существенно повышается степень безопасности данных, поскольку правила целостности данных определяются в базе данных на сервере и являются едиными для всех приложений, использующих эту БД. Таким образом, исключается возможность определения противоречивых правил поддержания целостности. Мощный аппарат транзакций, поддерживаемый sql-серверами, позволяет исключить одновременное изменение одних и тех же данных различными пользователями и предоставляет возможность откатов к первоначальным значениям при внесении в БД изменений, закончившихся аварийно.

Клиент-серверная СУБД осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются централизованно. Благодаря этому недостаток клиент-серверных СУБД состоит только в повышенных требованиях к серверу. Но данный недостаток компенсируется достаточно хорошим набором преимуществ.

• Массивы данных не перекачиваются по сети от сервера БД на компьютер пользователя. Требования к пропускной способности сети понижаются. Это делает возможным одновременную работу большого числа пользователей с большими объемами данных.
  
• Обработка данных осуществляется на сервере БД, а не в компьютере пользователей. Что позволяет использовать более простые, а значит, дешевые компьютеры на клиентских местах.
  
• Блокировки (захвата) данных одним пользователем не происходит.
  
• Обеспечивается доступ пользователя не к целому файлу, а только к тем данным из него, с которыми пользователь имеет право работать.
  

Таким образом, рассмотрев все плюсы и минусы различных СУБД, мы остановимся на клиент-серверных решениях, которые могут предложить нам следующие преимущества:

• Большие возможности управления
  
• Улучшенная производительность и масштабируемость
  
• Улучшенная безопасность и доступность
  

На сегодняшний день клиент-серверные решения идеальный вариант для разворачивания как средних так и серьезных информационных систем. Существует много различных решений: Oracle, IBM DB2, MS SQL Server, Sybase, MySQL. Наиболее распространенными среди них являются Oracle и MS SQL Server.

Основными преимуществами Oracle являются:

1. Высочайшая надежность
   
2. Возможность разбиения крупных баз данных на разделы (large-database partition), что дает возможность эффективно управлять гигантскими гигабайтными базами
   
3. Наличие универсальных средств защиты информации
   
4. Эффективные методы максимального повышения скорости обработки запросов
   
5. Индексация по битовому отображению
   
6. Свободные таблицы (в других СУБД все таблицы заполняются сразу при создании)
   
7. Распараллеливание операций в запросе
   
8. Наличие широкого спектра средств разработки, мониторинга и администрирования
   
9. Ориентация на интернет технологии
   

Не смотря на это MS SQL Server не сильно уступает имея такие важные характеристики как:

1) простота администрирования

2) возможность подключения к Web

3) быстродействие и функциональные возможности механизма сервера СУБД

4) наличие средств удаленного доступа

Целью дипломного проекта является создание автоматизированной системы «эксплуатация воздушных судов», основной задачей которой является централизованное хранения, обработка и передача информации о ВС, двигателей и агрегатов.

Для достижения поставленной цели оба продукта удовлетворяют в полном объеме. Но по экономическим соображениям выбор Microsoft SQL Server 2008 более выгодно по сравнению с Oracle 11g. Стоимость MS SQL Server в среднем колеблется около 100 тысяч, в то время как Oracle в среднем около 400 тысяч.


Выбор средств разработки.

Наиболее распространенным средством разработки различных приложений в среде Windows в настоящее время является Borland Delphi.

Среда Delphi обладает с одной стороны, высокой производительностью приложений благодаря созданию полностью скомпилированного кода, удобной настраиваемой средой разработки, компонентной архитектурой, позволяющей строить приложение путем сборки его из отдельных компонентов, множество которых имеет широкое распространение, а с другой стороны – возможностью доступа к разнообразным данным, начиная от плоских таблиц типа dBase и Paradox и заканчивая разнообразными серверными СУБД. Delphi представляет собой 32-разрядную рабочую среду для создания 32-разрядных приложений, которые могут исполняться под управлением Windows NT, XP, Vista, Windows7.

Основной упор  модели в Delphi делается на то ,чтобы максимально производительно использовать код. Это позволяет очень быстро разрабатывать приложения, так как уже существуют заранее подготовленные объекты. А так же вы можете создавать свои собственные объекты, без каких-либо ограничений. Язык Delphi — строго типизированный объектно-ориентированный язык, в основе которого лежит хорошо знакомый программистам Object Pascal.

В стандартную поставку Delphi входят основные объекты из 270 базовых классов. На этом языке очень удобно писать, как приложения к базам данных, так даже и игровые программы. Если принять во внимание и удобный интерфейс для создания графических оболочек, то можно с уверенностью заявить что язык Delphi– это очень доступный для понимания, но в то же время и очень мощный язык программирования.

Бурное развитие информационных технологий требовало качественной и быстрой разработке программного обеспечения. Именно для таких разработок проявил себя Borland Delphi и Microsoft Visual Basic. В основе систем быстрой разработки (RAD-систем, Rapid Application Development — среда быстрой разработки приложений) лежит технология визуального проектирования и событийного программирования, и вам не надо будет думать над программным кодом и реализацией  стандартных задач, все что вам требуется это подключить определённый модуль (в зависимости от задачи) и правильно построить интерфейс программы.


Информационное обеспечение включает два комплекса: внемашинное информационное обеспечение (классификаторы технико-экономической информации, документы, методические инструктивные материалы) и внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структуры информационной базы: входных, выходных файлов, базы данных).


Требования к серверу:


Основной сервер системы должен иметь конфигурацию не ниже следующей:

• X3430 (2.40GHz, 95W, 8MB, 1333, Turbo 1/1/2/3) Quad Core
  
• ОЗУ не менее 2048 MB;
  
• 4 x 500GB SATA Non-HotPlug (RAID 5);
  
• сетевой адаптер
  

Требования к АРМ:

• процессор CPU Intel Pentium Dual-Core E5400 OEM (S - 775, 2.70 GHz)
  
• ОЗУ не менее 1024 MB;
  
• объем жесткого диска не менее 60 GB;
  
• сетевой адаптер;
  
• монитор;
  
• клавиатура.
  
• Мышь
  
• Принтер
  

Применяемое системное ПО должно быть лицензированным. В состав системного должны входить программные средства операционной системы и системы управления базами данных, обеспечивающие открытую архитектуру СУБД. В качестве СУБД будет использоваться SQL Server 2008.


Системные программные средства, используемые специалистами авиакомпании:

• лицензионная локализованная версия ОС Windows ХР, Windows 7.
  
• MS OFFICE версии 2003.
  
• набор драйверов для взаимодействия с СУБД MS SQL Server.
  
• Монитор.
  
• Клавиатура, мышь.
  
• Принтер.
  

3. Проектирование видов обеспечения.

1. Техническое обеспечение.
   

Автоматизированная система эксплуатации ВС для специалистов авиакомпании должна отражать:

1. Оперативную информацию о текущем и планируемом состоянии ВС, двигателей и комплектующих изделий.
   
2. Получение информации, обладающей критичностью минимальные остатки и переработка ресурсов.
   
3. Получение оперативной информации о содержании текущих и готовящихся производственных заданий.
   
4. Формирование всех видов документов и отчетностей, предусмотренных для группы подготовки производства
   

Основные действия:

1. Учет новых агрегатов, двигателей, ВС.
   
2. Отражение затрат на ремонт и модернизацию агрегатов, двтгателей, ВС.
   
3. Отражение движения агрегатов для ВС.
   
4. Списание агрегатов, двигателей, ВС.
   

Программа должна взаимодействовать с БД, установленной на одном из серверов БД ОАО «ЮТэйр».

Для организации такого взаимодействия должна быть использована технология клиент-сервер, где АРМ «специалиста авиакомпании» выступает в роли клиента, а сервер БД соответственно в роли сервера. На рисунке 3 изображена технология клиент – сервер.




Рисунок 3 – технология клиент – сервер.

2. Информационное обеспечение.