Tagged: Проектирование

19
Июн
2021

🔄 Как стать сетевым инженером в 2021 году?

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

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

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

Что нужно знать и уметь?


Давайте разберем базовые навыки, необходимые начинающему инженеру сетей для входа в профессию:

  • Клиенты и серверы: как клиенты и сервисы соединяются с помощью сетей.
  • Стек протоколов TCP/IP: модель OSI, протоколы различных уровней, IPv4 и IPv6, подсети и основы статической и динамической маршрутизации.
  • Структурированная кабельная система.
  • Активное сетевое оборудование: концентраторы, коммутаторы, маршрутизаторы и т.д.
  • Сетевая безопасность: концепция защищенного периметра, межсетевые экраны и тому подобные решения.
  • Операционные системы (Windows Server, Linux).
Для анализа сетевых структур необходимо знать как их аппаратные, так и программные характеристики. Также необходимо понимание облачных вычислений, управление доменами и устройства корпоративных сетей.

Нужна ли формальная сертификация?


Начинающему сетевому инженеру стоит задуматься о получении сертификата от одного или нескольких производителей оборудования (вендоров). Наиболее популярным из них является CCNA (Cisco Certified Network Associate – начальный уровень в системе сертификации компании Cisco).

Тест CCNA включает проверку знаний по теории компьютерных сетей, стеку TCP/IP, модели OSI и по фактическому выполнению распространенных практических задач, которые должен решать сетевой инженер. Сертификат не является доказательством высокого уровня знаний: он скорее говорит о наличии базового понимания работы с сетевым оборудованием. Для новичков наличие официальной бумаги станет хорошим подспорьем в поиске работы.

Cisco – не единственный вариант получения сертификата, их много. Одним из перспективных вариантов является другой производитель сетевого оборудования – Juniper Networks. Его доля на рынке растет, поэтому эксперты Juniper пользуются большим спросом у работодателей.

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

Где получить недостающие знания?

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

  • Проект статей на habr.com «Сети для самых маленьких». Отличная серия публикаций по системному администрированию для новичков. Авторы проделали превосходную работу и создали хорошо структурированный онлайн-учебник.
  • Книга «Компьютерные сети» Виктора и Натальи Олифер предназначена для студентов технических ВУЗов. В ней разъясняются базовые принципы построения компьютерных сетей и способы управления ими, а также особенности традиционных сетевых технологий.
  • Книги Рене Мулинара (Rene Molenaar «How to master CCNP route»). Лучшая литература для подготовки к сертификации Cisco по треку R&S любого уровня. Единственный недостаток: издания платные и на английском языке.
  • Классика жанра – книга «Компьютерные сети» Э. Таненбаума и Д .Уэзэрол. В ней изложены основные понятия, определяющие современные тенденции развития компьютерных сетей.
Теория важна, но в первую очередь работодатели ищут в резюме кандидата практический опыт. Для общего понимания специфики хорошим началом станет стажировка в службе поддержки сети. Это отличный способ развить реальные навыки, необходимые будущему сетевому инженеру для решения повседневных задач. Также не стоит забывать про soft skills. Общение, работа в команде и творческий подход к решению проблем зачастую важнее академических результатов.

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

  • CISCO Packet Tracer. Мощная программа моделирования сетей
  • VIRL. Виртуальная лаборатория маршрутизации в Интернете
  • Boson NetSim. Имитатор сетевых коммутаторов и маршрутизаторов
  • EVE-NG (Emulated Virtual Environment). Эмулированная виртуальная лаборатория с сетевым оборудованием и программным обеспечением.
  • GNS3. Интерфейс для эмуляции и виртуализации сети

Где работают сетевые инженеры и сколько им платят?


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

Среди ведущих зарубежных работодателей можно найти таких гигантов, как Cisco Systems, AT&T и Amazon. Согласно исследованиям крупнейшего статистического сайта Salary.com, средняя заработная плата инженера сетей в США варьируется от 70 000 до 130 000 долларов в год в зависимости от уровня (Levels IV).

Российская площадка по поиску работы neuvoo.ru проанализировала зарплатную статистику по профессии «Сетевой Инженер»: в нашей стране молодой специалист получает от 385 000 рублей в год, а заработок самых опытных достигает 1 080 000 рублей в год.

