Modelos de la IS

Ingeniera Es el conjunto de conocimientos y tcnicas cientficas aplicadas a la creacin, perfeccionamiento e implementacin de estructuras (tanto fsicas como tericas) para la resolucin de problemas que afectan la actividad cotidiana de la sociedad. Software Es el conjunto de programas de cmputo, documentos asociados y esquemas de configuracin necesarios para que estos programas operen. Ingeniera de software Es el establecimiento y uso de principios solidos de la ingeniera para obtener un software confiable y eficiente de una manera econmica. Es la aplicacin prctica del conocimiento cientfico en el diseo y construccin de programas de computadora y la documentacin asociada requerida para desarrollar, operar y mantenerlos. Es la aplicacin de un enfoque sistemtico, disciplinado, y cuantificable al desarrollo, operacin y mantenimiento del software. Abarca un proceso, tcnicas de gestin, mtodos tcnicos y el uso de herramientas. Qu es un modelo de proceso del software? Es una descripcin del software que se presenta desde una perspectiva particular. Es una abstraccin de un proceso real.

Modelo en

cascada

Es el enfoque metodolgico que ordena rigurosamente las etapas del proceso para el desarrollo de software, de tal forma que el inicio de cada etapa debe esperar a la finalizacin de la etapa anterior. Un ejemplo de una metodologa de desarrollo en cascada es: 1. Anlisis de requisitos.- En esta fase se analizan las necesidades de los usuarios finales del software para determinar qu objetivos debe cubrir. De esta fase surge una memoria

llamada SRD (documento de especificacin de requisitos), que contiene la especificacin completa de lo que debe hacer el sistema sin entrar en detalles internos. Es importante sealar que en esta etapa se debe consensuar todo lo que se requiere del sistema y ser aquello lo que seguir en las siguientes etapas, no pudindose requerir nuevos resultados a mitad del proceso de elaboracin del software. 2. Diseo de sistema.- Descompone y organiza el sistema en elementos que puedan elaborarse por separado, aprovechando las ventajas del desarrollo en equipo. Como resultado surge el SDD (Documento de Diseo del Software), que contiene la descripcin de la estructura relacional global del sistema y la especificacin de lo que debe hacer cada una de sus partes, as como la manera en que se combinan unas con otras. Es conveniente distinguir entre diseo de alto nivel o arquitectnico y diseo detallado. El primero de ellos tiene como objetivo definir la estructura de la solucin (una vez que la fase de anlisis ha descrito el problema) identificando grandes mdulos (conjuntos de funciones que van a estar asociadas) y sus relaciones. Con ello se define la arquitectura de la solucin elegida. El segundo define los algoritmos empleados y la organizacin del cdigo para comenzar la implementacin. 3. Diseo de programa.- Es la fase en donde se realizan los algoritmos necesarios para el cumplimiento de los requerimientos del usuario as como tambin los anlisis necesarios para saber que herramientas usar en la etapa de Codificacin. 4. Codificacin.- Es la fase en donde se implementa el cdigo fuente, haciendo uso de prototipos as como de pruebas y ensayos para corregir errores. Dependiendo del lenguaje de programacin y su versin se crean las bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la programacin sea un proceso mucho ms rpido. 5. Pruebas.- Los elementos, ya programados, se ensamblan para componer el sistema y se
comprueba que funciona correctamente y que cumple con los requisitos, antes de ser entregado al usuario final.

6. Implementacin.- Es la fase en donde el usuario final ejecuta el sistema, para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que el sistema no falle. En la creacin de desarrollo de cascada se implementa los cdigos de investigacin y pruebas del mismo 7. Mantenimiento.- Una de las etapas ms crticas, ya que se destina un 75% de los recursos, es el mantenimiento del Software ya que al utilizarlo como usuario final puede ser que no cumpla con todas nuestras expectativas. Ventajas Una de las principales ventajas de un modelo en cascada es que la planificacin es muy sencilla. Podemos pasar por alto detalles concretos y despus, en una nueva planificacin, llevarlos a cabo. En nuestro caso, en una primera instancia nos ocupamos del funcionamiento bsico de un CRM y ms tarde, abordamos los aspectos ms avanzados, como el mdulo de inteligencia. La calidad de este tipo de proyectos es muy alta dado que una vez terminada una versin puede mejorarse e incluso redisearse para que su funcionamiento sea ms eficiente. Desventajas En la vida real, un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin del modelo, lo cual hace que lo lleve al fracaso. El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el proceso de prueba y hasta que el software no est completo no se opera. Esto es la base para que funcione bien. Cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costos del desarrollo.

