366,180 research outputs found

    Development of a Measure to Assess the Complexity of Information Systems Development Projects

    Get PDF
    Information systems development (ISD) projects are becoming increasingly complex. ISD project complexity makes it difficult for project managers to deliver effective systems within time and budget constraints. As a result, the success of ISD projects is increasingly dependent on an organizationiĢs ability to effectively assess and manage complexity. The purpose of this paper is to develop a measure for assessing ISD project complexity. A two-dimensional conceptual framework is proposed to define four distinct types of software project complexity: structural organizational complexity, structural IT complexity, dynamic organizational complexity, and dynamic IT complexity. Based on field interviews, focus group discussions, and a large-scale survey of ISD project managers, a measure of ISD project complexity with 17 indicators was developed. The results of an exploratory data analysis provide strong evidence that the final measure has satisfactory measurement properties. The contributions of this research to both theory development and practice are discussed

    Measuring the software process and product: Lessons learned in the SEL

    Get PDF
    The software development process and product can and should be measured. The software measurement process at the Software Engineering Laboratory (SEL) has taught a major lesson: develop a goal-driven paradigm (also characterized as a goal/question/metric paradigm) for data collection. Project analysis under this paradigm leads to a design for evaluating and improving the methodology of software development and maintenance

    Quality factors and coding standards - a comparison between open source forges

    Get PDF
    Enforcing adherence to standards in software development in order to produce high quality software artefacts has long been recognised as best practice in traditional software engineering. In a distributed heterogeneous development environment such those found within the Open Source paradigm, coding standards are informally shared and adhered to by communities of loosely coupled developers. Following these standards could potentially lead to higher quality software. This paper reports on the empirical analysis of two major forges where OSS projects are hosted. The first one, the KDE forge, provides a set of guidelines and coding standards in the form of a coding style that developers may conform to when producing the code source artefacts. The second studied forge, SourceForge, imposes no formal coding standards on developers. A sample of projects from these two forges has been analysed to detect whether the SourceForge sample, where no coding standards are reinforced, has a lower quality than the sample from KDE. Results from this analysis form a complex picture; visually, all the selected metrics show a clear divide between the two forges, but from the statistical standpoint, clear distinctions cannot be drawn amongst these quality related measures in the two forge samples

    Using a Combination of Measurement Tools to Extract Metrics from Open Source Projects

    Get PDF
    Software measurement can play a major role in ensuring the quality and reliability of software products. The measurement activities require appropriate tools to collect relevant metric data. Currently, there are several such tools available for software measurement. The main objective of this paper is to provide some guidelines in using a combination of multiple measurement tools especially for products built using object-oriented techniques and languages. In this paper, we highlight three tools for collecting metric data, in our case from several Java-based open source projects. Our research is currently based on the work of Card and Glass, who argue that design complexity measures (data complexity and structural complexity) are indicators/predictors of procedural/cyclomatic complexity (decision counts) and errors (discovered from system tests). Their work was centered on structured design and our work is with object-oriented designs and the metrics we use parallel those of Card and Glass, being, Henry and Kafura's Information Flow Metrics, McCabe's Cyclomatic Complexity, and Chidamber and Kemerer Object-oriented Metrics

    Real world evaluation of aspect-oriented software development : a thesis submitted in partial fulfilment of the requirements for the degree of Master of Science in Computer Science at Massey University, Palmerston North, New Zealand

    Get PDF
    Software development has improved over the past decade with the rise in the popularity of the Object-Oriented (OO) development approach. However, software projects continue to grow in complexity and continue to have alarmingly low rates of success. Aspect-Oriented Programming (AOP) is touted to be one solution to this software development problem. It shows promise of reducing programming complexity, making software more flexible and more amenable to change. The central concept introduced by AOP is the aspect. An aspect is used to modularise crosscutting concerns in a similar fashion to the way classes modularise business concerns. A crosscutting concern cannot be modularised in approaches such as OO because the code to realise the concern must be spread throughout the module (e.g. a tracing concent is implemented by adding code to every method in a system). AOP also introduces join points, pointcuts, and advice which are used with aspects to capture crosscutting concerns so they can be localised in a modular unit. OO took approximately 20 years to become a mainstream development approach. AOP was only invented in 1997. This project considers whether AOP is ready for commercial adoption. This requires analysis of the AOP implementations available, tool support, design processes, testing tools, standards, and support infrastructure. Only when AOP is evaluated across all these criteria can it be established whether it is ready to be used in commercial projects. Moreover, if companies are to invest time and money into adopting AOP, they must be aware of the benefits and risks associated with its adoption. This project attempts to quantify the potential benefits in adopting AOP, as well as identifying areas of risk. SolNet Solutions Ltd, an Information Technology (IT) company in Wellington, New Zealand, is used in this study as a target environment for integration of aspects into a commercial development process. SolNet is in the business of delivering large scale enterprise Java applications. To assist in this process they have developed a Common Services Architecture (CSA) containing components that can be reused to reduce risk and cost to clients. However, the CSA is complicated and SolNet have identified aspects as a potential solution to decrease the complexity. Aspects were found to bring substantial improvement to the Service Layer of SolNet. applications, including substantial reductions in complexity and size. This reduces the cost and time of development, as well as the risk associated with the projects. Moreover, the CSA was used in a more consistent fashion making the system easier to understand and maintain, and several crosscutting concerns were modularised as part of a reusable aspect library which could eventually form part of their CSA. It was found that AOP is approaching commercial readiness. However, more work is needed on defining standards for aspect languages and modelling of design elements. The current solutions in this area are commercially viable, but would greatly benefit from a standardised approach. Aspect systems can be difficult to test and the effect of the weaving process on Java serialisation requires further investigation

    A Management Maturity Model (MMM) for project-based organisational performance assessment

    Get PDF
    Common sense suggests that organisations are more likely to deliver successful projects if they have systems in place that reflect a mature project environment based on a culture of continuous improvement. This paper develops and discusses a Management Maturity Model (MMM) to assess the maturity of project management organisations through a customisable, systematic, strategic and practical methodology inspired from the seminal work of Darwin, Deming, Drucker and Daniel. The model presented is relevant to organisations, such as construction and engineering companies, that prefer to use the Project Management Body of Knowledge (PMBOKā„¢ Guide) published by the Project Management Institute (PMI), but without the disadvantages of excessive time and cost commitments and a ā€˜one size fits allā€™ approach linked to rigid increments of maturity. It offers a game-changing advance in the application of project-based organisational performance assessment compared to existing market solutions that are unnecessarily complex. The feasibility of MMM is field-tested using a medium-sized data centre infrastructure firm in Tehran

    Global Innovations in Measurement and Evaluation

    Get PDF
    We researched the latest developments in theory and practice in measurement and evaluation. And we found that new thinking, techniques, and technology are influencing and improving practice. This report highlights 8 developments that we think have the greatest potential to improve evaluation and programme design, and the careful collection and use of data. In it, we seek to inform and inspireā€”to celebrate what is possible, and encourage wider application of these ideas

    Assessing architectural evolution: A case study

    Get PDF
    This is the post-print version of the Article. The official published can be accessed from the link below - Copyright @ 2011 SpringerThis paper proposes to use a historical perspective on generic laws, principles, and guidelines, like Lehmanā€™s software evolution laws and Martinā€™s design principles, in order to achieve a multi-faceted process and structural assessment of a systemā€™s architectural evolution. We present a simple structural model with associated historical metrics and visualizations that could form part of an architectā€™s dashboard. We perform such an assessment for the Eclipse SDK, as a case study of a large, complex, and long-lived system for which sustained effective architectural evolution is paramount. The twofold aim of checking generic principles on a well-know system is, on the one hand, to see whether there are certain lessons that could be learned for best practice of architectural evolution, and on the other hand to get more insights about the applicability of such principles. We find that while the Eclipse SDK does follow several of the laws and principles, there are some deviations, and we discuss areas of architectural improvement and limitations of the assessment approach
    • ā€¦
    corecore