Рубрика «Промышленное программирование» - 19

в 8:19, , рубрики: C, hal, microcontrollers, stm32, stm32cube, программирование микроконтроллеров, Промышленное программирование

В свое время, более 5 лет, при поиске информации о 32-разрядных микроконтроллерах, обратил внимание, что практически все примеры для STM32 подразумевали использование SPL (Standard Peripherals Library). Цитата из Википедии:

STM32F10x Standard Peripherals Library (сокр. STM32F10x SPL) — библиотека, созданная компанией STMicroelectronics на языке Си для своих микроконтроллеров семейства STM32F10x. Содержит функции, структуры и макросы для облегчения работы с периферией микроконтроллера."

В настоящее время, для снижения порога вхождения и ускорения разработки предлагается использовать STM32CUBE. Цитата с сайта STM:

STM32Cube embedded software libraries, including:

The HAL hardware abstraction layer, enabling portability between different STM32 devices via standardized API calls.
The Low-Layer (LL) APIs, a light-weight, optimized, expert oriented set of APIs designed for both performance and runtime efficiency.
A collection of Middleware components, like RTOS, USB library, file system, TCP/IP stack, Touch sensing library or Graphic Library (depending on the MCU series)

На мой взгляд, для большинства проектов не нужны внешние библиотеки и проще использовать обращение к регистрам микроконтроллера, используя стандартную документацию.
Читать полностью »

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

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

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

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

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

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

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

в 13:59, , рубрики: arduino, csv файлы, python, tkinter, датчик движения, потенциометр, Промышленное программирование, разработка под windows

Постановка задачи

Цифровые и аналоговые датчики, подключенные к Arduino, генерируют большие объёмы информации, которая требует обработки в реальном масштабе времени [1].

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

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

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

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

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

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

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

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

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

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

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

Пролог

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

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

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

в 7:13, , рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, проектирование по, Промышленное программирование, разработка по, Тестирование IT-систем, тестирование по, управление проектами, формирование требований, функциональное программирование

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

Использование спецификаций требований в управлении проектом

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

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

Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »

в 10:50, , рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, Промышленное программирование, разработка программного обеспечения, Тестирование IT-систем, требования, управление проектами, формирование требований, функциональное программирование

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

Рекомендации по проектированию спецификаций требований с примерами

То, о чем не говорят, каждый понимает по-своему

Как и было анонсировано в предыдущих разделах, мы постараемся преобразовать требования на разработку ПО в такой формат, чтобы они максимально упростили и ускорили работу команды превращающую их в конечный продукт.

Готовим читателей к знакомству со спецификациями

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

Пример обзора документа:
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2 - 1

Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать полностью »

в 13:37, , рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, Промышленное программирование, разработка программного обеспечения, Тестирование IT-систем, требования, управление проектами, формирование требований, функциональное программирование

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

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

в 16:05, , рубрики: Блог компании Школа GoTo, машинное обучение, обучение программированию, онлайн-кинотеатры, открытые данные, Программирование, проектный подход, Промышленное программирование, рекомендательные системы, школа программирования, школьники

image

Еще одна статья от лица участника школы о проекте, реализованном в рамках очередной выезда:

«Я – Дмитрий Пасечнюк, и я хочу поделиться своим исследованием, сделанном на каникулах в рамках выездной весенней смены Школы GoTo под руководством Александра Петрова, asash, технического директора компании E-Contenta.

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

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

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

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

Обо всем по порядку под катом.
Читать полностью »

в 12:43, , рубрики: haskell, алгебра везде, Блог компании Школа GoTo, дети наше будущее, инновации, информационная безопасность, летняя школа, Программирование, Промышленное программирование, функциональное программирование, чёрная лямбда

Чёрная Лямбда ефрейтора Волкова: новое направление и гранты на летнюю школу - 1

Не далее чем в июле прошла очередная школа GoTo. В этот раз мы решили внести некоторое разнообразие в стандартный набор Ардуин, Питонов, и прочих, и случился Хаскелль. Небольшое отделение из 6 юношей (кусочек нашего общего взвода в 60 человек) бодро промаршивало по $lambda$-исчислению, основам синтаксиса, прошло посвящение в ФП написанием факториала, посворачивало списки, научилось словосочетанию "параметрически полиморфная функция высшего порядка" и присущему этому пониманию типов и тайпклассов под предводительством ефрейтора Волкова.

А ещё у нас были элементы инфобеза, криптовалюты, React Native, nix, и, конечно, git.

И мы начали писать книгу про Haskell.

В общем, получилось задорно.

(Под катом картинки участников, лямбды, илосос, анонс нового направления и гранты)

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

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