Можно ли переделать программу на FoxPro 2.6 в современный вид?
На работе в государственной больнице есть программа, написанная на FoxPro 2.6, работающая в DOS. Отдел статистики в формы вводят данные по пациентам и отделениям, потом печатают отчеты по определенным формам. Файлы базы данных, насколько я понимаю, хранятся в файлах DBF.
Подскажите, можно ли переделать эту программу в современный вид, с нормальным интерфейсом, возможностью печати на usb-принтер и чтобы работала под Windows 7. А также желательно с возможностью переноса существующих данных.
Я в том, что связано с DOS, вообще не разбираюсь. Буду благодарен, если подскажете хотя бы как правильно задавать этот вопрос Гуглу.
Для правильного вопроса надо знать половину ответа
А вам и не надо разбираться в DOS, достаточно более-менее разбираться в предметной области и иметь исходники старой программы. Ну или не иметь исходников, но хорошо разбираться в предметной области, чтобы понять логику работы программы.
Средства работы с DBF есть практически под все языки, так что можно написать как программу, работающую с теми же базами, так и конвертировать базы в другой формат и сделать хоть десктопное, хоть web-приложение.
Павел Романов, Учтите что ценник на разработку такого ПО с нуля может перекрыть весь годовой бюджет на ИТ в больнице
Если это РФ, поищите лучше какиенить федеральные программы (не компьютерные) по поводу обновления программных инфраструктур в больницах, сейчас же массово внедряют такие комплексы и до вашей больницы очередь дойдет
Павел Романов, Фирму или индивидуала. Задача классическая, сильно специальных знаний не требующая. Если это не столица, то ценник может быть вполне умеренным. Но обязательно оговаривайте какой-то период внедрения/поддержки и желательно получение полных исходников после этого периода, чтобы кто-то другой смог продолжить работу в дальнейшем.
1С - хороший вариант. Но это если есть готовая конфигурация для Вашей области, в которую только нужно импортировать данные, ну и возможно немного доработать. А разрабатывать конфигурацию с нуля скорее всего дороже выйдет, плюс стоимость самой 1С. Но это всё не точно - смотреть нужно.
Олег Гамега, В 1С уже есть проверенные, отработанные "кирпичики" для создания учётной системы - справочники, документы, регистры, их взаимосвязи, инструменты для создания отчётов, разумеется печать всего этого. Плюс дополнительные плюшки типа контроля прав пользователей, электронной почты, вложенных файлов и т.п. (пишу первое, что в голову пришло - там очень много всего). Если всё это реализовывать в программе, которая пишется скорее всего в единственном экземпляре, то трудозатраты, а следовательно и цена будет больше. С другой стороны часто далеко не все эти возможности 1С нужны. Плюс иногда при внедрении 1С приходится подстраивать привычную логику работы под логику 1С (например, вполне возможно, что в описываемой системе понятия "документ", и тем более "проведение" нет вообще!), в самописном приложении легче сохранить привычные процессы. А в целом это такой же инструмент, как и любой другой язык программирования. Нужно смотреть реальные цены на подобную разработку в конкретном регионе, добавить цену на 1С (если нужен клиент-сервер, то в случае 1С это будет существенно) и принять решение.
ИМХО если и нанимать разработчика, то надо чтобы исходники были предоставлены.
Но тут я вижу много проблемы: трудности взаимопонимания заказчика и исполнителя, период исправления ошибок, который может тянуться долго - за чей счет это будет делаться? Риск недостаточное компетентности исполнителя и риск срыва сроков проекта. Очень много рисков.
Чем проще задача по объему тем лучше ее сделать самим, хотя бы потому что ее будет проще сопровождать. А с точки зрения квалификации - это рост.
По инструменту - я бы смотрел в сторону WWW, это или php, или python и т.п. языки, библиотеки для доступа к DBF давно существуют. Нет смысла сейчас делать толстого клинтеа под винду, тем более простые приложения - больше доля проблем с поддержкой и совместимостью. Тем более DBF подразумевает файловый доступ скорее всего через сеть - это дополнительный источник проблем.
DBF в Foxpro имеет свои индексы, которые как правило плохо поддерживаются сторонними библиотеками, а без индексов что-то приличное по объему будет сделать сложно. При совместном использовании foxpro , то читать такую dbf базу со стороны безопасно только на чтение. Можно сделать некий демон на foxpro который будет писать в эту базу. Это гораздо безопаснее.
А самый эффективный вариант по возможности уходить с DBF на MySQL, полностью поменяв стек.
hx510b, разумеется, если они возьмут исполнителем первого попавшегося студента, которому на пиво не хватает, то будут и риски и срывы. Но если подойти с умом, как положено при любом найме на работу, то не вижу в задаче никаких подводных камней - проект как проект.
kalapanga, согласен, если повезет с выбором - то будет успех, если не повезет - то будут проблемы. Я сам занимался наймом людей - работа с исполнителями - это тоже работа и без погружения в детали проекта праздника точно не будет. Насчет "с умом" - можно привести много примеров высоко бюджетных проектов, делавшихся в интересах серьезных и именитых компаний, которые все равно заканчивались фиаско. Поэтому, если даже в крупных известных компаниях не всегда знают как достичь гарантированного успеха, при этом имея хорошие бюджеты и опытных сотрудников. То что говорить о тех, кто этим занимается случайно? Это однозначно риск.
Риск можно снизить - условиями договора, чтобы исполнитель был заинтересован в успехе проекта - впереди должен быть не только плата за работу, но и хороший приз. Т.е. нужно мотивировать исполнителя успеть, и сделать это хорошо. Второй аспект - отбор исполнителя - здесь мне кажется важными - взаимное понимание обсуждаемых проблем. хороше портфолио успешных проектов - чем больше проектов исполнитель сделал - тем очевиднее вероятность его успеха в следующем проекте.
hx510b, Всё совершенно правильно говорите! Действительно, очень важен пункт про взаимопонимание и тесное взаимодействие. Заказчик должен осознавать, что от него тоже потребуется серьёзная работа. Со стороны заказчика должен участвовать не только айтишник (к нему-то будет не так уж много вопросов), но и кто-то - заинтересованный активный пользователь существующей программы. Именно с ним у исполнителя должен быть постоянный контакт. Потом он станет основным тестировщиком и приёмщиком нового продукта. Мне в своё время сильно повезло при реализации очень похожего проекта взаимодействовать с инженером заказчика. Дама могла ответить на любой мой вопрос, а потом тщательно проверила то, что у нас получилось. Ей самой всё это было очень интересно. И после запуска новой программы исправлений-доработок уже практически не было.
Переделать врятли есть смысл. а вот написать с нуля и сделать импорт данных вполне, почему бы и нет. у гугла спросите только как вытянуть данные из foxpro
==
Вообще конечно советую не связываться с госконторами, ничего кроме геморроя вы там не найдете, а им еще и жизнь усложните (когда уволитесь наконец оттуда)
Ваша основная задача - импортировать данные из DBF. Это и есть самое ценное.
А обертку новую подобрать из учета требований к современным системам. Под оберткой я понимаю платформу, язык программирования, тип БД, где все храниться будет.
У меня тоже есть очень старый проект на FoxPro 2.6. В свое время хотели начать переписывать на Visual FoxPro, но руки так и не дошли. Теперь с высоты опыта, думаю, что лучше написать всё заново на более современном стеке, только данные экспортнуть и всё.
Эх FoxPro 2.6 ностальгия... :)
Тут сильно всё зависит от требуемого функционала и близкодоступных кадров, так как вариантов очень много. Сами формочки и логику можно на любом стеке написать (например на PHP или на C#/.NET). Больше вопросов вызывает конструктор форм для печати и другой возможный функционал. Например, для моего проекта на Foxpro 2.6 для отчетов я использовал Seagate Crystal Reports и его, скорее всего, можно натравить на другую БД и он будет работать так же. Посмотрите как это реализовано у вас и на основе этой информации поищите доступное решение. Ну и наверное, найти разработчика на Visual FoxPro будет сложнее, чем например на C#, так как на нем уже давно никто ничего не разрабатывает. Как-то так.
Oligophren, Спасибо, примерно понял. А просто например на MS Access можно сделать? Там в принципе в программе около 10 параметров всего заносится, типа ФИО, возраст, адрес, в каком отделении лежал, с каким диагнозом, сколько дней. Ну и печать отчетов например загруженность отделений или все кто лежал за определенный период.
Павел Романов, смотри в сторону framework на python - пусть это будет django или любой другой каркас, на который вешать свой функционал. Можно конечно PHP joomla, drupal, но на PHP кодеров много, а грамотных мало.
В общем виде стек называется LAMP - Linux, Apache, MySQL, PHP/Python/Perl
По MS Access ничего путного сделать нельзя. Только прототип для себя на коленках. Там много проблем.
Павел Романов, теоретически можно и на MS Access, наверное. Не могу точно сказать, так как сталкивался с ней только в универе и уже не помню что она может.
Стоит не только переписать, но и заново переосмыслить функциональность. Выкинуть хлам, дописать новую.
Можно переписать на другие современные технологии (например, .NET) и СУБД, пока стало не поздно.
Но если есть лишнее время...
Чтобы хоть немного оттянуть неминуемый конец цикла программы, можно провести короткий эксперимент по адаптации к Visual FoxPro 9.0 (VFP) для запуска в Windows 7/10 или через Wine в GNU Linux.
Для оценки финансовой окупаемости переноса ПО из FoxPro можно воспользоваться этим калькулятором.
не надо .Net , не надо привязываться к винде, не надо пилить толстого клиента - это все дорогие и бесперспективные занятия.
.Net уже не является актуальной технологией как и Wnidows. Есть смысл вкладываться в только кроссплатформенные решения - а это WWW стек.
Microsoft как кидал и так и кидает своих клиентов. Нет смысла туда платить деньги.
К тому же на рынке труда .Net - тоже узкая ниша - мало вакансий мало специалистов. Скоро совсем будет экзотика.
Можно попробовать скомпилировать на [х]Harbour. Это такой проект, который уже на 100% совместим с CA Clipper 5.3, который имел некоторую совместимость с FoxBase. Смотря, какие фишки FoxPro использовались. Скорее всего придется адаптировать исходники.
