Software Quality Assurance Evaluation

WHAT is "software quality assurance" evaluation service?  [中文介紹]

We provide the technical software quality assessment according to ISO/IEC 25010 (Systems and software engineering —  Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models) on maintainability, security aspects

WHY and WHO should perform "software quality assurance" assessment?

  1. IT Technical Compliance Due Diligence, we provide technical and business opinions, we perform independents assessment on IT system and software for the company,  prior to signing a business contract, cooperation, investment, acquire, or an act with a certain standard of care, particular for investor and stakeholder.
  2. Software developer wants to know the technologies and skills used in developing the software are compliance with best practice.
  3. Buyer or Customer who wants to know the maintainability effort are fulfilled the requirements (might includes specification, financial, budget, and standards)

WHAT kind of software or system can be evaluated?

  • Embedded system software, i.e. IoT (Internet of Things), RTOS (real time operating system)...
  • Mobile apps
  • Business used system
  • others, upon request

Typical Software and System concerns in maintainability have been found

  1. File/class size, large files with too much logic should be avoided
  2. Method size, different tasks should be defined in different functions.
  3. Duplication, literal duplication of fragments of code make debugging much harder. These are typically a sign of poor maintenance
  4. Cyclomatic complexity, the number of decision points per method/function
  5. Automated unit tests, whether the source code contains test code that can be run automatically to detect regression
  6. Language specific aspects, includes deprecated functions, exception handling, and style issues 

WHAT is the evaluation process?

  1. Customer interview by assessor, in order to understand the business context and review goal, and software size and technology 
  2. Creation of project proposal. The proposal should list expected effort, times required and cost. 
  3. Signing of proposal, NDA and establish secure communication and delivery of developer documents, source code. The evaluation starts as soon as source code is received 
  4. Document review and analysis of source code. The code is investigated using automated tools. Core parts are reviewed by hand. 
  5. Interview and validation discussion with developers. The goal of this meeting is to validate that no software components are missing from the evaluation and to ask questions to the developers about any unusual findings. It might also have questions about the development process (e.g. use of tools to generate code).  
  6. Creation of near-final report. 
  7. Discussion of near-final report between local consultant and senior client. The goal of the discussion is to make sure the near-final report is clear and answers all questions from the senior client. Based on this meeting, additional clarifying text might be added to the report
  8. Delivery of final evaluation report (PDF). 

HOW to and criteria for prepare the evaluation?

  • The system should be developed in common technology. We only accept the software and IT system developed in Java, C#, Ruby on Rails, Scala, Python, C/C++, PL/SQL, PHP, Perl, with HTML, Javascript, CSS, XSLT and SQL as supporting technologies. If the system is written in another technology, we will have to check if a programming language expert is available before a proposal can be created. 
  • The system to be evaluation should have at least 6000 lines of code. This typically corresponds to at least six months of development by one developer or at least two months of development by a 2 ~ 6 developer team. If the system size is too small, the evaluation will not be effective is discovering new insight. 
  • The main parts of the code (comments, variable and function names) should be written in English. 
  • Basic developer documentation should be available. In order to understand the system, some developer documentation of a project architecture document should be available. If not, the developers should create basic documentation together with the local consultant. The documentation should describe the basic software components and their function. 
  • The system should be deployed or soon be deployed in a production environment. Part of the review consists of finding quality issues that lead to business risks. If software is only meant for research or as a prototype, the review will typically not result in the discovery of business risk. 

Software Quality Assurance Evaluation Report

  • Executive Summary
  • Business context and evaluation goal
  • Evaluation process and prerequisites 
  • Evaluation criteria 
  • Maintainability evaluation results

This service is associated with ICT Institute, Netherlands, EU    

Contact us:


Last modified: Saturday, 11 March 2017, 9:09 AM