7-software_engineering_management (1133547), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

Анализ и выбор соответствующих компонент может и, в подавляющембольшинстве случаев, должен рассматриваться как самостоятельная задача процесса планированияв контексте сформулированных высокоуровневых требований, определенного содержания и базовыхограничений проекта, таких как сроки, ресурсы, стоимость). Это позволяет четко разделить, в томчисле, в контексте затрат, что именно будет разрабатываться самостоятельно (может быть какотдельный “суб-проект”), что будет использоваться из 3-их источников (3rd party), а что будетявляться содержательным (с точки зрения проекта) результатом работ, то есть егонепосредственным активом, обладающим, например, функциональной, для данного проекта,нагрузкой.2.3 Оценка усилий, расписания и стоимостных ожиданий (Efforts,Schedule and Cost Estimation)Ожидаемые пределы усилий, необходимых для решения каждой задачи (task) проекта основываютсяна разбиении задач, их входах и выходах.

Для этого используется калиброванная (calibrated настроенная для заданных условий) модель ожиданий (estimation model), базирующаяся наCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru8Основы программной инженерии (по SWEBOK)Программная инженерия. Управление программной инженерией.исторических данных по усилиям, связанным с объемом задачи (size-effort historical data, частоопределяется как человеко-месяцы к функциональным точкам или количеству строк кода).

Также,для оценки усилий могут применяться и другие методы, например, экспертная оценка или оценка потипу приложения (встроенное, телекоммуникационное), квалификации проектной группы и т.п.Кроме того, необходимо идентифицировать связи и зависимости между задачами (tasksdependencies) и потенциально критические аспекты (bottlenecks) проекта. Такие работы могут бытьпроведены с использованием, например, метода анализ критического пути (critical path analysis –достаточно распространенный метод, относящийся к общей дисциплине управления проектами,применимый и для проектов программных систем). Если возможно, критические аспекты должныбыть разрешены, а для задач определены ожидаемые сроки выполнения (расписание), включающиеначало, длительность и окончание (например, в форме PERT-диаграмм*).* PERT анализ (Program, Evaluation, and Review Technique) – техника оценки ожиданий вотношении длительности (duration) задач проекта, проводимая на основе определениясреднего весового значения трех оценок длительности - пессимистической, оптимистическойи ожидаемой (то есть наиболее вероятной, при первичной оценке).

Аналогичная техникаможет и часто используется для оценки усилий (effort), необходимых для реализации задачи.Наибольший эффект дает сочетание различных методов оценки. В то же самое время, чембольше методов оценки используется, тем более трудоемкой (а, следовательно, иресурсоемкой) становится такая работа, поэтому задача менеджмента – определитьнаиболее оптимальный и эффективный для данного проекта набор методов и техник,используемых в процессе планирования и корректировки.Требования к ресурсам (люди, инструменты) транслируются в стоимостные ожидания.В совокупности, вся эта деятельность является итеративной и должна обсуждаться и проводиться дотех пор, пока не будет достигнут консенсус между соответствующими заинтересованными лицами –в первую очередь, менеджментом <проекта> и инженерами <входящими в команду проекта>.2.4 Распределение ресурсов (Resource Allocation)С задачами (для которых назначены сроки), должны быть ассоциированы оборудование, средства и,конечно, люди.

Это подразумевает распределение (назначение или принятие, в зависимости отстиля и формы управления) обязанностей/ответственности. Для этого может, например,использоваться диаграмма Ганта (Gantt chart). Эта деятельность определяется и ограничиваетсядоступностью ресурсов, их оптимальным использованием в заданном контексте и вопросами,связанными с персоналом (например, продуктивностью конкретных лиц и группы, в целом,организационной и командной структурой, подразумевая специфику коллектива, наравне соштатным расписанием и другие вопросы).Крайне необходимо выделить как самостоятельную тему данной секции вопросы управленияперсоналом – people management, уделив особое внимание аспектам экспертизы (не стоитпутать с ролями/обязанностями) и лидерства специалистов в проектной команде. К этой жетеме, также стоит отнести вопросы обучения, прохождения тренингов специалистамипроектной команды.

Наконец, к теме ресурсов имеет непосредственное отношение иопределение необходимости и объема привлечения внешних консультантов (неявляющихся сотрудниками ни исполнителя, ни заказчика), к сожалению, не упоминаемоездесь в SWEBOK, но крайне важное, по опыту автора, для успешности проекта, обладающеговысокой степенью новизны (например, в терминах используемых технологий и, особенно,применения тех или иных архитектурных решений).2.5 Управление рисками (Risk Management)В части управления рисками должны проводиться: идентификация и анализ рисков - что, когда и почему может быть сделано неверно и к чемуэто может привести; оценка критических рисков - какие из рисков наиболее значительны (если им не уделятьдолжного внимания) и что необходимо сделать, чтобы их избежать;Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия. Управление программной инженерией.смягчение рисков (risk mitigation) и планируемость непредвиденных обстоятельств(contingency planning) – формирование стратегии, касающейся рисков и управлениепрофилями рисков.Для идентификации и оценки рисков необходимо применять соответствующие методы и техники(например, построение дерева решений – decision tree или моделирование процессов – processsimulation).

Кроме того, со всеми заинтересованными лицами необходимо определить правила иполитики прекращения проекта.Наравне с идеями общего управления рисками, важно понимать и управлять рисками, уникальнымидля деятельности в области программной инженерии, например, тенденция добавлять в получаемыйпрограммный продукт функциональные и другие возможности, неопределенные на уровнетребований или риски, заложенные в самой природе программного обеспечения, связанные, впервую очередь с его сложностью и архитектурно-технологической новизной, присутствующей, в тойили иной степени, в любом программном проекте.2.6 Управление качеством (Quality Management)Качество определяется в терминах атрибутов, значимых для данного конкретного проекта и/илиассоциированного с ним продукта.

Атрибуты могут выражаться как качественно, так и количественно.Эти характеристики качества определяются в спецификации требований к программномуобеспечению (см. область знаний “Требования к программному обеспечению” – SoftwareRequirements).Отправной точкой для соблюдения качества является набор индикаторов, соответствующихожиданиям заинтересованных лиц. На этой стадии (как мы помним, речь идет о планированиипроекта) также специфицируются процедуры, связанные с проведением SQA-деятельности(деятельности по обеспечению качества – software quality assurance) на протяжении всех процессовжизненного цикла и для проверки и аттестации (V&V – verification and validation) для получаемогопродукта и всех активов (артефактов) проекта (см. область знаний “Качество программногообеспечения” – Software Quality).2.7 Управление планом проекта (Plan Management)Наравне с другими аспектами ведения проекта, должно быть определено как проект будетуправляться и как будет управляться план проекта.

Отчетность, мониторинг и контроль проектадолжны соответствовать выбранному процессу программной инженерии и сущности проекта,отражая также в виде различных артефактов именно то, что будет использоваться в процессеуправления. При этом, в изменяющемся окружении принципиально важно, чтобы и сам план проектабыл управляем. Это требует строгого соблюдения планов, которые должны быть систематическинаправляемы, контролируемы, оцениваемы, по которым будет вестись отчетность и, там где этоприменимо, корректируемы.

Планы, ассоциированные с другими процессами поддержки,ориентированными на управление, также должны быть управляемы соответствующим образом(например, это касается вопросов документирования, конфигурационного управления и разрешенияпроблем).3. Выполнение программного проекта (Software Project Enactment)План проекта реализуется за счет выполнения процессов, представленных в плане. Следованиеплану на протяжении выполнения проекта связано с ожиданиями, что соблюдение <корректносоставленного> плана приводит к успешному удовлетворению требований заинтересованных лиц идостижению целей проекта.

Основой для успешного выполнения проекта является управленческаядеятельность по ведению оценки и измерений, мониторинга, контроля и отчетности.3.1 Реализация планов* (Implementation of Plans)Проект инициируется и проектные работы выполняются в соответствии с планом. В процессевыполнения используются соответствующие ресурсы (например, усилия персонала, бюджет) иCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия. Управление программной инженерией.производятся необходимые результаты (deliverables; активы, артефакты проекта – например,архитектурные документы, тестовые сценарии).* в SWEBOK используется как “план проекта” в единственном числе, так и “планы” – вомножественном числе, подразумевающие, судя по контексту, отдельные задачи проекта.3.2 Управление контрактами с поставщиками (Supplier Contract Management)Включает подготовку и выполнение соглашений с поставщиками, мониторинг деятельностипоставщиков, принятие у поставщиков продуктов, использование и интеграцию этих продуктов врамках проектных работ.3.3 Реализация процесса по ведению измерений (Implementation of Measurement Process)Данный процесс выполняется на протяжении всего проекта, обеспечивая сбор всех необходимыхданных (см.

6.2 Plan the Measurement Process и 6.3 Perform the Measurement Process).3.4 Процесс мониторинга (Monitor Process)Соблюдение плана проверяется постоянно и через предопределенные интервалы времени.Анализируются выходы (outputs) и условия завершения <задач>. Получаемые <в процессеизмерений> результаты оцениваются в терминах требуемых характеристик (например, черезпроцедуры обзора/оценки и аудита – review, audit). Затраты усилий (efforts), соблюдения расписания,стоимость к данному моменту, используемые ресурсы – все это исследуется к каждой дате оценки.При этом, оценивается и корректируется профиль рисков, а также, производится проверкаудовлетворения требований качества.Моделируются и анализируются данные измерений.

Анализ расхождений (variance analysis) <плана среальным выполнением проекта> базируется на оценке отклонений реальных данных отпланируемых и ожидаемых. Такой анализ может проводиться в отношении оценки перерасходасредств (cost overrun), нарушения расписания и других важных характеристик – ограничений проектаЧасто выполняется “внешний” (например, с привлечением представителей заказчика) анализкачества и других измеряемых данных (например, анализ плотности дефектов – defect densityanalysis). Проводится повторное (уточняющее) выявление рисков и оценка их последствий (riskexposure and leverage), разрабатывается дерево решений, проводится моделирование (рисков идействий по их предотвращению) и другие работы – уже в контексте полученных данных. Все этиработы позволяют обнаруживать проблемы и идентифицировать исключения, основываясь навыходе за рамки приемлемых границ тех или иных параметров проекта (в частности, характеристиккачества).

Характеристики

Список файлов книги