1 PDF

Instituto Politcnico Nacional
Centro de Investigacin en Computacin

Secretara de Investigacin y Posgrado

META (MEtodologa Tradicional y gil), UNA
METODOLOGA HBRIDA PARA DESARROLLO
DE SOFTWARE WEB PROPUESTA PARA LAS
EMPRESAS DE SOFTWARE EN MXICO

DIRECTOR DE TESIS: M. en C. SANDRA DINORA ORANTES JIMNEZ

MXICO, D.F. OCTUBRE 2012

T E S I S
QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS DE LA COMPUTACIN
P R E S E N T A
ING.ERNDIRA MIRIAM JIMNEZ HERNNDEZ

META (MEtodologa Tradicional y gil), una metodologa hbrida para
desarrollo de software Web propuesta para las empresas de software en
Mxico

Erndira Miriam Jimnez Hernndez

Octubre 2012 ii

Resumen

El desarrollo de software es una actividad no trivial, razn por la cual se ha intentado dar
solucin a dicha problemtica a travs del uso de metodologas, las cuales proporcionan
procesos sistematizados sobre el desarrollo de software con el fin de mejorar la
productividad y la calidad.

En la actualidad, existen un gran nmero de metodologas para el desarrollo de software;
estas se engloban en tres categoras: las metodologas tradicionales, las metodologas giles
y las metodologas hbridas.

Las metodologas tradicionales propician las buenas prcticas que existen dentro de la
Ingeniera de Software; sin embargo, requieren de mucha disciplina para seguir con el
riguroso proceso que stas conllevan.

Las metodologas giles presentan respuestas rpidas al cambio y son flexibles, aunque
generan poca documentacin y no hacen uso de mtodos formales.

Las metodologas hbridas son la nueva tendencia en el rea de Ingeniera de Software, su
principal caracterstica es que incorporan algunas prcticas de las metodologas
tradicionales y giles existentes, brindado as una gran ventaja.

Este trabajo propone una metodologa hbrida para desarrollo de proyectos de software
Web, la cual es conocida como MEtodologa Tradicional y gil (META por sus siglas en
espaol) que combina algunas prcticas de las metodologas RUP (Rational Unified
Process, Proceso Unificado de Racional), XP (eXtreme Programming, Programacin
Extrema) y Scrum.

META se dise a partir de un estudio (que se realiz como parte de esta investigacin), en
el cual se comprob que las empresas mexicanas dedicadas a desarrollar software son
candidatas a utilizar una metodologa hbrida.

Finalmente META se prob en proyectos de desarrollo de software reales y se evalu su
calidad con la norma NMX-I-055-NYCE; de esta manera se presenta a META como una
opcin factible para desarrollo de software en Mxico.

Mxico


Octubre 2012 iii

Abstract

The software development is a nontrivial activity, this is the reason why it have been used
methodologies for trying to solve this problem because they provide a systematic process
for software development in order to improve productivity and quality.

Currently, there are a lot of methodologies for software development, these falls into three
broad categories: traditional methodologies, agile methodologies and hybrid
methodologies.

The traditional methodologies foster the best practices that exist within Software
Engineering; however, they require a lot of discipline to continue the rigorous process that
they entail.

The agile methodologies have quick responses to change and they are flexible, but they
generate little documentation and they do not make use of formal methods.

The hybrid methodologies are the new trend in the area of Software Engineering, its main
feature is that they incorporate some practices of the existing methodologies, providing a
great advantage.

This thesis proposes a hybrid methodology for software development of Web projects
called META (MEtodologa Tradicional y gil, Traditional and Agile Methodology), it
combines some practices within others methodologies as RUP (Rational Unified Process),
XP (eXtreme programming) and Scrum.

META was designed from a study (which was conducted as part of this research), in which
it was found that Mexican companies dedicated to developing software are candidates to
use a hybrid methodology.

Finally META was tested in real projects of software development and it was assessed its
quality with the standard NMX-I-055-NYCE; thereby it presents META as a feasible
option for software development in Mexico.

Mxico


Octubre 2012 iv

Agradecimientos.

Al Instituto Politcnico Nacional.
Por brindarme la oportunidad de pertenecer a una de las mejores instituciones de la
Repblica Mexicana, ofrecindome una formacin acadmica de calidad al servicio de mi
pas.

Al Centro de Investigacin en Computacin.
Por proporcionar los recursos humanos y materiales necesarios para la adecuada
adquisicin de conocimiento.

A CONACYT.
Por otorgarme una beca que signific un apoyo econmico durante el tiempo que curs la
Maestra.

A mi Asesora.
Por haberme ayudado incondicionalmente y compartir su conocimiento conmigo.

Al Comit Tutorial.
Por su valiosa aportacin en comentarios y recomendaciones que permitieron mejorar mi
formacin acadmica y aumentar la calidad de mi proyecto de tesis.

A mi Pap.
Que siempre me ha guiado y me ha sabido ofrecer sabios consejos en los momentos en que
ms lo he necesitado, adems de ser el ejemplo que siempre me motiva a buscar ms en la
vida y a obrar con rectitud y congruencia.

A mi Mam.
Que ha estado siempre al pendiente de m brindndome su cario y comprensin.

A mis Hermanos.
Mis amiguitos, que han estado a mi lado siempre dndole alegra a mi vida.

A mi Novio.
Que me anima y me apoya para alcanzar mis sueos y hacerlos realidad

Y en general, a aquellas personas que han compartido momentos especiales de su vida
conmigo que quedarn por siempre en mi memoria y por los cuales estar agradecida toda
la vida.

Mxico


Octubre 2012 v

ndice

Resumen..................... ii
Abstract.......................... iii
Agradecimientos............................. iv
Glosario.......................... ix
1 Introduccin............... 11
1.1 Planteamiento del problema...................... 11
1.2 Objetivos................................................... 12
1.2.1 Objetivo General.............................. 12
1.2.2 Objetivos Especficos...................... 12
1.3 Justificacin.............................................. 13
1.4 Beneficios Esperados................................ 18
1.5 Lmites y Alcances.................................... 18
1.6 Organizacin de la Tesis........................... 18
1.7 Resumen............................ 18
2 Marco Terico................................................ 19
2.1 Introduccin.............................................. 19
2.2 Estado del Arte...................... 19
2.2.1 Metodologas Tradicionales............. 19
2.2.1.1 RUP...................................... 20
2.2.2 Metodologas giles........................ 23
2.2.2.1 XP........................................ 24
2.2.2.2 Scrum................................... 27
2.2.3 Metodologas Hbridas..................... 29
2.2.3.1 EssUP.................................... 29
2.3 Norma Mexicana NMX-I-055-NYCE.......................... 30
2.3.1 Modelo de Calidad Interna y Externa ............. 31
2.3.2 Modelo de Calidad para la Calidad en Uso............. 31
2.4 Resumen........................ 32
3 META......................................................................... 33
3.1 Introduccin.......................................................... 33
3.2 Caractersticas de META...................................... 33
3.3 Requerimientos y Requisitos para el Uso de META........................ 33
3.4 Capacitacin para el uso de META...................................... 34
3.5 Roles en META.................................................... 34
3.6 Principios Metodolgicos de META.................... 36
3.7 Proceso de Desarrollo de META.......................... 42
3.7.1 Planteamiento............................................... 44
3.7.2 Preparacin.................................................. 50
3.7.3 Construccin................................................ 52
3.7.4 Implantacin................................................ 53
3.8 Componentes de META....................... 53

Mxico


Octubre 2012 vi

3.9 Ventajas de META....................... 55
3.10 Limitaciones de META........................ 55
3.11 Resumen........................ 55
4 Pruebas y Resultados obtenidos. ......................................................................... 56
4.1 Introduccin.......................................................... 56
4.2 Evaluacin de META....................................... 56
4.3 Opinin respecto a META.................................................... 62
4.4 Resumen.................... 62
5 Conclusiones y Trabajos Futuros............................................................................. 63
Bibliografa.. ......................................................................... 65
Referencias URL........................................................................... 66
Apndices. ................................................................................................................. 67
1 Caractersticas de las Aplicaciones Web..................................................... 67
2 Plantilla General del Contrato......................................... 68
3 Flder del Proyecto..................................................... 70
4 Calidad Interna del Producto.......................................................... 76
5 Calidad Externa del Producto......................................... 80
6 Calidad en Uso del Producto.................................................. 84
Anexos............................................................................... 85
1 Metodologas Hbridas para desarrollo de software: una opcin factible para
Mxico (Revista Digital Universitaria)

2 META: a new hybrid methodology to software development created to suit the
current needs in Mexico (ICTA 2011)
3 Metodologa Hbrida para desarrollo de software en Mxico (CICIC 2012)

Mxico


Octubre 2012 vii

ndice de Figuras

Figura 1.1. Metodologas utilizadas en las empresas mexicanas............... 12
Figura 1.2. rea bajo la curva de la distribucin normal............................... 16
Figura 1.3. Intervalo de confianza.................................. 17
Figura 2.1. Etapas de RUP......................... 22
Figura 2.2. Etapas de XP............................ 27
Figura 2.3. Proceso de Scrum.................................... 29
Figura 2.4. Modelo para la calidad del producto............................ 30
Figura 2.5. Modelo para la calidad interna y externa............................. 31
Figura 2.6. Modelo para la calidad en uso...................................... 32
Figura 3.1. Roles en META................................................... 36
Figura 3.2. Ciclo de Deming...................................................... 38
Figura 3.3. Proceso de desarrollo de META.................................................. 43
Figura 3.4. Ejemplo de Diagrama Interfaz-Navegacin de la pgina de inicio del sitio... 45
Figura 3.5. Ejemplo de Diagrama Interfaz-Navegacin de la pgina principal de los
Clientes........................................................................................

45
Figura 3.6. Ejemplo de Diagrama Interfaz-Navegacin de la pgina principal de las
Tiendas.............................................................................................

46
Figura 3.7. Estimacin con META-Software............................................. 47
Figura 3.8. Generacin de contrato con META-Software......................................... 48
Figura 3.9. Plan de proyecto general para el mes de diciembre......................................... 49
Figura 3.10. Plan de proyecto general para el mes de enero.............................................. 49

Mxico


Octubre 2012 viii

ndice de Tablas

Tabla 2.1. Metodologas giles vs. Metodologas Tradicionales...................... 24
Tabla 3.1. Roles en META................................................. 34
Tabla 3.2. Tabla de Actividad-Responsabilidad..................................... 50
Tabla 3.3. Tabla de Gestin de Riesgos y Problemas................................ 52
Tabla 3.4. Componentes de META................................ 54
Tabla 4.1. Tabla de Normalizacin de las Mtricas para la evaluacin del Producto........ 57
Tabla 4.2. Tabla Calidad Interna del Producto (Media aritmtica y porcentaje)........... 58
Tabla 4.3. Tabla Calidad Externa del Producto (Media aritmtica y porcentaje).......... 59
Tabla 4.4. Media Aritmtica y Porcentaje de las Caractersticas de la Calidad Interna del
Producto............................................................

60
Tabla 4.5. Media Aritmtica y Porcentaje de las Caractersticas de la Calidad Externa
del Producto..............................................................

60
Tabla 4.6. Media Aritmtica y Porcentaje de las Caractersticas de la Calidad en Uso del
Producto....................................................................

61
Tabla 4.7. Calidad del Producto.................................. 61

Mxico


Octubre 2012 ix

Glosario

Glosario de Trminos

Base de Datos Es una coleccin de datos interrelacionados almacenados
conjuntamente en uno o ms ficheros de computadora [IEE90].

Calidad Totalidad de las caractersticas de una entidad que nacen de su
capacidad para satisfacer las necesidades explcitas e implcitas
[NYC06].

Caso de Uso Es una funcionalidad del sistema que proporciona al usuario un
valor aadido [IBM11].

Evaluacin de Calidad Examen sistemtico del grado al cual una entidad es capaz de
cumplir los requisitos especificados [NYC06].

Hbrido

Se dice de todo lo que es producto de elementos de distinta
naturaleza [RAE01].

Ingeniera de Software Es la aplicacin de un enfoque sistemtico, disciplinado y
cuantificable al desarrollo operacin (funcionamiento) y
mantenimiento del software: es decir, la aplicacin de Ingeniera
al software [IEE93].

Metodologa Conjunto de pasos y procedimientos que deben seguirse para
desarrollar sistemas computacionales [SOM09].

Mtrica Es una medida cuantitativa o cualitativa del grado en que un
sistema, componente o proceso posee un atributo determinado
[IEE93].

Puntos de Funcin

Es una mtrica empleada para medir la funcionalidad que
entrega un sistema a travs del conocimiento del nmero de
entradas externas, salidas externas, consultas externas, archivos
lgicos internos y archivos de interfaz externos [ALB79].

Software Conjunto de programas, instrucciones y reglas informticas para
ejecutar ciertas tareas en una computadora [RAE01].

Web Protocolo basado en hipertexto, que permite conectar su
contenido mediante hipervnculos, fue pensado como una fuente
de material de slo lectura, que se encontraba en una gran
estructura de servidores cargados con miles de datos [BER96].

Mxico


Octubre 2012 x

Glosario de Acrnimos

COCOMO COnstructive COst MOdel, Modelo Constructivo de Costos

CRC Class Responsibility-Collaboration, Clase Responsabilidad-Colaboracin

DSA Development Software Adaptative, Desarrollo de Software Adaptativo

INEGI Instituto Nacional de Estadstica y Geografa

META MEtodologa Tradicional y gil

OMT Object Modeling Technique, Tcnica de Modelado de Objetos

PERT Program Evaluation and Review Technique, Tcnica de Evaluacin y
Revisin de Programas

RUP Rational Unified Process, Proceso Unificado de Racional

UML Unified Modeling Language, Lenguaje Unificado de Modelado

UP Unified Process, Proceso Unificado

XP eXtreme Programming, Programacin Extrema

Mxico


Octubre 2012 11

1 Introduccin

El software se ha convertido en una tecnologa indispensable en los negocios, la ciencia y la
ingeniera; ha permitido la creacin, la expansin y el fin de tecnologas. En la actualidad,
el software est relacionado con sistemas de todo tipo: de transporte, mdicos, de
telecomunicaciones, militares, industriales, de entretenimiento, entre otros.

A medida que la importancia del software ha crecido, la Ingeniera de Software ha
intentado desarrollar tecnologas que faciliten y disminuyan el tiempo y el costo de
construccin y mantenimiento del software; entre las cuales se pueden mencionar a las
metodologas como una aportacin que ha simplificado la labor no trivial de desarrollo de
software.

Una metodologa para desarrollo de software, es un conjunto de pasos y procedimientos
que deben seguirse para desarrollar sistemas computacionales [SOM09].

Por lo que se espera que al utilizar una metodologa para desarrollo de software, sta
proporcione un conjunto de prcticas y herramientas que faciliten el proceso de desarrollo,
obteniendo un producto con alta calidad, seguridad y que satisfaga las expectativas del
cliente.

1.1 Planteamiento del Problema

En Mxico el 79% de las empresas desarrolladoras de software utilizan las metodologas
conocidas como RUP (Rational Unified Process, Proceso Unificado de Racional), XP
(eXtreme Programming, Programacin Extrema) y Scrum [JIM12].

De manera especfica, el 37% de las empresas utilizan RUP, el 26% utilizan XP y el 16%
Scrum (vase Figura 1.1); considerando esta informacin se puede observar que el 42% de
las empresas hacen uso de metodologas giles (porque XP y Scrum se consideran giles) y
el 37% de una metodologa tradicional (RUP); de este modo, al investigar cul es la
situacin de esas empresas, permite plantear la posibilidad de diseo de una metodologa
que se adapte especficamente a sus necesidades porque no existe una metodologa genrica
que funcione para todos los proyectos y tanto RUP, XP y Scrum surgieron para el mbito
de desarrollo estadounidense y europeo, por lo cual al implantarlas en Mxico no resultan
ser siempre la mejor eleccin.

Mxico


Octubre 2012 12

Figura 1.1. Metodologas utilizadas en las empresas mexicanas [JIM12]

1.2 Objetivos

1.2.1 Objetivo General

Disear una metodologa que se adapte al contexto actual de las empresas de
desarrollo de software en Mxico, basada en la nueva tendencia en el rea de
Ingeniera de Software: metodologas hbridas.

1.2.2 Objetivos Especficos

Identificar las necesidades y prcticas de Ingeniera de Software presentes en las
empresas dedicadas a desarrollar software en Mxico.
Definir una metodologa hbrida para desarrollo de software que tome en cuenta lo
investigado en el punto anterior.
Probar la utilidad de la metodologa propuesta en algunas empresas dedicadas a
desarrollar software en Mxico.

Mxico


Octubre 2012 13

1.3 Justificacin

En Mxico, ms del 50% de las empresas dedicadas al desarrollo de software son
candidatas a utilizar una metodologa hbrida. Por lo cual, las metodologas existentes son
tradicionales o giles y no se acoplan a las necesidades de las empresas [JIM12].

Por lo que el disear una metodologa hbrida para que las empresas de desarrollo de
software en Mxico la puedan utilizar, es una buena opcin para incrementar la
productividad en dichas empresas.

Lo anterior se comprob a travs de un estudio realizado con las empresas de software en
Mxico, dicho estudio se puede ver a detalle en el Artculo publicado en la Revista Digital
Universitaria (vase Anexo 1).

