Scheduled System Maintenance:
On Monday, April 27th, IEEE Xplore will undergo scheduled maintenance from 1:00 PM - 3:00 PM ET (17:00 - 19:00 UTC). No interruption in service is anticipated.
By Topic

Software, IEEE

Issue 2 • Date March-April 1998

Filter Results

Displaying Results 1 - 25 of 25
  • China's Budding Software Industry

    Publication Year: 1998 , Page(s): 20 - 21
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (182 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Inventing the Future

    Publication Year: 1998 , Page(s): 22 - 23
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (85 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Requirements Engineering

    Publication Year: 1998 , Page(s): 26 - 29
    Cited by:  Papers (6)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (123 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Crafting Nonhuman Champions

    Publication Year: 1998 , Page(s): 120 - 121
    Save to Project icon | Request Permissions | PDF file iconPDF (58 KB)  
    Freely Available from IEEE
  • Standards, Standards, Everywhere

    Publication Year: 1998 , Page(s): 122
    Save to Project icon | Request Permissions | PDF file iconPDF (135 KB)  
    Freely Available from IEEE
  • Products For Practitioners

    Publication Year: 1998 , Page(s): 124 - 125
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (59 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Two Math Tools

    Publication Year: 1998 , Page(s): 125
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (101 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Modular Security Toolkit

    Publication Year: 1998 , Page(s): 126
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (101 KB)  

    First Page of the Article
    View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Frequently begged questions and how to answer them [software]

    Publication Year: 1998 , Page(s): 93 - 96
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (104 KB)  

    Typical empirical questions about software and the software business include “How productive are programming teams?”, “What are the industry norms?”, “What are the best practices?”, and “How should I measure the productivity of a programming team?” These, and others like them, are frequently asked questions. I always answer these questions with a question. “What are you trying to decide?” People almost always ask empirical questions because they need to make decisions. These decisions are important, involving risk to human life and health, affecting economic and societal well-being, and determining the equitable and productive use of scarce resources. The questioners seem to feel-because the questions are so frequently asked and the answers so often provided-that the answers must be widely known, but in looking at the answers, I observe the same pattern repeatedly. Answers that seemed well-known and widely supported turn out to be only widely proliferated. They are based on one or two sources, which often prove thin and unreliable. They are “transparency facts”, copied from presentation to presentation. When confronted with such questions, the questioners have no time to research the answers, so they grab whatever answers are at hand. Thus, many frequently asked questions about software are more truly frequently begged questions View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Real-life object-oriented systems

    Publication Year: 1998 , Page(s): 76 - 83
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (156 KB)  

    The benefits of object-oriented development are difficult to obtain. The author studied seven OO development teams and found that they used one of three basic architectures. He explores the advantages and disadvantages of each architecture with regard to connecting databases, applications and screen objects View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Designers must do the modeling

    Publication Year: 1998
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (180 KB)  

    Put simply, those who construct the system, the designers, should own the requirements. To understand why, let's step back and examine what requirements really are. If we think of the requirements process as a black box, there are inputs to the process, things happening inside the black box, and outputs from the process. Inputs to the process include discussions with customers, past products, competitors' solutions, prototypes, and new ideas. Many authors have claimed that the primary output of a requirements process is a requirements specification. Not so. The primary output is our collective understanding of the customer's problem. The specification is only a representation, a model of that understanding. Although important, it is still a secondary product of the requirements process. One can think of requirements as “anything that drives design choices”. Based on that definition, a system's requirements are the collection of the reasons why we choose to design it as we do. Design choices are made not on paper, but inside the minds of designers. The choices are documented on paper. There are many other outputs of the requirements process, such as dataflow diagrams, object models, state models, event models, entity relationship models, natural language statements, and so on. The main benefit of producing all these artifacts is a better and agreed upon understanding of the problem, so that we can design more effective solutions for it View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Problem programmers

    Publication Year: 1998
    Cited by:  Papers (5)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (96 KB)  

    Tolerating even one problem programmer hurts the morale and productivity of good developers. Problem programmers are often viewed as having “low productivity”, but both software research and software experience suggest that such an assessment is too optimistic. Next time you need to improve productivity, don't look for what you can add, look for what you can take away View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Acquiring COTS software selection requirements

    Publication Year: 1998 , Page(s): 46 - 56
    Cited by:  Papers (73)  |  Patents (8)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (196 KB)  

    Commercial off the shelf software can save development time and money if you can find a package that meets your customer's needs. The authors propose a model for matching COTS product features with user requirements. To support requirements acquisition for selecting commercial off the shelf products, we propose a method we used recently for selecting a complex COTS software system that had to comply with over 130 customer requirements. The lessons we learned from that experience refined our design of PORE (procurement oriented requirements engineering), a template based method for requirements acquisition. We report 11 of these lessons, with particular focus on the typical problems that arose and solutions to avoid them in the future. These solutions, we believe, extend state of the art requirements acquisition techniques to the component based software engineering process View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Why Johnny can't test [software]

    Publication Year: 1998 , Page(s): 113 - 115
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (116 KB)  

    The question “Can US programmers be great testers?” is one side of a coin whose other side is, “Can Japanese programmers be creative software designers?” The author compares American and Japanese programmers because they represent the extremes in the range of programmers' behavior with regard to the “value of software”. This is an important observation by a Japanese software engineer from a culture of rigorous practices who works with American software engineers from a markedly different culture. His pessimistic and fatalistic view is just a starting point for debate that could lead to optimistic and constructive propositions View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The Black Death: a parallel of perilous projects

    Publication Year: 1998 , Page(s): 60 - 61
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (72 KB)  

    Three years ago (1995), the author came across P. Ziegler's book, The Black Death (1988). Being an avid history and anthropology enthusiast, he snatched it up for its cultural and historical relevance to the European society of the Middle Ages. Much to the author's surprise, he discovered how well the author's description of this tragic event parallels his own observations over the last 20 years (1978-98) of failing software projects and companies. While the specific characteristics and manifestations exhibited during 1347-1353 AD may differ with those in today's commercial organizations, the basic underlying human responses are much the same. These responses are triggered by extensive exposure to stress and the sudden irrelevance of what had always been accepted as business as usual or “the process”. The author examines some interesting parallels in their historical sequence View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using patterns to create component documentation

    Publication Year: 1998 , Page(s): 84 - 92
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (152 KB)  

    Good documentation facilitates communication between a component's creator and its users, providing insight into design intent, use cases and potential problems. Patterns can provide guidance on documentation content, structure and presentation. Four examples are presented that show you how View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • User involvement: key to success

    Publication Year: 1998
    Cited by:  Papers (5)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (308 KB)  

    The evidence is voluminous, consistent, and incontrovertible. It applies to corporate, government agency, and military software development. Quite simply, the software we build does not meet our customers' needs: those of us who build large software programs fail miserably-90 percent of the time-to deliver what customers want, when they want it, at the agreed upon price; we fail to adequately manage the software development process, user-developer communication breaks down, the requirements control process breaks down, we have runaway requirements, budgets, schedules, and “death march” projects. The Best Practices Framework of the Software Program Manager's Network outlines some solutions. First, we must identify what can go wrong. Precedents give ample hints regarding risks. We need to manage the development process with more attention, particularly to what might go wrong. Second, we must manage the most fundamental part of our task: defining our goal. We fail to use requirements management to surface (early) errors or problems, to baseline and track changes, and to improve user-developer communication View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The software design studio: an exploration

    Publication Year: 1998 , Page(s): 65 - 71
    Cited by:  Papers (11)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (272 KB)  

    Some software designers have recently turned for inspiration to the process of building design to improve development practices and increase software's usefulness and effectiveness. Architects' education revolves around the studio course, which promotes: project based work on complex and open ended problems; very rapid iteration of design solutions; frequent formal and informal critique; consideration of heterogeneous issues; the use of precedent and thinking about the whole; the creative use of constraints; and the central importance of design media. M. Kapor (1991) suggested that software practitioners needed to “rethink the fundamentals of how software is made” and proposed the architect's role in building design as a fruitful analogy for software professionals seeking to reform software practice. This analogy helps us focus on usefulness, usability, user needs and practices, and other technical and nontechnical aspects of good software design. It highlights concerns about people's lives and work practices and how people “inhabit” systems. Several authors have explored similarities and differences between software design and building design, including some who have pursued the software implications of architect Christopher Alexander's design patterns View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Reuse: what's wrong with this picture?

    Publication Year: 1998 , Page(s): 57 - 59
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (80 KB)  

    Something is seriously wrong with reuse. If there is a motherpie-and-applehood topic in software engineering, reuse is it. Everyone believes in it; everyone thinks we should be doing more of it. Reuse does have the potential our industry attributes to it. But the question that keeps recurring is this: why hasn't that potential already been achieved? Most software engineering literature points the finger at management. Don Reifer, for example, has conducted lots of industrial strength studies of businesses that practice reuse (D. Reifer, 1997), and to him the conclusion is clear: the companies that succeed at reuse do so because of managerial commitment, while the ones that fail lack such commitment. Several others say much the same thing. R. Prieto-Diaz turns the problem around and asserts that companies that fail at reuse do so because they treat it as a technical problem. The author disagrees. It seems to him that reuse's fundamental problem is clearly not a lack of managerial commitment. Based on his own experiences, the author thinks reuse hasn't succeeded to the extent we would like because there aren't that many software components that can be reused View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Analyzing and improving reliability: a tree-based approach

    Publication Year: 1998 , Page(s): 97 - 104
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (172 KB)  

    Tree-based reliability models integrate the benefits of software reliability growth models and input domain reliability models, offering a framework to assess reliability and guidance to improve it. The authors studied five large systems to test their approach View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • COTS software: the economical choice?

    Publication Year: 1998 , Page(s): 16 - 19
    Cited by:  Papers (16)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (196 KB)  

    A new trend in software commerce is emerging: generic software components, also called commercial off the shelf components, that contain fixed functionality. COTS components can be incorporated into other systems still under development so that the developing system and the generic components form a single functional entity. The role of COTS components is to help new software systems reach consumers more quickly and cheaply. Because arriving last to market spells sudden death in the software industry, any approach that carves days or weeks from a development schedule is worth considering. The article gives advice on taking the COTS option and the management decisions that have to be made View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • This old house [software development]

    Publication Year: 1998 , Page(s): 72 - 75
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (104 KB)  

    Comparing the improvement of existing software development processes to fixing up an old house, the author argues that working on one item at a time can be more practical than starting from the ground up. The author works at a software company that he imagines resembles many others. The company started out with five employees, including one programmer, and has grown to about 170 employees and $35 million a year in sales. Naturally the organization has experienced growing pains, and it is currently redefining what development means at the company. The article presents the author's view of the company's struggle to improve View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Scenarios in system development: current practice

    Publication Year: 1998 , Page(s): 34 - 45
    Cited by:  Papers (103)  |  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (228 KB)  

    Scenario based approaches are becoming ubiquitous in systems analysis and design but remain vague in definition and scope. A survey of current practices indicates we must offer better means for structuring, managing, and developing their use in diverse contexts. The European Esprit project Crews (Cooperative Requirements Engineering with Scenarios) are seeking a deeper understanding of scenario diversity, necessary to improve methodological and tool support for scenario based requirements engineering. They follow a two pronged strategy to gain this understanding. First, following the “3 dimensions” requirements engineering framework developed in the precursor Nature project (K. Pohl, 1994), they developed a scenario classification framework based on a comprehensive survey of scenario literature in requirements engineering, human computer interaction, and other fields. They used the framework to classify 11 prominent scenario based approaches. Secondly, to complement this research framework, they investigated scenario applications in industrial projects through site visits with scenario user projects. The article focuses on these site visits. It was found that while many companies express interest in Jacobson's use case approach, actual scenario usage often falls outside what is described in textbooks and standard methodologies. Users therefore face significant scenario management problems not yet addressed adequately in theory or practice, and are demanding solutions to these problems View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Opportunities online: fact or fantasy?

    Publication Year: 1998 , Page(s): 62 - 64, 122
    Cited by:  Patents (1)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (184 KB)  

    Countless ads, seminars, and publications describe the Web as a vast, untapped market for software vendors, both as a means to reach customers directly and as a venue for applications that require both an initial purchase and a monthly fee. The challenge thus far has been to provide content that people will pay for. Origin Systems, based in Austin, Texas, (USA) may have found a solution with its massively multiplayer role playing game, Ultima Online. Although UO's initial sales have outstripped any previous Origin title, the game has fallen prey to design, technical, and social problems that provide profound lessons for other online content providers View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Correct program slicing of database operations

    Publication Year: 1998 , Page(s): 105 - 112
    Cited by:  Papers (5)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (148 KB)  

    Program slicing helps isolate program components during debugging and analysis. The authors propose a method to correctly slice programs that involve database operations, which traditional methods often cannot do View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.

Aims & Scope

IEEE Software's mission is to build the community of leading and future software practitioners. The magazine delivers reliable, useful, leading-edge software development information to keep engineers and managers abreast of rapid technology change

Full Aims & Scope

Meet Our Editors

Editor-in-Chief
Diomidis Spinellis
Athens University of Economics and Business
28is Oktovriou 76
Athina 104 33, Greece
dds@computer.org