Customise, Test and Amend Software Applications

Customise, test and amend software applications

Introduction

Constructing forms and reports

Using advanced form techniques

Using advanced report techniques

Toolbars

Creating menu systems

Automating the StartUp

Testing and client feedback

Testing process overview

Amending to meet client requirements

Documenting the changes

Summary

Check your progress

Introduction

After reviewing the needs analysis and other materials, you can commence your design. Customising existing packaged software involves analysing the chosen software package and its features, and building a solution within the scope of that program. The program may be spreadsheet, database or another type of application.

In this Reading we’ll focus on the development of a customised application using a relational database. There are many database programs to choose from. Some of the more commonly known are Microsoft Access, Foxpro and SQL Server, Filemaker Pro and Apple/Claris Works. Most have trial versions available for download. All of these are well supported with plenty of free tutorials and resources available on the Internet.

You’ll need to create the forms, reports and other documents used by an organisation, test them, and talk with the people who use the system to make sure that they suit their needs. You should find out what aspects of the system work well, and where improvements can be made. After the client testing phase you make any required amendments to the software, documenting changes along the way.

The systems development lifecycle (SDLC) involves similar stages regardless of the size or scope of the project. SDLC is a systems approach to developing applications and is made up of stages:

1The software concept — identifies and defines a need for the new system

2Analysis — analyses the requirements of the end users

3The design — creates a blueprint for the design with specifications for hardware, software, user interface and data

4Constructing, coding, and debugging

5System testing and evaluation.

Constructing forms and reports

Most database applications include tools to make the construction of the forms and reports in your application easy to do by following a few simple prompts. Take the time to familiarise yourself with the package that you have chosen to use. There are many useful tutorials and text books available. Some suggestions have been noted in the Research section of this Learning Pack.

Once the objects have been set up you are able to modify them to suit the design requirements as specified by your client during the analysis and design phases of the project. You do this by changing the View of the object. For example, if you are using Microsoft Access this is done in Design View. In Filemaker Prothis is done in Layout View.

Find out how to do this in the program you are using.

Using advanced form techniques

Forms are used for displaying information or accepting user input. Although you can use tables to input information, forms give capabilities to be useful, informative and attractive to the user.

All the detail on a form is contained in objects called controls.Bound controlsare linked to data fields in the underlying table or query. They can be used to enter, edit, display and print data. Unbound controlsare not linked to the data fields in the underlying table or query. They can be used to display information such as form title, labels for data fields, boxes and lines to organise the form into sections, and graphics to make the form more attractive.

Using a form is an efficient way to enter data because it can save time and prevent typing errors by:

• matching paper forms on which data is collected
• using lists or combo boxes from which values are chosen rather than requiring the user to type repetitive data
• perform calculations or summarise data.

When designing forms in most software applications, each object on the form has its own properties. In Microsoft Access you can add objects to the form from the Control Toolbox. If it doesn’t come up on your screen automatically you can click on the button on the toolbar, or choose the View Menu (Toolbox).

By right-clicking on the object and selecting Properties you are able to make changes to the way the object ‘behaves’ — including its appearance, control source (what it is bound to), and any ‘events’ that may occur — such as opening a form because of a command button being ‘clicked’. The properties will look different depending on what the object is — eg a text box has different properties to an image.

Using advanced report techniques

Multi-table reports

Reports can be constructed using fields from more than one table. In doing so, it takes account of the relationships between tables. Many database programs have tools to help you construct your reports. You can then modify the design to suit the requirements of your client. For example, in Microsoft Access, the Report Wizard makes it very easy to construct complex reports using fields from many tables. You do not have to construct separate queries on which to base the report. The wizard does that automatically in the background.

Computed fields in reports

Reports can contain labels, and text boxes (which are bound to fields from the database). It is also possible to add text boxes whose data is computed from the fields in your tables or queries. For example, if you were creating a report containing the fees paid by Customers, it would be possible to introduce a computed field where the fees were added together, giving the total fees paid.

