Sei sulla pagina 1di 67

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

Ingeniería de Software

Estrategia y Gestión de los Sistemas de Información Ingeniería de Software 00

00

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

Introducción:

Introducción: Complejidad de los proyectos de TI 22

Complejidad de los proyectos de TI

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.

16% 31% 53%
16%
31%
53%
: El proyecto es cancelado en algún punto antes de terminar. 16% 31% 53% Exitosos Con

Exitosos

: El proyecto es cancelado en algún punto antes de terminar. 16% 31% 53% Exitosos Con

Con complicaciones

: El proyecto es cancelado en algún punto antes de terminar. 16% 31% 53% Exitosos Con

Fallados

: El proyecto es cancelado en algún punto antes de terminar. 16% 31% 53% Exitosos Con

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.

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.

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.

Causas de alargamiento de los proyectos

Causas de alargamiento de los proyectos 77

77

Introducción a la

Ingeniería de Software

88

¿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
INGENIERÍA DE SOFTWARE
Arte
Oficio

99

Historia de la Ingeniería de Software

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

1010

Disciplinas

1111

Disciplinas de la Ingeniería de Software

Disciplinas de la Ingeniería de Software 1212

1212

Requerimientos

1313

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

1414

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

1515

Patrones de requerimientos de software (2 de 2)

Información Interfaz inter- Fórmula de Tecnología sistemas cálculo Tipo de dato Estructura de Envejecimiento
Información
Interfaz inter-
Fórmula de
Tecnología
sistemas
cálculo
Tipo de dato
Estructura de
Envejecimiento
Cumplir con
Interacción
datos
de datos
estándar
Archivamiento
inter-sistemas
ID
de datos
Requerimientos
Fundamental
externos
Funcionalidad
Interfaz
Almacenar
usuaria
Documentación
usuaria
información
Consulta
Entidad de datos
Reportar
Reporte
Entidad viva
Transacción
Configuración
Crónica
Accesibilidad
Entidad de datos
Desempeño Instalabilidad Escalabilidad Tiempo de Ancho de banda respuesta Capacidad Extensibilidad Capacidad
Desempeño
Instalabilidad
Escalabilidad
Tiempo de
Ancho de banda
respuesta
Capacidad
Extensibilidad
Capacidad
Capacidad
dinámica
dinámica
estática
Facilidad de
instalación
Disponibilidad
Comercial
Multi
Multi lenguaje
Impuestos
organizaciones
Flexibilidad
Control Registro de de usuario acceso Autenticación Autorización Aprobación Autorización Autorización
Control
Registro de
de
usuario
acceso
Autenticación
Autorización
Aprobación
Autorización
Autorización
específica
configurable

1616

Diseño

1717

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

1818

Construcción

1919

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

lenguajes de construcción, codificación, pruebas de construcción, reuso, calidad de construcción e integración 2020

2020

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

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

2121

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

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

2222

Pruebas

2323

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

2424

Mantenimiento

2525

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

2626

Gestión de la configuración

2727

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

2828

Infraestructura - Ambientes de trabajo

Producción
Producción

Certificación

- Ambientes de trabajo Producción Certificación Desarrollo Gestión de la configuración Gestión de la

Desarrollo

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

2929

Gestión de la ingeniería de software

3030

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

3131

Proceso de ingeniería de software

3232

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

3333

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

3434

Cascada pura

Progresa a través de una secuencia ordenada de pasos
Progresa a través de una secuencia ordenada de pasos

Para pasar a la etapa siguiente se tienen

que haber conseguido los objetivos de la

etapa anterior

Concepto del

software

los objetivos de la etapa anterior Concepto del software Análisis de requerimientos Las etapas no se

Análisis de

requerimientos

Concepto del software Análisis de requerimientos Las etapas no se solapan Especificación de requerimientos

Las etapas no se solapan

Especificación de requerimientos

Especificación de requerimientos
Especificación de requerimientos
Especificación de requerimientos
Las etapas no se solapan Especificación de requerimientos Diseño preliminar Pocos signos visibles de progreso

Diseño

preliminar

Diseño preliminar
Diseño preliminar
Especificación de requerimientos Diseño preliminar Pocos signos visibles de progreso hasta el final Si falta

Pocos signos visibles de progreso hasta el final

Si falta una tarea pasada la etapa,

el trabajo retrasa la entrega y

aumenta el costo

Diseño

detallado

Diseño detallado
Diseño detallado
la entrega y aumenta el costo Diseño detallado Programación y pruebas Adecuado para versiones de

