Software Review

Software review is an extremely important technique used to assure the quality, functionality, and other features of your software. Unlike many of the other techniques for assuring quality that I have talked about in this blog, software review doesn’t follow an exact formula or a standard. I believe it gives you more freedom and in many cases depends on the person coding and the reviewer. What software reviews enable is the opportunity for people in your team to test your code and tell you of possible errors, improvements, etc.

Some of the most common software review practices include:

  • Code review: Systematic examination of the source code used to fix mistakes and remove vulnerabilities.
  • Pair Programming: In this type of code review, two programmers work together on one workstation and develop code. More people working in one piece of code enables the opportunity to bring up ideas that only one person might not have and gives more than one point of view for solving problems which is always good.
  • Walkthrough: For this review, a developer leads a team of software developers to go through a software product. Questions are asked and necessary comments are made about defects and errors.
  • Technical review: A technical review is more formal, qualified personnel review the software product and examine if its suitable enough for its intended use.
  • Inspection: This is another formal type of peer review in which experienced and qualified individuals examine software for bugs and defects using a defined process.

These were mainly software peer review techniques, there are other types of reviews used in later stages by management representatives. They are mainly used to evaluate work status and decisions regarding downstream activities are taken from there.

One final type of review I will talk about is audit reviews. These are external reviews in which one or more auditors that are not from the development team conduct an independent examination of your software product. Done by managerial level people.

A software product is not only comprised by code but includes everything related to the product itself like plans, requirements, design, etc. What I explained above is mainly focused on code review but there are also techniques you can use to review all the other key work products in your software. What is important to understand is that reviews will always (or at least should) come from people from that specific area that is being reviewed. You can’t ask someone from the design team to review someone’s back-end code. So reviewing these other key components of a software product is pretty much the same. Although I am sure there are other specific types of reviews, standards and techniques used to review them, the basic idea is to have someone else to help you find errors and improvements. Reviews don’t have to be as specific or strict as they are described above. A designer might have no use for “pair programming” but taking the core idea and using it from a design perspective would mean having someone help you design your software and make decisions as you start thinking about solutions for the product. Another example are technical reviews, people focused on the budget area might want to review your budget plan before moving forward. Does the fact that it doesn’t have code make it different from the technical review I talked about earlier? Not really, the core ideas are the same.

In conclusion, software reviews are extremely important when it comes to fixing errors and helping improve your software. They are not limited to code and the basic idea of most if not all the reviews can be translated into other areas to make sure that you are producing software to the best of you and your company’s ability.

External links:

Software review

Models and Standards

In a past blog I talked about software quality and how we can define it. Tl;dr quality depends on what the company and/or programmers believe is quality. Everyone will have a different vision of quality, but today we will talk about models and standards. Software quality models were created to solve this ambiguity problem. With them, we can standardize the measuring of software so that we know the quality of our product. Now I will talk about some models and explain what their purpose is.

CMMI: Standing for Capability Maturity Model Integration, CMMI itself is an institute which provides several different software quality models focused on different points. For example, there is a model focused on the development of quality software products, one focused on services, and more. What the CMMI institute claims is that many companies and organizations do not have a process to measure their capabilities against best practices, meaning that they can’t see which capabilities are giving the best performance and which ones should be improved. When you know the capabilities of your organization you can bring many benefits not only to the customers of the products they create, but also to company and the employees themselves.

TSP/PSP: Team Software Process (TSP) and Personal Software Process (PSP) can be used to help organization teams be self-directed and make them better at planning, tracking, establishing goals, and owning their processes and plans. TSP itself is meant to guide engineering teams through the development of software products and it helps the organizations establish good engineering practice. PSP is focused on a personal framework for engineers in a software developing context. This model was created by the Software Engineering Institute at Carnegie Mellon University.

