Resistencia extrema al cobre por un consorcio bacteriano conformado por Sulfo...
Ingenieria software
1.
2. En el principio se pidieron los
proyectos de Software.
Los proyectos estaban
desordenados y vacíos, y las
tinieblas estaban sobre la haz del
abismo, y el Espíritu de Dios se
movía sobre este mar de Caos.
Y dijo Dios: Sea la Planificación: y
fue la Planificación.
Y vio Dios que la Planificación era
buena: y apartó Dios la
Planificación del desorden…
4. ESTIMAR-> MIRAR AL FUTURO Y ACEPTAR CIERTO
GRADO DE INCERTIDUMBRE.
El gestor y el
equipo
Realizar
Estimación del trabajo
Estimación de recursos
Estimación del tiempo
5. COMPLEJIDAD DEL PROYECTO
TAMAÑO DE PROYECTO
GRADO DE INCERTIDUMBRE ESTRUCTURAL
9. El objetivo Se logra
Proceso de
descubrimiento
de la información
Proporciona Marco de
trabajo
Permita
realizar
Estimación del
trabajo
Estimación de
recursos
Estimación del
tiempo
10. Control
Datos a procesar
Función
Rendimiento
Restricciones
Interfaces
Fiabilidad
Describe
Primera tarea de la
planificación de proyectos
11.
12. Preguntas de
contexto libre
• ¿Quién esta detrás de
la solicitud de
trabajo?
• ¿Quién utilizará la
solución?
• ¿Cuál será el beneficio
económico de una
buena solución?
• ¿Hay otro camino para
la solución?
Comprender mejor el
problema
• ¿Cómo caracterizaría
un resultado correcto
que se generaría de
una solución
satisfactoria?
• ¿Con qué problema se
enfrentará esta
solución?
• ¿Hay aspecto o
limitaciones
especiales de
rendimiento que
afecten a la forma en
que se aborde la
solución?
Meta-cuestiones
Efectividad de la
reunión.
• ¿Es usted la persona
apropiada para
responder a estas
preguntas?
• ¿Son relevantes mis
preguntas para su
problema?
• ¿Estoy realizando
muchas preguntas?
• ¿Hay alguien más que
pueda proporcionar
información adicional?
• ¿Hay algo más que
debería preguntarle?
13. Lectura de la entrada del
código de barras.
Lectura del tacómetro de
pulsos.
Descodificación de los
datos del código de pieza.
Búsqueda en la base de
datos.
Determinación de la
posición del
comportamiento.
Producción de la señal de
control para el mecanismo
de maniobra.
Funciones importantes:
14. Acometer el esfuerzo de desarrollo de software
Segunda tarea de la
planificación de proyectos
Personal
Software
Reutilizable
Entorno Desarrollo
16. Componentes ya desarrollados
Componentes ya experimentados
Componentes con experiencia parcial
Componentes nuevos
No inventar
el Agua Tibia
17. 1
• Si los componentes ya desarrollados
cumplen los requisitos del proyecto,
adquiéralos.
2
• Si se dispone de componentes ya
experimentados, los riesgos asociados a la
modificación y a la integración se aceptan.
3
• Si se dispone de componentes de
experiencia parcial para el proyecto actual,
su uso se debe analizar con detalle.
18. Incorpora hardware y software
Se debe determinar el entorno de hardware y
software y verificar que estén disponibles.
19. Un gran error en la estimación puede hacer
la diferencia entre Ganancia o Perdida.
Mala
Estimación
Desastre para
el
Desarrollador
Tercera tarea de la
planificación de proyectos
24. DESCOMPONER EL PROBLEMA EN CONJUNTO DE
PEQUEÑOS PROBLEMAS.
SE DEBE DEFINIR ANTES EL TAMAÑO DE
SOFTWARE
1. Estimación basada en el problema
2. Estimación basada en el proceso
25. El grado con el cual se
ha estimado
adecuadamente el
tamaño
Habilidad para traducir
estimación en esfuerzo
humano, cronograma y
Dinero
Grado en el que la
planificación refleja las
habilidades del equipo
de Software
Estabilidad de los
requisitos del software
y el entorno que
soporta el esfuerzo de
la ingeniería de
software.
31. Los datos requeridos para estimar los Puntos de
Función son más macroscópicos que en LDC.
Nivel de descomposición considerablemente
menos detallado que en LDC.
PF se determina indirectamente mediante la
estimación del número de entradas, salidas,
archivos de datos, peticiones e interfaces
externas, entre otras.
32.
33. Técnica más habitual
El proceso se descompone en actividades o
tareas y el esfuerzo requerido para llevar a
cabo cada tarea
2) Estimación Basada
en el Proceso
34. delimitar las funciones
obtenidas a partir del
ámbito del software
actividades del proceso
para cada función
estimación de esfuerzo
(persona-mes) para cada
actividad en cada
función
aplicación de índices de
trabajo medios
(esfuerzo coste/unidad)
al esfuerzo estimado
para cada actividad
cálculo de costes y
esfuerzo de cada
función y de la actividad
35.
36. Utilizan formulas empíricas para predecir el
esfuerzo.
Los datos con los que se trabaja para estos
modelos son datos resultantes de una muestra
limitada de proyectos
Deben manejarse con prudencia.
37. El Modelo Constructivo de Costos
(COnstructive COst MOdel) es una jerarquía de
modelos de estimación para el software.
Fue desarrollado por Boehm a finales de los
años 70 y comienzos de los 80.
COCOMO
38. Básico
• calcula el esfuerzo del desarrollo de software en función del
tamaño del programa expresando en líneas de código (LDC)
estimadas.
Intermedio
• calcula el esfuerzo del desarrollo de software en función del
tamaño del programa y de un conjunto de “conductores de
costo”, que incluyen la evaluación subjetiva del producto, del
hardware, del personal y de los atributos del proyecto.
Avanzado
• incorpora todas las características de la versión intermedia y
lleva a cabo una evaluación de impacto de los conductores de
costo en cada fase (análisis, diseño, etc.) del proceso de
ingeniería de software.
39. Modelo
Orgánico
• Proyectos de software relativamente pequeños
y sencillos.
• Trabajan pequeños equipos.
• Con buena experiencia en la aplicación.
• Conjunto de requisitos poco rígidos.
Modelo
Semiacoplado
• Proyectos de software intermedios (en tamaño
y complejidad).
• Equipos intermedios
• Con variados niveles de experiencia
• Conjunto de requisitos poco o medio rígidos
Modelo
Empotrado
• Proyectos de software que deben ser
desarrollados en un conjunto de hardware,
software y restricciones operativas muy
restringidas
programa de análisis
termal desarrollado
para un grupo
calórico
sistema de
procesamiento de
transacciones con
requisitos fijos para un
hardware de terminal
o un software de
gestión de base de
datos
software de control
de navegación para
un avión
EJEMPLOS
42. Opciones de
adquisición
El software se puede comprar ya desarrollado.
Se pueden adquirir componentes de software “totalmente
o parcialmente experimentado”, y entonces modificarse e
integrarse para cumplir las necesidades específicas.
El software puede ser construido de forma personalizada
por una empresa externa para cumplir las necesidades del
comprador.
45. Desarrollo de una
especificación para la función y
rendimiento del software
deseado.
Estimación de coste interno de
desarrollo y la fecha de entrega.
Selección de 3 o 4 aplicaciones
candidatos que cumplan mejor
las especificaciones.
Selección de componentes de
software reutilizables.
Desarrollo de una matriz de
comparación que permita una
comparación una a una de las
funciones clave.
Evaluación de cada paquete de
software o de componentes,
según la calidad de productos
anteriores, soporte del
vendedor, dirección del
producto.
Contacto con otros usuarios de
dicho software y petición del
producto.
47. Es un apoyo a la decisión desarrollar – comprar.
1) Construir el sistema X
desde el principio
2) Reutilizar los
componentes existentes de
“experiencia parcial” para
construir el sistema
3) Comprar un producto de
software disponible y
modificarlo para cumplir
las necesidades locales
4) Contratar el desarrollo del
software a un vendedor
externo
48.
49. Estrategia - táctica
Contratación a un tercero que hace el
trabajo a bajo coste asegurando calidad.
PRO CONTRA
REDUCCION DE COSTES POR
AHORRO DE INFRAESTRUCTURA
AHORRO DE PERSONAL
SE PIERDE EL CONTROL DEL
SOFTWARE.
PROCESOS QUEDAN EN MANOS DE
TERCEROS
50. Implementar en un software las técnicas
de descomposición, o técnicas empíricas.
Permiten estimar costes y esfuerzo
Analizar “que pasa si”
53. Se quedan estancados
en el 90%, por no
llevar una buena
planificación, ni
estimar un buen
tiempo.
54. Fechas limite poco realista
Cambio en los requisitos de los clientes
Errores predecibles y no predecibles
Dificultades técnicas no previstas
Dificultades humanas
Falta de comunicación entre el equipo de trabajo
Falta de reconocimiento de retrasos
55. Es poco realista
exigirle al cliente
que cambie la fecha
de entrega!!!
Realizar una estimación en base
a proyectos anteriores.
Emplear modelo de proceso
incremental
Con bases explicar al cliente
porque la fecha no es realista
Ofertar estrategia al cliente
Esfuerzo estimado.
Duración Proyecto.
Estrategia de
desarrollo
Apuntar estimaciones.
Indicar mejora de
porcentaje.
56. Evoluciona
con el tiempo
Planificación Temporal Detallada
A media que progresa el
proyecto
Identifica y programa las
tareas
Planificación Temporal Macroscópica
Durante las primeras etapas
Identifica actividades y
funciones
57. 1 • COMPARTIMENTACION
2 • INTERDEPENDENCIA
3 • ASIGNACION DE TIEMPO
4 • VALIDACION DE ESFUERZO
5 • RESPONSABILIDADES DEFINIDAS
6 • RESULTADOS DEFINIDOS
7 • HITOS DEFINIDOS
61. Proyectos de desarrollo de concepto
Proyectos de desarrollo de una
nueva aplicación
Proyectos de mejoras de
aplicaciones
Proyectos de mantenimiento de
aplicaciones
Proyectos de reingeniería
62. Está en función
de muchas
características
del proyecto
Como se tratara
al proyecto
4
grados
de Rigor
Casual
Estructurado
Estricto
Reacción
Rápida
63. Tamaño de proyecto
Numero potencial de usuarios
Misión critica
Longevidad de la aplicación
Estabilidad de los requisitos
Facilidad de comunicación cliente/ desarrollador
Madurez de la tecnología aplicable
Limitaciones de rendimiento
Características empotradas/no empotradas
Personal del proyecto
Factores de reingeniería
Se emplean para determinar el
grado de rigor recomendado con
el que el proceso de software
debería aplicarse en un proyecto.
64. • Importancia de la
distribución de un
conjunto de tareas
a lo largo de la
duración del
proyecto.
• Cada uno de los
tipos de proyectos
puede enfocarse
usando un modelo
de proceso lineal,
secuencial o
iterativo
65. Ámbito del concepto
Planificación preliminar del concepto
Valoración del riesgo tecnológico
Prueba del concepto
Implementación del concepto
Reacción del cliente ante el concepto
67. Es una representación gráfica del flujo de tareas de
un proyecto
Muestra las tareas principales de la ingeniería de
software
68. • Técnica de evaluación y
revisión de programaPERT
• Método del camino
críticoGANT
69. • Estimaciones de
esfuerzo
• Descomposición de la
función del producto
• Selección del modelo
de proceso adecuado
• Selección del tipo de
proyecto y del
conjunto de tareas
Son dirigidas
por la
información
ya
desarrollada
en
actividades
anteriores:
70. En una red de trabajo, el esfuerzo, duración y
fecha de inicio delas tareas se las puede definir
como entradas.
Estas entradas generan un Grafico de tiempo
Gráfico de Gantt
UTILIDAD:
SEGUIMIENTO DEL PROGRESO
71. Reuniones periódicas del estado del proyecto
Evaluando resultados de las revisiones
realizadas a lo lardo del proceso de ingeniería
Determinando si se han conseguido lo
planteado y en la fecha programada.
Comparando la fecha real de inicio con las
previstas para cada tarea del proyecto
72. Se produce cuando se culminan todas las
tareas de planificación.
Comunicar el ámbito y recursos a los gestores
del software, personal técnico y al CLIENTE.
Definir los riesgos y sugerir técnicas de
aversión al riesgo.
Definición de costes y planificación temporal
Proporcionar un enfoque general de
desarrollo del software para el personal.
Describir como se garantizará la calidad.
