Понятие информационной системы

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

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

Вообще говоря, все стандарты на информационные системы (как и на любые системы вообще) можно разбить на следующие два основных класса:

- Функциональные стандарты, определяющие порядок функционирования системы в интересах достижения цели, поставленной перед нею ее создателями.

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

Модели, определяемые стандартами этих двух классов, конечно же взаимосвязаны, однако решают совершенно разные задачи и характеризуются принципиально различными подходами к их построению.

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

Таким образом, жизненный цикл информационной системы охватывает все стадии и этапы ее создания, сопровождения и развития:

? предпроектный анализ (включая формирование функциональной и информационной моделей объекта, для которого предназначена информационная система);

? проектирование системы (включая разработку технического задания, эскизного и технического проектов);

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

? интеграцию и сборку системы, проведение ее испытаний;

? эксплуатацию системы и ее сопровождение;

? развитие системы.

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

Эти проблемы привели к тому, что подавляющее большинство проектов информационных систем внедряется с нарушениями качества, сроков или сметы.

Почти треть проектов информационных систем прекращают свое существование, оставшись незавершенными. По данным, публикуемым Standish Group, в 1996 году 84% проектов информационных систем не были завершены в установленные сроки, в 1998 году сократилась до 74%, однако и в 2000-м общий объем «хронической незавершенки» не опустился ниже 50%.

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

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

В России создание и испытания автоматизированных систем, к которым относятся и информационные системы, регламентированы рядом ГОСТов, прежде всего серии 34. Однако отдельные положения этих ГОСТов уже устарели, а ряд этапов жизненного цикла информационных систем предоставлены недостаточно полно. Поэтому более целесообразно рассматривать в качестве определяющего документа международный стандарт ISO/IEC 12207. Данный стандарт определяет структуру жизненного цикла, содержащую процессы, которые должны быть выполнены во время создания программного обеспечения информационной системы.

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

Каскадная и спиральная модели

Однако стандарт ISO/IEC 12207 не предлагает конкретной модели жизненного цикла и методов разработки, его рекомендации являются общими для любых моделей жизненного цикла. Под моделью обычно понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и задач на протяжении жизненного цикла. Из существующих в настоящее время моделей наиболее распространены две: каскадная и спиральная. Они принципиально различаются самим подходом к информационной системе и ее программному обеспечению. Суть различий в том, что в каскадной модели информационная система является однородной и ее программное обеспечение определяется как единое (с ней) целое. Данный подход характерен для более ранних информационных систем (каскадный метод применяется с 1970 года), а также для систем, для которых в самом начале разработки можно достаточно точно и полно сформулировать все требования. При выполнении этих условий каскадный метод позволяет достичь хороших результатов.

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

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

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

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

CALS

Аббревиатура CALS расшифровывается как Continuous Acquisition and Life cycle Support -- непрерывная информационная поддержка жизненного цикла продукта. Встречается также другой перевод, менее схожий с исходным названием, но более близкий по смыслу: обеспечение неразрывной связи между производством и прочими этапами жизненного цикла изделия. Данная технология, разработанная в 80-х годах в Министерстве обороны США, распространилась по всему миру и охватила практически все сферы мировой экономики. Она предназначена для повышения эффективности и качества бизнес-процессов, выполняемых на протяжении всего жизненного цикла продукта, за счет применения безбумажных технологий. Началом создания системы CALS-технологий явилась разработка системы стандартов описания процессов на всех этапах жизненного цикла продукции.

В международных стандартах серии ISO 9004 (управление качеством продукции) введено понятие «жизненный цикл изделия». Данное понятие включает в себя следующие этапы жизненного цикла изделия: маркетинг, поиск и изучение рынка; проектирование и/или разработка технических требований к создаваемой продукции; материально-техническое снабжение; подготовка и разработка технологических процессов; производство; контроль, проведение испытаний и обследований; упаковка и хранение; реализация и/или распределение продукции; монтаж, эксплуатация; техническая помощь в обслуживании; утилизация после завершения использования продукции.

Для развития методологии CALS в США были созданы Управляющая промышленная группа по вопросам CALS (ISG) и ее исполнительный консультативный комитет. В настоящий момент в мире действует более 25 национальных организаций (комитетов или советов по развитию CALS), в том числе в США, Японии, Канаде, Великобритании, Германии, Швеции, Норвегии, Австралии и других странах, а также в НАТО.

Основные усилия этих и подобных организаций были направлены на создание разного уровня нормативной документации. За последние несколько лет разработаны следующие документы: ISO 10303 (Industrial automation systems and integration -- Product data representation and exchange), ISO 13584 (Part Library), Def Stan 00-60 (Integrated Logistic Support), MIL-STD-2549 (Configuration Management. Data Interface), MIL-HDBK-61 (Configuration Management. Guidance), AECMA Specification 2000M (International Specification for Materiel Management Integrated Data Processing for Military Equipment), AECMA Specification 1000D (International Specification for Technical Data Publications, Utilising a Common Source Data Base) и т. д.

Стандарты CALS

Стандарты, разработанные ISO для CALS-технологий, можно разбить на три группы: представление информации о продукте, представление текстовой и графической информации и общего назначения. К первой группе относятся: ISO/IEC 10303 Standard for the Exchange of Product Model Data (STEP) и ISO 13584 Industrial Automation -- Parts Library.

Во вторую группу входят: ISO 8879 Information Processing -- Text and Office System -- Standard Generalized Markup Language (SGML); ISO/IEC 10179 Document Style Semantics and Specification Language (DSSSL); ISO/IEC IS 10744 Information Technology -- Hypermedia/Time Based Document Structuring Language (HyTime); ISO/IEC 8632 Information Processing Systems -- Computer Graphics -- Metafile; ISO/IEC 10918 Coding of Digital Continuous Tone Still Picture Images (JPEG); ISO 11172 MPEG2 Motion Picture Experts Group (MPEG); Coding of Motion Pictures and associated Audio for Digital Storage Media и ISO/IECS 13522 Information Technology -- Coding of Multimedia and Hypermedia Information (MHEG).

Третья группа: ISO 11179 Information Technology -- Basic Data Element Attributes; ISO 3166 Information Processing -- Country Name Representations; ISO 31 Information Processing Representation of Quantities and Units; ISO 4217 Information Processing -- Currencies and Funds; ISO 639 Information Processing Coded Representation of Names of Languages и ISO 8601 Information Processing -- Date/Time Representations.

Кроме международных стандартов, разработанных ISO, стандарты CALS широко представлены стандартами с индексами MIL и FIPS, которые лишний раз подчеркивают приоритетность разработки технологии CALS Соединенными Штатами и их военным ведомством изначально (самая многочисленная группа стандартов CALS имеет индекс MIL -- стандартный индекс для документов, разработанных в МО США). Аббревиатура FIPS означает федеральный стандарт обработки информации (Federal Information Processing Standard).

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

Стандарты FIPS не так многочисленны, как ISO и MIL, и делятся всего на две группы: описания процессов и безопасности информации.

Госстандарт РФ готовит набор ГОСТов, отражающих, в частности, требования CALS-ориентированных стандартов серии ISO 10303 (Системы автоматизации производства и их интеграция; представление данных об изделии и обмен этими данными). Однако внедрение CALS-подхода в России имеет специфические сложности: часто для использования CALS-решений требуется предварительное проведение реинжиниринга бизнес-процессов; невысок уровень компьютеризации предприятий; отсутствует нормативная база; не хватает специалистов; нет рынка CALS-продуктов и услуг; нет денег на внедрение CALS технологий.

Понятно, что первоочередной задачей для развития CALS-технологий в России является создание соответствующей нормативной базы. Поэтому Госстандартом России и Минэкономики России было принято решение о совместном финансировании разработки ряда первоочередных стандартов, которые открывают путь к внедрению CALS-технологий в отечественной промышленности. В настоящее время уже утверждены первые стандарты в области CALS. Создан и уже действует Технический комитет №431 при Госстандарте России, организованный на базе научно-исследовательского центра CALS, основная задача которого -- разработка стандартов в области CALS.

К настоящему времени приняты следующие стандарты серии «Системы автоматизации производства и их интеграция»:

ГОСТ Р ИСО 10303-1-99. Методы описания. Общий обзор и основополагающие принципы;

ГОСТ Р ИСО 10303-21-99. Представление и обмен данными об изделии. Методы реализации. Текстовый обменный файл;

ГОСТ Р ИСО 10303-41-99. Представление и обмен данными об изделии. Интегрированные родовые ресурсы. Принципы описания продукта.

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

