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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

ГЛАВА 1 ОСНОВЫ ПРОЕКТИРОВАНИЯ ПРОГРАММ

1.1 Понятие базы данных и основы проектирования программ

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

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

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

«Паттерн является структурированным описанием задачи, с которой часто сталкиваются в процессе проектирования, ее наиболее подходящее решение и, как результат, рекомендации по применению этого решения в различных ситуациях. Удачно определенный паттерн позволяет пользоваться этим решением вновь. Также паттерн можно определить как описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте» [1].

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

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

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

Первый критерий классификации - цель, т.е. основная функция паттерна для реализации рассматриваемой системы. В связи с этим выделяют:

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

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

Для реализации любой задачи можно совмещать использование разных паттернов.

1.2 Разработка интерфейса

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

• единообразное отображение объектов;
• однообразная работа с объектами на уровне БД, в том числе: добавление, изменение, просмотр, удаление, поиск;
• схожая работа с объектами на уровне графического интерфейса.

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

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

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

Рис. 1.1 – Схема реализации с помощью патентов

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

Паттерн абстрактная фабрика используется, когда [1]:

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

В качестве первого примера реализации паттерна «Абстрактная фабрика» можно привести класс «AEntity», который является абстракцией объекта в БД. Этот класс играет роль абстрактного продукта в реализации паттерна. Класс содержит атрибуты: значение идентификатора объекта и флаг необходимости сохранения объекта в БД, а также их методы-обозреватели, которые возвращают соответствующее значение. Данный класс является родительским для всех классов, соответствующих объектам БД. Каждый объект БД должен обладать идентификатором, который определен в БД. В производных классах объектов БД - в конкретном рассматриваемом данном случае это классы «Шаблон» и «Отчет» - добавляются атрибуты, характеризующие эти объекты, а также методы- модификаторы и методы-обозреватели для работы с ними. Методы-модификаторы изменяют значение атрибута объекта и имеют только один аргумент - новое значение атрибута. Методы-обозреватели возвращают текущее значение атрибута объекта и не имеют аргументов. Часто названия этих методов начинаются с Get и Set соответственно. Классы «Шаблон» и «Отчет» играют роли конкретных объектов в реализации паттерна и относятся к разным семействам продуктов.

Следующий представитель данного паттерна - это класс «ADBLayer», который определяет набор базовых виртуальных функций для выполнения простых операций над объектом на уровне БД. Он также играет роль абстрактного продукта в реализации паттерна. Класс содержит методы добавления, удаления, изменения записей, а также выбора объектов по фильтру. При этом все функции класса являются абстрактными, т.е. их требуется определять в классах-наследниках: «TemplateDBLayer» и «PaperDBLayer», поскольку действия по отображению объектов на записи таблиц БД весьма конкретны. Классы «TemplateDBLayer» и «PaperDBLayer» играют роль конкретных объектов в реализации паттерна и относятся к разным семействам продуктов. В родительском классе «ADBLayer» в качестве входного параметра имеющихся функций выступает указатель на абстрактный объект класса «AEntity». В наследуемых классах при реализации функций используется уже конкретный объект («Шаблон» или «Отчет»), что достигается с помощью приведения типов.

Последний пример реализации данного вида паттерна - это класс «AFabric», являющийся абстрактной фабрикой. Класс содержит набор виртуальных функций для создания семейства абстрактных продуктов. Все функции являются абстрактными, и их требуется переопределять. Наследуемыми классами являются «TemplateFabric» и «PaperFabric», которые играют роль конкретных фабрик. Каждый из них обеспечивает создание конкретного семейства продуктов. В данном случае это семейства шаблонов и отчетов. Функция абстрактного класса «Создать сущность» в качестве выходного параметра возвращает указатель на абстрактный объект «AEntity», а в классах- наследниках возвращается объект конкретного класса. Аналогично реализована функция «Создать слой БД». Функция «Создать форму работы с объектом» получает в качестве параметра указатель на абстрактный объект класса «AEntity». Функция «Создать форму поиска» не использует в качестве параметров абстрактные классы, однако ее надо полностью переопределять из-за того, что требуется вызывать разные формы поиска, которые значительно отличаются от объекта к объекту из-за того, что все объекты отличаются по количеству и содержанию полей данных.

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

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

В данном паттерне выполняется правило: «Создавай объекты в отдельной операции, чтобы подклассы могли подменить способ их создания» [1]. Данное правило дает возможность изменять классы объектов так, как необходимо.

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

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

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

В представленной системе классов фабричные методы используются для создания объектов, используемых в шаблоне графического интерфейса. Класс «AGui», который содержит шаблоны алгоритмов для работы с объектами БД, обращается к фабрике для создания конкретного продукта. Фабричные методы абстрактной фабрики создают и возвращают конкретные продукты в зависимости от того, какая именно фабрика используется. При этом вызывающие объекты не знают ни конкретный класс фабрики, ни конкретный класс получаемых продуктов.

Кроме абстрактной фабрики фабричные методы определены в классе работы с БД «ADBLayer», в котором создают и возвращают фильтр для поиска по конкретной таблице БД, и в классе «AGui», в котором используются для создания объекта на основе выбранной по виджету таблицы записи. В обоих случаях базовые классы определяют интерфейс фабричных методов по созданию требуемых объектов, а производные классы реализуют их по своим потребностям.

1.3 Паттерн Стратегия

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

Паттерн стратегия используется, когда:

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

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

Атрибутами данного класса являются виджет таблицы, указатель на объект фабрики «AFabric» и список объектов, извлеченных из БД - List<AEntity*>. Соответственно для каждого атрибута реализованы методы-обозреватели, а их значения устанавливаются в конструкторе класса. Объекты фабрики играют роли конкретных стратегий и через фабричные методы позволяют создавать конкретные объекты работы с БД, которые использует контекст «AGui».

Кроме упомянутых функций в «AGui» реализован также полный набор операций для работы с объектами и записями объектов на форме: данные отображаются в таблице списком или каждый объект можно посмотреть в отдельной форме. Так, были реализованы функции «Добавление сущности», «Редактирование сущности», «Просмотр сущности», «Удаление записи», «Поиск записей» и «Создание фильтра поиска». Данные операции реализованы в классе «AGui» таким образом, что они оперируют абстрактными объектами ADBLayer, AFabric и AEntity.

Класс «ADBLayer» и наследуемые от него «TemplateDBLayer» и «PaperDBLayer» играют роли абстрактной и конкретных стратегий. Класс «ADBLayer» объявляет общий для всех поддерживаемых алгоритмов интерфейс. Однако, в нашем случае, данный класс определяет лишь набор функций, а реализация каждого алгоритма находится уже в конкретном классе. Это происходит из-за того, что алгоритмы значительно отличаются по используемым значениям и объектам. Класс «AGui» пользуется интерфейсом для вызова конкретного алгоритма, определенного в классе «TemplateDBLayer» или «PaperDBLayer».

Паттерн Шаблонный метод позволяет сохранять основную структуру алгоритма при переопределении некоторых функций в классах-наследниках.

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

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

Шаблонные методы вызывают операции следующих видов [1]:

• конкретные операции (либо из класса ConcreteClass, либо из классов клиента);
• конкретные операции из класса AbstractClass (т.е. операции, полезные всем подклассам);
• примитивные операции (т.е. абстрактные операции);
• фабричные методы (паттерн фабричный метод);
• операции-зацепки (hook operations), реализующие поведение по умолчанию, которое может быть расширено в подклассах.

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

Рассмотрим реализацию данного паттерна на примере класса «AGui» и классов-наследников «TemplateGui» и «PaperGui». AGui - абстрактный класс, который определяет операции, замещаемые в конкретных подклассах для реализации шагов алгоритма. Также он реализует шаблонный метод, определяющий скелет алгоритма. Шаблонный метод вызывает примитивные операции, а также операции, определенные в классе «AGui». В качестве примитивных операций выступают функции работы с сущностями: добавление, изменение, просмотр, поиск, которые единообразны для всех объектов.

Конкретные классы «TemplateGui» и «PaperGui» реализуют операции, выполняющие шаги алгоритма способом, который зависит от подкласса. В нашем примере существует только одна такая операция - «Отображение в таблице», которая полностью зависит от текущего объекта и реализована в конкретных классах.

Исходя из диаграммы классов, изображенной на рисунке, можно выделить следующие семейства абстрактных продуктов: это классы AEntity, ADBlayer, AFabric и AGui. Данные объекты входят в иерархии связанных классов. Так, объект AEntity находится на самом нижнем уровне, но для полноценной работы программы требуется его использование во всех остальных абстрактных классах. В качестве конкретных продуктов выступают классы-наследники от каждого абстрактного продукта, а именно объекты Шаблон и Отчет, TemplateDBlayer и PaperDBlayer, TemplateFabric и PaperFabric, TemplateGui и PaperGui соответственно.

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

ГЛАВА 2 ЭТАПЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

2.1 Цикл разработки программного обеспечения

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

Рис. 2.1 – Цикл разработки ПО

Подготовка — сбор и обработка требований. Предварительное планирование этапов работ, сроков, ресурсов и стоимости.

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

Создание.

Дизайн — получение графических макетов, визуальных форм, разработка интерфейсов. Создание индивидуального стиля.

Кодирование — получение исходного кода.

Тестирование — проверка программы на соответствие всем предъявляемым к ней требованиям.

Документирование — получение возможности передачи накопленных знаний другим разработчикам.

Поддержка.

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

Сопровождение — исправление выявленных ошибок, поддержка пользователей.

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

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

Рис. 2.2 – Планирование разработки ПО

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

Разработка — практическое решение задач для создания приложения.

Тестирование — аккумулирование итоговой информации в целях контроля выполнения задач спринта. Анализ ошибок и причин отклонений от плана. Поиск путей исправления оплошностей.

Демонстрация — представление заказчику готовой части ПО.

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

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

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

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

2.2 Этапы создания программ

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

1. Системное программное обеспечение является общим, не выполняющим конкретных специальных задач, этим оно и отличается от прикладного.

2. Прикладное ПО предназначено для непосредственного взаимодействия с пользователем и решает конкретно поставленные задачи.

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

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

Безусловно, начинается оно с возникших потребностей пользователя. Каждая компания имеет свою специфику работы и нуждается в индивидуальном подходе. Специально произведенная разработка программ, позволит значительно сэкономить время сотрудникам фирмы на обработке отдельной информации и внесении дополнительных данных. Это могут быть складские программы, программы для произведения сложных вычислений или элементарной записи телефонов клиентов для регулярной рассылки рекламной информации. Воспользовавшись услугами хорошего ПО, можно не только сэкономить время, но и деньги с заработной платы и налогов уже не требующегося сотрудника. ПО, в данном случае, оказывает услугу не только по экономии, но и избавляет работодателя от такого понятия как«человеческий фактор». Система не спит, не ест, не курит, не требует отпуск и не пьет чай — она всегда на месте и готова трудиться во благо предприятия. Если она вышла из строя, достаточно пригласить к ней программиста, и спустя пару часов система снова готова усердно работать. Чтобы воспользоваться услугами этой прекрасной барышни, достаточно найти сайт программного обеспечения и набрать номер телефона. Люди работающие в этой сфере точно знают что нужно клиенту и как добиться его абсолютного удовлетворения. Вам детально расскажут о всех возможностях и наверняка поведают много нового о современном ПО, ведь новшества внедряются ежесекундно[6;15].

Чтобы полностью удовлетворить все потребности заказчика предоставляя услуги по программному обеспечению, необходимо изучить особенности деятельности кампании для которой создается ПО. Важно узнать требования и пожелания непосредственных будущих пользователей программы, вникнуть в суть работы и понять ее досконально. Благодаря такому тщательному подходу, программист сможет не только создать представляемую вами версию программы, но и предложить ее в усовершенствованном варианте. Значимый плюс опытных мастеров программирования, что они уже не однажды сталкивались с проблемами и запросами аналогичными вашим и знают «каксделать лучше». Далее проводится предварительное планирование работ. Определив их, устанавливаются сроки по выполнению и определяются необходимые ресурсы для осуществления поставленных задач. На основании известных данных исчисляется общая стоимость работ по разработке программного обеспечения.

Проектирование ПО

