waashk/dblp huggingface dataset:
programming cost estimate: is it reasonable? a basic concern when considering a programming cost estimate is its reasonableness. a statistical examination of over thirty completed products was conducted, using least square error methods, to develop an improved method for establishing a central value and an acceptable range of values for programming product cost estimates. eight variables associated with the coding process, such as the number of lines of new and modified basic assembler language and number of new modules, were found to be useful in developing reasonableness equations. using regression equations developed from the variables, we developed reasonableness tests that compare the estimate prepared by the developer to the actual development effort applied to previous products. insight also was gained about programmer productivity, the quality of code estimations, and the optimum number of lines of code per module. estimates are usually based on the experience of the past. but whatever method is used, the main consideration is the error of estimate associated with that method. the basic question about any estimate is: how good is it? the current state of the art of the cost estimating of software projects evolved from the works of walverton1 attempting to correlate the size of effort in person-months with the size of the product expressed in thousand lines of source code (kloc). large dispersion of data forced walston and felix2 to take into account additional variables such as programmer experience and the complexity of the application as well as over twenty variables. putnam3 simplified staffing (life cycle curve) to a small and easily managed set of parameters that could be expressed in the form of nomograms. this paper contributes to the software cost estimation by identifying those variables of the product which were found to be governing: the importance of distinguishing higher level language programming language systems (pls) from low level basic assembler language (bal), the importance of recognizing the major increase of effort if code is modified rather than new code created. the magnitude of these differences is quantified. finally in the analysis of the optional number of modules for a product, a balance is shown between the intramodule complexity and the intermodule complexity. parametric data associated with program product development costs has been actively collected since mid-1976 by the program cost estimating department, now located at ibm's santa teresa laboratory. this data represents the actual person-month resources used to match program development requirements. products that were analyzed are a collection of classic ibm mainframe products: languages (such as cobol, pl/i, apl), utilities (vsam, os utilities, sort, etc.), and data base products (ims, data dictionary, etc.). these are &ldquo;system programs&rdquo; rather than applications. the range and median sizes of the products are shown in table 1. twenty six of the thirty products contain modified modules.
an empirical study of predicate dependence levels and trends. many source code analyses are closely related to and strongly influenced by interdependence among program components. this paper reports results from an empirical study of the interdependences involving program predicates and the formal parameters and global variables which potentially affect them.the findings show that it is possible to eliminate from consideration approximately 30% of the formal parameters, 50% of the 'touched' global variables, and 97% of the 'visible' global variables.another important and encouraging finding is a strong inverse correlation between the number of formal parameters and dependence level. the fact that no such correlation was found for global variables provides evidence to support the conjecture that global variables are harmful.
validation of the coupling dependency metric as a predictor of run-time failures and maintenance measures. the coupling dependency metric (cdm) is a successful design quality metric. here we apply it to four case studies: run-time failure data for a cobol registration system; maintenance data for a c text-processing utility; maintenance data for a c++ patient collaborative care system; and maintenance data for a java electronic file transfer facility. cdm outperformed a wide variety of competing metrics in predicting run-time failures and a number of different maintenance measures. these results imply that coupling metrics may be good predictors of levels of interaction within a software product
bi-criteria models for all-uses test suite reduction. using bi-criteria decision making analysis, a new modelfor test suite minimization has been developed that pursuestwo objectives: minimizing a test suite with regard to a particularlevel of coverage while simultaneously maximizingerror detection rates. this new representation makes it possibleto achieve significant reductions in test suite size withoutexperiencing a decrease in error detection rates. usingthe all-uses interprocedural data flow testing criterion, twobinary integer linear programming models were evaluated,one a single-objective model, the other a weighted-sums bicriteriamodel. the applicability of the bi-criteria model toregression test suite maintenance was also evaluated. thedata show that minimization based solely on definition-useassociation coverage may have a negative impact on the errordetection rate as compared to minimization performedwith a bi-criteria model that also takes into account theability of test cases to reveal error. results obtained withthe bi-criteria model also indicate that test suites minimizedwith respect to a collection of program faults are effectiveat revealing subsequent program faults.
enriching software engineering courses with service-learning projects and the open-source approach. real-world software engineers deal with complex problem. yet many software engineering courses do not involve projects of enough complexity to give students such experience. we sense that service-learning projects, while difficult to manage and sustain, can serve a crucial role in this regard. through trials in a senior-level software engineering course, we discovered that the open-source approach works well to enable students to work on large, multiple-term service-learning projects. we developed grow, a cross-term, cross-team educational software process to meet the challenges of adopting complex, real-world projects in one-term courses, and to sustain service learning.
prototyping a process monitoring experiment. features are often the basic unit of development for a very large software system and represent long-term efforts, spanning up to several years from inception to actual use. developing an experiment to monitor (by means of sampling) such lengthy processes requires a great deal of care in order to minimize casts and to maximize benefits. just as prototyping is often a necessary auxiliary step in a large-scale, long-term development effort, so, too, is prototyping a necessary step in the development of a large-scale, long-term process monitoring experiment. therefore, we have prototyped our experiment using a representative process and reconstructed data from a large and rich feature development. this approach has yielded three interesting sets of results. first, we reconstructed a 30-month time diary for the lead engineer of a feature composed of both hardware and software. these data represent the daily state (where the lead engineer spent the majority of his time) for a complete cycle of the development process. second, we found that we needed to modify our experimental design. our initial set of states did not represent the data as well as we had hoped. this is exemplified by the fact that the "other" category is too large. finally, the data provide evidence for both a waterfall view and an interactive, cyclic view of software development. we conclude that the prototyping effort is a necessary part of developing and installing any large-scale process monitoring experiment.
adding high availability and autonomic behavior to web services. rapid acceptance of the web services architecturepromises to make it the most widely supported andpopular object-oriented architecture to date. oneconsequence is that a wave of mission-critical webservices applications will certainly be deployed incoming years. yet the reliability options available withinweb services are limited in important ways. to use aterm proposed by ibm, web services systems need tobecome far more "autonomic," configuring themselves,diagnosing faults, and managing themselves. highavailability applications need more attention. moreover,the scenarios in which such issues arise often entail verylarge deployments, raising questions of scalability. in thispaper we propose a path by which the architecture couldbe extended in these respects.
journey of enlightenment: the evolution of development at microsoft. like many software companies, microsoft has been doing distributed application development for many years. however, recent changes in the market have altered the rules, both in terms of customer expectations and programming models for ubiquitous interconnected smart devices. these changes have provoked two dramatic shifts in the way we develop software. the first is the creation and use of the .net framework as a simple, secure, and robust platform for device-independent software development, data manipulation, and communications. the second is an agile yet highly disciplined approach to designing, testing, implementing, and verifying our software which presumes all bugs are unacceptable and must be found and fixed early before they impact internal groups, external partners, and eventually our customers. this paper discusses the nature and impact of these two dramatic shifts to the development practices at microsoft.
integrating hundred's of product through one architecture: the industrial it architecture. during the last few years, software product line engineering has gained significant interest as a way for creating software products faster and cheaper. but what architecture is needed to integrate huge amounts of products, from different product lines? this paper describes such an architecture and its support processes and tools. through cases, it is illustrated how the architecture is used to integrate new --- and old --- products in such diverse integration projects as vessel motion control, airport baggage handling systems, pulp&paper and oil&gas, in a very large organization. however, in a large organization it is a challenge to make everyone follow an architecture. steps taken to ensure global architectural consistency are presented. it is concluded that a single architecture can be used to unify development in a huge organization, where the distributed development practices otherwise may prohibit integration of various products.
statestep: a tool for systematic, incremental specification. statestep is an interactive tool for editing and checkingspecifications based on the finite state machine (fsm)model. the tabular notation supported is a novel yet simpleone, first developed to specify the external behaviour of aseries of audio compact disc recorders. the technique helpsto describe system behaviour in a systematic manner, intendedprincipally to ensure that no unusual scenarios, orcorner cases, are overlooked at the specification stage. thenotation is readily understandable and can reduce or eliminatethe need for internal events or other structuring primitives.it supports a naturally incremental approach to specification and seems especially suited to dealing with the kind of complexity that can arise in embedded user interfaces.
improving problem-oriented mailing list archives with mcs. developers often use electronic mailing lists when seeking assistance with a particular software application. the archives of these mailing lists provide a rich repository of problem-solving knowledge. developers seeking a quick answer to a problem find these archives inconvenient, because they lack efficient searching mechanisms, and retain the structure of the original conversational threads which are rarely relevant to the knowledge seeker.we present a system called mcs which improves mailing list archives through a process called condensation. condensation involves several tasks: extracting only messages of longer-term relevance, adding metadata to those messages to improve searching, and potentially editing the content of the messages when appropriate to clarify. the condensation process is performed by a human editor (assisted by a tool), rather than by an artificial intelligence (ai) system.we describe the design and implementation of mcs, and compare it to rlated systems. we also present our experiences condensing a 1428 message mailing list archive to an archive containing only 177 messages (an 88% reduction). the condensation required only 1.5 minutes of editor effort per message. the condensed archive was adopted by the users of the mailing list.
cobra: a hybrid method for software cost estimation, benchmarking, and risk assessment. current cost estimation techniques have a number of drawbacks. for example, developing algorithmic models requires extensive past project data. also, off-the-shelf models have been found to be difficult to calibrate but inaccurate without calibration. informal approaches based on experienced estimators depend on estimators' availability and are not easily repeatable, as well as not being much more accurate than algorithmic techniques. we present a method for cost estimation that combines aspects of algorithmic and experiential approaches (referred to as cobra, cost estimation, benchmarking, and risk assessment). we find through a case study that cost estimates using cobra show an average are of 0.09. although we do not have the room to describe the benchmarking and risk assessment parts, the reader will find detailed information in (briand et al., 1997)
an assessment and comparison of common software cost estimation modeling techniques. this paper investigates two essential questions related to data-driven, software cost modeling: (1) what modeling techniques are likely to yield more accurate results when using typical software development cost data? and (2) what are the benefits and drawbacks of using organization-specific data as compared to multi-organization databases? the former question is important in guiding software cost analysts in their choice of the right type of modeling technique, if at all possible. in order to address this issue, we assess and compare a selection of common cost modeling techniques fulfilling a number of important criteria using a large multi-organizational database in the business application domain. namely, these are: ordinary least squares regression, stepwise anova, cart, and analogy. the latter question is important in order to assess the feasibility of using multi-organization cost databases to build cost models and the benefits gained from local, company-specific data collection and modeling. as a large subset of the data in the multi-company database came from one organization, we were able to investigate this issue by comparing organization-specific models with models based on multi-organization data. results show that the performances of the modeling techniques considered were not significantly different, with the exception of the analogy-based models which appear to be less accurate. surprisingly, when using standard cost factors (e.g., cocomo-like factors, function points), organization specific models did not yield better results than generic, multi-organization models.
explaining the cost of european space and military projects. there has been much controversy in the literature on several issues underlying the construction of parametric software development cost models. for example, it has been argued whether (dis)economies of scale exist in software production, what functional form should be assumed between effort and product size, whether cocomo factors were useful, and whether the cocomo factors are independent. answers to such questions should help software organizations define suitable data collection programs and well-specified cost models. we use a data set collected by the european space agency to perform such an investigation. to ensure a certain degree of consistency in our data, we focus our analysis on a set of space and military projects that represent an important application domain and the largest subset in the database. these projects have been performed, however, by a variety of organizations. first, our results indicate that two functional forms are plausible between effort and product size: linear and log-linear. this also means that different project subpopulations are likely to follow different functional forms. second, besides product size, the strongest factor influencing cost appears to be team size. larger teams result in substantially lower productivity, which is interesting considering this attribute is rarely collected in software engineering cost databases. third, although some cocomo factors appear to be useful and significant covariates, they play a minor role in explaining project effort.
automated, contract-based user testing of commercial-off-the-shelf components. commercial-off-the-shelf (cots) components provide a means to construct software (component-based) systems in reduced time and cost. in a cots component software market there exist component vendors (original developers of the component) and component users (developers of the component-based systems). the former provide the component to the user without source code or design documentation, and as a result it is difficult for the latter to adequately test the component when deployed in their system. in this article we propose a framework that clarifies the roles and responsibilities of both parties so that the user can adequately test the component in a deployment environment and the vendor does not need to release proprietary details. then, based on this framework we combine and adapt two specification-based testing techniques and describe (and implement) a method for the automated generation of adequate test sets. an evaluation of our approach on a case study demonstrates that it is possible to automatically generate cost effective test sequences and that these test sequences are effective at detecting complex errors.
a replicated assessment and comparison of common software cost modeling techniques. delivering a software product on time, within budget, and to an agreed level of quality is a critical concern for many software organizations. underestimating software costs can have detrimental effects on the quality of the delivered software and thus on a company's business reputation and competitiveness. on the other hand, overestimation of software cost can result in missed opportunities to funds in other projects. in response to industry demand, a myriad of estimation techniques has been proposed during the last three decades. in order to assess the suitability of a technique from a diverse selection, its performance and relative merits must be compared.the current study replicates a comprehensive comparison of common estimation techniques within different organizational contexts, using data from the european space agency. our study is motivated by the challenge to assess the feasibility of using multi-organization data to build cost models and the benefits gained from company-specific data collection. using the european space agency data set, we investigated a yet unexplored application domain, including military and space projects. the results showed that traditional techniques, namely, ordinary least-squares regression and analysis of variance outperformed analogy-based estimation and regression trees. consistent with the results of the replicated study no significant difference was found in accuracy between estimates derived from company-specific data and estimates derived from multi-organizational data.
using simulation to empirically investigate test coverage criteria based on statechart. a number of testing strategies have been proposedusing state machines and statecharts as test models inorder to derive test sequences and validate classes orclass clusters. though such criteria have the advantage ofbeing systematic, little is known on how cost effective theyare and how they compare to each other.this article presents a precise simulation and analysisprocedure to analyze the cost-effectiveness of statechart-basedtesting techniques. we then investigate, using thisprocedure, the cost and fault detection effectiveness ofadequate test sets for the most referenced coveragecriteria for statecharts on three different representativecase studies. through the analysis of common results anddifferences across studies, we attempt to draw moregeneral conclusions regarding the costs and benefits ofusing the criteria under investigation.
modeling and managing risk early in software development. the authors present an automated modeling technique which can be used as an alternative to regression techniques to improve the quality of the software development process. the modeling process will allow for the reliable detection of potential problem areas and for the interpretation of the cause of the problem so that the most appropriate remedial action can be taken. it is shown that it can be used to facilitate the identification and aid the interpretation of the significant trends which characterize high risk components in several ada systems. the effectiveness of the technique is evaluated based on a comparison with logistic regression based models
investigating quality factors in object-oriented designs: an industrial case study. this paper aims at empirically exploring the relationships between most of the existing coupling and cohesion measures for object-oriented (oo) systems, and the fault-proneness of oo system classes. the underlying goal of such a study is to better understand the relationship between existing design measurement in oo systems and the quality of the software developed. the study described here is a replication of an analogous study conducted in an university environment with systems developed by students. in order to draw more general conclusions and to (dis)confirm the results obtained there, we now replicated the study using data collected on an industrial system developed by professionals. results show that many of our findings are consistent across systems, despite the very disparate nature of the systems under study. some of the strong dimensions captured by the measures in each data set are visible in both the university and industrial case study. for example, the frequency of method invocations appears to be the main driving factor of fault-proneness in all systems. however, there are also differences across studies which illustrate the fact that quality does not follow universal laws and that quality models must be developed locally, wherever needed.
a procedure for designing abstract interfaces for device interface modules. this paper describes the abstract interface principle and shows how it can be applied in the design of device interface modules. the purpose of this principle is to reduce maintenance costs for embedded real-time software by facilitating the adaptation of the software to altered hardware interfaces. this principle has been applied in the naval research laboratory's redesign of the flight software for the navy's a-7 aircraft. this paper discusses a design approach based on the abstract interface principle and presents solutions to interesting problems encountered in the a-7 re-design. the specification document for the a-7 device interface modules is available on request; it provides a fully worked out example of the design approach discussed in this paper.