By Topic

Software, IEEE

Issue 6 • Date Nov.-Dec. 2011

Filter Results

Displaying Results 1 - 25 of 28
  • Front Cover

    Page(s): c1
    Save to Project icon | Request Permissions | PDF file iconPDF (1123 KB)  
    Freely Available from IEEE
  • Charter Business Advertisement

    Page(s): c2
    Save to Project icon | Request Permissions | PDF file iconPDF (523 KB)  
    Freely Available from IEEE
  • IEEE Computer Society CSDP

    Page(s): 1
    Save to Project icon | Request Permissions | PDF file iconPDF (5155 KB)  
    Freely Available from IEEE
  • Table of Contents

    Page(s): 2 - 3
    Save to Project icon | Request Permissions | PDF file iconPDF (1095 KB)  
    Freely Available from IEEE
  • Assuring the Future? A Look at Validating Climate Model Software

    Page(s): 4 - 8
    Save to Project icon | Request Permissions | PDF file iconPDF (2512 KB)  
    Freely Available from IEEE
  • What an Agile Architect Can Learn from a Hurricane Meteorologist

    Page(s): 9 - 12
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (910 KB) |  | HTML iconHTML  

    You'll have to read further to find out! There are so many interesting things about this article-it's the first in a series based on presentations from the SATURN conference. My first college degree was in chemistry, so there was an immediate connection for me with this story about chemical abstracts. The author brings us architectural wisdom, combined with an agile point of view and weather forecasting. View full abstract»

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

    Page(s): 13 - 17
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1949 KB)  

    Software systems must continually evolve to meet ever changing needs. However, such systems often become legacy systems as a consequence of uncontrolled maintenance combined with obsolete technology. To control maintenance costs and preserve complex embedded business rules, companies must evolve their legacy systems. This article introduces technologies for software reengineering. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • The Architecture of Small Things

    Page(s): 18 - 19
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (269 KB) |  | HTML iconHTML  

    There is complexity, and then there is organized complexity. Pure complexity is chaotic; organized complexity is full of patterns. Naming these patterns and respecting their intention is the essence of architecture. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • From Programming to Modeling - and Back Again

    Page(s): 20 - 25
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (714 KB)  

    The authors describe an issue that they think is extremely important: the relationship between applications and solutions in the software engineering and information systems fields. In particular, they believe the fields desperately need a taxonomy of application domains, a taxonomy of solution approaches, and a mapping between the two. This article has a Web extra that offers an interview with one of the article's authors, Robert L. Glass, about the "dark side" of this topic. View full abstract»

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

    Page(s): 26 - 28
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (686 KB)  

    Given the parallels between the complexity of human spaceflight and large software systems, there are many things we developers can learn from successful space programs, such as the Soyuz. First, limiting a project's scope and complexity early on can have a dramatic payoff in its success and longevity. In addition, adding generous margins to early estimates (and any subsequent revisions) will ease the pain of development and deployment. Furthermore, gradual evolution with a working program at each step, rather than massive rewrites, benefits from successful architectures and teams, while also retaining the software's customer base and third-party contributors. Finally, a well-defined modular structure can increase the software's versatility yielding economies of scope and scale over its lifetime. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • To Pay or Not to Pay Technical Debt

    Page(s): 29 - 31
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (305 KB)  

    Ward Cunningham coined the term technical debt as a metaphor for the trade-off between writing clean code at higher cost and delayed de livery, and writing messy code cheap and fast at the cost of higher maintenance efforts once it's shipped. Joshua Kerievsky extended the metaphor to architecture and design. Technical debt is similar to financial debt: it supports quick development at the cost of compound interest to be paid later. The longer we wait to garden our design and code, the larger the amount of interest. Discussions of the metaphor have distinguished different types of technical debt and how and when to best pay them off. Most agree that, sooner or later, technical debt will come due. But is this assumption universally true? If it's better to pay interest, what factors influence the decision to service the debt? And if we decide to retire it, what approach should we take? View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Guest Editors' Introduction: Climate Change - Science and Software

    Page(s): 32 - 35
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (2891 KB) |  | HTML iconHTML  

    Climate change is likely to be one of the defining global issues of the 21st century. The past decade—the hottest in recorded history—has witnessed countries around the world struggling to deal with drought, heat waves, and extreme weather. The sheer scale of the problem also makes it hard to understand, predict, and solve. Climate science journals regularly publish special issues on specific climate models, typically timed to present results from a major new release of a given model. However, these tend to focus on the new science that the model enables, rather than to describe the software and its development. This special issue of IEEE Software magazine focuses on the "software" behind climate change models. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Clear Climate Code: Rewriting Legacy Science Software for Clarity

    Page(s): 36 - 42
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (2954 KB)  

    The Clear Climate Code project rewrote GISTEMP, a legacy software system used to produce an important global surface temperature dataset. The focus of the project is on clarity: making the source code as clear as possible to interested people, to improve public understanding. The result is a Python package that's easy to understand, run, and change, which allows any interested person to pose and answer novel research questions. In the process, the project's founders also discovered and fixed some inconsequential bugs and hopefully improved online discussion of global warming. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Managing Software Complexity and Variability in Coupled Climate Models

    Page(s): 43 - 48
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1361 KB) |  | HTML iconHTML  

    Coupled climate models exhibit scientific, numerical, and architectural variability. This variability introduces requirements that give rise to complexity. However, techniques exist that can tame this complexity; one such technique is feature analysis. As climate model fidelity and complexity increase, the climate-modeling community should adopt a systematic way to deal with software variability. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Software Testing and Verification in Climate Model Development

    Page(s): 49 - 55
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (2449 KB) |  | HTML iconHTML  

    Over the past 30 years, most climate models have grown from relatively simple representations of a few atmospheric processes to complex multidisciplinary systems. Computer infrastructure over that period has gone from punchcard mainframes to modern parallel clusters. Model implementations have become complex, brittle, and increasingly difficult to extend and maintain. Verification processes for model implementations rely almost exclusively on some combination of detailed analyses of output from full climate simulations and system-level regression tests. Besides being costly in terms of developer time and computing resources, these testing methodologies are limited in the types of defects they can detect, isolate, and diagnose. Mitigating these weaknesses of coarse-grained testing with finer-grained unit tests has been perceived as cumbersome and counterproductive. Recent advances in commercial software tools and methodologies have led to a renaissance of systematic fine-grained testing. This opens new possibilities for testing climate-modeling-software methodologies. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Enabling Open Development Methodologies in Climate Change Assessment Modeling

    Page(s): 56 - 61
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (737 KB) |  | HTML iconHTML  

    Computational simulation models help support scientifically grounded "what if" analyses by translating specialized knowledge into tools that can project the likely future impact of current actions. Models have thus become important in a variety of policy domains. In recent years, several software platforms for environmental policy-making and urban planning have added simulation models to decision support tools to provide stakeholders with direct access to these models. In this paper, we discuss the development of a publicly accessible Web service called ROMA (Radically Open Modeling Architecture) that allows anyone to create, combine, and run modular simulations, which can aid climate policy deliberations. ROMA currently provides the modeling functionality in the Climate CoLab (http:// climatecolab.org), a collective intelligence application in which large numbers of people work together to develop proposals to address climate change. In time, we hope that ROMA will support a community focused on model development and analysis. View full abstract»

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

    Page(s): 62 - 65
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (525 KB)  

    In "Open Source Climate Model Development Is Worth It," Isaac Held explains that a fully open source climate-modeling effort could be of great pedagogical value and maybe even of direct scientific importance by providing a toolbox for active researchers and people new to the field. In "Should Climate Models Be Open Source?" David Randall explains that ommunity-based climate model development can be facilitated by coding the model in a modular fashion, but it can cause problems because the real climate system isn't modular. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Pattern-Based Architecture Reviews

    Page(s): 66 - 71
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1540 KB)  

    Software architecture reviews are effective in identifying potential problems in architectures, however, are expensive, time-consuming, and generally rely on extensive architecture documentation. An architecture review that accommodates projects with very short development cycles, minimal documentation, or frequently changing requirements could be useful if it identifies important architectural issues. We developed a useful, inexpensive architecture review method that uses the architecture patterns in a system to identify important issues in the achievement of quality attributes. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using Guidelines to Improve Quality in Software Nonfunctional Attributes

    Page(s): 72 - 77
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1893 KB)  

    Software development aims to produce software systems that satisfy two requirement categories: functional and quality. One aspect of software quality is nonfunctional attributes (NFAs), such as security, performance, and availability. Software engineers can meet NFA requirements by applying suitable guidelines during software development. However, this process is complicated by the different effects of different guidelines on NFA quality and the relationships among the guidelines themselves. Thus, finding a suitable set of guidelines is not straightforward. This article introduces a step-by-step approach that gives software engineers a suitable guideline set to apply to improve NFA quality during the software development life cycle. The approach manages the effects different guidelines have on both the attributes and the relationships among the guidelines. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • SASSY: A Framework for Self-Architecting Service-Oriented Systems

    Page(s): 78 - 85
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (2473 KB) |  | HTML iconHTML  

    Making architectural decisions manually in the presence of quality-of-service trade-offs can be complicated. The SASSY (Self-architecting Software Systems) framework automatically generates candidate software architectures and selects the one that best serves stakeholder-defined, scenario-based quality-of-service (QoS) goals. This lets domain experts concentrate on functional and QoS requirements. SASSY reduces the effort of composing service-oriented systems by automatically generating the QoS-optimized architecture and rapidly reconfiguring it at runtime. Self-architecting occurs during initial system deployment and at runtime, thus making systems self-adaptive, self-healing, self-managing, and self-optimizing. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Verification and Validation for Trustworthy Software Systems

    Page(s): 86 - 92
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1225 KB) |  | HTML iconHTML  

    A continuous and proactive process for conducting verification and validation of systems involves using scenario-based testing to validate whether formal assertions correctly capture the intent of the natural language requirements. The process is automated through the use of statechart assertions and runtime execution monitoring. The statechart assertions can be used as part of a system reference model in support of independent verification and validation of trustworthy systems. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • 10 MLOC in Your Office Copier

    Page(s): 93 - 95
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (563 KB)  

    Amid the obvious volume of digital copiers and multifunction printers, the system size is in the millions of lines of code with functionality creep into several overlapping areas-a theme of many modern systems. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Developing Fault-Prediction Models: What the Research Can Show Industry

    Page(s): 96 - 99
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (383 KB)  

    A systematic review of the research literature on fault-prediction models from 2000 through 2010 identified 36 studies that sufficiently defined their models and development context and methodology. The authors quantitatively analyzed 19 of these studies and the 206 models they presented. They identified several key features to help industry software developers build or optimize fault-prediction models suitable to their specific contexts. View full abstract»

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

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

    Requirements analysts need to ask the right questions repeatedly. They need to be more inquisitive and know why people want things as well as what happens beforehand. This requires them to become less inhibited and keep asking questions until they and their stakeholders are satisfied with the answers. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • All Late Projects Are the Same

    Page(s): 104
    Multimedia
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (353 KB)  

    Lateness is the most common form of software project failure. Its causes can seem complex when viewed from ground level, but surprising simple with a slightly more distanced perspective. Note: Philippe Kruchten's last name is misspelled in the article sidebar. We apologize for this error. 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