основная часть - процесс выбора и отброшенных решений. множество людей предлагаю то же решение пытались делать типа decision tree, но оно становится очень длинным, очень быстро проект может иметь штук 10 коренных изменений, меняющих все детали. и читать все эти 10 историй разных решений - весьма утомительно нужно какое-то разделение между актуальным и не актуальным
Комментарии: 19
Anonim
вот на примере dcdc: у группы есть базовый набор данных по объекту исследования, например даташит похожего девайса. В задачи группы входит разработка прототипа преобразователя на дип компонентах. Результат ожидаемо будет хуже того, что есть в оригинале, но ты знаешь заранее это и цель получить опыт разработки в группе. Не уменьшение цены, не уменьшение размеров, а именно процессы.
Anonim
истории решений? вам нужен результат как говорят некоторые программисты - меня устроит понятное API, а что там внутри пофигу
Defragmented
это если команда уже собрана. это не так. если команда так же собирается в процессе - нужно передавать что уже было проверено
Anonim
а отдельному члену группы зачем нужны исходники вычислений плавучести атомов цезия на поверхности юпитера, если он работает с озеленением палубы? для этого достаточно нарисовать человеку квадратик с надписью исходник вычисления плавучести бла бла бла
Defragmented
разделение инфы о проекте по темам - интересная идея
Anonim
у меня пирамидки и прямые граверы по металлу, а едет двухзаходный спиральный гравер 0.15мм диаметр острия, 30° тут проблема будет одна, если ты оставишь только деление по темам. нужно будет по запчастям или по материалам искать - а структуры такой нет и начнется лютый поиск с перебором всех тем. Следовательно, нужна бд с динамической структурой
Andrey
Где такие купить?
Defragmented
наполнение многоключевого поиска на порядок усложнит заполнение бд желательно чтобы кто-то мог ее читать и писать кроме меня
Anonim
https://cncbit.ru/search/?query=%D0%93%D1%80%D0%B0%D0%B2%D0%B5%D1%80+%D0%BA%D0%BE%D0%BD%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B9+%D1%81%D0%BF%D0%B8%D1%80%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9+%D0%B4%D0%B2%D1%83%D1%85%D0%B7%D0%B0%D1%85%D0%BE%D0%B4%D0%BD%D1%8B%D0%B9+CNCBIT.RU-SVP-3-30-01 кроме многоключевого поиска будет еще проблема многоключевого отображения да хотя бы по одному ключу
Defragmented
если так со мной готовы работать ~10 человек, то с многоключевой бд - уже около 0.5 )
Anonim
обобщай и представляй в виде графа. внутри каждого блока свой граф верхний уровень должен быть понятен всем и иметь вид того, с чем все 10 могут работать. древовидная структура? ок, а внутри каждой директории перекрестные ссылки на связанные категории
Defragmented
т.е. файлы и папки, древовидная структура и многоключевые бд внутри тем
Anonim
ну тебе все равно будет сложно визуализировать сразу все варианты отображения
Defragmented
бд как файл простые данные = папки + файлы сложные данные = бд (файл) со сложнвм поиском внутри
Anonim
не, я имею в виду, что бд одна, но внутри папки есть грубо говоря, отдельная область с ключами из этой же бд, относящаяся к этой теме база получится связанной и динамической
Defragmented
окей. файлы + папки + доступ к общей бд как файл, который указывает что доставать из бд в этом случае
Anonim
ну что-то типа того в директории с темой будут файлы чертежей, описаниями процесса сборки и "ярлыки" на связанные с этой темой материалами, инструментами и т. д. То есть ярлыки навалом вне дерева, а данные по теме - древовидно. Ибо если все начинать упорядочивать в один вид - потеряется цель
Andrey
А плоскими коническими нет?
Anonim
это как пирамидка?