Математическое обеспечение и оценка трудоемкости алгоритма

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

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

Язык разработки

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

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

Типовая структура раздела следующая:

1. Общие сведения о языке (класс, автор, краткая история, среды разработки).

2. Поддерживаемые парадигмы программирования.

3. Типизация.

4. Особенности компилятора/интерпретатора.

5. Реализованные типы и структуры данных.

6. Объектно-ориентированные возможности.

7. Функциональные возможности.

8. Дополнительные сведения (управление памятью, исключения, расширения языка и т.п.).

Реализация системы

В разделе реализации системы необходимо описать три основные этапа: проектирование, кодирование и тестирование.

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

• общая архитектура системы (представление о компонентах системы, взаимосвязях между компонентами, а также правилах, регламентирующих эти взаимосвязи) и её связи с внешней средой;

• устройство (структура и алгоритм работы) ключевых компонентов;

• объектно-ориентированная структура (иерархия классов с основными методами и полями);

• пользовательский интерфейс.

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

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

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

Например, для языка Java [3], [4] можно придерживаться следующего стандарта оформления кода:

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

• количество операторов на строчке должно быть равно 1.

• все операторы, входящие в составной оператор (все, что находится между { } в языке Java) должны быть сдвинуты вправо на 5 (пять) символов (используйте табуляцию, настройте редактор, если он меньше);

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

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

• тип переменной необходимо указывать для КАЖДОЙ из них. На одной строчке - одна переменная. Идентификаторы (названия переменных, типов, подпрограмм) должны быть значимыми настолько, чтобы читающий текст программы мог понимать смысл всех переменных и т.д. без присутствия рядом автора.

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

В исходном коде обязательно наличие комментариев.

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

Комментировать необходимо:

• заголовок файла, пакета и класса описывающий их содержимое;

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

• ключевые для алгоритма переменные и структуры данных;

• наиболее важные основные этапы и особенности реализуемых алгоритмов.

Недопустимо комментировать каждую строку кода. При защите работы это рассматривается как незнание языка программирования.

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

Как минимум, тестирование должно предусматривать последовательное выполнение следующих этапов:

• разработку плана тестирования и тестовых заданий;

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

• выполнение тестовых процедур нагрузочного тестирования;

• формирование заключения по результатам.

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

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

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

Руководство пользователя (руководство по эксплуатации, руководство оператора) – документ, назначение которого – предоставить людям помощь в использовании некоторой системы. Документ входит в состав технической документации на систему и, как правило, подготавливается техническим писателем.

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

Типичное руководство пользователя содержит:

• Аннотацию, в которой приводится краткое изложение содержимого документа и его назначение

• Введение, содержащее ссылки на связанные документы и информацию о том, как лучше всего использовать данное руководство

• Страницу содержания

• Главы, описывающие, как использовать, по крайней мере, наиболее важные функции системы

• Глава, описывающая возможные проблемы и пути их решения

• Часто задаваемые вопросы и ответы на них

• Где ещё найти информацию по предмету, контактная информация

• Глоссарий и, в больших документах, предметный указатель

Руководство пользователя разрабатывается на основе стандарта РД 50-34.698-90 АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ.