Abstract
For the last few decades, project management and software quality management have undergone tremendous changes. This has been prompted by the constant pace of change in the information technology world, which has brought in new challenges hence calling for different solutions to the problem. This paper explores a number of approaches to software quality maintenance based on different concepts. The research adopts a critical perspective in which a number of ways of maintaining software quality are explored. It emphasizes software quality systems, as they are requisite for successful project management. It also contains a detailed coverage of the concept of quality and its measurement.
Introduction
Customers in the modern world have very high expectations concerning quality and dependability of products. They, therefore, expect the maximum of values from all organizations within the economy. This includes manufacturing companies, service companies, as well as the software sector. There is a myriad of software products in the market place, which are produced by top software development companies. Nevertheless, the duty of producing high quality software products constantly on time is not small. Repeatedly, errors are discovered in products produced by these top-of-the-league organizations. Further, on, products are shipped late due to quality problems. Such faults may result to a trivial irritation to a customer, loss of credibility for the company, or even worse, lead to injury or death.
When a product is delivered late, this leads to additional costs to the organization and may badly affect the income, productivity, or business strategy of the customer. As a result, organizations seek an infrastructure and structure for developing high-quality software every time. Despite these endeavors, there exists no silver bullet to guarantee software quality and timeliness within an organization. The only feasible solution is an increase in improvements through methodologies, tools, models, designs and requirements.
Literature Review
Debate on software quality development is not a new phenomenon in the engineering discipline. In particular, software quality management has been a thorn in the flesh for many managers and engineers. This is the process of ensuring that the requisite level of quality is achieved in a product. It entails establishing suitable standards and procedures and ensuring that these are followed. This should be geared towards development of a ‘quality culture’ whereby quality is perceived as the responsibility of all and sundry (Kitchenham, & Pfeleeger, 2001p.5).
David Garvin’s concept of quality
In a powerful paper probing views of quality, David Garvin examined how quality is perceived in various fields such as economics, philosophy, and marketing and operations management. He later concluded that, indeed, quality is a complicated and versatile concept (Garvin, 1984 p 24). He further noted that the concept could be explained from five views namely transcendental, user view, manufacturing view, product view, and value-based view. The transcendental perspective holds that quality is something that can be acknowledged but not distinct. The user view identifies quality as suitability for use. On the other hand, the manufacturing view sees quality as conformance to requirement. The product perspective presupposes that quality is linked to the inbuilt traits of the product. Lastly, the value-based view assumes that quality depends on the amount a consumer is ready to recompense it. It is important, therefore, to bring all these perspectives in the discussion of software quality management and control.
Going by the transcendental view, software quality is more of what Plato describes as the ideal or even Aristotle’s concept of form. Software quality is something toward which we endeavor as an ideal but may never realize at all. As such, when software developers struggle to come up with products that satisfy their customers, this satisfaction stands for the strived-for “recognition” as defined in this view of quality (Kitchenham, & Pfeleeger, 2001p.8).
The user view definition of software quality, examines the product in a task framework, which is highly personalized. In the case of the manufacturing view, software quality is evaluated by questioning whether the manufactured was right the first time. This view is highly criticized because there is little proof indicating that conformance to process standards like ISO 9001 or Capability Maturity Model is a guarantee of quality.
The product view of software quality posits that quality is only guaranteed by measuring and controlling internal product characteristics. Software-metrics supporters mainly adopt this perspective. Lastly, the value-based view on software quality equates quality to what the customer is prepared to pay for. This type of perception enables parties with different views to strike a middle ground between cost and quality. These perspectives imply that the way we view software quality is very important in coming up with ways of maintaining or controlling quality (Kitchenham, & Pfeleeger, 2001p.5).
Background to quality management
In the middle ages, an artisan developed a product completely from formation to delivery to the customer. This resulted to a very strong sense of satisfaction in the quality of the product by the artisan. Apprentices joined the artisans to gain knowledge of trade and skills through working closely with their masters. With the onset of the industrial revolution, this traditional paradigm transformed because labor became highly specialized. Workers were accountable for a particular element of the development or manufacture of a product.
This phenomenon led to dilution of the sense of ownership and the pride of workmanship in a product. Consequently, more strict management practices were required. These included planning, organizing, implementation, and control. Such practices inexorably resulted to a hierarchy of labor with different roles, as well as a reporting framework. There was a need of supervisor controls to ascertain quality and productivity issues were attended. Modern labor hierarchies are derived from this.
Software quality systems
Coming up with a software quality program from scratch consumes a lot of time alongside being headed for failure before commencement. The anxious practitioner encounters a number of challenges. These include insufficient preparation, misused terms, lack or poor planning, as well as lack of recognition of the roles played by the other team members in the organization. A software quality system (SQS) is meant for two main reasons.
The first reason is to build quality into the software from inception. This implies the problem addressed is precise and accurately stated, that the necessities for the remedy are clearly defined, elaborated and comprehended. As such, almost all the elements of the software quality system are endeared towards the validation of requirements and contentment. For quality to be instilled into the software system from its inception, the software necessities ought to be comprehended and documented. It is only after the actual requirements, as well as the needs of the user that they fulfill, are known and understood that the user will be contented with the software system delivered to him or her. The second reason for having SQS is to maintain the quality in the software throughout its software life cycle (SLC).
Elements of a software quality system
There are ten elements of the software quality system. These are standards, reviewing, testing, defect analysis, configuration management, security, education, vendor management, safety, and risk management. The first element to be discussed in the list is standards. Standards are meant to offer constant, meticulous, uniform and enforceable means for software development and operation activities. The role of developing standards is bestowed to professional bodies like the Institute of Electrical and Electronics Engineers (IEEE), international institutions like International Organization for Standardization (ISO), industry groups or individual software development organizations (Horch, 2003 p.10).
Standards entail all the fundamentals of the software lifecycle (SLC), even encompassing the very definition of the SLC itself. Compared to the other software quality elements, standards are the only element that can administrate every stage of the life cycle. Standards accomplish a number of roles. They can explain considerations to be covered during the concept exploration stage. In addition, they can also spell out the layout of the final report describing the retreat of a software system that is out of use (p.12).
There are some important features such as the necessity, that the specified level of should have. A standard cannot be observed if there is no genuine reason for its existence. The second characteristic that a standard should have is feasibility. If complying with the tenets of a standard beats the precedents of common sense, then there is no need of observing such a standard. The last characteristic of a standard is measurability. It should be possible to show that the standard is being followed.
Software standards should be put into place for the producer of a software product or component to be mindful of the technical aspects of the task as opposed to the habitual aspects that are common for the same task. For instance, standards for document formats allow the producer to be mindful of the technical issues and content instead of format or design particulars. Before examining, the next element of the software quality system, it is important to note that though standards are useful, their efficiency is dependent on support from policies that shoe their imposition precisely (Horch, 2003 p.14).
The second element of a software quality system is reviewing. Reviews allow continuing visibility into the software development and fitting activities. There are two major types of reviews namely product and process reviews. Product reviews, also referred to as technical reviews, are formal or informal examinations of products and components throughout the development stages of the software lifecycle. Informal product reviews usually occur during the software development lifecycle (SDLC) stages. On the other hand, formal product reviews indicate the end of the stages. The informal reviews generally encompass walkthroughs and inspections (p.15).
The other type of reviews is called the process review. It may be conducted at any time. It is meant to evaluate the accomplishment of the software process in effect. Data to be used in this type of reviews is derived from the technical reviews based on defects noted by the technical reviews. Opportunities for modifications of the current process are sought. The reviewing process also includes audits. These are evaluations of components for conformity to content and layout specifications, or constancy with or similarity to a predecessor. There are two types of audits namely formal and informal audits. A classical example of an informal audit is the unit development folder (UDF). This type of audit compares the content and condition of the UDF against principles governing the preparation of the UDF (Horch, 2003 p.16). It is aimed at ensuring that the UDFs are used as per the requirement. An example of a formal audit is the physical audit (PA). This compares the final appearance of the code against the final certification for that code. The physical audit aims to guarantee that documentation and code agree before being released to the user or customer.
The third element of the software quality system is testing. It is aimed at providing increased self-assurance and, as such, shows that the software requirements are being fulfilled. Testing involves planning, design, execution, and reporting. The next element of software quality system to be discussed in this paper is defect analysis. This is a blend of defect detection and correction, as well as defect trend analysis. The first two processes, coupled with change control, present a record of all the discrepancies present in each software component. Defect analysis also records the disposition of each fault, probably, in the form of a software problem report or software change request (Horch, 2003 p.17).
The defect analysis element of software quality control system achieves a number of objectives. To begin with, it prevents errors from remaining unsettled for unsuitable lengths of time. It also prevents unnecessary charges, as well as indicates the weak areas in the software. The process also provides analysis data for the examination and rectification of the development process. In addition, it cautions against possible defects through examination of defect trends.
The fifth element of the SQS is configuration management. It is aimed at maintenance of control of the software during development and after use. This is a three-fold activity that involves configuration identification, configuration control and, configuration accounting (Horch, 2003 p.17). Configuration identification is the naming and documentation of each component of the software so that the exact component of concern can be individually identified at any given time. On the other hand, configuration control is the prevention of unauthorized changes to any software product. Lastly, configuration accounting records the condition of each component.
The sixth element of the SQS is security. Security activities are applied to both data and the physical data center. They are meant to protect the worth of the software and its environment. Education is the seventh element of the software quality system. It ascertains that the people involved with software development and users are in a position to work well (Horch, 2003 p.18). The next element of the SQS under discussion is vendor management. Due to the existence of different types of software that can be purchased (off-shell, tailored shell and contracted), there is a need for the purchaser’s quality practitioners to work hand in hand with the vendor’s quality practitioners to guarantee consideration of all requisite steps.
The ninth element of SQS is safety. With the growth of importance of computers and software, as well as their impact on peoples’ lives, the safety of the gadgets becomes a major alarm. As such, every software project must deliberately put into consideration the safety implications of the software and the system of which it is a component. The last element of SQS is risk management. It is important to note that there are many risks linked with any software project. Risk management identifies the risk, determines the likelihood, cost, or threat of it; and takes action to do away, reduce or accept the risk (Horch, 2003 p.20).
Software quality management
Quality management is mainly crucial for large and complex systems, which need a progress record to support continuity of development with changes in the development team. Nevertheless, quality management is also needed for smaller systems to establish a quality custom. The activities involved in quality management are; quality assurance, planning and control. Quality planning is the setting out of the desired product traits to evaluate and identify those, which are more important than others are (Baltus, 2001 p.18). A quality plan, therefore, seeks to identify the quality assessment procedure. It is supposed to come up with the organizational standards that should be applied, and where appropriate, define new principles to be deployed.
On the other hand, quality control entails check up of the software the development process to ensure follow up on procedures and standards. This is achieved by use of quality reviews and automated software assessment and software measurement (O’Regan, 2002 p. 137). Quality reviews are the major means of validating the excellence of a process or a product. In this case, a group evaluates part or all of a process or system as well its certification to seek latent problems. There exist three major types of reviews aimed at different goals. These are; inspections for removing defects in the product, reviews for both product and process progress assessment and finally, quality reviews aimed at both products and standards(Malik, 2008 p.26). Reviews, thus, serve as part of the general quality management process. In project management, they offer essential information to project managers as well as provide product knowledge, which is shared among development team members.
It is crucial to note that, during the review process, comments are made. They are grouped into three categories. In the first category, a review may result to a ‘no-action’ comment. In such cases, there is no change to the software or documentation is needed. The second one is the ‘refer for repair’ comment. This implies that the designer or programmer should rectify an identified error. The last comment is that of ‘reconsider overall design’. Under this category, the problem noted in the review has effects on other parts of the design. As such, there is a need for embarking on the most cost-effective remedy to the problem (Malik, 2008 p.28).
As hinted earlier in this paper, quality control can be achieved through two approaches. One of them is through reviews as discussed in the preceding paragraphs. The other method is by automated software assessment and software measurement. This method emphasizes the derivation of a numeric value for a feature of a software product or process (Horch, 2003 p.121). This permits purposeful comparisons between techniques and processes. Though the strategy has been introduced in many companies, many organizations still lag in the efficient use of software measurement. This approach to quality control has a number of standards. For purposes of this paper, software metric will be given prominence.
A software metric is any type of measurement related to a software system, process or related documentation. A classical example to this is the Fog index or even the lines of code in a program. They enable the quantification of both the software and the soft ware process. They can also be used to predict product features or direct the software process. In addition, product metrics may be handy in the general predictions or recognition of irregular components (Baltus, 2001 p. 21).
Software metric makes several assumptions. The first one is that it presupposes that a software property can be measured. It also assumes that there is a connection between what can be measured and what one wants to know. They can only measure internal features though most of the focus is on external attributes. Software metric also assumes that the relation between what can be measured and what one wants to know can be formalized and validated. Lastly, it presumes that it is difficult to link what can be measured to attractive external quality features.
The external attributes include maintainability, reliability, portability and usability. On the other hand, external attributes are the number of procedure parameters, cyclomatic complexity, program size in lines of code, number of error messages, and length of user manual. If the assumptions of software metric are anything to go by, it follows that maintainability is related to the number of user parameters, cyclomatic complexity, program size in lines of code and the length of user manual. Reliability is related to cyclomatic complexity, program size in lines of code and the number of error messages. On the other hand, portability is closely linked to the number of procedure parameters and program size in lines of codes. Lastly, usability is related to the number of error messages and the length of user manual (Sommervile, 2004 p.36).
The challenges of software development have become a prodigy. Nevertheless, they revolve such issues like late delivery, high price and pitiable quality of software systems. The reply has been to come up with engineering-like disciplines for the software development procedure. Software engineering aims to create apt software of assured high quality at fair prices. Due to the mounting demands of the international software market where the quality of software has become a main competitive consideration and official conventions, as well as regulations on software accountability and warranty, pose major quality assurance procedures, the deployment of quantitative perspectives in software quality control is very crucial to any software (Mitchell, 2009 p 30).
One particular issue that has remained in the minds of software developers is the increasing cost of software systems maintenance. The capital invested in software maintenance has been approximated to take up more than half of the life cycle expenditure on software (Horch, 2003 p.128). Metrics are viewed as an important relief to aid in the maintenance process and, therefore, reduce costs. The mellowness of software engineering as a discipline is portrayed in the way metrics are incorporated in the software development and maintenance process. The sporadic application of metrics in the software development process is then perceived as a control system offering a constant response and permitting remedial measures in the entire process.
The outlook of maintenance has undergone tremendous transformations in the past. The phenomenon is no longer confined to remedial actions. In addition, it puts into consideration the evolutionary form of software (Mitchell, 2009 p. 27). There exist three types of maintenance namely corrective, adaptive and perfective maintenances. In the first case, the changes are prompted by lingering faults in a system while in the second type; the change is necessitated by changes in the environment in which the system is operating. The last category of maintenance is that whose alterations are geared towards ameliorating or increasing the performance of a system. The easiness by which all the three modifications can be performed is referred to as maintainability.
Maintainability metrics or simply put, those metrics suitable for quantifying maintainability, shore up maintenance management through three ways. In the first case, emphasis is laid on those software traits that enable maintenance (Kan, 2003 p.17). Secondly, metric values showing acceptable or unbearable levels of anticipated maintainability can direct the resolution whether a program or system should be unconstrained or not. Lastly, the resources to be spent in the future in maintaining a program or software system can be approximated. As such, it is not unanticipated that maintainability metrics have been the subject of many studies in the past.
The preceding discussions have expounded on a number of ways in which quality of software can be maintained. The focus of this paper now shifts to the importance of having efficient and effective software. One area that rings in the minds of many when software quality is mentioned is project management. Indeed, the two are often referred synonymously. As such, just like software quality, project management is important in all organizations be they large or small. This is because they are constantly involved in the implementation of new activities such as the development of a new product or service or even a public relations drive (Lewis, 2002 p.13). To stay at par with their competitors, there is no doubt, whether an organization will be faced with the challenge of developing of multifarious services and processes (Modesto, 2009 p. 6).
Conclusion
As seen earlier in this paper, quality implies that a product should meet its specification. However, in the case of software systems, the issue becomes challenging. A number of factors prompted this scenario. To begin with, there is a conflict of interests between customer quality requirements and developer quality requirements. The former demands products that are efficient, reliable and cost effective while the latter is out manufacture reusable and maintainable products.
Another problem that has befallen software quality is the fact that a number of quality requirements are challenging to specify in a precise manner. Lastly, software stipulations are incomplete and inconsistent. Despite these challenges, quality in the development of software systems cannot be compromised and as such, there is a need of waiting for specifications to improve on software quality. In addition, it is appropriate to put quality management procedures into place to ameliorate software quality despite defective stipulations.
References
Baltus, B 2001, Software quality: state of the art in management, testing and tools (2nd ed), Springer Verlag, New York.
Garvin, D, “What Does “Product Quality” really mean?” Sloan Management Review, 1984, pp. 25-45.
Horch, JW 2003, Practical guide to software quality management, (2nd ed) Artech House, Inc., New York.
Kan, SH 2003, Metrics and models in software quality engineering, Pearson Education, Inc., Boston, MA.
Kitchenham, B & Pfeleeger, SL 2001 Software quality: the elusive target. Web.
Lewis, JP 2002, Fundamentals of Project Management, AMAC, New York.
Lientz, BP& Rea, KP 2001, Breakthrough Technology Project Management, Academic Press, San Diego.
Malik, K 2008, Software quality: a practitioner’s approach, TaTa McGraw Hill, New Delhi.
Mitchell, RJ 2009, Managing complexity in software engineering (ed), Peter Peregrinus Ltd, London.
Modesto, ST 2009, Successful project management: insights from distance education practices. Web.
O’Regan, CG 2002, A Practical approach to software quality, Springer Verlag, New York.
Sommervile, I (2004), ‘Quality management’ in Software engineering (7th ed). Web.