MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN

INSTITUTO TECNOLGICO SUPERIOR DE PEROTE CARRERA: INGENIERA EN INFORMTICA.

MATERIA: FUNDAMENTOS DE SISTEMAS DE INFORMACIN.

TEMA: MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE

INFORMACIN.

NOMBRE DEL MAESTRO: LSCA. JOSE MANUEL DAZ RIVERA.

NOMBRE DEL ALUMNO: LEONEL ABAD MNDEZ.

MATRICULA: 1005SO49.

SEMESTRE: TERCERO.

FECHA: 08/10/2011.

INGENIERA EN INFORMTICA

NDICE

TEMA

PGINA

MODELO EN CASCADA-----------------------------------------------------------

3

MODELOS EVOLUTIVOS----------------------------------------------------------

5

MODELOS ESPIRALES------------------------------------------------------------

10

EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE--------- 14

MODELO DE PROCESO DE SOFTWARE IEEE------------------------------ 17

HERRAMIENTA CASE-------------------------------------------------------------- 18

LEONEL ABAD MNDEZ

Pgina 2


MODELO EN CASCADAEn Ingeniera de software el desarrollo en cascada, tambin llamado 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. El ms conocido, esta basado en el ciclo convencional de una ingeniera, el paradigma del ciclo de vida abarca las siguientes actividades:

Ingeniera y Anlisis del Sistema Anlisis de los Requisitos Diseo Codificacin Prueba Mantenimiento

Un ejemplo de una metodologa de desarrollo en cascada es: 1. Anlisis de requisitos 2. Diseo del Sistema 3. Diseo del Programa 4. Codificacin 5. Pruebas 6. Implantacin 7. Mantenimiento De esta forma, cualquier error de diseo detectado en la etapa de prueba conduce necesariamente al rediseo y nueva programacin del cdigo afectado, aumentando los costes del desarrollo. La palabra cascada sugiere, mediante la metfora de la fuerza de la gravedad, el esfuerzo necesario para introducir un cambio en las fases ms avanzadas de un proyecto. Si bien ha sido ampliamente criticado desde el mbito acadmico y la industria, sigue siendo el paradigma ms seguido al da de hoy. LEONEL ABAD MNDEZ Pgina 3


FASES DEL MODELO ANALISIS 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. DISEO DEL SISTEMA Se 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. DISEO DEL 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. 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.

LEONEL ABAD MNDEZ

Pgina 4


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. VERIFICACION 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. MANTENIMIENTO Una de las etapas mas criticas, 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. VARIANTES Existen variantes de este modelo; especialmente destacamos la que hace uso de prototipos y en la que se establece un ciclo antes de llegar a la fase de mantenimiento, verificando que el sistema final este libre de fallos 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.

MODELOS EVOLUTIVOSEl software evoluciona con el tiempo. Los requisitos del usuario y del producto suelen cambiar conforme se desarrolla el mismo. Las fechas de mercado y la competencia hacen que no sea posible esperar a poner en el mercado un producto absolutamente completo, por lo que se debe introducir una versin funcional limitada de alguna forma para aliviar las presiones competitivas. En esas u otras situaciones similares los desarrolladores necesitan modelos de progreso que estn diseados para acomodarse a una evolucin temporal o progresiva, donde los requisitos centrales son conocidos de antemano, aunque no estn bien definidos a nivel detalle. LEONEL ABAD MNDEZ Pgina 5


En el modelo Cascada y Cascada Realimentado no se tiene en cuenta la naturaleza evolutiva del software, se plantea como esttico con requisitos bien conocidos y definidos desde el inicio.6 Los evolutivos son modelos iterativos, permiten desarrollar versiones cada vez ms completas y complejas, hasta llegar al objetivo final deseado; incluso evolucionar ms all, durante la fase de operacin. Los modelos iterativo incremental y espiral (entre otros) son dos de los ms conocidos y utilizados del tipo evolutivo. MODELO ITERATIVO INCREMENTAL En trminos generales, podemos distinguir, en la figura 4, los pasos generales que sigue el proceso de desarrollo de un producto software. En el modelo de ciclo de vida seleccionado, se identifican claramente dichos pasos. La Descripcin del Sistema es esencial para especificar y confeccionar los distintos incrementos hasta llegar al Producto global y final. Las actividades concurrentes (Especificacin, Desarrollo y Validacin) sintetizan el desarrollo pormenorizado de los incrementos, que se har posteriormente.

