Ingeniería de Software: Y eso qué es?

Transcripción

1 Ingeniería de Software: Y eso qué es? Definición: Estrategia para desarrollar software de alta calidad. A qué se le denomina Software de alta calidad? Al software que sea: Util (al cliente). Portable. Que se pueda transferir de un entorno de operación a otro. Mantenible. Que soporte ajustes y adaptaciones con costos manejables. Confiable. Baja tasa de fallos. Tenga integridad. Resultados correctos con alto grado de exactitud. Eficiente. Que no consuma demasiados recursos. Consistencia de función. Accesible (al usuario). Buena ingeniería humana - Fácil de aprender y usar. 1

2 Ingeniería de Software: Y eso qué es? El intento de la Ingeniería de Software es proporcionar un marco de trabajo para construir Software de mayor calidad. Un proceso de software define el enfoque que se toma cuando el Software se trata con Ingeniería, pero la Ingeniería del Software también comprende las tecnologías que tiene el proceso (Métodos técnicos y herramientas automatizadas). La Ingeniería de Software es una TECNOLOGÍA conformada por: PROCESO + MÉTODOS: Técnicos y de Gestión. + HERRAMIENTAS Proporciona el marco de trabajo. + Ofrecen la guía de cómo construir técnicamente + Permiten automatización de procesos y métodos. 2

3 Ingeniería de Software: Y eso qué es? El trabajo que se asocia a la Ingeniería de Software puede dividirse en tres fases genéricas: DEFINICION DESARROLLO MANTENIMIENTO QUÉ CÓMO CAMBIOS Ingeniería de los sistemas. Diseño de Software. Asociados al manejo de errores. Existen cuatro tipos: Planificación del Proyecto de Software. Análisis de Requisitos. Generación de Código. Prueba del Software. Corrección: supresión de defectos. Adaptación: modificaciones del entorno original. Mejora: inclusión de funciones adicionales. Prevención: corregir, adaptar y mejorar más fácilmente el SW. 3

4 Estándares y modelos La Ingeniería del Software es una ingeniería muy joven que necesitaba: Definirse a sí misma: Cuáles son las áreas de conocimiento que la comprenden? Los estándares son útiles porque: Agrupan lo mejor y más apropiado de las buenas prácticas y usos del desarrollo de software. Agrupan buena parte de los conocimientos. SWEBOK: Software Engineering Body of knowledge Definir los procesos que intervienen en el desarrollo, mantenimiento y operación del software ISO/IEC 12207: Procesos del ciclo de vida del software De las mejores prácticas, extraer modelos de cómo ejecutar (y evaluar) esos procesos para evitar los problemas de la crisis del software CMM / CMMI ISO/IEC TR Definir estándares para establecer criterios unificadores en requisitos, pruebas, gestión de la configuración, etc. IEEE IEEE 1362 ISO Proporcionan un marco para implementar procedimientos de aseguramiento de la calidad. Proporcionan continuidad y entendimiento entre el trabajo de personas y organizaciones distintas. 4

5 CONCEPTO DE CICLO DE VIDA DEL SOFTWARE El ciclo de vida del software es una sucesión de estados o fases por los cuales pasa un software a lo largo de su "vida útil". El propósito es definir las distintas fases intermedias que se requieren para validar el desarrollo de la aplicación, es decir, para garantizar que el software cumpla los requisitos para la aplicación y verificación de los procedimientos de desarrollo: se asegura de que los métodos utilizados son apropiados. El esquema de ciclo de vida busca que los errores se detecten lo antes posible y por lo tanto, permite a todos los involucrados concentrarse en la calidad del software, en los plazos de implementación y en los costos asociados. El ciclo de vida básico de un software consta de los siguientes procedimientos (pueden ser secuenciados o simultáneos): 5

6 Definición de objetivos: definir el resultado del proyecto y su papel en la estrategia global. Análisis de los requisitos y su viabilidad: recopilar, examinar y formular los requisitos del cliente y examinar cualquier restricción que se pueda aplicar. Diseño general: requisitos generales de la arquitectura de la aplicación. Diseño en detalle: definición precisa de cada subconjunto de la aplicación. Programación: es la implementación de un lenguaje de programación para crear las funciones definidas durante la etapa de diseño. Prueba de unidad: prueba individual de cada subconjunto de la aplicación para garantizar que se implementaron de acuerdo con las especificaciones. 6

7 Integración: para garantizar que los diferentes módulos se integren con la aplicación. Éste es el propósito de la prueba de integración que está cuidadosamente documentada. Prueba beta (o validación): para garantizar que el software cumple con las especificaciones originales. Documentación: sirve para documentar información necesaria para los usuarios del software y para desarrollos futuros. Mantenimiento: para todos los procedimientos correctivos (mantenimiento correctivo) y las actualizaciones secundarias del software (mantenimiento continuo). El orden y la presencia de cada uno de estos procedimientos en el ciclo de vida de una aplicación dependen del tipo de modelo de ciclo de vida acordado entre el cliente y el equipo de desarrolladores. 7

8 MODELOS DE PROCESOS DE DESARROLLO DE SOFTWARE (ejemplares de modelos de ciclo de vida) 1. Modelo Lineal Secuencial (o de Cascada). Se compone de las siguientes etapas : Análisis de Requisitos. En esta etapa debe obtenerse la comprensión del dominio de la información del Software. Eso implica revisar la funcionalidad requerida, el comportamiento, el rendimiento y las condiciones de interconexión. Diseño. Se centra en cuatro atributos como son: Estructura de Datos, Arquitectura del Software, Representaciones de Interfaz, Detalles Procedimentales (Algoritmos). En esta etapa se traducen requisitos en una representación del Software donde se pueda evaluar su calidad antes de comenzar a codificar. Generación del Código. Pruebas. Verificación de sentencias internas y procesos externos para captar errores. Mantenimiento. Gestión de cambios después de entregado. Sin embargo este modelo falla porque: Rara vez se sigue el modelo a cabalidad. No se acomoda fácilmente ante cambios surgidos por deficiente recolección de requisitos. Presenta versiones de trabajo de los programas en estados muy avanzados, si un error grave no ha sido detectado, existe un alto riesgo de perder el trabajo realizado. 8

9 2. Modelo de construcción de prototipos. Tiene tres pasos: Escuchar al cliente. Recolección de requisitos. Se encuentran y definen los objetivos globales, se identifican los requisitos conocidos y las áreas donde es obligatorio más definición. Construir y revisar el prototipo. El cliente prueba el prototipo y lo utiliza para refinar los requisitos del software. Este modelo es útil cuando: El cliente no identifica los requisitos detallados. El responsable del desarrollo no está seguro de la eficiencia de un algoritmo, sistema operativo o de la interface hombre - máquina. Su principal desventaja es que una vez que el cliente ha dado su aprobación final al prototipo y cree que está a punto de recibir el proyecto final, se encuentra con que es necesario reescribir buena parte del prototipo para hacerlo funcional, porque lo más seguro es que el desarrollador haya hecho compromisos de implementación para hacer que el prototipo funcione rápidamente. Es posible que: el prototipo sea muy lento, muy grande, no muy amigable en su uso, o incluso, que esté escrito en un lenguaje de programación inadecuado. 9

10 3. Modelos Evolutivos. Tienen en cuenta que el software es susceptible de cambios con el paso del tiempo. Se basan en la idea de desarrollar una implementación inicial, exponiéndola a los comentarios del usuario y refinándola a través de las diferentes versiones hasta que se desarrolla un sistema adecuado. Las actividades de especificación, desarrollo y validación se entrelazan, en vez de separarse, con una rápida retroalimentación entre éstas. Para sistemas pequeños y medios (de hasta líneas de código), el enfoque evolutivo de desarrollo es el recomendado. Para sistemas grandes, se recomienda un proceso mixto que incorpore las mejores características del modelo en cascada y del desarrollo evolutivo Modelo Incremental. Combina repetición de elementos del Modelo Lineal Secuencial con la filosofía interactiva del Modelo de Construcción de Prototipos. En este modelo se entrega el software en partes pequeñas, pero utilizables llamadas Incrementos ; en general, cada incremento se construye sobre aquel que ya haya sido entregado. El primer incremento es fundamental, ya que sobre él se construirá el resto del producto. Este modelo es muy útil en situaciones en las que la fecha de entrega sea inmodificable. 10

11 3.2. Espiral. Boehm propuso un marco del proceso de software dirigido por el riesgo (el modelo en espiral): 11

12 Cada ciclo en la espiral representa una fase del proceso de software y se divide en cuatro sectores: 1. Establecimiento de objetivos. Se definen objetivos específicos para dicha fase del proyecto. Se identifican restricciones en el proceso y el producto, y se traza un plan de gestión detallado. Se identifican los riesgos del proyecto. 2. Valoración y reducción del riesgo. En cada uno de los riesgos identificados del proyecto, se realiza un análisis minucioso. Se dan acciones para reducir el riesgo. Por ejemplo, si existe un riesgo de que los requerimientos sean inadecuados, puede desarrollarse un sistema prototipo. 3. Desarrollo y validación. Después de una evaluación del riesgo, se elige un modelo de desarrollo para el sistema. Por ejemplo, la creación de prototipos desechables sería el mejor enfoque de desarrollo, si predominan los riesgos en la interfaz del usuario. 4. Planeación. El proyecto se revisa y se toma una decisión sobre si hay que continuar con otro ciclo de la espiral. Si se opta por continuar, se trazan los planes para la siguiente fase del proyecto FIN DEL DOCUMENTO 12