Общие особенности кадровой стратегии организаций бюджетной сферы (Этапы создания программного обеспечения)

Содержание:

Введение

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

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

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

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

Задачи исследования: изучить:

Модели жизненного цикла ПО

Этапы жизненного цикла ПО

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

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

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

Общие сведения

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

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

• требуемую пропускную способность системы;

• требуемое время реакции системы на запрос;

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

• простоту эксплуатации и поддержки системы;

• требуемую безопасность.

Производительность является главным фактором, который определяет эффективность системы. Хорошее проектное решение — основа высокопроизводительной системы.

Проектирование информационных систем охватывает три основные области:

• проектирование объектов данных, которые будут реализованы в базе данных;

• проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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

Долгое время процесс разработки ПО осуществлялся в соответствии с методиками, наработанными в инженерной области, — стандартная практика поэтапного создания продукта, начиная с составления спецификаций и заканчивая поставкой заказчику. Существуют стандарты ГОСТ (Россия) и ISO (Европа, Россия), CMM (Capability Maturity Model — распространен в США), регламентирующие данный процесс.

1.2. Общие принципы разработки программ

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

Частотный принцип. Принцип основан на выделении в алгоритмах и данных особых групп по частоте использования. Для действий, наиболее часто встречающихся при работе программ, создаются условия их быстрого выполнения. К часто используемым данным обеспечивается наиболее быстрый доступ. «Частые» операции стараются делать более короткими. Следует отметить, что лишь не более 5 % операторов программы оказывают ощутимое влияние на скорость выполнения программы. Этот факт позволяет значительную часть операторов программы кодировать без учета скорости вычислений, обращая основное внимание при этом на «красоту» и наглядность текстов.

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

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

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

Принцип функциональной избыточности. Этот принцип учитывает возможность проведения одной и той же работы различными средствами. Особенно важен учет этого принципа при разработке пользовательского интерфейса для выдачи одних и тех же данных разными способами вызова из-за психологических различий в восприятии информации [5].

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

1.3 Жизненный цикл программного обеспечения 

Известны несколько основных моделей жизненного цикла ПО.

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

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

Требования к проекту являются определяющими при выборе подхода к циклу разработки. В данной статье мы рассмотрим основные методологии в разработке ПО [7].

Каскадная или водопадная модель (Waterfall model)

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

Плюсы:

все стадии проекта выполняются в строгой последовательности;

строгость этапов позволяет планировать сроки завершения всех работ и соответствующие ресурсы (денежные и человеческие);

требования остаются неизменными в течение всего цикла.

Минусы:

сложности при формулировке четких требований и невозможность их изменения;

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

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

Рисунок 1.1 Каскадная модель

V-образная модель (V-model)

Данная модель стала последователем каскадной модели, так как с ее помощью можно устранить недостатки, которые были ранее [3].

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

Плюсы:

строгая этапизация;

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

усовершенствованный тайм-менеджмент.

Минусы:

невозможность адаптироваться к измененным требованиям заказчика;

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

нет действий, направленных на анализ рисков.

 Рисунок 1.2 V-образная модель

Инкрементная модель (Incremental model)

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

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

Плюсы:

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

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

привыкание заказчика к новой технологии происходит постепенно.

Минусы:

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

при постоянных изменениях структура системы может быть нарушена;

сроки сдачи системы могут быть затянуты из-за ограниченности ресурсов (исполнители, финансы).

  Рисунок 1.3 Инкрементная модель модель

Спиральная модель (Spiral model)

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

Плюсы:

управлению рисками уделяется особое внимание;

дополнительные функции могут быть добавлены на поздних этапах;

есть возможность гибкого проектирования.

Минусы:

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

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

более применима для больших проектов.

   Рисунок 1.4 Спиральная модель

Гибкая модель (Agile model)

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

Плюсы:

быстрое принятие решений за счет постоянных коммуникаций;

минимизация рисков;

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

Минусы:

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

сложно планировать процессы, так как требования постоянно меняются;

редко используется для реализации больших проектов.

    Рисунок 1.5 Гибкая модель

Скрам (Scrum)

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

Роли в методологии (Scrum Master, Product Owner, Team) позволяют четко распределить обязанности в процессе разработки. За успех Scrum в проекте отвечает Scrum Master и является связующим звеном между менеджментом и командой. За разработку продукта отвечает Product Owner, который также ставит задачи и принимает окончательные решения для команды.

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

Плюсы:

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

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

самостоятельная и самоорганизованная команда.

Минусы:

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

невозможно спланировать точную дату завершения, так как всё уточняется по результатам предыдущего спринта;

заказчики не всегда могут понять суть данной методологии и необходимо потратить время на “ликбез”.

Рисунок 1.6 Скрам (Scrum)

1.4 Стандарты жизненного цикла ПО

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

Среди наиболее известных стандартов можно выделить следующие:

ГОСТ 34.601-90 - распространяется на автоматизированные системы и устанавливает стадии и этапы их создания. Кроме того, в стандарте содержится описание содержания работ на каждом этапе. Стадии и этапы работы, закрепленные в стандарте, в большей степени соответствуют каскадной модели жизненного цикла.

ISO/IEC 12207:1995 - стандарт на процессы и организацию жизненного цикла. Распространяется на все виды заказного ПО. Стандарт не содержит описания фаз, стадий и этапов.

