В последнее время активно обсуждается темя зависимости количества ошибок в зависимости от языка на котором ведётся разработка. Эта темя всплывала здесь

Автор: eao197
Дата: 05.06.05

, здесь

Автор: FDSC
Дата: 13.06.05

и даже в мегафлейме здесь

Автор: Сергей Губанов
Дата: 09.06.05

. Так же эта тема с завидной регулярностью появляется и в вечных темах "X vs Y" и "зачем нужен goto?".
Однако мне кажется, что взгляд, что качество системы или ПО обеспечивается исключительно языком программирования (иногда так же поминают тестирование), несколько ограничен. Забавно, но об этом с дивной регулярностью вспоминают во время споров, когда исчерпываются аргументы в защиту того или иного языка.
Интересно было бы обсудить — какие факторы влияют на качество программ, надёжность (особенно при повторном использовании), саму возможность повторного использования. А так же то, каким образом влияют данные факторы на ту или иную характеристику ПО.
Тема, конечно, не оригинальна, и что на эту тему исписаны тонны бумаги (и выработаны стандарты, такие как ISO9000, ANSI или ГОСТ), но хотелось бы выяснить мнение участников форума, особенно со своим практическим опытом и своей точкой зрения на это.
Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:
— Организация процесса разработки
— Организация процесса тестирования
— Архитектура ПО
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Язык программирования
— Стиль кодирования
— Используемые модули и библиотеки
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти
Список далеко не полон, есть множество ньюансов и деталей. Было бы интересно обсудить, что вы думаете по этому поводу.

Слона то мы и не заметили.

IMHO на первом месте стоит квалификация проектной комманды

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

AF> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:
AF> — Организация процесса разработки
AF> — Организация процесса тестирования
AF> — Архитектура ПО
AF> — Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
AF> — Язык программирования
AF> — Стиль кодирования
AF> — Используемые модули и библиотеки
AF> — Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
AF> — Аккуратное слежение за выделением и освобождением памяти

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

AVM>Слона то мы и не заметили.

AVM>IMHO на первом месте стоит квалификация проектной комманды

Да, про этот фактор Андрей Федотов действительно забыл.
Но, имхо, он не на первом месте. А на третьем После организации процессов разработки и тестирования.

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

AF>> Поразмыслив, смог выделить следующие факторы, которые, с моей точки зрения оказывают влияние на качество и надёжность ПО:
AF>> — Организация процесса разработки
AF>> — Организация процесса тестирования
AF>> — Архитектура ПО
AF>> — Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
AF>> — Язык программирования
AF>> — Стиль кодирования
AF>> — Используемые модули и библиотеки
AF>> — Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
AF>> — Аккуратное слежение за выделением и освобождением памяти

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

AVM>Слона то мы и не заметили.

AVM>IMHO на первом месте стоит квалификация проектной комманды

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

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

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

AVM>>Слона то мы и не заметили.

AVM>>IMHO на первом месте стоит квалификация проектной комманды

E>Да, про этот фактор Андрей Федотов действительно забыл.
E>Но, имхо, он не на первом месте. А на третьем После организации процессов разработки и тестирования.

Как говорил Иосиф Виссарионович "Кадры решают все".
Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

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

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

AVM>>Слона то мы и не заметили.

AVM>>IMHO на первом месте стоит квалификация проектной комманды

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

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

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

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

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

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

AVM>>>Слона то мы и не заметили.

AVM>>>IMHO на первом месте стоит квалификация проектной комманды

E>>Да, про этот фактор Андрей Федотов действительно забыл.
E>>Но, имхо, он не на первом месте. А на третьем После организации процессов разработки и тестирования.

AVM>Как говорил Иосиф Виссарионович "Кадры решают все".
Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...
Вспомнить хотя бы историю про Берию и удвоение мощьности авиационного двигателя...

AVM>Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
AVM>IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
AVM>Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

Это верно только от части. Достаточно одного умного руководителя, что бы выстроить работу команды новичков (примеры тому видел сам, хотя это, конечно и достаточно трудно), а если у него ещё есть несколько опытных сотрудников и он их умело расставляет на ключевые позиции и эффективно строит процесс разработки (куда я включаю как составные части общение с заказчиками, сбор требований, анализ, проектирование, построение архитектуры, тестирование и все прочие компоненты) — то такая команда может работать и быстро и эффективно и выдавать продукт очень выского качества.
Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.

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

(С) — Увы, забыл

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

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

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

AVM>>>Слона то мы и не заметили.

AVM>>>IMHO на первом месте стоит квалификация проектной комманды

AF>> Вообще то логично, в список внести её необходимо. Однако насколько мне известно — все проводимые в данной области исследования, как это ни пародоксально, свидетельсвтуют о том, что это далеко не самый важный фактор — ни для качества, ни для надёжности.
AVM>Примеры в студию, плиз
Увы — на бумаге. Найду в электронном виде — выложу на всеобщее обозрение.

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

AVM>IMHO проектная команда = команда студентов + менеджер, который ими управлял + тех лидер, который их консультировал + и тд. Не надо преувеличивать роль руководства в проектной команде. Формально PM несет ответственность за проект, реально же успех проекта зависит не от конкретных людей, а от команды в целом.
В общем то согласен.
AVM>А вот завалить проект может и отдельно взятая личность.
А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.

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

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

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

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

AVM>>А вот завалить проект может и отдельно взятая личность.
AF> А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.

СММмы и прочие ISO конечно штуки крутые, но на малых командах (до 10 человек) они работают плохо — эффективность низкая, зато гибкость они снижают сильно. Так что тоже не панацея.

AF> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет.

А мой показывает обратное. Намек понятен?

AF> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?

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

AF> В то же время трудолюбивый и исполнительный новичок может делать полезную работу

Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.

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

AF> Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...

Правильно. Но в твоём списке менеджмент вообще отсутствует. А зря.

AVM>>Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
AVM>>IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
AVM>>Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

AF> Это верно только от части.

Это очень правильно. И это легко объяснятся. Дело в том что большинство багов появляются не в момент первоночального написания кода, а тогда, когда его начинают изменять по каким либо причинам. Это происходит потому, что когда код пишется, то как правило всё тщательно тестируется самим разработчиком. Когда вносятся изменения, то повторное тестирование всех сценариев очень часто не делается. Изменения вносятся в основном по нескольким причинам. Первая — change request, изменение требований заказчиком во время разработки. С этим ничего не поделаешь. Хотя и здесь можно многое контролировать, если архитектура и дизайн с самого начала были ориентированы на простое внесение изменений в систему. Вторая причина — изменение самой архитектуры и дизайна. Это в чистом виде ошибки архитекторов и дизайнеров. Чем больше таких ошибок тем больше багов будет внесено в систему в момент её изменения.

Бывает и такое, что зачастую горе-архитекторы пытаются отстоять правильность своих решений путём отказа от внесения каких-либо изменений в разрабатываемую ими часть дизайна системы. Типа, у меня всё правильно, это не я идиот, а вы. В результате там где, например, можно было бы обойтись добавлением одной таблички в БД для хранения состояния чего-либо, сооружается целая система персистентности размазанная по всем слоям и уровням. Т.е. система становится сложнее, а сложнее значит более подверженная наличию багов.

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

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

AF> Однако мне кажется, что взгляд, что качество системы или ПО обеспечивается исключительно языком программирования (иногда так же поминают тестирование), несколько ограничен.

Мне кажется этот посыл ошибочным. Я что-то не слышал о том, что кто-то говорит "качество системы или ПО обеспечивается исключительно языком программирования". Это домыслы. Говорят (и я с этим согласен), что некоторые языки способны облегчить выявление ошибок и теми или иными путями не дать совершить ошибки. Улавливаешь разницу?

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

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

AF> Интересно было бы обсудить — какие факторы влияют на качество программ, надёжность (особенно при повторном использовании), саму возможность повторного использования. А так же то, каким образом влияют данные факторы на ту или иную характеристику ПО.

