Gustaf,
Практика, замечу, бывает очень разная. Если в своей "практике" вам не доводилось программировать\поддерживать системы реализующие описанный функционал, то это не означает что таких систем не существуют в природе. Не расстраивайтесь, все бывает когда-то в первый раз ... ну или не бывает вообще
не надо так петросянить. Давайте лучше пройдемся по вашему мегасовету с точки зрения заказчика, не знакомого с програмированием:
Попробуйте подойти системно и в своей предметной области для себя глобально выделить (нарисовать на бумаге):
- объекты автоматизации
- их характеристики (свойства)
- требуемые действия над объектами автоматизации
переведите эти три пункта на язык человека, никогда не сталкивавшегося с программированием. Что например такое- обьекты автоматизации? Это компьютер? Это бухгалтер Машенька? Это журнал учета? Это магазин?
Какие есть характеристики у Маши? У магазина? У журнала учета? Ну Машины характеристики то понятны, и требуемые действия над ней тоже, если с характеристиками все в норме. А если это старая 60-летняя МарьяИванновна? Где взять на нее характеристики? В отделе кадров?
Как выглядят "требуемые действия" над журналом учета? Достать с полки, положить на полку?
- требуемые выходные формы\отчеты после выполненных действий над объектами
выходные отчеты после действия "закрыть" над обьектом "магазин" какие? Поставить на сигнализацию? Но мы пока не хотим заходить так далеко...
Дальше определите:
- количество пользователей\ролей в вашей системе
Что еще за роли? У нас не театр, у нас работают...
- необходимость в сетевом доступе к БД ПО (через локальную сеть, через интернет и т.п.)
Не блин, к бд сетевого дотупа не надо, будем использовать голубиную почту. И вообще у нас вайфай, так что никаких сетей.
- необходимость в авторизованном доступе к БД (через логин и пароль)
еще раз - у нас вайфай, поэтому доступ надо сделать не через логин и пароль, а через вайфай
- объем операций\сделок\транзакций в день
ну, обьемы у нас в литрах, транзакции у нас в банке, а сделки бывают разные, тут как повезет. Что определять?
- необходимость функции поиска в системе
да, обязательно. У нас бухгалтер в том году сбежал, надо бы его поискать.
- необходимость ведения историчности данных
историчности или истеричности? Первое не надо, у нас не музей, со вторым хорошо справляется наш главбух
- необходимость протоколирования действий пользователей системы
вы точно программист? А можно как нибудь без протоколов обойтись? Чтобы как только протокол достали, данные взяли и пропали..
- необходимость разграничения по ролям право на выполнение определенных операций\просмотр данных
разграничить чего куда зачем?
Если в своей "практике" вам не доводилось программировать\поддерживать системы реализующие описанный функционал, то это не означает что таких систем не существуют в природе.
такие системы существуют. Точнее не существует систем, в той или иной мере не поддерживающих "описанный функционал". Уж точно "обьекты" с "характеристиками" есть наверное везде.
Просто ваш совет выглядет так - главное описать сферического коня в ваккуме, а уж потом как нибудь до реальность доведем.
Только, наверное, наш программист ( и швец, и жрец и на дуде игрец) знает лучше заказчика "что именно ему надо" (а не наоборот) и будет его учить как именно ему вести свой учет. 5 баллов!
Не поверите, но это именно так. Заказчик мыслит категориями предметной области, причем категориями во многом неформализванными. А ваша задача - все разложить по полкам, убрать неоднозначности, и даже предвидеть будущие запросы. Если опыта нет - все это придется делать уже в процессе разработки, а не до. С переделками, с поломками, с багами.
происходит с перетряхиванием всех задействованных компьютеров, с установкой какого нибудь жудкого софта типа "эмуляция 640 кб оперативной памяти". Поддержка девайсов типа сканеров - на уровне "а оно вам надо за такие деньги"?
