Студопедия

КАТЕГОРИИ:

АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Зависимость сложности ilf и eif от количества det и ret




Количество RET

Количество DET

1-19 20-50 51+
1 Низкая Низкая Средняя
2-5 Низкая Средняя Высокая
6 + Средняя Высокая Высокая

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

Вопрос 12.

Анализ функциональных точек — стандартный метод измерения размера программного продукта с точки зрения пользователей системы. Метод разработан Аланом Альбрехтом (AlanAlbrecht) в середине 70-х. Метод был впервые опубликован в 1979 году. В 1986 году была сформирована Международная Ассоциация Пользователей Функциональных Точек (InternationalFunctionPointUserGroup — IFPUG), которая опубликовала несколько ревизий метода [2].

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

Вопрос 13.

При анализе методом функциональных точек надо выполнить следующую последовательность шагов :

  1. Определение типа оценки.
  2. Определение области оценки и границ продукта.
  3. Подсчет функциональных точек, связанных с данными.
  4. Подсчет функциональных точек, связанных с транзакциями.
  5. Определение суммарного количества не выровненных функциональных точек (UFP).
  6. Определение значения фактора выравнивания (FAV).
  7. Расчет количества выровненных функциональных точек (AFP).


Рисунок 37. Процедура анализа по методу функциональных точек

Подробнее на сайте: http://citforum.ru/SE/project/arkhipenkov_lectures/12.shtml

Вопрос 14.

Бизнес - архитектура предприятия(EBA-EnterpriseBusinessArchitecture) – это целевое построение организационной структуры предприятия, увязанное с его миссией, стратегией, бизнес - целями. В ходе построения бизнес - архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.

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

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

Вопрос 15.

Стандарты ITIL, CMMI, COBIT, PRINCE2, MSP, PMBOK

Стандарт ITIL

Назначение ITIL

Библиотека инфраструктуры информационных технологий (InformationTechnologyInfrastructureLibrary, ITIL) в настоящее время фактически стала международным стандартом в сфере организации и управления информационными технологиями.

ITIL включает в себя описание различных видов деятельности в сфере ИТ, таких как управление проектами, управление закупками, ИТ-сервис, и состоит из ряда практических руководств, предоставляющих информацию об эффективном и рациональном использовании различных ИТ-сервисов и предоставлении их потребителям.

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

Основные принципы ITIL

Организация деятельности ИТ-службы осуществляется с использованием процессного подхода. Задачей ИТ-службы является предоставление основному бизнесу полного набора информационных услуг.

ИТ-сервисы поставляются на основании соглашения об уровне предоставления сервисов (servicelevelagreement), которое является согласованным и утвержденным документом.

Качество предоставления ИТ-сервиса является измеряемой величиной.

Преимущества ITIL

Преимущества ITIL заключаются в следующем:

· использование передового опыта и проверенных знаний;

· направленность деятельности ИТ на решение задач бизнеса;

· использование ИТ-служб поставщиками ИТ-услуг для бизнес-подразделений;

· регламентирование деятельности ИТ соглашением об уровне услуг;

· стандартизация работы ИТ-персонала;

· направленность на обеспечение оптимального качества ИТ-услуг для потребителей;

· использование подходов менеджмента качества в управлении ИТ-сервисами;

· возможность подтверждения стоимости ИТ-сервиса на основании соглашения об уровне обслуживания.

 

Методология CMMI

 

CapabilityMaturityModelIntegration (CMMI) – Комплексная модель производительности и зрелости – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.

Любое совершенствование процессов подразумевает плавный/поэтапный процесс. В CMMI эти этапы формализованы — существует 5 уровней зрелости, каждый из которых указывает на зрелость процессов организации.