Diagrama genrico del desarrollo evolutivo incremental. El diagrama nos muestra en forma muy esquemtica, el funcionamiento de un ciclo iterativo incremental, el cual permite la entrega de versiones parciales a medida que se va construyendo el producto final. Es decir, a medida que cada incremento definido llega a su etapa de operacin y mantenimiento. Cada versin emitida incorpora a los anteriores incrementos las funcionalidades y requisitos que fueron analizados como necesarios. El incremental es un modelo de tipo evolutivo que est basado en varios ciclos Cascada realimentados aplicados repetidamente, con una filosofa iterativa. En la figura se muestra un refino del diagrama previo, bajo un esquema temporal, para LEONEL ABAD MNDEZ Pgina 6


obtener finalmente el esquema del Modelo de ciclo de vida Iterativo Incremental, con sus actividades genricas asociadas. Aqu se observa claramente cada ciclo cascada que es aplicado para la obtencin de un incremento; estos ltimos se van integrando para obtener el producto final completo. Cada incremento es un ciclo Cascada Realimentado, aunque, por simplicidad, en la figura 5 se muestra como secuencial puro.

Modelo iterativo incremental para el ciclo de vida del software Se observa que existen actividades de desarrollo (para cada incremento) que son realizadas en paralelo o concurrentemente, as por ejemplo, en la figura, mientras se realiza el diseo detalle del primer incremento ya se est realizando en anlisis del segundo. La figura 5 es slo esquemtica, un incremento no necesariamente se iniciar durante la fase de diseo del anterior, puede ser posterior (incluso antes), en cualquier tiempo de la etapa previa. Cada incremento concluye con la actividad de operacin y mantenimiento (indicada Operacin en la figura), que es donde se produce la entrega del producto parcial al cliente. El momento de inicio de cada incremento es dependiente de varios factores: tipo de sistema; independencia o dependencia entre incrementos (dos de ellos totalmente independientes pueden ser fcilmente iniciados al mismo tiempo si se dispone de personal suficiente); capacidad y cantidad de profesionales involucrados en el desarrollo; etc. Bajo este modelo se entrega software por partes funcionales ms pequeas, pero reutilizables, llamadas incrementos. En general cada incremento se construye sobre aquel que ya fue entregada. .

LEONEL ABAD MNDEZ

Pgina 7


Como se muestra en la figura, se aplican secuencias Cascada en forma escalonada, mientras progresa el tiempo calendario. Cada secuencia lineal o Cascada produce un incremento y a menudo el primer incremento es un sistema bsico, con muchas funciones suplementarias (conocidas o no) sin entregar. El cliente utiliza inicialmente ese sistema bsico intertanto, el resultado de su uso y evaluacin puede aportar al plan para el desarrollo del/los siguientes incrementos (o versiones). Adems tambin aportan a ese plan otros factores, como lo es la priorizacin (mayor o menor urgencia en la necesidad de cada incremento) y la dependencia entre incrementos (o independencia). Luego de cada integracin se entrega un producto con mayor funcionalidad que el previo. El proceso se repite hasta alcanzar el software final completo. Siendo iterativo, con el modelo incremental se entrega un producto parcial pero completamente operacional en cada incremento, y no una parte que sea usada para reajustar los requerimientos (como si ocurre en el modelo de construccin de prototipos). El enfoque incremental resulta muy til con baja dotacin de personal para el desarrollo; tambin si no hay disponible fecha lmite del proyecto por lo que se entregan versiones incompletas pero que proporcionan al usuario funcionalidad bsica (y cada vez mayor). Tambin es un modelo til a los fines de evaluacin. Nota: Puede ser considerado y til, en cualquier momento o incremento incorporar temporalmente el paradigma MCP como complemento, teniendo as una mixtura de modelos que mejoran el esquema y desarrollo general. Ejemplo: Un procesador de texto que sea desarrollado bajo el paradigma Incremental podra aportar, en principio, funciones bsicas de edicin de archivos y produccin de documentos (algo como un editor simple). En un segundo incremento se le podra agregar edicin ms sofisticada, y de generacin y mezcla de documentos. En un tercer incremento podra considerarse el agregado de funciones de correccin ortogrfica, esquemas de paginado y plantillas; en un cuarto capacidades de dibujo propias y ecuaciones matemticas. As sucesivamente hasta llegar al procesador final requerido. As, el producto va creciendo, acercndose a su meta final, pero desde la entrega del primer incremento ya es til y funcional para el cliente, el cual observa una respuesta rpida en cuanto a entrega temprana; sin notar que la fecha lmite del proyecto puede no estar acotada ni tan definida, lo que da margen de operacin y alivia presiones al equipo de desarrollo. LEONEL ABAD MNDEZ Pgina 8


