School Work

Software Engineering 5th Edition - Pressman

Software Engineering
of 4
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Related Documents
  PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 508 But some members of the software community continue to argue that software isunmeasurable or that attempts at measurement should be postponed until we bet-ter understand software and the attributes that should be used to describe it. This isa mistake.Although technical metrics for computer software are not absolute, they provideus with a systematic way to assess quality based on a set of clearly defined rules.They also provide the software engineer with on-the-spot, rather than after-the-factinsight. This enables the engineer to discover and correct potential problems beforethey become catastrophic defects.In Chapter 4, we discussed software metrics as they are applied at the process andproject level. In this chapter, our focus shifts to measures that can be used to assessthe quality of the product as it is being engineered. These measures of internal prod-uct attributes provide the software engineer with a real-time indication of the ef  fi -cacy of the analysis, design, and code models; the effectiveness of test cases; and theoverall quality of the software to be built. 19.1SOFTWARE QUALITY Even the most jaded software developers will agree that high-quality software is animportant goal. But how do we de fi ne quality?  In Chapter 8, we proposed a numberof different ways to look at software quality and introduced a de fi nition that stressedconformance to explicitly stated functional and performance requirements, explic-itly documented development standards, and implicit characteristics that are expectedof all professionally developed software. There is little question that the preceding de fi nition could be modi fi ed or extendedand debated endlessly. For the purposes of this book, the de fi nition serves to empha-size three important points: 1. Software requirements are the foundation from which quality is measured.Lack of conformance to requirements is lack of quality. 1 guidelines and past data. Theresults of the analysis are inter-preted to gain insight into thequality of the software, and the results of the inter-pretation lead to modification of work productsarising out of analysis, design, code, or test. What is the work product? Software metrics that arecomputed from data collected from the analysisand design models, source code, and test cases. How do I ensure that I’ve done it right? You shouldestablish the objectives of measurement beforedata collection begins, defining each technicalmetric in an unambiguous manner. De fi ne onlya few metrics and then use them to gain insightinto the quality of a software engineering workproduct. QUICKLOOK 1It is important to note that quality extends to the technical attributes of the analysis, design, andcode models. Models that exhibit high quality (in the technical sense) will lead to software thatexhibits high quality from the customer’s point of view. “Every program doessomething right, it just may not be thething that we want it to do.” author unknown  CHAPTER 19 TECHNICAL METRICS FOR SOFTWARE 2. Speci fi ed standards de fi ne a set of development criteria that guide the man-ner in which software is engineered. If the criteria are not followed, lack of quality will almost surely result. 3. There is a set of implicit requirements that often goes unmentioned (e.g., thedesire for ease of use). If software conforms to its explicit requirements butfails to meet implicit requirements, software quality is suspect. Software quality is a complex mix of factors that will vary across different applica-tions and the customers who request them. In the sections that follow, software qual-ity factors are identified and the human activities required to achieve them aredescribed. 19.1.1McCall’s Quality Factors The factors that affect software quality can be categorized in two broad groups: (1) factors that can be directly measured (e.g., defects per function-point) and (2) fac-tors that can be measured only indirectly (e.g., usability or maintainability). In eachcase measurement must occur. We must compare the software (documents, pro-grams, data) to some datum and arrive at an indication of quality.McCall, Richards, and Walters [MCC77] propose a useful categorization of fac-tors that affect software quality. These software quality factors, shown in Figure 19.1, focus on three important aspects of a software product: its opera-tional characteristics, its ability to undergo change, and its adaptability to newenvironments.Referring to the factors noted in Figure 19.1, McCall and his colleagues providethe following descriptions: Correctness. The extent to which a program satisfies its specification and fulfills the cus-tomer's mission objectives.  Reliability. The extent to which a program can be expected to perform its intended functionwith required precision. [It should be noted that other, more complete de fi nitions of relia-bility have been proposed (see Chapter 8).] 509 PRODUCT OPERATIONPRODUCT TRANSITIONPRODUCT REVISION Correctness Usability EfficiencyReliability IntegrityMaintainabilityFlexibilityTestabilityPortabilityReusabilityInteroperability FIGURE 19.1 McCall’s software quality factors It’s interesting to notethat McCall’s qualityfactors are as validtoday as they werewhen they were fi rst proposed in the1970s. Therefore, it’sreasonable to assert that the factors that affect software qualitydo not change.  PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING 510  Ef    fi  ciency. The amount of computing resources and code required by a program to performits function.  Integrity. Extent to which access to software or data by unauthorized persons can be controlled. Usability. Effort required to learn, operate, prepare input, and interpret output of a program.  Maintainability. Effort required to locate and fi x an error in a program. [This is a very lim-ited de fi nition.]  Flexibility. Effort required to modify an operational program. Testability. Effort required to test a program to ensure that it performs its intended function.  Portability. Effort required to transfer the program from one hardware and/or software sys-tem environment to another.  Reusability. Extent to which a program [or parts of a program] can be reused in otherapplications—related to the packaging and scope of the functions that the program performs.  Interoperability. Effort required to couple one system to another. It is dif  fi cult, and in some cases impossible, to develop direct measures of thesequality factors. Therefore, a set of metrics are de fi ned and used to develop expres-sions for each of the factors according to the following relationship:  F  q =  c  1 ϫ  m 1 + c  2 ϫ  m 2 + . . . + c   n ϫ  m  n where  F  q is a software quality factor, c   n are regression coef  fi cients,  m  n are the met-rics that affect the quality factor. Unfortunately, many of the metrics de fi ned by McCallet al. can be measured only subjectively. The metrics may be in the form of a check-list that is used to grade specific attributes of the software [CAV78]. The gradingscheme proposed by McCall et al. is a 0 (low) to 10 (high) scale. The following met-rics are used in the grading scheme:  Auditability. The ease with which conformance to standards can be checked.  Accuracy. The precision of computations and control. Communication commonality. The degree to which standard interfaces, proto-cols, and bandwidth are used. Completeness. The degree to which full implementation of required functionhas been achieved. Conciseness . The compactness of the program in terms of lines of code. Consistency. The use of uniform design and documentation techniquesthroughout the software development project.  Data commonality. The use of standard data structures and types throughoutthe program. “A product’s quality isa function of howmuch it changes theworld for thebetter.” Tom DeMarco  XRef The metrics noted canbe assessed duringformal technicalreviews discussed inChapter 8.  CHAPTER 19 TECHNICAL METRICS FOR SOFTWARE  Error tolerance. The damage that occurs when the program encounters anerror.  Execution ef    fi  ciency. The run-time performance of a program.  Expandability. The degree to which architectural, data, or procedural designcan be extended. Generality. The breadth of potential application of program components.  Hardware independence. The degree to which the software is decoupled fromthe hardware on which it operates.  Instrumentation. The degree to which the program monitors its own opera-tion and identi fi es errors that do occur.  Modularity. The functional independence (Chapter 13) of program compo-nents. Operability. The ease of operation of a program.  Security. The availability of mechanisms that control or protect programs anddata.  Self-documentation. The degree to which the source code provides meaning-ful documentation.  Simplicity. The degree to which a program can be understood without dif  fi -culty.  Software system independence. The degree to which the program is indepen-dent of nonstandard programming language features, operating system char-acteristics, and other environmental constraints. Traceability. The ability to trace a design representation or actual programcomponent back to requirements. Training. The degree to which the software assists in enabling new users toapply the system.The relationship between software quality factors and these metrics is shown inFigure 19.2. It should be noted that the weight given to each metric is dependent onlocal products and concerns. 19.1.2FURPS The quality factors described by McCall and his colleagues [MCC77] represent one of a number of suggested “checklists” for software quality. Hewlett-Packard [GRA87]developed a set of software quality factors that has been given the acronym FURPS—  511 Quality Factors
Related Search
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks