| 23.10.2019, 12:07 | |
Начало. Методические указания. Цели и задачи
3 СТРУКТУРА И СОДЕРЖАНИЕ КУРСОВОЙ РАБОТЫ
3.1 Общее содержание курсовой работыОглавление Введение 1. Анализ предметной области 1.1 Общее описание реализации технологии (бизнес-процесса) 1.2 Структура технологии (бизнес-процесса) и его информационные потоки 1.3 Выбор объекта автоматизации технологии (бизнес-процесса). Детальное описание объекта автоматизации 1.4 Постановка задачи исследования 2. Обзор инструментария Oracle Dsigner 2.1 Общие черты CASE-средств 2.2 Oracle Designer 2.3 Общая архитектура и основные компоненты Designer 2.4 Репозиторий - централизованная база данных проекта 2.5 Проектирование прикладной системы системы. 3. Моделирование объекта автоматизации. 3.1. Порядок выполнения работы. 3.2. Разработка диаграммы потоков данных. 3.3. Разработка ER-диаграмм. 3.4 Создание диаграмм серверной модели 3.5 Разработка диаграммы иерархии функций 3.5 Генерация форм ввода данных Заключение Список использованной литературы Приложения 3.2 Содержание разделов курсовой работы3.2.1 ВведениеВведение должно содержать общие сведения о работе. В нем необходимо отразить актуальность выбранной темы, цель и задачи и объект исследования, практическую значимость полученных результатов. Целью работы может быть: повышение эффективности исследуемого процесса (бухгалтерского учета предприятия, судопроизводства и т. д.) путем автоматизации работы с определенным документом (доверенность, счет фактура, договор и т. д.). Во вводной части также необходимо перечислить вопросы, которые будут рассмотрены в проекте, выделив вопросы, которые предполагается решить практически. По желанию, можно привести логическую структуру проекта. Объем введения должен быть не более 5 страниц (здесь и далее указаны объемы машинописного текста). 3.2.2 Анализ предметной областиДанный раздел посвящен анализу конкретного объекта исследования (определенного темой работы) и предмета автоматизации, подлежащей разработке. По литературным источникам анализируются структура и информационные потоки при совершении всех операций в конкретной предметной области. На основании этого обосновывается необходимость моделирования и разработки ИС для автоматизации предметной области, формулируются цель и задачи курсовой работы. Во втором подразделе с использованием всех доступных источников проводится анализ объекта и предмета курсовой работы, определенных заданием. Особое внимание следует уделить назначению, форме документа, его содержанию и правилам исполнения. Для качественной разработки информационной системы желательно рассмотреть не только сам объект автоматизации, но и структуру информационные и материальные потоки подразделения предприятия, для которого разрабатывается ИС. Приведем пример описание объекта автоматизации – кассовые операции. Для осуществления расчетов наличными деньгами каждое предприятие должно иметь кассу и вести кассовую книгу по установленной форме. Все поступления и выдачи наличных денег предприятия учитывают в кассовой книге. Прием наличных денег кассами предприятий производится по приходным кассовым ордерам, подписанным главным бухгалтером или лицом, уполномоченным на это письменным распоряжением руководителя предприятия. Выдача наличных денег из касс предприятий производится по расходным кассовым ордерам или надлежаще оформленным другим документам (платежным ведомостям (расчетно-платежным), заявлениям на выдачу денег, счетам и др.) с наложением на этих документах штампа с реквизитами расходного кассового ордера. Документы на выдачу денег должны быть подписаны руководителем, главным бухгалтером предприятия или лицами, уполномоченными на это. Выдача денег лицам, не состоящим в списочном составе предприятия, производится по расходным кассовым, ордерам выписываемым отдельно на каждое лицо, или по отдельной ведомости на основании заключенных договоров. Расходный кассовый ордер, иные документы, на основании которых оформляется расходный кассовый ордер Приходные и расходные кассовые ордера или заменяющие их документы до передачи в кассу регистрируются бухгалтерией в журнале регистрации приходных и расходных кассовых документов. Расходные кассовые ордера, оформленные на платежных (расчетно-платежных) ведомостях на оплату труда и других приравненных к ней платежей, регистрируются после их выдачи. Регистрация приходных и расходных кассовых документов может осуществляться с применением средств вычислительной техники. При этом в машинограмме «Вкладной лист журнала регистрации приходных и расходных кассовых ордеров», составляемой за соответствующий день, обеспечивается также формирование данных для учета движения денежных средств по целевому назначению Журнал регистрации приходных и расходных кассовых документов. Кассовые операции оформляются типовыми межведомственными формами первичной учетной документации для предприятий и организаций, которые утверждаются Госкомстатом России по согласованию с Центральным банком Российской Федерации и Министерством финансов Российской Федерации. Данное положение отсылает нас к Постановлениям Госкомстата России от 18.08.1998 № 88 «Об утверждении унифицированных форм первичной учетной документации по учету кассовых операций, по учету результатов инвентаризации» (далее – Постановление № 88), от 01.08.2001 № 55 «Об утверждении унифицированной формы первичной учетной документации № АО-1 «Авансовый отчет». Этими Постановлениями Госкомстата утверждены следующие формы первичных документов по учету кассовых операций:
Печатные формы кассовых документов представлены на рисунке 1 и 2. Далее производится подробное описание подразделения (организации) для которого разрабатывается информационная система, и анализируются информационные и материальные потоки информации при работе с рассматриваемым документом (объектом автоматизации). Описание, как правило, должно заканчиваться схемой, на которой отражаются данные потоки.
Рисунок 1 – Приходный кассовый ордер
Рисунок 2 – Расходный кассовый ордер
Во втором подразделе проводится анализ существующих систем автоматизации рассматриваемых процессов с рассмотрением положительных и отрицательных сторон каждого из них. При необходимости делаются выводы о необходимости разработки новой информационной системы или совершенствовании существующей. В третьем подразделе формируются требования в разрабатываемой информационной системе по следующим направлениям:
В заключение первого раздела основной части производится постановка задач, которые должны быть раскрыты в оставшейся части курсовой работы. Пример постановки задачи представлен ниже. Основной целью данной работы является моделирование предметной области на тему «Технология управления кассовыми операциями предприятия» при помощи среды моделирования и разработки Oracle Designer и входящего в него комплекта по автоматизированной разработке приложений. Задачи курсовой работы:
3.2.3 Обзор инструментария Oracle DesignerВ данном разделе производится обзор возможностей CASE-средств последовательно излагаются все стадии проектирования информационной системы, применительно к предложенной в задании тематике. Отдельным подразделом производится обосновывается выбор в качестве средства реализации инструментальной среды СУБД ORACLE. Пример содержания второго раздела представлен ниже. Характеритиска инструментария Oracle Designer. Набор инструментальных средств Oracle Designer предлагает интегрированное решение для разработки прикладных систем корпоративного уровня для Web и клиент/серверных приложений. Oracle Designer участвует в каждой фазе жизненного цикла разработки программного обеспечения от моделирования бизнес-процессов до внедрения. Применение единого репозитория, делает возможным использование любых его компонент для быстрой разработки масштабируемых, кросс-платформных распределенных приложений. Задачей Oracle Designer является сбор данных о потребностях пользователей и автоматизация построения гибких графических приложений. Oracle Designer используется не только для создания приложений, но и для ведения учета изменений, которые неизбежно происходят при эксплуатации системы. Графические модели определений проекта, интегрированные с многопользовательским репозиторием существенно облегчают работу с Oracle Designer. Инструментальные средства построены на базе общепринятых методик, охватывающих весь жизненный цикл разработки и позволяющих пользователям привычным для их организации способом. Это обеспечивает гибкость и открытость подхода к разработке программного обеспечения за счет использования только тех частей продукта, которые требуются в данной задаче. В рамках процесса разработки обеспечивается поддержка методов RAD, JAD, информационного проектирования, водопадного метода (waterfall), итеративного метода, а также индивидуального подхода, выбранного компанией. Пользуясь этими принципами, можно добиться успешного баланса организационных потребностей и технологических возможностей, и даже эффективно управлять риском, связанным с частыми неизбежными и важными изменениями как в одной, так и в другой области. Общая архитектура и основные компоненты DESIGNER. В соответствии с общей архитектурой CASE-системы DESIGNER, выделяются следующие основные этапы процесса разработки системы: моделирование и анализ деловой деятельности, разработка концептуальных моделей предметной области, проектирование прикладной системы и реализация. Первый этап связан с моделированием и анализом процессов, описывающих деятельность организации, технологические особенности работы. Целью является построение моделей существующих процессов, выявление их недостатков и возможных источников усовершенствования. Этот этап не является обязательным в случае, когда существующая технология и организационные структуры четко определены, хорошо понятны и не требуют дополнительного изучения и реорганизации. В состав DESIGNER/2000 входят удобные средства поддержки этого этапа, позволяющие строить наглядные представления процессов и взаимосвязей между ними и анализировать их с использованием средств мультимедиа. На втором этапе разрабатываются детальные концептуальные модели предметной области, описывающие информационные потребности организации, особенности функционирования и т. д. Результатом являются модели двух типов информационные, отражающие структуру и общие закономерности предметной области, и функциональные, описывающие особенности решаемых задач. На следующей стадии, этапе проектирования, на основании концептуальных моделей вырабатываются технические спецификации будущей прикладной системы определяется структура и состав базы данных, специфицируется набор программных модулей. Первоначальный вариант проектных спецификаций может быть получен автоматически с помощью специальных утилит на основании данных концептуальных моделей И наконец, на этапе реализации создаются программы, отвечающие всем требованиям проектных спецификаций. Использование генераторов приложений, входящих в состав DESIGNER, позволяет полностью автоматизировать этот этап, существенно сократить сроки разработки системы и повысить ее качество и надежность. В соответствии с общей архитектурой инструментальные средства, входящие в состав DESIGNER, разбиваются на следующие компоненты:
Репозиторий - централизованная база данных проекта. Все модели и спецификации, относящиеся к проекту прикладной системы и возникающие на различных этапах ее жизненного цикла, хранятся в централизованной базе данных репозитория. Работа над проектом во многом сводится к работе с этой базой данных вводу и коррекции различных описаний, проверке их согласованности и полноты, преобразованию одних моделей в другие и т. д. Вся информация в репозитории, относящаяся к одной и той же прикладной системе, называется приложением. В общем случае репозиторий может содержать несколько приложений. Средства доступа к репозиторию обеспечивают удобный многооконный объектно-ориентированный интерфейс ко всем элементам репозитария в рамках выбранного приложения. Все данные приложения представляются в виде иерархии типов, двигаясь по которой можно работать с различными объектами, определяя и уточняя их характеристики с помощью универсального окна свойств. Проектирование прикладной системы. На этапе проектирования формируются все спецификации, описывающие структуру и основные компоненты будущей системы. Как и на предыдущем уровне эти спецификации разделяются на информационные и функциональные - на описание базы данных и описание состава программных модулей системы. При описании базы данных указывается, какие таблицы в нее входят, специфицируются основные характеристики этих таблиц, состав столбцов каждой из них, уточняются параметры столбцов (тип значений, ограничения на допустимые значения, значения, принятые по умолчанию, статистические характеристики использования и многие другие), задаются ограничения целостности - логические условия, которые должны выполняться при любом содержании таблиц. Кроме того, описываются дополнительные объекты базы данных ORACLE, такие как индексы, кластеры, последовательности, основное назначение которых связано с повышением эффективности работы с базой данных, ускорением доступа к часто используемой информации. Функциональные возможности системы определяются спецификацией модулей различных типов, основными из которых являются экранные формы, обеспечивающие доступ пользователей к информации базы данных, отчеты, используемые для вывода данных в специализированном виде, удобном для дальнейшего анализа, меню, описывающие логику работы системы, процедурные модули. Предполагается, что эти типы модулей позволяют описать функционирование системы практически в полном объеме, как можно меньше прибегая к использованию дополнительных средств таких, как, например, процедуры, написанные на внешних языках программирования. Это поддерживается, в частности, достаточно развитыми возможностями выполнения вычислений непосредственно в формах и отчетах: например, наличие в формах аппарата триггеров позволяет включать в модуль типа формы алгоритмы обработки практически любой степени сложности. Все спецификации проекта системы разрабатываются на основе моделей концептуального уровня и должны обеспечивать выполнение всех содержащихся в них требований и ограничений. Первоначальный вариант спецификаций можно сформировать автоматически с помощью специальных утилит, к которым относятся:
С помощью утилиты автоматической генерации проекта базы данных по ER-диаграмме будут построены спецификации будущей базы данных ее состав таблиц, перечень столбцов каждой из них, уточнение характеристик столбцов, описание ограничений целостности и т. д. При генерации схемы базы данных по ER-модели каждой сущности ставится в соответствие таблица, атрибутам – столбцы таблиц, а для каждой связи создаются дополнительные столбцы и определяются ограничения целостности типа внешних ключей (foreign key constraint). Подтипы сущностей в ER-модели реализуются в схеме базы данных в виде одной общей таблицы или в виде совокупности нескольких – по одной на каждый подтип. По иерархии функций и диаграммам потоков данных могут быть автоматически сгенерированы спецификации программных модулей прикладной системы, описывающие общие характеристики модулей, с какими таблицами работает каждый из них, возможные действия с этими таблицами и т. д. При этом анализируется диаграмма иерархии функций и для каждой элементарной функции (нижней в иерархии) создается спецификация модуля. Тип модуля устанавливается по определенным правилам в соответствии с указанным для функции способом работы с сущностями. Например, если известно, что функция использует сущности только для чтения информации, то считается, что ей должен соответствовать модуль типа отчет. Предусмотрена также возможность «объединять» некоторые однотипные функции, т. е. создавать один модуль сразу для нескольких различных элементарных функций. Основой для такого «объединения» служит также характер использования функциями сущностей если две функции работают с одними и теми же сущностями и одинаково их используют, то это может считаться основанием для создания для них одного общего модуля. Разработчику предоставляется возможность регулировать уровень «объединения» функций путем выбора одного из имеющегося набора критериев. Для работы со всевозможными спецификациями уровня проектирования в DESIGNER предусмотрен целый набор графических редакторов, каждый из которых ориентирован на спецификации определенного типа. Использование на этом уровне графических моделей-диаграмм, является важной новой особенностью CASE-средств фирмы ORACLE. В предыдущих версиях, как и во многих CASE- системах других фирм, графические диаграммы используются обычно только на концептуальном уровне для ER-моделей, функциональных иерархий и т. д. В то же время, опыт практической деятельности в области CASE-технологий показывает, что использование графических изображений полезно и для представления структуры базы данных, схем взаимодействия программных модулей и т. д. В DESIGNER для этой цели предусмотрены:
3.2.4 Моделирование объекта автоматизацииВ данном разделе приводятся результаты практической части проделанной работы. В начале раздела студент должен определить порядок выполнения работы в виде перечня диаграмм и моделей, которые будут построены. Пример такого перечня представлен ниже. Порядок выполнения работы: 1. Построение диаграммы потоков данных. 2. Построение ER-модели. 3. Создание таблиц БД. 4. Построение диаграммы иерархии функций. В соответствии с определенным порядком производится построение моделей и диаграмм. Элементы полученных диаграмм и моделей должны содержать обозначения. Ниже диаграммы должно быть приведено описание (название, назначение) всех элементов. Ниже приведен пример описания практической части третьего раздела. Диаграмма потоков данных. Диаграмма потоков данных (DFD) – это процессно-ориентированное графическое представление прикладной системы (рисунок 3). Общая модель деловой деятельности представляется в виде совокупности диаграмм, каждая из которых описывает отдельный процесс в виде его разбиения на взаимосвязанные друг с другом шаги или подпроцессы.
Рисунок 3 – Общая схема диаграммы потоков данных
Фреймовая функция (Frame Function) – главная функция, которая будет содержать все подфункции (1). Локальная функция (Local Function) – функция в пределах главной (2). Хранение данных (DataStore) – когерентная коллекция данных (4). Другими словами, представляет данные, физически хранимые в папках, записях, файлах компьютера или базах данных. Потоки (DataFlows) описывают передачу информации или материальных объектов между двумя шагами процессов или между процессом и хранилищем (3). Организационные единицы представляют структуру предприятия или фирмы; допускается иерархическая структура организационных подразделений без ограничения на уровень вложенности (5). В данном проекте у нас представлены четыре диаграммы, четыре хранилища данных и связи между ними. Диаграмму потоков данных можно увидеть на рисунке 4. На диаграмме представлено три функции:
Каждая функция имеет собственное хранилище информации. ER-диаграмма ER-моделирование является важным методом при проектировании систем. Этот метод позволяет организациям формировать четкую картину их информационных потребностей, которую пользователи могут анализировать. В основе модели лежит представление о том, что предметная область состоит из отдельных объектов, находящихся друг с другом в определенных связях. Объекты описываются различными параметрами или атрибутами; однотипные объекты описываются одним и тем же набором параметров и объединяются в множества или классы; такие классы называются сущностями. Конкретные объекты, составляющие класс, называются экземплярами соответствующей сущности. Между сущностями специфицируются взаимосвязи различного вида: один к одному, один ко многим и др (рисунок 5). С помощью ER-диаграммы можно создавать, отображать и манипулировать всеми свойствами сущностей и отношениями между ними. Свойства атрибутов отображаются, используя принятые по умолчанию символы для обозначения обязательных, дополнительных и уникальных атрибутов. Диаграмма поддерживает переносимые отношения.
Рисунок 4 – Диаграмма потоков данных
Рисунок 5 – Общая схема ER-диаграммы
В нашем проекте представлено 4 сущности («шапка» документа, «содержание» документа, справочник агента и справочник товаров). Также необходимо упомянуть о видах связей между сущностями. Все связи в проекте одинаковы и являются связями от одного обязательного множества к другому обязательному множеству. ERдиаграмма представлена на рисунке 6.
Диаграмма иерархии функций Диаграмма иерархии функций (Function Hierarchy Diagrammer) применяется для декомпозиции функций, определения элементарных функций и отображения, каким образом функции используют данные. Данная диаграмма генерируется на основе диаграммы потоков данных. Иерархия функций является дополнением к ER-модели и представляет в виде диаграммы деятельность, выполняемую вашим предприятием. Здесь используется методика функциональной декомпозиции, посредством которой описание бизнес-функции высокого уровня для всего предприятия или его подразделения последовательно разбивается на более детализированные функции.
Рисунок 6 – ER-диаграмма
Функции располагаются иерархично. Иерархия функций показывает информацию, используемую функциями, в рамках сущностей и атрибутов. Каждая функция в иерархии разложена до самого низкого уровня функций (называемых элементарными функциями организации). Элементарные функции станут формами, отчетами и утилитами в завершенном приложении. Для декомпозиции функций, определения элементарных функций и отображения, каким образом функции используют данные, применяется диаграммер иерархии функций (Function Hierarchy Diagrammer). Примеры диаграммы иерархии функций представлена на рисунках 7 и 8.
Рисунок 8 – Диаграмма иерархий функций
Диаграмма серверной модели. Для преобразования концептуальной модели (ER-модели) в физическую используется мастер Database Design Transformer, который вызывается из построителя ER-моделей. Диаграмма серверной модели представлена на рисунке 9.
3.2.5 ЗаключениеВ заключении рекомендуется сделать выводы по проекту, определить пути его внедрения и направления дальнейшего совершенствования.
СПИСОК ЛИТЕРАТУРЫ1. Кондратьев В. Ю. Информационное обеспечение системы управления агропромышленным предприятием, подсистема учета основных средств / В. Ю. Кондратьев, Е. Б.Тюнин // Политематический сетевой электронный научный журнал КубГАУ. – Краснодар, 2005. – № 12. – С. 67–77. 2. Кондратьев В. Ю. Информационное обеспечение системы управления агропромышленным предприятием, подсистема учета банковских и кассовых операций / В. Ю. Кондратьев, А. А. Непомнящий // Политематический сетевой электронный научный журнал КубГАУ. – Краснодар, 2005. – № 12. – С. 48–66. 3. Кондратьев В. Ю. Повышение эффективности управления в сельскохозяйственных предприятиях на основе новых информационных технологий (на материалах предприятий Краснодарского края) : дис. канд. экон. наук / В. Ю. Кондратьев. – Краснодар, 2002. 4. Кумратова А. М. Точный прогноз как эффективный способ снижения экономического риска агропромышленного комплекса / А. М. Кумратова // Политематический сетевой электронный научный журнал КубГАУ. – Краснодар, 2014. – № 103. – С. 293–311. 5. Пескова С. А. Сети и телекоммуникации / С. А. Пескова, А. В. Кузин, А. Н. Волков. – СПб. : Питер, 2006. – 184 с. 6. Попова Е. В. Управление рисками в вопросах безопасности инвестиций в АПК / Е. В. Попова, А. М. Кумратова // Экономическое прогнозирование: модели и методы : материалы X Междунар. науч.-практ. конф. – Воронеж, 2014. – С. 194–200. 7. Рыбалкин И. П. Информационные системы / И. П. Рыбалкин, В. Ю. Кондратьев, Е. Б. Тюнин . Краснодар : КубГАУ, 2008. 200 с. 8. Ткаченко В. В. Предпосылки совершенствования моделей и методов управления производством зерна / В. В. Ткаченко, Л. О. Великанова // Современные проблемы науки и образования. –2008. – № 4. – С. 121–123. 9. Тюнин Е. Б. Интеграция оперативного и управленческого учета в сельхозпредприятиях на основе информационно-аналитических систем / Е. Б. Тюнин // Молодой ученый. – 2012. – № 12. – С. 280–282. 10. Тюнин Е. Б. Совершенствование оперативного управления в сельхозпредприятиях на основе математических и инструментальных методов : автореф. дис. канд. экон. наук / Е. Б. Тюнин; АГУ. – Майкоп, 2008. 11. Тюнин Е. Б. Геоинформационные технологии в управлении производством сельхозпредприятий / Е. Б. Тюнин, В. Ю. Кондратьев // Электронный бизнес: проблемы, развитие и перспектива : материалы VII Всеросс. науч.-практ. конф. – Воронеж : ВГУ, 2008. – С. 121–124. 12. Тюнин Е. Б. Информационно-аналитическое обеспечение процесса оперативного управления в сельскохозяйственном предприятии / Е. Б. Тюнин // Журнал научных публикаций аспирантов и докторантов. – Курск, 2008. – № 2. – С. 23–25. 13. Тюнин Е. Б. Распределенные информационные системы в управлении сельскохозяйственным предприятием / Е. Б. Тюнин // Журнал научных публикаций аспирантов и докторантов. – Курск, 2012. – № 11. 14. Тюнин Е. Б. Электронная карта полей как инструмент информационно-аналитического обеспечения оперативного управления производством / Е. Б. Тюнин, М. И. Семенов, В. Ю. Кондратьев // Труды Кубанского государственного аграрного университета. – Краснодар : КубГАУ. – № 4 (19). – 2009. 15. Тюнин Е. Б. Совершенствование оперативного управления в сельхозпредприятиях на основе математических и инструментальных методов : автореф. дис. … канд. экон. наук . – Майкоп : АГУ, 2008. 16. Тюнин Е. Б. Современные системы автоматизации управления технологическими процессами: лабораторный практикум / Е. Б. Тюнин, М. И. Семенов . – Краснодар: КубГАУ, 2012. – 104 с. 17. Тюнин Е. Б. Проектирование информационных систем / Е. Б. Тюнин, В. Ю. Кондратьев . – Краснодар: КубГАУ, 2012. -240 с. 18. Тюнин Е. Б. Информационно-аналитическое обеспечение процесса оперативного управления в сельскохозяйственном предприятии / Е. Б. Тюнин // Журнал научных публикаций аспирантов и докторантов. – 2008. – №2 (20). – С. 23-25. 19. Тюнин Е. Б. Совершенствование оперативного управления в сельхозпредприятиях на основе математических и инструментальных методов (на примере отраслей растениеводства): дис. канд. экон. наук / Е. Б. Тюнин . –Майкоп : АГУ, 2008. 20. Тюнин Е. Б. Информационные технологии в деловой коммуникации / Е. Б. Тюнин . – Краснодар : КубГАУ, 2015. – 74 с.
ПРИЛОЖЕНИЯ
Приложение АПеречень базовых тем курсовых работ по специальности 09.03.02 – Информационные системы и технологии
Приложение БМИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ Факультет прикладной информатики Кафедра информационных систем
КУРСОВАЯ РАБОТА по дисциплине «Информационные технологии»
на тему: Технология управления кассовыми операциями в предприятии
Выполнил: студент группы ИТ1004 _________________ Петров И. И.
Руководитель: канд. экон. наук, доцент Тюнин Е. Б.
Дата защиты_______________ Оценка_____________
Краснодар 2016
Приложение ВМИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования КУБАНСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ Факультет прикладной информатики Кафедра___________________________________________________________ УТВЕРЖДАЮ Заведующий кафедрой _____________________ _____________________ (подпись, инициалы, фамилия)
«___»___________20__г.
ЗАДАНИЕ НА КУРСОВУЮ РАБОТУ Студент ___________________________________ код ______ группа _______ по дисциплине _________________________________________________ (название дисциплины) Тема______________________________________________________________ __________________________________________________________________ __________________________________________________________________ утверждена на заседании кафедры от «___» ________20__г. Протокол №____
ОСНОВНЫЕ ВОПРОСЫ ТЕМЫ _______________________________________________________________________________________________________________ Руководитель курсовой работы _____________________________________ (личная подпись) И.О. Фамилия Срок сдачи курсовой работы «_____ » ___________________20__ г. Задание к исполнению принял________________________________________ (личная подпись студента) И.О. Фамилия РЕЦЕНЗИЯ
На курсовую работу студента (ки) __________________________________ (Фамилия И.О.) __________________________________________________________________ В рецензии необходимо отметить следующие моменты: актуальность и практическую значимость; соответствие содержания работы целевой установке, полнота изложения материала, аргументированность, самостоятельность, уровень обоснованности и эффективности решений; конкретную оценку выполненной работы и ее соответствие требованиям ГОС по специальности; вопросы, которые не получили достаточного освещения в курсовой работе, либо совсем отсутствуют. ______________________________________________________________________________________________________________
_______________________________
ОГЛАВЛЕНИЕ ВВЕДЕНИЕ.. 3 1 ЦЕЛИ И ЗАДАЧИ ВЫПОЛНЕНИЯ КУРСОВОЙ РАБОТЫ... 4 2 УКАЗАНИЯ ПО ВЫПОЛНЕНИЮ И ЗАЩИТЕ КУРСОВОЙ РАБОТЫ 5 2.1 Цель и задачи курсовой работы.. 5 2.2 Этапы выполнения курсовой работы.. 6 2.3 Базовая тематика курсовых работ. 6 2.4 Требования к содержанию курсовой работы.. 7 2.5 Требования к оформлению пояснительной записки. 7 3 СТРУКТУРА И СОДЕРЖАНИЕ КУРСОВОЙ РАБОТЫ... 12 3.1 Общее содержание курсовой работы.. 12 3.2 Содержание разделов курсовой работы.. 12 3.2.1 Введение. 12 3.2.2 Анализ предметной области. 13 3.2.3 Обзор инструментария Oracle Designer 17 3.2.4 Моделирование объекта автоматизации. 22 3.2.5 Заключение. 29 СПИСОК ЛИТЕРАТУРЫ... 30 ПРИЛОЖЕНИЯ.. 33 ПРИЛОЖЕНИЕ А.. 34 ПРИЛОЖЕНИЕ Б. 36 ПРИЛОЖЕНИЕ В.. 37
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
Методические указания Составитель: Тюнин Евгений Борисович Подписано в печать 24.10.2016. Формат 60 × 84 1/16. Усл. печ. л. – 2,3. Уч.-изд. л. – 1,8. Тираж 50 экз. Заказ №
Типография Кубанского государственного аграрного университета. 350044, г. Краснодар, ул. Калинина, 13 | |
|
| |
| Просмотров: 681 | Загрузок: 0 | | |
