Cualidades del Software

Slides:



Advertisements
Presentaciones similares
Software y Producción de Software Ingeniería del Sofware III Lic. Sergio Daniel Caballero Lic. Sergio Daniel Caballero – Dr. Horacio D Kuna.
Advertisements

Clase 09.  Garantizar la calidad de software  La prueba nunca termina, del IS translada se translada al usuario  Las casas de software invierte del.
Sistemas de Información Enfoques para la Construcción de los Sistemas de Información MBA Luis Elissondo.
Ciclo de vida del software. Definición ' El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una.
FUNDAMENTOS DEL ANÁLISIS DE SISTEMAS Un sistema es un conjunto de componentes que se unen e interactúan entre si para formar un todo en base a un mismo.
Calidad de Software.   ¿Qué es?  ¿Quién lo hace?  ¿Por qué es importante?  ¿Cuáles son los pasos?  ¿Cuál es el producto final?  ¿Cómo me aseguro.
Pruebas de Funcionalidad de Software: Caja Negra y Caja Blanca Curso: Diseño de Sistemas 9no. Semestre.
PROGRAMACION ORIENTADA A EVENTOS
Metodología de Implementación de Sistemas ERP
intro_intro_GnU/Linux
Diseño de interfases Sistemas de Información
IEEE-std Práctica Recomendada para la Especificación de Requerimientos de Software Fuente: IEEE Recommendad Practice for Software Requirements.
Ingeniería de Software
CC4401 – Ingeniería de Software I
Tratamiento de Datos Capitulo Dos.
LOS DIFERENTES LENGUAJES DE PROGRAMACION PARA LA WEB
SWEBOK.
Gestión de Software Conferencia # 2 Niveles de PSP: PSP0.1.
U.T. 11: Introducción A Las Bases De Datos
Cualidades del Software
DISEÑO DE PROCESOS TEMA 6.
Principios de la Ingeniería de Software
Cualidades del Software
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
Tema 3. Lenguaje unificado de modelado UML
Seminario de Arquitectura de Software
UNIVERSIDAD NACIONAL DE LOJA Área de la Educación, el Arte y la Comunicación Informática Educativa IV INGENIERIA DE SOFTWARE Taller de Análisis y Diseño.
Tipos de pruebas Hector Leonardo Arias.
Metodología de la programación
Ingeniería del Software
Principales desafíos: adaptabilidad y agilidad empresarial
FUNDAMENTOS DE PROGRAMACION EN ENTORNO WEB. Rodrigo Cabello Ing. Informático Director de proyectos Think – Ideas in Motion FUNDAMENTOS.
Unidad 5: Evaluación de los sistemas
En este periodo el analista se esfuerza por comprender la información que necesitan los usuarios para realizar su trabajo de la manera correcta.
Análisis y diseño de aplicaciones. Introducción Crisis del software - conferencia organizada en 1968 por la Comisión de Ciencias de la OTAN en Garmisch.
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS.
Identificación y Clasificación de los Componentes Reutilizables.
Identificación y Clasificación de los Componentes Reutilizables.
Universidad Nacional Experimental Francisco De Miranda Vice-rectorado Académico Municipalización Universitaria Morón Estado Carabobo MORÓN NOVIEMBRE 2018.
Estructura general de un programa. Estructura general de un programa. Pseudocódigo Diagrama de flujo Concepto de programas. Concepto de programas. Instrucciones.
Norma IEC 1131 Norma IEC 1131 en STEP 7 NORMA IEC 1131 EN STEP 7
ATRIBUTOS DE CALIDAD LIC. EN INGENIERÍA EN SISTEMAS COMPUTACIONALES CALIDAD EN EL SOFTWARE LISC02SA.
Estructura de Sistemas Operativos CAMPOS CHACALTANA, ANTHONY.
Estructura de los sistemas Operativos 1. Componentes de un sistema operativo  Administración de procesos  Administración de memoria  Subsistema de Entrada/Salida.
PRIMERA UNIDAD: GESTIÓN DE INGENIERÍA DE SOFTWARE S1. Introducción a la Ingeniería de Software S2. Modelos y Marcos de Procesos de software S3. Especificación.
ESTRUCTURA DE SISTEMAS OPERATIVOS Carbajal Rojas karla.
PARAMETROS PARA EL DISEÑO DE CONTENIDOS EDUCATIVOS DIGITALES
Mtro. Juan Almazán Corona
4. Estimación del esfuerzo 1 TEMA 4. ESTIMACIÓN DEL ESFUERZO EN EL DESARROLLO DE SOFTWARE Jose Onofre Montesa Andrés Universidad Politécnica de Valencia.
INTRODUCCIÓN A UML Oscar Miguel Alonso Moreno. INTRODUCCIÓN A UML  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
ASIGNATURA: REINGENIERÍA DEL SOFTWARE CUATRIMESTRE: I DOCENTE: ING. IRENE MARTÍNEZ MEJÍA CORREO: Managua, 26 de Enero 2019
1 SISTEMAS II CICLO DE VIDA. 2 Sistemas II. CICLO DE VIDA DE Los Sistemas de Información “ Es un proceso por el cual los analistas de sistemas, los ingenieros.
INTEGRANTES u Álvarez Palomino David u Salazar Colonia Jesús Felipe u Velásquez Huapaya Ricardo.
Desarrollo de Sistemas de Información Contable - Sis USB 1 METODOLOGIAS DE DESARROLLO DE SOFTWARE.
NORMA ISO/IEC 9126 Norma publicada en Usada para la evaluación de la calidad de software. Establece las características de calidad para productos.
MODELO EN CASCADA Integrantes: Felipe Alemán Lester Blandón.
INTRODUCCIÓN A UML.  QUE ES UML?  PARA QUE SE UTILIZA  COMPONENTES  DIAGRAMAS.
Desarrollo de Sistemas de Información Contable - Sis USB 1 METODOLOGIAS DE DESARROLLO DE SOFTWARE.
Plan de Sistemas de Información (PSI). Plan de Sistemas de Información (PSI) Descripción y Objetivos Tiene como objetivo la obtención de un marco de referencia.
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS
ESTRUCTURA DE LOS SISTEMAS OPERATIVOS
ESTRUCTURA DE SISTEMAS OPERATIVOS - ROY CANEPA JUAN FABIO
Estructura de Sistemas Operativos
Ha llegado el momento de dar una mirada al interior de los Sistemas Operativos. En las siguientes secciones examinaremos cuatro estructuras distintas.
Diseñas y elaboras algoritmos para la solución de problemas
HOJA DE VERIFICACIÓN DE CALIDAD. Una hoja de verificación es una herramienta expresada en un formato que se utiliza para recolectar de manera estructurada.
Especificación de Requerimientos
Ing. Carlos García P. C.I UNIDAD EDUCATIVA “SALINAS INNOVA” P Identifique el contexto para el cual se Planifica un nuevo sistema ÁREA.
Transcripción de la presentación:

