Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

UNIDAD II CONCEPTOS BSICOS DEL DESARROLLO DE SISTEMAS DE INFORMACIN 2.1 Ciclos de vida de desarrollo de los sistemas 2.1.1 Ciclo de vida clsico El modelo de cascada Gustavo Donoso: El modelo de cascada es tambin conocido como Modelo en cascada o Modelo lineal secuencial o Ciclo de vida bsico o Ciclo de vida clsico. Es un refinamiento altamente influenciado para 1970 del modelo de etapas. Existe, para este modelo, un reconocimiento de los ciclos de retroalimentacin entre etapas, y una gua para confinar las retroalimentaciones a las etapas sucesivas con el objetivo de minimizar el costo del re-trabajo involucrado en retroalimentaciones a travs de muchas etapas. Las ventajas que presentan tanto el modelo de etapas y de cascada tiene relacin con la idea de postular un marco de trabajo claro, que reconoce y define las actividades involucradas en el desarrollo de software, permitiendo establecer relaciones de cooperacin entre ellas. Corresponden, tambin, a los mtodos ms usados en desarrollo de software y que han sido exitosos durante dcadas tanto en el desarrollo de grandes sistemas como en el de pequeos. Tanto el modelo de etapas como el de cascada, presentan algunas dificultades comunes. Por ejemplo, la especificacin de los problemas. Ambos mtodos asumen que el diseador puede distinguir entre lo que el sistema debe hacer y como el sistema lo har; pero algunos problemas no pueden ser divididos tan fcilmente para ser atacados desde este prisma. Por otro lado, generalmente los requerimientos son especificados al inicio del proyecto y, paradojalmente, cuando se tiene la claridad suficiente para definir precisamente lo que se quiere es cuando se est en las ltimas etapas del proyecto. Esto es consecuencia, en general, de que los clientes no estn familiarizados con la tecnologa, con lo cual producen requerimientos muy vagos, que son interpretados arbitrariamente por los desarrolladores. Otro factor importante es que estos mtodos asumen que una vez que los requerimientos han sido definidos entonces ellos no cambiarn ms. Pero, dependiendo de la complejidad del proyecto, la implementacin final puede ocurrir meses o, eventualmente, aos despus de que los requerimientos han sido especificados; as, en las ltimas etapas del proyecto, los requerimientos pueden haber cambiado. Existira un nfasis en la elaboracin de documentos. El sistema completo es descrito y registrado en papel, cada etapa produce cierta cantidad de documentos. Esto lleva a que, por ejemplo, para sistemas complejos las especificaciones de 1

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

requerimientos pueden ser de cientos de pginas, explicando todos u cada uno de los detalles del sistema. Y es difcil poder visualizar a priori, desde ste volumen de papel, las caractersticas del sistema. Por ltimo, se ha detectado que el enfoque lineal de estos mtodos no sera el adecuado para reflejar el proceso de desarrollo de software. Esto explica que se diga que para algunos proyectos el modelo clsico los lleva a seguir las etapas en orden incorrecto. Ms an, es posible que todas las etapas del proyecto, estn comprimidas dentro de cada una. Como se ha podido observar, la especificacin de mtodos ms acabados para el desarrollo de software no logra superar el problema de la distancia entre la visin del usuario y la del desarrollador, ya que no se ha buscado resolver ese problema, sino que las soluciones se centraron principalmente en la divisin de las tareas con miras al control de las mismas, lo que si bien soluciona el problema de especificar y luego programar, crea otros, como el presentado en el prrafo anterior, en que no todos los problemas podran ser abordados desde una misma perspectiva de orden en las etapas.

Modelo de Cascada

Ingeniera de software 2.1.2 El modelo de etapas

Lic. Comp. Guillermo Mera Callejas

Gustavo Donoso: En 1956, el enfrentarse a un gran sistema de software como el SemiAutomated Ground Environment (SAGE) hizo que se reconocieran los problemas inherentes a la codificacin y esto llev al desarrollo del modelo de etapas, con el objetivo de poder mejorar estos nuevos problemas. Este modelo estipula que el software ser desarrollado en sucesivas etapas: 1. Plan operativo Etapa donde se define el problema a resolver, las metas del proyecto, las metas de calidad y se identifica cualquier restriccin aplicable al proyecto.

2. Especificacin de requerimientos 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 requerimientos. 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, tienen 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 requerimientos 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. Mantencin La mantencin ocurre cuando existe algn problema dentro de un sistema existente, e involucrara la correccin de errores que no fueron descubiertos 3

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

en las fases de prueba, mejoras en la implementacin de las unidades del sistema y cambios para que responda a los nuevos requerimientos. Las mantenciones se puede clasificar en: correctiva, adaptativa, perfectiva y preventiva.

Figura 1: Modelo de Etapas

El modelo de etapas consideraba que cada una de ellas debera ir a continuacin de la anterior, poniendo nfasis en la documentacin que resulta de cada una y que es la entrada de la siguiente, formalizando los procedimientos de planificacin y de control. Todo tendiente a conformar una cadena de produccin de software, de manera similar a una cadena de montaje de automviles. Pero ello no logra que las causas de fondo que hicieron que se replantease el modelo de codificar y fijar desapareciesen. Todava existe la distancia entre el programador (ahora desarrollador) y el usuario, esta distancia est dada por dominios de accin distintos. La iteracin de aproximacin es ahora ms factible, pero tambin resulta onerosa, es necesario instalar todo el software nuevamente en la cadena de montaje para su revisin y reconstruccin.

Ingeniera de software 2.1.3 Prototipos

Lic. Comp. Guillermo Mera Callejas

El desarrollo orientado a prototipos Gustavo Donoso: Si bien algunos autores consideran que esto es parte del ciclo de vida clsico (Boehm, 1988), es tambin posible verlo como un mtodo independiente. Una definicin de un prototipo en software podra ser: Las fases que comprende el mtodo de desarrollo orientado a prototipos seran:

Es un modelo del comportamiento del sistema que puede ser usado para entenderlo

completamente o ciertos aspectos de l y as (a) Investigacin preliminar clarificar los requerimientos... Un prototipo es Las metas principales de una representacin de un sistema, aunque no es esta fase son: un sistema completo, posee las caractersticas del determinar el problema y su mbito, la sistema final o parte de ellas" importancia y sus efectos potenciales sobre la organizacin por una parte y, por otro lado, identificar una idea general de la solucin para realizar un estudio de factibilidad que determine la factibilidad de una solucin software.

(b) Definicin de los requerimientos del sistema El objetivo de esta etapa es registrar todos los requerimientos y deseos que los usuarios tienen en relacin al proyecto bajo desarrollo. Esta etapa es la ms importante de todo el ciclo de vida, es aqu donde el desarrollador determina los requisitos mediante la construccin, demostracin y retroalimentaciones del prototipo. Por lo mismo esta etapa ser revisada con ms detalle luego de esta descripcin.

(c) Diseo tcnico Durante la construccin del prototipo, el desarrollador ha obviado el diseo detallado. El sistema debe ser entonces rediseado y documentado segn los estndares de la organizacin y para ayudar a las mantenciones futuras. Esta fase de diseo tcnico tiene dos etapas: por un lado, la produccin de una documentacin de diseo que especifica y describe la estructura del software, el control de flujo, las interfaces de usuario y las funciones y, como segunda etapa, la produccin de todo lo requerido para promover cualquier mantencin futura del software.

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

(d) Programacin y prueba Es donde los cambios identificados en el diseo tcnico son implementados y probados para asegurar la correccin y completitud de los mismos con respecto a los requerimientos.

