7-software_engineering_management (1133547), страница 3
Текст из файла (страница 3)
группах, подразделениях, компаниях и т.п.),занимающихся инженерной деятельностью в области программного обеспечения.Рисунок 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 andevaluation) играют действия по мониторингу и контролю процессов - “Monitoring & ControllingProcesses”. Таким образом, с учетом реального содержания секции “Software projectenactment”, ее название и переведено автором как “Выполнение программного проекта”, хотя“enactment” в большей степени подразумевает формальный “запуск” работ.
Конечно, переводмог звучать и как “исполнение” (например, следуя PMBOK), однако, такой перевод, помнению автора, все же несет слишком формальный оттенок, что, субъективно, несоответствует ряду методологических подходов (в первую очередь agile) и культурных“ограничений”.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru6Основы программной инженерии (по SWEBOK)Программная инженерия. Управление программной инженерией.1. Инициирование и определение содержания (Initiation and Scope Definition)Данная секция фокусируется на наборе действий, связанных с эффективным определениемтребований к программному обеспечению с использованием различных методов извлечениятребований, а также оценкой осуществимости проекта с различных точек зрения.
Если проектпризнан осуществимым, следующей задачей является специфицирование процедур проверки иизменения требований (см. область знаний “Требования к программному обеспечению” – SoftwareRequirements).1.1 Определение и обсуждение требований (Determination and Negotiation of Requirements) – выбор иприменение методов определения (извлечения), анализа (например, моделирования сценариев usecase), специфицирования и проверки (например, прототипирования) требований, принимая ввнимание позицию различных заинтересованных лиц. Это является первичными работами,необходимыми для определения содержания, целей и ограничений проекта.
Данные работы важнывсегда, так как позволяют определить четкие границы задач, необходимых для выполнения, вчастности, это особенно заметно для проектов, обладающих большой степенью “новизны” (идет лиречь о технологических аспектах проекта, его масштабах, методах и т.п.).1.2 Анализ осуществимости. Технические, операционные, финансовые, социальные/политическиеаспекты. (Feasibility Analysis.
Technical, Operational, Financial, Social/Political.)Инженеры должны убедиться в том, что для успешного завершения проекта (в заданные сроки, врамках бюджета и т.п.) доступны необходимые возможности (capabilities) и ресурсы, будь то люди (теили иные специалисты), экспертиза (опыт, знания, навыки), средства (например, инструментарий),инфраструктура и поддержка (как внутренняя, так и внешняя, например, со стороны старшихменеджеров организационной структуры, отвечающей за разработку, и ключевых менеджеров илидругих заинтересованных лиц со стороны “заказчика”).
Это часто требует хотя бы приблизительнойоценки усилий и стоимости с использованием соответствующих методов (например, техники, вкоторой экспертная оценка базируется на аналогиях).1.3 Процесс оценки и пересмотра требований (Process of Review and Revision of Requirements)Учитывая неизбежность изменений, жизненно важно определить и согласовать сзаинтересованными лицами процедуры (например, в контексте деятельности по управлениюизменениями) в рамках которых будут проводиться оценка и пересмотр требований. Это однозначнопредполагает, что требования не будут неизменны, но могут и должны корректироваться всоответствии с заданными и детализированными процессами (например, design review – оценкадизайна).
Если изменения приняты, необходимо проводить анализ зависимостей (traceabilityanalysis) и рисков (см. далее тему 2.5 “Управление рисками” – Risk Management) для оценки влияниярассматриваемых изменений. Такой анализ необходимо проводить, в общем случае, и прирассмотрении “изменения” для принятия решения о передачи его “в работу” или отклонении(например, в силу обоснованных причин, таких как проектные решения, позволяющих отметить егокак реализуемое в следующей версии), и уже более детально, если изменение требования(ий)решено реализовать (в силу, например, контрактных обязательств со стороны исполнителя) инеобходимо определить, как именно такое изменение повлияет на существующую систему и какиеработы необходимо выполнить, чтобы удовлетворить обновленному(ым) требованиям. SWEBOKотмечает, что управление изменениями полезно и при оценке результатов проекта (программногопродукта, программной системы), так как содержание и требования формируют основу оценкиуспешности проекта.
(см. также секцию “Контроль конфигураций” области знаний SoftwareConfiguration Management).2. Планирование программного проекта (Software Project Planning)Процесс планирования является итеративным* и базируется на содержании, требованиях и оценкеосуществимости проекта. Здесь стоит напомнить, что различные фазы проекта перекрываются (что,например, специально отмечает PMBOK) и вместе с определением содержания, детализациейтребований и проведением анализа осуществимости, параллельно с этим сам разрабатываемыйплан проекта в той или иной степени детализируется и формируется определенный комплекс работ,Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru7Основы программной инженерии (по SWEBOK)Программная инженерия. Управление программной инженерией.оцениваются необходимые ресурсы и временные границы работ, и т.п. SWEBOK, основываясь натакой позиции, говорит, что при планировании также оцениваются и отбираются соответствующиепроцессы жизненного цикла.
Там где это уместно, проект детализируется в виде структурнойдекомпозиции работ, для которых отмечены ассоциируемых с их завершением результаты и иххарактеристики. Такие характеристики, обычно, связаны с вопросами качества и другимиустановленными атрибутами требований, соблюдением сроков выполнения работ, усилиями,стоимостью и т.д. Ресурсы распределяются по задачам таким образом, чтобы обеспечитьоптимальную продуктивность (на персональном, командном и организационном уровне),использование средств (инфраструктуры, инструментов,...) и оборудования, а также строгоесоблюдение проектного расписания. Также должно проводится управление рисками и, в частности,необходимо определить “профиль рисков”, принятый соответствующими заинтересованнымилицами.
Как составная часть планирования, необходимо определить необходимые процессыобеспечения качества в форме соответствующих процедур и обязанностей (responsibilities) пооценке, проверке, аттестации и аудиту качества (см. область знаний “Качество программногообеспечения” – Software Quality). Безусловно, что должны быть определены процессы и обязанностив части управления планом проекта, его оценкой и порядка пересмотра различных аспектов проекта.* позднее, при обсуждении жизненного цикла и, в частности, спиральной модели разработки,мы будем рассматривать ключевые идеи итеративного подхода.2.1 Планирование процесса (Process Planning)С учетом содержания и требований конкретного проекта необходимо выбрать, адаптировать ииспользовать соответствующую модель процессов жизненного цикла (например, спиральную, сэволюционным прототипированием).
Также должны быть выбраны методы и инструменты. Науровне проекта, методы и инструменты используются для декомпозиции проекта в виде наборазадач (tasks), с ассоциированными входами, выходами и условиями завершения (completion),например, в форме структуры декомпозиции работ – WBS (work breakdown structure). Это влияет навысокоуровневое (первичное) определение проектного расписания и организационной структуры<проектной команды>.2.2 Определение результатов (Determine Deliverables)Должен быть определен результат выполнения каждой задачи (например, описание архитектуры,отчет по анализу, набор тестов и т.п.), то есть какие активы/артефакты мы должны получить повыполнении соответствующей задачи проекта.
При этом оцениваются возможности повторногоиспользования программных компонент, созданных ранее, в процессе разработки другихпрограммных продуктов, и потенциал применения готовых к использованию компонент из 3-ихисточников. Должно быть определено, какие именно компоненты будут использоваться и как онибудут получены (через каких поставщиков).Такие компоненты, обычно, называют “off-the-shelf”, подразумевая в настоящее время не толькокоммерческое, но и общедоступное программное обеспечения, если его использование обоснованов рамках данного проекта.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
