UNIVERSIDAD NACIONAL DE LOJA

REA DE LA ENERGA, LAS INDUSTRIAS Y LOS RECURSOS NATURALES NO RENOVABLES

CARRERA DE INGENIERA EN SISTEMAS

MDULO IX INGENIERA DE SOFTWARE

INTEGRANTES:
Chinchay Marjorie Herrera Karla Largo Elivar Michay Franklin Rodrguez Gabriela

DOCENTE:
Ing. Roberto Jcome

PARALELO:

LOJA ECUADOR 2013

CICLO DE VIDA CLSICO DEL SOFTWARE

1. FASE DE ANLISIS a). Investigacin Preliminar.- Tiene como finalidad buscar la informacin suficiente para determinar si se debe continuar con el Ciclo de Vida del Desarrollo del Sistema. En la investigacin preliminar se deben satisfacer los siguientes aspectos: Aclarar y comprender la solicitud del proyecto. Definir el alcance y las restricciones o limitaciones del sistema. Identificar los beneficios que se obtendran si el sistema propuesto es completado Especificar un estimado de tiempo y costo para las prximas fases de desarrollo. Presentar un informe a la gerencia describiendo el problema y detallando si se recomienda continuar con la fase de anlisis del sistema.

b). Estudio de factibilidad Factibilidad Operacional: Se refiere al hecho de que si trabajar o no el sistema si este se llega a desarrollar Factibilidad Tcnica: Se refiere a los recursos necesarios como herramientas, conocimientos, habilidades, experiencia, que son necesarios para efectuar las actividades o procesos que requiere el proyecto. Factibilidad Financiera y Econmica: Se refiere a los recursos econmicos y financieros necesarios para desarrollar o llevar a cabo las actividades o procesos y/o para obtener los recursos bsicos que deben considerarse son el costo del tiempo, el costo de la realizacin y el costo de adquirir nuevos recursos. [1] c). Anlisis de requerimientos Es analizar y afinar los requerimientos, con el fin de conseguir la comprensin detallada de los requerimientos primordiales para desarrollar un producto de software correcto y de fcil mantenimiento. Los requerimientos deben estar expresados en el lenguaje natural para que estos puedan ser entendidos por el cliente y las personas que manejaran el mismo. d). Requerimientos del Sistema

Estos especifican lo que el sistema de informacin deber hacer o cules propiedades o cualidades debe de tener. Requerimientos Funcionales.- Son los que especifican lo que el sistema de informacin debe hacer. Requerimientos no Funcionales.- Son los que especifican una propiedad o cualidad que el sistema debe tener.

Es analizar y afinar los requerimientos, con el fin de conseguir la comprensin detallada de los requerimientos primordiales para desarrollar un producto de software correcto y de fcil mantenimiento. Los requerimientos deben estar expresados en el lenguaje del cliente. Identificacin de Requerimientos.-El analista de sistema debe utilizar tcnicas de recopilacin de informacin como la entrevista, encuesta u observacin para poder definir correctamente los requerimientos que debe cumplir la aplicacin de software a desarrollar. Especificacin de los requerimientos.- Consiste en la redaccin clara y correcta de los requerimientos del sistema en lo que se conoce como documento de requerimientos los cuales deben reunir las siguientes caractersticas: Definidos sin ambigedad Ser completos Tener consistencia Evitar describir detalles de diseo Estar enumerados [2]

2. FASE DE DISEO a). Diseo del Sistema El Diseo del Sistemas se define con el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica. El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y debe acumular todos los requisitos implcitos que desea el cliente. La importancia del Diseo del Software se puede definir en una sola palabra Calidad, dentro del diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de materializar con precisin los requerimientos del cliente. El proceso de diseo representa los requerimientos en una forma que permita la codificacin del producto (adems de una evaluacin de la calidad previa a la etapa de codificacin). Al igual que los requerimientos, el diseo es documentado y se convierte en parte del producto de software.

