APPLYING THE ISO/IEC 26550 AND ISO/IEC 26551 STANDARDS TO INCORPORATE THE QUALITY OF THE SOFTWARE IN A PRODUCT LINE

The Software Product Line (SPL) is geared toward large-scale reuse of software artifacts and components, productivity, cost reduction and time to market, and to improve quality. It based on two processes, domain engineering and application engineering. Before the diffusion of the series of own ISO standards to SPL, the engineering of the domain was formed by the analysis disciplines, design and implementation of the domain. However, in the ISO/IEC 26550 standard a new reference model is defined in which domain analysis is replaced by the scope of the SPL and domain requirements engineering. On the other hand, the ISO/IEC 26551 standard defines the reference model for the requirements engineering of SPL structured in five processes, the scope of the SPL is one of them and the first one to be considered in the development of SPL. In addition, in one of the scope of the SPL activities, it specified that the quality of the product must be considered. In this sense, this work proposes to incorporate the obtaining of the domain quality model of the SPL, which provides information on the software quality of any product. The quality model of the domain is obtained using the ISO/IEC 25010 standard. The artifacts that are built, relative to product quality, will be part of the product portfolio artifact, result of the scope of the product.La Línea de Productos de Software (LPS), está orientada a la reutilización a gran escala de artefactos y componentes de software, productividad, reducción de costos y tiempo de comercialización, y a mejorar la calidad. Se basa en dos procesos, la ingeniería del dominio y la ingeniería de la aplicación. Antes de la difusión de la serie de estándares ISO propios a una LPS, la ingeniería del dominio estaba formada por las disciplinas análisis, diseño e implementación del dominio. Sin embargo, en el estándar ISO/IEC 26550 se define un nuevo modelo de referencia en el cual el análisis del dominio es sustituido por el alcance de la LPS y la ingeniería de requisitos del dominio. Por otra parte, en el estándar ISO/IEC 26551 se define el modelo de referencia para la ingeniería de requisitos de una LPS estructurado en cinco procesos, el alcance de la LPS es uno de ellos y el primero que debe ser considerado en el desarrollo de una LPS. Además, en una de las actividades del alcance de la LPS, se especifica que debe ser considerada la calidad del producto. En tal sentido, este trabajo propone incorporar la obtención del modelo de calidad del dominio de la LPS, que proporcione información sobre la calidad de software de cualquier producto. El modelo de calidad del dominio se obtiene haciendo uso del estándar ISO/IEC 25010. Los artefactos que se construyen, relativos a la calidad del producto, formarán parte del artefacto portafolio del producto, resultado del alcance del producto.&nbsp

Una Aproximación de Ingeniería de Requisitos para Líneas de Productos Software Basada en una Estrategia de Desarrollo Dirigido por Modelos

[EN] The Requirements Engineering (RE) activity is crucial in software engineering. A failure when defining the requirements of a system could increase the costs of the entire product development process. This problem is even more critical in the Software Product Lines (SPL) development, since the definition and specification of requirements must deal with a new dimension: requirements variability. Requirements variability is specified during the domain engineering process, in which variability points are defined so as to distinguish which requirements will be common, and which will be variable. These variability points are resolved during an application engineering activity called requirements derivation in order to obtain the requirements for a specific product. Another paradigm that is widely applied in SPL Development is Model-Driven Software Development (MDSD). MDSD can reduce production costs by increasing software reuse. Despite this fact, the RE approaches for SPL found in literature have some weaknesses. Many of the current approaches represent the variability information in the requirements models, thus reducing the requirements' readability. Moreover, the RE approaches for SPL used during application engineering are normally limited to deriving the product requirements from the SPL requirements and do not indicate how to represent non-existent requirements in the SPL: the delta requirements. This has an undesirable effect on the flexibility of the approaches. The aim of this thesis is to define and validate an RE approach in the context of SPL that will support the definition and specification of the requirements of an SPL, allowing them to be derived from the requirements of a product using the MDSD paradigm, and also supporting the definition and specification of delta requirements. In this context, we have defined a process called FEDRE. During domain engineering, strategy definition and requirements specification obtained from model features are used. During application engineering, the derivation and validation of product requirements ensure that requirements meet customer needs. The necessary delta requirements could be specified, when they will be required, with the aim to prevent that product requirements are limited to a mere combination of LPS requirements. Moreover, a technological approach based on a MDSD strategy was defined. During domain engineering, the variability of the SPL and the requirements variability are represented as multi-model views, and traceability relationships are established among them. During application engineering, the productconfiguration is defined and the requirements of the product to be built are derived using a strategy based on model transformations. The process proposed in FEDRE has been validated using two quasi-experiments. In the first quasi-experiment, the SPL requirements were specified with the aim of validating the FEDRE domain engineering guidelines. According to the results, FeDRE was perceived as easy to use and useful as regards specifying the requirements for an SPL. In the second quasi-experiment, the requirements of a product were validated with the aim of verifying whether the customer needs where covered. In the case of their not being covered, the participants specified the delta requirements. Most of the subjects were able to correctly identify what needs were covered and which requirements had to be added as delta requirements. This dissertation contributes to the field of development of SPL by providing a process and technology, along with an automated and generic approach with which to define and specify requirements in SPL environments.[ES] La actividad de Ingeniería de Requisitos (IR) resulta crucial dentro de la ingeniería del software. Un fallo durante la definición de los requisitos de un sistema puede provocar sobrecostes durante todo el proceso de desarrollo. Este problema se acentúa aún más en el desarrollo de Líneas de Producto Software (LPS) debido a que la definición y especificación de los requisitos deben de tratar con una nueva dimensión: la variabilidad de los requisitos. Esta variabilidad de los requisitos de la LPS se específica durante el proceso de ingeniería del dominio, donde se definen los puntos de variabilidad que permiten diferenciar qué requisitos serán comunes y cuáles serán variables. Estos puntos de variabilidad se resuelven durante el proceso de ingeniería de la aplicación para obtener los requisitos de un producto específico, en la actividad llamada derivación de requisitos. Otro paradigma ampliamente aplicado en las LPS es de Desarrollo de Software Dirigido por Modelos (DSDM). El DSDM puede reducir costes de producción, gracias al aumento de la reutilización de software. Sin embargo las aproximaciones actuales representan la información de la variabilidad de los requisitos exclusivamente en el mismo modelo de requisitos, perjudicando la legibilidad de los requisitos. Por otra parte durante la ingeniería de la aplicación, las aproximaciones de IR para LPS normalmente se limitan a derivar los requisitos del producto a partir de los requisitos de la LPS, pero no explicitaban cómo representar requisitos que no existían previamente en la LPS: los requisitos delta. Este hecho incide negativamente en la flexibilidad de las aproximaciones. El objetivo de esta tesis doctoral es definir y validar una aproximación de IR en el contexto de LPS que soporte la definición y especificación de los requisitos de una LPS, permitiendo derivar a partir de ellos los requisitos de un producto haciendo uso del paradigma de DSDM, y soportando además la definición y especificación los requisitos delta. En este contexto, se ha definido un proceso llamado FeDRE. Durante la ingeniería del dominio se utiliza una estrategia de definición y especificación de los requisitos a partir del modelo de características. Durante la ingeniería de la aplicación se cubre la derivación de los requisitos y la validación para comprobar que satisfacen las necesidades del cliente. En el caso de que fuera necesario se permiten modelar los requisitos delta, evitando que los requisitos del producto estén limitados a una mera combinación de requisitos de la LPS. Por otra parte se ha definido una aproximación tecnológica basada en una estrategia de DSDM. Durante la ingeniería del dominio se representan en un multimodelo las vistas de variabilidad de la LPS y la de requisitos, estableciendo relaciones de trazabilidad entre ellas. Durante la ingeniería de la aplicación se define una configuración del producto y se derivan, mediante una estrategia basada en transformaciones de modelos, los requisitos del producto a desarrollar. El proceso propuesto en FeDRE se ha validado mediante dos cuasi-experimentos. El primer cuasi-experimento modelaba los requisitos de una LPS con el objetivo de validar las guías de la ingeniería del dominio de FeDRE. Los resultados mostraron que FeDRE fue percibido como fácil de usar y útil para especificar los requisitos de una LPS. En el segundo cuasi-experimento se validaron los requisitos de un producto con el objetivo de comprobar si cubrían las necesidades del cliente. En el caso de que no lo hicieran, los participantes especificaron los requisitos delta. La mayor parte de los sujetos fueron capaces de identificar correctamente qué necesidades estaba cubiertas y qué requisitos debían de añadirse como requisitos delta. Esta tesis doctoral contribuye al campo de desarrollo de LPS proveyendo de un proceso y una aproximación tecnológica, automatizada y genérica para la definición y especificación de re[CA] L'activitat d'Enginyeria de Requeriments (ER) és crucial dins de l'enginyeria del programari. Un error durant la definició dels requeriments d'un sistema pot provocar sobrecostos durant tot el procés de desenvolupament. Aquest problema s'accentua en el desenvolupament de Línies de Producte Software (LPS) a causa de que la definició i especificació dels requeriments han de treballar amb una nova dimensió: la variabilitat dels requeriments. Aquesta variabilitat dels requeriments de l'LPS s'especifica durant el procés d'enginyeria del domini, on es defineixen els punts de variabilitat que permeten diferenciar quins requeriments seran comuns i quins seran variables. Aquests punts de variabilitat es resolen durant el procés d'enginyeria de l'aplicació per obtenir els requeriments d'un producte específic, en l'activitat anomenada derivació de requeriments. Un altre paradigma àmpliament aplicat a les LPS és el Desenvolupament de Programari Dirigit per Models (DSDM). El DSDM pot reduir costos de producció, gràcies a l'augment de la reutilització de programari. Malgrat això les aproximacions d'ER per a LPS presenten algunes debilitats. Moltes de les aproximacions actuals representen la informació de la variabilitat dels requeriments exclusivament en el mateix model de requeriments, perjudicant la llegibilitat dels requeriments. D'altra banda, durant l'enginyeria de l'aplicació, les aproximacions d'ER per a LPS normalment es limiten a derivar els requeriments del producte a partir dels de la LPS, però no expliciten com representar requeriments que no existien prèviament a l'LPS: els requeriments delta. Aquest fet incideix negativament en la flexibilitat de les aproximacions. L'objectiu d'aquesta tesi doctoral és definir i validar una aproximació d'ER en el context de LPS que done suport a la definició i especificació dels requeriments d'una LPS, permetent derivar a partir d'ells els requeriments d'un producte fent ús del paradigma de DSDM i donant suport a més a la definició i especificació dels requeriments delta. En aquest context, s'ha definit un procés anomenat FeDRE. Durant l'enginyeria del domini s'utilitza una estratègia de definició i especificació dels requeriments a partir del model de característiques. Durant l'enginyeria de l'aplicació es cobreix la derivació dels requeriments i la validació per comprovar que satisfan les necessitats del client. En el cas que fora necessari es permetrà modelar els requeriments delta, evitant que els requeriments del producte estiguen limitats a una mera combinació de requeriments de l'LPS. D'altra banda s'ha definit una aproximació tecnològica basada en una estratègia de DSDM. Durant l'enginyeria del domini es representen en un multimodel les vistes de variabilitat de l'LPS i la de requeriments, establint relacions de traçabilitat entre elles. Durant l'enginyeria de l'aplicació es defineix una configuració del producte i es deriven, mitjançant una estratègia basada en transformacions de models, els requeriments del producte a desenvolupar. El procés proposat en FeDRE s'ha validat mitjançant dos quasi-experiments. El primer quasi-experiment modelava els requeriments d'una LPS amb l'objectiu de validar les guies de l'enginyeria del domini de FeDRE. Els resultats mostren que FeDRE va ser percebut com fàcil d'utilitzar i útil per especificar els requeriments d'una LPS. En el segon quasi-experiment es van validar els requeriments d'un producte amb l'objectiu de comprovar si cobrien les necessitats del client. En el cas que no ho feren, els participants especificaren els requeriments delta. La major part dels subjectes van ser capaços d'identificar correctament quines necessitats estaven cobertes i quins requeriments havien d'afegir com a requeriments delta. Aquesta tesi doctoral contribueix al camp del desenvolupament de LPS proveint d'un procés i d'una aproximació tecnològica, automatitzada i genèrica per a la definició i especificació dBlanes Domínguez, D. (2016). Una Aproximación de Ingeniería de Requisitos para Líneas de Productos Software Basada en una Estrategia de Desarrollo Dirigido por Modelos [Tesis doctoral no publicada]. Universitat Politècnica de València. https://doi.org/10.4995/Thesis/10251/6326

