Mejores Prácticas de Desarrollo de Software

Presentación del tema: "Mejores Prácticas de Desarrollo de Software"— Transcripción de la presentación:

1 Mejores Prácticas de Desarrollo de Software
Gloria Quintanilla Directora de Consultoría y Servicios Miembro Fundador Presidente del Consejo de Honor

2 “Sólo el 28% de los proyectos de software tienen éxito.”
Es una realidad... “Sólo el 28% de los proyectos de software tienen éxito.” Standish Group, CHAOS Report, 2001

3 “Industrial Software Metrics Top 10 List” Barry Boehm
Hechos del software Encontrar y corregir un error durante Producción cuesta veces más que en el Diseño. El tiempo de desarrollo no puede comprimirse más de un 25% aumentando el número de gente. Por cada $1 gastado en desarrollo, se gastan $2 en mantenimiento. Los costos de desarrollo y mantenimiento están directamente en función de las actividades manuales. Programación representa solo un 15% del “esfuerzo” de desarrollo. En desarrollo de software existe deseconomía de escala (costo/línea) “Industrial Software Metrics Top 10 List” Barry Boehm

4 Síntomas de la crisis del Software
No son cubiertas las necesidades del negocio. Requerimientos mal definidos. Módulos que no se integran. Difícil de mantener. Tardío descubrimiento de defectos. Baja calidad. Usuario finales insatisfechos. Bajo desempeño sobre altas cargas. Esfuerzo no coordinado del equipo. Liberaciones (Build-and-release issues)

5 Problemática del desarrollo de Software
Maximizar Beneficios Dirección Conducir el equipo al éxito Jefe de Proyecto Crear Software de calidad Desarrollador

6 Problemática del desarrollo de Software
Maximizar Beneficios Dirección Retraso en proyectos Oportunidades perdidas Amenazas de la competencia Conducir el equipo al éxito Jefe de Proyecto Fechas ajustadas Recortes de presupuestos Pocos recursos. Crear Software de calidad Desarrollador Reuniones Cambios Rehacer trabajo hecho

7 Problemática del desarrollo de Software
Maximizar Beneficios Dirección Dirección Retraso en proyectos Oportunidades perdidas Amenazas de la competencia Conducir el equipo al éxito Jefe de Proyecto Jefe de Proyecto Fechas ajustadas Recortes de presupuestos Pocos recursos. Crear Software de calidad Desarrollador Desarrollador Reuniones Cambios Rehacer trabajo hecho

8 Mejores Prácticas en Desarrollo de Software
Proceso Práctico Desarrollo Iterativo Gestión de Requisitos Arquitecturas Basadas en Componentes Modelado Visual (UML) Verificación Continua de la Calidad Gestión del Cambio

9 ¿Qué son las Mejores Prácticas?
Es un conjunto de principios, métodos y procesos que permiten mejorar la calidad y productividad del desarrollo de software.

10 La validez de las Mejores Prácticas está probada
Utilizadas en: 1000’s de clientes. 1000’s de proyectos. Líderes del sector.

11 Mejores Prácticas en Desarrollo de Software
Proceso Práctico Desarrollo Iterativo Gestión de requisitos Arquitecturas Basadas en Componentes Modelado Visual (UML) Verificación Continua de la Calidad Gestión del Cambio

12 ANÁLISIS DE REQUISITOS
Desarrollo en cascada ANÁLISIS DE REQUISITOS DISEÑO CODIFICACIÓN INTEGRACIÓN PRUEBAS

13 Desarrollo iterativo Iteración 1 Iteración 2 Iteración n
Tiempo Cada iteración produce una versión executable del sistema. Las primeras iteraciones atacan los riesgos mayores. Se define y robustece la arquitectura de la aplicación en forma temprana. Cada iteración permite la retroalimentación del usuario. Se prueba desde el principio, verificando desempeño y escalabilidad. Entregables bien definidos y delimitados permiten tener metas a corto plazo y no una sola meta a largo plazo. El progreso se mide mediante la evaluación de las implementaciones (mediciones reales).

