• A
  • A
  • A
  • АБВ
  • АБВ
  • АБВ
  • А
  • А
  • А
  • А
  • А
Обычная версия сайта

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”

 

Нашли опечатку?
Выделите её, нажмите Ctrl+Enter и отправьте нам уведомление. Спасибо за участие!
Сервис предназначен только для отправки сообщений об орфографических и пунктуационных ошибках.