Published 16 years ago
(updated 13 years ago)
Como sabemos, los sistemas de software cada vez son más complejos, debido tanto a los pasos agigantados que da la tecnología, como a la importancia que continuamente cobran los sistemas de
información en nuestras vidas. A lo largo de los años, nuevos métodos, técnicas y herramientas han sido creados para mitigar esta creciente complejidad de desarrollar software.Una de las técnicas que han surgido para mitigar dicha complejidad, es la reutilización, la cual consiste en desarrollar elementos de software que puedan utilizarse más de una vez con la mínima cantidad
de modificaciones, garantizando que al reutilizar un elemento de software libre de defectos, implicará que el sistema que lo utilice no tendrá problema alguno en lo que respecta a dicho elemento.
Tal fue el éxito de aplicar la reutilización, que ésta evolucionó de alguna manera hasta generar el concepto de “Líneas de Productos de Software” (LPS) –conocido también como Familias de Sistemas de Software– para el cual se conocen indicios desde los años 70 cuando Parnas mencionó los beneficios de tener una familia de sistemas compartiendo características entre ellos[1].
Adaptación de productos de forma masiva
Las LPS parten de las ideas de la producción en serie (como lo hizo Henry Ford), dando la capacidad a una organización de producir o generar (nótese que no se usa el término desarrollar) sistemas de software en forma masiva, satisfaciendo las demandas del mercado; entre otros beneficios significativos. La adaptación masiva consiste en la capacidad para generar productos que comparten en gran parte características comunes, pero también mantienen características propias de cada uno de ellos. Tomando como ejemplo una línea de productos de automóviles, se puede ver que para un modelo específico de auto se pueden fabricar unidades con características propias tales como el color,
el número de puertas, transmisión automática o estándar, eléctrico o no, etcétera. Manteniendo las características esenciales del modelo.
Líneas de productos de software
Según el Instituto de Ingeniería de Software (SEI) una LPS se define de la siguiente manera: “Una LPS es un conjunto de sistemas de software compartiendo características comunes y administradas que satisface las necesidades específicas de un segmento de mercado particular o misión y que
son desarrolladas de forma preescrita a partir de un conjunto común de elementos clave”. Como lo indica la definición, una LPS consiste en un conjunto de elementos clave para producir sistemas de software que comparten características comunes (llamadas similitudes), pero al mismo tiempo mantienen características propias (llamada variabilidad). Para proporcionar estas características individuales a cada miembro de la familia, la adaptación masiva debe ser lo suficientemente flexible para satisfacer tal necesidad, pues además el número distinto de miembros está limitado a una serie de
restricciones las cuales también deben satisfacerse; a esto se le llama administración de la variabilidad.
Fases o etapas para implementar una LPS
En una LPS se propicia una reutilización a alto nivel, desarrollando los elementos comunes que servirán como base para la generación de cada miembro de la familia. Las etapas esenciales a ejecutar
son tres:
1. De ingeniería de dominios en la cual se desarrollan los elementos
comunes.
2. De ingeniería de aplicaciones donde se generan los sistemas que
son miembros de la familia. Dichos miembros se generan a partir
de los elementos comunes, pero tomando en cuenta el modelo de
variabilidad definido.
3. Un conjunto de actividades que orquestarán las dos etapas anteriores.
Es decir, se necesita de un proceso para ejecutar de manera ordenada la ingeniería de dominios y la ingeniería de aplicaciones.
Las dos primeras etapas están compuestas por las fases tradicionales del modelo de cascada (Requerimientos, Diseño, Implementación, Pruebas) pero con objetivos distintos como ya se mencionó.
Enfoques de adopción de una LPS
Se han planteado varios enfoques como estrategia para realizar la adopción de una LPS, entre ellos algunos tienen nombre distinto de acuerdo al “framework” o metodología en la que están contenidos, pero consisten en la misma estrategia. Básicamente, existen tres enfoques de adopción los cuales han sido reportados bajo otros nombres, sin embargo, en esencia son lo mismo. Dischos enfoques son:
Proactivo: funciona cuando la implantación de la LPS se hace desde cero, es decir que aún no se cuenta con sistemas de software que pertenecerán a la familia. Debido a la complejidad y al enorme esfuerzo que demanda este enfoque, es apropiado para las empresas que tienen una visión muy clara de los productos que conformarán la familia, además de que tienen niveles de madurez para predecir con gran certeza tal proceso y cuentan con los recursos económicos y humanos suficientes para realizar la inversión.
Extractivo: inicia con la selección de uno o más sistemas ya existentes, que serán parte de la familia de productos; efectuando un tipo de ingeniería inversa para extraer los artefactos de software comunes para establecerlos como elementos comunes y modelar la variabilidad que existe entre ellos. Este enfoque es ad-hoc para organizaciones que quieren efectuar la transición de una manera rápida,
de desarrollar sistemas individuales a generar sistemas a partir de una LPS.
Reactivo: toma la esencia del proceso de espiral o iterativo para efectuar la transición poco a poco. Se realizan los pasos como en el enfoque proactivo, pero para cada ciclo o espiral, de esta manera se van eliminando riesgos y se va aclarando la visión de las similitudes y variabilidades de los productos que serán miembros de la familia. Es adecuado para organizaciones que mantienen planes de trabajo agresivos, que no pueden dedicar los recursos humanos suficientes para la adopción y sólo pueden disponer de un subconjunto de ellos.
Beneficios de una LPS
La implantación de una LPS no es una tarea sencilla, sino que requiere un gran esfuerzo y sobre todo una gran inversión para su éxito. Sin embargo, los beneficios obtenidos motivan a realizarlo. Los beneficios de un proyecto de mejora de procesos de software han sido presentados y documentados[2, 3] y se dice que el retorno de inversión va en un rango de 5:1 de costo-beneficio. En un caso de estudio de la empresa Cummins Engine Inc.[4] se adoptó una LPS después de haber realizado un proyecto de mejora de procesos; y reportan que la mejora de procesos por sí sola tuvo un radio de costo-beneficio entre 2:1 y 3:1; y la implantación de la LPS en adición a la mejora de procesos arrojó un costo-beneficio de 10:1. Lo cual muestra evidencia de que si un SPI vale la pena, una LPS vale aún más.
Existen muchos beneficios que una LPS puede proporcionar, destacando los siguientes entre los más relevantes:
• Obtención de las ganancias de una producción a gran escala.
Como se mencionó en la adaptación masiva, una LPS habilita a producir sistemas de software a partir de una plataforma de artefactos comunes de manera que los productos sólo necesiten ensamblarse en vez de ser desarrollados individualmente.
• Mejora la capacidad para el “Time-to-market”. Muchas veces las demandas del mercado exigen tener estrategias de mercadotecnia que implican tener productos o implementar ideas innovadoras
antes de cierta fecha. Bajo un esquema tradicional de desarrollo de sistemas individualmente, dichas estrategias son demasiado difíciles de ejecutar haciendo perder a una organización la oportunidad de crecer en un mercado cambiante, pues como se dice por ahí: “el que pega primero pega dos veces”. Con una LPS, una organización puede tomar el reto de establecer estrategias de mercadotecnia agresivas, ya que cuentan con la capacidad de generar productos de forma acelerada. En la figura 1
se muestra una gráfica que representa el tiempo de desarrollo de sistemas de software con y sin una LPS, donde el eje horizontal representa el número de sistemas distintos desarrollados ,y el eje vertical el tiempo de liberación en el mercado. Como se puede ver al inicio, el tiempo de desarrollo de la LPS hace que éste sea mucho mayor que el desarrollo de los primeros sistemas individuales ,debido a que primero se deben desarrollar los elementos comunes, sin embargo, conforme se empiezan a desarrollar más sistemas, el tiempo de liberación en una LPS se reduce radicalmente en comparación al desarrollo individual, lo cual demuestra que a un mediano plazo los beneficios serán mucho mayores; pues como se mencionó, una organización se puede comprometer a liberar cierto producto de su LPS en menos de la mitad del tiempo que le llevaría desarrollarlo individualmente.
• Reducción de costos de desarrollo. Con una LPS los costos de desarrollo de los sistemas miembros de la familia, están muy por debajo de los costos de desarrollo de sistemas individuales. Al igual que en el “time-to-market”, al inicio el desarrollo de los elementos comunes tiene mayor costo que desarrollar un sistema individualmente. No obstante, una vez obtenidos, el costo disminuye.
Se puede decir que la tasa de incremento en el costo acumulado es mucho menor en una LPS que en sistemas individuales.
• Mejora de la calidad de los productos. Desde que el desarrollo de los elementos comunes es similar al desarrollo de los artefactos para un sistema individual, dichos elementos son probados constantemente por cada producto generado, y por formar parte de todos los productos de la familia se puede decir que la calidad es más fácil y fielmente asegurada en todos ellos.
• Logro de las metas de reutilización de la organización. Dado que las LPS se basan en la reutilización de artefactos para un conjunto de sistemas, la reutilización planeada se obtiene al desarrollar la plataforma de elementos comunes.
• Reducción de la necesidad de contratar nuevo personal. Desde que el proceso de generación de los productos de software se automatiza cada vez más, la necesidad de contratar gente disminuye
debido a que dichos productos son generados cada vez con menos ingenieros de software, lo cual de alguna manera ayuda a disminuir los costos a la organización.
• Incremento de la satisfacción del cliente. Por varios de los beneficios mencionados anteriormente, los clientes y usuarios de los sistemas generados con la LPS obtienen productos de software de
mucha mayor calidad a precios mucho más bajos que los que obtendrían con un proveedor que no cuenta con una LPS. Existen otros beneficios no menos importantes, sin embargo los que
aquí se presentaron son los más significativos. Si se desea obtener
más información acerca de estos otros beneficios se recomienda
consultar el capítulo 2 en [4].
El método FODA
Desde antes de existir el concepto de LPS existía la herramienta de análisis de dominio (AD), que se enfoca en analizar los aspectos comunes de un dominio particular que podíría consistir de un conjunto
de sistemas relacionados. A partir de esto, surgieron muchos métodos de AD, siendo el método FODA (Feature-Oriented Domain Analysis) el que marcó una pauta en el desarrollo del AD, pues ha sido ampliamente utilizado para extraer las similitudes y variabilidades de un dominio. El principal objetivo de FODA es la identificación de características relevantes de sistemas de software que pertenecen a un dominio. Se dice que estas características son aspectos del dominio visibles al usuario final.
A pesar de que el método FODA está compuesto de tres fases, para las cuales hay una serie de actividades individuales [6], la más relevante es la del modelado de características, pues es la que definirá las similitudes y variabilidades implícitas en el dominio. Dicho modelo de características se define por medio de un árbol donde quedarán especificados los elementos comunes y variables del dominio.
Por ejemplo, en la figura 2 se muestra un árbol de características para una línea de automóviles donde se pueden ver las características comunes (como la transmisión y el caballaje) y las características variables. Las variables pueden ser opcionales y estar contenidas o no en un sistema particular del dominio (como es el caso del aire acondicionado). También puede haber características alternativas de las cuales sólo una se puede implementar en un sistema particular del dominio (por ejemplo: la transmisión puede ser manual o automática,pero no ambas). Además, dentro de un modelo de características se pueden incluir algunas reglas de composición las cuales definen algunas relaciones entre características opcionales y/o alternativas.
Existen principalmente dos tipos de ellas: la primera es donde la existencia de una implica o requiere la existencia de la otra; y la segunda es donde la existencia de una implica o requiere que no exista la otra (que sean mutuamente exclusivas). Para nuestro modelo de ejemplo en la figura, existe una regla donde la existencia de aire acondicionado requiere que el caballaje sea mayor a 100.
Conclusiones
En este artículo se dió un vistazo a los fundamentos sobre los que descansan las líneas de productos de software. Como se pudo ver, la misma complejidad del sofware hace que nuevos métodos sean desarrollados para mitigarla, como lo son las LPS. Pero además de intentar reducir la complejidad de
desarrollo de software, las LPS tienen otros beneficios significativos, como la disminución del costo de desarrollo, que motivan a las organizaciones a tomar el reto de invertir en la implantación de una LPS.
Referencias
[1]. Parnas, D.L. “On the Design and Development of Program Families”. IEEE Transactions on Software Engineering, SE-2:1-9, March 1976.
[2] Ferguson, P. et al. “Software Process Improvement Works!” (CMU/SEI-99- TR-027, ADA371804)”. Software Engineering Institute, November 1999.
[3] Goldenson, D. & Herbsleb, J. “After the Appraisal: A Systematic Survey of Process Improvement, its Benefits, and Factors that Influence Success (CMU/SEI-95-TR-009, ADA302225)”. Software Engineering Institute, August 1995.
[4] Clements, P. & Northrop, L. “Software Product Lines: Practices and Patterns”. Reading, MA: Addison-Wesley, 2002.
[5] Kang, K. et al. “Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical Report CMU/SEI-90-TR-21”. Software Engineering Institute, November 1990.
Acerca del Autor
Gilberto Grajales obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas (CIMAT) realizando investigación sobre Líneas de Productos de Software aplicado al área de Ingeniería de Requerimientos. Ha jugado distintos roles en proyectos de desarrollo de software. Actualmente labora en JPE Consultores donde se dedica a la consultoría, capacitación y mejora de procesos en Ingeniería de Software. Tiene un especial interés en las áreas de Ingeniería de Requerimientos y Calidad de Software. Puede ser contactado en gilberto@jpeconsultores.com
información en nuestras vidas. A lo largo de los años, nuevos métodos, técnicas y herramientas han sido creados para mitigar esta creciente complejidad de desarrollar software.Una de las técnicas que han surgido para mitigar dicha complejidad, es la reutilización, la cual consiste en desarrollar elementos de software que puedan utilizarse más de una vez con la mínima cantidad
de modificaciones, garantizando que al reutilizar un elemento de software libre de defectos, implicará que el sistema que lo utilice no tendrá problema alguno en lo que respecta a dicho elemento.
Tal fue el éxito de aplicar la reutilización, que ésta evolucionó de alguna manera hasta generar el concepto de “Líneas de Productos de Software” (LPS) –conocido también como Familias de Sistemas de Software– para el cual se conocen indicios desde los años 70 cuando Parnas mencionó los beneficios de tener una familia de sistemas compartiendo características entre ellos[1].
Adaptación de productos de forma masiva
Las LPS parten de las ideas de la producción en serie (como lo hizo Henry Ford), dando la capacidad a una organización de producir o generar (nótese que no se usa el término desarrollar) sistemas de software en forma masiva, satisfaciendo las demandas del mercado; entre otros beneficios significativos. La adaptación masiva consiste en la capacidad para generar productos que comparten en gran parte características comunes, pero también mantienen características propias de cada uno de ellos. Tomando como ejemplo una línea de productos de automóviles, se puede ver que para un modelo específico de auto se pueden fabricar unidades con características propias tales como el color,
el número de puertas, transmisión automática o estándar, eléctrico o no, etcétera. Manteniendo las características esenciales del modelo.
Líneas de productos de software
Según el Instituto de Ingeniería de Software (SEI) una LPS se define de la siguiente manera: “Una LPS es un conjunto de sistemas de software compartiendo características comunes y administradas que satisface las necesidades específicas de un segmento de mercado particular o misión y que
son desarrolladas de forma preescrita a partir de un conjunto común de elementos clave”. Como lo indica la definición, una LPS consiste en un conjunto de elementos clave para producir sistemas de software que comparten características comunes (llamadas similitudes), pero al mismo tiempo mantienen características propias (llamada variabilidad). Para proporcionar estas características individuales a cada miembro de la familia, la adaptación masiva debe ser lo suficientemente flexible para satisfacer tal necesidad, pues además el número distinto de miembros está limitado a una serie de
restricciones las cuales también deben satisfacerse; a esto se le llama administración de la variabilidad.
Fases o etapas para implementar una LPS
En una LPS se propicia una reutilización a alto nivel, desarrollando los elementos comunes que servirán como base para la generación de cada miembro de la familia. Las etapas esenciales a ejecutar
son tres:
1. De ingeniería de dominios en la cual se desarrollan los elementos
comunes.
2. De ingeniería de aplicaciones donde se generan los sistemas que
son miembros de la familia. Dichos miembros se generan a partir
de los elementos comunes, pero tomando en cuenta el modelo de
variabilidad definido.
3. Un conjunto de actividades que orquestarán las dos etapas anteriores.
Es decir, se necesita de un proceso para ejecutar de manera ordenada la ingeniería de dominios y la ingeniería de aplicaciones.
Las dos primeras etapas están compuestas por las fases tradicionales del modelo de cascada (Requerimientos, Diseño, Implementación, Pruebas) pero con objetivos distintos como ya se mencionó.
Enfoques de adopción de una LPS
Se han planteado varios enfoques como estrategia para realizar la adopción de una LPS, entre ellos algunos tienen nombre distinto de acuerdo al “framework” o metodología en la que están contenidos, pero consisten en la misma estrategia. Básicamente, existen tres enfoques de adopción los cuales han sido reportados bajo otros nombres, sin embargo, en esencia son lo mismo. Dischos enfoques son:
Proactivo: funciona cuando la implantación de la LPS se hace desde cero, es decir que aún no se cuenta con sistemas de software que pertenecerán a la familia. Debido a la complejidad y al enorme esfuerzo que demanda este enfoque, es apropiado para las empresas que tienen una visión muy clara de los productos que conformarán la familia, además de que tienen niveles de madurez para predecir con gran certeza tal proceso y cuentan con los recursos económicos y humanos suficientes para realizar la inversión.
Extractivo: inicia con la selección de uno o más sistemas ya existentes, que serán parte de la familia de productos; efectuando un tipo de ingeniería inversa para extraer los artefactos de software comunes para establecerlos como elementos comunes y modelar la variabilidad que existe entre ellos. Este enfoque es ad-hoc para organizaciones que quieren efectuar la transición de una manera rápida,
de desarrollar sistemas individuales a generar sistemas a partir de una LPS.
Reactivo: toma la esencia del proceso de espiral o iterativo para efectuar la transición poco a poco. Se realizan los pasos como en el enfoque proactivo, pero para cada ciclo o espiral, de esta manera se van eliminando riesgos y se va aclarando la visión de las similitudes y variabilidades de los productos que serán miembros de la familia. Es adecuado para organizaciones que mantienen planes de trabajo agresivos, que no pueden dedicar los recursos humanos suficientes para la adopción y sólo pueden disponer de un subconjunto de ellos.
Beneficios de una LPS
La implantación de una LPS no es una tarea sencilla, sino que requiere un gran esfuerzo y sobre todo una gran inversión para su éxito. Sin embargo, los beneficios obtenidos motivan a realizarlo. Los beneficios de un proyecto de mejora de procesos de software han sido presentados y documentados[2, 3] y se dice que el retorno de inversión va en un rango de 5:1 de costo-beneficio. En un caso de estudio de la empresa Cummins Engine Inc.[4] se adoptó una LPS después de haber realizado un proyecto de mejora de procesos; y reportan que la mejora de procesos por sí sola tuvo un radio de costo-beneficio entre 2:1 y 3:1; y la implantación de la LPS en adición a la mejora de procesos arrojó un costo-beneficio de 10:1. Lo cual muestra evidencia de que si un SPI vale la pena, una LPS vale aún más.
Existen muchos beneficios que una LPS puede proporcionar, destacando los siguientes entre los más relevantes:
• Obtención de las ganancias de una producción a gran escala.
Como se mencionó en la adaptación masiva, una LPS habilita a producir sistemas de software a partir de una plataforma de artefactos comunes de manera que los productos sólo necesiten ensamblarse en vez de ser desarrollados individualmente.
• Mejora la capacidad para el “Time-to-market”. Muchas veces las demandas del mercado exigen tener estrategias de mercadotecnia que implican tener productos o implementar ideas innovadoras
antes de cierta fecha. Bajo un esquema tradicional de desarrollo de sistemas individualmente, dichas estrategias son demasiado difíciles de ejecutar haciendo perder a una organización la oportunidad de crecer en un mercado cambiante, pues como se dice por ahí: “el que pega primero pega dos veces”. Con una LPS, una organización puede tomar el reto de establecer estrategias de mercadotecnia agresivas, ya que cuentan con la capacidad de generar productos de forma acelerada. En la figura 1
se muestra una gráfica que representa el tiempo de desarrollo de sistemas de software con y sin una LPS, donde el eje horizontal representa el número de sistemas distintos desarrollados ,y el eje vertical el tiempo de liberación en el mercado. Como se puede ver al inicio, el tiempo de desarrollo de la LPS hace que éste sea mucho mayor que el desarrollo de los primeros sistemas individuales ,debido a que primero se deben desarrollar los elementos comunes, sin embargo, conforme se empiezan a desarrollar más sistemas, el tiempo de liberación en una LPS se reduce radicalmente en comparación al desarrollo individual, lo cual demuestra que a un mediano plazo los beneficios serán mucho mayores; pues como se mencionó, una organización se puede comprometer a liberar cierto producto de su LPS en menos de la mitad del tiempo que le llevaría desarrollarlo individualmente.
• Reducción de costos de desarrollo. Con una LPS los costos de desarrollo de los sistemas miembros de la familia, están muy por debajo de los costos de desarrollo de sistemas individuales. Al igual que en el “time-to-market”, al inicio el desarrollo de los elementos comunes tiene mayor costo que desarrollar un sistema individualmente. No obstante, una vez obtenidos, el costo disminuye.
Se puede decir que la tasa de incremento en el costo acumulado es mucho menor en una LPS que en sistemas individuales.
• Mejora de la calidad de los productos. Desde que el desarrollo de los elementos comunes es similar al desarrollo de los artefactos para un sistema individual, dichos elementos son probados constantemente por cada producto generado, y por formar parte de todos los productos de la familia se puede decir que la calidad es más fácil y fielmente asegurada en todos ellos.
• Logro de las metas de reutilización de la organización. Dado que las LPS se basan en la reutilización de artefactos para un conjunto de sistemas, la reutilización planeada se obtiene al desarrollar la plataforma de elementos comunes.
• Reducción de la necesidad de contratar nuevo personal. Desde que el proceso de generación de los productos de software se automatiza cada vez más, la necesidad de contratar gente disminuye
debido a que dichos productos son generados cada vez con menos ingenieros de software, lo cual de alguna manera ayuda a disminuir los costos a la organización.
• Incremento de la satisfacción del cliente. Por varios de los beneficios mencionados anteriormente, los clientes y usuarios de los sistemas generados con la LPS obtienen productos de software de
mucha mayor calidad a precios mucho más bajos que los que obtendrían con un proveedor que no cuenta con una LPS. Existen otros beneficios no menos importantes, sin embargo los que
aquí se presentaron son los más significativos. Si se desea obtener
más información acerca de estos otros beneficios se recomienda
consultar el capítulo 2 en [4].
El método FODA
Desde antes de existir el concepto de LPS existía la herramienta de análisis de dominio (AD), que se enfoca en analizar los aspectos comunes de un dominio particular que podíría consistir de un conjunto
de sistemas relacionados. A partir de esto, surgieron muchos métodos de AD, siendo el método FODA (Feature-Oriented Domain Analysis) el que marcó una pauta en el desarrollo del AD, pues ha sido ampliamente utilizado para extraer las similitudes y variabilidades de un dominio. El principal objetivo de FODA es la identificación de características relevantes de sistemas de software que pertenecen a un dominio. Se dice que estas características son aspectos del dominio visibles al usuario final.
A pesar de que el método FODA está compuesto de tres fases, para las cuales hay una serie de actividades individuales [6], la más relevante es la del modelado de características, pues es la que definirá las similitudes y variabilidades implícitas en el dominio. Dicho modelo de características se define por medio de un árbol donde quedarán especificados los elementos comunes y variables del dominio.
Por ejemplo, en la figura 2 se muestra un árbol de características para una línea de automóviles donde se pueden ver las características comunes (como la transmisión y el caballaje) y las características variables. Las variables pueden ser opcionales y estar contenidas o no en un sistema particular del dominio (como es el caso del aire acondicionado). También puede haber características alternativas de las cuales sólo una se puede implementar en un sistema particular del dominio (por ejemplo: la transmisión puede ser manual o automática,pero no ambas). Además, dentro de un modelo de características se pueden incluir algunas reglas de composición las cuales definen algunas relaciones entre características opcionales y/o alternativas.
Existen principalmente dos tipos de ellas: la primera es donde la existencia de una implica o requiere la existencia de la otra; y la segunda es donde la existencia de una implica o requiere que no exista la otra (que sean mutuamente exclusivas). Para nuestro modelo de ejemplo en la figura, existe una regla donde la existencia de aire acondicionado requiere que el caballaje sea mayor a 100.
Conclusiones
En este artículo se dió un vistazo a los fundamentos sobre los que descansan las líneas de productos de software. Como se pudo ver, la misma complejidad del sofware hace que nuevos métodos sean desarrollados para mitigarla, como lo son las LPS. Pero además de intentar reducir la complejidad de
desarrollo de software, las LPS tienen otros beneficios significativos, como la disminución del costo de desarrollo, que motivan a las organizaciones a tomar el reto de invertir en la implantación de una LPS.
Referencias
[1]. Parnas, D.L. “On the Design and Development of Program Families”. IEEE Transactions on Software Engineering, SE-2:1-9, March 1976.
[2] Ferguson, P. et al. “Software Process Improvement Works!” (CMU/SEI-99- TR-027, ADA371804)”. Software Engineering Institute, November 1999.
[3] Goldenson, D. & Herbsleb, J. “After the Appraisal: A Systematic Survey of Process Improvement, its Benefits, and Factors that Influence Success (CMU/SEI-95-TR-009, ADA302225)”. Software Engineering Institute, August 1995.
[4] Clements, P. & Northrop, L. “Software Product Lines: Practices and Patterns”. Reading, MA: Addison-Wesley, 2002.
[5] Kang, K. et al. “Feature-Oriented Domain Analysis (FODA) Feasibility Study, Technical Report CMU/SEI-90-TR-21”. Software Engineering Institute, November 1990.
Acerca del Autor
Gilberto Grajales obtuvo el grado de Maestro en Ingeniería de Software en el Centro de Investigación en Matemáticas (CIMAT) realizando investigación sobre Líneas de Productos de Software aplicado al área de Ingeniería de Requerimientos. Ha jugado distintos roles en proyectos de desarrollo de software. Actualmente labora en JPE Consultores donde se dedica a la consultoría, capacitación y mejora de procesos en Ingeniería de Software. Tiene un especial interés en las áreas de Ingeniería de Requerimientos y Calidad de Software. Puede ser contactado en gilberto@jpeconsultores.com
- Log in to post comments