Специфика работы: мнения специалистов о профессии


Если молодому инженеру поставить задачу – починить оборудование, первое, что он делает – идет в Google, даже не заглянув в инструкцию или спецификацию. Он найдет ответ на вопрос. И, если повезет, то ничего не сломает. В нашей профессии можно ошибаться – мы не лечим людей и не запускаем ракеты. Но даже при этом «чисто экспериментальный» подход неразумен и часто неэффективен. Специалисту для уверенного выполнения своих задач нужна база знаний. В нашем случае – понимание принципов, по которым работает сеть. Потом человек начинает расти. Подтягивает знания по операционным системам и аппаратному обеспечению. Шлифует это все знаниями по безопасности. В итоге мы получаем серьезного профессионала.
Александр Городецкий, заведующий кафедрой «Сетевые технологии и системное администрирование» компьютерной академии Шаг. Источник: blog.trud.com
Карьеру в ИТ сегодня чаще всего ассоциируют с задачами в области разработки софта. Программист, тестировщик, системный архитектор, тим-лид и подобные позиции у всех «на слуху». Между тем, ничуть не менее важная область современных цифровых решений представлена сетями, где свой вклад в создание и работу самых современных digital-продуктов делают сетевые инженеры.
Аркадий Марисенков, инженер IP-сетей компании Linxdatacenter. Источник: tproger.ru
Сетевые инженеры обычно работают в крупных компаниях, часто – в телекоммуникационных провайдерах. Такие организации обладают масштабной инфраструктурой, работать с которой интересно. Среди других технологических компаний, сравнимыми возможностями обладают разве что гиганты, вроде Google и Facebook. Поэтому сетевики не заинтересованы в рассмотрении предложений о переходе. На рынке не так уж много инженеров, обладающих опытом автоматизации и написания продакшн-кода (например, опыта работы с SDN). Поэтому в данном направлении – всегда нехватка специалистов.
Энрико Хейдельберг, HR manager, компания Riot Games. Источник: amazinghiring.ru
***

Стать квалифицированным сетевым инженером достаточно сложно. Работодатели все чаще ищут профессионалов с универсальными навыками, а крупные компании обычно требуют высшее образование в области компьютерных наук, информационных систем или компьютерной инженерии. Если у вас нет ученых степеней в этой области – не страшно! Теперь можно изучить все необходимое при помощи практикующих наставников-профессионалов факультета «Сетевой инженер» образовательной онлайн-платформы GeekBrains. Здесь вы освоите сетевые технологии с нуля, получите диплом о профессиональной подготовке и сможете начать карьеру на уровне настоящего боевого джуна. Получите необходимые знания по администрированию сетей, закрепите их на практике, а также пополните портфолио двумя самостоятельными проектами. Не упустите свой шанс. Удачи!

15
Май
2021

🔀 SDLC модели: как выбрать правильный подход к разработке и не завалить проект

В этой статье Вадим Кулага, проектный менеджер EPAM Anywhere, расскажет об основных моделях разработки программного обеспечения (SDLC), их плюсах и минусах, а также о реальных примерах их использования.

29
Апр
2021

🕸 21 лучший метод выведет ваши навыки проектирования API на новый уровень

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

Перевод публикуется с сокращениями, автор оригинальной статьи Mohammad Faisal.

Немного терминологии

Любой API следует так называемому ресурсно-ориентированному
дизайну и состоит из трех ключевых концепций.

  • ресурс: часть данных, например, User;
  • коллекция: группа ресурсов, например, List of users;
  • URL: местоположение ресурса или коллекции, например, /user.

1. Kebab-case для URL-адресов

Если вы хотите получить
список заказов.

Плохо:

        /systemOrders или /system_orders
    

Хорошо:

        /system-orders
    

2. CamelCase для параметров

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

Плохо:

        /system-orders/{order_id} или /system-orders/{OrderId}
    

Хорошо:

        /system-orders/{orderId}
    

3. Множественное число, указывающее на коллекцию

Если необходимо получить
всех пользователей системы.

Плохо:

        GET /user или GET /User
    

Хорошо:

        GET /users
    

4. URL начинается с коллекции и заканчивается идентификатором

Если хотите сохранить
концепцию единой и последовательной.

Плохо:

        GET /shops/:shopId/category/:categoryId/price
    

Это плохо, потому что здесь
описано свойство, а не ресурс.

Хорошо:

        GET /shops/:shopId/ или GET /category/:categoryI
    

5. Не используйте глаголы в URL ресурса

Не используйте глаголы в URL для выражения действий. Вместо этого примените
описанные ниже методы.

Плохо:

        POST /updateuser/{userId} или GET /getusers
    

Хорошо:

        PUT /user/{userId}
    

6. Используйте глаголы в URL для Non-Resource

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

Хорошо:

        POST /alerts/245743/resend
    

7. Используйте camelCase для свойства JSON

Если у вас есть тело запроса
или ответ в JSON, имена свойств должны быть в camelCase.

Плохо:

        {
   user_name: «Programmer's library»
   user_id: «1»
}

    

Хорошо:

        {

   userName: «Programmer's library»

   userId: «1»

}
    

8. Мониторинг

Службы HTTP RESTful должны
реализовывать конечные точки API /health,
/version и /metrics, предоставляющие следующую информацию:

  • /health – отвечает на запросы с кодом состояния 200 OK;
  • /version – отвечает на запрос номером версии;
  • /metrics – эта конечная точка будет предоставлять различные показатели, например, среднее время отклика.

Настоятельно рекомендуем использовать
конечные точки /debug и /status.

9. Не используйте table_name для имени ресурса

Не используйте имя таблицы
в качестве имени ресурса. В долгосрочной перспективе такая лень может привести
к проблемам.

Плохо:

        product_order
    

Хорошо:

        product-orders
    

10. Применяйте инструменты проектирования

Существует много хороших
инструментов проектир
ования API:

  • API Blueprint
  • Swagger

Наличие хорошей и
подробной документации обеспечивает отличный клиентский опыт для пользователей
API.

11. Используйте порядковый номер в качестве версии

Всегда указывайте номер
версии для API. Номер версии должен быть v1, v2 и т. д.

Хорошо:

        http://api.domain.com/v1/shops/3/products
    

Если API используется
внешними сущностями, изменение конечной точки может нарушить их
функциональность, поэтому использование версий обязательно.

12. Выводите в ответе общее количество ресурсов

Если API возвращает
список объектов, всегда включайте общее количество ресурсов в ответ.

Плохо:

        {

пользователи: [ .

..

]

}
    

Хорошо:

        {

пользователи: [ .

..

],

всего: 34

}
    

13. Принимайте параметры ограничения и смещения

Всегда принимайте
параметры ограничения и смещения в операциях GET.

Хорошо:

        GET /shops?offset=5&limit=5
    

Это необходимо для пагинации
на фронтенде.

14. Получаем поля параметров запроса

Следует учитывать объем
возвращаемых данных. Добавьте параметр fields,
чтобы предоставить только необходимые поля из вашего API.

Пример:

Вернуть только название,
адрес и контакты магазинов.

        GET /shops?fields=id,name,address,contact
    

В некоторых случаях это поможет
уменьшить размер ответа.

15. Не передавайте в URL токены аутентификации

Это очень плохая
практика, потому что URL часто регистрируются и, следовательно, маркер
аутентификации также будет регистрироваться без необходимости.

Плохо:

        GET /shops/123?token=some_kind_of_authenticaiton_token
    

Хорошо:

Вместо этого передайте их
в заголовке:

        Authorization: Bearer xxxxxx, Extra yyyyy
    

Кроме того, токены
авторизации должны быть недолговечными.

16. Проверка Content-Type

Сервер не должен
принимать content-type. Например,
если вы принимаете application/x-www-form-urlencoded,
злоумышленник может создать форму и запустить простой запрос POST.

Всегда валидируйте тип контента, а если хотите использовать content-type по умолчанию, используйте application/json.

17. Использование методов HTTP для функций CRUD

Следующие методы служат для
описания CRUD-функций:

  • GET: получение представления ресурса.
  • POST: создание новых ресурсов и подресурсов.
  • PUT: обновление существующих ресурсов.
  • PATCH: обновление существующих ресурсов, но только тех полей, которые были описаны (остальные остаются без изменений).
  • DELETE: удаление существующих ресурсов.

