Mejores Prcticas de Desarrollo de Software Gloria Quintanilla

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

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

Hechos del software • Encontrar y corregir un error durante Producción cuesta 1000 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 Preparado por:

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) Preparado por:

Problemática del desarrollo de Software Direcció n Jefe de Proyecto Desarrollad or Preparado por: Maximizar Beneficios Conducir el equipo al éxito Crear Software de calidad

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

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

Mejores Prácticas en Desarrollo de Software Mejores Prácticas 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 Preparado por:

¿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. Preparado por:

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

Mejores Prácticas en Desarrollo de Software Mejores Prácticas 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 Preparado por:

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

Desarrollo iterativo Iteración 1 Iteración 2 R R D Iteración n R D C I C I T T 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). Preparado por:

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 Preparado por:

Perfil de riesgo de un desarrollo iterativo Cascada Iterativo Riesgo Tiempo Preparado por:

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

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

Ejemplo de un proceso iterativo Contenido Tiempo Preparado por:

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 Preparado por:

Niveles de estimados N 1 Variación de +/- 50% o más N 2 Variación de +/- 30% Preparado por: N 3 Variación de +/- 10%

Niveles de Planes N 1 N 2 Preparado por:

El plan de desarrollo de software integra otros planes Preparado por:

Mejores Prácticas en Desarrollo de Software Mejores Prácticas 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 Preparado por:

¿Por qué preocuparnos por los requisitos? Preparado por:

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

¿Porqué falla un Proyecto? Entre Otros: 1. 2. 3. 4. 5. 6. 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 Preparado por:

¿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 Preparado por:

Impacto de los errores en los requisitos Etapa 1 -2 Elicitación de requisitos 5 Diseño 10 Codificación 20 Pruebas unitarias 50 Pruebas 200 Mantenimiento “ 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 Costo de reparación de errores Boehm ‘ 76, 88 Preparado por:

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. Preparado por:

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 Preparado por:

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

Atributos de requisitos en la Admón. del Proyecto us t a St Req. 10 Aprobado Req. 13 Propuesto Req. 40 Obligatorio Preparado por: R o g s ie Bajo Medio Alto ad rid o i Pr o z r to e s u f o C Es Alta Baja Alto $$$ $$ $

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

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

Repositorio de requisitos Preparado por:

Matriz de rastreabilidad Muestra las dependencias entre requerimientos Preparado por:

Mejores Prácticas en Desarrollo de Software Mejores Prácticas 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 Preparado por:

Evolución típica de una aplicación. . . arreglo A 790 arreglo A 812 nuevo requerimiento V 1. 2 a Arquitectura 1. 0 Preparado por: V 1. 2

Resistencia al cambio arreglo A 790 arreglo A 812 nuevo requerimiento r Preparado por: V 1. 2 Arquitectu a 1. 0 V 1. 2 a

¿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 Preparado por:

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 Preparado por:

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

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

J 2 EE CLIENTE SERVIDOR Dispositivo Cliente HTML, XML, WML JDBC HTTP Web Server Contenedor Web EJB Server Dispositivo Cliente Contenedor de Applets JSP Servelet Java. Mail Contenedor de EJB HTTP Servicios J 2 EE Applet Servicios J 2 SE EJB Servicios J 2 EE JNDI JMS Servicios J 2 SE HTTP RMI Dispositivo Cliente Contenedor de Aplicaciónes Cliente RMI Aplicación Cliente Servicios J 2 EE Servicios J 2 SE Mail Server PRESENTACIÓN Preparado por: LÓGICA DE NEGOCIO Directory Services Message Queue Java Application CORBA INTEGRACIÓN

Mejores Prácticas en Desarrollo de Software Mejores Prácticas 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 Preparado por:

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

UML: El lenguaje para el desarrollo software Planned major revision (2003) UML 2. 0 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 partners UML 1. 0 June 1996 UML 0. 9 OOPSLA 95 Otras metodologías. OOSE Preparado por: Unified Method 0. 8 Booch method OMT

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

Perspectivas arquitectónicas de una casa 1 2 3 Preparado por:

Arquitectura en desarrollo de SW: 4+1 Vistas VISTA LÓGICA VISTA IMPLEMENTACIÓN Repository Document. List Document File. Mgr File. Manager add( ) name : int delete( ) fetch. Doc( ) docid : int sort. By. Name( ) num. Field : int get( ) read() fill the open( ) Document code. . close( ) read( ) File. List sort. File. List( ) f. List create( ) fill. Document( ) add( ) delete( ) 1 Graphic. File. List rep File Repository (from Persistence) read( ) CASOS DE USO Grp. File name : char * = 0 read( ) read. Doc( ) open( ) read. File( ) create( ) fill. File( ) Use Case 1 Actor A VISTA DE PROCESO Use Case 2 Use Case 3 Actor B VISTA DE DESPLIEGUE ºÐ» ê ȯ°æÀÇ Çϵå¿þ¾î¹× ³×Æ®¿÷À¸·ÎÀÇ Á¤º¸ ½Ã½ºÅÛ ¿¬°á ¸ðµ¨ À©µµ¿ì 95 : Ŭ¶óÀ̾ðÆ® À©µµ¿ì NT: ÀÀ¿ë¼ ¹ö À¯´Ð½º ¸Ó½Å: ÀÀ¿ë ¼ ¹ö ¹× µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö IBM ¸ÞÀÎÇÁ·¹ÀÓ: µ¥ÀÌŸ ¼ ¹ö, Åë½Å ¼ ¹ö main. Wnd user ƯÁ¤¹®¼ ¿¡ ´ëÇÑ º¸±â¸¦ » ç¿ëÀÚ°¡ ¿äû ÇÑ´Ù. file. Mgr : document : File. Mgr Document g. File repository 1: Doc view request ( ) Windows 95 2: fetch. Doc( ) 3: create ( ) [yes] ¹®¼ °ü¸® Ŭ¶óÀ̾ðÆ®. EXE 4: create ( ) ¹®¼ °ü¸® ¾ÖÇø´ 5: read. Doc ( ) Windows NT È ÀÏ°ü¸®ÀÚ´ ÀÐ¾î¿ ¹®¼ ÀÇ Á¤º¸¸¦ÇØ´ç ¹®¼ °´Ã¼¿¡ ¼³Á¤À» ¿äû ÇÑ´Ù. 6: fill. Document ( ) Solaris 7: read. File ( ) ¹®¼ °ü¸® ¿£Áø. EXE 8: fill. File ( ) Alpha UNIX ÀÀ¿ë¼ ¹ö. EXE È ¸é°´Ã¼´ ÀоîµéÀÎ °´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î Á¤·ÄÀ» ½ÃÄÑÈ ¸é¿¡ º¸¿©ÁØ´Ù. 9: sort. By. Name ( ) Windows NT IBM Mainframe µ¥ÀÌŸº£À̽º¼ ¹ö Preparado por:

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

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

Mejores Prácticas en Desarrollo de Software Mejores Prácticas 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 Preparado por:

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 w Costo de reparar el software. w Costo de perder oportunidades. Costo w Costo de perder clientes Concepción Elaboración Preparado por: Construcción Transición

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. Preparado por:

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 Preparado por:

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 Preparado por: Verificación

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 Verificaciones Necesidades Producto Requisitos Revisiones Preparado por:

Jerarquía de planes Plan de Desarrollo Plan de Aseguramiento de la Calidad Plan de Pruebas (de software) Preparado por:

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

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

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 Preparado por:

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

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

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

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

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

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

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

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

Mejores Prácticas en Desarrollo de Software Mejores Prácticas 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 Preparado por:

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

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

Dificultades del Desarrollador: 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 Preparado por:

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

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

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. Preparado por:

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

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

Proceso basado en actividades ew N ! n f f o 2 B ti tug 6 6 Bu 8 s c a g 1 e g. F B 1 u 8 New widget g 1 s r 5 4 s u 1 1 x i ! o B n F f i f g x Bug 952 Bug 396 u Bug 953 a N 2 M B B u 4 r New Button New Script t 6 B e u gs 411 80 8 Buw g s T ! 6 f g FGU ug 62 o. Freix. Bt 5 u 8 f 1 1 New widget 1 w Bug 952 e Bugs 411 ix I 4 B g. B 8 u. Mg s g 611 N e Bu 8 New g 1 s 411 widget 8 r 5 u New x 0 i o B ! BMug F 2 B Bugs 411 widget f ug 6 Bug 951 6 f 8 u N t n ew W 11 New widget g s o u Bu i New Script eb G t e B r c g r a. New oix. N N phicssa. List F Windows 2000 BMS e 1 M e 8 New widget ug 4 w 5 n D x Bug 952 Fw i B a Bug 400 8 g. Script su. New Fix Bugs r. Button B Bug 396 0 959 u ugs 4 G B p 11 UNew p T o rt Iw Bug New DB Update 480 Buge Fix 196 N 950 support Doc I U G Preparado por:

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

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

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 Preparado por:

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. Preparado por:

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 ! Preparado por:

Gestión de Procesos ¿tenemos tiempo? …. Preparado por:

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

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) Preparado por: ISO 9000

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 Preparado por:

Los Ocho Principios de Gestión de la Calidad • • 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 Preparado por: ISO 9000

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

Gestión de Procesos • 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. Preparado por: ISO 9000

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

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 Preparado por: Información relacionada con el SEI: http: //www. sei. cmu. edu

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

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

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

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

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

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

Áreas Clave del Proceso de Software Coordinación Intergrupal (CI 3) CMM 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) Enfoque a Procesos de la Organización (EP 3) Admón. de Configuraciones (AC 2) Aseguramiento de la Calidad (QA 2) 5 Optimizado 4 Administrado 3 Definido/ Organización 2 Repetible/ Proyecto 1 A la medida Admón. de Subcontratistas (AS 2) Seguimiento a Proyectos (SP 2) Planeación de Proyectos (PP 2) Admón. de Requerimientos (AR 2) Preparado por: Niveles de Madurez de Capacidad del Proceso

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

RUP : Un Proceso Práctico de Desarrollo Responsabilidad de la Dirección RUP Gestión de los Recursos Medición, Análisis y Mejora Proceso de Software Realización del Producto 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 Preparado por:

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 Preparado por: RUP

Gracias Preparado por: