Manual Ppi Entregables v1.1

MANUAL DE PROCEDIMIENTOS

PARA LA ELABORACIÓN DEL

PROYECTO PEDAGÓGICO

INTEGRADOR NIVEL POR NIVEL (Versión 1.1)

01/08/2011

Politécnico Colombiano Jaime Isaza Cadavid CLAUDIA ALEJANDRA ROSERO NOGUERA

PRESENTACIÓN

El Politécnico Colombiano Jaime Isaza Cadavid es una Institución de Educación superior, que se dedica a la

formación de la juventud antioqueña; con una marcada y reconocida vocación hacia la Educación Técnica y

Tecnológica.

En la actualidad nos encontramos inmersos en la era del conocimiento, que determina nuevos modelos de

actuación donde la tecnología y el conocimiento son imprescindibles para el crecimiento, fortalecimiento y

permanencia en los diferentes ámbitos sociales. Por ello el compromiso de la institución por la formación de

profesionales íntegros con las competencias que el sector productivo necesita.

Los procesos de enseñanza, aprendizaje y evaluación deben desarrollar formas para medir, acompañar y

ajustar sus gestiones para el logro de los resultados propuestos en los Niveles de formación. Este propósito se

plantea desde la formación por proyectos en los que se empleen competencias de formación en situaciones y

problemas diversos, graduales y continuos de cada Nivel académico respectivo, enmarcados en la creatividad y

la formación pedagógica.

Por lo anterior, se presenta este manual, el cual pretende orientar al estudiante a realizar paso a paso la

elaboración del Proyecto Pedagógico Integrador (PPI).

PERFIL DEL ESTUDIANTE

El graduado de la Técnica Profesional en Programación de Sistemas de Información, podrá desempeñar los

siguientes roles:

Programador Junior: Dado un diseño puede implementarlo en un ambiente específico.

Auxiliar de documentación

Auxiliar en el soporte básico de aplicativos

Probador de software: A partir de una lista de chequeo verifica el cumplimiento de especificaciones.

Auxiliar en mantenimiento de Sistemas

El graduado de la Tecnología en Sistematización de Datos en apoyo a equipos coordinados por Ingenieros,

podrá ser:

Asistente en levantamiento de requerimientos.

Asistente de diseño

Programador Junior en una plataforma tecnológica

Ejecutor de planes de prueba.

Asistente en la construcción de planes de pruebas

Soporte técnico informático e Instrucción a usuarios finales.

Documentador de manuales para sistemas de información

Administrador de Recursos Informáticos

COMPETENCIAS ESPECÍFICAS Y TRANSVERSALES A DESARROLLAR

MÓDULOS SOL

Co

mp

eten

cias

Gen

eral

es

Requisitos Diseño Programación Pruebas Implantación

Cl

ie

nt

e

Cl

ie

nt

e

Co

mp

eten

cias

Esp

ecíf

icas

esp

ecíf

icas

Programar en un lenguaje

Documentación

de Software

Construcción de

modelos de

datos

Pruebas de

Software

Soporte a

usuario

Manejo de Negociación

Comprensión del Enfoque Sistémico /

Procesos

Comprensión Organizacional

Modelamiento de Datos

Operador de

Recursos

Informáticos

- Trabajo en equipo - Manejo de las TICs - Pensamiento conceptual - Orientación al logro - Gestión de la Información - Organización y planificación - Comunicación oral y escrita - Pensamiento Analítico Sistémico - Interpretación de documentos - Investigación y creatividad - Pensamiento Algorítmico - Aplicar mejores prácticas

Módulo sol: Módulo que coordina a los demás módulos del semestre para desarrollar satisfactoriamente

el PPI. El profesor de éste módulo tiene a su cargo la responsabilidad de organizar, acompañar y gestionar los

PPI de los estudiantes durante el semestre.

MODULOS SOL DE LA TÉCNICA

MODULOS SOL DE LA TECNOLOGÍA

•Identificación del Ciclo de Vida del Software

•Pensamiento Analítico Sistémico I (*)

PRIMER SEMESTRE

•Definición de Requerimientos

•Pensamiento Analítico Sistémico II (*)

SEGUNDO SEMESTRE

•Construcción de elementos de Software Web

•Pensamiento Analítico Sistémico III (*)

TERCER SEMESTRE

•Garanitizar el cumplimiento de los Requerimientos del Software

CUARTO SEMESTRE

•Análisis de Requerimientos

•Construcción de elementos de Software 2 (*)

QUINTO SEMESTRE

•Diseño del Sistema


SEXTO SEMESTRE

•Implantar el Sistema de Información


SÉPTIMO SEMESTRE

(*) Módulo Sol Alternativo, sólo en casos especiales, aprobados por la Coordinación del PPI

QUE ES UN PROYECTO PEDAGÓGICO INTEGRADOR?

Proyecto Pedagógico Integrador: tipo de proyecto que centra su interés en la gestión educativa compartida,

por lo que se caracteriza en no corresponder a áreas específicas de formación. Se asume como una estrategia

didáctica que puede involucrar la participación de la comunidad que rodea el centro educativo, que tiene

límites en el tiempo y resultados que se concretan mediante productos de gestión (Nikerson, Perkins y Otros,

1994).

El PROYECTO PEDAGÓGICO INTEGRADOR (PPI) se constituye en la estrategia didáctica de integración modular

que da la oportunidad al estudiante de demostrar ante la comunidad académica que es merecedor de forma

integral de continuar con su proceso de formación al siguiente nivel.

Esto significa que el estudiante debe utilizar las competencias adquiridas durante su formación para proponer

un proyecto del nivel de formación respectivo. Además de lo anterior, el PROYECTO PEDAGÓGICO

INTEGRADOR (PPI) constituye una experiencia de auto-aprendizaje para el estudiante, dado el grado de

profundidad y dedicación que este implica, convirtiéndolo en la experiencia perfecta de la educación del futuro

profesional del sector del software.

La técnica Profesional en sistemas de información del Politécnico Colombiano Jaime Isaza Cadavid fundamenta

su proceso formativo en la canalización del esfuerzo del estudiante hacia el desarrollo de un proyecto que

reúna las competencias aportadas por todos los módulos que hacen parte del semestre. Esto se entiende

como una estrategia didáctica que involucra límites de tiempo y resultados que se concreta mediante

productos de gestión.

Para comprender la importancia del proyecto pedagógico integrador es necesario identificar que es un

proceso adquirido por el estudiante para iniciar su ciclo formativo como Técnico profesional; como su nombre

lo indica “integra” la dinámica de enseñanza y las competencias obtenidas y desarrolladas en los demás

módulos que se ven durante el semestre y su respectiva aplicación.

OBJETIVO DEL PPI

Aplicar de manera integral las competencias desarrolladas en los diversos módulos de los niveles en proceso

ascendente de lo simple a complejo, con proyecciones hacia la creatividad y el inicio de actividades

investigativas.

GUIA PARA EL

EQUIPO DE

ESTUDIANTES,

PARA LA

ELABORACIÓN DE SU

PPI

ENTREGABLES SEMESTRE POR SEMESTRE

Se define la generación de entregables ligados al ciclo de vida del software como evidencia

objetiva del proceso de aprendizaje, cada semestre el nivel de dificultad varía dependiendo de las

competencias a alcanzar en los diferentes módulos.

Los proyectos internos de clase el alcance será asignado por el docente del

módulo sol alternativo

Recuerde…

Cada entregable se debe presentar en

un solo documento, teniendo en cuenta

la norma ICONTEC vigente.

I.M.P.O.R.T.A.N.T.E

El Docente del módulo de

programación se encarga de evaluar

el código antes de cada socialización.

A continuación se describe lo que deben entregar nivel por nivel:

Para desarrollar satisfactoriamente su PPI, tenga en cuenta los siguientes anexos, los cuales

contienen los documentos necesarios para realizar los entregables:

Esquema de Actividades (Anexo 1): Es una lista de actividades que facilita la creación del diagrama de Gantt, tenga en cuenta las semanas del semestre con las diferentes actividades que aseguren el cumplimiento del proyecto.

Lista de chequeo para verificar interpretación de especificaciones (Anexo 2): Diligenciar la lista, la cual le permite al docente del módulo sol, verificar la interpretación del documento que se entregó.

Estándar Diseño de Interfaz de Usuario (Anexo 3)

Estándar para Codificar (Anexo 4)

Estándar Manual de Usuario (Anexo 5)

El profesor del módulo sol (Identificación del

Ciclo de Vida del Software), es el responsable

de entregar a los estudiantes las

Especificaciones proyecto asignado.

ENTREGABLE 1 Semana 8 Politécnico

EL EQUIPO DE PPI DEBE ENTREGAR POR ESCRITO

Diagrama de Gantt

Con base en el esquema de Actividades (Anexo 1), debe construir en una herramienta ofimática el Diagrama de Gantt. Recuerde que en el esquema, deben estar discrimina das todas las actividades de PPI, a realizar durante todo el proyecto, indicando tiempo estimado y tiempo real.

Impactos y posibles beneficiarios del proyecto

Debe analizar cuáles son los impactos y posibles beneficiarios del proyecto a desarrollar; tenga en cuenta que no todo proyecto, posee los aspectos indicados a continuación, ya que puede ser el caso de que alguno o algunos de ellos no tengan repercusión o relevancia en el proyecto; o por el contrario, se puede determinar otro tipo de impactos en otras áreas o aspectos.

Impacto Social: Establezca de que manera el proyecto contribuirá en el desarrollo de la sociedad y en qué sentido influirán los resultados del trabajo en determinados sectores sociales.

Impacto Ambiental: Indique en que aspectos el proyecto tiene beneficios o riesgos

ecológicos; o como el proyecto puede mejorar y controlar aspectos ambientales negativos.

Impacto Educativo: Indicar de que manera el proyecto beneficiará generalmente o

particularmente al proceso de enseñanza-aprendizaje personal y/o de la sociedad.

Impacto Económico: Indique las repercusiones (beneficios y/o problemas) de carácter económico que tendrá el proyecto en el ámbito local, regional o nacional; se puede señalar los aspectos económicos positivos que provocará el proyecto en los individuos, grupos o sociedad.

Solución a la lista de chequeo para verificar interpretación de especificaciones

Con base en la lista de chequeo Anexo 2 debe diligenciar parcialmente los ítems con la temática que conoce.

Mapa de Navegación

Un mapa de navegación sirve para forma parte del diseño y en este sentido es cada vez más fundamental definir el mapa de navegación o esquema detallado de las opciones que va a tener el usuario en cada parte del sistema. Esto supone responder a las siguientes preguntas:

- ¿Hacia dónde se puede ir desde cada sitio? - ¿Siempre se puede volver al principio?

Ejemplo:

Ejemplo:

Ejemplo:

Ejemplo:

- ¿Hay varios principios? - ¿Cómo se jerarquiza? - ¿Hay secciones separadas? - ¿Se debe poder desplazar sólo por cada sección? - ¿Cuántos y qué enlaces fuera de la sección deben existir, y por qué?

Se está simplificando mucho el concepto de enlace, y quizás es un buen punto para volver a los principios: no hay sólo "enlaces", sino que hay muchos tipos lógicamente distintos:

Enlaces de significado (de explicación, de completar el concepto). Enlaces de relación (temas relacionados) Enlaces de contexto. Enlaces de secuencia de navegación. Enlaces jerárquicos (estructurales). Enlaces específicos de la aplicación

Un mapa de navegación representa una opción más para que el usuario conozca dónde está, por dónde ha pasado, y qué le falta por ver y le permite desplazarse dentro del mismo.

EJEMPLO MAPA DE NAVEGACIÓN En la figura 1, se muestra el mapa de navegación de un producto multimedia para aprender algoritmos, con el tema específico de ciclos. De acuerdo con la planeación de este proyecto, el producto multimedia está compuesto por cinco pantallas:

- Menú principal - Presentación del tema: ”Ciclos” - Créditos - Ejemplos - Ejercicios

RECUERDA. Un mapa de navegación puede

representarse en forma textual, en forma

gráfica o una combinación de ambas. Parecida

a un organigrama o árbol genealógico.

Definición de las pantallas del ejemplo anterior

Bosquejo de Ventanas

Una interfaz de usuario, permite al cliente visualizar el sistema, aclarar opciones sobre los requerimientos y especificar detalles a incluir en el sistema a desarrollar. Debe tener en cuenta los estándares de diseño entregados y el mapa de navegación elaborado por el equipo de trabajo, para implementar la funcionalidad.

SUGERENCIA. La definición de los elementos en el mapa de navegación deberá

realizarse de forma general. La descripción a detalle de los elementos se realizará en la

etapa de diseño detallado.

Mapa Conceptual

El equipo de trabajo debe realizar un mapa conceptual diferenciando la necesidad, objetivo, problema del proyecto asignado

(Semana 9)

Portada Breve explicación del proyecto, teniendo en cuenta el mapa conceptual (Video o

animación). Duración del video máximo 3 minutos Revisión impactos por medio de un Mapa conceptual o mental Explicación del mapa de navegación Avance bosquejo de formularios en una herramienta de prototipado (Pencil,

balsamik mockups, idoco, cacoo entre otros) NOTA: El material a utilizar en la socialización, debe ser entregada máximo el día viernes de la semana 9, hasta las 11m. Equipo que no haga esta entrega se lo evaluará sobre 4.0.

ENTREGABLE 2 Semana 17

EL ESTUDIANTE ES EL RESPONSABLE DE ENTREGAR

Solución a la lista de chequeo para verificar interpretación de especificaciones

Con base en la lista de chequeo entregada, usted debe terminar de diligenciar dicho documento.

Aplicación funcionando.

