Columna Vertebral del Software, Una Metodología de Desarrollo

Fourth LACCEI International Latin American and Caribbean Conference for Engineering and Technology (LACCET’2006)
“Breaking Frontiers and Barriers in Engineering: Education, Research and Practice”
21-23 June 2006, Mayagüez, Puerto Rico.
Columna Vertebral del Software, Una Metodología de Desarrollo Para PyMES
Irene Pérez
Maestra de Cátedra, ITESM Campus Chihuahua, México, [email protected]
Rodolfo Castelló
Director de la Escuela de Ingeniería, ITESM Campus Chihuahua, México, [email protected]
Resumen
Las Pequeñas y Medianas Empresas (PyMES) dedicadas al desarrollo de software o que cuentan con un
área o unidad de negocio dedicadas a ello, están generando una parte significativa del software utilizado en
México y en el mundo. Sin embargo, carecen de una metodología de desarrollo de software adecuada a sus
necesidades y sus recursos, ya que las metodologías existentes y sus marcos de trabajo difícilmente son
adaptados; y en casos extremos, ni siquiera son utilizados.
El presente trabajo tiene como objetivo presentar una metodología de desarrollo de software y un marco de
trabajo pensado en las PyMES; ya que este tipo de empresas son especialmente sensibles al mal uso de los
recursos, por lo que es importante que puedan contar con herramientas que les permitan administrar el
proceso productivo y les ayuden a controlar la calidad del software que desarrollan.
Palabras Clave
Ingeniería de Software, Metodología de Desarrollo de Software, PyMES.
1. Introducción
Actualmente en Estados Unidos más del 70% de las compañías dedicadas al desarrollo de software se
consideran empresas medianas o pequeñas -llamadas PyMES- (Brodman 1994, Fayad 2000); mientras que
en México, representan aproximadamente el 80% de las organizaciones del país (Silva 2004). Sin embargo,
la importancia de las PyMES no solo radica en que son mayoría numérica, sino en que están generando una
cantidad realmente significativa de los productos de software del mercado (Fayad y otros 2000); ya que rara
vez el tamaño de la empresa está relacionado con la complejidad o con las características del software que
pueda llegar a producir.
A pesar de su relevancia, las PyMES tienen un problema en común: las metodologías de desarrollo de
software y los modelos para la implantación de sistemas de calidad, en la mayoría, no están adecuados para
pequeñas y medianas empresas ya que no son fáciles de adaptar; o bien, se dificulta su implantación debido
a la cantidad de recursos con los que una organización de este tamaño cuenta (Fayad y otros 2000, Brouse
1999, Reifer 2003).
Obtener la certificación de un sistema de calidad reconocido como CMM o ISO 9000:2000 proporciona a
las empresas la oportunidad de competir en el mercado por un contrato (Brouse 1999); pero el proceso es
costoso, tanto que por lo general excede los recursos económicos de las PyMES y satura al capital humano
con el que cuentan. Algunos autores sugieren que este tipo de empresas implementen procedimientos de
calidad que resultan más sencillos o bien que lo hagan parcialmente (Widera 2000, Reifer 2003, Silva 2004,
Brouse 1999).
¿Pero que pasa cuando una empresa PyME desarrolla para clientes internos?, ¿le resulta redituable la
inversión de una certificación de calidad?, ¿debe tener un sistema de calidad y utilizar una metodología de
desarrollo a pesar del costo que ello implica? La respuesta que se le da a estas preguntas, es que se debe
implementar un sistema de calidad para reducir la cantidad de retrabajo, generar costos más bajos y mejorar
el tiempo de entrega (Presuman 1992); aunque no necesariamente buscando obtener una certificación de un
sistema de calidad internacional.
Este artículo tiene como objetivo presentar una metodología de desarrollo de software y marco de trabajo
para PyMES que desarrollan software para clientes internos, y cuyo principal interés para adoptar un
sistema de calidad está relacionado con el control del proceso de desarrollo y no con el de competir por
contratos o abrir nuevos mercados, ya que para ellos la calidad del software tiene mayor importancia que la
velocidad a la que tiene que ser desarrollado.
La Sección Metodología Columna Vertebral del Software presenta la explicación de la metodología
propuesta para PyMES. En la Sección Marco de Trabajo se explica como aplicar la metodología.
Posteriormente, en la Sección Aplicación se describe un caso práctico. Por último, en la Sección
Conclusiones se exponen los resultados obtenidos, así como los Trabajo Futuros relacionados con la
investigación que se presenta.
2. Metodología Columna Vertebral del Software (CVS)
La metodología de desarrollo de software Columna Vertebral del Software (CVS) lleva ese nombre debido
a que se enfoca a establecer y documentar la estructura funcional de los desarrollos de software. Intenta
rescatar la estructura robusta que genera la metodología de Cascada al analizar el problema como un
conjunto global; y toma de la metodología XP la idea de mantener una retroalimentación constante con el
usuario, pues tal como lo define Kent Beck (Beck 1999), los retrasos en la información de los cambios en
los requerimientos impactan directamente tanto en la efectividad como en el costo del software.
La idea de generar un sistema de información es una alternativa “poderosa, fácil y económica” (Meadows
2000) para aquellas empresas que debido a lo limitado de los recursos económicos no pueden crear y
mantener una infraestructura física.
Figura 1. Metodología Columna Vertebral del Software (CVS)
En la Figura 1 se puede apreciar que la metodología CVS inicia con un problema del mundo real que debe
ser resuelto. Después de un análisis global, se identifican los principales módulos que componen la
aplicación y sus interrelaciones, así como también las posibles relaciones con otras aplicaciones de software
existentes.
Una vez identificados los principales módulos y sus relaciones, se empieza a trabajar con cada uno de ellos
de manera individual. El diseño y desarrollo de la aplicación de software se realiza por módulos, siguiendo
una prioridad previamente establecida. El programador deberá solicitar retroalimentación al cliente, durante
y después del desarrollo de cada módulo, y siempre que exista una duda. El objetivo es asegurarse que la
solución que se está construyendo resolverá el problema en cuestión y cumplirá con los requerimientos
emergentes relacionados.
Cabe mencionar que la definición de cada módulo está directamente relacionada con el paradigma de
programación que se utilice en el proceso de desarrollo de software y la arquitectura sobre la cual se realicen
los desarrollos.
Si durante el proceso cíclico de retroalimentación se detecta la necesidad de cambiar las interrelaciones
previamente establecidas, el sistema de información permite evaluar su impacto utilizando la información ya
almacenada (Cheng 1995). Si la modificación se realiza, ésta deberá verse reflejada en el sistema de
información de la CVS. Este procedimiento de verificación se debe realizar tanto para software en proceso
de desarrollo, como para cualquier mantenimiento. El proceso de desarrollo de software termina cuando se
construye el último módulo.
El sistema de información que se genera ayuda a entender el funcionamiento de la aplicación desarrollada lo
que facilitará su mantenimiento y la capacitación de nuevos integrantes del equipo de trabajo. Permitirá al
administrador planear futuros desarrollos dando prioridad a los proyectos que puedan llegar a tener mayor
impacto en la empresa. Además, le facilitará la visualización de las necesidades de capacitación y
entrenamiento del personal en base a la planeación proyectada.
La documentación que se genere en cada etapa, las herramientas a utilizar para diseñar, evaluar o
implementar un módulo, deben ser definidas a través de estándares de la compañía y los requerimientos del
cliente. Para que la empresa PyME obtenga un producto de software, y no solo un programa ejecutable al
cual difícilmente se le podrá dar mantenimiento, debe considerar sus requerimientos con la misma
importancia que los requerimientos de sus clientes internos.
3. Marco de Trabajo
La aplicación de la metodología se realiza bajo la consideración de que la mayoría de los departamentos o
PyMES dedicados al desarrollo de software para clientes internos, se encuentran formados por rango de uno
a cinco integrantes. Por lo que es muy probable que el proceso de desarrollo de software, desde el análisis
hasta la implantación, sea realizado por una misma persona que jugará varios roles.
La importancia de identificar cada rol de manera independiente tiene como objetivo evitar que se esquiven
las responsabilidades que cada uno conlleva. Los principales roles identificados para la implantación de la
metodología CVS se describen a continuación:
 Cliente o usuario: Persona o personas que requieren el desarrollo o modificación de algún producto de
software; o bien, solo utilizan una aplicación para realizar de manera más eficiente sus actividades.
 Cliente Intradepartamental: Representa las necesidades de la empresa, como: documentación, medibles,
código fuente, entre otros.
 Ingeniero de Software: También denominado programador, es la persona o personas asignadas al
desarrollo del producto de software.
 Auditor: Persona o equipo de trabajo encargado de verificar la calidad de la aplicación de software antes
de ser liberada.
 Supervisor: Persona encargada de la administración del área de desarrollo, departamento o PyME.
Los procesos clave para las metodologías del desarrollo de software son las actividades a las que se les
denomina el ciclo de vida del software (Sommerville 2002). Debido a que los paradigmas de desarrollo de
software y las plataformas utilizadas para cada aplicación generan una gama impresionante de posibilidades,
dentro del marco de trabajo solo se establecen los puntos básicos de cada actividad, sin establecer el cómo
realizarlos para permitir que cada empresa los adapte a sus necesidades.
3.1. Análisis De Requerimientos
Es común que las áreas de desarrollo o empresas que desarrollan aplicaciones para clientes internos se vean
saturadas de solicitudes debido a que no existe un costo directo que se deba pagar por el servicio.
Como primer paso el Supervisor realiza un análisis de factibilidad del proyecto requerido; si se trata de una
solicitud viable, el Ingeniero de Software realiza un análisis global para poder estimar un tiempo de entrega
que se le notificará al Cliente conforme al plan de trabajo establecido. En caso de no considerarse viable, se
debe notificar la razón al Cliente y se da por terminado el proyecto.
En relación a la estimación y definición de tiempos de entrega, se recomienda generar una tabla de
clasificación para los productos de software; puede ser en base a la complejidad, tamaño de la aplicación,
plataforma, etc., según lo considere la empresa. La clasificación junto con la información histórica del
tiempo planeado, el tiempo real y los recursos utilizados de cada proyecto desarrollado permitirán a la
empresa crear un registro histórico para evaluar su desempeño, realizar estimaciones para proyectos futuros,
y medir el impacto de algún cambio realizado en el proceso o producto.
El compromiso creado con los Clientes a través del establecimiento de una fecha de entrega, es un intento
por evitar que una solicitud de software se convierta en un proyecto sin fin por su constante crecimiento.
Tomando en consideración que las PyMES o áreas de desarrollo tienen varios Clientes a los que se les da el
servicio, es mejor alcanzar la meta establecida inicialmente en la solicitud del Cliente, y negociar una
segunda etapa para el proyecto cuando se trate de cambios significativos.
3.2. Diseño
Se sugiere que el sistema de información de la CVS maneje dos niveles de abstracción. El primero donde se
permita conocer la relación entre aplicaciones, y el segundo, que permita conocer los módulos que la forman
y sus interconexiones.
Una vez iniciado el proyecto, la licitación de requerimientos funcionales y no funcionales junto con el
diseño, se volverán actividades iterativas entre Cliente e Ingeniero de software que perdurará a lo largo del
desarrollo. Es importante recordar que durante esta etapa se debe de estar generando, consultando o
modificando el sistema de información de la metodología CVS.
3.3. Implantación
La metodología recomienda que el Ingeniero de Software realice la implantación por módulo, ya que en
caso de que alguno necesite rediseñarse, se afectará solo a aquéllos módulos con los que éste esté
relacionado, reduciendo el impacto en el sistema global.
Comunmente el programador realiza las pruebas a cada módulo que está desarrollando. Se recomienda
utilizar como base la información de la CVS para conocer las interrelaciones de ese módulo, así como
documentar en el sistema las pruebas realizadas y los resultados obtenidos.
Cuando el Ingeniero de Software considere que el módulo se encuentra terminado, se debe solicitar la
retroalimentación del Cliente. Si existe algún cambio solicitado que afecte la estructura del producto de
software en desarrollo, se debe utilizar el sistema de información de la CVS para evaluar el impacto a nivel
global, y registrar las modificaciones realizadas.
La evaluación del código por módulo ayuda a que se pierda la perspectiva global y no se analice el impacto
de unos módulos sobre otros; o bien de la aplicación terminada sobre otras ya existentes. Es por ello, que no
se debe eludir la etapa de pruebas al terminar la programación del último módulo.
3.4. Pruebas y Liberación
Esta actividad dentro de la metodología CVS, es ejecutada parcialmente por el Cliente, el Ingeniero de
Software, el Auditor, y el Supervisor. La evaluación del Cliente se obtiene durante el proceso de desarrollo
a través de la retroalimentación por módulos. Además se sugiere una encuesta de salida que pueda
cuantificar la percepción cualitativa del cliente. La naturaleza del producto de software desarrollado
indicará cuanto tiempo después de ser liberada una aplicación deberá de ser aplicada la encuesta. Las
preguntas incluidas en ella estarán en función de los medibles que la empresa quiera controlar.
El Ingeniero de Software realizó pruebas a cada uno de los módulos desarollados, pero el Auditor será el
encargado ahora de realizar una evaluación global. En caso de que una misma persona juegue ambos roles,
debe considerar que será doblemente responsable en caso de liberar un producto de software con errores.
En el caso de aplicación se utilizó una adecuación del método conocido como Cuarto Limpio (Presuman
1992). A través de este método se pueden reducir el número de pruebas que se realizan al producto de
software, y en lugar de tener un árbol de pruebas con crecimiento exponencial, se llevan a cabo solo un
porcentaje de las pruebas considerando evaluar más a los módulos que tienen mayor probabilidad de ser
utilizados. Cabe recordar que cada uno de los módulos ya fue evaluado de manera independiente. Los
resultados obtenidos de cada prueba estarán en función de los datos registrados durante su ejecución.
Como parte de la mejora continua, el porcentaje de pruebas a realizar a nivel global puede irse reduciendo
en función del número de productos de software que se aprueben sin haberse detectado ningún error o
inconsistencia.
Por último, el Supervisor tiene que evaluar el cumplimiento de los requerimientos del Cliente
Intradepartamental con la misma importancia con la que consideramos los requerimientos del Cliente. Tiene
que verificar el cumplimiento del proceso de desarrollo utilizado y auditar que el producto de software
cumple con los requisitos establecidos por la empresa. De igual forma deberá realizar las acciones
correctivas para que el proceso productivo se encamine a los estándares previamente definidos, utilizando
como base los medibles que cada software desarrollado genere.
Se recomienda ampliamente que dentro de los requisitos establecidos por el Cliente Intradepartamental, se
especifique la documentación con la que cada producto de software debe contar además del sistema de
información que se genera con la metodología CVS. Lo anterior obedece a que a pesar de que la
documentación “no está relacionada con la calidad del software producido, si lo está con la velocidad en la
que se realiza el mantenimiento” (Forward y Lethbridge 2002).
3.5. Mantenimiento
Es común que los productos de software desarrollados requieran nuevas modificaciones, debido a que
vivimos en un mundo competitivo y cambiante. En este caso, la PyME contará con documentación y un
sistema de información para evaluar el impacto de los cambios. Sin embargo, cuando el cambio solicitado
tiene como origen algún error en el código o en la funcionalidad de la aplicación desarrollada, es un foco de
alerta que indica que el procedimiento establecido no se está siguiendo o no está funcionando, por lo que el
Supervisor deberá tomar acciones para identificar el origen del problema y establecer las medidas
correctivas correspondientes.
3.6. Proceso de Mejora Continua
Un Proceso de Mejora Continua (CI, de sus siglas en inglés Continuous Improvement), más que un sistema
de calidad, es “una filosofía de administración que afronta el reto de mejorar los procesos y los productos
como un proceso de mejora sin fin, en el cual se logran obtener pequeñas ganancias cada vez” (Chase 1992).
Es por ello que un sistema de calidad exitoso requiere que la gerencia tenga una visión definida sobre la
empresa y un firme grado de compromiso.
Si la gerencia de la PyME está dispuesta a aceptar el reto, durante la explicación de la metodología CVS y
su marco de trabajo se describe algunos de los puntos de revisión para aplicar el proceso de CI; pero no son
los únicos, realmente cada paso del proceso es materia prima para realizar alguna mejora. Adicionalmente,
para aumentar el éxito de la implantación de un CI en PyMES, Brouse y Buys (Brouse 1999) sugieren la
aplicación de las algunas técnicas que pueden ser consultadas en su artículo.
4. Aplicación
El Instituto Tecnológico y de Estudios Superiores de Monterrey (ITESM) es una empresa sin fines de lucro
cuyo giro es la educación a nivel medio superior, superior y postgrado. Tiene varios campi instalados a lo
largo de la República Mexicana, pero la aplicación de la metodología CVS se limitó al departamento de
Informática del Campus Chihuahua.
El área de desarrollo cuenta con dos integrantes, uno funge como director del área y se encarga de
administrar los proyectos requeridos, y ambos tienen la función de desarrollo de software.
Se le considera una de las áreas más críticas del departamento de Informática debido a que las curvas de
aprendizaje son muy largas. Su función consiste en proporcionar servicios a alumnos, profesores y personal
administrativo, a través del desarrollo de sistemas que faciliten la operación y que de preferencia generen un
valor agregado al servicio que presta el ITESM.
Actualmente se tienen dieciséis sistemas corriendo, desarrollados en los siguientes lenguajes de
programación: PHP, JSP, Visual Fox Pro y Delphi. Las plataformas para los que fueron desarrollados son
principalmente Windows NT y UNIX, las bases de datos que utilizan son ORACLE y MySQL. En general
son aplicaciones WEB, multiplataforma, con BD distribuidas.
Los principales actores dentro del proceso de desarrollo de software son los Clientes y usuarios, la Empresa,
y los Ingenieros de Software (Sommerville 2002). Es por ello que el resumen que sobre la aplicación de la
metodología y su marco de trabajo se describe a continuación, utiliza como punto de referencia a cada uno
de estos actores.
4.1. Empresa
Como primer paso se definen claramente los objetivos que se desean alcanzar, se establecieron los
estándares y medibles que serán utilizados para este caso de aplicación. Uno de los principales
inconvenientes encontrados fue que no se tiene ninguna información histórica en la cual basarnos para la
definición de los estándares, por lo que se consideró como punto de partida lo establecido por la ingeniería
de software en diferentes fuentes bibliográficas.
Parte de los estándares y medibles se establecieron de manera colaborativa, otros simplemente fueron
definidos por el Supervisor. Adicionalmente, se aprovecharon aquellos estándares de facto que ya existían y
que no se contraponen con los objetivos establecidos.
Como era de esperarse, se requirió reestructurar algunas de las actividades que hacían dentro de su proceso
de desarrollo de software. Una de las más relevantes es la manera en la que se realizan las peticiones de los
Clientes internos para nuevos proyectos o mantenimiento a las aplicaciones ya existentes.
Con este fin se diseñó un formato para solicitar el servicio, donde se da una breve descripción de los
requerimientos; además el Cliente mismo ayuda a determinar el impacto de su petición en la empresa y la
urgencia con la que debe ser atendida. En caso de que el proyecto solicitado se considere factible, los datos
de la requisición ayudarán a la planeación de los proyectos y a la asignación de los recursos del área.
Además del sistema de información creado por la metodología CVS, donde se puede apreciar el impacto
que tendría en los sistemas ya desarrollados.
Otra actividad que se adicionó al proceso, queda a cargo del Supervisor, quién tendrá que realizar una
revisión periódica del cumplimiento y mejora de los estándares a través de los medibles dentro del proceso
de CI. Qué aunque efectivamente no proporciona un valor agregado al proceso en sí, permite llevar un
control sobre éste, lo que la convierte en una actividad requerida que debe tratar de optimizarse.
4.2. Ingeniero de Software
El punto de partida en este nivel fue la selección de un proyecto de software para la aplicación de la
metodología CVS y la definición del responsable de su desarrollo. También se definieron las herramientas a
utilizar en cada etapa del ciclo de vida de software considerando el paradigma de programación empleado y
la plataforma tecnológica.
Una ventaja encontrada en este caso de estudio, es que a pesar de que no se aplicaba ninguna metodología
de desarrollo en el área, el Ingeniero de Software por su formación académica requirió muy poco
entrenamiento. A pesar de que algunas de las herramientas propuestas le eran desconocidas y otras no estaba
acostumbrado a utilizarlas; su entendimiento y asimilación se dieron rápidamente.
Inicialmente fue difícil romper con la resistencia al cambio, pero uno de los factores que más ayudó a
lograrlo fue resaltar los beneficios que el uso de la metodología CVS le proporciona de manera directa al
Ingeniero de Software.
Agraciada o desgraciadamente, durante la implementación se dieron dos casos de rotación de personal en el
área, permitiendo sensibilizar de manera practica y no solamente teórica al personal sobre las consecuencias
que se padecen al no utilizar una metodología de desarrollo de software.
Durante todo el proceso se le dió seguimiento al avance y se reforzaron el qué y el cómo se deben llevar a
cabo cada una de las actividades. La inercia es una importante fuerza que se debe combatir con
entrenamiento y reforzando los objetivos que se desean alcanzar.
La documentación que se generó durante cada etapa fue definida por la empresa, pero el objetivo es que sea
utilizada en beneficio del propio Ingeniero de Software. Los documentos que se generaron fueron:
 Manual de usuario, el cual contiene una descripción del funcionamiento de cada pantalla del sistema y
una sección con la respuesta a las preguntas más frecuentes que vayan surgiendo durante el tiempo de
vida del software. El documento se incluyó como parte de la aplicación desarrollada para que el Cliente
lo tenga disponible cada vez que lo requiera.
 Manual técnico, se compaginó con la documentación generada en cada etapa del proyecto, pero a
petición de los mismos Ingenieros de Software se agregó una sección con la respuesta de los Clientes a
las dudas que le surgieron al encargado del proyecto durante su elaboración.
Al finalizar el proyecto se calcularon los medibles, se definió el tiempo de seguimiento de aplicación, se
auditó que el proyecto fuera un producto de software que cumpliera con los requerimientos del Cliente y del
Cliente Intradepartamental. Posteriormente, será función del Supervisor evaluar los medibles obtenidos
contra los estándares establecidos, y definir cuales serán las acciones a realizar para continuar con el proceso
de CI.
Al momento de finalizar el proyecto, ya se tiene la información sobre los módulos, sus interrelaciones y las
relaciones que se mantienen con otras aplicaciones existentes. Esta información se convertirá en los datos
que conforman el sistema de información propuesto en la metodología CVS, el cual estará completo y será
útil solo si se mantiene actualizado cada vez que se realice un cambio o se generé un nuevo producto de
software.
Cabe mencionar que para esta empresa en particular, se requiere además un proceso de reingeniería que
permita incluir en el sistema de información a todos los productos de software que están siendo utilizados
dentro de la empresa en este momento y que fueron desarrollados con anterioridad. Particularidad con la que
la mayoría de las empresas PyMES se verán identificadas.
4.3. Cliente
Una de las ventajas de las PyMES es precisamente la cercanía física que se puede tener con los Clientes
internos, lo que facilita la comunicación con ellos. Por ello la metodología CVS hace uso de dicha ventaja y
sugiere que el proceso de retroalimentación se realice cada vez que sea requerido.
Esto implica que el Cliente debe invertir parte de su tiempo de trabajo para el desarrollo del producto de
software.
Información más detallada sobre la metodología CVS, su marco de trabajo y el caso práctico puede ser
encontrada en la Tesis Metodología para la Administración de Proyectos de Desarrollo de Software para las
PyMES (Pérez 2006).
5. Conclusiones
Para que un sistema de calidad prospere y mejore de manera continua, es elemental el apoyo pleno de la
gerencia del área, departamento o empresa. Además todas las personas involucradas deben ser capacitadas
no solo en las herramientas y técnicas que requieren utilizar para elaborar su trabajo, sino en la cultura de
hacer mejor y no solo de hacer más.
Para lograr que una empresa obtenga provecho de su sistema de calidad, éste debe estar explícitamente bajo
la supervisión de una persona que le pueda dar seguimiento, asegurarse que la empresa se acerque a la meta
que se propusieron; e incluso, tener la autoridad de llevar a cabo las acciones correctivas que se requieran.
Para lograr un cambio permanente debe llevarse a cabo un proceso continuo y constante.
Este trabajo es una propuesta para que se pueda hacer un mejor uso de los recursos de las PyMES cuyo giro
es el desarrollo de software para clientes internos. Deseo que surjan más investigaciones enfocadas a ayudar
a las PyMES, cuya tendencia en los últimos 30 años ha sido de crecimiento constante.
6. Trabajo Futuro
En base a la experiencia obtenida de la aplicación de la metodología, se listan algunos temas cuya
investigación podría mejorar la propuesta realizada en este artículo:
 La representación gráfica de las interrelaciones, a nivel módulos y a nivel aplicaciones de software.
