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

DOO>>>Каким бы ни было ТЗ оно не может описать весь входной язык, все состояния автомата и функцию перехода. Это просто нереально.
V>>it depends (c)
DOO>Пример такого ТЗ, раз depends :)

боюсь, придется поверить на слово. если интересует область ПО: рентгеноспектральный анализ; контроллеры излучателей.


DOO>>>А почему ты все сводишь только к входным данным, причем только к тем, которые может ввести пользователь системы?
V>>где я говорю только о пользователях системы?
DOO>Хорошо переформулируем — ты все ограничиваешь только синхронными данными, не учитывая, например, асинхронные сигналы.

где?

DOO>Про обработку отказов оборудования я вообще молчу.

я отношу это тоже к входным воздействиям на систему.


V>>Это не входные данные системы?
DOO>По твоим рассуждениям создается такое впечатление.

по каким именно рассуждениям?


V>>асутп аэс и асутп арбузорастительного комбината — разные вещи с точки зрения требований к надежности. именно минимальных требований, но, разумеется, никак не верхнего ограничения культуры разработки.
DOO>В общем-то да. Но опять же, если речь о коробочном продукте (в смысле для массового использования), то тут ты уже не знаешь будет это АЭС или арбузорастительный комбинат.

в общем-то, согласен. но будет ли в аэс кто-либо использовать коробочный продукт школьника Васи Пупкина? если речь идет о выполнении требований надежности, то для системы подбираются компоненты, удовлетворяющие этим требованиям, ибо итоговая надежность условно не выше минимально надежного компонента ("условно" — потому, что "надежность" без конкретики применения — это сферический конь в вакууме). соответственно, ничто не мешает совместно существовать коробочным продуктам с надежностью 95%, 99%, 99.999%, решающим одну и ту же задачу, но с различной стоимостью. вряд ли много кому нужен стандартный калькулятор, с надежностью "пять девяток" за $5000 за одну лиценцию.