Para poder realizar el estudio se plante una encuesta con 19 preguntas, con respuestas de
opcin mltiple (la cual se incluye en el Apndice A del Anexo 1).

Tambin se recurri a los datos estadsticos de INEGI (Instituto Nacional de Estadstica y
Geografa). Segn INEGI, en el ao 2010 se contabilizaron 9540 empresas en Mxico
dedicadas al desarrollo de software [INE11].

Para calcular el tamao de la muestra, se aplic la encuesta a un grupo piloto con 20
empresas y se obtuvo que:

40% se inclinaron por el uso de metodologas hbridas
60% no se inclinaron por el uso de metodologas hbridas
Estos porcentajes representan los valores estadsticos de p y q respectivamente, mismos que
se utilizaron para encontrar el tamao de la muestra en la siguiente frmula matemtica
[WAL99]:
pq Z NE
pqN Z
n
2 2
2
+
=

Donde:
n es el tamao de la muestra
Z es el nivel de confianza
p
es la variabilidad positiva
q
es la variabilidad negativa
N es el tamao de la poblacin
E es la precisin o el error

Mxico


Octubre 2012 14

Considerando una poblacin de 9540 empresas, un nivel de confianza del 95% y un error
estndar en experimentos cientficos del 5% [COC84], se tiene:

86
86 . 85
) 60 . 0 )( 40 . 0 )( 95 . 0 ( ) 05 . 0 )( 9540 (
) 9540 )( 60 . 0 )( 40 . 0 ( ) 95 . 0 (
2
2
=
+
=
n
n
n

Por lo tanto, se seleccionaron aleatoriamente a 86 empresas de la lista que proporcion el
INEGI para que respondieran la encuesta.

Si el porcentaje de error se hubiera disminuido, entonces el nmero de empresas a
encuestar habra aumentado significativamente, incrementando los costos para obtener la
informacin.

Es importante mencionar que la seleccin de las empresas a las cuales se les aplic la
encuesta fue en forma aleatoria, que no todas las empresas sealadas por el INEGI se
pudieron encontrar y que no todas mostraron inters en participar, de tal manera que en ese
caso fueron sustituidas en forma aleatoria por otras empresas, hasta completar la muestra.

Despus de encuestar a las 86 empresas mexicanas dedicadas a desarrollar software, se
obtuvieron los siguientes resultados de la tabla que se muestra en el Apndice B del Anexo
1. En dicha tabla, slo se muestra la informacin de las preguntas 3, 4, 6, 7, 8 y 13 de la
encuesta; porque estas preguntas son las que permiten determinar el tipo de metodologa
utilizada por una determinada empresa para desarrollar software. (El nombre de las
empresas que corresponden a los nmeros de dicha tabla se encuentran en el Apndice C
del Anexo 1).

Los valores que aparecen como respuesta a las preguntas fueron asignados dependiendo del
tipo de metodologa:
Valor Tipo de metodologa
1 Metodologa gil
2 Metodologa Hbrida
3 Metodologa Tradicional
Al analizar los datos, se encontr que el nmero de empresas que prefieren los tres tipos de
metodologas se distribuyen de la siguiente manera:

Tipo de metodologa Nmero de empresas
Metodologas giles 22
Metodologas Hbridas 50
Metodologas Tradicionales 14
TOTAL 86

Mxico


Octubre 2012 15

Se puede observar que el nmero de empresas que prefieren metodologas hbridas es de 50
y no hbridas de 36.
Tipo de
metodologa
Nmero de
empresas
HIBRIDA 50
NO HIBRIDAS 36

Para determinar si una empresa tiene inclinacin por usar una determinada metodologa, no
se emple una sola pregunta, sino los valores de las preguntas que distinguen a dicha
metodologa. En las preguntas donde era permitido responder ms de una opcin, se sum
la puntuacin y se dividi entre el nmero de respuestas para encontrar el promedio de una
pregunta determinada.

Tomando en cuenta los datos mencionados, se realiz una prueba de hiptesis con
proporciones donde:

p
1
: Proporcin de empresas desarrolladoras de software con
una inclinacin hacia metodologas hbridas.

Hiptesis

H
0
:

p
1
0.50

H
1
:

p
1
<0.50

La interpretacin de la hiptesis es la siguiente:

H
0
:

El 50% o ms de las empresas desarrolladoras de software
tienen una inclinacin hacia el uso de metodologas hbridas.
H
1
:

Menos del 50% de las empresas desarrolladoras de software
tienen una inclinacin hacia el uso de metodologas hbridas.

El estadstico de prueba es [WAL99]:
n
p p
p p
z
) 1 (

Donde:
z es el estadstico de prueba
p
es la proporcin de la muestra que tiene inclinacin
hacia el uso de metodologas hbridas
p
es la proporcin de la poblacin = 0.50
n tamao de la muestra

Mxico


Octubre 2012 16

Sustituyendo:

5096 . 1
86
) 50 . 0 1 ( 50 . 0
50 . 0
86
50
=
= z

La informacin obtenida en el estudio tiene una distribucin normal, de tal manera que con
un nivel de significancia (o error) del 5% el rea de rechazo o no rechazo de la hiptesis
nula H
0
es como se muestra en la Figura 1.2:

Figura 1.2. rea bajo la curva de la distribucin normal
NOTA: El valor del rea bajo la curva normal (-1.645) se obtuvo de tablas estadsticas
[WAL99]

Se observa en la Figura 1.2 que el estadstico de prueba cae en la zona de no rechazo; por
lo tanto, no se rechaza H
0
y se dice que:

El 50% o ms de las empresas desarrolladoras de software tiene
una inclinacin hacia el uso de metodologas hbridas.
Para corroborar la prueba de hiptesis se realiz un intervalo de confianza, el cual podra no
hacerse, pero como su nombre lo indica, proporciona mayor certeza al experimento; as que
el intervalo de confianza se hizo para un nivel de significancia del 5% (porque la prueba de
hiptesis se realiz con un error del 5% y se tiene que considerar la misma en el intervalo).
Los lmites de dicho intervalo se muestran a continuacin (vase Figura 1.3):

Mxico


Octubre 2012 17

96 . 1
025 . 0
2
05 . 0
2
= = = z z z

Figura 1.3. Intervalo de confianza [WAL99]

Lo cual implica que con un error del 5% la proporcin de desarrolladores de software que
prefieren metodologas hbridas se encuentran entre el 47.77% y el 68.5%

n
pq
z p p
n
pq
z p
2 2

+ < <

86
86
50
1
86
50
96 . 1
86
50
86
86
50
1
86
50
96 . 1
86
50

+ < <
p

6855 . 0 4770 . 0 < < p

En la investigacin se puede observar que una metodologa hbrida ser de gran ayuda para
las empresas desarrolladoras de Software de la Repblica Mexicana, pero dadas las
similitudes de Mxico con los pases latinoamericanos seguramente estos resultados se
pueden extrapolar tambin para esos pases, con las respectivas diferencias propias de cada
una de esas naciones, empresas de desarrollo de software y grupos de trabajo.

En resumen esta investigacin mostr que es factible utilizar una metodologa hbrida para
desarrollar software en Mxico. Adems, proporcion informacin til para el diseo de la
misma.

Mxico


Octubre 2012 18

1.4 Beneficios Esperados

Elaborar una Metodologa Hbrida para desarrollar software que cumpla con las
caractersticas de calidad de la Norma Mexicana NMX-I-055-NYCE

Contribuir con la Ingeniera de Software con una nueva Metodologa Hbrida para
desarrollo de proyectos de software.

1.5 imites ! "lcances

Cada etapa del proceso de desarrollo ser definida como un conjunto de tareas
generales, de tal forma que existirn actividades como la estimacin de costos o la
elaboracin de diagramas de UML (Unified Modeling Language, Lenguaje
Unificado de Modelado) que no sern especificados con detalle.

La herramienta META-Software slo proporcionar apoyo en la generacin de
documentacin descrita dentro del proceso de desarrollo de META.

La metodologa ser probada en proyectos reales dentro de empresas mexicanas
para comparar resultados, los proyectos seleccionados debern cumplir con las
caractersticas para las cuales es ideal utilizar la metodologa propuesta.

1.# Or$ani%acin de la &esis

Esta tesis est dividida en cinco captulos, a continuacin se describe cada uno de ellos:

Captulo 1. Introduccin. Planteamiento general del problema, descripcin y
alcance del trabajo, objetivos y beneficios esperados.
Captulo 2. Marco Terico. Metodologas existentes, definiciones, terminologa y
conceptos a ser manejados en el trabajo.
Captulo 3. Metodologa Propuesta: META. Descripcin de la metodologa, as
como de la herramienta de apoyo llamada META-Software.
Captulo 4. Pruebas y resultados obtenidos.
Captulo 5. Conclusiones y trabajos futuros.

1.' (esumen

Las metodologas se han convertido en un elemento clave para la produccin de sistemas y
productos de software con alta calidad; de esta manera y con el objetivo de contribuir en el
crecimiento de la industria dedicada a desarrollar software en Mxico, se presenta la
propuesta de una metodologa basada en la nueva tendencia en el rea de Ingeniera de
Software: las metodologas hbridas.

Mxico


Octubre 2012 19

2 Marco Terico

2.1 )ntroduccin

De acuerdo con el Diccionario de la Real Academia Espaola, la palabra metodologa es un
conjunto de mtodos que se siguen en una investigacin cientfica o en una exposicin
doctrinal [RAE01].

En el rea de Ingeniera de Software, el trmino metodologa se refiere a un marco de
trabajo usado para estructurar, planificar y controlar el proceso de desarrollo de sistemas
computacionales [PRE05].

Actualmente hay dos tipos de metodologas: las tradicionales y las giles; aunque existe
una nueva propuesta: las metodologas hbridas [JIH12].

Las metodologas de desarrollo de software han evolucionando a medida que los
paradigmas de programacin tambin lo han hecho, de tal manera que se acoplaron a ellos
tratando de ajustarse a las nuevas necesidades; dichas metodologas han proporcionando
herramientas y prcticas que ayudan en el proceso de desarrollo de software.

As que resulta de vital importancia revisar la evolucin de las metodologas existentes para
poder proponer una metodologa hbrida que satisfaga las necesidades actuales de las
empresas de desarrollo de software en Mxico.

2.2 Estado del "rte

2.2.1 Metodologas Tradicionales

Existen dos tipos de metodologas tradicionales: las metodologas para el paradigma
estructurado y las metodologas orientadas a objetos [BRA00].

Con el surgimiento del paradigma estructurado, nacieron algunas metodologas acordes a
dicho paradigma; como la creada por Yourdon [YOU76], en la cual el uso de Diagramas de
Flujos de Datos, Diagramas de Contexto, Diagramas de Transicin de Estados y Diagramas
de Entidad-Relacin, aparecan como una constante en el modelado del sistema.

Cuando el paradigma de programacin orientado a objetos apareci, surgieron
metodologas para esta nueva forma de programar tambin; como OMT (Object Modeling
Technique, Tcnica de Modelado de Objetos) [RUM90], Mtrica 3 [MPE11], RUP
(Rational Unified Process, Proceso Unificado de Racional) [IBM11], entre otras.

Las metodologas orientadas a objetos contribuyeron positivamente a las metodologas
tradicionales existentes, al ser incrementales e iterativas. Adems promovieron la

Mxico


Octubre 2012 20

asignacin de roles dentro del equipo de desarrollo, facilitaron las divisin del sistema en
varios subsistemas y fomentaron el rehso de componentes.

As que de manera general, las metodologas tradicionales consideraron la importancia de
documentar el sistema, permitiendo entender, extender y mantener el software; porque estas
metodologas proveen una estructura bien definida y un orden.

Sin embargo, tambin tienen algunas desventajas, entre las cuales se puede sealar que se
requiere de un alto grado de disciplina, no se tiene respuesta rpida a cambios, se genera
documentacin innecesaria y se invierte mucho tiempo en el modelado del sistema.

Adems ests metodologas tienen un plan de proyecto muy riguroso. Por lo cual de manera
general, no consideran que el anlisis, el diseo y la construccin son impredecibles la
mayora de las veces.

2.2.1.1 RUP

El Proceso Unificado de Racional, por sus siglas en ingls RUP, es un proceso de
desarrollo de software que en conjunto con UML (Unified Modeling Language, Lenguaje
Unificado de Modelado) [OMG11], constituye una de las metodologas estndar ms
utilizadas para el anlisis, implementacin y documentacin de sistemas orientados a
objetos y de informacin [PRE05].

Originalmente se dise una metodologa genrica y de dominio pblico, UP (Unified
Process, Proceso Unificado) [JAC05], sin embargo fue comprada por Rational Corporation
de la empresa IBM, adoptando as el nombre de Rational Unified Process [IBM11], por lo
cual para conocer RUP basta con aprender UP puesto que la esencia es la misma.

RUP es una metodologa creada por Ivar Jacobson, Grady Booch y James Rumbaugh. Los
autores de RUP destacan que el proceso de software propuesto por RUP tiene tres
caractersticas esenciales:

a. Est dirigido por Casos de Uso.

Un Caso de Uso es un fragmento de funcionalidad del sistema que proporciona al
usuario un valor aadido; por lo que los Casos de Uso, representan los requisitos
funcionales del sistema [IBM11].

En RUP los Casos de Uso no slo son una herramienta de especificacin de los
requerimientos del sistema; tambin guan su diseo, implementacin y prueba.

Por lo que los Casos de Uso no slo inician el proceso de desarrollo, sino que
proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los
artefactos que son generados en las diferentes actividades del proceso de desarrollo.

Mxico


Octubre 2012 21

b. Est centrado en la arquitectura.

La arquitectura de un sistema es la organizacin o estructura de las partes
consideradas relevantes, lo que permite tener una visin comn entre todos los
involucrados (desarrolladores y usuarios) y una perspectiva del sistema completo.

La arquitectura involucra los aspectos estticos y dinmicos significativos del
sistema, est relacionada con la toma de decisiones que indican cmo tiene que ser
construido el sistema y ayuda a determinar en qu orden; adems, toma en cuenta
los elementos de calidad del sistema, rendimiento, reutilizacin y capacidad de
evolucin.

Por lo que RUP adems de utilizar los Casos de Uso para guiar el proceso, presta
especial atencin al establecimiento temprano de una buena arquitectura que no se
vea fuertemente impactaba ante cambios posteriores durante la construccin y el
mantenimiento. Cada producto tiene tanto una funcin como una forma y la funcin
corresponde a la funcionalidad reflejada en los Casos de Uso y la forma proporciona
la arquitectura.

c. Es iterativo e incremental.

RUP propone un proceso iterativo e incremental en donde el trabajo se divide en
partes ms pequeas o mini proyectos. Permitiendo que el equilibrio entre Casos de
Uso y arquitectura se vaya logrando durante cada mini proyecto, as durante todo el
proceso de desarrollo.

Cada mini proyecto puede verse como una iteracin del cual se obtiene un
incremento que produce un crecimiento del producto.

Una iteracin puede realizarse por medio de una cascada, es decir se pasa por los
flujos fundamentales (Requisitos, Anlisis, Diseo, Implementacin y Pruebas).

El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada
iteracin aborda una parte de la funcionalidad total, pasando por todos los flujos de
trabajo relevantes y refinando la arquitectura.

RUP consta de 5 fases, las cuales se muestran en la Figura 2.1.

Mxico


Octubre 2012 22

Figura 2.1. Etapas de RUP [PRE05]

La fase de inicio abarca la comunicacin con el cliente y las actividades de planeacin. Al
colaborar con los clientes y los usuarios finales se identifican los requisitos de negocios
para el software, se propone una arquitectura aproximada para el sistema y se desarrolla un
plan la naturaleza iterativa e incremental del sistema subsiguiente.

La fase de elaboracin abarca la comunicacin con el cliente y las actividades de modelado
del modelo genrico del proceso. La elaboracin refina y expande los casos de uso
preliminares que se desarrollan como una parte de la fase de inicio, adems, expande la
representacin arquitectnica para incluir cinco visiones diferentes del software: el modelo
de casos de uso, el modelo de anlisis, el modelo de diseo, el modelo implementacin y el
modelo de despliegue.

La fase de construccin es idntica a la actividad de construccin definida para el proceso
genrico del software.

La fase de transicin abarca las ltimas etapas de la actividad genrica de construccin y la
primera parte de la actividad genrica de despliegue. El software se entrega a los usuarios
finales para realizar pruebas beta y la retroalimentacin del usuario reporta tanto defectos
como cambios necesarios. Adems, el equipo de software crea la informacin de soporte
necesaria (por ejemplo, manuales de usuarios, gua de resolucin de problemas,
procedimientos de instalacin) para el lanzamiento. Al final de la fase de transicin el
incremento de software se convierte en un lanzamiento de software utilizable.

Mxico


Octubre 2012 23

La fase de produccin coincide con la actividad de despliegue del proceso genrico.
Durante esta fase se monitorea el uso subsiguiente del software, se proporciona el soporte
para el ambiente operativo (infraestructura) y se reciben y evalan los informes de defectos
y los requerimientos de cambios.

2.2.2 Metodologas giles

El esquema propuesto por las metodologas tradicionales ha demostrado ser efectivo y
necesario en proyectos de gran tamao (respecto a tiempo y recursos).

Sin embargo, este enfoque no resulta ser totalmente adecuado para algunos proyectos
actuales donde el entorno del sistema es cambiante y se exige reducir drsticamente los
tiempos de desarrollo; en este escenario, nacieron las metodologas giles, que en esencia
combinan una filosofa y un conjunto de directrices de desarrollo [SOM09].

La filosofa busca la satisfaccin del cliente y la entrega temprana del software incremental;
equipos de proyectos pequeos y con alta motivacin; mtodos informales; un mnimo de
productos de trabajo y una simplicidad general de desarrollo.

Las directrices de desarrollo resaltan la entrega sobre el anlisis y el diseo, la
comunicacin activa y contina entre los desarrolladores y los clientes.

La agilidad es ms que una respuesta efectiva al cambio; estimula las estructuras y actitudes
de los equipos para que la comunicacin (entre los miembros del equipo, los tcnicos, la
gente de negocios, los ingenieros de software y los clientes) sea menos complicada; resalta
la entrega rpida del software; adopta al cliente como una parte del equipo de desarrollo y
reconoce que la planeacin tiene sus lmites en un mundo incierto por lo cual el plan de
trabajo debe ser flexible.

Todas las metodologas giles se ajustan (en menor o mayor proporcin) al manifiesto para
el desarrollo de software y a los 12 principios sealados en la Alianza gil [PRE05].

Entre las metodologas giles pueden mencionarse: XP (eXtreme Programming,
Programacin Extrema) [BEC99], DSA (Development Software Adaptative, Desarrollo de
Software Adaptativo) [HIG99], Scrum [SCR86] y Crystal [COC04].

Las metodologas giles, al igual que las metodologas tradicionales poseen ciertas ventajas
y desventajas.

Algunas de las ventajas es que presentan respuestas rpidas y efectivas al cambio. Tienen
un plan de proyecto flexible y presentan una gran simplicidad de manera general en el
desarrollo.

Mxico


Octubre 2012 24

Sin embargo, las metodologas giles generan poca documentacin. Y no hacen uso de
mtodos formales. En la Tabla 1 se realiza una comparacin entre las principales
caractersticas de las metodologas giles con las metodologas tradicionales.

Tabla 2.1. Metodologas giles vs. Metodologas Tradicionales [JIM11].

Metodologas giles Metodologas Tradicionales
Basadas en heursticas provenientes
de prcticas de produccin de
cdigo.
Basadas en normas provenientes de
estndares seguidos por el entorno de
desarrollo.
Proceso menos controlado, con
pocos principios.
Proceso mucho ms controlado, con
numerosas polticas/normas.
Pocos artefactos. Ms artefactos.
Pocos roles. Ms roles.
Menos nfasis en la arquitectura del
software.
La arquitectura del software es
esencial.
Producen poca documentacin. Producen una gran cantidad de
documentacin.
Fciles de aprender e implementar. Difciles de aprender e implementar.
No requieren mucha disciplina. Requieren mucha disciplina.
Especialmente preparados para
cambios durante el proyecto.
Cierta resistencia a los cambios.
No existe contrato tradicional o al
menos es bastante flexible.
Existe un contrato prefijado.

2.2.2.1 P

XP, por sus siglas en ingls, Programacin Extrema, es el proceso gil que ms se utiliza en
Mxico (vase Anexo 1); el trabajo fundamental sobre XP fue publicado por Kent Beck, en
1999.
XP se diferencia de las metodologas tradicionales principalmente en que pone ms nfasis
en la adaptabilidad que en la previsibilidad; considera que los cambios de requisitos sobre
la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.
La Programacin Extrema se basa en 12 principios bsicos [BEC99] agrupados en cuatro
categoras:

Mxico


Octubre 2012 25

Retroalimentacin a escala fina.

o El principio de pruebas: consiste en establecer un perodo de pruebas de
aceptacin del programa (llamado tambin perodo de caja negra), donde se
definirn las entradas al sistema y los resultados esperados de estas entradas. XP
recomienda automatizar estas pruebas para poder hacer varias simulaciones del
sistema en funcionamiento.

o Proceso de planificacin: en este principio, el usuario tendr que escribir sus
necesidades, definiendo las actividades que realizar el sistema, con esto se
crear un documento llamado Historias del usuario. Se consideran suficientes
entre 20 y 80 historias (todo dependiendo de la complejidad del problema) para
formar el Plan de Liberacin, el cual define de forma especfica los tiempos de
entrega de la aplicacin para recibir retroalimentacin por parte del usuario. Por
regla general, cada una de las Historias del usuario suele necesitar de una a tres
semanas de desarrollo.

o El cliente como parte del equipo: el cliente tiene la facultad de determinar los
requerimientos, definir la funcionalidad, sealar las prioridades y responder
preguntas de los programadores. Esta fuerte interaccin cara a cara con el
programador disminuye el tiempo de comunicacin y la cantidad de
documentacin, junto con los altos costes de su creacin y mantenimiento;
razones por las cuales el cliente o el representante del cliente debe estar con el
equipo de trabajo durante toda la realizacin del proyecto.

o Programacin en parejas: es un concepto clave durante la actividad de
codificacin; XP recomienda que dos personas trabajen juntas en una misma
computadora para crear el cdigo de una historia. Esto es un mecanismo de
resolucin de problemas en tiempo real (dos cabezas piensan mejor que una) y
el aseguramiento de la calidad en las mismas condiciones.

Proceso continuo en lugar de por lotes.

o Integracin continua: este principio permite al equipo hacer un rpido
progreso implementando las nuevas caractersticas del software, en lugar de
crear builds (o versiones) estables de acuerdo a un cronograma establecido. Los
equipos de programadores XP pueden reunir su cdigo y reconstruir el sistema
varias veces al da, esto reduce los problemas de integracin comunes en
proyectos largos y estilo cascada.

o Refactorizacin: permite mejorar el diseo del sistema durante todo el proceso
de desarrollo a los programadores XP, ellos evalan continuamente el diseo y
recodifican lo necesario, la finalidad es mantener un sistema enfocado a la
minimizacin del cdigo duplicado y/o ineficiente.

Mxico


Octubre 2012 26

o Entregas pequeas: este principio consiste en colocar un sistema en
produccin, el cual se actualiza de forma rpida y constante permitiendo que el
producto sea evaluado en un ambiente real.

Entendimiento compartido.

o Diseo simple: se enfoca en proporcionar un sistema que cubra las necesidades
inmediatas del cliente, ni ms ni menos. Este proceso permite eliminar
redundancias y rejuvenecer los diseos obsoletos.

o Metfora: empleada por los programadores al inicio del proyecto, y se utiliza
en la creacin de las historias y las tarjetas CRC (Class Responsibility-
Collaboration, Clase Responsabilidad-Colaboracin).

XP centra su construccin en historias, que son breves descripciones de una
funcin de un sistema, en lugar de los tradicionales diagramas y modelos UML.

Las tarjetas CRC ayudan a definir actividades durante el diseo del sistema.
Cada tarjeta representa una clase en el paradigma de programacin orientado a
objetos y define sus responsabilidades (lo que ha de hacer) y las colaboraciones
con las otras clases (cmo se comunica con ellas).

De esta manera la metfora se utiliza como un recurso para describir los
requerimientos del sistema.

o Propiedad colectiva del cdigo: el principio seala que se debe generar un
cdigo con propiedad compartida; nadie es el propietario de nada, todos son el
propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales
en los que un programador posee un conjunto de cdigo; XP seala que
mientras haya ms gente trabajando en un mdulo, menos errores aparecern.

o Estndar de codificacin: es necesario definir las reglas para escribir y
documentar el cdigo desarrollado por diferentes equipos o personas; de tal
manera que el cdigo en el sistema se vea como si hubiera estado escrito por
una sola persona.

Bienestar del programador.

o La semana de 40 horas: XP sostiene que los programadores cansados escriben
cdigo de menor calidad, por lo que es necesario minimizar las horas extras y
mantener a los programadores frescos, de esta manera generarn cdigo de
mayor calidad; por lo cual XP sugiere que los programadores no laboren ms de
40 horas a la semana.

Mxico


Octubre 2012 27

XP est organizado como cuatro actividades del marco de trabajo (planeacin, diseo,
codificacin y pruebas), tal como se puede observar en la Figura 2.2.

Figura 2.2. Etapas de XP [PRE05]

2.2.2.2 !cr"#

Scrum o tambin conocida como Mel, es una metodologa gil que define un conjunto de
prcticas y roles. Fue propuesta en 1986 por Hirotaka Takeuchi e Ikujiro Nonaka [SCR86].

Los roles principales en Scrum son el ScrumMaster, que mantiene los procesos y trabaja de
forma similar al director de proyecto, el ProductOwner, que representa a los stakeholders
(interesados externos o internos) y el Team que incluye a los desarrolladores.
Durante cada sprint, un periodo entre una y cuatro semanas (la magnitud es definida por el
equipo), el equipo crea un incremento de software potencialmente entregable (utilizable).

El conjunto de caractersticas que forma parte de cada sprint viene del Product Backlog,
que es un conjunto de requisitos de alto nivel priorizados que definen el trabajo a realizar.

Mxico


Octubre 2012 28

Los elementos del Product Backlog que forman parte del sprint se determinan durante la
reunin de Sprint Planning. Durante esta reunin, el Product Owner identifica los
elementos del Product Backlog que quiere ver completados y los hace del conocimiento del
equipo. Entonces, el equipo determina la cantidad de ese trabajo que puede comprometerse
a completar durante el siguiente sprint. Durante el sprint, nadie puede cambiar el Sprint
Backlog, lo que significa que los requisitos estn congelados durante el sprint.

Adems durante un sprint, se deben realizar las Reuniones de Mel. Estas son reuniones
cortas (por lo general de 15 minutos) y estn presentes todos los miembros del equipo.
Existen 3 preguntas que plantean y responden todos los miembros:

1. Qu se realiz desde la ltima reunin?
2. Cules son los obstculos se encontraron?
3. Qu se espera lograr para la siguiente reunin del equipo?

El ScrumMaster, preside la reunin y evala las respuestas de cada persona. Cada reunin
de Mel ayuda al equipo a descubrir problemas potenciales tan pronto como sea posible.
Estas reuniones diarias tambin conducen a la socializacin del conocimiento y, por ende, a
promover una estructura con organizacin propia (vase Figura 2.3).

Scrum permite la creacin de equipos auto organizado impulsando la co-localizacin de
todos los miembros del equipo y la comunicacin verbal entre todos los miembros y
disciplinas involucrados en el proyecto.

Un principio clave de Scrum es el reconocimiento de que durante un proyecto los clientes
pueden cambiar de idea sobre lo que quieren y necesitan (a menudo llamado requirements
churn) y que los desafos impredecibles no pueden ser fcilmente enfrentados de una forma
predictiva y planificada.

Por lo tanto, Scrum adopta una aproximacin pragmtica, aceptando que el problema no
puede ser completamente entendido o definido y centrndose en maximizar la capacidad
del equipo de entregar rpidamente y responder a requisitos emergentes.

Existen varias implementaciones de sistemas para gestionar el proceso de Scrum, que van
desde notas amarillas "post-it" y pizarras, hasta paquetes de software.

Mxico


Octubre 2012 29

Figura 2.3. Proceso de Scrum [SCR86].

2.2.$ Metodologas %bridas

Como se puede observar, existen una gran diversidad de metodologas; sin embargo, todas
ellas caen dentro de alguna de las dos clasificaciones mencionadas: giles o tradicionales.

As que partiendo del significado de la palabra hbrido, segn el Diccionario de la Real
Academia Espaola [RAE01]:

Se dice de todo lo que es producto de elementos de distinta naturaleza.

Las metodologas hbridas pretenden retomar las ventajas de las metodologas existentes, de
tal forma que sean una combinacin de las mejores prcticas descritas en cada una de ellas.

Dentro las metodologas hbridas existentes se puede mencionar a EssUP (Essential Unified
Process, Proceso Esencial Unificado) como la pionera [JAC10].

2.2.$.1 EssUP

EssUP es una metodologa creada por Ivar Jacobson en el 2010, basada en el UP, los
mtodos giles y la madurez de procesos [JAC10].

EssUP intenta ser gil porque no pretende imponer un proceso especfico, adems toma en
cuenta que es necesario tener flexibilidad y respuestas rpidas ante los cambios; pero, si
deja en claro que es necesario documentar y modelar en UML, con lo cual retoma una
importante caracterstica de las metodologas tradicionales orientadas a objetos.

Por consiguiente es considerada una metodologa hbrida conceptualmente, ya que en la
prctica el equipo de desarrollo de software que pretenda utilizar esta metodologa debe

Mxico


Octubre 2012 30

seleccionar el modelo de ciclo de vida de desarrollo de software que mejor se adapte a sus
necesidades, asignar los roles que crean convenientes y seleccionar las mejores prcticas.

Con lo cual se presenta un problema que podra considerarse una desventaja de EssUp, se
necesita experiencia y conocimiento suficiente para saber elegir las mejores prcticas
dentro de la Ingeniera de Software y aplicarlas de manera adecuada en cada proyecto de
software.

EssUP presenta una nueva tendencia en metodologas para desarrollo de software, ya que
intenta retomar algunas ventajas de las metodologas tradicionales y de las giles,
convirtindola en la primera metodologa considerada hbrida.

2.3 *orma +e,icana *+-.)./55.*01E

