ПОИСК
Это наилучшее средство для поиска информации на сайте
Нисходящий анализ процесса управления проектированием программного изделия
из "Методы управления проектированием программного обеспечения "
Рассмотрим любую организацию, связанную с созданием программных средств, начиная с самой вершины иерархии, и попытаемся выяснить, где выполняется каждая функция проектирования программного изделия или где она должна была бы обеспечиваться, если бы не была предусмотрена заранее. Можно с уверенностью сказать, что требуемые функции могли бы выполняться соответствующими подразделениями с должным качеством, если, разумеется, эти функции в принципе выполнимы в данной организации. Во всяком случае, нет оснований считать, что для проектирования универсального программного обеспечения понадобится какой-то особый подход, хотя жрецы программирования могут с этим и не согласиться. Чтобы определить, следует ли функции объединять или нет, необходимо рассмотреть структуру всей организации сверху вниз и выяснить, какие средства — объединенные или раздельные— в большей степени способствуют целям вышестоящей организации. [c.51]Следует помнить, что грамотная декомпозиция — единственное, что минимизирует связь между отдельными элементами системы. Рассмотрим в качестве примера компоновку программного изделия в единое целое. Иногда эту функцию объединяют с функцией оценки качества изделий, поскольку ни одна из функций проектирования не предполагает ответственности за весь проект. В результате группа, занимающаяся оценкой качества, вынуждена приводить в порядок интерфейс между компонентами изделия вместо того, чтобы заниматься поиском труднообъяснимых ошибок. В то же время в тех случаях, когда объединение компонентов изделия в единое целое является частью процесса разработки, а не оценки, ответственность за отладку интерфейсов между компонентами изделия, очевидно, остается там, где возникает необходимость в отладке. [c.51]
Каждая организация должна иметь администратора, который выполняет роль, аналогичную роли директора (рис. 5.1). Директор несет ответственность за успех и неудачу создания программных изделий. В структуре, показанной на рис. 5.1, несомненно, должно существовать то или иное важное направление деятельности, включающее функцию разработки. Лицо, которое руководит этим направлением, следовало бы считать ответственным за все аспекты создания любого изделия, выпускаемого данной организацией. Чтобы координировать процесс разработки изделия, это лицо имеет право назначать администраторов изделий и руководителей проектов или использовать матричную схему организации работ. [c.51]
Директору важно знать, что функции, от которых зависит успех его деятельности, выполняются должным образом, хотя и не находятся под его непосредственным контролем. Слабое управление любой функцией может привести к тому, что результаты директорской деятельности будут плачевными. Благодаря же использованию матричной структуры вышестоящая организация, которой директор подотчетен, может способствовать выявлению затруднений, возникающих при выполнении любой функции, — независимо от того, подчинена она ему или иет, — и помогать ему применять те или иные корректирующие воздействия по соответствующим каналам управления. [c.52]
Вернуться к основной статье