You are on page 1of 15

INTEGRANTES: • Johanna Zambrano Alcívar • Josefa Velásquez Orellana • Jessenia Zambrano Cedeño

OBJETIVO: Actividades relacionadas con la Ingeniería de requerimientos del software, desarrollo, pruebas y evolución.

Conjunto de actividades que conducen a la creación de un producto SOFTWARE, pudiendo ser desde cero en un lenguaje de programación estándar como Java o C. Son 4: 1. Especificación del software. 2. Diseño e implementación. 3. Validación. 4. Evolución.

Se organizan de forma distinta en los diferentes procesos, en el cascada se organizan en secuencia, en cambio en el de desarrollo evolutivo van entrelazadas. Las actividades dependen del tipo de software, de las personas y de la estructura organizacional, sin que exista una forma específica de organizarlas.

En esta etapa se va a comprender y definir que servicios se requiere e identificar las restricciones de funcionamiento y desarrollo del mismo. Esta etapa es crítica ya que los errores originaran problemas posteriores en el diseño e implementación del sistema.

1. Estudio de viabilidad.- Estimación de las necesidades del usuario que se puedan satisfacer con las actuales tendencias de software y hardware. Se analizará si el sistema propuesto es rentable y si se puede desarrollar dentro del presupuesto. Debe ser económico y rápido, siendo así que en el resultado se informe si se continuará con un análisis más detallado.

2. Obtención y análisis de los requerimientos.Por medio de la observación de los sistemas existentes, discusiones con usuarios y proveedores, etc. se pueden obtener los requerimientos del sistema, pudiéndose desarrollar uno o más modelos y prototipos del sistema. 3. Especificación de requerimientos.- Es traducir la información recopilada durante el análisis en un documento, se pueden incluir dos tipos de requerimientos: el de usuario son declaraciones abstractas de los requerimientos del cliente y del usuario final, y los del sistema son una descripción más detallada de la funcionalidad a proporcionar.

4. Validación de requerimientos.-Es la que comprueba la veracidad, consistencia y completitud de los requerimientos. Durante este proceso es inevitable que se descubran errores, se deben modificar para corregirlos.

Un diseño de software es una descripción de la estructura del mismo donde se van a implementar los datos que son parte del sistema, las interfaces entre los componentes del sistema y algunas veces los algoritmos utilizados. Este proceso conlleva agregar formalidad y detalle durante el desarrollo y regresar a los diseños anteriores para corregirlos. Puede implicar el desarrollo de varios modelos con diferentes niveles de abstracción, mientras se descompone un diseño se descubren los errores, así mejorando los modelos de diseño previos.

1. Diseño arquitectónico. Los subsistemas que forman el sistema y sus relaciones se identifican y documentan. 2. Especificación abstracta. Para cada subsistema se produce una especificación abstracta de sus servicios y las restricciones bajo las cuales debe funcionar. 3. Diseño de la interfaz. Para cada subsistema se diseña y documenta su interfaz con otros subsistemas. Esta especificación de la interfaz debe ser inequívoca ya que permite que el subsistema se utilice sin conocimiento de su funcionamiento. 4. Diseño de componentes. Se asignan servicios a los componentes y se diseñan sus interfaces. 5. Diseño de la estructura de datos. Se diseña en detalle y especifica la estructura de datos utilizada en la implementación del sistema. 6. Diseño de algoritmos. Se diseñan en detalle y especifican los algoritmos utilizados para proporcionar los servicios.

La programación es una actividad personal y no existe un proceso general que se siga comúnmente. Algunos programadores empiezan con los componentes que comprenden, los desarrollan y después continúan con los que comprenden menos. Algunos desarrolladores prefieren definir los datos al inicio del proceso y los utilizan para conducir el desarrollo del programa; otros dejan los datos sin especificar tanto como sea posible. Normalmente, los programadores llevan a cabo algunas pruebas del código que han desarrollado. A menudo esto muestra defectos en el programa que se deben eliminar del mismo. Esto se denomina depuración. Las pruebas y la depuración de defectos son procesos diferentes. Las pruebas establecen la existencia de defectos. La depuración comprende la localización y corrección de estos defectos.

Localizar error

Diseñar la reparación del error

Reparación del error

Volver a probar el programa

El proceso de depuración es parte tanto del desarrollo como de las pruebas del software. Al depurar, se generan hipótesis acerca del comportamiento en el programa; después, se prueban estas hipótesis y encontrar el defecto que origina la anomalía en la salida. Pueden escribirse nuevos casos de pruebas para localizar el problema. Para ayudar al proceso de depuración, se pueden utilizar herramientas de depuración interactiva que muestran los valores intermedios de las variables del programa y una traza de las sentencias ejecutadas.

Se utiliza para mostrar que el sistema se ajusta a su especificación y que cumple las expectativas del usuario que lo comprará. Implica procesos de comprobación, como las inspecciones y revisiones en cada etapa del proceso del software desde la definición de requerimientos hasta el desarrollo del programa. Existe un proceso de pruebas de tres etapas en el cual se prueban los componentes del sistema, la integración del sistema y, finalmente, el sistema con los datos del cliente. En el mejor de los casos, los defectos se descubren en las etapas iniciales del proceso y los problemas con la interfaz, cuando el sistema se integra.

1. Prueba de componentes . Se prueban los componentes individuales para asegurarse de que funcionan correctamente de forma independiente, sin los otros componentes. Los componentes pueden ser entidades simples como funciones o clases de objetos, o pueden ser agrupaciones de estas entidades. 2. Prueba del sistema. Los componentes se integran para formar el sistema. Comprende encontrar errores que son el resultado de interacciones no previstas entre los componentes y su interfaz. Se valida que el sistema cumpla sus requerimientos funcionales y no funcionales. Para sistemas grandes, esto puede ser un proceso gradual en el cual los componentes se integran para formar subsistemas que son probados individualmente antes de que ellos mismos se integren para formar el sistema final. 3. Prueba de aceptación. Es la etapa final en el proceso de pruebas antes de que se acepte que el sistema se ponga en funcionamiento. Se prueba con los datos proporcionados por el cliente y con datos de prueba simulados. Debido a la diferencia existente entre los datos reales y los de prueba, puede revelar errores y omisiones en la definición de requerimientos del sistema. También problemas en los requerimientos donde los recursos del sistema no cumplen las necesidades del usuario o donde el desempeño del sistema es inaceptable.