Что пришло в голову сразу:
1. Качество проектирования (грамотное применение выбранной парадигмы и паттернов, корректность предположений, качество декомпозиции).
2. Класс и отвественность программистов (человеческий фактор).
3. Использование средств автоматизации (визульные дизайнеры, рефакторинг, генерация кода, отладчики, IDE).
4. Использование библиотек (их качество).
5. Характеристики безопасности языка программирования и рантайма.
6. Умение команды (если разработка ведется командой) разделять обязанности и распараллеливать разработку.
7. Наличие ревизии кода и рефакторинга.

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

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

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

AVK>Зависит от проектов. Если проект позволяет, то действительно команда начинающих программистов способна под пристальным контролем выдавать качественный продукт (но хотя бы один высококлассный спец быть должен). А бывают проекты, когда новичкам просто нечего поручить. Управляемые платформы эту ситуацию конечно сглаживают, но и они отнюдь не панацея.

В общем то согласен. Про наличие хотя бы одного спеца я собственно и сам писал. А вот насчёт сложности проекта — это вопрос. Те же сети были сделаны как раз новичками. Бедолаги получив задание от родины и правительства (родного, американского) сидели и ждали, когда наконец придёт профессионал, который раскажет им, что им надо делать. А он так и не пришёл. И ничего — сделали. За год сделали.

AVM>>>А вот завалить проект может и отдельно взятая личность.
AF>> А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.

AVK>СММмы и прочие ISO конечно штуки крутые, но на малых командах (до 10 человек) они работают плохо — эффективность низкая, зато гибкость они снижают сильно. Так что тоже не панацея.

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

AF>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет.
AVK>А мой показывает обратное. Намек понятен?

Понятен.
Непонятно только, что именно показывает ваш опыт? Что связь есть (с чем я согласен) или что эта связь — прямая?

AF>> Представь простую житейскую ситуацию — квалифицированный бездельник. Ну и толку от его квалификации, если он делает, что он хочет или вообще гонит халтуру?

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

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

AF>> В то же время трудолюбивый и исполнительный новичок может делать полезную работу

AVK>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
А вот это во многом зависит от того, как распределять работу.

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

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

AF>> Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...

IT>Правильно. Но в твоём списке менеджмент вообще отсутствует. А зря.
+1
Кстати совершенно верно. Я его забыл, точнее не выделил отдельно из процесса организации работ по проекту.

AVM>>>Организация всех процессов, в том числе и процесса тестирования, зависит от квалификации проектной команды.
AVM>>>IMHO наличие квалифицированных специалистов, является НЕОБХОДИМЫМ условием для производства качественного софта.
AVM>>>Естественно ТОЛЬКО этого условия не достаточно, но без него просто труба.

AF>> Это верно только от части.

IT> ...
IT>Есть ещё один момент связанный с переделками. Это занимает определённое время, в результате команда не укладывается в сроки, отсюда спешка, тап-ляп кодирование и откровенное игнорирование тестирования самими разработчиками. Порой доходит до того, что в QA сдаётся не то чтобы глючный непротестированный код, а просто откровенно недоделанный, код в котором отсутствует какая-то функциональность. Расчёт делается на то, что пока QA будет тестировать, всё это будет паралельно дописываться.

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

То есть обобщая, качество зависит от:
— Менеджмента
— Качества проектирования (качества архитектуры, в частности учётом возможных изменений в архитектуре)
— Управления внесением изменений (по запросу клиента ли или при правке багов)
— Правильной оценкой времени при планировании, с учётом возможных рисков, связанных с правкой багов в предидущих версиях
— Организацией процесса тестирования (в частности передачей на тестирование продукта своевременно)

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

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

AF>> Однако мне кажется, что взгляд, что качество системы или ПО обеспечивается исключительно языком программирования (иногда так же поминают тестирование), несколько ограничен.

