Quality Standards in Open Source Lifecycle

Transcription

1 Quality Standards in Open Source Lifecycle Bogdan VINTILA Academy of Economic Studies, Bucharest, Romania Abstract: Open source applications and components are very important for the communities of software developers. Developing applications using open source components ensures reduction of costs and time. The use of open source components ensures a high quality of the applications because open source components are tested by the whole community. The source code provided by the developers of the applications or components allows other developers the quick modification of code to be able to solve their own problems. Quality is an important issue for the open source software. Open source software must comply with the quality standards in order to have success within the community. The McCall quality model is a reference model for software quality. The model is presented and explained. Alternative models are also presented and explained. Differences between these quality models are highlighted. Effects of complying with quality standards are discussed. Keywords: open source, lifecycle, quality, standards, McCall. 1. Introduction Open source represents software that have no using costs and can be modified and distributed by anyone. The open source concept is different from the free software one as in the case of free software the source code is not available to third parties and these can t modify the product in order to redistribute it. Open source software development raises problems to the traditional approach in which the users must pay to use the software products. The existence of a software product that solves a problem and is free of charge leads to a diminishing of the sales of a commercial product that solves the same problem. Developing open source informatics products has many advantages [1]: - quick development; as any interested person can contribute to the development of the product the product s finalizing time is short; the application s modules are developed by different persons and after all modules are finalized, they are put together; - detailed testing; testing is a very important process for the development cycle of informatics applications; as the users community that use open source components is very large, the products are tested by many users; if for developing applications advanced knowledge is required, for the testing of applications, in the conditions of an automated error reporting tool, it is required only the usual work of an user and the existence of an Internet connection; by using automated reporting tools the developing team receives many data regarding the problems the application encounters in current use; - high performance of the developed application; the diversity of the team members ensure a high flux of ideas regarding the realization and optimization of the application s modules; the diversity of the members domains ensure diversity in the ways the problems are solved; the availability of the source code leads to application s performance improvements as anyone can contribute with optimizations; 46

2 - new versions of the application in short periods of time [2]; is given by the environment s dynamic and the high number of open source developers; new versions allow performance evaluation, identification of deficiencies and new facilities the application must offer; - high modularization [3]; for applications developed in software development companies it is possible to develop unitary applications as all team members are at the same location, communicate without problems and the source code is located on a single computer; for the open source development the teams seldom reunite; the distance between the team members imposes a different way of work for the developing of the application; the modularized development is the most fit for a dispersed team; each member of the team develops and tests the module it s been assigned and then, after all modules are finalized, these are reunited and the unitary functioning of the application is tested; application modularizing shortens the time necessary for the development of the application and the interaction between the team members; - source code security [4]; at the traditional centralized development there is the risk that malicious persons destroy the applications files; at the open source development the risk is inexistent as the source code is copied on the computers of all developers and if one of the computers is destroyed only the data updated by that only developer is lost; the replication of data on many computers ensures a great protection against data loss. As seen above, there are many advantages of developing open source software or using open source modules. 2. McCall Quality Standard The rapid evolution of technologies and approaches of the events leads to the creation of new standards. Standardization leads to the possible development of objective assessment and ranking. Chain of products and services ensure rapid variant selection that best meets the user criteria. It is also necessary to standardize procedures for measuring the levels of various characteristics surveyed. In the absence of the measurement, data analysis results are not comparable and are compromised. McCall quality model developed in 1977 has eleven software quality factors [5]. These factors are grouped into three categories: Factors on product operation: correctness, reliability, efficiency, integrity, usability; Factors on product revision: maintainability, flexibility, testability; Factors of product transition: portability, reuse, interoperability. 47

3 Fig Influence factor grouping for McCall model Fig. 2.1 notes the model categories of influence factors for software quality defined by the McCall model. Requirements of fairness are defined as the list of system output. Exits must treat all possible inputs. The list for possible entries are not defined outputs are considered invalid. Accuracy of results is specified to have no problems on inaccurate data or calculations. Completeness of data is also important to meet the quality factor. The update of data and its availability must be given also for quality assurance in terms of fairness. Also in this factor are embedded and standards for coding and documentation system. Requirements of reliability concerns the impossibility of operation. These determine the maximum rate of system failure. Reliability is specified either for the whole system or component thereof. Efficiency refers to the hardware requirements necessary to achieve certain treatment. The main hardware is processing capacity, working memory, memory storage and communication capabilities. Efficacy involves the use of as few hardware tasks. Also effective for mobile devices, can be considered as long as the product can run up to energy resource depletion. For efficiency specifications are declared as hardware processing unit, or unit of processing hardware required. 48

4 Fig Product operation factors Integrity requirements are related to system security software. This involves restricting access of unauthorized persons and also distinguishes between people with the right to write and read and those with the right data. Ensure that only persons entitled to write can change the data in the system is vital to its integrity. Usability refers to the resources needed to prepare staff for using the software. If the software meets all other specifications, but it takes days to six months of basic training of personnel, the software will be bought because the time required of staff is too high. Usability requirements are defined as the time required for preparing an individual for a set of functions of the software. Fig. 2.1 highlights the factors regarding product operation. Factors on the software revision are maintainability, flexibility and testability. Maintainability quantifies the effort from users and staff in charge of maintainability to identify the reasons for the unavailability of software, to correct defects and to verify the success of changes. This requires a modular structure of the software, documentation, the manual. Flexibility quantifies the effort for adaptive maintainability activities. These include the resources necessary to adapt the software for different customers, different activities and different products. Although the software is designed to support these facilities, it must be set our clients. Testability assumes the testing of an information system and its operation. The testability specifications are related to some options of programs that help testers. The testability includes the system requirements check at start to see if it can run and all the resources it needs are available. 49

5 Fig Product revision factors Fig. 2.3 summarizes factors on product review. They are very important for the life of the product. Factors on the product transition are portability, interoperability and reuse. Portability is adapting the software system to be run under conditions consisting of different hardware, different operating systems. Compliance with the portability allows running the same basic software platform regardless of hardware or software by operating minor changes. Reuse requires the use of software modules designed for other products in the current project. Reuse also involves the construction of modules for the current project that will be used in future for other projects. By reusing software modules developers reduce the time needed to meet such requirements and resource consumption. This is because software modules have been tested and do not need a re-test. Interoperability focuses on automatically work with other software or software designed to control equipment. Interoperability requirements specify the software products that the new product should work with. Accepted standard in the field structure can also be specified. 50

6 Fig Product transition factors Fig. 2.4 shows the factors affecting product quality in terms of product transition criterion. 3. Alternative quality models Two alternative models have emerged after the McCall model: the model of Evans and Marciniak 1987; the model of Deutsch and Willis in These two models bring new influence on software quality. Both models exclude testability from the McCall model. The Evans and Marciniak model has twelve factors that are grouped into three categories: design, performance and adaptation. The Deutsch and Willis model has fifteen factors grouped into four categories: operating performance and change management. Two of the factors suggested by the new models are very similar to the model factors McCall. The three new factors are verifiability, security and manageability. Verifiability requirements defining features design and programming that enables efficient verification of design and programming. Safety requirements are designed to eliminate hazard conditions for operators of equipment as a result of errors in process control software. These errors can degenerate into inappropriate reaction to dangerous situations or failure to give warnings to the detection of dangerous situations. Manageability requirements are related to administrative tools that support software changes during the development and maintenance period. Fig. 3.1 shows the new factors of the model developed by Deutsch and Willis to the McCall model. 51

7 Fig Deutsch and Willis model Fig. 3.2 shows the new factors of the model developed by Evans and Marciniak compared to the McCall model. Fig Evans and Marciniak model IEEE and ISO standards for software quality models are made on the basis of quality. ISO defines four software components: software; procedures; documentation; data required for running the software system. Computer software is source code resulted in additional executable files and other files needed to run the system. They are different depending on the operating systems and hardware architectures that are designed to run. Procedures relate to how to use the programs, how to abstain data entry, interpretation of results. They define the order in which programs are run, the methods involved, the person responsible for activities necessary application software. User Documentation refers to information given to users about the operation of the software system. This gives a description of all the applications available and appropriate methods of use. The documentation also implies the existence of complete and accurate information in the source code of operations performed. Documentation of source code makes software maintenance process. Documentation during product development ensures a smooth collaboration between team members and also developing effective inspections. Data required for running the software system include sample data, additional files needed product that are not default operating system, drivers for data access. Other data include parameters, codes and lists of names to adapt software to specific user needs. Standard test data ensures that the transition from one version to another no undesirable effects occur in the processing. Software quality is thus ensured by ensuring quality for the above components. ISO 9126 is an international standard for software quality assessment [6]. The fundamental objective is to address human error which may affect the development of a software project. The standard is divided into four parts: - quality model; - external metrics; - internal metrics; - metric use quality. 52

8 The quality is established in the first part of the standard ISO It classifies software quality in a set of features and subfeatures as follows: functionality; o adequacy; o accuracy; o interoperability; o standard compliance; o security; reliability; o maturity; o recovery; o fault tolerance; usability; o learnability; o intelligibility; o operability; efficiency; o time behavior; o resource behavior; maintenance; o stability; o analyzability; o changeability; o testability; portability; o installability; o replaceability; o adaptability; o portability standards compliance. Each subfeature is divided into attributes. Each attribute can be verified or measured for a considered software product. Attributes not defined in the standard may therefore be different for different software products. The standard provides a framework for organizations to define a quality model for software. External metrics are applicable to software running. Internal metrics do not depend on running the software. They are applied statically. Quality in use metrics is available only when the final product is used in field conditions. Ideally internal quality determines the external quality. ISO 9126 is replaced in 2005 by ISO The standards are constantly updated to meet all user requirements better. Adapting to standards is a vital activity for any organization performing software. 4. Conclusions Developing open source applications is a process of many advantages. The development is quick, the components are of high quality, the number of testers is very high, the necessary of resources is diminished. Quality standards are very important for the lifecycle of the open source products. The software product is a result of the processes that are run during the development cycle. Ensuring the quality of the processes increases the probability of obtaining a high quality software product as a result. The quality models are 53

9 very important for the quality of the product and of the processes that ensure this quality. The product s lifecycle is not only development, but also the maintenance phase that lasts after the release of the software to the public. The quality is ensured by having processes that fulfill all the quality requirements. Ensuring a high quality for the product during the development cycle leads to a smooth maintenance process afterwards. The maintenance process is done as long as it is easier to keep fixing faults than to develop a whole new product. If all the quality requirements were complied with during the development cycle, the maintenance process is an easy one and the life of the product is prolonged. Acknowledgements This article is a result of the project Doctoral Program and PhD Students in the education research and innovation triangle. This project is co funded by European Social Fund through The Sectorial Operational Program for Human Resources Development , coordinated by The Bucharest Academy of Economic Studies. References [1] K. Fogel, Producing open source software: how to run a successful free software project. O'Reilly, [2] S. Weber, The success of open source, Illustrated ed. Harvard University Press, [3] F. P. Deek and J. A. McHugh, Open source: technology and policy. Cambridge University Press, [4] S. Koch, Free/open source software development, Illustrated ed., S. Koch, Ed. Idea Group Inc (IGI), [5] G. Daniel, Software Quality Assurance From Theory to Implementation. Addison Wesley, [6] Wikipedia. (2010, Feb.) ISO [Online]. [7] I. Ivan, B. Vintila, C. Ciurea, M. Doinea "The Modern Developments Cycle of Citizen Oriented Applications," Studies in Informatics and Control, vol. 18, no. 3, [8] F. O. Bjørnson and T. Dingsøyr, "Knowledge management in software engineering: A systematic review of studied concepts, findings and research methods used," Information and Software Technology, vol. 50, no. 11, pp , Oct [9] S. Liu, "Integrating top-down and scenario-based methods for constructing software specifications," Information and Software Technology, vol. 51, no. 11, pp , Nov [10] P. Pocatilu, Costurile testarii software. Bucharest, Romania: ASE Publishing House,

10 [11] B. L. Vinz and L. H. Etzkorn, "Improving program comprehension by combining code understanding with comment understanding," Knowledge-Based Systems, vol. 21, no. 8, pp , Dec Author Bogdan VINTILĂ graduated the Bucharest University of Economics, the Faculty of Cybernetics, Statistics and Economic Informatics. He is currently a PhD candidate in the field of Economic Informatics at University of Economics and at the University of Gothenburg in the Applied IT department. He is interested in citizen oriented informatics applications, developing applications with large number of users and large data volumes, e-government, e-business, project management, applications' security and applications' quality characteristics. 55