Abstract: Software maintenance is the dominant factor contributing to the high cost of software. In this paper, the software maintenance process and the important software quality attributes that affect the maintenance effort are discussed. One of the most important quality attributes of software maintainability is the stability of a program, which indicates the resistance to the potential ripple effect that the program would have when it is modified. Measures for estimating the stability of a program and the modules of which the program is composed are presented, and an algorithm for computing these stability measures is given. An algorithm for normalizing these measures is also given. Applications of these measures during the maintenance phase are discussed along with an example. An indirect validation of these stability measures is also given. Future research efforts involving application of these measures during the design phase, program restructuring based on these measures, and the development of an overall maintainability measure are also discussed.

Abstract: The contributions of measurement and experimentation to the state of the art in software engineering are reviewed. The role of measurement in developing theoretical models is discussed, and concerns for reliability and validity are stressed. Current approaches to measuring software characteristics are presented as examples. In particular, software complexity metrics related to control flow, module interconnectedness, and Halstead's Software Science are discussed. The use of experimental methods in evaluating cause-effect relationships is also discussed. Example programs of experimental research which investigated conditional statements and control flow are reviewed. The conclusion argues that many advances in software engineering will be related to improvements in the measurement and experimental evaluation of software techniques and practices.

Abstract: In attempting to describe the quality of computer software, one of the more frequently mentioned measurable attributes is complexity of the flow of control. During the past several years, there have been many attempts to quantify this aspect of computer programs, approaching the problem from such diverse points of view as graph theory and software science. Most notable measures in these areas are McCabe's cyclomatic complexity and Halstead's software effort. More recently, Woodward et al. proposed a complexity measure based on the number of crossings, or "knots," of arcs in a linearization of the flowgraph.

Abstract: The behavior of a software system can be modelled in terms of sequences of events, flows, or operations that may occur during execution. To support this approach, a number of non-procedural description languages based on regular expressions have been proposed. These include event expressions, flow expressions, and the many variations of path expressions. The purpose of this paper is to survey and assess these notations, and to suggest some directions for future research.

Abstract: : The Data and Analysis Center for Software (DACS) is being established to serve as a central source for information and data on software technology. This interim report presents the status of the DACS after the initial 18 months of development. Descriptions of the software engineering computer database and the technology information base are provided. This report also contains information on the types of products developed during this reporting period and the technical inquiries received relating to software technology. (Author)

Abstract: An approach to software design representation which is consistent with the concept of engineering blueprints is presented. The main criteria for software engineering blueprints are defined and a network scheme of graphical representation is considered through an overview of Petri net techniques. The concept of an abstract process (AP) is introduced as the basic element of system representation. An abstract process network schema of software design representation is developed and supported by an algebraic system of notation. Methods of AP-net construction are presented and illustrated by examples. The advantages of using the proposed approach in different phases of software engineering are pointed out and the main directions for further research have been identified.

