Воспользуюсь услугами разработчика.

[ritminform]

Самому некогда заниматься, поэтому готов заплатить...

 

 

Задача:

 

Написать кроссплотформенную программу для просмотра и редактирования таблицы до 100 млн. записей.

 

Программа должна поддерживать не менее, чем 5 наиболее распространенных СУБД по выбору разработчика, в т.ч. MS SQL и MySQL.

 

Язык программирования - по выбору разработчика.

 

Структура таблицы:

ном 1 КОД - строка 12 символов (идентификатор)

ном 2 ИНН - строка 12 символов

ном 3 ФАМИЛИЯ - строка 1000 символов

ном 4 ИМЯ - строка 1000 символов

ном 5 ОТЧЕСТВО - строка 1000 символов

ном 6 УЛИЦА - строка 1000 символов

ном 7 ДОМ - строка 3 символа

ном 8 КВАРТИРА - строка 3 символа

 

Интерфейс:

Навигация и редактирование аналогична открытому листу в MS Excel.

Интерфейс ввода новой записи - обсуждается.

Поиск - аналогично комбинации клавиш Ctrl+F в MS Excel.

Комбинации клавиш Ctrl+1, Ctrl+2, Ctrl+3, Ctrl+6 упорядочивают таблицу по соответствующему полю (достаточно индексирования по первым 50 символам поля)

ДОПОЛНИТЕЛЬНО: скорость прокрутки таблицы по клавишам со стрелками, клавишам PageUP, PageDown не должна уступать скорости в MS Excel на протяжении всей таблицы (даже если прокручивать от первой до последней записи).

 

Дополнительные условия:

1. Разработанная программа становится собственностью заказчика.

2. Приемка-сдача работы происходит путем передачи заказчику программы, установки заказчиком программы на компьютер, тестирования программы с таблицами заказчика во всех обговоренных СУБД на операционных системах Windows и Linux размером до 100 млн. записей.

3. Для работы программы не должно требоваться дополнительного лицензионного софта. За исключением лицензий на Win и SQL. Для приемки-сдачи разработчик обязан предоставить свои лицензии в случае отсутствия таковых у заказчика.

4. ПРОГРАММА ДОЛЖНА РАБОТАТЬ В МНОГОПОЛЬЗОВАТЕЛЬСКОМ РЕЖИМЕ (соответственно блокирование записи при редактировании и обновление изображения таблицы). Авторизация пользователей, контроль прав, журнализация не нужны. Доступ всем, права всем. Все unknown.

5. Apache не использовать.

 

Предлагайте. Называйте суммы.

[Watashi]

Убедительная просьба: не пишите здесь больше. Откройте тему "Соколов - м...ак" и там развлекайтесь, если Вам так хочется. Обещаю Вам заходить туда и подтверждать название темы.

То, что я жлоб, я уже признал. laugh.gif То, что кидаю пустые понты - тоже признал. laugh.gif Надеюсь, что Вы удовлетворены.

Более чем удовлетворен и конечно последую вашей просьбе. Насчет темы тоже стоит подумать

Удачи в поисках разработчика.

Удаляюсь.

[Флэйм]

Внесу свои пять копеек

ritminform

Если попытаться формализовать приведенные тех.требования, поучим следующее:

1. Среда разработки - Java (больше никто без перекомпиляции и с такой степенью "простоты" для конечного пользователя нужный уровень кроссплатформенности не обеспечит)

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

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

 

Исходя из первичных ТТ получаем, что стоимость разработки будет в районе 50-80 тыс.руб. А учитывая заказчика (я вам при оценке сайта для вас об этом уже говорил) накидываем еще 30-50тыс. руб.

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

 

А вообще, тут имеем классическую проблему софт-разработок: заказчик (даже с учетом, что вроде бы знаком с ИТ) не может описать, что ему нужно, а потенциальные исполнители не готовы эти знания вытащить и требуют нормативку по ГОСТам

P.S.: давно хотел отписаться, но времени катастрофически нет, это же не со спокойным пикироваться

[ritminform]

1. Среда разработки - Java (больше никто без перекомпиляции и с такой степенью "простоты" для конечного пользователя нужный уровень кроссплатформенности не обеспечит)

Чем не подойдет, например, Python? (это только по моим скромным знаниям)

 

