Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Мы разделяем шифр документа и название файла. Название файла имеет вид вроде такого
код. наименование документа (версия).doc
код. наименование документа (версия).doc
А шифр очень похож на ваш. И Шифр и название файла печатаются на каждом листе документа, так что найти электронную версию не составляет труда.
В структуре каталогов, как правило, предусмотрен ещё каталог для зафиксированных (утверждённых сторонами) версий, ну и специфические усложнения ещё. А так да, по этапам проекта тоже.
В структуре каталогов, как правило, предусмотрен ещё каталог для зафиксированных (утверждённых сторонами) версий, ну и специфические усложнения ещё. А так да, по этапам проекта тоже.
папки маздай, онтологии форева!
На примере таких случаев (если умными словами — когда нужно упорядочивать по многим дискретным параметрам) видно, насколько папки, допускающие только один уровень упорядочивания (собственно, вложенность, она ж простая композиция) неудобны.
На примере таких случаев (если умными словами — когда нужно упорядочивать по многим дискретным параметрам) видно, насколько папки, допускающие только один уровень упорядочивания (собственно, вложенность, она ж простая композиция) неудобны.
Точно! Как колбаса и велосипедная рама.
Я не пытался решить задачу организации информации. Речь о презентации формата и удобства его использования в рамках конкретного процесса. Файлы и папки в этом топике не более чем сущности, посредством которых представлен формат. Но за активность спасибо :)
Я не пытался решить задачу организации информации. Речь о презентации формата и удобства его использования в рамках конкретного процесса. Файлы и папки в этом топике не более чем сущности, посредством которых представлен формат. Но за активность спасибо :)
«Онтологии форева»… это что имеется ввиду? Я ради интереса решил освежить свои знания статейкой в википедии.
Не совсем понял как это будет выглядеть реализация на практике хранения кучи проектных документов (WinFS рулит?? Wiki подобная система с кучей тегов?) Или это было философское отступление, не все же про работу говорить?
Формально онтология определяется как O = <X,R,F>, где
* X — конечное множество понятий предметной области,
* R — конечное множество отношений между понятиями,
* F — конечное множество функций интерпретации.
Не совсем понял как это будет выглядеть реализация на практике хранения кучи проектных документов (WinFS рулит?? Wiki подобная система с кучей тегов?) Или это было философское отступление, не все же про работу говорить?
В русской википедии, как часто бывает, наплыв «умников», которым лишь бы свою крутизну показать, а насколько понятно непосвященному человеку — начхать…
Если наиболее кратко: онтология — это формальное описание предметной области. В чем польза? Вместо того, чтобы закидывать знания в некую запись (в данном примере — порядок неких кодовых символов и цифирок задают знания о версии и параметрах готовности проекта), которую, при автоматизации, нужно парсить и записывать в нужном формате — хранить сами знания. Тогда над этими формализованными знаниями можно организовывать полезные действия (интерпретации, если пользоваться «умными» словами). Например, анализ чего-нибудь-полезного в зависимости от фазы проекта в «линейной», предложенной автором топика, форме проводить уже не слишком удобно — нужно парсить строчку и только после этого с инфой работать.
WinFS умерла не родившись — ну и фиг с ней. Да, там были элементы системы знаний. Впрочем, зная логику и манеру ведения бизнеса M$ можно сказать, что была бы она предельно казуальной и кривоватой… например, поддерживала бы только «предустановленную» онтологию — что не то чтобы плохо, но и хорошего в том мало.
Вики к онтологиям вообще отношения не имеет — это система на основе гипертекста и обычного текстового поиска, весь смысл туда заносят люди.
Если наиболее кратко: онтология — это формальное описание предметной области. В чем польза? Вместо того, чтобы закидывать знания в некую запись (в данном примере — порядок неких кодовых символов и цифирок задают знания о версии и параметрах готовности проекта), которую, при автоматизации, нужно парсить и записывать в нужном формате — хранить сами знания. Тогда над этими формализованными знаниями можно организовывать полезные действия (интерпретации, если пользоваться «умными» словами). Например, анализ чего-нибудь-полезного в зависимости от фазы проекта в «линейной», предложенной автором топика, форме проводить уже не слишком удобно — нужно парсить строчку и только после этого с инфой работать.
WinFS умерла не родившись — ну и фиг с ней. Да, там были элементы системы знаний. Впрочем, зная логику и манеру ведения бизнеса M$ можно сказать, что была бы она предельно казуальной и кривоватой… например, поддерживала бы только «предустановленную» онтологию — что не то чтобы плохо, но и хорошего в том мало.
Вики к онтологиям вообще отношения не имеет — это система на основе гипертекста и обычного текстового поиска, весь смысл туда заносят люди.
Приведите, пожалуйста, практический пример, который можно реализовать и внедрить в компании? Хотя бы на уровне взаимодействия между сотрудниками одного отдела.
Я, конечно же, за светлое будущее. Но исключительно ради его практических плюсов, а не абстрактного блага.
Я, конечно же, за светлое будущее. Но исключительно ради его практических плюсов, а не абстрактного блага.
Если вы не против, на своем примере (думал недавно на досуге):
В большинстве провайдеров для учета звонков и составления тикетов используются самые обычные записи разговоров (впрочем, полезные во многих случаях, не только в технических вопросах) и текстовые блоки с пометкой приоритетов.
Предполагаемый профит от внедрения системы на основе знаний:
1. возможность _формально_ описать действия пользователей, операторов ТП, и вообще всех, кто имеет отношение к ситуации;
2. из (1) следует, что можно так же модернизировать ПО обмена сообщениями — заменив иногда довольно толстые и запутанные инструкции по заполнению тикетов (случай для примера: у провайдера есть программа размещения wi-fi точек у желающих, в том числе физ.лиц. В случае проблем на точке в тикет приходится включать массу инфы о контактах держателя и о самой точке — и это кроме инфы о проблеме абонента). Прямой профит от этого: сокращение действий операторов и большинства персонала по обработке тикетов, возможность напрямую связать действия с информацией из тикета (опять же пример, немного абстрактный — при обнаружении невыдачи IP проводятся некоторые рутинные действия — которые можно автоматизировать).
3. мелочь, а приятно — в ряде случаев, поверх собственно онтологии можно повесить экспертную систему. Это и подсказка ТП в сложных случаях, и возможность удаленной помощи абонентам (нет ведь ничего сложного создать облегченную версию базы знаний по самым частым случаям и раздавать их при подключении и просто желающим).
Я вообще поклонник идеи онтологий в «малых формах», наподобие системы тикетов или ежедневников — где внедрение интеллектуальных систем сдерживается не сложностью предметной области (хотя большая сложность скорее стимулирует использование онтологий — для примера можно поглядеть на современные САПР), а лишь отсутствием подходящих инструментов и небольшой известностью самой концепции.
В большинстве провайдеров для учета звонков и составления тикетов используются самые обычные записи разговоров (впрочем, полезные во многих случаях, не только в технических вопросах) и текстовые блоки с пометкой приоритетов.
Предполагаемый профит от внедрения системы на основе знаний:
1. возможность _формально_ описать действия пользователей, операторов ТП, и вообще всех, кто имеет отношение к ситуации;
2. из (1) следует, что можно так же модернизировать ПО обмена сообщениями — заменив иногда довольно толстые и запутанные инструкции по заполнению тикетов (случай для примера: у провайдера есть программа размещения wi-fi точек у желающих, в том числе физ.лиц. В случае проблем на точке в тикет приходится включать массу инфы о контактах держателя и о самой точке — и это кроме инфы о проблеме абонента). Прямой профит от этого: сокращение действий операторов и большинства персонала по обработке тикетов, возможность напрямую связать действия с информацией из тикета (опять же пример, немного абстрактный — при обнаружении невыдачи IP проводятся некоторые рутинные действия — которые можно автоматизировать).
3. мелочь, а приятно — в ряде случаев, поверх собственно онтологии можно повесить экспертную систему. Это и подсказка ТП в сложных случаях, и возможность удаленной помощи абонентам (нет ведь ничего сложного создать облегченную версию базы знаний по самым частым случаям и раздавать их при подключении и просто желающим).
Я вообще поклонник идеи онтологий в «малых формах», наподобие системы тикетов или ежедневников — где внедрение интеллектуальных систем сдерживается не сложностью предметной области (хотя большая сложность скорее стимулирует использование онтологий — для примера можно поглядеть на современные САПР), а лишь отсутствием подходящих инструментов и небольшой известностью самой концепции.
к слову, про практические плюсы: внедрение онтологий (или семантической информации или еще как — синонимов нынче много) предполагает кумулятивный рост способов применения. То есть первоначально отдача будет незначительной, однако с распространением подхода будет происходить взрывной рост «пользы» от внедрения — за счет той самой эмерджентности, которая «свойство системы». Вспоминается пример из курса: сейчас для того, чтобы сходить с девушкой в кино и кафешку нужно самому выбрать подходящий фильм (пересмотреть кучу рецензий), найти подходящую кафешку (найти подходящие меню и цены), да потом еще все это как-то согласовать на местности и во времени. С интеллектуальным поиском можно будет просто высказать текущие пожелания («легкую комедию» и «рыбное меню с подходящим вином»), а остальное найдет система.
Присоединяюсь. Честно говоря не разу не встречал какую либо практическую реализацию вышеописанного алгоритма. Насколько я понял основная проблема это описание предметной области, что скорее всего является мягко говоря нетривиальной задачей.
У нас хранение документов осуществляется примерно так же, как описано в статье. Но с гораздо меньшей детализацией, здесь есть реально полезные мысли, за что особая благодарность автору.
В свое время активно экспериментировали с wiki Confluence. Было описание проекта в wiki формате, к нему прикладывались файлы проекта через webdav. Активно использовалось тегирование для описание самого проекта.
У нас хранение документов осуществляется примерно так же, как описано в статье. Но с гораздо меньшей детализацией, здесь есть реально полезные мысли, за что особая благодарность автору.
В свое время активно экспериментировали с wiki Confluence. Было описание проекта в wiki формате, к нему прикладывались файлы проекта через webdav. Активно использовалось тегирование для описание самого проекта.
не, описание предметной области, в 90% случаев, не представляет большой проблемы. Более того, удачная онтология во многом повторяет термины, используемые людьми для работы в предметной области. То есть если ты знаешь свою работу — значит ты знаешь ее онтологию.
Сейчас сложностей вижу 3:
1. нет правильных инструментальных средств для внедрения онтологий в проекты. Есть замечательные «обычные» IDE, есть неплохие редакторы онтологий — но нет инструментов, которые бы объединяли их качества;
2. нет хороших метамоделей (они ж онтологии верхнего уровня — наиболее абстрактные модели, на основе которых можно строить более детальные прикладные онтологии) — идеи классов и объектов, в свое время, совершили неплохую революцию, но сейчас, ИМХО, это все более превращается в балласт (не верите? Тогда скажите, в скольки проектах вам приходилось использовать все диаграммы UML 2.0)
3. самое главное — пока мало людей, которые понимали бы неизбежность этого пути. То есть вот так вот фатально — нету больше альтернатив, а которые есть — все так или иначе сводятся к онтологиям. В свое время, ООП сделали психологи. Сейчас концепцию программирования сделают философы.
Сейчас сложностей вижу 3:
1. нет правильных инструментальных средств для внедрения онтологий в проекты. Есть замечательные «обычные» IDE, есть неплохие редакторы онтологий — но нет инструментов, которые бы объединяли их качества;
2. нет хороших метамоделей (они ж онтологии верхнего уровня — наиболее абстрактные модели, на основе которых можно строить более детальные прикладные онтологии) — идеи классов и объектов, в свое время, совершили неплохую революцию, но сейчас, ИМХО, это все более превращается в балласт (не верите? Тогда скажите, в скольки проектах вам приходилось использовать все диаграммы UML 2.0)
3. самое главное — пока мало людей, которые понимали бы неизбежность этого пути. То есть вот так вот фатально — нету больше альтернатив, а которые есть — все так или иначе сводятся к онтологиям. В свое время, ООП сделали психологи. Сейчас концепцию программирования сделают философы.
Спасибо за развернутое описание. Вот Вы и ответили на вопрос «почему нет».
Понимаете, внедрять нужно то, что гарантированно будет работать и помогать. Причем стоимость владения таким решением должна должна быть как минимум не больше того, что я привел в посте. Ну или плюсы должны очень сильно перевешивать. Поэтому «онтологии форева!», но «папки пока не маздай» :)
Понимаете, внедрять нужно то, что гарантированно будет работать и помогать. Причем стоимость владения таким решением должна должна быть как минимум не больше того, что я привел в посте. Ну или плюсы должны очень сильно перевешивать. Поэтому «онтологии форева!», но «папки пока не маздай» :)
Всегда пожалуйста.
Сейчас я, в общем, и не преследую цели «пересадить» всех на онтологии и интеллектуальное ПО. Скорее есть потребность создать некий «информационный шум», рекламу технологии — чтобы когда инструментальные средства появились (а это произойдет весьма скоро — базовые технологии уже есть, ПО из смежных областей так же появляются, так что дело за командой, которая сможет это реализовать и широко заявить об успехе) — достаточное количество разработчиков уже было в курсе, что есть такая штука и как ей можно воспользоваться.
Еще раз подчеркну — новый подход будет развиваться по-взрывному. В отличие от ООП, который развивался сравнительно равномерно, в онтологиях возможно широкое использование предыдущего опыта и наработок.
Сейчас я, в общем, и не преследую цели «пересадить» всех на онтологии и интеллектуальное ПО. Скорее есть потребность создать некий «информационный шум», рекламу технологии — чтобы когда инструментальные средства появились (а это произойдет весьма скоро — базовые технологии уже есть, ПО из смежных областей так же появляются, так что дело за командой, которая сможет это реализовать и широко заявить об успехе) — достаточное количество разработчиков уже было в курсе, что есть такая штука и как ей можно воспользоваться.
Еще раз подчеркну — новый подход будет развиваться по-взрывному. В отличие от ООП, который развивался сравнительно равномерно, в онтологиях возможно широкое использование предыдущего опыта и наработок.
Мажорная версия
Отвечает на вопрос: сколько раз документ был направлен на утверждение заказчику.
А вот это очень интересно. У нас несколько иная схема: Мажор-Минор-Билд. Но Ваша идея инкрементирования мажора очень интересна. Спасибо!
Отвечает на вопрос: сколько раз документ был направлен на утверждение заказчику.
А вот это очень интересно. У нас несколько иная схема: Мажор-Минор-Билд. Но Ваша идея инкрементирования мажора очень интересна. Спасибо!
А мы еще дату добавляли в конце, причем дата в обратном порядке (ГГ ММ ДД), для того что бы при сортировке хронология сохранялась. Или же наоборот дату в начало, если в паке документы одного типа, но с разными названиями.
Что сильно напоминает ГОСТ, тока там названия сущностей другие.
Если с рос. заказчиками работать, то как тогда лучше сделать?
По-мойму если в момент Presale выслать документ с таким шифром, но русским, то впечатление будет солидное.
Если с рос. заказчиками работать, то как тогда лучше сделать?
По-мойму если в момент Presale выслать документ с таким шифром, но русским, то впечатление будет солидное.
Извините, дурацкий вопрос: а что такое Useful Club?
Ограниченная, запутанная система классификации документов. Я бы даже добавил — вредная.
Может я конечно ошибаюсь, но очень бы хотелось увидеть скриншот папки, где такие документы лежат.
Может я конечно ошибаюсь, но очень бы хотелось увидеть скриншот папки, где такие документы лежат.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Способ организации проектных директорий и файлов