reconocimiento de posibles riesgos de desarrollos de ... · javier Ávila asesor del proyecto por...

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

2

Nota De Aceptación

________________________

________________________

Presidente Del Jurado

_______________________

Jurado

_______________________

Jurado

_______________________

Bogotá, 28 de noviembre de 2008


2008

3

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.


2008

4

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.


2008

5

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


2008

6

3.2.1. DESCRIPCIÓN DE LA SITUACIÓN ACTUAL ............................................................ 68

3.2.2. DIAGNOSTICO DE LA SITUACIÓN ACTUAL ............................................................ 73

4. DEFINICION DE LA ESTRUCTURA DE LA MÉTRICA ................................. 74

4.1. ASI Análisis del Sistema de Información ....................................................................... 74

4.1.1. Definición Del Sistema .............................................................................................. 74

4.1.2. Establecimiento De Requisitos .................................................................................. 78

4.1.3. Análisis De Los Casos De Uso ................................................................................ 100

4.1.4. Definición De Interfaces De Usuario ........................................................................ 105

4.1.5. 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


2008

7

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


2008

8

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


2008

9

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


2008

10

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


2008

11

Tabla 23 Muestra de Encuesta ...................................................................................... 129

Tabla 24 Respuesta Pregunta 1 ..................................................................................... 130









Tabla 33 Respuesta Pregunta 10 ................................................................................... 133


2008

12

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.


2008

13

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.


2008

14

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


2008

15

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


2008

16

1.2. 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.


2008

17

1.3. 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.


2008

18

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.


2008

19

1.4. 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


2008

20

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


2008

21

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.


2008

22

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


2008

23

- 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


2008

24

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


2008

25

- Ejecución del Modelo de Diagnóstico Exportador –Modiex-

- Realización de proyectos de asociatividad.

- Capacitación Administrativa, Comercial y Financiera.

• 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/


2008

26

- 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


2008

27

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.

4http://w3.bsa.org/colombia/


2008

28

2.2. 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.


2008

29

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.


2008

30

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.


2008

31

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 e

c

d


2008

32

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


2008

33

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.


2008

34

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.


2008

35

• 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.


2008

36

Ilustración 3 Estructura Métrica V3


2008

37

Las fases de la Métrica V3 son:

DSI A

SI

INTERFAZ

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)


2008

38

- 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.


2008

39

� 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


2008

40

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.


2008

41

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.


2008

42

ASI 1 DEFINICIÓN DEL SISTEMA

ASI 2 ESTABLECIMIENTO DE

REQUISITOS

ASI 3 IDENTIFICACIÓN DE SUBSITEMAS DE

ANÁLISIS

ASI 4 ANÁLISIS DE

CASOS DE USO

ASI 5 ANÁLISIS DE CLASES

ASI 6ELABORACIÓN DE MODELO DEL

DATOS

ASI 7ELABORACIÓN DE MODELO DE PROCESOS

ASI 8 DEFINICIÓN DE INTERFACES DE

USUARIO

ASI 9ANÁLISIS DE CONSISTENCIA

ASI 10ESPECIFICACIÓN

DE PLAN DE PRUEBAS

ASI 11 PRESENTACIÓN Y APROBACIÓN DEL ANÁLISIS DEL SI

Actividad Común

Actividad Solo Proceso OO

Actividad Solo Proceso Estructurado

Estructura ASI

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


2008

43

• 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


2008

44

� 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


2008

45

DSI 1DEFINICION DE LA ARQUITECTURA DEL

SISTEMA

DSI 2DISEÑO DE LA

ARQUITECTURA DE SOPORTE

DSI 3DISEÑO DE

CASOS DE USO REALES

DSI 4DISEÑO DE CLASES

DSI 5DISEÑO DE LA ARQUITECTURA DE MODULOS DEL SISTEMA

DSI 6DISEÑO FISICO DE

DATOS

DSI 7VERIFICACIÓN Y

ACEPTACIÓN DE LA ARQUITECTURA DEL

SISTEMA

DSI 8GENERACIÓN DE

ESPECIFICACIONES DE CONSTRUCCIÓN

