Пока решил ограничиться только отчетами, необходимыми топ - менеджменту.

Какие, например?
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))

Хм. Не пристало так делать компании, которая свято блюдёт стандарты качества процессов :P

Алексей, разверните мысль, расскажите, что пристало адептам стандартов качества процессов?

Я вам как менеджер (не топ, конечно, но всё таки ) скажу

Желаю Вам добраться и до топ.

Кстати, кто поедет на STARWEST? Я -- поеду!

Придется пропустить :)
(причину смотреть выше :))

Пока решил ограничиться только отчетами, необходимыми топ - менеджменту.

Какие, например?
(Просто интересно, в моем случае просто спрашивают: "Ну что, готово?" :))

А в чем сложность? Используйте Ado, их Basic это позволяет, нет?
Или воспользуйтесь ODBC. Четыре функции: подключился, выбрал, взял, отключился.

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

Алексей, скажите честно, все думают разное, или одно и тоже?

Посмотрите на наш форум. Даже ещё проще -- на Вас и на меня и на наши мнения про процессы :)

Когда все думают одинаково -- это скучно.

Я понял, что мы думаем одинаково, просто по-разному называем :)
То, что скучно - это верно.

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

Поработайте вольно, добавьте практических примеров, пояснений, комментариев и это будет уже Ваше авторское право. Слова-то у всех одинаковые (хотя бывают исключения :)).

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

Алексей, скажите честно, все думают разное, или одно и тоже?

Я понимаю это, но в моем городе (Днепропетроск) я не нашла предложений.

В Москву надо, в Москве вся сила

Москва- это хорошо :rolleyes:

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

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

Мне казалось этот форум посвящен решению проблем, связанных с Rational Tools

За решение, безусловно, спасибо :)
Только способ, возможно, не совсем универсальный?

В этом деле майкрософту можно смело доверять :)

А как же "У всех машины настроены по разному, а тем более тестовые станции" ?

И вам не советую :)

"Не годен"?

Вообще-то, себя имел ввиду. Совпало :)

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

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

Я понимаю это, но в моем городе (Днепропетроск) я не нашла предложений.

В Москву надо, в Москве вся сила

Хороший договор - тоже требование процессного ГОСТа

Возьмите такой пример: без ТЗ нельзя оказывать качественных услуг, с этим все согласны (кроме бабушки :)).

Не только бабушка, я тоже с этим не согласен :)

Хорошо, заменяю "нельзя" на "сложно". Хотя для меня это одно и тоже.

Нельзя бросать дело, не доделав его до конца. Особенно, когда за этот конец заплатили и его ждут :).

А разве, кто-то с этим спорит?

B)

Никто, наверное, просто размышляем :)
Вот, например, если все с этим согласны, то как это гарантировать?
Мой тезис такой - Качество процесса - гарантия доведения проекта до качественного конца.
Чем меньше качество процесса - тем меньше гарантии.
Алексей требует ответа "Да или Нет". Я сказал "Да"
Человек 8, мне кажется, вот здесь уже возразят.

Полностью согласен, Вячеслав, с конкретными примерами.
Я просто хочу сказать, что нельзя обобщать. Хотя бы и с ценами на услуги. Чем сложней проект, тем больше вероятность, что он потребует перевыделения ресурсов, изменения графиков, приоритетов. Партнеры должны ориентироваться на долговременное сотрудничество, полностью доверять друг другу. Я привык даже в себе сомневаться, что уж говорить о постороннем человеке :).
"Сомнение - есть целомудрие мозга" Р.Желязны

Viktor,

Вы полностью соответствуете выбранному Вами псевдониму!

Спасибо

Какова основная мысль в Вашем предыдущем сообщении?

B)

Нельзя бросать дело, не доделав его до конца. Особенно, когда за этот конец заплатили и его ждут :).
И если что-то от этого дела долетело, нельзя говорить что это именно тот конец.
(Скоро начну себя в рамки вставлять :))

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

Тоже отличный аргумент "ЗА".

Не согласен, что это аргумент "ЗА", разве цель бизнеса обменивать деньги на время? Поэтому кажется странным мне софтверной фирме оутсорсить тестирование. Тестирование - неотьемлимая часть разработки. Цель бизнеса - через разработку ПО получать прибыль. Но! Если фирма не занимается самостоятельным созданием ПО, то она может зааутсорсить все, что угодно, связанное с ним. При этом обменяет свое время (затраченное на поиск аутсорсеров) на деньги заказчика. :)
Аутсорсинг возможен, если рабочая сила дешевле или есть какие-либо доп. преимущества. А так - "точите чужое оружие".
Как же определить дешевле или нет? Сначала посчитать свои затраты, затем - узнать цену аутсорсера. Вот свои затраты именно на этот проект (а особенно - предполагаемые :)) точно посчитать очень трудно. Во что выльется цена аутсорсера - тоже. Появляется некая переменная трудно контролируемая (так как требует жесткой самодисциплины) - аутсорсер. К чему приводит она ? - К увеличению риска.
Есть ли какие-то доп.преимущества? Здесь уже больше объективной информации. Предополжим, специализация продукта, наличие продуктов для тестирования, цели проекта и т.д (профсоюз?). Возможно, требуется сертификация продукта, лицензирование деятельности и т.д. К чему приводит использование аутсорсера в этом случае? - К уменьшению риска.
Вот проблема с определением дешевизны рабочей силы, как раз и приводит к сложности использования этого процесса. Может быть "аутсорсинг" - это не то слово которое нужно употреблять?

Прыгун в высоту. Хороший прыгун. Гарантированно прыгает 2 метра, даже выше может, но 2 метра -- гаратированно. Имеет сертификат "Прыгун на 2 метра". Как он его получил? Сертификационная организация проверила, что 1000 последних прыжков была не ниже 2 метров и на основании этого выдала сертификат.

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

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

Сертификация подтверждает, что организация знает как и умеет следовать качественному процессу. Но она не даёт гарантий для данного конкретного проекта.

Если это качественный прыгун и он следует требованиям, он не остановится пока не прыгнет на два метра, даже если первый раз ему это не удалось.
Именно для того, чтобы не было таких "брошенных" прыжков и существуют требования стандартов по обеспечению качества. Прыгун должен прыгать до тех пор, пока не перепрыгнет. И заказчик знает, прыгун будет прыгать, а не плюнет и скажет, что "в следующий раз". И вот это я называю гарантия качества и этого требует стандарт. Прыгать не до обеда (или один раз), а прыгнуть на определенную высоту, и не важно сколько раз придется прыгнуть для этого. Хотя в другой ситуации, возможно, потребуется прыгать до обеда. Значит качественный будет тот прыгун, который будет прыгать до обеда.
Заказчик не любит случайностей. Все должно быть определено и измерено. ГОСТ нужен заказчику, а не производителю изначально. Здесь палка о двух концах, на одном конце один поставщик, у которого, возможно, "толковые ребята", на другом - поставщик с гарантированным качеством услуги. Где заказчик? Особенность системы менеджмента качества как раз и заключается в том, что стоимость услуги не увеличивается(даже сокращается). Заказчику должно гарантироваться качественное исполнение заказа. А сколько это стоит (сколько раз нужно прыгнуть), это не проблема качества (хотя, возможно, проблема заказчика). Возьмите такой пример: без ТЗ сложно оказывать качественные услуги, с этим все согласны (кроме бабушки :)). Сколько будет стоить разработка продукта без ТЗ, или по ТЗ? Заказчику? Разработчику? (Я уже не говорю о рисках вообще не получить продукта). Но получение продукта - лишь доля работ по получению прибыли. Его нужно качественно подать, качественно поддержать и т.д. Вот у разработчика есть продуктный стандарт. Продукт удовлетворяет требованиям заказчика сегодня. А завтра? Заказчику, необходимо чтобы и завтра он удовлетворял его требованиям. А где это требование прописано? В процессном стандарте :). Вот и понятие возникло - жизненный цикл. Требования стандарта - обеспечение качества на протяжении всего жизненного цикла. Хочешь мертвую программу - пожалуйста, говорят, есть нетленные тела. Лично мне нужна программа без запаха. "Программа умирает", если не поддерживается и не обслуживается. Прыгун дряхлеет и чахнет, банан гниет. Но появится новый прыгун, вырастет новый банан. Появится другая программа и другой разработчик на нашем месте, если мы не будем качественно исполнять заказ.

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

Почему нельзя гарантировать заранее, что проект будет следовать качественному процессу?
Сертификация как раз это и подтверждает.

При применении на предприятии устоявшихся процессов качество разработок будет выше (при условии соблюдении стандартов на эти процессы).

Не уверен, цель устоявшихся (адаптированных?) процессов может быть далека от целей обеспечения качества.