Esta norma est incluida dentro de las Normas Mexicanas para el rea de Tecnologa de la
Informacin y es empleada en Ingeniera de Software para evaluar la Calidad de Producto
(se utiliza para medir la calidad de las metodologas porque son un producto); est basada
en la Norma Internacional ISO/IEC 9126-1: 2001 [ISO01].

Esta Norma Mexicana describe un modelo para la calidad del producto constituido por dos
partes (vase Figura 2.4):

1. Calidad interna y externa.
2. Calidad en uso.

Figura 2.4. Modelo para la calidad del producto [NYC06].

La primera parte del modelo especifica seis caractersticas para la calidad interna y externa,
las cuales estn subdivididas a la vez en subcaractersticas. Estas subcaractersticas se
manifiestan externamente cuando el producto se usa y son el resultado de los atributos
internos del mismo.

Mxico


Octubre 2012 31

La segunda parte del modelo especifica cuatro caractersticas de la calidad en uso, pero no
elabora el modelo para la calidad en uso a un nivel inferior al de caractersticas, porque la
calidad en uso es el efecto percibido por el usuario como el resultado de la combinacin de
las seis caractersticas de calidad del producto.

2.$.1 Modelo de &alidad 'nterna ( E)terna.

Los atributos de calidad del producto se clasifican en seis caractersticas (funcionalidad,
confiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad), las cuales son a su vez
subdivididas en subcaractersticas (vase Figura 2.5). Las subcaractersticas se pueden
medir mediante mtricas internas o externas.

Cada una de las caractersticas y subcaractersticas se encuentran definidas en la norma.

Figura 2.5. Modelo para la calidad interna y externa [NYC06].

2.$.2 Modelo de &alidad para la &alidad en Uso.

Los atributos de calidad en uso se clasifican en cuatro caractersticas: efectividad,
productividad, seguridad y satisfaccin (vase Figura 2.6). Estas caractersticas al igual
que las de Calidad Interna y Externa, se encuentran definidas en la NMX-I-055-NYCE.

Mxico


Octubre 2012 32

Figura 2.6. Modelo para la calidad en uso [NYC06].

2.4 (esumen

El desarrollo de software requiere de hacer uso de metodologas, las cuales proveen una
gua al equipo de desarrollo para crear un sistema con calidad. Por lo que resulta importante
conocer qu tipo de metodologas existen, para qu tipo de proyectos estn diseadas y
cmo deben de aplicarse en el ambiente real de desarrollo.

Mxico


Octubre 2012 33

3 Metodologa Propuesta: MTA

3.1 )ntroduccin

Como resultado de la investigacin realizada surge META (MEtodologa Tradicional y
gil), una metodologa hbrida para desarrollo de proyectos de software.

META fue creada a partir de un estudio realizado con empresas mexicanas desarrolladoras
de software [JIM12]. Por esta razn, META se dise tomando en cuenta las necesidades
actuales de esas empresas mexicanas; sin embargo puede aplicarse en empresas de otros
pases en las cuales se desee desarrollar proyectos de software que cumplan con las
caractersticas para las cuales es ideal utilizar META.

META en una metodologa que combina algunas prcticas existentes dentro de las
metodologas RUP (Rational Unified Process, Proceso Unificado de Racional), XP
(eXtreme Programming, Programacin Extrema) y Scrum; por lo cual es un hbrido entre
lo tradicional y lo gil.

3.2 1aracter2sticas de +E&"

META es una metodologa diseada para desarrollar proyectos de software con las
siguientes caractersticas:

Proyectos de desarrollo de aplicaciones Web (en el Apndice 1 se pueden ver las
caractersticas de una aplicacin Web).
Proyectos que se desarrollen en un lapso de 2 a 6 meses.
Equipos de desarrollo conformados a lo ms por 10 integrantes (sin contar a los
usuarios y al cliente).

