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”

 

Пользовательские сценарии (отчёт о ходе работы над проектом)

Итак, заявка на проект готова, зачёт за неё, будем надеяться, успешно получен, значит, необходимо дальше работать над проектом. Давайте посмотрим, что именно уже сделано с точки зрения ИТ-проектирования. Если коротко, мы описали проблемное поле, требующее какого-то software-решения, и указали, что именно будет делать пользователь нашего продукта для того, чтобы решить свою проблему. Можно ли уже, говоря по-простому, приступать кодить? Пожалуй, всё-таки рановато.

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

 

            Пример 1 – Аутентификация пользователя на сайте / в приложении

            Вряд ли нужно объяснять, что такое аутентификация, и есть готовые решения, которые позволят нам наладить этот процесс довольно быстро, но даже с учётом этого нам необходимо ответить на несколько вопросов, которые мы задаём самим себе исходя из функционала, который мы прописали в заявке, рисков и условий работы в целом. Например, нужна ли нам двухфакторная аутентификация? С одной стороны, есть некий минимальный уровень безопасности, который должны обеспечивать все сайты и приложения, с другой стороны – вряд ли сайт, где вы читаете новости, должен быть так же защищён, как и банковское приложение или сайт Госуслуги. Таким образом, выбор – за вами, но, если в вашем продукте должна быть 2FA, вы должны это предусмотреть и в какой-то момент “запрограммировать” прохождение аутентификации пользователем. Вы должны чётко знать, в какой момент что именно вводит ваш пользователь, чтобы предусмотреть это в своём коде (подробнее об этом можно прочитать тут: https://skillbox.ru/media/code/identifikatsiya-autentifikatsiya-avtorizatsiya-chem-oni-razlichayutsya/).
 

            Пример 2 – Разграничение прав доступа

            Допустим, в вашем продукте предусмотрено оставление отзывов или комментариев или коротких заметок. Подобный функционал требует хотя бы базовой модерации для того, чтобы, например, удалять оскорбительные комментарии или комментарии, подпадающие под действие УК РФ. Должен ли обладать правами модерации любой пользователь? Очевидно, что нет. Вряд ли будет правильно, если у каждого пользователя будет возможность удалить любой комментарий любого другого пользователя. Здравый смысл подсказывает, что такие права должны быть только у администратора ресурса. Но и тут есть интересные моменты, которые стоит обдумать: должна ли быть у пользователей возможность отправить жалобу администратору? Должны ли у администратора быть возможности выбирать себе помощников, назначать некоторых пользователей модераторами и давать им права удалять комментарии? А, может, прав удалять комментарии вообще не должно быть, только редактирование? А что если комментарий наберёт 300 дизлайков и тогда он удалится автоматически (допустим, один человек может быть предвзят к другому, но, может, 300 человек – это уже не просто предвзятость, а явный сигнал тревоги?)? А если эти 300 дизлайков – накрутка ботов, как быть? Как видите, вопросы можно задавать до бесконечности и когда-то надо остановиться, но остаётся фактом в каком-то смысле очевидная вещь, что если мы что-то хотим реализовать в нашем приложении, это сначала должно быть спроектировано.  

 

            Пример 3 – рисование таблицы в текстовом редакторе

            Этот пример можно часто услышать на НИПСах, но он довольно показательный. Итак, мы пишем текстовый редактор и решили добавить функционал рисования таблиц. Как это будет происходить? Нам необходимо понимать, из каких шагов будет состоять действие пользователя. Необходимо выбрать какой-то пункт меню или нажать на какую-то иконку, далее каким-то способом указать, сколько мы хотим строк и столбцов, после этого приступить к заполнению таблицы (вручную, скорее всего, но, может, дать возможность считывать сразу из файла? А каких форматов?). Опять начались вопросы, но это важные вопросы. Навскидку, можно процесс описать так: пользователь выбирает в главном меню пункт “Таблицы”, затем выбирает пункт “Вставить”, вводит количество строк и столбцов, выбирает возможность выбрать ширину столбцов, возможность проинициализировать ячейки таблицы каким-то значением (или отказывается от этих возможностей) и, нажимая кнопку “Ок” или “Вставить таблицу”, вставляет таблицу в документ. Примерно так происходит вставка таблицы в известном редакторе Microsoft Word.

            Разберём этот пример поподробнее. Главное, что нужно в нём увидеть – то, что описание поведение пользователя в продукте реализуется по шаблону “актор + глагол”. Под актором мы понимаем того, кто совершает действие, выраженное глаголом. Почти всегда (но не всегда!) таким автором является пользователь, который совершает какое-то действие: что-то нажимает, что-то выбирает, что-то вводит. Иногда бывает так, что в ответ на действие пользователя продукт реагирует тем или иным образом, например, “система просит ввести пароль ещё раз, информируя о количестве оставшихся попыток, если пароль введён неверно”, “система информирует пользователя, что в течение 24 часов он лишается возможности зайти под своим логином, поскольку количество попыток ввести верный пароль превысило заданный лимит”. Здесь, мы видим, ответное действие осуществляет система, но в любом случае это описывается в формате “актор + глагол”.  

            Пользовательским сценарием мы будем называть последовательность действий, описанных в формате “актор + глагол”, которая позволяет реализовать определённое функциональное требование. Упоминание функциональных требований неслучайно: дело в том, что каждое функциональное требование должно быть развёрнуто в пользовательском сценарии. А иначе, зачем бы мы его тогда выдвигали в нашей заявке? 

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

 

Требования к пользовательским сценариям:

• каждому функциональному требованию в заявке на проект должен соответствовать минимум один пользовательский сценарий, таким образом, пользовательских сценариев должно быть минимум 9;
• каждый пользовательский сценарий должен начинаться по шаблону “актор + глагол”;
• в отличие от функциональных требований, каждый шаг сценария – это законченное предложение, но не стоит его делать слишком длинным и не стоит формулировать один шаг в нескольких предложениях (см. образец на GitHub)
• каждый сценарий должен состоять из 7-9 шагов минимум. Меньшее число шагов свидетельствует о недостаточной проработке сценариев, если же шагов больше 7-9, то это даёт повод задуматься либо о том, что некоторые этапы сценария слишком детализированы, либо о том, что один большой сценарий необходимо разбивать на два отдельных поменьше;
• в каждом сценарии должны быть описаны шаги, имеющие отношение к конкретному функционалу, не нужно начинать сценарии с действий типа “пользователь включает компьютер”, “пользователь запускает приложение”
  и т. п.;
• в сценариях необходимо предусмотреть реакцию системы на тот случай, если “что-то пойдёт не так”, например, если в компьютерной игре пользователь пытается купить оружие, на которое у него не хватает монет, ему необходимо сообщить об этом (альтернативным решением является показать игроку то, что он может купить за имеющиеся у него средства, но тогда в сценарии покупки это тоже необходимо отразить, например, “система выводит список товаров, которые пользователь может приобрести за имеющиеся у него средства”;
• к названию файла с пользовательскими сценариями и его визуальному оформлению предъявляются определённые требования, понять которые можно, ознакомившись с образцом:

https://github.com/aakuptsov/test_repo/blob/master/akuptsov_userscripts.md