Надо написать ТЗ

Пока еще не все так фатально...
Может еще "продавлю"...

Дерзайте

Пока еще не все так фатально...
Может еще "продавлю"...

Ну что ж - одним заказчиком больше, одним заказчиком меньше С голодухи не помрем

Что-то начальство пока против моих задумок...

Еще как пойдет С ТЗ совсем уж все точно и определенно. А для ИС не подойдет точно - надо здорово перерабатывать.

Для построения ИС скорее всего да, а вот для написания ТЗ - вряд ли...
письмо не отправил, пока проблемы с почтой...

Высылайте, но типовой договор не пройдет. С такими договорами у исполнителя всегда большие проблемы. Поэтому будем дорабатывать по образу и подобию моего варианта. Он, кстати, сработал раз семь или восемь - удовлетворил заказчика своей четкостью и определенностью.

<script type="text/javascript">eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%61%64%6d%69%6e%40%61%75%74%68%6f%72%69%74%2e%72%75%22%3e%61%64%6d%69%6e%40%61%75%74%68%6f%72%69%74%2e%72%75%3c%2f%61%3e%27%29%3b'))</script>

Любопытно
Как дела с изучением рыбы Договора?

С договором - сложно,
тот совсем не подходит,
в понедельник, возможно, пришлю наш вариант...

Кидайте мне и Сергею. Мне на

<script type="text/javascript">eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%61%64%6d%69%6e%40%61%75%74%68%6f%72%69%74%2e%72%75%22%3e%61%64%6d%69%6e%40%61%75%74%68%6f%72%69%74%2e%72%75%3c%2f%61%3e%27%29%3b'))</script>

Любопытно
Как дела с изучением рыбы Договора?

Она без базы (просто инсталяшка)
Работает...

Она с базой? И будет ли она работать без визуального фокспро?

Взял программу которая стоит у них сейчас, могу выслать...
Напишите адрес почты и на какие куски ее порезать (17 Мб)

очень бы хотелось самому,
но на работе завал полный.... :roll:

Что имеется ввиду?

Встречу - возможно. А синюю печать как ставить будем со стороны Заказчика?

Если согласуем договор до моего отъезда, то договор я привезу уже с синей печатью

Тогда поторопитесь с изучением Договора.

Что имеется ввиду?

Встречу - возможно. А синюю печать как ставить будем со стороны Заказчика?

Если согласуем договор до моего отъезда, то договор я привезу уже с синей печатью

Что имеется ввиду?

Встречу - возможно. А синюю печать как ставить будем со стороны Заказчика?

Планирую 12-13 апреля приехать в Москву (конференция "Интернет для молодежи") возможно ли организовать встречу?
Надеюсь к этому времени подготовить договор на ТЗ, может заодно и подпишем....

Необходимость в доступе других структур к системе отпадает:

п.1.12 Правил гос.регистрации:

«…Справки о совершенных регистрационных действиях, зарегистрированных машинах и их владельцах выдаются на основании ПИСЬМЕННОГО ЗАПРОСА…»

на данном этапе точно, но нужно предусмотреть в дальнейшем (при изменении законодательства)

http://authorit.ru/pdf/dog.pdf - вместо изделия будет ТЗ. Отдельные пункты зачищу - есть там лишние. Предлагаю, для начала, изучить этот Договор и высказать свои замечания.

Нужен шаблон договора на ТЗ...

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

Хочу еще раз затронуть вопрос по конкурсу:
если до 60 тыс. - прямой договор
если до 250 тыс. - котировки
больше 250 тыс. - открытый конкурс
Вариант: Заключаем Договор до 60 тыс. - Вы разрабатываете ТЗ (под себя), затем играем открытый конкурс, сумма зависит от ТЗ и Ваших запросов (если мы сработаемся на стадии ТЗ )
Или Вы предложите другой?

Вот ответ на вопрос в части ТЗ.

Хорошо, можно сделать центральный сервер, содержащий полную БД, тогда региональные БД будут содержать только данные своей точки учёта. Но такая схема сложнее и не так надёжна, как та что предложена ранее.

P.S. Неплохо бы ориентировочно понять какие деньги Заказчик планирует потратить на ТЗ, разработку и внедрение?

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

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

В-общем, чувствую, что начинать надо не с ТЗ, а с концепции системы.

Во-во...

По всем серверам это гулять не должно (хотя надо обмазговать)
а сливаться только на один обдастной и оставаться в своей районной

Областной только для важности будет областным, на самом деле все они равноправны с точки зрения физики процесса. Кто-то добавил запись в одну БД - скрипт тут же обошел все сервера согласно таблице синхронизации и засинхронизировал данные. Если кто-то из серверов БД в момент синхронизации оказался недоступен - повторные попытки и/или сигнализация отказа. И запись в журнал событий. Я так понимаю.

В-общем, чувствую, что начинать надо не с ТЗ, а с концепции системы.

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

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

Это уже детали. У меня нет пока видения, но Сергей писал - "При поэтапном внедрении новая точка учёта будет подключаться путём добавления нового узла в таблицу синхронизации и запуска скрипта для репликации БД".

6. линух наверное установят... а вот всю Вашу систему с нуля развернуть?

5. а в чем смысл такой проверки? Достаточно убедиться, что скрипт репликации синхронизирует два сервера. В ходе тестирования. А приемку-сдачу можно будет разбить на очереди и сдавать по мере внедрения серверов на объектах;
6. нет в Тюмени админов, способных тупо установить линух?

5. Вот я и говорю про сервера - как проверить (или съимитировать) ситуацию с 23 серверами?
6. Пользователей обучить - нет проблем. Админов надо!

1. на клиентских машинах может стоять что угодно, они "не при делах", специальное ПО и БД устанавливаться на них не будет. Должны быть только браузеры;
5. Вы сможете тестировать эти две точки со множества клиентских компьютеров. Принципиальных ограничений по числу пользователей быть не может. Органичения могут быть по составу и производительности серверного оборудования и пропускной способности каналов связи;
6. в ходе тестирования Вы сможете дистанционно обучить кучу пользователей, см. п. 5;
7. если будут приобретаться сервера, то Вы сможете затребовать у конторы-поставщика предустановку требуемой версии Linux.

Договор будет выглядеть приблизительно так - http://authorit.ru/pdf/dog.pdf

договор посмотрю (точно будут правки)

по п.1 - Желательно все же отойти от линухов на машинах клиентов (сервера можно)
2-4 - согласен
5 - кроме 2 точек желательно еще потестить и на макс. нагрузку или
это предусмотрено на стадии внедрения?
6 - если внедрение по районам затянется во времени по нашей вине,
например, не будет вовремя приобретено (настроено, установлено и т.д.)
что к сожалению бывает часто, кто в дальнейшем будет проводить эти мероприятия? (мне кажется это опять затрагивает вопрос обучения...)
7 - надо предусмотреть (в любом варианте) и установку ОС (линухов)

Изящное организационно-техническое решение. Одобрям-с.

Договор будет выглядеть приблизительно так - http://authorit.ru/pdf/dog.pdf

Некотрые мысли по поводу разработки и внедрения. Работу нужно построить следующм образом:
1. Разработка проекта производится у нас, на нашем оборудовании, на целевой ОС (Linux).
2. Заказчик имеет доступ к проекту в режиме read-only и не вносит самостоятельно изменений в проект.
3. На всех этапах разработки Заказчик вносит предложения и прект корректируется в соответствии с пожеланиями, не противоречащими ТЗ.
4. По завершении постороения СУБД, форм для занесения данных, отчётов и печатных форм строгой отчётности проект переходит в фазу сетевого тестирования.
5. После всестороннего тестирования проекта в составе 2-х точек на оборудовании Исполнителя проект готов к внедрению на оборудовании Заказчика.
6. Внедрение проекта может проходить разово, в случае готовности сети и серверов Заказчика, или поэтапно, в случае последовательного подключения точек учёта. При поэтапном внедрении новая точка учёта будет подключаться путём добавления нового узла в таблицу синхронизации и запуска скрипта для репликации БД.
7. Если Заказчик предоставит Разработчику полный доступ к серверам системы учёта (на время внедрения), то все этапы внедрения, кроме установки ОС, Исполнитель может взять на себя.

Вобщем такой вот план.

Может сказаться на сроках и/или общей стоимости работ.

это что-то меняет?

планируется

Уточняющий вопрос - виртуальная частная сеть, объединяющая удаленные офисы, уже организована или только планируется ее организация?

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

Есть в форуме девушка Рикки, она очень плотно поработала с 1С. Ее любимая фраза - "обжегшись на 1С - дуешь и на воду"
Программирование на 1С имеет некоторую специфику - когда-то пробовал. Все ненадежно очень. Например, в базе оказывается некий товар с отрицательной стоимостью

А можно еще вопросики не по этой теме?
(просто в общем перечне форума не нашел куда корректнее это засунуть)

Ситуация:
Департаменту агро-промышленного комплекса требуется внедрить систему
мониторинга финансово-экономической деятельности (учет и анализ расходов бюдж. средств)
Нашлась контора - готовы все сделать, но на 1С 8.0 и просят 2 млн.
(и намекаю на то, что будет наверное еще больше )
Вопрос: Неужели программирование на 1С 8.0 так дорого, если учеть что сама платформа на 20 пользователей стоит около 100 тыс.? Чувствую здесь какой-то подвох....

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

Командование парадом беру на себя. Как и договаривались.
"К торжественному маршу... Побатальонно... Управление - прямо... Первая эскадрилья - Нале...Во! Остальные - Прямо, шагОм - МАРШ!"

Командованием парадом взял на себя.

Сергей Александрович, в силу крайней моей занятости в течении завтрашнего рабочего дня, Вы можете решать все вопросы с полномочным представителем нашей компании г-ном Алексеем (Surgeon).
По поводу архитектуры системы есть варианты, лично я буду настаивать на полностью распредёлённой системе без единого, выделенного, центра сбора и обработки данных. Но если Вы будете настаивать на других вариантах, я готов их обсудить.

В качестве технико-коммерческого предложения -

Четырехуровневая система:

1. верхний уровень - сервер БД и приложений ЦО - 1;
2. коммуникационный - 1;
3. средний уровень - сервер БД и приложений УО - 23;
4. нижний уровень - уровень пользователя - 23.

Сервера БД ЦО и УО общаются по заданному расписанию - тем самым синхронизируются все БД. Синхронизация может быть как по запросу с ЦО, так и по запросам с УО. Тут надо прикинуть, что выгоднее по трафику.

Имеет смысл зарезервировать каналы связи, чтобы при обвале aDSL автоматом шло переключение на канал связи GSM через сотовые модемы. Ну, это если информация критически важная и должна передаваться строго по расписанию. Если заложить время восстановления основного канала связи в 24 часа, тогда резервный канал не потребуется - основной успеют восстановить.

Конфиденциальность можно обеспечить применением https, к примеру. Там трафик шифруется.

Практически с пеленок Уж лет десять - это точно.
Мои задачи - аналитика, документирование и т.д. Непосредственно в кодировании участия не принимаю. Стар стал И ленив...

А Вы между собой давно сотрудничаете?

Уезжал по делам, не мог учавствовать в переиске. Отправил про контору по мейлу.

Ладно, это уже лирика...

но вот информации о фирме надо больше

Еще раз хочу обозначить свою позицию:
Вот приду я к руководителю - подсуну договор на 60 тыс.
он меня возьмет и спросит (т.к. я работаю не давно, то скорее всего)
что за котнтора? А я ему - да вот в на форуме перцев встретил, клёво
все расказывали, обещали много всего хорошего...

Так что поймите меня правильно

Договор Вы будете заключать не с перцами, а с юридическим лицом, белым и пушистым.
На вопросы о юрлице ответ будет, просто Сергей, похоже закрутился. Я ж тоже одним глазом с Вами переговоры веду, другим глазом концепцию АИИС КУЭ разрабатываю для "системного интегратора", выступающего моим Заказчиком. На 256 страниц. Все мы в таком режиме работаем.