PROTOTIPO DE ARQUITECTURA EMPRESARIAL …repository.udistrital.edu.co/bitstream/11349/3104/1... ·...

FACULTAD DE INGENIERIA

PROYECTO CURRICULAR DE INGENIERIA DE SISTEMAS

Proyecto de Grado:

PROTOTIPO DE ARQUITECTURAEMPRESARIAL PARA UN PORTAL WEB

DE INVESTIGACION BASADO EN LAUSABILIDAD

Presentada por:Juan Gabriel Mora Hernandez

Kevin Eduardo Jamaica Gonzalez

Proyecto de Grado:

PROTOTIPO DE ARQUITECTURAEMPRESARIAL PARA UN PORTAL WEB

DE INVESTIGACION BASADO EN LAUSABILIDAD

Presentada por:Juan Gabriel Mora Hernandez

Kevin Eduardo Jamaica Gonzalez

Dirigida por:Ing. Sandro Javier Bolanos Castro PhD

FACULTAD DE INGENIERIAPROYECTO CURRICULAR DE INGENIERIA DE SISTEMAS

BOGOTA D.C.2016

Nota de aceptacion:

Firma del presidente del jurado

Firma del jurado

Bogota D.C., Abril de 2016

Dedicatoria

“El hombre que se levanta es aun mas grande que el que no ha caıdo.”Concepcion Arenal

A mi madre Maria Teresa Mora por brindarme su afecto y su apoyo incon-dicional en todas las la etapas de mi vida. Gracias a su esfuerzo he logradollegar a donde estoy hoy.A mi tia Paulina Mora por su acompanamiento y afecto.A Alejandra Lopez, quien representa un gran apoyo para mi.A mi companero de proyecto de grado y amigo Kevin Jamaica por el apoyoy esfuerzo que dedico para sacar adelante este proyecto.

JUAN GABRIEL MORA HERNANDEZ

Dedicatoria

“El pasado sin rencor, el presente con pasion y el futuro sin temor”.AnonimoQuiero agradecer a mis padres Luis Eduardo Jamaica y Cecilia Gonzalez porbrindarme su educacion, formacion, carino y apoyo, durante las diferentesetapas de mi vida.Quiero agradecer a Dios por las bendiciones recibidas durante mi vida queme han permitido alcanzar lo inalcanzable.A mis hermanos y sobrinos por estar presentes en mi vida.A Gala Forero, que se ha convertido en una persona importante en mi vida:gracias por ser mi mejor amiga y acompanante.A nuestro director de proyecto de grado Sandro Bolanos por brindarnos sutiempo, conocimiento, experiencia y guıa durante todo el desarrollo del pro-yecto.A mi amigo y companero de proyecto de grado Gabriel Mora por el apoyo ycompanerismo que ha tenido hacia mi.

KEVIN EDUARDO JAMAICA GONZALEZ

Agradecimientos

Agradecemos la direccion y acompanamiento a nuestro director del pro-yecto y profesor Sandro Javier Bolanos Castro por habernos brindado elapoyo, conocimiento y guıa necesarios para desarrollar este trabajo de gra-do, a nuestro companero Juan Camilo Salazar que nos brindo su apoyo yconocimiento en las primeras fases del proyecto y a la Universidad DistritalFrancisco Jose de Caldas por la formacion y espacios que nos ha proporcio-nado, lo que nos permitio crecer personal y profesionalmente durante todoeste tiempo.

Indice general

Lista de figuras 10

Lista de tablas 14

1. INTRODUCCION 151.1. PLANTEAMIENTO DEL PROBLEMA . . . . . . . . . . . . 161.2. OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . 171.2.2. Objetivos Especıficos . . . . . . . . . . . . . . . . . . . 17

1.3. JUSTIFICACION . . . . . . . . . . . . . . . . . . . . . . . . . 18

2. LA METODOLOGIA AGIL 202.1. EL MANIFIESTO AGIL . . . . . . . . . . . . . . . . . . . . . 202.2. METODOLOGIA XP (“EXTREME PROGRAMMING”) . . 25

3. MODELOS DE CALIDAD 303.1. DEFINICION DE USABILIDAD . . . . . . . . . . . . . . . . 303.2. EVOLUCION DE LA DEFINICION DE USABILIDAD . . . 31

3.2.1. Norma ISO/IEC 9241-11 (1998) . . . . . . . . . . . . . 323.2.2. Norma ISO/IEC 9126-1 (2001) . . . . . . . . . . . . . 333.2.3. Norma ISO/IEC 25000 ”SQUARE”(2005) . . . . . . . 35

6

INDICE GENERAL 7

4. METAPROCESO 394.1. MODELO DE PROCESO . . . . . . . . . . . . . . . . . . . . 394.2. METODOLOGIAS PARA EL DESARROLLO DE SOFTWA-

RE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5. ANALISIS DE REQUERIMIENTOS 435.1. PUNTO DE VISTA DE USUARIO . . . . . . . . . . . . . . . 435.2. PUNTO DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . 44

5.2.1. Requerimientos Funcionales . . . . . . . . . . . . . . . 445.2.2. Requerimientos No Funcionales . . . . . . . . . . . . . 44

6. DISENO DEL SOFTWARE 466.1. UNIFIED MODELING LANGUAGE (UML) . . . . . . . . . 46

6.1.1. Casos De Uso . . . . . . . . . . . . . . . . . . . . . . . 466.2. EL LENGUAJE ARCHIMATE . . . . . . . . . . . . . . . . . 49

7. EJECUCION 517.1. DEFINICION DE REQUERIMIENTOS . . . . . . . . . . . . 51

7.1.1. Requerimientos Del Punto De Vista De Usuario . . . . 517.1.2. Requerimientos Del Sistema . . . . . . . . . . . . . . . 52

7.1.2.1. Requerimientos funcionales . . . . . . . . . . 527.1.2.2. Requerimientos no funcionales . . . . . . . . . 54

7.2. CASOS DE USO . . . . . . . . . . . . . . . . . . . . . . . . . 567.2.1. Sistema Total . . . . . . . . . . . . . . . . . . . . . . . 567.2.2. Sistema En General . . . . . . . . . . . . . . . . . . . . 57

7.2.2.1. Especificacion de casos de uso del sistema engeneral . . . . . . . . . . . . . . . . . . . . . 58

7.2.3. Modulo De Transacciones . . . . . . . . . . . . . . . . 657.2.3.1. Especificacion de casos de uso del modulo de

transacciones . . . . . . . . . . . . . . . . . . 66

INDICE GENERAL 8

7.2.4. Modulo De Comunidad Web . . . . . . . . . . . . . . . 707.3. ARQUITECTURA EMPRESARIAL . . . . . . . . . . . . . . 72

7.3.1. Capa Motivacional . . . . . . . . . . . . . . . . . . . . 747.3.1.1. Contextualizacion de los objetivos estrategicos 767.3.1.2. Definicion de los interesados (Stakeholders) . 777.3.1.3. Matriz del enfoque de gestion de los Stakehol-

ders . . . . . . . . . . . . . . . . . . . . . . . 807.3.1.4. Punto de Vista de Stakeholders . . . . . . . . 827.3.1.5. Punto de Vista de Realizacion de Objetivos . 887.3.1.6. Punto de Vista de Contribucion de Objetivos 907.3.1.7. Punto de Vista de Principios . . . . . . . . . 927.3.1.8. Punto de Vista Realizacion de Requerimientos 947.3.1.9. Punto de Vista de Motivacion . . . . . . . . . 967.3.1.10. Objetivos de la Arquitectura . . . . . . . . . 98

7.3.2. Capa de Negocio . . . . . . . . . . . . . . . . . . . . . 987.3.2.1. Punto de Vista de Organizacion . . . . . . . . 1017.3.2.2. Punto de Vista de Cooperacion de Actor . . . 1037.3.2.3. Punto de Vista de Funcion de Negocio . . . . 1057.3.2.4. Punto de Vista de Proceso de Negocio . . . . 1077.3.2.5. Punto de Vista de Producto . . . . . . . . . . 110

7.3.3. Capa de Aplicacion . . . . . . . . . . . . . . . . . . . . 1127.3.3.1. Punto de Vista de Comportamiento de Apli-

cacion . . . . . . . . . . . . . . . . . . . . . . 1147.3.3.2. Punto de Vista de Cooperacion de Aplicacion 1167.3.3.3. Punto de Vista de Estructura de Aplicacion . 1187.3.3.4. Punto de Vista de Uso de Aplicacion . . . . . 121

7.3.4. Capa de Infraestructura . . . . . . . . . . . . . . . . . 1237.3.4.1. Punto de Vista de Infraestructura . . . . . . . 125

7.3.4.2. Punto de Vista de Uso de Infraestructura . . 1277.3.4.3. Punto de Vista de Organizacion e Implemen-

tacion . . . . . . . . . . . . . . . . . . . . . . 1297.3.4.4. Punto de Vista de Estructura de Informacion 1317.3.4.5. Punto de Vista de Realizacion del Servicio . . 133

7.3.5. Capa de Implementacion y Migracion . . . . . . . . . . 1357.3.5.1. Punto de Vista de Proyecto . . . . . . . . . . 1367.3.5.2. Punto de Vista de Migracion . . . . . . . . . 1387.3.5.3. Punto de Vista de Migracion e Implementacion140

8. PROTOTIPO 142

9. CONCLUSIONES Y TRABAJO FUTURO 149

Indice de figuras

2.1. Proceso de desarrollo XP, Tomada del libro Software Enginee-ring: A Practitioner’s Approach - Pressman, Roger S. . . . . . 25

2.2. Proceso de XP para producir un incremento, Tomada del libroIngenierıa del software - Sommerville, Ian. . . . . . . . . . . . 26

3.1. Divisiones de la norma ISO/IEC 25000, Tomada del PortalWeb ISO 25000. . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1. PQ: (C&D,Q,...) . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1. Metamodelos en diferentes niveles de especificidad, Tomada dela pagina oficial de The Open Group, http://www.opengroup.org/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.1. Diagrama de Casos de Uso del comportamiento del Sistema . . 567.2. Diagrama de Casos de Uso Generales . . . . . . . . . . . . . . 577.3. Diagrama de Casos de Uso del comportamiento del modulo de

transacciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 657.4. Diagrama de Casos de Uso del comportamiento del modulo de

comunidad Web . . . . . . . . . . . . . . . . . . . . . . . . . . 707.5. Mapa de Stakeholders . . . . . . . . . . . . . . . . . . . . . . 777.6. Enfoque de Gestion de Stakeholders . . . . . . . . . . . . . . . 807.7. Metamodelo del Punto de Vista de Stakeholders . . . . . . . . 827.8. Punto de Vista de Stakeholders 1 . . . . . . . . . . . . . . . . 83

10

http://www.opengroup.org/


INDICE DE FIGURAS 11

7.9. Punto de Vista de Stakeholders 2 . . . . . . . . . . . . . . . . 847.10. Punto de Vista de Stakeholders 3 . . . . . . . . . . . . . . . . 857.11. Punto de Vista de Stakeholders 4 . . . . . . . . . . . . . . . . 867.12. Punto de Vista de Stakeholders 5 . . . . . . . . . . . . . . . . 877.13. Metamodelo del Punto de Vista de Realizacion de Objetivos . 887.14. Punto de Vista Realizacion de Objetivos . . . . . . . . . . . . 897.15. Metamodelo del Punto de Vista de Contribucion de Objetivos 907.16. Punto de Vista de Contribucion de Objetivos. . . . . . . . . . 917.17. Metamodelo del Punto de Vista de Principios . . . . . . . . . 927.18. Punto de Vista de Principios . . . . . . . . . . . . . . . . . . . 937.19. Metamodelo del Punto de Vista de Realizacion de Requeri-

mientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 947.20. Punto de Vista de Realizacion de Requerimientos . . . . . . . 957.21. Metamodelo del Punto de Vista de Motivacion . . . . . . . . . 967.22. Punto de Vista de Motivacion . . . . . . . . . . . . . . . . . . 977.23. Metamodelo del Punto de Vista de Organizacion . . . . . . . . 1017.24. Punto de Vista de Organizacion . . . . . . . . . . . . . . . . . 1027.25. Metamodelo del Punto de Vista de Cooperacion de Actor . . . 1037.26. Punto de Vista de Cooperacion de Actor . . . . . . . . . . . . 1047.27. Metamodelo del Punto de Vista de Funcion de Negocio . . . . 1057.28. Punto de Vista de Funcion de Negocio . . . . . . . . . . . . . 1067.29. Metamodelo del Punto de Vista de Proceso de Negocio . . . . 1077.30. Punto de Vista de Proceso de Negocio 1 . . . . . . . . . . . . 1087.31. Punto de Vista de Proceso de Negocio 2. . . . . . . . . . . . . 1097.32. Metamodelo del Punto de Vista de Producto . . . . . . . . . . 1107.33. Punto de Vista de Producto . . . . . . . . . . . . . . . . . . . 1117.34. Metamodelo del Punto de Vista de Comportamiento de Apli-

cacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114


7.35. Punto de Vista de Comportamiento de Aplicacion. . . . . . . . 1157.36. Metamodelo del Punto de Vista de Cooperacion de Aplicacion 1167.37. Punto de Vista de Comportamiento de Aplicacion. . . . . . . . 1177.38. Metamodelo del Punto de Vista de Estructura de Aplicacion . 1187.39. Punto de Vista de Estructura de la Aplicacion . . . . . . . . . 1197.40. Metamodelo del Punto de Vista de Uso de Aplicacion . . . . . 1217.41. Punto de Vista de Uso de Aplicacion . . . . . . . . . . . . . . 1227.42. Metamodelo del Punto de Vista de Infraestructura . . . . . . . 1257.43. Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . 1267.44. Metamodelo del Punto de Vista de Infraestructura . . . . . . . 1277.45. Punto de Vista de Uso de Infraestructura . . . . . . . . . . . . 1287.46. Metamodelo del Punto de Vista de Organizacion e Implemen-

tacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1297.47. Punto de Vista de Organizacion e Implementacion . . . . . . . 1307.48. Metamodelo del Punto de Vista de Estructura de Informacion 1317.49. Punto de Vista de Estructura de Informacion . . . . . . . . . 1327.50. Metamodelo del Punto de Vista de Realizacion del Servicio . . 1337.51. Punto de Vista de Realizacion del Servicio . . . . . . . . . . . 1347.52. Metamodelo del Punto de Vista de Proyecto . . . . . . . . . . 1367.53. Punto de Vista de Proyecto . . . . . . . . . . . . . . . . . . . 1377.54. Metamodelo del Punto de Vista de Migracion . . . . . . . . . 1387.55. Punto de Vista de Migracion . . . . . . . . . . . . . . . . . . . 1387.56. Metamodelo del Punto de Vista de Migracion e Implementacion1407.57. Punto de Vista de Migracion e Implementacion . . . . . . . . 141

8.1. Imagen 1 de Prototipo: Pagina de versiones de Coloso. . . . . 1438.2. Imagen 2 de Prototipo: Pagina de ingreso a la Wiki. . . . . . . 1448.3. Imagen 3 de Prototipo: Visualizacion preliminar de la Wiki. . 1458.4. Imagen 4 de Prototipo: Pagina de ingreso al foro. . . . . . . . 146


8.5. Imagen 5 de Prototipo: Visualizacion preliminar del foro. . . . 1478.6. Imagen 6 de Prototipo: Pagina de ingreso a los blogs. . . . . . 148

Indice de cuadros

2.1. Practicas del proceso XP. . . . . . . . . . . . . . . . . . . . . . 29

3.1. Sub Factores de Usabilidad en Norma ISO/IEC 9241-11. . . . 323.2. Sub Factores de Usabilidad en Norma ISO/IEC 9126-1. . . . . 34

7.1. Definicion de Caso de Uso GEN01. . . . . . . . . . . . . . . . 597.2. Definicion de Caso de Uso GEN02. . . . . . . . . . . . . . . . 617.3. Definicion de Caso de Uso GEN03. . . . . . . . . . . . . . . . 637.4. Definicion de Caso de Uso GEN04. . . . . . . . . . . . . . . . 647.5. Definicion de Caso de Uso TRA01. . . . . . . . . . . . . . . . 677.6. Definicion de Caso de Uso TRA02. . . . . . . . . . . . . . . . 697.7. Definicion de Caso de Uso COM01. . . . . . . . . . . . . . . . 717.8. Elementos participantes de la Capa Motivacional. . . . . . . . 757.9. Matriz de enfoque de gestion de Stakeholders. . . . . . . . . . 817.10. Elementos participantes de la Capa de Negocio. . . . . . . . . 1007.11. Elementos participantes de la Capa de Aplicacion. . . . . . . . 1137.12. Elementos participantes de la Capa de Infraestructura. . . . . 1247.13. Elementos participantes de la Capa de Implementacion y Mi-

gracion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

14

Capıtulo 1

INTRODUCCION

Cada ano, el Foro Economico Mundial (World Economic Forum) realizaun estudio en el que evalua las capacidades tecnologicas de mas de 100 paıses,cuyos resultados publicados en ’The Global Technology Report’, permitenvisualizar los avances y retrasos que tienen los paıses y las regiones en esteaspecto, en comparacion al resto del mundo.1 Para la edicion del ano 2014, elreporte proyectado deja en claro que la mejora de la conectividad de AmericaLatina y el Caribe sigue representando uno de los principales desafıos de laregion, a pesar de los recientes esfuerzos de muchos paıses para desarrollar yactualizar sus infraestructuras de las TIC -Tecnologıas de la informacion yla comunicacion-.2

Mientras, Colombia esta en un pequeno punado de paıses en la region,que han logrado avances significativos en el desarrollo y la garantıa de unmayor y mejor acceso a la infraestructura de las TIC, lo que garantiza unmayor uso de estas en los diferentes grupos de interes. Sin embargo, lasdebilidades persisten en el sistema de innovacion que dificulta la capacidad de

1REVISTA ENTER.CO. Colombia es quinta en la region en desarrollo de TIC. Pagi-na web version HTML. Abril 12 de 2011. [citado 13 de septiembre de 2014]. Disponibleen internet: http://www.enter.co/cultura-digital/negocios/colombia-es-quinto-en-la-region-en-desarrollo-de-tic/

2THE WORLD ECONOMIC FORUM. The Global Information Technology Report2014. Documento en PDF. Abril 22 de 2014. [citado 13 de septiembre de 2014]. Dispo-nible en internet: http://www.weforum.org/issues/global-information-technologyhttp://www3.weforum.org/docs/WEF GlobalInformationTechnology Report 2014.pdf Pag. 15

15

http://www.enter.co/cultura-digital/negocios/colombia-es-quinto-en-la-region-en-desarrollo-de-tic/

http://www.enter.co/cultura-digital/negocios/colombia-es-quinto-en-la-region-en-desarrollo-de-tic/

http://www.weforum.org/issues/global-information-technology

http://www3.weforum.org/docs/WEF_GlobalInformationTechnology_Report_2014.pdf

http://www3.weforum.org/docs/WEF_GlobalInformationTechnology_Report_2014.pdf

CAPITULO 1. INTRODUCCION 16

la region en general, para aprovechar plenamente estas tecnologıas, e impulsarsu potencial de competitividad, impactando positivamente a nivel economicoy social.3

Este reto de fomentar la innovacion en el paıs, involucrando las TIC,conlleva a la incursion al mundo web y al reconocimiento de la importanciaque tiene la informacion que se suministra en el ciberespacio, siendo esta unafuente primordial para que los desarrolladores puedan crear nuevas formas dedarle uso a los datos, y ası ampliar las oportunidades de brindar y encontrarcualquier informacion que se ajuste a las necesidades.4

Es por ende, que el tema principal en el cual se enfoca el presente pro-yecto, es el estudio acerca de los distintos tipos de portales web, con el finde lograr combinar exitosamente en un mismo portal, una web que brin-de no solo Productos y Servicios Informaticos, sino tambien espacios parael Conocimiento, la Investigacion y el Desarrollo en Ingenierıa de Software,que permitan a su vez, una retroalimentacion entre la comunidad web, y elfomento en el uso de estas herramientas para el autoaprendizaje.

1.1. PLANTEAMIENTO DEL PROBLEMA

