Основы Программной Инженерии (по swebok) Введение Программная инженерия как дисциплина swebok руководство
 Скачать 3.21 Mb.
|
|
Инициирование и определение содержания (Initiation and Scope Definition) Данная секция фокусируется на наборе действий, связанных с эффективным определением требований к программному обеспечению с использованием различных методов извлечения требований, а также оценкой осуществимости проекта с различных точек зрения. Если проект признан осуществимым, следующей задачей является специфицирование процедур проверки и изменения требований (см. область знаний “Требования к программному обеспечению” – Software Requirements). Определение и обсуждение требований (Determination and Negotiation of Requirements) – выбор и применение методов определения (извлечения), анализа (например, моделирования сценариев use case), специфицирования и проверки (например, прототипирования) требований, принимая в внимание позицию различных заинтересованных лиц. Это является первичными работами, необходимыми для определения содержания, целей и ограничений проекта. Данные работы важны всегда, так как позволяют определить четкие границы задач, необходимых для выполнения, в частности, это особенно заметно для проектов, обладающих большой степенью “новизны” (идет ли речь о технологических аспектах проекта, его масштабах, методах и т.п.). Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.) Инженеры должны убедиться в том, что для успешного завершения проекта (в заданные сроки, в рамках бюджета и т.п.) доступны необходимые возможности (capabilities) и ресурсы, будь то люди (те или иные специалисты), экспертиза (опыт, знания, навыки), средства (например, инструментарий), инфраструктура и поддержка (как внутренняя, так и внешняя, например, со стороны старших менеджеров организационной структуры, отвечающей за разработку, и ключевых менеджеров или других заинтересованных лиц со стороны “заказчика”). Это часто требует хотя бы приблизительной оценки усилий и стоимости с использованием соответствующих методов (например, техники, в которой экспертная оценка базируется на аналогиях). Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements) Учитывая неизбежность изменений, жизненно важно определить и согласовать с заинтересованными лицами процедуры (например, в контексте деятельности по управлению изменениями) в рамках которых будут проводиться оценка и пересмотр требований. Это однозначно предполагает, что требования не будут неизменны, но могут и должны корректироваться в соответствии с заданными и детализированными процессами (например, design review – оценка дизайна). Если изменения приняты, необходимо проводить анализ зависимостей (traceability analysis) и рисков (см. далее тему 2.5 “Управление рисками” – Risk Management) для оценки влияния рассматриваемых изменений. Такой анализ необходимо проводить, в общем случае, и при рассмотрении “изменения” для принятия решения о передачи его “в работу” или отклонении (например, в силу обоснованных причин, таких как проектные решения, позволяющих отметить его как реализуемое в следующей версии), и уже более детально, если изменение требования(ий) решено реализовать (в силу, например, контрактных обязательств со стороны исполнителя) и необходимо определить, как именно такое изменение повлияет на существующую систему и какие работы необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOK отмечает, что управление изменениями полезно и при оценке результатов проекта (программного продукта, программной системы), так как содержание и требования формируют основу оценки успешности проекта. (см. также секцию “Контроль конфигураций” области знаний Software Configuration Management). Планирование программного проекта (Software Project Planning) Процесс планирования является итеративным 2 и базируется на содержании, требованиях и оценке осуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что, например, специально отмечает PMBOK) и вместе с определением содержания, детализацией требований и проведением анализа осуществимости, параллельно с этим сам разрабатываемый план проекта в той или иной степени детализируется и формируется определенный комплекс работ, оцениваются необходимые ресурсы и временные границы работ, и т.п. SWEBOK, основываясь на такой позиции, говорит, что при планировании также оцениваются и отбираются соответствующие процессы жизненного цикла. Там где это уместно, проект детализируется в виде структурной декомпозиции работ, для которых отмечены ассоциируемых с их завершением результаты и их характеристики. Такие характеристики, обычно, связаны с вопросами качества и другими установленными атрибутами требований, соблюдением сроков выполнения работ, усилиями, стоимостью и т.д. Ресурсы распределяются по задачам таким образом, чтобы обеспечить оптимальную продуктивность (на персональном, командном и организационном уровне), использование средств (инфраструктуры, инструментов,…) и оборудования, а также строгое соблюдение проектного расписания. Также должно проводится управление рисками и, в частности, необходимо определить “профиль рисков”, принятый соответствующими заинтересованными лицами. Как составная часть планирования, необходимо определить необходимые процессы обеспечения качества в форме соответствующих процедур и обязанностей (responsibilities) по оценке, проверке, аттестации и аудиту качества (см. область знаний “Качество программного обеспечения” – Software Quality). Безусловно, что должны быть определены процессы и обязанности в части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта. позднее, при обсуждении жизненного цикла и, в частности, спиральной модели разработки, мы будем рассматривать ключевые идеи итеративного подхода. Планирование процесса (Process Planning) С учетом содержания и требований конкретного проекта необходимо выбрать, адаптировать и использовать соответствующую модель процессов жизненного цикла (например, спиральную, с эволюционным прототипированием). Также должны быть выбраны методы и инструменты. На уровне проекта, методы и инструменты используются для декомпозиции проекта в виде набора задач (tasks), с ассоциированными входами, выходами и условиями завершения (completion), например, в форме структуры декомпозиции работ – WBS (work breakdown structure). Это влияет на высокоуровневое (первичное) определение проектного расписания и организационной структуры <проектной команды>. Определение результатов (Determine Deliverables) Должен быть определен результат выполнения каждой задачи (например, описание архитектуры, отчет по анализу, набор тестов и т.п.), то есть какие активы/ артефакты мы должны получить по выполнении соответствующей задачи проекта. При этом оцениваются возможности повторного использования программных компонент, созданных ранее, в процессе разработки других программных продуктов, и потенциал применения готовых к использованию компонент из 3-их источников. Должно быть определено, какие именно компоненты будут использоваться и как они будут получены (через каких поставщиков). Такие компоненты, обычно, называют “off-the-shelf”, подразумевая в настоящее время не только коммерческое, но и общедоступное программное обеспечения, если его использование обосновано в рамках данного проекта. Анализ и выбор соответствующих компонент может и, в подавляющем большинстве случаев, должен рассматриваться как самостоятельная задача процесса планирования в контексте сформулированных высокоуровневых требований, определенного содержания и базовых ограничений проекта, таких как сроки, ресурсы, стоимость). Это позволяет четко разделить, в том числе, в контексте затрат, что именно будет разрабатываться самостоятельно (может быть как отдельный “подпроект”), что будет использоваться из 3-их источников (3rd party), а что будет являться содержательным (с точки зрения проекта) результатом работ, то есть его непосредственным активом, обладающим, например, функциональной, для данного проекта, нагрузкой. Оценка усилий, расписания и стоимостных ожиданий (Efforts,Schedule and Cost Estimation) Ожидаемые пределы усилий, необходимых для решения каждой задачи (task) проекта основываются на разбиении задач, их входах и выходах. Для этого используется калиброванная (calibrated - настроенная для заданных условий) модель ожиданий (estimation model), базирующаяся на исторических данных по усилиям, связанным с объемом задачи (size-effort historical data, часто определяется как человеко-месяцы к функциональным точкам или количеству строк кода). Также, для оценки усилий могут применяться и другие методы, например, экспертная оценка или оценка по типу приложения (встроенное, телекоммуникационное), квалификации проектной группы и т.п. Кроме того, необходимо идентифицировать связи и зависимости между задачами (tasks dependencies) и потенциально критические аспекты (bottlenecks) проекта. Такие работы могут быть проведены с использованием, например, метода анализ критического пути (critical path analysis – достаточно распространенный метод, относящийся к общей дисциплине управления проектами, применимый и для проектов программных систем). Если возможно, критические аспекты должны быть разрешены, а для задач определены ожидаемые сроки выполнения (расписание), включающие начало, длительность и окончание (например, в форме PERT- диаграмм*). PERT анализ (Program, Evaluation, and Review Technique) – техника оценки ожиданий в отношении длительности (duration) задач проекта, проводимая на основе определения среднего весового значения трех оценок длительности - пессимистической, оптимистической и ожидаемой (то есть наиболее вероятной, при первичной оценке). Аналогичная техника может и часто используется для оценки усилий (effort), необходимых для реализации задачи. Наибольший эффект дает сочетание различных методов оценки. В то же самое время, чем больше методов оценки используется, тем более трудоемкой (а, следовательно, и ресурсоемкой) становится такая работа, поэтому задача менеджмента – определить наиболее оптимальный и эффективный для данного проекта набор методов и техник, используемых в процессе планирования и корректировки. Требования к ресурсам (люди, инструменты) транслируются в стоимостные ожидания. В совокупности, вся эта деятельность является итеративной и должна обсуждаться и проводиться до тех пор, пока не будет достигнут консенсус между соответствующими заинтересованными лицами – в первую очередь, менеджментом <проекта> и инженерами <входящими в команду проекта>. Распределение ресурсов (Resource Allocation) С задачами (для которых назначены сроки), должны быть ассоциированы оборудование, средства и, конечно, люди. Это подразумевает распределение (назначение или принятие, в зависимости от стиля и формы управления) обязанностей/ответственности. Для этого может, например, использоваться диаграмма Ганта (Gantt chart). Эта деятельность определяется и ограничивается доступностью ресурсов, их оптимальным использованием в заданном контексте и вопросами, связанными с персоналом (например, продуктивностью конкретных лиц и группы, в целом, организационной и командной структурой, подразумевая специфику коллектива, наравне со штатным расписанием и другие вопросы). Крайне необходимо выделить как самостоятельную тему данной секции вопросы управления персоналом – people management, уделив особое внимание аспектам экспертизы (не стоит путать с ролями/обязанностями) и лидерства специалистов в проектной команде. К этой же теме, также стоит отнести вопросы обучения, прохождения тренингов специалистами проектной команды. Наконец, к теме ресурсов имеет непосредственное отношение и определение необходимости и объема привлечения внешних консультантов (не являющихся сотрудниками ни исполнителя, ни заказчика), к сожалению, не упоминаемое здесь в SWEBOK, но крайне важное, по опыту автора, для успешности проекта, обладающего высокой степенью новизны (например, в терминах используемых технологий и, особенно, применения тех или иных архитектурных решений). Управление рисками (Risk Management) В части управления рисками должны проводиться: идентификация и анализ рисков - что, когда и почему может быть сделано неверно и к чему это может привести; оценка критических рисков - какие из рисков наиболее значительны (если им не уделять должного внимания) и что необходимо сделать, чтобы их избежать; смягчение рисков (risk mitigation) и планируемость непредвиденных обстоятельств (contingency planning) – формирование стратегии, касающейся рисков и управление профилями рисков. Для идентификации и оценки рисков необходимо применять соответствующие методы и техники (например, построение дерева решений – decision tree или моделирование процессов – process simulation). Кроме того, со всеми заинтересованными лицами необходимо определить правила и политики прекращения проекта. Наравне с идеями общего управления рисками, важно понимать и управлять рисками, уникальными для деятельности в области программной инженерии, например, тенденция добавлять в получаемый программный продукт функциональные и другие возможности, неопределенные на уровне требований или риски, заложенные в самой природе программного обеспечения, связанные, в первую очередь с его сложностью и архитектурно-технологической новизной, присутствующей, в той или иной степени, в любом программном проекте. Управление качеством (Quality Management) Качество определяется в терминах атрибутов, значимых для данного конкретного проекта и/или ассоциированного с ним продукта. Атрибуты могут выражаться как качественно, так и количественно. Эти характеристики качества определяются в спецификации требований к программному обеспечению (см. область знаний “Требования к программному обеспечению” – Software Requirements). Отправной точкой для соблюдения качества является набор индикаторов, соответствующих ожиданиям заинтересованных лиц. На этой стадии (как мы помним, речь идет о планировании проекта) также специфицируются процедуры, связанные с проведением SQA-деятельности (деятельности по обеспечению качества – software quality assurance) на протяжении всех процессов жизненного цикла и для проверки и аттестации (V&V – verification and validation) для получаемого продукта и всех активов (артефактов) проекта (см. область знаний “Качество программного обеспечения” – Software Quality). Управление планом проекта (Plan Management) Наравне с другими аспектами ведения проекта, должно быть определено как проект будет управляться и как будет управляться план проекта. Отчетность, мониторинг и контроль проекта должны соответствовать выбранному процессу программной инженерии и сущности проекта, отражая также в виде различных артефактов именно то, что будет использоваться в процессе управления. При этом, в изменяющемся окружении принципиально важно, чтобы и сам план проекта был управляем. Это требует строгого соблюдения планов, которые должны быть систематически направляемы, контролируемы, оцениваемы, по которым будет вестись отчетность и, там где это применимо, корректируемы. Планы, ассоциированные с другими процессами поддержки, ориентированными на управление, также должны быть управляемы соответствующим образом (например, это касается вопросов документирования, конфигурационного управления и разрешения проблем). Выполнение программного проекта (Software Project Enactment) План проекта реализуется за счет выполнения процессов, представленных в плане. Следование плану на протяжении выполнения проекта связано с ожиданиями, что соблюдение <корректно составленного> плана приводит к успешному удовлетворению требований заинтересованных лиц и достижению целей проекта. Основой для успешного выполнения проекта является управленческая деятельность по ведению оценки и измерений, мониторинга, контроля и отчетности. Реализация планов 4 (Implementation of Plans) Проект инициируется и проектные работы выполняются в соответствии с планом. В процессе выполнения используются соответствующие ресурсы (например, усилия персонала, бюджет) и производятся необходимые результаты (deliverables; активы, артефакты проекта – например, архитектурные документы, тестовые сценарии). в SWEBOK используется как “план проекта” в единственном числе, так и “планы” – во множественном числе, подразумевающие, судя по контексту, отдельные задачи проекта. Управление контрактами с поставщиками (Supplier Contract Management) Включает подготовку и выполнение соглашений с поставщиками, мониторинг деятельности поставщиков, принятие у поставщиков продуктов, использование и интеграцию этих продуктов в рамках проектных работ. Реализация процесса по ведению измерений (Implementation of Measurement Process) Данный процесс выполняется на протяжении всего проекта, обеспечивая сбор всех необходимых данных (см. 6.2 Plan the Measurement Process и 6.3 Perform the Measurement Process). Процесс мониторинга (Monitor Process) Соблюдение плана проверяется постоянно и через предопределенные интервалы времени. Анализируются выходы (outputs) и условия завершения <задач>. Получаемые <в процессе измерений> результаты оцениваются в терминах требуемых характеристик (например, через процедуры обзора/оценки и аудита – review, audit). Затраты усилий (efforts), соблюдения расписания, стоимость к данному моменту, используемые ресурсы – все это исследуется к каждой дате оценки. При этом, оценивается и корректируется профиль рисков, а также, производится проверка удовлетворения требований качества. Моделируются и анализируются данные измерений. Анализ расхождений (variance analysis) <плана с реальным выполнением проекта> базируется на оценке отклонений реальных данных от планируемых и ожидаемых. Такой анализ может проводиться в отношении оценки перерасхода средств (cost overrun), нарушения расписания и других важных характеристик – ограничений проекта Часто выполняется “внешний” (например, с привлечением представителей заказчика) анализ качества и других измеряемых данных (например, анализ плотности дефектов – defect density analysis). Проводится повторное (уточняющее) выявление рисков и оценка их последствий (risk exposure and leverage), разрабатывается дерево решений, проводится моделирование (рисков и действий по их предотвращению) и другие работы – уже в контексте полученных данных. Все эти работы позволяют обнаруживать проблемы и идентифицировать исключения, основываясь на выходе за рамки приемлемых границ тех или иных параметров проекта (в частности, характеристик качества). Отчетность по результатам создается в соответствие с планом, а также, при выходе за заданные ограничения проекта или параметров отдельных его работ. Хотелось бы обратить внимание на то, что современная практика управления проектами, в частности, разработки и сопровождения программного обеспечения, требует обеспечения возможности доступна к актуальным данным по проекту в любой момент времени. По-сути в настоящее время возникает целый класс интегрированных инструментов и специализированных продуктов, часто называемый project dashboard (наиболее близкий перевод этого понятия на русский язык может звучать как “панель управления проектом”). Обычно, такие инструменты не только работают со “снимками” данных, сводя их воедино, но обращаются непосредственно к данным в системах конфигурационного управления, управления требованиями, сценариями тестирования, аудита кода, расписания проекта в соответствующих средствах управления проектами и т.п. |