Управление программной инженерией может быть определено как приложение вопросов управления (management activities) - планирования, координации, количественной оценки, мониторинга, контроля и отчетности - к инженерной деятельности для систематического, упорядоченного и количественно измеряемого обеспечения разработки и сопровождения программных систем (IEEE 610.12-90, Standard Glossary for Software Engineering Terminology).
Таким образом, область знаний “Управление программной инженерией” определяет аспекты управления и количественной оценки в программной инженерии. Измерения являются важным аспектом для всех областей знаний SWEBOK и соответствующая тема также включена и в описании данной области знаний.
В принципе, корректно утверждать, что возможно управлять программной инженерией так же, как и любым другим комплексным процессом. В то же время, существуют аспекты, специфичные для программных продуктов, а процессы жизненного цикла программных систем, в какой -то мере, усложняют достижение необходимого уровня эффективности управления. Среди таких усложняющих факторов:
• Восприятие клиентов (потребителей, заказчиков) таково, что часто отсутствует с их стороны понимание сложности, порожденной самой природой программной инженерии, в частности связанной с влиянием изменяющихся требований.
• Практически неизбежно изменение или появление новых клиентских требований, как следствие функционирования процессов программной инженерии.
• В результате, программные системы часто строятся с применением итеративных процессов, вместо последовательного выполнения и закрытия работ (задач).
• Уровень новизны и сложности программных систем часто крайне высок (и не позволяет в полной мере применять уже существующие наработки и опыт).
• Применяемые технологии обладают высокой скоростью изменения, обновления и устаревания
Что касается программной инженерии, управленческая деятельность в этой области происходит на трех уровнях:
• Организационное управление и управление инфраструктурой
• Управление проектами
• Планирование и контроль программ количественной оценки
Последние два уровня описаны в данной области знаний, что никак не принижает значимости общих вопросов управления организационными аспектами и инфраструктурой.
Хотя все области знаний тесно связаны с другими дисциплинами, связь данной области знаний с общими вопросами менеджмента особенно важны, что и будет более подробно, в отличие от других областей знаний, представлено в ниже. Вопросы организационного менеджмента важны с точки зрения влияния на программную инженерию, например, в контексте управления политиками/полномочиями сотрудников или других внутрикорпоративных стандартов, в рамках которых выполняется любая деятельность (например, с точки зрения отчетности по занятости сотрудников), в том числе - инженерная. Такие политики подвержены влиянию со стороны требований к организации эффективного процесса разработки и сопровождения и, на практике, бывает необходимо адаптировать общие и создать специальные для инженерной деятельности внутренние организационные стандарты, обеспечивающие эффективное управление программной инженерией. Эти политики являются основой для решения долгосрочных задач улучшения процессов и повышения производительности труда специалистов, вовлеченных с работы по созданию сопровождению программного обеспечения.
Другим важным аспектом управления является управление персоналом через политики и процедуры найма и приема на работу, обучения, и мотивации специалистов, помощи в развитии навыков для дальнейшего карьерного роста (mentoring in career developement). Все это требует внимания не только в контексте проекта, но в рамках всей организации. Для инженеров-программистов особо важными, в частности, являются вопросы обучения и индивидуального внимания менеджмента. В большой степени это связано с постоянно развивающимеся технологиями и потребностью в обновлении и расширении знаний для эффективного решения поставленных задач. Часто не придают необходимого внимания вопросам коммуникаций между сотрудниками. На самом деле управление коммуникациями, создание естественных условий (в agile-практиках им придается особое внимание) для их развития - один из ключевых элементов повышения не только продуктивности команд разработки и сопровождения, но и, например, точности получаемых от пользователей требований и запросов на изменения, то есть любой информации, которая передается между людьми и значима для успешного решения поставленных задач. Наконец, управление портфелями (проектов разработки и работ по сопровождению) позволяет сформировать и развивать общее видение в отношении всех существующих, обновляемых и создаваемых программных активов на уровне ИТ-подразделения и в организации, в целом. Все это, в конечном счете, обеспечивает и более эффективное управление ресурсами, а, значит, и возможность интенсивного, а не экстенсивного развития организации, в которой инновации начинают играть одну из ключевых ролей.
Вместе с осознанием специфики управленческой деятельности в приложении к программной инженерии, ИТ-специалистам необходимо понимать и ключевые аспекты общего менеджмента и управления проектами.
Организационная культура, нормы поведения, аспекты корпоративного управления в вопросах приобретения и поставки, управления цепочками поставок (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)
SWEBOK отмечает, что, несомненно, области знаний управления проектами имеют непосредственное влияние на решение вопросов управления инженерной деятельностью в области программного обеспечения. Не имеет смысла, да и просто невозможно дублировать в SWEBOK содержание PMBOK. Вместо этого, PMBOK рассматривается как ключевой источник информации и знаний по управлению проектами, настоятельно рекомендуемый всем лицам, в той или иной степени вовлеченных в управленческую деятельность в программных проектах. Таким образом, естественно, что управление проектами можно найти в области знаний SWEBOK “Связанные дисциплины”
(Related Disciplines).
Данная область знаний состоит из пяти секций, посвященных процессам управления программной инженерией и еще одной секции, касающейся вопросов измерений и количественных оценок в управлении. Хотя эти два аспекта (управление и измерения) часто рассматриваются отдельно и, в самом деле, обладают многими уникальными аспектами, их тесная взаимосвязь играет важную роль в этой области знаний. К сожалению, сложилось, во многих случаях, обоснованное [Chaos, 2004] восприятие индустрии программного обеспечения как недостаточно зрелой, в силу частых срывов сроков, превышения бюджетных ограничений, недостаточного качества продуктов, неопределенной функциональности и других причин. Управление, ориентированное на измерения, как один из основных принципов любой инженерной деятельности, может серьезно помочь в изменении сложившейся неблагоприятной ситуации и формировании положительного восприятия программной индустрии потребителями (пользователями и заказчиками). По-сути, управление без измерений, количественных или качественных, приводит к отсутствию прогресса в достижении целей, а измерения без управления - к потере контекста и целей. Однако, в то же время, управление и измерения без необходимого и достаточного уровня знаний становится неэффективным и, часто, превращается в самоцель (что приводит, по мнению автора к излишней бюрократизации и неадекватной загруженности ресурсов). Таким образом, управленческая деятельность, в общем плане (включая количественные и качественные оценки), должна проводиться сбалансировано с другими аспектами программной инженерии, не превращая Software Engineering Management (SEM) в дорогостоящую, но бесполезную работу. Эффективный менеджмент требует комбинации соответствующих систематических и упорядоченных подходов в управлении и соответствующего опыта[6].
серьезным практическим опыт управления проектами и пытается сдать соответствующий экзамен только на основе штудирования PMBOK и теоретических “изысканий”.
Прежде, чем детализировать данную область знаний, необходимо дать рабочие определения для понятий “процесс управления” и “измерения”:
• Процесс управления (Management process) описывает действия (работы - activities), предпринимаемые для обеспечения того, что процессы программной иженерии выполняются в согласовании с политиками, целями и стандартами, принятыми в организации
• Измерения (Measurement) связаны с определением величин и характеристикой различных аспектов программной инженерии (продуктов, процессов и т.п.), а также разработкой на их основе моделей[7] с использованием статистических методов (и данных), экспертных знаний и других техник.
• * В данном контексте, SWEBOK видимо подразумевает, что полученные модели используются для идентификации и анализа рисков, планирования и совершенствования процессов программной инженерии (процессов жизненного цикла, включая процессы сопровождения), а также процесса управления.
Секции (подобласти) данной области знаний, связанные с управлением программной инженерией, тесно связаны с секций измерений (количественной оценки).
Вполне естественно, что данная область знаний тесно связана с другими областями знаний SWEBOK и ее необходимо рассматривать в контексте других областей знаний. Стоит особо отметить следующие аспекты применения других областей знаний в управлении программной инженерией и, особо, в управлении программными проектами:
• Требования к программному обеспечению (Software Requirements) - соответствующие действия по работе с требованиями (в первую очередь, их определение) указанной области знаний должны выполняться в фазе инициирования (Initiation) и определения содержания (Scope Definition) программных проектов.
• Конфигурационное управление (Software Configuration Management) - связано с идентификацией, контролем, учетом статуса (активов проекта, включая запросы на изменения, прим. автора) и аудитом конфигураций (в терминах конфигурационного управления) в сочетании с управлением релизами (release management) и развертыванием программных систем.
• Процесс программной инженерии (Software Engineering Process) - процессы и продукты тесно связаны; указанная область знаний включает аспекты измерений продуктов и процессов.
• Качество (Software Quality) - качество является одной из постоянных целей управления и большого комплекса соответствующих работ, которыми необходимо управлять.
Данная область знаний рассматривает управление программной инженерий в терминах организационного процесса, включающего управление процессами и проектами. Структурная декомпозиция этой области знаний основывается и на определении соответствующих тем и на рассмотрении жизненного цикла. При этом, основной отправной точкой дальнейшей детализации является процесс управления программными проектами (в оригинале SWEBOK в данной области знаний активно используется термин software engineering project). Таким образом, структура декомпозиции управления программной инженерией включает шесть основных секций (подобластей), из которых первые пять, в основном, следуют стандарту 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) - касается разработки и реализации программ по измерению (ведению количественной оценки) в организациях (в общем смысле, т.е. группах, подразделениях, компаниях и т.п.), занимающихся инженерной деятельностью в области программного обеспечения.
1. Инициирование и определение содержания (Initiation and Scope Definition)
Данная секция фокусируется на наборе действий, связанных с эффективным определением требований к программному обеспечению с использованием различных методов извлечения требований, а также оценкой осуществимости проекта с различных точек зрения. Если проект признан осуществимым, следующей задачей является специфицирование процедур проверки и изменения требований (см. область знаний “Требования к программному обеспечению” - Software Requirements).
1.1 Определение и обсуждение требований (Determination and Negotiation of Requirements) - выбор и применение методов определения (извлечения), анализа (например, моделирования сценариев use case), специфицирования и проверки (например, прототипирования) требований, принимая в внимание позицию различных заинтересованных лиц. Это является первичными работами, необходимыми для определения содержания, целей и ограничений проекта. Данные работы важны всегда, так как позволяют определить четкие границы задач, необходимых для выполнения, в частности, это особенно заметно для проектов, обладающих большой степенью “новизны” (идет ли речь о технологических аспектах проекта, его масштабах, методах и т.п.).
Инженеры должны убедиться в том, что для успешного завершения проекта (в заданные сроки, в рамках бюджета и т.п.) доступны необходимые возможности (capabilities) и ресурсы, будь то люди (те или иные специалисты), экспертиза (опыт, знания, навыки), средства (например, инструментарий), инфраструктура и поддержка (как внутренняя, так и внешняя, например, со стороны старших менеджеров организационной структуры, отвечающей за разработку, и ключевых менеджеров или других заинтересованных лиц со стороны “заказчика”). Это часто требует хотя бы приблизительной оценки усилий и стоимости с использованием соответствующих методов (например, техники, в которой экспертная оценка базируется на аналогиях).
1.3 Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements)
Учитывая неизбежность изменений, жизненно важно определить и согласовать с заинтересованными лицами процедуры (например, в контексте деятельности по управлению изменениями) в рамках которых будут проводиться оценка и пересмотр требований. Это однозначно предполагает, что требования не будут неизменны, но могут и должны корректироваться в соответствии с заданными и детализированными процессами (например, design review - оценка дизайна). Если изменения приняты, необходимо проводить анализ зависимостей (traceability analysis) и рисков (см. далее тему 2.5 “Управление рисками” - Risk Management) для оценки влияния рассматриваемых изменений. Такой анализ необходимо проводить, в общем случае, и при рассмотрении “изменения” для принятия решения о передачи его “в работу” или отклонении (например, в силу обоснованных причин, таких как проектные решения, позволяющих отметить его как реализуемое в следующей версии), и уже более детально, если изменение требования(ий) решено реализовать (в силу, например, контрактных обязательств со стороны исполнителя) и необходимо определить, как именно такое изменение повлияет на существующую систему и какие работы необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOK отмечает, что управление изменениями полезно и при оценке результатов проекта (программного продукта, программной системы), так как содержание и требования формируют основу оценки успешности проекта. (см. также секцию “Контроль конфигураций” области знаний Software Configuration Management).
2. Планирование программного проекта (Software Project Planning)
Процесс планирования является итеративным* и базируется на содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что, например, специально отмечает PMBOK) и вместе с определением содержания, детализацией требований и проведением анализа осуществимости, параллельно с этим сам разрабатываемый план проекта в той или иной степени детализируется и формируется определенный комплекс работ, оцениваются необходимые ресурсы и временные границы работ, и т.п. SWEBOK, основываясь на такой позиции, говорит, что при планировании также оцениваются и отбираются соответствующие процессы жизненного цикла. Там где это уместно, проект детализируется в виде структурной декомпозиции работ, для которых отмечены ассоциируемых с их завершением результаты и их характеристики. Такие характеристики, обычно, связаны с вопросами качества и другими установленными атрибутами требований, соблюдением сроков выполнения работ, усилиями, стоимостью и т.д. Ресурсы распределяются по задачам таким образом, чтобы обеспечить оптимальную продуктивность (на персональном, командном и организационном уровне), использование средств (инфраструктуры, инструментов,...) и оборудования, а также строгое соблюдение проектного расписания. Также должно проводится управление рисками и, в частности, необходимо определить “профиль рисков”, принятый соответствующими заинтересованными лицами. Как составная часть планирования, необходимо определить необходимые процессы обеспечения качества в форме соответствующих процедур и обязанностей (responsibilities) по оценке, проверке, аттестации и аудиту качества (см. область знаний “Качество программного обеспечения” - Software Quality). Безусловно, что должны быть определены процессы и обязанности в части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта.
• * позднее, при обсуждении жизненного цикла и, в частности, спиральной модели разработки,
мы будем рассматривать ключевые идеи итеративного подхода.
2.1 Планирование процесса (Process Planning)
С учетом содержания и требований конкретного проекта необходимо выбрать, адаптировать и использовать соответствующую модель процессов жизненного цикла (например, спиральную, с эволюционным прототипированием). Также должны быть выбраны методы и инструменты. На уровне проекта, методы и инструменты используются для декомпозиции проекта в виде набора задач (tasks), с ассоциированными входами, выходами и условиями завершения (completion), например, в форме структуры декомпозиции работ - WBS (work breakdown structure). Это влияет на высокоуровневое (первичное) определение проектного расписания и организационной структуры <проектной команды>.
2.2 Определение результатов (Determine Deliverables)
Должен быть определен результат выполнения каждой задачи (например, описание архитектуры, отчет по анализу, набор тестов и т.п.), то есть какие активы/артефакты мы должны получить по выполнении соответствующей задачи проекта. При этом оцениваются возможности повторного использования программных компонент, созданных ранее, в процессе разработки других программных продуктов, и потенциал применения готовых к использованию компонент из 3-их источников. Должно быть определено, какие именно компоненты будут использоваться и как они будут получены (через каких поставщиков).
Такие компоненты, обычно, называют “off-the-shelf”, подразумевая в настоящее время не только коммерческое, но и общедоступное программное обеспечения, если его использование обосновано в рамках данного проекта. Анализ и выбор соответствующих компонент может и, в подавляющем большинстве случаев, должен рассматриваться как самостоятельная задача процесса планирования в контексте сформулированных высокоуровневых требований, определенного содержания и базовых ограничений проекта, таких как сроки, ресурсы, стоимость). Это позволяет четко разделить, в том числе, в контексте затрат, что именно будет разрабатываться самостоятельно (может быть как отдельный “суб-проект”), что будет использоваться из 3-их источников (3rd party), а что будет являться содержательным (с точки зрения проекта) результатом работ, то есть его непосредственным активом, обладающим, например, функциональной, для данного проекта, нагрузкой.
2.3 Оценка усилий, расписания и стоимостных ожиданий (Efforts,Schedule and Cost Estimation)
Ожидаемые пределы усилий, необходимых для решения каждой задачи (task) проекта основываются на разбиении задач, их входах и выходах. Для этого используется калиброванная (calibrated - настроенная для заданных условий) модель ожиданий (estimation model), базирующаяся на исторических данных по усилиям, связанным с объемом задачи (size-effort historical data, часто определяется как человеко-месяцы к функциональным точкам или количеству строк кода). Также, для оценки усилий могут применяться и другие методы, например, экспертная оценка или оценка по типу приложения (встроенное, телекоммуникационное), квалификации проектной группы и т.п.
Кроме того, необходимо идентифицировать связи и зависимости между задачами (tasks dependencies) и потенциально критические аспекты (bottlenecks) проекта. Такие работы могут быть проведены с использованием, например, метода анализ критического пути (critical path analysis - достаточно распространенный метод, относящийся к общей дисциплине управления проектами, применимый и для проектов программных систем). Если возможно, критические аспекты должны быть разрешены, а для задач определены ожидаемые сроки выполнения (расписание), включающие начало, длительность и окончание (например, в форме PERT-диаграмм[8]).
• * PERT анализ (Program, Evaluation, and Review Technique) - техника оценки ожиданий в отношении длительности (duration) задач проекта, проводимая на основе определения среднего весового значения трех оценок длительности - пессимистической, оптимистической и ожидаемой (то есть наиболее вероятной, при первичной оценке). Аналогичная техника может и часто используется для оценки усилий (effort), необходимых для реализации задачи. Наибольший эффект дает сочетание различных методов оценки. В то же самое время, чем больше методов оценки используется, тем более трудоемкой (а, следовательно, и ресурсоемкой) становится такая работа, поэтому задача менеджмента - определить наиболее оптимальный и эффективный для данного проекта набор методов и техник, используемых в процессе планирования и корректировки.
Требования к ресурсам (люди, инструменты) транслируются в стоимостные ожидания.
В совокупности, вся эта деятельность является итеративной и должна обсуждаться и проводиться до тех пор, пока не будет достигнут консенсус между соответствующими заинтересованными лицами - в первую очередь, менеджментом <проекта> и инженерами <входящими в команду проекта>.
2.4 Распределение ресурсов (Resource Allocation)
С задачами (для которых назначены сроки), должны быть ассоциированы оборудование, средства и, конечно, люди. Это подразумевает распределение (назначение или принятие, в зависимости от стиля и формы управления) обязанностей/ответственности. Для этого может, например, использоваться диаграмма Ганта (Gantt chart). Эта деятельность определяется и ограничивается доступностью ресурсов, их оптимальным использованием в заданном контексте и вопросами, связанными с персоналом (например, продуктивностью конкретных лиц и группы, в целом, организационной и командной структурой, подразумевая специфику коллектива, наравне со штатным расписанием и другие вопросы).
• смягчение рисков (risk mitigation) и планируемость непредвиденных обстоятельств (contingency planning) - формирование стратегии, касающейся рисков и управление профилями рисков.
Для идентификации и оценки рисков необходимо применять соответствующие методы и техники (например, построение дерева решений - decision tree или моделирование процессов - process simulation). Кроме того, со всеми заинтересованными лицами необходимо определить правила и политики прекращения проекта.
Наравне с идеями общего управления рисками, важно понимать и управлять рисками, уникальными для деятельности в области программной инженерии, например, тенденция добавлять в получаемый программный продукт функциональные и другие возможности, неопределенные на уровне требований или риски, заложенные в самой природе программного обеспечения, связанные, в первую очередь с его сложностью и архитектурно-технологической новизной, присутствующей, в той или иной степени, в любом программном проекте.
2.6 Управление качеством (Quality Management)
Качество определяется в терминах атрибутов, значимых для данного конкретного проекта и/или ассоциированного с ним продукта. Атрибуты могут выражаться как качественно, так и количественно. Эти характеристики качества определяются в спецификации требований к программному обеспечению (см. область знаний “Требования к программному обеспечению” - Software Requirements).
Отправной точкой для соблюдения качества является набор индикаторов, соответствующих ожиданиям заинтересованных лиц. На этой стадии (как мы помним, речь идет о планировании проекта) также специфицируются процедуры, связанные с проведением SQA-деятельности (деятельности по обеспечению качества - software quality assurance) на протяжении всех процессов жизненного цикла и для проверки и аттестации (V&V - verification and validation) для получаемого продукта и всех активов (артефактов) проекта (см. область знаний “Качество программного обеспечения” - Software Quality).
2.7 Управление планом проекта (Plan Management)
Наравне с другими аспектами ведения проекта, должно быть определено как проект будет управляться и как будет управляться план проекта. Отчетность, мониторинг и контроль проекта должны соответствовать выбранному процессу программной инженерии и сущности проекта, отражая также в виде различных артефактов именно то, что будет использоваться в процессе управления. При этом, в изменяющемся окружении принципиально важно, чтобы и сам план проекта был управляем. Это требует строгого соблюдения планов, которые должны быть систематически направляемы, контролируемы, оцениваемы, по которым будет вестись отчетность и, там где это применимо, корректируемы. Планы, ассоциированные с другими процессами поддержки, ориентированными на управление, также должны быть управляемы соответствующим образом (например, это касается вопросов документирования, конфигурационного управления и разрешения проблем).
3. Выполнение программного проекта (Software Project Enactment)
План проекта реализуется за счет выполнения процессов, представленных в плане. Следование плану на протяжении выполнения проекта связано с ожиданиями, что соблюдение <корректно составленного> плана приводит к успешному удовлетворению требований заинтересованных лиц и достижению целей проекта. Основой для успешного выполнения проекта является управленческая деятельность по ведению оценки и измерений, мониторинга, контроля и отчетности.
3.1 Реализация планов* (Implementation of Plans)
Проект инициируется и проектные работы выполняются в соответствии с планом. В процессе выполнения используются соответствующие ресурсы (например, усилия персонала, бюджет) и