• Author / Uploaded
• Noel Pérez

• Categories
• Pruebas de software
• Software
• Objeto (informática)
• Ingeniería de software
• Informática

Citation preview

República Bolivariana de Venezuela Ministerio del Poder Popular para la Educación Universitaria Instituto Universitario Politécnico “Santiago Mariño” Extensión Puerto Ordaz Escuela de Ingeniería de Sistemas

Profesor(a): Ing. Richard Rodríguez

Alumno: Noel Pérez C.I: V-21.124.293

Ciudad Guayana, Enero del 2013

Introducción En la ingeniería de sistemas y la ingeniería de software, la Ingeniería de requisitos o Ingeniería de requerimientos1 comprende todas las tareas relacionadas con la determinación de las necesidades o de las condiciones a satisfacer para un software nuevo o modificado, tomando en cuenta los diversos requisitos de los inversores, que pueden entrar en conflicto entre ellos. Muchas veces se habla de requerimientos en vez de requisitos; esto se debe a una mala traducción del inglés. La palabra requirement debe ser traducida como requisito, mientras que requerimiento se traduce al inglés como request. El propósito de la ingeniería de requisitos es hacer que los mismos alcancen un estado óptimo antes de alcanzar la fase de diseño en el proyecto. Los buenos requisitos deben ser medibles, comprobables, sin ambigüedades o contradicciones, etc.

Análisis y Diseño Orientado a Objetos Es un método de análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del problema. El Análisis orientado a objetos ofrece un enfoque nuevo para el análisis de requisitos de sistemas software. En lugar de considerar el software desde una perspectiva clásica de entrada/proceso/salida, como los métodos estructurados clásicos, se basa en modelar el sistema mediante los objetos que forman parte de él y las relaciones estáticas (herencia y composición) o dinámicas (uso) entre estos objetos. El uso de Análisis orientado a objetos puede facilitar mucho la creación de prototipos, y las técnicas de desarrollo evolutivo de software. Los objetos son inherentemente reutilizables, y se puede crear un catálogo de objetos que podemos usar en sucesivas aplicaciones. De esta forma, podemos obtener rápidamente un prototipo del sistema, que pueda ser evaluado por el cliente, a partir de objetos analizados, diseñados e implementados en aplicaciones anteriores. Y lo que es más importante, dada la facilidad de reutilización de estos objetos, el prototipo puede ir evolucionando hacia convertirse en el sistema final, según vamos refinando los objetos de acuerdo a un proceso de especificación incremental.

Análisis de requisitos del software La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software. Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos – un conjunto de actividades que son denominadas

análisis – El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como interrogador, como consultor, como persona que resuelve problemas y como negociador. El análisis y la especificación de requisitos pueden parecer una tarea relativamente sencilla, pero las apariencias engañan. El contenido de comunicación es muy denso. Abundan las ocasiones para malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero de software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: “Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir”. El análisis de requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño de software. El análisis de requerimientos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software.

Tareas de Análisis El análisis de requisitos del software se puede subdividir en cinco áreas de esfuerzo: 

Reconocimiento del problema



Evaluación y síntesis



Modelado



Especificación



Revisión

Todos los métodos de análisis se relacionan por un conjunto de principios operativos: 

Debe representarse y entenderse el dominio de la información de un problema.



Deben definirse las funciones que debe realizar el software.



Debe

representarse

el

comportamiento

del

software

(como

consecuencia de acontecimientos externos), 

Deben dividirse los modelos que representan información, función y comportamiento de manera que se descubran los detalles por capas (o jerárquicamente).



El proceso de análisis debería ir desde la información esencial hasta el detalle de la implementación. Además de los principios operativos mencionados anteriormente, se

sugiere un conjunto de principios directrices para la ingeniería de requerimientos: 

Entender el problema antes de empezar a crear el modelo de análisis.



Desarrollar prototipos que permitan al usuario entender como será la interacción hombre-máquina.



Registrar el orden y la razón de cada requerimiento,



Usar múltiples planteamientos de requerimientos.



Priorizar los requerimientos.



Trabajar para eliminar la ambigüedad. Un ingeniero de software que se apegue a estos principios es muy

probable que desarrolle una especificación de software que represente un excelente fundamento para el diseño.

Métodos de Análisis Orientados al Flujo de Datos La información se transforma como un flujo a través de un sistema basado en computadora. El sistema acepta entrada de distintas formas; aplica un hardware, software y elementos humanos para transformar la entrada en salida; y produce una salida en distintas formas. La entrada puede ser una señal de control transmitida por un transductor, una serie de números escritos por un operador humano, un paquete de información transmitido por un enlace a red, o un voluminoso archivo de datos almacenado en memoria secundaria. La transformación puede comprender una sencilla comparación lógica, un complejo algoritmo numérico, o un método de inferencia basado en regla de un sistema experto. La salida puede encender un sencillo led o producir un informe de 200 páginas. En efecto, un modelo de flujo de datos puede aplicarse a cualquier sistema basado en computadora independientemente del tamaño o complejidad. Diagramas de Flujos de Datos Conforme con la información se mueve a través del software, se modifica mediante una serie de transformaciones. Un diagrama de flujos de datos (DFD), es una técnica grafica que describe el flujo de información y las transformaciones que se aplican a los datos, conforme se mueven de la entrada a la salida. Diccionario de Datos Un análisis del dominio de la información puede ser incompleto si solo se considera el flujo de datos. Cada flecha de un diagrama de flujo de datos representa uno o más elementos de información. Por tanto, el analista debe disponer de algún otro método para representar el contenido de cada flecha de un DFD. Se ha

propuesto el diccionario de datos como una gramática casi formal para describir el contenido de los elementos de información y ha sido definido da la siguiente forma: El diccionario de datos contiene las definiciones de todos los datos mencionados en el DFD, en una especificación del proceso y en el propio diccionario de datos. Los datos compuestos (datos que pueden ser además divididos) se definen en términos de sus componentes; los datos elementales (datos que no pueden ser divididos) se definen en términos del significado de cada uno de los valores que puede asumir. Por tanto, el diccionario de datos esta compuesto de definiciones de flujo de datos, archivos [datos almacenados] y datos usados en los procesos [transformaciones]…

Desarrollo del Sistema Jackson Desarrollo del sistema de Jackson ( JSD ) es un lineal metodología de desarrollo de software desarrollado por Michael A. Jackson y John Cameron en la década de 1980. Principios de funcionamiento Tres principios básicos del funcionamiento de JSD es que: 1. El desarrollo debe comenzar con la descripción y el modelado del mundo real, en lugar de especificar o la estructuración de la función realizada por el sistema. Un sistema realizado utilizando el método de JSD realiza la simulación del mundo real antes de que se le prestó atención directa a la función o propósito del sistema. 2. Un modelo adecuado de un mundo ordenado por tiempo en sí mismo debe ser ordenado por tiempo. El principal objetivo es mapear el progreso en el mundo real sobre los avances en el sistema que modela.

3. La manera de aplicar el sistema se basa en la transformación de especificación en conjunto eficiente de los procesos. Estos procesos deben ser diseñados de tal manera que sería posible ejecutar en software y hardware disponible. Etapa de modelado En la etapa de modelado el diseñador crea una colección de diagramas de estructura de la entidad y se identifican las entidades en el sistema, las acciones que realizan, el tiempo-orden de las acciones en la vida de las entidades y los atributos de las acciones y entidades. Estructura de la entidad diagramas utilizan la notación de diagramas de Jackson Programación Estructurada diagramas de estructura . Propósito de estos diagramas es crear una descripción completa de los aspectos del sistema y de la organización. Los desarrolladores tienen que decidir qué cosas son importantes y cuáles no lo son. La buena comunicación entre los desarrolladores y los usuarios del nuevo sistema es muy importante. Esta etapa es la combinación de la etapa anterior entidad / acción y el paso de las estructuras de entidad. Etapa Red En la fase de red de un modelo del sistema como un todo se desarrolla y se representa como un diagrama de especificación del sistema (SSD) (también conocido como un diagrama de la red ). Diagramas de red muestran procesos (rectángulos) y la forma en que se comunican entre sí, ya sea a través del vector de estado de conexiones (de diamantes) o por medio de flujo de datos en las conexiones (círculos). En esta etapa es la funcionalidad del sistema definido. Cada entidad se convierte en un proceso o programa en el diagrama de red. Programas externos posteriormente, se

agregan a los diagramas de red. El propósito de estos programas es el de procesar la entrada, calcular la producción y mantener los procesos de la entidad hasta a la fecha. Todo el sistema se describe con estos diagramas de red y se completan con las descripciones acerca de los datos y las conexiones entre los procesos y programas. El paso inicial del modelo especifica una simulación del mundo real. El paso función añade a esta simulación las operaciones y procesos ejecutables adicionales necesarias para producir una salida del sistema. Paso el tiempo del sistema proporciona la sincronización entre procesos, presenta limitaciones. Esta etapa es la combinación de la primera etapa "modelo inicial", el paso de la "función" y el "sistema de temporización 'paso.