ISO-15504: The ISO-15504 is an international standard for software process improvement capability determination. This is yet another model to help organizations measure their capabilities when developing software products. Similar to the CMMI, its purpose is to set a standard for software process evaluation and let the organization evaluate their current performance. It has a set of requirements to evaluate the processes of an organization which can be generalized into: process evaluation, process improvement, and evaluation of the capacity/maturity of processes.

MOPROSOFT: MOPROSOFT is said to be an easy to understand and adopt model which is more practical than other standards thanks to its shorter length. It is also meant to facilitate the fulfillment of requirements from other models, including the ISO-15504. This model is better for organizations with the structure used in Mexico for software development and maintenance. It also provides a low cost solution for organizations and can be either established from zero or adapted in case the organization already had established processes beforehand.

IDEAL method: The IDEAL method does not refer to a software quality model, but rather a decision making tool to help you look at a scenario from an objective perspective and define the problem and explore solutions. Its purpose is to set emotion aside and make the process of decision making action drive, all while reducing the fear and anxiety of taking a decision, encouraging thinking, and being easy to use for everybody. IDEAL stands for the set of steps that one must follow in order to use this method effectively. First you must Identify the problem, then Define your goals, after that you can start Exploring solutions to later Act on it, and finally, Look back. This method can be used in many contexts, not just the software quality field and will help you improve life decisions when used correctly.

These models have different standards and qualities to help you measure and improve the process and quality of your software developing organization. Choosing one will be up to you based on your needs and goals. This was only a brief summary of each of them so I recommend you investigate more about each one (and any others that weren’t listed here) before deciding which you want to use.

External links:

Software Quality Models

CMMI

TSP/PSP

ISO-15504

MOPROSOFT

IDEAL method

Defining Software Quality

Assuring product quality is crucial for every serious business. The problem with software is that it is harder to define quality than it is with physical products. Let’s take a shirt for example. How can we say that a shirt is of good quality? Well our shirt is comfortable, it’s durable, and it has a good design. Of course we could go into more thorough details like “the fabric was made with only the best of cotton which came from plants grown in the optimal coordinates with the perfect temperature and amounts of water” but we don’t need all of that to say that our shirt is of good quality. So, what makes good quality software? Is it the design of the software? Is it the speed at which the software operates or how reliable it is? And is it possible for software to have all of these qualities?

The first thing we need to understand to answer these questions is that every company, regardless on what product they make, will have a different definition of quality. This doesn’t mean we can’t have common key concepts for defining quality. Among the most popular ones are:

  • Design
  • Functionality
  • Reliability
  • Consistency
  • Durability

But of course, many others exist.

Image taken from asq.org

Let me say this right now, no piece of software will ever be perfect. You can try to excel at all of the qualities of software, but ultimately, it is impossible to not have any flaws. The importance of each will vary greatly depending on what exactly you are trying to provide to your customers and what the purpose of the software is. Focusing on what you want the end product to be could become dangerous and counterproductive. When you focus on the process rather than the result, you get more control out of what you have right now, you get to experiment, and it will put aside things that may distract you from what you are currently doing. Why bother stressing over something you haven’t even gotten to yet when you could be giving all your attention to the process that’s currently going on.

Now that we have accepted the reality and know that no software will be perfect and that we should focus on what we have and what we are doing rather than what we want in the future, we still must answer the question, how can we assure quality in software? As stated before, we must have knowledge of what we want the purpose of our software to be. Is it supposed to help people complete work tasks? Then maybe we should focus on functionality and reliability. Is the software an entertainment mean for the general public? Then design and functionality could take a higher priority than the other qualities. Once you know this, deciding whether or not your software is of good quality becomes much easier.

For those who are still unconvinced or unsure as to what quality in software means, I have good news for you. Thankfully, people have asked themselves these questions for many years, that’s why they decided to create standards. Standards exist to make our lives easier when checking for quality in software. Several standards exist and it is up to you to decide which suits your idea better to use as a guideline for ensuring quality. I will be talking more about these standards and their purpose in another blog post.

External links used:

What is Software Quality?

Focus on process, not outcome

Software Quality Standards