Преподаватель который помогает студентам и школьникам в учёбе.

Основы проектирования программ. Этапы создания программного обеспечения

Содержание:

Введение

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

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

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

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

Технология разработки программного обеспечения – это комплекс мер по созданию программных продуктов. Данная деятельность включает в себя несколько этапов, с которыми так или иначе придется столкнуться при разработке достаточно крупного программного обеспечения.

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

Объект исследования – проектирование программ.

Предмет исследования – создание программного обеспечения.

Цель работы – исследование основ проектирования программ и этапов создания программного обеспечения.

Поставленная цель работы обусловила решение следующих задач:

– рассмотреть основы проектирования программ;

– изучить этапы создания программного обеспечения.

1 Основы проектирования программ

1.1 Стандарты разработки IT-программы

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

Комплекс документов, регламентирующих деятельность разработчиков, называют нормативно-методическим обеспечением (HMЗ).

Документы, что входят в состав НМЗ – это стандарты, руководящие документы, методики, положения, инструкции, шаблоны и тому подобное.

Указанные документы регламентируют:

– порядок создания, внедрения и сопровождения системы;

– общие требования к составу системы, к связям между ее компонентами, к качеству программного обеспечения;

– разновидности, состав и содержание проектной и программной документации [10, c. 56].

Исторически сложилось так, что одним из самых распространенных стандартов создания программных систем де-факто является ЕСПД, – Единая Система Программной Документации (серия ГОСТ 19.ХХХ). Изначально эти стандарты были ориентированы на класс сравнительно простых программ, которые могла разработать небольшая группа программистов.

Некоторые авторы считают эти стандарты устаревшими (концептуально и по форме), и в то же время ЕСПД продолжают активно использовать при оформлении ПД.

Международные стандарты проектирования информационных систем:

ISO / IEC 12207 – базовый стандарт на процессы жизненного цикла ИС, он ориентирован на разные типы проектов. В стандарте не предусмотрено конкретных этапов жизненного цикла ИС. Вместо того определен только ряд процессов. Поэтому стандарт позволяет реализовать произвольную модель жизненного цикла, и это является его достоинством.

ГОСТ 34.601-90 – распространяется на автоматизированные информационные системы (АИС) и регламентирует стадии, этапы их создания, содержит описание содержания работ на каждом из этапов. Стандарт ориентирован на использование каскадной модели жизненного цикла.

ISO / IEC 12207: 1995-08-01 и сопутствующие стандарты. Международный стандарт ISO / IEC 12207 (предложен в 1995 техническим комитетом ISO / IEC JTC1 «Информационные технологии, подкомитет SC 7, проектирование программного обеспечения») является важнейшим нормативным документом, регламентирующим жизненный цикл программного обеспечения.

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

Согласно с базовым международным стандартом ISO / IEC 12207 процессы жизненного цикла делятся на 3 группы:

1. Главные процессы:

– приобретение – устанавливает действия предприятия-покупателя;

– поставки – устанавливает действия предприятия-поставщика;

– разработка – устанавливает действия предприятия-разработчика;

– функционирование – устанавливает действия предприятия-оператора, который обеспечивает обслуживание системы в целом в процессе ее функционирования;

– сопровождение – устанавливает действия персонала, обеспечивающего сопровождение программы, то есть управление, модификацию, поддержку функциональной пригодности и текущего состояния; к этому процессу также относится установление (инсталляция) ПО на вычислительной системе и его удаления.

2. Вспомогательные процессы – это процессы, которые предназначены для поддержки главных составляющих, организации верификации, качества проекта, тестирования и проверки ПО и т.д.:

– процесс документирования;

– процесс обеспечения качества;

– процесс управления конфигурацией;

– процесс аттестации;

– процесс верификации;

– процесс аудита;

– процесс решения проблем;

– процесс совместной оценки.

3. Организационные процессы определяют задачи и действия, которые выполняет как заказчик, так и разработчик проекта, а именно:

– процесс создания инфраструктуры проекта;

– процесс управления;

– процесс обучения;

– процесс усовершенствования.

Стандарты «де-факто» – стандарты, которые официально не утверждены, но фактически действуют, например, стандартом «де-факто» долгое время были языки взаимодействия с языком программирования С и базами данных SQL, фирменные стандарты (к примеру, Microsoft ODBC) [3, c. 41].

Рассмотрим другие способы классификации стандартов.

По объекту стандартизации:

– стандарты на технологии и процессы;

– стандарты на услуги и продукты;

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

По предмету стандартизации:

– стандарты на языках программирования;

– стандарты на интерфейс, протоколы и т.д.;

– стандарты на создание жизненного цикла ИС.

В отдельную группу принято выделять корпоративные стандарты.

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

– стандарты проектирования;

– стандарты на оформление документации;

– стандарты на интерфейсы.

Стандарт проектирования должен регламентировать:

– набор моделей (диаграмм) на любой стадии проектирования системы и уровень детализации;

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

Кроме этого данный стандарт регламентирует:

– общие правила оформления диаграмм, также включая требования к их формам, размеру, наполнению и т.д.;

– требования к конфигурации рабочих мест, настройка операционной системы, общие настройки проекта и т.д.;

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

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

– комплектность, структуру и состав документации на каждой стадии проектирования;

– требования к ее оформлению в т.ч. содержание разделов, подразделов, таблиц, пунктов и т.д.;

– правила рассмотрения, подготовки, согласования и внедрения документации с указанием предельных сроков выполнения каждой стадии;

– правила к настройке технических средств подготовки документации.

Общие стандарты интерфейса должны устанавливать:

– правила оформления экранных форм (шрифты, цвет символов, фона);

– расположение и состав элементов и окон управления;

– правила использования средства ввода (клавиатуры, мыши и т.п.);

– правила оформления текстов справок;

– перечень сообщений;

– правила обработки (реакцию) на действия пользователя.

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

1.2 Программное обеспечение и технологии программирования

Программный принцип управления лежит в основе работы всех компьютеров, смысл его заключается в том, что компьютером выполняются действия по предварительно заданной программе [1, c. 98].

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

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

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

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

Все программное обеспечение делится на 2 большие группы:

– системное ПО, которое представляет собой совокупность программ, которые обеспечивают работу компьютера;

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

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

Системное ПО, в свою очередь, делится на базовое и сервисное.

Базовое ПО состоит из:

– операционных систем;

– оболочек;

– сетевых операционных систем.

Сервисное ПО состоит из программ (утилиты):

– диагностирующих;

– антивирусных;

– обслуживающих носители;

– архиваторов;

– обслуживающих сети.

Прикладное ПО будет работать только при наличии системного.

Прикладные программы называются приложениями. К ним относятся:

– табличные и текстовые процессоры;

– базы данных;

– экспертные системы;

– интегрированные пакеты;

– графические процессоры;

– обучающие программы;

– программы математических расчетов, моделирования и анализа;

– коммуникационные программы;

– игры.

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

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

– трансляторы;

– непосредственную среду разработки программ;

– отладчики;

– библиотеки справочных программ (процедур и функций);

– редакторы связей и др. [8, c. 109].

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

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

К технологии программирования применяют следующие требования:

1. Она должна предусматривать отторжимость программного продукта от его разработчика.

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

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

4. Все этапы работы коллектива программистов должны быть охвачены средствами автоматизации.

5. Технология программирования не должна зависеть от языка программирования.

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

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

В заключение главы можно сделать следующие выводы:

Комплекс документов, регламентирующих деятельность разработчиков, называют нормативно-методическим обеспечением (HMЗ). Документы, что входят в состав НМЗ – это стандарты, руководящие документы, методики, положения, инструкции, шаблоны и тому подобное.

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

2 Этапы создания программного обеспечения

2.1 Проектирование программного обеспечения

Проектирование программного обеспечения представляет собой частный случай проектирования процессов и продуктов.

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

Ход процесса проектирования ПО и его результаты будут зависеть не только от состава требований, но и от опыта проектировщика (разработчика) и от выбранной модели процесса проектирования.

После определения требований к программному обеспечению разработчиком будут получены согласованный четкий план действий, график сроков и оплат. В то же время разработчик может сократить время разработки и повысить ее качество, а также позволяет предусмотреть любые другие нюансы разработки, к примеру, юридические (передача авторских прав на проектируемое программное обеспечение) [12, c. 165].

При проектировании ПО заранее разработчик имеет возможность:

– оценить время разработки и стоимость программного продукта;

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

– избежать неудовлетворенности и разногласий между заказчиком и исполнителем.

Подготовительный этап.

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

– подготовки;

– проектирования;

– создания, включающего дизайн, кодирование, тестирование, документирование;

– поддержки, включающей внедрение и сопровождение.

В процессе подготовки к проектированию должны быть решены организационные вопросы:

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

2. Определиться с бюджетом и сроками: на основании имеющихся материалов утверждают примерную стоимость, общий срок всего проекта, а также срок и точную стоимость ближайшего этапа.

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

Этапы и результаты проектирования.

Проектирование состоит из следующих этапов:

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

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

3. Разработки технического задания (ТЗ). ТЗ составляет архитектор в соответствии с описанием и ответами на вопросы заказчика. Затем ТЗ согласовывают с менеджером проекта, далее передают клиенту и производят правки.

4. Этапа разработки макетов, которые затем добавляются к ТЗ. На данном этапе разрабатывают макеты принципиальных схем устройства, интерфейсов, диаграмм структуры базы данных, схем взаимодействия компонентов.

5. Контроля. В ходе этого этапа архитектором устраняются замечания менеджера проектов.

6. Утверждения. На данном этапе заказчиком проверяется и меняется самостоятельно ТЗ, либо сообщается список правок проект-менеджеру. После устранения замечаний ТЗ утверждают и прилагают к контракту.

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

– что делать (содержит описание продукта, функциональных возможностей, категорию пользователей)?

– как делать (содержит описание архитектуры)?

– как проверить, достигнута ли цель (варианты тестирований, критерии оценки)? [6, c. 43].

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

Требования к ТЗ на разработку программного обеспечения.

Приведем минимальные требования, достаточные для ТЗ, в соответствии с которыми оно должно:

– полно, четко (инструкционно, без лишних слов и возможностей разночтения) и структурировано описывать разрабатываемый программный продукт (как должно выглядеть ПО, как и с чем работать, каким требованиям должно отвечать) и процесс его разработки, чтобы у архитектора не возникло вопросов по реализации ПО;

– исключить противоречивые сведения;

– быть юридически точно оформленным (согласно ГОСТу), так как наряду с контрактом и прочими документами ТЗ приобретет юридическую силу.

В техническом задании должны содержаться:

– общие данные по проекту (название продукта, категория пользователей и назначение использования);

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

– детальный план работ, содержащий перечень этапов и сроки по каждому из них;

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

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

– требования к документации, содержащей описание процесса и результатов разработки.

В составе ТЗ важно уделить внимание описаниям:

1) конкретных деталей:

– пользователей программного продукта (их роли, права и функции);

– алгоритмов обработки данных;

– перечня закрытых и открытых протоколов;

– требований к безопасности данных в ходе всего жизненного цикла;

– списка используемых в разработке компонентов (свободных, платных);

2) примеров:

– аналогов, интегрируемых систем с указанием ссылок на них;

– типичных сценариев взаимодействия системы с пользователем;

– входящих данных и форматов данных взаимодействия подсистем (таблиц, баз, страниц и др.);

– исходящих данных (видов отчетов и экспортируемых файлов);

3) надежности и производительности:

– уровней нагрузки системы (день, месяц, максимальный);

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

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

2.2 Этапы проектирования базы данных

Процесс проектирования базы данных делится на следующие этапы:

1) инфологическое проектирование базы данных;

2) изложение требований к той операционной обстановке, в которой планируется использование информационной системы;

3) определение с СУБД и другого программного обеспечения;

4) логическое проектирование базы данных;

5) физическое проектирование базы данных;

6) инфологическое проектирование [5, c. 89].

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

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

Существует 3 основных подхода к созданию инфологической модели предметной области:

– функциональный подход реализует принцип «от задач», используется при известных функциях комплекса задач или группы лиц, с целью обслуживания чьих информационных потребностей создается база данных;

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

– проектирование с использованием метода «сущность-связь», который является комбинацией функционального и предметного подхода.

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

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

Определяют атрибуты каждой сущности, которые делятся на:

– описательные и идентифицирующие;

– простые и составные;

– основные и производные;

– однозначные и многозначные.

Для атрибута указывается его название, тип данных и описываются ограничения целостности – множество значений, которые он может принимать. Затем определяются связи внутри локального представления, каждая из которых определяется именем, обязательностью (обязательные и факультативные), степенью и типом (1:1, 1:М, М:М).

Обратим внимание, что обязательные связи выделяют двойной линией (рисунок 1).

Рисунок 1 – Связи внутри локального представления

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

Например, связь между отделом и сотрудниками, работающими в нем – бинарная. А связь ЭКЗАМЕН между дисциплиной, студентом и преподавателем – тернарная (рисунок 2).

Рисунок 2 – Связь между отделом и сотрудниками

После создания локальных представлений выполняют их объединение. При объединении нужно определить и устранить все противоречия, которое приводит к необходимости возврата на этап моделирования локальных представлений [9, c. 212].

Определение требований к операционной обстановке.

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

Выбор СУБД и другого программного обеспечения.

Выбор СУБД принципиально влияет на проектирование базы данных. На практике разработчики руководствуются несколькими важнейшими критериями, среди которых:

– модель данных, поддерживающийся данной СУБД, ее соответствие потребностям предметной области;

– производительность системы;

– функциональные возможности для последующего развития информационной системы;

– оснащенность системы инструментарием для администрирования данными;

– надежность и удобство эксплуатации СУБД;

– стоимость СУБД и возможного дополнительного программного обеспечения.

Логическое проектирование БД.

На данном этапе ведется разработка логической структуры базы данных, которая соответствует логической модели предметной области, что существенно зависит от типа модели данных, которая поддерживается данной СУБД.

В результате строятся схемы базы данных концептуального и внешнего уровней архитектуры, которые составлены на языке определения данных DDL, поддерживаемом выбранной СУБД.

Физическое проектирование БД.

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

Одним из важнейших моментов проектирования базы данных является разработка средств защиты базы данных, которая делится на:

– защиту от сбоев – применяется резервное копирование;

– защиту от несанкционированного доступа – для доступа к данным пользователю предоставляется соответствующее право доступа.

В заключение главы можно сделать следующие выводы:

Проектированием программного обеспечения является процесс создания проекта программного обеспечения (ПО), кроме того, под проектированием ПО понимают дисциплину, изучающую методы проектирования. Проектирование программного обеспечения представляет собой частный случай проектирования процессов и продуктов.

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

Процесс проектирования базы данных делится на следующие этапы: инфологическое проектирование базы данных; изложение требований к той операционной обстановке, в которой планируется использование информационной системы; определение с СУБД и другого программного обеспечения; логическое проектирование базы данных; физическое проектирование базы данных; инфологическое проектирование.

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

Заключение

По результатам проведенного исследования можно сделать следующие выводы:

Список использованных источников

Астапчик Н.И. Основы алгоритмизации и программирования: учебно-методическое пособие / Н.И. Астапчик, В.В. Пенкрат. – М.: Кнорус, 2018. – 182 c.
Банк В.Р. Автоматизированные информационные технологии в экономике: учебник / В.Р. Банк, В.С. Зверев. – Астрахань: Изд-во АГТУ, 2015. – 260 с.
Батин Н.В. Основы программирования: пособие / Н.В. Батин. – Минск: ИВЦ Минфина, 2019. – 89 c.
Гаспариан М.С. Информационные системы: учебник / М.С. Гаспариан. – М.: МЭСИ, 2017. – 33 с.
Дигрис А.В. Прикладное программирование: пособие / А.В. Дигрис. – Минск: БГУ, 2019. – 193 c.
Железко Б.А. Технологии программирования: учебное пособие / Б.А. Железко, Е.Г. Новицкая, Г.Н. Подгорная. – Минск: РИПО, 2017. – 99 с.
Молоков К.А. Основы информатики и программирование: учебное пособие / К.А. Молоков. – М.: Проспект: Дальневосточный федеральный университет, 2018. – 220 с.
Морозов В.В. Прикладной анализ и программирование: пособие / В.В. Морозов. – М.: Юрайт, 2016. – 246 с.
Расолько Г.А. Теория и практика программирования: учебное пособие / Г.А. Расолько, Ю.А. Кремень. – М.: Проспект, 2015. – 446 с.
Ролич О.Ч. Технологии программирования: курс лекций / О.Ч. Ролич. – Минск: БГУ, 2018. – 144 с.
Трофимова В.В. Информационные системы и технологии в экономике и управлении: учебник / В.В. Трофимов. – М.: Юрайт-Издат, 2015. – 521 с.
Труханович Т.Л. Основы алгоритмизации и программирования: учебное пособие / Т.Л. Труханович, О.П. Рябычина. – М.: Юрайт, 2017. – 211 с.