Estrategia y Gestión de los Sistemas de Información

Ingeniería de Software

0
Agenda

 Introducción: Complejidad de los proyectos de TI

 Introducción a la Ingeniería de Software

 Disciplinas
 Requerimientos
 Diseño
 Construcción
 Pruebas
 Mantenimiento
 Gestión de la configuración
 Gestión de la ingeniería de software
 Proceso de ingeniería de software
 Herramientas y métodos de ingeniería de software
 Calidad del software
 Estimación del Tamaño y el Esfuerzo del Software
 Ingeniería de Software y el PETI

 Actividad: Identificación de posibles causas de alargamiento de proyectos de

Talibank
1
 Introducción:
Complejidad de los proyectos de TI

2
Fallas en los proyectos de TI (1 de 2)
 The Standish Group es una organización que presenta resultados en
la ejecución de proyectos de TI clasificándolos en:
 Exitosos (Succesful): Terminan en tiempo, dentro del presupuesto y con el
alcance solicitado.
 Con complicaciones (Challenged): Terminan y quedan operativos, pero fuera de
tiempo, fuera del presupuesto o con menos funcionalidad que la solicitada.
 Fallados (Failed): El proyecto es cancelado en algún punto antes de terminar.

31% 16%

53%

Exitosos Con complicaciones Fallados

3
Fallas en los proyectos de TI (2 de 2)

 Este tipo de análisis son ratificados por las vivencias y experiencias de

cientos de personas relacionadas al mundo de TI.

 Sin embargo, un proyecto de TI es complejo, medirlo sólo por la

desviación en estas tres dimensiones, sobre todo teniendo como base
el estimado original, pone fuera de todo análisis las situaciones y
cambios inherentes a un proyecto de TI.

 Es necesario que los procesos de gestión de proyectos TI, pueda

manejar adecuadamente esa complejidad.

 El hardware de las sondas espaciales suelen resistir muchos años sin

la posibilidad de ser cambiado (están en el espacio); sin embargo, el
software es actualizado de vez en cuando para poder completar su
misión.

4
Escribir software no es como otras ramas
de la ingeniería (1 de 2)
 Diferencia fundamental: Otras ramas de la ingeniería están restringidas por las
limitaciones físicas del mundo real, el software no.
 Un edificio construido hasta la mitad, aún puede ser utilizado. En software, es
usual que o sirva todo o no sirva nada.
 Los componentes de la ingeniería tradicional existen en el mundo real y pueden
ser verificados y modificados en una interacción ver-hacer, cosa que no se puede
hacer en software.
 La programación orientada a objetos se creó para
acercar la programación a la realidad.
 Por ejemplo, trate de visualizar como construir una casa
en una calabi-yau.

5
Escribir software no es como otras ramas
de la ingeniería (2 de 2)
 Los componentes físicos de la vida real interactúan de maneras más limitadas
y predecibles. Por ejemplo, al construir un auto es difícil que una luz
intermitente genere fallas en el motor o que al construir una casa por error al
jalar la palanca de un excusado suene el timbre. Un pequeño trozo de
software en un programa puede generar efectos fuertes en toda una
aplicación.

 Es más difícil hacer cambios al medio de un proyecto de ingeniería; el mundo

físico es menos maleable que el de software. El congreso de EEUU no puede
ir a la mitad de un lanzamiento a la luna y pedir que en vez de ello vayan a
Marte.

 Hacer software es más arte que ciencia. Es como escribir novelas de ficción:
 Es un acto de creación.
 Con pocas reglas definidas.
 En un medio etéreo y con pocas restricciones.
 Es difícil de enseñar.
 Sólo se puede ver si es bueno cuando está listo integralmente, no cuando se está
haciendo.
6
Causas de alargamiento de los proyectos

7
 Introducción a la
Ingeniería de Software

8
¿Qué es Ingeniería de Software

 Aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo,

operación y mantenimiento de software

 En general, aplicación de la ingeniería al software

 Ingeniería = Aplicación creativa de principios científicos al diseño o desarrollo de estructuras,
máquinas, aparatos, o procesos de manifactura, o trabajos utilizándolos individualmente o en
combinación; o para construirlo u operarlo con conocimiento total de su diseño; o pronosticar su
comportamiento bajo condiciones específicas de operación; todo esto respetando la función
requerida, economía de operación y seguridad para la vida y la propiedad.

 El desarrollo de software, término ampliamente usado, no necesariamente

incorpora el paradigma de la ingeniería

Ciencia

INGENIERÍA DE SOFTWARE

Arte Oficio
9
Historia de la Ingeniería de Software

1990 / Siglo XXI

•Reducción de
1970 / 1980 costos
•Mayor complejidad •Sistemas
del software distribuidos
•Introducción de •Open source
1960
Sistemas Operativos •Internet
•Concepto de modernos (UNIX) •Programación ágil
modularidad y •Programación
ocultamiento de orientada a objetos
información
1950 •Microcomputadoras
•Aparición de
lenguajes de
programación
(FORTRAN,
ALGOL, COBOL)
1940
•Se inicia la
división entre
hardware y
software

10
Disciplinas

11
Disciplinas de la Ingeniería de Software

12
Requerimientos

13
Requerimientos de Software
 Un requerimiento es definida como una propiedad que debe tener el software para resolver un
problema del mundo real
 Fundamentos de requerimientos. Definiciones de requerimientos de software, tipos de
requerimientos: producto vs. proceso, funcional vs. no funcional, propiedades emergentes
 Proceso de requerimientos. Procesos que orienta cómo gestionar requerimientos. Describe
modelos de procesos, actores o roles, gestión y soporte al proceso, y mejora y calidad del proceso
 Captura de requerimientos. Identifica de dónde vienen los requerimientos y cómo se puede
recolectarlos
 Análisis de requerimientos. Los requerimientos son analizados para detectar y resolver conflictos
entre requerimientos, identificar los límites del software y cómo debe interactuar con su entorno. Los
requerimientos se clasifican, se modelan, se diseña la arquitectura, se negocia
 Especificación de requerimientos. Se produce un documento que puede ser revisado, evaluado y
aprobado. Para sistemas complejos se puede necesitar describir la definición del sistema, los
requerimientos del sistema y los requerimientos del software
 Validación de requerimientos. Se examinan los documentos para asegurar que definen el sistema
correcto, el sistema que el usuario espera. Se logra a través de revisiones, prototipeo, validación de
modelos y pruebas de aceptación
 Consideraciones prácticas. El proceso de requerimientos es iterativo, debe gestionarse el cambio,
los requerimientos tienen atributos complementarios y deben ser rastreados y medidos

14
Patrones de requerimientos de software (1 de 2)

 Patrón de requerimiento de software. Es un enfoque para especificar un tipo

particular de requerimiento de software
 Es aplicado al nivel de requerimiento individual
 Proveen guía: Sugieren información a incluir, dan consejo, alertan errores comunes, sugieren
otras cuestiones a considerar
 Ahorran tiempo: No se tiene que escribir el requerimiento de cero
 Proveen consistencia para requerimientos del mismo tipo

 Anatomía
 Detalles básicos
 Aplicabilidad
 Discusión
 Contenido
 Plantilla
 Ejemplo
 Requerimientos extra
 Consideraciones para desarrollo
 Consideraciones para prueba

15
Patrones de requerimientos de software (2 de 2)
Información
Interfaz inter- Fórmula de
Tecnología
sistemas Tipo de dato cálculo

Estructura de Envejecimiento
Cumplir con Interacción de datos
datos Archivamiento
estándar inter-sistemas
ID de datos

Requerimientos
externos
Fundamental
Funcionalidad
Interfaz
Documentación Almacenar usuaria usuaria
información
Consulta
Entidad de datos
Reportar

Reporte

Entidad viva Transacción Configuración Crónica

Accesibilidad
Entidad de datos

Desempeño
Tiempo de
Instalabilidad Escalabilidad Control
Ancho de banda Registro de
respuesta usuario de
Capacidad acceso
Extensibilidad Autenticación
Capacidad Capacidad dinámica
dinámica estática

Facilidad de Autorización
instalación Aprobación
Disponibilidad

Comercial Autorización Autorización

específica configurable
Multi Multi lenguaje
Impuestos
organizaciones
Flexibilidad

16
Diseño

17
Diseño de Software

 Diseño es el proceso de definir la arquitectura, componentes, interfaces y otras

características del software
 Fundamentos de diseño. Entendimiento del rol y alcance del diseño del software:
Conceptos generales, contexto del diseño, proceso de diseño y técnicas para
realizar el diseño
 Temas claves en diseño de software. Concurrencia, control y manejo de
eventos, distribución de componentes, tolerancia a fallas y manejo de excepciones
y errores, interacción y presentación, y persistencia de datos
 Arquitectura y estructura de software. Estructuras arquitecturales y puntos de
vista, estilos de arquitectura, patrones de diseño y familias de programas y
frameworks
 Análisis y evaluación de la calidad del diseño. Atributos de calidad, análisis de
la calidad y técnicas de evaluación y mediciones
 Notaciones de diseño. Descripciones estructurales (componentes del software) y
de comportamiento
 Métodos y estrategias de diseño. Estrategias generales, métodos de diseño
orientados a la función, métodos de diseño orientados a objetos, diseño centrado
en la estructura de datos, diseño basado en componentes y otros

18
Construcción

19
Construcción del software

 Construcción del software es la creación detallada de software a

través de codificación, verificación, pruebas unitarias, pruebas de
integración y depuración
 Fundamentos de construcción. Minimizar la complejidad, anticipar
cambios, construir para verificar y estándares para construcción
 Gestionando la construcción. Modelos, planeamiento y medición de
la construcción
 Consideraciones prácticas. Diseño de la construcción, lenguajes de
construcción, codificación, pruebas de construcción, reuso, calidad de
construcción e integración

20
Evolución de los lenguajes de programación (1 de 2)

21
Evolución de los lenguajes de programación (2 de 2)

22
Pruebas

23
Pruebas de software

 Pruebas de software consiste en la verificación dinámica del comportamiento

de un programa dentro de un conjunto finito de casos de prueba,
cuidadosamente seleccionados de potencialmente infinitas posibilidades, en
comparación con el comportamiento esperado
 Fundamentos de pruebas de software. Terminología de pruebas, temas
claves de pruebas y relación entre pruebas y otros temas
 Niveles de pruebas. Objetivos de los tipos de pruebas
 Técnica de pruebas. Pruebas basadas en intuición y experiencia, basadas
en la especificación, basadas en el código, basadas en fallas, basadas en el
uso y técnicas relativas a la naturaleza de la aplicación. Cómo seleccionar y
combinar las técnicas apropiadamente
 Mediciones relacionadas a pruebas. Mediciones del programa probado y de
las pruebas realizadas
 Proceso de pruebas. Consideraciones prácticas sobre el proceso y
actividades de pruebas

24
Mantenimiento

25
Mantenimiento de software

 Una vez en operación, se describen anomalías, cambia el entorno de

operación y surgen nuevos requerimientos de usuarios. El
mantenimiento empieza luego de la entrega, pero hay actividades
que deben empezar antes
 Fundamentos de mantenimiento de software. Definiciones y
terminología, naturaleza, necesidad y costos del mantenimiento,
evolución del software y categorías de mantenimiento
 Temas claves en mantenimiento de software. Temas técnicos,
temas de gestión, estimación del costo de mantenimiento y medición
del mantenimiento
 Proceso de mantenimiento. Procesos y actividades de
mantenimiento
 Técnicas para mantenimiento. Comprensión del programa,
reingniería e ingeniería reversa

26
Gestión de la configuración

27
Gestión de la configuración del software

 Gestión de la configuración del software (SCM) es una disciplina para identificar la

configuración del software en distintos momentos del tiempo con el propósito de
controlar cambios a la configuración y mantener la integridad y trazabilidad de los
cambios a través del ciclo de vida del software
 Gestión del proceso SCM. Contexto organizacional para SCM, restricciones y guía
para SCM, planificación de SCM
 Identificación de la configuración del software. Identifica elementos a ser
controlados, identificar esquemas para los elementos y sus versiones, herramientas y
técnicas para ser utilizadas al obtener y gestionar elementos controlados
 Control de la configuración del software. Gestión de los cambios durante el ciclo de
vida del software: Requerir, evaluar, aprobar e implementar cambios de software,
desviaciones y evidencias
 Reporte del estado de la configuración del software. Información del estado y
reporte de la configuración de software
 Auditoria de la configuración del software. Auditoria de la configuración funcional del
software, de la configuración física y de la línea base
 Entrega y gestión de versiones de software. Construcción de software y
administración de versiones

28
Infraestructura - Ambientes de trabajo
Producción
Certificación

Desarrollo

Gestión de la Gestión de la
configuración configuración

29
Gestión de la ingeniería de software

30
Gestión de la ingeniería de software

 La gestión de la ingeniería de software incluye la administración y medición

de la ingeniería de software. Si bien las mediciones son importantes en toda
la gestión, es en esta disciplina en donde se detalle
 Definición de alcance e inicio. Determinación y negociación de
requerimientos, análisis de factibilidad y revisión de requerimientos
 Planificación del proyecto de sw. Proceso de planificación, determinación
de entregables, esfuerzo, cronograma y estimación de costos, reserva de
recursos, gestión de riesgos, gestión de la calidad y gestión del plan
 Implementación del proyecto de sw. Implementación de planes, gestión de
contratos con proveedores, implementación del proceso de medición, proceso
de monitoreo, proceso de control y reporte
 Evaluación y revisión. Determinación de la satisfacción de requerimientos y
revisión y evaluación del desempeño
 Cierre. Actividades de cierre
 Medición de la ingeniería de software. Medición del proceso y producto,
mantenimiento permanente de la medición, planificación de la medición,
desempeño de la medición y evaluación de la medición

31
Proceso de ingeniería de software

32
Proceso de ingeniería de software

 El proceso de ingeniería de software está relacionado a la

definición, implementación, evaluación, medición, gestión, cambio y
mejora del proceso de ingeniería de software
 Implementación y cambio del proceso. Infraestructura del proceso,
ciclo de gestión del proceso de software, modelos para la
implementación y el cambio y consideraciones prácticas
 Definición del proceso. Modelos de ciclo de vida del sw, procesos
del ciclo de vida del sw, notación, adaptación del proceso y
automatización
 Evaluación del proceso. Modelos de evaluación del proceso y
métodos de evaluación del proceso
 Medición del proceso y el producto. Medición del proceso, medición
del producto de sw, modelos de información de software y técnicas de
medición de procesos

33
Ciclos de Vida para el Desarrollo de Software

 A continuación se verá los siguientes ciclos de vida para el Desarrollo de

Software
 Cascada pura
 Sashimi
 Codificar y corregir
 Modelo en espiral
 Prototipo evolutivo
 Entrega por etapa
 Entrega evolutiva

34
 Cascada pura

Progresa a través de una secuencia ordenada de pasos

Para pasar a la etapa siguiente se tienen

Concepto del que haber conseguido los objetivos de la
software etapa anterior
Análisis de
requerimientos

Especificación de Las etapas no se

requerimientos solapan

Diseño
preliminar Pocos signos visibles
Si falta una tarea pasada la etapa,
el trabajo retrasa la entrega y Diseño de progreso hasta el
aumenta el costo detallado final

Programación y
pruebas
Adecuado para versiones de Explotación y
mantenimiento o migración mantenimiento
35
Sashimi

Similar al modelo de cascada, pero con fases solapadas

Debido al solapamiento los hitos

resultan mas ambiguos

Concepto del
software Análisis de
requerimientos
Especificación de
requerimientos
Diseño
preliminar
Diseño
detallado
Programación y
Actividades en paralelo puede pruebas Explotación y
suponer mala comunicación, mantenimiento
suposiciones incorrectas e ineficacia.

36
Codificar y corregir
Empieza con una idea general de lo que se necesita, y luego se usa cualquier
combinación de diseño, código, depuración y prueba hasta que tener listo el producto

Especificación
del sistema
Codificar y
(con suerte) corregir

Entrega (con suerte)

No se pierde tiempo en planificación,

documentación, control de calidad, Se pasa directamente a codificar, se
cumplimiento de estándares muestra indicios de progreso

Útil para proyectos pequeños que se No permite evaluación de calidad e

liquidan después de construidos identificación de riesgos

37
Modelo en espiral
Modelo orientado al riesgo que divide el proyecto software en miniproyectos. Cada
miniproyecto se encarga de resolver uno o varios riesgos

Se comienza con una pequeña

parte y se expande tras reducir Se conoce con anterioridad
riesgos riesgos insuperables

Determinar
Identificar
objetivos y
riesgos
alternativas

Enfoque de Evaluar
siguiente alternativas
iteración

INICIO Generar entregas de

Planificar iteración y comprobar su
siguiente corrección
iteración

38
Prototipo evolutivo
Se diseñan y construyen las partes mas importantes, luego se refina y amplia

Se usa cuando el cliente no

facilita requerimientos y Genera signos visibles de
especificaciones o cuando progreso y permite modificar
cambian con celeridad sobre la marcha

Recolección y
refinamiento
de requisitos
Diseño
Evaluación rápido

Construcción
del prototipo

Desarrollo del Imposibilidad de conocer a

priori tiempo de desarrollo
producto final

39
 Entrega por etapas
Luego del diseño global se puede implementar y entregar la aplicación en etapas. Se
crea un producto para entregar al final de cada etapa

Concepto del
software
Proporciona signos tangibles
Análisis de
requerimientos de progreso

Especificación de
requerimientos
Diseño
global
Etapa 1: Diseño detallado, codificación,
depuración, prueba y entrega
Proporciona funcionalidad útil en manos
del cliente sin tener aplicación finalizada
Etapa 2: Diseño detallado, codificación,
depuración, prueba y entrega

Etapa n: Diseño detallado, codificación,

40
depuración, prueba y entrega
40
Entrega evolutiva
Ofrece el control de la entrega por etapas y la flexibilidad del prototipo evolutivo. Se
desarrollan versiones añadiendo funcionalidad a las anteriores y mostrándoselas al
cliente

Concepto del
software
Entregar
Análisis de versión
requerimientos final

Diseño global y del Debe

núcleo del sistema diseñarse
Repetir ciclo hasta previamente el
Desarrollar
agotar tiempo, una versión núcleo del
presupuesto, ejecutar sistema y su
iteraciones planeadas Incorporar la globalidad
Entregar la
o hasta que el cliente realimentación
versión
del cliente
este satisfecho
Educir la
realimentación
del cliente
41
Herramientas y métodos de
ingeniería de software

42
Herramientas y métodos de ingeniería de software

 Los métodos y herramientas de ingeniería de software incluyen

soporte, proceso, estructura y automatización para todas las
disciplinas de ingeniería de software, adicionando temas misceláneos
del uso de herramientas, como técnicas de integración de
herramientas

 Existe los métodos heurísticos relacionados a enfoques informales,

los métodos formales relacionados a enfoques basados en
matemáticas y métodos de prototipeo

43
Unified Process

44
Capability Maturity Model Integrated (CMMi)

45
Capability Maturity Model Integrated – Level 3

46
Calidad del software

47
Calidad del software

 La calidad de software está relacionadas a aspectos de calidad que

transcienden los procesos del ciclo de vida del software. La calidad de
software es una preocupación constante en ingeniería de software

 Fundamentos de la calidad de software. Cultura y ética de la

ingeniería de software, valor y costos de la calidad, modelos y
características de la calidad, y mejoramiento de la calidad

 Procesos de gestión de la calidad del software. Aseguramiento de la

calidad del software, verificación y validación, y revisiones y auditoria

 Consideraciones prácticas de la calidad de sw. Requerimientos de

calidad de software, definición de defectos, técnicas de gestión de la
calidad de software y medición de la calidad de sw

48
Estimación del Tamaño y el
Esfuerzo del Software

49
Estimaciones en el Software

 Estimar es el proceso de predecir cuánto se requerirá para construir un

software

 Cuánto puede ser:

 Tamaño, para poder comparar un software contra otro
 Esfuerzo, para poder dimensionar el trabajo requerido para construir un software
 Costo, para poder estimar el valor de construir un software

 Evidentemente, estas tres cuantificaciones están relacionadas y la raíz la

representa la estimación del tamaño

50
Tamaño del Software – Líneas de Código

 Existen dos medidas comunes: Líneas de código y puntos de función

 La medición de líneas de código o LOC (Lines Of Code) usa las líneas

del lenguaje de programación como unidad de medida al ser el elemento
productivo básico
 El término NCLOC se utiliza para las Non-Commented LOC (líneas de código no
comentadas)
 El término ELOC se utiliza para las Effective LOC (líneas de código efectivas,
usualmente las no comentadas)
 Algunas organizaciones consideran los comentarios en el código como una unidad
de medida válida y no diferencian los comentarios de otras líneas de código
 El término KLOC (Kilo LOC) se utiliza para denominar mil líneas de código
 Las principales desventajas al usar las LOC para calcular el tamaño son 1) que se
suele contabilizar como línea válida a un condicional o a una asignación de
variables (LOC “simples”) y 2) que no se puede estimar el tamaño antes de realizar
la codificación de las líneas

51
Tamaño del Software: Puntos de Función

 Los puntos de función (PF) mide el tamaño en términos de la

cantidad de funcionalidad en un sistema

 El proceso de identificación de PF consiste en 7 pasos

 1. Identificar las funcionalidades que requiere el usuario
 2. Identificar las operaciones que se deben realizar para implementar las
funcionalidades
 3. Identificar los elementos funcionales que deben existir en el software para
implementar las operaciones
 4. Clasificar cada elemento funcional y asignarle un grado de complejidad de
acuerdo a una tabla. A continuación asignarle la cantidad de puntos de función
basado en la clasificación y grado de complejidad
 5. Sumar todos los elementos funcionales para obtener el total de Puntos de
Función No Ajustados (PFn)
 6. De acuerdo a la naturaleza del entorno de la elaboración del software llenar la
tabla de Factores de Complejidad Total y sumarlos para obtener el valor FCT
 7. Finalmente, obtener el total de Puntos de Función Ajustados con la fórmula

PFa = PFn * (0.665 + 0.01 * FCT)

52
Tablas para obtener la Cantidad de Puntos de Función
Clasificación Descripción Entrada Salida Consulta
Entradas Entradas externas provistas por Sistema Otro
sistema
un usuario (selecciones de
opciones, ingresos de datos, etc.) Archivo
Interfaz
Salidas Salidas externas esperadas por
un usuario (reportes
programados, mensajes, etc.)
Consultas Entradas interactivas para obtener
información realizadas por un Complejidad
usuario (emisión de tickets,
Elemento B M A
reportes solicitados, etc.)
Funcional
Archivos Archivos lógicos del sistema
Entradas 1 3 5
Interfaces Interfaces no humanas con otros
sistemas (incluyendo acceso a Salidas 4 5 6
archivos) Consultas 3 4 6

Grado de Descripción Archivos 5 7 10

Complejidad Interfaces 7 10 15
Alto Complejo
Medio Medio
Bajo Simple
53
Tabla para calcular el Factor de Complejidad Total

# Factor de Complejidad Valor 0 = No influye

1 = Influye muy poco
1 Comunicación de datos 2 = Influye poco
2 Proceso distribuido 3 = Influye moderadamente
4 = Influye de manera importante
3 Objetivos de rendimiento (performance)
5 = Influyo mucho
4 Configuración bastante utilizada
5 Tasa de transacciones
6 Entrada de datos en línea
7 Eficiencia con el usuario final
8 Actualizaciones en línea
9 Procesamiento complejo
10 Reusabilidad del código
11 Facilidad de instalación
12 Facilidad de operación
13 Instalación en múltiples sitios
14 Facilidad para hacer cambios
FCT =

54
Ejemplo de Puntos de Función (1 de 3) 4

3
Funcionalidades Operaciones Elementos Clasificación Complejidad PF
Funcionales
Mantenimiento del Digitar datos Formulario de Entradas B 1
catálogo de captura de datos
productos
Reporte de rotación Capturar registros Procesos de M 3
de stock captura
Cálculo de costos Acceder o consultar Lectura de scanner M 3
archivos
Llamar o invocar Consultas / Consultas B 3
funciones Llamadas
Listar reportes Listados / Informes Salidas B 4

Generar archivos Archivo del sistema Archivos M 7

1 (Movimiento de
Productos)
2
Archivo externo Interfaces A 15
(Tipo de Cambio)
Puntos de Función No Ajustados Totales (PFn) 36

5
55
Ejemplo de Puntos de Función (2 de 3)

# Factor de Complejidad Valor 0 = No influye

1 = Influye muy poco
1 Comunicación de datos 1 2 = Influye poco
2 Proceso distribuido 1 3 = Influye moderadamente
4 = Influye de manera importante
3 Objetivos de rendimiento (performance) 4
5 = Influyo mucho
4 Configuración bastante utilizada 1
5 Tasa de transacciones 4
6 Entrada de datos en línea 5
7 Eficiencia con el usuario final 5
8 Actualizaciones en línea 5
9 Procesamiento complejo 5 6
10 Reusabilidad del código 5
11 Facilidad de instalación 5
12 Facilidad de operación 5
13 Instalación en múltiples sitios 2
14 Facilidad para hacer cambios 3
FCT = 51

56
Ejemplo de Puntos de Función (3 de 3)

7 PFa = PFn * (0.665 + 0.01 * FCT)

PFa = 36 * (0.665 + 0.01 * 51)

PFa = 43

57
Esfuerzo para construir el software

 Una vez identificado el tamaño del software, se requiere dividir este

tamaño entre la capacidad de producción de las personas que realizarán
el trabajo

 Esto es análogo a calcular cuánta y/o por cuánto tiempo se requiere

mano de obra para construir una casa de 100 m2, si se sabe que se
producen 5 m2 por cada día de 8 horas

 Consideraciones claves para estimar el esfuerzo:

 Contar con una tabla de productividad del personal en función a sus roles,
lenguajes de programación y tiempo. Opcionalmente se puede incluir un detalle con
la clasificación y el grado de complejidad de los puntos de función
 Alinear la estimación de tamaño con lo que está representado en la tabla de
productividad. Habrá una incompatibilidad de datos si se compara un tamaño
calculado en total de PF contra una tabla que está desagregada por complejidad
del punto de función
 Considerar el tiempo como factor clave para la medición. Se sugiere tener una
unidad de medida única como horas o días, y trabajar los cronogramas con esa
unidad de medida, para evitar incompatibilidades
58
Tabla de Productividad del Personal
Puntos de Función por Hora de Trabajo (ejemplo)

Lenguajes de Roles
Programación Analista Programador Programador
programador Senior Junior
Senior
VB .NET 4 3 2

C# 3 2 1

Java/J2EE 2 1 0.5

59
Ingeniería de Software y el PETI

60
Ingeniería de Software y el PETI

 Proyectos de Negocios
 Proceso de atención de requerimientos
 Pruebas: participación de usuarios y datos de pruebas
 Mantenimiento: costo y recurrencia
 Gestión de la configuración: ambientes
 Procesos y herramientas utilizadas
 Estimación del costo del software

 Proyectos Internos de TI
 Nuevos procesos de desarrollo: dinámico, ágil, etc.
 Capacitaciones y certificaciones
 Acciones de mejora de productividad

61
62
 Actividad:
Identificación de posibles causas
de alargamiento de proyectos de
Talibank

63
 ACTIVIDAD
Identificación de posibles causas de alargamiento de
proyectos de Talibank
 Conformar grupos. Obtener sus materiales: plumones, papelógrafo y masking tape
 Elija 5 proyectos que están en proceso o por iniciar en Talibank e identifique para cada
uno 3 posibles causas de alargamiento de acuerdo al Diagrama Causa-Efecto revisado
 Elija un proyecto y para cada una de sus posibles causas de alargamiento, proponga
una posible forma de mitigar o eliminar dicho riesgo
 Tiempos: Discusión y elaboración 40” / Exposiciones 20”
 Realizar la exposición al aula

64
65
66