8. Оперативно-технологическая связь

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

  Различают магистральную сеть связи, дорожную сеть связи и сети станционной распорядительной телефонной связи – отделенческой и станционной. Отделенческая оперативно-технологическая связь организуется по диспетчерскому, постанционному и комбинированному типам, а также может быть прямой. При организации связи по диспетчерскому типу устройства избирательного вызова располагаются у диспетчера, и он единолично управляет процессом соединения с вызываемым объектом. Аппаратура промпункта не имеет устройств посылки вызова, который осуществляется голосом. При организации связи по постанционному типу промпункты оборудуются устройствами посылки вызова. При постанционно-диспетчерской связи аппаратуру постанционного типа устанавливают на участковой станции с подключением ручной междугородной телефонной станции.

8. Классификация вычислительных систем

Большое разнообразие вычислительных систем породило естественное желание ввести для них какую-то классификацию. Эта классификация должна однозначно относить ту или иную вычислительную систему к некоторому классу, который, в свою очередь, должен достаточно полно ее характеризовать. Таких попыток предпринималось множество. Одна из первых классификаций, ссылки на которую наиболее часто встречаются в литературе, была предложена М. Флинном в конце 60-х годов прошлого века. Она базируется на понятиях двух потоков: команд и данных. На основе числа этих потоков выделяется четыре класса архитектур:

• SISD (Single Instruction Single Data) - единственный поток команд и единственный поток данных. По сути дела это классическая машина фон Неймана. К этому классу относятся все однопроцессорные системы.

• SIMD (Single Instruction Multiple Data) - единственный поток команд и множественный поток данных. Типичными представителями являются матричные компьютеры, в которых все процессорные элементы выполняют одну и ту же программу, применяемую к своим (различным для каждого ПЭ) локальным данным. Некоторые авторы к этому классу относят и векторно-конвейерные компьютеры, если каждый элемент вектора рассматривать как отдельный элемент потока данных.

• MISD (Multiple Instruction Single Date) - множественный поток команд и единственный поток данных. М. Флинн не смог привести ни одного примера реально существующей системы, работающей на этом принципе. Некоторые авторы в качестве представителей такой архитектуры называют векторно-конвейерные компьютеры, однако такая точка зрения не получила широкой поддержки.

• MIMD (Multiple Instruction Multiple Date) - множественный поток команд и множественный поток данных. К этому классу относятся практически все современные многопроцессорные системы.

11. Microsoft Exchange Server — программный продукт для обмена сообщениями и совместной работы.

Основные функции Microsoft Exchange: обработка и пересылка почтовых сообщений, совместный доступ к календарям и задачам, поддержка мобильных устройств и веб-доступ, интеграция с системами голосовых сообщений (начиная с Exchange 2007), поддержка систем обмена мгновенными сообщениями

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

12. Протоколы получения почты

После попадания почты на конечный сервер, он осуществляет временное или постоянное хранение принятой почты. Существует две различные модели работы с почтой: концепция почтового хранилища (ящика) и почтового терминала.

POP3

В концепции почтового хранилища почта на сервере хранится временно, в ограниченном объёме (аналогично почтовому ящику для бумажной почты), а пользователь периодически обращается к ящику и «забирает» письма (то есть почтовый клиент скачивает копию письма к себе и удаляет оригинал из почтового ящика). На основании этой концепции действует протокол POP3.

IMAP

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

13. Модель OSI

1. физический уровень

2. канальный уровень

3. сетевой уровень

4. транспортынй уровень

5. сеансовый уровень

6. уровень представления

7. прикладной уровень

Протоколы IEEE 802

Протоколы ITU

Другие стандарты

• ANSI

• ATM Forum

• EIA

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

• распознать данные;

• разбить данные на управляемые блоки;

• добавить информацию к каждому блоку, чтобы:

• указать местонахождение данных;

• указать получателя;

• добавить информацию синхронизации и информацию для проверки ошибок;

• поместить данные в сеть и отправить их по заданному адресу.

