jueves, 6 de agosto de 2009

Hola Esta es la Presentacion

http://www.youtube.com/watch?v=mWYT4i_QryI
Para leer todo nuestro informe o descargarlo puedes visitar:

http://es.calameo.com/read/00007615932935ea70efc

Marisol,Dayro Y Juan

miércoles, 5 de agosto de 2009

martes, 4 de agosto de 2009

Modelo en cascada

El modelo en cascada, también denominado modelo convencional,responde a la secuencia de pasos de desarrollo de un producto empleada desde el comienzo del desarrollo de software para la mayorparte de los sistemas de software.Este modelo se caracteriza por la existencia de un conjunto defases secuenciadas en el tiempo.

A la finalización de una fase secomienza la siguiente tomando como datos de entrada los resultadosde la anterior. En cada una de las fases se introduce más detallehasta obtener un código ejecutable y eficiente que incorpore los requisitos necesarios. Tomaremos como referencia en la siguientedescripción el modelo de ciclo de vida propuesto por la AgenciaEspacial Europea (ESA) y que se corresponde con el modelo encascada.

Las fases principales consideradas son las siguientes:

  1. • Definición de requisitos.
  2. • Diseño.
  3. • Implementación.
  4. • Transferencia del producto.
  5. • Evolución.

Aún hoy se considera que todos los demás modelos no son más que "modificaciones" de este modelo básico. Aunque es cierto que todos lo demás modelos han derivado de él para evitaralgunos de sus problemas, preferimos tratarlos de forma diferenciada.

1 • Definición de requisitos.


Empleada desde el comienzo del desarrollo de software para la mayor parte de los sistemas de software. Este modelo se caracteriza por la existencia de un conjunto de fases secuenciadas en el tiempo. Posiblemente con anterioridad a esta fase ha existido algún estudio de factibilidad que permite asegurar que el software a realizares "realizable", responde a un mercado potencial o real, etc.

La fase de definición de requisitos suele subdividirse en dos subfases:

Análisis de requisitos de usuario (1)

Análisis de requisitos de sísteme (2)

La subfase de (1) análisis de requisitos de usuario tiene como objetivo conocer las necesidades de los usuarios y cuáles deben serlos servicios que un sistema de software debe ofrecerles para satisfacerlas. La fase implica la creación del Documento de Requisitos de Usuario (DRU) que constituye el documento base para que, al final del desarrollo, el sistema sea aceptado por el usuario. Los requisitos de los usuarios pueden ser de muchos tipos diferentes. Por un lado, el usuario tiene requisitos que corresponden al servicio que el sistema de software que se pretende construir le debe proporcionar. En otros casos, se trata de limitaciones existentes en la operación del sistema.

Como ejemplo:

A) Un usuario puede requerir un sistema de control de un ascensor que, entre otros muchos requisitos, desde que el usuario pulsa un botón en la puerta hasta que ésta se cierre no deba transcurrir más de 3 segundos. Este requisito corresponde a un servicio que debe proporcionar al usuario.

B) Podría ser que el sistema de software tenga que utilizar un determinado sistema operativo (lo cual limita el tipo de soluciones posibles).

Esta subfase se aprovecha también para generar el plan de desarrollo con una estimación de costes y recursos .

La subfase de (2) análisis de requisitos del sistema consiste en la construcción de un modelo lógico del sistema de software describiendo las funciones que sean necesarias (sin tomar ninguna decisión sobre cómo implementarlas) y las relaciones entre ellas suponiendo que no existen limitaciones de recursos. Por modelo lógico se entiende la identificación de las funciones de software requeridas para satisfacer los requisitos del usuario. Esta identificación se suele realizar en varios niveles de detalle hasta llegara uno en el que las funciones identificadas estén suficientemente claras de tal forma que no exija un refinamiento posterior. El producto generado en esta fase es el Documento de Requisitos de Software (DRS). También se genera en esta sub-fase el plan de gestión del desarrollo con estimaciones de costes y recursos más ajustados que en la sub-fase anterior.

