Билет 29

Билет 29 Вопрос 1. Впервые термин Совокупная стоимость владения (Total Cost of Ownership – ТСО) был введен Полем Страссманом, под ТСО он понимал денежные затраты на обслуживание, модернизацию, ремонт, приобретение новых программных продуктов (ПП) для технического средства (например, компьютера), или поддержание в рабочем состоянии ПП (например, базы данных) за все предполагаемое или фактическое время его существования. Наиболее простым определением TCO информационной системы (ИС) является следующее: это затраты, связанные с приобретением, внедрением и использованием ИС. При этом необходимо рассматривать первоначальные и последующие затраты, в совокупности определяя их как единые затраты на информационную систему в процессе ее создания и эксплуатации. Любое предприятие с помощью автоматизации стремится повысить эффективность ведения своего бизнеса. Одно из главных условий достижения данной цели — «разумные» (т. е. не больше, но и не меньше) ИТ-затраты, которые точно так же, как и любые другие, требуют планирования, учета и контроля. Исходя из этого, для отечественных предприятий и ИТ-менеджеров неотъемлемыми и требующими детального рассмотрения являются вопросы, связанные с проблемой снижения совокупной стоимости владения информационной системой. ТСО первоначально разрабатывалась как средство расчета стоимости владения компьютером на Wintel-платформе и благодаря усилиям Gartner Group и Interpose эта методика стала основным инструментом для подсчета ТСО и в других областях компьютерных технологий. Например, сейчас имеются методики расчета ТСО документооборота, различных аппаратных платформ, сетей, ПО. Управление ИТ-активами - это набор взаимосвязанных процессов, нацеленных на решение вопросов физического учёта, финансового контроля и контрактных обязательств, связанных с ИТ-активами, на протяжении всего жизненного цикла. Мы выделяем три основных аспекта ITAM: физический, финансовый и контрактный. Назначение: • Оптимизация расходов (экономия) при использовании ИТ-активов.  Стратегические решения, основанные на полноте информации об ИТ-активах.  Контроль закупок.  Мониторинг использования.  Получение лучших условий при заключении контрактов.  Сопоставление счетов и контрактов.  Успешное прохождение аудитов. • Соответствие ИТ-активов требованиям бизнеса (количество, необходимая функциональность, стоимость и т.д.). • Соответствие требованиям внешних и внутренних регуляторов (законодательство, отраслевые стандарты, внутренние политики), от которых зависит непрерывность бизнеса. Наиболее часто встречающиеся задачи, которые решает ITAM: • Управление портфелем ИТ-активов • Управление закупками • Управление договорами • Управление затратами: учет затрат, отслеживание исполнения бюджета, расчет себестоимости ИТ-услуг • Управление конкурсами (тендерами) • Управление активами ПО (Software Asset Management, SAM). Существует множество мнений, что может являться ИТ-активом: • Оборудование, запчасти и расходные материалы • Программное обеспечение • ИТ-услуги • Другие нематериальные сущности (логические элементы) В основном же подразумевается, что ИТ-актив - это аппаратное и программное обеспечение. ITSM (IT Service Management, управление ИТ-услугами) — подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Управление ИТ-услугами реализуется поставщиками ИТ-услуг путём использования оптимального сочетания людей, процессов и информационных технологий[1]. Для содействия реализации подхода к управлению ИТ-услугами используется серия документов ITIL[2]. В отличие от более традиционного технологического подхода, ITSM рекомендует сосредоточиться на клиенте и его потребностях, на услугах, предоставляемых пользователю информационными технологиями, а не на самих технологиях. При этом процессная организация предоставления услуг и наличие заранее оговоренных в соглашениях об уровне услуг параметров эффективности (KPI) позволяет ИТ-отделам предоставлять качественные услуги, измерять и улучшать их качество. Важным моментом при изложении принципов ITSM является системность. При изложении каждого составного элемента ITSM (управление инцидентами, управление конфигурациями, управление безопасностью и т. д.) в обязательном порядке прослеживается его взаимосвязь и координация с остальными элементами (службами, процессами) и при этом даются необходимые практические рекомендации. ITIL не является конкретным алгоритмом или руководством к действию, но она описывает передовой опыт (best practices) и предлагает рекомендации по организации процессного подхода и управления качеством предоставления услуг. Это позволяет оторваться от особенностей данного конкретного предприятия в данной конкретной отрасли. Вместе с тем, несмотря на определённую абстрактность, ITIL всячески нацелено на практическое использование.

Вопрос 2.