Cualidades del Software ¿Qué es un buen software?

Cualidades del Software Correcto Confiable Robusto Eficiente Amigable Verificable Reusable Portable Interoperable Productivo A Tiempo Visible Coheso Desacoplado Comprensible Mantenible

Correcto Especificación de Requisitos Un software es correcto si se comporta de acuerdo con su especificación. La definición supone: la existencia de un especificación de requisitos la posibilidad de determinar sin ambigüedad la correspondencia entre la especificación y el diseño. La correctitud del software puede comprobarse probándolo o mediante análisis. Software

Correcto Confiable Confiable El software se comporta de acuerdo con lo esperado por el usuario. A diferencia de la corrección, la confiabilidad es algo relativo. El mercado puede admitir algunos errores en el software siempre que en general se comporte en forma esperable. No sólo no damos garantías de corrección del software, sino que varios productos incluyen un “disclaimer”. Esta es una señal de la inmadurez del área.

Robusto Un software es robusto si se comporta en forma razonable aún en situaciones no anticipadas. Datos de entrada incorrectos o fallas de hardware son las situaciones más frecuentes. La cantidad de código que se dedica a hacer el software robusto depende de la experiencia de los usuarios o lo crítico de su misión. Si algo se especifica como requisito, cumplirlo es cuestión de corrección; si no está en los requisitos es cuestión de robustez.

Eficiencia Un sistema de software es eficiente si usa sus recursos en forma económica. Los criterios de eficiencia varían con la tecnología y el tiempo. Métodos de evaluación de performance: monitoreo, análisis, simulación. No es bueno evaluar la performance sólo después que el producto esta listo. Muy lento  baja la productividad de los usuarios. Usa mucho disco  puede ser muy caro ejecutarlo. Usa mucha memoria  puede afectar la performance de otros sistemas.