DSI 9DISEÑO DE

MIGRACIÓN Y CARGA INICIAL DE

DATOS

Actividad Común

Actividad Solo Proceso OO

Actividad Solo Proceso Estructurado

Estructura DSI

DSI 10ESPECIFICACIÓN TÉCNICA DEL

PLAN DE PRUEBAS

DSI 11ESTABLECIMIENTO DE REQUISITOS DE IMPLANTACIÓN

DSI 12APROBACIÓ DEL DISEÑO SISTEMA DE INFORMACIÓN

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


2008

46

• 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

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.


2008

47

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.

CSI 1PREPARACIÓN: ENTORNO

DE GENERACIÓN Y CONSTRUCCIÓN

CSI 2GENERACIÓN: CÓDIGO DE LOS COMPONENTES Y PROCEDIMIENTOS

CSI 3EJECUCIÓN DE LAS PRUEBAS UNITARIAS

CSI 4EJECUCIÓN DE LAS

PRUEBAS DE INTEGRACIÓN

CSI 5EJECUCIÓN DE LAS

PRUEBAS DEL SISTEMA

CSI 6ELABORACIÓN DE LOS MANUALES DE USUARIO

CSI 7DEFINICIÓN DE LA FORMACIÓN DE

USUARIOS FINALES

CSI 8CONSTRUCCIÓN COMPONENTES Y

PROCEDIMIENTOS DE MIGRACION Y CARGA INICIAL

DE DATOS

CSI 9APROBACIÓN DEL

SISTEMA DE INFORMACIÓN

Estructura CSI

Ilustración 8 Estructura CSI


2008

48

� 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.


2008

49

Ilustración 9 Estructura IAS


2008

50

� 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


2008

51

• 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.

• Preventivo: Mejorar la calidad interna de los sistemas

Para 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


2008

52

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


2008

53

� 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.


2008

54

� 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.


2008

55

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.


2008

56

� 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:


2008

57

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:


2008

58

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


2008

59

Qué Hacen? Quiénes?

Sobre qué Información?

Lógica De Procesos

Categorías de Análisis BPM

Ilustración 13 Categorías de Análisis BPM


2008

60

2.3. 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 6 Microsoft Visual Studio .NET (2002) Microsoft Visual Studio .NET 2003 Microsoft Visual Studio 2005 Microsoft Visual Studio 2008


2008

61

• 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


2008

62

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


2008

63

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).


2008

64

� .NET 3.5 incluye biblioteca ASP.NET 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 versiones para varios entornos informáticos,

incluyendo computadoras domésticas o de 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


2008

65

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.


2008

66

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


2008

67

� 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


2008

68

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


2008

69

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


2008

70

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


2008

71

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/


2008

72

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/


2008

73

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.


2008

74

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.


2008

75

� Modelo de Negocio:

Ilustración 14 Modelo de Negocio


2008

76

� 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


2008

77

� 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


2008

78

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 sistema y combinar

procesos o componentes de 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.


2008

79

� 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


2008

80

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.


2008

81

� 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.


2008

82

� 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.


2008

83

� 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.


2008

84

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 Tiempo en días que tiene validez la cotización.

Forma de Pago 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 DETALLE NIT Identificación del cliente. Nombre Nombre del cliente. Teléfono Teléfono del cliente

Teléfono alternativo Otro teléfono del cliente Mail Correo electrónico del cliente Dirección Dirección del cliente Ciudad Ciudad del cliente Contacto Nombre de la persona contacto.


2008

85

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.


2008

86

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


2008

87

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


2008

88

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


2008

89

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


2008

90

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.


2008

91

� Análisis de Requisitos

Del Diagrama de Casos de Uso general obtenemos los siguientes

casos de uso especificados.

� Crear Nueva Cotización

Cotizador

Creando Cotización

DefiniendoPreproducto

DefiniendoComponente

Definiendo Proceso

DefiniendoMaterias Primas

Definiendo DatosComerciales

Asigna Número deCotización Nueva

1

1

Preprensa

Ilustración 16 Diagrama de CU Crear Nueva Cotización


2008

92

� Modificar cotización

Ilustración 17 Diagrama de CU Modificar Cotización


2008

93

� Hacer una cotización basada en una Existente

Cotizador

Creando CotizaciónBasada en Otra

DefiniendoPreproducto

DefiniendoComponente

Definiendo Proceso

DefiniendoMaterias Primas

Definiendo DatosComerciales

Asigna Número deCotización Nueva

1

1

Preprensa

Ilustración 18 Diagrama de CU Hacer una Cotización basada en una Existente


2008

94

� 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.


2008

95

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



2008

96

� 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

preconfigurado.

v. El sistema define el proceso


En el punto i. Si no hay materias primas

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.


2008

97

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


2008

98


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.


2008

99


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.


2008

100

4.1.3. Análisis De Los Casos De Uso

� Identificación de Clases Asociadas a Casos de Uso

Diagrama De Clases

+ObtieneDatosProceso() : String+BuscaSatelite() : String+SolicitaCrearSatelite() : String+EligeCentroProduccion() : String+SeleccionaMP() : String+DefineMP() : String+SeleccionaProceso() : String+DefineProceso() : String

-Id_Proceso : Integer-Nombre_Proceso : String

Proceso

+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

-Id_Producto : Integer-Nombre_Producto : String

Producto

+ObtieneDatosMP() : Integer+SolicitaCrearMP() : String+EligeMP() : Integer

-Id_MP : Integer-Nombre_MP : String

Materia Prima+ObtieneDatosComponente() : String+SeleccionaMP() : String+DefineMP() : String+BuscaMP() : String+SolicitaCrearMP() : String+SeleccionaProceso() : String+DefineProceso() : String+BuscaProceso() : String+SolicitaCrearProceso() : String

-Id_Componente : Integer-Nombre_Componente : String

Componente

+ObtieneDatosCotizacion() : String+CorrerProcesoCalculo() : String+BuscaCliente() : String+CreaClienteRapido() : String+EligeCliente() : String+ConsultaOpciones() : String+ConfiguraPropuesta() : String+DefineMontaje() : String+DefineDatosComerciales() : String+BuscaPlantillaProduto() : String+EligePlantillaProducto() : String+GuardaCotizacion() : Boolean

-Id_Cotizacion : Integer-Id_Cliente : Integer-Cantidad_prod : Integer-Cantidad_pag : Integer

Cotizacion

-Fin1

1

-Fin2

*

-Fin30..1

-Fin4*

-Fin5

*

-Fin61

-Fin7

0..1

-Fin8

*

Ilustración 19 Diagrama de Clases


2008

101

� 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 Tipo Descripción Id_Cotizacion Integer Código de la Cotización Id_Cliente Integer Código del Cliente Cantidad_prod Integer Numero de productos a realizad Cantidad_pag Integer Número de páginas a producir

o Operaciones

Tabla 6 Operaciones Cotización

Operación Descripción ObtieneDatosCotizacion Permite capturar los datos de una nueva cotización CorrerProcesoCalculo Calcula el total de la cotización BuscaCliente Permite buscar un cliente CreaClienteRapido Permite Crear un Cliente de forma rápida EligeCliente Permite seleccionar un cliente encontrado ConsultaOpciones Permite consultar los opciones de cotización ConfiguraPropuesta Permite configurar una propuesta


2008

102

DefineMontaje Permite definir el montaje elegido DefineDatosComerciales Permite definir datos comerciales BuscaPlantillaProduto Permite buscar una plantilla de un producto EligePlantillaProducto Permite elegir una plantilla encontrada GuardaCotizacion 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 Tipo Descripción Nombre_Producto : String Integer Código Producto Nombre_Producto String Nombre del producto

o Operaciones

Tabla 8 Operaciones Producto

Operación Descripción ObtieneDatosProducto Permite capturar los datos de un producto SeleccionaComponente Permite seleccionar un componente DefineComponente Permite definir un componente BuscaComponente Permite buscar un componente SolicitaCrearComponente Permite solicitar la creación de un nuevo componente SeleccionaMP Permite Seleccionar materia prima DefineMP Permite definir la materia prima BuscaMP Permite Buscar la materia prima SolicitaCrearMP Permite solicitar la creación de un nueva materia prima BuscaProceso Permite buscar un proceso SeleccionaProceso Permite seleccionar un proceso DefineProceso Permite definir un proceso SolicitaCrearProceso Permite solicitar la creación de un nuevo proceso


2008

103

� 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 Tipo Descripción Id_Proceso Integer Código Proceso Nombre_Proceso String Nombre del proceso

o Operaciones

Tabla 10 Operaciones Proceso

Operación Descripción ObtieneDatosProceso Permite capturar datos de un proceso BuscaSatelite Permite buscar un satélite SolicitaCrearSatelite Permite crear un nuevo satélite EligeCentroProduccion Permite elegir un centro de producción SeleccionaMP Permite seleccionar materia prima DefineMP Permite definir materia prima SeleccionaProceso Permite Seleccionar un proceso DefineProceso Permite definir un proceso


2008

104

� 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 Descripción Id_Componente Integer Código Componente Nombre_Componente String Nombre del Componente

o Operaciones

Tabla 12 Operaciones Componente

Operación Descripción ObtieneDatosComponente Permite capturar datos de un componente SeleccionaMP Permite seleccionar Materia prima DefineMP Permite definir materia prima BuscaMP Permite buscar materia prima SolicitaCrearMP Permite solicitar la creación de una materia prima SeleccionaProceso Permite Seleccionar un proceso DefineProceso Permite definir un proceso BuscaProceso Permite buscar un proceso SolicitaCrearProceso Permite solicitar creación de un nuevo proceso


2008

105

� 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 Tipo Descripción Id_MP Integer Código Materia Prima Nombre_MP String Nombre Materia Prima

o Operaciones

Tabla 14 Operaciones Materia Prima

Operación Descripción ObtieneDatosMP Permite capturar datos de una materia prima SolicitaCrearMP Permite solicitar creación de una nueva materia prima EligeMP 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


2008

106

� 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.


2008

107

Ilustración 20 Interfaz Árbol APIS


2008

108

A continuación se representan los formularios de creación de componentes

del sistema.

Ilustración 21 Interfaz FRM Creación


2008

109

Ilustración 22 Interfaz FRM de Creación2


2008

110

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


2008

111

Ilustración 24 Interfaz Configuración2


2008

112

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.


2008

113

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.


2008

114

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


2008

115

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.


2008

116

5.3. 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

COMENTARIOS

NSU NO

Aprobación del cliente sobre la calidad y procesos del modulo

El nivel de satisfacción de usuario se obtiene mediante una encuesta realizada al entregar c/modulo

Datos de Calidad NO Registro de Métricas Datos de Calidad de Pruebas NO Registro de Métricas

Defectos Posteriores a la entrega (DELTA) NO Registro de Métricas

Los defectos producidos durante el desarrollo serán controlados durante la fase de mantenimiento que será administrada como un proyecto independiente.

Defectos posteriores a la entrega (Total) NO Registro de Métricas

Defectos detectados por el cliente (Delta) NO Registro de Métricas

Los defectos producidos durante el desarrollo serán controlados durante la fase de mantenimiento que será administrada


2008

117

como un proyecto independiente.

Defectos detectados por el cliente (Total) NO Registro de Métricas Total de errores y defectos conocidos en el código al momento de entregar el producto NO Registro de Métricas

El producto debe ser entregado libre de errores conocidos.

Tiempo calendario y productividad para mejoras del producto NO Registro de Métricas

El proyecto implica el desarrollo de un producto nuevo.

Tiempo calendario y productividad para un producto nuevo NO Registro de Métricas

Adecuación de la estimación de esfuerzo NO Registro de Métricas

Adecuación de la estimación de calendario NO Registro de Métricas Adecuación de la estimación de tamaño del producto NO Registro de Métricas

Tamaño del producto del proyecto (Total) NO Registro de Métricas

Tamaño del producto del proyecto (Delta) NO Registro de Métricas

Productividad NO Registro de Métricas

Cantidad de código reutilizado NO Registro de Métricas

