You are on page 1of 31

UNIVERSIDAD JOS CARLOS MARITEGUI

FACULTAD DE INGENIERA Y ARQUITECTURA


ESCUELA PROFESIONAL DE INGENIERA DE SISTEMAS E INFORMTICA

PRESENTADO POR:
Johann Chambilla Flores
Christian Ortega Bernedo
Rocio Maritza

CURSO:
GESTIN DE CALIDAD DE SOFTWARE

DOCENTE:
Ing. Luis Palomino Chura

MOQUEGUA - PER
Mayo del 2017
NDICE
Introduccin..... 4

1. Captulo I: MODELOS DE GESTION CALIDAD ISO 9000 y CMMI. 5

1.1 Qu son las normas ISO 9000? .... 6

1.1.1 Antecedentes.... 6

1.1.2 Objetivos... 7

1.1.3 Familia ISO 9000... 8

1.2 Qu es CMMI? ........ 10

1.2.1 Niveles de Madurez........ 10

1.2.2 Por qu evaluar CMMI? ...... 11

1.2.3 Beneficios de CMMI...... 12

2. Capitulo II: CALIDAD EN EL CICLO DE VIDA. 13

2.1 Qu es el ciclo de vida de un Software?.......................................................... 14

2.1.1 Procedimientos.. 14

2.2 Modelos de Ciclo de Vida de Software..15

2.2.1 Modelo en Cascada. 15

2.2.2 Modelo en V. 16

2.3 Aseguramiento de Calidad de Software.. 17

2.4 Crisis de la Calidad de Software 18

3. Captulo III: DESARROLLO EVOLUTIVO DE LOS METODOS AGILES Y HIBRIDOS..19

3.1 Mtodos Agiles. 20

3.1.1 Antecedentes..20

3.1.2 Manifiesto gil.. 20

3.1.2.1 Principios Metodolgicos 21

3.1.2.2 Principios Bsicos de las Metodologas. 22

3.1.3 Comparacin entre Metodologas Agiles y Tradicionales. 24

3.1.4 Algunas tcnicas Agiles.. 24

3.1.4.1 Extreme Programming. 24

3.1.4.2 SCRUM26

3.1.4.3 Dynamic Systems Development Method (DSDM) ..26

3.1.4.4 Adaptive Software Development8 (ASD) 26

2
3.1.4.5 Proceso Unificado gil 26

3.1.4.6 Modelado gil 27

3.2 Qu son Mtodos Hbridos? 27

3.2.1 Metodologa Propuesta 28

3.2.2 Caractersticas. 28

3.2.3 Roles28

3.2.4 Principios Metodolgicos.28

3.2.5 Proceso de Desarrollo.29

3.2.6 Algunas Tcnicas Hibridas 29

3.2.6.1 ESSUP. 29

CONCLUSIONES. 30

3
INTRODUCCIN

La calidad del software es una preocupacin a la que se dedican muchos esfuerzos. Sin embargo,

el software casi nunca es perfecto. Todo proyecto tiene como objetivo producir software de la

mejor calidad posible, que cumpla, y si puede supere las expectativas de los usuarios.

El ciclo de vida del software describe el desarrollo de software, desde la fase inicial hasta la fase

final. El propsito de este programa es definir las distintas fases intermedias que se requieren

para validar el desarrollo de la aplicacin, es decir, para garantizar que el software cumpla los

requisitos para la aplicacin y verificacin de los procedimientos de desarrollo: se asegura de

que los mtodos utilizados son apropiados.

Las normas nacen para que las empresas se rijan por unos principios de organizacin y para que

den estabilidad en el mercado y en la sociedad.

Cuando se crea un producto o servicio se hace para satisfacer las necesidades y demandas de

unos clientes. Para tener buenos rendimientos econmicos y asegurar el futuro, la empresa

tiene que organizarse de tal forma que d garantas a los usuarios, compradores, trabajadores,

directivos y accionistas.

El equilibrio social est en juego, resulta inaceptable encontrar hoy empresas con mandos

rgidos y ancladas en el pasado, sin la capacidad de adaptarse a los cambios y que no se enfocan

en su cliente, por eso es importante, para una firma que desee alcanzar altos niveles de

competitividad, el uso y aplicacin de estndares de calidad internacionales que le permitan

ampliar sus mercados, mejorar su posicionamiento y crear valor.

4
CAPTULO I
MODELOS DE GESTIN DE
CALIDAD ISO 9000
y CMMI

