INTEGRANTES: Johanna Zambrano Alcvar Josefa Velsquez Orellana Jessenia Zambrano Cedeo

OBJETIVO: Actividades relacionadas con la Ingeniera de requerimientos del software, desarrollo, pruebas y evolucin.

Conjunto de actividades que conducen a la creacin de un producto SOFTWARE, pudiendo ser desde cero en un lenguaje de programacin estndar como Java o C. Son 4: 1. Especificacin del software. 2. Diseo e implementacin. 3. Validacin. 4. Evolucin.

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 especfica 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 crtica ya que los errores originaran problemas posteriores en el diseo e implementacin del sistema.

1. Estudio de viabilidad.- Estimacin 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 econmico y rpido, siendo as que en el resultado se informe si se continuar con un anlisis ms detallado.

2. Obtencin y anlisis de los requerimientos.Por medio de la observacin de los sistemas existentes, discusiones con usuarios y proveedores, etc. se pueden obtener los requerimientos del sistema, pudindose desarrollar uno o ms modelos y prototipos del sistema. 3. Especificacin de requerimientos.- Es traducir la informacin recopilada durante el anlisis 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 descripcin ms detallada de la funcionalidad a proporcionar.

4. Validacin 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 diseo de software es una descripcin 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 diseos anteriores para corregirlos. Puede implicar el desarrollo de varios modelos con diferentes niveles de abstraccin, mientras se descompone un diseo se descubren los errores, as mejorando los modelos de diseo previos.

1. Diseo arquitectnico. Los subsistemas que forman el sistema y sus relaciones se identifican y documentan. 2. Especificacin abstracta. Para cada subsistema se produce una especificacin abstracta de sus servicios y las restricciones bajo las cuales debe funcionar. 3. Diseo de la interfaz. Para cada subsistema se disea y documenta su interfaz con otros subsistemas. Esta especificacin de la interfaz debe ser inequvoca ya que permite que el subsistema se utilice sin conocimiento de su funcionamiento. 4. Diseo de componentes. Se asignan servicios a los componentes y se disean sus interfaces. 5. Diseo de la estructura de datos. Se disea en detalle y especifica la estructura de datos utilizada en la implementacin del sistema. 6. Diseo de algoritmos. Se disean en detalle y especifican los algoritmos utilizados para proporcionar los servicios.

La programacin es una actividad personal y no existe un proceso general que se siga comnmente. Algunos programadores empiezan con los componentes que comprenden, los desarrollan y despus continan 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 cdigo que han desarrollado. A menudo esto muestra defectos en el programa que se deben eliminar del mismo. Esto se denomina depuracin. Las pruebas y la depuracin de defectos son procesos diferentes. Las pruebas establecen la existencia de defectos. La depuracin comprende la localizacin y correccin de estos defectos.

Localizar error

Disear la reparacin del error

Reparacin del error

Volver a probar el programa

El proceso de depuracin es parte tanto del desarrollo como de las pruebas del software. Al depurar, se generan hiptesis acerca del comportamiento en el programa; despus, se prueban estas hiptesis y encontrar el defecto que origina la anomala en la salida. Pueden escribirse nuevos casos de pruebas para localizar el problema. Para ayudar al proceso de depuracin, se pueden utilizar herramientas de depuracin 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 especificacin y que cumple las expectativas del usuario que lo comprar. Implica procesos de comprobacin, como las inspecciones y revisiones en cada etapa del proceso del software desde la definicin 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 integracin 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 aceptacin. 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 definicin de requerimientos del sistema. Tambin problemas en los requerimientos donde los recursos del sistema no cumplen las necesidades del usuario o donde el desempeo del sistema es inaceptable.