Скачать презентацию Calidad Enfocada en el Desarrollo de Software M Скачать презентацию Calidad Enfocada en el Desarrollo de Software M

1094d29370a6f158c29e832038cc02d7.ppt

  • Количество слайдов: 145

Calidad Enfocada en el Desarrollo de Software M. C. Juan Carlos Olivares Rojas Noviembre Calidad Enfocada en el Desarrollo de Software M. C. Juan Carlos Olivares Rojas Noviembre 2009

Competencias • Conoce la importancia de la aplicación de la calidad en cada una Competencias • Conoce la importancia de la aplicación de la calidad en cada una de las fases 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

Competencias • Interpersonales: Capacidad de trabajar en equipo interdisciplinario, Compromiso ético. • Sistémicas: Capacidad 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.

Evidencias • Actividades 10% • Aplicación de Estándares de Calidad en el Proyecto 30% Evidencias • Actividades 10% • Aplicación de Estándares de Calidad en el Proyecto 30% (dos metodologías por equipo de trabajo presentando resultados al final de la unidad en fecha aun por especificar) • Actividad Evaluadora Parcial 60%

Temario • Qué es la calidad del software. • Cómo obtener calidad de software Temario • Qué es la calidad del software. • Cómo obtener calidad de software (métodos, metodologías, estándares). • Cómo controlar la calidad del software. • Costo de la calidad del software. • Nomenclatura y certificación ISO 9001: 2000.

Temario • La norma ISO/IEC 9126. • Análisis de factores que determinan la calidad Temario • La norma ISO/IEC 9126. • Análisis de factores que determinan la calidad del software.

Temario • Calidad desde el inicio (comunicación y planeación) • Calidad en el modelado Temario • Calidad desde el inicio (comunicación y planeación) • Calidad en el modelado (análisis y diseño) • Calidad en la construcción (codificación y pruebas) • Calidad en el mantenimiento). despliegue (instalación,

Calidad en la Comunicación • Problemas de comunicación Calidad en la Comunicación • Problemas de comunicación

Trabajo en Equipos • El problema de comunicación se da a través de la Trabajo en Equipos • El problema de comunicación se da a través de la colaboración de varias personas en un proyecto. • El capital intelectual como se ha comentado es sumamente difícil de controlar y estandarizar. • La mejor forma de trabajar en equipo es a través de una buena cultura organizacional (principios y valores).

Técnicas de Discusión • Para la toma de decisiones grupales, existen varios métodos que Técnicas de Discusión • Para la toma de decisiones grupales, existen varios métodos que se pueden seguir como: – votación (la decisión más votada gana), – votación aprobatoria (cada miembro puede votar por más de una opción, la opción más votada es la que gana), – suma de rangos (se otorgan ponderaciones a las opciones, siendo 1 para la menos votada, este proceso se realiza por participante, gana la opción con mayor puntaje) y – desviación mínima (se selecciona la opción que tenga mayor puntaje y cuya desviación sea mínimo).

Técnicas de Discusión • Estas técnicas se pueden mejorar a través de otras técnicas Técnicas de Discusión • Estas técnicas se pueden mejorar a través de otras técnicas que ayudan a la toma de decisiones que a continuación se mencionan: – lluvia de ideas, – rueda de mesa (similar a la lluvia de ideas pero cada quien tiene un turno para exponer sus ideas de forma cíclica), – análisis FODA (Fortalezas Oportunidades Debilidades Amenazas).

Técnicas de Discusión • Para problemas más complejos se puede utilizar la técnica Philips Técnicas de Discusión • Para problemas más complejos se puede utilizar la técnica Philips 66. La cual consiste en hacer grupos de 6 personas que discutirán el problema por 6 minutos. • Otra técnica compleja es el Proceso Delphi, la cual se utiliza cuando se desea aislar los miembros del grupo para aislar sus opiniones; o bien, cuando se necesita la opinión de expertos los cuales se encuentran alejados geográficamente.

Calidad en la Planeación • De las tres etapas de la planeación, el itinerario Calidad en la Planeación • De las tres etapas de la planeación, el itinerario (calendarización de actividades) es la que generalmente se realiza. • El seguimiento se da en prácticamente cualquier estándar de calidad (quizás en proyectos pequeños no se de con tanta frecuencia) • La estimación es la etapa más complicada en cuestión del desarrollo de software y la estimación de costos no es la excepción.

Costos de la Calidad del Sw • El costo de la calidad tiene dos Costos de la Calidad del Sw • El costo de la calidad tiene dos componentes: lo que se invierte en obtener buena calidad y lo que se paga por no lograrla. • La primera componente es decidida por los desarroladores y puede ser controlada; la segunda no se puede decidir sino que se manifiesta en las fallas de nuestro producto.

Costos de la Calidad del Sw Costos de la Calidad del Sw

Costos de la calidad del Sw • Entre los costos de prevención se incluyen: Costos de la calidad del Sw • Entre los costos de prevención se incluyen: – planificación de la calidad, – revisiones técnicas formales, – equipo de pruebas, – formación. • Entre los costos de evaluación se encuentran: – inspección en el proceso y entre procesos, – calibrado y mantenimiento del equipo, – pruebas.

Costos de la calidad del Sw • Entre los costos de fallos se encuentran: Costos de la calidad del Sw • Entre los costos de fallos se encuentran: – retrabajo (revisión), – reparación, – análisis de las modalidades de fallos. – resolución de quejas, – devolución y sustitución de productos, – soporte de línea de ayuda, – trabajo de garantía.

Costos de la Calidad del Sw Costos de la Calidad del Sw

Costo de la Calidad del Sw • Si llamamos P, E, Fi, Fe y Costo de la Calidad del Sw • Si llamamos P, E, Fi, Fe y C a las horas totales usados en el proyecto para actividades categorizadas como prevención, Evaluación, Fallas internas, Fallas externas y Creación, respectivamente, tenemos que: • Esfuerzo de Calidad = Eo. Q = (P+E+ Fi+Fe) • Costo de Calidad = Co. Q = (P+E+Fi+Fe) / (P+E+Fi+Fe+C) • Esfuerzo de Mala Calidad = Eo. PQ = Fi+Fe • Costo de Mala Calidad = Co. PQ = (Fi+Fe) / (P+E+Fi+Fe+C)

Costo de la Calidad del Sw • Ejemplo: En un proyecto se usaron 1280 Costo de la Calidad del Sw • Ejemplo: En un proyecto se usaron 1280 horas de las cuales 280 horas se usaron en administración, 60 en entrenamiento para el proyecto, 40 en adaptaciones del proceso para el proyecto, 420 en creación, 50 en inspecciones, 160 en pruebas, 30 en correcciones debido a inspecciones, y 150 en debugging antes de la entrega, y 90 en correcciones finales después de la entrega.

Costo de la Calidad del Sw • Quedan 1000 horas en actividad del proyecto Costo de la Calidad del Sw • Quedan 1000 horas en actividad del proyecto propiamente tal descontadas las horas de administración. • Entonces tenemos: P=60+40, E=50+160, Fi=30+150, Fe=90, C=420, Eo. Q=580, Co. Q=58%, Eo. PQ=270, Co. PQ=27% y Overhead=280/1280=21, 9%.

Costos de la Calidad del Software • Ejemplo – Un ingeniero experimentado introduce 100 Costos de la Calidad del Software • Ejemplo – Un ingeniero experimentado introduce 100 defectos por KLOC y el 50% de estos llegan a la fase de pruebas – Un producto de 50, 000 LOC entraría a la fase de pruebas con 2, 500 defectos por ser encontrados – Se requiere en promedio de 5 a 10 horas-programador para encontrar cada defecto, es decir, un total de 20, 000 horas-programador – Un equipo de 5 personas, trabajando 160 horas al mes, terminaría en 25 meses

Costos de la Calidad del Software • Ejemplo – Asumir un rendimiento promedio del Costos de la Calidad del Software • Ejemplo – Asumir un rendimiento promedio del 70% en el proceso de aseguramiento de calidad. – Un producto de 50, 000 LOC entraría a la fase de pruebas con 750 defectos por ser encontrados – Se requeriría un total de 6, 000 horas-programador para encontrar todos los defectos – Un equipo de 5 personas, trabajando 160 horas al mes, terminaría en un periodo de entre 7 y 8 meses – El ahorro sería de 1 año y medio de pruebas!!! © 2001 by Carnegie Mellon University 23

Calidad en Quark. Soft Tamaño C++ Four. Js Progress Java 28, 344 LOC 48, Calidad en Quark. Soft Tamaño C++ Four. Js Progress Java 28, 344 LOC 48, 578 LOC 43, 793 LOC 42, 086 LOC Productividad 6. 14 LOC/Hr 6. 98 LOC/Hr 5. 39 LOC/Hr 5. 25 LOC/hr Error 26. 59% 3. 03% 1. 34% 18. 32% Calidad 0. 18 D/KLOC 0. 24 D/KLOC 0. 34 D/KLOC 0. 41 D/KLOC • Asumiendo un producto de 80 KLOC • En promedio, los defectos encontrados en pruebas se llevan de 8 a 20 horas corregirlos cada uno

Calidad en el Desarrollo de Sw • En el 2006 el departamento de defensa Calidad en el Desarrollo de Sw • En el 2006 el departamento de defensa de los estados unidos realizó el proyecto bug hunting en donde revisaron los errores del top 50 de proyectos de código abierto. • Se encontraron los siguientes estadísticos

Calidad en el desarrollo de Sw Proyecto Defectos Detectados Defectos Pendientes de Verificar Defectos Calidad en el desarrollo de Sw Proyecto Defectos Detectados Defectos Pendientes de Verificar Defectos pendientes de Inspección Líneas de código (KLOC) Defectos/KL OC Apachehttpd 2 4 25 133. 919 0. 217 Firebird 0 0 197 270. 917 0. 727 Firefox 352 65 168 1855. 717 0. 126 Free. BSD 0 6 605 1582. 166 0. 386 Gnome 349 12 48 706. 511 0. 085 KDE 1253 10 40 4619. 029 0. 011 Mono 69 1 70 334. 195 0. 212 Net. BSD 1267 196 1350 4717. 818 0. 328 PHP 75 0 1 467. 757 0. 002 Postgre. SQL 53 0 23 846. 884 0. 027

Calidad en el modelado • ¿Cuántos diagramas debo crear? No existe una respuesta específica. Calidad en el modelado • ¿Cuántos diagramas debo crear? No existe una respuesta específica. • ¿Debo hacer diagramas de todo tipo? No, sólo se deben utilizar los diagramas que mejor reflejen el modelado de la problemáticaoe

Calidad en el modelado • ¿Qué tan grande debe de ser un diagrama? Entre Calidad en el modelado • ¿Qué tan grande debe de ser un diagrama? Entre más grande sea un diagrama mayor es la confusión. Se deben realizar diagramas bien detallados, pero no tan detallados. • ¿Cuánto texto debe complementar el modelo? Entre menos texto mejor, son como los comentarios del código fuente: pocos pero claros.

Calidad en el modelado • Algunas recomendaciones para el modelado de software son: • Calidad en el modelado • Algunas recomendaciones para el modelado de software son: • No tenga a los programadores esperando los modelos. • Trabajar de una macrovista microvista(enfoque Top-Down). a • Se debe documentar en forma económica. una

Calidad en el modelo • Si es obvio no se debe de modelar. • Calidad en el modelo • Si es obvio no se debe de modelar. • Hacer hincapié en la especialización. • Utilizar patrones de diseño. • Reestructuración de códigos

Procesos de Negocio • Un proceso de negocios es un conjunto de Proceso de Procesos de Negocio • Un proceso de negocios es un conjunto de Proceso de negociosen las que pasos o actividades relacionadas intervienen gente, información y otros recursos para crear valor. • Los procesos de negocios se integran de pasos que se pueden identificar en el tiempo y el espacio • Tiene un principio y un fin

Procesos de Negocio • Tienen entradas y salidas Procesos de Negocios • Tiene un Procesos de Negocio • Tienen entradas y salidas Procesos de Negocios • Tiene un grado de formalización pero no necesitan ser totalmente estructurados

Procesos de Negocio • Los procesos de negocios son la manera más Procesos de Procesos de Negocio • Los procesos de negocios son la manera más Procesos de negocios de los común de mejorar el desempeño sistemas de trabajos ya que podemos cambiar el proceso de negocio cambiando, eliminando o agregando pasos al proceso o también cambiando los métodos de cómo se usan estos pasos

Proceso de Negocios Proceso de Negocios

Proceso de Negocio Proceso de Negocio

Modelado Procesos Negocios 36 Modelado Procesos Negocios 36

Modelado de procesos • El modelado de procesos es en si mismo el proceso Modelado de procesos • El modelado de procesos es en si mismo el proceso de negocio. • Es la subdivisión del proceso de negocios en sus elementos básicos con el propósito de poderlos estudiar y mejorarlos

Modelado de Procesos de Negocios • El modelado de procesos es esencial en el Modelado de Procesos de Negocios • El modelado de procesos es esencial en el desarrollo de los sistemas de información ya que nos ayuda a identificar el problema que el sistema de información deberá resolver y la manera en como deberá resolverlo

Función vs. Proceso • Función: identificada por un verbo. Es continua. – – – Función vs. Proceso • Función: identificada por un verbo. Es continua. – – – Comercializar Fabricar Vender Expedir Comprar • Proceso: identificado por verbo+sustantivo. Tiene un inicio y un fin. No es continuo. – – Tomar un pedido Ensamblar un pieza Facturar a un cliente Solicitar materiales

Procesos de Negocios • Las aplicaciones empresariales están diseñadas para apoyar la coordinación e Procesos de Negocios • Las aplicaciones empresariales están diseñadas para apoyar la coordinación e integración de procesos que abarcan toda la empresa. • Ejemplos de estas Aplicaciones empresariales se muestran a continuación: • Sistemas de administración de la cadena de suministro (SCM).

Procesos de Negocio • Sistemas de administración de relaciones con clientes (CRM). • Sistemas Procesos de Negocio • Sistemas de administración de relaciones con clientes (CRM). • Sistemas de administración del conocimiento (Business Intelligence). • Sistemas Integrales que abarcan los procesos de la organización, llamados ERP (Enterprise Resource Plannig).

 • Procesos de Negocio Los Sistemas de Administración del Procesos de Negocio Conocimiento • Procesos de Negocio Los Sistemas de Administración del Procesos de Negocio Conocimiento recolectan todo el conocimiento y experiencia relevantes en la empresa y la hacen disponible donde y cuando sea necesaria para apoyar los procesos de la empresa y las decisiones administrativas. También enlazan a la empresa a fuentes externas de conocimiento.

 • BPMN Los Sistemas de Administración del Procesos de Negocio Conocimiento recolectan todo • BPMN Los Sistemas de Administración del Procesos de Negocio Conocimiento recolectan todo el conocimiento y experiencia relevantes en la empresa y la hacen disponible donde y cuando sea necesaria para apoyar los procesos de la empresa y las decisiones administrativas. También enlazan a la empresa a fuentes externas de conocimiento.

BPMN • Desarrollado por Business Process Management Initiative (BPMI). • Es un estándar: BPMN BPMN • Desarrollado por Business Process Management Initiative (BPMI). • Es un estándar: BPMN Business Process Modeling Notation. • La especificación BPMN 1. 0 fue publicada en Mayo del 2004.

Introducción • El objetivo principal de desarrollar BPMN es proveer una notación que sea Introducción • El objetivo principal de desarrollar BPMN es proveer una notación que sea fácilmentendible por todos los usuarios de negocio. • Desde los analistas que crean los borradores iniciales de procesos hasta los desarrolladores técnicos que son responsables de implementar la tecnología que ejecutará dichos procesos. Y por supuesto, la gente de negocio que manejará y monitoreará estos procesos.

Introducción • BPMN define un Diagrama de Procesos de Negocio (BPD), basado en la Introducción • BPMN define un Diagrama de Procesos de Negocio (BPD), basado en la técnica de “flowcharting” (diagramado de flujos) que ajusta modelos gráficos de operación de procesos de negocio. • Un modelo de procesos de negocio es una red de objetos gráficos, correspondientes a actividades y controles de flujo que definen el orden de ejecución de éstas.

Elementos Un BPD (diagrama de procesos de negocio) se estructura con un grupo de Elementos Un BPD (diagrama de procesos de negocio) se estructura con un grupo de elementos gráficos. Las cuatro categorías básicas de elementos son: • Flow Objects (objetos de flujo) • Connecting Objects (objetos de conexión) • Swimlanes (Carriles) • Artifacts (artefáctos)

Elementos: Flow Objects Un BPD tiene un pequeño grupo de elementos centrales (tres), los Elementos: Flow Objects Un BPD tiene un pequeño grupo de elementos centrales (tres), los cuales son los Flow Objects: - Event (Evento) - Activity (Actividad) - Gateway (Decisión)

Flow Objects: Event • Un evento se representa por un circulo y es algo Flow Objects: Event • Un evento se representa por un circulo y es algo que “sucede” durante el curso de un proceso de negocio. • Los eventos afectan el flujo del proceso y usualmente tienen un causa (trigger - disparador) o un impacto (result – resultado). • Los eventos se representan con círculos con el centro abierto para permitir anotar diferentes disparadores o resultados.

Flow Objects: Event • Hay tres tipos de eventos basado en cuándo ellos afectan Flow Objects: Event • Hay tres tipos de eventos basado en cuándo ellos afectan el flujo: - Start (comienzo) - Intermediate (intermedio) - End (final)

Flow Objects: Activity • Una actividad (Activity) se representa por un rectángulo con sus Flow Objects: Activity • Una actividad (Activity) se representa por un rectángulo con sus bordes redondeados y es un término genérico para el trabajo que un organización realiza. • Un actividad puede ser atómica o no atómica (compuesta).

Flow Objects: Activity • Los tipos de actividades son: - Task (tareas) - Sub-process Flow Objects: Activity • Los tipos de actividades son: - Task (tareas) - Sub-process (subproceso) + Los subprocesos se distinguen por un pequeño + al centro y abajo en la figura.

Flow Objects: Gateway • Un Gateway es representado por la figura de un diamante Flow Objects: Gateway • Un Gateway es representado por la figura de un diamante y se usa para controlar la divergencia de la secuencia de un flujo. • Determina las “tradicionales” decisiones, tanto de bifurcaciones, como uniones y acoplamientos de flujos. • Las anotaciones al interior indican el tipo de comportamiento de control.

Elementos: Connecting Objects • Los objetos de flujo se conectan entre ellos en un Elementos: Connecting Objects • Los objetos de flujo se conectan entre ellos en un diagrama para crear el esqueleto básico de la estructura de un proceso de negocio. • Existen tres Connecting Objects que proveen esta función de conexión. - Sequence Flow - Message Flow - Association

Connecting Objects: Sequence Flow Un Sequence Flow se representa por una línea sólida con Connecting Objects: Sequence Flow Un Sequence Flow se representa por una línea sólida con el extremo sólido Es usada para mostrar el orden (secuencia) de la actividad dentro del proceso. Note que el término “control flow” generalmente no es usado en BPMN.

Connecting Objects: Message Flow Un Message Flow se representa por una línea segmentada con Connecting Objects: Message Flow Un Message Flow se representa por una línea segmentada con el extremo sin relleno. Es usada para mostrar el flujo de mensajes entre dos participantes de procesos separados (business entities o business roles). En BPMN, dos “Pools” en el diagrama representan a dos participantes.

Connecting Objects: Association Una Association se representa por una segmentada finamente con el extremo Connecting Objects: Association Una Association se representa por una segmentada finamente con el extremo en punta. línea Se usa para asociar datos, textos u otros artefactos con flujos de objetos. Las asociaciones son usadas para mostrar las entradas y salidas de las actividades.

Ejemplo con formas básicas Ejemplo de Proceso de Negocio Simple Ejemplo con formas básicas Ejemplo de Proceso de Negocio Simple

Ejemplo con formas básicas y marcas internas en las formas Segmento de un Proceso Ejemplo con formas básicas y marcas internas en las formas Segmento de un Proceso con más detalles

Elementos: Swimlanes Muchas técnicas de modelados utilizan el concepto de swimlanes como mecanismo de Elementos: Swimlanes Muchas técnicas de modelados utilizan el concepto de swimlanes como mecanismo de organización de actividades en categorías visuales separadas para ilustrar las diferentes capacidades funcionales o responsabilidades. BPMN soporta swimlanes con dos constructores principales: - Pool - Lane

Swimlanes : Pool Un Pool representa un Participante en un Proceso. Nombre El Pool Swimlanes : Pool Un Pool representa un Participante en un Proceso. Nombre El Pool también actúa como contenedor gráfico para separar al grupo de actividades realizadas por un participante de otros Pools. Los Pools se usan generalmente en el contexto de situaciones B 2 B.

Swimlanes : Lane Un Lane es una partición dentro de un pool y se Swimlanes : Lane Un Lane es una partición dentro de un pool y se extiende a lo largo de todo el pool, tanto vertical como horizontalmente. Nombre Los Lanes son usados para organizar y categorizar actividades.

Swimlanes : Pool & Lane Los Pools se usan cuando los diagramas involucran a Swimlanes : Pool & Lane Los Pools se usan cuando los diagramas involucran a dos entidades de negocios o participantes separados. Están físicamente separados en el diagrama. Las actividades dentro de Pools separados son consideradas auto contenidas en el proceso. De esta forma, la secuencia del flujo podría no atravesar el límite del Pool.

Swimlanes : Pool & Lane Los flujos de mensajes son los mecanismos que muestran Swimlanes : Pool & Lane Los flujos de mensajes son los mecanismos que muestran la comunicación entre dos participantes, conectando de esta manera a dos Pools (u objetos dentro de los Pools).

Swimlanes : Pool & Lane Ejemplo de BPD con Pools Swimlanes : Pool & Lane Ejemplo de BPD con Pools

Swimlanes : Pool & Lane Los Lanes son más cercanos a los swimlanes que Swimlanes : Pool & Lane Los Lanes son más cercanos a los swimlanes que tradicionalmente se utilizan para modelar procesos de negocio. Los Lanes son usados para separar actividades asociadas con una función específica de la organización. La secuencia de flujos podría atravesar los límites del Lane dentro de un Pool, pero podrían no usarse flujos de mensajes entre Flow Objects en Lanes del mismo Pool.

Swimlanes : Pool & Lane Segmento de un Proceso con Lanes Swimlanes : Pool & Lane Segmento de un Proceso con Lanes

Elementos : Artifacts BPMN fue diseñado para permitir a los modeladores y herramientas de Elementos : Artifacts BPMN fue diseñado para permitir a los modeladores y herramientas de modelado algunas flexibilidades para extender la notación básica y proveer la habilidad poder modelar diferentes contextos apropiadamente. No está limitado el número de Artefactos que se pueden agregar a un diagrama para que éste represente más apropiadamente al contexto del negocio. La versión actual de BPMN predefine sólo tres tipos de artefactos.

Elementos : Artifacts Data object Nombre [Estado] Group Annotation Anotaciones de Texto permiten al Elementos : Artifacts Data object Nombre [Estado] Group Annotation Anotaciones de Texto permiten al Modelador agregar información adicional

Artifact : Data Object Los Data Objects son un mecanismo para mostrar como las Artifact : Data Object Los Data Objects son un mecanismo para mostrar como las actividades requieren o producen objetos. Se conectan a las actividades a través de asociaciones. Nombre [Estado]

Artifact : Group Un Group es representado por un rectángulo redondeado dibujado con línea Artifact : Group Un Group es representado por un rectángulo redondeado dibujado con línea segmentada El agrupamiento puede ser usado para propósitos de documentación o análisis, y no afecta la secuencia del flujo.

Artifact : Annotation Las Annotations son mecanismos para que un modelador pueda agregar información Artifact : Annotation Las Annotations son mecanismos para que un modelador pueda agregar información textual adicional para el lector del diagrama BPMN. Anotaciones de Texto permiten al Modelador agregar información adicional

Artifact Los modeladores puede crear sus propios tipos de artefactos que agreguen más detalle Artifact Los modeladores puede crear sus propios tipos de artefactos que agreguen más detalle al proceso. Con bastante frecuencia se muestran entradas y salidas de actividades en los procesos. Sin embargo, la estructura básica del procesos, es especificada con actividades, gateways, y flujos de secuencia.

Artifact Segmento de un Proceso con Lanes. Sin artefactos. Segmento de un Proceso con Artifact Segmento de un Proceso con Lanes. Sin artefactos. Segmento de un Proceso con Lanes. Con artefactos.

Elementos centrales de los diagramas Elementos centrales de los diagramas

Lista completa de elementos Lista completa de elementos

Ejemplo Ejemplo

Elementos del Proceso Elementos del Proceso

Usos Generales de BPMN Dentro de la variedad de objetivos de modelado de procesos, Usos Generales de BPMN Dentro de la variedad de objetivos de modelado de procesos, hay dos tipos básicos que pueden ser creados con un BPD: • Collaborative (Public) B 2 B Processes • Internal (Private) Business Processes

Collaborative (Public) B 2 B Processes Ejemplo proceso colaborativo Collaborative (Public) B 2 B Processes Ejemplo proceso colaborativo

Ejemplo Proceso de Alto Nivel Ejemplo de proceso de alto nivel el cual es Ejemplo Proceso de Alto Nivel Ejemplo de proceso de alto nivel el cual es básicamente una serie de subprocesos con tres puntos de decisión.

Ejemplo Proceso de Alto Nivel Ejemplo Proceso de Alto Nivel

Ejemplo Proceso de Alto Nivel Ejemplo Proceso de Alto Nivel

Ej. Proceso Interno: Más bajo Nivel Ej. Proceso Interno: Más bajo Nivel

Modelado de Negocios con el UML • Modelo de Casos de Uso de Negocios Modelado de Negocios con el UML • Modelo de Casos de Uso de Negocios – Actores del Negocio – Casos de Uso del Negocio – Diagramas de Actividades • Modelo de Objetos del Negocio – Trabajadores del Negocio – Entidades del Negocio – Diagramas de Actividades (Detallado) – Diagramas de Colaboración – Diagramas de Secuencia

Modelo de casos de uso del negocio Actor del Negocio Alguien o algo externo Modelo de casos de uso del negocio Actor del Negocio Alguien o algo externo a la empresa que interactúa con ella. Ejemplos: Clientes, Proveedores, etc.

Modelo de casos de uso del negocio Caso de uso del Negocio Secuencia de Modelo de casos de uso del negocio Caso de uso del Negocio Secuencia de acciones (actividades) que una organización realiza para obtener un resultado observable y de valor para un actor de negocio particular. Un caso de uso del negocio es lo mismo que un proceso de negocio

Modelo de casos de uso del negocio Diagrama de Casos de Uso del Negocio Modelo de casos de uso del negocio Diagrama de Casos de Uso del Negocio Es la representación de un grupo de casos de uso del negocio relacionados dentro de la empresa. Nos dicen que procesos de la organización proporcionan valor agregado y los individuos que interactúan con la misma. Describen completamente la organización en términos de casos de uso del negocio.

Modelo de casos de uso del negocio Diagrama de Actividades Es la representación de Modelo de casos de uso del negocio Diagrama de Actividades Es la representación de una secuencia de actividades dentro de un caso de uso del negocio. Provee una manera gráfica de documentar un caso de uso del negocio.

Caso Empresa de Fabricación Caso Empresa de Fabricación

D. A. Registrar Pedido D. A. Registrar Pedido

Modelo de objetos del negocio Trabajador del Negocio Un Trabajador del Negocio (Obrero, Empleado Modelo de objetos del negocio Trabajador del Negocio Un Trabajador del Negocio (Obrero, Empleado o funcionario) realiza actividades dentro de un caso de uso del negocio, interactua con otros trabajadores del negocio y manipula entidades del negocio.

Modelo de objetos del negocio Entidades del Negocio Una Modelo de objetos del negocio Entidades del Negocio Una "cosa" manipulada o usada por los trabajadores del negocio. Son ejemplos de entidades del negocio: factura, pedido, plan de producción, etc

Cliente Diagrama de Actividades Detallado Comercial Jefe. Técnico Jefe. Producción Cliente Diagrama de Actividades Detallado Comercial Jefe. Técnico Jefe. Producción

Diagrama de Clases Diagrama de Clases

Diagrama de Secuencia Diagrama de Secuencia

Diagrama de Colaboración 98 Diagrama de Colaboración 98

Procesos de Negocio Procesos de Negocio

Pruebas y depuración • La fase de prueba se realiza una vez integrado cada Pruebas y depuración • La fase de prueba se realiza una vez integrado cada uno de los módulos del sistema. • La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración • Una vez identificado los errores en la fase de pruebas, se procede Depuración • Una vez identificado los errores en la fase de pruebas, se procede a corregirlos. A esta fase se le llama depuración. • En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Pruebas y depuración • La fase de prueba se realiza una vez integrado cada Pruebas y depuración • La fase de prueba se realiza una vez integrado cada uno de los módulos del sistema. • La fase de pruebas se realiza de distintas formas tratando de encontrar la mayoría de los errores que se encuentran de manera inherente en el software.

Depuración • Una vez identificado los errores en la fase de pruebas, se procede Depuración • Una vez identificado los errores en la fase de pruebas, se procede a corregirlos. A esta fase se le llama depuración. • En la fase de depuración también se arreglan detalles superficiales del software además de optimizar y mejorar algunos procesos.

Depuración • Es la detección, corrección y eliminación de errores de software. • El Depuración • Es la detección, corrección y eliminación de errores de software. • El tener un plan de pruebas ayuda a clarificar el proceso de depuración. • El plan de pruebas debe de estar mucho antes de la construcción del software.

Depuración • Existen muchos tipos de pruebas dependiendo de la labor y características de Depuración • Existen muchos tipos de pruebas dependiendo de la labor y características de cada una de ellas. • Pruebas Alfa: se realizan por el usuario final en un ambiente controlado. • Pruebas Beta: se realizan por el usuario sin controlar el ambiente.

Depuración • A continuación se mencionan algunas características deseables que deben contener los planes Depuración • A continuación se mencionan algunas características deseables que deben contener los planes de prueba: • Diseñar un caso de prueba para cada funcionalidad del software. • Establecer como mínimo un caso de prueba de datos correcto.

Depuración • Establecer como mínimo un caso de prueba de datos incorrecto. • Ejemplo: Depuración • Establecer como mínimo un caso de prueba de datos incorrecto. • Ejemplo: Caso de Prueba de un módulo de raíz cuadrada. • Qué el usuario ingrese un número mayor que 0.

Depuración • Qué el usuario ingrese un número 0 • Qué el usuario ingrese Depuración • Qué el usuario ingrese un número 0 • Qué el usuario ingrese un número menor que 0. • Toda actividad de construcción (codificación) es susceptible de cometer errores dado que se trata de una actividad humana.

Depuración • Al realizar la depuración de un programa existe la posibilidad de un Depuración • Al realizar la depuración de un programa existe la posibilidad de un 50% de cometer otro error. • Es recomendable realizar pruebas de trazado (assert) para visualizar en donde ocurren los errores.

Depuración • Se recomienda probar lo antes cualquier fragmento de código. posible • Las Depuración • Se recomienda probar lo antes cualquier fragmento de código. posible • Las pruebas ayudan al aseguramiento de calidad pero no garantizan que un software esté 100% libre de errores.

Depuración • Las pruebas de caja blanca también llamadas transparentes se concentran en lo Depuración • Las pruebas de caja blanca también llamadas transparentes se concentran en lo que es el código fuente. • No se pueden tener pruebas que abarquen el 100% de los casos de uso. Se deben realizar pruebas de segmentos

Depuración • Las pruebas de segmentos son bloques de instrucciones. • Las pruebas de Depuración • Las pruebas de segmentos son bloques de instrucciones. • Las pruebas de caja negra están orientadas a lo que se espera realicen los componentes modulares del sistema.

Depuración • Son pruebas funcionales y no interesa como se realizan las cosas sólo Depuración • Son pruebas funcionales y no interesa como se realizan las cosas sólo que el resultado obtenido sea el correcto. • Se recomienda que sean los usuarios quienes las realicen. • Existen diversas filosofías de pruebas como la programación defensiva.

Depuración • La programación defensiva es una técnica de probar primero. Es considerada una Depuración • La programación defensiva es una técnica de probar primero. Es considerada una técnica de codificación. Se basa en el principio de divide y vencerás. • Se codifica el esqueleto de la aplicación. • Se realizan pruebas.

Depuración • Se corrigen los errores y se vuelven a hacer pruebas. • Las Depuración • Se corrigen los errores y se vuelven a hacer pruebas. • Las pruebas de estrés se encargan de observar el rendimiento de la aplicación sobre cargas demandantes de trabajo: grandes volúmenes de datos con poco espacio en disco, 90% de uso de CPU, múltiples conexiones, etc.

Depuración • Existen otros tipos de prueba como: • Pruebas de unidad: se encargan Depuración • Existen otros tipos de prueba como: • Pruebas de unidad: se encargan de un módulo de software en particular. • Pruebas de Integración: son pruebas que se realizan con dos o más módulos trabajando en conjunto.

Depuración • Existen otro tipos de prueba como las de aceptación que están más Depuración • Existen otro tipos de prueba como las de aceptación que están más involucradas en el concepto en sí que en el desarrollo. • También se pueden aplicar pruebas aleatorias. Lo ideal es poder utilizar un framework de pruebas.

Depuración • La mayoría de los IDEs modernos presentan frameworks para la depuración desde Depuración • La mayoría de los IDEs modernos presentan frameworks para la depuración desde el clásico step by step over sobre cada uno de los módulos hasta la realización de pruebas de unidad. • Entre las más famosas destacan JUnit para realizar pruebas de unidad en Java.

Guía Prueba de Programas • Se necesita especificar las salidas o resultados esperados. • Guía Prueba de Programas • Se necesita especificar las salidas o resultados esperados. • Un programador debe de evitar probar sus propios programas. • Una organización no debe de probar sus propios programas.

Guía Prueba de Programas • Inspeccionar los resultados obtenidos de cada prueba. • Los Guía Prueba de Programas • Inspeccionar los resultados obtenidos de cada prueba. • Los casos de prueba deben escribirse condiciones de entrada que son inválidas e inesperadas, así como también aquellas que son válidas y esperadas.

Guía Prueba de Programas • Examinar un programa para verificar que hace lo que Guía Prueba de Programas • Examinar un programa para verificar que hace lo que deba de hacer es sólo parte de la prueba, la otra mitad es asegurarse que el programa no haga lo que no deba de hacer. • No realizar planeaciones asumiendo que no se encontrarán errores.

Guía Prueba de Programas • La probabilidad de la existencia de mas errores en Guía Prueba de Programas • La probabilidad de la existencia de mas errores en una sección de un programa es proporcional al número de errores encontrados en esa sección. • La realización de pruebas es una actividad extremadamente creativa e intelectualmente retadora.

Guía Prueba de Programas • Se debe de realizar una lista de verificación para Guía Prueba de Programas • Se debe de realizar una lista de verificación para inspecciones de prueba que contenga los siguientes puntos: • • Datos Declaración de datos Errores computacionales Errores de comparación

Guía Prueba de Programas • Errores de control de flujo • Errores de Interface Guía Prueba de Programas • Errores de control de flujo • Errores de Interface • Errores de Entrada/Salida • Se pueden utilizar métodos deductivos e inductivos para la prueba de software.

Depuración por Inducción • Se siguen los siguientes pasos: • • • Localizar los Depuración por Inducción • Se siguen los siguientes pasos: • • • Localizar los datos pertinentes Organizar los datos Estudiar las relaciones Divisar las hipótesis Probar las hipótesis Corregir el error

Depuración por Deducción • • • Enumerar las posibles causas Usar procedimientos de eliminación Depuración por Deducción • • • Enumerar las posibles causas Usar procedimientos de eliminación Refinar las hipótesis restantes Probar las hipótesis restantes Si no se pueden probar las hipótesis entonces coleccionar más datos y repetir el proceso • En caso contrario corregir el error

XP e. Xtreme Programming • Se tienen doce principios básicos: • • • Planeación XP e. Xtreme Programming • Se tienen doce principios básicos: • • • Planeación y requerimientos Entregas pequeñas e incrementales Metáforas de Sistemas Diseños simples Pruebas continuas Refactorización

XP e. Xtreme Programming • • • Programación en pares Propiedad colectiva del código XP e. Xtreme Programming • • • Programación en pares Propiedad colectiva del código Integración Continua Semanas de 40 horas Clientes como miembros del equipo Codificar con estándares

Extreme Testing • Las programación extrema tienen las siguientes ventajas en lo que respecta Extreme Testing • Las programación extrema tienen las siguientes ventajas en lo que respecta al proceso de pruebas: • Se gana confianza ya que el código debe cumplir las especificaciones. • Se tiene el resultado final del código antes de codificar

Extreme Testing • Se entiende mucho mejor las especificaciones y requerimientos de la aplicación. Extreme Testing • Se entiende mucho mejor las especificaciones y requerimientos de la aplicación. • Se inicia con diseños simples y se refactoriza el código después para mejorar el desempeño sin preocuparse de que se estén rompiendo las especificaciones.

Plan de Pruebas • Se recomienda utilizar la metodología y formatos del estándar IEEE Plan de Pruebas • Se recomienda utilizar la metodología y formatos del estándar IEEE 829 para documentación de pruebas de software: • Pasos que incluye: • Identificador de plan de pruebas (se muestra el estándar a seguir para el nombre de las pruebas)

Plan de Pruebas • Introducción (en que consiste las pruebas del sistema) • Elementos Plan de Pruebas • Introducción (en que consiste las pruebas del sistema) • Elementos a probar • Características a ser probadas • Características que no se probarán • Enfoque • Criterio de fallo o aceptación de los elementos

Plan de Pruebas • Criterio de Suspensión y Reanudación de requerimientos • Entregables de Plan de Pruebas • Criterio de Suspensión y Reanudación de requerimientos • Entregables de las pruebas • Tareas de las pruebas • Necesidades del entorno • Responsabilidades • Equipo y necesidades de capacitación • Agenda

Plan de Pruebas • Riesgos y contingencias • Acuerdos • A las pruebas se Plan de Pruebas • Riesgos y contingencias • Acuerdos • A las pruebas se les ha empezado a llamar de manera formal verificación y validación. • Existen metodologías más robustas como el TMMI (Test Maturity Model)

Plan de pruebas Plan de pruebas

Formato Plan de Pruebas ID: 1 Nombre: Enviar artículo Probado por: Fulanito Descripción: Se Formato Plan de Pruebas ID: 1 Nombre: Enviar artículo Probado por: Fulanito Descripción: Se introducen los datos del artículo y de los autores. Condiciones de Entrada: nombre. Articulo=“Calidad del Sw” … email. Autor=“jcolivar@itmorelia. edu. mx” Resultado Esperado: 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. Resultado Obtenido: Se generan bien userid y password pero el correo no llegó.

Práctica de Laboratorio • Realizar un programa que permita calcular el área de un Práctica de Laboratorio • Realizar un programa que permita calcular el área de un triángulo conociendo tres lados utilizando la fórmula de herón. • Realizar el plan de pruebas que garantice que el programa está libre de errores

Arquitectura Arquitectura

Casos de Pruebas • ¿Con cuantos casos de prueba valido que el software está Casos de Pruebas • ¿Con cuantos casos de prueba valido que el software está correcto? • Para cada caso de prueba sólo indicar las posibles entradas. • Por ejemplo: • Caso de Prueba 1: A=3 B=4 C=5, el resultado esperado debe de ser 6. • ¿Es diferente el caso A=4 B=3 C=5?

Casos de Prueba • Tipos de Triángulo en Base a sus lados: • Se Casos de Prueba • Tipos de Triángulo en Base a sus lados: • Se deben tener al menos un caso de cada uno de ellos y al menos un caso no válido: A=0 B=1 C=“Hola”.

Caso de Prueba • ¿Cuál es el resultado esperado para el caso de prueba Caso de Prueba • ¿Cuál es el resultado esperado para el caso de prueba A=1 B=2 C=3? • Area=0 • ¿Qué pasó? • !Exento este parcial quien pueda dibujar un triangulo de dimensiones 1, 2 y 3 cm para cada lado!

Referencias • Pressman, R. (2004). Ingeniería del Software un Enfoque Práctico. Sexta Edición. Mc. Referencias • Pressman, R. (2004). Ingeniería del Software un Enfoque Práctico. Sexta Edición. Mc. Graw Hill. • Guido, J. y Clements, J. , “Administración Exitosa de Proyectos”, Segunda Edición, Thomson, México, 2003, ISBN: 0 -324 -07168 -X.

Referencias • Pintor, A. (2009), Material del curso Calidad del Software II, Instituto Tecnológico Referencias • Pintor, A. (2009), Material del curso Calidad del Software II, Instituto Tecnológico de Morelia. • Myers, et al. (2004), “The Art of Software Testing”, Wiley, Estados Unidos, 2004, ISBN: 0 -471 -46912 -2

Referencias • Piattini M. G. y F. O, Calidad en el desarrollo y mantenimiento Referencias • Piattini M. G. y F. O, Calidad en el desarrollo y mantenimiento del software. Ed. RAMA.

¿Preguntas? ¿Preguntas?