русс | укр

Языки программирования

ПаскальСиАссемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование

Все о программировании


Linux Unix Алгоритмические языки Аналоговые и гибридные вычислительные устройства Архитектура микроконтроллеров Введение в разработку распределенных информационных систем Введение в численные методы Дискретная математика Информационное обслуживание пользователей Информация и моделирование в управлении производством Компьютерная графика Математическое и компьютерное моделирование Моделирование Нейрокомпьютеры Проектирование программ диагностики компьютерных систем и сетей Проектирование системных программ Системы счисления Теория статистики Теория оптимизации Уроки AutoCAD 3D Уроки базы данных Access Уроки Orcad Цифровые автоматы Шпаргалки по компьютеру Шпаргалки по программированию Экспертные системы Элементы теории информации

Синицын И.В., Терновсков В.Б. 13 страница


Дата добавления: 2013-12-23; просмотров: 1082; Нарушение авторских прав


6.2 Планирование процесса измерений (Plan the Measurement Process).................................... 14

6.3 Выполнение процесса измерений (Perform the Measurement Process).................................. 15

6.4 Оценка измерений (Evaluate Measurement)............................................................................ 16

Управление программной инженерией может быть определено как приложение вопросов управления (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. Область знаний “Управление программной инженерией” [SWEBOK, 2004, с.8-2, рис. 1]

 


 

1. Инициирование и определение содержания (Initiation and Scope Definition)

Данная секция фокусируется на наборе действий, связанных с эффективным определением требований к программному обеспечению с использованием различных методов извлечения требований, а также оценкой осуществимости проекта с различных точек зрения. Если проект признан осуществимым, следующей задачей является специфицирование процедур проверки и изменения требований (см. область знаний “Требования к программному обеспечению” - Software Requirements).

1.1 Определение и обсуждение требований (Determination and Negotiation of Requirements) - выбор и применение методов определения (извлечения), анализа (например, моделирования сценариев use case), специфицирования и проверки (например, прототипирования) требований, принимая в внимание позицию различных заинтересованных лиц. Это является первичными работами, необходимыми для определения содержания, целей и ограничений проекта. Данные работы важны всегда, так как позволяют определить четкие границы задач, необходимых для выполнения, в частности, это особенно заметно для проектов, обладающих большой степенью “новизны” (идет ли речь о технологических аспектах проекта, его масштабах, методах и т.п.).

1.2 Анализ осуществимости. Технические, операционные, финансовые, социальные/политические аспекты. (Feasibility Analysis. Technical, Operational, Financial, Social/Political.)

Инженеры должны убедиться в том, что для успешного завершения проекта (в заданные сроки, в рамках бюджета и т.п.) доступны необходимые возможности (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)

Проект инициируется и проектные работы выполняются в соответствии с планом. В процессе выполнения используются соответствующие ресурсы (например, усилия персонала, бюджет) и



<== предыдущая лекция | следующая лекция ==>
Синицын И.В., Терновсков В.Б. 12 страница | Синицын И.В., Терновсков В.Б. 14 страница


Карта сайта Карта сайта укр


Уроки php mysql Программирование

Онлайн система счисления Калькулятор онлайн обычный Инженерный калькулятор онлайн Замена русских букв на английские для вебмастеров Замена русских букв на английские

Аппаратное и программное обеспечение Графика и компьютерная сфера Интегрированная геоинформационная система Интернет Компьютер Комплектующие компьютера Лекции Методы и средства измерений неэлектрических величин Обслуживание компьютерных и периферийных устройств Операционные системы Параллельное программирование Проектирование электронных средств Периферийные устройства Полезные ресурсы для программистов Программы для программистов Статьи для программистов Cтруктура и организация данных


 


Не нашли то, что искали? Google вам в помощь!

 
 

© life-prog.ru При использовании материалов прямая ссылка на сайт обязательна.

Генерация страницы за: 0.008 сек.