Is planning by Juan Carlos Olivares Rojas

Software Planning Juan Carlos Olivares Rojas MSN: juancarlosolivares@hotmail.com jcolivar@itmorelia.edu.mx http://antares.itmorelia.edu.mx/~jcolivar/ @jcolivares Social Network: Facebook, LinkedIn. Hi5

Clase Pasada

• Obtener los requerimientos del Problema del Poker Planning • Expresarlos en el documento de definición y especificación de requerimientos • Aplicar otras técnicas de requerimientos a parte de casos de uso (especificarlo) • Programar la especificación de la función

Clase pasada

• Analizar diferentes tipos de requerimientos • ¿Para especificar requerimientos se tiene que hacer un análisis? • Retomar programa orientado a aspectos • Analizar requermientos de proyectos con casos de uso.

¿Qué es esto?

Especificación Formal

• Es la mejor forma de indicar requerimientos, el detalle es que se requiere de un nivel de abstracción muy alto a veces más díficil de expresar el propio problema. • Requerimiento: método de ordenamiento de forma ascendente. • Entradas: dos arreglos de tamaño n: p y q, donde p es el arreglo original y q el resultado.

Especificación Formal

• Salida: q[o] < q[1] < q[2] … < … q[n] • ¿cuál es el problema? • Es válido lo siguiente: public int [] ordenar(int p[]){ int q[] = new int [p.length]; for(int i=0; i<p.length; i++) q[i]=0; Return q;}

Planificación del tiempo

• Para asegurar que un proyecto de software se realice de manera exitosa es necesario realizar la gestión del proyecto. • La gestión de proyectos se compone como cualquier proceso administrativo de cuatro etapas claves: planeación, organización, control y dirección. • Entre los recursos disponibles, el tiempo es la principal restricción de un sistema.

Planificación del tiempo

• Aunque la administración del tiempo sea prioritario en el desarrollo de proyectos de software, los recursos humanos y materiales deben ser gestionados de forma adecuada. Todos estos recursos implican el uso de recursos económicos. • La planeación es el primer acercamiento a la construcción de soluciones. Típicamente se compone de tres fases: Estimación, Itinerario, Seguimiento.

Planificación del tiempo

• La estimación es la parte más difícil de la planeación dado que se tiene que definir • Existen diferentes tipos de planeación en función al tiempo: operativa (táctica) y estratégica. • ¿qué tipo de planeación se realiza cuando se desarrolla software? • Planeación operativa.

Planificación del tiempo

• La planificación de proyectos de software es complicada por que es un producto intangible y no hay un “proceso” estándar definido. • La planeación parte del pleno entendimiento de lo que es el problema. • La planeación tiene como finalidad el logro de objetivos: en nuestro caso el desarrollo exitoso de productos de software.

Planificación del tiempo

• La planeación es un proceso que nos permite ver donde estamos, hacia donde queremos llegar y que se va a hacer para lograrlo (realización de un plan). • Un plan generalmente es un documento escrito que sirve de guía de desarrollo para cumplir las metas del proyecto. • Es un proceso iterativo el cual termina hasta que el proyecto mismo haya terminado.

Planificación del tiempo

• El éxito o fracaso de un proyecto de software depende en gran parte de la planificación, ya que con ayuda de ésta se pueden evitar problemas como: • Retraso de tiempo de entrega • Sobrepasar el presupuesto • Baja calidad del producto

Planificación

GESTION DE PROYECTOS

PLANIFICACIÓ N

Planificación del tiempo (calendarización) Estimación de costos (esfuerzo)

•Propuesta •Planificación •Supervisión •Personal •Informal

Gestión de riesgos y control de calidad Gestión de la configuración de sw

Gestión de Proyectos

• El proceso de gestión de proyectos consiste básicamente en: Establecer las prioridades de un proyecto Hacer la valoración inicial de las actividades del proyecto Definir los hitos del proyecto y productos a entregar Mientras el proyecto no se haya terminado o cancelado repetir Bosquejar la programación en el tiempo del proyecto Iniciar actividades conforme a la programación