De acuerdo a la interfaz ya diseñada y teniendo en cuenta el módulo asignado del proyecto Debe presentar: - La ventana de ingreso al sistema (indicando usuario y contraseña)

TENER EN CUENTA

Presentación en una herramienta ofimática

Redacción, ortografía Legalidad en la información

presentada (Referenciar documentos e imágenes)

Técnicas de exposición

- Una ventana que indique la implementación de alguna funcionalidad, con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-Borrar –List - Listar) - De la ventana desarrollada anteriormente se debe poder generar una consulta. NOTA.

El Almacenamiento de la información se debe hacer en Arreglos. Las funcionalidades se deben implementar en Java.

Avance de Prototipo de Manual de Usuario

El estudiante debe entregar avance del manual de usuario de las funcionalidades desarrolladas del proyecto, acorde a los estándares entregados. PONER MANUAL TYT

(Semana 18)

Portada Breve explicación del proyecto, teniendo en cuenta el mapa conceptual Aplicación funcionando (Almacenamiento de la información en Arreglos)

- La ventana de ingreso al sistema (indicando usuario y contraseña) - Una ventana que indique el funcionamiento con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-Borra, List-listar) - De la funcionalidad desarrollada anteriormente se debe poder generar una consulta.

NOTA: El material a utilizar en la socialización, debe ser entregada máximo el día viernes de la semana 18, hasta las 12m. Equipo que no haga esta entrega no se le permitirá exponer.

TENER EN CUENTA: Redacción, ortografía. Legalidad en la información presentada Dominio en la exposición proyecto Presentación en alguna herramienta ofimática Validación de datos Almacenamiento de la información en

Matrices y Vectores

SEGUNDO SEMESTRE

Para desarrollar satisfactoriamente su PPI, tenga en cuenta los siguientes anexos, los cuales

contienen los documentos necesarios para realizar los entregables:

Estándar Diseño de Interfaz de Usuario (Anexo 3)

Estándar para Codificar (Anexo 4)

Estándar Manual de Usuario (Anexo 5)

El profesor del módulo sol (Definición de Requerimientos o Pensamiento Analítico y Sistémico II),

realiza un conversatorio con sus estudiantes sobre el alcance de los proyectos.



Diagrama de Gantt

Con base en el diagrama de actividades anexo 1, el estudiante debe construir en una herramienta ofimática el Diagrama de Gantt actualizado.

Mapa de Navegación

Un mapa de navegación sirve para forma parte del diseño y en este sentido es cada vez más fundamental definir el mapa de navegación o esquema detallado de las opciones que va a tener el usuario en cada parte del sistema. Esto supone responder a las siguientes preguntas:

- ¿Hacia dónde se puede ir desde cada sitio? - ¿Siempre se puede volver al principio? - ¿Hay varios principios? - ¿Cómo se jerarquiza? - ¿Hay secciones separadas? - ¿Se debe poder desplazar sólo por cada sección? - ¿Cuántos y qué enlaces fuera de la sección deben existir, y por qué?

Se está simplificando mucho el concepto de enlace, y quizás es un buen punto para volver a los principios: no hay sólo "enlaces", sino que hay muchos tipos lógicamente distintos:

Enlaces de significado (de explicación, de completar el concepto). Enlaces de relación (temas relacionados) Enlaces de contexto. Enlaces de secuencia de navegación. Enlaces jerárquicos (estructurales). Enlaces específicos de la aplicación

Un mapa de navegación representa una opción más para que el usuario conozca dónde está, por dónde ha pasado, y qué le falta por ver y le permite desplazarse dentro del mismo.

EJEMPLO MAPA DE NAVEGACIÓN

En la figura 1, se muestra el mapa de navegación de un producto multimedia para aprender algoritmos, con el tema específico de ciclos. De acuerdo con la planeación de este proyecto, el producto multimedia está compuesto por cinco pantallas:

- Menú principal - Presentación del tema: ”Ciclos” - Créditos - Ejemplos - Ejercicios

Definición de las pantallas del ejemplo anterior

RECUERDA. Un mapa de navegación puede

representarse en forma textual, en forma

gráfica o una combinación de ambas.

Parecida a un organigrama o árbol

genealógico.

SUGERENCIA. La definición de los elementos en el mapa de navegación deberá

realizarse de forma general. La descripción a detalle de los elementos se realizará en la

etapa de diseño detallado.

Mapa Conceptual

El equipo de trabajo debe realizar un mapa conceptual diferenciando la necesidad, objetivo, problema del proyecto asignado

Avance de Programación

El avance de programación El docente del módulo sol le asignará a cada equipo la funcionalidad a realizar, entre ellos puede estar:

- Módulo de seguridad: Creación de Usuarios y perfiles (mínimo 3) - Maestros con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-

Borrar, Listar-list) - entre otros

Almacenamiento de la información en: o Listas y archivos para estudiantes de demanda autónoma. o Listas y Bases de Datos para estudiantes articulados

Los estudiantes articulados deben continuar con su proyecto del semestre anterior desarrollado en web. Nota.

Usted debe tener en cuenta los estándares de diseño entregados.

(Semana 9 )

Portada Breve explicación del proyecto, teniendo en cuenta el mapa conceptual por medio de

un Video o animación. Duración 3 minutos Explicación Mapa de Navegación Avance de programación El avance de programación se hará en java. El docente del módulo sol le asignará a cada

equipo la funcionalidad a realizar, entre ellos puede estar: - Módulo de seguridad: Creación de Usuarios y perfiles (mínimo 3) - Maestros con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-

Borrar, Listar-list) entre otros Almacenamiento de la información en:

Listas y archivos para estudiantes de demanda autónoma. Listas y Bases de Datos para estudiantes articulados

Los estudiantes articulados deben continuar con su proyecto del semestre anterior desarrollado en web.

TENER EN CUENTA

Presentación en una herramienta ofimática

Redacción, ortografía Legalidad en la información presentada

(Referenciar documentos e imágenes) Técnicas de exposición Almacenamiento de la información en

listas y archivos para estudiantes de demanda autónoma. Listas y Bases de Datos para estudiantes articulados




De acuerdo al mapa de navegación, debe implementar las funcionalidades del proyecto de acuerdo a las especificaciones y estándares entregados.

Módulo de seguridad: Parametrizado, indicando Usuarios, perfiles (mínimo 3) con sus respectivos permisos, éstos deben poderse modificar.

Maestros con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-Borrar, List-listar)

Un módulo completo que solucione una funcionalidad. Reportes predefinidos Implementar diferentes parámetros de búsqueda

Requerimientos de Infraestructura y Utilidades del Sistema

Debe documentar: Cuáles son los requisitos mínimos de memoria y disco duro, para el correcto

funcionamiento de la aplicación. Adicionalmente debe:

Implementar el About o Acerca de… Éste debe indicar Versión, Autores y correo

Avance de Prototipo de Manual de Usuario

El estudiante debe entregar avance del manual de usuario de las funcionalidades desarrolladas del proyecto, acorde a los estándares entregados. PONER MANUAL TYT

