Equipo: 3

Capitulo 6: Diseo y gestin y pruebasEquipo: 3Integrantes: Briseo lvarez Gabriel Alejandro.Mestas Estrada Uriel.Mendoza Martnez Cristhian.Martnez Elizalde Carlos Bryan.Uno de los problemas ms difciles de resolver en el mundo del desarrollo de SW, ha sido la logstica.- Entregar en el tiempo acordado el sistema funcionando en el lugar prestablecido.

Problemas!!!

Asumimos que el sistema desarrollado fue revisado y por ende probado y que estamos frente al diseo detallado de cada caso de uso.Muchas veces en la fase de revisin, el producto a revisar es tan importante como otros que no se revisanEntonces...

Proceso de diseo

Qu revisamos?Cmo seleccionamos el producto a revisa?Se requiere de un criterio de seleccin que nos permita:Revisar las partes criticas.Como tambin las partes con potenciales falencias (engao/error).

Cada desarrollador usa y modifica el cdigo escrito por otro desarrollador para su posterior integracin. Esta es una de las fuentes con muchos errores y por consiguiente de difcil solucin. Y cuando el cdigo esta integrado se prueba para probar su funcionalidad, comprobar errores y corregirlos.Por ello es necesario una forma de trabajo que facilite y acelere este proceso.Coordinacin de la construccin

La mayora de proyectos son comprobados por empresas dedicadas al testing, sin embargo los responsables de estos proyectos piensan que el proyecto tendr una mejora en su calidad, desafortunadamente en la mayora de los casos slo les cobran por decirles el numero de errores que aun tiene el proyecto.Pruebas

Pruebas de software.

Como ya sabemos, se aconseja encontrar los errores cuanto antes para corregirlos.Estas son algunas de las razones para cambiar la forma de trabajo con las pruebas:

El proceso de prueba manual es propenso a errores adems de largo.Liberar a las personas haciendo cosas creativas.Trabajar en un ambiente de confianza.Utilizar mejor los recursos a partir de menor costo.Desarrollar un criterio de diseo basado en las pruebas.

Forma de trabajo tradicional:

Forma de trabajo propuesta con las pruebas automatizadas y formando parte del criterio de diseo.

Por lo mencionado necesitamos:*Automatizar las pruebas.*Desarrollar un criterio de diseo basado en las pruebas.En la siguiente imagen se muestra la automatizacin de las pruebas para contar con una realimentacin temprana y con alta frecuencia se muestra un servidor de integracin continua.

Ambiente de desarrollo con pruebas automatizadas.Sitio centralizado donde se almacena y mantiene informacin digital, habitualmente bases de datos o archivos informticos.En el libro Berczuk menciona ciertos patrones que si los lleva a cabo, contar con un repositorio estable y consistente. Adems de ser el punto de acceso al cdigo compartido que evita inconsistencias varias. Adems realiza el trabajo con el cdigo compartido desde inicio hasta dia a dia, facilitando la integracin de diferentes partes INTEGRACIN CONTINUA.Trabajo con el repositorioCreados para poder conseguir las siguientes pautas:

Mejorar la calidad del softwareReducir riesgosTests de facil ejecucionTests con poco mantenimiento y en el lenguaje que los desarrolladores programen el sistema Tests Sistematicos y AutomaticosEn todo proyecto no encontramos con ciertos obstculos que hacen regularmente que disminuya la calidad del software as como aumentar los tiempos de entrega, algunos de los mas comunes llegan a ser:

Actitud de los programadoresLa inversin inicial (capacitacin)Cdigo en constante cambioCmo adoptar la nueva forma de trabajoTambin encontramos al conflicto de desconocer que es lo que ayuda o afecta al desarrollo de software de calidad, principalmente se deben automatizar pruebas unitarias, de componentes, con y sin interfaz de usuario.Mientras tanto no se puede intervenir con tareas que suelen ser fciles de manera manual pero lo contrario si se automatizan,

Cuales son los elementos que debemos automatizar y cuales no?Como se dijo antes comenzar por la capacitacin de los analistas, testers y programadores.*Seleccionar un modo de trabajo.*Eleccin de herramientas*Desarrollo de proyectos piloto.*Institucionalizar.Estrategia de automatizacin Una de las soluciones para mejorar la calidad del software es tomar en cuenta los tests como un criterio que permite evaluar el desarrollo conforme se est realizando.

Una forma de mostrar los resultados es mediante un sitio donde encuentren informacin valiosa para realizar su trabajo de manera adecuada; debe mantenerse actualizada para cumplir con el objetivo de actualidad de la informacin deseable.Integracin continuaSe realizan por especialistas externos para tener una opinin mas certera y menos conformista de los errores cometidos.Dichas revisiones son profundas pero sobre todo rigurosas para que cumplan con el objetivo que tienen planteado.

Revisiones de diseo y cdigoPermitir detectar problemas durante el ciclo de vida del sistema.Definir criterios para su resolucin.Verificar que se resolvieron de manera adecuada.Objetivos de revisinGenerar datos sobre el producto, proceso de desarrollo, interaccin del grupo.

Aumenta la validacin y verificacin de requerimientos principalmente.

Permite acuar el concepto de calidad del software.BeneficiosClaro que no ambas ayudan a la temprana deteccin de errores, pero las revisiones formales nos permiten visualizar si los requerimientos son los adecuados, se presenta en una junta, se debe registrar entre otras cosas.

Mientras que las informales no necesitan de la presencia de todo el equipo de trabajo, las mtricas son opcionales adems de enfocarse a demostrar como el producto cubre los requerimientos.Revisiones formales e informales es lo mismo?Pues se debe tomar en cuenta la logstica pues no puede pasar de largo en el desarrollo del software pues suele influir en disminuir la calidad del mismo, por lo mismo nos aclara que el poner a prueba constantemente el cdigo y el proyecto ayuda a la deteccin pero sobre todo la correccin de errores para generar informes de resultados mas amables y con una expectativa mas amplia de la calidad de los productos que se realizan en este caso el software.Conclusiones