Etapas: El diseo de los datos. El Diseo Arquitectnico. El Diseo de la Interfaz. El Diseo de procedimientos. Dependiendo de la metodologa utilizada para esta fase se utiliza algunas herramientas de modelado o diagramas UML entre los que podemos destacar son: Diagramas de clases, Diagramas de Casos de Uso. 3. FASE DE IMPLEMENTACIN Es la fase ms costosa y que consume ms tiempo, se dice que es costosa porque muchas personas, herramientas y recursos, estn involucrados en el proceso y consume mucho tiempo porque se completa todo el trabajo realizado previamente durante el ciclo de vida. Las actividades que se cumplen en esta fase son: Definir la organizacin del cdigo en trminos de subsistemas estructurados en capas. Implementar (codificar y estructurar) clases y objetivos en trminos de componentes (cdigo fuente, ejecutables, bases de datos, etcteras. Integrar los resultados producidos por desarrolladores individuales y equipos en un sistema ejecutable. En la implementacin se instala el nuevo sistema de informacin para que empiece a trabajar y se capacita a sus usuarios para que puedan utilizarlo. La instalacin puede realizarse segn cuatro mtodos: Directo, paralelo, piloto y en fases. Mtodo directo: Se abandona el sistema antiguo y se adopta inmediatamente el nuevo. Esto puede ser sumamente riesgoso porque si algo marcha mal, es imposible volver al sistema anterior, las correcciones debern hacerse bajo la marcha. Regularmente con un sistema nuevo suelen surgir problemas de pequea y gran escala. Si se trata de grandes sistemas, un problema puede significar una catstrofe, perjudicando o retrasando el desempeo entero de la organizacin. Mtodo paralelo: Este mtodo es de bajo riesgo. Si el sistema nuevo falla, la organizacin puede mantener sus actividades con el sistema antiguo. Pero puede representar un alto costo al requerir contar con personal y equipo para laborar con los dos sistemas, por lo que este mtodo se reserva especficamente para casos en los que el costo de una falla sera considerable. Mtodo piloto: Pone a prueba el nuevo sistema slo en una parte de la organizacin. Al comprobar su efectividad, se implementa en el resto de la organizacin. El mtodo es menos costoso que el paralelo, aunque ms riesgoso. Pero en este caso el riesgo es controlable al limitarse a ciertas reas, sin afectar toda la empresa.

Mtodo en fases: La implementacin del sistema se divide en partes o fases, que se van realizando a lo largo de un periodo de tiempo, sucesivamente. Una vez iniciada la primera fase, la segunda no se inicia hasta que la primera se ha completado con xito. As se contina hasta que se finaliza con la ltima fase. Es costoso porque se hace ms lenta la implementacin, pero sin duda tiene el menor riesgo. Los mtodos piloto y en fases suelen ser los ms practicados puesto que tienen menor riesgo. Como se puede observar la decisin de adoptar cualquiera de los mtodos estar influenciada por factores de riesgo y disponibilidad de recursos. Otro aspecto importante de esta fase es la capacitacin del personal, que cobra especial importancia para asegurar el uso acertado del sistema. Se puede adelantar camino al capacitar personal, antes incluso de contar con los equipos nuevos, para que el usuario se familiarice con el nuevo sistema. Si el sistema es sencillo y el usuario tiene cierta 4. FASE DE PRUEBAS Las pruebas de software son las investigaciones empricas y tcnicas cuyo objetivo es proporcionar informacin objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Pruebas Dinmicas Estticas: Son aquellas que implican ejecucin de los programas y puede adoptar cualquiera de los mtodos y estrategias descritas anteriormente. Se lleva a cabo siguiendo tres pasos: Seleccin de casos de prueba. Ejecucin de la prueba. Anlisis de los resultados. Son aquellas que centran su atencin en la estructura de los programas o en su lgica, no en los resultados. Puede ser de tres tipos: Anlisis de flujo de control: detecta cdigo no estructurado o inalcanzable. Anlisis de flujo de datos: determina las anomalas en el uso de los datos y variables. Anlisis de interfaces: evidencia cualquier discrepancia entre los parmetros que se envan desde un mdulo y la forma en que el mdulo receptor est preparado para recibirlos.

1. Prueba Unitaria: Es la que se hace de un solo programa o mdulo. El programador es el responsable de realizar esta prueba y se lleva a cabo en el ambiente de desarrollo.

2. Prueba de Integracin: Es la que se hace de las interfaces que existen entre programas dentro de un procedimiento con el fin de detectar cualquier problema de intercambio de datos, archivos o parmetros y asegurar que pueden ser ejecutados en el orden o secuencia requeridos. Normalmente el mtodo ms usado para realizar estas pruebas es de Arriba hacia Abajo. Es realizada por el analista del proyecto y el equipo de desarrollo en el ambiente de prueba.

3. Prueba Funcional: Su propsito es identificar las discrepancias que pueden existir entre el sistema y sus especificaciones funcionales. Es realizada por el analista del proyecto y el equipo de desarrollo en el ambiente de prueba. 4. Prueba de Sistema: Es el complemento de la prueba funcional y est dirigida a probar los aspectos tcnicos del sistema para poner en evidencia discrepancias con respectos a sus Casos, un conjunto de situaciones o condiciones ante las cuales un programa debe responder satisfactoriamente para que pueda afirmarse que cumple con sus especificaciones u objetivos. Los datos de prueba se derivan de los casos de prueba ya que ellos son los valores que se escogen para particularizar cada caso de prueba. Un buen caso de prueba es el que tiene alta probabilidades de detectar errores, no el que simplemente demuestra que los programas funcionan. Al preparar un caso de prueba deben ser especificados los resultados que se esperan. Deben ser preparados tanto para condiciones vlidas como invlidas. Objetivos La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error Un buen caso de prueba es aquel que tiene una alta probabilidad demostrar un error no descubierto hasta entonces. Una prueba tiene xito si descubre un error no detectado hasta entonces. El objetivo es disear casos de prueba que, sistemticamente, saquen a la luz diferentes clases de errores, hacindolo con la menor cantidad de tiempo y de esfuerzo. La prueba no puede asegurar la ausencia de errores; slo puede demostrar que existen defectos en el software. Proceso de prueba El proceso de prueba tiene dos entradas: Configuracin del software: Incluye la especificacin de requisitos del software, la especificacin del diseo y el cdigo fuente Configuracin de prueba: Incluye un plan y un procedimiento de prueba. Si el funcionamiento del software parece ser correcto y los errores encontrados son fciles de corregir.

Se trata de disear pruebas que tengan la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y de tiempo. Cualquier producto de ingeniera se puede probar de dos formas: Pruebas de caja negra: Realizar pruebas de forma que se compruebe que cada funcin es operativa. Pruebas de caja blanca: Desarrollar pruebas de forma que se asegure que la operacin interna se ajusta a las especificaciones, y que todos los componentes internos se han probado de forma adecuada.

En la prueba de la caja negra, los casos de prueba pretenden demostrar que las funciones del software son operativas, que la entrada se acepta de forma adecuada y que se produce una salida correcta. En la prueba de caja blanca se realiza un examen minucioso de los detalles procedimentales, comprobando los caminos lgicos del programa, comprobando los bucles y condiciones, y examinado el estado del programa en varios puntos. Pruebas de Cajas Blancas La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para derivar los casos de prueba. Las pruebas de caja blanca intentan garantizar que: Se ejecutan al menos una vez todos los caminos independientes de cada mdulo Se utilizan las decisiones en su parte verdadera y en su parte falsa Se ejecuten todos los bucles en sus lmites Se utilizan todas las estructuras de datos internas

5. MANTENIMIENTO DEL SOFTWARE En ingeniera del software, el mantenimiento de software es la modificacin de un producto de software despus de la entrega, para corregir errores, mejorar el rendimiento, u otros atributos. El mantenimiento del software es una de las actividades ms comunes en la ingeniera de software. Perfectivo: Mejora del software (rendimiento, flexibilidad, reusabilidad) o implementacin de nuevos requisitos. Tambin se conoce como mantenimiento evolutivo. Adaptativo: Adaptacin del software a cambios en su entorno tecnolgico (nuevo hardware, otro sistema de gestin de bases de datos, otro sistema operativo) Correctivo: Correccin de fallos detectados durante la explotacin. Preventivo: Facilitar el mantenimiento futuro del sistema. 6. VENTAJAS Y DESVENTAJAS: El ciclo de vida clsico es el paradigma ms viejo y el ms ampliamente usado en la ingeniera del software. Sin embargo, su aplicabilidad en muchos campos ha sido cuestionada. Entre los problemas que aparecen cuando se aplica el modelo cascada estn:

No aplica la iteracin: Los proyectos raramente siguen el flujo secuencial que el modelo propone. La iteracin siempre es necesaria y est presente, creando problemas en la aplicacin del modelo. Requerimientos no especificados adecuadamente: A menudo es difcil para el cliente poder especificar todos los requerimientos explcitamente. El modelo de vida del software clsico requiere esto y presenta problemas acomodando la incertidumbre natural que existe al principio de cualquier proyecto. No hay entregas funcionales: Una versin funcional del sistema no estar disponible hasta tarde en la duracin del desarrollo. Cualquier error o malentendido, si no es detectado hasta que el programa funcionando es revisado, puede ser desastroso. Cada uno de estos problemas es real, sin embargo, el modelo clsico del ciclo de vida del software tiene un lugar bien definido e importante en los trabajos de ingeniera del

software. Este modelo se aplica bien en situaciones en las que el software es simple y en las que el dominio de requerimientos es bien conocido, la tecnologa usada en el desarrollo es accesible y los recursos estn disponibles. BIBLIOGRAFIA [1] DEL POZO, Eugenio y Otros, Fases de un proceso de desarrollo de software, Instituto tecnolgico de las Amricas ITLA, [07-09-2010], [21-09-2013], En lnea disponible de: [http://s3.amazonaws.com/pptdownload/fasesdeunproyectodedesarrollodesoftware-100911101424phpapp02.pdf?response-contentdisposition=attachment&Signature=cArfBArHl0hct%2B8s82B7V2nQdnc%3D&Expir es=1379867581&AWSAccessKeyId=AKIAIW74DRRRQSO4NIKA] [2] ZULOAGA ROTTA, Luis, Anlisis de Requerimientos, [21-09-2013], En lnea disponible de: [http://www.galeon.com/zuloaga/Doc/AnalisisRequer.pdf] [3] Nahama Fernndez, Diseo de Sistemas, Instituto Universitario de Tecnologa de Administracin Industrial (IUTA GUARENAS),[12-02-2012], [22-09-2013], En lnea disponible de: [http://www.infcr.uclm.es/www/mpolo/asig/0708/phd/apuntesDoctorado.pdf]