Est ndares para el Proceso Institucional de Desarrollo y ... · Este manual le mostrará los...
Transcript of 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
MINISTERIO DE EDUCACIÓN PÚBLICA
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 3 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 4 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 5 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 6 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 7 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 8 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 9 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 10 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 11 de 125 15 de febrero 2012
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:
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 12 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 13 de 125 15 de febrero 2012
• 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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 14 de 125 15 de febrero 2012
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,
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 15 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 16 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 17 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 18 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 19 de 125 15 de febrero 2012
• 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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 20 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 21 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 22 de 125 15 de febrero 2012
• 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".
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 23 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 24 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 25 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 26 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 27 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 28 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 29 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 30 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 31 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 32 de 125 15 de febrero 2012
• 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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 33 de 125 15 de febrero 2012
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 PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 34 de 125 15 de febrero 2012
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”
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 35 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 36 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 37 de 125 15 de febrero 2012
• 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”.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 38 de 125 15 de febrero 2012
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 %
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 39 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 40 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 41 de 125 15 de febrero 2012
• 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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 42 de 125 15 de febrero 2012
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:
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 43 de 125 15 de febrero 2012
• 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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 44 de 125 15 de febrero 2012
• 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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 45 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 46 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 47 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 48 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 49 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 50 de 125 15 de febrero 2012
14. ANEXOS
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 51 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 52 de 125 15 de febrero 2012
Márgenes
� Izquierdo 3 cm
� Derecho 2,5 cm
� Superior 2,5 cm
� Inferior 2,5 cm
Tamaño de papel
� Carta
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 53 de 125 15 de febrero 2012
14.2. ANEXO No. 2
14.2.1. Rotulación de Disco Compacto parte externa
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 54 de 125 15 de febrero 2012
14.2.2. Rotulación de Disco Compacto superficie del disco
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 55 de 125 15 de febrero 2012
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
Solicitante Departamento de Registros Laborales.
Descripción Contar con una interfaz amigable que brinde ayuda al usuario y le facilite la realización de sus tareas.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 56 de 125 15 de febrero 2012
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
Solicitante Departamento de Registros Laborales.
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 57 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 58 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 59 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 60 de 125 15 de febrero 2012
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:
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 61 de 125 15 de febrero 2012
14.7. ANEXO No. 7
14.7.1. Acta Aceptación de la fase Preinversión
Ministerio de Educación Pública
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 62 de 125 15 de febrero 2012
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).
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 63 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 64 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 65 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 66 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 67 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 68 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 69 de 125 15 de febrero 2012
14.14. Anexo 14.
Aplicaciones WEB
14.14.1. Formularios de Ingreso (Login)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 70 de 125 15 de febrero 2012
14.14.2. Formulario Principal
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 71 de 125 15 de febrero 2012
14.14.3. Menú dentro del formulario principal
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 72 de 125 15 de febrero 2012
14.14.4. Formularios de Mantenimiento
Menú Modificar
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 73 de 125 15 de febrero 2012
Filtros
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 74 de 125 15 de febrero 2012
14.14.5. Formularios de Consulta
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 75 de 125 15 de febrero 2012
14.14.6. Formularios de Modificar la Contraseña
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 76 de 125 15 de febrero 2012
Aplicaciones Cliente/Servidor
14.14.7. Formularios de Mantenimiento
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 77 de 125 15 de febrero 2012
14.14.8. Formularios de Actualización
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 78 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 79 de 125 15 de febrero 2012
14.16. ANEXO No. 16
14.16.1. Tabla de Entidades del Sistema
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 80 de 125 15 de febrero 2012
14.17. ANEXO No. 17
14.17.1. Tabla de los requerimientos de los procesos del sistema
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 81 de 125 15 de febrero 2012
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:
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 82 de 125 15 de febrero 2012
14.19. ANEXO No. 19
14.19.1. Acta aceptación Fase
Ministerio de Educación Pública
Dirección Informática de Gestión
Nombre del Sistema
ACEPTACIÓN DE LA ETAPA DE PROMOCIÓN, NEGOCIACIÓN
Y FINANCIAMIENTO
Elaborado por:
___________________________
Implicado(s)
Aprobado por:
______________________ ______________________
Implicado(s) Ing. Gabriel Dennis
Enero 2009
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 83 de 125 15 de febrero 2012
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:
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 84 de 125 15 de febrero 2012
14.20.2. Iconos que se deben utilizar en las aplicaciones
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 85 de 125 15 de febrero 2012
Limpiar
Exportar
Importar
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 86 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 87 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 88 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 89 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 90 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 91 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 92 de 125 15 de febrero 2012
14.25. ANEXO No. 25
14.25.1. Acta Aceptación Fase
Ministerio de Educación Pública
Dirección Informática de Gestión
Nombre de la fase
ACEPTACIÓN OFICIAL DE LA ETAPA DE INVERSION Y EJECUCIÓN
Elaborado por:
___________________________
Implicado(s)
Aprobado por:
______________________ ______________________
Implicado(s) Ing. Gabriel Dennis
Enero 2009
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 93 de 125 15 de febrero 2012
14.26. ANEXO No. 26
14.26.1. Acta Aceptación oficial del Sistema
Ministerio de Educación Pública
Dirección Informática de Gestión
Nombre del Sistema
ACEPTACIÓN OFICIAL DEL SISTEMA
Elaborado por:
___________________________
Implicado(s)
Aprobado por:
______________________ ______________________
Implicado(s) Ing. Gabriel Dennis
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 94 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 95 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 96 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 97 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 98 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 99 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 100 de 125 15 de febrero 2012
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 .
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 101 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 102 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 103 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 104 de 125 15 de febrero 2012
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)
{
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 105 de 125 15 de febrero 2012
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" />
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 106 de 125 15 de febrero 2012
<StaticSelectedStyle BackColor="#5D7B9D" />
<StaticMenuItemStyle
BorderColor="White" HorizontalPadding="5px" VerticalPadding="2px" />
<DynamicHoverStyle BackColor="#6CB3EC" ForeColor="White" />
<DynamicMenuStyle BackColor="#E1EDFB" />
<DynamicSelectedStyle BackColor="#5D7B9D" />
<DynamicMenuItemStyle HorizontalPadding="5px"
VerticalPadding="2px" />
<StaticHoverStyle BackColor="#89C1EF"
Font-Bold="true" ForeColor="White" />
<Items>
<asp:MenuItem NavigateUrl="~/frmPrincipal.aspx" Text="Inicio" Value="Inicio"></asp:MenuItem>
</Items>
</asp:Menu>
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 107 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 108 de 125 15 de febrero 2012
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ú.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 109 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 110 de 125 15 de febrero 2012
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>
<!--modo de autenticación-->
<authentication mode="Forms">
<forms loginUrl="~/frmIngreso.aspx" timeout="120" slidingExpiration="false" defaultUrl="~/frmIngreso.aspx" cookieless="AutoDetect"/>
</authentication>
<!--autorización: denegar a usuarios q no se han logueado-->
<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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 111 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 112 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 113 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 114 de 125 15 de febrero 2012
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)
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 115 de 125 15 de febrero 2012
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")
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 116 de 125 15 de febrero 2012
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()
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 117 de 125 15 de febrero 2012
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>
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 118 de 125 15 de febrero 2012
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
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 119 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 120 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 121 de 125 15 de febrero 2012
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">
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 122 de 125 15 de febrero 2012
</cc1:ModalPopupExtender>
Programe los procedimientos restantes para el funcionamiento adecuado de la búsqueda detallada.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 123 de 125 15 de febrero 2012
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.
ESTÁNDARES PARA EL PROCESO INSTITUCIONAL DE DESARRO LLO Y MANTENIMIENTO DE SOFTWARE
MINISTERIO DE EDUCACIÓN PÚBLICA
Versión: 3.0 Página 124 de 125 15 de febrero 2012
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