3. Необходимо уточнение: а) что подразумевается под автоматическим "обновлением" отображения таблицы,

Если одни юзер отредактировал запись, то другогой юзер должен сразу это увидеть

 

б) какое максимальное кол-во строк должно отображаться на экране,

Что за тупой вопрос? А как Вы сами на него ответите?

 

в) на каком железе планируется использование ПО (клиентское и серверное), т.к. именно от этого существенно зависит скорость обновления при прокрутке (которая, как я понял не должна превышать 1 сек. и непонятно как должна быть организована: "непрерывная по записям" или после скроллирования),

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

 

г) кто и как предоставляет тестовый набор данных.

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

[Marik]

А чё нет... и я ввяжусь в холивар

 

Насколько я понял, требуется одновременный доступ нескольких пользователей к базе данных. И работе с ней.

 

Но сначала уточняющие вопросы:

1. В этой системе должна быть поддержка нескольких СУБД. Очевидно, что работать с таким массивом данных будет сервер, а клиенту лишь выдаваться результат. Клиент на этапе подключения выбирает к какой именно базе обращаться?

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

3. Если исключить бредовые случаи (которые обычно отказываются регистрировать паспортные столы), то самая длинная фамилия состоит из 34 букв, а самое длинное имя из 28. С отчествами думаю похожая ситуация. Зачем 1000 символов на эти поля? Названия улиц также едва ли бывают длиннее 50 символов. В то время как номер дома (13к2) или квартиры (115а) может быть 4 символа. Итого вопрос: Можно ли ограничиться длинной полей Ф, И, О, улица по 50 символов, и увеличить длину полей дом, квартира до 4?

4. Задержки при прокрутке до 1 секунды устраивают ведь?

5. Почему запрещаете реализовать эту систему с web-интерфейсом? Это решило бы проблему кросс-платформенности.

[ritminform]

А чё нет... и я ввяжусь в холивар

 

Насколько я понял, требуется одновременный доступ нескольких пользователей к базе данных. И работе с ней.

Да.

 

1. В этой системе должна быть поддержка нескольких СУБД. Очевидно, что работать с таким массивом данных будет сервер, а клиенту лишь выдаваться результат.

Скорее всего да.

 

Клиент на этапе подключения выбирает к какой именно базе обращаться?

Желательно, но не обязательно. Например: может быть что-то вроде .ini-файла. Т.е. система может просто настраиваться с его помощью на работу с конкретной БД.

 

2. Смущает ваша неопределенность в выборе СУБД. По сути звучит как "пусть будут mysql, mssql, ну и еще что-нибудь, на всякий случай". Вы не знаете к чему готовиться?

Я вообще не ограничиваю в выборе СУБД. Определил только количество типов. Разработчик должен продемонстрировать работоспособность как минимум на 5 СУБД. СУБД разработчик выбирает сам.

 

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

Абсолютно верно.

 

В общем, какие именно СУБД должны поддерживаться?

На усмотрение разработчика. Для меня не принципиально. Вы заявите список, а я скорее всего соглашусь.

 

3. Если исключить бредовые случаи (которые обычно отказываются регистрировать паспортные столы), то самая длинная фамилия состоит из 34 букв, а самое длинное имя из 28. С отчествами думаю похожая ситуация. Зачем 1000 символов на эти поля? Названия улиц также едва ли бывают длиннее 50 символов. В то время как номер дома (13к2) или квартиры (115а) может быть 4 символа. Итого вопрос: Можно ли ограничиться длинной полей Ф, И, О, улица по 50 символов, и увеличить длину полей дом, квартира до 4?

Если Вас смущает название полей, можете их изменить. Тип и длину поля изменять нельзя.

 

4. Задержки при прокрутке до 1 секунды устраивают ведь?

Боюсь, что это много. Что в данном случае подразумеваем под словом задержка? Если время отклика на нажатие клавиши, то это много. Если полный скроллинг страницы записей на 50 или возможное "подвисание" причтении очередной порции данных, то, наверно, вполне приемлимо.

 

5. Почему запрещаете реализовать эту систему с web-интерфейсом? Это решило бы проблему кросс-платформенности.

Пусть ответом будет: НЕ ХОЧУ. Я же имею на это право?

 

Marik Эта тема не шутка и не прикол. Все что я написал - серьезно.

[Ksanatos]

Напоминает ситуацию из анекдота "Мне не надо как лучше, мне надо, чтобы вы замучились"

[Флэйм]

Чем не подойдет, например, Python? (это только по моим скромным знаниям)

Он интерпретируем (правда и тут есть варианты) со всеми вытекающими отсюда недостатками и достоинствами

Если одни юзер отредактировал запись, то другогой юзер должен сразу это увидеть

Таким образом, учитывая разброд и шатание с СУБД - однозначная трехзвенка (клиент - сервер приложений - СУБД).

Цитата(Флэйм @ 20 Nov 2009, 10:05 AM) *

б) какое максимальное кол-во строк должно отображаться на экране,

Что за тупой вопрос? cool.gif А как Вы сами на него ответите?

Легко - на экране одновременно отображается не более 10/100/10000/100000.... строк.

 

Ksanatos

+1000

[MpakV]

Как там объявление в газеты тиснутое поживает? Много Java-developerов высоконагруженных систем удалось найти в Астрахани за 30 тысяч рублей?

[ritminform]

Легко - на экране одновременно отображается не более 10/100/10000/100000.... строк.

Вы просто флудераст. Сгиньте из темы, пожалуйста.

[Флэйм]

ritminform

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

По итогам двух тем (данной и про ваш сайт) делаю неутешительный вывод: вы сами не понимаете, что вам нужно, при этом, считая себя ИТ-специалистом, считаете практически любую задачу сводимой к студенческой работе за 10 тысяч рублей. То что вы тут хотите, как говорил MpakV относится к высоконагруженным системам. При этом, вы не можете даже четко сформулировать требования! Давайте зайдем с другой стороны: опишите задачу, которую должна решать данная система, тогда на основе этого можно будет определить и требования к ней.

 

Иначе это похоже, как если бы я к вам пришел и сказал: "Хочу ручку, чтобы у нее было 10 цветов, и цветные карандаши (с любым цветом), и фонарик", а на ваш ответ, что такого нет или слишком дорого, сказал, "Да я за 100 рублей это сам сделаю, чего там делать - скочем смотать и все!".

[Marik]

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

Абсолютно верно.

Оу! Так вам не важен результат, а значит не важно за что платить, лишь бы человек работал! Я сегодня с утра мусор вынес и скрипт написал по обработке новостей. Переводите 3000 рублей на мой счет. К вечеру полный список дел могу составить. Это не шутка. Если вы хотите получить результат, то нужно цели ставить, а не придумывать как именно должен работать программист.

 

Если Вас смущает название полей, можете их изменить. Тип и длину поля изменять нельзя.

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

 

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

 

5. Почему запрещаете реализовать эту систему с web-интерфейсом? Это решило бы проблему кросс-платформенности.

Пусть ответом будет: НЕ ХОЧУ. Я же имею на это право?

Я пойму, если это продиктовано условиями применения готового продукта. Хотя нет, не пойму в любом случае. Защитить web-сервер не сложнее чем любой другой. Дыр в апаче меньше, чем в стороннем софте. Задача кроссплатформенности при использовании web-интерфейса решается однозначно. Это самодурство или вы не хотите говорить о каких-то еще условиях проекта?

 

В каких условиях будет использоваться система? Количество пользователей? Их удаленность?

[ritminform]

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

Абсолютно верно. Смысл другой.

 

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

Исходите из того, что никакой БД на сегодняшний день нет. Ничего конвертировать не надо.

 

Это самодурство или вы не хотите говорить о каких-то еще условиях проекта?

Я не хочу говорить о каких-то еще условиях проекта?

 

В каких условиях будет использоваться система? Количество пользователей? Их удаленность?

Первый вопрос не конкретен.

Количество пользователей - достаточно 3-5.

Удаленность... Считайте, что все будут работать терминально. Т.е. удаленность равна 0.

[ritminform]

...

Вы не считаете флудерастом предположение о размещении 10000 строк на экране?

 

Самоутверждаться предпочитаю в наличных деньгах. Форум - не то место.

Заинтересован получить то, что я написал. Для того и тема.

А на пустой треп про 10000 строк на экране у меня не всегда хватает времени.

Флейм писать не будет. ИМХО. А, следовательно, мне не о чем с ним разговаривать.

[ritminform]

Конечно, не будет, потому что в любом случае мозги Вы, извините, выебете больше, чем заплатите.

 

Я думаю, что никто из участников этой темы Вам ничего разрабатывать не будет по той же причине.

Пока, например, Вы мне тут мозги делаете...

Ваше мнение к сведению принял.

[Флэйм]

Флейм писать не будет. ИМХО. А, следовательно, мне не о чем с ним разговаривать.

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

ИМХО, судя по Вашим ответам тут (как в прочем и в теме про Ваш сайт), вы заказывать не собираетесь. Смысл этой темы мне абсолютно не понятен.

[ritminform]

ИМХО, судя по Вашим ответам тут (как в прочем и в теме про Ваш сайт), вы заказывать не собираетесь. Смысл этой темы мне абсолютно не понятен.

За 150-200 тысяч не собираюсь. Поэтому и предложил Вам покинуть тему.

[Флэйм]

За 150-200 тысяч не собираюсь. Поэтому и предложил Вам покинуть тему.

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

[ritminform]

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

Хорошо. Давайте попробуем еще раз.

Пожалуйста, меньше букв и конкретнее вопросы.

 

По поводу Явы: Можно и на Яве, однако я не против итерпретаторов.

По поводу строк на экране: не менее 50.

 

Задавайте еще вопросы, только желательно без подколок.

[Флэйм]

ritminform

А подколок и не было.

 

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

 

Итак,

Задача: разработка многопользовательской кроссплатформенной системы, для обработки данных, хранимых в одной единой таблице:

ном 1 КОД - строка 12 символов (идентификатор)

ном 2 ИНН - строка 12 символов

ном 3 ФАМИЛИЯ - строка 1000 символов

ном 4 ИМЯ - строка 1000 символов

ном 5 ОТЧЕСТВО - строка 1000 символов

ном 6 УЛИЦА - строка 1000 символов

ном 7 ДОМ - строка 3 символа

ном 8 КВАРТИРА - строка 3 символа

Оператор осуществляет ввод данных, их просмотр, сортировку, фильтрацию, поиск и редактирование.

Общее число записей - до 100 млн. Максимальное количество одновременно работающих опеораторов - 5. Максимальное время отклика системы при обновлении данных - 1 сек. Система должна быть независима от СУБД. Работа ведется в рамках ЛВС со скоростью не менее 1000Мб/с. При изменении записи одним из опраторов данные автоматически обновляются у всех остальных. Все права на разработку переходят заказчику.

 

Уточнения:

1. Кол-во одновременно обрабатываемых сток - от 50 до 100?

2. Минимальные требования к рабочим местам/серверу по оперативной памяти - ?

3. Время разработки - 2 месяца?

[ritminform]

ritminform

А подколок и не было.

 

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

 

Итак,

Задача: разработка многопользовательской кроссплатформенной системы, для обработки данных, хранимых в одной единой таблице:

ном 1 КОД - строка 12 символов (идентификатор)

ном 2 ИНН - строка 12 символов

ном 3 ФАМИЛИЯ - строка 1000 символов

ном 4 ИМЯ - строка 1000 символов

ном 5 ОТЧЕСТВО - строка 1000 символов

ном 6 УЛИЦА - строка 1000 символов

ном 7 ДОМ - строка 3 символа

ном 8 КВАРТИРА - строка 3 символа

Оператор осуществляет ввод данных, их просмотр, сортировку, фильтрацию, поиск и редактирование.

Общее число записей - до 100 млн. Максимальное количество одновременно работающих опеораторов - 5. Максимальное время отклика системы при обновлении данных - 1 сек. Система должна быть независима от СУБД. Работа ведется в рамках ЛВС со скоростью не менее 1000Мб/с. При изменении записи одним из опраторов данные автоматически обновляются у всех остальных. Все права на разработку переходят заказчику.

Спорные утверждения выделяю.

- максимальное - любое, но максимально должно быть не менее 5. Т.е. может и 10.

- время отклика - надо определить что мы будем понимать под этим словосочетанием.

- ЛВС не обязательна. Т.е. Мне не обязательно посылать SQL-запрос через сеть. Допускается терминальное подключение к серверу и, соответственно, запросы и результаты передаваться не будут. Соответственно, можно работать и на 64к

 

1. Кол-во одновременно обрабатываемых сток - от 50 до 100?

Не совсем понимаю.

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

- Если Вы имеете в виду количество отображаемых на экране строк в сетке, то вполне нормально.

 

2. Минимальные требования к рабочим местам/серверу по оперативной памяти - ?

По мне так чем меньше, тем лучше. Но будем отталкиваться от максимально - Core2Duo4600, 2Gb. Рабочие места оговаривать не будем, поскольку я предпочитаю тонких клиентов.

 

3. Время разработки - 2 месяца?

Это отдельный разговор. Но хотелось бы побыстрее.

P.S. 5часов/день*60дней=300 часов. 300 часов*500рублей/час=150 тысяч рублей. Дорого.

[ritminform]

Как там объявление в газеты тиснутое поживает? Много Java-developerов высоконагруженных систем удалось найти в Астрахани за 30 тысяч рублей?

 

А вот что я получил только что на почту от уважаемого мной специалиста после моего к нему телефонного звонка (дословно с разрешения автора):

Привет, Володь!

 

Прочитал я все.

1. Наши пацаны назвали сумму на порядок меньше - 20 штук и срок 1 месяц.

Исполнение на Ява + хибернэйт. Про питон скажу сразу - просто опыта работы на нем у наших ни у кого нет. А на Яве - есть.

2. НО! Мне тут же отметили отсутствие некоторых важнейших деталей в ТЗ.

Я их тоже увидел и удивлен, что никто не поднял вопросов:

а) сколько пользователей? Какие из права? Авторизация пользователей, контроль прав, журнализация не нужны. Доступ всем, права всем. Все unknown.

б) самое важное! Чего я просто забыл:

 

персональные данные должны защищаться по 1Г, а там авторизация на уровне СУДБ и прочие тонкости

типа сертифицированного ПО и ТО

Если тебя такие наблюдения по одному взглюду на твое ТЗ привлекают, то я вас свяжу и дальше договаривайтесь.

 

<подпись>.

[ritminform]

Заказывайте. Или 20тыс. тоже много?

Нормально. В выходные, надеюсь, будем встречаться и договариваться. Тогда и станет все ясно.

 

Мое мнение: Пацаны не до конца оценили всего масштаба задачи.

Пацанам то за 30... И стаж, и опыт, и должности.

Просто, думаю, что для них это семечки. Маленькая шабашка...

[Флэйм]

- максимальное - любое, но максимально должно быть не менее 5. Т.е. может и 10.

Принято

- время отклика - надо определить что мы будем понимать под этим словосочетанием.

Максимальное время, в течении которого происходит обновление данных: при скроллинге таблиц, поиске, наложении фильтров, добавлении записей и т.п.

- Если Вы имеете в виду количество отображаемых на экране строк в сетке, то вполне нормально.

Да.

 

Работа ведется в рамках ЛВС со скоростью не менее 1000Мб/с.

Тут мой косяк - поставил один 0 лишний Конечно 100Мб/с, но т.к. вам нужно еще и терминальное решение - действительно не существенно.

 

С перс.данными вопрос действительно интересный - если считаем, что это не реальные данные, а некая абстракция или что-то другое (судя по размерам полей) - то забейте. Если же это реальные данные - накидывайте еще минимум тысяч по 20 на аттестацию каждого рабочего места. Про сервер я вообще молчу.

[ritminform]

Максимальное время, в течении которого происходит обновление данных: при скроллинге таблиц, поиске, наложении фильтров, добавлении записей и т.п.

Это даже круто. Задача по наложению фильтров не ставится.

Главное для меня - отсутствие задержек при навигации. Не поиск и фильтрация, а клавиши со стрелками и PgUP-PgDown. Поведение должно быть как в Excel: нажал <Стрелка вниз> - курсор добежал по сетке до последней строчки и дальше пошел скроллинг таблицы от текущей до последней записи. ЭТО ВАЖНО.

Поведение, типа добежал до последней и перескочил на 1-ую строчку GRID-а, установив следующую запись в 1-ую строчку сетки - НЕПРИЕМЛЕМО.

 

С перс.данными вопрос действительно интересный - если считаем, что это не реальные данные, а некая абстракция или что-то другое (судя по размерам полей) - то забейте. Если же это реальные данные - накидывайте еще минимум тысяч по 20 на аттестацию каждого рабочего места. Про сервер я вообще молчу.

Не актуально. Выкиньте из головы.