- стандарты на продукты;
- стандарты на ресурсы.
Это определение подчеркивает аспект среды информационной системы, которую предоставляет открытая система для ее использования. Оно также вводит понятие "функциональный стандарт (профиль)", составляющий основу нового направления в стандартизации ИТ - "функциональная стандартизация", которая охватывает:
• базовые стандарты, определяющие фундаментальные и общие процедуры. Они создают инфраструктуру, которая может быть использована различными приложениями, и каждое из них может выбирать собственные факультативные параметры из базовых стандартов;
• профили, определяют соответствующие подмножества или комбинации базовых стандартов и используются для обеспечения конкретных факультативных параметров из базовых стандартов, они создают основу для разработки унифицированных международно признанных и аттестационных тестов;
• механизмы регистрации, обеспечивающие средства спецификации детализированного набора параметров в рамках базовых стандартов и профилей.
26. Объекты стандартизации и состав стандартов, используемых в процессе создания информационных систем.
Зарубежными специалистами, работающими в области информационных технологий (ИТ) была предложена методология открытых систем. Основным ее достоинством является сохранение вложенных ранее инвестиций при построении информационных систем (ИС) на различных аппаратных и программных платформах, обеспечение взаимосвязи систем, переносимости прикладного программного обеспечения и данных.
Общие свойства открытых ИС можно определить следующим образом:
• расширяемость (или масштабируемость) - обеспечивается возможность добавления новых функций ИС или изменения некоторых уже имеющихся функций без изменения остальных функциональных частей ИС;
• мобильность (или переносимость) - обеспечивается возможность переноса программ и данных при модернизации или замене аппаратных платформ ИС, а также возможность работы людей, пользующихся данной ИТ, без их переучивания при изменении ИС;
• интероперабельность - обеспечивается способность к взаимодействию данной ИС с другими ИС;
• дружественность к пользователю.
По определению специалистов IEEE (The Institute of Electrical and Electronics Engineers): "Открытая система - исчерпывающий и согласованный набор международных стандартов ИТ и функциональных стандартов профилей, которые специфицируют интерфейсы, службы и поддерживающие форматы, чтобы обеспечить интероперабельность и мобильность приложений, данных и персонала".
Все без исключения стандарты верхнего уровня предназначены для создания открытых информационных систем. Стандарты открытых информационных систем необходимы для обеспечения взаимодействия информационных технологий за счет достижения следующих видов мобильности:
- мобильность данных, заключающаяся в способности систем к взаимодействию за счет использования согласованных форматов данных (стандарт ISO 7498); стандарты обмена ГОСТ 6201-90 (ISO9735), ГОСТ 6106-87(ISO 6422)
- мобильность программ, заключающаяся в переносе прикладных программ при замене технических средств (ISO 9945);
- мобильность пользователя, заключающаяся в предоставлении дружественного интерфейса пользователю, не имеющему специальной подготовки;
- расширяемость - возможность добавления (наращивания) новых функций, которыми ранее информационная система не обладала, без ее модификации.
Стандартизации подлежат:
- базовые функции операционных систем (какие?);
- функции управления базами данных и распределенная обработка (какие?);;
- функции пользовательского интерфейса (какие?);;;
- функции взаимосвязи открытых систем (какие?);;;
- структура данных и документов (какие?);; ;
- безопасность информационных систем и др
Под интерфейсом понимается совокупность правил, в соответствии с которыми осуществляется взаимодействие объектов (программ, оборудования, человека).
Сущность методологии состоит в том, что при построении информационных систем стыковка должна обеспечиваться благодаря использованию стандартных интерфейсов между всеми компонентами систем. При этом сами же компоненты, в ряде случаев, могут быть и не стандартизированы.
Обобщенная структура любой ИС представляется состоящей из двух взаимодействующих частей:
функциональной части, включающей прикладные программы (приложения), реализующие функции ИС,
и среды (системной части), обеспечивающей исполнение прикладных программ.
Здесь можно выделить две группы стандартов: стандарты интерфейсов взаимодействия прикладных программ со средой ИС (Application Program Interface - API) и стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface - EEI).
Спецификации внешних интерфейсов среды ИС и интерфейсов взаимодействия между компонентами самой среды - это строгие описания всех необходимых функций, служб и форматов определенного интерфейса. Совокупность таких описаний составляет модель открытых систем (Reference model).
Эта методология получила название "функциональной стандартизации".
В ней пять этапов.
Этап 1. Разработка базовых стандартов. Базовые стандарты образуют массив, который может быть использован для выполнения широкого круга функций.
Этап 2. Разработка функциональных стандартов. Основу функциональных стандартов образуют профили, представляющие собой подмножества базовых стандартов, ориентированных на работу в конкретных конфигурациях реальных объектов и конкретных применениях. Функциональные стандарты (ФС) представляют собой нормативные документы по стандартизации, каждый из которых содержит определение одного или нескольких профилей. Таким образом, обобщенно можно определить, что ФС является" справочником-путеводителем" по применимости базовых стандартов к конкретным приложениям и реальным системам.
Одной из наиболее важных функций ФС является создание основы для построения комплектов аттестационных тестов, предназначенных для определения соответствия систем реальным стандартам.
Этап 3. Формализованное описание протоколов, их тестирование. Данный этап связан с необходимостью тестирования (верификации) стандартов ввиду их сложности и возможности неоднозначной интерпретации. Результатом этого этапа является обратная связь с первым этапом для коррекции базовых стандартов.
Этап 4. Реализация - это применение стандартов в конкретных технических и технологических решениях.
Этап 5. Проверка реализации на соответствие стандартам. Этот этап включает в себя аттестационное тестирование, являющееся проверкой конкретных реализаций, позволяющее оценить правильность реализации требований стандартов.
Профили увязываются с базовыми стандартами, механизмами регистрации профилей и с аттестационными тестами систем, реализующих эти профили.
Основные принципы открытых систем, средства и методы функциональной стандартизации могут быть применены в самых различных предметных проблемно ориентированных областях деятельности при создании сложных систем, технологий и услуг.
27. Профили, как уточнение и адаптация стандартов к условиям их использования.
При создании информационной системы стандарты должны конкретизироваться в соответствии с целями управления и спецификой объекта управления.
Из всех стандартов можно выделить те, которое наилучшим образом соответствует специфике внедряемого информационного сервиса.
Под профилем стандартов понимается выделенная совокупность базовых стандартов с указанными требованиями и рекомендациями, предназначенными для реализации конкретной функции в конкретном программном, техническом и другом окружении.
Конкретное окружение – это
- тип предприятия,
- обслуживаемые функции управления,
- классы задач,
- условия передачи и обработки территориально распределенных данных,
- среда документооборота, охватывающего цехи, склады и службы управления производством и т. д.
Профилирование стандартов – это фундаментальное понятие, используемое для адаптации стандартов к конкретной области применения.
Профиль стандартов всегда объединяет в себе два качества:
- удовлетворяет потребности управления, то есть обеспечивает информационную поддержку соответствующих функций управления и решаемых задач на конкретном предприятии;
- удовлетворяет требованиям и принципам построения открытых систем, технических, программных и коммуникационных средств (переносимость, расширяемость, дружественный интерфейс и др.).
Благодаря профилю осуществляется агрегирование базовых стандартов и определение значений их параметров, которые в базовых стандартах не задаются.
Поэтому профиль это не только набор согласованных стандартов, но и их параметризация.
В профиле уточняются детали базовых стандартов следующим образом:
Базовый стандарт | Профиль одного стандарта | |
| Обязательная часть | |
| Опция 2 | |
| Опция 8 | |
Опция 8 | ||
Опция 8 | ||
Опция 9 |
Обязательная часть
Опция 1
Опция 2На базе одного стандарта может формироваться несколько профилей.
Например, на основе Федерального государственного обучающего стандарта «Прикладная информатика» можно создать учебные планы следующих профилей:
Информационные системы в экономике,
Информационные системы в юриспруденции,
Информационные системы в медицине и т. д.
Одна часть дисциплин в стандарте является общей для всех профилей, а другая – предназначена для конкретного профиля (см рис. 3.4а).
На практике имеет место и иной процесс: один профиль создается на базе нескольких стандартов, что представлено на рис. 3.4б.
Стандарты, определяющие процедуры и форматы отдельных элементов, описывают минимум обязательных функциональных возможностей и параметров, а также факультативные возможности сверх этого минимума.
Профили не могут противоречить базовым стандартам, но могут использовать конкретные альтернативные выборы их комбинаций.
28. Характеристика стандарта обмена данными, его состав.
Для того чтобы различные информационные системы и их элементы могли эффективно обмениваться информацией, необходимы определенные стандарты обмена данных.
Протокол передачи данных — набор соглашений интерфейса логического уровня, которые определяют обмен данными между различными программами. Эти соглашения задают единообразный способ передачи сообщений и обработки ошибок при взаимодействии программного обеспечения разнесённой в пространстве аппаратуры, соединённой тем или иным интерфейсом.
Стандартизированный протокол передачи данных также позволяет разрабатывать интерфейсы, не привязанные к конкретной аппаратной платформе и производителю.
Например, в Интернет используется набор сетевых стандартных протоколов разных уровней для взаимодействия в сетях - TCP/IP (англ. Transmission Control Protocol/Internet Protocol).
Рассмотрим сокращенную структуру стандарта обмена данными в системах класса «Банк-Клиент» на примере программной системы 1С: Предприятие:
Справочно:
Система 1С: Предприятие подготавливает и учитывает различные платежные документы.
Для доставки их в банк применяются системы дистанционного банковского обслуживания, в том числе и системы класса "Банк - Клиент".
Один из модулей этой системы устанавливается на рабочем месте бухгалтера.
Стандарт разработан с целью выработки единых правил обмена финансовыми документами, описания структуры и форматов данных.
Схема обмена данными представлена на рисунке ниже
Что мы видим?
Модуль "Клиент банка" - программа, установленная у пользователя.
Модуль "Банк" - программа, установленная в банке.
Обмен какими документами происходит?
заявление на аккредитив,
инкассовое поручение.
1. Что делает пользователь при передаче информации в Банк?
Вводит в программу информацию или использует уже имеющиеся файлы (то есть, вводит, исправляет, удаляет, выбирает) платежные документы.
Какие? – Смотри выше.
Передает их в банк, причем передача данных осуществляется в два этапа.
На первом этапе пользователь подготавливает данные (платежные документы) и с помощью модуля обмена данными формирует файл данных.
На втором, с помощью программы "Клиент банка" этот файл читается и обрабатывается (приводится к стандартному виду, в соответствии со стандартами передачи данных). Результат обработки передается по телекоммуникационным каналам в Банк.
2. Что делает пользователь при приеме информации из Банка?
Прием данных также осуществляется в два этапа.
На первом - пользователем инициируется прием данных из Банка и формирование файла.
На втором, с помощью модуля обмена данными " этот файл читается и обрабатывается.
29. Создание информационных систем с учетом стандартов их жизненного цикла.
В соответствии со стандартом ИСО/МЭК «Информационная технология. Процессы жизненного цикла программных средств» создание информационных систем должно базироваться на понятии «жизненный цикл» программной системы.
Под жизненным циклом понимается период времени ее существования, начиная с выработки первоначальной концепции и кончая ее моральным устареванием и ликвидацией.
Традиционный жизненный цикл проектирования стоит из
- анализа объекта и системы управления;
- проектирования информационной системы:
- внедрения информационной системы;
- тестирования и реализации.
В соответствии со стандартом ИСО/МЭК ТО 15504 жизненный цикл программной системы состоит из следующих процессов:
- Основные процессы;
- Процессы приобретения
- обоснование необходимости в приобретении
- выявление требований
- выбор поставщика
- поставка и приемка
- Инженерные процессы
- проектирование программных средств
- конструирование программных средств (производство программных продуктов)
- эксплуатация
- тестирование
- сопровождение
- Вспомогательные процессы;
- Документирование
- Идентификация документов на выходе всех процессов
- Спецификация которые должны получиться на выходе всех процессов
- Верификация
- Определение критериев верификации
- Организация верификации
- Идентификация дефектов
- Проверка соответствия
- Определение критериев соответствия рабочих продуктов
- Организация контроля соответствия
- Предоставление доказательств соответствия программных продуктов
- Организационные процессы.
- Административное управление
- Оценка ресурсов и работ
- Разработка планов по выполнению работ
- Организация мониторинга хода выполнения работ
- Непосредственно организационные процессы
- Определение текущей способности системы производить требуемые услуги
- Усовершенствование процессов
- Организация улучшения деятельности путем аттестации
- Сбор данных вида «цена-качество» для усовершенствования
В основных процессах фигурируют две стороны: заказчик и поставщик (разработчик). Заказчик, прежде всего, должен определиться с требованиями к будущей информационной системе.
Эти требования содержат стратегию ее приобретения (например, тендерное предложение), пользовательские требования к системе, обоснование заключения договора с поставщиком, согласование процесса приемки готовой системы.
Группа вспомогательных процессов предназначена для обслуживания других процессов.
Группа организационных процессов включает управленческие (административные) и организационные процессы.
Административное управление – это, прежде всего, планирование работы информационной системы и обеспечение того, чтобы она давала услуги, соответствующие требованиям.
Организационные процессы направлены на периодическую аттестацию основных процессов и определение уровня их соответствия установленным требованиям.
Результаты служат основанием для совершенствования информационной системы.
30. Этапы создания информационных систем с ориентацией на бизнес-процессы.
В информационных системах, ориентированных на бизнес-процессы, информационная поддержка управления ими осуществляется за счет интегрированных систем класса ERP.
Как правило, используется стандартное программное обеспечение. Однако, конкретные условия требуют адаптации.
Есть два пути.
Адаптация процессов на предприятии – изменение существующих в компании бизнес-процессов и организационной структуры под ERP-систему..
Адаптация ERP-системы к особенностям предприятия осуществляется в том случае, если в ней какая-либо функция либо отсутствует, либо выполняется не так надо. Эта адаптация, проводимая на уровне пользовательской настройки, проблемой не является. Поэтому традиционный цикл проектирования трансформируется во внедрение ERP-системы в следующей последовательности:
- определение требований;
- анализ расхождений;
- конфигурация и адаптация;
- тестирование и реализация.
В отличие от традиционных систем ввод в действие ERP-систем подразумевает внедрение заранее спроектированных разработчиком приложений, характеризующихся:
- процессно-ориентированной ориентацией;
- непосредственным участием конечных пользователей в процессе внедрения.
В том случае, если уместен процессный подход, то создаваемая информационная система не должна быть простым слепком существующей системы управления.
Поэтому, выполнить ряд работ, важнейшими среди которых являются инжиниринг и реинжиниринг бизнес-процессов.
Под инжинирингом бизнеса понимается набор методов и средств, которые используются на предприятии для описания и проектирования бизнеса. С их помощью осуществляется формальное описание существующих процессов, происходящих на предприятии. Цель бизнес-инжиниринга состоит в определении фактического состояния дел на предприятии и отражении его в моделях типа «как есть».
Реинжиниринг бизнеса – это радикальное перепроектирование бизнес-процессов для достижения улучшения показателей деятельности предприятия. В результате создается модель «Как должно быть». Реинжиниринг – это видение новых перспективных технологий работы предприятия.
В отличие от инжиниринга реинжиниринг предусматривает замену старых методов управления новыми, обеспечивающими улучшение деятельности предприятия.
При реинжиниринге сначала определяется «что» должна делать компания, предприятие и т. д., а за тем «как» она должна это осуществлять.
Весь процесс можно представить набором стадий и операций :
Начальная
Формулирование целей
Создание команды разработчиков
Разработка плана и бюджета проекта
Стадия моделирования
Описание существующих бизнес-процессов «Как есть»
Разработка моделей «Как должно быть»
Стадия реализации проекта
Создание сервисов, реализующих модели «Как должно быть»
Тестирование результатов реализации
Стадия внедрения
Опытная эксплуатация
Документирование
Обучение
В результате описания существующих бизнес-процессов «как есть» получаем
- общую и детализированную диаграммы потоков данных, являющихся содержанием функциональной модели бизнеса. В функциональной модели, выполняемой в нотации IDEF, отражается взаимосвязь функций (операций) и документов, в которых фиксируются результаты производственно-хозяйственной деятельности;
- спецификации основных бизнес-операций, в которых описываются правила (алгоритмы) выполнения операций в различных стандартных ситуациях. Правила могут принимать различные формы: дерево решений, формулы, схемы и т. д.;
- состав данных, используемых в основных и вспомогательных бизнес-процессах.
Все выявленные и формализованные бизнес-операции должны быть привязаны к структурным подразделениям с помощью специальных указателей.
Анализ моделей «как есть» позволяет выявить:
- наличие лишних процессов, от которых можно отказаться.
- наличие эквивалентных по содержанию, но разных по структуре процессов.
Этап «как должно быть» - один их самых ответственных участков создания информационных систем.
В нем определяются новые информационные сервисы, призванные поддерживать скорректированные бизнес-процессы (реинжиниринг бизнеса).
Зачем все это?
Например, для того, чтобы:
- увеличить прибыль;
- снизить затраты;
- сократить время обработки;
- сократить время планирования;
- улучшить организацию производственных процессов и т. д.
Как правило, новые модели ориентируются на признанные стандарты, поэтому одним из способов получения моделей «как должно быть» является использование эталонных моделей.
Эталонные модели – воплощают в себе лучший опыт.
Сравнение эталонных моделей «как должно быть» с фактическими моделями «как есть» позволяет в ряде случаев адаптировать последние к возможностям ERP-систем.
На рисунке ниже показан процесс трансформации одних моделей в другие.
Реализации проекта состоит из двух этапов:
- создание новых информационных сервисов
- тестирование полученных результатов.
Внедрение проекта, предполагает
- осуществление опытной эксплуатации системы,
- ее документирование и обучение персонала.
- документирование процессов информационного обслуживания.
31. Эффективность информационных систем.
Определение эффективности – это фундаментальная проблема, которая в области информатики в целом пока не решена.
Однако, этот вопрос очень важен при принятии решений об инвестициях в информационную инфраструктуру. Тут появляется проблема финансовой ответственности специалистов в области информатики.
Хотя информационные системы стали одной из крупнейших статьей расхода корпоративных расходов, инвестирование в них часто совершается в слепую, без ясного видения результатов.
Это потому что сложно определить результаты от эксплуатации информационной инфраструктуры вообще, и информационной системы в частности.
Проблемным является тоже и процесс подсчета затрат.
С одной стороны, затраты на информационные технологии распределяются по многим направлениям бухгалтерского учета, а с другой, существуют невидимые затраты, объем которых значителен.
Если каким-либо образом, например, с помощью экспертных или других оценок доходы от информационной системы удается определить, то экономическую эффективность информационной системы можно рассчитать следующим образом:
Э=R после - R до - Z
где Э - экономическая эффективность информационной системы;
R после, R до - результат годовой финансовой деятельности после и до внедрения информационной системы;
Z - затраты на внедрение и функционирование информационной системы.
Данная формула иллюстрирует лишь общий взгляд на определение эффективности, так как в ней не учитываются многие факторы.
Прежде всего, факторы, времени и неопределенности.
Первый фактор требует соблюдения соизмеримости одних и тех же величин, полученных в разные периоды, а второй - учета влияния на величину доходов и затрат тех событий, которые не поддаются предвидению.
Определять доходы, получаемые в результате эксплуатации информационной системы - достаточно сложная задача. Для ее решения следует рассмотреть источники их возникновения. Их можно разделить на несколько частей:
1. Доход, первого рода получают за счет применения таких информационных сервисов, которые непосредственно влияют на экономические показатели предприятия.
Например:
а) сокращение простоя оборудования за счет решения оптимизационной задачи;
б) сокращение затрат на хранение запасов материалов за счет повышения ритмичности поставок;
в) сокращение неустоек и выплат штрафных санкций за счет введения графика доставки продукции;
г) повышение рентабельности предприятия за счет применения экспертных систем в процессе принятия решений и т. д.
2. Доход второго рода получают за счет повышения производительности и качества труда, непосредственно зависящих от средств автоматизации управленческих функций.
Например:
а) снижение трудовых затрат на ввод первичных документов за счет их передачи по каналам связи;
б) сокращение времени решения бухгалтерских, финансовых, маркетинговых и других задач за счет применения средств автоматизации;
в) снижение затрат за счет сокращения штата сотрудников, привлекаемых к делопроизводству, поиску и сортировке управленческой документации за счет внедрения электронного документооборота и т. д.
Результаты второго рода могут быть измерены с помощью экономических показателей, находящихся в бухгалтерской отчетности.
3. Доход третьего рода получают за счет положительного взаимовлияния уже автоматизированных управленческих процессов на другие автоматизированные или не автоматизированные. Связь эта опосредованная (не прямая).
Например, улучшение работы службы маркетинга, за счет внедрения новых средств автоматизации, влияет не только на эффективность процессов сбыта и снабжения, но и на само производство, так как оно, возможно, будет работать более ритмично. Последнее повысит производительность труда.
Доходы третьего рода измерить достаточно трудно, нет общепризнанных взглядов, подходов и, соответственно, методик. Однако, синергетический (системный) эффект несомненно имеет место, что обязывает прилагать усилия к его изучению.
32. Оценка и выбор информационных систем и технологий.
В процессе создания информационных систем или технологий необходимо осуществить их оценку и выбор, исходя их возможностей и потребностей покупателя.
Для этого необходимо получить достоверную информацию о производителе покупаемого программного продукта.
Как правило, эта информация включает:
1. Оценку репутации фирмы-производителя на рынке программных продуктов, число продаж данного программного продукта.
2. Количество внедрений данного продукта фирмой-производителем.
3. Соответствие покупаемой системы стандартам открытых систем.
4. Адаптируемость системы к новым информационным потребностям, новому производству, новым организационным структурам (за счет изменения параметров настроек или написания новых программ).
5. Совместимость покупаемой системы с иными системами, которые уже функционируют на предприятии, например системами управления технологическими процессами.
6. Приемлемость цены, складывающаяся из цены покупки, внедрения, сопровождения. Опыт показывает, что полная цена в два-три раза выше, по сравнению с ценой собственно программного продукта.
Если по всем пунктам имеем положительный ответ, то переходят непосредственно к процессу оценки покупаемой и внедряемой информационной системы.
Процесс оценки выполняется на основе действующих в нашей стране следующих стандартов: ГОСТ Р ИСО/МЭК 9126-93.
Оценка программной продукции, ГОСТ .
Оценка качества программных средств. Общие положения; ИСО/МЭК «Информационная технология. Процессы жизненного цикла программных средств».
Оценка осуществляется на основе анализа соответствия продукта-претендента пожеланиям пользователя по следующим характеристикам:
- функциональные возможности;
- надежность и безопасность;
- практичность и удобство применения;
- эффективность;
- сопровождаемость.
Каждая характеристика оценивается с помощью атрибутов.
В зависимости от наличия или отсутствия - анализируемую информационную систему, можно оценить нулем или единицей (ДА, НЕТ).
Если сумму всех единиц разделить на число, характеризующее "идеальную" систему, то можно получить оценку анализируемой информационной системы. Согласно данной методике "идеальная" система оценивается числом 36.
Оценки
Высокая при 0,7< к ≤ 1,
средняя при 0,5< к ≤ 0,7
низкая при к < 0,5,
Характеристики качества программных средств
Справочно
Характеристика | Промежуточная характеристика | Детальная характеристика | Наличие(1) отсутствие(0) |
1.Функциональные возможности | 1.1. Функциональная пригодность | 1.1.1-соответствие программных средств целям их применения | 1 |
1.1.2-соответствие состава и содержания выходной информации требованиям пользователей | 1 | ||
1.1.3-соответствие исходной информации, используемой в организации, требованиям ПС | 0 | ||
1.2 Способность к взаимодействию | 1.2- с информационной системой вышестоящей организации | 1 | |
1.2.2- с информационной системой нижестоящей организации | 1 | ||
1.2.3- с компонентами распределенных баз данных | 0 | ||
1.2.4- с банками, налоговой инспекцией, казначейством и т. д. | 0 | ||
2. Надежность и безопасность | 2.1. Защищенность | 2.1.1-соответствие ПС требованиям защиты от предумышленных угроз безопасности | 0 |
2.1.2-обеспечение эффективности оперативных методов защиты и восстановления при реализации угроз | 1 | ||
2.1.3-соответствие нормативным документам на защиту от различных типов угроз | 0 | ||
2.1.4-обеспечение защиты от различных типов угроз | 0 | ||
2.2. Устойчивость функционирования | 2.2.1-наличие средств восстановления при ошибке на входе; | 1 | |
2.2.2-наличие средств восстановления при сбоях оборудования | 1 | ||
2.2.3-наличие средств управления средствами восстановления; | 0 | ||
2.2.4-наличие автоматического рестарта | 1 | ||
2.2.5-вероятность работоспособного функционирования в течение месяца | 0 | ||
3.Практичность и удобство применения | 3.1. Легкость освоения | 3.1.1-возможность освоения ПС по документации | 1 |
3.1.2-возможность освоения ПС на контрольном примере 3.1.3-возможность поэтапного освоения ПС | 1 | ||
3.2. Доступность эксплуатационных документов | 3.2.1-полнота и понятность документации для освоения | 1 | |
3.2.2-точность пользовательских документов | 0 | ||
3.2.3-достаточность документов для запуска ПС в эксплуатацию | 1 | ||
3.2.4-ясность формулировок и описаний в документации; | 0 | ||
3.3. Простота использования | 3.3.1-комфортность эксплуатации (удовлетворительно, неудовлетворительно) | 1 | |
3.3.2-простота эксплуатации ПС | 1 | ||
4. Эффективность | 4.1. Временная эффективность | 4.1.1-удовлетворение временем выполнения программ и временем выдачи ответов на запросы | 0 |
4.1.2-удовлетворение временем подготовки входных данных | 1 | ||
4.2. Экономическая эффективность | 4.1.3-удовлетворение затратами на защиту данных; | 1 | |
4.2.1-удовлетворение соотношением общих затрат на эксплуатацию ПС и получаемой прибылью | 0 | ||
4.2.2-удовлетворение соотношением затрат на защиту данных и получаемой прибылью | 1 | ||
5.Сопровождаемость | 5.1. Внесение текущих изменений в ПС в процессе эксплуатации | 5.1.1-наличие документов, содержащих сроки внесения текущих изменений в ПС | 1 |
5.1.2-полнота документов, отражающих порядок внесения текущих изменений в ПС | 1 | ||
5.1.3-наличие системы контроля за внесением текущих изменений в ПС | 1 | ||
5.2. Обучение персонала в период внедрения и после внесения изменений в ПС | 5.2.1-наличие системы обучения персонала в процессе внедрения ПС | 1 | |
5.2.2-наличие тестов для контроля уровня знаний обучаемых | 0 | ||
5.2.3-наличие системы обучения после внесения изменений в ПС | 1 | ||
5.2.4-наличие требований к знаниям персонала допущенного к эксплуатации ПС. | 1 | ||
Всего по всем строкам | 25 |
К= 25/35=0.714
Литература
1. , Одинцов системы в экономике (лекции, упражнения и задачи): Учебное пособие.- М.: Вузовский учебник, 2008 (стр. 38-90).
2. Базовые российские стандарты в области открытых систем: http://cert. *****/1/1- 2,html.
3. ГОСТ Р ИСО/МЭК 9126-93. Оценка программной продукции, М.: ИПК изд. стандартов, 1994.
4. Оценка и аттестация зрелости процессов создания и сопровождения программных средств и информационных систем (ISO/IEC TR 15504 – CMM)/ Пер. с англ. и др. М.: Книга и бизнес, 2001 (стр. 48-63).
5. ИСО/МЭК 12207—95 «Информационная технология. Процессы жизненного цикла программных средств», М.: ИПК изд. Стандартов, 2000.
6. ИСО/МЭК ТО 15504:1998, Информационные технологии. Аттестация процессов, относящихся к программным средствам..
7. Бочаров корпоративные информационные системы: Принципы построения: Учеб. пособие/, .- М.: Финансы и статистика, 2005.
8. Ойхман Е. Г, Реинжиниринг бизнеса: Реинжиниринг организаций и информационные технологии.- Финансы и статистика, 1997.
9. , Рачковская И. А., Савченко предприятием (фирмой) с использованием информационных систем: Уч. пособие.- М.: Инфра-М, 2007.
10. Деверадж С., Кохли Р. Окупаемость ИТ: Измерение отдачи от инвестиций в информационные технологий.- М.: издательский дом, 2005.
11. , Баркалов С. А., Гуреева И. В., Портных технологии в управлении бизнес-процессами.- М.: Институт проблем управления им. , 2001.
12. Липунцов процессами.-М., ДМК Пресс, М., Компания АйТи., 3003.
13. Гаврилов производством на базе стандарта MRP II .-СПб, Питер, 2002
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 |
