Cuaderno de Trabajo del Desarrollo de un Formulario con JSP

El siguiente es el cuaderno de trabajo que fue realizado en base al desarrollo de un programa en la forma de un formulario utilizando conexión a base de datos, JSPs y sesiones, el cual fue desarrollado a lo largo de aproximadamente un mes.

Tiempo estimado para la escritura de un libro

Utilizando como base el promedio del numero de pulsaciones por minuto que obtuve en la prueba de velocidad de curso meca y a lo largo de las lecciones, puedo establecer que mi promedio de pulsaciones por minutos es de aproximadamente 340.

Suponiendo que me de a la tarea de escribir un libro, en el sentido de sólo escribirlo no de crearlo, y si éste es de 100 cuartillas, se puede utilizar un calculo para llegar a un tiempo aproximado que tardaría en escribirlo.

Primero, una palabra en promedio tiene de 8 a 10 letras.

Segundo, un reglón suele estar compuesto de aproximadamente 10 palabras, dependiendo lógicamente del tamaño del reglón y de la letra.

Tercero, una cuartilla en promedio está compuesta de 22 a 25 reglones.

Utilizando para el cálculo los valores más altos, tendríamos palabras de 10 letras, reglones de 10 palabras y cuartillas de 25 reglones.

Si mi promedio de pulsaciones por minuto es de 340, entonces soy capaz de escribir 34 palabras por minuto, eso sería 3.4 reglones al minuto. Por lo tanto puedo escribir una cuartilla en aproximadamente 7.3 minutos.

Si soy capaz de escribir una cuartilla  en 7.3 minutos, entonces 100 cuartillas me tomaría aproximadamente 730 minutos, tiempo que traducido a horas serían aproximadamente 12.1 horas.

Con esto se puede concluir que en la escritura de un libro de 100 cuartillas, el tiempo aproximado que tardaría en hacerlo sería de 12 horas.

Desarrollo de un Programa de Altas en JSP

Código de HTML.

Código de JSP.

Base de datos creada en MYSQL.

 Vista de la página web.

Ejecución del JSP.

Programa desarrollado en 20 minutos.

Certificado de CursoMeca

Desarrollo de una clase

Desarrollo de una clase en Java.

Esta clase fue desarrollada en 7 minutos y 30 segundos

Calidad

MODELOS DE DESARROLLO DE SOFTWARE:

Modelo "CMMI"

CMMI significa "Capability Maturity Model Integration" o en español "Modelo de Integración de la Madurez y Capacidad" y es un modelo de desarrollo de software enfocado al proceso de los mismos, este modelo maneja 6 conceptos principales, los cuales son:

• Procesos: Se define como un método para producir algo, el cual toma en cuenta las Técnicas, los Materiales, las Herramientas y las Personas que intervienen en su ejecución.
• Área de Proceso: Son un conjunto de actividades agrupadas para facilitar el camino de la mejora y establecen la capacidad de proceso de la empresa.
• Capacidad: Es una cualidad que permite el buen desarrollo de una actividad y suele aplicarse a los procesos, con la relación de que a mayor capacidad de un proceso, más predecible será su resultado.
• Madurez: Puede definirse como el alcance de la plenitud y es algo que se adquiere con la experiencia al evolucionar los procesos para bien.
• Organización: Como bien su nombre lo dice, es la estructura de la empresa desarrolladora, que toma en cuenta a la empresa en sí, la Unidad de Negocio, el Centro de Trabajo y el Proyecto.
• Modelo: Es un esquema teórico de una situación real que se desarrolla para facilitar la comprensión y estudio de ésta

El CMMI es un modelo que enseña el camino para alcanzar un nivel de Madurez de la organización o un nivel de capacidad en un área de proceso, por lo tanto este modelo dice Qué es lo que se tiene que hacer, mas no el Cómo hacerlo.

La estructura del modelo CMMI se divide en 2 tipos, el escalonado y el continuo, cada uno de ellos dividiendose en 6 niveles:

Estructura Escalonada (Evaluación de Madurez):

Nivel 0: Proceso incompleto y no aplicable.

Nivel 1 (Inicial): Proceso impredecible, poco controlado y reactivo.

Nivel 2 (Gestionado): Proceso aplicable en proyectos y frecuentemente reactivo.

Nivel 3 (Definido): Proceso aplicable a toda la organización y que reacciona anticipadamente.

Nivel 4 (Gestionado cuantitativamente): El proceso es predecible y controlado cuantitativamente.

Nivel 5 (Optimización): Enfoque en la mejora del proceso.

Estructura Continua (Evaluación de Capacidad):

Nivel 0: Incompleto

Nivel 1: Realizado, proceso informal e impredecible.

Nivel 2: Gestionado, sistema de gestión de proyectos presente, comportamiento predecible.

Nivel 3: Definido, procesos de ingeniería y de gestión definidos e integrados

Nivel 4: Gestionado cuantitativamente, productos y procesos controlados cuantitativamente.

Nivel 5: En optimización, la mejora de procesos está institucionalizada.

Clasificación de Áreas de Proceso:

• Ingeniería.
• Gestión de Proyecto.
• Gestión de Proceso.
• Soporte.

Cada una de estas áreas tiene diferentes funciones dependiendo del nivel en el que se encuentren, además de que también se conforman de:

• Meta u Objetivo General
• Meta u Objetivo Específico

El objetivo general es el propósito principal del proyecto y los objetivos específicos son aquellos que al cumplirse llevan a la realización del objetivo general. Estos objetivos facilitan la institucionalización del proceso, es decir, cuando se sigue de una forma rutinaria como parte de la organización y para esto es necesario seguir los pasos de Compromiso, Habilidades, Implantación y Verificación.

Gestión de Proyecto: Cubren las actividades relacionadas con la planificación, seguimiento y control del proyecto. Está conformado por los siguientes apartados:

• Planificación de Proyectos.
• Seguimiento y Control de Proyectos.
• Gestión Integrada de Proyectos.
• Desarrollo de Equipos Integrado.
• Gestión de Riesgos.
• Gestión de Proyectos Cuantitativa.
• Gestión de Acuerdos con Proveedores.

Ingeniería: Da soporte a las actividades del ciclo de vida de desarrollo del producto. Está conformado por:

• Desarrollo de Requisitos.
• Gestión de Requisitos.
• Solución Técnica.
• Integración del Producto.
• Verificación.
• Validación.

Soporte: Proporciona los procesos esenciales para soportar el desarrollo y mantenimiento del producto, formado por:

• Medición y Análisis.
• Gestión de Configuración.
• Aseguramiento de Calidad de Proceso y Producto.
• Análisis y Resolución de Decisiones.
• Análisis y Resolución Causal.
• Entorno Organizativo para la Integración.

Gestión de Procesos: Contiene las prácticas relacionadas con la implementación de un programa de mejora de procesos, conformado por:

• Enfoque en el Proceso Organizativo.
• Definición del Proceso Organizativo.
• Formación Organizativa.
• Rendimiento del Proceso Organizativo.
• Innovación y Despliegue Organizativo.

Con la aplicación de todos estos aspectos del modelo CMMI, se espera un buen nivel de calidad en el desarrollo del software en aspectos como la organización, la productividad, el cumplimiento de requisitos, etc.

Modelo PSP/TSP:

El modelo conocido como PSP/TSP es uno que se encuentra dividido en dos partes, inicialmente se aplica el PSP (Personal Software Process) y posteriormente el TSP (Team Software Process).

El PSP es un proceso que como su nombre lo dice está diseñado a nivel personal, y que se aplica a tareas estructuradas

El objetivo de este proceso es:

• Planear y monitorear el trabajo.
• Administrar la calidad de los productos que se producen.
• Medir y mejorar el desempeño.

Todas estas acciones se realizan a un nivel personal, donde el individuo se toma a sí mismo como sujeto de estudio y lleva a cabo estas acciones, buscando su mejora y el desarrollo de disciplina.

Una vez que cada individuo lleva a cabo el PSP, se prosigue ahora con el TSP, el cual como su nombre indica, es un proceso de desarrollo para equipos basados en CMMI. El propósito de este modelo es obtener:

• Predecibilidad de costo y tiempo.
• Mejora de productividad y ciclos de desarrollo.
• Mejora de calidad de productos.

En suma lo que busca lograr este conjunto de procesos es la resolución de problemas de negocio, esto primero haciendo que cada individuo mejore su forma de trabajar y de analizar su desempeño para después juntarse con otros y trabajar en un equipo con el objetivo de cumplir con un desarrollo de manera eficaz y eficiente.

Proceso de Mejora Continua.

El llamado proceso de mejora continua proviene de la época de la segunda guerra mundial, más específicamente de japón, donde este término es conocido como "Kaizen", "Kai" que significa "Cambio" y "Zen" que significa "Bueno". Esto fue debido a que al término de la 2da guerra mundial la situación de Japón era muy difícil y crearon el llamado JUSE (Unión Japonesa de Científicos e Ingenieros) con el cual crearon metodologías para mejorar el proceso empresarial.

El proceso de mejora continua hace uso del llamado "Círculo de Deming", el cual está constituido por 4 pasos que forman un ciclo, haciendo que una vez es terminado el último, se vuelve a empezar el ciclo con el primer paso. Estos pasos son:

• Planear: Se establece una meta, se analiza un problema y se define el plan de acción.
• Hacer: Se ejecuta el plan de acción y se registra.
• Verificar: Se analiza el resultado obtenido.
• Actuar: Una vez se tienen los resultados, se decide si es necesaria alguna modificación para mejorar.

Cuando el círculo de Deming se aplica al proceso de mejora continua, lo que se obtiene es un ciclo en el que una empresa una vez que lleva a cabo un proyecto, es capaz de analizar los resultados que obtuvo de éste y ver si fueron favorables o no, una vez que se determina esto, se procede a discutir si se puede realizar alguna modificación a la forma en que se ejecutó el proyecto para mejorarlo y una vez hecho esto, se reinicia el ciclo con el mismo proyecto o uno nuevo, pero ya aplicando las modificaciones que se discutieron con anterioridad. De esta forma el ciclo provoca que continuamente se estén revisando y analizando los procesos que lleva a cabo el equipo o la empresa y así modificarlos constantemente en busca de un mejor desempeño, dando lugar así a la mejora continua.

Fuentes:

http://www.alconet.com.ar/ISO/menu.html

http://www.aec.es/c/document_library/get_file?p_l_id=32315&folderId=210056&name=DLFE-6053.pdf

http://www.kernel.com.mx/documentos/psp_tsp.pdf

http://www.manufacturainteligente.com/kaizen/

Factores Internos y Externos de la Calidad de Software

Cómo se ha visto anteriormente, la calidad de software es algo que depende de una serie de métricas cuyo propósito es evaluar si el software cumple con características particulares de cada métrica, esto con el objetivo de garantizar la calidad del mismo.

Algo que debe de tenerse en cuenta, es que una métrica como bien su nombre lo dice, es una medida de algo, sin embargo estas no se aplican al software directamente, sino que se aplican a través de los anteriormente mencionados "factores de calidad", estos pueden ser de tipo interno (la estructura de funcionamiento del software) o de tipo externo (lo que "ve" el usuario). Estos factores son los siguientes:

Exactitud:

Este es probablemente el factor más importante de calidad de un software, pues se refiere a la función que tiene el mismo y si la cumple o no, es decir que si por ejemplo la función de un software es comprimir archivos en un formato en particular, éste tendrá exactitud si cumple específicamente con eso que es su función o propósito, si este factor falla, fácilmente puede hacer que todos los demás factores se vuelvan completamente inútiles puesto que el software simple y sencillamente no cumpliría con su función o propósito.

Una formula o métrica para calcular la exactitud puede ser la siguiente:

Número de Requerimientos - Requerimientos Cumplidos

Con esta fórmula se evalúa cuántos de los requerimientos que se tienen para un software fueron cumplidos, si el resultado es cero, quiere decir que el nivel de exactitud es optimo, pues cumple con lo que se requiere de él y si el resultado es mayor de cero, en nivel de exactitud iría disminuyendo al no cumplir con todos sus requerimientos.

Robustez:

La robustez es el segundo factor más importante en la calidad de un software, esto es debido a que la robustez es la capacidad de un software de reaccionar a situaciones anormales.

Como podría esperarse, la exactitud se enfoca en que el software cumpla su función, sin embargo para que suceda esto el usuario debe de interactuar de manera correcta con éste, pero esto no siempre va a suceder así debido a los errores humanos, un ejemplo sencillo es una calculadora, una calculadora esperaría que el usuario introduzca operaciones matemáticas lógicas y que tengan sentido, normalmente esto provocaría que si el usuario intenta introducir una operación con errores matemáticos (por ejemplo una división entre cero) o de sintaxis, el software de la calculadora fallara y se estropeara debido a que se está enfrentando a una situación para la cual no fue diseñada. Sin embargo la robustez del software se encarga de esto al actuar como un "margen de error", haciendo que si el software se encuentra con situaciones anormales despliegue automáticamente un mensaje de error al usuario indicándole la situación en cuestión, registrando así esa situación anormal en el software y evitando que se estropee.

Una fórmula que podría utilizarse para medir la robustez de un software sería la siguiente:

Número de errores / Número de veces que reacciona bien

Esta formula nos dice que entre más veces el software reaccione de manera adecuada ante los errores que se presenten, el nivel de robustez es mayor, en este caso cuando el resultado sea lo más cercano posible a 1.

Eficiencia:

La eficiencia es una parte importante de la calidad de un software, y puede definirse como la cantidad de recursos utilizados por éste para cumplir con su función. Un programa puede cumplir con su función, pero esto no sería de mucha ayuda si para hacerlo necesita consumir una cantidad enorme de recursos de la computadora y además tarda en dar un resultado. Es debido a esto que la eficiencia de un software es importante, puesto que si el nivel es alto permite que cumpla su función de una manera rápida y sin consumir demasiados recursos. Normalmente esto se toma como un aspecto secundario dado que se le da una mayor prioridad a que sea eficaz, es decir que cumpla su función (exactitud) y es a causa de esto que constantemente uno podría por ejemplo encontrarse con programas cuyos requerimientos mínimos se cumplen o se sobrepasan, pero que a la hora de la ejecución, el desempeño es pobre y consume más recursos de los que aparentaba, provocando un desperdicio innecesario de recursos y de tiempo.

Una forma de medir la eficiencia de un software es la siguiente:

Resultados / Recursos

Con esta formula se da a entender que entre más resultados se puedan obtener con menos recursos, el nivel de eficiencia será mayor, es decir que el nivel de eficiencia aumenta cuando el resultado es mayor a 1 y disminuye cuando es menor a 1.

Funcionalidad:

La funcionalidad se refiere a la "simpleza" que tiene el software al momento que el usuario interactua con él, es decir a la capacidad del software de hacer que el usuario entienda como funciona y no se pierda. Normalmente para lograr esto, lo que se hace es "limitar" la extensión o cantidad de posibilidades que ofrece un software, esto es debido a que si las posibilidades son demasiadas el usuario corre riesgo de verse abrumado por tantas opciones y funciones, provocando que se pierda y no entienda bien cómo funciona el software, mientras que si las posibilidades son demasiado bajas se corre con el riesgo de que el software se vea muy limitado en sus capacidades y que no pueda cumplir con todas sus funciones de manera satisfactoria. Un ejemplo de esto puede ser facebook, el cual en sus constantes actualizaciones y cambios ha llegado a un punto donde ofrece tantas posibilidades a los usuarios que estos se ven abrumados por ellas y pierden la habilidad de manejar el sitio de manera fluida y sencilla.

Medir la funcionalidad es algo un tanto más complicado que los demás factores, debido a que en este se debe buscar un equilibrio y no irse a algún extremo, por lo que la fórmula podría ser la siguiente:

Número de funciones + Número de posibles errores

Con esta fórmula se da a entender que entre más funciones se tienen, mayor cantidad de errores o complicaciones pueden surgir, pero como debe mantenerse un equilibrio lo ideal es que el número de funciones sea únicamente el necesario para cumplir con los requerimientos.

Fácil de Usar:

Este es un factor que está estrechamente relacionado con el anterior (funcionalidad). Como bien su nombre lo dice, este factor se enfoca en que el software pueda ser tomando por cualquier usuario y éste pueda rápidamente entenderlo y utilizarlo, para lograr esto se deben de tomar en cuenta aspectos como la interfaz gráfica, tutoriales que expliquen el software, simplicidad del programa, etc. Sin embargo un detalle que se debe tener en cuenta es que no se debe de hacer que un software sea excesivamente fácil de utilizar debido a que esto provocaría que estuviera limitado en las posibilidades que ofrece, además de que si alguien con conocimientos avanzados utiliza un software así, rápidamente sentiría que es demasiado simple y limitado por lo que al igual que con la funcionalidad se debe de mantener un equilibrio en este apartado.

La forma de medir este factor puede ser la siguiente:

Nivel de conocimiento del usuario * Tiempo que tarda en entender el programa

Con esta fórmula se da a entender que entre menor sea el resultado, más fácil de usar es el programa, pero el detalle que debe de tenerse en cuenta es que entre mayor nivel de conocimiento tenga un usuario, menos tiempo tardará en entender el programa, por lo que deben también tomarse en cuenta a los usuarios con menor nivel de conocimiento.

Reutilización:

La reutilización puede definirse como la capacidad que tiene un software de utilizar sus elementos en la construcción de otro, esto es debido a que un software en sus partes más fundamentales, puede compartir estructuras con otros ya existentes y gracias a esto los ya existentes pueden ser utilizados en la construcción del nuevo, evitando así que se tenga que volver a desarrollar algo que ya se había hecho antes y permitiendo así acelerar el proceso de desarrollo del software.

Un ejemplo de la reutilización pueden ser las librerías de Java, dado que estas librerías son códigos hechos anteriormente que cumplen con alguna función en particular y que al utilizarlas en la construcción de un software se acelera el proceso al ya no tener que volver a programar una función que éste requiera.

La forma de medir la reutilización puede ser la siguiente:

Cantidad utilizada del software original / Tamaño original del software

Con esta fórmula se expresa que entre más se haya utilizado un software en la construcción de otro, su nivel de reutilización es mayor, en este caso cuando el resultado sea lo más cercano a 1.

Compatibilidad:

La compatibilidad de un software es su capacidad de poder interactuar correctamente con otros para cumplir alguna función determinada. Normalmente un mismo software va a ser utilizado en diferentes plataformas y va a tener que interactuar con diversos programas, la compatibilidad se encarga de garantizar que éste software pueda interactuar de manera correcta con todos ellos y que así pueda cumplir lo requerido, el ejemplo más sencillo de esto vendría siendo el sistema operativo que un programa de pide para poder instalarlo.

Una formula para medir la compatibilidad sería:

No. Sistemas capaces de comunicarse / No. de cambios requeridos para poder combinarse

Con esta fórmula se dice que entre menos cambios requiera un software para interactuar correctamente con otros, mayor es su nivel de compatibilidad.

Puntualidad:

Este factor no es estrictamente designado al software, sino a todo el proceso de su desarrollo, puesto que la puntualidad como bien su nombre lo indica es la capacidad de entregar el software en el tiempo requerido. Cuando un software se desarrolla, debe de cumplir con los requerimientos del cliente y uno de ellos suele ser una fecha de entrega del software, esta fecha indica el tiempo que se tiene para desarrollarlo y el nivel de puntualidad dependerá del cumplimiento de esta fecha de entrega.

Para medir la puntualidad se utiliza la siguiente fórmula:

Tiempo en el que se entregó - Tiempo indicado

Si el resultado es negativo, entonces el software fue entregado antes de la fecha límite, lo cual podría decirse que es bueno. Si el resultado es 0, el software fue entregado exactamente en el tiempo indicado, lo cual también es bueno, y si el resultado es positivo, el software fue entregado después de tiempo, lo cual es malo.