Como se dijo, el Iterativo Incremental es un modelo del tipo evolutivo, es decir donde se permiten y esperan probables cambios en los requisitos en tiempo de desarrollo; se admite cierto margen para que el software pueda evolucionar. Aplicable cuando los requisitos son medianamente bien conocidos pero no son completamente estticos y definidos, cuestin esa que si es indispensable para poder utilizar un modelo Cascada. El modelo es aconsejable para el desarrollo de software en el cual se observe, en su etapa inicial de anlisis, que posee reas bastante bien definidas a cubrir, con suficiente independencia como para ser desarrolladas en etapas sucesivas. Tales reas a cubrir suelen tener distintos grados de apremio por lo cual las mismas se deben priorizar en un anlisis previo, es decir, definir cual ser la primera, la segunda, y as sucesivamente; esto se conoce como definicin de los incrementos con base en priorizacin. Pueden no existir prioridades funcionales por parte del cliente, pero el desarrollador debe fijarlas de todos modos y con algn criterio, ya que basndose en ellas se desarrollarn y entregarn los distintos incrementos. El hecho de que existan incrementos funcionales del software lleva inmediatamente a pensar en un esquema de desarrollo modular, por tanto este modelo facilita tal paradigma de diseo. En resumen, un modelo incremental lleva a pensar en un desarrollo modular, con entregas parciales del producto software denominados incrementos del sistema, que son escogidos segn prioridades predefinidas de algn modo. El modelo permite una implementacin con refinamientos sucesivos (ampliacin o mejora). Con cada incremento se agrega nueva funcionalidad o se cubren nuevos requisitos o bien se mejora la versin previamente implementada del producto software. Este modelo brinda cierta flexibilidad para que durante el desarrollo se incluyan cambios en los requisitos por parte del usuario, un cambio de requisitos propuesto y aprobado puede analizarse e implementarse como un nuevo incremento o, eventualmente, podr constituir una mejora/adecuacin de uno ya planeado. Aunque si se produce un cambio de requisitos por parte del cliente que afecte incrementos previos ya terminados (deteccin/incorporacin tarda) se debe evaluar la factibilidad y realizar un acuerdo con el cliente, ya que puede impactar fuertemente en los costos. La seleccin de este modelo permite realizar entregas funcionales tempranas al cliente (lo cual es beneficioso tanto para l como para el grupo de desarrollo). Se priorizan las entregas de aquellos mdulos o incrementos en que surja la necesidad operativa de hacerlo, por ejemplo para cargas previas de informacin, indispensable para los incrementos siguientes.

LEONEL ABAD MNDEZ

Pgina 9


