Ingenieria software

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…

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

 COMPLEJIDAD DEL PROYECTO
 TAMAÑO DE PROYECTO
 GRADO DE INCERTIDUMBRE ESTRUCTURAL

Establecer
plan de
proyectos
Defina
Tareas
Fechas clave
Identificar responsables
por tareas
Especificar dependencia
por tareas

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

 Control
 Datos a procesar
 Función
 Rendimiento
 Restricciones
 Interfaces
 Fiabilidad
Describe
Primera tarea de la
planificación de proyectos

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?

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

Acometer el esfuerzo de desarrollo de software
Segunda tarea de la
Personal
Software
Reutilizable
Entorno Desarrollo

El
Planificador
debe
especificar
Habilidades Requeridas
Posición organizacional
Especialidad

 Componentes ya desarrollados
 Componentes ya experimentados
 Componentes con experiencia parcial
 Componentes nuevos
No inventar
el Agua Tibia

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.

 Incorpora hardware y software
 Se debe determinar el entorno de hardware y
software y verificar que estén disponibles.

 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

Implica
muchas
variables
• Humanas
• Técnicas
• Ambientales
• Políticas
• etc
Mientras mas se conozca menos
errores serios se cometerán.
Nunca es exacta

Basarse en proyectos similares
Descomposición Simple
Uso de Modelos Empíricos

TECNICAS DE
DESCOMPOSICION
MODELOS
EMPIRICOS
HERRAMIENTAS
AUTOMÁTICAS

 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

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.

 Métricas basadas en la Productividad
 LDC/pm
 PF/pm
 Combinaciones

Optimista
Mas
Probable
Pesimista
Valor
Esperado

Descomposición funcional
absolutamente esencial
Considerables niveles de detalle
LDC se estima directamente.

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

 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

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

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

 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

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.

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

 FALTA LO MIO LO DEL EJERCICIO

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.

Sentido
crítico del
software
Coste final

Menos caro
comprar
Menos caro
experimentar
Más caro es una
evaluación de
potenciales
paquetes de
software

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.

Coste de
Soporte
Externo
Fecha
entrega
Coste de
Adquisición

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

 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

 Implementar en un software las técnicas
de descomposición, o técnicas empíricas.
 Permiten estimar costes y esfuerzo
 Analizar “que pasa si”

Descripción del
personal de
desarrollo y/o
entorno de
desarrollo
Estimación
cuantitativa
Características
cualitativas

Yo se Lenguaje
Ensamblador y
Fortran.
No necesito saber
ingeniería de
software
A la larga
90 %

Se quedan estancados
en el 90%, por no
llevar una buena
planificación, ni
estimar un buen
tiempo.

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

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.

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

1 • COMPARTIMENTACION
2 • INTERDEPENDENCIA
3 • ASIGNACION DE TIEMPO
4 • VALIDACION DE ESFUERZO
5 • RESPONSABILIDADES DEFINIDAS
6 • RESULTADOS DEFINIDOS
7 • HITOS DEFINIDOS

Proceso de
Software
eficaz
debería
Definir una
colección de
tareas
Se
diseñan
Para acomodar
diferentes proyectos
diferentes grados de rigor

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

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

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

• 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

Á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

Tareas
Principales
Descomponer
en sub-tareas
Planificación
Temporal
Detallada

 Es una representación gráfica del flujo de tareas de
un proyecto
 Muestra las tareas principales de la ingeniería de
software

• Técnica de evaluación y
revisión de programaPERT
• Método del camino
críticoGANT

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

 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

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

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

Ingenieria software

Más contenido relacionado

La actualidad más candente (20)

Destacado (6)

Similar a Ingenieria software (20)

Más de Iván Sanchez Vera (20)

Último (20)

Ingenieria software