Abstract: 1. Introductio n Software maintenance is an expensive proposition. S M routinely accounts for 50%-80% of total life cycle costs of a softwar e system, and in some cases exceeds 99% of the life cycle cost [17]. Th e problems of SM are especially acute when the systems being maintaine d are the software systems known as embedded computer systems. Characteristically, these systems are large (50-100,000 lines of code) , long-lived (10-15 years or more), must perform with a very high degre e of reliability, and must be constantly updated to meet changin g requirements [4]. The importance of reducing the cost of SM i s recognized in the requirements for the Ada programming environment (th e \"Pebbleman\" document) : \"As software maintenance has become the main cost-factor in th e lifecycle of computerized systems, specific efforts should be mad e to reduce this factor. .. The human factor aspect of the wor k itself, as well as the properties of the environment in whic h maintenance takes place, should be investigated in order to deriv e improved methods, procedures, and tools for maintenance .\" [15 ] In general, there are three main complementary approaches t o the problems of software maintenance : 1. The computer science approach : This approach aims at reducin g the number and severity of software bugs, and making program s easy to modify as requirements change. The emphasis in thi s approach is on the creation and use of such things as structure d technologies, specification and design languages, verificatio n techniques, abstract data types, and improved programmin g languages. 2. The toolkit approach : This approach emphasizes the use of mor e and better tools : symbolic execution packages, test dat a generators, resource monitors, source-level debuggers, etc. Th e belief is that with more sophisticated tools, programmers ma y detect bugs earlier and fix them more easily. 3. The environmental approach : The profusion of sophisticated tool s is negated by the fact that many tools a project would like t o use do not run on the project's machine. Also, the tools do no t have uniform user/tool and tool/tool interfaces. This has le d in recent years [11] to the environmental approach, which take s one of two forms. One form is to have an environment into which

Abstract: Estimates of health risk often depend on extrapolations to low-dose levels of the data from controlled experiments in animal toxicity. The bridge between the simulated and actual settings is of great current concern to statisticians. We lack textbooks and integrated sets of case studies describing the application of operations research and simulation methodology to the health sciences. The most useful set of studies is by Warner and Holloway (University of Michigan Press, 1978); most of the examples deal with the application of queuing and linear programming models to planning of facilities and optimization of resources within a working hospital. I plan to collect case studies of simulations aimed at policy-makers concerned with nationwide standards.

Abstract: Identifying crucial problems in SEPM, this summary of Survey results challenges the computing community to address and solve them.

Abstract: This paper extends previous work on development of a methodology for the prediction of the performance of computer software systems from design level specifications and continuing through implementation. The effects of synchronized behavior, such as results from data reservation in multi-thread executions of data base systems, and competition for host system resources are incorporated. The previous methodology uses hierarchical graphs to represent the execution of software on some host computer system (or on some abstract machine). Performance metrics such as response time were obtained from analysis of these graphs assuming execution of a single copy on a dedicated host. This paper discusses the mapping of these execution graphs upon queueing network models of the host computing environment to yield performance metric estimates for more complex and realistic processing environments.

Abstract: The design of a two-semester course sequence in software engineering is described. These courses, offered at the undergraduate level, are centered around student projects developed in conjunction with local industry; the projects are used as a focal point to motivate and teach software engineering concepts and tools. The goal of the courses is to provide the student with an overview of the entire software development process, experience as a member of a project team, and exposure to a real-world software environment. This paper describes the course organization and topics, and techniques for project selection and monitoring. Results and experience gained to date with this approach are also discussed.

Abstract: It is proposed to express program designs by hierarchical specifications of design decisions A case study of program construction is presented to substantiate the proposal Composition rules based on logic are given for these hierarchical specifications Advantages and disadvantages of the suggestions are assessed

Abstract: In a field as rapidly growing as software engineering, the education problem splits into two major parts-university education and industrial education. (Some of which is given at university locations, as short courses, but considered industrial education here.) Both parts draw on the same underlying disciplines and methodologies. But the people involved-both teachers and students-have different objectives and characteristics. At the university level students are young, inexperienced, and relatively homogeneous in background and abilities. At the industrial level, students are older, more experienced, and vary considerably in background and abilities. In this paper, we discuss the underlying commonalities and the overlaid differences of university and industrial education in software engineering. The commonalities in discipline and methodologies involve the study and understanding of the Software Process, as discussed in Section II of this special issue, and of the "Tools" and "Know How" discussed in Section III. The differences are due to the characteristics and objectives of students, and show up on curricula content and structure and in course definition.

Abstract: There are many pitfalls for the unwary hardware engineer who must develop software. In particular, hardware quality control procedures and concepts can easily be misapplied. The purpose of this paper is to help hardware-oriented engineers apply some of the quality assurance lessons learned by software engineers. We first discuss how software is and is not analogous to hardware, and then outline recommended software engineering approaches for developing high-quality software products. We concentrate on methods for preventing and detecting software error.

Abstract: Software development tools include pre-imple mentation tools for automated analysis and design of software, post-implementation tools for auto mated verification and validation of software, and the familiar implementation tools such as compilers, text editors, loaders, and diagnostic packages.

Abstract: The primary thrust of this paper is to explore many of the problems currently plaguing software development activities and to propose how some of the recently developed management practices may be employed in dealing with them. The practices described range from people organizations (e.g., chief programmer teams) to fully automated engineering tools (e.g., software requirements engineering methodology). A number of techniques are presented. These include methods for coping with communications problems in the requirements definition activity, for evolving a facility which will help increase the productivity of software designers and proggammers, and for maintaining a high degree of visibility during the elusive unit design code and test phase of a project. A very practical view of the management problems and suggested approaches is presented. Key principles, potentials "pitfalls," and unresolved concerns are addressed from a viewpoint of where the state of the art is today and where the industry appears to be heading in the mid-1980's.

Abstract: Good programming demands sound testing, verification, and validation techniques throughout the life cycle–even if the development environment has limited support and resources.

Abstract: Computer organization: hardware/software , Computer organization: hardware/software , مرکز فناوری اطلاعات و اطلاع رسانی کشاورزی

Abstract: Programmers, even in well-organized software environments which utilize some modern software engineering practices, are often lacking of a discipline in their individual programming effort. There has not been an emphasis on discipline in progamming practice, as is traditional in other engineering and scientific fields' instruction. A framework organized to be suitable for early presentation and developing usage is presented and evaluated. It integrates the notions of top-down design, stepwise refinement, structured flowcharting, test case description, and analysis in the context of a framework for systematically developing and concurrently documenting programs. The framework was evaluated in actual usage during introductory programming instruction by comparing it to a typical conventional approach. A comparison of programming effort showed only a 16 percent increase in time required in the disciplined approach, which certainly makes it feasible for introductory instruction. Program quality comparisons were carried out by a comprehensive testing for logic errors in the completed projects. The results were impressively favorable for the disciplined approach.

Abstract: Programming Development at IBM's Santa Teresa Laboratory has been investigating “The Elements of Software Science” as defined by Maurice H. Halstead.1,2 This report summarizes the findings after several large IBM products have been counted and analyzed. Program vocabulary, length, volume and lines of code are discussed and compared. It is shown that the size of a program can be estimated with reasonable accuracy once the vocabulary is known.Within the programming community the traditional measures of quality and productivity have been based upon the number of lines of source statements which have been coded for a given product. Estimating the costs, time duration, number of programmers required, and quality levels also hinge upon “lines-of-code” predictions for the product. Maurice H. Halstead 1,2 has suggested a comprehensive set of software metrics which we are using to examine the characteristics of existing program products. These software metrics do not hinge upon lines-of-code counts but rather upon the counting of operators and operands. This report explains how the “Elements of Software Science” as defined by Professor Halstead relate to IBM data from large programming products. The software science formulas are neither derived nor altered in this paper but are treated as theorems which we have set out to prove or to disprove by measuring Santa Teresa Laboratory program products. We were motivated to look for measures other than lines-of-code because of our historic inability to estimate the size of a project with any consistent degree of accuracy. In performing this study, we have counted and analyzed large volumes of existing program product code. This report focuses upon the Software Science size metrics (length and volume) in comparison to the traditional lines-of-code measure.