Activities Involving a Localized Application

When comes to localize an application or website, most of us will think only on the contents to suit the local language.  In fact, there are lots of areas to take care of and there are factors to determine how much we can localize or change the application or website.

Basic areas to change:

1. Labels
2. Action Buttons
3. Navigation buttons/links
4. Client validation messages
5. Error messages (static or dynamic)
6. Quick links
7. Input boxes

Factors to determine localizations/changes:

• Field lengths – for the specific context, grids, table what is the maximum field length of the affected text to fit the local language’s text.
• Layout of the page – if the context is too long, how it will affect the user experience.  Example on the main page, should it not be too long to allow the user to scroll up/down on the screen to read the contents.
• Search capability – the application is able to search by the local language characters.
• Sorting capability – the application is able to sort in ascending or descending order based on the local language.

Hints to Complete Functional Specification Document

Ever experience we can’t finish to get the Customers to agree or sign-off the functional specifications as per planned and instead, it is getting longer and having more details?  In today’s business world, customers are no longer as “dumb” as most IT professionals are thinking of.  With technology advance and lots of training and courses on IT business technology, they are getting to know what they want to get for their projects or products development so that they don’t feel the suppliers are hiding any information.

The above may be true but it may not be necessary to cover everything during user requirement gathering.  This is still a preliminary stage to understand the business flows, expectations and user experiences for the software applications or products and hence put the project schedule on risk if unable to sign-off the requirements to move on to design and development stages.

With that in mind, we can prepare ourselves upfront by anticipating what they are looking for.  Below are the items I have experience and like to share on what to take note of when preparing the sign-off.

1. Use case diagrams – Do not put in too much details e.g. the default selections, exception handling or else it will be too long and it became a technical design flows rather than user flow.
2. Use Cases – no technical details on the functionality.  In most cases, certain level of technical information must be included and defined for the requirement.  If to the stage whereby unable to assess the technical aspect of the requirement,  we will indicate for that requirement’s feasibility will be reviewed during design phase.
3. Screenshots – indicate that wireframes, user interfaces of the software are for illustration purposes.
4. Messages/labels -which are static (labels) and dynamics (normally error or warning messages) to be shorten or rename.  Also to note for any language translations
5. Field lengths – The length, field type (i.e. integer, double, string), default value (if any).  These information mainly covers for input fields.
6. Document layout – make sure to print out the document and ensure the contents can be viewed and aligned correctly.

SCRUM – Developing User Stories for Iterative Development

Last 5 months, I have exposed to SCRUM software development methodology and with my experiences on implementing software projects this methodology works very well to the traditional waterfall model.

In today’s business world, companies are working and analysing consumers’ behaviors and to drive for high quality, productivity applications/products.  This results in having to provide ‘move to market’ products as soon as possible.

Agile development helps in this way.  For example, I am working on a rich client mobile app and to move into this competition, the product has to launch in a short period of time.  In software development, user requirements and coming up with functional specification document is the part that make up most of the development timeline.  Customer wants to speed up development so that they have more time for conducting user acceptance testing.  The technical project manager wants to finalize and sign-off the functional specification document so that the project team can work on the confirmed requirements and target any scope creep along the design and development phases.

1. Develop user stories – gives stand-up and walk-through of each user requirement, on the user flows and expectation of the outputs.

2. Solutioning - develop the functional requirements to achieve the outputs.  Document into the functional specification, review and sign-off.

3. The cycle continues by going back to step 1 with the new user story.  Identify any dependencies and review the user flows from previous functional specification.

By the above method, we are able to get thing moving in a win-win situation.

Basic Requirements for Developing Mobile Banking Apps

With the popularity of iPhone, Android or any smartphones, there is demand of doing online updates of profiles or transactions on the run.

When comes to designing the user interface and recommending the  functionality for mobile banking, we have to remember that there are limitations to the amount of contents, features, not to mention the types of transactions allowed and the encryption logic to use.  One important note for developing mobile apps for online transactions is not to allow caching or to store unnecessary user profile and date inside the smartphone’s memory.

Below are the basic recommendation for consumers’ needs in performing banking activities on-the-go:

Login	Accounts	Transfer	Payment	Settings	Miscellaneous
2FA	Account Summary	Immediate/Future Funds Transfer to My Account	Add to My Payee	Application version display	Maintenance Page
SMS content in app	Account Details	Immediate/Future Funds Transfer to Another Account	Immediate/Future Bill Payment to Prearranged Payees	Language change	App update screen
SMS regenerating	Transaction History	Immediate/Future Funds Transfer to Other Bank Account	One Time Payment		Error Screen
Flash SMS		Schedule Transfer Summary View/Amend/Cancel	Schedule Payment Summary View/Amend/Cancel		Logout
Terms and conditions					Contact US
Language switch					Idle Session Timeout
Home Screen