El modelo iterativo incremental no obliga a especificar con precisin y detalle absolutamente todo lo que el sistema debe hacer, (y cmo), antes de ser construido (como el caso del cascada, con requisitos congelados). Slo se hace en el incremento en desarrollo. Esto torna ms manejable el proceso y reduce el impacto en los costos. Esto es as, porque en caso de alterar o rehacer los requisitos, solo afecta una parte del sistema. Aunque, lgicamente, esta situacin se agrava si se presenta en estado avanzado, es decir en los ltimos incrementos. En definitiva, el modelo facilita la incorporacin de nuevos requisitos durante el desarrollo. Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se implementa funcionalidad parcial. Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de partes operativas del software. El modelo proporciona todas las ventajas del modelo en cascada realimentado, reduciendo sus desventajas slo al mbito de cada incremento. El modelo incremental no es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, o de alto ndice de riesgos.

MODELOS ESPIRALESEl modelo espiral fue propuesto inicialmente por Barry Boehm. Es un modelo evolutivo que conjuga la naturaleza iterativa del modelo MCP con los aspectos controlados y sistemticos del Modelo Cascada. Proporciona potencial para desarrollo rpido de versiones incrementales. En el modelo Espiral el software se construye en una serie de versiones incrementales. En las primeras iteraciones la versin incremental podra ser un modelo en papel o bien un prototipo. En las ltimas iteraciones se producen versiones cada vez ms completas del sistema diseado. El modelo se divide en un nmero de Actividades de marco de trabajo, llamadas regiones de tareas. En general existen entre tres y seis regiones de tareas (hay variantes del modelo). En la figura 6 se muestra el esquema de un Modelo Espiral con 6 regiones. En este caso se explica una variante del modelo original de Boehm, expuesto en su tratado de 1988; en 1998 expuso un tratado ms reciente.

LEONEL ABAD MNDEZ

Pgina 10


++++++++++++++++++++++++++++++++ Modelo espiral para el ciclo de vida del software. Las regiones definidas en el modelo de la figura son:

Regin 1 - Tareas requeridas para establecer la comunicacin entre el cliente y el desarrollador.

Regin 2 - Tareas inherentes a la definicin de los recursos, tiempo y otra informacin relacionada con el proyecto.

Regin 3 - Tareas necesarias para evaluar los riesgos tcnicos y de gestin del proyecto.

Regin 4 - Tareas para construir una o ms representaciones de la aplicacin software.

Regin 5 - Tareas para construir la aplicacin, instalarla, probarla y proporcionar soporte al usuario o cliente (Ej. documentacin y prctica).

Regin 6 - Tareas para obtener la reaccin del cliente, segn la evaluacin de lo creado e instalado en los ciclos anteriores. Las actividades enunciadas para el marco de trabajo son generales y se aplican a cualquier proyecto, grande, mediano o pequeo, complejo o no. Las regiones que definen esas actividades comprenden un conjunto de tareas del trabajo: ese conjunto s se debe adaptar a las caractersticas del proyecto en particular a emprender. Ntese que lo listado en los tems de 1 a 6 son conjuntos de tareas, algunas de las ellas normalmente dependen del proyecto o desarrollo en si.

LEONEL ABAD MNDEZ

Pgina 11


Proyectos pequeos requieren baja cantidad de tareas y tambin de formalidad. En proyectos mayores o crticos cada regin de tareas contiene labores de ms alto nivel de formalidad. En cualquier caso se aplican actividades de proteccin (por ejemplo, gestin de configuracin del software, garanta de calidad, etc.). Al inicio del ciclo, o proceso evolutivo, el equipo de ingeniera gira alrededor del espiral (metafricamente hablando) comenzando por el centro (marcado con en la figura 6) y en el sentido indicado; el primer circuito de la espiral puede producir el desarrollo de una especificacin del producto; los pasos siguientes podran generar un prototipo y progresivamente versiones ms sofisticadas del software. Cada paso por la regin de planificacin provoca ajustes en el plan del proyecto; el coste y planificacin se realimentan en funcin de la evaluacin del cliente. El gestor de proyectos debe ajustar el nmero de iteraciones requeridas para completar el desarrollo. El modelo espiral puede ir adaptndose y aplicarse a lo largo de todo el Ciclo de vida del software (en el modelo clsico, o cascada, el proceso termina a la entrega del software). Una visin alternativa del modelo puede observarse examinando el eje de punto de entrada de proyectos. Cada uno de los circulitos () fijados a lo largo del eje representan puntos de arranque de los distintos proyectos (relacionados); a saber:

Un proyecto de desarrollo de conceptos comienza al inicio de la espiral, hace mltiples iteraciones hasta que se completa, es la zona marcada con verde.

Si lo anterior se va a desarrollar como producto real, se inicia otro proyecto: Desarrollo de nuevo Producto. Que evolucionar con iteraciones hasta culminar; es la zona marcada en color azul.

Eventual y anlogamente se generarn proyectos de mejoras de productos y de mantenimiento de productos, con las iteraciones necesarias en cada rea (zonas roja y gris, respectivamente). Cuando la espiral se caracteriza de esta forma, est operativa hasta que el software se retira, eventualmente puede estar inactiva (el proceso), pero cuando se produce un cambio el proceso arranca nuevamente en el punto de entrada apropiado (por ejemplo, en mejora del producto). El modelo espiral da un enfoque realista, que evoluciona igual que el software; se adapta muy bien para desarrollos a gran escala.

LEONEL ABAD MNDEZ

Pgina 12


El Espiral utiliza el MCP para reducir riesgos y permite aplicarlo en cualquier etapa de la evolucin. Mantiene el enfoque clsico (cascada) pero incorpora un marco de trabajo iterativo que refleja mejor la realidad. Este modelo requiere considerar riesgos tcnicos en todas las etapas del proyecto; aplicado adecuadamente debe reducirlos antes de que sean un verdadero problema. El Modelo evolutivo como el Espiral es particularmente apto para el desarrollo de Sistemas Operativos (complejos); tambin en sistemas de altos riesgos o crticos (Ej. navegadores y controladores aeronuticos) y en todos aquellos en que sea necesaria una fuerte gestin del proyecto y sus riesgos, tcnicos o de gestin. Desventajas importantes:

Requiere mucha experiencia y habilidad para la evaluacin de los riesgos, lo cual es requisito para el xito del proyecto.

Es difcil convencer a los grandes clientes que se podr controlar este enfoque evolutivo. Este modelo no se ha usado tanto, como el Cascada (Incremental) o MCP, por lo que no se tiene bien medida su eficacia, es un paradigma relativamente nuevo y difcil de implementar y controlar. MODELO ESPIRAL WIN & WIN Una variante interesante del Modelo Espiral previamente visto (Fig. 6) es el Modelo espiral Win-Win (Barry Boehm). El Modelo Espiral previo (clsico) sugiere la comunicacin con el cliente para fijar los requisitos, en que simplemente se pregunta al cliente qu necesita y l proporciona la informacin para continuar; pero esto es en un contexto ideal que rara vez ocurre. Normalmente cliente y desarrollador entran en una negociacin, se negocia coste frente a funcionalidad, rendimiento, calidad, etc. Es as que la obtencin de requisitos requiere una negociacin, que tiene xito cuando ambas partes ganan. Las mejores negociaciones se fuerzan en obtener Victoria & Victoria (Win & Win), es decir que el cliente gane obteniendo el producto que lo satisfaga, y el desarrollador tambin gane consiguiendo presupuesto y fecha de entrega realista. Evidentemente, este modelo requiere fuertes habilidades de negociacin. El modelo Win-Win define un conjunto de actividades de negociacin al principio de cada paso alrededor de la espiral; se definen las siguientes actividades:

LEONEL ABAD MNDEZ

Pgina 13


1. Identificacin del sistema o subsistemas clave de los directivos (*) (saber qu quieren). 2. Determinacin de condiciones de victoria de los directivos (saber qu necesitan y los satisface) 3. Negociacin de las condiciones victoria de los directivos para obtener condiciones Victoria & Victoria (negociar para que ambos ganen). (*) Directivo: Cliente escogido con inters directo en el producto, que puede ser premiado por la organizacin si tiene xito o criticado si no. El modelo Win & Win hace nfasis en la negociacin inicial, tambin introduce 3 hitos en el proceso llamados puntos de fijacin, que ayudan a establecer la completitud de un ciclo de la espiral, y proporcionan hitos de decisin antes de continuar el proyecto de desarrollo del software.