Example

Figure 1: Microsoft Access report in Design View showing calculated fields

Below are some examples of different calculations that can be performed in Microsoft Access and their meanings.

Calculation / Meaning
=[Subtotal] + [Delivery] / The sum of the values of the Subtotal and Delivery fields
=[DueDate]—[InvoiceDate] / The difference between the values of the DueDate and InvoiceDate fields
=IIf([Confirmed] = ‘Yes’, ‘Order Confirmed’, ‘Order Not Confirmed’) / Displays the message ‘Order Confirmed’ if the value of the Confirmed field is Yes; otherwise, it displays the message ‘Order Not Confirmed’
=Sum([Fee]) / Uses the Sum function to display the sum of the values of the Fee field

Group totals

Where items in a report are grouped, it is often convenient to include in the footer of a group a total of a particular field for each group. For example, if you had a report containing orders and order lines, with a total price for each order line, then you could include a group total which gives the total price for the order.

Example

In Microsoft Access you click on View (Sorting and Grouping) or the button on the toolbar.

Figure 2: Microsoft Access report — Sorting and Grouping Options

Practice

Use the Internet or built-in help menus to find out how to change the properties of an object on a form and report with the software package you are using. To practice, change the background colour of a text box on your form.

Toolbars

Depending on which application you are using, you can make changes to the toolbars and create special customised toolbars for your client.

Most users never make any changes to the toolbars provided. However, it’s very easy to remove toolbar buttons which you never use and replace them with buttons for commands which you do use. Also, when you develop your own macros, you might like to run these from your own personally-designed toolbar buttons. You can have several, if you like, each with a set of buttons for specific tasks. You can also decide which toolbars you want displayed at any time and can change their position on the screen.

You can tailor the user environment with customised toolbars by:

• adding new toolbars to the taskbar.
• adding new buttons to toolbars.
• changing the order in which the buttons appear.
• removing buttons and toolbars that you don’t need.

By creating customised toolbars you can remove unnecessary features and add additional features to enhance the application. This has several benefits such as:

• easier for the end user to learn
• end-users are less likely to access features of the program that they do not require (and that the developer would rather they didn’t)!
• better navigation through the system.

You will need to understand the way the end-user uses software programs to best design toolbars to suit their needs. Not all end users can use a mouse, and some simply prefer not to. Make sure wherever possible in your application, you include keyboard shortcuts. In many applications such as Microsoft Office Applications, this can be done by using the ampersand(&) symbol before the letter you wish to use as the short cut.Below is an example of a customised toolbar containing only buttons and commands necessary to using the customised application:

Figure 3: A customised toolbar

Example

In the Microsoft Office Suite you can customise toolbars by selecting Customise from the Tools menu. The Customise window gives you the options to create new or modify existing toolbars and commands.

Figure 4: The Customise window in Microsoft Office Suite

Investigate

Use the Internet or built-in Help menus to find out how to do this in your database application.

Creating menu systems

Automating the StartUp

If you want to make using the customised application easy for the users, it is a good idea to have the menu form open automatically when the database is opened. A shortcut to the application can then be placed on the desktop. You will need to check what features are available in the software application you are using. There are several ways of opening a form or carrying out other actions when the database starts.

Example

In Microsoft Access the most common way is to set the Startup Form property in the Startup Dialog box. It is opened from Startup in the Tools menu.

Figure 5: Startup Dialog Box in Microsoft Access

The form you want to use as your main menu can be selected from the dropdown box Display Form/Page.

Alternatively in Microsoft Access, you can create a macro that opens a form and any other actions that you want to carry out when the file is first opened. These are named as AutoExec. This allows you to include additional actions whenever the file is opened. Be careful not open a form in both the Startup dialogue window and the AutoExec macro. The AutoExec macro is run after the startup properties and overwrites it.

