Showing papers in "IEEE Software in 1997"

A cost-value approach for prioritizing requirements

Abstract: Developing software systems that meet stakeholders' needs and expectations is the ultimate goal of any software provider seeking a competitive edge. To achieve this, you must effectively and accurately manage your stakeholders' system requirements: the features, functions, and attributes they need in their software system. Once you agree on these requirements, you can use them as a focal point for the development process and produce a software system that meets the expectations of both customers and users. However, in real world software development, there are usually more requirements than you can implement given stakeholders' time and resource constraints. Thus, project managers face a dilemma: how do you select a subset of the customers' requirements and still produce a system that meets their needs? The authors developed a cost-value approach for prioritizing requirements and applied it to two commercial projects.

Document ranking and the vector-space model

Abstract: Efficient and effective text retrieval techniques are critical in managing the increasing amount of textual information available in electronic form. Yet text retrieval is a daunting task because it is difficult to extract the semantics of natural language texts. Many problems must be resolved before natural language processing techniques can be effectively applied to a large collection of texts. Most existing text retrieval techniques rely on indexing keywords. Unfortunately, keywords or index terms alone cannot adequately capture the document contents, resulting in poor retrieval performance. Yet keyword indexing is widely used in commercial systems because it is still the most viable way by far to process large amounts of text. Using several simplifications of the vector-space model for text retrieval queries, the authors seek the optimal balance between processing efficiency and retrieval effectiveness as expressed in relevant document rankings.

How user perceptions influence software use

Abstract: Traditionally, human-computer interaction researchers have focused on a system's usability. The authors applied an MIS-proven technology acceptance model that accounts for system usefulness as well. They discovered that this factor has a strong bearing on user acceptance.

How software process improvement helped Motorola

Abstract: Many organizations are using or considering the Capability Maturity Model as a vehicle for software process improvement But does the CMM provide real benefits? The authors offer metrics and data that show the results of Motorola's CMM usage

A model-based interface development environment

Abstract: The author describes Mobi-D (Model-Based Interface Designer), a comprehensive environment that supports user-centered design through model-based interface development. In the Mobi-D paradigm, a series of declarative models, such as user-task, dialog, and presentation, are interrelated to provide a formal representation of an interface design. This contrasts to model-based systems, which use only one or two models in isolation and have no explicit notion as to how the various model elements are organized into an interface design.

Intrusion detection via system call traces

Abstract: Unusual behavior in computer systems can be detected by monitoring the system calls being executed by programs. Analysis of the temporal ordering of these calls reveals that such anomalies are localized within traces and that normal program behavior can be described compactly using deterministic finite automata. This article presents preliminary work in analyzing system call traces, particularly their structure during normal and anomalous behavior.

Architectural styles, design patterns, and objects

Abstract: Architectural styles, object-oriented design and design patterns all hold promise as approaches that simplify software design and reuse by capturing and exploiting system design knowledge. This article explores the capabilities and roles of the various approaches, their strengths and their limitations.

Reexamining the fault density component size connection

Abstract: In software engineering, the lack of experimental evidence often means that anecdotal, intuitive, or sometimes just plain commercial arguments become surprisingly well-entrenched. Conventional wisdom, that smaller components contain relatively fewer faults may be wrong. The author found that medium-sized components were proportionately more reliable than small or large ones. Moreover, he says, there may be limits on the fault density we can achieve.

The use and misuse of focus groups

Abstract: Focus groups are a somewhat informal technique that can help you assess user needs and feeling both before interface design and long after implementation. In a focus group, you bring together six to nine users to discuss issues and concerns about the features of a user interface. The group typically lasts about two hours and is run by a moderator who maintains the group's focus. Focus groups often bring out users' spontaneous reactions and ideas and let you observe some group dynamics and organizational issues. The paper discusses the use and misuse of focus groups.

Implementing effective software metrics programs

Abstract: Increasingly organisations are foregoing an ad hoc approach to metrics in favor of complete metrics programs. The authors identify consensus requirements for metric program success and examine how programs in two organisations measured up.

Estimates, uncertainty, and risk

Abstract: The authors discuss the sources of uncertainty and risk, their implications for software organizations, and how risk and uncertainty can be managed. Specifically, they assert that uncertainty and risk cannot be managed effectively at the individual project level. These factors must be considered in an organizational context.

How experienced project managers assess risk

Abstract: Software development projects, given their diverse and abstract nature, offer unique challenges and risks. Although a substantial body of literature has been written to address project risk management, my experience in the field led me to question whether this literature accurately mirrors the concerns of real-world project managers. To confirm my suspicions, I surveyed 14 experienced application systems developers, all located in Ireland. All survey participants manage custom-built, software-intensive application development projects that originate from external clients. The survey focused on three major areas: (1) Which characteristics of the customer, the application, and so on, do experienced software project managers consider important when planning new development projects for new, external clients? (2) How do these characteristics relate to accepted software project risk drivers? (3) Do most project managers characterize new projects in generally the same way, or do different project managers use different perceptual lenses when viewing new projects? This survey of a homogenous group of project managers revealed a surprising diversity of risk management concerns.

Formal methods: promises and problems

Abstract: Successfully applying formal methods to software development promises to move us closer to a true engineering discipline. The authors offer suggestions for overcoming the problems that have hindered the use of formal methods thus far.

Establishing software measurement programs

Abstract: In seeking to improve software, companies are finding out how much is involved in measuring it. They are also learning that the more integral software measurement is to the company's underlying business strategy, the more likely it is to succeed. We propose a framework or metamodel called the Model, Measure, Manage Paradigm (M/sup 3/P), which is our extension of the well known Quality Improvement Paradigm/Goal-Question-Metric paradigm (R.B. Grady, 1992; V.R. Basili and H.D. Rombach, 1988). M/sup 3/P helps counter a contributing factor commonly seen in failed measurement programs, namely the lack of well defined links between the numerical data and the surrounding development and business contexts, by coupling technical, business, and organizational issues into a given measurement program context. An example where links are important is in highly technical measurement and analysis reports which do not generally answer the concerns of senior executives. We present some early experience with our framework gathered from several case studies, discuss the 8 stages of M/sup 3/P implementation and describe a tool set we developed for use with M/sup 3/P.

Predicting how badly "good" software can behave

Abstract: Using fault injection and failure-tolerance measurement with ultrarare inputs, the authors create on automated software environment that can supplement traditional testing methods. Applied to four case studies, their methods promise to make software more robust.

Collaborations: closing the industry-academia gap

Abstract: When it comes to software engineering education, there is a gap between what industry needs and what universities offer. To close this gap, the authors propose a comprehensive collaboration between academic software engineering programs and industry. They offer a model for this collaboration and highlight three real-world ventures.

Status report on software measurement

Abstract: The most successful software measurement programs are ones in which researcher, practitioner, and customer work hand in hand to meet goals and solve problems. But such collaboration is rare. The authors explore the gaps between these groups and point toward ways to bridge them.

Ariane 5: Who Dunnit?

Abstract: At a 1993 software symposium in inland China, a keynote speaker from the US joked that he had arrived safely because the transportation systems in China “were not yet heavily controlled by software.” When disastrous accidents occur, computers are often singled out for blame— sometimes, rightly so. What have we learned from our many expensive lessons? Not much. One lesson is the need for risk management, but as Nuseibeh points out, it is not practiced even in mission critical projects like Ariane 5. —Tomoo Matsubara

A software platform for testing intrusion detection systems

Abstract: Intrusion detection systems monitor system activities to identify unauthorized use, misuse, or abuse. IDSs offer a defense when your system's vulnerabilities are exploited and do so without requiring you to replace expensive equipment. The steady growth in research on intrusion detection systems has created a demand for tools and methods to test their effectiveness. The authors have developed a software platform that both simulates intrusions and supports their systematic methodology for IDS testing.

Putting risk management into practice

Abstract: The authors use an SEI designed road map as a guide to discussing effective and ineffective risk management methods based on six years' experience with software intensive DoD programs. These programs followed the SEI approach of continuous and team risk management, selecting processes and methods that would best fit their work cultures.

Implementing risk management on software intensive projects

Abstract: Rising costs, falling performance, and slipping schedules are common problems on large scale software projects. The authors describe key risk issues and how they were mitigated in one DoD (military) project.

Heuristic risk assessment using cost factors

Abstract: The author describes an expert system tool that can be used to analyze patterns of software cost driver ratings submitted for a Cocomo cost estimate. These results help users determine and rank associated sources of software project risk.

The Problem with Function Points

Abstract: he concept of function points goes a long way toward addressing the genuine need for frontend measures of product size. My concern is that specific types of function points—such as Albrecht’s version,1 which is popular in the US, and Symons Mark II version,2 which is popular in the UK—are not the straightforward, simple measures some people imagine. Function points have fundamental flaws in their construction that prevent them from being valid measures.3 This means there is a danger they will behave in unexpected ways, for example asserting that one program is larger than another when it is not. In most cases, if function points are used with caution within a specific organization, you will probably have few problems. But if you want to use them for cross-company benchmarking, as the basis for development or support contracts between different companies, or to develop generic estimation models, there is a non-negligible risk that you will encounter problems.

Idioms and patterns as architectural literature

Abstract: If patterns are not about objects, and if they reach beyond software architecture, then what is a pattern? The author explores the relationships that might exist between objects, patterns and architecture, then examines their implications for software developers.

N-version design versus one good version

Abstract: Evidence indicates that n-version development techniques are more reliable than producing one "good" version-and cost effective in the long run. The author concludes that diverse, independent channels used in parallel are significantly superior to even the current state of the art, especially in situations where cost of failure is high.

Gauging software readiness with defect tracking

Abstract: In the competitive commercial software market, companies feel compelled to release software the moment it is ready. Their task is treacherous, treading the line between releasing poor quality software early and high quality software late, Finding a sound answer to the question: "is the software good enough to release now?" can be critical to a company's survival. That answer is, sometimes based on gut instinct, but several techniques can put this judgment on firmer footing.

Qualitative and quantitative reliability assessment

Abstract: During the development of a software system, the supplier must efficiently monitor the development activities; comply with the delivery schedule; predict when a specified level of reliability will be reached, or at least check how well the software will satisfy the customer's requirements; and reduce maintenance efforts. On the other hand, the customer needs a reliable product, delivered on time and at the lowest price. Our method helps reach these goals. It is based on the analysis and evaluation of software reliability by processing failure data collected on a software product during its development and operation. Traditionally, system reliability efforts have not focused on software reliability. We believe that failure prediction can be improved if software reliability modeling is integrated into an overall approach. The method we propose is based on the combined use of descriptive analyses, trend analyses, and reliability models to control testing activities, evaluate software reliability, and plan maintenance.

Integrating risk assessment with cost estimation

Abstract: Incorporating hard data into risk estimates can help make them more accurate. The author developed a quantitative method and a corresponding tool that draw on questionnaires and project history to help calculate software project risk contingencies: RiskMethod and RiskTool.

Using patterns to improve our architectural vision

Abstract: Pattern languages can play an important role in furthering the use of architecture and objects in software design, but first we must understand what these terms mean. The authors use the work of Christopher Alexander (1975, 1979, 1981, 1985) to illuminate the problems and shed light on future directions in our use of pattern languages in design.

Recursive design of an application-independent architecture

Abstract: The authors' development method focuses on a systematic process using precise specification of system components to create application-independent architectures with a high degree of automation-achieved through large-scale code generation-and broad applicability, focusing on real-time systems.