На данной стадии разработки автоматизированной системы составляются технические задания и создаются спецификации, излагаются планы по проведению работ в документальном виде. Проводится анализ составленного плана работ. Какие процессы и вычисления должны быть видимыми, а какие могут производиться скрыто. К каким данным необходим доступ для внесения корректировок, а какие могут производиться только автоматически и даже нуждаются в этом. Кроме того, в зависимости от сложности создаваемой программы, могут применяться различные методы проектирования. Если программа не слишком сложна, то для нее вполне подойдет «ручное» проектирование. Если же система является продуктом сложным, то без автоматизации, даже на данном этапе — не обойтись. В основном, проектированию подвергается архитектура ПО, устройство его компонентов и пользовательские интерфейсы. Чтобы наглядно описать предполагаемую систему, используют при проектировании ER-диаграммы, блок-схемы, DFD-диаграммы, UML-диаграммы и макеты[7;124].

Что включает в себя создание программного обеспечения

1. Создание дизайна.

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

2. Кодирование ПО.

Само по себе понятие кода, представляет собой набор знаков или символов предназначенных для записи или передачи конкретных, заранее обусловленных понятий. Как известно, видимое на мониторе изображение это лишь передаваемый визуальный объект, на самом деле программы пишутся и состоят из цепочек чисел, букв, символов и значимых пробелов. Чтобы немного приблизится к понятию, достаточно нажать на правую кнопку мыши и выбрать«просмотр кода элемента». Именно так или приблизительно так, выглядят страницы сайтов и программ в момент своего появления на свет. Вот именно такую работу программиста, подразумевает под собой понятие «КодированиеПО». Задача практически невыполнимая для рядового обывателя, но интересная и простая для мастера своего дела. Нужно ли говорить, что опыт при выполнении подобной задачи дело далеко не последнее.

3. Тестирование программного обеспечения.

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

— демонстрация программы заказчику для окончательного ее утверждения;

— проверка программы на наличие ошибок, или как их называют в народе«багов».

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

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

4. Документирование ПО в процессе разработки.

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

4.1. Чем полезно документирование:

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

4.1.2. В случае появления ошибки на определенном участке системы, будет гораздо удобней, если этот участок будет иметь свое название. Так можно быстро донести до коллег информацию и она будет мгновенно принята к сведению. Одним словом, «раздел № 26», звучит намного понятней, чем «вчеранедоделанная Ваней часть системы».

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

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

4.2. Рекомендации по документированию программного обеспечения:

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

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

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

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

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

2.3 Поддержка программного обеспечения

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

1. Внедрение ПО.

Выполнен договор, разработка программного обеспечения окончена успешно. Что следует за этим? Радостное пользование новым ПО сотрудниками организации. Чтобы пользование на самом деле было радостным и приятным, необходимо обучить работников. Важно разъяснить каждому, как и что делать нужно, а как и что ни в коем случае нельзя. На первых порах внедрения, сами разработчики с настороженностью пользуются своим детищем и просят сообщать обо всех странных внезапно объявившихся процессах. Фактически, первые недели между работниками компании-заказчика и фирмы-исполнителя, налаживаются партнерские взаимоотношения. Пройдя процесс успешного обучения пользователем и избавившись от сомнений появления возможных недочетов разработчиком, их общение в скором времени сойдет на нет. Но и окончательно вычеркивать из своей жизни существование программиста не стоит. Людям свойственно ошибаться, может произойти сбой из-за механической поломки или по другим причинам — именно в таком случае снова на пороге появится программист. Последняя ситуация как раз относится к следующему пункту статьи — сопровождение.

2. Сопровождение ПО.

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

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

2.1. Кого могут заинтересовать услуги по сопровождению ПО?

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

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

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

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

Чем полезно сотрудничество с компанией создающей ПО

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

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

— все вопросы по IT системам, вы сможете адресовать сопровождающей вашу компанию фирме. Это значительно быстрее поможет решать проблемы сотрудников с техникой и сэкономит ваши деньги;

— профессионалы в сфере программных систем, максимально обезопасят ваши системы от рисков разного рода. Взломы и неумышленное нанесение вреда — будут маловероятными посетителями;

— все сложности станут разрешаться в считанные минуты, ведь предоставление своевременных услуг — это зачастую пункт в договоре на сопровождение ПО;

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

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

