Требования к разрабатываемому программному продукту и критерии его оценки

Hrcb

Согласовано Председатель ГЭК, к.т.н, управляющий ООО «РНД СОФТ» «__»___________2020 г. ___________Р.А. Забродин (подпись)

Утверждаю Директор ГБПОУ РО «РКСИ» «__»______________2020 г. ___________С.Н. Горбунов (подпись)

Критерии оценки качества подготовки ВКР по рейтинговой системе

для специальности

09.02.03«Программирование в компьютерных системах»

Ростов-на-Дону

2020 г.

Рассмотрено На заседании цикловой комиссии “Программирование” Протокол № ___ от ____________ 2020 г. Председатель ЦК ___________

Согласовано Зам. директора по НМР «__»___________2021 г. ___________И.В. Подцатова

Содержание

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

2. Общие требования к выпускной квалификационной работе (ВКР)................... 4

3. Требования к разработке программного продукта...............................................8

4. Правила оценки ВКР..............................................................................................13

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

Настоящие критерии разработаны в соответствии с порядком организации и проведения государственной итоговой аттестации выпускников в ГБПОУ РО «РКСИ» утвержденным директором колледжа 08.09.2014г. и регламентируют использование балльно-рейтинговой системы оценивания результатов подготовки и защиты ВКР, основанной на дифференциации баллов и четких критериях таксономии, при проведении процедур предзащиты и защиты работы (проекта).

Настоящие критерии и требования к ВКР определяют порядок оценки выпускной квалификационной работы выпускников по специальности 09.02.03 «Программирование в компьютерных системах» в ГБПОУ РО «РКСИ».

Настоящие требования обязательны к применению Государственной экзаменационной комиссией во время оценивания ВКР.

Целью рейтинговой оценки является:

- повышение качества подготовки и защиты ВКР;

- создание благоприятного эмоционального фона оценивания;

- получение комплексной, объективной и достоверной оценки качества ВКР.

Общие требования к выпускной квалификационной работе (ВКР)

К выпускной квалификационной работе специальности 09.02.03 предъявляются следующие требования:

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

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

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 сведения о внедрении;

5.16 заключение;

5.17 список литературы;

5.18 приложения:

− графические материалы;

− документация;

− файлы исходных кодов;

− прочие дополнения, необходимые для полноты описания работы.

6. Содержание пояснительной записки:

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

6.2 Сбор, анализ и формирование требований к ПП.

Описательная часть отражает два этапа:

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

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

6.3 Проектирование и разработка архитектуры ПП. На данном этапе необходимо:

− сформировать диаграмму связей (mindmap) – графическую схему взаимодействия объектов (модулей, страниц и т. д.) проектируемого ПП;

− разработать сценарии использования проектируемого ПП (Use-case диаграммы);

− произвести прототипирование основных экранных форм (с использованием любых продуктов или онлайн-сервисов для прототипирования. Как-то, но не ограничиваясь: www.ninjamock.com, www.moqups.com);

− выбрать архитектуру разрабатываемого ПП (автономные, двухзвенные, многозвенные, CORBA, SOA, REST и т. д.), сформировать графическую схему, описать её структуру и основные элементы;

− выбрать и обосновать выбор базы данных (исходя из модели данных) и СУБД, описать таблицы данных, структуру хранимых данных;

6.4 Разработка ПП.

В данном разделе необходимо:

− выбрать и обосновать выбор инструментальных средств разработки, системы управления проектом, хранилище средств контроля версионности git (github, gitlab, bitbucket) и т. д.; В случае уже принятого в качестве стандарта набора инструментальных средств у заказчика явно это указать.

− сформировать календарный план разработки ПП.

6.5 Тестирование ПП.

− выбрать метод проверки качества (ручное/автоматизированное тестирование, интеграционное, нагрузочное, функциональное, A/B-тестирование), обосновать выбор;

− разработать тест-план и тест-кейсы проверки качества ПП;

− провести соответствующее тестирование и зафиксировать количество обнаруженных ошибок в баг-репорте с подробным воспроизведением шагов, приводящих к ошибке (с дальнейшим исправлением ошибок и повторением итерации тестирования);

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

6.6 Разработка документации на ПП.

Раздел может содержать:

− структуру разрабатываемой документации. Например, систему помощи в приложении (Help), руководства по установке ПП, пользователя, администратора, программиста, по технической поддержке и т. д., которые выносятся в приложения к диплому.

6.7 Информационная безопасность:

− исходя из обрабатываемых и хранимых данных в ПДн, рассмотреть методы обеспечения информационной безопасности, особенно при хранении информации, содержащей персональные данные пользователей.

6.8 Экономическая часть может содержать расчёты себестоимости разработанного программного продукта, расчёт экономической эффективности разработанного программного продукта.

6.9 ТБ и ОТ – в данном разделе рассматриваются вопросы, связанные с выбором мер охраны труда при выполнении работ, связанных с разработкой программного продукта, а также охраны труда производственного персонала, созданием комфортных условий при разработке программного продукта.

6.10 Сведения о внедрении – информация о дальнейшем использовании программного продукта заказчиком со ссылкой на документы, подтверждающие факт внедрения (проверяется руководителем и отражается в отзыве), подтверждением является полноценно внедренный в работу заказчика проект и продемонстрированный на защите (опубликован в сети в домене заказчика, имеются первые пользователи, посетители и т.д.).

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

6.12 Список используемых источников:

– с обязательным указанием ссылок в пояснительной записке на печатные издания и/или интернет-ресурсы.

6.13 Приложение (обязательное) должно содержать программный код (выборочный, определённый руководителем) разработанного программного продукта.

6.14 Графическая часть должна отражать схемы, таблицы, графики, скриншоты программного продукта, определённые руководителем.

Примечание. В случае выполнения ВКР группой студентов в пояснительной записке каждым членом группы освещаются вопросы основной части, соответствующие его индивидуальному заданию.

7. Рекомендации к объему пояснительной записки.

Рекомендуемый объем пояснительной записки дипломного проекта 45-50 листов печатного текста, с соблюдением требований правил оформления текстовых документов в РКСИ.

7.1 Введение – примерно 2% от общего объема ПЗ, т.е. 1 лист печатного текста).

7.2 Сбор, анализ и формирование требований к ПП — примерно 14% от общего объёма ПЗ, т. е. 6-8 листов печатного текста.

7.3 Проектирование и разработка архитектуры ПП — примерно 20% от объёма ПЗ, т. е. около 10 листов печатного текста.

7.4 Разработка ПП – примерно 10% от общего объема ПЗ, т.е. 5 листов печатного текста.

7.5 Тестирование ПП - примерно 21% от объёма ПЗ, т. е. около 9 листов печатного текста.

7.6 Разработка документации на ПП - примерно 2% от объёма ПЗ, т. е. 1 лист печатного текста.

7.7 Информационная безопасность - содержание и объём данного раздела ПЗ определяется способами обработки и представления ПДн в программном продукте и ВКР.

7.8 Экономическая часть – содержание и объем данного раздела ПЗ определяется методологией представленной консультантом по экономической части.

7.9 ТБ и ОТ– примерно 3% от общего объема ПЗ, т.е. 3 листа печатного текста.

7.10 Внедрение программного продукта подтверждается справкой о внедрении выданной заказчиком, утверждается печатью организации и составляет 1% от общего объема ПЗ, т.е. 1 лист.

7.11 Заключение – примерно 2% от общего объема ПЗ, т.е. 1 лист печатного текста

7.12 Список используемых источников – примерно 3% от общего объема ПЗ, т.е. 1-2 листа печатного текста.

7.13 Приложение (обязательное) – не более 25% от общего объема ПЗ, т.е. 12 листов печатного текста.

Примечание. В случае выполнения ВКР группой студентов объём разделов основной части пояснительной записки может варьироваться в соответствии с индивидуальным заданием каждого члена группы.

8. Оформление пояснительной записки ВКР должно соответствовать требованиям Правил оформления текстовых документов, принятых в ГБПОУ РО «РКСИ». Контроль над соблюдением требований оформления ВКР возложен на руководителя ВКР.

Требования к разрабатываемому программному продукту и критерии его оценки

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

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

Оценка «удовлетворительно»		Оценка «хорошо»	Оценка «отлично»
Программные продукты (модули), работающие с базой данных и самостоятельно
При работе с серверной или распределённой базой данных: − спроектирована база данных; − создана база данных; − отображение содержимого базы данных в пользовательском интерфейсе; − операции с данными в пользовательских интерфейсах: сортировка, добавление, изменение, удаление. При работе с источниками данных (открытые данные, API, сервисы): − отображение содержимого источника данных в пользовательском интерфейсе; − операции с данными в пользовательских интерфейсах: сортировка, добавление, изменение, удаление.		К критериям на оценку 3 балла добавляется как минимум одна из функций: − выгрузка данных в любом из сторонних форматов: в два простых (csv, html, OpenOffice, xml, txt и т.д.) или один сложный (pdf, doc, rtf, xls и т. д.); − подготовка и представление форм отчётов под требования заказчика; − использование шифрования пользовательских данных для локальных БД; − для API - шифрование соединения внешними сервисами.	К критериям на оценку 4 балла добавляются функции: − использование сторонних библиотек; − работа с облачными хранилищами или аналогичными по сложности сервисами (движками, модулями); − статическая сборка приложения; − создание инсталлятора для готовой программы; − для модуля – наличие скомпилированной версии библиотеки.
Совместные дипломные работы по разработке программных продуктов, работающих с использованием баз данных
*Разработка базы данных*
При работе с серверной или распределённой базой данных: – разработана инфологическая модель базы данных; − разработана логическая модель базы данных (построена нормализованная ER-модель в CASE-средстве); − база данных реализована на физическом уровне; – реализованы запросы на добавление, удаление и изменение данных; – реализованы запросы на выборку.		К критериям на оценку 3 балла добавляется: – реализованы запросы к нескольким таблицам.	к Критериям на оценку 4 балла добавляется: – расписаны все этапы нормализации отношений от 1НФ до 3НФ (ДКНФ); – реализованы хранимые процедуры и триггеры.
*При разработке программных продуктов, работающих с использованием базы данных*
− отображение содержимого базы данных в пользовательском интерфейсе; − операции с данными в пользовательских интерфейсах: сортировка, добавление, изменение, удаление.		К критериям на оценку 3 балла добавляется как минимум одна из функций: – проведена проверка вводимых данных на корректный ввод и вывод сообщения о допущенных ошибках; − выгрузка данных в любом из сторонних форматов: в два простых (csv, html, OpenOffice, xml, txt и т.д.) или один сложный (pdf, doc, rtf, xls и т. д.); − подготовка и представление форм отчётов под требования заказчика; − использование шифрования пользовательских данных для локальных БД.	К критериям на оценку 4 балла добавляются функции: − использование сторонних библиотек; − работа с облачными хранилищами или аналогичными по сложности сервисами (движками, модулями); − статическая сборка приложения; − создание инсталлятора для готовой программы; − для модуля – наличие скомпилированной версии библиотеки.
Сайт, лендинг, электронный учебник
− блочная вёрстка; − при разработке использованы JS, CSS; − изменён шаблон сайта. (Верстку необходимо производить самостоятельно, при использовании доп. компонентов/библиотек необходимо понимать их функциональность и ориентироваться в них)		К критериям на оценку 3 балла добавляются функции: − семантическая верстка; − дизайн разработан с учётом целевой аудитории; − сайт содержит больше 3-х страниц или секций; − использование CMS по требованию заказчика с изменением кода используемого шаблона или плагина; − сайт адаптируется под разные размеры экранов (минимальный размер 320 × 568px (iPhone SE)) .	К критериям на оценку 4 балла добавляются функции: − проект написан с использованием клиентских и серверных языков программирования; − пройдена проверка PageSpeed Insights API (PSI) не ниже 80 баллов; − использование умных селекторов; − все страницы имеют мета-параметры и Open Graph теги; − административная / серверная часть сайта разработана самостоятельно ИЛИ реализована с помощью CMS (с обязательной разработкой собственного шаблона и виджета/плагина/модуля, а также реализацией возможности редактирования всего контента (контактные данные, галереи, изображения, текст и т.д.) сайта из админ-панели); − функции тестирования с выводом результата (для электронных учебников).
Совместные дипломные работы по веб-разработке ( front - end + back - end )
*Front-end*
− блочная вёрстка; − при разработке использованы JS, CSS; − изменён шаблон сайта.		К критериям на оценку 3 балла добавляются функции: – использование AJAX, анимация на уровне JS или сопоставимые по сложности скрипты; − использование фреймворка; − использование и понимание паттернов проектирования.	К критериям на оценку 4 балла добавляются функции: – реализация SPA / SSR; − использование препроцессора; − автоматическая сборка проекта; − написание автоматических тестов; − реализация метода авторизации (oAuth2, JWT).
*Back - end (Использование CMS недопустимо)*
− все страницы сайта динамически генерируются; − реализовано API.		К критериям на оценку 3 балла добавляются функции: − разработаны скрипты взаимодействия с клиентской частью в количестве, не менее 3х (корзина и т. п.); − реализация документации API на основе общепринятых стандартов (OpenApi, Swagger); − использование серверного фреймворка; − использование паттернов проектирования; − использование миграций БД.	К критериям на оценку 4 балла добавляются функции: − написание автоматических тестов; − описание методики развертки проекта; − использование Docker; − создание «сервиса», вызов которого возможен в различных контроллерах.
Математические модели
− имеется постановка задачи; − построена математическая модель; − описан математический метод; − имеется аналитическое решение задачи; − использована модель на объекте исследования; − составлен алгоритм; − самостоятельно написана программа с пользовательским интерфейсом.		К критериям на оценку 3 балла добавляются этапы работы: − описаны входные и выходные данные; − имеется последовательность выполняемых операций в программе; − управление программой (установка, меню, команда); − динамические графики с элементами управления.	К критериям на оценку 4 балла добавляются этапы работы: − осуществляется вывод визуальных данных (отчёты и их выгрузка в формате PDF, XLS, графики- диаграммы).
	Мобильные приложения
	− разработано мобильное приложение для одной из основных платформ (без серверной части и веб-интерфейса); − использование стандартных стилей оформления интерфейса (flat, material design, apple interface guideline).	К критериям на оценку 3 балла добавляются функции: − нативное приложение; − взаимодействие мобильного приложения с серверной частью с помощью API (источник данных \ API \ встроенная БД); − использование паттернов проектирования.	К критериям на оценку 4 балла добавляются функции: − приложение размещено в сети (AppStore, GooglePlay, WindowsStore); − использования локального хранилища данных; − авторизация в приложении по стандартам (oauth2, jwt); − написание UI тестов; − использование реактивного подхода.
	Аппаратно-программные системы
	− реализована программа (внешний исполняемый файл или скрипт для ПК (смартфона, планшета и т.д.), управляющая (допускается режим односторонней передачи информации) или взаимодействующая с внешним модулем* или 4мя внешними устройствами**, а так же программа для микроконтроллера или автономной части АПС; − присутствует электрическая принципиальная схема АС, при использовании 3х и более модулей/устройств; − реализовано взаимодействие между двумя и более устройствами (датчиками, камерами и т.п.).	К критериям на оценку 3 балла добавляются функции: − разработан собственный интерфейс управления устройствами (двусторонняя передача данных); − передача данных осуществляется по беспроводным технологиям.	К критериям на оценку 4 балла добавляются функции: − взаимодействие модуля с внешним API; − присутствует созданная серверная часть; − использования сторонних скетчей проектов не более 40% реализуемого проекта; − создание руководства по эксплуатации.

* Под внешним модулем понимается автономная система имеющая собственный микроконтроллер, который запрограммирован соответственно требуемой задаче (Arduino, Raspberry Pi, wi-fi-модули и т.д.).

** Под внешними устройствами понимаются датчики и устройства, соответственно (участвующими в работе АС), и не имеющими собственных микроконтроллеров или имеющих стандартную программу в них. (переменные резисторы, диоды, динамики, bluetooth-модули, и.т. п.)

Программные продукты не указанные в пунктах выше оцениваются в соответствии с темой и заданием.

Правила оценки ВКР

Максимальным значением общего рейтинга выполнения дипломного проекта (работы) является 100 баллов. Интерпретация итогового рейтинга ВКР и ее защиты в традиционный формат производится по следующей шкале:

«5» - от 85-100 баллов и соблюдение требований к ПП на оценку «отлично»;

«4» - от 71-84 баллов и соблюдение требований к ПП на оценку «хорошо»;

«3» - от 55-70 баллов и соблюдение требований к ПП на оценку «удовлетворительно»;

«2» - менее 55 баллов.

Максимальная сумма баллов, которую выпускник может набрать составляет 100 баллов.

Минимальная (пороговая) сумма баллов, которая позволяет получить положительную отметку, составляет 55 баллов. При этом система оценки делится на три основные группы:

− подготовка ВКР;

− разработка программного продукта;

− защита ВКР.

Таблица 1 – Показатели и критерии оценки ВКР

Показатели	Критерии оценки	Баллы
Подготовка ВКР (оценивается руководителем ВКР)
Соответствие качества оформления пояснительной записки и графического материала требованиям нормоконтроля	1. имеются существенные замечания 2. соответствует с незначительными замечаниями 3. соответствует в целом	0 2 8
Количество используемой печатной литературы и Интернет ресурсов	1. низкое (до 10 источников) 2. среднее (от 11 до 15 источников) 3. высокое (от 16 и более)	0 1 2
Соблюдение графика подготовки и сроков сдачи готовой ВКР	1. не соблюдалось 2. соблюдалось	0 6
Участие в предзащите ВКР	1. не участвовал 2. участвовал	0 8
Грамматика оформления пояснительной записки	1. не соблюдается 2. соблюдается частично 3. соблюдается	0 2 4
Рекомендуемая оценка руководителя ВКР	1. оценка «неудовлетворительно» 2. оценка «удовлетворительно» 3. оценка «хорошо» 4. оценка «отлично»	0 3 4 5
Рекомендуемая оценка рецензента ВКР	1. оценка «неудовлетворительно» 2. оценка «удовлетворительно» 3. оценка «хорошо» 4. оценка «отлично»	0 3 4 5

Продолжение таблицы 1

Показатели	Критерии оценки	Баллы
Защита ВКР (оценивается членами ГЭК)
Оценка программного продукта в соответствии с критериями (смотрите раздел 3 ВКР)	1. оценка «удовлетворительно» 2. оценка «хорошо» 3. оценка «отлично»	13 23 34
Обоснованность выбранных инструментальных средств разработки и технологий разработки программного продукта	1. необоснованный выбор 2. частично обоснован 3. обоснованный выбор	0 4 8
Использование электронных средств управления проектом	1. не используется 2. используются	0 6
Внедрение программного продукта, подтвержденное справкой от заказчика.	1. не подтверждено 2. подтверждено	0 4
Качественная демонстрация реализованного проекта	1. отсутствует 2. присутствует	0 2
Уверенное изложение материала ВКР.	1. низкое 2. средние 3. высокое	0 1 3
Ответы на вопросы (количество вопросов рекомендуется не более 5)	1. отрицательный ответ; 2. положительный ответ.	1 балл (за каждый правильный ответ)

Показатель среднего итогового индивидуального рейтинга студента определяется председателем ГЭК как среднее арифметическое сумм баллов, поставленных членами ГЭК:

А=(К1+К2+К3+К4+Кn)/N

где А – итоговый рейтинг студента;

К – рейтинг студента, выставленный каждым из членов ГЭК;

N – количество членов ГЭК.

Примечание:

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

Литература:

1. Письмо Министерства образования и науки Российской Федерации от 20.07.2015 № 06-846 «О направлении Методических рекомендаций» https://www.garant.ru/products/ipo/prime/doc/71098018/

2. http://mosmetod.ru/files/metod/SPO/docx_spo/pril_2_06-846.pdf

Дата добавления: 2022-12-03; просмотров: 52; Мы поможем в написании вашей работы!

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

Мы поможем в написании ваших работ!