Сервис-ориентированная архитектура (SOA, service-oriented architecture) – модульный подход к разработке программного обеспечения, основанный на использовании сервисов (служб) со стандартизированными интерфейсами [21]. OASIS (Организация по распространению открытых стандартов структурированной информации) определяет SOA следующим образом (OASIS Reference Model for Service Oriented Architecture V 1.0): Сервисно-ориентированная архитектура – это парадигма организации и использования распределенных информационных ресурсов таких как: приложения и данные, находящихся в сфере ответственности разных владельцев, для достижения желаемых результатов потребителем, которым может быть: конечный пользователь или другое приложение. В основе SOA лежат принципы многократного использования функциональных элементов ИТ, ликвидации дублирования функциональности в ПО, унификации типовых операционных процессов, обеспечения перевода операционной модели компании на централизованные процессы и функциональную организацию на основе промышленной платформы интеграции. Компоненты программы могут быть распределены по разным узлам сети, и предлагаются как независимые, слабо связанные, заменяемые сервисы-приложения. Программные комплексы, разработанные в соответствии с SOA, часто реализуются как набор веб-сервисов, интегрированных при помощи известных стандартных протоколов (SOAP, WSDL, и т. п.) Интерфейс компонентов SОА-программы предоставляет инкапсуляцию деталей реализации конкретного компонента (ОС, платформы, языка программирования, вендора, и т. п.) от остальных компонентов. Таким образом, SOA предоставляет гибкий и элегантный способ комбинирования и многократного использования компонентов для построения сложных распределенных программных комплексов. SOA хорошо зарекомендовала себя для построения крупных корпоративных программных приложений. Целый ряд разработчиков и интеграторов предлагают инструменты и решения на основе SOA (например, платформы IBM WebSphere, Oracle/BEA Aqualogic, Microsoft Windows Communication Foundation, SAP NetWeaver, ИВК Юпитер, TIBCO, Diasoft). Основными целями применения SOA для крупных информационных систем, уровня предприятия, и выше являются [21]: • сокращение издержек при разработке приложений, за счет упорядочивания процесса разработки; • расширение повторного использования кода; • независимость от используемых платформ, инструментов, языков разработки; • повышение масштабируемости создаваемых систем; • улучшение управляемости создаваемых систем. Принципы SOA: • архитектура, как таковая, не привязана к какой-то определенной технологии; • независимость организации системы от используемой вычислительной платформы (платформ); • независимость организации системы от применяемых языков программирования; • использование сервисов, независимых от конкретных приложений, с единообразными интерфейсами доступа к ним; • организация сервисов как слабосвязанных компонентов для построения систем. Архитектура не привязана к какой-то определенной технологии. Она может быть реализована с использованием широкого спектра технологий, включая такие технологии как REST, RPC, DCOM, CORBA или веб-сервисы. SOA может быть реализована, используя один из этих протоколов и, например, может использовать, дополнительно, механизм файловой системы, для обмена данными. Главное, что отличает SOA, это использование независимых сервисов, с четко определенными интерфейсами, которые, для выполнения своих задач, могут быть вызваны неким стандартным способом, при условии, что сервисы заранее ничего не знают о приложении, которое их вызовет, а приложение не знает, каким образом сервисы выполняют свою задачу. SOA также может рассматриваться как стиль архитектуры информационных систем, который позволяет создавать приложения, построенные путем комбинации слабосвязанных и взаимодействующих сервисов. Эти сервисы взаимодействуют на основе какого-либо строго определенного платформо-независимого и языково-независимого интерфейса (например, WSDL). Определение интерфейса скрывает языково-зависимую реализацию сервиса. Таким образом, системы, основанные на SOA, могут быть независимы от технологий разработки и платформ (таких как Java, .NET и т. д.). К примеру, сервисы, написанные на C#, работающие на платформах .Net и сервисы на Java, работающие на платформах Java EE, могут быть с одинаковым успехом вызваны общим составным приложением. Приложения, работающие на одних платформах, могут вызывать сервисы, работающие на других платформах, что облегчает повторное использование компонентов. SOA может поддерживать интеграцию и консолидацию операций в составе сложных систем, однако SOA не определяет и не предоставляет методологий или фреймворков для документирования сервисов. Языки высокого уровня, такие как BPEL, или спецификации, такие как WS-CDL и WS-Coordination, расширяют концепцию сервиса, предоставляя метод оркестрации, для объединения мелких сервисов в более обширные бизнес-сервисы, которые, в свою очередь, могут быть включены в состав технологических процессов и бизнес-процессов, реализованных в виде составных приложений или порталов.