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

в 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, , рубрики: Анализ и проектирование систем, визуализация данных, менеджмент проектов, Программирование, проектирование, Проектирование и рефакторинг, Промышленное программирование, требования, управление проектами, формирование требований

Пролог

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

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

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

в 6:48, , рубрики: металлообработка, проектирование

Раздвигая границы проектирования с аддитивным производством из металла...

Авторы: Terry Wohlers и Ian Campbell
11 марта 2016 г.

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

Дополнительная прибавочная стоимость может быть получена благодаря сокращению стоимости жизненного цикла, улучшению эстетической привлекательности продукта, улучшению удобопользования и повышению эффективности*. Впечатляющий пример повышения эффективности с применением технологии послойного сплавления порошка алюминия: автомобильная головка блока цилиндров аддитивно произведённая немецкой компанией FIT (Рис. 1) Головки блоков цилиндров ДВС должны обеспечивать минимизацию трения, для оптимизации входящих и исходящих потоков газов, движения охлаждающей жидкости и гашения вибрации. А будучи высоконагруженными элементами при всём перечисленном должны иметь высокую прочность.

FIT было поручено разработать улучшенную версию ГБЦ гоночного автомобиля, которая отвечала бы требованиям к эффективности, и имела бы меньший вес. Дальнейший текст иллюстрирует, как проектирование для АТ максимизирует геометрическую свободу, и повышает эффективность создаваемых деталей.

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

в 7:31, , рубрики: css, DRY, html, javascript, React, ReactJS, solid, web, архитектура приложений, Блог компании ДоксВижн, компоненты, проектирование, Разработка веб-сайтов

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

Эта статья во многом вдохновлена докладом Павла Силина на РИТ 2017, однако здесь много моего собственного опыта и размышлений. Примеры будут на React + TypeScript, однако подход не привязан к какой-либо технологии.

Заменяй и властвуй — подход SOLID для разработки повторно используемых компонентов в вебе - 1Читать полностью »

в 10:33, , рубрики: css, IT-стандарты, less, sass, архитектура, переменные, проектирование, Проектирование и рефакторинг, Разработка веб-сайтов, Совершенный код, фронтенд

Правила управления переменными в препроцессорах и методика переопределения настроек

История архитектурной ошибки, её последствия, и три правила, благодаря которым вы сможете держать исходный код в порядке и снизить стоимость внесения изменений.

Предыстория

В 2014 году в компании начали редизайн проекта и в основу вёрстки мы положили свежий на тот момент Bootstrap 3.0.1. Использовали мы его не как отдельную стороннюю библиотеку, а тесно заинтегрировали с нашим собственным кодом: отредактировали переменные под наш дизайн и компилировали кастомизированный Бутстрап из LESS исходников самостоятельно. Проект оброс собственными модулями, которые использовали бутстраповские переменные и добавляли в файл с настройками свои новые переменные.

В тот момент я думал, что это правильный подход.

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

в 5:50, , рубрики: Блог компании ГК ЛАНИТ, инженерные работы, Ланит, освещение, проектирование, системная интеграция, уличное освещение, метки:

Несколько месяцев мы занимались тем, что меняли внешний вид ночного Биробиджана. "ЛАНИТ-ПАРТНЕР" в рамках реализации энергосервисного контракта установил 2200 современных светодиодных светильников разных моделей, заменив устаревшие энергонеэффективные лампы на улицах центрального города Еврейской автономной области. Теперь Шолом-Алейхем сможет «читать» в любое время суток.

Биробиджан на светлой стороне: как мы за свои деньги город осветили - 1
Памятник писателю Шолом-Алейхему (Соломону Наумовичу Рабиновичу) в Биробиджане.
Источник
 Читать полностью »

в 8:21, , рубрики: веб-дизайн, графический дизайн, дизайн, дизайн мобильных приложений, интерфейсы, карьера, нетворкинг, проектирование, прототипирование

Без правок. Как стать самым счастливым дизайнером на планете - 1

Три месяца назад я проектировал корпоративный сайт. Имея хороший опыт, я подошел к задаче серьезно: провел аудит отрасли, определил цели бизнеса, описал задачи пользователей и на основе всего этого создал приятный и удобный интерфейс. Но, несмотря на все старания, мой дизайн был отвергнут. Я получил длинный список правок, расстроился и, чтобы не написать чего лишнего, закрыл ноутбук и отправился на улицу.

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

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