Сообщений в теме: 53

[barancev]

Как то незаметно дискуссия разделила всех на два лагеря - тех, кто считает найденные ошибки, и тех, кто считает оставшиеся.
;)

Я отношу себя к третьему лагерю -- тех, кто считает и то и другое.
Более точно: считает, сколько найдено, для того, чтобы оценить, сколько ещё осталось.

Согласен

Вообще-то Вы не должны быть согласны, потому что у Вас нет необходимости оценивать, сколько осталось :)

[Viktor]

Viktor,
допускаю, что между Вами и Вашим топ-мереджером происходит следующий диалог:
ТМ: - Продукт готов?
V: - Готов!
ТМ: - Смотри, головой отвечаешь!
V: - Дык, тык, мык, как всегда!
ТМ: - Тогда запускай!

Конечно, не так поэтично, но общий смысл понятен.

Но что позволяет Вам быть субъективно уверенным, что разрабатываемое приложение готово?

Объективные доказательства. Какие? - не скажу, наверняка, скажете, что - это религия.

[Viktor]

Вообще-то Вы не должны быть согласны, потому что у Вас нет необходимости оценивать, сколько осталось :)

Удивительно, но я согласен с Вашей позицией, просто в этом отношении мне "повезло" больше :).

[Viktor]

Вы упомянули верификацию. Что Вы имели в виду -- динамическую верификацию (в просторечии называемую тестированием) или формальную проверку правильности программы?

Безо всяких ограничений, просто этот процесс оценки продукта (артефакта). По большей части экспертный.

[Undi]

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

Допустим, Вы уверены, что понимаете все исходные требования. Допустим, тестирование прошло успешно. Что дает Вам уверенность, что ошибок нет?
Без привязки к конкретным условиям.

Верификация

О терминологии говорили в теме "Verification & Validation - что это такое?".
Цитирую Ваш ответ в ту тему:

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

Т.е. ранее Вы говорили о доле вероятности.
А теперь повторю вопрос: что Вам дает уверенность, что ошибок нет вообще?

[Viktor]

О терминологии говорили в теме "Verification & Validation - что это такое?".

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

Т.е. ранее Вы говорили о доле вероятности.

Все верно, но там я рассматривал частный случай - верификация программного продукта.
Мысль была какая, имеется некая одна высокая оценка качества какого-то артефакта, она снижает вероятность получить некачественный продукт (не программный! комплекс: программа+услуги).
Чем больше внутренних артефактов оценивается, и оценки выше, тем менее вероятность получить некачественный продукт. Если мы начнем оценивать процессы создания, то еще уменьшаем вероятность дефектов. Те рассуждения общие, это работает в общем, ни каких конкретных применений. (Причем, в ходе той дискуссии Анатолий намекал на узость нашего понимания этих процессов, поэтому здесь я просто привел общий термин, без всякой конкретной привязки к какому-либо виду деятельности или процессу)
А конкретная ситуация следующая - во-первых, эти оценки должны быть экспертные, во-вторых, здесь не может быть каких-то промежуточных состояний например "готовность 70%" или "вероятность возникновения ошибки 0,10", артефакт либо готов, либо нет, и в третьих, ответственность - персональная.
И опять же метод оценки топ-менеджментом - не объективен (в любой организации, в нашей точно). Я - сторонник объективных методов, но я не топ-менеджер.
Еще раз повторюсь - это очень затратно по времени и экономически необосновано, однако успешно работает.

А теперь повторю вопрос: что Вам дает уверенность, что ошибок нет вообще?

1. Аутотренинг. (Спасибо, Алексей!)
2. Контроль процессов разработки.
3. Оценка артефактов
4. Тестирование программного продукта (его можно и выше, но пусть тут)
5. Налаженная процедура разрешения проблем.
6. Следование стандартам и методологиям
7. Персональная ответственность перед заказчиком
Вот семь моих субъективных методов повышения уверенности в отсутствии ошибок в условиях моей корпорации. Может что-то пропустил.

