создать систему для отслеживания дат предстоящего технического обслуживания спецтехники на предприятии, управление и планирование состояния техники на определенную дату

[MI2]

Добрый день!
Заранее выражаю благодарность за внимание к теме и буду признательна за помощь.

Задача - создать систему для отслеживания дат предстоящего технического обслуживания спецтехники
на предприятии, управление и планирование состояния техники на определенную дату.
Имеем объекты: "машина", "двигатель машины", "календарь сроков обсуживания (ТО)", "пользователь".
К машине типа N подходит двигатель только типа K.
Для машины существует свой календарь сроков ТО, т.е на таком-то часу наработки необходимо проверить и/или заменить такие то детали.
Для двигателя существует тоже свой календарь проверок.
Ну и при наступлении даты следующего ТО, заблаговременно нужно оповестить пользователя.

Одно из главных требований к системе - создание гибких настроечных механизмов, для того, чтобы пользователи самостоятельно (без участия разработчиков):
- добавляли новые типы машин, двигателей,
- к каждому новому типу двигателя и машины создавали свой календарь.

Сложность в том, что границ при добавлении машин нет: может понадобиться добавить тип машины с двумя двигателями. Перечень всевозможного оборудования (атрибуты объектов) для каждого типа машины и двигателя уникальный. И календари уникальные (методы их обработки, алгоритмы расчета), форматы для атрибутов тоже уникальные (серийный номер у одной машины - 5 символов, а у другой - 16).

При этом у разработчиков не наблюдаю возникновения вопросов в реализации такой системы, то есть они утверждают, что требование это мы сможем обеспечить без проблем. У меня же - непонимание как это будет работать для пользователя. Что будет для него со стороны админки, и как будут задаваться, например, новые форматы атрибутов, которые мы сейчас не закладываем?
Я права в том, что при такой структуре данных, пользователи самостоятельно не смогут управляться с добавлением новых типов объектов ?
А если не права, кто нибудь может подсказать мне как это будет выглядеть на деле ?

[ViktorR]

Сам сложных систем не писал.
Сталкивался с разработкой системы для гаража.
На авто есть карточка. В карточке поля на все основные параметры, которые характеризуют авто: расход топлива (добавка на зима/лето, на наличие кондиционера, на движение за городом и в городской черте, ...), износ шин (шины на лето/ на зиму), ремонт (привязка к карточке авто карточек на закупленное оборудование, ...), привязка двигателя, дата ввода в эксплуатацию, график обслуживания, кто водители, ...
Важно, что в этой системе существуют роли, которым позволено выполнять только определённые функции (руководитель, механик, диспетчер, ...).
Какую то часть данных вводят одни люди, а какую то - другие: показания спидометров, какая марка топлива, сколько и каким образом приобретено, ...
Система завязана на кадровый учёт, складской учёт и бухгалтерию, при желании руководитель организации тоже может получать какие то отчёты.
Собственно как понимаю, вас волнует вопрос "Смогут ли пользователи самостоятельно добавлять новые типы объектов?"
А в чём может быть их новизна?
В наименовании? В наличии каких то важных на ваш взгляд (или чей то другой) атрибутов, которых нет в существующей системе учёта?
В общем случае есть стандартные утверждённые формы учёта. Если необходимо в них вносить изменения, то это прерогатива определённого круга лиц. Возможно, что в таком случае потребуется вносить изменения в ПО.
При внесении изменений необходимо помнить об архиве учётных данных. Должна быть временнAя привязка.
При просмотре прошлых данных открываются формы учёта, которые действовали на тот период. Надо будет отдельно хранить формы документов.
Мне думается, что существенных ограничений не будет, если систему создаст не Вася Пупкин, а известная организация, которая, к тому же будет выполнять тех. сопровождение, ...

PS: Система Гараж разработана на 1С-Предприятие и работает в достаточно крупной по меркам нашей страны организации и её подразделениях ...

[MI2]

А в чём может быть их новизна? В наличии каких то важных на ваш взгляд (или чей то другой) атрибутов, которых нет в существующей системе учёта?<<

Да, в наличии части уникальных атрибутов, которые будут характеризовать новый объект и в формате этих атрибутов. Легче на примере, уже сейчас есть две машины:
У 1-ой машины - 38 деталей с ограниченным сроком службы, 3 из которых одинаковые в названии (но с разными партами). Какую то нужно проверить на 5 КМ наработки, какую то на 35 ЧАСАХ наработки, а третью на 5 км или 35 часах (что наступит ранее). Серийный номер состоит из 5 цифр + 1латиница.
У 2-ой машины совершенно другой комплект деталей, со своим графиками. Серийный номер состоит из 4 цифр. Это все мы создадим в системе сразу.

Наступает завтра и пользователь (ролевая модель предусматривается) добавляет 3-ю машину и соответственно тип двигателя:
График проверки для одной из деталейдвигателя измеряется в количестве ЗАПУСКОВ. А запуски-то мы сейчас не предусмотрели. Плюс у этой машины еще появляется регистрационный номер состоящий из 15 цифр.

Как пользователь самостоятельно добавит атрибут "рег. номер" ? Как укажет обязательность регист. номера для этого типа машины ? Как задаст допустимый формат для рег. номера? Ведь, если не задаст, не удастся реализовать проверку на корректность введенного регистр. номера при добавлении единицы объекта.
А как добавит такой параметр для атрибута движка как "количество запусков"? КАК и при помощи каких механизмов в интерефейсе сделает это пользователь - вот тут я совсем не понимаю.

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

Буду премного благодарна, если у вас есть ответы на эти вопосы и Вы немного на пальцах еще раз мне объясните. Похоже, что в моей голове схема как то усложнилась, чем есть в реалиях.

[MI2]

Если я правильно понимаю, дляграфика проверок нужно задать все возможные классификаторы:

- часы наработки
- количество запусков
- пройденный километраж
- все конфигурации "или-или"

но вот если появится деталь со сроком годности, то тут уже потребуется разработчик. Потому что дата ТО будет расчитываться по формуле которой в системе нет (текущая дата минус дата выпуска детали).

а формат для рег. номера не задавать, и не реализовывать проверку на наличие ошибок при вводе.


Все верно ?

[taras-proger77]

Сообщение от MI2

Сложность в том, что границ при добавлении машин нет: может понадобиться добавить тип машины с двумя двигателями.

И что? У Мрии их только маршевых 6.

Сообщение от MI2

Я права в том, что при такой структуре данных, пользователи самостоятельно не смогут управляться с добавлением новых типов объектов ?

С какого перепугу?

[MI2]

Сообщение от taras-proger77

С какого перепугу?

а объяснить можете как они добавят сам новый параметр для вычисления срока ТО?

[Аватар]

У меня же - непонимание как это будет работать для пользователя.

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

[taras-proger77]

А зачем им добавлять параметр? Добавить надо объект и связать его с другим объектом. Есть объект «машина», есть объект «левый двигатель», есть объект «правый двигатель», добавляем все три объекта, каждому указываем тип и связываем их. А в каждом типе уже есть все нужные параметры, вводим их значения, некоторые параметры объектов типа «МАШИНА» указывают на пользователя. Как подошёл срок на любой из двигателей, пользователь оповещается. Если посреди срока левый двигатель встал из-за бракованной детали и был целиком заменён, то в базу заносится время его замены, оповещение на правый двигатель придёт по плану, а на левый – через полтора срока. Двигатели могут быть разными. Например, на самолёте два двигателя маршевые, а три мотор-колеса для руления, у них в принципе разные регламентные сроки. Или на судне один двигатель – подруливающего устройства, один – рулевой, два двигателя азиподов и два первичных двигателя силовой установки. Проблема будет, если вдруг неожиданно окажется, что кроме двигателей надо добавлять сами насосы, генераторы и прочие агрегаты, а обозвать их машинами будет нельзя, потому что машина – это весь БЕЛАЗ.

[taras-proger77]

Сообщение от Аватар

Гибкая и мощная система регламентов обычно сводится к тому, что настраивать её может только разработчик.

Гибкая система как раз тем и отличается, что настраивать её не может только разработчк. Иначе она не гибкая. Тем более если её может настраивать только разработчик.

[MI2]

Сообщение от Аватар

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

Пользователи будут не такие) именно поэтому меня и волнует этот вопрос. Им инструкцию нужно мощную писать, и интерфейс должен быть интуитивнопонятный.

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