81,951 research outputs found

    Is it Possible to Disregard Obsolete Requirements? A Family of Experiments in Software Effort Estimation

    Get PDF
    Context: Expert judgement is a common method for software effort estimations in practice today. Estimators are often shown extra obsolete requirements together with the real ones to be implemented. Only one previous study has been conducted on if such practices bias the estimations. Objective: We conducted six experiments with both students and practitioners to study, and quantify, the effects of obsolete requirements on software estimation. Method By conducting a family of six experiments using both students and practitioners as research subjects (N = 461), and by using a Bayesian Data Analysis approach, we investigated different aspects of this effect. We also argue for, and show an example of, how we by using a Bayesian approach can be more confident in our results and enable further studies with small sample sizes. Results: We found that the presence of obsolete requirements triggered an overestimation in effort across all experiments. The effect, however, was smaller in a field setting compared to using students as subjects. Still, the over-estimations triggered by the obsolete requirements were systematically around twice the percentage of the included obsolete ones, but with a large 95% credible interval. Conclusions: The results have implications for both research and practice in that the found systematic error should be accounted for in both studies on software estimation and, maybe more importantly, in estimation practices to avoid over-estimation due to this systematic error. We partly explain this error to be stemming from the cognitive bias of anchoring-and-adjustment, i.e. the obsolete requirements anchored a much larger software. However, further studies are needed in order to accurately predict this effect

    Keeping Pace with Changes - Towards Supporting Continuous Improvements and Extensive Updates in Manufacturing Automation Software

    Get PDF
    Every long-term used software system ages. Even though intangible goods like software do not degenerate in the proper sense, each software system degenerates in relation to the everlasting changes of requirements, usage scenarios and environmental conditions. Accordingly, operational software is commonly situated in a continuous evolution process in which manually conducted modifications and adaptations try to preserve or reinforce its quality. Unfortunately, such an unmanaged evolution inevitably leads to a discrepancy between the obsolete originally documented requirements and the updated software itself. For this reason, our contribution presents a coherent vision of an anti-aging cycle that preserves (non-)functional requirements as explicit runtime artefacts. The fulfilment of these requirements is validated based on conditionally triggered online test cases. In order to achieve an enhanced semantic test coverage, these test cases are adapted by monitoring, analysing and learning typical system behaviours. To explain our vision in more detail and demonstrate the benefit of a managed software evolution, our anti-aging cycle is exemplarily applied on the domain of manufacturing automation

    Methods of representing the structure of complex industrial products on computer files, to facilitate planning, costing and related management tasks : a thesis presented in fulfilment of the requirements for the degree of Master of Technology in Manufacturing and Industrial Technology at Massey University

    Get PDF
    When the original concepts for the computerisation of product structures were developed in the late 1960's the available computer power was very limited. A modularisation technique was developed to address the situation in which a number of similar products were being manufactured. This technique tried to rationalise these products into family groups. Each member of the family differed from the others due to the possession of different features or options. However there was also a high degree of commonality to give the product membership of the family. Modularisation involved the identification of the options and features providing the variability. Those parts remaining tended to be common to all members of the family and became known as the common parts. Separate Bills of Material (BOMs) were set up for each of the identified options or features. Another BOM was set up for the common parts. The simple combination of the required options and/or features BOMs with the common parts BOM specified a product. Computer storage requirements and redundancy were reduced to a minimum. The Materials Requirements Planning (MRP) system could manipulate these option and feature BOMs to over plan product variability without over planning the parts common to all members. The modularisation philosophy had wide acceptance and is the foundation of MRP training. Modularisation, developed for MRP, is generally parts orientated. An unfortunate side effect tends to be the loss of product structure information. Most commercial software would list 6 resistors, Part No. 123, in the common parts BOM without concern as to where the resistors are fitted. This loss of product structure information can hide the fact that two products using these 6 resistors 'in common' are in fact different as they do not use the resistors in the same 6 places. Additional information must be consulted to enable the correct assembly of the 'common' portion of these products. The electronics industry is especially affected by this situation. This industry has changed considerably since the late 1960's. Product variability can be very high. Changes and enhancements are a constant factor in products having a relatively short life span. The modularisation technique does not have a good mechanism for the situation where an option itself has options or features. This situation can exist down a number of layers of the family tree structure of an electronics product. Maintenance of these BOMs is difficult. Where there are options within options the designers and production staff need to know the inter-relationship of parts between options to ensure accuracy, compatibility and plan assembly functions. The advent of computerised spreadsheets has made the maintenance of this type of product structure information easier. This matrix is another separate document which must be maintained and cross checked. It will inevitably differ from the BOMs periodically. This thesis develops a product structure Relational BOM based on the matrix for the family of products. The processing power of the 1990's computer is fully utilised to derive the common parts for any or all of the selected products of the family. All product structure information is retained and the inter-relationship of parts is highly visible. The physical maintenance of the BOMs is simple. The BOM serves all purposes without the need for supplementary information. It is fully integrated into the Sales Order Entry , MRP, Costing, Engineering Design and Computer Aided Manufacturing (CAM) systems. This technique has been proven by being the only system used in one Electronics Design and Manufacturing organisation for over 1 year without any major problems. As described in Section 1.6 user satisfaction has been high. The response of the users to the suggestion 'lets buy an "off the shelf" package' is very negative, as it would not incorporate this BOM system. Users have expressed the opinion that EXICOM could not continue, with present staffing levels, using the traditional BOM structure

    Invest to Save: Report and Recommendations of the NSF-DELOS Working Group on Digital Archiving and Preservation

    Get PDF
    Digital archiving and preservation are important areas for research and development, but there is no agreed upon set of priorities or coherent plan for research in this area. Research projects in this area tend to be small and driven by particular institutional problems or concerns. As a consequence, proposed solutions from experimental projects and prototypes tend not to scale to millions of digital objects, nor do the results from disparate projects readily build on each other. It is also unclear whether it is worthwhile to seek general solutions or whether different strategies are needed for different types of digital objects and collections. The lack of coordination in both research and development means that there are some areas where researchers are reinventing the wheel while other areas are neglected. Digital archiving and preservation is an area that will benefit from an exercise in analysis, priority setting, and planning for future research. The WG aims to survey current research activities, identify gaps, and develop a white paper proposing future research directions in the area of digital preservation. Some of the potential areas for research include repository architectures and inter-operability among digital archives; automated tools for capture, ingest, and normalization of digital objects; and harmonization of preservation formats and metadata. There can also be opportunities for development of commercial products in the areas of mass storage systems, repositories and repository management systems, and data management software and tools.

    Managing Process Variants in the Process Life Cycle

    Get PDF
    When designing process-aware information systems, often variants of the same process have to be specified. Each variant then constitutes an adjustment of a particular process to specific requirements building the process context. Current Business Process Management (BPM) tools do not adequately support the management of process variants. Usually, the variants have to be kept in separate process models. This leads to huge modeling and maintenance efforts. In particular, more fundamental process changes (e.g., changes of legal regulations) often require the adjustment of all process variants derived from the same process; i.e., the variants have to be adapted separately to meet the new requirements. This redundancy in modeling and adapting process variants is both time consuming and error-prone. This paper presents the Provop approach, which provides a more flexible solution for managing process variants in the process life cycle. In particular, process variants can be configured out of a basic process following an operational approach; i.e., a specific variant is derived from the basic process by applying a set of well-defined change operations to it. Provop provides full process life cycle support and allows for flexible process configuration resulting in a maintainable collection of process variants

    National Space Transportation System (NSTS) technology needs

    Get PDF
    The National Space Transportation System (NSTS) is one of the Nation's most valuable resources, providing manned transportation to and from space in support of payloads and scientific research. The NSTS program is currently faced with the problem of hardware obsolescence, which could result in unacceptable schedule and cost impacts to the flight program. Obsolescence problems occur because certain components are no longer being manufactured or repair turnaround time is excessive. In order to achieve a long-term, reliable transportation system that can support manned access to space through 2010 and beyond, NASA must develop a strategic plan for a phased implementation of enhancements which will satisfy this long-term goal. The NSTS program has initiated the Assured Shuttle Availability (ASA) project with the following objectives: eliminate hardware obsolescence in critical areas, increase reliability and safety of the vehicle, decrease operational costs and turnaround time, and improve operational capability. The strategy for ASA will be to first meet the mandatory needs - keep the Shuttle flying. Non-mandatory changes that will improve operational capability and enhance performance will then be considered if funding is adequate. Upgrade packages should be developed to install within designated inspection periods, grouped in a systematic approach to reduce cost and schedule impacts, and allow the capability to provide a Block 2 Shuttle (Phase 3)
    • 

    corecore