Programación y pruebas

Programación y pruebas
Programación y pruebas
Programación y pruebas
el costo Diseño detallado Programación y pruebas Adecuado para versiones de mantenimiento o migración

Adecuado para versiones de mantenimiento o migración

Explotación y mantenimiento

3535

Sashimi

Similar al modelo de cascada, pero con fases solapadas
Similar al modelo de cascada, pero con fases solapadas

Debido al solapamiento los hitos

resultan mas ambiguos

Debido al solapamiento los hitos resultan mas ambiguos Concepto del s o f t w a

Concepto del

software

resultan mas ambiguos Concepto del s o f t w a r e Análisis de r

Análisis de

ambiguos Concepto del s o f t w a r e Análisis de r e q

requerimientos Especificación de

e q u e r i m i e n t o s Especificación de requerimientos

requerimientos Diseño

o s Especificación de requerimientos D i s e ñ o preliminar Diseño d e t

preliminar Diseño

de requerimientos D i s e ñ o preliminar Diseño d e t a l l

detallado Programación y

pruebas

Actividades en paralelo puede suponer mala comunicación, suposiciones incorrectas e ineficacia.

Explotación y

mantenimiento

3636

Codificar y corregir

Empieza con una idea general de lo que se necesita, y luego se usa cualquier
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
(con suerte)
Codificar y corregir
Codificar y
corregir

Entrega (con suerte)

No se pierde tiempo en planificación, documentación, control de calidad, cumplimiento de estándares

Útil para proyectos pequeños que se liquidan después de construidos

Se pasa directamente a codificar, se muestra indicios de progreso

No permite evaluación de calidad e identificación de riesgos

3737

Modelo en espiral

Modelo orientado al riesgo que divide el proyecto software en miniproyectos. Cada miniproyecto se encarga
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 riesgos

Se conoce con anterioridad riesgos insuperables

INICIO

Determinar

objetivos y

alternativas

Identificar

riesgos

Determinar objetivos y alternativas Identificar riesgos Enfoque de siguiente iteración Evaluar alternativas Generar

Enfoque de

siguiente

iteración

Evaluar

alternativas

Generar entregas de iteración y comprobar su corrección

Planificar

siguiente

iteración

3838

Prototipo evolutivo

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

Se usa cuando el cliente no

facilita requerimientos y

especificaciones o cuando cambian con celeridad

Genera signos visibles de progreso y permite modificar sobre la marcha

visibles de progreso y permite modificar sobre la marcha Recolección y refinamiento de requisitos Diseño
Recolección y refinamiento de requisitos Diseño Evaluación rápido Construcción del prototipo Desarrollo del
Recolección y
refinamiento
de requisitos
Diseño
Evaluación
rápido
Construcción
del prototipo
Desarrollo del
producto final

Imposibilidad de conocer a priori tiempo de desarrollo

3939

Entrega por etapas

Luego del diseño global se puede implementar y entregar la aplicación en etapas. Se crea
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 Análisis de Proporciona signos tangibles de progreso requerimientos Especificación de
Concepto del
software
Análisis de
Proporciona signos tangibles
de progreso
requerimientos
Especificación de
requerimientos
Diseño
global

Proporciona funcionalidad útil en manos del cliente sin tener aplicación finalizada

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

depuración, prueba y entrega

detallado, codificación, depuración, prueba y entrega Etapa 2: Diseño detallado, codificación, depuración,

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

depuración, prueba y entrega

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

depuración, prueba y entrega

4040

Entrega evolutiva

Ofrece el control de la entrega por etapas y la flexibilidad del prototipo evolutivo. Se
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

Concepto del software
Concepto del software
Concepto del software

Entregar

versión

final

Análisis de

requerimientos

Entregar versión final Análisis de requerimientos Diseño global y del núcleo del sistema Repetir ciclo hasta
Entregar versión final Análisis de requerimientos Diseño global y del núcleo del sistema Repetir ciclo hasta

Diseño global y del núcleo del sistema

Diseño global y del núcleo del sistema
Diseño global y del núcleo del sistema
Diseño global y del núcleo del sistema

Repetir ciclo hasta

agotar tiempo, presupuesto, ejecutar iteraciones planeadas o hasta que el cliente

este satisfecho

Desarrollar una versión

Educir la realimentación
Educir la
realimentación

del cliente

Incorporar la

realimentación

del cliente

Entregar la

versión

Debe diseñarse previamente el

núcleo del

sistema y su globalidad

4141

Herramientas y métodos de