Modelo en espiral

Las actividades de este modelo se conforman en una espiral, en la que cada bucle o iteracin representa un conjunto de actividades. Las actividades no estn fijadas a ninguna prioridad, sino que las siguientes se eligen en funcin del anlisis de riesgo, comenzando por el bucle interior. Anlisis de riesgo.- es el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daos y consecuencias que stas puedan producir. En cada vuelta o iteracin hay que tener en cuenta: Los objetivos.- qu necesidad debe cubrir el producto Alternativas.- las diferentes formas de conseguir los objetivos de forma exitosa, desde diferentes puntos de vista como pueden ser: 1. Caractersticas: experiencia del personal, requisitos a cumplir, etc. 2. Formas de gestin del sistema. 3. Riesgo asumido con cada alternativa. Desarrollar y Verificar.- Programar y probar el software.

Si el resultado no es el adecuado o se necesita implementar mejoras o funcionalidades: Se planificaran los siguientes pasos y se comienza un nuevo ciclo de la espiral. La espiral tiene una forma de caracola y se dice que mantiene dos dimensiones, la radial y la angular: Angular: Indica el avance del proyecto del software dentro de un ciclo. Radial: Indica el aumento del coste del proyecto, ya que con cada nueva iteracin se pasa ms tiempo desarrollando. Para cada ciclo habr cuatro actividades: Determinar Objetivos: Fijar tambin los productos definidos a obtener: requerimientos, especificacin, manual de usuario. Fijar las restricciones.

Identificacin de riesgos del proyecto y estrategias alternativas para evitarlos. Hay una cosa que solo se hace una vez: planificacin inicial. Anlisis del riesgo: Se lleva a cabo el estudio de las causas de las posibles amenazas y probables eventos no deseados y los daos y consecuencias que stas puedan producir. Desarrollar y probar. Tareas de la actividad propia y de prueba. Anlisis de alternativas e identificacin resolucin de riesgos. Dependiendo del resultado de la evaluacin de los riesgos, se elige un modelo para el desarrollo, el que puede ser cualquiera de los otros existentes, como formal, evolutivo, cascada, etc. As si por ejemplo si los riesgos en la interfaz de usuario son dominantes, un modelo de desarrollo apropiado podra ser la construccin de prototipos evolutivos. Si lo riesgos de proteccin son la principal consideracin, un desarrollo basado en transformaciones formales podra ser el ms apropiado. Planificacin. Revisamos todo lo hecho, evalundolo, y con ello decidimos si continuamos con las fases siguientes y planificamos la prxima actividad. Ventajas

El anlisis del riesgo se hace de forma explcita y clara. Une los mejores elementos de los restantes modelos. Reduce riesgos del proyecto Incorpora objetivos de calidad Integra el desarrollo con el mantenimiento, etc.

Adems es posible tener en cuenta mejoras y nuevos requerimientos sin romper con la metodologa, ya que este ciclo de vida no es rgido ni esttico. Desventajas Genera mucho tiempo en el desarrollo del sistema Modelo costoso Requiere experiencia en la identificacin de riesgos

Modelo RUP (Proceso Unificado Racional)

Es un proceso de desarrollo de software desarrollado por la empresa Rational Software, actualmente propiedad de IBM. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin. El RUP est basado en 6 principios clave que son los siguientes: Adaptar el proceso.- El proceso deber adaptarse a las necesidades del cliente ya que es muy importante interactuar con l. Las caractersticas propias del proyecto u organizacin, el tamao del mismo, as como su tipo o las regulaciones que lo condicionen, influirn en su diseo especfico. Tambin se deber tener en cuenta el alcance del proyecto en un rea subformal para hacer un proceso de satisfaccin del software. Equilibrar prioridades.- Los requisitos de los diversos participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un equilibrio que satisfaga los deseos de todos. Gracias a este equilibrio se podrn corregir desacuerdos que surjan en el futuro. Demostrar valor iterativamente.- Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los inversores, la estabilidad y

