Главная страница  Анализ эмпирических данных 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 [ 48 ] 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

) Но нс бригад главного программиста.

Последующая проверка показала, что эти программисты являлись, как правило, руководителями групп технических специалистов) и одновременно, в силу тех или иных обстоятельств, несли ответственность за 1*екоторую часть нрограммных изделий. Если учесть, что помимо этой обязанности они должны были руководить работой коллектива от 5 до 15 спе-циалнстов, участвовать в рабочих и административных совещаниях, заниматься поиском и распределе-; нием необходимых ресурсов, исполнять роль связующего звена между программистами, руководством и заказчиком, то становится очевидным, что по существу эти люди были лишены возможности уделять должное внимание созданию бездефектных Ерограмм., Зависимости уровня ошибок от численных значений оценок программистов и руководителей технических групп представлены на рис. 4.2. Характерно, что руководителями технических групп обычно назначают преуспевающих программистов, и такое назначение расценивается как своего рода поощрение. Для тото что- бы при оценке программистов руководители был l равных условиях с рядовыми программистами, число ошибок каждого программиста делят а коэффициент его загрузки (рис. 4.3). После применения такого подхода разница между уровнями ошибок рядовых про-, граммистов и ртаводителей рабочих групп, выраженная в процентах, составила 12, а не 34%.

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

Использование оценок программистов в настоящем исследовании оказалось довольно плодотворным, так как на основе такой оценки можно было объяснить.



1 ifi

3,0

I 2,0

о о о

Э ООО

8о е

\2,0

5 10 15 20 о 5 70 15

Оцешш Оценка

Рис. 4.2. Зависимость частоты ошибок от оценки программиста.

с -профессиональные програм.мнсгы, сре,няя оценка 14, частота ошибок 1.45: 6 -технические руководители, средняя oi-ениа 18, частота ошибок г.ГО.

I,

3,0 2,0 1,0

о°

о i

О о

10 15 Оценка а.

20 О

1

о о

15 20

Оценка 6

Рис. 4.3. Зависимость отношения частоты ошибок к коэффициенту загрузки программиста от его оценки, е -профессиональные программисты; б-технические руководителя.

i 50



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

4.5.2. Зависимость уровня ошибок от способа распределения программистов

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

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

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

Полученные результаты (рис. 4.4) не подтвердили точку зрения, согласно которой у семи нянек дитя

) Уровень ошибок равен числу действительных ошибок на 100 операторов исходной программы.



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 [ 48 ] 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105

© 2000 - 2018 ULTRASONEX-AMFODENT.RU.
Копирование материалов разрешено исключительно при условии цититирования.