разработка кода программного продукта на основе готовых спецификаций

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

ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

«ОРЕНБУРГСКИЙ КОЛЛЕДЖ ЭКОНОМИКИ И ИНФОРМАТИКИ»

(ГАПОУ «ОКЭИ»)

ОТЧЁТ

ОКЭИ 09.02.03.9 0 16. 32 П

Содержание

1 Определение модуля для разработки программного кода……………………

2 Выбор необходимого программного обеспечения…………………………..

3 Осуществление разработки кода программного продукта на основе спецификаций на уровне модуля. Построение блок-схемы разработка программного кода………………………………………………………………………………….

4 Выполнение тестирования программного модуля……………………..

5 Выполнение отладки программных модулей с исполнением специальных программных средств……………………………………………………………………

6 Осуществление оптимизации программного кода модуля…………………

Определение модуля для разработки программного кода

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

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

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

Мной была разработана форма, которая содержат модули для удобства работы такие как:

-модуль на добавление;

-модуль на удаление;

-модуль на редактирование;

-модуль для перехода в накладную;

Выбор необходимого программного обеспечения

Для разработки модуля была выбрана среда разработки Microsoft Visual Studio 2008.

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

За прохождение практики была разработана форма, в которой созданы модули, код, представлен в (Приложении А):

-Модуль на добавление:

В этом модуля добавляются записи (вид товар, название товара, количество в отделе, цена за единицу) в таблицу «Товар» Блок-схема представлена (см. Рисунок 1).

Рисунок 1 – Блок-схема модуля «добавление»

-Модуль на редактирование/сохранение:

В этом модуле редактируются записи в таблице «Товар» а далее сохраняются и в измененном виде заносятся в таблицу. Блок-схема представлена (см. Рисунок 2).

Рисунок 2 – Блок-схема модуля «редактирование/сохранение»

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

-Модуль на вывод накладной:

Этот модуль будут открывать отчет «Накладная» по дате получения. Блок-схема представлена (см. Рисунок 4).

Рисунок 4 – Блок-схема модуля «Вывод накладной»

При нажатии на этот модуль форма будет закрыта.

Источник

Отчет по производственной практике (по профилю специальности) пп. 01 Разработка программных модулей программного обеспечения для компьютерных систем

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное учреждение

«Российский экономический университет им. Г.В. Плеханова»

Техникум Пермского института (филиала)

Отчет
по производственной практике (по профилю специальности)

ПП.01 Разработка программных модулей программного обеспечения

для компьютерных систем

(индекс по РУП и наименование учебной практики)
Профессионального модуля ПМ.01 Разработка программных модулей

программного обеспечения для компьютерных систем

(индекс по РУП и наименование учебной практики)
Специальность 09.02.03 Программирование в компьютерных системах

Студент __________ Новиков Егор Николаевич

(подпись) (фамилия, имя, отчество)

Руководитель практики от организации
_____________________________________________________________________________

(подпись) (фамилия, имя, отчество)
МП «____»__________________ 201_ года

Руководитель практики от техникума
_________________________ Ильин И.В.

(подпись) (фамилия, имя, отчество)
«____»__________________ 201_ года

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

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

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

Штат отдела ИТО состоит из 4 человек, включая руководителя Бузмакова Д.В. (рис.1).

Рис. 1. Структура отдела ИТО
1.2. Технические и программные средства организации

В рамках практики был проведен анализ имеющегося ПО организации. На предприятии используются различные ОС начиная с Windows XP и заканчивая Windows 7(клиентские) и серверные Windows: Server 2000,2003, 2008R2, 2012, Linux: Debian.

2.1. Разработка приложений обработки данных на ассемблере (задание №1).

Задание выполнено в среде c++. Ниже приведен программный код:

Источник

Методические указания «Разработка спецификаций к Программному продукту»

Методические указания к проектированию спецификаций программного обеспечения

по УП ПМ.01 «Разработка программных модулей программного обеспечения для компьютерных систем»

специальности 09.02.03 «Программирование в компьютерных системах»

Назначение спецификации

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

План разработки спецификации

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

1.2 Соглашения, принятые в документах

1.3 Границы проекта

2.1 Общий взгляд на продукт

2.2 Классы и характеристики пользователей

2.3 Операционная среда

2.4 Ограничения дизайна и реализации

2.5 Предположения и зависимости

3.x Функция системы X

3.x.2 Функциональные требования

4. Требования к данным

4.1 Логическая модель данных

4.4 Получение, целостность, хранение и утилизация данных

5. Требования к внешним интерфейсам

5.1 Пользовательские интерфейсы

5.3 Интерфейсы оборудования

5.4 Коммуникационные интерфейсы

6. Атрибуты качества

6.1 Удобство использования

6.4 Техника безопасности

7. Требования по интернационализации и локализации

8. Остальные требования

Приложение A. Словарь терминов

Приложение Б. Модели анализа

Методические указания по заполнению спецификации

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

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

Описание разделов шаблона спецификации требований

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

1.2 Соглашения, принятые в документах

1.3 Границы проекта

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

2.1 Общий взгляд на продукт

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

2.2 Классы и характеристики пользователей

2.3 Операционная среда

2.4 Ограничения дизайна и реализации

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

2.5 Предположения и зависимости

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

3.x Функция системы X

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

3.x.2 Функциональные требования

4. Требования к данным

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

4.1 Логическая модель данных

Модель данных это визуальное представление объектов и наборов данных, которые будет обрабатывать система, а также отношений между ними. Существует много видов нотации для моделирования данных, в том числе диаграммы отношений «сущность–связь» и диаграммы классов UML. Можно включить модель данных для бизнес-операций, выполняемых системой или логическое представление данных, с которыми будет работать система. Это не то же самое, что модель данных реализации, которая реализуется в виде дизайна базы данных.

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

4.4 Получение, целостность, хранение и утилизация данных

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

5. Требования к внешним интерфейсам

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

Две команды разработчиков ПО объединились для создания флагманского продукта компании A. Datum Corporation. Команда, отвечающая за базу знаний, создала сложное ядро анализа на C++, а команда, отвечающая за приложения, реализовала пользовательский интерфейс на Java. Подсистемы взаимодействовали между собой посредством API. К сожалению, команда, отвечающая за базу знаний, периодически модифицировала API, в результате чего систему не удавалось собрать и запустить на выполнение должным образом. Команде, отвечающей за приложения, требовалось несколько часов, чтобы распознать все проблемы и определить основную причину — изменение API. Эти изменения не согласовывались, не доводились до сведения всех заинтересованных в проекте лиц и не были скоординированы с соответствующими модификациями в коде на Java. Изменение интерфейса обязательно требует уведомления об этом людей, группы или системы на другой стороне этого интерфейса. Интерфейс скрепляет компоненты вашей системы — включая пользователей, поэтому необходимо документировать детали интерфейса и синхронизировать модификации в процессе управления изменениями в проекте.

5.1 Пользовательские интерфейсы

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

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

• размер и конфигурация экрана или ограничения разрешения;

• стандартные кнопки, функции или ссылки перемещения, одинаковые для всех экранов, например кнопка справки;

• стандарты отображения и текста сообщений;

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

• стандарты конфигурации интерфейса для упрощения локализации ПО;

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

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

5.3 Интерфейсы оборудования

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

5.4 Коммуникационные интерфейсы

6. Атрибуты качества

6.1 Удобство использования

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

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

6.4 Техника безопасности

7. Требования по интернационализации и локализации

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

8. [Остальные требования]

Приложение A. Словарь терминов

Приложение Б. Модели анализа

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

Методические указания по оформлению спецификации

Интервал между текстом предыдущего раздела (подраздела) и заголовком последующего должен быть не меньше 15 мм.

Абзацы в тексте начинаются отступом, равным 15 мм.

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

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

Номер страницы проставляется в центре нижней части листа без точки.

На титульном листе номер страницы не указывается.

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

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

Заголовки пунктов и подпунктов записывают с абзацного отступа строчными буквами (кроме первой прописной).

Переносы слов в заголовках не допускаются. Точка в конце заголовка не ставится.

Наименования структурных элементов «СОДЕРЖАНИЕ», «ВВЕДЕНИЕ», «ЗАКЛЮЧЕНИЕ», «СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ» служат заголовками структурных элементов и печатаются симметрично тексту.

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

Титульный лист является первым листом пояснительной записки. Титульный лист выполняется на листе формата А4 по форме, приведенной в Приложении 1.

Слово «Содержание» записывают в виде заголовка (симметрично тексту) прописными буквами.

Содержание включает: введение;

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

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

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

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

Пункты нумеруются по порядку в пределах раздела. Например, 3.2 — пункт 2 раздела 3.

Подпункты нумеруются в пределах пункта, например, 3.2.1.

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

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

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

Иллюстрации (графики, схемы, диаграммы) следует располагать непосредственно после текста, в котором они упоминаются впервые, или на следующей странице. На все иллюстрации должны быть даны ссылки.

Чертежи, графики, диаграммы, схемы должны соответствовать требованиям Единой системы конструкторской документации (ЕСКД).

Иллюстрации, за исключением иллюстрации приложений, нумеруются арабскими цифрами сквозной нумерацией. Допускается нумерация в пределах раздела (разбиение на пункты во внимание не принимается). Например, рисунок 3.1 — рисунок первый в третьем разделе. В общем случае рисунок может содержать:

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

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

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

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

При ссылках на иллюстрации следует писать «. в соответствии с рисунком 2».

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

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

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

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

В конце заголовков в подзаголовков знаки препинания не ставят.

Заголовки указывают в единственном числе.

Диагональное деление головки таблицы не допускается.

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

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

Единицы измерения физических величин указываются через запятую после заголовка строки или заголовка (подзаголовка) графы.

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

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

Цифровые и подобные им данные заменять кавычками нельзя.

Если какие-либо данные в таблице не приводят, то в соответствующей графе ставят прочерк.

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

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

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

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

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

Формулы, помещаемые в приложениях, должны нумероваться отдельной нумерацией с добавлением обозначения приложения, например: (А. 1).

Ссылки в тексте на порядковые номера формул дают в скобках.

В соответствии с ГОСТ 7.32-2003 список составляется в порядке появления ссылок в пояснительной записке. В список включают все источники, на которые есть ссылки в пояснительной записке.

Пример сведений о периодическом издании: Колесов А. П., Павлова О. М. Заключительные советы тем, кто программирует на VB & VBA // Компьютер­Пресс № 6 / 2002, с. 35-38.

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

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

Каждое приложение должно начинаться с нового листа с указанием наверху посередине страницы слова «ПРИЛОЖЕНИЕ» и его обозначения.

Приложения оформляют как продолжение пояснительной записки на последующих ее страницах. Для приложений можно использовать кегль 8-10.

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

Приложения обозначают заглавными буквами русского алфавита, начиная с А, за исключением букв Ё, 3, И, О, Ч, Ь, Ы, Ъ. Если в документе одно приложение, оно обозначается «ПРИЛОЖЕНИЕ А»

Ниже заголовка располагается текст приложения.

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

Рисунки, таблицы и формулы, помещаемые в приложении нумеруют в пределах данного приложения, например: Рисунок Б.1 — рисунок 1 в приложении Б.

Приложения должны иметь общую с остальной частью документа сквозную нумерацию страниц. При необходимости приложение может иметь «СОДЕРЖАНИЕ».

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

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

Порядок номеров приложений и литературных ссылок должен соответствовать порядку появления ссылок на них.

При ссылке на литературный источник указывается его порядковый номер, заключенный в квадратные скобки. Например, [4] или [4, 5, 6].

При первой ссылке на рисунок пишется, например, рисунок 1.4 или (рисунок 1.4).

При повторной ссылке на рисунок пишется, например, см. рисунок 1.4 или (см. рисунок 1.4).

При первой ссылке на таблицу пишется, например, в таблице 2.3 или (таблица 2.3).

При повторной ссылке добавляется слово «см.», например, см. таблицу 2.4 или (см. таблицу 3.1).

При ссылке на приложение пишется полностью слово «приложение» и указывается его номер, например, «. в приложении А» или (приложение Б).

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

Источник