Quantifying Reliability through Dynamic and Static Code Analysis

7 Comments

I have been pondering about the application reliability for a few days. Is reliability solely based on a transaction being successful, or is it tempered with an element of security as well? Generally, users will be appreciative of an application that will enable them to securely perform a transaction. So how will you retain the stakeholder confidence regarding application security and reliability? There are many parameters while talking about the security of the application but in this context I would only like to point to the static and the dynamic code analysis. My experiences were mostly around measuring the reliability of a software application based on the dynamic code analysis. The dynamic code analysis leverages the instrumentation data captured at application runtime exposing the vulnerabilities at runtime. It is achieved by running a set of pre-defined test cases which are again limited by the stakeholders’ perceptions. Though the dynamic code analysis helps build the stakeholder confidence, it is not comprehensive. Inorder to evaluate a software application for reliability we need a more holistic approach and can be achieved by complementing the dynamic code analysis with static code analysis. The static code analysis is a source code or byte code analysis of a software application. Though inherently complex, it carries weight since it can be implemented early on and iteratively in the SDLC. Through that iterative process at a certain point when a usable product of small scale is ready to be put to test at run-time (dynamic code analysis), the data gathered can be used to further analyze the static code and vice-versa. The data thus harnessed can be used to remediate the current and future issues of security and performance long before the product is available to the end user. I am emphasizing on the pro-active approach of tackling the issues than being reactive. Although a reliability of 100% would be ideal, I would instill some doubt on the performance of the application because no matter how smart an application design is, there is someone smarter out there to challenge it. Only continuous verification and validation is the key to maintaining an optimum level of user satisfaction and productivity. This in turn would verify the rate of successful transactions that can be quantified as the reliability factor.

7 thoughts on “Quantifying Reliability through Dynamic and Static Code Analysis”

  1. Thank you Chetana for your reply!
    That makes sense why you don’t use time spent in each method. because in my work I simulate the software architecture in order to estimate its reliability I need to analyze the time spent in each class/layer too. In my thesis I am working on performance and reliability of application server and web services and that’s good that I see somebody use these stuffs in real work!

    Your blog presents some worthwhile information and I really liked reading them.
    Please keep up your good work!

    Thanks again.

    p.s. I also write a blog for my daughter and I liked the idea of SMILES blog :)

  2. Hi,
    I really enjoyed reading this post. I have a question and I really appreciate if you leave me a line for this.

    What kind of dynamic code analysis output you use to quantify the reliability factor? Do you use time spent in each class/method? Do you use the number of failure happened in each class/method under different test cases? Or do you inspect the overall architecture of software by looking the run-time call graph?

    Thank you for any comments you can provide.
    Best Regards.

    1. Hello Mariam,
      In response to your questions:

      What kind of dynamic code analysis output you use to quantify the reliability factor?
      We use the count of the successful process outputs to derive the reliability factor.

      Do you use time spent in each class/method?
      No. We look at the desired outputs for a specific method call based on the input descriptors.

      Do you use the number of failure happened in each class/method under different test cases?
      Yes

      Or do you inspect the overall architecture of software by looking the run-time call graph?
      I personally do not inspect the architecture but the process outputs gathered from the call graph definitely have the capacity to influence the overall architecture.

Leave a Reply

Your email address will not be published. Required fields are marked *