Здравствуйте, AndreyFedotov, Вы писали:


AF> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:

......

AF> Список далеко не полон, есть множество ньюансов и деталей. Было бы интересно обсудить, что вы думаете по этому поводу.

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Вопрос только в количестве такой работы. Бывает что ее недостаточно чтобы загрузить даже одного единственного человека.

а бывает, что она составляет основную часть работы. Так что все зависит от проекта, и схема "один умный, десять старательных" тоже имеет все права на существование. см у Брукса, например.

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, AndrewVK, Вы писали:

AVK>>Вопрос только в количестве такой работы. Бывает что ее недостаточно чтобы загрузить даже одного единственного человека.

Д>а бывает, что она составляет основную часть работы. Так что все зависит от проекта,

Именно это я и сказал с самого начала.

Здравствуйте, AndreyFedotov, Вы писали:

AF>С тем, что новичку врядли стоит поручать решение вопроса о том, что и как делать — я согласен. Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно. В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

Ты это всё пробовал или теоретизируешь? Полезность детального проектирования с написанием подробной спецификации и передачей всего этого потом в разработку пэтэушникам придумали большевики вместе с мериканскими мэнеджарами для того чтобы оправдать необходимость аутсорсии. Такая схема работает очень плохо. Архитектору надо продумать каждую строчку кода и её задокументировать. Это объём работ больший чем само по себе написание кода. К тому же многие вещи гораздо проще решаются именно во время процесса написания кода. Одно дело удержать все мелочи в голове и совсем другое выразить их в коде и увидеть проблемы. В общем, бред это всё. Мы опять скатываемся к флейму на тему программистов-дигеров. Не работает это.

Здравствуйте, Дарней, Вы писали:

Д>В любом (почти) проекте есть части, которые не требуют квалификации, но требуют рутинной работы и терпения. Рисование формочек, написание оберток к библиотекам, и т.д. и т.п. И что, за такую работу ты тоже посадишь специалистов высокой квалификации?

Примеры ты конечно придумал классные

UI — это одна из наиболее сложных частей любой системы, если он не абсолютно примитивен. И тому есть много причин:

1. Большинство багов в любом проекте — это UI (ну да, его же рисуют новички ).
2. С автоматическим тестированием UI до сих пор хреново.
3. Все недочёты и недоработки видны невооружённым взглядом, так что схалявить и замазать (типа сделаем две кнопки вместо одной) практически невозможно.
4. Событийная модель, которая делает код трудно понимаемым и поддерживаемым, так сказать код без начала и без конца.
5. Постоянные затычки и workarounds в стандартных и не очень компонентах.
6. Заказчики, всё время требующие воплощения своих фантазий в UI (заметь, про BL они как правило вообще не догадываются).
7. Практически полное отсутствие повторного использования.
8. Среди приоритетов один из первых — это удобство для пользователя, а не чистота объектной модели и пр. лабуды.
9. Постоянная несовместимость с разрешениями, цветовыми схемами, предпочтениями пользователей.

Список можно продолжать.

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

Что там ещё? Обёртки?

Обёртки это первый шаг к разработке public-интерфейсов собственных библиотек и фреймворков. Как работает твоя библиотека внутри мало кого интересует, лишь бы она делала то, что от неё требуется. А вот насколько у неё удобный, последовательный и в то же время достаточный интерфейс — это пользователей как правило волнует и даже очень. Новичок конечно может сделать рапер, но как бы потом на этот рапер не пришлось делать ещё один рапер. Впрочем, если у тебя 10 новичков, то возможно десятая обёртка всей этой луковицы оказажется годной к использованию.

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndreyFedotov, Вы писали:

AF>>С тем, что новичку врядли стоит поручать решение вопроса о том, что и как делать — я согласен. Но решив этот вопрос, спроектировав его — воплощение в жизнь поручить можно. В зависимости от новичка конечно и от ситуации. Иногда достаточно описать решение, а иногда модно отдать наполовину написанный код.

IT>Ты это всё пробовал или теоретизируешь? Полезность детального проектирования с написанием подробной спецификации и передачей всего этого потом в разработку пэтэушникам придумали большевики вместе с мериканскими мэнеджарами для того чтобы оправдать необходимость аутсорсии. Такая схема работает очень плохо. Архитектору надо продумать каждую строчку кода и её задокументировать. Это объём работ больший чем само по себе написание кода. К тому же многие вещи гораздо проще решаются именно во время процесса написания кода. Одно дело удержать все мелочи в голове и совсем другое выразить их в коде и увидеть проблемы. В общем, бред это всё. Мы опять скатываемся к флейму на тему программистов-дигеров. Не работает это.

Я бы не был столь категоричен. И именно потому, что пробовал и это работало. Правда тут есть довольно сильные зависимости от:
— новичка
— какова реальная сложность кода (именно не критичность или важность, а сложность)
— того, в чём выражается сложность кода (архитектура, алгоритмы, объём)
— того, что из этого новичок может сделать хорошо и качественно

Хотя в целом согласен. Поручать критичные вещи новичку — не лучшая идея.

Здравствуйте, AndreyFedotov, Вы писали:

AF> Я бы не был столь категоричен. И именно потому, что пробовал и это работало.

И я пробовал много раз, во многих проектах и во многих командах. С новичками и с профессионалами. И что интересно. Чем больше общения + доверия и меньше бумажек + формализма, тем лучше результат. Новичку конечно можно поручить и довольно сложную задачу. Но он её хорошо решит только под присмотром профессионала. Но в данном случае целью должна быть не освободить профессионала, а научить новичка. Т.е. профику в данном случае нужно будет побыть ещё и нянькой.

AF>Правда тут есть довольно сильные зависимости от:
AF> — какова реальная сложность кода (именно не критичность или важность, а сложность)
AF> — того, в чём выражается сложность кода (архитектура, алгоритмы, объём)

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

Здравствуйте, IT, Вы писали:

IT>UI — это одна из наиболее сложных частей любой системы, если он не абсолютно примитивен.

Ха, просто супер.
У меня на эту тему были ну просто войны с коллегами. Сделать качественные контролы и адекватное GUI — это зачастую самые сложные задачи в приложениях. И к ним же обычно самые высокие требования.

Рад, что хоть кто-то считает так же.

--------
Не согласен только насчет "повторного" использования. ИМХО, задачи ввода и автоматизации валидации данных, а так же визуальные use-cases на эту тему весьма поддаются автоматизации.

Примеры, поддающиеся автоматизации (навскидку):
— контрол с данными надо сопровождать специальным лейблом, который автоматически будет disabled/visibled в зависимости от состояния целевого контрола, так же пусть передает фокус на целевой контол при кликаньи на лейбл.

— в момент валидации данных неплохо автоматически установить фокус на контрол, где требуется вмешательство, иногда для этого надо открыть соответствующую вкладку в TabControle, или проскролить, если форма скролится (все это автоматизируется)

— надписи к полям данных (и колонкам таблицы) можно получать автоматически.

— список actions надо привязывать не к контролу, а к полю сущности, тогда формирование индивидуального ContextMenu для контролов и ячеек таблиц будет значительно более простым делом;

— дизайнить менюхи в стандартных дизайнерах — вообще самое ГУИшное зло, необходимо использовать паттерн Command, можно обогощать его доп. признаками, типа код иконки, подсказка, раздел справки и т.д. Тогда будет единообразное построение меню и даже обычных кнопок на форме, связанных с командами, разумеется и единообразная обработка событий от них.
(кстати, неоднократно подумывал о дизайнере менюшек именно под реализацию технологии Command, но все руки не доходят)

— ввести на ГУИ понятие "контейнер данных", наделить его состояниями, обыграть множество use-cases при различных его состояниях. Ввести понятие связанных контейнеров данных.

— заполнение деревях — одно из самых муторных действ. Особенно, если заполянть надо по lazy-loading и из разнородных истоников, отображая разнородные данные. мы решили проблему путем написания набора DataSources под деревяхи и самой деревяхи, умеющей общатся с DataSources. Кода практически не стало.

(список неполный, это что сейчас вспомнилось)

Здравствуйте, Дарней, Вы писали:

Д>так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

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

Здравствуйте, VladD2, Вы писали:

VD>Низкое качество квалификации любого специалиста будет негативно сказываться на судьбе проекта. Так что можно говорить не о иеранхии пренебрижения к качеству, а о опасности появления неквалифицированного "специалиста" на подобных постах. В таком ключе согласен. Неквалифицированный руководитель — это самое фиговое что может быть. Но от квалифицированного руководителя не будет толку если у него бездарная команда проектировщиков или программистов.

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

Здравствуйте, vdimas, Вы писали:

V>Не согласен только насчет "повторного" использования. ИМХО, задачи ввода и автоматизации валидации данных, а так же визуальные use-cases на эту тему весьма поддаются автоматизации.

Полностью со всем согласен. Но я немного не о том. Ты фактически говоришь о разработке UI фреймворка адаптированного к твоей задаче. Здесь можно и нужно выявлять повторно используемый код. Я же говорю о прикладной-логике работы самих форм. Ну, например, у тебя есть комбобокс в котором содержится список адресов. При выборе адреса форма заполняет несколько полей соответствующих этому адресу. Вроде ничего сложного. Но теперь мы хотим повторно использовать эту же логику на другой форме. В большинстве случаев решение — Copy/Paste. Можно конечно сделать контрол, который будет инкапсулировать подобное поведение, но не факт, что на второй форме у нас будет тот же самый лэйаут. Может быть даже надо будет добавить/убрать ещё одно поле. В совсем маразматических случаях среди наших полей может появиться ещё одно вообще не относящееся к делу. Т.е. речь не об универсальной логике взаимодействия контролов и объектов, а о специфике конкретной формы или даже участка формы. Что-то типа visual inheritance компонентов. В идеале, берём такой компонент, кидаем на форму, логику реюзаем, его визуальные части изменяем по собственному усмотрению.

V>Примеры, поддающиеся автоматизации (навскидку):

На предыдущем проекте было у нас что-то подобное. Всё это прошло три или четыре реинкарнации. В результате архитектура UI была намертво прибита гвоздями к архитектуре объектной модели. Не к бизнес-модели, а к самому фреймворку. Начинали мы с команды в 4 постоянно от безделья курящих бамбук BL-девелопера и без передыху пыхтящих ничего не успевающих 4-х UI-щиков, а заканчивали в 3 BL-девелопера и 1-го UI-щика. Вот такой получился эффект. Но возможно это только при интерграции BL и UI фреймворков, а точнее при совместной разработке обоих. Ну и конечно большую роль сиграла квалификация нашего UI-шика. Монстр, блин.

V>- контрол с данными надо сопровождать специальным лейблом, который автоматически будет disabled/visibled в зависимости от состояния целевого контрола, так же пусть передает фокус на целевой контол при кликаньи на лейбл.

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

V>- в момент валидации данных неплохо автоматически установить фокус на контрол, где требуется вмешательство, иногда для этого надо открыть соответствующую вкладку в TabControle, или проскролить, если форма скролится (все это автоматизируется)

Базовую валидацию тоже можно размечать атрибутами.

V>- надписи к полям данных (и колонкам таблицы) можно получать автоматически.

DisplayName

V>- список actions надо привязывать не к контролу, а к полю сущности, тогда формирование индивидуального ContextMenu для контролов и ячеек таблиц будет значительно более простым делом;

Не знаю. ContextMenu зависит от контекста, а не от объекта.

V>- ввести на ГУИ понятие "контейнер данных", наделить его состояниями, обыграть множество use-cases при различных его состояниях. Ввести понятие связанных контейнеров данных.

В датасетах (точнее у DataRowView) есть весьма простая, но полезная функциональность — IEditableObject. Можно на это посмотреть, да и вообще глянуть на DataRowView полезно.

V>- заполнение деревях — одно из самых муторных действ. Особенно, если заполянть надо по lazy-loading и из разнородных истоников, отображая разнородные данные. мы решили проблему путем написания набора DataSources под деревяхи и самой деревяхи, умеющей общатся с DataSources. Кода практически не стало.

Интересно посмотреть на ваше решение. Вообще же, Lazy loading — это большая палка с двумя острыми концами.

V>(список неполный, это что сейчас вспомнилось)

Да всё понятно Главная идея — UI далёк от совершенства и нам ещё есть над чем работать

Здравствуйте, IT, Вы писали:

IT>UI — это одна из наиболее сложных частей любой системы, если он не абсолютно примитивен. И тому есть много причин:

IT>1. Большинство багов в любом проекте — это UI (ну да, его же рисуют новички ).

Единственный мой проект, в котором основные баги были в UI — это был проект с полностью нестандартным интерфейсом а-ля Mac OS. Во всех остальных на него приходилось максимум процентов 20, основная часть — это логика и проблемы в используемых библиотеках. Наверно, мы что-то неправильно делали

IT>2. С автоматическим тестированием UI до сих пор хреново.

Есть такое дело. Да не очень оно и нужно, если есть модульные тесты для логической части.

IT>4. Событийная модель, которая делает код трудно понимаемым и поддерживаемым, так сказать код без начала и без конца.

Трудно понимаемый и поддерживаемый — это когда всю логику навешивают на форму? Не спорю, только научить отделять мух от котлет можно даже новичков, если у них в голове не совсем уж пусто.

IT>5. Постоянные затычки и workarounds в стандартных и не очень компонентах.

Дык документировать надо, и затычки с обходными решениями — в первую очередь!

IT>6. Заказчики, всё время требующие воплощения своих фантазий в UI (заметь, про BL они как правило вообще не догадываются).

Вот для этого и нужные толковые архитекторы и руководители проектов.

IT>7. Практически полное отсутствие повторного использования.

и что?

IT>8. Среди приоритетов один из первых — это удобство для пользователя, а не чистота объектной модели и пр. лабуды.

и?

IT>9. Постоянная несовместимость с разрешениями, цветовыми схемами, предпочтениями пользователей.

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

IT>Список можно продолжать.

Ну попробуй.

IT>Не каждый профессионал способен написать хороший UI код средней сложности

написать или спроектировать?

IT>Обёртки это первый шаг к разработке public-интерфейсов собственных библиотек и фреймворков.

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

Здравствуйте, IT, Вы писали:

Честно говоря, не понимаю, о чем вообще спор. Существуют разные программисты — одни профессиональные, другие не очень. В любом среднем проекте имеются и те. и другие, причем вторых намного больше. Это — объективная реальность, данная нам в ощущениях, и другой у нас нет. Остается только организовать работу таким образом, чтобы выполнить проект.
Можно (и нужно) заняться обучением новичков, но основная задача фирмы — производство программ, а не обучение сотрудников за свой счет, и эту задачу надо решать здесь и сейчас.
Можно (и нужно) нанять как можно больше профи, но их число ограничено и на все задачи их не хватит
И какие варианты у нас остаются? Профессионалов отправить кодировать, а новичков поставить ими управлять?

Здравствуйте, VladD2, Вы писали:

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

Вот и я тоже все время удивляюсь таким "непризнанным гениям".
Если начальник действительно неадекватен — можно без труда занять его место, при условии что вышестоящее начальство фирмы не такое же тупое. Если неадекватно все начальство фирмы — что вообще делать в такой фирме?

Здравствуйте, AndreyFedotov, Вы писали:

AF> Собственно, именно об этом я и хотел сказать — что квалификация должна быть, но не
AF>обязательно равномерно высокой у всех.
<SKIP>
AF> По поводу того, чья квалификация важнее — руководителей, архитекторов или разработчиков — есть разные мнения и есть различные эффективные способы организации команд, с различными профилями квалификаций.
AF> Единственное, что можно сказать наверняка — способности реального руководителя должны быть не ниже срединих — это ключевой фактор. Остальное можно обыгрывать.

Если все же вернуться к теме качества софта (качество ПО — способность ПО удовлетворять предъявленным функциональным и нефункциональным требованиям), то позволю себе настаивать — квалификация разработчиков имеет очень важное значение. Именно разработчики (программисты/дизайнеры/архитекторы) реализуют функциональные и нефункциональные требования в коде и если они не имеют достаточной квалификации — ни о каком качестве не может быть и речи.
Руководство же в большей мере влияет на сроки и бюджет проекта.
Понятно, что все в этом мире взаимосвязанно, но приоритеты я бы расставил именно так.

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, AndreyFedotov, Вы писали:

AF>> Да и мой опыт свидетельствует о том же. Видел команды очень хороших профи, где царило раздолбайство, и качество того, что они делали было прямо скажем не очень — откровенная халутра. Видел и команды студентов (явно новичков), которые тем не менее грамотно управлялись и качество работы было гораздо выше.

Д>так что на первом месте должна быть квалификация руководства, после которой — квалификация аналитиков и проектировщиков

С точки зрения денег — согласен. Я бы расположил стоимость (в USD) ошибок по мере ее убывания так:

— ошибки в управлении (в том числе и при оценке проекта);
— ошибки анализа и архитектуры;
— ошибки в дизайне и разработке.

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

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AVM, Вы писали:

AVM>>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.

IT>Власть сама по себе не страшна. Страшна власть, которая потворствует принятию "судьбоносных" решений.
Тогда пусть одиним из признаков "квалификации" власти будет ее способность уметь ограничить себя в "потворстве принятию "судьбоносных" решений"

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, AndreyFedotov, Вы писали:

AF>> Я бы не был столь категоричен. И именно потому, что пробовал и это работало.

IT>И я пробовал много раз, во многих проектах и во многих командах. С новичками и с профессионалами. И что интересно. Чем больше общения + доверия и меньше бумажек + формализма, тем лучше результат. Новичку конечно можно поручить и довольно сложную задачу. Но он её хорошо решит только под присмотром профессионала. Но в данном случае целью должна быть не освободить профессионала, а научить новичка. Т.е. профику в данном случае нужно будет побыть ещё и нянькой.

Игорь, со всем этим я согласен.
Однако мы рассматриваем несколько вырожденный случай. Конечно если у нас 9 профи и один новичок, то проучать новичку наиболее критичный участок, который до этого спроектировал профи, что бы новичок постоянно бегал к нему с вопросами — это как минимум странно.
Я же подразумевал несколько другую ситуацию: команда, где 2-3 профи и 6-8 новичков. В данном случае, когда на одного профи 3-4 новичка, описанная выше стратегия обучения новичков уже работает. Если ребята обучаемые, профи умеет учить — хотя бы средне, то производительность связки профи + 2-4 новичка уже выше чем у одного профи в 1,5 — 3 раза (в зависимости от ситуации). В добавок — по завершению проекта имеем не только сделанный проект, но и несколько более опытных сотрудников. Потому это не только обучение — но и более высокая производительность.

AF>>Правда тут есть довольно сильные зависимости от:
AF>> — какова реальная сложность кода (именно не критичность или важность, а сложность)
AF>> — того, в чём выражается сложность кода (архитектура, алгоритмы, объём)

IT>Опять находим противоречие. Простой код проще и быстрее самому написать, чем объяснить кому бы то ни было. Со сложным ещё хуже. Как правило не начав его писать сомому трудно сказать что вообще нужно делать.
Это если кода мало. А если много и кодеров не один, а несколько?

Здравствуйте, AndreyFedotov, Вы писали:

AVM>>>>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
AF>>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. ....
AVM>>Есть, причем прямая связь.
AF> То есть ситуация, когда есть две команды, у первой квалификация в среднем выше, и она проваливает проект, а вторая его делает — это прямая связь?
AF> Или всё-таки стоит рассмотреть, что вы имеете в виду под квалификацией команды? Кого конкретно в команде?
Под квалификаций команды я имею квалификацию каждого члена проектной команды (ПМа, архитектора, дизайнера/разработчика, тест-дизайнера/тестера). Чем выше квалификация членов проектной команды, тем выше вероятность что качество произведенного продукта будет высоким. (Естественно при всех прочих равных условиях).

AVM>>Если же "квалификация — вторична", то к бьющемуся в истерике гуру-архитектору, присоединиться гуру-менеджер проекта... И будут они вместе тосковать, глядя на стадо разработчиков.
AF>А что им тосковать — будут учить. <SKIP>
Им не новичков учить надо. У них задача сделать продукт, причем высококачественный продукт. Или я что то не понял?

AF>>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?
AVM>>Не надо смешивать теплое с твердым.
AVM>>Представь себе другую жизненную ситуацию, тебе надо поштукатурить стены в квартире. Ты будешь искать:
AVM>>a) хорошего прораба?
AVM>>b) хороших штукатуров?
AF>А вот это зависит от размеров квартиры и того, построена она или нет.
А какая разница? Тебе все равно рано или поздно понадобиться хороший штукатур.

AF>Эта аналогия не совсем применима, по той причине, что перештукатурить совсем не так дёшево, как переписать код.
Стоимость 1 кв метра штукатурки — примерно 10-15 USD. Работы примерно на 20-30 мин. Итого — 5-10 USD/час.
Ты точно уверен что перештукатурить стоит дороже чем переписать код????

AF>>> Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.
AVM>>Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.
AVM>>Но мое IMHO мне подсказывает, что в реальном проекте, запросто может появляться новичек-разработчик за которым недесмотрели и который может наворотить столько, что потом три тим-лида не разберуться.
AF>А что есть квалификация Тим-лида и ПМ'а — как не умение смортеть за этими самыми разработчиками?
ИМНО для ПМа важнее правильно сделать оценку проекта, его планирование и уметь грамотно управлять рисками. Зачем к множеству рисков добавлять еще и риск связанный с низкой квалификацией персонала?

Здравствуйте, AVM, Вы писали:

AVM>Если все же вернуться к теме качества софта (качество ПО — способность ПО удовлетворять предъявленным функциональным и нефункциональным требованиям), то позволю себе настаивать — квалификация разработчиков имеет очень важное значение. Именно разработчики (программисты/дизайнеры/архитекторы) реализуют функциональные и нефункциональные требования в коде и если они не имеют достаточной квалификации — ни о каком качестве не может быть и речи.
AVM>Руководство же в большей мере влияет на сроки и бюджет проекта.
AVM>Понятно, что все в этом мире взаимосвязанно, но приоритеты я бы расставил именно так.

У меня есть несколько догадок по этому поводу:
— Скорее всего у вас работа с требованиями ведётся (как и в большинстве мест) достаточно хаотично.
— Нет регулярных, систематических и глубоких codereview
— Начальство занимается только сроками и бюдежтом (судя по вашим же словам)
— У вас или нет аналитиков и архитекторов вообще или они занимаются лишь общими контурами системы, не вдаваясь в детали
То есть де-факто девелоперу самому надо догадываться, что от него хотят. Да вдобавок его код толком никто не смотрит. То есть вся система в целом зависит от того, как каждый напишет свой кусок. В этом случае совершенно естественно, что ему нужна высокая квалификация.
Если это так, то это только подтверждает как раз то о чём я и говорил — о низкой квалификации управляющих.