CustomDevelopmentMethod(методика Oracle) по разработке прикладных информационных систем - технологический материал, детализированный до уровня заготовок проектных документов, рассчитанных на использование в проектах с применением Oracle. Применяется CDM для классической модели ЖЦ (предусмотрены все работы/задачи и этапы), а также для технологий "быстрой разработки" (Fast Track) или "облегченного подхода", рекомендуемых в случае малых проектов.

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

MicrosoftSolutionFramework(MSF)сходна с RUP, так же включает четыре фазы: анализ, проектирование, разработка, стабилизация, является итерационной, предполагает использование объектно-ориентированного моделирования. MSF в сравнении с RUP в большей степени ориентирована на разработку бизнес- приложений.

ExtremeProgramming(XP).Экстремальное программирование (самая новая среди рассматриваемых методологий) сформировалось в 1996 году. В основе методологии командная работа, эффективная коммуникация между заказчиком и исполнителем в течение всего проекта по разработке ИС, а разработка ведется с использованием последовательно дорабатываемых прототипов. 

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

2.1 Общая характеристика этапов

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

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

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

Чем раньше будут обнаружены ошибки или выявлен неправильных подход в реализации того или иного действия, тем цена этих ошибок будет меньше. Иными словами, в зависимости от этапа обнаружения ошибки ее цена может меняться от 10 до 100 раз. Например, если на самом начальном этапе цена исправления ошибки будет равняться 100 рублей, то на этапе тестирования она может вылиться в 10000. Поэтому этапы разработки ПО очень важны, и разработчик должен их соблюдать и попытаться донести это видение до менеджеров, которым всегда нужен только результат. Так как они или отводят на это слишком мало времени или и вовсе не считают это необходимым, например, зачем при программировании вырабатывать какие-то требования или что-то там проектировать [8].

Основные этапы разработки ПО

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

Этап 1 – Определение проблемы

Этап 2 – Выработка требований

Этап 3 – Создание плана разработки

Этап 4 – Разработка архитектуры системы или высокоуровневое проектирование

Этап 5 – Детальное проектирование

Этап 6 – Кодирование и отладка

Этап 7 – Тестирование компонентов

Этап 8 – Интеграция компонентов

Этап 9 – Тестирование всей системы

Этап 10 – Сопровождение, внесение изменений, оптимизация

2.2 Описание этапов создания программного обеспечения

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

Этап 1 – Определение проблемы

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

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

Определение проблемы – это фундамент всего процесса программирования!

Этап 2 – Выработка требований

Что такое требования и зачем их нужно выработать?

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

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

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

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

Этап 3 – Создание плана разработки

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

Этап 4 – Разработка архитектуры системы или высокоуровневое проектирование

Архитектура системы – это каркас программы, это высокоуровневое проектирование программы.

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

Архитектура системы обычно включает:

Общее описание системы;

Основные компоненты;

Формат и способ хранения данных;

Специфические бизнес-правила;

Способ организации пользовательского интерфейса;

Подход к безопасности системы;

Оценки производительности;

Возможности масштабирования;

Моменты, связанные с интернациональностью, т.е. будет ли система интернациональной.

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

Этап 5 – Детальное проектирование

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

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

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

Этап 6 – Кодирование и отладка

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

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

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

Этап 7 – Тестирование компонентов

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

Этап 8 – Интеграция компонентов

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

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

Создание справочной системы:

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

Кроме справочной информации справочная система содержит необходимые инструкции по инсталляции программы. Обычно их представляют в виде файла Readme разных форматов: *.doc, *.txt, *.htm. Более подробно рассматриваемый этап разработки программы будет описан позже.

Рисунок 2.1 Создание установочного диска (CD-ROM):

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

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

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

Этап 9 – Тестирование всей системы

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

Этап 10 – Сопровождение, внесение изменений, оптимизация

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

Заключение

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

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

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

Список литературы

1. Автоматизация проектирования вычислительных систем. Языки, моделирование и базы данных / ред. М. Брейер. - М.: Мир, 2015. - 463 c.
2. Гвоздева, В. А. Основы построения автоматизированных информационных систем / В.А. Гвоздева, И.Ю. Лаврентьева. - М.: Форум, Инфра-М, 2016. - 320 c.
3. Ипатова, Э. Р. Методологии и технологии системного проектирования информационных систем / Э.Р. Ипатова, Ю.В. Ипатов. - М.: Флинта, 2015. - 256 c.
4. Мидоу, Ч. Анализ информационных систем / Ч. Мидоу. - М.: Прогресс, 2016. - 400 c.
5. Паттерсон, Д. Архитектура компьютера и проектирование компьютерных систем / Д. Паттерсон, Дж. Хеннесси. - М.: Питер, 2015. - 784 c.
6. Шастова, Г. А. Выбор и оптимизация структуры информационных систем / Г.А. Шастова, А.И. Коёкин. - М.: Энергия, 2015. - 256 c.
7. Шоу, А. Логическое проектирование операционных систем / А. Шоу. - М.: Мир, 2016. - 360 c.
8. Юркевич, Е. В. Введение в теорию информационных систем / Е.В. Юркевич. - М.: Группа ИДТ, 2014. - 272 c.