Письмо из ИСП РАН

Кто-то об этом только говорит, а кто-то уже это делает!
http://systech.miem.edu.ru/ogl-4-11.html
статья № 9.

Пардон, если честно, думал, что такие уже не используется.

Ну отчего же. В контексте опенсорс вполне себе катит: дешево и сердито, в смысле функционально. Дешево - это если не сложно, т.е. если структуры данных и их связи достаточно прозрачны, а запросы стабильно просты, чтобы не перенапрячь одного разработчика, то чего бы и не забацать простецкий движок выборки, хранения и поиска с простыми файлами, которые в ОЗУ нынешних компутеров можно всосать без остатка и только сплевывать на диск появляющиеся изменения. Конечно, если аппетиты начнут расти и программа начнет тяжелеть от своей могучести, ну тогда предется перенести все в СУБД и работать с ней. Но ведь до этого еще нужно дорасти.

Пардон, если честно, думал, что такие уже не используется. Хотя первую базу данных (бинарную) сделал на Prolog'e и впервые заработал на такой БД в "страшный" 93 ( а может и 94 , не помню).
После разъяснения Алексея, XML - на самом деле, не то.

Третий день молчат, как рыбы об лед.

А как и где хранить исходную информацию?

Это зависит от. От многого. Но если предположить, что приложение будет, что называется, однопользовательским (а оба предложения и Ваше и от Vadim вполне можно представить именно такими), то уместно забацать БД просто в файлах, хоть в текстовых, хоть в бинарных. Вполне себе вариант использовать легонькую реляционную (обеспечит простоту изменений) СУБД на один компутер (BDE от Delphi, какую-нибудь библиотеку для DBF, Access, FoxPro). Если уж без "тяжелой" РСУБД жизнь совсем не мила то бесплатных их тоже предостаточно, как и платных. Без XML. А без XML, зачем еще Sedna?

А как же ответ из ИСП РАН, разве мы его не дождемся? :?

Эта примерно такая же хрень, что и HTML. Те же теги, которые позволяют структурировать информацию, но более жесткие правила их применения. Совершенно ничего сложного. Фактически - это база данных с теговой разметкой. Правда, в упрощенном понимании.
Чтобы посмотреть , как это выглядит, можно в AuthorIT любой топик публикнуть в XML и посмотреть текстовым редактором или браузером.

А как и где хранить исходную информацию?

Использование XML? Возможно и без него можно справиться, я об этом змИе мало, что знаю (если честнее, то вообще ничего )

Развивайте больше отношений между существующими .

Молчание Алексея, по поводу ответа, говорит о том, что тему пора прикрывать.

Господа, мне представляется, что высказываемые идеи достаточно конструктивны, но вот нужна ли в их реализации СУБД? А если нужна, то отчего нужно заморачиваться еще и на XML? По моему скромному мнению СУБД хороша, когда есть конкурентный доступ, а XML должен давать некоторую гибкость (в виде змеи по Ляпису-Трубецкому ) не могу сказать чего. :roll: Как там с бритвой товарища Оккама - не плодите лишние сущности, однако.

В ряде случаев будет полезно использовать ГОСТ 12977-84. Изделия ГСП (Государственная система промышленных приборов и средств автоматизации). Общие технические условия.

На самом деле, ГОСТ В 20.39 вряд ли интересен широкому кругу разработчиков. Нужно взять за основу требования ГОСТ 15150-69, а ГОСТ В — это, уж, для нас, бедных .

Порядок действий практический такой же, как и в 27.003 (например, приложение 3).

В этом и смысл автоматизации и заключается. Если в базе данных, грубо говоря, реализовать хранение информации (в объеме ГОСТ В 20.39) и процедуры (запросы) обработки этой информации, то получится модель (база) знаний, необходимая для решения задачи создания ТЗ. Пользователь вводит исходную информацию, например, группу изделия, и ему выдается, что по таким-то характеристикам значения параметров должны быть такими-то, а по другим характеристикам - необходимо задать в ТЗ или не предъявлять требования.

Остапа понесло .

Идея заманчивая, однако, как показывает опыт, не всё, что есть в ТЗ, попадает в ТУ. Кроме того, в ТЗ бывает так, что изделие не в полной степени должно соответствовать группе, а лишь по отдельным показателям. В ГОСТ В 20.39 ряд требований по группе ссылается на ТЗ. Так что не всё так просто. Но основу документа создать можно.

Еще одна идея. Тут наши дотошные ОТК-шники посчитали, что для проверки разработанной нами аппаратуры нужно оформить 1150 протоколов испытаний, а до того испытания провести. А займут эти испытания по оптимистичным оценкам 3 месяца. Если же процесс испытаний автоматизировать, сроки можно сократить в несколько раз. Суть большинства проверок состоит в том, чтобы на стандартном генераторе задать определенные частоты и амплитуды сигналов, подать их на аппаратуру, а на выходе померить напряжение, после чего провести некоторые вычисления. Поскольку сегодня имеются программно-управляемые средства измерения, то можно на основе ПМИ сделать программу управления приборами с распечаткой результатов вычислений в виде протоколов. Такая управляющая программа может стать очень заманчивым приложением к ПМИ.

Если действовать в рамках ГОСТ 2, то весь процесс автоматизации займет два, отсилы три дня. Правда, не помню, есть ли ПМ в ГОСТ 2. А 20 ГОСТов у меня вообще не оказалось.

Имею смутное представление о XML и тем более, о XML-СУБД Sedna (при желании в этом можно и разобраться ), но есть следующая "тема". Одним из первых шагов разработки ТЗ является определение для разрабатываемого изделия группы по ГОСТ 20.39.304. После того как определена группа задаются требования в соответствии с серией ГОСТ 20.39.xxx. Как правило эти требования "задаются вручную", а если этот процесс автоматизировать? Если это получается, то дальше - больше, а почему не автоматизировать процесс разработки ПМИ, ТУ.
Постановка задачи не ахти какая , но для "начала", думаю пойдет.

Я правда не монстр, :oops: но... Даже не пытась нырять в глубину технологий разросшихся вокруг ХаМЛя, я попробую посмотреть со стороны. Ребята забацали нечто (ихнюю субд), но она, по большому счету, никому, кроме таких же академиков где-нибудь в штатах или Израиле, чтобы просто посмотреть и сравнить, нафиг не нужна.

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

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

Ну, собсно, понятно - теоретики полезли в практику... и поняли, что без конкретных знаний в области документооборота, их "конъюнкции" нафиг никому не облокотились - понадобился Алексей.

Автор письма - член программного комитета Четвертого весеннего коллоквиума молодых исследователей в области баз данных и информационных систем http://syrcodis.ispras.ru/2007/call_for_papers.ru.html

К РАН отношусь с уважением, и во время оно готов бы был поработать "за идею", из любви к науке, но ребята ведь явно затеяли коммерческий проект

давайте дождемся ответа на письмо Алексея.

Сдается мне, зреет очередная халтурка на тему "Как написать ТЗ и ТП за 2 недели"

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

Граждане вполне понимают, что хотят

Неподдающаяся осмыслению игра умных слов говорит о том, что не монимают, КАК
Далее конкретика:

Сдается мне, зреет очередная халтурка на тему "Как написать ТЗ и ТП за 2 недели"

Может это я идиот?

Я вот тоже - каждое слово по отдельности понимаю, а фразу целиком ну никак ниасилю

В статье, честно говоря, я разобрал только буквы - слова в осмысленные фразы не складывались. Такое очучение , что ребята дернули где-то буржуинскую статью, немного подправили и выложили.

Может это я идиот?

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

Граждане, похоже, сами особо не понимают, что они хотят - отсюда и своеобразный стиль изложения (о значении фразы "мы готовы делать сквозные решения, включающие в ... гибкие папйплайны публикациии полный round-triping используя ведущие XML и прочие редакторы" я могу только догадываться ) - человек явно не понимает о чем пишет.

Я понимаю так - граждане сделали пару-тройку успешных проектов и начали думать на тему расширения, а тут увидели знакомую аббревиатуру (XML) и ломанулись... Но, похоже, кто-то им рога пообломал и они решили проконсультироваться на тему "а что они вообще хотят"...

Предположения.
1) Разрабатывается (разработан ???) очередной программный продукт (на основе http://www.osp.ru/text/302/185085/) для автоматизации документооборота.
2) Предложит использовать данную технологию для развития сайта authorit.ru

Если честно, сам ничего не понял , кроме того, что фамилия - известная.

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