(e) Operacin y mantencin La instalacin del sistema en ambiente de explotacin, en este caso, resulta de menor complejidad, ya que se supone que los usuarios han trabajado con el sistema al hacer las pruebas de prototipos. Adems, la mantencin tambin debera ser una fase menos importante, ya que se supone que el refinamiento del prototipo permitira una mejor claridad en los requerimientos, por lo cual las mantenciones perfectivas se reduciran. Si eventualmente se requiriese una mantencin entonces el proceso de prototipado es repetido y se definir un nuevo conjunto de requerimientos. La fase ms importante corresponde a la definicin de requerimientos, la cual correspondera a un proceso que busca aproximar las visiones del usuario y del desarrollador mediante sucesivas iteraciones. La definicin de requerimientos consiste de cinco etapas entre dos de las cuales se establece un ciclo iterativo:

(f) Anlisis grueso y especificacin El propsito de esta subfase es desarrollar un diseo bsico para el prototipo inicial.

(g) Diseo y construccin El objetivo de esta subfase es obtener un prototipo inicial. El desarrollador debe concentrarse en construir un sistema con la mxima funcionalidad, poniendo nfasis en la interface del usuario.

(h) Evaluacin Esta etapa tiene dos propsitos: extraer a los usuarios la especificacin de los requerimientos adicionales del sistema y verificar que el prototipo desarrollado lo haya sido en concordancia con la definicin de requerimientos del sistema. Si los usuarios identifican fallas en el prototipo, entonces el desarrollador simplemente corrige el prototipo antes de la siguiente evaluacin. El prototipo es repetidamente modificado y evaluado hasta que todos los requerimientos del sistema han sido satisfechos. El proceso de evaluacin puede ser dividido en cuatro pasos separados: preparacin, demostracin, uso del prototipo y discusin de comentarios. En esta fase se decide si el prototipo es aceptado o modificado.

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

(i) Modificacin Esto ocurre cuando la definicin de requerimientos del sistema es alterada en la subfase de evaluacin. El desarrollador entonces debe modificar el prototipo de acuerdo a los comentarios hechos por los usuarios.

(j) Trmino Una vez que se ha desarrollado un prototipo estable y completo, es necesario ponerse de acuerdo en relacin a aspectos de calidad y de representacin del sistema.

En la siguiente figura se puede ver un esquema en que estas etapas se realizan, note que la especificacin de requerimientos est claramente diferenciada de las dems. Es en ella donde se utiliza el prototipado, ya que permite entregar al usuario lo que sera una visin la solucin final en etapas tempranas del desarrollo, reduciendo tempranamente los costos de especificaciones errneas. Modelo de desarrollo orientado a prototipos. Las ventajas de un enfoque de desarrollo orientado a prototipos estn dadas por: reduccin de la incertidumbre y del riesgo, reduccin de tiempo y de costos, incrementos en la aceptacin del nuevo sistema, mejoras en la administracin de proyectos, mejoras en la comunicacin entre desarrolladores y clientes, etc.

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Si bien, el desarrollo orientado a prototipos tiene considerables ventajas, tambin presenta desventajas como: la dependencia de las herramientas de software para el xito ya que la necesidad de disminucin de incertidumbre depende de las iteraciones del prototipo, entre ms iteraciones existan mejor y esto ltimo se logra mediante el uso de mejores herramientas lo que hace a este proceso dependiente de las mismas. Tambin, no es posible aplicar la metodologa a todos los proyectos de software y, finalmente, la mala interpretacin que pueden hacer los usuarios del prototipo, al cual pueden confundir con el sistema terminado.

No se puede desconocer que la fase de definicin de requerimientos se ha perfeccionado en dos aspectos importantes: primero se ha aproximado los visiones del usuario y el desarrollador, lo cual representa el beneficio de establecer una base comn de comunicacin; tambin, el hacer explcita la posibilidad de iterar sobre estos dominios permitira que la convergencia de los mismos sea una posibilidad cierta.

Pero lo anterior no asegura el xito, por ejemplo, qu certeza existe en que esta iteracin sea en la direccin correcta y lleve a la convergencia de los dominios; no se puede desconocer las diferencias que existen entre la prueba de un prototipo de software en la fase de definicin de requerimientos y el uso del mismo ya como un producto terminado. Para explicar esto, podemos hablar de dos dominios en el usuario, uno que es el que se establece cuando se prueba el prototipo y otro, distinto por cierto, el que ocurre cuando el usuario hace uso del software en ambiente de explotacin.

2.1.4

RAD

Ingeniera de software 2.1.5 Espiral

Lic. Comp. Guillermo Mera Callejas

Gustavo Donoso: El modelo Espiral de Boehm para Ingeniera de Software agrupa las mejores caractersticas del modelo del ciclo de vida clsico y de prototipos. Pero tambin agrega nuevas funciones que no estn incluidas en los otros modelos, como el anlisis de riesgo. El modelo espiral define cuatro actividades principales para el ciclo de vida. Planificacin La determinacin de los objetivos del proyecto, alternativas y restricciones. Anlisis de Riesgo El anlisis de alternativas y la identificacin y solucin de riesgos. Ingeniera Desarrollo del producto. Evaluacin del cliente El asentimiento de los resultados de la ingeniera. El modelo es representado por una espiral dividida en cuatro cuadrantes, en que cada uno describe las actividades mencionadas anteriormente. El modelo espiral utiliza un esquema de desarrollo iterativo donde la primera iteracin comienza en el centro del crculo e, incrementalmente, se va desplazando hacia afuera. Las siguientes iteraciones sucesivas son versiones ms completas del software que est siendo construido. Al principio de cada iteracin del ciclo de vida se hace un anlisis de riesgo, mientras, por el otro extremo, la revisin del proyecto se realiza al final de la iteracin. As, se puede contrarrestar cualquier riesgo observado mediante las acciones adecuadas en el tiempo preciso.

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

El modelo espiral es visto como un enfoque ms realista para el desarrollo de grandes sistemas de software. Usa un mtodo evolucionario para desarrollo y prototipos como

una tcnica de reduccin de riesgo (pese a que los prototipos pueden ser usados en cualquier etapa dentro del ciclo de vida). Tambin utiliza el enfoque de sistematizacin y el 'desarrollo en etapas' del ciclo de vida clsico, pero, con la diferencia que todos estn incorporados dentro del esquema iterativo planteado por el modelo espiral.

10

Ingeniera de software 2.1.6 Desarrollo evolutivo

Lic. Comp. Guillermo Mera Callejas

El modelo de desarrollo evolutivo Gustavo Donoso:

El desarrollo evolutivo es una metodologa de desarrollo de software muy relacionada con, pero claramente distinta de, desarrollo por prototipos. El nfasis esta puesto sobre la importancia de obtener un sistema de produccin flexible y expandible. As, si los requerimientos cambian durante el desarrollo del sistema, entonces con un mnimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible.

La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que el desarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendra la propiedad de satisfacer los nuevos requerimientos lo ms rpido posible. En contraste, prototipos usa un enfoque iterativo solo para determinar los requerimientos organizacionales. Por lo tanto el tiempo tomado entre cada iteracin es mucho ms importante para el desarrollo evolutivo.

El desarrollo evolutivo asume que los requerimientos de un proyecto estn sujetos a cambios continuos, por lo cual es necesario definir una estrategia de desarrollo que refleje esta situacin. En cambio, el desarrollo orientado a prototipos, as como los anteriores, asume que los requerimientos "reales" existen y se vale de las iteraciones del prototipo para establecerlos y modelarlos.