Gestión de Proyectos

Esperar (por un momento) Revisar el progreso del proyecto Revisar los estimados de los parámetros del proyecto Actualizar la programación del proyecto Renegociar las restricciones del proyecto y los productos a entregar Si surgen problemas entonces Iniciar la revisión técnica

Fin si

Fin mientras

Gestión de Proyectos

• Durante la recolección de requerimientos, se listan todos los elementos que se deben entregar del proyecto: actividades e hitos. • Los hitos se convierten en la métrica fundamental que permite medir el grado de avance del proyecto. Más que los hitos son los “entregables del proyecto”. Un hito es un punto de control.

Planificaci贸n del Proyecto

Entregables del proceso de Planificaci贸n

Planificación del Proyecto

• Ejemplo de una actividad de planeación: Instalar un Sistema de cómputo. • ¿Qué se puede Observar? • Que es incorrecta • ¿Por qué? Cada actividad realizada debe tener asignada un recurso humano responsable de hacerlo, recursos materiales (infraestructura) y financieros para llevarlo

Planificación del Proyecto

• Reformulando la actividad: Instalar un sistema de control computarizado en el Departamento de Control Escolar de cada Escuela, Unidad o Centro para el 31 de diciembre de 2006, que no requiera más de 500 horas de trabajo de análisis de sistemas y operaciones con más de 10% de paro durante los tres primeros meses. El responsable de esta actividad es el Ing. Fernando Martínez

Planificación del Proyecto

• Existen varias formas de representar una planeación: • Pueden representarse como una lista de actividades priorizadas, como un programa de actividades, como un calendario de actividades, como una matriz de responsabilidades, etc. • Lo importante es la especificación de las actividades a realizar así como los recursos utilizados y productos esperados.

Planificación del Proyecto

• Generalmente se inicia con lo que se conoce como diagrama de planeación, el cual es otra técnica de organización en la cual nos centramos en cada tarea. También recibe el nombre de diagrama de actividades. • En esta etapa se debe definir que actividades se pueden realizar sin depender de ninguna, que actividades para realizarse dependen de otras y finalmente que actividades pueden realizarse simultáneamente (en paralelo).

Diagrama de Planeación

• Los diagramas de actividades se pueden resumir en una matriz de tiempos, en donde básicamente se debe indicar las tareas, la estimación de tiempo y las relaciones con otras tareas (entregables representados con las letras M). Tarea Duración (días)

15 T1 (M1)

Dependencias

T10

T11

T12

T3, T6 (M4)

T5, T7 (M7)

T2,T4 (M2)

T1,T2 (M3)

T1 (M1)

T4 (M5)

T9 (M6)

T11 (M8)

Matriz de Tiempo

• La matriz del tiempo debe contener al menos los

siguientes campos: EDT/WBS (Código de la actividad), el nombre de la actividad y la duración en días.

• La duración del tiempo puede ser estimada o fija. Se considera que un tiempo es fijo aquel

que no puede realizarse en menos tiempo o que tiene que realizarse en una fecha indicada.

Matriz de Tiempo

• El tiempo puede ser calculado en base a la siguiente fórmula: (to + 4t m + t p ) te = 6 • En donde: – te = Tiempo estimado – to = Tiempo optimista – tm = Tiempo promedio – tp = tiempo pesimista

• Esta matriz del tiempo puede ser expresada de mejor forma de forma gráfica y de manera conjunta con un diagrama de Gantt.

Diagrama de Gantt

â&#x20AC;˘ Se recomienda usarlos cuando son menos de 20 actividades y el tiempo es breve.

Diagrama de Planeaciรณn

โ ข Se deben considerar siempre la asignaciรณn de recursos humanos a las actividades. Tarea

Ingeniero

Jane

Anne

Jane

Fred

Mary

Anne

Jim

Fred

Jane

T10

Anne

T11

Fred

T12

Fred

Diagrama PERT

• El manejo de redes de actvidades con PERT permite utilizar mejores modelos matemáticos de estimación.

