Индивидуальный план работы — нововведение в планировании, которое может оказаться наиболее полезным средством достижения целей производственных планов. Индивидуальный план работы есть инструмент целевого управления, обеспечивающий фиксацию в письменной форме самим индивидуумом и его непосредственным руководителем конкретных выработанных ими совместно целей и сроков окончания работы и последующий контроль ее завершения или прекращения. Правильно составленный и должным образом контролируемый индивидуальный план работы может соединить в себе целевой, стратегический и тактический планы на основе бюджета, а также учесть перспективы продвижения по службе и повышения квалификации. Это действенное средство одушевления разработки программного изделия и выявления в ней роли каждого участника. Индивидуальные планы работы более эффективны тогда, когда составляются для всех сотрудников на всех уровнях. Такие рабочие планы для иерархической системы управления представляют собой иерархический набор стратегических ц тактических планов, каждый из которых устанавливает, как должны достигаться цели следующего, более высокого уровня иерархии. Для организации с матричной структурой руководители программ, работая совместно с функциональными руководителями, могут зафиксировать все свои цели в соответствующих индивидуальных планах и таким образом устранить многие трения и путаницу, характерные для матричной структуры. Индивидуальные планы работы обсуждаются подробно в разд. 14.3. [c.65]
Наконец, при организации разработки программного изделия следует учесть еще один инструмент, хорошо вписывающийся в индивидуальные рабочие планы, — использование стандартов. Каждый, кто занимался программированием, по достоинству оценивает пользу стандартизации в кодировании и документировании программ. В равной мере важны стандарты управления, помогающие проводить планирование, анализ результатов и оценку эффективности осуществляемых проектов. Для того чтобы иметь возможность проверять полноту планирования и проводить декомпозицию проекта на любом этапе, необходимы системные и процедурные руководства, описывающие как методику проведения разработки, так и методики выполнения связанных друг с другом функций поддержки, выпуска документации и испытаний. [c.89]
Администратор изделия регулирует степень участия каждой из функциональных групп в разработке программного изделия, успешность которой измеряется прежде всего степенью соблюдения ранее установленных технических требований и целей, временных ограничений и допустимых границ затрат. Обычно он выполняет свою роль, начиная с фазы анализа осуществимости и до окончания фазы оценки. В высокоразвитой матричной организации он может быть профессиональным руководителем проекта, ранее участвовавшим в выполнении функции планирования. Но скорее всего ранее он мог быть сотрудником подразделения разработки, где продемонстрировал способность хорошо понимать работы, выполняемые другими людьми. Часто говорят, и, к сожалению, иногда справедливо, что руководитель несет все обязанности и всю ответственность и не имеет никаких полномочий. Работа в матричной организации трудна не только для него, но и для руководителей функциональных групп и для каждого участника проекта. Любой разработчик имеет над собой двух начальников. Необходимость постоянно разрешать двусмысленные положения и конфликты является платой за обеспечение контролируемости проекта. Матричные организации, подобные той, которая показана на рис. 7.2, становятся все более распространенными по мере их роста все больше людей не только приобретают умение приспосабливаться к такой структуре организации, но и становятся ее сторонниками. [c.98]
Ниже речь пойдет о содержании сетевых графиков разработки программного изделия, а не об их форме. Для получения дополнительной информации по теории и применению сетевых методов можно обратиться к работе Арчибальда [55]. Современные тенденции в автоматизации сетевого анализа описаны в трудах Американской ассоциации по управлению [56], а вопросам эффективного использования метода критического пути в управлении программированием посвящена работа Кирка [57]. Материал, изложенный ниже, относится в равной степени к простым и сложным сетям, обрабатываемым вручную или с помощью ЭВМ. Многие организации считают самым простым средством сетевого планирования стандартную сеть для конкретного вида проекта. Стандартная сеть — это типичная совокупность работ, событий и условий, которые охватывают большинство вопросов, представляющих интерес в типичном проекте. В табл. 14.7, 14.8 и на рис. 14.7 показаны стандартный план и сетевой график разработки программного изделия. Отдельные части графика, показанного на рис. 14.7, используются на страницах этой книги для иллюстрации многих вопросов. Эти графики могут служить хорошим подспорьем в реальных проектах при соответствующей корректировке сроков работ и дат событий и добавлений либо исключений тех или иных элементов. [c.262]
Процесс создания новых изделий в условиях машиностроительной промышленности представляет собой единое целое, комплекс работ, преследующих определенную цель — разработку и внедрение в практику новых средств производства или предметов потребления. Для достижения этой цели необходимо выяснение потребности в новых видах продукции, проектирование и разработка конструкции изделия, его освоение производством, стимулирование спроса, а если необходимо, то и обучение потребителей пользованию новой продукцией. Организация такого комплекса работ возможна на основе применения программно-целевого подхода к планированию и организации работ по созданию новой техники. [c.211]
Для планирования и организации процесса создания ПО САПР требуются нормативные данные о распределении трудоемкости и длительности работ по этапам разработки. Они приведены в табл. 4.5 [10] (для трех наиболее применимых в САПР размеров программного изделия). [c.94]
Эту книгу можно прочитать от начала до конца и тем самым полностью ознакомиться с методологией организации проектирования программных изделий. Если же читателя интересуют не все аспекты управления, то можно прочитать лишь отдельные главы (часть II построена по функциональному принципу) и изучить только требуемые функции управления планирование, разработку, обслуживание, выпуск документации, испытания, организацию поддержки или сопровождение. В книге очень широко используется специальная терминология, однако ключевые термины выделяются курсивом и включены в предметный указатель. В каждой главе можно также найти ссылки на литературу для более глубокого обсуждения сложных вопросов, что повышает возможность использования книги в качестве справочного пособия. [c.17]
Имеются весьма основательные доводы в пользу отделения друг от друга некоторых из функций, правильное выполнение которых способствует успешному выпуску изделия. К тому времени, когда почерпнутые из этой книги методы и средства будут введены в действие, такое разграничение функций наверняка можно будет реализовать. И тогда следует удовлетвориться, что группа испытаний работает независимо от группы разработки и потому не подчинена и не может ей подчиняться. Затем следует обособить функцию обслуживания, которая должна в равной степени охватывать обеспечение нормальной деятельности всех остальных групп. При этом, однако, нельзя забывать о планировании, организации поддержки, документирования и сопровождения программных изделий в целях лучшего удовлетворения потребностей пользователя. Если потребности пользователя изменяются, следует без колебаний преобразовывать и эти функции. Приняв такую стратегию, можно-смело приступать к более полной реализации принципов проектирования программного обеспечения и применять методы управления этим процессом точно так же, как их применяют в целом или по частям преуспевающие. руководители. [c.20]
Управление проектированием программного изделия включает семь функций планирование, разработку, обслуживание, выпуск документации, испытания, поддержку и сопровождение. На рис. 5.1 показан возможный вариант иерархической декомпозиции этих функций. Такая идеализированная организация вряд ли может существовать, поскольку она предполагает полную обособленность процессов, связанных с проектированием программных изделий, от других видов деятельности и изолирование всех функций друг от друга. Однако эта идеализация облегчает последующее рассмотрение. Необходимость в том или ином организационном подразделении [c.49]
Некоторые из перечисленных обязанностей группы обслуживания требуют отдельного рассмотрения. Системное обеспечение включает управление планами, т. е. наблюдение за составлением и фактическим выполнением планов в соответствии с целями и задачами организации. Это означает, что по крайней мере один человек — администратор планирования — хотя бы часть своего рабочего времени посвящает контролю и координации планов разработки всех программных изделий. [c.119]
В состав технологической службы вводится также бюро организации и планирования технической подготовки производства, на которое возлагается выполнение задач по разработке сквозных технологических маршрутов и координации всех работ по подготовке и освоению новых изделий. Это подразделение должно стать ведущим планово-координирующим органом службы технического директора. Включение его в отдел комплексной организационно-технологической подготовки (вместо непосредственного подчинения техническому директору) обусловливается характером выполняемых работ, ограниченностью норм управляемости руководителей высшего уровня и возможностью создания развитого механизма горизонтального управления с помощью программно-целевых структур. [c.196]
Планирование, поскольку оно связано с разработкой программных изделий, пронизывает всю структуру корпорации AB . Органы управления корпорации определяют для каждого отдела-задачу и бюджет. Внутри фирмы AB omputers сектор управления сериями изделий задает стратегию, а сектор проектирования систем обеспечивает тактические решения. Фирма AB omputers является убежденным сторонником матричной структуры организации, при этом сектор проектирования систем назначает руководителей проектов, выполняемых в рамках матричной структуры. Группа обслуживания разработки программного обеспечения берет на себя обязанности по координации их деятельности и представлении результатов их совместной работы руководителю сектора программных изделий, который иначе может оказаться в затруднительном положении. [c.42]
Точно так же, как нет необходимости передавать функции контроля документации группе обслуживания, управление планами не обязательно осуществлять в рамках групщл планирования. Глобальное управление выполнением планов может осуществляться в рамках функции обслуживания, но лучше всего осуществлять эту деятельность там, где можно сохранить объективность планов. Управление планами может выполняться как в группе планирования, так и в группе обслуживания, если предположить, что существует внешнее подразделение планирования и отдел, контролирующий программные изделия, а группа обслуживания входит в состав сектора программных изделий. Те элементы процесса управления планами, которые являются глобальными, т. е. выходящими за пределы одного сектора программных изделий, должны выполняться группой обслуживания. Вспомним, например, структуру корпорации AB . Управление планами в ней осуществляется отделом планирования и административного управления (в рамках их обязанностей по управлению производственной деятельностью) и группой обслуживания разработки программного обеспечения (рис. 6.3). Таким образом, в любой организации, занятой созданием программных изделий, должно существовать подразделение с глобальной ответственностью за целевое и стратегическое планирование, управление бюджетом и планами для всей организации. В то же время каждое функциональное подразделение, такое, как отдел разработки программных изделий или отдел сбыта, должно иметь свой собственный персонал тактического планирования и взаимодействия в рамках функции глобального управления планами. [c.70]
Здесь фиксируется информация о том, что было хорошо и что плохо на протяжении жизненного цикла программного изделия. Этот раздел является <золо-той жилой планирования для группы разработки на ранних фазах создания новых программных изделий и полезной основой для организации работы группы сопровождения в фазе использования данного программного изделия. Использование опыта прошлых разработок обеспечивает экономию времени и средств будущем. [c.295]