Рубрика «проектирование» - 12

в 15:19, , рубрики: php, postgresql, sql, Анализ и проектирование систем, велосипедостроение, КодоБред, проектирование

Введение

На очередном собеседовании меня спросили о недостатках модели данных EAV (Entity Attribute Value), я не нашёл что сказать, на мой взгляд это идеальный способ хранения произвольных данных. После короткого раздумья, я сказал что единственная проблема это невозможность построить индексы для выборок.
После собеседования я озадачился этим вопросом на несколько дней, пришёл к каким то выводам, для очистки совести чуть чуть погуглил. Нагуглил подтверждения своим мыслям, но этого мне было мало — захотелось реализации с подтверждением цифрами.
Если и вам интересно к каким выводам я пришёл и какой выигрыш от оптимизации можно получить, то добро пожаловать под кат.
Читать полностью »

в 9:29, , рубрики: 3d, AR, AR и VR, VR, Блог компании Top 3D Shop, будущее здесь, проектирование

[КЕЙС] Применение Microsoft Hololens компанией НЕОЛАНТ - 1

Здравствуйте! Сегодня мы рассказываем о применении дополненной реальности в промышленности, на примере использования Microsoft Hololens компанией НЕОЛАНТ.

Читать полностью »

в 16:04, , рубрики: .net, api, C#, CAD/CAM, multicad, nanoCAD, Программирование, проектирование, строительство

На мой взгляд один из лучших способов научится чему-то это поделится знаниями с другими людьми.

В этот раз мне понадобилось понять, как создаются пользовательские объекты в NanoCAD с помощью MultiCAD.NET API. В блоге компании Нанософт есть статья от 2013 года, в которой объясняются базовые вопросы создания пользовательских примитивов. Но согласитесь было бы не интересно, просто воспроизвести эту статью, поэтому мы ее немного дополним.

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

Под понятием «псевдо-3D» в данном случае я имею ввиду, что наши объекты не будут обладать свойствами модели твёрдого тела, то есть это будет просто набор связанных геометрических примитивов в трёхмерной системе координат. Может это не совсем корректный термин, но я пока лучше ничего не подобрал.

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

Так или иначе если вы интересуетесь: проектированием, САПР, NanoCAD, разработкой под .NET и в частности на C#, а также овцами и Улицей Сезам, то возможно эта статья как раз для вас.

Вам тоже интересно причем тут овцы и Улица Сезам? Тогда милости прошу под кат.

«Как баран на новые ворота» или пользовательские «псевдо-3D» объекты в NanoCAD с помощью MultiCAD.NET API - 1
Читать полностью »

в 9:52, , рубрики: diy или сделай сам, деревообработка, изготовление, проектирование, станок, шлифование, Электроника для начинающих

Введение

Горизонтально-шлифовальный станок - 1

В данной статье описывается процесс конструирования и создания горизонтально-шлифовального станка по дереву. Акцент в изложении материала ставится на особенностях изготовлении и воплощении в материале подобных изделий в рамках хоббийной мастерской.

Предыстория. Одно время я занимался изготовлением традиционных луков. Для получения требуемой силы натяжения и обеспечения качества склейки требовалось точно калибровать узкие и длинные полоски шпона твердых пород дерева. Узкоспециализированного станка для подобных задач у меня не было, обходился приспособлениями и услугами сторонних лиц.

Приступая к работе я ставил перед собой следующие цели и задачи: создать функциональное, удобное, надежное, ремонтнопригодное, компактное, эстетичное изделие, способное выполнять предназначенные для него задачи.

Круг задач был очерчен следующим образом: иметь возможность получить прошлифованную поверхность с допуском по толщине в 0,1 мм на всей длине и ширине заготовки.Читать полностью »

в 5:29, , рубрики: pcb design, pcb production, Анализ и проектирование систем, Блог компании YADRO, печатные платы, проектирование

Пока мы заканчиваем последние приготовления к серийному выпуску сервера VESNIN, хочу провести образовательный эксперимент — опишу наши внутренние методики и рекомендации для расчёта стека печатных плат. С одной стороны, приятно, если наш опыт будет кому-то полезен. С другой, мы сами рады получить дельные комментарии, чтобы улучшить нашу практику. Если интересно прочитать и обсудить — добро пожаловать под кат.
Наша методика расчета стека печатных плат - 1

Читать полностью »

в 5:02, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент продукта, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, требования, управление проектами, формирование требований

С частью 4 можно ознакомиться, перейдя по ссылке

VIII Определяем сущности предметной области

Все, что видим мы, — видимость только одна.
Далеко от поверхности мира до дна.
Полагай несущественным явное в мире,
Ибо тайная сущность вещей — не видна
Омар Хайям

Практика формирования требований в ИТ проектах от А до Я. Часть 5. Сущности предметной области. Немного о стратегиях - 1
Определив абстрактные хранилища продукта, мы получаем костяк для построения детальной модели данных. При проектировании структуры сущностей продукта, удобно использовать канонические диаграммы «Сущность-связь» (ERD), логическую диаграмму (Logic Diagram) или диаграмму классов (Class diagram).

Цель этой группы работ — спроектировать модель хранилищ данных для использования в продукте, а также задокументировать сущности системы и способы их взаимодействия.

Теория проектирования такого типа диаграмм детально изложена в литературе, описывающей работу с UML. Например, эта тема очень удачно представлена в [11]. Поэтому остановлюсь лишь на некоторых аспектах, интересных на мой взгляд,.
Читать полностью »

в 11:59, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент продукта, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, требования, управление проектами, формирование требований

С частью 2 можно ознакомиться, перейдя по ссылке

VI ОПРЕДЕЛЯЕМ ФУНКЦИИ СИСТЕМЫ И ГРАНИЦЫ ПРОЕКТА

Каждая модель ограничена в своих ответах, но нет ограничения на то, как и что моделирует модель, как нет ограничения на человеческую мысль
Дуглас Т. Росс

Практика формирования требований в ИТ проектах от А до Я. Часть 3. Функции системы и Границы проекта - 1

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

Цель данной группы работ: максимально полно определить набор функций, который должен выполнять целевой продукт, для удовлетворения выявленных потребностей заказчика. Отобрать те из них, которые, могут быть реализованы в рамках текущего проекта.

Границы проекта (project scope) показывают, какая область конечного продукта будет реализована в текущем проекте. Другими словами, определяется черта между тем, что мы будем делать сейчас и тем, что отложим на потом или от чего вообще сможем отказаться. Для этого в арсенале команды должен быть инструмент, позволяющий не просто строить модели создаваемого продукта, а помогающий наглядно очертить рамки автоматизируемых процессов, а также предоставлять возможность легко выносить процессы за границу или включать их обратно. Это очень важно для осознания и более качественного планирования объемов работ. Подобный инструмент полезен не только для «борьбы» с непомерными желаниями заказчика, но и для маневров менеджмента со стороны разработчиков.
Читать полностью »

в 14:12, , рубрики: bim, данные, информационное моделирование, Исследования и прогнозы в IT, проектирование, Читальный зал

Здесь представлены некоторые рассуждения посвященные теме перехода от документоориентированного подхода в проектировании (далее ДКО) к датаориентированному (далее ДО). Рассмотрены основные особенности и преимущества ДО подхода в сравнении с ДКО подходом на примере выполнения наиболее распространённых бизнес-процессов в проектной деятельности.

Введение

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

Такой подход ранее был единственно возможным. В сегодняшней же действительности во многих сферах жизнедеятельности мы наблюдаем трансформацию и переход от ДКО парадигме к ДО. И это одно из основных направлений в программе “цифровая экономика”, реализация которой определят будущее нашего государства. В частности ДО подход лежит в основе всех современных технологий определяющих так называемую четвертую промышленную революцию.

В проектной же деятельности весь обмен информацией все еще полностью основан на обмене документами.

С другой стороны мы наблюдаем достаточно сильный интерес к технологии информационного моделирования (BIM). И хотя реализация данной технологии отличается на уровне различных государств, отраслей и отдельных компаний, основные принципы остаются общими. Среди них можно выделить использование 3D моделей и общей среды данных.

Но возможна ли реализация технологии BIM в документоориентированном мире?
Читать полностью »

в 6:05, , рубрики: бизнес-модели, менеджмент проектов, проектирование, требования, Управление продуктом, управление проектами, управление разработкой, формирование требований

С частью 1 можно ознакомиться, перейдя по ссылке

IV ОПРЕДЕЛЯЕМ ЦЕЛИ, ПРОЕКТА

Цель не обязательно должна достигаться. Порой это просто направление двигаться дальше.
Брюс Ли.

Практика формирования требований в ИТ проектах от А до Я. Часть 2. Цели и Потребности - 1

Одним из основных признаков системы, отличающим ее от разрозненных компонентов, является подчиненность всей организации системы — некоторой цели. Проектная работа команды, представляет собой тоже некую систему и соответственно должна «идти на поводу» у какой-то цели. Потому, установив коммуникации между участниками проекта, начнем определять цели, которые мы хотим достичь в результате создания нового продукта.

Цель данной группы работ: определить основные задачи, которые ставят перед собой группы заинтересованных лиц, участвующих в проекте.
Читать полностью »

в 13:24, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент проектов, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, требования, управление проектами, формирование требований

Пролог

Читая на этой площадке статьи по управлению проектами, часто ощущается рвущаяся наружу боль менеджеров, вызванная неэффективным использованием ресурсов в проекте. А одной из основных причин этих проблем чаще всего называется именно отсутствие качественных заданий на разработку продукта. Проявляться эта беда может в разных симптомах: в виде трудностей с делегированием абстрактных расплывчатых заданий, или взаимного непонимания на совещаниях по решениям, которые имеются только у каждого в голове, при этом представляются они абсолютно по разному и т.п. Читая об этом в сознании живо проносятся картинки из своей собственной практики. И вот Вы уже напряжены и пытаетесь быстрее перейти от симптомов к рецептам избавления от этой головной боли. И что же мы чаще всего можем увидеть? А дальше, как правило, идут оптимистические и решительные, лозунги — готовьте правильно задачи исполнителям, не надейтесь, что они быстро сами во всем разберутся, до всего догадаются или им внезапно придет озарение. Подождите! А как это сделать? Авторы, подняв проблему, почему-то поиски ее решения оставляют для самостоятельной работы читателя. А ведь это самое интересное и сложное.

В своей статье «О качестве требований в ИТ проектах, начистоту (с позиции команды разработки)», я попытался более конкретно подойти к решению этих проблем и рассказал на своем опыте, как можно преобразовать собранные требования для автоматизации в ИТ проекте так, чтобы максимально повысить результативность команды, воплощающую их в целевой продукт. Повысить именно за счет качественно сформулированных заданий на разработку продукта, покрывающую весь процесс.

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

1...111213...2030...33
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js