Sería interesante, amigable e ilustrativo poder navegar entre diferentes niveles de abstracción.
 Generar un sistema de información automatizado y amigable para soportar la aplicación de la
metodología CVS y su marco de trabajo.
 La automatización de la captura de datos que permitan generar los medibles de calidad y su
comparación con los estándares establecidos por la compañía PyME. El trabajo realizado por
Subramanian y Chung (Subramanian y Chung 2001), así como la propuesta de Olsina y otros (Olsina
y otros 2000), son propuestas interesantes que podrían ser consideradas en este rubro.
7. Reconocimientos
A través de este medio quiero agradecer al ITESM campus Chihuahua por las facilidades prestadas para la
elaboración y la aplicación de la metodología CVS. Especialmente al Ingeniero Manuel Salais por su
paciencia y amplia cooperación.
Referencias.
Beck Kent, Embracing Change with Extreme Programming, Publicado por IEEE Multimedia, 1999,
páginas 70-77.
Brodman, J.G y Johnson, D.L., What small businesses and small organizations say about the CMM,
Publicado en The 16th IEEE International Conference, 1994, páginas 331-340.
Brouse, P.S. y Buys, R.T., Affordable ways to improve application development, Publicado por IT
Professional, 1999, páginas 47-52.
Chase Ricard B. y Aquilano Nicholas J., Production and Operations Management: a life cycle approach,
Editor Irwin, 1992.
Chung L., Requirements Engineering Processes, Computer Science Program, The University of Texas,
Dallas, 1997.
Fayad Mohamed E., Laitinen Mauri y Ward Robert P., Software Engineering in the Small, Publicado en
Comunications of the ACM, 2000, páginas 115-118.
Forward Andrew y Lethbridge Timothy C., The Relevance of Software Documentation, Tools and
Technologies: A Survey, Publicado en ACM, 2002, páginas 26-33.
Meadows Donella, Leverage Points Place to Intervene in a System, Disponible en Internet
http://www.wordlwatch.org. Accedida en Octubre 2004.
Olsina L.A., Merota M. F., Lafuente G. J., Martín M. A., Katrib M. y Vallecillo A. , Un Marco Conceptual
para la Definición y Explotación de Métricas de Calidad, Publicado ACM, 2000.
Pérez Blanco Irene E., Metodología para la Administración de Proyectos de Desarrollo de Software para
las PyMES, Tesis de Maestría del ITESM Campus Chihuahua, 2006.
Pressman Roger S., Software Engineering: a practiotioner´s approach, Editorial McGraw-Hill Inc., 1992.
Reifer J. Donald, XP and the CMM, Publicado por IEEE Journal, 2003, páginas 14-15.
Silva Alarcón Armando, Modelos de calidad. La industria del software en México, Disponible en Internet
http://www.enterate.unam.mx. Accedida en Octubre 2004.
Sommerville Ian, Ingeniería de Software, Editorial Addison Wesley, 2002.
Subramanian N. y Chung L., Metrics for Software Adaptability, Publicado por SQM 2001, 2001, páginas
95-108.
Widera John W., On Time with Quality No Excuses, principles and practices for small and midsize
corrugated container businesses, Editor Tucson Container Co and California Box Co, 2000.
Authorization and Disclaimer.
Authors authorize LACCEI to publish the papers in the conference proceedings. Neither LACCEI nor the
editors are responsible either for the content or for the implications of what is expressed in the paper.