ОРГАНИЗАЦИИ РАЗЛИЧНЫХ ОТРАСЛЕЙ ПРОМЫШЛЕННОСТИ

ОРГАНИЗАЦИИ РАЗЛИЧНЫХ ОТРАСЛЕЙ ПРОМЫШЛЕННОСТИ

На рис. 11.1 показано распределение ролей и обязанностей в обычной промышленной организации. Эта структура может адаптироваться к конкретным обстоятельствам.
Обычная организация имеет следующие основные особенности:.
■ Ответственность за описание процесса и его сопровождение специфична для конкретного направления бизнеса, где имеет смысл говорить об общности процессов. Например, процесс разработки ПО для авиации отличен от процесса, используемого для разработки офисных приложений.
Рис. 11.1. Стандартные роли в организации.
■ Ответственность за автоматизацию процесса — это организационная роль, которая по важности равна роли определения процесса. Проекты достигают общности процессов прежде всего за счет поддержки общего инструментария.
■ Организационные роли могут выполняться отдельным индивидуумом или несколькими различными командами, в зависимости от масштаба организации. Компании по производству ПО со штатом 20 человек может хватить одного человека для выполнения всех ролей, в то время как телекоммуникационной компании со штатом в 10 ООО человек требуются сотни людей для создания эффективной организации по разработке ПО.
Ответственный за процесс разработки ПО.
Ответственный за процесс разработки ПО (Software Engineering Process Authority, SEPA) обеспечивает обмен информацией и руководствами по процессу между практиками, занимающимися проектом. Это лицо отвечает перед руководителем организации за выполнение текущих оценок зрелости процесса в данной организации и за планирование дальнейшего его развития. SEPA должен оказывать помощь при инициировании проекта и периодически оценивать его процессы. Распространение лучшей практики при создании ПО может выполняться только в том случае, если SEPA понимает как само необходимое улучшение, так и особенности конкретного проекта. Он является ответственным и подотчетным за определение процесса и его сопровождение (модификацию, совершенствование, внедрение новых технологий). Функции SEPA могут выполняться отдельным лицом, руководителем организации либо целой командой представителей. SEPA должен действительно быть ответственным — компетентным и обладающим властью, — а не бессильным перед неэффективной бюрократией должностным лицом.
Ответственный за проверку проекта.
Ответственный за проверку проекта (Project Review Authority, PRA) — отдельное лицо, отвечающее за то, чтобы проект по созданию ПО подчинялся всем организационным и экономическим правилам, практике и стандартам, касающимся ПО. Менеджер проекта по созданию ПО ответственен за соблюдение требований контракта или каких-то других стандартов, которым подчиняется проект, и подотчетен PRA. PRA рассматривает вопросы соответствия проекта как контрактным обязательствам, так и обязательствам, вытекающим из организационной политики проекта. Заказчик следит за требованиями контракта, контрольными точками, контрактными обязательствами, ежемесячным анализом состояния управления проектом, прогрессом, качеством, затратами, сроками и риском. PRA рассматривает поручения заказчика, а также следит за строгим соблюдением политики организации, выполнением финансовых условий и за другими рисками и аспектами.
Ответственный за среду разработки ПО.
Ответственный за среду разработки ПО (Software Engineering Environment Authority, SEEA) отвечает за автоматизацию процесса, сопровождение стандартной среды, обучение пользованию средой и сопровождение в организации наработок, пригодных для повторного использования. Роль, которую выполняет SEEA, необходима для достижения высокого уровня отдачи от вложенных ресурсов для обычного процесса. Инструменты, методы и обучение могут эффективно амортизироваться на протяжении нескольких проектов только в том случае, если кто-то (например, SEEA) будет отвечать за сопровождение и администрирование стандартной среды. Во многих случаях среда может быть улучшена, изменена по требованию или модифицирована, однако существование готового на 80% решения для каждого проекта критично для утверждения процесса, используемого организацией, и для обеспечения хорошего ROI от инструментов.
Инфраструктура.
Инфраструктура организации обеспечивает поддержку людских ресурсов, независимые от проектов исследования и разработки, а также другие важнейшие направления, связанные с созданием ПО. Она может изменяться в диапазоне от тривиальной до глубоко окопавшейся бюрократии. Типичными компонентами организационной инфраструктуры являются следующие:.
■ Администрирование проекта: система учета времени; контракты, цены, сроки и условия; интеграция в корпоративные информационные системы.
■ Инновационные центры: поддержка инструментария, заявок и предложений, независимые исследования и разработки.
■ Профессиональный рост: внутренний выездной лагерь для обучения, найм персонала, сопровождение базы данных по квалификации персонала, библиотека специальной литературы, публикации.
Сервисный центр организации обеспечивает стандартную среду, которая финансируется за счет основного бизнеса и поддерживается в качестве основных фондов для всех проектов, выполняемых в рамках организации. SEEA является компаньоном SEP A. SEPA отвечает за определение и усовершенствование процесса, a SEEA — за автоматизацию процесса.
Представляется важным, чтобы менеджеры организации рассматривали среду для разработки ПО так же, как технические средства, т.е. как оборудование, входящее в основные фонды. В большинстве мелких и незрелых организаций существует сопротивление такому подходу; в них специальная разработка процесса и инструментальное обеспечение относятся к прямым затратам проекта. В зрелых организациях, занимающихся созданием ПО, процесс и инструментальное обеспечение должны являться основными фондами организации так же, как это происходит в других инженерных дисциплинах. А раз так, то они должны.
Проектные организации и распределение обязанностей.
финансироваться из капитальных ресурсов. Финансовые модели могут предполагать включение этих затрат в накладные расходы или в общие и административные затраты либо в смету проекта, основанную на его выполнении. В сегодняшней индустрии ПО, характеризующейся устаревшими методами отчетности, финансированием обеспечения инструментами за счет проектов и методами лицензирования ПО, относительно небольшое количество организаций перешло на подобную модель капитальных вложений для своих программных сред. Такими организациями являются, как правило, достаточно зрелые, крупномасштабные организации-разработчики ПО, которые достигли стабильного определения процесса и установили долговременное сотрудничество с поставщиками инструментальных средств.