Este capítulo introduce la verificación y validación del software, discutiendo la diferencia entre ambos procesos. Explica que la verificación se refiere a crear el producto correctamente de acuerdo a las especificaciones, mientras que la validación se refiere a crear el producto correcto para satisfacer las necesidades del usuario. También describe los diferentes tipos de técnicas de verificación y validación, como inspecciones de software, análisis estático y pruebas, y explica la importancia de planificar cuidadosamente el proceso de verificación y valid
Este documento presenta una introducción al enfoque de desarrollo de software Extreme Programming (XP). Explica que XP es una metodología ágil que se basa en valores como la simplicidad, el feedback continuo y la comunicación entre el cliente y el equipo de desarrollo. Describe las principales fases y prácticas de XP, incluyendo historias de usuario, iteraciones cortas, desarrollo incremental y refactorización constante del código.
Cuadro comparativo entre moprosoft y cmmiJimmy Davila
Este documento compara Moprosoft y CMMI, dos modelos para la mejora de procesos de desarrollo de software. Moprosoft es un modelo mexicano con 9 procesos, mientras que CMMI es un marco internacional con 5 niveles de madurez. Ambos modelos buscan mejorar la calidad y productividad, aunque CMMI se enfoca más en la mejora continua. El documento también lista algunas empresas certificadas en cada modelo.
Fundamentos de la arquitectura de softwareRoger Villegas
Este documento presenta una breve historia de la arquitectura de software desde 1960 hasta la actualidad, destacando conceptos clave como estilos, lenguajes de descripción arquitectónica, marcos y vistas, procesos y metodologías, abstracción, escenarios, campos de investigación, arquitecturas comunes, modalidades y tendencias, y las diferencias entre arquitectura y diseño.
El método SAAM (Software Architecture Analysis Method) es un método para evaluar la modificabilidad y otros atributos de calidad de una arquitectura de software. El procedimiento de SAAM implica describir la arquitectura, desarrollar escenarios de cambio futuros, evaluar cómo la arquitectura soportaría esos cambios, y generar una evaluación global. El objetivo final es mejorar la comunicación, reusabilidad y evolución del sistema.
Siguiendo con los apuntes de Ingeniería de Software para la Ingeniería en Computación, de la Universidad Tecnologica de la Mixteca en Huajuapan de León, Oaxaca México.
The document discusses various aspects of software development including:
1. Software quality focuses on meeting customer requirements and expectations in terms of functionality, performance, cost and time to market.
2. Common software development process models include waterfall, prototype, spiral and agile models which are suited for different types of requirements.
3. Testing is a critical part of the development process and includes unit, integration, system and user acceptance testing. System testing involves testing functionality, usability, compatibility and other quality attributes.
Este documento describe varios métodos para estimar el esfuerzo, costo y tiempo de proyectos de desarrollo de software, incluyendo los modelos COCOMO I y COCOMO II, la técnica Delphi y estimación por puntos de función. También explica conceptos como entradas, salidas, consultas de datos y archivos lógicos internos, los cuales son elementos clave considerados en el conteo de puntos de función.
El documento presenta la norma ISO/IEC 9126 sobre la calidad del software, enfocándose en el atributo de mantenibilidad. Define la mantenibilidad como la facilidad para extender, modificar o corregir errores en un sistema de software. Explica los cinco subatributos de la mantenibilidad y cómo medirla, ya sea mediante métricas externas como el tiempo medio para reparar un error, o métricas internas como la cohesión y acoplamiento del código. Finalmente, discute cómo ciertos cambios pueden afectar neg
Este documento presenta una introducción al enfoque de desarrollo de software Extreme Programming (XP). Explica que XP es una metodología ágil que se basa en valores como la simplicidad, el feedback continuo y la comunicación entre el cliente y el equipo de desarrollo. Describe las principales fases y prácticas de XP, incluyendo historias de usuario, iteraciones cortas, desarrollo incremental y refactorización constante del código.
Cuadro comparativo entre moprosoft y cmmiJimmy Davila
Este documento compara Moprosoft y CMMI, dos modelos para la mejora de procesos de desarrollo de software. Moprosoft es un modelo mexicano con 9 procesos, mientras que CMMI es un marco internacional con 5 niveles de madurez. Ambos modelos buscan mejorar la calidad y productividad, aunque CMMI se enfoca más en la mejora continua. El documento también lista algunas empresas certificadas en cada modelo.
Fundamentos de la arquitectura de softwareRoger Villegas
Este documento presenta una breve historia de la arquitectura de software desde 1960 hasta la actualidad, destacando conceptos clave como estilos, lenguajes de descripción arquitectónica, marcos y vistas, procesos y metodologías, abstracción, escenarios, campos de investigación, arquitecturas comunes, modalidades y tendencias, y las diferencias entre arquitectura y diseño.
El método SAAM (Software Architecture Analysis Method) es un método para evaluar la modificabilidad y otros atributos de calidad de una arquitectura de software. El procedimiento de SAAM implica describir la arquitectura, desarrollar escenarios de cambio futuros, evaluar cómo la arquitectura soportaría esos cambios, y generar una evaluación global. El objetivo final es mejorar la comunicación, reusabilidad y evolución del sistema.
Siguiendo con los apuntes de Ingeniería de Software para la Ingeniería en Computación, de la Universidad Tecnologica de la Mixteca en Huajuapan de León, Oaxaca México.
The document discusses various aspects of software development including:
1. Software quality focuses on meeting customer requirements and expectations in terms of functionality, performance, cost and time to market.
2. Common software development process models include waterfall, prototype, spiral and agile models which are suited for different types of requirements.
3. Testing is a critical part of the development process and includes unit, integration, system and user acceptance testing. System testing involves testing functionality, usability, compatibility and other quality attributes.
Este documento describe varios métodos para estimar el esfuerzo, costo y tiempo de proyectos de desarrollo de software, incluyendo los modelos COCOMO I y COCOMO II, la técnica Delphi y estimación por puntos de función. También explica conceptos como entradas, salidas, consultas de datos y archivos lógicos internos, los cuales son elementos clave considerados en el conteo de puntos de función.
El documento presenta la norma ISO/IEC 9126 sobre la calidad del software, enfocándose en el atributo de mantenibilidad. Define la mantenibilidad como la facilidad para extender, modificar o corregir errores en un sistema de software. Explica los cinco subatributos de la mantenibilidad y cómo medirla, ya sea mediante métricas externas como el tiempo medio para reparar un error, o métricas internas como la cohesión y acoplamiento del código. Finalmente, discute cómo ciertos cambios pueden afectar neg
The document discusses software architecture and defines it as the fundamental organization of a system embodied by its components, their relationships, and design principles. It provides examples of common software architecture structures like modules and components, distribution, and multiple views. Common architectural patterns are also presented, including layers, client-server, master-slave, pipe-filter, and MVC, with examples to illustrate each pattern. The role of the software architect is discussed as well as why architecture is important for systems that are large-scale, distributed, and secure.
This document summarizes key topics from a lecture on security engineering:
1. It discusses security engineering and management, risk assessment, and designing systems for security. Application security focuses on design while infrastructure security is a management problem.
2. It outlines guidelines for secure system design including basing decisions on security policies, avoiding single points of failure, balancing security and usability, validating all inputs, and designing for deployment and recoverability.
3. It also covers risk management, assessing threats, and designing architectures with layered protection and distributed assets to minimize the effects of attacks.
Este documento describe los factores y características que determinan la calidad en el desarrollo de software según el modelo de McCall de 1977. Identifica once factores clave como corrección, fiabilidad, eficiencia e integridad. También explica cinco características como ser simple y fácil de calcular, empírica e intuitivamente persuasiva. Luego, explica cinco métricas como la métrica de disponibilidad, integridad, tiempo medio entre fallos, mantenimiento y eficacia de la eliminación de defectos con ejemplos.
La calidad del software se puede medir mediante estándares como ISO 9000 e ISO 9003, CMMI y SPICE. Se utilizan diferentes tipos de indicadores y métricas para medir la calidad del software a nivel de proceso, proyecto y producto. Algunos factores importantes de calidad incluyen la funcionalidad, confiabilidad, usabilidad, eficiencia y capacidad de mantenimiento.
IEEE 730 1989: Plan de aseguramiento de la calidad del softwareJesús Navarro
Este plan de aseguramiento de calidad especifica las actividades para garantizar la calidad del software, incluyendo revisar documentos como los requerimientos, diseño y plan de pruebas. Detalla responsables como el gerente del desarrollo de software y desarrollador, y establece estándares como IEEE830, herramientas como Android Studio, y revisiones como de requerimientos e inspecciones funcionales.
El documento proporciona definiciones de reingeniería de acuerdo a Hammer y Champy y el SEI. Explica que la reingeniería del software es necesaria cuando las aplicaciones se vuelven inestables debido a cambios continuos, y que sus objetivos incluyen mejorar la calidad y reducir costos de mantenimiento. También describe dos métodos comunes, el Análisis de Opciones para Reingeniería y el Modelo de la Herradura.
Estandares y modelos de calidad del softwareaagalvisg
La calidad del software puede parecer un concepto alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad, en este documento encontraras los estándares para crear un software de calidad.
Desarrollo de software basado en lineas de productosJOSEPHPC3000
Este documento describe los conceptos fundamentales de las líneas de productos de software (LPS). En 3 oraciones: LPS permiten la producción rápida y económica de una familia de productos de software relacionados mediante la reutilización de activos de software compartidos y la gestión de las variaciones entre productos; una LPS requiere activos de software reutilizables, modelos de decisión, procesos de producción y repositorios; el éxito de una LPS depende de factores tecnológicos, metodológicos, organizacionales y ger
Quality, quality concepts
Software Quality Assurance
Software Reviews
Formal Technical Reviews
SQA Group Plan
ISO 9000, 9001
Example
Internal and external attributes
Global Software Development powered by PerforcePerforce
From inception to sunset, hundreds of people from around the world are involved in the production and live operations of video games developed by Electronic Arts. An overview of how EA uses a variety of features in Perforce Helix to effectively utilize its world wide talent pool, develop software efficiently, and protect its intellectual property.
Este documento presenta tres métodos para la evaluación de arquitecturas de software: SAAM, ATAM y ARID. SAAM se enfoca en la modificabilidad y evalúa arquitecturas a través de escenarios. ATAM analiza cómo los atributos de calidad interactúan entre sí realizando concesiones. ARID es adecuado para evaluar diseños parciales tempranos. Todos los métodos involucran stakeholders y proveen información para mejorar la arquitectura.
Tecnicas de estimacion de costos de proyecto softwareantonio
El documento trata sobre la planificación estratégica de sistemas de información. Explica que la planificación es importante para establecer objetivos y estrategias. Una parte clave de la planificación es estimar los recursos necesarios como el esfuerzo en meses-hombre. También cubre técnicas para estimar el tamaño del software, costos y esfuerzo requerido como líneas de código y puntos de función.
Conforme el tamaño y complejidad del software se incrementa, diseñarlo va más allá de la aplicación sistemática y cuantificable de una metodología para su construcción, operación y mantenimiento. La arquitectura de software como disciplina, se centra en la idea de reducir la complejidad del software
especificando, modelando y administrando dependencias, comportamientos, y cualidades. Este taller presenta una guía para profesionales de la industria de software, bajo un enfoque técnico, práctico y ágil, respecto a:
a) ¿por qué extender el diseño de software a un nivel arquitectónico?
b) ¿cuándo es valioso abordar el diseño de un proyecto desde un enfoque arquitectónico?
c) ¿qué enfoque utilizar (model-driven, reuse-driven ó risk-driven)?
d) ¿cómo iniciar la adopción de un enfoque arquitectónico?
Concluyendo con una discusión cualitativa y cuantitativa del uso de estilos, modelos, patrones y tácticas arquitectónicas.
Este documento presenta la arquitectura del Framework Batuta a través de diferentes vistas. Describe tres subsistemas principales: definición de procesos, ejecución de procesos y resolución de servicios. Explica tres casos de uso clave: diseño de procesos de negocio, transformación e instalación de procesos, y ejecución de procesos.
Este documento discute varios factores y modelos relacionados con la estimación de costos de software. Describe factores de costo como el tamaño del producto, tiempo disponible, confiabilidad, productividad y métricas técnicas. También cubre técnicas de descomposición, estimación de esfuerzo basada en líneas de código, puntos de función y procesos. Finalmente, explica modelos empíricos como COCOMO y modelos de estimación de tiempo.
Este documento presenta un plan de aseguramiento de la calidad (SQA) para un proyecto de desarrollo de software. El plan describe las actividades de calidad que se llevarán a cabo, incluyendo la revisión de productos, el cumplimiento de procesos, revisiones técnicas formales y el seguimiento de desviaciones. También especifica la documentación requerida como especificaciones de requisitos, diseño de software, planes de verificación y validación, y documentación de usuario. El plan cubre las etapas de requisitos, an
The document discusses software quality assurance (SQA) and quality control (QC). It defines SQA as a planned set of activities to evaluate the development process and ensure software meets requirements. QC focuses on reviews, inspections, and tests to find and remove defects before product release. Formal technical reviews (FTRs) are important QC activities that involve evaluation of work products by other engineers to uncover errors early. The goal is to improve quality and catch the majority of defects in a cost-effective manner.
El documento describe conceptos clave relacionados con la calidad del software, incluyendo modelos como ISO 9126, CMMI y principios de gestión de la calidad. Explica que la calidad del software implica seguir metodologías estándar para garantizar la confiabilidad, mantenibilidad y facilidad de prueba del software. También cubre temas como el aseguramiento, control y mejora continua de la calidad a lo largo del ciclo de vida del desarrollo de software.
Este documento describe los sistemas críticos y la importancia de la confiabilidad en estos sistemas. Explica que los sistemas críticos son aquellos cuyos fallos pueden causar grandes pérdidas económicas, daños físicos o amenazar vidas humanas. Discute tres tipos principales de sistemas críticos y define la confiabilidad como la probabilidad de que un sistema funcione correctamente. También analiza las dimensiones clave de la confiabilidad como la disponibilidad, fiabilidad y protección.
Un framework para el despliegue y evaluación de procesos softwareIván Ruiz-Rube
Este documento presenta una tesis doctoral sobre un marco de trabajo para el despliegue y evaluación de procesos de software. La tesis propone un método para automatizar el despliegue de procesos de software en herramientas de soporte y mejorar los procedimientos para evaluar la calidad de los procesos mediante la recopilación de métricas. El marco de trabajo se basa en modelos de procesos, sus relaciones y la integración con herramientas de soporte.
The document discusses software architecture and defines it as the fundamental organization of a system embodied by its components, their relationships, and design principles. It provides examples of common software architecture structures like modules and components, distribution, and multiple views. Common architectural patterns are also presented, including layers, client-server, master-slave, pipe-filter, and MVC, with examples to illustrate each pattern. The role of the software architect is discussed as well as why architecture is important for systems that are large-scale, distributed, and secure.
This document summarizes key topics from a lecture on security engineering:
1. It discusses security engineering and management, risk assessment, and designing systems for security. Application security focuses on design while infrastructure security is a management problem.
2. It outlines guidelines for secure system design including basing decisions on security policies, avoiding single points of failure, balancing security and usability, validating all inputs, and designing for deployment and recoverability.
3. It also covers risk management, assessing threats, and designing architectures with layered protection and distributed assets to minimize the effects of attacks.
Este documento describe los factores y características que determinan la calidad en el desarrollo de software según el modelo de McCall de 1977. Identifica once factores clave como corrección, fiabilidad, eficiencia e integridad. También explica cinco características como ser simple y fácil de calcular, empírica e intuitivamente persuasiva. Luego, explica cinco métricas como la métrica de disponibilidad, integridad, tiempo medio entre fallos, mantenimiento y eficacia de la eliminación de defectos con ejemplos.
La calidad del software se puede medir mediante estándares como ISO 9000 e ISO 9003, CMMI y SPICE. Se utilizan diferentes tipos de indicadores y métricas para medir la calidad del software a nivel de proceso, proyecto y producto. Algunos factores importantes de calidad incluyen la funcionalidad, confiabilidad, usabilidad, eficiencia y capacidad de mantenimiento.
IEEE 730 1989: Plan de aseguramiento de la calidad del softwareJesús Navarro
Este plan de aseguramiento de calidad especifica las actividades para garantizar la calidad del software, incluyendo revisar documentos como los requerimientos, diseño y plan de pruebas. Detalla responsables como el gerente del desarrollo de software y desarrollador, y establece estándares como IEEE830, herramientas como Android Studio, y revisiones como de requerimientos e inspecciones funcionales.
El documento proporciona definiciones de reingeniería de acuerdo a Hammer y Champy y el SEI. Explica que la reingeniería del software es necesaria cuando las aplicaciones se vuelven inestables debido a cambios continuos, y que sus objetivos incluyen mejorar la calidad y reducir costos de mantenimiento. También describe dos métodos comunes, el Análisis de Opciones para Reingeniería y el Modelo de la Herradura.
Estandares y modelos de calidad del softwareaagalvisg
La calidad del software puede parecer un concepto alejado de la vida diaria de la mayoría de las personas, pero nada más lejos de la realidad, en este documento encontraras los estándares para crear un software de calidad.
Desarrollo de software basado en lineas de productosJOSEPHPC3000
Este documento describe los conceptos fundamentales de las líneas de productos de software (LPS). En 3 oraciones: LPS permiten la producción rápida y económica de una familia de productos de software relacionados mediante la reutilización de activos de software compartidos y la gestión de las variaciones entre productos; una LPS requiere activos de software reutilizables, modelos de decisión, procesos de producción y repositorios; el éxito de una LPS depende de factores tecnológicos, metodológicos, organizacionales y ger
Quality, quality concepts
Software Quality Assurance
Software Reviews
Formal Technical Reviews
SQA Group Plan
ISO 9000, 9001
Example
Internal and external attributes
Global Software Development powered by PerforcePerforce
From inception to sunset, hundreds of people from around the world are involved in the production and live operations of video games developed by Electronic Arts. An overview of how EA uses a variety of features in Perforce Helix to effectively utilize its world wide talent pool, develop software efficiently, and protect its intellectual property.
Este documento presenta tres métodos para la evaluación de arquitecturas de software: SAAM, ATAM y ARID. SAAM se enfoca en la modificabilidad y evalúa arquitecturas a través de escenarios. ATAM analiza cómo los atributos de calidad interactúan entre sí realizando concesiones. ARID es adecuado para evaluar diseños parciales tempranos. Todos los métodos involucran stakeholders y proveen información para mejorar la arquitectura.
Tecnicas de estimacion de costos de proyecto softwareantonio
El documento trata sobre la planificación estratégica de sistemas de información. Explica que la planificación es importante para establecer objetivos y estrategias. Una parte clave de la planificación es estimar los recursos necesarios como el esfuerzo en meses-hombre. También cubre técnicas para estimar el tamaño del software, costos y esfuerzo requerido como líneas de código y puntos de función.
Conforme el tamaño y complejidad del software se incrementa, diseñarlo va más allá de la aplicación sistemática y cuantificable de una metodología para su construcción, operación y mantenimiento. La arquitectura de software como disciplina, se centra en la idea de reducir la complejidad del software
especificando, modelando y administrando dependencias, comportamientos, y cualidades. Este taller presenta una guía para profesionales de la industria de software, bajo un enfoque técnico, práctico y ágil, respecto a:
a) ¿por qué extender el diseño de software a un nivel arquitectónico?
b) ¿cuándo es valioso abordar el diseño de un proyecto desde un enfoque arquitectónico?
c) ¿qué enfoque utilizar (model-driven, reuse-driven ó risk-driven)?
d) ¿cómo iniciar la adopción de un enfoque arquitectónico?
Concluyendo con una discusión cualitativa y cuantitativa del uso de estilos, modelos, patrones y tácticas arquitectónicas.
Este documento presenta la arquitectura del Framework Batuta a través de diferentes vistas. Describe tres subsistemas principales: definición de procesos, ejecución de procesos y resolución de servicios. Explica tres casos de uso clave: diseño de procesos de negocio, transformación e instalación de procesos, y ejecución de procesos.
Este documento discute varios factores y modelos relacionados con la estimación de costos de software. Describe factores de costo como el tamaño del producto, tiempo disponible, confiabilidad, productividad y métricas técnicas. También cubre técnicas de descomposición, estimación de esfuerzo basada en líneas de código, puntos de función y procesos. Finalmente, explica modelos empíricos como COCOMO y modelos de estimación de tiempo.
Este documento presenta un plan de aseguramiento de la calidad (SQA) para un proyecto de desarrollo de software. El plan describe las actividades de calidad que se llevarán a cabo, incluyendo la revisión de productos, el cumplimiento de procesos, revisiones técnicas formales y el seguimiento de desviaciones. También especifica la documentación requerida como especificaciones de requisitos, diseño de software, planes de verificación y validación, y documentación de usuario. El plan cubre las etapas de requisitos, an
The document discusses software quality assurance (SQA) and quality control (QC). It defines SQA as a planned set of activities to evaluate the development process and ensure software meets requirements. QC focuses on reviews, inspections, and tests to find and remove defects before product release. Formal technical reviews (FTRs) are important QC activities that involve evaluation of work products by other engineers to uncover errors early. The goal is to improve quality and catch the majority of defects in a cost-effective manner.
El documento describe conceptos clave relacionados con la calidad del software, incluyendo modelos como ISO 9126, CMMI y principios de gestión de la calidad. Explica que la calidad del software implica seguir metodologías estándar para garantizar la confiabilidad, mantenibilidad y facilidad de prueba del software. También cubre temas como el aseguramiento, control y mejora continua de la calidad a lo largo del ciclo de vida del desarrollo de software.
Este documento describe los sistemas críticos y la importancia de la confiabilidad en estos sistemas. Explica que los sistemas críticos son aquellos cuyos fallos pueden causar grandes pérdidas económicas, daños físicos o amenazar vidas humanas. Discute tres tipos principales de sistemas críticos y define la confiabilidad como la probabilidad de que un sistema funcione correctamente. También analiza las dimensiones clave de la confiabilidad como la disponibilidad, fiabilidad y protección.
Un framework para el despliegue y evaluación de procesos softwareIván Ruiz-Rube
Este documento presenta una tesis doctoral sobre un marco de trabajo para el despliegue y evaluación de procesos de software. La tesis propone un método para automatizar el despliegue de procesos de software en herramientas de soporte y mejorar los procedimientos para evaluar la calidad de los procesos mediante la recopilación de métricas. El marco de trabajo se basa en modelos de procesos, sus relaciones y la integración con herramientas de soporte.
Este documento presenta información sobre diferentes temas de ingeniería de software como Cleanroom, reingeniería, ingeniería web y desarrollo basado en componentes. También incluye los nombres de los integrantes del equipo 4 de ingeniería de software aplicada.
Ingeniería del software basada en componentesjose_macias
La ingeniería del software basada en componentes (ISBC) es un proceso centrado en el diseño y construcción de sistemas informáticos mediante la reutilización de componentes de software. Representa la filosofía de "comprar en lugar de construir" y pasa de programar software a componer sistemas mediante componentes reutilizables. El proceso implica establecer requisitos, diseñar la arquitectura, determinar qué subsistemas se compondrán de componentes existentes y cuáles se construirán, y componer finalmente los componentes de ac
Ingeniería inversa y reingeniería de softwareMoises Medina
Este documento resume los conceptos de ingeniería inversa, reingeniería de software, análisis y diseño orientados a objetos, y programación extrema. La ingeniería inversa analiza el código existente para generar representaciones de alto nivel como diagramas, la reingeniería mejora el software existente, el análisis y diseño orientados a objetos usa clases, herencia y otros principios, y la programación extrema se basa en valores como la simplicidad.
El documento evalúa las condiciones de seguridad y operación del centro de cómputo respondiendo a más de 60 preguntas sobre la protección contra desastres, seguridad física, iluminación, ventilación, electricidad, mantenimiento de hardware y software, copias de seguridad, y capacitación del personal.
El documento describe los principales factores que afectan la calidad de software, incluyendo la corrección, robustez, eficiencia, portabilidad, integridad, facilidad de uso, verificabilidad, compatibilidad, extensibilidad, reutilización y mantenimiento. Los factores internos afectan al desarrollador, mientras que los externos afectan al cliente usuario final. Un ejemplo describe un proyecto fallido de 125 millones de dólares para implementar un sistema de reservas global que resultó imposible de integrar.
El documento presenta información sobre la calidad de software. Define la calidad de software como el grado en que un producto de software cumple con las expectativas de los clientes. Explica que la calidad implica evaluar tanto el producto final como los procesos de desarrollo, los cuales están estandarizados en modelos como ISO/IEC 9126 e ISO/IEC 25000. Estos modelos definen las características de calidad como funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad y portabilidad.
Este documento describe dos notaciones para modelar procesos de negocio: BPMN y Eriksson-Penker Business Modeling Profile. BPMN es la notación más popular y se está convirtiendo en un estándar. Se basa en diagramas de flujo y tiene elementos gráficos simples como actividades, eventos, puertas y carriles/particiones. Eriksson-Penker también permite modelar procesos de negocio visualizando el flujo de información y cómo se realiza el trabajo dentro de una organización. Ambas notaciones ayudan a analizar y comunicar proces
Este documento describe las pruebas de caja blanca y negra. Las pruebas de caja blanca verifican que líneas específicas de código funcionan correctamente y que todas las estructuras de datos y bucles se ejecutan como se espera. Las pruebas de caja negra se enfocan en las entradas y salidas sin considerar el código interno, y buscan garantizar que la interfaz funcione según los requisitos. Existen diferentes métodos para realizar ambos tipos de pruebas, como análisis estático, dinámico,
Este documento presenta criterios para evaluar la confiabilidad y calidad de sitios web. Los criterios incluyen: 1) autoría definida, 2) actualización periódica, 3) propósitos claros, 4) objetividad en los contenidos, 5) precisión de la información, 6) fuentes confiables citadas, y 7) buena organización y navegabilidad. El documento explica cada criterio y da ejemplos de sitios web que los cumplen y no cumplen.
La ingeniería web es la aplicación sistemática de metodologías de ingeniería al desarrollo de aplicaciones web de alta calidad. El documento discute la definición de ingeniería web, las diferencias y similitudes con la ingeniería de software, los atributos de las aplicaciones web como accesibilidad multiplataforma y portabilidad, y los modelos de procesos de ingeniería web como el desarrollo incremental y la evaluación continua con el cliente. También presenta ejemplos de aplicaciones web como reservas de mesas en línea y formularios de
Este documento presenta información sobre pruebas de software. Explica diferentes tipos de pruebas como pruebas unitarias, de integración, de validación y de sistema. También define conceptos clave como verificación y validación y describe el proceso general de pruebas de software para garantizar el correcto funcionamiento de un sistema.
Este documento presenta un plan de pruebas para el sistema de ventas y facturación de MEGAMAXI S.A. con el objetivo de verificar la funcionalidad de los módulos de clientes, inventario, facturación y reportes. Describe las técnicas y tipos de pruebas a realizar, incluyendo pruebas de integridad de datos, funcionalidad, interfaz de usuario, seguridad y recuperación. El plan detalla los criterios de entrada y salida, producibles, ambientes de prueba, roles, riesgos y procesos de gest
Este documento resume el modelo en cascada del ciclo de vida del desarrollo de software. El modelo en cascada consta de las siguientes fases secuenciales: 1) análisis, 2) diseño, 3) codificación, 4) prueba y 5) mantenimiento. Cada fase debe completarse antes de pasar a la siguiente, con la información y productos entregados por la fase anterior. El modelo en cascada fue el primero propuesto y aunque anticuado, sigue usándose en algunos proyectos o como parte de otros modelos más modernos.
Este documento describe los conceptos clave de la ingeniería de software y la gestión de la calidad de software. Explica los modelos del ciclo de vida del software como la cascada, prototipo e incremental. También cubre temas como requisitos, diseño, construcción, verificación, validación y pruebas de software.
El documento presenta los conceptos de validación y verificación de software. Explica que la validación busca comprobar que el software cumple con las expectativas del cliente, mientras que la verificación busca comprobar que el sistema cumple con los requerimientos especificados. Además, detalla las diferentes etapas de las pruebas de software como parte del proceso de validación y verificación.
Este documento describe los procesos de pruebas y validación de software, los cuales son fundamentales para garantizar su calidad. Explica que las pruebas buscan encontrar errores en el software mediante la ejecución sistemática de pruebas de datos de entrada y comparación de salidas, aunque no pueden garantizar la ausencia total de errores. También distingue entre pruebas de verificación, que revisan el cumplimiento de especificaciones, y pruebas de validación, que evalúan si el software satisface las necesidades del usuario.
El documento describe el proceso de desarrollo de software, incluyendo diferentes modelos como la cascada, prototipado y espiral. También discute el Software Capability Maturity Model (SW CMM) que evalúa la capacidad de las empresas para gestionar proyectos de software de manera estructurada y predecible.
El documento trata sobre la calidad de software. Explica que la calidad debe considerarse a lo largo de todo el ciclo de vida del software, desde la concepción hasta la descontinuación. También describe los diferentes tipos de pruebas como las pruebas de unidad, integración y funcionales que ayudan a garantizar la calidad. Finalmente, destaca los beneficios de la calidad tanto para el cliente como para el proveedor.
El documento compara el método de cascada y el método en espiral para el desarrollo de software. El método de cascada sigue un proceso lineal de especificación, diseño, implementación, prueba e instalación, mientras que el método en espiral es un proceso iterativo que evalúa riesgos y desarrolla prototipos para resolver problemas antes de avanzar al siguiente nivel del producto. El método en espiral se centra en la gestión de riesgos y la calidad, mientras que el método de cascada presenta mayores riesgos para
Este documento describe la calidad y garantía de calidad del software. Explica que la calidad del software se refiere a cumplir con los requisitos funcionales y de rendimiento establecidos. También cubre los factores que afectan la calidad como la corrección, fiabilidad y mantenibilidad. Finalmente, define que la garantía de calidad del software (SQA) es un plan para asegurar la calidad a través de métodos técnicos, pruebas y mediciones.
Herramientas y entornos de implementacion de softwareMiguel Sanchez
Este documento describe las herramientas CASE (Computer-Aided Software Engineering), que ayudan en el desarrollo y mantenimiento de software reduciendo los costos. Explica los objetivos, componentes y ejemplos de herramientas CASE, así como los beneficios y desventajas. También cubre temas como la prueba de software, validación y verificación de software orientado a objetos y aplicaciones web, y la evolución de sistemas heredados.
El documento habla sobre los fundamentos del diseño de software. Explica que el diseño de software permite producir modelos del sistema que pueden evaluarse antes de codificar. También cubre conceptos como abstracción, modularidad, estructura de datos, procedimientos de software y arquitectura. Finalmente, discute técnicas para garantizar la calidad como pruebas estáticas, dinámicas, automatizadas y manuales.
El documento describe diferentes tipos de pruebas de software, incluyendo pruebas estáticas, dinámicas, funcionales y no funcionales. Explica que las pruebas estánticas se realizan sin ejecutar el código, mientras que las dinámicas requieren ejecutar la aplicación. También cubre diferentes enfoques de pruebas como de caja blanca, caja negra y aleatorias, así como niveles de pruebas como unitarias, de integración y de sistema.
El documento presenta una introducción a las pruebas funcionales y de carga para aplicaciones mediante la suite Oracle Application Testing. Explica los pasos básicos para realizar pruebas funcionales y de carga, como crear y configurar scripts, añadir validaciones, y analizar resultados. También describe las principales características y ventajas de las herramientas Oracle Functional Testing y Oracle Load Testing para automatizar pruebas de calidad de aplicaciones.
El documento presenta una introducción a la ingeniería de software, incluyendo diferentes modelos de desarrollo como el modelo en cascada, el desarrollo evolutivo y el modelo en espiral. También describe técnicas como los prototipos, diagramas de flujo de datos y entidad-relación, así como la validación, verificación y documentación de software.
El documento describe el modelo en cascada y el modelo en V para el desarrollo de software. Explica que el modelo en cascada sigue un enfoque secuencial de análisis de requisitos, diseño, codificación, prueba y mantenimiento. El modelo en V añade las fases de verificación y validación y muestra la relación entre las fases de desarrollo y prueba asociadas. Ambos modelos tienen ventajas como una metodología bien definida, pero también desventajas como la dificultad de cambiar requisitos tarde en
Las Claves para Gestionar Proyectos de Sistemas de InformaciónSolutions DAT
La Gestión Integrada de Proyectos, con todo tipo de detalles paso a paso, y con un lenguaje claro y entendible, tanto por técnicos como no técnicos, desde la vertiente del Cliente y del Proveedor.
El documento describe las fases de un proyecto de desarrollo de software orientado a la web, incluyendo el análisis de necesidades, diseño de la aplicación, versiones funcionales y definitivas, y post-venta y mantenimiento. También discute la medición de la calidad de un software para la web a través de cualidades externas e internas, y las pruebas necesarias como validación de código, simulación de usuarios, y herramientas en el navegador.
El documento describe las fases de un proyecto de desarrollo de software orientado a la web, incluyendo el análisis de necesidades, diseño de la aplicación, versiones funcionales y definitivas, y post-venta y mantenimiento. También discute la medición de la calidad de un software para la web a través de cualidades externas e internas, y las pruebas necesarias como validación de código, simulación de usuarios, y herramientas en el navegador.
El documento describe las fases de un proyecto de desarrollo de software orientado a la web, incluyendo el análisis de necesidades, diseño de la aplicación, versiones funcionales y definitivas, y post-venta y mantenimiento. También discute la medición de la calidad de un software para la web a través de cualidades externas e internas, y las pruebas necesarias como validación de código, simulación de usuarios, y herramientas en el navegador.
Durante el período citado se sucedieron tres presidencias radicales a cargo de Hipólito Yrigoyen (1916-1922),
Marcelo T. de Alvear (1922-1928) y la segunda presidencia de Yrigoyen, a partir de 1928 la cual fue
interrumpida por el golpe de estado de 1930. Entre 1916 y 1922, el primer gobierno radical enfrentó el
desafío que significaba gobernar respetando las reglas del juego democrático e impulsando, al mismo
tiempo, las medidas que aseguraran la concreción de los intereses de los diferentes grupos sociales que
habían apoyado al radicalismo.
José Luis Jiménez Rodríguez
Junio 2024.
“La pedagogía es la metodología de la educación. Constituye una problemática de medios y fines, y en esa problemática estudia las situaciones educativas, las selecciona y luego organiza y asegura su explotación situacional”. Louis Not. 1993.
Presentación de la conferencia sobre la basílica de San Pedro en el Vaticano realizada en el Ateneo Cultural y Mercantil de Onda el jueves 2 de mayo de 2024.
1. CAPITULO 1
Verificación y Validación
Asegurando que un sofware satisface las
necesidades del usuario
Por Julio C. Alsina
Ingeniería de Software
2. Objetivos
• Introducción a la verificación y validación del
software y discusión acerca de las diferencias
entre ambas.
• Descripción del proceso de inspección de
programa y su rol en la verificación y validación.
• Explicación de análisis estático como técnica de
verificación
• Descripción del proceso de desarrollo del software
Cleanroom
Ingeniería de Software
3. Tópicos cubiertos
• Planificación de la Verificación y
Validación
• Inspecciones de Software
• Análisis estático automatizado
• Desarrollo del software Cleanroom
Ingeniería de Software
4. Verificación vs validación
• Verificación:
“Estamos creando el producto correctamente”
El software debería ajustarse a su especificación
• Validación:
" Estamos creando el producto correcto"
El software debería realizar lo que el usuario realmente
necesita
Ingeniería de Software
5. El proceso de V & V
• Es un proceso de ciclo de vida – V&V
debería aplicarse en cada etapa en el
proceso de software (Rev. Req., Diseño, Insp.Codigo, Prueba)
• Tiene dos objetivos principales:
– El descubrimiento de defectos en un sistema
– El asegurar que un sistema es utilizable en una
situación operacional
Ingeniería de Software
6. V&V Estática y dinámica
• Inspecciones de Software: relacionadas con el
análisis de una representación estática de un
sistema para descubrir problemas (V&V estática)
– Puede ser un suplemento de un documento basado en
una herramienta y análisis de código
• Prueba de Software: relacionadas con pruebas y
observaciones del comportamiento del producto
(V&V dinámica)
– El sistema es ejecutado con datos de prueba y es
observado su comportamiento operacional
Ingeniería de Software
7. V&V estáticas y dinámicas
Static
Verificación
verification
Estática
Requirements
Especif. de High-level
Diseño de Formal
Especificación Detailed
Diseño
specification Program
Programa
specification
Requerim. design
Alto Nivel Formal design
Detallado
Dynamic
Validación
Prototype
Prototipo validation
Dinámica
“Técnicas estáticas solo comprueban correspondencia con las especificaciones”
“No demuestran que SW tiene utilidad operacional ni desempeño o fiabilidad”
“Para validar un sistema de SW se requieren PRUEBAS”
Ingeniería de Software
8. Pruebas de programa
“Son prácticas con programas que utilizan datos similares a los reales”
“Examinan salidas buscando anomalías”
“Pueden realizarse en fase de Implementación o despues de finalizar la misma”
• Pueden revelar la presencia de errores, NO su
ausencia
• Una prueba exitosa es aquella en la que se
descubren uno o mas errores
• La única técnica de validación para requerimientos
no funcionales
• Debe ser utilizada conjuntamente con verificación
estática para proveer un completo proceso de V&V
Ingeniería de Software
9. Tipos de Pruebas
• Pruebas de Defectos
– Pruebas diseñadas para descubrir
defectos en los sistemas
– Una prueba de defectos exitosa es aquella que revela la
presencia de defectos en un sistema
– Controladores obtienen sentimiento intuitivo de la
fiabilidad del SW
• Pruebas estadísticas
– Pruebas diseñadas para reflejar la frecuencia de
entradas de usuario. Utilizadas para estimación de
fiabilidad (número de caidas del sistema).
– Desempeño valora Tiempo Ejec. y Tiempo Respuesta
Ingeniería de Software
10. Metas de V& V
• La Verificación y Validación deberían
conceder confianza en que el software
alcanza su propósito.
• Esto NO significa que esté libre de defectos
• Mas bien debería ser lo suficientemente
bueno para su uso y el tipo de uso
determinará el grado de confianza que es
necesaria
Ingeniería de Software
11. Nivel de Confianza V & V
Depende del propósito del sistema, expectativas del
usuario y del ambiente de marketing
– Función del Software
• El nivel de confianza depende de cuan crítico es el software para una
organización (Ej. sistemas criticos de medicina)
– Expectativas del Usuario
• Los usuarios pueden tener bajas expectativas de ciertos tipos de
software. La tolerancia a fallas de sistema ha decrecido.
– Ambiente de Marketing
• Poner tempranamente un producto a la venta puede ser mas
importante que encontrar defectos en el programa (Ej. Si clientes no
estan dispuestos a pagar alto precio SW, son más tolerantes a fallas)
Ingeniería de Software
12. Pruebas y Depuración
• Pruebas y depuración de defectos son procesos distintos
• V&V están relacionados con el establecimiento de la
existencia de defectos en un programa
• Depuración está relacionada con
localizar y reparar estos errores
• Depuración considera formular una hipótesis acerca del
comportamiento del programa, luego probar estas
hipótesis para encontrar el error
• Pueden apoyarse en herramientas interactivas
integradas con un sistema de interpretación
Ingeniería de Software
13. El proceso de Depuración
Test
Resultados Test
Casos de
results Specification
Especificación
de pruebas cases
Pruebas
Locate Design Repair Re-test
Localizar Diseñar repair
error
Reparac Reparación de
error
Volver a
error program
error error error probar
Ingeniería de Software
14. Planeamiento de V & V
• V&V es un proceso caro. Puede ocupar la mitad del
presupuesto de desarrollo
• Se necesita una planificación cuidadosa para obtener lo
mejor de los procesos de pruebas e inspección
• La planificación debería estar antes que nada en el
proceso de desarrollo
• El plan debería identificar el balance entre verificación
estática y pruebas
• La planficación de las pruebas se relaciona con la
definición de estándares para el proceso de pruebas,
mas que con la descripción de las pruebas de productos
• Cuanto más crítico, mayor esfuerzo a verif. estáticas
Ingeniería de Software
15. El modelo de desarrollo V
Requir ements
Especif. de System
Especif. de System
Diseño del Detailed
Diseño
specification specification design design
Requerim. Sistema. Sistema. Detallado
PlanAcceptance
de Prueba System
Plan de Prueba PlanSub-system
de Prueba Module and
Codificación
integration integration unit code
y prueba de
test plan
de Aceptación Integración sma. Integr.test plan
Sub-sma.
test plan and tess
unidad y módulo
Servicio
Service
Prueba de
Acceptance Prueba Integra-
System Prueba Integra-
Sub-system
test
Aceptación integration test
ción Sistema integration test
ción sub-sistema
“Derivar planes de prueba a partir de las especificaciones y diseño del sistema”
Ingeniería de Software
16. La estructura de un plan de prueba de software
• Proceso de pruebas ”Descripcion de fases principales del proceso”
• Trazabilidad de requerimientos
“Plantear de forma a probar individualmente todos los requerimientos”
• Items probados ”Especificar los items de proceso de SW a probar”
• Agenda de pruebas ”Calendarizar pruebas y asignar recursos”
• Procedimientos de almacenamiento de pruebas
”Almacenar resultados. Debe ser posible auditar los procesos de prueba”
• Requerimientos de software y hardware
• Limitaciones ”Anticipar restricciones que puedan afectar al proceso”
Ingeniería de Software
17. Inspecciones de Software
• Involucran al equipo examinando la fuente de
representación con el objetivo de descubrir
anomalías y defectos
• No requieren ejecución de un sistema,
de modo que pueden ser utilizadas
antes de la implementación
• Pueden ser aplicadas a cualquier representación
del sistema (requerimientos, diseño, datos de
prueba, etc.)
• Técnica muy efectiva para descubrir errores
Ingeniería de Software
18. Exito de la Inspección
• Muchos y diferentes defectos pueden ser
descubiertos en una sola inspección. En
pruebas, un defecto puede enmascarar otro
de modo que son requeridas varias
ejecuciones. Cada prueba normalmente
conduce a una sola falla o defecto.
• Resaltan la reutilización y el conocimiento
de programación, de modo que los revisores
están preparados para ver aquellos tipos de
errores que aparecen comunmente.
Ingeniería de Software
19. Inspecciones y Pruebas
• Las inspecciones y pruebas son complementarias y
no técnicas de verificación opuestas
• Ambas deberían ser utilizadas
durante el proceso de V&V
• Las inspecciones pueden chequear conformidad con
una especificación, pero no conformidad con los
requerimientos reales del cliente
• Las inspecciones no pueden chequear características
funcionales, como ser rendimiento, usabilidad, etc.
• Las inspecciones sobrecargan el costo inicial pero
conducen a ahorros luego que los equipos adquieren
experiencia en su utilización.
Ingeniería de Software
20. Inspecciones de Programa
• Enfoque formalizado a revisiones de
documentos
• Intento explícito para la
DETECCIÓN de defectos (no la corrección)
• Los defectos pueden ser errores lógicos,
anomalías en el código que pueden indicar
una condición errónea (por ej. una variable
no inicializada) o el no cumplimiento de
estándares.
Ingeniería de Software
21. Pre-condiciones para Inspección
• Una especificación precisa debe estar disponible
• Los miembros del equipo deben estar familiarizados con
los estándares de la organización
• Debe estar disponible el código sintácticamente correcto
• Un checklist de errores debería estar preparado
• La gerencia debe aceptar que la inspección incrementará
los costos tempranamente en el proceso de software
• La gerencia no debe utilizar las inspecciones en las
evaluaciones del personal
Ingeniería de Software
22. El proceso de inspección
Planifica-
Planning
ción Panorama
Overview Follow-up
Seguimiento
general Individual
Preparación Re-elabora-
Rework
preparation
individual ción
Inspection
Reunión de
meeting
Inspección
Ingeniería de Software
23. Procedimiento de Inspección
• Panorama general del sistema presentado al
equipo de inspección (autor describe objetivo del codigo)
• Código y documentos asociados son distribuídos
por adelantado al equipo de inspección
• Preparacion individual de los participantes
• La inspección se realiza y son descubiertos los
errores (< 2hs). Cantidad depende de experiencia
• Se realizan las modificaciones para reparar los
errores descubiertos
• La re-inspección puede o no ser necesaria (seguimiento)
• El documento resultante es aprobado por el
moderador
Ingeniería de Software
24. Equipos de Inspección
• Constituídos por al menos 4 miembros:
– El autor del código a ser inspeccionado
– El inspector que encuentra los errores,
omisiones e inconsistencias
– El lector que lee el código al equipo
– El moderador que dirige la reunión y anota los
errores descubiertos (responsable de planificar)
– Otros roles son secretario y moderador en jefe.
Ingeniería de Software
25. Checklists de Inspección
• Un checklist de errores comunes debería
utilizarse para dirigir la inspección
• Un checklist de errores es dependiente del
lenguaje de programación
• Cuanto mas „débil‟ el tipo de
chequeo, mas largo el checklist
• Ejemplos: inicialización, nombrado de
constantes, terminación de bucles, límites
de arrays, etc.
Ingeniería de Software
26. Chequeos de inspección
Clase de falta Chequeo de Inspección
Fallas de datos -Están todas las variables inicializadas antes de que sus valores sean utilizados?
- Han sido nombradas todas las constantes?
- El límite inferior de los arrays debería ser 0, 1 u otro?
- El límite superior de los arrays debería ser igual al tamño del array o a su tamaño menos 1?
- Si se utilizan cadenas de caracteres, existe un delimitador explícitamente asignado?
Fallas de control - Para cada sentencia condicional, es correcta la condición?
- Cada bucle se termina?
- Están correctamente puestos entre paréntesis las sentencias compuestas?
- En las sentencias CASE, son posibles todos los casos que se incluyen?
Fallas de entrada/salida - Son utilizadas todas las variables?
- Todas las variables de salida tienen un valor asignado antes de que ocurra la salida?
Fallas de interfase - Todas las llamadas a funciones y procedimientos tienen el número correcto de parámetros?
- Coinciden los tipos de parámetros formales y casuales?
- Están los parámetros en el orden correcto?
- Si los componentes accesan la memoria compartida, tienen el mismo modelo de la estructura de
memoria compartida?
Fallas de administración - Si una estructura relacionada es modificada, han sido todos los enlaces correctamente reasignados?
de almacenamiento - Si se utiliza almacenamiento dinámico, se ha distribuído el espacio correctamente?
- Luego de que el espacio ya no sea necesario, es explícitamente desocupado?
Fallas de administración - Han sido consideradas todas las posibles condiciones de error?
de excepciones
Ingeniería de Software
27. Ratio de Inspección
• 500 declaraciones/hora durante el panorama general
• 125 declaraciones de origen/hora durante la
preparación individual
• 90-125 declaraciones/hora pueden ser
inspeccionadas
• Sin embargo, la inspección es un proceso caro
• Inspeccionar 500 líneas cuesta acerca de 40 horas
hombre
(4 personas 1 hs. panorama gral. + 4 hs. Prep.Individual + 4 a 5 hs. Inspección)
Ingeniería de Software
28. Análisis estático automatizado
• Los analizadores estáticos son herramientas
de software para el procesamiento
de texto fuente
• Analizan el texto del programa e intentan
descubrir condiciones potenciales de error y
las ponen a disposición del equipo de V&V
• Es muy efectivo como soporte para las
inspecciones. Es un suplemento pero no
puede reemplazar el proceso de inspección
Ingeniería de Software
29. Chequeos de análisis estático
Clase de falta Chequeo de Análisis estático
Fallas de datos - Variables utilizadas antes de su inicialización
- Variables declaradas pero nunca utilizadas
- Variables asignadas dos veces pero nunca utilizadas entre
asignaciones
- Posibles violaciones de límites de arrays
- Variables no declaradas
Fallas de control - Código no encontrado
- Segmentos incondicionales dentro de bucles
Fallas de entrada/salida - Variables de salida dobles
Fallas de interfase - No coinciden los tipos de parámetros
- No coinciden los números de parámetros
- Resultados de función sin utilizarse
- Funciones y procedimientos que no son llamados
Fallas de administración de - Punteros no asignados
almacenamiento - Punteros aritméticos
Ingeniería de Software
30. Etapas del análisis estático
• Análisis de Control de Flujo. Chequea los bucles
con salidas o entradas múltiples, encuentra código
perdido, etc.
• Análisis de uso de datos. Detecta variables no
inicializadas, variables escritas dos veces sin una
intervención asignada, variables que fueron
declaradas pero nunca fueron usadas, etc.
• Análisis de Interfase. Chequea la consistencia de
declaraciones de rutinas y procedimientos y sus
usos.
Ingeniería de Software
31. Etapas del Análisis Estático
• Análisis del flujo de información. Identifica las
dependencias de variables de entrada y salida.
No detecta anomalías, pero resalta información
para la inspección o revisión de código.
• Análisis de rutas. Identifica las rutas utilizadas en
el programa y analiza las declaraciones ejecutadas
en esas rutas. Potencialmente útil en el proceso de
revisión.
• Estas etapas generan gran cantidad de
información, que debe ser usada con cuidado
Ingeniería de Software
32. 138% more lint_ex.c Listar programa
#include <stdio.h> Define función con 1 parametro
printarray (Anarray)
int Anarray;
{
printf(“%d”,Anarray);
}
main ()
{ Se llama función c/3 parametros
int Anarray[5]; int i; char c;
printarray (Anarray, i, c); Variables i y c declaradas
printarray (Anarray) ; no reciben valor y result.no se usa
}
139% cc lint_ex.c
Compilación sin errores
140% lint lint_ex.c Lint SI DETECTA ERRORES
lint_ex.c(10): warning: c may be used before set Variables usadas sin inicializar
lint_ex.c(10): warning: i may be used before set
printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) #Argum. dif.a los declarados
printarray, arg. 1 used inconsistently lint_ex.c(4) ::
lint_ex.c(10)
printarray, arg. 1 used inconsistently lint_ex.c(4) :: Análisis estático
lint_ex.c(11)
printf returns value which is always ignored LINT
33. Utilización del análisis estático
• Particularmente valioso cuando un lenguaje
como por ej. C es utilizado, el cual tiene un
tipeo débil y por lo tanto varios errores
pueden no ser detectados por el compilador
• Menos efectivo en términos de costos para
lenguajes como Java, que tienen fuertes
controles de tipeo y pueden por lo tanto,
detectar varios errores durante la
compilación
Ingeniería de Software
34. Desarrollo de software de „Sala Limpia‟
• El nombre se deriva del proceso de „Sala Limpia‟
en la fabricación de semiconductores. La filosofía
es evitar los defectos antes que corregirlos.
• Reemplaza a pruebas de unidades de componentes
por inspeccion para comprobacion de consistencia
con especificaciones
• El proceso de desarrollo está basado en:
– Especificación formal
– Desarrollo incremental
– Verificación estática utilizando argumentos de
corrección
– Pruebas estadísticas para determinar la fiabilidad de los
programas
Ingeniería de Software
35. El proceso de „Sala Limpia‟
Formally Reparación del Error
Error rework
Formalizar
specify
system
Especificación
Define
Definir Construct
Construir Formally
Verificar Integrate
Integrar
software
incrementos de structured
programa verify
código increment
incremento
increments
software program
estructurado code
formalmente
Develop
Desarrollar
operational
perfil Design
Diseñar Test
Pruebas
profile
operacional statistical integrated
pruebas sistema
tests system
estadísticas integrado
Ingeniería de Software
36. Características del proceso de Sala Limpia
• Especificación formal utilizando un modelo
de transición de estados
• Desarrollo incremental
• Programación estructurada – se utilizan
técnicas de control limitado y abstracción
• Verificación estática utilizando
inspecciones rigurosas
• Pruebas estadísticas del sistema (se basa en
el perfil operacional)
Ingeniería de Software
37. Desarrollo Incremental
Especificación
Frozen
specification
congelada
Establish
Establecer Formal
Especificación Develop s/w
Desarrollo de Deliver
Entrega del
rerquirements
requerimientos specification
Formal increment
Incremento de sw software
Software
Solicitud de ements change request
Requir cambio de requerimientos
Ingeniería de Software
38. Especificación Formal e Inspecciones
• El modelo basado en estados es una
especificación del sistema y el proceso de
inspección chequea el programa
contra este modelo
• El enfoque de programación es definido de
manera a que la correspondencia entre el
modelo y el sistema sea clara
• Argumentos matemáticos (no pruebas) son
utilizados para elevar la confianza en el
proceso de inspección
Ingeniería de Software
39. Equipos del proceso de „Sala Limpia‟
• Equipo de Especificación.. Responsable del
desarrollo y mantenimiento de la especificación
del sistema.
• Equipo de Desarrollo. Responsable por desarrollar
y verificar el software. El software NO es
ejecutado o compilado durante este proceso.
• Equipo de Certificación. Responsable por el
desarrollo de una serie de pruebas estadísticas para
ejercitar el software luego del desarrollo. Modelos
de crecimiento de la fiabilidad son utilizados para
determinar cuando la fiabilidad es aceptable.
Ingeniería de Software
40. Evaluación del proceso de „Sala Limpia‟
• Los resultados en IBM han sido impresionantes
con algunas fallas descubiertas en sistemas
entregados
• Evaluación independente muestra que el proceso
no es mas costoso que otros enfoques
• Menos errores que en un proceso
de desarrollo „tradicional‟
• No está claro como este enfoque puede ser
transferido a un ambiente con ingenieros menos
capacitados o menos motivados
Ingeniería de Software
41. Puntos claves
• La verificación y validación no son lo mismo. La
verficación muestra conformidad con la
especificación; la validación muestra que el
programa satisface las necesidades del cliente
• Los planes de prueba deberían ser elaborados para
guiar el proceso de pruebas
• Las técnicas de verificación estática consideran la
examinación y el análisis del programa para la
detección de errores
• Las inspecciones de programa
son muy efectivas para descubrir errores
Ingeniería de Software
42. Puntos claves
• Las inspecciones de código de programa son
realizadas por un equipo pequeño para localizar
fallas
• Las herramientas de análisis estático pueden
descubrir anomalías en los programas las cuales
pueden ser indicadores de fallas en el código
• El proceso de desarrollo de „Sala Limpia‟ depende
del desarrollo incremental, verificación estática y
pruebas estadísticas
Ingeniería de Software