Explora: Infrastructure for Scaling Up Software Visualisation to Corpora

Visualisation provides good support for software analysis. It copes with the intangible nature of software by providing concrete representations of it. By reducing the complexity of software, visualisations are especially useful when dealing with large amounts of code. One domain that usually deals with large amounts of source code data is empirical analysis. Although there are many tools for analysis and visualisation, they do not cope well software corpora. In this paper we present Explora, an infrastructure that is specifically targeted at visualising corpora. We report on early results when conducting a sample analysis on Smalltalk and Java corpora.

Embedding Spatial Software Visualization in the IDE: an Exploratory Study

Software visualization can be of great use for understanding and exploring a software system in an intuitive manner. Spatial representation of software is a promising approach of increasing interest. However, little is known about how developers interact with spatial visualizations that are embedded in the IDE. In this paper, we present a pilot study that explores the use of Software Cartography for program comprehension of an unknown system. We investigated whether developers establish a spatial memory of the system, whether clustering by topic offers a sound base layout, and how developers interact with maps. We report our results in the form of observations, hypotheses, and implications. Key findings are a) that developers made good use of the map to inspect search results and call graphs, and b) that developers found the base layout surprising and often confusing. We conclude with concrete advice for the design of embedded software maps

MRI-based breast volumetry-evaluation of three different software solutions

As lipofilling of the female breast is becoming more popular in plastic surgery, the use of MRI to assess breast volume has been employed to control postoperative results. Therefore, we sought to evaluate the accuracy of magnetic resonance imaging (MRI)-based breast volumetry software tools by comparing the measurements of silicone implant augmented breasts with the actual implant volume specified by the manufacturer. MRI-based volume analysis was performed in eight bilaterally augmented patients (46 ± 9 years) with three different software programs (Brainlab© I plan 2.6 neuronavigation software; mass analysis, version 5.3, Medis©; and OsiriX© v.3.0.2. 32-bit). The implant volumes analysed by the BrainLab© software had a mean deviation of 2.2 ± 1.7% (r?=?0.99) relative to the implanted prosthesis. OsiriX© software analysis resulted in a mean deviation of 2.8 ± 3.0% (r?=?0.99) and the Medis© software had a mean deviation of 3.1 ± 3.0% (r?=?0.99). Overall, the volumes of all analysed breast implants correlated very well with the real implant volumes. Processing time was 10 min per breast with each system and 30 s (OsiriX©) to 5 min (BrainLab© and Medis©) per silicone implant. MRI-based volumetry is a powerful tool to calculate both native breast and silicone implant volume in situ. All software solutions performed well and the measurements were close to the actual implant sizes. The use of MRI breast volumetry may be helpful in: (1) planning reconstructive and aesthetic surgery of asymmetric breasts, (2) calculating implant size in patients with missing documentation of a previously implanted device and (3) assessing post-operative results objectively.

Hot Clones, Maintaining a Link Between Software Clones Across Repositories

Code duplication is common in current programming-practice: programmers search for snippets of code, incorporate them into their projects and then modify them to their needs. In today's practice, no automated scheme is in place to inform both parties of any distant changes of the code. As code snippets continues to evolve both on the side of the user and on the side of the author, both may wish to benefit from remote bug fixes or refinements --- authors may be interested in the actual usage of their code snippets, and researchers could gather information on clone usage. We propose maintaining a link between software clones across repositories and outline how the links can be created and maintained.

Lessons in Software Evolution Learned by Listening to Smalltalk

The biggest challenge facing software developers today is how to gracefully evolve complex software systems in the face of changing requirements. We clearly need software systems to be more dynamic, compositional and model-centric, but instead we continue to build systems that are static, baroque and inflexible. How can we better build change-enabled systems in the future? To answer this question, we propose to look back to one of the most successful systems to support change, namely Smalltalk. We briefly introduce Smalltalk with a few simple examples, and draw some lessons for software evolution. Smalltalk's simplicity, its reflective design, and its highly dynamic nature all go a long way towards enabling change in Smalltalk applications. We then illustrate how these lessons work in practice by reviewing a number of research projects that support software evolution by exploiting Smalltalk's design. We conclude by summarizing open issues and challenges for change-enabled systems of the future.

Assimilation of Compliance Software in Highly Regulated Industries: An Empirical Multitheoretical Investigation

In this paper we follow a theory-based approach to study the assimilation of compliance software in highly regulated multinational enterprises. These relatively new software products support the automation of controls which are associated with mandatory compliance requirements. We use institutional and success factor theories to explain the assimilation of compliance software. A framework for analyzing the assimilation of Access Control Systems (ACS), a special type of compliance software, is developed and used to reflect the experiences obtained in four in-depth case studies. One result is that coercive, mimetic, and normative pressures significantly effect ACS assimilation. On the other hand, quality aspects have only a moderate impact at the beginning of the assimilation process, in later phases the impact may increase if performance and improvement objectives become more relevant. In addition, it turns out that position of the enterprises and compatibility heavily influence the assimilation process.

Enterprise software adoption and perceived business performance — an empirical investigation in Germany and the U.S.

This work contributes to the ongoing debate on the productivity paradox by considering CIOs’ perceptions of IT business value. Applying regression analysis to data from an international survey, we study how the adoption of certain types of enterprise software affects the CIOs’ perception of the impact of IT on the firm’s business activities and vice versa. Other potentially important factors such as country, sector and size of the firms are also taken into account. Our results indicate a more significant support for the impact of perceived IT benefits on adoption of enterprise software than vice versa. CIOs based in the US perceive IT benefits more strongly than their German counterparts. Furthermore, certain types of enterprise software seem to be more prevalent in the US.

The Software Prototype as Digital Boundary Object – A Revelatory Longitudinal Innovation Case

With the availability of lower cost but highly skilled software development labor from offshore regions, entrepreneurs from developed countries who do not have software development experience can utilize this workforce to develop innovative software products. In order to succeed in offshored innovation projects, the often extreme knowledge boundaries between the onsite entrepreneur and the offshore software development team have to be overcome. Prior research has proposed that boundary objects are critical for bridging such boundaries – if they are appropriately used. Our longitudinal, revelatory case study of a software innovation project is one of the first to explore the role of the software prototype as a digital boundary object. Our study empirically unpacks five use practices that transform the software prototype into a boundary object such that knowledge boundaries are bridged. Our findings provide new theoretical insights for literature on software innovation and boundary objects, and have implications for practice.

Highlights in Analytical Chemistry in Switzerland: OMA & OPA - A Software Tool for Mass Spectrometric Sequencing of Nucleic Acids

Oligonucleotides comprising unnatural building blocks, which interfere with the translation machinery, have gained increased attention for the treatment of gene-related diseases (e.g. antisense, RNAi). Due to structural modifications, synthetic oligonucleotides exhibit increased biostability and bioavailability upon administration. Consequently, classical enzyme-based sequencing methods are not applicable to their sequence elucidation and verification. Tandem mass spectrometry is the method of choice for performing such tasks, since gas-phase dissociation is not restricted to natural nucleic acids. However, tandem mass spectrometric analysis can generate product ion spectra of tremendous complexity, as the number of possible fragments grows rapidly with increasing sequence length. The fact that structural modifications affect the dissociation pathways greatly increases the variety of analytically valuable fragment ions. The gas-phase dissociation of oligonucleotides is characterized by the cleavage of one of the four bonds along the phosphodiester chain, by the accompanying loss of nucleases, and by the generation of internal fragments due to secondary backbone cleavage. For example, an 18-mer oligonucleotide yields a total number of 272’920 theoretical fragment ions. In contrast to the processing of peptide product ion spectra, which nowadays is highly automated, there is a lack of tools assisting the interpretation of oligonucleotide data. The existing web-based and stand-alone software applications are primarily designed for the sequence analysis of natural nucleic acids, but do not account for chemical modifications and adducts. Consequently, we developed a software to support the interpretation of mass spectrometric data of natural and modified nucleic acids and their adducts with chemotherapeutic agents.

How Do Software Architects Specify and Validate Quality Requirements?

Software architecture is the result of a design effort aimed at ensuring a certain set of quality attributes. As we show, quality requirements are commonly specified in practice but are rarely validated using automated techniques. In this paper we analyze and classify commonly specified quality requirements after interviewing professionals and running a survey. We report on tools used to validate those requirements and comment on the obstacles encountered by practitioners when performing such activity (e.g., insufficient tool-support; poor understanding of users needs). Finally we discuss opportunities for increasing the adoption of automated tools based on the information we collected during our study (e.g., using a business-readable notation for expressing quality requirements; increasing awareness by monitoring non-functional aspects of a system).

Quality in emergency departments: a study on 3,285,440 admissions

INTRODUCTION: A multi-centre study has been conducted, during 2005, by means of a questionnaire posted on the Italian Society of Emergency Medicine (SIMEU) web page. Our intention was to carry out an organisational and functional analysis of Italian Emergency Departments (ED) in order to pick out some macro-indicators of the activities performed. Participation was good, in that 69 ED (3,285,440 admissions to emergency services) responded to the questionnaire. METHODS: The study was based on 18 questions: 3 regarding the personnel of the ED, 2 regarding organisational and functional aspects, 5 on the activity of the ED, 7 on triage and 1 on the assessment of the quality perceived by the users of the ED. RESULTS AND CONCLUSION: The replies revealed that 91.30% of the ED were equipped with data-processing software, which, in 96.83% of cases, tracked the entire itinerary of the patient. About 48,000 patients/year used the ED: 76.72% were discharged and 18.31% were hospitalised. Observation Units were active in 81.16% of the ED examined. Triage programmes were in place in 92.75% of ED: in 75.81% of these, triage was performed throughout the entire itinerary of the patient; in 16.13% it was performed only symptom-based, and in 8.06% only on-call. Of the patients arriving at the ED, 24.19% were assigned a non-urgent triage code, 60.01% a urgent code, 14.30% a emergent code and 1.49% a life-threatening code. Waiting times were: 52.39 min for non-urgent patients, 40.26 min for urgent, 12.08 for emergent, and 1.19 for life-threatening patients.