[Green]

Браво, Viktor!
Вы, как истинный партизан, не выдаете тайны ни при каких обстоятельствах!
B)

Но Вы сильно меня заинтриговали и, наверное, не только меня.

Где же Вы работаете и что производите?
Единственное предположение, которое я могу сделать, Вы работаете в компании - системном интеграторе, т.е. Ваша компание скорее не разрабатывает ПО, но адаптирует его к нуждам заказчика и поставлеет в комплексе с "железом".

[Viktor]

Браво, Viktor!
Вы, как истинный партизан, не выдаете тайны ни при каких обстоятельствах!
B)

Но Вы сильно меня заинтриговали и, наверное, не только меня.

Где же Вы работаете и что производите?
Единственное предположение, которое я могу сделать, Вы работаете в компании - системном интеграторе, т.е. Ваша компание скорее не разрабатывает ПО, но адаптирует его к нуждам заказчика и поставлеет в комплексе с "железом".

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

[Undi]

1. Аутотренинг. (Спасибо, Алексей!)
2. Контроль процессов разработки.
3. Оценка артефактов
4. Тестирование программного продукта (его можно и выше, но пусть тут)
5. Налаженная процедура разрешения проблем.
6. Следование стандартам и методологиям
7. Персональная ответственность перед заказчиком
Вот семь моих субъективных методов повышения уверенности в отсутствии ошибок в условиях моей корпорации. Может что-то пропустил.

Я тоже считаю, что Ваши методы субъективны. Во всяком случае, мне они 100%-ной уверенности не дают :)

[Viktor]

Во всяком случае, мне они 100%-ной уверенности не дают :)

А какой смысл измерять уверенность в процентах?
Как Вы объясните заказчику, что уверены в продукте на 80%? А если его бизнес зависит от Вашего продукта? Т.е. за его деньги вы навесите на него дополнительные риски? Я думаю, спасибо он Вам не скажет, более того.

Шутка за шуткой, и мы подошли к серьезным вещам:
Уверенность в себе, в своей команде, в своем продукте, нужна ли она?
Что нужно, чтобы быть уверенным в выше перечисленных пунктах?
Вот я предложил несколько методов, практически все они крутятся вокруг верификации. Валидация тоже является важным методом. Верно было подмечено, что поднятие уверенности в команде возможно и методами самовнушения, мне кажется это лучше, чем внушать неуверенность. Метрики процессов разработки также повышают уверенность. Гарантии производителя продукта.
Теперь приглашаю всех дополнить список.

[barancev]

Шутка за шуткой, и мы подошли к серьезным вещам:
Уверенность в себе, в своей команде, в своем продукте, нужна ли она?
Что нужно, чтобы быть уверенным в выше перечисленных пунктах?

Вообще-то мы не то чтобы подошли, а партизанскими способами осуществили подмену темы -- вместо ответа на простой и понятный вопрос (цитирую Светлану): "что Вам дает уверенность, что ошибок [в выпускаемом продукте] нет вообще?", Виктор предлагает нам пафосные высказывания по поводу уверенности в себе, в своей команде и т.п. Я бы квалифицировал это как увиливание от ответа :)

[Viktor]

Вообще-то мы не то чтобы подошли, а партизанскими способами осуществили подмену темы -- вместо ответа на простой и понятный вопрос (цитирую Светлану): "что Вам дает уверенность, что ошибок [в выпускаемом продукте] нет вообще?",

Заданы конкретные вопросы. Ответы сложны и требуют рассуждений.

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

Это идет в разрез с чьими-то интересами? Чем же это плохо?

Я бы квалифицировал это как увиливание от ответа :)

Неправда, я написал 7 (!) четких методов. Хотел увильнуть потому как не хотел навязывать системное видение, но не удалось :)

[Undi]

видимо, мы опять говорим на разных языках

[Viktor]

видимо, мы опять говорим на разных языках

Я все еще во власти данного Вам обещания. Хотя сомнения уже закрадываются в мою голову :).