reconocimiento de posibles riesgos de desarrollos de sistemas de

Transcripción

RECONOCIMIENTO DE POSIBLES RIESGOS DE DESARROLLOS DE
SISTEMAS DE INFORMACIÓN UTILIZANDO CATALOGACIÓN EN
METODOLOGÍA MÉTRICA V3
YAMILETH BALANTA GALEANO
Trabajo de Grado para Optar al Título de
Ingeniero de Sistemas
Asesor: JAVIER AVILA SALCEDO
Ingeniero de Sistemas
FUNDACIÓN UNIVERSITARIA KONRAD LORENZ
FACULTAD DE INGENIERIA
INGENIERIA DE SISTEMAS
BOGOTA
2008
RECONOCIMIENTO DE POSIBLES RIESGOS DE DESARROLLOS DE SISTEMAS DE
INFORMACIÓN UTILIZANDO CATALOGACIÓN EN METODOLOGÍA MÉTRICA V3
2008
Nota De Aceptación
________________________
________________________
Presidente Del Jurado
_______________________
Jurado
_______________________
Jurado
_______________________
Bogotá, 28 de noviembre de 2008
2
2008
AGRADECIMIENTOS
A mi mami y hermana que siempre han estado allí para mí y para impulsarme a
alcanzar mis sueños, por su amor y acompañamiento en los más difíciles caminos.
A Francisco por sus consejos, por calmarme cuando mas tensionada me
encontraba y por su amor todos los días.
Al Ing. Gustavo Herazo por su apoyo, por la idea, por las correcciones y la guía en
este proceso.
Al Ing. Javier Ávila asesor del proyecto por el acompañamiento.
A mis amigos, los del alma por la buena vibra y su interés en mi bienestar.
3
2008
RESUMEN
Cuando nos referimos a riegos hoy en día, debemos también referirnos a términos
de Calidad y Aseguramiento de la misma dentro de los procesos, debido a que
esta nos permite minimizar y administrar los primeros y, orientar cualquiera de
nuestras labores organizacionalmente hablando al éxito.
En actividades como el Desarrollo de Software es necesario enmarcarse en una
metodología, que permita obtener las bases suficientes para estructurar los
procesos transversales al desarrollo y es lo que la Métrica V3 sugiere.
El análisis y aplicación que sobre la Metodología Métrica V3 se realiza en este
documento, guía los pasos hacia la obtención de una base documental que
soporte el desarrollo y a futuro, la certificación de un sistema de información, con
la flexibilidad suficiente como para ser usado en Análisis Estructurado u
Orientación a Objetos.
4
2008
TABLA DE CONTENIDO
INTRODUCCIÓN .................................................................................................. 12
1. ASPECTOS DE LA INVESTIGACIÓN ........................................................... 14
1.1.
DESCRIPCION DEL PROBLEMA .................................................................................... 14
1.2.
JUSTIFICACION .............................................................................................................. 16
1.3.
DELIMITACION ................................................................................................................ 17
1.3.1.
Espacial .................................................................................................................... 17
1.3.3.
Conceptual ................................................................................................................ 17
1.3.4.
Metodológica ............................................................................................................. 18
1.4.
OBJETIVOS ..................................................................................................................... 19
1.4.1.
Objetivo General ....................................................................................................... 19
1.4.2.
Objetivos Específicos ................................................................................................ 19
2. MARCO TEORICO ......................................................................................... 20
2.1.
ANTECEDENTES ............................................................................................................. 20
2.1.1.
Históricos .................................................................................................................. 20
2.1.2.
Legales ..................................................................................................................... 22
2.1.3.
Investigativos ............................................................................................................ 27
2.2.
BASES TEORICAS .......................................................................................................... 28
2.2.1.
Modelo De Desarrollo Del Proyecto ........................................................................... 28
2.2.2.
Modelo Del Proceso De Desarrollo ............................................................................ 29
2.2.3.
Metodología De Calidad ............................................................................................ 33
2.2.4.
Principio de Aseguramiento de la Calidad .................................................................. 51
2.2.5.
Modelo Del Negocio .................................................................................................. 57
2.3.
TEORIAS GENERICAS BASADAS EN INGENIERIA ....................................................... 60
2.3.1.
Microsoft Visual Studio .NET ..................................................................................... 60
2.3.2.
Microsoft Windows XP ............................................................................................... 64
3. DISEÑO METODOLOGICO ........................................................................... 68
3.1.
TIPO DE INVESTIGACIÓN ............................................................................................... 68
3.2.
ANÁLISIS ......................................................................................................................... 68
5
3.2.1.
3.2.2.
2008
DESCRIPCIÓN DE LA SITUACIÓN ACTUAL ............................................................ 68
DIAGNOSTICO DE LA SITUACIÓN ACTUAL............................................................ 73
4. DEFINICION DE LA ESTRUCTURA DE LA MÉTRICA................................. 74
4.1.
ASI
4.1.1.
4.1.2.
4.1.3.
4.1.4.
4.1.5.
Análisis del Sistema de Información ....................................................................... 74
Definición Del Sistema .............................................................................................. 74
Establecimiento De Requisitos .................................................................................. 78
Análisis De Los Casos De Uso ................................................................................ 100
Definición De Interfaces De Usuario ........................................................................ 105
Menús del Sistema .................................................................................................. 106
5. PLAN DE ASEGURAMIENTO DE LA CALIDAD ........................................ 112
5.1.
DESCRIPCIÓN ............................................................................................................... 112
5.2.
OBJETIVOS DE CALIDAD ............................................................................................. 115
5.2.1.
Evitar en un 85% los defectos de funcionalidad y acoplamiento entre interfaces. ..... 115
5.2.2.
Mantener un NSU (Nivel de Satisfacción de Usuario) igual o mayor a un 85%,
soportado por los resultados obtenidos en las métricas del proyecto. ...................................... 115
5.3.
MÉTRICAS DEL PROYECTO......................................................................................... 116
5.4.
AUDITORÍAS ................................................................................................................. 118
6. PLAN DE SEGURIDAD ............................................................................... 119
6.1.
DESCRIPCIÓN ............................................................................................................... 119
6.2.
PROPOSITO Y ALCANCE ............................................................................................. 122
6.3.
ROLES Y RESPONSABILIDADES ................................................................................. 122
6.4.
DOCUMENTACIÓN DE RIESGOS ................................................................................. 123
6.5.
ACTIVIDADES DE GESTION DE RIESGOS................................................................... 123
6.6.
HERRAMIENTAS DE GESTIÓN DE RIESGOS .............................................................. 124
6.7.
CRITERIO DE CIERRE................................................................................................... 124
6.8.
CALENDARIO DE ACTIVIDADES DE GESTIÓN DE RIESGOS ..................................... 124
6.9.
RIESGOS DETECTADOS .............................................................................................. 125
6
2008
6.10.
PREGUNTAS DE ANÁLISIS DE RIESGOS ................................................................ 126
6.11.
ESCALA DE MEDICIÓN E IMPACTO......................................................................... 127
7. CONCLUSIONES ......................................................................................... 136
7.1.
CONCLUSIONES METODOLOGICAS FINALES ........................................................... 136
7.2.
CONCLUSIONES GENERALES DEL PROYECTO ........................................................ 137
BIBLIOGRAFIA .................................................................................................. 139
7
2008
INDICE DE ILUSTRACIONES
Ilustración 1 Modelo: Equipo de Trabajo MSF .................................................................. 32
Ilustración 2 Modelo: Proceso MSF .................................................................................. 33
Ilustración 3 Estructura Métrica V3................................................................................... 36
Ilustración 4 Fases Métrica V3 ......................................................................................... 37
Ilustración 5 Estructura EVS ............................................................................................ 40
Ilustración 6 Estructura ASI .............................................................................................. 42
Ilustración 7 Estructura DSI.............................................................................................. 45
Ilustración 8 Estructura CSI.............................................................................................. 47
Ilustración 9 Estructura IAS .............................................................................................. 49
Ilustración 10 Estrutura MSI ............................................................................................. 51
Ilustración 11 Características ISO-9126 ........................................................................... 52
Ilustración 12 Estructura BPM .......................................................................................... 58
Ilustración 13 Categorías de Análisis BPM....................................................................... 59
Ilustración 14 Modelo de Negocio .................................................................................... 75
Ilustración 15 Diagrama de CU Generales ....................................................................... 85
Ilustración 16 Diagrama de CU Crear Nueva Cotización .................................................. 91
Ilustración 17 Diagrama de CU Modificar Cotización........................................................ 92
Ilustración 18 Diagrama de CU Hacer una Cotización basada en una Existente .............. 93
Ilustración 19 Diagrama de Clases................................................................................. 100
Ilustración 20 Interfaz Árbol APIS................................................................................... 107
Ilustración 21 Interfaz FRM Creación ............................................................................. 108
Ilustración 22 Interfaz FRM de Creación2 ...................................................................... 109
8
2008
Ilustración 23 Interfaz Configuración .............................................................................. 110
Ilustración 24 Interfaz Configuración2 ............................................................................ 111
Ilustración 25 Tendencia * Pregunta .............................................................................. 134
Ilustración 26 Promedio Riesgos .................................................................................... 135
9
2008
INDICE DE TABLAS
Tabla 1 Preguntas ISO..................................................................................................... 52
Tabla 2 Versiones Microsoft Visual Studio .NET .............................................................. 60
Tabla 3 Campos de Cada Cotización ............................................................................... 84
Tabla 4 Campos de Cada Cliente Rapido ........................................................................ 84
Tabla 5 Atributos Cotización .......................................................................................... 101
Tabla 6 Operaciones Cotización .................................................................................... 101
Tabla 7 Atributos Producto ............................................................................................. 102
Tabla 8 Operaciones Producto ....................................................................................... 102
Tabla 9 Atributos Proceso .............................................................................................. 103
Tabla 10 Operaciones Proceso ...................................................................................... 103
Tabla 11 Atributos Componente ..................................................................................... 104
Tabla 12 Operaciones Componente............................................................................... 104
Tabla 13 Atributos Materia Prima ................................................................................... 105
Tabla 14 Operaciones Materia Prima ............................................................................. 105
Tabla 15 Métricas del Proyecto ...................................................................................... 116
Tabla 16 Roles y Responsabilidades ............................................................................. 122
Tabla 17 Documentación de Riesgos ............................................................................. 123
Tabla 18 Actividades de Gestión de Riesgos ................................................................. 123
Tabla 19 Calendario de Actividades Gestión de Riesgos ............................................... 124
Tabla 20 Preguntas de Análisis de Riesgos ................................................................... 126
Tabla 21 Escala de Medición e Impacto ......................................................................... 127
Tabla 22 Matriz de Probabilidad ..................................................................................... 128
10
2008
Tabla 23 Muestra de Encuesta ...................................................................................... 129
Tabla 24 Respuesta Pregunta 1..................................................................................... 130
Tabla 33 Respuesta Pregunta 10 ................................................................................... 133
11
2008
INTRODUCCIÓN
Normalmente en el ámbito del Desarrollo de Software a nivel universitario
contamos con la información sobre metodologías, formas de medir el software y
como asegurar la calidad del mismo, todo en una o dos materias que no se
consideran suficientes para abarcar los alcances. Al investigar dentro del mundo
de las métricas y calidad del software observamos que no solo con ver un curso al
respecto podemos asegurar que se ha comprendido completamente el fin de estos
conceptos, ni la dependencia o colaboración de uno y otro por ende; en
comunicación con los docentes de las aéreas dentro la FUKL, se identifico la
necesidad de un análisis investigativo y de aplicación que permita dimensionar
estos dos aspectos en el mercado real y dejar un aporte al respecto a la
comunidad académica.
Es entonces donde nace la idea de generar una base conceptual y de análisis que
permita hallar las falencias y fortalezas de un desarrollo, mediante la aplicación de
la Metodología Métrica V3 en su estructura estándar sobre un proyecto de
software real, independiente de la metodología de desarrollo y que se encuentren
en producción en este momento.
12
2008
Se espera de esta manera dejar en manos de los docentes, estudiantes y
demás actores de la formación académica, una herramienta que logre
direccionar y abrir un cambio hacia la estructuración de desarrollos de
software confiable, mantenible y de los cuales se obtengan productos de un
alto nivel de calidad.
Es de aclarar que el hecho de asegurar la calidad de los productos y
servicios ofrecidos por una organización no representa una ventaja
competitiva en este momento sino una, necesidad y una exigencia en el
mercado actual.
13
2008
1. ASPECTOS DE LA INVESTIGACIÓN
1.1.
DESCRIPCION DEL PROBLEMA
Durante el desarrollo de un proyecto se debe tener en cuenta además de
los requerimientos también los riegos que pueden presentarse antes,
durante o después del desarrollo, medir el trabajo a realizar y administrar
estos ítems, disminuyendo las posibilidades de incumplimiento de los
niveles de calidad que se estima alcanzar.
Para tales efectos es necesario tener una metodología de métricas
estructurada dentro un proceso de calidad que mitigue los posibles riesgos
y propenda por el mejoramiento continuo a partir de mediciones, por la
permanencia en el tiempo de los sistemas desarrollados y los niveles de
cumplimiento de los mismos. Se estima entonces el análisis de un método
que permita a cualquier tipo de metodología de desarrollo enmarcarse en la
aplicación de las buenas técnicas y ejercicios que la direccione en alcanzar
dichos fines.
Colonia Technologies es una empresa nueva colombiana conformada por
un grupo de profesionales en diferentes áreas del conocimiento, que
aportan su experiencia en consultoría para generar soluciones innovadoras
14
2008
con tecnología de última generación ayudando así al desarrollo y
crecimiento de las empresas por ende a nuestro país, trabajando siempre
en pro de las necesidades, expectativas, requerimientos y plena
satisfacción de nuestros socios de negocios (Clientes) aplicando siempre
excelentes estándares de calidad y servicio.1
Las empresas de desarrollo de software que están incursionando en el
mercado colombiano; tienen como derrotero el crecimiento organizacional
con énfasis en la calidad de los servicios que ofrecen, orientados
completamente a los clientes y a cubrir sus necesidades tecnológicas.
Colonia Technologies es una de estas empresas por lo cual a permitido que
se aplique la Métrica V3 en el desarrollo de uno de sus productos llamado
“APIS Gestión de Producción”, con el fin de estructurar el proceso de
aseguramiento de la calidad del software que desean extender a sus
desarrollos futuros.
Colonia Technologies no cuenta en este momento con un plan de
aseguramiento de la calidad y quieren iniciar su proceso de manera
temprana para acoger todos sus proyectos con este plan.
1
http://www.coloniatechnologies.com/empresa.htm
15
1.2.
2008
JUSTIFICACION
El hecho de implementar un plan de aseguramiento de la calidad,
enmarcado en una metodología que facilite estructurar cada proyecto
enfocándolo a un buen termino y mantenimiento hacen necesaria la
vinculación de la Métrica V3, por su estándar permitirá la aplicación
independiente de la metodología de desarrollo que decida adoptar la
organización.
La selección de la Métrica V3 se hace después de analizar las opciones
existentes en el mercado y observar que es esta (Métrica V3), la que a
nuestro juicio ha sido estructurada de tal manera que permite estandarizar
las metodologías de desarrollo de soluciones informáticas en un esquema
de calidad sin importar el producto y proceso a implementar.
Debido a que la aplicación de la Métrica se enmarca dentro del proyecto de
grado de Ingeniería de Sistemas y, la organización ve la necesidad de
estructurar su propio plan de aseguramiento de la calidad, esta facilita las
herramientas
y
documentación
organizacional
necesarias
para
la
investigación.
16
1.3.
2008
DELIMITACION
1.3.1. Espacial
El proyecto se desarrollará en la empresa Colonia Technologies,
ubicada en Calle 18 Sur # 18-29 Bogotá – Colombia, liderada por el Dr.
Mauricio Gómez y que cuenta con 1 año en el mercado de las
soluciones tecnológicas.
1.3.2. Cronológica
El tiempo de desarrollo del proyecto se refiere directamente al tiempo
estipulado por la Facultad de Ingeniería de la FUKL, referido a 4 meses
(julio a noviembre) para el desarrollo del proyecto de grado.
1.3.3. Conceptual
El alcance del proyecto se estipula en la entrega de la documentación
referente a los antecedentes investigativos, bases conceptuales, diseño
metodológico y las conclusiones referidos al análisis de la metodología
Métrica V3 en un sistema de desarrollo software en proceso.
17
2008
No se generará un aplicativo respecto del análisis realizado, el análisis y
culminación del proyecto no dependen de la finalización del software
que se encuentran en desarrollo.
No se compromete con la empresa desarrolladora que permite el
análisis sobre su software ningún ítem contractual que obligue a la
entrega de resultados.
1.3.4. Metodológica
Los Modelos Metodológicos vinculados en el desarrollo del proyecto
“Reconocimiento De Posibles Riesgos De Desarrollos De Sistemas De
Información Utilizando Catalogación En Metodología Métrica V3”,
representan una base conceptual y de análisis para la comunicada
académica aterrizados en un proyecto real de Desarrollo de Software.
18
1.4.
2008
OBJETIVOS
1.4.1. Objetivo General
Elaborar un estudio explicativo que permita reconocer riesgos potenciales
en productos software aplicando Metodología Métrica V3.
1.4.2. Objetivos Específicos
• Realizar un estudio del estado del arte.
• Realizar el modelamiento de la lógica de negocio de la empresa.
• Aplicar la metodología Métrica V3 a los sistemas de información pertinentes
19
2008
2. MARCO TEORICO
La contextualización teórica que se estructura a continuación tiene como
fin soportar el análisis realizado sobre aseguramiento de la calidad en
cuanto a desarrollo de software se refiere, es abundante la información que
al respecto se encuentra tanto por la visión organizacional de las empresas
de la rama como, por las exigencias gubernamentales que en el marco
legal colombiano se tienen sobre calidad.
Gracias y pese a estas exigencias se ha abierto un camino de diferencias y
de posicionamiento de las empresas de desarrollo de soluciones
informáticas dándole el lugar que durante años se había relegado
únicamente a la realización y no, a la sustentación y soporte continuado de
las herramientas.
2.1.
ANTECEDENTES
2.1.1. Históricos
“De acuerdo con la Norma ISO 9000:2000: Grado en el que un conjunto
de características inherentes cumple con los requisitos.”2
2
http://calidadiso.wiki.mailxmail.com/PaginaInicial
20
2008
La definición anterior se refiere al concepto de calidad para llegar a esto,
es necesario aclarar que debió recorrerse un amplio camino que no ha
terminado aún.
En sus primeros años, hasta la década de los 40’s se aplico únicamente
a la inspección y detección de errores. Empresas como Ford y
Laboratorios Bel fueron acuñando y dando las primeras bases a este
concepto que hoy va de la mano con la excelencia.
Ente los años 40’s y 80’s se manejo la calidad como un control
estadístico a los productos, en esa época los mercados eran poco
competitivos, la idea entonces era detectar los productos defectuosos y
evitar que llegaran al cliente, donde el control de calidad era un
problema a resolver.
Después de los 80’s los mercados se tornan más competitivos haciendo
necesaria la estructuración de una garantía de calidad que permitiera
planificar y medir el concepto que hasta el momento se refería mas a
corrección que a prevención, el concepto de CALIDAD. Se evidencio
que en todos los departamentos de la organización debía garantizarse
dicha calidad y es entonces cuando, diferentes entidades se preocupan
por estructurar un marco para este fin.
21
2008
Hoy día el concepto de calidad como lo conocemos se refiere a la
capacidad de una organización de identificar oportunidades de mejora,
resultado de una planificación, coordinación, formación, fijación de
objetivos acordes con la misión y visión organizacional. El concepto de
calidad enmarca no solo aspectos de productos específicos, sino
también a la sociedad en general.
Es justo aquí donde los actores de este proceso nos vinculamos con la
administración de defectos, planes de acción y demás herramientas que
permitan alcanzar en un alto nivel las expectativas del cliente. A este
siglo la prioridad número uno de cualquier organización es el cliente, y la
calidad se refiere directamente a la satisfacción de su idea de la misma.
2.1.2. Legales
CONVENIO DE SOFTWARE Y SERVICIOS ASOCIADOS (2000)
• FECHA DE LA SUSCRIPCION DEL CONVENIO
-
Convenio suscrito en la ciudad de San Andrés a los 25 días del mes
de agosto del año 2000
• ACTORES DE LA CADENA
22
2008
-
Ministerio de Industria, Comercio y Turismo, Agenda de Conectividad
-
Proexport, Bancoldex, Sena, Departamento Nacional de Planeación DNP
-
Federación Colombiana de la Industria del Software -FEDESOFT,
CATI
• VISIÓN DE LA CADENA
-
Mejorar la productividad y competitividad de la cadena de software y
servicios asociados con miras al fortalecimiento de la producción
nacional, a una mayor integración de los eslabones de la cadena y a
la consolidación ampliación de los mercados externos.
• PRINCIPALES LOGROS
-
Apoyo al sector para la elaboración de planes exportadores para 12
empresas del sector.
-
Apoyo a proyectos de generación masiva de recurso humano
especializado en TI en desarrollo de software.
-
Fomento a programas de certificación de calidad para el sector
del software.
-
Apoyo a la realización de ruedas de negocios para promocionar las
empresas de la India y de Colombia. Se contó con la participación de
23
2008
alrededor de 21 empresas colombianas que sostuvieron reuniones
con las 12 empresas Indias que visitaron el país.
-
Estructuración del “Proyecto Cumbre” por parte de Agenda de
Conectividad en el 2002 programa de formación de profesionales,
ingenieros de sistemas disciplinas afines, con el que se busca
fomentar y facilitar el acceso programas de posgrado.
-
El SENA conformó la mesa sectorial de Teleinformática.
-
El SENA estructuró el programa de informática y formación en áreas
virtuales a través de tres proyectos: modelo de gestión de aulas
informáticas, aula informática abierta y aula de informática itinerante.
Estos programas entrarán en operación en el tercer trimestre de
2002.
-
Fedesoft, realizó en convenio con Proexportel Estudio de Inteligencia
de Mercados para el hacer estudios de demanda para Perú,
Venezuela, EE.UU., Costa Rica, Ecuador y Guatemala.
• PROYECTOS ACTUALES
Como producto del proceso de reformulación del convenio se
identificaron los siguientes temas como prioritarios:
-
Legalidad del proceso de exportación de Software
-
Realización del evento SOFTIC
24
-
Ejecución del Modelo de Diagnóstico Exportador –Modiex-
-
Realización de proyectos de asociatividad.
-
Capacitación Administrativa, Comercial y Financiera.
2008
• LIMITACIONES
-
95% Empresarios del sector son Ingenieros de Sistemas, por lo tanto
carecen de formación: Administrativa, Comercial y Financiera.
-
Mercado Nacional
o Dudas de permanencia de las empresas
o Dudas sobre soporte técnico adecuado
o Dudas sobre actualización adecuada
-
Poca Inversión Extranjera
-
Falta de alianzas nacionales e internacionales
-
Bajo nivel de asociatividad.3
ADECUACIÓN DE LOS INFORMES DE GESTIÓN Y ESTADOS
FINANCIEROS A LA LEY 603 DE 2.000
• BENEFICIOS DEL SOFTWARE LEGAL
3
http://www.mincomercio.gov.co/eContent/Documentos/competitividad/convenios/
25
-
2008
Calidad asegurada. El software legal le asegura calidad en todos sus
aspectos, desde la manera que ha sido diseñado, hasta la
presentación del producto, respaldo y soporte técnico. Cuando utiliza
software ilegal corre el riesgo de introducir un virus que puede
extenderse en su computadora y la red corporativa.
-
Actualizaciones. Al registrarse como usuario con licencia de paquete
de software legal. Es posible que reciba notificaciones y a menudo
ofertas de descuentos.
-
Responsabilidad por el funcionamiento. Detrás de cada software
existen
miles
de
horas
de
trabajo
que
le
garantizan
un
funcionamiento adecuado y confiable. Cuando usa una copia ilegal
no puede estar seguro de que ésta funcione adecuadamente.
-
Documentación completa. El software ilegal no cuenta con los
instructivos de instalación y las guías para usuarios, materiales que
son de gran ayuda para potenciar el uso de las herramientas en el
trabajo diario. Además, cuenta con las respectivas facturas de
compraventa que le permiten evitar cualquier inconveniente.
-
Soporte de producto. Cuando adquiere software legal puede esperar
recibir apoyo a través de las líneas de soporte de los fabricantes y
26
2008
capacitación de alto nivel a través de la red de distribuidores. El
software ilegal no ofrece ninguno de estos beneficios.4
2.1.3. Investigativos
Algunos de los proyectos que en el análisis del estado del arte se han
encontrado en relación son:
• “Aplicación De Conceptos De Gestión De Proyectos Y Gestión
De Riesgo En El Desarrollo De Productos Nuevos En El
Campo De Tecnología De Información.”: Este proyecto
desarrollado en la en la Universidad de Puerto Rico, analiza
los riegos en el desarrollo de un producto software enmarcado
en el PMI y, en la definición y administración de riegos que
propone.
4
http://w3.bsa.org/colombia/
27
2.2.
2008
BASES TEORICAS
2.2.1. Modelo De Desarrollo Del Proyecto
El modelo sobre el cual se desarrollara el proyecto de grado es el
Método Científico, el cual cuenta con 4 fases:
•
Antecedentes Investigativos: Donde se define el problema a
tratar, se delimita y se estructuran los objetivos que se desea
alcanzar.
•
Bases Conceptuales: Define el marco teórico, estado del arte y
antecedentes investigativos referente al problema en cuestión.
•
Diseño Metodológico: Define la o las metodologías a usar en el
desarrollo
del
proyecto,
bien
sea
un
modelo
de
telecomunicaciones, desarrollo de módulos, calidad, software
libre, TICs, etc, y el resultado de la aplicación de la misma.
•
Conclusiones: Recomendaciones, información de pros y contras
en el desarrollo del proyecto.
28
2008
2.2.2. Modelo Del Proceso De Desarrollo
Para el proyecto objeto de estudio es MSF Microsoft Solutions
Framework, ubicado dentro de las metodologías Ágiles de Desarrollo de
Software.
MSF propone una secuencia generalizada para la construcción de
soluciones software. El proceso se define como flexible y de adaptable
al diseño y desarrollo de múltiples productos.
MSF consta de 5 fases distintas, combinando la claridad del modelo en
cascada y las ventajas de los puntos de transición del modelo en espiral.
•
Previsión
•
Planeación
•
Desarrollo
•
Estabilización
•
Implementación
Los componentes de MSF se definen como:
PRINCIPIOS
o Promover comunicaciones abiertas.
o Trabajar para una visión compartida.
o Fortalecer los miembros del equipo.
29
2008
o Establecer responsabilidades claras y compartidas.
o Focalizarse en agregar valor al negocio.
o Permanecer ágil, y esperar los cambios.
o Invertir en calidad
o Aprender de todas las experiencias.
o Partners con clientes.
o Siempre crear productos entregables.
DISCIPLINAS
o Gestión de Proyectos: Describe el rol de la gestión del
proyecto dentro del modelo de equipo de MSF, y como
permite mayor escalabilidad desde proyectos pequeños hasta
proyectos largos y de mayor complejidad, basándose sobre:
Entregas Cortas
Incorporar características nuevas sucesivamente
Identificar cambios ajustando el cronograma
o Control de Riesgos: Ayuda al equipo a identificar las
prioridades, tomar decisiones estratégicas y correctas, y
controlar las emergencias potenciales.
30
2008
o Control de Cambios: Diseñada para hacer proactivo al
equipo, los cambios deben considerarse riesgos inherentes y
como tal deben ser administrados.
MODELOS
o Equipo de Trabajo: Este modelo alienta la agilidad para hacer
frente a nuevos cambios involucrando a todo el equipo en las
decisiones fundamentales, asegurando una revisión desde
todas las perspectivas. Este modelo se escala dependiendo
del tamaño del proyecto y de equipo de personas disponibles.
a
b
f
c
e
d
31
2008
Ilustración 1 Modelo: Equipo de Trabajo MSF
o Proceso: El modelo de Proceso implementa una estrategia
iterativa en la construcción de productos del proyecto,
suministra una clara imagen del estado de estos en cada
etapa. Cada equipo puede identificar con mayor facilidad el
32
2008
impacto de cambios y administrarlos de manera efectiva.
Enfocándose a la adaptabilidad en lugar de a la predictibilidad.
Ilustración 2 Modelo: Proceso MSF
2.2.3. Metodología De Calidad
La metodología para estructurar el plan de aseguramiento de la calidad
es Métrica V3.
33
2008
Métrica V3 es una Metodología de Planificación, Desarrollo y
Mantenimiento de Sistemas de Información.
Puede ser utilizada libremente con la única restricción de citar la fuente
de su propiedad intelectual: el Ministerio de Administraciones Públicas
del Gobierno de España.
Esta metodología propia está basada en el modelo de procesos del ciclo
de vida de desarrollo ISO/IEC 12207 (Information Technology - Software
Life Cycle Processes) así como en la norma ISO/IEC 15504 SPICE
(Software Process Improvement And Assurance Standards Capability
Determination).
La aplicación de la Métrica pretende alcanzar los siguientes objetivos:
•
Proporcionar o definir Sistemas de Información que ayuden a
conseguir los fines de la Organización mediante la definición
de un marco estratégico para el desarrollo de los mismos.
•
Dotar a la Organización de productos software que satisfagan
las necesidades de los usuarios dando una mayor importancia
al análisis de requisitos.
34
•
2008
Mejorar la productividad de los departamentos de Sistemas y
Tecnologías de la Información y las Comunicaciones,
permitiendo una mayor capacidad de adaptación a los
cambios y teniendo en cuenta la reutilización en la medida de
lo posible.
•
Facilitar la comunicación y entendimiento entre los distintos
participantes en la producción de software a lo largo del ciclo
de vida del proyecto, teniendo en cuenta su papel y
responsabilidad, así como las necesidades de todos y cada
uno de ellos.
•
Facilitar la operación, mantenimiento y uso de los productos
software obtenido.
35
2008
Ilustración 3 Estructura Métrica V3
36
2008
INTERFAZ
A SI
DSI
Las fases de la Métrica V3 son:
Ilustración 4 Fases Métrica V3
Los procesos que se observan vinculados a las fases de la Métrica se
definen a continuación:
•
Planificación de Sistemas de Información (PSI)
•
Desarrollo de Sistemas de Información (DSI). Dividido en
cinco procesos:
-
Estudio de Viabilidad del Sistema (EVS)
-
Análisis del Sistema de Información (ASI)
37
2008
-
Diseño del Sistema de Información (DSI)
-
Construcción del Sistema de Información (CSI)
-
Implantación y aceptación del Sistema (IAS)
•
Mantenimiento de Sistemas de Información (MSI)
•
Proporciona también cuatro interfaces transversales a las tres
fases
anteriores
que
propenden
por
la
mejora
y
perfeccionamiento de los procesos:
-
Gestión de proyectos (GP)
-
Seguridad (SEG)
-
Aseguramiento de la Calidad (CAL)
-
Gestión de la Configuración (GC)
PSI:
En esta etapa se estudian las necesidades de información de los
procesos de de la organización, definiendo requisitos generales y
obteniendo modelos conceptuales de información y del sistema.
Al tener estos datos se evalúan las opciones existentes a nivel
tecnológico y se propone un entorno. Seguidamente se elabora un
cronograma para los proyectos y se mantiene actualizado el proceso.
38
2008
EVS:
En este proceso se inicia el estudio de los sistemas de información
definidos en cada alternativa de solución propuesta como:
•
Soluciones a la Medida
•
Soluciones basadas en productos del mercado (COTS)
•
Soluciones Mixtas
Este estudio se hace con el fin de identificar las condiciones en que
se van a desarrollar y/o a implantar, así como las características que
deben reunir en cuanto a operación, mantenibilidad y portabilidad,
para satisfacer las necesidades del cliente y los requisitos
especificados.
Para cada alternativa se analizan:
•
Impacto en la organización
•
Inversión
•
Riesgos Asociados
39
2008
Ilustración 5 Estructura EVS
ASI:
En este proceso se obtiene una especificación detallada del sistema
de información, a partir de la especificación resultante del proceso
EVS.
También se detallan los estándares y normas a cumplir, las
revisiones a llevar a cabo y sobre qué productos, así como los
procedimientos
y
mecanismos
necesarios
para
resolver
los
problemas que surjan, definiendo las acciones preventivas o
correctoras para su posterior corrección e identificando quiénes son
los responsables en cada caso.
40
2008
En el proceso ASI se realizan cesiones de trabajo con los usuarios
para extraer los requisitos que
harán parte del Catalogo de
Requisitos y el Modelo de Casos de Uso.
Los requisitos se dividen como:
•
Requisitos Funcionales
o Casos de Uso (obligatorios para OO)
•
Actores
Casos de Uso
Breve descripción de cada CU
Requisitos no Funcionales
o Restricciones de Entorno
o Niveles de Servicio del sistema
Rendimiento
Seguridad
Implantación
Disponibilidad, etc.
41
2008
Estructura ASI
ASI 2
ESTABLECIMIENTO DE
REQUISITOS
ASI 1
DEFINICIÓN
DEL SISTEMA
ASI 3
IDENTIFICACIÓN DE
SUBSITEMAS DE
ANÁLISIS
ASI 4
ANÁLISIS DE
CASOS DE USO
ASI 9
ANÁLISIS DE
CONSISTENCIA
ASI 5
ANÁLISIS DE
CLASES
ASI 10
ESPECIFICACIÓN
DE PLAN DE
PRUEBAS
ASI 6
ELABORACIÓN
DE MODELO DEL
DATOS
ASI 11
PRESENTACIÓN Y
APROBACIÓN DEL
ANÁLISIS DEL SI
Actividad Común
Actividad Solo Proceso OO
ASI 7
ELABORACIÓN
DE MODELO DE
PROCESOS
Actividad Solo Proceso
Estructurado
ASI 8
DEFINICIÓN DE
INTERFACES DE
USUARIO
Ilustración 6 Estructura ASI
Los productos resultantes de este proceso son:
•
Descripción general del entorno tecnológico
•
Glosario de términos
•
Catálogo de normas
•
Catálogo de requisitos
42
•
2008
Especificación de interfaz de usuario
En análisis estructurado:
•
Plan de migración y carga inicial de datos
•
Contexto del sistema
•
Matriz de procesos/localización geográfica
•
Descripción de interfaz con otros sistemas
•
Modelo de procesos
•
Modelo lógico de datos normalizado
En análisis orientado a objetos:
•
Modelo de negocio/modelo de dominio
•
Modelo de casos de uso
•
Especificación de casos de uso
•
Descripción de subsistemas de análisis
•
Descripción de interfaces entre subsistemas
•
Modelo de clases de análisis
•
Comportamiento de clases de análisis
•
Análisis de la realización de los casos de uso
43
2008
DSI:
Las revisiones del diseño se centran en confirmar que los requisitos
especificados en el proceso ASI, se han traducido en una
arquitectura conforme al entorno tecnológico seleccionado.
Asimismo, se revisan los requisitos que deben cumplir los distintos
niveles de pruebas (unitarias, de integración, del sistema, de
implantación y aceptación) especificados en el plan de pruebas, de
acuerdo a los criterios de revisión.
El proceso DSI define la arquitectura del sistema de información con:
•
Particiones Físicas
•
Subsistemas del Diseño
•
Particiones y ubicación de los subsistemas en ellas
•
Infraestructura tecnológica
44
2008
Estructura DSI
Actividad Común
DSI 1
DEFINICION DE LA
ARQUITECTURA DEL
SISTEMA
Actividad Solo Proceso OO
Actividad Solo Proceso
Estructurado
DSI 2
DISEÑO DE LA
ARQUITECTURA DE
SOPORTE
DSI 3
DISEÑO DE
CASOS DE USO
REALES
DSI 4
DISEÑO DE
CLASES
DSI 8
GENERACIÓN DE
ESPECIFICACIONES
DE CONSTRUCCIÓN
DSI 7
VERIFICACIÓN Y
ACEPTACIÓN DE LA
ARQUITECTURA DEL
SISTEMA
DSI 9
DISEÑO DE
MIGRACIÓN Y
CARGA INICIAL DE
DATOS
DSI 12
APROBACIÓ DEL
DISEÑO SISTEMA
DE INFORMACIÓN
DSI 10
ESPECIFICACIÓN
TÉCNICA DEL
PLAN DE PRUEBAS
DSI 5
DISEÑO DE LA
ARQUITECTURA
DE MODULOS
DEL SISTEMA
DSI 11
ESTABLECIMIENTO
DE REQUISITOS DE
IMPLANTACIÓN
DSI 6
DISEÑO FISICO DE
DATOS
Ilustración 7 Estructura DSI
Los productos resultantes de este proceso son:
•
Catálogo de requisitos (se completa)
•
Catálogo de excepciones
•
Catálogo de normas para el diseño y construcción
•
Diseño de la arquitectura del sistema
•
Entorno tecnológico del sistema
•
Procedimientos de operación y administración del sistema
45
•
Procedimientos de seguridad y control de acceso
•
Diseño detallado de los subsistemas de soporte
•
Modelo físico de datos optimizado
•
Asignación de esquemas físicos de datos a nodos
2008
En diseño estructurado:
•
Diseño de la arquitectura modular
•
Diseño de interfaz de usuario
En diseño orientado a objetos:
•
Diseño de la realización de los casos de uso
•
Modelo de clases de diseño
•
Comportamiento de clases de diseño
•
Diseño de interfaz de usuario
CSI:
En Este proceso se revisan los estándares de nomenclatura y
normativa aplicada en la generación del código de componentes, en
la evaluación de los resultados de las pruebas, en los manuales de
usuario y en el esquema de formación.
46
2008
Con respecto a las pruebas, se revisa que se han llevado a cabo las
pruebas unitarias, de integración y del sistema según los criterios de
selección de verificaciones y casos de prueba asociados.
En este proceso se realizan las pruebas unitarias, de integración y del
sistema, se construyen además los procedimientos de migración y carga
inicial de datos.
Estructura CSI
CSI 2
GENERACIÓN: CÓDIGO DE
LOS COMPONENTES Y
PROCEDIMIENTOS
CSI 1
PREPARACIÓN: ENTORNO
DE GENERACIÓN Y
CONSTRUCCIÓN
CSI 5
EJECUCIÓN DE LAS
PRUEBAS DEL SISTEMA
CSI 3
EJECUCIÓN DE LAS
PRUEBAS UNITARIAS
CSI 9
APROBACIÓN DEL
SISTEMA DE
INFORMACIÓN
CSI 4
EJECUCIÓN DE LAS
PRUEBAS DE
INTEGRACIÓN
CSI 6
ELABORACIÓN DE LOS
MANUALES DE USUARIO
CSI 7
DEFINICIÓN DE LA
FORMACIÓN DE
USUARIOS FINALES
CSI 8
CONSTRUCCIÓN
COMPONENTES Y
PROCEDIMIENTOS DE
MIGRACION Y CARGA INICIAL
DE DATOS
Ilustración 8 Estructura CSI
47
2008
IAS:
En este proceso se realiza la entrega y aceptación del sistema en su
totalidad, y se deben haber realizado las actividades necesarias para
dar inicio a la producción:
•
Preparar el entorno de explotación
•
Instalar los componentes
•
Activar los procedimientos manuales y automáticos
•
Realizar la migración o carga inicial de datos
•
Realizar la prueba de implantación
•
Realizar la prueba de aceptación
•
Preparar el mantenimiento
Normalmente el desarrollo y mantenimiento se realizan por grupos
diferentes.
48
2008
Ilustración 9 Estructura IAS
49
2008
MSI:
La idea de este proceso es obtener una nueva versión de un sistema
de información, a partir de las peticiones de mantenimiento de los
usuarios.
Los productos que se obtienen en el proceso son:
•
Catálogo de peticiones de cambio
•
Resultado del estudio de la petición
•
Propuesta de solución
•
Análisis de impacto de los cambios
•
Plan de acción para la modificación
•
Plan de pruebas de regresión
•
Evaluación del cambio
•
Evaluación del resultado de las pruebas de regresión
Los tipos de mantenimiento existentes son:
•
Correctivo: Cambios para corregir errores del producto
software
50
•
2008
Perfectivo (evolutivo): Cubre la expansión o cambio en las
necesidades del usuario.
•
Adaptativo: Modificaciones por cambios en el entorno en el
que el software opera.
•
Para
Preventivo: Mejorar la calidad interna de los sistemas
el
proceso
MSI
se
trabajan
únicamente
se trabajan
mantenimiento correctivo y evolutivo.
Ilustración 10 Estrutura MSI
2.2.4. Principio de Aseguramiento de la Calidad
ISO-9126
El estándar ISO-9126[7] establece que cualquier componente de la
calidad del software puede ser descrito en términos de una o más de
seis características básicas, las cuales son: funcionalidad, confiabilidad,
usabilidad, eficiencia, mantenibilidad y portabilidad; cada una de las
cuales se detalla a través de un conjunto de subcaracterísticas que
permiten profundizar en la evaluación de la calidad de productos de
51
2008
software. A continuación se muestra la pregunta central que atiende
cada una de estas características.
Tabla 1 Preguntas ISO
Características
Pregunta Central
Funcionalidad
¿Las funciones y propiedades satisfacen las
necesidades explícitas e implícitas; esto es,
el qué . . . ?
Confiabilidad
¿Puede mantener el nivel de rendimiento,
bajo ciertas condiciones y por cierto tiempo?
Usabilidad
¿El software es fácil de usar y de aprender?
Eficiencia
¿Es rápido y minimalista en cuanto al uso de
recursos?
Mantenibilidad
¿Es fácil de modificar y verificar?
Portabilidad
¿Es fácil de transferir de un ambiente a
otro?
A continuación de detallan las características que establece el estándar
ISO-9126.
Características ISO-9126
Ilustración 11 Características ISO-9126
52
2008
Funcionalidad:
En este grupo se tienen una serie de atributos que permiten calificar
si un producto de software maneja en forma adecuada el conjunto de
funciones que, satisfagan las necesidades para las cuales fue
diseñado. Para este propósito se establecen los siguientes atributos:
o Adecuación: Se enfoca a evaluar si el software cuenta con un
conjunto de funciones apropiadas para efectuar las tareas que
fueron especificadas en su definición.
o Exactitud: Este atributo permite evaluar si el software presenta
resultados o efectos acordes a las necesidades para las
cuales fue creado.
o Interoperabilidad: Permite evaluar la habilidad del software de
interactuar con otros sistemas previamente especificados.
o Conformidad: Evalúa si el software se adhiere a estándares,
convenciones o regulaciones en leyes y prescripciones
similares.
o Seguridad: Se refiere a la habilidad de prevenir el acceso no
autorizado, ya sea accidental o premeditado, a los programas
y datos.
53
2008
Confiabilidad:
Los atributos que se refieren a la capacidad del software de
mantener su nivel de ejecución bajo condiciones normales, esto en
un periodo de tiempo establecido. Las subcaracterísticas que el
estándar sugiere son:
o Nivel de Madurez: Permite medir la frecuencia o falla por
errores en el software.
o Tolerancia a Fallas: Se refiere a la habilidad de mantener un
nivel específico de funcionamiento en caso de fallas del
software o de cometer infracciones de su interfaz específica.
o Recuperación: Se refiere a la capacidad de restablecer el nivel
de operación y recobrar los datos que hayan sido afectados
directamente por una falla, así como al tiempo y esfuerzo
necesarios para lograrlo.
Usabilidad:
Son un conjunto de atributos que, permiten evaluar el esfuerzo
necesario que deberá invertir el usuario para utilizar el sistema.
54
2008
o Comprensibilidad: Se refiere al esfuerzo requerido por los
usuarios para reconocer la estructura lógica del sistema y los
conceptos relativos a la aplicación del software.
o Facilidad de Aprender. Establece atributos del software
relativos al esfuerzo que los usuarios deben hacer para
aprender a usar la aplicación.
o Operabilidad. Agrupa los conceptos que evalúan la operación
y el control del sistema.
Eficiencia:
Esta característica permite evaluar la relación entre el nivel de
funcionamiento del software y la cantidad de recursos usados. Los
aspectos a evaluar son:
o Comportamiento con respecto al tiempo: Atributos del
software relativos a la los tiempos de respuesta
y de
procesamiento de datos.
55
2008
Mantenibilidad:
Son los atributos que permiten medir el esfuerzo necesario para
realizar modificaciones al software, ya sea por la corrección de
errores o por el incremento de funcionalidad, vinculando los
siguientes factores:
o Capacidad
de
análisis:
El
esfuerzo
necesario
para
diagnosticar las deficiencias o causas de fallas, o para
identificar las partes que deberán ser modificadas.
o Capacidad de Modificación: Mide el esfuerzo necesario para
modificar aspectos del software, remover fallas o adaptar el
software para que funciones en un ambiente diferente.
o Estabilidad: Se evalúan los riesgos de defectos inesperados
resultado de las modificaciones realizadas al software.
o Facilidad de prueba: Es el esfuerzo necesario para validar el
software una vez que fue modificado.
Portabilidad:
Es la habilidad del software de ser transferido de una ambiente a
otro, y considera los siguientes aspectos:
56
2008
o Adaptabilidad: Evalúa la oportunidad para adaptar el software
a
diferentes
ambientes
sin
necesidad
de
aplicarle
modificaciones.
o Facilidad de instalación. Esfuerzo necesario para instalar el
software en un ambiente determinado.
o Conformidad: Permite evaluar si el software se adhiere a
estándares o convenciones relativas a portabilidad.
o Capacidad de reemplazo: Esfuerzo usado en sustituir el
software por otro producto con funciones similares.
2.2.5. Modelo Del Negocio
Para modelar el Negocio partiendo de que la metodología para el
desarrollo del proyecto es MSF, se decide hacer uso de BPM
(Business Process Management). Este proceso se apoya en un
modelo grafico (BPMN), se traduce en un lenguaje específico
(BPML) y tiene una herramienta software que soportan y sirven
de integración de las dos primeras (BPMS), podemos visualizarlo
de la siguiente manera:
57
2008
BPM
Ilustración 12 Estructura BPM
Las categorías de análisis de un sistema BPM se basan en una
lógica de procesos, hacia la cual se definen:
•
Quiénes?: Los usuarios que interactúan con los procesos
•
Qué Hacen?: Actividades sobre los procesos
•
Sobre qué Información?: Documentación que se tiene sobre
los procesos
58
2008
Categorías de Análisis BPM
Qué Hacen?
Quiénes?
Lógica De Procesos
Sobre qué Información?
Ilustración 13 Categorías de Análisis BPM
59
2.3.
2008
TEORIAS GENERICAS BASADAS EN INGENIERIA
2.3.1. Microsoft Visual Studio .NET
Microsoft Visual Studio es un entorno de desarrollo integrado
(IDE, por sus siglas en inglés) para sistemas Windows. Soporta
varios lenguajes de programación tales como Visual C++, Visual
C#, Visual J#, ASP.NET y Visual Basic .NET, aunque
actualmente se han desarrollado las extensiones necesarias para
muchos otros.
Visual Studio permite a los desarrolladores crear aplicaciones,
sitios y aplicaciones web, así como servicios web en cualquier
entorno que soporte la plataforma .NET (a partir de la versión net
2002). Así se pueden crear aplicaciones que se intercomuniquen
entre estaciones de trabajo, páginas web y dispositivos móviles.
Tabla 2 Versiones Microsoft Visual Studio .NET
Versiones
Microsoft Visual Studio 5
Microsoft Visual Studio .NET (2002)
Microsoft Visual Studio .NET 2003
60
•
2008
Visual Studio 2008
Visual Studio 2008 fue publicado (RTM) el 17 de Noviembre de
2007 en inglés, mientras que la versión en castellano no fue
publicada hasta el 2 de Febrero de 2008.
El nuevo framework (.Net 3.5) está diseñado para aprovechar las
ventajas que ofrece el nuevo sistema operativo "Windows Vista" a
través
de
sus
subsistemas
"Windows
Communication
Foundation" (WCF) y "Windows Presentation Foundation" (WPF).
El primero tiene como objetivo la construcción de aplicaciones
orientadas a servicios mientras que el último apunta a la creación
de interfaces de usuario más dinámicas que las conocidas hasta
el momento.
A las mejoras de desempeño, escalabilidad y seguridad con
respecto a la versión anterior, se agregan entre otras, las
siguientes novedades:
La mejora en las capacidades de Pruebas Unitarias
permiten ejecutarlas más rápido independientemente de si
61
2008
lo hacen en el entorno IDE o desde la línea de comandos.
Se incluye además un nuevo soporte para diagnosticar y
optimizar el sistema a través de las herramientas de
pruebas de Visual Studio. Con ellas se podrán ejecutar
perfiles durante las pruebas para que ejecuten cargas,
prueben procedimientos contra un sistema y registren su
comportamiento; y utilizar herramientas integradas para
depurar y optimizar.
Con Visual Studio Tools for Office (VSTO) integrado con
Visual Studio 2008 es posible desarrollar rápidamente
aplicaciones de alta calidad basadas en la interfaz de
usuario (UI) de Office que personalicen la experiencia del
usuario y mejoren su productividad en el uso de Word,
Excel, PowerPoint, Outlook, Visio, InfoPath y Project. Una
completa
compatibilidad
para
implementación
con
ClickOnce garantiza el entorno ideal para una fácil
instalación y mantenimiento de las soluciones Office.
Visual Studio 2008 permite incorporar características del
nuevo Windows Presentation Foundation sin dificultad
tanto en los formularios de Windows existentes como en
62
2008
los nuevos. Ahora es posible actualizar el estilo visual de
las aplicaciones al de Windows Vista debido a las mejoras
en Microsoft Foundation Class Library (MFC) y Visual C++.
Visual Studio 2008 permite mejorar la interoperabilidad
entre código nativo y código manejado por .NET. Esta
integración más profunda simplificará el trabajo de diseño
y codificación.
LINQ (Language Integrated Query) es un nuevo conjunto
de herramientas diseñado para reducir la complejidad del
acceso a Base de Datos, a través de extensiones para
C++ y Visual Basic así como para Microsoft .NET
Framework. Permite filtrar, enumerar, y crear proyecciones
de muchos tipos y colecciones de datos utilizando todos la
misma sintaxis, prescindiendo del uso de lenguajes
especializados como SQL o XPath.
Visual Studio 2008 ahora permite la creación de soluciones
multiplataforma
adaptadas
para
funcionar
con
las
diferentes versiones de .Net Framework: 2.0. (Incluido con
Visual Studio 2005), 3.0 (incluido en Windows Vista) y 3.5
(incluido con Visual Studio 2008).
63
.NET
3.5
incluye
biblioteca
ASP.NET
2008
AJAX
para
desarrollar aplicaciones web más eficientes, interactivas y
altamente personalizadas que funcionen para todos los
navegadores
más
populares
y
utilicen
las
últimas
tecnologías y herramientas Web, incluyendo Silverlight y
Popfly.5
2.3.2. Microsoft Windows XP
Windows XP (cuyo nombre en clave inicial fue Whistler) es una
línea de sistemas operativos desarrollado por Microsoft que
fueron hechos públicos el 25 de octubre de 2001. Se considera
que están en el mercado 400 millones de copias funcionando.
Las letras "XP" provienen de la palabra eXPerience ("experiencia"
en español).
Dispone
de
incluyendo
versiones
para
computadoras
varios
entornos
domésticas
o
de
informáticos,
negocios,
computadoras portátiles, las llamadas "Tablet PC" y media
center. Sucesor de Windows 2000 y Windows ME y antecesor de
Windows Vista; es el primer sistema operativo de Microsoft
5
http://es.wikipedia.org
64
2008
orientado al consumidor que se construye con un núcleo y
arquitectura de Windows NT y que se encuentra disponible en
versiones para PC de 32 y 64 bits.
Las ediciones más comunes son la Home destinada al hogar y la
Professional, que tiene características adicionales tales como la
posibilidad de unirse a un dominio, en vez de solo a grupos de
trabajo, y soporte para 2 procesadores (Home a partir del SP
para multicore). La edición Media Center es una versión de XP
Professional para equipos con características específicas: control
remoto y capacidades multimedia, tales como ver y grabar la TV,
reproducir vídeos, fotos o música; recibir HDTV y compartir datos
con una Xbox 360 mediante Online Spotlight. Windows XP Tablet
PC Edition se diseñó para funcionar con la plataforma Tablet PC.
Se lanzaron dos versiones de 64 bits: Windows XP edición 64 bits
para los procesadores Itanium y otra diseñada para procesadores
AMD64 y EM64T.
A diferencia de sus versiones anteriores presenta mejoras en la
estabilidad y de la eficacia. Tiene una Interfaz gráfica de usuario
(GUI) perceptiblemente reajustada, un cambio de Microsoft
promovido para un uso más fácil que en las versiones anteriores.
65
2008
Se introdujeron nuevas capacidades de gestión de software para
evitar el “DLL Hell” que plagó las viejas versiones. Es también la
primera versión de Windows que utiliza la activación del producto
para reducir la piratería del software, una restricción que no sentó
bien a algunos usuarios. Ha sido también criticado por las
vulnerabilidades de seguridad, integración de Internet Explorer, la
inclusión del reproductor Windows Media Player y aspectos de su
interfaz.6
Windows XP introdujo nuevas características, incluyendo:
Ambiente totalmente gráfico
Secuencias más rápidas de inicio y de hibernación.
Capacidad del sistema operativo de desconectar un
dispositivo externo, de instalar nuevas aplicaciones y
controladores sin necesidad de reiniciar.
Una
nueva
interfaz
de uso
más
fácil,
incluyendo
herramientas para el desarrollo de temas de escritorio.
Uso de varias cuentas, que permite un usuario guarde el
estado actual y aplicaciones abiertos en su escritorio y
permita que otro usuario abra una sesión sin perder esa
información.
6
http://es.wikipedia.org/wiki/Windows_XP
66
2008
ClearType, diseñado para mejorar legibilidad del texto
encendido en pantallas de cristal líquido (LCD) y monitores
similares.
Escritorio Remoto, que permite a los usuarios abrir una
sesión con una computadora que funciona con Windows
XP a través de una red o Internet, teniendo acceso a sus
usos, archivos, impresoras, y dispositivos;
Soporte para la mayoría de módems ADSL y conexiones
wireless, así como el establecimiento de una red FireWire.
•
Ediciones:
Windows XP Starter Edition
Windows XP Home Edition
Windows XP Professional Edition
Windows XP Corporate Edition
Windows XP Retail Edition
Windows XP OEM Edition
Windows XP Media Center Edition
Windows XP Tablet PC Edition
67
2008
3. DISEÑO METODOLOGICO
3.1.
TIPO DE INVESTIGACIÓN
La investigación a la cual se refiere el proyecto “Reconocimiento De
Posibles Riesgos De Desarrollos De Sistemas De Información
Utilizando Catalogación En Metodología Métrica V3”, es una
Investigación Descriptiva-Explicativa, teniendo en cuenta que este
tema no ha sido suficientemente trabajado a nivel académico en el
entorno Colombiano.
3.2.
ANÁLISIS
3.2.1. DESCRIPCIÓN DE LA SITUACIÓN ACTUAL
Es muy común encontrar en el mercado empresas con énfasis en
calidad y administración de riesgos, en todos los campos de acción
posibles. En este momento en el campo de desarrollo de soluciones
referentes
a
las
Tecnologías
de
Información
y
las
Telecomunicaciones (TICS), se encuentra y sobre todo es necesario
el aseguramiento de la calidad y la administración de riesgos
68
2008
potenciales, justamente en los mismos campos de acción donde en
antes simplemente se identificaban como herramientas y no como
activos transversales a todas las áreas de una organización.
Debido a este auge encontramos herramientas para el análisis de
riesgos como:
ENTERPRISE RISK ASSESSOR (ERA) Y RISK ADVISOR
- Empresa: (Methodware Software)
Permite implementar procesos de Administración Corporativa o
específica de Riesgos (Integral, Riesgo Operativo, Lavado de
Dinero, Proyectos, etc.), de forma “distribuida” en las unidades
del negocio o “centralizada” en áreas específicas. El ERA permite
la Auditoría integrada a la gestión del riesgo.7
ACTIVE RISK MANAGER
-
Empresa: (OverSeas)
Active Risk Manager es el sistema de software ERM más
ampliamente desplegado y el único verdaderamente amplio. Está
7
http://www.catalogodesoftware.com/producto.aspx?pid=57
69
2008
siendo usado por más de 25,000 usuarios en todo el mundo, en
más de 60 compañías en 5 continentes.
Originalmente desarrollado para tratar los requerimientos de
gerenciamiento de riesgos de grandes programas de defensa,
ahora gerencia los riesgos de varias de las organizaciones más
grandes del globo en todos los sectores. Para leer más acerca de
la historia de ARM, por favor haga clic aquí o en el link de
navegación a la izquierda.
ARM es un producto COTS+. Esto significa que hay una
aplicación genérica que está disponible a la base entera de
clientes, pero si un cliente requiere mejoras específicas para la
aplicación estamos felices por desarrollarlas como componentes
de trabajo no financiados, parcialmente financiados o totalmente
financiados por el cliente.
@RISK
-
Empresa: Palisade
@RISK realiza análisis de riesgo utilizando simulación de
Monte Carlo para mostrar una gran cantidad de escenarios
70
2008
posibles en su hoja Excel; también le dice qué tan factibles
son estos escenarios. Gracias a esto Usted puede evaluar
que riesgos tomar y cuáles evitar.8
EAR / PILAR Entorno de Análisis de Riesgos
-
Empresa: EAR
Las herramientas EAR soportan el análisis y la gestión de
riesgos
de
un
sistema
de
información
siguiendo
la
metodología Magerit,
Los activos están expuestos a amenazas que, cuando se
materializan, degradan el activo, produciendo un impacto. Si
estimamos la frecuencia con que se materializan las
amenazas, podemos deducir el riesgo al que está expuesto el
sistema. Degradación y frecuencia califican la vulnerabilidad
del sistema.
El gestor del sistema de información dispone de salvaguardas,
que o bien reducen la frecuencia de ocurrencia, o bien
reducen o limitan el impacto. Dependiendo del grado de
8
http://www.palisade-lta.com/risk/
71
2008
implantación de estas salvaguardas, el sistema pasa a una
nueva estimación de riesgo que se denomina riesgo residual.
PILAR dispone de una biblioteca estándar de propósito
general, y es capaz de realizar calificaciones de seguridad
respecto de normas ampliamente conocidas como son:
* ISO/IEC 27002:2005 - Código de buenas prácticas para la
Gestión de la Seguridad de la Información
* SP800-53:2006 - Recommended Security Controls for
Federal Information Systems
* Criterios de Seguridad, Normalización y Conservación del
Consejo Superior de Informática y para el Impulso de la
Administración Electrónica).9
Esto es solo un abrebocas de la inmensa cantidad de herramientas
que en el mercado se encuentran para el análisis y mitigación de
riesgos en cualquiera sea el área de estudio.
9
http://www.ar-tools.com/
72
2008
3.2.2. DIAGNOSTICO DE LA SITUACIÓN ACTUAL
Actualmente en Colonia Technologies no se tiene una estructura de
análisis de riesgo, métrica y aseguramiento de la calidad del software
que producen. Se han realizado entonces entrevistas con Alexander
Gómez Project Manager de Colonia Techologies, sobre la compañía
y sobre el producto APIS en desarrollo actualmente.
73
2008
4. DEFINICION DE LA ESTRUCTURA DE LA MÉTRICA
4.1.
ASI Análisis del Sistema de Información
Debido a que Colonia Technologies trabaja el proyecto APIS por
módulos y como tal ha sido contratado con el cliente, se definirán los
procesos de la Métrica V3 sobre le modulo principal de APIS que es
el Modulo de Cotizaciones.
4.1.1. Definición Del Sistema
Determinación Del Alcance del Sistema
El módulo de cotizaciones permitirá realizar el detalle de la cotización
de los trabajos que solicita el cliente, de tal forma que se pueda
generar un presupuesto de costos y un margen por cada tipo de
trabajo según lo que la empresa defina como utilidad, permitiendo
también generar una carta de cotización al cliente, que se podrá
guardar en formato PDF para ser enviada por mail.
74
2008
Modelo de Negocio:
Ilustración 14 Modelo de Negocio
75
2008
Identificación del Entorno Tecnológico
Entorno de Desarrollo
o Hardware:
Equipo de Computo
1 Gb Memoria
Procesador 2.0 o posterior
o Software:
Microsoft Visual Studio.NET 2008
Windows XP o posterior
Entorno del Cliente
o Hardware:
Equipo de Computo
1 Gb Memoria
Procesador 2.0 o posterior
o Software:
Microsoft Framework 3.5
Windows XP o posterior
76
2008
Identificación de los Usuarios Participantes y Finales
Perfil de Usuario: El usuario que interactúe directamente con
el módulo de de cotizaciones debe tener conocimientos
consolidados en el área de la industria gráfica, y un muy buen
conocimiento de la operación y los procesos de Intergráficas,
de la misma forma debe tener conocimiento acerca del
proceso total de cotización como del sistema completo, debe
contar con la capacidad de comprobar los resultados que
arroje el sistema con medios y/o métodos manuales, adicional
de la capacidad de tomar decisiones en la administración de
trabajos y procesos propios de Intergráficas como de sus
satélites.
Características de Usuario:
o Conocer acerca de la configuración del montaje de
páginas en los pliegos, desperdicios, pinzas, cintas de
color o comprobación, entre otras.
o Conocer a fondo los procesos y procedimientos de
producción de Intergráficas.
o Estar en capacidad de hacer cálculos con métodos e
instrumentos manuales o no automáticos de los
77
2008
desperdicios, costos, consumos y tiempos generados al
momento de correr y procesar la cotización.
o Estar en capacidad de decidir la mejor opción de
cotización que presenta el
procesos
o componentes
de
sistema y combinar
tal
forma
que
la
rentabilidad del producto esté en función de lo
esperado por Intergráficas.
o Estar en capacidad de recolectar toda la información
necesaria acerca del trabajo que se está cotizando.
4.1.2. Establecimiento De Requisitos
Obtención de Requisitos
FUNCIONALES:
En Las cotizaciones se manejará un margen de seguridad, del
cual no podrá bajar el valor de venta que fije el cotizador con
respecto al costo.
Todas las opciones que aparezcan en las pantallas para elegir
o digitar un código serán configuradas mediante maestros en
el módulo de parametrización.
78
2008
La cotización no se podrá imprimir hasta que no se hayan
diligenciado los datos comerciales.
Las versiones de la cotización se crearán una vez impreso el
documento.
Para cada cotización sólo se podrá aprobar una versión.
Al traer la plantilla de producto, se deben poder adicionar
procesos y materias primas que no se encuentren en ella sin
afectar su configuración.
El presupuesto de la cotización se generará de acuerdo a los
costos, tiempos y consumos configurados para cada proceso.
En la cotización se debe poder elegir el satélite con el que se
envía a realizar un trabajo, de tal forma que se pueda ingresar
el costo fijo o variable según sea el caso.
Se deben poder generar cotizaciones para varias cantidades
(definidas en rangos), de tal forma que arroje el presupuesto
79
2008
para cada cantidad y de igual forma la forma optima de
procesarlas.
Los procesos, materias primas y componentes que se traigan
a la cotización desde la plantilla de producto serán de
configuración obligatoria.
Cada vez que se cambie la cotización se generará una nueva
versión de ella.
Para la generación de los dibujos de montaje, el sistema debe
hacer el cálculo del lomo.
En la cotización se deberá traer como dato fijo (según la
parametrización general del sistema) el tamaño de las pinzas,
de la tira de color y de los datos de montaje.
Los tipos de plegado que se configuren al trabajo se definirán
como maestro y se configurarán por centro de producción.
Se debe poder configurar el transporte como un costo
adicional, que se ejecutará como un satélite.
80
2008
Al calcular los datos preliminares de la cotización el sistema
deberá generar una lista de las posibles formas de procesar el
trabajo, organizado de mejor a peor opción de acuerdo a los
costos y tiempos, mostrando el detalle de configuración de
cada una de las opciones generadas.
Los costos adicionales a la cotización se deben manejar como
satélites o materias primas adicionales a las que por defecto
tenga cada componente configurado.
La cotización debe tener una validez de tal forma que no se
permita la apertura de un pedido, si ha caducado la dicha
validez.
Todos los márgenes que se configuren por tipo de trabajo, por
producto, por administrativos, entre otros, se sumarán al costo
de presupuesto para generar el valor de venta sugerido.
La comisión del vendedor se sumará como un margen.
81
2008
Al terminar la cotización, el cotizador deben poder generar los
siguientes reportes de la versión de cotización que se
trabajará.
o Carta Cliente (contiene el detalle de los procesos y los
valores de venta) que se podrá enviar directamente por
correo electrónico.
o Informe a comercial (contiene el detalle de los procesos,
materias primas, satélites, el valor de venta, sin
tiempos ni costos)
o Presupuesto (contiene el detalle de los procesos con
tiempos y costos)
En la cotización se podrán manejar los estados según el flujo
de trabajo que quiera implementar Intergráficas.
Se podrán adicionar archivos a la cotización que queden como
evidencia.
Igualmente, se podrán agregar o manejar márgenes a
diligenciar o con valores por defecto para la cotización.
82
2008
De los márgenes mencionados anteriormente, pueden existir
algunos que el cotizador podrá modificar a la hora de cotizar.
El módulo de cotizaciones generará un tiempo (plano o en
secuencia) estimado de producción (en días) para el producto
que se está cotizando, basándose en el tiempo de trabajo
diario de cada centro de producción.
La modificación de precios finales de venta se debe hacer
para cada cantidad según la tabla de cantidades en la
cotización.
Los clientes rápidos creados en cotizaciones no se deben
integrar a ofimática.
Se deben poder crear cotizaciones basadas en cotizaciones
anteriores.
Se deben capturar los siguientes campos en cada cotización.
83
2008
Tabla 3 Campos de Cada Cotización
DATO
DETALLE
Cliente
Identificación del cliente.
Nombre
Nombre del producto.
Cantidad
Cantidad de ejemplares del producto.
Clase de producto Clase o tipo de producto a cotizar
Validez
Forma de Pago
Tiempo en días que tiene validez la cotización.
La forma de pago de la cotización (que viene por defecto del
cliente pero puede cambiarse en la cotización.
Campaña
Código de la campaña
Márgenes
Los márgenes configurados para capturarse por cotizaciones.
Se deben capturar los siguientes campos en cada cliente
rápido.
Tabla 4 Campos de Cada Cliente Rapido
DATO
NIT
Nombre
Teléfono
DETALLE
Identificación del cliente.
Nombre del cliente.
Teléfono del cliente
Teléfono alternativo
Mail
Dirección
Ciudad
Contacto
Otro teléfono del cliente
Correo electrónico del cliente
Dirección del cliente
Ciudad del cliente
Nombre de la persona contacto.
84
2008
NO FUNCIONALES
Diagrama de Casos de Uso Generales
Ilustración 15 Diagrama de CU Generales
Especificación de Casos de Uso
Especificación Caso de Uso: Crear Nueva Cotización
o Descripción: El usuario del sistema ingresa al
Modulo de Cotizaciones, digita la solicitud de
Preprensa, gestiona la cotización y guarda la
cotización.
85
2008
o Flujo de Eventos:
i. El usuario ingresa al modulo de cotizaciones.
ii. El sistema muestra las opciones de creación de
cotización.
iii. El usuario selecciona “Crear Nueva Cotización”.
iv. El usuario digita la solicitud de Preprensa.
v. El usuario se registra con perfil de Cotizador
vi. El usuario busca el cliente.
vii. El usuario elige el cliente
viii.
El
sistema permite buscar plantilla del
producto
ix. El usuario elige plantilla del producto.
x. El sistema solicita cantidades
xi. El usuario Ingresa cantidades
a cotizar (de
producto o paginas)
xii. El sistema define Preproducto
xiii.
El sistema corre el proceso de calculo
xiv.
El
usuario
consulta
opciones
y
configuraciones propuestas.
xv.
El sistema despliega opciones de montaje
xvi.
El usuario define montaje
86
2008
xvii.
El cliente solicita da click en “Guardar”
xviii.
El sistema genera un numero de cotización
xix.
El sistema Imprime Reporte.
o Flujos Alternativos:
En el punto v. Si el usuario se registra con perfil de
Preprensa se despliega la opción la crear solicitud
de Preprensa, y luego va al paso viii.
En el punto vi. Si el cliente no existe, el sistema
permite crear un usuario rápido.
En el punto viii. Si la plantilla del producto no existe,
se solicita la creación de la plantilla y se va al punto
ix.
o Precondiciones:
El usuario debe tener un login en el sistema.
o Postcondiciones:
La información de la cotización queda guardada en
la base de datos.
Especificación Caso de Uso: Modificar cotización
o Descripción: El usuario ingresa al modulo de
Cotizaciones y selecciona “Modificar”, el cliente
87
2008
selecciona la cotización y realiza los cambios
permitidos, luego es guardada la información.
o Flujo de Eventos:
i. El sistema busca cotización
ii. El usuario Modifica Datos Generales
iii. El sistema define Preproducto
iv. El usuario consulta opciones y configuraciones
propuestas.
v. El sistema despliega opciones de montaje
vi. El usuario define montaje
vii. El cliente solicita da click en “Guardar”
viii. El sistema guarda una versión de la cotización.
ix. El sistema Imprime Reporte.
En el punto ii. Si el usuario define modificar plantilla
entonces se va a - El sistema permite buscar
plantilla del producto El usuario elige plantilla del
producto y va al punto iii. Si la plantilla del producto
no existe se solicita la creación de la plantilla El
usuario elige plantilla del producto y va al punto iii.
o Precondiciones:
El usuario debe tener un login
88
2008
El usuario debe estar en el modulo de Cotizaciones.
o Postcodiciones:
La información del la cotización modificada es
grabada en el registro correspondiente.
Especificaciones Caso de Uso: Hacer una cotización
basada en una Existente
o Descripción: El cliente busca una cotización que ya
ha sido configurada con un Preproducto y lo
relaciona con un cliente.
o Flujo de Eventos:
i. El sistema busca cotización
ii. El sistema permite buscar un cliente
iii. El usuario elige un cliente
iv. El sistema define Preproducto
v. El sistema corre el proceso de calculo
vi. El usuario consulta opciones y configuraciones
propuestas.
vii. El sistema despliega opciones de montaje
viii.El usuario define montaje
ix. El cliente solicita da clic en “Guardar”
x. El sistema genera un numero de cotización
89
2008
xi. El sistema Imprime Reporte.
En el punto i. Si el usuario elige seleccionar perfil de
Preprensa va - El usuario digita la solicitud de
Preprensa y va al punto iv.
o Precondiciones:
El usuario debe tener un login en el sistema.
o Postcondiciones:
La información de la cotización queda guardada en
la base de datos.
90
2008
Análisis de Requisitos
Del Diagrama de Casos de Uso general obtenemos los siguientes
casos de uso especificados.
Crear Nueva Cotización
Definiendo
Componente
Definiendo Proceso
Definiendo
Materias Primas
Definiendo
Preproducto
Cotizador
Preprensa
1
Creando Cotización
1
Definiendo Datos
Comerciales
Asigna Número de
Cotización Nueva
Ilustración 16 Diagrama de CU Crear Nueva Cotización
91
2008
Modificar cotización
Ilustración 17 Diagrama de CU Modificar Cotización
92
2008
Hacer una cotización basada en una Existente
Definiendo
Componente
Definiendo Proceso
Definiendo
Materias Primas
Definiendo
Preproducto
Cotizador
Preprensa
1
Creando Cotización
Basada en Otra
1
Definiendo Datos
Comerciales
Asigna Número de
Cotización Nueva
Ilustración 18 Diagrama de CU Hacer una Cotización basada en una Existente
93
2008
Especificación Caso de Uso: Definiendo Preproducto
o Descripción: El usuario ingresa los datos del
producto, define los componentes y materias primas
del mismo, obteniendo finalmente un proceso
configurado.
o Flujo de Eventos:
i.
El usuario diligencia los datos del producto
ii.
El usuario Modifica Datos Generales
iii.
El
usuario
selecciona
el
componente
preconfigurado.
iv.
El sistema define el componente
v.
El usuario selecciona la materia prima
vi.
El sistema define la materia prima
vii.
El
usuario
selecciona
el
proceso
preconfigurado.
viii.
El sistema define el proceso
En
el
punto
i.
Si
no
hay
componentes
preconfigurados, el usuario busca componente y las
agrega, luego para al punto iv.
En el punto i. Si el componente existe pasa al punto
iv.
94
2008
En el punto v. Si no existe materia prima
preconfigurada, el usuario busca materias primas y
las agrega, luego pasa al punto vi.
En el punto v. Si no existe materia prima, el usuario
la crea y pasa al punto vi.
En
le
punto
vii.
Si
no
existe
un
proceso
preconfigurado, el usuario busca proceso y los
agrega, luego pasa al punto viii.
En el punto vii. Si no existe un proceso, el usuario lo
creo y para al punto viii.
o Precondiciones:
o Postcodiciones:
La información del Preproducto modificado es
95
2008
Especificación Caso de Uso: Definiendo Componente
componente
y
materias
primas
del
mismo,
obteniendo finalmente un componente configurado.
o Flujo de Eventos:
i.
El
usuario
diligencia
los
datos
del
componente
ii.
El usuario selecciona la materia prima
iii.
El sistema define la materia prima
iv.
El
usuario
selecciona
el
proceso
materias
primas
preconfigurado.
v.
El sistema define el proceso
En
el
punto
i.
Si
no
hay
configuradas, el usuario busca materias primas y las
agrega, luego pasa al punto iii.
En el punto i. Si la materia prima existe pasa al
punto iii.
En
le
punto
iv.
Si
no
existe
un
proceso
preconfigurado, el usuario busca proceso y los
agrega, luego pasa al punto vi.
96
2008
En el punto iv. Si no existe un proceso, el usuario lo
creo y para al punto vi.
o Precondiciones:
o Postcodiciones:
La información del componente modificado es
Especificación Caso de Uso: Definiendo Proceso
proceso y materias primas del mismo, obteniendo
finalmente un proceso configurado.
o Flujo de Eventos:
i. El usuario diligencia los datos del Proceso
ii. El usuario elige centro de producción
iii. El usuario selecciona la materia prima
preconfigurada
iv. El sistema define la materia prima
v. El
usuario
selecciona
el
proceso
preconfigurado.
vi. El sistema define el proceso
97
2008
En el punto i. El proceso debe ser ejecutado por un
satélite, entonces el sistema busca el satélite, y
luego va al punto iii.
En el punto i. Si el satélite no existe, el usuario
solicita creación del satélite y liego va al pinto iii.
o Precondiciones:
o Postcodiciones:
La información del proceso modificado es grabada
en el registro correspondiente.
Especificación Caso de Uso: Definiendo Materias Primas
o Descripción: El usuario ingresa los datos de las
materias primas del mismo, obteniendo finalmente la
configuración de las mismas
o Flujo de Eventos:
i. El sistema muestra subclase o código de la
materia prima.
ii. El usuario elige subclase o código de la materia
prima.
98
2008
En el punto i. Si la subclase no existe, se solicita y
crea nueva materia prima y pasa al punto ii.
o Precondiciones:
o Postcodiciones:
La información del la materia prima modificada es
Validación de Requisitos
En reunión con el Project Manager Alexander Gómez se
validaron los Casos de Uso obtenidos y se confirmo paso a paso
la certeza y aplicación de los mismos.
99
2008
4.1.3. Análisis De Los Casos De Uso
Identificación de Clases Asociadas a Casos de Uso
Diagrama De Clases
Cotizacion
-Id_Cotizacion : Integer
-Id_Cliente : Integer
-Cantidad_prod : Integer
-Cantidad_pag : Integer
+ObtieneDatosCotizacion() : String
+CorrerProcesoCalculo() : String
+BuscaCliente() : String
+CreaClienteRapido() : String
+EligeCliente() : String
+ConsultaOpciones() : String
+ConfiguraPropuesta() : String
+DefineMontaje() : String
+DefineDatosComerciales() : String
+BuscaPlantillaProduto() : String
+EligePlantillaProducto() : String
+GuardaCotizacion() : Boolean
Producto
-Fin1
1
-Fin2
*
-Id_Producto : Integer
-Nombre_Producto : String
+ObtieneDatosProducto() : String
+SeleccionaComponente() : String
+DefineComponente() : String
+BuscaComponente() : String
+SolicitaCrearComponente() : String
+SeleccionaMP() : String
+DefineMP() : String
+BuscaMP() : String
+SolicitaCrearMP() : String
+BuscaProceso() : String
+SeleccionaProceso() : String
+DefineProceso() : String
+SolicitaCrearProceso() : String
0..1
-Fin3
*
-Fin4
-Fin5
*
1
-Fin6
Proceso
-Id_Proceso : Integer
-Nombre_Proceso : String
+ObtieneDatosProceso() : String
+BuscaSatelite() : String
+SolicitaCrearSatelite() : String
+EligeCentroProduccion() : String
Componente
-Id_Componente : Integer
-Nombre_Componente : String
+ObtieneDatosComponente() : String
+BuscaMP() : String
+BuscaProceso() : String
+SolicitaCrearProceso() : String
Materia Prima
-Fin7 -Fin8
0..1
*
-Id_MP : Integer
-Nombre_MP : String
+ObtieneDatosMP() : Integer
+EligeMP() : Integer
Ilustración 19 Diagrama de Clases
100
2008
Descripción de Atributos y Operaciones
Cotización: Clase que representa el documento donde
inicia todo el flujo de trabajo de Apis, la cotización es el
documento mediante el cual se configura el detalle del
trabajo que el cliente quiere que se elabore y del cual se
generará un presupuesto de procesos, materias primas,
tiempos y costos que acarreará la elaboración de dicho
trabajo.
o Atributos
Tabla 5 Atributos Cotización
Atributo
Id_Cotizacion
Id_Cliente
Cantidad_prod
Cantidad_pag
Tipo
Integer
Integer
Integer
Integer
Descripción
Código de la Cotización
Código del Cliente
Numero de productos a realizad
Número de páginas a producir
o Operaciones
Tabla 6 Operaciones Cotización
Operación
ObtieneDatosCotizacion
CorrerProcesoCalculo
BuscaCliente
CreaClienteRapido
EligeCliente
ConsultaOpciones
ConfiguraPropuesta
Descripción
Permite capturar los datos de una nueva cotización
Calcula el total de la cotización
Permite buscar un cliente
Permite Crear un Cliente de forma rápida
Permite seleccionar un cliente encontrado
Permite consultar los opciones de cotización
Permite configurar una propuesta
101
DefineMontaje
DefineDatosComerciales
BuscaPlantillaProduto
EligePlantillaProducto
GuardaCotizacion
2008
Permite definir el montaje elegido
Permite definir datos comerciales
Permite buscar una plantilla de un producto
Permite elegir una plantilla encontrada
Permite guardar la configuración de una Cotización
Producto: Clase que se refiere al grupo de componentes y
procesos y Materias primas que se facturan al cliente.
o Atributos
Tabla 7 Atributos Producto
Atributo
Nombre_Producto : String
Nombre_Producto
Tipo
Integer
String
Descripción
Código Producto
Nombre del producto
o Operaciones
Tabla 8 Operaciones Producto
Operación
ObtieneDatosProducto
SeleccionaComponente
DefineComponente
BuscaComponente
SolicitaCrearComponente
SeleccionaMP
DefineMP
BuscaMP
SolicitaCrearMP
BuscaProceso
SeleccionaProceso
DefineProceso
SolicitaCrearProceso
Descripción
Permite capturar los datos de un producto
Permite seleccionar un componente
Permite definir un componente
Permite buscar un componente
Permite solicitar la creación de un nuevo componente
Permite Seleccionar materia prima
Permite definir la materia prima
Permite Buscar la materia prima
Permite solicitar la creación de un nueva materia prima
Permite buscar un proceso
Permite seleccionar un proceso
Permite definir un proceso
Permite solicitar la creación de un nuevo proceso
102
2008
Proceso: Clase que se refiere a cualquier actividad que se
ejecuta sobre un componente, una materia prima o sobre
el producto; los procesos pueden ser ejecutados por
Intergráficas (en un centro de producción) o por satélites.
o Atributos
Tabla 9 Atributos Proceso
Atributo
Id_Proceso
Nombre_Proceso
Tipo
Integer
String
Descripción
Código Proceso
Nombre del proceso
o Operaciones
Tabla 10 Operaciones Proceso
Operación
ObtieneDatosProceso
BuscaSatelite
SolicitaCrearSatelite
EligeCentroProduccion
SeleccionaMP
DefineMP
SeleccionaProceso
DefineProceso
Descripción
Permite capturar datos de un proceso
Permite buscar un satélite
Permite crear un nuevo satélite
Permite elegir un centro de producción
Permite seleccionar materia prima
Permite definir materia prima
Permite Seleccionar un proceso
103
2008
Componente: Se refiere a la configuración de la materia
prima y procesos del producto a realizar.
o Atributos
Tabla 11 Atributos Componente
Atributo
Tipo
Id_Componente
Integer
Nombre_Componente String
Descripción
Código Componente
Nombre del Componente
o Operaciones
Tabla 12 Operaciones Componente
Operación
ObtieneDatosComponente
SeleccionaMP
DefineMP
BuscaMP
SolicitaCrearMP
SeleccionaProceso
DefineProceso
BuscaProceso
SolicitaCrearProceso
Descripción
Permite capturar datos de un componente
Permite seleccionar Materia prima
Permite definir materia prima
Permite buscar materia prima
Permite solicitar la creación de una materia prima
Permite Seleccionar un proceso
Permite buscar un proceso
Permite solicitar creación de un nuevo proceso
104
2008
Materia Prima: Clase que se refiere a base de inventario
con el cual se va generar el producto.
o Atributos
Tabla 13 Atributos Materia Prima
Atributo
Id_MP
Nombre_MP
Tipo
Integer
String
Descripción
Código Materia Prima
Nombre Materia Prima
o Operaciones
Tabla 14 Operaciones Materia Prima
Operación
ObtieneDatosMP
SolicitaCrearMP
EligeMP
Descripción
Permite capturar datos de una materia prima
Permite solicitar creación de una nueva materia prima
Permite elegir una materia prima
4.1.4. Definición De Interfaces De Usuario
•
Principios Generales de la Interfaz
La interfaz de APIS será dinámica, gracias a las facilidades que
Microsoft Visual Studio.NET 2008 presenta para este fin.
La interfaz referente a la Cotización tiene un menú que permitira:
Crear nuevas cotizaciones
Modificar cotizaciones
Crear cotizaciones basadas en otra ya existente
105
2008
Configurar materias primas, procesos, componentes y
productos preconfigurados
4.1.5. Menús del Sistema
El siguiente grafico muestra una aproximación de como se
desplegará el árbol de menú del sistema para cada función.
Estas interfaces se generalizan para los Casos de uso tratados en el
modulo de cotizaciones.
106
2008
Ilustración 20 Interfaz Árbol APIS
107
2008
A continuación se representan los formularios de creación de componentes
del sistema.
Ilustración 21 Interfaz FRM Creación
108
2008
Ilustración 22 Interfaz FRM de Creación2
109
2008
En el grafico siguiente se tiene la presentación genérica para la
configuración de producto, cotizaciones y otros componentes del
sistema.
Ilustración 23 Interfaz Configuración
110
2008
Ilustración 24 Interfaz Configuración2
111
2008
5. PLAN DE ASEGURAMIENTO DE LA CALIDAD
Este plan describe el cómo se asegurará la calidad del producto software a
desarrollar, en el marco de la Métrica V3.
5.1.
DESCRIPCIÓN
El objetivo de la interfaz de Aseguramiento de la Calidad de
MÉTRICA Versión 3 es proporcionar un marco común de referencia
para la definición y puesta en marcha de planes específicos de
aseguramiento de calidad aplicables a proyectos concretos. Si en
la organización ya existe un sistema de calidad, dichos planes
deberán ser coherentes con el mismo, completándolo en los
aspectos no contemplados relativos a normas particulares del
cliente, usuario o sistema concreto.
La calidad se define como “grado en que un conjunto de
características
inherentes
cumple
con
unos
requisitos”
[ISO
9000:2000]. El Aseguramiento de la Calidad pretende dar confianza
en que el producto reúne las características necesarias para
satisfacer todos los requisitos del Sistema de Información.
112
2008
Por tanto, para asegurar la calidad de los productos resultantes el
equipo de calidad deberá realizar un conjunto de actividades que
servirán para:
• Reducir, eliminar y lo más importante, prevenir las deficiencias
de calidad de los productos a obtener.
• Alcanzar una razonable confianza en que las prestaciones y
servicios esperados por el cliente o el usuario queden
satisfechas.
Para conseguir estos objetivos, es necesario desarrollar un plan de
aseguramiento de calidad específico que se aplicará durante la
planificación del proyecto de acuerdo a la estrategia de desarrollo
adoptada en la gestión del proyecto. En el plan de aseguramiento de
calidad se reflejan las actividades de calidad a realizar (normales o
extraordinarias), los estándares a aplicar, los productos a revisar, los
procedimientos a seguir en la obtención de los distintos productos
durante el desarrollo en MÉTRICA Versión 3 y la normativa para
informar de los defectos detectados a sus responsables y realizar el
seguimiento de los mismos hasta su corrección.
113
2008
El grupo de aseguramiento de calidad participa en la revisión de los
productos seleccionados para determinar si son conformes o no a los
procedimientos, normas o criterios especificados, siendo totalmente
independiente del equipo de desarrollo. Las actividades a realizar por
el grupo de aseguramiento de calidad vienen gobernadas por
el plan. Sus funciones están dirigidas a:
• Identificar las posibles desviaciones en los estándares
aplicados, así como en los requisitos y procedimientos
especificados.
• Comprobar que se han llevado a cabo las medidas preventivas
o correctoras necesarias.
Las revisiones son una de las actividades más importantes del
aseguramiento de la calidad, debido a que permiten eliminar
defectos lo más pronto posible, cuando son menos costosos de
corregir. Además existen procedimientos extraordinarios, como las
auditorías, aplicables en desarrollos singulares y en el transcurso de
las cuales se revisarán tanto las actividades de desarrollo como las
propias de aseguramiento de calidad. La detección anticipada de
114
2008
errores evita el que se propaguen a los restantes procesos de
desarrollo, reduciendo substancialmente el esfuerzo invertido en los
mismos.
En
este
sentido
es
importante
destacar
que
el
establecimiento del plan de aseguramiento de calidad comienza en
el Estudio de Viabilidad del Sistema y se aplica a lo largo de todo el
desarrollo, en los procesos de Análisis, Diseño, Construcción,
Implantación
y
Aceptación
del
Sistema
y
en
su
posterior
Mantenimiento.
5.2.
OBJETIVOS DE CALIDAD
Los objetivos de calidad seleccionados para APIS son:
5.2.1. Evitar en un 85% los defectos de funcionalidad y acoplamiento entre
interfaces.
5.2.2. Mantener un NSU (Nivel de Satisfacción de Usuario) igual o mayor a un
85%, soportado por los resultados obtenidos en las métricas del
proyecto.
115
5.3.
2008
MÉTRICAS DEL PROYECTO
Las métricas serán colectadas por módulos según se contrato con el
cliente para el producto APIS.
Las Métricas que serán tomadas son:
Tabla 15 Métricas del Proyecto
MÉTRICA
TOMADA
UBICACIÓN DE LA
INFORMACIÓN
NSU
NO
Aprobación del cliente
sobre la calidad y
procesos del modulo
Datos de Calidad
Datos de Calidad de
Pruebas
NO
Registro de Métricas
NO
Defectos Posteriores
a la entrega (DELTA) NO
Defectos posteriores
a la entrega (Total)
NO
Defectos detectados
por el cliente (Delta) NO
COMENTARIOS
El nivel de
satisfacción de
usuario se obtiene
mediante una
encuesta realizada al
entregar c/modulo
Los defectos
producidos durante el
desarrollo serán
controlados durante la
fase de
mantenimiento que
será administrada
como un proyecto
independiente.
Los defectos
producidos durante el
desarrollo serán
controlados durante la
fase de
mantenimiento que
será administrada
116
2008
como un proyecto
independiente.
Defectos detectados
por el cliente (Total)
Total de errores y
defectos conocidos
en el código al
momento de
entregar el producto
Tiempo calendario y
productividad para
mejoras del producto
Tiempo calendario y
productividad para
un producto nuevo
Adecuación de la
estimación de
esfuerzo
Adecuación de la
estimación de
calendario
Adecuación de la
estimación de
tamaño del producto
NO
NO
NO
NO
NO
NO
NO
Tamaño del producto
del proyecto (Total)
NO
Tamaño del producto
del proyecto (Delta) NO
Productividad
Cantidad de código
reutilizado
Cantidad de
requerimientos de
cambio
NO
NO
NO
El producto debe ser
entregado libre de
errores conocidos.
El proyecto implica el
desarrollo de un
producto nuevo.
No se implementarán
requerimientos de
cambio para el
prototipo.
117
Cantidad de
personas integrantes
del equipo de
proyecto
SI
Inspecciones y datos
de revisiones
NO
Costos
SI
Gestión de riesgos
NO
Plan de Riesgos
5.4.
2008
Los costos son
controlados por el
área de finanzas.
AUDITORÍAS
El grupo encargado de Calidad y Procesos será el que se encargue
del análisis, gestión y seguimiento que permite asegurar el
rendimiento, efectividad y cumplimiento de los planes que sean
estructurados.
Se debe manejar una auditoria desde este departamento tanto a
nivel funcional como de configuración del los productos software,
todo enmarcado en un cronograma de auditorías.
118
2008
6. PLAN DE SEGURIDAD
Este plan contiene la información de la forma como se Administran los riesgos
para el proyecto APIS.
6.1.
DESCRIPCIÓN
El objetivo de la interfaz de seguridad de MÉTRICA Versión 3 es
incorporar en los sistemas de información mecanismos de seguridad
adicionales a los que se proponen en la propia metodología,
asegurando el desarrollo de cualquier tipo de sistema a lo largo de
los procesos que se realicen para su obtención.
La seguridad del sistema de información ya se considera en
MÉTRICA Versión 3 como requisito funcional (ASI 2.1), es decir
previamente al desarrollo del mismo. La interfaz de Seguridad hace
posible incorporar durante la fase de desarrollo las funciones y
mecanismos que refuerzan la seguridad del nuevo sistema y del
propio proceso de desarrollo, asegurando su consistencia y
seguridad.
119
2008
El análisis de los riesgos constituye una pieza fundamental en el
diseño y desarrollo de sistemas de información seguros. Si bien los
riesgos que afectan a un sistema de información son de distinta
índole: naturales (inundaciones, incendios, etc.) o lógicos (fallos
propios, ataques externos, virus, etc.) son estos últimos los
contemplados en la interfaz de Seguridad de MÉTRICA Versión 3.
De lo anterior se desprende que existen dentro de la interfaz dos
tipos de actividades diferenciadas:
• Actividades relacionadas con la seguridad intrínseca del
sistema de información (representadas en la parte inferior del
gráfico).
• Actividades que velan por la seguridad del propio proceso de
desarrollo del sistema de información (representadas en la
parte superior del gráfico).
Si en la organización ya existe un plan de seguridad o una
metodología de análisis y gestión de riesgos como por ejemplo
MAGERIT, para cada sistema de información deberán analizarse las
necesidades de seguridad del sistema respecto al método vigente, y
120
2008
determinar las diferencias si las hubiera, así como aquellas
necesidades
concretas
que
no
se
encuentren
recogidas,
estableciendo así el plan de seguridad del sistema de información. Si
no existe un plan de seguridad en la organización habrá que
desarrollarlo desde el principio. El plan recogerá además las
medidas de seguridad, activas o preventivas y reactivas, en
respuesta a situaciones en que se produce un fallo reduciendo su
efecto, relacionadas con la seguridad del sistema de información y
del proceso de desarrollo.
Las valoraciones sobre la seguridad deben ser realizadas en función
de
las
características
del
sistema:
complejidad,
tamaño,
incertidumbre, participantes, etc. Por los responsables de la
seguridad del sistema de información, quienes se apoyarán para sus
decisiones en su conocimiento y experiencia en la materia sin perder
de vista además que, al ser finitos los recursos, no pueden
asegurarse todos los aspectos del desarrollo de los sistemas de
información, por lo que habrá que aceptar un determinado nivel de
riesgo concentrándose en los aspectos más comprometidos o
amenazados, que serán diferentes según las circunstancias.
121
6.2.
2008
PROPOSITO Y ALCANCE
A continuación se consigna el proceso a seguir para identificar,
valorar, controlar y monitorear los riesgos potenciales en el ciclo de
vida del proyecto.
6.3.
ROLES Y RESPONSABILIDADES
Tabla 16 Roles y Responsabilidades
ROL
RESPONSABILIDAD
Project Manager
Control de la ejecución del plan de riesgos y revisión
de estado durante las reuniones periódicas de
control de avance.
Gestor de Riesgos
* Coordinar las actividades de identificación y
análisis de riesgos
* Mantenimiento de la lista de riesgos
* Notificar a la gerencia de los nuevos riesgos
identificados y reporte del estado de resolución de
un riesgo.
Responsable de
Riesgo
El gestor de riesgos asigna un respopnsable por
c/riesgo identificado, este responsable se encarga
de:
* Valorar la exposición al riesgo
* Reportar el estado de solución de un riesgo al
gestor de riesgos
* Implementar planes de acción para mitigar el riesgo
122
6.4.
2008
DOCUMENTACIÓN DE RIESGOS
Tabla 17 Documentación de Riesgos
DOCUMENTO
Lista de Riesgos
DESCRIPCIÓN
Contiene los factores de riesgos identificados y manejados
para el proyecto.
Contiene información para cada uno de los riesgos del
proyecto:
* Identificador
* Fecha de identificación
* Descripción
* Impacto
* Probabilidad (0-1)
* Impacto (1-100)
* Exposición
* Plan de mitigación y contingencia
* Responsable de riesgo
* Fecha de cierre planificado
Datos de Riesgos * Estado
6.5.
ACTIVIDADES DE GESTION DE RIESGOS
Tabla 18 Actividades de Gestión de Riesgos
ACTIVIDAD DE RIESGOS
Identificación
Análisis
Planificación
Seguimiento
Control
PARTICIPANTES
Equipo del Proyecto
* Gestor de Riesgos
* Responsable de Riesgo
* Equipo del Proyecto
* Gestor de Riesgos
* Project Manager
* Gestor de Riesgo
* Responsable de Riesgo
* Gestor de Riesgo
123
6.6.
2008
HERRAMIENTAS DE GESTIÓN DE RIESGOS
La herramienta usada para gestionar los riesgos será la Lista de
Riesgos.
6.7.
CRITERIO DE CIERRE
Para dar cierre a in riesgo, se debe asegurar que el factor que lo
genera está cubierto y no será activado nuevamente.
6.8.
CALENDARIO DE ACTIVIDADES DE GESTIÓN DE RIESGOS
Este calendario va de la mano con cada una de las fases del
proyecto, debido a que APIS está siendo desarrollado por módulos y
que, cada modulo tiene una planificación y tiempos específicos, se
detalla a continuación a que fase se refiere cada actividad.
Tabla 19 Calendario de Actividades Gestión de Riesgos
ACTIVIDAD DE RIESGO
* Identificación
* Análisis
* Planificación
* Seguimiento
* Control
EVENTO
Final de la fase de Estudio de Viabilidad del
Sistema
Todas las fases del proyecto
124
6.9.
2008
RIESGOS DETECTADOS
Al realizar una verificación de los riesgos que pueden afectar los
productos, encontramos los siguientes:
Escaso Tiempo de Planificación: El tiempo dedicado a la planificación de
los proyectos es muy corto, teniendo en cuenta la envergadura de los
mismos, lo cual puede representar un serio inconveniente a futuro
dirigido a la estimación de procesos.
Flexibilidad del Diseño: Debido a los tipos de productos que se
encuentra desarrollando Colonia Technologies, es necesario tener claro
que el diseño debe ser suficientemente flexible como para adaptarse a
diferentes entornos.
Inexperiencia en la aplicación de la metodología de desarrollo: Colonia
Technologies es una empresa nueva en el mercado que se encuentra
en etapa de estructuración y, se presentan fallas en la aplicación de la
Metodología de Desarrollo (MSF).
Inexistencia de Administración de Riesgos: La compañía no cuenta con
un proceso de administración de riesgos.
Amplia área de negocios: La compañía se encuentra desarrollando
productos software a la medida y paquetes comerciales, esto representa
una amplia área de negocios lo que genera trabajo excesivo.
125
6.10.
2008
PREGUNTAS DE ANÁLISIS DE RIESGOS
Estas
preguntas
están
estructuradas
para
el
modulo
de
COTIZACIONES, es posible que apliquen para otros módulos o que
sean ampliadas.
Tabla 20 Preguntas de Análisis de Riesgos
PREGUNTAS DE
CARACTERISTICA SUBCARECTIRISTICA ANÁLISIS
* ¿Se cuenta con las
funciones para la
FUNCIONALIDAD
creación y modificación
Adecuación
de cotizaciones?
* ¿Puede la
comunicación entre los
componentes introducir
imprecisiones en los
servicios ofrecidos por
Exactitud
los componentes?
* ¿Dónde se encuentran
los componentes que
permiten al sistema
interactuar con otros
Interoperatividad
sistemas?
* ¿Existen decisiones
para minimizar el manejo
FIABILIDAD
incorrecto de datos en la
comunicación entre
Nivel de Madurez
componentes?
* ¿Cómo se detecta el
funcionamiento
incorrecto de un
Tolerancia a Fallas
componente?
* ¿Cómo es la relación
entre el número de
EFICIENCIA
componentes de las
Comportamiento con
diferentes partes de la
Respecto a Tiempo
arquitectura?
126
MANTENIBILIDAD
PORTABILIDAD
6.11.
2008
* ¿Cómo se verifica el
funcionamiento correcto
de un componente?
* ¿Cómo se facilita el
Capacidad de
reemplazo de un
Modificación
componente?
* ¿Existe un mecanismo
para determinar si todos
los componentes del
sistema se encuentran
correctamente
Facilidad de Instalación instalados?
* ¿Existe alguna manera
de identificar las reglas
para interactuar con
componentes de
sistemas externos a la
Adaptabilidad
arquitectura?
ESCALA DE MEDICIÓN E IMPACTO
Para medir el impacto se usa la siguiente escala que será aplicada a cada
una de las preguntas de análisis de riesgo:
Tabla 21 Escala de Medición e Impacto
ESCALA PESO
Muy Poco
0,05
Poco
0,10
Moderado
0,20
Alto
0,40
Muy Alto
0,80
• Matriz de probabilidad e impacto 10
10
PMBOK Guide, 2004
127
2008
Tabla 22 Matriz de Probabilidad
PROBABILIDAD AMENAZAS
0,9
0,05
0,7
0,04
0,5
0,03
0,3
0,02
0,1
0,01
0,05
0,09
0,07
0,05
0,03
0,01
0,1
0,18
0,14
0,1
0,06
0,02
0,2
0,36
0,28
0,2
0,12
0,04
0,4
0,72
0,56
0,4
0,24
0,08
0,8
El área en rojo representa el riesgo más alto
El área media representa los riesgos moderados
El área en azul representa los riesgos menos importantes
Debido a que el proceso del proyecto APIS aún no facilita la recolección de
información y la aplicación del cuestionario establecido, se simulo con la
escala de medición la respuesta de 30 encuestas
para identificar el
porcentaje de riesgo en cada escala por pregunta:
128
2008
Tabla 23 Muestra de Encuesta
PREGUNTAS DE ANÁLISIS
NI
MP
P
M
A
MA
¿Se cuenta con las funciones
para la creación y modificación
de cotizaciones?
¿Puede la comunicación entre
los componentes introducir
imprecisiones en los servicios
ofrecidos por los
componentes?
¿Dónde se encuentran los
componentes que permiten al
sistema interactuar con otros
sistemas?
¿Existen decisiones para
minimizar el manejo incorrecto
de datos en la comunicación
entre componentes?
¿Cómo se detecta el
funcionamiento incorrecto de
un componente?
¿Cómo es la relación entre el
número de componentes de
las diferentes partes de la
arquitectura?
¿Cómo se verifica el
funcionamiento correcto de un
componente?
¿Cómo se facilita el reemplazo
de un componente?
¿Existe un mecanismo para
determinar si todos los
componentes del sistema se
encuentran correctamente
instalados?
¿Existe alguna manera de
identificar las reglas para
interactuar con componentes
de sistemas externos a la
arquitectura?
129
2008
Tabla 24 Respuesta Pregunta 1
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta1
0,17
0,00
0,03
0,05
0,10
0,03
0,20
0,17
0,40
0,50
0,80
0,10
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta2
0,00
0,23
0,10
0,05
0,10
0,23
0,20
0,10
0,40
0,07
0,80
0,27
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta3
0,00
0,47
0,05
0,07
0,10
0,30
0,20
0,03
0,40
0,00
0,80
0,17
130
2008
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta4
0,67
0,00
0,10
0,05
0,10
0,10
0,20
0,03
0,40
0,00
0,80
0,07
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta5
0,00
0,50
0,23
0,05
0,10
0,17
0,20
0,03
0,40
0,03
0,80
0,07
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta6
0,00
0,50
0,05
0,17
0,10
0,20
0,20
0,00
0,40
0,03
0,80
0,07
131
2008
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta7
0,43
0,00
0,23
0,05
0,10
0,17
0,20
0,03
0,40
0,00
0,80
0,13
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta8
0,00
0,50
0,20
0,05
0,10
0,27
0,20
0,00
0,40
0,00
0,80
0,03
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta9
0,00
0,43
0,05
0,27
0,10
0,10
0,20
0,03
0,40
0,07
0,80
0,10
132
2008
AMENAZA
NP
MP
P
M
A
MA
INTERVALOS
Pregunta10
0,37
0,00
0,23
0,05
0,10
0,27
0,20
0,00
0,40
0,03
0,80
0,10
133
2008
Ilustración 25 Tendencia * Pregunta
134
2008
El riesgo que ha sido detectado por cada pregunta se encuentra en un 43% de No
Impacto, donde se identifica entonces que los riesgos no estan afectando de
manera imporatante al modulo, sin embargo deben adeministrados y reducidos
pues el valor de impacto debe tender a 0.
Ilustración 26 Promedio Riesgos
135
2008
7. CONCLUSIONES
7.1.
CONCLUSIONES METODOLOGICAS FINALES
Al finalizar el proyecto y con él la aplicación de la Métrica V3, se noto
claramente la guía esta aporta al desarrollo de productos software,
como se estimó inicialmente, la Métrica V3 no solo es un marco de
referencia sino, una estructura que permite cimentar las etapas de
desarrollo, independiente de la metodología de desarrollo aplicado.
A pesar de esto es necesario tener claro una notación que permita
modelar el sistema pues, la Métrica no tiene ni plantillas ni estructura
la forma de llevar gráficamente el desarrollo del sistema.
La compañía que permitió aplicar parcialmente la Métrica en uno de
sus desarrollos es nueva, la Métrica nos da bases teóricas
importantísimas para estructurar no solo el desarrollo del producto
sino, el de todos los sistemas desarrollados al interior de la
compañía, contando con la documentación necesaria para enfocarse
parcial o totalmente a las interfaces y su mantenimiento.
136
2008
La Métrica no segmenta el desarrollo o lo limita a proyectos
pequeños o grandes, a la medida o comerciales, por tanto no limita
las metodologías de desarrollo Estructurado u OO, dándonos
herramientas
tanto para unos
como para otros
obteniendo
igualmente resultados que van de la mano con las exigencias
actuales del mercado.
Son entonces claros y notorios los múltiples beneficios que la
Metodología aporta a los nuevos desarrollos.
7.2.
CONCLUSIONES GENERALES DEL PROYECTO
En el momento de definir los objetivos se tenía claro el norte a
alcanzar y, los limitantes que se tenían de tiempo del Proyecto de
Grado y de tiempo de desarrollo del Producto software que sería
estudiado. Se logró cumplir con los objetivos planteados inicialmente
a pesar de tener expectativas mayores, es un logro entender y
aplicar la Métrica dejando así una base teórica o guía de consulta
para los estudiantes de la Facultad de Ingeniería de Sistemas.
137
2008
Se logro la aplicación parcial de la Métrica a las etapas del proyecto
que se han realizado y esto evidencia que de continuar con la
aplicación los resultados en el desarrollo serían óptimos.
Las continuas reuniones y consultas con los asesores del proyecto
permitieron afinar los resultados que deseaban obtenerse respecto
del tiempo existente y se logro un buen desarrollo del mismo.
Se logro dejar para el modulo de Cotizaciones del proyecto APIS, la
documentación base para iniciar el nivel de Diseño del Sistema de
Información en el cual aspiran trabajar durante 3 meses más.
138
2008
BIBLIOGRAFIA
•
AGUILAR RAMOS, Catherine. Identificación de riesgos de proyectos de
software en base a taxonomías. Puerto Rico, 2005, 191 h. Trabajo
de
Grado (Maestro en Ingeniería). Universidad de Puerto Rico. Disponible en <
http://grad.uprm.edu/tesis/>
•
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. ASI. [en linea].
<http://www.csi.map.es/csi/metrica3/index.html>. [citado en 27 de julio de
2008]
•
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. EVS. [en linea].
2008]
•
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. DSI. [en linea].
2008]
139
•
2008
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. IAS. [en linea].
2008]
•
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. MSI. [en linea].
2008]
•
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. PSI. [en linea].
2008]
•
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. CALIDAD. [en linea].
2008]
•
MINISTERIO DE ADMINISTRACIONES PÚBLICAS. SEGURIDAD. [en
linea]. <http://www.csi.map.es/csi/metrica3/index.html>. [citado en 27 de
julio de 2008]
140
•
2008
UNIVERSIDAD DE ALCALA. Integración de UML en la metodología
MÉTRICA. [en linea].
<http://www.cc.uah.es/hilera/docs/1999/c_jisbd/c_jisbd.htm> [citado en 19
de agosto de 2008]
•
UNIVERSIDAD DE LA LAGUNA. METRICA en la Enseñanza del Análisis
de Sistemas de Información. [en linea]. < http://bioinfo.uib.es/> [citado en 19
agosto de 2008]
•
MINISTERIO DE COMERCION, INDUSTRIA Y TURISMO, Republica de
Colombia.
[en
linea].
<
http://www.mincomercio.gov.co/eContent/Documentos/competitividad/conve
nios/> [citado en 20 de agosto de 2008]
•
ANSI/PMI, Norma Nacional Americana. Guía de los Fundamentos de la
Dirección de Proyectos: Guía del PMBOK. 2004. Tercera Edición. ANSI/PMI
99-001-2004.
141
•
2008
UNIVERSIDAD DE BURGOS. Calidad del Software y Métricas. [en linea].
<http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r21722.PDF>.
[citado en 27 de agosto de 2008]
•
VEMN SISTEMAS. Microsoft Solution Framework v.4 Agile (MSF). [en
linea].
<http:/download.microsoft.com/download/4/4/E/44E1B331-E509-
4D10-A9E3-B60640A3A403/20051206-ARC-BA.ppt>. [citado en 12 de
septiembre de 2008]
•
GATTACA S.A. Presentación de Metodología MSF (Microsoft Solutions
Framework).
[en
linea].
<http://www.e-
gattaca.com/eContent/library/documents/>. [citado en 12 de septiembre de
2008]
•
SÁNCHEZ ORTIZ, Aurora. Unidad III: Diseño De Procesos De Negocios.
[en
linea].
http://trevinca.ei.uvigo.es/~adomin/csi/web/pdfs/csi_met.pdf.
[citado en 12 de septiembre de 2008].
142

reconocimiento de posibles riesgos de desarrollos de sistemas de

Transcripción

Documentos relacionados

ORGANIGRAMA CORPORACIÓN VILLA GRIMALDI

Análisis Interno/Externo

DESARROLLOS INMOBILIARIOS