3.3 (e3uerimientos ! (e3uisitos para el 4so de +E&"

Es necesario contar y cumplir con los tres siguientes requerimientos y requisitos para hacer
uso de META:

1. Requerimientos Materiales:

Papel rotafolio.
Notas adhesivas.
Cinta adhesiva.
Marcadores de colores.
Carpetas o Folders.
Hojas blancas.

Mxico


Octubre 2012 34

2. Requisitos de Conocimientos Previos:

Saber realizar Diagramas en UML (Unified Modeling Language, Lenguaje
Unificado de Modelado) [OMG11].
Saber realizar Diagramas Entidad-Relacin [ROS08].
Saber realizar Estimaciones de Costos.
Saber realizar Prototipos de software.
Saber programar en el lenguaje a utilizar con META.

3. Requisitos de la Empresa:

Seleccionar proyectos de desarrollo de software que cumplan con las
caractersticas para las cuales es ideal utilizar META (vase Seccin 3.2)
Tener los equipos de cmputo necesarios para que cada integrante del equipo
META pueda desarrollar su funcin adecuadamente.
Proporcionar al equipo de desarrollo un espacio de trabajo dentro de las
instalaciones de la empresa que les permita estar co-localizados.

3.4 1apacitacin para el uso de +E&"

Para utilizar META es necesario contar con los requerimientos y conocer:

1. Los roles que deben existir.
2. Los principios metodolgicos de META.
3. El proceso de desarrollo de META.

3.5 (oles en +E&"

En META se plantea que deben existir los siguientes roles o papeles dentro del equipo de
desarrollo, vase Tabla 3.1:
Tabla 3.1. Roles en META
ROL DESCRIPCION
Cliente Especifica los requerimientos y es quin financia el proyecto de
software.
Lder del
proyecto
Se encarga de buscar nuevos proyectos, recopilar la informacin
necesaria para establecer los requerimientos y negociar los
proyectos; por lo que es el integrante del equipo de desarrollo
que tiene ms relacin con el cliente/usuarios, as que debe tener
facilidad para comunicarse con ellos en trminos que el
cliente/usuarios comprendan.
Es adems, el intermediario entre el cliente y el administrador
del proyecto, por lo cual debe de saber cmo se realiza el

Mxico


Octubre 2012 35

software tambin.
Debe de tener la habilidad de unir ideas, personas y recursos; as
como tener facilidad para la toma de decisiones.
Administrador
del proyecto
Se encarga de coordinar a los programadores, al probador y al
documentador. Adems organiza las reuniones necesarias para
analizar los requerimientos, realizar el diseo, el plan de
proyecto y las pruebas.
Debe acompaar al lder del proyecto en las reuniones con el
cliente.
Programadores Son los responsables de codificar el diseo.
Probador Se encarga de realizar las pruebas en todo momento. Es decir,
verifica que se realizan las actividades de manera adecuada en
cada fase del proceso de desarrollo de software. Adems deber
cumplir con la tarea de asegurar la calidad, haciendo uso del
Ciclo y los 14 Principios de Deming.
Documentador Su funcin principal es generar los documentos que respalden y
documenten lo que se va generando a lo largo del proceso de
software.
Usuarios finales Son las personas que interactan con el software una vez que se
libera para su uso productivo.

META retoma una importante caracterstica de las metodologas giles: incluir a los
usuarios finales y al cliente como parte del equipo de desarrollo. Esto ayuda en gran medida
a lograr el xito del proyecto, ya que son ellos quienes saben lo que quieren, por lo tanto, se
debe tener el cuidado de propiciar un ambiente de confianza y colaboracin con ellos.
Si el equipo de desarrollo es menor a 5 integrantes, es decir que no se pueda asignar al
menos un rol a cada integrante (Lder del Proyecto, Administrador del Proyecto,
Programador, Probador y Documentador), pueden hacerse las adecuaciones necesarias para
que una persona cumpla con uno o dos roles; aunque se sugiere que una persona sea
destinada a cumplir slo un rol.
De manera general, se puede resumir el flujo de comunicacin entre los integrantes del
equipo de desarrollo tal como se muestra en la Figura 3.1.

Mxico


Octubre 2012 36

Figura 3.1. Roles en META
*

*
El diagrama utilizado para representar el flujo de comunicacin es un diagrama con simbologa propia, as
como otros diagramas utilizados en este captulo, en caso contrario llevan la referencia respectiva a su autor.

3.# Principios +etodol$icos de +E&"

Para poder utilizar adecuadamente META se deben conocer los siguientes principios
metodolgicos:

Hacer uso de papel rotafolio.

Es un papel bond de medidas 63.5cm x 77.47cm aproximadamente. Es usado como
una herramienta de comunicacin para aplicarse durante el trabajo cara a cara
porque facilita la interaccin y el debate.

Se puede utilizar en exposiciones, con explicaciones dialogadas u observaciones, as
como en la presentacin de resultados de un trabajo en equipo o para realizar lluvias
de ideas temticas.

Es conveniente el uso de este tipo de papel porque tiene un bajo costo, es fcil de
transportar, propicia la participacin en un grupo y se pueden retomar los
contenidos debido a la permanencia del mensaje, lo cual no se asegura si se escribe
en un pizarrn por ejemplo.

Mxico


Octubre 2012 37

Adems se sugiere hacer uso de marcadores o plumones de distintos colores para
tratar de proporcionar mayor presentacin a lo escrito en el rotafolio.

Realizar lluvias de ideas durante las juntas.

Esta tcnica consiste en la reunin del equipo de trabajo para intentar descubrir cul
es el problema, cul es la causa de un problema y cmo resolverlo; a travs de la
participacin de cada miembro con sus ideas.

El proceso que se sigue para esta tcnica es el siguiente:

a) Seleccionar el tema.
b) Generar la lluvia de ideas a travs de la participacin de los involucrados.
c) Realizar el anlisis de las ideas.
d) Seleccionar las mejores ideas.

Para obtener mejores resultados se recomienda seguir las siguientes reglas:

1) El lder debe analizar con anterioridad los puntos a tratar, de manera que
presente slo opciones a los dems.
2) Todos los presentes en la reunin deben participar.
3) Se deben anotar las ideas en el papel rotafolio.
4) Se deben analizar las ideas; sin embargo, el lder del proyecto ser quien
tome las decisiones finales tomando en cuenta la experiencia de los dems
miembros del equipo.

Hacer uso del Ciclo de Deming [DEM90] para la Gestin de Riesgos durante todo
el proceso de desarrollo de META.

Durante el proceso de desarrollo del software, se tendrn que prevenir riesgos y
eliminarlos, resultando conveniente hacer uso del Ciclo de Deming, vase Figura
3.2.

Como parte de los documentos que se deben elaborar, se tiene un apartado de
documentacin para la gestin de riesgos y problemas, mismos que se explicarn en
la seccin del Proceso de Desarrollo de META; sin embargo aqu se describe el
mtodo adecuado para realizar dichas gestiones.

Mxico


Octubre 2012 38

Figura 3.2. Ciclo de Deming [DEM90]

En el Ciclo de Deming se identifican 4 actividades primordiales, las cuales se
describen a continuacin:

Planear: se requiere identificar los objetivos y procesos que se requieren mejorar;
para despus recopilar los datos para profundizar en el conocimiento del proceso.
Posteriormente se deben analizar e interpretar los datos, establecer los objetivos de
mejora, detallar las especificaciones de los resultados esperados y definir los
procesos necesarios para conseguir estos objetivos.

Hacer: Implementar los procesos necesarios para llevar a cabo el plan elaborado con
anterioridad.

Verificar: Comprobar que se implementaron las cosas segn lo planeado.

Actuar: Documentar el ciclo para tener presente cmo mejorar la prxima vez.

Considerar los 14 Principios de Calidad de Deming [DEM90], para garantizar
calidad en el proceso y en el producto de software. Los 14 principios han sido
adecuados para ser empleados en una empresa de desarrollo de software.

La razn por la cual se consider el Ciclo y los Principios de Deming como una
opcin viable para ser incluida en META, fue porque la mayora de los estndares
internacionales de calidad adoptan el Sistema Deming como punto de referencia en
sus propuestas; esto se determin despus de realizar una estancia de investigacin

Mxico


Octubre 2012 39

con el Dr. Francisco Ortiz Zaragoza en la Universidad Politcnica de Cartagena, en
Espaa.

Los 14 principios se describen a continuacin:

1) Crear constancia, con la finalidad de ser ms competitivos y permanecer en
el mercado.

En este punto se tratan las mejoras a la compaa, como son el tener y hacer
uso de tecnologa actualizada, contar con equipo de buena calidad, procesos
y procedimientos adecuados para la elaboracin del producto de software;
con lo cual se garantizar la permanencia en el mercado de la empresa.

2) Comprender y adoptar la nueva filosofa.

La calidad debe convertirse en la nueva cultura. Ante el reto de la
competitividad internacional, es necesario que todos los miembros del
equipo tengan consciencia de eliminar errores, defectos, mala calidad y
malas prcticas. De esta manera, un servicio confiable reduce los costos, las
demoras y los errores.

Para el logro de la calidad se tendr que concientizar a todos los integrantes
del equipo de desarrollo. Ya que la calidad debe ser compromiso de todos.

3) Terminar con la dependencia de la inspeccin masiva.

Es necesario acabar con las inspecciones de volmenes grandes de
informacin o de grandes mdulos, ya que esto resulta costo y no
necesariamente es acertado.

A cambio de esto, es necesario concientizar a los integrantes del equipo que
deben obtener desde un principio pequeos mdulos o productos de
software de calidad.

4) Terminar con la prctica de hacer negocios con base al precio.

Antes de adquirir hardware o software, se debe asegurar que cuentan con la
calidad que se requiere, en lugar de comprar porque tienen el menor costo.

5) Encontrar y resolver problemas para mejorar el sistema de desarrollo de
software, constante y permanentemente.

Es necesario que el equipo est preparado para afrontar los problemas que se
presenten da a da. Con esta pauta, se analizarn y se detectarn los

Mxico


Octubre 2012 40

problemas, para su correccin y prevencin. Para lo cual se debe hacer uso
del Ciclo de Deming descrito anteriormente.

6) Instruir mtodos modernos de adiestramiento.

Es de suma importancia que a los integrantes del equipo se les destine
recursos, tanto de tiempo como de dinero, para que puedan adquirir un
adiestramiento adecuado y les sea ms sencillo acoplarse a la empresa de
desarrollo de software y al equipo con el cual trabajarn.

7) Adoptar e implantar el liderazgo.

Dentro de la empresa como dentro del equipo de desarrollo, debe existir el
liderazgo.

Un buen lder (como lo define Deming), crea confianza e impulsa a los
dems para que busquen nuevas maneras para hacer las cosas. Adems
dirige los cambios, busca modelos de accin para hacer lo que est bien y
opera con los recursos emocionales de los integrantes del equipo, con
valores, compromisos y aspiraciones.

Es decir, un buen lder hace sentir a los dems integrantes un alto nivel de
realizacin, mostrndoles cmo contribuye su trabajo a la realizacin de las
metas del proyecto; con lo cual se estimula la necesidad humana de: sentirse
importante, diferente y til.

8) Expulsar el miedo dentro del equipo de desarrollo.

Los integrantes necesitan trabajar en un ambiente estable y seguro, que
ofrezca apoyo y no amenazas. Por esta razn, se deber tener cuidado en los
siguientes aspectos para evitar el temor:

a) Posibilidad de perder el empleo
b) Posibilidad de sufrir algn dao fsico.
c) Evaluacin del desempeo.
d) Fracasos en la capacitacin.
e) Mala supervisin.
f) Falta de definiciones operacionales.

9) Romper las barreras entre los integrantes del equipo.

Es muy importante que todos los integrantes del equipo de desarrollo estn
interrelacionados entre s, que formen un equipo con un fin comn, que es el
de producir un producto de software de excelente calidad y entregarlo a

Mxico


Octubre 2012 41

tiempo. Por lo cual es importante quitar las barreras que impiden la
comunicacin.

Los factores ms comunes de las barreras son:

a) Mala comunicacin o ausencia de la comunicacin
b) Desconocimiento de las metas
c) Decisiones o polticas confusas y que requieren interpretacin
d) Cuotas y normas de trabajo
e) Celos por posiciones y salarios
f) Problemas interpersonales

Es importante tener en cuenta que la duracin y el xito de una empresa y/o
equipo de desarrollo, estar condicionado por las buenas relaciones, la
comunicacin y la confianza que se les profese.

Para lo cual, se tiene que cambiar la actitud de los miembros del equipo o de
la empresa; entendindose que todos deben estar abiertos a la comunicacin
y dar apoyo completo para realizar las tareas necesarias.

10) Eliminar las metas numricas.

Las metas numricas que se fijan para los integrantes del equipo de
desarrollo, sin ofrecer una gua que lleve a la meta, son contra producentes,
ya que generan frustracin y resentimiento.

Algunos ejemplos de carteles y metas numricas son:

a) Hacerlo bien la primera vez.
b) Nuestro trabajo es la calidad.
c) Incrementar las ventas en un 10% el siguiente ao.

11) Eliminar estndares de trabajo que estipulen cantidad y no calidad.

Las cuotas numricas slo toman en cuenta los nmeros, no la calidad ni los
mtodos. Porque estimulan a la gente para que produzcan cantidad en vez de
calidad.

Por lo que no se debe recurrir a las cuotas cuando lo que se requiere es
liderazgo.

Los objetivos no son malos; el problema es cuando se fijan objetivos sin
proveer los medios para alcanzarlos, o cuando los mismos son utilizados con
criterio de inspeccin final.

Mxico


Octubre 2012 42

Un estndar de trabajo apropiado definir lo que es y lo que no es aceptable
en cuanto a calidad, para lo cual sugiere Deming que se estudie el trabajo y
que se definan los lmites del trabajo.

12) Eliminar las barreras que impiden al integrante del equipo estar orgulloso
de su labor.

Es importante que los miembros del equipo de desarrollo estn enterados de
cul trabajo es aceptable y cul no; ya que esto los motivar a hacer las
cosas bien y les permite hacer una autoevaluacin.

Para esto es recomendable:

a) Proporcionar a los integrantes del equipo y de la empresa, materiales,
herramientas y mtodos apropiados.
b) Atender las necesidades bsicas de los integrantes.
c) Cerciorarse de que los integrantes entienden la gran importancia que
desempean dentro del proceso de desarrollo del software.

13) Educacin y entrenamiento.

Esto permitir adaptar a las personas a nuevos proyectos y nuevas
responsabilidades. Adems, permite la superacin, el desenvolvimiento y la
confianza del integrante del equipo.

14) Crear una estructura que impulse da a da los trece puntos anteriores.

Esto se requiere para tener un proceso de calidad que genere productos de
software que satisfagan las expectativas del cliente, cumplan lo pactado en
tiempo y recursos.

Por lo que con dichos principios se guan las actividades dentro del proceso de desarrollo
de META.

3.' Proceso de 5esarrollo de +E&"

Dentro de META se tienen 4 fases o etapas principales (Planteamiento, Preparacin,
Construccin e Implantacin), tal como se puede apreciar en la Figura 3.3, las cuales se
describirn ms adelante:

Mxico


Octubre 2012 43

Figura 3.3. Proceso de desarrollo de META

El proceso de manera general se puede comparar con lo que pasa en una carrera de
obstculos, en donde todo el equipo de desarrollo corre como un solo individuo hasta llegar

Mxico


Octubre 2012 44

a la meta; haciendo la analoga, cada una de las etapas son obstculos que el equipo debe
pasar. Pero, a diferencia de lo que pasa en una carrera de obstculos, si no se puede brincar
una etapa en un primer intento, existe un camino alternativo que permite realizar una serie
de iteraciones para poder estar preparados y saltar para continuar con la siguiente fase.

$.*.1 Plantea#iento

En esta etapa se deben cumplir los siguientes objetivos:

Definir los requerimientos del proyecto que se va a desarrollar.

Esto se hace en constante comunicacin entre el lder y el cliente a travs de
reuniones con lluvias de ideas. Es recomendable que el administrador del proyecto
tambin est presente para poder brindar una asesora tcnica en caso de ser
necesario.

Las propuestas o ideas deben escribirse en un papel rotafolio de tal manera que sea
visible para todos los involucrados lo que se plantea; se sugiere que el lder sea
quien escriba las ideas, aunque si el cliente o el administrador desean escribir
personalmente algo es vlido.

Para esta actividad en particular, se sugiere que se le d al cliente la oportunidad de
expresar sus ideas, porque en muchas de las ocasiones los desarrolladores creen
saber lo que l cliente quiere y se puede cometer el error de disear algo que no se
desea.

Despus de escuchar lo que el cliente desea, se deben elaborar los Diagramas de
Casos de Uso tal como los plantea UML [OMG11], los cuales describirn la
funcionalidad del sistema a desarrollar para corroborar as, que se comprendi lo
que el cliente desea.

Adems, se debe(n) elaborar el Diagrama de Interfaz-Navegacin de la(s)
ventana(s) principal(es), con la intencin de tener una referencia del diseo que
tendrn las dems ventanas. Estos diagramas permitirn al cliente visualizar el
software, por lo que son de gran ayuda al momento de definir lo requerimientos.

Una pauta a considerar para saber cuntas ventanas deben dibujarse a travs de un
Diagrama de Interfaz-Navegacin, es tomando en cuenta el nmero de actores
diferentes o usuarios del sistema.

Por ejemplo se pueden ver los Diagramas de Interfaz-Navegacin de las Figuras
3.4, 3.5 y 3.6, en ellas se muestran los elementos que incluirn la ventana principal
o la pgina de inicio del sitio, y se indican hacia a dnde se dirigen los botones con

Mxico


Octubre 2012 45

nmeros encerrados en crculos de color verde; este ejemplo muestra cmo deben
de especificarse estos diagramas en el papel rotafolio.

Figura 3.4. Ejemplo de Diagrama Interfaz-Navegacin de la pgina de inicio del
sitio.

Figura 3.5. Ejemplo de Diagrama Interfaz-Navegacin de la pgina principal de los
Clientes.

Mxico


Octubre 2012 46

Figura 3.6. Ejemplo de Diagrama Interfaz-Navegacin de la pgina principal de las
Tiendas

Si an mostrando los Casos de Uso y los Diagramas de Interfaz-Navegacin se
presentan problemas para comprender lo que el cliente desea, se pueden realizar
prototipos, aunque se debe tener el cuidado de no invertir mucho tiempo en ellos,
slo deben servir como tcnica de recopilacin de informacin.

Una vez que el cliente otorg el visto bueno de los Diagramas de Casos de Uso
planteados inicialmente en el papel rotafolio, es necesario que el documentador
haga uso de alguna herramienta grfica como Paint o Visio, para respaldar dicha
informacin en una carpeta o flder del proyecto, de tal manera que la empresa vaya
generando su propio repositorio de informacin de los proyectos.

En el Anexo 3 se pueden ver las hojas que deben contener la carpeta o flder del
proyecto, a travs del cual se documentar lo referente al proyecto.

En el caso de los Diagramas Interfaz-Navegacin se recomienda el uso del software
Dreamweaver, iWeb o FrontPage; considerando que stos permiten generar
una vista real de las pantallas principales.

Realizar la estimacin de costo monetario, tiempo y recursos; tanto materiales como
humanos. Se sugiere hacer uso de mtodos de estimacin como Puntos de Funcin
[ALB79] y/o COCOMO (COnstructive COst MOdel, Modelo Constructivo de
Costos) [BOE81]; dicha estimacin se puede hacer con la ayuda de META-Software

Mxico


Octubre 2012 47

(vase Figura 3.7), aunque es importante sealar que se requiere tener
conocimiento previo para realizar dichos clculos.

Figura 3.7. Estimacin con META-Software

Elaborar, pactar y firmar un contrato que estipule los costos y los requerimientos,
as como penalizaciones y otros aspectos legales; en el Apndice 2 se puede ver la
plantilla general del contrato elaborado con la asesora jurdica de la Lic. Paulina
Vega Aguilar. El contrato puede ser elaborado con la ayuda de la herramienta
META-Software (vase Figura 3.8), en el cual slo es necesario ingresar los
campos necesarios para llenar la plantilla general del contrato; si se desea modificar
dicho contrato generado con META-Software, se puede editar abrindolo con ayuda
de algn procesador de textos para extensiones de archivos .doc (como Word de
Microsoft).

Mxico


Octubre 2012 48

Figura 3.8. Generacin de contrato con META-Software

Elaborar un plan general del proyecto.

Para crear el plan general del proyecto se sugiere que la unidad de tiempo sea la
semana. El primer paso para crear el plan general, consiste en calcular el tiempo
que se tendr para llevar a cabo cada una de las 4 fases que se deben cumplir para
desarrollar el software. Para lo cual se debe tomar en cuenta la siguiente
distribucin de tiempo y esfuerzo para cada etapa:

Planteamiento 15%
Preparacin 15%
Construccin 60%
Implantacin 10%
100%

As que si se tiene estimado que el proyecto se terminar en x tiempo, el clculo a
realizar es (en nmero de semanas):

Clculo etapa 1 = 0.15 x

Mxico


Octubre 2012 49

Es decir, una vez que se multiplica el nmero de semanas que se tendrn para
realizar el proyecto por el porcentaje de esfuerzo, se debe redondear cada clculo.
De esta manera, se elabora un calendario en papel rotafolio (como el que se
muestra en la Figura 3.9 y 3.10), con la finalidad de mostrar el tiempo que se debe
dedicar a cada etapa, pero sin especificar qu se realizar cada da, puesto que esto
se definir en la etapa de Preparacin.

Dicho calendario deber pegarse en un lugar visible para todos los miembros del
equipo:

Figura 3.9. Plan de proyecto general para el mes de diciembre

Figura 3.10. Plan de proyecto general para el mes de enero

Mxico


Octubre 2012 50

En las Figuras anteriores se identifican cada una de las etapas, las cuales
corresponden a un clculo de ejemplo para un proyecto de 8 semanas:

Despus de elaborar los calendarios, se debe realizar una lista de actividades, as
como asignarle la precedencia a cada una. Esto con la finalidad de asignarle una
duracin, una etapa y uno o ms responsables.

La lista de actividades debe incluirse en una Tabla de Actividad-Responsabilidad
(vase Tabla 3.2). Cabe mencionar, que es recomendable no invertir mucho tiempo
en esta tabla, puesto que ser la propuesta inicial elaborada por el lder y el
administrador para ser discutida en las reuniones de la etapa de Preparacin, por lo
que se deber realizar en papel rotafolio.

Tabla 3.2. Tabla de Actividad-Responsabilidad

ACTIVIDAD PRECEDENCIA DURACIN ETAPA RESPONSABLE (S)
Actividad A - 1 da 1 Miguel
Actividad B A 1 da 2 Graciela
Actividad C B 2 das 3 Dinora
Actividad D C,B 1 da 4 Gilberto

En esta etapa, se puede hacer uso de una serie de ciclos, considerando que el software tiene
una naturaleza evolutiva; estos ciclos servirn para pactar acuerdos entre los involucrados.

Es decir, se deben llegar a acuerdos para definir los requerimientos del sistema, del costo,
del tiempo de desarrollo y de las clusulas presentes en el contrato.

$.*.2 Preparaci+n

En esta etapa se deben establecer las tareas y responsabilidades entre los miembros del
equipo. Por lo que esta etapa se resume en la realizacin del anlisis y el diseo a travs de
algunas iteraciones si se requieren, es decir a travs de varias juntas en donde el lder de
proyecto, el administrador del proyecto, los programadores, el probador y el documentador
colaboren con su experiencia y sus ideas para poder llevar a cabo los objetivos de esta fase.

Mxico


Octubre 2012 51

Como punto de partida, en esta fase de deben realizar los Diagramas de Interfaz-
Navegacin (como los de las Figuras 3.4, 3.5 y 3.6) de todas las pginas. Estos deben estar
pegados en un lugar visible para todos, porque se ocuparn durante las siguientes fases.

Una vez realizados dichos diagramas, se deben presentar al cliente y hacer las correcciones
necesarias; despus se deben realizar los diagramas de Entidad-Relacin (en caso de ser
necesarios para modelar la Base de Datos) y los diagramas de UML que se requieran. Estos
diagramas tambin debern estar pegados en un lugar visible para todos, con el objetivo de
agilizar la comunicacin.

Adems, se analizar la propuesta de la Tabla de Actividad-Responsabilidad elaborada en
la fase de Planteamiento, y se realizarn los cambios necesarios.

Se llenar el Calendario o Plan general del proyecto de la fase inicial, en el cual se pueden
adherir notas adhesivas o bien escribir directamente sobre el papel.

Tambin se debe acordar entre los miembros del equipo:

La Tecnologa Web a utilizar (JSP, PHP, etc)
El manejador de Bases de Datos (MySQL, Oracle, PostgreSQL, etc)
El Servidor Web (Apache, Tomcat, etc)
La nomenclatura de las clases, atributos y mtodos (es decir cmo se van a nombrar
las clases, si van a llevar maysculas al iniciar el nombre, minsculas, ect).
El Entorno de Desarrollo que se va a utilizar (NetBeans, Eclipse, JCreator, ect)
El Sistema Operativo en el cul trabajarn programando (Linux, Windows,
Mac, etc).

En esta fase es importante mencionar que el lder deber presentar su propuesta inicial en
los asuntos a tratar en las juntas, porque si deja todo a consideracin del resto del equipo se
podra invertir mucho tiempo en decidir cul de todas las ideas presentadas es la adecuada.

Como en esta fase tendr la informacin del proyecto pegada en un lugar visible para todos
los integrantes del equipo en papel rotafolio, el documentador puede fotografiar dichos
rotafolios con la intencin de anexarlos en el flder del proyecto, as como de respaldar
digitalmente dicha informacin.

Finalmente se requiere que el administrador, el probador y el documentador trabajen en
conjunto para establecer el plan para la gestin de riesgos y problemas. La Tabla 3.3
presenta los campos necesarios para identificar los posibles riesgos o problemas, fue
diseada tomando en cuenta el Ciclo de Calidad de Deming, con sus 4 actividades (Planear,
Hacer, Verificar y Actuar); por lo que se requerir emplear el ciclo para ir llenando la tabla.

Mxico


Octubre 2012 52

Tabla 3.3. Tabla de Gestin de Riesgo y Problemas

Objetivo Fase Resultaos
es!e"aos
P"o#esos $e#esa"ios !a"a al#a$%a"
objetivos
Co&!"oba#i'$ Obse"va#io$es

$.*.$ &onstr"cci+n

En esta fase se lleva a cabo la codificacin del diseo que se plante en la fase de
preparacin.

La construccin es dirigida por los Diagramas Interfaz-Navegacin de todo el sitio y por el
Plan General (el calendario y la tabla de Actividad-Responsabilidad).

Para lo cual, los programadores codificarn lo que les fue asignado y debern incluir al
inicio de las clases que estn programando una descripcin de lo que hacen, con la finalidad
de ir documentando su cdigo.

El cdigo que generen, ser verificado por el probador y el administrador del proyecto, de
tal forma, que cada 3 das se verificar que se estn haciendo las actividades segn lo
planeado, permitiendo tambin, la deteccin temprana de errores.

Adems se har uso de algunas prcticas propuestas en otras metodologas como:

Juntas cada 3 das o cada semana.

Si se tiene poco tiempo para esta fase las juntas debern hacerse cada 3 das,
de lo contrario, semanalmente. Y las presidir el lder y el administrador,
preguntando a cada miembro:

4. Qu se realiz desde la ltima reunin?
5. Cules son los obstculos se encontraron?
6. Qu se espera lograr para la siguiente reunin del equipo?

El documentador deber anotar las respuestas de cada miembro y
respaldarlas en el flder del proyecto.

Estas juntas permitirn generar un ciclo de comunicacin en esta etapa de tal
manera, que se puedan identificar avances y problemas.

Mxico


Octubre 2012 53

Programacin en parejas

La programacin en parejas es un concepto de XP. Consiste en que dos
personas trabajen juntas en una misma computadora para crear el cdigo.
Esto es un mecanismo de resolucin de problemas en tiempo real (dos
cabezas piensan mejor que una) y el aseguramiento de la calidad en las
mismas condiciones. Esto se aplicar cuando se tenga poco tiempo para
desarrollar la aplicacin y se pueda contar con los recursos necesarios
(monetarios y humanos).

Antes de pasar a la siguiente fase, se deben realizar las pruebas de caja negra (que evalan
la funcionalidad del sistema, lo que ve el usuario final), de tal manera que se pruebe la
funcionalidad del sistema. Estas pruebas debern estar diseadas por el probador y con el
visto bueno del administrador del proyecto.

Algunas de las pruebas que deben realizarse son:

Pruebas a la navegacin del sistema (que los links sean los adecuados).
Pruebas de seguridad
Pruebas de validacin de los campos.

Cada vez que una ventana sea codificada y probada, se anotar con una nota adhesiva en el
Diagrama de Interfaz-Navegacin una nota que indicar que est hecha. Esto servir para
comunicar los avances y como motivacin a la persona que pega su nota.

Como punto final, el documentador elaborar el manual de usuario, el cual ser supervisado
por el administrador.

$.*., '#plantaci+n

En esta etapa se instala el software de manera operativa en el Servidor Web y se llevan a
cabo las pruebas finales con los usuarios a travs de una serie de retroalimentaciones.

Adems, debe evaluarse la satisfaccin del cliente, como parte del proceso de calidad que
se debe llevar durante todo el proceso de desarrollo en META.

3.6 1omponentes de +E&"

META se compone de algunas caractersticas tomadas de las metodologas RUP, XP,
Scrum y de algunas diseadas propiamente como parte de META (vase Tabla 3.4).

Mxico


Octubre 2012 54

Tabla 3.4. Componentes de META

Caractersticas
tomadas de
RUP
Caractersticas
tomadas de XP
Caractersticas
tomadas de Scrum
Aportaciones de META
Utilizar los
Diagramas de
Casos de Uso
para representar
los requisitos
funcionales del
sistema.
Utilizar los
Diagramas de
UML para
modelar el
software.
Considerar al
cliente como
parte del equipo.
Programacin
en parejas.
Realizar pruebas
de caja negra
para evaluar la
funcionalidad
operativa del
software
Hacer uso de las
Tarjetas CRC
(Class
Responsibility-
Collaboration,
Clase
Responsabilidad
-Colaboracin)
para asignar las
tareas.
Guardar la
documentacin del
proyecto en el
Backblog, en META
se llama Carpeta del
Proyecto.
Asignar el rol de
ScrumMaster a un
miembro del equipo
que tiene
comunicacin con el
cliente y el
ProductOwner; en
META el
ScrumMaster es el
Lder del Proyecto.
Asignar el rol de
ProductOwner a un
miembro del equipo
que tiene
comunicacin con el
cliente y el
ScrumMaster; en
META el
ProductOwner es el
Administrador del
Proyecto.
Hacer uso de notas
adhesivas para
agilizar la
comunicacin de los
integrantes del
equipo.
Reuniones Mel para
conocer los avances
en proyecto de
desarrollo de
software.
Co-localizacin de
los miembros del
equipo y
comunicacin
verbal.
Hacer uso del papel rotafolio para propiciar la
participacin del equipo.
Establecer las reglas para realizar las lluvias de
ideas durante las reuniones de equipo.
Disear las cuatro fases del proceso de desarrollo
de META.
Emplear la analoga de una carrera de atletismo
con obstculos para explicar el proceso de
desarrollo de META.
Disear los Diagramas de Interfaz-Navegacin y
su simbologa para poder modelar las ventanas
del sistema.
Disear un mtodo para calcular el tiempo
necesario para llevar a cabo cada una de las
cuatro etapas del proceso de desarrollo.
Proponer la elaboracin de un calendario en
papel rotafolio, para mostrar a los miembros de
equipo el tiempo calculado para realizar cada
fase y las actividades correspondientes.
Creacin de un nuevo modelo de ciclo de vida
que combina los modelos iterativo y secuencial.
Disear la tabla de actividad-responsabilidad a
partir de las tarjetas CRC y el mtodo PERT
(Program Evaluation and Review Technique,
Tcnica de Evaluacin y Revisin de Programas)
[HIL02] para establecer las actividades que se
llevaran a cabo, su precedencia, etapa y
responsable.
Crear la herramienta de software META-
Software para apoyar en la actividad de
estimacin de costos con el mtodo de puntos de
funcin y/o COCOMO
Crear una herramienta de software llamada
META-Software para apoyar la elaboracin del
contrato de desarrollo.
Adecuar los 14 principios de calidad de Deming
para emplearlos como parte de la gestin de
calidad de META
Definir los roles y las caractersticas que deben
tener las personas para que desempeen una
determinada funcin dentro del equipo
Proponer el ciclo de Deming para Gestionar los
riesgos y problemas.
Disear la Tabla de Gestin de Riesgos de
Problemas a partir del Ciclo de Deming.

Mxico


Octubre 2012 55

3.7 8entajas de +E&"

META posee las siguientes ventajas:

Es una metodologa que se dise a partir de una investigacin realizada con las
empresas de desarrollo de software en Mxico, por lo cual se adapta a sus
necesidades reales.
Es una metodologa probada en proyectos reales con resultados satisfactorios.
Es una metodologa que cumple con las caractersticas de calidad de la Norma
Mexicana NMX-I-055-NYCE.
Al evaluarse a travs de la Norma Mexicana NMX-I-055-NYCE las metodologas:
META, RUP, XP Y Scrum; META mostr resultados superiores de calidad.
Es una metodologa en la cual no se requiere invertir un largo periodo de tiempo
para su capacitacin.
Es una metodologa que no pide experiencia en el uso de diversas prcticas de
Ingeniera de Software.

3.1/ imitaciones de +E&"

META posee las siguientes limitaciones:

Se dise para desarrollar proyectos de tipo Web.
Se dise para proyectos que se desarrollen en un lapso de tiempo no menor a 2
meses y no mayor a 6 meses.
Se dise para utilizarse en equipos de desarrollo no mayores a 10 personas (sin
incluir cliente/usuarios).
No se proporciona una gua para el aprendizaje de los conocimientos que forman
parte de los Requisitos para el Uso de META (Seccin 3.3).

3.11 (esumen

META es una metodologa hbrida para desarrollo de software que incluye algunas de las
prcticas de las metodologas RUP, XP y Scrum, por lo cual es un hbrido entre lo
tradicional y lo gil. META consta de cuatro fases: Planteamiento, Preparacin,
Construccin e Implantacin. META fue diseada para tomando las necesidades actuales
de las empresas de desarrollo en Mxico, pero puede ser utilizada en otros pases.

Mxico


Octubre 2012 56

! Pruebas " Resultados obtenidos

4.1 )ntroduccin