5
Qu son las normas ISO 9000?

La serie ISO 9000 es un conjunto de normas orientadas a ordenar la gestin de la empresa

que han ganado reconocimiento y aceptacin internacional debido al mayor poder que

tienen los consumidores y a la alta competencia internacional acentuada por los procesos

integracionistas. Algunas de estas normas especifican requisitos para sistemas de calidad

(ISO 9001, 9002, 9003) y otras dan una gua para ayudar en la interpretacin e

implementacin del sistema de calidad (ISO 9000-2, ISO 9004-1)

1.1.1 Antecedentes

La normalizacin internacional se realiza con base en un amplio criterio, no slo se

refiere a lo legislacin comunitaria en molea de productos o servicios, sino

pretendiendo ser un mtodo para asegurar la economa, ahorrar gastos, evitar el

desempleo y garantizar el funcionamiento rentable de las empresas. Las

organizaciones deben tener un sistema de calidad ms eficiente cada da, que integre

todas las actividades que pudieran afectar la satisfaccin de las necesidades explcitas y

tcitas de sus clientes.

Es por esta razn que surgi la necesidad de normalizar la forma de asegurar la calidad.

El Organismo Internacional de Normalizacin, ISO, (Internatlonal Organization for

Standardization), fue creado en 1947 y cuenta con 91 estados miembros, que son

representados por sus organismos nacionales de normalizacin

La ISO trabaja para lograr uno forma comn de conseguir el establecimiento del sistema

de calidad, que garantice la satisfaccin de las necesidades y

expectativas de los consumidores.

A comienzos de! ao 1980 la ISO design una serie de comits tcnicos para

que trabajaran en el desarrollo de normas comunes que fuesen aceptadas

universalmente. El resultado de este trabajo fue publicado siete aos ms tarde a travs

del compendio de normas ISO 9000, posterior a la publicacin de la norma de

6
aseguramiento de la calidad-vocabulario (ISO 8402), que fue dada a conocer en 1986.

El diario oficial de las comunidades europeas, el 28 de Enero de 1991, public una

comunicacin que fue tambin nombrada el Libro Verde de la normalizacin. Este

importante documento no slo fue un marco de referencia para Europa, sino tambin

para las comunidades que negocian con ellos, como el caso de Mercosur, con esto se

exige o sus proveedores que sean auditados y certificados bajo los lineamientos de la

ISO 9000

La frecuencia que ISO estableci para la revisin y actualizacin de lo serie ISO

9000 fue de cinco aos

1.1.2 Objetivos

Proporcionar elementos para que una organizacin pueda lograr la calidad del

producto o servicio, a la vez que mantenerla en el tiempo, de manera que las

necesidades del cliente sean satisfechas permanentemente, permitindole a la

empresa reducir costos de calidad, aumentar la productividad, y destacarse o

sobresalir frente a la competencia.

Proporcionar a los clientes o usuarios la seguridad de que el producto o los servicios

tienen la calidad deseada, concertada, pactada o contratada.

Proporcionar a la direccin de la empresa la seguridad de que se obtiene la calidad

deseada.

Establecer las directrices, mediante las cuales la organizacin, puede seleccionar y

utilizar las normas.

7
1.1.3 Familia ISO 9000

NORMA AO CONTENIDO

8402 1986 Gestin y aseguramiento de la calidad

9000 1987

9000-1 1987 Norma para la gestin y aseguramiento de la calidad - Parte 1

9000-2 1993 Norma para la gestin y aseguramiento de la calidad - Parte 2

9000-3 1991 Norma para la gestin y aseguramiento de la calidad - Parte 3

9000-4 1993 Norma para la gestin y aseguramiento de la calidad - Parte 4

9001 1987 Sistema de calidad

9002 1987 Sistema de calidad

9003 1987 Sistema de calidad

9004-1 1987 Gestin de la calidad y elementos del sistema de calidad - Parte 1

9004-2 1991 Gestin de la calidad y elementos del sistema de calidad - Parte 2

9004-3 1993 Gestin de la calidad y elementos del sistema de calidad - Parte 3

9004-4 1993 Gestin de la calidad y elementos del sistema de calidad - Parte 4

9004-5 PC Gestin de la calidad y elementos del sistema de calidad - Parte 5

9004-6 PT Gestin de la calidad y elementos del sistema de calidad - Parte 6

9004-7 PNI Gestin de la calidad y elementos del sistema de calidad - Parte 7

