Software Planning Juan Carlos Olivares Rojas MSN: [email protected]...
-
Upload
silvia-dominguez-agueero -
Category
Documents
-
view
222 -
download
0
Transcript of Software Planning Juan Carlos Olivares Rojas MSN: [email protected]...
Software Planning
Juan Carlos Olivares Rojas
MSN: [email protected]@itmorelia.edu.mx
http://antares.itmorelia.edu.mx/~jcolivar/@jcolivares
Social Network: Facebook, LinkedIn. Hi5
• 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.
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
• Alto costo de mantenimiento, etc.
Planificación del tiempo
Planificación
GESTION DEPROYECTOS
•Propuesta•Planificación•Supervisión
•Personal•Informal
PLANIFICACIÓN
Planificación del tiempo
(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
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.
Gestión de Proyectos
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.
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).
Planificación del Proyecto
• 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
WBS
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.
Métricas del Software
• 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
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 del Software
• 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.
Métricas Orientadas al Tamaño
• 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].
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 auditoría, etc.
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 configuración software
• 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
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
• 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?