EL PROCESO UNIFICADO DE DESARROLLO DE SOFWAREEl Proceso Unificado de Desarrollo Software o simplemente Proceso Unificado es un marco de desarrollo de software que se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y por ser iterativo e incremental. El refinamiento ms conocido y documentado del Proceso Unificado es el Proceso Unificado de Rational o simplemente RUP. El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo extensible que puede ser adaptado a organizaciones o proyectos especficos. De la misma forma, el Proceso Unificado de Rational, tambin es un marco de trabajo extensible, por lo que muchas veces resulta imposible decir si un refinamiento particular del proceso ha sido derivado del Proceso Unificado o del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a un mismo concepto. El nombre Proceso Unificado se usa para describir el proceso genrico que incluye aquellos elementos que son comunes a la mayora de los refinamientos existentes. Tambin permite evitar problemas legales ya que Proceso Unificado de Rational o RUP son marcas registradas por IBM (desde su compra de Rational Software Corporation en 2003). El primer libro sobre el tema se denomin, en su versin espaola, El Proceso Unificado de Desarrollo de Software (ISBN 84-7829-036-2) y fue publicado en 1999 por Ivar Jacobson, Grady Booch y James Rumbaugh, conocidos tambin por ser los desarrolladores del UML, el Lenguaje Unificado de Modelado. Desde entonces los autores que publican libros sobre el tema y que no estn afiliados

LEONEL ABAD MNDEZ

Pgina 14


a Rational utilizan el trmino Proceso Unificado, mientras que los autores que pertenecen a Rational favorecen el nombre de Proceso Unificado de Rational. CARACTERISTICAS Iterativo e Incremental: El Proceso Unificado es un marco de desarrollo iterativo e incremental compuesto de cuatro fases denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una de estas fases es a su vez dividida en una serie de iteraciones (la de inicio slo consta de varias iteraciones en proyectos grandes). Estas iteraciones ofrecen como resultado un incremento del producto desarrollado que aade o mejora las funcionalidades del sistema en desarrollo. Cada una de estas iteraciones se divide a su vez en una serie de disciplinas que recuerdan a las definidas en el ciclo de vida clsico o en cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba. Aunque todas las iteraciones suelen incluir trabajo en casi todas las disciplinas, el grado de esfuerzo dentro de cada una de ellas vara a lo largo del proyecto.

Diagrama ilustrando como el nfasis relativo en las distintas disciplinas cambia a lo largo del proyecto. Dirigido por los casos de usoEn el Proceso Unificado los casos de uso se utilizan para capturar los requisitos funcionales y para definir los contenidos de las iteraciones. La idea es que cada iteracin tome un conjunto de casos de uso o escenarios y desarrolle LEONEL ABAD MNDEZ Pgina 15


todo el camino a travs de las distintas disciplinas: diseo, implementacin, prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se est Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de ARLOW, Jim que menciona el tema. Centrado en la arquitectura El Proceso Unificado asume que no existe un modelo nico que cubra todos los aspectos del sistema. Por dicho motivo existen mltiples modelos y vistas que definen la arquitectura de software de un sistema. La analoga con la construccin es clara, cuando construyes un edificio existen diversos planos que incluyen los distintos servicios del mismo: electricidad, fontanera, etc. Enfocado en los riesgos: El Proceso Unificado requiere que el equipo del proyecto se centre en identificar los riesgos crticos en una etapa temprana del ciclo de vida. Los resultados de cada iteracin, en especial los de la fase de Elaboracin, deben ser seleccionados en un orden que asegure que los riesgos principales son considerados primero. Lenguaje unificado de modelado: El Lenguaje unificado de modelado no es el sucesor de la oleada de mtodos de anlisis y diseo orientados a objetos que surgi a finales de la dcada de los 1980 y principios de la siguiente. El UML unifica, sobre todo, los mtodos de Booch, Rumbaugh, Brhl (OMT) y Jacobson, pero su alcance ha llegado a formar parte fundamental de la Ingeniera de Software tras su estandarizacin en 1997 con el OMG (Object Management Group o Grupo de administracin de objetos). Por qu analizar y disear? En resumidas cuentas, la cuestion fundamental del desarrollo del software es la escritura del cdigo. Despus de todo, los diagramas son solo imagenes bonitas. Ningun usuario va a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funcione (UML Gota a Gota, Addison Wesley, Pag 7). Por lo tanto, cuando considere usar el UML es importante preguntarse por qu lo har y como le ayudara a usted cuando llegue el momento de escribir el codigo. No existe una evidencia empirica adecuada que demuestre si estas tecnicas son buenas o malas.

LEONEL ABAD MNDEZ

Pgina 16


MODELO DE PROCESO DE SOFWARE IEEE.Segn la definicin del IEEE, citada por [Lewis 1994] "software es la suma total de los programas de computadora, procedimientos, reglas, la documentacin asociada y los datos que pertenecen a un sistema de cmputo". Segn el mismo autor, "un producto de software es un producto diseado para un usuario". En este contexto, la Ingeniera de Software (SE del ingls Software Engineering) es un enfoque sistemtico del desarrollo, operacin, mantenimiento y retiro del software", que en palabras ms llanas, se considera que "la Ingeniera de Software es la rama de la ingeniera que aplica los principios de la ciencia de la computacin y las matemticas para lograr soluciones costo-efectivas (eficaces en costo o econmicas) a los problemas de desarrollo de software", es decir, "permite elaborar consistentemente productos correctos, utilizables y costo-efectivos" [Cota 1994]. El proceso de ingeniera de software se define como "un conjunto de etapas parcialmente ordenadas con la intencin de logra un objetivo, en este caso, la obtencin de un producto de software de calidad" [Jacobson 1998].El proceso de desarrollo de software "es aquel en que las necesidades del usuario son traducidas en requerimientos de software, estos requerimientos transformados en diseo y el diseo implementado en cdigo, el cdigo es probado, documentado y certificado para su uso operativo". Concretamente "define quin est haciendo qu, cundo hacerlo y cmo alcanzar un cierto objetivo" [Jacobson 1998]. El proceso de desarrollo de software requiere por un lado un conjunto de conceptos, una metodologa y un lenguaje propio. A este proceso tambin se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepcin, elaboracin, construccin y transicin. La concepcin define le alcance del proyecto y desarrolla un caso de negocio. La elaboracin define un plan del proyecto, especifica las caractersticas y fundamenta la arquitectura. La construccin crea el producto y la transicin transfiere el producto a los usuarios. Actualmente se encuentra en una etapa de madurez el enfoque Orientado a Objetos (OO) como paradigma del desarrollo de sistemas de informacin. El Object Management Group (OMG) es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnologa de informacin OO. El OMG tiene como objetivo central la promocin, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especificaciones entorno a la tecnologa OO. Una de las especificaciones ms importantes es la adopcin en 1998 del Lenguaje de LEONEL ABAD MNDEZ Pgina 17


Modelado Unificado o UML (del ingls Unified Modeling Language) como un estndar, que junto con el Proceso Unificado estn consolidando la tecnologa OO.

HERRAMIENTA CASE

Captura de pantalla del editor UML Umbrello

Las herramientas

CASE (Computer Aided Software Engineering, Ingeniera

de

Software Asistida por Computadora) son diversas aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el coste de las mismas en trminos de tiempo y de dinero. Estas herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en tareas como el proceso de realizar un diseo del proyecto, clculo de costes, implementacin de parte del cdigo automticamente con el diseo dado, compilacin automtica,

