Вход – пользовательский интерфейс для ввода параметров распределений.
Выходы – отдельный интерфейс, пользовательский интерфейс аналитика.
Задача: сформировать поток вносимых изменений в заказы с различными распределениями по параметрам.
Вход – пользовательский интерфейс для ввода параметров распределений.
Выходы – отдельный интерфейс, пользовательский интерфейс аналитика.
Задача: сформировать поток отчетов о выполнении единиц заказов с различными распределениями по параметрам (задержка или досрочное выполнение) с учетом наличия материалов.
Входы – пользовательский интерфейс для ввода параметров распределений, записи о наличии материалов в собственной БД, отдельный интерфейс для приема дневных планов на производство.
Выходы – отдельный интерфейс, пользовательский интерфейс аналитика.
Задача: сформировать поток данных о поставке материалов с различными распределениями по параметрам (задержка в поставке, ошибки в номенклатуре поставляемых материалов) в соответствии с заявками от Back office.
Входы – пользовательский интерфейс для ввода параметров распределений, отдельный интерфейс для приема заявок на поставку материалов от Back office.
Выходы – отдельный интерфейс, пользовательский интерфейс аналитика.
Задача: построить наглядные представления зависимости эффективности работы компании (выполняемость заказов, задержки, остатки материалов на производстве, плотность графика производства и т.д.) от распределения параметров отдельных этапов бизнес-процессов. Вывести обобщенные параметры оценки эффективности бизнес модели в целом и эффективности алгоритмов прогнозирования и оптимизации в Back office.
Перечень строящихся зависимостей и методики оценки согласуются с преподавателем.
Выход – пользовательский интерфейс аналитика.
1. Учебная группа разбивается на три команды, которые выбирают (случайным образом или по коллективному согласованию) модули для работы над ними.
2. Каждая команда разрабатывает свой модуль. Общее хранилище данных (например на основе реляционной СУБД) разрабатывает команда модуля Back office и предоставляет доступ к нему остальным командам. Команда модуля имитационного моделирования разрабатывает собственные программные интерфейсы с другими модулями и согласует с их командами использование интерфейсов.
3. Каждая команда выявляет неполноту информации в описании бизнес-процессов и функциональности модуля и интервьюирует преподавателя для получения дополнительной информации. С преподавателем также конкретизируются требования к функциональности и качеству своей части проекта. Все неоговоренные аспекты при сдаче проекта будут трактоваться в пользу преподавателя. Все достигнутые договоренности вносятся в ТЗ команды.
Максимальный балл, который может набрать студент – 100 баллов. Пересчет в оценку за экзамен производится по следующей схеме:
81–100 баллов – отлично,
66–80 баллов – хорошо,
50–65 баллов – удовлетворительно.
Максимальный балл может быть поставлен только в случае сдачи контрольной точки в указанный в таблице срок.
Критерий оценки |
Время выполнения и максимальный начисляемый балл |
|||||
Front office |
Back office |
Имитационное моделирование |
||||
Развернутое ТЗ на свой модуль (включающее детальное описание функциональности и программной архитектуры в виде UML диаграмм) |
2-е занятие |
10 |
2-е занятие |
10 |
2-е занятие |
10 |
Схема данных (физическая модель БД, диаграмма классов или другая форма), согласованная с другими командами (наличие согласия остальных команд обязательно) |
2-е занятие |
10 |
||||
Детальное описание программных интерфейсов с остальными модулями (согласованное с их командами) |
2-е занятие |
10 |
||||
Обоснованные алгоритмы оптимизации формирования производственного плана (с вычислением ближайшей даты возможного выполнения очередного заказа) и формирования плана закупок материалов |
2-е занятие |
10 |
||||
Обоснованные алгоритмы имитации параметров бизнес-процесса; обоснованные формы представления аналитического материала |
2-е занятие |
10 |
||||
Эффективный пользовательский интерфейс (включая необходимые проверки на правильность ввода и обоснование usability) |
4-е занятие |
10 |
||||
Работающий код своего модуля (демонстрация всех необходимых функциональностей, возможно с использование «заглушек» вместо взаимодействия с другими модулями) |
4-е занятие |
30 |
4-е занятие |
30 |
4-е занятие |
30 |
Интеграция с другими модулями. Интеграция считается достигнутой, если реализованы все потоки между двумя модулями в обе стороны (вопрос «Кто виноват в отсутствии связи» не рассматривается). Указанный в таблице максимальный балл соответствует интеграции с двумя модулями (в случае интеграции только с одним модулем максимальный балл уменьшается в два раза) |
6-е занятие |
20 |
6-е занятие |
20 |
6-е занятие |
20 |
Пользовательская документация (охватывает все реализованные функциональности) |
6-е занятие |
10 |
||||
Личный балл каждого участника команды, выставляемый по итогам собеседования с преподавателем после сдачи проекта. Необходимо детально знать код и архитектуру (в том числе используемые алгоритмы) своего модуля. |
8-е занятие или дата экзамена |
20 |
8-е занятие или дата экзамена |
20 |
8-е занятие или дата экзамена |
20 |
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.