RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 44
TI Scientific Software Development at a Research Facility
A1 Christine A. Ramsdale,
A1 Steve H. Kinder,
A1 Karen S. Ackroyd,
A1 Paul C. Stephenson,
A1 Mike C. Miller,
A1 Geoff R. Mant,
K1 Requirements
K1 specifications
K1 software engineering
K1 project management
K1 people management
K1 management of computing and information systems
K1 software construction
K1 physical sciences and engineering
AB The Synchrotron Radiation Computing Group at Daresbury Laboratory develops experiment control and data acquisition software to support scientific research. Here, the authors review their experiences and learning over the past 20 years, examining the organizational structure they use on a project to develop a generic data acquisition (GDA) system. They discuss what worked well, how they adapted methodologies and tools to meet their particular needs, and improvements for the future.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.93
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.93

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 18
TI Developing Scientific Software
A1 Judith Segal,
A1 Chris Morris,
K1 scientific computing
K1 high-performance computing
K1 simulation
K1 data visualization
AB Not all scientific computing is high-performance computing—the variety of scientific software is huge. Such software might be complex simulation software developed and running on a high-performance computer, or software developed on a PC for embedding into instruments; for manipulating, analyzing or visualizing data or for orchestrating workflows. This special issue provides some flavor of that variety. It also explores the question of how the development of scientific software can be improved.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.85
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.85

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 16
TI What Is a Requirements Engineer?
A1 Barbara Paech,
K1 software certification
K1 requirements engineering
K1 certified professional requirements engineering
K1 IREB
AB The lack of a clear definition about what constitutes a requirements engineer is problematic. Companies trying to establish clear RE responsibilities don't have clear standards on how to train their people, define the role, or choose the right people for the job. The Certified Professional for Requirements Engineering initiative (http://certified-re.de/en) has established a syllabus and a certification framework to improve this situation in industry.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.106
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.106

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 29
TI Understanding the High-Performance-Computing Community: A Software Engineer's Perspective
A1 Jeffrey C. Carver,
A1 Lorin M. Hochstein,
A1 Daniela Cruzes,
A1 Victor R. Basili,
A1 Jeffrey K. Hollingsworth,
A1 Marvin V. Zelkowitz,
A1 Forrest Shull,
K1 high-performance computing
K1 computational science
K1 empirical software engineering
K1 productivity
AB Studies of computational scientists developing software for high-performance computing systems indicate that these scientists face unique software engineering issues. Previous failed attempts to transfer SE technologies to this domain haven't always taken these issues into account. To support scientific-software development, the SE community can disseminate appropriate practices and processes, develop educational materials specifically for computational scientists, and investigate the large-scale reuse of development frameworks.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.103
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.103

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 14
TI Measuring Architectural Complexity
A1 Grady Booch,
K1 complexity
K1 complexity measurement
K1 decomposition
K1 architecture model
K1 design pattern
AB Without refactoring, complex software-intensive systems become increasingly irregular and thus increasingly chaotic over time. We can understand complex software systems only when they're nearly decomposable and hierarchic. One measure the author uses is lines of source code: the greater the SLOC, the more inertia to change the system will have, the more people it will take to keep it fed, the more stakeholders who will be crawling all over it. The author describes the more complex measures he uses; these are tuned to Philippe Kruchten's 4+1 view model of architecture. He also counts the number of identifiable design patterns at work. These metrics can generally be gathered automatically via clever mining of configuration management and testing data.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.91
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.91

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 4
TI Essentials of Software Process
A1 Hakan Erdogmus,
K1 utilitarian view of software process
K1 human-centricity
K1 pragmatism
K1 empiricism
K1 experimentation
K1 value orientation
AB Process trends can be placed inside a triangular map according to their emphasis on three aspects, represented by the vertices: people, technology, and rigor. Plan-oriented, engineering, and research-based approaches tend to view software as a rigid artifact, so they stress technology and rigor over people. Evolutionary approaches tend to view software development as an organic, skills-driven technical activity, so they stress people and technology over rigor. But this scheme of positioning process approaches is rather rough. A more complete scheme requires dissection in terms of seven essential, mutually reinforcing characteristics: human-centricity, technical orientation, discipline, pragmatism, empiricism, experimentation, and value orientation.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.87
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.87

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 52
TI Supporting Scientists' Everyday Work: Automating Scientific Workflows
A1 Norman G. Vinson,
A1 Keith Mews,
A1 Mark Vigder,
A1 Janice Singer,
A1 Darlene Stewart,
K1 physical sciences and engineering
K1 workflow management
K1 office automation
K1 information technology and systems applications
K1 information technology and systems
K1 user-centered design
K1 user interfaces
K1 information interfaces and representation
K1 information technology and systems
AB An action research project involving scientists from the National Research Council Canada and the Institute for Ocean Technology analyzed difficulties in using software to collect data and manage processes. The project identified three requirements for increasing research productivity: ease of use for end users, managing scientific workflows, and facilitating software interoperability. On the basis of these requirements, the researchers developed Sweet, a software framework, to help automate scientific workflows.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.97
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.97

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 82
TI Testing the Value of Checklists in Code Inspections
A1 Les Hatton,
K1 software failure
K1 code inspections
K1 testing
AB Checklists are an important part of code and design inspections. Ideally, they aim to increase the number of faults found per inspection hour by highlighting known areas of previous failure. In practice, although some researchers have quantified checklists' benefits, the conclusions' statistical robustness hasn't been as well represented. The author subjects checklists' effectiveness to formal statistical testing, using data from 308 inspections by industrial engineers over a three-year period. The results showed no evidence that checklists significantly improved these inspections. Further analysis revealed that individual inspection performance varied by a factor of 10 in terms of faults found per unit time, and individuals found on average about 53 percent of the faults. Two-person teams found on average 76 percent of the faults.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.100
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.100

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 21
TI Dealing with Risk in Scientific Software Development
A1 Rebecca Sanders,
A1 Diane Kelly,
K1 Professional end-user developer
K1 scientific application software
K1 software development
K1 software testing
K1 empirical study
AB The development of scientific software involves risk in the underlying theory, its implementation, and its use. Through a series of interviews, the authors explored how research scientists at two Canadian universities developed their software. These interviews indicated that the scientists used a set of strategies to address risk. They also suggested where the software engineering community could perform research focused on specific problems faced by scientific software developers.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.84
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.84

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 89
TI The Way We Program
A1 Diomidis Spinellis,
K1 source code
K1 comments
K1 meaningful identifiers
K1 indentation
K1 whitespace
K1 art
AB Code lacking comments, meaningful identifiers, and correct indentation is a nightmare. By studying 30 programs of various sizes to measure what percentage of their source code consisted of comments, meaningful identifiers, and whitespace, the author found that more than half of the code served developers rather than the compiler. The relative composition of the three elements was equally distributed and didn't appear to vary with project size. This finding substantiates the view of programming as an art form and the importance of source code in the software development process. Therefore we need to focus management's attention on code and its developers.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.101
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.101

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 95
TI Two Mistakes and Error-Free Software: A Confession
A1 Robert L. Glass,
K1 software engineering
K1 software errors
K1 error-free software
K1 silver bullet
K1 Test Coverage Analyzer
AB The software development process and the resulting product are so complex that no error-detecting approach will ever be able to produce error-free software.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.102
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.102

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 74
TI Testing Feature-Rich Reactive Systems
A1 Tony Savor,
K1 test state space
K1 real-time
K1 reactive system
K1 test automation
K1 test generation
K1 telephony
K1 specification complexity
AB Reactive systems that service multiple clients or users are often highly configurable to provide customized, value-added services to individual users. A large configuration space is characteristic of such systems, resulting in a large test state space. A new framework reduces specification complexity and enables automated testing for such systems. A running example from class-5 telephony illustrates the benefits of this new approach and the experiences gained in developing and testing it.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.99
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.99

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 66
TI Structural Epochs in the Complexity of Software over Time
K1 Packaging
K1 Software packages
K1 Open source software
K1 Software measurement
K1 Application software
K1 Software testing
K1 Software maintenance
K1 Design methodology
K1 Software design
K1 Software systems
K1 structural epochs
K1 software evolution
K1 software complexity
K1 software structure
K1 Structure 101
AB A case study using a new complexity measurement framework called Structure 101 tracked the structural complexity of three open source software products through their different releases. The analysis found that, as these software products evolved, a large proportion of structural complexity in early releases at the application-code level progressively migrated to higher-level design and architectural elements in subsequent releases, or vice-versa. This pattern repeated itself throughout the evolution of the software product. Refactoring efforts successfully reduced complexity at lower levels, but shifted the complexity to higher levels in the design hierarchy. Conversely, design restructuring at higher levels shifted complexity to lower levels. If this trend holds true for other software products, then mere code refactoring might not be enough to effectively managing structural complexity. Periodic major restructuring of software applications at the design or architectural level could be necessary.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.96
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.96

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 92
TI What Do We Know about Developer Motivation?
A1 Nathan Baddoo,
A1 Tracy Hall,
A1 Sarah Beecham,
A1 Helen Sharp,
A1 Hugh Robinson,
K1 software developers
K1 motivation
K1 management
AB Software engineers will do better work and stay with a company if they are motivated—as a result the success of software projects is likely to improve. The authors use the findings from their in-depth review of the 92 studies published in the last 25 years on software engineer motivation to give an overview of what managers need to know to improve motivation among their employees.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.105
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.105

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 37
TI Scientific Software as Workflows: From Discovery to Distribution
A1 David Woollard,
A1 Nenad Medvidovic,
A1 Yolanda Gil,
A1 Chris A. Mattmann,
K1 workflow management
K1 programming environments and construction tools
K1 software construction
AB Scientific workflows—models of computation that capture the orchestration of scientific codes to conduct in silico research—are gaining recognition as an attractive alternative to script-based orchestration. Even so, researchers developing scientific workflow technologies still face fundamental challenges, including developing the underlying science of scientific workflows. You can classify scientific-workflow environments according to three major phases of in silico research: discovery, production, and distribution. On the basis of this classification, scientists can make more-informed decisions regarding the adoption of particular workflow environments.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.92
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.92

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 8
TI Semantic Wikis
A1 Sebastian Schaffert,
A1 Malte Kiesel,
A1 Fran?ois Bry,
A1 Joachim Baumeister,
K1 semantic web
K1 ontologies
K1 web applications
AB Semantic Wikis are connecting established wiki concepts with semantic technologies by combining social intelligence with AI. This overview of the basic ideas of semantic wikis includes examples of existing system implementations and briefly discusses promising application areas.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.95
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.95

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 12
TI Up-front Design
A1 Rebecca J. Wirfs-Brock,
K1 up-front design
K1 software development
AB There can be significant benefits in thinking through a design until you get it "right enough" before launching into a major development effort. For such up-front design to be effective, you must develop a design rhythm that balances thinking, learning, and doing.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.104
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.104

RT Journal Article
JF IEEE Software
YR 2008
VO 25
IS
SP 59
TI Development of a Weather Forecasting Code: A Case Study
A1 Andrew Mark,
A1 Jeffrey C. Carver,
A1 Richard Kendall,
A1 David Fisher,
A1 Dale Henderson,
A1 Douglass Post,
A1 Clifford E. Rhoades Jr.,
A1 Susan Squires,
K1 software engineering
K1 management
K1 software engineering process: life cycle
K1 physical sciences and engineering
AB Computational science is increasingly supporting advances in scientific and engineering knowledge. The unique constraints of these types of projects result in a development process that differs from the process more traditional information technology projects use. This article reports the results of the sixth case study conducted under the support of the Darpa High Productivity Computing Systems Program. The case study aimed to investigate the technical challenges of code development in this environment, understand the use of development tools, and document the findings as concrete lessons learned for other developers' benefit. The project studied here is a major component of a weather forecasting system of systems. It includes complex behavior and interaction of several individual physical systems (such as the atmosphere and the ocean). This article describes the development of the code and presents important lessons learned.
PB IEEE Computer Society, [URL:http://www.computer.org]
SN 0740-7459
LA English
DO 10.1109/MS.2008.86
LK http://doi.ieeecomputersociety.org/10.1109/MS.2008.86