Hacia una línea de productos: diseño de arquitecturas de referencia en el dominio de la computación móvil

Las Líneas de Productos de Software (LPS) basadas en la reutilización, pretenden mejorar tiempo de comercialización, evolución del software y bajar costos de desarrollo. Productos de software, miembros de la familia LPS, son derivados instanciando una Arquitectura de Referencia (RA: “Reference Architecture”) genérica, con componentes comunes y variantes. La ventaja para una empresa es obtener productos concretos instanciando la RA, reutilizando un repositorio de activos (“assets”). Sin embargo, diseñar una RA para un dominio dado, es tarea compleja y costosa en vista de que ésta debe ser evolutiva, acorde con los cambios tecnológicos. Se puede atacar el problema considerando que la empresa crea desde cero su LPS, aplicando una estrategia descendente (“top-down”), para definir el repositorio de activos inspirándose en productos del mercado existentes en el dominio. Otra forma es seguir una estrategia ascendente (“bottom-up”) cuando una empresa tiene varios productos desarrollados y determinar mediante un proceso de reingeniería, componentes o módulos que pueden ser reutilizados como activos; esta es la estrategia seguida en la presente investigación. El objetivo de este trabajo es describir un proceso bottom-up semi-formal, sistemático y repetible de diseño de la RA, representada por un grafo conexo no dirigido. El proceso es aplicado al caso de estudio de aplicaciones de Transacciones Financieras, sub-dominio de la Computación Móvil del consorcio CONECTIUM Limited C.A., que también contempla aplicaciones en los sub-dominios Sistemas de Salud y Contenidos de Entretenimiento. Los resultados obtenidos son ilustrativos, repetibles y de utilidad para la práctica industrial, facilitando así la Ingeniería de una LPS.Palabras clave: línea de productos de software, arquitectura de referencia,diseño de una arquitectura de referencia, proceso bottom-up, computación móvil, ingeniería del dominio

Estrategias de pruebas de líneas de producto de sistemas de tiempo real especificados con diagramas de estados jerárquicos

Las Líneas de Producto Software han aparecido en la ingeniería del software como una técnica cuyo objetivo es el de poder crear diferentes variantes software a partir de una infraestructura común, del mismo modo que se hace en otros sectores industriales. Un aspecto que hasta ahora no se ha investigado con tanta extensión es el de las Pruebas de Línea de Producto Software. La cuestión fundamental es decidir hasta qué punto es posible probar las diferents variantes de forma común. En el caso más optimista, probando una funcionalidad sobre la parte general se podría dar por probada sobre todas las variantes. Por contra, en el caso más pesimista, las pruebas de una Línea de Producto Software serían exactamente iguales que las pruebas de varios productos independientes que se hicieran de forma separada. Como término medio, aunque se pruebe la misma funcionalidad en todas las variantes, se podrian reutilizar por ejemplo la arquitectura de pruebas, los casos de prueba, el entorno de pruebas, etc. Buscando dar una solución al problema de las pruebas de Líneas de producto Software de tiempo real, la Tesis Doctoral propone un método de pruebas basado en los diagramas de estados jerárquicos del lenguaje UML para definir los casos de prueba. Se propone una técnica para asegurar la correspondencia (trazabilidad) de los requisitos con los casos de prueba, estructurándolos de forma semejante a los requisitos y estudiando cómo las variantes de los requisitos impactan sobre los diferentes elementos de prueba. También se define dentro del método un flujo de actividades, cuyo objetivo es la automatización de las pruebas para así poder probar las diferentes variantes de la Línea de Producto Software de forma eficiente. Este método tiene tres fases: el Diseño de Pruebas, donde se agrupan en clases de prueba los requisitos tanto genéricos como específicos de cada variante, y se modela cada clase de prueba mediante diagramas de estados jerárquicos y, si es preciso, escenarios en los cuales se incluyen de forma explícita sus requisitos asociados. En la fase de Implementación de Pruebas, estos diagramas se describen por medio de tablas de estados y eventos, con la información adicional necesaria (los datos de prueba) para generar automáticamente el código con los casos de prueba ejecutables. En la fase final de Ejecución de Pruebas, se realiza el caso de prueba sobre el sistema real y se registra el resultado obtenido. Como aportación final, se propone un metamodelo donde se muestran todos los elementos del método de pruebas y las relaciones que existen entre ellos. Para comprobar que la solución propuesta al problema de las pruebas de Líneas de Producto Software de Tiempo real es satisfactoria, se ha elegido una doble estrategia consistente en la aplicación del método sobre un caso industrial real y en la elaboración de un conjunto de herramientas software prototipo, con las cuales se ha demostrado la validez del método propuesto y se ha delimitado su alcance. El caso industrial real escogido ha sido el de una Línea de Productos Software Tiempo Real de sistemas de control del tráfico ferroviario, en el que el autor desarrolla desde hace diez años su actividad profesional, lo cual da a esta Tesis Doctoral un marcado carácter industrial, tanto por la relevancia práctica del tema elegido como por reflejar una experiencia de aplicación industrial real. Las herramientas software desarrolladas, tanto en el caso de aplicación industrial real, como en el ámbito de la Tesis Doctoral, sirven de soporte a la generación de casos de prueba a partir de los modelos de diagramas de estados, la ejecución automatizada de las pruebas, el análisis de los resultados o veredictos de las pruebas y la medición de cobertura de requisitos alcanzada en las pruebas

Evaluación de atributos de calidad en líneas de productos software de forma efectiva en costes

Software product line engineering is a software development paradigm that allows the systematic reuse in the development of a product family, a set of related products that share common features. A feature is a relevant aspect or characteristic of a system. In software product line engineering, the quality validation (to assure that the quality requirements are met) is very important. It is necessary to ensure that the product line assets, especially the product line architecture is exible enough to support all the products of the line and any new future product. However, traditionally, during the evaluation time only the functional requirement variability has been considered and the quality attribute variability has received little attention. In order to overcome this limitation, the CaLiPro method to evaluate quality in software product lines has been proposed. With this method, the evaluation of the quality attributes and their variability within a software product line can be achieved in a coste ective way. This method is based on the modeling of the quality attribute variability throughout the development phase. This modeling also helps to de ne the relationships and interactions between the functional and the quality attribute variability. Therefore, it is viable to predict which variable aspects a ect quality in order to reduce the evaluation work and to avoid the validation of each product individually. Two strategies are proposed herein to reduce evaluation e ort: 1) to create a generic evaluation model (with variability) to allow the evaluation of all the products at the design level and 2) to select the minimum number of products or designs in order to evaluate and extrapolate the results to the overall product line. Although the main goal of this method is the evaluation, the results obtained from this evaluation can be very useful during the derivation. The method also has a phase to facilitate quality aware product derivation.Software produktu lerroen ingeniaritza softwarea garatzeko paradigma bat da, eta produktu familiak sortzeko sistematikoki berrerabiltzea ahalbidetzen du. Produktu familiak elkarrekin harremana duten produktu multzoak dira, zenbait ezaugarri (features) batean dituztenak. Ezaugarriok sistema batean gailentzen direnak dira. Software produktu lerroen ingeniaritzan, oso garrantzitsua da kalitatea garaiz egiaztatzea: kalitate atributuak bete egingo direla ziurtatzea. Produktu lerroetako aktiboak malguak izan daitezela ziurtatu behar da, produktu lerroen egitura bereziki, eta lerroko produktu guztientzat (baita etorkizuneko produktuentzat ere) euskarri gisa balioko dutela. Alabaina, ebaluatzeko orduan irizpide funtzionalak soilik hartu ohi dira kontuan, eta kalitate atributuen aldakortasunak ez du ikertzaileen arreta bereganatzen. Arazo horri aurre egiteko CaLiPro metodoa proposatzen dugu. Metodo horrek kalitate atributuak eta beraien aldakortasuna ebaluatzeko aukera ematen du software produktu lerroetan, modu eraginkor batean eta koste baxuarekin. Oinarrietako bat kalitate atributuen aldakortasuna modelatzea da: garapenaren une guztietan kalitatearen aldakortasuna balioestea, lehen graduko entitatetzat hartzea, alegia. Hala, aldakortasun funtzionalaren eta kalitate atributuen aldakortasunaren arteko harremanak eta interakzioak atzeman daitezke, eta posible da kalitatean eragiten duten ezaugarri aldakorrak zein diren jakitea, eta informazio hori ebaluazio ahalegina murrizteko erabiltzea, produktu denak banan-banan ebaluatu beharrik gabe. Ebaluazio ahalegina murrizteko bi estrategia proposamen dauzkagu: batetik, ebaluaketa modelo generikoa (aldakorra) sortzea; horrek produktu lerroetako produktu guztiak ebaluatzea ahalbidetuko du. Eta bestetik, ahalik eta produktu edo diseinu kopuru txikiena aukeratzea ebaluaziorako, eta gero emaitzak lerro osora estrapolatzea. Metodoaren helburu nagusia kalitatea ebaluatzea bada ere, lortutako emaitzak oso baliagarriak dira deribazio aldian ere. Horregatik, kalitate irizpideak aintzat hartuta produktuen deribazioa errazteko fase bat ere aurreikusten da.La ingeniería de línea de productos software es un paradigma de desarrollo software que permite una reutilización sistemática en el desarrollo de una familia de productos, un conjunto de productos relacionados que comparten características (features) comunes. Una feature es un aspecto o característica relevante de un sistema. En la ingeniería de líneas de productos software, la validación temprana de la calidad (asegurar que los requisitos de calidad se van a lograr) cobra una importancia especial. Hay que asegurar que los activos de la línea de productos, sobre todo la arquitectura de línea de productos, sean exibles y den soporte a todos los productos de la línea, así como a futuros productos. Sin embargo, tradicionalmente a la hora de evaluar, sólo se ha considerado la variabilidad en los requisitos funcionales y la evaluación de la variabilidad en los atributos de calidad ha recibido poca atención. Para responder a esta problemática, se propone el método Ca-LiPro (Evaluación de atributos de Calidad en Líneas de Productos Software) que permite evaluar los atributos de calidad y su variabilidad en una línea de productos software de una forma efectiva en costes. Una de las bases del método es el modelado de la variabilidad en los atributos de calidad, que trata la variabilidad de los atributos de calidad como una entidad de primer grado durante todo el desarrollo y permite capturar las relaciones e interacciones existentes entre la variabilidad funcional y la variabilidad en los atributos de calidad. De este modo, es posible centrarse en los aspectos variables que afectan a la calidad y utilizar esta información para reducir el esfuerzo de evaluación y evitar tener que evaluar todos los productos uno a uno. Para ello, se proponen dos estrategias de reducción de esfuerzo de las evaluaciones: crear un modelo de evaluación genérico (con variabilidad) que permita evaluar a nivel de diseño todos los productos de la línea y seleccionar el mínimo número de productos o diseños para su evaluación de modo que se puedan extrapolar los resultados a toda la línea. Aunque el objetivo principal del método es la evaluación de la calidad, los resultados obtenidos de la evaluación son una informaci ón muy útil durante la derivación. Por esta razón, el método también contempla una fase para facilitar una derivación de productos tendiendo en cuenta aspectos de calidad

Derivación, Evaluación y Mejora de la Calidad de Arquitecturas Software en el Desarrollo de Líneas de Producto Software Dirigido por Modelos

En los últimos años se han propuesto diferentes aproximaciones para el desarrollo de sistemas altamente complejos. Algunos esfuerzos intentan aplicar la aproximación de Líneas de Producto Software tratando de sacar partido de la reutilización masiva para producir sistemas software que comparten un conjunto común de características. Una Línea de Producto Software (LPS) es un conjunto de sistemas software que comparten un conjunto de características comunes que satisfacen las necesidades específicas de un segmento de mercado particular y que son desarrollados a partir de un conjunto de activos software comunes de un modo preestablecido [6]. El desarrollo de una LPS consta de dos procesos básicos: la Ingeniería del Dominio, donde se establece cuáles son las partes comunes y las variables y se construye un conjunto de activos (product¿s line core assets) como partes de los sistemas software a desarrollar, y la Ingeniería de la Aplicación, donde los core assets son reutilizados sistemáticamente para derivar productos específicos. De este modo se reducen costes y tiempo de desarrollo. En el desarrollo de líneas de producto se presentan dos arquitecturas software que juegan dos roles diferenciados; i) la arquitectura de la línea de producto que da soporte a todas los posibles productos que pueden ser obtenidos a partir de la línea de producto y que cuenta con los mecanismos de variabilidad necesarios para cubrir toda la gama de productos y ii) la arquitectura de producto, que es creada a partir de la arquitectura de la línea de producto ejerciendo los mecanismos de variabilidad, para que esta se adapte a los requisitos del producto en desarrollo. En general, el aseguramiento de la calidad del producto es una actividad crucial para el éxito de la industria del software, pero es, si cabe, más importante cuando se trata del desarrollo de líneas de producto software, dado que la reutilización masiva de core assets hace que los atributos de calidad (propiedades físicas o abstractas de un artefacto software) de los core assets impacten en la calidad de todos los productos de una línea de producto. Este hecho es de especial relevancia cuando tratamos con la arquitectura software, que es el core asset mas critico en el desarrollo de líneas de producto. La arquitectura software es la vía para conseguir el cumplimiento de los requisitos no funcionales de nuestro producto, por lo que asegurar que estos requisitos se cumplen durante el proceso de derivación de la arquitectura es una actividad crítica en el proceso de desarrollo. El desarrollo de líneas de producto va, en la mayoría de los casos, ligada a la aplicación del paradigma de desarrollo dirigido por modelos. El Desarrollo de Software Dirigido por Modelos (DSDM) que promueve el uso de modelos durante a lo largo de todo el proceso de desarrollo de software, permitiendo que estos modelos puedan ser transformados sucesivamente hasta la obtención del producto final. En la literatura no se encuentran propuestas que, de forma completa, sistemática y automatizada, permitan obtener arquitecturas de producto software que cumplan una serie de requisitos de calidad. El presente trabajo de investigación pretende la mejora del contexto anterior proponiendo el método QuaDAI (Quality Driven Architecture Derivation and Improvement), un método de derivación, evaluación y mejora de la calidad de arquitecturas software en el Desarrollo de Líneas de Producto Dirigido por Modelos mediante la definición de un artefacto (el multimodelo) y de un proceso dirigido por transformaciones que permite automatizar un proceso (el de derivación, evaluación y mejora) de por si altamente complejo. Este método va dirigido a empresas de desarrollo de software que utilice el paradigma de LPS y que pretendan introducir técnicas automatizadas de aseguramiento de calidad y para investigadores interesados en el campo de las arquitecturas software, líneas de producto y desarrollo dirigido por modelos.González Huerta, J. (2014). Derivación, Evaluación y Mejora de la Calidad de Arquitecturas Software en el Desarrollo de Líneas de Producto Software Dirigido por Modelos [Tesis doctoral no publicada]. Universitat Politècnica de València. https://doi.org/10.4995/Thesis/10251/36448TESI

