Контрольная работа
по дисциплине «Методы и средства проектирования информационных систем и технологий»
Группа 1609
Студент ___________ ______ Киргизов_ ___
(подпись) Фамилия И.О.
Преподаватель ___________ А.З.Шакирова
(подпись)
Оценка _____________ Дата ____.___.2020 г.
Регистрационный № ______ дата регистрации ____.____.201__г.
Адрес электронной почты студента ___________________________________
Бугульма – 2020
Содержание
Введение. 3
1. Международный стандарт ISO/IEC 12207: 1995-08-01. 4
2. Основные понятия IDEF0. 9
3. Методологии моделирования бизнес-процессов. 17
Заключение. 21
Список использованной литературы.. 22
Введение
Современные компании и организации функционируют в условиях большого объема постоянно изменяющейся информации, которую необходимо оперативно анализировать и принимать правильные решения. Бурно развивается вычислительная техника и информационные технологии. Трудно найти сейчас компанию, не занимающуюся развитием информационных технологий. Современные руководители фирм полностью отдают себе отчет в том, что в настоящее время успешность и прибыльность компании полностью зависят в том числе, и от уровня развития IT-технологий, скорости и качества обработки информации, обоснованности и взвешенности принимаемых решений.
Требуется постоянная серьезная работа не только IT-специалистов, но и топ-менеджеров по согласованию или точнее – синхронизации всех усилий по стратегическому развитию компании и её информационных систем. Большой ошибкой является позиция руководителей компаний, которые, внедрив однажды информационную систему, перестают ею заниматься. Поэтому процесс проектирования информационных систем в настоящее время становиться обязательным. В данном случае, если этот процесс не впервые осуществляется компанией, то термин проектирование приравнивается к понятию развитие информационной системы. Этим объясняется бурное развитие технологий проектирования информационных систем (ИС) в последние годы. Прежде всего, создание CASE-технологий, которые во много сокращают сроки проектирования ИС, позволяют организовать одновременную коллективную работу, оперативно вносить изменения и быстро реагировать на изменение обстановки на предприятии.
Международный стандарт ISO/IEC 12207: 1995-08-01
Первая редакция ISO 12207 была подготовлена в 1995 г. объединенным техническим комитетом ISO/IEC JTC1 «Информационные технологии, подкомитет SC7, проектирование программного обеспечения».
По определению, ISO 12207 — базовый стандарт процессов жизненного цикла ПО, ориентированный на различные виды ПО и типы проектов автоматизированных систем, в которых ПО является одной из составных частей. Стандарт определяет стратегию и общий порядок в создании и эксплуатации ПО, он охватывает жизненный цикл от концептуализации идей до завершения проекта. Целесообразность совместного использования стандартов на информационные системы и на ПО обусловливается одним из положений ISO 12207, согласно которому процессы, используемые во время жизненного цикла ПО, должны быть совместимы с процессами, используемыми во время жизненного цикла автоматизированной системы.
Согласно ISO 12207, система — это объединение одного или нескольких процессов, аппаратных средств, программного обеспечения, оборудования и людей для обеспечения возможности удовлетворения определенных потребностей или целей.
В отличие от Oracle COM стандарт ISO 12207 в равной степени ориентирован на организацию действий каждой из двух сторон: поставщика (разработчика) и покупателя (пользователя); он может быть применен и в том случае, когда обе стороны — из одной организации.
В стандарте ISO 12207 не предусмотрено каких-либо этапов (фаз или стадий) жизненного цикла информационной системы. Данный стандарт определяет лишь ряд процессов, причем по сравнению с Oracle CDM стандарт ISO 12207 состоит из гораздо более крупных обобщенных процессов: приобретение, поставка, разработка и т. п. Несколько утрируя, можно сказать, что один процесс ISO 12207 сопоставим со всеми процессами Oracle CDM вместе взятыми.
Согласно ISO 12207, каждый процесс подразделяется на ряд действий, а каждое действие — на ряд задач.
Очень важной особенностью ISO 12207 по сравнению с CDM является то, что каждый процесс, действие или задача инициируются и выполняются другим процессом по мере необходимости, причем нет заранее определенных последовательностей (естественно, при сохранении логики связей по исходным сведениям задач и т. п.).
Основные и вспомогательные процессы жизненного цикла.
В стандарте ISO 12207 описаны пять основных процессов жизненного цикла программного обеспечения:
- процесс приобретения определяет действия предприятия-покупателя, которое приобретает информационную систему, программный продукт или службу программного обеспечения;
- процесс поставки определяет действия предприятия-поставщика, которое снабжает покупателя системой, программным продуктом или службой программного обеспечения;
- процесс разработки определяет действия предприятия-разработчика, которое разрабатывает принцип построения программного изделия и программный продукт;
- процесс функционирования определяет действия предприятия-оператора, которое обеспечивает обслуживание системы в целом (а не только программного обеспечения) в процессе ее функционирования в интересах пользователей. В отличие от действий, которые определяются разработчиком в инструкциях по эксплуатации (эта деятельность разработчика предусмотрена во всех трех рассматриваемых стандартах), определяются действия оператора по консультированию пользователей, получению обратной связи и др., которые он планирует сам и берет на себя соответствующие обязанности;
- процесс сопровождения определяет действия персонала, обеспечивающего сопровождение программного продукта, то есть управление модификациями программного продукта, поддержку его текущего состояния и функциональной пригодности; сюда же относятся установка программного изделия на вычислительной системе и его удаление.
Кроме основных, стандарт ISO 12207 оговаривает 8 вспомогательных процессов, которые являются неотъемлемой частью всего жизненного цикла программного изделия и обеспечивают должное качество проекта программного обеспечения.
К вспомогательным процессам относятся:
- процесс решения проблем;
- процесс документирования;
- процесс управления конфигурацией;
- процесс обеспечения качества;
- процесс верификации;
- процесс аттестации;
- процесс совместной оценки;
- процесс аудита.
В стандарте ISO 12207 также определяются четыре организационных процесса:
- процесс управления;
- процесс создания инфраструктуры;
- процесс усовершенствования;
- процесс обучения.
И наконец, в стандарте ISO 12207 определен один особый процесс, называемый процессом адаптации, который определяет основные действия, необходимые для адаптации этого стандарта к условиям конкретного проекта.
Все сказанное выше позволяет сформулировать следующие особенности стандарта ISO 12207.
Стандарт ISO 12207 имеет динамический характер, обусловленный способом определения последовательности выполнения процессов и задач, при котором один процесс при необходимости вызывает другой или его часть. Такой характер позволяет реализовать любую модель жизненного цикла.
Стандарт ISO 12207 обеспечивает максимальную степень адаптивности. Множество процессов и задач сконструировано так, что возможна их адаптация в соответствии с конкретными проектами информационных систем. Эта адаптация сводится к исключению процессов, видов деятельности и задач, неприменимых в конкретном проекте.
Стандарт принципиально не содержит описания конкретных методов действий, а тем более — заготовок решений или документации. Он лишь описывает архитектуру процессов жизненного цикла программного обеспечения, но не конкретизирует в деталях, как реализовывать или выполнять услуги и задачи, включённые в процессы. Данный стандарт не предписывает имена, форматы или точное содержание получаемой документации. Решения такого типа принимаются сторонами, использующими стандарт.
Обеспечение качества разными процессами выполняется с разной предусмотренной степенью организационной независимости контролирующей деятельности вплоть до обязательных требований к полной независимости проверяющею персонала от какой-либо прямой ответственности за проверяемые объекты. В отличие от CDM контроль этого вида предусмотрен на самых ранних шагах разработки, начиная с анализа системных требований посредством их проверок на соответствие потребностям приобретения.
Степень обязательности рассматриваемого стандарта следующая: после решения организации о применении ISO 12207 в качестве условия торговых отношений является ее ответственность за указание минимального набора требуемых процессов и задач, которые обеспечивают согласованность с этим стандартом.
Стандарт содержит предельно мало описаний, направленных на проектирование базы данных. Это можно считать оправданным, так как разные системы и разные прикладные комплексы программного обеспечения могут не только использовать весьма специфические типы баз данных, но и вообще не использовать базу данных.
Ценность стандарта ISO 12207 в том, что он содержит наборы задач, характеристик качества, критериев оценки и т. п., дающие всесторонний охват проектных ситуаций. Например, при выполнении анализа требований к системе предусматривается, что:
- рассматривается область применения системы для определения требований, предъявляемых к системе;
- спецификация требований системы должна описывать функции и возможности системы, области применения системы, организационные требования и требования пользователя, безопасность, защищенность, человеческие факторы, эргономику, связи, операции и требования сопровождения; проектные ограничения и квалификационные требования.
Далее, при выполнении анализа требований к программному обеспечению предусмотрено 11 классов характеристик качества, которые используются позже при обеспечении качества.
При этом разработчик должен установить и документировать в виде требований к программному обеспечению следующие спецификации и характеристики:
- функциональные и возможные спецификации, включая исполнение, физические характеристики и условия среды эксплуатации, при которых единица программного обеспечения должна быть выполнена;
- внешние связи (интерфейсы) с единицей программного обеспечения;
- требования квалификации;
- спецификации надежности, включая спецификации, связанные с методами функционирования и сопровождения, воздействия окружающей среды и вероятностью травмы персонала;
- спецификации защищенности, включая спецификации, связанные с компрометацией точности информации;
- человеческие факторы спецификаций по инженерной психологии (эргономике), включая связанные с ручным управлением, взаимодействием человека и оборудования, ограничениями на персонал и областями, нуждающимися в концентрированном человеческом внимании, которые являются чувствительными к ошибкам человека и обучению;
- определение данных и требований к базе данных;
- установочные и приемочные требования поставляемого программного продукта в местах функционирования и сопровождения (эксплуатации);
- документацию пользователя;
- работа пользователя и требования выполнения;
- требования сервиса пользователя.
Хотя стандарт не предписывает конкретной модели жизненного цикла или метода разработки, он определяет, что стороны-участники при использовании стандарта ответственны за следующее:
- выбор модели жизненного цикла для разрабатываемого проекта;
- адаптацию процессов и задач стандарта к этой модели;
- выбор и применение методов разработки программного обеспечения;
- выполнение действий и задач, подходящих для проекта программного обеспечения.
2. Основные понятия IDEF0
Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:
Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рисунок 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).
Каждая из четырех сторон функционального блока имеет своё определенное значение (роль), при этом:
· Верхняя сторона имеет значение “Управление” (Control);
· Левая сторона имеет значение “Вход” (Input);
· Правая сторона имеет значение “Выход” (Output);
· Нижняя сторона имеет значение “Механизм” (Mechanism).
Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.
Вторым понятием методологии IDEF0 являются интерфейсные дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.
Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.
Рисунок 1– Функциональный блок
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон подходит данная интерфейсная дуга, она носит название “входящей”, “исходящей” или “управляющей”. Кроме того, “источником” (началом) и “приемником” (концом) каждой функциональной дуги могут быть только функциональные блоки, при этом “источником” может быть только выходная сторона блока, а “приемником” любая из трех оставшихся.
Необходимо отметить, что любой функциональный блок по требованиям стандарта должен иметь по крайней мере одну управляющую интерфейсную дугу и одну исходящую. Это и понятно – каждый процесс должен происходить по каким-то правилам (отображаемым управляющей дугой) и должен выдавать некоторый результат (выходящая дуга), иначе его рассмотрение не имеет никакого смысла.
При построении IDEF0 – диаграмм важно правильно отделять входящие интерфейсные дуги от управляющих, что часто бывает непросто. К примеру, на рисунке 2 изображен функциональный блок “Обработать заготовку”.
В реальном процессе рабочему, производящему обработку, выдают заготовку и технологические указания по обработке (или правила техники безопасности при работе со станком). Ошибочно может показаться, что и заготовка и документ с технологическими указаниями являются входящими объектами, однако это не так. На самом деле в этом процессе заготовка обрабатывается по правилам отраженным в технологических указаниях, которые должны соответственно изображаться управляющей интерфейсной дугой.
Рисунок 2 – Функциональный блок “Обработать заготовку”
Другое дело, когда технологические указания обрабатываются главным технологом и в них вносятся изменения (рисунок 3). В этом случае они отображаются уже входящей интерфейсной дугой, а управляющим объектом являются, например, новые промышленные стандарты, на основе которых производятся данные изменения.
Рисунок 3 – Пример функционального блока
Как было отмечено, механизмы (дуги с нижней стороны) показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию (рисунок 4).
Рисунок 4 – Пример механизма
Приведенные выше примеры подчеркивают внешне схожую природу входящих и управляющих интерфейсных дуг, однако для систем одного класса всегда есть определенные разграничения. Например, в случае рассмотрения предприятий и организаций существуют пять основных видов объектов:
· материальные потоки (детали, товары, сырье и т.д.);
· финансовые потоки (наличные и безналичные, инвестиции и т.д.);
· потоки документов (коммерческие, финансовые и организационные документы);
· потоки информации (информация, данные о намерениях, устные распоряжения и т.д.);
· ресурсы (сотрудники, станки, машины и т.д.). При этом в различных случаях входящими и исходящими интерфейсными дугами могут отображаться все виды объектов, управляющими только относящиеся к потокам документов и информации, а дугами-механизмами только ресурсы.
Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0.
Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).
Определение и формализация цели разработки IDEF0 – модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе, на которых необходимо фокусироваться в первую очередь. Например, если мы моделируем деятельность предприятия с целью построения в дальнейшем на базе этой модели информационной системы, то эта модель будет существенно отличаться от той, которую бы мы разрабатывали для того же самого предприятия, но уже с целью оптимизации логических цепочек.
Точка зрения определяет основное направление развития модели и уровень необходимой детализации. Четкое фиксирование точки зрения позволяет разгрузить модель, отказавшись от детализации и исследования отдельных элементов, не являющихся необходимыми, исходя из выбранной точки зрения на систему. Например, функциональные модели одного и того же предприятия с точек зрения главного технолога и финансового директора будут существенно различаться по направленности их детализации. Это связано с тем, что в конечном итоге, финансового директора не интересуют аспекты обработки сырья на производственных станках, а главному технологу ни к чему прорисованные схемы финансовых потоков. Правильный выбор точки зрения существенно сокращает временные затраты на построение конечной модели.
В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунок 6. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.
Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Принципы ограничения сложности IDEF0-диаграмм.
Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:
· Ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;
Рисунок 5 – Декомпозиция функциональных блоков
· Ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.
Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.
Наглядность графического языка IDEF0 делает модель вполне читаемой и для лиц, которые не принимали участия в проекте ее создания, а также эффективной для проведения показов и презентаций. В дальнейшем, на базе построенной модели могут быть организованы новые проекты, нацеленные на производство изменений на предприятии (в системе).
3. Методологии моделирования бизнес-процессов
Главной целью использования методологий и методов моделирования бизнес-процессов является повышение операционной эффективности компании – то есть организация всех дел наиболее оптимальным способом, ведущим к снижению затрат и одновременно к улучшению качества предлагаемых продуктов или услуг. Для того, чтобы провести такого рода оптимизацию, нужно в первую очередь смоделировать основные процессы, повседневно происходящие во всех подразделениях предприятия.
К настоящему времени разработаны многочисленные методологии моделирования бизнес-процессов. Менеджер может выбирать подходящий вариант, исходя из особенностей деятельности компании и текущих задач. К выбору стоит подходить ответственно – в конечном итоге именно от этого зависит, достаточно ли наглядной, удобной и понятной окажется модель. Поэтому конкурентоспособный управленец обязан быть хорошо знаком как минимум с несколькими основными методиками.
Методы моделирования бизнес-процессов:
· Flow Chart Diagram (диаграмма потока работ) – способ графического описания работы с применением особых символов для каждой операции, набора данных, единицы оборудования, исполнителя. В результате на схеме демонстрируется логическая последовательность всех операций. Это гибкий подход, он дает возможность при необходимости рассмотреть один комплекс действий сразу в нескольких вариантах.
· Data Flow Diagram – изображение передачи данных между операциями, для характеристики информационной стороны бизнес-процесса. Это позволяет наблюдать данные на входе в систему и в каждую операцию в отдельности, и соответствующую информацию на выходе. Также в ней отображается, какими способами сведения претерпевают изменения и где хранятся. Деятельность компании раскладывается на логические информационные уровни, причем базовая схема улучшается добавлением подробных описаний подпроцессов, тоже имеющих свою внутреннюю структуру.
· Role Activity Diagram (диаграмма ролей). Под ролью здесь понимается каждый элемент, выполняющий ту или иную функцию. Каждая часть описывается, и анализируется отдельно, а затем рассматривается их взаимодействие.
· IDEF (Integrated Definition for Function Modeling) – это целый набор аналитических средств, применяемых не только в управлении бизнесом, но и во многих других сферах. Чаще всего встречаются варианты IDEF0 и IDEF3. Первый из этих вариантов представляет собой модель функций, причем сложные функции делятся на более простые составляющие, а затем различные блоки логически объединяются посредством стрелок. При использовании IDEF3 речь идет о «поведенческом» описании: демонстрируется поток работ либо переходные состояния объектов.
· Цветные сети Петри – график, на котором представлены действия и события, символизирующие переход из одной стадии в другую. Таким образом можно увидеть, что приводит к тем или иным изменениям, насколько быстро и эффективно.
· Unified Modeling Language – графический язык для визуализации, специфицирования, конструирования и документирования процессов и систем. Комплекс из девяти видов диаграмм, описывающих разные аспекты: классы, объекты, прецеденты, последовательности, кооперации, состояния, деятельность, компоненты, развертывание. В результате получается представление очередности действий сотрудников и работы различных объектов внутри организации. Схема может разветвляться, в ней отмечаются разнообразные условия и исключения из правил.
· ARIS (Architecture of Integrated information Systems) – методология и соответствующее семейство программных продуктов. Они используются для структурированного описания, анализа и последующего совершенствования бизнес-процессов предприятия. Система наглядно показывает правила деятельности предприятия и значения показателей результативности. Так можно определить желаемые характеристики работы компании, совершенствовать архитектуру, улучшить процессы, рационально распределять ресурсы. Инструмент определяет весь цикл разработки – анализ требований, спецификация информационной системы и описание физической реализации.
Методы моделирования бизнес-процессов реализованы в специальных компьютерных программах, позволяющих оперативно визуализировать «картинку» при вводе данных. Каждую из методологий можно изучить в рамках специализированных образовательных программ. Инструментальные средства рассматриваются отдельности, углубленно, или обзорно, в сравнении. Именно накапливание систематизированных знаний обо всех моделях, рассмотрение примеров практического применения и способов использования в различных ситуациях помогает успешно использовать разные методики при реальном руководстве предприятием.
Заключение
Особое место занимают современные информационные технологии ведения электронной коммерции, работа с заказчиками и поставщиками. И в этом направлении проектирование и развитие информационных систем не возможно без знания основных методологий и программных средств, позволяющих в кратчайшие сроки и без ошибок управлять этими процессами. Компании получают колоссальные конкурентные преимущества, если уровень развития информационных систем соответствует уровню развития предприятия. Улучшается инвестиционная привлекательность компании, основные бизнес-процесс становятся прозрачными и понятными для контроля и управления, исключаются ошибки, брак и связанные с ними потери и времени, и средств, в конечном счете, увеличивается прибыль компании.
При создании сложных информационных систем зачастую очень трудно понять требования персонала заказчика. Они могут быть сформулированы некорректно, а в процессе анализа конкретных бизнес-процессов даже измениться. Поэтому появление методологий современного проектирования и моделирования информационных систем было насущной задачей, над которой работали специалисты разных стран. Появление автоматизированных систем управления в шестидесятых годах прошлого столетия определялось получением начальных знаний и опыта их разработки и внедрения. Анализировались все успехи и неудачи создания первых АСУ, но бесспорным было сокращение времени обработки информации, производственных и управленческих затрат и как следствие персонала.
Список использованной литературы
1. Белов, В.В. Проектирование информационных систем: Учебник / В.В. Белов. - М.: Академия, 2018. - 144 c.
2. Гвоздева, Т.В. Проектирование информационных систем: технология автоматизированного проектирования. Лабораторный практикум. Учебно-справочное пособие / Т.В. Гвоздева, Б.А. Баллод. - СПб.: Лань, 2018. - 156 c.
3. Емельянова, Н.З. Проектирование информационных систем: Учебное пособие / Н.З. Емельянова, Т.Л. Партыка, И.И. Попов. - М.: Форум, 2013. - 432 c.
4. Коваленко, В.В. Проектирование информационных систем: Учебное пособие / В.В. Коваленко. - М.: Форум, 2015. - 976 c.
5. Перлова, О.Н. Проектирование и разработка информационных систем: Учебник / О.Н. Перлова, О.П. Ляпина, А.В. Гусева. - М.: Academia, 2017. - 416 c.
6. Соловьев, И.В. Проектирование информационных систем. Фундаментальный курс: Учебное пособие для высшей школы / И.В. Соловьев, А.А. Майоров; Под ред. В.П. Савиных. - М.: Академический проспект, 2009. - 398 c.