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
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.
¿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
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
• Alto costo de mantenimiento, etc.
Planificación
Planificación del
tiempo
GESTION DE
PLANIFICACIÓ (calendarización)
N
PROYECTOS
Estimación de
•Propuesta costos (esfuerzo)
•Planificación
•Supervisión
•Personal Gestión de riesgos y
•Informal 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 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).
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 T4 T5 T6 T7 T8 T9 T10 T11 T12
T1 T2 T3
Duración (días) 8 15 15 10 10 5 20 25 15 15 7 10
T1 T2,T4 T1,T2 T1 T4 T3, T6 T5, T7 T9 T11
(M1) (M2) (M3) (M1) (M5) (M4) (M7) (M6) (M8)
Dependencias
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
• 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
T1 Jane
T2 Anne
T3 Jane
T4 Fred
T5 Mary
T6 Anne
T7 Jim
T8 Fred
T9 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 GU I Prueba de usabilidad
8 7 day s 10 7 day s
Mon 12/ 14/98Tue 12/ 22/ 98 Thu 12/ 31/ 98
Wed 12/23/ 98
Diseño GU I
6 14 day s
Tue 11/ 24/ 98 Fri 12/ 11/98 Prueba del sist ema
Rev isióndel diseño Escribir manual de Ent renamient ode
usuario usuarios 12 10 day s
5 1 day 14 7 day s 15 5 day s Mon 2/1/99 Fri 2/ 12/99
Mon 11/ 23/98Mon 11/ 23/98 Mon 12/ 14/98Tue 12/ 22/ 98 Tue 12/ 29/ 98
Wed 12/23/ 98
Diseño Base de datos Programación BD Prueba de la BD
7 21 day s 9 21 day s 11 7 day s
Tue 11/ 24/ 98 Tue 12/ 22/ 98 Wed 1/20/ 99
Wed 12/23/ 98 Thu 1/ 21/ 99 Fri 1/ 29/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
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 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 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 Burbuja
Diccionario de datos Dato elemental
Datos Diagrama E/R Objetos y Relac.
Estado Diagrama de Trans. Estados Estado y transiciones
• Realizando un buen modelado los costos
son calculados de mejor forma.
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.
• Se deben de tomar en cuenta las
condicionales
Más Métricas
• Estructuras de Decisión
x
x
x
Hacer ... Mientras x
Secuencia Si x entonces... hasta 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
complejidad. Se recomienda que sea
menor que 10.
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
Más Métricas
ELSE
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
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:
E = A + B X (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,
Técnicos/hardware/ software.
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 informes.
Estudio de viabilidad
Viablidad
Viabilidad Viabilidad
Técnica
Económica Operativa
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 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 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 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 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
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
Nivel 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
Son aquellos que se pueden descubrir
Riesgos conocidos con una cuidadosa evaluación del plan
del proyecto de su entorno técnico
Tipos de Riesgos
Son aquellos
predecibles podemos extrapolar de
que
proyectos anteriores o de
Riesgos nuestra experiencia
Son
Riesgos impredecibles 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 Producto
herramienta CASE
Cambio de tecnología Negocio
Competencia del producto Negocio
Ejemplo de Riesgos
TIPO DE RIESGO EJEMPLOS DE POSIBLES RIESGOS
o la base de datos que se utiliza en el sistema no puede procesar tantas
Tecnología: se derivan de transacciones por segundo como se esperaba
tecnología de SW o HW o los componentes de software a reutilizar tienen defectos que limitan su
funcionalidad
Personal: asociadas al equipo de o imposible contratar personal con los conocimientos requeridos
desarrollo o personal clave enfermo o no disponible en momentos críticos
Organizacionales: al entorno o la organización se reestructura y una nueva administración se responsabiliza del
donde se desarrolla el proyecto
software o los problemas financieros de la organización reducen el presupuesto del proyecto
Herramientas: asociado a
o las herramientas CASE generan código ineficiente
herramientas case y de
o las distintas herramientas CASE no se pueden integrar
apoyo
Requerimientos: derivado de los
o cambios de requerimientos que precisan modificaciones en el diseño
cambios requeridos por el
o los clientes no comprenden el impacto de los cambios en los requerimientos
cliente
Estimación: derivado de los o el tiempo requerido para desarrollar el software está subestimado
estimados administrativos y o la tasa de reparación de defectos está subestimada
los recursos requeridos o el tamaño del software está subestimado
Riesgos en OpenUP
1. Riesgos relacionados con nuevas
Riesgos tecnologías.
técnicos 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
Riesgos No 2. El calendario propuesto del cliente es muy
técnicos 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 Riesgos
Riesgo Estrategia
Problemas financieros de la Preparar un documento breve para la dirección de la empresa que muestra que el
organización proyecto hace contribuciones muy importantes a las metas del negocio
organizar cursos de capacitación para el personal ya existente, investigar la
Problemas de reclutamiento
posibilidad de contratar en otras regiones o países
reorganizar el equipo de tal forma que se solapen el trabajo y los miembros del
Enfermedad del personal
equipo comprendan el trabajo de los demás
Componentes defectuosos reemplazar los componentes defectuosos con los comprados de fiabilidad conocida
rastrear la información para valorar el impacto de los requerimientos, maximizar la
Cambios en los requerimientos
información oculta en ellos
preparar un documento breve para la dirección de la empresa que muestra que el
Reestructuración organizativa
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
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 al cumplimiento de los
requerimientos.
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
• 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?