IT
Добро пожаловать на страницу ИТ-проектов в Лицее НИУ ВШЭ!
Здесь можно узнать, что является ИТ-проектом, как оформить сопроводительную документацию и как подготовиться к защите ИВР. Создание ИТ-проекта – это большая и интересная работа, в ходе которой вы приобретёте много полезных навыков и сможете пополнить ваше портфолио.
Что является ИТ-проектом
ИТ-проектом является деятельность, направленная на создание ИТ-продукта в рамках выполнения индивидуальной выпускной работы. Это значит, что в процессе работы над вашим проектом вы создадите ИТ-продукт, исходя из требований, предъявляемых к работе над ИВР в Лицее НИУ ВШЭ. Конечно, это определение вряд ли можно назвать строгим с точки зрения индустрии, но оно отражает главные особенности работы над ИТ-проектом. Более подробно о том, что такое проект и продукт, можно прочесть здесь:
https://habr.com/ru/companies/kuper/articles/667266/
Опишем различные свойства и характеристики ИТ-продуктов. Говоря об этом, мы, конечно, имеем в виду контекст индивидуальной выпускной работы, а не какие-то универсальные качества.
Что может быть ИТ-продуктом:
- мобильное приложение
- веб-сервис
- десктопное приложение
Общие свойства ИТ-продуктов:
- у продукта должна быть широкая целевая аудитория или конкретный заказчик;
- у продукта обязательно должен быть графический интерфейс;
- у продукта обязательно должен быть бэкенд;
- данные не должны храниться на том компьютере, планшете, смартфоне и т. п., где запускается ваши приложения и сервисы: запуская их на другом аналогичном устройстве, по логину и паролю должны подгрузиться все необходимые данные;
- к моменту релиза продукт должен быть полностью готов к использованию.
Что не может быть ИТ-продуктом
На самом деле, довольно трудно дать исчерпывающий перечень типов ИТ-продуктов, которые не могут быть допущены к защите в качестве ИВР. Если ваш проект не попадает в список того, что не может быть одобрено, это не значит, что он автоматически дойдёт до защиты. Все сомнительные случаи необходимо обсуждать в ходе индивидуальной консультации. И, конечно, необходимо отметить, что сами по себе эти вещи не являются “плохими”: это прекрасные и нужные сервисы, просто их создание не позволяет в полной мере развить те навыки, которые мы можно получить, создавая более сложные продукты.
Итак, к защите не допускаются:
- проекты, которые запускаются из командной строки, а также всевозможные библиотеки, фреймворки, модули, плагины и т. п., то есть программные элементы, которые являются частью большего продукта;
- сайты-визитки, приложения и другие ресурсы информационного характера, созданные, в том числе и c помощью блочных конструкторов, не требующих навыков программирования, а также проекты, созданные с помощью движков, работающих на собственных скриптах высокого уровня (например, Godot);
- Telegram-боты и боты для других мессенджеров и сервисов.
- продукты, выполняющие, главным образом, информационную функцию: всевозможные справочники, электронные энциклопедии, учебники и т. п.
- учебные курсы, электронные пособия и различные материалы для обучения и подготовки к экзаменам;
- монофункциональные проекты, то есть, такие, у которых есть только одна-две базовых функции;
- проекты, полностью дублирующие функционал других проектов;
- проекты, функциональность которых невозможно оценить на защите.
Примеры названий успешных ИТ-проектов (набор 2023 года):
- HelpForMum (Анастасия Зубаревич, 11И3) – мобильное приложение (iOS) для молодых мам, позволяющее вести пищевой дневник и справляться с проблемами аллергии у детей (27 баллов);
- EcoTrace (Архип Глинов, 11И2) – мобильное приложение (Android), объединяющее экологических энтузиастов – 29 баллов
- MyHealth (Ярослав Новиков, 11И1) – приложение, помогающее вести здоровый образ жизни – 27 баллов
Заявка на ИТ-проект
Особенностью публикации заявок на ИТ-проект является использование системы контроля версии Git и платформы GitHub, где размещается заявочный md-файл, помимо системы 2359. Сделано это для того, чтобы с самого начала у лицеистов был стимул изучать Git / GitHub.
Для знакомства с Git / GitHub предлагаем начать с тьюториала по ссылке: https://www.w3schools.com/git/
Про md-файлы можно почитать здесь: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax
Наконец, образец заявки на GitHub можно посмотреть по ссылке: https://github.com/aakuptsov/test_repo (файл akuptsov_application.md)
Обращаем внимание, что образец даёт представление лишь о структуре и о визуальном оформлении заявки, в то время как сложность проекта в заявке-образце весьма завышена.
Необходимые разделы заявки:
- проблемное поле
- заказчик или целевая аудитория
- аппаратные и программные требования
- функциональные требования
- похожие / аналогичные продукты
- инструменты разработки и информация о базе данных
- этапы разработки
- возможные риски
Рассмотрим каждый из этих разделов поподробнее.
Проблемное поле
Заказчик или целевая аудитория
Аппаратные и программные требования
Функциональные требования
Похожие / аналогичные продукты
Инструменты разработки и информация о базе данных
Этапы разработки
Возможные риски
Пользовательские сценарии (отчёт о ходе работы над проектом)
Итак, заявка на проект готова, зачёт за неё, будем надеяться, успешно получен, значит, необходимо дальше работать над проектом. Давайте посмотрим, что именно уже сделано с точки зрения ИТ-проектирования. Если коротко, мы описали проблемное поле, требующее какого-то software-решения, и указали, что именно будет делать пользователь нашего продукта для того, чтобы решить свою проблему. Можно ли уже, говоря по-простому, приступать кодить? Пожалуй, всё-таки рановато.
Дело в том, что хотя мы теперь и знаем, как именно будет себя вести пользователь, мы пока не понимает, из каких конкретных шагов будет состоять каждое его действие. То, что мы сформулировали, это важно, но пока ещё слишком обобщённо и нам необходимо конкретизировать пользовательские действия, разбить их на части, каждую из которых мы и будем разрабатывать.
Пример 1 – Аутентификация пользователя на сайте / в приложении
Пример 2 – Разграничение прав доступа
Пример 3 – рисование таблицы в текстовом редакторе
Пользовательским сценарием мы будем называть последовательность действий, описанных в формате “актор + глагол”, которая позволяет реализовать определённое функциональное требование. Упоминание функциональных требований неслучайно: дело в том, что каждое функциональное требование должно быть развёрнуто в пользовательском сценарии. А иначе, зачем бы мы его тогда выдвигали в нашей заявке?
Теперь, мы надеемся, всё складывается в довольно логичную картину: сначала, на этапе заявки, мы проектируем функциональные требования, потом мы каждое требование разворачиваем в пользовательском сценарии, прописывая шаги, как именно оно должно быть реализовано в продукте.
Требования к пользовательским сценариям:
- каждому функциональному требованию в заявке на проект должен соответствовать минимум один пользовательский сценарий, таким образом, пользовательских сценариев должно быть минимум 9;
- каждый пользовательский сценарий должен начинаться по шаблону “актор + глагол”;
- в отличие от функциональных требований, каждый шаг сценария – это законченное предложение, но не стоит его делать слишком длинным и не стоит формулировать один шаг в нескольких предложениях (см. образец на GitHub)
- каждый сценарий должен состоять из 7-9 шагов минимум. Меньшее число шагов свидетельствует о недостаточной проработке сценариев, если же шагов больше 7-9, то это даёт повод задуматься либо о том, что некоторые этапы сценария слишком детализированы, либо о том, что один большой сценарий необходимо разбивать на два отдельных поменьше;
- в каждом сценарии должны быть описаны шаги, имеющие отношение к конкретному функционалу, не нужно начинать сценарии с действий типа “пользователь включает компьютер”, “пользователь запускает приложение”
и т. п.; - в сценариях необходимо предусмотреть реакцию системы на тот случай, если “что-то пойдёт не так”, например, если в компьютерной игре пользователь пытается купить оружие, на которое у него не хватает монет, ему необходимо сообщить об этом (альтернативным решением является показать игроку то, что он может купить за имеющиеся у него средства, но тогда в сценарии покупки это тоже необходимо отразить, например, “система выводит список товаров, которые пользователь может приобрести за имеющиеся у него средства”;
- к названию файла с пользовательскими сценариями и его визуальному оформлению предъявляются определённые требования, понять которые можно, ознакомившись с образцом:
https://github.com/aakuptsov/test_repo/blob/master/akuptsov_userscripts.md
Изменения в проекте
Сначала оговоримся, что в этом разделе мы не будем обсуждать смену типа ИВР или темы. Скажем только, что да, можно поменять проект на исследование и наоборот, можно менять тему ИВР, а также отметим, что в проектах, в том числе и в ИТ, есть момент, после которого ничего уже менять будет нельзя, но про этом мы напишем в отдельном разделе.
Итак, изменения. А куда же без них? В очень редких случаях проблемное поле и образ продукта задаются сразу, не претерпевают изменений и воплощаются так, как было написано в первоначальном документе. Это совершенно нормально. Произойти это может по многим причинам: например, в ходе интервью с представителями целевой аудитории выясняется, что они свою проблему видят не так, как вы, или, например, вы понимаете, что функциональные требования должны быть другие, или вы решили упростить реализацию тех или иных функций, что должно найти отражение в пользовательских сценариях.
Рассмотрим разные случаи.
1) Расширение функционала
2) Изменение уже существующего функционала
3) Сужение функционала
Окончательная заявка на проект
До определённого момента вносить изменения можно хоть каждый день, но в конце сентября (как правило) настаёт момент, когда все ваши изменения надо зафиксировать, получить одобрение и после этого ничего уже нельзя будет поменять. Возможно, это звучит излишне сурово, но если посмотреть на всю ленту времени, то окажется, что это всего лишь за месяц-за полтора до сдачи итоговых материалов. В этом есть свою плюс: в какой-то момент надо уже окончательно определиться с функционалом и работать, а не менять что-то до последнего.
1) создать в репозитории вашего проекта файлы final_application.md и final_scripts.md;
2) если в вашей заявке будут изменения в сравнении с первоначальной, вы должны ещё создать файл changes.md;
3) в файлах final_application.md и final_scripts.md, очевидно, будут ваши окончательные заявка и сценарии (с изменениями или без);
4) в файле changes.md будут отражены изменения, если таковые имеются, в формате:
1. Функциональное требование № / Пользовательский сценарий №
Краткое описание изменения: планировалось А, Б, В, стало – Б, Г, Д
Причина: укажите причину, по которой произошли изменения
5) если у вас изменений никаких нет (первоначальная заявка и сценарии, и окончательная заявка и окончательные сценарии – идентичны), то напишите просто “Изменений нет”;
6) ВНИМАНИЕ (много раз): даже если у вас изменений нет, файлы final_application.md и final_scripts.md должны быть. Пусть они будут повторять до байта первоначальные файлы, но быть в корне репозитория они должны. Также обязательно должен быть файл changes.md, даже если изменений нет (что там должно быть – см. выше);
7) ВНИМАНИЕ (ещё раз): файлы с первоначальной заявкой и сценариями удалять не нужно – в репозитории нужно создать папку OLD и поместить их туда;
Итак, будем считать, что окончательная заявка и сценарии утверждены и теперь уже мы на 100% знаем, что именно вы будете представлять на защите. Переходим к следующим этапам – показ кода.
Первый показ кода
Есть такая “бородатая” мемная фраза о том, что половина работы по написанию курсовой / диплома и т. п. – это создание на рабочем столе папки “Курсовая” / “Диплом” и т. п. Помимо шутки в этом есть своя логика: какое-то хотя бы символическое начало должно быть. Говоря метафорически, первый показ кода – это создание такой папки. Вам необходимо сделать следующее:
- создать в репозитории как минимум пустую папку проекта, а как максимум – представить какую-то часть кода вашего проекта (возможно, уже написанную вами до этого);
- в корне репозитория создать файл first_code.md, в котором вы опишете, что именно вы сделали, например, “Создана пустая папка будущего проекта”, “Реализованы функциональные требования №1 и №3” и т. п.
ВНИМАНИЕ: если какой-то код в репозитории представлен даже до дедлайна, но файл first_code.md отсутствует, этап считается не пройденным.
Как видите, требования к этому этапу небольшие и его цель – скорее, психологическая: обозначить начало работы над проектом (если, конечно, она не началась ранее, что предпочтительнее).
Второй показ кода
Тут уже посерьёзнее, шутки заканчиваются. На этом этапе у вас должно быть реализовано плюс-минус 50% всего вашего проекта. Это значит, что должны уже полноценно работать 4-5 сценариев. Что нужно на этом этапе:
- реализовать 4-5 сценариев из вашего проекта;
- закоммитить их в репозиторий проекта;
- создать файл second_code.md
- в этом файле опубликовать ссылку на видео, где демонстрируется работа вашего наполовину готового проекта. О видео речь пойдёт ниже;
Требования к демонстрационному видео
Итоговые материалы
Рано или поздно всё заканчивается, включая работу над ИВР. К определённому дню вам необходимо будет сдать итоговые материалы. Если после окончательной заявки нельзя изменять функционал проекта, то после сдачи итоговых материалов нельзя менять ни одного байта и ни одной буквы в проекте. Да, вот так строго, но так это работает.
Итак, что нужно для сдачи итоговых материалов.
- Записать видео, аналогичное второму показу кода, только в этот раз вы демонстрируете работу всего проекта. Обратите, пожалуйста, внимание, что вам нужно записать новое видео (к этому моменту вы уже освоите запись видео и сделаете это быстро, я думаю) по всем сценариям, а не добавить к видео из второго показа недостающие сценария. Все остальные требования к внутреннему оформлению и качеству – такие же.
- Закоммитить полностью ваш проект, все файлы, в репозиторий. В случае, когда это по тем или иным причинам сделать невозможно (исключая причину “я не сделал / не сделала проект”), просьба сообщить мне об этом заранее. Случаи “я за 5 минут до дедлайна сдачи понял / поняла, что проект не коммитится”, рассматриваться не будут.
- Выслать отчёт как в 2359, так и в репозитории (об этом ниже).
ВНИМАНИЕ: проект допускается до защиты, если выполнены все три условия: есть видео, есть полностью доступный код проекта, есть отчёт
Отчёт о проекте
В любом (ну почти) проекте есть проектная документация, которой, будет строги, часто уделяется не меньшее внимание, чем продукту. В ИТ-проектах важным является написание отчёта. Почему это важно? Предлагаю ознакомиться с критериями и посмотреть, сколько баллов даётся за отчёт.
Титульный лист проекта с точки зрения содержания должен быть оформлен так.
Другие требования к оформлению:
- шрифт – Times New Roman, Calibri или HSE Sans;
- размер: 14, интервал: 1.5;
- поля: 2 cм, выравнивание: по ширине;
- после заголовков точки не ставятся;
- нумерация страниц – снизу по центру, титульный лист не нумеруется.
В отчёте должны быть следующие разделы:
- введение – краткое описание проекта: что из себя представляет продукт, почему вы решили его делать, что сподвигло на это;
- проблемное поле: вы описываете, какую проблему вы описываете, а также описываете результаты проведённых количественных и качественных интервью (см. критерии оценивания);
- целевая аудитория;
- функциональные требований – перечисление с кратким описанием;
- используемый стек технологий;
- этапы работы над проектом (реальные, не предполагаемые, как в первоначальной заявке, а те, которые реально получились) – содержание, сроки;
- краткий анализ аналогичных продуктов;
- рефлексия;
Поскольку рефлексия получила отдельный критерий в системе оценивания ИВР, перечислим отдельно подразделы, которые должны быть в рефлексии:
- проблемы, которые возникли в процессе работы над проектами и способы их решения;
- какие умения и навыки были приобретены в процессе работы над проектом и как их можно применить в дальнейшем;
- что можно было бы сделать по-другому;
- как можно дальше развивать проект.
Обратите, пожалуйста, внимание, что отчёт пишется в повествовательном виде (связным текстом), не тезисно и не перечислением каких-либо пунктов.
Также обратите внимание, что в отчёте важны не только содержание и оформление, но и грамотность. Обидно будет потерять баллы за орфографические или пунктуационные ошибки.
Нашли опечатку?
Выделите её, нажмите Ctrl+Enter и отправьте нам уведомление. Спасибо за участие!
Сервис предназначен только для отправки сообщений об орфографических и пунктуационных ошибках.