ICS 121: Software Qualities

Overview

Why review qualities?
External qualities
- Functionality
- Usablity
- Conformance
- Reliability and performance
Internal qualities
- Process mesasurements
- Maintainability

Why Review Qualities?

You covered software qualities in ics52
You need to keep them in mind as we talk about software development methods.
The qualities of the method influence the qualities of the product.

External Qualities > Functionality

Correctness: Correctness is the most basic quality goal. It means that, when valid inputs are given and the system is in a valid state and under reasonable load, the system's behavior and results will be correct.
Robustness: Robustness is the system's ability to gracefully handle invalid inputs. It should never be possible for any user input to crash the system or corrupt data, even if that user input is abnormal, unexpected, or malicious.
Accuracy: Accuracy refers to the mathematical precision of calculations done by the system. Any system that does numeric calculations must consider accuracy, e.g., financial or scientific applications.
Factual correctness: The data in the system should be a true representation of the real world. Any system that contains initial data or gathers data about the real world should be sure that the data is factually correct. E.g., a tax preparation program should embody correct and up-to-date facts about tax law.

External Qualities > Usability

Understandability: Users need to understand the system to use it. The basic metaphor should be understandable and appropriate to user tasks. Some defects in understandability include unclear metaphors, poor or hard-to-see labels, lack of feedback to confirm the effects of user actions, and missing or inadequate on-line help.
Accessibility: Not all human users have the same physical abilities. Some people are near-sighted, colorblind, blind, or deaf. Accessibility is the quality that allows a software product to serve handicaped users. However, many accessibility features are useful to fully-able users too. E.g., web page layout that works well with a wide range of font sizes. E.g., logically structured HTML or dialog boxes that make sense to a screen-reader utility. The U.S. Government now requires accessibilty features in software that it purchases.
Learnability and Memorability: Every user interface contains some details that users will need to learn and remember. E.g., Alt-F to open the "File" menu. UI cues and rules can make these details easier to learn and remember. E.g., the "F" is underlined and, as a rule, the first letter is usually the accelerator key.
Task support: This is the quality of match between user tasks and the system's UI. Task support defects are cases where the system forces the user to take unnatural steps to accomplish a task or where the user is given no support for a difficult step in a task. E.g., must the user invent an 8-character filename for their "Christmas card list"? E.g., must users total their own tax deductions?
Efficiency: Users should be able to accomplish common tasks with reasonable effort. Common tasks should be possible with only one or two steps. The difficulty of each step should also be considered. E.g., does the user have to remember a long code number or click on a very small button?
Safety: Humans are error-prone, but the negative effects of common errors should be limited. E.g., users should realize that a given command will delete data, and be asked to confirm their intent or have the option to undo.
Consistency and Familiarity: Users should be able to apply their past experience from other similar systems. This means that user interface standards should be followed, and common conventions should be used whenever possible. Also, UI elements that appear in several parts of the UI should be used consistently, unless another UI quality takes priority. E.g., if most currency entry fields do not require a dollar-sign, then one that does demand it is a consistency defect, unless there is a real chance that the user is dealing with another currency on that step in his/her task.
Subjective satisfaction: Users should feel generally satisfied with the UI. This is a subjective quality that sums up the other user interface qualities as well as aesthetics.

External Qualities > Conformance

Compatibility: Systems that claim to follow standards or claim compatibility with existing systems must adhere to the relevant file formats, protocols, and APIs. It is especially important to be compatabile with previous versions of the same product and other products from the same vendor.
Portability: Systems that claim portability must run on multiple operating systems and hardware platforms. This is usually achieved by compatability with standards and with layers of abstraction in the design.

External Qualities > Reliability and Performance

Security: The system should allow usage only by authorized users, and restrict usage based on permissions. The system should not allow users to side-step security rule or exploit security holes. E.g., all user input should be validated and any malicious input should be rejected.
Consistency under load: Every system has some capacity limits. What happens when those limits are exceeded? The system should never lose or corrupt data.
Consistency under concurrency: Systems that allow concurrent access by multiple users, or that use concurrency internally, should be free of race conditions and deadlock.
Availability under load: Every system has some capacity limits. What happens when those limits are exceeded? The system should continue to service those requests that it is capable of handling. It should not crash or stop processing all requests.
Longevity: The system should continue to operate as long as it is needed. It should not gradually use up a limited resource. Example longevity defects include memory leaks or filling the disk with log files.
Efficiency: The system's operations should execute quickly, with reasonable use of machine and network resources. E.g., if one user does one operation, it should execute efficiently.
Scalability: Scalability is a general quality that holds when the system continues to satisfy its requirements when various usage parameters are increased. E.g., a file server might be scalable to a high number of users, or to very large files or very high capacity disks. Several specific scalability goals are listed below.
Scalability > Performance under load: This is a specific type of scalability goal dealing with the performance of the system at times when it is servicing many requests from many users.
Scalability > Large data volume: This is a specific type of scalability goal dealing with the ability for the system to handle large data sets. Operations should continue to be correct and efficient as data set size increases. Furthermore, the user interface should still be usable as the data presented to users increases in length.

Internal Qualities > Process Measurements

Productivity: Productivity is the amount of resulting product that is produced by an average unit of developer effort. How quickly and efficently can the system be developed? Are developers able to make forward progress or are they spending all their time on process overhead or rework?
Reuse: Reuse is the measure of assets used in this project that were constructed in past projects or purchased. Has the team looked for reusable components? Are artifacts other than code being considered for reuse (e.g., design patterns, code generators, test suites, user interface designs, etc.)? Is reuse being considered for each project individually or is there a plan to increase reuse across a product-line or throughout the organization?
Reusability: Reusability is the measure of assets created in this project that are likely to be reused later. Has the team looked for or talked to potential reusers? Are artifacts other than code being considered for reuse (e.g., design patterns, code generators, test suites, user interface designs, etc.)? Is reuse being considered for each project individually or is there a plan to increase reuse across a product-line or throughout the organization?
Process Reliability: A reliable process is sure to produce the desired results every time it is carried out. In contrast, an unreliable process works sometimes and not others. For example, depending on one super-programmer is not a reliable process. Reliable processes often have checks and balances and ways to detect problems and recover from them.
Time to Market: Time to market is the measure of how much calendar time is needed to produce a release. Would the company make more money if the product got to market faster? Usually that is the case. Faster time to market depends on productivity, but also on allowing many resources to work in parallel, and without substantial rework that would lengthen the critical path. Often this parallelism means that vendors, developers, contractors, partners, integrators, and customers need to work together rather than waiting for one organization to produce a finished product for the next organization to pick up.

Internal Qualities > Maintainability

Operability: The long-term needs of system administrators should be reliably supported. E.g., is the system easy to install? Can the administrator recover from a crash? Is there sufficient log output to diagnose problems in the field? Can the system's data be backed up without downtime? Can the system be upgraded practically?
Understandability: Will it be easy for (future) developers to understand how the system works?
Evolvability: Can the system easily be modified and extended over time? Does the design have fetures that allow plug-ins, subclassing, or other managable extensions? If part of the system is changed, is the work needed proportional to the magnitude of the change rather than the overall size of the system? Can individual components evolve without demanding complete retesting and repackaging of every component?
Testability: Can the system easily be tested? Do the requirements precisely specify possible inputs and the desired results? Can the system be tested in parts? When failures are observed, can they be traced back to defects in specific components (i.e., debugging)? Is testing practical with the available testing tools?