Інженерія програмного забезпечення

Ми виходимо з того, що ваша команда може супроводжувати й під що може наймати людей, що використовують інші ваші системи і що має робити програмне забезпечення. Для більшості бізнес-систем це поширена мова, як-от TypeScript, Java, C# або Python, реляційна база даних і хмара, яку ви вже використовуєте. Ми фіксуємо кожен вибір та його причини.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Так. Ми проєктуємо ізоляцію орендарів, конфігурацію для кожного орендаря, ролі, хуки білінгу й журнали аудиту з першого релізу, бо додавання їх пізніше означає переписування моделі даних. Ми узгоджуємо з вами, чи орендарі спільно використовують базу даних, схему чи нічого, виходячи з ваших потреб у безпеці й витратах.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Ваша платформа будується із самодостатніх бізнес-компетенцій з власними API, як-от ціноутворення, онбординг чи білінг. Кожну можна змінити, масштабувати чи замінити, не торкаючись решти, а нові продукти можуть їх повторно використовувати. Це підходить платформам, що зростатимуть роками; невеликому інструменту це не потрібно.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Для більшості нових застосунків ми використовуємо React з Next.js, бо він підтримує серверний рендеринг і має сильні інструменти. Ми також працюємо з Angular і Vue.js і продовжуємо у фреймворку, який ви вже використовуєте, коли це розумний вибір.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Обирайте настільний застосунок, коли робота потребує офлайн-режиму, прямого доступу до пристроїв чи локальних файлів, великих обсягів даних чи графіки або швидких екранів із керуванням із клавіатури. Для більшості інших потреб вебзастосунок простіше розгортати й оновлювати. Ми радимо в кожному випадку окремо, і іноді правильною відповіддю є вебзастосунок із невеликим настільним компонентом.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Нативні застосунки дають найкращу швидкодію й найкраще підходять для кожної операційної системи. Кросплатформні застосунки мають спільну кодову базу для Windows, macOS і Linux, що знижує вартість їх створення й змін. Ми радимо нативні, коли домінує одна платформа або робота висуває високі вимоги, і кросплатформні, коли важливі кілька платформ.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Так, для завдань, які це дозволяють. Ми разом із вами вирішуємо, які дані потрібні кожному користувачу на пристрої, зберігаємо їх зашифрованими й записуємо зміни, доки не повернеться мережа. Коли той самий запис змінюється у двох місцях, узгоджені правила вирішують, яка зміна переможе, або просять людину обрати.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Так. Ми інтегруємося з пристроями, якими користується ваш персонал, як-от сканери штрихкодів, принтери чеків і етикеток, ваги й платіжні термінали. Ми підключаємося через драйвери, SDK чи стандартні порти кожного пристрою й тестуємо на точних моделях і прошивках, які ви використовуєте, бо пристрої одного типу часто поводяться по-різному.

Докладніше: Інженерія застосунків, платформ і компонованих продуктівПосилання на це запитання

Нативні застосунки на Swift і Kotlin дають найповніший доступ до можливостей пристрою. Кросплатформні застосунки на React Native чи Flutter мають більшу частину коду спільною для iOS і Android, що знижує вартість їх створення й змін. Ми рекомендуємо нативні, коли застосунок сильно залежить від пристрою, і кросплатформні для більшості бізнесових і споживчих застосунків.

Докладніше: Мобільність, просторові обчислення й цифрові двійникиПосилання на це запитання

Цифровий двійник є живою 3D-моделлю фізичного місця чи процесу, що отримує дані з його датчиків і систем. Його варто будувати, коли рішення щодо цього місця дорого перевіряти в реальності. Приклади: зміна виробничої лінії, планування порту, управління районом розумного міста чи навчання персоналу діям у рідкісних ситуаціях.

Докладніше: Мобільність, просторові обчислення й цифрові двійникиПосилання на це запитання

До тих, що описують реальний майданчик: промислових IoT і платформ датчиків, систем будівель і заводів, ERP і систем обслуговування активів. Ми узгоджуємо джерела даних і частоту оновлення кожного, щоб двійник показував майданчик таким, як він є.

Докладніше: Мобільність, просторові обчислення й цифрові двійникиПосилання на це запитання

Так, де це дозволяють шляхи. Ми зберігаємо потрібні користувачу дані на пристрої зашифрованими й ставимо його зміни в чергу, доки звʼязок не повернеться. Правила синхронізації вирішують, що робити, коли той самий запис змінився у двох місцях, і ми проєктуємо ці правила разом із вами.

Докладніше: Мобільність, просторові обчислення й цифрові двійникиПосилання на це запитання

Ми проєктуємо за WCAG 2.2 AA з першого каркаса: достатній контраст, видимий фокус, логічний порядок читання, достатньо великі цілі й позначка для кожного елемента керування. Автоматичні перевірки виконуються на кожну зміну. Перед кожним релізом ми вручну перевіряємо ключові шляхи з клавіатурою й екранними читачами.

Докладніше: UX і автономна інженерія якостіПосилання на це запитання

Так. Дизайн справа наліво означає більше, ніж віддзеркалити екран: навігація, індикатори прогресу й іконки напрямку віддзеркалюються, а числа, логотипи й елементи керування медіа зазвичай ні. Арабський текст потребує власного шрифту, кегля й міжрядкового інтервалу, і ми перевіряємо обидва напрями з носіями мови.

Докладніше: UX і автономна інженерія якостіПосилання на це запитання

Тести інтерфейсу зазвичай ламаються, коли кнопка зміщується чи перейменовується, навіть якщо функція досі працює. Самовідновні тести використовують ШІ, щоб знову знайти елемент і запропонувати оновлений тест, який інженер переглядає до прийняття. Набір залишається надійним, не приховуючи справжніх дефектів.

Докладніше: UX і автономна інженерія якостіПосилання на це запитання

Він швидко читає великі обсяги старого коду: пояснює, що робить програма, простежує, куди йдуть дані, пропонує рефакторинг і готує чернетки тестів. Інженери вирішують, що змінювати, переглядають кожен рядок і доводять це характеризаційними тестами. ШІ прискорює розуміння; він не замінює перевірку.

Докладніше: Модернізація застарілих систем із прискоренням ШІПосилання на це запитання

Так. Ми перекладаємо чи перебудовуємо програми COBOL як хмарно-нативні сервіси й мігруємо дані DB2 зі звірянням на кожному кроці. Пакетні завдання й файлові інтерфейси отримують сучасні аналоги. Частини, що стабільні й дорогі для перенесення, можуть залишатися за шаром API, доки не прийде їхня черга.

Докладніше: Модернізація застарілих систем із прискоренням ШІПосилання на це запитання

Коли старе ядро стабільне й правильне, але до нього важко дістатися. Сучасні API перед ним дають новим каналам, партнерам і продуктам користуватися його функціями, не торкаючись внутрішнього устрою. Ми рекомендуємо заміну, коли система блокує зміни, не піддається захисту чи більше не має персоналу.

Докладніше: Модернізація застарілих систем із прискоренням ШІПосилання на це запитання

Суверенна хмара тримає дані, операції й правовий контроль у межах однієї юрисдикції. Це може бути регіональний постачальник, державна хмара, регіон гіперскейлера з належними засобами контролю або ваш власний дата-центр. Вона потрібна, коли закон чи ваш регулятор вимагає, щоб певні записи залишалися в країні. Ми картуємо, які з ваших навантажень підпадають під такі правила, перш ніж радити, де їм працювати.

Докладніше: Хмарна інженерія, SovereignTech і гібридна міграціяПосилання на це запитання

Зазвичай той, яким ви вже користуєтеся, якщо немає чіткої причини змінювати. Вирішальні чинники: розміщення даних, ваші наявні договори й навички, потрібні вам керовані послуги та те, як підключаються інші ваші системи. Ми працюємо з AWS, Microsoft Azure, Google Cloud, Alibaba Cloud і регіональними державними хмарами й залишаємо код, специфічний для провайдера, лише там, де це виправдано.

Докладніше: Хмарна інженерія, SovereignTech і гібридна міграціяПосилання на це запитання

Інфраструктура визначається в інструментах з відкритим кодом, як-от Terraform, OpenTofu чи Pulumi, а навантаження працюють на Kubernetes чи інших переносних платформах. Де власний сервіс постачальника кращий, ми використовуємо його свідомо й записуємо шлях виходу. У результаті ви маєте письмову оцінку того, скільки коштувало б перенесення кожного навантаження.

Докладніше: Хмарна інженерія, SovereignTech і гібридна міграціяПосилання на це запитання

