Рубрика «Анализ и проектирование систем» - 86

в 15:33, , рубрики: GUI, Ideal OS, MacOS, OS X, UX, Анализ и проектирование систем, Графические оболочки, Идеальная ОС, командная строка, Программирование, системное программирование, Совершенный код

TL;DR: К концу этого эссе я надеюсь убедить вас в следующих фактах. Во-первых, что современные десктопные операционные системы никуда не годятся. Они раздутые, тормознутые и напичканы легаси-хламом, а кое-как работают только благодаря закону Мура. Во-вторых, что инновации в десктопных ОС прекратились около 15 лет назад, а основные игроки вряд ли собираются много вкладывать в них снова. И наконец, я надеюсь убедить вас, что мы можем и должны начать с нуля, усвоив уроки прошлого.

«Современные» десктопные ОС раздуты

Возьмём Raspberry Pi. За 35 долларов я могу купить отличный компьютер с четырьмя процессорными ядрами, каждое на частоте более гигагерца. У него также есть 3D-ускоритель, гагабайт оперативки, встроенные WiFi с Bluetooth и Ethernet. За 35 баксов! И всё-таки для многих задач, которые я хочу на нём запустить, Raspberry Pi ничем не лучше компьютера на 66 мегагерц, который был у меня в колледже.

Идеальная ОС: переосмысление операционных систем для десктопа - 1
Читать полностью »

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

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

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

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

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

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

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

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

в 9:31, , рубрики: C, IP, IT-стандарты, networking, p2p-сети, stun, Анализ и проектирование систем, Блог компании Emercoin, Программирование

Как узнать свой внешний IP из программы - 1

При написании различных программ для работы с сетью, особенно p2p систем, время от времени возникает необходимость узнать внешний IP своего компьютера из программы (тот адрес, по которому Ваш компьютер доступен из Большого Интернета). Часто возникает искушение пойти легким путем и использовать внешние WEB-сервисы, которые по http возвращают Вам IP, или самому развернуть таковой. Хотя такой способ решения задачи и работоспособен, он тем не менее, имеет ряд недостатков:

  • При использовании собственного сервера – нужно где-то его держать и поддерживать, заодно и c соответствующим доменным именем. В случае выхода его из строя, или принудительного отзыва домена, вся Ваша p2p сеть выходит из строя.
  • При использовании внешнего сервера – Вы вводите зависимость своей системы как от его работоспособности, так и от формата ответов, который вообще никак не стандартизирован, и который владелец сервера может поменять в любой момент. С теми же последствиями для вашей сети.
  • http, которым советуют пользоваться – базируется на tcp, то есть протокол сравнительно тяжеловесный, требующий установки соединения и тп. В общем, пользоваться можно, но перерасход ресурса как компьютера, так и сети налицо.

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

в 6:25, , рубрики: IT-стандарты, xbrl, Анализ и проектирование систем, отчетность, стандарты, финансы, цб рф

6.6. Многомерность

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

Это приведет к изменениям во всех частях таксономии – в основном, к отбрасыванию элементов, которые больше не нужны, и замене нескольких элементов на один комбинированный:

  • Базовые концепты
    Теперь нам не нужно различать два измерения, поэтому мы можем избавиться от концептов nr_employees_by_age и nr_employees_by_gender.
  • Таксономия измерений
    Поскольку мы можем использовать элемент gender для обозначения “всех гендерных групп”, аналогично добавим элемент all в тип age_group_type.Читать полностью »

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

Пролог

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

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

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

в 9:05, , рубрики: mongodb, nosql, Анализ и проектирование систем, базы данных, Проектирование и рефакторинг

image Приветствую бойцов невидимого бэкенда!

Вы уже почитали обзоры MongoDB. Вероятно, прошли отличные онлайн-курсы на university.mongodb.com. Конечно, у вас уже есть многообещающий проект-прототип с использованием MongoDB.

Что мы можем ждать от MongoDB на этом этапе?

  • Удешевление хранилища — чтение с ведомых реплик экономит iops мастера, не требуется RAID, отказ одного диска не фатален.
  • Повышаем скорость разработки — можно допустить бОльшую небрежность в проектировании структур данных, т.к. мы вполне можем все исправлять на работающем приложении.
  • Повышаем отзывчивость приложения — независимо от разработки, легко увеличить число ведущих реплик или количество шардов, чтобы компенсировать возросшую нагрузку на приложение.
  • Повышаем надежность приложения — независимо от разработки, убираем единую точку отказа.

И вот, вы готовы ввязаться в бой — выпустить проект на публику.

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

в 21:05, , рубрики: ansi c, C, event loop, event-driven, event-driven programming, javascript, libuv, node.js, nodejs, Анализ и проектирование систем, Программирование, системное программирование

image
Юдель Пэн. Часовщик. 1924

«Компьютер — это конечный автомат. Потоковое программирование нужно тем, кто не умеет программировать конечные автоматы» 
Алан Кокс, прим. Википедия

“Знай свой инструмент” — твердят все вокруг и все равно доверяют. Доверяют модулю, доверяют фреймворку, доверяют чужому примеру.

Излюбленный вопрос на собеседованиях по Node.js — это устройство Event Loop. И при всем том, очевидном факте, что прикладному разработчику эти знания будут полезны, мало кто пытается самостоятельно погрузиться в устройство событийного цикла. В основном, всех устраивает картинка сверху. Хоть это и похоже на пересказ фильма, который ты не смотрел, а о котором тебе рассказал друг.
Читать полностью »

в 7:23, , рубрики: 1С, 1С-Битрикс, Анализ и проектирование систем, базы данных, Блог компании 1С, отчетность, Проектирование и рефакторинг, проектирование систем, разработка приложений

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

В платформе «1С:Предприятие» за построение отчётов отвечает механизм под названием «Система компоновки данных» (сокращенно СКД). В этой статье мы постараемся дать краткое описание идеи и архитектуры механизма СКД и его возможностей.
image
Читать полностью »

в 17:39, , рубрики: IT-стандарты, Анализ и проектирование систем, бизнес-модель, математика, моделирование предметной области, Семантика

Правильно заданный вопрос быстро приводит к правильному ответу. Недавно меня спросили: «Почему стандарты бизнес-анализа сконцентрированы на выявлении требований, но ничего не говорят о превращении этих требований в решение?» В самом начале своей карьеры аналитика я искал ответ на вопрос: как анализировать предметную область и как превращать результат анализа в структуру модели: откуда брать классы, атрибуты и методы? Тогда я нашел один более-менее вразумительный метод, описанный в книге Крега Лармана Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку. Аналитику предлагалось прохождение по тексту с маркерами разных цветов: Красный выделяет существительные и является основанием для создания классов, зеленый — прилагательные, причастия и проч. — основа для создания атрибутов этих классов. И глаголы выделяются синим — основа для создания методов.

Однако, в реальности этот метод не работал. Один и тот же факт я мог смоделировать при помощи класса, значения атрибута или метода в зависимости от своего желания. Об этом написано подробно у Крисса Партриджа в книге Business Objects: Re-Engineering for Re-Use.
Читать полностью »

в 9:06, , рубрики: IT-стандарты, xbrl, Анализ и проектирование систем, отчетность, стандарты, финансы, цб рф

6.4. Как облегчить жизнь

До сих пор мы использовали только простые item-концепты. Каждый из nr_employees-концептов мог быть интерпретирован независимо от остальных.

У такого подхода есть недостаток: если количество полов обычно ограничивается двумя, то для возраста мы могли бы иметь большее количество групп, чем три в нашем примере. Что, если бы нам понадобилось разделить возраста на 10-летние интервалы? Пришлось бы добавить новые концепты для групп 11–20, 21–30, 31–40, 41–50, 51–60 и 61–70. А при делении на 5-летние, 2-летние или даже годовые интервалы это очень быстро станет утомлять. Базы ссылок стали бы очень большими, поскольку надо было бы определять ссылки для каждого из этого множества концептов. Хотелось бы иметь более эффективный подход для подобных ситуаций.

И сегодня мы расскажем, как нам в этом могут помочь кортежи.Читать полностью »

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