Microsoft Access also has a built in tool for creating menu systems, which is called the Switchboard Manager. Click on Tools / Database utilities / Switchboard Manager. You can have as many switchboard pages as you need in the application, and as with all aspects of your customised application it is a good idea to plan the design first. Once you have given the switchboard a name, by clicking on Edit you can add items to it — for example, a button to open a form or a button to exit the application.

Investigate

Take the time now to examine the database software that you have chosen to use, and find out what tools are available to help create the menu system for the customised application. You might try using the Help menu or search the Internet to find out what is available.

Testing and client feedback

Every object such as tables, forms, queries or reports, which are created in the database, must be tested thoroughly. Testing a database system is a vast topic, indeed a subject on its own. The first stage for you as the software developer is to test the application before handing it over to the client. It’s also a good idea to get somebody unfamiliar with the application to use it and enter data. Because you are familiar with the design you will know how it should be entered — unlike somebody that hasn’t used it before. This is a great way of finding potential problems.

Test data should be designed according to the purpose of the customised application. The aim of most software customisations is to develop an application which allows quick and easy data entry and minimises the possibility of data entry error.You should consider the following issues when designing test data:

• Test data should verify the correct operation of completed components of the database. Data used must test each component and help to identify any design errors overlooked in earlier stages of the customisation. Test data should also identify all possible limitations of our design. That is, it should show us how the tested component will respond to incorrect data entry, such as data out of the defined range, entry of an incorrect data type and missing data.
• Entering test data should identify any system limitations related to entering data. For example, if the data value to be entered into a field is within a small range of possible entries, then a lookup combo box or a list box with pre-set data values to choose from will be a good option to make the software more user friendly. For example for a field in a table which records addresses, the field for ‘State’ could be a drop down box containing QLD, NSW, ACT, VIC, TAS, SA, WA, and NT.
• Many people have good keyboarding skills and avoid using a mouse whenever possible. You need to test whether our application allows keyboard only data entry for this type of user, and that tab orders have been set correctly.
• Another technique to help data entry and reduce the possibility of a data entry error is to use default values. They appear in every record, unless it is replaced by a different value entered by the user.

After the new system is installed, an acceptance and handover procedure occurs. This involves the user being satisfied that the project has been successful and accepting the software for use. It can involve a testing process where users formally accept the new system, or it may be an informal acceptance. Quality customer service is one of the most important attributes of any successful project. It ensures the client is gaining confidence with the new system and using it to its full capabilities.

Post implementation reviews are an important way of ensuring the client is satisfied with the product and that the product or system is functioning as intended. A post implementation review is conducted after the hand over of the system. It consists of a questionnaires and interviews to staff members, to analyse how the system is performing and the levels of user acceptance.

Questionnaires and interviews can be carried out with staff identified as key users of the system. The results of the review are analysed for evaluation. A meeting takes place to discuss the findings of the review. From the results of the review key stakeholders will be able to identify any new issues or further action that may need to take place.

Testing process overview

The testing process can be summarised into the following stages:

1Testing

• Test each component of the new system thoroughly.

2Handover

• System delivered to client & installed
• Conversion of old system (transferring data if necessary)
• User training
• System used in ‘normal’ operational setting

3Amend the system according to client requirements

• Post implementation review — may lead to further modifications
• Continuing use may lead to or identify further enhancements or changes

4Obtain client agreement — sign off

Amending to meet client requirements

During the testing period some limitations and errors in the system will be discovered. You will be able to correct them quickly after they are reported. However, during the same period, your client may discover many new possibilities for the customised software. Some of these new requirements will be easy to add to the existing system. Others may require a system redesign and can be difficult to implement. Any new changes may have an impact on the existing system and need to be analysed before implementation.

For example, if the client wants to add new information which could be added as a field to a table or a new table in the database, such changes may not have a big impact on the front end. However, if the client requires changes which alter the existing relationship between tables, then such a change may have a huge impact on the front-end section of the database. The amount of work which will be required to redesign a collection of forms, queries and reports may make the suggested changes not feasible to implement.