De acuerdo al Plan Vive Digital 2014-2018 (“Plan de tecnologıa para losproximos cuatro anos en Colombia, que busca que el paıs de un gran saltotecnologico mediante la masificacion de Internet y el desarrollo del ecosistemadigital nacional”)5, la educacion y el comercio en Colombia han tenido gran-des avances, encontrando como cada vez se le da mayor prioridad a integrarlas TIC en el aprendizaje, la Investigacion y la generacion de conocimiento.Ası mismo, este plano de desarrollo tecnologico local se esta fomentando demanera muy fuerte, principalmente en el uso de la web para el crecimiento

3Ibıdem.4REVISTA ENTER.CO. Tim Berners-Lee se preocupa por internet. Pagina web version

HTML. Septiembre 15 de 2010. [citado 13 de septiembre de 2014]. Disponible en inter-net: http://www.enter.co/chips-bits/smartphones/tim-berners-lee-se-preocupa-por-internet/

5PORTAL VIVE DIGITAL COLOMBIA. El Plan Vive Digital. Pagina web versionHTML. [citado el 19 de septiembre de 2014]. Disponible en internet: http://www.mintic.gov.co/portal/vivedigital/612/w3-propertyvalue-6106.html

http://www.enter.co/chips-bits/smartphones/tim-berners-lee-se-preocupa-por-internet/

http://www.enter.co/chips-bits/smartphones/tim-berners-lee-se-preocupa-por-internet/

http://www.mintic.gov.co/portal/vivedigital/612/w3-propertyvalue-6106.html

http://www.mintic.gov.co/portal/vivedigital/612/w3-propertyvalue-6106.html


economico, la evolucion y la alta competitividad de las empresas.6

Cabe resaltar, que no existe una consideracion que unifique propiedadesemergentes de las dos areas a las que se hace alusion en este texto (Sectoreducativo y sector empresarial). No obstante, se relacionan a partir del reco-nocimiento y la importancia que puede alcanzar la investigacion academicay el conocimiento, cuya retroalimentacion brinde bases para el fomento deldesarrollo e innovacion en el ambito empresarial.

Por ejemplo, en la actualidad se cuenta con un prototipo de Portal Em-presarial de Productos y Servicios informaticos, conocido como Colosoft. Sinembargo, su estructura basada en el principio de simplicidad, no cuenta auncon un modulo dinamico de gestion de usuarios, que posibilite la creacionde una comunidad de conocimiento en torno al area de ingenierıa de softwa-re, ni tampoco con un modulo que gestione agilmente la comercializacion deproductos. Es aquı donde se hace necesario crear extensiones, que permitanmanejar tanto el modulo de comercializacion del producto, como el modulode creacion de una comunidad academica de investigacion y desarrollo.

1.2. OBJETIVOS

1.2.1. Objetivo General

Desarrollar un prototipo funcional de software para la creacion de un por-tal empresarial que permita la comercializacion de productos informaticos,y a su vez sirva de espacio para la generacion de conocimiento compartidoy el suministro de herramientas que contribuyan al crecimiento personal yacademico de los usuarios de dicho portal.

1.2.2. Objetivos Especıficos

Implementar una pasarela de pagos para optimizar las transacciones decompra y adquisicion del software que se realicen en el portal.

6REVISTA ENTER.CO. El pasado, presente y futuro de la tecnologıa en Colom-bia. Pagina web version HTML. Julio 9 de 2014. [citado 13 de septiembre de 2014].Disponible en internet: http://www.enter.co/cultura-digital/colombia-digital/el-pasado-presente-y-futuro-de-la-tecnologia-en-colombia/

http://www.enter.co/cultura-digital/colombia-digital/el-pasado-presente-y-futuro-de-la-tecnologia-en-colombia/

http://www.enter.co/cultura-digital/colombia-digital/el-pasado-presente-y-futuro-de-la-tecnologia-en-colombia/


Crear un modulo que permita la interaccion entre los diferentes usua-rios del portal, que contribuya a la conformacion de una comunidadacademica en ingenierıa de software.

Proporcionar un canal eficaz para facilitar la comunicacion entre so-porte tecnico y el usuario cuando este lo requiera.

Abrir un espacio para la Base de Datos de Conocimiento (Wiki), quepermita el libre acceso a los conocimientos en torno a la ingenierıa desoftware.

Proporcionar una plataforma web que sea ampliamente accesible y facilde usar, de tal forma que el usuario consiga su objetivo agil y eficien-temente.

1.3. JUSTIFICACION

Desde las predicciones de las grandes consultoras mundiales de TI -Gartner,Forrester, IDC, McKinsey...- empresas de infraestructuras TI, desarrollo desoftware o de seguridad informatica, tales como Cisco, McAfee, Panda Se-curity, Kaspersky, CA Technologies, hasta sus informes a nivel mundial ylocal (Mexico, Espana, Colombia, Argentina) apuestan por la computacionen nube como una de sus mayores prioridades y aconsejan a las empresas yorganizaciones que en la epoca de crisis economica actual, las opciones queofrece la nube son las mejores soluciones tecnologicas para ellas, a la vez queles supone una gran reduccion de costes en sus economıas corporativas.7

Ası mismo, en el contexto de la sociedad del conocimiento, las tecno-logıas de uso educativo se han convertido en un soporte fundamental parala instruccion, beneficiando ası a un universo cada vez mas amplio de perso-nas. Esta asociacion entre tecnologıa y educacion no solo genera mejoras decaracter cuantitativo (capacidad de ensenar a cada vez mas personas), sinotambien y principalmente mejoras de orden cualitativo: los educadores en-cuentran en Internet nuevos recursos y posibilidades de enriquecer su proceso

7JOYANES AGUILAR, Luis. Computacion en la nube: estrategias de Cloud Computingen las empresasas. 2a ed. Mexico: Alfaomega, 2012, p. 2.


de aprendizaje. 8

De esta forma, es posible visualizar la manera como estas herramientasestimulan la experimentacion, reflexion y la generacion de conocimientos in-dividuales y colectivos, que favorecen la conformacion de un ciberespacio decreatividad y que contribuyen a crear un entorno de aprendizaje colaborativo.

Teniendo en cuenta estas tendencias de evolucion tecnologica y los canalesde informacion, se pretende la creacion de una comunidad especializada en untema de investigacion y conocimiento, que gire en torno a un producto final,que contribuyan a la elaboracion de nuevas investigaciones, creando ası uncırculo de conocimiento”que aporte nueva informacion al tema especıfico In-genierıa de Software.

8COBO ROMANI, Cristobal. PARDO KUKLINSKI, Hugo. Planeta Web 2.0. Inteli-gencia Colectiva o Medios Fast Food. E-Book de acceso gratuito. Vesrion 0.1. Grup deRecerca d’Interaccions Digitals, Universitat de Vic, 2007, p. 101 - 102.

Capıtulo 2

LA METODOLOGIA AGIL

2.1. EL MANIFIESTO AGIL

El manifiesto agil es un escrito breve de un grupo pequeno de desarrolla-dores, consultores e ingenieros de software, donde relatan doce principios parasatisfacer la necesidad de una alternativa a la documentacion en el desarrollode los procesos de software, libre de ataduras hacia las corporaciones duenasde los procesos de documentacion. Entre las metodologıas que representaneste manifiesto, se encuentran algunas como: Extreme Programming (XP),SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-DrivenDevelopment y Pragmatic Programming.

Los autores de este manifiesto, reunieron sus ideas en torno a una necesi-dad de manejo agil y completo de la documentacion del desarrollo de software.Es ası que en febrero de 2001, en Utah, Estados Unidos, se reunieron paracrear dicho manifiesto, dejando sus ideas claras y al alcance de cualquier nue-vo desarrollador, consultor, ingeniero, o cualquier rol que necesite crear unadocumentacion de un proceso de desarrollo de software.1

1BECK, Kent; BEEDLE, Mike; VAN BENNEKUM, Arie; COCKBURN, Alistair;CUNNINGHAM, Ward; FOWLER, Martin; GRENNING, James; HIGHSMITH, Jim;HUNT, Andrew; JEFFRIES, Ron; KERN, Jon; MARICK, Brian; MARTIN, RobertC.; MELLOR, Steve; SCHWABER, Ken; SUTHERLAND, Jeff; THOMAS, Dave. Ma-nifesto for Agile Software Development. Sitio Web sobre los principios de las metodo-logias agiles. 2001. [citado 7 de noviembre de 2014]. Disponible en internet: http://agilemanifesto.org/

20

http://agilemanifesto.org/

http://agilemanifesto.org/

CAPITULO 2. LA METODOLOGIA AGIL 21

Cabe resaltar, que el manifiesto se ha puesto en Internet, para el cono-cimiento global, y a su vez permite ser firmado por nuevos representantes,lo que genera un soporte a la hora de documentar el proceso de desarrollosoftware, y permite a su vez la generacion de nuevas ideas.

Entre los autores, se encuentran personas como2:

Beedle, Mike: Fundador y CEO de e-Architects Inc., una empresa deconsultorıa que se especializa en el desarrollo de aplicaciones utilizandoobjetos distribuidos y tecnologıas de Internet. A pesar de las demandasdel negocio de Mike, se ha mantenido como consultor en donde se aplicaSCRUM y XP. Tuvo el privilegio de ser los primeros en adoptar elmetodo SCRUM, y ha introducido SCRUM a 7 organizaciones desdemediados de los 90.

Van Bennekum, Arie: Ha participado activamente en DSDM y elConsorcio DSDM desde 1997. Antes de eso habıa estado trabajandocon desarrollo rapido de aplicaciones. Su pasion por los metodos agilesse basa en ofrecer a los clientes lo que realmente necesitan de unamanera que realmente se adapte a los usuarios finales y las empresas.En este momento en el tiempo es miembro de la junta directiva deDSDM Consortium Benelux y acreditado como practicante, entrenador,y consultor DSDM.

Cockburn, Alistair: El trabajo de Alistair en la decada de 1990 seconvirtio en la familia Crystal de metodologıas agiles. Alistair y JimHighsmith ahora estan trabajando juntos para llevar a Crystal un pocomas alla, generando ideas de adaptacion para la creacion de ecosistemasde desarrollo de software agiles.

Cunningham, Ward: Es uno de los fundadores de Cunningham &Cunningham, Inc. Tambien se ha desempenado como Director de I + Den Wyatt Software y como Ingeniero de Principios en el Laboratorio deInvestigacion de Informatica Tektronix. Ward, es bien conocido por suscontribuciones a la practica del desarrollo de la programacion orientadaa objetos, la variacion llamada Extreme Programming.

Fowler, Martin: Cientıfico jefe para ThoughtWorks, una empresa dedesarrollo de aplicaciones y consultorıa. El ha estado involucrado desde

2Ibıdem.


hace mas de una decada en el uso de tecnicas orientadas a objetos paralos sistemas de informacion.

Highsmith, Jim: Desarrollador principal del metodo agil “AdaptativeSoftware Development”, y autor de un libro con el mismo nombre.Autor de varios libros sobre los metodos agiles.

Hunt, Andrew: Socio en The Pragmatic Programmers , y co-autordel libro: “The Pragmatic Programmer: From Journeyman to Mas-ter. Es fundador de su propia empresa de consultorıa especializada enel desarrollo de software agil. Andy ha estado desarrollando softwareprofesionalmente desde principios de los anos 80 a traves de diversasindustrias tales como telecomunicaciones, banca, servicios financieros,servicios publicos, imagen medica, artes graficas, y los servicios de In-ternet.

Jeffries, Ron: Consultor con objeto de Mentor , y el autor (con AnnAnderson y Chet Hendrickson) de Extreme Programming Installed.Ron fue el primer mentor de la programacion extrema, y es un contri-buidor prolıfico a los grupos de Internet relacionados con la metodologıaXP, y un orador frecuente en conferencias de software. Es propietariode XProgramming.com, sitio web especializado en la metodologıa XP.

Kern, Jon: Publico su metodologıa de desarrollo iterativo ligero enguıas de desarrolladores para Lotus Notes 4.5 y 5.0. Puso sus tecnicaspara trabajar en proyectos del Departamento de Defensa, y luego a supropia empresa (Lightship Inc.). En 1999, se unio a Peter Coad parala puesta en marcha de TogetherSoft, donde creo el grupo de mentoresprofesionales, y el desarrollo guiad de productos.

Marick, Brian: Programador y consultor de pruebas software. Repre-sentante de una parte de la comunidad de los consultores de pruebassoftware, que han desarrollado un estilo de pruebas mas sencillo, dis-minuyendo la dependencia de la documentacion, y el aumento de laaceptacion del cambio.

Martin, Robert: Profesional de software desde 1970. Es presidentey fundador de Object Mentor Inc. una firma de consultores altamenteexperimentados que ofrecen XP y consultorıa de procesos agiles, soft-ware de consultorıa de diseno, capacitacion y servicios de desarrollo a


las grandes corporaciones de todo el mundo. Ha publicado decenas deartıculos en diversas revistas especializadas, y es un ponente habitualen conferencias internacionales y ferias comerciales.

Schwaber, Ken: Presidente Advanced Development Methods (ADM),una empresa dedicada a la mejora de la practica de desarrollo de soft-ware. El es un desarrollador con experiencia de software, gerente deproductos, y consultor. Schwaber inicio la revolucion de productos degestion de procesos de la decada de 1990 y tambien trabajo con JeffSutherland para formular las versiones iniciales del proceso de desa-rrollo de SCRUM. En los ultimos cinco anos ha formalizado SCRUM,ayudado a muchas organizaciones desplegar con exito los productos ysistemas que utilizan dicha metodologıa.

Sutherland, Jeff: es Director de Tecnologıa de PatientKeeper, unacompanıa que proporciona aplicaciones moviles e inalambricas para loscentros clınicos. Ha sido director de tecnologıa o Vicepresidente de In-genierıa en nueve companıas de tecnologıa de software e introdujo unmejorado concepto sobre los procesos de desarrollo agiles para cadauno de ellos. Su trabajo en grandes proyectos de software, basadas encomponentes, ha dado lugar a innovaciones en la banca, los seguros, lossistemas de bibliotecas, la industria aeroespacial, la companıa aerea ylos aviones de arrendamiento, ingenierıa nuclear, y la robotica.

Literalmente, el manifiesto agil ha sido firmado de la siguiente mane-ra: “Estamos descubriendo formas mejores de desarrollar software tanto pornuestra propia experiencia como ayudando a terceros. A traves de este tra-bajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentacion extensiva

Colaboracion con el cliente sobre negociacion contractual

Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos mas losde la izquierda.”3

3Ibıdem.


Los principios con los que cuenta el manifiesto agil, y que han repercutidoen todas las metodologıas agiles de desarrollo de software, son:

La mayor prioridad es satisfacer al cliente mediante la entrega tempranay continua de software con valor.

Se aceptan cambios en los requisitos, incluso en etapas tardıas del desa-rrollo. Los procesos Agiles aprovechan el cambio para proporcionar ven-taja competitiva al cliente.

Se hace entrega de software funcional frecuentemente, entre dos se-manas y dos meses, con preferencia al periodo de tiempo mas cortoposible.

Los responsables de negocio y los desarrolladores trabajan juntos deforma cotidiana durante todo el proyecto.

Los proyectos se desarrollan en torno a individuos motivados.

El metodo mas eficiente y efectivo de comunicar informacion al equipode desarrollo y entre sus miembros, es la conversacion cara a cara.

El software funcionando es la medida principal de progreso.

Los procesos Agiles promueven el desarrollo sostenible. Los promotores,desarrolladores y usuarios deben ser capaces de mantener un ritmoconstante de forma indefinida.

La atencion continua a la excelencia tecnica y al buen diseno mejora laAgilidad.

La simplicidad, o el arte de maximizar la cantidad de trabajo no reali-zado, es esencial.

Las mejores arquitecturas, requisitos y disenos emergen de equiposauto-organizados.

A intervalos regulares, el equipo reflexiona sobre como ser mas efecti-vo para a continuacion ajustar y perfeccionar su comportamiento enconsecuencia.


Figura 2.1: Proceso de desarrollo XP, Tomada del libro Software Engineering:A Practitioner’s Approach - Pressman, Roger S.

2.2. METODOLOGIA XP (“EXTREME PRO-GRAMMING”)

La programacion extrema (eXtreme Programming - XP) es un proceso dedesarrollo de software, incluido como disciplina en la ingenierıa de software.Kent Beck fue el primer autor de acunar el termino en su libro .Extreme Pro-gramming Explained: Embrace Change”(1999). Es posiblemente el metodoagil mas conocido y ampliamente utilizado. Se diferencia de las metodologıastradicionales principalmente en que pone mas enfasis en la adaptabilidadque en la previsibilidad, esto quiere decir que se enfoca mas en los proce-sos emergentes que puedan surgir sobre el desarrollo, que en el analisis derequerimientos inicial. Los defensores de XP consideran que los cambios derequisitos sobre la marcha son un aspecto natural, inevitable e incluso desea-ble del desarrollo de proyectos.


El aspecto mas sorprendente de la programacion extrema son sus reglassimples. Es muy parecido a un rompecabezas: hay muchas piezas pequenasque individualmente no tienen sentido, pero cuando se combinan juntas uncuadro completo puede ser visto. Las reglas pueden parecer torpes y tal vezincluso ingenuas al principio, pero se basa en valores y principios solidos. 4.

La metodologıa XP esta basada en los valores de la simplicidad, la co-municacion, la retroalimentacion, el coraje y el respeto. Su accion consisteen traer todo el equipo juntos en la presencia de practicas simples, con sufi-ciente informacion para permitir que el equipo para ver donde estan y parasintonizar las practicas a su situacion particular.5.

Figura 2.2: Proceso de XP para producir un incremento, Tomada del libroIngenierıa del software - Sommerville, Ian.

Los valores de la programacion extrema son6:

Simplicidad:Base de la programacion extrema. Se simplifica el diseno para agilizar eldesarrollo y facilitar el mantenimiento. Un diseno complejo del codigojunto a sucesivas modificaciones por parte de diferentes desarrolladores

4WELLS, Don http://www.extremeprogramming.org/. Extreme Programming:Agentle introduction. October 8, 2013

5JEFFRIES, Ron. http://www.extremeprogramming.org/. Extreme Programming:Agentle introduction. October 8, 2013

6Software Engineering: A Practitioner’s Approach – 6th edition – PRESSMAN, RogerS. – New York, United States – Mc Graw Hill – 2005 – p. 78 – 81

http://www.extremeprogramming.org/

http://www.extremeprogramming.org/


hacen que la complejidad aumente exponencialmente. Para mantener lasimplicidad es necesaria la refactorizacion del codigo, esta es la manerade mantener el codigo simple a medida que crece. Tambien se aplicala simplicidad en la documentacion, de esta manera el codigo debecomentarse en su justa medida.

Comunicacion:La comunicacion se realiza de diferentes formas. Para los programado-res el codigo comunica mejor cuanto mas simple sea. Si el codigo escomplejo hay que esforzarse para hacerlo inteligible. Las pruebas uni-tarias son otra forma de comunicacion ya que describen el diseno delas clases y los metodos al mostrar ejemplos concretos de como utili-zar su funcionalidad. Los programadores se comunican constantementegracias a la programacion por parejas. La comunicacion con el clien-te es fluida ya que el cliente forma parte del equipo de desarrollo. Elcliente decide que caracterısticas tienen prioridad y siempre debe estardisponible para solucionar dudas.

Retroalimentacion (feedback):Al estar el cliente integrado en el proyecto, su opinion sobre el estadodel proyecto se conoce en tiempo real. Al realizarse ciclos muy cortostras los cuales se muestran resultados, se minimiza el tener que rehacerpartes que no cumplen con los requisitos y ayuda a los programadoresa centrarse en lo que es mas importante. El codigo tambien es unafuente de retroalimentacion gracias a las herramientas de desarrollo.Por ejemplo, las pruebas unitarias informan sobre el estado de salud delcodigo. Ejecutar las pruebas unitarias frecuentemente premite descubrirfallos debidos a cambios recientes en el codigo.

Coraje:Muchas de las practicas implican coraje. Una de ellas es siempre di-senar y programar para hoy y no para manana. Esto es un esfuerzopara evitar empantanarse en el diseno y requerir demasiado tiempo ytrabajo para implementar todo lo demas del proyecto. El coraje le per-mite a los desarrolladores que se sientan comodos con reconstruir sucodigo cuando sea necesario. Esto significa revisar el sistema existen-te y modificarlo si con ello los cambios futuros se implementaran masfacilmente. Otro ejemplo de coraje es saber cuando desechar un codigo:


