Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Функциональный аудит программных конфигураций (Software Functional Configuration Audit) Цель FCA состоит в том, чтобы убедиться, что контролируемый программный элемент полностью соответствует заданным спецификациям. “Выход”, то есть результат проверки и аттестации (V&V, verification and validation) программного обеспечения является ключевым “входом” (исходными данными) для проведения этого аудита. Физический аудит программных конфигураций (Software Physical Configuration Audit) Цель PCA состоит в том, чтобы убедиться, что дизайн и документация точно согласуются с самим программным продуктом. Внутренние аудиты базовых линий (In-process Audits of Software Baseline) Как уже упоминалось выше, аудиты могут выполняться на протяжении всего процесса разработки для получения текущего статуса заданных элементов конфигураций. В данном случае, аудит может проводиться в отношении к выборочным элементам базовых линий с тем, чтобы убедиться, что соблюдаются заданные спецификациями характеристики процесса, скорости и качества развития продукта, а также того, что документация соответствует и поддерживается в согласованном состоянии с документируемыми элементами продукта в процессе их эволюционирования/на протяжении жизненного цикла. Управление выпуском и поставкой (Software Release Management and Delivery) Термин “релиз” (release, выпуск) используется в данном контексте, подразумевая распространение <и использование> элементов конфигураций за рамками работ по разработке программного обеспечения. Это может включать как внутренние релизы, так и выпуск и передачу программного обеспечения заказчикам. В ситуациях, когда доступны для поставки различные версии программных элементов (в частности, различные версии для разных платформ или редакции с различным набором функциональных возможностей), часто бывает необходимо создавать специализированные версии и пакеты (сборки) соответствующих материалов (элементов, активов) для выпуска в качестве <самостоятельной> версии. Программная библиотека (предоставляющая соответствующий инструментарий для такой сборки) играет ключевую роль в выполнении таких работ. Сборка программного обеспечения (Software Building) Сборка (building) программного обеспечения – деятельность по комбинированию корректных версий элементов программных конфигураций, проводимая с использованием соответствующих конфигурационных данных, с целью получения исполняемой программы (программной системы) для передачи заказчику и/или другим получателям (например, выполняющим работы по тестированию). Исполняемая программа для аппаратных и программно-аппаратных систем получается в результате деятельности по системной сборке (system building). Инструкции по сборке предоставляют описание необходимых для сборки шагов, представленных в заданной (корректной) последовательности. Работы по сборке программного обеспечения выполняются не только для получения нового релиза, но и для повторного создания предыдущих релизов в целях их восстановления, тестирования, сопровождения или каких-либо других необходимых действий. Программное обеспечение собирается с использованием заданных версий таких средств поддержки (supporting tools), как компиляторы. В ряде случаев может требоваться повторная сборка точной копии ранее собранного элемента конфигурации. В этом случае, средства поддержки и ассоциированные инструкции по сборке должны находиться под контролем SCM (подразумевая, в зависимости от контекста, в определенных ситуациях, SCM-систему или только процесс) для обеспечения доступности корректной версии инструментария. Часто бывают полезны возможности инструментов, позволяющие выбирать корректные для заданного окружения версии программных элементов, а также обеспечивать автоматизацию процесса сборки (например, по расписанию) программного обеспечения на основы выбранных версий и соответствующих конфигурационных данных. Такие возможности инструментов особенно необходимы для крупных проектов с параллельной разработкой и/или распределенной средой разработки (географически распределенной команды разработки). Большинство программных средств, обеспечивающих инфраструктуру разработки поддерживают такую возможность (или, как минимум, декларируют ее). Эти инструменты сильно отличаются (по степени комплексности предоставляемого функционала и) по своей сложности, требуя в ряде случаев изучения специализированного (специфичного для конкретного инструмента) языка сценариев, или предоставляя графические возможности, скрывающие сложность настройки “интеллектуальных” средств сборки программного обеспечения. Процесс и результаты сборки могут быть необходимы для последующего использования <в других процессах, работах и проектах> и часто являются объектом верификации (проверки) в рамках деятельности по обеспечению качества (SQA). Управление выпуском программного обеспечения (Software Release Management) Управление выпуском (release management) программного обеспечения охватывает идентификацию, упаковку (сборку) и передачу элементов продукта, например, исполняемых программ, документации, аннотацию релиза (release note) и конфигурационные данные. Понимая, что изменения в продукте происходят постоянно, одной из задач управления выпуском продукта является определение момента времени, когда именно выпускать продукт (в этом контексте, управление выпуском может быть тесно связано как с деятельностью по обеспечению качества, так и с маркетинговыми соображениями в отношении выпускаемого продукта). На это решение также влияет серьезность проблем, решению которых адресуется релиз, и количественная оценка плотности сбоев (fault densities) в предыдущих релизах. Задача упаковки (packaging) состоит в идентификации того, какие элементы продукта должны быть выпущены (например, на основании функциональных требований и их трассировки на элементы конфигурации), и в последующем выборе корректных вариантов этих элементов, задаваемом аспектами применения продукта. Документирование информации о физическом содержании релиза, обычно, включают в документ описания версии (version description document). В свою очередь, аннотация релиза (release note) содержит информацию о новых возможностях, известных проблемах, а также требованиях к платформе(ам), которые необходимо соблюдать для предусмотренного режима эксплуатации продукта. Подготовленный к выпуску пакет (package) также включает инструкции по установке и обновлению <предыдущей версии>. Создание такой инструкции может быть осложнено тем, что некоторые текущие пользователи могут иметь устаревшие версии, более ранние, чем предыдущий выпущенный релиз. Наконец, в ряде случаев, деятельность по управлению выпуском может требовать отслеживание распространения (поставки) продукта различным заказчикам или в рамках заданных целевых систем. Например, возможны ситуации, когда поставщику требуется уведомить заказчика об обнаруженных проблемах. Для поддержки таких функций управления выпуском могут требоваться соответствующие возможности инструментария поддержки (средств поддержки или “вспомогательных средств”, если, например, попытаться максимально приблизиться к русскоязычной терминологии ГОСТ 12207). Также полезна и связь с инструментальными возможностями поддержки процесса обработки запросов на изменения для отображения содержимого релиза на полученные запросы на изменения (SCR - software change request, включая сообщения об обнаруженных ранее и исправленных в данном релизе ошибках, прим. автора). Эти инструментальные средства <поддержки управления выпуском продуктов> также могут поддерживать информацию о различных целевых платформах и <операционном> окружении, используемом у заказчиков. Управление программной инженерией Глава базируется на IEEE Guide to the Software Engineering Body of Knowledge - SWEBOK. Содержит перевод описания области знаний SWEBOK “Software Engineering Management”, с замечаниями и комментариями. Управление программной инженерией (Software Engineering Management) Управление программной инженерией может быть определено как приложение вопросов управления (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) в дорогостоящую, но бесполезную работу. Эффективный менеджмент требует комбинации соответствующих систематических и упорядоченных подходов в управлении и соответствующего опыта 1 например, на практике практически невозможно добиться статуса PMP – Project Management Professional по версии Project Management Institute (PMI), если претендент не обладает серьезным практическим опыт управления проектами и пытается сдать соответствующий экзамен только на основе штудирования PMBOK и теоретических “изысканий”. Прежде, чем детализировать данную область знаний, необходимо дать рабочие определения для понятий “процесс управления” и “измерения”: Процесс управления (Management process) описывает действия (работы - activities), предпринимаемые для обеспечения того, что процессы программной иженерии выполняются в согласовании с политиками, целями и стандартами, принятыми в организации Измерения (Measurement) связаны с определением величин и характеристикой различных аспектов программной инженерии (продуктов, процессов и т.п.), а также разработкой на их основе моделей 2 с использованием статистических методов (и данных), экспертных знаний и других техник. В данном контексте, 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. Область знаний “Управление программной инженерией” [SWEBOK, 2004, с.8- 2, рис. 1] Здесь нельзя не сделать замечание, связанное со структурированием этой области знаний. Обсуждаемая область знаний, действительно, тесно связана с дисциплиной управления проектами. Более того, речь идет о приложении управления проектами к программной инженерии. В этом контексте кажется уместным сопоставить предлагаемый в SWEBOK цикл “Initiation & scope definition – Planning – Enactment – Review & evaluation – Closure” с процессными группами PMBOK “Initiation – Planning – Execution – Monitoring & Controlling – Closing”. Как мы видим, в PMBOK роль работ SWEBOK “Обзор и оценка” (Review and evaluation) играют действия по мониторингу и контролю процессов - “Monitoring & Controlling Processes”. Таким образом, с учетом реального содержания секции “Software project enactment”, ее название и переведено автором как “Выполнение программного проекта”, хотя “enactment” в большей степени подразумевает формальный “запуск” работ. Конечно, перевод мог звучать и как “исполнение” (например, следуя PMBOK), однако, такой перевод, по мнению автора, все же несет слишком формальный оттенок, что, субъективно, не соответствует ряду методологических подходов (в первую очередь agile) и культурных “ограничений”. |