Процесс внедрения технологий в России не стоит на месте. Так, 24 октября 2000 года Министерство промышленности, науки и технологий России и научно-исследовательский центр CALS-технологий «Прикладная логистика», при содействии и участии Госстандарта России и государственной компании «Росвооружение», провело II научно-техническую конференцию «CALS-технологии -- ключ к обеспечению успеха предприятий на внутреннем и внешнем рынках». На конференции присутствовало более 300 участников, представлявших 125 предприятий и организаций из 35 регионов России.

Эксплуатация информационных систем

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

Тут встает вопрос -- а в качестве кого по отношению к информационной системе (например, корпоративной сети предприятия) выступают те, кто работает на предприятии и занят ее эксплуатацией -- системные администраторы, менеджеры, пользователи и т. д.? В развитой современной корпорации специалисты по информационным технологиям принимают самое непосредственное участие в формировании сетевого решения -- выборе архитектуры, оптимизации топологии, настройке сетевого программного обеспечения и конечно же модернизации сети. Другими словами, сотрудники предприятия по отношению к сети выступают в качестве одних из ее создателей. Следовательно, модель жизненного цикла информационной системы, хотят они этого или нет, становится их рабочим инструментом.

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

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

Эффективность реализации CALS

Основная задача, решаемая путем применения CALS-технологий, -- экономия времени и средств при одновременном повышении качества. Так, в США применение CALS-технологий сопровождается следующими типовыми показателями.

? В процессах проектирования и инженерных расчетах: сокращение времени проектирования на 50%; снижение затрат на изучение выполнимости проектов на 15-40%.

? В процессах организации поставок: уменьшение количества ошибок при передаче данных на 98%; сокращение времени поиска и извлечения данных на 40%; сокращение времени планирования на 70%; сокращение стоимости информации на 15-60%.

? В производственных процессах: сокращение производственных затрат на 15-60%; повышение показателей качества на 80%;

? в процессах эксплуатационной поддержки изделий: сокращение времени на изменения технической документации на 30%; сокращение времени планирования поддержки на 70%; снижение стоимости технической документации на 10-50%.

11. Общая стоимость владения информационной инфраструктурой

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

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

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

· изменения в законодательстве;

· изменение оргструктуры компании;

· появление новых технологий (например, распространение Интернета перевернуло все представления о бизнесе).

Обычно нужно оценить расходы, связанные с владением покупкой на протяжении нескольких лет. Методы такой оценки существуют и известны под названием TCO -- total cost of ownership, или совокупная стоимость владения, которая помогает оценить затраты, связанные с использованием всех составляющих элементов ИС за период их жизненного цикла.

В принципе модель ТСО призвана помочь руководителям ИТ-отделов распределить средства таким образом, чтобы добиться максимальной отдачи от инвестиций в ИТ и при этом уложиться в бюджет, выделенный на внедрение. ТСО нередко оказывается решающим фактором при выборе и внедрении (или при отказе от внедрения) какого-либо информационного продукта.

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

Не менее важным является вопрос о том как снизить ТСО. По экспертным оценкам, при правильном подходе к снижению непродуктивных затрат, реальная экономия может составить до трети общих расходов на ИТ.

Основными направлениями снижения ТСО можно назвать:

- внедрение аутсорсинга;

- максимальную централизацию обработки и хранения информации;

- уменьшение числа специализированных элементов (прежде всего компьютеров с прикладным ПО);

- перенос прикладного ПО на серверы приложений;

- обеспечение возможности входа в систему с любой точки;

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

Также, по мнению экспертов, для сокращения совокупной стоимости владения ИС имеет смысл соблюдать следующие рекомендации при подборе активного сетевого оборудования:

· должна быть обеспечена возможность легкой интеграции существующей инфраструктуры сети и новейших сетевых технологий;

· системы, построенные на выбранном сетевом оборудовании, должны обеспечивать наименьшее время отклика и наибольшую производительность;

· должна быть обеспечена возможность наращивания производительности ИС в соответствии с конкретными требованиями пользователей;

· должен быть обеспечен необходимый уровень защиты информации.

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

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

В 1997 году маркетинговая фирма Gartner Group опубликовала сенсационные данные; за три года совокупные расходы на покупку и содержание тогдашнего стандартного персонального компьютера составляли 30000 долларов США. Именно тогда вошла в обиход понятие ТСО (Total Cost Ownership) -- Общая стоимость владения (ОСВ).

В настоящее время концепция ТСО разработана для большинства информационных систем (ИС), технологий и платформ, она является общепризнанной для оценки эффективности ИТ.

ТСО является ключевым количественным показателем ИТ и ИС, так как позволяет оценивать совокупные затраты на ИТ, анализировать их и соотвественно управлять ИТ-затратами (ИТ-бюджетом) для достижения наилучшей отдачи от ИТ.

Оценка ТСО применяется как для «наведения порядка», так и для рассмотрения проектов. ТСО является одним из важнейших критериев при выборе лучшего проекта. Однако при принятии проекта необходимо учитывать также и другие качественные и количественные показатели: технические, технологические, управленческие, кадровые, финансовые. Не всегда наименьшее ТСО идет на пользу проекту.

Ключевым моментом является сравнение ТСО данного IT-проекта (например, ТСО в пересчете на одного пользователя системы) с ТСО других компаний аналогичного профиля. Сравнение происходит как правило со средними показателями по отрасли (аналогичным компаниям) и с «лучшими в группе». Средние и лучшие показатели рассчитываются и отслеживаются экспертами Gartner Group по многим предприятиям различных отраслей.

Определение ТСО важно при определении стоимости контрактов (особенно долгосрочных) аутсорсинга, лизинга и сервиса, при обосновании затрат на существующие ИТ или будущие проекты, в борьбе за ИТ-бюджет, при доказательстве эффективности работы ИТ-подразделений, для обоснования сокращения расходов на имеющиеся ИТ. На ТСО оказывает влияние качество подготовки, опыт и знания персонала, как пользователей, так и разработчиков. Постоянное отслеживание ТСО стало текущей работой в большинстве крупных компаний, которые используют ИТ-технологии. Реализуются целевые корпоративные программы по оптимизации ТСО.

Методика Gartner Group

В программе исследований Gartner Group рассматриваются конкретные рекомендации по улучшению ТСО в зависимости от структуры ИС, типов платформ, операционных систем и т.д.

Архитектура ТСО и модели расчетов были разработаны и усовершенствованы экспертами Gartner Group на протяжении нескольких лет. Эти модели заложены в основу программного продукта ТСО «Менеджер», который облегчает работы по определению и управлению ТСО в крупных компаниях.

В основу модели ТСО положены две категории расходов: прямые (бюджетные) и косвенные. Источниками покрытия этих расходов служат бюджеты соответствующих подразделений компании (если существует многоуровневая система бюджетов).

Прямые расходы включают в себя следующие группы затрат:

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

2. Проектирование системы. Затраты те же, что и в предыдущем случае.

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

4. Доставка. Транспортные расходы по доставке приобретенных компонент к месту установки.

5. Установка системы. Включает стоимость сопутствующего ПО и оплату труда. Если установка привела к простою действующей системы или к временной потере производительности труда пользователей, эти расходы также учитываются.

6. Разработка или покупка прикладного программного обеспечения.

7. Обучение пользователей работе в новой системе. Сюда входит оплата сверхурочной занятости пользователей, стоимость учебных курсов, оплата тьюторов.

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

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

Косвенные расходы:

1. Обучение ИТ-персонала.

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

3. Управление системами. Разрешение проблем, управление изменениями, контроль производительности и др.

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

5. Затраты на лицензии

6. Затраты на обновление (контракт на обновление)

7. Поддержка пользователей: тренинги, «справочный стол» (системы поддержки пользователей в сети), стоимость мер по разрешению проблем, включая приглашение сторонних специалистов, контракт на обслуживание и др.

8. Обеспечение безопасности (физической, информационной и т.д.)

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

10. Другие факторы, не попавшие ни в одну из статей расходов и зависящие от конкретной ситуации.

Какие данные нужны для расчета ТСО?

В соответствии с методикой Gartner Group необходимо собрать следующую информацию:

- о бюджете предприятия (валовый доход, прибыль и т.п.);

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

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

- данные о платежах за услуги (каналы связи аренда оборудования и т.п.);

- данные об управлении информационной инфраструктурой (корпоративной сетью, информационными системами, хранением данных, эксплуатацией);

- данные о разработке ПО (создание, тестирование, документирование, адаптация и доработка);

- данные о действиях конечного пользователя влияющих на ТСО.

Более подробно можно становиться на определении стоимости «человеческого фактора» в ТСО. Методика Gartner Group учитывает следующие составные части этого вклада:

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

- время, затрачиваемое пользователем на самообразование взаимопомощь вместо обращения в службу поддержки;

- время, затрачиваемое пользователями в связи с неоптимальными приемами работы;

- время, затрачиваемое пользователями на праздное время провождение и использование компьютера в личных целях;

- расход времени, связанный с подключением переносных компьютеров (подключение к сети, инсталляция ПО, перенос данных и т.п.);

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

- расход времени на запланированные простои (модернизация оборудования, сети, обновление ПО);

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

Согласно результатам различных исследований, при оснащении предприятия компьютерной техникой ее стоимость составляет, в т.ч. и в России, от 20% до 50% общих издержек связанных с эксплуатацией оборудования. Остальное приходится на косвенные вопросы -- ремонт и модернизацию, поддержку и обучение пользователей, установку и обновление программного обеспечения, всевозможные сетевые сервисы и другие мелочи, требующие со временем в немалые суммы.

Оценка общей стоимости владения

ОСВ включает:

· стоимость компьютеров и программного обеспечения;

· техническое обслуживание программно-аппаратных комплексов;

· затраты на обучение и переобучение сотрудников;

· затраты на установку новых версий ПО;

· стоимость потребляемой электроэнергии;

· зарплата сотрудников IT-департаментов;

· оплата сотрудникам вынужденного безделья во время простоя компьютеров;

· «товарищеская» помощь пользователей друг другу при возникновении трудностей;

· потери рабочего времени при самостоятельном устранении мелких неполадок.

В последнее время для расчета ОСВ добавлены коэффициенты, учитывающие:

- конфигурацию сети;

- однородность/неоднородность серверных, сетевых и клиентских платформ;

- различное энергопотребление рабочих станций и экономичных «блокнотных» ПК;

- квалификацию пользователя;

- сложность вычислительной среды, в которой ведется работа;

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

- организация работы информационных технологий;

12. Защита информации

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

Под конфиденциальностью (confidentiality) мы понимаем свойство компьютерной системы, благодаря которому доступ к информации в ней ограничен кругом доверенных лиц. Целостность (integrity) -- это характеристика, указывающая на то, что изменения могут быть внесены в систему только авторизованными лицами или процессами. Другими словами, незаконные изменения в защищенной компьютерной системе должны обнаруживаться и исправляться. Основные части компьютерной системы -- это аппаратура, программы и данные.

Другой способ взглянуть на защиту в компьютерных системах -- считать, что мы стараемся защитить службы и данные от угроз защите (security threats). Мы выделяем четыре типа угроз защите:

- перехват (interception);

- прерывание (interruption);

- модификация (modification);

- подделка (fabrication).

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

Примером прерывания может служить повреждение или потеря файла. Обычно прерывание связывают с такой ситуацией, когда службы или данные становятся недоступными, уничтожаются, их невозможно использовать и т. п. В этом смысле атаки типа «отказ в обслуживании» (denial of service), при которых кто-то злонамеренно старается сделать определенную службу недоступной для других, -- это угроза защите, классифицируемая как прерывание.

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

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

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

Просто констатировать, что система должна быть в состоянии противостоять всевозможным угрозам защите -- это не метод построения защищенных систем. Прежде всего, следует описать требования к защите, то есть правила защиты. Правила защиты (security policy) точно описывают разрешенные и запрещенные действия для системных сущностей. В понятие «системные сущности» входят пользователи, службы, данные, машины и т. п. После составления правил защиты можно сосредоточиться на механизмах защиты (security mechanisms), посредством которых реализуются эти правила. Наиболее важные из них:

- шифрование (encryption);

- аутентификация (authentication);

- авторизация (authorization);

- аудит (auditing).

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

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

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

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

Архитектура защиты Globus

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

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

- Среда состоит из множества административных доменов.

- Локальные операции (то есть операции, протекающие в пределах одного домена) обеспечиваются исключительно локальными мерами защиты.

- Глобальные операции (то есть операции, в которые включается несколько доменов) требуют инициатора, известного во всех вовлеченных в операцию доменах.

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

- Глобальная аутентификация стоит выше локальной.

- Контроль доступа к ресурсам относится к компетенции локальной идентификации.

- Пользователи могут делегировать свои права процессам.

- Группа процессов в одном домене может использовать свои идентификаторы совместно.

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

Предполагается, что локальные правила не изменятся только из-за того, что система входит в Globus. Глобальные правила Globus, кроме того, не изменяют действия локальных правил защиты. Соответственно, глобальная защита в Globus ограничена лишь операциями, в которые вовлечены несколько доменов.

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

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