By Topic

IEEE Software

Issue 3 • May-June 2007

Filter Results

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

    Publication Year: 2007, Page(s): c1
    Request permission for commercial reuse | PDF file iconPDF (888 KB)
    Freely Available from IEEE
  • [Inside front cover]

    Publication Year: 2007, Page(s): c2
    Request permission for commercial reuse | PDF file iconPDF (884 KB)
    Freely Available from IEEE
  • [Advertisement]

    Publication Year: 2007, Page(s): 1
    Request permission for commercial reuse | PDF file iconPDF (1132 KB)
    Freely Available from IEEE
  • Table of contents

    Publication Year: 2007, Page(s):2 - 3
    Request permission for commercial reuse | PDF file iconPDF (888 KB)
    Freely Available from IEEE
  • Article summaries

    Publication Year: 2007, Page(s): 4
    Request permission for commercial reuse | PDF file iconPDF (33 KB)
    Freely Available from IEEE
  • Novelty in Sameness

    Publication Year: 2007, Page(s):5 - 7
    Request permission for commercial reuse | PDF file iconPDF (156 KB) | HTML iconHTML
    Freely Available from IEEE
  • Letters

    Publication Year: 2007, Page(s):8 - 9
    Request permission for commercial reuse | PDF file iconPDF (924 KB) | HTML iconHTML
    Freely Available from IEEE
  • The Irrelevance of Architecture

    Publication Year: 2007, Page(s):10 - 11
    Cited by:  Papers (2)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (234 KB) | HTML iconHTML

    The architecture of a software-intensive system is largely irrelevant to its end users. Far more important to these stakeholders is the system's behavior, exhibited by raw, naked, running code. Most interesting system tests should be based on the use cases that are identified incrementally over the system's life cycle, the same use cases that the system's architects used to guide their design deci... View full abstract»

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

    Publication Year: 2007, Page(s):12 - 14
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (445 KB) | HTML iconHTML

    Design reviews are an essential part of any design process. However, taking the criticism that comes from such reviews can be hard. The word criticism even has a slightly negative connotation in our culture. But design criticism is invaluable, and effectively giving and receiving it are skills that every software designer needs to master. It can be difficult to filter out constructive arguments fr... View full abstract»

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

    Publication Year: 2007, Page(s): 15
    Request permission for commercial reuse | PDF file iconPDF (768 KB)
    Freely Available from IEEE
  • Ship Effortlessly

    Publication Year: 2007, Page(s):16 - 17
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (153 KB) | HTML iconHTML

    Shipping software is difficult work and it's much more than just writing code. We need to decide which version to deliver, be sure we can build that exact version, package it for installation, and then either deliver or deploy a copy the customer can use. Shipping software is tough enough when all these "postproduction" activities go smoothly, but more often than not, teams stumble over them. You ... View full abstract»

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

    Publication Year: 2007, Page(s):18 - 20
    Cited by:  Papers (3)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (145 KB) | HTML iconHTML

    Successful requirements engineering is about more than just managing requirements. It's also about the relationship to and management of specifications. Typically, traceability structures capture the relationships between requirements, specifications, and domain statements. Traceability is therefore about more than just the relationships between requirements, stakeholders, and designs. At Praxis, ... View full abstract»

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

    Publication Year: 2007, Page(s): 21
    Request permission for commercial reuse | PDF file iconPDF (1046 KB)
    Freely Available from IEEE
  • Silver Bullets and Other Mysteries

    Publication Year: 2007, Page(s):22 - 23
    Cited by:  Papers (2)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (123 KB) | HTML iconHTML

    What can developers do when faced with an aged software system? This is where a silver bullet comes in handy. At various times, this silver bullet has been known by names such as structured programming, object-oriented languages, 4GLs (fourth-generation programming languages), CASE (computer-aided software engineering) tools, RDBMSs (relational database management systems), XML, visual programming... View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Guest Editors' Introduction: TDD--The Art of Fearless Programming

    Publication Year: 2007, Page(s):24 - 30
    Cited by:  Papers (17)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (474 KB) | HTML iconHTML

    Test-driven development is a discipline of design and programming where every line of new code is written in response to a test the programmer writes just before coding. This special issue of IEEE Software includes seven feature articles on various aspects of TDD and a Point/Counterpoint debate on the use of mock objects in applying it. The articles demonstrate the ways TDD is being used in nontri... View full abstract»

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

    Publication Year: 2007, Page(s): 31
    Request permission for commercial reuse | PDF file iconPDF (1253 KB)
    Freely Available from IEEE
  • Professionalism and Test-Driven Development

    Publication Year: 2007, Page(s):32 - 36
    Cited by:  Papers (7)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (243 KB) | HTML iconHTML

    Test-driven development is a discipline that helps professional software developers ship clean, flexible code that works, on time. In this article, the author discusses how test-driven development can help software developers achieve a higher degree of professionalism View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Test-Driven Development of Relational Databases

    Publication Year: 2007, Page(s):37 - 43
    Cited by:  Papers (6)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (385 KB) | HTML iconHTML

    In test-first development, developers formulate and implement a detailed design iteratively, one test at a time. Test-driven development (also called test-driven design) combines TFD with refactoring, wherein developers make small changes (refactorings) to improve code design without changing the code's semantics. When developers decide to use TDD to implement a new feature, they must first ask wh... View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Test-Driven Development of a PID Controller

    Publication Year: 2007, Page(s):44 - 50
    Cited by:  Papers (2)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (412 KB) | HTML iconHTML

    The development of embedded control systems in Simulink usually continues with automatic code generation, the build process, and several tests: software-in-the-loop (SiL), hardware-in-the-loop (HiL), and system tests in the real environment of the controller, the vehicle. Our test-driven control-system design cycle integrates into this process because it doesn't interrupt the system's model-based ... View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Test-Driven GUI Development with TestNG and Abbot

    Publication Year: 2007, Page(s):51 - 57
    Cited by:  Papers (9)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (164 KB) | HTML iconHTML Multimedia Media

    Testing GUIs can make the entire system safer and more robust. Any GUI, even one providing only the simplest capabilities, likely encloses some level of complexity. The more user-friendly a GUI is the more complexity it might be hiding from the user. Any complexity in software must be tested because code without tests is a potential source of bugs. A well-tested application has a greater chance of... View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Envisioning the Next-Generation of Functional Testing Tools

    Publication Year: 2007, Page(s):58 - 66
    Cited by:  Papers (4)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (202 KB) | HTML iconHTML

    The functional test-driven development (FTDD) cycle moves functional test specification to the earliest part of the software development life cycle. Functional tests no longer merely assess quality; their purpose now is to drive quality. For some agile processes such as extreme programming, functional tests are the primary requirements specification artifact. When functional tests serve as both th... View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Incorporating Performance Testing in Test-Driven Development

    Publication Year: 2007, Page(s):67 - 73
    Cited by:  Papers (8)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (1138 KB) | HTML iconHTML

    Our performance-testing approach required manually inspecting the performance logs. During the project's development, JUnit-based performance testing tools, such as JUnitPerf, weren't available. Such tools provide better visibility of performance problems than manual inspection of performance logs. Although we believe manual inspection of performance trends is necessary, specifying the bottom-line... View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Learning Test-Driven Development by Counting Lines

    Publication Year: 2007, Page(s):74 - 79
    Cited by:  Papers (4)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (513 KB) | HTML iconHTML

    During the last two years, Nokia Networks has started changing much of its product development from a traditional waterfall approach to Scrum, an agile software development process. Besides Scrum, there has been a lot of focus on engineering practices such as test-driven development. We've been involved in creating TDD training at Nokia Networks to support the transition to agile development. This... 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):80 - 83
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (76 KB) | HTML iconHTML

    Test-driven development with mock objects is a technique to support writing truly object-oriented code. What matters in object-oriented programming is what objects do, how each object responds to and affects its environment. Everything else is internal. In our experience, TDD with mock objects, or interaction testing, helps us write flexible, well-structured code composed of objects that are easy ... View full abstract»

    Full text access may be available. Click article title to sign in or learn about subscription options.
  • Determining Criteria for Selecting Software Components: Lessons Learned

    Publication Year: 2007, Page(s):84 - 94
    Cited by:  Papers (12)
    Request permission for commercial reuse | Click to expandAbstract | PDF file iconPDF (1075 KB) | HTML iconHTML

    Software component selection is growing in importance. Its success relies on correctly assessing the candidate components' quality. For a particular project, you can assess quality by identifying and analyzing the criteria that affect it. Component selection is on the suitability and completeness of the criteria used for evaluation. Experiences from determining criteria for several industrial proj... View full abstract»

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

Aims & Scope

IEEE Software 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