24.11.2016
20424
Концепция быстрой разработки приложений (RAD, Rapid Application Development) когда-то применялась для создания приложений с минимумом программного кода. Приложения получались с ограниченным функционалом и не предназначались для продолжительного использования.
Но в последние несколько лет направление RAD эволюционировало в достаточно универсальное средство, которое подходит практически для любых проектов. Мы расскажем об изменениях, которые претерпела концепция RAD в последние годы, преимуществах ее использования в облаке, вариантах с минимумом программного кода, и о том, для каких проектов RAD наиболее применима.
Существует две основных причины, по которым представителям IT-компаний стоит опираться на новые подходы в разработке приложений.
Применение каждого из этих подходов сопряжено с рядом сложностей, а именно:
а) Дефицит технического персонала. Необходимо вовремя собрать хорошую команду квалифицированных специалистов.
б) Задержки сроков. Могут быть вызваны поиском сотрудников или ресурсов; реализация большинства инновационных проектов требует продолжительного времени, сложно заранее предугадать, какая из инноваций ПО окажется по-настоящему эффективной.
в) Чрезмерные расходы. Всегда нужно учитывать то обстоятельство, что проект может выйти за очерченные границы; по мере работы над проектом требования возрастают. Это важный аспект, на который необходимо обращать внимание при подсчете совокупной стоимости владения (TCO), поскольку, ко всему прочему, нужно также учитывать и необходимость поддержки работы приложения.
а) Интеграция с уже существующими приложениями:
Слабая связность (loose coupling) — это тренд сегодняшнего дня, для этого используются протоколы на основе HTTP, такие как REST (можно сравнить с SOAP-интеграцией). У многих корпоративных приложений могут отсутствовать определенные REST API. Чаще встречается интеграция с CRM, SCM и другими системами.
в) Дизайн хороших API. Когда создаются новые API, масштабируемость и управление версиями становятся главными сложностями. Должна присутствовать возможность добавления новой версии приложения без каких-либо затруднений.
а) Увеличьте штат сотрудников, которые могут заниматься инновациями. Для разработки современных приложений необходимы различные навыки и умения (front-end, back-end), многие из них устроены довольно сложно и беспрерывно меняются.
б) Используйте проверенные платформы и инструменты, необходимые для быстрой разработки мобильных приложений. Когда интерфейс приложения не был столь важным фактором, было достаточно BPM-систем. Но требования пользователей изменились. В приложениях, отвечающих духу времени, реализуется передовой опыт и стандарты (material design). К сожалению, BPM-системы разрабатывались без применения программного кода, и сейчас они неконкурентоспособны.
в) Создание корпоративных стандартов, делающих возможным повторное использование. Стоимость соблюдения стандартов корпоративного дизайна (будь то шрифты, цвета или темы) должна компенсироваться выбором подходящей платформы, которая бы делала возможным такие практики. Необходима возможность повторного использования разработок, которые делают квалифицированные инженеры — с целью сокращения рабочего времени, затрат и обеспечения целостности системы всех проектов. (Зачем заново писать код для аналогичных проектов?)
1) IaaS (инфраструктура как услуга — возможность применения облачной инфраструктуры для самостоятельного управления ресурсами обработки, хранения и прочих базовых вычислительных ресурсов) получила широкое распространение благодаря Amazon AWS и Microsoft Azure. Стоимость аппаратного обеспечение сводится к минимуму: вместо капитальных затрат (CAPEX) достаточно операционных (OPEX).
2) Технологии больших данных становятся доступны благодаря дешевым облачным сервисам.
3) Облачные сервисы позволяют компаниям увеличить бюджет инноваций. Помимо возможностей IaaS, можно отметить и PaaS (платформа как сервис), такой подход делает разработку приложений еще более дешевой.
RAD-платформы не должны применяться для разработки игр и других сверхинтерактивных приложений. Согласно этому правилу, из списка возможных автоматически вычёркиваются Angry birds и приложения, функционирующие на манер Uber.
RAD больше подойдет для приложений, в основе работы которых заложены данные (и которые становятся доступными за счет систем управления базами данных).
Каждой компании стоит обратить внимание на RAD-стратегию. Во-первых, такой подход позволяет создавать UI более целостными. Такие приложения больше соответствуют требованиям дизайна целевых устройств. (К примеру, даже перенос кнопок OK и Cancel, если оригинальное приложение создавалось для другой платформы, может быть сопряжен с низким качеством адаптации, и даже поставить под угрозу весь проект).
Уровень квалификации сотрудников зависит от выбора конкретной RAD-платформы, но уровень необходимых навыков здесь определенно ниже, чем если бы пришлось разрабатывать приложение в каком-то языке программирования. Учитывая то, что на сегодняшний день практически каждое приложение предоставляет определенный уровень гибкости, рядовой пользователь может сделать кастомизацию без участия сотрудника IT-отдела. Это комбинация профессиональных разработчиков, разбирающихся в различных технологиях (HTML, CSS, Javascript, API, Security, Java, DB design, и пр.) и передовых наработок (дизайнерские паттерны, основы UX и т.д.)
Современные RAD-платформы не создавались как платформы, для которых совершенно не требуются какие-либо познания в программировании. Они лишь облегчают задачу.
Спрос на мобильные приложения беспрерывно увеличивается. Приложения должны работать на различных устройствах (с разным форм-фактором и интерактивными возможности). Многие корпоративные приложения должны быть доступны на широком множестве электронных устройств (ПК, лэптопы).
Поэтому необходимы API, делающие возможной автономную разработку для серверной (back-end) и клиентской части (front-end).
Руководители наиболее прогрессивных компаний отдают себе отчет в том, что у RAD существуют определенные преимущества. Такие проблемы, как сокращение бюджетов и кадрового потенциала, встречаются повсеместно. Технологический ландшафт беспрерывно меняется, и многие рассматривают RAD как подходящее решение сложностей, связанных с этим процессом.
Некогда распространение Agile-методов тоже шло постепенно. Но сейчас гибкая методология уже стала мейнстримом.
Руководителям отделов информационных технологий целесообразнее выбирать платформы с невысоким содержанием программного кода, чтобы упростить внедрение будущих инноваций. Никто не знает, в каком направлении технологии будут развиваться в дальнейшем, это все равно, что пытаться предсказать, какая компания добьется успеха на рынке.
Использование эффективной платформы устраняет традиционные сложности, сопряженные с IT, и предоставляет необходимые ресурсы.
Главное — выбрать соответствующий тип приложения: адаптивное, нативное или гибридное.
Адаптивное приложение работает на мобильном браузере, на обычном браузере для ПК (деспот или лэптоп). Доступ к приложению осуществляется за счет ввода URL, приложение должно быть доступно на небольших экранах, хотя в нем могут отсутствовать возможности взаимодействия с помощью жестов и ряд других возможностей (камера). Адаптивное приложение адаптируется к размерам экрана устройства, предоставляет доступ к важным средствам управления в зависимости от доступного места.
Нативные приложения работают быстрее, устанавливаются на устройство (им может потребоваться доступ к внутреннему серверу). Однако разрабатывать нативные приложения сложнее, их необходимо обновлять для работы на новых устройствах и ОС.
Гибридные приложения — это некое промежуточные звено. Их проще разрабатывать и поддерживать (за счет технологий HTML/CSS/JS).
Подпишись на рассылку
01.03.2016
2732
В последние годы пользовательские взаимодействия эволюционируют столь стремительно, что дизайнеры едва ли могут за ними уследить. Такая эволюция позволяет...
13.07.2017
148736
Следующий шаг после установки Tomcat — выбрать базовые настройки. Этот процесс разбит на два этапа