By Topic

Software, IEEE

Issue 2 • Date March-April 2007

Filter Results

Displaying Results 1 - 25 of 30
  • [Front cover]

    Publication Year: 2007 , Page(s): c1
    Save to Project icon | Request Permissions | PDF file iconPDF (806 KB)  
    Freely Available from IEEE
  • [Inside front cover]

    Publication Year: 2007 , Page(s): c2
    Save to Project icon | Request Permissions | PDF file iconPDF (361 KB)  
    Freely Available from IEEE
  • Call for Papers

    Publication Year: 2007 , Page(s): 1
    Save to Project icon | Request Permissions | PDF file iconPDF (48 KB)  
    Freely Available from IEEE
  • Table of contents

    Publication Year: 2007 , Page(s): 2 - 3
    Save to Project icon | Request Permissions | PDF file iconPDF (792 KB)  
    Freely Available from IEEE
  • Article summaries

    Publication Year: 2007 , Page(s): 4
    Save to Project icon | Request Permissions | PDF file iconPDF (31 KB)  
    Freely Available from IEEE
  • What's Good Software, Anyway?

    Publication Year: 2007 , Page(s): 5 - 7
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | PDF file iconPDF (135 KB) |  | HTML iconHTML  
    Freely Available from IEEE
  • Letters

    Publication Year: 2007 , Page(s): 8
    Cited by:  Papers (1)
    Save to Project icon | Request Permissions | PDF file iconPDF (226 KB) |  | HTML iconHTML  
    Freely Available from IEEE
  • Toward Design Simplicity

    Publication Year: 2007 , Page(s): 9 - 11
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (165 KB) |  | HTML iconHTML  

    When designing I tend to go with the flow. I don't think deeply about why I'm making any particular decision. I'm an intuitive designer. I do have a set of principles that drive my decision making. But I don't ponder what principle to apply at each moment or worry about violating any specific principle when I do make a decision. My design process is fluid, dynamic, and somewhat messy. I'm comfortable with tossing out partial solutions when better ideas come along. Rework and revision seem natural and necessary. A sense of design aesthetics drives my decision making as much as anything. Clean designs are better than messy ones. Simplicity does not precede complexity, but follows it. Get it working, then get it working better seems to track with my experience. But not every comprehensive solution can be simplified View full abstract»

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

    Publication Year: 2007 , Page(s): 12 - 13
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (328 KB) |  | HTML iconHTML  

    Whenever the author conducts an architectural assessment for software development projects, he endeavors to speak truth to power: those with true power never fear the truth. Sam Guckenheimer has observed that in software code there is truth. Code represents the stark reality of a software development organization's labor. There is also truth to be found in a system's architecture. Every system's architecture is molded by the forces that swirl around it, and the collective concerns of all the stakeholders represent the most dynamic forces shaping a system. The software development organization's unique task is to address all the essential concerns of all the important stakeholders and to ensure that they aren't blindsided by unexpected problems and stakeholders. This is why employing a process that incrementally and iteratively grows a system's architecture through the regular release of testable executables is so important. Such a process lets the software team engage the right stakeholders at the right time and to make the right decisions, neither too early nor too late. In creating a software-intensive system that's both relevant and beautiful, every stakeholder, no matter how close or how far from the code, deserves the truth View full abstract»

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

    Publication Year: 2007 , Page(s): 14 - 15
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (558 KB) |  | HTML iconHTML  

    Accepting some of the testing team's responsibility by writing your own tests lets you trade the time you spend fixing defects for less time spent avoiding them in the first place. View full abstract»

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

    Publication Year: 2007 , Page(s): 16 - 17
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (120 KB) |  | HTML iconHTML  

    The ultimate source of truth regarding a program is its execution. When a program runs, everything comes to light: correctness, CPU and memory use, and even interactions with (potentially buggy) libraries, operating systems, and hardware. Yet, this source of truth is also fleeting, rushing into oblivion at the tune of billions of instructions per second. Worse, capturing that truth can be a tricky, tortuous, or downright treacherous affair. Peeking into a program's operation typically involves preparing a special version of it: we might compile it with specific flags or options, link it with appropriate libraries, or run it with suitable arguments. Often, we can't easily reproduce a problem, so we need to ship our carefully crafted program version to a customer, who then will have to wait for the problem to appear again. Irritatingly, some of the ways we instrument programs make the program too slow for production use or obfuscate the original problem View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Guest Editors' Introduction: Stakeholders in Requirements Engineering

    Publication Year: 2007 , Page(s): 18 - 20
    Cited by:  Papers (10)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1050 KB) |  | HTML iconHTML  

    The growing attention being paid to stakeholders' needs and desires reflects the growing importance of requirements engineering (RE) in software and systems development. This introduction reviews the RE process: identifying the stakeholders in a project, determining who and how important they are, prioritizing the identified stakeholder roles, and selecting representative individuals or groups from the identified and prioritized stakeholder roles with whom the development team can elicit and validate system requirements. The authors then mention each article in the issue in the context of today's latest thinking on RE. This article introduces a special issue on stakeholders in requirements engineering. View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Stakeholders in Global Requirements Engineering: Lessons Learned from Practice

    Publication Year: 2007 , Page(s): 21 - 27
    Cited by:  Papers (36)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (187 KB) |  | HTML iconHTML  

    Due to its communication and collaboration-intensive nature, as well as inherent interaction with most other development processes, the practice of requirements engineering is becoming a key challenge in global software engineering (GSE). In distributed projects, cross-functional stakeholder groups must specify and manage requirements across cultural, time-zone, and organizational boundaries. This creates a unique set of problems, not only when an organization opens new development subsidiaries across the world but also when software development is a multiorganizational business affair. We need innovative processes and technologies to manage stakeholders' expectations and interaction in global projects. This article reports on the state of the practice, drawn from industrial empirical studies, of stakeholders' interaction in global RE. The article revisits stakeholders' needs in global RE, discusses the challenges they face in distributed interaction, and offers practical advice to alleviate these challenges, as distilled from empirical studies of GSE practice View full abstract»

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

    Publication Year: 2007 , Page(s): 28 - 35
    Cited by:  Papers (36)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (856 KB) |  | HTML iconHTML  

    Requirements elicitation and documentation are complex activities. So, not only the requirements themselves but also the people involved and the means for managing the requirements will evolve during the project. For example, it might be necessary to add RE personnel, to document templates, or to change the requirements classification scheme. In summary, especially in participative RE, the underlying platform as well the RE approach must be flexible. As the well-known Wikipedia shows, wikis provide a flexible platform for asynchronous collaboration to create content in general. In this article, we investigate how to adapt this approach to support active stakeholder participation in RE. We include a document structure for wiki-based RE and discuss potential problems and solutions based on our experience View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Stakeholder Risk Assessment: An Outcome-Based Approach

    Publication Year: 2007 , Page(s): 36 - 45
    Cited by:  Papers (4)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (290 KB) |  | HTML iconHTML  

    Managing software projects can often degrade into fighting fires lit by the embers of unrecognized and unmanaged risks. Stakeholders are a recognized source of significant software project risk, but few researchers have focused on providing a practical method for identifying specific project stakeholders. Furthermore, no methods provide guidance in identifying and managing project risks arising from those stakeholders. We developed the outcome-based stakeholder risk assessment model to provide this practical guidance. OBSRAM offers the project team a step-by-step approach to identifying stakeholders during requirements engineering, identifying stakeholder influences on the project, identifying the project's impact on stakeholders, and assessing the risks that their potential negative responses pose. We illustrate OBSRAM using a case study of a simulated airline-crew-scheduling system project that aims to reduce aircraft ground turnaround time to 30 minutes or less View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Determining Stakeholder Needs in the Workplace: How Mobile Technologies Can Help

    Publication Year: 2007 , Page(s): 46 - 52
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (788 KB) |  | HTML iconHTML  

    Mobile technologies offer exciting new opportunities to improve important requirements processes. However, providing usable, useful mobile requirements engineering (RE) tools is challenging due to mobile devices' limitations and limited knowledge on successfully using mobile RE tools in the field. You can use the reported lessons learned as an initial guide to develop and use mobile RE tools successfully. We believe that mobile RE tools will complement rather than replace traditional approaches, and the combination of context-aware and conventional elicitation and negotiation approaches has the potential to improve the quality of requirements. Evaluation studies also revealed several issues, including biases arising from the limited information available on mobile devices; integrated training, process guidance, and tool support for analysts; and guidance for end users to discover and document their own requirements. Further work in the mobile RE field is needed to address these issues. Mobile RE tools help elicit stakeholder heeds in the workplace. The authors discuss lessons learned that practitioners can adopt and use in their work View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • So, You Think You Know Others' Goals? A Repertory Grid Study

    Publication Year: 2007 , Page(s): 53 - 61
    Cited by:  Papers (8)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (469 KB) |  | HTML iconHTML  

    Recent research in requirements engineering (RE) has generated a number of notations for modeling stakeholders' goals and the relationships between them. However, the community has paid little attention to how stakeholders can develop consensus on the meaning of the goals in a goal model. In this article, we show how to use the repertory grid technique (RGT) to compare stakeholders' terms when they describe their softgoals (goals whose satisfaction can't be established in a clear-cut sense). We conducted a pilot study for a nonprofit organization to demonstrate our approach. The study shows that the technique can readily identify agreements and mismatches in stakeholders' terminologies and can be performed without preliminary training or specific resources View full abstract»

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

    Publication Year: 2007 , Page(s): 62 - 65
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (1047 KB)  

    The key to successful systems is building what the stakeholders desire. In a way, this point can hardly be gain.said: nobody wants to build what the stakeholders don't desire. But as usual, the devil is in the details. this paper contrasts two examples to illustrate what it can mean to build what stakeholders desire. There's an old saying in software development that the users don't know what they want until you give them what they asked for. Experienced developers often smile ruefully when they hear this, having been told at least once in their careers that a system they had delivered was totally unacceptable when it was exactly (as far as they could tell) what was requested. There's more to delivering good software than following orders. The paper describes what positive role developers can play in discovering and exploring requirements View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Metrics-Based Management of Software Product Portfolios

    Publication Year: 2007 , Page(s): 66 - 72
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (258 KB) |  | HTML iconHTML  

    Commmercial software product vendors such as Microsoft, IBM, and Oracle develop and manage a large portfolio of software products, which might include operating systems, middleware, firmware, and applications. Many institutions (such as banks, universities, and hospitals) also create and manage their own custom applications. Managers at these companies face an important problem: How can you manage investment, revenue, quality, and customer expectations across such a large portfolio? A heuristics-based product maturity framework can help companies effectively manage the development and maintenance of a portfolio of software products View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Misleading Metrics and Unsound Analyses

    Publication Year: 2007 , Page(s): 73 - 78
    Cited by:  Papers (2)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (976 KB) |  | HTML iconHTML  

    The authors demonstrate that the recommendations for analyzing productivity in the appendix to the ISO/IEC 15939 standard are inappropriate. They also show that problems with the ISO/IEC advice can be compounded if software engineers attempt to apply statistical process-control techniques to software productivity metrics. They recommend using small meaningful data sets as the basis for productivity analysis and using effort-estimation models to assess productivity rather than productivity metrics. This article is part of a special focus section of software metrics View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • A Practical Approach for Quality-Driven Inspections

    Publication Year: 2007 , Page(s): 79 - 86
    Cited by:  Papers (6)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (142 KB) |  | HTML iconHTML  

    Software inspection is a rigorous process for validating software work products that's both efficient and cost effective. However, this process presents challenges that might keep software developers from continuing to implement inspections. From our experience, major reasons for this are poor or missing customization of inspections for given context characteristics and insufficient stakeholder involvement. The TAQtIC (Tailoring Approach for Quality-Driven Inspections) inspection approach lets organizations implement inspections in a sustainable way in a given organizational context. Practitioners can use TAQtIC's underlying concepts to customize inspections for their environment. Experiences from projects using this approach demonstrate how organizations can tailor inspections of their software products View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Using Eclipse as a Tool-Integration Platform for Software Development

    Publication Year: 2007 , Page(s): 87 - 89
    Cited by:  Papers (3)
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (312 KB) |  | HTML iconHTML  

    Eclipse is an open source software project dedicated to providing a robust, full-featured, and commercial-quality platform for developing and supporting highly integrated software engineering tools. Excepting the small Eclipse runtime kernel, all the platform components are plug-in tools integrated seamlessly through predefined extension points. The platform supports deliverables throughout the development and maintenance life cycle View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Applications and Nominations Sought for Editor-in-Chief of IEEE Distributed Systems Online

    Publication Year: 2007 , Page(s): 90
    Save to Project icon | Request Permissions | PDF file iconPDF (269 KB)  
    Freely Available from IEEE
  • Book Shelf

    Publication Year: 2007 , Page(s): 91 - 93
    Save to Project icon | Request Permissions | PDF file iconPDF (59 KB) |  | HTML iconHTML  
    Freely Available from IEEE
  • Currents

    Publication Year: 2007 , Page(s): 94 - 98
    Save to Project icon | Request Permissions | Click to expandQuick Abstract | PDF file iconPDF (63 KB) |  | HTML iconHTML  

    The Google Web Toolkit's public debut and rapid maturing have brought attention to the myriad tools and frameworks for facilitating Web applications, particularly those written with Ajax Asynchronous JavaScript and XML. GWT's debut had significance for the industry far beyond Google itself. It was a lot like what Google Maps did for Ajax technology in general; it legitimized the idea of an Ajax component framework and made Ajax frameworks more visible. It is widely believed that GWT's debut signals a new era of visibility for Ajax frameworks 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