Методические указания. МУ К ПЗ ТРПО ПКС. Методические указания по выполнению практических работ учебной дисциплины мдк 03. 01 Технология разработки программного обеспечения
 Скачать 5.82 Mb.
|
3. МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ДЛЯ СТУДЕНТОВ ПО КОНКРЕТНЫМ ВИДАМ ПРАКТИЧЕСКИХ РАБОТПри выполнении каждой практической работы необходимо придерживаться следующих правил: Внимательно прочитайте инструкцию по выполнению практической работы, которая содержит: - наименование работы; - ключевые слова (термины, которые необходимо знать до выполнения практической работы); - цель работы; - теоретические сведения (краткое изложение основных теоретических положений); - указания к работе (описание порядка выполнения работы); - контрольные вопросы (позволяют определить уровень освоения теоретической и практической частей работы). 2. Пользуясь указаниями к работе, выполните предложенные задания. 3. Оформите письменный отчет по выполненной практической работе. Требования к содержанию и оформлению отчета по практической работе (форма отчета, оформляемого студентом) Практическая работа №…. «___________________» (наименование практической работы) Цель работы: ……………………….. Оборудование, раздаточный материал: ………………………………………… Ход работы: Задание 1. (переписанное задание) …………………….. (ответ) ……. ………………………………….. Вывод (соответствующий полученным результатам (например, можно начать следующим образом: полученных данных можно сделать следующие выводы: (и перечисляем, к каким выводам в результате проделанной работе вы пришли) при наличии Критерии оценки результатов выполнения практической работы Критериями оценки результатов выполнения практической работы являются: - степень реализации цели работы; - качество оформления отчета; - степень соответствия результатов работы заданным требованиям. Оценка выполнения практической работы Отметка 5 – «отлично» выставляется, если студент имеет глубокие знания учебного материала по теме практической работы, показывает усвоение взаимосвязи основных понятий, используемых в работе, самостоятельно выполнил все указания по выполнению практической работе, смог ответить на контрольные вопросы, даёт правильный алгоритм решения задачи. Отметка 4 – «хорошо» выставляется, если студент показал знание учебного материала, допускает небольшие неточности при выполнении экспериментальных заданий и расчетов, смог ответить почти полно на все контрольные вопросы. Отметка 3 – «удовлетворительно» выставляется, если студент в целом освоил материал практической работы, но затрудняется с выполнением всех заданий практической работы без помощи преподавателя, ответил не на все контрольные вопросы. Отметка 2 – «неудовлетворительно» выставляется студенту, если он имеет существенные пробелы в знаниях основного учебного материала практической работы, не может самостоятельно выполнить задания практической работы, не раскрыл содержание контрольных вопросов. 4. МЕТОДИЧЕСКИЕ УКАЗАНИЯ ДЛЯ СТУДЕНТОВ ПРИ ПРОВЕДЕНИИ ПРАКТИЧЕСКИХ ЗАНЯТИЙРаздел 1. Технология разработки программного обеспечения Тема 1.1. Процессы создания программного обеспечения Практическое занятие 1. Тема: Разработка технического задания Цель работы: Ознакомление с процедурой разработки технического задания на создание программного продукта с применением ГОСТ 19.201-78. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения 1. Техническое задание оформляют в соответствии с ГОСТ 19.201-78 на листах формата А4 и A3 по ГОСТ 2.301-68, как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом. 2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78. Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать. 3. Для внесения изменений и дополнений в техническое задание на последующих стадиях разработки программы или программного изделия выпускают дополнение к нему. Согласование и утверждение дополнения к техническому заданию проводят в том же порядке, который установлен для технического задания. 4. Техническое задание должно содержать следующие разделы: •название программы и область применения; •основание для разработки; •назначение разработки; •технические требования к программе или программному изделию; •технико-экономические показатели; •стадии и этапы разработки: •порядок контроля и приемки; •приложения. В зависимости от особенностей программы или программного изделия допускается уточнять содержание разделов, вводить новые разделы или объединять отдельные из них. 5. Содержание разделов 5.1. В разделе «Наименование и область применения» указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие. 5.2. В разделе «Основание для разработки» должны быть указаны: •документ (документы), на основании которых ведется разработка; •организация, утвердившая этот документ, и дата его утверждения; •наименование и (или) условное обозначение темы разработки. 5.3. В разделе «Назначение разработки» должно быть указано функциональное и эксплуатационное назначение программы или программною изделия. 5.4. Раздел «Технические требования к программе или программному изделию» должен содержать следующие подразделы: •требования к функциональным характеристикам; •требовании к надежности; •условия эксплуатации; •требования к составу и параметрам технических средств; •требования к информационной и программной совместимости; •требования к маркировке и упаковке; •требования к транспортированию и хранению; •специальные требования. 5.5. В подразделе «Требования к функциональным характеристикам» должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.п. 5.6. В подразделе «Требования к надежности» должны быть указаны требования к обеспечению надежного функционирования (обеспечение устойчивого функционирования, контроль входной и выходной информации, время восстановления после отказа и т. п.). 5.7. В подразделе «Условия эксплуатации» должны быть указаны условия эксплуатации (температура окружающего воздуха, относительная влажность и т. п. для выбранных типов носителей данных), при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала. 5.8. В подразделе «Требования к составу и параметрам технических средств» указывают необходимый состав технических средств с указанием их технических характеристик. 5.9. В подразделе «Требования к информационной и программной совместимости» должны быть указаны требования к информационным структурам на входе и выходе и методам решения, исходным кодам, языкам программирования. При необходимости должна обеспечиваться защита информации и программ. 5.10. В подразделе «Требования к маркировке и упаковке» в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки. 5.11. В подразделе «Требования к транспортированию и хранению» должны быть указаны для программного изделия условия транспортирования, места хранения, условия хранения, условия складирования, сроки хранения в различных условиях. 5.12. В разделе «Технико-экономические показатели» должны быть указаны: ориентировочная экономическая эффективность предполагаемая годовая потребность, экономические преимущества разработки по сравнению с лучшими отечественными и зарубежными образцами или аналогами. 5.13. В разделе «Стадии и этапы разработки» устанавливают необходимые стадии разработки, этапы и содержание работ (перечень программных документов, которые должны быть разработаны, согласованы и утверждены), а также, как правило, сроки разработки и определяют исполнителей. 5.14. В разделе «Порядок контроля и приемки» должны быть указаны виды испытаний и общие требования к приемке работы. 5.15. В приложениях к техническому заданию при необходимости приводят: •перечень научно- исследовательских и других работ, обосновывающих разработку; •схемы алгоритмов, таблицы, описания, обоснования, расчеты и другие документы, которые могут быть использованы при разработке; •другие источники разработки. Порядок выполнения работы Ниже приведено 15 вариантов программных продуктов. В соответствии с индивидуальным вариантом разработайте техническое задание на создание программного продукта по всем требованиям. 1. Разработка программного комплекса «Автотранспорт». 2. Разработка программного комплекса «Обслуживание банкомата». 3. Разработка программного комплекса «Управление гостиницей». 4. Разработка программного комплекса «Выдача кредитов в банке». 5. Разработка программного комплекса «Строительная фирма». 6. Разработка программного комплекса «Управление библиотечным фондом». 7. Разработка программного комплекса «АРМ работника склада» 8. Разработка программного комплекса «АРМ администратора ателье по ремонту оргтехники» 9. Разработка программного комплекса «АРМ администратора спорткомплекса». 10. Разработка программного комплекса «АРМ администратора автосалона». 11. Разработка программного комплекса «АРМ администратора ресторана». 12. Разработка программного комплекса «АРМ сотрудника ЖЭСа». 13. Разработка программного комплекса «АРМ администратора аэропорта». 14. Разработка программного комплекса «АРМ работника отдела кадров». Форма отчета: Составить техническое задание в соответствии с ГОСТ 19.201-78. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. ГОСТ 19.201-78 Единая система программной документации. Техническое задание. Требования к содержанию и оформлению." Раздел 1. Технология разработки программного обеспечения Тема 1.1. Процессы создания программного обеспечения Практическое занятие 2. Тема: Построение диаграмм переходов состояний и функциональных диаграмм. Цель работы: получение навыков создания и редактирования функциональных моделей в нотации IDEF0. Изучение основных характеристик и основ работы с STD-диаграммами в графическом редакторе. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия (Л1: р.2, гл.1, п.1.1-1.3 с. 74-87); изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Функциональная диаграмма IDEF0. 1. Основные сведения по методологии IDEF0 Модель в нотации IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм. Каждая диаграмма является единицей описания системы и располагается на отдельном листе. Цель моделирования. Модель не может быть построена без четко сформулированной цели. Пример цели: «Описать функциональность предприятия с целью написания спецификаций ИС». Точка зрения. Точку зрения можно представить как взгляд человека, который видит систему в нужном для моделирования аспекте. Как правило, выбирается точка зрения человека, ответственного за моделируемую работу в целом. Цель и точка зрения документируются. Основные элементы IDEF0-модели В основе методологии IDEF0 лежат 4 основных понятия: ‒ функциональный блок; ‒ интерфейсная дуга (стрелка); ‒ декомпозиция; ‒ глоссарий. 1. Функциональный блок Функциональные блоки обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Графически функциональные блоки изображаются в виде прямоугольников. Все блоки должны быть названы и определены. Имя функционального блока должно быть выражено сочетанием отглагольного существительного, обозначающего процесс, или глаголом:  Определение функционального блока заносится в глоссарий или словарь работ (Activity Dictionary). Все функциональные блоки модели нумеруются. Номер состоит из префикса и числа. Может использоваться префикс любой длины, но обычно используется префикс А. Контекстная (корневая) работа (функциональный блок) имеет номер А0. 2. Интерфейсная дуга (стрелка – Arrow) Взаимодействие функциональных блоков с внешним миром и между собой описывается в виде интерфейсных дуг (стрелок). Стрелки представляют собой некую информацию и обозначаются существительными (например, «Заготовка», «Изделие») или именуемыми сочетаниями (например, «Готовое изделие»). Все стрелки должны быть определены. В IDEF0 различают типы стрелок. Каждая стрелка имеет свое расположение относительно функционального блока.  Вход (Input) – материал или информация, которые используются или преобразуются работой для получения результата (выхода). Стрелка Input рисуется входящей в левую грань работы. Управление (Control) – правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Рисуется как входящая в верхнюю грань работы. Выход (Output) – материал или информация, которые производятся работой. Каждая работа должна иметь хотя бы одну стрелку выхода. Работа без результата не имеет смысла и не должна моделироваться. Изображается исходящей из правой грани работы. Механизм (Mechanism) – ресурсы, которые выполняют работу, например, персонал предприятия, станки, устройства и т.д. Рисуется как входящая в нижнюю грань работы. 3. Декомпозиция Разбиение системы на крупные фрагменты – функции, функции – на подфункции и т.д. до конкретных процедур. Модель может содержать 4 типа диаграмм: ‒ контекстную (в каждой модели может быть только 1 контекстная диаграмма); ‒ декомпозиции; ‒ дерева узлов; ‒ только для экспозиции (FEO). Контекстная диаграмма является вершиной древовидной структуры диаграмм и представляет собой общее описание системы и ее взаимодействия с внешней средой. После описания системы в целом проводится разбиение ее на крупные фрагменты. Этот процесс называется функциональной декомпозицией, а диаграммы, которые описывают каждый фрагмент и взаимодействие фрагментов – диаграммами декомпозиции. После декомпозиции контекстной диаграммы проводится декомпозиция каждого большого фрагмента системы на более мелкие и т.д., до достижения нужного уровня подробности описания. Диаграмма дерева узлов показывает иерархическую зависимость работ, но не взаимосвязи между работами. Диаграммы для экспозиции (FEO) строятся для иллюстрации отдельных фрагментов модели, для иллюстрации альтернативной точки зрения либо для специальных целей. Все диаграммы имеют нумерацию. Контекстная диаграмма имеет номер А-0, декомпозиция контекстной диаграммы – номер А), остальные диаграммы-декомпозиции – номера по соответствующему узлу (например, А1, А2, А21 и т.д.). Диаграмма переходов состояний STD. Используются для моделирования поведения. STD состоит из следующих объектов: Состояние – моделируемая система в любой заданный момент времени должна находится точно в одном из конечного множества состояний Начальное состояние является стартовой точкой для начального системного перехода, соответствующего состоянию системы после её инсталляции. STD должна иметь только одно начальное состояние, а также любое (конечное) число завершающих состояний. Переход определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода идентифицирует событие, являющееся причиной перехода и управляющее им. Это событие обычно состоит из управляющего потока (сигнала), возникающего как во внешнем мире, так: и внутри системы при выполнении некоторого условия. Действие – это операция, которая может быть связана с переходом, и выполняющаяся при выполнении перехода  На STD состояния представляются узлами, а переходы - дугами Условия идентифицируются именем перехода и возбуждают выполнение перехода. Действия или отклики на события привязываются к переходам и записываются под соответствующим условием. Начальное состояние на диаграмме должно иметь входной переход, изображаемый потоком из стартового узла. Применяются два способа построения STD. Первый способ заключается в идентификации всех возможных состояний и дальнейшем исследовании всех не бессмысленных связей (переходов) между ними. По второму способу сначала строится начальное состояние, затем следующие за ним и т.д. В ситуации, когда число состояний и/или переходов велико, для проектирования спецификаций управления могут использоваться матрицы переходов состояний. В матрице переходов по вертикали указываются состояния, из которых осуществляется переход, а по горизонтали - состояния, в которые осуществляется переход. При этом каждый элемент матрицы содержит соответствующие условия и действия, обеспечивающие переход из "вертикального" состояния в "горизонтальное". Порядок выполнения работы В соответствии с индивидуальным вариантом, построить диаграммы IDEF0 и STD. Перечень индивидуальных вариантов приведен в приложении Б. Отчет по практическому занятию выполняется в формате MS Word, который содержит экранные формы моделей согласно заданию. Требования к построению модели 1. На контекстной диаграмме необходимо указать точку зрения и цель моделирования. 2. Количество блоков любой декомпозиции не менее 3-х и не более 9. 3. Количество декомпозиций – 3 уровня декомпозиции. Форма отчета: Функциональная диаграмма IDEF0 и диаграмма переходов состояний STD с описанием процесса построения диаграмм. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО / Е. А. Черткова. —2-е изд., испр. и доп. — М.: Издательство Юрайт, 2017. — 168 с. — (Серия: Профессиональное образование). - URL://www.urait.ru Раздел 1. Технология разработки программного обеспечения |