calidad del producto, y se refina la direccin del proyecto as como tambin los riesgos involucrados. Colaboracin entre equipos.- El desarrollo de software no lo hace una nica persona sino mltiples equipos. Debe haber una comunicacin fluida para coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc. Elevar el nivel de abstraccin.-Este principio dominante motiva el uso de conceptos reutilizables tales como patrn del software, lenguajes 4GL o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificacin de software a la medida del cliente, sin saber con certeza qu codificar para satisfacer de la mejor manera los requisitos y sin comenzar desde un principio pensando en la reutilizacin del cdigo. Un alto nivel de abstraccin tambin permite discusiones sobre diversos niveles y soluciones arquitectnicas. stas se pueden acompaar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML. Enfocarse en la calidad.-El control de calidad no debe realizarse al final de cada iteracin, sino en todos los aspectos de la produccin. El aseguramiento de la calidad forma parte del proceso

Iteraciones

Preliminares

#1

#2

#n

#n+1

#n+2

#n

#n+1

de desarrollo y no de un grupo independiente. Ciclo de vida El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades. En la Figura muestra cmo vara el esfuerzo asociado a las disciplinas segn la fase en la que se encuentre el proyecto RUP.

Las primeras iteraciones (en las fases de Inicio y Elaboracin) se enfocan hacia la comprensin del problema y la tecnologa, la delimitacin del mbito del proyecto, la eliminacin de los riesgos crticos, y al establecimiento de una baseline (Lnea Base) de la arquitectura. Durante la fase de inicio las iteraciones hacen mayor nfasis en actividades de modelado del negocio y de requisitos. En la fase de elaboracin, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan ms los flujos de trabajo de requisitos, modelo de negocios (refinamiento), anlisis, diseo y una parte de implementacin orientado a la baseline de la arquitectura. En la fase de construccin, se lleva a cabo la construccin del producto por medio de una serie de iteraciones. Para cada iteracin se seleccionan algunos Casos de Uso, se refinan su anlisis y diseo y se procede a su implementacin y pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementacin de la nueva versin del producto. En la fase de transicin se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Como se puede observar en cada fase participan todas las disciplinas, pero dependiendo de la fase el esfuerzo dedicado a una disciplina vara. Principales caractersticas Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo) Pretende implementar las mejores prcticas en Ingeniera de Software Desarrollo iterativo Administracin de requisitos Uso de arquitectura basada en componentes Control de cambios Modelado visual del software Verificacin de la calidad del software Fases RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas: Proceso: Las etapas de esta seccin son: (Revise nuevamente la grfica) Modelado de negocio Requisitos Anlisis y Diseo Implementacin Pruebas Despliegue

Soporte: En esta parte nos encontramos con las siguientes etapas: Gestin del cambio y configuraciones Gestin del proyecto Entorno

La estructura dinmica de RUP es la que permite que ste sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente: Inicio (tambin llamado Incepcin o Concepcin). Elaboracin. Desarrollo (tambin llamado Implementacin, Construccin). Cierre (tambin llamado Transicin).

Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer anlisis del dominio del problema, se disea la solucin preliminar. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan las mejoras para el proyecto. Fase de Transicin: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto. Artefactos RUP en cada una de sus fases (pertenecientes a la estructura dinmica) realiza una serie de artefactos que sirven para comprender mejor tanto el anlisis como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los siguientes: Inicio: Documento Visin Diagramas de caso de uso Especificacin de Requisitos

Elaboracin: Documento Arquitectura que trabaja con las siguientes vistas: Vista Lgica Diagrama de clases Modelo E-R (Si el sistema as lo requiere) Vista de Implementacin Diagrama de Secuencia Diagrama de estados Diagrama de Colaboracin Vista Conceptual Modelo de dominio Vista fsica Mapa de comportamiento a nivel de hardware. Diseo y desarrollo de casos de uso, o flujos de casos de uso arquitectnicos Pruebas de los casos de uso desarrollados, que demuestran que la arquitectura documentada responde adecuadamente a requerimientos funcionales y no funcionales.

Construccin: Especificacin de requisitos faltantes Diseo y desarrollo de casos de uso y/o flujos de acuerdo con la planeacin iterativa Pruebas de los casos de uso desarrollados, y pruebas de regresin segn sea el caso

Transicin: Pruebas finales de aceptacin Puesta en produccin Estabilizacin

Ventajas Requiere conocimientos del proceso y de UML. Progreso visible en las etapas tempranas. El uso de Iteraciones (actividades) Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integracin final del sistema Facilita la reutilizacin del cdigo teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual adems permite que se aprecien oportunidades de mejoras en el diseo. Desventajas Por el grado de complejidad puede no resultar muy adecuado.

RUP es generalmente mal aplicado en el estilo cascada.

Modelo de prototipos
El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseo rpido se centra en una representacin de aquellos aspectos del software que sern visibles para el cliente o el usuario final. Este diseo conduce a la construccin de un prototipo, el cual es evaluado por el cliente para una retroalimentacin; gracias a sta se refinan los requisitos del software que se desarrollar. La interaccin ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Etapas Plan rpido Modelado, diseo rpido Construccin del Prototipo Desarrollo, entrega y retroalimentacin Comunicacin Ventajas

Este modelo es til cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. Tambin ofrece un mejor enfoque cuando el responsable del desarrollo del software est inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debera tomar la interaccin humano-mquina. Desventajas

El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intencin de crear un prototipo de forma rpida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su funcin. En aras de desarrollar rpidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementacin poco convenientes (por ejemplo, elegir un lenguaje de programacin incorrecto porque proporcione un desarrollo ms rpido).

Modelo por etapas

El modelo de desarrollo de software por etapas es similar al Modelo de prototipos ya que se muestra al cliente el software en diferentes estados sucesivos de desarrollo, se diferencia en que las especificaciones no son conocidas en detalle al inicio del proyecto y por tanto se van desarrollando simultneamente con las diferentes versiones del cdigo. Este modelo estipula que el software ser desarrollado en sucesivas etapas: 1. Plan operativo.- Etapa donde se define el problema que resolver, las metas del proyecto, las metas de calidad y se identifica cualquier restriccin aplicable al proyecto. 2. Especificacin de requisitos.- Permite entregar una visin de alto nivel sobre el proyecto, poniendo nfasis en la descripcin del problema desde el punto de vista de los clientes y desarrolladores. Tambin se considera la posibilidad de una planificacin de los recursos sobre una escala de tiempos. 3. Especificacin funcional.- Especifica la informacin sobre la cual el software a desarrollar trabajar. 4. Diseo.- Permite describir como el sistema va a satisfacer los requisitos. Esta etapa a menudo tiene diferentes niveles de detalle. Los niveles ms altos de detalle generalmente describen los componentes o mdulos que formarn el software a ser producido. Los niveles ms bajos, describen, con mucho detalle, cada mdulo que contendr el sistema. 5. Implementacin.- Aqu es donde el software a ser desarrollado se codifica. Dependiendo del tamao del proyecto, la programacin puede ser distribuida entre distintos programadores o grupos de programadores. Cada uno se concentrar en la construccin y prueba de una parte del software, a menudo un subsistema. Las pruebas, en general, tiene por objetivo asegurar que todas las funciones estn correctamente implementadas dentro del sistema. 6. Integracin.- Es la fase donde todos los subsistemas codificados independientemente se juntan. Cada seccin es enlazada con otra y, entonces, probada. Este proceso se repite hasta que se han agregado todos los mdulos y el sistema se prueba como un todo. 7. Validacin y verificacin.- Una vez que el sistema ha sido integrado, comienza esta etapa. Es donde es probado para verificar que el sistema es consistente con la definicin de requisitos y la especificacin funcional. Por otro lado, la verificacin consiste en una serie de actividades que aseguran que el software implementa correctamente una funcin especfica. Al finalizar esta etapa, el sistema ya puede ser instalado en ambiente de explotacin. 8. Mantenimiento.- El mantenimiento ocurre cuando existe algn problema dentro de un sistema existente, e involucrara la correccin de errores que no fueron descubiertos en las fases de prueba, mejoras en la implementacin de las unidades del sistema y cambios para que responda a los nuevos requisitos. Las mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva.