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

если открыть серьезную книжку по тестированию ПО там все подходы по генерации формальных признаков уже написаны

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

T>>Все 4 твоих случая и есть "человеческий фактор", а опечатки это реально не только опечатки.
DG>под человеческим фактором обычно подразумевают то, что свойственно человеку, и не свойственно машине (цифровому автомату)

Правильно. Решение задач вообще не свойственно машинам.

T>>1. недостаточно полная информация — основная причина
T>> а. недостаточный уровень знаний ЧФ !

DG>машине это свойственно даже в большей степени

А что, у машин уже есть разумная жизнь ? Не знал.

T>> б. неверная методология ЧФ !
DG>аналогично

Методология управление своей деятельностью, требует разумной жизни

T>>2. неверная реализация ЧФ !
DG>тем более

Дай ка ссылку на какой нибудь реализатор задач

T>>3. фактор помехоустойчивости — ЧФ ! проявляется в том в п.п. 1..2 человек просто делает ошибки.

DG>и только вот это ЧФ, потому что именно человеку свойственно делать каждый раз одно и тоже чуть-чуть по другому

T>> усталость
DG>усталось это тоже не ЧФ, за ddos тот же rsdn и ошибки от "усталости" rsdn сразу полезут.

Усталость это только один из ЧФ, т.к. именно из за неё человек и делает одно и то же каждый раз чуть чуть по другому.

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

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

DG>если открыть серьезную книжку по тестированию ПО там все подходы по генерации формальных признаков уже написаны

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

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

таким свойством обладает широкий класс алгоритмов, которые перестраивают себя на основе свой деятельности: переборные алгоритмы с перестроением последовательности перебора, нейронные сети и т.д.

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

это лишь говорит о наличии задачи: построить проектную документацию на русском языке на основе кода.

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

IT>>Если коротко, то я это понимаю как меру усилий, требуемых для решения поставленной задачи.

T>Это сильно субъективное определение. Задача одна и та же, но одному для решения надо только синтаксис нового языка освоить, а другому всё программирование целиком, а третьему еще и математику дополнительно подтянуть.

Всё правильно. Никто не отрицает, что сложность субъективна. Поэтому и определение такое субъективное.

T>Проще определять как количество составляющих в описании решения, тогда можно переводить метрику и в количество усилий и в количество ошибок на километр.

Это всё части целого.

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

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

DG>это лишь говорит о наличии задачи: построить проектную документацию на русском языке на основе кода.

В каких книгах по тестированию ПО описывается решение этой задачи ?

T>В каких книгах по тестированию ПО описывается решение этой задачи ?

решение этой задачи к тестированию никакого отношения не имеет.

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

T>>В каких книгах по тестированию ПО описывается решение этой задачи ?

DG>решение этой задачи к тестированию никакого отношения не имеет.

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

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

M>Программинг только на заре 70-ых был "академическим", да и то математика там привлекалась только в силу требуемых алгоритмов. В целом же, программинг — это вообще отдельная дисциплина, где не то что "математическую модель", пару квадратов на бумаге — и то сложно расположить! Простой пример: GUI usability. Психология+интуиция+чтобы работало. Или вот базы данных — их что, по рядам Фурье считают? Далеко нет. Тупо "на практике" проверяют, будет ли отзывчивой система при 20 запросах в сек. Почему 20? Да просто эмпирика!

Все это так, но плохо, что это так. Когда-то и инженеры "эмпирически" конструировали, и в программировании это пройдет.

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

DG>не вижу кода SyncTabs

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

DG> и анимации

Анимацию добавить не сложно:

List<Tab> tabs;
int initialTabCount;
DateTime animateTime;

Timer animateTimer;
animateTimer.Tick += delegate
{
  if (DateTime.UtcNow - animateTimer > animateDuration)
  {
    initialTabCount = tabs.Count;
    animateTimer.Stop();
    return;
  }

  Invalidate();
};

void panel_MouseLeave()
{
  animateTime = DateTime.UtcNow;
  animateTimer.Start();
  Invalidate();
}

LazyMaker tabMaker = new LazyMaker(
  delegate
  {
    if (tabs.Count == initialTabCount)
    {
      SyncTab();
    }
    else if (DateTime.UtcNow - animateTime < animateDuration)
    {
      SyncTabWithAnimate(DateTime.UtcNow - animateTime);
    }
    else
    {
      SyncTabSpecial();
    }
  },
  delegate { return panel.Size; },
  delegate { return tabs.ChangeTick; },
  delegate { return initialTabCount; }
);

void ClickTabDelete(Tab tab)
{
  tabs.Remove(tab);
  Invalidate();
}

void Invalidate()
{
  tabMaker.Make();
}

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

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

HH> А что если предположить, что баг не должно быть вообще? Почему человек не может думать без ошибок? В чем причина ошибок?
HH> Мне кажется, основная причина в том, что разработка происходит стихийно, каждый пишет, что ему придет в голову.

если вы остановите впадение всех вод в океан, я вам напишу программу без ошибок

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

J>если вы остановите впадение всех вод в океан, я вам напишу программу без ошибок

Лети на Марс, там все воды остановлены — будешь кодить без ошибок.

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

J>>если вы остановите впадение всех вод в океан, я вам напишу программу без ошибок
R3>Лети на Марс, там все воды остановлены — будешь кодить без ошибок.

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

U>Что ты там рассчитываешь увидеть интересного?

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

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

DG>хотя бы почему его три, и почему именно этот код растет при увеличении задачи.

Потому что логически есть три разные задачи:

1) Штатное размещение закладок на панели
2) Размещение закладок на панели таким образом, чтобы крестик следующей закладки оказался на месте крестика удаленной закладки
3) Размещение закладок на панели в ходе анимации

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

DG>есть подозрение, что этот код дублируется (содержит элементы copy-paste)

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

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

I>Все это так, но плохо, что это так. Когда-то и инженеры "эмпирически" конструировали, и в программировании это пройдет.

а они перестали "эмпирически" конструировать?

Почему тогда тестовые полигоны до сих пор не разломали, аэродинамические трубы и т.п.

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

K>В XIX веке инженеры-мостостроители тоже, в массе своей, не верили в математику — они же практики, а не непойми кто. И мосты падали. А как иначе-то?

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

U>Не понял проблему.

ты не привел полноценного кода, который можно запустить — это проблема.

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

C>Имхо, скорее программист это "исследователь". До некоторой степени конечно.

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

C>Создание софтины во многом похоже на исследование, на поиск решения. А где это видано чтобы она находилось сразу да еще и единственно верное!?! (а иначе, нахр мы все нужны, если решение есть)? Не зря Брукс говорил "первая версия системы всегда отправляется в помойку".

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

C>А математику мы любим, и ценим, и уважуха с респектом. Только
C>а) Вопрос ни как считать, а что... Частенько "математики" знают как считать, но мало имеют понятия что и зачем. Неспроста программирование азмь езмь прикладная математика...
C>б) А Эдсгер Дейкстра про математику и программирование как то отмечал "что слабым (poor) математикам лучше оставаться чистыми (pure) математикам". И совершенно прав. Видал примеры не по разу..

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

C>думать надо головой.

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

C>Математика это такая острая сабля, ею можно как и красиво колбаску нарезать, так и яйца себе отрубить.

Острая сабля — это как раз голова. А математика — это бронещиток на яйцах.

C>Так что голова, голова и еще раз голова. Математика всего лишь инструмент, причем в котором очень важно понимать граничные условия применимости того или иного решения.

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