La medicin es un elemento clave en cualquier proceso de ingeniera, porque es a travs de
las medidas que se logra la evaluacin de la calidad de los productos de la ingeniera. La
evaluacin tiene como propsito determinar en qu medida se estn cumpliendo las
caractersticas de calidad que se fijan en los estndares o normas; de esta manera, por
medio de la evaluacin es posible obtener una retroalimentacin, detectando fortalezas y
debilidades.

En este sentido, la evaluacin es un instrumento para el mejoramiento que permite obtener
informacin vlida y confiable; de este modo, la evaluacin impulsa el mejoramiento ya
que genera compromisos con el logro de objetivos precisos.

Por tanto, tomando en cuenta lo anterior, resulta conveniente la evaluacin de META
(MEtodologa Tradicional y gil) para determinar en qu grado cumple con las
caractersticas de calidad incluidas en la Norma Mexicana NMX-I-055-NYCE [NYC06].

4.2 Evaluacin de +E&"

Para evaluar la calidad de META se hizo uso de la Norma Mexicana NMX-I-055-NYCE
(vase Seccin 2.3). Esta norma define un conjunto de caractersticas de calidad, las cuales
se pueden medir a travs de las mtricas definidas en ella.

En la NMX-I-055/01-NYCE, la cual corresponde al modelo de calidad, se especifica que
esta norma puede utilizarse para medir productos de software, as como para definir los
requisitos de calidad en otros usos, como en META.

META fue probado en una empresa dedicada a desarrollar software, el proyecto de campo
cumpli con las caractersticas para las cuales fue diseada esta metodologa; es decir, se
construy un software Web, en un tiempo de desarrollo de 4 meses y con 10 personas
integrando el equipo de desarrollo (sin contar usuarios/cliente).

Adems en la misma empresa se realizaron otros proyectos con caractersticas similares,
pero haciendo uso de las metodologas RUP (Rational Unified Process, Proceso Unificado
de Racional), Scrum y XP (eXtreme Programming, Programacin Extrema).

Es importante sealar, que en la empresa no se haba hecho uso anteriormente de ninguna
de las cuatro metodologas para desarrollo de software mencionadas, por lo que se debe de
considerar que el conocimiento de estas metodologas era nulo en todos los casos,
proporcionando equidad en este aspecto.

Mxico


Octubre 2012 57

META fue probado en un ambiente real para poder evaluar su calidad a travs de la norma
NMX-I-055-NYCE, pero tambin se probaron las metodologas con las cuales se realiz el
hbrido (RUP, XP y Scrum); para poder comparar su calidad con META a travs de la
misma norma. La evaluacin de las metodologas fue realizada por el lder de los cuatro
proyectos que se realizaron, porque l es el integrante de desarrollo que se sita en la parte
media del flujo de comunicacin entre el equipo de desarrollo y los usuarios/cliente.

Las metodologas se evaluaron considerando los siguientes puntos de vista:

Para la Calidad Interna: sin poner a prueba an las metodologas, se evalu la
documentacin de cada una de ellas.
Para la Calidad Externa: se consideraron cada una de las metodologas en cada fase
durante su etapa de pruebas.
Para la Calidad en Uso: se consider lo que el cliente/usuarios vieron reflejado en el
producto de software creado con cada una de las cuatro metodologas.

En el Apndice 4 se pueden ver las mtricas aplicadas para medir la calidad interna del
producto, en el Apndice 5 se encuentran las mtricas aplicadas para medir la calidad
externa y en el Apndice 6 las mtricas para la calidad en uso. Al lder del proyecto se le
proporcionaron slo las ltimas columnas de las tablas (Propsito de la Mtrica y
Resultados de la Evaluacin de la Metodologa que de manera especfica us cada lder);
adems se le dio a conocer la tabla de normalizacin de mtricas para la evaluacin (vase
Tabla 4.1).

Tabla 4.1. Tabla de Normalizacin de las Mtricas para la Evaluacin del Producto
[NYC06].
0 1 2 3 4 5

No
Aplica
(NA)

No
Sabe
(NS)
Nunca Pocas
veces
Algunas veces Casi
siempre
Siempre
Muy mal Mal Normal Bueno Muy bueno
Nada Alguno Normal Casi Mucho
No tiene Bsico Mediano Alto Muy alto
Ninguno Muy pocos Pocos Casi
todos
Todos
Muy baja Baja Media Alta Muy alta
No Poco Mediamente Casi todo Completamente
Inaceptable Debajo del
promedio
Promedio Buena Excelente
No est
definido
Poco
definido
Mediamente
definido
Casi todo
definido
Completamente
definido
No Promedio Si

META (MEtodologa Tradicional y gil), una metodologa hbrida para desarrollo de software Web propuesta para las
empresas de software en Mxico


Septiembre 2012 58

Con las tablas de los Apndices 4 y 5, se calcularon los promedios y porcentajes para cada subcaracterstica de los modelos de calidad
interna y externa, tal como se pueden apreciar en la Tabla 4.2 y 4.3 respectivamente (no se calcul la del modelo de Calidad en Uso
porque no tiene subcaractersticas, slo caractersticas).

Tabla 4.2. Tabla de Calidad Interna del Producto (Media aritmtica y porcentaje)

CARACTR!"T#CA "$BCARACTR!"T#CA Resultados de la valuaci%n de la
Metodologa
&Media Arit'(tica)
Resultados de la valuaci%n de la
Metodologa
&*orcenta+e)
MTA R$* ,* "cru' MTA R$* ,* "cru'
-uncionalidad Ada.tabilidad 4/0 3 4/0 4/0 123 423 123 123
5actitud 4/4 0 4 4/4 123 1223 623 123
#ntero.erabilidad 0 0 0 4 1223 1223 1223 623
"eguridad de Acceso 0 0 4 0 1223 1223 623 1223
Con7or'idad de -uncionalidad 4 0 4 4 623 1223 623 623
Con7iabilidad Madure8 0 4 0 0 1223 623 1223 1223
Tolerancia a -allas 4/4 4/3 4 4/4 123 643 623 123
Recu.eraci%n 4 3 0 4 623 423 1223 623
Con7or'idad de Con7iabilidad 4 4 4 4 623 623 623 623
$sabilidad -acilidad de Co'.rensi%n 4 2 0 3 623 423 1223 423
-acilidad .ara A.render 4 3/0 4 4 623 923 623 623
:.eratividad 4/6 3/2 4/6 4 143 443 143 623
Atracci%n 0 4 0 0 1223 623 1223 1223
7iciencia Co'.orta'iento del Tie'.o 0 3 4 4 1223 423 623 623
$tili8aci%n de los Recursos 4 4 4 2 623 623 623 423
Con7or'idad de 7iciencia 4 4 4 4 623 623 623 623
Mantenibilidad -acilidad de An;lisis 0 0 4 4 1223 1223 623 623
-acilidad .ara #ntroducir
Ca'bios
0 2/0 0 4/0 1223 023 1223 123
Con7or'idad de Mantenibilidad 4 3 0 4 623 423 1223 623
*ortabilidad -acilidad de #nstalaci%n 0 2 0 4 1223 423 1223 623



Septiembre 2012 59

Tabla 4.3. Tabla de Calidad Externa del Producto (Media aritmtica y porcentaje)

CARACTR!"T#CA "$BCARACTR!"T#CA Resultados de la valuaci%n de la
Metodologa
&Media Arit'(tica)
Metodologa
&*orcenta+e)
-uncionalidad Ada.tabilidad 0 4/0 0 4/0 1223 123 1223 123
5actitud 0 4 0 0 1223 623 1223 1223
#ntero.erabilidad 0 4 0 4 1223 623 1223 623
"eguridad de Acceso 0 0 3 4 1223 1223 423 623
Con7or'idad de
-uncionalidad
0 4 4 4 1223 623 623 623
Con7iabilidad Madure8 0 4/0 0 0 1223 123 1223 1223
Tolerancia a -allas 4/4 4/3 4/3 4/4 123 643 643 123
Recu.eraci%n 4 3 0 4 623 423 1223 623
Con7or'idad de
Con7iabilidad
0 4 0 4 1223 623 1223 623
$sabilidad -acilidad de Co'.rensi%n 0 3/0 0 4/0 1223 923 1223 123
-acilidad .ara A.render 4/0 3/0 4/0 4 123 923 123 623
:.eratividad 4/6 3/2 4/6 4/2 143 443 143 643
Atracci%n 0 4 0 0 1223 623 1223 1223
7iciencia Co'.orta'iento del Tie'.o 0 3 4 0 1223 423 623 1223
$tili8aci%n de los Recursos 0 4 0 0 1223 623 1223 1223
Con7or'idad de 7iciencia 0 4 0 0 1223 623 1223 1223
Mantenibilidad -acilidad de An;lisis 0 0 4 0 1223 1223 623 1223
Ca'bios
0 3 4/0 4/0 1223 423 123 123
Con7or'idad de
Mantenibilidad
0 4 0 0 1223 623 1223 1223
*ortabilidad -acilidad de #nstalaci%n 0 3 0 4 1223 423 1223 623



Septiembre 2012 60

Con los resultados de las subcaractersticas de las dos tablas anteriores, se calcul la media aritmtica y el porcentaje de cada
caracterstica de los modelos de calidad Interna y Externa, como se puede observar en la Tabla 4.4 y 4.5 respectivamente.

Tabla 4.4. Media Aritmtica y Porcentaje de las Caractersticas de la Calidad Interna del Producto

CARACTR!"T#CA Resultados de la valuaci%n de la
Metodologa
&Media Arit'(tica)
Metodologa
&*orcenta+e)
-uncionalidad 4/4 4/4 4/3 4/4 123 123 643 663
Con7iabilidad 4/4 3/6 4/0 4/4 663 943 123 663
$sabilidad 4/0 3/2 4/9 4 123 443 143 623
7iciencia 4/3 3/4 4 3/3 643 923 623 443
Mantenibilidad 4/4 3/0 4/4 4/2 123 923 123 643
*ortabilidad 0 2 0 4 1223 423 1223 623

Tabla 4.5. Media Aritmtica y Porcentaje de las Caractersticas de la Calidad Externa del Producto

Metodologa
&Media Arit'(tica)
Metodologa
&*orcenta+e)
-uncionalidad 0 4/3 4/4 4/3 1223 643 663 643
Con7iabilidad 4/9 4 4/6 4/4 143 623 143 663
$sabilidad 4/6 3/4 4/1 4/4 143 923 163 663
7iciencia 0 3/4 4/4 0 1223 923 123 1223
Mantenibilidad 0 4 4/0 4/6 1223 623 123 143
*ortabilidad 0 3 0 4 1223 423 1223 623

Mxico


Septiembre 2012 61

En la Tabla 4.6 se puede observar la media aritmtica y el porcentaje para cada
caracterstica de modelo de calidad en Uso, esta se obtuvo de los resultados de la tabla del
Apndice 6.

Tabla 4.6. Media Aritmtica y Porcentaje de las Caractersticas de la Calidad en Uso del
Producto
Metodologa
&Media Arit'(tica)
Metodologa
&*orcenta+e)
7ectividad 0 4 0 0 1223 623 1223 1223
*roductividad 0 0 0 0 1223 1223 1223 1223
"eguridad 0 4 0 0 1223 623 1223 1223
"atis7acci%n 0 4 0 0 1223 623 1223 1223

Promediando la informacin de las tres tablas anteriores, se calcul la calidad del producto,
tal como se puede observar en la Tabla 4.7.

Tabla 4.7. Calidad del Producto

Modelo de Calidad Resultados de la valuaci%n de la
Metodologa
&Media Arit'(tica)
Metodologa
&*orcenta+e)
#nterna 4/4 3/0 4/0 4 123 923 123 623
5terna 4/1 3/6 4/9 4/0 163 943 143 123
n $so 0 4/3 0 0 1223 643 1223 1223
T:TA< 4/6 3/1 4/9 4/0 143 963 143 123

Como se puede observar en la Tabla anterior, META obtuvo un 96% de Calidad Total, la
cual es superior a la obtenida por RUP (78%), XP (94%) y Scrum (90%).

La Calidad Interna evalu la documentacin y la capacitacin necesaria para hacer uso las
metodologas; META result con el mayor porcentaje (92%); en este sentido, META
obtuvo mejores resultados que RUP (70%) porque sta requiere de ms conocimientos
previos y de invertir ms tiempo en comprender cmo utilizarla y obtuvo mejores
resultados que XP (90%) y Scrum (80%) porque stas no proporcionan ayuda en algunas
fases, dejando incgnitas de cmo debe utilizarse adecuadamente.

La Calidad Externa evalu el funcionamiento en operacin de las metodologas; en este
modelo de calidad, META tambin obtuvo mayor calidad (98%), puesto que se presentaron
menos problemas durante el desarrollo de software que XP (94%), Scrum (90%) y RUP
(76%).

Mxico


Septiembre 2012 62

La Calidad en Uso evalu la satisfaccin del cliente/usuarios al recibir el software en
tiempo, bajo presupuesto y cumpliendo los requerimientos pactados inicialmente. En este
modelo de calidad las metodologas con mayor calidad fueron META (100%), XP (100%)
y Scrum (100%).

4.3 Opinin respecto a +E&"

META fue evaluado tambin de manera terica por dos personas dedicadas a desarrollar
software y con conocimientos en algunas metodologas, los comentarios se presentan a
continuacin:

Dr. Carlos Mondragn
Certificado en XP y Scrum

META es una propuesta interesante puesto que efectivamente retoma algunas de las
mejores cualidades de las metodologas que combina y contiene los elementos necesarios
para ponerse en prctica. Una de las cosas ms interesantes, es que META se limita a
proyectos Web, con lo cual se evitan errores de implementacin para desarrollar otro tipo
de sistemas, como sucede algunas veces con otras metodologas, que al querer aplicar para
todos los tipos de proyecto, en la prctica no funcionan.

Ing. Omar Johary Lpez
Certificado en RUP

La metodologa META es una propuesta que podra ayudar a muchas empresas mexicanas
que van iniciando su actividad en el campo de desarrollo de software, porque contiene
actividades que resultan sencillas de llevar a la prctica y considera muchas de las buenas
prcticas incluidas en metodologas como RUP, en donde se da mucho valor a documentar
y modelar mediante el uso de diagramas.

4.4 (esumen

META fue probada en una empresa de desarrollo de software, en un proyecto que cumpla
con las caractersticas para las cuales fue diseada, dando como resultado un producto de
software que cumpli con los requisitos planteados por el cliente, en tiempo y bajo el
presupuesto acordado.

META cumpli con porcentajes aceptables segn las caractersticas de la norma NMX-I-
055-NYCE y mostr porcentajes parecidos e incluso superiores a los obtenidos por otras
metodologas como RUP, Scrum y XP.

Mxico


Septiembre 2012 63

# $onclusiones " Traba%os &uturos

El objetivo general de este trabajo fue disear una metodologa que se adapte al contexto
actual de las empresas de desarrollo de software en Mxico, basada en la nueva tendencia
en el rea de Ingeniera de Software: metodologas hbridas; se puede considerar que se
cumpli con este objetivo, porque en funcin al estudio realizado con las empresas
mexicanas dedicadas a elaborar productos de software se obtuvo el contexto de desarrollo
para poder disear la metodologa: META (MEtodologa Tradicional y gil).

Como se observ en el Captulo 3, META es un hbrido que incluye algunas prcticas de
otras metodologas, como RUP (Rational Unified Process, Proceso Unificado de Racional),
Scrum y XP (eXtreme Programming, Programacin Extrema).

META es un hbrido entre lo tradicional y lo gil (porque RUP es una metodologa
tradicional, mientras que XP y Scrum son giles), de esta manera surge la pregunta:
META es un hbrido tambin entre lo esttico y dinmico?, la respuesta es afirmativa
porque las metodologas tradicionales presentan respuestas estticas a los cambios que se
presentan durante el desarrollo de software y las metodologas giles presentan respuestas
dinmicas ante los cambios, mostrando as, mayor flexibilidad durante el proceso de
desarrollo; de esta manera, META presenta mayor ventaja ante RUP, XP y Scrum, al
combinar dos caractersticas que le permiten ser flexible ante los cambios y a la vez
proporcionar pautas durante todo el proceso de desarrollo.

Las ventajas de META fueron probadas; recordando as, otro objetivo sealado en este
trabajo: probar la utilidad de la metodologa propuesta en algunas empresas dedicadas a
desarrollar software en Mxico, el cual tambin se cumpli aunque slo con una empresa,
razn por la cual se busc la evaluacin de manera terica con personas certificadas en las
metodologas RUP, Scrum y XP; tal como se observ en el Captulo anterior. Con esto se
cumpli tambin uno de los beneficios esperados: elaborar una Metodologa Hbrida para
desarrollar software que cumpla con las caractersticas de calidad de la Norma Mexicana
NMX-I-055-NYCE. META se prob en un proyecto real y se evalo a travs de esa
norma, obteniendo un resultado de calidad satisfactorio (96%), obteniendo el mejor
resultado al compararse con las metodologas de las cuales retoma algunas prcticas: RUP
(78%), XP (94%) y Scrum (90%).

De esta manera, se puede decir que META cumpli con las expectativas del trabajo de tesis
y que representa una opcin confiable para desarrollar software, puesto que cumple con las
caractersticas de calidad que permiten desarrollar software de calidad, esto motiva a
publicar como trabajo futuro a META como un estndar en NYCE porque cumple con las
caractersticas de calidad de la Norma Mexicana NMX-I-055-NYCE.

Sin embargo, dadas las limitaciones de tiempo para probar META en ms proyectos, como
trabajo futuro tambin se propone realizar ms proyectos de software con META para
poder elaborar un estudio estadstico que permita identificar an mejor las debilidades y

Mxico


Septiembre 2012 64

fortalezas de la metodologa; as como para tener un indicador del nmero de proyectos de
software en los cuales fue posible crear el producto en tiempo, bajo presupuesto y
cumpliendo con las expectativas del cliente.

Tambin se propone probar META en otros pases para poder determinar si funcionara en
empresas no mexicanas y de presentarse algn inconveniente, realizar las adecuaciones
necesarias para que META sea utilizada internacionalmente.

Finalmente, se propone identificar con base a las pruebas en ms proyectos, qu
funcionalidades deberan agregarse en la herramienta META-Software para proporcionar
ms ayuda en la gestin de META.

Mxico


Septiembre 2012 65

'ibliogra(a

[ALB79]
Albrecht, A.J., Measuring Application Development Productivity, en Proc.IBM Aplication
Development Symposium, Monterey, CA, Octubre de 1979.
[BER96]
Berners-Lee, Tim, The World Wide Web: Past, Present and Future, Prentice Hall, 1996.
[BOE81]
Bohem, B., Software Engineering Economics, Prentice Hall, 1981.
[BRA00]
Braude, Eric, Ingeniera de Software: Una perspectiva orientada a objetos, Alfaomega, 2000.
[COC84]
Cochran, William, Tcnicas de muestreo, C.E.C.S.A, 10984.
[COC04]
Cockburn, Alistar, Crystal Clear: a human-powered methodology for small teams, Addison-
Wesley Professional, 2004.
[HIG99]
Highsmith, James, Adaptative Software Development: A Collaborative Approach to Managing
Complex Systems, Dorset House, 1999.
[HIL02]
Hillier-Lieberman, Investigacin de Operaciones, McGraw Hill, 2002.
[IEE93]
IEEE, Standard Glossary of Software Engineering Terminology, IEEE, 1993.
[IEE90]
IEEE, Standard Glossary of Software Engineering Terminology, IEEE, 1990.
[ISO01]
ISO, ISO/IEC 9126-1, Quality Model, 2001.
[JIH12]
Jimnez-Hernndez. E. y Orantes-Jimnez S., MEMORIAS, Segunda Conferencia Iberoamericana
de Complejidad, Informtica y Ciberntica (CICIC 2012), TEMA: Metodologa Hbrida para
Desarrollo de Software en Mxico, ISBN-13: 978-1-936338-55-9, Orlando, Florida, EEUU, del
25 al 28 de marzo del 2011.
[JIM11]
Jimnez-Hernndez. E. y Orantes-Jimnez S., MEMORIAS, International Conference on
Information and Communication Technologies and Applications (ICTA 2011), TEMA: META: a
new hybrid methodology to software development created to suit of the current needs in Mexico,
ISBN-13: 978-1-936338-45-0, Orlando, Florida, EEUU, del 29 de noviembre al 2 de diciembre del
2011.
[NYC06]
NYCE, Norma Mexicana NMX-I-055-NYCE, Calidad del Producto, 2006.
[PRE05]
Pressman, Roger, Ingeniera de Software: Un enfoque prctico, McGraw Hill, 2000.
[RAE01]
Real Academia Espaola, Vigsima segunda edicin, 2001.
[ROS08]
Ross, Margy, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Kindle
Edition, 2008.
[RUM90]
Rumbaugh et al , Object-Oriented Modeling and Design, Prentice-Hall, 1990.
[SOM09]
Sommerville, Ian, Software Engineering, Prentice Hall, 2009.
[WAL99]
Walpole-Myers, Probabilidad y Estadstica para Ingenieros, Pearson Education, 1999.

[YOU76]
Yourdon, Eduard, Techniques of Program Structure and Design, Prentice Hall, 1976.

Mxico


Septiembre 2012 66

Re(erencias )R*

[BEC99]
Beck, Kent, Extreme programming (XP): a gentle introduction, consultado el 3 de octubre del
2011, disponible en Internet: www.extremeprogramming.org/, 1999.
[DEM90]
Deming, Edwards, The Deming System, consultado el 15 de septiembre del 2011, disponible en
Internet: deming.org/, 1990.
[IBM11]
IBM, Rational Unified Process (RUP), consultado el 18 de septiembre del 2011, disponible en
Internet: www-01.ibm.com/software/awdtools/rup/, 2011.
[INE11]
INEGI, Estadstica, consultado el 14 de febrero del 2011, disponible en Internet:
www.inegi.org.mx, 2011.
[JAC05]
Jacobson, Ivar, The Unified Process Lifecycle Practice, consultado el 20 de septiembre del 2011,
disponible en Internet: www.ivarjacobson.com/Unified_Process_Lifecycle.aspx, 2005.
[JAC10]
Jacobson, Ivar, The Essential Unified Process (EssUP), consultado el 5 de septiembre del 2011,
disponible en Internet: www.ivarjacobson.com , 2010.
[JIM12]
Jimnez Hernndez, Erndira Miriam y Orantes Jimnez, Sandra Dinora, Metodologas hbridas
para desarrollo de software: una opcin factible para Mxico, Revista Digital Universitaria [en
lnea]. 1 de enero de 2012, Vol. 13, No.1 [Consultada: 2 de enero de 2012]. Disponible en Internet:
http://www.revista.unam.mx/vol.13/num1/art16/index.html ISSN: 1607-6079.
[MPE11]
Ministerio de Presidencia de Espaa, Mtrica v3, consultado el 8 de octubre del 2011, disponible
en Internet: administracionelectronica.gob.es, 2011.
[OMG11]
Object Management Group, UML, consultado el 14 de septiembre del 2011, disponible en
Internet: www.uml.org, 2011.
[SCR86]
Scrum group, Scrum, consultado el 2 de octubre del 2011, disponible en Internet:
www.scrum.org/, 1986.

Mxico


Septiembre 2012 67

Apndice 1
CARACTERSTICAS DE LAS APLICACIONES WEB

Segn Pressman [PRE05], las Aplicaciones Web cumplen con las siguientes caractersticas:

Intensidad de Red. Por su propia naturaleza, una Aplicacin Web es intensiva de red.
Reside en una red y debe dar servicio a las necesidades de una comunidad diversa de
clientes. Una Aplicacin Web puede residir en Internet (posibilitando una comunicacin
abierta para todo el mundo). De forma alternativa, una aplicacin se puede ubicar en una
Intranet (implementando la comunicacin a travs de redes de una organizacin) o una
Extranet (comunicacin entre redes).

Controlada por el contenido. En muchos casos, la funcin primaria de una Aplicacin
Web es utilizar hipermedia para presentar al usuario el contenido de textos, grficos, sonido
y vdeo.

Evolucin continua. A diferencia del software de aplicaciones convencional, que
evoluciona con una serie de versiones planificadas y cronolgicamente espaciadas, las
Aplicaciones Web estn en constante evolucin. No es inusual que algunas Aplicaciones
Web (especficamente, su contenido) se actualicen cada hora.

Inmediatez. Las aplicaciones basadas en Web tienen una inmediatez que no se encuentra
en otros tipos de software.

Seguridad. Dado que las Aplicaciones Web estn disponibles a travs de1 acceso por red,
es difcil limitar la poblacin de usuarios finales que pueden acceder a la aplicacin. Con
objeto de proteger el contenido confidencial y de proporcionar formas seguras de
transmisin de datos, debern implementarse fuertes medidas de seguridad en toda la
infraestructura que apoya una Aplicacin Web y dentro de la misma aplicacin.

Esttica. Una parte innegable del atractivo de una Aplicacin Web es su apariencia e
interaccin. Cuando se ha diseado una aplicacin con el fin de comercializarse o vender
productos o ideas, la esttica puede tener mucho que ver con el xito del diseo tcnico.

Mxico


Septiembre 2012 68

Apndice 2
PLANTILLA GENERAL DEL CONTRATO

CONTRATO QUE CELEBRAN POR UNA PARTE
NOMBRE DE LA EMPRESA DESARROLLADORA DE
SOFTWARE A LA QUE EN LO SUCESIVO SE LE
DENOMINAR LA EMPRESA Y POR OTRA PARTE
EL CLIENTE NOMBRE DEL CLIENTE, EN
ADELANTE EL CLIENTE Y CONJUNTAMENTE CON
LA EMPRESA COMO LAS PARTES, AL TENOR DE
LAS SIGUIENTES:
DECLARACIONES
I. DECLARA LA EMPRESA:
a) Que e u!a e"#$ea %e %ea$$&''& %e
&()*a$e + &$,a!-.a%a /&!(&$"e a 'a
Le+e Me0-/a!a, /&! (a/u')a% #a$a
/e'e1$a$ e)e )-#& %e /&!)$a)&.
1) Que u $e#$ee!)a!)e /ue!)a /&!
(a/u')a%e u(-/-e!)e + !e/ea$-a #a$a
&1'-,a$'e e! '& )2$"-!& 3ue e
#$ee!)e e' /&!)$a)&, 'a /ua'e !& 'e
4a! -%& "&%-(-/a%a & '-"-)a%a e!
(&$"a a',u!a.
/) Que e)5 e! %-#&-/-6! %e &($e/e$ a EL
CLIENTE u! e$7-/-& 3ue /&!-)e e!
-!)e,$a$ 1a8& u! "-"& &()*a$e '&
$e3ue$-"-e!)& e#e/-(-/a%& e! 'a
CLAUSULAS CAPITULO II DE LOS
REQUERIMIENTOS.
II. DECLARA EL CLIENTE:
9. Que e)5 -!)e$ea%& e! 3ue LA
EMPRESA 'e #$e)e e' e$7-/-&: +
"a!-(-e)a /&!&/e$ + e)a$ %e a/ue$%&
/&! e' /&!)e!-%& %e e)e -!)$u"e!)&.
E0#ue)& '& a!)e$-&$, LAS PARTES #a/)a! '&
-,u-e!)e:
CLAUSULAS
CAPITULO I
DE LAS DEFINICIONES DEL SISTEMA
PRIMERA.; LA EMPRESA e /&"#$&"e)e a
%ea$$&''a$ e' &()*a$e #a$a EL CLIENTE. D-/4&
&()*a$e $e/-1-$5 e' !&"1$e %e NOMBRE DEL
SISTEMA: a' 3ue e! '& u/e-7& e %e!&"-!a$5
EL PROYECTO.
SEGUNDA.; LA EMPRESA e /&"#$&"e)e a %-e<a$
e -"#'e"e!)a$ e! EL PROYECTO, u!a a#'-/a/-6!
*e1.
TERCERA.; EL CLIENTE e a/e#)a 3ue '&
$e3ue$-"-e!)& %e' &()*a$e %e/$-)& e! 'a
CLAUSULAS CAPITULO II DE LOS REQUERIMIENTOS
/u"#'e! /&! '& 3ue EL CLIENTE %eea.
CLAUSULAS
CAPITULO II
DE LOS REQUERIMIENTOS
PRIMERA.; LA EMPRESA e /&"#$&"e)e a 3ue EL
PROYECTO /u"#'a /&! '& -,u-e!)e
$e3ue$-"-e!)&: e %e/-$, EL CLIENTE + LA EMPRESA
a/e#)a! e)a$ %e a/ue$%&. P&$ '& 3ue EL CLIENTE
a/e#)a 3ue e /u"#'-$5 6'& /&! '& -,u-e!)e:
9. Re3ue$-"-e!)& 9
=. Re3ue$-"-e!)& =.
>. Re3ue$-"-e!)& >.
?. Re3ue$-"-e!)& ?.
CLAUSULAS
CAPITULO III
DE LOS PRECIOS Y FORMAS DE PAGO
PRIMERA.; EL CLIENTE e /&"#$&"e)e /&! LA
EMPRESA a #a,a$ e! > e04-1-/-&!e e' "&!)& )&)a'
%e' #$&+e/)&. P&$ '& 3ue e! 'a (e/4a /&$$e#&!%-e!)e
a' 9$a FEC@A DE PAGO e %e1e$5 /u1$-$ e' =AB %e'
)&)a'. Pa$a e' =%a FEC@A DE PAGO e %e1e$5 /u1$-$
e' ?AB %e' )&)a', + (-!a'"e!)e #a$a e' >$a FEC@A DE
PAGO %e1e$5 /u1$-$ '& /&$$e#&!%-e!)e a' ?AB.
CLAUSULAS
CAPITULO IV
DE LA DURACION
PRIMERA.; E' #$ee!)e /&!)$a)& )e!%$5 u!a %u$a/-6!
4a)a e' %Ca FEC@A DE ENTREGA DEL SOFTWARE,
(e/4a e! 'a /ua' LA EMPRESA e!)$e,a$5 EL
PROYECTO a EL CLIENTE.

Mxico


Septiembre 2012 69

CLAUSULAS
CAPITULO V
DE LA COLABORACION Y SEGUIMIENTO DEL
PROYECTO
PRIMERA.; EL CLIENTE e /&"#$&"e)e a
/&'a1&$a$ /&! LA EMPRESA #a$a ''e7a$ a /a1& u!
)&)a' %e NUMERO DE REVISIONES $e7--&!e 3ue
e ''e7a$5! a /a1& e,D! LA EMPRESA )e!,a
a7a!/e e! EL PROYECTO.
SEGUNDA.; LA EMPRESA e /&"#$&"e)e a
/&'a1&$a$ /&! EL CLIENTE %e u!a (&$"a
$e#e)u&a + #$&(e-&!a'.
TERCERA.; Caua$5 $e/--6! e' /&!)$a)& e! /a&
%e' -!/u"#'-"-e!)& %e EL CLIENTE: !&
#$&#&$/-&!a$ -!(&$"a/-6! !e/ea$-a #a$a e'
%ea$$&''& %e EL PROYECTO: !& a-)-$ a 'a
$eu!-&!e %e $e7--6! %e a7a!/e e)-#u'a%a e!
e' /&!)$a)&.
CAPITULO VI
DE LAS FASES DE DESARROLLO DEL
SOFTWARE
PRIMERA.; EL CLIENTE e a/e#)a 3ue EL
PROYECTO 6'& %e1e /u"#'-$ /&! '& #a/)a%& e!
'a CLAUSULAS CAPITULO II DE LOS
REQUERIMIENTOS. P&$ '& 3ue a/e#)a 3ue LA
EMPRESA !& 4a$5 /&a a',u!a 3ue !& e)2
e#e/-(-/a%a e! e)e /&!)$a)&. AC 3ue a"1a
#a$)e, e %e/-$: LA EMPRESA + EL CLIENTE
a/e#)a! 3ue e %a #&$ )e$"-!a%& 'a (ae e
&1)e!/-6! %e $e3ue$-"-e!)&.
CLAUSULAS
CAPITULO VII
DE LA ENTREGA Y ACEPTACION
PRIMERA.; EL PROYECTO e$5 e!)$e,a%& e' >$a
FEC@A DE PAGO a EL CLIENTE e! u 'u,a$ %e
)$a1a8& %e EL CLIENTE, e' /ua' e e!/ue!)$a e!
LUGAR DONDE RESIDE EL CLIENTE.
SEGUNDA.; EL PROYECTO e$5 e!)$e,a%& e! 'a
(e/4a e<a'a%a, #&$ u! $e#$ee!)a!)e %e LA
EMPRESA. P&$ '& 3ue EL CLIENTE %e1e$5 (-$"a$
u! %&/u"e!)& e! e' 3ue %e (e 3ue e' #$&%u/)&
(ue $e/-1-%& + 3ue a)-(a/e /&! '& 3ue EL
CLIENTE #-%e e! e)e /&!)$a)&.

TERCERA.; LA EMPRESA e /&"#$&"e)e a
e!)$e,a$'e a EL CLIENTE u! CD /&! EL PROYECTO,
a%e"5 EL CLIENTE $e/-1-$5 u! "a!ua' %e uua$-&.
CUARTA.; EL CLIENTE e /&"#$&"e)e a e!)$e,a$ e!
'a "-"a (e/4a 3ue e a/&$%6 e! 'a PRIMERA
/'5uu'a %e e)e CAPITULO VII e' #a,& 3ue
/&$$e#&!%e a 'a )e$/e$a e04-1-/-6! "e!/-&!a%a e!
e' CAPITULO III DE LOS PRECIOS Y FORMAS DE
PAGO.
CLAUSULAS
CAPITULO VIII
DE LA GARANTIA
PRIMERA.; LA EMPRESA e /&"#$&"e)e 3ue EL
PROYECTO e$5 %ea$$&''a%& %e (&$"a 3ue ,a$a!)-/e
'a a)-(a//-6! %e EL CLIENTE /u"#'-e!%& /&! '&
$e3ue$-"-e!)& #a/)a%& #&$ a"1a #a$)e e! 'a
CLAUSULAS CAPITULO II DE LOS REQUERIMIENTOS
+ e! 'a CLAUSULAS CAPITULO I DE LAS
DEFINICIONES DEL SISTEMA.

CLAUSULAS
CAPITULO IX
DE LA PROPIEDAD INTELECTUAL
PRIMERA.; LA EMPRESA %e/'a$a 3ue EL CLIENTE
#&ee$5 (a/u')a%e #a$a %-#&!e$ %e 'a (&$"a 3ue
%eee %e EL PROYECTO, #&$ '& /ua' LA EMPRESA !&
e 4a$5 $e#&!a1'e %e' u& & "a!e8& 3ue #ue%a
%a$ EL CLIENTE a EL PROYECTO.
SEGUNDA.; LA EMPRESA %e/'a$a 3ue EL CLIENTE
e$5 e' %ue<& %e 'a #$&#-e%a% -!)e'e/)ua' %e EL
PROYECTO.
Se u/$-1e e! LUGAR Y FEC@A
EL CLIENTE
EEEEEEEEEEEEEEEEEEEEEEEEEE
NOMBRE Y FIRMA

LA EMPRESA
EEEEEEEEEEEEEEEEEEEEEEEEEE
NOMBRE Y FIRMA

Mxico


Septiembre 2012 70

Apndice 3
FLDER DEL PROYECTO

No. Proyecto

Versin:____ Fecha: ____

TTULO DEL
PROYECTO

Resumen
______________________________
______________________________
______________________________

Mxico


Septiembre 2012 71

DESCRIPCIN

Tipo de Proyecto:__________________________

Cliente:____________________________

Equipo de Desarrollo

Lder de Proyecto:_________________
Administrador de Proyecto:__________
Programadores:___________________
___________________
Probador:________________________
Documentador:_________________

Metodologa de Desarrollo: META

Mxico


Septiembre 2012 72

REQUERIMIENTOS

1. Requerimiento 1
2. Requerimiento 2
3. Requerimiento 3
.
.
Requerimiento n

Diagrama de
caso de uso

Sistema

Mxico


Septiembre 2012 73

ESTIMACIN DE COSTOS

Realizada por:_____________________

Mtodo de estimacin:______________

Fecha de estimacin:_______________

Costo total monetario $_____________

Tiempo de Desarrollo:______________

Mxico


Septiembre 2012 74

GESTIN DE RIESGOS Y
PROBLEMAS

Objetivo Fase Resultado
Esperado
Proceso
Necesario
Comprobacin Observaciones

Mxico


Septiembre 2012 75

OBSERVACIONES

_________________________
_________________________
_________________________
_________________________
_________________________



Septiembre 2012 76

Apndice 4
CALIDAD INTERNA DEL PRODUCTO

CARACTR!"T#CA "$BCARACTR!"T#CA M=TR#CA *R:*>"#T: D <A M=TR#CA Resultados de la valuaci%n de la
Metodologa
MTA R$* ,* "cru'
-uncionalidad Ada.tabilidad Adecuaci%n
7uncional
?Cu;n adecuadas son las 7unciones
revisadas@
4 2 0 4
Alcance de la
i'.le'entaci%n
7uncional
?Cu;n correcta es la i'.le'entaci%n
7uncional@
0 4 4 0
5actitud 5.ectativa a la
e5actitud
?AaB di7erencias ace.tables entre los
resultados actuales B los ra8onables
es.erados@
0 0 4 0
5actitud en el
c;lculo
?Cu;n a 'enudo los usuarios Callan
resultados e5actos@
4 0 3 4
*recisi%n ?Cu;n a 'enudo los usuarios Callan
resultados con .recisi%n adecuada@
0 0 0 0
#ntero.erabilidad -acilidad en el
interca'bio de
datos
?Cu;n correcto se reali8a el
interca'bio .ara trans7erir datos
es.ec7icos Due se i'.le'entan@
0 0 0 4
"eguridad de Acceso Acceso auditable ?Cu;n co'.leto es el rastro auditable
con res.ecto a los datos@
0 0 4 0
Con7or'idad de
-uncionalidad
Con7or'idad de
7uncionalidad
?Cu;n cu'.lida es la 7uncionalidad del
.roducto a las regulaciones, nor'as B
convenios a.licables@
4 0 4 4
Con7iabilidad Madure8 li'inaci%n de
7allas
?Cu;n a 'enudo es .osible corregir
las 7allas@
0 3 0 0
Madure8 de la
.rueba
?"e .rueba correcta'ente el
.roducto@
0 0 0 0
Tolerancia a -allas *revenci%n de ?Cu;n a 'enudo es .osible .revenir 0 4 4 0



Septiembre 2012 77

interru.ciones Due el .roducto origine una interru.ci%n
total del a'biente de .roducci%n@
*revenci%n de
7allas
?Cu;n a 'enudo es .osible controlar
los .atrones de 7allas .ara evitar 7allas
serias B criticas@
0 4 4 0
*revenci%n de
o.eraci%n
incorrecta
?Cu;n a 'enudo es .osible
i'.le'entar 7unciones con la
ca.acidad de evitar o.eraciones
incorrectas@
4 0 4 4
Recu.eraci%n -acilidad de
restableci'iento
?Cu;n ca.a8 es el .roducto .ara
restablecerse a s 'is'o des.u(s de
un evento anor'al@
4 3 0 4
7ectividad de
restauraci%n
?Cu;n e7ectiva es la ca.acidad de
restauraci%n@
4 3 0 4
Con7or'idad de
Con7iabilidad
Con7or'idad de
con7iabilidad
?Cu;n con7or'e es la con7iabilidad del
.roducto a regulaciones a.licables,
nor'as B convenios@
4 4 4 4
$sabilidad -acilidad de
Co'.rensi%n
#ntegridad de la
descri.ci%n
co'.render las 7unciones des.u(s de
leer la descri.ci%n del .roducto@
4 2 0 3
Actividades
co'.rensibles
?<os usuarios co'.renden Du( se
reDuiere .or el .roducto co'o entrada
B Du( .ro.orciona este co'o salida@
4 2 0 3
-acilidad .ara A.render -;cil de a.render
a dese'.eEar
una tarea en uso
?Cu;n a 'enudo el usuario des.u(s
de a.render c%'o dese'.eEar una
tarea es.ec7ica .uede .onerla en
.r;ctica e7iciente'ente@
4 3 4 4
7ectividad de la
docu'entaci%n
del usuario BFo
aBuda del
.roducto
?Cu;n a 'enudo las tareas .ueden
co'.letarse correcta'ente des.u(s de
usar docu'entaci%n BFo aBuda del
.roducto@
4 4 4 4



Septiembre 2012 78

:.eratividad Consistencia
o.eracional en
uso
?Cu;n consistentes son los
co'.onentes del .roducto@
4 0 4 4
Correcci%n del
error en uso
?Cu;n a 'enudo el usuario .uede
7;cil'ente recu.erarse de un error o
reintentar tareas@
0 3 0 4
Recu.eraci%n en
uso de un error
o.eracional
?Cu;n a 'enudo el usuario .ude
recu.erarse 7;cil'ente de una 'ala
situaci%n@
0 4 0 4
-acilidad de
ada.taci%n
7;cil'ente ada.tar los .rocedi'ientos
de o.eraci%n .ara su conveniencia@
0 2 0 4
Reducci%n del
.rocedi'iento de
o.eraci%n
?Cu;n a 'enudo el usuario 7;cil'ente
.uede reducir los .rocedi'ientos de
o.eraci%n a su conveniencia@
0 2 0 4
Atracci%n #nteracci%n
atractiva
?Cu;n atractiva es la .resentaci%n del
.roducto .ara el usuario@
0 4 0 0
7iciencia Co'.orta'iento del
Tie'.o
Rendi'iento ?Cu;n a 'enudo se .ueden
dese'.eEar las tareas
satis7actoria'ente sobre un .eriodo de
tie'.o dado@
0 3 4 4
$tili8aci%n de los
Recursos
$tili8aci%n de los
recursos
'ateriales
?Cu;n a 'enudo se .uede Cacer uso
de los recursos 'ateriales sin .rovocar
ine7iciencias@
4 4 4 2
Con7or'idad de
7iciencia
Con7or'idad de
e7iciencia
?Cu;n con7or'e es la e7iciencia del
nor'as B convenios@
4 4 4 4
Mantenibilidad -acilidad de An;lisis Ca.acidad de
segui'iento de
auditora
identi7icar la o.eraci%n es.eci7ica Due
origina la 7alla@
0 0 4 4
Ca'bios
7iciencia del ciclo
de ca'bio
?Cu;n a 'enudo se .uede resolver
7;cil'ente el .roble'a del usuario a su
0 3 0 4



Septiembre 2012 79

satis7acci%n dentro de una escala
ace.table de tie'.o@
Co'.le+idad de
'odi7icaci%n
?l res.onsable del uso del .roducto
.uede reali8ar 7;cil'ente las
adecuaciones necesarias o solucionar
un .roble'a@
0 2 0 0
Con7or'idad de
Mantenibilidad
Con7or'idad de
'antenibilidad
?Cu;n con7or'e es la 'antenibilidad
del .roducto a regulaciones a.licables,
nor'as B convenios@
4 3 0 4
*ortabilidad -acilidad de #nstalaci%n -;cil de instalar ?l res.onsable del uso del .roducto
.uede 7;cil'ente instalarlo al a'biente
de o.eraci%n@
0 2 0 4



Septiembre 2012 80

Apndice 5
CALIDAD EXTERNA DEL PRODUCTO

CARACTR!"T#CA "$BCARACTR!"T#CA M=TR#CA *R:*>"#T: D <A M=TR#CA Resultados de la valuaci%n de la
Metodologa
MTA R$* ,* "cru'
-uncionalidad Ada.tabilidad Adecuaci%n
7uncional
?Cu;n adecuadas son las 7unciones
evaluadas@
0 0 0 0
Alcance de la
i'.le'entaci%n
7uncional
?Cu;n correcta es la i'.le'entaci%n
7uncional@
0 4 0 4
5actitud 5.ectativa a la
e5actitud
?AaB di7erencias ace.tables entre los
resultados actuales B los ra8onables
es.erados@
0 4 0 0
5actitud en el
c;lculo
?Cu;n a 'enudo los usuarios Callan
resultados e5actos@
0 4 0 0
*recisi%n ?Cu;n a 'enudo los usuarios Callan
resultados con .recisi%n adecuada@
0 4 0 0
#ntero.erabilidad -acilidad en el
interca'bio de
datos
?Cu;n correcto se reali8a el
interca'bio .ara trans7erir datos
es.ec7icos Due se i'.le'entan@
0 4 0 4
"eguridad de Acceso Acceso auditable ?Cu;n co'.leto es el rastro auditable
con res.ecto a los datos@
0 0 3 4
Con7or'idad de
-uncionalidad
Con7or'idad de
7uncionalidad
?Cu;n cu'.lida es la 7uncionalidad del
.roducto a las regulaciones, nor'as B
convenios a.licables@
0 4 4 4
Con7iabilidad Madure8 li'inaci%n de
7allas
?Cu;n a 'enudo es .osible corregir
las 7allas@
0 4 0 0
Madure8 de la
.rueba
?"e .rueba correcta'ente el
.roducto@
0 0 0 0
Tolerancia a -allas *revenci%n de ?Cu;n a 'enudo es .osible .revenir 0 4 0 0



Septiembre 2012 81

interru.ciones Due el .roducto origine una interru.ci%n
total del a'biente de .roducci%n@
*revenci%n de
7allas
?Cu;n a 'enudo es .osible controlar
los .atrones de 7allas .ara evitar 7allas
serias B criticas@
0 4 4 0
*revenci%n de
o.eraci%n
incorrecta
i'.le'entar 7unciones con la
ca.acidad de evitar o.eraciones
incorrectas@
4 0 4 4
Recu.eraci%n -acilidad de
restableci'iento
?Cu;n ca.a8 es el .roducto .ara
restablecerse a s 'is'o des.u(s de
un evento anor'al@
4 3 0 4
7ectividad de
restauraci%n
?Cu;n e7ectiva es la ca.acidad de
restauraci%n@
4 3 0 4
Con7or'idad de
Con7iabilidad
Con7or'idad de
con7iabilidad
?Cu;n con7or'e es la con7iabilidad del
nor'as B convenios@
0 4 0 4
$sabilidad -acilidad de
Co'.rensi%n
#ntegridad de la
descri.ci%n
co'.render las 7unciones des.u(s de
leer la descri.ci%n del .roducto@
0 3 0 4
Actividades
co'.rensibles
?<os usuarios co'.renden Du( se
reDuiere .or el .roducto co'o entrada
B Du( .ro.orciona este co'o salida@
0 4 0 0
-acilidad .ara A.render -;cil de a.render
a dese'.eEar
una tarea en uso
?Cu;n a 'enudo el usuario des.u(s
de a.render c%'o dese'.eEar una
tarea es.ec7ica .uede .onerla en
.r;ctica e7iciente'ente@
0 3 0 4
7ectividad de la
docu'entaci%n
del usuario BFo
aBuda del
.roducto
?Cu;n a 'enudo las tareas .ueden
co'.letarse correcta'ente des.u(s de
usar docu'entaci%n BFo aBuda del
.roducto@
4 4 4 4



Septiembre 2012 82

:.eratividad Consistencia
o.eracional en
uso
?Cu;n consistentes son los
co'.onentes del .roducto@
4 4 4 4
Correcci%n del
error en uso
7;cil'ente recu.erarse de un error o
reintentar tareas@
0 3 0 4
Recu.eraci%n en
uso de un error
o.eracional
?Cu;n a 'enudo el usuario .ude
recu.erarse 7;cil'ente de una 'ala
situaci%n@
0 3 0 4
-acilidad de
ada.taci%n
7;cil'ente ada.tar los .rocedi'ientos
de o.eraci%n .ara su conveniencia@
0 3 0 4
Reducci%n del
.rocedi'iento de
o.eraci%n
?Cu;n a 'enudo el usuario 7;cil'ente
.uede reducir los .rocedi'ientos de
o.eraci%n a su conveniencia@
0 3 0 0
Atracci%n #nteracci%n
atractiva
?Cu;n atractiva es la .resentaci%n del
.roducto .ara el usuario@
0 4 0 0
7iciencia Co'.orta'iento del
Tie'.o
Rendi'iento ?Cu;n a 'enudo se .ueden
dese'.eEar las tareas
satis7actoria'ente sobre un .eriodo de
tie'.o dado@
0 3 4 0
$tili8aci%n de los
Recursos
$tili8aci%n de los
recursos
'ateriales
?Cu;n a 'enudo se .uede Cacer uso
de los recursos 'ateriales sin .rovocar
ine7iciencias@
0 4 0 0
Con7or'idad de
7iciencia
Con7or'idad de
e7iciencia
?Cu;n con7or'e es la e7iciencia del
nor'as B convenios@
0 4 0 0
Mantenibilidad -acilidad de An;lisis Ca.acidad de
segui'iento de
auditora
identi7icar la o.eraci%n es.eci7ica Due
origina la 7alla@
0 0 4 0
Ca'bios
7iciencia del ciclo
de ca'bio
?Cu;n a 'enudo se .uede resolver
7;cil'ente el .roble'a del usuario a su
0 4 4 0



Septiembre 2012 83

satis7acci%n dentro de una escala
ace.table de tie'.o@
Co'.le+idad de
'odi7icaci%n
?l res.onsable del uso del .roducto
.uede reali8ar 7;cil'ente las
adecuaciones necesarias o solucionar
un .roble'a@
0 2 0 4
Con7or'idad de
Mantenibilidad
Con7or'idad de
'antenibilidad
?Cu;n con7or'e es la 'antenibilidad
del .roducto a regulaciones a.licables,
nor'as B convenios@
0 4 0 0
*ortabilidad -acilidad de #nstalaci%n -;cil de instalar ?l res.onsable del uso del .roducto
.uede 7;cil'ente instalarlo al a'biente
de o.eraci%n@
0 3 0 4



Septiembre 2012 84

Apndice 6
CALIDAD EN USO DEL PRODUCTO

CARACTR!"T#CA M=TR#CA *R:*>"#T: D <A M=TR#CA Resultados de la valuaci%n de la
Metodologa
MTA R$* ,* "cru'
7ectividad 7ectividad de la
tarea
?Gu( .orcenta+e de ob+etivos B tareas
se logran correcta'ente@
0 4 0 0
Conclusi%n de la
tarea
?Gu( .orcenta+e de las tareas se
co'.leta@
0 4 0 0
*roductividad 7iciencia de la
tarea
?Cu;n e7icientes son los usuarios@ 0 0 0 0
"eguridad "eguridad de las
.ersonas
a7ectadas .or el
uso del .roducto
?Cu;n correcto es el .roducto .ara no
.rovocar a7ectaciones en las .ersonas
.or su uso@
0 4 0 0
DaEo econ%'ico ?Cu;n correcto es el .roducto .ara no
.rovocar a7ectaciones econ%'icas .or
su uso@
0 4 0 0
"atis7acci%n scala de
satis7acci%n
?Cu;n satis7ecCo est; el usuario@ 0 4 0 0

Anexos

Anexo 1
Metodologas Hbridas para desarrollo de software:
una opcin factible para Mxico (Revista Digital
Universitaria)

Anexo 2
META: a new hybrid methodology to software
development created to suit the current needs in
Mexico (ICTA 2011)

Anexo 3
Metodologa Hbrida para desarrollo de software en
Mxico (CICIC 2012)

1 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

1 PDF

Cargado por

Copyright:

Formatos disponibles

Instituto Politcnico Nacional

Centro de Investigacin en Computacin

También podría gustarte