![]() Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву ![]() Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Методические средства информационных технологийСодержание книги
Поиск на нашем сайте
Для большинства технологий характерной чертой их развития является стандартизация и унификация. Стандартизация — нахождение решений для повторяющихся задач и достижение оптимальной степени упорядоченности. Унификация — относительное сокращение разнообразия элементов по сравнению с разнообразием систем, в которых они используются. Если в области традиционного материального производства уже давно сложилась система формирования и сопровождения стандартов, то в области информационных технологий многое предстоит сделать. Главная задача стандартизации в рассматриваемой области — создание системы нормативно-справочной документации, определяющей требования к разработке, внедрению и использованию всех компонентов информационных технологий. На сегодняшний день в области информационных технологий наблюдается неоднородная картина уровня стандартизации. Для ряда технологических процессов характерен высокий уровень стандартизации (например для транспортирования информации), для других — он находится в зачаточном состоянии. Многообразные стандарты и подобные им методические материалы упорядочим по следующим признакам [43]: 1. По утверждающему органу: • официальные международные стандарты; • официальные национальные стандарты; • национальные ведомственные стандарты; • стандарты международных комитетов и объединений; • стандарты фирм-разработчиков; • стандарты «де-факто». 2. По предметной области стандартизации: • функциональные стандарты (стандарты на языки программирования, интерфейсы, протоколы, кодирование, шифрование и др.); • стандарты на фазы развития (жизненного цикла) информационных систем (стандарты на проектирование, материализацию, эксплуатацию, сопровождение и др.). В зависимости от методического источника в качестве стандартов могут выступать метод, модель, методология, подход. Следует отметить, что указанные стандарты обладают разной степенью обязательности, конкретности, детализации, открытости, гибкости и адаптируемости. В качестве примера рассмотрим ряд стандартов различного уровня. Международный стандарт ISO/OSI разработан международной организацией по стандартизации (International Standards Organization — ISO), предназначен для использования в области сетевого информационного обмена, представляет эталонную семиуровневую модель, известную как модель OSI (Open System Intercongtction — связь открытых систем). Первоначально усилия были направлены на разработку структуры (модели) протоколов связи цифровых устройств. Основная идея была связана с разбиением функций протокола на семь различных категорий (уровней), каждый из которых связан с одним более высоким и с одним более низким уровнем (за исключением самого верхнего и самого нижнего). Идея семиуровневого открытого соединения состоит не в попытке создания универсального множества протоколов связи, а в реализации «модели», в рамках которой могут быть использованы уже имеющиеся различные протоколы. В последнее время достигнут значительный прогресс в реализации различных типов протоколов, о чем говорит успешное функционирование многих сетей передачи данных, например, Интернета. Более подробно данный стандарт изложен в подразд. 3.2.
Международный стандарт ISO/IEC 12207:1995-08-01 — базовый стандарт процессов жизненного цикла программного обеспечения, ориентированный на различные его виды, а также типы информационных систем, куда программное обеспечение входит как составная часть. Разработан в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения». Включает описание основных, вспомогательных и организационных процессов. Основные процессы программного обеспечения: • процесс приобретения, определяющий действия покупателя, приобретающего информационную систему, программный продукт или его сервис; • процесс поставки, регламентирующий действия поставщика, снабжающего указанными выше компонентами; • процесс разработки, определяющий действия разработчика принципов построения программного изделия; • процесс функционирования, определяющий действия оператора, обслуживающего информационную систему в интересах пользователей и включающий помимо требований инструкции по эксплуатации консультирование пользователей и организацию обратной связи с ними; • процесс сопровождения, регламентирующий действия персонала по модификации программного продукта, поддержке его текущего состояния и функциональной работоспособности.
Вспомогательные процессы регламентируют документирование, управление конфигурацией, обеспечение качества, верификацию, аттестацию, совместную оценку, аудит. Степень обязательности для организации, принявшей решение о применении ISO/IEC 12207, обусловливает ответственность в условиях торговых отношений за указание минимального набора процессов и задач, требующих согласования с данным стандартом. Стандарт содержит мало описаний, направленных на проектирование баз данных, что объясняется наличием отдельных стандартов по данной тематике. ГОСТ 34 в качестве объекта стандартизации рассматривает автоматизированные системы различных видов и все виды их компонентов, в том числе программное обеспечение и базы данных. Стандарт в основном рассматривает проектные документы, что отличает его от стандарта ISO/IEC 12207. В структуре стандарта выделяют стадии и этапы разработки автоматизированных систем (АС). Рассмотрим краткую характеристику: 1. Формирование требований к АС: • обследование объекта и обоснование необходимости создания АС; • формирование требований пользователя к АС; • оформление отчета о выполненной работе и заявки на разработку АС (тактико-технического задания); 2. Разработка концепции АС: • изучение объекта; • проведение необходимых научно-исследовательских работ; • разработка вариантов концепции АС, удовлетворяющей требованиям пользователя; • оформление отчета о выполненной работе; 3. Техническое задание: • разработка и утверждение технического задания. 4. Эскизный проект: • разработка предварительных проектных решений по системе и ее частям; • разработка документации на АС и ее части. 5. Технический проект: • разработка проектных решений по системе и ее частям; • разработка документации на АС и ее части; • разработка и оформление документации на поставку изделий для комплектования АС и/или технических требований (технических заданий) на их разработку; • разработка заданий на проектирование в смежных частях проекта объекта автоматизации. 6. Рабочая документация: • разработка рабочей документации на систему и ее части; • разработка или адаптация программ. 7. Ввод в действие: • подготовка объекта автоматизации к вводу АС в действие; • подготовка персонала; • комплектация АС поставляемыми изделиями (программными, техническими и информационными средствами); • строительно-монтажные работы; • пуско-наладочные работы; • предварительные испытания; • опытная эксплуатация; • приемочные испытания. 8. Сопровождение АС: • выполнение работ в соответствии с гарантийными обязательствами; • послегарантийное обслуживание. ГОСТ 34 содержит обобщенную понятийную и терминологическую систему, общую схему разработки, общий набор документов. В настоящее время обязательность выполнения ГОСТа 34 отсутствует, поэтому его используют в качестве методической поддержки. Методика Oracle COM (Custom Development Method) является развитием ранее разработанной версии Oracle CASE-Method, известной по использованию Designer/2000. Она ориентирована на разработку прикладных информационных систем под заказ. Структурно построена как иерархическая совокупность этапов, процессов и последовательностей задач. Этапы: • стратегия (определение требований);
• анализ (формирование детальных требований); • проектирование (преобразование требований в спецификации); • реализация (разработка и тестирование приложений); • внедрение (установка, отладка и ввод в эксплуатацию); • эксплуатация (поддержка, сопровождение, расширение). Процессы: • RD — определение производственных требований; • ES — исследование и анализ существующих систем; • ТА — определение технической архитектуры; • DB — проектирование и построение базы данных; • MD — проектирование и реализация модулей; • CV — конвертирование данных; • DO — документирование; • ТЕ — тестирование; • TR — обучение; 250 • TS — переход к новой системе; • PS — поддержка и сопровождение. Процессы состоят из последовательностей задач, причем задачи разных процессов взаимосвязаны ссылками. Методика не предусматривает включение новых задач, удаление старых, изменение последовательности выполнения задач. Методика необязательна, может считаться фирменным стандартом. В связи с широким использованием в настоящее время объектной технологии большой интерес представляет CORBA (Common Object Request Broker Architecture) — стандарт в виде набора спецификаций для промежуточного программного обеспечения (middleware) объектного типа. Его автором является международный консорциум OMG (Object Management Group), объединяющий более 800 компаний (IBM, Siements, Microsoft, Sun, Oracle и др.). OMG разработал семантический стандарт, включающий 4 основных типа: • объекты, моделирующие мир (студент, преподаватель, экзамен); • операции, относящиеся к объекту и характеризующие его свойства (дата рождения студента, пол и др.); • типы, описывающие конкретные значения операций; • подтипы, уточняющие типы. На основе этих понятий OMG определил объектную модель, спецификацию для развития стандарта CORBA, постоянно развиваемую. В настоящее время CORBA состоит из 4 основных частей: • Object Request Broker (посредник объектных запросов); • Object Services (объектные сервисы); • Common Facilities (общие средства); • Application and Domain Interfaces (прикладные и отраслевые интерфейсы). Параллельно с CORBA корпорацией Microsoft был разработан стандарт COM/DCOMB (Component Object Model/Distributed СОМ), предназначенный для объединения мелких офисных программ. Основным недостатком данного стандарта была ориентация на Windows и Microsoft. Корпорация Microsoft долгое время не присоединялась к OMG и развивала собственный стандарт. Однако жизнь заставила приступить к мирным переговорам. OMG взаимодействует с другими центрами стандартизации: ISO, Open Group, WWW консорциум, IEEE и многими другими. CORBA стал неотъемлемой частью распределенных объектных компьютерных систем.
Приведенные примеры стандартов дают представление о подходах к решению проблем стандартизации. Естественно затраты на стандартизацию могут сделать проектные работы по внедрению информационных технологий более дорогостоящими, однако эти затраты с лихвой окупаются в процессе эксплуатации и развития системы, например при замене оборудования или программной среды. Таким образом, стандартизация является единственной возможностью обеспечения порядка в бурно развивающихся информационных технологиях. По аналогии с современным строительством, когда дома строят из блоков или панелей, программные приложения реализуются из компонентов. Под компонентом в данном случае понимают самостоятельный программный продукт, поддерживающий объектную идеологию, реализующий отдельную предметную область и обеспечивающий взаимодействие с другими компонентами с помощью открытых интерфейсов. Такая технология направлена на сокращение сроков разработки программных приложений и обеспечение гибкости внедрения. В плане реализации подобной технологии естественным является переход от стандартизации интерфейсов к стандартизации компонентов. Для унификации этого процесса необходимы метастандарты проектирования бизнес-процессов, которые формулируют основные установочные концепции. На первый взгляд, бизнес-процессы и информационных технологии имеют мало общего. Однако внедрение информационных технологий всегда приводит к реорганизации бизнеса. Потому методики моделирования бизнеса имеют много общего с проектированием информационных систем. Здесь может быть выстроена следующая цепочка: предметная область — бизнес-модель — модель информационной системы — технологическая модель — детальное представление — функционирование системы. Среди стандартов проектирования бизнес-процессов можно отметить следующие: семейство стандартов IDEF (Integration Definition for Function), RUP (компании Rational Software), Catalysis (компании Computer Associates). Каждый из этих стандартов базируется на исходных понятиях. Например, в стандарте IDEFO (Integration Definition for Function Modeling) такими понятиями являются: • «Работа» (Fctivity) — для обозначения действия; • «Вход» (Input), «Выход» (Output), «Управление» (Control), «Механизм» (Mechanism) — для обозначения интерфейсов. Использование стандартов проектирования бизнес-процессов позволяет унифицировать процесс абстрагирования и формализации представления предметной области. Мощным методологическим средством в этой области является концепция CALS (Continuous Acquisition and Life cycle Support). Русскоязычный термин, отражающий специфику CALS — компьютерное сопровождение процессов жизненного цикла изделий (КСПИ). Выделяют следующие основные аспекты данной концепции: • компьютеризация основных процессов создания информации; • интеграция информационных процессов, направленная на. совместное и многократное использование одних и тех же данных; • переход к безбумажной технологии организации бизнес-процессов. В методологии CALS (КСПИ) существуют две составные части: компьютеризированное интегрированное производство (КИП) и интегрированная логистическая поддержка (ИЛП).
В состав КИП входят: • системы автоматизированного проектирования конструкторской и технологической документации САПР-К, САПР-Т, CAD/CAM); • системы автоматизированной разработки эксплуатационной документации (ETPD — Electronic Technical Develoment); • системы управления проектами и программами (РМ —); • системы управления данными об изделиях (PDM — Project Data Managent); • интегрированные системы управления (MRP/ERP/SCM). Система интегрированной логистической поддержки (ИЛП) предназначена для информативного сопровождения бизнес-процессов на послепроизводственных стадиях жизненного цикла изделий от разработки до утилизации. Целью внедрения ИЛП является сокращение затрат на хранение и владение изделием. В состав ИЛП входят: • система логистического анализа на стадии проектирования (Logistics Suuport Analysis); • система планирования материально-технического обеспечения (Order Administration, Invoicing); • элктронная эксплуатационная документация и электронные каталоги; • система поддержки эксплуатации и др. Важной составляющей (КСПИ) является электронная подпись (ЭЦП). Современный электронный технический документ состоит из двух частей: содержательной и реквизитной. Первая содержит необходимую информацию, а вторая включает аутентификацион-ные и идентификационные сведения, в том числе из обязательных атрибутов — одну или несколько электронных подписей. Развитие CALS (КСПИ) связано с созданием виртуального предприятия, которое создается посредством объединения на контрактной основе предприятий и организаций, участвующих в жизненном цикле продукции и связанных общими бизнес-процессами. Информационное взаимодействие участников виртуального предприятия реализуется на базе хранилищ данных, объединенных через общую корпоративную или глобальную сеть. Значительный прогресс достигнут в области стандартизации пользовательского интерфейса. Среди множества интерфесов выделим следующие классы и подклассы: • символьный (подкласс — командный); • графический (подклассы — простой, двухмерный, трехмерный); • речевой; > > • биометрический (мимический); ! • семантический (общественный). Выделяют два аспекта пользовательского интерфейса: функциональный и эргономический, каждый из которых регулируется своими стандартами. Один из наиболее распространенных графических двумерных интерфейсов WIMP поддерживается следующими функциональными стандартами: ISO 9241-12-1998 (визуальное представление информации, окна, списки, таблицы, метки, поля и др.); ISO 9241-14-1997 (меню);,jt ISO 9241-16-1998 (прямые манипуляции); п ISO/IES 10741-1995 (курсор); ISO/IES 12581-(1999-2000) (пиктограммы). Стандарты, затрагивающие эргономические характеристики, являются унифицированными по отношению к классам и подклассам: ISO 9241-10-1996 (руководящие эргономические принципы, соответствие задаче, самоописательность, контролируемость, соответствие ожиданиям пользователя, толерантность к ошибкам, на-страиваемость, изучаемость); ISO/IES 13407-1999 (обоснование, принципы, проектирование и реализация ориентированного на пользователя проекта); ГОСТ Р ИСО/МЭК 12119-2000 (требования к практичности, понятность, обозримость, удобство использования); ГОСТ Р ИСО/МЭК 9126—93 (практичность, понятность, обучаемость, простота использования). Оценивая вышеприведенные стандарты, необходимо подчеркнуть, что эффективность является критерием функциональности интерфейса, а соответствие пользовательским требованиям — критерием эр гоном ичности. Помимо общей формализации информационных технологий, рассмотренной выше, в настоящее время большое внимание уделяется разработке внутрикорпоративных стандартов. На первый взгляд, внедрение информационных технологий предполагает организацию безбумажного документооборота. Однако на практике существует большое количество отчетных форм, требующих твердой копий. К сожалению, на данном этапе невозможно разработать универсальный внутрикорпоративный стандарт и тиражировать его. Для унификации процесса формирования внутрикорпоративных стандартов используется единая технология их проектирования, содержащая следующую последовательность работ: • определение дерева задач (оглавление стандарта); • определение типовых форм для каждой задачи; • назначение исполнителей; • разработка матрицы ответственности; • разработка календарного графика; • описание входящих и выходящих показателей; • составление глоссария терминов. Контрольные вопросы 1. Что входит в состав базовых программных средств? 2. Дайте определение операционной системы. 3. Охарактеризуйте направления развития операционных систем. 4. Укажите направление эволюции современных языков программирования. 5. Какие элементы используются для семантического и синтаксического описания любой конструкции языка программирования? 6. В чем отличие языка программирования от его реализации? 7 Чем отличается компилятор от интерпретатора? 8. Перечислите стадии жизненного цикла программного продукта. 9. Какие функции реализуют программные среды? 10. Какие блоки входят в состав ЭВМ классической (фоннеймановской) архитектуры? 11. Каковы отличительные признаки машин баз данных? 12. Перечислите типы процессоров и укажите их отличительные признаки. 13. Укажите основные компоненты персонального компьютера. 14. Укажите самые распространенные аппаратные средства информационных технологий. 15. В чем назначение унификации и стандартизации? 16. Перечислите основные типы стандартов. 17. Какие основные процессы программного обеспечения охвачены современными стандартами? ЗАКЛЮЧЕНИЕ
|
|||||||||
Последнее изменение этой страницы: 2016-06-26; просмотров: 417; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 18.226.88.63 (0.012 с.) |