Coraje para quitar codigo fuente obsoleto, sin importar cuanto esfuerzoy tiempo se invirtio en crear ese codigo.

Respeto:Este quinto valor, respeto, fue anadido en la segunda edicion del libro.Extreme Programming Explained”(Beck, 1999). El respeto se manifies-ta de varias formas. Los miembros del equipo se respetan los unos aotros, porque los programadores no pueden realizar cambios que ha-cen que las pruebas existentes fallen o que demore el trabajo de suscompaneros. Los miembros respetan su trabajo porque siempre estanluchando por la alta calidad en el producto y buscando el diseno optimoo mas eficiente para la solucion a traves de la refactorizacion del codi-go. Los miembros del equipo respetan el trabajo del resto no haciendomenos a otros, una mejor autoestima en el equipo y elevando el ritmode produccion en el equipo.

La programacion extrema implica varias practicas, resumidas en la si-guiente tabla, que se ajustan a los principios de los metodos agiles7:

7SOMERVILLE, Ian. Ingenierıa del software. 7ma ed. Madrid, Espana. 2005. PearsonEducacion S.A. p. 364 – 366.


Principio oPractica

Descripcion

Planificacionincremental

Los requerimientos se registran en historias de usuario, y las historiasa incluir en una entrega se determinan segun el tiempo disponible y suprioridad relativa.

Entregas pe-quenas

Se hacen pequenas y frecuentes mejoras, que anaden, por lo menos, lamınima funcionalidad que proporcione valor de negocio.

Simplicidad ydiseno senci-llo

Es mas sencillo hacer algo simple y tener un poco de trabajo extra paracambiarlo si se requiere, que realizar algo complicado y quizas nuncautilizarlo.

Pruebasunitariascontinuas

Se utiliza un sistema de pruebas de unidad, automatizado, para realizarpruebas en nuevas funcionalidades antes de que estas se implementen,incluyendo pruebas de regresion.

Refactorizacion Se espera que todos los desarrolladores refactoricen el codigo continua-mente tan pronto como encuentren posibles mejoras en el codigo. Estoconserva el codigo sencillo y mantenible.

Programacionen parejas

Los desarrolladores trabajan en parejas, verificando cada uno el trabajodel otro y proporcionando la ayuda necesaria para hacer siempre unbuen trabajo.

Propiedad co-lectiva

Este metodo promueve que todo el personal pueda corregir y exten-der cualquier parte del proyecto. Las frecuentes pruebas de regresiongarantizan que los posibles errores seran detectados.

Integracioncontinua

En cuanto acaba el trabajo en una tarea, se integra en el sistema entero.

Ritmo soste-nible

No se consideran aceptables grandes cantidades de horas extras, ya quea menudo el efecto que tienen es que se reduce la calidad del codigo yla productividad a medio plazo.

Cliente pre-sente

Un representante de los usuarios finales del sistema debe estar siempredisponible al equipo de desarrollo. El cliente es responsable de formularal equipo los requerimientos del sistema para su implementacion.

Cuadro 2.1: Practicas del proceso XP.

Capıtulo 3

MODELOS DE CALIDAD

3.1. DEFINICION DE USABILIDAD

Desde los comienzos de la ingenierıa de software, se observo que la ca-lidad de un producto software esta compuesta por un conjunto de muchosfactores, uno de ellos es la usabilidad. Los modelos de calidad surgen paradescribir dichos factores, sus relaciones, como pueden ser medidos y como lasmediciones pueden ser interpretadas.

Cuando se habla de usabilidad, se refiere a la facilidad con la que unapersona es capaz de llevar a cabo una accion, tarea o proceso utilizando unsitio Web o alguno de sus elementos. En esto juega un papel importanteaspectos como el diseno o la organizacion de los contenidos.

La usabilidad es un factor clave en cualquier desarrollo de software, ya quedetermina si los usuarios de dicho software encuentran facilidad o dificultadpara el manejo del mismo, definiendo el exito o fracaso. Ya en estos tiempos delas tecnologıas de la comunicacion y la informacion, la usabilidad se vuelve unfactor clave en cuanto a un desarrollo Web se refiere, puesto que sus usuariosya no se reducen a los pocos que adopten su software, sino que se extiende alnumero de usuarios que accedan a traves de Internet a dicha pagina, siendomuy importante ganar la atencion de muchos usuarios, garantizando el exitoo fracaso de un sitio Web.

Algunas metricas aportan informacion sobre el comportamiento del usua-rio en el sitio Web, como el promedio de tiempo en una pagina, a partir del

30

CAPITULO 3. MODELOS DE CALIDAD 31

cual se deduce que si es elevado, entonces le intereso el contenido, o el numerode clicks que ha hecho para desplazarse a otros modulos del sitio Web juntocon el analisis del mapa de calor de la pagina, lo cual indica que tan facil yacertado es el sitio para satisfacer los movimientos del usuario.

3.2. EVOLUCION DE LA DEFINICION DEUSABILIDAD

El concepto de usabilidad ha supuesto un reto para los creadores de losestandares durante los ultimos 20 anos. Existen diferentes interpretacionesrelacionadas con el uso profesional, que dieron lugar a que la usabilidad sedefina de diferente manera en el estandar ISO de calidad del software y enlos estandares de ergonomıa.

La definicion original de la usabilidad en el estandar ISO / IEC 9126(1991) fue en terminos de los atributos de un producto que hacen que estesea facil de usar:

“Usabilidad (Usability): Conjunto de atributos que estan relacionadoscon el esfuerzo necesario para utilizar el producto software y con la evaluacionindividual de cada uso, por un conjunto de usuarios establecidos o implıcitos.”

En los ultimos anos han ido surgiendo modelos de calidad que incluyen lausabilidad entre sus caracterısticas. Dichos modelos se pueden clasificar endos categorıas: aquellos que han sido definidos propiamente por una estruc-tura propuesta por el mismo autor, o bien, aquellos basados en estandaresexistentes tales como la norma ISO/IEC 9241-11 (1998) o la ISO/IEC 9126-1(2001).

Existe una gran variedad de modelos de calidad propuestos que contem-plan la usabilidad como una de sus caracterısticas, pero cada uno suele des-componerla en distintas subcaracterısticas. Entre los modelos de calidad de-finidos desde cero encontramos los siguientes trabajos:

McCall (1977): Los atributos claves de un producto final desde el puntode vista del usuario son los denominados factores de calidad; estos fac-tores fueron clasificados en tres grupos principales: Revision del produc-to (mantenibilidad, flexibilidad), transicion del producto (portabilidad,interoperabilidad) y operacion del producto (usabilidad, eficiencia).


Nielsen (1993): Su modelo es bastante detallado, centrado en los con-ceptos de aceptabilidad social y aceptabilidad practica; Allı se definela usabilidad como una subcaracterıstica de la aceptabilidad practica.Mantiene que la usabilidad puede ser descompuesta en los atributos: fa-cilidad de aprendizaje, eficiencia de uso, facilidad para recordar, erroresmınimos y atraccion subjetiva.

Dromey (1998): Plantea un modelo de calidad basado en comporta-mientos y usos. Donde un comportamiento es algo que posee el softwarepara una determinada tarea, y los usos son las acciones de los usuarioscon el software.

3.2.1. Norma ISO/IEC 9241-11 (1998)

Esta norma, parte de la serie ISO 9241, ofrece una primera definicionformal de usabilidad que se usara en los estandares posteriores.

Define la usabilidad en terminos de efectividad, eficiencia y satisfacciondel usuario, en un contexto de uso especıfico, es decir, mide el grado en queun producto puede ser usado por determinados usuarios para conseguir unoo varios objetivos especıficos.1

FACTOR DESCRIPCIONEfectividad Capacidad, exactitud y exhaustividad que

pueda tener el usuario de lograr objetivos es-pecıficos.

Eficiencia Recursos empleados en relacion con la exacti-tud y la exhaustividad con la que los usuarioscumplen sus metas.

Satisfaccion Libertad de manipulacion, y actitudes posi-tivas hacia el uso del producto.

Cuadro 3.1: Sub Factores de Usabilidad en Norma ISO/IEC 9241-11.

1ISO WEB SITE. Standar ISO/IEC 9241-11. Pagina web version HTML. 2008. [citado07 de noviembre de 2014]. Disponible en internet: http://www.iso.org/iso/home/store/catalogue tc/catalogue detail.htm?csnumber=16883

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=16883



Esta norma explica los beneficios de la medicion de la usabilidad en termi-nos de rendimiento y satisfaccion del usuario. Estas se miden por el gradoen que se alcanzan las metas previstas de utilizacion, los recursos que tienenque ser gastados para alcanzar los objetivos previstos, y la medida en la queel usuario encuentra el uso del producto aceptable.

Esta norma ha contribuido como base a otros modelos de calidad comolos de:

Van Welie (1999): Su modelo se presenta estructurado en tres capas: Enla capa superior estan los factores que pertenecen a la norma ISO/IEC9241-11: Eficiencia, Efectividad y Satisfaccion. En la segunda capa seencuentra un conjunto de indicadores de usabilidad, que se puedenponer en practica durante una monitorizacion: Facilidad de aprendizaje,errores de seguridad, satisfaccion, rendimiento y facilidad para recordar.Por ultimo, en la capa inferior estan los mecanismos, los cuales nose pueden observar en las pruebas de usuario, pero que pueden serutilizados en heurısticas para mejorar los indicadores de uso.

Abran (2003): No solo toma la norma ISO/IEC 9241-11, sino que laintegra con otras caracterısticas, como por ejemplo aprendizaje y se-guridad, provenientes de la ISO/IEC 9126-1. Este modelo posee unaestructura jerarquica de caracterısticas, que se descomponen en subca-racterısticas, y a su vez estas se descomponen en atributos medibles.

3.2.2. Norma ISO/IEC 9126-1 (2001)

Esta norma proporciona un modelo de calidad del producto software don-de la usabilidad es una de las caracterısticas de primer nivel, y esta a su vez esdescompuesta en cuatro subcaracterısticas: Comprension, facilidad de apren-dizaje, operatividad, y grado de atraccion. Ademas de definir el concepto de“calidad de uso” como la capacidad del producto software para permitir alos usuarios alcanzar sus objetivos especıficos con efectividad, productividad,satisfaccion y seguridad.2

2ISO WEB SITE. Standar ISO/IEC 9126-1. Pagina web version HTML. 2003. [citado 07de noviembre de 2014]. Disponible en internet: http://www.iso.org/iso/home/store/catalogue tc/catalogue detail.htm?csnumber=22750




FACTOR DESCRIPCIONComprension Evalua que tan facil es para el usuario

comprender el funcionamiento del sis-tema.

Facilidad de Aprendizaje Determina que tan facil es para el usua-rio aprender a utilizar el sistema.

Operatividad Determina si el usuario puede utilizarel sistema sin mucho esfuerzo.

Grado de Atraccion Verifica que tan atractiva se ve la inter-faz de la aplicacion.

Cuadro 3.2: Sub Factores de Usabilidad en Norma ISO/IEC 9126-1.

Se encuentran modelos que han estado basados en parte por esta norma,como por ejemplo:

Franch y Carvallo (2003): Estos autores presentan un modelo de ca-lidad orientado a productos software empaquetados (ERP, bibliotecasde estructuras de datos, etc). El modelo esta basado en las caracterısti-cas presentes en la norma ISO/IEC 9126-1: funcionalidad, fiabilidad,usabilidad, eficiencia, mantenibilidad y portabilidad. Estas caracterısti-cas se descomponen en subcaracterısticas que toman como referenciala misma norma ISO/IEC 9126-1, pero se incorporan modificaciones(tales como anadir nuevas subcaracterısticas, refinar existentes, etc.)para adaptarlas segun que tipo de software empaquetado sea. Cadasubcaracterıstica se descompone en atributos, definiendo las relacio-nes existentes entre ellos mismos y asociandoles metricas capaces decuantificarlos.

Abrahao e Insfran (2006): Han propuesto un modelo de calidad basadoen la ISO/IEC 9126-1, centrado solo en la usabilidad, siendo el unicomodelo integrado en las fases tempranas de un proceso de desarrollo.Se adopto la misma estructura jerarquica de la norma, pero descompo-niendo con mas detalle las subcaracterısticas que definen la usabilidad(Comprension, facilidad de aprendizaje, operatividad y grado de atrac-cion) en otras subcaracterısticas, y estas en atributos medibles.


3.2.3. Norma ISO/IEC 25000 ”SQUARE”(2005)

La meta perseguida en la creacion de esta norma es dar un paso hacia unconjunto de estandares organizados de manera mas logica, enriquecidos connuevas aportaciones y unificados con respectos a las normas anteriores paraser capaces de cubrir los dos principales procesos: especificacion de requisitosde calidad del software y evaluacion de la calidad del software, soportadospor un proceso de medicion. SQuaRE se centra exclusivamente en el pro-ducto software y establece criterios para su especificacion, su medicion y suevaluacion.

La calidad del producto, junto con la calidad del proceso, es uno de losaspectos mas importantes actualmente en el desarrollo de Software. Relacio-nada con la calidad del producto, recientemente ha aparecido la familia denormas ISO/IEC 25000, que proporciona una guıa para el uso de la nuevaserie de estandares internacionales llamada Requisitos y Evaluacion de Ca-lidad de Productos de Software (SQuaRE - System and Software QualityRequirements and Evaluation).

ISO/IEC 25000 constituye una serie de normas basadas en ISO/IEC 9126y en ISO/IEC 14598 cuyo objetivo principal es guiar el desarrollo de los pro-ductos de software mediante la especificacion de requisitos y evaluacion decaracterısticas de calidad. ISO/IEC 25000, conocida como SQuaRE (Systemand Software Quality Requirements and Evaluation), es una familia de nor-mas que tiene por objetivo la creacion de un marco de trabajo comun paraevaluar la calidad del producto software. Esta familia de normas ISO/IEC25000 se encuentra compuesta por cinco divisiones.3

ISO/IEC 2500n – Division de Gestion de Calidad Las normas queforman este apartado definen todos los modelos, terminos y definiciones co-munes referenciados por todas las otras normas de la familia 25000. Actual-mente esta division se encuentra formada por4:

ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la arqui-tectura de SQuaRE, la terminologıa de la familia, un resumen de las

3PORTAL ISO 25000: Calidad del producto software. Normas ISO 25000. Pagina webversion HTML. 2014. [citado 07 de noviembre de 2014]. Disponible en internet: http://iso25000.com/index.php/normas-iso-25000

4Ibıdem.

http://iso25000.com/index.php/normas-iso-25000

http://iso25000.com/index.php/normas-iso-25000


Figura 3.1: Divisiones de la norma ISO/IEC 25000, Tomada del Portal WebISO 25000.

partes, los usuarios previstos y las partes asociadas, ası como los mo-delos de referencia.

ISO/IEC 25001 - Planning and Management: establece los requisitos yorientaciones para gestionar la evaluacion y especificacion de los requi-sitos del producto software.

ISO/IEC 2501n – Division de Modelo de Calidad Las normas de esteapartado presentan modelos de calidad detallados incluyendo caracterısticaspara calidad interna, externa y en uso del producto software. Actualmenteesta division se encuentra formada por5:

ISO/IEC 25010 - System and software quality models: describe el mo-delo de calidad para el producto software y para la calidad en uso.Esta Norma presenta las caracterısticas y subcaracterısticas de calidadfrente a las cuales evaluar el producto software.

5Ibıdem.


ISO/IEC 25012 - Data Quality model: define un modelo general parala calidad de los datos, aplicable a aquellos datos que se encuentranalmacenados de manera estructurada y forman parte de un Sistema deInformacion.

ISO/IEC 2502n – Division de Medicion de Calidad Estas normasincluyen un modelo de referencia de la medicion de la calidad del producto,definiciones de medidas de calidad (interna, externa y en uso) y guıas practi-cas para su aplicacion. Actualmente esta division se encuentra formada por6:

ISO/IEC 25020 - Measurement reference model and guide: presentauna explicacion introductoria y un modelo de referencia comun a loselementos de medicion de la calidad. Tambien proporciona una guıapara que los usuarios seleccionen o desarrollen y apliquen medidas pro-puestas por normas ISO.

ISO/IEC 25021 - Quality measure elements: define y especifica un con-junto recomendado de metricas base y derivadas que puedan ser usadasa lo largo de todo el ciclo de vida del desarrollo software.

ISO/IEC 25022 - Measurement of quality in use: define especıficamentelas metricas para realizar la medicion de la calidad en uso del producto.

ISO/IEC 25023 - Measurement of system and software product qua-lity: define especıficamente las metricas para realizar la medicion de lacalidad de productos y sistemas software.

ISO/IEC 25024 - Measurement of data quality: define especıficamentelas metricas para realizar la medicion de la calidad de datos.

ISO/IEC 2503n – Division de Requisitos de Calidad Las normas queforman este apartado ayudan a especificar requisitos de calidad que puedenser utilizados en el proceso de elicitacion de requisitos de calidad del productosoftware a desarrollar o como entrada del proceso de evaluacion. Para ello,este apartado se compone de7:

6Ibıdem.7Ibıdem.


ISO/IEC 25030 - Quality requirements: provee de un conjunto de reco-mendaciones para realizar la especificacion de los requisitos de calidaddel producto software.

ISO/IEC 2504n – Division de Evaluacion de Calidad Este apartadoincluye normas que proporcionan requisitos, recomendaciones y guıas parallevar a cabo el proceso de evaluacion del producto software. Esta division seencuentra formada por8:

ISO/IEC 25040 - Evaluation reference model and guide: propone unmodelo de referencia general para la evaluacion, que considera las entra-das al proceso de evaluacion, las restricciones y los recursos necesariospara obtener las correspondientes salidas.

ISO/IEC 25041 - Evaluation guide for developers, acquirers and inde-pendent evaluators: describe los requisitos y recomendaciones para laimplementacion practica de la evaluacion del producto software desdeel punto de vista de los desarrolladores, de los adquirentes y de losevaluadores independientes.

ISO/IEC 25042 - Evaluation modules: define lo que la Norma consideraun modulo de evaluacion y la documentacion, estructura y contenidoque se debe utilizar a la hora de definir uno de estos modulos.

ISO/IEC 25045 - Evaluation module for recoverability: define un modu-lo para la evaluacion de la subcaracterıstica Recuperabilidad (Recove-rability).

ISO/IEC 25050 a ISO/IEC 25099 La division de extension de SQua-RE (ISO/IEC 25050 a ISO/IEC 25099) se reserva para normas o informestecnicos que aborden dominios de aplicacion especıficos o que puedan serutilizados para complementar otras normas de la familia SQuaRE.9

8Ibıdem.9Ibıdem.

Capıtulo 4

METAPROCESO

Para llegar a la definicion de metaproceso es conveniente establecer elcontexto que nos permita acercarnos al concepto

4.1. MODELO DE PROCESO

Cuando se hace referencia al concepto de modelo de proceso se hace refe-rencia la proposicion de un marco de actividades organizadas y articuladas,con diferentes estructuras, que buscan establecer un flujo de trabajo parallevar a cabo la solucion de un proyecto. Un modelo de proceso tiene comofinalidad proporcionar un paso a paso para lograr un desarrollo eficaz.

4.2. METODOLOGIAS PARA EL DESARRO-LLO DE SOFTWARE

La metodologıa busca proponer y organizar una serie de acciones y practi-cas que complementen el modelo de proceso, con el fin de hacer mas robustoel proceso de desarrollo de software. Con la experiencia adquirida por la pra-xis y el conocimiento se puede llevar a modelar exitosamente una mezclaentre el proceso y la metodologıa de software que optimice el diseno y laplaneacion dentro del proceso de desarrollo de un software

39

CAPITULO 4. METAPROCESO 40

Para el proceso de desarrollo de software lo que se debe establecer inicial-mente es el diseno y la arquitectura que va a tener el software, para que estediseno se pueda llevar a cabo mas facilmente se han establecido ciertas meto-dologıas, que en si ya proveen una estructura para llevar a cabo exitosamenteel proceso de diseno.

