Бригада главного программиста При проектировании [c.14]
Второй по значимости проблемой, затрагиваемой в книге, является проблема руководства проектом. Принцип организации разработок в форме проектов принят сейчас настолько широко, что рассматривается нами как очевидный. В начале 70-х годов стала весьма популярной концепция бригады главного программиста. В книге эта концепция упоминается лишь вскользь и не является обязательным условием применения развиваемой в книге методологии. [c.15]
Если в организации практикуется создание бригад главных программистов, необходимо зарезервировать такие посты, как посты главного программиста, помощника главного программиста и проблемного программиста, для неформального решения вопроса о соответствующих назначениях, так же как часто резервируется пост руководителя проекта. Такая стратегия позволяет польстить самолюбию вновь назначаемого старшего инженера по программному обеспечению, который до этого занимал должность старшего программиста в проекте средних масштабов, и помочь избежать моральных переживаний старшему инженеру, которому могут предложить работать проблемным программистом. [c.59]
Бригады главного программиста [c.89]
Прежде чем рекомендовать использование бригад главного программиста в качестве организационной формы проекта, проведем сравнение этой формы с традиционной организацией проекта и покажем, каким образом можно приспособить, если это вообще потребуется, методологию, изложенную в этой книге, к работе с бригадами главного программиста. Возникновение таких бригад тесно связано с рядом современных идей в области программирования. Ниже вводятся некоторые понятия, которые помогут понять дальнейшее содержание главы. Как показал опыт деятельности Отделения федеральных систем фирмы IBM [39], бригада главного программиста является наивысшим звеном в использовании ряда иерархически связанных методов программирования, в основе которых находится библиотека поддержки разработки. Благодаря этой библиотеке удается формально разделить функции и повысить производительность программирования. Библиотека поддержки разработки содержит машинные процедуры, которые позволяют проводить изменения исходных и машинных программ, а также библиотек тестовых данных, вызывать программы и данные для компиляции, редактирования связей и проведения тестовых прогонов, поддерживать и сохранять библиотеки программ и данных и, наконец, генерировать отчетные документы. Кроме того, [c.89]
Наконец, в вершине иерархии методов проектирования помещается концепция бригады главного программиста, в состав которой входят главный программист, его помощник, администратор библиотеки, а также от одного до пяти проблемных программистов. Главный программист является старшим техническим руководителем группы, который управляет ею и вместе со своим помощником проектирует, кодирует и объединяет модули высокого уровня или наиболее важные модули. Помощник главного программиста, на котором лежит ответственность за разработку некоторых из этих модулей, также является старшим техническим экспертом, он, кроме того, всегда должен быть готов взять на себя роль главного программиста бригады. Администратор библиотеки, являющийся высококвалифицированным секретарем, осуществляет функции, связанные с библиотекой поддержки разработки. Проблемные программисты составляют младший технический персонал, который по указанию главного программиста занимается написанием и отладкой отдельных модулей, не играющих критической роли в системе. Используя методы нисходящего проектирования, структурного программирования, а также библиотеку поддержки разработки, главный программист и его помощник тщательным образом проверяют тексты программы, написанные проблемными программистами с точки зрения функциональной полноты этих программ и их соответствия правилам структурного программирования. [c.91]
Концепция бригады главного программиста хорошо вписывается в методологию, излагаемую в данной книге. Библиотека поддержки разработки является хорошей иллюстрацией методов конфигурационного управления на уровне проекта. Структурное программирование удовлетворяет многим требованиям методологии проектирования, которые упоминаются в этой книге. Нисходящее проектирование, называемое также программированием сверху вниз, является фактически постепенной детализацией описаний функциональной структуры на уровнях более простых функций до тех пор, пока, наконец, не будет достигнут уровень собственно операторов языка программирования [14]. В ходе этого процесса фактически осуществляется декомпозиция проекта, описанная в предыдущей главе. Как заметил Бейкер [39], один из недостатков работы бригад главного программиста заключается в отсутствии подробных описаний функциональной структуры, которые отражали бы все внешние аспекты системы, не затрагивая внутренней структуры проекта. Ясно, что речь здесь идет о внешних спецификациях, рассмотренных в гл. 2. Бригада главного программиста, в составе которой предусмотрена должность руководителя проек- [c.91]
Независимо от выбранной организации — на основе бригад главного программиста или традиционной схемы, соответствующей структуре проекта, — необходимо выполнять одни и те же функции поддержки, выпускать одни и те же документы и осуществлять одни и те же этапы анализа. Изменяются лишь значимость различных этапов проектирования, а также среднее время и затраты труда на выполнение этих этапов. Бейкер считает, что организация персонала на основе бригад главного программиста позволяет сэкономить по сравнению с традиционной организацией проекта от 10 до 20% общей численности персонала и затрат труда, выраженных в человеко-месяцах (рис. 2.2). [c.92]
Бригада главного программиста 57, [c.381]
Прежде всего рассмотрим проблему подбора кадров. Поскольку речь идет об универсальных программных средствах, т. е. предназначенных для эксплуатации в нестандартных условиях, вряд ли нужно доказывать, что такое программное обеспечение должно быть достаточно сложным и для его разработки нужны специалисты высокой квалификации. В противном случае каждый пользователь мог бы обойтись собственными силами и не было бы необходимости создавать программные изделия. Замечание Дей-кстры о системном проектировании — этот вид работы очень сложен и любая попытка выполнить ее с помощью специалистов не самого высокого класса либо обречена на неудачу, либо ее ждет скромный успех при огромных расходах [30] —относится к любому универсальному программному обеспечению. Для проектирования такого программного обеспечения необходимо выделять квалифицированный персонал на всех участках работы. Следует искать людей, которые уже выполняли подобные функции по крайней мере достаточно хорошо, или тех, кто выполнял очень грамотно функции чуть меньшей сложности. Руководство проектами надо всегда поручать лишь тем специалистам, которые уже обладают таким опытом. Здесь можно воспользоваться концепцией бригады главного программиста при обсуждении кандидатуры на место этого руководителя следует иметь в виду, что наиболее подходящим является специалист, уже имеющий опыт работы в роли помощника главного программиста. Может показаться, что назначение на руководящие должности только квалифицированного персонала с практическим опытом носит слишком безапелляционный характер. Ведь когда-то и где-то люди должны начинать работать, но как смогут они это сделать, если будут принимать на работу только опытных специалистов К счастью, в университетах в настоящее время обучают структурному программированию и проектированию, и большинство студентов получают некоторые практические навыки во время учебы. Таким образом, новые специалисты в области вычислительной техники могут часто рассматриваться как достаточно квалифицированные для их назначения в качестве проблемных программистов, т. е. рядовых программистов, которые находятся в распоряжении главного программиста и его помощников или работают в качестве системных программистов на более низких должностях в традиционных программных проектах. [c.57]
При использовании изложенных здесь сведений следует руководствоваться собственной интуицией и опытом. Для расширения своего кругозора полезно ознакомиться с литературой, касающейся методов проведения количественных оценок в различных условиях проектирования. Несколько очень ценных примеров описаны в работах Арона [43, 44], Нельсона [45], Макнейла [46], Донельсона [47], Вольвертона [48] и (для условий проектирования с помощью бригад главного программиста) в работе Бейкера [41]. Есть и такие работы, например Брукса [36], Бёма [42] и Скотта [49, 50], в которых рассматриваются вопросы производительности труда программистов. [c.96]
Группа применения систем по обработке данных координирует работу по введению системы. Каждая разработка применения возглавляется руководителем проекта. Ему непосредственно подчинено достаточное количество программистов. Дополнительную поддержку он получает от членов бригады из других подразделений, которые связаны со старой или новой системой. Организационная структура бригады , производящей изучение обработки данных в масштабах всей компании, показана на рис. 25. На диаграмме видна не только подчиненность, но и задачи членов группы. Вычислительные установки, монтируемые этой группой, становятся производственной программой завтрашнего дня для главных, региональных и внутриуправленческих установок. [c.92]