Приложение В титульный лист курсовой работы

 

 

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ФГБОУ ВПО «Казанский национальный исследовательский технический университет им.А.Н. Туполева-КАИ»

Лениногорский филиал

 

 

КУРСОВАЯ РАБОТА

по дисциплине: Технологии программирования

Тема: Алгоритмы сортировки одномерных массивов

 

	Исполнитель:	И.И. Иванов, студент группы 28179
	Руководитель:	Д.И.Киргизов, доцент кафедры ИТ

 

Лениногорск 2015

Приложение Г Унифицированные требования к оформлению курсовых работ студентов

№ п/п	Объект унификации	Параметр унификации
	Формат листа бумаги	А4
	Размер шрифта	14 пунктов
	Название шрифта	Times New Roman
	Междустрочный интервал	Полуторный
	Кол-во строк на странице	28-30 строк (1800 печатных знаков)
	Абзац	1,25 см (5 знаков)
	Поля (мм)	Левое, верхнее и нижнее – 20, правое – 10
	Общий объем без приложений	20-25 страниц машинописного текста
	Объем введения	2-3 стр. машинописного текста
	Объем основной части	15-20 стр. машинописного текста
	Объем заключения	2-2,5 стр. машинописного текста (примерно равен объему введения)
	Нумерация страниц	Сквозная, в нижней части листа, посередине. На титуль-ном листе номер страницы не проставляется
	Последовательность приведения структурных частей работы	Титульный лист. Задание на курсовую работу. Содержа-ние. Введение. Основная часть. Заключение. Глоссарий. Список использованных источников. Список сокращений. Приложения
	Оформление структурных частей работы	Каждая структурная часть начинается с новой страницы. Наименования приводятся с абзаца с прописной (заглавной буквы). Точка в конце наименования не ставится
	Структура основной части	2-3 главы, соразмерные по объему
	Наличие глоссария	Обязательно, не менее 10 понятий
	Состав списка использованных источников	Не менее 10 библиографических описаний документаль-ных и литературных источников
	Наличие приложений	Обязательно
	Оформление содержания (оглав-ления)	Содержание (оглавление включает в себя заголовки всех разделов, глав, параграфов, глоссария, приложений с указанием страниц начала каждой части)

 

Приложение ДСОДЕРЖАНИЕ ПРАКТИЧЕСКОЙ ЧАСТИ

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

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

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

Возможны различные варианты подготовки ТЗ:

· в соответствии с государственным стандартом ГОСТ 34.602-89, предполагающим детальное описание всех возможных аспектов разработки ПО и требующим подготовку значительного по объему документа;

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

· в соответствии с некоторым упрощенным корпоративным шаблоном оформления.

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

1. Введение

1.1. Наименование продукта

1.2. Краткая характеристика области применения

2. Основание для разработки

2.1. Документ, на основании которого ведется разработка

2.2. Организация, утвердившая документ

3. Назначение разработки

4. Требования к разработке

4.1. Требования к функциональным характеристикам

4.2. Требования к надежности

4.3. Требования к составу и параметрам технических средств

4.4. Требования к информационной и программной совместимости

5. Требования к программной документации

6. Технико-экономические показатели

7. Этапы разработки

8. Порядок контроля и приемки.

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

 

КОДИРОВАНИЕ

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

Стандарт оформления кода обычно принимается и используется некоторой группой разработчиков программного обеспечения с целью единообразного оформления совместно используемого кода. Такой стандарт сильно зависит от используемого языка программирования. Например, стандарт оформления кода для языка C/C++ будет серьёзно отличаться от стандарта для языка BASIC.

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

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

Пример:

class Raster;

class ImageSprite;

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

Пример:

Run(); RunFast(); GetBackground(); CheckModel(); isValidMove(5,2,5,4);

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

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

Обычно таким переменные дают следующие имена:

· i, j, k, m, n для целых типов;

· c, d, s для символьных типов.

Константы.Имена переменных, объявленных константами внутри класса, и ANSI констант должны содержать символы только в верхнем регистре с словами разделяемыми символом подчеркивания («_»). ANSI констант следует избегать для упрощения отладки.

Пример:

static final int MIN_WIDTH = 4; static final int MAX_WIDTH = 999; static final int GET_THE_CPU = 1;

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

Пример:

Строки

int *ptr; ptr = new int [100];

ptr[0] = 0;

Следует оформить следующим образом:

int *ptr;

ptr = new int [100];

ptr[0] = 0;

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

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

1) определения переменных:

char str[80];

int counter = 0;

fgets( str, 79, infile);

counter++;

2) последовательности однотипных инструкций или директив:

#include

#include

#include

#define NAME_SIZE 256

#define MAX_LEN 3000

3) функции:

int main()

{

. . .

}

char *get_name(FILE *f)

{

. . .

}

4) любые логически завершенные блоки кода:

printf( "Enter size and delta: " ); // Блок ввода данных

scanf( "%d", &size );

scanf( "%f", &delta );

for( i=0; i < size; i++ ) //Блок использования данных

{

a[i] -= delta;

b[i] += delta;

}

Комментарии.Большинство специалистов сходятся во мнении, что комментарии должны объяснять намерения программиста, а не код; то, что можно выразить на языке программирования, не должно выноситься в комментарии – в частности, надо использовать говорящие названия переменных, функций, классов, методов и пр., разбивать программу на лёгкие для понимания части, стремиться к тому, чтобы структура классов и структура баз данных были максимально понятными и прозрачными и т. д.

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

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

Комментировать следует:

· заголовок файла, описывая содержимое данного файла;

· заголовок функции, поясняя назначение ее аргументов и смысл самой функции;

· вводимые переменные и структуры данных;

· основные этапы и особенности реализуемых алгоритмов;

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

Некоторые комментарии программисты используют в ходе своей работы. Подобные комментарии особенно полезны, когда над одним кодом работает несколько разработчиков. Так, комментарием TODO обычно помечают участок кода, который программист оставляет незавершённым, чтобы вернуться к нему позже. Комментарий FIXME помечает обнаруженную ошибку, которую решают исправить позже. Комментарий XXX или ZZZ обозначает найденную критическую ошибку, без исправления которой нельзя продолжать дальнейшую работу.