Распространенные услуги реализации проектов разработки программного обеспечения

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

1. Корпоративные веб решения, которые зачастую включают в себя:

— консалтинг и бизнес-анализ;

— разработка заказных CRM, ERP и прочих решений;

— интеграция и внедрение модулей и компонентов систем управления(планирование ресурсов, ERP-системы, CRM-системы);

— настройка и развертывание корпоративной системы;

— разработка и модернизация и нового функционала;

— перенос процессов и информации;

— интеграция корпоративной системы с другими IT системами предприятия;

— обслуживание и поддержка решения;

2. Автоматизация бизнес-процессов это:

— в банковской сфере автоматизация бизнес процессов, телекоммуникационном секторе и торговле;

— разработка корпоративных шин данных (ESB) и интеграционных решений;

— разработка ERP систем корпоративных;

— разработка порталов корпоративных, CRM;

— разработка приложений мобильных;

— разработка инструментов визуализации и анализа данных;

3. Разработка мобильных приложений включает в себя:

— работа в приложениях с банками и финансами;

— получение телекоммуникационных услуг;

— приложения по обучению и маркетингу;

— приложения для торговли и коммерции;

— автомобильные и транспортные приложения;

— приложения по здравоохранению;

— энергетика;

4. ИТ консалтинг — предоставляет возможность проанализировать имеющиеся на современном рынке технологии, инструменты и продукты. Анализ так же ведется в плане рациональности их использования в избранном проекте. То есть, данная программа существует для отбора программ и сопутствующих инструментов для их создания и использования. С целью определения«пригодности» каждой, отслеживаются следующие позиции:

— предъявленные бизнес требования к системе;

— требования к системе технические;

— архитектура самой системы;

— сроки и план реализации.

5. Услуги Research and Development.

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

6. Разработка дизайна.

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

— проработку стандартных элементов на экранах приложения и их расположение;

— по приложению пути навигации;

— подготовку стартового экрана, иконок, и подбор цветовой гаммы;

— внесение персональных новых элементов управления и отображение информации;

— подготовку набора экранов приложения.

7. Чтобы ПО было абсолютно адаптированным и качественным, его разработкой занимаются команды специалистов, выделенные специально для решения этой задачи. Люди полностью интегрируются в работу компании и прекрасно осознают поставленные цели. Сотрудничая с работниками фирмы, создают неповторимый уникальный и универсальный продукт. Это называется — выделенный центр разработки ПО.

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

ГЛАВА 3 ПОСТАНОВКА ПРОБЛЕМЫ СОЗДАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ДЛЯ ИНТЕГРИРОВАННОЙ ЛОГИСТИЧЕСКОЙ ПОДДЕРЖКИ ЦЕНТРОБЕЖНЫХ КОМПРЕССОРОВ

Центробежные компрессоры (ЦК) относятся к динамическому типу оборудования и широко распространены во многих отраслях промышленности, включая нефтедобывающую, химическую, пищевую и энергетическую. Большая область применения ЦК обусловливает наличие множества вариантов их конструкционного исполнения, что очень усложняет процесс технического обслуживания и эксплуатации этого оборудования. Надёжная и безопасная работа ЦК обеспечивается системой технического обслуживания и ремонта (ТОиР). При этом стоимость и качество осуществления ТОиР в значительной мере определяются уровнями инструментального технического обследования и ремонта и технической документацией. Большие номенклатура и объём работ технического обслуживания, включая проведение различных видов диагностики и обработки её результатов требуют выполнения значительного количества инженерно-технических расчётов и формирования множества отчётов, актов, протоколов и других видов текущей технической документации.

Упростить формирование технической документации по динамическому оборудованию, а также ускорить и повысить точность обработки результатов диагностирования при одновременном снижении затрат на эксплуатацию ЦК можно, если подойти к достижению этой цели с позиций интегрированной логистической поддержки (ИЛП) [1]. При этом для обеспечения высокого качества ИЛП центробежных компрессоров объем эксплуатационно-технических данных, непрерывно пополняемый по каждой единице оборудования на протяжении всего этапа эксплуатации, должен быть систематизирован и формализован.

Реализация ИЛП центробежных компрессоров, как сложного инженерно­технического и организационно-технологического процесса включает в себя автоматизацию решения следующих задач:

- формирование и ведение паспортно-технической документации;

- проверка характеристик технологического оборудования и устройств на соответствие требованиям нормативно-технической документации;

- планирование ремонтных работ и оформление ремонтной документации;

- оформление актов технического обследования;

- сбор статистики отказов и прогнозирование остаточного ресурса;

- анализ результатов технической диагностики.

Анализ научно-технической литературы и существующих программных средств (ПС) не выявил моделей, алгоритмов и программного обеспечения, позволяющих осуществить комплексное автоматизированное решение, перечисленных выше задач. Поэтому указанные выше задачи решаются преимущественно с помощью универсальных и не интегрированных между собой ПС, например, таких как MathCAD, Microsoft Excel, Microsoft Visio, что приводит к существенным недостаткам осуществления ИЛП, среди которых можно отметить:

- многократное дублирование операций поиска, ввода и обработки данных;

- сложность обмена информацией между различными ПС;

- высокая вероятность появления ошибок при вводе данных;

- отсутствие специализированного графического редактора для работы с картами диагностических обследований элементов ЦК (формулярами).

При этом необходимо отметить, что в настоящее время существуют различные ПС, которые позволяют сравнивать отдельные характеристики компрессоров [2-3]. Например, ПС «APRP 4.3» и «SELECT 1.1» позволяют определить коэффициенты аналитических зависимостей кривых «напор - расход», «расход - коэффициент полезного действия», «расход - мощность»; редактировать и систематизировать их для дальнейшего использования и производить подбор насосов, но не предназначена для ведения паспортной документации. Кроме этого, ПС «OLDPUMPE» является каталогом графических характеристик насосов, но не предназначена для ведения паспортной документации и анализа результатов технической диагностики. В результате анализа функциональных возможностей, специализированных ПС, применяемых в РФ и за рубежом («ТЕХНО», «АСТОР», «TRIM- PlannedMaintenanceSystem», «Global», «Лоцман: PLM», «iMaint», «SAP R3», «AutoCAD», «AutoPlantEquipment V8i», «Компас-График», «SVM-RM»,«ВИБРОБИТ», «АРМИД», «Топаз-115», «КОМПАКС», «RecipCOM» HOERBIGER), также установлено, что они позволяют решать только очень ограниченный круг задач технического облуживания и ремонта ЦК.

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

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

- предоставление структурированных актуальных данных о ЦК в графическом и численном виде;

- автоматизированный поиск необходимых данных;

- ввод и хранение в базе данных упорядоченных актуальных паспортно­технических данных о ЦК;

- обработка и хранение эксплуатационных данных о ЦК в графическом и численном виде, включая: схемы формуляров элементов компрессора, результаты вибромониторинга, технических обследований;

- осуществление расчета технических параметров центробежного компрессора.

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

Реализацию ПС по ИЛП центробежных компрессоров предлагается осуществлять с помощью следующих разработанных моделей:

- представления знаний о ЦК в виде сети фреймов [4], содержащая структурированные параметры ЦК;

- математическая для определения параметров ЦК.

Разработанная фреймовая модель представления знаний содержит в себе основные параметры необходимые для интегрированной логистической поддержки ЦК, эксплуатация которого производится на предприятии. Фреймовая модель выполнена в виде схемы, верхние уровни которой заполнены информацией, неизменной для всего класса объектов, определяемых заданным фреймом. Нижний уровень, называемый «терминалами» [5], заполняется переменными данными, характеризующие особенности отдельных объектов.

Рис. 1. ФР: Центробежный компрессор

На рис. 1 представлена общая структура разработанной фреймовой модели ЦК. Модель состоит из пяти основных информационных блоков:

1. «Основные характеристики ЦК» (рис. 2) -блок включает общую паспортно­техническую информацию о ЦК как единице оборудования.
2. «Технологические характеристики

ЦК» (рис.3) - в блоке находится информация о технологических параметрах компрессорного агрегата, включая параметры потоков и ступеней, режимов работы ЦК и компонентов рабочей среды.

