Transcript Clase modelo

Planificación del Sistema
M.C. Juan Carlos Olivares Rojas
[email protected]
http://antares.itmorelia.edu.mx/~jcolivar/
[email protected]
@jcolivares
Febrero 2010
Competencias
• Específica: Realiza la planificación de un
proyecto de software de una organización
• Genéricas
• Instrumentales: Capacidad de análisis y
síntesis, Capacidad de organizar y planificar,
Conocimientos básicos de la carrera,
Comunicación oral y escrita en su propia
lengua, Habilidades de gestión de información,
Solución de problemas, Toma de decisiones.
Competencias
• Interpersonales: Capacidad crítica y autocrítica,
Capacidad de trabajar en equipo interdisciplinario,
Capacidad de comunicarse con profesionales de
otras áreas, Compromiso ético.
• Sistémicas:
Habilidades
de
investigación,
Capacidad de adaptarse a nuevas situaciones,
Capacidad de generar nuevas ideas (creatividad),
Liderazgo, Capacidad para diseñar y gestionar
proyectos, Iniciativa y espíritu emprendedor,
Preocupación por la calidad, Búsqueda del logro.
Saberes
• Planificación del tiempo.
• Evaluación del costo beneficio.
• Estudio de viabilidad.
• Planificación de la documentación.
• Gestión de la configuración del software.
Evidencias
• 10% Actividades realizadas en el salón de
clases evaluables
• 30% Contracto del Proyecto
• 60% Actividad de Evaluación Final (TeóricoPráctico)
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).
• La planeación es todo un arte. En metodologías
ágiles como XP se le llama el “juego de la
planeación” dado que una vez que se ha
planeado es necesario replanear.
• La planeación no tiene un formato estándar.
Planificación del tiempo
• 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. Esto
quiere decir que su revisión es continua, ya que
tanto requerimientos como restricciones
pueden cambiar a lo largo del desarrollo.
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
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
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
Actividades
• En sus equipos de trabajo
planeación de su proyecto.
realicen
la
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)
Dependencias
T1
T2
T3
8
15
15
T1
(M1)
T4
T5
T6
T7
T8
T9
T10
T11
T12
10
10
5
20
25
15
15
7
10
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  4tm  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 Planeación
• Al ser un grafo se pueden aplicar muchas
técnicas para optimizar los proyectos.
3
10
1
6
2
4
7
11
5
9
8
12
Es el tiempo mínimo
requerido para finalizar el
proyecto
Diagrama de Gantt
• Se recomienda usarlos cuando son menos de
20 actividades y el tiempo es breve.
Ruta Crítica
• Los métodos de optimización de planeación
como CPM (Método de la ruta crítica) y PERT
(Program Evaluation and Review Technice)
ayudan a encontrar las mejores alteranativas
de soluciónde un proyecto.
• ¿Qué diferencias existente?
• CPM es estático en PERT se toman tiempos de
inicio y fin optimistas y pesimistas.
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ónGUI
Prueba de usabilidad
8
10
7 days
7 days
Mon 12/14/98T ue 12/22/98
Wed 12/23/98T hu 12/31/98
Revisión del diseño
Escribirmanual de
usuario
Entrenamientode
usuarios
12
10 days
5
14
15
Mon 2/1/99
Fri 2/12/99
Diseño GUI
6
14 days
Prueba del sistema
T ue 11/24/98Fri 12/11/98
1 day
Mon 11/23/98Mon 11/23/98
7 days
5 days
Mon 12/14/98T ue 12/22/98
Wed 12/23/98T ue 12/29/98
Diseño Base de datos
ProgramaciónBD
Prueba de la BD
7
9
11
21 days
T ue 11/24/98T ue 12/22/98
21 days
Wed 12/23/98Wed 1/20/99
7 days
T hu 1/21/99 Fri 1/29/99
Actividad
• Tarea: próximo viernes 19 de Febrero traer una
laptop por equipo con un software de
administración de proyectos como MS-Project,
Mr. Project, WinProject, etc.
• Crear una cuenta en google calendar.
• Para ahorita determinar un diagrama de
planeación y su matriz del tiempo incluyendo:
actividad, dependencias, desgloce de tiempos
estimados.
Time Boxing
• Se tiene bien definido las fechas de entrega y a
partir de allí se realiza una planeación hacia
atrás.
• El producto final se entregará el viernes 4 de
junio. En caso de retraso hasta el miércoles 9
de junio se considerará nivelación, hasta el
viernes 11 de junio se considerará
extraordinario.
• Habrá un hito de revisión el viernes 7 de mayo.
TimeBoxing
• El contrato ya negociado se entregará el
viernes 5 de marzo por lo que el inicio formal
del proyecto es el lunes 8 de marzo.
• El seguimiento del proyecto se reportará hasta
el tercer parcial.
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
• El trabajar con WBS hace fácil y comprensible
las actividades de desarrollo así como la
asignación de personal a las actividades del
proyecto en base a un organigrama
1
2
3
Instalar LotusNotes para apoyar el desarrollo de un proyecto
Instalar
servidor
Instalar
cliente local
Instalar
cliente remoto
Diseñar BD
Programar BD
WBS
Administración de Proyectos
WBS
WBS
Herramientas Admon. Proyectos
• Existen muchas herramientas para la
administración de proyectos que en esencia
tienen las mismas carácterísticas básicas.
• La primera actividad consiste en determinar las
fechas de inicio y fin del proyecto así como
especificar opciones del calendario, como días
y horas laborales, etc.
Herramientas Admon. Proyectos
• Se pueden tener varias vistas del proyecto, de
manera predeterminada se pone el diagrama
de Gantt.
• Para obtener el CPM se puede utilizar el
Asistente para Diagrama de Gantt el cual
permite especificar la ruta crítica.
• El avance se puede realizar con una curva del
proyecto indicando objetivos cumplidos y en
que tiempo.
Herramientas Admon. Proyectos
• Cuando se inserta un recurso se asume que
existe un 100% del recurso, es decir, existe un
solo recurso para el proyecto.
• Para asignar recursos se puede utilizar el
asistente o la hoja de recursos.
• Existen diversos tipos de costos: por uso (que
dependen del tiempo) y fijos (que son
constantes en la duración del proyecto).
Herramientas Admon. Proyectos
• También se pueden considerar tasas estándar
y tasas por hora extra.
• El project nos permite recalcular tiempos,
asignación de recursos e hitos cuando ocurren
cambios de manera muy similar a una hoja de
cálculo.
• La fórmula mágica de la gestión de proyectos
es: Trabajo = Duración * Unidades.
Herramientas Admon. Proyectos
• Lo importante es llevar un control sobre el % de
las actividades completadas y guiarnos con el
tiempo.
• Se pueden realizar informes y reportes más
llamativos del proyecto.
Actividad
• Realizar el WBS del proyecto por equipo de
trabajos. El WBS tendrá un anidamiento
máximo de tres niveles (1.1.1)
• Se mostrará en forma de árbol o de glosario,
para cada nodo hoja se hará la estimación del
tiempo esperado y se definirá el entregable de
cada paquete.
Evaluación del costo beneficio
• En todo proyecto que se desarrolle siempre es
importante conocer si es realmente es costoefectivo 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
• El costo de los sistemas de información
actualmente es del 90% por lo que una mala
estimación puede originar que un proyecto se
cancele, salga más costoso o requiera de más
tiempo de desarrollo.
• 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
Indicadores del Proceso
• Brindan una visión profunda sobre la eficacia
de un proceso ya existente.
• Permiten evaluar lo que está y no funcionando.
• Su propósito es mejorar los procesos de
software a largo plazo y conducir a estrategias
que permitan mejorar la calidad del proceso.
Indicadores del Proyecto
• Son utilizadas para supervisar el progreso
durante el desarrollo de software y controlar la
calidad del producto, además se utilizan para
realizar las estimaciones de tiempo y esfuerzo.
Permiten al gestor de proyecto:
• Evaluar el estado del proyecto
• Seguir las pistas de los riesgos potenciales.
Indicadores del Proyecto
• Detectar las áreas de problemas para evitar
áreas críticas
• Ajustar el flujo y las tareas del trabajo
• Evaluar la habilidad del equipo del proyecto
para controlar la calidad del producto de
software.
Métricas del Software
• Una métrica del software es la aplicación
continua de técnicas basadas en las medidas
de los procesos de desarrollo del software y
sus productos, para producir una información
de gestión significativa y a tiempo. Esta
información se utilizará para mejorar esos
procesos y los productos que se obtienen de
ellos.
• Las métricas aplican a todas las etapas del
ciclo de vida del desarrollo de software.
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.
Métricas Orientadas al Tamaño
Ventajas:
• Que son fáciles de calcular en cualquier
proyecto
• Existen varias herramientas de estimación
basadas en las líneas de código
Desventajas:
• la falta de una definición universal de
línea de código.
Métricas Orientadas al Tamaño
Desventajas:
• las líneas de código dependen de los
lenguajes de programación.
• El estilo de programación dependerá de
cada persona.
• El decidir que líneas de código se
contabilizaran ya sean nuevas, líneas
modificadas, reutilizadas más definiciones
de datos y comentarios.
• dificultad de estimar en fases tempranas
del desarrollo la cantidad de líneas que
tendrá una aplicación.
Actividad
• Dada la siguiente aplicación determinar la
cantidad de líneas de texto (total de los
archivos) y la cantidad de LOCs.
Distinguir las líneas de comentarios de los
espacios en blanco.
• En base a las estimaciones anteriores
calcular el nivel real de comentarios en el
programa.
• ¿cuántas LOCs estiman en su proyecto?
Otras métricas
• Se pueden tener métricas enfocadas a
mejorar la legibilidad del código fuente
como número de variables declaradas
que no se utilizan, si los nombres de los
identificadores son representativos, si se
sangra el código, etc.
• PUNTOS EXTRAS: TRES en el parcial.
Herramienta gráfica que permita contabilizar
LOCs,
NCLOCs,
CLOCs
(separando
comentarios de blancos). Para entregar
mañana al final de la clase.
Otras métricas
• La métrica de LOC no toma en cuenta el
concepto de reutilización ni el concepto de
costes fijos ni tareas que se desarrollan
que no producen instrucciones. Por ello,
no debe ser utilizada esta medida
directamente en la estimación de esfuerzo
o productividad.
• Una mejor métrica para el tamaño de un
software puede estar representado por
medir la longitud en términos de número
de bytes de almacenamiento requerido
para contener el texto del programa.
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
• Realizando un buen modelado los costos
son calculados de mejor forma.
Otras métricas
• Como se pudo observar una métrica tan
sencilla como los LOC (SLOC -Source
LOC-) tiene su complejidad algo alta y
una eficiencia no del todo buena.
Considerese:
Nombre
Nº
del
de
Costo Nº de
$
proyect Person
o
Nº de
Esfuerzo
error páginas de empleado
es
Líneas
de
documenta (días/hom código
as
ción
bre)
(LDC)
Proy1
15
20Mil
520
320
1200
3220
Proy2
10
17Mil
380
450
1000
2800
Otras métricas
• Calcúlese para los dos proyectos:
•
•
•
•
Productividad =LDC / persona mes
Costo Unitario = $ / LDC
Grado de errores = Nº de errores / LDC
Grado de documentación =
Nº de
páginas documentadas / LDC
• NÓTESE: LAS MEDICIONES SON
DATOS HISTÓRICOS.
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.
Puntos de Función
• Es una métrica sintética que se compone
de la suma ponderada de los siguientes
parámetros:
Mét. Orientadas a la Función
• Ejemplos de entradas: pantallas de
datos llenadas por usuarios, cintas
magnéticas, discos flexibles, entradas
sensoriales, por lápiz magnético, clicsde
ratón.
• Ejemplos de salidas: pantallas de datos
de salidas, informes impresos, archivos
en disco flexible, sets de cheques,
facturas impresas.
Mét. Orientadas a la Función
• Ejemplos de archivos internos lógicos:
Un archivos plano, una tabla de una base
de datos relacional.
• Ejemplos de (archivos externos lógicos
de) interfaz: bases de datos compartidas,
archivos lógicos direccionables desde o
hacia otra aplicación.
•Consultas externas: consulta de un
usuario sin actualizar un archivo,
mensajes de ayuda, mensajes de
selección.
Mét. Orientadas a la Función
• Ejemplos de archivos internos lógicos:
Un archivos plano, una tabla de una base
de datos relacional.
• Ejemplos de (archivos externos lógicos
de) interfaz: bases de datos compartidas,
archivos lógicos direccionables desde o
hacia otra aplicación.
•Consultas externas: consulta de un
usuario sin actualizar un archivo,
mensajes de ayuda, mensajes de
selección.
Factores de Ajuste
• C1 comunicación de datos
• C2 funciones distribuidas
• C3 objetivos de performance
• C4 configuración usada fuertemente
• C5 tasa de transacciones
• C6 entrada de datos en línea
Factores de Ajuste
• C7 eficiencia del usuario final
• C8 actualización en línea
• C9 procesamiento complejo
•
•
•
•
•
C10 reusabilidad
C11 facilidad de instalación
C12 facilidad operacional
C13 sitios múltiples
C14 facilidad del cambio
Escala de Ajuste
• 0 factor no presente o sin influencia
• 1 influencia insignificante
• 2 influencia moderada
• 3 influencia promedio
• 4 influencia significativa
• 5 influencia fuerte
Escala de Ajuste
• Comunicación de datos: La evaluación
se reflejaría en un 0 para aplicaciones
batch, y un 5 para aplicaciones en que
predomina el teleproceso.
• Funciones distribuidas: La evaluación
arrojaría un 0 para aplicaciones
monolíticas puras, y un 5 para
aplicaciones
que
se
ejecutan
dinámicamente en varios procesadores.
Escala de Ajuste
• Objetivos de performance: la evaluación
sería un 0 si no hay establecido ningún
criterio especial de performance por los
usuarios, y un 5 si los usuarios insisten en
objetivos de performance muy rigurosos
que requieren un esfuerzo considerable
para ser logrados.
• Configuración usada fuertemente: la
evaluación sería un 0 si la aplicación no
tiene restricciones especiales de uso, y un
5 si el uso anticipado requiere especial
esfuerzo para ser logrado.
Escala de Ajuste
•Tasa de transacciones: la evaluación
sería un 0 si el volumen de transacciones
no es significativo, y un 5 si el volumen es
lo suficientemente significativo como para
producir stress en la aplicación.
• Entrada de datos en línea: la evaluación
sería un 0 si menos del 15% de las
transacciones son interactivas, y un 5 si
más del 50% de las transacciones son
interactivas.
Escala de Ajuste
•Eficiencia del usuario final: la evaluación
sería un 0 si no hay usuarios finales o no
hay requerimientos especiales para los
usuarios finales, y un 5 si los
requerimientos de eficiencia de usuarios
finales son lo suficientemente rígidos
como para requerir un esfuerzo.
• Actualización en línea: la evaluación
sería un 0 si no hay, y un 5 si las
actualizaciones
son
obligatorias
y
especialmente difíciles, quizás debido a la
necesidad de proteger datos.
Escala de Ajuste
• Procesamiento complejo: la evaluación
sería un 0 si no hay, y un 5 en casos que
requieren decisiones lógicas extensas,
matemática compleja, o esquemas de
seguridad elaborados.
• Reusabilidad: la evaluación sería un 0 si
la funcionalidad se planifica para
permanecer local a la aplicación actual, y
un 5 si mucha de la funcionalidad y los
artefactos del proyecto se pretende que
sean usados ampliamente por otras
aplicaciones.
Escala de Ajuste
• Facilidad de instalación: la evaluación
sería un 0 si este factor es insignificante, y
un 5 si la instalación es importante.
•Facilidad operacional: la evaluación sería
un 0 si este factor es insignificante, y un 5
si la facilidad operacional es tan
restrictiva.
• Sitios múltiples: la evaluación sería un 0
si hay solo un sitio planificado de uso, y
un 5 si el proyecto y sus artefactos son
usados en muchos lugares.
Escala de Ajuste
• Facilitamiento del cambio: la evaluación
sería un 0 si el cambio no ocurre, y un 5 si
la
aplicación
se
desarrolla
específicamente para permitir los cambios
rápidos.
• Procedimiento para calcular el factor de
ajuste:
– Sumar las ponderaciones de los 14 criterios (valor
entre 0 y 70)
– Multiplicar la suma por 0.01 para obtener un valor
temporal
– Sumar 0.65 al valor temporal para obtener eñll
factor de complejidad (valor entre 0.65 y 1.35)
Ejemplo
• Suponga una aplicación con 10 entradas,
10 salidas, 10 consultas, 1 archivo de
datos y 1 archivo de interfaz, todos ellos
de complejidad promedio.
• Suponga que los factores de influencia se
determinaron de la siguiente manera: C1,
C2 y C10 = 0; C8 = 2; C4, C5 y C9 = 3;
C3, C6, C7, C11, C12 y C14 = 4; C13 = 5
• El proyecto se considera de complejidad
promedio
Ejemplo
• La suma de los factores de ajuste da 40.
Por lo que el factor de complejidad da: 40
* 0.01 + 0.65 = 1.05
• Se calculan los puntos de función no
ajustado (NAPF):
Ejemplo
• Finalmente se calcula los puntos de
función ajustados: 147 * 1.05 = 154
• En muchas ocasiones los puntos de
función necesitan ser expresados en
KLOC o KSLOC. Esto depende del
lenguaje de programación. Así si el
programa fuera en C se requerirían
19.712 KLOC y si fuera C++ de 4.466
KLOC.
Conversión de Líneas de Código
Ada
Basic Compilado
Basic Interpretado
Ensamblador
C
C++
Visual Basic
Cobol80
Fortran77
Prolog
Pascal
Lisp
Modula2
75
90
128
320
128
29
30
96
185
61
90
61
80
Ejercicio
• Utilizando puntos de Función, suponga
una aplicación con 6 entradas, 15 salidas,
10 consultas, 2 archivo de datos y 2
archivo de interfaz, todos ellos de alta
complejidad.
• Por otra parte suponga que los factores
de influencia se determinaron de la
siguiente manera: C1=1, C2=0, C3=4,
C4=2, C5=2, C6=4, C7=4, C8=4, C9=5,
C10=2, C11=0, C12=3, C13=4, C14=5.
Ejercicio
• Calcule, los puntos de Función, el factor
de complejidad, los puntos de función
ajustados y calcule el SLOC si fuese
desarrollado en C++ y el KSLOC si fuese
desarrollado en JAVA
Tarea
• Calcúlese las líneas de código necesarias
para implementar una aplicación de
control de clientes en lenguaje C estándar
para una empresa de distribución que
apoya su gestión en dos bases de datos:
• Datos de clientes de gran complejidad.
• Un archivo
complejidad.
de
back-up
de
poca
Tarea
• Todo el trabajo se realiza mediante tres
tipos de transacciones distintas para
consultas, altas y bajas de datos. Todas
estas operaciones tienen una complejidad
alta. Para que el sistema de información
esté bien integrado la aplicación deberá
transferir dos archivos de complejidad
media que contienen datos para otras
aplicaciones (contabilidad y dirección por
objetivos). Asimismo, el software debe
generar hasta tres tipos distintos de
informes, de complejidad media, sobre
clientes.
Tarea
• Por último, las consultas trabajarán sobre
dos
posibles
transacciones
de
complejidad baja y una consulta de
ayuda, a plena pantalla, de gran
complejidad. El desarrollo del proyecto se
realizará en un entorno cuyos factores de
costos serán todos de tipo medio excepto
la entrada de datos on-line (valor 5), la
actualización on-line (valor 5) y facilidad
de operación (valor 5).
• Una vez calculadas las LDC necesarias
en C, hallénse también las LDC
necesarias para implementar la aplicación
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
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
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
extranjero
ENDIF
Leer archivo de ventas
ENDWHILE
Escribir linea de listado
Limpiar área de impresión
ENDWHILE;
Cerrar archivos
a
total
Más Métricas
Más Métricas
• NOC (Número de hijos) jerarquía de
relaciones en POO.
• CBO (Acoplamiento de Objetos): número
de asocianes con respecto a una clase
• Tarea: aplicar puntos de casos de uso al
proyecto (leer articulo para ver las
referencias de cómo hacerlo). Se necesita
desarrollen diagramas de caso de uso.
Más Métricas
• Se tienen algunas metodologías y
estándares para la medición y estimación
del software:
• GQM (Goal Question Metric) consiste en
plantearse una serie de objetivos donde
por cada uno de ellos se realizan diversas
preguntas que llevan a tener cada una de
ellas diversas respuestas.
• PSM (Practical Software Measurament)
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:
basados en ecuaciones.
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:
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
Actividad
• Dado el siguiente código determinar:
• Número de Nodos y Aristas del Grafo
• Representación gráfica del grafo
• Determinación
de
la
complejidad
ciclomática a través de las tres fórmulas.
Replaneación
• ¿Qué no ha cambiado ni cambiará?
• El producto final se entregará el viernes 4 de
junio. En caso de retraso hasta el miércoles 9
de junio se considerará nivelación, hasta el
viernes 11 de junio se considerará
extraordinario.
• Habrá un hito de revisión el viernes 7 de mayo.
TimeBoxing
• El contrato ya negociado se entregará el jueves
18 de marzo por lo que el inicio formal del
proyecto es el lunes 22 de marzo.
• Examen de la segunda unidad viernes 19 de
marzo.
• PENDIENTES: Estimación por Casos de Uso.
Tarea
• Examen sobre COCOMO II ejercicio práctico
mañana.
• Favor de leer y aclarar dudas antes de
comenzar clases.
COCOMO
• COnstructive Cost Model es un modelo
algorítmico de estimación de costos de
proyectos de software desarrollado en 1981 y
actualizado en 1999.
• En su primera versión se basa en tres modelos:
básico (nulo), intermedio (despues de Ing. De
Requerimientos) y avanzado (cuando se
termina el diseño). Los tres modelos tienen la
misma fórmula base:
COCOMO
E = aSbFA
donde:
– E: esfuerzo en personas mes
– S: tamaño medido en KLDC
– FA: Factor de ajuste (igual a 1 en el modelo
básico)
– a, b: s/tablas del modelo en función del tipo
de sistema
• Adicionalmente se cuenta con tres tipos
de proyectos:
COCOMO
• Orgánicos: proyectos pequeños de <
50KLDC, en los cuales se tiene
experiencia de proyectos similares
• Semi-acoplado: proyectos de complejidad
media (<
300
KLDC)
donde
la
experiencia es variable.
• Empotrado: proyectos bastante complejos
donde la experiencia es nula y se utiliza
tecnología realmente de frontera.
Tabla COCOMO
Básico
Modo
a
b
c
Intermedio
d
a
b
c
d
Orgánico
2.4 1.05
2.5 0.38 3.2 1.05
2.5
0.38
Semiacoplado
3.0 1.12
2.5 0.35 3.0 1.12
2.5
0.35
Empotrado
3.6 1.2
2.5 0.32 2.8 1.2
2.5
0.32
• Se recomienda en general utilizar el modelo
intermedio.
Tabla COCOMO
Modelo
COCOMO
Básico
COCOMO
Básico/intermedio
COCOMO
Intermedio
Esfuerzo nominal
(En) en personasmes
Tiempo de
desarrollo (Td)
Esfuerzo nominal
(En) en personasmes
2.4 KLOC1.05
2.5 KLOC0.38
3.2 KLOC1.05
Semi-libre
3.0 KLOC1.12
2.5 KLOC0.35
3.0 KLOC1.12
Empotrado
3.6 KLOC1.20
2.5 KLOC0.32
2.8 KLOC1.20
Modelo de
desarrollo
Orgánico
• Se puede representar de esta forma
COCOMO
• Es necesario elegir los constructores de
costos dentro de 15 factores. Es
necesario ajustar dichos factores en una
escala ordinal de 6 puntos: muy baja,
baja,
media,
alta,
muy
alta
y
extremadamente alta.
• Si por ejemplo en la capacidad de análisis
se escoge el factor de 1.46, indica que se
debe aumentar el esfuerzo en 46%
Manejadores de Costo COCOMO
Manejadores de Costo
Very Low
Low
Nominal
High
Very High
Extra
High
ACAP Analyst Capability
1.46
1.19
1.00
0.86
0.71
-
AEXP Applications Experience
1.29
1.13
1.00
0.91
0.82
-
CPLX Product Complexity
0.70
0.85
1.00
1.15
1.30
1.65
DATA Database Size
-
0.94
1.00
1.08
1.16
-
LEXP Language Experience
1.14
1.07
1.00
0.95
-
-
MODP Modern Programming Practices
1.24
1.10
1.00
0.91
0.82
-
PCAP Programmer Capability
1.42
1.17
1.00
0.86
0.70
-
RELY Required Software Reliability
0.75
0.88
1.00
1.15
1.40
-
SCED Required Development Schedule
1.23
1.08
1.00
1.04
1.10
-
STOR Main Storage Constraint
-
-
1.00
1.06
1.21
1.56
TIME Execution Time Constraint
-
-
1.00
1.11
1.30
1.66
TOOL Use of Software Tools
1.24
1.10
1.00
0.91
0.83
-
TURN Computer Turnaround Time
-
0.87
1.00
1.07
1.15
-
VEXP Virtual Machine Experience
1.21
1.10
1.00
0.90
-
-
VIRT Virtual Machine Volatility
-
0.87
1.00
1.15
1.30
-
Manejadores de Costo COCOMO
• Los manejadores de costo se clasiican en 4
categorías:
• Software
– Fiabilidad
– Tamaño de la base de datos
– Complejidad del producto
• Hardware
– Restricciones de tiempo de ejecución
– Restricciones de almacenamiento principal
Manejadores de Costo COCOMO
• Hardware
– Volatilidad de Máquina Virtual
– Tiempo de respuesta de la computadora
• Personal
– Capacidad del analista
– Experiencia en la aplicación
– Capacidad de los programadores
– Experiencia en el Sistema Operativo
– Experiencia en el lenguaje de Programación
Manejadores de Costo COCOMO
• Proyecto
– Prácticas de Programación modernas
– Utilización de herramientas de software
– Limitaciones de planificación
COCOMO II
• Es una variante del modelo tradicional
que cuenta con otros modelos:
• El
modelo
Aplicaciones.
de
Composición
de
– Indicado
para
proyectos
construidos
con
herramientas modernas de construcción de
interfaces gráficos para usuario.
• El modelo de Diseño anticipado.
• Este modelo puede utilizarse para obtener
estimaciones aproximadas del costo de
un proyecto antes de que esté
determinada por completo su arquitectura.
COCOMO II
• El modelo de Diseño anticipado.
– Este modelo puede utilizarse para obtener
estimaciones aproximadas del costo de un proyecto
antes de que esté determinada por completo su
arquitectura. Utiliza un pequeño conjunto de drivers
de costo nuevo y nuevas ecuaciones de
estimación.
• El modelo Post-Arquitectura.
– Este es el modelo COCOMO II más detallado. Se
utiliza una vez que se ha desarrollado por completo
la arquitectura del proyecto. Tiene nuevos drivers
de costo, nuevas reglas para el recuento de líneas
y nuevas ecuaciones.
Comparativa COCOMO I y II
Comparativa COCOMO II
COCOMO
• En muchas ocasiones no solamente es
necesario calcular el esfuerzo sino que
tambien se requiere calcular el tiempo de
desarrollo T=c Ed
• Para determinar la productividad: PR=LDC/E
• Para calcular el Personal promedio: P=E/T
• Nótese que para manejar este modelo se
necesita de métricas de tamaño como LDC o
bien Puntos de Función, etc.
Actividad 1
• En base a la tarea de Puntos de función
previa determine lo siguiente:
• Determine el costo del proyecto si el
modelo es intermedio, el tipo de proyecto
semiacoplado, los manejadores de costos
todos nominales, asumiendo que el
proyecto se realizará en COBOL con un
costo nominal $90,000 persona/año.
Actividad 2
• En el mismo proyecto se desea saber
quien tuvo mayor productividad para
brindarle un aumento de sueldo.
• Cristhian implementó
salidas del sistema.
las
entradas
y
• Carreón implementó los archivos externos
• José Alfredo
consultas.
archivos
externos
y
Actividad 3
• Considerando los siguientes manejadores
de
costos,
¿cómo
quedan
las
estimaciones de las métricas del
proyecto?
• ACAP alto, CPLX bajo, DATA muy alto,
STOR extremedamente alto, todo los
demás de complejidad nominal.
Actividad 4
• ¿Qué cambios son necesarios hacer para
que el proyecto se entregue en tres
meses? ¿y si fuera un solo mes?
• Empezar a desarrollar su estimación de
costos de su proyecto. Recordar que se
aplicará Puntos de Casos de Uso para
estimar la complejidad del software.
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
Técnica
Viabilidad
Económica
Viabilidad
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
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.
al
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.
Planificación documentación
• El plan del proyecto de software se produce
como culminación de la etapa de planificación.
• El plan del proyecto de software es un
documento breve, esta dirigido a una diversa
audiencia y debe :
– Comunicar el alcance y recursos a los gestores del
Software, personal técnico y clientes.
– Definir los riesgos y sugerir planes de contingencia
Planificación documentación
• Definir el costo y el plan temporal para la
revisión de la gestión.
• Proporcionar una aproximación global del
desarrollo del software para toda la gente
involucrada en el proyecto.
• Describir cómo se garantizará la calidad y la
gestión de cambios.
Gestión configuración software
• Los cambios durante el
construcción de un software:
proceso
de
– 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
• Una vulnerabilidad es un factor interno
caracterizado por un hueco de seguridad (una
debilidad del sistema) que puede ser
aprovechada por una amenaza.
• Son factores externos que pueden aprovechar
las vulnerabilidades de un sistema para
exponer a un activo de información.
• Los controles tienden a
amenazas y vulnerabilidades.
minimizar
las
Gestión de Riesgos
• Los riesgos se dan cuando se combina una
amenaza con una vulnerabilidad.
• Los ataques son cuantificados al impacto que
pueden producir, generalmente expresados en
dinero.
• El impacto puede darse por ejemplo al no tener
un recurso disponible causando pérdidas
económicas al no poder trabajar o bien un daño
de imagen social.
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
Gestión de Riesgos
Impacto
Frecuencia
• La forma de estimar
la frecuencia
es si no se
tiene valores estadísticos es a través de
Muymanejar
Alto
Alto
Alto
una tabla
de valoración
entre las
Altoamenazas y las vulnerabilidades
Alto
Medio basadas en la
misma tabla anterior.
Alto
Medio
Alto
Nivel de Riesgo
Medio
Alto
Bajo
•Medio
El valor de las vulnerabilidades
Medio
Medio va a estar en
respuesta a los controles
implementados.
Medio
Medio
Bajo
Medio
Bajo
Alto
•Medio
El impacto se cuantifica
en cuestión
de dinero
Bajo
Medio
aunque
queda
representado
en
forma
Bajo
Bajo
Bajo
Gestión de Riesgos
• Una vez obtenidaImpacto
el riesgo seFrecuencia
puede cuantificar
un % en relación al nivel cualitativo dado. Por
Muyejemplo:
Alto
Alto
si se dan
escalas Alto
de alto, medio y
alto deberá
Altobajo. Salió un riesgo
Alto
Medio estar entre el
67% y 100%
Alto
Medio
Alto
Nivel de Riesgo
Medio
Alto
Bajo
•Medio
Al igual que otros
que se estiman
Medio recursosMedio
como el tiempo, las
actividades
y el dinero; los
Medio
Medio
Bajo
riesgos tienen que ser re-estimados en todo
Medio
Bajo
Alto
momento.
Medio
Bajo
Medio
Bajo
Bajo
Bajo
Negociación de Contratos
• La fase de contratos es una actividad
indispensable en el desarrollo de cualquier tipo
de proyecto.
• En la fase de contratos se realiza un
compromiso por escrito de las actividades a
desarrollar así como de los productos a
entregar.
• Se debe de indicar tanto penalizaciones así
como bonificaciones en caso de existir.
Resumen de Planeación
• De acuerdo con Humprey se tiene el siguiente
ciclo de vida en la planeación de proyectos de
software:
Requerim.
iniciales
Negociar
compromisos
Detallar
requerim.
WBS
Estimar
tamaño
NLC
Estimar
recursos
Prog y
equipo
Elaborar
calendario
Calendario
No
El calendario
satisface las
necesidades?
Si
Hacer
sistema
real
estimación
Comparación
(base de casos)
Resumen de Planeación
Necesidades
del cliente
Definir
requerimientos
Hacer diseño
conceptual
Estimar el tamaño
del producto
Base de datos
histórica de tamaño
Cliente
Producto
final
Estimar los
recursos a utilizar
Base de datos
histórica de productividad
Hacer el calendario
de actividades
Recursos
disponibles
Desarrollar
el producto
Tamaño, recursos
y calendario
Administración
Proceso de
análisis
Reporte de
seguimiento
Referencias
• (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.
Dudas