Etapa de implementación En la etapa de implementación del modelo de red abstracto de la solución se convierte en un sistema físico, representado como un diagrama de implementación del sistema (SID). El SID muestra el sistema como un planificador de proceso que llama módulos que implementan los procesos. Datastreams se representan como llamadas a procesos invertidos. Símbolos de bases de datos representan colecciones de entidades estatales-vectores, y hay símbolos especiales para los archivos de memoria intermedia (que deben aplicarse cuando los procesos están programados para ejecutarse en diferentes intervalos de tiempo). La preocupación central de paso es la aplicación de optimización del sistema. Es necesario reducir el número de procesos, ya que es imposible proporcionar cada proceso que está contenida en la especificación con su propio procesador virtual. Por medio de la transformación, los procesos se combinan con el fin de los límites de sus miembros para que el número de procesadores.

Fundamentos de la Programación Orientada a Objetos Objeto Entidad que contiene los atributos que describen el estado de un objeto del mundo real y las acciones que se asocian con el objeto del mundo real. Un objeto es designado con un nombre o un identificador. Abstracción Es el principio de ignorar aquellos aspectos de un fenómeno observado que no son relevantes, con el objetivo de

concentrarse en

aquellos que si lo son. Encapsulamiento Es la propiedad del POO que permite ocultar al mundo exterior la representación interna del objeto. Esto quiere decir que el objeto puede ser utilizado, pero los datos esenciales del mismo no son conocidos fuera de él. La idea central del encapsulamiento es esconder los detalles y mostrar lo relevante. Permite el ocultamiento de la información separando el aspecto correspondiente a la especificación de la implementación; de esta forma, distingue el "qué hacer" del "cómo hacer". La especificación es visible al usuario, mientras que la implementación se le oculta. Modularidad Es la propiedad que permite tener independencia entre las diferentes partes de un sistema.

La modularidad consiste en dividir un programa en módulos o partes, que pueden ser compilados separadamente, pero que tienen conexiones con otros módulos. En un mismo módulo se suele colocar clases y objetos que guarden una estrecha relación. Jerarquía / Herencia Es el proceso mediante el cual un objeto de una clase adquiere propiedades definidas en otra clase que lo preceda en una jerarquía de clasificaciones. Permite la definición de un nuevo objeto a partir de otros, agregando las diferencias entre ellos (Programación Diferencial), evitando repetición de código y permitiendo la reusabilidad. Polimorfismo Es una propiedad del POO que permite que un método tenga múltiples implementaciones, que se seleccionan en base al tipo objeto indicado al solicitar la ejecución del método. Concurrencia La concurrencia es la propiedad que distingue un objeto activo de uno que no está activo. Se implementa mediante el proceso de creación o instanciación de objetos a partir de su clase y las propiedades de identidad y estado de los objetos. Persistencia La persistencia es la propiedad de un objeto mediante la cual su existencia perdura en el tiempo y/o espacio.

Se implementa mediante los procesos de construcción y destrucción de los objetos definidos como parte del comportamiento de la clase.

Garantías de calidad del software

Es una disciplina de la ingeniería de software se especializa en la aplicación de procesos de calidad a lo largo del proyecto de software.

Su misión no se limita a actividades de verificación, sino que además asume un rol de liderazgo en la gestión de la calidad durante el proceso de creación y diseño del producto. La garantía de calidad no debe confundirse con la técnica específica de control de calidad, cuyo objetivo es verificar el producto. Una concepción errónea que aún persiste en la industria, es limitar su acción al aseguramiento de la calidad del producto y a constatar adherencia a estándares. La garantía de calidad toma responsabilidad por los siguientes procesos: 1.

gestión de los procesos de ingeniería de software

2.

iniciativas de mejoramiento de procesos a lo largo de la organización,

3.

integración de los procesos de calidad de ingeniería y servicios a la clientela El liderazgo de la garantía de calidad puede ser asumida en

organizaciones pequeñas o muy jóvenes por el jefe del proyecto, siendo el grupo de desarrollo el responsable de su ejecución. Estos individuos pueden provenir de organizaciones más maduras donde hayan adquirido el "know-

how" en procesos de calidad, o pueden hacerse asesorar por consultores externos que los ayuden a definir sus sistema de calidad. La garantía de calidad se asegura de lo siguiente: 

Se usa la metodología de desarrollo apropiada



Las actividades de desarrollo han sido debidamente planeadas



Se han definido estándares y procedimientos para al proyecto