La idea entonces de la metodologa de desarrollo evolutivo es estar liberando constantemente una nueva versin del sistema que sea completamente funcional; as, cada sistema producto de las iteraciones sucesivas del mtodo tendra incorporado los nuevos requerimientos que ha sido posible identificar y que no estaran considerados en la anterior versin.

As, las etapas del desarrollo evolutivo tienen por objetivo extender los incrementos de un producto de software operacional, en las direcciones determinadas por la evolucin de la experiencia operacional.

11

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

El modelo de desarrollo evolutivo puede ser idealmente asociado a un lenguaje de aplicacin de cuarta generacin y mejor an a situaciones en que el usuario dice, "yo no puedo hablarte sobre lo que yo quiero, pero yo lo reconocera si lo viese". As, este mtodo entregara al usuario rpidamente una capacidad operativa inicial y, adems, establecera una base real operacin para determinar las mejoras subsecuentes en el producto.

Pero, existiran algunas dificultades tcnicas que no pueden dejar de ser mencionadas, por ejemplo: - No facilita la integracin de aplicaciones que han sido desarrolladas como sistemas independientes.

- Facilita la posibilidad de que existan casos de "esclerosis de informacin", en el sentido que trabajos temporales alrededor de algunas deficiencias del software se solidifican como poderes inmodificables a la evolucin. Es decir, en la medida que se evoluciona, esta misma facilidad a la evolucin llevara a que no sea posible seguir evolucionando.

- Pueden ocurrir que el software nuevo es un reemplazo incremental de un subsistema dentro de un gran sistema existente. Si el sistema existente est pobremente modularizado, entonces es obvia la dificultad en hacer que la nueva versin se acople con facilidad al resto. 12

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

El mtodo evolutivo tiene la gran ventaja de reconocer la existencia de una constante de cambios en los requerimientos y, desde esta premisa, propone una solucin, la cual es vlida para la solucin de ese problema pero que no resolvera la inquietud original, esto es que el mtodo no facilita elementos que permitan reducir la distancia conceptual entre los dominios del desarrollador y del usuario.

Con la existencia del mtodo evolutivo se configura una nueva problemtica en el desarrollo de sistemas, es decir, la crisis se expande ahora en el sentido que no slo se requiere reflejar lo ms fielmente posible las necesidades del usuario, sino que ahora los ambientes en que el sistema est inserto estn sujetos a cambios y estos cambios inciden en la efectividad del software desarrollado. Lo anterior fue articulado por Meir M. Lehman a principio de la dcada de los ochenta, al definir las leyes de la evolucin del software, en que las dos primeras leyes tienen directa relacin con lo que se describe. Veamos a Lehman citado por Ian Sommerville, en el libro Ingeniera de Software:

Lehman propone que la evolucin de un sistema de software est sujeta a varias leyes. Ha determinado estas leyes a partir de observaciones experimentales de varios sistemas, como los grandes sistemas operativos (...). Dice Lehman que hay cinco leyes de la evolucin de los programas: 1. Cambio Continuo. Un programa que se utiliza en un ambiente del mundo real debe cambiar o ser cada vez menos til en ese ambiente. 2. Complejidad creciente. A medida que un programa en evolucin cambia, su estructura se hace ms compleja, a menos que se lleven a cabo esfuerzos activos para evitar este fenmeno. 3. Evolucin del programa. La evolucin del programa es un proceso autorregulador, y una medicin de atributos del sistema, como el tamao, el tiempo entre versiones, el nmero de errores advertidos, etc., revela las tendencias estadsticas significativas y las caractersticas invariantes. 4. Conservacin de la estabilidad organizativa. Durante el tiempo de vida de un programa, su rapidez de desarrollo es casi constante e independiente de los recursos dedicados al desarrollo del sistema.

5. Conservacin de la familiaridad. Durante el tiempo de vida de un sistema, la evolucin del cambio del sistema en cada versin es, aproximadamente, constante. 13

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Sommerville considera las "leyes" de Lehman como elementos positivos en la configuracin del mbito en que se desarrollan los sistemas, por ejemplo, dice que las dos primeras hiptesis de Lehman son casi con certeza vlidas. Interpretando la primera como: ...El razonamiento subyacente en la primera ley... es que cuando un sistema de software (sobre todo uno grande) se construye para modelar algn ambiente y despus se introduce en l, modificndose as el ambiente original con la presencia del sistema de software... No puede ser ms interesante para los propsitos de esta revisin la caracterstica planteada por esta hiptesis, es decir, si se desarrolla software no se podra pensar desde la perspectiva de estabilidades, todo lo contrario, necesariamente es el cambio el motor y el configurador de los sistemas de software. Aqu el punto es la introduccin de una nueva perspectiva al problema del desarrollo de software, perspectiva que ser determinante en el planteamiento de un modelo que permita reflejarla. Lo expresado en la primera ley, configura un nuevo problema -como se haba anticipado- para el desarrollo de software, adems de la distancia conceptual entre desarrollador y usuario, existira el problema de la evolucin constante de la organizaciones o, ms claramente, la connaturalidad de las organizaciones al cambio como elemento subyacente en su ser organizacional. Situacin que se haba anticipado en el curso de "Ambientes..."

La segunda ley en el anlisis de Somerville corresponde al hecho de que la estructura del programa original se estableci para aplicarlo a un conjunto de necesidades iniciales. A medida que se produce el cambio evolutivo de esas necesidades, la estructura original se degrada y con ello se va haciendo ms compleja ya que al ir incrementndose la distancia conceptual entre el software y el medio que lo contiene, ste va estando cada vez ms presente en el hacer cotidiano, formulando quiebres constantes sobre el sistema de trabajo lo que imprime un sello de complejidad a la utilizacin del software. Las siguientes leyes tienen relacin con las caractersticas de las organizaciones y de los individuos que participan en el proceso de desarrollo de software. Lehman afirma que las organizaciones se esfuerzan por lograr la estabilidad e intentan evitar cambios drsticos o repentinos. Por tanto, a medida que se aaden ms recursos a un proyecto de software, el efecto evolutivo de la adicin de nuevos recursos se va reduciendo, hasta que la adicin de nuevos recursos no produce ningn efecto. Si bien, estas ltimas leyes no resultan tan obvias como las primeras y podran ser cuestionadas, es posible que la ltima, que tiene que ver con la conservacin de la familiaridad sea la ms til, como tambin la de reduccin de personal, en el sentido que cuanta ms gente trabaje, menos productivo ser cada miembro del proyecto. Las proposiciones de Lehman se orientaron a la creacin de un mtodo de desarrollo que considerase estas caractersticas.

14

Ingeniera de software 2.1.7

Lic. Comp. Guillermo Mera Callejas

El Proceso Unificado de Desarrollo de Software (RUP)

Introduccin El Proceso Unificado es un proceso de software genrico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaos de proyectos. Provee un enfoque disciplinado en la asignacin de tareas y responsabilidades dentro de una organizacin de desarrollo. Su meta es asegurar la produccin de software de muy alta calidad que satisfaga las necesidades de los usuarios finales, dentro de un calendario y presupuesto predecible. El Proceso Unificado tiene dos dimensiones (Error! No se encuentra el origen de la referencia.):

Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lgica de acuerdo a su naturaleza. La primera dimensin representa el aspecto dinmico del proceso conforme se va desarrollando, se expresa en trminos de fases, iteraciones e hitos (milestones). La segunda dimensin representa el aspecto esttico del proceso: cmo es descrito en trminos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles. El Proceso Unificado se basa en componentes (component-based), lo que significa que el sistema en construccin est hecho de componentes de software interconectados por medio de interfaces bien definidas (well-defined interfaces). El Proceso Unificado usa el Lenguaje de Modelado Unificado (UML) en la preparacin de todos los planos del sistema. De hecho, UML es una parte integral del Proceso Unificado, fueron desarrollados a la par. Los aspectos distintivos del Proceso Unificado estn capturados en tres conceptos clave: dirigido por casos de uso (use-case driven), centrado en la arquitectura (architecture-centric), iterativo e incremental. Esto es lo que hace nico al Proceso Unificado. 15

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

El Proceso Unificado es dirigido por casos de uso Un sistema de software se crea para servir a sus usuarios. Por lo tanto, para construir un sistema exitoso se debe conocer qu es lo que quieren y necesitan los usuarios prospectos. El trmino usuario se refiere no solamente a los usuarios humanos, sino a otros sistemas. En este contexto, el trmino usuario representa algo o alguien que interacta con el sistema por desarrollar. Un caso de uso es una pieza en la funcionalidad del sistema que le da al usuario un resultado de valor. Los casos de uso capturan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso el cual describe la funcionalidad completa del sistema. Este modelo reemplaza la tradicional especificacin funcional del sistema. Una especificacin funcional tradicional se concentra en responder la pregunta: Qu se supone que el sistema debe hacer? La estrategia de casos de uso puede ser definida agregando tres palabras al final de la pregunta: por cada usuario? Estas tres palabras tienen una implicacin importante, nos fuerzan a pensar en trminos del valor a los usuarios y no solamente en trminos de las funciones que sera bueno que tuviera. Sin embargo, los casos de uso no son solamente una herramienta para especificar los requerimientos del sistema, tambin dirigen su diseo, implementacin y pruebas, esto es, dirigen el proceso de desarrollo. An y cuando los casos de uso dirigen el proceso, no son elegidos de manera aislada. Son desarrollados a la par con la arquitectura del sistema, esto es, los casos de uso dirigen la arquitectura del sistema y la arquitectura del sistema influencia la eleccin de los casos de uso. Por lo tanto, al arquitectura del sistema y los casos de uso maduran conforme avanza el ciclo de vida. El Proceso Unificado est centrado en la arquitectura El papel del arquitecto de sistemas es similar en naturaleza al papel que el arquitecto desempea en la construccin de edificios. El edificio se mira desde diferentes puntos de vista: estructura, servicios, plomera, electricidad, etc. Esto le permite al constructor ver una radiografa completa antes de empezar a construir. Similarmente, la arquitectura en un sistema de software es descrita como diferentes vistas del sistema que est siendo construido. El concepto de arquitectura de software involucra los aspectos estticos y dinmicos ms significativos del sistema. La arquitectura surge de las necesidades de la empresa, tal y como las interpretan los usuarios y otros stakeholders, y tal y como estn reflejadas en los casos de uso. Sin embargo, tambin est influenciada por muchos otros factores, tales como la plataforma de software en la que se ejecutar, la disponiblidad de componentes reutilizables, consideraciones de instalacin, sistemas legados, requerimientos no funcionales (ej. desempeo, confiabilidad). La arquitectura es la vista del diseo completo con las caractersticas ms importantes hechas ms visibles y dejando los detalles de lado. Ya que lo importante depende en parte del criterio, el cual a su vez viene con la experiencia, el valor de la arquitectura depende del personal asignado a esta tarea. Sin embargo, el proceso ayuda al arquitecto a enfocarse en las metas correctas, tales como claridad (understandability), flexibilidad en los cambios futuros (resilience) y reuso. 16

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Cmo se relacionan los casos de uso con la arquitectura? Cada producto tiene funcin y forma. Uno slo de los dos no es suficiente. Estas dos fuerzas deben estar balanceadas para obtener un producto exitoso. En este caso funcin corresponde a los casos de uso y forma a la arquitectura. Existe la necesidad de intercalar entre casos de uso y arquitectura. Es un problema del huevo y la gallina. Por una parte, los casos de uso deben, cuando son realizados, acomodarse en la arquitectura. Por otra parte, la arquitectura debe proveer espacio para la realizacin de todos los casos de uso, hoy y en el futuro. En la realidad, ambos arquitectura y casos de uso deben evolucionar en paralelo. El Proceso Unificado es Iterativo e Incremental Desarrollar un producto de software comercial es una tarea enorme que puede continuar por varios meses o aos. Es prctico dividir el trabajo en pequeos pedazos o mini-proyectos. Cada mini-proyecto es una iteracin que finaliza en un incremento. Las iteraciones se refieren a pasos en el flujo de trabajo, los incrementos se refieren a crecimiento en el producto. Para ser ms efectivo, las iteraciones deben estar controladas, esto es, deben ser seleccionadas y llevadas a cabo de una manera planeada. Los desarrolladores basan su seleccin de qu van a implementar en una iteracin en dos factores. Primero, la iteracin trata con un grupo de casos de uso que en conjunto extienden la usabilidad del producto. Segundo, la iteracin trata con los riesgos ms importantes. Las iteraciones sucesivas construyen los artefactos del desarrollo a partir del estado en el que fueron dejados en la iteracin anterior. En cada iteracin, los desarrolladores identifican y especifican los casos de uso relevantes, crean el diseo usando la arquitectura como gua, implementan el diseo en componentes y verifican que los componentes satisfacen los casos de uso. Si una iteracin cumple sus metas y usualmente lo hace el desarrollo contina con la siguiente iteracin. Cuando la iteracin no cumple con sus metas, los desarrolladores deben revisar sus decisiones previas y probar un nuevo enfoque.

Conclusin Los conceptos anteriormente tratados dirigido por casos de uso, centrado en arquitectura, desarrollo iterativo e incremental son igualmente importantes. La arquitectura provee la estructura sobre la cual guiar el trabajo en iteraciones, mientras que los casos de uso definen las metas y dirigen el trabajo en cada iteracin. Remover cualquiera de estos conceptos reducir severamente el valor del Proceso Unificado. Es como una mesa de tres patas, sin alguna de ellas, la mesa se caer.

17

Ingeniera de software 2.2 Definicin de sistema de informacin

Lic. Comp. Guillermo Mera Callejas

Introduccin: Un sistema de informacin es un conjunto de elementos que interactan entre s con el fin de apoyar las actividades de una empresa o negocio. El equipo computacional: el hardware necesario para que el sistema de informacin pueda operar. El recurso humano que interacta con el Sistema de Informacin, el cual est formado por las personas que utilizan el sistema. Un sistema de informacin realiza cuatro actividades almacenamiento, procesamiento y salida de informacin. bsicas: entrada,

Entrada de Informacin: Es el proceso mediante el cual el Sistema de Informacin toma los datos que requiere para procesar la informacin. Las entradas pueden ser manuales o automticas. Las manuales son aquellas que se proporcionan en forma directa por el usuario, mientras que las automticas son datos o informacin que provienen o son tomados de otros sistemas o mdulos. Esto ltimo se denomina interfaces automticas.

Las unidades tpicas de entrada de datos a las computadoras son las terminales, las cintas magnticas, las unidades de diskette, los cdigos de barras, los escners, la voz, los monitores sensibles al tacto, el teclado y el mouse, entre otras. Almacenamiento de informacin: El almacenamiento es una de las actividades o capacidades ms importantes que tiene una computadora, ya que a travs de esta propiedad el sistema puede recordar la informacin guardada en la seccin o proceso anterior. Esta informacin suele ser almacenada en estructuras de informacin denominadas archivos. La unidad tpica de almacenamiento son los discos magnticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM).

