Состав пояснительной записки проекта по разработке программного обеспечения

Титульный лист

Содержание

Задание на проектирование (бланк задания см. в приложении А)

Список сокращений

Введение

1 Краткая характеристика объекта автоматизации (автоматизируемого процесса)

2 Анализ и планирование требований к программному продукту

3 Проектирование программного обеспечения

4 Построение программного продукта

5 Внедрение программного продукта

Чертежи и плакаты

1 Функциональная модель ПО (А6.01)

2 Информационная модель ПО (А6.02)

3 Основные алгоритмы программы (А6.03)

4 Структура базы данных ПО (А6.04)

5 Основные экранные интерфейсы ПО (А6.05)

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

Приложения

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

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

Одним из возможных подходов к разработке ПО является получившая в последнее время широкое распространение методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий 3 элемента:

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

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

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

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

В разделе «Анализ и планирование требований к программному продукту» описываются функции, определяемые пользователями системы, которые должен выполнять программный продукт, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном по опросу пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей информационной системы, предварительные функциональные и информационные модели ИС.

В разделе «Проектирование программного обеспечения» описываются проектные этапы. На этом этапе часть пользователей может принимать участие в техническом проектировании системы под руководством специалистов-разработчиков. Используются CASE-средства для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации.

После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении информационной системы на подсистемы. С использованием CASE-средств проект разделяется на части (делится функциональная модель). Результатом данной фазы должны быть:

• общая информационная модель системы;

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

• точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;

• построенные прототипы экранов, отчетов, диалогов.

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

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

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

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

• определяется необходимость распределения данных;

• производится анализ использования данных;

• производится физическое проектирование базы данных;

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

• определяются способы увеличения производительности;

• завершается разработка документации проекта.

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

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

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

Следует, однако, отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша в первую очередь для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если же разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

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

Оформление проекта

Пояснительная записка должна быть оформлена на формате А4, текст шрифта Times New Roman 14 пт, межстрочный интервал полуторный, выравнивание по ширине, поля текста: слева – 3 см, справа – 1,5 см, сверху и снизу – 2 см, выравнивание по ширине, красная строка – 1,25 см. Нумерация страниц производится сверху в центре.

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

Нужно различать дефис и тире. В словах используется дефис (-), в качестве знака препинания используется тире (–).

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

Рисунок 1.1 – Название рисунка

Нумерация рисунков в главе сквозная. После подрисуночной надписи вводится пустая строка.

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

Таблица 1.1 – Название таблицы

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

Продолжение таблицы 1.1 (без названия, таблица начинается с номеров столбцов).

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

Список литературы нумеровать по алфавиту. При указании web-страниц сначала вводится адрес, далее ставится тире и указывается ресурс (автор и т.д.).

Если в тексте есть сокращения, то их нужно приводить в списке сокращений. Нумерации производится по алфавиту. Пример:

АСУ – автоматизированная система управления

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

Введение к курсовому проекту оформляется следующим образом.

Введение

Актуальность проекта. В этой же строчке продолжаем писать об актуальности проекта.

Цель проекта.В этой же строчке продолжаем писать цель проекта. Цель всегда состоит из одного предложения.

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

Новизна и практическая ценность проекта.На этой же строчке продолжаем писать о новизне и практической ценности проекта.

Область внедрения.Продолжаем писать на этой же строчке о внедрении проекта.

Защита проекта

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

Процедура защиты предусматривает

1 Подготовку доклада по проекту. Структура доклада включает в себя:

а) обоснование актуальности выбранной темы;

б) постановку цели, вытекающей из актуальности темы проекта;

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

г) результаты, полученные в ходе проектирования;

д) выводы.

2 Ответы на вопросы по проекту по окончании доклада.