Sqs u2

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