IT

 

Добро пожаловать на страницу ИТ-проектов в Лицее НИУ ВШЭ!

Здесь можно узнать, что является ИТ-проектом, как оформить сопроводительную документацию и как подготовиться к защите ИВР. Создание ИТ-проекта – это большая и интересная работа, в ходе которой вы приобретёте много полезных навыков и сможете пополнить ваше портфолио.

 

Что является ИТ-проектом

ИТ-проектом является деятельность, направленная на создание ИТ-продукта в рамках выполнения индивидуальной выпускной работы. Это значит, что в процессе работы над вашим проектом вы создадите ИТ-продукт, исходя из требований, предъявляемых к работе над ИВР в Лицее НИУ ВШЭ. Конечно, это определение вряд ли можно назвать строгим с точки зрения индустрии, но оно отражает главные особенности работы над ИТ-проектом. Более подробно о том, что такое проект и продукт, можно прочесть здесь:

https://habr.com/ru/companies/kuper/articles/667266/

Опишем различные свойства и характеристики ИТ-продуктов. Говоря об этом, мы, конечно, имеем в виду контекст индивидуальной выпускной работы, а не какие-то универсальные качества.

 

Что может быть ИТ-продуктом

 

• мобильное приложение
• веб-сервис
• десктопное приложение

 

Общие свойства ИТ-продуктов:

 

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

 

Что не может быть ИТ-продуктом

На самом деле, довольно трудно дать исчерпывающий перечень типов ИТ-продуктов, которые не могут быть допущены к защите в качестве ИВР. Если ваш проект не попадает в список того, что не может быть одобрено, это не значит, что он автоматически дойдёт до защиты. Все сомнительные случаи необходимо обсуждать в ходе индивидуальной консультации. И, конечно, необходимо отметить, что сами по себе эти вещи не являются “плохими”: это прекрасные и нужные сервисы, просто их создание не позволяет в полной мере развить те навыки, которые мы можно получить, создавая более сложные продукты.

 

Итак, к защите не допускаются:

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

 

Примеры названий успешных ИТ-проектов (набор 2023 года):

1. HelpForMum (Анастасия Зубаревич, 11И3) – мобильное приложение (iOS) для молодых мам, позволяющее вести пищевой дневник и справляться с проблемами аллергии у детей (27 баллов);
    
2. EcoTrace (Архип Глинов, 11И2) – мобильное приложение (Android), объединяющее экологических энтузиастов – 29 баллов
    
3. 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”