Во введении объясняется, почему выбор школьного обеда может быть сложным, если одновременно учитывать стоимость, калорийность, состав и вкусы ученика. Здесь формулируются проблема, цель, задачи и предполагаемый продукт проекта, а также обозначаются границы системы: она помогает сравнивать блюда, но не ставит диагноз и не заменяет рекомендации врача. Отдельно указывается, для кого предназначен прототип и какие данные будут нужны для его создания.

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

Раздел посвящён различию между аллергией и пищевой непереносимостью, а также необходимости точно указывать ингредиенты и возможные следы аллергенов. Объясняется, почему отсутствие сведений о компоненте нельзя трактовать как доказательство его отсутствия. На этой основе определяются правила предупреждений и обработки неизвестных данных, чтобы система не создавала ложное чувство безопасности.

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

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

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

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

Здесь прототип проверяется на нескольких сценариях, например при ограниченном бюджете, исключении определённого ингредиента или выборе любимых блюд. Результаты сравниваются с ручной проверкой каталога, фиксируются ошибки и случаи, когда система должна показать предупреждение вместо рекомендации. По итогам оцениваются точность фильтров, понятность интерфейса и ограничения, которые необходимо устранить перед дальнейшим использованием.

В заключении подводятся итоги разработки и проверки прототипа, соотносятся полученные результаты с поставленными задачами. Указывается, какие критерии система учитывает успешно, какие сведения требуют уточнения и почему проверка состава особенно важна при пищевой аллергии. Также можно предложить направления улучшения: расширение каталога, обновление меню и привлечение специалистов для проверки данных.

В списке приводятся источники, использованные при изучении питания, состава продуктов, аллергенов и разработки алгоритма. Для нормативных документов указываются полное название и номер, для сайтов — название организации, заголовок материала и дата обращения. Источники следует выбирать проверяемые и актуальные; сведения о конкретных блюдах необходимо сверять с данными школьной столовой или изготовителя.