18. Применение отношений в URL для вложенных ресурсов

Вот некоторые
практические примеры:

  • GET /shops/2/products: получить список всех продуктов из магазина 2.
  • GET /shops/2/products/31: получить подробную информацию о продукте 31, из магазина 2.
  • DELETE /shops/2/products/31: удалить продукт 31 из магазина 2.
  • PUT /shops/2/products/31: обновить информацию о продукте 31 (использовать только URL ресурса, а не коллекцию).
  • POST /shops: создать новый магазин и вернуть сведения о нем.

19. CORS

Поддерживайте заголовки
CORS (Cross-Origin Resource Sharing) для всех общедоступных API.

Рассмотрите возможность поддержки разрешенного CORS-источника « * » и принудительной авторизации с помощью OAuth-токенов. Избегайте объединения учетных данных пользователя с валидацией происхождения.

20. Безопасность

Применяйте протокол HTTPS
(зашифрованный TLS) ко всем конечным точкам, ресурсам и службам.

HTTPS должен быть у всех колбеков, эндпоинтов, push-уведомлений и веб-хуков.

21. Ошибки

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

При отклонении запроса клиента по причине ошибок службы возвращают коды HTTP – 4xx.

Заключение

Вот и все – поздравляем,
если вы зашли так далеко! Надеемся, вы кое-чему научились и будете применять рекомендации статьи в своих проектах. Удачи!

Дополнительные материалы:

14
Фев
2021

Правильность проектирования классов Java

Подскажите, правильный ли подход выбран к проектированию классов пользователей.
Есть пользователи, которые делятся на: админ, тренер, студент. У всех есть общие поля, такие как имя, логин и возраст и т.п. У конкретного типа юзера есть особ…

26
Янв
2021

Как правильно спроектировать классы? [закрыт]

Задачи как таковой нет, просто хочу уяснить один момент при проектировании классов. Вот у меня есть класс Book, и у него соответствующие характеристики: издатель, автор, название и т.д. Но есть же и другие книги, например, электронные, а н…

04
Ноя
2020

Laravel вывод данных из таблицы по столбцу текущей таблицы

Есть таблица Payments (платежи), структура такая
‘id’,’id_client’, ‘title’, ‘payment_type’
Как видно она имеет в себе свойство id_client, соответственно id конкретного клиента из таблицы клиентов, чтобы видеть какому клиенту принадлежит пл…

27
Окт
2020

Laravel как связать 2 таблицы для получения данных первой по id другой таблицы

Всем привет. Допустим есть 2 таблицы – clients и payments.
У клиента может быть много платежей, потому тут в моделях у нас связь hasMany.
А как сделать так, чтобы по id клиента указанного в url (допустим url такой /get/client/{client}/paym…

17
Окт
2020

📈 Четыре примера работы аналитиков: кейсы IT-компаний

Аналитики крупных компаний рассказали корреспонденту Proglib о самых интересных кейсах, над которыми им приходилось работать.

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

Иллюстрация с сайта pixabay.com
Иллюстрация с сайта pixabay.com

«Такое решение не имело аналогов на рынке»

О разработанной специалистами АО «Альфа-Банк» системы управления портфелями проектов рассказывает Алексей Лобзов, главный системный аналитик и выпускник университета «МИФИ» по специальности «Прикладная информатика».

Описание задачи

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

Этапы реализации

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

Наиболее интересна задача выравнивания проектов относительно заданных ограничений:

  • количества стартов проектов в промежуток времени;
  • объема платежей за единицу времени;
  • количества доступных специалистов.

Мы точно знали, что Microsoft Project (на тот момент версии 2013 года) имеет близкую к нашей задаче функцию распределения доступных ресурсов и трудовых затрат. Внедряемая система включала модуль календарного планирования на базе Microsoft Project Server, поэтому мы решили построить решение на движке Microsoft.

  1. Совместно с архитектором мы разработали сводную модель план-графиков проектов портфеля. В нее включались наиболее приоритетные проекты, попадающие в выделенный на исполнение лимит денежных средств;
  2. Затем провели тестирование и отладку модели, выставляя ограничения на даты стартов проектов, назначая затраты и трудовые ресурсы, устанавливая лимиты и выполняя выравнивание средствами Microsoft Project.

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

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

  • скорректировать даты стартов и установить лимит на количество проектов, стартующих в заданный промежуток времени;
  • распределить доступные денежные средства по проектам с учетом ограничений на объем платежей в единицу времени;
  • распределить трудовые ресурсы, учитывая их доступность.

Такое решение по ранжированию и выравниванию проектов на тот момент не имело аналогов на рынке.

Выводы

Это внедрение было для меня ценным по нескольким причинам:

  1. Я глубоко погрузился в процессы управления портфелями проектов и получил уникальный опыт их автоматизации. На своей практике не вспомню столь масштабных задач в данной области;
  2. Удалось подтвердить важность анализа возможностей переиспользования существующих решений. Кто знает, сколько времени и ресурсов мы бы потратили на разработку аналогичного Microsoft Project движка;
  3. Участие в подобных проектах побуждает делиться знаниями с окружающими.

По результатам внедрения было написано несколько статей:

  1. Лобзов А.В. На что обратить внимание при балансировке портфеля и выборе проектов // Управление проектами и программами. — 2016. — No2. — С.138–143
  2. Лобзов А.В. Балансировка портфелей и выбор проектов при наличии альтернативных вариантов достижения стратегических целей.
Иллюстрация с сайта pixabay.com
Иллюстрация с сайта pixabay.com

Превратили платформу интерактивного телевидения «Ростелекома» в современный сервис Wink

О создании сервиса Wink рассказывает Константин Валеев, руководитель центра компетенций по системной аналитике в «Ростелеком Информационные Технологии». Константин окончил «Московский Институт Электроники и Математики», а затем аспирантуру и сейчас пишет диссертацию.

Описание задач и их решение

Нашей компании поручили развивать платформу интерактивного телевидения Ростелекома (сейчас это сервис Wink).

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

1. Провести анализ пользовательской части продукта;

2. Описать модель данных и сценарии использования;

3. Разобраться в архитектуре компонентов и их функциях;

4. Зафиксировать потоки данных.

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

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

1. Собирают и документируют требования бизнеса;

2. Анализируют, декомпозируют и детализируют их;

3. На основе требований продумывают потоки, модель и маппинг данных;

4. Вместе с командой дизайна проектируют UX;

5. Совместно с разработчиками проектируют и согласовывают API.

Выводы

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

Для аналитика важно не только разбираться в чем-то уже существующем: продукте, системе, предметной области. Он должен принимать участие и в создании нового – в проектировании будущей системы.

Иллюстрация с сайта pixabay.com
Иллюстрация с сайта pixabay.com

Как сделать реверс-инжиниринг банковской системы с закрытым кодом и без документации

О проекте рассказывает старший аналитик компании Luxoft Анастасия Соболева. Анастасия окончила «Московский университет экономики, статистики и информатики» по специальности «Прикладная информатика в экономике». Ведет Telegram-канал Путь аналитика.

Описание задачи

Сейчас наша команда из 15 человек работает над проектом для крупного российского банка. Система поддерживает процессы фронт-офиса валютного дилинга. Также над проектом работает команда от бизнеса и ИТ-департамента банка.

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

Этапы реализации

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

Все потоки входных-выходных данных и наборы атрибутов удалось определить по документации смежных интегрированных решений, но сама система оставалась «черным ящиком». По наборам атрибутов удалось выделить ее основные объекты. По gap’ам потоков данных с помощью заполнились пробелы происходящего внутри системы при обработке данных. Там, где не нашлось информации, или была неоднозначность – посылали тестовые запросы от внешних систем и смотрели результаты на выходе.

Наша реализация еще в разработке: есть риски наличия «серых зон», поэтому на этапе интеграционного тестирования придется делать сверки, запуская одинаковые запросы через нашу систему и заменяемую.

Выводы

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

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

Еще могу посоветовать для работы PlantUML – это инструмент для кодирования UML-диаграмм. В нем не нужно рисовать стрелочки и квадратики, вместо этого пишется несложный код с определением методов и объектов. Такой инструмент хорошо систематизирует мышление и заставляет думать как разработчик.

Иллюстрация с сайта pixabay.com
Иллюстрация с сайта pixabay.com

«Понимание, как все должно все работать, пришло после изучения сотен страниц текстов и десятков экранов интерфейса»

О создании решения SaaS по модели White Label рассказывает Ольга Крамарченко, проектный и продуктовый менеджер компании Winvestor. Она начинала путь в ИТ как бизнес-аналитик, а затем перешла в управление. Образование Ольга получила в «Ростовском государственном экономическом университете» на факультете «Компьютерных технологий и информационной безопасности».

Описание задачи

Наиболее интересный для меня кейс – переход от заказной разработки к продуктовой, а именно изучение финтех-рынка и работы инвестиционных и управляющих компаний. Мы делали личный кабинет для таких компаний и их клиентов.

Этапы реализации

  1. Тестирование гипотезы, что такой продукт необходим рынку;
  2. Разработка MVP;
  3. Выход в продакшн, активные продажи и внедрение новой функциональности;
  4. Фаза поддержки существующих клиентов, усовершенствование системы.

Пришлось зарегистрироваться на всех релевантных сервисах: так у меня появилось около восьми брокерских счетов. Я тренировала насмотренность, изучала направления UX и проводила интервью с потенциальными клиентами.

Все это важно для создания востребованного рынком продукта. Понимание, как именно должно все работать, пришло после изучения сотен страниц текстов и десятков экранов интерфейса. Представленные решения на рынке были индивидуальными кабинетами под конкретные цели, а мы делали универсальное решение SaaS по модели White Label.

Выводы

Мы вышли на рынок с успешным MVP. Крупные и средние компании из мира финтеха стали нашими клиентами, а команда признана лучшим разработчиком ПО по мнению профессионального сообщества в 2018 и 2019 годах. На базе этого проекта мы начали строить единую экосистему для работы со всеми инвестиционными продуктами.

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

***

Аналитикам приходится решать нетривиальные рабочие задачи и вырабатывать соответствующие навыки. Если вы только задумываетесь о карьере в этой отрасли, мы рекомендуем пройти обучение на факультете Системной и бизнес-аналитики в GeekBrains. Занятия ведут опытные преподаватели, а студенты за время обучения выполняют четыре проекта. Личный куратор помогает им быстро разобраться задачами, на решение которых в ином случае ушли бы недели. Успешно окончившие курс студенты получают диплом о профессиональной подготовке и помощь в трудоустройстве: год обучения в онлайн-академии эквивалентен году реальной работы.

25
Авг
2020

Какие основные классы (сущности) нужно создать для планирования ремонтов?

Пытаюсь спроектировать классы для планирования ремонтов вычислительной техники.
По предметке:
Планируют ремонты на период:
5 лет ИЛИ
1год ИЛИ
1 месяц
Вид плана: годовой, пятилетний, месячный.
Жизненный цикл плана, как документа: создание, …

23
Июл
2020

Оценить учебный проект для решения задачек

Немного начал изучать программирование, выбрал Java, поскольку применяется на работе.
Нашёл сайт с задачками по программированию для обучения. Суть в том, что есть пул заданий по номерам. Сайт даёт какие-то входные данные в несколько строк…

01
Июл
2020

Паттерн проектирования для внутреннего приложения организаций

Работая в вебе, я знаю только паттерн MVC – где есть пользователи сайта и его непосредственные администраторы.. Но вот возникла задача разработать веб-сервис учета оборудования на складе, каким подходом можно пользоваться для проектировани…

30
Июн
2020

Как организовать кеширование между сервисами в разных датацентрах?

Прошу меня строго не судить так как я дилетант в микросервисах да и не силен в построении архитектуры приложения в целом.
У меня три вопроса касаемо архитектуры:

Как организовать кэш между двумя датацентрами которая одна например находитс…

30
Май
2020

Классификация и обработка результата плавающего типа в Java

Пишу бота для Discord на JDA. Хочу всё структурировать, классифицировать по красоте, читаемости и расширяемости с учётом принятых в Java стандартов оформления кода (в которых мало что понимаю, поэтому и задаю этот вопрос).

public class …

28
Май
2020

Рассказываем о методах инструментирования Go-кода, контекстной трассировке и специальном средстве лаконичного и гибкого инструментирования gtrace.

76331ef0-7c12-4d04-9ce9-fc153ee…