UNIVERSIDAD NACIONAL DE CHIMBORAZO

FACULTAD DE INGENIERA
ESCUELA DE INGENIERA EN SISTEMAS Y COMPUTACIN

Trabajo de grado previo a la obtencin del Ttulo de Ingeniero en Sistemas

y Computacin

TRABAJO DE GRADUACIN

Ttulo del proyecto

PROPUESTA METODOLOGA PARA LA IMPLEMENTACIN DE
SISTEMAS DE INFORMACIN WEB DISEADOS Y CENTRADOS EN LOS
USUARIOS. CASO PRCTICO: SISTEMA PARA LA GESTIN JUDICIAL.

Autor:
Angel Geovanny Cudco Pomagualli

Director:
Ing. Jorge Delgado

Riobamba Ecuador
2014
I

Los miembros del Tribunal de Graduacin del proyecto de investigacin de ttulo:

PROPUESTA METODOLGICA PARA LA IMPLEMENTACIN DE
SISTEMAS DE INFORMACIN WEB DISEADOS Y CENTRADOS EN
LOS USUARIOS. CASO PRCTICO: SISTEMA PARA LA GESTIN
JUDICIAL, presentado por: Angel Geovanny Cudco Pomagualli y dirigida por:
Ing. Jorge Delgado.
Una vez escuchada la defensa oral y revisado el informe final del proyecto de
investigacin con fines de graduacin escrito en la cual se ha constatado el
cumplimiento de las observaciones realizadas, remite la presente para uso y
custodia en la biblioteca de la Facultad de Ingeniera de la UNACH.
Para constancia de lo expuesto firman:

Ing. Fernando Molina Granja

-------------------------------------------

Presidente del Tribunal

Firma

Ing. Jorge Delgado

-------------------------------------------

Director del Proyecto

Firma

Ing. Danny Velasco

-------------------------------------------

Miembro del Tribunal

Firma

II

AUTORA DE LA INVESTIGACIN

La responsabilidad del contenido de este

Proyecto de Graduacin, nos corresponde
exclusivamente a: Angel Geovanny Cudco
Pomagualli (Autor) y del Ing. Jorge Delgado
(Director); y el patrimonio intelectual de la
misma

la

Chimborazo.

III

Universidad

Nacional

de

AGRADECIMIENTO

Agradezco de manera muy especial a la Universidad

Nacional de Chimborazo, a la Facultad de Ingeniera y a la
Escuela de Ingeniera en Sistemas y Computacin por los
conocimientos adquiridos y ser mi segundo hogar durante todo
este tiempo de formacin acadmica.
De igual manera me gustara que estas lneas sirvieran
para expresar mi ms profundo y sincero agradecimiento a
todas aquellas personas que con su ayuda han colaborado en la
realizacin del presente trabajo, en especial al Ing. Jorge
Delgado, director de esta investigacin, por la orientacin, el
seguimiento y la supervisin contina de la misma, pero sobre
todo por la motivacin y el apoyo recibido a lo largo de estos
aos.
Especial reconocimiento merece el inters mostrado
por mi trabajo y las sugerencias recibidas por parte del Ing.
Fernando Molina, quien adems de ser docente es un amigo
con quien me encuentro en deuda por el nimo infundido y la
confianza en m depositada. Tambin me agradezco la ayuda
recibida del Ing. Danny Velasco.
Un

agradecimiento

muy

especial

merece

la

comprensin, paciencia y el nimo recibidos de mi familia y

amigos.
A todos ellos, muchas gracias

IV

DEDICATORIA

A mi familia quienes por ellos soy lo que soy.

Para mis padres por su apoyo, consejos,
comprensin, ayuda en los momentos difciles, y por
ayudarme con los recursos necesarios para estudiar.
Me han dado todo lo que soy como persona, mis
valores, mis principios, mi carcter, mi empeo, mi
perseverancia, mi coraje para conseguir mis
objetivos.
A mis hermanos por estar siempre presentes,
acompandome para poderme realizar. A mi sobrina
Andrea quien ha sido y es una mi motivacin,
inspiracin y felicidad.

La dicha de la vida consiste en tener siempre

algo que hacer, alguien a quien amar y alguna cosa
que esperar. Thomas Chalmers.

NDICE GENERAL
AUTORA DE LA INVESTIGACIN ................................................................ III
AGRADECIMIENTO .......................................................................................... IV
DEDICATORIA .....................................................................................................V
NDICE GENERAL.............................................................................................. VI
INDICE DE FIGURAS ......................................................................................... XI
INDICE DE TABLAS ......................................................................................... XV
RESUMEN....................................................................................................... XVIII
SUMARY............................................................................................................. XX
INTRODUCCIN .................................................................................................. 1
CAPITULO I
MARCO REFERENCIAL
1.1.

TTULO DEL PROYECTO........................................................................ 3

1.2.

PROBLEMATIZACIN ............................................................................ 3

1.2.1. IDENTIFICACIN Y DESCRIPCIN DEL PROBLEMA ...................... 3

1.2.2. ANLISIS CRTICO .................................................................................. 4
1.2.3. PROGNOSIS ............................................................................................... 4
1.2.4. DELIMITACIN ........................................................................................ 5
1.2.5. FORMULACIN DEL PROBLEMA ........................................................ 5
1.2.6. HIPTESIS ................................................................................................. 5
1.2.7. IDENTIFICACIN DE LAS VARIABLES .............................................. 6
1.3.

OBJETIVOS................................................................................................ 6

1.3.1. GENERAL .................................................................................................. 6

1.3.2. ESPECFICOS ............................................................................................ 6
1.4.

JUSTIFICACIN ........................................................................................ 6
CAPITULO II
ESTUDIO COMPARATIVO DE METODOLOGAS PARA LA
IMPLEMENTACIN DE SISTEMAS DE INFORMACIN WEB

2.1.

INTRODUCCION A LOS SISTEMAS DE INFORMACIN .................. 8

VI

2.2.

SISTEMAS DE INFORMACIN .............................................................. 9

2.2.1. DEFINICIN DE UN SISTEMA DE INFORMACIN ........................... 9

2.2.2. COMPONENTES DE UN SISTEMA DE INFORMACIN................... 12
2.2.3. CLASIFICACIN DE UN SISTEMA DE INFORMACIN .................. 12
2.2.4. TIPOS DE SISTEMAS DE INFORMACIN.......................................... 13
2.3.

INGENIERA WEB .................................................................................. 14

2.3.1. EL PROCESO DE INGENIERA WEB ................................................... 14

2.3.2. CONTROL Y GARANTA DE LA CALIDAD ....................................... 15
2.3.3. CONTROL DE LA CONFIGURACIN ................................................. 15
2.3.4. LA GESTIN DEL PROCESO ................................................................ 16
2.3.5. DIFERENCIA CON LA INGENIERA DE SOFTWARE ...................... 16
2.4.

METODOLOGA OOHDM (OBJECT ORIENTED HYPERMEDIA

DESIGN METHODOLOGY) ................................................................... 17

2.4.1. INTRODUCCIN A OOHDM ................................................................ 17

2.4.2. FASES DE LA METODOLOGA OOHDM ............................................ 18
2.4.3. VENTAJAS DE OOHDM ........................................................................ 24
2.5.

METODOLOGA SOHDM ...................................................................... 25

2.5.1. FASES DE LA METODOLOGA SOHDM ............................................ 26

2.6.

METODOLOGA WSDM ........................................................................ 26

2.6.1. FASES DE LA METODOLOGA WSDM .............................................. 27

2.7.

METODOLOGA EORM ......................................................................... 30

2.7.1. INTRODUCCIN A LA METODOLOGA EORM ............................... 30

2.7.2. FASES DE LA METODOLOGA EORM ............................................... 31
2.7.3. VENTAJAS DE LA METODOLOGA EORM ....................................... 33
2.8.

ESTUDIO COMPARATIVO DE METODOLOGAS PARA EL DISEO

WEB .......................................................................................................... 33

2.8.1. REQUISITOS TRATADOS ..................................................................... 34

2.8.2. FASES DEL CICLO DE VIDA DE DESARROLLO DEL SOFTWARE41
2.8.3. CARACTERSTICAS DE LAS METODOLOGAS ............................... 46

VII

CAPITULO III
DESARROLLO DE UNA PROPUESTA METODOLGICA PARA LA
IMPLEMENTACIN DE SISTEMAS WEB BASADOS Y CENTRADOS EN
LOS USUARIOS
3.1.

DESARROLLO DE LA PROPUESTA .................................................... 49

3.1.1. REQUISITOS TRATADOS ..................................................................... 49

3.1.2. FASES DEL CICLO DE VIDA ................................................................ 51
3.1.3. CARACTERSTICAS .............................................................................. 56
3.2.

DESCRIPCIN DE LA METODOLOGA ............................................. 58

3.2.1. FASES DE LA METODOLOGA MEDWCU ........................................ 58

CAPITULO IV
APLICACIN DE LA PROPUESTA METODOLGICA MEDWCU PARA LA
IMPLEMENTACIN DE SISTEMAS WEB PARA LA GESTIN JURDICA
SIGEJ
4.1.

FASE 1: PLANIFICACIN ..................................................................... 70

4.1.1. VISIN GENERAL DEL SISTEMA ....................................................... 70

4.1.2. ESTUDIO DE VIABILIDAD ................................................................... 75
4.2.

FASE 2: ANLISIS .................................................................................. 80

4.2.1. ESPECIFICACIN DE REQUISITOS .................................................... 82

4.2.2. ANLISIS DE REQUISITOS .................................................................. 84
4.3.

DISEO .................................................................................................... 90

4.3.1. ARQUITECTURA DE LA SOLUCIN .................................................. 90

4.3.2. DISEO DE BASES DE DATOS ............................................................ 96
4.3.3. DISEO NAVEGACIONAL ................................................................... 99
4.3.4. DISEO DE INTERFAZ ABSTRACTA ............................................... 100
4.4.

CONSTRUCCIN .................................................................................. 100

4.4.1. PREPARACIN DEL ENTORNO DE TRABAJO ............................... 100

4.4.3. CREACIN DE MDULOS Y COMPONENTES. .............................. 101
4.5.

IMPLEMENTACIN Y MANTENIMIENTO ...................................... 101

VIII

CAPITULO V
METODOLOGA
5.1.

TIPO DE ESTUDIO ................................................................................ 102

5.1.1. SEGN EL OBJETO DE ESTUDIO: .................................................... 102

5.1.2. SEGN LA FUENTE DE INVESTIGACIN: ..................................... 102
5.1.3. SEGN LAS VARIABLES: .................................................................. 102
5.2.

POBLACIN Y MUESTRA .................................................................. 102

5.2.1. POBLACIN .......................................................................................... 102

5.2.2. MUESTRA .............................................................................................. 103
5.3.

OPERACIONALIZACIN DE VARIABLES ...................................... 103

5.4.

PROCEDIMIENTOS .............................................................................. 105

5.4.1. FUENTES DE INFORMACIN. ........................................................... 105

5.4.2. TCNICAS DE INVESTIGACIN. ...................................................... 105
5.4.3. INSTRUMENTOS DE RECOLECCIN DE DATOS. ......................... 105
5.5.

PROCESAMIENTO Y ANLISIS. ....................................................... 106

5.5.1. TEORA FUNDAMENTADA EN DATOS. .......................................... 106

5.5.2. ANLISIS DE TAREAS ........................................................................ 106
5.6.

COMPROBACIN DE HIPTESIS ..................................................... 106

5.6.1. NIVEL DE SIGNIFICANCIA ................................................................ 107

5.6.2. CLCULOS ............................................................................................ 107
5.6.3. DECISIN .............................................................................................. 110
CAPITULO VI
RESULTADOS Y DISCUSIN
6.1.

RESULTADOS ....................................................................................... 111

6.1.1. ANLISIS DE RESULTADOS DEL ESTUDIO COMPARATIVO DE

LAS METODOLOGAS......................................................................... 111
6.1.2. ANLISIS DE LA PROPUESTA METODOLGICA MEDWCU
FRENTE A LAS OTRAS METODOLOGAS. ..................................... 114
6.2.

DISCUSIN ............................................................................................ 118

IX

6.2.1. ANLISIS DE LAS METODOLOGAS EORM, WSDM, SOHDM Y

OOHDM. ................................................................................................. 118
CAPITULO VII
CONCLUSIONES Y RECOMENDACIONES
7.1.

CONCLUSIONES .................................................................................. 122

7.2.

RECOMENDACIONES ......................................................................... 124

CAPITULO VIII
PROPUESTA

8.1.

BASES DE LA PROPUESTA ................................................................ 125

8.2.

FASES DEL CICLO DE VIDA .............................................................. 126

8.2.1. PLANIFICACIN .................................................................................. 127

8.2.2. ANLISIS ............................................................................................... 129
8.2.3. DISEO .................................................................................................. 132
8.2.4. CONSTRUCCIN .................................................................................. 134
8.2.5. IMPLEMENTACIN Y MANTENIMIENTO ...................................... 134
9.

BIBLIOGRAFA .................................................................................. 135

10.

ANEXOS .............................................................................................. 138

INDICE DE FIGURAS
FIGURA 1. SISTEMA DE INFORMACIN. .................................................................. 10
FIGURA 2. INVERSIN EN CAPITAL DE TECNOLOGA DE LA INFORMACIN .............. 10
FIGURA 3. ACTIVIDADES DE UN SISTEMA DE INFORMACIN .................................. 12
FIGURA 4. MODELO CONCEPTUAL PARA UNA TIENDA DE CD'S.............................. 20
FIGURA 5. ESQUEMA BSICO NAVEGACIONAL PARA MY.YAHOO.COM .................... 21
FIGURA 6. DIAGRAMA DE CONFIGURACIN PARA LOS NODOS ADV. ..................... 23
FIGURA 7. DIAGRAMA DE CONFIGURACIN PARA LOS NODOS ADV. ..................... 23
FIGURA 8. METODOLOGA SOHDM....................................................................... 25
FIGURA 9. ANLISIS DE REQUISITOS DE LA METODOLOGA WSDM. ..................... 29
FIGURA 10. EJEMPLO DE MODELO ORIENTADO A OBJETOS FASE DE ANLISIS. ..... 31
FIGURA 11. EJEMPLO DE MODELO ORIENTADO A OBJETOS FASE DE DISEO. ........ 32
FIGURA 12. ANLISIS DE LOS REQUISITOS DE DATOS. ........................................... 35
FIGURA 13. ANLISIS DE LOS REQUISITOS DE INTERFAZ DE USUARIO. ................... 36
FIGURA 14. ANLISIS DE LA COMPARATIVA DE REQUISITOS NAVEGACIONALES. .... 37
FIGURA 15. ANLISIS DE LOS REQUISITOS DE PERSONALIZACIN. .......................... 38
FIGURA 16. ANLISIS DE LOS REQUISITOS TRANSACCIONALES.............................. 39
FIGURA 17. ANLISIS DE LA COMPARATIVA DE REQUISITOS NO FUNCIONALES. ..... 40
FIGURA 18. ANLISIS DEL CUMPLIMIENTO DE LOS REQUISITOS DE DATOS. ........... 41
FIGURA 19. ANLISIS

DE LA

COMPARATIVA

DE LA

FASE

DE IDENTIFICACIN DE

REQUERIMIENTOS. .............................................................................. 42
FIGURA 20. ANLISIS ESTADSTICO DE LA FASE DE ANLISIS. ............................... 43
FIGURA 21. ANLISIS DE LA FASE DE DISEO. ....................................................... 44
FIGURA 22. ANLISIS DE LA COMPARATIVA DE LA FASE DE CONSTRUCCIN. ....... 44
FIGURA 23. ANLISIS

DE LA

COMPARATIVA

DE LA

FASE

DE IMPLEMENTACIN Y

MANTENIMIENTO. ............................................................................... 45
FIGURA 24. ANLISIS

DE LA COMPARATIVA DE LAS FASES DEL CICLO DE VIDA DE

DESARROLLO DEL SOFTWARE. ............................................................. 46

FIGURA 25. ANLISIS DE LAS CARACTERSTICAS DE LAS METODOLOGAS. ........... 47

FIGURA 26. TRATAMIENTO DE LOS REQUISITOS DE LA PROPUESTA METODOLGICA
FRENTE A LAS DEMS METODOLOGAS EN ESTUDIO. ........................... 51

XI

FIGURA 27. FASES

DEL

CICLO

DE

VIDA

DE DESARROLLO DE SOFTWARE DE LAS

METODOLOGAS EN ESTUDIO Y LA PROPUESTA. .................................. 53

FIGURA 28. CUMPLIMIENTO DE

LAS CARACTERSTICAS DE LAS

METODOLOGAS DE

DISEO WEB CENTRADO EN EL USUARIO. ............................................ 57

FIGURA 29. FASES DE LA METODOLOGA MEDWCU. ........................................... 59

FIGURA 30. VIABILIDAD ECONMICA. .................................................................... 79
FIGURA 31. RELACIN COSTO - BENEFICIO CON COCOMO II. ............................. 80
FIGURA 32. CASO DE USO: ACCEDER AL SISTEMA. ................................................ 88
FIGURA 33. CASOS DE USO: MDULO CLIENTES.................................................... 89
FIGURA 34. CASOS DE USO: MDULO CASOS. ....................................................... 89
FIGURA 35. CASOS DE USO: MDULO OPERADORES DE JUSTICIA. ......................... 89
FIGURA 36. CASOS DE USO: MDULO MATERIA. ................................................... 90
FIGURA 37. CASOS DE USO: MDULO REPORTES. .................................................. 90
FIGURA 38. DIAGRAMA DE ARQUITECTURA DEL SIGEJ ......................................... 91
FIGURA 39. VISTA LGICA DEL SIGEJ................................................................... 93
FIGURA 40. DIAGRAMA DE DESPLIEGUE DEL SIGEJ. .............................................. 95
FIGURA 41. DIAGRAMA E - R. ................................................................................ 96
FIGURA 42. DIAGRAMA DE BASE DE DATOS. .......................................................... 97
FIGURA 43. DIAGRAMA DE CLASES. ....................................................................... 98
FIGURA 44. DIAGRAMA DE NAVEGACIN. ............................................................. 99
FIGURA 45. MAPA DEL SITIO DEL SISTEMA DE GESTIN JURDICA. ....................... 99
FIGURA 46. INTERFAZ ABSTRACTA. ..................................................................... 100
FIGURA 47. DISTRIBUCIN CHI CUADRADA ......................................................... 109
FIGURA 48. ACEPTACIN DE LA HIPTESIS DE INVESTIGACIN. .......................... 110
FIGURA 49. RESULTADO

COMPARATIVO DE LAS METODOLOGAS SEGN EL

TRATAMIENTO DE REQUISITOS. ......................................................... 112

FIGURA 50. RESULTADO COMPARATIVO DE LAS METODOLOGAS SEGN LOS CICLO DE
VIDA DE DESARROLLO DEL SOFTWARE. ............................................. 113

FIGURA 51. RESULTADO

COMPARATIVO DE LAS METODOLOGAS SEGN LAS

CARACTERSTICAS DE LAS METODOLOGAS. ...................................... 114

XII

FIGURA 52. RESULTADO COMPARATIVO SEGN EL TRATAMIENTO DE REQUISITOS DE

LA

PROPUESTA METODOLGICA MEDWCU

FRENTE A LAS DEMS

METODOLOGAS EN ESTUDIO............................................................. 115

FIGURA 53. RESULTADO

COMPARATIVO SEGN LAS FASES DEL

DESARROLLO

DE

SOFTWARE

CICLO DE VIDA DE

POR PARTE DE LAS

METODOLOGAS

ESTUDIADAS Y LA PROPUESTA METODOLGICA MEDWCU. ............ 116

FIGURA 54. RESULTADO

COMPARATIVO SEGN LAS CARACTERSTICAS DE LAS

METODOLOGAS

ESTUDIADAS Y DE LA

PROPUESTA METODOLGICA

MEDWCU. ....................................................................................... 117

FIGURA 55. RESUMEN DE LAS FASES DE LA METODOLOGA MEDWCU. .............. 127
FIGURA 56. CATLOGO DE SOFTWARE EN DREAMSPARK ............................... 139
FIGURA 57. SECCION DE DESCARGAS DE VISUAL STUDIO 2013............................ 139
FIGURA 58. SELECCIN DEL MEDIO DE INSTALACIN. .......................................... 140
FIGURA 59. DESCARGA DEL MEDIO DE INSTALACIN. .......................................... 140
FIGURA 60. INICIO DEL PROCESO DE INSTALACIN DE VISUAL STUDIO 2013. ...... 141
FIGURA 61. PANTALLA QUE SE MUESTRA AL FINALIZAR LA INSTALACIN. .......... 141
FIGURA 62. PRIMERA

PANTALLA DE DIALOGO DESPUS DE FINALIZAR LA

INSTALACIN..................................................................................... 142

FIGURA 63. ENTORNO DE TRABAJO LISTO PARA USAR. ......................................... 142

FIGURA 64. CUADRO

DE DIALOGO AL INICIAR LA INSTALACIN DEL SERVIDOR DE

BASES DE DATOS. ............................................................................... 143

FIGURA 65. NUEVA INSTALACIN DEL SERVIDOR DE BASES DE DATOS................. 143

FIGURA 66. VERIFICACIN

DE LOS REQUISITOS DE INSTALACIN DEL SQL

SERVER.

.......................................................................................................... 144
FIGURA 67. INGRESO DEL SERIAL DEL SQL SERVER. ........................................... 144
FIGURA 68. REVISIN
ENCONTRAR.

DE LOS POSIBLES INCONVENIENTES QUE SE PUDIESEN

..................................................................................... 144

FIGURA 69. CARACTERSTICAS A INSTALAR. ........................................................ 145

FIGURA 70. RESUMEN DE LAS CARACTERSTICAS A INSTALAR. ............................ 145
FIGURA 71. CHEQUEO DE LOS REQUISITOS DE SOFTWARE. ................................... 145
FIGURA 72. INICIO DEL PROCESO DE INSTALACIN DE SQL SERVER. ................... 146
FIGURA 73. ESPACIO DE DISCO DURO REQUERIDO PARA LA INSTALACIN. ........... 146

XIII

FIGURA 74. AGREGAR USUARIOS ADMINISTRADORES DEL SQL SERVER.............. 146

FIGURA 75. ASIGNACIN DE PERMISOS DE LOS ADMINISTRADORES DEL SQL SERVER.
.......................................................................................................... 147
FIGURA 76. CONFIRMACIN DE REQUISITSOS PARA LA INSTALACIN. ................. 147
FIGURA 77. INICIO DEL PROCESO DE INSTALACIN. .............................................. 147
FIGURA 78. FIN DEL PROCESO DE INSTALACIN DE SQL SERVER. ....................... 148
FIGURA 79. SECCIN CONFIGURACN EN WINDOWS 8. ........................................ 177
FIGURA 80. AGREGAR

CARACTERSTICAS DE

WINDOWS

WEN ESTE CASO INTERNET

INFORMATION SERVER. ..................................................................... 177

FIGURA 81. INSTALACIN LAS CARACTERSTICAS DE WINDOWS. ......................... 178
FIGURA 82. CONFIRMACIN DE LA CORRECTA INSTALACIN DE IIS. ................... 178
FIGURA 83. DIRECTORIO RAZ DE IIS. .................................................................. 179
FIGURA 84. CONVERTIR LA CARPETA CON EL CDIGO PRECOMPILADO EN APLICACIN
WEB A TRAVS DEL IIS MANAGER. .................................................. 179
FIGURA 85. SIGEJ VISTO DESDE UN NAVEGADOR WEB. ....................................... 179
FIGURA 86. SIGEJ VISTO DESDE UN DISPOSITIVO MVIL. ...................................... 180

XIV

INDICE DE TABLAS
TABLA 1. VALORACIN PARA LAS METODOLOGAS. .............................................. 34
TABLA 2. COMPARATIVA DE REQUISITOS DE DATOS ............................................. 35
TABLA 3. INTERPRETACIN DE RESULTADOS DE LA COMPARATIVA DE REQUISITOS
DE DATOS ............................................................................................ 35

TABLA 4. COMPARATIVA DE REQUISITOS DE INTERFAZ DE USUARIO ..................... 35

TABLA 5. INTERPRETACIN DE RESULTADOS DE LA COMPARATIVA DE REQUISITOS
DE INTERFAZ DE USUARIO ................................................................... 36

TABLA 6. COMPARATIVA DE REQUISITOS NAVEGACIONALES. ................................ 37

TABLA 7. ANLISIS DE LA COMPARATIVA DE LOS REQUISITOS NAVEGACIONALES. 37
TABLA 8. COMPARATIVA DE LOS REQUISITOS DE PERSONALIZACIN .................... 38
TABLA 9. PONDERACIN

DE

PERSONALIZACIN.

LA

COMPARATIVA

DE

LOS

REQUISITOS

DE

............................................................................. 38

TABLA 10. COMPARATIVA DE LOS REQUISITOS TRANSACCIONALES ...................... 38

TABLA

11.

CALIFICACIN

DE

LA

COMPARATIVA

DE

LOS

REQUISITOS

TRANSACCIONALES. ............................................................................ 39
TABLA 12. COMPARATIVA DE LOS REQUISITOS NO FUNCIONALES.......................... 39
TABLA 13. INTERPRETACIN

DE LA

COMPARATIVA

DE LOS

REQUISITOS

NO

FUNCIONALES. ..................................................................................... 39

TABLA 14. TIPOS DE REQUISITOS CONTEMPLADOS EN CADA PROPUESTA ............... 40

TABLA 15. CALIFICACIN

TIPOS DE REQUISITOS CONTEMPLADOS EN CADA

PROPUESTA .......................................................................................... 40

TABLA 16. COMPARATIVA DE LA FASE DE IDENTIFICACIN DE REQUERIMIENTOS 42

TABLA 17. CALIFICACIN A LA COMPARATIVA DE LA FASE DE IDENTIFICACIN DE
REQUERIMIENTOS. .............................................................................. 42
TABLA 18. COMPARATIVA DE LA FASE DE ANLISIS ............................................. 42
TABLA 19. CALIFICACIN A LA COMPARATIVA DE LA FASE DE ANLISIS. ............. 43
TABLA 20. COMPARATIVA DE LA FASE DE DISEO ................................................ 43
TABLA 21. CALIFICACIN A LA COMPARATIVA DE LA FASE DE DISEO ................. 43
TABLA 22. COMPARATIVA DE LA FASE DE CONSTRUCCIN ................................... 44

XV

TABLA 23. CALIFICACIN A LAS METODOLOGAS DE LA COMPARATIVA DE LA FASE

DE CONSTRUCCIN. ............................................................................. 44

TABLA 24. COMPARATIVA DE LA FASE DE IMPLEMENTACIN Y MANTENIMIENTO. 45

TABLA 25. CALIFICACIN A LA COMPARATIVA DE LA FASE DE IMPLEMENTACIN Y
MANTENIMIENTO. ............................................................................... 45
TABLA 26. RESUMEN DE LA COMPARATIVA DE LAS FASES DEL

CICLO DE VIDA DE

DESARROLLO DEL SOFTWARE .............................................................. 46

TABLA 27. CARACTERSTICAS DE LAS METODOLOGAS. ........................................ 47

TABLA 28. TRATAMIENTO

DE LOS

REQUISITOS

POR PARTE DE LA

METODOLOGA

PROPUESTA. ........................................................................................ 49
TABLA 29. CALIFICACIN

AL

TRATAMIENTO

DE

REQUISITOS

POR PARTE DE LAS

METODOLOGAS. .................................................................................. 50

TABLA 30. FASES DEL CICLO DE VIDA DE DESARROLLO DE SOFTWARE Y ATRIBUTOS

DE LAS METODOLOGAS EN ESTUDIO Y LA PROPUESTA ....................... 52

TABLA 31. FASES DEL CICLO DE VIDA DE DESARROLLO DE SOFTWARE POR PARTE DE
LAS METODOLOGAS ESTUDIADAS Y LA PROPUESTA METODOLGICA. 53

TABLA 32. ACTIVIDADES,

TCNICAS Y PRODUCTOS DE CADA UNA DE LAS FASES Y

SUBFASES DE MEDWCU. .................................................................... 54

TABLA 33. TCNICAS DE EVALUACIN DE USABILIDAD EN LAS DIFERENTES FASES DE

MEDWCU. ......................................................................................... 55
TABLA 34. CARACTERSTICAS

DE LAS

METODOLOGAS

ESTUDIADAS Y DE LA

PROPUESTA METODOLGICA. ............................................................. 56

TABLA 35. IDENTIFICACIN DEL PROBLEMA DE LOS DESPACHOS JURDICOS. ......... 71
TABLA 36. CARACTERSTICAS DEL SISTEMA. ......................................................... 71
TABLA 37. CRONOGRAMA DE ACTIVIDADES DEL DESARROLLO DEL SISTEMA. ....... 74
TABLA 38. EQUIPOS DE CMPUTO DEL DESPACHO PEACE JURDICA. ...................... 76
TABLA 39. RESUMEN DE CAPACIDADES DEL SISTEMA ........................................... 77
TABLA 40. MECANISMOS DE CONFIABILIDAD DEL SISTEMA. .................................. 78
TABLA 41. FACTORES QUE DETERMINAN LA FACILIDAD DE USO DEL SISTEMA. ...... 78
TABLA 42. REQUISITOS FUNCIONALES. .................................................................. 82
TABLA 43. ACTORES DEL SISTEMA ........................................................................ 84
TABLA 44. MODELO DE CASOS DE USO DEL SISTEMA. ............................................ 85

XVI

TABLA 45. DESCRIPCIN DE LOS COMPONENTES DE LA CAPA CONTROLLER. ........ 95

TABLA 46. OPERACIONALIZACIN DE LAS VARIABLES. ........................................ 104
TABLA 47. TABLA RESUMEN................................................................................ 107
TABLA 48. MATRIZ DE FRECUENCIAS ESPERADAS. ............................................... 108
TABLA 49. MATRIZ CON LOS VALORES ESTADSTICOS DE PRUEBA DE CHI CUADRADO.
.......................................................................................................... 108
TABLA 50. ANLISIS

DEL TRATAMIENTO DE REQUISITOS POR PARTE DE LAS

METODOLOGAS EORM, WSDM, SOHDM Y OOHDM. .................. 112

TABLA 51. RESULTADO COMPARATIVO DE LAS METODOLOGAS SEGN LOS CICLO DE

VIDA DE DESARROLLO DEL SOFTWARE. ............................................. 113

TABLA 52. RESULTADO

COMPARATIVO DE LAS METODOLOGAS SEGN LAS

CARACTERSTICAS DE LAS METODOLOGAS. ...................................... 114

TABLA 53.RESULTADO COMPARATIVO

LA

SEGN EL TRATAMIENTO DE REQUISITOS DE

PROPUESTA METODOLGICA MEDWCU

FRENTE A LAS DEMS

METODOLOGAS EN ESTUDIO............................................................. 115

TABLA 54. RESULTADO

COMPARATIVO SEGN LAS FASES DEL

DESARROLLO

DE

SOFTWARE

CICLO

POR PARTE DE LAS

DE

VIDA

DE

METODOLOGAS

ESTUDIADAS Y LA PROPUESTA METODOLGICA MEDWCU. ............ 116

TABLA 55. RESULTADO

COMPARATIVO SEGN LAS CARACTERSTICAS DE LAS

METODOLOGAS

ESTUDIADAS Y DE LA

PROPUESTA METODOLGICA

MEDWCU. ....................................................................................... 117

XVII

RESUMEN
En la actualidad el desarrollo de Sistemas de Informacin conlleva el
empleo de una gran cantidad de recursos, y la necesidad de actualizar estas
aplicaciones tanto en diseo como en contenido conllevan al empleo de un nuevo
proceso de desarrollo, en este sentido la metodologa es uno de los componentes
necesarios de todo diseo.
Al no disponer de una metodologa adecuada para el diseo de sistemas de
informacin independientemente de su entorno, el desarrollador no realiza su
trabajo de forma eficiente, esto provoca la insatisfaccin del usuario el mismo que
demanda una alta calidad.
El conjunto de procedimientos para la elaboracin de una metodologa debe estar
articulado lgica y tericamente con los objetivos de la investigacin. Si bien existe
una infinidad de libros de metodologas generales, no existe una metodologa
especfica para el anlisis, diseo, desarrollo e implementacin de sistemas web
diseados y centrados en los usuarios cuya finalidad sea la de representar a la
organizacin y sus objetivos, minimizar los problemas que pudiesen encontrarse y
de esta forma apoyar sus procesos.
Es ah donde surge la necesidad de proponer una metodologa diseada y centrada
en los usuarios, esta metodologa debe representar los objetivos de la organizacin,
adems debe ser independiente de la tecnologa de desarrollo y adaptarse a los
constantes cambios de la institucin.
Esta propuesta nace del Estudio Comparativo de las Metodologas OOHDM,
EORM, WSDM y SOHDM que segn Mara Jos Escalona, son las metodologas
que mejor se adaptan al desarrollo web centrado en los usuarios; esta propuesta
consta de las siguientes fases:
1. Planificacin
2. Anlisis
3. Diseo

XVIII

4. Construccin
5. Implementacin
Estas fases estn basadas en la metodologa de desarrollo de software (mtodo de
cascada) definida por Ingeniera del Software (Roger Pressman), y cada una de stas
fases son consideradas como mini-proyectos que tienen sus propios objetivos y
metas, donde el final de cada una de ellas es el punto de partida de la siguiente.
Como se seala, esta investigacin es solo una propuesta metodolgica cuya
finalidad es servir de referencia para que los desarrolladores web den la respectiva
importancia a al rol que cumplen los usuarios en los procesos de desarrollo e
implementacin de sistemas de informacin web.
El caso aplicativo de esta investigacin es un Sistema de Gestin Jurdica SIGEJ,
que surge debido a la importancia que tiene la informacin que es manejada dentro
de los estudios jurdicos y al afn de estar siempre al tanto de la tecnologa que
puede ser implementada para mejorar la atencin y servicio a los clientes, esto
ayudar en el trabajo diario, optimizar y simplificar la gestin de expedientes, as
como todas las tareas que se realizan, entre estas se tienen: el mantenimiento de los
expedientes jurdicos, el manejo de una agenda la cual implica la creacin de
alarmas pertinentes a los vencimientos de alguno de los documentos que son
necesarios para el correcto seguimiento de una causa.

XIX

SUMARY
At present the development of Information systems carries the employment of a great
quantity of resources, and the need to update these applications both in design and in
content they carry to the employment of a new process of development, in this respect
the methodology is one of the necessary components of any design.
On not having had a methodology adapted for the design of information systems
independently his environment, the developer does not realize his work of efficient
form, provoking the dissatisfaction of the user the same one that demands a high
quality.
The set of procedures for the production of a methodology must be articulated logic
and theoretically with the aims of the investigation. Though there exists an infinity of
books of general methodologies, a specific methodology does not exist for the analysis,
design, development and implementation of web systems designed and centered on the
users whose purpose is it of representing to the organization and his aims, minimizing
the problems that they could find and of this form to support his processes.
It is there where there arises the need to propose a methodology designed and centered
on the users, this methodology must represent the aims of the organization, in addition
it must be independent from the technology of development and to adapt to the constant
changes of the institution.
This offer is born of the Comparative Study of the Methodologies OOHDM, EORM,
WSDM and SOHDM that according to Mara Jose Escalona, are the methodologies
that better they adapt to the web development centred on the users; this offer consists
of the following phases:
1. Planning
2. Analysis
3. Design
4. Construction
5. Implementation

XX

These phases are based on the methodology of development of software (method of

waterfall) defined by Engineering of the Software (Roger Pressman), and each of these
phases are considered to be mini-projects that have his own aims and goals, where the
end of each one of them is the point of item of the following one. As it distinguishes
itself, this investigation is alone a methodological offer which purpose is to use as
reference in order that the web developers give the respective importance to the role
that the users fulfill in the processes of development and implementation of web
information systems.
The applicative case of this investigation is a System of Juridical Management SIGEJ,
which arises due to the importance that has the information that is handled inside the
law offices and to the zeal to be always to so much of the technology that can be
implemented to improve the attention and service to the clients, this will help in the
daily work optimizing and simplifying the management of processes, as well as all the
tasks that are realized, between these they are had: the maintenance of the juridical
processes, the managing of an agenda which implies the creation of pertinent alarms to
the maturities of someone of the documents that are necessary for the correct followup of a reason.

XXI

INTRODUCCIN
El desarrollo de sistemas de informacin est relacionado principalmente
con las siguientes reas de conocimiento como son: la ingeniera de software que
sugiere herramientas, tecnologas y metodologas para dar solucin a diversos tipos
de problemas; los sistemas de base de datos que guan en el anlisis, diseo,
implementacin y gestin de una base de datos; y, la ingeniera web que sugiere
principios y herramientas para construccin de aplicaciones web de calidad y
finalmente una metodologa donde el usuario desempee un rol importante.
La presente investigacin se compone de x captulos, pues as el Captulo I inicia
con un marco referencial del proyecto, seguido de los objetivos y la debida
justificacin. En el Captulo II se sustenta tericamente el presente trabajo adems
se realiza un estudio comparativo de las Metodologas ms usadas para la
implementacin de sistemas de informacin para la web como son la OOHDM,
WSDM, EORM y SOHDM. ste captulo servir para fundamentar bases tericas
y cientficas para el Desarrollo de una Propuesta Metodolgica para el diseo web
centrado en el usuario.
El Captulo III trata del desarrollo de la propuesta metodolgica para el diseo web
centrado en el usuario MeDWCU, en la que se regula el cumplimiento de normas,
funcionalidad, accesibilidad, adems, se realiza el estudio de las plataformas
necesarias para el desarrollo con el fin de seleccionar la ms adecuada. Esta
propuesta hereda las caractersticas ms relevantes de las metodologas OOHDM,
WSDM, EORM y SOHDM que fueron seleccionadas del estudio comparativo
realizado en el Captulo II, adicionalmente a la MeDWCU se le aadieron algunas
caractersticas que segn Escalona (2002) y Lamas (2009) son propias del diseo
web centrado en el usuario, estas caractersticas son: Accesibilidad, Usabilidad,
Tratamiento de la Informacin y Diseo de Interfaz de usuario.
En el Captulo IV se aplica la MeDWCU en la implementacin de sistemas web
centrado en los usuarios donde el caso prctico un Sistema de Informacin para la
Gestin Jurdica. En el mbito de la gestin y control de despachos jurdicos se
presentan diversos problemas como son: el seguimiento no adecuado a los procesos

y trmites, administracin no eficiente de los actividades relacionadas con los

procesos, recuperacin y tratamiento no eficiente de la informacin generada en los
despachos, etc. En la mayora de los despachos jurdicos el aumento del nmero de
clientes ha ocasionado que se tenga que gestionar y controlar gran cantidad de
informacin, lo cual ha trado como consecuencia que los casos que administra el
despecho no se gestionen de una forma eficiente, ni exista un control alguno de las
diversas etapas que pasa un caso, ni se pueda dar seguimiento a las diversas
actividades que se tienen que cumplir como: diligencias, trminos e instrucciones
fiscales. Adems, el tiempo dedicado al inventario de los casos es excesivo.
En el Captulo V se definen los mtodos, mecanismos, estrategias y/o
procedimientos a seguirse en la investigacin. En el Captulo VI se analiza los
resultados del estudio comparativo y los beneficios de la misma, se discute y
comprueba la hiptesis; adems en el Captulo VII se finaliza con las conclusiones
y recomendaciones del proyecto de investigacin. En el Captulo VIII se realiza la
propuesta enfocada al despliegue del software en su entorno real.

CAPITULO I
MARCO REFERENCIAL

1.1.

TTULO DEL PROYECTO

PROPUESTA METODOLOGA PARA LA IMPLEMENTACIN DE

SISTEMAS DE INFORMACIN WEB DISEADOS Y CENTRADOS EN LOS

USUARIOS. CASO PRCTICO: SISTEMA PARA LA GESTIN JURDICA.
1.2.

PROBLEMATIZACIN

1.2.1.

IDENTIFICACIN Y DESCRIPCIN DEL PROBLEMA

En la actualidad el desarrollo de Sistemas de Informacin conlleva el

empleo de una gran cantidad de recursos, y la necesidad de actualizar estas

aplicaciones tanto en diseo como en contenido conllevan al empleo de un nuevo
proceso de desarrollo, en este sentido la metodologa es uno de los componentes
necesarios de todo diseo.
Al no disponer de una metodologa adecuada para el diseo de sistemas de
informacin independientemente de su entorno, el desarrollador no realiza su
trabajo de forma eficiente, lo cual provoca la insatisfaccin del usuario el mismo
que demanda una alta calidad.
El conjunto de procedimientos para la elaboracin de una metodologa debe estar
articulado lgica y tericamente con los objetivos de la investigacin. Si bien existe
una infinidad de libros de metodologas generales, no existe una metodologa
especfica para el anlisis, diseo, desarrollo e implementacin de sistemas web
diseados y centrados en los usuarios cuya finalidad sea la de representar a la
organizacin y sus objetivos, minimizar los problemas que pudiesen encontrarse y
de esta forma apoyar sus procesos.

De este contexto, resulta necesario e importante analizar las metodologas ms

usadas en el diseo de sistemas web (OOHDM, EORM, SOHDM y WSDM) y
proponer una metodologa diseada y centrada en los usuarios. Al aplicar esta
metodologa se propone implementar un sistema para optimizar la gestin de
expedientes jurdicos.
1.2.2.

ANLISIS CRTICO
Los constantes cambios en la tecnologa hacen necesario disponer de una

adecuada metodologa para el desarrollo de sistemas de informacin, si bien es

cierto en la actualidad existen varias metodologas lo cual hace difcil escoger una
de stas y aplicarla en un proyecto de desarrollo, convirtindose en algo
desconcertante para los desarrolladores.
Por otra parte tanto los sistemas informticos aplicados tanto en gestin judicial
como jurdica deben ser integrales, parametrizables y adaptables a las necesidades
de cada tipo de procesos; este tipo de sistemas demandan una planificacin amplia,
que debe incluir los conceptos de relevamiento, anlisis, desarrollo, capacitacin,
implantacin, mantenimiento y soporte, lo cual resulta esencial para ello
contemplar los recursos necesarios para llevarlos a cabo (humano y financiero); es
aqu donde la metodologa a utilizar juega un papel importante y al no disponer de
una metodologa especfica para el desarrollo de este tipo de sistemas es importante
analizar de forma comparativa las ms utilizadas (OOHDM, EORM, SOHDM y
WSDM) y porteriormente en base a las caractersticas mas relevantes de cada una
de ellas proponer una nueva metodologa diseada y centrada en los usuarios que
se adapte al desarrollo de cualquier tipo de sistemas de informacin web, en esta
investigacin un sistema para la gestin gestin jurdica.
1.2.3.

PROGNOSIS
Al analizar de forma comparativa las metodologas del diseo de sistemas

web y proponer una metodologa diseada y centrada en los usuarios cuya finalidad
sea representar a la organizacin y sus objetivos as como minimizar los problemas
que pudiesen encontrarse y de esta forma apoyar sus procesos. sta metodologa

ser aplicable en la implementacin de cualquier sistema de informacin web

independientemente de las actividades se realicen, el caso aplicativo ser la
implementacin de un Sistema para la gestin jurdica.
Con la implementacin de un sistema web para la gestin jurdica se optimizarn
los flujos de trabajo y procesos documentales que se realizan diariamente de forma
manual en los despachos jurdicos.
1.2.4.

DELIMITACIN
El anlisis comparativo de las metodologas para el desarrollo de sistemas

de informacin se limitar al estudio de cuatro metodologas que estn enfocadas

al desarrollo en entornos web las mismas que se describen a continuacin:

OOHDM

EORM

SOHDM

WSDM

Posterior al anlisis se proceder a proponer una metodologa para el desarrollo de

sistemas web pensada y centrada en los usuarios que sea aplicable a la gestin
jurdica; sta propuesta metodolgica proveer de los conceptos necesarios para la
correcta implementacin de sistemas de informacin web en la cual los usuarios
desempean un rol fundamental.
1.2.5.

FORMULACIN DEL PROBLEMA

Cmo el desarrollo de una propuesta metodolgica para la

implementacin de sistemas de informacin web diseados y centrados en los

usuarios incidir en el desarrollo eficiente de sistemas informticos acorde a los
objetivos y procesos de la organizacin?
1.2.6.

HIPTESIS
El desarrollo de una propuesta metodolgica para la implementacin de

sistemas de informacin web diseado y centrado en los usuarios incidir en el

desarrollo eficiente de sistemas informticos acorde a los objetivos y procesos de

la organizacin.
1.2.7.

IDENTIFICACIN DE LAS VARIABLES

1.2.7.1. INDEPENDIENTE
Propuesta Metodolgica para la implementacin de sistemas de
informacin web diseados y centrados en los usuarios.
1.2.7.2. DEPENDIENTE
Desarrollo eficiente de sistemas informticos acorde a los objetivos y
procesos de la organizacin
1.3.

OBJETIVOS

1.3.1.

GENERAL
Desarrollar una propuesta metodolgica para la implementacin de

sistemas de informacin web diseados y centrados en los usuarios, aplicable en la

gestin jurdica.
1.3.2.

ESPECFICOS
Analizar las metodologas OOHDM, EORM, SOHDM y WSDM
utilizadas en el desarrollo de sistemas web.

Disear una propuesta metodolgica para la implementacin de sistemas

web diseados y centrados en los usuarios, tomando en cuanto las
caractersticas ms relevantes de las metodologas OOHDM, EORM,
SOHDM y WSDM.

Desarrollar e Implementar el sistema de gestin jurdica aplicando la

propuesta metodolgica MeDWCU.

1.4.

JUSTIFICACIN
La mayora de los mtodos y propuestas metodolgicas que existen para

desarrollar aplicaciones Web guan al grupo de desarrollo a travs de un conjunto

de fases y pasos predefinidos sin tomar en cuenta la situacin particular, como por
ejemplo: elementos del contexto de desarrollo, tipo de aplicacin, usuarios,
herramientas, tecnologa, experiencia de desarrollo, etc. de cada proyecto.
Por tal razn, se pretende proponer una nueva metodologa que se base en la
caracterizacin de cuatro metodologas (SOHDM, EORM, OOHDM, WSDM) con
el fin de determinar cul es su flexibilidad y su capacidad de adaptacin a
situaciones particulares o contextos de modelado dentro de un dominio de
aplicacin, que atienda los conceptos y principios de la ingeniera de mtodos e
ingeniera Web.
La metodologa propuesta est destinada a la elaboracin de sistemas de
informacin Web diseados y centrados en los usuarios y tiene como finalidad
representar a la organizacin y sus objetivos, minimizar los problemas que pudiesen
encontrarse y de esta forma apoyar sus procesos.

CAPITULO II
ESTUDIO COMPARATIVO DE METODOLOGAS PARA LA
IMPLEMENTACIN DE SISTEMAS DE INFORMACIN
WEB
Hoy en da el desarrollo de aplicacines web es muy diferente a la forma de como se
desarrollaban hace algunos aos atrs; el acelerado avance y crecimiento de las
TICs y la gran difusin de la Internet ha dado lugar al aparecimiento de nuevas
necesidades en el desarrollo de sistemas de informacin.
En este sentido de acuerdo con Escalona (2001) surgen nuevas definiciones acerca
de los sistemas de informacin dentro del mundo de la ingeniera del software tales
como: sistemas multimedia, sistemas hipermedia, aplicaciones web, sistemas de
informacin global, etc.
A continuacin se lleva a cabo el estudio de las metodologas web basadas y
centradas en los usuarios de mayor relevancia, como son: Metodologa OOHDM,
Metodologa SOHDM, Metodologa WSDM y la Metodologa EORM. Para lo cual
se realiza un amplio y completo estudio comparativo de todas las metodologas
mendionadas anteriormente posteriormente se presentan las bases y fundamentos
de la propuesta metodolgica en desarrollo.
2.1.

INTRODUCCION A LOS SISTEMAS DE INFORMACIN

Los sistemas de Informacin dan apoyo a las operaciones empresariales, la gestin

y la toma de decisiones, a su vez proporcionan a las personas la informacin que
necesitan mediante el uso de las tecnologas de la informacin. Las empresas, y en
general cualquier organizacin, los utilizan como un elemento estratgico con el
que innovar, competir y alcanzar sus objetivos en un entorno globalizado. Los
sistemas de informacin integran personas, procesos, datos y tecnologa, que van

ms all de los umbrales de la organizacin, para colaborar de formas ms eficientes

con proveedores, distribuidores y clientes.
Segn Brito (2009) el desarrollo de sistemas web involucra decisiones no triviales
de diseo e implementacin que inevitablemente influyen en todo el proceso de
desarrollo, lo cual afecta a la divisin de tareas. Los problemas involucrados, como
el diseo del modelo del dominio y la construccin de la interfaz de usuario, tienen
requerimientos disjuntos que deben ser tratados por separado.
El alcance de la aplicacin y el tipo de usuarios a los que estar dirigida son
consideraciones tan importantes como las tecnologas elegidas para realizar la
implementacin. As como las tecnologas pueden limitar la funcionalidad de la
aplicacin, decisiones de diseo equivocadas tambin pueden reducir su capacidad
de extensin y reusabilidad. Es por ello que el uso de una metodologa de diseo y
de tecnologas que se adapten naturalmente a sta, son de vital importancia para el
desarrollo de aplicaciones complejas.
En la actualidad existen tecnologas ampliamente usadas para el desarrollo de
aplicaciones web, pero muchas de ellas obligan al desarrollador a mezclar aspectos
conceptuales y de presentacin; la eleccin de tecnologas complejas demora el
proceso e incrementa los costos, pero en ocasiones permite adecuarse a
metodologas de diseo ms fcilmente. Tal es el caso de las tecnologas orientadas
a objetos, las cuales tienden a demorar el desarrollo en etapas tempranas. El tiempo
de desarrollo en la actualidad es crtico, tanto por razones de marketing como por
lmites en el presupuesto y los recursos. (Cowan & Lucena, 1995)
2.2.

SISTEMAS DE INFORMACIN

2.2.1. DEFINICIN DE UN SISTEMA DE INFORMACIN

Un Sistema de Informacin (SI) es un conjunto de componentes
interrelacionados para recolectar, manipular y diseminar datos e informacin y para
disponer de un mecanismo de retroalimentacin til en el cumplimiento de un
objetivo.

Figura 1. Sistema de Informacin.

Fuente: Laudon, Jane y Kenneth. Sistemas de informacin gerencial- Administracin de
la empresa digital. 2012

De forma cotidiana todos interactan con sistemas de informacin, para fines tanto
personales como profesionales; a menudo utilizamos cajeros automticos, los
empleados de las tiendas registran nuestras compras sirvindose de cdigos de
barras y escner.
Laudon & Laudon (2012) afirman que las principales compaas en la actualidad
gastan ms de 1000 millones de dlares al ao en tecnologa de informacin y en el
futuro depender an ms de los sistemas de informacin.

Figura 2. Inversin en capital de tecnologa de la informacin

Fuente: (Laudon & Laudon, Sistemas de informacin gerencial, 2012, p. 5)
Elaborado por: ngel Cudco

Andreu, Ricart, & Valor (1997) definen los sistemas de informacin como el
conjunto formal de procesos que, opera un conjunto de estructurado de datos

10

acuerdo con las necesidades de una empresa, recopila, elabora y distribuye la

informacin necesaria para la operacin de dicha empresa y para las actividades de
direccin de control correspondientes, apoyan al menos en parte, la toma de
decisiones necesarias para desempear las funciones y procesos de negocio de la
empresa de acuerdo con su estrategia.
Otra definicin de Sistema de Informacin dice Un sistema de informacin se
puede definir tcnicamente como un conjunto de componentes interrelacionados
que recolectan (o recuperan), procesan, almacenan y distribuyen informacin para
apoyar la toma de decisiones y el control en una organizacin. Adems de apoyar
la toma de decisiones, la coordinacin y el control, los sistemas de informacin
tambin pueden ayudar a los gerentes y trabajadores a analizar problemas,
visualizar asuntos complejos y crear productos nuevos. (Laudon & Laudon, 2012,
p. 15).
Los sistemas de informacin contienen informacin acerca de personas, lugares y
cosas importantes dentro de la organizacin o en el entorno que se desenvuelven.
Por informacin se entiende los datos que se han modelado en una forma
significativa y til para los seres humanos. En contraste, los datos son consecuencia
de los hechos en bruto y representan eventos que ocurren en las organizaciones o
en el entorno fsico antes de ser organizados y ordenados en una forma que las
personas puedan entender y utilizar.
Hay tres actividades en un sistema de informacin que produce la informacin que
las organizaciones necesitan para tomar decisiones, controlar operaciones, analizar
problemas y creas nuevos productos o servicios. Estas actividades son entrada,
procesamiento y salida.

La entrada captura o recolecta datos en bruto tanto al interior de la

organizacin como de su entorno externo.

El procesamiento convierte esta entrada de datos en una forma significativa.

La salida transfiere la informacin procesada a la gente que lo usar o a las

actividades para las que se utilizar.

11

Los sistemas de informacin tambin requieren retroalimentacin que es la salida

que se devuelve al personal adecuado de la organizacin para ayudarle a evaluar o
corregir la etapa de entrada.

Figura 3. Actividades de un Sistema de Informacin

Fuente: Ciborra, C. Labyrinths of Information, Oxford, Oxford University Press. 2002

2.2.2. COMPONENTES DE UN SISTEMA DE INFORMACIN

En un sentido amplio se puede considerar que un SI es un conjunto de
elementos que interactan para que la empresa pueda alcanzar sus objetivos
satisfactoriamente. Montero & Fernndez (2006) afirma que los componentes o
recursos de un SI son los siguientes:

Datos: En general se consideran datos tanto los estructurados como los no

estructurados, las imgenes, los sonidos, etc.

Aplicaciones: Se incluyen las aplicaciones manuales y las informticas.

Infraestructura: En infraestructura se incluyen las tecnologas y las

instalaciones (por ejemplo hardware, sistemas operativos, sistema de
gestin de base de datos, sistemas de red, multimedia y el medio en el que
se ubican) que permiten que se procesen las aplicaciones.

Personal: Los conocimientos que ha de tener el personal de los sistemas de

informacin para planificarlos, organizarlos, administrarlos y gestionarlos.

2.2.3.

CLASIFICACIN DE UN SISTEMA DE INFORMACIN

Montero & Fernndez (2006) proponen diversos criterios para la

clasificacin de los Sistemas de Informacin:

12

a) Por el grado de formalidad: Sistemas de Informacin Formales y los

Informales.
b) Por el nivel de automatizacin conseguido: En las organizaciones, pueden
existir sistemas que necesitan una alta participacin de los trabajadores poco
automatizadas (Por ejemplo, los sistemas para responder a preguntas
personalizadas a travs de un e-mail) -, mientras que otros sistemas son capaces
de trabajar sin la intervencin humana muy automatizadas (por ejemplo, las
centrales telefnicas totalmente automatizadas).
c) Por su relacin con la toma de decisiones: Una de las funciones que deben
cumplir los sistemas de informacin es colaborar en la toma de decisiones. En
funcin del lugar jerrquico en donde se tomen las decisiones, los sistemas de
informacin se podrn clasificar en estratgicos, de control u operativos.
d) Por la naturaleza de sus entradas y salidas: Un sistema de informacin
puede recibir informacin de diversas fuentes de informacin (personas,
empresas, otros sistemas de informacin, etc.) as como en distintos formatos
(a travs de un teclado, por la red, de un disquete, memoria USB, CD, DVD
etc.) del mismo modo, los Sistema de Informacin pueden proporcionar
informacin a travs de distintos formatos (impreso, por pantalla, en internet,
etc.).
e) Por el origen y el grado de personalizacin: En las empresas se pueden
encontrar Sistemas de Informacin que han sido diseados e implementados
slo para ellos, o tambin sistemas comprados que son utilizados por otras
empresas.
f) Por el valor que representan para las organizaciones: El sistema que
contiene la informacin de los usuarios suele tener una mayor importancia que
el sistema de informacin de presupuestos (ya que este es ms sencillo y se
puede hacer manualmente).
2.2.4. TIPOS DE SISTEMAS DE INFORMACIN
Laudon & Laudon (2012) plantean cuatro principales tipos de sistemas de
informacin que dan servicio a los diferentes niveles de la organizacin:

13

Los sistemas a Nivel Operativo apoyan a los gerentes operativos en el

seguimiento de las actividades y transacciones elementales de la organizacin
como ventas, ingresos, depsitos en efectivo, nmina, decisiones de crdito y
flujo de materiales en una fbrica.

Los sistemas a Nivel del Conocimiento apoyan a los trabajadores del

conocimiento y de datos de una organizacin. El propsito de estos sistemas es
ayudar a las empresas comerciales a integrar el nuevo conocimiento en los
negocios y ayudar a la organizacin a controlar el flujo del trabajo de oficina.

Los sistemas a Nivel Administrativo sirven a las actividades de supervisin,

control, toma de decisiones y administrativas de los gerentes de nivel medio.

Los sistemas a Nivel Estratgico ayudan a los directores a enfrentar y resolver

aspectos estratgicos y tendencias a largo plazo, tanto en la empresa como en
el entorno externo.

2.3.

INGENIERA WEB
Es el proceso utilizado para crear, implantar y mantener aplicaciones y

sistemas Web de alta calidad. Esta breve definicin nos lleva a abordar un aspecto
clave de cualquier proyecto como es determinar qu tipo de proceso es ms
adecuado en funcin de las caractersticas del mismo.
2.3.1. EL PROCESO DE INGENIERA WEB
Caractersticas como inmediatez y evolucin y crecimiento continuos, nos
llevan a un proceso incremental y evolutivo, que permite que el usuario se involucre
activamente, y facilite el desarrollo de productos que se ajustan mucho lo que ste
busca y necesita. (Olsina, 1999)
Pressman (2010) afirma: las actividades que formaran parte del marco de trabajo
incluiran las tareas abajo enumeradas. Dichas tareas seran aplicables a cualquier
aplicacin Web, independientemente del tamao y complejidad de la misma.
Las actividades que forman parte del proceso son:
Formulacin: identifica objetivos y establece el alcance de la primera entrega.

14

 Planificacin: genera la estimacin del coste general del proyecto, la

evaluacin de riesgos y el calendario del desarrollo y fechas de entrega.
Anlisis: especifica los requerimientos e identifica el contenido.
Modelizacin: se compone de dos secuencias paralelas de tareas:

Una consiste en el diseo y produccin del contenido que forma parte de

la aplicacin.

La otra, en el diseo de la arquitectura, navegacin e interfaz de usuario.

Es importante destacar la importancia del diseo de la interfaz.
Independientemente del valor del contenido y servicios prestados, una
buena interfaz mejora la percepcin que el usuario tiene de stos.

Generacin de pginas: integra el contenido, arquitectura, navegacin e

interfaz para crear esttica o dinmicamente el aspecto ms visible del sistema
de informacin web.
2.3.2. CONTROL Y GARANTA DE LA CALIDAD
Una de las tareas colaterales que forman parte del proceso es el Control y
Garanta de la Calidad (CGC). Todas las actividades CGC de la ingeniera software
tradicional como son: establecimiento y supervisin de estndares, revisiones
tcnicas formales, anlisis, seguimiento y registro de informes, etc, son igualmente
aplicables a la Ingeniera Web. (Olsina, 1999, p.95).
Sin embargo, en la Web toman especial relevancia para valorar la calidad aspectos
como:

Usabilidad,

Funcionabilidad,

Fiabilidad,

Seguridad,

Eficiencia

Mantenibilidad.
2.3.3. CONTROL DE LA CONFIGURACIN
Establecer mecanismos adecuados de control de la configuracin para la
Ingeniera Web es uno de los mayores desafos a los que esta nueva disciplina se
enfrenta. La Web tiene caractersticas nicas que demandan estrategias y
herramientas nuevas, existen cuatro aspectos importantes a tener en cuenta en el
desarrollo de tcticas de control de la configuracin para la Web (Olsina, 1999,
p.95):

15

Contenido: Resulta primordial considerar la dinamicidad con la que el

contenido se genera, es tarea compleja organizar racionalmente los objetos que
forman la configuracin y establecer mecanismos de control.

Personal: Cualquiera realiza cambios. Hay mucho personal no especializado

que no reconoce la importancia que tiene el control del cambio.

Escalabilidad: Es comn encontrar aplicaciones que de un da para otro crecen

considerablemente. Sin embargo, las tcnicas de control no escalan de forma
adecuada.

Poltica: Quin posee la informacin? Quin asume la responsabilidad y

coste de mantenerla?

2.3.4. LA GESTIN DEL PROCESO

Sametinger (1997) afirma que en un proceso tan rpido como es el proceso
de Ingeniera Web, donde los tiempos de desarrollo y los ciclos de vida de los
productos son tan cortos, merece la pena el esfuerzo requerido por la gestin? La
respuesta es que dada su complejidad es imprescindible.
Entre los aspectos que aaden dificultad a la gestin se destacan los siguientes:

Alto porcentaje de contratacin a terceros,

El desarrollo incluye una gran variedad de personal tcnico y no tcnico que

trabaja en paralelo,

El equipo de desarrollo debe dominar aspectos tan variopintos como, software

basado en componentes, redes, diseo de arquitectura y navegacin, diseo
grfico y de interfaces, lenguajes y estndares en Internet, test de aplicaciones
Web, etc, lo que hace que el proceso de bsqueda y contratacin de personal
sea arduo.

2.3.5. DIFERENCIA CON LA INGENIERA DE SOFTWARE

A modo de breve resumen Koch (2000) enumera las siguientes diferencias:

Confluencia de disciplinas: Sistemas de Informacin, Ingeniera Software y

Diseo Grfico que requiere equipos multidisciplinares y polivalentes.

16

Ciclos de vida y tiempo de desarrollo muy cortos - Cambio continuo:

Necesidad de soluciones que permitan flexibilidad y adaptacin conforme el
proyecto cambia.

Requisitos fuertes de Seguridad, Rendimiento y Usabilidad.

2.4.

METODOLOGA OOHDM (OBJECT ORIENTED HYPERMEDIA

DESIGN METHODOLOGY)

2.4.1.

INTRODUCCIN A OOHDM
Object Oriented Hypermedia Design Methodology (OOHDM, Mtodo de

Diseo Hipermedia Orientado a Objetos), es una metodologa ampliamente

aceptada para el desarrollo de aplicaciones de la web (Schwabe & Rossi, 1998). En
sus comienzos no contemplaba la fase de captura y definicin de requisitos, pero
actualmente propone el uso de User Interaction Diagrams (UIDs) definidos por
Vilain, Schwabe & Sieckenius (2000).
Las metodologas tradicionales de ingeniera de software, o las metodologas para
sistemas de desarrollo de informacin, no contienen una buena abstraccin capaz
de facilitar la tarea de especificar aplicaciones hipermedia. El tamao, la
complejidad y el nmero de aplicaciones crecen en forma acelerada en la
actualidad, por lo cual una metodologa de diseo sistemtica es necesaria para
disminuir la complejidad y admitir evolucin y reusabilidad. (Schwabe & Rossi,
1998)
Schwabe & Rossi (1998) aseguran que para producir aplicaciones en las cuales el
usuario pueda aprovechar el potencial del paradigma de la navegacin de sitios web,
mientras ejecuta transacciones sobre bases de informacin, es una tarea muy difcil
de lograr. En primer lugar, la navegacin posee algunos problemas. Una estructura
de navegacin robusta es una de las claves del xito en las aplicaciones hipermedia.
Si el usuario entiende dnde puede ir y cmo llegar al lugar deseado, es una buena
seal de que la aplicacin ha sido bien diseada.
Construir la interfaz de una aplicacin web es tambin una tarea compleja; Schwabe
& Rossi (1998) afirman que no slo se necesita especificar cules son los objetos

17

de la interfaz que deberan ser implementados, sino tambin la manera en la cual

estos objetos interactuarn con el resto de la aplicacin.
En hipermedia existen requerimientos que deben ser satisfechos en un entorno de
desarrollo unificado (framework). Por un lado, la navegacin y el comportamiento
funcional de la aplicacin deberan ser integrados. Por otro lado, durante el proceso
de diseo se debera poder desacoplar las decisiones de diseo relacionadas con la
estructura navegacional de la aplicacin, de aquellas relacionadas con el modelo
del dominio.
OOHDM propone el desarrollo de aplicaciones hipermedia a travs de un proceso
compuesto por cuatro etapas: diseo conceptual, diseo navegacional, diseo de
interfaces abstractas e implementacin.
2.4.2.

FASES DE LA METODOLOGA OOHDM

De acuerdo con Vilain, Schwabe & Sieckenius (2000), OOHDM como

tcnica de diseo de aplicaciones hipermedia, propone un conjunto de tareas que

segn pueden resultar costosas a corto plazo, pero a mediano y largo plazo reducen
notablemente los tiempos de desarrollo al tener como objetivo principal la
reusabilidad de diseo, y as simplificar el coste de evoluciones y mantenimiento.
Esta metodologa plantea el diseo de una aplicacin de este tipo a travs de cinco
fases que se desarrollan de un modo iterativo. Estas fases son:

Determinacin de Requerimientos.

Diseo Conceptual.

Diseo Navegacional.

Diseo de Interfaz Abstracta.

Implementacin.

2.4.2.1. Determinacin de Requerimientos

La herramienta en la cual se fundamenta esta fase son los diagramas de casos de
usos, los cuales son diseados por escenarios con la finalidad de obtener de manera
clara los requerimientos y acciones del sistema. Koch (2000) asegura que en este

18

punto es necesario identificar los actores y las tareas que ellos deben realizar,
posteriormente se determinan los escenarios para cada tarea y tipo de actor.
Los casos de uso que surgen a partir de aqu, sern luego representados mediante
los Diagramas de Interaccin de Usuario (UIDs), los cuales proveen de una
representacin grfica concisa de la interaccin entre el usuario y el sistema durante
la ejecucin de alguna tarea. Con este tipo de diagramas se capturan los requisitos
de la aplicacin de manera independiente de la implementacin.
Koch (2000) afirma que sta es una de las fases ms importantes, debido a que es
aqu donde se realiza la recogida de datos, para ello se deben de proporcionar las
respuestas a las siguientes interrogantes:
-

Cules son los tpicos principales que sern atendidos?

Cmo los tpicos estn relacionados entre s?

Qu categora de usuarios sern atendidos?

Cules son las tareas principales que sern abordadas?

Qu tareas corresponden a qu categora de usuarios?

Los recursos disponibles son competitivos con la informacin levantada?

Con las preguntas mencionadas anteriormente, se puede recaudar de cierta manera

las bases necesarias para la construccin de una aplicacin hypermedial exitosa, sin
embargo mientras mayor sea el nivel de profundidad de la recoleccin de datos,
mayor probabilidad de realizar una aplicacin adecuada a las necesidades de los
usuarios.
2.4.2.2. Diseo Conceptual.
Durante esta actividad se lleva a cabo, segn Koch (2000) un esquema
conceptual representado por los objetos del dominio, las relaciones y
colaboraciones existentes establecidas entre ellos.
El esquema de las clases consiste en un conjunto de clases conectadas por
relaciones. Los objetos son instancias de las clases. Las clases son usadas durante

19

el diseo navegacional para derivar nodos, y las relaciones que son usadas para
construir enlaces.
Como es de costumbre en modelos orientados a objetos, las clases son descritas por
un conjunto de atributos y mtodos (una vez implementado el comportamiento de
las clases), siendo an, organizadas en jerarquas (parte-de y es uno/a). (Schwabe
& Rossi, 1998). En la Figura 4 se observa un ejemplo prctico de cmo se
representa un diagrama de clases.

Figura 4. Modelo Conceptual para una Tienda de CD's

Fuente: Designing Personalized Web Applications;
http://www10.org/cdrom/papers/395/index.html

2.4.2.3. Diseo Navegacional.

La primera generacin de aplicaciones web fue pensada para realizar navegacin a
travs del espacio de informacin, mediante la ultilizacin de un modelo de datos
de hipermedia. (Schwabe, Pontes & Moura, 1999)
Schwabe, Pontes & Moura (1999) aseguran que el diseo de navegacin es

expresado en dos esquemas: el esquema de clases navegacionales y el esquema de

contextos navegacionales, los cuales se definen a continuacin:
* Esquema de Clases Navegacionales: establece las posibles vistas del
hiperdocumento a travs de unos tipos predefinidos de clases, llamadas
navegacionales como son los nodos, los enlaces y otras clases que representan
estructuras o formas alternativas de acceso a los nodos, como los ndices y los
recorridos guiados (Koch, 2000), ver Figura 5.

20

Figura 5. Esquema bsico navegacional para my.yahoo.com

Fuente:
Designing
Personalized
Web
http://www10.org/cdrom/papers/395/index.html

Applications

- Esquema de Contexto Navegacional: es el que permite la estructuracin del

hiperespacio de navegacin en sub-espacios para los que se indica la informacin
que ser mostrada al usuario y los enlaces que estarn disponibles cuando se accede
a un objeto (nodo) en un contexto determinado (Koch, 2000). Olsina (1999)
comenta con respecto a esta fase, es la fase en que diseamos la aplicacin
teniendo en cuenta los usuarios a los que va dirigida y los objetivos de la misma,
en pocas palabras, es la fase en que se plantea la manera de cmo ser la navegacin
del usuario en el hiperdocumento.
Las tareas que se ejecutan son las siguientes:
-

Se reorganiza la informacin representada en el modelo conceptual.

Se estructura la vista de navegacin sobre el modelo conceptual.

Una innovacin de OOHDM es que los objetos sobre los cuales navega el usuario
no son objetos conceptuales, sino otro tipo de objetos que se construyen a partir de
uno o ms objetos conceptuales, lo cual implica a su vez que el usuario navegue a
travs de enlaces, muchos de los cuales no se pueden derivarse directamente en
relaciones conceptuales.
Este modelo implementa un conjunto de datos predefinidos, Olsina (1999) describe
los siguientes:

Nodos: son contenedores de informacin, stos se definen como vistas

orientadas a objetos de las clases conceptuales. Los nodos se pueden definir al
combinar atributos de clases relacionadas en el esquema conceptual.

21

Enlaces: son los que identifican las relaciones implementadas en el esquema

conceptual. Las clases de los enlaces especifican sus atributos, comportamiento
y los objetos fuentes del mismo; estos representan las posibles formas de
comenzar la navegacin.

Estructuras de Acceso: Las estructuras de acceso actan como ndices o

diccionarios que permiten al usuario encontrar de forma rpida y eficiente la
informacin deseada. Los mens, los ndices o las guas de ruta son ejemplos
de estas estructuras.

Contexto Navegacional: Para disear bien una aplicacin hipermedia, hay que
prever los caminos que el usuario puede seguir, as es como nicamente se
podr evitar informacin redundante o que el usuario se pierda en la
navegacin. En OOHDM un contexto navegacional est compuesto por un
conjunto de nodos, de enlaces de clases de contexto y de otros contextos
navegacionales. Estos son introducidos desde clases de navegacin (enlaces,
nodos o estructuras de acceso), que pueden ser definidas por extensin o de
forma implcita.

Clase de Contexto: Es otra clase especial que sirve para complementar la

definicin de una clase de navegacin. Por ejemplo, sirve para indicar qu
informacin est accesible desde un enlace y desde dnde se puede llegar a l.

2.4.2.4. Diseo de Interfaz Abstracta.

Una vez que las estructuras navegacionales son definidas, se deben
especificar los aspectos de interfaz. Segn Vilain, Schwabe & Sieckenius (2000),
esto significa definir la forma en la cual los objetos navegacionales pueden
aparecer, cmo los objetos de interfaz activarn la navegacin y el resto de la
funcionalidad de la aplicacin.
El modelo de interfaz ADVs (Vista de Datos Abstractos), especifica la organizacin
y comportamiento de la interfaz, pero la apariencia fsica real o de los atributos, y
la disposicin de las propiedades de las ADVs, en la pantalla real son hechas en la
fase de implementacin. En la Figura 6 se puede observar un ejemplo de diagramas
de configuracin, y en la Figura 7 se pueden apreciar el diagrama de eventos que
ocurre sobre el mismo.

22

Figura 6. Diagrama de Configuracin para los nodos ADV.

Fuente: OOHDM's Design Process, disponible en:
http://www-di.inf.pucrio.br/schwabe/HT96WWW/section3.html

Figura 7. Diagrama de Configuracin para los nodos ADV.

Fuente: OOHDM's Design Process, disponible en:
http://www-di.inf.pucrio.br/schwabe/HT96WWW/section3.html

2.4.2.5. Implementacin
En esta fase, el diseador debe implementar el diseo, hasta ahora todos
los modelos fueron construidos en forma independiente de la plataforma de
implementacin; en esta fase es tenido en cuenta el entorno particular en el cual se
va a correr la aplicacin. (Olsina, 1999)
Al llegar a esta fase, el primer paso que debe realizar el diseador es definir los
tems de informacin que son parte del dominio del problema. Debe identificar

23

tambin, cmo son organizados los tems de acuerdo con el perfil del usuario y su
tarea; decidir qu interfaz debera ver y cmo debera comportarse.
A fin de implementar todo en un entorno web, el diseador debe decidir adems
qu informacin debe ser almacenada. Es de especial importancia el hacer notar
que hoy en da, hay muchos y varios ambientes de implementacin, con
caractersticas distintas. Es claro, por ejemplo, que no se puede usar el mismo
conjunto de lneas de accin en la traduccin de un proyecto OOHDM para un
documento HTML que para un programa en Macromedia Flash. (Silva & Mercerat,
2001)
2.4.3.

VENTAJAS DE OOHDM

De acuerdo con Silva & Mercerat (2001), OOHDM como metodologa de

desarrollo de aplicaciones de hipermedia, proporciona ventajas como:
-

La recuperacin de la informacin puede realizarse sin problemas.

Se pueden crear enlaces entre nodos cualesquiera.

La modularidad y la consistencia se potencian.

Marco idneo para la autora en colaboracin.

Soporte a diferentes modos de acceso a la informacin.

En la actualidad, el desarrollo de software a travs del uso de patrones de proyecto,

se encuentra en crecimiento segn Gamma, Helm, Johnson y Vlissides (1995), sin
embargo, su potencial se encuentra inexplorado en el campo de hipermedios,
especialmente a la hora de describir las arquitecturas para la navegacin e interface
en aplicaciones de hipermedia.
Schwabe & Rossi (1998) afirman que OOHDM se torna diferente y superior a otras
metodologas de desarrollo de aplicaciones de hipermedia al ofrecer la ventaja de
patrones de proyecto poderosos como primitivas para la construccin del modelo
navegacional de una aplicacin hipermedia.
Puede decirse con base en todas las ventajas antes mencionadas que OOHDM toma
en cuenta las crecientes necesidades de analistas y programadores de aplicaciones

24

hipermedia, y se presenta como una tcnica ideal de desarrollo para la produccin

de aplicaciones evolutivas de alta calidad.
2.5.

METODOLOGA SOHDM

Figura 8. Metodologa SOHDM.

Es un mtodo que desarrolla Diseo en Panoramas (escenario) Orientada a Objetos

en Hipermedia (Scenario - based Object-oriented Hypermedia Design
Methodology). Presenta la necesidad de disponer de un proceso que permita
capturar las necesidades del sistema, para lo cual se propone el uso de escenarios.
(Lee, Lee & Yoo, 1998).
Es una de las primeras propuestas para la web y brinda ms importancia a la tarea
de tratamiento de requisitos. Se caracteriza principalmente porque su ciclo de vida
comienza con la aplicacin de los escenarios como tcnica de elicitacin y
definicin de requisitos.

El proceso de definicin de requisitos parte de la

realizacin de un diagrama de contexto tal y como se propone en los diagramas de

flujos de datos (DFD) de Yourdon (1989).
La lista de eventos es una tabla que indica en qu eventos puede participar cada
entidad; por cada evento diferente, SOHDM propone elaborar un escenario. (Lee,
Lee & Yoo, 1998). Estos son representados grficamente mediante los
denominados SACs (Scenario Activity Chart).
Cada escenario describe el proceso de interaccin entre el usuario y el sistema
cuando se produce un evento determinado, el mismo que define el flujo de
actividades, los objetos involucrados y las transacciones realizadas. SOHDM

25

propone un proceso para conseguir a partir de estos escenarios el modelo conceptual

del sistema, que es representado mediante un diagrama de clases.
2.5.1.

Fases de la Metodologa SOHDM

Lee, Lee & Yoo (1998) aseguran que sta metodologa tiene semejanzas

con, OOHDM y EORM donde se diferencian en el uso de panoramas, que describen

las actividades en los acontecimientos y primitivas de flujos de actividades. Los
panoramas se definen en la fase de anlisis y se utilizan para modelar los objetos.
Esta metodologa, de acuerdo con Lee, Lee & Yoo (1998), dispone de seis fases:
anlisis del dominio, modelado del objeto, diseo de la visin, diseo de la
navegacin, diseo de la puesta en prctica y construccin. A continuacin se
detallan sus fases:
a)

Fase de Anlisis, se realizar un estudio de las necesidades de la aplicacin, del

entorno de trabajo y de los actores. La finalidad principal de esta fase es
conseguir los escenarios que representen las actividades que se pueden llevar a
cabo en el sistema

b) Fase de Modelado de Objetos, se desarrolla un diagrama de clases que

representa la estructura conceptual del sistema
c)

Fase de Diseo de Vistas, se reorganizan los objetos en unidades

navegacionales que representan una vista de los objetos del sistema

d) Fase de Diseo Navegacional, se enriquecen dichas vistas al definir los

enlaces e hiperenlaces que existen en el sistema
e)

Fase de Diseo de la Implementacin, se disean las pginas, la interfaz y la

base de datos del sistema

f)

Fase de Construccin, se realiza la construccin de la base de datos del

sistema. la que se implementa la aplicacin

2.6. METODOLOGA WSDM

Es un Mtodo de Diseo para Sitios Web (Web Site Design Method), donde
hay un acercamiento al usuario que define los objetos de informacin basado en sus

26

requisitos de informacin para el uso de la Web. WSDM se describe en trminos

de componentes y enlaces. (Troyler & Leune, 1997, p.90).
Distingue tres tipos de componentes de navegacin. Cada navegacin consta de tres
capas: contexto, la navegacin y capas de informacin.

El contexto es la capa superior de la navegacin y a su vez la de informacin

es la capa inferior.

La capa de navegacin conecta la capa de contexto y la capa de informacin.

Para acceder a la informacin intermedia por componentes y los vnculos

que se crean, tales como los ndices.

En este mtodo se definen una aplicacin Web a partir de los diferentes grupos de
usuarios que vaya a reconocer el sistema.
2.6.1.

FASES DE LA METODOLOGA WSDM

Troyler & Leune (1997) propone las siguientes fases:

-

Modelo de usuario

Diseo conceptual

Anlisis de Requisitos

Diseo de la implementacin

Realizacin de la Implementacin.

El tratamiento de requisitos se lleva a cabo en la etapa inicial, donde, en primer

lugar, se identifican y clasifican los usuarios que van a hacer uso de la aplicacin
Web
2.6.1.1. Fase de Modelo de Usuario
Cowan & Lucena (1995) aseguran que en esta fase se intenta detectar los perfiles
de usuarios para los cuales se construye la aplicacin; es decir en esta fase es
necesario determinar: Quin es el pblico objetivo? Cmo ser la visin de su
sitio Web? Cules son los objetivos de marketing de la empresa? Cules son los
objetivos de su sitio web? Qu mensaje tiene su compaa quiere transmitir? Cul
es el campo del negocio? Cules son los estndares de la industria?
27

Una vez que se tiene una comprensin del negocio y objetivos de la empresa, el
proceso de planificacin estratgica crear un plan inicial del sistema web. Se
divide en dos sub fases siguientes:
a) Clasificacin de usuarios: Se deben identificar y clasificar a los usuarios
que van a hacer uso del sistema.
Para ello, WSDM propone el estudio del entorno de la organizacin donde
se vaya a implantar el sistema y los procesos que se vayan a generar, estas
a su vez describen las relaciones entre usuarios y actividades que realizan
estos usuarios. Para la representacin grfica de estas relaciones WSDM
propone una especie de mapas de conceptos de roles y actividades. (Cowan
& Lucena, 1995)
b) Descripcin de los grupos de usuarios: Se describen con ms detalles los
grupos de usuarios detectados en la etapa anterior. (Cowan & Lucena,
1995).
Para ello, se debe elaborar un diccionario de datos, en principio con formato
libre, en el que indican los requisitos de almacenamiento de informacin,
requisitos funcionales y de seguridad para cada grupo de usuarios. (Cowan
& Lucena, 1995).
2.6.1.2. Fase de Diseo Conceptual
De acuerdo con Cowan & Lucena (1995), esta fase consta de los siguientes criterios:

Modelado de Objetos

Diagrama de Navegabilidad

Diagrama Entidad-Relacin

Se desarrolla el modelado conceptual durante este modelado se realizan dos tareas

a la vez: el modelado de objetos, y el diseo de la navegacin. Pocas
recomendaciones se dan en esta etapa, tales como la utilizacin de pginas de
ndice, derecho de informacin dividida en diversos tamaos, el uso de contexto y
de la informacin y el uso de seales de navegacin.

28

La navegacin modelo consiste en una serie de vas de navegacin, uno para cada
perspectiva que exprese la forma en que los usuarios de una perspectiva particular
puede navegar a travs de la informacin disponible. WSDM describe en trminos
de los componentes y enlaces.
2.6.1.3. Anlisis de Requisitos
a) Patrn de Diseo: Los patrones de diseo son la base para la bsqueda de
soluciones a problemas comunes en el desarrollo de software y otros mbitos
referentes al diseo de interaccin o interfaces. (Gamma, Helm, Johnson & Vlissides,
1995)
Gamma, Helm, Johnson & Vlissides (1995) afirman que un patrn de diseo resulta

ser una solucin a un problema de diseo, para que una solucin sea considerada
un patrn debe poseer ciertas caractersticas. Una de ellas es que debe haber
comprobado su efectividad al resolver problemas similares en ocasiones anteriores.
Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes
problemas de diseo en distintas circunstancias. WSDM por defecto usa como
patrn de diseo al patrn MVC (Modelo, Vista y Controlador).

Figura 9. Anlisis de requisitos de la Metodologa WSDM.

Fuente: Gamma, Helm, Johnson & Vlissides (1995)

b) Base de Datos: posterior al seleccionar el patrn de diseo se procede a definir

una base de datos que contenga el modelo de datos (datos de los usuarios, permisos,
etiquetas y pginas) del proyecto en desarrollo.

29

2.6.1.4. Fase de diseo de implementacin

Se modela la interfaz para cada rol de usuario, Ahora que se tiene una versin
definitiva del plan se puedan comenzar con la construccin del sitio web. Durante
esta fase, se efectuar la construccin de la arquitectura de navegacin del sitio.
-

Creacin de alta funcionalidad, que tiene como fin a la animacin, pues har
que se propague por todas las pginas de los medios necesarios con los
grficos y el texto.

El cdigo de los programas tcnicos y la funcionalidad del sitio.

La creacin y diseo de la pgina principal disponible.

2.6.1.5. Fase de la Realizacin de la Implementacin

Se codifican todos estos aspectos en el lenguaje concreto que se haya seleccionado.
WSDM es tambin una propuesta viva que est adaptndose a nuevos requisitos.
(Burbeck, 1992)
Burbeck (1992) propone preparar el lanzamiento de la web una vez que se tenga en
cuenta Cundo entraran a nuestra web? Antes de la puesta en marcha se debe
garantizar lo siguiente:
-

Continuas y exhaustivas pruebas que garantizar un impecable final del sitio

web.

Trabajo directamente con la empresa para garantizar la tcnica y la

usabilidad se cumplen las normas.

Velar el final del proyecto con la finalidad de ver si se han cumplido los
requisitos planteados.

Crear una fecha de lanzamiento y el plan.

2.7. METODOLOGA EORM

2.7.1. INTRODUCCIN A LA METODOLOGA EORM
Es una Metodologa de Relacin entre Objeto (Enhanced Object Relationship
Methodology), es definido por un proceso iterativo que se concentra en el modelado

30

orientado a objetos por la representacin de relaciones entre los objetos

(acoplamientos) como objetos, es por ello que fue una de las primeras propuestas
para Web centrada en el paradigma de la orientacin a objetos. (Lange, 1994)
Para automatizar la aplicacin de la metodologa EORM, su autor ha desarrollado,
en los laboratorios de investigacin de IBM, una herramienta denominada
ODMTool que, junto a un generador comercial de Interfaces Grficas de Usuario
denominado ONTOS Studio y un Sistema de Gestin de Base de Datos Orientado
a Objetos (SGBDOO), permite el diseo interactivo de esquemas EORM y la
generacin de cdigo fuente, inicialmente en C++, de las clases incluidas en estos
esquemas. El SGBDOO ofrece un repositorio de objetos que permite la
comparticin de la informacin de los esquemas entre las herramientas (ODMTool,
ONTOS Studio) y las aplicaciones hipermediales desarrolladas. (Lange, 1994)
2.7.2.

FASES DE LA METODOLOGA EORM

2.7.2.1. FASE DE ANLISIS

De acuerdo con Rumbaugh (1996), en esta fase trata de orientar a objetos
al sistema, sin considerar los aspectos hipermediales del mismo, obtenindose para
ello un Modelo de Objetos con la misma notacin utilizada en OMT, que refleje la
estructura de la informacin (mediante clases de objetos con atributos y relaciones
entre las clases) y el comportamiento del sistema (a travs de los mtodos asociados
a las clases de objetos).

Figura 10. Ejemplo de Modelo Orientado a Objetos Fase de Anlisis.

Fuente: Rumbaugh. 1996. Modelado y Diseo Orientado a Objetos. Prentice-Hall

31

2.7.2.2. FASE DE DISEO

Rumbaugh (1996) afirma que en esta fase se procede a modificar el modelo
de objetos obtenido durante el anlisis se aade la semntica apropiada a las
relaciones entre clases de objetos para convertirlas en enlaces hipermedia, donde
finalmente se obtiene un modelo enriquecido, que su autor denomina EORM
(Enhanced Object-Relationship Model), en el que se refleje tanto la estructura de la
informacin como las posibilidades de navegacin ofrecidas por el sistema sobre
dicha estructura, para lo cual existir un repositorio o librera de clases de enlaces,
donde se especifican las posibles operaciones asociadas a cada enlace de un
hiperdocumento, que sern de tipo crear, eliminar, atravesar, siguiente, previo etc.,
as como sus posibles atributos (fecha de creacin del enlace, estilo de presentacin
en pantalla, restricciones de acceso, etc.)

Figura 11. Ejemplo de Modelo Orientado a Objetos Fase de diseo.

Fuente: Rumbaugh. 1996. Modelado y Diseo Orientado a Objetos. Prentice-Hall

2.7.2.3. FASE DE CONSTRUCCIN

Segn Rumbaugh (1996), en esta fase se transforman los esquemas en
cdigo y guardados en una Base de Datos Orientada a Objetos, y en elaborar
formularios de consulta de las clases con la ayuda de un editor grfico de interfaces.
Se genera el cdigo fuente (por ejemplo en C#) correspondiente a cada clase y se
prepara la Interface Grfica de Usuario.

32

2.7.3.

VENTAJAS DE LA METODOLOGA EORM

En base al estudio realizado en este apartado se concluye en que sta metodologa

tiene las siguientes ventajas:

Encajamiento de relaciones semnticas en construcciones extensibles, las

cuales pueden participar en otras relaciones y a su vez pueden ser parte de
bibliotecas reutilizables.

EORM distingue dos tipos de relaciones orientadas a objetos: Relaciones de

generalizacin y relaciones definidas por el usuario. Mientras que los
primeros se concentran como en la semntica asociada entre ellas, los
segundos confan totalmente en la especificacin del usuario.

2.8.

ESTUDIO COMPARATIVO DE METODOLOGAS PARA EL

DISEO WEB
Una vez enunciadas las propuestas, se presenta en este apartado una serie de

estudios comparativos de las mismas. Estas comparaciones sirven para analizar el

grado de adecuacin de estas metodologas al momento de implementar sistemas
de informacin Web diseados y centrados en los usuarios cuya finalidad sea la de
representar a la organizacin y sus objetivos y as minimizar los problemas que
pudiesen encontrarse y de esta forma apoyar sus procesos.
Mara Jos Escalona Cuaresma (libro: Metodologas para el desarrollo de sistemas
de informacin global) para realizar la comparacin de metodologas y proponer
una nueva metodologa toma en cuenta los siguientes parmetros:
-

Requisitos tratados

Ciclo de vida de desarrollo del software

Mecanismos usados por las metodologas

Caractersticas de las metodologas

Para realizar el estudio comparativo se utilizara la siguiente valoracin.

Tablas con valores de S y No.

33

Si, tendr el valor de 1

No, tendr el valor de 0

Al final se analizarn los valores de Si o No de acuerdo a la siguiente tabla:

Tabla 1. Valoracin para las Metodologas.
VALOR
CALIFICACIN ABREVIATURA
PORCENTAJE
ASIGNADO
No Existe
NE
0
0,0%
Malo
M
1
20%
Regular
R
2
40%
Bueno
B
3
60%
Muy Bueno
MB
4
80%
Excelente
E
5
100%
Elaborado por: Angel Cudco

2.8.1.

Requisitos Tratados
En base a la clasificacin y especificacin de requisitos (Escalona, 2002),

la primera comparativa que se realiza de las propuestas estudiadas consiste en

determinar qu tipos de requisitos contempla cada propuesta.
Los requisitos a considerarse son los siguientes:
a) Requisitos de datos, tambin denominados requisitos de contenido, requisitos
conceptuales o requisitos de almacenamiento de informacin. stos requisitos
responden a la pregunta de qu informacin debe almacenar y administrar el
sistema.
b) Requisitos de interfaz (al usuario), tambin llamados en algunas propuestas
requisitos de interaccin o de usuario. Responden a la pregunta de cmo va a
interactuar el usuario con el sistema.
c)

Requisitos navegacionales, recogen las necesidades de navegacin del

usuario.

d) Requisitos de personalizacin, describen cmo debe adaptarse el sistema en

funcin de qu usuario interacte con l y de la descripcin actual de dicho
usuario.
e)

Requisitos transaccionales o funcionales internos, recogen qu debe hacer

el sistema de forma interna, sin incluir aspectos de interfaz o interaccin.
Tambin son conocidos en el ambiente web como requisitos de servicios.
34

f)

Requisitos no funcionales, son por ejemplo los requisitos de portabilidad, de

reutilizacin, de entorno de desarrollo, de usabilidad, de disponibilidad, etc.

2.8.1.1. Requisitos de Datos

Tabla 2. Comparativa de Requisitos de Datos
ESPECIFICACIN RECOLECCIN ANLISIS MANIPULACIN
SI
SI
SI
SI

WSDM
SOHDM
OOHDM
EORM

SI
SI
SI
SI

SI
SI
SI
SI

PRESENTACIN

TOTAL

NO
NO
SI
NO

4
3
5
4

SI
NO
SI
SI

Elaborado por: Angel Cudco

Tabla 3. Interpretacin de Resultados de la Comparativa de Requisitos de Datos

VALOR
OBTENIDO

CALIFICACIN

ABREVIATURA

PORCENTAJE

WSDM

MUY BUENO

MB

80%

SOHDM

BUENO

60%

OOHDM

EXCELENTE

100%

EORM

MUY BUENO

MB

80%

Elaborado por: ngel Cudco

ANALISIS DE REQUISITOS DE DATOS

120%
100%

100%
80%

80%

80%
60%

60%
40%
20%
0%
WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 12. Anlisis de los Requisitos de Datos.

Fuente: ngel Cudco

2.8.1.2. Requisitos de Interfaz de usuario

Tabla 4. Comparativa de Requisitos de Interfaz de usuario
CLARIDAD CONSICION CONSISTENCIA ESTETICA EFICIENCIA TOTAL
WSDM

NO

NO

NO

NO

NO

SOHDM

SI

NO

SI

NO

SI

OOHDM

SI

SI

SI

SI

SI

EORM

SI

NO

SI

SI

NO

Elaborado por: ngel Cudco

35

Tabla 5. Interpretacin de Resultados de la Comparativa de Requisitos de Interfaz de usuario

VALOR OBTENIDO CALIFICACIN ABREVIATURA PORCENTAJE
WSDM

NO EXISTE

NE

0%

SOHDM

BUENO

60%

OOHDM

EXCELENTE

100%

EORM

BUENO

60%

Elaborado por: ngel Cudco

ANLISIS DE REQUISITOS DE INTERFAZ
DE USUARIO
120%
100%
80%
60%
40%
20%
0%

100%
60%

60%

0%
WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 13. Anlisis de los Requisitos de Interfaz de usuario.

Fuente: ngel Cudco

2.8.1.3. Requisitos Navegacionales

De acuerdo con Silva & Mercerat (2001) los requisitos navegacionales contemplan
los siguientes aspectos:
a) Nodos: son contendores de informacin, stos se definen como vistas
orientadas a objetos de las clases conceptuales.
b) Enlaces: stos representan las posibles formas de comenzar la navegacin
(Snchez, ob. cit).
c) Estructuras de Acceso: las estructuras de acceso actas como ndices o
diccionarios que permiten al usuario encontrar de forma rpida y eficiente la
informacin deseada.
d) Contexto Navegacional: provee los caminos que el usuario puede seguir, de
esta forma se evita informacin redundante y que el usuario se pierda en la
navegacin.
e) Clase de contexto: sirve para contemplar la definicin de una clase de
navegacin.

36

Tabla 6. Comparativa de requisitos navegacionales.

NODOS ENLACES

ESTRUCTURAS
DE ACCESO

CONTEXTO
NAVEGACIONAL

CLASES DE
CONTEXTO

TOTAL

WSDM

NO

NO

NO

NO

NO

SOHDM

NO

NO

NO

NO

NO

OOHDM

SI

SI

SI

SI

SI

EORM

NO

NO

NO

NO

NO

Elaborado por: ngel Cudco

Tabla 7. Anlisis de la comparativa de los requisitos navegacionales.
VALOR OBTENIDO CALIFICACIN ABREVIATURA PORCENTAJE
WSDM

NO EXISTE

NE

0%

SOHDM

NO EXISTE

NE

0%

OOHDM

EXCELENTE

100%

EORM

NO EXISTE

NE

0%

Elaborado por: ngel Cudco

ANLISIS DE REQUISITOS
NAVEGACIONALES
120%
100%
80%
60%
40%
20%
0%

100%

0%

0%

0%

WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 14. Anlisis de la comparativa de requisitos navegacionales.

Fuente: ngel Cudco

2.8.1.4. Requisitos de Personalizacin

Estos requisitos abarcan los siguientes parmetros:
a) Modularidad
b) Adaptibilidad
c) Visibilidad
d) Claridad
e) Dependencia tecnolgica

37

En base a estos parmetros se realiza la siguiente comparativa.

Tabla 8. Comparativa de los Requisitos de Personalizacin
MODULARIDAD ADAPATIBILIDAD VISIBILIDAD CLARIDAD

DEPENDENCIA
TOTAL
TECNOLOGICA

WSDM

SI

SI

SI

SI

SI

SOHDM

NO

NO

NO

NO

NO

OOHDM

NO

NO

NO

NO

NO

EORM

NO

NO

NO

NO

NO

Elaborado por: ngel Cudco

Tabla 9. Ponderacin de la comparativa de los requisitos de personalizacin.

VALOR
OBTENIDO

CALIFICACIN

ABREVIATURA

PORCENTAJE

WSDM

EXCELENTE

100%

SOHDM

NO EXISTE

NE

0%

OOHDM

NO EXISTE

NE

0%

EORM

NO EXISTE

NE

0%

Elaborado por: ngel Cudco

ANLISIS DE LOS REQUISITOS DE

PERSONALIZACIN
120%

100%

100%
80%
60%
40%
20%

0%

0%

0%

SOHDM

OOHDM

EORM

0%
WSDM

METODOLOGAS

Figura 15. Anlisis de los requisitos de personalizacin.

Fuente: ngel Cudco

2.8.1.5. Transaccionales
a) Consistencia
b) Rapidez
c) Fiabilidad
d) Inflexibilidad
e) Durabilidad
Tabla 10. Comparativa de los Requisitos transaccionales
CONSISTENCIA

RAPIDEZ

FIABILIDAD

INFLEXIBILIDAD

DURABILIDAD

TOTAL

WSDM

NO

NO

NO

NO

NO

SOHDM

SI

SI

SI

SI

SI

38

OOHDM

NO

NO

NO

NO

NO

EORM

NO

NO

NO

NO

NO

Elaborado por: ngel Cudco

Tabla 11. Calificacin de la comparativa de los Requisitos Transaccionales.
VALOR OBTENIDO

CALIFICACIN

ABREVIATURA

WSDM

NO EXISTE

NE

PORCENTAJE
0%

SOHDM

EXCELENTE

100%

OOHDM

NO EXISTE

NE

0%

EORM

NO EXISTE

NE

0%

Elaborado por: ngel Cudco

ANLISIS DE LOS REQUISITOS

TRANSACCIONALES
120%
100%
80%
60%
40%
20%
0%

100%

0%
WSDM

SOHDM

0%

0%

OOHDM

EORM

METODOLOGA

Figura 16. Anlisis de los Requisitos Transaccionales.

Fuente: ngel Cudco

2.8.1.6. Requisitos No Funcionales

McConnell, Steve (1996) en su obra Rapid Development: Taming Wild
Software Schedules, define a los requisitos no funcionales como los "recursos" para
que trabaje el sistema de informacin, por ejemplo: el rendimiento, la calidad, la
disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.
Tabla 12. Comparativa de los Requisitos no funcionales.
RENDIMIENTO CALIDAD MANTENIMIENTO DISPONIBILIDAD
SI
NO
NO
NO

WSDM
SOHDM
OOHDM
EORM

SI
NO
NO
NO

SI
NO
NO
NO

NO
NO
NO
NO

FACILIDAD
TOTAL
DE USO
SI
4
NO
0
NO
0
NO
0

Elaborado por: ngel Cudco

Tabla 13. Interpretacin de la Comparativa de los Requisitos no funcionales.
VALOR OBTENIDO

CALIFICACIN

ABREVIATURA

PORCENTAJE

WSDM

MUY BUENA

MB

80%

SOHDM

NO EXISTE

NE

0%

OOHDM

NO EXISTE

NE

0%

EORM

NO EXISTE

NE

0%

Elaborado por: ngel Cudco

39

ANLISIS DE REQUISITOS NO
FUNCIONALES
100%

80%

80%
60%
40%
20%

0%

0%

0%

SOHDM

OOHDM

EORM

0%
WSDM

METODOLOGAS
Figura 17. Anlisis de la comparativa de requisitos no funcionales.
Fuente: ngel Cudco

2.8.1.7. RESUMEN

DEL

REQUISITOS

ESTUDIO

TRATADOS

COMPARATIVO
POR

LAS

DE

LOS

METODOLOGAS

ESTUDIADAS
En la tabla 14 se presentan los diferentes requisitos y se indica cules de
ellos son tratados en cada metodologa.
Tabla 14. Tipos de requisitos contemplados en cada propuesta
REQUISITOS

WSDM

80%

Interfaz
Usuario
0%

0%

100%

0%

No
Funcionales
80%

SOHDM

60%

60%

0%

0%

100%

0%

OOHDM

100%

100%

100%

0%

0%

0%

EORM

80%

60%

0%

0%

0%

0%

Datos

Navegacionales

Personalizacin

Transaccionales

Elaborado por: Angel Cudco

Tabla 15. Calificacin tipos de requisitos contemplados en cada propuesta
REQUISITOS

WSDM

80%

Interfaz
Usuario
0%

0%

100%

0%

No
Funcionales
80%

SOHDM

60%

60%

0%

0%

100%

0%

37%

OOHDM

100%

100%

100%

0%

0%

0%

50%

EORM

80%

60%

0%

0%

0%

0%

23%

Datos

Navegacionales

Personalizacin

Elaborado por: Angel Cudco

40

Transaccionales

PROMEDIO
43%

CUMPLIMIENTO DE
REQUISITOS DE DATOS

ANLISIS DEL CUMPLIMIENTO DE REQUISITOS DE

DATOS
50%
43%
37%
23%

WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 18. Anlisis del cumplimiento de los Requisitos de Datos.

Fuente: ngel Cudco

2.8.2.

Fases del Ciclo de vida de desarrollo del software

La segunda evaluacin que se va a realizar a las metodologas enunciadas

se hacen en base a las fases del ciclo de vida de desarrollo del software, esto muestra
cules de estas fases genricas son tratadas en cada metodologa y cules de ellas
pueden ser tiles. El ciclo de vida bsico de un software consta de los siguientes
procedimientos:

Planificacin

Estudio de Viabilidad

Identificacin de Requerimientos

Anlisis

Diseo

Construccin

Implementacin y Mantenimiento

2.8.2.1. Planificacin y Estudio de Viabilidad

Ninguna de las Metodologas en estudio dentro de sus Ciclos de vida realizan una
Planificacin y un Estudio de Viabilidad, al buscar una propuesta metodolgica
para el diseo e implementacin de sistemas de informacin web basadas y
centradas en los usuarios stas actividades constituyen el punto de partida para el
xito de los sistemas a implementar.

41

2.8.2.2. Identificacin de Requerimientos

Tabla 16. Comparativa de la Fase de Identificacin de Requerimientos
Alternativa de
Solucin

Priorizar y
Seleccionar
necesidades

Identificacin
de Usuarios

Contextos
de Usos

SI

SI

SI

SI

NO

NO

NO

NO

NO

NO

SI

SI

SI

SI

SI

NO

NO

NO

NO

NO

METODOLOGA
WSDM
METODOLOGA
SOHDM
METODOLOGA
OOHDM
METODOLOGA
EORM

Definicin de
TOTAL
estndares

Elaborado por: ngel Cudco

Tabla 17. Calificacin a la Comparativa de la Fase de Identificacin de Requerimientos.

WSDM
SOHDM
OOHDM
EORM

VALOR
OBTENIDO
4
0
5
0

CALIFICACIN

ABREVIATURA

PORCENTAJE

MUY BUENA
NO EXISTE
EXCELENTE
NO EXISTE

NE
NE
E
NE

80%
0%
100%
0%

Elaborado por: ngel Cudco

ANLISIS DE LA IDENTIFICACIN DE
REQUERIMIENTOS
120%

100%

100%

80%

80%
60%
40%
20%

0%

0%

0%

WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 19. Anlisis de la Comparativa de la Fase de Identificacin de Requerimientos.

Fuente: ngel Cudco

2.8.2.3. Fase de Anlisis

Tabla 18. Comparativa de la Fase de Anlisis

METODOLOGA
WSDM
METODOLOGA
SOHDM
METODOLOGA
OOHDM
METODOLOGA
EORM

Requerimientos

Perfiles

Intencin de
Uso

SI

SI

SI

SI

SI

SI

SI

NO

SI

SI

SI

SI

SI

SI

SI

SI

SI

NO

SI

NO

Elaborado por: ngel Cudco

42

Modelado de
Validacin TOTAL
Datos y Procesos

Tabla 19. Calificacin a la Comparativa de la Fase de Anlisis.

WSDM
SOHDM
OOHDM
EORM

VALOR
OBTENIDO
5
4
5
3

CALIFICACIN

ABREVIATURA

PORCENTAJE

EXCELENTE
MUY BUENA
EXCELENTE
BUENA

E
MB
E
B

100%
80%
100%
60%

Elaborado por: ngel Cudco

ANLISIS ESTADSTICO DE LA FASE DE ANLISIS

120%

100%

100%

100%

80%

80%

60%

60%
40%
20%
0%

WSDM

SOHDM
OOHDM
METODOLOGA

EORM

Figura 20. Anlisis estadstico de la Fase de Anlisis.

Fuente: ngel Cudco

2.8.2.4. Diseo
Tabla 20. Comparativa de la Fase de Diseo

METODOLOGA
WSDM
METODOLOGA
SOHDM
METODOLOGA
OOHDM
METODOLOGA
EORM

Contenido

Interaccin

Visual

Arquitectura de la
Informacin

Herramientas
Tecnolgicas

TOTAL

SI

SI

SI

SI

NO

SI

SI

SI

NO

NO

SI

SI

SI

SI

SI

SI

SI

SI

NO

NO

Elaborado por: ngel Cudco

Tabla 21. Calificacin a la comparativa de la Fase de Diseo

WSDM
SOHDM
OOHDM
EORM

VALOR
OBTENIDO
4
3
5
3

CALIFICACIN

ABREVIATURA

PORCENTAJE

MUY BUENA
BUENA
EXCELENTE
BUENA

MB
B
E
B

80%
60%
100%
60%

Elaborado por: ngel Cudco

43

ANLISIS DE LA FASE DE DISEO

120%

100%

100%

80%

80%

60%

60%

60%

40%
20%
0%

WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 21. Anlisis de la Fase de Diseo.

Fuente: ngel Cudco

2.8.2.5. Construccin
Tabla 22. Comparativa de la Fase de Construccin
Preparacin
Entorno de
Trabajo

Generacin de
Componentes y
Proc.

Pruebas y
Validacin

Educacin
a usuarios

Carga Inicial
de Datos

TOTAL

SI

SI

SI

NO

NO

NO

SI

SI

NO

NO

SI

SI

SI

SI

NO

NO

SI

SI

NO

NO

METODOLOGA
WSDM
METODOLOGA
SOHDM
METODOLOGA
OOHDM
METODOLOGA
EORM

Elaborado por: ngel Cudco

Tabla 23. Calificacin a las Metodologas de la Comparativa de la fase de construccin.

WSDM
SOHDM
OOHDM
EORM

VALOR
OBTENIDO
3
2
4
2

CALIFICACIN ABREVIATURA PORCENTAJE

BUENA
REGULAR
MUY BUENA
REGULAR

B
R
MB
R

60%
40%
80%
40%

Elaborado por: ngel Cudco

ANLISIS DE LA FASE DE CONSTRUCCIN
100%
80%

80%
60%

60%

40%

40%

40%
20%
0%
WSDM

SOHDM

OOHDM

EORM

METODOLOGA

Figura 22. Anlisis de la Comparativa de la Fase de Construccin.

Fuente: ngel Cudco

44

2.8.2.6. Implementacin y Mantenimiento

Tabla 24. Comparativa de la Fase de Implementacin y Mantenimiento.

METODOLOGA
WSDM
METODOLOGA
SOHDM
METODOLOGA
OOHDM
METODOLOGA
EORM

Revisin de
Tareas

Implementacin

Mantenimiento

Pruebas y
Validacin

Aprobacin
del SI

TOTAL

SI

SI

SI

NO

SI

NO

SI

SI

SI

NO

SI

SI

SI

SI

NO

SI

SI

SI

NO

NO

Elaborado por: ngel Cudco

Tabla 25. Calificacin a la Comparativa de la Fase de Implementacin y Mantenimiento.

WSDM
SOHDM
OOHDM
EORM

VALOR
OBTENIDO
4
3
4
3

CALIFICACIN

ABREVIATURA

PORCENTAJE

MUY BUENA
BUENA
MUY BUENA
BUENA

MB
B
MB
B

80%
60%
80%
60%

Elaborado por: ngel Cudco

ANLISIS DE LA COMPARATIVA DE LA FASE DE

IMPLEMENTACIN Y MANTENIMIENTO
100%

80%

80%

80%
60%

60%

60%
40%
20%
0%
WSDM

SOHDM

OOHDM

EORM

METODOLOGAS
Figura 23. Anlisis de la Comparativa de la Fase de Implementacin y Mantenimiento.
Fuente: ngel Cudco

45

2.8.2.7. Resumen de la Comparativa de las Fases del ciclo de vida de desarrollo

del software

ESTUDIO DE VIABILIDAD

ESPECIFICACIN
REQUERIMIENTOS

ANLISIS

DISEO

CONSTRUCCION

IMPLEMENTACION Y
MANTENIMIENTO

PROMEDIO

METODOLOGA
WSDM
METODOLOGA
SOHDM
METODOLOGA
OOHDM
METODOLOGA
EORM

PLANIFICACION

Tabla 26. Resumen de la Comparativa de las Fases del ciclo de vida de desarrollo
del software

0%

0%

80%

100%

80%

60%

80%

57%

0%

0%

0%

80%

60%

40%

60%

34%

0%

0%

100%

100%

100%

80%

80%

66%

0%

0%

0%

60%

60%

40%

60%

31%

Elaborado por: ngel Cudco

ANLISIS DE LA COMPARATIVA DE LAS FASES DEL

CICLO DE VIDA DE DESARROLLO DEL SOFTWARE
66%
57%
34%

31%

METODOLOGA METODOLOGA METODOLOGA METODOLOGA

WSDM
SOHDM
OOHDM
EORM

METODOLOGAS
Figura 24. Anlisis de la comparativa de las fases del ciclo de vida de desarrollo del software.
Fuente: ngel Cudco

2.8.3.

Caractersticas de las metodologas

Para la cuarta evaluacin se toman en cuenta las caractersticas importantes de las

metodologas que son adecuados para el desarrollo de los sistemas de informacin.
Estas caractersticas se pueden clasificar en:

46

ORIENTADA A
OBJETOS

TRATAMIENTO
USABILIDAD

TRATAMIENTO
ACCESIBILIDAD

DISEO
NAVEGACIONAL

DISEO
INTERACCIN

DISEO
INFORMACIN

DISEO
EXPERINECIA DEL
USUARIO

DISEO INTERFAZ
DE USUARIO

TOTAL

PORCENTAJE

Tabla 27. Caractersticas de las Metodologas.

METODOLOGA
WSDM

SI

SI

NO

SI

SI

NO

SI

SI

75%

METODOLOGA
SOHDM

SI

SI

NO

SI

SI

NO

SI

SI

75%

METODOLOGA
OOHDM

SI

NO

NO

SI

SI

NO

NO

SI

50%

METODOLOGA
EORM

SI

NO

NO

NO

NO

NO

NO

SI

25%

Elaborado por: ngel Cudco

ANLISIS DE LAS CARACTERSTICAS DE LAS

METODOLOGAS
75%

75%

50%

25%

WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 25. Anlisis de las Caractersticas de las Metodologas.

Fuente: ngel Cudco

47

CAPITULO III
DESARROLLO DE UNA PROPUESTA METODOLGICA
PARA LA IMPLEMENTACIN DE SISTEMAS WEB
BASADOS Y CENTRADOS EN LOS USUARIOS
El desarrollo de aplicaciones Web es una tarea que demanda amplios conocimientos
tcnicos y experiencia por parte del personal involucrado. (Escalona, 2002). Para
ello el equipo de trabajo encargado de esta labor debe seguir un proceso de
desarrollo acompaado de mtodos adecuados que influyan directamente en su
construccin, con el propsito de garantizar la calidad de este tipo de aplicaciones.
Por lo tanto, se ha diseado una propuesta metodolgica gil con un enfoque
sistemtico y disciplinado para desarrollar sistemas web diseados y centrados en
los usuarios de alta calidad, la cual toma en cuenta la estructura de las instituciones
educativas y contribuye a lograr mayor efectividad en esta rea de creciente
diversidad.
En este orden de ideas, es preciso sealar que se ha tomado en cuenta la usabilidad
de las aplicaciones Web, la cual se ha convertido en un factor crtico de calidad en
los sistemas de software que se desarrollan actualmente, y a sido considerada y
tomada en cuenta durante los ltimos aos por parte de la Ingeniera del Software.
(Beck, 1996). Sin embargo, hay un gran desconocimiento entre los desarrolladores
acerca de las tcnicas y atributos de usabilidad a ser considerados; aunado a la
percepcin de que los temas relacionados con la usabilidad son ms bien ajenos a
la Ingeniera del Software, y que deben aplicarse nicamente para el desarrollo de
la interfaz de usuario.

48

3.1.

Desarrollo de la propuesta
La metodologa propuesta est destinada a la elaboracin de sistemas de

informacin Web diseados y centrados en los usuarios y tiene como finalidad

representar a la organizacin y sus objetivos, minimizar los problemas que pudiesen
encontrarse y de esta forma apoyar sus procesos
Para el desarrollo de la Propuesta Metodolgica para la Implementacin de
Sistemas Web diseados y centrados en los usuarios de tomar en consideracin el
estudio comparativo de las Metodologas Web en el apartado 3.5 de este trabajo de
investigacin. En los siguientes apartados de ste captulo se detallan la propuesta
metodolgica aplicable en la Gestin Jurdica.
3.1.1.

Requisitos tratados
En la Tabla 15 se observa que la Metodologa OOHDM se encarga del

tratamiento de los requisitos de Datos, Interfaz al Usuario y Navegacionales, de

manera similar la Metodologa WSDM es ptima para el tratamiento de los
Requisitos de Personalizacin y Requisitos no funcionales, finalmente la
Metodologa SOHDM es ptima para el tratamiento de los Requisitos
Transaccionales.
La Metodologa a proponer abarca las caractersticas de la Metodologa OOHDM
para el tratamiento de los Requisitos de Datos, Interfaz al Usuario y
Navegacionales, de la Metodologa WSDM hereda el tratamiento de los Requisitos
de Personalizacin y No funcionales y de la Metodologa SOHDM hereda el
tratamiento de los Requisitos Transaccionales. En la Tabla 28 se puede observar el
tratamiento a los Requisitos por parte de la Metodologa Propuesta.
Tabla 28. Tratamiento de los Requisitos por parte de la Metodologa Propuesta.
METODOLOGA
REQUISITOS

DATOS

ATRIBUTOS

WSDM SOHDM OOHDM EORM PROPUESTA

ESPECIFICACIN

SI

SI

SI

SI

SI

RECOLECCIN

SI

SI

SI

SI

SI

ANLISIS

SI

SI

SI

SI

SI

MANIPULACIN

SI

NO

SI

SI

SI

PRESENTACIN

NO

NO

SI

NO

SI

CLARIDAD

NO

SI

SI

SI

SI

49

INTERFAZ AL
USUARIO

NAVEGACIONALES

PERSONALIZACIN

TRANSACCIONALES

NO FUNCIONALES

CONSICION

NO

NO

SI

NO

SI

CONSISTENCIA

NO

SI

SI

SI

SI

ESTETICA

NO

NO

SI

SI

SI

EFICIENCIA

NO

SI

SI

NO

SI

NODOS

NO

NO

SI

NO

SI

ENLACES
ESTRUCTURAS DE
ACCESO
CONTEXTO
NAVEGACIONAL
CLASES DE CONTEXTO

NO

NO

SI

NO

SI

NO

NO

SI

NO

SI

NO

NO

SI

NO

SI

NO

NO

SI

NO

SI

MODULARIDAD

SI

NO

NO

NO

SI

ADAPATIBILIDAD

SI

NO

NO

NO

SI

VISIBILIDAD

SI

NO

NO

NO

SI

CLARIDAD
DEPENDENCIA
TECNOLOGICA
CONSISTENCIA

SI

NO

NO

NO

SI

SI

NO

NO

NO

SI

NO

SI

NO

NO

SI

RAPIDEZ

NO

SI

NO

NO

SI

FIABILIDAD

NO

SI

NO

NO

SI

INFLEXIBILIDAD

NO

SI

NO

NO

SI

DURABILIDAD

NO

SI

NO

NO

SI

RENDIMIENTO

SI

NO

NO

NO

SI

CALIDAD

SI

NO

NO

NO

SI

MANTENIMIENTO

SI

NO

NO

NO

SI

DISPONIBILIDAD

NO

NO

NO

NO

SI

FACILIDAD DE USO

SI

NO

NO

NO

SI

Elaborado por: Angel Cudco

Al utilizar la informacin de la Tabla 28 se procede a la valoracin de las

Metodologas mediante la valoracin de las metodologas establecidas en el
aparatado 3.5.
Tabla 29. Calificacin al Tratamiento de Requisitos por parte de las metodologas.
REQUISITOS
METODOLOGA

Datos

WSDM
SOHDM
OOHDM
EORM
PROPUESTA

80%
60%
100%
80%
100%

Interfaz
Usuario
0%
60%
100%
60%
100%

Navegac.

Personalizac.

Transac.

0%
0%
100%
0%
100%

100%
0%
0%
0%
100%

0%
100%
0%
0%
100%

No
PROMEDIO
Funcionales
80%
43%
0%
37%
0%
50%
0%
23%
100%
100%

Elaborado por: Angel Cudco

En la Tabla 28 y Tabla 29 se observa el tratamiento a los Requisitos por parte de la

Propuesta Metodolgica. En la Figura 26 se observa el Tratamiento de los
Requisitos de la Propuesta Metodolgica frente a las Metodologas en estudio.

50

TRATAMIENTO DE REQUISITOS
100%

43%

50%

37%
23%

WSDM

SOHDM

OOHDM

EORM

PROPUESTA

METODOLOGA

Figura 26. Tratamiento de los Requisitos de la Propuesta Metodolgica frente a las dems
Metodologas en estudio.
Fuente: ngel Cudco

3.1.2.

Fases del Ciclo de Vida

Dentro de las Fases del Ciclo de Vida del desarrollo de software centrado

en el usuario, a continuacin se compararon algunas metodologas usadas

fecuentemente en el desarrollo de este tipo de sistemas, tales como: WSDM,
OOHDM, SOHDM y EORM. De este estudio comparativo se observ que estas
metodologas otorgan poca importancia a los usuarios en los modelos de desarrollo
de software, y la figura del usuario aparece al principio del desarrollo, al final del
mismo o al final de cada etapa, pero no durante el proceso de desarrollo.
Ninguna de las Metodologas estudiadas dentro de su ciclo de Vida contempla una
Fase de Planificacin tampoco realiza un Estudio de Factibilidad, por ello la
propuesta Metodolgica dentro de su Ciclo de Vida agrupa estas dos fases como
una sola a la cual se la denomina como Planificacin del Sistema de Informacin.
Las Fases de Especificacin de Requisitos y Anlisis se agrupan en una Fase
denominada Fase de Anlisis del Sistema, ya que Lamas (2009), Pressman (2010),
Sommerville (2011) y Escalona (2002) agrupan a estas fases como una sola dentro
del Ciclo de Vida de Software. En esta fase de la Metodologa OOHDM hereda las
Fases de Especificacin de Requisitos y de la Metodologa WSDM hereda la Fase
de Anlisis.

51

Las fases de Diseo y Construccin son heredadas de la Metodologa y finalmente

la Fase de Implementacin y Mantenimiento es una fusin entre la Metodologa
OOHDM y WSDM.
En el desarrollo de sistemas centrados en los usuarios, como los sistemas jurdicos,
intervienen equipos multidisciplinarios, de all la importancia de proporcionar una
frontera comunicativa entre ellos. Esto se considera de gran valor en el diseo de
MeDWCU, ya que se considera la necesidad de ofrecer una metodologa basada en
el paradigma orientado a objetos, que ofrezca el tratamiento a la usabilidad y
accesibilidad, que cubra todo el ciclo de desarrollo de aplicaciones Web, y que
utiliza el lenguaje de modelado UML (Unified Modeling Language), como un
formalismo especfico para aquellas partes en las que los participantes son capaces
de entenderlos; y especificaciones con tcnicas ms comunes para las
interconexiones comunicativas.
Tabla 30. Fases del Ciclo de Vida de Desarrollo de Software y atributos de las Metodologas en
estudio y la Propuesta
ATRIBUTOS

PLANIFICACIN

ESTUDIO DE
VIABILIDAD

DETERMINACI
N DE
REQUISITOS

ANLISIS DE
REQUISITOS

DISEO

CONSTRUCCIN

WSDM SOHDM

OOHDM

EORM PROPUESTA

Definicin y
Organizacin
Definir el Alcance

SI

Estimacin de
Recursos
Enfoque

SI

Alcance

SI

Impacto en la
Organizacin
Datos
Interfaz al
usuario
Navegacionales
Personalizacin
Transaccionales
NO
FUNCIONALES
Anlisis

FUNCIONAL
ES

ANLISIS DEL SISTEMA

PLANIFICACIN
DEL SISTEMA

FASES

SI

SI

SI

NO

SI

NO

SI
SI

SI

NO

SI

NO

SI

SI
SI
NO

NO
NO
NO

SI
SI
SI

NO
NO
NO

SI
SI
SI

NO

NO

SI

NO

SI

SI

SI

SI

SI

SI

Validacin

SI

SI

SI

NO

SI

Diseo de BD

SI

SI

SI

SI

SI

Navegacional

SI

SI

SI

SI

SI

Interfaz
Arquitectura de la
Informacin
Preparacin
Entorno de Trabajo
Creacin de
Templates

SI

SI

SI

SI

SI

SI

NO

SI

NO

SI

SI

NO

SI

NO

SI

SI

SI

SI

SI

SI

52

IMPLEMENTACIN Y
MANTENIMIENTO

Generacin de
Componentes y
Proc.
Pruebas y
Validacin
Carga Inicial de
Datos
Revisin de Tareas

SI

SI

SI

SI

SI

NO

NO

SI

NO

SI

NO

NO

NO

NO

SI

SI

NO

SI

SI

SI

Implementacin

SI

SI

SI

SI

SI

Mantenimiento
Pruebas y
Validacin
Aprobacin del SI

SI

SI

SI

SI

SI

NO

SI

SI

NO

SI

SI

NO

NO

NO

SI

Elaborado por: ngel Cudco

Tabla 31. Fases del Ciclo de Vida de Desarrollo de Software por parte de las Metodologas
estudiadas y la Propuesta Metodolgica.
FASES
PLANIFICACION
PLANIFICACIN
ESTUDIO DE
DEL SI
VIABILIDAD
ESPECIFICACIN
ANLISIS DEL REQUERIMIENTOS
SI
ANLISIS
DISEO
CONSTRUCCION
IMPLEMENTACION Y
MANTENIMIENTO
PROMEDIO

METODOLOGA
WSDM SOHDM OOHDM EORM PROPUESTA
0%
0%
0%
0%
100%
0%

0%

0%

0%

100%

80%

0%

100%

0%

100%

100%
80%
60%

80%
60%
40%

100%
100%
80%

60%
60%
40%

100%
100%
100%

80%

60%

80%

60%

100%

57%

34%

66%

31%

100%

Elaborado por: ngel Cudco

CUMPLIMIENTO FASES DEL CICLO DE VIDA DE

SOFTWARE
100%
66%

57%
34%

WSDM

SOHDM

31%

OOHDM

EORM

PROPUESTA

Figura 27. Fases del Ciclo de Vida de desarrollo de software de las Metodologas en estudio
y la Propuesta.
Fuente: ngel Cudco

Una vez que se ha entendido que el objetivo del desarrollo de sistemas de

informacin, es obtener un sistema que permita a los usuarios finales alcanzar sus
objetivos as como llevar a cabo, de forma efectiva y eficiente, las tareas necesarias

53

para conseguirlos, se hace necesario, no slo tener en cuenta los requisitos del
sistema, sino adems, incorporar nuevas tcnicas que ayuden a captar las
necesidades del usuario donde se tomen en cuenta los criterios de usabilidad, para
as desarrollar interfaces de usuario intuitivas y fciles de usar.
Cabe resaltar que MeDWCU es una metodologa de desarrollo iterativo e
incremental de la Ingeniera del Software, la cual por ser una propuesta centrada en
las necesidades de los usuarios, tiene como objetivo generar aplicaciones usables.
Adems, incorpora en las diferentes fases que la conforman algunos de los mtodos
de evaluacin de usabilidad sealados por Hom (1998).
El nmero de iteraciones de MeDWCU, as como de actividades y tcnicas a aplicar
en cada etapa, dependern de la complejidad del sitio Web a desarrollar.
3.1.2.1. Actividades y Tcnicas a aplicar en cada de fase del Ciclo de Vida
En la Tabla 32 se presentan las actividades, tcnicas y productos de cada
una de las fases y subfases de MeDWCU.
Tabla 32. Actividades, tcnicas y productos de cada una de las fases y subfases de MeDWCU.

ANLISIS DEL SI

PLANIFICACIN
DEL SI

FASES

ACTIVIDADES

PLANIFICACION

Planificar el proceso de
desarrollo.

ESTUDIO DE
VIABILIDAD

- Analizar el conjunto de
necesidades.
- Proponer una solucin a
corto plazo.
CAPTURA:
- Analizar el entorno.
- Identificar requisitos y
actores.

ESPECIFICACIN
REQUERIMIENTOS

ANLISIS DE
REQUISITOS

TECNICAS
- Estimacin de
costos.
- Estimacin de la
velocidad del
proyecto.
- Entrevistas,
cuestionarios
- Observacin
directa.
- Entrevistas,
cuestionarios
- Observacin
directa.
- Anlisis de
sistemas similares.

PRODUCTOS
- Tabla de
prioridades.
- Plan de entregas.
- Plan de
Iteraciones.
- Objetivos del
sistema.
- Estudio de
factibilidad.

- Documento de
requisitos:
usuarios.
- Tabla de
DEFINICIN:
requerimientos del
- Definir requisitos: datos, - Diagrama de Casos
sistema.
interfaz al usuario,
de Uso
- Tabla de casos de
Navegacionales,
- Diagramas de
usos.
personalizacin,
Interaccin de
transaccionales, no
Usuario
funcionales.
- Escenarios
- Validar requisitos.
- Sesiones de
- Catlogo de
VALIDACIN
- Analizar requisitos.
Trabajo
Requisitos

54

- Validar requisitos.

- Catalogacin
- Casos de Uso

BASICO:
- Disear la BD.
- Construir el diccionario
de datos.
NAVEGACIONAL:
- Disear diagramas de
clases.
- Disear modelo
navegacional.
INTERFAZ
ABSTRACTA:
- Interfaces determinadas

DISEO

- Modelo de Casos
de Uso
- Especificacin de
Casos de
Uso

- Tcnica
entidad/relacin
- Clasificacin,
agregacin,
generalizacin y
especializacin.

- Card sorting
- Prototipos.
- Diagramas E-R.
- Diseo Modelo
de navegacin.

- Tcnica de modelo
orientado a objetos.

- Modelo de
estructura de
navegacin.
- Prototipo de
pgina de inicio.

con cada seccin

perceptible por el
usuario.
Elaborado por: ngel Cudco

Las fases de Construccin e Implementacin, las cuales no se reflejan en la Tabla

32, corresponden a la prepararacin el cdigo fuente para cada una de las clases y
la interfaz grfica de usuarios y finalmente la implementacin del sistema de
informacin, es de vital importancia considerar el entorno particular en el cual se
va a desarrollar.
MeDWCU incorpora actividades de evaluacin durante todo el ciclo de vida del
desarrollo de sistemas centrados en los usuarios, para lo cual se incoporan planes
especficos que conlleven a la inspeccin, revisin y evaluacin del mismo; todo
ello con la finalidad de asegurar que cumpla perfectamente con la totalidad de los
requisitos para los cuales fue diseado.
La Tabla 33 presenta en forma resumida las tcnicas de evaluacin recomendadas
para ser utilizadas en las diversas fases del desarrollo de portales.
Tabla 33. Tcnicas de evaluacin de usabilidad en las diferentes fases de MeDWCU.
TCNICA

FASE

Observacin

Anlisis de requisitos.

Entrevistas

Anlisis de requisitos, diseo, implementacin.

55

Cuestionarios

Anlisis de requisitos, implementacin.

Pensar en voz alta

Implementacin, implementacin.

Card Sorting

Diseo

Elaborado por: Angel Cudco

3.1.3.

Caractersticas
El enfoque orientado a objetos como paradigma de diseo es muy til

debido al gran nivel de abstraccin que ofrece y a sus mecanismos de composicin

que facilitan el modelado de la estructura hipermedia, as lo seala Lange (1994).
En consecuencia la Propuesta Metodolgica a desarrollar se basa en este paradigma,
con la finalidad de proporcionar dicha ventaja a este tipo de desarrollos. Adems,
de acuerdo al estudio realizado a los diferentes enfoques metodolgicos sealados
previamente se observa que solamente EORM, OOHDM, SOHDM y WSDM,
emplean este paradigma. Por lo tanto, es a partir de ellas que se concret el estudio
comparativo.
Otro aspecto importante tomado en cuenta para el desarrollo de MeDWCU es la
USABILIDAD, debido que mejora la calidad de vida de los usuarios, ya que reduce
su estrs, incrementa la satisfaccin y la productividad al encontrar rpidamente la
informacin que buscan. El ltimo aspecto considerado en este estudio es la
Accesibilidad para que los usuarios puedan acceder de forma equitativa a los
contenidos del sistema de informacin.
Tabla 34. Caractersticas de las Metodologas estudiadas y de la Propuesta Metodolgica.
CARACTERSTICA

WSDM

SOHDM

OOHDM

EORM

PROPUESTA

ORIENTADA A OBJETOS

SI

SI

SI

SI

SI

TRATAMIENTO USABILIDAD

SI

SI

NO

NO

SI

TRATAMIENTO
ACCESIBILIDAD

NO

NO

NO

NO

SI

DISEO NAVEGACIONAL

SI

SI

SI

NO

SI

DISEO INTERACCIN

SI

SI

SI

NO

SI

DISEO INFORMACIN
DISEO EXPERINECIA DEL
USUARIO
DISEO INTERFAZ DE
USUARIO

NO

NO

NO

NO

SI

SI

SI

NO

NO

SI

SI

SI

SI

SI

SI

Elaborado por: ngel Cudco

56

CARACTERSTICAS DE METODOLOGAS CENTRADAS EN

LOS USUARIOS
100%
75%

75%
50%
25%

WSDM

SOHDM

OOHDM

EORM

PROPUESTA

METODOLOGA

Figura 28. Cumplimiento de las caractersticas de las Metodologas de diseo web centrado
en el Usuario.
Fuente: ngel Cudco

Finalmente, de acuerdo a los aspectos que abarca MeDWCU y a las consideraciones

tomadas en cuenta para su diseo, se pueden identificar las siguientes caractersticas
en la misma:
-

Tecnolgicamente independiente, adecundose a cualquier cambio de este

tipo.

Est conforme a los principios del Diseo Centrado en el Usuario.

Fomenta el desarrollo de sistemas evolutivo: Iterativo e incremental.

Evidencia la usabilidad del sistema cmo objetivo prioritario.

Utiliza una nomenclatura normalizada, que viene dada por el lenguaje de

modelado UML, lo cual habilita una comunicacin ms fluida entre las
personas involucradas.

Es una metodologa flexible, que le brinda la oportunidad a los

desarrolladores de utilizar otras tcnicas en la fase de requisitos.

MeDWCU toma en cuenta la complejidad del desarrollo de aplicaciones Web y

considera lo sealado por Pressman (2010), recomienda el siguiente equipo de
trabajo: desarrolladores y proveedores de contenidos, editores Web o
programadores, ingeniero de Web, diseador grfico, especialistas de soporte y
administrador. Este equipo de trabajo corresponde a personas que pueden tener
diversos roles, de acuerdo a la fase de desarrollo en la que se encuentren. Algunos

57

roles podrn ser abarcados por ms de una persona (desarrollador) y una persona
podr cubrir ms de un rol (proveedor de contenido).
Para finalizar es importante destacar que MeDWCU est orientado a proyectos de
diferente escala y cualquier tipo de riesgo, es independiente del lenguaje de
programacin y est enfocada a desarrollos Web. Adems, por ser una metodologa
gil, est circunscrita a los valores detallados en el Manifiesto para el desarrollo
gil de Software (Beck et al., 2001).
3.2.

Descripcin de la Metodologa
La metodologa MeDWCU est destinada a la elaboracin de sistemas de

informacin Web diseados y centrados en los usuarios que tiene como finalidad
representar a la organizacin y sus objetivos, minimizar los problemas que pudiesen
encontrarse y de esta forma apoyar sus procesos.
Esta metodologa se centra en el desarrollo de sistemas de informacin web basados
y centrados en los usuarios, segn Lamas (2009) las Metodologas ms ptimas
para este tipo de sistemas son SOHDM, OOHDM, WSDM y EORM, es por eso que
mediante la integracin de stas metodologas se proporcionar un modelo para la
construccin de sistemas web centrados en los usuarios a la vez permitir a los
interesados desarrollar aplicaciones de este tipo sin mayor esfuerzo.
3.2.1.

FASES DE LA METODOLOGA MeDWCU

La metodologa MeDWCU est organizada en cinco fases las mismas que

se describen en el siguiente grfico junto con las principales actividades.

58

Planificacin

Planificacin del Sistema

Estudio de Factibilidad

Anlisis

Determinacin y Especificacin de
Requisitos
Anlisis de Requisitos

Diseo

Diseo Bsico
Navegacional
Interfaz Abstracta

Construccin

Preparacin del entorno de trabajo

Creacin de Templates.
Creacin de Mdulos y Componentes.

Implementacin y
Mantenimiento

Revisin de Tareas.
Pruebas y validacin.
Aprobacin del SI.

Figura 29. Fases de la Metodologa MeDWCU.

Fuente: ngel Cudco

El objetivo de cada una de las fases se describe a continuacin:

Fase 1: Planificacin.- Definir concretamente con los interesados relevantes

un plan inicial para el desarrollo de la aplicacin. A la vez la planificacin se
encarga de la obtencin de un marco de referencia para que el desarrollo del
sistema responda con los objetivos estratgicos de la organizacin.

Fase 2: Anlisis del Sistema.- Obtener una especificacin detallada del

sistema de informacin que satisfaga las necesidades de los usuarios y sirva de
base para el posterior diseo del sistema.

Fase 3: Diseo.- Definir la arquitectura del sistema y del entorno tecnolgico

que le va a dar soporte, junto con la especificacin detallada de los
componentes del sistema de informacin. A partir de dicha informacin,
generar todas las especificaciones de construccin relativas al propio sistema,
as como la descripcin tcnica del plan de pruebas, la definicin de los
requisitos de implantacin y el diseo de los procedimientos de migracin y
carga inicial.

Fase 4: Construccin.- Desarrollar el cdigo de la aplicacin, mediante el uso

de templates para el correcto desarrollo de las interfaces. Luego de esto se
deber presentar al usuario el producto final, de modo que pueda dar nuevas
sugerencias del software y adaptarlas posteriormente.

59

Fase 5: Implementacin y Mantenimiento.- Esta etapa corresponde a la

implementacin y el mantenimiento de la aplicacin realizada, ya sea de forma
local o en un servicio de hosting, con el fin de verificar si se han cumplido a
cabalidad todos los requerimientos establecidos en un principio por parte de los
usuarios.

3.2.1.1. FASE 1: PLANIFICACIN

Para el correcto entendimiento y la adecuada aplicacin de la metodologa
a esta fase se la ha dividido en dos etapas: Planificacin y Estudio de Viabilidad,
las mismas que se describen en los siguientes apartados.
a) PLANIFICACIN DEL SISTEMA
La Planificacin de Sistemas de Informacin tiene como objetivo la
obtencin de un marco de referencia para el desarrollo de sistemas de informacin
que responda a los objetivos estratgicos de la organizacin. Este marco de
referencia consta de:

Una descripcin de la situacin actual, que constituir el punto de partida del

plan de desarrollo del Sistema de Informacin. Dicha descripcin incluir un
anlisis tcnico de puntos fuertes y riesgos, as como el anlisis de servicio a
los objetivos de la organizacin.

Un conjunto de modelos que constituya la arquitectura de informacin.

Una propuesta de calendario para la ejecucin de las fases del desarrollo de

software.

Un plan de seguimiento y cumplimiento de todo lo propuesto mediante el uso

de mecanismos de evaluacin adecuados.

La perspectiva del plan debe ser estratgica y operativa, no tecnolgica. Las

principales tcnicas a utilizar para esta actividad se describen a continuacin:

Sesiones de trabajo

Entrevistas encuestas.

Observacin directa.

60

b) ESTUDIO DE VIABILIDAD
El objetivo del Estudio de Viabilidad del Sistema es el anlisis de un
conjunto concreto de necesidades para proponer una solucin a corto plazo, que
tenga en cuenta restricciones econmicas, tcnicas, legales y operativas. Para ello,
se identifican las necesidades que se ha de satisfacer y se estudia, si procede, la
situacin actual.
A partir del estado inicial, la situacin actual y los requisitos planteados, se estudian
las alternativas de solucin, dichas alternativas pueden incluir soluciones que
impliquen desarrollos a medida, soluciones basadas en la adquisicin de productos
software del mercado o soluciones mixtas. Una vez descritas cada una de las
alternativas planteadas, se valora su impacto en la organizacin, la inversin a
realizar en cada caso y los riesgos asociados. Esta informacin se analiza con el fin
de evaluar las distintas alternativas y seleccionar la ms adecuada, que defina y
establezca su planificacin.
Dentro del estudio de viabilidad se deben considerar las siguientes actividades:

Establecimiento del Alcance del Sistema

Estudio de la Situacin Actual

Estudio de Alternativas de Solucin

Valoracin de las Alternativas

Seleccin de la Solucin

Las principales tcnicas a utilizar para esta actividad se describen a continuacin:

Sesiones de trabajo

Entrevistas encuestas.

Observacin directa.

3.2.1.2. FASE 2: ANLISIS

Para una correcta definicin a esta fase se le ha subdivido en dos fases:
Especificacin de requisitos y anlisis de requisitos. La descripcin de cada una de
ellas se la hace en los siguientes apartados.
61

3.2.1.2.1. ESPECIFICACIN DE REQUERIMIENTOS

Esta etapa es la primera actividad que se debe realizar en el desarrollo de
un Sistema de Informacin. Comienza despus de que un usuario ha detectado una
ausencia, falla o falta de oportunidad de la informacin o simplemente, luego que
la organizacin ha determinado un cambio en sus polticas, reglas o tecnologas a
aplicar.
En esta etapa, se debe responder a una pregunta fundamental: Qu es lo que quiere
el usuario? y para ello, se debe diagnosticar la situacin actual, recopilar los
requerimientos del usuario, tanto en relacin al sistema, es decir la situacin ideal,
para as poder definir alternativas de solucin, segn las cuales se podr avanzar
desde lo que hoy se posee, hacia el punto que se pretende llegar. En esta etapa se
logra claridad sobre lo que desea el usuario y la forma en la cual se le va a presentar
la solucin a sus problemas.
Los requerimientos son parte fundamental en un sistema de informacin ya que
estos representan el conjunto completo de resultados a ser obtenidos una vez que se
utilice el sistema. Los requerimientos de sistemas deben mostrar todo lo que el
sistema debe hacer ms todas las restricciones sobre la funcionalidad. Los
requerimientos forman un modelo completo, donde el sistema total presente algn
nivel de abstraccin. (Sommerville, 2011).
De este modo se puede decir que un requerimiento es una condicin o capacidad a
la que el sistema debe conformar. Un requerimiento de software puede ser definido
como:
Una capacidad del software necesaria por el usuario para resolver un
problema o alcanzar un objetivo.
Una capacidad del software que debe ser reunida o poseda por un sistema
o componente del sistema para satisfacer un contrato, especificacin,
estndar, u otra documentacin formal.

62

Los requerimientos de usuario representan el conjunto completo de resultados a ser

obtenidos mediante el uso del sistema1. Los requisitos a tomarse en cuenta dentro
del MeDWCU estn definidos en la seccin 2.8.1 de este documento, estos
requisitos son:
Funcionales:
o Requisitos de Datos.
o Requisitos de Interfaz de Usuario.
o Requisitos Navegacionales.
o Requisitos de Personalizacin.
o Requisitos Transaccionales.
Requisitos no funcionales.
El proceso de especificacin de requisitos se puede dividir en dos grandes
actividades (Lowe & Hall, 1999): captura y definicin de requisitos. El proceso
comienza con la realizacin de la captura de requisitos, el grupo de tcnicos toma
la informacin suministrada por los usuarios y clientes. Esta informacin puede
provenir de fuentes muy diversas: documentos, aplicaciones existentes, a travs de
entrevistas, etc. En base a esta informacin, el equipo de desarrollo elabora el
catlogo de requisitos.
a) Captura de Requisitos
La captura de requisitos es la actividad mediante la que el equipo de desarrollo de
un sistema de software extrae, de cualquier fuente de informacin disponible, las
necesidades que debe cubrir dicho sistema (Dez, 2001).
A continuacin se presentan un grupo de tcnicas que de forma clsica han sido
utilizadas para esta actividad en el proceso de desarrollo de todo tipo de software.

Entrevistas: resultan una tcnica muy aceptada dentro de la especificacin

de requisitos y su uso est ampliamente extendido. Las entrevistas le

Requerimientos
http://www.galeon.com/zuloaga/Doc/AnalisisRequer.pdf

63

permiten al analista tomar conocimiento del problema y comprender los

objetivos de la solucin buscada. A travs de esta tcnica el equipo de
trabajo se acerca al problema de una forma natural. Existen muchos tipos de
entrevistas y son muchos los autores que han trabajado en definir su
estructura y dar guas para su correcta realizacin (Durn, Bernldez, Ruz
& Toro, 1999 y Pan, Zhu & Jonhson, 2001).
Bsicamente, la estructura de la entrevista abarca tres pasos: identificacin
de los entrevistados, preparacin de la entrevista, realizacin de la entrevista
y documentacin de los resultados (protocolo de la entrevista).

Casos de Uso: Aunque inicialmente se desarrollaron como tcnica para la

definicin de requisitos (Jacobson, 1995), algunos autores proponen casos
de uso como tcnica para la captura de requisitos (Pan, Zhu & Johnson, 2001
y Liu & Yu, 200). Los casos de uso permiten mostrar el contorno (actores)
y el alcance (requisitos funcionales expresados como casos de uso) de un
sistema. Un caso de uso describe la secuencia de interacciones que se
producen entre el sistema y los actores del mismo para realizar una
determinada funcin. Los actores son elementos externos (personas, otros
sistemas, etc.) que interactan con el sistema como si de una caja negra se
tratase. Un actor puede participar en varios casos de uso y un caso de uso
puede interactuar con varios actores.

Cuestionarios y Checklists: Esta tcnica requiere que el analista conozca

el mbito del problema a solucionar. Consiste en redactar un documento con
preguntas cuyas respuestas sean cortas y concretas, o incluso cerradas por
unas cuantas opciones en el propio cuestionario (Checklist). Este
cuestionario ser cumplimentado por el grupo de personas entrevistadas o
simplemente para recoger informacin en forma independiente de una
entrevista.

Existen ms tcnicas para la captura de requisitos (anlisis de otros sistemas,

estudio de la documentacin, etc.), incluso tambin es comn encontrar alternativas
que combinen varias de estas tcnicas (Pan, Zhu & Johnson, 2001). Sin embargo,
las presentadas ofrecen un conjunto representativo de las ms utilizadas y resultan
suficientes para este tipo de sistemas.
64

b) Definicin de requisitos
Tambin para la actividad de definicin de requisitos en el proceso de ingeniera de
requisitos hay un gran nmero de tcnicas propuestas. Describimos brevemente las
ms relevantes para este trabajo.

Lenguaje natural: Resulta una tcnica muy ambigua para la definicin de

los requisitos. Consiste en definir los requisitos en lenguaje natural sin usar
reglas para ello. A pesar de que son muchos los trabajos que critican su uso,
es cierto que a nivel prctico todava se lo usa.

Plantillas o patrones: Esta tcnica, recomendada por varios autores

(Durn, Bernldez, Ruz & Toro, 1999 y Escalona, Torres & Mejias, 2002),
tiene por objetivo el describir los requisitos mediante el lenguaje natural
pero de una forma estructurada. Una plantilla es una tabla con una serie de
campos y una estructura predefinida que el equipo de desarrollo lo cumple
a travs del lenguaje del usuario. Las plantillas eliminan parte de la
ambigedad del lenguaje natural al estructurar la informacin; cuanto ms
estructurada sea sta, menos ambigedad ofrece. Sin embargo, si el nivel de
detalle elegido es demasiado estructurado, el trabajo de rellenar las plantillas
y mantenerlas, puede ser demasiado tedioso.

Escenarios: La tcnica de los escenarios consiste en describir las

caractersticas del sistema a desarrollar mediante una secuencia de pasos
(Liu & Yu, 2001). La representacin del escenario puede variar segn el
autor. Esta representacin puede ser casi textual o ir encaminada hacia una
representacin grfica en forma de diagramas de flujo (Weidenhaupt, Pohl,
Jarke & Haumer, 1999). El anlisis de los escenarios, hechos de una forma
u otra, pueden ofrecer informacin importante sobre las necesidades
funcionales de sistema (Lowe & Hall, 1999).

Casos de uso: Como tcnica de definicin de requisitos es como ms

ampliamente han sido aceptados los casos de uso. Actualmente se ha
propuesto como tcnica bsica del proceso RUP (Kruchten, 1998). Sin
embargo, son varios los autores que defienden que pueden resultar
ambiguos a la hora de definir los requisitos (Dez, 2001 y Vilain, Schwabe

65

& Sieckenius, 2002 y Insfrn, Pastor & Wieringa, 2002), por lo que hay
propuestas que los acompaan de descripciones basadas en plantillas o de
diccionarios de datos que eliminen su ambigedad.
3.2.1.2.2. ANLISIS DE REQUISITOS
Dentro del proceso de anlisis es fundamental que a travs de una coleccin de
requerimientos funcionales y no funcionales, el desarrollador o desarrolladores del
software comprendan completamente la naturaleza de los programas que deben
construirse para desarrollar la aplicacin, la funcin requerida, comportamiento,
rendimiento e interconexin (Pressman, 2010).
Los requisitos una vez que han sido especificados necesitan ser analizados y
validados. La validacin de requisitos tiene como misin demostrar que la
especificacin de los requisitos define realmente el sistema que el usuario necesita
o el cliente desea (Lowe & Hall, 1999). Es necesario asegurar que el anlisis
realizado y los resultados obtenidos de la etapa de definicin de requisitos son
correctos. Pocas son las propuestas existentes que ofrecen tcnicas para la
realizacin de la validacin y muchas de ellas consisten en revisar los modelos
obtenidos en la definicin de requisitos con el usuario para detectar errores o
inconsistencias.
Para ello las tcnicas ms ptimas para este tipo de actividades se recomiendan
emplear las siguientes:

Reviews o Walk-throughs: Est tcnica consiste en la lectura y correccin

de la completa documentacin o modelado de la definicin de requisitos.
Con ello solamente se puede validar la correcta interpretacin de la
informacin transmitida. Ms difcil es verificar consistencia de la
documentacin o informacin faltante.

Auditoras: La revisin de la documentacin con esta tcnica consiste en

un chequeo de los resultados contra una checklist predefinida o definida a
comienzos del proceso, es decir slo una muestra es revisada.

66

Matrices de trazabilidad: Esta tcnica consiste en marcar los objetivos del

sistema y chequearlos contra los requisitos del mismo (Olsina, 1999). Es
necesario determinar qu objetivos cubre cada requisito, de esta forma se
podrn detectar inconsistencias u objetivos no cubiertos.

Prototipos: Algunas propuestas se basan en obtener de la definicin de

requisitos prototipos que, sin tener la totalidad de la funcionalidad del
sistema, permitan al usuario hacerse una idea de la estructura de la interfaz
del sistema con el usuario (Olsina, 1999). Esta tcnica tiene el problema de
que el usuario debe entender que va a observar un prototipo y no el sistema
final.

3.2.1.3. FASE 3: DISEO

De acuerdo con Pressman (2010), el diseo del software es realmente un proceso
de muchos pasos pero que se clasifican dentro de uno mismo. En general, la
actividad del diseo se refiere al establecimiento de las estructuras de datos, la
arquitectura general del software, representaciones de interfaz y algoritmos. El
proceso de diseo traduce requisitos en una representacin de software.
Esta fase contempla las siguientes etapas: Diseo Conceptual, Diseo Bsico,
Diseo Navegacional y Diseo de Interfaz abstracta. Cada una de estas etapas se
describe en los siguientes apartados.
a.

Diseo conceptual: Se construye un modelo orientado a objetos que

represente el dominio de la aplicacin mediante el uso de las tcnicas propias de la

orientacin a objetos. La finalidad principal durante esta fase es capturar el dominio
semntico de la aplicacin en la medida de lo posible, siempre que se tenga en
cuenta el rol de los usuarios y las tareas que desarrollan. El resultado de esta fase
es un modelo de clases relacionadas que se divide en subsistemas.
b.

Diseo Bsico: En esta fase se deben disear la base de datos y los

diccionarios de datos. Por diseo de base de datos se refiera a la actividad en la cual

se toman los requerimientos y especificaciones de la fase de anlisis y se determina
la mejor manera de satisfacerlos, segn las apreciaciones del Usuario y de la
persona que lo desarrolla, a travs de un diseo inicial de base de datos.

67

La finalidad del diseo de bases de datos es establecer, a partir del trabajo con los
usuarios, las lneas bsicas del sistema, principalmente en lo que respecta a
funcionalidad y estructura de la base de datos.
c.

Diseo Navegacional: En la fase de diseo navegacional se disea la

aplicacin que cumpla con las tareas que el usuario va a realizar sobre el sistema.
Para ello, hay que partir del esquema conceptual desarrollado en la fase anterior.
Hay que tener en cuenta que sobre un mismo esquema conceptual se pueden
desarrollar diferentes modelos navegacionales (cada uno de los cuales dar origen
a una aplicacin diferente).
Al ser una etapa heredada de la Metodologa OOHDM se toma una serie de clases
especiales predefinidas, que se conocen como clases navegacionales: Nodos,
Enlaces y Estructuras de acceso, que se organizan dentro de un Contexto
Navegacional. Mientras que la semntica de los nodos y los enlaces son comunes a
todas las aplicaciones hipermedia, las estructuras de acceso representan diferentes
modos de acceso a esos nodos y enlaces de forma especfica en cada aplicacin.
d.

Diseo de Interfaz abstracta: Una vez definida la estructura navegacional,

hay que prepararla para que sea perceptible por el usuario y esto es lo que se intenta
en esta fase. Esto consiste en definir qu objetos de interfaz va a percibir el usuario,
y en particular el camino en el cul aparecern los diferentes objetos de navegacin,
qu objeto de interfaz actuar en la navegacin, la forma de sincronizacin de los
objetos multimedia y el interfaz de transformaciones.
Al existir una clara separacin entre la fase anterior y esta fase, para un mismo
modelo de navegacin se pueden definir diferentes modelos de interfaces, de esta
forma la interfaz se ajustar mejor a las necesidades del usuario.
3.2.1.4. FASE 4: CONSTRUCCIN
Al culminar correctamente las actividades anteriores, la parte lgica de la
aplicacin ya estara totalmente desarrollada, sin embargo, esto para el usuario no
representa nada, ya que lo que el usuario desea es poder interactuar con el software
desarrollado a travs de las interfaces de usuarios. Por lo cual en esta fase, se

68

dedicar totalmente a la programacin y generacin del cdigo de la aplicacin, de

modo que la aplicacin sea presentada al usuario.
En esta fase se desarrollarn las siguientes actividades:
a) Preparacin del entorno de trabajo.
b) Preparacin de Templates.
c) Generacin de mdulos y componentes.
d) Carga inicial de datos.
3.2.1.5. FASE 5: IMPLEMENTACIN Y MANTENIMIENTO
Como su nombre lo indica, esta etapa corresponde a la implementacin de
la aplicacin realizada, ya sea de forma local o mediante un servicio de hosting, con
el fin de verificar si se han cumplido a cabalidad todos los requerimientos
establecidos en un principio por parte de los usuarios.
Las actividades correspondientes a esta fase son las siguientes:
a) Instalacin de servidores.
b) Pruebas y funcionamiento.
c) Aprobacin del Sistema.
Si el Sistema cumple de forma satisfactoria con las actividades mencionadas
anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas
del nuevo sistema, para de esta forma dar inicio al proceso de aceptacin final,
durante el cual, el sistema comenzar a funcionar bajo la responsabilidad del
usuario, por un lapso determinado de tiempo llamado Periodo de Aceptacin.
Finalizado el Periodo de Aceptacin, se le dar al sistema la aprobacin final, para
que pase a ser el sistema oficial.

