Showing papers in "IEEE Software in 2000"
TL;DR: It is demonstrated that using pair programming in the software development process yields better products in less time-and happier, more confident programmers.
Abstract: The software industry has practiced pair programming (two programmers working side by side at one computer on the same problem) with great success for years, but people who haven't tried it often reject the idea as a waste of resources. The authors demonstrate that using pair programming in the software development process yields better products in less time-and happier, more confident programmers.
803 citations
TL;DR: The experience in implementing the Scrum software development process to address concerns of change in the product development life-cycle is discussed.
Abstract: In today's software development environment, requirements often change during the product development life-cycle to meet shifting business demands, creating endless headaches for development teams. We discuss our experience in implementing the Scrum software development process to address these concerns.
602 citations
Journal Article•
TL;DR: It is demonstrated that MMRE and pred(25) are, respectively, measures of the spread and the kurtosis of the variable z, where z=estimate/actual.
387 citations
TL;DR: In this article, the author sheds some light on why testing today's software products is so challenging, and identifies several solid approaches that all testers should be able to apply thoughtfully.
Abstract: The author sheds some light on why testing today's software products is so challenging, and he identifies several solid approaches that all testers should be able to thoughtfully apply. The effective tester has a rich toolkit of fundamental testing techniques, understands how the product will be used in its operating environment, and has a nose for where subtle bugs might lurk in the product and a bag of tricks for flushing them out. The methods described can help testers provide a sensible answer to the question of what they really mean when they say they have finished testing a software system.
346 citations
TL;DR: The role of IDSs in an organization's overall defensive posture is considered and guidelines for IDS deployment, operation, and maintenance are provided.
Abstract: Intrusion detection systems are an important component of defensive measures protecting computer systems and networks from abuse. This article considers the role of IDSs in an organization's overall defensive posture and provides guidelines for IDS deployment, operation, and maintenance.
264 citations
TL;DR: A framework for methodology differentiation, principles for methodology selection, and project experiences using these ideas are described.
Abstract: How do we determine the need for various software processes or methodologies, and what helps us choose the appropriate one for our project? To answer these questions, we need to get to the bottom of the controversy over methodologies and discover the dimensions along which they vary. This article describes a framework for methodology differentiation, principles for methodology selection, and project experiences using these ideas.
243 citations
TL;DR: In this article, the authors define a reference model for applying formal methods to the development of user requirements and their reduction to a behavioral system specification, focusing on the shared phenomena that define the interface between the system and the environment.
Abstract: The authors define a reference model for applying formal methods to the development of user requirements and their reduction to a behavioral system specification. The approach focuses on the shared phenomena that define the interface between the system and the environment.
238 citations
TL;DR: The accelerating trends of interconnectedness, complexity, and extensibility are aggravating the already-serious threat posed by malicious code.
Abstract: The accelerating trends of interconnectedness, complexity, and extensibility are aggravating the already-serious threat posed by malicious code. To combat malicious code, these authors argue for creating sound policy about software behavior and enforcing that policy through technological means.
233 citations
TL;DR: Developers can use this new sizing metric called Web Objects and an adaptation of the Cocomo II model called WebMo to more accurately estimate Web based software development effort and duration.
Abstract: Developers can use this new sizing metric called Web Objects and an adaptation of the Cocomo II model called WebMo to more accurately estimate Web based software development effort and duration Based on work with over 40 projects, these estimation tools are especially useful for quick-to-market development efforts
213 citations
TL;DR: An overview of a start-up's relationship with the software process is given and guidelines on how to apply this process to astart-up company are given.
Abstract: In the start-up environment, software process technologies and methodologies that focus on advanced levels of process maturity can be out of place. This article gives an overview of a start-up's relationship with the software process and gives guidelines on how to apply this process to a start-up company.
168 citations
TL;DR: The author explores improvisation and its role in smaller companies and finds that for most small software organizations the environment is constantly changing and often unpredictable.
Abstract: Traditional ways of developing software and improving the software process rely on theories that assume that the environment is predictable. However, for most small software organizations the environment is constantly changing and often unpredictable. The author explores improvisation and its role in smaller companies.
TL;DR: A process framework for working with COTS-based systems is developed at Carnegie Mellon University's Software Engineering Institute (SEI), which aims to provide clarity on how these products affect existing software development processes.
Abstract: Although commercial off-the-shelf (COTS) products are becoming increasingly popular, little information is available on how they affect existing software development processes or what new processes are needed. At Carnegie Mellon University's Software Engineering Institute (SEI), we are developing a process framework for working with COTS-based systems.
TL;DR: Differences in the factors, explaining productivity in the banking, insurance, manufacturing, wholesale/retail, and public administration sectors are examined, involving a unique database containing 206 business software projects from 26 Finnish companies.
Abstract: The article examines a statistical analysis of a productivity variation, involving a unique database containing 206 business software projects from 26 Finnish companies. The authors examine differences in the factors, explaining productivity in the banking, insurance, manufacturing, wholesale/retail, and public administration sectors. The authors provide productivity benchmarking equations that are useful both for estimating expected productivity at the start of a new project and for benchmarking a completed project for each business sector.
TL;DR: How does a large, multifaceted company change its culture from one where quality and customer satifaction were an afterthought to one where these elements became the driving force behind its main software development business, achieving both ISO 9001 registration and a CMM Level 5 rating in the process?
Abstract: How does a large, multifaceted company change its culture from one where quality and customer satifaction were an afterthought to one where these elements became the driving force behind its main software development business, achieving both ISO 9001 registration and a CMM Level 5 rating in the process? Telcordia Technologies (software development groups) instituted these institution-wide changes over five years.
TL;DR: The article sheds light on the realities of language conversions and discusses the possibilities and limitations of automated language converters.
Abstract: Billions of lines written in Cobol, PL/I, and other mature high level languages are still in active use. Many developers have tried to convert these languages to more modern ones, but few have succeeded. The article sheds light on the realities of language conversions and discusses the possibilities and limitations of automated language converters.
TL;DR: A mechanism is proposed that clarifies communication about components, improves understanding of how components are used in particular systems, and sheds light on evaluation strategies, and separates attributes along different axes of interest.
Abstract: The use of the "COTS" acronym can be a convenience, but it can also lead to confusion. The authors propose a mechanism that clarifies communication about components, improves understanding of how components are used in particular systems, and sheds light on evaluation strategies. The method separates attributes along different axes of interest, locating each component in a graphical space with different axes of interest and multiple points of interest. Given the need for better understanding of component-based systems and their growing importance, the value of such a mechanism could outweigh the increased effort of using it.
TL;DR: The authors use data and analysis from a collaborative effort between the Software Engineering Institute and the Space Shuttle Onboard Software Project as a vehicle to illustrate the analytic processes analysts frequently encounter when using statistical process control methods.
Abstract: Demand for increased software process efficiency and effectiveness places measurement demands on the software engineering community beyond those traditionally practiced. Statistical- and process-thinking principles lead to the use of statistical process control (SPC) methods to determine the consistency and capability of the processes used to develop software. The authors use data and analysis from a collaborative effort between the Software Engineering Institute (a federally funded research and development center sponsored by the US Department of Defense) and the Space Shuttle Onboard Software Project as a vehicle to illustrate the analytic processes analysts frequently encounter when using SPC.
TL;DR: In this paper, the authors found that when it comes to requirements negotiations, groups meeting face-to-face perform no better than those using video conferencing and computer support.
Abstract: Contrary to traditional wisdom, the authors found that, when it comes to requirements negotiations, groups meeting face-to-face perform no better than those using video conferencing and computer support. Furthermore, their study identified a particular distributed group configuration that significantly improved performance and was more conducive to negotiations than face-to-face meetings.
TL;DR: In a partially publicly funded project, the authors have started to apply their Product Line Software Engineering method developed at Fraunhofer IESE in six small and medium-sized companies addressing six different domains.
Abstract: Small and medium-sized enterprises work under heavy constraints: They need to be very flexible and fast in their reaction to customer requests, thus limiting their possibility for long-term planning. In a partially publicly funded project, the authors have started to apply their Product Line Software Engineering method developed at Fraunhofer IESE, in six small and medium-sized companies addressing six different domains. The article presents first experience and lessons learned from 24 months of project work; including first results within the companies.
TL;DR: Using a 161-project sample, it is concluded that an increase of one process maturity level can reduce development effort by 4% to 11%.
Abstract: When organizations make many improvements concurrently, software project managers have no way of determining how much improvement is due to process maturity versus other factors. Using a 161-project sample, the article isolates the effects on effort of process maturity versus other effects, concluding that an increase of one process maturity level can reduce development effort by 4% to 11%.
TL;DR: The authors underscore the importance of community in how new technical ideas become accepted, how despite software engineers too often prefer polemic to evidence, and the primacy given to the local guru that transcends formal organizational structures.
Abstract: Ideas and techniques from the social sciences can improve the theory and practice of the software engineering discipline. To illustrate the contributions this cross-pollination has made, the authors focus on the nature of paradigms and software quality management systems. Their studies underscore the importance of community in how new technical ideas become accepted, how despite software engineers too often prefer polemic to evidence, and the primacy given to the local guru that transcends formal organizational structures.
TL;DR: The authors used SPC on inspection and test data to assess product quality during testing and to predict post-shipment product quality for a major software release.
Abstract: Applying quantitative methods such as statistical process control (SPC) to software development projects can provide a positive cost-benefit return. The authors used SPC on inspection and test data to assess product quality during testing and to predict post-shipment product quality for a major software release.
TL;DR: This special issue looks at some aspects of this diversity in software development, and how processes differ greatly throughout the industry.
Abstract: First of all, what is a process? Asking this might seem trivial, but by reading the many excellent submissions for this issue, we realized this question has a far from trivial answer. According to the Merriam-Webster's Collegiate Dictionary, you can define a process as \" a series of actions or operations conducing to an end. \" This definition seems to fit peoples' general ideas about process, but clearly, numerous differing definitions of process exist. Is process the way a company operates—from marketing to human resources, to actual development—or the way a developer produces design or code, or tests the software? Does the process refer to management, engineering, or both? Does process imply a lot of formalism and expanding effort for writing and reading documents , instead of product development? Some people would answer yes to these questions, others no. Maybe the correct an-A \" one size fits all \" approach doesn't work in software development. Processes work or are appropriate only under certain conditions. Does NASA follow the same software development process as a startup e-commerce company? The answer is obvious. Processes differ greatly throughout the industry, and this special issue looks at some aspects of this diversity.
TL;DR: Why and how the authors make technology selection decisions is examined and how evidence supporting these decisions helps or hinders the adoption of new technology is considered.
Abstract: We can learn much from the business community about effective technology transfer. In particular, understanding the interests of different types of adopters can suggest to us the different kinds of evidence needed to convince someone to try an innovative technology. At the same time, the legal community offers us advice about what kinds of evidence are needed to build convincing cases that an innovation is an improvement over current practice. The article examines why and how we make technology selection decisions and also considers how evidence supporting these decisions helps or hinders the adoption of new technology.
TL;DR: In this article, an approach that is based on using linguistic information from information specifications to apply during the object-oriented analysis process is proposed, which helps to analyze this information semantically and syntactically and employs a semi-formal procedure to extract an objectoriented system's components.
Abstract: One of object orientation's main limitations is the object-oriented analysis process's immaturity. This article proposes an approach that is based on using linguistic information from information specifications to apply during this process. Our method helps to analyze this information semantically and syntactically and employs a semi-formal procedure to extract an object-oriented system's components.
TL;DR: The most radical of the three books I reviewed, The Fifth Discipline, can fundamentally change the way you view the world.
Abstract: Built to Last's answer is to consciously build a compmy with even more care than the hotels, airplanes, or computers from which the company earns revenue. Building a company requires much more than hiring smart employees and aggressive salespeople. Visionary companies consider the personality of their potential employees and how they will fare in the company culture. They treasure employees dedicated to the company's mission, while those that don't are \" ejected like a virus. \" They carefully choose goals and develop cultures that encourage innovation and experimentation. Visionary companies plan for the future, measure their current production, and revise plans when conditions change. Much like the TV show Biography, Built to Last gives fascinating historical insight into the birth and growth of The most radical of the three books I reviewed, The Fifth Discipline, can fundamentally change the way you view the world. The Flremise is that businesses, schools, gopernments, and other organizations can best succeed if they are learning organizations. The Fifth Discipline is Peter Senge's vehicle for explaining how five complementary components-systems thinking, personal mastery, mental models, shared vision, and team learning-can support continuous learning and therefore sustainable iniprovement. Senge, a professor a t MIT's Sloan School of Government and a director of the Society for Organizational Learning, looks beyont: simple cause-and-effect explanation:j and instead advocates \" systems thinking \" to discover a more complete understanding of how and why events occur. Systems thinkers go beyond the data readily available, question assumptions, and try to identify the many types of activities that can occur simultaneously. The need for such a worldview is made clear early in the book with the role-playing \" beer game. \" In this game, three participants play the roles of store manager, beverage distributor, and beer brewer. Each has information that would typically he available: the store manager knows how many cases of beer are in inventory , how many are on order, and how many were sold in the last week. The distributor tracks the orders placed with the brewery, inventory, orders received this week from each store, and so on. As the customers' demands vary, the manager, distributor, and brewer make what seem to be reasonable decisions to change the amount they order or brew. Thousands of people have played this and, unfortunately, the results are extremely consistent. As each player tries to maximize profits, each fails to consider how his …
TL;DR: This article provides a safe and simple method for doing both the identify which cost driver factors were likely to cause critical cost differences and estimate how much cost difference would result if a critical cost driver changed by a given degree by using some cost-estimating relationships.
Abstract: Simple software cost-analysis methods are readily available, but they aren't always safe. The simplest method is to base your cost estimate on the typical costs or productivity rates of your previous projects. That approach will work well if your new project doesn't have any cost-critical differences from those previous projects, but it won't be safe if some critical cost driver has degraded. Simple history-based software cost-analysis methods would be safer if you could identify which cost driver factors were likely to cause critical cost differences and estimate how much cost difference would result if a critical cost driver changed by a given degree. In this article, I provide a safe and simple method for doing both of these by using some cost-estimating relationships. COCOMO II is an updated and re-calibrated version of COCOMO (COnstructive COst MOdel). I also show how the COCOMO II cost drivers let you perform cost sensitivity and tradeoff analyses, and discuss how you can use similar methods with other software cost-estimation models
TL;DR: Wisdom is a new software engineering method addressing the specific needs of small teams that develop and maintain interactive systems and can smoothly be applied in small companies leveraging on their communication, speed, and flexibility.
Abstract: Wisdom is a new software engineering method addressing the specific needs of small teams that develop and maintain interactive systems. Because Wisdom defines a process, notation, and project philosophy, it can smoothly be applied in small companies leveraging on their communication, speed, and flexibility.
Journal Article•
TL;DR: AspectJ as mentioned in this paper is the first AOP language, and demonstrates how to use it to construct more reliable software by modularizing error-handling policies and allowing for easier maintenance and better reuse.
Abstract: Aspect-oriented programming (AOP) is a novel topic in the software engineering and languages communities. AOP appears to have the potential to significantly improve the reliability of programs, particularly by modularizing error-handling policies and allowing for easier maintenance and better reuse. In this article, we introduce AspectJ, the first AOP language, and demonstrate how you can use it to construct more reliable software.
TL;DR: Using the personal software process (PSP) as an example of an innovative information technology, a field study of developers using the PSP approach on software development projects in industry offers practical guidance on how software development organizations should support the diffusion of innovations into successful practice.
Abstract: Using the personal software process (PSP) as an example of an innovative information technology, the authors performed a field study of developers using the PSP approach on software development projects in industry. Their analysis of the results offers practical guidance on how software development organizations should support the diffusion of innovations into successful practice.