VITAL

Строку подключения можно получить следующим образом:
1. Создать файл с расширением *.udl.
2. Открыть файл и настроить соединение.
3. Сохранить файл.
4. Открыть этот файл в текстовом редакторе. Там будет нужная строка подключения.

У меня вот работает такой код
procedure ADOQuery;
var
ADOQuery: variant;
ConnectionString: String;
begin
ADOQuery := ADO.CreateADOQuery;
ConnectionString := 'Provider=SQLOLEDB.1;Password=ottpwork!@;Persist Security Info=True;User ID=sa;Initial Catalog=OTTPAUTOTEST77;Data Source=w248s3\sql2008';
ADOQuery.ConnectionString := ConnectionString;
ADOQuery.SQL := 'select top 1 Analit from MBAnalit';
ADOQuery.Open();
ShowMessage(ADOQuery.Field[0].AsString);
end;

У нас в компании для определения трудоемкости тестирования появилось желание выделить некие неделимые функциональные блоки продукта (Заполнение лог-файла, заполнение карточки справочника, и т.д.). Трудоемкость тестирования каждого блока фиксирована. Т.е. при написании стратегии тестирования мы просто берем блоки, которые будут в разрабатываемой функциональности и суммируем их трудоемкости тестирования. Для чего это надо. Чтобы дать на ранних стадиях более достоверную информацию о трудоемкости тестирования для руководителя проекта. А также чтобы эта трудоемкость была максимально прозрачна для всех (чтобы вопросов было меньше). Почему-то у меня в душе есть очень большие сомнения что такой метод будет работоспособным. В чем мои сомнения:
1. Мне кажется просто невозможным выделить все блоки, чтобы потом что-то по ним спрогнозировать.
2. Разработка временами кардинально меняется. Так что трудоемкость будет не верной.
3. На момент определения трудозатрат не всегда вообще еще ясно даже разработчику в полном объеме из чего будет состоять функциональность и как она будет реализована.
Сейчас определение трудозатрат происходит следующим образом:
1. Изучение тестовой основы (требования, ТЗ, проекты разработчиков и т.д.);
2. Выделение объектов тестирования.
3. Для каждого объекта определяется вид тестирования.
4. По каждому объекту выписывается список функций (уровень детализации не очень высокий)
5. Определяем на каких стенда нужно будет протестировать
6. На основе всего этого делаем вывод о трудоемкости тестирования с учетом возможных рисков и собственного опыта.
Существующий метод вроде бы полностью удовлетворяет.
Занимался ли кто-нибудь выделением этих самых блоков и каков результат? Оправданы ли мои сомнения?

Допустим, по каким то причинам сервер с папкой \\Test\Lib\ не работает, т.е. модуль MyLib "выключился". Но к счастью у нас на локальной машине в папке C:\Lib\ есть копия файла MyLib.sd.

А что мешает сразу подключить локальный файл?

Ну считывай параметры с файла и передавать в качестве параметра командной строки это все таки не одно и тоже...

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