Раздел разработки программного обеспечения

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

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

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

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

- анализ требований к ПО;

- анализ информационных технологий разработки;

- проектирование ПО;

- реализация;

- тестирование.

Заключение

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

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

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

 

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

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

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

Ссылки в тексте пояснительной записки на все источники обязательны!

 

Приложения

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

 

Графическая часть

Графическая часть отражает основные решения дипломного проекта, начиная от анализа предметной области и заканчивая компонентами разработанного ПО. Графическая часть может включать чертежи, выполненные в соответствии с ГОСТ 19.701-90, диаграммы IDEF0, IDEF1, IDEF1X, диаграммы UML и других технологий, а также рисунки, выполненные в «свободной манере».

Графические решения приводятся в формате А4 или А3 в тексте основной части пояснительной записки или в ее приложениях.

Количество чертежей, диаграмм и плакатов в дипломном проекте (порядка 15 – 20) определяется его тематикой и степенью детализации изложения материала в пояснительной записке.

Рекомендуемые графические решения (по этапам разработки ПО):

- анализ предметной области разработки: UML диаграммы классов предметной области, диаграммы IDEF1, IDEF1X а также плакаты;

- анализ требований к ПО: UML диаграммы вариантов использования и взаимодействия, диаграммы функционального моделирования IDEF0;

- анализ информационных технологий разработки: диаграммы IDEF0, IDEF1, IDEF1X, диаграммы UML и других технологий, а также ГОСТ 19.701-90 и плакаты;

- проектирование ПО: классов анализа и проектных классов, диаграммы взаимодействия, состояний, деятельности, развертывания; схемы ГОСТ 19.701-90, а также плакаты;

- реализация: UML диаграммы развертывания, пакетов, компонентов, деятельности; схемы ГОСТ 19.701-90, а также плакаты;

- тестирование: ГОСТ 2.105-95 (таблицы), UML диаграммы деятельности, компонентов; схемы ГОСТ 19.701-90, а также плакаты.

 

4 Рекомендации к структуре и оформлению раздела разработки программного обеспечения

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

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

- что система должна делать в первую очередь для ее основных пользователей?

- как должна выглядеть архитектура системы?

- каков план и во что обойдется разработка продукта?

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

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

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

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

В основе каждого этапа современной разработки программной системы лежит построение и использование моделей.

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

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

Рисунок 4.1 – Модели процесса разработки ПО

 

Анализ предметной области

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

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