Software Planning

Software Planning

Juan Carlos Olivares Rojas

MSN: [email protected]@itmorelia.edu.mx

http://antares.itmorelia.edu.mx/~jcolivar/@jcolivares

Social Network: Facebook, LinkedIn. Hi5

http://antares.itmorelia.edu.mx/~jcolivar/

• 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 conciliar()

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.

Clase pasada

¿Qué es esto?

• 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;}

Especificación Formal

• 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.


• 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.


• 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.


• 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.


• 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

• Alto costo de mantenimiento, etc.


Planificación

GESTION DEPROYECTOS

•Propuesta•Planificación•Supervisión

•Personal•Informal

PLANIFICACIÓN


(calendarización)

Estimación de costos (esfuerzo)

Gestión de riesgos y control de calidad

Gestión de laconfiguración de

sw

• El proceso de gestión de proyectos consiste básicamente en:

Establecer las prioridades de un proyectoHacer la valoración inicial de las

actividades del proyectoDefinir los hitos del proyecto y productos a

entregarMientras el proyecto no se haya terminado

o cancelado repetirBosquejar la programación en el tiempo del

proyectoIniciar actividades conforme a la programación

Gestión de Proyectos

Esperar (por un momento)Revisar el progreso del proyectoRevisar los estimados de los parámetros del

proyectoActualizar la programación del proyectoRenegociar las restricciones del proyecto y los

productos a entregarSi surgen problemas entonces

Iniciar la revisión técnica

Fin si

Fin mientras


• 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

• 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 acabo.


• 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


• 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.


• 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).


• 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).

Diagrama de Planeación

TareaT1 T2 T3

T4 T5 T6 T7 T8 T9 T10 T11 T12

Duración (días) 8 15 15 10 10 5 20 25 15 15 7 10

Dependencias

T1 (M1)

T2,T4(M2)

T1,T2(M3)

T1 (M1)

T4(M5)

T3, T6

(M4)

T5, T7

(M7)

T9(M6)

T11 (M8)

• 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:

• 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.

Matriz de Tiempo

6

)4( pmoe

tttt

• Se recomienda usarlos cuando son menos de 20 actividades y el tiempo es breve.

Diagrama de Gantt

• Se deben considerar siempre la asignación de recursos humanos a las actividades.

Diagrama de Planeación

Tarea Ingeniero

T1 Jane

T2 Anne

T3 Jane

T4 Fred

T5 Mary

T6 Anne

T7 Jim

T8 Fred

T9 Jane

T10 Anne

T11 Fred

T12 Fred

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

Diagrama PERT

Diseño GUI

6 14 days

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

Diseño Base de datos

7 21 days

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

ProgramaciónBD

9 21 days

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

Prueba de usabilidad

10 7 days

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

Prueba de la BD

11 7 days

Thu 1/21/99 Fri 1/29/99

Prueba del sistema

12 10 days

Mon 2/1/99 Fri 2/12/99

Escribir manual deusuario

14 7 days

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

Entrenamientodeusuarios

15 5 days

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

ProgramaciónGUI

8 7 days

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

Revisión del diseño

5 1 day

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

• 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.

Time Boxing

• 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

• 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.

Evaluación del costo beneficio

• 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.


• Un ingeniero de software recopila medidas y 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


• 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.


• 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.


•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.


• 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


• ¿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.


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

• Realizando un buen modelado los costos son calculados de mejor forma.

Otras métricas

Visión Diagrama Elemento básico

Funcional Diagrama de FD BurbujaDiccionario de datos Dato elemental

Datos Diagrama E/R Objetos y Relac.Estado Diagrama de Trans. Estados Estado y transiciones

• 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.

Otras métricas

• 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ét. Orientadas a la Función

• 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.

• Se deben de tomar en cuenta las condicionales

Más Métricas

• Estructuras de DecisiónMás Métricas

x

x

x

Secuencia Si x entonces...Hacer ... hasta x

Mientras x hacer...

• 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 complejidad. Se recomienda que sea menor que 10.

Más Métricas

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

Más Métricas

Abrir archivosLeer archivo ventasLimpiar línea de impresiónWHILE (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

Ejemplo

ELSE sumar venta extranjero a total

extranjero ENDIF Leer archivo de ventas ENDWHILE Escribir linea de listado Limpiar área de impresiónENDWHILE;Cerrar archivos

Más Métricas

Más Métricas

• 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 basados en ecuaciones.

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:

Estimación

E = A + B X (ev) cE = A + B X (ev) c

• 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

Estimación

• 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, Técnicos/hardware/ software.

Desarrollar o Comprar

• 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 informes.

Estudio de viabilidad

Estudio de viabilidad

ViablidadTécnica

ViabilidadEconómica

ViabilidadOperativa

• 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 Económica

• En caminada los recursos tecnológicos, humanos (capacidades).

• Los recursos tecnológicos pueden estar dados con respecto al hardware y software.

• Los recursos humanos enfocados al conocimiento y dominio de las tecnologías.

• Todos estos recursos implican costos.

Viabilidad Técnica

• 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.

Viabilidad Operativa

• 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].


• 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.


• 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 auditoría, etc.


• 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


• 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 eventos disponibles.

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

Gestión de Riesgos

Gestión de RiesgosNivel de Riesgo Impacto Frecuencia

Muy Alto Alto Alto

Alto Alto Medio

Alto Medio Alto

Medio Alto Bajo

Medio Medio Medio

Medio Medio Bajo

Medio Bajo Alto

Medio Bajo Medio

Bajo Bajo Bajo

Otra categoría de riesgos

Riesgos conocidos

Riesgos predecibles

Riesgos impredecibles

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

Tipos de

Riesgos

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

Ejemplo de RiesgosRiesgo 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

Ejemplo de RiesgosTIPO DE RIESGO EJEMPLOS DE POSIBLES RIESGOS

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

o la base de datos que se utiliza en el sistema no puede procesar tantas transacciones por segundo como se esperaba

o los componentes de software a reutilizar tienen defectos que limitan su funcionalidad

Personal: asociadas al equipo de desarrollo

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

Organizacionales: al entorno donde se desarrolla el

software

o la organización se reestructura y una nueva administración se responsabiliza del proyecto

o los problemas financieros de la organización reducen el presupuesto del proyecto

Herramientas: asociado a herramientas case y de

apoyo

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

Requerimientos: derivado de los cambios requeridos

por el cliente

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

requerimientos

Estimación: derivado de los estimados

administrativos y los recursos requeridos

o el tiempo requerido para desarrollar el software está subestimadoo la tasa de reparación de defectos está subestimadao 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 proyecto2. 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.

Control de RiesgosRiesgo 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 reclutamientoorganizar cursos de capacitación para el personal ya existente, investigar

la posibilidad de contratar en otras regiones o países

Enfermedad del personalreorganizar el equipo de tal forma que se solapen el trabajo y los

miembros del equipo comprendan el trabajo de los demás

Componentes defectuososreemplazar los componentes defectuosos con los comprados de

fiabilidad conocida

Cambios en los requerimientosrastrear la información para valorar el impacto de los requerimientos,

maximizar la información oculta en ellos

Reestructuración organizativapreparar 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

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

Tiempo de desarrollo subestimado

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 especificacione

s

Calidad del software• 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 al cumplimiento de los requerimientos.

Introducción

Calidad del software• Orientados hacia la satisfacción del

cliente.• Orientados hacia la productividad (0

defectos)• Tipos de Calidad

Introducción

GESTIÓN DE LA CALIDAD

Calidad del software• 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

Introducción

• 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.

Control de Calidad

• (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.

Referencias

¿Preguntas?

Software Planning

Documents

Transcript of Software Planning