Cantidad de requerimientos de cambio NO Registro de Métricas

No se implementarán requerimientos de cambio para el prototipo.


2008

118

Cantidad de personas integrantes del equipo de proyecto SI Registro de Métricas

Inspecciones y datos de revisiones NO Registro de Métricas

Costos SI Registro de Métricas

Los costos son controlados por el área de finanzas.

Gestión de riesgos NO Plan de Riesgos

5.4. 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.


2008

119

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.


2008

120

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


2008

121

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.


2008

122

6.2. 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


2008

123

6.4. DOCUMENTACIÓN DE RIESGOS

Tabla 17 Documentación de Riesgos

DOCUMENTO DESCRIPCIÓN

Lista de Riesgos Contiene los factores de riesgos identificados y manejados para el proyecto.

Datos de Riesgos

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 * Estado

6.5. ACTIVIDADES DE GESTION DE RIESGOS

Tabla 18 Actividades de Gestión de Riesgos

ACTIVIDAD DE RIESGOS PARTICIPANTES Identificación Equipo del Proyecto

Análisis * Gestor de Riesgos * Responsable de Riesgo

Planificación * Equipo del Proyecto * Gestor de Riesgos

Seguimiento * Project Manager * Gestor de Riesgo

Control * Responsable de Riesgo * Gestor de Riesgo


2008

124

6.6. 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 EVENTO

* Identificación * Análisis * Planificación

Final de la fase de Estudio de Viabilidad del Sistema

* Seguimiento * Control Todas las fases del proyecto


2008

125

6.9. 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.


2008

126

6.10. 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

CARACTERISTICA SUBCARECTIRISTICA PREGUNTAS DE ANÁLISIS

FUNCIONALIDAD

Adecuación

* ¿Se cuenta con las funciones para la creación y modificación de cotizaciones?

Exactitud

* ¿Puede la comunicación entre los componentes introducir imprecisiones en los servicios ofrecidos por los componentes?

Interoperatividad

* ¿Dónde se encuentran los componentes que permiten al sistema interactuar con otros sistemas?

FIABILIDAD

Nivel de Madurez

* ¿Existen decisiones para minimizar el manejo incorrecto de datos en la comunicación entre componentes?

Tolerancia a Fallas

* ¿Cómo se detecta el funcionamiento incorrecto de un componente?

EFICIENCIA Comportamiento con Respecto a Tiempo

* ¿Cómo es la relación entre el número de componentes de las diferentes partes de la arquitectura?


2008

127

MANTENIBILIDAD

Capacidad de Modificación

* ¿Cómo se verifica el funcionamiento correcto de un componente? * ¿Cómo se facilita el reemplazo de un componente?

PORTABILIDAD

Facilidad de Instalación

* ¿Existe un mecanismo para determinar si todos los componentes del sistema se encuentran correctamente instalados?

Adaptabilidad

* ¿Existe alguna manera de identificar las reglas para interactuar con componentes de sistemas externos a la arquitectura?

6.11. 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


2008

128

Tabla 22 Matriz de Probabilidad

PROBABILIDAD AMENAZAS 0,9 0,05 0,09 0,18 0,36 0,72 0,7 0,04 0,07 0,14 0,28 0,56 0,5 0,03 0,05 0,1 0,2 0,4 0,3 0,02 0,03 0,06 0,12 0,24 0,1 0,01 0,01 0,02 0,04 0,08

0,05 0,1 0,2 0,4 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:


2008

129

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?


2008

130

Tabla 24 Respuesta Pregunta 1

AMENAZA INTERVALOS Pregunta1 NP 0,00 0,17 MP 0,05 0,03 P 0,10 0,03 M 0,20 0,17 A 0,40 0,50 MA 0,80 0,10






2008

131








2008

132








2008

133




2008

134

Ilustración 25 Tendencia * Pregunta


2008

135

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


2008

136

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.


2008

137

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.


2008

138

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.


2008

139

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]


2008

140

• 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]


2008

141

• 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.


2008

142

• 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].

reconocimiento de posibles riesgos de desarrollos de ... · javier Ávila asesor del proyecto por...

Documents