Функции современного департамента автоматизации предприятия.
Люди + процессы + технологии
Структура верхнего уровня:
Любой пользователь должен иметь следующие возможности: - знать «права и обязанности пользователя в сфере ИТ» - обратиться к службе поддержки любым удобным для него способом; - получить информацию о гарантированном времени получения ответа; - проверить статус запроса и узнать, кто занимается решением его вопроса; - пожаловаться на несоблюдение «прав пользователя». Задачи эти крайне непросты и решить их под силу только очень четко работающему механизму, а схему построения подобного механизма можно изобразить следующим образом. Структурная модель поддержки в сфере ИТ:
В настоящее время как никогда важно иметь «идеальный» ИТ-департамент, который будет готов отвечать запросам бизнеса, а в чем-то и опережать их.
20. Понятие CIO-менеджмента.Понятие CIO-менеджмент (информационный менеджмент) как самостоятельное появилось в экономической информатике совсем недавно – в конце 70-х гг., когда возникла необходимость повышения эффективности при принятии ответственных решений в сфере информатизации. CIO-менеджмент– это специальная область менеджмента, выделившаяся как самостоятельное направление в последние годы и все более приобретающая специфические особенности. Сфера CIO-менеджмента – совокупность всех задач управления на всех этапах жизненного цикла предприятия, включающая все действия и операции, связанные как с информацией во всех ее формах и состояниях, так и с предприятием в целом на основе данной информации. CIO–менеджмент представляет собой круг задач управления, производственного и технологического характера, решение которых обеспечивает достижение целей организации в основной ее деятельности за счет эффективного согласованного управления как элементами, процессами и ресурсами собственно информационной системы, так и другими элементами, процессами и ресурсами предприятия. Поле приложения CIO-менеджмента – все этапы жизненного цикла информационной системы (создание – внедрение – поддержка). Задачи CIO-менеджмента – управление информационной системой (ИС) на всех этапах ее жизненного цикла, ее стратегическое развитие, маркетинг. CIO-менеджмент является актуальным видом деятельности для любой фирмы – и производителя, и потребителя ИС.
21. Структура службы автоматизации предприятия.Большинство компаний имеют иерархическую структуру. Они состоят из подразделений, объединяющих группы сотрудников. Существуют разные принципы формирования подразделений. Процессы и организационные подразделения (пример):
В процессах, в которых участвует несколько подразделений, контроль качества услуг осуществляется путем мониторинга определенных аспектов качества, например таких, как доступность, мощность ИТ-средств (пропускная способность), стоимость и стабильность. Затем ИТ-организация сопоставляет результаты мониторинга качества с потребностями заказчика. Структура таких процессов гарантирует получение качественной информации о предоставлении услуг, так, чтобы можно было совершенствовать контроль и планирование услуг.
22. Функциональные обязанности ИТ-менеджеров всех уровней.ИТ-менеджер (Information Technology Manager) руководит ИТ -отделом предприятия, который занимается внедрением информационной системы, позволяющей оценивать, контролировать и принимать решения в отношении состояния предприятия. Задачей ИТ-менеджера является выбор необходимых предприятию средств автоматизации, с минимизацией затрат времени и ресурсов на их освоение, настройку и внедрение. В частности, он отвечает за автоматизацию таких областей, как управление сетевым оборудованием, серверами и корпоративными приложениями, хранением и безопасностью данных, управлением парком персональных компьютеров и службой поддержки. ИТ-менеджер несет ответственность за: - ненадлежащее исполнение или неисполнение своих должностных обязанностей, предусмотренных настоящей должностной инструкцией, — в пределах, установленных действующим трудовым законодательством РБ; - правонарушения, совершенные в процессе своей деятельности, — в пределах, установленных действующим административным, уголовным и гражданским законодательством РБ; - причинение материального ущерба предприятию — в пределах, установленных действующим трудовым и гражданским законодательством РБ.
23. Ответственность менеджеров в области ИТ.Для менеджера существуют три базовых решения: - ничего не делать с информационной системой; - модифицировать существующую информационную систему; - создавать новую информационную систему. Ответственность руководителя в части информационной системы организации состоит: - Понимание своего бизнеса и места в нем своей организации через информационные потребности; - Понимание возможностей современных автоматизированных и неавтоматизированных информационных систем и технологий; - Умение определить стратегию развития информационных систем; - Умение работать в современной информационной среде.
24. Идеологические принципы построения и использования эффективной информационной системы.Этапы проектирования ИС:
Разработка технического задания завершает пред проектную стадию создания ИС. Техническое задание является основным исходным документом, выдаваемым заказчиком и регламентирующим требования к разрабатываемой системе. Техническое задание устанавливает: - назначение и цели создания ИС; - совокупность технических требований, включая требования к эволюции системы; - показатели качества и временные характеристики решения задач и представления информации в системе; - требования к стандартизации и унификации; - технико-экономические и специальные требования к системе; - стадии разработки проектной документации; - порядок испытаний и приемки ЭИС и предварительную оценку экономической эффективности. На этапе технического проектирования создается собственно проект ИС, при этом формулируются и обосновываются все технические решения по ее созданию. В процессе рабочего проектирования создается комплекс рабочей документации, обеспечивающий практическое функционирование ИС. Процесс разработки и внедрения делится на очереди, а внутри очередей – на этапы или, наоборот, сначала на этапы, а внутри этапов – на очереди. Одновременно с разработкой рабочего проекта проводятся подготовительные мероприятия по созданию нормативно-справочной базы и обучению сотрудников аппарата управления. Постановка экономической задачи позволят более качественно выполнить последующие этапы проектирования информационных технологий для экономических задач, заключающиеся в разработке технического задания, техно-рабочего проекта и дальнейшем внедрении их в промышленную эксплуатацию.
25. Современные стандарты и модели диагностики функционирования ИС (модель СОСОМО).При планировании программного проекта надо оценить людские ресурсы (в чел. месяцах), продолжительность (в календарных днях), стоимость (в денежных единицах). Обычно исходят из прошлого опыта. Но если у нас новый проект, то возникает проблема предварительной оценки. В этом случае нельзя обойтись без специальных методик, позволяющих предварительно оценить затраты на планируемый проект. Так как средства на него потребуются сейчас, не в самом конце работы, когда уже будет завершен проект. А средства на проект или же сам договор на его разработку заключается до начала работы над продуктом. Так же следует учитывать неопределенность, которая бывает при создании программного продукта. Это должно помочь понять – стоит ли начинать проект или нет. COCOMO. В конце 70-х годов Барри Боэмом (Barry Boehm) была разработана модель оценивания объемов работ при разработке информационных систем, и получила название конструктивная модель стоимости (Constructive Cost Model – COCOMO). На сегодняшний день данная модель оценки трудоёмкости разработки программного обеспечения является наиболее известной среди множества подобных моделей. Она основана на анализе ряда проектов, реализованных по заказу Министерства обороны США. В общих чертах она с одной стороны определяет соответствие между размером системы в тысячах условных строк кода и «классом» проекта, а с другой трудоемкость разработки системы. -Базовый уровень рассчитывает трудоемкость и стоимость разработки как функцию от размера программы. Размер выражается в оценочных тысячах строк кода (KLOC – kilo lines of code). COCOMO применим к трем классам проектов разработки ПО: 1)Органический – маленькие команды с хорошим опытом работы и не жесткими требованиями к разработке. 2)Полуразделенный вид – средние по размеру команды со смешанным опытом разработки и со смешанными требованиями (как жесткими, так и нет). 3)Встроенный вид – разрабатываются с учетом множества жестких ограничений (по аппаратному, программному, операционному обеспечению и т.д.).
26. Современные стандарты и модели диагностики функционирования ИС (стандарт ISO).ISO 9000 — серия международных стандартов, описывающих требования к системе менеджмента качества организаций и предприятий. Серия стандартов ISO 9000 разработана Техническим комитетом ТК 176 Международной Организации по Стандартизации (ISO, International Organization for Standardization). В основе стандартов лежат идеи и положения теории всеобщего менеджмента качества (TQM). Серия стандартов ISO 9000 неоднократно пересматривалась. 1 версия была подготовлена в 1987 году. 2 версия была выпущена в 1994 году и представляла собой уточненную версию 1987. 3 версия была разработана в 2000 году. Версия 1994 года была радикально пере-смотрена. 4 версия стандарта вышла разобщенно – в 2005 году был выпущен стандарт ISO 9000-2005, в 2008 и 2009 годах были опубликованы стандарты ISO 9001 и 9004. Несмотря на ожидавшийся полный пересмотр версии 2000 года, ТК176 решил ограничиться "косметическими" правками – исправлением неточностей и разночтений. Причинами отказа от существенных изменений и задержки с выпуском новой версии бы-ли названы желание продлить срок действия существующих сертификатов у организаций (т.е. сохранить статус-кво в сертификационном бизнесе). Выход 5 версии стандартов планируется на 2012 год. Основополагающим стандартом серии стандартов качества является документ ISO 9000 "Стандарты на управление качеством и обеспечение качества. Руководящие положения по выбору и применению". Он определяет основные принципы политики руководства организаций в области обеспечения качества, описывает три возможных модели управления, устанавливает и разъясняет взаимосвязь между различными понятиями в области качества. Стандарт устанавливает новое для экономических процессов понятие "степень подтверждения", определяющее представление потребителю (заказчику) доказательств того, что система управления качеством и продукция изготовителя (поставщика) соответствует установленным в договорах техническим требованиям. В стандарте ISO 9004 "Система качества. Элементы системы управления качеством. Руководящие положения" рассматриваются 20 элементов системы управления качеством на предприятии и их применение. На основе рекомендаций этого стандарта руководитель предприятия может выбрать соответствующие элементы управления, отвечающие специфике организации. Используя рекомендации стандарта при проектировании системы управления качеством можно сократить затраты и одновременно, за счет применения уже апробированного опыта, повысить экономический эффект от проектируемой системы. Три модели обеспечения качества, входящие в состав стандартов серии ISO 9000, отражают различные виды (сочетания) производственных этапов предприятия, которые могут быть сертифицированы. Они позволяют сделать обоснованный выбор заказчику и поставщику продукции, а также корректно зафиксировать взаимные обязательства в договоре (контракте) на разработку, поставку или испытание продукции. Первая модель – стандарт ISO 9001 "Система качества. Модель обеспечения качества на стадиях разработки (проектирования, производства, монтажа и обслуживания)". Он используется тогда, когда изготовитель (поставщик) должен обеспечить соответствие продукции установленным требованиям на всех стадиях жизненного цикла продукции – от проектирования до обслуживания. Область организационного применения – договор (контракт) на поставку, включающий проведение опытно-конструкторских работ. Требования к продукции выражаются в основном с позиций эксплуатационных характеристик. Данная первая модель качества содержит наиболее полный набор требований при строгом соблюдении всех элементов управления качеством. Вторая модель – стандарт ISO 9002 "Система качества. Модель обеспечения качества на стадиях производства и монтажа". Стандарт применяется в условиях, когда требования к продукции устанавливаются с точки зрения уже разработанного проекта. В этих случаях необходимо подтвердить возможности изготовителя (поставщика) в части производства и монтажа продукции. Хотя в договоре (контракте) рекомендуется использовать полный набор требований, строгость соблюдения некоторых из элементов управления качеством может быть ослаблена. Третья модель – стандарт ISO 9003 "Система качества. Модель обеспечения качества на стадии контроля и испытания готовой продукции". Эта модель устанавливает возможности и обязанности изготовителя (поставщика) в части контроля и испытания поставляемой продукции. Третья модель качества может содержать полный набор требований или только часть наиболее важных элементов.
27. Современные стандарты и модели диагностики функционирования ИС (модель CMM).Capability Maturity Model – модель зрелости процессов создания ПО: эволюционная модель развития способности компании разрабатывать программное обеспечение. Изначально CMM разрабатывалась и развивалась как методика, позволяющая крупным правительственным организациям США выбирать наилучших поставщиков ПО. Для этого предполагалось создать исчерпывающее описание способов оценки процессов разработки ПО и методики их дальнейшего усовершенствования. В итоге авторы смогли добиться такой степени подробности и детализации, что стандарт оказался пригодным и для обычных компаний-разработчиков, желающих качественно улучшить существующие процессы разработки, привести их к определенным стандартам. Ключевым понятием стандарта является зрелость организации. Незрелой считается организация, в которой процесс разработки программного обеспечения зависит только от конкретных исполнителей и менеджеров, и решения зачастую просто импровизируются "на ходу" – то что на современном языке называется творческим подходом, или искусством.. В этом случае велика вероятность превышения бюджета или заваливания сроков сдачи проекта, и потому менеджеры и разработчики вынуждены заниматься только раз-решением ближайших проблем, становясь, тем самым, заложниками собственного программного продукта. С другой стороны, в зрелой организации имеются четко определенные процедуры создания программных продуктов и управления проектами. Эти процедуры по мере необходимости уточняются и совершенствуются в пилотных проектах или с помощью анализа стоимость/прибыль. Оценки времени и стоимости выполнения работ основываются на накопленном опыте и достаточно точны. Наконец, в компании существуют стандарты на процессы разработки, тестирования и внедрения ПО, правила оформления конечного программного кода, компонент, интерфейсов и т.д. Все это составляет инфраструктуру и корпоративную культуру, поддерживающую процесс разработки программного обеспечения, когда все стандартизовано. CMM определяет пять уровней зрелости организаций. В результате аттестации компании присваивается определенный уровень, который в дальнейшем может повышаться или понижаться. Здесь хочется отметить, что каждый следующий уровень включает в себя все ключевые характеристики предыдущих. Начальный уровень (initial level) описан в стандарте в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию. Повторяемый уровень (repeatable level). Для его внедрения на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам) и существует специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень. Определенный уровень (defined level). Он характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и процесс не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях. Управляемый уровень (managed level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях. Оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например с помощью создания и повторного использования компонент. Сертификационная оценка соответствия всех ключевых областей проводится по 10-балльной шкале. Для успешной квалификации данной ключевой области необходимо набрать не менее 6 баллов. Оценка ключевой области производится по следующим показателям: Заинтересованность руководства в данной области (планируется ли практическое внедрение данной ключевой области, существует ли понимание у руководства необходимости данной области и т.д.). Насколько широко данная область применяется в организации (например, оценке в 4 балла соответствует фрагментарное применение). Успешность использования данной области на практике (например, оценке в 0 бал-лов соответствует полное отсутствие какого-либо эффекта, а оценка в 8 баллов выставляется при наличии систематического и измеримого положительного результата практически во всей организации).
28. Современные стандарты и модели диагностики функционирования ИС (библиотека ITIL).ITIL — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. В семи томах библиотеки описан весь набор процессов, необходимых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей. Использованный в библиотеке процессный подход полностью соответствует стандартам серии ISO 9000 (ГОСТ Р ИСО 9000). Процессный подход акцентирует внимание предприятия на достижении поставленных целей, анализе ключевых показателей эффективности (KPI), а также на ресурсах, затраченных на достижение этих целей. Преимущества библиотеки ITIL для заказчиков/пользователей: - предоставление ИТ-услуг становится более ориентированным на заказчика, соглашения о качестве услуг способствуют улучшению взаимоотношений; - услуги описываются лучше, на языке заказчика и с требуемой детализацией; - лучше контролируются качество и стоимость услуг; - улучшается взаимосвязь компании с ИТ-организацией за счет определения точек контактов. Преимущества библиотеки ITIL для ИТ-организаций: - становится четко понятна структура ИТ-департамента, его организация становится более рациональной и более ориентированной на корпоративные цели; - руководство организацией становится более целенаправленным, облегчается Управление Изменениями; - эффективная структура процессов создает основу для эффективного аутсорсинга элементов ИТ-услуг; - следование передовому опыту ITIL способствует изменению корпоративной культуры в направлении осознания, что задачей ИТ-департамента является предоставление услуг, и поддерживает внедрение системы обеспечения качества на основе стандартов серии ISO-9000; - библиотека ITIL предоставляет единую "систему координат" и понятий для взаимодействия как в компании, так и с поставщиками, необходимую при разработке и стандартизации корпоративных процедур. Возможные проблемы при работе с ITIL: - переход на принципы ITIL может занять продолжительное время, потребовать значительных усилий и изменений в корпоративной культуре. Чересчур амбициозные планы при переходе на ITIL могут привести к разочарованию, и поставленные цели не будут достигнуты; - если совершенствование структуры процессов становится самоцелью, может пострадать качество услуг. В этом случае процедуры становятся бюрократической преградой, которую сотрудники стараются по возможности избегать; - улучшения не достигаются при недостатке понимания, что должны обеспечивать процессы (в чем их цель), что является критериями оценки эффективности процессов и как осуществлять их контроль; - улучшения в предоставлении услуг и снижении стоимости недостаточно видны; - успешная реализация требует вовлечения и наличие обязательств со стороны руководства и приверженности сотрудников на всех организационных уровнях. Предоставление права разработки структуры процессов специализированному подразделению может привести к его изоляции, в результате чего определенные им направления деятельности не будет приняты другими подразделениями; - при недостаточных инвестициях в инструментальные средства (программное обеспечение и др.) процессы не будут работать должным образом и сервис не улучшится. Могут потребоваться дополнительные ресурсы и персонал, если организация уже пере-гружена текущей рутинной работой. Эти возможные проблемы, конечно, могут быть решены. Библиотека ITIL развивалась с целью достижения преимуществ для ИТ-организации и компании в целом. Многие из лучших практических предложений направлены на предотвращение таких проблем или их решение в случае возникновения.
29. Модели уровней зрелости предприятия (модель СММ).Сервисный подход к управлению ИТ-службой требует определенной зрелости как для самой ИТ-службы, так и для бизнес-заказчиков. Уровень зрелости бизнес-процессов предприятия можно оценить на основе модели зрелости процесса разработки ПО (Capability Maturity Model – СММ) Института программ-ной инженерии при американском университете Карнеги-Меллон (Software Engineering In-stitute, SEI), которая была разработана в 1991г. С течением времени было выпущено целое семейство моделей: SW-CMM – для программных продуктов, SE-CMM – для системной инженерии, Acquisition CMM – для закупок, People CMM – для управления людскими ресурсами, ICMM -для интеграции продуктов. В 2002 году SEI опубликовал новую модель CMMI (Capability Maturity Model Integration), объединяющую ранее выпущенные модели и учитывающую требования международных стандартов. Базовым понятием модели CMM/СММI считается зрелость компании. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Результатом является высокий риск превышения бюджета или срыва сроков окончания проекта. В зрелой компании работают ясные процедуры управления проектами и построения программных продуктов. По мере необходимости эти процедуры уточняются и развиваются. Оценки длительности и затрат разработки точны, основываются на накопленном опыте. Кроме того, в компании имеются и действуют корпоративные стандарты на процессы взаимодействия с заказчиком, процессы анализа, проектирования, программирования, тестирования и внедрения программных продуктов. Все это создает среду, обеспечивающую качественную разработку программного обеспечения. В модели CMM/СММI определены пять уровней зрелости предприятий: - начальный; - повторяемый; - определенный; - управляемый; - оптимизирующий. Начальный уровень (уровень 1) означает, что процесс на предприятии не формализован, отсутствует четкое планирование и контроль. Результаты деятельности предприятия во многом случайны и сильно зависят от личных качеств отдельных сотрудников. Повторяемый уровень (уровень 2) предполагает внедрение формальных процедур для выполнения основных элементов процесса разработки ПО. Результаты выполнения процесса соответствуют заданным требованиям и стандартам. Основное отличие от уровня 1 состоит в том, что выполнение процесса планируется и контролируется. Применяемые средства планирования и управления дают возможность повторения ранее достигнутых успехов. Определенный уровень (уровень 3) требует, чтобы все элементы процесса были определены, стандартизованы и задокументированы. Основное отличие от уровня 2 заключается в том, что элементы процесса уровня 3 планируются и управляются на основе единого стандарта предприятия. Качество разрабатываемого ПО уже не зависит от способностей отдельных личностей. Управляемый уровень (уровень 4) на предприятии принимаются количественные показатели качества как программных продуктов, так и процесса. Это обеспечивает более точное планирование проекта и контроль качества его результатов. Основное отличие от уровня 3 состоит в более объективной, количественной оценке продукта и процесса. Оптимизирующий уровень (уровень 5) подразумевает, что главной задачей компании становится постоянное улучшение и повышение эффективности существующих процессов, ввод новых технологий. Основное отличие от уровня 4 заключается в том, что технология создания и сопровождения программных продуктов планомерно и последовательно совершенствуется. Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней.
30. Модели уровней зрелости предприятия (модель компании Gartner).По аналогии с понятием "уровень зрелости предприятия" используется понятие "уровень зрелости ИТ-инфраструктуры". Компания Gartner предлагает для оценки зрелости ИТ-службы использовать пять уровней: - хаотичный; - реактивный; - проактивный; - сервис; - польза. Хаотичный уровень характеризуется множественными службами поддержки, неразвитой службой эксплуатации. При реактивном уровне зрелости проводится отслеживание событий, имеется единая консоль и служба поддержки, осуществляется управление топологией сети, выполняется резервное копирование и инвентаризация; Проактивный уровень предусматривает управление производительностью, изменениями, проблемами, конфигурациями, доступностью. При этом должна обеспечиваться автоматизация управления ИТ-службой и планирование заданий; Уровень зрелости сервис обеспечивает планирование нагрузок и емкостей, управление уровнями обслуживания; Уровень зрелости ИТ-службы польза предполагает обеспечение качества предоставления ИТ-сервисов посредством использования бизнес-метрик – совокупности традиционных и нетрадиционных бизнес-показателей, которые рассматриваются в качестве принципиально важных для достижения компанией планируемого результата.
31. Модели уровней зрелости предприятия (модель компании IBM).Эффективность информационных систем и их ИТ-служб может по разному оцениваться для различных предприятий. Данное обстоятельство влияет на подходы к повышению эффективности деятельности ИТ-служб. Компания IBM сформировала четыре профиля предприятий для оптимизации ИТ-инфраструктуры: - commodity (товар); - utility (ресурс); - partner (партнер); - enabler (поддержка). В профиле commodity предприятие рассматривает ИТ-сервисы как свои основные инвестиции для автоматизации фундаментальных административных функций с минимальными расходами. При оптимизации ИТ-инфраструктуры в организациях с таким профилем основное внимание уделяется сокращению расходов. Для профиля utility компании, изначально сфокусированные на расходах, но признающие важность построения отношений с клиентами. Для этих предприятий оптимизация ИТ-инфраструктуры служит средством исполнения соглашений об уровне сервиса, сокращения времени реагирования, готовности и других параметров, связанных с обслуживанием клиентов. Профиль partner предполагает рассмотрение ИТ-инфраструктуры предприятия с точки зрения влияния на бизнес. Хотя сокращение расходов всегда актуально, основное внимание уделяется получению экономического эффекта от инвестиций в информационные технологии. В этих ситуациях бизнес-подразделения вместе с ИТ-службой работают над улучшением общего качества ИТ-сервиса и достижением конечных целей деятельности предприятия. В компаниях данного профиля enabler ИТ-инфраструктура служит важным элементом стратегии развития бизнеса. ИТ-инициативы в них выступают основной движущей силой развития бизнеса и рассматриваются как необходимое условие конкурентоспособности.
32. Модели уровней зрелости предприятия (модель компании Microsoft).В методологии компании Microsoft по оптимизации ИТ-инфраструктуры выделяют уровни зрелости ИТ-инфраструктуры предприятий. Модель зрелости ИТ-инфраструктуры, разработанная Microsoft, включает четыре уровня: - базовый; - стандартизированный; - рационализированный; - динамический. Базовый уровень зрелости ИТ-инфраструктуры характеризуется наличием большого количества процессов, выполняемых вручную, минимальной централизацией управления, отсутствием стандартов и политик безопасности, резервного копирования, управления образами систем. Руководство предприятия и ИС-службы слабо ориентируется в возможностях существующей ИТ-инфраструктуры и её потенциальных возможностях по повышению эффективности бизнеса. При этом расходы на управление ИТ-инфраструктурой высоки, так же высоки риски обеспечения качества предоставления ИТ-сервисов. Предприятия с базовым уровнем зрелости ИТ-инфраструктуры могут повысить эффективность бизнеса при переходе на стандартизированный уровень, за счет уменьшения расходов путем реализации следующих направлений: - разработки стандартов и политик, а также стратегии их применения; - снижения рисков, связанных с безопасностью, за счет создания эшелонированной обороны; - автоматизации многих ручных и длительно выполняемых операций; - внедрения передового опыта. Стандартизированный уровень зрелости ИТ-инфраструктуры предполагает введение точек управления на базе стандартов и политик администрирования настольных компьютеров и серверов, определение правил подключения машин к сети, управление ресурсами на основе Active Directory, формирование политик безопасности и управления доступом. Предприятия с ИТ-инфраструктурой данного уровня зрелости достаточно эффективно могут управлять инцидентами, но упреждающие действия по разрешению проблем ещё не проводятся. Процессы управления изменениями разрешаются частично и осуществляется первоначальное формирование базы данных позиций конфигурации. Повышение эффективности управления ИС службой предприятия возможно путем расширения уровня контроля над инфраструктурой, а также политикой безопасности для упреждающего реагирования на различные ситуации – от изменения рыночной конъюнктуры до стихийных бедствий. На рационализированном уровне зрелости ИТ-инфраструктуры предприятия затраты на управление настольными компьютерами, серверами и коммутационным оборудованием сетей сводятся к минимуму, а процессы поддержки и предоставления ИТ-сервисов начинают играть важную роль в поддержке и расширении бизнеса. При обеспечении информационной безопасности основное внимание уделяется профилактическим мерам, и на любые угрозы безопасности предприятие реагирует быстро и предсказуемо. На предприятии применяется полностью автоматизированное развертывание, с минимальным участием операторов. Количество образов программных систем (images) минимально, и процесс управления настольными компьютерами минимизирован. ИТ-служба поддерживает базу данных позиций конфигурации в исчерпывающей информацией. Динамический уровень зрелости ИТ-инфраструктуры предприятия предполагает понимание стратегической ценности для эффективного ведения бизнеса и получения конкурентных преимуществ. Данный уровень предполагает, что все расходы ИТ-службы прозрачны и находятся под полным контролем, пользователям доступны необходимые в их работе данные, организована эффективная совместная работа на уровне как сотрудников, так и отделов, а мобильные пользователи получают практически тот же уровень обслуживания, что и в офисах. Процессы поддержки и предоставления ИТ-сервисов автоматизированы. Это реализуется с помощью специализированных и встроенных в систему программных средств, что позволяет управлять информационными системами в соответствии с изменяющимися требованиями бизнеса. Инвестиции в информационные технологии дают быструю и заранее просчитываемую отдачу для бизнеса. Для данного уровня зрелости ИТ-инфраструктуры предприятия характерно эффективное управление процессами поддержки и предоставления ИТ-сервисов и постоянная оптимизация уровней поддержки сервисов. Предприятия с динамическим уровнем зрелости ИТ-инфраструктуры имеют возможность внедрять новые ИТ-технологии, необходимые для поступательного развития бизнеса, выигрыш от которых значительно перевешивает дополнительные расходы.
33. Стандарты оценки производительности ИС (Тесты TPC).По мере расширения использования компьютеров при обработке транзакций в сфере бизнеса все более важной становится возможность справедливого сравнения систем между собой. С этой целью в 1988 году был создан Совет по оценке производительности обработки транзакций (TPC – Transaction Processing Performance Council), который представляет собой бесприбыльную организацию. Любая компания или организация может стать членом TPC после уплаты соответствующего взноса. На сегодня членами TPC являются практически все крупнейшие производители аппаратных платформ и программного обеспечения для автоматизации коммерческой деятельности. К настоящему времени TPC создал три тестовых пакета для обеспечения объективного сравнения различных систем обработки транзакций и планирует создать новые оценочные тесты. В компьютерной индустрии термин транзакция (transaction) может означать почти любой вид взаимодействия или обмена информацией. Однако в мире бизнеса "транзакция" имеет вполне определенный смысл: коммерческий обмен товарами, услугами или деньгами. В настоящее время практически все бизнес-транзакции выполняются с помощью компьютеров. Наиболее характерными примерами систем обработки транзакций являются системы управления учетом, системы резервирования авиабилетов и банковские системы. Таким образом, необходимость стандартов и тестовых пакетов для оценки таких систем все больше усиливается. До 1988 года отсутствовало общее согласие относительно методики оценки систем обработки транзакций. Широко использовались два тестовых пакета: Дебет/Кредит и TPI. Однако эти пакеты не позволяли осуществлять адекватную оценку систем: они не имели полных, основательных спецификаций; не давали объективных, проверяемых результатов; не содержали полного описания конфигурации системы, ее стоимости и методологии тестирования; не обеспечивали объективного, беспристрастного сравнения одной системы с другой. Чтобы решить эти проблемы, и была создана организация TPC, основной задачей которой является точное определение тестовых пакетов для оценки систем обработки транзакций и баз данных, а также для распространения объективных, проверяемых данных в промышленности. TPC публикует спецификации тестовых пакетов, которые регулируют вопросы, связанные с работой тестов. Эти спецификации гарантируют, что покупатели имеют объективные значения данных для сравнения производительности различных вычислительных систем. Хотя реализация спецификаций оценочных тестов оставлена на усмотрение индивидуальных спонсоров тестов, сами спонсоры, объявляя результаты TPC, должны представить TPC детальные отчеты, документирующие соответствие всем спецификациям. Эти отчеты, в частности, включают конфигурацию системы, методику калькуляции цены, диаграммы значений производительности и документацию, показывающую, что тест соответствует требованиям атомарности, согласованности, изолированности и долговечности (ACID – atomicity, consistency, isolation, and durability), которые гарантируют, что все транзакции из оценочного теста обрабатываются должным образом. TPC определяет и управляет форматом нескольких тестов для оценки производительности OLTP (On-Line Transaction Processing), включая тесты TPC-A, TPC-B и TPC-C. Как уже отмечалось, создание оценочного теста является ответственностью организации, выполняющей этот тест. TPC требует только, чтобы при создании оценочного теста выполнялись определенные условия. Хотя упомянутые тесты TPC не являются характерными тестами для оценки производительности баз данных, системы реляционных баз данных являются ключевыми компонентами любой системы обработки транзакций. Следует отметить, что как и любой другой тест, ни один тест TPC не может измерить производительность системы, которая применима для всех возможных сред обработки транзакций, но эти тесты действительно могут помочь пользователю справедливо сравнивать похожие системы. Однако, когда пользователь делает покупку или планирует решение о покупке, он должен понимать, что никакой тест не может заменить его конкретную прикладную задачу. (Тест TPC-A) Выпущенный в ноябре 1989 года, тест TCP-A предназначался для оценки производительности систем, работающих в среде интенсивно обновляемых баз данных, типичной для приложений интерактивной обработки данных (OLDP – on-line data processing). Такая среда характеризуется: - множеством терминальных сессий в режиме on-line; - значительным объемом ввода/вывода при работе с дисками; - умеренным временем работы системы и приложений; - целостностью транзакций. Практически при выполнении теста эмулируется типичная вычислительная среда банка, включающая сервер базы данных, терминалы и линии связи. Этот тест использует одиночные, простые транзакции, интенсивно обновляющие базу данных. Одиночная транзакция (подобная обычной операции обновления счета клиента) обеспечивает простую, повторяемую единицу работы, которая проверяет ключевые компоненты системы OLTP. Тест TPC-A определяет пропускную способность системы, измеряемую количеством транзакций в секунду (tpsA), которые система может выполнить при работе с множеством терминалов. Хотя спецификация TPC-A не определяет точное количество терминалов, компании-поставщики систем должны увеличивать или уменьшать их количество в соответствии с нормой пропускной способности. Тест TPC-A может выполняться в локальных или региональных вычислительных сетях. В этом случае его результаты определяют либо "локальную" пропускную способность(TPC-A-local Throughput), либо "региональную" пропускную способность (TPC-Awide Throughput). Очевидно, эти два тестовых показателя нельзя непосредственно сравнивать. Спецификация теста TPC-A требует, что-бы все компании полностью раскрывали детали работы своего теста, свою конфигурацию системы и ее стоимость (с учетом пятилетнего срока обслуживания). Это позволяет опре-делить нормализованную стоимость системы ($/tpsA). (Тест TPC-B) В августе 1990 года TPC одобрил TPC-B, интенсивный тест базы данных, характеризующийся следующими элементами: - значительный объем дискового ввода/вывода; - умеренное время работы системы и приложений; - целостность транзакций. PC-B измеряет пропускную способность системы в транзакциях в секунду (tpsB). Поскольку имеются существенные различия между двумя тестами TPC-A и TPC-B (в частности, в TPC-B не выполняется эмуляция терминалов и линий связи), их нельзя прямо сравнивать. На рисунке 3.2 показаны взаимоотношения между TPC-A и TPC-B. (Тест TPC-C) Тестовый пакет TPC-C моделирует прикладную задачу обработки заказов. Он моделирует достаточно сложную систему OLTP, которая должна управлять приемом заказов, управлением учетом товаров и распространением товаров и услуг. Тест TPC-C осуществляет тестирование всех основных компонентов системы: терминалов, линий связи, ЦП, дискового в/в и базы данных. TPC-C требует, чтобы выполнялись пять типов транзакций: - новый заказ, вводимый с помощью сложной экранной формы;- простое обновление базы данных, связанное с платежом;- простое обновление базы данных, связанное с поставкой;- справка о состоянии заказов; - справка по учету товаров. Среди этих пяти типов транзакций по крайней мере 43%должны составлять платежи. Транзакции, связанные со справками о состоянии заказов, состоянии поставки и учета, должны составлять по 4%. Затем измеряется скорость транзакций по новым заказам, обрабатываемых совместно со смесью других транзакций, выполняющихся в фоновом режиме. База данных TPC-C основана на модели оптового поставщика с удаленными районами и товарными складами. База данных содержит девять таблиц: товарные склады, район, покупатель, заказ, порядок заказов, новый заказ, статья счета, складские запасы и история. Обычно публикуются два результата. Один из них, tpm-C, представляет пиковую скорость выполнения транзакций (выражается в количестве транзакций в минуту). Второй результат, $/tpm-C, представляет собой нормализованную стоимость системы. Стоимость системы включает все аппаратные средства и программное обеспечение, используемые в тесте, плюс стоимость обслуживания в течение пяти лет.
34. Стандарты оценки производительности ИС (Тесты SPEC).Важность создания пакетов тестов, базирующихся на реальных прикладных программах широкого круга пользователей и обеспечивающих эффективную оценку производительности процессоров, была осознана большинством крупнейших производителей компьютерного оборудования, которые в 1988 году учредили бесприбыльную корпорацию SPEC (Standard Performance Evaluation Corporation). Основной целью этой организации является разработка и поддержка стандартизованного набора специально подобранных тестовых программ для оценки производительности новейших поколений высокопроизводительных компьютеров. Членом SPEC может стать любая организация, уплатившая вступительный взнос. Главными видами деятельности SPEC является разработка и публикация наборов тестов, предназначенных для измерения производительности компьютеров. Перед публикацией объектные коды этих наборов вместе с исходными текстами и инструментальными средствами интенсивно проверяются на предмет возможности импортирования на разные платформы. Они доступны для широкого круга пользователей за плату, покрывающую расходы на разработку и административные издержки. Специальное лицензионное соглашение регулирует вопросы выполнения тестирования и публикации результатов в соответствии с документацией на каждый тестовый набор. SPEC публикует ежеквартальный отчет о новостях SPEC и результатах тестирования: "The SPEC Newsletter", что обеспечивает централизованный источник информации для результатов тестирования на тестах SPEC. Основным результатом работы SPEC являются наборы тестов. Эти наборы разрабатываются SPEC с использованием кодов, поступающих из разных источников. SPEC работает над импортированием этих кодов на разные платформы, а также создает инструментальные средства для формирования из кодов, выбранных в качестве тестов, осмысленных рабочих нагрузок. Поэтому тесты SPEC отличаются от свободно распространяемых программ. Хотя они могут существовать под похожими или теми же самыми именами, время их выполнения в общем случае будет отличаться. В настоящее время имеется два базовых набора тестов SPEC, ориентированных на интенсивные расчеты и измеряющих производительность процессора, системы памяти, а также эффективность генерации кода компилятором. Как правило, эти тесты ориентированы на операционную систему UNIX, но они также импортированы и на другие платформы. Процент времени, расходуемого на работу операционной системы и функции ввода/вывода, в общем случае ничтожно мал. Набор тестов CINT92, измеряющий производительность процессора при обработке целых чисел, состоит из шести программ, написанных на языке Си и выбранных из различных прикладных областей: теория цепей, интерпретатор языка Лисп, разработка логических схем, упаковка текстовых файлов, электронные таблицы и компиляция программ. Набор тестов CFP92, измеряющий производительность процессора при обработке чисел с плавающей точкой, состоит из 14 программ, также выбранных из различных прикладных областей: разработка аналоговых схем, моделирование методом Монте-Карло, квантовая химия, оптика, робототехника, квантовая физика, астрофизика, прогноз погоды и другие научные и инженерные задачи. Две программы из этого набора написаны на языке Си, а остальные 12 – на Фортране. В пяти программах используется одинарная, а в остальных – двойная точность. Результаты прогона каждого индивидуального теста из этих двух наборов выражаются отношением времени выполнения одной копии теста на тестируемой машине к времени ее выполнения на эталонной машине. В качестве эталонной машины используется VAX 11/780. SPEC публикует результаты прогона каждого отдельного теста, а также две составные оценки: SPECint92 – среднее геометрическое 6 результатов индивидуальных тестов из набора CINT92 и SPECfp92 – среднее геометрическое 14 результатов индивидуальных тестов из набора CFP92. Следует отметить, что результаты тестирования на наборах CINT92 и CFT92 сильно зависят от качества применяемых оптимизирующих компиляторов. Для более точного выяснения возможностей аппаратных средств с середины 1994 года SPEC ввел две дополнительные составные оценки: SPECbase_int92 и SPECbase_fp92, которые накладывает определенные ограничения на используемые компиляторы поставщиками компьютеров при проведении испытаний. Составные оценки SPECint92 и SPECfp92 достаточно хорошо характеризуют производительность процессора и системы памяти при работе в однозадачном режиме, но они совершенно не подходят для оценки производительности многопроцессорных и однопроцессорных систем, работающих в многозадачном режиме. Для этого нужна оценка пропускной способности системы или ее емкости, показывающая количество заданий, которое система может выполнить в течение заданного интервала времени. Пропускная способность системы определяется прежде всего количеством ресурсов (числом процессоров, емкостью оперативной и кэш-памяти, пропускной способностью шины), которые система может предоставить в распоряжение пользователя в каждый момент времени. Именно такую оценку, названную SPECrate и заменившую ранее применявшуюся оценку SPECthruput89, SPEC предложила в качестве единицы измерения производительности многопроцессорных систем. При этом для измерения выбран метод "однородной нагрузки" (homo genous capaci-tymetod), заключающийся в том, что одновременно выполняются несколько копий одной и той же тестовой программы. Результаты этих тестов показывают, как много задач конкретного типа могут быть выполнены в указанное время, а их средние геометрические значения (SPECrate_int92 – на наборе тестов, измеряющих производительность целочисленных операций и SPECrate_fp92 – на наборе тестов, измеряющих производительность на операциях с плавающей точкой) наглядно отражают пропускную способность одно-процессорных и многопроцессорных конфигураций при работе в многозадачном режиме в системах коллективного пользования. В качестве тестовых программ для проведения испытаний на пропускную способность выбраны те же наборы CINT92 и CFT92. При прогоне тестового пакета делаются независимые измерения по каждому от-дельному тесту. Обычно такой параметр, как количество запускаемых копий каждого от-дельного теста, выбирается исходя из соображений оптимального использования ресурсов, что зависит от архитектурных особенностей конкретной системы. Одной из очевидных возможностей является установка этого параметра равным количеству процессоров в системе. При этом все копии отдельной тестовой программы запускаются одновременно, и фиксируется время завершения последней из всех запущенных программ. С середины 1994 года SPEC ввела две дополнительные составные оценки: SPECrate_base_int92 и SPECrate_base_fp92, которые накладывает ограничения на используемые компиляторы. Следует отметить, что SPEC объявила о полном переходе с середины 1996 года на новый (третий) комплект тестов – CINT95, CFP95. Эти тесты удовлетворяют следующим ограничениям и требованиям: - размер кода и данных должен быть достаточно большим, чтобы он гарантирован-но не размещался целиком в кэш-памяти; - время выполнения тестов должно быть увеличено с секунд до минут; - используемые фрагменты программ должны быть реалистичными; - применение усовершенствованного способа измерения времени; - реализация более удобных инструментальных средств; - стандартизация требований к компиляторам и методов вызова. Новый комплект тестов состоит из 8 целочисленных программ, написанных на языке Си и 10 программ вещественной арифметики, написанных на Фортране.
35. Стандарты оценки качества ИТ.Качество ИС связано с дефектами, заложенными на этапе проектирования и проявляющимися в процессе эксплуатации. Свойства ИС, в том числе и дефектологические, могут проявляться лишь во взаимодействии с внешней средой, включающей технические средства, персонал, информационное и программное окружение. В зависимости от целей исследования и этапов жизненного цикла ИС дефектологические свойства разделяют на дефектогенность, дефектабельность и дефектоскопичность. Дефектогенность определяется влиянием следующих факторов: - численностью разработчиков ИС, их профессиональными психофизиологическими характеристиками; - условиями и организацией процесса разработки ИС; - характеристиками инструментальных средств и комплексов ИС; - сложностью задач, решаемых ИС; - степенью агрессивности внешней среды (потенциальной возможностью внешней среды вносить преднамеренные дефекты, например воздействие вирусов). Дефектабельность характеризует наличие дефектов ИС и определяется их количеством и местонахождением. Другими факторами, влияющими на дефектабельность, являются: - структурно-конструктивные особенности ИС; - интенсивность и характеристики ошибок, приводящих к дефектам. Дефектоскопичность характеризует возможность проявления дефектов в виде отказов и сбоев в процессе отладки, испытаний или эксплуатации. На дефектоскопичность влияют: - количество, типы и характер распределения дефектов; - устойчивость ИС к проявлению дефектов; - характеристики средств контроля и диагностики дефектов; - квалификация обслуживающего персонала. Оценка качества ИС является крайне сложной задачей из-за многообразия интересов пользователей. Поэтому невозможно предложить одну универсальную меру качества и приходится использовать ряд характеристик, охватывающих весь спектр предъявляемых требований. Наиболее близки к задачам оценки качества ИС модели качества программного обеспечения, являющегося одним из важных составных частей ИС. В настоящее время используется несколько абстрактных моделей качества программного обеспечения, основанных на определениях характеристики качества, показателя качества, критерия и метрики. Критерий может быть определен как независимый атрибут ИС или процесса ее создания. С помощью такого критерия может быть измерена характеристика качества ИС на основе той или иной метрики. Совокупность нескольких критериев определяет показатель качества, формируемый исходя из требований, предъявляемых к ИС. В настоящее время наибольшее распространение получила иерархическая модель взаимосвязи компонентов качества ИС. Вначале определяются характеристики качества, в числе которых могут быть, например: - общая полезность; - исходная полезность; - удобство эксплуатации. Далее формируются показатели, к числу которых могут быть отнесены: - практичность; - целостность; - корректность; - удобство обслуживания; - оцениваемость; - гибкость; - адаптируемость; - мобильность; - возможность взаимодействия. Каждому показателю качества ставится в соответствие группа критериев. Для указанных показателей приведем возможные критерии. Надо отметить, что один и тот же критерий может характеризовать несколько показателей: - практичность — работоспособность, возможность обучения, коммуникативность, объем ввода, скорость ввода-вывода; - целостность — регулирование доступа, контроль доступа; - эффективность — эффективность использования памяти, эффективность функционирования; - корректность — трассируемость, завершенность, согласованность; - надежность — точность, устойчивость к ошибкам, согласованность, простота; - удобство обслуживания — согласованность, простоту, краткость, информативность, модульность; - оцениваемость — простота, наличие измерительных средств, информативность, модульность; - гибкость — распространяемость, общность, информатированность, модульность; - адаптируемость — общность, информативность, модульность, аппаратную независимость, программную независимость; - мобильность — информативность, модульность, аппаратную независимость, программную независимость; - возможность взаимодействия — модульность, унифицируемость процедур связи, унифицируемость данных. С помощью метрик можно дать количественную или качественную оценку качества ИС. Различают следующие виды метрических шкал для измерения критериев. Первый тип — метрики, которые используют интервальную шкалу, характеризуемую относительными величинами реально измеряемых физических показателей, напри-мер, временем наработки на отказ, вероятностью ошибки, объемом информации и других. Второй тип — метрики, которым соответствует порядковая шкала, позволяющая ранжировать характеристики путем сравнения с опорными значениями. Третий тип — метрики, которым соответствуют номинальная, или категорированная шкала, определяющая наличие рассматриваемого свойства или признака у рассматриваемого объекта без учета градаций по этому признаку. Так, например, интерфейс может быть "простым для понимания", "умеренно простым", "сложным для понимания". Развитием иерархического подхода является модель классификации критериев качества информационных систем. С помощью функциональных критериев оценивается степень выполнения ИС основных целей или задач. Конструктивные критерии предназначены для оценки компонент ИС, независящих от целевого назначения. Одним из путей обеспечения качества ИС является сертификация. В США Радио-техническая комиссия по аэронавтике в своем руководящем документе определяет процесс сертификации следующим образом: "Сертификация — процесс официально выполняемой функции системы ... путем удостоверения, что функция удовлетворяет требованиям заказчика, а также государственным нормативным документам". К сожалению, в настоящее время не существует стандартов, полностью удовлетворяющих оценке качества ИС. В западноевропейских странах имеется ряд стандартов, определяющих основы сертификации программных систем. Стандарт Великобритании (BS750) описывает структурные построения программных систем, при соблюдении которых может быть получен документ, гарантирующий качество на государственном уровне. Имеется международный аналог указанного стандарта (ISO9000) и аналог для стран — членов НАТО (AQAP1). Существующая в нашей стране система нормативно-технических документов относит программное обеспечение к "продукции производственно-технического назначения", которая рассматривается как материальный объект. Однако программное обеспечение является скорее абстрактной нематериальной сферой. Существующие ГОСТы (например, ГОСТ 28195-89. "Оценка качества программных средств. Общие положения") явно устарели и являются неполными.