UNIVERSIDAD DE COLIMA -...
137
UNIVERSIDAD DE COLIMA FACULTAD DE TELEMÁTICA MPMPES: Modelo de Procesos para Micro y Pequeñas Empresas Desarrolladoras de Software TESIS Que para obtener el grado de Maestría en Computación PRESENTA Emilio Damián Bueno Vélez ASESOR Dr. Nicandro Farías Mendoza COASESOR Dr. Víctor Hugo Castillo Topete Colima, Colima. Enero de 2012
Transcript of UNIVERSIDAD DE COLIMA -...
UNIVERSIDAD DE COLIMA FACULTAD DE TELEMÁTICA
MPMPES: Modelo de Procesos para Micro y Pequeñas
Empresas Desarrolladoras de Software
TESIS Que para obtener el grado de
Maestría en Computación
PRESENTA
Emilio Damián Bueno Vélez
ASESOR
Dr. Nicandro Farías Mendoza
COASESOR
Dr. Víctor Hugo Castillo Topete
Colima, Colima. Enero de 2012
RESUMEN
El presente trabajo muestra el desarrollo de un Modelo de Procesos para Micro y
Pequeñas Empresas Desarrolladoras de Software, que sirva de guía para
empresas de este tipo que sea fácil de entender, aplicar y económico de adaptar
y en consecuencia que asegure la calidad de los productos y servicios
generados por la organización.
Se delinea la problemática general de las micro y pequeñas empresas
desarrolladoras de software para aplicar algún estándar ó modelo, así como
estudios que demuestran el interés de adopción de estos en los procesos de las
micro y pequeñas empresas.
Se presenta un análisis de las metodologías tradicionales y su contraparte las
metodologías ágiles, puntualizando sus diferencias en funcionalidad y
características de negocio en las micro y gran empresas.
Por parte de las metodologías ágiles se muestra un análisis en base a procesos,
roles, prácticas y entorno de uso, que tiene como finalidad especificar las
diferencias entre las metodologías ágiles seleccionadas.
Finalmente se muestra el modelo para el desarrollo así como los niveles que lo
integran, descrito cada nivel a través de sus procesos, productos generados y
actividades de los mismos.
ABSTRACT
The present work shows the development of a Process model for Very Small
enterprises that Develop Software Components, which uses as guide for
companies of this type that is easy to deal, applying and economically of
adapting and in consequence that assures the quality of the products and
services generated by the organization.
There is delineated the general problematic of the very small enterprises that
develop software components to apply some standard or model, as well as
studies that demonstrate the interest of adoption of these in the processes of the
very small enterprises.
One presents an analysis of the traditional methodologies and his counterpart the
agile methodologies, specifying their differences in functionality and
characteristics of business in the very small and large companies.
On the part of the agile methodologies an analysis appears on the basis of
processes, roles, practices and environment of use, which has as purpose,
specify the differences between the agile selected methodologies.
Finally, we show the model for the development and the levels within it, each
level described through their processes, products and activities generated them.
ÍNDICE
CAPÍTULO I CONTEXTO DEL PROBLEMA 1.1 Introducción ................................................................................................ 2
1.2 Antecedentes del trabajo a investigar ......................................................... 3
1.3 Trabajos relacionados ................................................................................. 6
1.4 Descripción del problema a investigar ...................................................... 13
1.5 Justificación .............................................................................................. 14
1.6 Los objetivos que se persiguen ................................................................. 17
1.6.1 Objetivo general ................................................................................. 17
1.6.2 Objetivos específicos .......................................................................... 17
1.7 Hipótesis del trabajo .................................................................................. 18
1.8 Descripción de la organización del trabajo ................................................ 18
1.9 Metodología .............................................................................................. 23
CAPÍTULO II ESTADO DEL ARTE 2.1 Proyectos de software ............................................................................... 25
2.2 Factores de riesgo en el desarrollo de software ....................................... 26
2.3 Ingeniería de software ............................................................................... 29
2.4 Calidad de software .................................................................................. 31
2.5 Micro y pequeñas empresas ..................................................................... 38
2.6 Metodologías para desarrollo de software ................................................ 49
2.6.1 Modelo secuencial .............................................................................. 50
2.6.2 Modelos iterativos e incrementales .................................................... 51
2.6.3 Modelo en espiral ............................................................................... 53
2.7 Metodologías ágiles para desarrollo de software .......................................... 54
2.8 Análisis metodologías ágiles para desarrollo de software ......................... 66
2.8.1 eXtreme Programming (XP) ............................................................... 66
2.8.2 Scrum ................................................................................................. 75
ÍNDICE (continuación…)
2.8.3 Metodologías Crystal .......................................................................... 91
2.8.4 Método de desarrollo de sistemas dinámicos (DSDM) ....................... 95
CAPÍTULO III DESARROLLO DEL MODELO MPMPES 3.1 Modelo propuesto para el desarrollo ....................................................... 104
3.2 Gerencia (GER) ...................................................................................... 106
3.2.1 Gestión de negocio, proyectos y recursos ........................................ 106
3.3 Operación ............................................................................................... 117
3.3.1 Administración de proyectos (OPE.1) ............................................... 117
3.3.2 Desarrollo y mantenimiento de software (OPE.2) ............................. 119
CAPÍTULO IV CONCLUSIONES 4.1 Conclusiones .......................................................................................... 126
4.2 Trabajo Futuro ........................................................................................ 127
BIBLIOGRAFÍA ............................................................................................ 129
Índice de Figuras
Fig. 1. Principales estándares y modelos ........................................................... 6
Fig. 2. Modelo y metodologías ágiles a utilizar en MPMPES ............................ 20
Fig. 3. Niveles del modelo de procesos MoProSoft .......................................... 47
Fig. 4. Representación del modelo en cascada (Waterfall) ............................... 50
Fig. 5. Representación del modelo incremental ................................................ 51
Fig. 6. Representación del modelo iterativo ...................................................... 52
Fig. 7. Representación del modelo en espiral ................................................... 53
Fig. 8. Mejor documentación de las metodologías ágiles ................................. 64
Fig. 9. Fases de XP .......................................................................................... 67
Fig. 10. Fases de SCRUM .................................................................................. 77
Fig. 11. Gráfico a partir de lista de requisitos en SCRUM ................................... 89
Fig. 12. Gráfico a partir de horas pendientes de iteración en SCRUM ............... 90
Fig. 13. Iteración en Crystal ................................................................................ 93
Fig. 14. Fases de DSDM ..................................................................................... 96
Fig. 15. Niveles de MPMPES ............................................................................ 105
Fig. 16. Procesos de la gestión de negocio (GER) ........................................... 109
Fig. 17. Proceso planificación de recursos (GER) ............................................ 110
Fig. 18. Procesos de bienes, servicios e infraestructura (GER) ........................ 112
Fig. 19. Procesos de plan recursos humanos y capacitación (GER) ................ 114
Fig. 20. Procesos de plan de conocimiento de la organización (GER) ............. 116
Fig. 21. Procesos de administración de proyectos ........................................... 119
Fig. 22. Procesos de desarrollo y mantenimiento de software .......................... 123
Fig. 23. Mapa general MPMPES....................................................................... 124
Índice de Tablas
Tabla 1. Tamaño de las empresas desarrolladoras de software en México ....... 14
Tabla 2. Tamaño de las empresas desarrolladoras de software en Montreal ..... 40
Tabla 3. Repartición de las MPE en México por sector ...................................... 41
Tabla 4. Diferencias entre una pequeña y gran empresa ................................... 42
Tabla 5. Empresas en México que adoptaron algún modelo de procesos .......... 48
Tabla 6. Diferencias entre metodologías agiles y metodologías tradicionales .... 62
Tabla 7. Ranking de agilidad de las diferentes metodologías ágiles................... 63
Tabla 8. Lista de Objetivos en Scrum ................................................................. 84
Tabla 9. Lista de tareas de la iteración en Scrum ............................................... 86
1
CAPÍTULO I
Contexto del
Problema
2
1.1 Introducción El incremento en la calidad de los procesos en una empresa desarrolladora de
software es fundamental para competir, adaptarse y sobrevivir en el mercado
internacional. En el desarrollo de software, la ingeniería de software toma un
papel muy importante ya que origina el desarrollo, operación y mantenimiento de
software, a través de planteamientos sistemáticos, disciplinados y cuantificables
al desarrollo, operación y mantenimiento de software y se ha demostrado que
las empresas internacionales promueven la calidad de software implantando
ingeniería de software (Laporte, Alexandre et al. 2008).
La industria de software reconoce las Micro y Pequeñas Empresas (MPEs, Very
Small Enterprises, VSEs por sus siglas en inglés) por su importante contribución
de productos y servicios. Un ejemplo claro del crecimiento de las Micro y
Pequeñas Empresas es la industria de software Irlandés un componente clave
para la economía nacional de Irlanda. Acorde a las empresas en Irlanda, al final
de 2004 alrededor de 750 empresas de software contrataron casi 12,000
personas, sin embargo, la mayoría de estas empresas de software son micro
empresas de las cuales el 1.9% tiene más de 100 empleados y más del 60%
tiene 10 empleados o menos (Laporte 2008).
Para lograr la calidad en sus productos y servicios las MPEs son atraídas por las
metodologías ágiles, estándares fáciles de implementar, que acorten el tiempo
de desarrollo del software proporcionando una mejor flexibilidad para cumplir sus
objetivos de negocio. Para lidiar con las limitaciones en recursos las MPEs
necesitan asesoramientos cortos, ligeros, fáciles de entender e implantar, por
consiguiente las MPEs demandan la mejora en los procesos para el desarrollo
de software, aunque lo manifiestan como un gran desafío (López 2003).
3
1.2 Antecedentes del trabajo a investigar
Los objetivos principales de la ingeniería de software son desarrollar, operar y
mantener el software. El desarrollo de software y asegurar la calidad del mismo
es una disciplina distinta, ya que las propiedades del software no son las mismas
que la ingeniería civil, mecánica o eléctrica, es por esto que los atributos para
asegurar la calidad del software son difíciles de especificar y planear, sin
embargo, el uso de estándares internacionales garantiza, (Joannou 2007):
Agrupar lo mejor y más apropiado de las buenas prácticas y usos del
desarrollo de software.
Englobar los conocimientos.
Proporcionar un marco para implementar procedimientos de
aseguramiento de la calidad.
Proveer continuidad y entendimiento entre el trabajo de personas y
organizaciones distintas.
La implantación de la ingeniería de software y los estándares internacionales,
conforman un área llamada ingeniería en las empresas, que integra disciplinas
ya establecidas, a lo largo de una década esta área a emergido y es definida
como un conjunto de conocimientos, principios y prácticas que tienen relación
con el análisis, diseño, implementación y operación de una empresa (Joannou
2007).
Los elementos que integran una disciplina en la empresa son:
Campo de estudio, conocimiento o experiencia;
Reglas de conducta o métodos de práctica; y
Métodos para asegurar la aplicación de reglas.
4
Integrar disciplinas en una empresa, sistemas e ingeniería de software requiere
integrar también:
Materiales de desarrollo profesional: pruebas de certificación.
Estándares en la organización: IEEE and the International
Organization for Standardization (ISO).
Disciplinas: empresa, sistemas, software y calidad.
Niveles de administración: empresa y proyecto.
Jerarquías de productos: sistemas de sistemas.
Objetivos de área: confiabilidad, dependencia y seguridad; y
Niveles de prescripción: principios, estándares y directrices (Joannou
2007).
La implantación de los estándares en la organización es un reto continuo, con
una constante actualización a las necesidades de las empresas, evolucionando
y formando parte importante del estado de arte de las tecnologías de software.
La aplicación de estándares en la empresa, asegura la solución del fenómeno
crisis del software, han sido muchas las organizaciones que han abordado, con
mayor o menor rigor, el análisis de problemas en el desarrollo de sistemas de
software. Sus trabajos se han encaminado a la localización de las causas; y a la
exposición en textos didácticos, normativos o estándares de procesos o
prácticas necesarias para abordar el desarrollo, mantenimiento y operación con
las mayores garantías de éxito (Joannou 2007).
En su mayoría los departamentos de universidades, organismos de
normalización o investigación nacionales o internacionales, sociedades de
profesionales, departamentos de defensa, departamentos de calidad y procesos
de empresas los que han ido generando normas y estándares.
Se considera como entidades de mayor reconocimiento internacional, por sus
trabajos y esfuerzos realizados para la normalización, y reconocimiento de la
ingeniería del software a: ISO, IEEE- Computer Society y SEI (Mochi 2006).
5
ISO
ISO (International Organization for Standardization) fue fundada en 1947 con 87
países miembros, en 1987 la ISO y IEC (International Electrotechnical
Commission), establecieron un Comité Internacional (JTC1) para las
Tecnologías de Información (Derniame, Ali Kaba et al. 1999).
La misión del JTC1 es la estandarización en el campo de campo de los sistemas
de tecnologías de la información, incluyendo microprocesadores y equipos. Los
estándares o instrucciones técnicas más importantes para la ingeniería de
software:
• ISO/IEC 12207
• ISO/IEC TR 15504
SEI
SEI (Software Engineering Institute) integrado en la Universidad Carnegie
Mellon, los trabajos y aportaciones realizadas por el Instituto son también
referente mundial de primer orden, siendo la aportación más significativa los
modelos de madurez de las capacidades: CMM y CMMI. Ambos modelos han
demostrado su efectividad en los casi 15 años de implantación efectiva en
entornos de producción de software:
• Como marco de referencia para mejora de procesos, y
• Como criterio de evaluación para determinar la madurez, y por tanto fiabilidad
de resultados previsibles de una organización de software (Derniame, Ali Kaba
et al. 1999).
IEEE Computer Society
IEEE (Institute of Electrical and Electronics Engineers) surgió en 1963 con la
fusión del AIEE (Instituto Americano de Ingenieros Eléctricos) y el Instituto de
Ingenieros de Radio (IRE). Su misión es preservar, investigar y promover la
información de tecnologías eléctricas y electrónicas. La IEEE Computer Society
es una sociedad integrada en IEEE, formada en la actualidad por más de
6
100,000 miembros en todo el mundo, su finalidad es avanzar en la teoría,
práctica y aplicación de las tecnologías de la información. Realiza conferencias,
publicaciones, cursos de formación, y desarrolla Estándares (Mochi 2006).
La figura 1 muestra los principales estándares y modelos de las entidades más
importantes:
Fig. 1. Principales estándares y modelos
(Mochi 2006)
1.3 Trabajos relacionados
En el mercado internacional actual, nos encontramos con una demanda de
productos y software de calidad, y la necesidad de proveer a las MPEs,
estándares adaptados a la medida, fáciles de implementar y fiables, además el
proporcionar una guía para la adaptación de los mismos. (Watts and Wesley
2000) y (Laporte, Alexandre et al. 2008), comparten los objetivos de
proporcionar estándares a las MPEs:
Realizar estándares para software, accesibles para MPEs.
7
Proveer documentación, de requerimientos mínimos, a la medida y de
adaptación de esfuerzo.
Proveer documentación integrada, disponible a los procesos de los
estándares.
La mayor parte de los estudios y encuestas por (Laporte 2008) confirman que la
ingeniería de software actual no completa todas las necesidades de las
organizaciones, especialmente aquellas con poco nivel de capital.
Investigaciones muestran que las MPEs encuentran complicado relacionar los
estándares ISO a las necesidades de su negocio y justificar la aplicación de
esos estándares a sus prácticas de negocio. La mayor parte de las MPEs no
pueden pagar los recursos en cuestión, por el número de empleados, costo y
tiempo, o buscar un beneficio en establecer el proceso de software en un ciclo
de vida.
Grupo WG24
(Laporte 2008) y el grupo WG24, en sus estudios y encuestas realizadas
definieron los requerimientos específicos de las MPEs, para poder implementar
estándares como ISO/SC7, además de recolectar información para identificar
problemas y soluciones potenciales, que puedan ayudar a aplicar estándares en
las MPEs y así hacerlas más competitivas:
El contexto de la MPE requiere un perfil de ciclo de vida dedicado y ligero.
Contextos particulares del negocio requieren perfiles particulares.
Existen diferencias significantes en los terminas de recursos disponibles e
infraestructura entre una MPE que emplea de 1 a 10 personas y un
departamento IT del mismo tamaño en una empresa grande.
Las MPE son limitadas tanto en tiempo y recursos, donde se debe lidiar
con el desconocimiento de entender como los estándares las van a
beneficiar.
8
Los beneficios para las MPEs deberán de incluir el reconocimiento de un
asesor o auditor por un cuerpo acreditado.
La integración de estándares en el área de procesos de software en la empresa
es de gran importancia, sin embargo en las MPEs no es habitual, (Garcia and
Suarez 2007) plantean una vista general de la administración de proyectos
usando un cuestionario de dos fases, para identificar procesos realizados y no
realizados. El cuestionario que se propone está basado en las áreas de
procesos del Nivel 2 de Capability Maturity Model Integration for Development
v1.2. Se espera que la aplicación del cuestionario a los procesos, ayude a las
MPEs a identificar:
Procesos y prácticas que han sido realizadas pero no documentadas.
Procesos que necesitan mayor atención.
Procesos que no han sido implementados por mala administración ó
desconocimiento.
El cuestionario utiliza preguntas cerradas y límites en el número de las posibles
respuestas. Este organizado de la siguiente manera:
Respuestas-Realizadas-Nivel 5: Siempre, usualmente, algunas veces,
rara vez y nunca.
2 Respuestas de Validación: No lo sé y no aplica.
Espacios adicionales de Información: Comentarios.
Cada respuesta involucra una única interpretación e indica el nivel de
rendimiento en base a PMP (Performance Level Classification).
Aunque modelos como CMMI and ISO/IEC 15504, son ofrecidos a las
organizaciones para mejorar sus procesos, existen muchas empresas que no los
9
usan, con el cuestionario propuesto se busco evaluar el estado actual en las
practicas de administración de procesos.
Existen estándares internacionales para empresas de software, sin embargo
fueron concebidos para grandes empresas, las nuevas investigaciones y
propuestas buscan acotar estos estándares, para aplicarlos en las MPEs.
Los estándares internacionales para mejora de procesos, como ISO/IEC
JTC1/SC7, son difíciles de adaptar a las MPEs, la utilización de metodologías
ágiles junto con estos estándares, puede llegar a una fusión empírica que se
ajuste a las necesidades de las MPEs. (Mc Caffery, Taylor et al. 2007)
determinan que limitadas en recursos y tamaño, MPEs desarrolladoras de
software, buscan mejora en sus procesos para mayor competitividad, en un
escenario anterior las empresas de software se enfocan en tiempo para
mercadeo, innovación y creatividad así a menudo ignoran modelos SPI como
CMM y CMMI, cuyo principal objetivo inicial es lograr estabilidad y previsibilidad.
Entonces, para realizar los objetivos del negocio, las MPEs muestran un
incremento hacia las metodologías ágiles, que prometen desarrollos rápidos en
tiempo y una mejor flexibilidad en la implementación del producto.
Los métodos ágiles son procesos empíricos que requieren frecuente revisión y
respuesta en implementación. No son fácilmente evaluados usando ISO/IEC
15504 y CMMI, aunque se puede usar la estructura de algunos métodos como
Scrum y XP hasta ISO 900117 y los niveles CMMI 2 y 3.
La utilización de estándares en la empresa, acopla toda la estructura
organizacional y disciplinas de la empresa, (Joannou 2007) identifica que
Integrar las disciplinas de la empresa, sistemas e ingeniería de software
requiere integrar:
Material de desarrollo profesional: entrenamiento, examinación y
certificación.
Estándares para el desarrollo de la empresa: IEEE e ISO
10
Disciplinas: empresa, sistemas, software y calidad.
Niveles de administración: empresa y proyectos.
Jerarquías en productos: sistemas de sistemas.
Áreas de objetivo: estabilidad, dependencia, seguridad.
Niveles de prescripción: principios, estándares y guías base.
En Latinoamérica y específicamente en México, investigaciones por grupos
internacionales, integran estándares y modelos para acotarlos a la estructura de
las MPEs, (Laporte 2008) concluyen que, en México, se consideran estándares
como ISO/IEC 12207, ó modelos como CMMI, que son muy generales ó muy
costosos para las empresas mexicanas. Un Modelo de Procesos mexicano fue
desarrollado después de una solicitud por el ministro de economía, este provee
a la Industria Mexicana de Software un modelo basado en prácticas
internacionales y con las siguientes características:
Fácil de entender;
Fácil de aplicar;
Económico de adaptar;
Como base, puede lograr evaluaciones exitosas con otros Estándares o
modelos, como ISO 9000:200 o CMMI®
Este modelo está dividido en cuatro partes:
1. Definición de Conceptos y Productos;
2. Requerimiento de Procesos (MoProSoft);
3. Guías para Implementación de Procesos;
4. Guías para Evaluación de Procesos.
El Modelo de Procesos MoProSoft utiliza ISO/IEC 12207 como su estructura
general, así como procesos de: ISO9000:2000, CMMI®, Project Management
Body of Knowledge (PMBOK) y de Software Engineering Body of Knowledge
11
(SWEBOK). MoProSoft también almacena, el modelo de Proceso de
Requerimientos de ISO/IEC 15504-2 (Secretaria de Economia 2004).
El porcentaje de cobertura por MoProSoft respecto a estas prácticas es:
ISO 9001:2000 92%
ISO/IEC 12207 95%
CMMI level 2 77%
MoProSoft se enfoca principalmente en los procesos y considera tres bases
organizacionales o niveles estructurales donde los procesos son organizados:
1. Alta Dirección, contiene la gestión de los procesos del negocio, su
propósito es establecer la razón de existencia de la organización, sus
objetivos y las condiciones requeridas para lograrlos.
2. Gerencia, consiste en la gestión de Procesos, gestión de Proyectos y
gestión de Recursos.
3. Operación, consiste en la gestión de Proyectos Específicos, Desarrollo y
Mantenimiento de Software.
La integración de los estándares en la empresa muestra un avance sin embargo
aun no es común, que se implementen estándares en MPEs, (Laporte 2008), en
encuestas e investigaciones obtuvieron que los datos arrojados muestran una
diferencia marcada en el porcentaje de compañías certificadas en proporción a
su tamaño: menos del 18% de MPEs están certificadas, mientras que el 53% de
grandes compañías (de las cuales tienen más de 25 empleados) reclaman ser
certificadas. Entre el 82% de las MPEs no tienen certificación alguna. En
grandes empresas que usan Estándares, dos familias de Estándares y modelos
emergen en la lista:
12
Estándar ISO (55%)
Modelos de Software Engineering Institute (47%)
WG24 anticiparon el débil uso de estándares por las MPEs, preguntando sobre
las razones de esto, los motivos que predominaron son:
1. Carecer de recursos (28%)
2. Los estándares no son requeridos (24%)
3. La naturaleza de los estándares, 15% de las respuestas consideraron que
los estándares son difíciles-burocráticos y no proveen la adecuada guía
para el uso en el entorno de negocios de MPEs.
Tres cuartos de las MPEs externan que es importante que sean evaluadas por
un estándar certificado, 40% de ellas solicitan certificación ISO.
Desde la perspectiva de la MPE, los beneficios que se tienen con la certificación
son: incrementar la competitividad, mayor confidencia y satisfacción del cliente,
mayor calidad en el producto software, mejora en los procesos, decremento en
el riesgo de desarrollo, facilidad de comercialización y gran potencial de
exportación (Laporte, Alexandre et al. 2008).
Sin embargo, las MPEs también expresan la necesidad de asistencia para
adoptar e implementar estándares: más del 62% desean mas guías con
ejemplos, y el 55% preguntaron por estándares ligeros y de fácil entendimiento
completo y con plantillas. Finalmente, las demandas indican sí puede ser posible
implementar estándares con el mínimo costo, tiempo y recursos.
En esto identificamos que las empresas creen que es de gran importancia
certificarse con algún estándar, aun siendo la empresa de tipo MPE (Laporte,
Alexandre et al. 2008).
13
1.4 Descripción del problema a investigar La industria reconoce que las Micro y Pequeñas Empresas Desarrolladoras de
Software (MPEs) tienen una importante contribución en la economía mundial,
desarrollando partes importantes de software que son fácilmente integrados en
empresas de mayor tamaño.
Estándares internacionales y modelos como ISO/IEC12207 ó CMMI, fueron
desarrollados para agrupar lo mejor y más apropiado de las buenas prácticas y
usos del desarrollo de software, sin embargo estos estándares no han sido
diseñados para MPEs (integradas desde 1 a 25 empleados), y por consecuencia
es difícil aplicarlos en ellas (Laporte 2008).
Investigaciones muestran que las MPEs, tienen percepciones negativas de los
estándares y modelos de procesos, primariamente por el alto costo,
documentación excesiva y burocracia. Como adición las MPEs muestran
dificultad al relacionar estándares como ISO/IEC 12207 a las necesidades de su
negocio y justificar la aplicación de un estándar internacional de este tipo en sus
operaciones (Laporte 2008).
La mayor parte de las MPEs, no tienen los recursos necesarios para la
aplicación de un estándar de gran tamaño, y por consiguiente no ven redituable
su implantación (Laporte, Alexandre et al. 2008).
México cuenta con una posición favorable para convertirse en un competidor de
talla mundial en el ramo de la industria de software, gracias a su ubicación
geográfica, perfil demográfico y estado de desarrollo tecnológico. No obstante el
potencial de desarrollo es evidente, la industria de software es apenas incipiente
en nuestro país: participa con tan sólo el 0.10% del PIB (cifras de 2000). Aunque
no existe un padrón exhaustivo de esta industria que proporcione información
exacta, una muestra de 206 empresas desarrolladoras de software muestra el
perfil actual de la industria que es mayoritariamente micro y pequeña, con un
14
tamaño muy inferior al del promedio internacional, que es de 250 empleados
(Secretaria de Economia 2009).
Tabla 1. Tamaño de las empresas desarrolladoras de software en México
(Secretaria de Economia 2009)
1.5 Justificación Existen puntos clave que son de beneficio para los clientes de las
organizaciones dedicadas al desarrollo y mantenimiento de software como son:
Certidumbre, ya que las empresas verificadas deben llevar a cabo sus
actividades con prácticas validadas por las normas mexicanas.
Calidad, porque al llevar a cabo buenas prácticas de desarrollo y
mantenimiento de software los resultados son medibles
Capacidad, ya que los procesos con los que se desarrolla ó mantiene el
software son repetibles (Alvarez 2009).
Las buenas prácticas de desarrollo y mantenimiento de software son el pilar
fundamental en el que las organizaciones dedicadas a esta actividad centran el
logro de sus objetivos de negocio, de esta forma los clientes se aseguran que
15
las organizaciones son capaces y cumplen correctamente con su objetivo que es
el desarrollo de software de calidad.
Se estima que en 2006 existían en México 4’290,108 empresas, de las cuales el
99.8 por ciento son Micro, Pequeñas y Medianas Empresas.
Una microempresa se considera a la que tiene entre 0 y 10 trabajadores. Esto
es así, independientemente de que el negocio se dedique a la industria, al
comercio o los servicios (Secretaria de Economia 2009).
Ventajas de las Micro Empresas:
Las microempresas son un motor de crecimiento económico y de empleo
fundamental para el país ya que, de acuerdo a resultados del último censo
económico del INEGI:
De cada 100 empresas mexicanas 96 son microempresas.
Contribuyen con el 40.6% del empleo.
Aportan el 15% del PIB.
Desventajas de las Micro Empresas:
La competitividad y productividad de las microempresas, sobre todo de las de
tipo tradicional está siendo amenazada por la incorporación de modernos
conceptos de negocio, que evidencian:
Limitada profesionalización.
Crecimiento desordenado.
Rezago tecnológico.
Altos consumos de energía.
Imagen comercial descuidada e insalubre.
Administración informal.
Limitados accesos al financiamiento (Alvarez 2009).
16
Hasta el momento se han registrado 138 empresas evaluadas en algún proceso
de calidad en 20 Estados de la República Mexicana: Aguascalientes, Baja
California, Chihuahua, Coahuila, Colima, DF, Hidalgo, Jalisco, México,
Michoacán, Nuevo León, Oaxaca, Puebla, Querétaro, Sinaloa, Sonora,
Tlaxcala, Veracruz, Yucatán y Zacatecas (Secretaria de Economia 2009).
Las empresas desarrolladoras de software demandan el uso de estándares
internacionales como ISO/IEC JTC1/SC7 conforme el incremento en la calidad
del software avanza, los procesos maduran y obtienen confianza en la misma,
sin embargo, estos estándares no fueron escritos para el desarrollo de MPEs
(integradas desde 1 a 25 empleados). México se ve afectado por este problema:
• La productividad de las empresas desarrolladoras de software es en general
baja, debido a la falta de uso de procesos avanzados. Esto les impone una
fuerte desventaja para competir frente a oferentes de otros países.
• México carece de centros tecnológicos que ofrezcan servicios de mejora y
aseguramiento de la capacidad de procesos de las empresas.
• Se carece de modelos, normas y de organismos evaluadores de la capacidad
de procesos de la producción de software. Las evaluaciones internacionales
de capacidad de procesos son costosas.
• Debido a la inexistencia de metodologías que permitan medir y evaluar la
calidad de software que se adquiere, los compradores locales se enfocan
más al precio que a la calidad (Secretaria de Economia 2009).
Desarrollar e Implantar un Modelo de Procesos apegado a los estándares
internacionales para el desarrollo de software aseguramos en las MPEs la
calidad en sus productos y servicios donde se obtienen beneficios como:
Incremento en la competitividad.
Mayor confidencia y satisfacción del cliente.
17
Mayor calidad en el producto software.
Mejora en los procesos.
Decremento en el riesgo de desarrollo.
Facilidad de comercialización y gran potencial de exportación (Laporte
2008).
Contar con un Modelo de Procesos especifico para MPEs crea condiciones para
que nuestro país y cualquier otro con empresas de tipo MPE asegure una
industria de software competitiva internacionalmente y desarrolle su crecimiento
en el corto plazo.
1.6 Los objetivos que se persiguen 1.6.1 Objetivo general
Crear un Modelo de Procesos para Micro y Pequeñas Empresas (MPEs)
Desarrolladoras de Software que asegure la calidad de sus productos y servicios
conforme a los Estándares Internacionales de Calidad.
1.6.2 Objetivos específicos
Generar un Modelo de Procesos que sirva de aplicación en empresas
reales, que demanden implementar un estándar que se apegue a la
estructura de Micro o Pequeña empresa.
Promover el uso de Estándares en las Micro y Pequeñas Empresas en
México.
La industria de software reconoce las Micro y Pequeñas Empresas por su
importante contribución de productos y servicios. Sin embargo, estándares
internacionales como ISO/IEC JTC1/SC7 no fueron escritos específicamente
18
para estas (integradas desde 1 a 25 empleados) y por consecuencia es difícil
aplicarlos.
Originar el desarrollo Nacional e Internacional de las Micro y Pequeñas
Empresas.
En un mundo de creciente competitividad, las empresas deben mostrar un
carácter evolutivo y dinámico, donde la capacidad de adaptación a cambios
estratégicos no afecte la estructura organizacional, aplicar un estándar en las
MPEs, certifica que la producción de la misma se apega a estándares
internacionales de calidad.
1.7 Hipótesis del trabajo Desarrollar un Modelo de Procesos específico para MPEs apegado a
Estándares Internacionales, Modelos de Procesos y Metodologías Agiles para
Desarrollo de Software, crea condiciones para asegurar la calidad de los
productos y servicios de las MPEs.
1.8 Descripción de la organización del trabajo En este trabajo de investigación se aplicara el Modelo MoProSoft, así como
metodologías ágiles para elaborar un Modelo de Procesos para Micro y
Pequeñas Empresas Desarrolladoras de Software, que cumpla con los objetivos
que estas empresas requieren para la aplicación de estándares como ISO/IEC
12207, ó modelos como CMMI, acotándolo a las necesidades que una Micro o
Pequeña Empresa necesita para poder implantar un Modelo de Procesos que
sea:
Fácil de entender.
Fácil de aplicar;
19
Económico de adaptar;
Ser un Modelo confiable, para lograr evaluaciones exitosas con otros
estándares o modelos, como ISO 9000:200 o CMMI®.
El capítulo 1 está compuesto por el contexto del problema donde se presenta la
descripción del problema a investigar, antecedentes y trabajos relacionados, así
como la descripción de los objetivos generales y específicos que se persiguen
en el trabajo de investigación.
El capítulo 2 se conforma por el estado del arte donde se muestra de lo general
a lo específico definiciones de un proyecto software y la importancia de la
ingeniería de software en la calidad de un producto de este tipo. Las
características propias de una MPE, así como un análisis de metodologías agiles
a utilizar en el desarrollo del modelo de procesos propuesto.
El capítulo 3 se exhibe la propuesta del modelo de procesos y sus
características, además de detallar cada nivel en sus requisitos, tareas y
herramientas a utilizar, complementándolo con su gráfico correspondiente a
cada nivel.
Por último el capítulo 4 establece las conclusiones obtenidas en el proceso del
trabajo de investigación así como el trabajo futuro que se puede desarrollar en
base a las experiencias obtenidas.
En la figura 2 se observan las metodologías y modelo a utilizar en el Modelo de
Procesos para Micro y Pequeñas Empresas Desarrolladoras de Software
(MPMPES).
20
Fig. 2. Modelo y metodologías ágiles a utilizar en MPMPES
La fase inicial requiere actividades de recolección de información, incluyendo
datos bibliográficos y datos experimentales. Los datos a investigar contienen
referencias sobre el uso de estándares y metodologías en las Micro y Pequeñas
Empresas, estadísticas de aplicación de estándares a nivel nacional e
internacional y datos recolectados de empresas que indiquen la importancia de
usar un estándar en ellas. Así mismo presentaré datos de la demanda actual
para las empresas y específicamente las micro y pequeñas en implantar
estándares que sean adaptados a su medida y su contexto en particular,
incluyendo un conjunto de guías y perfiles.
El Modelo de Procesos se considera apegado a MoProSoft en conjunto con
metodologías ágiles de desarrollo de software, se definen los conceptos básicos
pare describirlo:
21
Categoría de procesos: Un conjunto de procesos que abordan la misma área
general de actividad dentro de una organización.
Proceso: Conjunto de prácticas relacionadas entre sí, llevadas a cabo a través
de roles y por elementos automatizados, que utilizando recursos y a partir de
insumos producen un satisfactor de negocio para el cliente.
Objetivo: Fin a que se dirige o encamina una acción u operación.
Indicador: Mecanismo que sirve para mostrar o significar una cosa con
evidencias y hechos.
Rol: Es responsable por un conjunto de actividades de uno o más procesos. Un
rol puede ser asumido por una o más personas de tiempo parcial o completo.
Producto: Cualquier elemento que se genera en un proceso.
Práctica: Un conjunto de elementos, tales como actividades, roles,
infraestructura y mediciones, que al llevarse a cabo describen la ejecución de un
proceso.
Actividad: Conjunto de tareas específicas asignadas para su realización a uno o
más roles.
Verificación: Actividad para confirmar que el producto refleja propiamente los
requerimientos especificados para él.
Validación: Actividad para confirmar que el producto resultante es capaz de
satisfacer los requerimientos para su aplicación especificada o uso previsto.
22
Flujo de trabajo: Esquema que expresa las relaciones entre las actividades de
un proceso. Una relación puede ser secuencial, paralela, cíclica, de selección o
anidada.
Guía de ajuste: Modificación a las prácticas, entradas y salidas de un proceso,
siempre y cuando no afecten al cumplimiento de sus objetivos.
Gestión: Hacer diligencias conducentes al logro de un negocio.
Administración: Organizar trabajo y disponer recursos.
Organización: Empresa o área interna de una organización dedicada al
desarrollo y/o mantenimiento de software.
Infraestructura: Conjunto de elementos o servicios que se consideran
necesarios para la creación y funcionamiento de una organización.
Medición: Acción o efecto de medir.
Base de conocimiento: Es un repositorio de todos los productos tales como
productos de software, planes, reportes, registros, lecciones aprendidas y otros
documentos.
Situación excepcional: Circunstancia que impide el desarrollo de una actividad.
Lección aprendida: Experiencia positiva o negativa obtenida durante la
realización de alguna actividad.
Prospección: Estudio de la potencialidad o de la capacidad que tiene alguna
cosa para producir o dar resultados en el futuro, a partir del análisis de los datos
reunidos previamente (Oktaba 2007).
23
1.9 Metodología
El proyecto se desarrollará siguiendo los procesos considerados en MoProSoft y
las metodologías ágiles, integrando las fases del ciclo de vida tradicionales con
los procesos de administración de proyectos y los procesos de soporte
necesarios para un desarrollo satisfactorio del trabajo de investigación
propuesto.
A continuación se describen las etapas y procesos considerados para la
consecución del proyecto.
Investigación bibliográfica y definición del problema a investigar.
Análisis de micro y pequeñas empresas: Definición de los requerimientos,
especificación y estructura de la organización.
Identificación de uso de estándares internacionales en las micro y
pequeñas empresas nacionales e internacionales.
Modelo apegado a MoProSoft y metodologías ágiles para desarrollo de
software.
Reuniones semanales para revisar los avances del proyecto.
Seguimiento de tesis y productos generados. Revisión de tesis,
elaboración de artículos de investigación
Liberación del proyecto.
Documentación del proyecto.
Elaboración de informes semestrales: Informe semestral e Informe final.
24
CAPÍTULO II
Estado del
Arte
25
2.1 Proyectos de software Un proyecto en la definición de (Palacio 2007) a través de los conceptos
productos y servicios es:
1. Que los productos sean desarrollados a medida, partiendo de un diseño y la
posterior ejecución de un plan de ejecución y del mismo modo, que los servicios
puedan ser actuaciones únicas y específicas, concebidas y realizadas para las
necesidades de la ocasión.
2. Que los productos sean el resultado en serie de cadenas o procesos de
producción y los servicios, procedimientos normalizados, ejecutados según
protocolos y prácticas estandarizadas, que con carácter repetitivo se emplean
siempre para prestar el mismo servicio, o servicios del mismo tipo.
Cuando se encuentra en cualquiera de las dos situaciones anteriores y el
resultado obtenido sea un producto, a este proceso se llama proyecto, pero
cuando el resultado sea un servicio, entonces se llama operaciones.
Los proyectos tienen las siguientes características (Palacio 2007):
Los realizan personas.
Se ejecutan con recursos limitados.
Se llevan a cabo siguiendo una estrategia de actuación.
Producen un resultado único.
Se desarrollan en un marco temporal preestablecido. Tienen un inicio y fin
definidos.
Concluyendo lo anterior un proyecto es un conjunto de actividades necesarias
para producir un resultado previamente definido, en un rango de fechas
determinado y con una asignación específica de recursos.
26
Un proyecto software es aquel proyecto que genera como producto final una
aplicación o solución software. En la realización de producto se realizan un
conjunto de procesos, que conocemos como el ciclo de vida del desarrollo del
software.
A menudo se identifican las siguientes nueve fases dentro del ciclo de vida del
desarrollo del software:
1. Inicio del proyecto.
2. Especificación de los requisitos.
3. Diseño.
4. Codificación o implementación.
5. Test unitarios.
6. Test de integración.
7. Test del sistema.
8. Test de aceptación.
9. Sistema en uso (Mantenimiento) (Fowler 2003).
Al no contar con una metodología en las diferentes fases del desarrollo de
software se pueden presentar diversos factores de riesgo.
2.2 Factores de riesgo en el desarrollo de software
Se consideran factores de riesgo del desarrollo de productos software, a todos
aquellos factores que puedan provocar el fracaso del proyecto y
consecuentemente la no obtención del producto deseado (O.Mizuno, Kikuno et
al. 2000).
Esto incluye la obtención de un producto que no cumple los requisitos del
cliente, que no ha sido terminado en los plazos establecidos o simplemente que
27
no es un producto de calidad, con muchos errores y defectos que lo etiquetan
como incompleto (Mizuno, Adachi et al. 2001).
Se pueden encontrar diferentes métodos para cuantificar el grado de riesgo de
un proyecto y multitud de factores que pueden ocasionar riesgos reales en los
proyectos. (O.Mizuno, Kikuno et al. 2000) establece un conjunto de factores de
riesgo que deben tenerse en cuenta en cualquier proyecto de desarrollo de
software:
Factor Humano
En toda tarea que intervienen las personas se consideran los fallos humanos y
todo lo que esto lleva. En proyectos software tenemos en cuenta sobre todo:
Conocimientos, experiencia, habilidades del equipo de desarrollo y del
gestor del proyecto.
Estado anímico, físico y psíquico del equipo.
Diversidad del equipo.
Factor complejidad
Otro factor muy importante que se debe valorar en riesgos asociados a
proyectos software, es la complejidad del mismo proyecto, esto indica cuan
alerta a los detalles se debe estar. Un proyecto más complejo implica una mayor
probabilidad de que algo salga mal y por tanto, que el proyecto fracase.
Los principales indicadores son:
Tamaño del equipo de desarrollo.
Tamaño del proyecto.
Dependencias del proyecto respecto a equipos externos, internos.
Características de las tareas.
28
Factores tecnológicos
Debido a que un proyecto software es del ámbito tecnológico, este factor juega
un papel determinante cuando se desea lograr los objetivos. Pueden afectar de
diferentes maneras:
Infraestructura insuficiente o inexistente. En la solución o desarrollo.
Conocimientos técnicos del equipo de desarrollo. De las tecnologías del
proyecto.
Mala especificación de los requisitos no funcionales. Puede provocar
errores en el desarrollo.
Factores externos
Externos al equipo de desarrollo, pero no al proyecto. Incluyen riesgos como:
Cliente poco razonable. Puede provocar inestabilidad de los requisitos.
El desarrollador no se hace responsable de fallas o errores del software.
Factores gestión
Son todos aquellos que implican cualquier tipo de intento por controlar los
recursos humanos, temporales y técnicos del proyecto:
Gestión de los cambios en los requisitos.
Planificación basada en el conocimiento. En el conocimiento o
experiencia en proyectos similares anteriores.
Planificación excesivamente optimista cuando el equipo desconoce la
tecnología.
Problemas en proyectos anteriores quitan tiempo al equipo de desarrollo
actual.
Asignación de las responsabilidades técnicas.
Implicación/apoyo del equipo directivo.
29
Los diferentes tipos de factores de riesgo que afectan un proyecto software
pueden verse disminuidos y/o eliminados si seguimos metodologías que guíen a
los desarrolladores a alcanzar los objetivos de la mejor manera posible, este
conjunto de metodologías, procedimientos, reglas y documentación provienen de
la Ingeniería de Software.
2.3 Ingeniería de software
El software según la definición de (Lewis 1994), es la suma total de los
programas de computadora, procedimientos, reglas, la documentación asociada
y los datos que pertenecen a un sistema de cómputo”. El mismo autor, define
que un producto de software es un producto diseñado para un usuario. En el
mismo contexto la ingeniería de software provee un enfoque sistemático al
desarrollo, operación, mantenimiento y retiro del software. Es así como la
ingeniería de software permite lograr soluciones efectivas-eficaces, elaborando
productos de software funcionales y de calidad.
(Jacobson 1992) define el proceso de ingeniería de software como un conjunto
de etapas parcialmente ordenadas con la intención de lograr un objetivo, en este
caso, la obtención de un producto de calidad. La calidad del software se obtiene
al crear productos de software que cumplan con las necesidades y
requerimientos del usuario, y su diseño e implementación sea probado,
documentado y certificado para su uso operativo funcional.
En el concepto de ingeniera de software por (López 2003) establece una
relación entre las ciencias de computación y la ingeniería de software al afirmar
que esta última es el área donde se estudian principios de ciencias de
computación, administración y otras para aplicarlos al desarrollo de software,
esto quiere decir que la ingeniería de software, toma elementos de otras
disciplinas para utilizarlos en la construcción de software. Así como lo determina
30
(Joannou 2007) integrar las disciplinas de la empresa, sistemas e ingeniería de
software requiere integrar:
Material de desarrollo profesional: entrenamiento, examinación y
certificación.
Estándares para el desarrollo de la empresa: IEE e ISO.
Disciplinas: empresa, sistemas, software y calidad.
Niveles de administración: empresa y proyectos.
Jerarquías en productos: sistemas de sistemas.
Áreas de objetivo: estabilidad, dependencia, seguridad.
Niveles de prescripción: principios, estándares y guías base.
En otros conceptos de ingeniería de software en (López 2003) se afirma que es
el establecimiento y uso de principios robustos de la Ingeniería a fin de obtener
en forma económica software que sea fiable y que funcione eficientemente sobre
maquinas reales.
La IEEE define que la ingeniería software como la aplicación de un enfoque
sistemático, disciplinado y cuantificable hacia el desarrollo, operación y
mantenimiento del software.
La ingeniería de software tiene varios modelos, paradigmas o metodologías den
los cuales se apoya para el desarrollo de software, los cuales son mencionados
a continuación:
Modelo en cascada o Clásico (modelo tradicional)
Modelo en espiral (modelo evolutivo)
Modelo de prototipos
Desarrollo por etapas
Desarrollo iterativo y creciente o Iterativo e Incremental
RAD (Rapid Application Development)
31
El proceso de desarrollo de software requiere por un lado un conjunto de
conceptos, una metodología y un lenguaje propio. A este proceso también se le
llama el ciclo de vida del software que comprende cuatro grandes fases:
concepción, elaboración, construcción y transición. La concepción define el
alcance del proyecto y desarrolla un caso de negocio. La elaboración define un
plan del proyecto, especifica las características y fundamenta la arquitectura. La
construcción crea el producto y la transición transfiere el producto a los usuarios
(Lewis 1994).
Como se puede observar la ingeniería de software a través de sus principios,
procedimientos y técnicas permite desarrollar y mantener el software y su
principal objetivo es obtener productos software de calidad.
2.4 Calidad de software
Al hablar de calidad de software, nos introducimos a un apartado actual, donde
la calidad de los productos va ligada con la satisfacción del cliente y la
competitividad entre organizaciones, (Monsalve 2002) menciona que, la
satisfacción hacia el uso de un producto puede marcar una gran diferencia en el
mercado de productos similares. Es así como el desarrollo de artículos que
satisfacen las expectativas de los clientes y usuarios harán la diferencia entre
dos organizaciones que desarrollan productos que compiten en el mercado. La
preocupación por ofrecer productos acompañados de altos niveles de calidad no
es una actividad nueva. A lo largo de este siglo han surgido distintas
interpretaciones de como brindar calidad.
Como antes se ha mencionado los productos de software no deben carecer de
calidad, la calidad en los productos de software considera diversas actividades.
La gestión de la calidad dentro de este tipo de proyectos puede estandarizarse
dentro de la organización y certificarse a la comunidad de clientes.
32
Calidad se puede definir como "una característica o atributo de una cosa". De
esta forma se podría decir que la calidad de los productos puede medirse como
una comparación de sus características y atributos. Así, este concepto puede
aplicarse a cualquier producto.
Una de las formas de realizar una medida de calidad es observar las diferencias
ocurridas en la producción dos productos iguales. La producción de artículos de
cualquier especie no asegura que dos de ellos sean totalmente iguales. Quizás
sea preciso realizar observaciones acuciosas para lograr distinguir las
variaciones entre uno y otro, ya que estas pueden no ser obvias. Es más, quizás
sea necesario disponer de instrumentos adecuados y de precisión para poder
observar dichos cambios de la producción.
Uno de los principales objetivos de dar calidad a los productos es minimizar las
diferencias entre unidades producidas. Estas diferencias tienen diversos
orígenes y, por tanto, distintas y amplias formas de corregirlos, dependiendo de
la naturaleza del producto. Lo primordial es tener en cuenta el concepto de
brindar calidad a lo que se está realizando. De este modo, el brindar calidad es
una actividad esencial para un negocio que produce productos que serán
utilizados por otras personas (Monsalve 2002).
Cuando asociamos los términos calidad y software, según (Carvajal 2008) se
define la calidad de software como, la conformidad a los requisitos y la
adecuación al uso. Si valoramos la percepción más común de la calidad del
software se suele reconocer como la ausencia de errores que contenga nuestro
producto, ya que un producto con fallos, difícilmente cubrirá las funcionalidades
requeridas. Esta definición basada en los errores del producto software se suele
expresar como:
1. Radio de errores. Número de errores por millones de líneas del código fuente,
por puntos de función u otras unidades.
33
2. Fiabilidad. Número de errores durante n horas de funcionamiento, tiempo sin
errores ó la probabilidad de no tener ningún error durante cierto tiempo.
El cliente toma un papel importante en la calidad o la percepción de calidad en el
software, conocida como satisfacción del cliente.
(Stephen 2002) Considera dos conjuntos de objetivos en la calidad de las soluciones software:
La calidad del producto software.
La calidad de los procesos.
Por calidad del producto es básicamente que cumpla los requisitos establecidos
por los clientes, presente un bajo radio de errores, una alta fiabilidad un buen
grado de satisfacción de los usuarios.
En la calidad de los procesos, se persigue el mismo objetivo, obtener un
producto de calidad, sólo que se aspira llegar a este objetivo mediante un control
y una gestión de todo el proceso de desarrollo.
De aquí deriva que si los procesos son de calidad se tiene un mayor número de
probabilidades de que el producto final sea también de calidad. Normalmente
esta distinción se puede observar en la mejora de la calidad del software.
(Stephen 2002) también define que la calidad del software está formada por dos niveles:
1. La calidad intrínseca del producto. 2. La satisfacción del cliente.
La principal meta de un equipo desarrollador de software debería ser siempre
producir software catalogado como de alta calidad. Pero para ello se deben
tener en cuenta algunas ideas previas (Monsalve 2002):
34
Productos software son realizados por personas para personas
Así, las personas desarrolladoras deben tener en cuenta claramente que son
otras personas las que utilizarán sus productos, los que pueden estar sujetos a
fallos constantes. Aún a pesar de los avances actuales en Inteligencia Artificial,
los asistentes software para el desarrollo de software no son demasiado
confiables como para que la mano humana no intervenga en este proceso. El
desarrollo de productos software es una actividad sujeta a muchos factores que
la pueden hacer poco confiable.
Muchos desarrolladores piensan en la calidad como un atributo exclusivo de los
productos. Que esta empieza a considerarse una vez que las primeras líneas de
código son escritas. El concepto de calidad involucra muchos factores previos a
esta etapa, debiendo ponerse atención a cada una de estas etapas anteriores.
Sujeto a lo anterior, (Robert H. 1990) define que la calidad que pueden alcanzar
los productos software, y en general cualquier producto, está sometido a como
se desarrolla cada una de las etapas de la vida del producto, partiendo por la
definición de la idea del producto hasta la entrega y mantención del mismo. Así
la entrega de calidad a un producto considera actividades tales como:
Administración de la calidad
Asegurando minimizar las diferencias entre los recursos presupuestados y los
recursos realmente utilizados en las distintas etapas. Dichos recursos incluyen el
equipo de desarrollo, el equipamiento y tiempo de desarrollo.
Uso de tecnología de Ingeniería de Software eficiente
Considerando métodos de desarrollo y herramientas, aplicación de técnicas
formales a lo largo de todo el proceso.
35
Minimización de las variaciones entre los productos
Disminuyendo las diferencias y defectos entre versiones, pruebas en las
diferentes etapas del desarrollo.
Control de la documentación
Tanto de apoyo al desarrollo como a la entrega al usuario final, generada en
cada etapa, y verificación de los posibles cambios y modificaciones que pudiera
sufrir además de una correcta mantención y servicios de post-venta.
Calidad por etapas.
La calidad está presente en todas las etapas del proceso de desarrollo de los
productos software. A grandes rasgos se puede realizar una clasificación de
como interviene la aplicación de la calidad en dichas etapas. De esta forma
podemos distinguir que la calidad se puede asegurar en el diseño, en la
producción y la satisfacción final. (Monsalve 2002)
Calidad en el diseño
Se pretenden características definidas para la realización del producto software
y que se deberían cumplir posteriormente. Aquí la calidad se basa en definir un
listado de especificaciones a seguir. Involucra descripción de los procesos de
desarrollo, tareas y responsabilidades de los equipos de desarrollo. Dichos
procesos pueden estar estandarizados, por lo cual puede certificarse que el
trabajo se realiza bajo alguna norma de calidad, como puede ser la norma de
calidad ISO 9000-3:1993 que establece guías de acción para la aplicación de
ISO 9001 orientada al desarrollo, suministro y mantención de software.
En esta etapa la calidad aumenta en la medida que se realiza una alta
especificación de los procesos y se propone una estrecha tolerancia a la
modificación, estableciendo los métodos correctivos a las desviaciones
ocurridas.
36
Calidad en la producción
Se entiende el logro de la calidad en el grado que la producción se atine al
cumplimiento de los requerimientos de diseño. Si los requerimientos están bien
definidos y especificados el cumplimiento de la calidad en esta etapa no debería
tornarse en una tarea de complicaciones grandes, ya que las bases del trabajo
estarían previamente definidas.
Calidad de satisfacción
Esta es la medida de la calidad apreciada por los usuarios finales de los
productos software. En cierta medida es el entendimiento y aprecio del producto
software. Esta calidad es la culminación de un proceso previo sometido a
distintas aplicaciones de calidad de trabajo. No puede esperarse en esta etapa
una alta calidad si no hubo preocupación por ella en las etapas anteriores.
En gran parte, esta etapa es en donde más se aprecia la calidad dada a un
producto pues es aquí cuando se produce la comercialización y uso masivo de él
(Robert H. 1990).
Los usuarios verán una mayor calidad en un producto software en la medida que
este responde a los requerimientos, desarrolla un buen rendimiento, tiene
facilidad de uso, presenta una real ayuda y la documentación de usuario final
acompañada es realmente útil. Estas apreciaciones de calidad hacia un
determinado producto elevarán el nivel de confianza a la organización
desarrolladora, lo que puede elevar su posición en el mercado.
(Monsalve 2002) Resalta que para lograr una alta calidad del producto final este
debe estar soportado por una preocupación de asegurar la calidad en las etapas
previas a alcanzar dicho estado final. Lo que permite ir escalando en la oferta de
calidad es mantener un riguroso control de la calidad.
37
Control de la calidad
El control de la calidad definido por (Stephen 2002) es realizar una observación
constante acerca del cumplimiento de las tareas que pueden ofrecer una calidad
objetiva a la forma en cómo se está desarrollando un proyecto de Ingeniería de
Software. Es decir, una vigilancia permanente a todo el proceso de desarrollo y
ciclo de vida del software. Esta meta puede alcanzarse mediante frecuentes
inspecciones a las metodologías de trabajo y uso de herramientas, revisiones de
prototipos y testeo exhaustivo de los productos finales.
El control de la calidad permite realizar las rectificaciones pertinentes al
desarrollo en cuanto este empieza a desviarse de sus objetivos, alejando la
inclusión de la calidad al trabajo. Estas rectificaciones son posibles gracias a una
retroalimentación de las etapas superiores, creado un aprendizaje al observar
las salidas de cada etapa, hasta el producto final, y mejorar los procesos que
dan origen al sistema.
La retroalimentación, así como cada etapa realizada, debe generar
documentación, tanto como del diseño de los procesos de la etapa como de los
resultados obtenidos en cada etapa (y que servirá de entrada a la etapa
siguiente). Esto permite realizar el mejoramiento de los procesos débiles, lo que
definitivamente desembocará en un aseguramiento de la calidad en los procesos
ejecutados por la organización.
Por otra parte la documentación generada puede servir a modo de
entrenamiento de integrantes recientemente incorporados a los equipos de
desarrollo, los cuales no estarán familiarizados con los conceptos de calidad
manejados por dichos equipos (Robert H. 1990).
En el control de calidad se debe tener presente los costos que esta involucra.
(Monsalve 2002) menciona que si se piensa en las tareas que se debe realizar
en este control, puede observase que es necesario llevar a cabo tareas de
38
búsqueda de problemas, testeo, realimentación, rectificación, elaboración,
modificación y estudio de la documentación; entre otras actividades. Todas
ellas tienen costos involucrados (incluso puede darse la inclusión de equipos
destinados al aseguramiento de la calidad: los grupos SQA). Debe existir un
compromiso, ya que un excesivo costo en el control de la calidad puede hacer
que este proceso se torne ineficiente.
El mejoramiento de la calidad implica reducir los costos ya que se tendría un
cierto nivel de calidad ya asegurado.
Como conclusión a la calidad en los productos software, el asegurar la calidad
en las primeras etapas de este involucra que los costos del control en las etapas
posteriores tenderán a disminuir al tener menos aspectos que controlar pues,
nuevamente, la calidad estaría asegurada en sus bases.
El conocer el proyecto de software, aplicar ingeniería de software para el
desarrollo y poder asegurar la calidad en su desarrollo es solamente la base
para el que el equipo de desarrollo logre los objetivos.
El equipo de desarrollo en este caso de una MPE tiene que elegir la metodología
ó modelo adecuado que se ajuste a las características mismas de una MPE.
2.5 Micro y pequeñas empresas La definición de micro y pequeña empresa (MPE) suele ser muy ambiguo,
ya que no existe una definición comúnmente aceptada de estos términos. Por
ejemplo, los participantes del congreso de software a medida de CMM en 1995
no pudieron entrar en consenso en la definición de pequeña empresa.
Posteriormente, en 1998 en el panel de la conferencia SEPG en CMM y
proyectos pequeños, pequeño se definió como "proyectos de 3 a 4 meses de
duración con un equipo de desarrollo de 5 ó menos" (Laporte, Alexandre et al.
2008).
39
Johnson y Broadman definieron a la pequeña empresa como aquella con
“Menos de 50 desarrolladores de software y un pequeño proyecto aquel con
menos de 20 desarrolladores de software”.
Otra definición de MPE fue la definida por (Laporte, Alexandre et al. 2008) y es:
“Cualquier empresa que produzca servicios de Tecnologías de Información y
proyectos con un equipo de trabajo de 1 a 25 empleados”.
Tomando en cuenta una perspectiva legal la Comisión Europea define tres
niveles en la pequeña a mediana empresa (PME):
Pequeña a mediana – “Emplean menos de 250 personas y tienen un ingreso
anual que no excede los 50 millones de Euros, y/o su balance anual total no
excede los 43 millones de Euros”.
Pequeña – “Emplea menos de 50 personas, y su balance total anual no excede
los 10 millones de Euros”.
Micro – “Emplea menos de 10 personas, y su balance total anual no excede los
4 millones de Euros”
La industria de software reconoce a las micro y pequeñas empresas (MPEs,
Very Small Enterprises, VSEs por sus siglas en inglés) por su importante
contribución de productos y servicios. Un ejemplo claro del crecimiento de las
micro y pequeñas empresas es la industria de software Irlandés un componente
clave para la economía nacional de Irlanda. Acorde a las empresas en Irlanda, al
final de 2004 alrededor de 750 empresas de software contrataron casi 12,000
personas, sin embargo, la mayoría de estas empresas de software son micro
empresas de las cuales el 1.9% tiene más de 100 empleados y más del 60%
tiene 10 empleados o menos (Laporte 2008).
40
Las MPEs, si bien no son un fenómeno de nacimiento reciente, despiertan cada
vez más interés, tanto en el ámbito académico como en el de la opinión pública;
al punto que son consideradas “el motor de la economía europea” (Alvarez
2009).
Para entender aun mejor la dicotomía entre las diferentes definiciones es
necesario examinar el tamaño de las empresas de software operando en el
mercado. En Europa, el 85% del sector de empresas de tecnologías de
Información tiene de 1 a 10 empleados. En el contexto de las firmas de software
irlandesas el 1.9 % (10 empresas) de un total de 630, tienen más de 100
empleados en contraparte con el 61% de las empresas que tiene 10 empleados
o menos. En Canadá, específicamente en el área de Montreal, se ha encontrado
que el 78% de empresas desarrolladoras de software tienen menos de 25
empleados y el 50% menos de 10 empleados. En Brasil, las pequeñas empresas
representan aproximadamente el 70% del total de empresas (Laporte, Alexandre
et al. 2008).
Tabla 2. Tamaño de las empresas desarrolladoras de software en Montreal
(Laporte 2008)
La MPE en América Latina juega un papel muy importante en la cohesión social,
ya que contribuye significativamente a la generación de empleo, de ingresos,
erradicación de la pobreza y dinamiza la actividad productiva de las economías
locales, si bien es cierto que los estudios difieren en la estimación de la
Tamaño
De
Empresas de
Software
Desarrollo de
Proyectos
Empleados Número % Número %
1 a 25 540 78% 5,105 29%
26 a 100 127 18% 6,221 36%
Más de 100 26 4% 6,056 35%
TOTAL 693 100% 17,382 100%
41
contribución al Producto Interno Bruto, se estima que en promedio contribuyen
con el 20% del PIB y que, en algunos casos, esta contribución llega a alcanzar el
50% (Alvarez 2009).
En México Según el Instituto Nacional de Estadística, Geografía e Informática
(INEGI), existen alrededor de 2.84 millones de empresas en nuestro país, de las
cuales el 99.7% pertenecen al sector de las micro, pequeñas y medianas
empresas (tan sólo el 97% son MPEs), las cuales generan el 42% del Producto
Interno Bruto (PIB) y cerca del 64% del empleo formal en nuestro país.
La tabla 3 muestra como están distribuidas las micro y pequeñas empresas del
país por sector y el peso porcentual que tiene cada sector sobre el total de
empresas con estas características
Tabla 3. Repartición de las MPE en México por sector
(Secretaria de Economia 2004)
México cuenta con una posición favorable para convertirse en un competidor de
talla mundial en el ramo de la industria de software, gracias a su ubicación
geográfica, perfil demográfico y estado de desarrollo tecnológico. No obstante el
potencial de desarrollo es evidente, la industria del software es apenas incipiente
en nuestro país: participa con tan sólo el 0.10% del PIB (cifras de 2000). Aunque
no existe un padrón exhaustivo de esta industria que proporcione información
exacta, una muestra de 206 empresas, véase tabla 1, desarrolladoras de
software muestra el perfil actual de la industria que es mayoritariamente micro y
42
pequeña, con un tamaño muy inferior al del promedio internacional, que es de
250 empleados (Secretaria de Economia 2009).
Características de la MPE
Las características únicas de las MPEs así como las situaciones únicas propias
de su tamaño propician que el entorno del negocio sea diferente, algunas de
estas únicas diferencias del comportamiento entre las MPEs y las grandes
empresas son mencionadas en la tabla 4:
Tabla 4. Diferencias entre una pequeña y gran empresa
(Laporte, Alexandre et al. 2008)
El software producido por las MPE es sujeto a un numero distintivo e intrínseco
de características que lo hacen diferente a su contraparte las grandes empresas,
esto mismo afecta sus contenidos, su naturaleza y lo extenso en las actividades
de desarrollo. Hemos clasificado las características de una MPE acorde a cuatro
Característica Pequeña Empresa Gran Empresa
Practicas en Planeación No
estructurada/Operacional
Estructurada/Estratégica
Flexibilidad Alta Estructurada/Estratégica
Orientación al Riesgo Alto Medio
Procesos de
Administración
Informal Bajo
Capacidad de
Retroalimentación y
Aprendizaje
Limitados Alto
Impactos de un Mercado
Negativo
Profundos Manejables
Ventajas Competitivas Centradas en el capital
humano
Centradas en el capital
de la organización
43
categorías: Finanzas, Cliente, Procesos Internos de Negocio y Crecimiento
y Aprendizaje (Laporte, Alexandre et al. 2008).
Finanzas
Las MPE son económicamente vulnerables así como su flujo de efectivo y
dependen de los beneficios de los proyectos, es por esto que necesitan
desarrollar proyectos con buenos beneficios económicos. Tienden a desarrollar
proyectos con pocos beneficios y con demasiados impactos negativos:
demasiadas correcciones de errores, demasiado mantenimiento, pocos recursos
para retroalimentación, poco o nada de inversión para actividades de
aseguramiento de calidad, sin inversión para reúso de procesos de software,
poco capital para responder a riesgos, y un limitado capital para mejoras de
procesos y/o obtener certificaciones o asesorías.
Cliente
A menudo cada producto desarrollado por una MPE es para un cliente, donde el
cliente está a cargo de la administración del producto final; la integración del
software, instalación y operación.
Es una práctica normal para el cliente no definir la cantidad de la calidad los
requerimientos y la satisfacción del cliente depende de que tanto se hayan
cubierto los requerimientos específicos que pueden sufrir cambios a lo largo del
proyecto. Existe una estrecha relación entre los miembros del equipo de
desarrollo y el cliente, que muestra que el desarrollo de software en las MPE
está orientado altamente en la relación humana y la comunicación entre estos es
de suma importancia.
Procesos Internos de Negocio
Los negocios internos de una MPE son usualmente enfocados en el desarrollo
de sistemas de software a la medida, donde el producto software es elaborado
progresivamente y donde típicamente no tiene una fuerte relación con otros
proyectos. La mayor parte de la administración de procesos (como los recursos
44
humanos y la infraestructura) son realizados a través de mecanismos informales,
mayor parte a través de comunicación, donde la toma de decisiones y solución
de problemas son efectuados frente a frente.
Crecimiento y Aprendizaje
Las características de crecimiento y aprendizaje de una MPE sin tipificados por
una falta de aceptación a la asesoría de procesos de software, a la mejora de los
mismos y a la falta de recursos humanos que acepten la estandarización. Es
usual tener una percepción negativa por parte de las MPEs a estándares hechos
por grandes empresas para grandes empresas.
Estándares en las MPEs
En el Mercado Internacional actual, nos encontramos con una demanda de
productos y software de calidad, y la necesidad de proveer a las MPEs,
estándares adaptados a la medida, fáciles de implementar y fiables, además el
proporcionar una guía para la adaptación de los mismos.
La mayor parte de los estudios y encuestas por (Laporte 2008) confirman que la
Ingeniería de Software actual no completa todas las necesidades de las
organizaciones, especialmente las de tipo MPE.
La mayor parte de las MPEs no tienen los recursos para una certificación, por el
número de empleados, costo y tiempo.
(Laporte 2008) Define los requerimientos específicos de las MPEs, para poder
implementar estándares como ISO/SC7, además de recolectar información para
identificar problemas y soluciones potenciales, que puedan ayudar a aplicar
estándares en las MPEs y así hacerlas más competitivas:
El contexto de la MPE requiere un perfil de ciclo de vida dedicado y ligero.
Contextos particulares del negocio requieren perfiles particulares.
45
Existen diferencias significantes en los terminas de recursos disponibles e
infraestructura entre una MPE que emplea de 1 a 10 personas y un
departamento IT del mismo tamaño en una empresa grande.
Las MPE son limitadas tanto en tiempo y recursos, donde se debe lidiar
con el desconocimiento de entender como los estándares las van a
beneficiar.
Los beneficios para las MPEs deberán de incluir el reconocimiento de un
asesor o auditor por un cuerpo acreditado.
Los Estándares Internacionales para empresas de software, no fueron
concebidos para grandes empresas, las nuevas investigaciones y propuestas
buscan acotar estos estándares, para aplicarlos en las MPEs.
Los Estándares internacionales para mejora de procesos, como ISO/IEC
JTC1/SC7, son difíciles de adaptar a las MPEs, la utilización de metodologías
ágiles junto con estos estándares, puede llegar a una fusión empírica que se
ajuste a las necesidades de las MPEs.
Entonces, para realizar los objetivos del negocio, las MPEs muestran un
incremento hacia las metodologías ágiles, que prometen desarrollos rápidos en
tiempo y una mejor flexibilidad en la implementación del producto.
Los métodos ágiles son procesos empíricos que requieren frecuente revisión y
respuesta en implementación. No son fácilmente evaluados usando ISO/IEC
15504 y CMMI, aunque se puede usar la estructura de algunos métodos como
Scrum y XP hasta ISO 900117 y los niveles CMMI 2 y 3.
En Latinoamérica y específicamente en México, investigaciones por grupos
internacionales, integran estándares y modelos para acotarlos a la estructura de
las MPEs, (Laporte 2008) concluyen que, en México, se consideran estándares
como ISO/IEC 12207, ó modelos como CMMI, que son muy generales ó muy
costosos para las empresas Mexicanas. Un Modelo de Procesos Mexicano fue
desarrollado después de una solicitud por el ministro de economía, MoProSoft,
46
provee a la Industria Mexicana de Software un modelo basado en prácticas
internacionales y con las siguientes características:
Fácil de entender;
Fácil de aplicar;
Económico de adaptar;
Como base, puede lograr evaluaciones exitosas con otros Estándares o
modelos, como ISO 9000:200 o CMMI®
MoProSoft está dividido en cuatro partes:
1. Definición de Conceptos y Productos;
2. Requerimiento de Procesos (MoProSoft);
3. Guías para Implementación de Procesos;
4. Guías para Evaluación de Procesos.
El Modelo de Procesos MoProSoft utiliza ISO/IEC 12207 como su estructura
general, así como procesos de: ISO9000:2000, CMMI®, Project Management
Body of Knowledge (PMBOK) y de Software Engineering Body of Knowledge
(SWEBOK). MoProSoft también almacena, el modelo de Proceso de
Requerimientos de ISO/IEC 15504-2.
El porcentaje de cobertura por MoProSoft respecto a estas prácticas es:
ISO 9001:2000 92%
ISO/IEC 12207 95%
CMMI level 2 77%
MoProSoft se enfoca principalmente en los procesos y considera tres bases
organizacionales o niveles estructurales donde los procesos son organizados:
47
1. Alta Dirección, contiene la gestión de los procesos del negocio, su
propósito es establecer la razón de existencia de la organización,
sus objetivos y las condiciones requeridas para lograrlos.
2. Gerencia, consiste en la gestión de Procesos, gestión de Proyectos
y gestión de Recursos.
3. Operación, consiste en la gestión de Proyectos Específicos,
Desarrollo y Mantenimiento de Software.
Fig. 3. Niveles del modelo de procesos MoProSoft
(Oktaba 2007)
En la tabla 5 se muestra el número de empresas en México que consideraron
usar algún modelo en el desarrollo de sus productos software.
48
Tabla 5. Empresas en México que adoptaron algún modelo de procesos
(Secretaria de Economia 2009)
MODELO
CMM
CMMI
MOPROSOFT
Número de
empresas
14
36
90
TOTAL
140
El número de empresas en México que adoptaron algún modelo de desarrollo de
software, aunque es considerable, la mayor parte de estas empresas es de
escala mediana y grande (Secretaria de Economia 2009).
El grupo WG24 afirma que MoProSoft se enfoca más en las necesidades de
grandes organizaciones que en las MPEs (Laporte 2008).
Para lograr las necesidades de las MPEs en calidad en sus productos y servicios
las MPEs son atraídas por las metodologías ágiles, Estándares fáciles de
implementar, que acorten el tiempo de desarrollo del Software proporcionando
una mejor flexibilidad para cumplir sus objetivos de negocio.
Para lidiar con las limitaciones en recursos las MPEs necesitan asesoramientos
cortos, ligeros, fáciles de entender e implantar, por consiguiente las MPEs
demandan la mejora en los procesos para el desarrollo de Software, aunque lo
manifiestan como un gran desafío.
49
2.6 Metodologías para desarrollo de software
El concepto de metodología extraído de (Carvajal 2008) define que es una
colección de procedimientos, técnicas, herramientas y documentos auxiliares
que ayudan a los desarrolladores de software en sus esfuerzos por implementar
nuevos sistemas de información. Una metodología está formada por fases, cada
una de las cuales se puede dividir en sub-fases, que guiarán a los
desarrolladores de sistemas a elegir las técnicas más apropiadas en cada
momento del proyecto y también a planificarlo, gestionarlo, controlarlo y
evaluarlo.
Las metodologías intentan marcar un camino común a través del cual poder
producir software con éxito. El proceso de desarrollo del software está
compuesto por actividades, pero también por subprocesos, el control de estas
actividades y su verificación, llevan implícito el concepto de calidad. Muchas
metodologías incluyen dentro de sus técnicas el control de los procesos de
desarrollo, con el fin de garantizar una solución software de calidad.
Normalmente lo hacen como si el producto software fuese un producto industrial
más y certifican sus procesos contra entidades certificadoras (ISO), las cuales
enumeran las buenas prácticas que se deben seguir.
Al hablar de metodologías y proceso de desarrollo de software, el término
modelo de procesos de software va intrínseco, (Derniame, Ali Kaba et al. 1999)
definen que un modelo de procesos es una representación del mundo real, que
captura el estado de actual de las actividades para guiar, reforzar ó automatizar
partes de la producción de los procesos.
Estos son los diferentes modelos de procesos que nos podemos encontrar
dentro del mundo del desarrollo del software:
50
2.6.1 Modelo secuencial Representado por metodologías tan famosas como Cascada (Waterfall). Se
inicia con un completo análisis de los requisitos de los usuarios. Después de
varios meses de interacción con el usuario y los clientes, el equipo de desarrollo
determina un conjunto de características, requisitos funcionales y no funcionales.
Toda la información es documentada para la siguiente fase, diseño, donde el
equipo de desarrollo colabora entre sí para crear una arquitectura óptima del
sistema.
En el siguiente paso, los programadores implementan el diseño y finalmente, el
software completo es probado y enviado (Carvajal 2008).
El modelo en cascada resuelve el problema de los requisitos variables,
congelándolos, sin permitir los cambios.
Este modelo es referencia en los modelos de procesos formales (Carvajal 2008).
Fig. 4. Representación del modelo en cascada (Waterfall)
(Fundacion Wikimedia 2011)
51
2.6.2 Modelos iterativos e incrementales Ambos son flexibles en el ciclo de desarrollo y repiten el modelo de cascada en
cada una de las partes en las que lo dividen (Carvajal 2008).
Desarrollo incremental
Su principal objetivo es reducir el tiempo de desarrollo, dividiendo el proyecto en
intervalos incrementales superpuestos. Del mismo modo que con el modelo en
cascada, todos los requisitos se analizan antes de empezar a desarrollar, sin
embargo, los requisitos se dividen en incrementos independientemente
funcionales. El desarrollo de cada incremento se puede solapar, ahorrando
tiempo gracias al desarrollo concurrente multitarea a lo largo del proyecto.
(Carvajal 2008)
Fig. 5. Representación del modelo incremental
(Fundacion Wikimedia 2011)
52
Desarrollo iterativo
A diferencia del modelo incremental se centra más en capturar mejor los
requisitos cambiantes y la gestión de los riesgos. En el desarrollo iterativo cada
una de las iteraciones, es un producto funcional y entregable. La primera
iteración empieza con una versión muy simple, y cada una de las siguientes
iteraciones añade un conjunto de funcionalidades.
Cada una de las partes, iteraciones, siguen en si el modelo en cascada,
empezando con el análisis, seguido del diseño, implementación y finalmente las
pruebas. El desarrollo iterativo funciona bastante bien en ambientes cambiables,
ya que los requisitos son estáticos para cada iteración (Carvajal 2008).
Fig. 6. Representación del modelo iterativo
(Fundacion Wikimedia 2011)
53
2.6.3 Modelo en espiral Comprende las mejores características de ciclo de vida clásico y el de prototipos
(desarrollo iterativo). Además, incluye el análisis de alternativas, identificación y
reducción de riesgos.
El modelo en espiral y el iterativo, proporcionan un nivel de agilidad muy por
encima del de cascada, pero muchos usuarios consideraron que aún no eran
suficientes para el cambiante mundo de negocios (Derniame, Ali Kaba et al.
1999).
Fig. 7. Representación del modelo en espiral
(Fundacion Wikimedia 2011)
54
Existen otros modelos menos relevantes para las metodologías ágiles son V-
Model, WModel, X-Model, RAD y Orientado a Objetos (Carvajal 2008).
Por tanto cuando hablemos de metodologías se debe tener en cuenta todo lo
que va implícito dentro de ellas, sus métodos, sus modelos, sus herramientas,
su filosofía. (Letelier and Penades 2009) cuando hablan de metodologías de
desarrollo distinguen entre metodologías maduras e inmaduras, considerando a
estas últimas todas aquellas que difieran de los métodos formales y presentan
ciertos signos de debilidad, ya sea en el producto final, como en el desarrollo del
mismo.
Las metodologías tradicionales presentan largas fases de planificación y
análisis, así como un gran entusiasmo por el exceso de documentación, y
desvían a los proyectos a utilizar metodologías agiles.
2.7 Metodologías ágiles para desarrollo de software
Hasta hace poco el proceso de desarrollo llevaba asociada un marcado énfasis
en el control del proceso mediante una rigurosa definición de roles, actividades y
artefactos, incluyendo modelado y documentación detallada. Este esquema
tradicional para abordar el desarrollo de software ha demostrado ser efectivo y
necesario en proyectos de gran tamaño (respecto a tiempo y recursos), donde
por lo general se exige un alto grado de fases en el proceso. Sin embargo, este
enfoque no resulta ser el más adecuado para muchos de los proyectos actuales
donde el entorno del sistema es muy cambiante, y en donde se exige reducir
drásticamente los tiempos de desarrollo pero manteniendo una alta calidad
(Letelier and Penades 2009).
El objetivo de los métodos ágiles en definición de (Derniame, Ali Kaba et al.
1999) es permitir que una empresa sea ágil, mientras que las técnicas ágiles
55
pueden variar en su ejecución y en su énfasis, todas ellas comparten
características, incluyendo el desarrollo iterativo y están centradas en la
interacción, comunicación, y en la reducción de la creación de artefactos
intermedios. Desarrollar mediante iteraciones permite al equipo de desarrollo
adaptarse a los cambios de los requisitos. Trabajar con un alto grado de
comunicación permite que el equipo pueda tomar decisiones y aplicarlas
inmediatamente. La reducción de artefactos intermedios que no dan valor
añadido al producto final, nos permite asignar más recursos al producto en sí y
podrá ser acabado antes.
(Letelier and Penades 2009) Explica que las los métodos agiles innovan, no en
las prácticas que ellos utilizan, sino el reconocimiento de las personas como
principales valedoras para que un proyecto de software triunfe, en conjunto con
una gran orientación a la efectividad y la manejabilidad. La mayoría de
seguidores de las metodologías ágiles están de acuerdo en que ser ágil, es algo
más que seguir las guías que se supone que hacen un proyecto ágil.
La verdadera agilidad es más que un conjunto de prácticas, es un estado de
ánimo.
Ante las dificultades para utilizar metodologías tradicionales con estas
restricciones de tiempo y flexibilidad, muchos equipos de desarrollo se resignan
a prescindir del “buen hacer” de la ingeniería del software, asumiendo el riesgo
que ello conlleva.
En un escenario, donde el equipo de desarrollo es limitado en tamaño y recursos
como una MPE las metodologías ágiles emergen como una posible respuesta
para llenar ese vacío metodológico. Por estar especialmente orientadas para
proyectos pequeños, las metodologías ágiles constituyen una solución a medida
para ese entorno, aportando una elevada simplificación que a pesar de ello no
renuncia a las prácticas esenciales para asegurar la calidad del producto.
56
En la comunidad de la ingeniería del software, se está viviendo con intensidad
un debate abierto entre los partidarios de las metodologías tradicionales
(referidas peyorativamente como "metodologías pesadas") y aquellos que
apoyan las ideas emanadas del Manifiesto Ágil (Beck 2001). Por un lado, para
muchos equipos de desarrollo el uso de metodologías tradicionales les resulta
muy lejano a su forma de trabajo actual considerando las dificultades de su
introducción e inversión asociada en formación y herramientas. Por otro, las
características de los proyectos para los cuales las metodologías ágiles han sido
especialmente pensadas se ajustan a un amplio rango de proyectos industriales
de desarrollo de software; aquellos en los cuales los equipos de desarrollo son
pequeños, con plazos reducidos, requisitos volátiles, y/o basados en nuevas
tecnologías, como es el caso de una MPE.
En febrero de 2001 en Utah-EEUU, nace el término ágil aplicado al desarrollo de
software. Participaron un grupo de 17 expertos de la industria del software,
incluyendo algunos de los creadores o impulsores de metodologías de software.
Su objetivo fue proyectar los valores y principios que deberían permitir a los
equipos desarrollar software rápidamente y respondiendo a los cambios que
puedan surgir a lo largo del proyecto.
Se pretendía ofrecer una alternativa a los procesos de desarrollo de software
tradicionales, caracterizados por ser rígidos y dirigidos por la documentación que
se genera en cada una de las actividades desarrolladas. Varias de las
denominadas metodologías ágiles ya estaban siendo utilizadas con éxito en
proyectos reales, pero les faltaba una mayor difusión y reconocimiento.
Tras esta reunión se creó The Agile Alliance (Beck 2001), una organización, sin
ánimo de lucro, dedicada a promover los conceptos relacionados con el
desarrollo ágil de software y ayudar a las organizaciones para que adopten
dichos conceptos.
El punto de partida fue el Manifiesto Ágil, un documento que resume la filosofía
ágil.
57
El Manifiesto comienza enumerando los principales valores del desarrollo ágil. Se valora (Beck 2001):
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y
las herramientas. Las personas son el principal factor de éxito de un proyecto
software. Si se sigue un buen proceso de desarrollo, pero el equipo falla, el
éxito no está asegurado; sin embargo, si el equipo funciona, es más fácil
conseguir el objetivo final, aunque no se tenga un proceso bien definido. No se
necesitan desarrolladores brillantes, sino desarrolladores que se adapten bien al
trabajo en equipo. Así mismo, las herramientas (compiladores, depuradores,
control de versiones, etc.) son importantes para mejorar el rendimiento del
equipo, pero el disponer más recursos que los estrictamente son necesarios
también puede afectar negativamente. En resumen, es más importante construir
un buen equipo que construir el entorno.
Desarrollar software que funciona más que conseguir una buena
documentación. Aunque se parte de la base de que el software sin
documentación es un desastre, la regla a seguir es no producir documentos a
menos que sean necesarios de forma inmediata para tomar una decisión
importante. Estos documentos deben ser cortos y centrarse en lo fundamental.
Si una vez iniciado el proyecto, un nuevo miembro se incorpora al equipo de
desarrollo, se considera que los dos elementos que más le van a servir para
ponerse al día son: el propio código y la interacción con el equipo.
La colaboración con el cliente más que la negociación de un contrato. Las
características particulares del desarrollo de software hace que muchos
proyectos hayan fracasado por intentar cumplir unos plazos y unos costes
preestablecidos al inicio del mismo, según los requisitos que el cliente
manifestaba en ese momento.
58
Por ello, se propone que exista una interacción constante entre el cliente y el
equipo de desarrollo. Esta colaboración entre ambos será la que marque la
marcha del proyecto y asegure su éxito.
Responder a los cambios más que seguir estrictamente un plan. La
habilidad de responder a los cambios que puedan surgir a los largo del proyecto
(cambios en los requisitos, en la tecnología, en el equipo, etc.) determina
también el éxito o fracaso del mismo. Por lo tanto, la planificación no debe ser
estricta puesto que hay muchas variables en juego, debe ser flexible para poder
adaptarse a los cambios que puedan surgir. Una buena estrategia es hacer
planificaciones detalladas para unas pocas semanas y planificaciones mucho
más abiertas para unos pocos meses.
Los valores anteriores inspiran los doce principios del manifiesto. Estos
principios son las características que diferencian un proceso ágil de uno
tradicional. Los dos primeros son generales y resumen gran parte del espíritu
ágil. Son (Beck 2001):
I. La prioridad es satisfacer al cliente mediante tempranas y continuas
entregas de software que le aporte un valor. Un proceso es ágil si a las pocas
semanas de empezar ya se entrega software que funcione aunque sea
rudimentario. El cliente decide si pone en marcha dicho software con la
funcionalidad que ahora le proporciona o simplemente lo revisa e informa de
posibles cambios a realizar.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el
cliente tenga una ventaja competitiva. Este principio es una actitud que deben
adoptar los miembros del equipo de desarrollo. Los cambios en los requisitos
deben verse como algo positivo. Les va a permitir aprender más, a la vez que
logran una mayor satisfacción del cliente. Este principio implica además que la
estructura del software debe ser flexible para poder incorporar los cambios sin
59
demasiado coste añadido. El paradigma orientado a objetos puede ayudar a
conseguir esta flexibilidad.
Existen una serie de principios que tienen que ver directamente con el proceso
de desarrollo de software a seguir.
III. Entregar frecuentemente software que funcione desde un par de
semanas a un par de meses, con el menor intervalo de tiempo posible
entre entregas. Las entregas al cliente se insiste, en que sean software, no
planificaciones, ni documentación de análisis o de diseño.
IV. Los clientes y los desarrolladores deben trabajar juntos a lo largo del
proyecto. El proceso de desarrollo necesita ser guiado por el cliente, por lo que
la interacción con el equipo es muy frecuente
V. Construir el proyecto en torno a individuos motivados. Darles el entorno
y el apoyo que necesitan y confiar en ellos para conseguir finalizar el
trabajo. Las personas son el principal factor de éxito, todo los demás (proceso,
entorno, gestión, etc.) queda en segundo plano. Si cualquiera de ellos tiene un
efecto negativo sobre los individuos debe ser cambiado.
VI. El diálogo cara a cara es el método más eficiente y efectivo para
comunicar información dentro de un equipo de desarrollo. Los miembros del
equipo deben hablar entre ellos, éste es el principal modo de comunicación. Se
pueden crear documentos pero no todo estará en ellos, no es lo que el equipo
espera.
VII. El software que funciona es la medida principal de progreso. El estado
de un proyecto no viene dado por la documentación generada o la fase en la que
se encuentre, sino por el código generado y en funcionamiento. Por ejemplo, un
60
proyecto se encuentra al 50% si el 50% de los requisitos ya están en
funcionamiento.
VIII. Los procesos ágiles promueven un desarrollo sostenible. Los
promotores, desarrolladores y usuarios deberían ser capaces de mantener
una paz constante. No se trata de desarrollar lo más rápido posible, sino de
mantener el ritmo de desarrollo durante toda la duración del proyecto,
asegurando en todo momento que la calidad de lo producido es máxima.
Finalmente los últimos principios están más directamente relacionados con el
equipo de desarrollo, en cuanto metas a seguir y organización del mismo.
IX. La atención continua a la calidad técnica y al buen diseño mejora la
agilidad. Producir código claro y robusto es la clave para avanzar más
rápidamente en el proyecto.
X. La simplicidad es esencial. Tomar los caminos más simples que sean
consistentes con los objetivos perseguidos. Si el código producido es simple y
de alta calidad será más sencillo adaptarlo a los cambios que puedan surgir.
XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos
organizados por sí mismos. Todo el equipo es informado de las
responsabilidades y éstas recaen sobre todos sus miembros. Es el propio equipo
el que decide la mejor forma de organizarse, de acuerdo a los objetivos que se
persigan.
XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a
ser más efectivo, y según esto ajusta su comportamiento. Puesto que el
entorno está cambiando continuamente, el equipo también debe ajustarse al
nuevo escenario de forma continua. Puede cambiar su organización, sus reglas,
sus convenciones, sus relaciones, etc., para seguir siendo ágil.
61
Los firmantes de los valores y principios de este Manifiesto son: Kent Beck, Mike
Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern,
Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y
Dave Thomas (Beck 2001).
Los principios anteriores son los que recomendaré en el modelo de procesos
para el desarrollo de software en una MPE, ya que son los que más se ajustan a
la escala en recursos, equipo de trabajo y características de una MPE.
Antes de analizar algunas metodologías ágiles, la tabla 6 muestra las principales
diferencias respecto de las metodologías tradicionales (no ágiles) (Letelier and
Penades 2009).
Se ordenan esquemáticamente estas diferencias que no se refieren sólo al
proceso en sí, sino también al contexto de equipo y organización como el de tipo
MPE que es más favorable a cada uno de estas filosofías de procesos de
desarrollo de software.
62
Tabla 6. Diferencias entre metodologías agiles y metodologías tradicionales
(Letelier and Penades 2009)
Aunque los creadores e impulsores de las metodologías ágiles más populares
han suscrito el manifiesto ágil y coinciden con los principios cada metodología
tiene características propias y hace hincapié en algunos aspectos más
específicos.
La Tabla 7 (Letelier and Penades 2009), compara las distintas aproximaciones
ágiles en base a tres parámetros: vista del sistema como algo cambiante, tener
en cuenta la colaboración entre los miembros del equipo y características más
específicas de la propia metodología como son simplicidad, excelencia técnica,
63
resultados, adaptabilidad, etc. También incorpora como referencia no ágil el
Capability Madurity Model (CMM).
Tabla 7. Ranking de agilidad de las diferentes metodologías ágiles
(Letelier and Penades 2009)
Respecto a la tabla 7 y en apoyo de estudios realizados por (Carvajal 2008)
donde se evaluaron diversos aspectos como:, la metodología mejor
documentada, metodologías, metodologías con comunidades, metodología más
utilizada por empresas.
Los resultados se muestran a continuación:
64
Fig. 8. Mejor documentación de las metodologías ágiles
(Carvajal 2008)
Metodologías con certificación (Carvajal 2008):
Dynamic System Development Method tiene DSDM certified.
Feature Driven Development tiene FDD Certified.
Scrum dispone de Scrum Certified! (Carvajal 2008)
Metodologías en Empresas (Carvajal 2008):
Agile Modeling.
Agile Model Driven Development.
Agile Project Management.
Crystal methods.
Dynamic System Development Method.
Feature Driven Development.
Lean Development.
65
Scrum.
Extreme Programming.
Metodologías asociadas a la Agile Alliance (Carvajal 2008):
Agile Modeling.
Agile Model Driven Development.
Crystal methods.
Dynamic System Development Method.
Feature Driven Development.
Internet Speed Development.
Lean Development.
Pragmatic Programming.
Scrum.
Test Driven Development.
Extreme Programing.
Win Win Spiral.
Metodologías con comunidades o alianzas diferentes:
Agile Project Management, con Declaration of Interdependence for modern
management.
Dynamic System Development Method, con DSDM Consortium.
Scrum, con Scrum Alliance (Carvajal 2008).
En base a lo anterior la elección para el desarrollo del Modelo de Procesos para
Micro y Pequeñas Empresas Desarrolladoras de Software (MPMPES), en
conjunto con los niveles de MoProSoft se eligieron 4 metodologías agiles para
complementar el nivel de desarrollo y mantenimiento de software, son las
siguientes:
66
1. XP
2. SCRUM
3. Crystal
4. DSDM (Dynamic Systems Development Method)
Para su análisis se han seguido los siguientes puntos mencionados por (Pekka, Outi et al. 2002)
Procesos. Roles y responsabilidades. Prácticas. Entorno de uso.
2.8 Análisis metodologías ágiles para desarrollo de software
2.8.1 eXtreme Programming (XP)
Extreme Programming es sin duda el defensor de las metodologías ágiles. Nació
como un intento, bastante exitoso, de establecer un conjunto de prácticas que
facilitasen la finalización de los proyectos.
(Beck 2001), el padre de XP, describe la filosofía de XP como principios y
prácticas son de sentido común pero llevadas al extremo, de ahí proviene su
nombre
XP es una metodología ágil centrada en potenciar las relaciones interpersonales
como clave para el éxito en desarrollo de software, promoviendo el trabajo en
equipo, preocupándose por el aprendizaje de los desarrolladores, y propiciando
un buen ambiente de trabajo (Letelier and Penades 2009).
67
1. Procesos
El ciclo de vida de XP está compuesto de seis fases, ver figura 9:
Fig. 9. Fases de XP
(Carvajal 2008)
Exploración
En esta fase los usuarios escriben las historias de usuario que ellos quieren que
sean incluidas en la primera versión (requerimientos). Cada una de las tarjetas
de historia describe una funcionalidad que será añadida al programa.
El equipo de proyecto durante este tiempo se dedica a familiarizarse con las
tecnologías y herramientas que utilizará a lo largo del proyecto, probando las
herramientas y construyendo un prototipo simple para probar las posibilidades
de la arquitectura. El periodo de tiempo de esta fase puede variar desde unas
pocas semanas hasta unos pocos meses, dependiendo de la familiaridad del
equipo con las tecnologías (Letelier and Penades 2009).
Planificación de la Entrega
En esta fase el cliente establece la prioridad de cada historia de usuario, y
correspondientemente, los programadores realizan una estimación del esfuerzo
68
necesario de cada una de ellas. Se toman acuerdos sobre el contenido de la
primera entrega y se determina un cronograma en conjunto con el cliente. Una
entrega debería obtenerse en no más de dos meses. Esta fase dura unos pocos
días.
Las estimaciones de esfuerzo asociado a la implementación de las historias la
establecen los programadores utilizando como medida lo siguiente (Beck 2001):
Por valor: por valor del proyecto.
Por riesgo: el desarrollo de la historia por riesgo.
Por velocidad: el desarrollo determina a qué velocidad (tiempo) se puede
desarrollar el proyecto.
EL valor del proyecto ordena las historias del usuario (requerimientos) por valor:
Críticas: historias sin las cuales el sistema no funciona o no tiene razón
de ser.
Significantes para el proyecto: no son críticas pero tienen gran
importancia para el desarrollo del proyecto.
Funciones extra: requerimientos del usuario que no tienen gran
importancia en el proyecto pero son funcionales.
Los desarrolladores ordenan las historias también por riesgo que pueden ser:
bajo, medio o alto, por ejemplo:
Se le da un puntaje de 0 a 2 a las historias de usuario (requerimientos) en base
a los siguientes factores.
Desarrollable (¿se conocen todos los detalles de la historia?)
Completo (0)
Incompleto (1)
No se sabe (2)
Flexibilidad (¿es aplicable a cambios?)
69
Bajo (0)
Medio (1)
Alto (2)
Complejidad (¿qué tan difícil es para construirlo?)
Simple (0)
Estándar (1)
Complejo (2)
Iteraciones
El plan de entrega está compuesto por iteraciones de no más de tres semanas.
En la primera semana se intenta establecer una arquitectura utilizable a lo largo
del proyecto.
En la elaboración del plan de iteración deben considerarse (Beck 2001):
Historias de usuario no abordadas
Velocidad del proyecto
Pruebas de aceptación no superadas en la iteración anterior
Tareas no terminadas en la iteración anterior
Los usuarios son los que deciden que historias se van a realizar en cada
iteración, sabiendo que en la primera iteración se suele realizar una arquitectura
del sistema que pueda ser utilizada durante el resto del proyecto, seleccionando
aquellas historias que ayuden a construirla. Las pruebas funcionales creadas por
el cliente son ejecutadas al final de cada iteración, de tal manera que al final de
esta fase obtenemos una versión lista para producción.
Al final de la última iteración el sistema está listo para entrar en producción
70
Producción
Esta fase se reduce a una semana, requiere de pruebas adicionales y revisiones
de rendimiento antes de ser trasladado al entorno del cliente, se toman
decisiones de inclusión de nuevas características, las ideas que se proponen
en esta fase son documentadas para su posterior implementación (Beck
2001).
Mantenimiento
Una vez se ha liberada la primera versión a los usuarios, el proyecto se debe
mantener en el entorno de producción siempre y cuando aún hayan iteraciones
en fase de producción. Se deben de realizar nuevas iteraciones a través de
tareas de soporte para el cliente (Beck 2001).
Fin del proyecto
Es cuando el cliente no tiene más historias (requerimientos) que incluir en el
sistema. Esto requiere que el sistema satisfaga las necesidades en rendimiento
y confiabilidad. Se genera la documentación final (Beck 2001).
2. Roles
(Beck 2001) Define los siguientes roles:
Programador
El programador escribe las pruebas unitarias y produce el código del sistema.
Debe existir una comunicación y coordinación adecuada entre los
programadores y otros miembros del equipo.
Cliente
El cliente escribe las historias de usuario y las pruebas funcionales para validar
su implementación. Además, asigna la prioridad a las historias de usuario y
decide cuáles se implementan en cada iteración centrándose en aportar mayor
valor al negocio. El cliente es sólo uno dentro del proyecto pero puede
71
corresponder a un interlocutor que está representando a varias personas que se
verán afectadas por el sistema.
Encargado de pruebas (Tester)
El encargado de pruebas ayuda al cliente a escribir las pruebas funcionales.
Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es
responsable de las herramientas de soporte para pruebas.
Encargado de seguimiento (Tracker)
El encargado de seguimiento proporciona realimentación al equipo en el proceso
XP. Su responsabilidad es verificar el grado de acierto entre las estimaciones
realizadas y el tiempo real dedicado, comunicando los resultados para mejorar
futuras estimaciones.
También realiza el seguimiento del progreso de cada iteración y evalúa si los
objetivos son alcanzables con las restricciones de tiempo y recursos presentes.
Determina cuándo es necesario realizar algún cambio para lograr los objetivos
de cada iteración.
Entrenador (Coach)
Es responsable del proceso global. Es necesario que conozca a fondo el
proceso XP para proveer guías a los miembros del equipo de forma que se
apliquen las prácticas XP y se siga el proceso correctamente.
Consultor
Es un miembro externo del equipo con un conocimiento específico en algún
tema necesario para el proyecto. Guía al equipo para resolver un problema
específico.
72
Gestor (Big boss)
Es el vínculo entre clientes y programadores, ayuda a que el equipo trabaje
efectivamente creando las condiciones adecuadas. Su labor esencial es de
coordinación.
3. Prácticas
(Beck 2001) Define las siguientes prácticas:
El juego de la planificación
El equipo de desarrolladores estima el esfuerzo necesario para implementar las
historias y los clientes determinan los objetivos y tiempos de entrega.
Historias de usuario
Son los requisitos del sistema formulados en una o dos sentencias, en el
lenguaje común del cliente.
Cortas y pequeñas iteraciones
Un sistema simple se libera cada dos o tres meses y las diferentes versiones del
mismo se suceden en periodos no superiores al mes.
Metáforas
El sistema se define utilizando un conjunto de metáforas acordadas entre el
cliente y los programadores. Esta historia compartida guiará todo el proceso
describiendo cómo funciona el sistema.
Diseño simple
Se da gran importancia a la obtención de diseños simples que se puedan
implementar rápidamente, evitando diseños complejos y código extra.
Es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá
añadir funcionalidad si es necesario. La programación extrema apuesta que es
73
más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si
se requiere, que realizar algo complicado y quizás nunca utilizarlo.
Pruebas El desarrollo del software es orientado a pruebas (Test Driven Development) Las
pruebas unitarias se escriben antes que el código y están funcionando
continuamente. Las pruebas funcionales las escriben los clientes.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas,
incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba
antes de la codificación. Véase, por ejemplo, las herramientas de prueba JUnit
orientada a Java, DUnit orientada a Delphi, NUnit para la plataforma.NET o
PHPUnit para PHP. Estas tres últimas inspiradas en JUnit.
Refactorizar
Reestructurar el sistema eliminando duplicaciones, mejorando la comunicación,
simplificando y añadiendo flexibilidad.
Programación por pares
Es la técnica que promulga que dos personas escriban código en la misma
computadora.
Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas
en un mismo puesto. Se supone que la mayor calidad del código escrito de esta
manera -el código es revisado y discutido mientras se escribe- es más
importante que la posible pérdida de productividad inmediata.
Propiedad colectiva
Cualquiera puede compartir cualquier parte de código con cualquier otro
componente del equipo.
74
Integración continúa
Una nueva porción de código es integrada en el código fuente, tan pronto como
este lista. El sistema es integrado y construido muchas veces a lo largo del día,
todas las pruebas son ejecutadas y deben ser pasadas para aceptar la nueva
porción de código.
40 horas a la semana
Se establece un máximo de 40 horas de trabajo semanales.
Disponibilidad del cliente
Los clientes deben estar disponibles y presentes cuando sean requeridos por el
equipo de desarrollo.
Estándares de codificación
Reglas de codificación son establecidas y seguidas por los programadores. Se
enfatiza la comunicación a través del código.
Espacios de trabajo abiertos
Un gran espacio, con cubículos es lo recomendable.
4. Entorno de uso
(Beck 2001) en su opinión cree que a pesar de ser una metodología
ampliamente utilizada, tiene sus límites, los cuales aun no han sido claramente
establecidos. Especifica que XP es una metodología en la que es recomendable
trabajar con equipos de tamaño medio o pequeños, es decir entre tres y veinte
componentes como máximo. Considera intolerable esparcir los componentes de
un mismo equipo en ubicaciones distintas que no sean en la misma planta y
oficina. También considera un factor determinante la cultura de la empresa,
declarando que si observamos resistencia en cualquiera de las prácticas o
técnicas de XP es muy probable que el proyecto fracase. Otro factor clave para
utilizar con éxito XP es la tecnología, si esta no acepta cambios frecuentes o
75
requiere de continua retroalimentación, es muy probable que no consigamos
sacar el proyecto adelante.
En mi opinión esta metodología es de las más completas, mayor documentadas
y con mayor aceptación que cumple con muchos de los requisitos e ideologías
agiles, y las 6 fases del ciclo de vida para el desarrollo de software me parecen
ideales para el desarrollo de software de una MPE.
2.8.2 Scrum
La primera vez que se asocio el término Scrum a los procesos de desarrollo fue
en 1986, cuando Nonaka y Takeuchi presentaron su artículo The New Product
Development Game. Nonaka y Takeuchi presentaban en este artículo un
proceso adaptativo, rápido y auto-organizado de desarrollo de productos
(Carvajal 2008).
Scrum es un proceso en el que se aplican de manera regular un conjunto
de buenas prácticas para trabajar colaborativamente, en equipo, y obtener el
mejor resultado posible de un proyecto. Estas prácticas se apoyan unas a otras
y su selección tiene origen en un estudio de la manera de trabajar de equipos
altamente productivos (Agiles 2011).
En Scrum se realizan entregas parciales y regulares del producto final,
priorizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum
está especialmente indicado para proyectos en entornos complejos, donde se
necesita obtener resultados pronto, donde los requisitos son cambiantes o poco
definidos, donde la innovación, la competitividad, la flexibilidad y la productividad
son fundamentales (Agiles 2011).
76
Scrum también se utiliza para resolver situaciones en que no se está entregando
al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes
se disparan o la calidad no es aceptable, cuando se necesita capacidad de
reacción ante la competencia, cuando la moral de los equipos es baja y la
rotación alta, cuando es necesario identificar y solucionar ineficiencias
sistemáticamente o cuando se quiere trabajar utilizando un proceso
especializado en el desarrollo de producto (Letelier and Penades 2009).
1. Procesos
En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos
(iteraciones de un mes natural y hasta de dos semanas, si así se necesita).
Cada iteración tiene que proporcionar un resultado completo, un incremento de
producto final que sea susceptible de ser entregado con el mínimo esfuerzo al
cliente cuando lo solicite (Agiles 2011).
El proceso parte de la lista de objetivos/requisitos priorizada del producto, que
actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos
balanceando el valor que le aportan respecto a su coste y quedan repartidos en
iteraciones y entregas. De manera regular el cliente puede maximizar la utilidad
de lo que se desarrolla y el retorno de inversión mediante la replanificación de
objetivos que realiza al inicio de cada iteración, ver figura 10:
77
Fig. 10. Fases de SCRUM
(Agiles 2011)
Planificación de la iteración
El primer día de la iteración se realiza la reunión de planificación de la iteración.
Tiene dos partes:
Selección de requisitos (4 horas máximo).
El cliente presenta al equipo la lista de requisitos priorizada del producto o
proyecto. El equipo pregunta al cliente las dudas que surgen y selecciona los
requisitos más prioritarios que se compromete a completar en la iteración, de
manera que puedan ser entregados si el cliente lo solicita.
78
Planificación de la iteración (4 horas máximo).
El equipo elabora la lista de tareas de la iteración necesarias para desarrollar los
requisitos a que se ha comprometido. La estimación de esfuerzo se hace de
manera conjunta y los miembros del equipo se auto asignan las tareas (Agiles
2011).
Ejecución de la iteración
Cada día el equipo realiza una reunión de sincronización (15 minutos
máximo). Cada miembro del equipo inspecciona el trabajo que el resto está
realizando (dependencias entre tareas, progreso hacia el objetivo de la iteración,
obstáculos que pueden impedir este objetivo) para poder hacer las adaptaciones
necesarias que permitan cumplir con el compromiso adquirido. En la reunión
cada miembro del equipo responde a tres preguntas:
¿Qué he hecho desde la última reunión de sincronización?
¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener?
Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir con
su compromiso y de que no se merme su productividad.
Elimina los obstáculos que el equipo no puede resolver por sí mismo.
Protege al equipo de interrupciones externas que puedan afectar su compromiso
o su productividad (Agiles 2011).
Inspección y adaptación
El último día de la iteración se realiza la reunión de revisión de la iteración. Tiene
dos partes:
Demostración (4 horas máximo).
El equipo presenta al cliente los requisitos completados en la iteración, en forma
de incremento de producto preparado para ser entregado con el mínimo
esfuerzo. En función de los resultados mostrados y de los cambios que haya
79
habido en el contexto del proyecto, el cliente realiza las adaptaciones necesarias
de manera objetiva, ya desde la primera iteración, replanificando el proyecto.
Retrospectiva (4 horas máximo).
El equipo analiza cómo ha sido su manera de trabajar y cuáles son los
problemas que podrían impedirle progresar adecuadamente, mejorando de
manera continua su productividad. El Facilitador se encargará de ir eliminando
los obstáculos identificados (Agiles 2011).
2. Roles
Facilitador (Scrum Master)
Es importante darse cuenta que Scrum Master es más que un rol, es la
responsabilidad de funcionamiento de modelo, por tanto muchas veces es
aconsejable utilizar a personas y puestos más adecuados según la organización.
Un Scrum Master debe interactuar tanto con el equipo como con el cliente y con
los gestores (Agiles 2011).
Lidera al equipo llevando a cabo las siguientes responsabilidades:
Velar por que todos los participantes del proyecto sigan las reglas y proceso de
Scrum, encajándolas en la cultura de la organización, y guiar la colaboración
entre el equipo y con el cliente de manera que las sinergias sean máximas. Esto
implica:
Asegurar que la lista de requisitos priorizada esté preparada antes de la
siguiente iteración.
Facilitar las reuniones de Scrum (planificación de la iteración, reuniones
diarias de sincronización del equipo, demostración, retrospectiva), de
manera que sean productivas y consigan sus objetivos.
Enseñar al equipo a auto gestionarse. No da respuestas, si no que guía al
equipo con preguntas para que descubra por sí mismo una solución
(Agiles 2011).
80
Quitar los impedimentos que el equipo tiene en su camino para conseguir el
objetivo de cada iteración (proporcionar un resultado útil al cliente de la manera
más efectiva) y poder finalizar el proyecto con éxito. Estos obstáculos se
identifican de manera sistemática en las reuniones diarias de sincronización del
equipo y en las reuniones de retrospectiva.
Proteger y aislar al equipo de interrupciones externas durante la ejecución de la
iteración (introducción de nuevos requisitos). De esta manera, el equipo puede
mantener su productividad y el compromiso que adquirió sobre los requisitos que
completaría en la iteración (notar, que el equipo debe reservar tiempo para
colaborar con al cliente en la preparación de la lista de requisitos para la próxima
iteración) (Agiles 2011).
Equipo de desarrollo
Grupo de personas que de manera conjunta desarrollan el producto del
proyecto. Tienen un objetivo común, comparten la responsabilidad del trabajo
que realizan (así como de su calidad) en cada iteración y en el proyecto.
El tamaño del equipo está entre 5 y 9 personas. Por debajo de 5 personas
cualquier imprevisto o interrupción sobre un miembro del equipo compromete
seriamente el compromiso que han adquirido y, por tanto, el resultado que se va
a entregar al cliente al finalizar la iteración. Por encima de 9 personas, la
comunicación y colaboración entre todos los miembros se hace más difícil y se
forma subgrupos (Agiles 2011).
Es un equipo auto organizado, que comparte información y cuyos miembros
confían entre ellos. Realiza de manera conjunta las siguientes actividades en la
definición de (Agiles 2011):
Seleccionar los requisitos que se compromete a completar en una
iteración, de forma que estén preparados para ser entregados al cliente.
81
Estimar la complejidad de cada requisito en la lista de requisitos priorizada
del producto o proyecto.
En la reunión de planificación de la iteración decide cómo va a realizar su
trabajo
Seleccionar los requisitos que pueden completar en cada iteración,
realizando al cliente las preguntas necesarias.
Identificar todas las tareas necesarias para completar cada requisito.
Estimar el esfuerzo necesario para realizar cada tarea.
Cada miembro del equipo se auto asigna a las tareas.
Durante la iteración, trabajar de manera conjunta para conseguir los
objetivos de la iteración. Cada especialista lidera el trabajo en su área y el
resto colaboran si es necesario para poder completar un requisito.
Al finalizar la iteración
Demostrar al cliente los requisitos completados en cada iteración.
Hacer una retrospectiva la final de cada iteración para mejorar de forma
continua su manera de trabajar.
El equipo es multidisciplinar
Los miembros del equipo tienen las habilidades necesarias para poder
identificar y ejecutar todas las tareas que permiten proporcionar al cliente
los requisitos comprometidos en la iteración.
Tienen que depender lo mínimo de personas externas al equipo, de
manera que el compromiso que adquieren en cada iteración no se ponga
en peligro.
Se crea una sinergia que permite que el resultado sea más rico al nutrirse
de las diferentes experiencias, conocimientos y habilidades de todos.
Colaboración creativa.
82
Los miembros del equipo dedicarse al proyecto a tiempo completo para evitar
dañar su productividad por cambios de tareas en diferentes proyectos, para
evitar interrupciones externas y así poder mantener el compromiso que
adquieren en cada iteración.
Todos los miembros del equipo trabajan en la misma localización física, para
poder maximizar la comunicación entre ellos mediante conversaciones cara a
cara, diagramas en pizarras blancas, etc.
El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo
mínimo posible, para poder aprovechar el esfuerzo que les ha costado construir
sus relaciones interpersonales, engranarse y establecer su organización del
trabajo (Agiles 2011).
Cliente
Las responsabilidades del Cliente (que puede ser interno o externo a la
organización) son:
Ser el representante de todas las personas interesadas en los resultados del
proyecto (internas o externas a la organización, promotores del proyecto y
usuarios finales [idealmente también debería ser un usuario clave] o
consumidores finales del producto) y actuar como interlocutor único ante el
equipo, con autoridad para tomar decisiones y definir los objetivos del producto o
proyecto (Agiles 2011).
Dirigir los resultados del proyecto
Es el propietario de la planificación del proyecto: crea y mantiene la lista
priorizada con los requisitos necesarios para cubrir los objetivos del
producto o proyecto, conoce el valor que aportará cada requisito.
Reparte los objetivos/requisitos en iteraciones y establece un calendario
de entregas.
Antes de iniciar cada iteración replanifica el proyecto en función de los
requisitos que aportan más valor en ese momento, de los requisitos
completados en la iteración anterior y del contexto del proyecto en ese
83
momento (demandas del mercado, movimientos de la competencia, etc.)
(Agiles 2011).
Colaborar con el equipo para planificar, revisar y dar detalle a los objetivos
de cada iteración
Participar en la reunión de planificación de iteración, proponiendo los
requisitos más prioritarios a desarrollar, respondiendo a las dudas del
equipo y detallando los requisitos que el equipo se comprometer a hacer.
Estar disponible durante el curso de la iteración para responder a las
preguntas que puedan aparecer.
No cambiar los requisitos que se están desarrollando en una iteración,
una vez está iniciada.
Participar en la reunión de demostración de la iteración, revisando los
requisitos completados (Agiles 2011).
3. Prácticas
Scrum dispone de prácticas y herramientas para la gestión de las diferentes
fases de Scrum (Carvajal 2008). A continuación las principales prácticas y
herramientas:
Lista de Objetivos (Product Backlog)
Define los requisitos del sistema o el trabajo a hacer a lo largo del proyecto. Está
compuesto por una lista de requisitos de negocio y técnicos, actualizados y
priorizados.
La lista de objetivos/requisitos priorizada representa la visión y expectativas del
cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es
el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del
equipo, quien proporciona el coste estimado de completar cada requisito). Dado
que reflejar las expectativas del cliente, esta lista permite involucrarle en la
dirección de los resultados del producto o proyecto.
84
Contiene los objetivos/requisitos de alto nivel del producto o proyecto, que
se suelen expresar en forma de historias de usuario. Para cada
objetivo/requisito se indica el valor que aporta al cliente y el coste
estimado de completarlo. La lista está priorizada balanceando el valor que
cada requisito aporta al negocio frente al coste estimado que tiene su
desarrollo, es decir, basándose en el Retorno de la Inversión (ROI).
En la lista se indican las posibles iteraciones y las entregas esperadas por
el cliente (los puntos en los cuales desea que se le entreguen los
objetivos/requisitos completados hasta ese momento), en función de la
velocidad de desarrollo del (los) equipo(s) que trabajará(n) en el proyecto.
Es conveniente que el contenido de cada iteración tenga una coherencia,
de manera que se reduzca el esfuerzo de completar todos sus objetivos.
La lista también tiene que considerar los riesgos del proyecto e incluir los
requisitos o tareas necesarios para mitigarlos (Agiles 2011).
En la tabla 8 se muestra un ejemplo de Lista de objetivos:
Tabla 8. Lista de objetivos en Scrum
(Agiles 2011)
85
Planificación de la Iteración (Sprint Planning)
La planificación de las tareas a realizar en la iteración se divide en dos partes:
Primera parte de la reunión. Se realiza en un estimado de tiempo como
máximo 4 horas
El cliente presenta al equipo la lista de requisitos priorizada del producto o
proyecto, pone nombre a la meta de la iteración (de manera que ayude a tomar
decisiones durante su ejecución) y propone los requisitos más prioritarios a
desarrollar en ella.
El equipo examina la lista, pregunta al cliente las dudas que le surgen, añade
más condiciones de satisfacción y selecciona los objetivos/requisitos más
prioritarios que se compromete a completar en la iteración, de manera que
puedan ser entregados si el cliente lo solicita (Agiles 2011).
Segunda parte de la reunión. Se realiza en un estimado de tiempo como
máximo 4 horas
El equipo planifica la iteración, elabora la táctica que le permitirá conseguir el
mejor resultado posible con el mínimo esfuerzo. Esta actividad la realiza el
equipo dado que ha adquirido un compromiso, es el responsable de organizar su
trabajo y es quien mejor conoce cómo realizarlo.
Define las tareas necesarias para poder completar cada objetivo/requisito,
creando la lista de tareas de la iteración (Sprint Backlog) basándose en la
definición de completado.
Realiza una estimación conjunta del esfuerzo necesario para realizar cada tarea.
Cada miembro del equipo se autoasigna a las tareas que puede realizar (Agiles
2011).
Lista de tareas de la iteración (Sprint Backlog)
Lista de tareas que el equipo elabora en la reunión de planificación de la
iteración (Sprint planning) como plan para completar los objetivos/requisitos
86
seleccionados para la iteración y que se compromete a demostrar al cliente al
finalizar la iteración, en forma de incremento de producto preparado para ser
entregado.
Esta lista permite ver las tareas donde el equipo está teniendo problemas y no
avanza, con lo que le permite tomar decisiones al respecto.
Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo
pendiente para finalizarlas y la auto asignación que han hecho los miembros del
equipo (Agiles 2011).
En la tabla 9 se muestra un ejemplo de lista de tareas de la iteración:
Tabla 9. Lista de tareas de la iteración en Scrum
(Agiles 2011)
87
Reunión diaria de sincronización del equipo (Scrum daily meeting)
El objetivo de esta reunión es facilitar la transferencia de información y la
colaboración entre los miembros del equipo para aumentar su productividad, al
poner de manifiesto puntos en que se pueden ayudar unos a otros.
Cada miembro del equipo inspecciona el trabajo que el resto está realizando
(dependencias entre tareas, progreso hacia el objetivo de la iteración, obstáculos
que pueden impedir este objetivo) para al finalizar la reunión poder hacer las
adaptaciones necesarias que permitan cumplir con el compromiso conjunto que
el equipo adquirió para la iteración (en la reunión de planificación de la iteración)
(Agiles 2011).
Cada miembro del equipo debe responder las siguientes preguntas en un lapso
de tiempo como máximo 15 minutos:
¿Qué he hecho desde la última reunión de sincronización? ¿Pude hacer todo lo
que tenía planeado? ¿Cuál fue el problema?
¿Qué voy a hacer a partir de este momento?
¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos en esta
iteración y en el proyecto?
Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la iteración,
donde se actualiza el estado y el esfuerzo pendiente para cada tarea, así como
con el gráfico de horas pendientes en la iteración (Agiles 2011).
Demostración de requisitos completados (Sprint Review)
Reunión informal donde el equipo presenta al cliente los requisitos completados
en la iteración, en forma de incremento de producto preparado para ser
entregado con el mínimo esfuerzo, haciendo un recorrido por ellos lo más real y
cercano posible al objetivo que se pretende cubrir.
88
En función de los resultados mostrados y de los cambios que haya habido en el
contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera
objetiva, ya desde la primera iteración, replanificando el proyecto.
Se realiza en un lapso de tiempo como máximo 4 horas (Agiles 2011).
Retrospectiva (Sprint Retrospective)
Con el objetivo de mejorar de manera continua su productividad y la calidad del
producto que está desarrollando, el equipo analiza cómo ha sido su manera de
trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que
se comprometió al inicio de la iteración y por qué el incremento de producto que
acaba de demostrar al cliente era lo que él esperaba o no:
¿Qué cosas han funcionado bien?
¿Cuales hay que mejorar?
¿Qué cosas quiere probar hacer en la siguiente iteración?
¿Qué ha aprendido?
¿Cuáles son los problemas que podrían impedirle progresar adecuadamente? El
Facilitador se encargará de ir eliminando los obstáculos identificados que el
propio equipo no pueda resolver por sí mismo.
Notar que esta reunión se realiza después de la reunión de demostración al
cliente de los objetivos conseguidos en la iteración, para poder incorporar su
feedback y cumplimiento de expectativas como parte de los temas a tratar en la
reunión de retrospectiva
Se realiza en un lapso de tiempo como máximo 3 horas (si la iteración es
mensual) (Agiles 2011).
Gráficos de trabajo pendiente (Burndown charts)
Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la
que se está completando los objetivos/requisitos. Permite extrapolar si el Equipo
podrá completar el trabajo en el tiempo estimado (Agiles 2011).
Se pueden utilizan los siguientes gráficos de esfuerzo pendiente:
89
Días pendientes para completar los requisitos del producto o proyecto
(product burndown chart), realizado a partir de la lista de requisitos priorizada
(Product Backlog).
Horas pendientes para completar las tareas de la iteración (sprint
burndown chart), realizado a partir de la lista de tareas de la iteración (Iteration
Backlog) (Agiles 2011).
Este tipo de gráfico permite realizar diversas simulaciones: ver cómo se aplazan
las fechas de entrega si se le añaden requisitos, ver cómo se avanzan si se le
quitan requisitos o se añade otro equipo, etc. (Agiles 2011).
En las figuras 11 y 12 se muestran los ejemplos:
Fig. 11. Gráfico a partir de lista de requisitos en SCRUM
(Agiles 2011)
90
Fig. 12. Gráfico a partir de horas pendientes de iteración en SCRUM
(Agiles 2011)
4. Entorno de uso
Scrum es una metodología que es usada cuando el cliente requiere tener
resultados a corto plazo, cambiar a menudo los requisitos del proyecto, ver si se
cumplen sus expectativas a lo largo del desarrollo (Carvajal 2008).
Por parte de la empresa desarrolladora de software ofrece tener equipos
altamente productivos y motivados, solucionar los problemas que impiden que
los equipos progresen, utilizar un proceso de gestión ligero aún en proyectos
complejos (Carvajal 2008).
Scrum es una metodología que cubre a la perfección las áreas de gestión de
proyecto ágiles. La mayoría de los esfuerzos se están centrando en combinar
metodologías ágiles que sean complementarias, como por ejemplo Scrum y XP.
Es de resaltar las diversas prácticas y herramientas graficas que maneja Scrum
(Agiles 2011).
91
2.8.3 Metodologías Crystal
Se trata de un conjunto de metodologías para el desarrollo de software
caracterizadas por estar centradas en las personas que componen el equipo (de
ellas depende el éxito del proyecto) y la reducción al máximo del número de
artefactos producidos. Han sido desarrolladas por Alistair Cockburn. El
desarrollo de software se considera un juego cooperativo de invención y
comunicación, limitado por los recursos a utilizar. El equipo de desarrollo es un
factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y
destrezas, así como tener políticas de trabajo en equipo definidas. Estas
políticas dependerán del tamaño del equipo, estableciéndose una clasificación
por colores, por ejemplo Crystal Clear (3 a 8 miembros) y Crystal Orange (25 a
50 miembros). En este análisis analizare Crystal Clear, ya que es el acorde para
una MPE (Carvajal 2008).
1. Procesos
La familia de metodologías Crystal no especifica ningún ciclo de vida concreto, ni
ningún modelo de procesos, en vez de eso lo que hace es determinar una guía
de las políticas estándar, productos de trabajo, asuntos locales, herramientas,
estándares y roles (Carvajal 2008).
Políticas estándar
Son las prácticas necesarias que se aplican a lo largo de todo proceso de
desarrollo del software. Se recomiendan las siguientes:
Entregas incrementales hechas regularmente.
Seguimiento del progreso mediante hitos claves basados en entregas de
software, más que en entrega de documentos.
Usuario involucrado directamente.
Pruebas automáticas regresivas de las funcionalidades.
Dos usuarios criticando cada entrega.
92
Talleres del producto y puesto a punto de la metodología, en medio y al
final de cada iteración (Carvajal 2008).
Artefactos
Secuencia de entregas, modelado de objetos, manual de usuario, casos de
pruebas y código.
A modo particular Clear incluye anotaciones de los casos de uso y
características del producto. La planificación en Clear se pide que se haga
pensando en las diferentes entregas y reuniones con los clientes (Carvajal
2008).
Asuntos locales
Son asuntos locales aquellos procedimientos que Crystal especifica que deben
hacerse, pero el cómo, es responsabilidad del proyecto. Por ejemplo, la
documentación del proyecto es necesaria, pero como se haga es un asunto local
del proyecto (Carvajal 2008).
Herramientas
Las herramientas que necesita la metodología Crystal Clear son un compilador,
una herramienta de control de versiones y una herramienta de gestión, además
de pizarras, que ayudan a sustituir algunos documentos escritos y la realización
de reuniones (Carvajal 2008).
Actividades
Crystal propone seleccionar las notaciones estándares, convenciones de diseño,
estándares de formato y de calidad, a ser usadas en un proyecto.
Las actividades se verán en mayor detalle en el punto de prácticas.
En la figura 13 se pueden ver las principales actividades que se llevan a cabo en
una iteración.
93
Fig. 13. Iteración en Crystal
(Carvajal 2008)
2. Roles
Sponsor.
Diseñador de programas senior.
Diseñador de programas.
Usuario. A tiempo parcial como mínimo (Carvajal 2008).
3. Prácticas
Planificación por etapas
Básicamente consiste en la planificación del siguiente incremento del sistema.
La planificación debe finalizar con una versión ejecutable cada tres o cuatro
meses como máximo. El equipo selecciona los requisitos que serán
94
implementados en el incremento y planifican lo que creen que serán capaces de
hacer (Carvajal 2008).
Revisiones y resúmenes
Cada incremento consta de diferentes iteraciones y cada iteración incluye las
siguientes actividades: construcción, demostración y resumen de los objetivos
del incremento (Carvajal 2008).
Monitorización
Los progresos del proyecto son monitorizados a partir de las diferentes entregas
del equipo durante el proceso de desarrollo. El progreso se mide con los hitos
clave y la estabilidad de las fases (muy inestable, fluctúa y lo suficiente estable
para revisar) (Carvajal 2008).
Paralelismo y flujo
Cuando el monitor de estabilidad nos indica un estado lo suficientemente estable
para su revisión, entonces es el momento para pasar a la siguiente tarea
(Carvajal 2008).
Técnicas de puesta a punto de la metodología
Se basa en la realización de entrevistas y talleres elaborar una metodología
específica para cada proyecto.
Una de las ideas centrales es modificar o fijar el proceso de desarrollo, es muy
importante ver que cada vez que finaliza una iteración, el equipo tiene más
experiencia y puede modificar aspectos para que la metodología se adapte
mejor al proyecto (Carvajal 2008).
Punto de vista del usuario.
En Crystal Clear se sugiere la opinión de dos usuarios por cada versión del
producto liberada (Carvajal 2008).
95
4. Entorno de uso
La metodología Crystal Clear tiene ciertas limitaciones que no les permiten
desarrollar proyectos con un alto componente crítico (altos factores de riesgo),
de la mismo forma que ambas prescriben su uso a entornos locales. Crystal
Clear restringe su entorno de trabajo a un solo equipo, situado en una misma
oficina (Carvajal 2008).
La guía de trabajo que presenta Crystal Clear es altamente recomendable para
equipos pequeños. Da flexibilidad y prioriza la parte humana (como todas las
Metodologías Agiles), apuntando a lograr eficiencia, habitabilidad y confianza en
los miembros del equipo (Carvajal 2008).
Presta especial importancia a la ubicación física del grupo, donde la
comunicación cumple el principal rol. La entrega frecuente de código confiable y
funcional mantiene el foco y evita distracciones.
El equipo es el que elige qué técnicas aplicar según lo que consideren apropiado
en cada proyecto (Letelier and Penades 2009).
2.8.4 Método de desarrollo de sistemas dinámicos (DSDM)
DSDM tiene sus orígenes en 1994 y desde entonces se ha convertido en uno de
los frameworks de desarrollo rápido de aplicaciones más utilizados y conocidos.
DSDM es un framework sin ánimo de lucro y sin propietarios para el desarrollo
rápido de aplicaciones, mantenido por el DSDM Consortium.
La idea fundamental de DSDM se basa en que en vez de fijar las
funcionalidades de un producto y después el tiempo y el coste, fijar primero el
tiempo y el coste y con esto fijado, determinar las funcionalidades que se
pueden implementar en el producto (Carvajal 2008).
96
1. Procesos
DSDM está formado por las cinco siguientes fases: estudio de viabilidad, estudio
de negocio, modelo funcional de las iteraciones, iteraciones de diseño y
construcción e implementación, ver figura 14:
Fig. 14. Fases de DSDM
(Carvajal 2008)
Las dos primeras fases son secuenciales y se hacen solo una vez, mientras que
las otras tres son iterativas e incrementales a lo largo de todo el proceso de
desarrollo. DSDM trata las iteraciones como cajas de tiempo y estas duran un
predeterminado periodo de tiempo, una vez finalizadas, las iteraciones también
finalizan. El tiempo de duración de una iteración se decide de antes de iniciarla y
normalmente va desde unos pocos días, hasta unas pocas semanas (Carvajal
2008).
Estudio de viabilidad
En esta fase se estudia la idoneidad de utilizar DSDM en el proyecto que nos
ocupa y por tanto, se decide si utilizarlo o no. Otros aspectos que se tienen en
97
cuenta en el estudio de viabilidad son las posibilidades técnicas de llevar a cabo
el proyecto y los riesgos presentes.
De esta fase se obtienen dos artefactos o productos de trabajo, son un reporte
de viabilidad y un esbozo del plan de desarrollo del proyecto. A veces, si la
tecnología con la que tratamos es desconocida, se realizar un prototipo para
conocerla mejor y ver sus posibilidades. Esta fase no debe pasar de unas pocas
semanas (Carvajal 2008).
Estudio de negocio
Esta es la fase en que las características principales del negocio y la tecnología,
son evaluadas. La manera recomendada del llevar a cabo esta fase es mediante
la realización de talleres, donde participaran los clientes más expertos en la
materia, de tal manera que sean capaces de identificar todas las facetas
fundamentales del sistema y acordar unas prioridades de desarrollo. Los
procesos de negocio y las clases de usuario afectadas se describirán en la
definición del área de negocio. Descripciones de alto nivel de los procesos de
negocio se incluyen en la definición del área de negocio, ya sea usando
diagramas Entidad Relación u objetos del modelo de negocio. Otros artefactos
que se generan en esta fase son una definición de la arquitectura del sistema y
un esbozo del plan de desarrollo del prototipo (Carvajal 2008).
Modelo funcional de las iteraciones
Es la primera de las fases iterativas e incrementales. En cada iteración los
contenidos y el enfoque son planificados, la iteración continua y los resultados
son analizados para mejorar las futuras iteraciones. Se realizan las tareas tanto
de análisis como de codificación, se construyen prototipos, y las experiencias
extraídas de ellos son para mejorar los modelos de análisis. Los prototipos no se
descartan por completo, sino que a medida que su calidad va aumentando, se
van incluyendo en el sistema final. Se genera un modelo funcional, el cual
contiene el código del prototipo y los modelos de análisis. Otra tarea que se
realiza en cada una de las iteraciones es la realización de pruebas.
98
Otros artefactos que se generan en esta fase son una lista ordenada en función
de la prioridad de las funciones que son entregadas al final de la iteración y
documentación del prototipo funcional, que incluyen comentarios de los usuarios
sobre la iteración actual.
También se genera un listado con los requisitos no funcionales y un análisis de
los riegos que pueden surgir a lo largo del desarrollo (Carvajal 2008).
Iteraciones de diseño y construcción
Estas son las fases en las que principalmente se construye el sistema. El
resultado final es un sistema probado, que como al menos satisface los mínimos
requisitos establecidos. Esta fase es iterativa e incremental y el diseño y los
prototipos funcionales son revisados por los clientes, ocasionando los cambios
que sean necesarios en el sistema con sus aportaciones y comentarios (Carvajal
2008).
Implementación
En esta fase se pasa del entorno de desarrollo al entorno de producción. Se da
formación a los usuarios y finalmente se entrega el sistema para que lo utilicen.
En esta fase, además de la liberación del sistema, también se deben entregar un
manual de usuario y un informe de revisión del proyecto. En este último
documento, se especifican los futuros desarrollos necesarios, si es que los hay.
DSDM define cuatro posibles situaciones para los futuros desarrollos:
1. No se necesite realizar mayor desarrollo.
2. Se han dejado sin realizar un conjunto de requisitos importantes y en este
caso se tiene que reiniciar todo el proceso desde el principio.
3. Se han quedado algunas funcionalidades o críticas sin implementar,
entonces se vuelve a la fase de modelo funcional de iteraciones.
99
4. La última situación es que algunos problemas técnicos no han podido ser
resueltos debido a falta de tiempo, ahora se corregirán realizando las
iteraciones que hagan falta desde la fase de diseño e implementación
(Carvajal 2008).
2. Roles
Desarrolladores y desarrollador sénior
Son los únicos roles que establece a nivel de desarrollo y cubren todos los
posibles papeles de las tareas de desarrollo como son el análisis, diseño,
implementación e incluso pruebas (Carvajal 2008).
Coordinador técnico
Es el responsable de la calidad técnica del proyecto y define la arquitectura del
sistema (Carvajal 2008).
El usuario embajador
Sus principales tareas son las de aportar el conocimiento de la comunidad de
usuarios al proyecto y de informar a los usuarios de los progresos del proyecto
(Carvajal 2008).
El asesor de los usuarios
Puede ser cualquier usuario que represente un importante punto de vista para el
proyecto. Por ejemplo un miembro del departamento de tecnología o un auditor
financiero, etc. (Carvajal 2008).
Visionario
Es un usuario que participa del proyecto y que tiene una percepción más real de
los objetivos de negocio del sistema y del proyecto. Normalmente suele ser el
tutor del proyecto y el que tuvo la idea inicial para realizarlo. Entre sus tareas se
encuentra supervisar que se identifican todos los requisitos de negocio y que se
van implementando en el orden de importancia correcto (Carvajal 2008).
100
Sponsor ejecutivo
Es la persona de la compañía que tiene la autoridad financiera y la
responsabilidad. Por ende, el sponsor ejecutivo es el que suele tener la última
palabra en la toma de decisiones (Carvajal 2008).
3. Prácticas Existen nueve prácticas que definen la ideología y las bases de toda actividad en
DSDM (Carvajal 2008).
La involucración activa del usuario es imperativa
Unos pocos usuarios experimentados deben seguir todo el proceso de desarrollo
para asegurar una valoración correcta y a tiempo.
Los equipos DSDM deben tener libertad poder para tomar decisiones
En rápidos ciclos de desarrollo no se pueden tolerar largos periodos de decisión.
Los usuarios involucrados tienen el conocimiento para decidir hacia donde se
dirige el proyecto.
El objetivo es la entrega frecuente de productos
Las decisiones erróneas pueden ser solventadas si los ciclos son cortos y los
usuarios proporcionan unas valoraciones correctas.
Adecuación a los objetivos de negocio es el criterio esencial para aceptar
las entregas
Si los objetivos de negocio aún no han sido satisfechos no podemos dedicarnos
a mejorar técnicamente el sistema.
101
El desarrollo iterativo e incremental es necesario para convergir en una
solución de negocio correcta
Rara vez los requisitos no varían a lo largo del proyecto, si dejamos al sistema
evolucionar a través del desarrollo iterativo, los errores se pueden corregir y
encontrar antes.
Todos los cambios durante el desarrollo son reversibles
A lo largo de todo el proyecto es sencillo tomar un camino incorrecto, pero con
cortas iteraciones y asegurando que todos nuestro pasos se puedan deshacer,
los caminos incorrectos pueden ser rectificados.
Los requisitos son la línea de base en alto nivel
Congelar los requisitos se puede hacer solo a alto nivel, para que los detalles de
los requisitos puedan variar libremente. De este modo fijamos los requisitos
esenciales en etapas tempranas del proyecto.
Las pruebas se integran a lo largo del ciclo de vida
Todos los componentes del sistema deberían ser probados por los
desarrolladores y usuarios al mismo tiempo que son desarrollados.
Un enfoque colaborativo y cooperativo compartido por todos los
integrantes de la empresa es esencial
Las decisiones de lo que es entregado y de lo que falta por realizar es siempre
un compromiso y requiere aceptación por todas las partes que participan.
4. Entorno de uso El tamaño de los equipos en DSDM varía desde un mínimo de dos integrantes
hasta seis, pudiendo coexistir múltiples equipos en un mismo proyecto. La razón
de que como mínimo haya dos componentes por equipo radica en que como
mínimo debe haber un desarrollador y un cliente. El número máximo ha sido
102
extraído de diferentes experiencias con las metodologías. DSDM se puede
aplicar tanto a proyectos grandes como pequeños, siempre que los sistemas
grandes sean divisibles en componentes que puedan ser desarrollados por
equipos pequeños (Carvajal 2008).
Se sugiere la utilización de DSDM en aplicaciones empresariales antes que en
aplicaciones científicas (Carvajal 2008).
La selección de buenas prácticas, métodos y herramientas, que hayan sido
probadas es sin duda una estrategia inteligente, disponer de varias
metodologías donde elegir nos facilitará mucho ante un entorno hostil que
pudiera afectar los requisitos y objetivos de un proyecto software (Letelier and
Penades 2009).
En este análisis de estas cuatro metodologías da paso al siguiente capítulo del
desarrollo del modelo MPMPES donde en conjunto con MoProSoft y estas
metodologías agiles aplicadas al nivel de desarrollo y mantenimiento de software
se adapta a las principales virtudes y características de una MPE.
103
CAPÍTULO III
Desarrollo del
Modelo MPMPES
104
3.1 Modelo propuesto para el desarrollo
El modelo MPMPES se desarrollo siguiendo los procesos considerados en
MoProSoft y las Metodologías Ágiles, integrando las fases del ciclo de vida
tradicionales con los procesos de administración de proyectos y los procesos de
soporte necesarios para un desarrollo satisfactorio de un proyecto software en
una MPE.
MoProSoft considera tres bases organizacionales o niveles estructurales donde
los procesos son organizados (ver figura 3):
1. Alta Dirección, contiene la gestión de los procesos del negocio, su
propósito es establecer la razón de existencia de la organización,
sus objetivos y las condiciones requeridas para lograrlos.
2. Gerencia, consiste en la gestión de Procesos, gestión de Proyectos
y gestión de Recursos.
3. Operación, consiste en la gestión de Proyectos Específicos,
Desarrollo y Mantenimiento de Software.
En este Modelo MPMPES, considere 2 niveles estructurales que se apegan a las
características organizacionales y funcionales de un MPE:
1. Gerencia, contiene la gestión de procesos del negocio, gestión de
proyectos y gestión de recursos.
2. Operación, consiste en la gestión de proyectos, y Desarrollo y
Mantenimiento de Software.
105
En la figura 15 se muestran los niveles de MPMPES:
Fig. 15. Niveles de MPMPES
A continuación describiré los 2 niveles, las actividades y requisitos de cada
proceso involucrado.
106
3.2 Gerencia (GER)
3.2.1 Gestión de negocio, proyectos y recursos El propósito de la gestión del negocio es establecer el porqué de la existencia de
la organización, sus objetivos principales y condiciones para lograrlos, es
necesario considerar las necesidades de los clientes y los resultados obtenidos
para proponer cambios y mejoras continuas.
El propósito de la gestión de proyectos es asegurar que los proyectos
contribuyan al cumplimiento de los objetivos y estrategias de la organización.
El propósito de la gestión de recursos, es conseguir y dotar a la organización de
recursos humanos, infraestructura, ambiente de trabajo y proveedores, así como
la creación de una base de conocimiento de la organización.
Objetivo:
O1 Lograr que la organización trabaje en función de un plan estratégico
mediante la correcta implementación y mejoras del mismo si así se requiere.
O2 Cumplir con el Plan Estratégico de la organización mediante la generación y
realización de proyectos.
O3 Mantener bajo control las actividades de Gestión de Proyectos mediante el
cumplimiento del Plan de Gestión de Proyectos.
O4 Atender los Comentarios y Quejas del cliente mediante la definición y
ejecución de Acciones Correctivas o Preventivas.
O5 Lograr los objetivos del Plan Estratégico mediante la provisión de los
recursos humanos calificados e infraestructura suficiente.
O6 Proveer a los miembros de la organización, recursos y mecanismos
adecuados mediante la Base de Conocimiento.
107
Actividades:
A1 Planificación Estratégica (O1)
Entradas: Propuesta de Mejoras.
Actividad: Define un plan estratégico, sobre lo que es más importante para
lograr el éxito de la organización con los siguientes elementos:
a) Misión, Visión y Valores;
b) Objetivos de la Organización, así como la forma de alcanzarlos por medio
de la definición de estrategias;
c) Cartera de proyectos que habilite la ejecución de estrategias;
d) Presupuesto, incluye gastos e ingresos;
e) Plan de comunicación con el cliente, incluye elementos de comunicación
con el cliente para su atención.
El plan estratégico se verifica y se valida, en caso de que haya una propuesta de
mejoras, es necesario revisar los elementos que son afectados y realizar los
cambios necesarios.
Salidas: Plan Estratégico.
A2 Mejora Continua
Entradas: Reporte de acciones correctivas o preventivas relacionadas con los
clientes, reportes financieros, propuestas tecnológicas, considerando los
factores externos de la organización.
Actividad: Se realizan las siguientes tareas:
a) Análisis de Reporte de acciones correctivas o preventivas relacionadas
con los clientes, reportes financieros, propuestas tecnológicas,
considerando los factores externos de la organización;
b) Generación del reporte de valoración en base al análisis;
c) Generación y Validación de la propuesta de mejoras al plan estratégico,
tomando en cuenta el reporte de valoración.
108
Salidas: Propuesta de Mejoras.
A3 Planificación de Proyectos (O2, O4)
Entradas: Plan Estratégico.
Actividad: Se realizan las siguientes tareas:
a) A partir de de la Cartera de Proyectos identificada, en el Plan Estratégico
se establece o se actualiza el Plan de Gestión de Proyectos,
considerando los proyectos y oportunidades de proyectos de la
organización. Este plan contiene los siguientes elementos:
i) Plan de Ventas, se planea la realización de acciones para generar
y cerrar las oportunidades de proyectos, la presentación de
propuestas y la firma de contrato;
ii) Plan de Proyectos, se planea la asignación de recursos, el
seguimiento y la evaluación de los proyectos contratados.
b) Establecer Mecanismos de Comunicación con los Clientes.
Salidas: Plan de Gestión de Proyectos.
A4 Realización (O2, O3, O4)
Entradas: Plan de Gestión de Proyectos, Plan del Proyecto, Documento de
Aceptación.
Actividad: se realizan las siguientes tareas:
a) Ejecución del Plan de Proyectos y elaboración de los Contrato(s);
b) Ejecución del Plan de Gestión de Proyectos, generando para cada
proyecto el Registro del Proyecto, la Descripción del Proyecto y las
Metas Cuantitativas para el Proyecto;
c) Cierre de los Proyectos al recibir Documento(s) de Aceptación.
Salidas: Contrato(s), Registro(s) de Proyecto, Descripción(es) del Proyecto,
Metas cuantitativas para el Proyecto.
109
En la figura 16 se muestran los procesos anteriores:
Fig. 16. Procesos de la gestión de negocio (GER)
110
A5 Planificación de Recursos (O5, O6)
Entradas: Plan Estratégico.
Actividad: se realizan las siguientes tareas:
a) generación o actualización del Plan de Bienes, Servicios e Infraestructura,
a partir del Plan Estratégico;
b) generación o actualización del Plan de Recursos Humanos a partir del
Plan Estratégico;
c) generación o actualización del Plan de Conocimiento de la Organización,
a partir del Plan Estratégico.
Salidas: Plan de Bienes, Servicios e Infraestructura, Plan de Recursos
Humanos, Plan de Conocimiento de la Organización.
En la figura 17 se muestra el proceso de Planificación de Recursos:
Fig. 17. Proceso planificación de recursos (GER)
111
A6 Preparación Plan de Bienes, Servicios e Infraestructura (O5)
El propósito de Bienes, Servicios e Infraestructura es proporcionar proveedores
de bienes, servicios e infraestructura que satisfagan los requisitos de los
proyectos
Entradas: Plan de Bienes, Servicios e Infraestructura.
Actividad: se realizan las siguientes tareas:
a) revisión del Plan de Bienes, Servicios e Infraestructura;
b) definición de criterios para:
i) selección y aceptación de los bienes y servicios;
ii) evaluación de los proveedores.
Salidas: Solicitud de Bienes ó Servicios.
A6.1 Instrumentación
Entradas: Solicitud de Bienes o Servicios, Proveedores.
Actividades: se realizan las siguientes tareas:
a) Solicitud de Bienes o Servicios, Proveedores;
b) selección de los proveedores y adquisición de bienes y servicios de
acuerdo a la Solicitud de Bienes o Servicios y la actualización de
Proveedores.
Salidas: Registro de Bienes ó Servicios, Proveedores.
En la figura 18 se muestran los procesos de Registro de Bienes, Servicios e
Infraestructura:
112
Fig. 18. Procesos de bienes, servicios e infraestructura (GER)
En las actividades de la figura 18 está la solicitud de bienes, servicios e
infraestructura, así como los proveedores y el registro de los bienes de la
organización.
113
A7 Preparación Plan de Recursos Humanos (O5, O6)
El propósito de Recursos Humanos es proporcionar los recursos humanos
adecuados para cumplir las responsabilidades asignadas a los roles dentro de la
organización.
Entradas: Plan de Recursos Humanos
Actividad: se realizan las siguientes tareas:
a) revisión del Plan de Recursos humanos;
b) definición de criterios para:
i) selección, asignación y aceptación de los recursos humanos;
ii) capacitación u otras acciones que satisfagan estas necesidades;
iii) evaluación de desempeño.
c) elaboración o actualización del Plan de Capacitación con base en el Plan
de Recursos Humanos.
Salidas: Plan de Capacitación.
A7.1 Instrumentación
Entradas: Plan de Recursos Humanos, Plan de Capacitación.
Actividad: se realizan las siguientes tareas:
a) selección, asignación y aceptación de los recursos humanos, en caso que
se contrate nuevo persona, integrarlo en el Registro de Recursos
Humanos;
b) capacitación de recursos humanos de acuerdo al Plan de Capacitación y
actualización del Registro de Recursos Humanos.
Salidas: Registro de Recursos Humanos.
114
En la figura 19 se muestran los procesos Plan de Recursos Humanos y Plan de
Capacitación:
Fig. 19. Procesos de plan recursos humanos y capacitación (GER)
En las actividades de la figura 19 está los procesos del plan de recursos
humanos, el registro de recursos humanos, así como el plan de capacitación
necesario para el personal humano.
115
A8 Preparación Plan de Conocimiento de la Organización (O6)
El propósito de Conocimiento de la Organización es mantener disponible y
administrar la Base de Conocimiento que contiene la información y los productos
generados por la organización.
Entradas: Plan de Conocimiento de la Organización.
Actividad: se realizan las siguientes tareas:
a) Elaboración del Diseño de la Base de Conocimiento;
i) identificación, documentación o actualización de las actividades
para la definición o modificación de la Base de Conocimiento de
acuerdo al Plan de Conocimiento de la Organización;
ii) identificación de los mecanismos de consulta, mantenimiento y
respaldo en función de los requisitos de los usuarios
Salidas: Diseño de la Base de Conocimiento.
A8.1 Realización
Entradas: Diseño de la Base de Conocimiento.
Actividad: se realizan las siguientes tareas:
a) generación o actualización del la Base de Conocimiento de la
organización de acuerdo al Diseño de la Base de Conocimiento;
b) implantación o mantenimiento de la Base de Conocimiento para que se
incorporen y se consulten los productos provenientes de procesos y
proyectos
Salidas: Base de Conocimiento.
En la figura 20 se muestran los procesos de Plan de Conocimiento de la
Organización:
116
Fig. 20. Procesos de plan de conocimiento de la organización (GER)
En las actividades de la figura 20 está el diseño de la base de conocimiento de
la organización, así como las actividades de generación, mantenimiento y
actualización de la misma.
117
3.3 Operación
3.3.1 Administración de proyectos (OPE.1) El propósito de la Administración de Proyectos es establecer y llevar a cabo
sistemáticamente las actividades que permitan cumplir con los objetivos de un
proyecto en tiempo y costo esperados.
Objetivo:
O1 Lograr los objetivos del proyecto en tiempo y costo mediante la coordinación
y el manejo de los recursos del mismo.
O2 Mantener informado al Cliente mediante la realización de reuniones de
avance del proyecto.
A1 Planificación del Proyecto (O1)
Entradas: Descripción del Proyecto, Metas.
Actividad: se realizan las siguientes tareas:
a) definición de Actividades con base en la Descripción del Proyecto, el
proceso de Desarrollo y Mantenimiento de Software y con el Cliente;
b) definición con el Cliente del Protocolo de Entrega;
c) determinación del Tiempo Estimado en las actividades considerando las
Metas para el proyecto;
d) integración del Equipo de Desarrollo, asignando roles y responsabilidades
basándose en la Descripción del Proyecto;
e) establecimiento del Calendario de las actividades;
f) calculo del Costo Estimado del proyecto, considerando las Metas para el
proyecto;
g) generación del Plan de Desarrollo en función del Plan del Proyecto.
Salidas: Plan de Desarrollo, Plan del Proyecto.
118
A2 Realización (O1, O2)
Entradas: Plan de Desarrollo, Plan del Proyecto, Entrega de Software.
Actividad: Se realizan las siguientes tareas:
a) asignación de tareas al Equipo de Desarrollo;
b) revisión del Producto, Equipo de Desarrollo y Calendario;
c) recopilación de los Reportes de Actividades;
d) realización de reuniones de revisión con el Equipo de Desarrollo y el
Cliente;
e) revisión de los productos generados, que forman parte de la Entrega de
Software.
A3 Cierre (O1)
Entradas: Plan de Desarrollo, Plan del Proyecto, Entrega de Software.
Actividad: se realizan las siguientes tareas:
a) cierre formal del proyecto y Entrega del Software de acuerdo a lo
establecido en el Plan del Proyecto y obtención del Documento de
Aceptación;
b) generación de Sugerencias de Mejora en el proceso.
Salidas: Documento de Aceptación, Sugerencias de Mejora.
La figura 21 muestra los procesos de Administración de Proyectos:
119
Fig. 21. Procesos de administración de proyectos
En las actividades de la figura 21 está la administración de proyectos, donde se
describe la descripción del proyecto, sus metas, el plan de desarrollo,
calendarización de actividades conforme al plan, así como la definición de
actividades a desarrollar a lo largo del proyecto
3.3.2 Desarrollo y mantenimiento de software (OPE.2) El propósito de Desarrollo y Mantenimiento de Software es la realización
sistemática de las actividades en base a las fases de la metodología ágil XP:
Exploración, Planificación de la Entrega, Iteración, Producción, Mantenimiento y
Termino del Proyecto así como integrando actividades de las metodologías
agiles XP, SCRUM, Crystal y DSDM, cumpliendo con los requisitos
especificados para el proyecto.
120
En el Desarrollo y Mantenimiento de Software se utilizaron las fases que define
eXtreme Programming, asimismo cuando se haga mención en las actividades y
prácticas se señalará de que metodología ágil proviene.
Objetivo:
O1 Lograr que los productos de salida sean consistentes con los productos de
entrada en cada fase del ciclo de desarrollo mediante las actividades, prácticas y
pruebas.
O2 Llevar a cabo las actividades de las fases mediante el cumplimiento del Plan
de Desarrollo.
O3 Satisfacer al cliente mediante: tempranas, incrementales y continuas
entregas de software que le aporten un valor.
O4 Coordinar el proyecto entre el Cliente y el Equipo de Desarrollo.
O5 Realizar tareas de mantenimiento y soporte al cliente.
A1 Fase de Exploración (O1, O2, O4)
Entradas: Plan de Desarrollo.
Actividad: se realizan las siguientes tareas:
a) distribución de tareas a los miembros del equipo de desarrollo según su
rol, de acuerdo al Plan de Desarrollo;
b) obtención de los requerimientos de parte del cliente a través de las
historias de usuario (XP);
c) familiarización del equipo con las tecnologías y herramientas a utilizar a lo
largo del proyecto (DSDM);
d) creación de un prototipo simple para probar las posibilidades de la
arquitectura (XP).
Salidas: Especificación de Requerimientos.
121
A2 Planificación de la Entrega (O1, O2, O4)
Entradas: Plan de Desarrollo, Especificación de Requerimientos.
Actividad: se realizan las siguientes tareas:
a) Establecer a través del cliente la prioridad de cada requerimiento (XP,
Crystal);
b) Estimación en esfuerzo, valor y riesgo cada requerimiento (XP);
c) Creación de una lista de requerimientos priorizada (SCRUM);
d) Planeación de la inclusión de nuevos requerimientos si así lo desea el
cliente para la próxima iteración (XP).
Salidas: Requerimientos para la próxima Iteración.
A3 Iteración (O1, O2, O3, O4)
Entradas: Plan de Desarrollo, Especificación de Requerimientos,
Requerimientos para la próxima Iteración.
Actividad: se realizan las siguientes tareas:
a) Establecer un plan de iteración de no más de tres semanas (XP);
b) Creación de lista de tareas de la iteración en conjunto con el cliente
(SCRUM);
c) Creación de una arquitectura utilizable a lo largo del proyecto (XP,
DSDM);
d) Aplicación de pruebas unitarias continuas, frecuentemente repetidas y
automatizadas, incluyendo pruebas de regresión. (Crystal, XP);
e) Realización de reuniones de sincronización con los miembros del Equipo
de Desarrollo (SCRUM);
f) Realización de gráficos de trabajo pendiente. (SCRUM);
g) Aplicación de Retrospectiva de la Iteración (SCRUM).
122
Salidas: Plan de Iteración, Arquitectura del Proyecto.
A4 Producción (O1, O2, O3, O4)
Entradas: Plan de Desarrollo, Plan de Iteración, Arquitectura del Proyecto.
Actividad: se realizan las siguientes tareas:
a) Realización de pruebas adicionales y revisiones de rendimiento (XP);
b) Decisión en conjunto con el cliente de la inclusión de nuevas
características para su posterior implementación (XP, Crystal);
c) Liberación de la versión funcional al cliente (XP).
Salidas: Versión Funcional.
A5 Mantenimiento (O1, O2, O4, O5)
Entradas: Plan de Desarrollo, Versión Funcional.
Actividad: se realizan las siguientes tareas:
a) Mantención del proyecto en producción si aun hay iteraciones por incluir.
(XP);
b) Analizar nuevas iteraciones en conjunto con la opinión del cliente.
(Crystal);
c) Realización de Tareas de Soporte al Cliente (XP).
Salidas: Tareas de Soporte al Cliente
A6 Término del Proyecto (O1, O2, O4)
Entradas: Plan de Desarrollo.
a) Pasar a al Termino del Proyecto cuando el cliente no tenga más
requerimientos que incluir y el Proyecto satisfaga las necesidades en
rendimiento y confiabilidad. (XP, Crystal);
b) Liberación de la Versión Final de Software (XP, DSDM);
c) Elaboración y Liberación de Manual de Usuario al Cliente; (XP, DSDM)
123
d) Entrega de Software al Cliente;
e) Elaboración de un informe de revisión de proyecto (DSDM).
Salidas: Versión Final de Software, Manual de Usuario, Entrega de
Software.
La figura 22 muestra los procesos de Desarrollo y Mantenimiento de Software:
Fig. 22. Procesos de desarrollo y mantenimiento de software
A continuación se muestra el mapa general del modelo MPMPES:
124
Fig. 23. Mapa general MPMPES
125
CAPÍTULO IV
Conclusiones
126
4.1 Conclusiones Las empresas, en su estructura, sus procesos, y en todas las disciplinas que la
integran, buscan lograr la calidad en productos y servicios, la certificación en
algún estándar internacional o usando metodologías de procesos, lo anterior va
de la mano con obtener lo que la organización necesita:
Productos de calidad;
Fiables;
Estables;
Funcionales;
y que reflejen los requerimientos.
Si bien los estándares internacionales como ISO/SC7, son usados en empresas
de mediano y gran tamaño, aun no son fácilmente implementadas en empresas
pequeñas y muy pequeñas, muchos son los factores: pocos recursos, personal
reducido, además de la dificultad que encuentran organizaciones de este tipo
para adaptar estos estándares, sin embargo este tipo de empresas requieren y
reclaman el uso de estándares y obtener una certificación con los mismos.
Diversas investigaciones, abundan en como acotar estos estándares, tomando
el camino de la fusión entre los mismos, integrando metodologías de procesos,
ciclos de vida, metodologías ágiles, etc. El campo de acción es muy amplio,
sobre todo en Latinoamérica donde la mayoría de las organizaciones son de tipo
pequeño y muy pequeño, Grupos internacionales buscan integrar estos
estándares en la empresa, y obtener resultados tangibles en las mismas.
En esta tesis se desarrolló un modelo capaz de solucionar esta problemática
obteniendo de MoProSoft (Oktaba 2007) su estructura y acotando sus procesos
a los requeridos por una empresa de tipo MPE, en el nivel de Desarrollo y
Mantenimiento de Software se utilizaron las fases de la metodología ágil XP
127
como estructura principal, a cada fase se fusionaron las prácticas, herramientas
y actividades de las siguientes metodologías:
XP;
SCRUM;
Crystal;
DSDM.
Con lo anterior obtenemos lo mejor de cada metodología, ya que con el análisis
concluimos que cada metodología es aplicable en casos específicos, con
diferentes técnicas, procesos, actividades y herramientas formales y no
formales. Así el equipo de desarrollo de software tiene variedad tanto formal, no
formal, esquemática y grafica para desarrollar cada fase del proceso de
desarrollo y mantenimiento se software.
Si bien existen cantidad de implementaciones de modelos y paradigmas para el
desarrollo y mantenimiento de software, sin embargo el contar con un modelo de
este tipo para una micro y pequeña empresa nos sirve como una guía fácil,
adaptable y entendible para asegurar la calidad en los productos y servicios.
4.2 Trabajo Futuro
Esta tesis propone un modelo para las Micro y Pequeñas Empresas
Desarrolladoras de Software, nos proporciona una guía tanto grafica, como de
procesos y actividades a desarrollar acoplándose a las características de
tamaño y funcionales de una MPE, sin embargo el modelo puede ser aun más
avanzado si se le implementan las siguientes características:
Si se incorporan prácticas, actividades y herramientas de otras
metodologías agiles.
128
Si se detallan los niveles de capacidad de cada proceso.
Si se jerarquiza los procesos por colores.
Si se realiza un patrón de procesos.
Agregar más procesos si en la práctica una MPE lo requiere.
Aplicar y analizar los resultados del modelo MPMPES en una micro ó
pequeña empresa desarrolladora de software.
129
BIBLIOGRAFÍA Agiles, P. (2011). "http://www.proyectosagiles.org." Revisada noviembre de 2011, 2011. Alvarez, M. (2009). "Manual de la Micro, Pequeña y Mediana Empresa." 108. Beck, K. (2001). "http://www.agilealliance.org." Revisada Noviembre de 2011. Carvajal, J. (2008). Metodologías Ágiles: herramientas y modelo de desarrollo para aplicaciones java ee como metodología empresarial. UPC. Barcelona, Universidad de
Barcelona. Máster: 215. Derniame, J., B. Ali Kaba, et al. (1999). Software Process: Principles, Methodology, Technology., Springer. Fowler, M. (2003). "Who needs an Architect?" IEE Computer Society. Fundacion Wikimedia, I. (2011). "http://es.wikipedia.org/wiki/Software." Revisada 15 de Noviembre de 2011, 2011. Garcia, I. and L. E. Suarez (2007). "Determining Practice Achievement in Project Management using a Two-Phase Questionnaire on Small and Medium Enterprises." International Conference on Software Engineering Advances(ICSEA). Jacobson, I. (1992). "Object-Oriented Software Engineering: A Use Case Driven Aproach." ACM Press: 465-493. Joannou, P. (2007). "Enterprise, Systems, and Software Engineering-The Need for Integration." IEEE Computer Society Laporte, C. Y., S. Alexandre, et al. (2008). "A Software Engineering Lifecycle Standard for Very Small Enterprises." EuroSPI 16: 129-141. Laporte, C. Y., Alexandre, S., Renault, A., Crowder, K.V. (2008). "The Development of International Standards for Very Small Enterprises." INCOSE (International Council on Systems Engineering) Seventeenth International Symposium. Letelier, P. and C. Penades (2009). "Métodologías ágiles para el desarrollo de software: eXtreme Programming (XP)." Universidad Politécnica de Valencia: 17. Lewis, G. (1994). "What is Software Engineering?" DataPro (4015): 1-10.
130
López, O. (2003). "Ingeniería de Software: Entre la tradición de la Programación y el Managment." 2. Mc Caffery, F., P. S. Taylor, et al. (2007). "Adept: A Unified Assessment Method for Small Software Companies." IEEE Computer Society. Mizuno, O., T. Adachi, et al. (2001). "On prediction of cost and duration for risky software projects based on risk questionnaire ". Mochi, P. (2006). La industria del software en México en el contexto internacional y latinoamericano. CRIM. Cuernavaca, UNAM: 263. Monsalve, L. (2002). "Calidad de los Productos Software." Departamento Ingeniería Informática y Ciencias de la Computación: Universidad de Concepción Chile: 4. O.Mizuno, T., Y. Kikuno, et al. (2000). "Characterization of risky projects based on a project managers' evaluation." 387-395. Oktaba, H. (2007). Procesos de Software. Palacio, J. (2007). "Flexibilidad con Scrum, principios de diseño e implantación en campos Scrum." SafeCreative Octubre 2007. Pekka, A., S. Outi, et al. (2002). "Agile Software Development methods, review and analysis." VTT Electronics. Robert H., D. (1990). "Software Quality, Concepts and Plans." Secretaria de Economia, S. E. (2004). Estudio para determinar la cantidad y calidad de recursos humanos necesarios para el desarrollo de la industria de Software en México. México: 118. Secretaria de Economia, S. E. (2009). Programa para el Desarrollo de la Industria del Software (PROSOFT). S.E. Mexico. 1.3. Stephen, H. (2002). "Metrics and Models in Software Quality Engineering ". Watts, H. and A. Wesley (2000). "Introduction to Team Software Process."
