Estรกndares de Calidad Aplicados al Software M.C. Juan Carlos Olivares Rojas jcolivar@itmorelia.edu.mx
http://antares.itmorelia.edu.mx/~jcolivar/ @jcolivares
Febrero 2010
Competencias
• Conoce la importancia de la aplicación de estándares de calidad y productividad en el desarrollo de un software. • Genéricas • Instrumentales: Capacidad de análisis y síntesis, Capacidad de organizar y planificar, Comunicación oral y escrita en su propia lengua, Conocimiento de una segunda lengua, Habilidades de gestión de información, Toma de
Competencias
• Interpersonales: Capacidad de trabajar en equipo interdisciplinario, Compromiso ético. • Sistémicas: Capacidad de aplicar los conocimientos en la práctica, Habilidades de investigación, Capacidad de generar nuevas ideas (creatividad), Liderazgo, Capacidad para diseñar y gestionar proyectos, Iniciativa y espíritu emprendedor, Preocupación por la calidad, Búsqueda del logro.
Temario
• Introducción (Metodologías Ágiles/PSP/TSP) • • • • • • • •
ISO RUP ITIL CMM/CMMI MOPROSOFT Six Sigma Spice Métrica 3
Evidencias
• Actividades 10%
• Aplicación de Estándares de Calidad en el Proyecto 40% (dos metodologías por equipo de trabajo presentando resultados al final de la unidad en fecha aun por especificar) • Actividad Evaluadora Parcial 50%
Introducción
• En la unidad anterior, se vio la calidad en términos generales aun y cuando parte del material se enfocó al software. • En esta unidad se describen algunas metodologías de desarrollo de software que más que describirlas se trata de rescatar el enfoque de calidad que cada una de ellas trata de lograr.
Software Hoy en Día
• Mito: programadores ahora ya programan como de antes.
los de no los
• Herramientas más fáciles y productivas • El software es cada día más complejo
Desarrollo Ágil
• Se siguen desarrollando las mismas actividades del proceso de desarrollo de software, sólo difieren en la forma de hacerlo. • Las Metodologías Ágiles se fundamentan en 4 principios básicos (manifiesto ágil): • Al individuo y las interacciones en el equipo de desarrollo más que a las actividades y las herramientas.
Desarrollo Ágil
• Desarrollar software que funciona más que conseguir una buena documentación Minimalismo respecto del modelado y la documentación del sistema. • La colaboración con el cliente más que la negociación de un contrato. • Responder a los cambios más que seguir estrictamente una planificación.
Beneficios
โ ข Es mรกs adecuada para los cambios reduciendo los errores (costos) y logrando la satisfacciรณn de los clientes. Tradicional Costo del cambio
Suposiciรณn MAs tiempo
Método Tradicional vs. Ágil Metodología Ágil
Metodología Tradicional
Pocos Artefactos. El modelado es prescindible, modelos desechables.
Más Artefactos. El modelado es esencial, mantenimiento de modelos
Pocos Roles, más genéricos y flexibles
Más Roles, más específicos
No existe un contrato tradicional, debe ser bastante flexible
Existe un contrato prefijado
Cliente es parte del equipo de desarrollo (además in-situ)
El cliente interactúa con el equipo de desarrollo mediante reuniones
Orientada a proyectos pequeños. Corta duración (o entregas frecuentes), equipos pequeños (< 10 integrantes) y trabajando en el mismo sitio
Aplicables a proyectos de cualquier tamaño, pero suelen ser especialmente efectivas/usadas en proyectos grandes y con equipos posiblemente dispersos
La arquitectura se va definiendo y mejorando a lo largo del proyecto
Se promueve que la arquitectura se defina tempranamente en el proyecto
Énfasis en los aspectos humanos: el individuo y el trabajo en equipo
Énfasis en la definición del proceso: roles, actividades y artefactos
Se esperan cambios durante el proyecto
Se espera que no ocurran cambios de gran impacto durante el proyecto
Metodologías Ágiles
• Crystal Methodologies, Alistarir Cockburn, www.crystalmethodologies.org
• SCRUM, Ken Schwaber & Jeff Sutherland, www.controlchaos.com
• DSDM (Dynamic Systems Development Method), www.dsdm.org
Metodologías Ágiles
• FDD (Feature-Driven Development), Peter Coad & Jeff De Luca, www.nebulon.com/fdd, www.coad.com/peter/#fdd
• Extreme Programming, Kent Beck www.extremeprogramming.org, www.xprogramming.com • Adaptative Software Development, Highsmith www.adaptivesd.com
Jim
Metodologías Ágiles
• Las dos principales metodologías ágiles son scrum y XP (eXtreme Programming). • Cualquiera que fuera el método ágil debe de cumplir con el manifiesto ágil. • Scrum es certificable mientras que XP no lo es, pero muchos equipos de desarrollo la manejan ampliamente.
eXtreme Programming (XP)
• Es una metodología idónea para equipos de desarrollo pequeños menores a 10 personas. • Se caracteriza por ser una metodología “ligera” (excluye todo lo que no sirve dejando la esencia o “sabor” de las cosas). • Se centra en la implementación (codificación) por lo que es ideal para entornos dinámicos.
XP
• La comunicación se da de manera muy informal, generalmente verbal. • Las metodologías ágiles se preocupan por inculcar valores y XP no es la excepción, sus principales valores son: – Comunicación – Simplicidad – Retroalimentación – Coraje.
XP
• Los actores que participan en el desarrollo de software son: • Programador: responsable de decisiones técnicas y de construir el sistema. No hay distinción entre analistas, diseñadores o codificadores. Es decir, en XP los programadores modelan, codifican y prueban. • Clientes: son parte del sistema, determinar que construir y cuando, realizan test para determinar cuando algo está completo.
XP
• Entrenador (Coach): es el líder del equipo. Tiende a estar en un segundo plano a medida que el equipo madura • Rastreador (Tracker): también llamado Metric Man, se encarga de observar sin molestar, debe conservar datos históricos. • Probador (Tester): Ayuda al cliente con las pruebas funcionales.
XP
â&#x20AC;˘ El proceso de desarrollo en XP se puede resumir como: Mientras(sistema_es_Ăştil) { Captar requisitos User Stories Methaphor Planificar Release planning Iteration planning
XP
Desarrollar Programming Presentar la entrega Releasing }
• Puntos clave: el juego de planificación, entregas cortas, diseños simples, refactorización. LA GRAN FOTO
La gran foto
XP
• XP es una metodología muy utilizada pero como todo tiene también sus puntos débiles. Entre ellos que pocos son los que utilizan la metodología completa. • A continuación se muestran y se explican las prácticas que componen a la Programación Extrema. • XP no es sólo tirar líneas de código fuente.
Artefactos en XP
• Historias del Usuario
• Tareas de Ingeniería (bitácora de lo que se está realizando) • Pruebas de Aceptación • Pruebas Unitarias y de Integración • Plan de la Entrega • Código
Historia de Usuario Historia de Usuario Número: 1
Nombre: Enviar artículo
Usuario: Autor Modificación de Historia Número: Prioridad en Negocio: Alta (Alta / Media / Baja) Riesgo en Desarrollo: (Alto / Medio / Bajo)
Iteración Asignada: 2 Puntos Estimados:
Puntos Reales:
Descripción: Se introducen los datos del artículo (título, fichero adjunto, resumen, tópicos) y de los autores (nombre, e-mail, afiliación). Uno de los autores debe indicarse como autor de contacto. El sistema confirma la correcta recepción del artículo enviando un e-mail al autor de contacto con un userid y password para que el autor pueda posteriormente acceder al artículo.
Observaciones:
Spikes
Clima de Trabajo
• Espacio abierto
• Mesas centrales • Cubículos en el espacio exterior
Clima de Trabajo
• Reunión diaria: “Stand-up Meeting” – Todo el equipo – Problemas – Soluciones
• De pie en un círculo – Evitar discusiones largas – Sin conversaciones separadas
XP simple design CRC cards
spike solut ions prot ot ypes
user st ories values accept ance t est crit eria it erat ion plan
refact oring pair programming
Release sof t ware increment project velocit y comput ed
unit t est cont inuous int egrat ion accept ance t est ing
Adaptative Softwre Development adapt ive cycle planning uses mission st at ement project const raint s basic requirement s
Requirement s gat hering JAD mini-specs
t ime-boxed release plan
Release sof t ware increment adjust ment s f or subsequent cycles
component s implement ed/ t est ed focus groups for feedback formal t echnical reviews post mort ems
Tarea
• De su proyecto determinar el número de LOC, de ELOC y la productividad estimada (LOC/Hora) • Entrega miércoles 24 de Febrero de 2010. • Metodologías Asignadas: • E1: Víctor Hernández y David Sandoval: Scrum y CMM/CMMI
Tarea
• E2: Dante Solorio y Huber Duarte: Lean Software Development, Moprosoft • E3: María Guadalupe Orozco: FDD, ITIL • E4: José Coria y José CompetiSoft/EvalProsoft, Métrica 3 • E5: Carlos Fabie: Six Sigma, Spice
García:
Scrum
• Es otra metodología ágil que entre sus principales características están: • Desarrollo de software por medio de iteraciones (Sprints). • Indicado para proyectos con un rápido cambio de requerimientos. • Gran protagonismo de reuniones a lo largo del
Scrum
• Originada a finales de los 80’s se empezó a popularizar a mediados de los 90’s. En inglés americano se denomina melé y hace referencia a una jugada de rugby. • Los roles se dividen en cerdo y gallina para indicar el grado de participación en el proyecto.
Scrum
• Los actores que metodología son:
intervienen
• Propietarios del producto • Usuarios del poducto • Scrum master
en
esta
Scrum
Scrum
• Los sprints son la base del desarrollo en scrum, consisten
en
una
serie
de
actividades
previamente definidas en un lapso de 30 días.
• El product backlog es la lista de las tareas a realizar durante todo el proyecto. No es una lista fija. Se prioriza las tareas según los
requisitos de los usuarios o del propietario de la aplicación.
Scrum
Scrum
• Sprint planning meeting: reunión que se realiza antes de cada Sprint. • Se hace conjuntamente con el Propietario del producto el Scrum Master y el equipo Scrum. • Enfocar la reunión hacia los requisitos más prioritarios.
Scrum
• Revisión del sprint: se realiza al final de cada Sprint. • Se deben reunir el propietario de la aplicación los usuarios así como el Scrum Master y su equipo , además también es recomendable que acudan ingenieros de otros proyectos para dar su punto de vista.
• Product owner:
Scrum
• Definir la funcionalidad del producto • Decidir las fechas de liberación y el contenido (release) • Aceptar o rechazar el producto
Scrum
• ¿Quiénes son products owner? • • • • •
Analista Tester Usuario final Cliente Product Manager
Scrum
• Un rol de suma importancia metodología es el escuchar.
en
esta
• Muchos problemas de desarrollo se pueden solucionar fácilmente si se escucha a los clientes, usuarios finales y equipos de desarrollo.
Lean
• En una era donde ser esbelto es lo in , ¿podemos poner a dieta nuestros procesos de desarrollo de software? • No existe una definición formal de metodologías esbeltas simplemente se usan los principios del pensamiento ágil. Cada autor varía los principios manejados. A continuación se muestran algunos principios básicos.
Principios Lean
• Eliminar el desperdicio • Construir con calidad • Crear conocimiento • Postergar compromiso • Entregas rápidas • Repetar a las personas
Eliminar el Desperdicio
• Mito: Especificación temprana reduce el desperdicio • ¿Qué es desperdicio?
– Lo que no agrega valor – Retraso en la entrega – Funcionalidad no usada
• ¿Qué es valor?
– Ejemplos – Stock: Requerimientos, Diseño, Bugs, …
Construir con Calidad
• Mito: trabajo del tester es encontrar defectos • Inspección para prevenir o para detectar defectos • Listas de bug: desperdicio • Pruebas automatizadas antes que el código – De aceptación – Integración – Unitarias
Hacerlo bien a la primera
• Cuidado…
– El código cambia – Mucho código es desperdicio – Menos código, menos oportunidad de defectos
• Solución
– KISS – Refactoring
Crear Conocimiento
• Mito: las predicciones crean predictibilidad • No es posible
– Conocer las necesidades al inicio – Diseñar sin implementar
• Desarrollo de producto como aprendizaje y mejora – Del producto / negocio – Del proceso – Difundir el conocimiento!
Postergar Compromisos
• Mito: Planificación es compromiso • Tomar decisiones irreversibles • Buscar soluciones reversibles
Entregas rápidas
• Alta calidad • Bajo costo
• Menos cambios • Habilita a pruebas de concepto y mayor conocimiento del cliente
Respetar a las personas
• Mito: existe la mejor manera de hacerlo • Líderes emprendedores • Expertos técnicos • Control basado en objetivos
Optimizar el todo
• Mito: optimizar por descomposición • Ejemplos:
– El cliente quiere algo para ayer – Testing está sobrecargado
• Las cadenas de valor que cruzan entre empresas pueden ser costosas
OSSD
• Open Source Software Development es una metodología de desarrollo de software que comparte muchas características de los considerados métodos ágiles: primero las personas, entregables rápidos y pequeños, entre otros. • La parte de rigidez en el desarrollo de software al no estar tan marcada hace de esta metodología una opción no muy viable en cierto tipo de proyectos
FDD
• Feature-Driven Development (Desarrollo dirigido por características), es un proceso ágil para el desarrollo de sistemas. • Fue diseñado por Peter Coad, Eric Lefebvre y Jeff DeLuca. • No hace énfasis en la obtención de los requerimientos sino en como se realizan las fases de diseño y construcción.
FDD
• Propone tener etapas de cierre cada dos semanas. • Se basa en un proceso iterativo con iteraciones cortas que producen un software funcional que el cliente y la dirección de la empresa pueden ver y monitoriar. • El proceso consiste de cinco pasos secuénciales durante los cuales se diseña y se construye el sistema:
Proceso
Desarrollo de un Modelo Global
• Cuando comienza el desarrollo, los expertos del dominio están al tanto de la visión, el contexto y los requerimientos del sistema a construir. • Se divide el dominio global en áreas que son analizadas detalladamente. • Los desarrolladores construyen un diagrama de clases o de objetos por cada área.
Constr. Lista Funcionalidades
• Una funcionalidad es un ítem útil a los ojos del cliente. • La lista es elaborada por los desarrolladores y es evaluada por el cliente. • Se divide la lista en subconjuntos según la afinidad y la dependencia de las funcionalidades.
Característica/Rasgo
• Una carácterística o rasgo se formula en base al siguiente criterio: • <acción><resultado><objeto> • calcular el importe total de una venta • determinar la última operación de un cajero • validar la contraseña de un usuario.
Planeación por Funcionalidad
• En este punto se procede a ordenar los conjuntos de funcionalidades conforme a su prioridad y dependencia, y se asigna a los programadores jefes. • Diseño por funcionalidades y Construcción por funcionalidades:
– Se selecciona un conjunto de funcionalidades de la lista. – Se procede a diseñar y construir la funcionalidad mediante un proceso iterativo. •
Diseño y Constr. Funcionalidad
• Una iteración puede tomar de unos pocos días a un máximo de dos semanas. El proceso iterativo incluye inspección de diseño, codificación, pruebas unitarias, integración e inspección de código.
En conclusi贸n
Roles
• Está metodología se basa en muchos roles: claves, soporte y adicionales. • Entre los roles clave están: • Director del Proyecto – líder y administrador del proyecto
• Arquitecto Jefe – Encargado del modelado global de la aplicación
Roles
• Director de Desarrollo:
– Lleva diariamente las actividades de desarrollo. – Resuelve conflictos
• Programador en Jefe • Propietario de clases • Expertos de dominio
– Puede ser un usuario, un cliente, analista o una mezcla de estos.
Roles
– Poseen el conocimiento de los requerimientos del sistema. – Pasa el conocimiento a los desarrolladores para que se asegure la entrega de un sistema completo.
• Entre los roles de soporte se encuentran: • Gestor de Domino – Lidera el grupo de expertos del dominio
• Gestor de entregas
Roles
• Language Lawyer (Guru del Lenguaje)
– Posee un vasto conocimiento en un lenguaje específico de programación o tecnología.
• Ingeniero de construcción • Toolsmith / Herramentista
– Rol para la construcción de herramientas específicas para el desarrollo, conversión de datos y testeo. – Puede trabajar en la preparación y mantenimiento tanto de bases de datos o sitios web destinados al proyecto.
Roles
• Administrador del sistema
– Configura, administra y repara los servidores, estaciones de trabajo y equipos de desarrollo y testeo utilizados por el equipo.
• Entre los roles adicionales se encuentran: • Tester • Deployer
– Encargado de convertir información existente al nuevo sistema
Actividad
• Del proyecto encontrar/reformular los requerimientos para que cumplan con el criterio de carácterística en FDD. • Del listado de carácterísticas agruparlas y priorizarlas en iteracionesde dos semanas.
Proceso dX (RUP Ágil)
• Creado por Robert Martin. El proceso dx es una versión totalmente dócil del RUP. • El dX está diseñado para gente que tiene que usar el RUP pero quiere usar XP. • Esta metodología es un ejemplo claro de mezcla de metodologías.
Conclusiones
• Las metodologías ágiles no son nada nuevo bajo el sol. • Se tienen que “tropicalizar” las metodologías para su buen funcionamiento. • Existe una fuerte discusión en la academia sobre si enfocarse a las metodologías ágiles o no (al final de cuentas se debe entender el proceso).
Conclusiones
• El proceso de desarrollo de software es un proceso sociotecnológico. • Para poder aprender la metodología se necesita vivirla (se necesitan “horas de vuelo”). • Las metodologías ágiles son muy buenas cuando se domina el proceso en general.
Conclusiones
• Si el usuario final y/o clientes no colaboran es sumamente difícil aplicar la metodología. • Se debe aplicar métodos ágiles si se tienen procesos bien definidos pero no funcionan de manera adecuada frente a los campos o bien, el equipo de desarrollo no está a gusto. • Se siguen realizando el mismo proceso de desarrollo de software sólo cambia la forma.
Conclusiones
• No importa que metodología se utilice solo hay que llevarlo a la práctica como toda una verdadera disciplina. • La agilidad no cuesta. Lo único constante es el cambio. • A continuación se detalla una metodología de calidad enfocada en el área de la función informática para comprender las características básicas de las metodologías de
COBIT
• Control OBjective for Information & related Technology. • Es un marco de trabajo para la Gobernanza (Gobierno) de T.I • El término Governance hace referencia al sistema que implementa la alta gerencia para asegurar el logros de los objetivos de la empresa.
COBIT
• Cuando se habla de Gobierno de TI se hace mención a las relaciones y procesos necesarios para guiar a la empresa hacia sus objetivos organizacionales balanceando de forma adecuada el ROI (Retorno de Inversión). • Surge de la necesidad de que en antaño no existía ningún modelo de referencia para llevar acabo la administración de la función informática en las empresas.
COBIT
โ ข Se tienen cinco รกreas clave:
COBIT
• Los usuarios de COBIT son variados pero es útil para: • La alta gerencia • Los responsables de las TICs dentro de la empresa • Los usuarios de las TICs • Para los auditores
COBIT
• ¿Cómo se relaciona organizaciones?
COBIT
con
las
COBIT
• ¿Para que me sirve COBIT? Para planear, organizar, dirigir y controlar toda la función informática dentro de una empresa. Nos sirve de modelo de referencia. • COBIT está basado en estándares de organismos como
ISO
e
ISACA.
Tiene
una
fuerte
orientación hacia el negocio y hacia procesos.
COBIT
â&#x20AC;˘ Ayuda a estandarizar en la empresa:
COBIT
Figura 15 – El Cubo Cobit
• Se puede visualizar de mejor forma en un cubo:
ad d i ad d l i d i ib da m i n r r o fo gu sp n i e o D S C
S
PERSONAS
DE
TI
INFRAESTRUCTURA
APLICACIONES
PROCESOS
ACTIVIDADES
RE CU RS O
PROCESOS DE TI
DOMINIOS
INFORMACION
ci C on a fid e ad nc In ia te l gr id id ad
Ef ic ie n
Ef ic
ac ia
REQUERIMIENTOS DE NEGOCIO
COBIT
• Define un modelo de madurez para los procesos de Gobernanza de TI de las organizaciones similares a CMM: • • • • • •
0 Inexistente 1 Inicial 2 Repetible 3 Definida 4 Administrada 5 Optimizada
COBIT
• La estructura del estándar es la siguiente: RECURSOS DE TI • • • • •
datos sistemas de aplicación tecnología instalaciones gente
PLANEACON Y ORGANIZACION
MONITOREO ADQUISICION E IMPLEMENTACION
ENTREGA Y SOPORTE
COBIT
• PO1 Definición de un Plan Estratégico de Tecnología de Información • PO2 Definición Información
de
la
Arquitectura
•… • PO11 Administración de Calidad
de
COBIT
• AI1 Identificación Automatizadas • AI2 Adquisición y Software de Aplicación
de
Soluciones
Mantenimiento
• ... • AI6 Administración de Cambios
de
COBIT
• DS1 Definición de Niveles de Servicio • DS2 Administración de Servicios prestados por Terceros • ... • DS13 Administración de Operaciones
COBIT
• M1 Monitoreo de los procesos
• M2 Evaluar la Adecuación del Control Interno • M3 Obtener Garantía Independiente • M4 Proveer Auditoría independiente
• DS 2.3 tarea).
COBIT
Contratos con terceros (actividad o
• Objetivo de control: “La gerencia debe definir procedimientos específicos para asegurar que un contrato formal es definido y acordado para cada relación de servicio con un proveedor”.
• 4 dominios
COBIT
• 34 procesos • 318 objetivos de control
COBIT Gente
Instalaciones
Tecnología
Sistemas de información
Datos
Recursos
Efectividad
Confidencialidad Integridad El proceso de planeación debe tomar en consideración los requerimientos de integridad de datos
Disponibilidad Cumplimiento
Requerimientos
Eficiencia
Confiabilidad de la información
s io (p s so ce ro
Planeación y organización
in m
Adquisición e implementación
Do
Monitoreo Prestación de servicio y soporte
)
Roles en COBIT
• Más que roles o definir una descripción de puestos propone funciones que se deben de cumplir dentro de una organización: • • • • • •
CEO (Director Ejecutivo) CFO (Director de Finanzas) Ejecutivo del Negocio CIO (Director de Informática) Dueño del proceso de negocio Jefe de Operaciones
• • • • •
Roles en COBIT
Arquitecto en Jefe Jefe de Desarrollo Jefe de Administración de TI PMO (Director de Proyectos) Cumplimiento, Auditoria, Seguridad.
Riesgo
y
• En algunos procesos en particular se manejan roles exclusivos como en DS que se llega a manejar el rol de “help desk”
Personal Software Proccess
• Watts S. Humphrey es el inventor del PSP (Personal Software Process) y el TSP (Team Software Process). • PSP se utiliza cuando no existe un equipo de programadores (un solo desarrollador). • Es un proceso de mejora continua. Está diseñado para que se realicen varias pruebas antes de liberar el producto.
PSP
• ¿Por qué surgen las metodologías de desarrollo de software personal? • Por que cada Ingeniero es diferente. • Para lograr la mejora continua se necesita que cada Ingeniero debe tener procesos bien definidos y cuantificados. • Para lograr la calidad de software cada desarrollador debe de asumir las responsabilidad de hacer su trabajo con calidad.
PSP
• Metodologías del SEI CMU
CMM
TSP
Organización
Equipos
Personas PSP
Proceso del PSP
PSP
• Consta de varias tareas que el programador tiene que realizar repetidamente. • Para tener una buena calidad se requiere de tener métricas de calidad bastante elevadas, esto es, aproximadamente un error por cada mi líneas de código. • El cuaderno de ingeniería (bitácora) es el elemento clave de esta metodología.
PSP
• Las diferentes etapas del PSP son: • Proceso base: el programador conoce las necesidades del cliente para tener una idea clara de lo que programará. • Ambiente de mejora: en caso de tener un proyecto ya hecho esta es la etapa de depuración, se utiliza para mejorar el proyecto anterior.
PSP
• Estimación de tamaño de proyecto, pruebas: en caso de ser un proyecto nuevo se estima el tamaño que tendrá el software. Tomando en cuenta el tiempo que se le dedicará y las especificaciones del cliente. • Plantación de tareas y horario: ya teniendo el tamaño del software se puede hacer una estimación del tiempo que se tomará para hacer la programación, así como, las diferentes tareas.
PSP
• Se debe realizar un horario para tomar en cuenta cuanto tiempo debe tomar cada tarea y terminar a tiempo. • Control de calidad personal: por medio de pruebas se califica la eficiencia del sistema así como los errores que pueda llegar a tener, se tiene que confirmar que la calidad del software es la deseada.
PSP
• Proceso Cíclico: teniendo en cuenta la calidad con la que el programa será liberado se decide si el software se liberara o tiene que volver a entrar en el proceso como proceso base. • El problema mas grande que se presenta con el PSP es que para los programadores es difícil tratar de visualizar todas las tareas y etapas del desarrollo.
Actividades de PSP
• Desarrollar un plan para cada proyecto y/o componente. • Registrar su tiempo de desarrollo. • Registrar sus defectos • Conservar sus datos en informes del proyecto
Actividades de PSP
â&#x20AC;˘ Utilizar sus datos para planear los proyectos y/o los componentes futuros. â&#x20AC;˘ Analizar sus datos para desarrollar sus procesos con mas calidad para mejorar su funcionamiento.
Niveles de Madurez de PSP
PSP
• Hasta estos momentos se ha realizado de manera informal el nivel PSP0. • Se necesita hacer reingeniería al proceso actual para poder evolucionar a la parte 1. • Necesitamos codificación.
estandarizar
errores
y
estilos
de
Ejercicio PSP
• Se necesita realizar un software que en base a métricas de software pueda determinar rendimientos de programadores. Programador
LOC ELOC Otros Métodos
1 2 3 4 5
66 41 68 90 75
20 10 5 34 12
… … … … …
1 2 8 5 14
Ejercicio PSP
• Los programadores pueden ser diversos al igual que las métricas (de manera predeterminada hay tres). • Se deberá calcular quién es el mejor programador considerando
la
siguiente
fórmula
empírica
(LOC/ELOC)-(Methods*0.1). • El mejor programador es aquel que tiene la métrica más baja siempre y cuando sea >0
Ejercicio PSP
• Para determinar la mejor pareja, se necesita aplicar la siguiente fórmula: • mejorPareja(P1, P2) = |p1.prop1-p2.prop1| + |p1.prop2-p2.prop2| + … + |p1.propnp2.propn| • El programa deberá tener una interface gráfica en forma de tabla. • Realizar la planeación personal de este
Ejercicio PSP
• En PSP la gestión del tiempo es de suma importancia. Es el único recurso que no se puede recuperar. • Implementación de la solución con todos los aspectos planeados. Tomar tiempos en base al formato dado del cuaderno de ingeniería. • Comprobar que tan efectiva fue la estimación que realizamos en la planeación.
Formato PSP
Formato PSP
Formato PSP
â&#x20AC;˘ CPI: precio de la actividad. Por ejemplo se pagan $100 por cada 25 LOC/hora. â&#x20AC;˘ %Nuevo reusado es el conjunto de nuevas APIs realizadas. Para ello considerar el siguiente formato.
Formato PSP
Formato PSP
• LOC Base. Programa Original
• LOC Modificado. Líneas de Código Modificadas • LOC Suprimido. Línea de códigos eliminadas
Formato PSP
• Nuevo y cambiante. Cuando se crean nuevas funcionalidades a un programa (note que no es ni modificado ni suprimido). • Reutilizado. Código que se toma de una biblioteca realizada por nosotros • LOC Total = Base - Suprimido + Agregado + Reutilizado
Defectos
• Es quizás la métrica por excelencia para determinar si un producto es de calidad o no (sobre todo cuando se ve la calidad desde un enfoque costo-efectivo/libre de errores). • Un defecto es una desviación de un producto o proceso de la norma estándar dada en un rango.
Defectos
• Si la norma es +/- 0.5 cm en un pantalón en su largo y una pieza tiene una desviación de 0.6 cm, dicho producto está fuera de la norma. • Desde el punto de vista de satisfacción del cliente, un defecto es que al cliente no le guste el producto. Desafortunadamente esta métrica es demasiado cualitativa. • ¿Qué es un defecto de software?
Defectos
• El IEEE Standard 100-1992 define un defecto como una “anomalía del producto”. • ¿Es lo mismo error que defecto? • En general se maneja el mismo término en Software aunque está más extendido el término fallo.
Defectos
• Desde el punto de vista económico de la calidad, un defecto es todo aquello que tiene un costo negativo en la producción o en el producto una vez terminado. • En términos generales los defectos tienen un costo y son sinónimo de incompetencia.
Defectos
• Algunos estudios indican que las actividades del diseño introducen entre el 50 al 65% de todos los errores durante el proceso de software. • Sin embargo, se ha demostrado que las revisiones técnicas formales son efectivas en un 75% a la hora de detectar errores. • ¿Qué es una revisión técnica formal?
Revisiones Técnicas Formales
• Las revisiones del software son un “filtro” para el proceso de ingeniería del software. Esto es, las revisiones se aplican en varios momentos del desarrollo del software y sirven para detectar errores y defectos que pudieran así ser eliminados. • Las revisiones del software sirven para “purificar” las actividades de ingeniería del software que suceden como resultado del análisis, el diseño y la codificación.
Revisiones Técnicas Formales
• El trabajo técnico necesita ser revisado por la misma razón que los lápices necesitan gomas: errar es humano. • La segunda razón por la que necesitamos revisiones técnicas es que, aunque la gente es buena descubriendo algunos de sus propios errores, algunas clases de errores se le pasan por alto más fácilmente al que los origina que a otras personas.
Revisiones Técnicas Formales
• Al igual que los filtros de agua, las RTF's (Revisión Técnica Formal) tienden o retardar el “flujo” de las actividades de ingeniería del software. • Es importante recalcar que las RTFs no son pruebas. El proceso de pruebas y depuración es una actividad independiente y necesaria para el desarrollo de un producto.
Revisiones Técnicas Formales
• Algunas formas de revisión informal son: • Reunión • Presentación
• Una forma de encontrar y detectar errores es la amplificación de los mismos. Poner filtros más altos en las especificaciones (por ejemplo activar los warnnigs como errores) es una buena manera de eliminar defectos.
Revisiones Técnicas Formales
• Patrones de Falla
Revisiones Técnicas Formales
• Sobresimplificación
Tipos de Errores
• Sobre ejecución bajo presión • Fallas funcionales • Fallas en cascada • Fallas de coordinación:
Manejo de Errores en PSP
Actividad
• Continuar con lo previsto en su planeación personal. • Agregar el formato de errores encontrados (etapa de compilación)
PSP
• ¿Realmente se ahorra tiempo con PSP? • Si, dado que al haber menos errores se eficientiza todo el proceso. • Es necesario como para casi cualquier actividad el trabajo en Equipo que con las técnicas anteriormente descritas no nos sirve.
Equipos de Trabajo
• Es uno de los pasos más importantes del proceso de planeación. • Debe existir acuerdo en la selección de las herramientas y metodología para evitar ineficiencias que impidan al equipo de trabajo progresar y concebir el objetivo deseado.
Equipos de Trabajo
• Las características deseables de un equipo de trabajo son: 1. Debe de haber un líder. 2. Los miembros del equipo deben de ser creíbles y acreditados. 3. Los miembros del equipo deben entender y estar de acuerdo con las metas. 4. Debe existir múltiple cooperación y compañerismo.
Equipos de Trabajo
â&#x20AC;˘ Se debe tomar en cuenta:
1. Determinar las tareas a llevar a cabo. 2. Estimar esfuerzos. 3. Estimar el numero de gente requerida. 4. Especificar los roles y responsabilidades de
Equipos de Trabajo
5. Seleccionar el personal apropiado con las tareas y trabajos a llevar a cabo con el paso de la metodologĂa. 6. Sesiones de entrenamiento y capacitaciĂłn requerida al hacer comprender la metodologĂa. 7. Tener un espacio de trabajo. 8. Seleccionar consultas externas
Equipos de Trabajo
• Algunos problemas de trabajar en equipo: • Liderazgo poco efectivo • Falta de compromiso/coperación • Falta de participación • Procrastinación
TSP
• En muchas ocasiones se necesita de otros programadores para terminar un proyecto, pero al estar más de uno no se puede utilizar el proceso de software personal, este problema se soluciona formando un equipo de trabajo y llevando a cabo el desarrollo por medio de TSP. • TSP, en conjunto con PSP, ayuda al Ingeniero de Software a mejorar la calidad tanto del proceso como del producto de software.
TSP
• Conjunto de procesos definidos y estructurados para formar y guiar equipos de ingenieros que desarrollan Software. • TSP = PSP + Desarrollo Organizacional + Teoría de Grupos/Equipos + Control Estadístico de Procesos + Admón. de Proyectos + Enfoque de Procesos.
TSP
• Equipos de 3 a 15 miembros (recomendable de 5 a 10) • Los miembros deben saber PSP. • Diseñado para ayudar a:
– Formación de equipos – Administración del Equipo – Formación de equipos objetivos – Asignación de Roles
Definición
de
TSP
• Diseñado para ayudar a:
– Definir/Ajustar el proceso del equipo – Planeación detallada y balanceada – Administración del Equipo Comunicación – Coordinación Control del proyecto – Análisis de Riesgos
• Los proyectos TSP son dirigidos por el equipo. Esto es, el equipo se administra así mismo.
TSP
• Cada miembro del equipo es responsable de: • Planea y le da seguimiento al progreso de su trabajo • Administra la calidad de su trabajo • Trabaja agresivamente objetivos del equipo.
para
lograr
los
TSP
• El equipo también debe mostrarle a los gerentes y al cliente que el equipo se auto-administra. • Reporta constantemente el avance y el status del proyecto • Anticipa, planea acciones concretas, y hace reportes sobre los riesgos que conlleva el proyecto
TSP
• Los planes detallados tanto del equipo como de cada miembro del equipo facilitan un seguimiento preciso del avance del proyecto. • Cada miembro del equipo es responsable de:
– Recolectar los datos (métricas) de sus actividades – Verificar que su plan de trabajo se vaya cumpliendo
TSP
• Cada miembro del equipo es responsable de:
– Mantener informado al equipo – Cada miembro del equipo también es responsable de la calidad del trabajo que produce
• El proceso consta de 4 etapas y de los procesos de lanzamiento (sesiones en equipo inicial), relanzamiento (sesiones intermedias) y análisis postmortem.
TSP
TSP
โ ข Composiciรณn de un launch
• Roles en TSP:
TSP
• Gerente de Interfase con el Usuario • Gerente de Diseño • Gerente de Implementación • Gerente de Planeación • Gerente de Procesos • Gerente de Calidad • Gerente de Soporte Técnico • Gerente de Pruebas
Resultados de PSP/TSP
â&#x20AC;˘ Una empresa Nivel 5 de CMM logro:
CMM
• No todo es trabajar en equipo ni de manera personal. Se
necesita definir una estructura organizacional que permita el desarrollo de software.
• CMM (Modelo de Madurez de Capacidades) ayuda en esta parte al brindar un marco de trabajo de mejores prácticas a nivel organizacional.
• La madurez de un proceso indica el grado de dominio que se tiene del mismo
CMM
â&#x20AC;˘ Niveles de Madurez. TambiĂŠn debe incluir el Nivel 0 sin madurez. Mejoramiento continuo de procesos Proceso predecible
Proceso estĂĄndar y consistente Proceso disciplinado
Administrado (4)
Definido (3)
Repetible (2)
Inicial (1)
Optimizando (5)
CMM
• Para medir el grado de madurez se necesita de métricas lo que en esta metodología son los KPA (Key Process Area). • Nivel 1 Inicial: Proceso hecho a la medida y dependiente de “heroes”. No existen KPA • Nivel 2 Repetible: Proceso intuitivo y dependiente de los individuos: Admon. Requerimientos, Planificación de Proyectos, Seguimiento y Control de Proyectos,
CMM
• Administración de la configuración, Admon. de subcontractos. • Nivel 3 Definido: Proceso definido e institucionalizado. KPA: Enfoque a procesos. Definición de Procesos. Programas de Entrenamiento. Administración Integrada del Software. Coordinación entre grupos. Revisiones de pares.
CMM
• Nivel 4 Administrado: proceso medido y administrado cualitativamente. KPA: Administración cuantitativa del proceso, admon. de la calidad del software. • Nivel 5 Optimizado: Proceso continuamente mejorado. KPA: Prevención de defectos. Admon. Del cambio tecnológico. Admon del proceso de cambio (mejoramiento continuo).
CMM
• Cada KPA tiene su objeto principal así como indicadores de cumplimiento sugerido. Ejemplo • Administración de Requerimientos. • Objetivo: Determinar el estado actividades de administración requerimientos.
de de
las los
• Indicadores:
CMM
– Estado de cada requerimiento aprobado. – Actividades de cambio de cada requerimiento especificado. – Cantidad de cambios acumulados para los requerimientos aprobados, incluyendo el total de cambios propuestos, abiertos, probados e incorporados a la baseline del proyecto.
• A nivel mundial se tienen: 75% empresas Nivel 1, 15% Nivel 2, 10% Nivel3, 5% Nivel 4 y <1% del total de
CMM
• La madurez va enfocada a la organización, mientras que la capacidad va orientada hacia los procesos. • CMMI (CMM mejorado) trae muchas mejoras a CMM integrando otros frameworks (desarrollo, adquisición y servicios). Permitiendo que todas las empresas de TI se puedan integrar en el mismo modelo.
CMM
• Otras de las carácterísticas de CMMI es su flexibilidad al momento de evaluar procesos. Mientras en CMM si todas las categorías son nivel 5 y se tiene una nivel 3 el desempeño general es de 3. En CMMI se pueden tener multiniveles en diferentes partes del proceso (proceso escalonado). • Se puede medir CMMI a través de Standard CMMI Appraisal Method for Process Improvement (SCAMPI).
MOPROSOFT
• Modelo de PROcesos para la industria del SOFTware es la norma oficial mexicana (NMX-059/01-NYCE-2005) para el desarrollo de aplicaciones. • Es una versión ligera de CMMI adaptada a las necesidades de la Industria del Software en México. • Deriva del proyecto federal PROSOFT. Se publicó por vez primera en 2002
MOPROSOFT
â&#x20AC;˘ Se divide en tres procesos generales:
MOPROSOFT
• Se tiene una fácil y rápida integración hacia CMMI
para
el
caso
de
con
el
certificaciones
internacionales. • Actividad: propuesto.
seguir
plan
personal
SEMAT
• Software Engineering Method and Theory es una propuesta de los principales investigadores sobre Ingeniería del Software por tratar de mejorar las prácticas de está disciplina. • Entre las problemáticas encuentran:
a
resolver
se
• La Ing. Del Sw son más prácticas de modas que una verdadera disciplina de ingeniería.
SEMAT
• Falta de consenso en fundamentos básicos. • La gran variedad de métodos, técnicas y metodologías que realmente no se autodistinguen. • La falta de evaluación y experimental realmente creíble
validación
SEMAT
• La división de las prácticas industriales de la investigación académica. • Se propone la construcción de un kernel donde todos los métodos y técnicas estén basados en prácticas y patrones ya establecidos con anterioridad. • Se manejan 13 principios básicos: – Calidad – Simplicidad
SEMAT
– Teoría – Realismo y escabilidad – Justificación – Falsabilidad – Perspectiva hacia delante – Modularidad – Automejora – Abierto – Rectitud – Objetividad – Oportunidad
Tendencias Desarrollo Sw
• Cómputo en la nube • Web como plataforma • Cómputo paralelo
• Dispositivos conectados • Procesos ágiles
Métrica 3
• Primer metodología de desarrollo 100% en español. Es una metodología realmente internacional (aunque es norma oficial española). • Adpatada del método estructurado de DeMarco & Yourdon, así como de SSADM (Structured System Analysis and Design Methodology) y MERISE • Está estructurada en procesos, actividades y
Métrica 3
• Los procesos están definidos en procesos principales (planificación, desarrollo y mantenimiento) y procesos de interfaz (calidad, seguridad, gestión y configuración) • En cada etapa hay entregables como código y documentación.
Factores de Calidad de McCall
Estรกndar ISO 9126
SPICE
• Software Process Improvment and Capability dEtermination, es una metodología para la evaluación de procesos de software definida en el estándar ISO/IEC 15504. • Maneja una escala de valores donde van más allá de ser si o no. No 0
Parcial 15 16
Adecuado 50 51
Completo 85 86 100 %
SPICE Proceso
Identifica cambios a
Es evaluado por Evaluaci贸n del Proceso
Gu铆a a Mejoramiento del Proceso
Identifica capacidad y riesgos del Gu铆a a
Motiva
Determinaci贸n de Capacidades
SPICE Parte 1
Parte 9
Conceptos y guía introductoria
Vocabulario
Parte 7
Parte 8
Parte 6
Guía para la mejora de procesos
Guía para la determinación de la madurez de los procesos de proveedores
Guía para la cualificación de los evaluadores
Parte 3
Parte 4
Realizando una evaluación
Guía para realizar evaluaciones
Parte 2
Parte 5
Un modelo de referencia para procesos y madurez de procesos
Un modelo de evaluación y directrices
SPICE
Procesos Primarios CUS.1 Adquisición -Preparar adquisicón -selecc proveedor -confrolar proveedor -aceptación del cliente
Procesos de Soporte
CUS.2 Suministro
SUP.1 Documentación
CUS.4 Operación
SUP.2 Gestión de la Configuración
Uso operacional Soporte al cliente
CUS.3 Obtención de Requerimientos ENG.1 Desarrollo -An.Reqs. y diseño SIS -Construir SW -Integrar y -An. Reqs. SW -Integrar SW probar SIS -Diseño SW -Probar SW
SUP.3 Aseguramiento de la Calidad SUP.4 Verificación SUP.5 Validación SUP.6 Revisión Conjunta SUP.7 Auditoría SUP.8 Resolución de Problemas
ENG.2 Mantenimiento SIS y SW Procesos Organizativos MAN.1 Gestión MAN.2 Gestión de proyecto
ORG.1 Alineamiento con la organización ORG.2 Mejora -establecer procesos - evaluarlos -mejorarlos
MAN.3 Gestión de la Calidad
ORG.3 Gestión de recursos humanos ORG.5 Infraestructura ORG.5 Medición
MAN.3 Gestión de Riesgos
ORG.6 Reuso
SPICE
โ ข Ejemplo de Evaluaciรณn Process
Process Atttributes Performed Managed Established Predictable 1.1
2.1
2.2
3.1
3.2
4.1
4.2
Level 5.1
5.2
Requirements elicitation
2
Customer Support
2
Software Design
3 3
Software construction Software testing
3 Fully Achieved Partially Achieved
Largely Achieved Not Achieved
PC2
• Programming Contest Control es un software basado en Java para la realización de los concursos de programación de la ACM realizado por la universidad de California en Sacramento. • Se puede descargar del sitio http://www.ecs.csus.edu/pc2/
oficial:
• Al descomprimir el archivo se deberá copiar el
PC2
• En el archivo pc2v9.ini se guardan las configuraciones básicas de donde se encuentran los servidores (puerto y dirección IP) en el caso de ejecutar el servidor se puede dejar en localhost. Para los clientes, es necesario colocar la dirección IP o nombre de dominio del servidor. El puerto predeterminado es el 50002. • El primer proceso en ejecutar será pc2server
PC2
• Los archivos *.bat son para Sistemas Windows (revisar configuración de Java) y los shellscripts para cualquier sistema *X (Unix, Linux, Mac OS X). • La contraseña del servidor es site1 y el password es site1. Se pedirá que definan una contraseña para el concurso. Favor de no perderla ya que si no, no se podrá ejecutar el sistema.
PC2
• El siguiente proceso a correr es el administrador: pc2admin. Si se corre en consola favor de pasar el argumento & para que el proceso se ejecute en el transfondo. • La contraseña es administrator1 al igual que el password. En el sistema de administración se pueden configurar muchas cosas que a continuación se describen.
PC2
• En cuentas habrá que definir el número de cuentas a utilizar: por default ya se cuenta con una cuenta de administrador pero será necesario definir al menos una cuenta de jueces, tablero y equipos (número de participantes). Se pueden cambiar el nombre y password aunque para fines prácticos se dejarán igual. • Se habilitará la opción de juez automático. Si se deja deshabilitado (opción predeterminada) se deberá hacer un jueceo manual.
PC2
• El jueceo automático se basa en archivos tanto de entrada como de salida. • La opción de lenguajes es otra que se debe de activar. Ya existen algunos lenguajes predeterminados, sino existe se deberá indicar en la máquina servidora donde existe el compilador y las demás herramientas de desarrollo. • Se manejará lenguaje Java y ANSI C.
PC2
• La configuración de los problemas se da en el apartado de problemas. Aquí se deberá indicar lo siguiente: • • • • • •
El nombre del problema El tiempo (predeterminado de 120 segundos) La entrada, activarla por archivo El archivo de resultados El tipo de jueceo deberá ser automático El validador a aplicar será diff
PC2
• La última opción dentro de la configuración será el manejo de tiempos. En esta misma opción se puede iniciar el concurso. • Es necesario ejecutar los procesos de jueces, tablero, equipos y por último arrancar el concurso. • La contraseña para el juez (pc2judge) es judge1 al igual que el password. No se configura nada.
PC2
• Para el tablero (pc2board) el usuario es scoreboard1 al igual que la contraseña. Tampoco hay configuración importante aquí • Finalmente hay que correr las versiones cliente: team1 en nombre de usuario y contraseña para el equipo1. • En el cliente se deberá indicar el problema, el lenguaje y anexar los archivos de código
PC2
• Se cuenta con la opción de test que permite verificar si el programa compila de forma adecuada en nuestra máquina (para no gastar un intento). • Otra de las utilidades a manejar es pc2ver que indica la versión del sistema y pc2reset que se deberá ejecutar cuando se quiera correr otro concurso.
PC2
• //Lectura de datos en Java • BufferedReader br = new BufferedReader (new InputStreamReader (System.in), 1) • int num = Integer.parseInt(br.readLine()); •… • //Salida de datos • System.out.println(resultado); • //IMPORTANTE: Verificar como debe de ir la salida de datos
ITIL
• Biblioteca de Infraestructura de Tecnologías de la Información, de origen inglés después estandarizada a nivel munidal, es el conjunto de lineamientos sobre la administración y procuración de servicios operativos de TI. • Cuenta con cinco procesos clave: – Manejo de incidentes – Manejo de problemas – Manejo de configuraciones
– Manejo de cambios – Manejo de entregas
ITIL
• Cuenta con 8 libros:
– Entrega de Servicios – Servicio de Soporte – Gestión de la infraestructura de TI – Gestión de la seguridad – Perspectiva de negocio – Gestión de aplicaciones – Gestión de activos de software
ITIL
• También se tiene el libro de implementación en pequeña escala.
ITIL
• La parte más importante son los centros de servicio (Service Desk), ya que sirven de punto de enlace entre los usuarios y la gestión de servicios de TI aunque también se realizan todos los demás procesos: incidentes, problemas, gestión del cambio, configuraciones. • Para lograr la calidad en los servicios se deben establecer previamente los SLA (Service
• Los centros de conformados por:
ITIL
servicios
pueden
• Call center: concentran canalizando a la parte respectiva
estar
llamadas
• Help Desk (Centro de Soporte): primera línea de soporte técnico. • Los service desk pueden ser centralizados,
ITIL
• ITIL es certificable a nivel personal en tres niveles: • Foundation (básico) • Practicioner (intermedio, conocimiento en el diseño de procesos) • Manager (avanzado, dirección de TI)
Six Sigma
• Originada por Motorola e implementada después con éxito por General Electric está enfocado al control estadístico de la calidad en la cual los procesos deben de estar dentro del rango de 6 desviaciones estándar: 3.4 defectos por millón ó 99.99996% de efectividad. • Es un marco de trabajo que incluye métricas y una filosofía de trabajo muy en particular.
Six Sigma
• Los niveles jerárquicos importancia son:
en
orden
• Lead Black Belts • Campeón (Champion) • Maestro Cinta Negra (Master Black Belt) • Cinta Negra (Black Belt) • Cinta Verde (Green Belt)
de
Six Sigma
• El proceso en Six Sigma es DMAIC: • • • • •
Definir Medir Analizar Mejorar Controlar
• Variantes: DMADV = (Definir, Analizar, Diseñar y Verificar)
Medir,
Six Sigma
• Se utilizan muchas herramientas estadísticas como: – Diagrama de Flujo de Procesos – Diagrama de Causa-Efecto – Diagrama de Pareto – Histograma – Gráfica de Corrida – Gráfica de control – Diagrama de Dispersión –
OpenUP
• Originado como resultado de la compra de Rational creador de RUP por parte de IBM. • UP es toda una metodología para el desarrollo de software: Requisitos del usuario
Proceso de desarrollo de software
Sistema de software
• Se caracteriza por ser una forma disciplinada de asignar tareas y responsabilidades en una empresa de
OpenUP
• Su objetivo es Asegurar la producción de software de calidad dentro de plazos y presupuestos predecibles. Dirigido por casos de uso, centrado en la arquitectura, iterativo (mini-proyectos) e incremental (versiones). • También es considerado un producto: • Desarrollado y mantenido por la comunidad libre • Actualizado constantemente para tener en cuenta las mejores prácticas de acuerdo con la experiencia.
OpenUP
• Aumenta la productividad de los desarrolladores mediante acceso a: • Base de conocimiento, plantillas y herramientas.
• Se centra en la producción y mantenimiento de modelos del sistema más que en producir documentos. • UP es una guía de cómo usar UML de la forma más efectiva. • Existen herramientas de apoyo a todo el proceso: Modelamiento visual, programación, pruebas, etc.
OpenUP
• UP pretende implementar las mejores prácticas actuales en ingeniería de software: • • • • • •
Desarrollo iterativo del software Administración de requerimientos Uso de arquitecturas basadas en componentes Modelamiento visual del software Verificación de la calidad del software Control de cambios
OpenUP
• Desarrollo Iterativo:
• El software moderno es complejo y novedoso. No es realista usar un modelo lineal de desarrollo como el de cascada. • Un proceso iterativo permite una comprensión creciente de los requerimientos a la vez que se va haciendo crecer el sistema. • UP sigue un modelo iterativo que aborda las tareas más riesgosas primero. Con esto se logra reducir los riesgos del proyecto y tener un subsistema ejecutable
OpenUP
• Administración de Requerimientos: • Obtener los requerimientos • Organizarlos • Documentar requerimientos de funcionalidad y restricciones • Rastrear y documentar decisiones
OpenUP
• Arquitectura basada en Componentes: • El proceso se basa en diseñar tempranamente una arquitectura base ejecutable. • • • • •
La arquitectura debe ser: Flexible Fácil de modificar Intuitivamente comprensible Promueve la reutilización de componentes
OpenUP
• Modelamiento visual de la estructura y el comportamiento de la arquitectura y los componentes. • Bloques de construcción: • Ocultan detalles • Permiten la comunicación en el equipo de desarrollo • Permiten analizar la consistencia: • entre las componentes • entre diseño e implementación
OpenUP
• Verificación de la calidad:
• No sólo la funcionalidad es esencial, también el rendimiento y la confiabilidad. • UP ayuda a planificar, diseñar, implementar, ejecutar y evaluar pruebas que verifiquen estas cualidades. • El aseguramiento de la calidad es parte del proceso de desarrollo y no la responsabilidad de un grupo independiente.
OpenUP
• Control de Cambios:
• Los cambios son inevitables, pero es necesario evaluar si éstos son necesarios y rastrear su impacto. • UP indica como controlar, rastrear y monitorear los cambios dentro del proceso iterativo de desarrollo.
OpenUP
• UP divide el proceso de desarrollo en ciclos, teniendo un producto al final de cada ciclo. • Cada ciclo se divide en cuatro Fases: • • • •
Inicio Elaboración Construcción Transición
• Cada fase concluye con un hito bien definido donde deben tomarse ciertas decisiones.
• Fases de UP
OpenUP
• Fase de Inicio
OpenUP
• Se establece la oportunidad y alcance el proyecto. • Se identifican todas las entidades externas con las que se trata (actores) y se define la interacción a un alto nivel de abstracción: • Identificar todos los casos de uso • Describir algunos en detalle
OpenUP
• La oportunidad del negocio incluye: • • • •
Criterios de éxito Identificación de riesgos Estimación de recursos necesarios Plan de las fases incluyendo hitos
– Productos: – Un documento de visión general: • • • • •
Requerimientos generales del proyecto Características principales Restricciones Modelo inicial de casos de uso (10% a 20 % listos). Glosario.
• Caso de negocio: • • • •
OpenUP
Contexto Criterios de éxito Pronóstico financiero Identificación inicial de riesgos.
• Plan de proyecto. • Uno o más prototipos.
OpenUP
• Hito: Objetivos del Ciclo de Vida
Inicio
Elaboración
Construcción
Transición
– Las partes interesadas deben acordar el alcance y la estimación de tiempo y costo. – Comprensión de los requerimientos plasmados en casos de uso.
OpenUP
• Fase de Elaboración • Objetivos: • • • •
Analizar el dominio del problema Establecer una arquitectura base sólida Desarrollar un plan de proyecto Eliminar los elementos de mayor riesgo para el desarrollo exitoso del proyecto
• Visión de “una milla de amplitud y una pulgada de profundidad” porque las decisiones de arquitectura requieren una visión global del sistema.
• Productos:
OpenUP
• Es la parte más crítica del proceso • Se puede decidir si vale la pena seguir adelante • A partir de aquí la arquitectura, los requerimientos y los planes de desarrollo son estables. • Ya hay menos riesgos y se puede planificar el resto del proyecto con menor incertidumbre.
OpenUP
• Se construye una arquitectura ejecutable que contemple: • Los casos de uso críticos • Los riesgos identificados • Modelo de casos de uso (80% completo) con descripciones detalladas. • Otros requerimientos no funcio-nales o no asociados a casos de uso. • Descripción de la Arquitectura del Software.
OpenUP
• Un prototipo ejecutable de la arquitectura. • Lista revisada de riesgos y del caso de negocio. • Plan de desarrollo para el resto del proyecto. • Un manual de usuario preliminar.
OpenUP
• Hito:
Arquitectura de Ciclo de Vida
Concepción
• • • •
Elaboración
Construcción
Transición
Condiciones de éxito de la elaboración: ¿Es estable la visión del producto? ¿Es estable la arquitectura? ¿Las pruebas de ejecución demuestran que los riesgos han sido abordados y resueltos? • ¿Es el plan del proyecto algo realista? • ¿Están de acuerdo con el plan todas las personas
• Construcción:
OpenUP
• En esta fase todas las componentes restantes se desarrollan e incorporan al producto. Todo es probado en profundidad. • El énfasis está en la producción eficiente y no ya en la creación intelectual. • Puede hacerse construcción en paralelo, pero esto exige una planificación detallada y una arquitectura muy estable.
• Productos:
OpenUP
• El producto de software integrado y corriendo en la plataforma adecuada. • Manuales de usuario. • Una descripción del “release” actual.
OpenUP
• Hito: Concepción
Elaboración
Capacidad Operacional
Construcción
Transición
• Se obtiene un producto Beta que debe decidirse si puede ponerse en ejecución sin mayores riesgos. • Condiciones de éxito: • ¿El producto está maduro y estable para instalarlo en el ambiente del cliente? • ¿Están los interesados listos para recibirlo?
• Transición:
OpenUP
• El objetivo es traspasar el software desarrollado a la comunidad de usuarios. • Una vez instalado surgirán nuevos elementos que implicarán nuevos desarrollos (ciclos). • Incluye:
• Pruebas Beta para validar el producto con las expectativas del cliente • Ejecución paralela con sistemas antiguos
OpenUP
• Conversión de datos • Entrenamiento de usuarios • Distribuir el producto
• Los objetivos de la fase de transición: • Obtener autosuficiencia de parte de los usuarios. • Concordancia en los logros del producto de parte de las personas involucradas. • Lograr el consenso cuanto antes para liberar el producto al mercado.
OpenUP
• Hito: Concepción
Elaboración
Construcción
Transición
Producto
• En esta etapa se obtiene el software final.
• Definiciones:
OpenUP
• Un trabajador define el comportamiento y las responsabilidades de un individuo. • Es como un “sombrero” que la persona usa durante el proyecto: • Una persona puede tener varios sombreros • Es el rol que desempeña en un momento dado • Responsabilidades: • Hacer una serie de actividades •
• Actividades:
OpenUP
• Una actividad es una unidad de trabajo que se asigna a un trabajador. Ej.: • Crear o modificar un artefacto
• Una actividad lleva entre un par de horas y un par de días, involucra un solo trabajador y un número pequeño de artefactos.
OpenUP
• Las actividades se consideran en la planificación y evaluación del progreso del proyecto. • • • • •
Ejemplos: Planificar una iteración - Administrador de proyecto Encontrar actores y casos de uso - Analista Revisar el diseño - Revisor de diseño Ejecutar pruebas de performance - Ing. de pruebas de performance
OpenUP
• Asignación de Actividades: Recurso
Trabajador
Actividad
Pablo
Diseñador
Diseño de Objetos
María
Autor de Casos de Uso
Detallar un Caso de Uso
José
Diseñador de Casos de Uso
Diseñar un Caso de Uso
Silvia
Revisor de Diseño
Revisar el Diseño
Arquitecto
Análisis de Arquitectura Diseño de Arquitectura
Eduardo
• Artefactos:
OpenUP
• Elementos de información producidos, modificados o usados por el proceso. • Son los productos tangibles del proyecto. • Son usados por los trabajadores para realizar nuevas actividades y son el resultado de esas actividades.
• Flujos de Trabajo:
OpenUP
• Una lista de actividades, trabajadores y artefactos constituye un proceso. • Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso. • No siempre es posible representar flujos de trabajo.
• Flujos de Trabajo:
OpenUP
Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Flujos de Trabajo Esenciales: Flujos de Trabajo de Ingeniería
Flujos de Trabajo de Apoyo
OpenUP
• Existen habitualmente problemas de comunicación entre ingenieros de software e ingenieros de negocios. Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
• UP proporciona un lenguaje y proceso común para estos dos ámbitos. • Para el modelamiento del negocio se usan “business use cases” (casos de uso del negocio): • La forma en que el software dará apoyo al negocio. Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
• Requerimientos:
OpenUP
Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
• Los desarrolladores y clientes deben acordar qué es lo que el sistema debe hacer: Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
• • • • •
Relevar requerimientos Documentar funcionalidad y restricciones Documentar decisiones Identificar actores Identificar casos de uso Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Los casos de uso describen la funcionalidad. • Los requerimientos no funcionales se incluyen en una especificación complementaria. Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
Imprimir Informe Diseñador
Reciclar
Cliente
Revisor de Diseño
Operador
Administrar Depósito Revisar el Revisar el Revisar la Análisis Diseño Arquitectura
OpenUP
• Análisis y Diseño: Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
• Descripción de cómo se implementará el sistema: un plano Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
• Debe: • Ejecutar las tareas y funciones descritas en los casos de uso • Satisfacer todos los requerimientos • Flexible a cambios Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
• El diseño se arquitectura.
OpenUP centra
Análisis de Arquitectura
en
Diseño de Arquitectura
la
Describir Concurrencia
noción
de
Describir Distribución
Arquitecto
• Diseñar y validar la arquitectura es una tarea esencial. Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
• El modelo de diseño consta de • Clases estructuradas en paquetes • Diseños de subsistemas con interfaces definidas (componentes) Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
• Implementación
OpenUP
Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
• Propósito:
Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
• Definir la organización del código • Implementar clases y objetos en forma de componentes (fuente, ejecutables, etc.) • Probar las componentes desarrolladas • Integrar las componentes en un sistema ejecutable Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Pruebas: Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
• Propósito: • Verificar la interacción entre los objetos • Verificar la integración apropiada de componentes • Verificar que se satisfacen los requerimientos • Identificar los defectos y corregirlos antes de la instalación Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• UP describe como planear y ejecutar estas pruebas. Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
Arquitecto
• UP propone probar las componentes desde el principio: • Confiabilidad, funcionalidad y performance Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
Diseñador
• Las pruebas de regresión son importantes en desarrollos iterativos. Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Distribución: Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
• Producir un producto y hacerlo llegar a sus usuarios finales. Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
• • • • •
Incluye varias actividades: Producir un “release” Empaquetar el software Distribuir el software Instalar el software Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Administración de Proyectos: Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
• Es el arte de balancear objetivos contrarios, manejar riesgos y producir software que satisface a clientes y usuarios. Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
• UP incluye:
Análisis de Objetos
Diseño de Objetos
Diseñador
• Un framework para manejo de proyectos de software Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Guías para planificación, provisión personal, ejecución y monitoreo de planes Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
de
Describir Distribución
Arquitecto
• Un framework para manejar riesgos Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
• Administración Cambio:
de
Análisis de Objetos
Configuración Diseño de Objetos
y
del
Diseñador
• Forma de controlar los artefactos producidos por las personas que trabajan en el proyecto. Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Algunos problemas habituales: • Actualizaciones simultáneas • Múltiples versiones Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
Arquitecto
Análisis de Casos de Uso
• • • •
Diseño de Casos de Uso
UP da guías para: Desarrollos en paralelo Automatizar la construcción Administrar defectos Diseñador de Casos de Uso
Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
OpenUP
• Ambiente: Análisis de Arquitectura
Diseño de Arquitectura
Describir Concurrencia
Describir Distribución
• Ambiente y herramientas de desarrollo que harán posible llevar a cabo el proyecto. Arquitecto
Análisis de Casos de Uso
Diseño de Casos de Uso
Diseñador de Casos de Uso
• UP guía en la configuración de un ambiente de proceso apropiado a cada proyecto. Análisis de Objetos
Diseño de Objetos
Diseñador
Revisor de Diseño
Revisar el Análisis
Revisar el Diseño
Revisar la Arquitectura
Otras Metodologías
• MSF (Microsoft Solution Framework) es la metodología de desarrolla propuesta por Microsoft. • TickIT es una metodología basada en ISO 9000 para lograr la calidad en el despliegue de servicios de Información. • BOOTSTRAP: metodología muestreo de datos.
para
el
Referencias
• Roger S. Pressman, Ingeniería de software un Calidad del Software en México enfoque práctico.Ed. McGraw Hill. • • Piattini M.G. y F.O, Calidad en el desarrollo y mantenimiento del software. Ed. RAMA. • • Hernández Ballesteros, J. F. Y Minguet Melían J. La calidad del software y su medida, Ed. CERASA.
Referencias
• Carnegie Mellon University (2008). Overview Calidad del Software en México of Team Software Process and Personal Software Process. http://www.sei.cmu.edu/tsp/index.html. • Melendez, Miguel (2006). Personal Software Process/Team Software Process. http://homepages.mty.itesm.mx/al796320/So ftwareProcess.doc.
Referencias
• Gabardini, J. (2009) Scrum - Product Owner y Calidad del Software en México PlanificaciónJuan Gabardini. Facultad de Ingeniería – UBA, Argentina • Cohn, Mike www.mountaingoatsoftware.com
(2009)
Dudas