Це залежить від кожної системи: де можна зберігати її дані, які в неї потреби в продуктивності й звʼязності, які ліцензії і що ваша команда може експлуатувати. Багато підприємств ведуть гібридну інфраструктуру, яка добре працює, коли спроєктована як одне ціле. Ми порівнюємо варіанти за витратами, ризиком і зусиллями й радимо той, який обрали б самі.

Докладніше: Хмарна інженерія, SovereignTech і гібридна міграціяПосилання на це запитання

Розгляньте це, коли дані не можуть залишати ваш периметр або коли використання достатньо стабільне, що власні потужності коштують менше за оплату за кожен виклик. Ми порівнюємо приватний кластер, суверенну хмару й публічний сервіс моделей для вашого навантаження, а потім розмірюємо кластер і моделі, які він обслуговує.

Докладніше: Хмарна інженерія, SovereignTech і гібридна міграціяПосилання на це запитання

Так. Ми починаємо з того, що у вас є, і замінюємо лише те, що без підтримки або заважає дизайну. Де треба купувати обладнання чи ліцензії, ми вказуємо, що потрібно і чому, а постачальника обираєте ви.

Докладніше: Хмарна інженерія, SovereignTech і гібридна міграціяПосилання на це запитання

DevOps є практикою, за якої розробники й експлуатація спільно відповідають за роботу програмного забезпечення. Платформна інженерія перетворює цю практику на продукт: внутрішню платформу для розробників, що дає кожній команді однаковий перевірений спосіб створювати, розгортати й запускати сервіси. Ваші команди витрачають час на функції, а не на конвеєри.

Докладніше: DevOps, платформна інженерія та середовища ШІ-програмуванняПосилання на це запитання

Зазвичай ті, що у вас уже є. Ми працюємо з Terraform, OpenTofu і Pulumi для інфраструктури, Kubernetes для контейнерів і поширеними сервісами CI/CD, зокрема GitLab CI/CD, GitHub Actions і Argo CD. Ми рекомендуємо зміну лише тоді, коли інструмент блокує потрібне вам.

Докладніше: DevOps, платформна інженерія та середовища ШІ-програмуванняПосилання на це запитання

Ні, якщо їх налаштовано для кожного сценарію використання. Завдання переходить до меншої моделі лише після того, як проходить ті самі оцінювання, що й передова модель, а кешовані відповіді використовуються лише там, де збережена відповідь залишається правильною. Усе непевне все одно йде до більшої моделі.

Докладніше: SRE, спостережуваність і FinOps хмари та токенів ШІПосилання на це запитання

GreenOps застосовує підхід FinOps до енергії й вуглецю. Навантаження розміщуються за фактичним споживанням, працюють там і тоді, де й коли електроенергія чистіша, якщо можуть зачекати, і звітуються в термінах, потрібних вашій звітності ESG.

Докладніше: SRE, спостережуваність і FinOps хмари та токенів ШІПосилання на це запитання

Підтримка залежить від моделі й версії прошивки. Ми перевіряємо кожен HSM під час аудиту CBOM і плануємо оновлення чи заміну лише там, де вони потрібні.

Докладніше: Постквантова криптографія й квантово-стійке шифруванняПосилання на це запитання

Рідко. Постквантова криптографія працює на мережах і обладнанні, які у вас уже є, а QKD потребує виділених оптичних ліній. Ми розглядаємо QKD лише для кількох високоцінних ліній, де його очікує регулятор чи партнер.

Докладніше: Постквантова криптографія й квантово-стійке шифруванняПосилання на це запитання

AWS, Microsoft Azure, Google Cloud, Alibaba Cloud і регіональні урядові хмари, а також ваші власні центри даних і приватні GPU-кластери. Інфраструктура визначена в Terraform, OpenTofu чи Pulumi, а навантаження працюють на Kubernetes, тож вибір провайдера залишається відкритим.

Докладніше: Хмара й інфраструктураПосилання на це запитання

Так. Ми оцінюємо, які сервіси привʼязують вас до провайдера, проєктуємо ціль у суверенній хмарі, іншого провайдера чи вашому центрі даних і переносимо навантаження поетапно зі шляхом відкату для кожного. Ви вирішуєте, як далеко йти: деякі клієнти переносять усе, інші лише навантаження, які важливі для їхніх регуляторів.

Докладніше: Хмара й інфраструктураПосилання на це запитання