Ingeniería de Software I

INGENIERÍA DE SOFTWARE I
CAPÍTULO IV: PROYECTOS DE

SOFTWARE
http://www.ticweb.es/aplicaciones-para-la-administracion-de-
proyectos/
CAPÍTULO IV: PROYECTOS DE SOFTWARE
EL ESPECTRO ADMINISTRATIVO
La administración efectiva de un proyecto
de software se enfoca en las cuatro P:
personal, producto, proceso y proyecto. El
orden no es arbitrario. El gerente que
olvida que el trabajo de la ingeniería del
software es una empresa intensamente
humana nunca triunfará en la
administración del proyecto. Un gerente
que fracase en alentar una comunicación
comprensiva con los participantes durante
las primeras etapas de la evolución de un
producto se arriesga a construir una
solución elegante para el problema
equivocado. El gerente que ponga poca
atención al proceso corre el riesgo de
insertar métodos y herramientas técnicos
competentes pero en el vacío. Aquel que proyectos/
se embarque sin un plan sólido pone en
peligro el éxito del proyecto. (Pressman,
2010, pág. 555)
FIGURA 2.3 (Pressman, 2010, pág. 34).

La administración de los proyectos de
software comienza con un conjunto de
actividades que de manera colectiva se
llaman planificación de proyecto. Antes de
que el proyecto pueda comenzar, el
equipo de software debe
debe estimar
estimar
el trabajo que se va a realizar, los
recursos que se requerirán y el tiempo
que transcurrirá de principio a fin. Una vez
completadas dichas actividades, el equipo
de software debe establecer un
calendario del proyecto que defina las
tareas e hitos de la ingeniería de
software, que identifique quién es
responsable de realizar cada tarea y http://www.ticweb.es/aplicaciones-para-la-administracion-de-
proyectos/
especifique las dependencias entre tareas
que puedan imponer una fuerte demora
sobre el avance. (Pressman, 2010, pág.
562)
MÉTRICAS
1. MARCO CONCEPTUAL PARA LAS

MÉTRICAS DE PRODUCTO
1.1. Métricas para el Modelo de
Requerimientos
1.1.1. Métrica basada en funciones
2. MÉTRICAS EN LOS DOMINIOS DE

PROCESO Y PROYECTO
2.1. Medición del Software
2.1.1. Métricas orientadas a tamaño
2.1.2. Métricas orientadas a función
3. MODELO DE ESTIMACIÓN
EMPÍRICOS proyectos/
3.1. El modelo COCOMO II

1. MARCO CONCEPTUAL PARA LAS MÉTRICAS DE PRODUCTO
1.1. Métricas para el Modelo de Requerimientos
El trabajo técnico en la ingeniería del software
comienza con la creación del modelo de
requerimientos. En esta etapa se derivan los
requerimientos y se establece un cimiento para el
diseño. Por tanto, son deseables métricas de
producto que proporcionen comprensión acerca de
la calidad del modelo de análisis.
La métrica de punto de función (PF) puede usarse
de manera efectiva como medio para medir la
funcionalidad que entra a un sistema. Al usar datos
históricos, la métrica PF puede entonces usarse
para: 1) estimar el costo o esfuerzo requerido para
diseñar, codificar y probar el software; 2) predecir
el número de errores que se encontraran durante http://www.ticweb.es/aplicaciones-para-la-
las pruebas, y 3) prever el número de administracion-de-proyectos/
componentes y/o de líneas fuente proyectadas en

el sistema implementado. (Pressman, 2010, pág.
532)
Los valores de dominio de información se
definen en la forma siguiente:
Número de entradas externas (EE). Cada
entrada externa se origina de un usuario o se
transmite desde otra aplicación, y proporciona
distintos datos orientados a aplicación o
información de control. Con frecuencia, las
entradas se usan para actualizar archivos lógicos
internos (ALI). Las entradas deben distinguirse
de las consultas, que se cuentan por separado.
Número de salidas externas (SE). Cada salida
externa es datos derivados dentro de la
aplicación que ofrecen información al usuario. En http://www.ticweb.es/aplicaciones-para-la-
administracion-de-proyectos/
este contexto, salida externa se refiere a
reportes, pantallas, mensajes de error, etc. Los
items de datos individuales dentro de un reporte
no se cuentan por separado. (Pressman, 2010,
pág. 532)
Número de consultas externas (CE). Una

consulta externa se define como una entrada
en línea que da como resultado la generación
de alguna respuesta de software inmediata en
la forma de una salida en línea (con
frecuencia recuperada de un ALI).
Número de archivos lógicos internos (ALI).
Cada archivo lógico interno es un
agrupamiento lógico de datos que reside
dentro de la frontera de la aplicación y se
mantiene mediante entradas externas.
Número de archivos de interfaz externos
(AIE). Cada archivo de interfaz externo es un
agrupamiento lógico de datos que reside fuera http://www.ticweb.es/aplicaciones-para-la-administracion-
de-proyectos/
de la aplicación, pero que proporciona
información que puede usar la aplicación.
(Pressman, 2010, pág. 532)
Una vez recolectados dichos datos, la tabla de la figura 23.1 se completa y un
valor de complejidad se asocia con cada conteo. Las organizaciones que usan
métodos de punto de función desarrollan criterios para determinar si una entrada
particular es simple, promedio o compleja. No obstante, la determinación de
complejidad es un tanto subjetiva. (Pressman, 2010, pág. 532)
Figura 23.1 Cálculo de puntos de función (Pressman, 2010, pág. 532)

No obstante, la determinación de complejidad es un tanto subjetiva.
Para calcular puntos de función (PF), se usa la siguiente relación:
PF = conteo total X [0.65 + 0.01 X ∑ (Fi)]
donde conteo total es la suma de todas las entradas PF obtenidas de la figura
23.1.
Los Fi (i = 1 a 14) son factores de ajuste de valor (FAV) con base en
respuestas a las siguientes preguntas [Lon02]: (Pressman, 2010, pág. 532)

a.1. El sistema requiere respaldo y recuperación confiables?
a.2. Se requieren comunicaciones de datos especializadas para transferir
información hacia o desde la aplicación?
a.3. Existen funciones de procesamiento distribuidas?
a.4. El desempeño es crucial?
a.5. El sistema correrá en un entorno operativo existente enormemente utilizado?
a.6. El sistema requiere entrada de datos en línea?
a.7. La entrada de datos en línea requiere que la transacción de entrada se
construya sobre múltiples pantallas u operaciones?
a.8. Los ALI se actualizan en línea?
a.9. Las entradas, salidas, archivos o consultas son complejos?
a.10. El procesamiento interno es complejo?
a.11. El código se diseña para ser reutilizable?
a.12. La conversión y la instalación se incluyen en el diseño?
a.13. El sistema se diseña para instalaciones múltiples en diferentes
organizaciones?
a.14. La aplicación se diseña para facilitar el cambio y su uso por parte del
usuario? (Pressman, 2010, pág. 532)
PF = conteo total X [0.65 + 0.01 X ∑ (Fi)]
En la figura 23.3 se muestran estos datos, junto con la complejidad adecuada.
El conteo total que se muestra en la figura 23.3 debe ajustarse usando la
ecuación (23.1). Para los propósitos de este ejemplo, suponga que ∑ (Fi) es 46
(un producto moderadamente complejo). Por tanto, PF = 50 X [0.65 + (0.01 X
46)] = 56 (Pressman, 2010, pág. 532)

2. MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO

2.1.1. Métricas orientadas a tamaño
Con la finalidad de desarrollar métricas que
puedan asimilarse con métricas similares de
otros proyectos, pueden elegirse líneas de
códigos como un valor de normalización. A
partir de los rudimentarios datos contenidos
en la tabla, pueden desarrollarse métricas
simples orientadas a tamaño para cada
proyecto:
• Errores por KLOC (miles de líneas de
código).
• Defectos por KLOC.
• $ por KLOC.
• Páginas de documentación por KLOC.
Además, es posible calcular otras métricas http://www.ticweb.es/aplicaciones-para-la-administracion-
interesantes: de-proyectos/
• Errores por persona-mes.

• KLOC por persona-mes.
• $ por página de documentación. (Pressman, 2010, pág. 577)

2.1.2. Métricas orientadas a función
Las métricas de software orientadas a función
usan una medida de la funcionalidad entregada
por la aplicación como un valor de
normalización. La métrica orientada a función
de mayor uso es el punto de función (PF). El
cálculo del punto de función se basa en
características del dominio y de la complejidad
de información del software.
El punto de función, como la medida LOC, es
controvertido. Quienes lo proponen afirman que
el PF es independiente del lenguaje de
programación, lo que lo hace ideal para http://www.ticweb.es/aplicaciones-para-la-
aplicaciones que usan lenguajes
convencionales y no procedurales, y que se
basa en datos que es más probable que se
conozcan tempranamente en la evolución de un
proyecto, lo que hace al PF más atractivo como
enfoque de estimación. (Pressman, 2010, pág. 577)

2.1.3. Reconciliación de métricas LOC y PF
La relación entre líneas de código y
puntos de función depende del
lenguaje de programación que se
use para implementar el software y la
calidad del diseño. Algunos estudios
intentan relacionar las medidas PF y
LOC. La tabla4 [QSM02], que se
presenta en la página siguiente,
ofrece estimaciones burdas del
número promedio de líneas de
código requeridas para construir un
punto de función en varios lenguajes http://www.ticweb.es/aplicaciones-para-la-administracion-de-
proyectos/
de programación. Una revisión de
estos datos indica que un LOC de
C++ proporciona aproximadamente
2.4 veces la “funcionalidad” (como
promedio) que un LOC de C.

2.1.3. Reconciliación de métricas LOC y PF
Más aún, un LOC de Smalltalk

proporciona al menos cuatro veces
la funcionalidad de un LOC para un
lenguaje de programación
convencional, como Ada, COBOL o
C. Al usar la información contenida
en la tabla, es posible “retroactivar”
[Jon98] el software existente para
estimar el número de puntos de http://www.ticweb.es/aplicaciones-para-la-administracion-de-
función, una vez conocido el proyectos/
número total de enunciados del

lenguaje de programación.

2.1. Medición del
Software
2.1.3.
Reconciliación de
métricas LOC y PF

MÉTRICAS
1. MARCO CONCEPTUAL PARA

LAS MÉTRICAS DE PRODUCTO
1.1. Métricas para el Modelo de
Requerimientos
2. MÉTRICAS EN LOS DOMINIOS

DE PROCESO Y PROYECTO
2.1.1. Métricas orientadas a
tamaño
2.1.2. Métricas orientadas a
función
3. MODELO DE ESTIMACIÓN
EMPÍRICOS
3. MODELO DE ESTIMACIÓN EMPÍRICOS
En su libro clásico acerca de
“economía de la ingeniería de
software”, Barry Boehm [Boe81]
introdujo una jerarquía de modelos de
estimación de software que llevan el
nombre COCOMO, por COnstructive
COst MOdel: modelo constructivo de
costos. El modelo COCOMO original
se convirtió en uno de los modelos de
estimación de costo más ampliamente
utilizados y estudiados en la industria.
Evolucionó hacia un modelo de
estimación más exhaustivo, llamado
COCOMO II [Boe00]. Como su
predecesor, COCOMO II en realidad es http://www.ticweb.es/aplicaciones-para-la-administracion-de-
proyectos/
una jerarquía de modelos de
estimación que aborda las áreas
siguientes: (Pressman, 2010, pág. 609)
• Modelo de composición de aplicación. Se usa
durante las primeras etapas de la ingeniería de
software, cuando son primordiales la elaboración
de prototipos de las interfaces de usuario, la
consideración de la interacción del software y el
sistema, la valoración del rendimiento y la
evaluación de la madurez de la tecnología.
• Modelo de etapa temprana de diseño. Se usa
una vez estabilizados los requisitos y establecida
la arquitectura básica del software.
• Modelo de etapa postarquitectónica. Se usa
durante la construcción del software.
Como todos los modelos de estimación para
http://www.ticweb.es/aplicaciones-para-la-
software, los modelos COCOMO II requieren administracion-de-proyectos/
información sobre dimensionamiento. Como parte

