Файл: Министерство науки и высшего образования российской федерации рубцовский институт (филиал) федерального государственного бюджетного образовательного учреждения высшего образования.doc

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

Категория: Отчет по практике

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

Добавлен: 25.10.2023

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

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

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

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ

Рубцовский институт (филиал) федерального государственного бюджетного образовательного учреждения высшего образования

«Алтайский государственный университет»

Кафедра математики и прикладной информатики

ОТЧЕТ

о прохождении учебной практики

по профессиональному модулю ПМ.03 Ревьюирование программных продуктов

в Рубцовском Институте (филиале) АлтГУ

Выполнил

Студент 2 курса

группы 1215С11


____________________________

(подпись студента)

Руководитель практики от Рубцовского Института (филиала) АлтГУ:


Рязанова О.В.

Оценка_____________

«_____» ________ 2023г.

Подпись руководителя:

_____________________

Рубцовск 2023


ВВЕДЕНИЕ




Учебная практика по профессиональному модулю ПМ.03 Ревьюирование программных продуктов является частью профессионального цикла, входит в профессиональный модуль ППССЗ в соответствии с ФГОС СПО по специальности 09.02.07 Информационные системы и программирование, квалификация: специалист по информационным системам базовой подготовки в части освоения основного вида профессиональной деятельности – осуществление интеграции программных модулей.

Вид практики – учебная.

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

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

Задачи учебной практики:


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

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

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

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

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

Индивидуальные задания, полученные от руководителя практики:

  1. Изучить методы моделирования и анализа программного кода.

  2. Изучить теоретические основы ревьюирования программных продуктов.

  3. Изучить измерительные методы оценки программ, эталонов и методов проверки корректности программ

  4. Изучить метрики сложности, стилистики и понятности программных продуктов.

  5. Ознакомиться с назначением и функциональными возможностями типовых инструментов анализа программных проектов.

  6. Выполнить сравнительный анализ программных продуктов (офисные пакеты, браузеры, средства просмотра видео, средства создания видео и т.д) для выявления наилучшего решения. Выполнить анализ достоинств и недостатков не менее, чем трех программных продуктов. Выбрать критерии сравнения. Определить характеристики программных продуктов различными методами и инструментами. Оформить результаты сравнительного анализа программных продуктов и их версий.

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

  8. Создать схемы организации менеджмента программного проекта (по предложенной предметной области).

  9. Изучить возможности и создать репозитории программного проекта по варианту предметной области (на примере: Eclipse Neon3, NetBeans, VisualStudio и др.).

  10. Изучить возможности организации работы над программным проектом по варианту предметной области в команде разработчиков в среде разработки (по выбору).

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

  12. Провести планирование code-review.

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

  14. Приобрести навыки планирования, проведения и оформления результатов ревьюирования программных продуктов.

  15. Проверить целостность программного кода.

  16. Провести выполнение измерений характеристик кода в средах Eclipse Neon3, NetBeans, Visual Studio и оформить результаты.

  17. Вести индивидуальный дневник практики в соответствии с установленными требованиями.

  18. Подготовить письменный отчет по результатам практики.



СОДЕРЖАНИЕ



Задание 1

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

Существует несколько методов моделирования программного кода:

Диаграмма прецедентов использования является одним из видов диаграмм в языке моделирования UML. Используется для визуализации функциональности или поведения системы из точки зрения ее актеров

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

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


Диаграмма классов – это один из основных видов диаграмм в языке моделирования UML. Используется для визуализации структуры классов в системе, их атрибутов, методов и взаимосвязей. Диаграммы классов помогают визуализировать структуру системы, отображая классы, их атрибуты и методы, а также связи между ними. Являются важным инструментом для анализа, проектирования и документирования программного обеспечения. Диаграммы классов помогают разработчикам лучше понять архитектуру системы, их взаимосвязи и иерархию классов. Также используются для коммуникации между разработчиками и заинтересованными сторонами в процессе разработки программного обеспечения.

Диаграмма компонентов – это один из видов диаграмм в языке моделирования UML, который позволяет визуализировать структуру компонентов системы и их взаимосвязи. Диаграмма компонентов помогает разработчикам лучше понять структуру системы и взаимосвязи между компонентами. Используется на этапе анализа, проектирования и документирования системы. Диаграмма компонент также может быть полезна для коммуникации между разработчиками и заинтересованными сторонами, а также для планирования и управления разработкой программного обеспечения.

Диаграмма размещения. Диаграмма размещения – это один из видов диаграмм в языке моделирования UML, который позволяет визуализировать физическую архитектуру системы и размещение её компонентов на различных узлах. Диаграмма размещения помогает разработчикам и системным архитекторам визуализировать и понять физическую конфигурацию и развертывание системы. Позволяет анализировать и планировать распределение компонентов на различных узлах, выявлять потенциальные узкие места и проблемы производительности. Диаграмма размещения также полезна при коммуникации с разработчиками, администраторами системы и другими заинтересованными сторонами для обсуждения физической инфраструктуры и архитектурных решений.
Задание 2

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

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


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

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

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

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

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

Формальная инспекция включает пять этапов, каждый из которых выполняет свою роль в процессе:

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