M. Deutsch and R. Willis. Software Quality Engineering - A Total Technical and Management Approach, Prentice Hall, 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....may be misleading because a person with a developer view of a product does not necessarily have a developer view of a resource. Instead, the various purposes of application of an object may be considered different ways of using the object. Thus, categories of various user needs can be identified (Deutsch, 1988) as indicated in Figure 4. The user, or more generally, the customer, in this context, is not necessarily the end user of a software system. While looking at roles rather than purposes may be a simple and straightforward way of approaching quality of products, processes and resources, it is less ....

....possibilities exist: The object may be applied in order to solve a problem (thus creating profit) or it may be developed in order to be sold (thus creating profit) These two instances of the overall purpose are called the consumer and supplier (Basili, 1995) User needs Figure 4. User needs (Deutsch, 1988) Operational Maintenance Functional Performance Change Management Figure 5. Views of quality. Overall purpose Functional Management Change Supplier Consumer Maintenance Operational Overall quality Administrative Applicative Interaction 2.5 Product Quality 21 The dimension denoting overall ....

[Article contains additional citation context not shown here]

M. Deutsch and R. Willis. Software Quality Engineering - A Total Technical and Management Approach, Prentice Hall, 1988.

....However, the functional requirements is not enough in achieving software quality. What we need to do is to add quality to software during the engineering process. To achieve this, testers must be conscious of quality requirements at the same time they are building in functional requirements[4]. In the 4 other words, the objective of this paper is to answer the two crucial questions in software testing: When to stop testing (whether distributed or not) How good the software is after testing Therefore, requirements specification must include the software requirements, test ....

Deutsch, M. S. & Willis, R. R., Software Quality Engineering: A Total Technical and Management Approach. Prentice Hall, Inc., Englewood Cliffs, NJ, 1988.

....systems. It is also interesting to note that both definitions are probabilistic. Finally, we note that the second definition includes the notion of degraded or different service, and requires that it be defined. In the context of software engineering, Deutsch has offered the following defin ition[4]: Survivability: The degree to which essential functions are still available even though some part of the system is down. This definition is not sufficient for our needs. If it were applied to a critical information system in this form, the user of the system could not be sure which functions ....

Deutsch, M.S. & Willis, R.R., Software Quality Engineering: A Total Technical and Management Approach, Englewood Cliffs, NJ: Prentice-Hall, 1988.

....rate . Compliance to the project UI guidelines . Clarity of documentation Product quality characteristics do not necessarily vary between OTS reuse evaluation cases as much as product functionality. In fact, some general product quality characteristics have been proposed over the years [10,17,26] and these can be used a template for defining this criteria. Typically the structure and relationships of product quality characteristics remain relatively unchanged between OTS evaluation cases but their acceptable values may vary more. An example of a product quality characteristics hierarchy ....

M. S. Deutsch and R. R. Willis. Software Quality Engineering - A total Technical and Management Approach, Englewood Cliffs: Prentice-Hall, 1988. 317 pages.

....of the final product quality. Quality models are also complemented by a collection of activities that influence criteria and hence factors. Performing an activity is then a means to control the overall quality of a product, hopefully improving it. We refer the reader to Deutsch and Willis [7] for an introduction to software quality models. In our context, the advantages of defining a quality model of requirements include descriptive and prescriptive uses of the model in the analysis and control of requirements documents quality. Within the scope of a project, quality models are ....

M. S. Deutsch and R. R. Willis. Software Quality Engineering: A Total Technical and Management Approach. Prentice Hall, 1988.

....without disturbing overall network function. This has been a critical consideration since our workstation cluster is constantly in use for production purposes which may not be disrupted under any circumstances. The Neuronet package conforms to the spiral life cycle model of software development (Deutsch Willis, 1988); i.e. each application in the package is conceived and implemented as an evolving prototype. The package including RDRAW was originally implemented on a network of Digital Equipment Corporation PDP 11 computers. The remote display version of RDRAW was developed when Neuronet was ported to a ....

M. Deutsch, R. Willis. Software Quality Engineering: A Total Technical and Management Approach. Prentice-Hall; Englewood Cliffs, NJ, 1988.

....measures did not previously exist. Additional measures were added to five cells that may have previously had incomplete measurement. 8. CONCLUSIONS Often there are many metrics which attempt to measure the same dimension of the same level. The collection of measurement data is very expensive [8]. However, the collection of multiple measures to measure the same dimension of the same level of software can be useful. The collection of multiple measures allows them to be compared to each other to either confirm that they do indeed measure the same dimension or establish that one (or more) of ....

Deutsch, Michael S., and Ronald R. Willis, Software Quality Engineering: A Total Technical and Management Approach, Prentice-Hall, Englewood Cliffs, NJ, 1988.

....cation of the nal product quality. Quality models are also complemented by a collection of activities that in uence criteria and hence factors. Performing an activity is then a means to control the overall quality of a product, hopefully improving it. We refer the reader to Deutsch and Willis [7] for an introduction to software quality models. In our context, the advantages of de ning a quality model of requirements include descriptive and prescriptive uses of the model in the analysis and control of requirements documents quality. Within the scope of a project, quality models are ....

M. S. Deutsch and R. R. Willis. Software Quality Engineering: A Total Technical and Management Approach. Prentice Hall, 1988.

....for this system are expressed in approximately 3,100 pages of highly structured natural language. The CAATS Software Requirements Specifications (SRSs) is based on the concept of a thread, namely, a path through a system that connects an external event or stimulus to an output event or response [4]. This threads based approach differs significantly from other traditional approaches to software requirements specification such as Structured Analysis. Given that much of the software requirements specification effort for this project was nearing completion when our investigation began, we have ....

) Michael S. Deutsch and Ronald R. Willis. Software Quality Engineering - A Total Technical and Management Approach. Prentice Hall Series in Software Engineering, Englewood Cliffs, New Jersey, 1988.

....However, the functional requirements is not enough in achieving software quality. What we need to do is to add quality to software during the engineering process. To achieve this, testers must be conscious of quality requirements at the same time they are building in functional requirements[4]. In the other words, the objective of this paper is to answer the two crucial questions in software testing: # When to stop testing (whether distributed or not) # How good the software is after testing Therefore, requirements specification must include the software requirements, test ....

Deutsch, M. S. & Willis, R. R., Software Quality Engineering: A Total Technical and Man-- agement Approach. Prentice Hall, Inc., Englewood Cliffs, NJ, 1988.

....the concomitant heavily increasing costs of failure. The production of high quality information software systems is an important issue for the near future (Musa, 1990) Software quality is the degree to which a customer or user perceives the software as meeting his or her composite expectations (Deutsch and Willis, 1988). To achieve software quality, it is essential that the software is tested. This is not only a developmental activity for discovering product defects but also anindependentassessment of software execution in an operating environment. It involves the execution of a deterministic 3 software ....

Deutsch, M.S. and Willis, R.R. (1988) Software Quality Engineering--A Total Technical and Management Approach (Prentice Hall International , London).

....that a software product is a solution to a problem, and thus the quality of the product becomes to which extent the problem is solved (Juran, 1974) We will use the latter definition throughout this paper. 2.1. Quality factors For the purpose of discussing product quality, we refer to work by Deutsch and Willis (1988). Their quality model has a number of similarities with other early work on quality (Gillies, 1992) by e.g. McCall (1977) and Boehm (1978) In their view, product includes code, design and documentation. Their model makes a distinction between aspects of quality that an engineer can affect ....

....users view of quality is decomposed in a way that is similar to the models of McCall and Boehm, as shown in Figure 3. For the four low level quality aspects, the breakdown into quality factors results in a list of 15 entries. For a more elaborate discussion of these quality factors, we refer to Deutsch (1988). User needs Figure 1 User needs (Deutsch, 1988) Operational Maintenance Functional Performance Change Management 3 The 15 quality factors are based on how the user perceives quality. In order to actually improve quality we need to tie the quality factors to attributes of the product which we ....

[Article contains additional citation context not shown here]

Deutsch, M., Willis, R. 1988. Software Quality Engineering - A Total Technical and Management Approach, Prentice Hall.

....were not included for those cells for which validated measures already exist. CONCLUSION AND FUTURE RESEARCH As Table 1 shows, often there are multiple metrics available which attempt to measure the same dimension of the same level. The collection of measurement data is usually very expensive [6]; nevertheless, the application of multiple measures to measure the same dimension of the same level of software can be useful. The collection of data for multiple measures allows the measures to be compared to each other to either confirm that they do indeed measure the same dimension or ....

Deutsch, Michael S., and Ronald R. Willis, Software Quality Engineering: A Total Technical and Management Approach, Prentice-Hall, Englewood Cliffs, NJ, 1988.

....the suggestions of total quality management (TQM) and QFD. Like the inter disciplinary requirements discovery techniques mentioned in the previous paragraph, these techniques could all be adopted and customized for software with little risk to user organizations. Illustrations are provided by Deutsch and Willis [1988] and Gilb [1988] When the development project is uncertain about key features of the project or problem, it is advisable to keep track of all the assumptions that must be made. Yet these records do not usually find their way into more formal CASE representations. This is yet another example where ....

Deutsch, M.S. and R.R. Willis, Software Quality Engineering: A total technical and management approach, Prentice-Hall, 1988.

....heavily increasing costs of failure. The production of high quality information software systems is an important issue for the near future (Musa, 1990) Software quality is the degree to which a cus 2 tomer or user perceives the software as meeting his or her composite expectations (Deutsch and Willis, 1988). To achieve software quality, it is essential that the software is tested. This is not only a developmental activity for discovering product defects but also anindependentassessment of software execution in an operating environment. It involves the execution of a deterministic software system ....

Deutsch, M.S. and Willis, R.R. (1988) Software Quality Engineering--A Total Technical and Management Approach (Prentice Hall International , London).

....However, the functional requirements is not enough in achieving software quality. What we need to do is to add quality to software during the engineering process. To achieve this, testers must be conscious of quality requirements at the same time they are building in functional requirements[4]. In the 5 other words, the objective of this paper is to answer the two crucial questions in software testing: # When to stop testing (whether distributed or not) # How good the software is after testing Therefore, requirements specification must include the software requirements, test ....

Deutsch, M. S. & Willis, R. R., Software Quality Engineering: A Total Technical and Management Approach. Prentice Hall, Inc., Englewood Cliffs, NJ, 1988.

No context found.

M. Deutsch, R. Willis. Software Quality Engineering: A Total Technical and Management Approach. Prentice-Hall; Englewood Cliffs, NJ, 1988.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC