Part 2: The software.
Introduction:
In part one of this article, we looked at the steps needed to assess unsupported software and hardware in a business from a systems perspective. In this part we will look at the process and options available when a client wishes to manage the bespoke software of a system when the original vendor is no longer involved, in order to support it effectively, fix bugs, or to make improvements.
Welcm Software’s Process:
Usually at this stage the software will be in one of three forms:
- Executable program files stored locally on the PC
- Web application files served from a local server
- Web application files served from a remote server
In the case of executable files, for Windows based systems this will typically be a WPF or WinForms application with C# logic. These need to be decompiled in order to understand the application logic. There may well be associated DLL files that will also need investigating and decompiling if necessary. Decompiling them creates a set of source code files that will need to be arranged and rebuilt into a functioning application. This code will be checked in to a dedicated repository for the client.
Web application files on a local server may or may not need decompiling, depending on the technology used. ASP.Net/C# applications may have DLL files that require decompiling, whereas an application written using PHP for example would not require decompiling.
The same applies for files stored on a remote server, except access would be required to the remote server in the form of logins and passwords or ssh keys.
When rebuilding software from the source code, we aim to recreate the live environment within our development environment as accurately as possible, in order to test thoroughly before deploying. This means in the case of applications that access external APIs, we may create simulated versions of these API endpoints within our local systems with dummy data (see our article on creating dummy data for testing).
During this process we will gain an understanding of how all elements of the application function, and will be able to then carry out any bug fixes or specific requests for changes by the client, or provide recommendations for improvements.
In some cases the current software solution may be too outdated and we would recommend recreating the functionality with new software. The existing system can be used to help define the functionality and we will migrate across any existing data and ensure a smooth transition between systems.
We always ensure we thoroughly document the code and any changes as they are checked in to the source code repository, to ensure the client maintains control of their software in the future.
