Transcript Muy Alto
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 Estación de Trabajo Impresora Cantidad 3 Descripción Procesador Intel Celeron 1.60GHz
Memoria 512 MB Monitor 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 interceptados.
y no ser
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 mayor demanda.
de las áreas de
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
PROCESO
Mercado Competitivo Organización (Solución de Negocio)
PERSONAS
Entorno de Desarrollo
TECNOLOGIA
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
–
Personas participantes
–
Errores durante el desarrollo Ciclo de Vida de un Proyecto
–
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 otras estimaciones.
fácilmente
• •
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
APA
AN
ALIS
DE IS Por lo tanto los proporcionan una Puntos de Función 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 Diseño Preliminar Diseño Detallado Código
•Buena comunicación con el usuario •Las
especificaciones completas deben ser
•Reducir
posteriores al mínimo las modificaciones en cuanto a los requerimientos y especificaciones
COMO SE DETERMINAN LOS PUNTOS DE FUNCION
Se deriva de una relación empírica de 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 CARACTERÍSTICAS DE DOMINIO DE DEFINICIÓN DE LAS
UN EJEMPLO GRÁFICO CARACTERÍSTICAS DE DOMINIO DE 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
M U L T I P L I C A D O R Puntos de Función Ajustados Es un multiplicador estandarizado de influencia cuyo intervalo es de 0,65 a 1,35 PFA
=
PF
x [ 0,65 + 0,01 x
S
F i
]
El total de los puntos de función sin ajustar (de acuerdo a las 5 características de dominio de la información) 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
F i
]
Resultado Gráfico de Puntos de Función
Dominio de Información PFA
349.6
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
Presentación Gráfica de la Estimación de las LDC MÉTRICAS ORIENTADAS AL TAMAÑO 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
• Esfuerzo (personas-meses) =
A x (Tamaño)
B
x
EMi
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*
S
SF
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)
) 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 •3.12, nivel 3 (CMM)
Optimizante (5)
•4.68, nivel 2 •6.24, nivel 1, superior •7.80, nivel 1, inferior.
Administrado (4) 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:
•ninguna •Gestión de requisitos.
software CMM:
•Nivel Repetible (2) - áreas claves de proceso: •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 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 3 Definido 2 Repetible 1 Inicial (Cualitativo) Proceso medido (Cualitativo) Proceso definido e institucionalizado (Intuitivo) Proceso dependiente de individuos (Ad hoc/ca ótico)
Cambio de tecnología
Análisis de procesos Prevención de problemas Métricas de procesos Análisis de procesos Planes cuantitativos de calidad Entrenamiento, testeo Prácticas técnicas y revisiones Foco en el proceso, estándares y procesos Administración de proyectos y planificación Administración de la configuración Aseguramiento de la calidad de software
Resultados
Productividad y calidad Riesgo
FACTOR DE ESFUERZO COMPUESTO POST ARQUITECTURA (EMi)
• • • •
Producto: Plataforma: Personal:
Proyecto
,
,
Nomenclatura Empleada
RELY (Seguridad Requerida) DATA DOCU (Tamaño de Base de Datos) (Documentación Adaptada al Ciclo de Vida) CPLX (Complejidad), RUSE TIME (Tiempo de (Reutilización Requerida) 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) MUY BAJO BAJO NOMINAL ALTO MUY ALTO Indicador RELY
Efecto de falla sin ninguna consecuencia.
Efecto Peq. Recuperable fácilmente.
Fallas Moderadas.
Grandes Pérdidas Financieras Riesgo de Vidas Humanas
EXT.
ALTO Valor Asociado 0.75
0.88
1.00
1.15
1.39
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 BAJO NOMINAL ALTO MUY ALTO EXT.
ALTO Indicador DATA Valor Asociado 1.00
<10
0.93
>=10 Y <100 >=100 Y <1000 >=1000
1.00
1.09
1.19
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DEL PRODUCTO (DOCU) MUY BAJO BAJO NOMINAL ALTO MUY ALTO EXT.
ALTO Indicador DOCU
Muchas Etapas sin cobertura.
Algunas Etapas sin Cobertura.
Adaptado a las etapas del Ciclo de Vida.
Excesiva Documentaci ón.
Muy Excesiva Docu.
Valor Asociado 0.89
0.95
1.00
1.06
1.13
1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DEL PRODUCTO (CPLX) NIVEL MUY BAJO BAJO NOMINAL ALTO OPERACIONES DE CONTROL
Códigos lineales: DO IF-THEN-ELSE Predicados simples, pocas subrutinas.
Subrutinas en secuencia la mayor parte en predicados simples.
OPERACIONES MATEMÁTICAS
Evaluación de expresiones matemáticas simples: C = A+B*(D-E).
Evaluación de expresiones reiteradas. Raíces y Potencias.
Programación Estructurada (PE). Mayormente subrutinas simples. Tablas de decisión.
Uso de subrutinas matemáticas y estadísticas. Operaciones con matrices y vectores.
Programa estructurado con muchas subrutinas. Considerables módulos. Colas. Pilas.
Análisis numérico. Interpolación multivariable. Ecuaciones diferenciales.
OPERACIONES DE ENTRADA/SALIDA
Lecturas simples Escrituras con formatos simples.
OPERACIONES DE MANEJO DE DATOS
Arreglos simples en memoria RAM.
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.
E/S comprende selecciones, Múltiples archivos de chequeos de estado y tratamiento E/S. Cambios simples de errores.
en la estructura de datos.
Optimización del solapamiento de E/S. Operaciones de E/S a nivel físico.
Complejas reestructuraciones de los datos. Subrutinas activadas por el FD.
MUY ALTO EXTRA ALTO
Código reentrante y recursivo. Prioridad fija de interrupción manual.
Programación múltiple. Cambios dinámicos de prioridad. Micro código.
Ecuaciones con matrices singulares. Ecuaciones diferenciales parciales. Análisis numérico difícil. Análisis numérico difícil y no estructurado. Análisis muy preciso. Métodos estocásticos.
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.00
1.15
1.30
1.66
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DEL PRODUCTO (RUSE) Indicador RUSE MUY BAJO BAJO NOMINAL ALTO MUY ALTO EXT.
ALTO
Ninguna A través del Proyecto A través de Programas A través de Líneas de Productos.
A través de Líneas Múltiples de Prod.
Valor Asociado 1.00
0.91
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 NOMINAL ALTO MUY ALTO EXT.
ALTO Indicador TIME
50% 70% 85%
95% Valor Asociado 1.00
1.00
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 RE * 3600 VDS 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 m CIj = CIj (caracteres) j=1 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 BAJO NOMINAL ALTO MUY ALTO EXT.
ALTO Indicador STOR Valor Asociado
1.00
1.00
50% 1.00
70% 1.06
85% 1.21
95% 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 de este indicador.
MUY BAJO BAJO NOMINAL ALTO MUY ALTO EXT.
ALTO Indicador PVOL Valor Asociado
1.00
>=1 MES Y <=12 MESES 0.87
>=6 MESES Y <=2 SEM >=2 MESES Y <=1 SEM 1.00
1.15
>=2 SEM Y <= 2 DIAS 1.30
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 BAJO NOMINAL ALTO Indicador ACAP Valor Asociado
15 % 1.50
35% 1.22
55%.
1.00
75% 0.83
MUY ALTO
90% 0.67
EXT.
ALTO
100% 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.
Indicador PCAP Valor Asociado MUY BAJO
15 % 1.37
BAJO
35% 1.16
NOMINAL
55%.
1.00
ALTO
75% 0.87
MUY ALTO
90% 0.74
EXT.
ALTO
100% 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.
Indicador PCON Valor Asociado MUY BAJO
48% 1.24
BAJO NOMINAL ALTO
24% 1.10
12% 1.00
6% 0.92
MUY ALTO
3% 0.84
EXT.
ALTO
0% 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.
Indicador AEXP Valor Asociado MUY BAJO
2 meses 1.22
BAJO
6 meses 1.10
NOMINAL
1.00
ALTO
0.89
MUY ALTO
12 meses 36 meses 72 meses 0.81
EXT.
ALTO
> 72 meses 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.
Indicador PEXP Valor Asociado MUY BAJO
2 meses 1.25
BAJO
6 meses 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.
Indicador PEXP Valor Asociado MUY BAJO
2 meses 1.22
BAJO
6 meses 1.10
NOMINAL
12 meses 1.00
ALTO MUY ALTO
36 meses 0.91
72 meses 0.84
EXT.
ALTO
> 72 meses 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.
INDICADOR MUY BAJO Indicador TOOL Valor Asociado
Editar, Codificar y Corregir.
1.24
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.
BAJO
Ciclos y Pequeña Integración.
1.12
NOMINAL
Integración Moderna.
1.00
ALTO MUY ALTO
Bastante Integra ción.
0.86
Cuantiosa Integración.
0.72
EXT.
ALTO 1.00
CRITERIOS DE SELECCIÓN DEL NIVEL PARA INDICADORES DEL PROYECTO DESARROLLO MULTITAREA (SITE) INDICADOR MUY BAJO Indicador SITE
Teléfono, Correo.
Valor Asociado 1.25
BAJO
Teléfono, Fax.
NOMINAL
Banda Corta, Emails.
1.10
1.00
ALTO MUY ALTO
Banda Ancha
0.92
Banda Ancha, Ocasional Mente 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
85%
1.10
NOMINA L
100%
ALTO MUY ALTO
130% 160%
1.00
1.00
1.00
EXT.
ALTO 1.00