В чем заключается постановка задачи и предпроектные исследования
Предпроектный анализ
Сергей Нужненко darkboatman, ведущий системный аналитик SuperJob, делится опытом запуска IT-проектов с точки зрения аналитика.
По итогам выступления на прошедшем митапе у меня получается серия заметок, в которых я постараюсь, освободившись от ограничения форматом выступления, обсудить с вами принципы выполнения предпроектных задач и покажу несколько примеров из жизни.
Это пригодится представителям заказчика, системным, бизнес-аналитикам, менеджерам проектов, другим участвующим в запуске ИТ-проектов, итераций или спринтов.
Под предпроектом мы понимаем все задачи, которые надо выполнить до момента получения согласия всех сторон, утверждения бюджета, а главное — понимания, что мы делаем и зачем, а также каким способом, то есть кого надо привлечь и кому позже надо будет ставить задачу. Эти задачи одинаковы как для большого проекта, так и для короткой двухнедельной итерации.
Мы знаем, что, во-первых, хорошая постановка задачи — это половина решения, а, во-вторых, не столь важно, насколько продуктивно ты что-то делаешь, если при этом делаешь не то, что нужно. Системной предпроектной работе уделяется удручающе мало внимания. Подавляющее число обсуждений, книг и статей посвящено тому, что делать внутри проекта, или поиску продукта во взаимодействии с рынком. В серой зоне оказывается переход от понимания, что надо продавать, к самой работе.
Задачи предпроекта
Что нужно сделать для того, чтобы построить ИТ-систему или сервис?
Вот список больших задач, которые так или иначе решаются для любой системы:
Предпроект (хоть он и не всегда так называется) может выполняться в разных условиях: на систему в целом, на подсистемы или на каждую фичу продукта.
Все указанные задачи могут выполняться годы, месяцы или пролетать за неделю в рамках подготовки сессии планирования спринта, могут сопровождаться различным количеством бумаги и разными схемами взаимодействия участников.
Однако перед тем, как мы начнем фиксировать цели, пресловутые 4 параметра проектного треугольника — формулировать обязанности участников проекта, назначать внешние статус-митинги с участием спонсора и расчехлять другие общеупотребимые инструменты проектного управления — необходимо полностью выполнить задачи предпроекта:
1) Понять сроки и стоимость
2) Допродать систему:
4) Определиться с ресурсами: видами, этапами, сроками, объемами работ и источниками ресурсов
Без этого ничего (хорошего) не выйдет.
Трудности
Все проблемы, о которых пойдет речь ниже, развиваются на заведомо неблагоприятном фоне, общем для всех предпроектов.
Надо быстро определиться со стоимостью системы на фоне высокой неопределенности.
Идет торг за бюджет и сроки — это конфликт, изначально заложенный в любой предпроект.
Заказчик хочет Сhrysler Escalade, денег есть на ГАЗ 69, но нужен ему Renault Logan. Бывает, что при этом поставщик решений хочет продавать яхты и самолеты, но реально может сделать только надувную лодку, а сейчас пойдет искать, у кого купить Logan.
Проект еще не «продан» и идет борьба за его запуск.
Обзор проблем и решений
Мы расположили частые проблемы предпроекта по мере роста зрелости заказчика и других участников ИТ-проекта:
1) «Письмо Дяди Фёдора»
2) Не учтены полный ЖЦ и структура как системы, так и финансового актива
3) Не учтены задачи предпроектной фазы
Обзор предлагаемых решений, о которых мы более детально поговорим в следующих разделах:
Кроме этого необходимо помнить о базовых принципах, которые мстят за невнимание к себе. Среди них:
В чем заключается постановка задачи и предпроектные исследования
6.3. ПРЕДПРОЕКТНОЕ ИССЛЕДОВАНИЕ и
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Предпроектное исследование осуществляется с целью параметризации проекта создания АИПС. Сначала выявляются все материальные, финансовые людские и временные ресурсы для выполнения необходимых проектных работ. Это этап сбора необходимых данных и их анализа.
На основе полученных данных формируется Техническое задание (ТЗ) – третий этап проектирования (при необходимости – технико-экономическое обоснование проекта – ТЭО), и собственно проект (четвёртый этап проектирования).
При этом следует отличать работы, связанные с автоматизацией физического труда от работ по автоматизации умственного труда.
Объектами автоматизации могут быть как отдельно взятые, автономные операции или процессы, так и интегральные (интегрированные) системы, требующие обеспечения автоматизации целого комплекса процессов. На основе полученных в процессе проектирования данных в дальнейшем будет приобретаться необходимое оборудование и программное обеспечение, осуществляться монтаж и наладка (при необходимости) оборудования, инициализация (инсталляция, установка) необходимых программ, обучение персонала и опытная эксплуатация создаваемых фрагментов (элементов и подсистем) АИС.
Эти условия становятся наиболее актуальными при использовании локальных и глобальных компьютерных сетевых технологий, получивших в наше время название Интранет и Интернет, соответственно.
Этап анализа предполагает подробное исследование бизнес-процессов и информации, необходимой для их выполнения: сущностей, их атрибутов и связей (отношений). На этом этапе создаётся информационная модель ИС, а на следующем за ним этапе проектирования – модель данных.
Вся собранная информация формализуется и уточняется по результатам её анализа.
На этапе анализа происходит уточнение существующих и необходимых для конечной реализации аппаратных и программных средств. Для этого могут привлекаться группы тестирования и технические специалисты. При проектировании информационной системы важно учесть и дальнейшее её развитие, например рост объёмов обрабатываемых данных, увеличение интенсивности потока запросов, изменение требований надёжности информационной системы и др.
На этом этапе определяют модели задач для получения сравнительных характеристик СУБД, которые могут быть использованы для реализации АИС. На этапе исследования может быть осуществлен выбор СУБД. Полученные данные могут показать, что выбранная СУБД не удовлетворит требования Заказчика. Аналогичные данные могут быть получены в отношении предлагаемой аппаратной платформы и операционной системы. Такие результаты свидетельствуют о необходимости изменения и (или) корректировки начальных данных, полученных в результате предпроектного исследования.
По полученным результатам следует выявить необходимые средства разработки АИС, выбор которых уточняется на этапе анализа. Если предполагаемое средство разработки не позволяет выполнять хотя бы часть работ в заранее заданный срок, то принимают решение об изменении срока (как правило, его увеличении) или о смене средства разработки. Осуществляя выбор средств разработки, следует учитывать наличие персонала, владеющего ими.
На этапе анализа уточняю существование или появление возможных ограничений, рисков и критических факторов. Если первичное исследование показало, что какие-либо требования Заказчика не могут быть удовлетворены в проектируемой АИС, то рассматривается возможность их изменения Заказчиком.
Необходимо оценивать степень удовлетворения каждой из потребностей Заказчика, связанных с внедрением ИС. При этом не следует забывать, что отсутствие необходимых исходных данных затрудняет проектирование системы.
В рамках предпроектного исследования может осуществляться концептуальное проектирование (conceptual design) – разработка аванпроекта (пилотного проекта) или программы создания системы.
Он должен осуществляться в течение непродолжительного времени иначе Заказчик может потерять интерес к проекту. Важной функцией пилотного проекта является принятие решения относительно приобретения или отказа от использования ИС.
Возможным следующие варианты решения:
Выполненная на данном этапе работа позволяет ответить на вопрос, какие требования Заказчика могут быть удовлетворены, если стоит продолжать данный проект. Может оказаться, что проект продолжать не имеет смысла, например из-за того, что какие-то требования не могут быть удовлетворены по объективным и иным причинам. Если принимается решение о продолжении проекта, то переходят к формированию Технического задания.
Техническое задание (ТЗ) – третья стадия проектирования АИС. Оно формируется по результатам проведённого предпроектного исследования и включает разработку и утверждение Технического задания на создание АИС.
Напомним, что разработчики к нему могут и не приступить, если в результате предпрпоектного исследования было выявлено, что Заказчику следует отказаться от использования АИС.
В зависимости от условий создания системы возможны различные совмещения функций заказчика, разработчика, поставщика и других организаций, участвующих в работах по созданию АИС.
В соответствии с ГОСТ 34.601-90 после согласования с заказчиком, выполняется разработка, оформление, согласование и утверждение технического задания (ТЗ) на АИС. Данный стандарт также определяет состав участников проектирования и реализации проектных решений при составлении и (или) согласовании ТЗ.
Легко заметить, что многие его компоненты не только базируются на результатах проведённого предпроектного исследования, но и входят в состав ТЗ.
В зависимости от вида, назначения, специфических особенностей объекта автоматизации и условий функционирования системы допускается оформлять разделы ТЗ в виде приложений, вводить дополнительные, исключать или объединять подразделы ТЗ.
В состав ТЗ на АИС включают приложения, содержащие:
1. Расчёт ожидаемой эффективности системы;
2. Оценку научно-технического уровня системы;
3. Использованные при разработке ТЗ методические и наиболее важные информационные материалы из состава документов указанных в разделе «Источники разработки».
Дополнительные рекомендации по составу и содержанию ТЗ на автоматизированные системы различного назначения и приложений к ним содержатся также в РД 50-640-87 и ГОСТ 24.602-86.
Предпроектное обследования при разработке информационной системы
Что бывает без предпроектного обследования?
В свое время мне пришлось заниматься разработкой и продажей систем для составления маршрутов транспорта: на карту выводятся точки с заказами, обводишь их мышью и размещаешь в машины. Обращается к нам одна компания с просьбой продать приложение. Не один месяц мы пытались выяснить, зачем же им подобная система нужна, в результате продали им «коробку», очень уж они просили. Затем решила данная компания привлечь нас для внедрения. И тут выяснилось, что в первую очередь им нужна была функциональность для учета топлива, которая в нашей системе отсутствовала от слова совсем.
А бывает, присоединяешься к проекту в ходе разработки системы, изучаешь документацию по проекту и уже разработанную функциональность. И в какой-то момент приходит осознание: есть интерфейс, программа что-то делает, а вот ответить, зачем она разрабатывается, какие бизнес-задачи решает, какие показатели должны быть достигнуты, никто из проектной команды не способен. Можно ли таким образом создать систему, отвечающую запросам заказчика?
Иными словами, еще до составления Технического задания следует провести обычно небольшое (это как когда) исследование и ответить на ряд вопросов.
Основные вопросы, на которые отвечает обследование
Как говорится, вам надо понять, ЧТО, ГДЕ, КОГДА. А именно:
Зачем нужно писать, почему недостаточно обсудить и проговорить?
Составление документа позволяет сформулировать мысль на совершенно ином качественном уровне, чем при устном обсуждении. В разговоре неохваченными остаются многие детали, часть информации забывается и позже упускается из виду. А бумага сохраняет все мысли.
Да, составление документов — дело кропотливое и иногда неприятное, но оно того стоит. Мысль ценна только тогда, когда она сформирована, а сформирована она тогда, когда сформулирована на бумаге.
Что должно содержать в себе предпроектное обследование?
Обычно под предпроектным обследованием имеют в виду изучение бизнес-процессов предприятия. Об этом написано много статей и книг. Но к сожалению, простого изложения процессов недостаточно.
Результатом исследования может быть целый пакет документов (часть из них приведена в конце статьи). Центральным (и, к сожалению, часто единственным) документом у меня обычно является документ «Концепция системы». Этот документ мы и обсудим в настоящей статьей.
Разрабатывая собственную структуру Концепции, я взял за основу отчет, подготавливаемый согласно ГОСТ 34 на стадии «Формирование требований к АС» (см. стандарт РД 50-34.698-90 «Методические указания. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов»). Но при этом внес свои дополнения.
«Концепция системы» может содержать 2, а иногда и 30 страниц. Все зависит от постановки задачи. «Концепция», как правило, согласовывается с высшим руководством заказчика, и только на основании этого можно разрабатывать Техническое задание.
Цель создания (модернизации) системы
Под целью создания я понимаю именно бизнес-цели. «Автоматизировать» — это не цель. Добавить функцию — тоже не цель. И «оптимизировать» — не цель. Например, сидит сотрудник и пару часов в день он может поспать прямо на рабочем месте (реальный случай, кстати). И кто-то просит автоматизировать его деятельность. Зачем? Чтобы он четыре часа спал?
За несколько лет анализа десятков проектов удалось определить только пять возможных целей создания (модернизации) системы:
Идея системы
В случае, если документ «Концепция» получается достаточно объемным, имеет смысл вначале кратко изложить самую суть системы, ее идею. Например, вы хотите создать какую-либо специализированную социальную сеть (ходите по музеям и делитесь впечатлениями). Я бы вначале описал потребность в общении между посетителями, а затем кратко — суть: разрабатывается мобильное приложение, в котором пользователь может написать свои впечатления от того или иного экспоната.
Сравнение старого и нового
Самым эффективным способом понять суть создаваемой системы — идти как бы от противного.
Для этого необходимо:
На чем собираемся зарабатывать
Если разрабатывается приложение, с помощью которого планируется зарабатывать деньги, то обязательно нужно определить методы заработка: размещение рекламы, платная подписка, платные услуги, взимаемый процент и т.д. Выбранный способ (или способы) может сильно повлиять на разрабатываемую функциональность.
Заинтересованность сторон
Если для функционирования создаваемой системы необходимо участие других организаций, то обязательно нужно решить, как их привлечь к работе, заинтересовать. Иными словами, сначала выстраиваем всю бизнес-цепочку, потом уже все остальное.
Описание автоматизируемых процессов
Цель данного раздела — дать общее, но полное представление о процессе. Например, вы разрабатываете интернет-магазин. Очевидно, что нужен каталог, корзина, интеграция с банком-эквайером и доставка. Но вот вопросы возврата, отказа при доставке, отказа поставщика, неожиданного отсутствия товара на складе могут ускользнуть от вашего внимания. Лучше продумать все возможные варианты заранее и решить, что из этого будет автоматизироваться, а какие случаи происходят так редко, что лучше их «разгребать» в ручном режиме.
Для описания не обязательно приводить схемы. В общем случае обычный текстовый сценарий намного более полно раскрывает сущность действий.
Юридическое обеспечение
Нередко после создания системы оказывается, что в использующие приложение люди или организации нарушают закон. Поэтому вначале надо найти юридически чистую схему, а затем уже вырабатывать технические решения.
Перечень функций
Документ «Концепция» — это не Техническое задание, поэтому описываются бизнес-функции, верхний уровень. Нет никакого смысла на данном этапе говорить об авторизации и работе с профилем пользователя. Но дать общее представление о функциональности надо обязательно.
Требования к безопасности
Если вы разрабатываете финансовую систему или систему, содержащую строго конфиденциальные данные, то необходимо привести перечень стандартов безопасности. Например, требования к шифрованию хранимых или передаваемых данных. Не забывайте и о все ужесточающихся требованиях к обработке и хранению персональных данных.
Выбор варианта реализации системы
Иногда в зависимости от потребностей необходимо определить вид приложения (веб-приложение, нативное), платформу (Windows, Linux), общую архитектуру (один сервер или несколько кластеров), взять ли типовую систему и доработать или вести разработку с нуля. Для этого необходимо сравнить предлагаемые варианты и выбрать наиболее подходящий.
Другие документы предпроектного исследования
Как мы уже говорили выше, результатом хорошего, серьезного предпроектного исследования, проводимого не одну неделю целой командой, является целый пакет документов. Вот некоторые из них:
Заключение
В статье мы очень бегло пробежались по основным разделам предпроектного обследования. Почему бегло? Потому что такое обследование — крайне творческое занятие. Главное, чтобы при прочтении концепции сложилось полное понимание, как это должно работать. А в остальном два документа с результатами исследования могут никак не быть похожими друг на друга. Соответственно и перечень разделов в вашем документе может сильно отличаться от приведенного выше.
Предпроектные исследования
Предпроектный анализ связан с детальным изучением особенностей той архитектурной ситуации, которая принята дипломником.
Цель предпроектного исследования – сбор всех необходимых для проектирования материалов. Начинается работа с изучения технического задания на проектирование, в котором дается информация о назначении и принципиальном устройстве проектируемого объекта, о предъявляемых конструктивных, технологических и эргономических требованиях, особенностях и возможностях производственной базы, требуемых связях с предметным окружением.
Всей этой предпроектной работе должна сопутствовать общая концептуальная разработка с необходимым выделением узловых точек всего средового пространства.
Содержание процесса дизайн-проектирования
«Процесс дизайн-проектирования начинается с постановки проблемы. Проблематизация расширяет смысловой контекст поставленной задачи и трансформирует ее в проблему. Следующим этапом проектирования является выявление сторон и связей в проблеме и формулирование ее содержания. Что включает определение исходных условий и ресурсов для решения проблемы (локализация проблемы). Важным фактором деятельности дизайнера на данном этапе можно обозначить определение проектных целей и состава решаемых задач, определение и ориентация на адресат проектируемого объекта. Выделение системы потребительских требований и предпочтений и социокультурную типологизацию потенциального потребителя.
Формирование «образа целей» и способов их достижения, а так же вычленение предмета проектирования происходит под влиянием смыслового контекста, который включает исторический анализ проблемы, изучение способов ее решения.
Смысловой контекст проекта, в зависимости от поставленной цели в той или иной мере включает:
ролевой контекст (контекст деятельности различных специалистов вокруг разрабатываемого объекта);
функциональный контекст (прогноз функционирования проектируемого объекта в системе «человек-предмет-среда»);
образно-художественный контекст (аналогии между выразительными особенностями дизайн-объекта и приемами повышения выразительности, разработанными в других областях искусства и культуры, анализ композиционно-образного решения объектов-аналогов).
На данном этапе проектирования проводится функциональный анализ стадий и форм существования объекта и особенностей его взаимодействия с человеком на различных уровнях социального функционирования (производство, распределение, хранение, транспортировка, эксплуатация, ремонт, утилизация). Выявляются ограничивающие условия внешней среды и ее качественные характеристики (географические, климатические, сезонные, региональные, демографические и пр.).»
«Первые идеи – композиционные, конструктивные, функционально-компоновочные, художественно-стилистические – начинают материализоваться лишь в процессе эскизирования – графического выражения замысла в эскизе, в рабочем проекте.
Дизайн-концепция
Дизайн-концепция носит абстрагированный характер. В ее задачи входит разработка обоснованных принципов формообразования проектируемого объекта, как правило, на научной основе. Поэтому, представляемые на стадии дизайн-концепции материалы, наряду с традиционными изобразительными формами, содержат различные схемы, логические модели и т.п. материалы.
В Концепции раскрывается:
— концептуальное решение проекта;
-композиционное решение проекта;
— цветовое решение проекта,
-обосновываются принципы формообразования объектов;
-рассматриваются технологические особенности;
В дизайн-концепции прорабатываются:
Концепция становится теоретической базой для последующих проектных поисков.
Наметив общий концептуальный характер решения главных элементов интерьерных и средовых пространств, дипломник приступает к детальной разработке планов, принятых для проектирования. Он должен четко разобраться в их функциональной и композиционно-художественной структуре, намечая различные варианты ее построения. Среди этих вариантов он по своему усмотрению отбирает лучшие, представляя их на промежуточный кафедральный просмотр.
Различие между художественным и проектным образом в том, что потребитель воплощенного проектного образа входит с ним в практическое взаимодействие, он им пользуется в обыденной жизни. Основные характеристики проектного образа, сохраняющего также и «родовые свойства» художественного: идеальность (способность к существованию в идее); целостность; осмысленность.
Для выражения идеи дизайнером используется главным образом арсенал традиционных графических и пластических средств. Культурная концепция сложного комплексного объекта предваряет поиск его проектного языка.
Форпроект предусматривает многовариантный графический или пластический поиск основной идеи проектируемого объекта. Форэскиз- чистовой вариант эскиза, в котором уточняются все пропорциональные соотношения предметов и цветовых пятен, решаются пластические задачи формообразования.
После того как форэскизы полностью определены и утверждены руководителем диплома и одобрены на заседании кафедры, можно приступать к практическому осуществлению работы.
Большое значение имеет оформление уже готовой работы. Иногда приходится менять решение, имея уже готовый результат. Поэтому очень важно продумать проект до мелочей.»
Эскизное проектирование
«На этой стадии делается большое количество зарисовок и набросков, позволяющих представить объект во всех ракурсах, выделить и подчеркнуть его особенности. В зависимости поставленной задачи ведется композиционный графический поиск по отдельным аспектам – функционально-техническим, художественно-стилистическим, архитектоническим и др.
В итоге всех графических поисков дизайнер должен дать полное представление о художественно-стилистическом и цветофактурном решении проектируемого объекта.
После выполнения эскизов следует очень важная работа по составлению уже отмеченной нами выше, общей графической композиции дипломного проекта. Строится эта композиция в масштабе к натуральной величине планшетов по принципу того или иного (вертикального, горизонтального или смешанного) их расположения.
Графическая часть дипломного проекта компонуется на 3-4 листах форматом 1м. на 1,40м. На них в наиболее рациональном порядке располагаются все элементы проекта.»
«Подача проекта включает:
· постановка проектной задачи (составление технического задания);
· текстовое и графическое оформление материалов проектных исследований, и предлагаемой дизайн-концепции в виде дизайн-предложения;
· поиск вариантов компоновочного и пластического решения объекта, его основных формообразующих элементов, выбор проектного варианта;
· цвето-графическая разработка проектируемого объекта, художественно-графическое представление материалов проектного решения; оформление материалов эскизного дизайн-проекта.
· уровень проектной реализации дизайн-концепции.»
«В состав проекта входит:
· оформление графических планшетов с чертежами (развертки стен, разрезы, фасады, планы, генпланы, конструктивные чертежи) и схемами, перспективными изображениями интерьеров, эскизами деталей, экспликациями;
· Теоретическая часть с приложениями. В приложениях необходимо размещать аналоговые объекты, чертежи и перспективные изображения дипломной работы как в крупном масштабе, так и вся графическая композиция подачи проекта.
Графическая часть дипломного проекта компонуется на 3-4 листах форматом 1м. на 1,40м. На них в наиболее рациональном порядке располагаются все элементы проекта.»
Технические требования к оформлению текста
Объем пояснительной записки должен быть в пределах 60 страниц машинописного текста. Используется белая бумага формата А4 (210×297 мм), лист заполняется только с одной стороны.
Шрифт – Times New Roman,
Поля оставляют со всех четырех сторон.
При таких полях каждая страница должна содержать приблизительно 1800 знаков (30 строк, по 60 знаков в строке, считая каждый знак препинания и пробел между словами также за печатный знак).
Фразы, начинающиеся с новой (красной) строки, печатают с абзацным отступом от начала строки, равным трем печатным символам.
Разделы и подразделы нумеруются арабскими цифрами и записываются с абзацного отступа.
Наименование структурных элементов: «ВВЕДЕНИЕ», «ОГЛАВЛЕНИЕ», «ЗАКЛЮЧЕНИЕ», «ПРИЛОЖЕНИЕ», «СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ» пишутся посерединелиста прописными буквами без точки в конце наименования.
Названия глав и параграфов располагаются по центру листа
Все сноски и подстрочные примечаний перепечатывают (через один интервал) на той странице, к которой они относятся.
Все страницы нумеруются, начиная с титульного листа и оглавления, но номера страниц на них не ставятся. Номер страницы проставляется с третьего листа в середине нижнего поля страницы арабскими цифрами. Если в работе есть рисунки, схемы, таблицы и пр., то для них используется сквозная нумерация.
Каждая новая глава начинается с новой страницы. Это же правило относится к другим основным структурным частям работы введению, заключению, списку литературы, приложениям, указателям.
Расстояние между названием главы и последующим текстом должно быть равно двум интервалам. Такое же расстояние выдерживается между заголовками главы и параграфа.
Расстояния между основаниями строк заголовка принимают таким же, как и в тексте.
Точку в конце заголовка, располагаемого посредине строки, не ставят.
Подчеркивать заголовки и переносить слова в заголовке не допускается.
Внутри пункта и подпункта могут быть перечисления, которые печатаются с обзацного отступа. Перед каждым элементом перечисления ставится дефис или строчная буква русского алфавита.
Оформление таблиц и иллюстративного материала
Рукопись, рисунки, фотографии должны быть без пометок, карандашных исправлений, пятен и загибов, набивка буквы на букву и дорисовка бука чернилами не допускается.
Все ошибки и опечатки необходимо исправить. Число исправлений должно быть минимальным на страницу не более пяти исправлений, они устраняются от руки чернилами черного цвета.
Требования к оформлению списка литературы
Список литературысоставляется в алфавитном порядке и включается в общую нумерацию страниц. Алфавитный способ группировки литературных источников характерен тем, что фамилии авторов и заглавий (если автор не указан) размещены по алфавиту.
Принято следующее оформление списка литературы монографии, книги, статьи, пособия, рекомендации, иностранные источники и информация из Интернета размещается после перечня всех источников на языке ВКР.
Список литературы должен состоять не менее чем из 30 источников по искусствоведению, философии, композиции, цветоведению, технологии, включая статьи из специализированных журналов, каталогов выставок и информацию из Интернета.
Требования к оформлению приложения
Приложенияимеют отдельную нумерацию, так как поясняют определенный параграф, все иллюстрации нумеруются и подписываются единым для всего текста шрифтом. Нумерация страниц в приложении не ставится.
Количество иллюстраций, сопровождающих работу, должно в достаточной степени пояснять смысл и суть написанного, а также, придавать, излагаемому материалу, определенную ясность и конкретность.
При оформлении цитат и сносок следует придерживаться общепринятых положений.