est ndares para el proceso institucional de desarrollo y ... · este manual le mostrará los...

MINISTERIO DE EDUCACIÓN PÚBLICA

ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARROLLO Y

MANTENIMIENTO DE SOFTWARE

CODIGO:

FEBRERO 2012

ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE


Versión: 3.0 Página 2 de 125 15 de febrero 2012

TABLA DE CONTENIDOS

TABLA DE CONTENIDOS ............................... ............................................................... 2

1. INTRODUCCIÓN ...................................................................................................... 8

2. OBJETIVOS ......................................... .................................................................... 9

2.1. Objetivo General .................................. ............................................................. 9

2.2. Objetivos Específicos ............................. ......................................................... 9

3. ALCANCE ........................................... ................................................................... 10

4. DEFINICIONES Y ABREVIATURA ........................ ................................................ 10

4.1. Abreviaturas: ..................................... ............................................................. 10

4.2. Definiciones: ..................................... .............................................................. 10

5. COLABORADORES ..................................... .......................................................... 10

6. ACTUALIZADO POR ................................... .......................................................... 11

7. RESPONSABILIDAD ................................... .......................................................... 11

8. DIRECTRICES ........................................................................................................ 11

9. DOCUMENTACIÓN DEL PROYECTO ........................ ........................................... 11

9.1. MANUAL DE SISTEMA ................................. .................................................. 12

9.2. MANUAL TÉCNICO .................................... ..................................................... 13

9.3. MANUAL DE USUARIO ................................. ................................................. 14

9.4. Especificaciones generales para la entrega del Manu al del Sistema ........ 14

9.5. Rotulación de Disco Compacto....................... .............................................. 15

10. PROCESO ELABORACIÓN DEL PROYECTO .................. ................................ 17

10.1. PREINVERSIÓN ........................................................................................... 17

10.1.1. Identificar el proyecto.............................................................................. 18

10.1.2. Elaborar perfil del proyecto ..................................................................... 18

10.1.3. Analizar pre factibilidad del proyecto ...................................................... 19

10.1.4. Analizar factibilidad del proyecto ............................................................ 24

10.1.5. Elaborar cronograma .............................................................................. 24

10.1.6. Seguimiento y control ............................................................................. 25




10.1.7. Establecer costos (equipo de cómputo, materiales y equipo de trabajo) 25

10.1.8. Diseñar plan para la validación de requerimientos ................................. 26

10.2. PROMOCIÓN, NEGOCIACIÓN Y FINANCIAMIENTO ........... ...................... 26

10.2.1. Diagramas .............................................................................................. 27

10.2.2. Diseño de prototipos ............................................................................... 27

10.2.3. Descripción de entidades, procedimientos y funciones .......................... 30

10.2.4. Plan para la validación del Diseño .......................................................... 31

11. INVERSIÓN O EJECUCIÓN ............................................................................... 31

11.1. PLAN PARA LA VALIDACIÓN DE LA CODIFICACIÓN ........ ..................... 32

11.2. ARQUITECTURA ...................................... ................................................... 32

11.2.1. Estándares para las variables ................................................................ 33

11.2.2. Estándares para la soluciones ................................................................ 33

11.2.3. Reportes y Subreportes .......................................................................... 33

11.2.4. Estándares para las bases de datos ...................................................... 34

11.2.5. Estándares para nombrar objetos .......................................................... 36

11.2.6. Estructura general de los impresos ........................................................ 36

11.2.7. Observaciones Generales de Programación .......................................... 37

11.3. LENGUAJE DE DESARROLLO ............................ ....................................... 40

11.4. MOTOR BASE DE DATOS ............................... ........................................... 40

11.5. ESTÁNDARES GENERALES .............................. ........................................ 40

11.6. PRUEBAS ........................................... .......................................................... 41

11.6.1. Diseño plan de pruebas .......................................................................... 41

11.6.2. Aprobación del Plan................................................................................ 45

11.6.3. Seguimiento y Reporte de Defectos ....................................................... 46

11.7. CAPACITACIÓN ...................................... ..................................................... 46

12. OPERACIÓN O FUNCIONAMIENTO ........................ ......................................... 47

12.1. EVALUACIÓN DEL PROYECTO ........................... ...................................... 48

12.1.1. Evaluación operacional ........................................................................... 48

12.1.2. Impacto organizacional ........................................................................... 48




12.1.3. Opinión de los administradores .............................................................. 48

12.1.4. Desempeño del desarrollo ..................................................................... 48

14. ANEXOS.............................................................................................................. 50

14.1. ANEXO No. 1 ....................................... ......................................................... 51

14.2. ANEXO No. 2 ....................................... ......................................................... 53

14.2.1. Rotulación de Disco Compacto parte externa ........................................ 53

14.2.2. Rotulación de Disco Compacto superficie del disco ............................... 54

14.3. ANEXO No. 3 ....................................... ......................................................... 55

14.3.1. Plantilla Requerimientos ......................................................................... 55

14.4. ANEXO No. 4 ....................................... ......................................................... 57

14.4.1. Cronograma de Actividades ................................................................... 57

14.5. ANEXO No. 5 ....................................... ......................................................... 59

14.5.1. Costos (Equipo de cómputo, materiales y equipo de trabajo) ................ 59

14.6. ANEXO No. 6 ...................................... ......................................................... 60

14.6.1. Plan Validación de Requerimientos ........................................................ 60

14.7. ANEXO No. 7 ....................................... ......................................................... 61

14.7.1. Acta Aceptación de la fase Preinversión ............................................... 61

14.8. ANEXO No. 8 ....................................... ......................................................... 62

14.8.1. Diagrama de casos de uso ..................................................................... 62

14.8.2. Ejemplo de Cuadro Resumen Requerimientos/Casos de Uso ............... 63

14.9. ANEXO No. 9 ....................................... ......................................................... 64

14.9.1. Diagramas de secuencia ........................................................................ 64

14.10. ANEXO No. 10 ...................................... ........................................................ 65

14.10.1. Diagramas Conceptuales ....................................................................... 65

14.11. ANEXO No. 11 ...................................... ........................................................ 66

14.11.1. Diagrama de Base de Datos o Diagrama Entidad-Relación (DER) ........ 66

14.12. ANEXO No. 12 ...................................... ........................................................ 67

14.12.1. Diccionario de Datos (DD) ...................................................................... 67

14.13. ANEXO No. 13 ...................................... ........................................................ 68




14.13.1. Prototipos de formularios ........................................................................ 68

14.14. Anexo 14. ......................................... ............................................................ 69

14.14.1. Formularios de Ingreso (Login) ............................................................... 69

14.14.2. Formulario Principal ................................................................................ 70

14.14.3. Menú dentro del formulario principal....................................................... 71

14.14.4. Formularios de Mantenimiento ............................................................... 72

14.14.5. Formularios de Consulta ......................................................................... 74

14.14.6. Formularios de Modificar la Contraseña ................................................. 75

14.14.7. Formularios de Mantenimiento ............................................................... 76

14.14.8. Formularios de Actualización .................................................................. 77

14.15. ANEXO No. 15 ...................................... ........................................................ 78

14.15.1. Prototipo de informes.............................................................................. 78

14.16. ANEXO No. 16 ...................................... ........................................................ 79

14.16.1. Tabla de Entidades del Sistema ............................................................. 79

14.17. ANEXO No. 17 ...................................... ........................................................ 80

14.17.1. Tabla de los requerimientos de los procesos del sistema ...................... 80

14.18. ANEXO No. 18 ...................................... ........................................................ 81

14.18.1. Plan para la Validación del Diseño ......................................................... 81

14.19. ANEXO No. 19 ...................................... ........................................................ 82

14.19.1. Acta aceptación Fase ............................................................................. 82

14.20. ANEXO No. 20 ...................................... ........................................................ 83

14.20.1. Estándares para tipos de datos .............................................................. 83

14.20.2. Iconos que se deben utilizar en las aplicaciones .................................... 84

14.20.3. Objetos para Visual Basic .Net ............................................................... 86

14.20.4. Objetos para Visual Basic .NET ............................................................. 87

14.21. ANEXO No. 21 ...................................... ........................................................ 88

14.21.1. Plan para la Validación de la Codificación .............................................. 88

14.22. ANEXO No. 22 ...................................... ........................................................ 89

14.22.1. Plan pruebas .......................................................................................... 89




14.23. ANEXO No. 23 ...................................... ........................................................ 90

14.23.1. Informe de la Prueba ............................................................................. 90

14.24. ANEXO No. 24 ...................................... ........................................................ 91

14.24.1. Seguimiento y Reporte de Defectos ....................................................... 91

14.25. ANEXO No. 25 ...................................... ........................................................ 92

14.25.1. Acta Aceptación Fase ............................................................................. 92

14.26. ANEXO No. 26 ...................................... ........................................................ 93

14.26.1. Acta Aceptación oficial del Sistema ........................................................ 93

14.27. ANEXO No. 27 ...................................... ........................................................ 94

14.27.1. Plan de Capacitación .............................................................................. 94

14.28. ANEXO No. 28 ...................................... ........................................................ 95

14.28.1. Documento Aceptación de la Capacitación ............................................ 95

14.29. ANEXO No. 29 ...................................... ........................................................ 96

14.29.1. Evaluación del Proyecto ......................................................................... 96

14.30. ANEXO No. 30 ...................................... ........................................................ 97

14.30.1. Minuta ..................................................................................................... 97

14.31. ANEXO No. 31 ...................................... ........................................................ 98

14.31.1. Manual de Programación según los estándares Web ............................ 98

Tabla de Contenido Manual de Estándar de Programaci ón WEB ........................... 99

1. Manual de Estándar de Programación Web ............ ......................................... 100

2. Estándares para las Soluciones .................... .................................................... 100

3. Diseño ............................................ ...................................................................... 102

3.1. Plantilla ......................................... ................................................................. 102

3.2. Hojas de Estilo ................................... ........................................................... 103

3.3. Archivos Javascript ............................... ...................................................... 103

3.4. Menú .............................................. ................................................................ 105

4. Seguridad ......................................... ................................................................... 107

4.1. Arquitectura de Seguridad en la Base de Datos ..... ................................... 107

4.2. Esquematización del Menú .......................... ................................................ 109




4.3. Modo de Autenticación en webconfig ................ ........................................ 110

4.4. Cookies ........................................... .............................................................. 110

4.5. Proceso de Construcción del Menú: ................. ......................................... 111

5. Adicionales ....................................... ................................................................... 118

5.1. Búsqueda detallada en formularios de Mantenimiento ............................ 118

5.2. Consideraciones para la creación de la Búsqueda Det allada .................. 119

15. CONCLUSIÓN ................................................................................................... 123

16. BIBLIOGRAFÍA ...................................... ........................................................... 124

HOJA DE REVISIÓN Y ACEPTACIÓN ..................... .......... ¡Error! Marcador no definido.




1. INTRODUCCIÓN

El presente es un instrumento que instruye al desarrollador de sistemas del Ministerio de Educación Pública y a los desarrolladores externos contratados por este ministerio sobre los procesos a seguir a la hora de realizar un sistema de información computarizado.

Este manual le mostrará los lineamientos generales basándose en el ciclo de desarrollo de software V que permite el aseguramiento de la calidad de los sistemas.

Es una tarea innovadora que involucra un conjunto ordenado de antecedentes, actividades planificadas y relacionadas entre sí, que requiere la decisión sobre el uso de recursos que señalan alcanzar objetivos definidos, a efectuarse en un cierto periodo, en una zona geográfica delimitada y para un grupo de afectados (stakeholders), solucionando problemas, mejorando una situación o satisfaciendo una necesidad y de esta manera contribuir a los objetivos de desarrollo del país.

La administración de proyectos1 ocurre cuando se da énfasis y atención especial para conducir actividades no repetitivas con el propósito de lograr un conjunto de metas. Esta actividad es llevada a cabo por un conjunto de coordinadores de proyectos que actúan como agentes unificadores para proyectos particulares, tomando en cuenta los recursos existentes, tales como el tiempo, materiales, capital, recursos humanos y tecnología. Además, sirve para aprovechar de mejor manera los recursos críticos cuando están limitados en cantidad y/o tiempo de disponibilidad. También ayuda a realizar acciones concisas y efectivas para obtener el máximo beneficio.

1 Todo proyecto de Tecnología del Ministerio de Educación Pública debe realizarse con base en el Manual Estándar para el desarrollo de un proyecto TI.




2. OBJETIVOS

2.1. Objetivo General

Establecer los estándares que permitan describir detalladamente los procesos de captura, diseño, validación, selección, manipulación, procesamiento, conservación y aseguramiento de la información con el fin de mejorar el proceso de toma de decisiones de los analistas.

2.2. Objetivos Específicos

2.2.1. Definir la documentación pertinente de un sistema de información desde que se inicia hasta que finalice, con el fin de cumplir con los procesos permanentes de captura, diseño, validación, selección, manipulación, procesamiento, conservación y aseguramiento de la información.

2.2.2. Describir todas las actividades del ciclo de vida de un sistema para garantizar el cumplimiento de las normas técnicas para la gestión y el control de las tecnologías de información.

2.2.3. Asignar responsabilidades en el establecimiento de los mecanismos de control, revisión y aprobación para las etapas del proyecto y para su finalización “Gestión de proyectos”.

2.2.4. Diseñar instrumentos de actuación pública que fomenten la modernización de las herramientas de gestión empresarial a través de la implantación de estándares y lineamientos adecuados a las necesidades a través de la promoción del diagnóstico como paso previo y necesario para la ejecución de inversiones.




3. ALCANCE

Este manual tiene como finalidad de instruir y guiar al personal de Informática de Gestión o al personal de la entidad que se contrate para la implementación de un nuevo sistema en el momento que tengan que realizar la documentación del sistema que están construyendo, ya que son temas específicos que deben de llevarse a cabo al pie de la letra, porque son los que guiarán al usuario final a entender el por qué y cómo fue que se llevó a cabo el sistema en cuestión, y por consiguiente su forma de usarlo.

4. DEFINICIONES Y ABREVIATURA

4.1. Abreviaturas:

MEP: Ministerio de Educación Pública.

DIG: Dirección de Informática de Gestión.

Rx: se utiliza esta nomenclatura para definir los diferentes requerimientos, ‘x’ equivale al número de requerimiento, por ejemplo: R1 = Requerimiento 1.

IR: Ingeniería de Requerimientos.

OE: Objetivos Específicos.

REQ: Requerimiento.

4.2. Definiciones:

Stakeholders: Es aquella persona o entidad que está interesada en la realización de un proyecto o tarea, auspiciando el mismo ya sea mediante su poder de decisión o de financiamiento, o a través de su propio esfuerzo.

5. COLABORADORES

MARI. Kattia Paniagua Alfaro, Departamento de Innovación y Control Informático, setiembre 2009. Lic. John Mehlbaum Ucañan, Departamento de Soporte Técnico, setiembre 2009. Licda. Caroline Gutiérrez, Departamento de Sistemas de Información, setiembre 2009. Licda. Jacqueline Sequeira Torres, Departamento de Sistemas de Información, setiembre 2009.




Licda. Marcela Ramírez Rojas, Departamento de Innovación y Control Informático, setiembre 2009. Ing. Fabio López Alfaro, Departamento de Sistemas de Información, setiembre 2009.

6. ACTUALIZADO POR

Licda. Grettel Sánchez Calvo, Departamento de Sistemas de Información, abril 2011. Lic. José Martín Sanchún Macín, Departamento de Innovación y Control Informático, febrero 2012.

7. RESPONSABILIDAD

Los responsables inmediatos de hacer que se cumpla lo estipulado en este manual, serán los jefes de cada Dirección que tengan a cargo proyectos de realización de sistemas de información, cada jefe debe de dar la directriz a sus subordinados o a la entidad contratada, ya que para comenzar a realizar cada sistema deben cumplir con todo lo que se indica en este manual.

8. DIRECTRICES

El departamento de Innovación Tecnológica y Control Informático, será el responsable por medio de las listas de verificación de que se cumpla lo estipulado en todo el contenido de este manual.

No será justificado, el hecho de no haber cumplido con lo estipulado en el presente manual, ya que con ello, se estaría incumpliendo con las Normas técnicas para la gestión y el control de las tecnologías de información (N-2-2007-CO-DFOE).

9. DOCUMENTACIÓN DEL PROYECTO

La documentación oficial debe contener:




9.1. MANUAL DE SISTEMA

• Introducción • Objetivo General • Objetivos específicos • Fase I. PREINVERSION

• Preinversión • Identificación del proyecto • Perfil • Prefactibilidad • Factibilidad • Cronograma • Costos • Plan para la validación de requerimientos • Acta aceptación Fase Preinversión

• Fase II. PROMOCIÓN, NEGOCIACIÓN Y FINANCIAMIENTO • Diagrama de casos de uso • Diagramas de secuencia • Diagramas Conceptuales • Prototipos de formularios • Prototipos de informes • Descripción de entidades, procedimientos y funciones • Diagrama de Base de Datos • Diccionario de Datos • Plan para la validación del diseño • Acta aceptación Fase Promoción, Negociación y Financiamiento

• Fase III. INVERSIÓN O EJECUCIÓN • Plan para la validación de la codificación • Presentación de prototipos a los usuarios • Resultado pruebas • Plan Capacitación • Acta aceptación Fase Inversión o Ejecución

• Fase IV. Operación o Funcionamiento




• Evaluación del proyecto • Acta aceptación Fase Operación o funcionamiento

• Conclusión • Glosario • Bibliografía

9.2. MANUAL TÉCNICO

Todo manual técnico se debe presentar como mínimo con las siguientes secciones:

• Portada

• Tabla de contenidos

• Introducción

• Objetivo General

• Objetivos Específicos

• Describir detalladamente las herramientas, base de datos y componentes que forman el sistema diseñado

• Debe describir detalladamente el instalador usado y sus componentes, además de los pasos exactos para que el Sistema sea instalado donde sea necesario.

• Descripción de las tablas que componen la base de datos ya sean internas y externas.

• Debe agregar el código y una explicación de los procedimientos almacenados o no almacenados, trigger, funciones, scripts utilizados en el Sistema.

• Debe agregar todas las pantallas e informes que formen el sistema, y una explicación que sucede cuando se modifican los datos, que campos cambian, que procedimientos o funciones intervienen, que tablas se afectan.

• Debe agregar un diagrama Entidad-Relación.

• Diccionario de términos (Glosario)

• Anexos




9.3. MANUAL DE USUARIO

Todo manual usuario se debe presentar como mínimo las siguientes secciones:

• Portada

• Tabla de contenidos

• Introducción

• Objetivo General

• Objetivos Específicos

• Descripción detallada de cada uno de los módulos y componentes que forman el sistema, ilustrándose con todas las pantallas e informes posibles.

• Narrar qué sucede cuando se modifican los datos.

• Narrar cómo se solucionan los problemas más comunes

• Diccionario de términos (Glosario)

• Anexos

Importante:

Debe incluir la versión digital en el menú Ayuda del sistema desarrollado.

El estándar para la presentación de los tres documentos mencionados debe apegarse a los lineamientos que se solicitan en el anexo No.1

9.4. Especificaciones generales para la entrega del Manual del Sistema

Los documentos deben ser entregados a la Comisión de Calidad y Desarrollo para su análisis.

Todos los cambios, nuevos requerimientos, aprobación del sistema u otros, deben respaldarse con un documento que tenga el formato oficial y firmado por ambas partes,




NO SE DEBE REALIZAR NINGUN CAMBIO SIN LA FIRMA DE ACEPTACION DEL INTERESADO.

Todos los documentos para realizar los cambios, las minutas de las reuniones (ver anexo No. 30), aprobación del sistema y/u otros documentos utilizados durante el análisis, desarrollo, puesta en marcha de los sistemas deben ser archivados al final del Manual del Sistema.

El Jefe de Control de Calidad o el profesional asignado de la Dirección de Informática de Gestión tiene la obligación de revisar la documentación, los avances y el código del Sistema, durante o al final de este, para emitir un reporte a la DIG.

Se debe entregar el acta de entrega final de sistema que deberá ser firmada por los interesados para hacer constar la entrega del sistema y toda la documentación pertinente.

Si un sistema ya finalizado es sujeto de un nuevo requerimiento el ciclo deberá incluirse en la etapa de Operación y Funcionamiento según se explica más adelante.

9.5. Rotulación de Disco Compacto

El analista desarrollador debe entregar un disco compacto con toda la información electrónica del Sistema y los instaladores. El disco compacto debe ser entregado en un estuche, éste por la parte externa debe tener la siguiente rotulación:

Ministerio de Educación Pública

Dirección de Informática de Gestión o nombre de la entidad externa que desarrolla

Departamento de Sistemas de Información o departamento de la entidad externa que desarrolla el software

Nombre del Proyecto

Contenido del disco

Funcionario que entrega la información/Fecha

Funcionario que graba la información/Fecha




Funcionario que verifica la información/Fecha

Para más detalle de como debe de quedar la caratula en al parte externa ver anexo No. 2.

Si en el Departamento hay impresora para hacerle carátula al disco compacto éste debe llevar impreso la siguiente información Además el disco compacto debe llevar impreso la siguiente información:

1. Nombre de la Institución

2. Nombre de la Dirección a la que se desarrolla el software

3. Fecha de entrega del disco compacto.

4. Versión del software: Una versión, revisión o edición de un producto, es el estado en el que se encuentra en un momento dado en su desarrollo o modificación. La nomenclatura oficial es:

VERSIÓN DESCRIPCIÓN

1.0 Versión inicial

1.0.1 Modificación simple versión inicial

2.0 Modificación compleja versión inicial 1.0 (cambios muy importantes o de estructura)

2.0.1 Modificación simple versión 2.0

2.0.2 Modificación simple versión 2.0.1

5. Detalle del contenido del disco compacto.

6. Nombre de la Dirección de Informática.

7. Nombre del sistema que se desarrollo.

8. Nombre del departamento al que se le desarrolla el software.

Para más detalle de como debe de quedar la caratula en la superficie del disco ver anexo No. 2




10. PROCESO ELABORACIÓN DEL PROYECTO

Los proyectos se llevarán a cabo tomando en cuenta las siguientes fases:

• Pre inversión

• Promoción, negociación y financiamiento

• Inversión o ejecución

• Operación y funcionamiento.

El modelo de ciclo de vida del software que se utilizará es el Ciclo V, que proviene del principio que cuando estoy en las etapas de la izquierda de la V, debo definir como lo voy a probar cuando esté a la derecha.

Este ciclo está reflejado en todas las etapas del proyecto.

10.1. PREINVERSIÓN

Etapa(s) del Ciclo de Vida V: Investigación Preliminar y Análisis de Requerimientos




Entregable(s): - Documento Investigación preliminar

- Acta aceptación Fase I PREINVERSIÓN ver acta en el anexo No. 7.

Es la fase donde se elabora el documento base del proyecto (ver estándares de formato en el anexo No. 1). En esta etapa se realizan todos los estudios y estimaciones tendentes a determinar la factibilidad y viabilidad de los proyectos.

10.1.1. Identificar el proyecto

Un proyecto a nivel de su identificación, implica información muy precisa y básica sobre algunas variables que permiten visualizar el problema o la necesidad a resolver, la vialidad desde la perspectiva de las estrategias de desarrollo institucional, la disponibilidad o posibles recursos. Debe indicar:

• Nombre del proyecto

• Definición del problema

• Administrador del proyecto

• Dependencia o instancia que lo solicita

• Organización que ejecuta

• Dependencia asignada a ejecutar

• Recurso Humano a participar en el proyecto (contactos principales)

10.1.2. Elaborar perfil del proyecto

Un proyecto a nivel de perfil, es un documento bien estructurado, coherente, con cierto grado de información y análisis de los siguientes aspectos: contexto del proyecto, antecedentes, necesidad/problema, justificación, objetivos, metas, aspectos técnicos, financieros, económicos-sociales y ambientales del proyecto. Este documento debe permitir al responsable los elementos necesarios para tomar ciertas decisiones sobre el proyecto.




• Objetivo General y Específicos

• Descripción Detallada del Problema

• Evaluación de la situación actual (modo de operación)

• Alcance y Limitación del Proyecto

Si el proyecto es brindar mantenimiento a una aplicación, además de las actividades anteriores debe indicar:

• Descripción detallada de las modificaciones solicitadas.

• Establecer impacto del cambio.

10.1.3. Analizar pre factibilidad del proyecto

Un proyecto a nivel de pre factibilidad, es un documento bastante acabado, coherente, con información y análisis muy profundo sobre variables importantes como: el mercado, la tecnología, la rentabilidad financiera, económica-social e impacto ambiental. Es un documento completo con niveles mínimos de incertidumbre y facilita al gerente la toma de decisiones sobre el proyecto.

• Análisis de Insumos .

• Requerimientos

• Costos .

Análisis de Insumos (descripción del equipo de cómputo, mobiliario y materiales de oficina, especificaciones de herramientas de desarrollo, descripción del equipo de trabajo informático y contraparte).

Análisis de Requerimientos o Ingeniería de Requerim ientos especificaciones de las funciones que debe realizar el sistema solicitado o las modificaciones a un software existente, en listado numerado como sigue: R1, R2, R3…) Debe utilizar herramientas como observación, entrevista y cuestionarios. Además de llenar la plantilla de requerimientos como se muestra en el anexo No. 3.




Los requerimientos de un sistema de software, son extensos y detallados, y además contienen múltiples relaciones entre sí. Los requerimientos se deben descubrir antes de empezar a construir un producto, y que puede ser algo que el producto debe hacer o una cualidad que el producto debe tener. Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o porque el cliente quiere que ese requerimiento sea parte del producto final. Así que si no se tienen los requerimientos correctos, no se puede diseñar o construir el producto correcto y, consecuentemente, el producto no permitirá a los usuarios finales realizar su trabajo.

Entonces, "Ingeniería de Requerimientos" se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto determinado. El uso del término "ingeniería" implica que se deben utilizar técnicas sistemáticas y repetibles para asegurar que los requerimientos del sistema estén completos y sean consistentes y relevantes.

Actividades de la Ingeniería de Requerimientos

Usualmente podemos dividir las prácticas de la IR en 4 actividades, a saber:

• Extracción • Análisis • Especificación • Validación

Como toda división de tareas, no es una estricta representación de la realidad, sino que se hace con el fin de sistematizar la realización de la IR. En general la delimitación entre una actividad y la otra no es tan clara, ya que están sumamente interrelacionadas, existiendo un alto grado de iteración y retroalimentación entre una y otra.

• Extracción:

Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requerimientos del sistema. Aquí, los analistas deben trabajar junto al cliente para descubrir el problema




que el sistema debe resolver, los diferentes servicios que el sistema debe prestar, las restricciones que se pueden presentar, etc.

Pero, en definitiva, descubrir los requerimientos del sistema no sólo implica preguntar a las personas qué quieren: es un proceso delicado que involucra comprender el domino de aplicación, es decir, obtener un conocimiento del área general de aplicación del sistema; comprender el problema en sí, lo que implica que se debe extender y especializar el conocimiento sobre el dominio general para que se aplique al cliente en particular; comprender el negocio, por tanto, se debe entender en profundidad cómo es que este sistema interactuará afectará a las partes del negocio que estarán involucradas y cómo puede contribuir a lograr las metas de la empresa; finalmente, comprender las necesidades y restricciones de los usuarios del sistema, en particular, se deben entender los procesos de trabajo que se supone que el sistema apoyará y el rol de cualquier otro sistema que actualmente se involucre en dichos procesos.

Es importante, entonces, que la extracción sea efectiva, ya que la aceptación del sistema dependerá de cuán bien éste satisfaga las necesidades del cliente y de cuán bien asista a la automatización del trabajo.

• Análisis:

Sobre la base de la extracción realizada previamente, comienza esta fase -que se presenta sumamente compleja en un proyecto donde el dominio es desconocido- en la cual se apunta a descubrir problemas con los requerimientos del sistema identificados hasta el momento.

Usualmente se hace un análisis luego de haber producido un bosquejo inicial del documento de requerimientos; aquí se leen los requerimientos, se conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones con el cliente para discutir los requerimientos.

Debemos destacar que no es posible convertir el análisis en un proceso estructurado y sistemático, lo que convierte a esta etapa en "subjetiva" porque depende en gran medida del juicio y de la experiencia del analista.




• Especificación:

En esta fase se documentan los requerimientos acordados con el cliente, en un nivel apropiado de detalle.

En la práctica, esta etapa se va realizando conjuntamente con el análisis, pero podríamos decir que la Especificación es el "pasar en limpio" el análisis realizado previamente aplicando técnicas y/o estándares de documentación, como la notación UML.

• Validación:

La validación es la etapa final de la IR. Su objetivo es, valga la redundancia, validar los requerimientos, es decir, verificar todos los requerimientos que aparecen en el documento especificado para asegurarse que representan una descripción, por lo menos, aceptable del sistema que se debe implementar. Esto implica verificar que los requerimientos sean consistentes y que estén completos.

La validación representa un punto de control interno y externo; interno, porque se debe verificar internamente lo que se está haciendo, y externo, porque se debe validar con el cliente.

Preferentemente, el documento de requerimientos obtenido en la etapa anterior sólo debería incluir los requerimientos que son aceptables para los usuarios. Pero es inevitable que durante la validación se descubran algunos problemas relacionados con los usuarios, y esto se debe corregir antes de aprobarse el documento final de requerimientos.

En definitiva, la validación de especificaciones realmente significa asegurarse de que el documento de requerimientos represente una descripción clara del sistema, y es una verificación final de que los requerimientos cubren las necesidades de los usuarios.

Esta etapa puede confundirse con la de análisis, pero la diferencia es clara: mientras que en el análisis se trabaja sobre el boceto del documento de requerimientos, en la validación se utiliza el documento final, lo que equivale a decir, los requerimientos "depurados".




Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema. Esto se logra mediante al clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos.

El análisis de requerimientos consiste brevemente en los siguientes pasos:

• Obtener información acerca de lo que los usuarios desean

• Clasificar esos deseos para comenzar a estructurar requerimientos

• Identificar los niveles de jerarquía del sistema y empezar a alojar los ya clasificados requerimientos en cada nivel.

• Especificar formalmente los requerimientos de acuerdo al nivel de audiencia que se desea.

Si los requerimientos se enfocan a describir las necesidades del cliente, entonces es lógico que para recabarlos haya que obtener la información de los usuarios que van interactuar con el sistema por desarrollar. Esto es, mediante entrevistas con el cliente y/o usuarios recabando documentación que describa la manera que el cliente desea que funcione el sistema de software.

Las necesidades y/o requerimientos del cliente evolucionan con el tiempo y cada cambio involucra un costo. Por eso es necesario tener archivada una copia de la documentación original del cliente, así como cada revisión o cambio que se haga a esta documentación




Como cada necesidad del cliente es tratada de diferente forma, es necesario clasificar estas necesidades para saber cuáles de ellas serán satisfechas por el software y cuales por algún otro producto del sistema.

Los requerimientos son el punto de acuerdo entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente y/o usuario.

10.1.4. Analizar factibilidad del proyecto

Un proyecto a nivel de factibilidad, es documento completo con toda la información y análisis sobre las variables del proyecto, contempla un análisis de los diversos escenarios en que podría actuar el proyecto, desde el punto de vista de su evaluación incorpora todos los indicadores financieros, económicos y ambientales, un análisis de sensibilidad sobre las variables más críticas o incertidumbres para visualizar su comportamiento y posible viabilidad, con un nivel aceptable de incertidumbre y facilitar al gerente la toma de decisiones sobre el proyecto.

• Identificación y discusión de alternativas de solución.

• Costos para cada alternativa de solución.

• Restricciones operativas y técnicas.

• Análisis de requerimientos de ancho de banda. Identificar número de usuarios que utilizarán la aplicación y si ésta es de consulta o introducción de datos.

• Programación de actividades.

• Análisis de Costo/Beneficio (Evaluar que tanto son los costos respecto a los beneficios; ya que a cada dependencia se le asigna determinado presupuesto).

• Aprobación por escrito del usuario.

10.1.5. Elaborar cronograma

Se debe usar para controlar e ir evaluando las actividades que se realicen y corregir cualquier tipo de desviación con la programación vigente, para lograr el cumplimiento de las etapas definidas con anterioridad.




Cualquier desviación debe quedar documentada, firmada e informada, la programación inicial no debe ser cambiada. Se debe realizar un cronograma con el formato y las actividades detalladas a continuación. Además el Ingeniero debe incluir todas las actividades en el Sistema Gestor de Proyectos y actualizar periódicamente las fechas de inicio, fin, porcentaje de avance y estado de las actividades.

Cuando se preparen los cronogramas se debe tener en cuenta el tiempo para pruebas, preparación de manuales y la capacitación a los usuarios del sistema. Para este último, debe estimar el porcentaje de funcionarios que podrán ser capacitados (no menos del 50% de los usuarios de la aplicación), en caso de que alguno no pueda tomarse en cuenta, los capacitados servirán como multiplicadores en la oficina correspondiente. (Ver cronograma de actividades en el anexo No. 4)

10.1.6. Seguimiento y control

El Equipo de Dirección de Proyectos2 designará un funcionario para brindar seguimiento al proceso de elaboración del proyecto y éste se encargará de controlar que se cumplan todas las actividades en el tiempo establecido.

En caso de atrasos, se deben realizar los ajustes necesarios para que el plazo de entrega del proyecto se cumpla.

10.1.7. Establecer costos (equipo de cómputo, materiales y equipo de trabajo)

Es la fase donde se elabora el documento del proyecto, en esta etapa se realizan todos los estudios y estimaciones tendentes a determinar la factibilidad y viabilidad de los proyectos. Consiste en identificar los proyectos, formularlos, evaluarlos y seleccionar los más rentables desde el punto de vista del mercado, técnico, financiero, económico, social y ambiental. (Realizar una tabla como se muestra en el anexo No. 5)

2 Refiérase al Manual de Estándar para el Desarrollo de un Proyecto “Aspectos Generales” ítem 8.




10.1.8. Diseñar plan para la validación de requerimientos

En este apartado se debe definir los casos de prueba que utilizará en las pruebas de integración y de aceptación . Los mismos deben garantizar que se cumpla con los requerimientos anotados en el punto 10.1.3 (Ver plan en el anexo No. 6).

Importante:

Es obligatorio concluir esta etapa con el acta de aprobación. (Ver acta en el anexo No. 7)

10.2. PROMOCIÓN, NEGOCIACIÓN Y FINANCIAMIENTO

Etapa(s) del Ciclo de Vida V: Diseño del Sistema

Entregable(s): -Documento Diseño del sistema

- Acta aprobación Prototipo

- Acta aprobación Fase II Promoción, Negociación y Financiamiento (Ver Acta en el anexo No. 19)

Comprende todos los aspectos relacionados con la negociación de los recursos necesarios para realizar el proyecto, en especial, los financieros. Así como, las acciones para promocionar y divulgar el proyecto ante las autoridades y entidades vinculadas al mismo y que en alguna medida son responsables y deben brindar las aprobaciones correspondientes para hacer una realidad el proyecto. El resultado básico de esta fase, es la viabilidad del proyecto y la aprobación del financiamiento.

Esta etapa es fundamental para garantizar la implementación del proyecto. Generalmente sirve de ligamento entre la etapa de pre inversión y la de inversión.

El resultado básico de esta fase es la viabilidad del proyecto y la aprobación del financiamiento en caso de que sea con un convenio externo. La viabilidad se da desde la perspectiva de la comunidad beneficiaria del proyecto. En esta sección presentamos un análisis y diseño del sistema.

En esta fase se pretende confeccionar diferentes diagramas que le permitan a los interesados (tanto el solicitante como el ente facilitador) formarse una opinión del




proyecto o sistema para así poder emitir un criterio de aprobación/denegación del mismo.

10.2.1. Diagramas

Diagrama de casos de uso (ver ejemplo en el anexo No. 8)

Diagramas de secuencia (ver ejemplo en el anexo No. 9)

Diagramas Conceptuales (ver ejemplo en el anexo No. 10)

Diagrama de Base de Datos (ver ejemplo en el anexo No. 11)

Diccionario de Datos (ver ejemplo en el anexo No. 12)

10.2.2. Diseño de prototipos

Es la técnica para la recopilación rápida de requerimientos de información de los usuarios. Los prototipos se deben hacer tempranamente en el ciclo de vida del desarrollo de sistemas, con el propósito de buscar reacciones iniciales de los usuarios y de la administración hacia el prototipo, sugerencias, planes de revisión, innovaciones; cuando se realiza el desarrollo puede tener o no el mismo diseño, pero si debe tener las mismas estructuras.

10.2.2.1. Prototipos de formularios

Debe haber una explicación en qué consiste el formulario, que datos y tablas se actualizan, con cual otro sistema interactúa, de que requerimientos del usuario forman parte (R1, R2). (Ver formulario de prototipos en anexo No. 13)




10.2.2.2. Estándares para el uso de los formularios.

La política del Ministerio de Educación Pública es que toda nueva aplicación debe desarrollarse como sistemas que los usuarios puedan utilizar accediendo a un servidor web a través de Internet o de una intranet mediante un navegador (aplicaciones Web).

Aplicaciones Web

Al igual que en la programación de aplicaciones de escritorio (Windows form) se debe mantener en el nombre de los formularios el prefijo ‘frm’ seguido de la descripción del formulario en singular.

• Formularios de Ingreso (Login)

Estos formularios se utilizan con el fin de identificar y autentificar el usuario que ingresará al sitio web o sistema. El nombre de formulario de ingreso se fijará de la siguiente manera: utilizando el prefijo ‘frm’, seguido de la palabra Ingreso, de la siguiente manera frmIngreso. (Ver estándar del formulario en el anexo No. 14)

• Formulario Principal

Este formulario es el que se encuentran al ingresar al sistema y que sirve como menú general de ingreso al resto del sistema.

Ver ejemplo del menu dentro del formulario principal en el anexo No. 14

El nombre este formulario será el prefijo ‘frm’ seguido de la palabra Principal, de la siguiente forma: frmPrincipal.

(Ver estándar del formulario en el anexo No. 14)

• Formularios de Mantenimiento

Los formularios de este tipo son los que se utilizan para realizar las transacciones básicas de agregar, modificar o eliminar.




El nombre de estos formularios se asignarán de la siguiente manera: el prefijo ‘frm’, seguido de la palabra Mantenimiento y el nombre de la tabla a la cual esta afectando el mantenimiento. Asi por ejemplo frmMantenimientoUniversidades. (Ver estándar del formulario en el anexo No. 14).

• Formularios de Consulta

Los formularios de consulta se crean con el fin de realizar busquedas parametrizadas de diferentes datos.

Para asignar el nombre a estos formularios se coloca el prefijo ‘frm’, seguido de la palabra Consulta y la tabla que se esta consultando. Por ejemplo frmConsultaEmpleados. (Ver estándar del formulario en el anexo No. 14)

• Formularios de Modificar la Contraseña

Este tipo de formularios se realizan con el fin de que el usuario del sistema pueda cambiar su contraseña de ingreso al sistema.

Para asignar el nombre a estos formularios se coloca el prefijo ‘frm’, seguido de las palabras ModificarContraseña. Por ejemplo frmModificarContraseña. (Ver estándar del formulario en el anexo No. 14)

Aplicaciones Cliente/Servidor

En caso de que se trate de una modificación a una aplicación existente, desarrollada Cliente/Servidor, debe observar los siguientes estándares:

Para todos los formularios de un proyecto el nombre se debe definir utilizando el prefijo “frm” seguido de la descripción del formulario en singular. Por ejemplo: frmAccesosUsuario

• Formularios de Mantenimiento




Estos son los formularios que se crean con el propósito de realizar las transacciones de insertar, modificar, eliminar y consultar sobre una tabla. El nombre de los formularios de mantenimiento se deberá fijar de la siguiente manera: utilizando el prefijo “frm” seguido por la palabra “Mantenimiento” y el nombre de la tabla (a la que se le realizará el mantenimiento) en singular. Por ejemplo: frmMantenimientoInstitucion. (Ver estándar del formulario en el anexo No. 14)

• Formularios de Actualización

Estos son los formularios que se encuentran formados por un “grid” y por diferentes “textbox” en los cuales se mostrará la información correspondiente al registro seleccionado previamente en el “grid” con el fin de realizar alguna transacción.

El nombre de este tipo de formulario deberá definirse de la siguiente forma: utilizando el prefijo “frm” seguido de alguna de las siguientes palabras: calcular, generar, actualizar (según sea el caso) y el nombre del objeto sobre el cual se realizará la transacción en singular. Por ejemplo: frmActualizarVehiculo. (Ver estándar del formulario en el anexo No. 14)

10.2.2.3. Prototipos de informes

Debe describir que tablas y campos tomó en cuenta para generar el informe, además describir si realiza algún campo calculado. (Ver anexo No. 15).

10.2.3. Descripción de entidades, procedimientos y funciones

Los requerimientos de un sistema de software, son extensos y detallados, y además contienen múltiples relaciones entre sí. Obtenemos la posibilidad de especificar sistemas complejos al documentar especificaciones simples y concisas para el sistema.

Esto se logra al clasificar, estructurar y organizar todo lo que el sistema debe de hacer. En otras palabras al analizar sus requerimientos. Los requerimientos son el punto de acuerdo




entre el cliente y el proyecto de desarrollo de software, este entendimiento es necesario para poder construir software que satisfaga las necesidades de nuestro cliente y/o usuario.

El formato de una tabla con elementos básicos para reunir los requerimientos de las entidades del sistema por desarrollar (Ver formato de entidades en el anexo No. 16).

Formato de una tabla con elementos básicos para reunir los requerimientos de los procesos del sistema por desarrollar (Ver formato de procesos en el anexo No. 17)

10.2.4. Plan para la validación del Diseño

En este apartado debe precisar los casos que utilizará en las pruebas de integración . Los mismos deben garantizar que se cumpla con lo definido en el punto 10.2.2.1. (Ver anexo No. 18)

Importante:

Es obligatorio concluir esta etapa con el acta de aprobación3. (Ver anexo No. 19)

11. INVERSIÓN O EJECUCIÓN

Etapa(s) del Ciclo de Vida V: Desarrollo del Sistema, pruebas, Capacitación, Implantación

Entregable(s):

• Plan para la validación de la codificación

• Plan de pruebas

• Resultado de las pruebas

• Plan capacitación

3 Nota: Promoción, Negociación y Financiamiento El resultado básico de esta fase, es la viabilidad del proyecto y la aprobación del financiamiento.




• Manual de usuario

• Manual técnico

• Acta aceptación del Sistema

Debe realizar el siguiente proceso:

• Plan para la validación de la codificación

• Diseño y presentación de prototipos a los usuarios

• Codificación

• Ejecución de pruebas

• Elaboración manual técnico y de usuario

• Capacitación

• Implantación

Estrategia:

• Debe buscar en el repositorio de código reutilizable módulos similares a los requeridos. (\\embsisrep\Repositorio)

11.1. PLAN PARA LA VALIDACIÓN DE LA CODIFICACIÓN

En este apartado debe precisar los casos que utilizará en las pruebas Unitarias . Los mismos deben garantizar que cada módulo funcione correctamente. (Ver anexo No. 21)

11.2. ARQUITECTURA

Todos los sistemas deben desarrollarse utilizando capas (3 capas) una de Acceso a Datos, otra Lógica y otra de Presentación. (Ver punto 11.2.2). Para observar los lineamientos específicos para el programador ver anexo 31.




11.2.1. Estándares para las variables

Todas las variables de un proyecto se deben declarar por ejemplo utilizando: “strNombreUsuario”, “intCantidadPagos”. Las variables globales deben estar declaradas en una región llamada “Variables”. Cada variable, ya sea local o global, deben estar debidamente comentadas y tener una definición en la que se indique para qué sirve cada una. (Ver tabla en el anexo No. 20 )

11.2.2. Estándares para la soluciones

Las soluciones deberán nombrarse con las abreviaturas o siglas de cada proyecto, por ejemplo: para el sistema de horas extra la solución deberá llamarse SiHoEx. Cada solución deberá tener cuatro proyectos (projects), los cuales se describen a continuación:

• Capa de Acceso a Datos

• Capa Lógica

• Capa de Presentación

• Proyecto de Reportes

A cada uno de estos proyectos se les debe asignar el nombre de la siguiente forma: Utilizando el prefijo “prj”. El nombre correspondiente (Acceso a datos, Lógica, Presentación o Reportes) el cual debe iniciar con mayúscula y en caso de que sea un nombre compuesto cada una de las palabras debe iniciar con mayúscula, sin preposiciones, ni guión bajo “_”. El nombre de la solución a la que pertenece. Por ejemplo: “prjAccesoDatosCACS”, “prjLogicaSICOVE”, “prjReportesSACE”.

11.2.3. Reportes y Subreportes

La forma de asignar el nombre a los reportes será la siguiente: Utilizando el prefijo “rpt”. El nombre de la tabla de la cual se extrae la información para el reporte siguiendo los




estándares definidos para las tablas (los cuales se detallan más adelante). En caso de que se utilice más de una tabla, se deberá usar el nombre de la tabla base (tabla de la cual se extrae la mayor cantidad de información).

Por ejemplo: “rptUsuarios”, “rptPresupuesto”. Cuando existan subreportes el nombre se deberá asignar de la misma forma que para los reportes y adicionalmente se deberá agregar la palabra “Detalles” al final. Por ejemplo: “rptPresupuestoDetalles”, “rptAguinaldosDetalles”.

11.2.4. Estándares para las bases de datos

Las bases de datos deberán nombrarse utilizando el prefijo “bda” seguido del nombre del sistema (abreviaturas). Por ejemplo: bdaSICOVE, bdaSICJE, etc.

El usuario desarrollador NO DEBE SER Dbo ni OWNER, cuando una aplicación se coloca en el servidor para que esté en producción, Igualmente, es importante que el programador no sea dbo en ningún momento de desarrollo ya que el único dbo que debe existir es el usuario del departamento de base de datos. Lo anterior debido a que en caso de que el desarrollador le "herede" la aplicación a otro compañero o bien se marche del MEP van a quedar objetos creados con ese usuario.

Por lo tanto, las aplicaciones deben tener un usuario de programación, por ejemplo para sistema SIGE existe un usuario “SIGE”. Este usuario al final solo debe quedar con dos permisos: DATA READER y DATAWRITER. Durante el desarrollo se le puede dar la función o rol de DATABASE CREADOR para la creación de objetos pero el DBA los suprimirá al colocarlo en producción. Debe de cumplirse obligatoriamente.

A las tablas de las bases de datos se les debe asignar el nombre usando el prefijo “tbl” seguido del nombre de la tabla en plural. Por ejemplo: “tblUsuarios”, “tblAccesos”. Si se utilizan tablas de encabezado y detalle las tablas de encabezado deben nombrarse como se mencionó en el párrafo anterior, mientras que para las tablas de detalle se debe utilizar el mismo nombre de la tabla encabezado a la que corresponde más la palabra “Detalles”.

Por ejemplo: Tabla de encabezado � “tblFacturas”, Tabla detalle � “tblFacturasDetalles”




Los campos de las tablas deberán definirse anteponiendo el estándar del tipo de dato (descrito en el anexo No. 20) seguido del nombre del campo, el cual debe ser descriptivo. Por ejemplo: “strPrimerApellido”, “intEdad”.

Los procedimientos almacenados que se creen en la base de datos deben ser nombrados como se indica a continuación: Utilizando el prefijo “pal” Seguido de la acción que realizará el procedimiento almacenado en infinitivo, es decir Insertar, Modificar, Borrar o Consultar. Nombre de la tabla sobre la que se ejecutará el procedimiento.

Por ejemplo: “palInsertarUsuarios”, “palModificarSalarios”

Los triggers que se utilicen en el sistema deberán usar el prefijo “tri” seguido de la acción que se realizará: Insertar, Modificar, Borrar o Consultar según sea el caso y el nombre de la tabla sobre la que se ejecutará el trigger.

Por ejemplo: “triInsertarAccesos”, “triModificarPresupuestos”

Importante:

Desde el planteamiento hasta la puesta en marcha se debe trabajar con uno de los DBA para buscar un equilibrio entre la aplicación y el motor de base de datos.

Algunas de las razones son las siguientes:

a. Equilibrio de la aplicación sin importar el servidor en el cual se colocará en producción.

b. Seguridad tanto del servidor como de la base de datos para evitar Inject_SQL.

c. Mayor aprovechamiento de las bases de datos existentes evitando duplicación de tablas.




11.2.5. Estándares para nombrar objetos

Si el objeto que se va utilizar no se encuentra en la lista para nombrarlo se utiliza el siguiente estándar:

• Si el nombre del objeto consta de tres palabras, el prefijo se forma con la primera letra de cada palabra. Por ejemplo: si el nombre del objeto es MaskedEditValidator el prefijo será “mev”, o bien, si el nombre del objeto es CascadingDropDown el prefijo será “cdd”. (Ver detalle en el anexo No. 20)

• Si el nombre del objeto consta de dos palabras, el prefijo se forma con la primera letra de cada palabra más la última letra del nombre del objeto. Por ejemplo: si el nombre del objeto es CalendarExtender el prefijo será “cxr”, o bien si el nombre del objeto es TabContainer el prefijo será “tcr”.

• Si el nombre del objeto consta de una sola palabra, el prefijo se forma con la primera letra, más una consonante del centro de la palabra, más la ultima letra. Por ejemplo: si el nombre del objeto es Rating el prefijo será “rtg”, o bien si el nombre del objeto es Accordion el prefijo será “arn”.

Nota: Es importante que a la hora de crear estos prefijos no sean iguales a uno de los existentes en el manual, para evitar confusiones.

11.2.6. Estructura general de los impresos

Las características particulares de cada impreso o salida impresa se respetarán de acuerdo con la necesidad percibida por el diseñador. Sin embargo se requiere que cada impreso tenga un encabezado estándar con siguientes características:

• Logo del MEP

• Nombre oficial de la institución

• Nombre del departamento responsable de emitir el informe

• Título descriptivo del informe

• Fechas en caso de rangos




• Fecha del informe

• Número de página

• Nombre del reporte

• Línea divisoria para separar el encabezado del cuerpo del reporte

Los impresos deben tener dos opciones de presentación: por impresora y por pantalla.

11.2.7. Observaciones Generales de Programación

El código debe estar organizador en regiones, lo cual facilitará la comprensión del mismo no sólo por parte del programador, sino también por parte de cualquier otra persona a la cual le sea asignado y ayudará a realizar un mantenimiento más eficiente cuando sea necesario.

Cada función o procedimiento del sistema, así como cada una de las variables que se utilicen deben estar debidamente documentados.

Para documentar las funciones y los procedimientos se debe utilizar el siguiente esquema de documentación el cual debe usarse inmediatamente antes de la función o procedimiento:

'EFECTO: Para qué se crea o para qué servirá la función o el procedimiento

'RECIBE: usuario: usuario con el que se conectará a la base de datos

'passW: contraseña de usuario

'hostN: nombre de máquina en que trabaja el usuario

'DEVUELVE: Valor que devolverá la función, si es un procedimiento debe indicarse “NO DEVUELVE”

Cabe resaltar que dentro de cada función se deben comentar las variables y las líneas de código que así se considere necesario, por ejemplo: los cálculos matemáticos. Para las consultas SQL las palabras reservadas deben ir en mayúscula, ya que esto facilitará la lectura y comprensión de dichas consultas. Por ejemplo: “SELECT * FROM tblUsuarios”, “TRUNCATE TABLE tblInstituciones”.




Use siempre sentencias Select-Case o Switch en lugar de utilizar sentencias if-then repetitivas.

Utilice nombres tratando de conservar la abstracción, las implementaciones están sujetas a cambios o pueden ser utilizadas en otras aplicaciones, trate de expresar el “que hace” y no el “como lo hace”, además utilice nombres relativamente largos para que se entiendan y la misma programación se vaya documentando.

No utilice abreviaturas

Ejemplo: Utilice SeleccionarRegistro() y no RealizarConsultaSelect().

Utilice emplearSeleccionarComida() que SeleccionarlaComidadelMenu().

Los nombres de todas las estructuras de código deben ser en español.

Evite nombres imprecisos o ambiguos los cuales provocar interpretaciones subjetivas

Incluso para el caso de una variable de poco uso, que deba aparecer sólo en unas cuantas líneas de código, emplee un nombre descriptivo.

Utilice nombres de variables de una sola letra, como i o j sólo para índices (ciclos for).

No utilice números o cadenas literales, como por ejemplo For i = 1 To 7. En su lugar, emplee constantes con nombre, del tipo For i = 1 To Enumeración para que resulten fáciles de mantener y comprender.

Cuando ponga nombre a las columnas de las tablas, no repita el nombre de la tabla; por ejemplo, evite un campo llamado EstudiantesApellido de una tabla llamada Estudiantes.

Evite el uso de caracteres como $ o %




Mantenga y actualice los comentarios detallados al mismo tiempo que el código fuente

Los comentarios deben ser en español.

Al principio de cada rutina, resulta útil hacer comentarios estándar, repetitivos, que indiquen el propósito de la rutina, las suposiciones y las limitaciones.

Un comentario repetitivo podría consistir en una breve introducción que explicara por qué existe y qué puede hacer.

Evite los comentarios recargados, como las líneas enteras de asteriscos. En su lugar, utilice espacios para separar los comentarios y el código.

Evite rodear un bloque de comentarios con un marco tipográfico. Puede resultar agradable, pero es difícil de mantener.

Antes de la implementación, quite todos los comentarios temporales o innecesarios.

Use frases completas cuando escriba comentarios. Los comentarios deben aclarar el código, no añadirle ambigüedad.

Vaya comentando al mismo tiempo que programa, porque probablemente no tenga tiempo de hacerlo más tarde. Por otro lado, aunque tuviera oportunidad de revisar el código que ha escrito, lo que parece obvio hoy es posible que seis semanas después no lo sea.

Evite comentarios superfluos o inapropiados, como comentarios divertidos al margen.

Use los comentarios para explicar el propósito del código. No los use como si fueran traducciones literales.

Para evitar problemas recurrentes, haga siempre comentarios al depurar errores y solucionar problemas de codificación, especialmente cuando trabaje en equipo.




Haga comentarios en el código que esté formado por bucles o bifurcaciones lógicas. Se trata en estos casos de áreas clave que ayudarán a los lectores del código fuente.

Realice los comentarios en un estilo uniforme, respetando una puntuación y estructura coherentes a lo largo de toda la aplicación.

Después de la secuencia de continuación de línea no puede escribirse un comentario en la misma línea.

Todos los comentarios deben estar ortográficamente bien escritos, una escritura incorrecta demuestra un desarrollo negligente.

Todas las modificaciones a los sistemas en producción deben documentarse y tener la fecha de modificación y el funcionario que la realizó.

11.3. LENGUAJE DE DESARROLLO

El lenguaje oficial para desarrollo de software es Visual Basic .Net 2005

11.4. MOTOR BASE DE DATOS

El motor de base de datos que debe utilizar es SQL Server 2000 o superior.

11.5. ESTÁNDARES GENERALES

En los puntos del 11.2.1 al 11.2.7 encontrará los estándares para:

• Variables (ver el punto 11.2.1)




• Soluciones (ver el punto 11.2.2)

• Reportes y subreportes (ver el punto 11.2.3)

• Base de datos (ver el punto 11.2.4)

• Tipos de datos

• Objetos

11.6. PRUEBAS

11.6.1. Diseño plan de pruebas

El plan de pruebas debe contener (ver detalles en No. 22):

Código de prueba : La primera letra debe ser una P, seguida por un guion y el número de prueba. Ej.: P-01

Descripción de Aspectos Generales: Esta sección establece el alcance y el objetivo del plan de pruebas. Es aquí donde se describen los aspectos fundamentales del esfuerzo que se hará para probar una aplicación, independientemente de las características y tamaño que ésta pueda tener.

• Objetivo - Describe por qué el Plan de Pruebas fue desarrollado - cuáles son sus objetivos. Esto incluye requerimientos de documentación, definición de estrategias de prueba, identificación de recursos, estimación de plazos y proyección de entregables.

• Alcance - Describe brevemente los recursos que el plan requiere, las áreas de responsabilidad, las etapas y los riesgos potenciales.

Descripción de Requerimientos. Contiene una lista de todos los requerimientos que serán probados. Cualquier requerimiento no incluido en esta lista estará fuera del alcance de las pruebas.

• Requerimientos Funcionales: todas las funciones que deben ser probadas, por ejemplo la creación, la corrección y supresión de registros, son puestas en esta lista.




Puede incluirse la lista completa en esta sección o bien hacerse referencia a otro documento que contenga la información.

• Requerimientos de Diseño: Las pruebas de la interfaz de usuario, las estructuras de menú u otros elementos de diseño también deberían ser puestas en una lista o referenciados hacia otro documento.

• Requerimientos de Integración: Los requerimientos para probar el flujo de datos desde un componente a otro deben ser incluidos y ellos harán parte del Plan de Pruebas.

• Otros Requerimientos: Cualesquiera otras exigencias que tenga la aplicación y que necesiten ser probadas.

Definición de la Estrategia de Pruebas

Unitarias

Debe utilizar los casos que describió en el punto 11.1 (Inversión o Ejecución) Es necesario realizar pruebas que demuestren que cada función es completamente operativa (caja negra) y pruebas que aseguren que la operación interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado de forma adecuada (caja blanca).

Pruebas de caja blanca

Las pruebas de caja blanca permiten examinar la estructura interna del programa. Se diseñan casos de prueba para examinar la lógica del programa. Es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar casos de prueba que garanticen que:

• Se ejercitan todos los caminos independientes de cada módulo.

• Se ejercitan todas las decisiones lógicas.

• Se ejecutan todos los bucles.

• Se ejecutan las estructuras de datos internas.

Observaciones:




• Lograr una buena cobertura de ramas.

• Las pruebas de caja blanca se pueden hacer con un depurador (debugger).

Prueba de caja negra

Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa.

Los casos de prueba de la caja negra pretende demostrar que:

• Las funciones del software son operativas.

• La entrada se acepta de forma adecuada.

• Se produce una salida correcta, y la integridad de la información externa se mantiene.

• Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales del programa.

La prueba de la caja negra intenta encontrar errores de las siguientes categorías:

• Funciones incorrectas o ausentes.

• Errores de interfaz.

• Errores en estructuras de datos o en accesos a bases de datos externas.

• Errores de rendimiento.

• Errores de inicialización y de terminación.

Algunas técnicas de diseño son:

• Diseño descendente: Se inicia probando los módulos más generales.

• Ventaja: Piensa en términos de funcionalidad global.

• Inconveniente: No dispongo de los módulos inferiores.




• Diseño ascendente: Se comienza probando los módulos base.

• Ventaja: No hay que construir módulos ficticios.

• Inconveniente: Se centra más en el desarrollo que en las expectativas del cliente.

• Codificación incremental: Se codifican sólo las partes de cada módulo necesarias para cada funcionalidad; una vez probada, se van añadiendo funcionalidades.

• Ventaja: Cuando hay mucha interacción con el usuario.

• Inconveniente: No tenemos módulos completos hasta el final.

De integración

Debe utilizar los casos que describió en los puntos 10.1.8 de la Fase I (Pre inversión) y punto 10.2.4 de la Fase II (Promoción, Negociación y Financiamiento). Las pruebas de integración se centran en probar la coherencia semántica entre los diferentes módulos, tanto de semántica estática (se importan los módulos adecuados; se llama correctamente a los procedimientos proporcionados por cada módulo), como de semántica dinámica (un módulo recibe de otro lo que esperaba). Normalmente estas pruebas se van realizando por etapas, englobando progresivamente más y más módulos en cada prueba.

Las pruebas de integración se pueden empezar en cuanto tenemos unos pocos módulos, aunque no terminarán hasta disponer de la totalidad. En un diseño descendente (top-down) se empieza a probar por los módulos más generales; mientras que en un diseño ascendente se empieza a probar por los módulos de base.

Como parte de la ejecución de las pruebas, se deben incluir aspectos de concurrencia, este proceso implica que la misma aplicación puede ser utilizada por dos o más usuarios al mismo tiempo, por lo tanto requiere de al menos dos usuarios ubicados en computadores diferentes con el mismo detalle de la prueba a ejecutar, pero con diferentes datos, de tal forma que realicen la prueba al mismo tiempo, verificando al final de la misma además de los resultados esperados, que el sistema realice ambos procesos correctamente.




Prueba de aceptación

Debe utilizar los casos que describió en los puntos 10.1.8 de la Fase I (Preinversión). El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptación, desde el punto de vista de su funcionalidad y rendimiento.

Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.

Observaciones:

El Equipo de Dirección de Proyectos debe establecer y verificar la relación entre requisitos y pruebas, garantizando que cada uno esté cubierto al menos por una prueba, de modo que ante el fallo de un requisito se puede determinar el conjunto de pruebas a realizar.

Las pruebas deben realizarse con datos reales. La preparación de estos datos es responsabilidad de los usuarios.

El documento que debe usar para documentar cada prueba debe contener el tipo de prueba, casos de prueba, recursos requeridos, responsable, participantes, resultados (Ver anexo No. 23)

Recursos Requeridos. Identificar los roles y las responsabilidades que serán requeridas para la ejecución del Plan de Pruebas.

Calendario y Plazos. Documentar el plazo en el cual la aplicación a probar estará disponible para pruebas y el tiempo estimado para ejecutar los casos de prueba. Especifique si se proporcionará partes construidas, sobre una base regular durante el ciclo de prueba, o cuando se espera que los componentes del sistema estén listos para pruebas.

11.6.2. Aprobación del Plan

El Plan de Pruebas debe ser revisado por todas las partes responsables de su ejecución y aprobado por el Equipo de Dirección de Proyectos. Obtenga las firmas de aprobación en todas las páginas del mismo.




11.6.3. Seguimiento y Reporte de Defectos

Documente el instrumento y el proceso usado para registrar y rastrear los defectos (ver anexo No. 24).

Las siguientes son categorías para priorizar o calificar defectos:

• Crítico - denota una función inutilizable que causa un término anormal o una falla general, o cuando un cambio en un área de la aplicación causa un problema en otra parte.

• Severo - una función no actúa como fue requerido o diseñado, o un objeto de interfaz no trabaja como se muestra.

• Advertencia - la función trabaja, pero no tan rápidamente como esperado, o no se ajusta a las normas y convenciones.

• No crítico - para el funcionamiento de sistema: palabras con mala ortografía, formateo incorrecto, mensajes de error vagos o confusos o advertencias.

Importante:

Para aprobar esta etapa debe firmarse el acta del anexo No. 25.

Para aceptar el sistema en su totalidad debe llenar el anexo No. 26.

11.7. CAPACITACIÓN

El proceso de capacitación debe realizarse en el ambiente donde se va a utilizar la aplicación. Debe utilizar el formulario del anexo No. 27 el cual indique el nombre del sistema, responsable de la capacitación, número de funcionarios, fecha, recursos requeridos y documentos que se les entregan a los funcionarios.




En el anexo No. 28 puede visualizar el documento de aceptación de la capacitación.

Los contenidos del manual de usuario y del técnico se detallaron en el apartado 9. Documentación del proyecto.

12. OPERACIÓN O FUNCIONAMIENTO

ETAPA(S) DEL CICLO DE VIDA V: EVALUACIÓN

Consiste en poner en marcha el proyecto y concretar los beneficios netos estimados en el documento de Pre inversión. En esta fase los bienes o servicios que se esperan del proyecto se prestan de manera continua y permanente durante la vida útil del proyecto. Esta es la fase que permite lograr los objetivos intermedios y final del proyecto, es decir, resolver el problema o satisfacer la necesidad, una vez logrado esto el ciclo de vida del proyecto se cierra.

Comienza otro ciclo en función de los nuevos problemas o necesidades que aparezcan. Además, el proceso en esta fase es mucho más complejo que en las otras, ya que adquiere carácter de permanencia durante la vida útil del proyecto. El producto de esta fase pueden ser bienes o servicios que son vitales para el logro de los objetivos del proyecto.

De esta forma se puede ver que en cuanto se presenten nuevos requerimientos, cambios o mejoras al sistema en cuestión, se deberá realizar nuevamente un ciclo para la documentación adecuada de éstos ajustes. Así se tendrá una elaboración del manual del sistema como sigue:

- Pre inversión

- Promoción, Negociación y Financiamiento

- Inversión o Ejecución

- Operación o Funcionamiento (Surgimiento de nuevos requerimientos o cambios)




12.1. EVALUACIÓN DEL PROYECTO

La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones: evaluación operacional, impacto organizacional, opinión de los administradores y desempeño del desarrollo.

Cuando la evaluación se conduce en forma adecuada proporciona mucha información que puede ayudar a mejorar la efectividad de los esfuerzos de desarrollo de aplicaciones subsecuentes. (Ver anexo No. 29)

12.1.1. Evaluación operacional

Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.

12.1.2. Impacto organizacional

Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.

12.1.3. Opinión de los administradores

Valoración por parte de los directivos y administradores dentro de la organización así como de los usuarios finales.

12.1.4. Desempeño del desarrollo




La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.




14. ANEXOS




14.1. ANEXO No. 1

Encabezados y Pie de Página

Todo documento que se elabore debe llevar el encabezado y el pie de página indicado a continuación.

Encabezado del documento:

Pie de página del documento:

Formato del texto de documentos

Texto Tipo de letra Tamaño Espaciado Interlineado

Título 1 Arial Negrita Mayúscula, Numerado

14 12 ptos 1,5 líneas

Título 2 Arial Negrita, Numerado 12 6 ptos 1,5 líneas

Título 3 Arial cursiva, subrayado 12 6 ptos 1,5 líneas

Normal Arial, Justificado 12 6 ptos Sencillo

Notas Arial cursiva centrado 12 6 ptos Sencillo

Vocablos extranjeros Arial cursiva 10 6 ptos Sencillo

Encabezado Arial 14 0 ptos Sencillo

Pie de página Arial 11 0 ptos Sencillo




Márgenes

� Izquierdo 3 cm

� Derecho 2,5 cm

� Superior 2,5 cm

� Inferior 2,5 cm

Tamaño de papel

� Carta




14.2. ANEXO No. 2

14.2.1. Rotulación de Disco Compacto parte externa




14.2.2. Rotulación de Disco Compacto superficie del disco




14.3. ANEXO No. 3

14.3.1. Plantilla Requerimientos

Ejemplo de los Objetivos Específicos:

Identificador OE-001

Fecha 16/01/2009

Solicitante Departamento de Registros Laborales.

Descripción Automatizar, agilizar y controlar el proceso de asignación de expedientes inactivos.

Identificador OE-002

Fecha 16/01/2009


Descripción Contar con una interfaz amigable que brinde ayuda al usuario y le facilite la realización de sus tareas.




Requerimientos funcionales definidos por el cliente\usuario, con un ejemplo para el sistema de expedientes inactivos:

ID REQ-001 Almacenar, consular y modificar los datos de los

funcionarios.

Versión 1.0

Fecha 16/01/2009


Objetivos

Asociados

OE-001, OE-005

Descripción El sistema debe ser capaz de almacenar y modificar los datos

de los diferentes funcionarios (Identificación, nombre completo,

puesto, especialidad, salario, fecha de cese de funciones,

fecha de envío, estado, cantidad de folios, fechas extremas,

numero de caja y orden, observaciones.

Importancia Alta

Cuando debe estar

listo

Antes de la etapa de pruebas. Según el cronograma del

sistema de expedientes inactivos.

Comentarios El sistema debe ser capaz de almacenar y modificar los datos

de los diferentes funcionarios.




14.4. ANEXO No. 4

14.4.1. Cronograma de Actividades

Tareas Duración Comienzo Fin

Nombre del proyecto

PREINVERSION

Investigación Preliminar

Realización estudio de factibilidad técnica

Realización estudio de factibilidad económica

Realización estudio de factibilidad operacional

Presentación del documento con el estudio de factibilidad

Aprobación de documento de estudio de factibilidad

Análisis de Requerimientos

Ejecución de entrevistas

Análisis de la información recolectada en las entrevistas

Evaluación de la documentación recolectada

Elaboración del documento de requerimientos

Revisión del doc. de requerimientos por la contraparte del proyecto

Corrección del documento de requerimientos

Entregable: Documento Etapa Preinversión a la Comis ión de Calidad y Desarrollo

Entregable: Acta Aceptación Etapa PREINVERSION

PROMOCION, NEGOCIACION Y FINANCIAMIENTO

Diseño del Sistema

Identificación de casos de uso

Creación de diagramas de casos de uso

Diagramas de secuencia

Diagramas conceptuales

Diseño diagrama Base de Datos

Diccionario de Datos

Diseño de Diagrama de Base de Datos

Diseño de prototipos

Descripción de entidades, procedimientos y funciones

Plan para la validación del diseño




Entregable: Documento Etapa Promoción, Negociac ión y

Financiamiento a la Comisión de Calidad y Desa rrollo

Entregable: Acta Aceptación Etapa Promoción, Ne gociación y

Financiamiento

INVERSION O EJECUCION

Desarrollo del Sistema

Creación de pantallas

Ajuste de pantallas

Ajuste da Base de Datos

Realización de mantenimientos

Implementación de las Reglas del Negocio

Realización de reportes

Presentación prototipos al usuario

Pruebas del Sistema

Aplicación de pruebas unitarias

Ejecución de pruebas integrales

Evaluación de pruebas

Corrección de problemas identificados durante las pruebas

Entregable: Resultado de Pruebas a la Comisión Cali dad y

Desarrollo

Aprobación de pruebas

Elaboración de manual técnico y de usuario

Capacitación de Usuarios del Sistema

Confección de material para capacitación

Realización de taller de Capacitación

Implantación del Sistema

Entregable: Acta Aceptación Etapa INVERSION Y E JECUCION

Entregable: Acta Aprobación Oficial del Sistema

OPERACIÓN O FUNCIONAMIENTO

Evaluación

Entregable: Informe evaluación del proyecto a la Comisión Calidad y Desarrollo




14.5. ANEXO No. 5

14.5.1. Costos (Equipo de cómputo, materiales y equipo de trabajo)

Recurso Tipo De Recurso Beneficio Cantidad Total En $

SYBASE Base de datos Información ya ingresada en las tablas necesarias para la planilla.

1

SQL Server Base de datos Facilidad de conexión y utilización

1

Computadora Hardware 2 $1200

Servidor Sybase Hardware 1

Servidor SQL Server Hardware 1 $1200

Licencia Visual Basic

Software 1

Analistas Recurso Humano 3




14.6. ANEXO No. 6

14.6.1. Plan Validación de Requerimientos

Código

Prueba

Requerimiento Caso(s) de prueba para

validación

P-001 R1: El sistema debe permitir el manejo, validación de

usuarios y restricción por medio de diferentes tipos de

usuario.

Caso 1: Agregar usuario no

existente y que sistema no deje

ingresar.

Caso 2: Ingresar clave de usuario

con privilegios restringidos y

verificar su acceso solo a áreas

permitidas.

P-002 R2: (Describirlo) Caso 1:

Caso 2:

P-003 R..N: (Describirlo) Caso 1:

Caso 2:




14.7. ANEXO No. 7

14.7.1. Acta Aceptación de la fase Preinversión


Dirección Informática de Gestión

Nombre del Sistema

ACEPTACIÓN DE LA FASE PREINVERSIÓN

Elaborado por:

___________________________

Implicado(s)

Aprobado por:

______________________ ______________________

Implicado(s) Ing. Gabriel Dennis

Enero 2009

Nota: Pre inversión es la fase preliminar para la ejecución de un proyecto que permite, mediante elaboración de estudios, demostrar las capacidades técnicas, económicas-financieras, institucionales y sociales de este.




14.8. ANEXO No. 8

14.8.1. Diagrama de casos de uso

Es una representación gráfica de parte o el total de los actores y casos de uso del sistema, incluyendo sus interacciones. Todo sistema tiene como mínimo un diagrama Main Use Case, que es una representación gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso).




14.8.2. Ejemplo de Cuadro Resumen Requerimientos/Casos de Uso

Requerimiento Casos de uso que resuelven el

requerimiento

R1: El sistema debe permitir el manejo, validación

de usuarios y restricción por medio de diferentes

tipos de usuario.

1. Registrar usuarios.

2. Validación de usuarios.

3. Restricción de ingreso al sistema.

R2: El sistema debe tener control sobre las

transacciones que se realizan en el sistema por

medio de bitácoras.

1. Registrar las transacciones por medio de

bitácoras.

R3: El sistema debe ser capaz de registrar,

clasificar y almacenar los datos necesarios de la

documentación recibida por parte de usuarios

externos o internos.

1. Registrar la documentación

2. Eliminar la documentación

3. Modificar la documentación

4. Consultar la documentación documentos

a la base de datos

R4: El sistema debe ser capaz de mantener un

consecutivo de todos los documentos recibidos.

1. Generar un consecutivo de los

documentos recibidos.

R5: El sistema debe ser capaz de generar

diferentes tipos de consultas y reportes solicitados

por el usuario de los diferentes departamentos.

1. Generar Reportes desde la base de datos




14.9. ANEXO No. 9

14.9.1. Diagramas de secuencia

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase.




14.10. ANEXO No. 10

14.10.1. Diagramas Conceptuales

Es una técnica usada para la representación gráfica del conocimiento. Un mapa conceptual es una red de conceptos. En la red, los nodos representan los conceptos, y los enlaces las relaciones entre los conceptos en forma de flechas etiquetadas.




14.11. ANEXO No. 11

14.11.1. Diagrama de Base de Datos o Diagrama Entidad-Relación (DER)

Un DER es una herramienta de modelado de sistemas, que se concentra en los datos almacenados en el sistema y las relaciones entre éstos. Un diagrama de entidad-relación o DER es un modelo de red que describe la distribución de los datos almacenados en un sistema de forma abstracta.




14.12. ANEXO No. 12

14.12.1. Diccionario de Datos (DD)

El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema. El objetivo de un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades. Define con precisión los datos de entrada, salida, componentes de almacenes, flujos, detalles de las relaciones entre almacenes, etcétera. El diccionario de datos nos muestra la lista de todos los atributos por cada entidad o tabla y sus características.

Entidad: Nombre que se le asigno a la tabla en la base de datos

Atributos: Nombre de cada campo dentro de la entidad en la base de datos

Tipo: Tipo de información que almacenara el atributo en la base de datos

Largo: Cantidad máxima de caracteres que aceptara el atributo

Condición: Restricciones que se han estipulado para un campo en específico

Descripción: Descripción del propósito del campo

Entidad Atributos Tipo Largo Restricciones Descripción Primary Key Identificación del grupo al cual

Not null pertenecerán los usuarios.

descripción varchar 35 Not null Descripción del grupo

Primary Key

Not null

descripción varchar 35 Not null Descripción del documento

Grupo al que pertenece el

documento

Identifica el tipo de documento

grupos tinytext Not null

doctype

id varchar 5

id varchar 15

groups




14.13. ANEXO No. 13

14.13.1. Prototipos de formularios

Nombre del Formulario Tablas y datos

Explicación: Este formulario se utiliza con el fin de identificar y autentificar el usuario que ingresará al sitio web o sistema.

syslogins (master), AGK003 (sigrh_real)

name y password, AGKUSR, AGK3DS, AGKNOM

Nombre Formulario: frmIngreso. Sistema con que Interactúa:

SIGRH, Active Directory

Requerimiento del que forma parte: R1




14.14. Anexo 14.

Aplicaciones WEB

14.14.1. Formularios de Ingreso (Login)




14.14.2. Formulario Principal




14.14.3. Menú dentro del formulario principal




14.14.4. Formularios de Mantenimiento

Menú Modificar




Filtros




14.14.5. Formularios de Consulta




14.14.6. Formularios de Modificar la Contraseña




Aplicaciones Cliente/Servidor

14.14.7. Formularios de Mantenimiento




14.14.8. Formularios de Actualización




14.15. ANEXO No. 15

14.15.1. Prototipo de informes

Nombre de Pantalla Tabla y campos involucrados

Realizar Llamada:

Se mostrará la información del oferente y de la propuesta de nombramiento correspondiente

Tb_Llamadas

tb_Nombramientos

Requerimiento del que forma parte: R1




14.16. ANEXO No. 16

14.16.1. Tabla de Entidades del Sistema




14.17. ANEXO No. 17

14.17.1. Tabla de los requerimientos de los procesos del sistema




14.18. ANEXO No. 18

14.18.1. Plan para la Validación del Diseño

Información de la pantalla Caso(s) de prueba para validación

Nombre:

frmMantenimientoFuncionarios

Caso de prueba 1:

Que al digitar el número de cédula se

visualicen los datos personales del

funcionario.

Caso de prueba 2:

Que el “grid” cargue los nombramientos

interinos del funcionario.

Descripción:

Permite realizar el mantenimiento de los funcionarios que utilizarán el sistema.

Campos a validar:

txtCedula

dgvNombramientos

Nombre: Caso de prueba 1:

Caso de prueba 2:

Descripción:

Campos a validar:




14.19. ANEXO No. 19

14.19.1. Acta aceptación Fase



Nombre del Sistema

ACEPTACIÓN DE LA ETAPA DE PROMOCIÓN, NEGOCIACIÓN

Y FINANCIAMIENTO

Elaborado por:

___________________________

Implicado(s)

Aprobado por:

______________________ ______________________


Enero 2009




Tipo de Dato Prefijo

boolean bol

byte byt

char chr

date dat

datetime dti

decimal dec

double dbl

int16 i16

int32 i32

int64 i64

integer int

long lng

new new

object obj

short sht

single sgl

string str

Visual Basic .NetTipo de Dato Prefijo

bigint big

binary bin

bit bit

char chr

datetime dti

decimal dec

float flt

image img

int int

money mny

nchar nch

ntext ntx

numeric num

nvarchar nvc

real rel

smalldatetime sdt

smallint sin

smallmoney smn

sql_variant var

text txt

timestamp stm

tinyint tin

uniqueidentifier uid

varbinary vbn

Varchar vch

SQL Server

14.20. ANEXO No. 20

14.20.1. Estándares para tipos de datos

Para las variables se deben utilizar los siguientes estándares:

Para los campos de las tablas se deben utilizar los siguientes estándares:




14.20.2. Iconos que se deben utilizar en las aplicaciones




Limpiar

Exportar

Importar




14.20.3. Objetos para Visual Basic .Net

Nombre Estándar Nombre Estándar

AccessDataSource ads FontDialog fdg

Adrotator adr File Field ffd

BulletedList bdl Flow Layout Panel flp

BindingNavigator bdn FileSystemWatcher fsw

BindingSource bds FileUpload fup

BackGroundWorker bgw FormView fvw

Button btn GroupBox gbo

ColorDialog cdg Grid Layout Panel glp

CompareFileValidator cfv GridView gvw

CheckBox chk Hidden hdd

CheckedListBox clb HiddenField hfd

Calendar cld Hyperlink hpl

ComboBox cmb HelpProvider hpv

ContextMenu cmn HScrollBar hsb

ContextMenuStrip cms Input (Button) ibt

ChangePassword cpw Input (CheckBox) ick

CrystalReportViewer crv Input (file) ifl

CreateUserWizard cuw Input (Hidden) ihd

CustomValidator cva ImageList ils

DropDownList ddl ImageButton imb

Dropdown ddw Image img

DataGridView dgv ImageMap imp

Div div Input (password) ipw

DirectoryEntry dre + Input (radio) irb

DirectorSearcher drs Input (reset) ire

DataGrid dtg Input (submit) isu

Datalist dtl Input (text) itx

DateTimePicker dtp Label lbl

DataSet dts Linkbutton lbt

DataView dtv LoginName lgn

DomainUpDown dud LoginStatus lgs

DirectorySearcher dys LoginView lgv

EventLog elg LinkLabel lnk

ErrorProvider epv Localize loc

FolderBrowserDialog fbd Login log




14.20.4. Objetos para Visual Basic .NET

Nombre Estándar Nombre Estándar Nombre Estándar

ListBox lsb Password Field pwf ToolStripContainer tsc

ListView lsv PasswordRecovery pwr ToolStrip tst

Literal ltl RadioButtonList rbl TreeView tvw

MonthCalendar mcl Radio Button rbt Text Area txa

Menu men ReportDocument rdc Text Field txf

MenuStrip mns ResetButton reb TextBox txt

MainMenu mnu Repeater rep View viw

MessageQueue msq RegularExpressionValidator rev VScrollBar vsb

MaskedTextBox mtb RequiredFileValidator rfv ValidationSummary vsm

MultiView mvw RangeValidator rgv WebBrowser wbr

NotifyIcon nic RichTextBox rtb Wizard wiz

NumericUpDown nud ReportView rvw XMLDataSource xds

OdbcCommand ocm SubmitButton sbt Xml xml

OdbcConnection ocn SqlCommand scm

OdbcDataAdapter oda SqlConnection scn

OleDbCommand odc SplitContainer sco

OleDbConnection odn ServiceController sct

ObjectDataSource ods SqlDataAdapter sda

OpenFileDialog ofd SqlDataSource sds

OleDbDataAdapter old Select sel

OracleCommand orc SaveFileDialog sfd

OracleDataAdapter ord SiteMapDataSource smd

OracleConnection orn SiteMapPath smp

ProgressBar pba Splitter spl

PictureBox pbx SerialPort spt

PerformanceCounter pcn StatusStrip sst

PrintDocument pdc StatusBar stb

PrintDialog pdg Substitution sub

PropertyGrid pgd TabControl tbc

PlaceHolder phd Table tbl

Panel pnl ToolBar tbr

PrintPreviewControl ppc ToolTip tip

PrintPreviewDialog ppd TableLayoutPanel tlp

Process prs Timer tmr

PageSetupDialog psd TrackBar trb




14.21. ANEXO No. 21

14.21.1. Plan para la Validación de la Codificación

Código de

Prueba

Tipo de prueba

(Caja negra, caja blanca)

Función o componente que prueba

P01 Caja blanca Creación de usuarios

P02 Caja negra Clasificación de correspondencia




14.22. ANEXO No. 22

14.22.1. Plan pruebas

Código de la prueba P25

Descripción de aspectos generales

Objetivo

Probar funcionalidad del módulo.

Alcance

Módulo principal

Descripción de requerimientos

R2: El sistema debe tener control sobre las transacciones que se realizan en el sistema por medio de bitácoras.

Definición estrategias de prueba

Describa detalladamente los pasos para realizar la prueba y el tipo de prueba (unitaria, de integración, de aceptación del sistema)

Prueba unitaria:

-Agregar un usuario

-Otorgarle permisos de administrador

-Revisar bitácora para verificar nombre funcionario que realiza la transacción, fecha, hora y módulos que afecta.

Recursos requeridos Nombre de usuario con permisos de administrador

Calendario 23-11-2010

Vo. Bo. Comité Calidad y Desarrollo




14.23. ANEXO No. 23

14.23.1. Informe de la Prueba

CÓDIGO P25

TIPO DE PRUEBA

(UNITARIA, INTEGRACIÓN, ACEPTACIÓN)

Integración

CASO DE USO

Registrar las transacciones por medio de bitácoras.

ENTRADA Información funcionarios Departamento de Compras.

RESULTADOS ESPERADOS Que registre en bitácora nombre usuario, fecha, hora y acción realizada.

RECURSOS REQUERIDOS Nombre de usuario con permisos de administrador

FECHA EJECUCIÓN 23-11-2010

RESPONSABLE Juan Pérez Solís

RESULTADO DE LA PRUEBA Satisfactoria




14.24. ANEXO No. 24

14.24.1. Seguimiento y Reporte de Defectos

CÓDIGO PRUEBA CLASIFICACION DEL DEFECTO

(Crítico, Severo, Advertencia, No crítico)

ACCION

P23

Crítico

Rediseñar formulario

P26 No crítico

Evaluar la posibilidad de corregirlo en una segunda etapa.




14.25. ANEXO No. 25

14.25.1. Acta Aceptación Fase



Nombre de la fase

ACEPTACIÓN OFICIAL DE LA ETAPA DE INVERSION Y EJECUCIÓN

Elaborado por:

___________________________

Implicado(s)

Aprobado por:

______________________ ______________________


Enero 2009




14.26. ANEXO No. 26

14.26.1. Acta Aceptación oficial del Sistema



Nombre del Sistema

ACEPTACIÓN OFICIAL DEL SISTEMA

Elaborado por:

___________________________

Implicado(s)

Aprobado por:

______________________ ______________________


Enero 2009

Nota: Operación o Funcionamiento esta etapa consiste en otro ciclo en función de los nuevos problemas o necesidades que aparezcan, requiere de insumos importante para la prestación de servicios a nivel organizacional.




14.27. ANEXO No. 27

14.27.1. Plan de Capacitación

Fecha capacitación

Nombre del sistema

Capacitador

Cantidad de Funcionarios

Documentos que se entregarán

Recursos requeridos

(Hardware, software)




14.28. ANEXO No. 28

14.28.1. Documento Aceptación de la Capacitación

Sistema: _____________________________ Capacitador: _____________________ Fecha: ________

Documentación entregada a usuario final:

___________________________________________________

NOMBRE CÉDULA FIRMA




14.29. ANEXO No. 29

14.29.1. Evaluación del Proyecto

DESCRIPCIÓN RESULTADO

1. Operacional (Facilidad de uso, tiempo de respuesta)

2. Impacto organizacional (Impacto competitivo, impacto sobre el flujo de información externo e interno)

3. Opinión de los directivos (Valoración por parte de los directivos y usuarios finales)

4. Desempeño (Tiempo de desempeño coincide con la propuesta inicial)




14.30. ANEXO No. 30

14.30.1. Minuta

MINUTA Código : Fecha:

Acta N° xx

Reunión (Tema: ej. Kick Off, Seguimiento)

Fecha: día/mes/año

Lugar:

Hora:

De xx a xx

Presentes: Nombre Puesto

La reunión inicia a las xx Agenda

1. 2. 3.

Objetivo de la Reunión:

Resultados de la Reunión:

Artículo Compromisos

Compromiso Fecha Cumplimiento Responsables 1. 2. Artículos Acuerdos 1. N° Acuerdo Promotor

2. La sesión se levanta a las xxx




14.31. ANEXO No. 31

14.31.1. Manual de Programación según los estándares Web

Elaborado por:

Caroline Gutiérrez Mena

Fabio López Alfaro

Marzo 2009




Tabla de Contenido Manual de Estándar de Programaci ón WEB

Tabla de Contenido Manual de Estándar de Programación WEB .................................................... 99

1. Manual de Estándar de Programación Web .............................................................................. 100

2. Estándares para las Soluciones .................................................................................................. 100

3. Diseño .......................................................................................................................................... 102

3.1. Plantilla ................................................................................................................................ 102

3.2. Hojas de Estilo .................................................................................................................... 103

3.3. Archivos Javascript ............................................................................................................ 103

3.4. Menú .................................................................................................................................... 105

4. Seguridad ..................................................................................................................................... 107

4.1. Arquitectura de Seguridad en la Base de Datos .............................................................. 107

4.2. Esquematización del Menú ................................................................................................ 109

4.3. Modo de Autenticación en webconfig ............................................................................... 110

4.4. Cookies ................................................................................................................................. 110

4.5. Proceso de Construcción del Menú:.................................................................................. 111

5. Adicionales .................................................................................................................................. 118

5.1. Búsqueda detallada en formularios de Mantenimiento .................................................. 118

5.2. Consideraciones para la creación de la Búsqueda Detallada ......................................... 119




1. Manual de Estándar de Programación Web

Después de instalar el Microsoft Visual Studio 2005 se debe instalar el Ajax Extensions

2. Estándares para las Soluciones

Se conservan las capas de las soluciones Windows:

• Capa de Acceso a Datos

• Capa Lógica

• Capa de Presentación

• Proyecto de Reportes

Es importante que en la capa de Acceso a datos, en la cual utilicemos la conexión que se define en el web. config, se realice un Imports System.Configuration además de que se agregue al proyecto la referencia .




Imagen 1: Agregar Referencia .NET.

Esto para poder leer la conexión desde el web.config la cual se define de la siguiente manera:

<connectionStrings>

<add name="nombreConexion" connectionString="Data Source=Servidor;Initial Catalog=BD;User ID=Usuario;Password=Contraseña"

providerName="System.Data.SqlClient" />

</connectionStrings>

En la clase de la capa de Acceso a Datos donde utilizaremos la conexión se coloca la siguiente instrucción, con la cual se asigna a una variable de tipo string, el valor de la cadena de conexión declara en el web.config

strVariable =

ConfigurationManager.ConnectionStrings("nombreConexion").ConnectionString




3. Diseño

El diseño se refiere a todo lo relacionado con la visualización gráfica de la aplicación web.

3.1. Plantilla

Para la plantilla se ha utilizado como base el sitio del MEP. La plantilla es aquel elemento dentro de la aplicación llamado “Página Principal” cuya extensión es “.master” y en donde se diseña la plantilla que se utilizará en el resto del sistema. La ilustración 1 muestra la vista general de la plantilla a utilizar.

Imagen 2: Plantilla estándar de aplicaciones Web de l MEP.




En los desarrollos Web se utilizará dos plantillas diferentes una que sirve para el form de ingreso y otras que contiene el control para realizar el menú que se utiliza en el resto de formularios del proyecto, las cuales tienen como nombre mpIngreso.master y mpAplicacion.master respectivamente.

3.2. Hojas de Estilo

Las hojas de estilo a utilizar son las nombradas, se sugiere colocarlas todas en una sola carpeta de nombre “css dentro de la Capa de Presentación, estás hojas de estilo así como los archivos .js que contienen los script de JavaScript, son muy importantes para que el formato de las plantillas y el funcionamiento de los controles sea el adecuado. Debe incluirse el archivo llamado default.css

Default.css: Entre sus características más importantes está el que establece el estilo del texto a utilizar en todos los forms dentro de la clase BODY. El estilo establecido es:

font-family: Georgia, "Times New Roman", Times, serif;

font-size: 14px;

color:Navy;

3.3. Archivos Javascript

Los archivos .js que se utilizan son archivos de texto que contienen los scripts, estos se deben colocar en una carpeta de nombre “js”. Estos archivos permiten la funcionalidad de los botones que se encuentran en la parte superior derecha de algunos de los formularios. Entre sus características más importantes que contienen funciones y variables que se ejecutan en el formulario y se pueden utilizar desde cualquier formulario lo que permite ahorrar código.




Imagen 3: Ejemplos de botones de los formularios

jsMantenimientosFijo.js: Este archivo contiene los scripts que permiten el juego de botones de las diferentes opciones del Mantenimiento (Agregar, Modificar, Eliminar). (Imagen3)

Además debe incluirse un archivo js por cada uno de los formularios de mantenimiento y que llevan los botones anteriores, cada uno de esos archivos js, debe llevar el siguiente código:

//limpieza: Limpia todos los controles del form.

//Colocar aquí todos los controles en su estado de vacío o no chequeado.

function limpieza()

{

document.getElementById("ctl00_ContentPlaceHolder1_txtCodigoArea").value="";

document.getElementById("ctl00_ContentPlaceHolder1_txtDescripcionArea").value="";

document.getElementById("ctl00_ContentPlaceHolder1_txtNombre").value="";

document.getElementById("ctl00_ContentPlaceHolder1_txtCodigoArea").disabled=false;

document.getElementById("ctl00_ContentPlaceHolder1_txtCodigoArea").focus();

}

//activacionymuestra2: Esta es la activación de los menús de modificar y eliminar

//Colocar aquí el campo de búsqueda por defecto en el modificar y eliminar

function activacionymuestra2(id,id2)

{




activacionMuestraEliminarModificar(id, id2, 'ctl00_ContentPlaceHolder1_txtCodigoArea');

}

* Donde 'ctl00_ContentPlaceHolder1_txtCodigoArea' es el id del control del lado del cliente

3.4. Menú

El menú permite la navegación dentro de los diferentes forms del proyecto, además ayuda a la validación de los accesos a los formularios, el menú cambiará según el perfil asignado al usuario que ingrese.

El menú se construye a partir del control web Menu, colocado en la página principal, es decir en la máster. Los ítems del menú se cargan dinámicamente según el perfil que esté asociado al Login realizado por el usuario. Esta programación se encuentra en el codebehind de la página principal de la aplicación y se detalla en la sección 3 de Seguridad.

El siguiente son los estándares en el diseño del Menú, en cuanto a colores, tipografía y forma:

<asp:Menu ID="mnMenu"

runat="server" BackColor="#BCCBE5"

DynamicHorizontalOffset="2"

Font-Names="Verdana" Font-Size="1em" ForeColor="#286FA8" Orientation="Horizontal"

StaticBottomSeparatorImageUrl="~/images/bullet.gif"

StaticEnableDefaultPopOutImage="False"

StaticSubMenuIndent="10px" Width="200px">

<LevelSelectedStyles>

<asp:MenuItemStyle BackColor="#E5EAF0" Font-Underline="False"/>

</LevelSelectedStyles>

<StaticMenuStyle BorderColor="White" Width="200px" />




4. Seguridad

4.1. Arquitectura de Seguridad en la Base de Datos

La arquitectura de Base de Datos de seguridad nos permite establecer la relación entre los empleados de una aplicación, sus áreas o departamentos, los formularios de la aplicación y los perfiles asociados a dichos formularios, tal como se muestra a continuación.

Imagen 4: Arquitectura de seguridad en BD 1




Las tablas involucradas son las siguientes:

Nombre Tabla Descripción

tblAreas Almacena el listado de Áreas o departamentos de la institución.

tblEmpleados Almacena el listado de Empleados asociados a un área.

tblUsuarios Almacena los datos de una cuenta de usuario del sistema.

tblPerfiles Almacena el listado de perfiles existentes en la aplicación, los cuales se asocian a los usuarios

tblPerfilDetalles Almacena la especificación de la acción a realizar en los formularios asociándolos a los perfiles La acción a realizar puede ser alguno de los siguientes estados:

tblForms Almacena el nombre de todos los formularios sin tomar en cuenta su prefijo de éstandar. Además los asocia a una sección.

tblSeccion Almacena el nombre de las diferentes secciones que contendrá cada región del menú.




4.2. Esquematización del Menú

El esquema del menú permite al programador ubicar cada una de las partes involucradas en el armado del menú de la aplicación. El esquema posee la siguiente forma:

Imagen 5: Estructura del Menú

Bloques de Menú: Son 4 principales. Los bloques no son leídos dinámicamente, la programación del menú los tiene involucrados.

Inicio: Muestra la pantalla de inicio del sistema

Operaciones: Contiene los formularios que están relacionados con transacciones de datos.

Consulta: Contiene los formularios que están relacionados con consulta de datos.

Seguridad: Contiene los formularios que están relacionados con la administración de empleados, usuarios y perfiles del sistema.

1

2

3

Secciones: contienen una clasificación y organización lógica de los formularios. Las secciones se cargan dinámicamente en el menú y se encuentran almacenadas en la tblSeccion.

Nombres de Formularios: Son los nombres de los formularios a llamar. Los nombres de formularios se cargan dinámicamente en el menú y se encuentran almacenados en la tblForms.

4.3. Modo de Autenticación en webconfig

El modo de autenticación a utilizar es el de Forms de .Net. Las siguientes líneas establecen este modo y deben ser colocadas en el web config en medio de las etiquetas de system.web.

<system.web>



<authentication mode="Forms">

<forms loginUrl="~/frmIngreso.aspx" timeout="120" slidingExpiration="false" defaultUrl="~/frmIngreso.aspx" cookieless="AutoDetect"/>

</authentication>



<authorization>

<deny users="?"/>

</authorization>

</system.web>

El modo de autenticación a utilizar es el de Forms de .Net. Las siguientes líneas establecen este modo y deben ser colocadas en el web config en medio de las etiquetas de system.web.

4.4. Cookies

Las cookies a utilizar registran datos necesarios para la autenticación.




Cookies("SICONESUP")("nombreUsuario"): Almacena el nombre de usuario proveniente de tblUsuarios.strUsuario

Cookies("SICONESUP")("Perfil"): Almacena el nombre del Perfil del usuario proveniente de tblUsuarios. strPerfil

Cookies("SICONESUP")("Nombre"): Almacena el nombre completo del empleado, concatenándose los datos de tblEmpleados.strNombre, tblEmpleados.strPrimerApellido y tblEmpleados.strSegundoApellido

4.5. Proceso de Construcción del Menú:

El menú se construye dinámicamente en la aplicación, leyendo la información del perfil asociado al usuario que ingresa al sistema.

El proceso de construcción del menú es el siguiente:

Primeramente ingrese los datos de las áreas en tblAreas.

Cree al menos un empleado en la tblEmpleados

Ingrese el nombre de un Perfil en tblPerfiles

Cree un Usuario en la tblUsuarios asociado al perfil y empleado creados ingrese los datos de las secciones que van a tener los menús en la tabla tblSeccion.

Agregue los datos de los nombres de los formularios del sistema en la tabla tblForms

Ingrese los detalles del Perfil en la tabla tblPerfilDetalles




Copie los siguientes bloques de código en el codebehind de la página principal de la aplicación.

armarMenu(): Consulta el perfil del empleado y recorre el detalle del mismo según la acción que posea cada formulario, para adjuntarlo como ítem del bloque del menú que corresponda.

Public Sub armarMenu()

Dim objLogicaNegocio As New Usuarios()

Dim myDataSet As New DataSet()

myDataSet = objLogicaNegocio.ConsultarPerfilUsuario(Request.Cookies("SICONESUP")("nombreUsuario"))

Dim myDataRow As DataRow

For i As Integer = 0 To myDataSet.Tables(0).Rows.Count - 1

myDataRow = myDataSet.Tables(0).Rows(i)

Select Case myDataRow.Item("strAccion")

Case ("Si")

Dim Seguridad As New Web.UI.WebControls.MenuItem("Seguridad", "Seguridad", "")

Dim Usuarios As New Web.UI.WebControls.MenuItem("Usuarios", "Usuarios", "", "frmSeguridad/frmMantenimientoUsuarios.aspx")

Dim Perfiles As New Web.UI.WebControls.MenuItem("Perfiles", "Perfiles", "", "frmSeguridad/frmMantenimientoPerfiles.aspx")

Dim Empleados As New Web.UI.WebControls.MenuItem("Empleados", "Empleados", "", "frmSeguridad/frmMantenimientoEmpleados.aspx")

Dim Areas As New Web.UI.WebControls.MenuItem("Areas", "Empleados", "", "frmSeguridad/frmMantenimientoAreas.aspx")

Seguridad.ChildItems.Add(Usuarios)

Seguridad.ChildItems.Add(Perfiles)

Seguridad.ChildItems.Add(Empleados)

Seguridad.ChildItems.Add(Areas)




mnMenu.Items.Add(Seguridad)

Exit Select

Case ("Ambos") 'Si es Administrador(Consulta y Mantenimiento)

mantenimiento(myDataRow)

consulta(myDataRow)

Exit Select

Case ("Mantenimiento") 'Si es Mantenimiento

mantenimiento(myDataRow)

Exit Select

Case ("Consulta") 'Si es Consulta

consulta(myDataRow)

Exit Select

Case ("Ninguno") 'Si no es ninguno

Exit Select

End Select

Next

End Sub

mantenimiento(): Elabora el bloque del menú de operaciones. Recibe un registro del detalle del perfil consultado y lo adjunta como ítem de este bloque de menú y de la sección a la que pertenece.

Public Sub mantenimiento(ByVal myDataRow As DataRow)

Dim itemMantenimiento As New System.Web.UI.WebControls.MenuItem("Operaciones", "Operaciones")

itemMantenimiento = DirectCast(mnMenu.FindItem("Operaciones"), System.Web.UI.WebControls.MenuItem)

If itemMantenimiento Is Nothing Then

itemMantenimiento = New MenuItem("Operaciones", "Operaciones")

mnMenu.Items.Add(itemMantenimiento)




End If

Dim Seccion As New System.Web.UI.WebControls.MenuItem(myDataRow.Item("strSeccion"), myDataRow.Item("strSeccion"))

Dim x As Integer = -1

For j As Integer = 0 To itemMantenimiento.ChildItems.Count() - 1

If (itemMantenimiento.ChildItems.Item(j).Value = myDataRow.Item("strSeccion")) Then

x = j

Exit For

End If

Next

If (x = -1) Then

itemMantenimiento.ChildItems.Add(Seccion)

x = itemMantenimiento.ChildItems.Count - 1

End If

Dim subitem As New System.Web.UI.WebControls.MenuItem(myDataRow.Item("StrNombre"), myDataRow.Item("StrNombre"), "", "frmMantenimientos/frmMantenimiento" + quitarTildes(myDataRow.Item("StrNombre")).Replace(" ", "") + ".aspx", "")

itemMantenimiento.ChildItems.Item(x).ChildItems.Add(subitem)

End Sub

consulta(): Elabora el bloque del menú de consulta. Recibe un registro del detalle del perfil consultado y lo adjunta como ítem de este bloque de menú y de la sección a la que pertenece.

Public Sub consulta(ByVal myDataRow As DataRow)

Dim itemConsulta As New System.Web.UI.WebControls.MenuItem("Consulta", "Consulta")

itemConsulta = DirectCast(mnMenu.FindItem("Consulta"), System.Web.UI.WebControls.MenuItem)




If itemConsulta Is Nothing Then

itemConsulta = New MenuItem("Consulta", "Consulta")

mnMenu.Items.Add(itemConsulta)

End If

Dim Seccion As New System.Web.UI.WebControls.MenuItem(myDataRow.Item("StrSeccion"), myDataRow.Item("StrSeccion"))

Dim x As Integer = -1

For j As Integer = 0 To itemConsulta.ChildItems.Count() - 1

If (itemConsulta.ChildItems.Item(j).Value = myDataRow.Item("StrSeccion")) Then

x = j

Exit For

End If

Next

If (x = -1) Then

itemConsulta.ChildItems.Add(Seccion)

x = itemConsulta.ChildItems.Count - 1

End If

Dim subitem As New System.Web.UI.WebControls.MenuItem(myDataRow.Item("StrNombre"), myDataRow.Item("StrNombre"), "", "frmConsultas/frmConsulta" + quitarTildes(myDataRow.Item("StrNombre")).Replace(" ", "") + ".aspx", "")

itemConsulta.ChildItems.Item(x).ChildItems.Add(subitem)

End Sub

quitarTildes(): Reemplaza las vocales con tíldes por volcales sin tildar.

Public Function quitarTildes(ByVal cadena As String) As String

cadena = cadena.Replace("á", "a")

cadena = cadena.Replace("é", "e")




cadena = cadena.Replace("í", "i")

cadena = cadena.Replace("ó", "o")

cadena = cadena.Replace("ú", "u")

cadena = cadena.Replace("Á", "A")

cadena = cadena.Replace("É", "E")

cadena = cadena.Replace("Í", "I")

cadena = cadena.Replace("Ó", "O")

cadena = cadena.Replace("Í", "U")

Return cadena

End Function

Cree una clase Usuario en el proyecto de Lógica de Negocio, y agregue la función ConsultarPerfilUsuario, la cual recibe el nombre de usuario y devuelve en un dataSet el detalle del perfil.

Public Function ConsultarPerfilUsuario(ByVal strUsuario As String) As DataSet

Dim myDataSet As DataSet = New DataSet()

Try

Dim cmd As SqlCommand = Conexion.generarConexion()

cmd.CommandType = CommandType.StoredProcedure

cmd.CommandText = "palConsultarPerfilUsuario"

cmd.Parameters.AddWithValue("@strUsuario", strUsuario)

'abrimos la conexion

cmd.Connection.Open()

'ejecucion del comando

Dim elDataAdapter As New SqlDataAdapter(cmd)

elDataAdapter.Fill(myDataSet)

'cerrar la conexion

cmd.Connection.Close()




Catch ex As Exception

myDataSet = Nothing

End Try

Return myDataSet

End Function

Cree un procedimiento almacenado en la BD con el nombre palConsultarPerfilUsuario que posea la siguiente instrucción, la cual devuelve la información necesaria para la elaboración del Menú.

CREATE PROCEDURE [dbo].[palConsultarPerfilUsuario]

@strUsuario nvarchar (50)

AS

select tblForms.strNombre, tblForms.strSeccion, tblPerfilDetalles.strAccion

from tblPerfilDetalles, tblForms, tblPerfiles, tblUsuarios

where tblUsuarios.strUsuario = @strUsuario and tblPerfiles.strNombre= tblUsuarios.strPerfil and tblPerfilDetalles.strPerfil=tblPerfiles.strNombre and tblForms.strNombre = tblPerfilDetalles.strForm

order by tblForms.strSeccion

GO

En el codebehind del Formulario, copie el siguiente bloque de código para restringir el acceso a cada formulario. El procedimiento autenticarForm verifica que verdaderamente el usuario no tenga acceso al formulario, preguntándose por la condición de rebote de la acción que posee en la tabla tblPerfilDetalles.

Dim STRFORM As String = "Habilitar Seguridad" 'Nombre del formulario

''' <summary>

''' Realiza la autenticación de que el usuario puede o no visualizar este form

''' </summary>

''' <remarks></remarks>




Public Sub autenticarForm()

Dim objLogica As New Usuarios()

Dim strAccion As String = objLogica.autenticarForm(Request.Cookies("SICONESUP")("Perfil"), STRFORM)

If strAccion = "No" Then 'Condición de rebote

Response.Redirect("~/frmPrincipal.aspx")

End If

End Sub

5. Adicionales

5.1. Búsqueda detallada en formularios de Mantenimi ento

La búsqueda detallada es una herramienta para el usuario con el fin de permitirle realizar consultas por criterios de búsqueda específicos. Se recomienda su utilización en los casos específicos de modificar y eliminar, haciendo su incorporación como un elemento más del menú de estas operaciones.

Imagen 6: Ejemplos de botón de Búsqueda Detallada en los formularios

La búsqueda detallada está constituida por un panel en el formulario, encargado de congelar la pantalla del formulario, y permitiéndole únicamente al usuario utilizar este panel.

Opción de Búsqueda Detallada




Imagen 7: Ejemplos de panel de búsqueda detallada

5.2. Consideraciones para la creación de la Búsqued a Detallada

La búsqueda detallada involucra varios elementos esenciales para su creación. Entre ellos están:

Incorporar la biblioteca de controles de AjaxControlToolkit para .Net. Esto se logra copiando el archivo ajaxControlToolkit.dll en la carpeta:

C:\WINDOWS\MICROSOFT.NET\FRAMEWORK\v2.0.50727

Agregar al cuadro de Herramientas los controles de .NET, los contenidos en la librería. Esto se logra dando clic derecho sobre el panel de controles y seleccionando la opción elegir elementos y activar todos los controles relacionados con el ajaxControlToolkit.




Imagen 8: Elección de controles de ajaxControlToolkit

Verifique que el AjaxExtensionsControls esté debidamente instalado en su equipo. Deberá aparecer en el cuadro de controles este tipo de herramientas.

Imagen 9: Pantalla de Instalación de AjaxExtensions

Agregue al formulario, en tipo de diseño, un ModalPopupExtender asociado a un panel de .Net. Además, dentro del panel, agregue un updatepanel del AjaxExtensions. Dentro del updatepanel coloque los elementos necesarios para realizar las búsquedas, tales como sqlDataSources, GridViews, DropDownLists y botones.




Imagen 9: Ejemplo de controles para la búsqueda detallada

Verifique que las propiedades del ModalPopupExtender sean las apropiadas. Es necesario que exista una clase css para el manejo de color de fondo y transparencia:

.congelar

{

background-color:black ;

filter:alpha(opacity=60);

opacity:0.6;

}

<cc1:ModalPopupExtender

BackgroundCssClass="congelar"

PopupControlID="Panel1"

ID="ModalPopupExtender1"

TargetControlID="ibtDetalles"

OkControlID="btnCerrar"

runat="server">




</cc1:ModalPopupExtender>

Programe los procedimientos restantes para el funcionamiento adecuado de la búsqueda detallada.




15. CONCLUSIÓN

Este manual debe ser aplicado para todos los desarrollos de Software del Ministerio de Educación Pública realizados a partir del 01 de enero de 2009, de forma tal que se estandarice la forma de documentar los sistemas según este formato.

Cualquier duda en la aplicación de éste puede ser remitida al encargado en el Departamento de Innovación Tecnológica y Control Informático.

Es de vital importancia que se elabore la documentación de los sistemas desde el momento en que son solicitados, ya que el Departamento de Innovación Tecnológica y Control Informático realiza las revisiones de la misma en cualquier etapa del proyecto.




16. BIBLIOGRAFÍA

Documentos Digitales

Manual de Lineamientos versión 3.pdf

Manual del ciclo de vida para ingeniería del software v. 1.2.docx

Manual del Estándar para Documentación del Ministerio de Educación, San José Costa Rica, 2010

Referencias

http://docentes.uni.edu.ni/ftc/Trinidad.Perez

http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso

http://es.wikipedia.org/wiki/Diagrama_de_secuencia

http://www.it.uc3m.es/tsps/testing.htm#s2

http://lsi.ugr.es/~arroyo/inndoc/doc/pruebas/pruebas_d.php

http://www.ldc.usb.ve/~teruel/ci4713/clases2001/planPruebas.html

est ndares para el proceso institucional de desarrollo y ... · este manual le mostrará los...

Documents