1. «Конструкционные характеристики элементов ЦК» (рис. 4) - блок содержит детальную информацию о конструкционном исполнении оборудования и параметры его элементов.
2. «Эксплуатационный журнал компрессора» (рис.1) - в блоке представлены эксплуатационные данные работы компрессора.
3. «Ремонтные данные» (рис. 1) - блок содержит данные о результатах выполнения ремонтных работ.

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

m - количество типов аппаратного оформления ЦК

Рис. 2. ФР: Основные характеристики ЦК: n – количество присоединяемых к ЦК трубопроводов; m – количество типов аппаратного оформления ЦК

Рис. 3. ФР: Технологические характеристики ЦК

Использование в модели (рис. 2 к компрессору (трубопровод стороны всасывания и нагнетания, трубопроводы смазки), а связи «1-m» - наличие у ЦК дополнительного аппаратного оформления в виде нескольких вспомогательных сосудов или агрегатов (например, емкость-ресивер и фильтр).

Связи «1-n» во фрейме «Технологические характеристики ЦК» (рис. 3) позволяют учесть наличие у ЦК нескольких изолированных друг от друга потоков рабочих сред, повышение давления в каждом из которых осуществляется поэтапно в нескольких ступенях. Также модель предусматривает работу компрессора при различных режимах.

Рис. 3. ФР: Конструкционные характеристики элементов ЦК

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

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

ЗАКЛЮЧЕНИЕ

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Акулов О.А. Информатика: учебник / О.А. Акулов, Н.В. Медведев. – М.: Омега-П, 2012. – 270 с.
2. Алексеев А.П. Информатика 2014 / А.П. Алексеев. – М.: СОЛОН-ПРЕСС, 2012. – 608 с.
3. Виноградова М.В. Мазнев В. Г.. Автоматизация разработки интерфейсов взаимодействия для обмена данными с устройствами // Проблемы построения и эксплуатации систем обработки информации и управления: Сб. статей (М.) под ред. Черненького В.М. - 2014. Выпуск 5.
4. Виноградова М.В., Гжельская М.О. Технология проектирования баз данных на примере пропускной системы общежития // Проблемы построения и эксплуатации систем обработки информации и управления: Сб. статей (М.) под ред. Черненького В.М.. - 2011. Выпуск 8.
5. Вьюхин В.В. Информатика и вычислительная техника: учеб. пособие для инженерных специальностей / В.В. Вьюхин; под ред. В.Н. Ларионова. - М.: Дрофа, 2012. – 286 с.
6. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб: Питер, 2015. 368 с.
7. Гейн А.Г. Основы информатики и вычислительной техники / А.Г. Гейн. - М.: Просвещение, 2012. – 245 с.
8. Дубина О. Обзор паттернов проектирования // ЦИТФорум. 2015. URL: http://citforum.ru/SE/project/pattern/index.shtml#toc (дата обращения 16.10.2017).
9. Информатика: практикум по технологии работы на компьютере / под ред. Н.В. Макаровой. - 2-е изд. - М.: Финансы и статистика, 2012. – 384 с.
10. Л.Л. Босова, Н.И. Михайлова. – М.: Бином, 2012. – 400 с.
11. Макарова Н.В. Информатика: практикум по технологии работы на компьютере / Н.В. Макарова, С.Н. Рамин. – М.: Академия, 2015. – 384 с.
12. Макарова Н.В. Информатика: учеб. пособие для вузов / Н.В. Макарова, Н.В. Бройдо. – М.: Академия, 2012. – 768 с.
13. Могилев А.В. Информатика: учеб. пособие для вузов / А.В. Могилев, Н.И. Пак, Е.К. Хеннер; под ред. Е.К. Хеннера. - М.: Академия, 2015. – 346 с.
14. Острейковский В.А. Информатика / В.А. Острейковский. М.: Высш. шк., 2015. – 235 с.
15. Угринович Н.Д. Практикум по информатике и информационным технологиям: учеб. пособие для общеобразовательных учреждений / Н.Д. Угринович,
16. Федоров О. Шаблоны проектирования: практические примеры // Программист о программировании. 2015. URL: http://glan-saratov.ru/category/шаблоны-проектирования/ (дата обращения 18.09.2020).