(Semana 18)

Portada Breve explicación del proyecto, teniendo en cuenta el mapa conceptual Implementación de las funcionalidades del programa planteado, el cual debe incluir

- Módulo de seguridad: Parametrizado, indicando Usuarios, perfiles (mínimo 3) con sus respectivos permisos, éstos deben poderse modificar.

- Un módulo completo que solucione una funcionalidad. Explicación detallada del proceso implementado.

- Reportes predefinidos - Implementar diferentes parámetros de búsqueda

TENER EN CUENTA: Redacción, ortografía. Legalidad en la información presentada Dominio en la exposición proyecto Validación de datos Almacenamiento de la información en listas y

archivos para estudiantes de demanda autónoma. Listas y Bases de Datos para estudiantes articulados

TERCER SEMESTRE


Funcionalidad implementada

Debe implementar Módulo de seguridad: Parametrizado, indicando Usuarios, perfiles (mínimo 3) con sus

respectivos permisos, éstos deben poderse modificar. Maestros con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-

Borrar, List-listar) Nota. Desarrollo web y almacenamiento de la información en Base de Datos

Requerimiento de Infraestructura: Utilidades del Sistema

Utilizar herramientas del sistema para administrar perfiles de usuario, para el aplicativo… Mínimo dos roles.

Manual de Usuario

Construir manual de usuario con base en los avances en el desarrollo del software

(Semana 9) Portada

Descripción del problema, explicación global del proyecto. Con un Video o animación. Duración máxima 3 minutos

Manejar perfiles con sus respectivo permisos Manejo de estándares web Manejo de sesiones Avance en conocimientos en BD Módulo de seguridad: Parametrizado, indicando Usuarios, perfiles (mínimo 3) con sus

respectivos permisos, éstos deben poderse modificar. Maestros con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-

Borrar, List-listar)



De acuerdo a las especificaciones entregadas, el estudiante debe terminar de implementar las funcionalidades del proyecto en web.

Módulo de seguridad: Parametrizado, indicando Usuarios, perfiles (mínimo 3) con sus respectivos permisos, éstos deben poderse modificar.

Maestros con el CRUDL (Create-Crear, Recovery-Consultar, Update-Actualizar, Delete-

Borrar, List-listar) Un módulo completo que solucione una funcionalidad. Reportes predefinidos Usted debe realizar el diseño para estadísticas, informes dinámicos…

Documentación del Código según estándares

El estudiante debe documentar su código de acuerdo a los estándares de java y web respectivamente.

Validación de Datos

El estudiante debe realizar pruebas básicas al proyecto.

Manual de Usuario y del Sistema

El estudiante debe entregar el manual de usuario y del Sistema, de acuerdo a los estándares; teniendo en cuenta el cumplimiento del alcance del proyecto.


A través de un documento explicar paso a paso como: Generar un archivo de registro del Software, cuando éste se ejecute se debe validar la

autenticación; es decir el rango de la dirección IP. Utilizar Herramientas del sistema para generar informes en el momento de instalación, es

decir: - Cómo está el Disco duro - About: Versión, Autores y correo

Reflexión o lecciones aprendida

El estudiante debe entregar en un documento aplicando normas Icontec las lecciones aprendidas al desarrollar el proyecto.

Semana 18

Portada Toda la aplicación funcionando Web y Escritorio Elaborar reportes definidos por el usuario Portabilidad del software Manejo de históricos Manual de usuario y del sistema Módulo web terminado e integrado Diseño de ayuda y a cerca de… Aplicación de las reglas del negocio a la Base de Datos

IMPORTANTE. En la semana 18 el equipo debe entregar

un CD con todo su proyecto terminado y debidamente

documentado incluyendo entregables desde el 1er

semestre hasta la fecha y el software terminado e

integrado (incluir códigos fuente y archivos .war y .jar)

CUARTO SEMESTRE


Software Escritorio y web

Entrega de la aplicación completa.


Utilizar herramientas del sistema para administrar perfiles de usuario, para el aplicativo…

Manual de Usuario y del Sistema

El estudiante debe entregar el manual de usuario y del Sistema, de acuerdo a los estándares; teniendo en cuenta el cumplimiento del alcance del proyecto.

Descripción Proyecto Asignado

El equipo debe describir el estado actual del proyecto asignado

Avance Pruebas realizadas a la fecha

Avance de pruebas realizadas al proyecto asignado

(Semana 9)

Portada Software Escritorio y web Manual de Usuario y del Sistema integrado al proyecto Descripción Proyecto Asignado Avance Pruebas realizadas a la fecha


Pruebas

Presentar pruebas de: - Top Down o Botton up - caja blanca - caja negra

Aplicabilidad

Explicar la aplicación de cada una de las pruebas realizadas.

Resultado

Explicar los resultados obtenidos con las pruebas realizadas

(Semana 18)

Portada Presentar pruebas de:

- Top Down o Botton up - caja blanca - caja negra

Aplicación de cada una de las pruebas realizadas. Resultados obtenidos con las pruebas realizadas

ANEXOS Anexo 1. Esquema de Actividades

Nro. Act

FASE ACTIVIDADES

1 planificación 2 planificación Leer del documento con las especificaciones del proyecto entregado

3 Interpretar documento de especificaciones 4 Construir en Gannt Projet el Diagrama de Actividades 5 Elaborar los impactos del proyecto 6 Diligenciar (Avance) lista de chequeo para verificar interpretación de

especificaciones 7 Interpretar estándares de Diseño 8 Interpretar estándares para codificar 9 Interpretar documento Manual de Usuario 10 Elaborar Mapa de Navegación de la solución (walkthrough) 11 Desarrollar un prototipo navegacional (deseable funcional) 12 Realizar primera entrega 13 Realizar primera Socialización 14 Continuar diligenciando la lista de chequeo para verificar interpretación

de especificaciones 15 Terminar de desarrollar el software con todos los componentes 16 Documentar el código del software elaborado 17 Elaborar manual de usuario 18 Realizar test de pruebas 19 Realizar lista de autoevaluación (Reflexiones o lecciones aprendidas) 20 Terminar diligenciamiento lista de chequeo para verificar interpretación

de especificaciones 21 Realizar Segunda entrega 22 Realizar segunda Socialización

Anexo 2. Lista de chequeo para verificar interpretación de especificaciones

ID DESCRIPCION SI NO 1 ¿Considera que el alcance debe complementarse?

2 ¿Considera que el sistema propuesto soluciona los problemas detectados en el sistema actual?

3 ¿Los requisitos explican la funcionalidad a implementar?

4 ¿Necesita mejorar o complementar los requisitos planteados para cumplir satisfactoriamente con la solución? (Si su respuesta es si, diligencie el Anexo al final del documento)

5 ¿El caso de uso tiene un nombre que corresponde a la descripción del sistema?

6 ¿El caso de uso tiene una identificación de acuerdo al estándar?

7 ¿Esta el caso de uso asociado a algún requisito?

