6 research outputs found

    Service Oriented Architecture for a Software Traceability System

    Get PDF
    In order to improve software development and keep up with the fast pace of business, standards and methodologies for determining and endorsing effective software development processes have been introduced and put into effect on software projects. Accordingly, many tools that interpret these standards and methodologies have been developed and employed. Although there is active development and research in the area of requirements traceability, the desired level of acceptance has not been achieved, and the most widely reported reason for this in the industry, is that of: ‘poor and immature integration technology’. This has resulted in existing tools often suffering problems due to poor integration and inflexibility with other technologies, which undermines the usefulness, usability and longevity of the Requirements Traceability provided by these tools. The panacea, at least in the confines of this project, is to employ a new technology: ’Web Services’ as the underlying framework, to address these problems. The motivation for employing the web services architecture for this project is to allow personalized customization of a traceability solution, hence providing a ubiquitous software development process that incorporates standards as well as software engineering industry best practices

    Uma abordagem para representação e rastreio de artefatos.

    Get PDF
    Rastreabilidade de Requisitos refere-se ao processo de rastreio de requisitos ao longo de todo o ciclo de vida de um software. Visto que um grande conjunto de informações é usado e produzido e tais devem ser rastreadas, ela é essencial ao processo de desenvolvimento de software. Não obstante, uma vez que a complexidade dos sistemas desenvolvidos cresce, a miríade de artefatos relacionados também cresce. Sendo assim, engenheiros de requisitos são encarregados de rastrear requisitos em diferentes níveis de abstrações. Neste contexto, vale ressaltar que não há um consenso acerca do processo de rastreabilidade e, como consequência, práticas de rastreabilidade de requisitos não podem ser unificadas em diferentes ambientes organizacionais. Propor uma abstração comum para rastreabilidade de requisitos e também identificar aspectos chave do processo de rastreabilidade são reconhecidos como notáveis tópicos de pesquisa dentre os grandes desafios da rastreabilidade de requisitos. Sendo assim, no presente trabalho, propomos uma Linguagem de Representação de Rastreabilidade (TRL), que provê abstrações para a rastreabilidade de requisitos. Tal linguagem é então explorada por um processo de rastreabilidade, centrado na mesma. Desta forma, ao discutirmos detalhadamente as fases do processo proposto, atores, responsabilidades, entradas e saídas esperadas bem como contratos e interfaces que regem tal processo, nós investigamos aspectos comuns do processo de rastreabilidade. A avaliação do presente trabalho considera que: (i) a representação proposta foi avaliada considerando critérios de legibilidade e redigibilidade, ou seja, quão compreensível ela é; e (ii) o processo proposto foi avaliado considerando sua performance e eficiência, isto é, quão bem o processo apoia atividades beneficiadas pela rastreabilidade de requisitos. Como resultados, observamos que a linguagem e suas construções foram avaliadas como de fácil leitura e escrita e que a linguagem é uma abordagem viável para abstrair rastreabilidade de requisitos. Além disso, observamos que o processo proposto possui melhor performance e eficiência quando comparado à um processo ad hoc. Dados os resultados observados, a abordagem proposta (linguagem e processo) fornece abstrações para o processo de rastreabilidade de requisitos bem como fomentar a discussão acerca dos principais aspectos do processo de rastreabilidade, desta forma, promovendo a rastreabilidade de requisitos portável.Requirements Traceability (RT) refers to the process of tracing requirements through the software development life-cycle. It is essential for the software development process because a lot of information is used and produced and it should be kept related or traceable. Nevertheless , as the complexity of a system increases, themyriad of related artifacts also increases. Therefore, one is encumbered of tracing requirements through different abstraction levels. Moreover, there is not a consensus about the traceability process and, as a consequence, requirements traceability practices cannot be unified across different organizational settings. Proposing a common abstraction to requirements traceability and also identifying common aspects to the requirements traceability process have been recognized as remarkable research topics of the grand challenges of requirements traceability. Therefore, is this work, we propose a Traceability Representation Language (TRL), which provides abstractions to requirements traceability. Such representation is then exploited by a requirements traceability process centered on it. Thus, by thoroughly discussing process’ phases, activities, actors, responsibilities, and input/output artifacts as well as traceability contracts, which govern process’ phases and how they intercommunicate, we investigate common aspects of requirements traceability. The evaluation of the present work was twofold: (i) the proposed language was evaluated considering its readability and writability, i.e. how comprehensible it is; and (ii) the proposed process was evaluated regarding its performance and effectiveness, i.e. how well it supports requirements traceability tasks. As a result, we observed that the language’s constructions were evaluated as easily read/written and that it is a feasible approach to provide an abstraction to requirements traceability. Moreover,we observed that the proposed process improves the performance and efficiency of the requirements traceability process, while maintaining the same accuracy of other approaches. Therefore, the proposed approach (language and process) is feasible to address abstractions to requirements traceability as well as foster the discussion of major aspects of the requirements traceability process, thus portable traceability can be addressed, i. e. how requirements traceability techniques can be used across different projects or even organizations

    Deducing Requirements From Agile Software Processes

    Get PDF
    In classical engineering practice, the elicitation of requirements is an important early project phase. Requirements help to define the project goals and scope, they serve as a basis for cost estimation, and in validated projects they are the cornerstone of the traceability matrix. However, requirements elicitation is difficult because of the abstract nature of the process and because there is uncertainty at the start of a project about what can be done. In recent software development practice, waterfall methods have fallen into disfavor, and agile methods are preferred. Agile methods avoid formal requirements specification, and instead use techniques such as scrums and user stories to specify development phases that are performed iteratively. In agile methods, requirements remain implicit and undocumented. While agile may avoid the difficulties of formal elicitation of requirements, it may in the process bypass the activity of analysis of user needs, and the generation of a baseline against which the implemented system can be validated. In this thesis we show that requirements can be deduced from the user stories and process maps that result from agile methodologies. A modified failure mode effects analysis approach is used to identify risks, failure modes, and countermeasures, and to evaluate risks and countermeasures by computing severity and likelihood of the risks, and the benefits of the countermeasures. The deduction of requirements from agile artifacts encourages an agile team to think through its preferences and proposed implementations, and objectively rate them. It captures the rationale for the user stories and process maps, and provides traceability from business goals to the functional requirements
    corecore