Краткие теоретические и учебно-методические материалы по теме практической работы — КиберПедия 

Особенности сооружения опор в сложных условиях: Сооружение ВЛ в районах с суровыми климатическими и тяжелыми геологическими условиями...

Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...

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

2019-05-27 414
Краткие теоретические и учебно-методические материалы по теме практической работы 0.00 из 5.00 0 оценок
Заказать работу

ЛАБОРАТОРНАЯ РАБОТА № 8,9

«Разработка и оформление эскизного проекта»

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

Образовательные результаты, заявленные во ФГОС третьего поколения:

Студент должен

уметь:

- использовать методы получения кода с заданной функциональностью и степенью качества;

знать:

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

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

Разработка спецификаций.

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

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

• диаграмм потоков данных (DFD —Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

• диаграмм «сущность—связь» (ERD —Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;

• диаграмм переходов состояний (STD —State Transition Diagrams), характеризующих поведение системы во времени;

• функциональных диаграмм (методика SADT);

• спецификаций процессов;

• словаря терминов.

Спецификации процессов.

Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси —Шнейдермана.

Словарь терминов.

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

Диаграммы переходов состояний.

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

Функциональные диаграммы.

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

Диаграммы потоков данных.

Для описания потоков информации в системе применяются диаграммы потоков данных (DFD —Data flow diagrams). DFD позволяет описать требуемое поведение системы в виде совокупности процессов, взаимодействующих посредством связывающих их потоков данных. DFD показывает, как каждый из процессов преобразует свои входные потоки данных в выходные потоки данных и как процессы взаимодействуют между собой.

Диаграммы «сущность—связь»

Диаграмма сущность—связь —инструмент разработки моделей данных, обеспечивающий стандартный способ определения данных и отношений между ними. Она включает сущности и взаимосвязи, отражающие основные бизнес-правила предметной области. Такая диаграмма не слишком детализирована, в нее включаются основные сущности и связи между ними, которые удовлетворяют требованиям, предъявляемым к ИС.

 

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

1. На основе технического задания из лабораторной работы № 4-5 выполнить анализ функциональных и эксплуатационных требований к программному продукту.

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

3. Определить диаграммы потоков данных для решаемой задачи.

4. Определить диаграммы «сущность—связь», если программный продукт содержит базу данных.

5. Определить функциональные диаграммы.

6. Определить диаграммы переходов состояний.

7. Определить спецификации процессов.

8. Добавить словарь терминов.

9. Оформить результаты, используя MS Office или MS Visio в виде эскизного проекта.

10. Сдать и защитить работу.

 

2.3 Контрольные вопросы

1. Назовите этапы разработки программного обеспечения?

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

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

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

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

Проектирование

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

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

Реализация

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

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

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

Результатом тестирования является устранение всех недостатков системы и заключение о ее качестве.

Внедрение и поддержка

Внедрения системы обычно предусматривает следующие шаги:

· установка системы,

· обучение пользователей,

· эксплуатация.

 

2. Что такое жизненный цикл программного обеспечения?

Жизненный цикл программного обеспечения (ПО) — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации

3. В чем заключается постановка задачи и предпроектные исследования?

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

4. Назовите функциональные и эксплуатационные требования к программному продукту?

· правильность – функционирование в соответствии с техническим заданием;

· универсальность – обеспечение правильной работы при любых допустимых данных и защиты от неправильных данных;

· надежность (помехозащищенность) – обеспечение полной повторяемости результатов, т.е. обеспечение их правильности при наличии различного рода сбоев;

· проверяемость – возможность проверки получаемых результатов;

· точность результатов – обеспечение погрешности результатов не выше заданной;

· защищенность – обеспечение конфиденциальности информации;

· программная совместимость – возможность совместного функционирования с другим программным обеспечением;

· аппаратная совместимость – возможность совместного функционирования с некоторым оборудованием;

· эффективность – использование минимально возможного количества ресурсов технических средств, например, времени микропроцессора или объема оперативной памяти;

 

5. Перечислите составляющие эскизного проекта?

· Ведомость эскизного проекта. Общая информация по проекту.

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

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

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

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

· Схема автоматизации. Логический процесс создания автоматизированной системы от начала до конца.

· Согласно ГОСТ 34.201-89, дополнительно в эскизный проект по необходимости может быть включено техническое задание на разработку новых технических средств.

6. Охарактеризуйте спецификации и модели?

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

Моде́ль— это система, исследование которой служит средством для получения информации о другой системе процесса, устройства или концепции.

 

 


 

УТВЕРЖДАЮ

 

Руководитель (заказчика ИС)

Личная подпись_________ Расшифровка подписи ______

Печать

Дата «____»___________________ 2019 г.

 

УТВЕРЖДАЮ

 

Руководитель (разработчика ИС)

Личная подпись_________ Расшифровка подписи______

Печать

Дата «____»___________________ 2019 г.

 

 

Эскизный проект на создание

информационной системы

 

Создание программы

(наименование вида И С)

 

Аптека

(наименование объекта информатизации)

 

Аптек

(сокращенное наименование И С)

 

На 8 листах

Действует с «__»________ 2014 г.

 

Содержание

Содержание                                                                                                                       47

Ведомость эскизного проекта                                                                                         48

Пояснительная записка к эскизному проекту                                                               49

Общие положения.                                                                                                           49

Основные технические решения                                                                                    49

Решения по структуре системы                                                                                      49

Решения по режимам функционирования, работы системы                                       50

Решения по численности, квалификации и функциям персонала АС.                       50

Состав функций комплексов задач, реализуемых системой                                            50

Решения по составу программных средств, языкам деятельности,

алгоритмам процедур и операций и методам их реализации                                      51

Источники разработки                                                                                                     51

 

Ведомость эскизного проекта

На предыдущих стадиях разработки Программы “Аптека” были составлены и утверждены следующие документы:

• Техническое задание на создание информационной системы Программы “Аптека”, разработанное на основании ГОСТ 34.602—89 на написание ТЗ на автоматизированные системы управления от 01.01.1990 г.

Общие положения

Данный документ является эскизным проектом на создание Программы “Аптека” для аптеки.

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

Источники разработки

Данный документ разрабатывался на основании ГОСТ 34.698—90 на написание ТЗ на автоматизированные системы управления от 01.01.1992 г.

 

Приложения

СОСТАВИЛИ

Должность исполнителя_______________________________________________

Фамилия, имя, отчество_______________________________________________

Подпись________________

Дата «____»_______ 2019 г.

Должность исполнителя_______________________________________________

Фамилия, имя, отчество_______________________________________________

Подпись_______________

Дата «____»______ 2019 г.

Должность исполнителя______________________________________________

Фамилия, имя, отчество______________________________________________

Подпись_______________

Дата «____»______ 2019 г.

 

ЛАБОРАТОРНАЯ РАБОТА № 8,9

«Разработка и оформление эскизного проекта»

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

Образовательные результаты, заявленные во ФГОС третьего поколения:

Студент должен

уметь:

- использовать методы получения кода с заданной функциональностью и степенью качества;

знать:

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

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

Разработка спецификаций.

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

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

• диаграмм потоков данных (DFD —Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

• диаграмм «сущность—связь» (ERD —Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы;

• диаграмм переходов состояний (STD —State Transition Diagrams), характеризующих поведение системы во времени;

• функциональных диаграмм (методика SADT);

• спецификаций процессов;

• словаря терминов.

Спецификации процессов.

Спецификации процессов обычно представляют в виде краткого текстового описания, схем алгоритмов, псевдокодов, Flow-форм или диаграмм Насси —Шнейдермана.

Словарь терминов.

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


Поделиться с друзьями:

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

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

Археология об основании Рима: Новые раскопки проясняют и такой острый дискуссионный вопрос, как дата самого возникновения Рима...

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



© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!

0.079 с.