14. Стек протоколов TCP/IP (англ. Transmission Control Protocol/Internet Protocol — протокол управления передачей) — набор сетевых протоколов разных уровней модели сетевого взаимодействия DOD, используемых в сетях. Протоколы работают друг с другом в стеке(англ. stack, стопка) — это означает, что протокол, располагающийся на уровне выше, работает «поверх» нижнего, используя механизмы инкапсуляции. Например, протокол TCP работает поверх протокола IP.

Стек протоколов TCP/IP основан на модели сетевого взаимодействия DOD и включает в себя протоколы четырёх уровней:

• прикладного (application),

• транспортного (transport),

• сетевого (network),

• канального (data link).

Протоколы этих уровней полностью реализуют функциональные возможности модели OSI. На стеке протоколов TCP/IP построено всё взаимодействие пользователей в IP-сетях. Стек является независимым от физической среды передачи данных.

15.Виды ПО:

• -Системное(ос, драйвер, утилиты)

• -Прикладное (для решения функциональных задач-ms office audio video)

• - сис. разработанное по( комплекс программ длоя создания по на яз. программирования)

• -субд(комплекс программ для управления бд-спец назн,универсал назнач, конкретиз. примеры: ibm db2 oracle ms sql server)

• -экспертные системы(компьютерная система, способная частично заменить специалиста-эксперта в разрешении проблемной ситуации, CLIPS OpenCyc WolframAlpha  HASP/SIAP

16. Систе́мное програ́ммное обеспе́чение — это комплекс программ, которые обеспечивают управление компонентами компьютерной системы, такими как процессор, оперативная память, устройства ввода-вывода, сетевое оборудование, выступая как «межслойный интерфейс», с одной стороны которого аппаратура, а с другой - приложения пользователя. 

17. Прикладная программа или приложение — программа, предназначенная для выполнения определенных пользовательских задач и рассчитанная на непосредственное взаимодействие с пользователем.

18. Средства разработки программного обеспечения – совокупность приемов, методов, методик, а также набор инструментальных программ (компиляторы, прикладные/системные библиотеки и т.д.), используемых разработчиком для создания программного кода Программы, отвечающего заданным требованиям.

19. Систе́ма управле́ния ба́зами да́нных (СУБД) — совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных^[

^20. Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации^[1]. Этот цикл — процесс построения и развития ПО. Модель жизненного цикла ПО — структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Модель жизненного цикла зависит от специфики, масштаба и сложности проекта и специфики условий, в которых система создается и функционирует. Водопадная (каскадная, последовательная) модель

Основная статья: Модель водопада

Водопадная модель жизненного цикла (англ. waterfall model) была предложена в 1970 г. Уинстоном Ройсом. Она предусматривает последовательное выполнение всех этапов проекта в строго фиксированном порядке. Переход на следующий этап означает полное завершение работ на предыдущем этапе. Требования, определенные на стадии формирования требований, строго документируются в виде технического задания и фиксируются на все время разработки проекта. Каждая стадия завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой разработчиков.

Этапы проекта в соответствии с каскадной моделью:

1. Формирование требований;

2. Проектирование;

3. Реализация;

4. Тестирование;

5. Внедрение;

6. Эксплуатация и сопровождение.

Преимущества:

• Полная и согласованная документация на каждом этапе;

• Легко определить сроки и затраты на проект.

Недостатки:

В водопадной модели переход от одной фазы проекта к другой предполагает полную корректность результата (выхода) предыдущей фазы. Однако неточность какого-либо требования или некорректная его интерпретация в результате приводит к тому, что приходится «откатываться» к ранней фазе проекта и требуемая переработка не просто выбивает проектную команду из графика, но приводит часто к качественному росту затрат и, не исключено, к прекращению проекта в той форме, в которой он изначально задумывался. По мнению современных специалистов, основное заблуждение авторов водопадной модели состоит в предположениях, что проект проходит через весь процесс один раз, спроектированная архитектура хороша и проста в использовании, проект осуществления разумен, а ошибки в реализации легко устраняются по мере тестирования. Эта модель исходит из того, что все ошибки будут сосредоточены в реализации, а потому их устранение происходит равномерно во время тестирования компонентов и системы^[2]. Таким образом, водопадная модель для крупных проектов мало реалистична и может быть эффективно использована только для создания небольших систем^[3].

[править]Итерационная модель

Альтернативой последовательной модели является так называемая модель итеративной и инкрементальной разработки (англ. iterative and incremental development, IID), получившей также от Т. Гилба в 70-е гг. название эволюционной модели. Также эту модель называютитеративной моделью и инкрементальной моделью^[4].

Модель IID предполагает разбиение жизненного цикла проекта на последовательность итераций, каждая из которых напоминает «мини-проект», включая все процессы разработки в применении к созданию меньших фрагментов функциональности, по сравнению с проектом в целом. Цель каждой итерации — получение работающей версии программной системы, включающей функциональность, определённую интегрированным содержанием всех предыдущих и текущей итерации. Результат финальной итерации содержит всю требуемую функциональность продукта. Таким образом, с завершением каждой итерации продукт получает приращение — инкремент — к его возможностям, которые, следовательно, развиваются эволюционно. Итеративность, инкрементальность и эволюционность в данном случае есть выражение одного и то же смысла разными словами со слегка разных точек зрения^[3].

По выражению Т. Гилба, «эволюция — прием, предназначенный для создания видимости стабильности. Шансы успешного создания сложной системы будут максимальными, если она реализуется в серии небольших шагов и если каждый шаг заключает в себе четко определённый успех, а также возможность «отката» к предыдущему успешному этапу в случае неудачи. Перед тем, как пустить в дело все ресурсы, предназначенные для создания системы, разработчик имеет возможность получать из реального мира сигналы обратной связи и исправлять возможные ошибки в проекте»^[4].

Подход IID имеет и свои отрицательные стороны, которые, по сути, — обратная сторона достоинств. Во-первых, целостное понимание возможностей и ограничений проекта очень долгое время отсутствует. Во-вторых, при итерациях приходится отбрасывать часть сделанной ранее работы. В-третьих, добросовестность специалистов при выполнении работ всё же снижается, что психологически объяснимо, ведь над ними постоянно довлеет ощущение, что «всё равно всё можно будет переделать и улучшить позже»^[3].

Различные варианты итерационного подхода реализованы в большинстве современных методологий разработки (RUP, MSF, XP).

[править]Спиральная модель

Спиральная модель (англ. spiral model) была разработана в середине 1980-х годов Барри Боэмом. Она основана на классическом цикле Деминга PDCA (plan-do-check-act). При использовании этой модели ПО создается в несколько итераций (витков спирали) методом прототипирования.

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

На каждой итерации оцениваются:

• риск превышения сроков и стоимости проекта;

• необходимость выполнения ещё одной итерации;

• степень полноты и точности понимания требований к системе;

• целесообразность прекращения проекта.

Важно понимать, что спиральная модель является не альтернативой эволюционной модели (модели IID), а специально проработанным вариантом. К сожалению, нередко спиральную модель либо ошибочно используют как синоним эволюционной модели вообще, либо (не менее ошибочно) упоминают как совершенно самостоятельную модель наряду с IID^[3].

Отличительной особенностью спиральной модели является специальное внимание, уделяемое рискам, влияющим на организацию жизненного цикла, и контрольным точкам. Боэм формулирует 10 наиболее распространённых (по приоритетам) рисков:

1. Дефицит специалистов.

2. Нереалистичные сроки и бюджет.

3. Реализация несоответствующей функциональности.

4. Разработка неправильного пользовательского интерфейса.

5. Перфекционизм, ненужная оптимизация и оттачивание деталей.

6. Непрекращающийся поток изменений.

7. Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.

8. Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.

9. Недостаточная производительность получаемой системы.

10. Разрыв в квалификации специалистов разных областей.

21. CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств [Вендров А.М., www.citforum.ru/database/case/index.shtml].

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

Большинство CASE-средств основано на парадигме "методология/метод/нотация/структура/средство".

Методология задает руководящие указания для оценки и выбора проекта разработки ПО, этапы и последовательность работ, правила применения тех или иных методов.

Метод - систематическая процедура или технология генерации описаний компонент ПО (например, описание потоков и структур данных).

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

Структуры являются средством для реализации структурного анализа и построения структуры конкретной системы.

Средства - технологические и программные инструменты для поддержки и усиления методов.

CASE-технологии обладают следующими основными достоинствами, которые позволяют широко использовать их при разработке информационных систем:

• ускоряют процесс коллективного проектирования и разработки;

• позволяют за короткий срок создать прототип заказанной системы с заданными свойствами;

• освобождают разработчика от рутинной работы, оставляя время для творчества;

• обеспечивают эффективность и качество разрабатываемого ПО за счет автоматизации контроля всего процесса разработки;

• поддерживают сопровождение и развитие системы на высоком уровне.

Следует отметить, что, несмотря на все потенциальные возможности CASE-средств, существует достаточно много примеров их неудачного внедрения, в результате которых CASE-средства становятся "полочным" ПО (Shelfware).

В связи с этим необходимо учитывать следующее:

• CASE-средства не обязательно дают немедленный эффект, он может быть получен только спустя какое-то время;

• реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;

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

Можно также перечислить следующие факторы, усложняющие определение возможного эффекта от использования CASE-средств:

• широкое разнообразие качества и возможностей CASE-средств;

• относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

• широкое разнообразие в практике внедрения различных организаций;

• отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

• широкий диапазон предметных областей проектов;

• различная степень интеграции CASE-средств в различных проектах.

Билет 22

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

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

В-третьих, необходимость технологических решений в большинстве случаев может быть закреплена получением технологических документов.

Билет 23

Система СИРИУС создана на современно программой технической базе и рассматривается как корпоративная (система формируется по одним и тем же правилам для однородных объектов) и интегральная (функционирование системы на основе единой информационной базы, предусматривающий идентичность представления информации об объектах в серверах различных уровней управления а также использование единых источников сбора и обработки данных). Система СИРИУС в отведенной в ней зоне ответственности, решает главную целевую задачу ОАО «РЖД» - обеспечение прибыль компании.

Система выполнена по модульной схеме которая включает в себя БД АСОУП-2, источник данных, JDBC Data Source, сервер удаленных объектов( RMI Remote Server), WEB - приложение СИРИУС, приложение STDP менеджер, WEB – браузер.

В момент загрузки системы стартуют приложение сервиса имен, сервер СИРИУС, клиент – сервер СИРИУС и STDP менеджер каждая в своем потоке.

В момент инициализации сервер СИРИУС создает объекты удаленного доступа который регистрируется в сервисе имен в момент инициализации Client Server Sirius выполняет подключение к серверам Сервер СИРИУС через запросы Name Service. Пользователь системы формирует через Web – браузер, и запрашивает требуемые данные.

Web – приложения 2 уровня принимают запросы пользователей, обрабатывает их, и в зависимости от полученных параметров формирует запрос в одну или несколько систем Сервер СИРИУС по RMI соединению. Запросы в разные системы обрабатываются в параллельном режиме

Билет 24

АРМ пользователя системы ДИСПАРК включает в себя: IBM-совместимый персональный компьютер (PC), цветной монитор, принтер с форматом печати АЗ, операционную систему Windows ХР.

. Система функционирует в масштабе реального времени, охватывает всю сеть российских железных дорог. ДИСПАРК содержит сведения о каждом вагоне, охватывающие около ста возможных операций, осуществляемых с ним. Это позволяет осуществлять более точную оценку работы вагонного парка и тем самым создает предпосылки для автоматизированного управления качеством грузовых перевозок.

Эффективность системы ДИСПАРК обеспечивается за счет:

- сокращения порожнего пробега вагонов путем автоматизированного пономерного прикрепления их к заявкам на погрузку;

- увеличения доходов от информирования грузоотправителей и грузополучателей о месте нахождения, времени прибытия вагонов;

- увеличения доходов от предоставления вагонов в аренду и компаниям-операторам;

-сокращения потерь от нарушения сроков доставки и от несохранных перевозок;

- сокращения объема капитальных вложений в приобретение новых вагонов за счет улучшения использования существующего парка;

- сокращения объема платы за использование «чужих» вагонов в результате оптимальной регулировки парка вагонов.

Билет 26

. ДИСКОР представляет собой систему, связывающую комплексы АСОУП, ИОММ, «Экспресс», ЕК ИОДВ, а также различные средства программирования. На основе современных технологий («клиент-сервер» и Intranet) система ДИСКОР позволяет получить сведения об основных показателях работы дороги, таких как погрузка, выгрузка, работа подвижного состава, прием и сдача вагонов и т.п. ДИСКОР функционирует на основе web-технологий, что существенно упрощает процесс установки и конфигурирования клиентских АРМ. В качестве универсального ПО используется программа просмотра web (например, MS Internet Explorer).

Билет 27

ЭТРАН (электронная транспортная накладная) — это автоматизированная система централизованной подготовки и оформления пеЬевозочных документов.

Целью системы ЭТРАН является переход на использование электронного документооборота для взаимодействия с пользователями услуг железнодорожного транспорта при организации перевозок грузов.

Назначение системы. При разработке системы ЭТРАН предусматривалось:

- внедрение электронного документооборота с использованием внут- •, ренней и внешних сетей передачи данных;

- обеспечение защиты конфиденциальной информации сертифицированными средствами;

- обеспечение режима реального времени: не более 3—5 с на одну технологическую операцию;

- обеспечение однократности ввода информации и минимальное число корректировок;

- обеспечение решения новых задач в системе;

- обеспечение решения действующих задач в новой постановке;

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

- более глубокая интеграция с автоматизированными системами оперативного управления перевозками (АСУП) и автоматизированной системой управления финансами и ресурсами (ЕК АСУФР);

- включение грузоотправителей и экспедиторов в технологический процесс на основе решений в области электронного документооборота;

-сохранение и развитие на переходный период существующих комплексов по обработке перевозочных документов (ЕК ИОДВ, АС ТехПД, АРМ ТВК, и интерфейсов с АСУП, ЕК АСУФР.

Билет 29

• ЕК АСУФР – единая корпоративная автоматизированная система управления финансами и ресурсами;

• Назначение ЕК АСУФР - обеспечение эффективного корпоративного управления финансами и ресурсами единого хозяйствующего субъекта железнодорожного транспорта с развитой филиальной структурой, дочерними предприятиями и диверсифицированной хозяйственной деятельностью.

• ЕК АСУФР является многофункциональной ERP-системой, состоящей из множества взаимоувязанных прикладных подсистем, реализация которых обеспечивается на основе стандартного промышленного продукта SAP R/3.

Стратегическими целями системы ЕК АСУФР являются:

• интеграция бизнес-процессов в единую систему управления;

• прозрачность финансового и бухгалтерского учета;

• повышение эффективности в сфере отчетности и управления;

• единая методология учета и управления, соответствие бухгалтерского учета национальным и международным стандартам;

• сокращение числа устаревших прикладных систем;

• обеспечение инвестиционной привлекательности отрасли.

ЕК АСУФР включает в свой состав два функциональных уровня, распределенных по центральному и дорожным сегментам системы:

• уровень корпорации (центральный уровень);

• уровень филиалов и структурных подразделений (дорожный уровень).

При этом обеспечиваются:

• единая методология хозяйственной деятельности (план счетов, аналитика, бизнес - процессы, перечень хозяйственных операций);

• единое стандартное программно-технологическое обеспечение SAP R/3;

• единая методология разработки и внедрения (ASAP);

• единая вычислительная платформа.