14 Los retos del Líder del Proyecto
Dificultad para conocer el estado real de los proyectos Falta de comunicación con el equipo y poca eficiencia En las juntas de equipo sólo se recopila información y no se resuelven problemas Múltiples proyectos, prioridades y procesos ? ? ? ? ? ? ? Líder del proyecto

15 Perfil de riesgo de un desarrollo iterativo
Cascada Iterativo Riesgo Tiempo

16 Reducción del retrabajo
Síntomas de un proceso convencional en cascada Problemas de retrasos en proyectos 40% esfuerzo en integracion y pruebas Actividades Secuenciales: Análisis Diseño Código Integración Pruebas Problema Inicio de Integración 100% Progreso (% codificado) Fecha Fin Original Fecha Fin Real Tiempo

17 Reducción del retrabajo
Prototipos Arquitectura Versiones Versión Funcionales Final Fases secuenciales – Actividades iterativas 100% Progreso (% codificado) Fecha Fin Original Fecha Fin Real Tiempo

18 Ejemplo de un proceso iterativo
Contenido Tiempo

19 Rational Unified Process
“Processes represent “recipes” for success, based on the past experience on projects” Dr. Pankaj Jalote, 2002 “RUP se ha convertido en el proceso de desarrollo de software más utilizado” Oktaba, Ibargüengoitia y Ruiz 2001 …to transform an organization into a highly productive team, one of the best decisions you can make is to CHANGE what you can, ACCEPT what you can’t change, and BORROW EVERYTHING you can that has been validated by a successful software community. Philippe Krutchen, 2001

20 N1 Variación de +/- 50% o más
Niveles de estimados N3 Variación de +/- 10% N2 Variación de +/- 30% N1 Variación de +/- 50% o más

21 Niveles de Planes N1 N2

22 El plan de desarrollo de software integra otros planes

23 Mejores Prácticas en Desarrollo de Software
Proceso Práctico Desarrollo Iterativo Gestión de Requisitos Arquitecturas Basadas en Componentes Modelado Visual (UML) Verificación Continua de la Calidad Gestión del Cambio

24 ¿Por qué preocuparnos por los requisitos?

25 Érase un proyecto ... Como lo solicitó el cliente Como lo diseñó
el arquitecto Como lo especificó el ingeniero Como lo solicitó compras Como lo construyó el contratista Como quedó finalmente LO QUE REALMENTE SE NECESITABA

26 ¿Porqué falla un Proyecto?
Entre Otros: El usuario no sabe lo que quiere (¿o nosotros no lo entendemos?). Requerimientos y especificaciones incompletos. Cambio en los requerimientos y especificaciones. Carencia de participación por parte del usuario. No existe documentación. Falta de una metodología para la gestión de requisitos. Standish Group, ‘99

27 ¿Qué son los requisitos?
Un requisito es una propiedad/característica que debe ser mostrada por el sistema que se esté construyendo. Característica que debe incluirse en un sistema

28 Impacto de los errores en los requisitos
Costo de reparación de errores Etapa Boehm ‘76, 88 “ Resolver errores en fase de mantenimiento cuesta 200 veces más que resolverlos en gestión de requisitos.” Average cost ratio 14:1 Grady 1989 1-2 Elicitación de requisitos 5 Diseño 10 Codificación 20 Pruebas unitarias 50 Pruebas 200 Mantenimiento

29 Gestión de requisitos implica…
Asegurarse de: Resolver el problema correcto. Construir el sistema apropiado. Fases de gestión de requisitos: Identificación. Organización (estructura y rastreabilidad). Documentación (especificación). Validación de requisitos. Gestión: del cambio en requisitos, de los atributos, de la rastreabilidad.

30 Técnicas de trabajo con usuarios
Talleres de requerimientos Entrevistas Cuestionarios Prototipos Juego de roles Análisis de regulaciones y procesos actuales Lluvia de ideas