Procesamiento de Informacin: Es la capacidad del Sistema de Informacin para efectuar clculos de acuerdo con una secuencia de operaciones preestablecida. Estos clculos pueden efectuarse con datos introducidos recientemente en el sistema o bien con datos que estn almacenados. Esta caracterstica de los sistemas permite la transformacin de datos fuente en informacin que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyeccin financiera a partir de los datos que contiene un estado de resultados o un balance general de un ao base.

18

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Salida de Informacin: La salida es la capacidad de un Sistema de Informacin para sacar la informacin procesada o bien datos de entrada al exterior. Las unidades tpicas de salida son las impresoras, terminales, diskettes, cintas magnticas, la voz, los graficadores y los plotters, entre otros. Es importante aclarar que la salida de un Sistema de Informacin puede constituir la entrada a otro Sistema de Informacin o mdulo. En este caso, tambin existe una interface automtica de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interface automtica de salida con el Sistema de Contabilidad, ya que genera las plizas contables de los movimientos procesales de los clientes. Actividades que realiza un Sistema de Informacin: Entradas: Datos generales del cliente: nombre, direccin, tipo de cliente, etc. Polticas de crditos: lmite de crdito, plazo de pago, etc. Facturas (interface automtico). Pagos, depuraciones, etc.

Proceso: Clculo de antigedad de saldos. Clculo de intereses moratorios. Clculo del saldo de un cliente.

Almacenamiento: Movimientos del mes (pagos, depuraciones). Catlogo de clientes. Facturas.

Salidas: Reporte de pagos. Estados de cuenta. Plizas contables (interface automtica) Consultas de saldos en pantalla de una terminal.

Las diferentes actividades que realiza un Sistema de Informacin se pueden observar en el diseo conceptual ilustrado en la en la figura 1.2.

Tipos y Usos de los Sistemas de Informacin Durante los prximos aos, los Sistemas de Informacin cumplirn tres objetivos bsicos dentro de las organizaciones: 1. Automatizacin de procesos operativos. 19

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

2. Proporcionar informacin que sirva de apoyo al proceso de toma de decisiones. 3. Lograr ventajas competitivas a travs de su implantacin y uso.

Los Sistemas de Informacin que logran la automatizacin de procesos operativos dentro de una organizacin, son llamados frecuentemente Sistemas Transaccionales, ya que su funcin primordial consiste en procesar transacciones tales como pagos, cobros, plizas, entradas, salidas, etc. Por otra parte, los Sistemas de Informacin que apoyan el proceso de toma de decisiones son los Sistemas de Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisin de Grupo, Sistemas Expertos de Soporte a la Toma de Decisiones y Sistema de Informacin para Ejecutivos. El tercer tipo de sistema, de acuerdo con su uso u objetivos que cumplen, es el de los Sistemas Estratgicos, los cuales se desarrollan en las organizaciones con el fin de lograr ventajas competitivas, a travs del uso de la tecnologa de informacin. Los tipos y usos de los Sistemas de Informacin se muestran en la figura 1.3.

20

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

A continuacin se mencionan las principales caractersticas de estos tipos de Sistemas de Informacin.

Sistemas Transaccionales. Sus principales caractersticas son: A travs de stos suelen lograrse ahorros significativos de mano de obra, debido a que automatizan tareas operativas de la organizacin.

Con frecuencia son el primer tipo de Sistemas de Informacin que se implanta en las organizaciones. Se empieza apoyando las tareas a nivel operativo de la organizacin.

Son intensivos en entrada y salid de informacin; sus clculos y procesos suelen ser simples y poco sofisticados.

Tienen la propiedad de ser recolectores de informacin, es decir, a travs de estos sistemas se cargan las grandes bases de informacin para su explotacin posterior.

Son fciles de justificar ante la direccin general, ya que sus beneficios son visibles y palpables.

Sistemas de Apoyo de las Decisiones. Las principales caractersticas de estos son: Suelen introducirse despus de haber implantado los Sistemas Transaccionales ms relevantes de la empresa, ya que estos ltimos constituyen su plataforma de informacin. La informacin que generan sirve de apoyo a los mandos intermedios y a la alta administracin en el proceso de toma de decisiones.

Suelen ser intensivos en clculos y escasos en entradas y salidas de informacin. As, por ejemplo, un modelo de planeacin financiera requiere poca informacin de entrada, genera poca informacin como resultado, pero puede realizar muchos clculos durante su proceso.

No suelen ahorrar mano de obra. Debido a ello, la justificacin econmica para el desarrollo de estos sistemas es difcil, ya que no se conocen los ingresos del proyecto de inversin.

21

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Suelen ser Sistemas de Informacin interactivos y amigables, con altos estndares de diseo grfico y visual, ya que estn dirigidos al usuario final.

Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos y de decisiones no estructuradas que no suelen repetirse. Por ejemplo, un Sistema de Compra de Materiales que indique cundo debe hacerse un pedido al proveedor o un Sistema de Simulacin de Negocios que apoye la decisin de introducir un nuevo producto al mercado.

Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participacin operativa de los analistas y programadores del rea de informtica. Este tipo de sistemas puede incluir la programacin de la produccin, compra de materiales, flujo de fondos, proyecciones financieras, modelos de simulacin de negocios, modelos de inventarios, etc.

Sistemas Estratgicos. Sus principales caractersticas son: Su funcin primordial no es apoyar la automatizacin de procesos operativos ni proporcionar informacin para apoyar la toma de decisiones.

Suelen desarrollarse in house, es decir, dentro de la organizacin, por lo tanto no pueden adaptarse fcilmente a paquetes disponibles en el mercado.

Tpicamente su forma de desarrollo es a base de incrementos y a travs de su evolucin dentro de la organizacin. Se inicia con un proceso o funcin en particular y a partir de ah se van agregando nuevas funciones o procesos.

Su funcin es lograr ventajas que los competidores no posean, tales como ventajas en costos y servicios diferenciados con clientes y proveedores. En este contexto, los Sistema Estratgicos son creadores de barreras de entrada al negocio. Por ejemplo, el uso de cajeros automticos en los bancos en un Sistema Estratgico, ya que brinda ventaja sobre un banco que no posee tal servicio. Si un banco nuevo decide abrir sus puerta al pblico, tendr que dar este servicio para tener un nivel similar al de sus competidores.

Apoyan el proceso de innovacin de productos y proceso dentro de la empresa debido a que buscan ventajas respecto a los competidores y una forma de hacerlo en innovando o creando productos y procesos.

22

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Un ejemplo de estos Sistemas de Informacin dentro de la empresa puede ser un sistema MRP (Manufacturing Resoure Planning) enfocado a reducir sustancialmente el desperdicio en el proceso productivo, o bien, un Centro de Informacin que proporcione todo tipo de informacin; como situacin de crditos, embarques, tiempos de entrega, etc. En este contexto los ejemplos anteriores constituyen un Sistema de Informacin Estratgico si y slo s, apoyan o dan forma a la estructura competitiva de la empresa.

Por ltimo, es importante aclarar que algunos autores consideran un cuarto tipo de sistemas de informacin denominado Sistemas Personales de Informacin, el cual est enfocado a incrementar la productividad de sus usuarios.

2.3

Caractersticas de un sistema de informacin

Es muy comn que cuando mencionamos la palabra sistema lo nico que sobrevuele nuestras mentes sean computadoras o artefactos electrnicos conectados entre s, y aunque hay mucho de cierto en este concepto debemos mencionar que el concepto de la palabra sistema posee muchas aceptaciones. Un sistema de informacin es uno de los tipos ms utilizados en la actualidad, para comprender mejor su significado procederemos a definirlo; entendemos por sistema de informacin un conjunto de elementos que interactan entre s con el objetivo de apoyar las actividades de un negocio especfico. Este tipo de sistema se maneja a travs de una computadora la cual contiene un hardware para el primero pueda operar adecuadamente; ste programa realiza cuatro actividades bsicas: entrada, almacenamiento, procesamiento y salida de datos. En la primera actividad se toman los datos que se requieren procesar, las entradas pueden ser manuales u automticas, las primeras son las que se otorgan directamente por el usuarios, mientras que las segundas son datos provenientes de otros mdulos. El almacenamiento de informacin es, sin lugar a dudas, la accin ms importante que realiza, a travs de esta propiedad el sistema recuerda los datos que han sido introducidos en la seccin anterior; stos suelen almacenarse en estructuras conocidas como archivos. El procesamiento est vinculado a la capacidad que tiene el sistema para efectuar clculos de acuerdo a una secuencia de operaciones; esta es la caracterstica que permite la transformacin de datos fuente en informacin vital para luego tomar decisiones. Por ltimo, encontramos la salida, aqu es donde se extrae la informacin procesada hacia el exterior, las unidades tpicas ms conocidas son los cds, impresoras, disekettes, cintas magnticas, etc. Podemos decir que la evolucin de los sistemas de informacin aparece con la primera computadora, la misma estaba justificada por el ahorro de mano de obra y los excesos de papeles que antes prevalecan. 23

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Las primeras aplicaciones que se implanta son las contables ya que los ordenadores estaban destinados a las oficinas de contabilidad, en estos tiempos quienes los manejaban eran administradores sin una preparacin formal en computacin. La etapa de expansin se inicia con la instalacin exitosa del primer sistema de informacin en la organizacin, las aplicaciones se expanden hacia inventarios, facturacin, cheque, proveedores, etc. Por ltimo tenemos la etapa de integracin en donde la integracin de los datos surge como resultado directo de la centralizacin del departamento de sistemas bajo una sola estructura administrativa, aparecieron las tecnologas relacionadas con la base de datos que se complement con una reduccin de precios del hardware y el software. 2.4 Funciones de un sistema de informacin Los sistemas de informacin difieren en sus tipos de entradas y salidas, en el tipo de procesamientos y en su estructura. Estos elementos estn determinados por el propsito u objetivos del sistema, el cual es establecido a su vez, por la organizacin, en todos ellos podemos encontrar un conjunto de funciones que, segn Senn, son las siguientes: 1- Procesamiento de Transacciones: La cual consiste en capturar o recolectar, clasificar, ordenar, calcular, resumir y almacenar los datos originados por las transacciones, que tienen lugar durante la realizacin de actividades en la organizacin. 2- Definicin de Archivos: Consiste en almacenar los datos capturados por el procesamiento de transacciones, de acuerdo a una estructura u organizacin de almacenamiento adecuado (base de datos o archivo) un mtodo que facilite su almacenamiento, actualizacin y acceso, y un dispositivo apropiado de almacenamiento (disco, cintas, diskettes, y otros). 3- Mantenimiento de Archivos: Los archivos o bases de datos del sistema deben mantener actualizados. Las operaciones bsicas de mantenimiento son la insercin, la modificacin y la eliminacin de datos en los medios de almacenamiento. 4- Generacin de Reportes: La realizacin de esta funcin es esencial para el sistema de informacin, ella se encarga de producir la informacin requerida y trasmitirla a los puntos o centros de informacin que la soliciten. Esta transmisin de informacin se puede efectuar mediante el movimiento fsico de los elementos de almacenamiento (papel, cintas magnticas, diskettes, y otros) o mediante la comunicacin de seales elctricas digitales o analgicas a dispositivos receptores (terminales, convertidores, estaciones remotas u otro computador). Los reportes que genera el sistema de informacin se clasifican en: a) Reportes de Errores: Proporcionan informacin sobre los errores que ocurren y se detectan durante el procesamiento de transacciones. b) Reportes de Actividades: Proporcionan informacin sobre las actividades elementos de la organizacin. No estn orientados a la toma de decisiones. Por ejemplo. Listados de empleados, listados de inventarios de piezas, y otros. c) Reportes Regulares: Estn orientados a la toma de decisiones. Se preparan a intervalos definidos de tiempo y en un formato fijo, por lo que se pueden generar automticamente.

24

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

d) Reporte de Excepcin: tiles para controlar situaciones anormales pues sealar la ocurrencia de condiciones "fuera de limite".Tienen un formato predefinido y se pueden generar automticamente bajo solicitud o cuando ocurra la condicin anormal. e) Reportes no Planeados: Requeridos eventualmente para la toma de decisiones. Se generan cuando se solicitan y pueden tener un formato predefinido. f) Reportes Especiales: Requeridos generalmente una sola vez con fines de analizar situaciones o resolver problemas involucran el uso de modelos que respondan a interrogantes del tipo "que ocurre si" No tienen formato predefinido y pueden o no generarse automticamente. Los dos primeros reportes son producidos por los subsistemas de procesamiento de transacciones, mientras que los restantes los producen los subsistemas de procesamientos de informacin. 5- Procesamientos de Consultas: Parte de la informacin requerida por los usuarios responde a interrogantes no predefinidas y cuyas respuestas son generalmente cortas por lo que no requiere un formato complejo como el de los reportes. Estas interrogantes reciben el nombre de consultas interactivas y constituyen un medio directo de comunicacin hombre-maquina. Esta funcin es generalmente ejecutada por los subsistemas de administracin de datos, que facilita el acceso a los datos y de procesamiento de informacin. La mayora de Sistemas de Manejo de Bases de Datos que existen, poseen una herramienta que facilita la realizacin de esta funcin, denominada lenguaje de consultas o de interrogacin o lenguajes para el dilogo hombre-mquina. 6- Mantenimiento de la Integridad de los Datos: Los datos mantenidos por el sistema de informacin deben ser confiables y veraces por lo que una de sus funciones debe garantizar la integridad de tales datos y protegerlos contra accesos indebidos o no autorizados y contra modificaciones mal intencionadas.

2.5 Planeacin, factibilidad y control

Planificacin. La planificacin de un proyecto de software no difiere de la planificacin de cualquier proyecto de ingeniera. Se identifica una serie de tareas del proyecto. Se establecen interdependencias entre las tareas. Se estima el esfuerzo asociado con cada tarea. Se hace la asignacin de personal y de otros recursos. Se crea una "red de tareas". Se desarrolla una agenda de fechas. Seguimiento y Control. Una vez que se ha establecido la agenda de desarrollo, comienza la actividad de seguimiento y control. El gestor del proyecto sigue la pista a cada tarea establecida en la agenda. Si una tarea se sale de la agenda, el gestor puede utilizar una herramienta de planificacin automtica sobre el proyecto para determinar el impacto del error de planificacin sobre los hitos intermedios y sobre la fecha final de entrega. En ese caso se pueden reasignar recursos, reordenar las tareas o (como ltimo recurso) modificar los compromisos de entrega para resolver el problema no detectado. De este modo, se puede controlar mejor el desarrollo del software. Estudio de Factibilidad Factibilidad se refiere a la disponibilidad de los recursos necesarios para llevar a cabo los objetivos o metas sealados, la factibilidad se apoya en 3 aspectos bsicos: Operativo. 25

