Файл: Курсовой проект по мдк 03. 01. Технология разработки программного обеспечения.doc

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 29.11.2023

Просмотров: 266

Скачиваний: 6

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

СОДЕРЖАНИЕ

Введение

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

1.1. Характеристика магазина мебели

1.2 Описание деятельности персонала мебельный складного магазина

1.3 Необходимость автоматизации деятельности магазина мебели

2. Техническое задание на разработку информационной системы.

Введение

2.1. Основание для разработки.

2.2. Назначение разработки

2.3. Требования к программе

3. Выбор модели жизненного цикла программного обеспечения

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

4.1 Основы проектирования информационных систем (ИС)

4.2 Определение перечней сущностей и их атрибутов

4.3 Инфологическая модель

4.4 Выбор ключевых полей

4.5 Нормализация отношений

5. Реализация ПО Мебельный склад с помощью программного инструментария

5.1 Характеристика инструментария для реализации проекта

5. 2 Реализация таблиц

5.3 Реализация запросов

5.5 Реализация отчетов

5.4 Реализация форм

5.6 Разработка программной оболочки

5.7 Составление руководства пользователя

6. Тестирование и отладка программного продукта

7. Экономическая оценка программного продукта

Заключение

Список использованной литературы источников

ПРИЛОЖЕНИЕ



Жизненный цикл традиционно разделяют на следующие основные этапы:

  1. Анализ требований,

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

  3. Кодирование (программирование),

  4. Тестирование и отладка,

  5. Эксплуатация и сопровождение.



Рис.1 - Каскадная модели ЖЦ ПО

Достоинства модели:

  • стабильность требований в течение всего жизненного цикла разработки;

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

  • определенность и понятность шагов модели и простота её применения;

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

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

Недостатки модели:

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

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

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

  • непригодность промежуточного продукта для использования;

  • невозможность гибкого моделирования уникальных систем;

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

  • недостаточное участие пользователя в создании системы — в самом начале (при разработке требований) и в конце (во время приёмочных испытаний);

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

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

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


Реализовать Каскадную модель жизненного цикла затруднительно ввиду сложности разработки ПС без возвратов к предыдущим шагам и изменения их результатов для устранения возникающих проблем.


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

4.1 Основы проектирования информационных систем (ИС)


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

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

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

Проектирование ИС охватывает три основные области:

  • проектирование объектов данных, которые будут реализованы в базе данных;

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

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

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

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

  • требуемой пропускной способности системы;

  • требуемого времени реакции системы на запрос;

  • безотказной работы системы;

  • необходимого уровня безопасности;




4.2 Определение перечней сущностей и их атрибутов


Сущность - объект любой природы данные, о котором хранятся в отношении (таблице, в которой содержатся данные).

Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.

В рассматриваемой предметной области можно выделить следующие сущности и их атрибуты:


Рис. 2 – Схема данных

4.3 Инфологическая модель


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

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



Рис. 3 – ER – диаграмма

4.4 Выбор ключевых полей


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

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

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

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

4.5 Нормализация отношений


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

Первая нормальная форма

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

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

Вторая нормальная форма

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

Третья нормальная форма

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

Четвёртая нормальная форма

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

Пятая нормальная форма

Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.

Шестая нормальная форма

Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.

Автоматизированная информационная система «Мебельный склад» прошла все стадии нормализации.