Полномочия по принятию или отклонению предлагаемых изменений обычно возлагаются на <организационную> сущность, называемую совет по конфигурационному контролю - Configuration Control Board (чаще звучит как совет по координации изменений - Change Control Board, CCB). В небольших проектах такие полномочия могут, в действительности, принадлежать лидеру или одному назначенному лицу из числа членов проектной команды. Решения о том, кто именно будет включен в CCB для данной системы (проекта) могут варьироваться, в зависимости от данных критериев. Однако, в CCB всегда должно присутствовать лицо, вовлеченное в организацию конфигурационного управления. В CCB входят все заинтересованные лица, чья роль соответствует уровню CCB. Когда содержание полномочий CCB охватывает только аспекты программного обеспечения, такой совет называется Software Configuration (Change) Control Board – SCCB. Деятельность CCB обычно является объектом аудита качества или оценки.
Учитывая роль управления изменениями в конфигурационном управлении и реальные задачи CCB, более обоснованным выглядит использование именно названия Change Coordination & Control Board – в общем случае звучащий как совет по координации и контролю изменений.
8.3.1.2 Процесс обработки запросов на изменения
(Software change request process)
Эффективный процесс <обработки> запросов на изменения (SCR process) требует использования соответствующих средств поддержки и процедур <для данного вида деятельности>, от “бумажных” форм и документированных процедур (как последовательности действий или сценариев) до программных инструментов, позволяющих отсылать запросы на изменения, выполнять процесс обработки таких запросов (изменять их статус, комментировать, детализировать и т.п.), фиксировать решения, принятые CCB, а также генерировать отчетную информацию по процессу обработки запросов на изменения. Связь между этими средствами и инструментами обработки отчетов об ошибках может существенно облегчить определение решений для обнаруженных проблем.
Обработка различных типов запросов на изменения в отношении разрабатываемых или модифицируемых программных систем, будь то сообщения о проблемах (defect report) или запросы на расширение функциональности (enchancement request), даже при разных процессах принятия решений в отношении их, должны быть объединены в единую систему (в единой базой данных), являющуюся составной и неотъемлемой частью единой среды конфигурационного управления. Только в этом случае можно обеспечить однозначную и актуальную связь между запросами различных типов и другими активами проекта (кодом, документацией, проектными моделями, задачами, ресурсами и т.п.), что позволяет не только получать актуальную информацию в любой момент времени, но и оперативно принимать те или иные (в том числе, управленческие) решения в отношении проекта, основываясь на максимально полном и корректном объеме информации.
8.3.2 Реализация изменений (Implementing Software Changes)
Принятые (утвержденные) запросы на изменения (SCR) реализуются используя определенные процедуры. Если набор утвержденных запросов на изменения может выполняться одновременно, необходимо обеспечить отслеживание того, какие именно SCR реализованы в конкретной версии программного продукта и базовой линии <конфигурации>. Составной частью процесса “закрытия” изменения, является аудит конфигурации и верификация качества программного обеспечения. Это обеспечивает гарантию того, что были внесены только утвержденные изменения.
Фактическая реализация изменений поддерживается инструментальными средствами, обеспечивающими управление версиями и поддержку <единого> репозитория кода.
Как минимум, эти инструменты должны поддерживать операции chek-in/check-out (помещение в репозиторий/ получение из репозитория) и ассоциированные возможности по контролю версий (например, отметка версии – labeling, сравнение – compare/diff, слияние – merge и т.п.). Более мощные инструменты могут поддерживать параллельную разработку (parallel development) и среду географически распределенной разработки (geographically distributed environment). Эти инструменты могут объявляться (в рамках организации) как отдельные специализированные приложения, целиком находящиеся под контролем независимой SCM-группы (как самостоятельной/выделенной организационной сущности).
8.4 Учет статусов конфигураций
(Software Configuration Status Accounting)
Учет статусов программных конфигураций (Software Configuration Status Accounting, SCSA) подразумевает сохранение (recording) и генерацию отчетности (reporting) для всей информации, необходимой для эффективного управления конфигурациями программного обеспечения.
8.4.1 Информация о статусе конфигураций (Software Configuration Status Information)
Деятельность по учету статуса конфигураций (SCSA) предназначена и выполняется для получения (и генерации отчетов) информации, необходимой для осуществления процессов жизненного цикла системы. Как и в любой информационной системе, информация о статусе конфигураций должна идентифицироваться, собираться и поддерживаться <в актуальном состоянии> по мере эволюции этих конфигураций. Различная информация и количественные показатели необходимы для поддержки процесса конфигурационного управления, а также для генерации отчетности (о статусе конфигураций), необходимой для управления, выполнения процессов программной инженерии и других связанных видов деятельности. Типы доступной информации обычно включают идентификацию утвержденных конфигураций, наравне с идентификацией и текущим статусом реализации изменений, отклонений и отказов от изменений. SWEBOK дает ссылки на источники, содержащие возможные (частные) списки важных информационных элементов.
Современные инструментальные средства SCM должны включать определенные формы поддержки сбора и данных и подготовки SCSA-отчетности. Это может быть реализовано на уровне обращения к соответствующим базам данных, может быть представлено и в виде самостоятельных приложений, а также являться функциональной составляющей более крупных интегрированных инструментальных средств.
Логично, что только такие интегрированные многофункциональные средства возможно считать полноценными SCM-инструментами, образующими категорию систем конфигурационного управления. В противном случае, мы говорим лишь об отдельно взятых (пусть и взаимодействующих, в той или иной степени) инструментах - “системе управления заявками на изменения” (change request submission), “системе сообщения и отслеживания дефектов” (defect-tracking), “системе контроля версий” (version control), “системе генерации отчетности” (configuration reporting) и т.п.
8.4.2 Отчетность по статусу конфигураций (Software Configuration Status Reporting)
Отчетная информация может быть использована различными организационными единицами или проектными группами, включая команду разработки, команду сопровождения, управляющих проектами и персоналом, обеспечивающим проверку качества. Отчетность может предоставляться в специальной форме, следуя специфическим запросам, но может генерироваться на постоянной основе (с определенной периодичностью) в соответствии с заданными шаблонами. Определенные элементы информации, получаемой в процессе деятельности по учету статуса конфигураций, может становиться составной частью данных, необходимых и используемых в работах по обеспечению качества (как продуктов, так и процессов).
В дополнение к отчетности по текущему статусу конфигураций, информация, получаемая в процессе SCSA-деятельности, может использоваться как основа для проведения различных количественных оценок в интересах управления, разработки или конфигурационного управления. Например, к такого рода данным относятся: количество запросов на изменения на один конфигурационный элемент; среднее время, необходимое для реализации запрошенных изменений <заданного типа>.
8.5 Аудит конфигураций (Software Configuration Auditing)
Аудит программного обеспечения – деятельность, выполняемая для независимой оценки программных продуктов и процессов на соответствие применимым в данном случае инструкциям, стандартам, руководящим документам, планам и процедурам. Аудиты проводятся в строгом соответствии с четко определенными процессами, содержащими и определяющими различные роли аудиторов и из обязанности. Каждый аудит должен быть, в свою очередь, четко спланирован и может требовать привлечения многих специалистов для выполнения различных задач (определяемых процедурой аудита) за достаточно короткий промежуток времени. Автоматизированные средства, обеспечивающие поддержку планирования и проведения аудита, могут существенно облегчить и ускорить этот процесс.
Деятельность по аудиту программных конфигураций определяет степень, в которой элемент конфигурации удовлетворяет заданным (например, на уровне требований и/или запросов на изменения) функциональным и физическим характеристикам. Неформальный аудит такого типа может быть связан с ключевыми точками жизненного цикла. Существует два достаточно распространенных типа формального: функциональный аудит конфигураций (Functional Configuration Audit, FCA) и физический аудит конфигураций (Physical Configuration Audit, PCA). Успешное завершение этих аудитов может быть обязательным требованиям для фиксирования базовой линии продукта. В то же время, если сравнивать контекст FCA и PCA для программного и аппаратного обеспечения, перед их выполнением необходимо четко оценивать реальные потребности в таких видах аудита (так как они требуют существенных, иногда, просто “неподъемных” затратах ресурсов).
8.6 Управление выпуском и поставкой
(Software Release Management and Delivery)
Термин “выпуск” (release) используется в данном контексте, подразумевая распространение и использование элементов конфигураций за рамками работ по разработке программного обеспечения. Это может включать как внутренние выпуски, так и выпуск и передачу программного обеспечения заказчикам. В ситуациях, когда доступны для поставки различные версии программных элементов (в частности, различные версии для разных платформ или редакции с различным набором функциональных возможностей), часто бывает необходимо создавать специализированные версии и пакеты (сборки) соответствующих материалов (элементов, активов) для выпуска в качестве <самостоятельной> версии.
8.6.1 Сборка программного обеспечения (Software Building)
Сборка (building) программного обеспечения – деятельность по комбинированию корректных версий элементов программных конфигураций, проводимая с использованием соответствующих конфигурационных данных, с целью получения исполняемой программы (программной системы) для передачи заказчику и/или другим получателям (например, выполняющим работы по тестированию).
Исполняемая программа для аппаратных и программно-аппаратных систем получается в результате деятельности по системной сборке (system building).
Инструкции по сборке предоставляют описание необходимых для сборки шагов, представленных в заданной (корректной) последовательности. Работы по сборке программного обеспечения выполняются не только для получения нового выпуска, но и для повторного создания предыдущих выпусков в целях их восстановления, тестирования, сопровождения или каких-либо других необходимых действий.
8.6.2 Управление выпуском программного обеспечения
(Software Release Management)
Управление выпуском (release management) программного обеспечения охватывает идентификацию, упаковку (сборку) и передачу элементов продукта, например, исполняемых программ, документации, аннотацию релиза (release note) и конфигурационные данные. Понимая, что изменения в продукте происходят постоянно, одной из задач управления выпуском продукта является определение момента времени, когда именно выпускать продукт (в этом контексте, управление выпуском может быть тесно связано как с деятельностью по обеспечению качества, так и с маркетинговыми соображениями в отношении выпускаемого продукта). На это решение также влияет серьезность проблем, решению которых адресуется релиз, и количественная оценка плотности сбоев (fault densities) в предыдущих релизах. Задача упаковки (packaging) состоит в идентификации того, какие элементы продукта должны быть выпущены (например, на основании функциональных требований и их трассировки на элементы конфигурации), и в последующем выборе корректных вариантов этих элементов, задаваемом аспектами применения продукта. Документирование информации о физическом содержании выпуска, обычно, включают в документ описания версии (version description document). В свою очередь, аннотация выпуска (release note) содержит информацию о новых возможностях, известных проблемах, а также требованиях к платформе(ам), которые необходимо соблюдать для предусмотренного режима эксплуатации продукта. Подготовленный к выпуску пакет (package) также включает инструкции по установке и обновлению <предыдущей версии>. Создание такой инструкции может быть осложнено тем, что некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем предыдущий выпущенный релиз. Наконец, в ряде случаев, деятельность по управлению выпуском может требовать отслеживание распространения (поставки) продукта различным заказчикам или в рамках заданных целевых систем. Например, возможны ситуации, когда поставщику требуется уведомить заказчика об обнаруженных проблемах.
9. Управление программной инженерией
4 часа
Управление программной инженерией может быть определено как приложение вопросов управления (management activities) – планирования, координации, количественной оценки, мониторинга, контроля и отчетности – к инженерной деятельности для систематического, упорядоченного и количественно измеряемого обеспечения разработки и сопровождения программных систем.
Таким образом, область знаний “Управление программной инженерией” определяет аспекты управления и количественной оценки в программной инженерии. Измерения являются важным аспектом для всех областей знаний программной инженерии, и соответствующая тема также включена и в описании данной области знаний.
В принципе, корректно утверждать, что возможно управлять программной инженерией так же, как и любым другим комплексным процессом. В то же время, существуют аспекты, специфичные для программных продуктов, а процессы жизненного цикла программных систем, в какой-то мере, усложняют достижение необходимого уровня эффективности управления. Среди таких усложняющих факторов:
· клиенты часто не знают, что им нужно, или что может быть осуществимо;
· восприятие клиентов (потребителей, заказчиков) таково, что часто отсутствует с их стороны понимание сложности, порожденной самой природой программной инженерии, в частности связанной с влиянием изменяющихся требований;
· клиенты часто недооценивают сложности, порожденной самой природой программной инженерии, в частности связанной с влиянием изменяющихся требований;
· вполне вероятно, что улучшение понимания и изменение условий будут создавать новые или изменять существующие требования.
· как результат часто изменяющихся требований ПО нередко создается с помощью итерационного процесса, а не в виде последовательно выполняющихся задач;
· разработка ПО обязательно включает в себя творчество и дисциплину. Поддержать надлежащий баланс между ними иногда сложно;
· степень новизны и сложности часто высокая;
· изменение базовых технологий часто имеет стремительный темп.
Что касается программной инженерии, управленческая деятельность в этой области происходит на трех уровнях:
Последние два уровня описаны в данной области знаний, что никак не принижает значимости общих вопросов управления организационными аспектами и инфраструктурой.
Хотя все области знаний тесно связаны с другими дисциплинами, связь данной области знаний с общими вопросами управления особенно важны, что и будет более подробно, в отличие от других областей знаний, представлено в ниже. Вопросы организационного управления важны с точки зрения влияния на программную инженерию, например, в контексте управления политиками/полномочиями сотрудников или других внутрикорпоративных стандартов, в рамках которых выполняется любая деятельность (например, с точки зрения отчетности по занятости сотрудников), в том числе - инженерная. Такие политики подвержены влиянию со стороны требований к организации эффективного процесса разработки и сопровождения и, на практике, бывает необходимо адаптировать общие и создать специальные для инженерной деятельности внутренние организационные стандарты, обеспечивающие эффективное управление программной инженерией. Эти политики являются основой для решения долгосрочных задач улучшения процессов и повышения производительности труда специалистов, вовлеченных с работы по созданию сопровождению программного обеспечения.
Другим важным аспектом управления является управление персоналом через политики и процедуры найма и приема на работу, обучения, и мотивации специалистов, помощи в развитии навыков для дальнейшего карьерного роста (mentoring in career developement). Все это требует внимания не только в контексте проекта, но в рамках всей организации. Для инженеров-программистов особо важными, в частности, являются вопросы обучения и индивидуального внимания руководства. В большой степени это связано с постоянно развивающимеся технологиями и потребностью в обновлении и расширении знаний для эффективного решения поставленных задач.
Часто не придают необходимого внимания вопросам коммуникаций между сотрудниками. На самом деле управление коммуникациями, создание естественных условий (в гибких методологиях разработки им придается особое внимание) для их развития – один из ключевых элементов повышения не только продуктивности команд разработки и сопровождения, но и, например, точности получаемых от пользователей требований и запросов на изменения, то есть любой информации, которая передается между людьми и значима для успешного решения поставленных задач. Наконец, управление портфелями (проектов разработки и работ по сопровождению) позволяет сформировать и развивать общее видение в отношении всех существующих, обновляемых и создаваемых программных активов на уровне ИТ-подразделения и в организации, в целом. Все это, в конечном счете, обеспечивает и более эффективное управление ресурсами, а, значит, и возможность интенсивного, а не экстенсивного развития организации, в которой инновации начинают играть одну из ключевых ролей.
Вместе с осознанием специфики управленческой деятельности в приложении к программной инженерии, ИТ-специалистам необходимо понимать и ключевые аспекты общего управления и управления проектами.
Организационная культура, нормы поведения, аспекты корпоративного управления в вопросах приобретения и поставки, управления цепочками поставок (supply chain management), маркетинг, продажи, партнерства и т.п. – все это влияет, хотя и неявно, на организационные процессы программной инженерии.
В отношении данной области знаний особо уместно подчеркнуть значимость вопросов управления проектами (project management), так как “конструирование имеющих ценность программных артефактов” (к которым относятся требования, модели, документация, тесты и т.п.) обычно ведется в форме проектов. Например, принимая это во внимание, создатели SWEBOK особо отмечают связь данной области знаний c Руководством к Своду Знаний по Управлению Проектами PMBOK (A Guide to the Project Management Body of Knowledge. PMBOK® Guide). В контексте управления программной инженерией следует понимать важность соответствующих областей знаний PMBOK:
· управление интеграцией проекта (project integration management);
· управление содержанием проекта (project scope management);
· управление сроками проекта (project time management);
· управление стоимостью проекта (project cost management);
· управление качеством проекта (project quality management);
· управление человеческими ресурсами проекта (project human resource management);
· управление коммуникациями проекта (project communication management);
· управление рисками проекта (project risk management);
· управление поставками проекта (project procurement management).
Несомненно, области знаний управления проектами имеют непосредственное влияние на решение вопросов управления инженерной деятельностью в области программного обеспечения. Не имеет смысла, да и просто невозможно включать материалы PMBOK в данные лекции. PMBOK рассматривается как ключевой источник информации и знаний по управлению проектами, настоятельно рекомендуемый всем лицам, в той или иной степени вовлеченных в управленческую деятельность в программных проектах.
Данная область знаний состоит из пяти секций, посвященных процессам управления программной инженерией и еще одной секции, касающейся вопросов измерений и количественных оценок в управлении. Хотя эти два аспекта (управление и измерения) часто рассматриваются отдельно и, в самом деле, обладают многими уникальными аспектами, их тесная взаимосвязь играет важную роль в этой области знаний. К сожалению, сложилось, во многих случаях, обоснованное восприятие индустрии программного обеспечения как недостаточно зрелой, в силу частых срывов сроков, превышения бюджетных ограничений, недостаточного качества продуктов, неопределенной функциональности и других причин. Управление, ориентированное на измерения, как один из основных принципов любой инженерной деятельности, может серьезно помочь в изменении сложившейся неблагоприятной ситуации и формировании положительного восприятия программной индустрии потребителями (пользователями и заказчиками). По-сути, управление без измерений, количественных или качественных, приводит к отсутствию прогресса в достижении целей, а измерения без управления – к потере контекста и целей. Однако, в то же время, управление и измерения без необходимого и достаточного уровня знаний становится неэффективным и, часто, превращается в самоцель (что приводит к излишней бюрократизации и неадекватной загруженности ресурсов). Таким образом, управленческая деятельность, в общем плане (включая количественные и качественные оценки), должна проводиться сбалансировано с другими аспектами программной инженерии, не превращая управление в программной инженерии дорогостоящую, но бесполезную работу. Эффективное управление требует комбинации соответствующих систематических и упорядоченных подходов в управлении и соответствующего опыта.
Прежде, чем детализировать данную область знаний, необходимо дать рабочие определения для понятий “процесс управления” и “измерения”:
· Процесс управления (Management process) описывает действия (работы - activities), предпринимаемые для обеспечения того, что процессы программной иженерии выполняются в согласовании с политиками, целями и стандартами, принятыми в организации.
· Измерения (Measurement) связаны с определением величин и характеристикой различных аспектов программной инженерии (продуктов, процессов и т.п.), а также разработкой на их основе моделей* с использованием статистических методов (и данных), экспертных знаний и других техник.
Данная область знаний тесно связана с другими областями:
Требования к программному обеспечению (Software Requirements) – соответствующие действия по работе с требованиями (в первую очередь, их определение) указанной области знаний должны выполняться в фазе инициирования (Initiation) и определения содержания (Scope Definition) программных проектов.
Конфигурационное управление (Software Configuration Management) – связано с идентификацией, контролем, учетом статуса (активов проекта, включая запросы на изменения, прим. автора) и аудитом конфигураций (в терминах конфигурационного управления) в сочетании с управлением релизами (release management) и развертыванием программных систем.
Процесс программной инженерии (Software Engineering Process) – процессы и продукты тесно связаны; указанная область знаний включает аспекты измерений продуктов и процессов.
Качество ПО (Software Quality) – качество является одной из постоянных целей управления и большого комплекса соответствующих работ, которыми необходимо управлять.
Данная область знаний рассматривает управление программной инженерий в терминах организационного процесса, включающего управление процессами и проектами. При этом, основной отправной точкой дальнейшей детализации является процесс управления программными проектами. Структура декомпозиции управления программной инженерией включает шесть основных секций (подобластей), из которых первые пять, в основном, следуют стандарту IEEE (ISO/IEC, ГОСТ Р) 12207 в части “Процесса управления” (Management Process):
· Инициирование и определение содержания (Initiation and scope definition) – касается принятия решения о начале программного проекта
· Планирование программного проекта (Software project planning) – относится к работам, предпринимаемым для подготовки к успешному ведению программно-инженерной деятельности с точки зрения управления
· Выполнение программного проекта (Software project enactment) – касается общепринятых (general accepted) действий по управлению программной инженерией в процессе проведения соответствующих инженерных работ
· Обзор и оценка (Review and evaluation) – относится к работам по проверке того, что получаемый программный продукт отвечает заданным целям, требованиям, ограничениям и т.п.
· Закрытие <проекта> (Closure) – относится к фиксированию результатов программного проекта после передачи полученного программного продукта в эксплуатацию.
· Измерения в программной инженерии (Software engineering measurement) – касается разработки и реализации программ по измерению (ведению количественной оценки) в организациях (в общем смысле, т.е. группах, подразделениях, компаниях и т.п.), занимающихся инженерной деятельностью в области программного обеспечения.
9.1 Инициирование и определение содержания (Initiation and Scope Definition)
Данная секция фокусируется на наборе действий, связанных с эффективным определением требований к программному обеспечению с использованием различных методов извлечения требований, а также оценкой осуществимости проекта с различных точек зрения. Если проект признан осуществимым, следующей задачей является специфицирование процедур проверки и изменения требований (см. область знаний “Требования к программному обеспечению” – Software Requirements).
9.1.1 Определение и обсуждение требований (Determination and Negotiation of Requirements)
Определение и обсуждение требований (Determination and Negotiation of Requirements) – выбор и применение методов определения (извлечения), анализа (например, моделирования сценариев use case), специфицирования и проверки (например, прототипирования) требований, принимая в внимание позицию различных заинтересованных лиц. Это является первичными работами, необходимыми для определения содержания, целей и ограничений проекта. Данные работы важны всегда, так как позволяют определить четкие границы задач, необходимых для выполнения, в частности, это особенно заметно для проектов, обладающих большой степенью “новизны”
9.1.2 Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.)
Инженеры должны убедиться в том, что для успешного завершения проекта (в заданные сроки, в рамках бюджета и т.п.) доступны необходимые возможности (capabilities) и ресурсы, будь то люди (те или иные специалисты), экспертиза (опыт, знания, навыки), средства (например, инструментарий), инфраструктура и поддержка (как внутренняя, так и внешняя, например, со стороны старших руководителей организационной структуры, отвечающей за разработку, и ключевых руководителей или других заинтересованных лиц со стороны “заказчика”). Это часто требует хотя бы приблизительной оценки усилий и стоимости с использованием соответствующих методов (например, техники, в которой экспертная оценка базируется на аналогиях).
9.1.3 Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements)
Учитывая неизбежность изменений, жизненно важно определить и согласовать с заинтересованными лицами процедуры (например, в контексте деятельности по управлению изменениями) в рамках которых будут проводиться оценка и пересмотр требований. Это однозначно предполагает, что требования не будут неизменны, но могут и должны корректироваться в соответствии с заданными и детализированными процессами (например, design review – оценка дизайна). Если изменения приняты, необходимо проводить анализ зависимостей (traceability analysis) и рисков (см. далее пункт 9.2.5 “Управление рисками”) для оценки влияния рассматриваемых изменений. Такой анализ необходимо проводить и при рассмотрении “изменения” для принятия решения о передачи его “в работу” или отклонении (например, в силу обоснованных причин, таких как проектные решения, позволяющих отметить его как реализуемое в следующей версии), и уже более детально, если изменение требований решено реализовать и необходимо определить, как именно такое изменение повлияет на существующую систему и какие работы необходимо выполнить, чтобы удовлетворить обновленным требованиям.
9.2 Планирование программного проекта (Software Project Planning)
Процесс планирования является итеративным и базируется на содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что, например, специально отмечает PMBOK) и вместе с определением содержания, детализацией требований и проведением анализа осуществимости, параллельно с этим сам разрабатываемый план проекта в той или иной степени детализируется и формируется определенный комплекс работ, оцениваются необходимые ресурсы и временные границы работ, и т.п.
При планировании также оцениваются и отбираются соответствующие процессы жизненного цикла. Там где это уместно, проект детализируется в виде структурной декомпозиции работ, для которых отмечены ассоциируемые с их завершением результаты и их характеристики. Такие характеристики, обычно, связаны с вопросами качества и другими установленными атрибутами требований, соблюдением сроков выполнения работ, усилиями, стоимостью и т.д. Ресурсы распределяются по задачам таким образом, чтобы обеспечить оптимальную продуктивность, использование средств (инфраструктуры, инструментов и т.д.) и оборудования, а также строгое соблюдение проектного расписания.
Также должно проводится управление рисками и, в частности, необходимо определить “профиль рисков”, принятый соответствующими заинтересованными лицами.
Как составная часть планирования, необходимо определить необходимые процессы обеспечения качества в форме соответствующих процедур и обязанностей (responsibilities) по оценке, проверке, аттестации и аудиту качества (см. раздел 10 “Управление качеством”).
Безусловно, что должны быть определены процессы и обязанности в части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта.
9.2.1 Планирование процесса (Process Planning)
С учетом содержания и требований конкретного проекта необходимо выбрать, адаптировать и использовать соответствующую модель процессов жизненного цикла (например, спиральную, с эволюционным прототипированием). Также должны быть выбраны методы и инструменты. На уровне проекта, методы и инструменты используются для декомпозиции проекта в виде набора задач (tasks), с ассоциированными входами, выходами и условиями завершения (completion), например, в форме структуры декомпозиции работ – WBS (work breakdown structure). Это влияет на высокоуровневое (первичное) определение проектного расписания и организационной структуры <проектной команды>.
9.2.2 Определение результатов (Determine Deliverables)
Должен быть определен результат выполнения каждой задачи (например, описание архитектуры, отчет по анализу, набор тестов и т.п.), то есть какие активы/артефакты мы должны получить по выполнении соответствующей задачи проекта. При этом оцениваются возможности повторного использования программных компонент, созданных ранее, в процессе разработки других программных продуктов, и потенциал применения готовых к использованию компонент из 3-их источников. Должно быть определено, какие именно компоненты будут использоваться и как они будут получены (через каких поставщиков).
Анализ и выбор соответствующих компонент может и, в подавляющем большинстве случаев, должен рассматриваться как самостоятельная задача процесса планирования в контексте сформулированных высокоуровневых требований, определенного содержания и базовых ограничений проекта, таких как сроки, ресурсы, стоимость). Это позволяет четко разделить, в том числе, в контексте затрат, что именно будет разрабатываться самостоятельно (может быть как отдельный “суб-проект”), что будет использоваться из 3-их источников.
9.2.3 Оценка усилий, расписания и стоимостных ожиданий (Efforts,Schedule and Cost Estimation)
Ожидаемые пределы усилий, необходимых для решения каждой задачи (task) проекта основываются на разбиении задач, их входах и выходах. Для этого используется калиброванная (calibrated - настроенная для заданных условий) модель ожиданий (estimation model), базирующаяся на исторических данных по усилиям, связанным с объемом задачи. Также, для оценки усилий могут применяться и другие методы, например, экспертная оценка или оценка по типу приложения (встроенное, телекоммуникационное), квалификации проектной группы и т.п.
Кроме того, необходимо идентифицировать связи и зависимости между задачами (tasks dependencies) и потенциально критические аспекты (bottlenecks) проекта. Такие работы могут быть проведены с использованием, например, метода анализ критического пути (critical path analysis – достаточно распространенный метод, относящийся к общей дисциплине управления проектами, применимый и для проектов программных систем). Если возможно, критические аспекты должны быть разрешены, а для задач определены ожидаемые сроки выполнения (расписание), включающие начало, длительность и окончание (например, в форме PERT-диаграмм*).
| PERT анализ (Program, Evaluation, and Review Technique) – техника оценки ожиданий в отношении длительности (duration) задач проекта, проводимая на основе определения среднего весового значения трех оценок длительности - пессимистической, оптимистической и ожидаемой (то есть наиболее вероятной, при первичной оценке). Аналогичная техника может и часто используется для оценки усилий (effort), необходимых для реализации задачи. Наибольший эффект дает сочетание различных методов оценки. В то же самое время, чем больше методов оценки используется, тем более трудоемкой (а, следовательно, и ресурсоемкой) становится такая работа, поэтому задача менеджмента – определить наиболее оптимальный и эффективный для данного проекта набор методов и техник, используемых в процессе планирования и корректировки. |
В совокупности, вся эта деятельность является итеративной и должна обсуждаться и проводиться до тех пор, пока не будет достигнут консенсус между соответствующими заинтересованными лицами – в первую очередь, руководством (проекта) и инженерами (входящими в команду проекта).
9.2.4 Распределение ресурсов (Resource Allocation)
С задачами (для которых назначены сроки), должны быть ассоциированы оборудование, средства и, конечно, люди. Это подразумевает распределение (назначение или принятие, в зависимости от стиля и формы управления) обязанностей/ответственности. Для этого может, например, использоваться диаграмма Ганта. Эта деятельность определяется и ограничивается доступностью ресурсов, их оптимальным использованием в заданном контексте и вопросами, связанными с персоналом (например, продуктивностью конкретных лиц и группы, в целом, организационной и командной структурой, подразумевая специфику коллектива, наравне со штатным расписанием и другие вопросы).
Крайне необходимо выделить как самостоятельную тему данной секции вопросы управления персоналом – people management, уделив особое внимание аспектам экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в проектной команде. К этой же теме, также стоит отнести вопросы обучения, прохождения тренингов специалистами проектной команды.
Наконец, к теме ресурсов имеет непосредственное отношение и определение необходимости и объема привлечения внешних консультантов (не являющихся сотрудниками ни исполнителя, ни заказчика).
9.2.5 Управление рисками (Risk Management)
В части управления рисками должны проводиться:
· идентификация и анализ рисков – что, когда и почему может быть сделано неверно и к чему это может привести;
· оценка критических рисков – какие из рисков наиболее значительны (если им не уделять должного внимания) и что необходимо сделать, чтобы их избежать;
· смягчение рисков (risk mitigation) и планируемость непредвиденных обстоятельств (contingency planning) – формирование стратегии, касающейся рисков и управление профилями рисков.
Для идентификации и оценки рисков необходимо применять соответствующие методы и техники (например, построение дерева решений – decision tree или моделирование процессов – process simulation). Кроме того, со всеми заинтересованными лицами необходимо определить правила и политики прекращения проекта.
Наравне с идеями общего управления рисками, важно понимать и управлять рисками, уникальными для деятельности в области программной инженерии, например, тенденция добавлять в получаемый программный продукт функциональные и другие возможности, неопределенные на уровне требований или риски, заложенные в самой природе программного обеспечения, связанные, в первую очередь с его сложностью и архитектурно-технологической новизной, присутствующей, в той или иной степени, в любом программном проекте.
9.2.6 Управление качеством (Quality Management)
Качество определяется в терминах атрибутов, значимых для данного конкретного проекта и/или ассоциированного с ним продукта. Атрибуты могут выражаться как качественно, так и количественно. Эти характеристики качества определяются в спецификации требований к программному обеспечению (см. раздел 3 «Разработка и управление требованиями»).
Отправной точкой для соблюдения качества является набор индикаторов, соответствующих ожиданиям заинтересованных лиц. На этой стадии (как мы помним, речь идет о планировании проекта) также специфицируются процедуры, связанные с проведением SQA-деятельности (деятельности по обеспечению качества – software quality assurance) на протяжении всех процессов жизненного цикла и для проверки и аттестации (V&V – verification and validation) для получаемого продукта и всех активов (артефактов) проекта (см. область знаний “Качество программного обеспечения” – Software Quality).
9.2.7 Управление планом проекта (Plan Management)
Наравне с другими аспектами ведения проекта, должно быть определено как проект будет управляться и как будет управляться план проекта. Отчетность, мониторинг и контроль проекта должны соответствовать выбранному процессу программной инженерии и сущности проекта, отражая также в виде различных артефактов именно то, что будет использоваться в процессе управления. При этом, в изменяющемся окружении принципиально важно, чтобы и сам план проекта был управляем. Это требует строгого соблюдения планов, которые должны быть систематически направляемы, контролируемы, оцениваемы, по которым будет вестись отчетность и, там где это применимо, корректируемы. Планы, ассоциированные с другими процессами поддержки, ориентированными на управление, также должны быть управляемы соответствующим образом (например, это касается вопросов документирования, конфигурационного управления и разрешения проблем).
9.3 Выполнение программного проекта (Software Project Enactment)
План проекта реализуется за счет выполнения процессов, представленных в плане. Следование плану на протяжении выполнения проекта связано с ожиданиями, что соблюдение <корректно составленного> плана приводит к успешному удовлетворению требований заинтересованных лиц и достижению целей проекта. Основой для успешного выполнения проекта является управленческая деятельность по ведению оценки и измерений, мониторинга, контроля и отчетности.
9.3.1 Реализация планов (Implementation of Plans)
Проект инициируется и проектные работы выполняются в соответствии с планом. В процессе выполнения используются соответствующие ресурсы (например, усилия персонала, бюджет) и производятся необходимые результаты (deliverables; активы, артефакты проекта – например, архитектурные документы, тестовые сценарии).
9.3.2 Управление контрактами с поставщиками (Supplier Contract Management)
Включает подготовку и выполнение соглашений с поставщиками, мониторинг деятельности поставщиков, принятие у поставщиков продуктов, использование и интеграцию этих продуктов в рамках проектных работ.
9.3.3 Реализация процесса по ведению измерений (Implementation of Measurement Process)
Данный процесс выполняется на протяжении всего проекта, обеспечивая сбор всех необходимых данных (см. пункты 9.6.2 Планирование процесса измерений (Plan the Measurement Process) и 9.6.3 Выполнение процесса измерений (Perform the Measurement Process)).
9.3.4 Процесс мониторинга (Monitor Process)
Соблюдение плана проверяется постоянно и через предопределенные интервалы времени. Анализируются выходы (outputs) и условия завершения <задач>. Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых характеристик (например, через процедуры обзора/оценки и аудита – review, audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному моменту, используемые ресурсы – все это исследуется к каждой дате оценки. При этом, оценивается и корректируется профиль рисков, а также, производится проверка удовлетворения требований качества.
Моделируются и анализируются данные измерений. Анализ расхождений (variance analysis) <плана с реальным выполнением проекта> базируется на оценке отклонений реальных данных от планируемых и ожидаемых. Такой анализ может проводиться в отношении оценки перерасхода средств (cost overrun), нарушения расписания и других важных характеристик – ограничений проекта.
| Современная практика управления проектами, в частности, разработки и сопровождения программного обеспечения, требует обеспечения возможности доступна к актуальным данным по проекту в любой момент времени. По-сути в настоящее время возникает целый класс интегрированных инструментов и специализированных продуктов, часто называемый project dashboard (наиболее близкий перевод этого понятия на русский язык может звучать как “панель управления проектом”). Обычно, такие инструменты не только работают со “снимками” данных, сводя их воедино, но обращаются непосредственно к данным в системах конфигурационного управления, управления требованиями, сценариями тестирования, аудита кода, расписания проекта в соответствующих средствах управления проектами и т.п. |
9.3.5 Процесс контроля (Control Process)
Выходы (результаты) процесса мониторинга обеспечивают базис, на основе которого принимаются те или иные решения. Изменения в проект вносятся там, где это необходимо, и где ассоциированные риски и их влияние смоделированы и могут быть управляемы (контролируемы). Эти изменения могут проводиться в форме корректирующих действий (например, повторного тестирования определенных компонент) и могут приводить к изменению плана, работ, документов и других активов проекта. При этом, важно контролировать (идентифицировать, оценивать и принимать решения) прямые и косвенные влияния любых изменений.
В некоторых случаях, это может приводит к прекращению проекта. Во всех случаях необходимо проводить контроль изменений и процедур конфигурационного управления (см. предыдущую область знаний «Конфигурационное управление»). При этом, решения должны документироваться и сообщаться (желательно, перед этим обсуждаться) всем заинтересованным сторонам, планы – корректироваться (там где это необходимо), а все необходимые данные должны заноситься в центральную базу данных проекта.
9.3.6 Ведение отчетности (Reporting)
Отчеты проводятся за определенный и согласованный период времени, согласуясь с планом проекта и адресуясь заинтересованным лицам (в том числе – “внешним”, со стороны заказчика). В принципе, возможны выделить две группы отчетов – по общему состоянию проекта (именно, они обычно адресованы и заказчику), а также детализированные отчеты, подготавливаемые чаще и касающиеся отдельных групп в команде проекта, отдельных работ, групп требований, функциональных модулей и т.п.
9.4 Обзор и оценка (Review and Evaluation)
В критических точках проекта оценивается общий (по всему проекту) прогресс в достижении установленных целей и удовлетворении требований заинтересованных лиц. Аналогично, проводится оценка (assessment) эффективности процессов, <работы> персонала, а также инструментов и методов, использованных в работах, проведенных за заданный промежуток времени.
9.4.1 Определение удовлетворения требованиям (Determining Satisfaction of Requirements)
Так как достижение удовлетворения пользователей является одной из наших принципиальных целей, представляется важным периодическая и формальная оценка прогресса в данном вопросе. Такая оценка проводится при достижении определенных вех (milestones) проекта, например, при утверждении разработанной архитектуры). При этом идентифицируются отклонения от соответствующих ожиданий (планов) и проводятся необходимые действия, связанные с результатами оценки отклонений (например, действия по корректировке плана). Как было отмечено выше, во всех случаях проводится контроль изменений и процедуры конфигурационного управления, документируются принятые решения и обеспечивается необходимая отчетность. Дополнительную информацию, также имеющую отношение к обсуждаемому вопросу, можно найти в области знаний “Тестирование программного обеспечения”.
9.4.2 Оценка продуктивности/результативности (Reviewing and Evaluation Performance)
Периодическая оценка продуктивности специалистов, вовлеченных в проект, обеспечивает понимание того, насколько они следуют плану, и дает возможность идентифицировать вероятные проблемы (например, конфликты между членами проектной команды). Для оценки эффективности применяются различные методы, инструменты и техники. Сам процесс оценки является систематическим, а процедуры – периодическими. Все это зависит от используемых управленческих техник, применяемых методологий, организационных принципов, сложившейся культуры, то есть рассматривается, в том числе, в контексте специфики программной инженерии, дисциплины управления проектами и общего управления.
9.5 Закрытие (Closure)
Проект закрывается/завершается (не путайте с прекращением проекта), когда все планы и процессы выполнены и завершены. На этой стадии в результатам проекта применяются критерии оценки его успешности. Когда принимается решение о закрытии проекта, выполняются действия по архивированию проектных данных, анализу результатов, полученных в процессе работы над проектом (post mortem analysis), и улучшению процессов (process improvement).
9.5.1 Определение <критериев> закрытия проекта (Determining Closure)
Проект закрывается, когда завершены специфицированные в плане проекта задачи и подтверждено <удовлетворительное> достижение критериев завершения (completion criteria) проекта. При этом, все запланированные результаты (продукт, его модули и т.п.) должны быть переданы заказчику и/или в эксплуатацию с приемлемыми (с точки зрения требований) и принятыми (со стороны заказчика) характеристиками. Удовлетворение требованиям – проверено и подтверждено/утверждено заказчиком, а цели проекта – достигнуты. Перечисленные процессы, в общем случае, требуют вовлечения всех заинтересованных лиц. Результаты их выполнения документируются, включая подтверждения со стороны заказчика о соответствии результатов проекта заданным требованиям (client acceptance list, например, по результатам приемочных, или, как их еще называют, приемо-сдаточных тестов) и, если это необходимо, включая также отчеты об оставшихся/требующих доработки проблемах (known problems).
9.5.2 Работы по закрытию проекта (Closure Activities)
После того, как принято и утверждено решение о закрытии проекта (также говорят о “подтверждении закрытия/завершения проекта”) создается архив материалов в соответствии с утвержденными заинтересованными лицами методами, местоположением, формой и заданной длительностью хранения. База данных измерений <в организации> обновляется в соответствии с полученными финальными данными проекта и проводится пост-проектный анализ этих данных. Анализ по завершении проекта помогает в оптимизации процессов, практик и организационной структуры (см. область знаний Software Engineering Process).
9.6 Измерения в программной инженерии (Software Engineering Measurement)
Вы не можете контролировать то, что не можете измерить…
Вы не можете измерить то, что вы не можете определить…
Вы не можете определить то, что вы не знаете…
Важность и роль количественных оценок - измерений - в управленческих практиках широко известна, растет с каждым годом. Эффективные измерения становятся одним из краеугольных камней организационной зрелости.
Ключевые термины и методы по измерениям в программной инженерии определены в стандарте ISO/IEC 15939:2007 Systems and software engineering — Measurement process, основывающемся на международном словаре метрологии, выпущенном ISO в 1993 году. Несмотря на это, в различной литературе встречаются разные термины, например, часто термин “metric” – метрика (на русском языке выглядит предпочитительным использовать именно этот термин) используется вместо “measure” – измерение.
Данная тема следует указанному международному стандарту ISO/IEC 15939, который описывает процесс, определяющий действия/работы (activities) и задачи (tasks)*, необходимые для реализации процесса ведения измерений, а также включающий информационную модель измерений.
*Примечание: “действия/работы” - activities, “задачи” – tasks: термин “задача” используется для более глубокого уровня детализации, чем “действия/работы”; термины “действия” и “работы”, как вы уже заметили, часто используются взаимозаменяемым образом. Так или иначе, это вопрос договоренности о терминологии при организации WBS (Work Breakdown Structure) – структуры декомпозиции работ
9.6.1 Установление и поддержка процесса ведения измерений (Establish and Sustain Measurement Commitment)
Формулируются требования в отношении измерений. Каждая попытка измерения должна руководствоваться организационными целями и следовать набору измерений, выполняемых в отношении требований, в соответствии с принятыми организационными или проектными стандартами. Например, в качестве организационной цели может выступать “выпуск на рынок новых продуктов первыми”. Это, в свою очередь, может порождать требование того, что факторы, способствующие достижению цели также должны быть оценены количественно, с тем, чтобы проект могу быть управляем в процессе достижения заданного результата. Для этого необходимо:
·
| Организационная единица - organizational unit: этот термин хоть и не очень удачен, но будет использоваться достаточно часто в контексте ведения измерений для описания границ измерений. При этом часто подразумевается не фиксированная структурная единица в организации, а некая “единица деятельности”, в отношении которой проводятся измерения – операция, задача, работа, проект, программа, деятельность организации, в целом. |
· Заручиться поддержкой руководителей и персонала в ведении измерений. Такая поддержка должна быть оформлена формально, сообщена персоналу и поддержана соответствующими ресурсами.
Выделяются соответствующие ресурсы для проведения измерений. Организационная поддержка измерений является основным фактором успеха, так как назначение ресурсов просто необходимо для реализации процесса ведения измерений. Назначение ресурсов включает распределение ответственности (например, пользователь, аналитик и т.п.) в отношении различных задач процесса измерения и предоставление необходимого финансирования, обучения, инструментов и поддержки процесса сопровождения на постоянной основе.
9.6.2 Планирование процесса измерений (Plan the Measurement Process)
Задание “организационной единицы” (в частности, в понимании “единицы деятельности”, как описывалось выше). Таким образом обеспечивается явный контекст измерений и связанные с ним ограничения. В качестве такой “единицы” (в общем случае) могут выступать организационные процессы, прикладные домены (области деятельности или отдельных работ) и т.п.
Идентификация информационных потребностей <в отношении результатов измерений>. Такие потребности, обычно, базируются на целях, ограничениях, рисках и проблемах на уровне заданной организационной единицы. В основе указанных аспектов лежат различные цели – организационные, проектные и т.п. Все эти аспекты (как и порождающие их цели) должны быть четко идентифицированы и для них должны быть определены соответствующие приоритеты. Затем, должно быть выбрано подмножество аспектов, в отношении которых будут проводиться измерения, и полученные результаты также должны быть документированы, персонал поставлен в известность о них, а заинтересованным лицам необходимо провести требуемую оценку аспектов измерений
Выбор метрик (измерений). Кандидаты в метрики должны быть выбраны на основе приоритетов информационных потребностей и других критериев – таких, как стоимость сбора данных, возможность срыва процессных работ при сборе данных (например, в силу недостатка ресурсов), легкость анализа, легкость получения точных и целостных данных и т.п.
Определение наборов <собираемых> данных, а также процедур анализа и ведения отчетности. Это включает в себя коллекцию процедур и расписаний, хранение, проверку, анализ, отчетность и конфигурационное управление собираемыми данными.
Определение критериев оценки информационных продуктов (т.е. результатов измерений). На критерии оценки влияют технические и бизнес цели, сформулированные прежде для соответствующей организационной единицы. Результаты измерений ассоциированы с создаваемым продуктом <являющемся целью проекта>, а также с процессами, обеспечивающими управление и измерения в проекте
Дата: 2019-02-19, просмотров: 327.
