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)
Обращаем внимание, что образец даёт представление лишь о структуре и о визуальном оформлении заявки, в то время как сложность проекта в заявке-образце весьма завышена.
Необходимые разделы заявки:
- проблемное поле
- заказчик или целевая аудитория
- аппаратные и программные требования
- функциональные требования
- похожие / аналогичные продукты
- инструменты разработки и информация о базе данных
- этапы разработки
- возможные риски
Рассмотрим каждый из этих разделов поподробнее.
Проблемное поле
Главная цель любого проекта – решить определённую проблему с помощью создания продукта, в нашем случае – ИТ-продукта. Не каждая проблема может решаться или должна решаться с помощью ИТ-продукта и многие проблемы могут быть решены уже имеющимися приложениями и сервисами, но, если вы полагаете, что для решения какой-то проблемы ваш продукт будет лучше, чем имеющиеся аналоги, вам необходимо доказать это и первое, что нужно сделать – описать проблемное поле и выделить проблему. Недостаточно просто сказать, что какая-то проблема есть, необходимо это доказать.
Требования к разделу:
- описание проблемного поля состоит из двух логических частей
- в первой части задаётся контекст, кратко описывающий ту предметную / социальную область, в которой функционирует продукт
- в этом описании кратко упоминаются главные акторы, которые используют продукт
- после этого идёт описание проблемы в лексическом поле “трудности”: отсутствие, невозможность осуществить что-либо, недостаточность, медленная скорость, большие затраты на решение проблемы имеющимися способами и т. п.
- необходимо избегать описание проблемы в виде описания того, что будет хорошего после создания продукта, например: “всем понравится моя игра”; или в виде излишнего обобщения, например: ”всем известно, что детям неинтересна геометрия и её понимают плохо”
- необходимо избегать субъективных описаний: плохо, мало и т. п.
- в конце указывается способы, которым будет обосновываться проблемное поле: количественные и качественные интервью, для обоих типов указывается примерное число вопросов и объём выборки.
Про количественные исследования можно почитать здесь:
https://habr.com/ru/companies/agima/articles/710042/
Про качественные исследования можно почитать здесь:
https://habr.com/ru/companies/agima/articles/717042/
Заказчик или целевая аудитория
Вы решаете не какую-то абстрактную проблему, а проблему определённой целевой аудитории или заказчика, то есть, конкретных людей (даже если вы с ними лично незнакомы). Для того, чтобы более качественно спроектировать функционал и интерфейс вашего продукта, необходимо хорошо представлять себе, для какой аудитории вы делаете вашу работу.
Требования к разделу:
- выделяем акторов, которые были упомянуты в проблемном поле, и описываем их социальные характеристики с точки зрения того, как они влияют на проблемное поле (например, возраст может влиять на лёгкость использования вашего продукта)
- описываем минимум 2-3 социальные группы
- не используем излишне обобщённые описания, например, “все люди” или “все” подростки, конкретизируйте их по нескольким параметрам
- вместо целевой аудитории может быть заказчик. От заказчика необходимы: техническое задание, печать и подпись. Заказчиками не могут быть родственники или друзья, это должны быть организации. В конце работы над проектом у вас должна быть виза заказчика
Аппаратные и программные требования
В этом не очень большом разделе необходимо указать системные требования к устройству, на котором необходимо тестировать ваш продукт, а также операционную систему и версию браузера (при необходимости). В системных требованиях необходимо указать процессор, объём оперативной памяти, объём жесткого диска или памяти на устройстве для хранения приложения и данных, видеокарту. Также необходимо указать минимальную версию операционной системы, а также название и минимальную версию браузера, достаточные для запуска вашего продукта. Иными словами, необходимо описать компьютер / гаджет, на котором ваш продукт точно должен работать.
Функциональные требования
Не умаляя роль других разделов заявки, можно утверждать, что этот раздел – самый важный, поскольку именно здесь описывается функционал вашего ИТ-продукта. Здесь вы указываете, какие действия ваши приложение или сервис будут позволять совершать пользователю, что он может сделать. Например, в популярных текстовых редакторах можно набирать текст, редактировать текст, удалять и копировать текст, работать с таблицами, изменять цвет шрифта и т. п.
Функциональные требования должны соотноситься с проблемным полем: совокупность тех действий, которые может совершать пользователь, позволит ему решить ту проблему, ради которой он установил ваш ИТ-продукт на своё устройство.
Требования к разделу:
- функциональных требований должно быть минимум 9, причём, работа с аккаунтом: регистрация, вход, напоминание / изменение пароля и изменение параметров аккаунта (фамилия, имя и т. п.) должно быть входить в 1 сценарий;
- каждое функциональное требование должно быть описано тезисно: не нужно подробно расписывать, какие именно шаги будет делать пользователь в рамках исполнения того или иного действия (это вы будете делать потом в пользовательских сценариях);
- в списке требований должна быть сохранение / загрузка состояний среды либо импорт / экспорт значимых данных и статистики. Так, например, если вы пишете игру, то у неё должна быть возможность сохранить и загрузить игровое действие в любой момент. Если это рецепты или инструкции, то должна быть возможность экспорта их в pdf-файл или какой-то ещё формат. Примеры на все случаи жизни привести трудно и конкретные случаи должны обсуждаться в рамках очной консультации;
- среди функциональных требований могут выделяться существенные требования, те, ради которых вы и решили делать ваш проект. Например, если вы заявили приложение, которое помогает подбирать подарки друзьям с помощью нейросети, но в итоге это у вас не реализовано, проект не может быть допущен к защите, поскольку, очевидно, именно это и является главной особенностью продукта, а вы её не реализовали и по сути у вас остался только интерфейс;
- не нужно делать более 12-13 функциональных требований. Если у вас их больше, возможно, какие-то имеет смысл укрупнить и детализировать уже потом на этапе пользовательских сценариев
- все функциональные требования должны быть реализованы в конечном продукте, поэтому к формулировкам необходимо подходить реалистично.
Похожие / аналогичные продукты
Сегодня редко какой продукт создаётся с нуля и, прежде чем выходить на рынок, исполнители исследуют уже имеющиеся решения или продукты, которые решают похожие проблемы, и с учётом полученных данных разрабатывают что-то своё.
Требования к разделу:
- необходимо проанализировать 3-4 похожих или аналогичных продукта
- главное, что необходимо отметить в анализе: что отсутствует в аналогах (или работает не так, как нужно), необходимое для решения проблемы из проблемного поля;
- если вам кажется, что аналогов вашему продукту нет (скорее всего, всё-таки кажется, но мало ли), то укажите, почему проблема не может быть решена стандартными способами (соцсети, офисные пакеты, какие-то имеющиеся онлайн-решения и т. п.)
- если в выбранной вами теме имеется всем известный продукт (например, Word / Google Docs в обработке текста), проанализируйте его тоже
- не нужно писать о сильных сторонах этих продуктов, здесь цель – выявление недостатков проектирования с расчётом на то, что у вас этих недостатков не будет
Инструменты разработки и информация о базе данных
Здесь необходимо указать, какие языки программирования и среды разработки вы будете использовать, а также упомянуть любой другой полезный для вас инструментарий. Отдельно необходимо упомянуть базу данных, которая будет использоваться в вашем проекте. Наличие базы данных является обязательным условием для допуска к защите. Пожалуйста, отдавайте предпочтение табличным базам данных.
Требования к разделу:
- укажите используемые языки программирования. Если ваш выбор не является конвенциональным, объясните, почему вы выбираете именно такой стек технологий;
- укажите среду разработки и любой другой инструментарий (как минимум, можно указать Git/GitHub);
- не забудьте указать базу данных и кратко пояснить, почему вы выбрали именно её.
Если выбранный стек технологий вам пока неизвестен в деталях, пожалуйста, оцените риски его использования и вообще создания ИТ-проекта в целом. Учтите, что вам необходимо знать не только сами языки, но и стиль кода (например, PEP8 для Python).
Этапы разработки
В этом разделе необходимо совместить два вида “контрольных точек”: с одной стороны, какие-то этапы, которые задаёт логика работы над ИВР во всём Лицее, с другой – логика вашей лично работы, этапы, на которые вы её разбиваете.
Так, если говорить про Лицей, то общая рамка ИВР предполагает такие шаги как первоначальная заявка на проект, отчёт о ходе работы над проектом (пользовательские сценарии в ИТ-проектах), окончательная заявка, загрузка итоговых материалов (включая отчёт). В ИТ-проектах есть ещё дополнительные этапы: показ кода №1 и показ кода №2. Обычно показы кода идут после окончательной заявки, но если авторы проекта абсолютно уверены, что они не будут менять концепцию проекта, то показы кода могут быть уже после отчёта о ходе работы над проектом (пользовательские сценарии).
Что же касается ваших внутренних этапов, то тут сложно что-то предугадать и они определяются вашим планированием. Впрочем, можно предположить, что у многих будут такие этапы как проектирование интерфейса, создание фронтенда, создание бэкенда и т. п.
Таким образом, вам необходимо выстроить единую временную линию, на которой будут и лицейские этапы работы, и ваши личные.
Данный раздел должен быть оформлен в виде диаграммы Ганта. Подробнее про эти диаграммы можно почитать здесь:
https://skillbox.ru/media/management/razbiraem-diagrammu-ganta-instrument-kotoryy-dolzhen-znat-kazhdyy-menedzher/
Для каждого шага должны быть определены начало и конец, некоторые задачи вы можете решать параллельно, всё зависит от ваших предпочтений.
В настоящий момент мы не предъявляем каких-либо требований к внешнему виду диаграммы, кроме каких-то общих пожеланий, чтобы диаграмму было легко читать.
Требования к разделу:
- перечислить этапы тезисно, не забыв про внешние (лицейские) шаги;
- в конце списка дать вставить как изображение или дать ссылку на диаграмму Ганта.
Возможные риски
Заполняя данный раздел, вам необходимо оценить, насколько вам под силу будет реализовать ваш замысел. У нас ни в коем случае нет желания отговаривать вас от выполнения ИТ-проекта, но мы предупреждаем, что определённые риски есть. Так, совершенно точно мы не рекомендуем делать ИТ-проект тем, кто только в 10-ом классе приступил к изучению программирования и промышленной разработки. Кроме того, мы просим тщательно оценить риски, связанные с изучением определённого стека технологий: то, что может показаться посильным в начале октября, вполне возможно, окажется чем-то неподъёмным ближе к маю, поскольку помимо работы над ИВР у вас ещё много других задач.
Требования к разделу:
- рисков должно быть минимум 3-5
- необходимо давать детально описание, например, вместо “не хватит времени на проект” имеет смысл написать “не хватит времени на изучение библиотеки PyTorch”
Нашли опечатку?
Выделите её, нажмите Ctrl+Enter и отправьте нам уведомление. Спасибо за участие!
Сервис предназначен только для отправки сообщений об орфографических и пунктуационных ошибках.