Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
ТРПО учебное пособие.doc
Скачиваний:
36
Добавлен:
22.08.2019
Размер:
3.13 Mб
Скачать

8.1.2 Нисходящий анализ процесса управления проектированием программного изделия

Управление проектированием программного изделия включает в себя следующие функции:

  • планирование;

  • разработку;

  • обслуживание;

  • выпуск документации;

  • испытания;

  • поддержку;

  • сопровождение;

Иерархическая декомпозиция управления разработкой программного изделия может быть представлена следующим образом (рис. 8.1).

Рис. 8.1 — Декомпозиция управления

Такая идеализированная организация требует полной обособленности процессов, связанных с проектированием, от других видов деятельности и изолированности всех функций друг от друга. Естественно, что на практике это не реализуемо.

Каждая организация должна иметь администратора (директора), именно он несет ответственность за успех и неудачу разработки. В структуре также должно существовать то или иное важное направление деятельности, включая функцию разработки. Лицо, которое руководит этим направлением, считается ответственным за все аспекты создания изделия, выпускаемого организацией. Чтобы координировать процесс разработки, это лицо имеет право назначать администраторов изделия и руководителей проектов и обеспечивать их взаимодействие.

8.1.3 Организация взаимодействия

Если все взаимодействия хорошо определены, то и управление ими организовано должным образом. Если же взаимодействия плохо организованы, то даже при жесткой линейной структуре подчинения трудно будет создать конечное изделие.

Важнейшим принципом любого вида управления является разделение целого на части, и многие методы и средства основываются именно на этом принципе.

Совокупность точек, в которых две функциональные группы взаимодействуют друг с другом, называется организационной границей. Иногда функция может иметь один канал взаимодействия со всеми остальными функциями, однако более вероятно, что она имеет несколько границ соприкосновения. Границы функции определяются множеством зафиксированных и незафиксированных планов, стратегий, процедур, которые определяют функциональные обязанности. Чем больше сведений фиксируется в письменном виде, тем лучше, т.к. это уменьшает двусмысленность. Основное свойство организационной границы состоит в разграничении ответственности (кто и что делает, каким образом, для чего и т.д.). Неполное определение, двусмысленность и сложность приводят к невозможности описания, а следовательно, и понимания природы взаимодействия.

Но ни сами документы, ни их коллективное обсуждение не могут обеспечить действенных взаимосвязей, если отсутствуют контакты функциональных групп.

Общие организационные обязанности могут устанавливаться с помощью должностных инструкций и целевых планов подразделений. Конкретные обязанности определяются планами выпуска изделия. Пропорциональное распределение ответственности обеспечивается соответствующими стратегиями управления. В них обязательно должны предусматриваться возможности невыполнения взятых обязательств и учитываться поправки на исключительные случаи, чтобы сделать планы и процедуры жизнеспособными.

8.1.4 Установление целей, средства их достижения

Первым шагом процесса установления и достижения целей является подбор необходимого персонала. Когда в организации происходят изменения, соответственно меняется и ее персонал. Некоторые изменения происходят периодически. Подобные изменения характеризуются экспоненциальным ростом числа устанавливаемых связей. Чтобы приспособиться к этим колебаниям, нужны руководители, способные к адаптации. Руководителей, продуктивных только в каком-либо одном виде деятельности, нужно заменять. Программирование — область деятельности, требующая высокой квалификации, оно привлекает к себе неординарных, эксцентричных людей. Такие люди редко понимают структуру организации, ориентированную на создание программного продукта, часто отказываются работать в условиях ограничения свободы творчества, т.к. они вынуждены тратить время на документирование или защиту своих разработок. Однако их участие в «черновой работе» необходимо, и чтобы склонить этих людей к работе, необходимо комплектовать штат, руководствуясь соображениями эффективности. Это означает отход от идеальных установленных общих правил, предоставление свободного режима прихода и ухода с работы, выделение таким людям помощников, способных компенсировать их неумение четко документировать свои результаты. Но при этом следует сравнивать прямые затраты, связанные со стимулированием «привилегированных» сотрудников, а также неявные издержки, связанные с ухудшением морального состояния их сослуживцев, с получаемой организацией выгодой.

Основным методическим принципом управления разработкой является целевое управление.

Целевое управление представляет собой концепцию планирования и управления, с помощью которой руководитель устанавливает соответствующие цели через своего непосредственного руководителя более высокого ранга и участвует в установлении целей последнего; при этом результаты его деятельности оцениваются на основании конкретного обсуждения и документального рецензирования.

Цели присутствуют в планах самого различного уровня: целевых планах, бюджете, планах выпуска изделий, документации и т.д. Основной план для программного изделия — соглашение о требованиях. Цели, сформулированные в этом плане, должны включаться в индивидуальные рабочие планы, служащие тем механизмом, посредством которого в системе целевого управления достигается договоренность между исполнителями и их руководителями.

Достижение цели гарантируется включением общих целей создания изделия в индивидуальные рабочие планы и организацией текущего контроля за их выполнением.

Соглашение о требованиях, план поддержки, распределение бюджета и другие средства устанавливают те границы, в пределах которых не требуется использование обратной связи.

Существует три вида основных критериев оценки эффективности той или иной деятельности:

  • конкретные свойства;

  • затрачиваемое время;

  • стоимость.

Каждый из этих критериев имеет определенные границы действия, по достижению которых обязательно предоставление отчета руководству о результатах.

Однако следует учитывать, что управление созданием программных изделий является примером управления в условиях неопределенности. Качество такого управления зависит от способностей руководителей предвидеть трудности, планировать разработку с учетом случайных факторов и уметь защищать такого рода планирование от критики начальства, которое требует непременно «исключить случайность».