Объем дисциплины. Особенности проектного менеджмента. Модели СПУ как инструмент управления IT-проектом

Основы экономики программной инженерии и управление проектами Лекция 1 План лекции 1 0. Объем дисциплины 1. Особенности проектного менеджмента. Литература по теме 1 2. Модели СПУ как инструмент управления IT-проектом. 2.1 Задача планирования комплекса работ Литература по теме 2 0. Объем дисциплины Общий объем дисциплины в з.е. /час: 5 / 180 Форма промежуточной аттестации: Экзамен Форма обучения Лекции очная 17 Виды занятий, их трудоемкость (час.) В том числе, СРС для Самостоятель изучения Лабораторные ная работа теоретического работы студента материала, не (СРС) изложенного в лекциях 34 93 40 Как следует из приведенной таблицы, в дисциплине планируются часы по СРС не только на изучение лекционного материала и выполнение заданий по лабораторным работам, но и для самостоятельного освоения теоретического материала с использованием учебников и электронных ресурсов. 1 Особенности проектного менеджмента Методики управления любыми проектами являются в значительной степени универсальными. Однако область реализации проекта оказывает существенное влияние на организацию управления его исполнением. Особенно это характерно для такой специфической области, как информационные технологии (ИТ). Разнообразными и специфичными оказываются модели жизненного цикла и иерархические структуры программных проектов (IT-проектов), состав проектных команд, источники рисков и приемы их минимизации и пр. Согласно определению, принятому ЮНЕСКО, ИТ — это комплекс взаимосвязанных, научных, технологических, инженерных дисциплин, изучающих методы эффективной организации труда людей, занятых обработкой и хранением информации; вычислительную технику и методы организации ее взаимодействия с людьми и производственным оборудованием, их практические приложения, а также связанные со всем этим социальные, экономические и культурные проблемы. Организация управления столь сложными объектами потребовала разработки соответствующих подходов, которые были сформулированы в виде различных методологий и стандартов (ITIL, MOF, MSF, COBIT и пр.). В основе этих методик лежит предположение о существовании достаточно универсальной модели жизненного цикла информационных технологий (ЖЦ ИТ) и ограниченного множества технологических и управленческих задач (процессов), которые должны выполняться на различных этапах жизненного цикла и обеспечивать качество и эффективность ИТ. При анализе такой модели становится очевидным, что отдельные подмножества процессов ЖЦ ИТ естественным образом объединяются в проекты и, как следствие, требуют применения методов проектного управления для их качественного исполнения. Наиболее масштабными и значимыми оказываются проекты, связанные с созданием и внедрением некоторых ИТ-решений, в частности, информационных систем (ИС), управление проектами которых будет рассматриваться в данной дисциплине. В настоящее время на уровне международных стандартов существует множество толкований понятия «проект». Приведем одно из них: «под проектом понимают временнόе предприятие, направленное на создание уникального продукта, услуги или результата». Из данного определения следует, что проект имеет продолжительность во времени: дату начала и завершения; является предприятием, предпринятым для создания продукта (услуги), направленного на достижение определенной цели (целей). Классическое определение проекта: «Проект – это комплекс усилий, предпринимаемых с целью получения конкретных уникальных результатов в рамках отведенного времени и в пределах утвержденного бюджета, который выделяется на оплату ресурсов, используемых или потребляемых в ходе проекта». Другие определения проекта см. в учебнике [2] – в параграфе 1.1 «Основные понятия и определения». Итак, помимо ограничений во времени, любой проект имеет финансовые, трудовые (человеческие) и другие ограничения. Рациональная реализация программного проекта должна обеспечить достижение конкретных результатов при соблюдении ограничений «железного треугольника» (рис.1): Рис. 1 – «Железный треугольник» ограничений проекта Ни один из углов треугольника не может быть изменен без изменения других. Например, чтобы уменьшить время, потребуется увеличить бюджет и/или сократить содержание. В приложении к индустрии программного обеспечения к трем основным ограничениям «железного треугольника» добавляют четвертое ограничение — приемлемое качество. В этом случае система ограничений должна строиться на основе приоритетов проекта и учитывать требования потребителей к создаваемому продукту или услуге. В случае необходимости жесткого предопределенного набора функциональности «плавающими» характеристиками проекта будут требуемое время и необходимый бюджет (рис. 2). Неотъемлемой частью любого программного проекта является анализ компромиссов, направленный на выделение функциональных требований, которые можно реализовать в заданных ограничениях проекта, будь то сроки, бюджет, качество или другие характеристики. В общем случае задача такого анализа состоит в нахождении баланса, приемлемого для всех сторон, связанных с проектом; заказчиков, которым нужна определенная функциональность в конкретные сроки при имеющемся бюджете; исполнителей, которые обладают бюджетом, достаточным для реализации проекта в заданные сроки с расчетным уровнем трудоемкости проекта и соответствующим уровнем качества. Неотъемлемой частью любого программного проекта является анализ компромиссов, направленный на выделение функциональных требований, которые можно реализовать в заданных ограничениях проекта, будь то сроки, бюджет, качество или другие характеристики. В общем случае задача такого анализа состоит в нахождении баланса, приемлемого для всех сторон, связанных с проектом; заказчиков, которым нужна определенная функциональность в конкретные сроки при имеющемся бюджете; исполнителей, которые обладают бюджетом, достаточным для реализации проекта в заданные сроки с расчетным уровнем трудоемкости проекта и соответствующим уровнем качества. Согласно стандарту PMBOK (A Guide to the Project Management Body of Knowledge — Руководство к своду знаний по управлению проектами) проект считается успешным, если он выполнен в срок в соответствии со спецификациями и в пределах запланированного бюджета. Общепринято, что не существует единственного правильного процесса разработки программного обеспечения. В каждом новом проекте в соответствии с «Законом 4-х П» (рис. 3) процесс должен определяться каждый раз заново, в зависимости от проекта, продукта и персонала. Совершенно разные процессы должны применяться для проектов, в которых участвуют 5 человек, и для проектов, в которых участвуют 500 человек. Если продуктом проекта является критическое ПО (например, система управления атомной электростанцией), то процесс разработки должен сильно отличаться от разработки сайта. И, наконец, по-разному следует организовывать процесс разработки в команде начинающих программистов и в команде состоявшихся профессионалов. Реализация любого проекта предусматривает скоординированное выполнение взаимосвязанных действий. Очевидно, чем сложнее проект, тем более актуальной становится задача координации работ и исполнителей данного проекта. Сказанное выше позволяет выделить следующие основные признаки проектных разработок: · они направлены на достижение конкретных целей; · они включают в себя взаимосвязанные работы; · они имеют ограниченную протяженность во времени, с определенным началом и концом; · все они в определенной степени неповторимы и уникальны. В общем случае, именно эти четыре характеристики отличают проекты от других видов деятельности. Каждая из названных характеристик важна, об этом речь пойдет в других темах. Однако особого внимания требует первая из названных характеристик, на которой остановимся более подробно. Направленность проекта на достижение целей Проекты нацелены на получение определенных результатов - иными словами, они направлены на достижение целей. Именно эти цели являются движущей силой проекта, и все усилия по его планированию и реализации предпринимаются для того, чтобы эти цели были достигнуты. Разные типы IT-проектов преследуют разные цели. Грамотно сформулированная цель (цели) определяет особенности управления (менеджмента) проектом. Что, в свою очередь, позволяет полно выявить задачи проекта, определить его состав и структуру, связи с внешней средой, технологию разработки и внедрения. Как правило, цели проекта должны соотноситься с организационными (в том числе, с организацией вычислений) или организационно-экономическими вопросами в системе, в рамках которой рассматривается проект. Здесь цель можно рассматривать – по аналогии с понятием эффективности операции в исследовании операций. Иногда – это один показатель из рассматриваемой системы, для которой создается проект. В.И. Грекул в своей работе [1] отмечает особую роль информационных технологий (ИТ): «В соответствии с современными представлениями ИТ должны не только поддерживать достижение текущих бизнес-целей организации, но и являться источником и движущей силой стратегических изменений бизнеса. Этим обусловлены исключительная важность эффективного управления информационными технологиями, возросшее внимание к развитию методов корпоративного управления информацией и ИТ-активами». Остановимся в этой связи на примере. Пусть разрабатывается проект информационной системы автоматизации судопроизводства в судах общей юрисдикции. Некоторые разработчики видят цель: разработать ПО для оперативного учета документов в процессе судопроизводства. Это первый (наиболее часто используемый подход, продвигаемый на практике некоторыми программистами и «теоретиками», стремящимися к самовыражению в Интернет). Второй подход к выявлению целей названного проекта, отмеченный, в частности, в работе [1], – найти пути повышения эффективности использования отдельных информационных технологий и проекта в целом. Здесь можно выявить цели: · сократить затраты труда государственных гражданских служащих судов общей юрисдикции; · повысить эффективность принятия судебных решений судьями – путем разработки и внедрения проекта информационной системы автоматизации судопроизводства. Во втором случае разработка проекта – это не самоцель. Это средство для реализации поставленных целей, лежащих в данном случае в системе судопроизводства суда. Здесь поставлены цели проекта, реализация которых поможет специалистам при выполнении их должностных обязанностей, сделает более эффективной их работу. Цели достигаются «путем разработки и внедрения проекта». То есть проект – это не цель. Это средство для ее реализации. Встает вопрос: могут ли отразиться на самом проекте, на его качестве, поставленные тем или иным образом цели? Может быть, цели вообще не надо ставить? Для ответа на эти вопросы рассмотрим возможные варианты реализации названного проекта. В первом случае на поверхности лежит пресловутый подход к автоматизации оперативного учета: разрабатываются программы, позволяющие вводить информацию первичных процессуальных документов в суде и накапливать ее в базе данных. Кажется, что же еще? Но на практике все сложнее: секретари судебных заседаний будут вводить эту информацию в БД, и при этом вести вручную всевозможные картотеки и журналы, являющиеся обязательными, будут выполнять работу по подготовке текущих документов к судебным заседаниям с учетом поиска в картотеках и прочие функции. В итоге затраты их труда с внедрением проекта не уменьшатся, а наоборот – значительно возрастут, что приведет к регулярному резкому увеличению рабочего дня и, как итог – массовому увольнению работников с этих должностей (сценарий – не придуманный здесь только ради примера). В итоге – проект не эффективен, внедрение не реально, в системе управления – дополнительные издержки из-за текучести кадров. При втором подходе, если ставить целью сокращение затрат труда названных специалистов, работу в проекте придется начинать не с автоматизации первичных документов, а с совершенствования системы всего документооборота в судопроизводстве. Здесь, во-первых, нужно будет решить организационно-правовые вопросы отмены обязательного ручного заполнения различных картотек и журналов, справок, отчетов и проч. При этом в проекте должна быть предусмотрена не только автоматизация первичных документов, но и: · процедуры автоматизированного формирования всех промежуточных процессуальных и деловых документов на основе первичной учетной информации; · процедуры формирования справок по запросам; · итоговых отчетов в вышестоящие инстанции. Все эти формируемые электронные документы: их форму и технологию формирования – нужно вначале утвердить, а затем автоматизировать. Во-вторых, необходима разработка мощной поисковой системы, которая позволяла бы находить в БД всю ту информацию, которую находили вручную по документам. Для этого должны быть реализованы не только типовые запросы к БД, но и язык запросов, формируемых пользователем ситуационно. Для реализации цели «повышение эффективности судебных решений» – требуется разработка банка судебных решений и соответствующей экспертной системы, позволяющей выдавать рекомендации по принимаемым решениям с пояснениями по ним. Очевидно, что при втором подходе к проекту информационная система будет иметь другой состав и структуру. Что приведет в возрастанию не только затраты на программирование, но потребуют решения таких системных вопросов как «Совершенствование нормативно-организационной документации», «Совершенствование документооборота», «Разработка информационно-поисковой системы». Эти и иные проектные решения при их внедрении обеспечат достижение поставленных целей (о чем опять-таки свидетельствует практика). Для реализации поставленных в проекте целей требуется решить ряд задач, которые можно рассматривать как подцели основной цели. Они, в свою очередь, разбиваются на более мелкие подцели. Например, подцель (как процесс) «Определение информационной архитектуры системы» в проекте ИС можно разбить на работы: · создание и ведение корпоративной информационной модели, · создание и ведение корпоративных справочников нормативно-справочной информации (НСИ), · разработка и ведение схемы классификации данных, · обеспечение владельцев данных процедурами и инструментами для классификации информационных потоков в системе, · применение информационной модели, справочников НСИ и схемы классификации для оптимизации бизнес-процессов в системе. В итоге реализация проекта обычно предполагает комплекс взаимосвязанных целей и их подцелей, составляющих отдельные работы. Содержание работ в ИТ-проекте зависит от множества факторов: от цели проекта, используемых программных и технических средств, сферы внедрения и т. д. и определяется принятой методологией создания ИТ-решения. Особенности проектов информационных систем Важными являются также следующие аспекты управления разработкой ИТ-проектов, отмеченные, в частности, в [1]. Сфера ИТ, в которой реализуются проекты больших информационных систем (ИС), порождает специфические особенности их исполнения: · проблема эффективных коммуникаций между заказчиком и исполнителем проекта. Заказчиком, как правило, является бизнес, а исполнителем — ИТ-специалисты, и есть трудности в выявлении и согласовании требований, ожиданий от проекта, в формировании технического задания; · солидарная ответственность заказчика и исполнителя за результат проекта. В ИТпроекте должны создаваться условия для взаимодействия сторон, и стороны, участвующие в нем, несут равную ответственность за результаты проекта; · тесное переплетение ИТ-процессов и бизнес-процессов; зачастую реализация ИТпроекта предусматривает частичную или полную реорганизацию структуры предприятия и изменение технологии ведения бизнеса; · вовлечение в ИТ-проект множества подразделений организации, имеющих собственные интересы и представления о целях и задачах проекта; как следствие, существует высокая вероятность конфликтов между ними и проектной командой; · масштабность ИТ-проектов; в крупных компаниях масштабы проектной деятельности в области ИТ измеряются миллионами долларов, и реализация новых проектов происходит постоянно — развитие ИТ-инфраструктуры в растущих компаниях требует больших и регулярных вложений. Масштабность, в свою очередь, подразумевает высокий уровень ответственности и соответственно повышенные требования к компетенции тех людей, которые этими проектами управляют; · высокая степень изменчивости: по мере реализации проектов уточняются и корректируются требования к содержанию проектов. Принятие решений в таких проектах характеризуется высокими рисками, что требует от руководителя глубоких знаний методики проектного управления и понимания особенностей ее применения в сфере ИТ. Управление проектом · Чаще всего на практике используется подход к управлению проектами с учетом проблемы ограничений. · Известный закон Лермана гласит: "Любую техническую проблему можно преодолеть, имея достаточно времени и денег", а следствие Лермана уточняет: "Вам никогда не будет хватать либо времени, либо денег". Именно для преодоления сформулированной в следствии Лермана проблемы и была разработана методика управления деятельностью на основе проекта. А распространение данной методики управления на различные сферы деятельности является дополнительным доказательством ее эффективности. Если попросить менеджера описать, как он понимает свою основную задачу в выполнении проекта, то скорее всего он ответит:"Обеспечить выполнение работ". Это действительно главная задача руководителя. Но если задать тот же вопрос более опытному менеджеру, то можно услышать и более полное определение главной задачи менеджера проекта: "Обеспечить выполнение работ в срок, в рамках выделенных средств, в соответствии с техническим заданием". Именно эти три момента: время, бюджет и качество работ находятся под постоянным вниманием руководителя проекта. Их также можно назвать основными ограничениями, накладываемыми на проект. · Под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, денежным средствам (и ресурсам), а также качеству конечных результатов проекта (документированных, например, в техническом задании). · За тридцать с лишним лет, в течении которых применяется технология управления проектами, был разработан целый ряд методик и инструментов, призванных помочь руководителям проектов управлять этими ограничениями. · Для того, чтобы справиться с ограничениями по времени используются методы построения и контроля календарных графиков работ. Для управления денежными ограничениями используются методы формирования финансового плана (бюджета) проекта и, по мере выполнения работ, соблюдение бюджета отслеживается, с тем, чтобы не дать затратам выйти из-под контроля. Для выполнения работ требуется их ресурсное обеспечение и существуют специальные методы управления человеческими и материальными ресурсами (например, матрица ответственности, диаграммы загрузки ресурсов). Из трех основных ограничений труднее всего контролировать ограничения по заданным результатам проекта. Проблема заключается в том, что задания часто трудно и формулировать, и контролировать. Для решения данных проблем используются, в частности, методы управления качеством работ. Итак, руководители ИТ-проектов прежде всего отвечают за три аспекта реализации проекта: · сроки, · расходы, · качество результата. В соответствии с общепринятым принципом управления проектами, считается, что эффективное управление сроками работ является ключом к успеху по всем трем показателям. Временные ограничения проекта часто являются наиболее критичными. Там, где сроки выполнения проекта серьезно затягиваются, весьма вероятными последствиями являются перерасход средств и недостаточно высокое качество работ. Поэтому, в большинстве методов управления проектами основной акцент делается на календарном планировании работ и контроле соблюдения календарного графика. Исчерпывающее описание процесса управления ИТ-проектами приводит В.П. Грекул, который обобщил в своей работе [1] собственный опыт разработки внедренных проектов. При этом управлении проектами предлагается обращать внимание на этапы работы: · определить методологию управления проектами / программами для ИТинвестиций; · создать и поддерживать методологию управления ИТ-проектами; · организовать и вести мониторинг ИТ-проектов, измерений и системы управления; · создать описание проектов, план-графиков, планов качества, бюджетов, планов информирования и управления рисками; · обеспечить участие заинтересованных сторон проекта; · осуществлять эффективный контроль над проектами и внесениями изменений в проекты; · определить и реализовать методы анализа результатов проекта. С целью структурирования процессы управления проектом принято делить на области знаний. Ниже перечислены области знаний, составляющие процессы проектного управления. Предложенный перечень сформирован на основе рекомендаций лучших мировых практик [1] и содержится в стандарте управления проектами: · · · · · · · · · управление интеграцией; управление содержанием; управление сроками; управление стоимостью; управление качеством; управление рисками; управление человеческими ресурсами; управление коммуникациями; управление конфигурацией. Названные вопросы подробно будут рассмотрены в изучаемой дисциплине, а также в дисциплине «Технология командной разработки программного обеспечения». Описание содержания основных из перечисленных областей знаний и соответствующих им процессов приводится в нижеследующих главах. Подробное описание приведено в [1, 2]. Литература по теме 1 1 Грекул В. И. Проектное управление в сфере информационных технологий [Электронный ресурс] / В. И. Грекул, Н. В. Коровкина, Ю. В. Куприянов. — Эл. изд. — М. : БИНОМ. Лаборатория знаний, 2013. — 336 с. : ил. — (Проекты, программы, портфели). 2 Основы экономики программной инженерии и управления проектами — Астахова А.В. (ПМ): Учебник. Ред. 3. Ч.1/ Составитель А.В. Астахова — На правах рукописи — Барнаул: ЭОС АлтГТУ. —Дата первичного размещения: 30.08.2020 — // http://lms.altstu.ru/ilias/ 3 Введение в проектный менеджмент / https://hr-portal.ru/article/vvedenie-v-proektnyymenedzhment (обращение 28.08.2020) 2 Модели СПУ как инструмент управления IT-проектом 2.1 Задача планирования комплекса работ Как следует из главы 1, для ИТ-проекта характерным является то, что он состоит из ряда отдельных, элементарных работ или «звеньев», которые не просто выполняются независимо друг от друга, а взаимно обусловливают друг друга, так что выполнение некоторых работ не может быть начато раньше, чем завершены некоторые другие. Планирование любого такого комплекса работ должно производиться с учетом следующих существенных элементов: — времени, требующегося на выполнение всего комплекса работ и его отдельных звеньев; — стоимости всего комплекса работ и его отдельных звеньев; — материальных, людских (трудовых) и прочих ресурсов. Рациональное планирование комплекса работ требует, в частности, ответа на следующие вопросы: — Как распределить имеющиеся материальные средства и трудовые ресурсы между звеньями комплекса? — В какие моменты начинать и когда заканчивать отдельные работы? — Какие могут возникнуть препятствия к своевременному завершению комплекса работ и как их устранять? и т. д. При планировании сравнительно небольших по объему (количеству звеньев) комплексов работ ответ на такие вопросы обычно дает руководитель проекта, причем без специальных математических расчетов, просто на основе опыта и здравого смысла. Однако, когда речь идет об очень сложных, дорогостоящих комплексах работ, состоящих из большого числа звеньев, сложным образом обусловливающих друг друга, такие приемы становятся недопустимыми. В этих случаях возникает необходимость в специальных расчетах, позволяющих обоснованно ответить на поставленные выше вопросы и ряд других. Одним из математических методов, широко применяемых при решении такого рода задач, является метод сетевого планирования или, как его часто называют, СПУ (сетевое планирование и управление). Метод сетевого планирования и управления (СПУ) представляет собой логикоматематический метод решения задач рационального планирования сложного комплекса взаимосвязанных работ по выполнению каких-либо программ и проектов. В определении, данном ниже, расшифровывается аббревиатура СПУ. СПУ – это система сетевого (С) планирования (П) и управления– это совокупность научно обоснованных положений планирования, анализа и регулирования (управления в узком смысле этого слова: У) производственных процессов по разработке проекта. Система основана на моделировании этих процессов с помощью сетевого графика с использованием теории графов, теории вероятностей и информационных технологий. Метод сетевого планирования позволяет решать как прямые, так и обратные задачи. Прямые задачи отвечают на вопрос: что будет, если мы примем данную схему организации выполнения работ по проекту? Обратные – отвечают на вопрос: как нужно организовать (спланировать) работы проекта, чтобы он обладал, в каком-то смысле, максимальной эффективностью? Например, чтобы уменьшить длительность выполнения всех работ или найти резервы и высвободить трудовые и иные ресурсы, или уменьшить (увеличить) внешние инвестиции в проект. Основной информацией для сетевого планирования является список или перечень работ (звеньев) комплекса, в котором указаны не только работы, но и их взаимная обусловленность (окончание каких работ требуется для начала выполнения каждой работы). Будем называть такой список структурной таблицей комплекса работ. Работы в таблицу заносятся не всегда с учетом их упорядоченности и связи друг с другом, таблица формируется не в один этап и может уточняться в процессе ее формирования. На практике пользуются наименованиями работ, их шифрами (в соответствие с некоторой системой классификации и кодирования информации), но при построении соответствующей математической модели и нахождении ее искомых параметров удобно использовать индексы. В следующих параграфах рассмотрим модели и алгоритмы СПУ. Литература по теме 2 2 Сетевое планирование / http://upr-proektom.ru/setevoe-planirovanie (обращение 28.08.2020 г.)