Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Методы сбора данных в человеко-ориентированном проектировании информационных систем. Учебное пособие
.pdf
В учебном пособии будут ссылки на многие рекомендации этого
свода знаний.
Управление проектами. Самым распространенным сводом знаний
по управлению проектами является PMBoK (англ. Project Management
Body of Knowledge) [49, 60]. Он подготовляется и выпускается Институтом управления проектами (Project Management Institute, PMI). В нем
представлены методики, подходы, инструменты и техники, необходимые для эффективного выполнения проекта.
Свод знаний с момента выхода первого издания в 90-е годы ХХ века регулярно обновляют и дополняют на основе полученного опыта
решения проблем, возникавших в процессе управления проектами. Актуальное издание на 2023 год – PMBoK 7, изданный
в 2021 году.
Представленные в руководстве знания могут быть использованы
командой проекта для того, чтобы предусматривать и оценивать риски,
принимать решения и строить оптимальные маршруты прохождения
проектов.
Согласно PMBoK в любом проекте надо выделять набор взаимосвязанных процессов, соответствующих его жизненному циклу: процессы инициации (подготовки), планирования, исполнения, мониторинга, контроля и
завершения.
Основная задача использования PMBoK – представить в одном месте информацию о терминах, процессах и артефактах в области управления проектами, использование которых обеспечит на практике достижение командой проекта согласованного понимания задач. Это хорошо
структурированный документ, описывающий процесс управления проектом в целом и знания, необходимые для выполнения отдельных задач
внутри
проекта.
Свод знаний содержит описание:
• терминов проектного управления;
• основных организационных структур компаний и ролей команды
проекта;
• процессов и областей знаний об управлении проектами.
Выделенные области знаний охватывают вопросы, начиная с управления содержанием проекта и заканчивая знаниями для управления интеграцией проекта – объединения всех ресурсов и процессов проекта на
всех этапах его жизненного цикла. Каждая область четко фокусирует
внимание менеджеров проектов на необходимости решения определенных задач, включая задачи сбора данных.
11
Знания по управлению проектами, представленные в PMBoK, лучше всего применимы к проектам, для которых на этапе инициирования
и планирования достаточно четко выявлены их требования, цели и задачи. К ним следует отнести все проекты создания ИТ-систем на основе типовых решений: проекты внедрения коробочных продуктов, установки оборудования и т
. д.
Знания PMBoK можно также использовать в проектах создания систем, состоящих из большого числа типовых элементов различного
назначения. Реализация таких проектов требует четкой координации
выполнения большого числа процессов в разных сферах деятельности
и выстраивания этих процессов в оптимальной последовательности.
Свод знаний PMBoK будет неэффективен в проектах с высокой
степенью неопределенности, например,
когда проект в целом связан
с производством инновационного продукта. Он также плохо применим
для проектов, где в ходе их реализации необходимо производить и/или
использовать инновационные продукты. Таким образом, PMBoK нецелесообразно использовать для большей части проектов разработки инновационных продуктов – проектов стартапов и проектов, содержащих
НИР и ОКР. На этапе подготовки
такого рода проектов сложно однозначно определить их содержание, цели, задачи, планируемые процессы и ресурсы. В этом случае для управления проектом следует использовать гибкие методологии управления. Заметим, что знания об этих
методологиях уже частично включены в седьмую версию РМВоК.
Программная инженерия. Общепринятая сумма знаний по про-
граммной инженерии
(Software Engineering Body of Knowledge, SWEBOK)
[64] публикуется обществом IEEE Computer Society с 2005 года
как международный стандарт ISO/IEC. Третья версия SWEBOK V3 одобрена и опубликована в качестве стандарта ISO/IEC TR 19759:2015.
SWEBOK является основополагающим научно-техническим документом, который согласуется с современной регламентацией процессов жизненного цикла программного обеспечения (ПО) стандартом
ГОСТ Р ИСО 12207 (ISO/IEC 12207) [65]. Понятие «программная инженерия» определяется как применение систематизированного перечня дисциплин,
оцениваемого по количественным параметрам подхода
к разработке, функционированию и сопровождению ПО.
Обновленная версия SWEBOK V3, вышедшая в 2014 году, содержит описание следующих 15 областей знаний, относящихся к программной инженерии:
1) требования к ПО (Software Requirements);
2) проектирование ПО (Software Design);
12
3) конструирование ПО (Software Construction);
4) тестирование ПО (Software Testing);
5) сопровождение ПО (Software Maintenance);
6) управление конфигурацией ПО (Software Configuration Management);
7) управление в программной инженерии (Software Engineering Ma-
nagement);
8) процесс программной инженерии (Software Engineering Process);
9) инструменты и методы программной инженерии (Software Engi-
neering Tools and Methods);
10) качество ПО (Software Quality);
11) профессиональные практики программного инжиниринга
(Software Engineering Professional Practice);
12) экономика программного инжиниринга (Software Engineering
Economics);
13) основы вычислений (Computing Foundation);
14) математические основы (Mathematical Foundation);
15) основы инжиниринга (Engineering Foundation).
Для каждой области даны определения ключевых
понятий, подходы,
рекомендуемые для применения, методы и инструменты поддержки инженерной деятельности при проектировании разных типов программных систем. Представленный в SWEBOK V3 объем знаний следует
практически использовать на соответствующих этапах жизненного цикла программной системы.
Бизнес-модель по руководству и управлению ИТ на предприя-
тии (COBIT). COBIT (англ. Control Objectives for Information and Re-
lated Technologies) – это рекомендации ISACA (англ. Information Systems Audit and Control Association) по
руководству предприятием и
менеджменту ИТ [49, 58]. Они издаются в виде «Бизнес-модели по руководству и управлению ИТ на предприятии» и по мере необходимости обновляются. Методология COBIT универсальна и может быть рекомендована организациям любого масштаба и сферы деятельности:
государственным, коммерческим и некоммерческим. На эту методологию ИТ-специалистам следует ориентироваться так
же, как и на рас-
смотренные выше своды знаний.
Версия COBIT 5, вышедшая в 2012 году, получила наибольшее
распространение. В ней была представлена методология решения задачи руководства и управления ИТ на предприятии, применение которой
поможет предприятиям «добиться оптимальной ценности от ИТ,
13
поддерживая баланс между получением выгоды и оптимизацией рисков и ресурсов» [58]. Использование методологии дает возможность:
• руководить и управлять ИТ всего предприятия не только в обла-
стях функциональной ответственности ИТ-специалистов, но и бизнеса
в целом,
• учитывать потребности в ИТ внутренних и внешних заинтересо-
ванных сторон.
В COBIT 5 описан набор принципов и факторов влияния, которые
обеспечивают внедрение системы руководства и управления ИТ на
предприятии. Факторы влияния – это сущности, которые способствуют
решению задач предприятия в целом. Рекомендуется использовать
семь видов факторов влияния:
1) принципы, политики и подходы;
2) процессы;
3)
организационные структуры;
4) культуру, этику и поведение;
5) информацию;
6) услуги, инфраструктуру и приложения;
7) персонал, навыки и компетенции.
Отметим, что большая часть используемых факторов прямо или
косвенно влияет на поведение людей.
Методология COBIT 5 акцентирует внимание руководителей на
вопросах развития информационных и связанных с ними технологий
с целью получения информации об ожидаемой выгоде, приемлемом
уровне риска и затратах от широкого круга заинтересованных сторон.
Эти ожидания следует выявлять, разрешать возможные конфликты
интересов, т. е. ими следует управлять. Для этого надо иметь полные и
сквозные описания функциональных обязанностей бизнеса и ИТ, а также управлять взаимодействием предприятий с внешними контрагентами
бизнеса и ИТ: аутсорсинговыми компаниями, поставщиками,
тантами, клиентами, поставщиками облачных и других услуг. Считается, что управление информационными технологиями должно стать
неотъемлемой частью всех бизнес-проектов, включая инновационные.
Необходимо также обеспечивать контроль над растущим числом ИТрешений, создаваемых и управляемых пользователями.
Версия COBIT 2019 года была актуализирована с учетом дополнительно полученного знания об информационных технологиях [49].
В этой
семи факторов влияния. Для обозначения каналов влияния на дости-
версии предлагается учитывать взаимосвязи указанных выше
консуль-
14
жение ИТ-целей вводится понятие компонентов влияния вместо понятия факторов влияния. Методология в целом построена на двух наборах принципов и предоставляет большую гибкость в решении задач
при внедрении и адаптации приложений.
Первый набор содержит принципы, описывающие требования к системе управления корпоративной информацией и технологиями.
Второй набор включает
фреймворку построения системы управления корпоративной информацией и технологиями.
Следование рекомендуемым принципам обеспечивает:
принципы, описывающие требования к
• построение концептуальной модели, учитывающей ключевые
компоненты и взаимосвязи между ними для обеспечения возможности
автоматизации;
• гибкость и открытость в поддержке соответствия ИТ-изменений
контексту и условиям жизнедеятельности организации;
• соответствие нормам законодательства и основным стандартам.
Процессы обеспечения безопасного управления корпоративной
информацией и технологиями (всего 40 процессов) были разделены на
пять категорий (доменов).
1. EDM (англ. Evaluate, Direct and Monitor) – оценка вариантов действий, помощь топ-менеджменту в принятии решений и мониторинг
прогресса в достижении целей.
2. APO (англ. Align, Plan and Organize) – управление всеми компонентами и процессами ИТ-инфраструктуры компании.
3. BAI (
ниями и их внедрением в бизнес-процессы.
4. DSS (англ. Deliver, Service and Support) – управление функцио-
нированием ИТ-сервисов, включая их безопасность.
5. MEA (англ. Monitor, Evaluate and Assess) – управление достиже-
нием внутренних и внешних показателей и целей.
На уровне предприятия интеграция применения рекомендаций COBIT
и других сводов знаний, стандартов и библиотек должна обеспечить:
• формирование ценности для заинтересованных
зультативного и инновационного использования ИТ на предприятии;
• удовлетворенность бизнес-пользователей услугами и работой ИТ;
• соответствие ИТ законодательству, правилам, контрактным обя-
зательствам и внутренней политике;
• совершенствование связей между потребностями бизнеса и целя-
ми ИТ.
англ. Build, Acquire and Implement) – управление ИТ-реше-
сторон путем ре-
15
Таким образом, рассмотренные своды знаний и методологии COBIT
содержат актуальные для практического применения в разработке
ИТ-инициатив основные подходы, принципы и методы, которые могут
быть использованы в различных областях деятельности специалистов
команды проекта. В них дано актуальное представление накопленных
знаний соответствующей предметной области, что позволяет быстро
и глубоко в ней ориентироваться.
При
разработке руководства для конкретного ИТ-проекта необхо-
димо учитывать следующее.
1. Практически все своды знаний и профессиональные стандарты
представляют собой рамочные документы (фреймворки). В них выделены комплексы задач, регламентированы основные входы, выходы,
критерии оценки, возможные инструменты и существующая практика
решения задач при выполнении определенной деятельности в ходе реализации ИТ
-проекта. Приводится рекомендуемый набор методов,
подходов и различной техники, включая методы сбора данных, которые можно использовать в решении выделенных задач. При этом дается свобода в использовании для решения выделенных задач других
методов и подходов.
2. Документы не содержат детального описания процессов решения
задач, т. е. предоставляют ИТ-специалистам свободу
действий в выборе инструментов и их конкретном использовании при решении задач
проекта.
3. Наиболее продуктивно своды знаний могут быть использованы
ИТ-специалистами, имеющими опыт практической работы. Они позволят им легко структурировать уже имеющиеся в команде проекта
знания и навыки для конкретного ИТ-проекта и в случае необходимости привлечь
дополнительно специалистов с необходимыми компетен-
циями.
4. Пользу для реализации конкретной ИТ-инициативы из представленных сводов знаний могут получить бизнес-аналитики, осуществляющие системный анализ бизнес-контекста при реализации различных
ИТ-инициатив в организации. Эти знания помогут им эффективно выполнять роль посредника между бизнес-персоналом и ИТ-персоналом
в
процессе разработки проекта.
5. Использование командой проекта рекомендаций этих источников
знаний при разработке конкретного проекта. Заметим, что отсутствие
у заказчика бизнес-аналитика потребует самостоятельного решения командой проекта задач системного анализа организации как управляемой
16
системы для определения бизнес-контекста ИТ-проекта. Для этого необходимо иметь специалистов, владеющих знаниями по бизнес-анализу
и работе с большой группой внутренних и внешних заинтересованных
сторон ИТ-инициативы. Заметим, что для задач анализа ракурса информационных технологий организации необходимы дополнительные компетенции ИТ-специалистам. Необходимо знание подходов, методов
и техники проведения такого анализа.
6. Без качественных исходных данных для анализа бизнесконтекста ИТ-проекта невозможно четко определить решаемую проблему, выявить и специфицировать требования к проекту.
7. Управление требованиями, по своей сути, – это работа на всех
этапах жизненного цикла проекта с заинтересованными сторонами по
согласованию решений об изменениях ИС. Работа команды проекта
включает решение комплекса задач выявления заинтересованных сторон, получение от них и из других источников первоначальных данных, анализ полученных данных с целью извлечения необходимой информации, согласование полученных результатов и т. д. Все это
требует от ИТ-специалистов знаний, умений и навыков, прежде всего в
области коммуникативного взаимодействия. Сбор и уточнение данных
в ходе реализации ИТ-проекта необходимы для системного представления командой проекта предметной области деятельности заинтересованных сторон.
8. Базовые понятия во взаимодействии с заинтересованными сторонами в ходе реализации проекта. Желательно иметь модели этих понятий. Для их построения можно воспользоваться рекомендациями
ВАВОК. К базовым понятиям при разработке ИТ-инициатив надо отнести следующие: человеко-ориентированное проектирование; измерение
и шкалы; данные, информацию и знания; коммуникацию и общение;
качество данных; управление данными, манипуляцию данными и т. д.
9. Для конкретного проекта возможность использовать методы
(технику) сбора данных в дополнение к рекомендуемым сводами знаний и стандартами.
1.2. ОБЩИЕ ПРИНЦИПЫ
ЧЕЛОВЕКО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ
Существующие своды знаний и серии стандартов акцентируют
внимание разработчиков ИТ-инициатив на использовании человекоориентированного проектирования систем. В сериях стандартов
17
ГОСТ Р 55241 [74, 75] и ГОСТ Р ИСО 9241 [71, 72] рассмотрены
вопросы системного анализа различных ракурсов организации и эргономики взаимодействия человек–система; методы обеспечения пригодности; принципы человеко-ориентированного проектирования, представления информации, организации диалога и т. д. В ГОСТ Р ИСО/МЭК
25021–2014 рассмотрены элементы показателей качества, требования
и оценка качества систем и
программного обеспечения (SQuaRE) [66].
Вопросы информационного обеспечения операторской деятельности, человеко-информационного взаимодействия, морфологии и грамматики языков операторской деятельности представлены в серии стандартов ГОСТ Р 43 [67–69].
Подчеркнем, что своды знаний, стандарты и методологии базируются на определенных наборах принципов. Цель использования руководящих принципов в реализации ИТ-инициатив – повысить качество
процессов проектирования
и управления проектом путем создания руководства по разработке продукта (сервиса, приложения, системы) для
команды конкретного проекта. При разработке такого руководства желательно ориентироваться на хорошо проверенные в практике принципы. Необходимо выбрать соответствующие промышленные руководящие принципы и создать руководство по стилю разработки проекта,
которое:
• установит критерии пригодности и
удобства работы с приложе-
нием для пользователей, которыми будет руководствоваться команда
ИТ-проекта;
• сориентирует команду проекта на всех этапах его жизненного
цикла на использование согласованных принципов;
• установит общую ответственность команды проекта за пользова-
тельский интерфейс;
• обеспечит следование руководящим принципам при покупке
программных продуктов, используемых в проекте;
• позволит использовать
ранее хорошо разработанные и тестиро-
ванные элементы в различных приложениях;
• сориентирует разработчиков на анализ работы пользователей
с приложениями после внедрения.
На рис. 1 показана рекомендуемая методологией управления информационными технологиями COBIT схема установления ИТ-целей и
детализации их в цели факторов (компонентов) влияния [58]. По мнению разработчиков методологии, она обеспечивает интеграционный
подход к организации руководства и управления ИТ на предприятии.
18
При этом информация и связанные с ней информационные технологии
рассматриваются как активы предприятия, которыми следует управлять, как и любыми другими активами.
Для любой ИТ-инициативы можно выделить две заинтересованные
стороны (внутренние и внешние), которые она прямо или косвенно
задевает. Одни стороны определяют цели, владеют и распоряжаются
ресурсами (заказчики, владельцы бюджета
и т. д.), другие – устанавливают ограничения, в рамках которых будут реализовываться бизнес- и
ИТ-процессы (по рискам, требованиям регуляторов, надсистем и т. д.),
но ни те, ни другие не участвуют непосредственно в работе автоматизируемых бизнес-процессов. Есть третья сторона, которая непосредственно участвует в процессах (исполнители процессов, конечные
пользователи ИС), пытается достичь требуемых первыми двумя сторонами результатов и отвечает за них. Информационная система предназначена в основном для поддержки их деятельности.
Рис. 1. Схема установления ИТ-целей и их детализации
Возможны различные варианты вовлеченности заинтересованных
сторон в жизнедеятельность конкретной организации. При этом каждая сторона имеет свои запросы к жизнедеятельности организации,
в которой реализуется ИТ-инициатива. На выявление значимых для
проекта заинтересованных сторон, получение и анализ данных об их
запросах, согласование интересов будет направлена во многом деятельность команды проекта (табл
. 1 [73, 75]).
19
Таблица 1
Характеристика принципов человеко-ориентированного подхода
Принцип подхода Краткая характеристика (рекомендации)
Проектирование на
основе точного определения пользователей, задач и среды
Вовлечение пользователей в проектирование и разработку
Улучшение проекта
за счет его оценки
пользователями
1. Определение всех важных групп конечных пользователей и других внутренних и внешних заинтересованных
сторон
2. Учет прямого или косвенного влияния, которое ИТ-система может оказать на пользователей и другие заинтересованные стороны
3. Учет степени пригодности и доступности ИТзависит от условий ее использования, где условия использования – это характеристики задач пользователей и вариантов среды
1. Пользователи – важный источник знаний об условиях
использования, задачах и о том, как они смогут применять
систему
2. Вовлечение пользователей должно быть активным
3. Пользователи могут участвовать в оценке тех или иных
ИТ-решений
4. Пользователи, активно вовлекаемые в проектирование,
должны отражать характеристики всех групп пользователей системы
5. Способы и результативность привлечения пользователей
к проектированию определяются активностью взаимодействия разработчиков и пользователей, а также особенностями проекта
6. При разработке универсальных ИТ-продуктов совокупность вовлекаемых пользователей должна представлять
собой группы пользователей с определенными характеристиками для правильной идентификации требований пользователей
1. Отзывы пользователей являются важным источником
информации при проектировании
2. Оценка проекта или прототипа пользователями является
средством уменьшения риска несоответствия ИТ-системы
их нуждам и реальным условиям деятельности
3. Оценка проекта пользователями должна быть частью проверки выполнения требований к проекту при его приемке
4. Отзывы
системы являются основой для последующей ее модификации
пользователей о результатах использования
системы
20
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]