Инструменты управления проектами - Менеджмент и трудовые отношения дипломная работа

Главная

Менеджмент и трудовые отношения
Инструменты управления проектами

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


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
· Обзор и интеграция существующего знания об управлении проектами на основе системной динамики;
· Обзор и интеграция существующего знания о циклах ПВР и методах их изучения;
· Качественный анализ выявленных в ранее проведенных исследованиях факторов, влияющих на циклы ПВР.
· Проведение стандартизированного наблюдения с полным участием наблюдателя в некоторых ситуациях и с исследователем полностью в качестве наблюдателя; проведение наблюдения в полевых условиях для получения наиболее естественной картины протекающих событий с учетом всех экзогенных и эндогенных факторов, влияющих на проект (имитация схемы управления проектами на основе системной динамики);
· Проведение анкетирования экспертной группы с целью установления причин возникновения циклов ПВР и последствий их возникновения;
· Проведение глубинного интервью с экспертной группой для перепроверки и подтверждения результатов анкетирования и проведенного наблюдения;
· Обобщение полученной информации и выработка рекомендаций по минимизации негативных последствий в результате возникновения циклов ПВР и по снижению вероятности их появления.
· наличие определенных критериев успеха реализации проекта;
· отчетливое понимание каждым участником команды собственной роли в реализации проекта;
· лояльное отношение каждого участника к реализуемому проекту.
Организационные факторы включают в себя следующие:
· поддержка и вовлеченность в процесс руководителя проекта;
· наличие определенной стратегической цели организации;
· реализация проектов согласно портфелям проектов, которые в свою очередь соответствуют стратегической цели компании;
· соответствие цели реализуемого проекта стратегической цели организации;
· наличие четко определенной для всех подразделений роли управления проектами.
Здесь стоит отметить важный фактор, который оказывает одно из самых значительных положительных влияний на продуктивное использование управления проектами в IT-области: соответствие реализуемых проектов стратегической цели компании и наличие четкого определения этой цели для всех участников проектной деятельности. Как говорилось ранее, в IT-области на данный момент распространено использование Agile-методологии, при использовании методов и инструментов которой конечная цель проекта может размываться в ходе самого процесса. Рассмотрим данный недостаток в следующем разделе и сравним Agile-методологию с традиционными методами управления проектами.
Используемые методы управления IT-проектами
На сегодняшний день существует множество различных подходов к управлению IT-проектами. Выбор того или иного метода зачастую осуществляется индивидуально по отношению к каждому проекту. Наиболее широко используются традиционные методы управления. В то же время, в условиях стремительно развивающихся информационных технологий, становится популярной Agile-методология, призванная повышать эффективность реализации IT-проектов. Таким образом, возникает проблема совмещения или поиска взаимосвязей между традиционными методами и Agile-методологией.
Основным преимуществом Agile-методологии является возможность внесения изменений в проект практически на любой стадии его реализации с наименьшими рисками для срока и бюджета, что достигается с помощью управления на основе спринтов с формулировкой для каждого из них краткосрочных целей для достижения. Но подобный метод управления влечет за собой другой негативный результат - итоговая цель (цель реализации всего проекта) становится размытой для участников, выполнение каждого спринта со своей краткосрочной целью может привести к отклонению от итоговой цели проекта.
Таким образом, agile-методология решает основной недостаток традиционных методов - значительный ущерб (как по срокам, так и по бюджету) при внесении изменений в проект на поздних стадиях реализации, что наиболее характерно для проектов, выполняемых в IT-сфере. Отсюда возникает идея совмещения agile-методологии и традиционных методов для повышения эффективности УП. С другой стороны, в обоих этих методах имеется еще один большой недостаток - пренебрежение учетом человеческого фактора и других обратных связей, которые возникают на протяжении всего процесса. Подобные обратные связи могут оказывать значительное негативное влияние на основные характеристики реализации проекта - сроки и бюджет; в первую очередь это происходит из-за возникновения циклов повторного выполнения работы (циклов ПВР), когда при получении дополнительной информации необходимо заново выполнять ту или иную работы. Избежать, точнее - снизить вероятность возникновения данного недостатка возможно с использованием подхода, основанного на системной динамике.
Говоря о традиционных методах, стоит сказать, что они основаны на идеи того, что даже если каждый проект уникален в своем роде, то его составляющие уже были изучены ранее, на примере какого-либо другого проекта. То есть, любой проект может быть разбит на несколько элементов, каких-либо событий/действий, каждое из которых может быть по отдельности рассмотрено как известный объект, изученный ранее при реализации аналогичных проектов. Таким образом, далее проводится оценка каждого события с точки зрения его стоимости, продолжительности и ресурсных затрат. Подобный подход приводит к разработке тщательно спланированного проекта, протекающего в четко определенных условиях и ограничениях, в то время как реальная ситуация может выглядеть немного иначе.
Таблица 1. Традиционные методы и подходы в УП
Начальное/базовое определение всего проекта. Оценки стоимости и наброски расписания
Определение ответственностей, организационной структуры проекта
Простое и наглядное представление расписания проекта без отображения зависимостей между отдельными событиями
Оценка и разработка реалистичного бюджета, подходящего под все стандарты, относительно которого отслеживаются все работы проекта
ИСПОЛЬЗОВАНИЕ ВЫШЕПЕРЕЧИСЛЕННЫХ МЕТОДОВ СОВМЕСТНО
Разработка расписания; определения взаимозависимости и уровней влияния событий; определение критических работ; основы стоимостной оценки, распределения ресурсов и анализа рисков
Таким образом, видно, что и традиционные методы, как и подход, основанный на системной динамике, рассматривают управление проектами в качестве динамического процесса планирования, применения и контроля.
Такие методы, как PERT, и инструменты, как WBS, и т.д. подразумевают детальную разработку плана проекта:
· разработка расписания с точным определением сроков для каждого события;
· разработка ресурсного расписания с точным определением использования материальных и человеческих ресурсов по каждой из работ;
Далее, каждый нынешний этап, на котором находится проект, сравнивается с планом.
В отличие от подобной схемы, основной целью подхода, основанного на системной динамики, является определение большинства обратных связей, ответственных за «поведение» проекта, пренебрегая при этом какими-то детализированными компонентами. Процесс управления проектом включает определение различных «мягких» факторов, которые зачастую являются экзогенными переменными, но при этом очень сильно (критично) влияют на результаты проекта. То есть большое внимание уделяется человеческому фактору.
Если рассматривать четыре основных этапа, то получается следующее:
· Планирование: рассматривается компромисс между задержкой завершения проекта и наймом новых сотрудников; модель включает различные стратегии по управлению персоналом и вопросы, связанные с приемлемостью задерживания проектов.
· Менеджмент управления человеческими ресурсами: несмотря на то, что традиционно этот этап включается в этап планирования, в системной динамике он рассматривается отдельно и затрагивает проблемы, связанные с наймом дополнительного персонала для проекта. Обычно сюда включаются такие факторы, как проведение тренингов и обучение персонала, уровень опыта рабочей силы, время, затрачиваемое на ассимиляцию.
· Применение: основное внимание обращается на проблемы, приводящие к ошибкам, которые могут остаться незаметными - концепция цикла ПВР. Здесь могут рассматриваться такие сложные проблемы, как задержки в предоставлении необходимой информации и оборудования, изменения структуры и процессов или политика обеспечения качества и недооценка проекта.
· Контроль: рассматриваются проблемы, связанные с отслеживанием нынешнего статуса проекта.
Как видно, подход, основанный на системной динамике, не зацикливается на детальной разработке той или иной работы; он позволяет оценить всевозможные варианты развития событий, разделяя все работы на две группы: «работы, которые должны быть сделаны» и «сделанные работы».
В целом, подход к управлению проектами на основе системной динамики имеет достаточно большие преимущества по сравнению с традиционными подходами. Доказательства этого так же можно найти в работе P.E.D. Love, G.D. Holt, L.Y. Shen, H. Li, Z. Irani [24], где очень четко высказано мнение относительно того, что любой проект постоянно подвергается влиянию окружающей его среды, причем не только каких-то внутренних факторов, как отношения внутри команды и их мотивация, но и различных внешних, так называемых, регрессоров как, например, политическая ситуация в стране и в мире, изменения в социальных и культурных отраслях и т.п. При этом авторы указывают на некоторые недостатки риск-менеджмента, заключающихся в том, что все его методы направлены на риски, которые возможно заранее определить, но в целом система не включает в себя какие-либо методологии относительно того, как предугадать появление риска, индивидуального для данного проекта. Таким образом, авторы высказывают мнение, что подход, основанный на системной динамике, позволяет улучшить процесс принятия решений на стратегическом уровне, в то время как традиционные методы позволяют справиться только с третью основных задач, возникающих в процессе управления проектом.
Например, в работах Rodrigues A, Bowers J. [36] высказано предположение, что управление проектом можно разделить на следующие ступени:
· Уровень 1 - взаимодействие проекта и компании-подрядчика; важным вопрос здесь оказывается то, совпадают ли цели проекта с целями компании;
· Уровень 2 - так называемые, стратегические альтернативы конкретного проекта; например, какие основные задачи определены в проекте, их соответствие основным целям, форма организационной структуры;
· Уровень 3 - здесь определяются конкретные детали проекта, включая в себя объем необходимой рабочей силы, сроки и расписание проекта и т.д.
Указывается, что если традиционные методы способны справиться с последним уровнем, то на первом и втором они оказываются, зачастую, бессильны, хотя бы в силу того, что не направлены на включение различных психологических факторов.
Преимущества использования подхода, основанного на системной динамике
Ключевые моменты, характеризующие преимущество управления проектами на основе системной динамики:
· Важно понимать, что поведение системы возникает из обратной связи, которая поступает от накопителя (состояния системы) к потокам, изменяющим состояние системы (накопитель).
· Модель, построенная на основе системной динамики, должна приносить полезность и доверие/уверенность конечному пользователю (то есть менеджеру). Полезность зависит от того, затрагивает ли модель ключевые проблемы, которые интересуют менеджера; в то время как наличие доверительного уровня означает способность модели давать результаты, согласующиеся с ментальными моделями самих менеджеров.
Можно выделить несколько проблем, связанных с основными характеристиками проектов, которые решает системная динамика [37]:
1) Разрабатываемые проекты сложны и состоят из множества взаимозависимых компонент.
Взаимозависимость усложняет анализ из-за того, что какие-либо изменения в одной части системы могут повлечь за собой изменения в другой - может быть нарушено расписание выполнение одной работы, что ведет к задержке выполнения всего проекта, появлению циклов повторного выполнения работы (циклы ПВР) и т.д.
2) Разрабатываемые проекты очень подвижны
Например, такие процессы как найм сотрудников и их обучение постоянно требуют различного количества времени, зачастую - сверхурочного. В таких процессах почти всегда возникают временные задержки, связанные также с обнаружением и исправлением ошибок и с применением различных мер в ответ на предсказуемые изменения проекта. Такие динамические элементы подразумевают, что краткосрочные ответы системы на какие-то экзогенные или эндогенные возмущения могут отличаться от долгосрочных. К примеру, найм дополнительных сотрудников в долгосрочной перспективе расширяет возможности организации, в то время как в краткосрочной перспективе производительность опытных работников снижается, так как они вынуждены затрачивать часть своего времени на обучение стажеров.
3) Во всех проектах имеются обратные связи и отдача.
Существуют позитивные и негативные петли обратной связи. Позитивные петли характеризуются следующими признаками:
Негативные петли, в свою очередь, характеризуются следующим:
Например, когда наблюдается угроза выхода проекта за рамки расписания, одним из возможных способов ответных мер является увеличение использования сверхурочных трудозатрат. С другой стороны, длительная работа в таком темпе может выбить из сил сотрудников, снизить их мотивацию и заинтересованность, что, в свою очередь, приведет к снижению производительности, увеличению вероятности появления ошибок, что говорит о наличии позитивной петли обратной связи. Для возвращения системы к устойчивому состоянию необходимо введение каких-либо негативных петлей обратной связи.
Традиционные инструменты по снижению затрат и управлению расписанием как, например, метод CPM (critical path method) не могут в полной мере справляться с эффектом отдачи и обратной связи. Оценка людей, как правило, субъективна в таких ситуациях, что приводит к недооценке возможных отдач. Никто из людей не застрахован от ошибок. Поэтому, даже методы, направленные на управление расписанием, как диаграммы Ганта, PERT и CPM не могут решить данной проблемы, что, впрочем, не означает, что данные методы не являются важными; наоборот, традиционные инструменты и системная динамика дополняют друг друга.
4) Разрабатываемые проекты состоят из нелинейных связей.
Наличие нелинейных связей вполне логично для сложных систем; это означает, что все причинно-следственные связи не имеют простой, пропорциональной зависимости. Например, рассматривая приведенный выше пример, увеличивая количество рабочих часов с 40 до 44 в неделю, можно увеличить отдачу на 10%. Но, опять же, как говорилось ранее, длительные и частые переработки приводят к быстрому угасанию производительности работников, их невнимательности, снижению мотивации, увеличению совершаемых ошибок и так далее. Системная динамика в своих моделях берет во внимание все возможные варианты развития события.
5) Разрабатываемые проекты включают в себя и «жесткие», и «мягкие» данные.
При разработке проектов учитываются не только технические зависимости между компонентами, но и влияние человеческого фактора. Системная динамика включает использование разнообразных источников данных, включая числовые данные, интервью, исследования, наблюдения и другие методы, позволяющие выявить основы организационной структуры, основных целей и тд.
Далее приведен инструментарий, который принято использовать при построении моделей системной динамики и имитационных моделей на основе причинно-следственных диаграмм:
Рисунок 1 . Схематичное представление потоков и накопителей; Ист. [36]
С помощью потоков и накопителей очень наглядно изображаются обычные причинно-следственные связи. Накопителями являются «стоки», потоки бывают исходящие и входящие. Облако при исходящем потоке показывает какой-то источник, который в данном исследовании может не конкретизироваться; такое же облако может быть на наконечнике исходящего потока. Есть стандартизированные требования к данным обозначениям [1]:
· потоки всегда выражаются в единицах размерности модели (количество людей, рублей, литров, метров, килограмм и т.п.) за единицу времени (минуту, час, день, месяц, квартал, год и т.п.);
· накопители всегда выражаются в единицах модели;
· единицы измерения потоков на входе и потоков на выходе всегда совпадают (т.е. если в модели входящий поток измеряется в единицах «человек в год», то и на выходе поток должен измеряться количеством человек за год, но никак не за месяц, квартал и т.п.).
Влияние обратных связей и циклов ПВР на продолжительность IT-проектов
Основными причинами увеличения продолжительности IT-проектов, как и проектов в других областях, можно назвать снижение производительности членов команд и возникновение описанных ранее циклов ПВР. Все эти факторы взаимосвязаны между собой преимущественно за счет наличия обратных связей в ходе протекания любого процесса. Как только менеджер проекта замечает какое-либо отклонения от планового срока реализации всего проекта или отдельной задачи, он предпринимает различные инструменты для корректировки отклонения. Зачастую применяется три основных способа:
· увеличение трудозатрат членов команд (частые переработки);
· добавление новых участников в команду (привлечение дополнительных человеческих ресурсов).
В результате, всё это оказывает негативное влияние на мотивацию сотрудников, выражаясь в конечном итоге в снижение производительности. Снижение производительности, в свою очередь, влияет на увеличение возникновения циклов ПВР и увеличение их продолжительности. Таким образом, наблюдается возникновение многочисленных позитивных петлей, которые способствует экспоненциальному росту отклонения фактических сроков от плановых [Рис.2].
Рисунок 2. Обратные связи при использовании менеджером различных методов для корректировки задержки; Ист. [12]
Обратные связи, описанные выше, приводят к появлению циклов повторного выполнения работы (циклы ПВР); подобный цикл схематично может быть представлен следующим образом [5]:
Рисунок 3. Схематичное изображение цикла ПВР; Ист. [5]
Данная схема не является единой, но все циклы в любом проекте протекают примерно одним и тем же образом. Как видно из схемы, цикл состоит из четырех накопителей (стоков). Изначально все работы в проекте относятся к типу «следуемые для выполнения»; далее, после протекания различных процессов, некоторые работы переходят в стадию «выполненных», что в свою очередь истощает первый накопитель, а позже и накопитель, обозначающий известные работы, которые будут повторены. Зачастую, увеличение количества работ, которые несколько раз повторяются, наблюдается в середине и конце проекта.
Наличие обратной связи и циклов ПВР может оказывать следующее влияние на проект: цикл ПВР сдвигает сроки выполнения работ вправо - то есть, увеличивает их, но при этом качество выполнения работ и производительность возрастает [22]:
Рисунок 4. Влияние циклов ПВР на сроки и качество; Ист. [26]
Рассмотрим пример [2]. Размер проекта предполагается равным 64 000 DSI (специальная размерная величина для оценки количества строк кода) [24, 39]. Размер номинальной потенциальной производительности обычного рабочего со средним уровнем опыта равен 1 заданию за рабочий день, а значимость 1 задания равна 60 DSI. Таким образом, получается, что размер проекта в терминах выполненных задач равен 64 000/60 = 1,067.
На начальном этапе менеджеру предстоит оценить размер проекта. Никогда не известна настоящая величина, поэтому оценка очень приблизительна. Представим, что проект был недооценен и было предположено, что его размер составит только 33% от реального, т.е. 0,67*64 000 = 42 880 DSI. Далее на основании этого уровня проводится оценка необходимых усилий и расписания с помощью модели COCOMO Это алгоритмическая модель оценки стоимости разработки программного обеспечения, разработанная Барри Боэмом (Barry Boehm). Модель использует простую формулу регрессии с параметрами, определенными из данных, собранных по ряду проектов. Ист. [24, 32] . По данной модели получилось, что необходимое количество рабочих дней равно 2 359 дней, а продолжительность проекта = 296 дней.
В конце рассчитывается среднее необходимое количество сотрудников посредством деления количества рабочих дней на продолжительность проекта; получили 8 людей. Но очень редко бывает, что с первого же дня проекта задействована необходимое количество людей - в этом основная проблема.
На фоне всех этих условий строится оценочный график, на котором видно, что при таких изначальных предположениях в реальной ситуации проект будет выполнен более, чем за 440 дней (это происходит за счет того, что в процессе выполнения установленных задач, все детальнее становится видно всю ситуацию и ее реальные значения):
Рисунок 5. Оценочный график 1. Ист. [2]
Рассмотрим более подробно ситуацию с производительностью.
Как видно из указанного выше графика, средняя номинальная потенциальная производительность (ANPPRD) падает вначале из-за того, что затрачивается время на обучение персонала. Далее, потенциальная производительность начинает расти (POTPRD), например, благодаря получению новых знаний в конкретной сфере.
В проекте существует две причины снижения производительности. Первый тип причин включает мотивацию и общение; влияет этот тип на образование пробела (gap) между потенциальной производительностью и реальной. Второй тип причин влияет на снижение уровня средней производительности.
Рисунок 6. Оценочный график 2. Ист. [2]
Здесь видно, что в самом начале проекта фактическая доля человеко-дней (рабочих дней) (AFMDPJ) составляла 0,6, что означает, что члены команды тратили по 0,6*8 = 4,8 часов в день на проект. На последнем этапе наблюдается резкий взлет этой кривой, что говорит о значительных переработках, которые, в свою очередь, возникли из-за изначальной недооценки проекта.
Одним из прямых доказательств влияния циклов ПВР на увеличение продолжительности реализации проектов является то, что на выполнение таких циклов требуется соответствующие временные затраты. Существуют различные типы циклов ПВР, на реализацию которых затрачивается различное количество дополнительного времени и бюджета.
Различные типы проблем оказывают влияние на появление циклов ПВР через возникновение обратных связей, учет которых является основным преимуществом применения системного подхода в управлении проектами. Рассмотрим существующие циклы ПВР.
В работе S. B. Yu and J. Efstathiou [50] циклы ПВР делятся на 5 типов:
a) обратный цикл ПВР - простая система обратной петли, которая подразумевает, что переделанный объект возвращается в основной поток, в котором снова подвергается проверке; здесь необходимы высокий уровень квалификации и значительный опыт «инспектора»;
b) прямой цикл ПВР означает, что после того, как какой-то объект или процесс переделан, он не проверяется заново, а включается уже полноценно в поток; соответственно, такая система обусловлена значительными рисками в плане того, что если «ремонт» объекта не исправил каких-то недочетов, то это может оказать негативное влияние на последующую работу;
c) цикл «отбрасывания» - после выявления какого-то дефекта, объект не отправляется на доработку, а выкидывается из работы совсем; это явление может быть обусловлено высокими финансовыми затратами, которые в последующей работе скорее всего не оправдаются;
d) двойной обратный цикл - подразумевает наличие еще одной (дополнительной) инспекции после устранения неполадок дефектного объекта, причем, объект не будет возвращен в общий поток, пока не будет окончательно пройдена данная инспекция;
e) обратный цикл с буфером - подразумевает наличие буфера, который дает возможность упорядочить сбившийся из-за повторного выполнения работы информационный или материальный поток; такой буфер несет дополнительную стоимость, но, в свою очередь, смягчает влияние на сроки, т.к. в нем изначально учитывается дополнительный временной ресурс. Если же буфер не предусмотрен, то может возникнуть следующая ситуация:
Рисунок 7. Нарушение последовательности при наличии цикла ПВР; Ист. [46]
Как видно на Рисунке 1 (а) и (b) во время того, как объект 3 находился на доработке, другие три объекта (6, 5 и 4) успели пройти проверку, поэтому на выходе (с) получилась нарушенная последовательность. В работе введена величина, которая измеряет данное изменение последовательности и равна тому, на сколько «объектов назад» был отброшен исправленный объект - длина беспорядка (в данном случае, равна 3), обозначается.
Ниже приведен рисунок, на котором схематично указаны перечисленные выше типы циклов ПВР:
Рисунок 8. Схематичное изображение типов циклов ПВР;Ист. [39]
Для каждого проекта или даже для каждого отдельного процесса в проекте необходимо выбирать наиболее подходящий цикл ПВР. Интересен следующий результат, полученные в ходе этого исследования: повышение сложности нарушенной последовательности находится в прямой зависимости с наличием цикла ПВР, но в обратной с проводимой «инспекцией», что, впрочем, логично, т.к. чем чаще проводится проверка объектов на наличие дефектов, тем меньше вероятность, что время, затраченное на исправление этих ошибок, будет достаточно велико для нарушения последовательности; с другой стороны, часты «проверки» могут оказаться более затратными, нежели последующее восстановление последовательности, но все равно при этом остается преимущество в плане сохранения сроков выполнения всего процесса в целом (правда, «инспекция» частая инспекция может не выявить никаких отклонений, в то время как значительные материальные средства на ее проведение будут затрачены). Кроме того, в результате проведенного исследования, были полученные следующие результаты по достоинствам и недостаткам всех типов циклов ПВР по достигнутому уровню той или иной характеристики:
Таблица 2. Сравнение различных типов циклов ПВР
Наиболее широко встречающимся типом цикла ПВР (для проектов в различных сферах) является обратный цикл ПВР, так как он не требует сверхзатрат на установление дополнительного цикла проверки, т.е. дополнительной инспекции. При этом, подобный подход к устранению дефектов может нести негативные аспекты, проявляющиеся в значительной нагрузке на единственное звено проверки. Такие типы циклов, как прямой, обратный и цикл «отбрасывания» наиболее приемлимы для производственных проектов, когда проблемы преимущественно возникают из-за технических недостатков используемого оборудования. В процессах, которые в большей мере построены на использовании человеческих ресурсов, наиболее приемлемым представляется моделирование циклов ПВР на основе типов двойной проверки и обратного с временным буффером. Двойная проверка позволяет распределить нагрузку на инспектора, а запланированный буффер - предусмотреть возможность возникновения проблем, связанных с человеческим фактором (дополнительное согласование процессов, утверждение изменений, дополнительное тестирование исправленных работ и т.д.).
Необходимость наличия подобного буффера обуславливается еще одним фактором - потребность в дополнительном времени на обработку задач, ожидающих повторного выполнения. Исследование Hazhir Rahmandad и Kun Hua [33] предлагает интересный подход к изучению циклов ПВР. Интересна модель, предложенная авторами, которая рассматривает циклы ПВР не только с точки зрения выполняемых задач и задач, отправляемых на «инспекцию», но и с точки зрения самих дефектов. Два процесса могут протекать параллельно: процесс проверки на наличие дефектов самих задач и жизненный цикл самих дефектов, и эти два процесса очень тесно взаимосвязаны.
Все дефекты, как и основные задачи, могут находится на стадии ожидания проверки, после чего переходят в стадию дефектов, ожидающих переделывания, а оттуда они либо возвращаются в первоначальное состояние в качестве упущенных дефектов, либо уходят в общий поток работы в качестве исправленных дефектов (причем, пропущенные дефекты проходят повторно цикл, но некоторый их процент так и остается пропущенным и возвращается в общий поток задач).
Исследователи предложили очень интересный вариант расчета вероятности выявления дефектов. Для этого было предложено понятие дефектной плотности - общее количество дефектов на полный объем работ. То есть если 100 задач, 113 дефектов, то плотность равна 1,3. На нижнем рисунке данное явление представлено схематично (зеленое поле - общий объем работ, красные точки - разброс дефектов, область в правом нижнем углу - проводимый тест на выявление дефектов, площадь этой области обозначается буквой a и рассчитывается в задачах):
Рисунок 9. Дефектная плотность; Ист. [29]
И это дает возможность расчета вероятности через Пуассоновское распределение. Данное распределение было выбрано в силу двух факторов: вероятность выявления дефектов одинаково на любой области проведения тестов; каждый из дефектов имеет одинаковую вероятность попадания в тест.
Отсюда была выведена формула вычисления вероятности выявления k дефектов в тестовой зоне размера a:
таким образом, если плотность (d) равна 1,3, а a=1, k=0, тогда существует 27 процентная вероятность выявления этих дефектов. Если k=1, тогда вероятность повышается до 35%, что вполне логично. Причем, при увеличении области проверки, вероятность тоже значительно увеличивается, если k мало; если k достаточно велико (примерно соразмерно с количеством проверяемых задач), то вероятность увеличивается, но не значительно.
Кроме того, была выведена формула расчета вероятности безуспешного прохождения тестирования:
Значение обозначает вероятность того, что была протестирована с k дефектами и k дефектов были упущены.
Единственным возможным препятствием здесь может быть тип цикла ПВР (типы циклов были представлены ранее). Если брать цикл с двойной инспекцией, тогда здесь необходимо рассматривать этот цикл опять же в виде двух отдельных циклов с прямой петлей, иначе распределение Пуассона уже может подвергнуться сомнению, т.к. вероятность выявления дефектов на двух уровнях будет разная. Но даже если рассматривать эти циклы отдельно друг от друга как два простых, тогда появляется сложность в том плане, что дефект, прошедший инспекцию 1, затем прошедший инспекцию 2, возвращается обратно в инспекцию 1, но уже с другой вероятностью выявления, причем она может быть как выше, так и ниже. Выше,
Инструменты управления проектами дипломная работа. Менеджмент и трудовые отношения.
Реферат: Ловушка для животноводов и тяжёлых металлов
Реферат: Психология человеческих проблем
Анализ Производительности Труда На Предприятии Курсовая
Контрольная работа: Кредит в практике внешней торговли. Пластиковые деньги
Курсовая работа по теме Анализ системы управления ОАО 'Мегафон-Ритейл'
Помощник В Написании Сочинений
Скачать Клише Для Итогового Сочинения
Контрольная работа: Великий русский педагог К.Д.Ушинский - основоположник научной педагогики в России
Организация Продажи Современного Банковского Продукта Курсовая
Цифровой Отчет По Производственной Практике
Курсовая работа: Влияние семьи на становление личности. Скачать бесплатно и без регистрации
Сочинение Каким Я Вижу Воспитателя
Реферат: Забота о здоровье людей
Сочинение Дубровский Герой Или Разбойник
Отчет по практике по теме Принципы осуществления надзора над соблюдением санитарного законодательства
Экология И Общество Реферат
Пожарная Охрана Реферат
Курсовая работа по теме Климат Крымского полуострова и тенденции его изменения
Анализ Кредитоспособности Предприятия Курсовая Работа
Книги Для Сочинения Егэ
Проектирование измерителя временного интервала - Коммуникации, связь, цифровые приборы и радиоэлектроника курсовая работа
Особенности комплексных смысловых переводческих трансформаций при научно-техническом переводе - Иностранные языки и языкознание курсовая работа
Аналіз діяльності Гюстава Доре - Культура и искусство контрольная работа