Planificación de las pruebas del software

La complejidad actual en la construcción de los sistemas de software, ha impuesto la necesidad de mejorar los procesos de construcción con el menor costo y esfuerzo posible. Las pruebas del software, a diferencia de otras etapas del proceso de construcción, no tienen la misma visibilidad para el usuario, lo que determina que ante presiones de tiempo o costos, sea esta etapa la que se redefina según lo planeado, a pesar de que esta decisión atenta directamente sobre la calidad del software. Para asegurar la correcta construcción del software, en relación a las pruebas, se hace indispensable pensarlas integradas y lo más automatizadas posible. En el proyecto de investigación, se ha trabajado sobre la derivación semiautomática de Casos de Prueba a partir de escenarios futuros y en el presente trabajo se ha avanzado sobre la planificación de esos Casos de Prueba obtenidos, para asegurar que la funcionalidad propuesta en los escenarios contemple las dependencias de recursos y funcionales existentes entre las tareas. De esta manera se utiliza la integración de los escenarios para identificar las dependencias y ordenar la ejecución de los Casos de Prueba en las denominadas suites de prueba, que permiten analizar la funcionalidad parcial y total del futuro sistema de software.Eje: Ingeniería del Software.Red de Universidades con Carreras en Informátic

Planificación de las pruebas del software

La complejidad actual en la construcción de los sistemas de software, ha impuesto la necesidad de mejorar los procesos de construcción con el menor costo y esfuerzo posible. Las pruebas del software, a diferencia de otras etapas del proceso de construcción, no tienen la misma visibilidad para el usuario, lo que determina que ante presiones de tiempo o costos, sea esta etapa la que se redefina según lo planeado, a pesar de que esta decisión atenta directamente sobre la calidad del software. Para asegurar la correcta construcción del software, en relación a las pruebas, se hace indispensable pensarlas integradas y lo más automatizadas posible. En el proyecto de investigación, se ha trabajado sobre la derivación semiautomática de Casos de Prueba a partir de escenarios futuros y en el presente trabajo se ha avanzado sobre la planificación de esos Casos de Prueba obtenidos, para asegurar que la funcionalidad propuesta en los escenarios contemple las dependencias de recursos y funcionales existentes entre las tareas. De esta manera se utiliza la integración de los escenarios para identificar las dependencias y ordenar la ejecución de los Casos de Prueba en las denominadas suites de prueba, que permiten analizar la funcionalidad parcial y total del futuro sistema de software.Eje: Ingeniería del Software.Red de Universidades con Carreras en Informátic

Planificación de las pruebas del software

La complejidad actual en la construcción de los sistemas de software, ha impuesto la necesidad de mejorar los procesos de construcción con el menor costo y esfuerzo posible. Las pruebas del software, a diferencia de otras etapas del proceso de construcción, no tienen la misma visibilidad para el usuario, lo que determina que ante presiones de tiempo o costos, sea esta etapa la que se redefina según lo planeado, a pesar de que esta decisión atenta directamente sobre la calidad del software. Para asegurar la correcta construcción del software, en relación a las pruebas, se hace indispensable pensarlas integradas y lo más automatizadas posible. En el proyecto de investigación, se ha trabajado sobre la derivación semiautomática de Casos de Prueba a partir de escenarios futuros y en el presente trabajo se ha avanzado sobre la planificación de esos Casos de Prueba obtenidos, para asegurar que la funcionalidad propuesta en los escenarios contemple las dependencias de recursos y funcionales existentes entre las tareas. De esta manera se utiliza la integración de los escenarios para identificar las dependencias y ordenar la ejecución de los Casos de Prueba en las denominadas suites de prueba, que permiten analizar la funcionalidad parcial y total del futuro sistema de software.Eje: Ingeniería del Software.Red de Universidades con Carreras en Informátic

Derivación de casos de prueba a partir de escenarios

Como se describió en un artículo precedente [Kaplan 15], este proyecto tiene por objetivo concebir un mecanismo para generar tempranamente los casos de prueba partiendo del conocimiento obtenido en la etapa de Ingeniería de Requisitos (IR), particularmente del proceso de requisitos basado en escenarios [Leite 97] [Leite 04]. En dicha oportunidad se presentó la propuesta general del proyecto, mientras que en el presente artículo se profundiza la relación escenarios futuros – casos de prueba (EFCP) y se describe un mecanismo de derivación automática. En muchos casos, la etapa de prueba es la variable de ajuste cuando los tiempos y el presupuesto de un proyecto están en crisis. Lograr que las pruebas, total o parcialmente, se realicen después de cada modificación asegura la calidad de los requisitos del software. Esto fuerza la necesidad de una creación, actualización y ejecución de los CP automática, con el objetivo de probar el software tantas veces como sea necesario. Que además permitan la mínima distracción de las etapas en desarrollo y a un bajo costo es indispensable para que no se trasformen en un elemento de perturbación. Cabe destacar que, al ser una actividad transversal en el proceso de construcción del software, estos CP evolucionan durante el diseño ya que es cuando se conoce en qué componente de software se alojará cada requisito (software allocation). Este nuevo conocimiento permite generar CP de caja blanca con un alto nivel de detalle.Eje: Ingeniería de Software.Red de Universidades con Carreras en Informática (RedUNCI

Uma proposta para rastreabilidade no desenvolvimento de software

Orientador: Mario JinoTese (doutorado) - Universidade Estadual de Campinas, Faculdade de Engenharia Elétrica e de ComputaçãoResumo: Rastreabilidade tem sido um tópico de pesquisa no desenvolvimento de software por pelo menos 40 anos, sendo adicionada a muitos padrões, como o DOD-STD-2167A e o IEEE 830-1998. Este último, por exemplo, afirma que uma boa especificação de requisitos de software deve ser rastreável. A rastreabilidade fornece muitos benefícios para projetos de software, tais como: identificação das razões para decisões de design, prevenção de problemas de dependência, identificação de responsabilidades em um projeto, estimação de impacto e de custo de modificações, e medição do progresso de desenvolvimento. Sucintamente, a rastreabilidade permite a geração de um produto de melhor qualidade. Dois principais focos surgiram na literatura nos últimos anos: desenvolvimento baseado em modelo e geração automática de rastros. O primeiro trata da modelagem de rastreabilidade, definindo relações e elementos de um projeto; o segundo trata da descoberta automática de relações entre elementos. Vários conceitos foram definidos até agora, como rastreabilidade bidirecional, rastreabilidade de especificações pré e pós-requisitos, rastreabilidade horizontal e vertical, e rastreabilidade explícita e implícita. Embora haja um consenso geral sobre a maioria dos conceitos relacionados a rastreabilidade, há uma falta de consenso sobre como, e o quê, deve ser rastreado; não há consenso sobre: quais relações são relevantes para os projetos de desenvolvimento de software, quais elementos devem ser rastreados, como as mudanças nos elementos de um projeto afetam as relações existentes, ou como atualizar as relações dadas certas mudanças. Os modelos de rastreabilidade visam responder a essas questões fornecendo um padrão para ser usado como uma guia em projetos de desenvolvimento de software; entretanto, não há consenso sobre o que um modelo deve conter. Existe uma variedade de modelos, cada um considerando diferentes tipos de relações, elementos, e possuindo diferentes focos. Além disso, a maioria dos modelos possui problemas que tornam o seu uso difícil, ou até mesmo impossível; por exemplo, existem modelos que não descrevem - suficientemente ou em nada - as ligações de rastreabilidade que propõem. Este trabalho visa a ajudar nesta questão, fornecendo uma contribuição dupla: um modelo de referência para criar e avaliar modelos de rastreabilidade, e um metamodelo abrangente, construído em cima do modelo de referência, para adicionar rastreabilidade a projetos de desenvolvimento de software. Nosso Modelo de Referência para rastreabilidade define os elementos básicos em um modelo de rastreabilidade e define conjuntos básicos de: ações, tipos de ligações, tipos de artefatos, e processos. Propriedades necessárias para o conjunto de tipos de ligações e o conjunto de tipos de artefatos também são fornecidas. Nosso Metamodelo para rastreabilidade é composto por: um modelo conceitual descrevendo e organizando os elementos de rastreabilidade; um conjunto de tipos de artefatos representando as atividades definidas no Modelo de Referência, além de um conjunto de tipos de artefatos criados para registrar decisões de design; um conjunto de tipos de ligações que modelam diferentes relações de rastreabilidade; e um conjunto de processos para garantir a consistência de projetosAbstract: Traceability has been a topic of research in software development for at least 40 years, being added to many standards, such as the DOD-STD-2167A and the IEEE 830-1998. The latter, for instance, states that a good software requirements specification should be traceable. Traceability provides many benefits to software projects, such as: identification of the reasons for design decisions, avoidance of dependency issues, identification of accountability in a project, estimation of impact and cost of modifications, and measurement of development progress. Succintly, traceability allows the generation of a better quality product. Two main focuses have emerged in the literature in recent years: model-based development and automated trace generation. The former concerns modeling traceability by defining relations and elements in a project; the latter concerns automatic discovery of relations between elements in a project. Several concepts have been defined so far, such as bidirectional traceability, pre and post-requirements specification traceability, horizontal and vertical traceability, and explicit and implicit traceability. While there is general consensus on most concepts related to traceability, there is a lack of consensus on how, and what, should be traced; there is no consensus on which relations are relevant for software development projects, which elements should be traced, how changes in elements of a project affects existing relations, or how to update relations given certain changes. Traceability models aim to answer these questions by providing a standard to be used as a guide in software development projects; however, there is no consensus on what a model should contain. There is a variety of models, each considering different types of relations, elements, and having distinct focuses. Also, the majority of models have issues which makes them difficult or even impossible to use; for instance, there are models which do not describe - sufficiently or at all - traceability links which they propose. This work aims to help in this issue by providing a twofold contribution: a reference model for creating and evaluating traceability models, and a comprehensive metamodel, built on top of the reference model, to add traceability to software development projects. Our Reference Model for traceability defines the basic elements in a traceability model and defines basic sets of: actions, link types, artifact types, and processes. Necessary properties for the sets of link types and artifact types are also provided. Our Metamodel for traceability is composed of: a conceptual model describing and organizing the elements of traceability; a set of artifact types representing the activities of the Reference Model, plus a set of artifact types created to record design decisions; a set of link types modeling different traceability relations; and a set of processes to ensure project consistencyDoutoradoEngenharia de ComputaçãoDoutor em Engenharia Elétrica1142618CAPE

Proceso de generación de casos de prueba en el contexto MDD/MBT

Desde la aparición de la metodología MDD, mucho se ha propuesto y definido en cuanto a lenguajes y herramientas que sirven de soporte y automatizan sus diferentes aspectos. Uno de estos aspectos donde se ha puesto más énfasis es en la definición de lenguajes que permiten traducir un modelo en otro. Luego, con la aparición de MBT, se han propuesto nuevos aportes e investigaciones que sirven de soporte para la generación de casos de prueba y para el testing en general. En este sentido, se ha analizado que las actividades de testeo a nivel modelado, muchas veces se realizan en la etapa de diseño del sistema, con los detalles de implementación ya definidos. Sin embargo, es en etapas iniciales del desarrollo de software, cuando se define claramente la funcionalidad del sistema, indicando el "qué" sin mencionar el "cómo". Esta tesina presenta un proceso, dentro de los contextos mencionados, que permite generar casos de prueba tempranamente en el ciclo de vida del desarrollo, de manera automática por medio de transformaciones y con generación de trazabilidad. Se brinda, de esta manera, soporte testing de sistemas y a las técnicas de trazabilidad dentro de los contextos MDD y MBT.Facultad de Informátic

Proceso de generación de casos de prueba en el contexto MDD/MBT

Desde la aparición de la metodología MDD, mucho se ha propuesto y definido en cuanto a lenguajes y herramientas que sirven de soporte y automatizan sus diferentes aspectos. Uno de estos aspectos donde se ha puesto más énfasis es en la definición de lenguajes que permiten traducir un modelo en otro. Luego, con la aparición de MBT, se han propuesto nuevos aportes e investigaciones que sirven de soporte para la generación de casos de prueba y para el testing en general. En este sentido, se ha analizado que las actividades de testeo a nivel modelado, muchas veces se realizan en la etapa de diseño del sistema, con los detalles de implementación ya definidos. Sin embargo, es en etapas iniciales del desarrollo de software, cuando se define claramente la funcionalidad del sistema, indicando el "qué" sin mencionar el "cómo". Esta tesina presenta un proceso, dentro de los contextos mencionados, que permite generar casos de prueba tempranamente en el ciclo de vida del desarrollo, de manera automática por medio de transformaciones y con generación de trazabilidad. Se brinda, de esta manera, soporte testing de sistemas y a las técnicas de trazabilidad dentro de los contextos MDD y MBT.Facultad de Informátic

XX Workshop de Investigadores en Ciencias de la Computación - WICC 2018 : Libro de actas

Actas del XX Workshop de Investigadores en Ciencias de la Computación (WICC 2018), realizado en Facultad de Ciencias Exactas y Naturales y Agrimensura de la Universidad Nacional del Nordeste, los dìas 26 y 27 de abril de 2018.Red de Universidades con Carreras en Informática (RedUNCI

WICC 2017 : XIX Workshop de Investigadores en Ciencias de la Computación

Actas del XIX Workshop de Investigadores en Ciencias de la Computación (WICC 2017), realizado en el Instituto Tecnológico de Buenos Aires (ITBA), el 27 y 28 de abril de 2017.Red de Universidades con Carreras en Informática (RedUNCI

XX Workshop de Investigadores en Ciencias de la Computación - WICC 2018 : Libro de actas

Actas del XX Workshop de Investigadores en Ciencias de la Computación (WICC 2018), realizado en Facultad de Ciencias Exactas y Naturales y Agrimensura de la Universidad Nacional del Nordeste, los dìas 26 y 27 de abril de 2018.Red de Universidades con Carreras en Informática (RedUNCI