How to analyze a software application for weaknesses and come up with a plan to stabilize it?

Since this is a very wide-ranging question, I will narrow it down to the range of mobile applications that are most relevant to the example chosen here, which is a mobile medical records application. To start with, let’s consider the following scenario:

a)   A tablet-based application with a Windows-based user interface.

This is essentially a Windows application, but which allows the user the convenience of a pen- based interface. Let’s assume that the pen based interface works fine. Then, from a technical perspective, the present analysis can mostly focus on whether the application meets the user’s business requirements and on how well it performs.

Firstly, the performance is irrelevant if the application does not meet the needs of the user! Therefore, here are some questions to ponder:

•     Does the weakness that we are considering stem from an inability to meet these requirements?

•     Do we have clearly documented business and/or functional requirements to refer back to?

•     Was the correlation between requirements and functionality meticulously tracked during analysis, design and development?

•     Do we have documented Use Cases to explain the appropriate role playing for this application?

If we did our jobs properly in the first place, then the answer to all of these questions is “yes” and then we can simply match up the actual functionality to the business requirements. This should allow us to determine where the weakness lies and how to address it.

However, to make this more interesting, let’s assume now that we’re dealing with a legacy system that was ported by the company to a mobile application. In that case, we may be dealing with a system that has no proper documentation to refer to.

Here is where proper quality assurance comes into play! Since we’re assuming that the normal process of rigorous testing was never done on the original app, it becomes incumbent upon our intrepid QA person/people to test the heck out of it, in order to determine where it breaks.

That’s the first step in pinpointing where the app is weak, if we have no specs to refer back to. If we do have specs then the task is much easier, but the principle of using rigorous testing to determine when it breaks still applies.

Likewise, if feedback from the users was not part of the development process (which it would have been if we using an Agile methodology!!!), then it is essential to get that feedback now. In other words, if people are already using the app, then we need to know exactly when/how it does or does not meet their needs.

Again, I must emphasize that this should have happened before the app was released, but failing that, let’s get this input now. This will lead to a set of functional requirements that can then be compared with the test results for our QA staff. Essentially the take home message here is this: a combined effort by the analysts, designers, developers and QA staff results in an application that has no surprises. Ideally this would happen before release, but better late than never!

Once all of this has been done, then we can fix the bugs and/or enhance the product, as needed. At this point we know what it actually does versus what it should do, such that it is now a straightforward process to determine what needs to be done in order to stabilize it (i.e. it’s understood that we’re including bug tracking as a subset of this whole process).

Of course, now we come to the ubiquitous issues of maintenance, such as:

•     How long will it take?

•     How much will it cost?

•     Who will do the work?

•     Who will pay for it/

•     When will it be done?

Sorry to sound like broken record, but once again Agile development comes to the rescue here. After all, fixing or enhancing an app is just a microcosm of the original, overall development process. Thus, the same principles apply:

•     Address any unknown/risky issues first

•     Get constant feedback from the users

•     Ensure effective communication within the dev team, to identify/address problems early

•     Release small, frequent iterations

•     Test constantly!

b)   How corporate strategy directly affects this situation

Another important consideration here is, “What are the relevant apps of our competitors doing?” Thus the above process should also take into account whatever the competition currently does and whether our product is up to snuff.

Indeed, it may even be that the competition has recently added features that make the latest release of our app obsolete! In that case, our app may work just fine and yet still have a significant weakness. Similarly, the technology behind the app must constantly be re-evaluated, with respect to what is currently available “out there”.

The best designed and implemented app in the world may become useless if the technology is

no longer appropriate (e.g. the Yellow Pages). So, this suggests that s/w development should not stand alone: marketing, strategy, product management and other factors need to be considered as well.

The most effective way to ensure that this occurs is to create a system of overlapping competencies, so that all the bases are covered by more than one individual (i.e. like baseball players backing each other up on the field). This requires us to foster an atmosphere of “covering each other’s backs”, as opposed to “looking over each other’s shoulders”. There’s a subtle but critical difference between the two approaches!

Hence, for example, we should have the product manager involved in quality assurance, the development team leader concerned about business management, the chief technology officer wondering about corporate strategy, and so on. Since that appears to be the case already, then the challenge is to propagate this mentality going forward, as we grow.

This leads to two further questions, right off the bat:

•     How do we maintain the sense of family/mutual assistance as we grow from a small to medium to large company?

•     Why hasn’t this company grown more since its inception?

These are tough questions that are best addressed when we meet. However, I will say this here: if we can’t maintain a congenial atmosphere, then the issue of growth becomes moot (unless we want to become just another big, impersonal corporation).

Conversely, that growth may have been inhibited (intentionally or otherwise) by a desire to maintain that atmosphere. In that case, since our products and the related market are both clearly conducive to growth, then the challenge is clear (which is where I come in!).

c)   Addressing the above scenario with apps developed for more specialized devices, such as the

Blackberry, iPhone or iPad

This issue is also beyond the scope of the present discussion and thus best addressed when we meet, but a few quick notes are appropriate here:

•     How do we address potential problems with proprietary software? By the way, this also applies to the use of products from potential partners (e.g. Procura, Qualicode and Motion Computing).

•     What tools are available to diagnose potential hardware problems that can affect our software products? As trusted partners of RIM, do we have complete access to their diagnostic tools? Similarly, what if the initial assumption above was invalid and the pen based interface was actually the problem – what tools does Motion Computing provide for analyzing their pad computers?

•     How relevant is the user’s perspective? Since our products are intended for various user categories (agencies, home care nurses, personal support workers), then the weaknesses in a given app may depend largely on the user’s role.

•     Is language an issue? By developing multilingual products, we expose ourselves to potential glitches that derive from the improper mapping of database objects to the application code. On the other hand, if we did/do this right, then we can just as easily accommodate ten languages as two (i.e. the relational database design should make the mapping for numerous languages as simple as for two). Qualicode is now looking to the European market – are we? What about Asia? 1

•     Why are we not developing apps for Apple products? Unless this is prohibited by one

of our partners (e.g. RIM), then what would be involved in this? Would all of the above apply if we were to develop apps for Apple products as well?

•     What is the meaning of life?

Okay, maybe that last one was just a bit of a stretch … but the answers to these and many more questions will be forthcoming over the course of our upcoming meeting(s). I’ll be that you just can’t wait!

1 Actually, it occurs to me that the 7 languages which I either speak or understand are all European … so, if you want to wait a bit to address the Asian market (until I get a chance to learn Mandarin also), then that’s okay.