Calidad de Software

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
9001 1987 Sistema de calidad
9004-1 1987 Gestin de la calidad y elementos del sistema de calidad - Parte 1
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
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

Calidad de Software

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Calidad de Software

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD JOS CARLOS MARITEGUI

FACULTAD DE INGENIERA Y ARQUITECTURA

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

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

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.2 Modelos de Ciclo de Vida de Software..15

2.2.1 Modelo en Cascada. 15

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.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.3 Dynamic Systems Development Method (DSDM) ..26

3.1.4.4 Adaptive Software Development8 (ASD) 26

3.1.4.6 Modelado gil 27

3.2 Qu son Mtodos Hbridos? 27

3.2.1 Metodologa Propuesta 28

3.2.4 Principios Metodolgicos.28

3.2.5 Proceso de Desarrollo.29

3.2.6 Algunas Tcnicas Hibridas 29

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

que los mtodos utilizados son apropiados.

den estabilidad en el mercado y en la sociedad.

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

ampliar sus mercados, mejorar su posicionamiento y crear valor.

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

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

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

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

tcitas de sus clientes.

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

representados por sus organismos nacionales de normalizacin

de calidad, que garantice la satisfaccin de las necesidades y

expectativas de los consumidores.

que trabajaran en el desarrollo de normas comunes que fuesen aceptadas

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

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

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

9000 fue de cinco aos

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

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

utilizar las normas.