Уровень зрелости – это главный, итоговый показатель оценки по модели CMMI. Процессы первого уровня зрелости характеризуются хаотичностью, реактивностью, непредсказуемостью. Несмотря на это, очень часто организации, находящиеся на данном этапе развития, производят довольно качественные продукты. При этом, как правило, превышается бюджет и время разработки данных продуктов. Качественные продукты данных организаций производятся не за счет устойчивых и отлаженных процессов, а благодаря титаническим усилиям отдельных личностей. В случае ухода таких людей очень тяжело повторить успешные проекты. На данном этапе очень тяжело предсказать производительность процессов, протекающих в организации. На уровне 1 производственный процесс (а вместе с ним и все процессы) представляется аморфной сущностью, практически черным ящиком, представление о процессах очень ограниченное, чрезмерно много усилий тратится на выяснение статуса развития проекта и текущего хода работ. В принципе, для небольших компаний, разрабатывающих собственные проекты или небольшие проекты по заказу – это приемлемо. Но для них и не нужна никакая модель CMMI. Эта модель показывает себя во всей красе при разработке действительно больших проектов.

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

Уровень зрелости 3 – определенный уровень. В этом случае процессы определены. Установлены стандарты в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Присутствует более детальное описание всех процессов, в котором лучше раскрываются связи и зависимости, знание которых позволяет улучшить управление. На этом уровне – уровне 3 — становится видимой внутренняя сторона наших черных ящиков. Это внутренняя структура отражает способ, применения стандартного производственного процесса организации.

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

Уровень зрелости 5 – уровень постоянного улучшения (оптимизации) процессов. На данном этапе имеем точные характеристики оценки эффективности бизнес процессов, что позволяет нам постоянно и эффективно улучшать бизнес процессы путем развития существующих методов и техник и внедрения новых.

Процессные области — это то, из чего состоит вся модель. CMMI определяет 22 процессные области. Для каждой из процессных областей существует ряд целей, которые должны быть достигнуты при внедрении CMMI в данной процессной области. Некоторые цели являются уникальными — они называются специальными. Общие цели применяются к нескольким процессным областям. Цели достигаются при помощи выполнения практик; так же, как цели, практики делятся на специальные и общие.

Использование модели CMMI позволяет организации оценить эффективность процессов, установить приоритетные направления их усовершенствования, а также внедрить данные усовершенствования. Внедрение СММ/CMMI позволяет улучшить структуру и качество процессов (основные проблемы в программных разработках — это проблемы управления, а не технические проблемы), обеспечить стабильно высокое качество разработок и освоить процессы, которые могут служить основой для повышения конкурентной способности и дальнейшего развития, и расширения компании. В основе CMM/CMMI лежит понятие процесса. Принятие этой концепции помогает избежать естественной для многих организаций тенденции винить в неудачах людей. Увольнение сотрудников — не решение проблемы. За последние десятилетия произошли революционные изменения в технологии, однако проблемы успешного выполнения проекта остались. В этом аспекте технология также не решение проблемы. Ценность процесса в том, что он помогает уловить и использовать наивысшие достижения в будущих проектах. Именно на этой предпосылке и базируется CMMI. СММ/CMMI — это модели, т.е. упрощенное представление мира. Модели СММ/CMMI содержат существенные элементы процессов, обеспечивающих разные стороны деятельности, и могут быть использованы как руководство для разработки и улучшения производственных процессов. В официальных изданиях модели подчеркивается, что она не представляет собой процессы или их описание. Реальные процессы в любой организации зависят от множества факторов, включая специфику бизнеса, структуру и размер организации.

Стандарт COBIT

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

Объекты контроля информационных и смежных технологий [ControlObjectivesforInformationandrelatedTechnology (COBIT)] представляет собой комплекс средств, который содержит всю информацию, необходимую для ИТ управления и контроля. В удобной и логичной форме CobiT обеспечивает специалистов надлежащей практикой, чтобы помочь оптимизировать ИТ и с точки зрения инвестиций, и успешного достижения целей в области бизнеса.

CobiT способствует решению проблем предприятий путем:

организации ИТ в общепринятые модели процессов,

определения целей управления для анализа,

установления измеряемых связей между требованиями бизнеса и ИТ–целями,

определения привлекаемых основных ИТ-ресурсов

предоставления инструментов для управления:

целей и показателей эффективности ИТ,

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

RACI карт, чтобы уточнить функции и обязанности персонала.

CobiT ориентирован на обеспечение надлежащего управления и контроля ИТ. Он согласован с другими стандартами и оптимальной практикой и действует как интегратор различных инструктивных материалов.

Преимущества использования CobiT включают:

Улучшение согласования бизнеса и ИТ,

Взаимопонимание между всеми заинтересованными сторонами на основе общего языка,

Понимание того, что ИТ делает для управления бизнесом,

Широкое признание со стороны третьих лиц.

Методология PRINCE2

PRojects IN ControlledEnvironments 2 (PRINCE2) представляет собой структурированный метод управления проектами, одобренный правительством Великобритании в качестве стандарта управления проектами в социальной сфере. Методология PRINCE2 включает в себя подходы к менеджменту, контролю и организации проектов.

Преимущества

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

Недостатки

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

 

Методология МSP

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

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

Преимущества MSP

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

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

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

· Обеспечивает контролируемый ход программы,

· Управляет влиянием программы на организацию (обеспечение того, чтобы программа была всегда в соответствии со стратегией организации),

· Ориентирован на достижение отдачи от инвестиций и других пособий,

· Управляет закрытием программы.

 

Стандарт PMBOK

PMBOK(ProjectManagementBodyofKnowledge) - Свод правил по управлению проектами PMBOKGuide 3-rdEdition (ProjectManagementBodyofKnowledge), определяет круг знаний, необходимых для эффективного управления проектами. Документ включает в себя процессы охватывающие все стадии жизненного цикла проекта (инициация, планирование, исполнение, контроль и завершение). Результаты или выходы одного процесса могут являются входами для другого процесса. PMBOK включает следующие части процессов управления проектом:

· Управлениеинтеграцией (Project Integration Management)

· Управление человеческими ресурсами (ProjectHumanResourceManagement)

· Управлениезатратами (Project Cost Management)

· Управление содержанием (ProjectScopeManagement)

· Управлениесроками (Project Time Management)

· Управлениекачеством (Project Quality Management)

· Управлениекоммуникациями (Project Communication Management)

· Управлениерисками (Project Risk Management)

· Управлениепоставкамииконтрактами (Project Procurement And Contracts Management)

PMBOK имеет наибольшее распространение в мире. Создатели стандарта - Американский институт управления проектами (PMI - ProjectManagementInstitute). Основанный в 1969 году, Институт Управления Проектами (PMI) вырос в ведущую профессиональную ассоциацию по управлению проектами, объединяющую более 150 000 членов.

Вопрос 16.

Основные правила заполнения таблицы следующие:

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

· порядок следования колонок несущественен;

· каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);

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

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

· заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования).

Вопрос 17.

 

Базовая Архитектура, в свою очередь, включает:

  • набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technicalreferencemodel – TRM);
  • набор элементарных архитектурных элементов, которые используются как "строительные блоки" при построении конкретных решений;
  • базаданныхстандартов (Standards Information Base).

В состав Эталонной Модели, в свою очередь, входит система (таксономия) общих служб, включающая такие службы, как Обмен и преобразование данных, Управление данными, Поддержка интернационализации, Службы Каталогов и т.п.

TOGAF основан на итеративной процессной модели, которая предусматривает повторное использование имеющихся архитектурных компонент. TOGAF включает методологию разработки архитектуры под названием ArchitectureDevelopmentMethod(ADM). В соответствии с ADM разработка системной архитектуры состоит из следующих фаз:

Рисунок: ArchitectureDevelopmentMethod

 










Последнее изменение этой страницы: 2018-05-10; просмотров: 200.

stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда...