Разовая работа (ВОЗМОЖНО, И, СКОРЕЕ ВСЕГО, УДАЛЕННАЯ) по переводу программного комплекса (программы, отчеты, формы) с платформы 2.6 на VFP 9
Географически, если это важно, находимся в Донецкой области, Украина.

Направление: складской учет.
Объем работ: довольно большой
Срок: до трех месяцев
Оплата: договорная
Варианты оплаты (банком, Webmoney... и т.д.): на Ваше усмотрение



Вопросы, предложения и пожелания по оплате пишите сюда или на ''.phorum_html_encode('choleria@gmail.com').''
с уважением, Антон

ЗЫ. Прошу прощения за изначально неправильно оформленную тему. По мере сил исправил



Исправлено 2 раз(а). Последнее : countzero, 02.02.10 17:09

>перевод программного комплекса
Имхо
А оно надо? Слишком разные подходы к программам, отчетам, формам у 2.6 и VFP 9
в VFP 9 очень много нового и очень интересного
да плюс коррекция бизнес-процессов, которые 99% изменились с момента написания на 2.6
Тупой перевод с платформы 2.6 на VFP 9 неэффективен
Начинать надо с ТЗ, в котором прописан функционал и что желательно сохранить из уже написанного, а потом писать заново на VFP 9

PrSymbol
>
плюс коррекция бизнес-процессов, которые 99% изменились с момента написания на 2.6

Комплекс работает и постоянно модифицируется силами штатных программистов (то есть, бизнес-процессам соответствует).

Проблема в том, что времени у них катастрофически недостаточно, потому и принято решение поиска внешних специалистов для этой задачи.

countzero

PrSymbol
>
плюс коррекция бизнес-процессов, которые 99% изменились с момента написания на 2.6

Комплекс работает и постоянно модифицируется силами штатных программистов (то есть, бизнес-процессам соответствует).

Проблема в том, что времени у них катастрофически недостаточно, потому и принято решение поиска внешних специалистов для этой задачи.

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

Самый важный вопрос - какова цель подобного перевода - зачем менять то что и так работает... Просто одно дело тупо "сконвертировать" программу в 9-ку (конечно это я утрирую - ибо чтобы оно "заработало" реально придётся попотеть, хотя по срокам это видимо реально), и совсем другое, на основе вашей бизнес-логики создать с нуля новую программу - используя продвинутые возможности 9-ки... Но тут сроки IMHO маловаты.
P.S. И всё-же надо следовать правилам "доски объявлений"

1. Где территориально находитесь.
2. Какие доки есть (ТЗ, описание БД, описание интерфейса, ... )

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

ТЗ заключается в том, чтобы перенести на VFP 9 . Описание БД и интерфейса, к сожалению, в данный момент в головах, но программисты готовы составить документацию.

Плохое ТЗ. Нужно чётко представлять ЦЕЛЬ - красивый интерфейс, работа в Vista\Win7, ускорение... А не средства.
Может имеет смысл сначала открыть тему в основном форуме и обсудить... А ещё лучше почитать что ранее писалось по поводу таких "переводов" - и уже потом "доформулировать" постановку. Т.к. всё-же есть существенная разница между "адаптацией" FPD программы (читай возможностью её запуска в среде VFP9) и реальным переписыванием, используя новые возможности.

отписался

countzero
ТЗ заключается в том, чтобы перенести на VFP 9 . Описание БД и интерфейса, к сожалению, в данный момент в головах, но программисты готовы составить документацию.

Так где территориально находитесь, ведь придётся встречаться, что бы утрясать "тонкости".

PaulWist

countzero
ТЗ заключается в том, чтобы перенести на VFP 9 . Описание БД и интерфейса, к сожалению, в данный момент в головах, но программисты готовы составить документацию.

Так где территориально находитесь, ведь придётся встречаться, что бы утрясать "тонкости".

Паш, товарисч ответы пишет в первом посте.

ssa
... товарисч ответы пишет в первом посте.

Упс, понял.

Далековато, однако, а так бы взялся





Исправлено 1 раз(а). Последнее : PaulWist, 03.02.10 12:12

кому как

PaulWist

ssa
... товарисч ответы пишет в первом посте.

Упс, понял.

Далековато, однако, а так бы взялся

Така ж фигня...

Если будет структура таблиц (описание полей и связей) то интерфейс легко перенести на VFP. Тупая конвертация отчетов может не пойти (оформление разъедется) но то же реально. Если до 25 февраля на резюме не ответят можно взяться. Готовьте описание . Все равно делать это придется.



Исправлено 1 раз(а). Последнее : IgorK, 03.02.10 14:58

Если есть штатные программисты то в чем проблема, анологичную задачу перевода тупо решал переброской кода в VFP, далее корректировал размеры и перекодировал меню и тексты в prg , в define window добавлял font 'courier' , отчеты правда переносились криво пришлось переписать, в таблицах кодовую страницу 866 и все работало как прежде.

Если решить проблему единообразного показа, вставки , редактирования и удаления записи то работать с VFP - одно удовольствие. Но Ключевые поля могут быть 1) строковые 2) цифровые 3 ) составные и даже это решаемо... Самое неп риятное когда реляционную модель не соблюдают. Как с этим бороться я пока не придумал... Как у вас с этой проблемой?