9004-8 NP Gestin de la calidad y elementos del sistema de calidad - Parte 8

PC = Proyecto de comit ; PT = Proyecto de trabajo

10011-1 1990 Lineamientos para auditar sistemas de calidad- Parte 1

10011-2 1991 Lineamientos para auditar sistemas de calidad- Parte 2

10011-3 1991 Lineamientos para auditar sistemas de calidad- Parte 3

10012-1 PT Requerimiento de aseguramiento para equipos de medicin

10013 PNI Lineamientos para la elaboracin de manuales de calidad

10014 PT Aspectos econmicos de la calidad

10015 NP Educacin continua y lineamientos para la capacitacin

8
La norma ISO 9000 contiene las directrices para seleccionar y utilizar las

normas para el aseguramiento de la calidad, es decir, es la que permite

seleccionar un modelo de aseguramiento de calidad, entre las que se describen

las ISO 9001/9002/9003.

La norma ISO 9004. establece directrices relativas a los factores tcnicos,

administrativos y humanos que afectan a la calidad del producto, es decir,

establece directrices para la gestin de la calidad.

La norma ISO 9004-2 establece directrices relativas a los factores tcnicos,

administrativos y humanos que afectan a la calidad de los servicios, es decir, se

refiere especialmente a los servicio.

Las normas ISO 9001/9002/9003 establecen requisitos de determinan que

elementos tienen que comprender los sistemas de calidad, pero no es el propsito

imponer uniformidad en los sistemas de calidad. 5on genricas e independientes de

cualquier industria o sector econmico concreto.

Las tres normas tienen igual introduccin y antecedentes, pero en lo referido a

los requisitos del sistema encontramos diferencias. La primera diferencia es

relativa al nmero de temas (ver tabla 1), y la segunda es 'relativa a la exigencia. La ms

completa es la 9001. mientras que la 9003 es la ms escueta y sencilla.

Otra diferencia la encontramos en el objeto y campo de aplicacin que detallamos a

continuacin:

ISO-9001: especifica los requisitos que debe cumplir un sistema de calidad,

aplicables cuando un contrato entre dos partes exige que se demuestre la

capacidad de un proveedor en el diseo, desarrollo, produccin, instalacin y

servicio posventa del producto suministrado, con la finalidad de satisfacer al cliente.

9
ISO-9OO2: especifica los requisitos que debe cumplir un sistema de calidad,

aplicables cuando un contrata entre dos partes exige que se demuestre la

capacidad de un proveedor en la produccin, Instalacin y servicie' posventa del

producto suministrado, con la finalidad de satisfacer al cliente.

ISO-9003: especifica los requisitos que debe cumplir un sistema de calidad,

aplicables cuando un contrato entre dos partes exige que se demuestre la

capacidad de un proveedor en la inspeccin, y ensayos finales del producto

suministrado, con la finalidad de satisfacer al cliente.

1.2 Qu es CMMI?

CMMI (Modelo de Madurez de Capacidad Integrado) pertenece a la familia de modelos

desarrollados por el SEI (Software Engineering Institute) para evaluar las capacidades de las

organizaciones de ingeniera de sistemas, ingeniera de software, adems del desarrollo

integrado del producto y del proceso.

1.2.1 Niveles de Madurez

Un Nivel de Madurez es una plataforma evolutiva bien definida destinada a lograr un

proceso de software maduro. Cada nivel de madurez proporciona una capa en los

cimientos para un proceso de mejora continua.

El modelo CMM define 5 niveles de madurez:

1. Inicial. Es el primer nivel es decir que no es necesario hacer ningn esfuerzo para

llegar aqu, las organizaciones en este nivel no disponen de un ambiente adecuado

para el desarrollo de software. Aunque se utilicen tcnicas correctas de ingeniera,

los esfuerzos se ven minados por falta de planificacin. Los procesos varan segn

los individuos, el xito de los proyectos se basa la mayora de las veces en el esfuerzo

personal, aunque a menudo se producen fracasos y casi siempre retrasos y sobre

costos. El resultado de los proyectos es impredecible y esta pobremente controlado.

10
2. Repetible. En este segundo nivel se encuentran las empresas en las que existe

planificacin y seguimiento de proyectos y est implementada la gestin de los

mismos. No obstante, an existe un riesgo significativo de no cumplir las metas.

3. Definido. Existe un conjunto establecido de procesos estndar globales bien

definidos (estableciendo sus objetivos) dentro de la organizacin. Existe un sistema