Amigable Un software es amigable si sus usuarios lo encuentran fácil de utilizar. La interfaz con el usuario es parte esencial del ser amigable. Depende de los usuarios: novicios: mejor largos mensajes explicativos. expertos: aprecian los atajos. Los sistemas insertos son amigables si son fáciles de configurar. La consistencia de las interfaces es un factor determinante. También la performance y la confiabilidad.

Verificable El software es verificable si sus propiedades pueden ser comprobadas. La corrección y la performance pueden verificarse fácilmente. La verificación puede hacerse mediante análisis o tesiting. Más verificable: monitores en el código, diseño modular, disciplina en la codificación, lenguaje de programación adecuado.

Reusable Software ya construido se usa con pocos o ningún cambio. La reutilización es más apropiada para componentes que para sistemas completos. Las bibliotecas (¿librerías?) científicas FORTRAN son los ejemplos más antiguos. Java APIs son ejemplos más nuevos. El reuso es una cualidad difícil (¿imposible?) de conseguir a posteriori. La orientación a objetos tiene el potencial para mejorar la reutilización y la evolución. También los patrones de arquitectura y el desarrollo de familias de productos.

Portable Un software es portable si puede ejecutarse en distintos ambientes (hardware, sistemas operativos, etc.). Una forma de lograr portabilidad es suponer la mínima configuración. Esto penaliza los sistemas que podrían ejecutar mejor haciendo uso del ambiente disponible. Otra opción es determinar sobre la marcha las disponibilidades del ambiente.

Interoperable Un sistema es interoperable si puede coexistir y cooperar con otros sistemas. Las componentes reutilizables son (deben ser) inherentemente interoperables. La estandarización de las interfaces promueve la interoperabilidad. Los sistemas abiertos son casos típicos de sistemas interoperables.

Productivo La productividad es la eficiencia del proceso de desarrollo del software. La productividad de un equipo de desarrollo es generalmente menor que la suma de las productividades individuales. Existen métricas para medir la productividad (LOC, puntos de función, etc.). La automatización y el soporte de software de desarrollo aumentan la productividad.

A Tiempo El proceso de desarrollo debe obtener su producto en el tiempo planeado. Tener el producto a tiempo da, en general, una mejor oportunidad comercial, y a veces hace que el producto sea útil o inútil. Tener un producto a tiempo sin confiabilidad o eficiencia tampoco es útil. Requiere: planificación estimación del trabajo hitos verificables

Visible Un proceso de desarrollo de software es visible si todos sus pasos están claramente documentados, y se puede saber su estado de avance en cada momento. Diseño, testing, codificación e integración pueden suceder simultáneamente, pero deben coordinarse. La visibilidad ayuda a evaluar el impacto de las decisiones. También es esencial cuando existe rotación en el personal.

Cohesión Medida de la relación entre las partes de una componente. Coincidental: no relacionados. Lógica: funciones similares. Temporal: ejecución simultánea. Procedural: secuencia de control. Comunicacional: comparten el input. Secuencial: output de uno es input del otro. Funcional: todas las partes son necesarias para la función. Objeto: todas las acciones actúan sobre los mismos datos del objeto.

Acoplamiento Medida de la interdependencia de distintas componentes. Módulo A Módulo B Módulo C Módulo D Área de datos compartidos Medida de la interdependencia de distintas componentes. Sistemas muy acoplados comparten variables o información de control. Sistemas desacoplados interfaces definidas con listas de parámetros. Módulo A Datos de A Módulo B Datos de B Módulo C Datos de C Módulo D Datos de D

Comprensible Un sistema es comprensible si es fácil comprender cómo funciona. Características que afectan la comprensibilidad del sistema: cohesión y acoplamiento nombres documentación complejidad Si un sistema es comprensible, es también más mantenible y verificable. Desde el punto de vista del usuario, ser comprensible es ser amigable y robusto.

Mantenible Un sistema es mantenible si es fácil modificarlo. Tipos de mantenimiento: correctivo (aprox. 20%) adaptativo (aprox. 20%) perfectivo (más de 50%) Software Mantenible: reparable: que permite corregir defectos, evolucionable: facilita la introducción de nuevas funcionalidades. Condiciones: número de componentes, acoplamiento, documentación completa, comprensible, al día, uso de componentes estándar. La evolucionabilidad decrece con cada versión del software.