Ingeniera de software Tcnico. Econmico.

Lic. Comp. Guillermo Mera Callejas

El xito de un proyecto est determinado por el grado de factibilidad que se presente en cada una de los tres aspectos anteriores. Para esto se realiza un estudio de factibilidad que sirve para recopilar datos relevantes sobre el desarrollo de un proyecto y en base a ello tomar la mejor decisin, si procede su estudio, desarrollo o implementacin. El objetivo de un estudio de factibilidad es auxiliar a una organizacin a lograr sus objetivos y cubrir la metas con los recursos actuales en las siguientes reas. Factibilidad Tcnica. Mejora del sistema actual. Disponibilidad de tecnologa que satisfaga las necesidades. Factibilidad Econmica. Tiempo del analista. Costo de estudio. Costo del tiempo del personal. Costo del tiempo. Costo del desarrollo / adquisicin. Factibilidad Operativa. Operacin garantizada. Uso garantizado. La investigacin de factibilidad es un proyecto que consiste en descubrir cuales son los objetivos de la organizacin, luego determinar si el proyecto es til para que la empresa logre sus objetivos. La bsqueda de estos objetivos debe contemplar los recursos disponibles o aquellos que la empresa puede proporcionar, nunca deben definirse con recursos que la empresa no es capaz de dar. En las empresas se cuenta con una serie de objetivos que determinan la posibilidad de factibilidad de un proyecto sin ser limitativos.

2.6.1 Definicin del nuevo sistema

Definicin del problema Delimitacin del problema La delimitacin del problema se refiere a identificar todos aquellos aspectos que son importantes para el desempeo de una actividad y aislar todos aquellos que no interfieren en el mismo. En la delimitacin del problema se deben de escribir cada uno de los recursos y procesos que intervienen dentro del rea del proyecto, para analizar cada uno de ellos y seleccionar aquellos que realmente intervengan dentro del problema identificado. El objetivo de delimitar el problema es disminuir el grado de complejidad del proyecto para atender solo aquellos aspectos que son requeridos. Se deben de proporcionar todos los elementos posibles que ayuden a soportar con bases firmes y concretas todos los elementos (recursos, personal e ideas) que son necesitados por el proyecto para su operacin ptima. 26

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Anlisis de Sistemas de Computacin. Conceptos y Anlisis: Es un conjunto o disposicin de procedimientos o programas relacionados de manera que juntos forman una sola unidad. Un conjunto de hechos, principios y reglas clasificadas y dispuestas de manera ordenada mostrando un plan lgico en la unin de las partes. Un mtodo, plan o procedimiento de clasificacin para hacer algo. Tambin es un conjunto o arreglo de elementos para realizar un objetivo predefinido en el procesamiento de la Informacin. Esto se lleva a cabo teniendo en cuenta ciertos principios: Debe presentarse y entenderse el dominio de la informacin de un problema. Defina las funciones que debe realizar el Software. Represente el comportamiento del software a consecuencias de acontecimientos externos. Divida en forma jerrquica los modelos que representan la informacin, funciones y comportamiento. El proceso debe partir desde la informacin esencial hasta el detalle de la Implementacin. La funcin del Anlisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir este objetivo, un Sistema basado en computadoras hace uso de seis (6) elementos fundamentales: Software, que son Programas de computadora, con estructuras de datos y su documentacin que hacen efectiva la logstica metodologa o controles de requerimientos del Programa. Hardware, dispositivos electrnicos y electromecnicos, que proporcionan capacidad de clculos y funciones rpidas, exactas y efectivas (Computadoras, Censores, maquinarias, bombas, lectores, etc.), que proporcionan una funcin externa dentro de los Sistemas. Personal, son los operadores o usuarios directos de las herramientas del Sistema. Base de Datos, una gran coleccin de informaciones organizadas y enlazadas al Sistema a las que se accede por medio del Software. Documentacin, Manuales, formularios, y otra informacin descriptiva que detalla o da instrucciones sobre el empleo y operacin del Programa. Procedimientos, o pasos que definen el uso especifico de cada uno de los elementos o componentes del Sistema y las reglas de su manejo y mantenimiento. Un Anlisis de Sistema se lleva a cabo teniendo en cuenta los siguientes objetivos en mente: Identifique las necesidades del Cliente. Evale que conceptos tiene el cliente del sistema para establecer su viabilidad. Realice un Anlisis Tcnico y econmico. Asigne funciones al Hardware, Software, personal, base de datos, y otros elementos del Sistema. Establezca las restricciones de presupuestos y planificacin temporal. Cree una definicin del sistema que forme el fundamento de todo el trabajo de Ingeniera.

27

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Para lograr estos objetivos se requiere tener un gran conocimiento y dominio del Hardware y el Software, as como de la Ingeniera humana (Manejo y Administracin de personal), y administracin de base de datos. Objetivos del Anlisis. Identificacin de Necesidades. Es el primer paso del anlisis del sistema, en este proceso en Analista se rene con el cliente y/o usuario (un representante institucional, departamental o cliente particular), e identifican las metas globales, se analizan las perspectivas del cliente, sus necesidades y requerimientos, sobre la planificacin temporal y presupuestal, lneas de mercadeo y otros puntos que puedan ayudar a la identificacin y desarrollo del proyecto. Algunos autores suelen llamar a esta parte ¨ Anlisis de Requisitos y lo dividen en cinco partes: Reconocimiento del problema. Evaluacin y Sntesis. Modelado. Especificacin. Revisin Antes de su reunin con el analista, el cliente prepara un documento conceptual del proyecto, aunque es recomendable que este se elabore durante la comunicacin Cliente analista, ya que de hacerlo el cliente solo de todas maneras tendra que ser modificado, durante la identificacin de las necesidades. Estudio de Viabilidad. Muchas veces cuando se emprende el desarrollo de un proyecto de Sistemas los recursos y el tiempo no son realistas para su materializacin sin tener prdidas econmicas y frustracin profesional. La viabilidad y el anlisis de riesgos estn relacionados de muchas maneras, si el riesgo del proyecto es alto, la viabilidad de producir software de calidad se reduce, sin embargo se deben tomar en cuenta cuatro reas principales de inters: 1. Una evaluacin de los costos de desarrollo, comparados con los ingresos netos o beneficios obtenidos del producto o Sistema desarrollado. 2. Viabilidad econmica. Un estudio de funciones, rendimiento y restricciones que puedan afectar la realizacin de un sistema aceptable. 3. Viabilidad Tcnica. 4. Viabilidad Legal. Es determinar cualquier posibilidad de infraccin, violacin o responsabilidad legal en que se podra incurrir al desarrollar el Sistema. Alternativas. Una evaluacin de los enfoques alternativos del desarrollo del producto o Sistema. El estudio de la viabilidad puede documentarse como un informe aparte para la alta gerencia.

28

Ingeniera de software Anlisis Econmico y Tcnico.

Lic. Comp. Guillermo Mera Callejas

El anlisis econmico incluye lo que llamamos, el anlisis de costos beneficios, significa una valoracin de la inversin econmica comparado con los beneficios que se obtendrn en la comercializacin y utilidad del producto o sistema. Muchas veces en el desarrollo de Sistemas de Computacin estos son intangibles y resulta un poco dificultoso evaluarlo, esto varia de acuerdo a la caractersticas del Sistema. El anlisis de costos beneficios es una fase muy importante de ella depende la posibilidad de desarrollo del Proyecto. En el Anlisis Tcnico, el Analista evala los principios tcnicos del Sistema y al mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, caractersticas de mantenimiento y productividad. Los resultados obtenidos del anlisis tcnico son la base para determinar sobre si continuar o abandonar el proyecto, si hay riesgos de que no funcione, no tenga el rendimiento deseado, o si las piezas no encajan perfectamente unas con otras. Modelado de la arquitectura del Sistema. Cuando queremos dar a entender mejor lo que vamos a construir en el caso de edificios, Herramientas, Aviones, Maquinas, se crea un modelo idntico, pero en menor escala (mas pequeo). Sin embargo cuando aquello que construiremos es un Software, nuestro modelo debe tomar una forma diferente, deben representar todas las funciones y sub funciones de un Sistema. Los modelos se concentran en lo que debe hacer el sistema no en como lo hace, estos modelos pueden incluir notacin grfica, informacin y comportamiento del Sistema. Todos los Sistemas basados en computadoras pueden modelarse como transformacin de la informacin empleando una arquitectura del tipo entrada y salida. Especificaciones del Sistema. Es un Documento que sirve como fundamento para la Ingeniera Hardware, software, Base de datos, e ingeniera Humana. Describe la funcin y rendimiento de un Sistema basado en computadoras y las dificultades que estarn presente durante su desarrollo. Las Especificaciones de los requisitos del software se produce en la terminacin de la tarea del anlisis. En Conclusin un proyecto de desarrollo de un Sistema de Informacin comprende varios componentes o pasos llevados a cabo durante la etapa del anlisis, el cual ayuda a traducir las necesidades del cliente en un modelo de Sistema que utiliza uno mas de los componentes: Software, hardware, personas, base de datos, documentacin y procedimientos. 2.7 DISEO DE SISTEMAS DE COMPUTACIN Conceptos y principios: El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretacin y realizacin fsica. La etapa del Diseo del Sistema encierra cuatro etapas: 1. Trasforma el modelo de dominio de la informacin, creado durante el anlisis, en las estructuras de datos necesarios para implementar el Software. 29

Ingeniera de software 2. El diseo de los datos.

Lic. Comp. Guillermo Mera Callejas

Define la relacin entre cada uno de los elementos estructurales del programa. 3. El Diseo Arquitectnico. Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean. 4. El Diseo de la Interfaz. 5. El Diseo de procedimientos. Transforma elementos estructurales de la arquitectura del programa. 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 Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un conjunto de revisiones tcnicas: 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. Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y mantienen el Software. El Diseo debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementacin. Para evaluar la calidad de una presentacin del diseo, se deben establecer criterios tcnicos para un buen diseo como son: Un diseo debe presentar una organizacin jerrquica que haga un uso inteligente del control entre los componentes del software. El diseo debe ser modular, es decir, se debe hacer una particin lgica del Software en elementos que realicen funciones y subfunciones especificas. Un diseo debe contener abstracciones de datos y procedimientos. Debe producir mdulos que presenten caractersticas de funcionamiento independiente. Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre los mdulos y el entorno exterior. Debe producir un diseo usando un mtodo que pudiera repetirse segn la informacin obtenida durante el anlisis de requisitos de Software. Estos criterios no se consiguen por casualidad. El proceso de Diseo del Software exige buena calidad a travs de la aplicacin de principios fundamentales de Diseo, Metodologa sistemtica y una revisin exhaustiva. Cuando se va a disear un Sistema de Computadoras se debe tener presente que el proceso de un diseo incluye, concebir y planear algo en la mente, as como hacer un dibujo o modelo o croquis. Diseo de la Salida. En este caso salida se refiere a los resultados e informaciones generadas por el Sistema, Para la mayora de los usuarios la salida es la nica razn para el desarrollo de un Sistema y la base de evaluacin de su utilidad. Sin embargo cuando se realiza un sistema, como analistas deben realizar lo siguiente: 30

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Determine qu informacin presentar. Decidir si la informacin ser presentada en forma visual, verbal o impresora y seleccionar el medio de salida. Disponga la presentacin de la informacin en un formato aceptable. Decida cmo distribuir la salida entre los posibles destinatarios. Diseo de Archivos. Incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos histricos, o informacin de referencia. Entre las decisiones que se toman durante el diseo de archivos, se encuentran las siguientes: Los datos que deben incluirse en el formato de registros contenidos en el archivo. La longitud de cada registro, con base en las caractersticas de los datos que contenga. La secuencia a disposicin de los registros dentro del archivo (La estructura de almacenamiento que puede ser secuencial, indexada o relativa). No todos los sistemas requieren del diseo de todos los archivos, ya que la mayora de ellos pueden utilizar los del viejo Sistema y solo tenga que enlazarse el nuevo Sistema al Archivo maestro donde se encuentran los registros. Diseo de Interacciones con la Base de Datos. La mayora de los sistemas de informacin ya sean implantado en sistemas de cmputos grandes o pequeos, utilizan una base de datos que pueden abarcar varias aplicaciones, por esta razn estos sistemas utilizan u administrador de base de datos, en este caso el diseador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta en el sistema. Herramientas para el Diseo de Sistemas. Apoyan el proceso de formular las caractersticas que el sistema debe tener para satisfacer los requerimientos detectados durante las actividades del anlisis: Herramientas de especificacin. Apoyan el proceso de formular las caractersticas que debe tener una aplicacin, tales como entradas, Salidas, procesamiento y especificaciones de control. Muchas incluyen herramientas para crear especificaciones de datos. Herramientas para presentacin. Se utilizan para describir la posicin de datos, mensajes y encabezados sobre las pantallas de las terminales, reportes y otros medios de entrada y salida. Herramientas para el desarrollo de Sistemas. Estas herramientas nos ayudan como analistas a trasladar diseos en aplicaciones funcionales. Herramientas para Ingeniera de Software. Apoyan el Proceso de formular diseos de Software, incluyendo procedimientos y controles, as como la documentacin correspondiente. Generadores de cdigos. Producen el cdigo fuente y las aplicaciones a partir de especificaciones funcionales bien articuladas. Herramientas para pruebas.

31

Ingeniera de software

Lic. Comp. Guillermo Mera Callejas

Apoyan la fase de la evaluacin de un Sistema o de partes del mismo contra las especificaciones. Incluyen facilidades para examinar la correcta operacin del Sistema as como el grado de perfeccin alcanzado en comparacin con las expectativas. La revolucin del procesamiento de datos de manera computarizada, junto con las prcticas de Diseo sofisticadas estn cambiando de forma dramtica la manera en que se trasladan las especificaciones de Diseo d Sistemas de Informacin funcionales. En Conclusiones Generales. En una organizacin o Empresa, el anlisis y Diseo de Sistemas, es el proceso de estudiar su Situacin con la finalidad de observar cmo trabaja y decidir si es necesario realizar una mejora; el encargado de llevar a cabo estas tareas es el analista de sistemas. Antes de comenzar con el desarrollo de cualquier proyecto, se conduce un estudio de Sistemas para detectar todos los detalles de la situacin actual de la empresa. La informacin reunida con este estudio sirve como base para crear varias estrategias de Diseo. Los administradores deciden que estrategias seguir. Los Gerentes, empleados y otros usuarios finales que se familiarizan cada vez ms con el uso de computadoras estn teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son Sistemas que actan de manera recproca con su medio ambiente recibiendo entradas y produciendo salidas. Los Sistemas que pueden estar formados por otros Sistemas de denominan Sub-sistemas y funcionan para alcanzar los fines de su Implantacin

32