8 ¿Tiene la descripción el propósito del caso de uso?

9 ¿Está definido el alcance del caso de uso y del proyecto?

10 ¿Están incluidas los pre-condición de entrada?

11 ¿Están incluidas las post-condiciones de salida?

12 ¿Los flujos alternativos son claros y completos?

13 ¿La descripción está bien definida y es consistente con la secuencia normal?

14 ¿El caso de uso tiene una representación gráfica y consistente con la descripción?

15 ¿El caso de uso indica los actores que intervienen y describe cada una de sus actividades?

16 ¿Indica el estado en que debe quedar el caso de uso al ser finalizado?

17 ¿Tiene una secuencia normal, donde describe paso a paso la ejecución del caso de uso del proyecto?

18 ¿Se encuentran definidas las relaciones entre los casos de uso del negocio? (include, extend)

19 ¿El documento cumple con los estándares definidos para la presentación de casos de uso?

20 ¿Los casos de uso aparecen descritos con expresiones claras y concretas?

21 ¿En los casos de uso que se extienden es clara la funcionalidad adicional?

22 ¿En los casos de uso es permitido crear dos veces el mismo registro?

23 ¿En los casos de uso, es posible crear datos, sin la necesidad de utilizar un estándar?

24 ¿Existe al menos un requisito no funcional plasmado en el caso de uso?

25 ¿En el caso de uso de autenticación de usuarios, si la información digitada es incorrecta, el usuario puede volver a ingresar al sistema?

26 ¿Las relaciones del diagrama de clases son coherentes de acuerdo a la solución planteada?

27 ¿El diagrama de clases incluye todas las operaciones necesarias para dar solución al problema?

28 ¿La documentación del diagrama de clase detalla adecuadamente la función que van a cumplir los atributos?

29 ¿La autenticación se puede realizar después de ingresar a alguna funcionalidad específica del sistema?

30 ¿Es posible que un usuario tenga varios perfiles?

31 ¿Es necesario haber iniciado sesión para gestionar la información de los maestros?

32 ¿Es necesario utilizar la información generada en los maestros para la creación de una tabla transaccional?

33 ¿En el diagrama de secuencia se observan los métodos que llevaran las clases del sistema?

34 ¿El documento cumple con los estándares definidos para la presentación de diagramas de secuencia?

35 ¿Se definen claramente las validaciones a realizar en caso de eliminar un registro?

36 ¿El documento es coherente y da claridad de cómo se dará solución al problema planteado?

37 Con la solución descrita en el documento se cumplen todos los objetivos planteados

Anexo 3. Estándar Diseño de Interfaz de Usuario

INTRODUCCIÓN

El diseño de sistemas de información comprende varias actividades que van desde el diseño de

infraestructura hasta la interfaz de usuario. Para que el sistema tenga éxito, es importante contar

con un buen diseño de la interfaz de usuario.

Una interfaz difícil de utilizar (Problemas de usabilidad), provocará que los usuarios cometan

muchos errores, o los usuarios simplemente se rehusarán a utilizar el sistema del software sin

tomar en cuenta su funcionalidad. Si la información se presenta en forma confusa, los usuarios no

comprenderán el significado de la información.

La interfaz debe utilizar términos familiares para los usuarios y los objetos que el sistema

manipula, deben estar directamente relacionados con el entorno del usuario.

CARACTERÍSTICAS DE LAS INTERFACES GRÁFICAS DE USUARIO

CARACTERÍSTICA DESCRIPCIÓN

Ventanas Las ventanas múltiples permiten que se despliegue simultáneamente información diversa en la pantalla de usuario.

Iconos Los iconos representan diferentes tipos de información. En algunos sistemas, los iconos representan archivos; en otros, procesos

Menús Los comandos se seleccionan de un menú en lugar de teclearse en un lenguaje de órdenes.

Apuntador Para seleccionar opciones de un menú o para indicar elementos de interés en una ventana, se utiliza el mouse.

Gráficos Los elementos gráficos se pueden mezclar con texto en el mismo despliegue.

Fuente. Ingeniería de Software. Ian Somerville[1]

INTERACCIÓN DEL USUARIO

Para realizar la interfaz de usuario, el diseñador se debe hacer dos preguntas:

- Cómo se introducirá la información del usuario en el software?

- Cómo se presentará al usuario la información requerida?

Una interfaz de usuario debe ser coherente debe integrar la interacción del usuario y la

presentación de la información.

ESTILO DE INTERACCIÓN PRINCIPALES VENTAJAS EJEMPLO DE APLICACIÓN

Manipulación Directa Interacción rápida e intuitiva.

Fácil de aprender.

Videojuegos.

Selección de Menús Evita errores del usuario. Se requiere digitar un

poco.

Muchos software de propósito general.

Llenado de Formularios Introducción de datos sencilla.

Fácil de aprender.

Control de almacén. Procesamiento de préstamos en una biblioteca.

Lenguaje de Comandos Flexible Sistemas bibliotecarios de recuperación de la información.

Lenguaje Natural Accesible a usuarios casuales.

Fácil de ampliar.

Sistemas para el manejo de horarios. Sistemas www de recuperación de información.

Fuente. Ingeniería de Software. Ian Somerville

DISEÑO DE LA INTERFAZ GRÁFICA

El diseño de la interfaz que se describe toma como referencia el estándar propuesto por Sun

Microsystems en el libro “Look and Feel Design Guidelines” [2]

TAMAÑO Y COLOR DE LA LETRA

Usted puede usar temas para redefinir tipos de letra tipo de letra, tamaños y estilos en su

aplicación. Por defecto en cuanto a la apariencia de Java define cuatro categorías de fuentes, "de

tipo estilos ":

La fuente de control,

la fuente del sistema,

la fuente del usuario y

el tipo de letra pequeña.

El tamaño de la fuente es una consideración importante para los usuarios con limitaciones

visuales.

La tabla 1, muestra los estilos definidos por defecto en java, para la apariencia de los

componentes.

Tabla 1. Estilos por defecto definidos para Java

Tipo de Estilo Defecto Uso

Control 12 puntos - negrilla Botones, casillas de verificación, títulos de menús, etiquetas y títulos de la ventana.

Pequeño 10 puntos - normal Atajos de teclado en los menús y la información sobre herramientas (tool tips).

Sistema 12 puntos - normal Árbol de componentes (Mapa navegacional) y la información sobre herramientas (tool tips)

Usuario 12 puntos normal Campos de texto y tablas Fuente. “Look and Feel Design Guidelines”

Para el proyecto que vamos a desarrollar, se debe tener en cuenta lo siguiente:

El tipo de letra a usar en los textos y etiquetas debe ser Arial con un tamaño de 12 o 11

puntos.

Se recomienda no aplicar formato cursivo o subrayado.

En cuanto al uso del color en la letra debe ser negro, sobre un fondo claro.

El uso del color es un aspecto importante, ya que suministra estéticamente un esquema agradable y confortable al usuario.

Los colores debe ser negro sobre un fondo blanco o gris. Solo debe utilizar una fuente de

color para un propósito especial, considere negrita para hacerla más fácil de leer y una

fuente de color rojo debe ser usada para identificar los campos requeridos.

VENTANAS

Una ventana es un área visual, normalmente de forma rectangular, su tamaño varía dependiendo

de los estándares del lenguaje de programación; contiene algún tipo de interfaz de usuario,

mostrando la entrada de datos y la salida, para uno o varios procesos que se ejecutan

simultáneamente.

Las ventanas se asocian a Interfaces Gráficas de Usuario (GUI), donde pueden ser manipuladas con

un puntero (mouse). La idea fue desarrollada en Xerox PARC.

Siempre se deben mantener los usuarios enfocados en una sola ventana, si es requerido para la

ejecución de un proceso la apertura de varias ventanas debe hacer la apertura de estas en forma

de cascada, tal como se muestra en la siguiente imagen.

NOMBRE DE LA VENTANA

Cada Ventana debe tener un nombre único descriptivo, alineado siempre a la izquierda, debe ser

en letra blanca sobre fondo azul; como lo indica la figura 1 y 2.

Figura 1. Contenido básico de una Ventana

Título de la ventana

Contenido de

la ventana

Icono Controles

CARACTERÍSTICAS DE UNA VENTANA PRINCIPAL

Las ventanas principales son contenedores de nivel superior para los elementos de la interfaz de

usuario. Una ventana principal podría celebrar una serie de contenidos integrados de fácil uso.

Por ejemplo, una ventana principal de su aplicación podría tener esta organización:

• El marco de la ventana: Contiene una barra de menú y un panel.

• La barra de menús: Contiene menús.

• El panel: Contiene una barra de herramientas y/o un panel de desplazamiento y/o barra de

desplazamiento.

• La barra de herramientas: Contiene botones de la barra.

• El panel de desplazamiento: Contiene un panel del editor con un plug-in kit de editor de texto

con estilo.

Figura 2. Componentes de una ventana principal

Fuente. “Look and Feel Design Guidelines”

Tenga en cuenta la aparición de los contenedores incrustados en una ventana principal y su

relación con la estructura subyacente, como se muestra en la Figura 3.

Figura 3. Partes de una ventana principal


TAMAÑO ESTÁNDAR DE LA VENTANA

El tamaño de la ventana varía dependiendo del contenido de la misma. Se debe tener en cuenta

que botones se deben colocar en fila horizontal y su tamaño, debe ser el necesario para que se

vean estéticamente con el contenido de la interfaz. Se recomienda como mínimo 800 x 600. Así

como lo indica la figura 4

Tenga en cuenta que no aplican éstas dimensiones en el acceso al sistema.

Figura 4. Tamaño de la ventana

SIMBOLOS

Los símbolos incluyen cualquier gráfico (normalmente de 48 x 48 píxeles o inferior) que representa

un estado o un concepto, pero no tiene asociado directamente la acción o el objeto. Los símbolos

pueden aparecer dentro de los cuadros de diálogo, cajas de estado del sistema de alerta, y

registros de eventos.

Los ejemplos en la figura 5, muestran los gráficos de un cuadro de Información de alerta

y una caja de preguntas de alerta y un símbolo de precaución superpuesto a un icono de carpeta

para indicar un estado hipotético.

Botones

Width 800

Height 600

Figura 5. Símbolos


El símbolo de pregunta se utiliza en un cuadro de entrada de alerta, como se muestra en la figura

6.

Se debe garantizar el correcto contraste entre un símbolo de precaución o el icono y el

contexto.

Figura 6. Ejemplo símbolo de Pregunta


Organización de la información dentro de una Ventana

La información debe ser ubicada en la ventana de tal forma que el usuario pueda alcanzar un

mejor desempeño en la ejecución de la tarea. La información más relevante debe estar ubicada en

la parte superior izquierda, y el flujo para el diligenciamiento debe ser de arriba hacia abajo o de

izquierda a derecha y los botones de acción de la forma deben estar ubicados en la parte inferior

de la ventana, así como se indica en el siguiente ejemplo:

INGRESO DE USUARIOS

BARRA DE MENÚ

La Barra de menú debe contener algo así en todas las ventanas del proyecto

EJEMPLOS DE ALGUNOS PROYECTOS DE SOFTWARE

Software bancario

Software contable

Software para compras y ventas

SOFTWARE PARA AEROPUERTOS

Software que se utiliza para la carga y centrado de aviones comerciales

SOFTWARE EDUCATIVO PARA NIÑOS

SOFTWARE PARA HISTORIAS CLÍNICAS (Datos Básicos e Historias Clínicas)

CUADROS DE MENSAJES

LECTURA COMPLEMENTARIA

Es necesario adelantarse a los errores que el usuario puede cometer en el uso de una interfaz,

desgraciadamente en muchos sitios no se utilizan las tecnologías adecuadas, ni se hace una

definición adecuada de las diferentes tipologías de errores a las que un usuario puede enfrentarse.

Una de las mayores frustraciones que un usuario puede llegar a tener en el uso de una interfaz, es

que ésta, no esté correctamente preparada para tolerar los errores más comunes que un usuario

pueda cometer en diferentes escenarios. No hay más que darse una vuelta por Internet y ver las

diferentes respuestas que dan algunos sistemas ante diferentes situaciones en las que un usuario

comete un error de forma involuntaria, o peor aún, provocado por una deficiente definición.

Una correcta gestión de los errores no suele ser una de las grandes prioridades en el desarrollo de

un producto, ya que en la mayoría de las ocasiones se da prioridad a otros conceptos, relegando a

los errores a posiciones de menor importancia.

Entonces, son los equipos de desarrollo los que definen los posibles errores y los mensajes que

obtiene el usuario. GRAN ERROR. Este trabajo es tarea del Consultor de Definición (o Analista) y

del Diseñador de Interacción. Los desarrolladores deben desarrollar en base a las especificaciones

dadas por ellos.

Algunas guías básicas a tener en cuenta y que pueden ayudar a prevenir y gestionar los errores de

forma adecuada:

1. Tipificar los errores o mensajes creando grupos lógicos:

Si identificamos varios tipos errores o mensajes que pueden considerarse similares, tipificarlos o

agruparlos es una buena manera de dar consistencia y orientar al usuario cuando éstos se

producen.

2. Prevenir el error antes de que se produzca:

Identificar todas aquellas situaciones en las que un usuario podría cometer un error y adecuar el

diseño para que éste no se produzca.

3. Crear ayudas contextuales:

Donde no sea posible prevenir un error, debe existir una ayuda o instrucción contextual que aclare

cómo se ha de realizar la acción.

4. Contextualizar el mensaje de error:

Los mensajes de error, cuando se produzcan, deben ser sensibles al contexto en el que el usuario

se encuentre en ese momento, huyendo de mensajes genéricos. Cuanto más concreto, mejor.

5. Redactar el mensaje de error de forma adecuada:

Utilizar un lenguaje directo, cercano y comprensible, huyendo de los mensajes abstractos o

técnicos, como por ejemplo “Error 42845: no se ha encontrado el usuario.”

6. Ofrecer alternativas cuando el error se produce:

Si el error llega a producirse no hay que limitarse a dar un buen mensaje de error contextualizado,

sino que también hay que ofrecer alternativas funcionales al usuario para que continúe en su tarea

y encuentre lo que busca.

7. Tolerancia de los motores de búsqueda a los errores tipográficos:

Uno de los errores más frecuentes es que el usuario cometa un error involuntario al escribir una

cadena de búsqueda. El sistema debería contar con la tecnología adecuada para tolerar estos

errores cometidos por el usuario de forma involuntaria y sugerir las alternativas más probables.

Anexo 4. Estándar para Codificar

ESTÁNDARES DE CODIFICACIÓN EN JAVA PARA EL PPI

Se definen estándares de codificación porque un estilo de programación homogéneo en un proyecto permite que todos los participantes lo puedan entender en menos tiempo y que el código en consecuencia sea mantenible. Puede ser que el estándar de documentación definido no sea perfecto para todas las situaciones. Si esto es así y cree que debe salirse de la norma: Documente los motivos.

1. Nombres de ficheros

Sufijos de ficheros en Java1: Código fuente: .java Código compilado: .class

Nombres de ficheros comunes: README: Resumen de información importante relativa al directorio

en el que está ubicado

2. Organización de ficheros

1 Según las convenciones de codificación de SUN

La correcta gestión de estos errores es una de las claves para que los usuarios utilicen un sistema de forma eficiente y no abandonen una tarea por no tener alternativas o ayudas que le faciliten conseguir su objetivo.

Un fichero consta de secciones separadas por líneas en blanco y líneas de comentario, ningún fichero debe tener más de 2000 líneas de código.

2.1 Ficheros de código fuente

Cada fichero contiene una única clase o interface. Si hay una clase privada o una interfaz asociadas a una clase pública se puede poner en el mismo fichero. La clase pública debe ser la primera. Ordenación de las secciones en un fichero de código fuente

Estas secciones deben ir separadas por una línea en blanco

Sentencia: package xxx.yyy; Sentencias de importación. Ej: import java.util.ArrayList;. No hay

líneas en blanco entre ellas Código de la clase. Va precedido por comentarios tipo javadoc con la

siguiente información: Prólogo explicativo de la clase (opcional),autor, versión, referencias

a otros elementos de código si se considera que debe haberlas.

3 Sangría

Las sangrías son importantes para la organización del código. Se establecen en bloques de sentencias.

1.3. Líneas largas Cuando una línea no quepa en una única línea se debe fraccionar atendiendo a estos principios generales:

Fraccionar después de una coma Fraccionar después de un operador Es mejor romper unidades de alto nivel que de bajo nivel.

Ejemplo:

longName1 = longName2 * (longName3 + longName4 - longName5) + 4 * longname6; //Correcto longName1 = longName2 * (longName3 + longName4 - longName5) + 4 * longname6; // Incorrecto

Si las reglas anteriores producen código confuso utilizar la sangría de 8 caracteres.

Ejemplo:

// Incorrecto if ((condition1 && condition2)

|| (condition3 && condition4) ||!(condition5 && condition6)) { doSomethingAboutIt(); // SE CONFUNDE CON LAS ANTERIORES

} // Usar esta sangría if ((condition1 && condition2)

|| (condition3 && condition4) ||!(condition5 && condition6)) {

doSomethingAboutIt(); } // Otra alternative correcta if ((condition1 && condition2) || (condition3 && condition4)

||!(condition5 && condition6)) { doSomethingAboutIt();

}

4 Comentarios

Normas generales a seguir en toda documentación:

1. Los comentarios deben añadir claridad al código. Deben contar el por qué y no el cómo. 2. Deben ser concisos. 3. Idealmente hay que escribir la documentación antes que el código.

Hay dos tipos de comentarios:

Comentarios de implementación Comentarios de documentación.

a. Comentarios de implementación: son del tipo: // ... o /* ... */. Describen el código. b. Comentarios de documentación: son del tipo: /** ... */. Describen una visión de más alto nivel para gente que no tiene el código a mano y que sólo quiere usarlo. La información de los comentarios no debe ser evidente, deben ser cosas que no están contenidas en el código. Los comentarios no deben estar en cajas dibujadas con asteriscos o similar ni deben incluir caracteres extraños.

4.1. Comentarios de implementación

Comentarios de bloque: Al comienzo de cada fichero o bloque. No se usan en este proyecto Comentarios de línea: Son comentarios explicativos de una parte pequeña del código. Sintaxis: // ... o /* ... */

4.2. Comentarios de documentación Son los comentarios destinados a ser procesados por javadoc. Se puede ver información adicional sobre javadoc en:

http://java.sun.com/products/jdk/javadoc/writingdoccomments.html

http://java.sun.com/products/jdk/javadoc/

IMPORTANTE

No se pueden usar comentarios de documentación para bloques de código dentro de métodos, porque javadoc los asigna a la primera declaración que encuentre detrás de ellos.

La sangría correcta según SUN es:

/** * Comentario sobre la clase A */ public class A { ... }

Otras normas son:

No se documentará lo que sea evidente Siempre se usarán los tags de javadoc para documentar los parámetros y valores

de retorno, aunque sólo sea para poner su nombre.

http://java.sun.com/products/jdk/javadoc/writingdoccomments.html

http://java.sun.com/products/jdk/javadoc/

5. Declaraciones

5.1. Número de declaraciones por línea

Se debe declarar cada variable en una línea distinta, de esta forma cada variable se puede comentar por separado. Ejemplo:

int level, size; // Incorrecto int level; // Correcto int size; // Size of table

Los arrays se deben declarar de este modo: double[ ] table; // Correcto double [ ]table; // Incorrecto

5.2. Inicialización

Inicializar cada variable en su declaración a menos que su valor inicial dependa de algún cálculo.

5.3. Localización En el comienzo de los bloques. La única excepción es el bucle for. No se deben declarar variables con el mismo nombre que otras en un método.

5.4. Declaraciones de clases e interfaces Se siguen estas reglas:

No hay espacio entre el nombre del método, el paréntesis y la lista de parámetros. Se abre la llave { al final de la misma línea que la declaración. La llave de } debe aparecer en línea aparte con la misma sangría que el método o

clase que cierra.

6. Sentencias

6.1. Sentencias simples Cada línea debe contener una sola sentencia. Ejemplos:

argv++; // Correcto

argc++; // Correcto argv++; argc++; // incorrecto

6.2. Sentencias compuestas Son las que están entre llaves { y }

Deben estar con sangría a un nivel superior que el precedente.

Todas las sentencias del tipo if o for, while, do ... while deberán tener llaves aunque sólo contengan una sentencia, de esta forma se evita la introducción accidental de errores si se añaden posteriormente sentencias.

6.3. Ejemplos: Sentencias if, for, while, do ... while, switch y try... catch Sentencia if

if (condition) { statements; } if (condition) { statements; } else { statements; } If ( condition) { statements; } else if (condition) { statements; } else { statements; }

Sentencia for y su nueva versión

for ( initialization; condition; update) { statements; } for ( initialization; condition; update);

La nueva versión del for tiene el siguiente formato

for (Declaration : List) { statements; } Ejemplo. Antes:

void cancelAl l(Collection c) {

for (Iterator i = c.iterator(); i.hasNext(); ) { TimerTask tt = (TimerTask) i.next(); tt.cancel();

} } Después: Void cancelAll (Collection c) {

for (Object o : c) { ((TimerTask)o).cancel();

} }

Sentencia while: while (condition) {

statements; } while (condition);

Sentencia do-while:

do { statements;

} while ( condition);

La sentencia switch tiene este formato y con sangría

switch ( condition) { case ABC:

statements; /* El comentario también con sangría */

case DEF: statements; break;

case XYZ: statements; break;

default: statements; break;

} La sentencia try ... catch

try { statements;

} catch (ExceptionClass e) { statements;

}

Si está seguida por finally:

try { statements;

} catch (ExceptionClass e) { statements;

} finally { statements;

}

6.4. Sentencias de retorno No se pondrá la expresión de retorno entre paréntesis a menos que con ello dé mayor claridad.

7. Espacio en blanco 7.1. Líneas en blanco Se deben usar dos líneas en blanco entre:

Diferentes secciones de un fichero de código fuente Entre clases y definiciones de interfaz

Se debe usar una línea en blanco:

Métodos Variables locales de un método y la primera sentencia Antes de un bloque o un comentario de línea (para que se sepa de un vistazo

que es lo que comenta) Entre diferentes secciones lógicas dentro de un fichero (más legibilidad)

7.2. Caracteres de espacio Se deben usar en las siguientes circunstancias:

Entre un paréntesis cerrado y una llave. Después de una coma en la lista de parámetros de un método. Entre operadores binarios: +, -, =, etc. Nunca entre un operador uno-ario y su

operando. La sentencia for y su paréntesis. Ejemplo: for (expr1, expr2, expr3); Casts. Ejemplo: myMethod((int) (cp 5), ((int) (i + 3)) + 1);+

8. Asignación de nombres

Esta es la sección más importante. Las normas genéricas son: 1. Se usan descriptores en inglés que dejan claro el cometido de la variable, método o clase. 2. Se usa terminología aplicable al dominio. 3. Si se usan abreviaturas hay que mantener en algún sitio una lista de lo que significan. 4. Evitar en lo posible los nombres largos (menos de 15 letras sería lo ideal) 5. Evitar nombres que difieran en una letra o en el uso de mayúsculas. 6. Un nombre no debería constar de más de dos palabras. 7. No usar siglas en los nombres a menos que queden muy largos o sean siglas conocidas por todos. Cada tipo de elemento debe nombrarse con una serie de reglas determinadas.

Paquetes: Todo en minúsculas. Cada palabra es más específica que la anterior. Clases e interfaces: Nombres. La inicial en mayúscula. Métodos: Deben ser verbos. La primera letra de la primera palabra en minúsculas,

el resto de las palabras empiezan por mayúsculas. Variables: Deben comenzar por minúscula. No se utilizará en ningún caso el

carácter "_" Constantes: Todo en mayúscula. Si son varias palabras, unidas por el carácter "_"

NOTA.

La adopción de un estándar de codificación, sólo es viable si se sigue desde el principio hasta el final del proyecto de software.

Anexo 5. Estándar Manual de Usuario

Debe explicarle al usuario como instalar el Software abc. Se recomienda hacer pantallazos de

cada paso para una clara explicación, así como lo indica el ejemplo:

1. Haga doble clic en el icono del escritorio perteneciente al Software abc versión 1.0 2. Si la base de datos se encuentra totalmente vacía sin ingresar usuarios le aparece la siguiente

pantalla la cual le permite ingresar los datos del administrador del Software abc

ABC Versión 1.0

3. Cuando inicie el Software abc se le pedirá su nombre de Usuario y contraseña

correspondiente como aparece en la pantalla:

Después de digitar los datos respectivos puede elegir la opción Aceptar para entrar al Menú Principal, o presionar la opción Cerrar para salir del sistema.

USO DE MENUS Una vez este dentro del Menú Principal puede navegar a través de la Barra de Menús, situada en la parte superior de la ventana de la aplicación, como se muestra en la pantalla:

Haga clic en el nombre del menú y elemento que desea utilizar o presione las teclas Alt + la letra que aparece en el nombre del elemento y a continuación presione la tecla Enter.

NOTA. Debe explicar el contenido de la barra de menú indicando que hace cada submenú; para mayor claridad

se recomienda explicar las funcionalidades del sistema en cada pantalla.

Reportes

Dentro de la Barra de Menús la pestaña Reportes genera una ventana en la cual debe seleccionar la identificación del usuario y la fecha de la cual desea realizar el reporte y luego de clic en el botón Mirar.

NOTA: Debe explicar cada reporte que emita el software.

Ayuda

El menú Ayuda es el que aparece al final de la Barra de Menús. Cuando se selecciona el menú en la barra aparecerán los elementos funcionamiento del sistema, características del sistema y Acerca de, en el cual aparecerá el Soporte Técnico del SISTEMA MEDITUR Versión 1.0. y El nombre de sus desarrolladores.

REFERENCIAS BIBLIOGRAFÍCAS

- ÁRIAS Callejas Manuel. Estándares de Codificación. 2009

- Deitel y Deitel. Java Como Programar. Prentice Hall 5ta Edición. 2004

- http://www.dosmilmastres.com/blog/revisiones-de-cdigo-y-estndares-de-codificacin/

- http://www.eetimes.com/design/embedded/4008320/The-best-coding-standards-eliminate-bugs

- http://fido.palermo.edu/servicios_dyc/encuentro2007/02_auspicios_publicaciones/actas_diseno/artic

ulos_pdf/A6029.pdf

- [1] Ingeniería de Software. Ian Somerville

- [2] “Look and Feel Design Guidelines” (2nd Edition) de Addison-Wesley - Sun Microsystems Inc.

(Editor)

http://www.dosmilmastres.com/blog/revisiones-de-cdigo-y-estndares-de-codificacin/

http://www.eetimes.com/design/embedded/4008320/The-best-coding-standards-eliminate-bugs

http://fido.palermo.edu/servicios_dyc/encuentro2007/02_auspicios_publicaciones/actas_diseno/articulos_pdf/A6029.pdf

http://fido.palermo.edu/servicios_dyc/encuentro2007/02_auspicios_publicaciones/actas_diseno/articulos_pdf/A6029.pdf

Documents

Manual Ppi Entregables v1.1