El personal ha sido debidamente entrenado en los procesos de calidad aplicables



Se llevan a cabo regularmente revisiones y auditorías independientes



El desarrollo es documentado adecuadamente para facilitar la mantención y la reutilización



La documentación se produce oportunamente y no después que el desarrollo ha sido completado



Los cambios introducidos han sido debidamente controlados



Las pruebas efectuadas son eficaces para detectar defectos, especialmente en aquellas áreas de mayor riesgo



Las actividades se llevan a cabo de acuerdo a los plazos y en los términos planeados



Las desviaciones a los estándares se identifican rápidamente



El proyecto está en condiciones para ser sometido a auditorías externas, si corresponde



La calidad es verificada con respecto a criterios preestablecidos



La gerencia es oportunamente informada de problemas y riesgos relativos a la calidad



Los problemas de calidad se analizan y las causas se comunican al proyecto para tomar medidas preventivas que eviten su repetición

Técnicas de Pruebas del Software Las pruebas de software (en inglés software testing) son las investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Es una actividad más en el proceso de control de calidad. Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software. Dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo. Existen distintos modelos de desarrollo de software, así como modelos de pruebas. A cada uno corresponde una nivel distinto de involucramiento en las actividades de desarrollo. Pruebas estáticas Son el tipo de pruebas que se realizan sin ejecutar el código de la aplicación (Ceferino). Puede referirse a la revisión de documentos, ya que no se hace una ejecución de código. Esto se debe a que se pueden realizar “pruebas de escritorio“ con el objetivo de seguir los flujos de la aplicación. Pruebas Dinámicas Todas aquellas pruebas que para su ejecución requieren la ejecución de la aplicación. Las pruebas dinámicas permiten el uso de técnicas de caja negra y caja blanca con mayor amplitud. Debido a la naturaleza dinámica de la ejecución

de

pruebas

es

posible

medir

comportamiento de la aplicación desarrollada.

con

mayor

precisión

el

Mantenimiento de Software El Servicio de mantenimiento de software es una de las actividades en la Ingeniería de Software y es el proceso de mejorar y optimizar el software desplegado (revisión del programa), así como también remediar los defectos. El mantenimiento de software es también una de las fases en el Ciclo de Vida de Desarrollo de Sistemas (SDLC ó System Development Life Cycle), que se aplica al desarrollo de software. La fase de mantenimiento es la fase que viene después del despliegue (implementación) del software en el campo. La fase de mantenimiento de software involucra cambios al software en orden de corregir defectos y dependencias encontradas durante su uso tanto como la adición de nueva funcionalidad para mejorar la usabilidad y aplicabilidad del software Tipos de mantenimiento A continuación se señalan los tipos servicio de mantenimientos existentes, y entre paréntesis el porcentaje aproximado respecto al total de operaciones de mantenimiento: Perfectivo: Mejora del software ( rendimiento , flexibilidad , reusabilidad ..) o implementación

de

nuevos

requisitos.

También

se

conoce

como

mantenimiento evolutivo . Adaptativo: Adaptación del software a cambios en su entorno tecnológico (nuevo hardware, otro sistema de gestión de bases de datos , otro sistema operativo ...) Correctivo: Corrección de fallos detectados durante la explotación.

Preventivo: Facilitar el mantenimiento futuro precondiciones, mejorar legibilidad...).

del sistema

(verificar

Conclusión A pesar de la importancia que tiene la Ingeniería de Requerimientos, ha costado mucho que se le preste la atención adecuada a esta actividad. Aún quedan muchos desafíos que deben ser mejorados, tales como la integración de requerimientos funcionales y no funcionales, la evaluación de especificaciones alternativas, la formalización de la SRS, entre otras. Cada actividad y técnica de la IR utilizada individualmente, dará diferentes soluciones para diferentes proyectos, incluyendo aquellos casos en los que el dominio y el área del problema son el mismo. Por esta razón, considero que no existe un modelo de proceso ideal para la IR; encontrar el método o la técnica perfecta es una ilusión, pues cada método y técnica ofrece diferentes soluciones ante un problema. En esta investigación se presentaron una serie de actividades y técnicas, que no pertenecen a un modelo de proceso en sí, sino, que son una alternativa al material publicado por diferentes autores y que, desde mi punto de vista, son las más importantes. Debemos recordar que la Ingeniería de Requerimientos es una actividad que involucra a clientes, usuarios, equipo de desarrollo, administradores de proyectos, etc.; por lo tanto, el proceso de IR no depende solamente de la forma en cómo se percibe el problema, sino también, del nivel de experiencia que tengan los involucrados.