Составитель: доц., к. т. н. Зеленко Л.С.

Составитель: доц., к. т. н. Зеленко Л.С.

УДК 004.4 (075)

Методические указания к лабораторному практикуму по дисциплине «Технологии программирования» / Самарский аэрокосмический ун-т; Сост. Зеленко Л.С. Самара, 2014. – с. 65.

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

Указания выполнены на кафедре программных систем.

Печатаются по решению редакционно-издательского совета Самарского государственного аэрокосмического университета им. академика С. П. Королева.

Рецензент ‑ канд. техн. наук, доцент Симонова Е.В.

СОДЕРЖАНИЕ

Технология быстрой разработки приложений RAD.. 5

Лабораторная работа №1 Разработка технического задания на программную систему. 8

Лабораторная работа № 2 Описание и анализ предметной области. 15

Лабораторная работа № 3 Постановка задачи. 18

Лабораторная работа № 4 Разработка структуры системы.. 20

Лабораторная работа № 5 Разработка спецификации требований. 23

Лабораторная работа № 6 Разработка прототипа интерфейса пользователя системы.. 28

Лабораторная работа № 7 Разработка структур данных и классов. 32

Лабораторная работа № 8 Разработка алгоритмов обработки данных. 36

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

Оформление отчета. 43

Список использованных источников. 46

Приложение А Пример оформления титульного листа. 49

Приложение Б Пример оформления реферата. 51

Приложение В Пример оформления технического задания на разработку ПС.. 52

Приложение Г Пример оформления приложения к техническому заданию.. 55

Приложение Д Структура содержания пояснительной записки. 59

Приложение Е Структура содержания руководства пользователя. 62

Технология быстрой разработки приложений RAD

Один из подходов к разработке программного обеспечения (ПО) в рамках спиральной модели ЖЦ – получившая широкое распространение методология (технология) быстрой разработки приложений RAD (Rapid Application Development) [1, 2]. Данная модель очень хорошо подходит к разработке учебных программ, т.к. включает в себя три составляющие:

Ø небольшую команду программистов (от 2 до 4 человек);

Ø короткий, но тщательно проработанный производственный график (от 2 до 4 мес.);

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

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

Жизненный цикл (ЖЦ) ПО по технологии RAD состоит из четырёх фаз (рисунок 1):

1. Анализа и планирования требований;

2. Проектирования;

3. Построения;

4. Внедрения.

Рассмотрим адаптированный вариант технологии RAD.

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

Результатом фазы должны быть: список расставленных по приоритету функций будущей ПС; предварительная функциональная модель ПС; предварительная информационная модель ПС.

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

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

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

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

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

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

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

В заключение перечислим основные принципы технологии RAD:

Ø разработка приложений итерациями;

Ø необязательность полного завершения работ на каждом этапе ЖЦ;

Ø обязательное вовлечение пользователей на этапе разработки;

Ø тестирование и развитие проекта одновременно с разработкой;

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

ЛАБОРАТОРНАЯ РАБОТА №1
разработка технического задания на программную систему

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

Тема проекта выдается преподавателем (в дальнейшем это руководитель проекта) на первом занятии, в течение первой работы в соответствии с темой проекта команда студентов разрабатывает техническое задание (ТЗ) по форме, приведенной в приложении А. Разработку ТЗ можно считать началом первой фазы ЖЦ будущей ПС.

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

Техническое задание состоит из трех частей:

1) содержание задания, в котором перечисляются все основные составные этапы выполнения проекта;

2) исходные данные к проекту;

3) календарный план выполнения работ.

Часть 1 – «Содержание задания». Данная часть ТЗ фиксирована, в ней перечислены основные составные этапы выполнения проекта. При разработке ПС в рамках лабораторного практикума и в дальнейшем при выполнении курсового проекта будут использоваться две основные методологии: объектно-ориентированного анализа и проектирования (ООАП) и методология структурного проектирования [3].