Sin embargo, este entorno es muy cambiante, y dada la evolucion que hatenido la ingenierıa de software se evidencia que el uso de algunos modelosy metodologıas de desarrollo ya establecidas no son suficientes para cum-plir a cabalidad con la planeacion y recursos estipulados al iniciar el procesode desarrollo de software. Cuando surgieron estos modelos que establecenpautas para desarrollar el proceso se vio el gran beneficio que tenıan pa-ra la planeacion y el diseno dentro de todo el proceso, permitiendo inclusoorganizar tanto los recursos fısicos como los humanos necesarios, pero consu constante uso y aplicacion empezo a evidenciarse que generalmente estono es suficiente para planear todo el proceso, ya que el entorno mismo delproceso de desarrollo de software hace que las condiciones varıen mucho, yque al final, despues de un largo proceso de implementacion y de pruebassurjan errores o problemas que no se tuvieron en cuenta en el alcance inicial,y esto lleva a que se consuma mas tiempo y recursos en la solucion de losmismos, para que se evidencie al final que no se cumplio a cabalidad conlos recursos estipulados inicialmente, aumentando tanto el tiempo como losrecursos usados durante todo el proceso.

Los procesos para la realizacion de software son concebidos como lareunion de los pasos y actividades necesarias para la creacion de un pro-ducto informatico, estos procesos modelan las necesidades del mundo real;sin embargo la evolucion en el proceso de desarrollo del software surgen nue-vos pasos que afectan tanto el proceso en el mundo real (como fue concebidooriginalmente), como en el modelo del proceso que se esta aplicando. Bajoesta necesidad es que surge el concepto de metaproceso, este establece lospasos necesarios para que el proceso del mundo real evolucione y se adapte.

El metaproceso de desarrollo de software1 surge como una solucion a losproblemas evidenciados generalmente en los procesos tradicionales, donde nose tienen muy en cuenta las eventualidades que se pueden presentar, propo-

1BOLANOS CASTRO, Sandro Javier; MEDINA GARCIA, Victor Hugo. METAPRO-CESO DE DESARROLLO DE SOFTWARE: EL GRIAL DE LAS METODOLOGIAS.Bogota D.C.: Universidad Francisco Jose de Caldas, 2013


niendo un modelo evolucionado que nace a partir de los procesos originales,pero se complementa con el manejo que se le debe dar a las eventualidadeso emergencias que aparezcan durante todo el proceso, para ası desprenderseun poco de la rigidez que plantea cada modelo.

”La evolucion establece los pasos que afecten tanto el proceso en el mundoreal, como el modelo del proceso, manteniendo consistentes esos posiblescambios.”2

El otras palabras el metaproceso es un concepto que abarca el por que delcomo, donde, quien, cuando, es decir, se trata a la causalidad del procesocomo tal y no al efecto al que se pretende llegar.

Figura 4.1: PQ: (C&D,Q,...)

*Fuente: BOLANOS, Sandro; MEDINA, Vıctor. MetaProceso de Desarrollode Software: El Grial de las Metodologıas y Procesos. 2013.

Dando una vista mas general al tema podemos identificar 3 conceptosque nos ayudan a definir la solucion que plantea el metaproceso a los incon-venientes detectados en los procesos tradicionales

Eleccion

Utilizacion

Creacion2Ibıdem.


La eleccion busca seleccionar el proceso que mas se ajuste a las necesi-dades del proyecto que se quiere tratar. Posteriormente este proceso debeser utilizado y aplicado conforme a su definicion y planteamiento; pero siaun ası no logramos modelar de forma adecuada la solucion que se deseaimplementar, entonces surge el concepto de la creacion, que pretende com-plementar las actividades ya existentes en el proceso original, con actividadesde otros procesos e incluso actividades innovadoras que faciliten y se adaptenmas a las necesidades del proyecto.

“Estas tres caracterısticas en las que un proceso deberıa ser visto es loque establece un dominio mas alla del proceso, o lo que se plantea comoMetaproceso.”3

3BOLANOS CASTRO, Sandro Javier; MEDINA GARCIA, Victor Hugo; SOTO, Jesus.METAPROCESO PARA EL DESARROLLO DE SOFTWARE. Bogota D.C.: UniversidadFrancisco Jose de Caldas, 2013

Capıtulo 5

ANALISIS DEREQUERIMIENTOS

Los requerimientos para un sistema son descripciones de lo que el sis-tema debe hacer, el servicio que ofrece y las restricciones en su operacion.Algunos de los problemas que surgen durante el proceso de ingenierıa derequerimientos son el resultado del fracaso de hacer una separacion clara en-tre esos diferentes niveles de descripcion. Es por eso que se ha concordadohacer la respectiva separacion de los requerimientos, en dos tipos distintos,segun su punto de vista: Requerimientos del punto de vista de usuario, yrequerimientos del sistema.

Los diferentes niveles de requerimientos son utiles debido a que informansobre el sistema a distintos tipos de lector.

5.1. PUNTO DE VISTA DE USUARIO

Los requerimientos del punto de vista de usuario, son enunciados en unlenguaje natural junto con diagramas, acerca de que servicios esperan losusuarios del sistema, y de las restricciones con las cuales este debe operar.En este proyecto, el punto de vista del usuario esta en un contexto generalhacia la finalidad del software, es decir, que los integrantes del equipo delproyecto haran un supuesto de lo que el usuario final espera del sistema,ya que no existe dicha informacion de los usuarios finales, al ser estos usua-

43

CAPITULO 5. ANALISIS DE REQUERIMIENTOS 44

rios virtuales. En un proceso de retroalimentacion al momento de poner enmarcha la aplicacion, se estara dispuesto a recibir comentarios, sugerenciasy opiniones, acerca del contenido de la pagina, pero este proyecto no tienecomo fin hacer el proceso de iteracion para la evolucion del sistema.

5.2. PUNTO DEL SISTEMA

Los requerimientos del sistema son descripciones mas detalladas de lasfunciones, los servicios y las restricciones operacionales del sistema de soft-ware. El documento de requerimientos del sistema, tiene que definir con exac-titud lo que se implementara.

5.2.1. Requerimientos Funcionales

Los requerimientos funcionales para un sistema se refieren a lo que elsistema exactamente debe hacer. Tales requerimientos dependen del tipo desoftware que se este desarrollando, de los usuarios esperados del software ydel enfoque general que adopta la organizacion cuando se escriben los reque-rimientos. Al expresarse como requerimientos del usuario, los requerimientosfuncionales se describen por lo general de forma abstracta que entiendan losusuarios del sistema. Sin embargo, requerimientos funcionales mas especıfi-cos del sistema, detallan las funciones del sistema, sus entradas y salidas, susexcepciones, etc.

Los requerimientos funcionales del sistema varıan desde requerimientosgenerales que cubren lo que tiene que hacer el sistema, hasta requerimien-tos muy especıficos que reflejan maneras locales de trabajar o los sistemasexistentes de una organizacion.

5.2.2. Requerimientos No Funcionales

Los requerimientos no funcionales, como indica su nombre, son requeri-mientos que no se relacionan directamente con los servicios especıficos que elsistema entrega a sus usuarios. Pueden relacionarse con propiedades emer-gentes del sistema, como fiabilidad, tiempo de respuesta y uso de almace-namiento. De forma alternativa, pueden definir restricciones sobre la imple-

CAPITULO 5. ANALISIS DE REQUERIMIENTOS 45

mentacion del sistema, como las capacidades de los dispositivos I/O o lasrepresentaciones de datos usados en las interfaces con otros sistemas.

Los requerimientos no funcionales, como el rendimiento, la seguridad ola disponibilidad, especifican o restringen por lo general caracterısticas delsistema como un todo.

Capıtulo 6

DISENO DEL SOFTWARE

6.1. UNIFIED MODELING LANGUAGE (UML)

Lenguaje Unificado de Modelado, o UML por sus siglas en ingles (UnifiedModeling Language), es un lenguaje de estandares tecnologicos, que con-tiene dentro de su grupo de herramientas, varios modelos visuales para eldiseno, planeacion, y definicion del software. Esta respaldado por el ObjectManagement Group (Consorcio dedicado al establecimiento y actualizacionde estandares tecnologicos). El UML sirve sobre todo para documentar elfuncionamiento deseado de un sistema, y ayuda a los diferentes integrantesde un proyecto de desarrollo de software, a tener claros sus objetivos y prin-cipal finalidad del software. UML es un estandar aprobado por la ISO, enla norma ISO/IEC 19501:2005 (Information technology — Open DistributedProcessing — Unified Modeling Language (UML) Version 1.4.2.). Dentro delamplio catalogo de diagramas que conforman el UML, se encuentra un dia-grama que en especial ha sido implementado en el presente proyecto parala definicion y resolucion de requerimientos, este es llamado el diagrama deCasos de Uso.

6.1.1. Casos De Uso

Normalmente, los requisitos se especifican en listas y estan expresados enterminos de lo que el sistema debe hacer. Estas listas son a menudo agrupadas

46

CAPITULO 6. DISENO DEL SOFTWARE 47

por funcionalidad o subsistemas. Los usuarios ven los sistemas informaticoscomo cajas negras. Este termino implica que la perspectiva de la aplicacionse ocupa solo de lo que entra y lo que sale. El funcionamiento interno no esimportante para la perspectiva de caja negra. Una especificacion de Caso deUso, busca describir el procedimiento que tiene dicho caso de uso internamen-te, esto con el fın de informar detalladamente al lector, lo que se espera que elsistema responda, y adecuando ası la funcionalidad para cubrir la respuestadel sistema a los requerimientos que se han definido anteriormente. Las prin-cipales secciones que definen y describen un caso de uso, y que generalmentese detallan en una especificacion de caso de uso, son:

Nombre del Caso de Uso: Este proporcionara una identificacion unicaal caso de uso, siendo recomendable un identificador unico escrito enlenguaje natural, numeros de identificacion largos tienden a desactivarusuarios.

Resumen: Describe la interaccion que se produce en este caso de uso,proporcionando de forma general el contexto y contenido.

Flujo Basico: Describe los pasos que los actores y el sistema pasan, porlograr el objetivo de este caso de uso. El actor siempre toma la primeraetapa, y luego el sistema responde, esto va de un lado a otro hastaque el objetivo se ha logrado. El curso basico de eventos representa elcamino correcto.a traves del caso de uso, sin errores que puedan serproducidos por el actor o el sistema, y sin caminos alternativos.

Flujo Alternativo: Aquı se muestra y se documentan los caminos me-nos comunes que deben ser abordados y que son generados por un tipoinusual de procesamiento. En general, aquı se definen los posibles ca-minos que puede seguir la interaccion, sin necesariamente ser un error,simplemente se trata de opciones de camino.

Flujo de Excepcion: Al igual que los caminos alternativos, muestran unprocesamiento no frecuente, sin embargo, estos muestran las interac-ciones que se producen cuando ocurre un error.

Flujo de Extension: Estos se despliegan cuando existe relacion entre doscasos de uso, es decir cuando un caso de uso proporciona una secuenciaopcional de eventos que se incluye en el otro caso de uso.


Pre Condiciones: Son las condiciones previas de esta interaccion, lascuales deben generarse antes de que ocurra la interaccion. Estas estanfuera del alcance del caso de uso y del sistema informatico que seesta desarrollando.

Post Condiciones: Ası como las condiciones previas, estan fuera delalcance del caso de uso y son parte de la relacion entre el caso deuso y el mundo exterior. Las poscondiciones deben ser independientesde la vıa alternativa tomada dentro del caso de uso. Un ejemplo deuna condicion posterior es la notificacion de que una transaccion seregistro con exito.

Autor(“es”): Creador(es) del caso de uso.


6.2. EL LENGUAJE ARCHIMATE

ArchiMate es un lenguaje de modelado, que tiene como funcion repre-sentar una arquitectura empresarial de una organizacion establecida. Paraello se apoya en tres perspectivas: negocio, sistemas y tecnologıa, todo estocon el fin de lograr mediar la interaccion entre los expertos del negocio y losexpertos de tecnologıa, para poder poner en marcha proyectos que involucrena estas dos partes y que tengan como fin el crecimiento y/o mejoramiento dela organizacion.ArchiMate establece un conjunto de diagramas y elementos para disenar lasarquitecturas empresariales. Dentro de un proyecto de desarrollo de softwaresirve para apoyar el diseno y la arquitectura de la solucion, proporcionandoherramientas que dejen vislumbrar mas a fondo el nucleo del negocio y quesirvan como apoyo para los procesos y metodologıas de software.

Figura 6.1: Metamodelos en diferentes niveles de especificidad, Tomada dela pagina oficial de The Open Group, http://www.opengroup.org/

“En la base del triangulo encontramos los metamodelos de los conceptosde modelado de arquitectura utilizados por organizaciones especıficas, ası co-mo una variedad de lenguajes y estandares de modelado existente; UML es



un ejemplo de un lenguaje en esta categorıa. En la parte superior del triangu-lo se encuentra el metamodelo ”mas general”para arquitecturas de sistemas,esencialmente un metamodelo que solo comprende nociones como .entidad 2

relacion”.

Capıtulo 7

EJECUCION

7.1. DEFINICION DE REQUERIMIENTOS

Una fase importante en un proyecto de arquitectura de software, es la de-finicion de requerimientos. En el presente proyecto, se han definido los reque-rimientos teniendo en cuenta la teorıa enunciada en el Capitulo 5 (ANALISISDE REQUERIMIENTOS).

7.1.1. Requerimientos Del Punto De Vista De Usuario

Teniendo en cuenta lo anterior, los requerimientos del punto de vista deusuario se han clasificado segun el modulo al cual se le requerira el servicio,estos son: modulo de transacciones, y modulo de comunidad web. Los reque-rimientos del punto de vista de usuario, los ha definido el equipo de proyectode la siguiente manera:

Modulo de transacciones:

• La plataforma permitira que los usuarios puedan visualizar losproductos y el contenido que se ofrecen.

• La plataforma permitira que solo los usuarios registrados puedanacceder a la adquisicion de los productos mencionados anterior-mente.

51

CAPITULO 7. EJECUCION 52

• La plataforma se encargara de realizar la transaccion de pago almomento de adquirir un producto, y generara un comprobante almomento de finalizar dicha transaccion.

• La plataforma brindara a los usuarios que hayan culminado exito-samente el proceso de transaccion, una manera sencilla de realizarla descarga del producto adquirido.

Modulo de comunidad web:

• La plataforma permitira realizar el registro de nuevos usuarios ensu sistema.

• La plataforma estara disponible para que cualquier usuario puedarevisar su base de conocimiento (La wiki, blogs de usuarios, foros).

• La plataforma permitira que solo los usuarios registrados puedanrealizar aportes de conocimiento en la base de conocimiento (Lawiki). Adicional, los usuarios registrados pueden participar de fo-ros y generar sus entradas de blogs, ası como realizar comentariosen estos.

7.1.2. Requerimientos Del Sistema

Los requerimientos del sistema permiten identificar las funcionalidadesbasicas y mas importantes de un sistema. En este proyecto, se han agrupadoen tres categorias, segun su modulo funcional, estos son: General (Refierea las funcionalidades basicas de la plataforma), Modulo de transacciones(Relaciona especıficamente los requerimientos que competen a dicho modulo),y Modulo de comunidad Web (Donde se agrupan los requerimientos que serelacionan a las funcionalidades de comunidad Web).

7.1.2.1. Requerimientos funcionales

Para el proyecto, se definieron los siguientes requerimientos funcionales,agrupados por tipo de servicio que brindara:

General:


• Al momento de ingresar al dominio de la plataforma, el usuariopodra visualizar desde su navegador web los diferentes modulosque existen.

• El sistema debe refrescar la vista de la pagina, cada vez que elusuario seleccione una distinta pestana en la barra de pestanas.Cada pestana es un modulo que existe en la pagina.

• El sistema debe redireccionar al usuario al momento de hacer clicken algun enlace, ya sea para ingresar a la ventana de login del usua-rio (Donde podra acceder como usuario registrado, o podra regis-trarse), para ingresar a los proveedores de servicios (Los proveedo-res de servicio son MediaWiki para el servicio de Wiki, Wordpresspara el servicio de blog, y Simple Machines Forum para el serviciode foro), o abrir una descripcion acerca de la informacion que elusuario busca.

• Se debe hacer control de las sesiones de usuario, esto significa quela plataforma debe ser capaz de permitir al usuario:

◦ Registrarse en el sistema con los siguientes datos obligatorios:Correo Electronico, Contrasena, Confirmacion de Contrasena,Primer Nombre y Primer Apellido.

◦ Ingresar con su id de usuario y su contrasena, proporciona-dos por el sistema segun los datos personales ingresados alsistema.

◦ Mantener su sesion activa mientras el usuario no la finalicepor su cuenta (cerrar sesion o perder la conexion).

◦ Cerrar en definitiva su sesion, salvando ası sus datos persona-les y su actividad hecha en el sistema permanentemente.

Modulo de transacciones:

• El sistema debe tener un modulo de “compras”, al que se le lla-mara modulo de transaccion, donde el usuario registrado puedavisualizar los diferentes productos, asociados por categorıa: Pro-ductos de desarrollo, y productos de investigacion.

• Al momento de que el usuario seleccione el producto a descargar,el sistema debe llevarlo a una pagina donde pueda elegir el metodode pago.


• Cuando el usuario elija el metodo de pago, el sistema lo redireccio-nara a la pasarela de pago implementada, que sera un componentede servicio externo llamado PayU Latam, donde ingresara sus da-tos de pago.

• El sistema debera recibir la confirmacion del componente externo(PayU Latam), para ası generar el comprobante de pago local, condatos necesarios como la fecha y hora de la compra, el valor realcancelado, la referencia de produto, etc.

• Luego de emitir el comprobante de pago, el sistema debe habilitarla descarga del producto seleccionado.

• El sistema debe ser usable al momento de que el usuario registradorealice una compra, esto es, que para el usuario debe ser intuitivoel proceso de seleccion, pago y descarga de un producto.

Modulo de comunidad web:

• El sistema debe tener un modulo de “comunidad”, al que se lellamara modulo de comunidad web, donde el usuario (ya sea re-gistrado o no registrado) puede visualizar los diferentes serviciosde la comunidad colosoft (Wiki, Blogs, Foros).

• Al momento cuando el usuario elija el servicio a usar, el sistemadebe redireccionar al usuario a la pagina del componente de servi-cio externo, ya sea MediaWiki para la Wiki, WordPress para losblogs, y Simple Machines Forum para los foros. El ingreso al conte-nido generado en cada servicio, dependera de cada pagina externa(Si la pagina externa ası lo requiere, el usuario debe registrarse adicha plataforma para ingresar a la totalidad del servicio).

7.1.2.2. Requerimientos no funcionales

Los requerimientos no funcionales, pueden relacionarse con propiedadesemergentes del sistema, como fiabilidad, tiempo de respuesta y uso de alma-cenamiento.

Los requerimientos no funcionales que se han definido para el desarrollode este proyecto, son:


La plataforma estara alojada en un servidor alojado en HostMons-ter.com, las 24 horas los 7 dıas de la semana durante el tiempo dearriendo de dicho servidor. Al momento de realizar este proyecto, elperiodo de arrendamiento expira el 17 de diciembre de 2015. Si ası lodesea el cliente del proyecto, el periodo de arrendamiento sera amplia-do.

Los usuarios del sistema tendran la obligacion de inscribirse al sistemapropio, si desean adquirir productos de la pagina, o contribuir con suconocimiento a la comunidad web.

Los usuarios del sistema deberan estar registrados o tener cuenta ac-tiva en las plataformas de servicios que usara la pagina, tales comoMediaWiki.org para aportar a la base de datos de conocimiento (Wi-ki), WordPress.com para generar sus propios blogs o generar comen-tarios, SimpleMachines.org para poder realizar aportes a foros de lacomunidad.

El sistema implementara provisiones para la privacidad de los datos delusuario.

La plataforma sera capaz de visualizarse desde cualquier navegadorweb.


7.2. CASOS DE USO

7.2.1. Sistema Total

Figura 7.1: Diagrama de Casos de Uso del comportamiento del Sistema

Fuente: Autores.


7.2.2. Sistema En General

Figura 7.2: Diagrama de Casos de Uso Generales

Fuente: Autores.


7.2.2.1. Especificacion de casos de uso del sistema en general

Nombre GEN01 - INICIO DE SESION

Resumen El usuario de la plataforma digita sus datos de ingreso: nom-bre de usuario y contrasena. La plataforma se encarga de va-lidar los datos para iniciar sesion o no.

Flujo (ACTOR)Basico 1. El usuario ingresa a la pagina de login.

3. El usuario ingresa sus datos a los campos correspondientescomo “nombre de usuario” y “contrasena”.4. El usuario da click sobre el boton “inicio”.(SISTEMA)2. El sistema despliega el formulario de login, que esta com-puesto por dos campos: “nombre de usuario” y “contrasena”.Adicional a esto, la ventana de login tambien estara compues-ta de dos botones que son “ingreso” y “cancelar”, y dos enlacesllamados “recordar contrasena” y “registrar nuevo usuario”.5. El sistema valida los datos comparando con su base dedatos.6. El sistema recupera los datos personales del usuario e iniciasesion en la pagina, permitiendo ası al usuario realizar lasacciones para un “usuario registrado”.

FlujoAlternativo

4.1. El usuario no da click sobre el boton “inicio”, en lugar deeso da click sobre el boton “cancelar”.4.2. El sistema se devuelve a la pagina de inicio. En este pasose vuelve al curso normal paso 1.4.1.1. El usuario no da click sobre el boton “cancelar”, en lugarde eso da click sobre el enlace de “recordar contrasena”.4.1.2. El sistema lo redirecciona a un formulario para resta-blecer la contrasena via e-mail.4.1.1.1. El usuario no da click sobre el enlace “recordar con-trasena”, en su lugar da click sobre el enlace “registrar nuevousuario”.4.1.1.2. El sistema lo redirecciona a un formulario para ingre-sar los nuevos datos.


Flujo deExcepcion

5.1. El sistema no valida los datos (No esta registrado en labase de datos, o hubo un error interno de consulta a dichabase de datos).

5.2. El sistema arroja un mensaje de error de inicio de sesiony permite al usuario re escribir sus datos. En este paso, sevuelve al curso normal paso 3.

Flujo de 4.1.2. GEN02 - RESTABLECER CONTRASENAExtension 4.1.1.2. GEN03 - REGISTRAR USUARIO

Pre 1. Tener acceso al servidor de datos.Condiciones 2. Tener una conexion a internet confiable y segura.

PostCondiciones

1. Estar en sesion de usuario activa.

Autores Kevin Eduardo Jamaica GonzalezJuan Gabriel Mora Hernandez

Cuadro 7.1: Definicion de Caso de Uso GEN01.


Nombre GEN02 - RESTABLECER CONTRASENA

Resumen El usuario solicita al sistema que envıe un e-mail de confirma-cion de cambio de contrasena. El usuario realiza el cambio decontrasena para ingresar al sistema.

Flujo (ACTOR)Basico 1. El actor ingresa a la ventana de restablecer contrasena.

3. El usuario ingresa su correo electronico registrado en laplataforma en el campo “correo registrado”.4. El usuario da click sobre el boton “enviar”.7. El usuario ingresa al link que se le ha enviado.9. El usuario ingresa la contrasena en el campo “contrasenanueva”, y la vuelve a ingresar en el campo “confirmar contra-sena”.10. El usuario da click sobre el boton “confirmar”.(SISTEMA)2. El sistema despliega un formulario de restablecimiento decontrasena, compuesto por un campo de texto llamado “correoregistrado”, y dos botones llamados “enviar” y “cancelar”.5. El sistema verifica que el correo electronico se encuentreregistrado en la base de datos.6. El sistema envıa un correo vıa e-mail, al correo que haingresado el usuario, con un link que habilita el cambio decontrasena.8. El sistema despliega un formulario de cambio de contra-sena, con los siguientes campos: “contrasena nueva”, “confir-mar contrasena” y con un boton llamado “confirmar”.11. El sistema confirma la sintaxis de la contrasena ingresadapor el usuario.12. El sistema actualiza la informacion de la contrasena delusuario.13. El sistema despliega un mensaje de culminacion exitosa.

Flujo 4.1. El usuario da click sobre el boton “cancelar”.Alternativo 4.2. El sistema regresa a la pagina de inicio. En este paso,

termina el caso de uso.


Flujo deExcepcion

5.1. El sistema no valida la informacion sobre el correoelectronico ingresado en el campo “correo registrado”, (Noencuentra el dato solicitado, o simplemente hubo un error deconexion).5.2. El sistema genera un mensaje de error que informa alusuario sobre la no existencia de su correo electronico en subase de datos. En este paso, se vuelve al curso normal paso 2.6.1. El sistema no esta en capacidad de enviar un correo vıae-mail. En este paso, se vuelve al curso normal paso 1.11.1. El sistema no confirma que el campo “nueva contrasena”esta bien escrito sintacticamente.11.2. El sistema arroja un mensaje de error al usuario, infor-mando que la contrasena tiene errores. En este paso, se vuelveal curso normal paso 9.12.1 El sistema no actualiza la informacion de la contrasenaen la base de datos (Por que no existe conexion).12.2 El sistema debe informar al usuario que la transaccionno fue exitosa. En este paso, se vuelve al curso normal paso9.

Flujo deExtension

NO APLICA

Pre 1. Tener conexion confiable y segura a internet.Condiciones 2. Servidor de la aplicacion disponible.

PostCondiciones

1. Cambio de la contrasena en la base de datos, para el usuarioactor.




Nombre GEN03 - REGISTRAR USUARIO

Resumen El usuario no tiene cuenta en la plataforma, ası que ingre-sa para registrar sus datos, generar un id de usuario y unacontrasena.

Flujo (ACTOR)Basico 1. El usuario ingresa en la ventana de “registrar nuevo usua-

rio”.3. El usuario ingresa los datos en todos los campos del formu-lario.4. El usuario da click sobre el boton “Aceptar”.

(SISTEMA)2. El sistema despliega una ventana con un formulario con lossiguientes campos obligatorios: “Nombres”, “Apellidos”, “Di-reccion de e-mail”, y los campos opcionales: “Edad”, “Ocu-pacion”, “Institucion”. Adicional, la ventana trae un boton de“Aceptar” y “Cancelar”.5. El sistema valida que los datos ingresados por el usuariosean coherentes con las reglas de validacion.6. El sistema convierte los datos del formulario, en un registrode la Tabla USERS de la base de datos.7. El sistema refresca la vista del usuario, lanzando una ven-tana emergente con un mensaje de culminacion.

FlujoAlternativo

3.1. El usuario solo ingresa los datos obligatorios en el formu-lario. En este paso, se vuelve al curso normal paso 4.4.1. El usuario da click sobre el boton “Cancelar”.4.2. El sistema regresa a la pagina de inicio. En este paso, sesale del caso de uso.


Flujo deExcepcion

3.1. El usuario no ingresa los datos mınimos requeridos (losdatos obligatorios), o ingresa algun campo con un valor noesperado.3.2. El sistema valida dichos datos, y lanza mensajes de erroren los campos que esten vacıos o incorrectos. En este paso, sevuelve al curso normal paso 3.5.1. El sistema pierde la conexion a la base de datos.5.2. El sistema guarda la informacion temporalmente dentrodel formulario, mientras restablece la conexion.

Flujo deExtension

NO APLICA

Pre 1. Tener conexion confiable y segura a internet.Condiciones 2. Servidor de la aplicacion disponible.

PostCondiciones

1. Insercion de nuevo registro en la tabla usuarios.




Nombre GEN04 - VISUALIZACION GENERAL DE LAPAGINA

Resumen El usuario de la plataforma puede visualizar los diferentesmodulos que contiene la pagina.

Flujo (ACTOR)Basico 1. El usuario ingresa a la pagina principal de la plataforma.

3. El usuario interactua con los elementos en la barra de pes-tanas (Da click sobre una pestana cualquiera) .(SISTEMA)2. El sistema carga todos los componentes visuales que con-tiene la pagina: El logo principal de la plataforma, el enlace a“inicio de sesion”, el conjunto de pestanas de cada modulo, yun panel donde se visualiza el contenido del modulo.4. El sistema refresca la visual del usuario, mostrando el panelde contenido del modulo que ha seleccionado el usuario.

FlujoAlternativo

3.1. El usuario puede interactuar con el panel de “Inicio deSesion”.3.2. El sistema despliega la pagina de “inicio de sesion”. Eneste paso, termina el caso de uso actual.5. El usuario puede seguir interactuando con la barra de pes-tanas de la pagina. En este paso, se vuelve al curso basicopaso 3.

Flujo deExcepcion

2.1. El sistema no carga en su totalidad los componentes vi-suales de la pagina de inicio.

Flujo deExtension

6. GEN01 - INICIO DE SESION

Pre 1. Tener acceso al servidor de datos.Condiciones 2. Tener una conexion a internet confiable y segura.PostCondiciones

NO APLICA




7.2.3. Modulo De Transacciones

Figura 7.3: Diagrama de Casos de Uso del comportamiento del modulo detransacciones

Fuente: Autores.


7.2.3.1. Especificacion de casos de uso del modulo de transaccio-nes

Nombre TRA01 - ADQUISICION DE PRODUCTO

Resumen El usuario tiene posibilidad de ingresar al modulo de transac-ciones, y elegir uno de los diferentes productos existentes ydisponibles de las dos categorıas que existen en el modulo:Desarrollo, o Investigacion.

Flujo (ACTOR)Basico 1. El usuario procede a ingresar al modulo de transacciones.

3. El usuario visualiza, interactua y elige alguno de los pro-ductos que esten disponibles y le interesen.6. El usuario procede a hacer click sobre el boton “Aceptar”.8. El usuario, luego de revisar el mensaje de comprobacion,da click al boton “Aceptar” de la ventana de mensaje.

(SISTEMA)2. El sistema despliega diferentes productos que contiene laplataforma, agrupados en categorıas: productos de desarrolloy productos de investigacion.4. El sistema permite al usuario visualizar una breve descrip-cion del producto.5. El sistema anade el boton de “Aceptar” dentro del mismopanel de navegacion entre productos.7. El sistema despliega una ventana de mensaje que realiza lacomprobacion de usuario junto con el nombre del producto,tambien se presentan dos botones, uno de “Aceptar” y el otrode “Cancelar”.9. El sistema realiza una comprobacion interna del usuario,verificando que el usuario este en “sesion de usuario registra-do”.10. Luego de realizar la verificacion de usuario, el sistemaprocede a redireccionar a dicho usuario a la plataforma de lapasarela de pagos.


FlujoAlternativo

6.1. El usuario elige otro producto disponible en la lista. Eneste paso, se vuelve al curso basico de eventos paso 4.8.1. El usuario da click sobre el boton “Cancelar” en lugar dehacerlo sobre el boton “Aceptar”. En este paso, se vuelve alcurso basico de eventos paso 3.

Flujo deExcepcion

10.1. El sistema no encuentra el usuario que intenta acceder,registrado en la base de datos.10.2. El sistema le lanza al usuario una ventana de mensaje,alertando al usuario que no ha iniciado sesion en la platafor-ma. En este paso, se vuelve al curso basico de eventos paso3.

Flujo deExtension

NO APLICA

Pre 1. Tener acceso al servidor de datos.Condiciones 2. Tener una conexion a internet confiable y segura.

PostCondiciones

1. Redireccionamiento a la plataforma del sistema de pasarelade pagos, en donde el usuario dara sus datos de compra.


Cuadro 7.5: Definicion de Caso de Uso TRA01.


Nombre TRA02 - DESCARGA DEL PRODUCTO

Resumen Luego de haber efectuado la transaccion por la plataformade pasarela de pago, el sistema recibe una comprobacion deesta, y permite habilitar la descarga del producto por partedel usuario.

Flujo (ACTOR: PASARELA DE PAGOS)Basico 1. La plataforma de pasarela de pagos, remite al sistema una

comprobacion de que la transaccion ha resultado exitosa.

(SISTEMA)2. El sistema habilita la posibilidad de descarga del producto.3. El sistema notifica al navegador que se realizara la descargadel producto.5. El sistema comienza el proceso de descarga.7. Al finalizar la descarga, el sistema crea un registro de com-probante de transaccion y notifica al usuario que se ha creado.

(ACTOR: USUARIO)4. El usuario autoriza la descarga a traves del navegador.6. El usuario recibe el producto en su maquina.8. El usuario recibe la informacion de la transaccion y quesera guardada en su perfil.

FlujoAlternativo

1.1. La pasarela de pagos no remite notificacion de transaccionexitosa.1.2. El sistema notifica al usuario que no se ha recibido con-firmacion de pago. Lanza una ventana de mensaje con lasopciones de “Reintentar” y “Cancelar”.1.2.1. El usuario elige la opcion “Reintentar”. En este paso, sevuelve a la condicion posterior No 1, del caso de uso TRA01- ADQUISICION DEL PRODUCTO.1.2.2. El usuario elige la opcion “Cancelar”. En este paso, setermina el caso de uso.


Flujo de 1.1. La pasarela de pagos no remite mensaje alguno.Excepcion 1.1.1. El sistema restablece la transaccion con la plataforma.

En este paso, se vuelve al curso basico de eventos, paso 2.1.1.2. El sistema no se logra volver a comunicar con la pasarelade pagos. Aquı el sistema asume que la transaccion se lleva acabo. En este paso, se vuelve al curso basico de eventos, paso3.5.1. El sistema pierde la comunicacion con el usuario.5.2. El sistema deja el producto en estado “activo para ladescarga”, para cuando el usuario quiera realizar la descarga.Esta propiedad define si el producto es descargable o no, yqueda guardada la informacion de dicho validador, en el re-gistro de base de datos. En este paso, se vuelve al curso basicode eventos, paso 3.

Flujo deExtension

NO APLICA

PreCondiciones

1. El usuario debe haber hecho alguna transaccion, exitosa ono, en la plataforma de la pasarela de pagos.2. Tener una conexion a internet confiable y segura.

PostCondiciones

1. El usuario puede descargar ilimitadamente el producto ad-quirido.


Cuadro 7.6: Definicion de Caso de Uso TRA02.


7.2.4. Modulo De Comunidad Web

Figura 7.4: Diagrama de Casos de Uso del comportamiento del modulo decomunidad Web

Fuente: Autores.


Nombre COM01 - APORTAR O CONSULTAR EN LA CO-MUNIDAD

Resumen El usuario tiene la posibilidad de elegir la forma de contribuiro tomar informacion de la comunidad: Acceder a la Wiki, leeralgun blog, o comentando en algun foro.

Flujo (ACTOR)Basico 1. El usuario ingresa al modulo de comunidad web.

3. El usuario elige alguna opcion de aporte a la comunidad.(SISTEMA)2. El sistema permite la visualizacion de los diferentes serviciosque ofrece para la comunidad (Wiki, Blog o Foros), y habilitaenlaces a cada plataforma que presta el servicio.4. El sistema redirecciona al usuario a la plataforma que prestael servicio, ya sea la plataforma MediaWiki para el servicio deWiki, la plataforma Wordpress para el servicio de Blog, o laplataforma Simple Machines Forum para el servicio de Foros.

FlujoAlternativos

3.1. El usuario navega por otras opciones antes de elegir o no,un servicio. En este paso, se vuelve al curso basico de eventospaso 3.

Flujo deExcepcion

NO APLICA

Flujo de 1. Ingreso a la plataforma de servicio de Wiki.Extension 2. Ingreso a la plataforma de servicio de Blog.

3. Ingreso a la plataforma de servicio de Foro.

PreCondiciones

1. Tener una conexion a internet confiable y segura.

PostCondiciones

1. El usuario es dirigido por el sistema, a una plataformaexterna.


Cuadro 7.7: Definicion de Caso de Uso COM01.


7.3. ARQUITECTURA EMPRESARIAL

La Arquitectura Empresarial se basa en proporcionar una vision inte-gral y general de una compania, facilitando la sinergia de procesos, datos yaplicaciones. A continuacion estan los diagramas que permiten modelar laarquitectura empresarial del negocio que se ha venido trabajando durante laejecucion de este proyecto.

Archimate es un lenguaje de peso ligero y escalable en varios aspectos:

Su marco de arquitectura es simple, pero lo suficientemente ampliocomo para proporcionar un buen mecanismo de estructuracion de losdominios de la arquitectura, capas y aspectos.

El lenguaje incorpora los conceptos del paradigma .Orientacion de servi-cio”, que promueve un nuevo principio de organizacion, en terminos deservicios para las organizaciones: empresa, aplicacion e infraestructura.

El papel de la norma Archimate es proporcionar un lenguaje grafico parala representacion de las arquitecturas empresariales con el tiempo (es decir,incluyendo la transformacion y la planificacion de la migracion), ası como sumotivacion y razon.

El nucleo del lenguaje consiste en tres tipos principales de elementos: ac-tivos, de comportamiento, y pasivos. Los elementos activos son los actoresempresariales, componentes de aplicaciones y dispositivos que muestran elcomportamiento real: Un elemento activo se define como una entidad quees capaz de realizar un comportamiento”. Luego estan los elementos de com-portamiento o dinamica, donde son asignados elementos activos para mostrarquien o que realiza la conducta: Un elemento de comportamiento se definecomo una unidad de actividad realizada por uno o mas elementos activos”.Finalmente, los elementos pasivos son los objetos sobre los cuales se realizaun comportamiento: Un elemento pasivo se define como un objeto en el quese realiza un comportamiento”.

Los tres elementos del nuclelo del lenguaje, se han basado en el lenguajenatural, donde la frase tiene un sujeto (activo), un verbo (comportamiento)y un objeto (pasivo).

En segundo lugar, el lenguaje de Archimate se compone de una visionexterna y una interna de los sistemas. Al mirar el aspecto conductual, estos


puntos de vista reflejan los principios de orientacion de servicio: Un serviciose define como una unidad de funcionalidad que un sistema expone a suentorno, al tiempo que oculta las operaciones internas, y que proporciona uncierto valor (puede ser economico u de otra caracterıstica)”.

Por lo tanto, el servicio es el comportamiento visible externamente, queproporciona una perspectiva de los sistemas que utilizan este servicio; elentorno consiste en todo lo que sale de este servicio. El valor proporciona lamotivacion para la existencia del servicio.

****Capas: El lenguaje Archimate define tres capas principales, con base en las

especializaciones de los conceptos basicos. Es ası, que cada tipo de elementodel nucleo del lenguaje (activo, comportamiento y pasivo), tiene una capaespecializada de diagramas. Tambien existen capas especializadas para lasextenciones (servicios e interfaces).

Las capas principales, de acuerdo con el nucleo del lenguaje, son:

La capa de negocio: Se ofrecen productos y servicios a clientes externos.Esta capa es realizada segun los procesos de negocio que generen losactores del negocio, es decir, en esta capa queda reflejado los acuerdosque se establezcan entre el equipo desarrollador, y los interesados.

La capa de aplicacion: Compatible con la capa de negocios. Con servi-cios de aplicaciones que realiza el software.

La capa de infraestructura: Ofrece los servicios necesarios para ejecutaraplicaciones, propios de la infraestructura, por ejemplo, los serviciosde procesamiento, almacenamiento y comunicacion realizadas por elhardware.

La capa de motivacion (extension): Un elemento de motivacion se definecomo un elemento que proporciona el contexto o la razon que esta detrasde la arquitectura de una empresa.

La capa de implementacion y migracion (extension): Anade conceptospara apoyar las fases tardıas de la arquitectura, relacionados con laimplementacion y migracion de arquitecturas.


7.3.1. Capa Motivacional

Esta capa se utiliza para modelar las motivaciones o razones que subyacenen el diseno o el cambio de una arquitectura empresarial. Estas motivacionesinfluyen, guıan y limitan el diseno.

Es esencial comprender los factores, a menudo denominados conductores”,que influyen en los elementos de motivacion. Pueden provenir de adentro ode fuera de la empresa. Los conductores internos, tambien llamados ”preo-cupaciones”, estan asociados con las partes interesadas, que pueden ser unser humano individual o algun grupo de seres humanos, como un equipo deproyecto, empresa o sociedad.

CONCEPTO DESCRIPCION NOTACION

Implicado

Representa el papel de un individuo,equipo u organizacion que presenteintereses o inquietudes, en relacion conel resultado de la arquitectura.

Manejador Entidad que crea, motiva y alimenta elcambio en la organizacion.

Valoracion El resultado de un analisis de unManejador.

Objetivo Estado final al que uno de los elemen-tos Implicados se propone alcanzar.

Requerimiento Declaracion de necesidad que deberealizarse por un sistema.


Restriccion Limitacion a la forma en que se realizaun sistema.

PrincipioPropiedad normativa de todos lossistemas en un contexto dado, o laforma en que se realizan.

Cuadro 7.8: Elementos participantes de la Capa Motivacional.


7.3.1.1. Contextualizacion de los objetivos estrategicos

Para el desarrollo de una vision de alto nivel de las capacidades y valorde negocio que se desean obtener como resultado de la Arquitectura Empre-sarial, se establece la identificacion de los objetivos estrategicos, y se planteala alineacion de dichos objetivos con los objetivos a tratar en el presente pro-yecto.Teniendo en cuenta esto, se extraen los objetivos estrategicos de la organiza-cion, que se encuentran implicitamente dentro de la vision y la mision de laempresa, puesto que no estan explicitamente declarados. Para esto, se per-mite citar la mision y vision de la empresa de esta manera:

Mision:”Nuestra empresa ofrece soluciones en Ingenierıa de Software de impacto,resultado de procesos de investigacion continua; nuestro mercado esta diri-gido a todo los roles involucrados en el proceso de desarrollo de software, aquienes les brindamos herramientas de ultima generacion junto con los me-canismos de capacitacion y entrenamiento en las diferentes disciplinas de laIngenierıa de Software.”

Vision:”Colosoft E.U se proyecta a cinco anos, ser una empresa reconocida por sussoluciones y productos dentro del sector del software, apalancando las or-ganizaciones cliente que soporten sus soluciones en nuestras plataformas,generando un mercado de confianza por el alto grado de experticia con quese realizan nuestros proyectos empresariales.”


7.3.1.2. Definicion de los interesados (Stakeholders)

La identificacion de los interesados y sus preocupaciones es una fase funda-mental a plantear dentro de la capa motivacional para la definicion posteriorde la Arquitectura Empresarial, puesto que en ellos va a existir repercusiondirecta del cumplimiento de los objetivos alineados a las TI.

Para el presente proyecto, se han identificado los Stakeholders mas relevan-tes mediante un mapa de stakeholders, teniendo en cuenta su participacionactiva o pasiva dentro del proyecto:

Figura 7.5: Mapa de Stakeholders

*Fuente: Propia. Fuente del diseno: The Open Group


Empresa Colosoft:

• Arquitecto de software de la organizacion Colosoft:El arquitecto de software es el encargado de realizar el desarrolloy continua mejora del producto interno que ofrece la organiza-cion, por eso es un rol de Stakeholder que merece enunciarse comorelevante puesto que la retroalimentacion de conocimiento que ge-nere el sitio Web, le permite tener una constante actualizacion deinformacion del area.

• Encargado del mercadeo de la organizacion Colosoft:Este interesado se toma en cuenta ya que sera el encargado de rea-lizar la promocion del sitio Web para la expansion de la cantidadde publico objetivo.

• Departameto de desarrollo:Segun los criterios con los que se desarrolle el proyecto, este de-partamento puede resultar beneficiado en cuanto a su importanciadentro de la organizacion, pues es el que se encarga del proceso dedesarrollo del software producto.

• Disenador grafico:Al igual que ocurre con el departamento de desarrollo, este in-teresado puede resultar beneficiado en cuanto a los resultados delproyecto, puesto que puede contribuir activamente en los desa-rrollos que tenga planteada la organizacion para metas a corto ymediano plazo.

Organizacion del proyecto:

• Estudiantes de Ingenierıa de Sistemas (Desarrolladoresde la plataforma Web):Se enuncian a los autores, y futuros desarrolladores que haganalgun aporte al sitio Web, al ser estos los que directamente serelacionan al proceso de ejecucion del proyecto.

• Gerente de la organizacion Colosoft:El gerente de la organizacion es el principal interesado en la eje-cucion del proyecto, puesto que por medio de esta solucion de TIse pueden alcanzar objetivos estrategicos a mediano y largo plazo.


Organizacion del usuario final:

• Investigadores usuarios del sitio Web:Uno de los roles del publico objetivo son los estudiantes, expertos einvestigadores que deseen recibir y aportar conocimiento respectoal area de Ingenierıa de Software, por lo cual se toma en cuentacomo interesado.

• Clientes del producto ofrecido por el sitio Web:El otro rol del publico objetivo son los potenciales clientes delproducto ofrecido, ya sean empresariales o personas naturales.

Entorno exterior:

• Sitios relacionados, considerados como competencia”parala empresa:Cualquier empresa que cuente con un software para el apoyo dela arquitectura de software, o que este interesada en incursionaren este campo, se ve involucrada negativamente por ser una com-petencia directa hacia la empresa.

• Empresa dedicada al servicio de servidor Web:La empresa que ofrece el servicio pago de alquiler del servidorWeb, resulta beneficiada al generar ganacias debido a que se debeasumir dicho costo por parte del proyecto.

• Empresa dedicada al servicio de dominio Web:La empresa que ofrece el servicio pago de alquiler del dominioWeb, resulta beneficiada al generar ganacias debido a que se debeasumir dicho costo por parte del proyecto.

• Colaboradores Web:Son aquellos sitios Web que se benefician del trafico de usuariosque pueda tener el sitio Web de Colosoft, y ası mismo estan otor-gando un servicio gratuito para continuar con el funcionamiento.En estos se toma en cuenta los sitios que ofrecen los servicios de:pasarela de pagos, comunidad web, buscador Web.


7.3.1.3. Matriz del enfoque de gestion de los Stakeholders

Luego de identificar a los directamente interesados en el proyecto, seevalua su capacidad para bloquear o contribuir en el avance. Algunos puedenestar interesados en la iniciativa que pretende abarcar la arquitectura, otrosno tanto.

Se debe calcular el interes y la influencia de cada interesado, con el fin deenfocar la participacion de la arquitectura de la empresa en los interesadosclave, y clasificar ası su grado de compromiso con el proyecto.

Figura 7.6: Enfoque de Gestion de Stakeholders

*Fuente: TOGAF 9.1 - The Open Group

Segun la tabla del enfoque de gestion, una alta influencia en el proyecto,y un alto interes en este, es lo que determina si se considera un interesadocomo clave o no.

A continuacion se realiza una matriz con la evaluacion de los Stakeholderspara determinar los interesados clave:


Stakeholder Preocupaciones Influencia Interes ClaseArquitecto deSW

Estructurar un producto quecumpla con las necesidades delpublico al que va dirigido.

Bajo Medio D

Mercadeo Dar a conocer el producto yatraer nuevos clientes por mediode la base de datos de conoci-miento

Media Alto D

Desarrollo deSW

Proporcionar una herramienta in-tegral adaptada a la necesidadesgenerales de los consumidores

Bajo Medio B

Diseno Grafico Proveer a los clientes herramien-tas visuales que se adapten a susnecesidades

Medio Medio C

EstudiantesDesarrolladores

Desarrollar un portal web usableque le proporcione a la empresaun reconocimiento por su produc-to

Alto Alto D

Gerente Expandir la companıa, atrayendonuevos clientes que se intersen enel producto

Medio Alto B

Investigadores Proveer herramientas para acce-der a la informacion relacionadacon el producto

Medio Alto D

Clientes Acceder a un portal web usableque le permita al cliente adquirirlos productos

Medio Alto D

Competencia Estar siempre activos en el en-torno compeititivo

Bajo Bajo A

Servidor Web Adquirir un servicio que provea lainfraestructura necesaria para po-der asegurar la estabilidad del si-tio web

Alto Medio D

Dominio Web Adquirir un servicio de proveedorde dominio estable y confiable

Alto Medio D

Colaboradores Usar las herramientas disponiblesen el mercado con altos niveles decalidad

Alto Medio B

Cuadro 7.9: Matriz de enfoque de gestion de Stakeholders.


7.3.1.4. Punto de Vista de Stakeholders

Tambien llamado punto de vista de las partes interesadas. Permite alanalista modelar las partes interesadas, los manejadores internos y externospara el cambio, y las valoraciones (en terminos de fortalezas, debilidades,oportunidades y amenazas) de esos controladores, ademas de sus vınculoscon los objetivos iniciales de alto nivel (Objetivo general y especıficos). Es-tos objetivos constituyen la base para el proceso de ingenierıa de requisitos,incluyendo el refinamiento objetivo, analisis de la contribucion y el conflicto,y la derivacion de los requerimientos que realicen los objetivos.

Figura 7.7: Metamodelo del Punto de Vista de Stakeholders

*Fuente: Sandro Bolanos.

En el diagrama del metamodelo, se puede observar la asociacion que exis-ten entre los elementos anteriormente descritos: stakeholder (interesado), ma-nejador, objetivo y valoracion. Estas relaciones se dan en cuanto a la valo-racion de objetivos creados por los interesados, y los manejadores que estanasociados a la parte interesada.


Figura 7.8: Punto de Vista de Stakeholders 1

*Fuente: Autores.

Para el presente proyecto, se han definido como interesados los integrantesdel equipo de desarrollo de la plataforma empresarial. Como manejador seha definido el desarrollar un proyecto (en este caso, el actual proyecto). Sehan planteado varias valoraciones de los interesados para el caso puntual dedesarrollar un proyecto; por un lado se tiene una valoracion de oportunidades(maneja metodologıas de desarrollo), se tiene valoracion de fortalezas (manejaherramientas), y por el otro se tiene una valoracion de amenazas (desconocetendencias) y una valoracion de debilidades (conceptos poco estables). Paracada valoracion se plantea un objetivo, ya sea para afianzar esa oportunidado fortaleza, o para atacar y mitigar el riesgo de dicha amenaza o debilidad.



*Fuente: Autores.

Se han planteado los objetivos especıficos, de acuerdo a la vision generalde la empresa y el alcance que pretende tener su producto. Es por esto queen este segundo diagrama del punto de vista de stakeholders se evidencianlas preocupaciones de los interesados en la creacion y accesibilidad de losusuarios a la plataforma Web.



*Fuente: Autores.

En este tercer diagrama del punto de vista de stakeholders, se evidenciala relacion del publicista que se encargara de promover en el publico el usodel sitio Web, con el objetivo fundamental de TI de incrementar el traficodel sitio Web.



*Fuente: Autores.

En este diagrama del punto de vista de stakeholders, se plasma la moti-vacion que tiene un tipo de usuario del portal Web, que en este caso es unusuario investigador, quien extrae y provee conocimiento del area. De allı sejustifica la creacion de un espacio abierto para la interaccion de estos usuarios(Estimula la creacion de la comunidad Web).



*Fuente: Autores.

El segundo tipo de usuario del portal, se trata de los clientes del producto.Si bien un usuario puede tener un rol distintivo (Investigador o cliente), puedeexistir el caso en que un mismo usuario tenga los dos roles. En este caso, elusuario cliente motiva un espacio en el portal, para permitir la descargasegura del producto, ya sea una version gratuita o una version con costos.


7.3.1.5. Punto de Vista de Realizacion de Objetivos

Permite al disenador, modelar el refinamiento de los objetivos (de altonivel) en objetivos mas concretos, y ası mismo, estos objetivos mas concretosen requisitos o limitaciones.

Figura 7.13: Metamodelo del Punto de Vista de Realizacion de Objetivos


Para el caso del metamodelo, se puede decir que la realizacion del objetivoimplica aplicar principios de ingenierıa, en los que se basa la realizacion de unmodelo; tambien se puede afirmar que los requerimientos y restricciones sondeducidos a partir de dichos objetivos y principios. El objetivo de alto nivelse puede dividir en varios objetivos mas concretos, asociandose por medio dela relacion de agregacion.

Se ha planteado un objetivo general para el funcionamiento del negocio, elcual es el apoyo de la comercializacion del software coloso. Este objetivo


Figura 7.14: Punto de Vista Realizacion de Objetivos

*Fuente: Autores.

general esta compuesto por varios objetivos especıficos, los cuales son respec-tivamente: implementar una pasarela de pagos, crear una comunidad web,y brindar soporte tecnico. Los objetivos que tienen que ver con el modulode transaccion, que son los de implementar pasarela de pago y el de brindarsoporte, estan basados en el principio de usabilidad, y de dicho principio sederiva un requerimiento, el cual se resume en proveer un portafolio.

El principio por el cual se va a basar la realizacion de los objetivos, es el deUsabilidad, por esto ese principio va ligado a los subobjetivos de desarrollo,y no al teorico.

Un requerimiento emergente al principio de Usabilidad, es el de ”Proveerun portafolio en lınea”.


7.3.1.6. Punto de Vista de Contribucion de Objetivos

Permite al disenador o analista, modelar las relaciones de influencia en-tre los objetivos y los requisitos. El resultado de este punto de vista puedeusarse para analizar el impacto que los objetivos tienen entre sı, o para de-tectar conflictos entre los objetivos de las partes interesadas. Este punto devista puede ser usado cuando se han refinado los objetivos en objetivos masespecıficos, y posiblemente en requisitos.

Figura 7.15: Metamodelo del Punto de Vista de Contribucion de Objetivos


En el diagrama de metamodelo se tiene los elementos mencionados anterior-mente: objetivos, requerimientos y principios. Como la descripcion del puntode vista lo indica, se trata de establecer relaciones entre objetivos, entreobjetivos y requerimientos, entre requerimientos, y entre objetivos o requeri-mientos con principios; ası mismo, se debe tener en cuenta los principios delos cuales se basan para ası tener una mejor idea del camino que seguir.


Figura 7.16: Punto de Vista de Contribucion de Objetivos.

*Fuente: Autores.

En este punto de vista se han definido objetivos concretos en torno a unrequerimiento ya definido: gestionar usuarios dentro de la plataforma Web‘Colosoft’. Este requerimiento cumple con los principios de usabilidad, costomınimo y simplicidad que se han venido trabajando dentro del proyecto.


7.3.1.7. Punto de Vista de Principios

Permite al disenador o analista, modelar los principios que son relevantespara el problema en cuestion, incluidos los objetivos que motivan a esosprincipios. Ademas las relaciones entre los principios y sus objetivos se puedenmodelar, por ejemplo, en la influencia positiva o negativa de un principiosobre un objetivo.

Figura 7.17: Metamodelo del Punto de Vista de Principios


El diagrama del metamodelo de este punto de vista es bastante sencillo:consta de los elementos importantes en este caso, que son los principios y losobjetivos. Es facil de leer, ya que permite visualizar las relaciones entre losdistintos objetivos y los principios que pueden haber motivado a la creacionde dicho objetivo.


Figura 7.18: Punto de Vista de Principios

*Fuente: Autores.

Este punto de vista se centra en un objetivo en especial: brindar apoyo yservicios de impacto al desarrollo de proyectos de ingenierıa de software. Deaquı se han resaltado los principios de los cuales esta basado.


7.3.1.8. Punto de Vista Realizacion de Requerimientos

Permite al disenador modelar la realizacion de requerimientos por los ele-mentos activos basicos, tales como los actores de negocio, servicios de negocio,procesos de negocio, servicios de aplicaciones, componentes de aplicacion, etc.Ademas, este punto de vista puede ser utilizado para refinar requisitos en re-quisitos mas detallados.

Figura 7.19: Metamodelo del Punto de Vista de Realizacion de Requerimien-tos


En el metamodelo se logra observar la realizacion del objetivo por medio dela definicion de requerimientos y restricciones. Claro esta decir que se puedenasociar los elementos activos basicos, como medio de realizacion de los re-querimientos o de las restricciones. Esto con el fin de respaldar la existenciade los elementos activos basicos en la consecucion de un objetivo final.


Figura 7.20: Punto de Vista de Realizacion de Requerimientos

*Fuente: Autores.

Permite al disenador modelar la realizacion de requerimientos por los ele-mentos activos basicos, tales como los actores de negocio, servicios de nego-cio, procesos de negocio, servicios de aplicaciones, componentes de aplicacion,etc. Ademas, este punto de vista puede ser utilizado para refinar requisitosen requisitos mas detallados.

En el metamodelo se logra observar la realizacion del objetivo por mediode la definicion de requerimientos y restricciones. Claro esta decir que sepueden asociar los elementos activos basicos, como medio de realizacion de losrequerimientos o de las restricciones. Esto con el fin de respaldar la existenciade los elementos activos basicos en la consecucion de un objetivo final.


7.3.1.9. Punto de Vista de Motivacion

Permite al disenador o analista, modelar el aspecto motivacional que seha generado en torno al proceso de arquitectura de software, sin ahondar enlos elementos dentro de este aspecto.

Figura 7.21: Metamodelo del Punto de Vista de Motivacion


El metamodelo de este punto de vista es, en sı, un ejemplo de lo que se puedelograr con la arquitectura empresarial: Se puede utilizar dicho punto de vistapara presentar una vision completa o parcial del aspecto motivacional por losinteresados relacionados (stakeholders), sus principales objetivos, los princi-pios que se aplican, y los principales requerimientos de servicios, procesos,aplicaciones y objetos.


Figura 7.22: Punto de Vista de Motivacion

*Fuente: Autores.

En este punto de vista se ha optado por definir objetivos enfocados a losdiferentes interesados, es ası que los objetivos de: .Ofrecer un portafolio deservicios y productos de investigacion 2.Abrir un espacio de discusion en tornoal area de Ingenierıa de Software.estan orientados hacia el cliente; el objetivode ”Brindar una plataforma Web usable.esta motivado por el desarrolladordel proyecto; el objetivo Retroalimentar los conocimientos internos reflejadosen el producto.es motivado por la empresa Colosoft; y por ultimo el objetivode Incrementar trafico del sitio Web.es motivado por dos interesados que eneste caso son el desarrollador y la organizacion Colosoft, puesto que es unobjetivo que cumple con las espectativas de ambos respecto a la ejecuciondel presente proyecto.


7.3.1.10. Objetivos de la Arquitectura

Proporcionar un portal web usable en el cual el usuario final puedaencontrar un producto relacionado a area de ingenierıa de software quecumpla con sus necesidades.

Establecer una base de conocimientos relacionados al producto que secomercializa, con el fin de formar una comunidad en torno al mismoque le aporte al producto y que le de un mejor posicionamiento en elmercado.

Facilitar la navegabilidad al usuario final para permitir la descarga delproducto que mas se ajuste a sus necesidades.

7.3.2. Capa de Negocio

La capa de negocio ofrece productos y servicios a clientes externos, quese realizan en la organizacion por los procesos de negocio llevados a cabo porlos actores empresariales.


Actor deNegocio

Perteneciente a la organizacion, encar-gado de realizar las acciones que serepresentaran.

Rol deNegocio

El comportamiento especıfico quepuede tener un Actor de Negocio par-ticipante, en un contexto particular.

Colaboracionde Negocio

Una especie de “rol emergente”, resul-tado de la cooperacion (temporal) dedos o mas Roles de Negocio. El resul-tado es un comportamiento colectivoespecıfico en un contexto particular.


Interfacede Negocio

Punto de acceso donde se presenta dis-ponible, para el ambiente, un Serviciode Negocio.

UbicacionRepresentacion de un punto o exten-sion en el espacio, donde se aplicara laarquitectura.

Proceso deNegocio

Ordenamiento de actividades. Presentala intencion de producir un conjuntodefinido de Productos o Servicios deNegocio.

Funcion deNegocio

Conjunto seleccionado de criterios(recursos y/o competencias de negocio,normalmente requeridos).

Interaccionde Negocio

Describe el comportamiento de unaColaboracion de Negocio.

Evento deNegocio

Se define como algo que sucede (inter-na o externamente) y sus influenciasen el comportamiento.

Servicio deNegocio

Satisface la necesidad de negocio paraun cliente (interno o externo a laorganizacion).


Objeto deNegocio

Elemento pasivo que tiene relevanciadesde una perspectiva empresarial.

RepresentacionForma perceptible de la informaciontransportada por un Objeto de Nego-cio.

SignificadoConocimiento o experiencia presenteen un objeto de negocio o su represen-tacion, dado un contexto particular.

Valor Utilidad o importancia de un Servicioo Producto de Negocio.

Producto

Coleccion coherente de servicios, acom-panado de un Contrato, que se ofrececomo un objeto compacto a los clientes(internos o externos).

ContratoEspecificacion formal o informal deun acuerdo que especifica los derechosy obligaciones asociados a un producto.

Cuadro 7.10: Elementos participantes de la Capa de Negocio.


7.3.2.1. Punto de Vista de Organizacion

Como su nombre lo indica, se centra en la organizacion interna, bien pue-de ser de una empresa, un departamento, una red de empresas o de cualquierentidad organizativa. El punto de vista de Organizacion es muy util en laidentificacion de las competencias, la autoridad y responsabilidades en unaorganizacion.

Figura 7.23: Metamodelo del Punto de Vista de Organizacion


En la grafica del metamodelo, el actor posee un rol dentro de la organizacion.Este rol puede estar disponible por medio de una interface que ofrecera susrespectivos servicios. Tambien del rol se puede inferir que existan colaboracio-nes donde se involucre el actor. Por ultimo, el elemento de localizacion existepara enfocar mas detalladamente en que lugar conceptual de la organizacion,esta desempenandose dicho actor.


Figura 7.24: Punto de Vista de Organizacion

*Fuente: Autores.

Para el caso propio, se han definido tres actores dentro del esquema denegocio, que cumplen con su respectivo rol, es ası que se tiene un actor‘Arquitectura’, donde su rol es el del arquitecto, se tiene tambien ‘Desarrollo’y su rol es el de desarrollador, y por ultimo esta el actor ‘Promocion’ dondetiene el rol de promotor. A su vez, estos roles se agregan en una colaboracionde negocio, que tiene objetivos especıficos como el de gestionar un proyecto,y el de realizar la publicidad. Todo esto ocurre dentro del actor ‘Colosoft’que es el software montado en la nube, y se accede a este por medio de lainterface ‘Portal Empresarial’.


7.3.2.2. Punto de Vista de Cooperacion de Actor

Se centra en las relaciones de los actores entre sı y con su entorno. Unejemplo comun de esto es el “diagrama de contexto”, lo que pone una organi-zacion en su entorno, que consiste en las partes externas, tales como clientes,proveedores y otros socios comerciales. Es muy util en la determinacion delas dependencias y colaboraciones externas y muestra la cadena de valor ored en el que opera el actor.

Figura 7.25: Metamodelo del Punto de Vista de Cooperacion de Actor


El diagrama del metamodelo de este punto de vista, permite identificar lospuntos de acceso a los servicios que generan los elementos activos de la capade negocio (Actor), y la capa de aplicacion (componente). Se logra observaruna interaccion entre los actores de la capa de negocio, con su respectivo roly/o colaboracion junto al servicio que ofrecen, comunicarse con los serviciosque se generan en la capa de aplicacion, o ya especıficamente con un compo-


nente de aplicacion.

Figura 7.26: Punto de Vista de Cooperacion de Actor

*Fuente: Autores.

Para el caso puntual del desarrollo actual, se tiene de nuevo la interacciondentro del actor ‘Colosoft’. En este punto de vista, se tienen los actores defini-dos anteriormente (Se recuerda que ‘Arquitectura’ tiene el rol de arquitecto,‘Desarrollo’ son los del rol de desarrollador, y ‘Promocion’ es el rol promo-tor), y una nueva colaboracion de negocio donde estan involucrados los tres:‘Equipo Empresarial’. Esta nueva colaboracion de negocio esta basada en elconjunto total de la funcion de la organizacion, y se centra en gestionarla.

Por otro lado, se tiene que el actor ‘Colosoft’ es accesible por medio deuna interface llamada ‘Portal Empresarial’, que basicamente lo que realiza esuna publicidad a un actor externo a la organizacion, que cumple con el rolde cliente del portal empresarial. Desde allı se pretende ofertar el productoa este actor.


7.3.2.3. Punto de Vista de Funcion de Negocio

Muestra las principales funciones de negocio de una organizacion y susrelaciones en terminos de flujos de informacion, valor o beneficios entre ellas.Las funciones de negocio se usan para representar los aspectos mas establesde una empresa en terminos de las actividades primarias que realiza, inde-pendientemente de los cambios a nivel organizacional, o nuevos desarrollostecnologicos. Ası, el punto de vista de funcion de negocio, proporciona unavision de alto nivel en las operaciones generales de la organizacion, y se puedeutilizar para identificar las competencias necesarias de acuerdo a sus princi-pales actividades.

Figura 7.27: Metamodelo del Punto de Vista de Funcion de Negocio


El diagrama del metamodelo es claro en el sentido que se quiere referenciara las relaciones entre distintas funciones de negocio en la organizacion. Claroesta que cada funcion cuenta con actores de negocio que cumplen un rol endicha funcion.


Figura 7.28: Punto de Vista de Funcion de Negocio

*Fuente: Autores.

En el diagrama propio, se anaden las funciones de negocio de los roles yadefinidos: el rol de arquitecto, en este caso, tiene asignadas dos funciones denegocio que son las de definir la estructura de los productos que se van a ponera disposicion del cliente, y la de innovar en la plataforma empresarial. El rolde desarrollador, por su parte, tiene asignadas las funciones del desarrollodel producto, y una funcion en comun con la del arquitecto, que es la deestructurar productos; esta funcion no es asignada a la colaboracion querepresentan ambos roles, puesto que aunque se representa como una solafuncion, se tienen perspectivas distintas respecto a los roles, es ası que elarquitecto solo construye una “base” del modelo, y el desarrollador construyelos “detalles”.

Para terminar de describir los roles definidos de los actores internos de laorganizacion, se tiene que el rol de promotor solo esta asignado a una funcionmuy especıfica: la de promocionar productos.

El rol del actor externo, que en este caso se llama cliente, se espera tengainteraccion con la funcion de la promocion del producto, y que tenga consumode la plataforma de software.


7.3.2.4. Punto de Vista de Proceso de Negocio

Se utiliza para identificar la estructura de alto nivel y la composicion deuno o mas procesos de negocio. Al lado de los procesos mismos, este puntode vista contiene otros conceptos directamente relacionados, tales como:

Los servicios que un proceso de negocio ofrece al mundo exterior.

La asignacion de los procesos de negocio a los roles, lo que da una ideade las responsabilidades de los actores asociados.

La informacion utilizada por el proceso de negocio.

Figura 7.29: Metamodelo del Punto de Vista de Proceso de Negocio


En el diagrama del metamodelo, se comienza asignando un rol (con su posiblecolaboracion, su respectivo actor y ası mismo con la ubicacion de este) a lafuncion de negocio que se tiene enfocado. Este proceso de negocio es usadopor un servicio de aplicacion, y puede ser directamente o a traves de unainteraccion de negocio. Ya para describir la parte interna de los elementosde la capa de negocios que interactuan en este punto de vista con la funcion


de negocio, un proceso de negocio puede relacionarse temporalmente con unevento de negocio, puede acceder a los conceptos hallados en los objetos denegocio, o puede servir de referencia a un servicio de negocio, que hace usode dicha funcion para ofrecer sus funcionalidades.

Figura 7.30: Punto de Vista de Proceso de Negocio 1

*Fuente: Autores.

Para el caso del desarrollo actual, se han definido dos procesos de negociofundamentales, y por los cuales se han generado para cada uno un punto devista distinto.

En el primero, se enfoca en el proceso de venta de un producto, don-de este a su vez esta conformado por dos procesos de negocio como lo sonla escogencia o eleccion del producto por parte del cliente (Desencadenadapor el evento de solicitud de compra), y posteriormente la realizacion de latransaccion en lınea (Que desencadena el evento de la descarga del producto).

Esta funcion de negocio mayor (Venta de un producto) es la que realizael actor ‘Colosoft’ en su rol de empresa, y se le asigna la ubicacion del portalempresarial, puesto que la organizacion se basa en dicha plataforma pararealizar sus funciones al exterior.


Figura 7.31: Punto de Vista de Proceso de Negocio 2.

*Fuente: Autores.

Para el segundo punto de vista del proceso de negocio, se tiene una fun-cion fundamental para el negocio: la actualizacion del software. Este procesode negocio, tambien esta compuesto por dos subprocesos, que son los de pla-neacion de la solucion (Desencadenado por la identificacion de la necesidadde actualizacion), y posteriormente el proceso de desarrollo de dicha solucion(Que desencadena una nueva version del software Coloso).

El proceso de negocio de enfoque en este punto de vista (Actualizacionsoftware), es asignado al rol que tiene el arquitecto.


7.3.2.5. Punto de Vista de Producto

Representa el valor que los productos ofrecen a los clientes u otras partesexternas involucradas, y se muestra la composicion de uno o mas productos enterminos de la constitucion de servicios de negocio o servicios de aplicacion.Tambien es usado para identificar las interfaces a traves de los cuales se ofreceeste producto, y los eventos asociados a este. El punto de vista de producto sesuele utilizar en el desarrollo de productos, para hacer un diseno con serviciosexistentes o mediante la identificacion de nuevos servicios que se tienen quecrear para el producto, dado el valor que un cliente espera del mencionado.

Figura 7.32: Metamodelo del Punto de Vista de Producto


En el diagrama del metamodelo, se logra observar desde una perspectiva delproducto, como este influye en otros elementos de negocio y de aplicacion. Esası, que el producto agrega un contrato, un servicio de negocio y un serviciode aplicacion, y a su vez el producto accede a la informacion de valor.


Figura 7.33: Punto de Vista de Producto

*Fuente: Autores.

Para el caso del desarrollo actual, el punto de vista del producto se centraen el objeto clave para tener acceso al ambiente externo: el producto ‘PortalColosoft’. Este producto esta conformado por dos servicios de negocio prin-cipales (por los cuales esta basado el presente proyecto), y un servicio deaplicacion. Un servicio de negocio es crear un espacio interactivo donde elcliente pueda relacionarse un poco mas con todos los temas sobre ingenierıade software (Modulo de conocimiento); el otro servicio de negocio que se va aofrecer, es el de ofertar y poner a disposicion el software ‘Coloso’ (Modulo detransacciones). Ası mismo, el servicio de aplicacion que compone el producto,es la aplicacion web desarrollada, siendo accedida por medio de una interfacede lenguaje PHP, por un componente llamado Fuel CMS, que no es mas sino el gestor de contenidos de la aplicacion web.

El valor del producto esta en que se implementan los principios de sim-plicidad, de aprendizaje, y de discusion.


7.3.3. Capa de Aplicacion

La capa de aplicacion es compatible con la capa de negocios a traves deservicios de aplicacion que son realizados por software.


Componentede Aplica-cion

Parte modular, desplegable, y reem-plazable de un sistema de software,donde se encapsula su comportamientoy datos, y los expone a traves de unconjunto de interfaces.

Colaboracionde Aplica-cion

Conjunto de dos o mas Componentesde Aplicacion. Trabajando juntasllevan a cabo una conducta colectiva.

Interfacede Aplica-cion

Punto de acceso donde se expone unServicio de Aplicacion disponible paraun usuario u otro Componente deAplicacion.

Funcion deAplicacion

Agrupacion de comportamientos auto-matizados que pueden ser realizadospor un Componente de Aplicacion.

Interaccionde Aplica-cion

Describe el comportamiento de unaColaboracion de Aplicacion.

Servicio deAplicacion

Servicio que expone el comportamientoautomatizado.


Objeto deDatos

Elemento pasivo apropiado para elprocesamiento automatizado.

Cuadro 7.11: Elementos participantes de la Capa de Aplicacion.


7.3.3.1. Punto de Vista de Comportamiento de Aplicacion

Describe la conducta interna de la aplicacion; por ejemplo, como se ofre-cen uno o mas servicios de aplicacion. Es util en el diseno del comportamientoprincipal de aplicaciones, o en la identificacion de solapamiento funcional en-tre diferentes aplicaciones.

Figura 7.34: Metamodelo del Punto de Vista de Comportamiento de Aplica-cion


En el diagrama del metamodelo se puede observar como la funcion de apli-cacion es el eje central en el comportamiento de aplicacion. Dicha funcionesta asignada a un componente de aplicacion, que a su vez esta compues-ta por una o mas interfaces de aplicacion, y por una o mas colaboracionesde aplicacion. La funcion de aplicacion tiene acceso a los conceptos de losobjetos de datos, los servicios de aplicacion y la interaccion de aplicacion.


Figura 7.35: Punto de Vista de Comportamiento de Aplicacion.

*Fuente: Autores.

Para el diseno de este punto de vista, se tienen en cuenta los distin-tos componentes que hacen parte de la aplicacion web: el componente detransacciones (que estara implementado en el modulo de transacciones), elcomponente de producto o servicio (productos o servicios que esten disponi-bles en la plataforma para ser consumidos por el cliente), el componente decomunidad (implementado en el modulo de comunidad web), y por ultimoel componente de publicidad. Estos cuatro componentes son los que estaran


integrados en la plataforma empresarial, y tendran asignados unas funcionesde aplicacion explicadas en el diagrama.

Para complementar este punto de vista, se definen unos objetos de da-tos, que los componentes van a acceder para realizar las funciones asignadas.Es ası que el componente de publicidad accede a los datos contenidos enun brochure de publicidad para realizar la funcion de captura de clientes, yel componente de transaccion accede a los datos de la plataforma de pagospara realizar la funcion de seguridad en la transaccion y entrega de producto.

7.3.3.2. Punto de Vista de Cooperacion de Aplicacion

Describe las relaciones entre los componentes de las aplicaciones en fun-cion de los flujos de informacion entre ellos, o en terminos de los servicios queofrecen y su uso. Este punto de vista se usa tıpicamente para generar unavision general del panorama de la aplicacion en una organizacion. Tambiense utiliza este punto de vista para expresar la cooperacion interna o la or-questacion de los servicios que en conjunto apoyan la ejecucion de un procesode negocio.

Figura 7.36: Metamodelo del Punto de Vista de Cooperacion de Aplicacion



En el diagrama de metamodelo, se debe enfocar hacia el elemento prin-cipal de este punto de vista que es el componente de aplicacion. Como elobjetivo del punto de vista es describir las relaciones entre los componentesde aplicacion, estos se componen de interfaces de aplicacion, y estan asigna-dos a las funciones de aplicacion y ubicaciones. Ası mismo los componentesde aplicacion pueden ser una agregacion de una colaboracion de aplicacion.

Figura 7.37: Punto de Vista de Comportamiento de Aplicacion.

*Fuente: Autores.

Para el caso del desarrollo actual, se muestran los componentes ya definidosanteriormente. Aquellos constituyen en sı, un producto que es la plataformaempresarial. Se distribuyen en dos ubicaciones de negocio: Back Office (serealiza por debajo de la aplicacion Web), y Front Office (se realiza hacia el


cliente). Los componentes que estan en el Back Office, son el producto yla transaccion; el producto se refiere al software ‘Coloso’, que se pretendecomercializar, la transaccion se refiere al servicio que se ofrece de transaccio-nabilidad. Los componentes en el Front Office, son aquellos que estan abiertosal publico, siendo el foco el componente de portal, que es usado por los com-ponentes de publicidad y comunidad.

7.3.3.3. Punto de Vista de Estructura de Aplicacion

Permite visualizar la estructura de una o mas aplicaciones o componen-tes. Este punto de vista es util en el diseno o la comprension de la estructuraprincipal de aplicaciones o componentes y los datos asociados; por ejemplo,para romper la estructura del sistema en construccion, o para identificar loscomponentes de aplicaciones heredadas que son adecuadas para la migraciono integracion.

Figura 7.38: Metamodelo del Punto de Vista de Estructura de Aplicacion


En el diagrama de metamodelo, se observa que el elemento de enfoque deeste punto de vista es el componente de aplicacion. Este componente de apli-cacion, hace uso de interfaces de aplicacion de las cuales esta compuesto. Elcomponente de aplicacion en el cual se enfoca, tiene el acceso a la informacion


en el objeto de datos, y forma parte de una colaboracion de aplicacion.

Figura 7.39: Punto de Vista de Estructura de la Aplicacion

*Fuente: Autores.

El componente principal, y que esta compuesto por otros varios componentes,en este caso se trata del componente Portal Web (Que lo hemos llamado enotras ocasiones Portal Empresarial). Ya se ha explicado anteriormente que laaplicacion se compone de los componentes transaccion, comunidad, producto,y publicidad. En este punto de vista se definen otros componentes internos


como el de servicios, y componentes externos como el que se usara para latransaccion (Pagos Online) y el que se usara para la comunidad (Wiki).

Como se puede observar, el componente principal se comunica a traves detres interfaces con los otros componentes, estructurandose ası: la interface decomunicacion (para poder usar el componente de comunidad), la interface deventa (para usar los componentes de producto, de servicio y de transaccion),y la interface de presentacion (para usar el componente de publicidad).

De este punto de vista se deriva los focos de desarrollo que se implemen-taron: se centro el desarrollo actual en los componentes de comunidad y detransaccion. Los componentes como producto o publicidad no los abarca eldesarrollo del proyecto actual.


7.3.3.4. Punto de Vista de Uso de Aplicacion

Describe como se utilizan las aplicaciones para soportar uno o mas pro-cesos de negocio, y la manera en que son utilizados por otras aplicaciones.Puede ser usado en el diseno de una aplicacion mediante la identificacion delos servicios que necesitan los procesos de negocio y otras aplicaciones, o enel diseno de procesos de negocio mediante la descripcion de los servicios queestan disponibles.

Figura 7.40: Metamodelo del Punto de Vista de Uso de Aplicacion


Para el caso del metamodelo, se tienen elementos de la capa de negocio, comoel objeto de negocio, el proceso de negocio, y el rol de negocio, interactuandocon elementos activos de la capa de aplicacion: el objeto de negocio tiene unconcepto mas concreto sobre lo que es el objeto de aplicacion; un servicio deaplicacion es usado directamente por el proceso de negocio; el rol de negociousa una interface de aplicacion para acceder al servicio de aplicacion.


Figura 7.41: Punto de Vista de Uso de Aplicacion

*Fuente: Autores.

En este punto de vista, se ha centrado en el componente primordial parala realizacion del negocio, que es el componente transaccion. El servicio queofrece la pasarela de pagos es el pago en lınea con tarjeta de credito, ası queeste servicio es el que ofrece el componente interno, que hace uso de dichapasarela. Aquı se puede asociar la funcion de negocio de venta de producto,que hace uso de dicho servicio de pago con tarjeta. Dicha funcion de negocioes realizada por el rol de cliente, y es desencadenada por el evento de comprade producto.


7.3.4. Capa de Infraestructura

La capa de infraestructura (tambien llamada la capa de tecnologıa), ofreceservicios de infraestructura como por ejemplo servicios de procesamiento,almacenamiento, y comunicacion, necesarios para ejecutar aplicaciones, ypara asegurar la comunicacion entre el hardware y software.


Nodo

Recurso computacional sobre elcual los Artefactos pueden seralmacenados o desplegados parasu ejecucion.

Dispositivo

Recurso de hardware sobre elcual los artefactos pueden seralmacenados o desplegados parasu ejecucion.

Sistema de Soft-ware

Entorno de software para tiposespecıficos de componentes yobjetos que se implementa en elen forma de Artefactos.

Interface deInfraestructura

Punto de acceso donde los Ser-vicios de Infraestructura sonofrecidos, para que un Nodopueda acceder a otros Nodos oComponentes de Aplicacion.

Red Medio de comunicacion entre doso mas Dispositivos.


Ruta de Comu-nicacion

Relacion entre dos o mas Nodos,a traves de la cual estos Nodospueden intercambiar datos.

Funcion de In-fraestructura

Agrupa los comportamientos deinfraestructura para ser realiza-dos por un Nodo.

Servicio de In-fraestructura

Unidad visible externamentede la funcionalidad significativapara el ambiente, proporcionadapor uno o mas Nodos, expuesta atraves de interfaces bien defini-das.

ArtefactoPieza fısica de datos que se utili-zan o producen en un proceso dedesarrollo de software.

Cuadro 7.12: Elementos participantes de la Capa de Infraestructura.


7.3.4.1. Punto de Vista de Infraestructura

Contiene los elementos de software y hardware de infraestructura de apo-yo a la capa de aplicacion, tales como dispositivos fısicos, redes o softwaredel sistema (como por ejemplo sistemas operativos, bases de datos o middle-ware).

Figura 7.42: Metamodelo del Punto de Vista de Infraestructura


En el diagrama de metamodelo presenta los distintos elementos que se pre-sentan en la capa de infraestructura, con sus relaciones entre sı. Este me-tamodelo permite una visualizacion de alto nivel, sobre la misma capa deinfraestructura. Es ası que en el diagrama se pueden visualizar elementoscomo los dispositivos de hardware necesarios para el proceso de negocio, lossistemas de software que estaran asignados a dichos dispositivos, los nodosdonde se almacenan o despliegan los artefactos siendo una especializacion delos dispositivos, y sus distintas comunicaciones entre sı a traves de interfaces,servicios o funciones. En este punto de vista, se puede visualizar fısicamente


Figura 7.43: Punto de Vista de Infraestructura

*Fuente: Autores.

como esta constituida la aplicacion web. Con distintas ubicaciones, se lograver la composicion del software. Por ejemplo, en el servidor de HostMonsteresta montado el servidor de la aplicacion web ‘Colosoft’; este servidor ofreceun servicio de alojamiento de dominio, y es accedido por medio de una cone-xion local a internet. Tambien esta la ubicacion de PayPal, que es donde seofrece el servicio de pasarela de pagos; esta pasarela de pagos puede accedera la aplicacion web por medio de una interface de servicio.

Por ultimo, en el extremo se tienen las maquinas fısicas de los clientes,que acceden al servicio de internet por medio de su red local WAN.


7.3.4.2. Punto de Vista de Uso de Infraestructura

Permite visualizar como las aplicaciones son compatibles con el softwarey hardware de infraestructura: los servicios de infraestructura son entrega-dos por los dispositivos; el software y las redes de sistema se proporcionana las aplicaciones. Este punto de vista desempena un papel fundamental enel analisis del rendimiento y escalabilidad, puesto que se refiere a la infraes-tructura fısica para el mundo logico de aplicaciones. Es util en la definicionde requisitos no funcionales y calidad de infraestructura.

Figura 7.44: Metamodelo del Punto de Vista de Infraestructura


El metamodelo presenta en su diagrama una comunicacion entre un compo-nente de aplicacion, que es un elemento activo de la capa de aplicacion, y susrelaciones con el servicio de infraestructura (que es el servicio consumido porel componente de aplicacion), y con la funcion de aplicacion (que presentauna relacion de asignacion, para que el componente realice dicha funcion).


Figura 7.45: Punto de Vista de Uso de Infraestructura

*Fuente: Autores.

Para el desarrollo actual, se diagraman los nodos de los servidores. Porun lado, esta el servidor propio, proporcionado por ‘HostMonster’, en dondese tiene alojado el componente Portal Web ‘Colosoft’. Este servidor propioprovee una funcion de infraestructura como lo es la venta del producto, y asu vez dicha funcion provee el servicio de pago. Este servicio de pago haceuso de la plataforma de pagos, contenido en el lado del servidor de PayPal(proveedor del servicio de pasarela de pagos). Ası, la aplicacion propia haceuna solicitud al servidor del componente externo, en forma de servicio.


7.3.4.3. Punto de Vista de Organizacion e Implementacion

Este punto de vista permite conocer como una o mas aplicaciones se rea-lizan en la infraestructura. Esto comprende la asignacion de aplicaciones ycomponentes en artefactos (fısicas), y el mapeo de la informacion utilizadapor estas aplicaciones y componentes en la infraestructura de almacenamien-to subyacente (logicas). Esta vista es importante al momento de realizar unanalisis de rendimiento y escalabilidad, puesto que se refiere a la infraes-tructura fısica para el mundo logico de aplicaciones. Tambien es util parael analisis de seguridad y riesgo, pues se puede identificar, por ejemplo, lasdependencias y riesgos crıticos.

Figura 7.46: Metamodelo del Punto de Vista de Organizacion e Implemen-tacion


En el diagrama de metamodelo, se puede observar los componentes de aplica-cion y objetos de datos, de la capa de aplicacion, interactuar con el artefactode la capa de infraestructura, siendo estos elementos de aplicacion, un con-cepto mas concreto de dicho artefacto. El artefacto que se comunica con lacapa de aplicacion esta asignado al un nodo de infraestructura. En este punto


Figura 7.47: Punto de Vista de Organizacion e Implementacion

*Fuente: Autores.

de vista se vuelve a enfocar el servidor propio, pero ya no como contenedorde la aplicacion, si no como contenedor de los sistemas de software necesariospara que funcione la aplicacion web. Es ası que se tiene la plataforma Java,ya que sin el soporte de Java, la aplicacion no serıa compatible, y tambien setiene el repositorio de la base de datos.

Es necesario recordar que el servidor es accesible por medio de Internet,y este a su vez es accesible por medio de una red local.


7.3.4.4. Punto de Vista de Estructura de Informacion

Este punto de vista es comparable a modelos tradicionales de informa-cion, creados en el desarrollo de casi cualquier sistema de informacion. Semuestra la estructura de la informacion, usada en la organizacion, o en unproceso especıfico. Puede permitir la visualizacion de la informacion a nivelde negocios, o a nivel de aplicacion en la forma de las estructuras de datosutilizados y como estos son entonces, asignados a la infraestructura subya-cente.

Figura 7.48: Metamodelo del Punto de Vista de Estructura de Informacion


En el caso del metamodelo, aparece el elemento de capa de negocios: ‘Sig-nificado’, que representa la informacion de valor de, en este caso, la repre-sentacion del objeto de negocio. El objeto de negocio en este punto de vista,es la entidad que concreta las ideas logicas del objeto de aplicacion y de larepresentacion del negocio.


Figura 7.49: Punto de Vista de Estructura de Informacion

*Fuente: Autores.

En este punto de vista lo que se busco fue dar un panorama jerarquicobasado en los objetos de las capas de negocio y de aplicacion. Es ası que elobjeto de mayor nivel es el producto final, el cual es conocido como software‘Colosoft’. Este producto esta compuesto de otros objetos de negocio, comola capacitacion (modulo de comunidad), documentos (modulo de transac-cion), entrenamiento (modulo de comunidad) y el objeto software (software‘Coloso’, compuesto de objetos de datos propios: frameworks, plugins, com-ponentes, complementos). En el ultimo nivel, se tienen los objetos de negocioque se resumen en documentos: libros, artıculos, poster, presentaciones; estosobjetos estan disponibles para el cliente por medio del modulo de transaccion.


7.3.4.5. Punto de Vista de Realizacion del Servicio

Se utiliza para mostrar como uno o mas servicios de negocios se realizanpor los procesos subyacentes (y a veces por componentes de la aplicacion).De esta forma, se concreta el puente entre el punto de vista del producto denegocio, y la vista del proceso de negocio. Proporciona una vista externa enuno o varios procesos de negocio.

Figura 7.50: Metamodelo del Punto de Vista de Realizacion del Servicio


En el diagrama del metamodelo, se logra identificar la interaccion entre lascapas de negocio, aplicacion e infraestructura, en donde los servicios y elproceso, de negocio, son accedidos por el servicio de aplicacion. Es allı dondese puede observar que los objetivos de la capa de negocio y los objetivos dela capa de aplicacion, se pueden solapar para tener una vision panoramicade las funciones del negocio, y los papeles que juegan los otros elementos endichas funciones.


Figura 7.51: Punto de Vista de Realizacion del Servicio

*Fuente: Autores.

En este punto de vista se le da enfoque a los servicios de negocio que sehan definido para el producto (software ‘Coloso’), teniendo el acceso a dichoproducto: soporte a arquitectura, diseno y desarrollo de software, y soporteal proceso de ingenierıa de software. Estos servicios son especializaciones delproceso de ingenierıa de software.

Por otro lado esta el objeto de datos referenciado como software. Estees accedido por el servicio de aplicacion de la adquisicion de producto desoftware, una especializacion del componente de pasarela de pagos.


7.3.5. Capa de Implementacion y Migracion

Esta capa anade conceptos para apoyra las fases tardıas de diseno, rela-cionadas con la implementacion y migracion de arquitecturas.


Paquete deTrabajo

Serie de acciones destinadas a lograrun objetivo unico dentro de un plazodeterminado.

Liberable Resultado definido con precision, deun Paquete de Trabajo.

MesetaEstado relativamente estable de laarquitectura que existe durante unperiodo de tiempo limitado.

Brecha Resultado de un analisis de disparidadentre dos Mesetas.

Cuadro 7.13: Elementos participantes de la Capa de Implementacion y Mi-gracion.


7.3.5.1. Punto de Vista de Proyecto

Se utiliza principalmente para modelar la gestion del cambio arquitectoni-co. La arquitectura del proceso de migracion (desde una situacion pasada(arquitectura empresarial en su estado actual), hasta una nueva situaciondeseada (objetivo de la arquitectura empresarial)), tiene consecuencias sig-nificativas en el mediano y largo plazo y el proceso posterior de toma dedecisiones.Algunos puntos importantes a tener en cuenta en los modelos disenados poreste punto de vista, son:

El completo desarrollo de la arquitectura empresarial en toda la orga-nizacion es una tarea que puede requerir varios anos.

Todos los sistemas y servicios deben seguir funcionando sin importartodas las presumibles modificaciones y cambios en la arquitectura em-presarial, durante el proceso de cambio.

El proceso de cambio puede tener que lidiar con los estandares tec-nologicos prematuros.

El cambio tiene consecuencias de gran relevancia para el personal, lacultura, la forma de trabajo y la organizacion.

Figura 7.52: Metamodelo del Punto de Vista de Proyecto


El metamodelo se centra en un “paquete de trabajo” que es el que encapsulalos aspectos de gestion utilizados en el proceso de integracion y migracion. Se


asocia dicho paquete de trabajo con los actores de negocio que interviene enel, y su respectivo rol de negocio, ademas de derivar en objetivos a medianoo largo plazo, y en liberables que permitan la realizacion de dichos objetivos.

Figura 7.53: Punto de Vista de Proyecto

*Fuente: Autores.

Para el diseno de este punto de vista, se utilizo la agrupacion de la plata-forma empresarial, para empaquetar los liberables de cada area, es ası queel proyecto actual se basa en el liberable nombrado ‘portal’, puesto que esel que esta enfocado para los desarrolladores; los liberables ‘Coloso’, y ‘bro-chure’ estan enfocados para ser entregados por el arquitecto de software, y elpromotor respectivamente. El paquete de trabajo que concierne a los desa-rrolladores, es el de integracion de los otros dos, para promover, divulgar yvender a traves del portal de investigacion.


7.3.5.2. Punto de Vista de Migracion

Este punto de vista implica modelos y conceptos que pueden ser utilizadospara especificar la transicion de una arquitectura existente a una arquitecturadeseada.

Figura 7.54: Metamodelo del Punto de Vista de Migracion


En el metamodelo se presenta la definicion de este punto de vista, desde losconceptos que se manejan en torno a la brecha y la platea, donde una (platea)refleja el estado actual de una arquitectura, y la otra (brecha) permite realizarla comparacion entre la arquitectura actual y la que se desea.

Figura 7.55: Punto de Vista de Migracion

*Fuente: Autores.

En este punto de vista se tienen en cuenta los estados de la arquitectura,


teniendo tres estados fundamentales: el estado base, el estado de transicion yel estado objetivo. En medio de cada estado de la arquitectura, se encuentranlas brechas que existen entre uno y otro estado.


7.3.5.3. Punto de Vista de Migracion e Implementacion

Se utiliza para relacionar los programas y proyectos a las partes de laarquitectura que se implementan. Esta vision permite el modelado del ambi-to de aplicacion de los programas, proyectos, o actividades del proyecto, enterminos de las plateas que se realizan o los elementos individuales de arqui-tectura que se ven afectados. Ademas, la forma en que los elementos se venafectados puede ser indicada por las relaciones.

Figura 7.56: Metamodelo del Punto de Vista de Migracion e Implementacion


En el metamodelo se puede observar el objeto de accion de la aplicacion,como lo es el liberable, que satisface un requerimiento o restriccion para al-canzar los objetivos planteados; ası mismo el liberable se integra a la platea oestado actual de arquitectura. Este liberable viene de un paquete de trabajodonde interactua con los actores y sus respectivos roles en la organizacion.


3cm3cmFigura 7.57: Punto de Vista de Migracion e Implementacion

*Fuente: Autores.

En este punto de vista se detalla el rol que poseen los desarrolladores delpresente proyecto, junto con el paquete de trabajo que le corresponde a dichorol. El liberable, al final del proceso de desarrollo, sera el portal empresarial,y cuenta con la realizacion de dos requerimientos importantes como lo son lagestion de usuarios y la gestion de pagos, que a su vez estan relacionadas conlos objetivos primordiales: crear comunidad web, y comercializar el producto.

Por ultimo se relacionan los estados de la arquitectura, especificando laarquitectura base ya implementada, y la arquitectura actual, basandose enla brecha que hay para el proceso de mejoramiento.

Capıtulo 8

PROTOTIPO

Para la implementacion de los difenrentes servicios de la comunidad weby la transaccionabilidad, se realizo una implementacion de herramientas li-bres que brindan la funcionalidad adecuada para cada proposito.

A continuacion se ven los prototipos de como acceder a estas herramientas,y la implementacion de las herramientas mismas, alineadas con el cumpli-miento de los objetivos de este proyecto.

142

CAPITULO 8. PROTOTIPO 143

Figura 8.1: Imagen 1 de Prototipo: Pagina de versiones de Coloso.

*Fuente: Autores.

Para la comercializacion de productos se manejan 3 versiones o categorıasde productos; la version academica, la version comunitaria o profesional y laversion empresarial, cada una de ellas con diferentes caracterısticas, puedenser de pago o gratuitas.


Figura 8.2: Imagen 2 de Prototipo: Pagina de ingreso a la Wiki.

*Fuente: Autores.

Para acceder a las herramientas relacionadas con la base de datos de co-nocimiento, se implementaron links de acceso desde el portal principal de lapagina de Colosoft, ubicados en la pestana “comunidad”.

En la imagen, se observa la pantalla principal del enlace al ingreso de laWiki de Colosoft.


Figura 8.3: Imagen 3 de Prototipo: Visualizacion preliminar de la Wiki.

*Fuente: Autores.

La wiki que es una de las principales herramientas de la base de datosde conocimiento se implemento con ayuda de una herramienta libre que pro-vee MediaWiki, posteriormente se realizaron los ajustes necesarios para sufuncionamiento y adaptacion al entorno.


Figura 8.4: Imagen 4 de Prototipo: Pagina de ingreso al foro.

*Fuente: Autores.

Ası mismo, se puede ingresar al foro de Colosoft, por medio de un enlacecontenido dentro del grupo de Comunidad”, en la pestana del mismo nombredentro de la plataforma.


Figura 8.5: Imagen 5 de Prototipo: Visualizacion preliminar del foro.

*Fuente: Autores.

El foro, de manera muy similar a la Wiki, se implemento con la ayu-da de una herramienta de software libre, que provee simple machine forum(http://www.simplemachines.org/). Esta tambien se adapto a los requeri-mientos de Colosoft.


Figura 8.6: Imagen 6 de Prototipo: Pagina de ingreso a los blogs.

*Fuente: Autores.

Por ultimo, se puede visualizar en la imagen, el enlace que se dirige alsitio de blogs. Aunque este espacio aun esta en construccion, ya se presentaun espacio en la plataforma para acceder a dicho servicio. Es posible que estaopcion ya no sea considerada en la revision posterior de los requerimientos.

Capıtulo 9

CONCLUSIONES YTRABAJO FUTURO

En el desarrollo del presente proyecto se evidencio las grandes ventajas quese obtienen despues de tener en cuenta los principios basicos de usabilidad ycomo estos se relacionan con las propiedades de la simplicidad, ya que, juntos,hacen que la calidad del software aumente considerablemente en comparaciona un producto que no incluya estas propiedades.

Se busco orientar el portal web ya existente a un entorno mas social,implementando aplicaciones que permitieron la creacion de una comunidadde conocimiento alrededor del mismo, con lo que se prentende generar unmayor trafico sobre el portal y ası facilitar los accesos al conocimiento porparte de los usuarios finales.

En el proceso de desarrollo de software es importante buscar nuevas es-trategias orientadas a mejorar y complementar las actividades de analisis ydiseno de software, con el fin de corregir los problemas que se evidencianhabitualmente en los procesos de analisis y diseno tradicionales.

Con Archimate se logro hacer una abstraccion amplia del funcionamientodel negocio, lo que sirvio de pilar para el proceso del diseno y posteriorimplementacion del software, y en base a esta experiencia se recomienda suuso en las fases de planeacion y analisis.

El analisis adecuado de la arquitectura empresarial previa al proceso dedesarrollo del software hizo que se identificaran nuevas necesidades para el

149

CAPITULO 9. CONCLUSIONES Y TRABAJO FUTURO 150

portal, lo que nos sirvio para establecer los objetivos del proyecto actual. Alfinal del desarrollo del proyecto, se evidencia que con ayuda de los principiosde usabilidad y la adopcion de una metodologıa pertinente, aplicando ası elconcepto de metaproceso, se cumplio con los objetivos del proyecto.

El presente proyecto se desarrollo bajo en contexto de una compania deservicios informaticos, sin embargo, es factible que esta solucion se pueda ge-neralizar para cualquier tipo de compania que necesite vender algun servicioo producto. Esto se plantea como una futura mejora.

Referencias

AMPLIMARK, E. ¿por que la experiencia de usuario realmen-te importa?. [en lınea]. Disponible en internet en la direccion:http://www.amplimark.com/user-experience (Acceso 14 de Mayo de 2011).

BOLANOS, S., GONZALEZ, R. A., ARISMENDI, A., and CASTANEDA,J. (2012). Un lenguaje de procesos para la industria del software. RevistaIberoamericana de Automatica e Informatica industrial, pages 1–12.

BOLANOS CASTRO, S. J. and MEDINA GARCIA, V. H. (2013). Meta-proceso del desarrollo de software: El grial de las metodologıas y procesos.

CABALLERO QUEMADES, F. and MONRORG CLIMENT, V. (2004).Informacion y Conocimiento en la Era de Internet.

CALERO, C., MORAGA, M. A., and PIATTINI, M. G. (2012). Calidaddel producto y proceso de software.

CANOS, J. H., LETELIER, P., and Carmen, P. M. Metodologıas Agiles enel desarrollo de software. DSIC -Universidad Politecnica de Valencia.

DATE, C. J. and FAUDON, S. L. (2001). Introduccion a los sistemas debases de datos. Pearson Educacion.

EGEA GARCIA, C. (2003). Diseno Web para todo@s: Accesibilidad al con-tenido en la Web.

FERNANDEZ, A. (1998). Produccion y diseno grafico para la Worl WideWeb.

151

REFERENCIAS 152

GAMEZ GAMEZ, A., SOLER Martınez, J., and RANDO GONZALEZ,E. (2001). El comercio electronico internacional: las webs que consiguenexportar.

GUAZMAYAN RUIZ, C. (2004). Internet y la Investigacion Cientıfica: ElUso de los Medios y las Nuevas Tecnologıas en la Educacion.

JACOBSON, I., BOOCH, G., and RUMBAUGH, J. (2000). El ProcesoUnificado de Desarrollo de Software.

JEFFRIES, R., ANDERSON, A., and HENDRICKSON, C. (2001). Extre-me Programming Installed.

KULAK, D. and GUINEY, E. (2012). Use Cases: Requirements in Context.

LARA NAVARRA, P. and MARTINEZ USERO, J. n. (2006). La Organi-zacion del Conocimiento en Internet.

LAUDON, K. C. and WESLE, A. (2014). E-Commerce 2013: Negocios,Tecnologia, Sociedad.

LICHTER, H., SCHNEIDER-HUFSCHMIDT, M., and ZULLIGHOVEN,H. (1994). Prototyping in industrial software projects-bridging the gapbetween theory and practice. pages 825–832.

MAEDA, J. (2006). The laws of Simplicity: Design, technology, business,life. MIT Press.

MORVILLE, P. Column about information architecture and findabi-lity. junio 21 de 2004. [en lınea]. Disponible en internet en la direc-cion: http://semanticstudios.com/publications/semantics/000029.php (Ac-ceso 14 de Mayo de 2011).

PRESSMAN, R. S. (2005). Software Engineering: A Practitioner’s Ap-proach.

ROSENBERG, D. and STEPHENS, M. (2007). Use Case Driven ObjectModeling with UML: Theory and Practice. Apress.

SAM-BODDEN, B. and JUDD, C. (2004). Enterprise Java Developmenton a Budget: Leveraging Java Open Source Technologies. Apress.

REFERENCIAS 153

SINTES, A. (2001). Sams Teach Yourself Object Oriented Programming in21 Days.

SOMERVILLE, I. (2005). Ingenierıa del software.

THE OPEN GROUP, E. (2013a). Togaf R© version 9.1, guıa de bolsillo.

THE OPEN GROUP, E. (2013b). Welcome to archimate R© 2.1, an opengroup standard.

ZHANG, L.-J., ZHANG, J., and CAI, H. (2007). Services Computing. Sprin-ger.

PROTOTIPO DE ARQUITECTURA EMPRESARIAL …repository.udistrital.edu.co/bitstream/11349/3104/1... ·...

Documents

Transcript of PROTOTIPO DE ARQUITECTURA EMPRESARIAL …repository.udistrital.edu.co/bitstream/11349/3104/1... ·...