Marciniak, J.J.: Encyclopedia of Software Engineering. John Wiley & Sons, Inc., New York, NY, USA (2002) 61 62  Home/Search   Document Not in Database   Summary   Related Articles   Check

....versions is to incorporate additional parts of standards. 5. New version of hardware, operating system, or third party component covers more functionality: The above categories are all examples of that the software system boundaries expand to support more of the tasks that users expect of them [ML 94] Naturally this is also true on the levels below the system. Should a new version of the layers of functionality under the product line architecture appear, developers will naturally try to use these lower level libraries, resulting in functionality being removed from the PLA components. 6. ....

Marciniak, J.L. (Editor), "Encyclopedia of Software Engineering", Lehman, M.M., on "Software Evolution", John Wiley & Sons, 1994.

....must all still be updated. This makes adoption of technologies supporting mobility slow and costly within existing infrastructures. 3.1.1. 2 Fault Tolerance and Concurrency Traditionally, fault tolerance has referred to building subsystems from redundant components that are placed in parallel [34]. This applies to both hardware and software systems. An example is the computer system for the space shuttle [38] which runs four redundant copies of the same computer. These computers are grouped in pairs, with one pair being in control as long as their results agree with each other. In the ....

J. J. Marciniak, "Encyclopedia of Software Engineering", John Wiley and Sons, 1994.

....Safety: This is a requirement that concerns about inadvertent actions against computer systems. This involves ensuring that the software will execute within a system context without resulting in 21 unacceptable risk (this must be defined considering political, moral and economical decisions) [Mar94]. Availability: This ensures that the resources of the system will be usable whenever they are needed by an authorised user. 3. Operation constraints These include physical constraints (size, weight, power) personnel availability, skill level considerations, accessibility for ....

....oriented analysis emerged basically from object oriented design to extend the paradigm to the beginning of software development as a way to keep its homogeneity. Shlaer and Mellor s method [SM88] was one of the pioneers of object oriented analysis. Some people consider JSD to be object oriented [Mar94]. However, the absence of the concepts of class and inheritance in its model prevents it from being classified as an object oriented method. Object oriented analysis is a method of analysis that investigates requirements from the viewpoint of objects, found in the informal description of the ....

[Article contains additional citation context not shown here]

Marciniak, J.J. (Editor-in-Chief). Encyclopedia of Software Engineering. John Wiley and Sons, Inc., 1994.

....to implement some extensions to the SMB protocol. 5. New version of hardware, operating system, or third party component covers more functionality: The above categories are all examples of that the software system boundaries expand to support more of the tasks that users expect of them [ML 94] Naturally this is also true on the levels below your system. Should a new version of the layers of functionality under your product line architecture appear that supports more of the functionality you use, you will naturally try to use these lower level libraries, resulting in functionality ....

Marciniak, J.L. (Editor), "Encyclopedia of Software Engineering", Lehman, M.M., on "Software Evolution", John Wiley & Sons, 1994.

.... Reusable Model Architecture Style Domain Specific Reusable Model Figure 6: Relationship of model 4 Software Engineering Models There have been efforts in late 80s and early 90s to perform researches in model based software engineering under various names such as domain analysis ( 16] 17] [24], 26] domain specific software architecture ( 3] 24] 25] and architecture principles ( 12] 13] 20] 26] 29] 31] 32] In this section, results from these efforts are integrated under a model based software engineering framework. A model is a pattern of something to be made ....

.... Model Figure 6: Relationship of model 4 Software Engineering Models There have been efforts in late 80s and early 90s to perform researches in model based software engineering under various names such as domain analysis ( 16] 17] 24] 26] domain specific software architecture ( 3] [24], 25] and architecture principles ( 12] 13] 20] 26] 29] 31] 32] In this section, results from these efforts are integrated under a model based software engineering framework. A model is a pattern of something to be made and we can think of this at many different levels of ....

John J. Marciniak, Domain-Specific Reuse, Encyclopedia of Software Engineering, John Wiley & Sons, 1992.

....7.5.3 The obfuscation priority of the source code object S. C H A P T E R 1 Introduction From small beginnings come great things. Proverb 1. 1 Reverse Engineering An extreme case of reverse engineering is taking someone else s product apart to determine how it functions (see Marciniak [35], pp. 1077 1084) More generally, reverse engineering involves analysing an existing system, regardless of ownership. By itself, reverse engineering is not illegal, and in fact it is commonly used to improve one s own products. Reverse engineering can reveal design flaws that are not otherwise ....

....it is necessary to first gain physical access to it. Using disassemblers or decompilers [8] the reverse engineer can decompile it to source code, then analyse its control flow and data structures. Additional tools such as program slicers may be used to perform this analysis (see Marciniak [35], pp. 873 877) One of the most important legitimate uses of software reverse engineering is recovering lost information about a system. Businesses are still using original COBOL language programs for the sake of being able to access old records. The source code for these programs may no longer ....

[Article contains additional citation context not shown here]

John J. Marciniak, editor. Encyclopedia of Software Engineering. John Wiley & Sons, Inc, 1994. ISBN 0-471-54004-8.

....to replicate a poorly reported experiment. The lure of cheap, relatively pollution free energy in abundance, was an exceptional motivation. Regarding the frequency of external replication work of software engineering experiments, we have been unable to find examples. Two recent reference works [41, 40] do not discuss external replication nor cite examples (though [40] provides a good discussion of independent verification and validation of software by an independent group different from the software development team) Reviews in the area of software testing and maintenance where empirical work ....

....pollution free energy in abundance, was an exceptional motivation. Regarding the frequency of external replication work of software engineering experiments, we have been unable to find examples. Two recent reference works [41, 40] do not discuss external replication nor cite examples (though [40] provides a good discussion of independent verification and validation of software by an independent group different from the software development team) Reviews in the area of software testing and maintenance where empirical work is relatively commonplace make no mention of external replication ....

J. Marciniak, editor. Encyclopedia of Software Engineering, volume 1 and 2. John Wiley and Sons, Inc., 1994.

....6. Results We present the results of most of our comparisons in tabular form. The tables contain reuse levels for lines and words, lengths, and in some cases are indexed by chapter title. Detailed comparisons of some items are included. We use the following notation in presenting T E X: [21] Introduction to the syntactic routines. Let s pause a moment now and try to look at the Big Picture. The TeX program consists of three main parts: syntactic routines, semantic routines, and output routines. The chief purpose of the = syntactic routines is to deliver the user s input to ....

Marciniak JJ (Editor-in-Chief) (1994) Encyclopedia of Software Engineering. Vol. 1, John Wiley & Sons

....at level n if it has n Gamma 1 superclasses. The level of the deepest leaf class is quoted as the depth of the hierarchy. Maintainability: ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment [26]. Standard significance testing was adopted and for the first experiment the stated null hypothesis was: H 0 The use of a hierarchy of 3 levels of inheritance depth does not affect the maintainability of object oriented programs, to be rejected in favour of the alternative hypothesis H 1 The ....

J. Marciniak, editor. Encyclopedia of Software Engineering, volume 1 and 2. John Wiley and Sons, Inc., 1994.

....with the quality of the outputs that software produces. 1. 1 Extended Propagation Analysis Differs from Traditional Measures of Fault Tolerance Traditionally, fault tolerance refers to building subsystems from redundant components that are placed in parallel to ensure higher quality systems [2]. Unlike traditional fault tolerance, EPA not only seeks to aid developers in increasing quality, but it also measures the quality of software outputs. In order to measure how good software outputs are, we introduce the notion of failure tolerance. Software is failure tolerant if and only if: ....

J. J. MARCINIAK. Encyclopedia of Software Engineering. Wiley, 1994.

No context found.

Marciniak, J.J.: Encyclopedia of Software Engineering. John Wiley & Sons, Inc., New York, NY, USA (2002) 61 62

No context found.

Marciniak (Ed.), Encyclopedia of software engineering (Vol. 1, pp. 528--532). New York: John Wiley. Boehm, B. W., Brown, J. R., & Lipow, M. (1976). Quantitative evaluation of software quality. In Proceedings of the 2nd international conference on software engineering, october 13-15 (pp. 592--605). San Francisco, CA.

No context found.

Marciniak, John J., editor, Encyclopedia of Software Engineering, v. 1, pp 958-969, John Wiley & Sons, 1994

No context found.

J. J. Marciniak, \Veri cation and validation, " in Encyclopedia of Software Engineering, vol. 2, pp. 1409-1433, Whiley Interscience, 1994.

No context found.

Marciniak, editor, Encyclopedia of Software Engineering. Wiley & Sons, Inc., 1994.

No context found.

J. J. Marciniak, editor. Encyclopedia of Software Engineering, volume 1-2. John Wiley & Sons, New York, 1. edition, 1994.

No context found.

J. J. Marciniak, editor. Encyclopedia of Software Engineering, volume 1. John Wiley & Sons, New York, 1994.

No context found.

John J. Marciniak, editor. Encyclopedia of Software Engineering. John Wiley and Sons, 1994.

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