ООАП (Object-Oriented Analysis/Design) ‑ технология разработки программных систем, в основу которых положена объектно-ориентированная методология представления предметной области в виде объектов, являющихся экземплярами соответствующих классов [4]. Методология ООАП тесно связана с концепцией автоматизированной разработки программного обеспечения (Computer Aided Software Engineering, CASE) и языком моделирования UML (Unified Modeling Language).

Методология объектно-ориентированного анализа и проектирования используется при выполнении лабораторной работы №2 – описании и анализе предметной области, где студенты должны выявить взаимосвязи между основными информационными объектами ПС, определить их характеристики и порядок взаимодействия.

Методология структурного проектирования применяется на первой фазе проектирования (лабораторная работа №3) при разделении системы на подсистемы, здесь используется принцип проектирования «сверху вниз». За каждым студентом закрепляется определенный перечень работ (обычно это разработка отдельной подсистемы), выполнение которых в дальнейшем контролирует преподаватель.

Часть 2 – «Исходные данные к проекту» включает в себя следующие подразделы:

1. Характеристики объекта автоматизации (или управления);

2. Требования к информационному обеспечению.

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

4. Требования к программному обеспечению.

5. Общие требования к проектируемой системе.

6. Перечень дополнительных работ (если необходимо).

Характеристики объекта автоматизации. Здесь указываются общие характеристики объекта автоматизации, характерные для рассматриваемой предметной области:

a) полное название объекта (ов);

b) условия его функционирования;

c) количественные и качественные показатели объекта, которые являются ограничениями процесса функционирования.

В качестве примера рассмотрим проект «Автоматизированная система составления и разгадывания линейного кроссворда по выбранной теме», ТЗ на который приведено в приложении Б.

Понятие «объект автоматизации» в явном виде в ГОСТ 34.602-89 [2] нигде не определено, но если внимательно прочитать п. 2.4.1. «В подразделе «Назначение системы» указывают вид автоматизируемой деятельности (управление, проектирование и т. п.) и перечень объектов автоматизации (объектов), на которых предполагается ее использовать»[1], то из него следует, что под «объектами автоматизации» авторы понимали вовсе не процессы. Будем считать, что объектом автоматизации может быть только материальный (интеллектуальный) объект ‑ организация, магазин, цех, отдел, и так далее.

Комментарии к примеру. Из названия темы следует, что в данном случае объект автоматизации – это линейный кроссворд, а виды автоматизируемой деятельности – это процессы:

1) составления/ генерирования кроссворда;

2) разгадывания кроссворда;

3) работы со словарем понятий.

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

Для каждого процесса в ТЗ должны быть указаны количественные показатели-ограничения, для того, чтобы их правильно выбрать, необходимо знать начальные сведения о структуре самого объекта, каким образом будет проходить его построение и разгадывание. Отправной точкой является определение линейного кроссворда (ЛК). Итак, ЛК – это «цепочка слов, которая строится методом стыкования, где последняя буква первого слова является первой буквой второго и т. д. В чайнворде, как и в кроссворде, используются только имена существительные в именительном падеже и единственном числе» [5]. Так как ЛК строится из слов, то необходимо указать ограничение на длину слова: минимальную длину слова можно определить равную 3, а максимальную – 15, потому что чаще всего кроссворды будут составляться на бытовые темы и сам ЛК не должен быть очень простым. Чтобы ЛК было интересно разгадывать, он не должен быть очень коротким, поэтому минимальное количество слов, например, 5, а максимальное – 15. Идем дальше: «слова в чайнворде не пересекаются, а только стыкуются друг с другом. Иногда цепочку слов изгибают для придания сетке причудливой формы. Длинная изогнутая цепочка может неоднократно пересекать саму себя, как слова в кроссворде, такая головоломка обычно называется кроссчайнвордом». Исходя из этого, можно задать следующее ограничение – на форму отображения ЛК: обычная (линейная), спираль, змейка, W-образная. «В линейных кроссвордах слова могут перекрываться не только одной, но и двумя или тремя буквами, поэтому их длина указывается в скобках при определении к слову» [5], эта часть описания ЛК дает еще одно ограничение: количество букв в пересечении ‑ от 1 до 3. В качестве пожелания, заказчик отметил, что ЛК необходимо строить в двух режимах: ручном и автоматическом (генерация кроссворда), из этого следует еще одно ограничение – составление кроссворда осуществляется с привязкой к словарю понятий. Для того чтобы системы была более универсальной (необходимо обеспечить создание тематических кроссвордов или на общие области знаний), заказчик предложил загружать в систему внешние словари понятий и обеспечить ему возможность редактировать их содержимое. При разгадывании кроссворда могут возникнуть затруднения, поэтому (в соответствии с пожеланиями заказчика) в системе должна быть организована система подсказок, количество которых можно связать с количеством слов – не менее 1 и не более 10% от количества слов.

Требования к информационному обеспечению. Разработка информационного обеспечения (ИО) – наиболее важная часть проекта, она может оказать существенное влияние на весь процесс разработки, поэтому уже на стадии разработки ТЗ необходимо определить:

1) на основании каких документов разрабатывается методическое и информационное обеспечение системы (нормативные и другие документы);

2) перечень исходных данных:

a) какие массивы данных используются и в каких форматах;

b) на каких носителях эти данные будут поставляться в систему;

3) перечень выходных данных:

a) какие массивы данных будут являться результатом работы ПС;

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

c) какие требования по целостности данных и их защите должны быть выполнены в проектируемой системе.

Расчет объема ОЗУ

Для расчета необходимого объема ОЗУ воспользуемся следующей формулой:

V_ОЗУ = V_ОС + V_ПР + [V_СПО] + [V_БД],

где V_ОС – ОЗУ, занимаемое операционной системой (256 Мб);

V_ПР – ОЗУ, которое займет само приложение (не превысит 8 Мб);

V_СПО – ОЗУ, занимаемое СУБД и другим сопутствующим ПО (оценим его сверху значением в 128 Мб);

V_БД – объем данных из базы, который может быть одновременно загружен в оперативную память (дадим ему оценку сверху в 10 Мб).

Суммарные объемы ОЗУ составит:

V_ОЗУ = 256 Мб + 8 Мб + 128 Мб + 20 Мб = 412 Мб.

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

Диаграмма модулей

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

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

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

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

Комментарии к примеру. На рисунке 6 приведен пример диаграммы модулей (фрагмент) для системы составления линейного кроссворда, структурная схема которой описана в лабораторной работе №3. В таблице 8 приведено описание модулей.

Рисунок 6 – Диаграмма модулей системы (фрагмент)

Таблица 8 – Описание модулей системы (фрагмент)

Название модуля	Название файла	Назначение	Подсистема
Генерирование кроссворда	Generation.c	Отвечает за автоматическое составление кроссворда при заданных параметрах	Подсистема генерирования кроссворда
Работа со словарем	Dict.c	Отвечает за редактирование словаря с понятиями и их определениями	Подсистема работы со словарем
Составление/ редактирование кроссворда	Rewrite_Cross.c	Отвечает за редактирование кроссворда	Подсистема ручного составления
Разгадывание кроссворда	Unravel.c	Отвечает за разгадывание кроссворда	Подсистема разгадывания кроссворда

Выбор и обоснование комплекса технических средств системы

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

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

- ввод данных с клавиатуры;

- управление курсором манипулятором типа «мышь»;

- вывод информации на дисплей и на печать;

- передача информации в БД.

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

- ЭВМ на базе архитектуры х86;

- частота процессора не ниже 500 МГц;

- ОЗУ не менее 512 Мб;

- место на жёстком диске не менее 10Гб;

- разрешение экрана не менее 1024х768 точек;

- манипулятор типа «мышь»;

- клавиатура;

- лазерный принтер (если нужно).

ОФОРМЛЕНИЕ ОТЧЕТА

После приемки реализации студент оформляет пояснительную записку (отчет) к системе со всеми требуемыми приложениями. Пояснительная записка к проекту оформляется в соответствии со стандартом СГАУ [22] и должна содержать:

- титульный лист (пример оформления титульного листа приведен в приложении А);

- задание на ПС (пример технического задания приведен в приложении В);

- реферат (пример реферата приведен в приложении Б);

- содержание (структура содержания приведена в приложении Г);

- введение;

- основная часть;

- заключение;

- перечень принятых сокращений (при наличии);

- перечень принятых терминов (при наличии);

- список использованных источников;

- приложения.

Основная часть пояснительной записки делится на разделы:

1) системотехническая часть;

2) конструкторско-технологическая часть;

3) исследовательская часть (если она оговорена в задании).

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

I. В системотехнической части приводится полное описание логического проекта в соответствии с шагами, приведенными в п.4:

1.1 анализ (описание) предметной области (определение объектов системы и их взаимосвязей, определение внешних и внутренних потоков данных, анализ применяемых методов и математических моделей);

1.2 формулирование постановки задачи (лабораторные работы №2 и №3);

1.3 разработка структурной схемы системы, в которой описывается назначение всех подсистем (лабораторная работа №4);

1.4 спецификация требований к ПС уточняет структурную схему системы, в ее состав входит перечень функций, выполняемых системой; описание внешней информационной среды и перечень исключительных ситуаций (при необходимости) (лабораторная работа №5);

1.5 прототип интерфейса системы (лабораторная работа №6);

1.6 разрабатываются структуры данных и классы объектов, их отношения представляются в виде диаграммы (иерархии) классов, при необходимости разрабатывается концептуальная и логическая модели хранения данных (ER-модель или SHM-диаграмма хранимых данных), определяются структуры потоков данных. Описываются все проектные решения по оптимизации выбранной модели хранения данных, а также по разработке логики процессов обработки данных и управления (лабораторная работа №7);

1.7 производится выбор и обоснование (разработка и описание) алгоритмов, применяемых для обработки данных, описание алгоритмов выполняется с помощью схем алгоритмов (лабораторная работа №8);

