CC BY
19
КАЧЕСТВО ПРОГРАММНОГО ПРОДУКТА В РАКУРСЕ
СОВРЕМЕННЫХ ПРАКТИЧЕСКИХ ТРЕБОВАНИЙ Атрощенко Н.А. Email: Atroschenko1152@scientifictext.ru
Атрощенко Натэлла Александровна - старший преподаватель, кафедра экономической информатики, Белорусский государственный университет информатики и радиоэлектроники, г. Минск, Республика Беларусь
Аннотация: анализируется влияние различных внешних и внутренних факторов на итоговое качество конечного программного продукта, общие и специфические требования к современной IT системе, влияние основных и дополнительных факторов на дальнейшую востребованность, жизнеспособность, устойчивость и практическую ценность программного продукта, в том числе готовность заказчика приобрести, внедрить и субсидировать дальнейшее развитие предлагаемого программного продукта; поэтому к современному специалисту по созданию и обеспечению информационных технологий выдвигается ряд требований по знанию основ международных стандартов программных систем, качества кода, архитектурных проектных решений, без этого нельзя добиться их конкурентоспособности и практической пригодности на IT рынке. Ключевые слова: IT технологии, качество программного кода.
QUALITY OF THE SOFTWARE PRODUCT IN THE PERSPECTIVE OF MODERN PRACTICAL REQUIREMENTS Atroschenko N.A.
Atroschenko Natella Alexandrovna - Senior Teacher, DEPARTMENT OF ECONOMIC INFORMATICS, BELARUSIONSTATE OF UNIVERSITY OF INFORMATICS AND RADIOELECTRONICS, MINSK, REPUBLIC OF BELARUS
Abstract: it analyzes the influence of various external and internal factors on the final quality of the final software product, general and specific requirements for a modern IT system, the influence of major and additional factors on the further demand, viability, sustainability and practical value of the software product, including the customer's readiness to acquire, implement and subsidize the further development of the proposed software product; Therefore, a number of requirements are put forward for a modern specialist in the creation and provision of information technologies for knowledge of the fundamentals of international standards for software systems, code quality, architectural design solutions — without this, their competitiveness and practical suitability in the IT market cannot be achieved. Keywords: IT technologies, quality of program code.
УДК 00.004.054
В связи с масштабной информатизацией жизни общества в современном мире лавинообразно возрастает и потребность в программных продуктах самого разного вида и назначения, в их написании, поддержке, обновлении, интеграции и т.д.
Известно, что серьёзных опытных специалистов не так уж и много в любой отрасли, гениальных ещё меньше. IT-индустрия здесь также не является исключением.
Поэтому для проверки качества программного кода существуют международные критерии и оценки.
Программный продукт, пройдя нелёгкий путь от стартапа до реализации, кроме выполнения общепринятых норм и стандартов должен обладать рядом дополнительных факторов, влияющих на его жизнеспособность, востребованность и готовность заказчика внедрить его у себя, оплачивать в дальнейшем его поддержку и обновление.
Среди общих требований, вне зависимости от направления (веб, математическая модель, банковская система или что-то другое), можно в общем выделить следующие требования:
• кроссплатформенность, кроссбраузерность, чёткое взаимодействие с другими программными и аппаратными комплексами, а также фреймворками, плагинами, статическими и динамическими библиотеками, хранилищами данных [2, с. 21];
• увеличение числа её возможных пользователей, последовавшее после её внедрения, чья работа будет теперь «завязана» на пользование этим программным продуктом; желательно, с принесением явной экономической выгоды;
• удобство в использовании и включение достаточно полной внятной документации для администраторов и пользователей;
• максимально лёгкая конфигурируемость, и при этом некие дополнительные выгоды, связанные с развитием программного комплекса, внесением новой функциональности, устранением ошибок без больших затрат на реинженеринг в случае необходимости;
• специфические требования к возможности решать некие связанные задачи, иногда не имеющие чёткой постановки, но чрезвычайно важные с экономической точки зрения для данного заказчика.
В то же самое время можно перечислить и ряд негативных сторон, общих для большинства программных продуктов, вызываемых в случае:
- низкой производительности программы, приводящей к экономическим издержкам, низкой востребованности, потерям потенциальных клиентов;
- нестабильной работы и частых сбоев, несущих ощутимый ущерб заказчику или партнёрам;
- невозможности доработки программного продукта без существенного перестроения архитектуры проекта, затрагивания максимального количества слоёв и уровней системы;
- изначально имеющихся ограничений: предположим, невозможность работы с почтовыми протоколами, отсутствия возможности сериализации объектов, сложностей в работе с многопоточными запросами и т.д.;
- сложности с внедрением программного продукта, как то: конфликты с операционными системами, библиотеками, архивами, адресными хранилищами данных и их типизации и т.д. [1, с. 302].
Поскольку чаще всего речь идёт о многоуровневой распределённой системе, для избегания возможных издержек как со стороны заказчика, так и со стороны исполнителя, необходимо с самого начала строго продумать наиболее важные моменты проектирования с учётом концептуальной структуры, архитектуры системы.
Архитектура многоуровневого распределённого приложения основана на клиент-серверном обмене данными и функциональности, основанной на взаимодействии равноправных объектов, осуществляющих этот обмен. Объекты при этом могут выступать причём как на клиентской, так и на серверной стороне.
От проектировщика, как правило, не зависит характер взаимодействия клиентской и серверной стороны, он определяется стандартами информационной системы (например, стандартами Java2EE), но все модификации, изменения, редактирование, усовершенствование, обновления, поддержка работы компонентов - напрямую являются задачами программиста.
На уровне реализации проектировщик вправе решить, какие задачи являются наиболее приоритетными, как модифицировать систему для получения наибольшей отдачи от неё.
На этапе проектирования нужно учитывать тот факт, что любое многоуровневое распределённое приложение, подобно «тяжёлому бомбардировщику», достаточно трудно будет развернуть, перенастроить, модифицировать, сделать полный upgrade системы, которую сечениями можно разделить на параллели трех типов:
• Layers (Слои), это: система программных интерфейсов управляющих аппаратными средствами, потоками и взаимодействием с операционной системой, реализация сервера приложений, логика представления (presentation logic);
• Tiers (Уровни): клиента, преставления, бизнес логики, интеграции, ресурсов;
• Capabilities (Возможности): работоспособность, ёмкость, гибкость, управляемость, масштабируемость, безопасность, тестируемость и т.д.
Достаточно серьёзно при проектировании программной системы необходимо отнестись и организации совместной работы многих людей, сделав их сотрудничество максимально экономически эффективным для получения практического результата.
При этом нужно учесть некоторые аспекты, касающиеся «человеческого фактора»:
• необходимо организовать техническую основу для устойчивой коммуникации разработчиков, так как они, как правило, находятся на удалённом расстоянии друг от друга;
• обеспечить снабжение необходимым программным обеспечением IT специалистов всех уровней;
• создать контроль версий (subversions) проекта;
• обеспечить полную техническую поддержку разработчиков информационной системы: недопустимо, чтобы выросли затраты или качество программного продукта из-за недостаточного количества оперативной памяти или слишком медленных процессоров;
• организовать тестирование всей системы в реальных «боевых» условиях, когда можно будет с точностью судить о качестве программной архитектуры, быстродействии, безопасности, масштабировании и устойчивости кода;
• обеспечить детальное описание различных аспектов эксплуатации системы;
• обеспечить руководство последовательностью деятельности разработчиков;
• проработать этапы выполнения проекта без непроизводительного простаивания работников и создать контроль за равномерностью трудовой нагрузки без «авральной работы»;
• нужно организовать своевременную оплату труда IT специалистов;
• обеспечить правовую сторону разработки: приобретение патентов, лицензирование, маркетинговую деятельность.
К человеческим факторам можно также отнести и тот факт, что объективно невозможно судить о том, что данная информационная система всегда и при любых обстоятельствах «правильно» выполняет поставленные перед ней задачи, максимально удовлетворяет практическим потребностям потенциальных пользователей, запросам всех заинтересованных лиц и различных групп пользователей.
Мнения людей о качестве программного продукта, как правило, чрезвычайно субъективны и зависят от многих причин: опыта, знаний, потребностей, реалистичности запросов и т.д.
Как следствие вышеизложенного можно отметить тот фактор, что при разработке сложных проектных решений нужно искать компромиссные решения между бюджетом проекта и затратами на программное обеспечение, организацией взаимодействия и оплатой труда разработчиков, между удовлетворённостью пользователей программного продукта и удовлетворённостью им IT-специалистов, между эксплуатационными характеристиками системы и реальными условиями её эксплуатации.
Качество программного кода при этом нельзя назвать определяющим для определения качественного уровня всей системы, особенно, если речь идёт о многоуровневом многоцелевом распределённом приложении.
Таким образом, понятие качественного программного продукта вовсе не достигается только борьбой за «чистоту и оптимизацию» кода программы; наряду с этим множество факторов может повлиять на реальный уровень качества программного продукта для заказчика, с точки зрения востребованности, окупаемости, трудозатрат, его экономической и практической ценности.
Список литературы /References
1. Машнин Т.С. Современные Java технологии на практике // Санкт-Петербург. «БХВ-Петербург», 2010. С. 302-305.
2. МонсонХейфел Ричард. Enterprise JavaBeans // Санкт Петербург. Символ, 2002. С. 21-24.
МИКРОСЕРВИСНАЯ АРХИТЕКТУРА ПРИЛОЖЕНИЯ КАК СИСТЕМА, УПРОЩАЮЩАЯ РАЗРАБОТКУ И ПОДДЕРЖКУ КОДА Петров Д.Г. Email: Petrov1152@scientifictext.ru
Петров Денис Георгиевич - специалист по защите информации в автоматизированных системах,
кафедра вычислительной техники, Чувашский государственный университет им. И.Н. Ульянова, г. Чебоксары
Аннотация: в статье анализируется метод описания объектов данных в строках передаваемых запросов, разбиение возможных запросов на логические единицы и их обработка. Рассмотрен формат передаваемых данных для изменения и добавления новых структур данных. Представлен универсальный протокол передачи данных для сервисов с многосервисной архитектурой, которые не могут быть написаны на разных языках программирования. Приведен пример возможных сущностей системы обработки запросов к базе данных, описанной API REST методологией передачи данных. Ключевые слова: микросервисная архитектура, распределение данных.
MICROSERVICE APPLICATION ARCHITECTURE AS A SYSTEM THAT SIMPLIFIES CODE DEVELOPMENT AND SUPPORT
Petrov D.G.
Petrov Denis Georgievich - Specialist in information protection in automated systems, DEPARTMENT OF COMPUTER ENGINEERING, CHUVASH STATE UNIVERSITY I.N. ULYANOV, CHEBOKSARY
Abstract: the article analyzes the method of describing data objects in the rows of transmitted queries, splitting possible queries into logical units and their processing. The format of the transmitted data for changing and adding new data structures is considered. A universal data transfer protocol for services with a multi-service architecture that cannot be written in different programming languages is presented. An example of possible entities of the database query processing system is described, which is described by the REST API data transfer methodology. Keywords: microservice architecture, data distribution.
УДК: 004.451.26
Метод распределения больших приложений на отдельные модули, взаимодействующие между собой по одному протоколу передачи данных, улучшает скорость разработки и поддержку системы. Разбиение монолитной части программного приложения [1, с. 52] -важная часть разработки больших систем. Для таких систем необходим универсальный метод описания объектов, передаваемых данных. Методологии REST API описывает такой способ передачи данных. Каждый новый запрос открывает соединение и отправляет данные на сервер. Существует несколько методов отправки запроса, используемые в системе:
• GET - получение данных. Ответ - данные от сервера в заданном формате и код возврата;
• POST - обновление данных. В теле запроса содержатся параметры описывающие данные для изменения. Ответ - данные от сервера и код возврата;
• PUT - создание нового объекта данных. В теле запроса содержатся параметры создаваемого объекта. Ответ - код возврата;