VD>Мне кажется этот посыл ошибочным. Я что-то не слышал о том, что кто-то говорит "качество системы или ПО обеспечивается исключительно языком программирования". Это домыслы. Говорят (и я с этим согласен), что некоторые языки способны облегчить выявление ошибок и теми или иными путями не дать совершить ошибки. Улавливаешь разницу?

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

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

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

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

Автор: eao197
Дата: 05.06.05

— панацеей она не является и для того, что бы обеспечить высокий уровень качества нужно задейстовать что-то ещё.

AF>> Интересно было бы обсудить — какие факторы влияют на качество программ, надёжность (особенно при повторном использовании), саму возможность повторного использования. А так же то, каким образом влияют данные факторы на ту или иную характеристику ПО.

VD>Что пришло в голову сразу:
VD>1. Качество проектирования (грамотное применение выбранной парадигмы и паттернов, корректность предположений, качество декомпозиции).
VD>2. Класс и отвественность программистов (человеческий фактор).
VD>3. Использование средств автоматизации (визульные дизайнеры, рефакторинг, генерация кода, отладчики, IDE).
VD>4. Использование библиотек (их качество).
VD>5. Характеристики безопасности языка программирования и рантайма.
VD>6. Умение команды (если разработка ведется командой) разделять обязанности и распараллеливать разработку.
VD>7. Наличие ревизии кода и рефакторинга.

+1

Спасибо! Про рефакторинг и средства разработки я вообще не подумал, хотя следовало бы

А как по твоему влияют на оное процесс разработки и менеджмент проекта?

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

AVM>>Как говорил Иосиф Виссарионович "Кадры решают все".
AF> Вот вот. Достаточно одного Иосифа Висарионовича, как кадры резко начинают решать всё...
AF> Вспомнить хотя бы историю про Берию и удвоение мощьности авиационного двигателя...
Не слышал такую историю, расскажи они удвоили мощьности авиационного двигателя?

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

AF> Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.
Бывает, и достаточно.

AF>

AF> Как говориться лучше стадо баранов под предводительством льва, чем стадо львов под предводительством барана.

AF> (С) — Увы, забыл
Понимаешь в чем тут засада. Стадо баранов под предводительством льва смогут только очень громко блеять. Если в этом суть проекта, то да success обеспечен. А вот качественный программный продукт от баранов не получить. Никак не получить.

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

AVK>>Зависит от проектов. Если проект позволяет, то действительно команда начинающих программистов способна под пристальным контролем выдавать качественный продукт (но хотя бы один высококлассный спец быть должен). А бывают проекты, когда новичкам просто нечего поручить. Управляемые платформы эту ситуацию конечно сглаживают, но и они отнюдь не панацея.

AF>А вот насчёт сложности проекта — это вопрос.

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

AF>Согласен. Панацеи вообще не бывает.

Бывает. Только это не технология, а человек. Не конкретный, а вобще.

AF>>> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет.
AVK>>А мой показывает обратное. Намек понятен?

AF>Понятен.
AF>Непонятно только, что именно показывает ваш опыт? Что связь есть (с чем я согласен) или что эта связь — прямая?

Не, намек был на то что твой опыт — не аргумент в споре. Как и мой.

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

AF>В принципе я бы согласился с таким подходом, елси бы не одна загвоздка
AF>Квалификация определяется по навыкам, умениям и знаниям.

Это вторичные признаки, позволяющие предварительно оценить эту самую квалификацию. Давай обратимся к словарю (KM.ru)

КВАЛИФИКАЦИЯ, и, ж.

1. см. квалифицировать.

2. Степень годности к какомун. виду труда, уровень подготовленности. Повышение квалификации. Высшая к.

3. Профессия, специальность. Приобрести квалификацию токаря.

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

AVK>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF> А вот это во многом зависит от того, как распределять работу.

Нет, это, прежде всего, зависит от задач проекта.

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

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

AVM>>У тебя похоже проектная команда = команда студентов.
AF>Отнюдь. Я имел в виду команды, где руководящий состав (разный, в зависимости от проекта и ситуации — иногда один менеджер, он же тим-лидер, а иногда целая группа менеджеров, спецов по предметной области, аналитиков, архитекторов) — умелый и эффективно организует процесс, ....
Я не пойму о чем мы спорим, ты говоришь то же что и я только другими словами
AF> ... а вот исполнители — те кто пишут код или выполняют тестирование — новички, без особого опыта или квалификации.
Ты никогда не встречал архитектора, которого вот-вот хватит кандратий, после того как он в 10-й раз сделал code review "новичка, без особого опыта или квалификации"?

AVM>>IMHO проектная команда = команда студентов + менеджер, который ими управлял + тех лидер, который их консультировал + и тд. Не надо преувеличивать роль руководства в проектной команде. Формально PM несет ответственность за проект, реально же успех проекта зависит не от конкретных людей, а от команды в целом.

AVM>>А вот завалить проект может и отдельно взятая личность.
AF> А вот это во многом зависит от управления проектом — как от мастерства рукводителя (или управляющей команды), так и от организации разработки. Собственно CMM Level 3 как раз в переводе на человеческий язык и означает, что один человек проект не завалит. Теоретически — даже если это сам руководитель. Хотя на практике это конечно случай особый.
CMMI 3 в нашей жизни очень редкая вешь. Я не в том плане, что сертификатов мало раздадено, а в том что денег эта штука жрет немеряно и не всякий заказчик захочет покупать качество по таким ценам. Причем даже наличие полного CMMI не гарантирует успех проекта.

AVM>>Я не утверждаю, что тогоко команда из супер-пупер гуру может выдавать на гора качественный код. Я говорю, что квалификация проектной команды должна учитываться в первую очередь.
AF> Не думаю. Мой опыт показывает, что прямой связи между уровнем команды и качеством кода — нет. ....
Есть, причем прямая связь.

AVM>>Ты можешь выстроить процессы, которые расчитаны на средний уровень квалификации разработчиков и делать качественный софт. Но IMHO ключевое слово тут не процессы, а средний уровень квалификации , потому что процессы ты сравнительно легко можешь менять и затачивать под конкретную ситуацию. А вот изменить уровень квалификации проектной команды обычно намного тяжелее.
AF> Как раз-таки наоборот — гораздо важнее процессы, а квалификация — вторична.
ISO 9000 предусматривает ответственность руководства за обучение персонала.
Если же "квалификация — вторична", то к бьющемуся в истерике гуру-архитектору, присоединиться гуру-менеджер проекта... И будут они вместе тосковать, глядя на стадо разработчиков.


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

AF> Вот для управления и для ключевых сотрудников, вроде Тим-Лида — вот там квалификация действительно важна.
Квалификация тим лида, важнее квалификации кодера потому что у тим-лида власти больше.
Но мое IMHO мне подсказывает, что в реальном проекте, запросто может появляться новичек-разработчик за которым недесмотрели и который может наворотить столько, что потом три тим-лида не разберуться.

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

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

В связи с чем возникает интересный вопрос — чей уровень квалификации наиболее критичен для проекта — всегда ли ответ один или есть несколько вариантов — схем построения эффективной команды?

AF>> Бывает и обратная ситуация — когда команда высококвалифицированных спецов, а руководство слабенькое. Результаты зачастую получаются удручающие.
AVM>Бывает, и достаточно.
Бывает. Но разве это то, к чему стоит стремиться?

AF>>

AF>> Как говориться лучше стадо баранов под предводительством льва, чем стадо львов под предводительством барана.

AF>> (С) — Увы, забыл
AVM>Понимаешь в чем тут засада. Стадо баранов под предводительством льва смогут только очень громко блеять. Если в этом суть проекта, то да success обеспечен. А вот качественный программный продукт от баранов не получить. Никак не получить.

Да нет. Суть-то как раз в том, что это львы под руководством барана блеют. А вот лев может суметь заставить баранов рычать. Вот тут как раз написано об одном подобном случае.

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

AVK>Минуточку. Про сложность я ничего не писал. Дело не в сложности, дело, скажем так, в изведанности. Если точно известно что и как писать, то можно придумать набор техник и метрик, которые обеспечат стабильное качество, вне зависимости от сложности выполняемых операций.
+1

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

AVK>Не, намек был на то что твой опыт — не аргумент в споре. Как и мой.

Забавная складывается ситуация. Я предложил высказать свои точки зрения и вруг с удивлением узнаю, что это уже оказывается спор.
Более того, у нас же в жизни вообще ничего больше нет, кроме нашего опыта. Если к нему нельзя обращаться — то к чему можно? Не верь глазам своим?
Тем более, что ничто не мешает привести собственные примеры, которые опровергнут, дополнят, расширят или изменят моё утверждение. Как раз это было бы полезно, что бы выявить, что было факторами успеха или провала в других проектах.

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

AF>>В принципе я бы согласился с таким подходом, елси бы не одна загвоздка
AF>>Квалификация определяется по навыкам, умениям и знаниям.

AVK>Это вторичные признаки, позволяющие предварительно оценить эту самую квалификацию. Давай обратимся к словарю (KM.ru)
AVK>

КВАЛИФИКАЦИЯ, и, ж.

AVK>1. см. квалифицировать.

AVK>2. Степень годности к какомун. виду труда, уровень подготовленности. Повышение квалификации. Высшая к.

AVK>3. Профессия, специальность. Приобрести квалификацию токаря.

AVK>Очевидно что в данном случае нам подходит 2 пункт. Итого — квалификация это степень годности к выполнению определенной работы. Так вот, человек, который прекрасно знает технологии, но при этом не имеет достаточного самоконтроля чтобы не халтурить, не годен к выполнению этой самой работы.

Это при условии, что он халтурит всегда. А если, как чаще всего и бывает — он хорошо работает в том проекте, который ему интересен и плохо на саппорте, например, — как тут быть?
Если бы тебя на саппорт засунули лет на 10 — ты уверен, что работал бы с энтузиазмом или вообще работал бы, а не халтурил?

AVK>>>Опять же, если в проекте есть такая работа, когда требуется только трудолюбие и ничего больше.
AF>> А вот это во многом зависит от того, как распределять работу.
AVK>Нет, это, прежде всего, зависит от задач проекта.

Например?

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

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

Я выделил эти два слова, чтобы чуть-чуть перевести акценты. Спор, который развивается после дополнения AVM о необходимости учета <i>квалификации проектной команды</i>

Автор: AVM
Дата: 25.06.05

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

Вот Андрей привел список факторов, который с учетом дополнения AVM можно по разному отсортировать в зависимости от того, какие свойства мы хотим получить от продукта. Если говорить о высоком качестве и надежности (в ущерб скорости разработки и, возможно, стоимости), то я бы их перечислил следующим образом:

— Организация процесса разработки
— Архитектура ПО
— Организация процесса тестирования
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Язык программирования
— Используемые модули и библиотеки
— Квалификация проектной команды
— Стиль кодирования
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти

Хотя, если проект должен быть выполнен одной организацией и одной относительно небольшой командой, то я бы его пересортировал так:

— Организация процесса разработки
— Архитектура ПО
— Организация процесса тестирования
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Квалификация проектной команды
— Язык программирования
— Используемые модули и библиотеки
— Стиль кодирования
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти

Повторюсь, речь идет именно о качестве и надежности.

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

— Квалификация проектной команды
— Язык программирования и используемые модули и библиотеки
— Архитектура ПО
— Организация процесса разработки
— Организация процесса тестирования
— Чёткие определения интерфейсов, включая диапазоны входных и выходных данных
— Анализ программы на предмет критических мест (нехватка памяти, переполнение стека)
— Аккуратное слежение за выделением и освобождением памяти
— Стиль кодирования


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