A STUDY ON QUALITY PARAMETERS OF SOFTWARE AND THE METRICS FOR EVALUATION

Size: px

Start display at page:

Download "A STUDY ON QUALITY PARAMETERS OF SOFTWARE AND THE METRICS FOR EVALUATION"

Melissa McBride
5 years ago
Views:

1 International Journal of Computer Engineering and Technology (IJCET), ISSN (Print) ISSN (Online) Volume 1 Number 1, May - June (2010), pp IAEME, International Journal of Computer Engineering and Technology (IJCET), ISSN (Print), IJCET I A E M E A STUDY ON QUALITY PARAMETERS OF SOFTWARE ABSTRACT AND THE METRICS FOR EVALUATION J.Emi Retna Karunya University Karunya nagar, Coimbatore jemiretna@yahoo.co.in Greeshma Varghese Karunya University Karunya nagar, Coimbatore greeshma_2010@gmail.com Merlin Soosaiya Karunya University Karunya nagar, Coimbatore merlinsoosaiya@gmail.com Sumy Joseph Karunya University Karunya nagar, Coimbatore almerah.joseph@gmail.com Software Quality is one of the illusive targets to achieve in the software development for the successful software projects. Software Quality activities are conducted throughout the project life cycle to provide objective insight into the maturity and quality of the software processes and associated work products. Software Quality activities are performed during each traditional development phase. There are many parameters or attributes which helps to ensure the quality of the software. The paper analyses and a detailed report are presented on each quality attribute parameter. INTRODUCTION Gone are the days when software quality was thought of as a luxury. But now software quality is one of the illusive targets to achieve in the software development. The successful software projects achieve excellence in software quality. Today it is viewed as 235

2 an essential parameter with any software delivered. Software quality has several definitions and is viewed in several perspectives. Software built with all the requirements specified by the client or software that has 0% defect (practically impossible) cannot be deemed as of high quality. Quality however is not a single parameter but it is a collection of parameters and it has a multidimensional concept. According to Crosby, quality is defined as a conformance to requirements, which means the extent to which the product conforms to the intent of design. Quality of design can be regarded as the determination of requirements and specifications and quality of conformance is conformance to requirements. Some of the parameters that add up to the quality of software are as given below: Capability (Functionality), Scalability, Usability, Performance, Reliability, Maintainability, Durability, Serviceability, Availability, Installability, Structured ness and Efficiency. There are two types of parameters namely functional parameters and non functional parameters. Functional parameters deal with the functionality or functional aspects of the application while non functional parameters deal with the non-functional parameters (but desirable) like usability, maintainability that a developer usually doesn t think of at the time of development. Generally the non functional parameters are considered only in the maintenance phase or after the software is being developed which causes rework or additional effort requirement. Hence it is a best practice to consider quality even in the initial phases of software development and deliver the software with high quality and on time. Some of the quality parameters are interrelated as specified Figure 1 Interrelationships of Software Attributes in figure 1 [1]. 236

3 Parameters Models and Metrics Features to improve parameters Capability (Functionality) 1. Function Point 1. Security of overall system 2. Feature set and capabilities of the program Usability 1. Questionnaires, Testing 2. Error Rate 3. ISO GUI 2. Component reuse Performance Reliability Maintainability Durability (also include session durability) Serviceability Availability 1. Execution Time 2. Time Reduction 3. Idle Time Reduction 4. Response Time 5. Completion Rate 6. Throughput 7. Service Unit Reduction 8. Meeting user s expectations 9. Problem resolution 10. Timeliness 1. exponential distribution models 2. Weibull distribution model 3. Thompson and Chelson's model 4. Jelinski Moranda model 5. LittleWood Model 6. MTTF (Mean Time To Failure) 7. MTTR (Mean Time To Repair) 8. POFOD (Probability of failure on demand) 9. Rate of fault occurrence 10. Reliability = MTBF/(1+MTBF) 1. Models like HPMAS 2. Polynomial assessment tool 3. Principle Components Analysis 4. Aggregate Complexity Measure 5. Factor Analysis 1. Reliability 2. Availability 3. Markov Chain Model 4. Supplier / Component Subsystem quality audits 5. PPM Defects 6. % right first time 7. Initial Quality Survey 8. Customer Satisfaction 9. Warranty Claim Rates 1. Mean Time To Repair = Unsheduled downtime/ no. of failures 2. Mean nodenours to repair = Unsheduled downtime nodehours/ no.of failures 3. Mean time to boot system = sum of wall clock time booting system/ no of boot events 1. System Uptime Mean Time To Failure 2. Mean Time To Failure+Mean Time To Repair *100% 1. Reduced hit ratio 2. Cache 3. Improved Processing Power 4. Software engineering practices 5. Design 6. Understanding user requirements 7. Architecture Design 1. Consistency 2. Data Integrity 3. Accuracy 1. Stability 1. Data Redundancy - Replication - Erasure Coding 2. Data Repair - Failure Detection - Repair 1. Help desk notification of exceptional events 2.Network Monitoring 3.Documentation 4.Event Logging 5Training 6Maintenance Work product is operational and available for use 237

4 Installability Scalability 1. Total installability time 2. Total count of installers 3. % of installers involved only in tuning 4. Time spent for user training 5. Count of database reports written 6. custom features percentage 7. Customer s negotiation strength 8. GQM 1. Load scalability 2. Service scalability 3. Data scalability 4. Page/screen response time Productivity 1. Programmer productivity = LOC Produced Person Months of Effort amount of output 2. Productivity = effort input Complexity 1. Cyclomatic Complexity (or conditional complexity), V (G) = E N + 2 where E is the number of flow graph edges and N is the number of nodes. 2. McClure s Complexity Metric= C + V where C is the number of comparisons in a module and V is the number of control variables referenced in the module 3. Cohesion STRENGTH = where X is reciprocal of the number of assignment statements in a module and Y is the number of unique function outputs divided by number of unique function inputs. 1. Effort needed to install software 1. Application specific factors 2. Load generation tool related 3. Hardware configuration of load client 4. Architecture Design 1. To reduce defect levels 2. Defect prevention and removal technologies 3. Defect Removal Efficiency 1. Increase in RFC(Request for a class) 2. Inheritance 3. module strength 4. Degree of data sharing Efficiency (of algorithms) Reusability 4. Coupling = where Zi = 1. Resource Utilization 2. Level of performance 3. End-to-end error detection like performance defects appear under heavy load 1. Reuse percent- the de facto standard measure of reuse level = (Reused Software / Total Software) * Use objective metrics on subjective data to obtain reusability readings Portability 1. Portability =1 (Resources needed to move system to the target environment/resource needed to create system for the resident environment) Testability 1. Effort needed for validating the modified software 2. Effort required to test a program Effort/Cost 1. Boehm s COCOMO model 2. Putnam s SLIM model 3. Albrecht s Function Point model 1.Usage of CPU 2.I/O capacity 3.Usage of RAM Table 1: Quality Parameters with models /metrics 1. Software system independence. 2. Machine independence. 3. Generality. 4. Modularity. 1. Design documentation 2. Code 1. Related with code 1. Preparation and execution 2. Ease of maintenance 3. Effort on duplicates and invalids 238

5 Generally if there is a reliability problem the usability of an application is rated poor. If the application becomes unavailable (availability factor decreases), then again the performance is rated low. If the performance of software improves it means factors such as availability are high. Hence all the parameters are inter-related and proportional. Table1 proposes the quality parameters, the key models and their key metrics. The feature that enhances the quality parameter is also listed. 1. CAPABILITY (FUNCTIONALITY) Functionality captures the amount of function contained on a product. Often functionality is measured rather than the physical code size. The software being developed needs to satisfy all the functional requirements. Functional requirements include almost all the user requirements or business requirements the what for the software is being developed. Once all the functionality is developed then the software becomes deliverable. The software developers, testers and quality practitioners are entrusted to verify if all the functional requirements are covered in software. If the functionality is developed the defects will be minimal in software. There are some sub characteristics that can be derived from the quality features of software [3]. Figure 2 Functionality Suitability: Attributes of software that bear on the presence and appropriateness of a set of functions for specified tasks. Accurateness: Attributes of software that bear on the provision of right or agreed results or effects. Interoperability: Attributes of software that bear on its ability to interact with specified systems. 239

6 Compliance: Attributes of software that make the software adhere to application related standards or conventions or regulations in laws and similar prescriptions. Security: Attributes of software that bears on its ability to prevent unauthorized access, whether accidental or deliberate, to programs or data. The most widely used metric is the Function Point metric. Function Points are measures of software size, functionality, and complexity used as a basis for software cost estimation [3].The procedure to calculate the Function Point is as explained below: Step 1: Determine the unadjusted function point count(ufp) 1. Count the number of external inputs. External inputs are those items provided by the user (e.g.) file names and menu selections) 2. count the number of external outputs External outputs are those items provided to the user (e.g.) reports and messages 3. Count the number of external inquiries External inquiries are interactive inputs that needs a response 4. Count the number of internal logical files 5. Count the number of external interface files Table 2 Determination of UFP Item External inputs External output External inquiries External files Internal files Simple Weighting Factor Average UFC= ((Number of items of variety i) *weight i) i= Complex VAF = (0.01 * TDI) FP = UFP * VAF 240

7 Table 3 The general system characteristics General Characteristic System Brief Description 1. Data communications 2. Distributed data processing How many communication facilities are there to aid in the transfer or exchange of information with the application or system? How are distributed data and processing functions handled? 3. Performance Was response time or throughput required by the user? 4. Heavily used configuration How heavily used is the current hardware platform where the application will be executed? 5. Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.? 6. On-Line data entry What percentage of the information is entered On-Line? 7. End-user efficiency Was the application designed for end-user efficiency? 8. On-Line update How many ILF s are updated by On-Line transaction? 9. Complex processing Does the application have extensive logical or mathematical processing? 10. Reusability Was the application developed to meet one or many user s needs? 11. Installation ease How difficult is conversion and installation? 12. Operational ease How effective and/or automated are start-up, back-up, and recovery procedures? 13. Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations? 14. Facilitate change Was the application specifically designed, developed, and supported to facilitate change? 241

8 Step 2: Determine the value adjustment factor (VAF) VAF is based on the Total Degree of Influence (TDI) of the 14 general system characteristics. TDI = Sum of Degree of Influence of 14 General System Characteristics (GSC). These 14 GSC are listed in Table 3. II. USABILITY Boehm defined software usability as the extent to which the product is convenient and practical to use. The software usability is considered as a combined form of understandability, learn ability, operability and finally the attractiveness of the product to the final user or user group [Pressman, 1999].How usable is software? Determines its longevity. Usability evaluation yields better results only if there is a good usability design. The usability evaluation can be user based or expert based. The software has to be usable. Usability depends on parameters such as ease-of-use, comfort level, simplicity etc. Functional software without the usable factor will be least desired. If the User Interface is designed with user friendliness in mind it adds to usability. Figure 2 depicts the consolidated usability model by Abron. As in the figure usability factor increase only if an application is effective, efficient, user expectations satisfied, ease to use and highly secure. Figure 3 Usability Some of the methods adopted to measure usability are a. How satisfied is the user b. Whether the user is able to perform the task intended (task success) c. The problems encountered when using the software (failure) d. The time taken to complete the task d. Task completion rates, task time, and satisfaction and error counts. 242

9 e. Ease of use f. Download delay g. More navigability h. Interactivity i. More responsive j. Higher quality To improve usability it is important to improve page reduction so that the page is informative and the information needs of the user are satisfied. Website download delay affects usability. Table 4. Usability Design Factors III. PERFORMANCE There are lots of factors that affect the performance of software like communication failure, poor bandwidth, hardware or component failure. The parameters for performance evaluation are: 1. Execution time 2. Service unit reduction 3. Idle time reduction 4. No of tasks completed A high performance application can be designed using various technologies like: 243

10 1. Caching 2. Multiple servers running on different machines 3. Thread management 4. Improved page design The selection of tools, technology/platform, design, knowledge base etc plays a vital role in the performance of an application. Appropriate models needs to be chosen at the early stage of software development itself. For e.g., Let us consider website performance analysis. The performance of a website is analyzed from a customer s perspective. When the user is only interested in checking the mails, he may log into any websites that provide mailing services. The leading providers have their own design and functionality built-in. Some of the service providers, on login directs to the user s mailbox (category 1)while some other service providers, on logging in provide a informative or a little junk page rather than directing to the user s mailbox on log in (category 2). So category 1 provides much better performance than category 2 since when the user s perspective is to check mails timeliness is met by category 1 and not category 2.The responsiveness of websites and the performance can be measured using tools that are available like ECperf Figure 4 Reliability Maturity: Attributes of software that bear on the frequency of failure by faults in the software Fault Tolerance: Attributes of software that bear on its ability to maintain a specified level of performance in case of software faults or of infringement of its specified interface. 244

11 Recoverability: Attributes of software that bear on the capability to re-establish its level of performance and recover the data directly affected in case of a failure and on the time and effort needed for it. Probability of failure on demand (POFOD) is a measure of the likelihood that the system will fail when a service request is made. It is relevant for safety critical or nonstop systems. Rate of fault occurrence is relevant for operating systems, transaction processing systems etc. It considers the frequency of unexpected behavior. Mean Time To Failure is the time between observed failures. Reliability is the capability of the software product to maintain a specified level of performance when used under specified conditions [9]. Reliability measures include 3 components: 1) Measuring the number of system failures for a given number of system inputs 2) Measuring the time or number of transactions between system failures 3) Measuring the time to restart after failure IV. MATHEMATICAL CONCEPTS OF RELIABILITY Mathematically reliability R(t) is the probability that a system will be successful in the interval from time 0 to time t: [6] R(t) = P(T > t), t => 0 where T is a random variable denoting the time-to-failure or failure time. Unreliability F(t), a measure of failure, is defined as the probability that the system will fail by time t. F(t) = P(T =< t), t => 0. In other words, F(t) is the failure distribution function. The following relationship applies to reliability in general. The Reliability R(t), is related to failure probability F(t) by: R(t) = 1 - F(t). V. MAINTAINABILITY The capability of the software product to be modified. Modifications may include corrections, improvements or adaptation of the software to change in environment, and in requirements and functional specifications" [7]. Proper documentation needs to be maintained for maintaining software. The document needs to be complete and updated. 245

12 Software Maintainability assessment can be conducted at various levels of granularity. At the component level models can be used to monitor changes to the system as they occur and to predict fault occurring at software components. At the file level we can use models to identify subsystem that are not well organized. Models like HPMAS [5], a hierarchical multidimensional assessment model can be used. The important sub attributes for Maintainability are: Analyzability: Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures, or for identification of parts to be modified. Changeability: Attributes of software that bear on the effort needed for modification, fault removal or for environmental change. Stability: Attributes of software that bear on the risk of unexpected effect of modifications. Testability: Attributes of software that bear on the effort needed for validating the modified software VI. DURABILITY Fig. 5 Maintainability Software usability efforts improve software durability. Software durability can be data durability or session durability. Session durability generally speaking is of short duration. Technologies like data replication, data repair can be used to enhance durability. Reliability and availability can be considered as metrics for data durability. VII. SERVICEABILITY Serviceability is the ability to offer promised services by the software or application. With software it deals with the support offered in terms of user manual, technical help, problem resolvement etc. As new versions of software get released, the 246

13 software get released, the support for the older versions vanishes. Incorporating serviceability facilitating features typically results in more efficient product maintenance, reduced operational cost etc. The maintainability feature can be inbuilt within the system. Systems can be built with features that automatically shoot mails or log a service call on experiencing a fault VIII. AVAILABILITY Availability is the measure of how likely the system is available for use. It considers the repair or restart time into account. Reliability and availability goes hand-inhand. Software needs to be available even as the load increases. Availability of means the software is available 997 out of 1000 time units. IX. INSTALLABILITY Software needs to be easily installable. The parameter that needs to be set to install software needs to be easy. The software needs to be configurable. X. SCALABILITY The software needs to be highly scalable in all environments. Scalability can be interms of load, service, data atc. A system inorder to be highly scalable needs to have the ability to handle large transactions and load. As the load increases in production a desirable system will be able to scale up with additional hardware resources either vertically or horizontally. Vertical Scaling is when inorder to support an increase in load, an individual server is given increased memory or processing power. Horizontal scaling is when increased load is handled by adding servers to a distributed system. XI. COMPLEXITY Low coupling is often a sign of well-structured system and good design [5]. High levels of coupling usually will be associated with lower productivity. Complexity can be of two types. a) Apparent complexity, is the degree to which a system or component has a design or implementation that is difficult to understand and verify. b) Inherent complexity, is the degree of complications of a system or system component determined by such factors as the number and intricacy of 247

14 interfaces[4], the number and intricacy of conditional branches, the degree of nesting, and the type of data structures Metrics used for measuring the qualities of Software Some software metrics include: Total Lines of code Number of characters Number of Comments Number of comment characters Code characters Halstead's estimate of program length metric Jensen's estimate of program length metric Cyclomatic complexity metric CONCLUSION Good engineering methods can largely improve software reliability. Before the deployment of software products, testing, verification and validation are necessary steps. Software testing is heavily used to trigger, locate and remove software defects. Software testing is still in its infant stage; testing is crafted to suit specific needs in various software development projects in an ad-hoc manner. Various analysis tools such as trend analysis, fault-tree analysis, Orthogonal Defect classification and formal methods, etc, can also be used to minimize the possibility of defect occurrence after release and therefore improve software reliability. After deployment of the software product, field data can be gathered and analyzed to study the behavior of software defects. Fault tolerance or fault/failure forecasting techniques will be helpful techniques and guide rules to minimize fault occurrence or impact of the fault on the system. REFERENCES: [1] Stephen H. Kan, Metrics and Models in Software Quality Engineering, Second Edition. [2] N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous and Practical Approach, Second Edition. [3] 248

15 [4] Software Quality assurance: Principles and Practice -Nina S God bole [5] Software Reliability Engineering-John D.Musa [6] Roger S. Pressman. Software Engineering a practitioner's Approach. McGraw-Hill, Inc., [7] International Standard. ISO/IEC Institute of Electrical and Electronics Engineers, Part 1, 2, 3: Quality model, [8] International Standard. ISO/IEC (2001), Institute of Electrical and Electronics Engineering, Part 1,2,3: Quality Model, 2001, 249

Software Quality Management

Software Quality Management 2004-2005 Marco Scotto (Marco.Scotto@unibz.it) Contents Definitions Quality of the software product Special features of software Early software quality models Boehm model McCall model Standard ISO 9126