By Topic

Software, IEEE

Issue 3 • Date May-June 1997

Filter Results

Displaying Results 1 - 24 of 24
  • Ariane 5: Who Dunnit?

    Page(s): 15 - 16
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (127 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.
  • Software risk management

    Page(s): 17 - 19
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (114 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.
  • Risk management may not be for everyone

    Page(s): 21 - 24
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (115 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.
  • Full text access may be available. Click article title to sign in or learn about subscription options.
  • Classifying software-based cache coherence solutions

    Page(s): 90 - 101
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (461 KB)  

    The authors propose a classification for software solutions to cache coherence in shared memory multiprocessors and show how it can be applied to more completely understand existing approaches and explore possible alternatives. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Guidelines for applying research results

    Page(s): 102 - 104
    Save to Project icon | Request Permissions | PDF file iconPDF (154 KB)  
    Freely Available from IEEE
  • Programming with class: a C++ introduction to computer science [Book Review]

    Page(s): 122
    Save to Project icon | Request Permissions | PDF file iconPDF (139 KB)  
    Freely Available from IEEE
  • The craft software testing [Book Reviews]

    Page(s): 123
    Save to Project icon | Request Permissions | PDF file iconPDF (130 KB)  
    Freely Available from IEEE
  • Operating Systems [Book Reviews]

    Page(s): 123
    Save to Project icon | Request Permissions | PDF file iconPDF (130 KB)  
    Freely Available from IEEE
  • Executive guide to preventing information technology disasters [Book Reviews]

    Page(s): 124
    Save to Project icon | Request Permissions | PDF file iconPDF (147 KB)  
    Freely Available from IEEE
  • Managing a programming project-Processes and People [Book Reviews]

    Page(s): 124
    Save to Project icon | Request Permissions | PDF file iconPDF (147 KB)  
    Freely Available from IEEE
  • Risk management is project management for adults

    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (132 KB)  

    Too often in the software industry, organizations approach project management in the same way a desperate gambler approaches the tables at Las Vegas or Monaco-with only one thought in mind: roll the dice. In a dice-tossing project, there is nothing you can do to improve your odds. Of course, that is not true for your software projects, but nothing you can do will make your risks go away completely. You can ignore them or you can deal with them explicitly. If you ignore your project's risks, all your other efforts will be for naught. Your project's success is based on opportunity and benefit, on cost and risk. Opportunity and benefit address the value of the delivered software. Cost and risk address the minimum and variable costs-in units of money, time and effort-that are necessary to deliver that product. Any form of risk management is better than none. If you have project management responsibilities, who should be dealing with the inherent risks of your project if not you? View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Managing risk in software maintenance

    Page(s): 43 - 50
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (168 KB)  

    Software risk management in maintenance differs in major ways from risk management in development. Risk opportunities are more frequent, risks come from more diverse sources, and projects have less freedom to act on them. The authors describe how they dealt with these differences in a large US Navy software maintenance organization View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • How experienced project managers assess risk

    Page(s): 35 - 41
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (116 KB)  

    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 View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Estimates, uncertainty, and risk

    Page(s): 69 - 74
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (132 KB)  

    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 View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Gauging software readiness with defect tracking

    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (124 KB)  

    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 View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Software “engineer”? Time will tell

    Page(s): 105 - 106
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (84 KB)  

    A discussion is given on the legal and policy aspects of information technology use and development in the US. There is a continuing proliferation of individuals and companies who portray themselves as being or employing software “gurus”, “experts” and “engineers”-titles that imply the knowledge and capability to resolve programming problems. Many of these individuals either lack these skills and experience or are applying their knowledge in environments where it has no value. This problem is particularly acute in the area of telephony or data/software/telecommunications convergence. There are signs, however, that your ability to describe yourself as an engineer or your company's services as engineering, without proper training and certification, may be coming to an end View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Implementing risk management on software intensive projects

    Page(s): 83 - 89
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (132 KB)  

    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 View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Putting risk management into practice

    Page(s): 75 - 82
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (172 KB)  

    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 View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Heuristic risk assessment using cost factors

    Page(s): 51 - 59
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (412 KB)  

    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 View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Let's ask the users [user interfaces]

    Page(s): 110 - 111
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (100 KB)  

    Tools, techniques, and concepts to optimize user interfaces are presented. Many aspects of usability can best be studied by simply asking the users. This is especially true for issues related to user satisfaction and anxiety, which are hard to measure objectively. Questionnaires and interviews are two methods you can use to determine how people use a system and what features they particularly like or dislike. Both methods are indirect: they do not study the interface itself but rather users' opinions about it View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The project scoping gamble

    Page(s): 107 - 109
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (208 KB)  

    A discussion is given on how to get people and technology to work together. The authors argue that software project managers can learn important lessons from the gambler. Software development is a gamble. Its a risky game-not unlike high stakes poker. And, like a gambler who must try to figure the best bet, when we're put on the spot trying to “scope” a software project we feel in need of some advice. Judging the timing and resources for a project is difficult when there's not much to go on. And yet, if you fail to estimate correctly, developers, management, and customers will all be unhappy. Defining a proper scope for your project won't guarantee its success, but a poor and especially an overly restricted scope may doom your project to failure. A gambler playing poker uses a variety of strategies to improve the odds of winning View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Integrating risk assessment with cost estimation

    Page(s): 61 - 67
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (192 KB)  

    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 View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Testing for millennium risk management

    Page(s): 126 - 127, 130-1
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (296 KB)  

    The Year 2000 conversion is a challenge to the economics of both testing and maintenance, but as a whole we are not responding with balanced priorities. Those looking for Year 2000 solutions typically allocate their first energies and budgets to acquiring automated analysis and conversion deals and services. This disturbing tendency ignores two facts that surface in virtually every analysis of the Year 2000 challenge: fifty percent or more of the effort will be in testing; and despite consuming a wealth of resources each year, current testing practices cannot satisfy the demands of current maintenance unrelated to the Y2K conversion. For the moment, most organizations continue to delay action on the Y2K Test problem while wading through the dozens of available analysis and conversion solutions. As a result, many Y2K projects have started on master plans that will need major revision once the true needs and benefits of testing automation become apparent. A growing number of those projects have already corrected course, revising strategy and reallocating budgets once they appreciated the nature of the Y2K testing challenge. Embarrassment will probably be the least of many worries for those that ignore the challenge much longer 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
Forrest Shull
Fraunhofer Center for Experimental Software Engineering