Programación GUI

Prueba de usabilidad

7 days

Mon 12/14/98Tue 12/22/98

Wed 12/23/98Thu 12/31/98

Revisión del diseño

Escribir manual de usuario

Entrenamiento de usuarios

10 days

Mon 2/1/99

Fri 2/12/99

Diseño GUI 6

14 days Prueba del sistema

Tue 11/24/98 Fri 12/11/98

1 day

Mon 11/23/98Mon 11/23/98

7 days

5 days

Mon 12/14/98Tue 12/22/98

Wed 12/23/98Tue 12/29/98

Diseño Base de datos

Programación BD

Prueba de la BD

7 days

Thu 1/21/99

Fri 1/29/99

21 days

Tue 11/24/98 Tue 12/22/98

21 days

Wed 12/23/98Wed 1/20/99

Time Boxing

• Se tiene bien definido las fechas de entrega y a partir de allí se realiza una planeación hacia atrás. • En metodologías ágiles se cuenta con un tiempo predeterminado, por ejemplo, los sprints en scrum son de 21 días.

WBS

• Es una técnica de planeación en la cual se puede describir y cuantificar la cantidad de trabajo a realizar. • Es una estructura tipo árbol en la cual se esquematizan y jerarquizan cada una de las actividades a realizar. • Es muy parecido a un organigrama con la diferencia que aquí los nodos son tareas.

WBS

• Se debe cumplir la regla de que todas los nodos hijos de un padre la suma de sus ponderaciones dan 100% las actividades del padre. • Las tareas de WBS llevan una numeración que indica su orden y anidamiento, muy parecido a un índice temático.

WBS

• Las ramas de cada árbol se les llama paquete y deben ser totalmente independientes de otros paquetes. • Las actividades de mayor nivel (de preferencias todas) deben ser medibles para poder cuantificar el grado de avance. • Las actividades deben presentar resultados tangibles.

WBS

Evaluación del costo beneficio

• En todo proyecto que se desarrolle siempre es importante conocer si es realmente es costo-efectivo el desarrollo de software tanto a nivel de cliente como a nivel de desarrollo. • Para poder evaluar un proyecto se necesita que esté terminado. Generalmente la evaluación se da antes de que comience el proyecto de allí la importancia que tiene la estimación en el desarrollo de software

Evaluación del costo beneficio

• Para poder estimar, se necesita medir. Para poder medir se necesita de un patrón de comparación denominado métrica. Las métricas del software son amplias y variadas.

Métricas del Software

• Las métricas además de ayudarnos a medir nos sirve de base para la calidad. • Las métricas son la base de la estimación.

Métricas del Software

• Cuando se recopila un solo aspecto de los datos se está hablando de medidas. Ejemplo: número de líneas de código o número de errores.

Métricas del Software

• Un ingeniero de software recopila medidas

desarrolla métricas para obtener indicadores. • Un indicador: es una métrica o una combinación de métricas que proporcionan un visión profunda del proceso y proyecto del software o del producto en si mismo. • Hay dos tipos de indicadores o métricas: Indicadores de proceso e indicadores del proyecto

Métricas del Software

• Las carácterísticas deseables para las métricas son:

– Objetiva. – Sencilla, definible con precisión para que pueda ser evaluada. – Fácilmente obtenible (a un coste razonable). – Válida, la métrica debería medir exactamente lo que se quiere medir y no otra cosa. – Robusta. Debería de ser relativamente insensible a cambios poco significativos en el proceso o en el producto.

Métricas del Software

• Las Métricas de producto pueden medir la complejidad del diseño, el tamaño del producto final (fuente u objeto) o el número de páginas de documentación producida.

• Las Métricas de proceso, son tiempo de desarrollo total, esfuerzo en días/hombre o meses/hombre de desarrollo del producto, tipo de metodología utilizada o nivel medio de experiencia de los programadores.

Métricas del Software

•Existen otras formas de clasificación por ejemplo basadas en propiedades objetivas y subjetivas:. •Por ejemplo, el tamaño del producto medido en líneas de código (LOC) es una medida objetiva del producto, y una medida subjetiva sería el nivel de experiencia de un programador es una medida subjetiva.

Métricas Orientadas al Tamaño

• Las Líneas de Código (LOC) son la medida más utilizada para determinar la longitud del código fuente. La definición más común es la siguiente: • Una línea de código es cualquier línea de un texto de un programa que no es un comentario o línea en blanco, sin tener en cuenta el número de instrucciones o parte de instrucciones en la línea. Esta medida se suele representar por NCLOC (No Comentary Lines of Code).

Métricas Orientadas al Tamaño

• Si queremos conocer la longitud real del programa esta sería: LOC = NCLOC + CLOC • donde CLOC es el número de líneas de comentarios • Una medida indirecta de la densidad de comentarios sería: CLOC / LOC

Métricas Orientadas al Tamaño

• ¿Es malo tener tantos comentarios?

• No. Se debe tener una buena documentación. Los comentarios deben de ser como notas taquigráficas. • El problema es considerar los comentarios como métrica para estimar el desarrollo de software. Aunque una buena documentación sea en código o no tiene su costo.

Otras métricas

• Cuando se habla de otras partes del desarrollo del ciclo de vida del software también se pueden cuantificar su proyecto: Visión

Diagrama

Elemento básico

Funcional

Diagrama de FD Diccionario de datos Diagrama E/R Diagrama de Trans. Estados

Burbuja Dato elemental Objetos y Relac. Estado y transiciones

Datos Estado

Otras métricas

• La tarea de determinar costos de un proyecto de software no es tan fácil como parece. • En general el costo total de un software está determinado por dos indicadores clave: • Esfuerzo para completar una actividad • Tiempo calendario se necesita para completar una actividad.

Mét. Orientadas a la Función

• Es un método para cuantificar el tamaño y la complejidad de un sistema software en términos de las funciones que el usuario desarrolla o desarrollará. • Se entiende por funciones a las entradas, salidas, archivos, etc. • La métrica por función mejor conocida es el punto de función aunque suelen manejarse muchas métricas como los Puntos de Caso de Uso y Objetos.

Más Métricas

• Existen otras métricas para determinar el tamaño y la complejidad del software. • Por ejemplo SIZE1 muestra el número de líneas con “;” que para lenguajes que tienen este terminador de instrucciones funciona de buena forma. • La métrica más exacta en cuanto al tamaño es la Complejidad Ciclomática

Más Métricas

• La Complejidad Ciclomática de McCabe (V(G)) evalua la complejidad del software en base a considerar el flujo de un programa como un grafo. • V(G)= A – N + 2 • Donde A es el número de arcos y N el número de nodos del grafo.

Más Métricas

• Estructuras de Decisión

x x

Secuencia

Si x entonces...

Hacer ... hasta x

Mientras x hacer...

Más Métricas

• Se pueden sacar como corolarios las siguientes fórmulas • V(G) = r, donde r es el número de regiones cerradas del grafo • V(G) = c + 1, donde c es el número de nodos de condición • Entre más alto es V(G) mayor es la

Más Métricas

• ¿Cuál es el software Simple y cual el complejo?

Ejemplo

Abrir archivos Leer archivo ventas Limpiar l铆nea de impresi贸n WHILE (haya registro ventas) DO Total nacional = 0; Total extranjero = 0; WHILE (haya reg. ventas) y (mismo producto) if (nacional) then sumar venta nacional a total nacional

ELSE

Más Métricas

sumar venta extranjero a total extranjero ENDIF Leer archivo de ventas ENDWHILE Escribir linea de listado Limpiar área de impresión ENDWHILE; Cerrar archivos

Más Métricas

Estimación

• Es la predicción de los recurso necesarios para desarrollar un proyecto: capitual intelectual, tiempo, esfuerzo, costos, herramientas, etc. • Existen diversas técnicas de estimación entre las que destacan: • Opinión de expertos: se basa en la experiencia profesional de un grupo de expertos. La técnica delphi es la más apropiada.

Estimación

• Se recomienda que se consense con varios expertos. • Analogía: se basa en la experiencia de proyectos anteriores por lo que es una mejor aproximación que la opinión de expertos. • Descomposición: consiste en dividir el proyecto en pequeños subproyectos a fin de estimar de forma más exacta.

Estimación

• En general se a cuantificado en un 40% el conjunto de actividades que tipicamente no se colocan en una planeación:, leer código, revisar, reunirse, etc. • Aproximadamente un 30% del tiempo de los programadores se dedican a actividades personales. • Modelos

matemáticos:

generalmente

Estimación

• Los modelos matemáticos pueden ser generalmente algorítmicos y empíricos. • Los modelos empíricos pueden ser parametrizados y no parametrizados. • En general los modelos empíricos parametrizados tienen una ecuación de la siguiente forma: c EE==AA ++BBXX (ev) (ev) c

Estimación

• Donde • A y B: son constantes obtenidas empíricamente • E: esfuerzo en meses/persona • ev: variable de estimación (LDC o PF) • Existen muchos modelos matemáticos para estimar costos de proyectos de software: COCOMO, COSIMO, SLIM, etc. En este curso se describirá COCOMO II

Desarrollar o Comprar

• En muchas ocasiones es más aconsejable adquirir un producto de software que desarrollarlo. Los gestores son los que tienen que tomar esta decisión y deben tener en cuenta lo siguiente: • Comprar/alquilar el software ya desarrollado con licencia y que se ajuste a las especificaciones.

Desarrollar o Comprar

• Comprar componentes de software parcial o totalmente experimentados y luego modificarlos para ajustarse con las especificaciones. • Encargar la construcción del software a una empresa externa. • En cualquiera de las tres alternativas, un factor importantísimo es la disponibilidad de recursos humanos,

Estudio de viabilidad

• El proceso de ingeniería de requerimientos comienza con un estudio de viabilidad. • Este es un estudio corto que ayuda a resolver si un nuevo sistema de software es o no candidato para desarrollarse de acuerdo a los recursos y restricciones impuestas por al organización. • Llevar a cabo un estudio de factibilidad comprende la evaluación y recolección de información y la redacción de

Estudio de viabilidad

Viablidad Viabilidad Viabilidad T茅cnica Econ贸micaOperativa

Viabilidad Económica

• En caminada en verificar si existe el suficiente recurso económico para llevar acabo el proyecto. • Toma consideraciones como: – VPN (Valor Presente Neto) – TIR (Tasa Interna de Retorno) – TREMA (tasa mínima atractiva de retorno) – ROI (Retorno de Inversión) – Punto de Equilibrio – Estudio de Mercado – Estimación de Costos – Análisis de Sensibilidad

Viabilidad Técnica

• En caminada los recursos humanos (capacidades).

tecnológicos,

• Los recursos tecnológicos pueden estar dados con respecto al hardware y software. • Los recursos humanos enfocados conocimiento y dominio de las tecnologías. • Todos estos recursos implican costos.

Viabilidad Operativa

• Enfocado a determinar si la organización a la cual va dirigido el desarrollo puede utilizar o no los sistemas. • En muchas ocasiones los sistemas funcionan de manera adecuada pero no existe el apoyo ni la logística necesaria para que se puedan llevar acabo.

Gestión configuración software

• Los cambios durante el proceso de construcción de un software: – Son inevitables – Provocan confusión e incertidumbre – Pueden ocurrir en cualquier momento

• Estos cambios aumentan conforme avanza el tiempo.

Gestión configuración software

• “El arte de coordinar el desarrollo de software para minimizar…la confusión, se denomina gestión de la configuración. La gestión es el arte de identificar, organizar y controlar las modificaciones que sufre el software…la meta es maximizar la productividad minimizando errores.” Babich [BAB86].

Gestiรณn configuraciรณn software

โ ข La planificaciรณn de la GCS empieza durante las primeras fases del proyecto y debe definir el o los documentos que se controlarรกn. Aquellos documentos que puedan requerirse para el futuro mantenimiento del software, deberรกn ser identificados y especificados como documentos de control.

Gestión configuración software

• El plan de la GCS incluye: • • • •

La identificación de los ECS La asignación de responsabilidades Las políticas de la GCS La definición de archivos de la GCS que deben ser controladas. • La definición de la base de datos • Puede incluir información de software externo, proceso de

Gestión configuración software

• El proceso se puede definir en cinco tareas de GCS: • • • • •

Identificación Control de versiones Control de cambios Auditorias de configuración Generación de informes

Gestión de Riesgos

• La administración de riesgos incluye la detección de riesgos y el control de los mismos. • ¿Qué es el riesgo? • Es la probabilidad de que una actividad no deseada ocurra. • Todas las actividades tienen riesgo. No existe una actividad 100% ni 0% riesgosa.

Gesti贸n de Riesgos

Gestión de Riesgos

• Los riesgos son generalmnete calculados por el producto de la probabilidad de ocurrencia de la amenaza vs los impactos que tendría el activo de materializarse dicha amenaza. • Los riesgos generalmente son calculados a nivel estadístico como el número de frecuencia en que ha ocurrido un evento contra el número total de

Gestión de Riesgos

• Existen muchas metodologías para calcular el riesgo. Todas ellas dependen de los usuarios dado que se estiman. • Los riesgos se estiman en niveles generalmente: alto, medio y bajo. Aunque las escalas pueden variar. • Lo más importante es tener un plan de contingencia.

Gesti贸n de Riesgos

Nivel de Riesgo

Gesti贸n de Riesgos Impacto

Frecuencia

Muy Alto

Alto

Medio

Alto

Medio

Alto

Medio

Alto

Bajo

Medio

Bajo

Medio

Bajo

Alto

Medio

Bajo

Medio

Bajo

Otra categoría de riesgos Riesgos conocidos Tipos de Riesgos

Riesgos predecibles Riesgos impredecibles

Son aquellos que se pueden descubrir con una cuidadosa evaluación del plan del proyecto de su entorno técnico Son aquellos que podemos extrapolar de proyectos anteriores o de nuestra experiencia Son extremadamente difíciles de identificar

*Los riesgos se deben identificar y tratar de minimizarlos **Se deben priorizar los riesgos

Ejemplo de Riesgos Riesgo

Tipo de riesgo

Rotación del personal

Proyecto

Cambio de administración

Proyecto

Hardware indisponible

Proyecto

Cambio de requerimientos

Proyecto y producto

Retrasos en la especificación

Proyecto y producto

Subestimación del tamaño

Proyecto y producto

Bajo desempeño de la herramienta CASE

Producto

Cambio de tecnología

Negocio

Competencia del producto

Negocio

TIPO DE RIESGO

Ejemplo de Riesgos

EJEMPLOS DE POSIBLES RIESGOS

la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba los componentes de software a reutilizar tienen defectos que limitan su funcionalidad

Tecnología: se derivan de tecnología de SW o HW

Personal: asociadas al equipo de desarrollo

o o

imposible contratar personal con los conocimientos requeridos personal clave enfermo o no disponible en momentos críticos

Organizacionales: al entorno donde se desarrolla el software

o o

la organización se reestructura y una nueva administración se responsabiliza del proyecto los problemas financieros de la organización reducen el presupuesto del proyecto

Herramientas: asociado a herramientas case y de apoyo

o o

las herramientas CASE generan código ineficiente las distintas herramientas CASE no se pueden integrar

Requerimientos: derivado de los cambios requeridos por el cliente

o o

cambios de requerimientos que precisan modificaciones en el diseño los clientes no comprenden el impacto de los cambios en los requerimientos

Estimación: derivado de los estimados administrativos y los recursos requeridos

o o o

el tiempo requerido para desarrollar el software está subestimado la tasa de reparación de defectos está subestimada el tamaño del software está subestimado

Riesgos en OpenUP Riesgos técnicos

Riesgos No técnicos

1. Riesgos relacionados con nuevas tecnologías. 2. Riesgos relativos a la arquitectura. 3. Riesgos relativos a construir el sistema adecuado, es decir, que cumpla con su objetivo y con sus usuarios. 4. Riesgos relativos al rendimiento.

1. Gente sin experiencia en el proyecto 2. El calendario propuesto del cliente es muy corto. 3. El cliente no realiza las aprobaciones en el tiempo establecido 4. Existan terceras personas subcontratadas con las que no se ha trabajado antes.

Riesgo

Control de Riesgos Estrategia

Problemas financieros de la organización

Preparar un documento breve para la dirección de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio

Problemas de reclutamiento

organizar cursos de capacitación para el personal ya existente, investigar la posibilidad de contratar en otras regiones o países

Enfermedad del personal

reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del equipo comprendan el trabajo de los demás

Componentes defectuosos

reemplazar los componentes defectuosos con los comprados de fiabilidad conocida

Cambios en los requerimientos

rastrear la información para valorar el impacto de los requerimientos, maximizar la información oculta en ellos

Reestructuración organizativa

preparar un documento breve para la dirección de la empresa que muestra que el proyecto hace contribuciones muy importantes a las metas del negocio

Rendimiento de la base de datos

Tiempo de desarrollo subestimado

investigar la posibilidad de comprar una base de datos con el rendimiento preciso

alertar al cliente de las dificultades potenciales y las posibilidades de retraso

¿Qué tiene más calidad?

• Los dos tienen la misma calidad siempre y cuando cumplan con sus requerimientos

Para ello debemos probar sus especificaciones

Calidad del software Introducción

• La calidad es un concepto muy asbtracto de definir. • Algunas definiciones básicas de calidad: • Cualidad o conjunto de cualidades de una persona o cosa que permiten compararla con otras de su especie. • Enfocadas

cumplimiento

los

Calidad del software Introducción

• Orientados hacia la satisfacción del cliente. • Orientados hacia la productividad (0 defectos) • Tipos de Calidad

GESTIÓN DE LA CALIDAD

Calidad del software Introducción

• Algunos ejemplos de falta de calidad en el software: • El programa no está probado • El sistema operativo está incompleto • No están escritos los requisitos • Estamos fuera de tiempo en un proyecto

Control de Calidad

• Es una actividad que se debe desarrollar a lo largo del proceso de desarrollo de software, el cual incluye: – Políticas de calidad – Métodos y herramientas de software efectivo – Revisiones Técnicas Formales – Prueba Multiescalares – Documentación – Manejo de métricas e indicadores – etc.

Control de Calidad

• La calidad debe de ser mensurable.

• La garantía o aseguramiento de la calidad (QA , Quality Assurance) sólo se puede realizar a través de un proceso de seguimiento, por lo tanto la calidad también se planea en el sentido de las técnicas que se usarán para lograr el éxito del proyecto. • La calidad como todo proceso tiene costo, pero es más costoso no tener calidad.

Control de Calidad

• El proceso más básico de control de calidad es la inspección, que en el área de desarrollo de software son los RTF. • Los RTF sirven de filtro para detectar y corregir defectos. Generalmente se aplican en la etapa de diseño que es donde hay más errores de desarrollo (50-60%). • Se debe de revisar al producto no al personal.

Control de Calidad

• Se debe tener una agenda (plan de trabajo) • Se deben evitar impugnaciones • Los problemas se enuncian más no se resuelven en ese momento • Deben existir reuniones periódicas • El control de calidad por excelencia es el control estadístico.

Referencias

• (Weitzenfeld, 2007) Ingeniería de Software Orientada a Objetos con UML, Java e Intrnet, Thomson. • (ITM 2007) Material de Libro de Texto de la materia de Planificación y Modelado, Instituto Tecnológico de Morelia. • (Sánchez, M. 2009) Material del Curso de Planificación y Modelado.

多Preguntas?