И содержание курсового проекта

Рег. № М-1905

РАЗРАБОТКА И СТАНДАРТИЗАЦИЯ
ПРОГРАММНЫХ СРЕДСТВ И
ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Методические указания

к курсовому проекту «Проектирование программного средства сложной структуры»

Специальность 080801 – Прикладная информатика в экономике

Направление 080800 – Прикладная информатика

Санкт-Петербург

Допущено

редакционно-издательским советом СПбГИЭУ

в качестве методического издания

Составитель

канд. техн. наук, проф. В.И. Фомин

канд. экон. наук, проф. А.И. Дашевский

Рецензент

д-р техн. наук, проф. И.А. Брусакова

Подготовлено на кафедре

информационных систем в экономике

Отпечатано в авторской редакции с оригинал-макета,

представленного составителем

Ó СПбГИЭУ, 2012

СОДЕРЖАНИЕ

1. Цель курсового проектирования..................................................... 4

2. Порядок выполнения и содержание курсового проекта.............. 4

3. Оформление курсового проекта..................................................... 10

4. Защита курсового проекта............................................................... 12

5. Выбор задания курсового проекта.................................................. 12

Список литературы............................................................................... 20

Приложение........................................................................................ 22

Цель курсового проектирования

Целью курсового проекта является реализация процессов жизненного цикла программного изделия (ПИ), для которого предполагается возможность его тиражирования и применения в виде пакета прикладных программ (ППП) для решения определенного набора экономических задач конечного пользователя. В соответствии с ГОСТ Р ИСО/МЭК 12207 “Процессы жизненного цикла программных средств” в проекте реализуются процессы разработки, документирования, обеспечения качества, приемки работ, приемки изделия, управления проектом.

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

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

Порядок выполнения

и содержание курсового проекта

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

- назначение и область применения ПИ, где указывается, на каком классе объектов оно может применяться, какие задачи и каким пользователем могут решаться с его применением;

- основание для разработки;

- требования заказчика к ПИ:

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

б) вид пользовательского управляющего и справочного интерфейса;

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

г) требования к операционному и программному окружению, к техническим средствам, к средствам разработки, сопровождения и адаптации ПИ к условиям конкретного объекта;

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

Данный перечень может расширяться в зависимости от специфики конкретной разработки.

- требования по передаче ПИ заказчику, его оценке и установке на месте эксплуатации (условия не должны выходить за возможности учебных аудиторий СПбГИЭУ);

- календарный план разработки с указанием сроков завершения этапов и работы в целом.

В качестве заказчика в курсовом проектировании может выступать преподаватель - руководитель проекта. Возможно использование ТЗ на ПИ, в создании которого студент участвует, работая за пределами университета. В этом случае следует согласовать задание с руководителем курсового проекта.

2.2. Определяется предварительная цена ПИ или сумма договора на разработку в зависимости от вида создаваемого ПИ. Приводится ее обоснование.

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

В первую очередь следует обратить внимание на выбор с кратким обоснованием:

- средства программирования (языка программирования);

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

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

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

Результаты организационной подготовки представляются в виде набора детального календарного плана работ с указанием в нем всех упомянутых характеристик и индивидуальных планов-заданий по исполнителям. При формировании индивидуальных планов исполнителей обязательным является их распределение по работам по функциональному принципу. Т.е., каждый исполнитель должен провести комплексную реализацию, по крайней мере, одной функции из числа представленных в пункте “Функциональные требования” ТЗ, выполнив для нее работы, указанные в п.п. 2.4, 2.5, 2.6, 2.7 настоящих методических указаний.

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

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

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

- разрабатывается пользовательский интерфейс, который позволяет пользователю осуществить управление работой ПИ при его эксплуатации;

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

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

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

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

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

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

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

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

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

- модули реализации функций пользователя. Конечный пользователь должен получить в результате реализации задачи экранный документ и его печатный аналог зонально-табличной формы со всеми комментирующими надписями, заголовком и основанием согласно наименованиям документов пользователя и реквизитов из его предметной области. Результаты работ по п.2.6 приводятся в виде набора документов “Текст программы” для отдельных программных модулей в расчете на доступность понимания логики, синтаксиса, семантики и прагматики программы технологически подготовленным пользователем документа, даже если он не был связан с программной реализацией. Для рационального сокращения объема проекта возможно приведение документа “Текст программы” только для одного из модулей по согласованию с руководителем проекта.

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

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

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

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

При подготовке документации пользователя следует учитывать материалы ГОСТ Р ИСО 9127 “Документация пользователя и информация на упаковке для потребительских пакетов программ” и ГОСТ Р ИСО/МЭК 15910 “Процесс создания документации пользователя программного средства”.

2.8. Представляются материалы по управлению процессом разработки, связанным с обеспечением фактического выполнения календарного плана, полученного в результате выполнения п.2.2. Указываются фактические затраты ресурсов и причины их отклонения от предполагаемых. Формулируются предложения по корректировке цены поставки ПИ в зависимости от результатов разработки.