El presente estudio de viabilidad brinda la
documentación necesaria para que la alta
gerencia decida tomar una de decisión en la
ejecución
del
sistema
manual
a
la
automatización en un periodo de tiempo que la
gerencia del negocio considere oportuno, por lo
tanto el equipo investigativo efectúa un
prototipo de sistema de información de Control
de Inventario y Facturación.
Permite especificar los recursos de software y
hardware para el desarrollo del sistema
proporcionando una mayor efectividad en su
implementación.
A continuación se detallan las características de los
equipos del negocio:
Análisis de los recursos de hardware
La empresa cuenta con los equipos tecnológicos
necesarios y las características que exigen las
nuevas plataformas existentes en el mercado,
permitiendo que este se ejecute sin presentar
problemas al momento de procesar los datos. A
continuación detallamos:
Nombre
Cantidad
Descripción
Procesador Intel Celeron 1.60GHz
Estación de Trabajo
3
Memoria 512 MB
Monitor
Impresora
1
Hewlet
Packard
caracteristicas)
(Agregar
sus
b) Análisis de los recursos de software
Para el desarrollo del sistema automatizado se elige como
lenguaje de programación C# que es orientado a objetos
permitiendo que la aplicación pueda ser ejecutada en
cualquier sistema operativo y multilenguaje que trabaja
con Cristal Report que genera reportes de salida en un
formato de datos y tiene un alto nivel de portabilidad y
gestor de base de datos SQL Server 2005 que presenta
características que lo hacen optimo para cualquier sistema
automatizado como: rapidez, multiplataforma, multiusuario
y permite la encriptación de datos lo que asegura que estos
puedan viajar por la red de forma segura y no ser
interceptados.
Consiste en realizar un análisis de las necesidades y definir
en base a estas los beneficios que se obtendrán a partir de
la implementación del sistema
Situación sin proyecto
No existe ninguna comunicación directa entre el área de
ventas e inventario, por lo que es manual, trayendo como
consecuencia demora en los procesos.
• Constante retraso en el proceso de inventario.
• La afluencia de clientes es significativo en las horas picos,
por lo que el tiempo de respuesta es lento.
• No existe integración automatizada con las otras áreas,
limitando el rendimiento.
Situación optimizada sin proyecto
•Establecer una mejor comunicación entre el
área de ventas e inventario.
•Redistribuir al personal, para hacerlo más
eficiente.
•Mejorar la organización de las áreas de
mayor demanda.
Situación con proyecto
Al instalar en la red LAN, el sistema
automatizado da una conexión directa y
acceso
de
compartir
archivos
de
información.
El departamento de ventas puede acceder a
los datos necesarios para minimizar el
tiempo de espera del cliente.
Todas las áreas contaran con la información
precisa para sus reportes.
Proporciona los datos necesarios para determinar
si el proyecto es viable, es decir si debe aceptarse o
rechazarse.
Beneficios tangibles
•Facilitar y optimizar tareas rutinarias.
•Reducir tiempo en el procesamiento de la
información automatizada con respecto al proceso
manual.
•Disminuir los costos económicos de los procesos.
•Control general y detallado de las existencias en
bodega.
Beneficios intangibles
•Seguridad y confiabilidad en la información.
•Portabilidad del sistema.
•Mejor servicio de atención al cliente.
•Brindar apoyo a la toma de decisiones al
ofrecer flexibilidad en la emisión de reportes
con información actualizada y veraz.
•Control de los accesos de usuarios
PRODUCTO
Características
del Cliente
Mercado
Competitivo
Organización (Solución
de Negocio)
PROCESO
PERSONAS
TECNOLOGIA
Entorno de
Desarrollo
Sistemas de
Información
Se derivan de la normalización de las medidas de
calidad y productividad con base al tamaño del
software desarrollado con anterioridad.
– No. de líneas de código (LDC)
– Esfuerzo (persona-mes)
– Costo
Ciclo de Vida de un Proyecto
– Personas participantes
– Errores durante el desarrollo
– Errores en el uso del producto
Las líneas de
código (LCD) es
un valor de
normalización
que permite
hacer
comparaciones
entre distintos
proyectos
Otros elementos
Errores / Miles de LCD
Defectos / Miles de LCD
Costo / Miles de LCD
Páginas de Documentación / Miles de LCD
Esfuerzo / Miles de LCD
Errores / Esfuerzo
Costo / Páginas de documentación
•La mayoría de los modelos de estimación de
software utilizan las LCD como clave de entrada.
•Existe un amplio conjunto de datos y literatura
que utilizan las LDC.
•En base a las LCD se pueden hacer fácilmente
otras estimaciones.
•Las LCD son dependientes del lenguaje de
programación. Perjudican a los programas más
cortos.
•No
incorpora
procedimentales.
fácilmente
lenguajes
•Requiere un nivel de detalle difícil de alcanzar.
PUNTOS DE FUNCION
PUNTOS DE FUNCIÓN (indirecta
¿Qué son?
Los Puntos de Función, llamados así por vez primera por Albertch,
A.J, son métricas orientadas a la función con un valor de
normalización.
Definición
Los Puntos de Función, son una forma sintética o alternativa para
medir el tamaño de un software.
Utilización
Los Puntos de Función, se utilizan en los primeros estudios del
desarrollo de un software, independientemente de la metodología
utilizada, y se determinan a partir de las especificaciones de los
requerimientos de la etapa de análisis que sirven de fundamento
para la etapa de diseño.
PUNTOS DE FUNCIÓN (indirecta
ET
AN
APA
ALIS
DE
IS
Por lo tanto los Puntos de Función
proporcionan una visión interna de la
calidad de los modelos de análisis.
Para una buena estimación es necesario un buen
análisis y compresión de cada una de las prestaciones
del producto, mediante una gestión de los
requerimientos:
– Metodología de análisis de requerimiento.
– Método para crear modelos de sistemas.
– Métodos de comunicación.
FASES DE REQUERIMIENTOS
Concepto del Producto
Análisis de
Requerimiento
•Buena comunicación con el usuario
Diseño
Preliminar
•Las especificaciones
completas
Diseño
Detallado
•Reducir
al
mínimo
las
modificaciones en cuanto a los
requerimientos y especificaciones
posteriores
Código
deben
ser
COMO SE DETERMINAN LOS PUNTOS DE
FUNCION
Se deriva de una
relación
de
empírica
acuerdo
a
medidas que sí son
contables de forma
directa.
Dominio de la Información y Evaluaciones de
Complejidad
•Número de Entradas de Usuario: que proporciona diferentes datos
orientados a la aplicación (no considera peticiones).
•Número de Salidas de Usuario: que proporciona información orientada a
la aplicación (informes, pantallas, mensajes de error, etc.)
•Número de Peticiones de Usuario: que es una entrada interactiva que
produce alguna respuesta del software inmediata en forma de salida
interactiva
•Número de Archivos Lógicos: que pueden ser parte de una gran base de
datos o archivos independientes.
•Número de Interfaces Externas: flujos legibles por la máquina (archivos
de datos de cinta o de disco) que transfieren información desde o hacia
otros sistemas.
UN
EJEMPLO GRÁFICO DE
CARACTERÍSTICAS DE DOMINIO
DEFINICIÓN
DE
LAS
UN
EJEMPLO GRÁFICO DE
CARACTERÍSTICAS DE DOMINIO
DEFINICIÓN
DE
LAS
DEFINIR el Valor de Complejidad para cada uno de los
dominios de información:
• SIMPLE
• MEDIO
• COMPLEJO
DEFINIR la fórmula para calcular los Puntos de Función con
relación a la complejidad para cada dominio de información:
PFA = PF x [ 0,65 + 0,01 x S Fi ]
Significados de los elementos de la fórmula
MULTIPLICADOR
Puntos de Función
Ajustados
PFA =
PF
Es un multiplicador estandarizado
de influencia cuyo intervalo es de
0,65 a 1,35
x
El total de los puntos de función sin
ajustar (de acuerdo a las 5 características
de dominio de la información)
[ 0,65 + 0,01 x S Fi ]
Valores de ajuste
de la
complejidad
(según
la
respuesta a 14 preguntas en
una escala de 0 a 5)
Sustitución gráfica de la fórmula de Puntos de
Función
PFA = Cuenta Total x [ 0,65 + 0,01 x S Fi ]
Resultado Gráfico de Puntos de Función
Dominio de
Información
349.6
PFA
Multiplicador estandarizado
MSc. Claudia Benavidez Rugama
Estimación de las LDC requerida para cada Punto de Función
de acuerdo al número medio LDC de un lenguaje de
programación determinado.
FÓRMULA:
TLDC
=
Número Medio de LDC de un “x”
Lenguaje de Programación
X
PFA
EJEMPLO:
24,472
=
70
(Lenguaje de Programación ADA)
X
349.6
MSc. Claudia Benavidez Rugama
MÉTRICAS ORIENTADAS AL TAMAÑO
Presentación Gráfica de la Estimación de las LDC
24,472
=
Lenguaje de Programación ADA
X
349.6
349,6
ESTIMACIÓN DEL ESFUERZO
•La Estimación del Esfuerzo nos determina el número de
personas que hay que incorporar al proyecto.
– Utilización de estimaciones a partir del tamaño
– Utilización de estimación a partir del tamaño en LDC
– Utilización del método algorítmico de aproximación (COCOMO)
COCOMO II
A x (Tamaño) B x  EMi
• Esfuerzo (personas-meses) =
donde :
A es una constante derivada de la calibración igual a 2.94.
B = 0.91 + 0.01 x S SFi, donde SFi es un factor para cada uno
de los indicadores de escala (5).
EMi es el Factor de esfuerzo compuesto obtenido a partir de los
indicadores
• El Tiempo de Desarrollo del Proyecto se estima a partir de la siguiente ecuación:
Tdes = 3.67*(E) 0.28+0.002*SSF
• La Cantidad de Personal necesaria para desarrollar el Sistema se cuantifica a
partir de la siguiente ecuación:
CH=E/Tdes
FACTORES DE ESCALA
. Precedentes (PREC)
. Flexibilidad de Desarrollo (FLEX)
. Resolución de Arquitectura/Riesgo (RESL)
. Cohesión del Equipo de Trabajo (TEAM)
. Madurez del proceso (PMAT)
Son cinco factores que afectan E, el exponente del TAMAÑO:
• PREC: Desarrollos previos similares
•0.00: nuevo desarrollo es idéntico a previos
•1.24: es muy parecido
•2.48: bastante parecido
•3.72: aspectos novedosos
•4.96: muy diferente
•6.20: totalmente diferente.
•FLEX: Flexibilidad del desarrollo (e.g. grado de acuerdo con requerimientos
pre-establecidos o con interfaces externos pre-existente)
•0.00: metas son generales
•1.01: cierto acuerdo
•2.03: acuerdo general
•3.04: cierta flexibilidad
•4.05: flexibilidad ocasional
•5.07: riguroso
FACTORES DE ESC ALA (SFi)
RESL: Manejo de riesgos y arquitectura
0.00: plan identifica todos los riesgos críticos y establece hitos para resolverlos,
calendario y presupuesto toma en cuenta riesgos, arquitectura puede tomarse
hasta el 40% del esfuerzo de desarrollo, herramientas disponibles para
resolver/mitigar riesgos y verificar especificación de la arquitectura muy poca
incertidumbre de remisión, interfaz con usuario, tecnología, desempeño, riesgos no
son críticos.
1.41: plan identifica la mayoría de los riesgos críticos y establece hitos para
resolverlos, calendario y presupuesto toma en cuenta la mayoría de los riesgos,
arquitectura puede tomarse hasta el 33% del esfuerzo de desarrollo, herramientas
disponibles para resolver/mitigar mayoría de riesgos y verificar especificación de la
arquitectura, poca incertidumbre remisión, interfaz con usuario, tecnología,
desempeño, riesgos no son críticos.
2.83: plan identifica muchos de los riesgos críticos y establece hitos para
resolverlos, calendario y presupuesto generalmente toma en cuenta riesgos,
arquitectura puede tomarse hasta el 25% del esfuerzo de desarrollo, herramientas
regularmente disponibles para resolver/mitigar riesgos y verificar especificaciòn de
la arquitectura algo de incertidumbre remisión, interfaz con usuario, tecnología,
desempeño, no más de un riesgo crítico.
FACTORES DE ESC ALA (SFi)
RESL: Manejo de riesgos y arquitectura
4.24: plan identifica algunos de los riesgos críticos y establece hitos para resolverlos,
calendario y presupuesto toma en cuenta algunos de los riesgos, arquitectura puede
tomarse hasta el 17% del esfuerzo de desarrollo, hay problemas con la disponibilidad
del arquitecto, algo de herramientas disponibles para resolver/mitigar riesgos,
verificar especificación de la arquitectura, considerable incertidumbre re misión,
interfaz con usuario, tecnología, desempeño, entre 2-4 riesgos críticos.
5.65: plan identifica pocos riesgos críticos y establece hitos para resolverlos,
calendario y presupuesto toma en cuenta pocos riesgos, arquitectura puede tomarse
hasta el 10% del esfuerzo de desarrollo, hay problemas con la disponibilidad del
arquitecto (disp. menor al 40%), pocas herramientas disponibles para resolver/mitigar
riesgos y verificar especificación de la arquitectura, significativa incertidumbre re
misión, interfaz con usuario, tecnología, desempeño, entre 5-10 riesgos críticos.
7.07: plan no identifica los riesgos críticos, calendario y presupuesto no toma en
cuenta los riesgos, arquitectura puede tomarse hasta el 5% del esfuerzo de desarrollo,
hay problemas con la disponibilidad del arquitecto (disp. menor del 20%),
herramientas no disponibles para resolver/mitigar riesgos y verificar especificación de
la arquitectura, extrema incertidumbre remisión, interfaz con usuario, tecnología,
desempeño, más de 10 riesgos críticos.
FACTORES DE ESCALA (SFi)
TEAM: Cohesión del equipo de desarrollo
0.0: interacciones fluidas, objetivos y culturas de accionistas totalmente
consistentes, total habilidad y disponibilidad de accionistas para
acomodar objetivos de otros accionistas, dilatada experiencia previa
operando como equipo, visión y compromisos 100% compartidos.
1.1: interacciones altamente cooperativas, objetivos y culturas de
accionistas fuertemente consistentes, fuerte habilidad y disponibilidad de
accionistas para acomodar objetivos de otros accionistas, considerable
experiencia previa operando como equipo, visión y compromisos
considerablemente compartidos.
2.19: interacciones principalmente cooperativas, objetivos y culturas de
accionistas considerablemente consistentes, considerable habilidad y
disponibilidad de accionistas para acomodar objetivos de otros
accionistas, mediana experiencia previa operando como equipo, visión y
compromisos medianamente compartidos.
FACTORES DE ESCALA (SFi)
TEAM: Cohesión del equipo de desarrollo
3.29: interacciones básicas cooperativas, objetivos y culturas de
accionistas básicamente consistentes, habilidad y disponibilidad básica
de accionistas para acomodar objetivos de otros accionistas, poca
experiencia previa operando como equipo, visión y compromisos poco
compartidos.
4.38: algunas interacciones difíciles, objetivos y culturas de accionistas
algo consistentes, algo habilidad y disponibilidad de accionistas para
acomodar objetivos de otros accionistas, poca experiencia previa
operando como equipo, visión y compromisos poco compartidos.
5.48: interacciones difíciles, objetivos y culturas de accionistas poco
consistentes, poca habilidad y disponibilidad de accionistas para
acomodar objetivos de otros accionistas, nada de experiencia previa
operando como equipo, visión y compromisos nada compartidos.
FACTORES DE ESCALA (SFi)
Madurez del proceso (PMAT) estimada, en relación al modelo de madurez de software CMM:
El Modelo de Capacidad de Madurez (CMM)
•Modelo de Madurez del Proceso de Software - desarrollado para evaluar las
capacidades de una organización de software e identificar las áreas más importantes de
mejoramiento - tratando el proceso completo de desarrollo de software como un
proceso que puede ser controlado, medido, y mejorado.
•Para mejorar sus capacidades, las organizaciones de software deben: comprender el
estado actual de sus procesos de software; desarrollar una visión de los procesos
deseados; establecer una lista de las acciones de mejoramiento requeridas en orden de
prioridad; producir un plan para cumplir dichas acciones; y comprometer los recursos
para ejecutar el plan
•Descompone cada nivel de madurez en áreas claves de proceso (KPA), prácticas claves,
e indicadores claves.
•Áreas claves: identifican objetivos a ser alcanzados para alcanzar un nivel de madurez
particular.
•Prácticas claves: procedimientos y actividades que contribuyen a alcanzar los objetivos.
•Indicadores claves: ayudan a determinar el cumplimiento de los objetivos, forman la
base para el procedimiento de evaluación.
FACTORES DE ESCALA (SFi)
Madurez del proceso (PMAT) estimada, en relación al modelo de madurez de software CMM:
El Modelo de Capacidad de Madurez (CMM)
•Desenfatiza el score (nivel de madurez) de una evaluación. El producto final es
ahora un perfil de áreas claves, que pueden ser satisfechas parcial o completamente,
o no ser satisfechas.
•El nivel de madurez se establece como aquel en que se satisfacen todas las áreas
claves en forma continua.
FACTORES DE ESCALA (SFi)
Madurez del proceso (PMAT)
Nivel de madurez estimada, en relación
al modelo de madurez de software
CMM:
•0.00, nivel 5
Capability Maturity Model
•1.56, nivel 4
(CMM)
Optimizante
(5)
•3.12, nivel 3
•4.68, nivel 2
•6.24, nivel 1, superior
Administrado
(4)
•7.80, nivel 1, inferior.
Definido
(3)
Repetible
(2)
Inicial (1)
FACTORES DE ESCALA (SFi)
Madurez del proceso (PMAT) estimada, en relación al modelo de madurez de
Nivel Inicial (1) - áreas claves de proceso:
software CMM:
•ninguna
•Nivel Repetible (2) - áreas claves de proceso:
•Gestión de requisitos.
•Planificación de proyectos de software.
•Supervisión y seguimiento de proyectos de software.
•Gestión de subcontratos de software.
•Aseguramiento de calidad de software.
•Gestión de la configuración de software.
•Nivel Definido (3) - áreas claves de proceso:
•Foco en el proceso de la organización.
•Definición del proceso de la organización.
•Programa de entrenamiento.
•Administración de software integrado.
•Ingeniería del producto de software.
•Coordinación inter grupos.
•Revisión por pares.
•Nivel Administrado (4) - áreas claves de proceso:
•Administración cuantitativa del proceso.
•Administración de calidad de software.
•Nivel Optimizante (5) - áreas claves de proceso:
•Prevención de defectos.
•Administración de cambios tecnológicos.
•Administración de cambios en el proceso.
FACTORES DE ESCALA (SFi)
Madurez del proceso (PMAT) estimada, en relación al modelo de madurez de
software CMM:
Capability Maturity
Model (CMM)
Nivel
Característica
Desafíos claves
5
Optimizante
Mejoramiento realimentado
al proceso
Un proceso humano-intensivo
Mantiene la organización en nivel optimizante
4
Administrado
(Cualitativo)
Proceso medido
Cambio de tecnología
Análisis de procesos
Prevención de problemas
3
Definido
(Cualitativo)
Proceso definido e
institucionalizado
Métricas de procesos
Análisis de procesos
Planes cuantitativos de calidad
2
Repetible
(Intuitivo)
Proceso dependiente de
individuos
Entrenamiento, testeo
Prácticas técnicas y revisiones
Foco en el proceso, estándares y procesos
(Ad hoc/caótico)
Administración de proyectos y planificación
Administración de la configuración
Aseguramiento de la calidad de software
1
Inicial
Resultados
Productividad
y calidad
Riesgo
FACTOR DE ESFUERZO COMPUESTO POST ARQUITECTURA (EMi)
• Producto: RELY, DATA, DOCU, CPLX, RUSE
• Plataforma: TIME, STOR, PVOL
• Personal: ACAP, AEXP, PCAP, PEXP, LTEX, PCON
• Proyecto: TOOL, SITE, SCED
Nomenclatura Empleada
RELY (Seguridad Requerida)
DATA (Tamaño de Base de Datos)
DOCU (Documentación Adaptada al Ciclo de Vida)
CPLX (Complejidad), RUSE (Reutilización Requerida)
TIME (Tiempo de Ejecución Requerido)
STOR (Almacenamiento principal Requerido)
PVOL (Volatilidad de la Plataforma)
ACAP (Capacidad del Analista)
AEXP (Experiencia del Analista)
PCAP (Capacidad del programador)
PEXP (Experiencia en la Plataforma de Sistema Operativo)
LTEX (Experiencia en Lenguaje y Herramienta)
PCON (Continuidad del personal)
TOOL (Uso de Herramientas de SW)
SITE (Desarrollo Multitarea)
SCED (Esquema de Desarrollo Programado)
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DEL PRODUCTO (RELY)
Indicador
RELY
Valor
Asociado
MUY BAJO
BAJO
Efecto de falla
sin ninguna
consecuencia.
Efecto Peq. Fallas
Grandes
Riesgo
Recuperable Moderadas. Pérdidas
de Vidas
fácilmente.
Financieras Humanas
0.75
0.88
NOMINAL
1.00
ALTO
1.15
MUY
ALTO
1.39
EXT.
ALTO
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DEL PRODUCTO (DATA)
Tamaño de la Base de Datos. (DATA)
Se toma el tamaño de la base de datos en kbytes y se divide entre la cantidad
de instrucciones mf, en dependencia del valor obtenido se toma la
complejidad de este indicador. Es lógico que para poder obtener el tamaño
de la base de datos, deban estar definidos, los archivos, los campos, la
longitud de estos y estimadas la cantidad de artículos.
MUY BAJO
Indicador
DATA
Valor
Asociado
BAJO
<10
1.00
0.93
NOMINAL
>=10 Y
<100
1.00
ALTO
MUY
ALTO
EXT.
ALTO
>=100 Y >=1000
<1000
1.09
1.19
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DEL PRODUCTO (DOCU)
MUY BAJO
Indicador
DOCU
Muchas
Etapas sin
cobertura.
Valor
Asociado
0.89
BAJO
NOMINAL
Algunas
Etapas sin
Cobertura.
Adaptado
a las
etapas del
Ciclo de
Vida.
0.95
1.00
ALTO
MUY ALTO
EXT.
ALTO
Excesiva
Muy
Documentaci Excesiva
ón.
Docu.
1.06
1.13
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DEL PRODUCTO (CPLX)
NIVEL
OPERACIONES DE
CONTROL
OPERACIONES
MATEMÁTICAS
OPERACIONES DE
ENTRADA/SALIDA
OPERACIONES
DE MANEJO DE
DATOS
MUY BAJO
Códigos lineales: DO
IF-THEN-ELSE
Predicados simples, pocas
subrutinas.
Evaluación de expresiones
matemáticas simples:
C = A+B*(D-E).
Lecturas simples Escrituras con
formatos simples.
Arreglos simples en
memoria RAM.
BAJO
Subrutinas en secuencia
la mayor parte en
predicados simples.
Evaluación de expresiones
reiteradas. Raíces y
Potencias.
No se necesitan procesos
especiales de E/S. Sólo toma y
entrega de información. No hay
solapamiento.
Archivos simples sin
cambios en la
estructura de datos.
Programación
Estructurada (PE).
Mayormente subrutinas
simples. Tablas de
decisión.
Uso de subrutinas
matemáticas y estadísticas.
Operaciones con matrices y
vectores.
E/S comprende selecciones,
Múltiples archivos de
chequeos de estado y tratamiento E/S. Cambios simples
de errores.
en la estructura de
datos.
1.00
ALTO
Programa estructurado
con muchas subrutinas.
Considerables módulos.
Colas. Pilas.
Análisis numérico.
Interpolación multivariable.
Ecuaciones diferenciales.
Optimización del solapamiento de
Complejas
E/S. Operaciones de E/S a nivel reestructuraciones de
físico.
los datos. Subrutinas
activadas por el FD.
1.15
MUY ALTO
Código reentrante y
recursivo. Prioridad fija de
interrupción manual.
Ecuaciones con matrices
singulares. Ecuaciones
diferenciales parciales.
Análisis numérico difícil.
EXTRA ALTO
Programación múltiple.
Cambios dinámicos de
prioridad. Micro código.
Análisis numérico difícil y no
estructurado. Análisis muy
preciso. Métodos
estocásticos.
NOMINAL
Subrutinas para interrumpir el
servicio. Manejo de líneas de
comunicación.
Uso generalizado de
lo anterior. Archivo
comando de
procesamiento.
Optimización de
búsqueda.
Operaciones micro programables. Dirección de datos en
lenguaje natural.
Estructuras dinámicas
altamente enlazadas
Valor
Asociado
0.75
0.88
1.30
1.66
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DEL PRODUCTO (RUSE)
MUY
BAJO
Indicador
RUSE
Valor
Asociado
BAJO
Ninguna
1.00
0.91
NOMINAL
ALTO
MUY
ALTO
EXT.
ALTO
A través A través de A través de
A través de
del
Programas Líneas de Líneas Múltiples
Proyecto
Productos.
de Prod.
1.00
1.14
1.29
1.49
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DE PLATAFORMA (TIME)
Tiempo de Ejecución Requerido.(TIME)
Se debe estimar el tiempo necesario para la ejecución de este componente y
calcular el tiempo disponible de computación, se divide uno entre otro y se
multiplica por 100 para hallar el por ciento, con este número se entra a la Tabla para
hallar el nivel de complejidad de este indicador.
El tiempo de ejecución podrá determinarse mediante la siguiente fórmula:
TE = TED + TEA + TSD. (Horas/día)
MUY BAJO
BAJO
Indicador
TIME
Valor
Asociado
1.00
1.00
NOMINAL
ALTO
MUY
ALTO
EXT.
ALTO
50%
70%
85%
95%
1.00
1.11
1.31
1.67
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DE PLATAFORMA (TIME)
(Tiempo de Ejecución ) TE = TED + TEA + TSD. (Horas/día)
Donde: TED - Tiempo consumido en la entrada de los datos (hr/día)
TEA - Tiempo de ejecución y acceso a archivos (hr/día)
TSD - Tiempo consumido en la salida de los datos (hr/día)
TED =
TSD =
VDE
VDS
RE * 3600
RS * 3600
Donde: VDE - Volumen de datos de entrada (caracteres/día)
RE- Rapidez de la entrada de datos (cps) (0.5)
VDS - Volumen de datos de salida (caracteres/día)
RS - Rapidez de salida de los datos (cps)
VDE o VDS =S CIj (caracteres)
m
j=1
CIj = Aij Donde: Aij - Longitud del dato i en el flujo j. (caracteres)
i=1
CIj - Capacidad de información del flujo j (caracteres)
m - Cantidad de datos de un flujo
n - Cantidad de flujos de entrada o de salida.
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES
DE PLATAFORMA (TIME)
El tiempo de ejecución y acceso a archivo depende del tipo de proyecto
(gestión, inteligencia artificial, cálculo científico, etc.), del tipo de máquina,
del sistema operativo, del sistema de gestión de base de datos, etc.
Este tiempo puede calcularse, a través de programas realizados
anteriormente del mismo tipo o diseñados para ello propiamente, que
simulen la ejecución de las instrucciones y los accesos y a partir de ellos
calcular "k11" (tiempo promedio de ejecución en segundos por cada mil
instrucciones) y entonces se puede calcular TEA así:
TEA = k11 * mf (horas/día)
3600
El tiempo de ejecución y acceso a archivos, es despreciable frente a
(TED+TSD) en sistemas de gestión y es grande con respecto a (TED+TSD) en
procesos que contengan Métodos Económico-Matemáticos, Estadísticos, de
Simulación, etc.
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PLATAFORMA
(STOR) ALMACENAMIENTO PRINCIPAL REQUERIDO.
MUY BAJO
Indicador
STOR
Valor
Asociado
1.00
BAJO
1.00
NOMINAL
ALTO
MUY
ALTO
EXT.
ALTO
50%
70%
85%
95%
1.00
1.06
1.21
1.57
Se estima la cantidad de memoria que se necesita para la ejecución de este
componente, se divide entre la memoria disponible del computador y se
multiplica por 100 para hallar el porciento, con este número se entra a la Tabla
para hallar el nivel de complejidad de este indicador.
La cantidad de memoria principal ocupada se puede calcular mediante la fórmula:
MP = MOS + MOP + MOD
Donde: MOS - Memoria ocupada por el Software instalado.
MOP - Memoria ocupada por los programas.
MOD - Memoria ocupada por los datos.
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PLATAFORMA
VOLATILIDAD DE LA PLATAFORMA. (PVOL)
La velocidad de cambio de los medios de cómputo es la frecuencia de cambio del
hardware y el software necesario para las tareas.
* Si el proyecto a desarrollar es un sistema operativo es la velocidad con que
cambia el hardware de la computadora.
* Si el proyecto a desarrollar es un Sistema de Gestión de Base de Datos (SGBD)
es la velocidad con que cambia el hardware de la computadora y el sistema
operativo.
* Si el subsistema a desarrollar es una aplicación del Sistema de Base de Datos es
la velocidad del cambio del hardware de la computadora, el sistema operativo y el
sistema de base de datos.
De acuerdo con la frecuencia de cambio se entrará en la Tabla y se hallará el nivel
MUY
BAJO
NOMINAL
ALTO
MUY
EXT.
de este indicador.
BAJO
Indicador
PVOL
Valor
Asociado
ALTO
>=1 MES Y
<=12
MESES
1.00
0.87
>=6
>=2
>=2
MESES Y MESES Y SEM Y
<=2 SEM <=1 SEM
<= 2
DIAS
1.00
1.15
1.30
ALTO
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PERSONAL
CAPACIDAD DE LOS ANALISTAS. (ACAP)
La capacidad de los analistas se mide en términos de percentiles con respecto a la
población total de analistas de sistemas. Los atributos que deben ser considerados
son: habilidad para el análisis, eficiencia e integridad y habilidad para la
comunicación y cooperación. Este atributo es del conjunto de analistas como un
equipo más que una suma de ellos individualmente. De acuerdo al valor estimado
por Usted se entra en la Tabla para hallar el nivel de este indicador.
MUY BAJO
Indicador
ACAP
Valor
Asociado
BAJO
NOMINAL
ALTO
MUY
ALTO
EXT.
ALTO
15 %
35%
55%.
75%
90%
100%
1.50
1.22
1.00
0.83
0.67
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PERSONAL
CAPACIDAD DE LOS ANALISTAS. (PCAP)
De este indicador se puede decir lo mismo que de ACAP salvo que lo
principal es la habilidad para programar en vez de la habilidad para el
análisis. El percentil será con respecto a la población de programadores.
Con el valor del percentil se entra a la Tabla y se halla el nivel de este
indicador.
MUY BAJO
Indicador
PCAP
Valor
Asociado
BAJO
NOMINAL
ALTO
MUY
ALTO
EXT.
15 %
35%
55%.
75%
90%
ALTO
100%
1.37
1.16
1.00
0.87
0.74
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PERSONAL
CONTINUIDAD DEL PERSONAL. (PCON)
Es el porcentaje de Servicio del Personal compuesto tanto por analistas
como por Programadores con respecto a los años de Existencia de la
Institución.
MUY BAJO
Indicador
PCON
Valor
Asociado
BAJO
NOMINAL
ALTO
MUY
ALTO
EXT.
48%
24%
12%
6%
3%
ALTO
0%
1.24
1.10
1.00
0.92
0.84
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PERSONAL
EXPERIENCIA DE LOS ANALISTAS. (AEXP)
Es el tiempo de trabajo promedio que lleva el grupo de analistas en la
actividad de análisis dentro de la rama en que se esta haciendo el
sistema. Con este valor se entra en la Tabla para hallar el nivel de este
indicador.
MUY BAJO
Indicador
AEXP
Valor
Asociado
BAJO
2 meses
6 meses
1.22
1.10
NOMINAL
ALTO
MUY
ALTO
EXT.
ALTO
12 meses 36 meses 72 meses > 72
meses
1.00
0.89
0.81
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PERSONAL
EXPERIENCIA EN EL SISTEMA OPERATIVO. (PEXP)
Es el tiempo promedio de experiencia en el sistema operativo de todo el
grupo de analistas y programadores. Con este valor se entra en la Tabla
para hallar el nivel de este indicador.
MUY BAJO
Indicador
PEXP
Valor
Asociado
BAJO
2 meses
6 meses
1.25
1.12
NOMINAL
ALTO
12 meses 36 meses
1.00
0.88
MUY
ALTO
72
meses
0.81
EXT.
ALTO
> 72
meses
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DE PERSONAL
EXPERIENCIA EN EL LENGUAJE DE PROGRAMACIÓN. (LTEX)
Es el tiempo promedio de experiencia en el lenguaje de programación de
analistas y programadores. Con este valor se entra en la Tabla para hallar
el nivel del indicador.
MUY BAJO
Indicador
PEXP
Valor
Asociado
BAJO
NOMINAL
2 meses
6 meses
12 meses
1.22
1.10
1.00
ALTO
MUY
ALTO
EXT.
ALTO
36
72 meses > 72
meses
meses
0.91
0.84
1.00
MSc. Claudia Benavidez Rugama
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DEL PROYECTO
USO DE MODERNAS HERRAMIENTAS DE SOFTWARE. (TOOL)
Se considera el uso de:
Muy bajo: Ensamblador
Editor de enlaces básico
Monitor básico
Programas de auxilio para la eliminación de
errores de programación
Bajo:
Compilador lenguaje de alto nivel
Macroemsamblador
Editor de enlaces overlay
Monitor de lenguaje independiente
Editor de documentos en lote
Biblioteca básica de ayuda
Sistema Base de Datos Básico
Nominal: Sistema operativo tiempo real o compartido
Sistema de Dirección de Base de Datos (DBMS)
Biblioteca simple de programación
Editor de documentos interactivo
Editor de enlaces overlay extendido
Programa de auxilio para la eliminación de
errores interactivo.
Alto:
Sistema operativo de memoria virtual
Sistema de ayuda al diseño de Base de
Datos
Biblioteca de apoyo a la programación con
ayuda para el manejo de la configuración
Analizador de uso fijo
Analizador del flujo de programas y textos
Editor de textos básico
Muy Alto: Sistema de documentación integrado
Sistema de control de proyectos
Herramientas automatizadas de diseño
Sistema automático de verificación
Herramientas de propósito especifico
Simuladores de conjuntos de instrucciones
Formateador de display
Herramientas del proceso de comunicación
de control de entrada de datos, ayuda a la
conversión, etc.
INDICADOR
MUY BAJO
BAJO
NOMINAL
ALTO
MUY ALTO
Indicador
TOOL
Editar,
Codificar y
Corregir.
1.24
Ciclos y
Pequeña
Integración.
1.12
Integración
Moderna.
Bastante
Integración.
0.86
Cuantiosa
Integración.
Valor
Asociado
1.00
0.72
EXT.
ALTO
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DEL PROYECTO
DESARROLLO MULTITAREA (SITE)
INDICADOR
MUY BAJO
BAJO
NOMINAL
ALTO
MUY ALTO
Indicador
SITE
Teléfono,
Correo.
Teléfono,
Fax.
Banda
Corta,
Emails.
Banda
Ancha
Valor
Asociado
1.25
1.10
1.00
0.92
Banda
Ancha,
OcasionalMente
Vídeo_Conf
erencia.
0.84
EXT.
ALTO
Múltiples
formas,
Interactivo.
0.78
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DEL PROYECTO
ESQUEMA DE DESARROLLO PROGRAMADO. (SCED)
Según el por ciento del TDES nominal que se quiera acelerar el proyecto o
desacelerar así será el nivel de este indicador que se halla en la Tabla. La
aceleración del proyecto por encima del 75 % del tiempo de desarrollo nominal es
considerado imposible al igual que un alargamiento de más de un 60%.
INDICADO
R
Indicador
SCED
Valor
Asociado
MUY
BAJO
75% del
Nominal.
1.29
BAJO
ALTO
MUY ALTO
85%
NOMINA
L
100%
130%
160%
1.10
1.00
1.00
1.00
EXT.
ALTO
1.00
Descargar

Diapositiva 1