Es importante distinguir en esta subfase entre requisitos funcionales (aquellos ligados a la relación entre datos de entrada y resultados (datos de salida) que debe presentar el sistema, incluidos los derivados de restricciones temporales cuando éstas están cuantificadas) y requisitos no funcionales (que incluyen todos los aspectos de calidad del sistema: por ejemplo, mantenibilidad (facilidadpara que el sistema evolucione y se modifique una vez entregado alusuario), escalabilidad (posibilidad de incrementar sustancialmente elnúmero de usuarios u otros parámetros), facilidad de uso, etc., que nopueden ligarse a funciones concretas dentro del sistema.Los mecanismos de control (en estas etapas son las revisiones delos documentos generados) deben asegurar que los requisitos softwaresatisfacen completamente los requisitos de usuario. el requisito de usuario puede implicar un conjunto de funciones de software cuya relación debe establecerse en el modelo lógico. Concretamente, implicará una funciónde «cierre de puerta» cuyo tiempo de ejecución deberá ser inferior a 3 segundos (¡aunque en esta fase no podamos asegurarlo!; seráposteriormente cuando podamos estimar y luego comprobar que,efectivamente, ello es posible). En el caso de la limitación del usuario respecto del sistema operativo, implicará el uso de determinados servicios del mismo (llamadas al sistema).

2. Diseño

La fase de diseño tiene como objetivo determinar una solución a los requisitos del sistema definidos en la fase anterior. Obviamente,existen muchas maneras de satisfacer los requisitos y, por tanto, multitud de diseños posibles. Es conveniente distinguir entre diseño de alto nivel o arquitectónico y diseño detallado.

El primero de ellos (arquitectonico) tiene como objetivo definir la estructura de la solución (una vez que la fase deanálisis ha descrito el problema) identificando grandes módulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solución elegida. El segundo (Detallado) define los algoritmos empleados y la organización del código para comenzar la implementación. En la subfase de diseño arquitectónico se parte del modelo lógico generado en la fase de definición de requisitos software y se transforma en una arquitectura agrupando las funciones identificadas en componentes software. Asi mismo, se define la activación y desactivación de cada uno de los componentes y el intercambio de informaciónentre ellos (ahora con limitaciones de espacio).

3. Implementación
Su objetivo es producir una solución eficiente en un lenguaje ejecutable que implemente las decisiones adoptadas en la fase de diseño. Suele incluir la codificación y la prueba del sistema hasta obtener un paquete ejecutable sobre la plataforma (hardware y S.O.) requerida por el usuario. Es interesante mencionar que todas las fases anteriores son conceptualmente independientes del lenguaje de programación seleccionado. Es ahora en la fase de implementación cuándo se selecciona y utiliza un lenguaje de programación determinado; lo que sí es evidente es que el conocimiento del lenguaje de implementación puede orientarla fase de diseño (como ocurre en el caso de los lenguajes de programaciónorientados a objetos) relacionando de forma más directa los objetos o módulos identificados con las construcciones del lenguaje. Como en el proceso de refinamiento se ha dividido el trabajo entre diversos componentes del equipo de trabajo, éstos han trabajado concurrentemente en el diseño detallado y en la subsiguienteimplementación de diversos módulos.
El problema es que ahora es necesario integrar los diversos módulos y construir el sistemas de software completo. Se denomina integración al proceso de construir un sistema de software combinando componentes individuales en una unidadejecutable. Este proceso de integración debe hacerse de formaordenada para que se integren los módulos en función del uso queunos hacen de otros. La gestión del proyecto deberá asegurar que laintegración se realiza adecuadamente. Una vez obtenida la implementación del sistema es necesarioprobar que satisface los requisitos definidos inicialmente. Posiblemente,cada uno de los diseñadores que ha estado construyendo cada uno delos módulos ha probado que su implementación está de acuerdo conlas decisiones tomadas en el diseño pero no puede asegurar que alintegrarlo con otros no existan problemas de incompatibilidades oaspectos no considerados individualmente en cada módulo. Esnecesario, por tanto, realizar pruebas a diferentes niveles hasta que elsistema en su conjunto sea aceptado por el usuario.
Al final de la fase, se genera el Manual de Usuario junto con elcódigo fuente del sistema y las pruebas asociadas.Aunque con la fase de implementación se dispone del «producto», no acaba con ella la actividad del equipo de desarrollo ni el ciclode vida del sistema de software construido. A estas fases se les suelenañadir otras dos que son cada vez más importantes: la fase de transferenciay la de evolución.
4. Transferencia del producto
La fase de transferencia del producto tiene como objetivo instalarel sistema de software desarrollado en el entorno del cliente y realizarlas pruebas de aceptación necesarias. En muchas ocasiones el procesode transferencia implica un período largo en el que se incluye laformación del usuario en el producto y la realización de las pruebas deaceptación junto con el usuario.Debemos tener presente que el usuario deberá aceptar el sistemaque se le entrega en función de los requisitos de usuario que dieronorigen a todo el proceso. Por ello, es importante que durante el desarrollosea posible conocer las decisiones asociadas con los requisitos deusuario (trazabilidad de requisitos).
Si bien este esquema es válido para productos que se realizanbajo encargo para un cliente determinado (por tanto, satisfacen requisitos concretos de este cliente), existen otros muchos productosdesarrollados para un mercado abierto en los que los clientes no existende forma individualizada sino que son clientes anónimos tipificados apartir de técnicas de mercadotecnia.Para muchos productos de consumo general, la fase de transferenciacontinúa las actividades de prueba iniciadas durante laimplementación con la colaboración del cliente.
Es típico consideraren esta fase un número reducido y controlado de clientes que, a cambiode obtener un producto no totalmente probado (conocido como «beta»o «alfa test»), pueden disponer de él mucho antes de que se comercialicede forma general.La entrega de productos «alfa» o «beta» es un reconocimientoimplícito de que pueden existir problemas tanto de errores ocultos comode adecuación del producto al usuario que saldrán a la luz mediante lainteracción con usuarios reales. No olvidemos que la prueba de un sistemade software puede demostrar la presencia de errores pero nunca suausencia.Se suele generar también en esta fase el documento de Historiadel Proyecto que resume las lecciones aprendidas y de cuyo análisisse pueden extraer conclusiones para la mejora de los procesos dedesarrollo en futuros proyectos.
5. Evolución
Una vez que el producto de software ha entrado en operación regular por el usuario no es de ningún modo un sistema inmutable. Todo producto software complejo debe adaptarse a un entorno queva cambiando (nuevas necesidades del cliente, evolución de laplataforma de ejecución hardware o software, etc). Un productosoftware que no evoluciona va haciéndose cada vez menos útil en ese entorno.






La evolución del sistema de software suele incluirse dentro deuna fase denominada de mantenimiento aunque su implicación esmucho más amplia de lo que el término significa en otras ingenierías. Anadie se le ocurre llevar su coche a un taller para que le incorporen unnuevo cilindro; sin embargo, parece que modificar líneas de código sepuede hacer sin alterar la sustancia del producto, lo cual no es cierto.Se suele hablar de tres tipos diferentes de mantenimiento:









1) Mantenimiento correctivo. Pretende eliminar problemassurgidos durante la fase de operación del sistema y que nohan sido detectados anteriormente.






2) Mantenimiento perfectivo. Pretende mejorar lafuncionalidad del sistema ya sea en relación con la eficienciaen ejecución del mismo (menor tiempo de respuesta,optimización del uso de la memoria, etc.), facilitar su uso,etc.






3) Mantenimiento evolutivo. Pretende modificar (ampliar,eliminar o sustituir) la funcionalidad del sistema paraadaptarla a las nuevas necesidades del usuario o con elobjetivo de adaptarlo a nuevas interfaces hardware osoftware.








Modelo ciclo de vida convencional












Las ventajas e inconvenientes del modelo de ciclo de vidaconvencional son bien conocidas desde hace tiempo y podemos decirque el 90 % de los desarrollos actuales se realizan de acuerdo con él. Como ventajas citamos:



a) Fases conocidas por todos los desarrolladores y ligadasa los perfiles técnicos clásicamente establecidos. Existegran experiencia documentada sobre el uso del modeloque coincide con la formación típica del ingeniero desoftware.



b) Es el más eficiente cuando el sistema es conocido y losrequisitos estables ya que se puede avanzar rápidamentehacia la fase de diseño arquitectónico sin que exista elpeligro de una continua interacción entre las primerasfases.



c) Permite una gestión del proceso de desarrollo basada enrevisiones de los documentos generados en cada fasefacilitando la ejecución de los procedimientos de gestión.El modelo en cascada ha sido normalizado por diversas entidadescomo base para el proceso de contratación y para la aceptación delsoftware entregado. Una de estas entidades ha sido la Agencia Espacial Europea (ESA) quien, en su conjunto de normas de ingeniería software, ha definido el modelo de ciclo de vida a utilizar.












Un modelo normalizado como el de la Agencia Espacial Europea no solo presta atención a las actividades técnicas a desarrollar sinotambién a cómo éstas son gestionadas a lo largo del desarrollo. La imbricación de unas y otras define los procesos definidos por elmodelo. Tenemos que destacar, no obstante, que el detalle de losprocedimientos a usar a partir de un modelo no está contenido en elmismo sino que debe ser generado por sus usuarios; así, grandescorporaciones suelen definir complejas guías de aplicación en las que se detallan los procesos a usar en cada una de las etapasadaptados a sus características organizativas o de los productossoftware que deben desarrollar.






La Figura 6 describe esquemáticamente la idea de este modelonormalizado. La figura está abstraída de las normas de la ESA quedescriben las actividades técnicas y de gestión .
En ella se handescrito las fases y asociadas a ellas las actividades fundamentales, los documentos generados y el proceso de revisión y validación decada una. Obsérvese que este proceso de validación se realiza a partirde los documentos generados; sólo en el caso del código es posibleautomatizar el proceso de revisión (por ejemplo, existen programasque pueden leer de forma inteligente un código fuente con el fin deextraer ciertas estadísticas que permiten a los implementadores conocerla calidad del mismo).Son múltiples las desventajas asociadas al modelo convencional;entre ellas citamos:a) La visibilidad del proceso es muy limitada siendo el códigogenerado el único producto con el que el usuario puedevalidar sus requisitos. Las entradas y salidas intermediasson documentos internos al equipo de desarrollo nopensadas para su validación por los usuarios. El único objetoformalizado es el código y aparece al final cuando lasmodificaciones (caso de afectar a las fases anteriores) sonmuy costosas.b) No permite manejar fácilmente cambios de requisitos unavez iniciado el desarrollo.Es típico cuando el usuario no conoce exactamente lo quedesea que cambie de opinión sobre sus necesidades o,simplemente, que no indique todas sus necesidades. A esteproblema se le conoce como de inestabilidad de los requisitos y es uno de los más graves en el proceso dediseño.






Modelo de ciclo de vida convencional de la ESA











Como consecuencia, impide realizar el seguimientode los requisitos a lo largo del desarrollo de forma tal quefacilite la evolución posterior del sistema.
c) Las actividades de prueba se realizan sobre el códigocuando la relación con las decisiones de diseño se hanperdido. Durante las pruebas de los módulos la situación estolerable pero en las pruebas de integración surgendificultades crecientes con la complejidad del sistema.Casi todos los demás modelos han surgido como variacionesde éste.
Una conocida variación es el modelo en V en el que los aspectosde prueba aparecen claramente ligados a cada una de las fases.En este modelo se asocia una fase de prueba a cada una de lasfases del ciclo de vida estableciendo métodos de gestión para lavalidación de cada una de ellas (conformidad).
La Figura describe esquemáticamente la idea de este modelo.Visto globalmente, el modelo en V implica que las pruebas no seconsideran parte de la implementación sino de forma separada relacionadascon cada una de las fases del desarrollo.El problema de aplicación de este modelo reside precisamenteen la capacidad que tengamos de asegurar la conformidad mediantepruebas sobre el código.

La aparición de tecnologías de software que permiten formalizar parcialmente la fase de análisis de requisitos de software o deldiseño arquitectónico, está permitiendo completar la visión de este modelo combinando las pruebas mencionadas ) con otras sobre los documentos de requisitos















Modelo de ciclo de vida en v

















o diseño que mejoran globalmente la capacidad de validar el producto resultante.