Back To Work On Blog!!!!!!!

It has been a long 6 month’s break from updating this blog!  Firstly I was busy with my new job role as a business analyst on banking projects since October 2010 and just came back from a month’s sabbatical break in south america.

I will keep posting on the interesting experiences on the banking projects I am doing right now, especially to touch base on mobile banking and other mobile computing technologies.

Stay tuned for more geek!

RE: EDI X12 Byte Space limitation – Project On Hold

As we are trying to solve this issue, we got an update from the customer that the project is on hold due to their resources’ priority on their internal system’s upgrade. Further to that, that upgrade is a dependence to this current project and there may be new changes after the completion.

That’s all for this project. I am doing my documentation to close up where we are.

EDI X12 Byte Space limitation

For one month, we have contents in EDI files sent to us with ‘broken lines’.  This results in some purchase order details in the file unable to process further or missing information being sent back as in 861 EDI.

We have to investigate the problem, starting from the actual inbound file or also known as the ‘raw file’ from Customer.  From our implementation, we have to process this file in 2 stages:

• Stage one: The system performs conversion of hex char (CR/LF) from raw 856 to the correct hex char (LF), re-generated 856.  This is the initial issue from Customer’s system which unable to resolve the extra ‘CR’ character from the file and this has to be manipulated at our side to allow the files to get through our system successfully before performing data mapping to respective outputs for our back-end systems.
• Stage two: The processed 856 is used for actual data translations into the respective output files to back-end systems

We faced the issue that at certain row(s) of the record, it got broken and there is a CR that caused it.  It seems like 2 files (of different ISA control numbers) have the same proble identified at the same record/row.  We also realized a pattern in which for every 4 kbytes of records in that file, CR is being included.  To investigate this to ensure if this is a system problem at our end, we requested the customer to send more similar file type that have more or less 4 kbytes of records to see if our analysis is correct.

We will find out more in the next few days.   Watch out this space for findings.

EDI Mapping Process – From requirements to concept

Like all other software development, we are to cover the requirements and determine the expected outputs of the EDI structures

1.  Gather the EDI input and output files requirements

• Input EDI segments and structures for the various scenarios
• Data mapping from the source EDI file to required EDI output files.
• Ensure the right information is mapped to the correct segments.
• Layouts of the mapped values e.g. for numeric values, the value to start from left-to-right positioning.

2.  Determine the data mappings’ values from the input file to outputs  files.

• Ensure maximum nos of fields and spaces required for output files from source file’s values.  These values are the ones that need to pass back to output files.
• Ensure correct values are mapped correctly to the output files.
• Derive the logic to extract the required values to map to the output files

Testing Web service Requests Performance

What do you know about web services testing? In simple words, this is also refer to internet connectivity testing, to ensure both sites (point A to point B) are linked up and able to transmit electronic messages over an unsecured or secure channel.

There are tools available to conduct web services testing automatically.  Tools like SOAP, a valid WDSL file, HTTP get/post are some of those tools that most engineers use.

In all web applications’ design, page loading performance is the key factor not to be neglected.  Imagine you have hundreds of users accessing a single web server to get their requests send back to their browsers all at the same time.  How will the web server able to sustain the same response time to not just one requests, but to the hundreds and not to mention some of them from this group are requesting the same information.

This is how you can start off a ‘simple testing’ to understand the current web server’s request loading performance by creating a manual test script.

• Using JMeter,  at the number of threads to send to the web server.  The number of threads represents the number of users accessing the web server.
• Add the web service request that you need to perform this testing.  The web requests are also refer to the requests that users (threads) access to to understand the request loading’s response times back to the clients.
• Add a report tool that allows you to capture all the web requests’ calls to and fro between the clients.  And this allow you to analyse the results and determine the work plan to enhance the server’s performance.

If designing a tool seems to be a tedious job to work on or due to time constraint, one way (not the best effective method) is to execute the actual, end-to-end processes from the application, to the web server and finally to the client machine.  The times taken will be based on the time a particular record from one web service call is received at the web server, the time the record is loaded into the database of the client’s application.

Common Shipments’ Updates for Freight Forwarding

Common shipment’s milestone to consider for track & trace from origin and destination hub.  They can be monitored based on Airway Bill, Commercial Invoice or Customer Purchase Order.

• Shipment Picked Up from origin hub (Shipper)
• Shipment Booked with respective carrier
• Shipment Departed/air-lifted from origin hub to carrier
• Shipment Arrived at destination port of entry
• Shipment Handover/documents released to brokers
• Shipment Custom-cleared from the destination port
• Shipment Delivered to destination hub (Consignee)