documentacin o deteccin de errores entre otras. Sistema de software que intenta proporcionar ayuda automatizada a las actividades del proceso de software. Los sistemas CASE a menudo se utilizan como apoyo al mtodo. HISTORIA Ya en los aos 70 un proyecto llamado ISDOS dise un lenguaje, y por lo tanto un producto, que analizaba la relacin existente entre los requisitos de un problema y las necesidades que stos generaban, el lenguaje en cuestin se denominaba PSL LEONEL ABAD MNDEZ Pgina 18


(Problem Statement Language) y la aplicacin que ayudaba a buscar las necesidades de los diseadores PSA (Problem Statement Analyzer). Aunque sos son los inicios de las herramientas informticas que ayudan a crear nuevos proyectos informticos, la primera herramienta CASE fue Excelerator que sali a la luz en el ao 1984 y trabajaba bajo una plataforma PC. Las herramientas CASE alcanzaron su techo a principios de los aos 90. En la poca en la que IBM haba conseguido una alianza con la empresa de software AD/Cycle para trabajar con sus mainframes, estos dos gigantes trabajaban con herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha muerto completamente abriendo el mercado de diversas herramientas ms especficas para cada fase del ciclo de vida del software. OBJETIVOS Mejorar la productividad en el desarrollo y mantenimiento del software. Aumentar la calidad del software. Reducir el tiempo y coste de desarrollo y mantenimiento de los sistemas informticos. Mejorar la planificacin de un proyecto Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a la bsqueda de soluciones para los requisitos. Automatizar el desarrollo del software, la documentacin, la generacin de cdigo, las pruebas de errores y la gestin del proyecto. Ayuda a la reutilizacin del software, portabilidad y estandarizacin de la documentacin Gestin global en todas las fases de desarrollo de software con una misma herramienta. Facilitar el uso de las distintas metodologas propias de la ingeniera del software.

CLASIFICACION LEONEL ABAD MNDEZ Pgina 19


Aunque no es fcil y no existe una forma nica de clasificarlas, las herramientas CASE se pueden clasificar teniendo en cuenta los siguientes parmetros: Las plataformas que soportan. Las fases del ciclo de vida del desarrollo de sistemas que cubren. La arquitectura de las aplicaciones que producen. Su funcionalidad. La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo que cubren: Upper CASE (U-CASE), herramientas que ayudan en las fases

de planificacin, anlisis de requisitos y estrategia del desarrollo, usando, entre otros diagramas UML. Middle CASE (M-CASE), herramientas para automatizar tareas en

el anlisis y diseo de la aplicacin. Lower CASE (L-CASE), herramientas que semi-automatizan la generacin de cdigo, crean programas de deteccin de errores, soportan la depuracin de programas y pruebas. Adems automatizan la documentacin completa de la aplicacin. Aqu pueden incluirse las herramientas de Desarrollo rpido de aplicaciones. Existen otros nombres que se le dan a este tipo de herramientas, y que no es una clasificacin excluyente entre s, ni con la anterior: Integrated CASE (I-CASE), herramientas que engloban todo el proceso de desarrollo software, desde anlisis hasta implementacin. MetaCASE, herramientas que permiten la definicin de nuestra propia tcnica de modelado, los elementos permitidos del metamodelo generado se guardan en un repositorio y pueden ser usados por otros analistas, es decir, es como si definiramos nuestro propio UML, con nuestros elementos, restricciones y relaciones posibles. CAST (Computer-Aided Software Testing), herramientas de soporte a la prueba de software. IPSE (Integrated Programming Support Environment), herramientas que soportan todo el ciclo de vida, incluyen componentes para la gestin de proyectos y gestin de la configuracin. LEONEL ABAD MNDEZ Pgina 20


Por funcionalidad podramos diferenciar algunas como: Herramientas de generacin semiautomtica de cdigo. Editores UML. Herramientas de Refactorizacin de cdigo. Herramientas de mantenimiento como los sistemas de control de versiones.

LEONEL ABAD MNDEZ

Pgina 21

Documents

MODELOS PRESCRIPTIVOS DEL DESARROLLO DE SISTEMAS DE INFORMACIÓN