de la jerarquía del modelo, están disponibles tres
diferentes opciones de dimensionamiento: puntos
objeto, puntos de función y líneas de código
fuente. (Pressman, 2010, pág. 609)
El modelo de composición de aplicación COCOMO II
usa puntos de objeto y se ilustra en los siguientes
párrafos. Debe observarse que otros modelos de
estimación, más sofisticados (que usan PF y KLOC),
también están disponibles como parte de COCOMO II.
Como los puntos de función, el punto de objeto es una
medida de software indirecta que se calcula usando
conteos del número de 1) pantallas (en la interfaz de
usuario), 2) reportes y 3) componentes que
probablemente se requieran para construir la
aplicación. Cada instancia de objeto (por ejemplo, una
pantalla o reporte) se clasifica en uno de tres niveles http://www.ticweb.es/aplicaciones-para-la-
de complejidad (simple, medio o difícil), usando
criterios sugeridos por Boehm [Boe96]. En esencia, la
complejidad es una función del número y de la fuente
de las tablas de datos de cliente y servidor que se
requieren para generar la pantalla o el reporte y el
número de vistas o secciones que se presentan como
parte de la pantalla o del reporte. (Pressman, 2010,
pág. 610)
Una vez determinada la complejidad, el número de pantallas, reportes y
componentes se ponderan de acuerdo con la tabla que se ilustra en la figura
26.6. Entonces se determina el conteo de puntos de objeto multiplicando el
número original de instancias de objeto por el factor de ponderación que hay
en la figura y se suman para obtener un conteo total de puntos de objeto.
Cuando debe aplicarse desarrollo basado en componente o reúso de software
general, se estima el porcentaje de reusó (%reusó) y el conteo de puntos de
objeto se ajusta: (Pressman, 2010, pág. 610)

/
Lista de Referencias.
• Pressman, R. (2010). Ingeniería del Software: Un enfoque práctico. México: Mc
Graw Hill.
• http://www.ticweb.es/aplicaciones-para-la-administracion-de-proyectos/

Ingeniería de Software I - Unidad 4

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ingeniería de Software I - Unidad 4

Cargado por

Copyright:

Formatos disponibles

CAPÍTULO IV: PROYECTOS DE

FIGURA 2.3 (Pressman, 2010, pág. 34).

1. MARCO CONCEPTUAL PARA LAS

2. MÉTRICAS EN LOS DOMINIOS DE

3.1. El modelo COCOMO II

componentes y/o de líneas fuente proyectadas en

Número de consultas externas (CE). Una

Figura 23.1 Cálculo de puntos de función (Pressman, 2010, pág. 532)

Figura 23.1 Cálculo de puntos de función (Pressman, 2010, pág. 532)

Figura 23.3 Cálculo de puntos de función (Pressman, 2010, pág. 532)

2. MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO

• Errores por persona-mes.

2. MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO

2. MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO

2. MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO

Más aún, un LOC de Smalltalk

número total de enunciados del

2. MÉTRICAS EN LOS DOMINIOS DE PROCESO Y PROYECTO

(Pressman, 2010, pág. 578)

1. MARCO CONCEPTUAL PARA

2. MÉTRICAS EN LOS DOMINIOS

información sobre dimensionamiento. Como parte

(Pressman, 2010, pág. 610)

También podría gustarte