1.8 производится выбор и обоснование комплекса программных средств (выбор языка программирования и среды разработки; выбор операционной систем; выбор среды программирования; выбор системы управления базами данных (при необходимости).

II В конструкторско-технологической части обосновываются решения, принятые при реализации логического проекта системы:

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

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

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

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

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

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

Термины и определения должны соответствовать ГОСТ 34.003-90 [6].

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

В приложения выносятся (приложения нумеруются прописными буквами русского алфавита):

- руководство по эксплуатации системы (Приложение А пояснительной записки, номера разделов, рисунков, таблиц, формул должны иметь префикс А (А.1, рисунок А.2 и т.п.)), структура приложения приведена в приложении Д;

- листинги программ (Приложение Б пояснительной записки);

- текст контрольного примера и результаты тестирования системы;

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

Рекомендуемый объем пояснительной записки 40-45 страниц машинописного текста (без приложений).

список использованных источников

1. Вендров, А. М. CASE-технологии. Современные методы и средств проектирования информационных систем. [Текст] / А. М. Вендров – М.: Финансы и статистика, 1999. – 256 с.: ил.

2. Информационная технология. Комплекс стандартов и руководящих документов на автоматизированные системы [Сборник]: //Сборник ГОСТ 34.003-90, РД 50-680-88, РД 50-682-89, ГОСТ 34.201-89 - ГОСТ 34.602.89. - М.: Изд-во стандартов, 1992. -150 с.

3. Зеленко, Л.С. Технологии программирования и программная инженерия (1 часть) [Текст]: учебное пособие / Л.С. Зеленко. – Самара: изд-во СГАУ, 2006. – 96 с.: ил.

4. Леоненков, А.В. Нотация и семантика языка UML [Электронный ресурс]/ А.В. Леоненков. – Интернет-университет информационных технологий. http: //www.intuit.ru/department/pl/umlbasics.

5. Определение линейного кроссворда [Электронный ресурс] ‑ http: //ru.wikipedia.org/wiki/Линейный_кроссворд.

6. СанПиН 2.2.2/2.4.2198-07. Гигиенические требования к персональным электронно-вычислительным машинам и организации работ. Изменение N 1 к СанПиН 2.2.2/2.4.1340-03 [Текст] – Дата введения c 01.07.07. – М.: Бюллетень нормативных и методических документов Госсанэпиднадзора. ‑ № 3. – 2007.

7. ГОСТ 12.1.005-88. Система стандартов безопасности труда. Общие санитарно-гигиенические требования к воздуху рабочей зоны [Текст] – Дата введения 01.01.1989. – М.: Стандартинформ, 2006. – 49 с.

8. ГОСТ 12.1.007-76. Система стандартов безопасности труда. Вредные вещества. Классификация и общие требования безопасности [Текст] – Дата введения 01.01.1977. ‑ М.: Стандартинформ, 2007. – 7 с.

9. Буч, Г. Язык UML. Руководство пользователя [Текст] /Г. Буч, Д. Рамбо, А. Якобсон. ‑ 2-е изд.: Пер. с англ. Мухина Н. – М.: ДМК Пресс, 2006. – 496 с.: ил.

10. Определение кроссворда [Электронный ресурс] ‑ http: //ru.wikipedia.org/
wiki/Кроссворд.

11. Большой Российский энциклопедический словарь [Текст]. ‑ М.: БРЭ, 2003.

12. Вигерс, К. Разработка требований к программному обеспечению [Текст]: Пер. с англ. /К. Вигерс. – М.: Издательский торговый дом «Русская Редакция», 2004. 576с.: ил.

13. Зеленко, Л.С. Программная инженерия. Курс лекций [Текст]: учебное пособие / Л.С. Зеленко. – Самара: изд-во СГАУ, 2012. – 148 с.: ил.

14. Орлик, С. Основы программной инженерии (по SWEBOK). Программные требования [Электронный ресурс] ‑ http: //swebok.sorlik.ru/1_software_
requirements.html.

15. Методика составления спецификаций требований к программному обеспечению, рекомендуемая Институтом Инженеров по Электротехнике и Радиоэлектронике (IEEE-830-1998) [Электронный ресурс] ‑ http: //www.webisgroup.ru/services/
programming/srs/ieee-830-1998/.

16. Соммервиль, И. Инженерия программного обеспечения/ Иан Соммервиль. – М., СПб, Киев: Издательский дом «Вильямс», 2002. – 626 с.: ил.

17. Смит, Дж. Принципы концептуального проектирования баз данных [Текст] // Дж. Смит, Д.Смит // Требования и спецификации в разработке программ. - М.: Мир, 1984. - С.165 - 198.

18. Джексон, Г. Проектирование реляционных баз данных для использования с микроЭВМ [Текст]: /Пер.с анг. - М.: Мир, 1991. - 252 с.

19. Леоненков, А.В. Самоучитель UML [Текст]. – СПб: БВХ-Петербург, 2002. -234 с.

20. Липаев, В.В. Программная инженерия. Методологические основы [Текст]. – М.: Издательство «ТЕИС», 2006. – 609 с.

21. СТО СГАУ 02068410-004-2007. Общие требования к учебным текстовым документам [Текст]: методические указания. - Самара: Изд-во Самар. гос. аэрокосм. ун-та, 2007. - 30 с.

22. ГОСТ 19.701-90 (ИСО 5807-85). ЕСПД. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения. – М.: Изд-во стандартов, 1991. - 26 с.

23. В.Турский. Методология программирования. М.: МИР, 1981 – 186с.

Приложение А
Пример оформления титульного листа

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

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ «САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ ИМЕНИ АКАДЕМИКА С. П. КОРОЛЕВА»
(НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ) (СГАУ)

Факультет информатики

Кафедра программных систем

ОТЧЕТ
по лабораторному практикуму по дисциплине
«Технологии программирования» на тему
«Автоматизированная система генерирования
линейного кроссворда по выбранной теме»

Выполнили:
студенты гр.6401 Б 348
Иванов В.В.
Петров А.И.
Руководитель проекта:
доцент каф. ПС Зеленко Л.С.

Дата сдачи:

Оценка:

Самара 2014

Приложение Б
Пример оформления реферата

РЕФЕРАТ

Пояснительная записка 35 с, 14 рисунков, 5 таблиц[12], 12 источников, 2 приложения.

ДЕРЕВО ПОИСКА, ГЕНЕРАТОР КРОССВОРДОВ, ГОЛОВОЛОМКА, СЛОВАРЬ ТЕРМИНОВ, ВАРИАНТ ОТОБРАЖЕНИЯ, РАЗГАДЫВАНИЕ

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

Программа написана на языке Object Pascal в среде Delphi v.6.0 и функционирует под управлением операционной системы Windows’2003.

ПРИЛОЖЕНИЕ В
Пример оформления технического задания на разработку ПС

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

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ
ИМЕНИ АКАДЕМИКА С.П. КОРОЛЕВА
(НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ)» (СГАУ)

Факультет информатики

Кафедра программных систем

ЗАДАНИЕ

на лабораторный практикум по дисциплине

«Технологии программирования»

студенту группы № 6401 Б 348
Иванову И.И.
Петрову П.П.

1. Тема проекта: «Автоматизированная система составления и разгадывания линейного кроссворда по выбранной теме»

2. Исходные данные к проекту: см. приложение к заданию

3. Перечень вопросов, подлежащих разработке в курсовом проекте:

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

3.2. Выполнить обзор существующих систем-аналогов

3.3. Разработать информационно-логический проект системы

3.4. Разработать и реализовать программное и информационное обеспечение, провести его тестирование и отладку.

3.5. Оформить документацию проекта

3.6. Подготовить презентацию по разработанной системе

Пример.

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

1) Требования к техническому обеспечению:

- ЭВМ типа IBM PC;

- процессор типа x86 или x64 тактовой частоты 1400 МГц и выше;

- …

2) Требования к программному обеспечению:

- операционная система Windows XP SP3 и выше;

- установленная платформа.Net версии 4.0 и выше;

- установленная СУБД ….

А.3 Установка системы

Пример.

Система поставляется в виде zip-архива. Данный файл необходимо распаковать в любую директорию на жестком диске. Запускаемым файлом системы является файл ххх.exe.[13]

А.4 Работа с системой

А.4.1 Работа с системой в режиме администратора (если необходимо)

Вход в систему (авторизация)

…

А.4.2 Работа с системой в режиме пользователя

Вход в систему (авторизация)

Вход в систему (регистрация)

Настройка параметров кроссворда

…

Учебное издание
Методические указания к лабораторному практикуму
по дисциплине «Технологии программирования»
Методические указания
Составитель: Зеленко Лариса Сергеевна
Самарский государственный аэрокосмический
университет им. академика С.П.Королева.
443086 Самара, Московское шоссе, 34.

[1] ГОСТ 34.602-89, с. 3.

[2] Рекомендуется рассказать о 4-5 разновидностях наиболее популярных кроссвордов.

[3] Диаграмма ‑ это графическое представление множества элементов.

[4] см. раздел 2.1 ТЗ «Характеристики объекта автоматизации»

[5] см. раздел 2.2 ТЗ «Требования к информационному обеспечению системы»

[6] Последняя функция не обязательна, т.к. достаточно сложна при реализации.

[7] см. раздел 2.5.1 ТЗ «Функции, реализуемые системой».

[8] Эта часть постановки задачи обязательна.

[9] Большой Российский энциклопедический словарь, с. 1437.

[10] Заинтересованное лицо ‑ некто, имеющий возможность (в том числе, материальную) повлиять на реализацию проекта/продукта

[11] […] – значения, указанные в таких скобках, могут отсутствовать

[12] Количество страниц, рисунков, таблиц указывается без учета приложений

[13] Если необходимы дополнительные ресурсы для обеспечения работоспособности системы, то все для них также должны быть перечислены условия установки. Если установка нестандартная, то она должна быть подробно описана (в объеме, достаточном для понимания пользователя).

Составитель: доц., к. т. н. Зеленко Л.С.

УДК 004.4 (075)

12 3 4 5 6 Следующая ⇒