Final Software Research Articles

L'influence du processus sur la qualité du produit

This paper presents the results of an observational study carried out in an academic environment in order to determine the possible influence of the development process on the quality of software requirements realization. All six teams developed their own version of the system based on the common specification. Three teams used the structured process UPEDU derived of the RUP and three teams used an agile type process - XP. An experts' committee evaluated the realization quality of each requirement. On 109 realized requirements it seems that the quality of 46 of them can depend on the used process. Furthermore, it seems that the realization quality of 27 of these requirements is function of the design methods used within the framework of the process. The article supplies indications that can be useful in the evaluation of the development processes and their influence on the quality ofthe final software product.

Acceptability-oriented computing

We discuss a new approach to the construction of software systems. Instead of attempting to build a system that is as free of errors as possible, the designer instead identifies key properties that the execution must satisfy to be acceptable to its users. Together, these properties define the acceptability envelope of the system: the region that it must stay within to remain acceptable. The developer then augments the system with a layered set of components, each of which enforces one of the acceptability properties. The potential advantages of this approach include more flexible, resilient systems that recover from errors and behave acceptably across a wide range of operating environments, an appropriately prioritized investment of engineering resources, and the ability to productively incorporate unreliable components into the final software system.

Adaptable architecture generation for embedded systems

Architecture generation is the first step in the design of software systems. Many of the qualities that the final software system possesses are usually decided at the architecture development stage itself. Thus, if the final system should be usable, testable, secure, high performance, mobile and adaptable, then these qualities or non-functional requirements (NFRs) should be engineered into the architecture itself. In particular, recently adaptability is emerging as an important attribute required by almost all software systems. Briefly, adaptability is the ability of a software system to accommodate changes in its environment. Embedded systems are usually constrained both in hardware and software. Current adaptable architecture development methods for embedded systems are usually manual and ad hoc––there are almost no comprehensive systematic approaches to consider NFRs at the architecture development stage. While there are several examples of approaches to generate architectures based on functional requirements, we believe that there are very few techniques that consider NFRs such as adaptability during the process of architecture generation. In this paper we present an automated design method that helps develop adaptable architectures for embedded systems by developing a tool called Software Architecture Adaptability Assistant (SA3). SA3 helps the developer during the process of software architecture development by selecting the architectural constituents such as components, connections, patterns, constraints, styles, and rationales that best fit the adaptability requirements for the architecture. The developer can then complete the architecture from the constituents chosen by the tool. SA3 uses the knowledge base properties of the NFR Framework in order to help automatically generate the architectural constituents. The NFR Framework provides a systematic method to consider NFRs, in particular their synergies and conflicts. We validated the architectures generated by SA3 in a type of embedded system called the vocabulary evolution system (VES) by implementing the codes from the generated architectures in the VES and confirming that the resulting system satisfied the requirements for adaptability. A VES responds to external commands through an interface such as ethernet and the vocabulary of these commands changes with time. The validation process also led to the discovery of some of the shortcomings of our automated design method.

Building knowledge discovery-driven models for decision support in project management

Accurate estimations of software size in the early stages of a software project are critical in software project management because they lead to a good planning and reduce project costs. In this work, the relation between early software size measures as the function points and measures of the final product as the lines of code has been studied. A process to refine association rules, based on the generation of unexpected patterns, is proposed. The goal is to generate strong association rules between attributes that can be obtained early in the project and the final software size.

Requirements Engineering-Based Conceptual Modelling

The software production process involves a set of phases where a clear relationship and smooth transitions between them should be introduced. In this paper, a requirements engineering-based conceptual modelling approach is introduced as a way to improve the quality of the software production process. The aim of this approach is to provide a set of techniques and methods to capture software requirements and to provide a way to move from requirements to a conceptual schema in a traceable way. The approach combines a framework for requirements engineering (TRADE) and a graphical object-oriented method for conceptual modelling and code generation (OO-Method). The intended improvement of the software production process is accomplished by providing a precise methodological guidance to go from the user requirements (represented through the use of the appropriate TRADE techniques) to the conceptual schema that properly represents them (according to the conceptual constructs provided by the OO-Method). Additionally, as the OO-Method provides full model-based code generation features, this combination minimises the time dedicated to obtaining the final software product.

