PERSONALIZACION METODOL´ OGICA PARA EL´...

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

PERSONALIZACION METODOLOGICA PARA ELASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

IMPLEMENTADO POR MI PYMES

Caso de estudio: Efron Colombia S.A.S.

Autor:LUIS ALEJANDRO URIBE NINO

Codigo 20172099046Grupo No. 2

FACULTAD DE INGENIERIAESPECIALIZACION EN INGENIERIA DE SOFTWARE

Bogota, ColombiaMayo 2018

UNIVERSIDAD DISTRITAL FRANCISCO JOSE DE CALDAS

PERSONALIZACION METODOLOGICA PARA ELASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

IMPLEMENTADO POR MI PYMES

Caso de estudio: Efron Colombia S.A.S.

Autor:LUIS ALEJANDRO URIBE NINO

Codigo 20172099046Grupo No. 2

Director:SANDRO JAVIER BOLANOS CASTRO, Ph.D.

Revisor:EDILBERTO FERNANDEZ SANTOS

FACULTAD DE INGENIERIAESPECIALIZACION EN INGENIERIA DE SOFTWARE

Bogota, ColombiaMayo 2018

“Dedico este trabajo a Leslie, a Sara, a Sofıa, a mi Mami, y a Dona Betty, quienes me hanensenado desde diferentes puntos de vista lo bello que es el amor, y me han brindado

durante las diferentes etapas de mi vida todo lo bonito y magico que esta palabracontempla.”

Luis Alejandro Uribe Nino.

A G R A D E C I M I E N T O S

Gracias a Dios por darnos la salud y permitirnos alcanzar este logro. A la Universidadpor formarnos para llegar al punto en el que estamos hoy. Al ingeniero Sandro Bolanospor orientarnos y compartir todo su conocimiento. A Edilberto Fernandez, Roberto Pava,Lilian Bejarano, Joaquın Mesa, Alexandra Abuchar, Jorge Mario Calvo, John Fredy Pa-rra, Sandra Milena Cortes, y demas profesores y funcionarios por este logro. A Efron pordarnos la oportunidad y la informacion para realizar este trabajo. Y a cada una de laspersonas que se preocuparon y me colaboraron para que yo culminara esta importanteetapa, en especial a mis companeros de estudio Daniel y Daniela por la colaboraciony el apoyo mancomunado. A Edwin mi jefe, por aconsejarme, orientarme y apoyarmeen este proceso. A mi mama por estar ahı cada vez que necesite de todo su apoyo, ypor supuesto a Leslie por darme la fuerza para culminar esta etapa y brindarme todo suamor. A todos mil Gracias!


7

D E C L A R AT O R I A

Declaro que la informacion y las imagenes contenidas en el presente trabajo de gradotitulado: Personalizacion Metodologica para el Aseguramiento de la Calidad del Soft-ware Implementado por Mi Pymes, son de absoluta autorıa propia, por lo tanto, son elresultado del trabajo del autor, excepto aquellos aportes intelectuales de otros autores,los cuales se han referenciado debidamente en el texto de dicho trabajo.


9

I N D I C E G E N E R A L

Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

I C O N T E X T UA L I Z A C I O N D E L A I N V E S T I G A C I O N . . . . . . . . . . . . 191 D E S C R I P C I O N D E L A I N V E S T I G A C I O N . . . . . . . . . . . . . . . . . . 21

1.1 Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . 211.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.3 Justificacion de la Investigacion . . . . . . . . . . . . . . . . . . . . 221.4 Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.5 Marco Referencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.6 Metodologıa de la Investigacion . . . . . . . . . . . . . . . . . . . . 251.7 Organizacion del Trabajo de Grado . . . . . . . . . . . . . . . . . . 261.8 Estudio de Sistemas Previos . . . . . . . . . . . . . . . . . . . . . . 26

II A R Q U I T E C T U R A Y D I S E N O . . . . . . . . . . . . . . . . . . . . . . . . 272 O R G A N I Z A C I O N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.1 Empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292.1.1 Mision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.1.2 Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.1.3 Objetivos de Calidad . . . . . . . . . . . . . . . . . . . . . . 302.1.4 Objetivos de la Organizacion . . . . . . . . . . . . . . . . . . 31

3 F A S E D E A R Q U I T E C T U R A D E N E G O C I O S . . . . . . . . . . . . . . . . . 333.1 Punto de Vista de Organizacion . . . . . . . . . . . . . . . . . . . . 35

3.1.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Punto de Vista de Cooperacion de Actor . . . . . . . . . . . . . . . 363.2.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Punto de Vista de Funcion de Negocio . . . . . . . . . . . . . . . . 383.3.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.4 Punto de Vista de Proceso de Negocio . . . . . . . . . . . . . . . . . 413.4.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

11

12 I N D I C E G E N E R A L

3.4.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Punto de Vista de Cooperacion de Proceso de Negocio . . . . . . . . 42


3.6 Punto de Vista de Producto . . . . . . . . . . . . . . . . . . . . . . . 443.6.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.6.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4 F A S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I O N . . . . . . 474.1 Punto de Vista de Uso de la Aplicacion . . . . . . . . . . . . . . . . 48


4.2 Punto de Vista de Comportamiento de la Aplicacion . . . . . . . . . 504.2.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3 Punto de Vista de Cooperacion de la Aplicacion . . . . . . . . . . . 524.3.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.3.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.4 Punto de Vista de Estructura de la Aplicacion . . . . . . . . . . . . 544.4.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.4.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5 F A S E D E A R Q U I T E C T U R A D E T E C N O L O G I A . . . . . . . . . . . . . . . 575.1 Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . 58


5.2 Punto de Vista de Uso de Infraestructura . . . . . . . . . . . . . . . 605.2.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 605.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3 Punto de Vista de Organizacion e Implementacion . . . . . . . . . . 625.3.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.4 Punto de Vista de Estructura de Informacion . . . . . . . . . . . . . 645.4.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 645.4.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.5 Punto de Vista de Realizacion del Servicio . . . . . . . . . . . . . . 665.5.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 665.5.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.6 Punto de Vista de Capas . . . . . . . . . . . . . . . . . . . . . . . . 685.6.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 685.6.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6 F A S E D E V I S I O N D E A R Q U I T E C T U R A . . . . . . . . . . . . . . . . . . . 716.1 Punto de Vista de Stakeholder . . . . . . . . . . . . . . . . . . . . . 73

I N D I C E G E N E R A L 13


6.2 Punto de Vista de Realizacion de Objetivos . . . . . . . . . . . . . . 746.2.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 746.2.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.3 Punto de Vista de Contribucion de Objetivos . . . . . . . . . . . . . 766.3.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 766.3.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

6.4 Punto de Vista de Principios . . . . . . . . . . . . . . . . . . . . . . 786.4.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 786.4.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

6.5 Punto de Vista de Realizacion de Requerimientos . . . . . . . . . . 796.5.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 796.5.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.6 Punto de Vista de Motivacion . . . . . . . . . . . . . . . . . . . . . 816.6.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 816.6.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

7 F A S E D E O P O RT U N I D A D E S Y S O L U C I O N E S . . . . . . . . . . . . . . . 837.1 Punto de Vista de Proyecto . . . . . . . . . . . . . . . . . . . . . . . 84

7.1.1 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 858 F A S E D E P L A N E A C I O N Y M I G R A C I O N . . . . . . . . . . . . . . . . . . . 87

8.1 Punto de Vista de Migracion . . . . . . . . . . . . . . . . . . . . . . 878.1.1 Metamodelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 878.1.2 Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

9 F A S E D E I M P L E M E N TA C I O N D E G O V E R N A N Z A . . . . . . . . . . . . . 899.1 Punto de Vista de Migracion e Implemantacion . . . . . . . . . . . 89


III R E F L E X I O N E S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9110 P R O P U E S TA M E T O D O L O G I C A . . . . . . . . . . . . . . . . . . . . . . . 9311 C O N C L U S I O N E S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9712 T R A B A J O S F U T U R O S . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9913 A N E X O S . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

13.1Coloso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10113.1.1Colosoft EU . . . . . . . . . . . . . . . . . . . . . . . . . . . 10113.1.2Autor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Bibliografıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

I N D I C E D E F I G U R A S

Figura 1 Efron Consulting[4] . . . . . . . . . . . . . . . . . . . . . . . 30Figura 2 Punto de Vista de Organizacion[7, 3] . . . . . . . . . . . . . . 35Figura 3 Modelo de Organizacion. Fuente: Autor . . . . . . . . . . . . 36Figura 4 Punto de Vista de Cooperacion de Actor[7, 3] . . . . . . . . . 37Figura 5 Modelo de Cooperacion de Actor. Fuente: Autor . . . . . . . . 38Figura 6 Punto de Vista de Funcion de Negocio[7, 3] . . . . . . . . . . 39Figura 7 Modelo de Funcion de Negocio. Fuente: Autor . . . . . . . . . 40Figura 8 Punto de Vista de Proceso de negocio[7, 3] . . . . . . . . . . 41Figura 9 Modelo de Proceso de Negocio. Fuente: Autor . . . . . . . . . 42Figura 10 Punto de Vista de Cooperacion de Proceso de Negocio[7, 3] . 43Figura 11 Modelo de Cooperacion de Proceso de Negocio. Fuente: Autor 44Figura 12 Punto de Vista de Producto[7, 3] . . . . . . . . . . . . . . . . 45Figura 13 Modelo de Producto. Fuente: Autor . . . . . . . . . . . . . . . 46Figura 14 Punto de Vista de Uso de Aplicacion[7, 3] . . . . . . . . . . . 49Figura 15 Modelo de Uso de Aplicacion. Fuente: Autor . . . . . . . . . . 50Figura 16 Punto de Vista de Comportamiento de Aplicacion[7, 3] . . . . 51Figura 17 Modelo de Comportamiento de Aplicacion. Fuente: Autor . . 52Figura 18 Punto de Vista de Cooperacion de Aplicacion[7, 3] . . . . . . 53Figura 19 Modelo de Cooperacion de Aplicacion. Fuente: Autor . . . . . 54Figura 20 Punto de Vista de Estructura de Aplicacion[7, 3] . . . . . . . . 55Figura 21 Modelo de Estructura de Aplicacion. Fuente: Autor . . . . . . 55Figura 22 Punto de Vista de Infraestructura[7, 3] . . . . . . . . . . . . . 59Figura 23 Modelo de Infraestructura. Fuente: Autor . . . . . . . . . . . 60Figura 24 Punto de Vista de Uso de Infraestructura[7, 3] . . . . . . . . . 61Figura 25 Modelo de Uso de Infraestructura. Fuente: Autor . . . . . . . 62Figura 26 Punto de Vista de Organizacion e Implementacion[7, 3] . . . 63Figura 27 Modelo de Organizacion e Implementacion. Fuente: Autor . . 64Figura 28 Punto de Vista de Estructura de Informacion[7, 3] . . . . . . . 65Figura 29 Modelo de Estructura de Informacion. Fuente: Autor . . . . . 66Figura 30 Punto de Vista de Realizacion del Servicio[7, 3] . . . . . . . . 67Figura 31 Modelo de Realizacion del Servicio. Fuente: Autor . . . . . . . 68

15

16 I N D I C E G E N E R A L

Figura 32 Punto de Vista de Capas[7, 3] . . . . . . . . . . . . . . . . . . 69Figura 33 Modelo de Capas. Fuente: Autor . . . . . . . . . . . . . . . . 70Figura 34 Relacion entre los elementos principales y los elementos motivacio-

nales [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Figura 35 Punto de Vista de Stakeholder[7, 3] . . . . . . . . . . . . . . 73Figura 36 Modelo de Stakeholder. Fuente: Autor . . . . . . . . . . . . . 74Figura 37 Punto de Vista de Realizacion de Objetivos[7, 3] . . . . . . . . 75Figura 38 Modelo de Realizacion de Objetivos. Fuente: Autor . . . . . . 76Figura 39 Punto de Vista de Contribucion[7, 3] . . . . . . . . . . . . . . 77Figura 40 Modelo de Contribucion. Fuente: Autor . . . . . . . . . . . . . 77Figura 41 Punto de Vista de Principios[7, 3] . . . . . . . . . . . . . . . . 78Figura 42 Modelo de Principios. Fuente: Autor . . . . . . . . . . . . . . 79Figura 43 Punto de Vista de Realizacion de Requerimientos[7, 3] . . . . 80Figura 44 Modelo de Realizacion de Requerimientos. Fuente: Autor . . . 80Figura 45 Punto de Vista de Motivacion[7, 3] . . . . . . . . . . . . . . . 81Figura 46 Modelo de Motivacion. Fuente: Autor . . . . . . . . . . . . . . 82Figura 47 Punto de Vista de Proyecto[7, 3] . . . . . . . . . . . . . . . . 84Figura 48 Modelo de Proyecto. Fuente: Autor . . . . . . . . . . . . . . . 85Figura 49 Punto de Vista de Migracion[7, 3] . . . . . . . . . . . . . . . . 87Figura 50 Modelo de Migracion. Fuente: Autor . . . . . . . . . . . . . . 88Figura 51 Punto de Vista de Migracion e Implementacion[7, 3] . . . . . 89Figura 52 Modelo de Migracion e Implementacion. Fuente: Autor . . . . 90Figura 53 Propuesta Metodologica. Fuente: Autor . . . . . . . . . . . . . 96Figura 54 Logo de Colosoft[1] . . . . . . . . . . . . . . . . . . . . . . . 101

I N T R O D U C C I O N

El proceso de desarrollo de software es un proceso flexible que permite que cada per-sona, grupo de trabajo o entidad defina su propia metodologıa de desarrollo, lo cualbrinda una autonomıa para que dicho proceso sea tan estructurado como se desee, estomismo puede ser contraproducente si se define una metodologıa no muy estructurada,es decir crea las condiciones para la aparicion de riesgos, los cuales bajo estas condi-ciones no se deben tener identificados y mucho menos deben tener definidos planes deaccion para la mitigacion de los mismos.

El proceso de mejora continua, los procesos de certificacion de calidad y demas pro-cesos que requieren la definicion de estandares y la elaboracion de la documentacionde los mismos, permiten cada vez mas que el aseguramiento de la calidad de los pro-ductos de software mejore, dado que de esta manera se identifican factores de riesgoque pueden ser mitigados o controlados, como tambien la identificacion de procesos yprocedimientos que pueden ser depurados y/u optimizados.

Basado en lo anterior es donde el aseguramiento de calidad toma fuerza y apalancalos demas procesos antes mencionados, y es allı donde la sinergia de varios estandaresy las buenas practicas hacen posible la implementacion de un producto de software concalidad, el cual no solo cumple con los requerimientos funcionales y no funcionales so-licitados por el cliente, si no tambien es un producto amigable y que genera un valoragregado al cliente, maximizando de esta forma su nivel de satisfaccion y generando unambiente cliente proveedor propicio para realizar nuevos negocios.

17

Parte I

C O N T E X T UA L I Z A C I O N D E L A I N V E S T I G A C I O N

1

D E S C R I P C I O N D E L A I N V E S T I G A C I O N

1.1 P L A N T E A M I E N T O D E L P R O B L E M A

En la actualidad se presenta una dificultad en el momento de la entrega de los pro-ductos de software a los usuarios funcionales, dado que no siempre se cumple con todaslas especificaciones que requieren y/o que esperan recibir los mismos, lo cual no sologenera insatisfaccion al grupo de trabajo tanto de cara al cliente como del proveedorde software, sino tambien genera sobrecostos al proyecto, retrasos en los tiempos deentrega, reduccion en los indicadores de calidad del proyecto, y mala imagen de loscolaboradores involucrados hacia al cliente y hacia la companıa que provee los serviciosde software.

Actualmente se cuenta con todo el marco teorico que brindan las normas ISO y demaspropuestas metodologicas que han sido implementadas a nivel mundial por empresasdesarrolladoras de software de tamano similar al de las mi pymes en Colombia, o inclu-so de mayor tamano pero que pueden tomarse como punto de referencia para mejorarel proceso de desarrollo de software.

1.2 O B J E T I V O S

Objetivo General

− Elaborar una personalizacion metodologica por medio de la investigacion de lasbuenas practicas del mercado para el aseguramiento de la calidad del softwareimplementado por mi pymes.

21

22 D E S C R I P C I O N D E L A I N V E S T I G A C I O N

Objetivos Especıficos

− Investigar los aspectos definidos en las normas internacionales ISO para el asegu-ramiento de la calidad de un producto de software por medio del internet y demasregistros documentales.

− Analizar las falencias de calidad mas comunes en un producto de software pormedio de la retroalimentacion de las mi pymes para focalizar la problematicaexistente.

− Analizar la arquitectura de negocio para el proceso de levantamiento de requeri-mientos de Efron Colombia.

1.3 J U S T I F I C A C I O N D E L A I N V E S T I G A C I O N

Justificacion Teorica

Basado en las normas ISO principalmente en la norma 15504, la cual demarca todoslos aspectos generales sobre el aseguramiento de la calidad, y apoyado en otras buenaspracticas estandarizadas y/o acogidas a nivel mundial se debe buscar definir y delimi-tar a un nivel especıfico el marco teorico sobre el aseguramiento de la calidad de losproductos de software.

Justificacion Metodologica

Tomando la delimitacion teorica que brindan las normas ISO y enfocado en las me-todologıas propias de cada mi pyme, se debe estructurar una propuesta metodologicaflexible que permita mejorar la calidad de los productos de software implementados porlas mi pymes.

Justificacion Practica

Como resultado del proceso investigativo se busca mejorar la satisfaccion del clienteincrementando la calidad de los productos de software que le son entregados, lo cual ge-nerara un efecto beneficioso de forma transversal al cliente y a la misma mi pyme, dadoque esto reducira los sobrecostos de las implementaciones, los tiempos de retroalimen-tacion, la imagen y las relaciones entre los participantes de los grupos de trabajo tantode parte del cliente como de parte del grupo de trabajo que implementa la solucion desoftware.

1.4 H I P O T E S I S 23

1.4 H I P O T E S I S

Al estructurar una personalizacion metodologica para la gestion del conocimientoque garantice el aseguramiento de la calidad del software implementado por mi pymes,se obtendra un valor agregado para los clientes y a su vez para las mismas mi pymes,dado que esto generara de forma implıcita una tranquilidad y seguridad hacia el cliente,quien sabra que el producto que esta recibiendo de parte de la mi pyme es un productoque satisface sus necesidades funcionales y no funcionales, y adicionalmente traera be-neficios para la companıa.

La personalizacion metodologica le dara a la gerencia del proyecto de parte de la mipyme una lınea base para lograr el aseguramiento de la calidad del software que le seraentregado al cliente, dado le brindara mecanismos metodologicos para gestionar tantocomo los clientes externos e internos del proyecto, logrando un mayor acompanamien-to y retroalimentacion de parte de todo el equipo de trabajo, dando como resultadoun producto con el mayor nivel de calidad posible, adicionalmente esta personalizacionmetodologica dara insumos y/o herramientas para poder identificar indicadores de me-dicion, los cuales podran evaluarse y hacer seguimiento por medio de una trazabilidad,la cual permitira determinar las acciones a tomar durante la ejecucion del proyecto deimplementacion del software implementado por una mi pyme.

Es aquı donde toma relevancia la implementacion de unos productos de software queapoyen la gestion de requerimientos y los indicadores del proyecto, su trazabilidad, lageneracion de una serie de reportes detallados, consolidados y gerenciales que permi-tan analizar y mostrar el comportamiento de las mediciones realizadas durante la im-plementacion del producto de software; esta herramienta tecnologica tambien deberamostrar el estado actual e historico de cualquier proyecto que haya sido registrado endicho software en un periodo de tiempo determinado, es decir, debe visualizar la infor-macion entre periodos de tiempo que el usuario requiera.

Todo lo anterior apalancara de forma transversal el proceso de mejora continua de la mipyme, dado que brindara informacion relevante y muy oportuna para identificar puntosde control, puntos de medicion, identificacion de factores de riesgos y un sin numero deinformacion que permitira que el software que se esta implementando tenga un curvade maduracion mucho mas corta, y su vez permitira que la misma mi pyme se conviertaen una organizacion mas estructurada, mas metodica, con mejores controles de calidad,y a su vez mas confiable para los clientes actuales y futuros, los cual les brindara unplus en el mercado que en la medida del tiempo se vera reflejado en sus indicadoresfinancieros.


1.5 M A R C O R E F E R E N C I A L

Marco Teorico

La norma ISO 15504 o SPICE por su nombre en ingles, Software Process ImprovementCapability Determination, es un modelo para la mejora, evaluacion de los procesos dedesarrollo, mantenimiento de sistemas de informacion y productos de software, dentrode la cual se define el Modelo de procesos de referencia como los procesos contenidosen la norma ISO 12207.[12] Normalmente, en la mejora de la calidad de los procesosparticipan dos tipos de modelos, el modelo de procesos y el modelo de evaluacion. Elmodelo de procesos define un catalogo o coleccion estructurada de buenas practicasque describen las caracterısticas de un proceso efectivo, mientras que el modelo deevaluacion proporciona los principios para realizar una evaluacion de la calidad, e im-plantacion, de dicho modelo de procesos en una organizacion.[5]

Establece un marco y los requisitos para cualquier fase de evaluacion de procesos yproporciona requisitos para los modelos de evaluacion de estos. Proporciona tambienrequisitos para cualquier modelo de evaluacion de organizaciones. Proporciona guıaspara la definicion de las competencias de un evaluador de procesos. Comprende: eva-luacion de procesos, mejora de procesos, determinacion de capacidad. Proporciona, ensu parte 5, un Modelo de evaluacion de procesos para las fases de ciclo de vida delsoftware definidos en el estandar ISO 12207 que define los procesos del ciclo de vidadel desarrollo, mantenimiento y operacion de los sistemas de software. Proporciona, ensu parte 6, un Modelo de evaluacion de procesos para las etapas de ciclo de vida delsistema, definidos en el estandar ISO 15288 que define los procesos del ciclo de vidadel desarrollo, mantenimiento y operacion de sistemas. Proporcionara, en su parte 8,un Modelo de evaluacion de procesos para los procesos de servicios TIC que seran defi-nidos en el estandar ISO 20000-4 que definira los procesos contenidos en la norma ISO20000-1. Equivalencia y compatibilidad con CMMI. ISO forma parte del panel elabora-dor del modelo CMMI y SEI mantiene la compatibilidad y equivalencia de esta ultimacon 15504. [12]

Marco Conceptual

Los sistemas de gestion estan pensados para apoyar la gestion de procesos de unaorganizacion y tienen como objetivo establecer y alcanzar unos indicadores previamen-te definidos por la direccion. Las organizaciones que tiene sistematizados sus procesoso cuentan con software que apoya dicha labor obtienen ventajas sobre sus competido-res directos, dado que pueden evidenciar las fortalezas o debilidades que presentan endeterminado momento y basados en la informacion que se provee a la direccion, la or-ganizacion puede tomar decisiones estrategicas frente el mercado cambiante.

1.6 M E T O D O L O G I A D E L A I N V E S T I G A C I O N 25

Las normas ISO se constituyen en una serie de estandares que se pueden agrupar porfamilias, segun los distintos aspectos relacionados con la calidad. Aunque existen masde 18.000 normas publicadas por ISO, se pueden clasificar las normas segun el siguientecriterio, normas relacionadas directamente con la calidad, normas relacionadas con lacalidad en el medio ambiente y sostenibilidad, normas relacionadas con la gestion de laseguridad y normas relacionadas con la calidad en la investigacion y desarrollo.[9]

Marco Espacial

El objetivo de este proceso investigativo es apoyar a las mi pymes que desarrollanproductos de software en la ciudad de Bogota, para que basado en el resultado dela propuesta metodologica se mejore el proceso de implementacion de desarrollo desoftware y mejoren sus procesos internos.

Marco Historico

Dıa a dıa las companıas en general buscan como optimizar los procesos y los resul-tados financieros para mitigar los gastos, los sobrecostos e incrementar la rentabilidad,basado en esto se busca por medio de este proceso investigativo apoyar dicha labor yoptimizar el uso de los recursos fısicos, financieros y del mismo capital humano.

Marco Legal

Este proceso investigativo directamente no esta enmarcado en un ambito legal, pe-ro si puede mitigar o subsanar el incumplimiento de algunas clausulas contractualesasociadas al aseguramiento de la calidad que pueden llegarse a presentarse durante laejecucion de un proyecto de implementacion de un producto de software.

1.6 M E T O D O L O G I A D E L A I N V E S T I G A C I O N

Tipo de Estudio

El tipo de estudio que se va a emplear en este proceso investigativo va a ser experi-mental, dado que se busca construir una personalizacion metodologica para el asegura-miento de la calidad del software implementado por mi pymes, y por lo mismo se debetomar como base lo existente y lo recomendado por las normas ISO, lo implementadopor otras companıas, las buenas practicas acogidas a nivel mundial y engranar todo loanterior para proyectarlo y hacerlo encajar con las especificaciones metodologicas delmas bajo nivel posible para obtener el resultado esperado.


Metodo de Investigacion

El holotipo de investigacion a utilizar es proyectivo con un nivel comprensivo, lo cualimplica encontrar una relacion con todos los factores inmersos en este proceso investi-gativo, enfatizando las relaciones de causalidad, y teniendo como objetivo la propuestametodologica.

Fuentes y Tecnicas para la recoleccion de la Informacion

En este proceso investigativo se van a utilizar las fuentes de informacion primaria ysecundaria, dado que se debe recoger informacion sobre el objeto de estudio, la cual yaexiste y ha sido definida a nivel mundial, incluyendo la resultante de otros procesos in-vestigativo y demas propuestas metodologicas ya implementadas, adicional a lo anteriorse debe adicionar la informacion que se debe recolectar por medio de entrevistas quenos permitan identificar puntos de analisis para general una propuesta metodologicaintegral o que contemple varios escenarios que hoy en dıa impactan los proyectos.

Tratamiento de la Informacion

El tratamiento que se le dara a la informacion sera analıtico, dado que se debe realizarun estudio a la informacion suministrada por companıas del sector de forma tal que seencuentren los puntos crıticos que impactan no solo al cliente sino a la misma mi pyme.Esto debido a que el concepto Calidad es subjetivo y cada proveedor de software ycliente lo puede interpretar desde un punto de vista diferente.

1.7 O R G A N I Z A C I O N D E L T R A B A J O D E G R A D O

La organizacion del trabajo de grado esta delimitada por la fase de contextualizacion,en donde se determinan todos los aspectos del planteamiento del problema y los me-canismos para dar solucion a la problematica; seguida de la parte del desarrollo de lainvestigacion, en donde se detalla la fase de arquitectura y diseno de la solucion tec-nologica; y por ultimo la fase final, donde se relacionan las reflexiones resultantes delmismo, lo cual todo depende en gran medida de la informacion suministrada por laspymes para analizar los puntos que requieren mejora o una reestructuracion bien seanivel del proceso o a nivel de la metodologıa utilizada segun sea el caso.

1.8 E S T U D I O D E S I S T E M A S P R E V I O S

Se realizo el estudio previo a dos mi pymes, las cuales se dedican a realizar imple-mentaciones de software a diferentes tipos de clientes y mercados, encontrando allı quecada una de las organizaciones enfoca sus esfuerzos en entregar un software de calidada sus clientes, pero gestionando diferentes indicadores.

Parte II

A R Q U I T E C T U R A Y D I S E N O

2

O R G A N I Z A C I O N

2.1 E M P R E S A

En el ano de 1999 en la ciudad de Bogota se constituyo Consult Soft Ltda, la cual des-de sus inicios se forjo como una empresa de desarrollo de Software a la medida sobretecnologıa Oracle, por lo mismo con el tiempo se certifico como partner Oracle, ası pocoa poco y gracias al trabajo y a la dedicacion de sus fundadores, Consult Soft empezo acrecer para consolidarse en una de las empresas con un posicionamiento relevante enel mercado, no solo del sector privado sino tambien en el sector publico.

Es ası como se inicio la lınea de consultorıa especializada, contratando y desarrollan-do el talento humando en areas como la arquitectura de aplicaciones, la administracionde bases de datos, el afinamiento de aplicaciones y la implantacion y configuracion deservidores de aplicaciones.

Esto ultimo permitio que a la companıa llegaran nuevos inversionistas, quienes despuesde un tiempo finalmente adquirieron la companıa en su totalidad. Gracias a la buenagestion que realizaron los nuevos duenos, se logro una alianza con la multinacional deorigen espanol Efron Consulting, lo cual genero el cambio de razon social a Efron Co-lombia S.A.S., y bajo este nuevo nombre se han comprado otras companıas nacionalesque han permitido diversificar las lıneas de servicio de la empresa.

En la actualidad se presenta una dificultad en el momento de la entrega de los produc-tos de software a los usuarios funcionales, dado que no siempre se cumple con todaslas especificaciones que requieren y/o que esperan recibir los mismos, lo cual no sologenera insatisfaccion al grupo de trabajo tanto de cara al cliente como del proveedorde software, sino tambien genera sobrecostos al proyecto, retrasos en los tiempos deentrega, reduccion en los indicadores de calidad del proyecto, y mala imagen de loscolaboradores involucrados hacia al cliente y hacia la companıa que provee los servicios

29

30 O R G A N I Z A C I O N

de software.

Figura 1: Efron Consulting[4]

2.1.1 Mision

Soportada por mas de 800 empleados a traves de Europa, LatinoAmerica y los EstadosUnidos, nuestra mision es ayudar a nuestros clientes a cumplir sus metas haciendolosmas competitivos a traves del cumplimiento de la excelencia en TI. Como consultoresTI y asesores contables, nos enorgullecemos en escuchar a nuestros clientes para poderidentificar necesidades y ofrecer soluciones de necesidad especıfica. Estamos orgullososde saber que 500 empresas de Fortune’s Global nos confıan proyectos que impactan de-cenas de miles, sino millones, de sus clientes alrededor del mundo.

2.1.2 Vision

En el ano 2020, EFRON sera reconocida por sus clientes como una companıa eficazen la entrega de productos y servicios tecnologicos en el mercado global, facilitando deesta manera que se desarrollen relaciones a largo plazo y siendo percibidos por nuestrosclientes como aliados estrategicos de negocios tecnologicos.

Contaremos con colaboradores motivados y orientados al logro de objetivos, quienestendran las competencias necesarias para ser considerados como consultores de nego-cios, lo cual permitira diferenciarnos de la competencia.

Ası mismo, para el ano 2022 EFRON posicionara sus productos, entregando solucio-nes confiables y flexibles a sus clientes, lo que les permitira adaptar sus negocios a lascondiciones cambiantes del mercado.

2.1.3 Objetivos de Calidad

− Incrementar la satisfaccion de nuestros clientes.

2.1 E M P R E S A 31

− Cumplir los requisitos establecidos por el cliente.

− Cumplir las metas establecidas para ventas y rentabilidad de la organizacion.

− Mejorar el clima organizacional.

− Incursionar en nuevos mercados.

− Mejorar las competencias del personal de la organizacion.

− Mejorar el Sistema de Gestion de Calidad.

2.1.4 Objetivos de la Organizacion

− Desarrollar soluciones de software capases de resolver las necesidades de nuestrosclientes.

− Brindar servicios de consultorıa y soporte optimos que promuevan el buen desem-peno de la organizacion de nuestros clientes.[2]

3

FA S E D E A R Q U I T E C T U R A D E N E G O C I O S

La fase de arquitectura de negocios tiene una correspondencia con la capa de nego-cios donde se hace referencia a la estructura estatica de una organizacion, en terminosde entidades que componen la organizacion y sus relaciones. Las entidades activas sonlos sujetos como por ejemplo actores del negocio o roles del negocio, que ejecutan proce-sos de negocio o funciones. Los actores del negocio pueden ser individuos pero tambiengrupos y recursos que permanecen a traves de la organizacion. Las entidades pasivasson los objetos de negocio que son manipulados por algun comportamiento tal como unproceso de negocio o una funcion y representan los conceptos importantes en los cualesla empresa piensa en un ambito.[7]

La mejora forma de interpretar los diferentes componentes a evaluar en la capa denegocios se pueden resumir en el siguiente cuadro resumen de los conceptos:

Cuadro 1: Conceptos Capa de NegocioConcepto Descripcion Notacion

Actor de NegocioEntidad organizacional que es capazde comportamiento de ejecucion

Rol de Negocio

Responsabilidad de realizar accionesespecıficas segun su comportamiento,ante el cual un actor puede ser asigna-do

Colaboracion deNegocio

Agregado de dos o mas roles de nego-cio que trabajan juntos para realizarcomportamiento colectivo.

33

34 F A S E D E A R Q U I T E C T U R A D E N E G O C I O S


Interfaz de Nego-cio

Un punto de acceso donde un serviciocomercial esta disponible para el me-dio ambiente.

LocalizacionUn punto o extension conceptual en elespacio.

Objeto de NegocioUn elemento pasivo que tiene relevan-cia de una perspectiva comercial.

Proceso de Nego-cio

Un elemento de comportamiento queagrupa el comportamiento basado enun orden de actividades. Es destina-do a producir un conjunto definido deproductos o servicios comerciales.

Funcion de Nego-cio

Un elemento de comportamiento queagrupa el comportamiento basado enun conjunto de criterios elegidos (tıpi-camente recursos comerciales requeri-dos y / o competencias).

Interaccion de Ne-gocio

Un elemento de comportamiento quedescribe la comportamiento de una co-laboracion empresarial.

Evento de NegocioAlgo que sucede (internamente o ex-ternamente) e influye en el comporta-miento.

Servicio de Nego-cio

Un servicio que satisface una necesi-dad comercial de un cliente (internoo externo al organizacion).

RepresentacionUna forma perceptible de la informa-cion llevado por un objeto comercial.

Meaning

El conocimiento o experiencia presen-te en un objeto comercial o su repre-sentacion, dado un contexto particu-lar.

3.1 P U N T O D E V I S TA D E O R G A N I Z A C I O N 35


ValorEl valor relativo, la utilidad o la im-portancia de un servicio o producto co-mercial.

Producto

Una coleccion coherente de servicios,acompanado de un contrato / conjun-to de acuerdos, que se ofrece en suconjunto para (internos o externos)clientes.

Contrato

Una especificacion formal o informalde acuerdo que especifica los derechosy obligaciones asociadas con un pro-ducto.

3.1 P U N T O D E V I S TA D E O R G A N I Z A C I O N

3.1.1 Metamodelo

Este punto de vista se enfoca en la organizacion interna de una companıa, un depar-tamento, una red de companıas o cualquier otra entidad organizacional. En este puntode vista es posible presentar modelos como diagramas de bloques anidados, o tambien,en una forma mas tradicional como los organigramas. El punto de vista de organizaciones muy util en la identificacion de competencias, autoridad y responsabilidades en unaorganizacion.

Figura 2: Punto de Vista de Organizacion[7, 3]


3.1.2 Modelo

EFRON es una companıa que enfoca sus esfuerzos en las instalaciones del cliente atraves de un consultor que reporta a un Director General y quien compone la Oficina deGerencia de Proyectos (PMO por sus siglas en ingles).

Figura 3: Modelo de Organizacion. Fuente: Autor

3.2 P U N T O D E V I S TA D E C O O P E R A C I O N D E A C T O R

3.2.1 Metamodelo

El punto de vista de cooperacion del actor se enfoca en la relacion que tienen losactores entre si y de estos con su entorno. Un ejemplo comun de esto es el diagramade contexto, el cual ubica una organizacion en su ambiente, que consiste en las partesexternas tales como clientes, proveedores y otros aliados de negocio. Es muy util a lahora de determinar dependencias y colaboraciones externas, y muestra la cadena devalor o la red en la que el actor opera.

3.2 P U N T O D E V I S TA D E C O O P E R A C I O N D E A C T O R 37

Otro uso importante del punto de vista de cooperacion de actor es mostrar como unnumero de actores de negocio cooperantes y/o componentes de aplicacion realizan jun-tos un proceso de negocio. Por lo tanto, en esta vista, tanto actores de negocio comoroles y componentes de aplicacion pueden aparecer.

Figura 4: Punto de Vista de Cooperacion de Actor[7, 3]

3.2.2 Modelo

En el levantamiento de requerimientos logramos identificar que la especificacion delproyecto y los lineamientos de calidad son los puntos convergentes entre el consultor yel director regional, y entre este y la PMO respectivamente. Aplicados en el proceso elcliente va a ser requerido para entrevistas, reuniones y teleconferencias.


Figura 5: Modelo de Cooperacion de Actor. Fuente: Autor

3.3 P U N T O D E V I S TA D E F U N C I O N D E N E G O C I O

3.3.1 Metamodelo

El punto de vista de funcion de negocio muestra las funciones de negocio principalesde una organizacion y sus relaciones en terminos de flujo de informacion, valor o bienesentre ellos. Las funciones de negocio son usadas para representar los aspectos masestables de una companıa en terminos de las actividades primarias que esta desempena,a pesar de los cambios organizacionales o los desarrollos tecnologicos. Por lo tanto laarquitectura de funcion de negocio de companıas que operan en el mismo mercadoa menudo exhibe mucha similaridad. De esta forma el punto de vista de funcion denegocio provee informacion de alto nivel en las operaciones generales de la companıa,

3.3 P U N T O D E V I S TA D E F U N C I O N D E N E G O C I O 39

y puede ser usada para identificar las competencias necesarias o para estructurar unaorganizacion de acuerdo a sus actividades principales.

Figura 6: Punto de Vista de Funcion de Negocio[7, 3]

3.3.2 Modelo

Para el proceso de levantamiento de requerimientos en EFRON se reconocen dos rolesfundamentales, el director general y el consultor, donde el director es un especialista engerencia de proyectos el cual tiene como funciones del proceso el estimar y analizar cos-tos de los proyectos, asignar consultores y recursos fısicos, transmitir los lineamientosde calidad que la PMO ha determinado aplicar al proyecto, realizar seguimiento de laejecucion, gestionar pagos y cierre del proyecto. A su vez el consultor que es un ingenie-ro de sistemas, debe aplicar los lineamientos de calidad para el levantamiento y analisisde los requerimientos para luego elevar las inquietudes y sugerir mejoras del procesoal cliente, documentar los requerimientos depurados y gestionar la aprobacion del re-querimiento para pasarlo a la siguiente fase dentro de EFRON para el desarrollo desoftware a la medida; es importante resaltar que el consultor se encuentra en constanteretroalimentacion con el director regional como parte del seguimiento del proyecto.


Figura 7: Modelo de Funcion de Negocio. Fuente: Autor

3.4 P U N T O D E V I S TA D E P R O C E S O D E N E G O C I O 41

3.4 P U N T O D E V I S TA D E P R O C E S O D E N E G O C I O

3.4.1 Metamodelo

El punto de vista de proceso de negocio es usado para mostrar la estructura de altonivel y la composicion de uno o mas procesos de negocio. Junto a los procesos como tal,este punto de vista contiene otros conceptos directamente relacionados, tales como:

− Los servicios que un proceso de negocio ofrece al mundo exterior, mostrando comoun proceso contribuye a la realizacion de los productos de la companıa.

− La asignacion de procesos de negocio a roles que le dan significado a las responsa-bilidades de los actores asociados.

− La informacion usada por los procesos de negocio.

Cada uno de estos puede ser entendido como un subproceso de la vista de proceso denegocio.

Figura 8: Punto de Vista de Proceso de negocio[7, 3]


3.4.2 Modelo

Las diferentes solicitudes de mejora a sus procesos de negocio que realizan los clientesa EFRON son cubiertas por el servicio de levantamiento de requerimientos. Ese proce-so tiene como lineamiento corporativo la calidad y la busqueda de la satisfaccion delcliente lo cual conlleva los procesos de analisis del problema, sugerencias de mejora ydocumentacion del problema. El consultor durante el proceso puede recibir el apoyo delgerente regional en cualquier momento que sea requerido para encontrar otros puntosde vista que puedan ayudar a la resolucion del problema y que ası se pueda constituirun documento de requerimientos de alta calidad.

Figura 9: Modelo de Proceso de Negocio. Fuente: Autor

3.5 P U N T O D E V I S TA D E C O O P E R A C I O N D E P R O C E S O D E N E G O C I O

3.5.1 Metamodelo

El punto de vista de cooperacion de proceso de negocio es usado para mostrar lasrelaciones de uno o mas procesos de negocio con los demas procesos de negocio y / o

3.5 P U N T O D E V I S TA D E C O O P E R A C I O N D E P R O C E S O D E N E G O C I O 43

con su ambiente. Puede ser usado tanto para crear un diseno de alto nivel de procesosde negocio dentro de su contexto como para proveer un responsable administradoroperacional para uno o mas de tales procesos con mando en sus dependencias. Sonaspectos importantes del punto de vista de cooperacion de procesos de negocio:

− Relacion causal entre los principales procesos de negocio de la empresa.

− Mapeo de los procesos de negocio a las funciones de negocio.

− Realizacion de servicios por procesos de negocio.

− Uso de datos compartidos.

Cada uno de estos puede ser considerado como una ”sub-vista”de la vista de coopera-cion de procesos de negocio.

Figura 10: Punto de Vista de Cooperacion de Proceso de Negocio[7, 3]


3.5.2 Modelo

En el proceso de levantamiento de requerimientos es clave para el exito trabajar dela mano del cliente para logara el documento de requerimientos. Sin esa colaboracionde los diferentes actores del proceso de negocio del cliente no sera un documento com-pleto y puede que termine retrasando la fase de desarrollo de software. Es por eso queinsistimos en la interaccion entre EFRON y el cliente.

Figura 11: Modelo de Cooperacion de Proceso de Negocio. Fuente: Autor

3.6 P U N T O D E V I S TA D E P R O D U C T O

3.6.1 Metamodelo

El punto de vista del producto muestra el valor que estos productos ofrecen a losclientes u otras partes externas involucradas y muestra la composicion de uno o masproductos en terminos de sus servicios constituyentes (aplicacion o negocios) y los con-tratos asociados u otros acuerdos. Tambien puede ser usado para mostrar las interfaces(canales) a traves de los cuales este producto es ofrecido, y los eventos asociados con elproducto. El punto de vista del producto es tıpicamente usado en el desarrollo de pro-ducto para disenar un producto por composicion de servicios ofrecidos o identificandocuales servicios nuevos tienen que ser creados para este producto, dado el valor que uncliente espera de este. Puede entonces servir como entrada para arquitectos de proce-

3.6 P U N T O D E V I S TA D E P R O D U C T O 45

sos de negocio y otros que necesitan disenar los procesos e igualmente realizar estosproductos.

Figura 12: Punto de Vista de Producto[7, 3]

3.6.2 Modelo

Para el consultor de EFRON prestar los servicios de entendimiento y analisis del pro-blema y la retroalimentacion y sugerencias del problema de forma correcta constituyenun documento de requerimientos bajo estandares de calidad como producto o materiaprima para el desarrollo de software a la medida. Es sumamente importante el momen-to en que se da la retroalimentacion del gerente regional al proceso de levantamientode requerimientos porque puede ayudar a dilucidar soluciones o mejoras lo cual es con-siderado una oferta de valor para el cliente en el producto terminado, y que al tener


alta la satisfaccion del cliente se facilita la elaboracion y consecucion del contrato deacuerdo de pagos.

Figura 13: Modelo de Producto. Fuente: Autor

4

FA S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I O N

La fase de arquitectura de sistemas de informacion tiene una correspondencia conla capa de aplicacion en donde el principal concepto de estructura activa es el compo-nente de aplicacion. Este concepto es usado para modelar cualquier entidad estructuralcomo son componentes de software que pueden ser parte de una o mas aplicaciones,aplicaciones completas, sub-aplicaciones o sistemas de informacion. Los componentesinter-relacionados son un ingrediente esencial, por eso es que se introduce el conceptode colaboracion de aplicacion definido por un colectivo de componentes los cuales eje-cutan aplicaciones. [7]

Veamos los componentes de la capa de aplicacion en la siguiente imagen:

Cuadro 2: Conceptos Capa de AplicacionConcepto Descripcion Notacion

Componentede Aplicacion

Una parte modular, implementable yreemplazable de un sistema de softwa-re que encapsula su comportamiento ydatos y los expone a traves de un con-junto de interfaces.

Colaboracionde Aplicacio-nes

Un agregado de dos o mas componen-tes de aplicacion que trabajan juntospara realizar un comportamiento co-lectivo.

47

48 F A S E D E A R Q U I T E C T U R A D E S I S T E M A S D E I N F O R M A C I O N

Cuadro 2: Conceptos Capa de AplicacionConcepto Descripcion Notacion

Interfaz deAplicacion

Un punto de acceso donde un serviciode aplicacion esta disponible para unusuario u otro componente de aplica-cion.

Objeto de Da-tos

Un elemento pasivo adecuado para elprocesamiento automatizado..

Funcion deAplicacion

Un elemento de comportamiento queagrupa el comportamiento automati-zado que puede realizar un componen-te de la aplicacion.

Interaccionde Aplicacio-nes

Un elemento de comportamiento quedescribe el comportamiento de una co-laboracion de aplicaciones.

Servicio deAplicacion

Un servicio que expone el comporta-miento automatizado.

4.1 P U N T O D E V I S TA D E U S O D E L A A P L I C A C I O N

4.1.1 Metamodelo

El punto de vista de uso de aplicacion describe como las aplicaciones son usadas parasoportar uno o mas procesos de negocio, y como ellos son usados por otras aplicaciones.Puede ser usado en el diseno de una aplicacion para identificar los servicios requeridospor los procesos de negocios y otras aplicaciones, o en el diseno de procesos de negociopara describir los servicios que estan disponibles. Ası, al identificar las dependencias de

4.1 P U N T O D E V I S TA D E U S O D E L A A P L I C A C I O N 49

los procesos de negocio sobre las aplicaciones, puede ser util para los administradoresoperativos responsables de estos procesos.

Figura 14: Punto de Vista de Uso de Aplicacion[7, 3]

4.1.2 Modelo

El proceso de levantamiento de requerimientos y su producto el documento de re-querimientos deberıan ser soportados por un servicio de software de Gestion de Re-querimientos el cual es soportado por el componente del gestor de requerimientos. Eldocumento de requerimientos es soportado por el reporte del levantamiento de reque-rimientos que se extrae del software.


Figura 15: Modelo de Uso de Aplicacion. Fuente: Autor

4.2 P U N T O D E V I S TA D E C O M P O RTA M I E N T O D E L A A P L I C A C I O N

4.2.1 Metamodelo

El punto de vista de comportamiento de aplicacion describe el comportamiento in-terno de una aplicacion. Por ejemplo, de que forma se realizan uno o mas servicios deaplicacion. Este punto de vista es util en el diseno del comportamiento general de aplica-ciones, o en la identificacion de interferencias funcionales entre diferentes aplicaciones.

4.2 P U N T O D E V I S TA D E C O M P O RTA M I E N T O D E L A A P L I C A C I O N 51

Figura 16: Punto de Vista de Comportamiento de Aplicacion[7, 3]

4.2.2 Modelo

Un software de gestion de requerimientos debe permitir gestionar las precondicionesde los requerimientos, gestionar las post condiciones de los requerimientos, gestionarlos criterios de aceptacion de los requerimientos, generar reportes y por supuesto y degran importancia la gestion en sı de los requerimientos. Cabe destacar que la generacionde reportes debe permitir generar un documento con los criterios de aceptacion y eldocumento de levantamiento de informacion como producto para la fase de desarrollode software.


Figura 17: Modelo de Comportamiento de Aplicacion. Fuente: Autor

4.3 P U N T O D E V I S TA D E C O O P E R A C I O N D E L A A P L I C A C I O N

4.3.1 Metamodelo

El punto de vista de cooperacion de aplicacion describe las relaciones entre los compo-nentes de aplicacion en terminos de la informacion que fluye entre ellos, o en terminosde los servicios que ellos ofrecen y usan. Este punto de vista es tıpicamente usado paracrear una vista general del panorama de aplicaciones en una organizacion. Tambien es

4.3 P U N T O D E V I S TA D E C O O P E R A C I O N D E L A A P L I C A C I O N 53

usado para expresar la cooperacion (interna) o la orquestacion de servicios que unidossoportan la ejecucion de un proceso de negocio.

Figura 18: Punto de Vista de Cooperacion de Aplicacion[7, 3]

4.3.2 Modelo

Adentrandonos una capa mas abajo en el modelo del software encontramos un backoffice que debe soportar el componente del gestor de requerimientos del cual destaca-mos el servicio de generacion de reportes en el front office de la aplicacion ya que vaa ser la funcionalidad que nos va permitir obtener el documento de levantamiento deinformacion y el documento de criterios de aceptacion a traves de una interfaz graficade usuario.


Figura 19: Modelo de Cooperacion de Aplicacion. Fuente: Autor

4.4 P U N T O D E V I S TA D E E S T R U C T U R A D E L A A P L I C A C I O N

4.4.1 Metamodelo

El punto de vista de estructura de aplicacion presenta la estructura de una o mas apli-caciones o componentes. Es util en el diseno o entendimiento de la estructura principalde las aplicaciones o componentes y de la informacion asociada; por ejemplo, para de-tallar la estructura de un sistema bajo construccion, o para identificar componentes deaplicaciones obsoletas que son apropiados para migracion / integracion.

4.4 P U N T O D E V I S TA D E E S T R U C T U R A D E L A A P L I C A C I O N 55

Figura 20: Punto de Vista de Estructura de Aplicacion[7, 3]

4.4.2 Modelo

El componente de gestion de requerimientos debe poder basar la informacion de losdocumentos de levantamiento de informacion y criterios de aceptacion en una cargamasiva de informacion en un momento o varios momentos particulares de cada procesode levantamiento de requerimientos. Dicha colaboracion va permitir integrar archivosplanos que los ingenieros pueden llegar a usa en situaciones donde la interfaz de laaplicacion no sea usada.

Figura 21: Modelo de Estructura de Aplicacion. Fuente: Autor

5

FA S E D E A R Q U I T E C T U R A D E T E C N O L O G I A

La fase de arquitectura de tecnologıa es correspondiente con la capa de tecnologıa enla cual el nodo es usado para modelar entidades estructurales de un sistema; su compor-tamiento es modelado por una relacion explicita entre los conceptos de comportamiento.Tambien contamos con una interface de infraestructura la cual es una locacion logicadonde los servicios de infraestructura son ofrecidos por un nodo que se accesara porotros nodos o componentes de aplicaciones desde la capa de aplicacion.

Los nodos pueden ser de dos tipos, dispositivo y sistema de software, donde el dis-positivo modela un recurso computacional fısico sobre el cual los artefactos pueden serdesplegados para ejecucion. Por otro lado el sistema de software es un componente quecorre en un dispositivo. Las interrelaciones de componentes en la capa tecnologica sonprincipalmente formadas por la infraestructura de comunicaciones, la cual modela lasrelaciones entre 2 o mas nodos, a traves de los cuales hay constante intercambio deinformacion.[7]

Todo esto lo podemos modelar con los siguientes conceptos resumidos:

Cuadro 3: Conceptos Capa de TecnologıaConcepto Descripcion Notacion

NodoUn recurso computacional sobre elcual artefactos pueden ser almacena-dos o desplegados para ejecucion.

DispositivoUn recurso de hardware sobre el cuallos artefactos pueden ser almacenadoo desplegado para su ejecucion.

57

58 F A S E D E A R Q U I T E C T U R A D E T E C N O L O G I A

Cuadro 3: Conceptos Capa de TecnologıaConcepto Descripcion Notacion

NetworkUn medio de comunicacion entre doso mas dispositivos..

Ruta de co-municacion

Un enlace entre dos o mas nodos, atraves del cual estos nodos pueden in-tercambiar datos.

Interfaz de In-fraestructura

Un punto de acceso al que otros nodosy componentes de la aplicacion pue-den acceder a servicios de infraestruc-tura ofrecidos por un nodo.

Software delSistema

Un entorno de software para tipos es-pecıficos de componentes y objetosque se implementan en el en forma deartefactos..

Funcion de In-fraestructura

Un elemento de comportamiento queagrupa el comportamiento infraestruc-tural que puede realizar un nodo.

Servicio de In-fraestructura

Una unidad de funcionalidad externa-mente visible, proporcionada por unoo mas nodos, expuesta a traves de in-terfaces bien definidas y significativapara el entorno.

Artefacto

Una pieza fısica de datos que se utilizao produce en un proceso de desarrollode software, o mediante el desplieguey la operacion de un sistema.

5.1 P U N T O D E V I S TA D E I N F R A E S T R U C T U R A

5.1.1 Metamodelo

El punto de vista de infraestructura contiene los elementos de infraestructura de soft-ware y hardware que soportan la capa de aplicacion, tales como dispositivos fısicos,

5.1 P U N T O D E V I S TA D E I N F R A E S T R U C T U R A 59

redes o sistemas de software (por ejemplo, sistemas operativos, bases de datos y softwa-re de capa media).

Figura 22: Punto de Vista de Infraestructura[7, 3]

5.1.2 Modelo

Por lineamientos corporativos de EFRON, la aplicacion Gestor de requerimientos de-berıa ser desarrollada para correr sobre sistema operativo Linux y la base de datos debeser Oracle. La forma como vamos a llegar la aplicacion a la nube es a traves del servidorde aplicaciones Oracle WebLogic y todo esto en el hosting contratado por EFRON paralas soluciones internas y en el que soportan las aplicaciones de clientes cuando ellos re-quieren la tercerizacion del servicio o que la solucion sea integral como Software comoservicio.


Figura 23: Modelo de Infraestructura. Fuente: Autor

5.2 P U N T O D E V I S TA D E U S O D E I N F R A E S T R U C T U R A

5.2.1 Metamodelo

El punto de vista de uso de la infraestructura muestra como las aplicaciones estan so-portadas por el software y hardware de infraestructura: los servicios de infraestructurason despachados por los dispositivos; los sistemas de software y las redes son provistosa las aplicaciones. Este punto de vista juega un rol importante en el analisis de desem-peno y escalabilidad, ya que relaciona la infraestructura fısica al mundo logico de lasaplicaciones. Es muy util en determinar los requerimientos de desempeno y calidad dela infraestructura basada en las demandas de las muchas aplicaciones que la usan.

5.2 P U N T O D E V I S TA D E U S O D E I N F R A E S T R U C T U R A 61

Figura 24: Punto de Vista de Uso de Infraestructura[7, 3]

5.2.2 Modelo

El componente gestor de requerimientos es usado por el servidor de aplicacionesOracle WebLogic del cual es importante resaltar como se especializa en la base de datosde Oracle en la cual se van a convertir todos los requerimientos en data estructuradagracias al correcto diligenciamiento por el consultor.


Figura 25: Modelo de Uso de Infraestructura. Fuente: Autor

5.3 P U N T O D E V I S TA D E O R G A N I Z A C I O N E I M P L E M E N TA C I O N

5.3.1 Metamodelo

El punto de vista de organizacion e implementacion muestra como una o mas apli-caciones son realizadas sobre la infraestructura. Esto comprende la asignacion de apli-caciones (logicas) y componentes en artefactos (fısicas), como Enterprise Java Beans,y el mapeo de la informacion utilizada por estas aplicaciones y componentes en la in-fraestructura de almacenamiento subyacente; por ejemplo, las tablas de las bases dedatos o sus archivos. Las vistas de despliegue juegan un papel importante en el analisisde desempeno y escalabilidad, ya que relaciona la infraestructura fısica con el mundologico de las aplicaciones. En analisis de seguridad y riesgos, las vistas de despliegueson usadas para identificar, por ejemplo, las dependencias crıticas y los riesgos.

5.3 P U N T O D E V I S TA D E O R G A N I Z A C I O N E I M P L E M E N TA C I O N 63

Figura 26: Punto de Vista de Organizacion e Implementacion[7, 3]

5.3.2 Modelo

El modelo de organizacion e implementacion nos muestra un componente gestor derequerimientos usado por el servidor de aplicaciones Oracle WebLogic para exponer elservicio de administracion de requerimientos al consultor y orquestar los contenidos yestructurar las plantillas del documento de levantamiento de informacion y los criteriosde aceptacion; recordemos que en el momento que sea requerido por el consultor, elpuede hacer una carga masiva de informacion.


Figura 27: Modelo de Organizacion e Implementacion. Fuente: Autor

5.4 P U N T O D E V I S TA D E E S T R U C T U R A D E I N F O R M A C I O N

5.4.1 Metamodelo

El punto de vista de estructura de la informacion es comparable con los modelostradicionales creados en el desarrollo de casi cualquier sistema de informacion. Muestrala estructura de la informacion usada en la empresa o en un proceso de negocio oaplicacion especıfica, en terminos de tipos de datos o estructuras de clases. Ası, estepunto de vista puede mostrar como la informacion del nivel de negocio es representadaen el nivel de aplicacion en terminos de las estructuras de datos usadas allı, y como

5.4 P U N T O D E V I S TA D E E S T R U C T U R A D E I N F O R M A C I O N 65

estas son luego mapeadas hacia la infraestructura subyacente.; por ejemplo, por mediode un esquema de base de datos.

Figura 28: Punto de Vista de Estructura de Informacion[7, 3]

5.4.2 Modelo

Para logra representar la necesidad del cliente y los lineamientos de calidad es ne-cesario definir un objeto de datos llamado requerimiento y otro llamado criterio deaceptacion respectivamente en la capa de software. Dicho requerimiento compone unatabla de la base de datos llamada modulo la cual entrega informacion al proyecto. Estea su vez es alimentado por la informacion del objeto de datos cliente, completando asıtoda la estructura del modelo de la base de datos de forma muy abstracta o de altonivel.


Figura 29: Modelo de Estructura de Informacion. Fuente: Autor

5.5 P U N T O D E V I S TA D E R E A L I Z A C I O N D E L S E RV I C I O

5.5.1 Metamodelo

El punto de vista de realizacion del servicio es usado para mostrar como uno o masservicios de negocio son realizados por los procesos subyacentes (y algunas veces porcomponentes de aplicacion). Ası, se forma el puente entre el punto de vista de producto

5.5 P U N T O D E V I S TA D E R E A L I Z A C I O N D E L S E RV I C I O 67

de negocio y la vista de proceso de negocio. Proporciona una ”vista desde afuera”sobreuno o mas procesos de negocio.

Figura 30: Punto de Vista de Realizacion del Servicio[7, 3]

5.5.2 Modelo

En EFRON la satisfaccion de los clientes es fundamental y la forma como se logra esa traves de la calidad del servicio, y es por eso que en el servicio de levantamiento derequerimientos se contemplan 2 objetos de negocio fundamentales para realizar dichoservicio y son la necesidad del cliente y los lineamientos de calidad los cuales van a serparte fundamental de la aplicacion de gestion de requerimientos constituyendose comotablas de la base de datos para poder gestionar esa informacion de forma eficiente.


Figura 31: Modelo de Realizacion del Servicio. Fuente: Autor

5.6 P U N T O D E V I S TA D E C A PA S

5.6.1 Metamodelo

El punto de vista de capas muestra varias capas y aspectos de una arquitectura em-presarial en un diagrama. Hay dos categorıas de capas, las llamadas capas dedicadasy las llamadas capas de servicio. Las capas son el resultado del uso de la relacion de“agrupamiento”para una division natural del conjunto entero de objetos y relacionesque hacen parte de un modelo. La capa de infraestructura, la de aplicacion, la de proce-so y la de actores/roles conforman la primera categorıa. El principio estructural detrasde un punto de vista completamente de capas es que cada capa dedicada expone, pormedio de la relacion de “realizacion”, una capa de servicios que son mas bien “usadaspor”la siguiente capa dedicada. Ası, podemos facilmente separar la estructura interna yla organizacion de una capa dedicada de su comportamiento externamente observableexpresado como la capa de servicio que la capa dedicada realiza.

5.6 P U N T O D E V I S TA D E C A PA S 69

Figura 32: Punto de Vista de Capas[7, 3]

5.6.2 Modelo

En resumen, el servicio de levantamiento de requerimientos con calidad para incre-mentar la satisfaccion del cliente es realizado por el proceso del levantamiento de re-querimientos el cual se desarrolla a un nivel de negocio, el cual genera la necesidadde controlar y gestionar dicho proceso a traves de un gestor de requerimientos en unaplataforma web, para lo cual es necesario soportar desde un servidor de aplicacionesOracle WebLogic.


Figura 33: Modelo de Capas. Fuente: Autor

6

FA S E D E V I S I O N D E A R Q U I T E C T U R A

Los principales conceptos de ArchiMate se enfocan en describir la arquitectura de lossistemas que soportan a las empresas. Sin tener en cuenta estan los elementos que moti-van el diseno y la operacion de la empresa. Estos aspectos motivacionales correspondenal ¿Por que?, el cual fue intencionalmente dejado por fuera del alcance en el diseno deArchiMate 1.0. Los conceptos motivacionales tales como objetivos, principios y requeri-mientos estan direccionados de forma tal que la arquitectura empresarial es alineada aese contexto y descrita por elementos motivacionales.

Un elemento motivacional es definido como un elemento que provee el contexto o razonque esta detras de la arquitectura de una empresa, ademas que reconoce los conceptosde los Implicados (Stakeholder), lineamientos (driver/manejador) y valoraciones. LosStakeholders representan las personas u organizaciones que influencian, guıan o res-tringen a las empresas. Los lineamientos representan los factores internos y externosque influencian los planes y objetivos de las empresas. El entendimiento de las fortale-zas, debilidades, oportunidades y amenazas en relacion a los lineamientos ayudan a laformacion de planes y objetivos que apropiadamente se direccionan a esos factores.[7]

Cuadro 4: Conceptos Capa MotivacionalConcepto Descripcion Notacion

Stakeholder

El papel de un individuo, equipo u or-ganizacion (o sus clases) que represen-ta sus intereses o preocupaciones enrelacion con el resultado de la arqui-tectura.

Driver (Con-trolador)

Algo que crea, motiva y alimenta elcambio en una organizacion.

71

72 F A S E D E V I S I O N D E A R Q U I T E C T U R A

Cuadro 4: Conceptos Capa MotivacionalConcepto Descripcion Notacion

Assessment(Resultado)

El resultado de algun analisis de alguncontrolador.

Goal (Meta)Un estado final que una parte interesa-da intenta lograr.

RequerimientoUna declaracion de necesidad que de-be ser realizada por un sistema.

RestriccionUna restriccion en la forma en que serealiza un sistema.

Principle(Principio)

Una propiedad normativa de todos lossistemas en un contexto dado, o la for-ma en que se realizan.

El principal objetivo de los conceptos motivacionales en ArchiMate es soportar losrequerimientos de gestion los cuales establecen los objetivos de negocio de alto nivel,los principios de arquitectura y los requerimientos de negocio iniciales, y es por esoque los objetivos y principios deben ser traducidos en requerimientos antes que loselementos principales, tales como los servicios, procesos y aplicaciones que pueden serasignados para realizarlos.[8]

Figura 34: Relacion entre los elementos principales y los elementos motivacionales [7]

6.1 P U N T O D E V I S TA D E S TA K E H O L D E R 73

6.1 P U N T O D E V I S TA D E S TA K E H O L D E R

6.1.1 Metamodelo

El punto de vista de Stakeholder permite al analista modelar los implicados, los li-neamientos y las valoraciones en terminos de fortalezas, debilidades, oportunidadesy amenazas. Ademas, el vınculo con los objetivos principales que abordan estas preo-cupaciones e indicadores debe ser descrito. En general es importante entender que elimplicado tiene un rol dentro de la organizacion y que el objetivo a analizar debe serel mas general de la unidad en analisis. Estos objetivos constituyen la base para el pro-ceso de ingenierıa de requerimientos ya que son la puerta para los requerimientos dela organizacion, mientras que los lineamientos (manejador) son una caracterıstica fun-damental de la mision del Stakeholder la cual termina siendo una funcion de alto niveldentro de la organizacion.

Figura 35: Punto de Vista de Stakeholder[7, 3]

6.1.2 Modelo

Basados en la contextualizacion del problema de la primera parte de este documento,el siguiente diagrama nos permite reconocer que elaborar un documento con los reque-rimientos del proceso y solucionar un problema crıtico de la companıa, son 2 objetivosgenerales de Efron Colombia, y en especıfico de su proceso de levantamiento de reque-rimientos, en donde el Consultor de EFRON ofrece un valor agregado en la relacion conel Cliente, entendiendo su situacion actual en busca del ahorro del dinero y tiempo, enuno o varios procesos de negocio en los que se pueda presentar algun cuello de botella,


y adicionalmente exista una opcion de mejora desde el interior de la organizacion porlos implicados.

Figura 36: Modelo de Stakeholder. Fuente: Autor

6.2 P U N T O D E V I S TA D E R E A L I Z A C I O N D E O B J E T I V O S

6.2.1 Metamodelo

El punto de vista de realizacion de objetivos permite al disenador modelar el refina-miento de los objetivos a un alto nivel en objetivos muy concretos para un posterior refi-namiento adicional convirtiendolos en requerimientos o en restricciones que describenlas propiedades que son necesarias para realizar los objetivos. El refinamiento de obje-tivos en sub-objetivos es modelado usando la relacion de agregacion. El refinamientode objetivos en requerimientos es modelado usando la relacion de realizacion. Adicio-

6.2 P U N T O D E V I S TA D E R E A L I Z A C I O N D E O B J E T I V O S 75

nal, los principios pueden ser modelados para guiar el refinamiento de los objetivos enrequerimientos.

Figura 37: Punto de Vista de Realizacion de Objetivos[7, 3]

6.2.2 Modelo

El punto de vista de realizacion de objetivos nos permite concluir que la “Elaboracionde un documento de requerimientos de un proceso que cumpla con los estandares decalidad de EFRON y del cliente es a traves la indagacion y profundizacion del proceso,


del entendimiento de los problemas del negocio a traves del trabajo con los actores delproceso, proponiendo alternativas de solucion y definiendo un alcance de la solucion.

Figura 38: Modelo de Realizacion de Objetivos. Fuente: Autor

6.3 P U N T O D E V I S TA D E C O N T R I B U C I O N D E O B J E T I V O S

6.3.1 Metamodelo

El punto de vista de contribucion de objetivos permite a un disenador o analistamodelar las relaciones de influencia entre los objetivos y los requisitos. Los puntos devista resultantes pueden utilizarse para analizar el impacto que unos objetivos tienensobre otros o para detectar conflictos entre los objetivos de las partes interesadas. Porlo general, este punto de vista se puede utilizar despues de que los objetivos han sidorefinados, en cierta medida, en subobjetivos y, posiblemente, en requisitos. Por lo tantolas relaciones de agregacion y de realizacion tambien pueden aparecer en este punto devista.

6.3 P U N T O D E V I S TA D E C O N T R I B U C I O N D E O B J E T I V O S 77

Figura 39: Punto de Vista de Contribucion[7, 3]

6.3.2 Modelo

El modelo de contribucion nos permite evidenciar que para elaborar un documentocon calidad con los requerimientos del proceso en estudio, es necesario que el usuarioo cliente del proceso suministre toda la informacion de las tareas que realiza el proceso.Para lograrlo encontramos que el consultor debe definir metodologıas para el entendi-miento con el usuario para lograr compenetrar con el y obtener la mayor informaciondel proceso. Se detecto que la tarea se ve obstaculizada por una especie de rechazonatural al cambio que las personas sufrimos.

Figura 40: Modelo de Contribucion. Fuente: Autor


6.4 P U N T O D E V I S TA D E P R I N C I P I O S

6.4.1 Metamodelo

El punto de vista de principios permite al analista o disenador modelar los principiosque son relevantes para el problema de diseno a mano, incluidos los objetivos quemotivan a estos principios. Ademas, las relaciones entre los principios y sus objetivos,pueden ser modelados. Por ejemplo, los principios pueden influir entre sı positiva onegativamente.

Figura 41: Punto de Vista de Principios[7, 3]

6.4.2 Modelo

Para incrementar la satisfaccion de los clientes cumpliendo sus requisitos con calidad,son fundamentales los principios de EFRON como son la calidad de su recurso humano,la excelencia en todos sus procesos, el compromiso con los clientes, la valoracion delempleado, y el crecimiento de EFRON como proceso de aprendizaje continuo.

6.5 P U N T O D E V I S TA D E R E A L I Z A C I O N D E R E Q U E R I M I E N T O S 79

Figura 42: Modelo de Principios. Fuente: Autor

6.5 P U N T O D E V I S TA D E R E A L I Z A C I O N D E R E Q U E R I M I E N T O S

6.5.1 Metamodelo

El punto de vista de la realizacion de requerimientos permite al disenador modelarla realizacion de las necesidades por los elementos basicos, tales como actores de nego-cio, servicios de negocio, procesos de negocio, servicios de aplicacion, componentes dela aplicacion, etc. Por lo general, los requerimientos son el resultado del refinamientodel punto de vista de objetivos. Ademas, este punto de vista se puede usar para refi-nar requisitos en requisitos mas detallados. La relacion de agregacion se usa para esteproposito.


Figura 43: Punto de Vista de Realizacion de Requerimientos[7, 3]

6.5.2 Modelo

Para incrementar la satisfaccion de los clientes cumpliendo sus requisitos con calidad,es necesario identificar los criterios de calidad para cada uno de los clientes alineandolas entregas de los requerimientos con base en los requisitos de calidad, se deben defi-nir indicadores que permitan la valoracion del cliente y para ello es necesario realizarmediciones periodicas para llevar una trazabilidad de los indicadores para cada uno delos clientes e identificar y documentar las mejoras al proceso programando reunionesperiodicas con el cliente para verificar las mejoras del proceso.

Figura 44: Modelo de Realizacion de Requerimientos. Fuente: Autor

6.6 P U N T O D E V I S TA D E M O T I VA C I O N 81

6.6 P U N T O D E V I S TA D E M O T I VA C I O N

6.6.1 Metamodelo

El punto de vista de motivacion permite al disenador o analista modelar el aspecto dela motivacion, sin centrarse en ciertos elementos dentro de este aspecto. Por ejemplo,este punto de vista puede ser usado para presentar de forma completa o parcial un re-sumen del aspecto motivacional relacionando a los implicados, sus objetivos primarios,los principios que estan aplicados, y el requerimiento principal enfocado a servicios,procesos, aplicaciones y objetos.

Figura 45: Punto de Vista de Motivacion[7, 3]

6.6.2 Modelo

La calidad y excelencia en la etapa de requerimientos donde el consultor de EFRON,escucha, analiza y genera recomendaciones sobre el proceso, para elaborar un docu-mento con los requerimientos aplicando las mejores practicas de esta etapa del serviciode desarrollo de software a la medida. Es clave la oportuna retroalimentacion por parte


del consultor hacia el cliente con los hallazgos en el proceso del cliente para empezar adar forma al servicio que se quiere llegar a prestar.

Figura 46: Modelo de Motivacion. Fuente: Autor

7

FA S E D E O P O RT U N I D A D E S Y S O L U C I O N E S

Cuadro 5: Conceptos Capa de Implementacion y MigracionConcepto Descripcion Notacion

Paquete deTrabajo

Una serie de acciones disenadas paralograr un objetivo unico dentro de untiempo especıfico.

EntregableUn resultado definido con precision deun paquete de trabajo.

PlateauUn estado relativamente estable dela arquitectura que existe durante unperıodo de tiempo limitado.

Gap (Brecha)Un resultado de un analisis de brechaentre dos mesetas.

83

84 F A S E D E O P O RT U N I D A D E S Y S O L U C I O N E S

7.1 P U N T O D E V I S TA D E P R O Y E C T O

− El desarrollo de la arquitectura empresarial en toda la organizacion es una tareaque puede requerir varios anos.

− Todos los sistemas y servicios deben permanecer operativos con independencia desuponer que se den modificaciones y cambios en la arquitectura de la empresadurante el proceso de cambio.

− El proceso de cambio puede tener que lidiar con los estandares de tecnologıainmaduros (por ejemplo, mensajerıa, seguridad, datos, etc.).

− El cambio tiene graves consecuencias para el personal, la cultura, la forma detrabajar, y la organizacion.

Ademas, hay varios otros aspectos de gobernanza que podrıan restringir el procesode transformacion, como la cooperacion interna y externa, la gestion de cartera deproyectos, la gestion de proyectos (entregables, objetivos, etc.), la planificacion de laplatea, los aspectos financieros y legales, etc.

Figura 47: Punto de Vista de Proyecto[7, 3]

7.1 P U N T O D E V I S TA D E P R O Y E C T O 85

7.1.1 Modelo

El proyecto para la construccion de un gestor de requerimientos tiene como objetivoincrementar la satisfaccion de los clientes de EFRON al cumplir sus requerimientos concalidad, gracias a la correcta interaccion cliente-consultor.

Figura 48: Modelo de Proyecto. Fuente: Autor

8

FA S E D E P L A N E A C I O N Y M I G R A C I O N

8.1 P U N T O D E V I S TA D E M I G R A C I O N

8.1.1 Metamodelo

La fase de planeacion de migracion esta resuelta por el punto de vista de migracionel cual implica modelos y conceptos que pueden ser utilizados para especificar la transi-cion de una arquitectura existente a una arquitectura deseada. La platea representa unestado relativamente estable de la arquitectura que existe durante un periodo limitadode tiempo. La brecha es el resultado de un analisis de diferencias entre dos plateas. Acontinuacion el metamodelo de este punto de vista.

Figura 49: Punto de Vista de Migracion[7, 3]

8.1.2 Modelo

Habiendo concebido una solucion de software para la gestion de los requerimientosse empieza a conceptualizar la proyeccion de una solucion a una herramienta de au-togestion, pero para llegar alla es necesario primero encontrar el punto neutro donde

87

88 F A S E D E P L A N E A C I O N Y M I G R A C I O N

todo lo que el cliente aporta al proceso se pueda obtener directamente en el sistema, yes por eso que el siguiente hito luego de desarrollar el gestor es incorporarle un ambien-te colaborativo de requerimientos con el cual se pueda tener la correcta comunicacionentre el cliente y el consultor y ası le pueda servir de guıa en la inclusion de los facto-res a evaluar de su proceso. Logrado ese paso dentro de la migracion de la aplicacion,encontramos que es posible llegar a un consultor virtual a traves de un sistema expertoque evalue los parametros que el cliente ha ingresado para que se genere un documentode levantamiento de requerimientos. Es importante resaltar que el rol y funciones delconsultor no desaparecen, ya que es clave considerar la aprobacion de el para tener elcriterio de aceptacion. Sin esto podemos presumir que el sistema seria autosuficientepero es necesario el visto bueno del experto.

Figura 50: Modelo de Migracion. Fuente: Autor

9

FA S E D E I M P L E M E N TA C I O N D E G O V E R N A N Z A

9.1 P U N T O D E V I S TA D E M I G R A C I O N E I M P L E M A N TA C I O N

9.1.1 Metamodelo

La implementacion y gobierno de la solucion son correspondientes con el punto devista de implementacion y migracion el cual es usado para relacionar programas y pro-yectos con la parte de la arquitectura que se debe implementar. Este punto permitemodelar el objetivo de los programas, proyectos, actividades, e hitos que se van a reali-zar. Ademas, este punto de vista puede ser usado en combinacion con los programas yvista de proyecto.

Figura 51: Punto de Vista de Migracion e Implementacion[7, 3]

89

90 F A S E D E I M P L E M E N TA C I O N D E G O V E R N A N Z A

9.1.2 Modelo

El proyecto para la construccion de un gestor de requerimientos tiene como objetivoincrementar la satisfaccion de los clientes de EFRON al cumplir sus requerimientos concalidad, gracias a la correcta interaccion cliente-consultor. Lograr el gestor de requeri-mientos va permitir la realizacion de un punto de partida para empezar a conceptualizarla proyeccion de una solucion a una herramienta de autogestion, pero para llegar allaes necesario primero encontrar el punto neutro donde todo lo que el cliente aporta alproceso se pueda obtener directamente en el sistema, y es por eso que el siguiente hitoluego de desarrollar el gestor es incorporarle un ambiente colaborativo de requerimien-tos con el cual se pueda tener la correcta comunicacion entre el cliente y el consultor yası le pueda servir de guıa en la inclusion de los factores a evaluar de su proceso.

Figura 52: Modelo de Migracion e Implementacion. Fuente: Autor

Parte III

R E F L E X I O N E S

10

P R O P U E S TA M E T O D O L O G I C A

El concepto calidad es subjetivo para cada uno de los actores y roles que estan in-volucrados en los procesos de implementacion de software, debido a esto y dentro deldesarrollo de la investigacion que se realizo en este trabajo de grado se concluyo, que engeneral las mi pymes que implementan software estan enfocadas en el aseguramientode la calidad de los artefactos resultantes de cada uno de los proyectos, solo que cadauna de ellas le da su propio enfoque.

Ahora si se tiene en cuenta que no existe una metodologıa o proceso de software losuficientemente particular o lo suficientemente general que cubra la gama de necesi-dades del desarrollo de software, debido en gran parte a la falta de un lenguaje quepermita la expresion tanto de metodologıas como de procesos, esto ha generado laproliferacion de propuestas que solo dispersan el problema, como efecto colateral lasmetodologıas y procesos se han asumido como soluciones ad-hoc surgidas como porgeneracion espontanea, sin unos roles definidos, cuya responsabilidad sea la de tratar ala metodologıa y al proceso como partes del problema mismo a resolver, apoyandose enpracticas reconocidas, evitando defectos ya identificados y controlando la misma meto-dologıa y/o proceso por medio de mediciones mucho mas precisas. [6]

Dentro del mundo de los procesos se reconoce al Project Management Institute, la cuales una organizacion que asocia a profesionales relacionados con la Gestion de Proyectosy donde uno de sus principales objetivos es formular estandares profesionales en Ges-tion de Programas [11], ahora dentro del mundo de las metodologıas una de las masreconocidas en Scrum, la cual es un marco de trabajo por el cual las personas puedenacometer problemas complejos adaptativos, a la vez que entregar productos del maxi-mo valor posible productiva y creativamente. [10] Lo anterior es un claro ejemplo quetanto procesos como metodologıas buscan dar solucion a las problematicas existentespor medio de los estandares que proponen, pero ninguno de los dos ejemplos otorgauna solucion de fondo, definitiva e integral.

93

94 P R O P U E S TA M E T O D O L O G I C A

En el proceso investigativo se evidencio que una de las fallas principales es que nose tiene en cuenta al cliente en la mayorıa de las etapas del proyecto, y es el quienfinalmente determina sı el producto entregado cumple con lo solicitado y lo esperado.

Basado en lo anterior la propuesta metodologica sugiere las siguientes recomendacio-nes:

− Tomar como base el proceso o metodologıa que se viene utilizando para la gestionde los proyectos de implementacion de software, solo que se debe integrar al usua-rio funcional o usuario lıder en cada una de las etapas del proceso, ası cada avanceobtenido ha sido acompanado o verificado por un representante del cliente.

− Realizar reuniones de seguimiento con el grupo de trabajo y con el cliente demanera frecuente, ası de esta manera se mantiene informado al cliente de losavances, estado actual de los demas procesos y posibles incidencias que hayanocurrido posterior a la ultima reunion de seguimiento.

− Del punto anterior se debe tener muy presente siempre dejar constancia de loscompromisos, acuerdos y conclusiones de cada reunion de seguimiento por mediode un acta de reunion.

− Definir para cada compromiso registrado en el acta de reunion un responsable,un alcance y una fecha de entrega, dicha definicion se debe realizar durante lareunion de seguimiento y debe quedar consignada en el acta de la reunion.

− Definir estandares de desarrollo para el nombrado, el diseno y la codificacion delsoftware, dado que esto determina un estandar de codificacion, genera orden almomento programar y reduce tiempos en los ajustes futuros.

− Determinar indicadores en cada fase del proyecto para realizar mediciones pe-riodicas y obtener una trazabilidad del estado del proyecto en cada una de lasfases, lo cual es el insumo para los informes de gestion que se le deben presentarperiodicamente al cliente.

− Personalizar las etapas del proceso o la metodologıa de tal manera que se tengamayor participacion del cliente en todas o en la gran mayorıa de las etapas delproyecto, esto con el objetivo de mantener informado al cliente durante la ejecu-cion del proyecto, y de la misma manera obtener aprobaciones sobre cada uno delos avances, lo cual facilitara el cierre oportuno del proyecto.

− Definir estandares para las fases de pruebas, lo cual permite que dicha fase tengaun hilo conductor definido, ordenado y con tiempos estimados, ası las demas areasdel cliente e internas del proyecto pueden estimar una fecha u hora estimada paraobtener la retroalimentacion respectiva.

P R O P U E S TA M E T O D O L O G I C A 95

− Definir la entrega de artefactos en cada una de las fases del proyecto para obtenerretroalimentacion de parte del cliente con la mayor frecuencia posible.

− Definir planes de accion para el momento en el que se identifiquen controles decambios haya un procedimiento definido y el cliente vea que una respuesta opor-tuna y estructurada.

− Definir planes de accion para el momento en el que se identifiquen garantıas porfuncionamientos inconsistentes, de esta manera se muestra al cliente que su pro-veedor tecnologico cuenta con estandares de calidad.

A continuacion se puede apreciar un grafico dentro del cual se describe de formageneral cada una de las etapas que pueden ocurrir dentro del proceso de desarrollode software para presentar al cliente un entregable o artefacto. Todo empieza por lareunion de inicio de proyecto, donde tanto los usuarios representativos del cliente co-mo los representantes del equipo de trabajo se reunen y revisan las necesidades quepresenta el cliente. Basados en la informacion recolectada en la reunion de inicio deproyecto, el equipo de trabajo elabora un documento de levantamiento de requerimien-tos, en el cual se plasman cada uno de los requerimientos funcionales y no funcionalesque solicito el cliente, o que son necesarios para cumplir con las expectativas del mismo.El cual es presentado al cliente por el Gerente de Proyecto, y es allı desde el punto ini-cial donde se debe involucrar al cliente, y su participacion termina hasta el punto dondele es entregado el artefacto.

Por lo tanto, en las demas fases como lo son el analisis, la presentacion de la solu-cion, la version inicial o preliminar del artefacto, la fase de pruebas debe estar presenteel cliente, es mas antes de iniciar esta ultima fase, el cliente debe haber definido los cri-terios de aceptacion del artefacto, ası de esta manera la fase de pruebas se basa en granparte en cumplir de manera funcional cada uno de los criterios de aceptacion previa-mente definidos. De esta manera la entrega final del artefacto sera un acto meramenteprotocolario, dado que sı se ha realizado cada una de las anteriores etapas con el rigorrespectivo, el artefacto en su version final cubrira todas y cada una de las expectativasdel cliente, generando ası un gran valor agregado y la satisfaccion para el cliente, quienes nuestro mayor aliado.

96 P R O P U E S TA M E T O D O L O G I C A

Figura 53: Propuesta Metodologica. Fuente: Autor

11

C O N C L U S I O N E S

El realizar una personalizacion metodologica por medio de las buenas practicas delmercado para el aseguramiento de la calidad del software implementado por mi pymes,nos permite concluir:

− Las normas ISO nos brindan un marco teorico relevante, pero al mismo tiempomuy general, dado que determina que procesos debemos implementar para mejo-rar como organizacion, pero no especifica el como llegar a esos estados ideales.

− Independientemente de los procesos o metodologıas utilizadas en la ejecucion y/ogestion de los proyectos de software, la falencia de calidad mas comun es el noinvolucrar al cliente en todas las etapas de ejecucion del proyecto.

− El analisis desde diferentes puntos de vista abarca los escenarios reales de lasorganizaciones y nos muestra un camino hacia la calidad y la mejora continua.

97

12

T R A B A J O S F U T U R O S

Haber realizado el analisis de arquitectura empresarial al proceso de levantamientode requerimientos no debe ser solo eso, un analisis, y no solo porque consideremosque esta etapa es la mas importante en el desarrollo de software a la medida, es por-que realmente es la capa mas alta de la gestion de negocios y consultorıa de EFRON,donde el profesional consultor y el gerente regional son los recursos que van a ser lapuerta para el crecimiento economico de la companıa, a traves de su trabajo en el clien-te y dentro de la organizacion. Poder otorgarles una herramienta de software para estaetapa del desarrollo, es el gran reto que se convierte en el futuro proyecto de desarrollo.

Lograr el Gestor de requerimientos como primer hito dentro de EFRON, va a permi-tir ejecutar proyectos en menor tiempo, de mejor calidad en cuanto a las necesidadesdel cliente, y con un plan de mejora definido en conjunto. Ahora un segundo hito debeser el analisis de la arquitectura de negocio para el proceso de registro y la medicion delos indicadores del aseguramiento de la calidad; para con esto dar origen al tercer hito,el cual consiste en implementar un modulo gestor del aseguramiento de la calidad delsoftware, el recibira informacion del modulo del gestor de requerimientos, y de esta ma-nera se tendra la informacion a un nivel de detalle ideal, y la informacion contenida enel software sera consistente y complementarıa, dando ası una valor agregado relevantepara la organizacion, el cual se traducira en una mejora de servicio hacia los clientes.

99

13

A N E X O S

13.1 C O L O S O

13.1.1 Colosoft EU

Colosoft es una empresa unipersonal que promueve el desarrollo de productos de ca-lidad con nuevas formas de Ingenierıa de Software, la plataforma de desarrollo puedeser descargada desde www.colosoft.com.co y utilizar segun la licencia adquirida. Colo-soft promueve el uso de coloso con un conjunto de soluciones que permiten abordar eldesarrollo de software en todas sus etapas.[1]

Figura 54: Logo de Colosoft[1]

13.1.2 Autor

Sandro Bolanos, es PhD en Ingenierıa de Software, MSc en Teleinformatica e Inge-niero de Sistemas; creador de lenguajes y plataformas de software, ha escrito variosdocumentos de investigacion en Ingeniera de Software, es docente investigador de laUniversidad Distrital Francisco Jose de Caldas, director del posgrado en Ingenierıa de

101

102 A N E X O S

Software de la UD, ha recibido distinciones y premios por sus meritos academicos y esconsultor en temas de Ingenierıa de Software.[1]

B I B L I O G R A F I A

[1] S. J. Bolanos Castro. Coloso academico, 2012.

[2] Efron Colombia. Metodologıa de trabajo, 2010.

[3] Coloso. Puntos de vista de archimate caso de estudio. Colosoft EU, 2012.

[4] Efron Consulting. Informacion corporativa, 2009.

[5] Kybele Consulting. Implantacion de las normas iso/iec 15504 e iso/iec 12207 conmetodos agiles y scrum, 2016.

[6] Sandro Javier Bolanos Castro. Vıctor Hugo Medina Garcia. Roberto Ferro Esco-bar. MetaProceso de Desarrollo de Software - El grial de las Metodologıas y Procesos.Editorial UD, 2016.

[7] The Open Group. The open group. archimate 2.0 specification, technical standard,2012.

[8] The Open Group. An introduction to the archimate R© 2 modeling language, 2013.

[9] Normas Iso. La familia iso, 2016.

[10] Ken Schwaber and Jeff Sutherland. La guıa de scrum, 2013.

[11] Wikipedia. Project management institute, 2015.

[12] Wikipedia. Iso 15504, 2018.

103

PERSONALIZACION METODOL´ OGICA PARA EL´...

Documents

Transcript of PERSONALIZACION METODOL´ OGICA PARA EL´...