¿Por qué reutilizar en la industria de Software? Crisis del Software: Problema de construir sistemas de software confiables ya a gran escala de una manera controlada y dentro de una economía eficiente. Construir software en una forma eficiente, eficaz, económica. La Reusabilidad del software a sido considerada como solución a la crisis del software. Idea básica: Debido a que el software está típicamente compuesto por partes similares, la mayoría del software nuevo puede ser ensamblado a partir de componentes preexistentes.
El software de aplicación, es aquel que utilizamos día a día, cada uno de los programas, aplicaciones o utilidades que manejamos dentro de nuestra computadora, entran dentro de esta clasificación, es el resultado de la programación de software, enfocado hacia alguno de los sistemas operativos, como puedes ver es el tercer y último paso, hablando de forma técnica es el software diseñado para el usuario final.
Aplicaciones de Sistema de control y automatización industrial Aplicaciones ofimáticas Software educativo Software médico Software de Cálculo Numérico Software de Diseño Asistido (CAD) Software de Control Numérico (CAM)
Mantenibilidad Esta característica representa la capacidad del producto software para ser modificado efectiva y eficientemente, debido a necesidades evolutivas, correctivas o perfectivas. Esta característica se subdivide a su vez en las siguientes subcaracterísticas:
Modularidad. Capacidad de un sistema o programa de ordenador (compuesto de componentes discretos) que permite que un cambio en un componente tenga un impacto mínimo en los demás. Reusabilidad. Capacidad de un activo que permite que sea utilizado en más de un sistema software o en la construcción de otros activos. Analizabilidad. Facilidad con la que se puede evaluar el impacto de un determinado cambio sobre el resto del software, diagnosticar las deficiencias o causas de fallos en el software, o identificar las partes a modificar. Capacidad para ser modificado. Capacidad del producto que permite que sea modificado de forma efectiva y eficiente sin introducir defectos o degradar el desempeño. Capacidad para ser probado. Facilidad con la que se pueden establecer criterios de prueba para un sistema o componente y con la que se pueden llevar a cabo las pruebas para determinar si se cumplen dichos criterios.
Crisis del Software: Sucesos Los proyectos no terminaban en plazo Los proyectos no se ajustaban al presupuesto inicial. Baja calidad del software generado. Software que no cumplía las especificaciones. Código inmantenible que dificultaba la gestión y evolución del proyecto
Mitos delSoftware 6. Mitos del software Muchas de las causas de la crisis del software se pueden encontrar en una mitología que surge durante los primeros años del desarrollo del software Propagaron información errónea y confusión 7. Mitos del software
Mitos de gestión
Mitos del cliente
Mitos de los Desarrolladores
8. Mitos de Gestión Los gestores están normalmente bajo presión de hacer que no se retrase el proyecto y mejorar la calidad Mito: Tenemos ya un libro lleno de estándares y procedimientos para construir un software ¿No les proporciona a caso todo lo que necesitan saber? Realidad: La respuesta es no 9. Mitos de Gestion Mito: Añadir programadores repondrá tiempo perdido por desperfectos Realidad: El desarrollo del software no es un proceso mecánico como el de fabricación. Añadir gente a un proceso de software retrasa aun mas el proyecto. 10. Mitos del Cliente El cliente cree en los mitos, debido que los gestores y desarrolladores hacen poco para corregir la mala información. Mito: Una declaración de los objetivos es suficiente para desarrollar el sistema, y los detalles se pueden ver después Realidad: Una mala definición inicial es la principal causa de software con fallas. Debe de existir una buena comunicación entre el cliente y el analista 11. Mitos del Cliente Mito: Los requisitos del proyecto cambian continuamente, pero los cambios se acomodan fácilmente debido a que el software es flexible. Realidad: El impacto del cambio varia de acuerdo con el momento en que se introduce. Conforme pasa el tiempo, el impacto en el costo crece con rapidez. 12. Mitos de los Desarrolladores La programación desde sus inicios se veía como un arte. Las viejas formas tardan en morir. Mito: Una vez que se describió el programa y hacemos
que funcione, la labor ha terminado. Realidad: “En cuanto más pronto se empiece a escribir el código mas tiempo se tardara en terminarlo” Se ha comprobado que el trabajo completado se ha realizado aun después de que se le entrega por primera vez al cliente. 13. Mitos de los Desarrolladores Mito: Hasta que no se esté ejecutando el programa no hay manera de probar su calidad Realidad: Aplicando una revisión técnica formal (filtro de calidad del sistema) se pueden encontrar los aciertos o deficiencias del sistema