Руководство проектированием программного обеспечения

Лекция №1 Цели и задачи дисциплины. Требования к результатам освоения дисциплины. Содержание дисциплины по модулям. Методологии разработки программного обеспечения. Процессы инициации проекта. Разработка Устава проекта. Анализ заинтересованных сторон. Цели и задачи дисциплины Цель изучения дисциплины «Руководство проектированием программного обеспечения» – снабдить будущего выпускника знаниями об основных нормативно-технических документах и практиках управления процессом разработки программного продукта, о методах оценки качества разработки программного продукта в ходе проектной и производственнотехнологической деятельности в области профессиональной деятельности «06 Связь, информационные и коммуникационные технологии» согласно профессиональным стандартам: – «06.017 Руководитель разработки программного обеспечения»; Основные задачи дисциплины: 1) изучение этапов и процессов подготовки и запуска проекта разработки программного продукта; 2) освоение методик управления различными аспектами проектной деятельности; 3) знакомство с вопросами, связанными с подбором и управлением команды разработки программного продукта. Требования к результатам освоения дисциплины В результате освоения дисциплины «Руководство проектированием программного обеспечения» должны быть сформированы следующие компетенции и обучающийся должен демонстрировать освоение указанными компетенциями по дескрипторам «знания, умения, владения», соответствующие тематическим модулям дисциплины, и применимые в их последующем обучении и профессиональной деятельности, таблица 2. Таблица 1 – Компетенции, сформированные в ходе изучения дисциплины РП ПО Код Код компетенции индикатора Проектируемые результаты освоения дисциплины Направление 09.04.01 ПК-1: способен руководить процессами разработки программного обеспечения. Знать: нормативно-технические документы, ИД-4ПК-1 – руопределяющие требования к проектной доководит и ведёт кументации. разработку проУметь: применять нормативно-технические ектной и технидокументы, определяющие требования к ческой докупроектной документации. ментации. Владеть: инициированием разработки про- ПК-2: способен руководить процессами проектирования программного обеспечения. ектной и технической документации. Знать: нормативно-технические документы по процессу разработки архитектуры проИД-8ПК-1 – осуграммного обеспечения. ществляет руУметь: применять нормативно-технические ководство продокументы по процессу разработки архитекектированием туры программного обеспечения. программного Владеть: оценкой качества проектирования обеспечения. программного обеспечения, структуры базы данных, программных интерфейсов. Знать: методы и средства сборки модулей и компонентов программного обеспечения; методы и программные интерфейсы взаимодействия с внешними программными компонентами; методы проектирования и разработки программных интерфейсов взаИД-3ПК-2 – про- имодействия внутренних модулей системы. ектирует слож- Уметь: Применять методы и средства сборные интегриру- ки модулей и компонентов программного емые про- обеспечения, разработки процедур для разграммные ком- вертывания программного обеспечения, миплексы. грации и преобразования данных, создания программных интерфейсов. Владеть: оценкой результатов выполнения заданий на разработку процедур интеграции, сборку, подключение к внешней среде, проверку работоспособности выпусков программного продукта. Знать: правила редактирования научнотехнической документации. ИД-4ПК-2 – веУметь: применять коллективную среду додет разработку кументирования программного обеспечепроектной и ния. технической Владеть: контролем и оценкой качества документации. разработанной проектной и технической документации. Знать: принципы построения архитектуры программного обеспечения и вида архитекИД-8ПК-2 – платур программного обеспечения. нирует этапы Уметь: применять принципы построения проекта разраархитектуры программного обеспечения и ботки провиды архитектур программного обеспечеграммного ния. обеспечения. Владеть: анализом архитектуры программного обеспечения. Содержание дисциплины по разделам и видам учебных занятий Содержание дисциплины по разделам 1. Основные этапы проекта разработки ПО. 2. Процессы управления проектом разработки ПО. 3. Команда проекта разработки ПО. Таблица 2 – Содержание разделов дисциплины Содержание разделов Раздел 1. Основные этапы проекта разработки ПО. Цели и задачи дисциплины. Требования к результатам освоения дисциплины. Содержание дисциплины по модулям. Методологии разработки программного обеспечения. Процессы инициации проекта. Разработка Устава проекта. Анализ заинтересованных сторон. Процессы планирования проекта. Разработка бюджета проекта. Разработка календарного плана. Оформление проекта. Основные этапы разработки программного обеспечения: сбор требований, проектирование и разработка, тестирование. Раздел 2. Процессы управления проектом разработки ПО. Способы оценки трудозатрат. Конус неопределенности. Процессы управления проектом. Типы процессов. Классификация процессов. Классификация областей знаний. Управление интеграцией проекта. Управление содержанием проекта. Управление расписанием проекта. Управление стоимостью проекта. Управление качеством. Управление ресурсами и коммуникациями. Планирование проектов. Инструменты планирования. Анализ рисков. S.M.A.R.T. Инструменты управления содержанием проекта. Раздел 3. Команда проекта разработки ПО. Команда разработки проекта. Типы проектных команд. Уровни принятия решений в проекте. Цели участников команды и окружения. Создание и развитие команды. Стадии существования команды. Культура команды проекта. Оценка деятельности команды проекта. Критерии эффективности команды. Содержание практических занятий Цель практических занятий: закрепление теоретического материала дисциплины, освоение методов решения практических задач в ходе занятий. Совместно, лекционный курс и практические занятия дадут магистранту знания об основных методиках и процессах инициации, планирования, управления проекта; о вопросах, связанных с формированием команды разработки программного продукта. Таблица 3 – Содержание практических занятий по дисциплине Содержание курса практических занятий Раздел 1. Основные этапы проекта разработки ПО. Практическое занятие 1: «Инициация и разработка Устава проекта» Практическое занятие 2: «Разработка бюджета и календарного плана проекта.» Раздел 2. Процессы управления проектом разработки ПО. Практическое занятие 3: «Оценка трудозатрат и неопределённостей при процессах управления проектом» Практическое занятие 4: «Управление интеграцией проекта» Практическое занятие 5: «Управление содержанием проекта» Практическое занятие 6: «Управление расписанием проекта» Практическое занятие 7: «Управление стоимостью проекта» Практическое занятие 8: «Управление качеством» Практическое занятие 9: «Использование инструментов планирования» Методологии разработки программного обеспечения Постараемся рассмотреть их через призму термина проект. Проект — это временное предприятие, направленное на создание уникального продукта, услуги или результата. Временный характер проектов указывает:  на факт протяжённости проекта во времени;  на наличие определенного начала и окончания. Программа проектов – это набор взаимосвязанных проектов, управление которыми координируется для достижения преимуществ и степени управляемости, недостижимых при управлении ими по отдельности. Портфель проектов – это набор проектов (или программ проектов), объединённых для достижения более эффективного управления. Управление проектом представляет собой ряд процессов, как правило, включает в себя, среди прочего:  выявление требований к проекту;  реагирование на различные потребности, затруднения и ожидания заинтересованных сторон;  установление и поддержание активных коммуникаций с заинтересованными сторонами;  управление ресурсами;  уравновешивание конкурирующих ограничений проекта, которые включают в себя, среди прочего: o содержание, o расписание, o стоимость, o качество, o ресурсы, o pиск. Условия конкретного проекта влияют на то, как реализуется каждый процесс управления проектом, а также как приоритезируются ограничения проекта. Группа процессов управления проектом — это логическое объединение процессов управления проектом с целью достижения конкретных целей проекта. Группы процессов являются независимыми от фаз проекта. Процессы управления проектом сгруппированы в следующие пять групп процессов управления проектом:  Группа процессов инициации. Процессы, выполняемые для определения нового проекта или новой фазы существующего проекта путем получения авторизации на начало проекта или фазы.  Группа процессов планирования. Процессы, требуемые для установления содержания работ, уточнения целей и определения направления действий, требуемых для достижения целей проекта.  Группа процессов исполнения. Процессы, выполняемые для исполнения работ, указанных в плане управления проектом, с целью соответствия требованиям проекта.  Группа процессов мониторинга и контроля. Процессы, требуемые для отслеживания, анализа, а также регулирования исполнения проекта; выявления областей, требующих внесения изменений в план; и инициирования соответствующих изменений.  Группа процессов закрытия. Это процессы, выполняемые для формального завершения или закрытия проекта, фазы или договора. Фаза проекта – совокупность логически связанных операций проекта, завершающихся достижением одного или ряда поставляемых результатов. Жизненный цикл проекта — это набор фаз, через которые проходит проект с момента его начала до момента завершения. Он определяет основные рамки управления проектом. Данные основные рамки действуют вне зависимости от особенностей конкретных работ по осуществлению проекта. Фазы проекта могут быть последовательными, итеративными или накладываться друг на друга. Жизненные циклы проекта могут быть предиктивными или адаптивными. В рамках жизненного цикла проекта обычно выделяется одна или более фаз, которые связаны с разработкой продукта, услуги или результата. Их называют «жизненный цикл развития». Жизненные циклы развития могут быть предиктивного, итеративного, инкрементного, адаптивного или смешанного типа.  В случае предиктивного жизненного цикла содержание, сроки и стоимость проекта определяются на начальных фазах жизненного цикла. Любые изменения содержания требуют тщательного управления. Предиктивные жизненные циклы могут также называться жизненными циклами типа водопада.  В случае итеративного жизненного цикла содержание проекта обычно определяется на начальной стадии жизненного цикла проекта, однако оценки сроков и стоимости проекта меняются в рабочем порядке по мере расширения понимания продукта командой проекта. Итеративность определяет разработку продукта путем выполнения ряда повторяющихся циклов, в то время как инкрементность определяет последовательное наращивание функциональности продукта.  В случае инкрементного жизненного цикла проекта поставляемый результат производится путем выполнения ряда итераций, которые последовательно наращивают функциональность в рамках заданного временного интервала. Поставляемый результат содержит такие необходимые и достаточные характеристики, чтобы считаться полным только после заключительной итерации.  Адаптивные жизненные циклы являются гибкими (agile), итеративными или инкрементными. Подробное содержание определяется и одобряется перед началом каждой итерации. Адаптивные жизненные циклы называют также «гибкими» (agile) или жизненными циклами, управляемыми изменениями.  Смешанный жизненный цикл представляет собой сочетание предиктивного и адаптивного жизненного цикла. Те элементы проекта, которые хорошо изучены или имеют заранее установленные требования, осуществляются по предиктивному жизненному циклу развития, а те, которые находятся в состоянии формирования — по адаптивному жизненному циклу развития. Наилучший тип жизненного цикла для каждого проекта определяет команда управления проектом. Жизненный цикл проекта должен обладать достаточной гибкостью, чтобы его можно было изменять с учетом различных факторов, включенных в проект. Гибкость жизненного цикла может быть обеспечена путем:  определения процесса или процессов, осуществление которых необходимо в каждой фазе;  осуществления процесса или процессов, определенных для каждой фазы;  корректировки различных качеств фазы (например, название, длительность, критерии выхода и критерии входа). Жизненные циклы проекта существуют независимо от жизненных циклов продукта, который может быть произведен в результате проекта. Жизненный цикл продукта — это набор фаз, которые представляют эволюцию продукта, от концепции через поставку, рост, зрелость и до изъятия из обращения. Таким образом, жизненные циклы проекта и программного продукта могут пересекаться лишь в единственном случае, когда создание программного продукта и является целью проекта. Процессы инициации проекта Инициация проекта – группа процессов управления проектом, результатом которых является формальная авторизация и санкционирование начала проекта или очередной фазы его жизненного цикла. Цель группы процессов инициации — привести в соответствие ожидания заинтересованных сторон и цель проекта, проинформировать заинтересованные стороны о содержании проекта и его целях, а также обсудить с ними, каким образом их участие в проекте и связанных с ним фазах может помочь обеспечить удовлетворение их ожиданий. Инициация проекта может включать следующие процедуры:  Разработка концепции проекта: o анализ проблемы и потребности в проекте; o сбор исходных данных; o определение целей и задач проекта; o рассмотрение альтернативных вариантов проекта.  Рассмотрение и утверждение разработанной концепции.  Принятие решения о начале проекта: o определение и назначение менеджера проекта; o принятие решения об обеспечении ресурсами выполнения первой фазы проекта. С точки зрения руководителя проекта именно на этапе инициации он отвечает себе на вопрос, можно ли этот проект сделать в рамках имеющих ограничений по времени, деньгам, ресурсам и проч.? Если уже сейчас понятно, что нельзя, то самое время с цифрами в руках объяснить, почему нельзя. Разработка Устава проекта Разработка устава проекта — процесс разработки документа, который формально авторизует существование проекта и предоставляет руководителю проекта полномочия использовать ресурсы организации в операциях проекта. Ключевая выгода от этого процесса состоит в том, что он обеспечивает связь между проектом и стратегическими целями организации, позволяет документально оформить проект и показывает обязательство организации в отношении проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте. Рис. 1. Разработка устава проекта: входы и выходы Как правило, разработка и подписание Устава несет в себе 3 основные функции:  Определить основные требования к результату проекта и основные характеристики самого проекта (бюджет, сроки).  Формально запустить проект, т. к. только после подписания проект считается действительно существующим в Компании.  Наделить руководителя проекта определенным уровнем полномочий (каким именно – зависит от Компании). Так же иногда устав проекта используется для оценки выгод от его реализации и принятия решения о запуске. Входы Бизнес-кейс и план управления выгодами проекта содержат в себе информацию о причинах инициации, целях и выгодах проекта. Соглашения – чаще всего это договоры, имеющие отношение к проекту. Факторы среды предприятия — это условия, не находящиеся под непосредственным контролем команды проекта, которые влияют на проект, ограничивают или направляют его. Они включают в себя, среди прочего:  государственные или промышленные стандарты (например, стандарты на продукты, стандарты качества, правила техники безопасности и производственные стандарты);  юридические или регуляторные требования и/или ограничения;  ситуацию на рынке;  культуру организации и политический климат;  модель руководства организации;  ожидания заинтересованных сторон и пороги риска. Активы процессов предприятия, которые могут оказывать влияние на процесс разработки устава проекта, включают в себя, среди прочего:  стандартные политики, процессы и процедуры организации;  модель руководства портфелем, программой и проектом;  методы мониторинга и отчетности;  шаблоны, стандарты, регламенты;  хранилище исторической информации и извлеченных уроков (например, записи и документы проекта, информация о результатах решений по отбору предыдущих проектов и информация об исполнении предыдущих проектов). Инструменты и методы Экспертная оценка – это заключение, вынесенное на основании компетентности в прикладной области, области знаний, сфере деятельности, отрасли и т. д., соответствующих осуществляемой деятельности. Экспертное заключение могут давать как группы, так и отдельные лица, имеющие специальное образование, знания, навыки, опыт или подготовку. Методы сбора исходных данных: Мозговой штурм. Этот метод применяется для составления в короткий срок перечня идей. Он осуществляется в коллективной среде и под руководством модератора. Мозговой штурм состоит из двух частей: сбор идей и их анализ. Мозговой штурм при разработке устава проекта можно применять для сбора данных, решений или идей от заинтересованных сторон, экспертов по предметным областям и членов команды. Фокус-группы. Фокус-группы объединяют в своем составе заинтересованные стороны и экспертов по предметным областям для изучения предполагаемых рисков, критериев успеха и других тем в форме диалога с более широким составом участников, чем при индивидуальных интервью. Интервью. Интервью применяются для получения информации по высокоуровневым требованиям, допущениям или ограничениям, критериям одобрения и другой информации от заинтересованных сторон путем прямого диалога с ними. Навыки межличностных отношений и работы с командой: Управление конфликтами. Навык управления конфликтами может потребоваться для достижения согласованного понимания заинтересованными сторонами целей, критериев успеха, высокоуровневых требований, описания проекта, укрупненных контрольных событий и других элементов устава. Фасилитация (англ. facilitate – помогать, облегчать, способствовать). Это способность обеспечить результативную работу группового мероприятия с успешной выработкой в итоге решения, предложения или заключения. В задачи модератора входит обеспечение результативного участия, достижение общего понимания, рассмотрение всех предложенных соображений, общее согласие с заключениями или результатами в рамках установленного в проекте процесса принятия решений, а также принятие надлежащих мер в отношении согласованных действий и соглашений в последующем. Управление совещаниями. Управление совещаниями состоит в подготовке повестки дня, обеспечении приглашения представителей всех ключевых групп заинтересованных сторон, а также в подготовке и рассылке итоговых протоколов и информации о действиях по результатам мероприятия. В рамках этого процесса совещания с заинтересованными сторонами проводятся с целью определения целей проекта, критериев успеха, ключевых поставляемых результатов, высокоуровневых требований, укрупненных контрольных событий и другой сводной информации. Выходы Устав проекта — это документ, выпущенный инициатором или спонсором проекта. Он документально оформляет высокоуровневую информацию, относящуюся к проекту, продукту, услуге или результату, для получения которых предназначен данный проект, в том числе такую, как:  назначение проекта – часто содержит в себе начальные условия, описание причин инициации проекта;  измеримые цели проекта и соответствующие критерии успеха – именно эта информация позволит оценить успешность/неуспешность проекта (см. ниже), и потому желательно, что бы она была измеримой и не допускать двойного толкования;  высокоуровневые описания, границы и ключевые поставляемые результаты проекта – отвечает на вопрос, что будет сделано;  высокоуровневые требования – это то, что не является содержанием проекта, но важно для него;  совокупный риск проекта – основная цель пункта, донести до всех заинтересованных лиц особенности того окружения и того момента, в которых вы делаете проект, озвучить свои опасения и получить подтверждение их готовности в этих вопросах вам всячески помогать;  укрупненное расписание контрольных событий (дорожная карта, roadmap) – чаще всего у событий имеются даты или сроки;  заранее утвержденные финансовые ресурсы – бюджет проекта;  список основных заинтересованных сторон;  требования к одобрению проекта (т. е. что именно составляет успех проекта, кто решает, что проект оказался успешным, и кто подписывает решение об окончании проекта);  критерии выхода из проекта (т. е. какие условия должны быть выполнены, чтобы проект или его фаза были закрыты или отменены);  назначенный руководитель проекта, сфера ответственности и уровень полномочий;  Ф.И.О. и полномочия спонсора или другого лица (лиц), авторизующего (авторизующих) устав проекта. На высоком уровне устав проекта обеспечивает общее понимание заинтересованными сторонами ключевых поставляемых результатов, контрольных событий, а также ролей и сфер ответственности всех участвующих в осуществлении проекта лиц. Журнал допущений. Определение высокоуровневых стратегических и операционных допущений и ограничений обычно дается в бизнес-кейсе до инициации проекта, откуда они затем переносятся в устав проекта. Допущения низкого уровня для операций и задач, например, определение технических спецификаций, оценок, расписания, рисков и т. п., формируются на всем протяжении осуществления проекта. Журнал допущений используется для записи всех допущений и ограничений в течение всего жизненного цикла проекта. Анализ заинтересованных сторон Идентификация заинтересованных сторон — это процесс регулярного выявления заинтересованных сторон проекта, а также анализа и документирования значимой информации об их интересах, вовлечении, взаимозависимости, влиянии и потенциальном воздействии на успех проекта. Ключевая выгода данного процесса состоит в том, что он дает команде проекта возможность определять соответствующий фокус для привлечения каждой заинтересованной стороны или группы заинтересованных сторон. Этот процесс по мере необходимости периодически осуществляется в ходе проекта. Рис. 2. Идентификация заинтересованных сторон: входы, инструменты и методы, выходы Часто этот процесс первый раз встречается в проекте либо перед разработкой и одобрением устава проекта, либо одновременно с этим. Он повторяется по мере необходимости, но должен выполняться в начале каждой фазы, а также каждый раз, когда в проекте или в организации происходят существенные изменения. Анализ заинтересованных сторон. Результатом анализа заинтересованных сторон является список заинтересованных сторон и относящейся к ним информации, такой как их должности в организации, роли в проекте, «ставки», ожидания, отношение (уровень поддержки проекта) и их интерес в информации о проекте. Ставки заинтересованных сторон могут включать в себя, среди прочего, сочетание следующих составляющих:  Интерес. То или иное решение по проекту или его конечный результат могут оказать влияние на отдельных лиц и группы лиц.  Права (юридические или моральные). Юридические права, такие, как право на охрану здоровья и безопасность, могут быть определены в законодательстве страны. Моральные права могут состоять в представлениях об охране исторических объектов или окружающей среды.  Собственность. Лицо или группа лиц имеют юридическое право на активы или имущество.  Знания. Специальные знания, которые могут принести пользу проекту благодаря более результативному достижению целей проекта, конечным результатам организации или знанию о распределении полномочий в организации.  Вклад. Выделение финансовых средств или других ресурсов, включая человеческие, или оказание поддержки в пользу проекта в менее осязаемой форме, например, путем защиты проекта в форме поддержки целей проекта или выполнение функции буфера между проектом и органами управления организации и ее политик. Метод отображения данных, который может использоваться в данном процессе, включает, среди прочего, графическое сопоставление и/или представление заинтересованных сторон. Цель метода – распределение по категориям с использованием различных подходов. Общепринятые методы включают в себя:  Матрица власти /интересов, матрица власти /влияния или матрица воздействия /влияния. Каждый из этих методов используется для группирования заинтересованных сторон на основе уровня их полномочий (власть), уровня заинтересованности в конечном результате проекта (интерес), способности оказать влияние на конечный результат проекта (влияние) или способности вызывать изменения в планировании или исполнении проекта. Данные модели классификации могут использоваться для небольших проектов или проектов с простыми взаимоотношениями между заинтересованными сторонами и проектом или в самом сообществе заинтересованных сторон.  Куб заинтересованных сторон. Эта модель является уточнением описанных выше матричных моделей. Она объединяет матричные элементы в трехмерную модель, которая может помочь руководителю и команде проекта в решении задач идентификации и вовлечения сообщества заинтересованных сторон своего проекта. Ее результатом является многомерная модель, которая улучшает наглядное представление сообщества заинтересованных сторон, изображая его в виде многомерного объекта, а также помогает в разработке стратегий коммуникаций.  Модель особенностей. Описывает классы заинтересованных сторон на основе оценки их уровня власти (уровень полномочий или способности влиять на конечный результат проекта), срочности (необходимость в незамедлительном внимании по причине как временных ограничений, так и высоких ставок заинтересованных сторон в конечном результате) и легитимности (уместность их вовлечения). Имеется адаптация модели особенностей, в которой близость заменяется легитимностью (применяется к команде и измеряет уровень участия ее членов в работах по проекту). Модель особенностей наиболее полезна при применении к большим и сложным сообществам заинтересованных сторон или в случаях, когда в сообществе существуют сложные сети взаимоотношений. Она также полезна при определении относительной важности идентифицированных заинтересованных сторон.  Направления влияния. Классифицирует заинтересованные стороны с учетом их влияния на работы по проекту или на саму команду проекта. Заинтересованные стороны могут быть классифицированы следующим образом: o снизу вверх (высшее руководство исполняющей организации или организации-клиента, спонсоры и управляющий комитет); o сверху вниз (команда или специалисты, вносящие вклад знаниями или навыками в качестве временных сотрудников); o наружу (группы заинтересованных сторон и их представители, не входящие в состав команды проекта, такие как поставщики, государственные органы, общественность, конечные пользователи и регулирующие органы); o в стороны (занимающие равное положение коллеги руководителя проекта, такие как руководители других проектов или руководители среднего звена, которые претендуют на ограниченные ресурсы проекта или сотрудничают с руководителем проекта в совместном использовании ресурсов или информации).  Приоритезация. Приоритезация заинтересованных сторон может быть необходима в проектах с большим числом заинтересованных сторон, когда в составе их сообщества часто происходят изменения, или когда взаимоотношения между заинтересованными сторонами и командой проекта или внутри сообщества заинтересованных сторон имеют сложный характер. Источники: 1. Сайт «Управление проектами» – https://upravlenie-proektami.ru 2. Руководство к своду знаний по управлению проектом (Руководство PMBOK)