Методическое пособие по выполнению практических заданий _Осущест. Методическое пособие по выполнению практических заданий
 Скачать 2.03 Mb.
|
|
Бюджетное Профессиональное Образовательное Учреждение Вологодской области «Череповецкий Лесомеханический техникум им. В.П. Чкалова» МЕТОДИЧЕСКОЕ ПОСОБИЕ ПО ВЫПОЛНЕНИЮ ПРАКТИЧЕСКИХ ЗАДАНИЙ УП.02 ПО ПРОФЕССИОНАЛЬНОМУ МОДУЛЮ ПМ. 02 ОСУЩЕСТВЛЕНИЕ ИНТЕГРАЦИИ ПРОГРАММНЫХ МОДУЛЕЙ для специальности: 09.02.07 «Информационные системы и программирование» Череповец 2021 Методическое пособие составлено преподавателем Резепиным А.С. в соответствии с рабочей программой профессионального модуля ПМ.02 «Осуществление интеграции профессиональных модулей». Методическое пособие рассмотрено на заседании ПЦК специальности 09.02.07 Информационные системы и программирование Протокол № от Председатель ПЦК Пахолкова В.И. Принято методическим советом Протокол №_____ от «___»_________2021г. Содержание
Введение В соответствии с Государственным образовательным стандартом подготовки специалистов профессиональный модуль ПМ.02 «Осуществление интеграции профессиональных модулей» является обязательным для студентов ссузов по направлению подготовки «Информационные системы и программирование». Поскольку курс имеет достаточно серьезную практическую составляющую, востребованность в методическом обеспечении для студентов очной формы обучения достаточно высока. Цель создания данного пособия – оказание методической помощи студентам при выполнении практических работ по учебной практике УП.02 по ПМ.02 «Осуществление интеграции профессиональных модулей». В пособии представлены примеры практических заданий по всем основным темам курса. Перед каждым заданием дан краткий перечень основных понятий по конкретной теме, которые студент должен изучить, приступая к решению задания. В конце каждой темы даны методические рекомендации по выполнению практических заданий. Перед выполнением каждого практического задания студенту необходимо выполнить входной контроль по предложенным в пособии вопросам, выполнить предложенные практические задания и подготовить ответы к вопросам для защиты практической работы. Практическую работу необходимо оформить согласно указанным требованиям по оформлению практических работ. Выполненная и правильно оформленная практическая работа представляется к защите. По результатам защиты выставляется оценка. Защищенная практическая работа сдается преподавателю. В конце учебной практики все защищенные работы подшиваются и сдаются преподавателю для зачета выполнения программы курса по практическим работам. Правила оформления практических работ 1. Работы выполняются на тетрадных листах формата А-4. 2. Отвести рамку на расстоянии 5 мм – сверху, справа и снизу, а слева отступить от края листа на 20 мм (лицевая сторона). 3. Текст от рамки должен отступать сверху и снизу на 10-15 мм, а слева и справа – на 5 мм. Соблюдая красную строку, отступить от рамки на 15 мм. 4. Заголовок «Практическая работа» пишется седьмым шрифтом (печатные буквы), знак № не ставится, а работа нумеруется по порядку. 5. Слово «Тема» не пишется, а сразу пишется тема работы, с заглавной буквы – 7 мм, остальные буквы 5 мм, печатным шрифтом. 6. Переносы слов в заголовках не допустимы. 7. Между словами оставлять интервал в ширину одной буквы, а между буквами – 1/3 ширины буквы. 8. Между заголовками оставлять интервал 8 мм. 9. Точек в конце предложения в заголовках не ставят. 10. Титульный лист является первым листом, но не нумеруется. 11. Вторым листом является содержание практических работ с указанием номеров листов. 12. В конце прикладывается список используемой литературы. Практическая работа 1. Инструментальные средства разработки программного обеспечения Цель работы: изучить современные инструментальные средства разработки программного обеспечения. Оборудование: ПК, браузер. Ход работы: 1. Основные понятия темы, схему циклической модели проектирования ПО: Инструментальные средства разработки ПО — программное обеспечение ,предназначенное для использования в ходе проектирования, разработки и сопровождения программ, в отличие от прикладного обеспечения. Ассемблеры — компьютерные программы, осуществляющие преобразование программы в форме исходного текста на языке ассемблера в машинные коды. Трансляторы — программы или технические средства ,выполняющие трансляцию программы. Ц  иклическая модель проектирования ПО (схема 1)Схема 1. Циклическая модель проектирования ПО 2. Схема процесса описания реализации программного кода с подробным описанием каждого этапа; С  хема 2. Процесс описания реализации программного кода.3. Состав современных систем программирования; интегрированная среда разработчика программ (комплекс программных средств используемых программистами); транслятор языка программирования (перевод языка в машинный код); компоновщик или редактор связей (сборка файлов в единый исполняемый файл); библиотеки стандартных программ и функций; вспомогательные программные средства — программы отладки (исправление ошибок); справочная система. 4. Функции современных компиляторов; Лексический анализ; Синтаксический анализ; Генерация объектного кода. 5. Современные средства программирования с кратким описанием каждого (Python, C++. VSS, MS Visual Studio, Oracle, MS SQL, MySQL): Python – универсальный современный язык программирования высокого уровня, к преимуществам которого относят высокую производительность программных решений и структурированный код. C++ - компилируемый, статически типизированный язык программирования общего назначения. Поддерживает такие парадигмы программирования, как процедурное программирование, объекто-ориентированное программирование и др. VSS – (Microsoft Visual SourceSafe) система управления версиями программного кода. MS Visual Studio - интегрированная среда разработки программного обеспечения и ряд других инструментальных средств. Содержит редактор исходного кода с поддержкой технологии IntelliSense. Oracle — объектно-реляционная система поддерживающая некоторые технологии, реализующие объектно-ориентированный подход. MS SQL – система управления реляционными базами данных,разработанная Microsoft. Основной используемый язык запросов — Transact-SQL. MySQL – свободная реляционная система управления базами данных. 6. Этапы проектирования приложений; Сбор требований к приложению; Предварительная оценка стоимости разработки; Проектирование прототипа; Составление технического задания; Разработка первого релиза продукта; Тестирование; Публикация; Техническая поддержка. 7. Нотации и средства для этапа проектирования; В состав проектирования ПО входят следующие действия: Выбор метода и стратегии ; Выбор представления внутренних данных; Разработка алгоритма; Документирование ПО; Тестирование; Выбор представления входных данных. Список средств для Проектирования ПО: построение блок-схем (Pencil Project); UML-диаграммы(LibreOffice Draw); Разработка макетов(Lumzy); Разработка математических моделей. Практическая работа 2. Основные понятия и стандартизация требований к программному обеспечению Цель: Научится проводить анализ предметной области разрабатываемого ПО. Оборудование: ПК Программное обеспечение: Теоретические сведения к практической работе Теоретические сведения к практической работе Требования к ПОопределяют, какие свойства и характеристики оно должно иметь для удовлетворения потребностей пользователей и других заинтересованных лиц. Однако, в большинстве случаев пользователи могут перечислить только часть свойств, которые они хотели бы видеть и в не всегда понятной формулировке. Анализом предметной области (или бизнес-моделированием, если речь идет о потребностях коммерческой организации) называют деятельность, направленную на: выявление реальных потребностей людей и организаций (которые часто отличаются от непосредственно выражаемых пользователями желаний), выяснения смысла высказанных требований пользователей выявление свойств желаемых результатов определение набора задач, для их достижения определение набора сущностей, необходимых при решении этих задач определение области ответственности будущей программной системы. После этого можно уже более точно сформулировать требования к ПО. Задание Опишите процесс работы кафедры вуза с точки зрения преподавателя. Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата. Таблица 1. Программный модуль «Кафедра»
Практическая работа 3. Разработка и оформление технического задания Цель: Научится составлять и анализировать требования к программе и разрабатывать техническое задание на разработку программного средства. Оборудование: ПК Теоретические сведения к практической работе; Техническое задание представляет собой документ, в котором сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс приемо-сдаточных испытаний. В разработке технического задания участвуют как представители заказчика, так и представители исполнителя. В основе этого документа лежат исходные требования заказчика, анализ передовых достижений техники, результаты выполнения научно-исследовательских работ, предпроектных исследований, научного прогнозирования и т. п. Порядок разработки технического задания; Разработка технического задания выполняется в следующей последовательности. Прежде всего, устанавливают набор выполняемых функций, а также перечень и характеристики исходных данных. Затем определяют перечень результатов, их характеристики и способы представления. Далее уточняют среду функционирования программного обеспечения: конкретную комплектацию и параметры технических средств, версию используемой операционной системы и, возможно, версии и параметры другого установленного программного обеспечения, с которым предстоит взаимодействовать будущему программному продукту. В случаях, когда разрабатываемое программное обеспечение собирает и хранит некоторую информацию или включается в управление каким-либо техническим процессом, необходимо также четко регламентировать действия программы в случае сбоев оборудования и энергоснабжения. Оценка качества процессов создания программного обеспечения. Переход от штучной разработки Программных продуктов к промышленному программированию обусловил повышение требований к качеству создаваемого ПО. В настоящее время существуют несколько стандартов: Международные стандарты серии ISO 9000 (ISO 9000 – ISO 9004) CMM – Capability Maturity Model – модель зрелости процессов создания ПО. Процесс сертификации программ на базе информации об их использовании. Серия стандартов ISO 9000 Одной из важнейшей проблем обеспечения качества ПС является формализация характеристик качества и методология их оценки. Основой регламентирования показателей качества ПС раннее являлся Международный стандарт ISO 9126: 1991 «Информационные технология. Оценка программного продукта. Характеристики качества и руководства по их применению». В России в области обеспечения жизненного цикла и качества сложных комплексов программ в основном применяется устаревших ГОСТов, которые отстают от Мирового уровня на 5-10 лет. Первая часть стандарта — ISO 9126-1 — распределяет атрибуты качества ПС по 6 характеристикам используемых в остальных частях стандарта. К ним применимы разные категории метрик: Категорийным, или описательным, метрикам наиболее адекватны функциональные возможности ПС. Количественные метрики применимы для измерения надежности и эффективности сложных комплексов программ. Качественные метрики в наибольшей степени соответствуют практически, сопровождаемости и мобильности ПС. Выбор показателей качества Исходными данными и высшим приоритетом при выборе показателей качества в большинстве случаев являются назначения, функции и функциональная пригодность, соответствующего ПС. Процессы выбора и установления метрик и шкал для описания характеристик качества ПС можно разделить на 2 этапа: Выбор и обоснование набора исходных данных отражающих общие возможности и этапы жизненного цикла ПС и его потребителей. Выбор, установление и утверждение конкретных метрик и шкал измерения характеристик и атрибутов качества проектов для последующих оценок. Оценка качества Методология и стандартизация оценки характеристик качества готовых ПС и их компонентов на различных этапах жизненного цикла посвящен Международный стандарт ISO 14598. Рекомендуется следующая общая съема процессов оценки: Установка исходных требований для оценки — определение целей испытаний. Селекция метрик качества, установление рейтингов и уровней приоритета метрик субхарактеристик и атрибутов. Планирование и проектирование процессов оценки характеристик и атрибутов качества в жизненном цикле ПС Выполнение измерений для оценки, сравнение результатов с критериями и требованиями. Функциональная пригодность — наиболее неопределенная и объективно трудно оцениваемая субхарактеристика ПС. Оценка корректности ПС — состоит в формальном определении степени соответствия комплекса реализованных программ исходным требованиям контракта. Оценка способности к взаимодействию — состоит в определении качества совместной работы компонентов ПС и баз данных. Оценка защищенности ПС — включает определение полноты использования доступных методов и средств защиты ПС от потенциальных угроз. Оценка надежности — измерение количественных метрик атрибутов субхарактеристик в использовании: завершенности, устойчивости к дефектам, восстанавливаемости, доступности. Потребность в ресурсах памяти и производительности компьютеров в процессе решения задач значительно изменяется в зависимости от состава и объема данных. Оценка практичности программных средств проводится экспертами и включает определение понятности, простоты использования, изучаемости и привлекательности ПС. Сопровождаемость можно оценивать полнотой и достоверностью документации о состояниях ПС и его компонентов. Оценка мобильности — качественное определение экспертами адаптируемости простоты установки, совместимости и замещаемости программ, выражаемое в баллах. Система управления качеством Определения характеристик и субхаракеристик качества: Функциональные возможности — способность ПС обеспечивать решение задач. Функциональная пригодность — набор и описание субхарактеристики и ее атрибутов, определяющие назначение. Правильность (корректность) — способность ПС обеспечивать правильные или приемлемые для пользователя результаты. Способность к взаимодействию — свойство ПС и их компонентов взаимодействовать с одной или большим числом компонентов внутренней и внешней среды Защищенность — способность компонентов ПС защищать программы и информацию. Надежность — обеспечение комплексом программ достаточно низкой вероятности отказа в процессе функционирования ПС в реальном времени. Эффективность — свойства ПС, обеспечивающие требуемую производительность решения функциональных задач. Практичность (применимость) — свойства ПС, обуславливающие сложность его понимания, изучения и использования. Сопровождаемость — приспособленность ПС к модификации и изменению конфигураций и функций. Мобильность — подготовленность ПС к переносу из одной аппаратно-операционной среды в другую.
1. Введение Настоящее техническое задание распространяется на разработатку программного модуля «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). 2. Основание для разработки Программа разрабатывается на основе сведений о сотрудниках кафедры. Наименование работы: « Программный модуль «Кафедра» ». Исполнитель: компания BestSoft.  Соисполнители: нет. З. Назначение Модуль предназначен для использования сотрудниками отдела кадров и деканата. 4. Требования к программе или программному изделию 4.1. Требования к функциональным характеристикам 4. l. l. Программа должна обеспечивать возможность выполнения следующих функций: Хранение вносимой информации в памяти и/или в базе данных; Вывод текстовой информации ;   • Визуальное предоставление информации о сотрудниках кафедры ;Распределение определенных файлов по соответствующим папкам/архивам (Например: Список со сведениями о преподавателях находится в C:\Users\User\Documents\ProgrModulKafedra\Учителя). 4.1.2. Исходные данные вводятся с устройства ввода или загружаются уполномоченным пользователем. 4.1.3. Организация входных и выходных данных Входные данные поступают с клавиатуры или из текстовых и графических документов. Выходные данные отображаются на экране и при необходимости выводятся на печать. 4.2. Требования к надежности Контроль вводимой информации. Регистрация и последующая авторизация уполномоченного пользователя. Блокировка некорректных действий пользователя при работе с системой. 4.3. Требования к составу и параметрам технических средств. Система должна работать на 1ВМ-совместимых персональных компьютерах.  Минимальная конфигурация: тип процессора. Pentium и выше;  объем оперативного запоминающего устройства 32 Мб и более; объем свободного места на жестком диске 64 Мб. Рекомендуемая конфигурация:  тип процессора. Pentium П 400; объем оперативного запоминающего устройства 128 Мб; объем свободного места на жестком диске 60 Мб. 4.4. Требования к программной совместимости. Программа должна работать под управлением семейства операционных систем Win 64 (Windows vista/7/8/10/ и т. п.). 5. Требования к программной документации Основными документами, регламентирующими разработку  будущих программ, должны быть документы Единой Системы Программной Документации (ЕСПД): руководство пользователя, руководство администратора, описание применения.6. Технико-экономические показатели  Эффективность системы определяется удобством использования системы для контроля и управления основными параметрами теплообеспечения помещений Московского института, а также экономической выгодой, полученной от внедрения аппаратно-программного комплекса.7. Порядок контроля и приемки  После передачи Исполнителем отдельного функционального модуля программы Заказчику последний имеет право тестировать модуль в течение 7 дней. После тестирования Заказчик дол-жен принять работу по данному этапу или в письменном виде изложить причину отказа принятия. В случае обоснованного отказа Исполнитель обязуется доработать модуль. 8. Календарный план работ
Руководитель работ Зубенко М.П. Практическая работа 4. Решение транспортной задачи в пакете ms Excel (LibreOffice ) Транспортная задача – это задача о минимизации транспортных расходов, связанных с обеспечением пунктов потребления определенным количеством однородной продукции, производимой в нескольких пунктах производства. В общем виде задача может быть сформулирована следующим образом. Однородный продукт, сосредоточенный в m пунктах производства, необходимо распределить между n пунктами потребления. Стоимость перевозки единицы продукции известна для всех маршрутов. Необходимо составить такой план перевозок, при котором запросы всех пунктов потребления были бы удовлетворены за счет имеющихся продуктов в пунктах производства и общие транспортные расходы по доставке продуктов были бы минимальными. Примем следующие обозначения: i – номер пункта производства, j –номер пункта потребления, ai– количество продукта, имеющееся в i-ом пункте производства, bj– количество продукта, необходимое для j-го пункта потребления, cij – стоимость перевозки единицы продукта из i-го пункта производства в j-й пункт потребления, xij – количество груза, планируемого к перевозке из i-го пункта производства в j-й пункт потребления,
Решение представлено на Рис.2.  Рис.2 (Готовое решение задачи) Практическая работа 5. Функциональная модель бизнес-процесса и CASE – средства Цель: Приобрести навыки построения функциональной модели бизнес-процесса в предметной области, используя CASE-средства и методологию IDEF0. Бизнес-процесс(БП) – упорядоченная во времени и пространстве совокупность взаимосвязанных работ, направленных на получение определенного результата (продукции, работ или услуг). Моделирование бизнес-процессов – это описание бизнес-процессов предприятия, позволяющее руководителю знать, как работают рядовые сотрудники, а рядовым сотрудникам – как работают их коллеги и на какой результат направлена вся их деятельность. Модель бизнес-процесса – представление бизнес-процесса на специализированном языке (с помощью специализированной нотации – текстовой, табличной, графической). Методологии: IDEF0 (BusinessProcess, функциональная модель) методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. В ней система представляется как совокупность взаимодействующих работ или функций; ARIS (Architecture of Integrated Information Systems) – методология и тиражируемый программный продукт для построения организационной и функциональной структур, структур данных и процессов; DFD (Data Flow, поток данных) – методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. Системы моделирования бизнес-процессов организации: AllFusionProcessModelerr7 (Computer Associates); RationalRose (Rational Software); OracleDesigner (Oracle); ARIS (IDSScheerAG); PowerDesigner (Sybase). Рис.3(Функциональная модель IDEF0)  Моделирование бизнес-процесса с использованием методологии IDEF0 Методология семейства IDEFO: Р  ис.4 (Функциональная модель бизнес процесса второго уровня)IDEF0 методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. В ней система представляется как совокупность взаимодействующих работ или функций. Практическая работа 6. |