Tecnología y Accesibilidad Volumen 2

Prologar el texto de las actas del VII Congreso Internacional sobre Aplicación de Tecnologías de la Información y Comunicaciones Avanzadas (ATICA2016) y de la IV Conferencia Internacional sobre Aplicación de Tecnologías de la Información y Comunicaciones para mejorar la Accesibilidad (ATICAcces 2016), no solo es una tarea privilegiada sino también una responsabilidad, en especial con la sociedad que solicita tecnologías inclusivas y comunicaciones efectivas en pro de la equidad. Es interesante señalar que el anhelo por consolidar categorías que favorezcan la participación social ha sido el sueño y trabajo de muchos, por ejemplo vale recordar que en este año del Congreso se cumplen 500 desde que Tomás Moro ofreciera al mundo su voz en “UTOPIA”, donde en la idealización de su isla estampó una cultura de trabajo, cooperación y democracia, sin descuidar que proclamó a Amauroto, la capital de su República, como una de total accesibilidad para que todo ciudadano pueda llegar y gozar de ella, con suficiente agua para todos; su localidad estaba constituida por casas que eran custodiadas por cerraduras tan simples que cualquiera podía ingresar o salir de ellas ya que el verdadero tesoro de toda persona era su propio ser. Este breve evocar, da la pauta para promover Utopías necesarias en cuanto a las TIC, que aunque sabemos que es quimérico hablar de ellas como totalmente abiertas y al alcance de todos, debería ser éste el ideal de los hombres cuya ciencia, hoy en día, permite integrarnos a esta nuestra aldea global, es por ello que ATICA 2016 busca romper aquellos muros virtuales y tecnológicos que impiden una comunicación efectiva en nuestros tiempos. El trabajo del Congreso también semeja a la norma de discusión del Senado de Utopía, donde sus expositores socializan sus lógicas mejores, no hay intervención que no sea fruto de la madurez de un proceso investigativo científico que procure el bien público. Parece igualmente exacto ver como entre los participantes existe una suerte de familia, que aunque adoptiva, por configurarse alrededor de un objetivo común como ATICA 2016, a todos ellos, su dedicación a la ciencia y la tecnología al servicio de los más necesitados, los ha unido. En esta ocasión los autores representan a 11 países: Argentina, Brasil, Colombia, Cuba, Ecuador, España, Francia, Guatemala, México, Panamá y Perú; es notable ver como los frutos académicos expuestos en los 80 artículos científicos aceptados de un total de 115 enviados, 36 abordan la línea de “Aplicación de Tecnologías de la Información y Comunicaciones para mejorar la Accesibilidad” y los restantes 44 son sobre “Aplicación de Tecnologías de la Información y Comunicaciones Avanzadas”, todos ellos superan en mucho las horas normales de trabajo, en resumen es evidente el esfuerzo académico y la convicción por un mundo más accesible desde las TIC .En el relato de Moro, la verdadera felicidad, es la libertad y el desarrollo de valores espirituales, pero también existe posibilidad para la guerra y la esclavitud, asimismo como la ciencia y tecnología pueden ser consideradas herramientas de doble arista; por ello el Congreso enfocó muy bien su debate y su comité científico, formado por académicos internacionales, aseguró que ATICA 2016 esté en torno a la inclusión y a la equidad. Igual satisfacción que dejó en su tiempo Utopía a aquellos a los cuáles le fue develada, encontrarán las gentes de hoy en ATICA 2016. Las memorias del evento ponen de manifiesto nuevas lógicas comunicativas y tecnológicas, pero sobre todo nos dicen que, conforme hace 500 años, es posible soñar en un futuro mejor si la ciencia y tecnología están al servicio del ser humano

Sistema electrónico de recolección, almacenamiento y proyección de datos de identificación reales para el control del expendio de cemento a granel

Proyecto de Graduación (Licenciatura en Ingeniería Electrónica) Instituto Tecnológico de Costa Rica, Escuela de Ingeniería Electrónica, 2007.Este proyecto centra sus objetivos en determinar con exactitud la cantidad de cemento a granel dispensado diariamente (total y por tipo) en el plantel de CEMEX COSTA RICA ubicado en Colorado de Abangares. Ya que la estrategia de control que se implementa actualmente en la empresa, cuantifica la cantidad de cemento dispensado únicamente por medio de facturas de compra. Por lo que no es posible realizar un control cruzado entre la cantidad indicada en la factura de compra y la cantidad de cemento dispensada en cada descarga, por lo que no se contemplan los errores que pueda cometer el operador en cargado de realizar la entrega de cemento. En busca de una solución a este problema, que sea de bajo costo y que además genere resultados a un corto plazo, se plantea diseñar e implementar un sistema electrónico que permita recolectar información en tiempo real de la cantidad y el tipo de cemento que se descarga en cada vehiculo de transporte, de la placa del vehiculo, la fecha y hora en que concluye el procedimiento de descarga y del número de factura de compra. Esto con el objetivo de contar con un registro real que asocie cada uno de los vehículos que retiraron cemento a granel de la planta con los datos de trazabilidad correspondientes; numero de factura, tipo y cantidad de kilogramos de cemento que se descargó. Adicionalmente, el sistema funcionará como un servidor web, permitiendo así el acceso al registro real de entregas de cemento a granel a través de una página web colocada en el dominio IP de la empresa. De esta forma los gerentes relacionados con esta área podrán tener acceso a esta y realizar un mejor control de la cantidad de producto dispensado, directamente desde su computador

Ingeniería de software I

Es un área de la informática que se encarga de utilizar herramientas y metodologías para analizar las necesidades de una organización, recolectar la información necesaria para especificar los requerimientos y, con estos, hacer el diseño de software que cumpla con todos los estándares de calidad, también se encarga de realizar toda la documentación necesaria para realizar el desarrollo, operar y mantenerlos

Implantación de un sistema en línea que permita ejercer el derecho a votar en elecciones presidenciales dentro del país de Nicaragua, haciendo uso del voto electrónico desatendido desde casa o voto no presidencia

Desde hace mucho tiempo, la tecnología ha hecho cambios para el bien de la humanidad, haciendo un mundo mejor, en tanto las personas sepan utilizar este recurso. Todo ha venido en evolución, tal como la comunicación (teléfono, correo, televisión, etc.), la ciencia (medicina, computación, etc.) y la economía. Otro gran apoyo de la tecnología en la sociedad ha sido el desarrollo de sistemas computacionales especializados en el proceso de elecciones a través de lo que hoy se conoce como voto electrónico o e-voting. Estos sistemas se han venido estableciendo en varios países de América y Europa mostrando cierto grado de aceptación por parte de los usuarios. Este método de voto electrónico es una muy buena propuesta en nuestro país, tomando en cuenta en el momento de su desarrollo, los requerimientos que establece el Consejo Supremo Electoral para el proceso de las eleccione