ingeniería de software

4242

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

4343

Unified Process

Unified Process 4444

4444

Capability Maturity Model Integrated (CMMi)

Capability Maturity Model Integrated (CMMi) 4545

4545

Capability Maturity Model Integrated Level 3

Capability Maturity Model Integrated – Level 3 4646

4646

Calidad del software

4747

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

4848

Estimación del Tamaño y el

Esfuerzo del Software

4949

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

5050

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

5151

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)

5252

Tablas para obtener la Cantidad de Puntos de Función

Clasificación

Descripción

Entradas

Entradas externas provistas por un usuario (selecciones de

opciones, ingresos de datos, etc.)

Salidas

Salidas externas esperadas por un usuario (reportes programados, mensajes, etc.)

Consultas

Entradas interactivas para obtener información realizadas por un usuario (emisión de tickets,

reportes solicitados, etc.)

Archivos

Archivos lógicos del sistema

Interfaces

Interfaces no humanas con otros

sistemas (incluyendo acceso a archivos)

Grado de Complejidad

Descripción

Alto

Complejo

Medio

Medio

Bajo

Simple

Entrada Salida Consulta Sistema Otro sistema Archivo
Entrada
Salida
Consulta
Sistema
Otro
sistema
Archivo

Interfaz

 

Complejidad

Elemento

B

M

A

Funcional

Entradas

1

3

5

Salidas

4

5

6

Consultas

3

4

6

Archivos

5

7

10

Interfaces

7

10

15

Salidas 4 5 6 Consultas 3 4 6 Archivos 5 7 10 Interfaces 7 10 15

5353

Tabla para calcular el Factor de Complejidad Total

#

Factor de Complejidad

Valor

1

Comunicación de datos

 

2

Proceso distribuido

 

3

Objetivos de rendimiento (performance)

 

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 =

 

0 = No influye

1 = Influye muy poco

2 = Influye poco

3 = Influye moderadamente

4 = Influye de manera importante

5 = Influyo mucho

influye 1 = Influye muy poco 2 = Influye poco 3 = Influye moderadamente 4 =
muy poco 2 = Influye poco 3 = Influye moderadamente 4 = Influye de manera importante

5454

4
4

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

3 Funcionalidades Operaciones Elementos Clasificación Complejidad PF Funcionales Mantenimiento del catálogo de
3
Funcionalidades
Operaciones
Elementos
Clasificación
Complejidad
PF
Funcionales
Mantenimiento del
catálogo de
Digitar datos
Formulario de
captura de datos
Entradas
B
1
productos
Reporte de rotación
de stock
Capturar registros
Procesos de
M
3
captura
Cálculo de costos
Acceder o consultar
Lectura de scanner
M
3
archivos
Llamar o invocar
funciones
Consultas /
Consultas
B
3
Llamadas
Listar reportes
Listados / Informes
Salidas
B
4
Generar archivos
Archivo del sistema
(Movimiento de
Productos)
Archivos
M
7
1
2
Archivo externo
Interfaces
A
15
(Tipo de Cambio)
Puntos de Función No Ajustados Totales (PFn)
36

5

5555

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

#

Factor de Complejidad

Valor

1

Comunicación de datos

1

2

Proceso distribuido

1

3

Objetivos de rendimiento (performance)

4

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

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

0 = No influye

1 = Influye muy poco

2 = Influye poco

3 = Influye moderadamente

4 = Influye de manera importante

5 = Influyo mucho

influye 1 = Influye muy poco 2 = Influye poco 3 = Influye moderadamente 4 =
6
6

5656

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

7
7

PFa = PFn * (0.665 + 0.01 * FCT)

PFa = 36 * (0.665 + 0.01 * 51)

PFa = 43

5757

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

5858

Tabla de Productividad del Personal

Puntos de Función por Hora de Trabajo (ejemplo)

Lenguajes de Programación

Roles

Analista

Programador

Programador

 

programador

Senior

Junior

Senior

VB .NET

4

3

2

C#

3

2

1

Java/J2EE

2

1

0.5

5959

Ingeniería de Software y el PETI

6060

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

6161

6262

Actividad:

Actividad: Identificación de posibles causas de alargamiento de proyectos de Talibank 6363
Actividad: Identificación de posibles causas de alargamiento de proyectos de Talibank 6363

Identificación de posibles causas

de alargamiento de proyectos de

Talibank

6363

Identificación de posibles causas de alargamiento de

proyectos de Talibank

ACTIVIDAD

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

6464

6565

6666