http://www.bibsonomy.org/burst/user/neilernst/softwareBibSonomy BuRST Feed for /user/neilernst/software2008-10-16T06:40:14+02:00http://www.bibsonomy.org/bibtex/2304a8039adccb65bcb9e81cef2fca327/neilernstneilernst2008-10-10T05:21:05+02:00software empirical Open-source <span style="color:#555555;">E. <a href="http://www.bibsonomy.org/author/Capra">Capra</a> und C. <a href="http://www.bibsonomy.org/author/Francalanci">Francalanci</a> und F <a href="http://www.bibsonomy.org/author/Merlo">Merlo</a> </span><em>IEEE Transactions on Software Engineering</em>(<em>2008</em>) <em>in press . </em>Fri Oct 10 05:21:05 CEST 2008IEEE Transactions on Software Engineeringin pressAn Empirical Study on the Relationship Between Software Design Quality, Development Effort and Governance in Open Source Projects2008software empirical Open-source The relationship among software design quality, development effort, and governance practices is a traditional research problem. However, the extent to which consolidated results on this relationship remain valid for open source (OS) projects is an open research problem. An emerging body of literature contrasts the view of open source as an alternative to proprietary software and explains that there exists a continuum between closed and open source projects. This paper hypothesizes that as projects approach the OS end of the continuum, governance becomes less formal. In turn a less formal governance is hypothesized to require a higher-quality code as a means to facilitate coordination among developers by making the structure of code explicit and facilitate quality by removing the pressure of deadlines from contributors. However, a less formal governance is also hypothesized to increase development effort due to a more cumbersome coordination overhead. The verification of research hypotheses is based on empirical data from a sample of 75 major OS projects. Empirical evidence supports our hypotheses and suggests that software quality, mainly measured as coupling and inheritance, does not increase development effort, but represents an important managerial variable to implement the more open governance approach that characterizes OS projects which, in turn, increases development effort.http://www.bibsonomy.org/bibtex/2dd7d71bb02462f23b6acb0a159c4bd52/neilernstneilernst2008-09-28T00:03:51+02:00software empirical <span style="color:#555555;">Khaled El <a href="http://www.bibsonomy.org/author/Emam">Emam</a> und A. <a href="http://www.bibsonomy.org/author/Güneş Koru">G&#252;ne&#351; Koru</a> </span><em>IEEE Software</em><em>25(5):84-90</em><em>Sept.-Oct.2008. </em>Sun Sep 28 00:03:51 CEST 2008IEEE SoftwareSept.-Oct. 584-90A Replicated Survey of IT Software Project Failures252008software empirical Despite various industry reports about the failure rates of software projects, there's still uncertainty about the actual figures. Researchers performed a global Web survey of IT departments in 2005 and 2007. The results suggest that the software crisis is perhaps exaggerated and that most software projects deliver. However, the overall project failure rate, including cancelled and completed but poorly performing projects, remains arguably high for an applied discipline.ScienceDirect - Information and Software Technology : Empirical studies of agile software development: A systematic reviewhttp://www.bibsonomy.org/bibtex/2847dedc5d317863634dcb750289a009a/neilernstneilernst2008-09-18T02:16:13+02:00must-read software agile <span style="color:#555555;">Tore <a href="http://www.bibsonomy.org/author/Dybå">Dyb&#229;</a> und Torgeir <a href="http://www.bibsonomy.org/author/Dingsøyr">Dings&#248;yr</a> </span><em>Information and Software Technology</em><em>50(9-10):833--859</em><em>#aug#2008. </em>Thu Sep 18 02:16:13 CEST 2008Information and Software Technology#aug#9-10833--859Empirical studies of agile software development: A systematic review502008must-read software agile Agile software development represents a major departure from traditional, plan-based approaches to software engineering. A systematic review of empirical studies of agile software development up to and including 2005 was conducted. The search strategy identified 1996 studies, of which 36 were identified as empirical studies. The studies were grouped into four themes: introduction and adoption, human and social factors, perceptions on agile methods, and comparative studies. The review investigates what is currently known about the benefits and limitations of, and the strength of evidence for, agile methods. Implications for research and practice are presented. The main implication for research is a need for more and better empirical studies of agile software development within a common research agenda. For the industrial readership, the review provides a map of findings, according to topic, that can be compared for relevance to their own settings and situations.http://www.bibsonomy.org/bibtex/21f8ee50a8b956cd3ef957867b6bc3c49/neilernstneilernst2008-06-24T20:17:31+02:00systems software <span style="color:#555555;">Barry <a href="http://www.bibsonomy.org/author/Boehm">Boehm</a> und Jo Ann <a href="http://www.bibsonomy.org/author/Lane">Lane</a> </span><em>Crosstalk: Journal of Defence Software Engineering</em><em>May2006. </em>Tue Jun 24 20:17:31 CEST 2008Crosstalk: Journal of Defence Software EngineeringMay21st Century Processes for Acquiring 21st Century Software-Intensive Systems of Systems2006systems software Our experiences in helping to define, acquire, develop, and assess 21st century software-intensive systems of systems (SISOS) have taught us that traditional 20th century acquisition and development processes do not work well on such systems. This article summarizes the characteristics of such systems, and indicates the major problem areas in using traditional processes on them. We also present new processes that we and others have been developing, applying, and evolving to address 21st century SISOS. These include extensions to the risk-driven spiral model to cover broad (many systems), deep (many supplier levels), and long (many increments) acquisitions needing rapid fielding, high assurance, adaptability to high-change traffic, and complex interactions with evolving commercial off-the-shelf products, legacy systems, and external systems. MetaPress - Book Chapterhttp://www.bibsonomy.org/bibtex/2b2f51f6db64467f11e7c2b18fb108ced/neilernstneilernst2008-06-19T19:01:43+02:00product software scenario line <span style="color:#555555;">Eelco <a href="http://www.bibsonomy.org/author/Rommes">Rommes</a> und Pierre <a href="http://www.bibsonomy.org/author/America">America</a> </span><em>Software Product Lines - Research Issues in Engineering and Management, </em><em>Springer, </em><em>Berlin, </em>(<em>2006</em>)Thu Jun 19 19:01:43 CEST 2008BerlinSoftware Product Lines - Research Issues in Engineering and Management3--52A Scenario-Based Method for Software Product Line Architecting2006product software scenario line Software product line engineering implies making a long-term investment in a common architecture. This architecture must support the derivation of potentially many generations of products in the line. Short-term and long-term business considerations should be well balanced when defining and evolving software product line architectures. Established methods for architecting lack support for doing this in an efficient manner. We present a scenariobased architecting method that addresses this problem. The method uses various types of scenario to ensure that the long-term future is taken into account, and to enable the efficient description, evaluation and comparison of multiple candidate architectures in parallel.Not previously uploadedhttp://www.bibsonomy.org/bibtex/290e3c09f10e3b5ec06f3d79658cce415/neilernstneilernst2008-05-27T15:06:33+02:00software taxonomy evolution <span style="color:#555555;">Ned <a href="http://www.bibsonomy.org/author/Chapin">Chapin</a> und Joanne E. <a href="http://www.bibsonomy.org/author/Hale">Hale</a> und Juan <a href="http://www.bibsonomy.org/author/Fernandez-Ramil">Fernandez-Ramil</a> und Wui-Gee <a href="http://www.bibsonomy.org/author/Tan">Tan</a> </span><em>Journal of Software Maintenance and Evolution: Research and Practice</em><em>13(1):3--30</em>(<em>2001</em>)Tue May 27 15:06:33 CEST 2008Journal of Software Maintenance and Evolution: Research and Practice13--30Types of software evolution and software maintenance132001software taxonomy evolution The past two decades have seen increasing sophistication in software work. Now and in the future, the work of both practitioners and researchers would be helped by a more objective and finer granularity recognition of types of software evolution and software maintenance activities as actually done. To these ends, this paper proposes a clarifying redefinition of the types of software evolution and software maintenance. The paper bases the proposed classification not on people's intentions but upon objective evidence of maintainers' activities ascertainable from observation of activities and artifacts, and/or a before and after comparison of the software documentation. The classification includes taking into account in a semi-hierarchical manner evidence of the change or lack thereof in: (1) the software, (2) the documentation, (3) the properties of the software, and (4) the customer-experienced functionality. A comparison is made with other classifications and typologies. The paper provides a classified list of maintenance activities and a condensed decision tree as a summary guide to the proposed evidence-based classification of the types of software evolution and software maintenance.http://www.bibsonomy.org/bibtex/23b4ebe26f9f306d3bd619612f857ef14/neilernstneilernst2008-05-27T03:20:42+02:00software seminal <span style="color:#555555;">Frederick Phillips <a href="http://www.bibsonomy.org/author/Brooks">Brooks</a> </span><em>Addison-Wesley, </em><em>Reading, Mass. u.a., </em>(<em>1975</em>)Tue May 27 03:20:42 CEST 2008Reading, Mass. u.a.The mythical man-month1975software seminal http://www.bibsonomy.org/bibtex/251b0ef8b8fa0269a593e586063d5048f/neilernstneilernst2008-05-25T01:01:16+02:00software should-read agile empirical <span style="color:#555555;">M. <a href="http://www.bibsonomy.org/author/Pikkarainen">Pikkarainen</a> und J. <a href="http://www.bibsonomy.org/author/Haikara">Haikara</a> und O. <a href="http://www.bibsonomy.org/author/Salo">Salo</a> und P. <a href="http://www.bibsonomy.org/author/Abrahamsson">Abrahamsson</a> und J. <a href="http://www.bibsonomy.org/author/Still">Still</a> </span><em>Empirical Software Engineering</em>(<em>2008</em>)Sun May 25 01:01:16 CEST 2008Empirical Software EngineeringThe impact of agile practices on communication in software development2008software should-read agile empirical Agile software development practices such as eXtreme Programming (XP) and SCRUM have increasingly been adopted to respond to the challenges of volatile business environments, where the markets and technologies evolve rapidly and present the unexpected.In spite of the encouraging results so far, little is known about how agile practices affect communication. This article presents the results from a study which examined the impact of XP and SCRUM practices on communication within software development teams and within the focal organization. The research was carried out as a case study in F-Secure where two agile software development projects were compared from the communication perspective. The goal of the study is to increase the understanding of communication in the context of agile software development: internally among the developers and project leaders and in the interface between the development team and stakeholders (i.e. customers, testers, other development teams). The study shows that agile practices improve both informal and formal communication. However, it further indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication. The study highlights the fact that hurdles and improvements in the communication process can both affect the feature requirements and task subtask dependencies as described in coordination theory. While the use of SCRUM and some XP practices facilitate team and organizational communication of the dependencies between product features and working tasks,the use of agile practices requires that the team and organization use also additional plan-driven practices to ensure the efficiency of external communication between all the actors of software development.http://www.bibsonomy.org/bibtex/23b8ed0b0f57e2af912a9bb84518d0d6c/neilernstneilernst2008-05-22T21:18:39+02:00history goals software personal requirements design <span style="color:#555555;">Neil A. <a href="http://www.bibsonomy.org/author/Ernst">Ernst</a> und John <a href="http://www.bibsonomy.org/author/Mylopoulos">Mylopoulos</a> </span><em>International Workshop on Software Evolvability at ICSM, </em><em>Paris, France, </em><em>IEEE Computer Society, </em><em>October2007. </em>Thu May 22 21:18:39 CEST 2008Paris, FranceInternational Workshop on Software Evolvability at ICSMOctoberTracing software evolution history with design goals2007history goals software personal requirements design When designing software for evolvability, it is important to understand which particular designs have worked in the past – and which have not. This paper argues that understanding the history of a software innovation is valuable in setting the context for future innovations. There is no formal discipline of software history. While there is an active body of research in information technology (IT) and innovation management, which seeks to understand how to maximize value from IT spending, this research often ignores the meaningful technological underpinnings of such tools. We suggest that the study of design history should be extended to software artifacts. The paper introduces notions like requirements analysis, technology context, and social context to explain how, and why, certain technologies evolved as they did. We apply these concepts to the history of distributed computing protocols. We conclude with observations drawn from this history that suggest designing software for evolvability must consider the history of similar applications in the requirements analysis.http://www.bibsonomy.org/bibtex/2d5881b40414277617e9bf3a909b36252/neilernstneilernst2008-05-15T17:04:31+02:00dynamic software adaptive <span style="color:#555555;">Daniel M. <a href="http://www.bibsonomy.org/author/Berry">Berry</a> und Betty H.C. <a href="http://www.bibsonomy.org/author/Cheng">Cheng</a> und Ji <a href="http://www.bibsonomy.org/author/Zhang">Zhang</a> </span><em>International Workshop on Requirements Engineering: Foundation for Software Quality, </em><em>Porto, Portugal, </em><em>June2005. </em>Thu May 15 17:04:31 CEST 2008Porto, PortugalInternational Workshop on Requirements Engineering: Foundation for Software QualityJuneThe Four Levels of Requirements Engineering for and in Dynamic Adaptive Systems2005dynamic software adaptive http://www.bibsonomy.org/bibtex/20dc83b000a90b34f14dc2800e754d88b/neilernstneilernst2008-04-03T20:40:10+02:00software empirical <span style="color:#555555;">Jo <a href="http://www.bibsonomy.org/author/Hannay">Hannay</a> und Magne <a href="http://www.bibsonomy.org/author/Jørgensen">J&#248;rgensen</a> </span><em>IEEE Transactions on Software Engineering</em><em>34(2):242-259</em><em>March/April2008. </em>Thu Apr 03 20:40:10 CEST 2008IEEE Transactions on Software EngineeringMarch/April2242-259The Role of Deliberate Artificial Design Elements in Software Engineering Experiments342008software empirical Increased realism in software engineering experiments is often promoted as an important means to increase generalizability and industrial relevance. In this context, artificiality, e.g., the use of constructed tasks in place of realistic tasks, is seen as a threat. In this article, we examine the opposite view, that deliberately introduced artificial design elements may increase knowledge gain and enhance both generalizability and relevance. In the first part of the article, we identify and evaluate arguments and examples in favor of, and against, deliberately introducing artificiality into software engineering experiments. In the second part of the article, we summarize a content analysis of articles reporting software engineering experiments published over the ten-year period 1993-2002. The analysis reveals a striving for realism and external validity, but little awareness of for what and when, various degrees of artificiality and realism are appropriate. We conclude that an increased awareness and deliberation in these respects is essential. However, arguments in favor of artificial design elements should not be used to justify studies that are badly designed or that have research questions of low relevance.http://www.bibsonomy.org/bibtex/2a029b7aa2273424b4606723f672d4da6/neilernstneilernst2008-02-16T23:35:51+01:00methods software research empirical <span style="color:#555555;">Steve <a href="http://www.bibsonomy.org/author/Easterbrook">Easterbrook</a> und Janice <a href="http://www.bibsonomy.org/author/Singer">Singer</a> und Margaret-Anne <a href="http://www.bibsonomy.org/author/Storey">Storey</a> und Daniela <a href="http://www.bibsonomy.org/author/Damian">Damian</a> </span><em>Springer, </em>(<em>2007</em>)Sat Feb 16 23:35:51 CET 2008Guide to Advanced Empirical Software EngineeringSelecting Empirical Methods for Software Engineering Research2007methods software research empirical Selecting a research method for empirical software engineering research is problematic because the benefits and challenges to using each method are not yet well catalogued. Therefore, this chapter describes a number of empirical methods available. It examines the goals of each and analyzes the types of questions each best addresses. Theoretical stances behind the methods, practical considerations in the application of the methods and data collection are also briefly reviewed. Taken together, this information provides a suitable basis for both understanding and selecting from the variety of methods applicable to empirical software engineering.http://www.bibsonomy.org/bibtex/20194bcfa92f21ac8ea1a6eae482d5cb2/neilernstneilernst2008-01-29T16:00:26+01:00Software model evolution <span style="color:#555555;">Harry <a href="http://www.bibsonomy.org/author/Sneed">Sneed</a> </span><em>Workshop on Model-Driven Software Evolution at CSMR, </em><em>Amsterdam, </em><em>March2007. </em>Tue Jan 29 16:00:26 CET 2008AmsterdamWorkshop on Model-Driven Software Evolution at CSMRMarchThe Drawbacks of Model-Driven Software Evolution2007Software model evolution This short paper is an essay on the drawbacks of model driven software evolution which apply equally well to model driven software development. The idea of automatically generating code changes from a UML type model is equally enticing as that of automatically generating whole components from such a model. The drawback is that there is then nothing to test against, since there is only one description of the system, the model. This violates the principles of software verification and validation, according to which correctness can only be demonstrated by comparing two independent descriptions of the same solution. For this reason, the author proposes another interpretation of model driven evolution, one in which the requirements model serves as a basis for propagating changes to both the code and the test, along two independent paths. The UML type system design could then be generated from the code and not [vice] versahttp://www.bibsonomy.org/bibtex/22796b941aecba62f3f86013eb3d37b23/neilernstneilernst2008-01-25T18:13:50+01:00software Structured RE validation change Goal-driven Viewpoints Requirements engineering questionnaires Empirical <span style="color:#555555;">Johan F. <a href="http://www.bibsonomy.org/author/Hoorn">Hoorn</a> und Elly A. <a href="http://www.bibsonomy.org/author/Konijn">Konijn</a> und Hans van <a href="http://www.bibsonomy.org/author/Vliet">Vliet</a> und Gerrit van der <a href="http://www.bibsonomy.org/author/Veer">Veer</a> </span><em>Journal of Systems and Software</em><em>80(3):328--355</em><em>#mar#2007. </em>Fri Jan 25 18:13:50 CET 2008Selected papers from the 1st International Workshop on Requirements Engineering for Business Need and IT Alignment (REBNITA'05), 1st International Workshop on Requirements Engineering for Business Need and IT AlignmentJournal of Systems and Software#mar#3328--355Requirements change: Fears dictate the must haves; desires the won't haves802007software Structured RE validation change Goal-driven Viewpoints Requirements engineering questionnaires Empirical We attempt to contribute to a general theory of requirements change from a goal-oriented and viewpoints-driven angle. To practitioners, this knowledge is relevant to anticipate changes in certain types of requirements, which may shorten the project's timeline, reduce costs, and increase product quality. Initially, we followed the common assumptions that what should be on a system is demanded by goals to achieve and what should not be on a system is demanded by goal states to avoid. However, requirements engineering of a diversity of systems (capacity and warehouse management, COTS PCs, and a Braille mouse) revealed that must requirements are predicted by goals to avoid (!) and won't requirements by goals to approach (!). Expectations about the positive or negative impact (valence) of requirements on goals played a moderating role. We unfold the gradual discovery of this "goals-to-requirements chiasm" (CHI-effect or [chi]-effect), claiming that variability in agreement to positive or negative requirements is predicted by goals of opposite polarity. We found that whether the [chi]-effect occurred or not, depended on the alignment of stakeholder viewpoints on goals and requirements. Comments from practitioners are included.http://www.bibsonomy.org/bibtex/2016a71c6014bd36e5d0c1e648350600f/neilernstneilernst2008-01-17T23:00:04+01:00User Software Business requirements architecture/design rules evolution <span style="color:#555555;">W. M. N. <a href="http://www.bibsonomy.org/author/Wan-Kadir">Wan-Kadir</a> und Pericles <a href="http://www.bibsonomy.org/author/Loucopoulos">Loucopoulos</a> </span><em>Journal of Systems Architecture</em><em>50(7):367--382</em><em>#jul#2004. </em><em>Adaptable System/Software Architectures . </em>Thu Jan 17 23:00:04 CET 2008Journal of Systems Architecture#jul#Adaptable System/Software Architectures7367--382Relating evolving business rules to software design502004User Software Business requirements architecture/design rules evolution In order to remain useful, it is important for software to evolve according to the changes in its business environment. Business rules, which can be used to represent both user requirements and conditions to which the system should conform, are considered as the most volatile part in today's software applications. Their changes bring high impact on both the business processes and the software itself. In this paper, we present an approach that considers business rules as an integral part of a software system and its evolution. The approach transcends the areas of requirements specification and software design. We develop the Business Rule Model to capture and specify business rules, and the Link Model to relate business rules to the metamodel level of software design elements. The aim is to improve requirements traceability in software design, as well as minimizing the efforts of software changes due to the changes of business rules. The approach is demonstrated using examples from an industrial application.Originally published in 1970. Describes waterfall model with iteration.http://www.bibsonomy.org/bibtex/212d7128ee85d39516a39e10a11b83a2f/neilernstneilernst2008-01-14T18:23:55+01:00software waterfall methodology <span style="color:#555555;">W. W. <a href="http://www.bibsonomy.org/author/Royce">Royce</a> </span><em>International Conference on Software Engineering, </em><em>Seite328--338. </em><em>Monterey, CA, USA, </em><em>IEEE Computer Society Press, </em>(<em>1987</em>)Mon Jan 14 18:23:55 CET 2008Monterey, CA, USAInternational Conference on Software Engineering328--338Managing the development of large software systems: concepts and techniques1987software waterfall methodology http://www.bibsonomy.org/bibtex/2360b0bf445fa15e647edf610608ade72/neilernstneilernst2008-01-09T23:48:48+01:00software seminal engineering <span style="color:#555555;">Frederick P. <a href="http://www.bibsonomy.org/author/Brooks">Brooks</a> </span><em>IEEE Computer</em><em>20(4):10--19</em><em>April1987. </em>Wed Jan 09 23:48:48 CET 2008IEEE ComputerApril410--19No {S}ilver {B}ullet: {E}ssence and {A}ccidents of {S}oftware {E}ngineering201987software seminal engineering http://www.bibsonomy.org/bibtex/2246d2273b6182382a4e2399b7cff5b45/neilernstneilernst2008-01-07T21:37:08+01:00software SCR seminal requirements <span style="color:#555555;">L.J. <a href="http://www.bibsonomy.org/author/Chmura">Chmura</a> und A.F. <a href="http://www.bibsonomy.org/author/Norcio">Norcio</a> und T.J. <a href="http://www.bibsonomy.org/author/Wicinski">Wicinski</a> </span><em>Transactions on Software Engineering</em>(<em>1990</em>)Mon Jan 07 21:37:08 CET 2008Transactions on Software Engineering729-740Evaluating software design processes by analyzing change data overtime161990software SCR seminal requirements An analysis is presented of early design and code change data from the software cost reduction (SCR) project, a well-reported effort conducted at the US Naval Research Laboratory from 1978 to 1988. The analyses are mostly time-based studies of the change data and relationships between the data and SCR personnel activity data. Some analyses of the change data show patterns consistent with a major goal of the SCR project: the design and development of easy-to-change software. Specifically, most changes took a day or less to uncover and resolve; the majority of changes updated at most one module. Moreover, these percentages remained fairly stable. No positive relationship appeared between error-correction effort and the number of days that an error remained in the SCR design documentation. Other analyses suggest that consistency may have been temporary. For example, the analyses suggest a stepwise growth in average change effort, and an increasing percentage of changes resulted in module interface updates. Certain specific ratios between SCR change data and personnel activity data may be possible indicators of design incompletenesszoterohttp://www.bibsonomy.org/bibtex/206fbdd14fe2ab1436ee10edc17fd595d/neilernstneilernst2008-01-07T21:10:05+01:00process software <span style="color:#555555;">Frank <a href="http://www.bibsonomy.org/author/McGarry">McGarry</a> und Rose <a href="http://www.bibsonomy.org/author/Pajerski">Pajerski</a> und Gerald <a href="http://www.bibsonomy.org/author/Page">Page</a> und Sharon <a href="http://www.bibsonomy.org/author/Waligora">Waligora</a> und Victor <a href="http://www.bibsonomy.org/author/Basili">Basili</a> und Martin <a href="http://www.bibsonomy.org/author/Zelkowitz">Zelkowitz</a> </span><em>CMU/SEI-94-TR-22. </em><em>Software Engineering Institute, </em><em>Pittsburgh, PA, USA, </em><em>December1994. </em>Mon Jan 07 21:10:05 CET 2008Pittsburgh, PA, USADecemberCMU/SEI-94-TR-22Software Process Improvement in the NASA Software Engineering Laboratory1994process software The Software Engineering Laboratory (SEL) was established in 1976 for the purpose of studying and measuring software processes with the intent of identifying improvements that could be applied to the production of ground support software within the Flight Dynamics Division (FDD) at the National Aeronautics and Space Administration (NASA)/Goddard Space Flight Center (GSFC). The SEL has three member organizations: NASA/GSFC, the University of Maryland, and Computer Sciences Corporation (CSC). The concept of process improvement within the SEL focuses on the continual understanding of both process and product as well as goal-driven experimentation and analysis of process change within a production environment.dblphttp://www.bibsonomy.org/bibtex/22dc15c7416ad9dcde10ea1e949787c90/neilernstneilernst2008-01-07T21:05:28+01:00software could-read complexity empirical <span style="color:#555555;">Victor R. <a href="http://www.bibsonomy.org/author/Basili">Basili</a> und Barry T. <a href="http://www.bibsonomy.org/author/Perricone">Perricone</a> </span><em>Commun. ACM</em><em>27(1):42-52</em>(<em>1984</em>)Mon Jan 07 21:05:28 CET 2008Commun. ACM142-52Software Errors and Complexity: An Empirical Investigation.271984software could-read complexity empirical