2 Содержание учебной практики

2.1 Цель и задачи

Целью учебной практики является:

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

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

• приобретение знаний и навыков наглядного представления решений на этапах разработки программ, используя для этого графические средства языка UML (диаграммы вариантов использования, классов, компонентов, активности) или схемы алгоритмов, программ, данных и систем (ГОСТ 19.701 – 90);

• подготовка к изучению специальных дисциплин, таких как «Объектно-ориентированное программирование», «Структуры данных», «Функциональное и логическое программирование» и ряду других.

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

2.2 Бюджет времени студента

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

2.3 Темы заданий на практику

2.3.1 Тематика общего задания

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

2.3.2 Тематика индивидуальных заданий

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

Разработка программ осуществляется в среде визуального программирования (например, Delphi).

Основные темы индивидуальных заданий:

• формирование и обработка массивов;

• обработка текстовой информации (строки, текстовые файлы, простые текстовые редакторы);

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

• формирование и обработка динамических структур данных (динамические массивы, списки и другие структуры);

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

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

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

• рекурсия и рекурсивные программы;

• игровые и обучающие программы.

3 Процесс разработки программных средств

3.1 От программы к программному продукту

Рассмотрим рисунок 3.1. В левом верхнем углу рисунка 3.1 находится программа. Она является завершенным продуктом, пригодным для запуска своим автором на системе, на которой была разработана (например, Delphi). Есть два способа, которыми программу можно превратить в более полезное, но и более дорогое программное средство (ПС). Эти два способа представлены по краям рисунка.

Рисунок 3.1 Эволюция системного программного продукта

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

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

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

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