Меню
Главная
УСЛУГИ
Авторизация/Регистрация
Реклама на сайте
ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА КОМПЬЮТЕРНЫХ ТЕХНОЛОГИЙ ИНФОРМАЦИОННОГО...Предметные и прикладные информационные технологииПрограммные средства информационных технологийМетодические принципы совершенствования управления предприятием на...ОРГАНИЗАЦИЯ И СРЕДСТВА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ОБЕСПЕЧЕНИЯ...МЕТОДИЧЕСКИЕ ОСНОВЫ СОЗДАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ И ТЕХНОЛОГИЙ В...Переход к мягким пиар-технологиям: информационная повестка дняПравовые режимы информационных технологий, коммуникационных сетейСвойства и классификация информационных технологийИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ: ПОНЯТИЯ, ТЕРМИНОЛОГИЯ, КЛАССИФИКАЦИЯ
 
Главная arrow Информатика arrow Информационные технологии
< Предыдущая   СОДЕРЖАНИЕ

Методические средства информационных технологий

Для большинства технологий характерной чертой их развития является стандартизация и унификация.

Стандартизация – нахождение решений для повторяющихся задач и достижение оптимальной степени упорядоченности.

Унификация – относительное сокращение разнообразия элементов по сравнению с разнообразием систем, в которых они используются.

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

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

процессов характерен высокий уровень стандартизации (например для транспортирования информации), для других – он находится в зачаточном состоянии.

Многообразные стандарты и подобные им методические материалы упорядочим по следующим признакам [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 CDM (Custom Development Method) является развитием ранее разработанной версии Oracle CASE-Method, известной по использованию Designer/2000. Она ориентирована на разработку прикладных информационных систем под заказ. Структурно построена как иерархическая совокупность этапов, процессов и последовательностей задач.

Этапы:

• стратегия (определение требований);

• анализ (формирование детальных требований);

• проектирование (преобразование требований в спецификации);

• реализация (разработка и тестирование приложений);

• внедрение (установка, отладка и ввод в эксплуатацию);

• эксплуатация (поддержка, сопровождение, расширение).

Процессы:

• RD – определение производственных требований;

• ES – исследование и анализ существующих систем;

• ТА – определение технической архитектуры;

• DB – проектирование и построение базы данных;

• MD – проектирование и реализация модулей;

• CV – конвертирование данных;

• DO – документирование;

• ТЕ – тестирование;

• TR – обучение;

• 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). Каждый из этих стандартов базируется на исходных понятиях. Например, в стандарте IDEF0 (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-1+1997 (меню);

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 (практичность, понятность, обучаемость, простота использования).

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

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

• определение дерева задач (оглавление стандарта);

• определение типовых форм для каждой задачи;

• назначение исполнителей;

• разработка матрицы ответственности;

• разработка календарного графика;

• описание входящих и выходящих показателей;

• составление глоссария терминов.

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Предыдущая   СОДЕРЖАНИЕ
 
Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика