2 research outputs found

    Un procedimiento de medición de tamaño funcional para especificaciones de requisitos

    Full text link
    Hoy en día el tamaño del software es utilizado en la gestión y control de producción como uno de los parámetros esenciales de los modelos de estimación que contribuyen a la calidad de los proyectos de software y productos entregables. Aunque la importancia de la medición temprana del tamaño es evidente, actualmente esta medición es solamente alcanzada en fases tardías del ciclo de vida del software (análisis, diseño e implementación). El tamaño de software puede ser cuantificado usando diferentes técnicas, como las líneas de código y los métodos de medición de tamaño funcional. Un método de medición de tamaño funcional mide el tamaño del software cuantificando los requisitos funcionales. El método Análisis de Puntos de Función (FPA) es el método mayormente utilizado. Este método fue desarrollado para medir Sistemas de Información de Gestión desarrollados con metodos tradicionales. Aunque IFPUG FPA ha ido alcanzado mayor popularidad en la industria, este método carece de aplicabilidad a todo tipo de software y a nuevos paradigmas de desarrollo. Para direccionar estas debilidades, COSMIC-FFP ha surgido como un método de segunda generación y ha sido probado como un estandar internacional (ISO/IEC 19761). Sin embargo, la generalidad de COSMIC-FFP requiere ser instanciado por medio de un procedimiento más específico y sistemático en conjunción con un método de desarrollo de software.Condori Fernández, ON. (2007). Un procedimiento de medición de tamaño funcional para especificaciones de requisitos [Tesis doctoral no publicada]. Universitat Politècnica de València. https://doi.org/10.4995/Thesis/10251/1998Palanci

    Combining SOA and BPM Technologies for Cross-System Process Automation

    Get PDF
    This paper summarizes the results of an industry case study that introduced a cross-system business process automation solution based on a combination of SOA and BPM standard technologies (i.e., BPMN, BPEL, WSDL). Besides discussing major weaknesses of the existing, custom-built, solution and comparing them against experiences with the developed prototype, the paper presents a course of action for transforming the current solution into the proposed solution. This includes a general approach, consisting of four distinct steps, as well as specific action items that are to be performed for every step. The discussion also covers language and tool support and challenges arising from the transformation
    corecore