de gestin de los proyectos. Una diferencia crtica entre los niveles 2 y 3 de madurez

es el alcance de los estndares, descripciones de los procesos y procedimientos. En

el nivel 2 pueden variar entre las distintas instancias de los procesos (entre

diferentes proyectos); a nivel 3 son globales dentro de la organizacin e igual en

todas las instancias de cada proceso.

4. Gestionado. Se caracteriza porque las organizaciones disponen de un conjunto de

mtricas significativas de calidad y productividad, que se usan de modo sistemtico

para la toma de decisiones y la gestin de riesgos. El software resultante es de alta

calidad.

5. Optimizado. La organizacin completa est volcada en la mejora continua de los

procesos. Se hace uso intensivo de las mtricas y se gestiona el proceso de

innovacin

1.2.2 Por qu evaluar CMMI?

El tema de CMMI cobra relevancia en la actualidad, cuando se habla de compaas que

producen software para satisfacer a un mercado creciente que reclama esta clase de

soluciones tecnolgicas. Partiendo del hecho de que deben buscar continuamente

alternativas que les permitan mejorar su performance y calidad de productos para

poder seguir compitiendo en un escenario cada vez ms globalizado y agresivo.

Necesidades a las que se enfrentan las compaas en la actualidad:

Mejor performance

11
Ms eficiencia

Evitar prdidas de mercado

Recursos humanos mejor preparados

Productos que faciliten la integracin de diferentes tecnologas.

1.2.3 Beneficios de CMMI

La gestin y la ingeniera de las actividades estn ms explcitamente enlazadas para

los objetivos del negocio.

Incorporar la experiencia adquirida en otras zonas de las mejores prcticas (por

ejemplo, la medicin, la gestin de riesgos, y gestin de proveedores)

Aplicar prcticas de alta madurez ms robustas.

Direccin organizacional adicional de funciones crticas para sus productos y servicios.

Cumplir lo ms completamente con las normas ISO.

12
CAPTULO II
CALIDAD EN EL CICLO DE
VIDA

13
2.1 Qu es el Ciclo de Vida de un Software?

El trmino ciclo de vida del software describe el desarrollo de software, desde la fase inicial

hasta la fase final. El propsito de este programa es definir las distintas fases intermedias

que se requieren para validar el desarrollo de la aplicacin, es decir, para garantizar que el

software cumpla los requisitos para la aplicacin y verificacin de los procedimientos de

desarrollo: se asegura de que los mtodos utilizados son apropiados.

Estos programas se originan en el hecho de que es muy costoso rectificar los errores que se

detectan tarde dentro de la fase de implementacin. El ciclo de vida permite que los errores

se detecten lo antes posible y, por lo tanto, permite a los desarrolladores concentrarse en

la calidad del software, en los plazos de implementacin y en los costos asociados.

2.1.1 Procedimientos

Definicin de objetivos: define la finalidad del proyecto y su papel en la estrategia

global.

Anlisis de los requisitos y su viabilidad: recopila, examina y formula los requisitos del

cliente y examina cualquier restriccin que se pueda aplicar.

Diseo general: requisitos generales de la arquitectura de la aplicacin.

Diseo en detalle: definicin precisa de cada subconjunto de la aplicacin.

Programacin (programacin e implementacin): implementacin de un lenguaje de

programacin para crear las funciones definidas durante la etapa de diseo.

Prueba de unidad: prueba individual de cada subconjunto de la aplicacin para

garantizar que se implementaron de acuerdo con las especificaciones.

Integracin: garantiza que los diferentes mdulos se integren con la aplicacin. Este es

el propsito de la prueba de integracin que est cuidadosamente documentada.

Prueba beta (o validacin): garantiza que el software cumple con las especificaciones

originales.

14
Documentacin: sirve para documentar informacin necesaria para los usuarios del

software y para desarrollos futuros.

Mantenimiento: comprende todos los procedimientos correctivos (mantenimiento

correctivo) y las actualizaciones secundarias del software (mantenimiento continuo).

El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una

aplicacin dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el

equipo de desarrolladores.

2.2 Modelos de Ciclo de Vida de Software

Para facilitar una metodologa comn entre el cliente y la compaa de software, los

modelos de ciclo de vida se han actualizado para reflejar las etapas de desarrollo

involucradas y la documentacin requerida, de manera que cada etapa se valide antes de

continuar con la siguiente

2.2.1 Modelo en Cascada

El modelo de ciclo de vida en cascada se comenz a disear en 1966 y se termin alrededor

de 1970. Se define como una secuencia de fases donde al final de cada una de ellas se rene

la documentacin para garantizar que cumple las especificaciones y los requisitos antes de

pasar a la fase siguiente:

15
2.2.2 Modelo en V

El modelo de ciclo de vida V proviene del principio que establece que los procedimientos

utilizados para probar si la aplicacin cumple las especificaciones ya deben haberse

creado en la fase de diseo.

16
2.3 Aseguramiento de Calidad de Software

El aseguramiento de calidad del software es el conjunto de actividades planificadas y

sistemticas necesarias para aportar la confianza en que el producto (software) satisfar

los requisitos dados de calidad.

El aseguramiento de calidad del software se disea para cada aplicacin antes de

comenzar a desarrollarla y no despus.

Algunos autores prefieren decir garanta de calidad en vez de aseguramiento.

o Garanta, puede confundir con garanta de productos

o Aseguramiento pretende dar confianza en que el producto tiene calidad

El aseguramiento de calidad del software est presente en:

o Mtodos y herramientas de anlisis, diseo, programacin y prueba

o Inspecciones tcnicas formales en todos los pasos del proceso de desarrollo

del software

o Estrategias de prueba multiescala

o Control de la documentacin del software y de los cambios realizados

o Procedimientos para ajustarse a los estndares (y dejar claro cuando se est

fuera de ellos

o Mecanismos de medida (mtricas)

o Registro de auditoras y realizacin de informes

Actividades para el aseguramiento- de calidad del software

o Mtricas de software para el control del proyecto

o Verificacin y validacin del software a lo largo del ciclo de vida

Incluye las pruebas y los procesos de revisin e inspeccin

o La gestin de la configuracin del software

17
2.4 Crisis de la Calidad de Software

La calidad ha sido durante mucho tiempo una preocupacin para las empresas, como lo

debe ser para los analistas de sistemas en el anlisis y diseo de sistemas de informacin.

Es demasiado arriesgado emprender todo el proceso de anlisis y diseo sin usar un enfoque

de aseguramiento de la calidad. Los tres enfoques para el aseguramiento de la calidad

mediante ingeniera de software son:

Garantizar el aseguramiento de la calidad total diseando sistemas y software con

un enfoque modular, descendente (de arriba abajo).

Documentar el software con las herramientas adecuadas.

Probar, mantener y auditar el software.

Dos propsitos guan el aseguramiento de la calidad. El primero es que el usuario del sistema

de informacin es el factor individual ms importante en establecer y evaluar su calidad. El

segundo es que mucho menos costoso corregir los problemas en sus fases iniciales que

esperar hasta que un problema se manifiesta a travs de las quejas o crisis del usuario.

Ya hemos aprendido acerca de la enorme inversin de mano de obra y otros recursos

empresariales que se requieren para desarrollar con xito un sistema. El uso del

aseguramiento de la calidad a lo largo del proceso es una forma de reducir los riesgos, ayuda

a garantizar que el sistema resultante ser lo que se necesita y de sea, mejorar

notablemente algn aspecto del desempeo del negocio. Este captulo proporciona al

anlisis tres enfoques principales para la calidad.

18
CAPTULO III
DESARROLLO EVOLUTIVO DE
LOS MTODOS GILES Y
HBRIDOS

19
3.1 Mtodos Agiles

3.1.1 Antecedentes

En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino gil aplicado

al desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del

software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su

objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar

software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.

Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,

caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de las

actividades desarrolladas.

Tras esta reunin se cre The Agile Alliance3 , una organizacin, sin nimo de lucro, dedicada a

promover los conceptos relacionados con el desarrollo gil de software y ayudar a las

organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto gil,

un documento que resume la filosofa gil.

3.1.2 Manifiesto gil

Segn el Manifiesto se valora:

Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.

La gente es el principal factor de xito de un proyecto software. Es ms importante construir un

buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el

entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que

ste configure su propio entorno de desarrollo en base a sus necesidades.

Desarrollar software que funciona ms que conseguir una buena documentacin.

20
La regla a seguir es no producir documentos a menos que sean necesarios de forma inmediata

para tomar un decisin importante. Estos documentos deben ser cortos y centrarse en lo

fundamental.

La colaboracin con el cliente ms que la negociacin de un contrato.

Se propone que exista una interaccin constante entre el cliente y el equipo de desarrollo. Esta

colaboracin entre ambos ser la que marque la marcha del proyecto y asegure su xito.

Responder a los cambios ms que seguir estrictamente un plan.

La habilidad de responder a los cambios que puedan surgir a los largo del proyecto (cambios en

los requisitos, en la tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del

mismo. Por lo tanto, la planificacin no debe ser estricta sino flexible y abierta

3.1.2.1 Principios Metodolgicos

I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de

software que le aporte un valor.

II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente

tenga una ventaja competitiva.

III. Entregar frecuentemente software que funcione desde un par de semanas a un

par de meses, con el menor intervalo de tiempo posible entre entregas.

IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del

proyecto.

V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el

apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo.

VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar

informacin dentro de un equipo de desarrollo.

VII. El software que funciona es la medida principal de progreso.

21
VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores,

desarrolladores y usuarios deberan ser capaces de mantener una paz

constante.

IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.

X. La simplicidad es esencial.

XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos

organizados por s mismos.

XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms

efectivo, y segn esto ajusta su comportamiento

3.1.2.2 Principios Bsicos de las Metodologas

En primer lugar, las metodologas giles mejoran la satisfaccin del cliente dado

que se involucrar y comprometer a lo largo del proyecto. En cada etapa del

desarrollo se informar al cliente sobre los progresos del mismo. De ese modo, el

cliente puede sumar su experiencia para optimizar las caractersticas del producto

final. Se pueden evitar as numerosos malentendidos dado que el cliente poseer

en todo momento una completa visin del estado del producto.

Asimismo, mejora la motivacin e implicacin del equipo de desarrollo. Pero esta

mejora no es casual: las metodologas giles permiten a todos los miembros del

equipo conocer el estado del proyecto en cualquier momento. Los compromisos

son negociados y aceptados por todos los miembros del equipo y las ideas de

cualquiera de sus integrantes son tenidas en cuenta.

Destacar que los procesos giles permiten ahorrar tanto tiempo como costes. El

desarrollo gil trabaja de un modo ms eficiente y rpido que otras metodologas.

Adems, estos procesos ponen el foco en cumplir estrictamente el presupuesto y

los plazos pactados a la hora de definir y planificar el proyecto.

22
Se trabaja con mayor velocidad y eficiencia. En las metodologas giles se trabaja

realizando entregas parciales pero funcionales del producto. De ese modo, es

posible entregar en el menor intervalo de tiempo posible una versin funcional del

producto.

Gracias a las entregas parciales (centradas en entregar en primer lugar aquellas

funcionalidades que en verdad aportan valor) y a la implicacin del cliente ser

posible eliminar aquellas caractersticas innecesarias del producto.

Las metodologas giles permiten mejorar la calidad del producto. La contnua

interaccin entre los desarrolladores y los clientes tienen como objetivo asegurar

que el producto final sea exactamente lo que el cliente quiere y necesita. Adems,

este enfoque permite abrazar la excelencia tecnolgica, lo que permite obtener un

producto tecnolgicamente superior.

Por otro lado, esta metodologa permite alertar rpidamente tanto de errores

como de problemas. En la etapa de planificacin, el equipo ha presentado una hoja

de ruta anticipando y dando respuesta a los principales problemas tcnicos y a la

velocidad en la que se puede trabajar. Con metodologas ms tradicionales, los

errores no identificados en las primeras fases del proyecto suelen acarrear costes

muy altos.

Y, finalmente, las metodologas giles permiten rentabilizar nuestras inversiones

ms rpidamente. Gracias a la realizacin de entregas tempranas el cliente tendr

rpido acceso a aquellas funcionalidades que en verdad aportan valor acelerando

el retorno de la inversin.

23
3.1.3 Comparacin entre Metodologas Agiles y Tradicionales

3.1.4 Algunas tcnicas Agiles

3.1.4.1 Extreme Programming

Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave

para el xito en desarrollo de software, promoviendo el trabajo en equipo,

preocupndose por el aprendizaje de los desarrolladores, y propiciando un buen clima

de trabajo. XP se basa en realimentacin continua entre el cliente y el equipo de

desarrollo, comunicacin fluida entre todos los participantes, simplicidad en las

soluciones implementadas y coraje para enfrentar los cambios. XP se define como

especialmente adecuada para proyectos con requisitos imprecisos y muy cambiantes, y

donde existe un alto riesgo tcnico

ROLES DE XP

- Programador. El programador escribe las pruebas unitarias y produce el cdigo del

sistema.

24
- Cliente. Escribe las historias de usuario y las pruebas funcionales para validar su

implementacin. Adems, asigna la prioridad a las historias de usuario y decide

cules se implementan en cada iteracin centrndose en aportar mayor valor al

negocio.

- Encargado de pruebas (Tester). Ayuda al cliente a escribir las pruebas funcionales.

Ejecuta las pruebas regularmente, difunde los resultados en el equipo y es

responsable de las herramientas de soporte para pruebas.

- Encargado de seguimiento (Tracker). Proporciona realimentacin al equipo. Verifica

el grado de acierto entre las estimaciones realizadas y el tiempo real dedicado, para

mejorar futuras estimaciones. Realiza el seguimiento del progreso de cada iteracin.

- Entrenador (Coach). Es responsable del proceso global. Debe proveer guas al

equipo de forma que se apliquen las prcticas XP y se siga el proceso correctamente.

- Consultor. Es un miembro externo del equipo con un conocimiento especfico en

algn tema necesario para el proyecto, en el que puedan surgir problemas.

PROCESO

El ciclo de desarrollo consiste (a grandes rasgos) en los siguientes pasos:

1. El cliente define el valor de negocio a implementar.

2. El programador estima el esfuerzo necesario para su implementacin.

3. El cliente selecciona qu construir, de acuerdo con sus prioridades y las

restricciones de tiempo.

4. El programador construye ese valor de negocio.

5. Vuelve al paso 1.

25
3.1.4.2 SCRUM

Propone una tcnica de desarrollo incremental mediante sprints. Para ello, no se cuenta

con una planificacin como tal, sino con un listado de caractersticas deseables para el

producto que se debern abordar durante los sprints de trabajo

3.1.4.3 Dynamic Systems Development Method (DSDM)

Define el marco para desarrollar un proceso de produccin de software. Nace en 1994

con el objetivo de crear una metodologa RAD unificada. Sus principales caractersticas

son: es un proceso iterativo e incremental y el equipo de desarrollo y el usuario trabajan

juntos. Propone cinco fases: estudio viabilidad, estudio del negocio, modelado

funcional, diseo y construccin, y finalmente implementacin. Las tres ltimas son

iterativas, adems de existir realimentacin a todas las fases.

3.1.4.4 Adaptive Software Development8 (ASD)

Su impulsor es Jim Highsmith. Sus principales caractersticas son: iterativo, orientado a

los componentes software ms que a las tareas y tolerante a los cambios. El ciclo de vida

que propone tiene tres fases esenciales: especulacin, colaboracin y aprendizaje. En la

primera de ellas se inicia el proyecto y se planifican las caractersticas del software; en

la segunda desarrollan las caractersticas y finalmente en la tercera se revisa su calidad,

y se entrega al cliente. La revisin de los componentes sirve para aprender de los errores

y volver a iniciar el ciclo de desarrollo.

3.1.4.5 Proceso Unificado gil

Es una versin simplificada del Rational Unified Process (RUP). En l se describe

una simple, fcil enfoque de entender el desarrollo de software de aplicaciones de

negocio utilizando tcnicas y conceptos giles

26
3.1.4.6 Modelado gil

Es una metodologa basada en la prctica para el modelado y eficaz documentacin

de los sistemas basados en software. En un Modelado gil de alto nivel es una

coleccin de las mejores prcticas, representados en el mapa de lenguaje de

patrones. A un nivel ms detallado Modelado gil es una coleccin de valores,

principios y prcticas para el software de modelado que se pueden aplicar en un

proyecto de desarrollo de software de una manera eficaz y ligero

3.2 Qu son Mtodos Hbridos?

Hay una gran diversidad de metodologas, aunque todas ellas caen dentro de alguna de las dos

clasificaciones mencionadas: giles o tradicionales. Sin embargo, existe una nueva categora: las

metodologas hbridas. Las metodologas hbridas pretenden retomar las ventajas de las

metodologas existentes, de tal forma que son una combinacin de las mejores prcticas

descritas en cada una de ellas.

3.2.1 Metodologa Propuesta

La metodologa que se propone es una metodologa hbrida para desarrollo de proyectos

de software. Fue creada tomando en cuenta las necesidades actuales de las empresas

mexicanas dedicadas al desarrollo de software. Esta metodologa combina algunas

prcticas existentes dentro de las metodologas RUP, XP y Scrum; por lo cual es un

hbrido entre lo tradicional y lo gil. Para utilizar esta metodologa basta saber:

Los roles que deben de existir.

Los principios metodolgicos.

El proceso de desarrollo.

27
3.2.2 Caractersticas

Proyectos de desarrollo de aplicaciones Web como ebusiness (electronic-business,

negocio electrnico), tambin e-commerce (electronic-commerce, comercio

electrnico).

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.2.3 Roles

ROL DESCRIPCION
Cliente Especifica los requerimientos y financia el proyecto de software
Lder del Se encarga de negociar los proyectos, por lo que es el integrante del
proyecto equipo de desarrollo que tiene ms relacin con el cliente/usuarios. Es
adems el intermediario entre el cliente y el administrador del proyecto.
Debe de tener la habilidad de unir ideas, personas y recursos. As como
tener facilidad para la toma de decisiones
Administrador Se encarga de coordinar a los programadores, al probador y al
del proyecto documentador. Adems organiza las reuniones necesarias para analizar
los requerimientos, realizar el diseo, el plan de proyecto y las pruebas.
Programador Son los responsables de codificar el diseo.
Probador Su funcin consiste en verificar 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.
Ayuda en la elaboracin de los rotafolios.
Usuarios finales Son las personas que interactan con el software una vez que se libera
para su uso productivo

3.2.4 Principios Metodolgicos

Hacer uso de papel rotafolio.

Realizar lluvias de ideas durante las juntas.

Hacer uso del Ciclo de Deming para la Gestin de Riesgos durante todo el proceso

de desarrollo.

28
Considerar los 14 Principios de Calidad de Deming, para garantizar calidad en el

proceso y en el producto de software.

3.2.5 Proceso de Desarrollo

Planteamiento, Preparacin, Construccin y Implantacin

3.2.6 Algunas Tcnicas Hibridas

3.2.6.1 ESSUP

Es una metodologa creada por Ivar Jacobson en el 2010, basada en el Proceso

Unificado (PU) [13], los mtodos giles y la madurez de procesos. EssUP es gil

porque no pretende imponer un proceso especfico, adems toma en cuenta que es

necesario tener flexibilidad y respuestas rpidas ante los cambios. Sin embargo,

EssUP menciona que es necesario documentar y modelar en UML [14], con lo cual

retoma una importante caracterstica de las metodologas tradicionales. Por lo que,

EssUP es una metodologa hbrida, aunque conceptualmente, ya que en la prctica

el equipo de desarrollo de software que pretenda utilizar esta metodologa debe

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 gran problema si no se tiene la experiencia y el

conocimiento necesario para saber elegir las mejores prcticas dentro de la

Ingeniera de Software y aplicarlas de manera adecuada en cada proyecto. EssUP

presenta una nueva tendencia en metodologas para desarrollo de software, ya que

29
intenta retomar algunas ventajas de las metodologas tradicionales y de las giles,

convirtindola en la primera metodologa hbrida.

CONCLUSIONES

Las metodologas de desarrollo de software han ido 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 proporcionado herramientas y

prcticas que ayudan en el proceso de desarrollo de software. Pero a pesar de la evolucin que

han tenido no existe una metodologa que se aplique para todos los tipos de proyecto de

software, por lo cual es necesario investigar cules son las necesidades reales del mbito donde

se desea implementar una determinada metodologa. As como tomar en cuenta las prcticas

de las metodologas existentes para poder seleccionar las que mejor convengan. Se puede

observar en los resultados de la investigacin, que las empresas que se dedican a desarrollar

software en Mxico no solamente son candidatas para usar metodologas hbridas, sino que

seguramente obtendrn mejores resultados al desarrollar software con una metodologa

hbrida. Por lo que esta metodologa ayudar a estas empresas a mejorar la calidad de sus

productos de software a menor costo y con un tiempo de desarrollo menor. La metodologa 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. La metodologa

se pretende implantar en algunas empresas mexicanas dedicadas a desarrollar software, esto

permitir probar la metodologa, para hacer las adecuaciones necesarias. Adems, se tiene

contemplado terminar la codificacin de la herramienta que servir de apoyo a la gestin del

proyecto al proporcionar la automatizacin de los elementos que se mencionan en el proceso

de desarrollo de la metodologa, como los diagramas de UML, el contrato, el plan de proyecto,

30
etc. Esta investigacin muestra que es factible utilizar una metodologa hbrida como la presente

metodologa para desarrollar software en Mxico. Adems, proporciona informacin que puede

ser empleada para otras investigaciones relacionadas con el rea de Ingeniera de Software en

Mxico.

31