Líneas de Producto de Software
Transcription
Líneas de Producto de Software
Líneas de Producto de Software - Introducción Rubby Casallas Departamento de Sistemas y Computación Universidad de los Andes, Bogotá Referencias [Pohl 2010] [Clements 2002] [Gomaa 2004] [Northrop 2007] Pohl K., Böckle G., van der Linden F., Requirements Engineering - Fundamentals, Principles, and Techniques. Berlin. Springer, 2010 Clements, P. & Northrop, L. Software Product Lines: Practices and Patterns. Boston, MA: Addison-Wesley, 2002. Gomaa, H. Designing Software Product Lines with UML: From Use Cases to Pattern-Based Software Architectures. Addison-Wesley Professional. 2004 Linda M. Northrop, Paul C. Clements. A Framework for Software Product Line Practice, Version 5.0. 2007. Agenda Definiciones: Línea de producción vs línea de producto Familia de productos Línea de producción Fábrica de software Objetivos de las SPLs Principios de la Ingeniería de Líneas de Producto (Product Line Engineering- [Pohl 2010] Capítulo 1) Productos individuales hechos a mano Línea de producción: productos iguales en grandes cantidades. Disminución de costos a través de estandarización Reducción de posibilidades de diversificación Línea de produción Línea de produción Línea de produción Principios de la Ingeniería de Líneas de Producto (Product Line Engineering) Personalización en masa (Mass Customisation): Producción en gran escala de productos adaptados/personalizados según necesidades de clientes particulares Ejemplos “Mass customization” Ejemplos “Mass customization” Principios de la Ingeniería de Líneas de Producto (Product Line Engineering) Personalización en masa (Mass Customisation): Producción en gran escala de productos adaptados/personalizados según necesidades de clientes particulares Plataformas (Platform): Una base tecnológica sobre la que se construye otras tecnologías o procesos Principios de la Ingeniería de Líneas de Producto (Product Line Engineering- [Pohl 2010] Capítulo 1) Qué ha pasado con el software? Cuáles son los inconvenientes del sw estandarizado (on the box) ? Cuáles son los principales riesgos del software “a la medida”? Software Product Line SPL ([Clements 2002] capítulo 1) “A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.” [Clements 2002] Línea de producto de software “Una Línea de Productos de Software es un conjunto de aplicaciones que comparten un conjunto común y administrado de características que satisfacen las necesidades particulares de un segmento del mercado o misión y que son desarrolladas a partir de un conjunto común de activos centrales en una forma prescrita” [Clements 2002] Qué no es una SPL? Reutilización fortuita de pequeñas partes de código Desarrollo de un sistema individual con reutilización de partes de otro Desarrollo basado en componentes Arquitectura reconfigurable Releases y versiones de productos individuales Conjunto de estándares técnicos Reutilización de software Experiencias? Contexto Qué, cómo Dificultades, éxitos “The interest of software product lines emerged from the field of software reuse when developers realized that they could obtain much greater reuse benefits by reusing software architectures instead of reusing individual software components” [Gomaa 2004] pag. 3 Beneficios SPLs [clements 20012] Una línea de producto tiene éxito porque los elementos comunes compartidos por los productos de software pueden ser aprovechados para lograr economías de escala Las compañías están encontrando que la práctica de construir conjuntos de sistemas relacionados a partir de activos comunes puede producir mejoras considerables en: Productividad, calidad, tiempo de salir al mercado y satisfacción de los clientes Beneficios SPLs Significativo aumento de la productividad (un orden de magnitud) Reducción del tiempo para salir al mercado Aumento de la calidad del producto Disminución del riesgo del proyecto Mayor satisfacción del cliente Uso más eficiente de los recursos humanos Capacidad para llevar a cabo la personalización en masa del producto Capacidad para mantener la presencia en el mercado Capacidad para sostener un crecimiento sin precedentes Pero finamente …. Cuáles son los “activos comunes” ? Qué es lo que se reutiliza? Además de reutilización qué más se necesita? Cómo se logran los beneficios? Qué es lo que se reutiliza? Los beneficios se logran a través de la reutilización, en una forma estratégica y prescrita, de activos (core assets) Una vez que el depósito de activos es establecido (plataforma según [Pohl 2010]) cada vez que un producto va a ser construido, hay un ahorro directo asociado con: Cómo se logran los beneficios? Qué es lo que se reutiliza? Requerimientos Arquitectura Componentes Modelamiento y análisis Pruebas Planeación Procesos Gente Beneficios vs. Costos tomado de: www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm Costs and Benefits of Product Lines Core Asset Benefit Additional Costs Requirements: The requirements are Commonality and variation are Capturing requirements for a group of written for the group of systems as a documented explicitly, which will help systems may require sophisticated whole, with requirements for individual lead to an architecture for the product analysis and intense negotiation to line. New systems in the product line will agree on both common requirements systems specified by a delta or an increment to the generic set. be much simpler to specify, because the and variation points that are acceptable requirements are reused and tailored. for all the systems. The architecture must support the Architecture: The architecture for the Architecture represents a significant product line is the blueprint for how each investment by the organization's most variation inherent in the product line, product is assembled from the talented engineers. Leveraging this which imposes an additional constraint components in the core asset base. investment across all products in the on the architecture and requires greater product line means that for subsequent talent to define. products, the most important design step is largely completed. Software components: The software The interfaces for components are The components must be designed to components that populate the core reused. For actual components that are be robust and extensible so that they asset base form the building blocks for reused, the design decisions, data are applicable across a range of product each product in the product line. Some structures, algorithms, documentation, contexts. Variation points must be built will be reused without alteration. Others reviews, code, and debugging effort can in or at least anticipated. Often, will be tailored according to prespecified all be leveraged across multiple components must be designed to be variation mechanisms. products in the product line. more general without loss of performance. Beneficios vs. Costos tomado de: http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm Performance modeling and analysis: For products that must meet real-time constraints (and some that have soft real-time constraints), analysis must be performed to show that the system's performance will be adequate. A new product can be fielded with high confidence that real-time and distributedsystems problems have already been worked out, because the analysis and modeling can be reused from product to product. Process scheduling, network traffic loads, deadlock elimination, data consistency problems, and the like will all have been modeled and analyzed. Reusing the analysis may impose constraints on moving processes among processors, creating new processes, or synchronizing existing processes. Business case, market analysis, marketing collateral, and cost and schedule estimates: These are the upfront business necessities involved in any product. Generic versions are built that support the entire product line. All the business and management artifacts All these artifacts must be generic or be involved in turning out the product line made extensible to accommodate product already exist at least in a generic form and variations. can be reused. Tools and processes for software development and making changes:The infrastructure for turning out a software product requires specific product line processes and appropriate tool support. Configuration control boards, configuration management tools and procedures, management processes, and the overall software development process are all in place and have been used before. Tools and environments purchased for one product can be amortized across the entire product line. The boards, process definitions, tools, and procedures must be more robust to account for unique product line needs and the differences between managing a product line and managing a single product. Beneficios vs. Costos tomado de: http://www.sei.cmu.edu/productlines/frame_report/benefits.costs.htm Test cases, test plans, and test data: There are generic testing artifacts for the entire set of products in the product line with variation points to accommodate product variation. Test plans, test cases, test scripts, and test data have already been developed and reviewed for the components that are reused. Testing artifacts represent a substantial organizational investment. Any saving in this area is a benefit. All the testing artifacts must be more robust, because they will support more than one product. In addition, they must be extensible to accommodate variation among the products. People, skills, and training: In a product line organization, even though members of the development staff may work on a single product at a time, they are, in reality, working on the entire product line. The product line is a single entity that embraces multiple products. Because of the commonality of the products and the production process, personnel can be more easily transferred among product projects as required. Staff expertise is usually applicable across the entire product line. Their productivity, when measured by the number of products to which their work applies, rises dramatically. Resources spent on training developers to use processes, tools, and system components are expended only once. Personnel must be trained beyond general software engineering and corporate procedures to ensure that they understand software product line practices and can use the core assets and procedures associated with the product line. New personnel must be much more specifically trained for the product line. Training materials must be created that address the product line. As product lines mature, the skills required in an organization tend to change, away from programming and toward relevant domain expertise and technology forecasting. This transition must be managed. SPLs Productividad SPLs Productividad Alcance de una Línea de Producto de Software Los productos que se pueden crear a partir de la plataforma (depósito de activos) es el alcance de la línea Costo vs. Beneficios: Si el alcance es muy amplio los beneficios se verán disminuidos Si el alcance es muy bajo los beneficios son altos pero se corre el riesgo de producir pocos productos