RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 14
TI Tell Me a Story
A1 Alain D?silets,
K1 user centric
K1 storytelling
AB The next time you find yourself struggling with the details of your software's functionality, back up and tell a story. Talking through simple user scenarios can help keep you on the right track.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.50
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.50

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 34
TI A Risk-Based, Value-Oriented Approach to Quality Requirements
A1 Martin Glinz,
K1 Quality requirements
K1 Quantification
K1 Risk
K1 Value
AB Quality requirements, i.e. those requirements that pertain to a system's quality attributes, are traditionally regarded to be useful only when they are represented quantitatively so that they can be measured. This article presents a value-oriented approach to specifying quality requirements that deviates from the classic approach. This approach uses a broad range of potential representations that are selected on the basis of risk assessment. Requirements engineers select a quality requirement representation such that they get an optimal balance between mitigating the risk of developing a system that doesn't satisfy the stakeholders' desires and needs on the one hand and the cost of specifying the requirement in the selected representation on the other hand. This issue is part of a special issue on quality requirements.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.31
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.31

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 85
TI Orchestrating Web Services with BPEL
A1 Panagiotis Louridas,
K1 Web services
K1 Business Process Execution Language
AB The Business Process Execution Language specifies Web services that work together to perform a business process. BPEL is an orchestrating language: it sets down exactly how the Web services will cooperate to carry out the overall business process. BPEL is an XML-based programming language?that is, you write BPEL programs in XML. Because XML wasn't designed with programmers in mind, the programming results aren't prime examples of elegance. Fortunately, you rarely need to write in BPEL by hand. Most BPEL programs are written using special graphical editors that let you describe the business process diagrammatically and then automatically generate the corresponding BPEL code.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.42
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.42

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 4
TI Measurement Acquiescence
A1 Hakan Erdogmus,
K1 software development productivity
K1 software measurement
AB Measuring software development productivity is difficult, but it's not impossible. It's prone to misuse and misinterpretation, and highly portable, precise measures are elusive. But we can still implement meaningful measures, provided we understand why we're doing it and provided we're aware of their limitations.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.40
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.40

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 90
TI User Requirements and System Requirements
A1 Neil Maiden,
K1 requirements
K1 user requirements
K1 system requirements
AB Stakeholders, analysts, and designers often fail to differentiate the roles of user and system requirements. Unfortunately, treating them as the same thing can create problems for projects. Here are three strategies for managing user and system requirements more effectively.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.54
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.54

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 92
TI "Googling" Test Practices? Web Giant's Culture Encourages Process Improvement
A1 Greg Goth,
K1 Software development
K1 software testing
K1 Google
K1 OpenSocial
K1 Testapalooza
AB Google's position as a leading Web-based applications platform and its embrace of rigorous incremental testing might be the vanguard of a new definition of what software testing encompasses.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.28
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.28

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 20
TI Connecting Design with Code
A1 Rebecca J. Wirfs-Brock,
K1 design intent
K1 code
AB Code clutter and unnecessary complexity can obscure design. How can designers better present their design decisions in their code?
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.33
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.33

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 18
TI The Software Engineering Silver Bullet Conundrum
A1 Daniel M. Berry,
K1 silver bullet
K1 essence
K1 accidents
K1 pain of software development
K1 human ambition
K1 requirements change
K1 software engineering methods
AB Fred Brooks argued in 1986 that, for various reasons, no software engineering silver bullet would be found in the next decade. I argue now that the main reason that there can be no software engineering silver bullet is that as soon as one is produced, we software engineers move on almost immediately to solve even harder problems for which the silver bullet does not help much. That a silver bullet quickly ceases to be silver is the basic conundrum of software engineering silver bullets.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.51
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.51

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 11
TI Understanding the Customer: What Do We Know about Requirements Elicitation?
A1 Natalia Juristo,
A1 Oscar Dieste,
A1 Forrest Shull,
K1 Requirements elicitation techniques
K1 software requirements
AB "Getting the requirements right" is one of the most important activities in software development, and making a crucial misstep at this phase can easily lead to large amounts of rework. The best way to develop a high-quality system with minimal effort is still to get the requirements right the first time. However, requirements elicitation still relies mainly on the same old proven techniques: interviewing the customer and showing him or her prototypes to get feedback. Has research has provided any clues on how to better accomplish this?
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.53
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.53

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 64
TI Point/Counterpoint
A1 Tom Gilb,
A1 Alistair Cockburn,
K1 software engineering
K1 software metrics
K1 software quality
AB This department is part of a special issue on software quality requirements. The first article, "Metrics Say Quality Better than Words," is written by Tom Gilb. The second article, "Subjective Quality Counts in Software Development," is written by Alistair Cockburn.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.43
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.43

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 22
TI Software Quality Requirements: How to Balance Competing Priorities
A1 J. David Blaine,
A1 Jane Cleland-Huang,
K1 Quality requirements
K1 non-functional requirements
K1 product value
K1 architectural qualities
AB The elicitation, analysis, and specification of quality requirements involve careful balancing of a broad spectrum of competing priorities. Developers must therefore focus on identifying qualities and designing solutions that optimize the product's value to its stakeholders.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.46
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.46

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 25
TI Making Practical Use of Quality Attribute Information
K1 Design methodology
K1 Software systems
K1 Taxonomy
K1 Software engineering
K1 Software design
K1 ISO standards
K1 Automatic control
K1 Control systems
K1 Information analysis
K1 Terminology
K1 architecture-centric design methods
K1 quality attribute requirements
K1 software system design
K1 quality attribute scenarios
K1 utility tree
K1 attribute driven design
K1 object oriented analysis and design
AB Quality attribute requirements are important both for customer and end-user satisfaction and for driving software system design. Yet asserting their importance raises many other questions. In particular, using quality attribute information in practice isn't obvious. Here, we consider two aspects of using such information: communicating with stakeholders about quality attributes and incorporating quality attribute requirements into existing analysis and design methods.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.39
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.39

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 7
TI Dynamically Typed Languages
K1 null
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.35
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.35

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 16
TI Tribal Memory
A1 Grady Booch,
K1 system architecture
K1 legacy code
K1 stakeholder dialogue
AB As the code written today becomes part of tomorrow's inexorably growing legacy, preserving these stories becomes increasingly important. It's costly to rely upon informal storytelling to preserve and communicate important decisions; it's incredibly costly to try to recreate those decisions and their rationale when the storytellers themselves are gone. Insofar as a software development organization can preserve its stories in a system's written architecture, it can make evolving that system materially easier.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.52
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.52

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 49
TI A Broad, Quantitative Model for Making Early Requirements Decisions
A1 Steven L. Cornford,
A1 Martin S. Feather,
A1 Tim Menzies,
A1 James D. Kiper,
A1 Kenneth A. Hicks,
K1 decision support
K1 requirements analysis
K1 requirements elicitation
K1 management
K1 cost estimation
K1 risk management
K1 information visualization
K1 optimization
K1 data mining
AB During the early phases of project life cycles, detailed information is scarce, yet developers frequently need to make key decisions, especially concerning trade-offs among quality requirements. Such trading among competing concerns occurs in many fields, including systems, hardware, and software engineering. The defect detection and prevention model aids in requirements decision making in all such fields. The DDP model uses coarse quantification of relevant factors. Examples from studies of software technology requirements analyses illustrate this approach.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.29
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.29

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 88
TI Using and Abusing XML
A1 Diomidis Spinellis,
K1 keywords: XML
K1 best practices
K1 interoperability
K1 schemas
K1 style
AB XML has many strengths: computers and humans can both process it, special tools can validate it, and it promotes robust input handling. To achieve interoperability, we should formally define schemas (adopting existing ones, when possible), and test XML data with different producers and consumers. Formatting the data in a way that is accessible to both human readers and popular software tools is also a good practice. XML is also easily misused. Its adoption as a format for human-produced code, and the thin wrapping of arbitrary data with XML tags are two popular offences.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.55
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.55

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 77
TI Does Test-Driven Development Really Improve Software Design Quality?
A1 David Janzen,
A1 Hossein Saiedian,
K1 test design
K1 test-driven development
K1 TDD
K1 software design
K1 software architecture
K1 quality analysis
K1 quality metrics
AB Test-driven development (TDD) is first and foremost a design practice. The question is, "How good are the resulting designs?" Advocates claim that TDD produces code that is simpler, more cohesive, and less coupled than code developed in a more traditional test-last way. Sounds good, but is it true? We collected evidence to substantiate or question the claims regarding TDD's influence on software. We focused on internal software quality?that is, design and code characteristics such as code complexity, size, coupling, and cohesion. We conducted three quasicontrolled experiments and one case study in a Fortune 500 company and another two quasicontrolled experiments with university students in undergraduate and graduate software engineering courses. We evaluated 24 student and professional programmers working on 21 software projects ranging in size from a few hundred to over 30,000 lines of code. The results indicate that TDD programmers tend to write software modules that are smaller, less complex, and more highly tested than modules produced by their test-last counterparts. However, the results didn't support claims for lower coupling and increased cohesion with TDD.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.34
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.34

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 57
TI A New Standard for Quality Requirements
A1 Jørgen Bøegh,
K1 software quality
K1 quality model
K1 quality requirements
K1 quality attribute
K1 standard
K1 ISO
K1 ISO/IEC 25030
K1 nonfunctional requirements
K1 functionality
K1 reliability
K1 usability
K1 maintainability
K1 efficiency
K1 portability
K1 quality in use
AB Software quality requirements is an important but somewhat neglected topic in software and systems engineering. Problems with requirements are one of most important causes of project failures. The ISO has recently published a new standard, ISO/IEC 25030, on software quality requirements. This paper introduces the new standard and discusses some of the thoughts behind the standard. Users of the standard are encouraged to provide feedback to the standards committee. This article is part of a special issue on quality requirements.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.30
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.30

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 68
TI From Documents to Applications Using Markup Languages
A1 Alfredo Fern?ndez-Valmayor,
A1 Jos? Luis Sierra,
A1 Baltasar Fern?ndez-Manj?,
K1 specialized application languages
K1 markup languages
K1 distribution
K1 maintenance and enhancement
AB This article proposes a software development approach that creates applications by processing documents that describe the application's data and structure. Domain experts mark up the documents using domain-specific descriptive markup languages, and developers build application kernels. The kernels process the marked documents and generate the applications as instantiations of object-oriented application frameworks. This document-oriented approach facilitates domain experts' active involvement in the development process while simplifying key aspects such as application production and maintenance.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.36
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.36

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 42
TI Supporting Roadmapping of Quality Requirements
A1 Richard Berntsson Svensson,
A1 Björn Regnell,
A1 Thomas Olsson,
K1 requirements engineering
K1 nonfunctional requirements
K1 quality requirements
K1 trade-off analysis
K1 cost-benefit analysis
K1 performance requirements
K1 roadmapping
AB When dealing with quality requirements, you often end up in difficult trade-off analysis. You must take into account aspects such as release targets, end-user experience, and business opportunities. At the same time, you must consider what is feasible with the evolving system architecture and the available development resources. Our experience from the mobile-phone domain shows that much can be gained if development team members share a common framework of quality indicators and have a simple, easy-to-use model for reasoning about quality targets. To support quality-requirements analysis, the Quper (quality performance) model combines cost and benefit views into a roadmap of each important quality indicator for the particular domain. The practical application of Quper involves six steps. This article is part of a special issue on quality requirements.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.48
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.48

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 95
TI On the Impurity of the English Language
A1 Robert L. Glass,
K1 English
K1 natural-language processing
K1 translation
K1 pronunciation
K1 software engineering
AB English's ambiguities and variations make it difficult to support as a universal language.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.41
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.41