На что обращать внимание при оценке проекта преобразования PowerBuilder?

Я пытался составить спецификацию для миграции с PowerBuilder 9 на 11.5 относительно сложного приложения. Конечно, PowerBuilder не совсем моя специальность. У меня возникают проблемы с попыткой обосновать оценку этой части проекта (и люди PowerBuilder, с которыми я разговаривал, в последнее время столкнулись с некоторыми личными проблемами и не общаются). Вот некоторые из показателей, которые мы видели и можем оценить:

-PBL Files
-Main Windows
-Data Windows
-Функции

(нет, у нас нет исходного кода для этого проекта)

Какие именно метрики полезны и сколько времени потребуется для каждой отдельной «единицы», такой как окно данных?


estimation powerbuilder project-estimation powerbuilder-conversion
person tekiegreg    schedule 24.03.2010    source источник
comment
Я мало что знаю о PB 9, но одна из причин, по которой мы просто заменили наше последнее приложение PB 5 на гораздо лучшую программу .NET, заключалась в том, что дыра была двоичным BLURB, к которому у нас не было доступа. код на уровне текста. Итак, контроль версий работал не очень хорошо, глобальный поиск не работал, а код-метрики ??? Да, поняли, тоже не очень хорошо работали.   -  person Doc Brown    schedule 25.03.2010

Ответы (2)


arrow_upward
5
arrow_downward

Большинство миграций PowerBuilder проходят довольно плавно. Самыми важными вещами, которые могут заставить вас перейти с 9.0 на 11.5, являются (а) изменение элемента управления Rich Text Edit (если он используется) и (б) Unicode по сравнению с ANSI. Последнее в первую очередь будет проблемой, если у вас есть вызовы внешних функций, которые передают строки и требуют только добавления суффикса; ANSI или перехода на версию вызова Unicode.

Итак, посмотрите, используется ли элемент управления Rich Text Edit, и посмотрите, сколько вызовов внешних функций объявлено. Если у вас нет ни того, ни другого, это будет так же просто, как открыть проект в 11.5 (конечно, после создания резервной копии) и разрешить 11.5 выполнить миграцию.

person Bruce Armstrong    schedule 24.03.2010
comment
Я согласен с двумя категориями. Миграция PB добавит квалификатор; ANSI ко всем вызовам внешних функций, которые имеют строковые параметры. Я бы поискал любые внешние функции, которые имеют байтовые массивы или капли, в которые кто-то пытается вставить строку; вставка в него строки Unicode вместо строки ANSI может вызвать проблемы. (PBL Peeper может предоставить вам список дополнительных функций.) Что касается метрик, я не думаю, что какие-либо метрики, основанные на коде, имеют значение; миграция автоматизирована. Подавляющее большинство усилий приходится на тестирование, поэтому вы хотите знать количество функциональных точек в пользовательском интерфейсе приложения. - person Terry; 25.03.2010
comment
Еще одна вещь, которую следует учитывать, если это приложение PFC, - это исправить и продолжить использовать перенесенный PFC или перейти на версию, созданную для 11.5. Если нет среднего уровня и есть настройки для PFC, вы можете оставить старую PFC. - person Hugh Brackett; 25.03.2010
comment
Хороший ответ, Брюс. Единственное, что я бы добавил, - это уделить много времени тестированию. Миграция обычно проходит очень гладко, готов поспорить, вы сделаете это в первый же день. Проблема с ANSI, упомянутая Терри, заставила меня мигрировать за один раз. Однако для обнаружения возникающих причуд требуется много испытаний. - person Rich Bianco; 29.11.2010

arrow_upward
0
arrow_downward

Прошло некоторое время, и я не помню подробностей, но наше обновление с 9 до 11.5 прошло очень гладко.

person FauxReal    schedule 31.03.2010