69

CAPITULO IV
APLICACIN DE LA PROPUESTA METODOLGICA
MeDWCU PARA LA IMPLEMENTACIN DE SISTEMAS
WEB PARA LA GESTIN JURDICA SIGEJ
Esta seccin corresponde a la fase de aplicacin de la propuesta
metodolgica para el desarrollo de un Sistema Web para la Gestin Jurdica el
mismo que se lo implementar en el Estudio Peace Jurdica y en Departamento
Jurdico del MIES Chimborazo.
La Metodologa MeDWCU consta de las siguientes fases:
4.1.

Fase 1: Planificacin

4.1.1.

Visin General del Sistema

4.1.1.1. Situacin actual

Las instituciones consideradas para la implementacin del Sistema de
Gestin Jurdica SISGEJ son el Estudio Peace Jurdica y en Departamento Jurdico
del MIES Chimborazo, los cuales no disponen de un sistema informtico para la
gestin de los procesos jurdicos.
La informacin generada en estos despachos jurdicos se la maneja de forma
manual, tras revisar el registro de los casos tratados en estas instituciones se
constat que el nmero de clientes durante los aos 2012 y 2013 ha crecido en un
17,64%, lo cual ha trado como consecuencia los siguientes problemas:
Deficiente control y gestin de los casos jurdicos.
No se puede acceder a la informacin global de los casos que se llevan a
cabo en stas instituciones.

70

4.1.1.2. Identificacin del problema

Tabla 35. Identificacin del Problema de los despachos jurdicos.
PROBLEMA:

AFECTADOS:
IMPACTO:

SOLUCIN:

En los despachos jurdicos la gestin y el control de los casos que se tramitan se la

maneja de forma manual, lo cual ocasiona dificultades en la administracin de los
expedientes, de igual forma no se puede obtener informacin global de los casos
que se tramitan en determinados lapsos de tiempo.
Los abogados y dems personas que laboran dentro de los despachos jurdicos.
Aumento del tiempo que se dedica a la gestin de los casos, retrasos en el
cumplimiento de las actividades de gestin y control, y la imposibilidad de explotar
la informacin para generar una visin global de los casos gestionados.
Implementacin de un Sistema de Gestin Jurdica que apoye los procesos y
actividades de los despachos jurdicos. El sistema ser capaz de reducir el tiempo
dedicado a la gestin de los casos, permitir un control eficaz de las actividades que
se realizan en los casos, tener la capacidad de explotar la informacin de los caso
para presentar una visin global de los mismos.

Elaborado por: ngel Cudco

4.1.1.3. Perspectivas del producto

El sistema de gestin y control de un despacho jurdico permitir la gestin
eficiente de la informacin de los casos, clientes, operadores de justicia,
participantes, actividades y materias. Adems se podr controlar las fechas de
cumplimiento de las diligencias y los plazos de los trminos e instrucciones fiscales,
adems generar reportes de los casos por su estado o ltima actividad.
a) Caractersticas del sistema
El sistema a desarrollar deber disponer de las siguientes funcionalidades:
Tabla 36. Caractersticas del sistema.
MDULO

FUNCIONALIDADES

DESCRIPCIN
Permitir el registro, actualizacin y

Gestin de Casos

eliminacin de la informacin que

tiene un caso.
Permitir asignar participantes al caso

Asignacin de participantes

como por ejemplo actor, demandado y

abogado contrario del caso

CASOS
Asignacin de una materia

Permitir asignar una materia

relacionada con un caso.

Asignacin de un operador de

Permitir asignar un operador de

justicia

justicia donde se tramitar el caso.

Asignacin de una etapa

71

Permitir asignar una etapa nueva al

caso. Cada etapa aade un nuevo

operador de justicia, nmero de causa

y grado.
Permitir buscar los casos que estn

Bsqueda de casos

asignados a un cliente especfico.

Permitir generar reportes de los casos

Reportes

por su estado o ltima actividad

Permitir el registro, actualizacin y
eliminacin de la informacin de los

Gestin de Clientes

clientes segn sea el tipo de cliente

natural o jurdico.

CLIENTES

Permitir realizar la bsqueda de los

clientes por su cedula y sus nombres si

Bsquedas

es natural o ruc y razn social si es

jurdico
Permitir el registro, actualizacin y

Gestin de operadores de justicia

operadores de justicia.

OPERADORES DE
JUSTICIA

eliminacin de la informacin de los

Bsqueda de operadores de
justicia

Permitir realizar la bsqueda de los

operadores de justicia por su nombre
de operador y lugar o jurisdiccin.
Permitir el registro, actualizacin y

Gestin de materia

eliminacin de la informacin de la
materia

MATERIA

Permitir realizar la bsqueda de las

Bsquedas

materias por su tipo de materia y

objeto de materia
Permitir el registro, actualizacin y

Gestin de participantes

eliminacin de la informacin de Los

participantes del caso.

PARTICIPANTES

Permitir realizar la bsqueda de los

DEL CASO
Bsqueda de participantes

participantes del caso por su cedula y

sus nombres si es natural o ruc y razn
social si es jurdico.
Permitir el registro, actualizacin y

Gestin de actividades

eliminacin de las actividades del caso

que se realizan en un operador de
justicia

ACTIVIDADES
Asignacin de actividades al
operador de justicia

Permitir ingresar actividades a un

operador de justicia donde
actualmente se est tramitando el caso

72

Permitir consultar los diversos tipos

Consulta de actividades

de actividades del caso como

diligencias, trminos y normales.
Permitir consultar las diligencias que

Control de diligencias

se tienen que realizar en los casos

segn una fecha determinada.
Permitir consultar los trminos de los
casos donde se mostrar cuanto

Control de trminos

tiempo resta para concluir el plazo

asignado a la actividad.
Permitir consultar las instrucciones

Control de instrucciones fiscales

fiscales de los casos donde se

mostrar cuanto tiempo resta para
concluir la duracin de la actividad.

Elaborado por: ngel Cudco

b) Caractersticas de los usuarios del sistema

Abogado: Educacin superior, conocimiento y experiencia en la gestin y
control de los casos.
Ayudante: Educacin superior, ayuda a las labores o actividades del
despacho jurdico como realizacin de las tareas que implica las actividades
y gestin de las carpetas de los casos.
4.1.1.4. Cronograma de Actividades

73

Tabla 37. Cronograma de Actividades del desarrollo del sistema.

TIEMPO ESTIMADO (SEMANAS)

ACTIVIDADES
1

10

11

1 PLANIFICACION
Visin del Sistema
Estudio de Viabilidad
2 ANLISIS
Especificacin de requisitos
Anlisis de Requisitos
3 DISEO
Arquitectura de la Informacin
Diseo de Bases de Datos
Diseo Navegacional
Diseo de Interfaz abstracta
4 CONSTRUCCIN
Preparacin del Entorno de
Trabajo.
Creacin de Mdulos y
Templates
5 IMPLEMENTACIN
Instalacin de servidores
Pruebas
Caraga inicial de datos
Aprobacin del SI

Elaborado por: ngel Cudco

74

12

13

14

15

16

17

18

19

20

21

22

23

24

25 26

4.1.2.

Estudio de Viabilidad
En este apartado se evalan las condiciones tcnicas, operativas y

econmicas que pueden asegurar el cumplimiento de las metas y objetivos del

presente sistema, y as, determinar su viabilidad; para lo cual se consideran las
siguientes:
-

Viabilidad tcnica

Viabilidad Operativa

Viabilidad econmica

Cada de estas viabilidades se desglosan en los siguientes apartados.

4.1.2.1. Viabilidad tcnica
La actividad fundamental de este apartado consiste en realizar una
evaluacin de la tecnologa existente en la organizacin, el estudio est destinado a
recolectar informacin sobre los componentes tcnicos que posee la organizacin y
la posibilidad de hacer uso de los mismos en el desarrollo e implementacin del
sistema propuesto y de ser necesario, los requerimientos tecnolgicos que deben ser
adquiridos para el desarrollo y puesta en marcha del sistema en cuestin. La
evaluacin se la realiz bajo dos enfoques: hardware y software.
a) Hardware
En cuanto a Hardware, se hace referencia al servidor donde debe estar instalado
el sistema propuesto, este debe cubrir con los siguientes requerimientos mnimos:
Procesador Pentium 166 Mhz.
64 MB de Memoria RAM
Disco Duro de 5 GB.
Unidad de CD-ROM
Tarjeta de Red.
Tarjeta de Vdeo.
Monitor SVGA.
Teclado.

75

 Mouse.
A continuacin se presentan los equipos que disponen las instituciones:
Tabla 38. Equipos de cmputo del despacho Peace Jurdica.
Nombre de
Equipo

Responsable

Fecha de
Adquisicin

Sistema
Operativo

Procesador

Memoria
Instalada

Disco Duro

PEACE1

Abg. Paul
Centeno

01/03/2013

Windows 7
Ultimate 64 bits

Intel Core i7,

280 Ghz

4 Gb

Samsung
931.51 Gb

PEACE2

Secretaria

15/08/2010

Windows 7
Ultimate 32 bits

Intel DUAL
Core 2.70 Ghz

2 Gb

Samsung
500 Gb

PEACE3

Pasante

01/03/2010

Windows 7
Ultimate 32 bits

Intel Core 2
Duo, 2.93 Ghz

2Gb

Samsung
500 Gb

Elaborado por: Angel Cudco

Al evaluar el hardware existente y tomar en cuenta la configuracin mnima

necesaria, las instituciones beneficiarias no necesitan realizar una inversin inicial
para la adquisicin de nuevos equipos, tampoco para repotenciar o actualizar los
equipos existentes, ya que los mismos satisfacen los requerimientos establecidos
tanto para el desarrollo y puesta en funcionamiento del sistema propuesto.
b) Software
En cuanto al software, las instituciones beneficiarias cuentan con todos los
utilitarios y herramientas de oficina necesarias para el correcto funcionamiento del
sistema SIGEJ, lo cual no amerita inversin alguna para la adquisicin de los
mismos. Para el desarrollo del Sistema SIGEJ se emple Microsoft Asp.Net, ya que
la UNACH posee las licencias Microsoft - Campus Agreement y por consiguiente
no es necesario adquirir software adicional.
Para el uso general del sistema mencionado anteriormente es recomendable instalar
cualquiera de los distintos navegadores que actualmente existen en el mercado, tales
como Firefox, Chrome o Internet Explorer.
Conclusin: Como resultado de este estudio tcnico se determin que en los
actuales momentos, las instituciones poseen la infraestructura tecnolgica
(Hardware y Software) necesaria para el desarrollo y puesta en funcionamiento el
sistema propuesto.

76

4.1.2.2. Viabilidad operativa

Se examina a continuacin el ajuste entre las necesidades que se pueden
identificar segn la problemtica y la solucin a dichas necesidades a travs de los
indicadores de efectividad, confiabilidad y facilidad de uso.
a)

Efectividad del sistema: Para materializar de alguna manera la efectividad

del sistema, se lista en la Tabla 40 un conjunto de caractersticas que resuman la

capacidad del mismo y que demuestren de qu manera se consiguen beneficios.
Tabla 39. Resumen de Capacidades del Sistema
Beneficio

Caractersticas que lo soportan

Mayor facilidad para la gestin de la

informacin de los procesos

Mantenimiento y constante actualizacin

de procesos, as como carga y descarga de
documentos relacionados. Al igual que
reportes, estadsticas y consultas de los
diferentes casos.

Informacin de usuarios actualizada

Los abogados pueden realizar un mejor
seguimiento de los casos de los que se
encarga
Mejor asignacin de los casos que se
presentan en el estudio de abogados

Seguridad de la informacin
Los clientes podrn tener un acceso a su
expediente sin necesidad de acercarse a la
instancia judicial respectiva
Mayor control de las fases de un caso.
Delegacin de responsabilidades
Consultas Jurdicas
Gestin de eventos programados
Elaborado por: ngel Cudco

77

Actualizacin constante de registros e

informacin de abogados y clientes.
Administracin de procesos, consultas de
estados y monitoreo del detalle de los
mismos a travs de un registro histrico
de las acciones realizadas por los
participantes en cada caso.
Asignacin de un proceso registrado a un
abogado segn carga procesal, materia,
etc.
Definicin de un conjunto de perfiles para
los usuarios del sistema con niveles de
acceso.
Consulta del proceso que enfrenta un
cliente as como de toda la documentacin
adjunta, mediante una seccin de clientes
en el SIGEJ.
Control de las etapas y flujos de trabajo
de los casos.
Asignacin de tareas con fechas y alarmas
al vencimiento de la tarea programada.
Repositorio de datos del cdigo civil,
penal, entre otros que puedan ser de
utilidad.
Registro de entradas en agenda con
alarmas

b)

Confiabilidad del sistema: Los criterios utilizados para parametrizar la

confidencialidad son: validacin de usuarios, control de acceso y registro de

accesos. En la siguiente tabla se detallan los criterios utilizados:
Tabla 40. Mecanismos de confiabilidad del sistema.
MECANISMO

DESCRIPCIN
Solamente aquellos usuarios con los permisos adecuados

Validacin de

pueden actualizar o solo visualizar los procesos de los

usuarios

casos que se estn efectuando.

El acceso al sistema de informacin de gestin jurdica

Control de acceso

estar basado en perfiles y roles.

Los accesos a los expedientes o asuntos mantendrn un
registro que incluya, al menos, la identificacin del

Registro de accesos

usuario, la fecha y hora en la que se realiz el acceso, el

tipo de acceso y si ha sido autorizado o denegado.

Elaborado por: ngel Cudco

c)

Facilidad de uso: De acuerdo con Pressman (2010) los factores que se

deben considerar para permitir al usuario la facilidad de uso de un sistema de

informacin son los siguientes:
Tabla 41. Factores que determinan la facilidad de uso del sistema.
FACTORES

DESCRIPCION
Los contenidos deben cargarse en una media de 4

Rapidez

segundos. Los usuarios lo ms que esperarn en ver

los contenidos es una media de 10 segundos
Los usuarios no necesitan aprender diversos caminos

Simplicidad

o esquemas para la navegacin en diversas partes del

sistema.

Que se pueda aprender

Se refiere al esfuerzo que requiere aprender a usar un

fcilmente

sistema (regla de los 10 minutos).

Que

sea

fcil

de

recordar cmo se usa

Consistencia
estandarizacin

Se refiere al esfuerzo que requiere recordar un

sistema despus de que se haya aprendido como se
usa y no se haya utilizado durante un tiempo.

Evitar

que

diferentes

palabras,

acciones

situaciones tengan el mismo significado.

Elaborado por: ngel Cudco

78

Los usuarios requieren una capacitacin convencional, es decir, como la que se

realizara al instalar un sistema cualquiera, puesto que para el uso del mismo se
requieren conocimientos bsicos de computacin. Por otro lado, el entorno grfico
simple, sencillo y amigable dar al usuario una sensacin de seguridad en el manejo
del sistema.
4.1.2.3. Viabilidad econmica
Para estimar un costo referencial del sistema, se toman en cuenta factores
laborales y no laborales. Entre los primeros se consideran el costo por hora de
trabajo. Los factores no laborales se centran en los conceptos extra como son
movilidad, servicios y materiales, etc.
Factores Laborales
Actividades

Horas

Costo ($5/h)

Planificacin

40

200,00

Anlisis

80

400,00

Diseo

80

400,00

160

800,00

Implementacin

20

100,00

Pruebas

20

100,00

400

2000,00

Construccin

Total

Factores no laborales
Concepto

Detalle

Movilidad

Costo ($)
200,00

Servicios

Materiales

Infraestructura

Luz

100,00

Internet

200,00

Telfono

10,00

tiles de oficina

100,00

Impresiones

100,00

Mobiliario

100,00

Oficina

100,00

Imprevistos

91,00
Total

1001,00

TOTAL ($)

3001,00
Figura 30. Viabilidad econmica.

79

Una vez que se han analizado los costos totales para el desarrollo del Sistema
SIGEJ, se concluye que el desarrollo del mencionado sistema es factible
econmicamente ya que se cuenta con los factores tanto laborales y no laborales,
adems del conocimiento y la disponibilidad para llevar a cabo dicho proyecto.
Cabe recalcar que el proyecto es autofinanciado por parte del investigador.
4.1.2.4. Anlisis Costo Beneficio
Luego de haber presentado la viabilidad tcnica, operativa y econmica a
continuacin se realizar un anlisis el cual deber reflejar el porqu del desarrollo
del sistema, es decir, de qu manera contribuye y qu ofrece para que sea
justificable su implementacin.
Para determinar la Relacin Costo-Beneficio se aplic el Mtodo COCOMO a
travs de la herramienta COCOMO II, la cual arroj los siguientes resultados.

Figura 31. Relacin Costo - Beneficio con COCOMO II.

Fuente: ngel Cudco

4.2.

Fase 2: Anlisis
El sistema ayuda en la gestin y control de un caso el cual implica el

mantenimiento de su informacin, recuperacin, asignacin de informacin

relacionada con el caso como materia, operadores de justicia y participantes.
80

Adems proporciona reportes sobre el estado de los casos o por la ltima actividad
realizada.
Antecedentes
Previo al anlisis realizado, se han podido detectar los siguientes problemas:

Casos: Se lleva registro manual sin un formato adecuado para la

informacin de los casos que gestiona el despacho jurdico, que no permite
su fcil manejo. Adems se tiene que realizar un inventario manual de los
casos para obtener el estado que se encuentran y su ltima actividad lo cual
es un proceso que consume mucho tiempo.

Clientes: Se lleva un registro manual sin un formato adecuado de los

clientes del despacho jurdico, que no permite su eficiente gestin.

Operadores de justicia: Se lleva un registro manual sin un formato

adecuado de los operadores de justicia donde se tramita el caso, que no
permite su eficiente gestin.

Materias: Se lleva un registro manual sin un formato adecuado de las

materias que pueden tener los casos, que no permite su eficiente gestin.

Participantes del caso: Se lleva un registro manual sin un formato

adecuado de los participantes del caso, que no permite su eficiente gestin.

Actividades: Se archiva informacin de las actividades correspondiente a

un caso lo que dificulta la gestin eficiente de las mismas.
Adems se podr controlar los tipos de actividades como diligencias donde
se debe controlar la fecha de cumplimiento de la actividad, trminos donde
se tiene supervisar el plazo y en las instrucciones la duracin.

Etapas: No se registra informacin de las etapas que se encuentra un caso

lo cual no permite controlar adecuadamente el caso.

81

4.2.1.

Especificacin de requisitos

5.2.1.1. Requisitos Funcionales

Tabla 42. Requisitos funcionales.

Cdigo Nombre

Descripcin

Req001

Gestin de Casos

Permite
el
ingreso,
actualizacin y eliminacin
de los datos de un caso

Req002

Asignacin de
participantes al caso

Permite la asignacin de un
cliente, oponente y abogado
contrario a un caso

Req003

Asignacin de una
materia al caso

Req004

Asignacin de un
operador de justicia
al caso

Req005

Asignacin de una
etapa al caso

Req006

Bsqueda de casos

Permite recuperar los casos

que tiene asignado un
cliente.

Generacin de
reportes

Permite generar reportes de

casos que maneja el
despacho por su estado o
ltima actividad realizada,
auditoria,
trminos,
diligencias, instrucciones
fiscales
y
actividades
realizadas por el gestor.

Req008

Gestin de clientes

Permite ingresar, actualizar

y eliminar los datos de un
cliente natural o jurdico.

Req009

Bsqueda de clientes

Permite recuperar los la

informacin
relacionada
con un cliente.

Req010

Gestin de
operadores de justicia

Permite ingresar, actualizar

y eliminar operadores de
justicia.

Req007

Permite asignar de una

materia relacionada con el
caso.
Permite asignar operadores
de justicia donde el caso
ser tramitado.
Permite recuperar los casos
que tiene asignado un
cliente.

82

Entradas
Se registrar: la fecha de inicio,
estado, nmero de causa y grado del
caso.
Asigna: participantes, materia y
operadores de justicia al caso
Se asigna: los participantes como
cliente, oponente y abogado
contrario y se escoger un rol de
actor/ofendido
o
demandado/imputado para el cliente
y oponente y el rol de abogado
oponente para el abogado contrario.
Se asigna: el tipo y objeto de
materia para un caso.
Se asigna: el nombre del operador
de justicia y su lugar (jurisdiccin).
Se registra: un nmero de causa y
grado al caso. Adems se asigna un
operador de justicia.
Se ingresar: cdula y nombres si
es cliente es una persona natural o
ruc y razn social si es una persona
jurdica para recuperar un cliente y
sus casos relacionados.
Se escoge el estado del caso:
archivado o trmite, clase de
actividad instruccin, trmino,
diligencia y nombre y apellido del
gestor.
Se registrar: la cdula, nombres,
correo, direccin si es una persona
natural o ruc, razn social y
representante si es una persona
jurdica.
Se ingresar: cdula y nombres si
es cliente es una persona natural o
ruc y razn social si es una persona
jurdica para recuperar un cliente.
Se registrar: nombre, lugar,
responsable, tipo de responsable
(juez o fiscal) y encargado del
operador de justicia.

Cdigo Nombre

Descripcin

Entradas

Permite la recuperacin de
los datos de un operador de
justicia.
Permite ingresar, actualizar
y eliminar las materias.

Se ingresar: el nombre del

operador o lugar para realizar la
bsqueda.
Se ingresar: tipo de materia y
objeto de la materia.
Se ingresar: el tipo de materia u
objeto de materia para realizar la
bsqueda.
Actividad normal se registran:
fecha de inicio, tipo y descripcin de
la actividad.
Diligencia se registran: fecha de
inicio, tipo, alarma da, alarma hora,
descripcin de la actividad y fecha
de cumplimiento.
Trmino se registran: fecha de
inicio, tipo, alarma da y descripcin
de la actividad, fecha de inicio y
finalizacin del trmino.

Req011

Bsqueda de
operadores de justicia

Req012

Gestin de materia

Req013

Bsqueda de materia

Permite la recuperacin de
los datos de una materia

Req014

Gestin de
actividades

Permite
ingresar,
actualizar,
eliminar
y
buscar la informacin de las
actividades del caso.

Req015

Asignacin de
actividades al
operador de justicia

Req016

Control de
diligencias

Req017

Control de trminos

Req018

Control de
instrucciones fiscales

Permite
mostrar
los
diversos
tipos
de
actividades que tiene un
caso con un operador de
justicia.
Permite ver las diligencias
de los casos con su hora,
cliente,
operador
de
justicia,
materia,
descripcin de la actividad.
Permite ver los trminos de
los casos con sus das de
plazo, cliente, operador de
justicia,
materia,
descripcin de la actividad.
Permite
ver
las
instrucciones fiscales de los
casos con duracin, cliente,
operador
de
justicia,
materia, responsable (juez o
fiscal).

Se escoge: tipo de actividad:

normal, diligencia, trmino, estado,
tipo y gestor.

Se ingresar: La fecha de la
diligencia para la cual se quiere
realizar la consulta

Elaborado por: ngel Cudco

5.2.1.2. Requerimientos no funcionales

a) Requisitos de Rendimiento
El sistema debe responder de inmediato (2-3 segundos) a las interacciones del
usuario. El sistema debe permitir acceso concurrente a la informacin de los casos.

83

4.2.2.

Anlisis de Requisitos
Una vez finalizada la identificacin y especificacin de los requerimientos

del sistema, la siguiente actividad a realizar es el anlisis de cada uno de estos

requerimientos mediante el Modelo de Casos de usos.
Este aparatado proporciona una vista coherente de los casos de uso y los actores del
sistema as como los lmites del sistema. Los casos de uso son ponderados y
priorizados.
4.2.2.1. Actores
Actores son seres humanos con sus diferentes roles de usuario u otros
sistemas que se comunican con el sistema de gestin y control de un despacho
jurdico. El tipo de actor determina su peso. Esto puede variar entre 1 y 3, donde
los ltimos resultan ser ms complejos. Un actor humano, interacta por medio de
una (grfica) interfaz de usuario se cuenta con un peso de 3. Una interfaz basada en
un protocolo cuenta con un peso de 2 y una interfaz de programacin como 1. Los
pesos son usados como base para el anlisis de los puntos de caso de uso.
Tabla 43. Actores del Sistema
Actor

Abogado

Ayudante

Descripcin
Gestionar y controlar la informacin que se genere en un
caso.
Gestionar las actividades que se generen en el despacho.

Peso

Elaborado por: ngel Cudco

4.2.2.2. Casos de Uso

Un caso de uso describe la interaccin de un actor con el sistema. Esta
interaccin nos conduce a un objetivo cual es significativo para el actor o experto
en la materia.
Un caso de uso tiene un peso. Este puede variar entre 1 y 3, donde el ltimo valor
es el ms complejo. El peso es determinado por la cantidad y complejidad de los
escenarios de un caso de uso. Los pesos son usados como base para el anlisis de
84

puntos de casos de uso. La ltima columna constituye la tabla de estados de

prioridad de negocio de los casos de uso. Se trata de un vehculo para el orden de
realizacin. Las letras usadas son las consonantes en la palabra MoSCoW, que
significa lo siguiente:

M MUST: Debe tener, este caso de uso es indispensable para el sistema

al ser til o ser vlido para el caso del negocio.

S SHOULD: Debera tener, este caso de uso es necesario.

C COULD: Podra tener, este caso de uso agrega valor, pero sin este
el sistema todava no sera til.

W - WON'T: Es deseable que tenga pero no lo tendr esta vez, Este

caso de uso no ser construido en esta iteracin de desarrollo de software.

Una distribucin correcta presentara un mximo del 70% de casos de caso con
prioridad Debe Tener dentro del mbito de un release.

Prioridad

Tabla 44. Modelo de casos de uso del sistema.

Nombre del Caso de
Uso

Descripcin

CU01

Acceder al sistema

Como un abogado del bufete, quiero acceder al

sistema de modo pueda realizar las diferentes tareas
del despacho jurdico.

Gestionar persona
natural

Como un abogado del bufete, quiero ingresar,

actualizar y borrar personas naturales que tienen
una relacin con el despacho y el caso de modo que
pueda realizar la gestin eficiente de dicha
informacin.

Gestionar persona
jurdica

Como un abogado del bufete, quiero ingresar,

actualizar y borrar personas jurdicas que tienen una
relacin con el despacho y el caso de modo que
pueda realizar la gestin eficiente de dicha
informacin.

Buscar persona natural

Como un abogado del bufete, quiero buscar los

tipos de personas naturales por su id persona o
nombres de modo que pueda realizar diversas
operaciones.

CU02

CU03

CU04

Peso

Cdigo

85

Prioridad

Descripcin

Buscar persona jurdica

Como un abogado del bufete, quiero buscar los

tipos de personas jurdicas por su id persona o
nombres de modo que pueda realizar diversas
operaciones con dicha informacin.

CU06

Gestionar Materia

Como un abogado del bufete, quiero ingresar,

actualizar y borrar las materias que puede tener un
caso de modo que pueda realizar una gestin
eficiente de dicha informacin.

CU07

Gestionar Operadores
de Justicia

Como un abogado del bufete, quiero ingresar,

actualizar y borrar los operadores de justicia donde
puede tramitar un caso de modo que pueda realizar
una gestin eficiente de dicha informacin.

CU8

Buscar materia

Como un abogado del bufete, quiero buscar

materias por su tipo de materia u objeto de materia
de modo que pueda realizar diversas operaciones
con dicha informacin.

CU9

Buscar operador de
justicia

Como un abogado del bufete, quiero buscar

operadores de justicia por su nombre de operador y
lugar de modo que pueda realizar diversas
operaciones con dicha informacin.

CU10

Gestionar Caso

Como un abogado del bufete, quiero ingresar,

actualizar y borrar casos de modo que pueda
realizar la gestin eficiente de dicha informacin.

CU11

Asignar una materia al

caso

Como un abogado del bufete, quiero asignar una

materia a un caso de modo que pueda realizar la
gestin eficiente del caso.

CU12

Asignar participantes a
un caso

Como un abogado del bufete, quiero asignar

participantes a un caso de modo que pueda realizar
la gestin eficiente del caso.

CU13

Asignar un operador de
justicia al caso

Como un abogado del bufete, quiero asignar un

operador de justicia a un caso de modo que pueda
realizar la gestin eficiente del caso.

CU14

Buscar caso asignado a

un cliente

Como un abogado del bufete, quiero buscar casos

asignados a un cliente por su id persona, nombres o
ruc segn sea el cliente natural o jurdico modo que
pueda realizar diversas operaciones.

CU05

Peso

Nombre del Caso de

Uso

Cdigo

86

Prioridad

Nombre del Caso de

Uso

Descripcin

CU15

Gestionar operador de
justicia relacionado con
un caso

Como un abogado del bufete, quiero agregar,

eliminar y actualizar operadores de justicia,
nmeros de causa y grados a un caso de modo que
pueda realizar una gestin eficiente de dicha
informacin.

CU16

Gestionar actividades
del caso con el
operador de justicia

Como un abogado del bufete, quiero agregar,

eliminar, y actualizar actividades realizadas de un
operador de justicia asignado al caso de modo que
pueda realizar una gestin eficiente de dicha
informacin.

CU17

Aadir diversos tipos

de archivos a las
actividades del caso

Como abogado del bufete, quiero aadir archivos

tipo pdf, doc y jpg a las actividades del caso para
realizar una gestin eficiente.

CU18

Controlar instrucciones
fiscales de los casos

Como un abogado del bufete, quiero revisar las

instrucciones fiscales de los casos de modo que
pueda controlar eficaz de dicha informacin.

CU19

Controlar diligencias de
los casos

Como un abogado del bufete, quiero revisar las

diligencias de los casos por su fecha de
cumplimiento de modo que pueda controlar eficaz
de dicha informacin.

CU20

Controlar trminos de
los casos

Como un abogado del bufete, quiero revisar los

trminos de los casos de modo que pueda controlar
eficaz de dicha informacin

CU21

Generar reporte de
casos por su estado.

Como un abogado del bufete, quiero generar un

reporte de los casos por su estado de modo que
pueda tener una visin global de los casos por ese
criterio.

CU22

Generar reporte de
casos por su ltima
actividad.

Como un abogado del bufete, quiero generar un

reporte de los casos por su ltima actividad
realizada de modo que pueda tener una visin
global de los casos por ese criterio.

CU23

Gestionar usuario

Como un abogado del bufete, quiero ingresar,

actualizar y borrar usuarios del sistema de modo
que pueda realizar una gestin eficiente de dicha
informacin.

CU24

Buscar usuario

Como un abogado del bufete, quiero buscar

usuarios por su id persona de modo que pueda

Peso

Cdigo

87

Descripcin

realizar diversas
informacin.

operaciones

con

Prioridad

Nombre del Caso de

Uso

Peso

Cdigo

dicha

CU25

Establecer alarmas de
las actividades

Como abogado del bufete, quiero establecer

alarmas a las actividades para realizar un
seguimiento efectivo.

CU26

Generar reporte de
actividades del caso

Como abogado del bufete, quiero generar un reporte

de actividades del caso para tener una visin global
de los casos y sus actividades.

CU27

Generar reporte
actividades asignadas al
gestor.

Como abogado del bufete, quiero generar un reporte

de actividades asignadas al gestor para tener una
visin global de los casos y sus actividades.

CU28

Generar reporte de
control de diligencias,
trminos e
instrucciones.

Como abogado del bufete, quiero generar un reporte

de control de diligencias, trminos e instrucciones
para tener una visin global de los casos y sus
actividades.

Elaborado por: ngel Cudco

Nota: se integraron los casos de uso CU19, CU27 y CU29 con el CU18 (Gestionar
actividades del caso con el operador de justicia).
4.2.2.3. Diagramas de Casos de Usos
En esta seccin el Modelo de Casos de Uso descritos en la Tabla 45 se
expresan en los Diagramas de casos de uso agrupados en los mdulos que
conforman el sistema.

Figura 32. Caso de Uso: Acceder al Sistema.

Fuente: ngel Cudco

88

Figura 33. Casos de Uso: Mdulo Clientes.

Fuente: ngel Cudco

Figura 34. Casos de Uso: Mdulo Casos.

Fuente: ngel Cudco

Figura 35. Casos de Uso: Mdulo Operadores de Justicia.

Fuente: ngel Cudco

89

Figura 36. Casos de Uso: Mdulo Materia.

Fuente: ngel Cudco

Figura 37. Casos de Uso: Mdulo Reportes.

Fuente: ngel Cudco

4.3.

Diseo

4.3.1. Arquitectura de la Solucin

En esta seccin se detalla la arquitectura que se emplea en la aplicacin para
lo cual primero se indica el tipo de arquitectura elegida. Luego se presenta el diseo
de la arquitectura de alto nivel que se utiliza en la solucin, esto implica dividir la
aplicacin en componentes funcionales posicionados en capas, las cuales tambin
son detalladas.

90

4.3.1.1. Representacin de la arquitectura

La arquitectura a utilizar ser Web. Se distinguen dos secciones, el cliente,
donde se encuentra el usuario del sistema y que acceder a la aplicacin por medio
de un navegador (Internet Explorer o Mozilla Firefox), y la segunda seccin la
conforma el servidor, en donde residen los datos, las reglas y lgica de la misma.
Uno de los motivos por los que se realiza una aplicacin Web es porque se sabe que
este tipo de aplicaciones emplean light clients, que son clientes que no ejecutan
demasiadas labores de procesamiento para la ejecucin de la misma aplicacin, lo
cual es un punto esencial ya que lo que menos se desea es que en la seccin cliente
se realicen demasiadas tareas, solo las necesarias para que el usuario final pueda
acceder a la aplicacin y realizar el trabajo deseado.
El auge de las redes locales y la popularidad de Internet han posibilitado el acceso
a travs de computadores y otros dispositivos mviles, ha aumentado y extendido
el empleo de las aplicaciones Web las cuales pueden ser utilizadas por usuarios
ubicados en cualquier lugar del planeta con acceso a Internet.

Figura 38. Diagrama de Arquitectura del SIGEJ

Fuente: ngel Cudco

91

4.3.1.2. Diseo de la arquitectura de la solucin

Se elige MVC2 porque es un patrn de diseo muy recomendado para
aplicaciones interactivas de Asp.Net. Separa los conceptos de diseo por lo que
minimiza la duplicacin de cdigo, el control centralizado y permite que la
aplicacin sea ms extensible. Asimismo permite enfocarse en la lgica de negocio,
es decir, las funcionalidades a implementar ya que los detalles del manejo de la
presentacin de la aplicacin son cubiertas por MVC.
Se elige NHibernate3 porque, a travs de los mapeos Object/Relational, se
consigue una persistencia de datos poderosa y de alta performance. NHibernate
soporta la mayora de los sistemas de bases de datos SQL, lenguaje en el cual se
encuentra la base de datos del sistema. Una de las principales ventajas de
NHibernate es ofrecer facilidades para la recuperacin y actualizacin de datos y
control de transacciones.
4.3.1.3. Vista Lgica
La siguiente figura muestra la vista lgica de la arquitectura, la cual detalla
las capas a utilizar.

El Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos
y la lgica de negocio de una aplicacin de la interfaz de usuario y el mdulo encargado de gestionar
los eventos y las comunicaciones.
3
NHibernate es la conversin de Hibernate de lenguaje Java a C# para su integracin en la
plataforma .NET.

92

Figura 39. Vista Lgica del SIGEJ

Fuente: ngel Cudco

Se han definido tres capas dentro de las cuales se dividir todo el sistema:

Capa de Presentacin (Vista): Esta capa es la responsable de la

visualizacin del sistema, es decir de la parte que interactuar con el usuario.
Tendr como patrn de diseo MVC, el cual provee de libreras para los
controladores de interfaz y soporta distintas tecnologas para el desarrollo
de las vistas.

Capa de lgica de negocios: Esta capa presenta una "interfaz" para brindar
servicios a la capa de presentacin, en esta capa se incluye a los servicios
que proveern los mtodos que tpicamente representarn a un caso de uso,
es decir, que implementarn las funcionalidades deseadas. Esta capa reduce
el nmero de llamadas requeridas al sistema, lo cual hace ms fcil su uso.
En entornos remotos, esto mejora dramticamente la performance.

La capa de acceso a datos: Esta capa es una porcin de cdigo que

justamente realiza el acceso a los datos. De esta manera cuando es necesario
cambiar el motor de base de datos, solamente se tendr que corregir esa
capa. Mientras que la capa de datos (en el nivel de datos) es donde estn

93

los datos y se corresponde directamente con la definicin de esquemas,

tablas, vistas, procedimientos almacenados y todo lo que se pueda o deba
poner en un motor de base de datos.
La realizacin de todos los casos de uso determinados para el sistema est
comprendida por mdulos y una base de datos (SQL). Cada uno de estos mdulos
contiene 4 tipos de clases (Web, Servicios, Modelo y las de Acceso a Base de datos).

Clases Web (web): Contiene las clases controladoras.

Clases de Servicios (service): Las clases que se encargan del manejo de las
clases del negocio. Son una especie de nexo entre la interfaz de usuario y
los objetos de negocio.

Clases de Modelo (model): Las clases que representan las entidades del
modelo de negocio. Contienen todos los datos del sistema. Ejemplos de
estas clases son Usuario, Proceso, Abogado, etc.

Clases de Acceso a Base de Datos (dao): Las clases que proporcionan la

comunicacin con la Base de Datos del Sistema.

4.3.1.4. Vista de despliegue

La vista de despliegue muestra las relaciones fsicas de los nodos que participan en
la ejecucin y de los componentes hardware y software que residen en ellos.

Cliente: En este nodo se hace uso de un navegador de Internet para que los
usuarios puedan acceder al sistema a travs de computadoras personales.

Servidor Web: Este nodo se encarga de manejar la lgica del negocio. El

equipo usuario se conecta a l para obtener los datos que requiere para
completar sus procesos.

Servidor BD: Este nodo contiene el servidor de base de datos del sistema.

94

Figura 40. Diagrama de despliegue del SIGEJ.

Fuente: ngel Cudco

4.3.1.5. Vista de implementacin

Esta vista describe la estructura total del modelo de implementacin, la
descomposicin del software en capas y subsistemas. Seguir el patrn Model View
Controller (MVC), el cual plantea la siguiente divisin:
Capa View: Esta capa maneja las clases que permiten la interaccin del
usuario con el sistema.
Capa Controller: Esta capa permite manejar la lgica del negocio de todos
los mdulos involucrados.
Tabla 45. Descripcin de los Componentes de la Capa Controller.
COMPONENTE
Gestin

Cliente

Seguimiento

Reportes

Seguridad

DESCRIPCIN
Este componente tiene todas las clases referentes a la
gestin del sistema (maestros).
Este componente contiene todas las clases
relacionadas a las funcionalidades a las que pueden
acceder los clientes del estudio de abogados dentro del
sistema.
Este componente contiene todas las clases
relacionadas a todas las acciones que se pueden
realizar en el sistema para realizar el seguimiento de
los procesos.
Este componente contiene todas las clases
relacionadas al control de las actividades de los
abogados por parte de su jefe.
Este componente contiene las clases correspondientes
a la seguridad, mantenimiento y a la validacin de
usuarios del Sistema.

Elaborado por: ngel Cudco

95

 Capa Model: Esta capa representa la realidad. Representa a las entidades

de negocio y a las clases encargadas de la persistencia de la informacin.
4.3.2. Diseo de Bases de datos
4.3.2.1. Modelo entidad relacin

Figura 41. Diagrama E - R.

Fuente: ngel Cudco

A continuacin se describen cada una de las entidades mostradas en la Figura 41.

Caso: Trmino general utilizado para definir al proceso judicial relacionado

con un cliente, que el despacho jurdico gestiona.
Cliente: Persona natural o jurdica que requiere los servicios del despacho
jurdico.
Materia: Trmino general que definira a los diversos tipos de materia que
tendr un caso.
Actividad: Trmino que define a la persona colabora en la gestin del
despacho jurdico.
Operador de Justicia: Institucin de la funcin judicial donde se trmitara
el caso.

96

4.3.2.2. Diagrama de Base de Datos

Figura 42. Diagrama de Base de datos.

97

4.3.2.3. Diagrama de clases

Figura 43. Diagrama de Clases.

98

4.3.3. Diseo Navegacional

4.3.3.1. Diagramas de Navegacin

Figura 44. Diagrama de Navegacin.

Fuente: ngel Cudco

4.3.3.2. Mapa del Sitio

INICIO
CONOSCANOS
OFERTA DE
SERVICIOS
SIGEJUR
NUESTROS
CLIENTES
CONTACTENOS

Cliente

Consultas
Mdulo Clientes

LOGIN

Mdulo Casos
Usuarios
Mdulo Reportes
Administracin

Figura 45. Mapa del Sitio del Sistema de Gestin Jurdica.

Fuente: ngel Cudco

99

4.3.4. Diseo de Interfaz Abstracta

Figura 46. Interfaz Abstracta.

Fuente: ngel Cudco

4.4.

Construccin

4.4.1. Preparacin del entorno de trabajo

Esta fase consta de las siguientes actividades:
a) Instalacin del Sistema operativo base.
b) Instalacin del IDE de desarrollo: Visual Studio Profesional 2013.
c) Instalacin del servidor de bases de datos: SQL Server 2012.
Ver Anexo 1.
4.4.2. Creacin de Templates.
El SIGEJ consta de las siguientes TEMPLATES:
-

Plantilla para el inicio de sesin.

Plantilla del sitio web.

100

Ver Anexo 2.
4.4.3. Creacin de Mdulos y Componentes.
El SIGEJ dispone de los siguientes mdulos:
-

Clientes

Casos

Operador de justicia

Recursos Humanos

Configuracin

Ver Anexo 3.
4.5.

Implementacin y Mantenimiento
a) Instalacin del servidor IIS 8.
b) Preparacin de la IP Pblica a utilizar.
c) La

aplicacin

puede

verse

http://190.152.181.70/sigej
Ver Anexo 4.

101

en

la

siguiente

direccin:

CAPITULO V
METODOLOGA
5.1.

TIPO DE ESTUDIO
Para la realizacin del presente trabajo se tomaron a consideracin varios

tipos de investigacin, los mismos que se detallan a continuacin:

5.1.1. Segn el objeto de estudio:

Investigacin de Campo: debido al proceso de recoleccin de los

requisitos de software y a la evaluacin de eficiencia y satisfaccin de los
usuarios.

5.1.2. Segn la fuente de investigacin:

Investigacin bibliogrfica: debido a los medios en los cuales est

sustentada la fase terica del presente documento, stos medios son: libros,
revistas, publicaciones, tesis, etc.

5.1.3. Segn las variables:

Investigacin Descriptiva: debido a que mide y evala diversos aspectos,

dimensiones o componentes del fenmeno a investigar.

5.2.

POBLACIN Y MUESTRA

5.2.1. Poblacin
La poblacin est constituida por las personas que se involucraron en la
aplicacin de la metodologa es decir la Comunidad de desarrolladores de sistemas
informticos basados en la web y los despachos jurdicos de la ciudad de Riobamba.

102

5.2.2. Muestra
La muestra que se tom corresponde al personal que conforman el
Departamento Jurdico del MIES Chimborazo y el Despacho Peace Jurdica, por
tratarse de una poblacin relativamente pequea el valor de la misma es igual a la
Poblacin.
5.3.

OPERACIONALIZACIN DE VARIABLES
A travs de la utilizacin de las variables establecidas se precisan las

dimensiones e indicadores que resultan relevantes para obtener el resultado

esperado al momento de medir la propuesta metodolgica planteada y la
funcionalidad del Sistema Web en la Gestin Jurdica.

103

Tabla 46. Operacionalizacin de las variables.

Variable

Tipo

Definicin conceptual

Independiente

Conjunto de procedimientos
basados en principios lgicos,
utilizados para alcanzar una gama
de objetivos que ayuden a
disminuir la complejidad y el
tiempo en el desarrollo de
sistemas informacin web para la
gestin jurdica.

Dimensin

Indicadores
Ciclo de vida.

Propuesta metodolgica

Disminuir
la Caractersticas
de
la
complejidad y el tiempo metodologa.
en el desarrollo.
Diseo de la Informacin
Componentes reusables
y colaborativos.
Cumplimiento de normas.
Tiempo de desarrollo.
Usabilidad.

Incidencia en el desarrollo
eficiente de sistemas que
representen a la organizacin
Dependiente
y sus objetivos y apoyar a sus
procesos.

Acoplamiento
Capacidad de obtener resultados mdulos
deseados en los recursos de
informacin, mediante la ptima Independencia
utilizacin de los recursos mdulos
disponibles.
Eficiencia

entre
Accesibilidad.
entre Simplicidad.
Funcionalidad.
Experiencia del Usuario.

Elaborado por: ngel Cudco

104

5.4.

PROCEDIMIENTOS

5.4.1. Fuentes de Informacin.

Entre las fuentes de informacin consta la Primaria y Secundaria:
a)

Primarias.- Esta informacin se obtendr basndose en la

Observacin y Conversacin con el gerente de la empresa,
trabajadores.

b)

Secundarias.- Las fuentes secundarias se obtendr de folletos,

revistas, trpticos relativos al tema, as como del Internet.

5.4.2. Tcnicas de investigacin.

Las tcnicas de investigacin utilizadas en el presente trabajo se
describen a continuacin:
a) Documental: Permite la recopilacin de informacin para enunciar
las teoras que sustentan el estudio de los fenmenos y procesos.
Incluye el uso de instrumentos definidos segn la fuente documental
a que hacen referencia.
b) De Campo: Permite la observacin y el contacto directo con el objeto
de estudio.
5.4.3. Instrumentos de recoleccin de datos.
Los instrumentos utilizados para la recoleccin de datos del presente
trabajo de investigacin fueron los siguientes:
La observacin
Entrevista
Cuestionarios
Encuesta.

105

5.5.

PROCESAMIENTO Y ANLISIS.

5.5.1. Teora fundamentada en datos.

La teora fundamentada en datos es un mtodo de investigacin
cualitativa que ayuda en la colecta, anlisis sistemtico de datos y en la
generacin de la teora.
En el desarrollo de esta tesis este mtodo se ha utilizado para precisar la
colecta y el anlisis general de los datos pertinentes a su ordenacin en cuanto
a los criterios econmicos, tcnicos y en cuanto al anlisis de datos.
5.5.2. Anlisis de tareas
En este proceso se describir las tareas realizadas actualmente por los
usuarios, sus patrones definidos de flujo de trabajo, los cuales se originan de
sus esquemas mentales y las necesidades de informacin para realizar su
trabajo. Es decir, se procura identificar qu el usuario hace, de qu manera
lo hace, y qu necesita para hacerlo. De esa manera, se logra el
entendimiento conceptual de las tareas que debern formar parte del sistema
en desarrollo. Para la obtencin de dicho entendimiento se pueden utilizar
varias tcnicas tales como entrevistas, observacin sistemtica, etc.
5.6.

COMPROBACIN DE HIPTESIS
Para la comprobacin de la Hiptesis planteada para el desarrollo de

la Tesis se utilizan las tablas resumen (Tabla 14, Tabla 15, Tabla 25, Tabla
26 y Tabla 27) del estudio comparativo realizado en la seccin 2.8 del
presente trabajo de investigacin, las mismas que permiten conocer el
desempeo de cada una de las metodologas y as saber cul es la mejor y que
ayude a cumplir con la hiptesis.
Mediante la valoracin de los parmetros establecidos en el estudio
comparativo de la seccin 3.5, se definir si existe la necesidad de desarrollar
una nueva metodologa de desarrollo web o es suficiente con las metodologas

106

estudiadas (OOHDM, WSDM, EORM y SOHDM), para posteriormente

aceptar o negar la hiptesis.
La comprobacin de la Hiptesis se la realiza mediante la prueba de Chi
Cuadrado y Matrices relacionales, donde el primer paso es definir la hiptesis
nula e hiptesis de investigacin.
Hi: El desarrollo de una propuesta metodolgica para la implementacin de
sistemas de informacin web diseados y centrados en los usuarios incidir
en el desarrollo eficiente de sistemas informticos acorde a los objetivos y
procesos de la organizacin.
Ho: El desarrollo de una propuesta metodolgica para la implementacin de
sistemas de informacin web diseados y centrados en los usuarios no
incidir en el desarrollo eficiente de sistemas informticos acorde a los
objetivos y procesos de la organizacin.
5.6.1. Nivel de Significancia
Una vez establecida la hiptesis de investigacin y la nula, se debe
determinar el nivel de significancia, que para el caso del presente anlisis se
utiliza un nivel de significacin estadstica del 10% (0,1), para obtener un
nivel de confianza aceptable.
5.6.2. Clculos
Para obtener los datos se emplea la tabla resumen:
Tabla 47. Tabla Resumen.

WSDM
SOHDM
OOHDM
EORM
TOTAL

REQUISITOS
13
11
15
7
46

FASES
17
10
20
9
56

CARACTERISTICAS
6
6
4
2
18

TOTAL
36
27
39
18
120

Elaborado por: ngel Cudco

Al utilizar la frmula de Chi Cuadrado se obtiene la matriz de frecuencias

esperadas.
107

Tabla 48. Matriz de frecuencias esperadas.

REQUISITOS
13,8
10,35
14,95
6,9

WSDM
SOHDM
OOHDM
EORM

FASES
16,8
12,6
18,2
8,4

CARACTERISTICAS
5,4
4,05
5,85
2,7

Elaborado por: ngel Cudco

Con estos datos se procede a calcular la matriz del valor estadstico de prueba
de Chi Cuadrado:
2

( )2
=

Donde:
2

=
=
Tabla 49. Matriz con los valores estadsticos de prueba de Chi Cuadrado.

WSDM
SOHDM
OOHDM
EORM

REQUISITOS
0,046376812
0,040821256
0,000167224
0,001449275

FASES
CARACTERISTICAS
0,002380952
0,066666667
0,536507937
0,938888889
0,178021978
0,585042735
0,042857143
0,181481481

Elaborado por: ngel Cudco

Finalmente los datos de la matriz anterior para determinar el valor de Chi

Cuadrado Calculado, para lo cual se emplea la siguiente frmula:

( )2
=
= 2,62066234892322

=1

108

Como sucede con las distribuciones estadsticas t y F, la distribucin Chi

Cuadrado tiene una forma que depende del nmero de grados de libertad
asociados a un determinado problema.
Para obtener un valor crtico (valor que deja un determinado porcentaje de
rea en la cola) a partir de una tabla de Chi Cuadrado, se debe seleccionar un
nivel de significancia y determinar los grados de libertad para el problema
que se vaya a resolver.
Los grados de libertad son una funcin del nmero de casillas de la matriz en
estudio. Es decir, los grados de libertad reflejan el tamao de la tabla. Los
grados de libertad de la columna son el nmero de filas (categoras) menos 1,
o bien, (r 1). Los grados de libertad de cada fila es igual al nmero de
columnas (muestras) menos 1, o bien, (k 1). El efecto neto es que el nmero
de grados de libertad para la tabla es el producto de (nmero de filas -1) por
(nmero de columnas -1), o bien, (r - 1)(k 1). Por lo tanto con 4 filas y 3
columnas, los grados de libertad son:
gl = (r 1)*(k 1 )
gl = (4 1)*(3 1) = (3)(2)
gl = 6
De acuerdo a la tabla estadstica de distribucin Chi Cuadrado, con un nivel
de significancia 0,10 a 6 grado de libertad, genera un valor de = 10.6446.

Figura 47. Distribucin Chi Cuadrada

109

5.6.3. Decisin
La prueba Chi Cuadrado requiere la comparacin del con el .
Si el valor estadstico de prueba es menor que el valor tabular, la hiptesis
nula es aceptada, caso contrario, Ho es rechazada.
En este caso: < , < ,

Figura 48. Aceptacin de la Hiptesis de Investigacin.

Fuente: ngel Cudco

Por lo tanto se rechaza la Ho y se acepta la Hi (Hiptesis de investigacin).

110

CAPITULO VI
RESULTADOS Y DISCUSIN

6.1.

RESULTADOS

6.1.1. ANLISIS

DE

RESULTADOS

DEL

ESTUDIO

COMPARATIVO DE LAS METODOLOGAS.

La comparacin de las metodologas de desarrollo de sistemas de informacin
web es una tarea difcil. El foco de cada metodologa puede ser diferente,
algunas tratan de concentrarse en varios aspectos del proceso de desarrollo,
otras tratan de detallar en profundidad algn aspecto en particular como por
ejemplo el tratamiento de requisitos. En los apartados 7.1.1.1, 7.1.1.2 y
7.1.1.3 se presentan los resmenes de la comparacin de las metodologas
EORM, SOHDM, OOHDM y WSDM, extrada del apartado 3.5, es
recomendable tener en cuenta los pasos que componen el proceso, la tcnica
de modelado, la representacin grfica, la notacin elegida para los modelos
y la herramienta CASE de soporte proporcionada para el desarrollo.
6.1.1.1. Tratamiento de Requisitos
Del estudio comparativo realizado en el apartado 3.5.1 se puede
observar que ninguna de las metodologas estudiadas cumple en un 100% el
tratamiento de requisitos para el diseo de sistemas de informacin web
basados y centrados en los usuarios planteados por Lamas (2009).
En la Tabla 50 se puede observar que la Metodologa OOHDM cumple en un
50% el tratamiento de requisitos y tiene una ligera ventaja frente a las dems
metodologas en estudio, estas son WSDM con un 43%, SOHDM con un 37%
y la metodologa EORM apenas un 23%.

111

Tabla 50. Anlisis del tratamiento de requisitos por parte de las metodologas EORM,
WSDM, SOHDM y OOHDM.
Datos

Interfaz
Usuario

Navegacionales

Personalizacin

Transaccionales

No
PROMEDIO
Funcionales

WSDM

80%

0%

0%

100%

0%

80%

43%

SOHDM

60%

60%

0%

0%

100%

0%

37%

OOHDM

100%

100%

100%

0%

0%

0%

50%

EORM

80%

60%

0%

0%

0%

0%

23%

Elaborado por: ngel Cudco

Los resultados de la tabla anterior de muestran grficamente en la siguiente

figura:

CUMPLIMIENTO DE
REQUISITOS DE DATOS

ANLISIS DEL CUMPLIMIENTO DE

REQUISITOS DE DATOS
50%
43%
37%
23%

WSDM

SOHDM

OOHDM

EORM

METODOLOGAS

Figura 49. Resultado comparativo de las metodologas segn el Tratamiento de Requisitos.

Fuente: ngel Cudco

6.1.1.2. Fases del ciclo de vida

Dentro del estudio de las metodologas WSDM, SOHDM, OOHDM y EORM,
se obtuvo la mayor ponderacin para la metodologa OOHDM, sin embargo esta
dos metodologas son aplicadas para proyectos con diferencias de duracin es
decir EORM es para proyectos cortos y que se deseen con rapidez OOHDM es
para desarrollos de software ms complejos y de mayor duracin.
Los resultados del estudio comparativo se representan la siguiente figura.
OOHDM se ajusta con el 86% frente a EORM con el 73%.

112

Tabla 51. Resultado comparativo de las metodologas segn los Ciclo de vida de desarrollo
del software.
WSDM

SOHDM

OOHDM

EORM

PLANIFICACION
ESTRATGICA

0%

0%

0%

0%

ESTUDIO DE
VIABILIDAD

0%

0%

0%

0%

ESPECIFICACIN
REQUERIMIENTOS

80%

0%

100%

0%

ANLISIS DE
REQUISITOS

100%

80%

100%

60%

FASES
1.

PLANIFICACIN
DEL SISTEMA

2. ANLISIS DEL
SISTEMA
3.

DISEO

80%

60%

100%

60%

4.

CONSTRUCCION

60%

40%

80%

40%

5.

IMPLEMENTACION Y MANTENIMIENTO

80%

60%

80%

60%

57%

34%

66%

31%

PROMEDIO

Elaborado por: ngel Cudco

Estos resultados se pueden observar de mejor manera en la siguiente figura:

ANLISIS DE LA COMPARATIVA DE LAS FASES
DEL CICLO DE VIDA DE DESARROLLO DEL
SOFTWARE
66%
57%

34%

31%

METODOLOGA METODOLOGA METODOLOGA METODOLOGA

WSDM
SOHDM
OOHDM
EORM
METODOLOGAS

Figura 50. Resultado comparativo de las metodologas segn los Ciclo de vida de
desarrollo del software.
Fuente: ngel Cudco

6.1.1.3. Caractersticas
Segn varios autores presentan varias caractersticas que deben tener una
metodologa dentro del diseo web centrado en el usuario. Despus del estudio
comparativo los resultados son los siguientes: las Metodologas WSDM y
SOHDM cumplen el 75% de las caractersticas propuestas por Lamas (2009)

113

para el diseo web centrado en el usuario, mientras que la metodologa OOHDM

cumple el 50% y la metodologa EORM cumple el 25% de las caractersticas.
Tabla 52. Resultado comparativo de las metodologas segn las caractersticas de las
metodologas.

Elaborado por: ngel Cudco

Fuente: ngel Cudco

Los resultados obtenidos en la Tabla 53, se explican grficamente en la siguiente

figura:

Figura 51. Resultado comparativo de las metodologas segn las caractersticas de las
metodologas.
Fuente: ngel Cudco

6.1.2. ANLISIS DE LA PROPUESTA METODOLGICA MeDWCU

FRENTE A LAS OTRAS METODOLOGAS.
De los apartados anteriores se puede observar que ninguna de las
metodologas consideradas en el estudio comparativo cumple en un 100% los
parmetros de evaluacin de dicho estudio, es ah en donde la propuesta
114

metodolgica MeDWCU adopta los aspectos ms relevantes de cada una de las

metodologas en estudio.
a)

Requisitos tratados

La propuesta metodolgica MeDWCU cumple el 100% de los requisitos

considerados dentro del diseo web centrado en el usuario, es decir para el
tratamiento de los requisitos de datos, interfaz de usuario y requisitos
navegacionales se basa en la metodologa OOHDM, para el tratamiento de los
requisitos de personalizacin y requisitos no funcionales se basa en la
metodologa WSDM y finalmente para el tratamiento de los requisitos
transaccionales se basa en la metodologa SOHDM.
Tabla 53.Resultado comparativo segn el tratamiento de requisitos de la Propuesta
Metodolgica MeDWCU frente a las dems Metodologas en estudio.
METODOLOGA

Datos

Interfaz
Usuario

Navegac.

Personalizac.

Transac.

No
PROMEDIO
Funcionales

WSDM

80%

0%

0%

100%

0%

80%

43%

SOHDM

60%

60%

0%

0%

100%

0%

37%

OOHDM

100%

100%

100%

0%

0%

0%

50%

EORM

80%

60%

0%

0%

0%

0%

23%

PROPUESTA

100%

100%

100%

100%

100%

100%

100%

Elaborado por: ngel Cudco

En la siguiente figura se muestra de forma grfica los resultados obtenidos en la

tabla anterior.

Figura 52. Resultado comparativo segn el tratamiento de requisitos de la Propuesta

Metodolgica MeDWCU frente a las dems Metodologas en estudio.
Fuente: ngel Cudco

115

b) Fases del Ciclo de vida

Dentro las fases del ciclo de vida ninguna de las metodologas en estudio
contaban con una fase de planificacin preliminar del sistema a desarrollar, razn
por la cual MeDWCU incorpora la fase de Planificacin del Sistema la cual
consta de dos sub-fases: Planificacin estratgica y Estudio de viabilidad que
tienen por objetivo establecer una visin preliminar del proyecto de software a
desarrollar. MeDWCU fusiona las fases de Especificacin de requisitos y
Anlisis de requisitos para dar origen a la fase de denominada Anlisis del
Sistema.
Tabla 54. Resultado comparativo segn las fases del Ciclo de Vida de Desarrollo de Software
por parte de las Metodologas estudiadas y la Propuesta Metodolgica MeDWCU.
FASES
1.

2.

PLANIFICACIN
DEL SISTEMA

ANLISIS DEL
SISTEMA

WSDM

SOHDM

OOHDM

EORM

MeDWCU

0%

0%

0%

0%

100%

0%

0%

0%

0%

100%

80%

0%

100%

0%

100%

100%

80%

100%

60%

100%

PLANIFICACION
ESTRATGICA
ESTUDIO DE
VIABILIDAD
ESPECIFICACIN
REQUERIMIENTO
S
ANLISIS DE
REQUISITOS

3.

DISEO

80%

60%

100%

60%

100%

4.

CONSTRUCCION

60%

40%

80%

40%

100%

5.

IMPLEMENTACION Y
MANTENIMIENTO

80%

60%

80%

60%

100%

57%

34%

66%

31%

100%

PROMEDIO

Elaborado por: ngel Cudco

Los resultados de la Tabla 54 se muestran grficamente en la siguiente figura.

Figura 53. Resultado comparativo segn las fases del Ciclo de Vida de Desarrollo
de Software por parte de las Metodologas estudiadas y la Propuesta
Metodolgica MeDWCU.
Fuente: ngel Cudco

116

c)

Caractersticas
Las metodologas SOHDM y WSDM cumplen el 75% de las caractersticas

planteadas por Lamas (2009) en el diseo web centrado en el usuario, es ah

donde la propuesta metodolgica MeDWCU se basa en las metodologas
mencionadas previamente y agrega el tratamiento de la accesibilidad y el diseo
de la informacin.
En la Tabla 55 se muestra el resumen del cumplimiento de las caractersticas por
parte de las metodologas en estudio y la propuesta metodolgica MeDWCU,
mientras que en la Figura 54 se muestra de forma grfica el resultado
comparativo segn las caractersticas del diseo web centrado en el usuario.
Tabla 55. Resultado comparativo segn las caractersticas de las Metodologas
estudiadas y de la Propuesta Metodolgica MeDWCU.

Elaborado por: ngel Cudco

Figura 54. Resultado comparativo segn las caractersticas de las Metodologas estudiadas
y de la Propuesta Metodolgica MeDWCU.

117

6.2.

DISCUSIN
La siguiente discusin est basada en los resultados obtenidos del

anlisis de las metodologas OOHDM, WSDM, SOHDM y EORM orientadas

a la desarrollo e implementacin de sistemas de informacin web y la
funcionalidad del portal para con los usuarios.
6.2.1. ANLISIS DE LAS METODOLOGAS EORM, WSDM,
SOHDM Y OOHDM.
EORM es una metodologa sencilla, que asume la orientacin a objetos como
paradigma para el desarrollo de aplicaciones para la web. Con ello se
garantizan todas las ventajas que la orientacin a objetos ofrece, pero adems
aumenta las posibilidades de reutilizacin en las aplicaciones, gracias a la
definicin del repositorio o libreras de clases enlace.
EORM tambin es adecuada para el diseo web porque, sigue la idea inicial
de HDM, separa la navegacin de lo conceptual. Esto garantiza la
reutilizacin y un mantenimiento ms fcil. Si hay un cambio en la
navegacin, lo conceptual no se modifica. Por otro lado, la aplicacin de la
metodologa EORM puede resultar bastante sencilla gracias al uso de
ODMTool, una herramienta desarrollada por el propio autor de EORM. Esta
herramienta se usa de forma conjunta con el generador comercial de
interfaces grficas de usuario, ONTOS Studio y con un sistema gestor de base
de datos orientado a objetos, de manera que se permite el diseo interactivo
de esquemas EORM y la generacin automtica de cdigo, inicialmente en
C++.
A pesar de todas estas ventajas, a EORM se le pueden hacer ciertas crticas.
Por un lado, el proceso metodolgico que propone resulta insuficiente en
muchos casos principalmente porque solo trata de manera especfica los
aspectos de almacenamiento y navegacin, deja de lado temas como la
funcionalidad del sistema o los aspectos de interfaz. Adems, en ningn
momento comenta las tcnicas a seguir para obtener los modelos que propone
o los productos que se deben generar en el desarrollo.
118

EORM tambin deja a un lado un aspecto muy importante en la mayora de

las aplicaciones: la captura de requisitos. No slo no ofrece ninguna propuesta
sino que no indica ninguna que se pueda usar.
En conclusin, EORM es la primera propuesta orientada a objetos. Es
necesario tenerla en cuenta a la hora de realizar una propuesta por las ideas
que ofrece y por los modelos que plantea, que resultan muy adecuados para
representar la navegacin y lo conceptual. Pero deja a un lado aspectos que
son crticos en el ciclo de desarrollo.
OOHDM es sin duda una de las metodologas que ms aceptacin tiene en el
desarrollo de aplicaciones multimedia. Actualmente sirve como base para el
desarrollo de nuevas propuestas metodolgicas para los sistemas de
informacin web. (Olsina, 1999)
OOHDM es una propuesta basada en el diseo, que ofrece una serie de ideas
que han sido asumidas por bastantes propuestas y que han dado muy buenos
resultados. La primera de ellas es que hace una separacin clara entre lo
conceptual, lo navegacional y lo visual. Esta independencia hace que el
mantenimiento de la aplicacin sea mucho ms sencillo. Adems, es la
primera propuesta que hace un estudio profundo de los aspectos de interfaz,
esencial no solo en las aplicaciones multimedia, sino que es un punto crtico
en cualquiera de los sistemas que se desarrollan actualmente.
OOHDM hace uso tambin de la orientacin a objetos y de un diagrama tan
estandarizado como el de clases, para representar el aspecto de la navegacin
a travs de las clases navegacionales: ndices, enlaces y nodos. Esta idea ha
dado muy buenos resultados y parece muy adecuada a la hora de trabajar.
Sin embargo, y a pesar de esto, OOHDM presenta algunas deficiencias.
OOHDM ha dejado fuera de su mbito un aspecto esencial que es el
tratamiento de la funcionalidad del sistema. El qu se puede hacer en el
sistema y en qu momento de la navegacin o de la interfaz se puede hacer,
es algo que no trata y que lo deja como tarea de implementacin.

119

Adems, OOHDM no ofrece ningn mecanismo para trabajar con mltiples

actores. Por ejemplo, imaginemos que la interfaz y la navegacin de la
aplicacin varan sustancialmente segn quin se conecte a la aplicacin. El
diagrama navegacional, los contextos navegacionales y los ADVs resultaran
muy complejos para representar esta variabilidad. Otra propuesta de OOHDM
que no parece adecuada es la de los contextos navegacionales.
En resumen, OOHDM ofrece una serie de ideas muy adecuadas a la hora de
plantear una metodologa de desarrollo que tenga en cuenta la navegacin y
la interfaz. Existen muchos ejemplos desarrollados mediante OOHDM que
pueden servir al momento de ver la viabilidad de estas ideas. Sin embargo,
hay que limitar el uso de esta propuesta a aplicaciones sencillas en las que la
complejidad funcional sea mnima.
La metodologa WSDM en principio puede ser bastante interesante en el
sentido de que ofrece una nueva visin al tratamiento de los usuarios. Es una
metodologa totalmente orientada a disear la aplicacin en base a los grupos
de usuarios desde el principio. Sin embargo, no comenta nada sobre aspectos
que pueden resultar importante considerar esta idea. Por ejemplo, puede ser
que la misma informacin se presente a dos usuarios de forma diferente.
Adems, como sus propios autores indican, solo sirve para desarrollar
sistemas web estticos, es decir, aplicaciones que muestren informacin. Esta
propuesta no trabaja aspectos como la funcionalidad, la seguridad, etc.
necesarias en los sistemas web. Se centra solo en cmo presentar la
informacin al usuario.
SOHDM es hasta ahora la nica propuesta que tiene en cuenta aspectos como
la especificacin de requisitos mediante el uso de los escenarios. Es una
propuesta bastante interesante pues cubre todas las fases del proceso de
desarrollo, sin tomamr en cuenta la implantacin y las pruebas.
SOHDM es una metodologa joven que no ha sido muy usada an. Tiene
como ventaja que es un proceso sencillo de seguir, aunque se le puede criticar

120

el hecho de que su nomenclatura est muy cerrada. Por ejemplo, para el

desarrollo de la interfaz se define cmo se representa una imagen o un botn
en el modelo, aunque no se dice nada de cmo se representa un elemento de
audio, sin dejar ninguna opcin a que el diseador pudiese definir su propia
representacin.

121

CAPITULO VII
CONCLUSIONES Y RECOMENDACIONES

7.1.

CONCLUSIONES
La Propuesta Metodolgica para el Desarrollo Web Centrado en el
Usuario MeDWCU define claramente la sistemtica que debe seguir
un proyecto de desarrollo de sistemas web desde su etapa inicial hasta su
culminacin, adopta las caractersticas ms destacadas de las
metodologas OOHDM, EORM, SOHDM y WSDM que segn Escalona
(2001) son las usadas con mayor frecuencia en la actualidad; se centra en
la arquitectura que relaciona la toma de decisiones e indica cmo debe
ser construido el sistema y en qu orden; se desarrolla bajo un enfoque
iterativo e incremental que divide el proyecto en fases (mini proyectos)
donde cada una de ellas cumple sus objetivos de manera depurada,
ajustndose a las caractersticas del desarrollo web debido a la
importancia proporcionada al usuario y al anlisis de requerimientos que
este demanda.

La MeDWCU proporciona y se centra en caractersticas esenciales

para el desarrollo del proyecto de sistemas de entorno web como:
usabilidad, accesibilidad, experiencia de usuario, diseo de la
informacin y navegacional, sin olvidar los criterios de confiabilidad,
disponibilidad, extensibilidad, escalabilidad, testeabilidad y seguridad; el
sistema a desarrollar debe adaptarse al continuo cambio tecnolgico y a
la aparicin de nuevos requisitos por parte de la institucin beneficiaria
del sistema; adems frente al continuo crecimiento de usuarios internos
y externos es necesario facilitar la realizacin de pruebas y proveer
mecanismos de seguridad.

122

Los procesos y mtodos de evaluacin utilizados para realizar el estudio

comparativo de las metodologas de Diseo Web OOHDM, EORM,
SOHDM y WSDM en donde se combin aspectos fundamentales de
Escalona (2001), Lamas (2009) y Koch(2000), permitieron estructurar de
manera concreta las fases (mini proyectos) de MeDWCU las mismas
que cumplen objetivos esenciales dentro de un proyecto de software para
la web y la aplicacin de sta permiti desarrollar de forma eficiente el
Sistema de Gestin Jurdica SIGEJ.

Se desarroll e implement un Sistema de Informacin Jurdica robusto

y confiable, con una slida y estable base de datos que integra la
informacin de los abogados que laboran en el estudio jurdico, clientes,
de los casos y de sus respectivas actividades y diligencias.

La correcta utilizacin del SIGEJ incide en la eficiencia de procesos de

gestin jurdica, para lo cual se aplic una arquitectura N-Capas que
permite desarrollar un software flexible a los procesos jurdicos definidos
en el Vademcum Procedural, no slo porque minimiza los dichos
procesos, sino porque adems permite realizar un seguimiento de los
casos y respaldar toda la informacin generada.

Se seleccion la tecnologa de desarrollo Web ASP.NET ya que brinda

las ventajas de: code-behind, velocidad en tiempos de respuesta,
seguridad, robustez, facilidad de mantenimiento, herramientas de trabajo,
cache, carpetas especializadas para una funcin especfica, adaptacin
automtica de cdigo a los dispositivos que lo acceden, utilizacin de
Master Pages, compatibilidad con XML y servicios web, utilizacin de
mltiples lenguajes complementarios.

123

7.2. RECOMENDACIONES

Socializar la propuesta metodolgica MeDWCU con el fin de lograr

nuevos recursos de informacin que se ajusten a las necesidades de los
diferentes usuarios independientemente del tipo de actividad que realicen
y de las tecnologas que se empleen para la correcta implementacin de
informacin que represente los objetivos de la empresa y de esta forma
apoyar sus procesos.

Las fases de una metodologa no son un ciclo de pasos que se deben

seguir al pie de la letra, en caso de que el ciclo de desarrollo no describa
un amplio alcance se debe recurrir a un modelo de desarrollo de software
o a un estndar internacional para cubrir dichas necesidades, adems
resulta primordial establecer, determinar y definir los flujos de
informacin alternativos que permita precisar los requerimientos no
funcionales y aspectos propios del usuario como la navegacin y el
diseo grfico.

Desarrollar nuevos mdulos para el SIGEJ los mismos que permitan

integrarse con los sistemas de informacin del Consejo de la Judicatura
y la Corte Constitucional, con la finalidad de que el SIGEJ se convierta
en una herramienta til no solo para los abogados sino tambin para los
clientes y los jueces que necesiten informacin acerca de un determinado
caso.

En cuanto al SIGEJ es de vital importancia mantener actualizada la

informacin de la aplicacin, pues esta es la nica manera de que se
muestre informacin real, til y completa.

124

CAPITULO VIII
PROPUESTA

8.1.

Bases de la propuesta
Del estudio comparativo de las metodologas para el diseo de sistemas

en la web del apartado 3.5 se han establecido los lineamientos de la

metodolgica MeDWCU, que tienen las siguientes ventajas:
-

Orientada a objetos,

Que separa el aspecto de navegacin del diseo bsico,

Que separa la interfaz de la navegacin.

MeDWCU debe adems tener una serie de caractersticas aadidas:

-

Debe cubrir todo el ciclo de vida del proyecto.

Debe estar orientada al proceso, es decir, debe indicar qu hacer en

cada momento del ciclo de vida.

Debe estar orientada al producto, es decir, en cada fase se indicar qu

hay que obtener y el formato que deber tener para ello.

Debe ser sencilla, sobretodo en sus primeras fases, para facilitar la

participacin del cliente y del usuario.

Debe ser completa, para cubrir todas las necesidades tanto del
desarrollador como del usuario y ofrecer una semntica suficiente
como para trabajar de forma adecuada todos los aspectos crticos que
se destacan de los sistemas de informacin web diseados y centrados
en los usuarios.

Al considerar estas premisas, en este documento se presenta una visin global

de toda la metodologa. El objetivo final es ir concretar cada una de las ideas

125

que se indican de forma general en este resumen, hasta conseguir una

propuesta completa y adecuada para este entorno.
A continuacin se va a presentar esta visin genrica, que empieza con el
ciclo de vida, indica sus objetivos, las tcnicas que se usan y los productos a
obtener en cada uno de ellas. Finalmente se har una valoracin general de la
propuesta y se comentar el estado de desarrollo actual de la misma.
8.2. Fases del Ciclo de vida
Para definir el ciclo de vida de presente propuesta, se parte de la idea de
dividir la vida del proyecto en flujos de trabajo o mini-proyectos. El ciclo de
vida comprender un total de cinco flujos de trabajo: planificacin, anlisis,
diseo, construccin e implementacin y mantenimiento. En principio estos
flujos de trabajo se realizarn de forma consecutiva, pero al ver la realidad de
los proyectos software, desde un determinado flujo es necesario volver a
flujos anteriores para redefinir nuevos aspectos. Por ello, MeDWCU ser
secuencial pero permitir iterar y volver a redefinir flujos anteriores.
En las propuestas que se han presentado, en el flujo de diseo se estudiarn
cuatro aspectos diferentes: arquitectura, base de datos, navegacin e interfaz.
Al asumir la idea de estudiar los aspectos de navegacin e interfaz de forma
independiente, el flujo de diseo en MeDWCU se va a dividir en cuatro
actividades: el diseo de la arquitectura, en el que se estudia el diseo
conceptual del sistema; diseo de la base de datos, diseo navegacional, en el
que se estudia el sistema de navegacin del sistema; y el diseo de la interfaz
abstracta, el en que se estudian los aspectos de presentacin e interaccin con
el usuario de forma abstracta.
Esta divisin que aparece reflejada en muchas metodologas, tambin se ve
reflejada en todos los flujos de trabajo de MeDWCU que se presenta, no slo
en el diseo; sino tambin desde los primeros flujos de trabajo se hace una
separacin entre lo que se almacena en el sistema, lo que se puede hacer con
el sistema y de qu forma se va a presentar la informacin al usuario.

126

La metodologa MeDWCU est organizada en cinco fases las mismas que se

describen en el siguiente grfico junto con las principales actividades.

Planificacin

Planificacin del Sistema

Estudio de Factibilidad

Anlisis

Determinacin
y
Especificacin
Requisitos
Anlisis de Requisitos

Diseo

Diseo Bsico
Navegacional
Interfaz Abstracta

Construccin

Preparacin del entorno de trabajo

Creacin de Templates.
Creacin de Mdulos y Componentes.

Implementacin
Mantenimiento

de

Revisin de Tareas.
Pruebas y validacin.
Aprobacin del SI.

Figura 55. Resumen de las fases de la Metodologa MeDWCU.

Fuente: ngel Cudco

A continuacin se detallan de forma ms concreta cada una de las fases que

comprenden la Propuesta Metodolgica MeDWCU.
8.2.1. PLANIFICACIN
Para el correcto entendimiento y la adecuada aplicacin de la metodologa a
esta fase se la ha dividido en dos etapas: Planificacin y Estudio de
Viabilidad, las mismas que se describen en los siguientes apartados.
8.2.1.1. PLANIFICACIN DEL SISTEMA
La Planificacin de Sistemas de Informacin tiene como objetivo la obtencin
de un marco de referencia para el desarrollo de sistemas de informacin que
responda a los objetivos estratgicos de la organizacin. Este marco de
referencia consta de:

127

Una descripcin de la situacin actual, que constituir el punto de

partida del plan de desarrollo del Sistema de Informacin. Dicha
descripcin incluir un anlisis tcnico de puntos fuertes y riesgos, as
como el anlisis de servicio a los objetivos de la organizacin.

Un conjunto de modelos que constituya la arquitectura de

informacin.

Una propuesta de calendario para la ejecucin de las fases del

desarrollo de software.

Un plan de seguimiento y cumplimiento de todo lo propuesto

mediante el uso de mecanismos de evaluacin adecuados.

La perspectiva del plan debe ser estratgica y operativa, no tecnolgica.

Las principales tcnicas a utilizar para esta actividad se describen a
continuacin:

Sesiones de trabajo

Entrevistas encuestas.

Observacin directa.

8.2.1.2. ESTUDIO DE VIABILIDAD

El objetivo del Estudio de Viabilidad del Sistema es el anlisis de un
conjunto concreto de necesidades para proponer una solucin a corto plazo,
que tenga en cuenta restricciones econmicas, tcnicas, legales y operativas.
Para ello, se identifican las necesidades que se ha de satisfacer y se estudia,
si procede, la situacin actual.
A partir del estado inicial, la situacin actual y los requisitos planteados, se
estudian las alternativas de solucin. Dichas alternativas pueden incluir
soluciones que impliquen desarrollos a medida, soluciones basadas en la
adquisicin de productos software del mercado o soluciones mixtas.
Una vez descritas cada una de las alternativas planteadas, se valora su impacto
en la organizacin, la inversin a realizar en cada caso y los riesgos asociados.

128

Esta informacin se analiza con el fin de evaluar las distintas alternativas y

seleccionar la ms adecuada, la misma que definan y establezcan su
planificacin.
Dentro del estudio de viabilidad se deben considerar las siguientes
actividades:

Establecimiento del Alcance del Sistema

Estudio de la Situacin Actual

Estudio de Alternativas de Solucin

Valoracin de las Alternativas

Seleccin de la Solucin

Las principales tcnicas a utilizar para esta actividad se describen a

continuacin:

Sesiones de trabajo

Entrevistas encuestas.

Observacin directa.

8.2.2. ANLISIS
Para una correcta definicin a esta fase se le ha subdivido en dos fases:
Especificacin de requisitos y anlisis de requisitos. La descripcin de cada
una de ellas se la hace en los siguientes apartados.
8.2.2.1. ESPECIFICACIN DE REQUISITOS
Esta etapa es la primera actividad que se debe realizar en el
desarrollo de un Sistema de Informacin. Comienza despus de que un
usuario ha detectado una ausencia, falla o falta de oportunidad de la
informacin o simplemente, luego que la organizacin ha determinado un
cambio en sus polticas, reglas o tecnologas a aplicar.
En esta etapa, se debe responder a una pregunta fundamental: Qu es lo que
quiere el usuario? y para ello, se debe diagnosticar la situacin actual,

129

recopilar los requerimientos del usuario, tanto en relacin al sistema, es decir

la situacin ideal, para as poder definir alternativas de solucin, segn las
cuales se podr avanzar desde lo que hoy se posee, hacia el punto que se
pretende llegar.
En esta etapa se logra claridad sobre lo que desea el usuario y la forma en la
cual se le va a presentar la solucin a buscar. Los requerimientos son parte
fundamental en un sistema de informacin ya que estos representan el
conjunto completo de resultados a ser obtenidos una vez que se utilice el
sistema. Los requerimientos de sistemas deben mostrar todo lo que el sistema
debe hacer ms todas las restricciones sobre la funcionalidad. Los
requerimientos forman un modelo completo, representa el sistema total con
algn nivel de abstraccin Sommerville (2011).
De este modo se puede decir que un requerimiento es una condicin o
capacidad a la que el sistema debe conformar. Un requerimiento de software
puede ser definido como:
Una capacidad del software necesaria por el usuario para resolver un
problema o alcanzar un objetivo.
Una capacidad del software que debe ser reunida o poseda por un
sistema o componente del sistema para satisfacer un contrato,
especificacin, estndar, u otra documentacin formal.
Los requerimientos de usuario representan el conjunto completo de resultados
a ser obtenidos mediante el uso del sistema4. Los requisitos a tomarse en
cuenta dentro del MeDWCU estn definidos en la seccin 3.5.1 de este
documento, estos requisitos son:
Funcionales:
o Requisitos de Datos.
o Requisitos de Interfaz de Usuario.

Requerimientos
http://www.galeon.com/zuloaga/Doc/AnalisisRequer.pdf

130

o Requisitos Navegacionales.
o Requisitos de Personalizacin.
o Requisitos Transaccionales.
Requisitos no funcionales.
8.2.2.2. ANLISIS DE REQUISITOS
Los requisitos una vez que han sido especificados necesitan ser analizados y
validados. La validacin de requisitos tiene como misin demostrar que la
especificacin de los requisitos define realmente el sistema que el usuario
necesita o el cliente desea (Lowe & Hall, 1999). Es necesario asegurar que el
anlisis realizado y los resultados obtenidos de la etapa de definicin de
requisitos son correctos. Pocas son las propuestas existentes que ofrecen
tcnicas para la realizacin de la validacin y muchas de ellas consisten en
revisar los modelos obtenidos en la definicin de requisitos con el usuario
para detectar errores o inconsistencias.
Para ello las tcnicas ms ptimas para este tipo de actividades se
recomiendan emplear las siguientes:

Reviews o Walk-throughs: Est tcnica consiste en la lectura y

correccin de la completa documentacin o modelado de la definicin de
requisitos. Con ello solamente se puede validar la correcta interpretacin
de la informacin transmitida. Ms difcil es verificar consistencia de la
documentacin o informacin faltante.

Auditoras: La revisin de la documentacin con esta tcnica consiste

en un chequeo de los resultados contra una checklist predefinida o
definida a comienzos del proceso, es decir slo una muestra es revisada.

Matrices de trazabilidad: Esta tcnica consiste en marcar los objetivos

del sistema y chequearlos contra los requisitos del mismo (Durn,
Bernldez, Ruz & Toro, 1999). Es necesario determinar qu objetivos
cubre cada requisito, de esta forma se podrn detectar inconsistencias u
objetivos no cubiertos.

131

Prototipos: Algunas propuestas se basan en obtener de la definicin de

requisitos prototipos que, sin tener la totalidad de la funcionalidad del
sistema, permitan al usuario hacerse una idea de la estructura de la
interfaz del sistema con el usuario (Olsina, 1999). Esta tcnica tiene el
problema de que el usuario debe entender que va observar un prototipo y
no el sistema final.

8.2.3. DISEO
Segn Pressman (2010), el diseo del software es realmente un proceso de
muchos pasos pero que se clasifican dentro de uno mismo. En general, la
actividad del diseo se refiere al establecimiento de las estructuras de datos,
la arquitectura general del software, representaciones de interfaz y
algoritmos. El proceso de diseo traduce requisitos en una representacin de
software.
Esta fase contempla las siguientes etapas:

Diseo Conceptual

Diseo Bsico

Diseo Navegacional

Diseo de Interfaz abstracta

Cada una de estas etapas se describe en los siguientes apartados.

A. Diseo conceptual: Se construye un modelo orientado a objetos que
represente el dominio de la aplicacin mediante el empleo de las tcnicas
propias de la orientacin a objetos. La finalidad principal durante esta fase es
capturar el dominio semntico de la aplicacin en la medida de lo posible,
consideral el rol de los usuarios y las tareas que desarrollan. El resultado de
esta fase es un modelo de clases relacionadas que se divide en subsistemas.

B. Diseo Bsico: En esta fase se deben disear la base de datos y los

diccionarios de datos. Por diseo de base de datos se refiera a la actividad en
la cual se toman los requerimientos y especificaciones de la fase de anlisis

132

y se determina la mejor manera de satisfacerlos, segn las apreciaciones del

Usuario y de la persona que lo desarrolla, a travs de un diseo inicial de base
de datos.
La finalidad del diseo de bases de datos es establecer, a partir del trabajo con
los usuarios, las lneas bsicas del sistema, principalmente en lo que respecta
a funcionalidad y estructura de la base de datos.
C. Diseo Navegacional: En la fase de diseo navegacional se debe
disear la aplicacin dndole una gran importancia a las tareas que el usuario
va a realizar sobre el sistema. Para ello, hay que partir del esquema conceptual
desarrollado en la fase anterior. Hay que tener en cuenta que sobre un mismo
esquema conceptual se pueden desarrollar diferentes modelos navegacionales
(cada uno de los cuales dar origen a una aplicacin diferente).
Al ser una etapa heredada de la Metodologa OOHDM se toma una serie de
clases especiales predefinidas, que se conocen como clases navegacionales:
Nodos, Enlaces y Estructuras de acceso, que se organizan dentro de un
Contexto Navegacional. Mientras que la semntica de los nodos y los enlaces
son comunes a todas las aplicaciones hipermedia, las estructuras de acceso
representan diferentes modos de acceso a esos nodos y enlaces de forma
especfica en cada aplicacin.
D. Diseo de Interfaz abstracta: Una vez definida la estructura
navegacional, hay que prepararla para que sea perceptible por el usuario y
esto es lo que se intenta en esta fase. Esto consiste en definir qu objetos de
interfaz va a percibir el usuario, y en particular el camino en el cul aparecern
los diferentes objetos de navegacin, qu objeto de interfaz actuarn en la
navegacin, la forma de sincronizacin de los objetos multimedia y el interfaz
de transformaciones. Al haber una clara separacin entre la fase anterior y
esta fase, para un mismo modelo de navegacin se pueden definir diferentes
modelos de interfaces, a su vez permitir que la interfaz se ajuste mejor a las
necesidades del usuario.

133

8.2.4. CONSTRUCCIN
Finalizadas correctamente las actividades anteriores, la parte lgica de
la aplicacin ya estara totalmente desarrollada, sin embargo, esto para el usuario
no representa nada, ya que lo que el usuario desea es poder interactuar con el
software desarrollado a travs de las interfaces de usuarios. Por lo cual en esta
fase, se dedicar totalmente a la programacin y generacin del cdigo de la
aplicacin, de modo que la aplicacin sea presentada al usuario.
En esta fase se desarrollarn las siguientes actividades:
e) Preparacin del entorno de trabajo.
f) Preparacin de Templates.
g) Generacin de mdulos y componentes.
h) Carga inicial de datos.
8.2.5. IMPLEMENTACIN Y MANTENIMIENTO
Como su nombre lo indica, esta etapa corresponde a la implementacin
de la aplicacin realizada, ya sea de forma local o mediante un servicio de
hosting, con el fin de verificar si se han cumplido a cabalidad todos los
requerimientos establecidos en un principio por parte de los usuarios.
Las actividades correspondientes a esta fase son las siguientes:
d) Instalacin de servidores.
e) Pruebas y funcionamiento.
f) Aprobacin del Sistema.
Si el Sistema cumple de forma satisfactoria con las actividades mencionadas
anteriormente, se procede a realizar la carga de los archivos, base de datos y
tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptacin
final, durante el cual, el sistema comenzar a funcionar bajo la responsabilidad
del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptacin.
Finalizado el Periodo de Aceptacin, se le dar al sistema la aprobacin final,
para que pase a ser el sistema oficial.

134

9. BIBLIOGRAFA

Libros y Folletos
Andreu, J, Ricart, J.E. & Valor, J. (1997). La organizacin en la era de la
informacin. Madrid. McGraw-Hill- IESE.
Beck, K. (1996). Smalltalk Best Practice Patterns. Published October 3rd
1996. Prentice Hall. ISBN13: 9780134769042
Brito, K. (2009). Metodologas de desarrollo de Aplicaciones Web.
Universidad de Cienfuegos Carlos Rafael Rodrguez Facultad de
Informtica Carrera de Ingeniera Informtica. Cienfuegos Cuba.
Burbeck, S. (1992). Applications Programming in Smalltalk-80(TM): How to
use ModelViewController (MVC)
Cowan, D. & Lucena, C. (1995). Abstract Data Views: An Interface
Specification Concept to Enhance Design for Reuse. IEEE Transactions on
Software Engineering. Vol. 21, No. 3, March 1995.
Troyler, O. & Leune, C. (1997). WSDM: A user-centered design method for
Web sites. En: Proceedings of the 7th International World Wide Web
Conference.
Dez, A. (2001). IRqA y el desarrollo de proyectos: Experiencias Prcticas. I
Jornadas de Ingeniera de Requisitos Aplicadas. JIRA 2001. Seville, Spain.
Escalona, M. (2002). Metodologas para el desarrollo de sistemas de
informacin global. Departamento de Lenguajes y Sistemas Informticos

135

Escuela Tcnica Superior de Ingeniera Informtica. Segunda edicin.

Sevilla-Espaa. RA-MA Editorial. 9-60 pg.
Gamma, E, Helm, R, Johnson, R & Vlissides, J. (1995). Design Patterns:
Elements of reusable object-oriented software, Addison Wesley.
Koch, N. (2000). Comparing Development Methods for Web Applications.
Ludwig-Maximilians-University Munich, Institute of Computer Science
Oettingenstr. 67, 80538 Mnchen, Germany.
Lamas, MJ. (2009). Metodologa para el Desarrollo de Sistemas de
Informacin Web. Universidad Catlica de Chile
Lange, D. (1994). An Object-Oriented design method for hypermedia
information systems. Proceedings of the 27th. Annual Hawaii International
Conference on System Science, January 1994.
Laudon, K. & Laudon, J. (2012). Administracin de Sistemas de Informacin;
organizacin y tecnologa conectada en red. Decimosegunda Edicin.
Mxico: Prentice Hall. Kaplan, R.y Norton, D.
Lee, H, Lee, C & Yoo, C. (1998). A scenario-based object-oriented
methodology for developing hipermedia information systems. En:
Proceedings of 31st Annual Conference on Systems Science, Eds. Sprague R.
Olsina, L. (1999). Web-site Quantitative Evaluation and Comparison: a Case
Study on Museums. Workshop on Software Engineering over the Internet, at
Int'l Conference on Software Engineering (ICSE). Los Angeles, US.
Electronic

Proceeding

at

http://sern.cpsc.ucalgary.ca/-

maurer/ICSE99WS/ICSE99WS.html.
Pressman, R. (2010). Ingeniera del Software; Un enfoque prctico. Espaol.
Sexta Edicin. McGraw-Hill Interamericana Companies.103-604 pg.

136

Rumbaugh, J. (1996). OMT Insights: perspectives on modeling from the

Journal of Object-Oriented Programming. SIGS Books. ISBN: 1-884842-585
Rossi, G. (1996) An Object Oriented Method for Designing Hipermedia
Applications. PHD Thesis, Departamento de Informtica, PUC-Rio, Brazil,
1996.
Schwabe, D. & Rossi, G. (1998). Developing Hypermedia Applications using
OOHDM. Workshop on Hypermedia Development Process, Methods and
Models, Hypertext98, Pittsburg, USA.
Schwabe, D., Pontes, R. A. & Moura, I. (1999). OOHDM-Web: An
Environment for Implementation of Hypermedia Applications in the WWW.
SigWEB Newsletter, Vol. 8, #2, Junho de 1999.
Sommerville, I. (2011). Ingeniera del Software. Departamento Ciencia de la
Computacin e Inteligencia Artificial Universidad de Alicante. Sptima
Edicin. Espaa-Madrid, Pearson Educacin S. L. 5-19 pg.
Vilain, P., Schwabe, D. & Sieckenius, C. (2000). A diagrammatic Tool for
Representing User Interaction in UML. Lecture Notes in Computer Science.
Proc. UML2000. York, England.
Sitios Web
Beck, et al. (2001). Manifiesto por el Desarrollo gil de Software. Disponible
en: http://agilemanifesto.org/

137

10.

ANEXOS

138

ANEXO 1
PREPARACIN DEL ENTORNO DE TRABAJO
Para la presente investigacin se dispone de una Cuenta Premiun en
DREAMSPARK de Microsoft a travs de la cual se puede descargar
gratuitamente todo el Software de desarrollo de esta empresa con su respectiva
licencia.

Figura 56. Catlogo de Software en DREAMSPARK

Fuente: ngel Cudco

Instalacin del IDE de Desarrollo: Visual Studio 2013

Paso

1:

Ir

la

pgina

oficial

de

Microsoft:

http://www.microsoft.com/visualstudio/esn/downloads como en la imagen.

Figura 57. Seccion de descargas de Visual Studio 2013.

Fuente: ngel Cudco

139

Paso 2: buscar el Visual Studio Ultimate 2013:

Figura 58. Seleccin del medio de instalacin.

Fuente: ngel Cudco

Paso 3: Existen varias opciones como: descargar el instalador que comenzara la

instalacin online (necesita de internet) y la imagen iso del disco (se puede
instalar sin internet), elegir cualquiera:

Figura 59. Descarga del medio de instalacin.

Fuente: ngel Cudco

140

Paso 4: Una vez descargado empieza la instalacin:

Figura 60. Inicio del proceso de instalacin de Visual Studio 2013.

Fuente: ngel Cudco

Paso 5: Esto puede tardar mucho segn las caractersticas del computador, una
vez terminada la instalacin, inicia la carga del programa para abrirse por primera
vez:

Figura 61. Pantalla que se muestra al finalizar la instalacin.

Fuente: ngel Cudco

141

Paso 6: Una vez cargado se muestra la primera pantalla de configuracin del

programa:

Figura 62. Primera pantalla de dialogo despus de finalizar la instalacin.

Fuente: ngel Cudco

Paso 7: Una vez preparado el programa iniciar normalmente y se puede

observar la nueva interfaz, no cambia mucho al 2012 pero tiene algunas opciones
nuevas:

Figura 63. Entorno de trabajo listo para usar.

Fuente: ngel Cudco

142

INSTALACIN DEL SERVIDOR DE BASES DE DATOS

a. Ejecutamos el instalador como Administrador
b. Nos posicionamos en el panel izquierdo de la pantalla sobre la opcin
INSTALLATION y le damos clic

Figura 64. Cuadro de dialogo al iniciar la instalacin del servidor de bases

de datos.
Fuente: ngel Cudco

c. en la siguiente ventana nos mostrara las opciones de instalacin nosotros

utilizaremos la primera New SQL Server stand-alone

Figura 65. Nueva instalacin del servidor de bases de datos.

Fuente: ngel Cudco

d. En la siguiente ventana Setup Suppot Rules damos clic en OK

143

Figura 66. Verificacin de los requisitos de instalacin del SQL Server.

e. La siguiente ventana es la ventana de registro ah ingresamos la clave del

producto y damos clic en NEXT

Figura 67. Ingreso del Serial del SQL Server.

f. Leer los trminos y condiciones y chequear la opcin I accept The lcense

terms, luego dar clic en NEXT
g. En este paso nos muestra los posibles problemas durante instalacin
chequeamos q todo este bien y damos clic en NEXT

Figura 68. Revisin de los posibles inconvenientes que se pudiesen encontrar.

144

h. Ac nos muestra las caractersticas que deseamos instalar o los componentes

en este caso le daremos All Features Whit Defaults, y luego clic en NEXT

Figura 69. Caractersticas a instalar.

i. Nos muestra un resumen de todo lo que se instalara, damos clic en NEXT

Figura 70. Resumen de las caractersticas a instalar.

j. Ac revisa si tenemos los pre-requisitos de software, luego damos clic en

NEXT

Figura 71. Chequeo de los requisitos de software.

145

k. Comenzamos con la configuracin, en este caso le pondremos un nombre que

podamos identificar fcilmente y luego clic en NEXT

Figura 72. Inicio del proceso de instalacin de SQL Server.

l. Se muestra un resumen de los requisitos de espacio que ocupara en disco duro,

si est todo bien damos clic en NEXT

Figura 73. Espacio de disco duro requerido para la instalacin.

m. Ac damos clic en Add Current User y nos agregara nuestro usuario de

Windows luego clic en NEXT

Figura 74. Agregar usuarios administradores del SQL Server.

146

n. Dar clic en Add current user y nos agregara nuestro usuario quien tendr
acceso ilimitado, luego damos clic en NEXT

Figura 75. Asignacin de permisos de los administradores del SQL Server.

o. Revisa que todo est en orden para la instalacin y luego clic en NEXT

Figura 76. Confirmacin de requisitsos para la instalacin.

p. muestra un resumen o reporte detallado de la instalacin, le damos clic en

INSTALL y esperamos a que finalice la instalacin

Figura 77. Inicio del proceso de instalacin.

Tomar alrededor de 30 minutos segn las caractersticas de la PC

147

q. Al finalizar la instalacin saldr la ventana con el resumen de la instalacin,

damos clic en CLOSE

Figura 78. Fin del proceso de instalacin de SQL Server.

Fuente: ngel Cudco

148

ANEXO 2
CREACIN DE TEMPLATES
Site.master
<%@

Master

Language="VB"

AutoEventWireup="true"

CodeFile="Site.master.vb"

Inherits="SiteMaster" %>
<!DOCTYPE html>
<html lang="es">
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Sistema deGestin Jurdica</title>
<asp:PlaceHolder runat="server">
<%: Scripts.Render("~/bundles/modernizr") %>
</asp:PlaceHolder>
<webopt:BundleReference runat="server" Path="~/Content/css" />
<link href="~/favicon.ico" rel="shortcut icon" type="image/x-icon" />
<style type="text/css">
.auto-style1 {
position: relative;
min-height: 1px;
float: left;
width: 66.66666666666666%;
left: 0px;
top: 0px;
padding-left: 15px;
padding-right: 15px;
}
</style>

<%--footbale--%>
<script src="js/footable.js"></script>
<script src="js/jquery-1.9.1.min.js"></script>
<%--footbale--%>
<%--

<script type="text/javascript">
$(function () {
$('#=gv_dataGrid.ClientID').footable({
breakpoints: {
phone: 300,
tablet: 640
}

149

})
})
</script> --%>
</head>
<body>
<form runat="server">
<asp:ScriptManager runat="server">
<Scripts>
<%--To

learn

more

about

bundling

scripts

in

ScriptManager

see

http://go.microsoft.com/fwlink/?LinkID=301884 --%>
<%--Framework Scripts--%>
<asp:ScriptReference Name="MsAjaxBundle" />
<asp:ScriptReference Name="jquery" />
<asp:ScriptReference Name="bootstrap" />
<asp:ScriptReference Name="respond" />
<asp:ScriptReference

Name="WebForms.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/WebForms.js" />
<asp:ScriptReference Name="WebUIValidation.js" Assembly="System.Web"
Path="~/Scripts/WebForms/WebUIValidation.js" />
<asp:ScriptReference

Name="MenuStandards.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/MenuStandards.js" />
<asp:ScriptReference

Name="GridView.js"

Assembly="System.Web"

Name="DetailsView.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/GridView.js" />
<asp:ScriptReference

Path="~/Scripts/WebForms/DetailsView.js" />
<asp:ScriptReference

Name="TreeView.js"

Assembly="System.Web"

Name="WebParts.js"

Assembly="System.Web"

Name="Focus.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/TreeView.js" />
<asp:ScriptReference
Path="~/Scripts/WebForms/WebParts.js" />
<asp:ScriptReference
Path="~/Scripts/WebForms/Focus.js" />
<asp:ScriptReference Name="WebFormsBundle" />
<%--Site Scripts--%>
</Scripts>
</asp:ScriptManager>
<div class="navbar navbar-inverse navbar-fixed-top">
<div class="col-md-3">
<div class="container">
<div class="col-md-3">
<div class="navbar-header">
<%--<asp:ImageButton

ID="ImageButton1"

runat="server"

ImageUrl="~/imagenes/logo_final.png" Height="84px" Width="252px" />--%>

<button

type="button"

class="navbar-toggle"

toggle="collapse" data-target=".navbar-collapse">
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<%--<span class="icon-bar"></span>--%>

150

data-

</button>
</div>
</div>
</div>
</div>
<div class="auto-style1">
<div class="collapse navbar-collapse bs-example-js-navbar-collapse">
<ul class="nav navbar-nav">

<li class="dropdown">
<a

id="drop1"

class="dropdown-toggle"

data-

toggle="dropdown" role="button" href="#">CLIENTES

<b class="caret"></b>
</a>
<ul

class="dropdown-menu"

aria-labelledby="drop1"

role="menu">
<li

role="presentation"><a

runat="server"

href="web/clientes/nuevo_cliente.aspx" tabindex="-1" role="menuitem">NUEVO</a></li>

<li role="presentation">
<a runat="server" href="http://twitter.com/fat"
tabindex="-1" role="menuitem">ACTUALIZAR</a>
</li>
<li role="presentation">
<a

runat="server"

href="web/clientes/reporte_clientes.aspx" tabindex="-1" role="menuitem">REPORTES</a>

</li>
</ul>
</li>
<li class="dropdown">
<a

id="drop2"

class="dropdown-toggle"

data-

toggle="dropdown" role="button" href="#">OPERADOR DE JUSTICIA

<b class="caret"></b>
</a>
<ul

class="dropdown-menu"

aria-labelledby="drop2"

role="menu">
<li role="presentation">
<a

runat="server"

href="web/operadordejusticia/nuevo_op_just.aspx"

tabindex="-1"

role="menuitem">NUEVO</a>
</li>
<li role="presentation">
<a

runat="server"

href="web/operadordejusticia/rep_juez.aspx"
role="menuitem">REPORTES</a>
</li>
<li role="presentation">

151

tabindex="-1"

<a runat="server" href="http://twitter.com/fat"

tabindex="-1" role="menuitem">BUSCAR</a>
</li>
</ul>
</li>
<li class="dropdown">
<a

id="drop3"

class="dropdown-toggle"

data-

toggle="dropdown" role="button" href="#">GESTIN DE CASOS

<b class="caret"></b>
</a>
<ul

class="dropdown-menu"

aria-labelledby="drop2"

role="menu">
<li role="presentation">
<a

runat="server"

href="web/casos/nuevo_caso.aspx" tabindex="-1" role="menuitem">NUEVO</a>

</li>
<li role="presentation">
<a

runat="server"

href="web/casos/agregar_diligencias.aspx"

tabindex="-1"

role="menuitem">AGREGAR

DILIGENCIAS</a>
</li>
<li role="presentation">
<a

runat="server"

href="web/casos/agregar_actividades.aspx"

tabindex="-1"

role="menuitem">AGREGAR

ACTIVIDADES</a>
</li>
<li role="presentation">
<a runat="server" href="http://twitter.com/fat"
tabindex="-1" role="menuitem">BUSCAR</a>
</li>
<li role="presentation">
<a

runat="server"

href="web/casos/reporte_casos.aspx" tabindex="-1" role="menuitem">REPORTES</a>

</li>
</ul>
</li>
<li class="dropdown">
<a

id="drop4"

class="dropdown-toggle"

data-

toggle="dropdown" role="button" href="#">TALENTO HUMANO

<b class="caret"></b>
</a>
<ul

class="dropdown-menu"

aria-labelledby="drop2"

role="menu">
<li role="presentation">
<a

runat="server"

href="web/talentohumano/nuevoabg.aspx" tabindex="-1" role="menuitem">NUEVO</a>

152

</li>
<li role="presentation">
<a runat="server" href="http://twitter.com/fat"
tabindex="-1" role="menuitem">ACTUALIZAR</a>
</li>
<li role="presentation">
<a runat="server" href="http://twitter.com/fat"
tabindex="-1" role="menuitem">BUSCAR</a>
</li>
<li role="presentation">
<a runat="server" href="http://twitter.com/fat"
tabindex="-1" role="menuitem">REPORTES</a>
</li>
</ul>
</li>
<li class="dropdown">
<a

id="drop5"

class="dropdown-toggle"

data-

toggle="dropdown" role="button" href="#">CONFIGURACION

<b class="caret"></b>
</a>
<ul

class="dropdown-menu"

aria-labelledby="drop2"

role="menu">
<li runat="server" role="presentation">
<a

href="http://twitter.com/fat"

tabindex="-1"

role="menuitem">NUEVO USUARIO</a>
</li>
<li role="presentation">
<a runat="server" href="http://twitter.com/fat"
tabindex="-1" role="menuitem">ACTUALIZAR</a>
</li>
<li role="presentation">
<a runat="server" href="http://twitter.com/fat"
tabindex="-1" role="menuitem">ACERCA DE..</a>
</li>
</ul>
</li>
</ul>
</div>
</div>
</div>
<!-- LINEA VERTICAL -->
<div class="col-md-3">
<hr />
<asp:ImageButton

ID="ImageButton1"

ImageUrl="~/imagenes/sigej.png" Height="84px" Width="215px" />

<h2>Agenda:</h2>

153

runat="server"

<asp:Calendar
BorderColor="White"

ID="Calendar1"

runat="server"

BackColor="White"

Font-Names="Verdana"

Font-Size="9pt"

ForeColor="Black"

Height="144px" Width="212px" BorderWidth="1px" NextPrevFormat="FullMonth">

<DayHeaderStyle Font-Bold="True" Font-Size="8pt" />
<NextPrevStyle

VerticalAlign="Bottom"

Font-Bold="True"

Font-

Size="8pt" ForeColor="#333333" />

<OtherMonthDayStyle ForeColor="#999999" />
<SelectedDayStyle BackColor="#333399" ForeColor="White" />
<TitleStyle BackColor="White" BorderColor="Black" Font-Bold="True"
BorderWidth="4px" Font-Size="12pt" ForeColor="#333399" />
<TodayDayStyle BackColor="#CCCCCC" />
</asp:Calendar>
<asp:Label

ID="Label1"

runat="server"

Text="Label"

runat="server"

CellPadding="4"

Visible="False"></asp:Label>
<hr />
<h4>Actividades para hoy:</h4>
<asp:DataList

ID="DataList1"

DataSourceID="SqlDataSource1"
BorderWidth="1px"

ForeColor="Black"

GridLines="Horizontal"

BorderColor="#CCCCCC"

Width="208px"

BackColor="White"

BorderStyle="None">
<FooterStyle BackColor="#CCCC99" ForeColor="Black" />
<HeaderStyle BackColor="#333333" Font-Bold="True" ForeColor="White"
/>
<ItemTemplate>
Actividad:
<asp:Label

ID="ActividadLabel"

runat="server"

Text='<%#

Eval("Actividad") %>' />

<br />
Estado:
<asp:Label

ID="EstadoLabel"

runat="server"

Text='<%#

Eval("Estado") %>' />

<br />
Encargado:
<asp:Label

ID="EncargadoLabel"

runat="server"

Text='<%#

Eval("Encargado") %>' />

<br />
Codigo Expediente:
<asp:Label ID="Codigo_ExpedienteLabel" runat="server" Text='<%#
Eval("[Codigo Expediente]") %>' />
<br />
Expediente Juzgado:
<asp:Label ID="Expediente_JuzgadoLabel" runat="server" Text='<%#
Eval("[Expediente Juzgado]") %>' />
<br />
Cliente:
<asp:Label

ID="ClienteLabel"

Eval("Cliente") %>' />

154

runat="server"

Text='<%#

<br />
<br />
</ItemTemplate>
<SelectedItemStyle

BackColor="#CC3333"

Font-Bold="True"

ForeColor="White" />
</asp:DataList>
<asp:SqlDataSource
ConnectionString="<%$

ID="SqlDataSource1"

runat="server"

ConnectionStrings:TESISConnectionString

%>"

SelectCommand="agenda_3" SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter

ControlID="Label1"

DbType="Date"

Name="fecha" PropertyName="Text" />

</SelectParameters>
</asp:SqlDataSource>
</div>
<!-- CONTENIDO PRINCIPAL -->
<div class="col-md-8">
<div class="container body-content" style="height: 106px">
<asp:ContentPlaceHolder ID="MainContent" runat="server">
</asp:ContentPlaceHolder>
<footer>
<p>&copy; <%: DateTime.Now.Year %> Sistema de Gestin Jurdica Derechos Reservados</p>
</footer>
</div>
</div>
</form>
</body>
</html>

155

Login.master
<%@ Master Language="VB" CodeFile="login.master.vb" Inherits="plantillas_login" %>
<!DOCTYPE html>
<html lang="es">
<head runat="server">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>Login</title>
<asp:PlaceHolder runat="server">
<%: Scripts.Render("~/bundles/modernizr") %>
</asp:PlaceHolder>
<webopt:BundleReference runat="server" Path="~/Content/css" />
<link href="~/favicon.ico" rel="shortcut icon" type="image/x-icon" />
</head>
<body>
<form runat="server">
<asp:ScriptManager runat="server">
<Scripts>
<%--To

learn

more

about

bundling

scripts

in

ScriptManager

see

http://go.microsoft.com/fwlink/?LinkID=301884 --%>
<%--Framework Scripts--%>
<asp:ScriptReference Name="MsAjaxBundle" />
<asp:ScriptReference Name="jquery" />
<asp:ScriptReference Name="bootstrap" />
<asp:ScriptReference Name="respond" />
<asp:ScriptReference

Name="WebForms.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/WebForms.js" />
<asp:ScriptReference Name="WebUIValidation.js" Assembly="System.Web"
Path="~/Scripts/WebForms/WebUIValidation.js" />
<asp:ScriptReference

Name="MenuStandards.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/MenuStandards.js" />
<asp:ScriptReference

Name="GridView.js"

Assembly="System.Web"

Name="DetailsView.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/GridView.js" />
<asp:ScriptReference

Path="~/Scripts/WebForms/DetailsView.js" />
<asp:ScriptReference

Name="TreeView.js"

Assembly="System.Web"

Name="WebParts.js"

Assembly="System.Web"

Name="Focus.js"

Assembly="System.Web"

Path="~/Scripts/WebForms/TreeView.js" />
<asp:ScriptReference
Path="~/Scripts/WebForms/WebParts.js" />
<asp:ScriptReference
Path="~/Scripts/WebForms/Focus.js" />
<asp:ScriptReference Name="WebFormsBundle" />
<%--Site Scripts--%>
</Scripts>

156

</asp:ScriptManager>
<div class="navbar navbar-inverse navbar-fixed-top">
<div class="container">
<div class="navbar-header">
<asp:Image

ID="Image1"

runat="server"

ImageUrl="~/imagenes/logo_final.png" Height="88px" Width="262px" />

</div>
<div class="navbar-collapse collapse">
<ul class="nav navbar-nav">
<li><a runat="server" href="~/web/login.aspx"></a></li>
</ul>
<asp:LoginView runat="server" ViewStateMode="Disabled">
<AnonymousTemplate>
<ul class="nav navbar-nav navbar-right">
</ul>
</AnonymousTemplate>
<LoggedInTemplate>
<ul class="nav navbar-nav navbar-right">
</ul>
</LoggedInTemplate>
</asp:LoginView>
</div>
</div>
</div>
<div class="col-md-3">
<hr />
<br />
<br />
<asp:ImageButton

ID="ImageButton1"

runat="server"

ImageUrl="~/imagenes/law_1.png" ImageAlign="AbsMiddle" />

</div>
<div class="col-md-8">
<div class="container body-content">
<hr />
<br />
<asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
</asp:ContentPlaceHolder>
<asp:ContentPlaceHolder ID="MainContent" runat="server">
</asp:ContentPlaceHolder>
<hr />
<footer>
<p>&copy;

<%:

DateTime.Now.Year

Jurdica</p>
</footer>
</div>
</div>

157

%>

Sistema

de

Gestin

</form>
</body>
</html>

158

ANEXO 3
CREACIN DE MDULOS Y COMPONENTES
Login.aspx
<%@ Page Title="" Language="VB" MasterPageFile="~/plantillas/login.master"
AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="_Default" %>
<asp:Content ID="Content1" ContentPlaceHolderID="ContentPlaceHolder1"
Runat="Server">
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" Runat="Server">
<h1><%: Title %>Iniciar Sesin</h1>
<div class="row">
<div class="col-md-8">
<section id="loginForm">
<div class="form-horizontal">
<h4>Ingrese su usuario y contrasea</h4>
<hr />
<asp:PlaceHolder runat="server" ID="ErrorMessage"
Visible="false">
<p class="text-danger">
<asp:Literal runat="server" ID="FailureText" />
</p>
</asp:PlaceHolder>
<div class="form-group">
<asp:Label runat="server" AssociatedControlID="UserName"
CssClass="col-md-2 control-label">Nombre de usuario</asp:Label>
<div class="col-md-0">
<asp:TextBox runat="server" ID="UserName"
CssClass="form-control" />
<asp:RequiredFieldValidator
ID="RequiredFieldValidator1" runat="server" ControlToValidate="UserName"
CssClass="text-danger" ErrorMessage="El campo de
nombre de usuario es obligatorio." />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label2" runat="server"
AssociatedControlID="Password" CssClass="col-md-2 controllabel">Contrasea</asp:Label>

159

<div class="col-md-0">
<asp:TextBox runat="server" ID="Password"
TextMode="Password" CssClass="form-control" />
<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />
</div>
</div>
<div class="form-group">
<div class="col-md-offset-2 col-md-0">
<%--NO RECORDAR SESION NI CONTRASEA--%>
<div class="checkbox">
<asp:CheckBox runat="server" ID="RememberMe" />
<asp:Label ID="Label3" runat="server"
AssociatedControlID="RememberMe">Recordar cuenta?</asp:Label>
</div>
</div>
</div>
<div class="form-group">
<div class="col-md-offset-2 col-md-0">
<asp:Button runat="server" Text="Iniciar sesin"
CssClass="btn btn-default" OnClick="Unnamed2_Click" />
<asp:SqlDataSource ID="SqlDataSource1" runat="server"
ConnectionString="<%$ ConnectionStrings:TESISConnectionString %>"
SelectCommand="inicio_sesion" SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter ControlID="UserName"
Name="usuario" PropertyName="Text" Type="String" />
<asp:ControlParameter ControlID="Password"
Name="contrasenia" PropertyName="Text" Type="String" />
</SelectParameters>
</asp:SqlDataSource>
</div>
</div>
</div>
</section>
</div>
</div>
</asp:Content>

160

Login.aspx.vb
Imports System.Data
Imports System.Data.SqlClient
Partial Class _Default
Inherits System.Web.UI.Page
Protected Sub Unnamed2_Click(sender As Object, e As EventArgs)
Dim x As Integer
Dim dvSql As DataView =
DirectCast(SqlDataSource1.Select(DataSourceSelectArguments.Empty), DataView)
If dvSql.Count > 0 Then
x = 1
End If
If x = 1 Then
Response.Write("Bienvenido")
Response.Redirect("Inicio.aspx")
Else
Response.Write("El usurio ingresado no existe")
End If
End Sub
End Class

Cliente.aspx
<%@ Page Title="" Language="VB" MasterPageFile="~/Site.master"
AutoEventWireup="false" CodeFile="nuevo_cliente.aspx.vb"
Inherits="web_clientes_nuevo_cliente" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" Runat="Server">
<h2>Nuevo Cliente</h2>
<div class="row">
<div class="col-md-6">
<section id="loginForm">
<div class="form-horizontal">
<h4>Seleccione el tipo de cliente.</h4>
<hr />
<asp:PlaceHolder runat="server" ID="ErrorMessage"
Visible="false">
<p class="text-danger">
<asp:Literal runat="server" ID="FailureText" />
</p>
</asp:PlaceHolder>
<div class="form-group">
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Seleccione el tipo de cliente:</asp:Label>
<div class="col-md-10">
<%-- <asp:TextBox runat="server" ID="UserName"
CssClass="form-control" />
<asp:RequiredFieldValidator
ID="RequiredFieldValidator1" runat="server" ControlToValidate="UserName"
CssClass="text-danger" ErrorMessage="El campo de
nombre de usuario es obligatorio." />--%>
<asp:DropDownList ID="DropDownList1" runat="server"
CssClass="form-control">
<asp:ListItem>Persona Natural</asp:ListItem>
<asp:ListItem>Persona Juridica</asp:ListItem>
</asp:DropDownList>
</div>
</div>

161

<div class="form-group">
<asp:Label ID="Label2" runat="server" CssClass="col-md-2
control-label" Font-Bold="True">Nombre / Razn Social:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="Password"
CssClass="form-control" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>
</div>
<div class="form-group">
<div class="col-md-offset-2 col-md-10">
<%--<asp:Button runat="server" Text="Aceptar"
CssClass="btn btn-default" />--%>
<asp:Button ID="Button1" runat="server" Text="Aceptar"
CssClass="btn btn-default" Width="115px" />
&nbsp;&nbsp;&nbsp;
<asp:Button ID="Button2" runat="server" Text="Completar
Informacin" CssClass="btn btn-default"/>
</div>
</div>
</div>
</section>
</div>
<div class="col-md-3">
<section id="socialLoginForm">
<%--PANEL 1--%>
<asp:Panel ID="Panel1" runat="server">
<asp:SqlDataSource ID="SqlDataSource1" runat="server"
ConnectionString="<%$ ConnectionStrings:TESISConnectionString %>"
SelectCommand="recuperar_id_participante" SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter ControlID="Password"
Name="nombre" PropertyName="Text" Type="String" />
</SelectParameters>
</asp:SqlDataSource>
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
</asp:Panel>
<%--PANEL 2--%>
<asp:Panel ID="Panel2" runat="server">
<h4>Persona Natural</h4>
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">CI:</asp:Label>
<asp:TextBox runat="server" ID="TextBox2" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Nombres:</asp:Label>
<asp:TextBox runat="server" ID="TextBox3" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Apellidos:</asp:Label>
<asp:TextBox runat="server" ID="TextBox4" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Direccin:</asp:Label>
<asp:TextBox runat="server" ID="TextBox5" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Profesin:</asp:Label>
<asp:TextBox runat="server" ID="TextBox6" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Fecha de Nacimiento:</asp:Label>

162

<asp:TextBox runat="server" ID="TextBox7" CssClass="formcontrol" TextMode="Date" />

<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Correo Electrnico:</asp:Label>
<asp:TextBox runat="server" ID="TextBox8" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Estado Civil:</asp:Label>
<asp:TextBox runat="server" ID="TextBox9" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Conyugue:</asp:Label>
<asp:TextBox runat="server" ID="TextBox10" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Telfono:</asp:Label>
<asp:TextBox runat="server" ID="TextBox11" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Celular:</asp:Label>
<asp:TextBox runat="server" ID="TextBox12" CssClass="formcontrol" />
<asp:Button ID="Button3" runat="server" Text="Aceptar"
CssClass="btn btn-default" Width="115px" />
</asp:Panel>
<%--PANEL 3--%>
<asp:Panel ID="Panel3" runat="server">
<h4>Persona Jurdica:</h4>
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Razn Social:</asp:Label>
<asp:TextBox runat="server" ID="TextBox13" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">RUC:</asp:Label>
<asp:TextBox runat="server" ID="TextBox14" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Direccin:</asp:Label>
<asp:TextBox runat="server" ID="TextBox15" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Telfono:</asp:Label>
<asp:TextBox runat="server" ID="TextBox20" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Correo Electrnico:</asp:Label>
<asp:TextBox runat="server" ID="TextBox16" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Fecha de Constitucin:</asp:Label>
<asp:TextBox runat="server" ID="TextBox17" CssClass="formcontrol" TextMode="Date" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Representante Legal:</asp:Label>
<asp:TextBox runat="server" ID="TextBox18" CssClass="formcontrol" />
<asp:Label runat="server" CssClass="col-md-2 control-label"
Font-Bold="True">Telefono Representante Legal:</asp:Label>
<asp:TextBox runat="server" ID="TextBox19" CssClass="formcontrol" />
<asp:Button ID="Button4" runat="server" Text="Aceptar"
CssClass="btn btn-default" Width="115px" />
</asp:Panel>
</section>
</div>
</div>

163

</asp:Content>

Reporte _clientes.aspx
<%@ Page Title="" Language="VB" MasterPageFile="~/Site.master"
AutoEventWireup="false" CodeFile="reporte_clientes.aspx.vb"
Inherits="web_clientes_reporte_clientes" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="Server">
<div class="row">
<div class="col-md-8">
<h3>Seleccione el tipo de cliente a buscar:</h3>
<hr />
<div class="form-group">
<div class="col-md-10">
<asp:DropDownList ID="DropDownList1" runat="server"
CssClass="form-control">
<asp:ListItem>Persona Natural</asp:ListItem>
<asp:ListItem>Persona Juridica</asp:ListItem>
</asp:DropDownList>
<hr />
<asp:Button ID="Button1" runat="server" Text="Aceptar"
CssClass="btn btn-default" Width="115px" />
<hr />
</div>
</div>
</div>
</div>
</asp:Content>

Casos.aspx
<%@ Page Title="" Language="VB" MasterPageFile="~/Site.master"
AutoEventWireup="false" CodeFile="nuevo_caso.aspx.vb"
Inherits="web_casos_nuevo_caso" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="Server">
<div class="row">
<div class="col-md-8">
<div class="form-horizontal">
<h2>Nuevo Caso:</h2>
<hr />
<div class="form-group">
<div class="col-md-10">
<div class="form-group">
<asp:Label ID="Label8" runat="server" CssClass="col-md2 control-label" Font-Bold="True">Cdigo expediente en el despacho:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox7"
CssClass="form-control" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label9" runat="server" CssClass="col-md2 control-label" Font-Bold="True">Asunto:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox8"
CssClass="form-control" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>

164

</div>
<div class="form-group">
<asp:Label ID="Label11" runat="server" CssClass="colmd-2 control-label" Font-Bold="True">Estado de expediente:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox10"
CssClass="form-control" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label12" runat="server" CssClass="colmd-2 control-label" Font-Bold="True">Fecha de Inicio:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox11"
CssClass="form-control" TextMode="Date" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label13" runat="server" CssClass="colmd-2 control-label" Font-Bold="True">Fecha de finalizacin:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox12"
CssClass="form-control" TextMode="Date" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label14" runat="server" CssClass="colmd-2 control-label" Font-Bold="True">Ciudad:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox13"
CssClass="form-control" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label15" runat="server" CssClass="colmd-2 control-label" Font-Bold="True">Provincia:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox14"
CssClass="form-control" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label16" runat="server" CssClass="colmd-2 control-label" Font-Bold="True">Codigo expediente en Juzgado:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox15"
CssClass="form-control" />
<%--<asp:RequiredFieldValidator
ID="RequiredFieldValidator2" runat="server" ControlToValidate="Password"
CssClass="text-danger" ErrorMessage="El campo de contrasea es obligatorio." />--%>

165

</div>
</div>
<div class="form-group">
<asp:Label ID="Label20" runat="server" CssClass="colmd-2 control-label" Font-Bold="True">Nombre Juez a cargo:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox19"
CssClass="form-control" />
<%-- <asp:Button ID="Button4" runat="server"
Text="Buscar" CssClass="btn btn-default" Width="130px" />
<asp:Button ID="Button7" runat="server"
Text="Aceptar" CssClass="btn btn-default" Width="130px" Visible="False" />--%>

<!-- Modal -->

<button class="btn btn-default" data-toggle="modal"
data-target="#myModal">
Buscar
</button>
<div class="modal fade" id="myModal" tabindex="-1"
role="dialog" aria-labelledby="myModalLabel" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<button type="button" class="close"
data-dismiss="modal" aria-hidden="true">&times;</button>
<h2 class="modal-title"
id="myModalLabel">Seleccione al operador de justicia:</h2>
</div>
<div class="modal-body">
<div class="table-responsive">
<asp:GridView ID="GridView1"
runat="server" AutoGenerateColumns="False" DataKeyNames="id_juez"
DataSourceID="SqlDataSource1" AllowSorting="True">
<Columns>
<asp:CommandField
ShowSelectButton="True" />
<asp:BoundField
DataField="id_juez" HeaderText="N" InsertVisible="False" ReadOnly="True"
SortExpression="id_juez" />
<asp:BoundField
DataField="nombres" HeaderText="Nombres" SortExpression="nombres" />
<asp:BoundField
DataField="apellidos" HeaderText="Apellidos" SortExpression="apellidos" />
<asp:BoundField
DataField="telefono" HeaderText="Telfono" SortExpression="telefono" />
<asp:BoundField
DataField="celular" HeaderText="Celular" SortExpression="celular" />
<asp:BoundField
DataField="juzgado" HeaderText="Juzgado" SortExpression="juzgado" />
<asp:BoundField
DataField="materia" HeaderText="Materia" SortExpression="materia" />
</Columns>
</asp:GridView>
<asp:SqlDataSource
ID="SqlDataSource3" runat="server" ConnectionString="<%$
ConnectionStrings:TESISConnectionString %>" SelectCommand="SELECT * FROM
[juez]"></asp:SqlDataSource>
</div>
</div>
<div class="modal-footer">
<button type="button"
class="btn btn-default" data-dismiss="modal">Salir</button>
<%--<button type="button"
class="btn btn-primary">Save changes</button--%>
</div>
</div>
</div>
</div>
<!-- Modal -->

166

<%--<asp:GridView ID="GridView1" runat="server"

AutoGenerateColumns="False" DataKeyNames="id_juez" DataSourceID="SqlDataSource1"
Visible="False" AllowSorting="True">
<Columns>
<asp:CommandField ShowSelectButton="True"
/>
<asp:BoundField DataField="id_juez"
HeaderText="id_juez" InsertVisible="False" ReadOnly="True" SortExpression="id_juez"
/>
<asp:BoundField DataField="nombres"
HeaderText="nombres" SortExpression="nombres" />
<asp:BoundField DataField="apellidos"
HeaderText="apellidos" SortExpression="apellidos" />
<asp:BoundField DataField="telefono"
HeaderText="telefono" SortExpression="telefono" />
<asp:BoundField DataField="celular"
HeaderText="celular" SortExpression="celular" />
<asp:BoundField DataField="juzgado"
HeaderText="juzgado" SortExpression="juzgado" />
<asp:BoundField DataField="materia"
HeaderText="materia" SortExpression="materia" />
</Columns>
</asp:GridView>--%>
<%--<asp:SqlDataSource ID="SqlDataSource1"
runat="server" ConnectionString="<%$ ConnectionStrings:TESISConnectionString %>"
SelectCommand="SELECT * FROM [juez]"></asp:SqlDataSource>--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label1" runat="server" CssClass="col-md2 control-label" Font-Bold="True">Cliente:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox1"
CssClass="form-control" />
<%-- <asp:Button ID="Button1" runat="server"
Text="Buscar" CssClass="btn btn-default" Width="130px" />
<asp:Button ID="Button2" runat="server"
Text="Aceptar" CssClass="btn btn-default" Width="130px" Visible="False" />--%>
<!-- MODAL -->
<button class="btn btn-default" datatoggle="modal" data-target="#myModal1">
Buscar
</button>
<div class="modal fade" id="myModal1"
tabindex="-1" role="dialog" aria-labelledby="myModalLabel" aria-hidden="true">
<div class="modal-dialog">
<div class="modal-content">
<div class="modal-header">
<button type="button"
class="close" data-dismiss="modal" aria-hidden="true">&times;</button>
<h2 class="modal-title"
id="myModalLabel1">Seleccione al cliente:</h2>
</div>
<div class="modal-body">
<div class="table-responsive">
<asp:GridView ID="GridView2"
cssclass="table table-hover" runat="server" AllowSorting="True"
AutoGenerateColumns="False" DataKeyNames="id_participante"
DataSourceID="SqlDataSource2" Visible="True">
<Columns>
<asp:CommandField
ShowSelectButton="True" />
<asp:BoundField
DataField="id_participante" HeaderText="N" InsertVisible="False" ReadOnly="True"
SortExpression="id_participante" />

167

<asp:BoundField
DataField="tipo" HeaderText="Tipo" SortExpression="Tipo" />
<asp:BoundField
DataField="nombre" HeaderText="Nombre/Razn Social" SortExpression="Nombre/Razn
Social" />
</Columns>
</asp:GridView>
<asp:SqlDataSource
ID="SqlDataSource2" runat="server" ConnectionString="<%$
ConnectionStrings:TESISConnectionString %>" SelectCommand="SELECT * FROM
[participante]"></asp:SqlDataSource>
</div>
</div>
<div class="modal-footer">
<button type="button"
class="btn btn-default" data-dismiss="modal">Salir</button>
<%--<button type="button"
class="btn btn-primary">Save changes</button>--%>
</div>
</div>
</div>
</div>
<!-- MODAL -->
<%--<asp:GridView ID="GridView2" runat="server"
AllowSorting="True" AutoGenerateColumns="False" DataKeyNames="id_participante"
DataSourceID="SqlDataSource2" Visible="False">
<Columns>
<asp:CommandField ShowSelectButton="True"
/>
<asp:BoundField DataField="id_participante"
HeaderText="id_participante" InsertVisible="False" ReadOnly="True"
SortExpression="id_participante" />
<asp:BoundField DataField="tipo"
HeaderText="tipo" SortExpression="tipo" />
<asp:BoundField DataField="nombre"
HeaderText="nombre" SortExpression="nombre" />
</Columns>
</asp:GridView>
<asp:SqlDataSource ID="SqlDataSource2"
runat="server" ConnectionString="<%$ ConnectionStrings:TESISConnectionString %>"
SelectCommand="SELECT * FROM [participante]"></asp:SqlDataSource>--%>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label2" runat="server" CssClass="col-md2 control-label" Font-Bold="True">Contraparte:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox2"
CssClass="form-control" />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label3" runat="server" CssClass="col-md2 control-label" Font-Bold="True">Abog. Contraparte:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="TextBox3"
CssClass="form-control" />
</div>
</div>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<asp:Button ID="Button3" runat="server" Text="Aceptar"
CssClass="btn btn-default" Width="130px" />
<asp:TextBox ID="TextBox4" runat="server"
Visible="False"></asp:TextBox>
<asp:TextBox ID="TextBox5" runat="server"
Visible="False"></asp:TextBox>
</div>
</div>

168

</div>
</div>
</div>
<asp:SqlDataSource ID="SqlDataSource1" runat="server" ConnectionString="<%$
ConnectionStrings:TESISConnectionString %>" SelectCommand="SELECT * FROM
[juez]"></asp:SqlDataSource>
</asp:Content>

Agregar_actividades.aspx
<%@ Page Title="" Language="VB" MasterPageFile="~/Site.master"
AutoEventWireup="false" CodeFile="agregar_actividades.aspx.vb"
Inherits="web_casos_agregar_actividades" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="Server">
<div class="row">
<div class="col-md-0">
<div class="form-horizontal">
<h2>Agregar actividades a diligencias</h2>
<hr />
<div class="form-group">
<div class="col-md-0">
<div class="form-group">
<div class="col-md-8">
<h3>Buscar Caso:</h3>
<asp:Label ID="Label3" runat="server"
CssClass="col-md-2 control-label" Font-Bold="True">Cliente:</asp:Label>
<asp:TextBox ID="TextBox2" runat="server"
CssClass="txt txt-default" Style="left: 0px; top: 0px;" Height="38px" Width="221px"
BorderStyle="Inset"></asp:TextBox>
&nbsp;&nbsp;&nbsp;&nbsp;
<asp:Button ID="Button3" runat="server"
Text="Buscar" CssClass="btn btn-default" Width="130px" />
<hr />
</div>
</div>
<div class="col-md-0">
<asp:Panel ID="Panel4" runat="server" Visible="False">
<h3>Listado de casos:</h3>
<br />
<div class="table-responsive">
<asp:GridView ID="GridView1" runat="server"
AllowSorting="True" AutoGenerateColumns="False" DataKeyNames="Nmero"
DataSourceID="SqlDataSource1">
<Columns>
<asp:CommandField
ShowSelectButton="True" />
<asp:BoundField DataField="Nmero"
HeaderText="Nmero" InsertVisible="False" ReadOnly="True" SortExpression="Nmero"
/>
<asp:BoundField DataField="Cliente"
HeaderText="Cliente" SortExpression="Cliente" />
<asp:BoundField DataField="Cdigo
Expediente en despacho" HeaderText="Cdigo Expediente en despacho"
SortExpression="Cdigo Expediente en despacho" />
<asp:BoundField DataField="Cdigo caso
en Juzgado" HeaderText="Cdigo caso en Juzgado" SortExpression="Cdigo caso en
Juzgado" />
<asp:BoundField DataField="Materia"
HeaderText="Materia" SortExpression="Materia" />
<asp:BoundField DataField="Estado"
HeaderText="Estado" SortExpression="Estado" />
<asp:BoundField DataField="Fecha de
Inicio" HeaderText="Fecha de Inicio" SortExpression="Fecha de Inicio" />
<asp:BoundField DataField="Fecha
finalizacin" HeaderText="Fecha finalizacin" SortExpression="Fecha finalizacin"
/>

169

<asp:BoundField DataField="Ciudad"
HeaderText="Ciudad" SortExpression="Ciudad" />
<asp:BoundField DataField="Provincia"
HeaderText="Provincia" SortExpression="Provincia" />
<asp:BoundField DataField="Contraparte"
HeaderText="Contraparte" SortExpression="Contraparte" />
<asp:BoundField DataField="Abg.
Contraparte" HeaderText="Abg. Contraparte" SortExpression="Abg. Contraparte" />
<asp:BoundField DataField="Juez"
HeaderText="Juez" ReadOnly="True" SortExpression="Juez" />
<asp:BoundField DataField="juzgado"
HeaderText="juzgado" SortExpression="juzgado" />
</Columns>
</asp:GridView>
<asp:SqlDataSource ID="SqlDataSource1"
runat="server" ConnectionString="<%$ ConnectionStrings:TESISConnectionString %>"
SelectCommand="buscar_caso_por_cliente_juez" SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter
ControlID="TextBox2" Name="cliente" PropertyName="Text" Type="String" />
</SelectParameters>
</asp:SqlDataSource>
</div>
</asp:Panel>
</div>
</div>
<div class="col-md-0">
<asp:Panel ID="Panel1" runat="server" Visible="False">
<hr />
<h3>Diligencias:</h3>
<div class="table-responsive">
<asp:GridView ID="GridView2" runat="server"
AllowSorting="True" AutoGenerateColumns="False" DataKeyNames="Numero de Diligencia"
DataSourceID="SqlDataSource2" Style="margin-right: 0px">
<Columns>
<asp:CommandField ShowSelectButton="True"
/>
<asp:BoundField DataField="Numero de
Diligencia" HeaderText="Numero de Diligencia" InsertVisible="False" ReadOnly="True"
SortExpression="Numero de Diligencia" />
<asp:BoundField DataField="Tipo de
Diligencia" HeaderText="Tipo de Diligencia" SortExpression="Tipo de Diligencia" />
<asp:BoundField DataField="Fecha de Inicio"
HeaderText="Fecha de Inicio" SortExpression="Fecha de Inicio" />
<asp:BoundField DataField="Fecha de
Finalizacin" HeaderText="Fecha de Finalizacin" SortExpression="Fecha de
Finalizacin" />
<asp:BoundField DataField="Descripcin"
HeaderText="Descripcin" SortExpression="Descripcin" />
<asp:BoundField DataField="Responsable"
HeaderText="Responsable" SortExpression="Responsable" />
<asp:BoundField DataField="Estado"
HeaderText="Estado" SortExpression="Estado" />
<asp:BoundField DataField="id_expediente"
HeaderText="Expediente" SortExpression="id_expediente" />
</Columns>
</asp:GridView>
<asp:SqlDataSource ID="SqlDataSource2"
runat="server" ConnectionString="<%$ ConnectionStrings:TESISConnectionString %>"
SelectCommand="buscar_diligenicias_caso" SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter ControlID="TextBox1"
Name="id_expediente" PropertyName="Text" Type="Int32" />
</SelectParameters>
</asp:SqlDataSource>
</div>
</asp:Panel>

170

<div class="table-responsive">
<table style="width: 100%;">
<tr>
<td>
<div class="col-md-0">
<asp:Panel ID="Panel2" runat="server"
Visible="False">
<h3>Nueva Actividad:</h3>
<hr />
<div class="form-group">
<asp:Label ID="Label5"
runat="server" CssClass="col-md-2 control-label" Font-Bold="True">Descripcin de la
Actividad:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server"
ID="TextBox3" CssClass="form-control" />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label1"
runat="server" CssClass="col-md-2 control-label" Font-Bold="True">Fecha
Actividad:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server"
ID="TextBox4" CssClass="form-control" TextMode="Date" />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label2"
runat="server" CssClass="col-md-2 control-label" Font-Bold="True">Estado
Actividad:</asp:Label>
<div class="col-md-10">
<asp:DropDownList
ID="DropDownList1" CssClass="form-control" runat="server">
<asp:ListItem>Pendiente</asp:ListItem>
<asp:ListItem>Realizado</asp:ListItem>
</asp:DropDownList>
</div>
</div>
<div class="form-group">
<asp:Label ID="Label4"
runat="server" CssClass="col-md-2 control-label" Font-Bold="True">Responsable
Actividad:</asp:Label>
<div class="col-md-10"
style="left: 0px; top: 0px">
<asp:TextBox runat="server"
ID="TextBox6" CssClass="form-control" />
</div>
</div>
<asp:Button ID="Button1"
runat="server" Text="Aceptar" CssClass="btn btn-default" Width="130px" />
<asp:Button ID="Button2"
runat="server" Text="Nueva Actividad" CssClass="btn btn-default" Width="139px" />
<asp:Button ID="Button4"
runat="server" Text="Consultar Actividades" CssClass="btn btn-default"
Width="167px" />
</asp:Panel>
</div>
</td>
<td>
<div class="col-md-0">
<asp:Panel ID="Panel3" runat="server">
<h3>Actividades efectuadas:</h3>
<hr />
<div class="table-responsive">
<asp:DataList ID="DataList1"
runat="server" DataSourceID="SqlDataSource3" GridLines="Both">

171

<ItemTemplate>
Descripcin de la
Actividad:
<asp:Label
ID="Descripcin_de_la_ActividadLabel" runat="server" Text='<%# Eval("[Descripcin
de la Actividad]") %>' />
<br />
Fecha de ejecucin:
<asp:Label
ID="Fecha_de_ejecucinLabel" runat="server" Text='<%# Eval("[Fecha de ejecucin]")
%>' />
<br />
Estado de la Actividad:
<asp:Label
ID="Estado_de_la_ActividadLabel" runat="server" Text='<%# Eval("[Estado de la
Actividad]") %>' />
<br />
Encargado de la
Actividad:
<asp:Label
ID="Encargado_de_la_ActividadLabel" runat="server" Text='<%# Eval("[Encargado de la
Actividad]") %>' />
<br />
<br />
</ItemTemplate>
</asp:DataList>
<asp:SqlDataSource
ID="SqlDataSource3" runat="server" ConnectionString="<%$
ConnectionStrings:TESISConnectionString %>"
SelectCommand="consultar_actividades_por_caso_y_diligencias"
SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter
ControlID="TextBox1" Name="id_caso" PropertyName="Text" Type="Int32" />
<asp:ControlParameter
ControlID="TextBox7" Name="id_diligencia" PropertyName="Text" Type="Int32" />
</SelectParameters>
</asp:SqlDataSource>
</div>
</asp:Panel>
</div>
</td>
</tr>
</table>
</div>
</div>
</div>
</div>
<asp:TextBox ID="TextBox1" runat="server"
Visible="False"></asp:TextBox>
<asp:TextBox ID="TextBox7" runat="server"
Visible="False"></asp:TextBox>
</div>
</div>
</asp:Content>

Agregar_diligencias.aspx
<%@ Page Title="" Language="VB" MasterPageFile="~/Site.master"
AutoEventWireup="false" CodeFile="agregar_diligencias.aspx.vb"
Inherits="web_casos_agregar_diligencias" %>
<asp:Content ID="Content1" ContentPlaceHolderID="MainContent" runat="Server">
<div class="row">
<div class="col-md-0">
<%--<section id="loginForm">--%>
<div class="form-horizontal">

172

<h2>Agregar Diligencias</h2>
<hr />
<h4>Buscar Caso</h4>
<div class="form-group">
<div class="col-md-0">
<asp:Panel ID="Panel1" runat="server">
<%--<div class="form-group">
<asp:Label ID="Label3" runat="server"
CssClass="col-md-2 control-label" Font-Bold="True">Cdigo Caso:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="txt_caso"
CssClass="form-control" />
</div>
</div>--%>
<div class="form-group">
<asp:Label ID="Label1" runat="server"
CssClass="col-md-2 control-label" Font-Bold="True">Cliente:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server" ID="txt_cliente"
CssClass="form-control" />
</div>
</div>
<asp:Button ID="Button3" runat="server" Text="Buscar"
CssClass="btn btn-default" Width="130px" />
</asp:Panel>
<asp:Panel ID="Panel2" runat="server" Visible="False">
<hr />
<div class="table-responsive">
<asp:GridView ID="GridView1" runat="server"
AllowSorting="True" AutoGenerateColumns="False" DataKeyNames="Nmero de Caso"
DataSourceID="SqlDataSource1">
<Columns>
<asp:CommandField ShowSelectButton="True"
/>
<asp:BoundField DataField="Nmero de Caso"
HeaderText="Nmero de Caso" InsertVisible="False" ReadOnly="True"
SortExpression="Nmero de Caso" />
<asp:BoundField DataField="Cdigo caso en
despacho" HeaderText="Cdigo caso en despacho" SortExpression="Cdigo caso en
despacho" />
<asp:BoundField DataField="Cdigo caso en
Juzgado" HeaderText="Cdigo caso en Juzgado" SortExpression="Cdigo caso en
Juzgado" />
<asp:BoundField DataField="Materia"
HeaderText="Materia" SortExpression="Materia" />
<asp:BoundField DataField="Estado"
HeaderText="Estado" SortExpression="Estado" />
<asp:BoundField DataField="Fecha de Inicio"
HeaderText="Fecha de Inicio" SortExpression="Fecha de Inicio" />
<asp:BoundField DataField="Fecha de
Finalizacin" HeaderText="Fecha de Finalizacin" SortExpression="Fecha de
Finalizacin" />
<asp:BoundField DataField="Ciudad"
HeaderText="Ciudad" SortExpression="Ciudad" />
<asp:BoundField DataField="Provincia"
HeaderText="Provincia" SortExpression="Provincia" />
<asp:BoundField DataField="Contraparte"
HeaderText="Contraparte" SortExpression="Contraparte" />
<asp:BoundField DataField="Abg.
Contraparte" HeaderText="Abg. Contraparte" SortExpression="Abg. Contraparte" />
<asp:BoundField DataField="Cliente"
HeaderText="Cliente" SortExpression="Cliente" />
<asp:BoundField DataField="Juez"
HeaderText="Juez" SortExpression="Juez" ReadOnly="True" />
</Columns>
</asp:GridView>

173

<asp:SqlDataSource ID="SqlDataSource1"
runat="server" ConnectionString="<%$ ConnectionStrings:TESISConnectionString %>"
SelectCommand="buscar_actividad" SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter
ControlID="txt_cliente" Name="cliente" PropertyName="Text" Type="String" />
</SelectParameters>
</asp:SqlDataSource>
</div>
</asp:Panel>
<div class="table-responsive">
<table style="width: 100%;">
<tr>
<td>
<div class="col-md-0">
<asp:Panel ID="Panel3" runat="server"
Visible="False">
<hr />
<h3>Nueva Diligencia:</h3>
<hr />
<div class="form-group">
<asp:Label ID="Label5"
runat="server" CssClass="col-md-2 control-label" Font-Bold="True">Tipo de
Diligencia:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server"
ID="TextBox2" CssClass="form-control" />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label6"
runat="server" CssClass="col-md-2 control-label" Font-Bold="True">Fecha de
Inicio:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server"
ID="TextBox3" CssClass="form-control" TextMode="Date" />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label7"
runat="server" CssClass="col-md-2 control-label" Font-Bold="True">Fecha de
Finalizacin:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server"
ID="TextBox4" CssClass="form-control" TextMode="Date" />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label8"
runat="server" CssClass="col-md-2 control-label" FontBold="True">Descripcion:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server"
ID="TextBox5" CssClass="form-control" />
</div>
</div>
<div class="form-group">
<asp:Label ID="Label9"
runat="server" CssClass="col-md-2 control-label" FontBold="True">Encargado:</asp:Label>
<div class="col-md-10">
<asp:TextBox runat="server"
ID="TextBox6" CssClass="form-control" />
</div>
</div>
<div class="form-group">

174

<asp:Label ID="Label10"
runat="server" CssClass="col-md-2 control-label" FontBold="True">Estado:</asp:Label>
<div class="col-md-10">
<%--<asp:TextBox runat="server"
ID="TextBox7" CssClass="form-control" />--%>
<asp:DropDownList
ID="DropDownList1" runat="server" CssClass="form-control">
<asp:ListItem>Pendiente</asp:ListItem>
<asp:ListItem>En
proceso</asp:ListItem>
<asp:ListItem>Realizado</asp:ListItem>
</asp:DropDownList>
</div>
</div>
<asp:Button ID="Button1" runat="server"
Text="Aceptar" CssClass="btn btn-default" Width="130px" />
<asp:Button ID="Button2" runat="server"
Text="Nueva Diligencia" CssClass="btn btn-default" Width="139px" />
<asp:Button ID="Button4" runat="server"
Text="Consultar Diligencias" CssClass="btn btn-default" Width="167px" />
</asp:Panel>
</div>
</td>
<td>
<div class="col-md-0">
<asp:Panel ID="Panel4" runat="server"
Visible="False">
<hr />
<h3>Diligencias efectuadas:</h3>
<hr />
<div class="table-responsive">
<asp:DataList ID="DataList1"
runat="server" DataKeyField="Nmero de diligencia" DataSourceID="SqlDataSource2"
GridLines="Both">
<ItemTemplate>
Nmero de diligencia:
<asp:Label
ID="Nmero_de_diligenciaLabel" runat="server" Text='<%# Eval("[Nmero de
diligencia]") %>' />
<br />
Tipo de Diligencia:
<asp:Label
ID="Tipo_de_DiligenciaLabel" runat="server" Text='<%# Eval("[Tipo de Diligencia]")
%>' />
<br />
Fecha de Inicio:
<asp:Label
ID="Fecha_de_InicioLabel" runat="server" Text='<%# Eval("[Fecha de Inicio]") %>' />
<br />
Fecha de finalizacin:
<asp:Label
ID="Fecha_de_finalizacinLabel" runat="server" Text='<%# Eval("[Fecha de
finalizacin]") %>' />
<br />
Descripcin:
<asp:Label ID="DescripcinLabel"
runat="server" Text='<%# Eval("Descripcin") %>' />
<br />
Encargado:
<asp:Label ID="EncargadoLabel"
runat="server" Text='<%# Eval("Encargado") %>' />
<br />
Estado de diligencia:
<asp:Label
ID="Estado_de_diligenciaLabel" runat="server" Text='<%# Eval("[Estado de
diligencia]") %>' />
<br />

175

id_expediente:
<asp:Label
ID="id_expedienteLabel" runat="server" Text='<%# Eval("id_expediente") %>' />
<br />
<br />
</ItemTemplate>
</asp:DataList>
<asp:SqlDataSource
ID="SqlDataSource2" runat="server" ConnectionString="<%$
ConnectionStrings:TESISConnectionString %>" SelectCommand="consultar_diligencias"
SelectCommandType="StoredProcedure">
<SelectParameters>
<asp:ControlParameter
ControlID="TextBox1" Name="id_expediente" PropertyName="Text" Type="Int32" />
</SelectParameters>
</asp:SqlDataSource>
</div>
</asp:Panel>
</div>
</td>
</tr>
</table>
</div>
</div>
</div>
</div>
<%--</section>--%>
<asp:TextBox ID="TextBox1" runat="server"
Visible="False"></asp:TextBox>
</div>
</div>
</asp:Content>

176

ANEXO 4
IMPLEMENTACIN
La implementacin del SiGEJ se la realiz a travs del IIS 8 y los contenidos se
vern en internet a travs de la siguiente direccin: http://190.152.181.70/sigej
Instalacin de IIS 8
Paso 1: En la pantalla de Inicio nos desplazamos hacia la derecha para que
aparezca la barra de herramientas. Seleccionaremos la opcin de Buscar y
buscaremos el trmino Caractersticas (dentro de la seccin Configuracin)

Figura 79. Seccin configuracn en Windows 8.

Fuente: ngel Cudco

Seleccionamos Activar o desactivar las caractersticas de Windows.

Paso 2: Activaremos la caracterstica Internet Information Services y
pulsaremos Aceptar.

Figura 80. Agregar caractersticas de Windows wen este caso Internet Information Server.

177

Paso 3: Esperaremos a que se instale la caracterstica y listo! ya tenemos en

nuestro Windows 8, IIS instalado.

Figura 81. Instalacin las caractersticas de windows.

Fuente: ngel Cudco

Paso 4: Para confirmar que todo est correctamente instalado, nos vamos a
nuestro navegador y ponemos http://localhost, nos deber cargar una pgina de
la misma forma que en la imagen.

Figura 82. Confirmacin de la correcta instalacin de IIS.

Fuente: ngel Cudco

Paso 5: Para trabajar con IIS 8 es como en sus versiones anteriores, el path
es C:\inetpub\wwwroot

178

PUBLICACIN DEL SISTEMA SIGEJ

Paso 1: Compilamos el SIGEJ en el Visual Studio 2013 y copiar la carpeta del
proyecto al directorio C:\inetpub\wwwroot

Figura 83. Directorio Raz de IIS.

Fuente: ngel Cudco

Paso 2: En el IIS Manager, la carpeta que contiene el SIGEJ la convertimos a

APLICACIN

Figura 84. Convertir la carpeta con el cdigo precompilado en Aplicacin Web

a travs del IIS Manager.
Fuente: ngel Cudco

Paso 3: para verificar el funcionamiento de la aplicacin ingresamos a la

siguiente direccin: http://190.152.181.70/sigej puede ser mediante un
computador:

Figura 85. SIGEJ visto desde un navegador web.

179

SIGEJ visto en un dispositivo mvil:

Figura 86. Sigej visto desde un dispositivo mvil.

Fuente: ngel Cudco

180

ANEXO 5
MANUAL DE USUARIO

181

ANEXO 6
CERTIFICADOS DE LA INSTITUCIN BENEFICIARIA

182