We improved performance and stability of a Payroll and tax system software, migrated it to the latest  version of Delphi

The team conducted the initial source code analysis to determine key project factors in order to select appropriate approach:

• Project size;
• Documentation fulfillness;
• Customer’s team responsibilities areas;
• Project dependencies;
• Migration sequence and approach.

It was crucial to determine the dependencies between components and core modules to plan the work consistently and also prevent working in vain, time, and resources wasting.

We used next migration framework:

Select RAD Studio version (Delphi version)

• Select Delphi version for the further development;
• Bought license;
• Deployed the project.

Create the project migration table

• Project (.dproj) name;
• Type of project: No-UI / UI project;
• Migration objectives;
• Project description;
• Dependencies etc.

Highlight main tasks to provide a baseline for further work;

Split the whole project into smaller projects

Prepared components migration table

Divide the projects to No-UI projects and UI projects

No-UI projects migration:

Analyze and describe at least 5 unit tests for the key functions of each project;

Develop unit tests for Delphi 7 version;

Perform migration:

• Try to compile (iterations) (change deprecated operators and so on);
• Analyze data types usage;
• Analyze pointers usage – remove or reduce pointers usage;
• Migrate strings to Unicode;
• Perform smoke test;
• Go through all warnings and hints (usually warning is equal to error);

Check unit tests for the up-to-date Delphi version;

UI projects migration

Analyze and describe at least 5 unit tests for each project for key functions for no-UI parts;

Develop unit tests for Delphi 7 version;

Perform migration:

• Open .dfm files (forms and data modules) in the text editor and fix/change any properties, class names, etc. according to Components Migration table (form should be prepared before opening in the IDE form editor, because in another case component just will disappear);
• Chang all components class names in the .pas files where is necessary;
• Put new components where is necessary;
• Try to compile (iterations) (change deprecated operators and so on);
• Analyze data types usage;
• Analyze pointers usage – remove or reduce pointers usage;
• Migrate strings to Unicode;
• Perform smoke test;
• Went through all warnings and hints (usually warning is equal to error);

Checked unit tests for the up-to-date Delphi version;

Testing (Manual, Automated)

For a common understanding of the functionality we organize all test cases in one list. After checking the tests’ relevance, it was found that many of them were obsolete and did not contain all the functionality parts. So, we expanded the initial list with the missing scenarios.

Some of the test cases that needed to be checked on a regular basis were automated. In the process of migration after finishing every phase a regression testing of the main functionality was made. In controversial cases the behaviour was compared with the unmigrated application.

Also, a special tool to test API was created. To see if the migration improved the software, a performance testing was conducted before and after the migration.

We applied the Agile software development methodology for the project migration. It gave us and to the customer the vision of the project speed, progress, deliverables and ability to test some parts in parallel to speed up the project migration itself. Our team tends to follow continuous delivery principles. Our client was completely informed of our speed, so it allowed them to increase/decrease the workload and the team scale according to each migration phase.

As far as the customer had their own established approach to the development, our team easily adapted to them to work collaboratively and productively.

As required by the agile approach we followed scrum activities such as:

Sprint planning

During that kind of meetings the team was taking the tasks for the upcoming sprint according to the task scale, difficulty and priority and approved it with the customer’s PO

Daily meetings

Day-to-day meetings where the day results, plans, questions were discussed;

Sprint grooming

The meeting where the teams validated current/valid/invalid tasks and cleaned the backlog up

Sprint demo

The session where all the company teams (more than 60 people) conducted the presentation of performed work. Almost all of the company members participated there, including top management leaders, subdivisions, etc. Each participant was able to ask any question or request some clarifications that made the communication transparent and the atmosphere warm

Retrospective session

The session where sprint results were discussed, the obtained knowledge was documented and stored for historical reasons.

On-time Reporting

Every sprint our project manager prepared bi-weekly reports to provide the customer with the project results, allotted time, tasks completion, difficulties, and any other helpful information. That approach prevented both sides from misunderstandings and allowed them to be in sync during the project timeline.