31 Atributos de los requisitos
Prioridad Estado Costo Req. 100 Responsable Dificultad Riesgo Relación Req. 201 Req. 202

32 Atributos de requisitos en la Admón. del Proyecto
Esfuerzo Costo Riesgo Prioridad Status  Req. 10 Aprobado Bajo Alta $$$  Req. 13 Propuesto Medio Baja $$   Req. 40 Obligatorio Alto Alto $

33 Evaluación del impacto del cambio
es una característica de la relación de dependencia de los requerimientos para reaccionar a los cambios de sus elementos relacionados Necesidades Negocio: Necesidades Negocio Características producto (casos de uso) Pruebas Características del producto: Rastreabilidad: la relación entre los artifactos Casos de Uso:

34 Compartir los requisitos
Cada uno de los participantes del proyecto requiere tener acceso a los requisitos. Desarrolladores y diseñadores Aseguramiento de la Calidad Req Analistas Usuarios y Clientes `Gerentes Líder de Proyecto

35 Repositorio de requisitos

36 Matriz de rastreabilidad
Muestra las dependencias entre requerimientos

37 Mejores Prácticas en Desarrollo de Software
Proceso Práctico Desarrollo Iterativo Gestión de Requisitos Arquitecturas Basadas en Componentes Modelado Visual (UML) Verificación Continua de la Calidad Gestión del Cambio

38 Evolución típica de una aplicación ...
arreglo A790 arreglo A812 nuevo requerimiento V 1.2a V 1.2 Arquitectura 1.0

39 Arquitectu a 1.0 r Resistencia al cambio arreglo A790 arreglo A812
nuevo requerimiento V 1.2a Arquitectu V 1.2 a 1.0 r

40 ¿Por qué utilizar arquitecturas de componentes?
La clave del éxito es crear arquitecturas: Duraderas Flexibles al cambio Basadas en componentes La Arquitectura es el 20% del esfuerzo que produce el 80% más importante Desarrollar: Con Reuso Para Reuso

41 Activos de software reutilizable
Reuso de todo “artefacto” Arquitectura Casos de Uso, Análisis, Diseño, Implementación y Pruebas Modelos de interfaces, modelos de negocio, patrones arquitectónicos, etc. Reuso de tecnología Proceso y automatización Proyectos Guías

42 Ejemplo: Arquitectura basada en componentes
Funciones de licenciamiento Funciones de cliente/ productos Mecanismos de interfaces Licencia Cliente Producto Comprado Existente Nuevo Database CRM

43 Arquitectura de los Sistemas Corporativos 3-capas
PRESENTACIÓN LÓGICA NEGOCIO INTEGRACIÓN Interfaces de usuarios Transactions procesing monitors Bases de datos

44 Contenedor de Aplicaciónes Cliente
J2EE Web Server Contenedor Web Servicios J2EE Servicios J2SE JSP Servelet EJB Server Contenedor de EJB EJB Dispositivo Cliente HTML,XML,WML Contenedor de Applets Applet Contenedor de Aplicaciónes Cliente Aplicación Cliente Mail Server Directory Services Message Queue Java Application CORBA JDBC JavaMail JNDI JMS RMI HTTP CLIENTE SERVIDOR PRESENTACIÓN LÓGICA DE NEGOCIO INTEGRACIÓN

45 Mejores Prácticas en Desarrollo de Software
Proceso Práctico Desarrollo Iterativo Gestión de Requisitos Arquitecturas Basadas en componentes Modelado Visual (UML) Verificación Continua de la Calidad Gestión del Cambio

46 ¿Qué es UML? UML es el lenguaje estándar para visualizar, especificar, construir y documentar los artefactos de una aplicación software

47 UML: El lenguaje para el desarrollo software
Planned major revision (2003) Approved minor revision 2001 UML 1.4 Current minor revision 1999 UML 1.3 OMG Acceptance, Nov 1997 Final submission to OMG, Sept 1997 First submission to OMG, Jan 1997 UML 1.1 UML 1.0 UML partners June 1996 UML 0.9 OOSE Otras metodologías Unified Method 0.8 OOPSLA 95 OMT Booch method

48 Modelado de Requisitos Modelado de Aplicaciones
UML Modelado de Requisitos Modelado de Aplicaciones Modelado Web Modelado de Datos Modelado de Negocio Un único lenguaje para todo el equipo

49 Perspectivas arquitectónicas de una casa
1 2 3

50 Arquitectura en desarrollo de SW: 4+1 Vistas
VISTA LÓGICA VISTA IMPLEMENTACIÓN Document Repository FileList FileManager GraphicFile File GrpFile read( ) open( ) create( ) fillFile( ) rep Repository name : char * = 0 readDoc( ) readFile( ) (from Persistence) FileMgr fetchDoc( ) sortByName( ) DocumentList add( ) delete( ) Document name : int docid : int numField : int get( ) close( ) sortFileList( ) fillDocument( ) fList 1 FileList File read() fill the code.. CASOS DE USO Actor A Use Case 1 Use Case 2 Use Case 3 Actor B VISTA DE PROCESO VISTA DE DESPLIEGUE Window95 ¹®¼­°ü¸® Ŭ¶óÀ̾ðÆ®.EXE Windows NT ¹®¼­°ü¸® ¿£Áø.EXE Windows95 Solaris ÀÀ¿ë¼­¹ö.EXE Alpha UNIX IBM Mainframe µ¥ÀÌŸº£À̽º¼­¹ö ¹®¼­°ü¸® ¾ÖÇø´ ºÐ»ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ - À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® - À©µµ¿ì NT: ÀÀ¿ë¼­¹ö - À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼­¹ö ¹× µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö - IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼­¹ö, Åë½Å ¼­¹ö [yes] user mainWnd fileMgr : FileMgr repository document : Document gFile 1: Doc view request ( ) 2: fetchDoc( ) 3: create ( ) 4: create ( ) 5: readDoc ( ) 6: fillDocument ( ) 7: readFile ( ) 8: fillFile ( ) 9: sortByName ( ) ƯÁ¤¹®¼­¿¡ ´ëÇÑ º¸±â¸¦ »ç¿ëÀÚ°¡ ¿äûÇÑ´Ù. È­ÀÏ°ü¸®ÀÚ´Â Àоî¿Â ¹®¼­ÀÇ Á¤º¸¸¦ ÇØ´ç ¹®¼­ °´Ã¼¿¡ ¼³Á¤À» ¿äûÇÑ´Ù. È­¸é °´Ã¼´Â ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑ È­¸é¿¡ º¸¿©ÁØ´Ù.

51 Ambientes: roundtrip engineering
Capacidad de modelado UML Sincronía entre modelos y código. Patrones de diseño.

52 Diseño y construcción del sistema desde una herramienta única
Diseño de Datos Analista de Negocio Desarrollador Una Herramienta para todo el equipo. Arquitecto Diseñador DB

53 Mejores Prácticas en Desarrollo de Software
Proceso Práctico Desarrollo Iterativo Gestión de Requisitos Arquitecturas Basadas en Componentes Modelado Visual (UML) Verificación Continua de la Calidad Gestión del Cambio

54 Verificación continua de la calidad
Es de 100 a 1000 veces más costoso encontrar y reparar los problemas del software después del desarrollo Costo de reparar el software. Costo de perder oportunidades. Costo de perder clientes Costo Concepción Elaboración Construcción Transición

55 Causas principales de la baja calidad del software
Probar Software es muy difícil. Cambios en los requerimientos. Falta de un proceso sistemático de pruebas. Mala comunicación entre miembros del equipo.

56 Solución: Verificación Continua
We have lost two generations of developers who think they just need to debug at the end, when they instead shouldn’t introduce any defects along the way. Ivar Jacobson, México 2001 Problema de Actitud: “bugs” son normales, “defectos” no son aceptados los programadores “ensucian”, otros (clientes) “limpian” Cambiar: Verificar y probar todo continuamente desde el inicio. Toda actividad es verificada: los casos de prueba se definen a partir de: requerimientos, análisis, diseño, codificación... Automatizar la verificación de la calidad con herramientas

57 Cada actividad incluye su verificación
Todo aquello que hagas, no lo habrás terminado, hasta que hayas verificado que hiciste lo que debías de hacer. Ejecución Actividad Acción Verificación

58 Plan de actividades de aseguramiento de la calidad
Conjunto de actividades que serán ejecutadas para generar confianza en que el producto cumplirá con los requerimientos y el proceso es efectivo Cliente Validaciones Necesidades Verificaciones Producto Requisitos Revisiones

59 Jerarquía de planes Plan de Desarrollo
Plan de Aseguramiento de la Calidad Plan de Pruebas (de software)

60 IMPLEMENTACIÓN. Probar en cada iteración .....
Pruebas Manuales Pruebas Re-ejecutar primeras pruebas y ... Tiempo Build 1

61 IMPLEMENTACIÓN. Pruebas de regresión
Pruebas Manuales Pruebas Difícil de forma manual! ...las nuevas pruebas... ...más tiempo Tiempo Build 1 Build 2 Build 3, 4, 5, 6, 7, 8 Build 9 Build 10

62 Calidad - el elemento evasivo
La perspectiva transcendental... algo que se puede reconocer pero no definir La perspectiva del usuario… apropiada para su objetivo (fitness for purpose) La perspectiva de manufactura… conformancia con la especificación La perspectiva de producto… la calidad se encuentra intensamen te relacionada con características inherentes al producto La perspectiva del valor… la calidad es dependiente de la cantidad que el cliente quiere pagar por ella

63 Calidad: IEEE Standard Glossary of Software Engineering Terminology
El grado en el que un sistema, componente o proceso cumple con: los requisitos especificados, y las necesidades y expectativas del cliente o usuario

64 Calidad del Software: Características (ISO 9126)
Eficiencia Facilidad de Uso Fiabilidad Funcionalidad Facilidad de Mantenimiento Portabilidad

65 Facilidad de Mantenimiento
La capacidad del software de proveer funciones que cumplan con las necesidades implícitas y las establecidas … apropiado precisión interoperación seguridad de acceso conformidad Calidad del Software Eficiencia Facilidad de Uso Fiabilidad Funcionalidad Facilidad de Mantenimiento Portabilidad functionality suitability accuracy interoperability security compliance

66 La capacidad del software de mantener su nivel de desempeño…
madurez tolerancia a fallos capacidad de recuperación conformidad Calidad del Software Eficiencia Facilidad de Uso Fiabilidad Funcionalidad Facilidad de Mantenimiento Portabilidad reliability maturity fault tolerance recoverability compliance

67 Facilidad de Mantenimiento
La capacidad del software de ser entendido, aprendido, usado y gustado por el usuario … entendible facilidad de aprendizaje facilidad de operación atractivo conformidad Calidad del Software Eficiencia Facilidad de Uso Fiabilidad Funcionalidad Facilidad de Mantenimiento Portabilidad usability understandability learnability operability attractiveness compliance

68 Facilidad de Mantenimiento
La capacidad del software de proveer el desempeño requerido, relativo a la catidad de recursos usados… tiempos de respuesta consumo de recursos conformidad Calidad del Software Eficiencia Facilidad de Uso Fiabilidad Funcionalidad Facilidad de Mantenimiento Portabilidad efficiency time behaviour resource utilization compliance

69 Facilidad de Mantenimiento
La capacidad del software de ser modificado. Modificaciones pueden incluir correcciones, mejoras o adaptaciones a cambios… facilidad de análisis facilidad de modificaciones estabilidad facilidad de pruebas conformidad Calidad del Software Eficiencia Facilidad de Uso Fiabilidad Funcionalidad Facilidad de Mantenimiento Portabilidad maintainability analysability changeability stability testability compliance

70 Facilidad de Mantenimiento
La capacidad del software de ser transferido de un ambiente a otro (organizacional, hardware o software)… facilidad de adaptación facilidad de instalación co-existencia facilidad de reemplazo conformidad Calidad del Software Eficiencia Facilidad de Uso Fiabilidad Funcionalidad Facilidad de Mantenimiento Portabilidad portability adaptability installability co-existence replaceability compliance

71 Mejores Prácticas en Desarrollo de Software
Proceso Práctico Desarrollo Iterativo Gestión de requisitos Arquitecturas basadas en componentes Modelado Visual (UML) Verificación Continua de la Calidad Gestión del Cambio

72 Criterios de liberación Errores Requerimientos
¡Cambiar! ¿Qué es lo primero que se le viene a la mente? ¡Otra vez! ¡Ya no lo hago! ¡Problemas! Código En el desarrollo de software, ¡Los cambios ocurren! Modelos Plataforma de distribución Pruebas ¡Todo el tiempo! Criterios de liberación Errores Especificaciones de integración Requerimientos

73 El Proceso de Cambio: El Problema
¿Por qué el build no se realizó? Por supuesto que no olvidé el archivo... ¿El requerimiento 462 se incluyó en esta liberación? ¿Cuántos errores de Prioridad 1 faltan? ¿Se arregló el error 873 en este build? Nuevo diseño web Nueva transacción del cliente Error 98 Nuevo botón GUI Añadir cálculo de promoción Error 179 Nueva plataforma Error 849 Error 527 Error 251 Error 348 Líder de Proyecto Analista Build 3 Build 2 Build 1 Probadores Integrador Desarrolladores

74 Dificultades del Desarrollador:
Acceso a la versión adecuada del producto. Desarrollar y probar en un entorno estable. Sincronización con el resto del equipo. Como resolver defectos sin afectar al desarrollo

75 Dificultades del Líder de Proyecto:
Evaluar el estado del proyecto. Comunicación entre los miembros. Gestionar de proyectos en paralelo. Procesos de control y seguimiento.

76 Dificultades del Integrador
Gran cantidad de versiones de archivos. Dependencias entre componentes. Pases a producción consistentes. Jefe de Proyecto Integrador

77 Factores que dificultan la gestión del cambio
Complejidad en el entorno del proyecto. Tamaño del equipo. Interdependencia entre componentes. Distribución geográfica. Complejidad del Sistema de Software. Tamaño del producto. Complejidad de la arquitectura. Número de plataformas. Aparición de nuevas tecnologías y requisitos.

78 Unificar la administración de cambios
¿Cómo cerrar el ciclo? La gente realiza las actividades ( i.e., órdenes de trabajo, corrección de errores) ? Bug 98 Añadir el Cálculo de Promoción Error 179 Nuevo boton GUI Nueva plataforma Nuevo diseño Web Error 849 Error 527 Error 251 Nueva Transacción del Cliente Erro 348 Las Actividades generan artefactos (i.e., módulos de código) Los artefactos se integran en líneas base

79 El Proceso de Cambio: La Solución
Administración de configuración y cambios Órdenes de Trabajo Calidad del producto Administración de configuración Petición de cambios y arreglo de defectos Fallas reportadas Petición de nuevas características

80 Proceso basado en actividades
Bug 862 Bug Fix 581 Bugs 411 Bug 611 New widget More stuff! Bug Fix 480 New Button New Script New Transaction Bug 396 Bug 952 Bug 953 New GUI Bug Fix 581 Bug 952 Bugs 411 New Web Graphics New GUI New widget Bug Fix 480 Bug 862 More stuff! Bug 611 New List New Script Bug 951 MS Windows 2000 New Transaction New DB support Bug 400 Update Doc New Button New Script Bug 950 Bugs 959 New DB support Bug 396 Bug Fix 196

81 Proceso basado en actividades
DB support Bug 396 Bugs 411 More stuff! Bug 611 MS Win 2000 New widget New GUI New Graphics Bug Fix 480 New List Bug Fix 581 Integration Bug 862 Bug Fix 196 New Script New button

82 Controlar los cambios del software
Orden de Trabajo Líder de Proyecto Requerimientos Diseño Desarrollo Pruebas Fix Bug 671 2. Special Promo 3. Fix Bug 829 2. Add copyright 3. Update price 1. Test Promo 3. Test GUI applet 1. Define Promo 3. Add Use Case To Do List To Do List To Do List To Do List 1. Special Promo 2. Verify Bug 467 2. Define GUI Requirements Code Content Test Scripts Requirement Document hello.c foo.c Delete items Cancel Order Rose models Special Promo

83 Administración de la configuración y cambios: Mediciones
“¿Los defectos de alto grado se lograron resolver en este build?” “¿Cúales cambios faltan por resolver?” Métricas revelan el estado del proyecto en cualquier momento. Líder del Proyecto

84 Gestión del trabajo en paralelo
Líneas de desarrollo y de mantenimiento. Concurrencia en el desarrollo. Particularización de componentes. Distintas versiones en producción.

85 Objetivos de la Administración de Configuración y Cambios
Permitir, controlar y monitorear cambios para habilitar un desarrollo iterativo. Controlar todos los artefactos de software - modelos, código, documentos, etc. Administrar todas las versiones, con integración automática a los cambios realizados al software. Establecer espacios de trabajo seguros y aislados para cada desarrollador. Contar con métricas de estado y avance. ¡ Saber qué está pasando en el equipo y en el proyecto !

86 Gestión de Procesos ¿tenemos tiempo?….

87 Modelos de Gestión de Procesos
QUÉ Genérico QUÉ Especializado ISO 9000 CÓMO CMM – Mejores Prácticas CON QUÉ Metodología- Proceso de la Organización Herramientas

88 Características de ISO 9000
Norma mexicana Certificación reconocida a nivel internacional Asegura la mejora continua de procesos Establece una cultura organizacional de calidad No provee lineamientos específicos para procesos especializados a un área de aplicación (de software en particular)

89 En el año 2000 se emitió una serie revisada de normas
ISO 9000 Estructura orientada a procesos Énfasis en la mejora continua, para mejorar la calidad del sistema y los procesos Medición de la satisfacción del cliente Mayor atención a la provisión de recursos Análisis de datos del desempeño del sistema

90 Los Ocho Principios de Gestión de la Calidad
ISO 9000 Orientación al cliente Liderazgo Participación del personal Enfoque a procesos Enfoque sistémico Mejora continua Toma de decisiones basadas en hechos Relaciones mutuamente benéficas con proveedores

91 Enfoque a la Gestión de Procesos ISO 9001:2000
Cliente Requisitos Cliente Satisfacción Responsabilidad de la Dirección Realización del Producto Gestión de los Recursos Medición, Análisis y Mejora Producto

92 Gestión de Procesos Establecer y mantener una política organizacional.
ISO 9000 Establecer y mantener una política organizacional. Establecer y mantener requisitos, objetivos y planes. Proveer recursos adecuados. Asignación de la responsabilidad y autoridad. Capacitación de la gente. Realización del proceso. Administración de la configuración de los productos de trabajo. Seguimiento y control de actividades. Verificación objetiva de la conformidad. Revisión por la alta gerencia y resolución de asuntos.

93 Modelos de Gestión de Procesos
QUÉ Genérico QUÉ Especializado ISO 9000 CÓMO CMM – Mejores Prácticas CON QUÉ Metodología- Proceso de la Organización Herramientas

94 El Software Engineering Institute (SEI)
CMM El Software Engineering Institute (SEI) de la Universidad de Carnegie Mellon (Pittsburgh, Pa.) es financiado por el departamento de defensa de los E.U.A. El SEI ha desarrollado, y constantemente está refinando, una metodología para la gestión y mejora de la capacidad del proceso de software El Capability Maturity Model (CMM) fué desarrollado con dos propósitos: Proporcionar al Departamento de Defensa un medio para caracterizar la capacidad de los contratistas de software Ayudar a determinar y mejorar las capacidades de las organizaciones de desarrollo de software Información relacionada con el SEI:

95 Gestión del Proceso de Software
CMM Responsabilidad de la Dirección Gestión de los Recursos Realización del Producto Medición, Análisis y Mejora Proceso de Software Niveles de Madurez de Capacidad del Proceso 5 Optimizado 4 Administrado 3 Definido/ Organización 2 Repetible/ Proyecto 1 A la medida

96 Institucionalización de procesos
CMM Compromiso para Ejecutar Dirección Habilidad para Ejecutar Recursos Medición Actividades Realizadas Realización Verificación de la Implantación Medición y Análisis Plan de Calidad del Proceso ISO 9001: 2000 Características Comunes del Proceso CMM

97 Institucionalización de procesos
CMM Compromiso para Ejecutar Dirección Habilidad para Ejecutar Recursos Medición Actividades Realizadas Realización Verificación de la Implantación Medición y Análisis Plan de Calidad del Proceso ISO 9001: 2000 Características Comunes del Proceso CMM

98 Institucionalización de procesos
CMM Compromiso para Ejecutar Dirección Habilidad para Ejecutar Recursos Medición Actividades Realizadas Realización Verificación de la Implantación Medición y Análisis Plan de Calidad del Proceso ISO 9001: 2000 Características Comunes del Proceso CMM

99 Institucionalización de procesos
CMM Compromiso para Ejecutar Dirección Habilidad para Ejecutar Recursos Medición Actividades Realizadas Realización Verificación de la Implantación Medición y Análisis Plan de Calidad del Proceso ISO 9001: 2000 Características Comunes del Proceso CMM

100 Institucionalización de procesos
CMM Compromiso para Ejecutar Dirección Habilidad para Ejecutar Recursos Medición Actividades Realizadas Realización Verificación de la Implantación Medición y Análisis Plan de Calidad del Proceso ISO 9001: 2000 Características Comunes del Proceso CMM

101 Áreas Clave del Proceso de Software
CMM Coordinación Intergrupal (CI-3) Revisiones entre Colegas (RC-3) Ingeniería de Software (IS-3) Programa Integral de Capacitación (PC-3) Admón. Integrada de Software (AI–3) Definición de Procesos de la Organización (PO-3) Niveles de Madurez de Capacidad del Proceso 5 Optimizado Enfoque a Procesos de la Organización (EP-3) 4 Administrado 3 Definido/ Organización Admón. de Configuraciones (AC-2) Aseguramiento de la Calidad (QA-2) 2 Repetible/ Proyecto Admón. de Subcontratistas (AS-2) 1 A la medida Seguimiento a Proyectos (SP-2) Planeación de Proyectos (PP-2) Admón. de Requerimientos (AR-2)

102 Modelos de Gestión de Procesos
QUÉ Genérico QUÉ Especializado ISO 9000 CÓMO CMM – Mejores Prácticas CON QUÉ Metodología- Proceso de la Organización Herramientas

103 RUP : Un Proceso Práctico de Desarrollo
Responsabilidad de la Dirección Gestión de los Recursos Realización del Producto Medición, Análisis y Mejora Proceso de Software 5 Optimizado 4 Administrado RUP: materializa las Mejores Prácticas y asegura que todos entiendan claramente y puedan seguir un proceso práctico al desarrollar software

104 RUP entrega el COMO que requiere ISO y CMM
El RUP define QUE actividades hay que hacer, QUIEN, CUANDO y COMO hacerlas La información que necesitas (con tanto detalle como requieras) Cuando la necesitas En un formato realmente utilizable RUP is a way to successfully fulfill CMM requirements Philippe Krutchen,2001

105 Gracias