Файл: Министерство науки и высшего образования российской федерации рубцовский институт (филиал) федерального государственного бюджетного образовательного учреждения высшего образования.doc
Добавлен: 25.10.2023
Просмотров: 193
Скачиваний: 7
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ
Рубцовский институт (филиал) федерального государственного бюджетного образовательного учреждения высшего образования
«Алтайский государственный университет»
Кафедра математики и прикладной информатики
ОТЧЕТ
о прохождении учебной практики
по профессиональному модулю ПМ.03 Ревьюирование программных продуктов
в Рубцовском Институте (филиале) АлтГУ
Выполнил
Студент 2 курса
группы 1215С11
____________________________
(подпись студента)
Руководитель практики от Рубцовского Института (филиала) АлтГУ:
Рязанова О.В.
Оценка_____________
«_____» ________ 2023г.
Подпись руководителя:
_____________________
Рубцовск 2023
ВВЕДЕНИЕ
Учебная практика по профессиональному модулю ПМ.03 Ревьюирование программных продуктов является частью профессионального цикла, входит в профессиональный модуль ППССЗ в соответствии с ФГОС СПО по специальности 09.02.07 Информационные системы и программирование, квалификация: специалист по информационным системам базовой подготовки в части освоения основного вида профессиональной деятельности – осуществление интеграции программных модулей.
Вид практики – учебная.
Учебная практика проводится непрерывно в рамках профессионального модуля.
Целью учебной практики по профессиональному модулю ПМ.03 Ревьюирование программных продуктов является дальнейшее закрепление и совершенствование приобретенных в процессе обучения знаний, полученных при изучении конкретных дисциплин, овладение обучающимися видом профессиональной деятельности – осуществление интеграции программных модулей, общими и профессиональными компетенциями по специальности, получение первоначального практического опыта.
Задачи учебной практики:
– формирование у обучающихся профессиональных умений, приобретение первоначального практического опыта, направленное на освоение вида деятельности Ревьюирование программных продуктов и способствующее формированию общих и профессиональных компетенций;
– закрепление теоретических знаний, полученных в процессе обучения профессиональных модулей;
– получение практического опыта в области ревьюирования программного кода, разработки технического задания при формировании проекта, измерения характеристик компонент программного продукта для определения соответствия заданным критериям, исследования созданного программного кода с использованием специализированных программных средств с целью выявления ошибок и отклонения от алгоритма;
-
проверка готовности обучающихся к самостоятельной трудовой деятельности; -
сбор, анализ и обобщение материалов для подготовки отчета по пройденным видам работ.
Индивидуальные задания, полученные от руководителя практики:
-
Изучить методы моделирования и анализа программного кода. -
Изучить теоретические основы ревьюирования программных продуктов. -
Изучить измерительные методы оценки программ, эталонов и методов проверки корректности программ -
Изучить метрики сложности, стилистики и понятности программных продуктов. -
Ознакомиться с назначением и функциональными возможностями типовых инструментов анализа программных проектов. -
Выполнить сравнительный анализ программных продуктов (офисные пакеты, браузеры, средства просмотра видео, средства создания видео и т.д) для выявления наилучшего решения. Выполнить анализ достоинств и недостатков не менее, чем трех программных продуктов. Выбрать критерии сравнения. Определить характеристики программных продуктов различными методами и инструментами. Оформить результаты сравнительного анализа программных продуктов и их версий. -
Выполнить сравнительный анализ средств разработки программных продуктов с указанием набора возможных средств выполнения поставленной задачи. Выполнить анализ достоинств и недостатков не менее, чем трех средств разработки. Оформить результаты сравнительного анализа в виде таблицы. -
Создать схемы организации менеджмента программного проекта (по предложенной предметной области). -
Изучить возможности и создать репозитории программного проекта по варианту предметной области (на примере: Eclipse Neon3, NetBeans, VisualStudio и др.). -
Изучить возможности организации работы над программным проектом по варианту предметной области в команде разработчиков в среде разработки (по выбору). -
Разработать проектную документацию программного проекта с использованием графических спецификаций. Определить этапы построения модели. Выбрать доступный инструмент моделирования. Составить ТЗ на разработку ПО. Выполнить моделирование ПО. -
Провести планирование code-review. -
Приобрести практические навыки выполнения оптимизации программного кода с использованием специализированных программных средств. -
Приобрести навыки планирования, проведения и оформления результатов ревьюирования программных продуктов. -
Проверить целостность программного кода. -
Провести выполнение измерений характеристик кода в средах Eclipse Neon3, NetBeans, Visual Studio и оформить результаты. -
Вести индивидуальный дневник практики в соответствии с установленными требованиями. -
Подготовить письменный отчет по результатам практики.
СОДЕРЖАНИЕ
Задание 1
Моделирование программного кода – это процесс создания абстрактной модели программы, которая позволяет разработчикам лучше понять и визуализировать структуру, поведение и взаимодействие компонентов программы. Это мощный инструмент, который может быть использован на различных этапах жизненного цикла разработки программного обеспечения. Моделирование программного кода помогает улучшить процесс разработки, повысить качество программного обеспечения и обеспечить понимание и согласованность среди разработчиков и заинтересованных сторон.
Существует несколько методов моделирования программного кода:
Диаграмма прецедентов использования является одним из видов диаграмм в языке моделирования UML. Используется для визуализации функциональности или поведения системы из точки зрения ее актеров
Диаграммы взаимодействия – это тип диаграмм, используемых в языке моделирования UML, который позволяет визуализировать взаимодействие между объектами или компонентами системы в рамках определенного сценария или варианта использования. Диаграммы взаимодействия помогают разработчикам лучше понять взаимодействие и обмен сообщениями между объектами или компонентами системы в рамках определенного сценария. Помогают визуализировать и анализировать поведение системы, выявлять потенциальные проблемы и оптимизировать взаимодействие между компонентами. Диаграммы взаимодействия являются важным инструментом при разработке и проектировании систем, а также для коммуникации и согласования с заинтересованными сторонами.
Диаграмма деятельности – это один из видов диаграмм в языке моделирования UML. Используется для визуализации процессов, процедур или бизнес-логики в системе. Диаграмма деятельности показывает последовательность шагов и переходов между различными действиями в процессе. Диаграммы деятельности помогают визуализировать процессы и логику выполнения в системе. Могут использоваться для анализа, проектирования, документирования и коммуникации в рамках разработки программного обеспечения или моделирования бизнес-процессов. Диаграммы деятельности часто применяются для моделирования сценариев использования, анализа временных аспектов системы и определения последовательности действий в процессе.
Диаграмма классов – это один из основных видов диаграмм в языке моделирования UML. Используется для визуализации структуры классов в системе, их атрибутов, методов и взаимосвязей. Диаграммы классов помогают визуализировать структуру системы, отображая классы, их атрибуты и методы, а также связи между ними. Являются важным инструментом для анализа, проектирования и документирования программного обеспечения. Диаграммы классов помогают разработчикам лучше понять архитектуру системы, их взаимосвязи и иерархию классов. Также используются для коммуникации между разработчиками и заинтересованными сторонами в процессе разработки программного обеспечения.
Диаграмма компонентов – это один из видов диаграмм в языке моделирования UML, который позволяет визуализировать структуру компонентов системы и их взаимосвязи. Диаграмма компонентов помогает разработчикам лучше понять структуру системы и взаимосвязи между компонентами. Используется на этапе анализа, проектирования и документирования системы. Диаграмма компонент также может быть полезна для коммуникации между разработчиками и заинтересованными сторонами, а также для планирования и управления разработкой программного обеспечения.
Диаграмма размещения. Диаграмма размещения – это один из видов диаграмм в языке моделирования UML, который позволяет визуализировать физическую архитектуру системы и размещение её компонентов на различных узлах. Диаграмма размещения помогает разработчикам и системным архитекторам визуализировать и понять физическую конфигурацию и развертывание системы. Позволяет анализировать и планировать распределение компонентов на различных узлах, выявлять потенциальные узкие места и проблемы производительности. Диаграмма размещения также полезна при коммуникации с разработчиками, администраторами системы и другими заинтересованными сторонами для обсуждения физической инфраструктуры и архитектурных решений.
Задание 2
Ревьюирование программного кода, также известное как инспекция кода, является систематическим и периодическим процессом анализа программного кода с целью обнаружения ошибок, которые могут не быть обнаружены на ранних этапах разработки. Оно также направлено на выявление некачественных архитектурных решений и критических участков в коде программы.
Иногда невозможно разработать автоматические или чётко формализованные ручные тесты для проверки функциональности программной системы. В некоторых случаях невозможно выполнить тестируемый программный код в условиях, создаваемых тестовым окружением. Это особенно актуально для встроенных систем, где программный код предназначен для обработки исключительных ситуаций, которые возникают только на реальном оборудовании.
В таких ситуациях, когда верифицируется не сам программный код, а проектная документация для системы, которую невозможно выполнить или создать отдельные тестовые примеры, часто используется метод экспертного исследования программного кода или документации для проверки его корректности и отсутствия противоречий.
Инспекции или просмотры являются экспертными исследованиями, которые могут быть неформальными или формальными. В неформальной инспекции автор передает эксперту определенный документ или часть программной системы, и эксперт после ознакомления составляет список замечаний, которые автор вносит исправления. Однако сам факт проведения инспекции и список замечаний не сохраняются отдельно, и состояние исправлений не отслеживается.
Формальная инспекция, напротив, является управляемым процессом с четкой структурой, которая обычно определяется стандартом проекта. Все формальные инспекции имеют одинаковую структуру и выходные документы, которые затем используются в процессе разработки. Факт начала формальной инспекции явно фиксируется в общей базе данных проекта, а также регистрируются документы, подвергаемые инспекции, и списки замечаний. Внесенные изменения, основанные на замечаниях, также отслеживаются. Формальная инспекция имеет схожие черты с автоматизированным тестированием: списки замечаний аналогичны отчетам о выполнении тестовых примеров.
В процессе формальной инспекции группой специалистов проводится независимая проверка соответствия инспектируемых документов исходным документам. Независимость проверки обеспечивается тем, что инспекторы, не участвовавшие в разработке инспектируемого документа, осуществляют эту проверку. Входными данными для процесса формальной инспекции являются инспектируемые документы и исходные документы, а результатом являются материалы инспекции, включающие список обнаруженных несоответствий и решение о изменении статуса инспектируемых документов.
Этапы формальной инспекции и роли ее участников процесс формальной инспекции состоит из пяти фаз: инициализация, планирование, подготовка (экспертиза), обсуждение, завершение.
Формальная инспекция включает пять этапов, каждый из которых выполняет свою роль в процессе:
Инициализация: на этом этапе определяются цели и задачи инспекции, формируется команда участников, определяются роли и ответственности каждого участника. Также проводится обзор инспектируемых документов и определяется распределение задач между участниками.