The OO-method approach for information systems modeling: from object-oriented conceptual modeling to automated programming

Current and future (conventional) notations used in Conceptual Modeling Techniques should have a precise (formal) semantics to provide a well-defined software development process, in order to go from specification to implementation in an automated way. To achieve this objective, the OO-method approach to Information Systems Modeling presented in this paper attempts to overcome the conventional (informal)/formal dichotomy by selecting the best ideas from both approaches. The OO-method makes a clear distinction between the problem space (centered on what the system is) and the solution space (centered on how it is implemented as a software product). It provides a precise, conventional graphical notation to obtain a system description at the problem space level, however this notation is strictly based on a formal OO specification language that determines the conceptual modeling constructs needed to obtain the system specification. An abstract execution model determines how to obtain the software representations corresponding to these conceptual modeling constructs. In this way, the final software product can be obtained in an automated way.

Creating a high school physics video based laboratory

We integrated our physics video-based laboratory with a hypertext system that contains the curricula of a high school physics course. We aim to create a pedagogic tool that includes the theoretical and experimental aspects of a physics course. Here we present the development methodology, the final software structure, the experiments we analyzed, and the results we obtained.

Building E-commerce applications from object-oriented conceptual models

This paper introduces an extension to UML that takes care of web page navigation using the OO-Method, dynamic prototyping, and a new way of specifying the navigation design. Furthermore, a software production process for e-commerce applications design is described. This process is driven by an Object-Oriented Web-Solutions Modeling approach (OOWS), which provides mechanisms to deal with the development of web-based applications. In the proposed process, a system is completely specified using object-oriented conceptual modeling techniques to capture properly the specific functionality of an e-commerce application. We place special emphasis on a navigational model that provides abstraction primitives to capture and represent navigational semantics. With such an extended conceptual model, system functionality and navigational features are described within a unified framework. Once the system specification is completed (problem space level), a strategy to obtain the software components that will constitute the final software product (solution space level) is defined. We briefly discuss how to map these abstraction primitives to e-commerce applications in order to be able to go from the problem space to the solution space in a structured, automated way.

Flexible processing framework for online event data and software triggering

The BABAR experiment is the particle detector at the new PEP-II factory facility at the Stanford Linear Accelerator Center. The experiment's goal is the detailed study of the fundamental phenomenon of charge-parity symmetry breaking in B meson decays. Within the detector's online system, the Online Event Processing subsystem (OEP) provides for near real-time processing of data delivered from the data acquisition system's event builder. It supports four principal tasks: the final software trigger, rapid-feedback fast data quality monitoring, event displays, and the final steps in online calibrations. In order to accommodate the expected 2000 Hz event rate, the OEP subsystem runs on computing farm, receiving events on each node into a shared memory buffer system and coordinating processes performing analysis on this data. Analysis tasks are assigned administrative characteristics providing for protection of data integrity and ensuring that indispensable tasks such as triggering are always performed, while others are performed as resources are available. Data access in OEP uses BABAR's standard offline reconstruction framework. Thus, notably, the Level 3 trigger software could be developed in advance in the full offline simulation environment and yet be suitable for near-real-time online running with minimal changes.

Nine color eleven parameter immunophenotyping using three laser flow cytometry.

This study describes a three laser flow cytometer, reagents, and software used to simultaneously evaluate nine distinct fluorescent parameters on one cell sample. We compare the quality of data obtained with (1) full software compensation and (2) the use of partial spectral compensation of selected pairs of parameters in analog hardware, in combination with final software compensation. An application characterizing low frequency murine B cell subpopulations is given. The fluorochromes used are: fluorescein (FITC), phycoerythrin (PE), Cy5PE and Cy7PE, excited at 488 nm by an argon laser; Texas Red (TR), allophycocyanin (APC), and Cy7APC excited at 595 nm by a pumped dye laser; and cascade blue (CB) and cascade yellow (CY) excited at 407 nm by a violet-enhanced krypton laser. Custom additions to commercial electronics and an extended optical bench allow the measurement of these nine parameters plus forward and side scatter light signals. We find the use of partial analog compensation reduces the variation in the background staining levels introduced by the compensation process. Novel B cell populations with frequencies below 1% are characterized. Nine color flow cytometry is capable of providing measurements with high information content. The choice of reagent-dye combinations and the ability to compensate in multi-parameter measurement space are crucial to obtaining satisfactory results.

Nine color eleven parameter immunophenotyping using three laser flow cytometry

This study describes a three laser flow cytometer, reagents, and software used to simultaneously evaluate nine distinct fluorescent parameters on one cell sample. We compare the quality of data obtained with (1) full software compensation and (2) the use of partial spectral compensation of selected pairs of parameters in analog hardware, in combination with final software compensation. An application characterizing low frequency murine B cell subpopulations is given.The fluorochromes used are: fluorescein (FITC), phycoerythrin (PE), Cy5PE and Cy7PE, excited at 488 nm by an argon laser; Texas Red (TR), allophycocyanin (APC), and Cy7APC excited at 595 nm by a pumped dye laser; and cascade blue (CB) and cascade yellow (CY) excited at 407 nm by a violet-enhanced krypton laser. Custom additions to commercial electronics and an extended optical bench allow the measurement of these nine parameters plus forward and side scatter light signals.We find the use of partial analog compensation reduces the variation in the background staining levels introduced by the compensation process. Novel B cell populations with frequencies below 1% are characterized.Nine color flow cytometry is capable of providing measurements with high information content. The choice of reagent-dye combinations and the ability to compensate in multi-parameter measurement space are crucial to obtaining satisfactory results.

System for Bridge Management in a Rural Environment

A system is presented for the cityor county-level management of bridges located in Wyoming. Although the research work was directly focused on the state of Wyoming, the consideration involved in the system development, the procedures involved, and the final software design are generally applicable to other states that have similar demographics and bridge inventories. Selected bridge management systems (BMS) are reviewed as appropriate, and characteristics of each, along with their advantages and disadvantages, are elaborated. Several of the favorable characteristics of these systems were modified and incorporated into the present system, called WYO_BMS. The objective of this paper is to provide the general background for the development of the WYO_BMS. Details specific to the Wyoming implementation are not provided here, but are available in the final report.

Metrics collection in code and unit test as part of continuous quality improvement

AbstractA policy of rigorous unit testing as a foundation for the integration of software systems has been found to be effective, resulting in rapid integration and good overall quality of the final software and systems. However, there is little detailed information on how effective individual components of the code and unit test phase of the software lifecycle are. IPL have conducted an exercise to gather and analyse detailed metrics for the module design and unit code and test phases. This will assist the improvement of estimation and planning, identify areas where quality can be improved and costs reduced, enhance project management with improvements in control over the development, and develop indicators that can be used to anticipate problem areas and facilitate risk management.

Factory Automation: Production Subsystem Management

Factory automation is a job that intends to map all the cooperative and competitive relationships that happen among the elements existing in a factory into the software domain. The goal of this paper is to show an important phase when a software system of this kind is to be built. This is the design phase. We have chosen an object oriented methodology. We think several concepts belonging to this methodology are applicable on the industrial environment to be controlled. We think it is very important to build a conceptual model of the system which will control the factory. The final software system will depend on the consistency of this model. The main feature of the model is to consider the factory as a set of different classes of components. The components belonging to each class have the same behavior.

Software quality metrics: considerations about requirements and requirement specifications

A general view of quality and reliability as the difference between what is expected and what is experienced is expanded on with respect to the requirement specification stages of software development. The dual nature of software requirements specifications, as solution to the problem of what the final software will be and do, and as a starting point for further system development, is formulated. This distinction is used to structure the types of metric that will be required. A distinction is drawn between those requirements that can be formalized, using for example a formal development method such as VDM, and those that cannot, either because they have inherently informal expectations or because they are not articulated. For the formalized requirements, metrics based on classical measurement theory are recommended. Where the requirements are informal, a comprehensive checklist procedure is suggested.

A meta-level software development model that supports V&V for AI software

V&V methods for AI software must adapt to the kinds of development cycles that are practical for complex AI applications that evolve over time; yet V&V requires that each project have a well-defined development process that supports V&V activities. In this paper we introduce a four-dimensional meta-level model about software development processes. This model allows a wide range of software development processes that can be tailored to the unique characteristics of different AI projects—while still providing ways to evaluate the development process and to include the controls needed for V&V. The four dimensions of our model are the definition, formalization, operationality, and performance of the software system. Standard software documentation as well as other software products such as prototypes and formal specifications occur as points in this four-dimensional space, and verification and validation can then be modeled as mappings between points in this space. As software developments proceeds through this four-dimensional space there should be enough intermediate software products acting as waypoints so the development process can be verified and the final software product can be validated in relation to its current requirements.

Designing a software reliability programme

AbstractDesigning reliable software is becoming an ever increasing problem because the high cost of software is largely due to reliability problems. The costs of finding and fixing the errors, better known as maintenance and testing costs, account for as much as 80 per cent of the total cost of the final software product. Software developers now have an even greater interest in preventing errors from making their way into the software and finding the errors that are present in the early stages of development. Precise software design, coding and testing play an important role. This paper presents a management plan for implementing a software reliability programme at a small software industry where no reliability programme yet exists and no reliability programme is yet established.

SELECTING SOFTWARE PART I: WHAT'S AVAILABLE… WHAT TO ASK ABOUT

As more and more library management software appears on the market, selecting the best computer programs to automate library functions has become increasingly difficult. Each type of program has its own advantages and disadvantages; some have a broad range of applications, but may be too complex or difficult for routine use. Others are designed to perform specific tasks, but cannot be readily modified to meet the needs of an individual department. Warranties, training requirements, and backup policies differ considerably, depending on which program you choose and which company manufactures it. Since library automation can be an expensive prospect, it is well worth the time and energy to develop a thorough acquaintance with what's available—and to know what questions to ask. Your final software decision will determine the productivity, efficiency, and cost‐effectiveness of your library automation project.

Structured planning–project views

The quality of software products may be improved by enhancing the performance of any of the varied activities associated with the production of the software. One such activity is ‘project planning’. Project planning may be a small part of the total project effort, but will have a large effect on all activities in the project and, therefore, a major impact on the final software quality. Thus the cost benefits that can be expected from effective project planning are substantial. This paper discusses ‘structured planning’ – the integration of many aspects of planning, such as work breakdown, scheduling, resource allocation and change/defect tracking, into a single project model, which could be the basis of a structured planning software tool.

Application of a Methodology for the Development and Validation of Reliable Process Control Software

This paper discusses the necessity of a good methodology for the development of reliable software, especialy with respect to the final software validation and testing activities. A formal specification development and validation methodology is proposed. This methodology has been applied to the development and validation of a pilot software, incorporating typical features of critical software for nuclear power plant safety protection. The main features of the approach indude the use of a formal specification language and the independent development of two sets of specifications. Analyses on the specifications consists of three-parts: validation against the functional requirements consistency and integrity of the specifications, and dual specification comparison based on a high-level symbolic execution technique. Dual design, implementation, and testing are performed. Automated tools to facilitate the validation and testing activities are developed to support the methodology. These includes the symbolic executor and test data generator/dual program monitor system. The experiences of applying the methodology to the pilot software are discussed, and the impact on the quality of the software is assessed.