В настоящее время большинство решило, что premature optimization — это зло, что этого делать не надо. Надо создать некую работающую систему, а потом посмотреть — работает ли она с нужными характеристиками. Если нет — оптимизировать те места, которые являются узким местом, находить их можно с помощью профайлера и т.д.
Я в настоящем сообщении сам этот принцип предлагю не обсуждать. Примем его в этом топике как есть, хотя я и не согласен с ним.
Потому что мой вопрос в ином.
Заявляя такое, отдаете ли вы себе отчет, в том, что вы фактически говорите : "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
(Отмечу со своей стороны, что ИМХО эта точка зрения как-то не очень вяжется с методами, используемыми при разработке иных систем. Трудно предположить, что разрабатывая самолет, создатели бы сказали — мы не знаем, с какой скорстью он будет летать, построим — посмотрим, если мало будет — будем что-то улучшать. Или, скажем, мостостроители заявили — не знаем, выдержит ли это мост груженые песком МАЗы, если не выдержит и обломится — добавим быков и укрепим полотно. Или.. примеров можно много привести. Но это в скобках).
А теперь вопрос.
Если вы признаете, что предсказать характеристики системы априорно нельзя, то из-за чего это ?
Возможные варианты ответа.
1. Это в принципе нельзя, система слишком сложна.
2. Это нельзя, потому что у нас нет для этого инструментов и методов. Пока нет. Если они появятся — сможем.
3. Это нельзя, потому что у нас на это нет денег. Нам дешевле сделать что-то , а потом исправлять, нежели потратить время на дотошный анализ.
Естественно, если есть другие варианты ответа — welcome.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А теперь вопрос.
PD>Если вы признаете, что предсказать характеристики системы априорно нельзя, то из-за чего это ?
PD>Возможные варианты ответа.
PD>1. Это в принципе нельзя, система слишком сложна. PD>2. Это нельзя, потому что у нас нет для этого инструментов и методов. Пока нет. Если они появятся — сможем. PD>3. Это нельзя, потому что у нас на это нет денег. Нам дешевле сделать что-то , а потом исправлять, нежели потратить время на дотошный анализ.
PD>Естественно, если есть другие варианты ответа — welcome.
Оценить можно — для этого разрабатываются прототипы. Данная оценка требуется это для выбора подходящей архитектуры.
Здравствуйте, Pavel Dvorkin, Вы писали:
>Если вы признаете, что предсказать характеристики системы априорно нельзя, то из-за чего это ?
Усредненно и неточно — пожалуйста. Любая сложная система — она как погода. Или как вес яблока — Вы можете точно сосчитать вес яблок на столе (т.е. с учетом, например, притяжения Проксимы Центавра, и топота слонов в Африке)?
Пример — постоянные срачи JVM/Mono на ЛОРе: что быстрее? И у всех — разные оценки. Хотя казалось бы....
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>(Отмечу со своей стороны, что ИМХО эта точка зрения как-то не очень вяжется с методами, используемыми при разработке иных систем. Трудно предположить, что разрабатывая самолет, создатели бы сказали — мы не знаем, с какой скорстью он будет летать, построим — посмотрим, если мало будет — будем что-то улучшать. Или, скажем, мостостроители заявили — не знаем, выдержит ли это мост груженые песком МАЗы, если не выдержит и обломится — добавим быков и укрепим полотно. Или.. примеров можно много привести. Но это в скобках).
Они используют два способа получить результат:
1)Сделать с большим запасом.
Получается очень дорого.
2)Компьютерные симуляции, продувка прототипов в аэродинамической трубе и тд и тп.
Вот как раз:
"Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось"
Разница в том что в отличии от инженеров которые делают самолет программисты могут обкатывать реальную систему, а не макет.
Ибо построить самолет очень дорого, а собрать программу из исходников почти ничего не стоит.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Заявляя такое, отдаете ли вы себе отчет, в том, что вы фактически говорите : "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
Да, не в состоянии. И на рынке не видно никого, кто в состоянии это сделать для мало-мальски сложной системы. Во всяком случае, судя по результатам работы
PD>1. Это в принципе нельзя, система слишком сложна. PD>2. Это нельзя, потому что у нас нет для этого инструментов и методов. Пока нет. Если они появятся — сможем.
Во первых, сам по себе программный продукт — это очень сложно. Там огромное количество "составных частей" и связей между ними.
Во вторых, каждый программный продукт — уникален (если тебе нужен второй "точно такой же" продукт — ты просто используешь существующий или копируешь с минимальными изменениями). В этом радикальное отличие от проектирования мостов или например самолетов. Соответственно, использовать при предварительном анализе характеристики других проектов получается редко.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Привет всем!
PD>В настоящее время большинство решило, что premature optimization — это зло, что этого делать не надо. Надо создать некую работающую систему, а потом посмотреть — работает ли она с нужными характеристиками. Если нет — оптимизировать те места, которые являются узким местом, находить их можно с помощью профайлера и т.д.
PD>Я в настоящем сообщении сам этот принцип предлагю не обсуждать. Примем его в этом топике как есть, хотя я и не согласен с ним.
PD>Потому что мой вопрос в ином.
PD>Заявляя такое, отдаете ли вы себе отчет, в том, что вы фактически говорите : "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
PD>(Отмечу со своей стороны, что ИМХО эта точка зрения как-то не очень вяжется с методами, используемыми при разработке иных систем. Трудно предположить, что разрабатывая самолет, создатели бы сказали — мы не знаем, с какой скорстью он будет летать, построим — посмотрим, если мало будет — будем что-то улучшать. Или, скажем, мостостроители заявили — не знаем, выдержит ли это мост груженые песком МАЗы, если не выдержит и обломится — добавим быков и укрепим полотно. Или.. примеров можно много привести. Но это в скобках).
Предельные характеристики вообще не получится оценить. На в программной инженерии, ни в строительстве мостов.
Иногда есть некоторые целевые характеристики (без достижения этих характеристик бессмысленно делать что-либо): тонн грузоподъемности моста, масса боевой машины десанта, дальность полета межконтинентального самолета . Естественно любой проект должен учитывать эти характеристики.
При этом мосты проектируются так, что никто и не сможет сколько он на самом деле выдержит тонн, потому что для проверки придется сломать мост. Обычно проектируют так чтобы перекрыть целевой показатель в несколько раз.
Для подавляющего большинства программных продуктов таких целевых характеристик нет, поэтому в проекты их никто не закладывает. Кроме того зачастую и нельзя задать эти характеристики (например сколько пользователей выдержит сайт), тогда начинают говорить о масштабировании.
Если же задаются целевые характеристики, то сразу же задаются и ограничения потока входных данных, а это значит что нужные характеристики можно вытянуть улучшением железа. И тут мы снова приходим к масштабируемости. То есть способности наращивать быстродействие увеличением количества ресурсов.
Бывают исключения, но встречаются они нечасто.
Поэтому оценивать заранее конечно можно, но зачастую не нужно.
Здравствуйте, WolfHound, Вы писали:
WH>Разница в том что в отличии от инженеров которые делают самолет программисты могут обкатывать реальную систему, а не макет. WH>Ибо построить самолет очень дорого, а собрать программу из исходников почти ничего не стоит.
Все же стоит уточнить. Если бы программу можно было целиком собрать из чужих исходников (или объектников, библиотек) — да. Если в программе придется применять автогенерируемые исходники — это уже некоторый труд на их генерацию. Но обычно приходится писать самому эти исодники вручную, а это уже немалый труд.
Впрочем, это к слову.
Сформулирую тогда вопрос несколько иначе.
Пусть в других отраслях и применяют описанные тобой методы. Но они все же изначально задаются некоторыми характеристиками и уверены в том. что их можно достигнуть. Я не знаю, как разрабатывали Конкорд, но изначально разработчики были уверены в том, что создать сверхзвуковой самолет можно, и эта уверенность базировалась на законах аэродинамики, термодинамики и чего-то там еще. Иначе они бы не стали его делать вообще.
Можешь ли ты, приступая к разработке некоторой системы, априорно сказать, что вот такие-то характеристики обязательно будут достигнуты ? Если да — на чем твоя уверенность основывается ? Если нет — не значит ли это, что ты приступаешь к разработке чего-то, не зная, какие у этого чего-то будут характерстики ? Можешь ли ты на основании каких-то соображений сказать, что достигнуть, скажем, требуемой производительности (понимай под ней что хочешь) невозможно при данном железе ? при данном софте ?
Здравствуйте, Wolverrum, Вы писали: >>Если вы признаете, что предсказать характеристики системы априорно нельзя, то из-за чего это ? W>Усредненно и неточно — пожалуйста.
Собственно, к чему все это было — чем мельче система, тем точнее можно определить ее поведение. Но вот характеристики ансамбля этих мелких систем обычно не равны сумме характеристик систем их составляющих. Пример — система из 5 молекул и 1000000 систем из 5 молекул (5000000 молекул) — имеют принципиально различное поведение: в системе из 5 молекул средняя энтропия довольно далека от хаоса за счет бОльшего размера флуктуаций, а в миллионе таких же систем мы этот хаос все же имеем. Поэтому оптимизация отдельных систем без оглядки на ансамбль ой не факт, что может привести к оптимизации характеристик ансамбля. В случае нашего антипаттерна имеем то же самое — применив, например, в одной подсистеме только быстрые сортировки без учета характера входных данных, вполне можно столкнуться с тем фактом что эти самые данные будут приходить преимущественно в обратно отсортированном порядке — и применение оптимального решения "сразу" в данном случае только вредит.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, WolfHound, Вы писали:
WH>>Разница в том что в отличии от инженеров которые делают самолет программисты могут обкатывать реальную систему, а не макет. WH>>Ибо построить самолет очень дорого, а собрать программу из исходников почти ничего не стоит.
PD>Все же стоит уточнить. Если бы программу можно было целиком собрать из чужих исходников (или объектников, библиотек) — да. Если в программе придется применять автогенерируемые исходники — это уже некоторый труд на их генерацию. Но обычно приходится писать самому эти исодники вручную, а это уже немалый труд.
PD>Впрочем, это к слову.
PD>Сформулирую тогда вопрос несколько иначе.
PD>Пусть в других отраслях и применяют описанные тобой методы. Но они все же изначально задаются некоторыми характеристиками и уверены в том. что их можно достигнуть. PD>Я не знаю, как разрабатывали Конкорд, но изначально разработчики были уверены в том, что создать сверхзвуковой самолет можно, и эта уверенность базировалась на законах аэродинамики, термодинамики и чего-то там еще. Иначе они бы не стали его делать вообще.
Они основывались на том, что уже были сверхзвуковые самолёты( т.е. на опыте коллег) и у них была задача спроектировать пассажирский самолёт с зданными характеристиками имея наработки в военном авиастроении и прочую, в т.ч., теоретическую базу.
PD>Можешь ли ты, приступая к разработке некоторой системы, априорно сказать, что вот такие-то характеристики обязательно будут достигнуты ? Если да — на чем твоя уверенность основывается ?
На опыте, практике других.
PD>Если нет — не значит ли это, что ты приступаешь к разработке чего-то, не зная, какие у этого чего-то будут характерстики ?
Исходя из опыта, можно сделать оценку с точностью ~20-30% с помощью прототипа. PD> Можешь ли ты на основании каких-то соображений сказать, что достигнуть, скажем, требуемой производительности (понимай под ней что хочешь) невозможно при данном железе ? при данном софте ?
Кроме очевидных вещей, только на остновании опыта/прототипа.
PD>Заявляя такое, отдаете ли вы себе отчет, в том, что вы фактически говорите : "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
Абсолютно неверно. Если продолжать вашу аналогию: зло — это экономия на весе салфеток на подголовниках даже до начала эскизного проекта. Сэкономить-то сэкономим, только в ход в наше творение будет через гальюн.
Я не собираюсь спорить с несколько абсурдным тезисом "отказавшись от преждевременной оптимизации — отказываемся от производительности". Производительность в первую очередь определяется алгоритмической сложностью, а уж затем — наноптимизациями. Если бы вы читали ответы в КСВ — никто не отрицал важность подбора "правильных" алгоритмов (а равно и важность дизайна без учёта нюансов реализации — чтобы была возможность исправить последствия неудачного выбора).
Пару часов назад собирался запостить в юмор результат подобной оптимизации, да что-то не смешно:
Stub-Insert: 2 170,0 ms
Stub-IndexesOf: 31,0 ms
Indexed-Insert: 158 578,0 ms
Indexed-IndexesOf: 0,0 ms
Сэкономил
PD>Если вы признаете, что предсказать характеристики системы априорно нельзя, то из-за чего это ?
Что вы понимаете под характеристиками системы? Сильно сложные штуки брать не будем, остановимся на обычном калькуляторе.
PD>Возможные варианты ответа.
Дешевле сделать хорошую архитектуру с запасом по оптимизации, чем выложиться по полной, и понять что развивать наше творение невозможно.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Все же стоит уточнить. Если бы программу можно было целиком собрать из чужих исходников (или объектников, библиотек) — да. Если в программе придется применять автогенерируемые исходники — это уже некоторый труд на их генерацию. Но обычно приходится писать самому эти исодники вручную, а это уже немалый труд.
Ты не понял о чем речь.
Написание исходных кодов == создание чертежей самолета.
Компиляция исходных кодов == строительство самолета.
Построить самолет дорого. Скомпилировать исходники почти ничего не стоит.
PD>Пусть в других отраслях и применяют описанные тобой методы. Но они все же изначально задаются некоторыми характеристиками и уверены в том. что их можно достигнуть. Я не знаю, как разрабатывали Конкорд, но изначально разработчики были уверены в том, что создать сверхзвуковой самолет можно, и эта уверенность базировалась на законах аэродинамики, термодинамики и чего-то там еще. Иначе они бы не стали его делать вообще.
Эта уверенность базируется исключительно на прототипах.
PD>Можешь ли ты, приступая к разработке некоторой системы, априорно сказать, что вот такие-то характеристики обязательно будут достигнуты ?
Про некоторые характеристики да.
PD>Если да — на чем твоя уверенность основывается ?
На существовании подобных систем.
Если подобных систем нет то пока не напишешь ничего не узнаешь.
Я ессно говорю не о программах уровня hello world.
PD>Если нет — не значит ли это, что ты приступаешь к разработке чего-то, не зная, какие у этого чего-то будут характерстики ?
Именно так и приходится делать.
Вот например делаю я тут генератор PEG парсеров.
Одно из требований это возможность использования полученного парсера для разбора кода в IDE в реальном времени те 2-3 метра в секунду минимум вынь да полож. Иначе оно будет бесполезно.
Когда я начинал это делать я не знал получится ли у меня получить нужную скорость.
Но благодоря куче хитрых оптимизаций таки получилось.
PD>Можешь ли ты на основании каких-то соображений сказать, что достигнуть, скажем, требуемой производительности (понимай под ней что хочешь) невозможно при данном железе ? при данном софте ?
Эти оценки можно делать для чегото очень маленького.
Для больших систем нельзя.
Единственно что можно сделать для больших систем это делать их масштабируемыми.
Это обычно отрицательно сказывается на производительности одной машины но окупается тем что машин можно поставить много. Ибо рано или поздно производительности одной машины всеравно не хватит. Я уж не говорю об обеспечении надежности.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Заявляя такое, отдаете ли вы себе отчет, в том, что вы фактически говорите : "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
S>Абсолютно неверно.
Что неверно-то ? Из отказа от преждеверенной оптимизации не следует то, что у меня выше в кавычках ? Сам отказ я не обсуждаю, об этом я писал. Я не для того этот вопрс поднял, чтобы получить еще одно обсуждение за или против.
Здравствуйте, WolfHound, Вы писали:
WH>Ты не понял о чем речь.
Ладно, шут с ним, я же писал, что это не важно.
PD>>Пусть в других отраслях и применяют описанные тобой методы. Но они все же изначально задаются некоторыми характеристиками и уверены в том. что их можно достигнуть. Я не знаю, как разрабатывали Конкорд, но изначально разработчики были уверены в том, что создать сверхзвуковой самолет можно, и эта уверенность базировалась на законах аэродинамики, термодинамики и чего-то там еще. Иначе они бы не стали его делать вообще. WH>Эта уверенность базируется исключительно на прототипах.
Хм... Когда ракету строили — были уверены, что она первую космическую наберет ? Прототипов-то не было. Или строили по принципу — давайте построим, тогда и выясним, может она со скоростью 8 км/ч летать или нет ? Сомнительно. Все же, думаю, рассчитали, и пришли к выводу, что можно.
А атомную бомбу возьми ? Получится или нет технически — никто не мог быть уверен, но что физически она возможна — знали точно, иначе бы и делать, скорее всего, не стали.
PD>>Можешь ли ты, приступая к разработке некоторой системы, априорно сказать, что вот такие-то характеристики обязательно будут достигнуты ? WH>Про некоторые характеристики да.
Что значит некоторые ? Про критические — всегда сможешь ? Под критическим я понимаю здесь те, недостижение которых отправляет всю работу в мусорную корзину.
PD>>Если да — на чем твоя уверенность основывается ? WH>На существовании подобных систем. WH>Если подобных систем нет то пока не напишешь ничего не узнаешь. WH>Я ессно говорю не о программах уровня hello world.
Hello, World не обсуждаем.
PD>>Если нет — не значит ли это, что ты приступаешь к разработке чего-то, не зная, какие у этого чего-то будут характерстики ? WH>Именно так и приходится делать. WH>Вот например делаю я тут генератор PEG парсеров. WH>Одно из требований это возможность использования полученного парсера для разбора кода в IDE в реальном времени те 2-3 метра в секунду минимум вынь да полож. Иначе оно будет бесполезно. WH>Когда я начинал это делать я не знал получится ли у меня получить нужную скорость. WH>Но благодоря куче хитрых оптимизаций таки получилось.
Хм. А если я тебя попрошу, скажем, написать нечто, что требует передачи с обычного диска 10 Гб/сек, то тоже возьмешься ? А если нет — почему со своим PEG взялся ? Личный опыт на уровне интуиции ? Или все же какая-то оценка была ?
PD>>Можешь ли ты на основании каких-то соображений сказать, что достигнуть, скажем, требуемой производительности (понимай под ней что хочешь) невозможно при данном железе ? при данном софте ? WH>Эти оценки можно делать для чегото очень маленького. WH>Для больших систем нельзя.
Тогда вернемся к 3 моим ответам — почему нельзя ? И к моему вопросу — означает ли...
WH>Единственно что можно сделать для больших систем это делать их масштабируемыми.
Ну это понятно — экстенсивный путь всегда возможен. Это я не хочу обсуждать сейчас.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что неверно-то ? Из отказа от преждеверенной оптимизации не следует то, что у меня выше в кавычках ? PD>>>: "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
Следует примерно так же, как неуловимость неуловимого Джо. И примерно по тем же причинам. Если вас не устраивает, что сейчас никто не пытается экономить на байтах, можно пойти 2мя путями:
1. Встать в позу д'Артаньяна.
2. Понять, что потеря байтов по сравнению с общим уровнем граблей — полная фигня.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Что неверно-то ? Из отказа от преждеверенной оптимизации не следует то, что у меня выше в кавычках ? PD>>>>: "Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
S>Следует примерно так же, как неуловимость неуловимого Джо. И примерно по тем же причинам. Если вас не устраивает, что сейчас никто не пытается экономить на байтах, можно пойти 2мя путями: S>1. Встать в позу д'Артаньяна. S>2. Понять, что потеря байтов по сравнению с общим уровнем граблей — полная фигня.
Я еще раз (но в последний!) объясняю, что я не обсуждаю здесь этот принцип. Я не обсуждаю здесь, что меня устраивает, а что нет. Я вообще свою точку не высказываю, кроме того места в скобках, где я сравнивал с иными отраслями. Но это в скобках. И даже там я не высказал своего мнения по этому вопросу, а лишь сравнил с другими отраслями.
Я спрашиваю — следует ли из этого принципа вот такое утверждение ?
"Мы не в состоянии априорно оценить характеристики разрабатываемой системы. Мы можем лишь ее сделать, а потом посмотрим, что у нас получилось" ?
Если не следует — объясни, почему не следует, без помощи Джо и д'Артаньяна.
Здравствуйте, Wolverrum, Вы писали:
W>Здравствуйте, Wolverrum, Вы писали: W>Собственно, к чему все это было — чем мельче система, тем точнее можно определить ее поведение. Но вот характеристики ансамбля этих мелких систем обычно не равны сумме характеристик систем их составляющих. Пример — система из 5 молекул и 1000000 систем из 5 молекул (5000000 молекул) — имеют принципиально различное поведение: в системе из 5 молекул средняя энтропия довольно далека от хаоса за счет бОльшего размера флуктуаций, а в миллионе таких же систем мы этот хаос все же имеем.
Пример не пойдет. Да, нельзя рассчитать поведение всех молекул, если их 5 млн. Но методы для оценки поведения этой системы есть, они совсем другие (статистическая термодинамика), и дают в результате информацию о поведении системы в целом не менее адекватно, чем квантовая механика об одной или 5 молекулах.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>В настоящее время большинство решило, что premature optimization — это зло, что этого делать не надо. Надо создать некую работающую систему, а потом посмотреть — работает ли она с нужными характеристиками. Если нет — оптимизировать те места, которые являются узким местом, находить их можно с помощью профайлера и т.д. PD>... PD>Естественно, если есть другие варианты ответа — welcome.
Я думаю, такая формулировка утрированна до неузнаваемости По-моему premature optimization относится собственно к "нижнему" этапу создания системы, то есть к кодингу. И здесь оно действительно зло, и по многим причинам. Начиная с непроизводительных затрат на неё, потенциальной опасности внести трудноуловимые баги, и вплоть до того, что она просто может мешать работе современных оптимизаторов. Плюс для неё действительно есть развиты диагностические средства, позволяющие избежать неоправданных трудозатрат.
Если же брать в целом, то оптимизацию на всех предшествующих этапах никто не отменял. Более того, ошибки допущенные на "высокоуровневых" этапах никакой низкоуровневой оптимизацией уже не исправишь, без ломки архитекторы и фактического перепроектирования системы. Вот эти ошибки и порождают всеми нами любимые "костыли".Особенно, на мой взгляд, это стало актуально сейчас, в эпоху многоядерности, когда вопросы параллелизма и масштабирования становятся определяющими в борьбе за производительность.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Если вы признаете, что предсказать характеристики системы априорно нельзя, то из-за чего это ?
PD>Возможные варианты ответа.
PD>1. Это в принципе нельзя, система слишком сложна. PD>2. Это нельзя, потому что у нас нет для этого инструментов и методов. Пока нет. Если они появятся — сможем. PD>3. Это нельзя, потому что у нас на это нет денег. Нам дешевле сделать что-то , а потом исправлять, нежели потратить время на дотошный анализ.
PD>Естественно, если есть другие варианты ответа — welcome.
В большинстве случаев не то что характеристики, но и собственно назначение системы является большой загадкой как для заказчиков, так и для исполнителей вплоть до начала ввода в эксплуатацию.
"Нормальные герои всегда идут в обход!"
