Анализ аналогов и прототипов
Аналог (от др.-греч. ἀνάλογος — соответственный, соразмерный) — объект (техническое решение) того же назначения, близкий по совокупности существенных признаков. Часто используется совместно с понятием прототип.
При проектировании информационной системы «Дефектоскопии рельсов» использовалась глобальная сеть Internet. В результате поиска не было найдено прототипов, так как дефектоскописты записывают результаты сканирования в таблицу Excel (Источник: сайт ABI Soft.ru.).
По отметкам можно строить различные отчеты с сохранением в формате Excel или HTML. На рис.1.1 представлен отчет о дефектах.
Рисунок 1.1 – Отчет по не проконтролированным участкам
На рис.1.2 представлен отчет о ширине стыков зазоров.
Рисунок 1.2 – Отчет по распознанным ширинам стыковых зазоров (с соответствующими изображениями стыков)
В результате поиска был найден аналог дефектоскопии колес. Результаты, которого записаны в таблице представлены на рис 1.3 источник: Refleader.ru.
Рисунок 1.3 –Анализ дефектов по классификации неисправностей колёсных пар
Этот аналог позволяет найти дефект детали и исправить её.
Дефектоскопия играет важную роль в нашем времени, потому что позволяет выявить дефекты в деталях и с помощью этого избежать катастроф.
Поэтому выбранная тема является актуальной.
Требования к по
Для разработки приложения необходимо перечислить функциональные и нефункциональные требования (характеристики).
Функциональные требования. Это перечень сервисов, которые должна выполнять система, причем должно быть указано, как система реагирует на те или иные входные данные, как она ведет себя в определенных ситуациях и т.д. В некоторых случаях указывается, что система не должна делать.
Нефункциональные требования. Описывают характеристики системы и ее окружения, а не поведение системы. Здесь также может быть приведен перечень ограничений, накладываемых на действия и функции, выполняемые системой. Они включают временные ограничения, ограничения на процесс разработки системы, стандарты и тд.
В действительности четкой границы между этими типами требований не существует. Например, пользовательские требования, касающиеся безопасности системы, можно отнести к нефункциональным. Однако при более детальном рассмотрении такое требование можно отнести к функциональным, поскольку оно порождает необходимость включения в систему средства авторизации пользователя. Поэтому, рассматривая далее эти виды требований, мы должны всегда помнить, что данная классификация в значительной степени искусственна.
Главная цель разработки приложения, облегчить и ускорить для персонала процесс заполнения данных об обнаруженных дефектах на участке дороги, а для администратора облегчить просмотр информации об дефектах на участке, а так же занесение информации об возможных дефектах и формирования подразделений.
В этой системе могут быть пользователями администратор, персонал. Для них описаны свой функциональные и нефункциональные требования.
Функции реализованные для администратора:
проходить аутентификацию;
принимать поступление новых дефектоскопов;
вести учёт дефектоскопов;
проводить регистрацию новых сотрудников;
Функции выполняемые персоналом:
просматривать информацию о дефектоскопии;
просматривать информацию о дефектах.
Задачей разрабатываемого приложения является создание простого и удобного инструмента для работы одного пользователя на запись данных и до десяти на чтение одновременно.
Полностью требования заказчика изложены в техническом задании (ПРИЛОЖЕНИЕ А).