Análisis de Sistemas

Facultad de Ingeniera de Sistemas, Cmputo y Telecomunicaciones Sistema a Distancia

ANLISIS DE SISTEMAS

CSAR LUZA MONTERO

2010

Anlisis de Sistemas - Unidad I Csar Luza Montero

2 Sistema a Distancia

INTRODUCCIN Las organizaciones estn considerando el tema de los Sistemas de Informacin como factor clave para lograr competitividad. Se estn realizando grandes inversiones para su construccin e implantacin, de manera eficiente, efectiva y con niveles de calidad pertinentes.

Los sistemas de informacin, conjunto de componentes software, hardware, base de datos, procedimientos y personal, proveen la informacin, requerida por las organizaciones para apoyar las actividades de toma de decisin y controlar las operaciones del da a da. Esta informacin debe transmitirse a todos los niveles de la organizacin, de manera oportuna y confiable.

El proceso de construccin e implantacin de sistemas de informacin implica esfuerzo conjunto de desarrolladores y clientes-usuarios, quienes realizan una serie de actividades, agrupadas en fases, conocida como Proceso de desarrollo, conducente a obtener un sistema de calidad que satisfaga las necesidades de informacin de los clientes-usuarios.

En general, las primeras actividades del proceso de desarrollo estn relacionadas con el anlisis de sistemas y la especificacin de requerimientos del software. El propsito del anlisis de sistemas es definir el papel de cada componente del sistema de informacin y asignar al software el mbito que le corresponde desempear. Durante la actividad de especificacin de requerimientos del software, se detalla el mbito de funcionalidad del software, de tal manera que cubra la totalidad de necesidades de los usuarios.

La literatura especializada establece que el xito de un proyecto de desarrollo de sistemas depende, en gran medida, de realizar bien el anlisis de sistemas y especificacin de requerimientos del software; por lo que es de gran relevancia, para la formacin de profesionales del campo de desarrollo de Sistemas de Informacin, el dominio de mtodos, tcnicas y herramientas que permitan afrontar con xito estas actividades.

Precisamente, este libro tiene el propsito de promover y consolidar, en el estudiante, el uso de mtodos, tcnicas y herramientas para el anlisis de sistemas y especificacin de requerimientos de software. Se enfatiza en el componente software del sistema de informacin, se utiliza la notacin del lenguaje de modelado unificado (UML) y se sigue el proceso de desarrollo unificado (RUP). En otras palabras, para el anlisis de sistemas se desarrolla el flujo de modelado del negocio, y para la especificacin de requerimientos, se sigue el flujo de requerimientos que permitir capturar sistemticamente los requerimientos usando la tcnica de casos de uso del UML.

Los contenidos de este libro se han organizado en cinco unidades temticas. stas se desarrollan en lecciones que incluyen apartados, esquemas y figuras, segn cul sea la necesidad didctica. Cada unidad consta tambin de un conjunto de actividades y de evaluacin orientados a afianzar el aprendizaje del estudiante y a valorar sus logros.

La primera unidad tiene como propsito que el estudiante comprenda y explique la importancia de los sistemas de informacin en las organizaciones, definiendo con precisin los conceptos relacionados a la organizacin, proceso de negocio, datos, informacin, conocimiento y sistemas de informacin; valorando la importancia de estos conceptos en el contexto del anlisis de sistemas de informacin.



La segunda unidad comprende los temas relacionados con el proceso de desarrollo de sistemas de informacin, estableciendo sus fases y actividades genricas; muestra los diversos modelos de proceso de desarrollo y las metodologas ms conocidas, y brinda una introduccin al UML y al RUP.

La tercera unidad orienta, al estudiante, en el desarrollo de habilidades para la construccin de modelos de negocio; los artefactos que se elaboran sirven de base para la determinacin de requerimientos del sistema. Se utiliza notacin UML siguiendo las actividades proporcionadas por el RUP.

La cuarta unidad tiene por finalidad que el estudiante desarrolle habilidades para representar modelos de dominio, mediante la construccin de diagrama de clases de UML. De esta manera, complementa los artefactos del modelo de negocios con una representacin de los conceptos o entidades que se manejan en el contexto del negocio o dominio de la aplicacin que cubra las necesidades y requerimientos de los usuarios-clientes.

La quinta unidad permite que el estudiante consolide habilidades para la especificacin de requerimiento usando el modelo de casos de uso del UML. Se tratan, con precisin, los conceptos de requerimientos funcionales y no funcionales, y se elaboran, con claridad los artefactos del modelo de casos de uso: actores, casos de uso, descripcin de casos de uso y diagrama de casos de uso.

En todo el libro, las figuras o tablas que no consignan fuente, corresponden a elaboracin propia. Las figuras o tablas que no consignan nmero, representa continuacin del texto donde estn ubicados.

El autor.



ORIENTACIONES METODOLGICAS La asignatura de Anlisis de Sistemas es de formacin profesional especializada, de naturaleza terica-practica. Tiene como propsito que el estudiante maneje, adecuadamente, los mtodos, tcnicas y herramientas para el anlisis y especificacin de requerimientos de software como componente de un sistema de informacin.

Para este fin, se desarrollan las siguientes unidades temticas: Los Sistemas de Informacin en las Organizaciones, El Proceso de desarrollo con RUP y UML, El Modelado del Negocio, El Modelado de Dominio, y Requerimientos con casos de uso.

Al inicio de cada unidad temtica, el estudiante dispone de una serie de preguntas que permitir valorar sus logros. Al finalizar la unidad, se brinda un resumen del contenido temtico, una lectura seleccionada de un tema de inters relacionado con el contenido temtico de la unidad, una serie de actividades que el estudiante debe realizar, una autoevaluacin que mide el aprendizaje del estudiante, una serie de direcciones Internet para exploracin online.

Es fundamental, para el proceso de autoaprendizaje, que el estudiante planifique el tiempo y esfuerzo requerido por cada unidad. Asimismo, mediante Internet, debe trabajar de manera colaborativa, fomentando el trabajo en equipo y compartiendo informacin. El docente, dispondr de un horario que permita interactuar con los estudiantes para absolver consultas o dudas, a travs de Internet.

En lo que respecta a la evaluacin del aprendizaje, al final de cada unidad temtica se dispone de una serie de preguntas de autoevaluacin que permite al estudiante medir sus logros de aprendizaje conceptual. Adems, se presenta una serie de casos que el estudiante desarrollar y que permitir al docente medir los logros de aprendizaje procedimental.



PRIMERA UNIDAD

LOS SISTEMAS DE INFORMACIN EN LAS ORGANIZACIONES Qu es una organizacin, como se estructuran sus actividades, cules son sus niveles? Qu son los procesos de negocios, como se clasifican? Cul es la diferencia entre dato, informacin y conocimiento? Qu es un sistema de informacin, cules son sus componentes, como se clasifican?



Leccin 1

Organizacin y procesos de negocios Los profesionales responsables de automatizar las actividades de una organizacin deben comprender los procesos de negocio que sta realiza a fin de identificar aquellas actividades manuales que sern reemplazas por sistemas software.

En esta leccin se revisa aspectos bsicos de una organizacin y del enfoque basado en procesos de negocios en la estructura de sus actividades.

1.1 Organizacin

1.1.1 Qu es una organizacin? Segn el Diccionario de la Real Academia de la Lengua, una organizacin es una asociacin de personas reguladas por un conjunto de normas en funcin de determinados fines.

Se puede considerar que una organizacin es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma (generalmente en departamentos o funciones) con arreglo a ciertas reglas de divisin del trabajo y comunicacin que interactan para producir bienes o servicios (Figura 1.1).

Figura 1.1 Componentes de una organizacin

Fuente: Elaboracin propia1

Las personas representan el recurso ms importante de la organizacin, juegan distintos roles o responsabilidades cuando realizan las diversas actividades requeridas para cumplir los objetivos de la organizacin.

Las actividades o tareas son las acciones que en conjunto transforman las entradas en bienes o servicios, se distinguen actividades operativas (realizadas por los obreros o empleados) y actividades de toma de decisin (realizadas por los gerentes).

Los recursos pueden ser dinero, materiales, maquinaria, infraestructura, tecnologa que sirve de soporte para realizar las actividades.

1 Las figuras siguientes que no consignen fuente, son de elaboracin propia

ACTIVIDADES

Reglas

Personas/Recursos

Bienes/Servicios Entradas



Las reglas estn dadas por las polticas, normas y procedimientos que rigen el desarrollo de las actividades y uso de los recursos.

1.1.2 Estructura organizacional La estructura organizacional representa la forma en que las personas, actividades y recursos se organizan segn ciertas reglas. Se han establecido diversos modelos o enfoques para la estructura de una organizacin; sin embargo, para el propsito de este texto se pueden considerar dos enfoques: Estructura Funcional y Estructura por Procesos.

Estructura funcional

En la estructura con enfoque funcional las actividades se organizan verticalmente, en reas funcionales, de forma altamente jerrquica, con mbitos de control muy limitados y rgidos (figura 1.2).

Cada funcin busca optimizar sus propias tareas, inclusive a costa del rendimiento de global de la organizacin. Su foco de anlisis es la tarea o funcin, su objetivo es la optimizacin de las tareas, se orienta al interior de la organizacin, tiene una visin fragmentada.

Figura 1.2 Estructura funcional

Estructura por procesos

En la estructura con enfoque por procesos las actividades se organizan de manera horizontal, facilitando la reunificacin de actividades fragmentadas (figura 1.3).

Se percibe las actividades como procesos que rompen las barreras funcionales por medio de los cuales se producen los productos y servicios, notndose las relaciones con el cliente. Se busca satisfacer al cliente, considerando el producto y el flujo de trabajo. Su foco de anlisis es el proceso, su objetivo es la mejora de los procesos, se orienta esencialmente al cliente y tiene una visin global.

Gerencia General

Investigacin y

Desarrollo

Produccin Finanzas Ventas



Figura 1.3 Organizacin por procesos

1.1.3 Niveles Organizacionales Los roles que las personas desempean en la organizacin se pueden agrupar en diversos niveles organizacionales. Podemos considerar niveles relacionados con la toma de decisiones, que agrupa a los gerentes, y nivel de operaciones, agrupa a empleados, obreros, etc., que realizan actividades rutinarias, sin responsabilidad de toma de decisiones.

Se suele utilizar un modelo de pirmide organizacional para representar los niveles organizacionales relacionados con la toma de decisiones. En la figura 1.4 se visualiza cuatro niveles: Estratgico, Administrativo, de Conocimiento y Operativo (Laudon, 2004).

Figura 1.4 Pirmide organizacional

Fuente: (Adaptado de Laudon, 2004)

Gerentes Operativos

Trabajadores del Conocimiento

Nivel Operativo

Nivel Administrativo

Nivel de Conocimiento

Directores

Gerentes de Nivel Medio

Nivel Estratgico

Gerencia General

Proceso de negocio (Flujo de actividades)





En esta pirmide podramos agregar, debajo de su base, un bloque grande para representar las actividades operacionales o rutinarias que tienen poca tarea de toma de decisiones.

Nivel estratgico

En el nivel estratgico, se realizan actividades relacionadas con toma de decisiones de asuntos estratgicos y tendencias a largo plazo, tanto en la empresa como el entorno externo; por ejemplo, se tratan asuntos como determinar los productos a elaborar dentro de cinco aos o determinar los niveles de empleo dentro de cinco aos. Se puede incluir a Directores, Gerente General, Gerentes de Divisin.

Nivel administrativo

En el nivel administrativo, se realizan actividades de supervisin, control y toma de decisiones de aspectos tcticos en el mediano plazo; por ejemplo, se tratan asuntos de exceso de presupuestos en un periodo o control del rendimiento. Se incluye a los gerentes de nivel medio, como gerente de reas: Gerente de Ventas, Gerente de Recursos Humanos, Gerente de una Agencia o Sucursal.

Nivel de conocimiento

En el nivel de conocimiento, se realizan actividades relacionadas con la investigacin y desarrollo para generar nuevas oportunidades de negocio o controlar el flujo de trabajo de oficina. Las personas que realizan este tipo de actividades son los trabajadores de conocimientos. Se incluye a Analistas de Financieros, Expertos en Marketing, Investigadores.

Nivel operativo

En el nivel operativo, se realizan actividades de seguimiento y control de las tareas realizadas por el personal operacional, empleados, obreros, quienes realizan transacciones elementales de la organizacin como ventas, depsitos en efectivo, nminas. Se toman decisiones de corto plazo, por ejemplo, reabastecimiento de stock de inventarios, otorgar prstamos bancarios, entre otros. Se incluye a los gerentes operativos: Jefe de Seccin de fabricacin, Jefe de Cajeros.

Este modelo de pirmide permite, a quienes desarrollan sistemas de informacin, visualizar el alcance de informacin requerido por cada nivel; as, en el nivel de gestin operativo, la informacin detallada es necesaria; mientras que, en el nivel estratgico, conviene proporcionar resmenes.



1.2 Procesos de negocio

1.2.1 Qu es un proceso de negocio? Un proceso de negocio es un orden especifico de actividades a travs del tiempo y lugar, con un comienzo y un fin, inputs y outputs: una estructura para la accin (Davenport, 1996).

Un proceso de negocio es un conjunto de actividades que toman uno o ms tipos de inputs y crean un output que es de valor para un cliente (Hammer, 1993).

Mediante los procesos de negocio se organizan y coordinan las actividades en funcin al cliente elaborando productos y servicios de valor.

Muchos procesos de negocios trascienden las reas funcionales tradicionales; por ejemplo, en muchas compaas el proceso de ejecucin de un pedido requiere la cooperacin entre la funcin de ventas, contabilidad y manufactura. En ventas se recibe el pedido y se inicia su trmite; en contabilidad se verifica el crdito y se factura el pedido) y en manufactura se produce y enva el pedido (figura 1.5).

Figura 1.5 Proceso de ejecucin de un pedido

.

Algunos ejemplos de proceso de negocios son: Proceso de Admisin, Proceso de Matrcula, Proceso de Contratacin de Personal, Proceso de Formulacin del Plan Anual de Desarrollo.

1.2.2 Clases de procesos de negocio Los procesos de negocios se pueden clasificar en: Principales, de Soporte y de Gestin.

Los Procesos Principales o Sustantivos son aquellos que estn ligados directamente con la realizacin del producto y la prestacin del servicio para el Cliente. Son los procesos de lnea, hacen realidad la misin de la organizacin.

Ejemplos:

Mediantes estos dos procesos el cliente interacta con la organizacin. El proceso Vender Producto permite al cliente recibir de la organizacin el producto requerido. El proceso Gestionar Pedido permite al cliente solicitar el pedido de bienes /servicios requerido.

VENDER PRODUCTO GESTIONAR PEDIDO

VENTAS CONTABILIDAD MANUFACTURA

Recibir pedido

Verificar Crdito

Producir pedido

Iniciar tramite

Facturar pedido

Enviar pedido



Los Procesos de Soporte son aquellos que proporcionan apoyo a los procesos principales o sustantivos. Usualmente estn relacionados con la gestin de recursos.

Ejemplos:

En estos dos procesos no hay agente externo, cliente, proveedor, etc., que interacte con la organizacin. Son procesos que apoyan a los procesos principales.

Los Procesos de Gestin son aquellos que estn vinculados al mbito de las responsabilidades de la direccin. Se relacionan con actividades de planificacin y control.

Ejemplos:

Estos dos procesos son realizados por los niveles gerenciales, no hay interaccin entre algn agente externo con la organizacin. Son proceso que refleja tareas gerenciales..

1.2.3 Cmo se describe un proceso de negocio? Un proceso de negocio se puede describir de manera textual o grfica. Se han propuestos diversos formatos para describir un proceso, pero los tems bsicos incluyen: la entrada, las actividades, quin o quines realizan las actividades, los recursos que se utilizan, las reglas que rigen el flujo de actividades y la salida.

A continuacin se muestra un ejemplo textual de descripcin de un proceso de Registro de Pedido para una empresa de fabricacin:

PLANIFICACIN

INVESTIGACIN DE MERCADO

DESARRROLLO DE PERSONAL

REVISIN

1. El cliente enva una orden de pedido, por telfono, por fax o por correo, al Dpto. Comercial. El pedido debe incluir la fecha de solicitud, datos del cliente y productos solicitados.

2. Un empleado del departamento comercial revisa el pedido (completndolo, si es necesario), y comienza su procesamiento envindolo al jefe tcnico, que est encargado de su anlisis.

3. El jefe tcnico analiza la viabilidad de cada producto del pedido por separado. Si el producto pedido est en el catlogo, su fabricacin es aceptada. En caso contrario, es considerado un producto especial, y el jefe tcnico estudia su produccin: Si es viable, la fabricacin del producto especial es aceptada; Si no es viable, el producto especial no ser fabricado.

4. Una vez estudiado el pedido completo, el jefe tcnico informa al departamento comercial de la aceptacin o rechazo de cada producto pedido; Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo para cada producto, a partir de una plantilla de fabricacin (la estndar si el producto estaba catalogado, o una nueva, especficamente diseada para el producto, si ste no estaba en el catlogo). Cada orden de trabajo es enviada al jefe de produccin, y queda pendiente de su lanzamiento.

5. El comercial comunica al cliente el resultado final del anlisis de su pedido.



En la figura 1.6, se describe el proceso de Registrar Pedido de manera grafica, usando la tcnica de Diagrama de Actividades de UML y modelado con la herramienta Rational Rose de IBM.

Figura 1.6 Descripcin Grafica del Proceso Registro de Pedido

Existen diversas tcnicas y herramientas para describir, de manera grfica, un proceso de negocio. Depender del profesional responsable, elegir aquella que se adapte mejor a las necesidades de la organizacin a la que brinda sus servicios.



Leccin 2

Introduccin a los Sistemas de informacin Las organizaciones requieren de informacin para apoyar las actividades de toma de decisin y controlar las operaciones del da a da. La informacin se transmite en todos los niveles de la organizacin a travs de los sistemas de informacin.

En esta leccin se brinda, a modo introductorio, los conceptos relacionados a los sistemas de informacin, los componentes y tipos de sistemas de informacin.

2.1 Concepto de Dato, Informacin y Conocimiento Desde aos atrs se reconoce que la informacin es un recurso valioso en las organizaciones. Los gerentes, empleados y todos aquellos que integran una organizacin la utilizan. Con frecuencia los empleados usan datos detallados para sus actividades de tipo operacional, los gerentes manejan informacin sumaria para tomar decisiones.

En muchas ocasiones se utilizan los trminos datos e informacin como sinnimos, pero son trminos que tiene distinto significado.

Datos

Los datos son registros de hechos observables no procesados que no tienen significado. En la figura 2.1 se aprecia algunos ejemplos de datos.

Figura 2.1 Datos

Informacin

La informacin es un conjunto de hechos agrupados para algn propsito en particular. Son datos procesados que tienen significado.

Por ejemplo, agrupando y organizando los datos mostrados en la figura 2.1:Zapato, Jos Quispe, 456789, 1200 y S/100, tenemos que se refieren a una factura (figura 2.2).

Figura 2.2 Informacin

Comercial Vende Barato S.A

Factura Nro 456789

Cliente: Jos Quispe

Detalle

Nro. Producto Cantidad Precio

01 Zapatos 1200 S/100

1200

S/100

Zapatos Jos Quispe

456789



Se puede afirmar que los datos son la materia prima para producir informacin. Entonces, en las organizaciones se procesan datos para obtener informacin.

En base a la informacin se adquiere conocimiento. Actualmente, se considera al conocimiento como el recurso ms preciado, por ello se habla de gestin del conocimiento en las organizaciones.

Conocimiento

El conocimiento es la informacin conectada a decisiones, procesos y acciones capaces de aplicar esa informacin.

Para explicar la diferencia entre informacin y conocimiento, considere una receta de preparacin de una torta. Las instrucciones e ingredientes indicados en la receta vendran a ser informacin, al igual que el libro de receta es informacin. Esta informacin se convierte en conocimiento cuando, una persona elabora una torta siguiendo las instrucciones y utilizando los ingredientes indicados en la receta. En otras palabras, cuando la informacin se lleva a la accin se convierte en conocimiento.

Desde una perspectiva de niveles se puede considerar que "El nivel ms bajo de los hechos conocidos son los datos. Los datos no tienen un significado intrnseco. Deben ser ordenados, agrupados, analizados e interpretados. Cuando los datos son procesados de esta manera, se convierten en informacin. La informacin tiene una esencia y un propsito. Cuando la informacin es utilizada y puesta en el contexto o marco de referencia de una persona, se transforma en conocimiento. El conocimiento es la combinacin de informacin, contexto y experiencia. (Harris, 1996).

La figura 2.3 trata de explicar las diferencias entre datos, informacin y conocimiento desde una perspectiva de niveles.

Figura 2.3 Dato, Informacin Y conocimiento

Fuente: (Adaptado de Harris, 1996)

2.2 Qu es Sistema de informacin? Un sistema de informacin es un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la informacin para apoyar la toma de decisiones y el control en una institucin. Los sistemas de informacin pueden contener datos acerca de personas, lugares y cosas importantes dentro de la institucin y el entorno que la rodea (Laudon, 2004).

Hechos agrupados para un propsito

Coleccin de hechos

CONOCIMIENTO

INFORMACIN

DATO

Informacin conectada a decisiones, procesos y acciones capacea de aplicar esa informacin



Un sistema de informacin recibe y procesa los datos de manera eficaz, sin errores, evala la calidad de los datos de entrada, almacena los datos de modo que estn disponibles cuando el usuario lo crea conveniente, elimina la informacin poco til evitando redundancias, brinda seguridad evitando la perdida de informacin o la intrusin de personal no autorizado o agentes externo a la compaa y genera informacin de salida, en el momento oportuno, y til para los usuarios, ayudando en el proceso de toma de decisiones.

Se suele confundir el concepto de sistemas de informacin con la computadora y los programas informticos. Una organizacin puede adquirir nuevas computadoras, instalar redes, desarrollar pginas Web, etc., pero ello no significa que se implemente sistema de informacin. El significado del trmino sistema de informacin abarca ms que los elementos computacionales, incluye, tambin, el modo de organizar dichos elementos, la forma de usarlos y los roles que desempean las personas en su explotacin para obtener la informacin que apoye las actividades de la empresa.

2.3 Componentes de un Sistema de informacin Se puede considerar que los componentes de un sistema de informacin son: el hardware, el software, la base de datos, los procedimientos y el personal. Estos elementos interactan entre s para lograr el objetivo del: proveer informacin para apoyar a la empresa (figura 2.4).

Figura 2.4 Componentes de un Sistema de Informacin

El hardware corresponde al elemento fsico del sistema de informacin incluye las redes computacionales y de telecomunicaciones. El software corresponde a los programas de aplicacin. La base de datos representa el almacn de los datos e informacin requerida por la empresa, las personas puede ser los usuarios finales y el personal de tecnologa de informacin. Los procedimientos establecen las reglas y normas del uso del sistema de informacin

Personas

Hardware

Software

Dato/informacin

Procedimiento

Sistema de Informacin



2.4 Tipos de sistemas de informacin De acuerdo con los intereses, especialidades y niveles en una organizacin, se pueden identificar los siguientes tipos de sistemas de informacin (Laudon, 2006): de nivel operativo, de nivel del conocimiento, de nivel administrativo y de nivel estratgico.

Los sistemas de informacin de nivel operativo apoyan a los gerentes operativos en el control de actividades y transacciones elementales de la organizacin, por ejemplo: ventas, ingresos, depsitos en efectivo, nomina, decisiones de crdito y flujo de materiales en una fbrica. Responden a preguntas de rutina y siguen el flujo de transacciones a travs de la organizacin. Por ejemplo, Cuntas partes hay en inventario? Qu pas con el pago del seor Gutirrez?

Los sistemas de informacin de nivel del conocimiento apoyan a los trabajadores del conocimiento de datos de una organizacin. Su objetivo es ayudar a las empresas comerciales a integrar el nuevo conocimiento en los negocios y ayudar a la organizacin a controlar el flujo del trabajo de oficina. Estos tipos de sistemas estn entre las aplicaciones de crecimiento ms rpidas en los negocios actuales.

Los sistemas de informacin de nivel administrativo apoyan a las actividades de supervisin, control, toma de decisiones, y administrativas de los gerentes de nivel medio. La pregunta principal que plantean estos sistemas es: Van bien las cosas? Por lo general, este tipo de sistemas proporcionan informes peridicos ms que informacin instantnea de operaciones. Apoyan a las decisiones no rutinarias y tienden a enfocarse en decisiones menos estructuradas para las cuales los requisitos de informacin no siempre son claros.

Los sistemas de informacin de nivel estratgico apoyan a los directores a enfrentar y resolver aspectos estratgicos y tendencias a largo plazo, tanto en la empresa como en el entorno externo. Su funcin principal es compaginar los cambios del entorno externo con la capacidad organizacional existente.

Segn la funcin que desempean o el tipo de usuario final del mismo, se pueden clasificar en (Laudon, 2006): Sistema de procesamiento de transacciones, Sistemas de informacin gerencia, Sistema de soporte a la toma de decisiones, Sistemas de informacin ejecutiva, Sistemas de automatizacin de oficinas, Sistemas expertos y Sistemas de Planificacin de Recursos Empresariales.

Sistema de procesamiento de transacciones (Transaction Process System- TPS) son aquellos que permiten gestionar la informacin referente a las transacciones producidas en una empresa u organizacin.

Sistema de informacin gerencial (Management Information System - MIS) son aquellos orientados a solucionar problemas empresariales en general.

Sistema de soporte a decisiones (Decision Suport System - DSS) son aquellas que sirve de herramienta para realizar el anlisis de las diferentes variables de negocio con la finalidad de apoyar el proceso de toma de decisiones.

Sistema de informacin ejecutiva (Executive Information System - EIS) son aquellas herramientas orientadas a usuarios de nivel gerencial, que permite monitorizar el estado de las variables de un rea o unidad de la empresa a partir de informacin interna y externa a la misma.



Sistema de automatizacin de oficinas (Office Automation System - OAS) son aplicaciones destinadas a ayudar al trabajo diario del administrativo de una empresa u organizacin.

Sistemas expertos (Expert System - SE) emulan el comportamiento de un experto en un dominio concreto.

Los Sistemas de Planificacin de Recursos Empresariales (Enterprise Resource Planning - ERP) integran la informacin y los procesos de una organizacin en un solo sistema.

Todos estos sistemas de informacin a su vez podran analizarse segn las diferentes reas de la empresa: ventas y mercadotecnia, manufactura y produccin, finanzas, contabilidad y recursos humanos. Para cada una de estas reas existe un conjunto especifico de aplicaciones informticas y equipos, los cuales han de estar coordinados entre si. Si ello no se realizara, una empresa tendr problemas de intercambio de datos entre las diferentes reas, aparecer la existencia de redundancia de datos y la existencia de ineficiencias e incrementos de costes de comunicacin.



Resumen

Organizacin y Procesos de Negocio

Una organizacin es un sistema compuesto por un conjunto de personas, actividades y recursos, distribuidas de alguna forma con arreglo a ciertas reglas de divisin del trabajo y comunicacin que interactan para producir bienes o servicios.

La estructura organizacional representa la forma en que las personas, actividades y recursos se organizan. Puede ser de dos tipos; funcional o de procesos.

Funcional: las actividades se organizan verticalmente, en reas funcionales, de forma altamente jerrquica, con mbitos de controles muy limitados y rgidos.

Por procesos: las actividades se organizan de manera horizontal, facilitando la reunificacin de actividades fragmentadas.

Los roles que las personas desempean en la organizacin se pueden agrupar en niveles organizacionales: Operacionales y Gerenciales. Los Gerenciales pueden ser: estratgico, administrativo, de conocimiento y de control operativo.

Nivel Operacional: Actividades rutinarias. No hay toma de decisin. Empleados, obreros.

Niveles Gerenciales: Actividades caracterizadas por toma de decisiones. o Nivel estratgico, asuntos estratgicos y tendencias a largo plazo. o Nivel administrativo, aspectos tcticos en el mediano plazo. o Nivel de conocimiento, investigacin y desarrollo o Nivel operativo, control de tareas del personal operacional. Decisiones de corto plazo.

Un proceso de negocio es un conjunto de actividades que toman uno o ms tipos de inputs y crean un output que es de valor para un cliente.

Clases de Procesos de Negocios

Principales: ligados con realizacin del producto / lprestacin del servicio para el Cliente.

De Soporte: apoyan los procesos principales. Relacionados con la gestin de recursos.

De Gestin: vinculados a la direccin. Se relacionan con actividades de planificacin y control.

Un proceso de negocio se puede describir en forma grafica o textual.

Introduccin a los sistemas de informacin

Los datos son registros de hechos observables no procesados que no tienen significado.

La informacin es un conjunto de hechos agrupados para algn propsito en particular. Son datos procesados que tienen significado.

El conocimiento es la informacin conectada a decisiones, procesos y acciones capaces de aplicar esa informacin.

Un sistema de informacin es un conjunto de componentes interrelacionados que permiten capturar, procesar, almacenar y distribuir la informacin para apoyar la toma de decisiones y el control en una institucin.

Los Componentes de un sistema de informacin son: Hardware, Software, Base de datos, Personas (usuarios finales y personal de T.I.) y Procedimientos.

Tipos de sistema de informacin

De acuerdo a intereses: Sistemas de informacin de nivel operativo, Sistema de informacin de nivel de conocimientos, Sistema de informacin de nivel administrativo y Sistema de informacin de nivel estratgico

Segn funcin que desempea: Sistema de procesamiento de transacciones (TPS), Sistema de informacin Gerencial (MIS), Sistema de soporte a las decisiones (DSS), Sistema de informacin ejecutiva (EIS), Sistema de automatizacin de oficinas (OAS), Sistema Experto (SE), Sistema de planificacin de recursos empresariales (ERP).

.



Lectura BACKUS: INTEGRANDO PROVEEDORES A LA CADENA DE SUMINISTROS (*)

La necesidad de automatizar procesos y generar valor en las actividades de las diferentes reas de una organizacin se ha convertido en una tendencia cada vez ms frecuente en las empresas, ello gracias a los beneficios que ofrece el e-business.

Es as, que Unin de Cerveceras Peruanas Backus y Johnston dando un paso adelante con la tecnologa, viene implementando mejoras en todos sus procesos para operar con estndares de clase mundial que tiendan a la satisfaccin de sus clientes y la integracin de sus proveedores como socios de negocios.

Rafael Trucos, Gerente de Planning y Marketing de ebiz Latin America, empresa especialista en soluciones e-business y operador tecnolgico de Backus, convers con Csar Campodnico, Gerente de Desarrollo de Proveedores con la finalidad de dar a conocer la forma de trabajo con proveedores y los beneficios obtenidos al implementar ebiz en Backus.

Desde que empezamos el proyecto e-commerce de ebiz en el ao 2004, hemos implementado nuevas soluciones integradas a nuestro sistema transaccional con la finalidad de agilizar nuestro proceso de abastecimiento y dar un mejor servicio a nuestros clientes internos, automatizando no solo nuestros procesos Logsticos, sino tambin Contables, coment Csar Campodnico.

En la actualidad, Backus ha implementado el mdulo de Peticiones de Oferta, Envo de cotizaciones, Envo de rdenes de compra, Visualizacin de estado de comprobantes de pago, Impresin de comprobantes de retencin y prximamente el mdulo de Registro de facturas para proveedores, agreg.

Por otro lado, Campodnico coment cuales fueron las caractersticas principales del servicio ofrecido por ebiz que permiti tomar una decisin al momento de hacer la integracin en SAP:

Customizacin a las exigencias segn modelo de negocio de Backus. Flexibilidad en la adecuacin de las necesidades de Backus. Tiempos de implementacin adecuados. Servicio al cliente BACKUS y sus proveedores. Consultas y Soporte a travs de Help Desk.

Apoyo al seguimiento en Call Center. Costo vs Beneficio (Inversin vs Ahorro) Sinergias del mercado Comunidad Empresarial electrnica Confiabilidad, Confidencialidad y Seguridad (Hosting operaciones en IBM)

As mismo, dentro de los beneficios obtenidos por la relacin Proveedor / Cliente se coment la reduccin de costos por negociacin consolidada, la funcionalidad personalizada a las prcticas del negocio, el mejor control de la operacin logstica y el incremento de nivel de servicio al cliente interno, todo ello orientado a cumplir los objetivos que persigue el modelo de gestin de cadena de suministro.

Finalmente, resalt que el uso de herramientas b2b forma parte de los Lineamientos bsicos para proveedores dando a conocer el compromiso de Backus en el establecimiento de una relacin fuerte, perdurable y de lealtad con sus proveedores.

(*) Fuente: ebiz News

Fecha de `publicacion: 7/6/2009 11:00:00

Link: http://www.generaccion.com/noticias/online/detalle.php?id=24447



Actividades 1 Identifique una organizacin, de cualquier tipo o tamao, y realice la descripcin de uno de

sus procesos de negocio de tipo principal. 2 Busque y explique algunas tcnicas de modelado de procesos de negocio y elabore un

ejemplo de cada una.

Autoevaluacin Contestar las siguientes preguntas: 1 Una organizacin es un sistema compuesto por 2 La estructura con enfoque de proceso se caracteriza por: 3 Los niveles de gestin de una organizacin son: 4 Un proceso de negocio es: 5 Los tipos de procesos de negocios son: 6 La diferencia entre dato e informacin es 7 La diferencia entre informacin y conocimiento es 8 Un sistema de informacin es: 9 Los componentes de un sistema de informacin son: 10 Los tipos de sistemas de informacin son:

Exploracin on-line Portal del CIO,

Portal de la Compaa IBM sobre transformacin de procesos de negocio para incrementar la flexibilidad empresarial a travs de SOA; contiene documentos, videos y casos de estudio. https://www-935.ibm.com/services/es/cio/flexible/

OMG, Object Management Group / Business Process Management Initiative Pagina de la Organizacin Internacional OMG (Object Management Group) que contiene informacin de estndares de modelado de procesos de negocios. http://www.bpmn.org/

Referencias bibliogrficas 1 Davenport, Thomas (1996). Innovacin de Procesos: Reingeniera del trabajo a travs de la

tecnologa de la informacin. Espaa. Daz Santos.

2 Hammer, Michel y James Champy (1993), Reengineering the Corporation: A Manifesto for Business Revolution. USA. Collins Business Essentials.

3 Harris, David (1996). Creating a Knowledge Centric Information Technology Environment. USA. Editorial Harris Training & Consulting Services Inc.

4 Laudon, Jane y Kenneth P. Laudon, J. (2004) Sistemas de Informacin Gerencial. 8 Ed. Mxico D.F. Pearson Educacin.

5 Laudon, Jane y Kenneth (2006). Sistemas de informacin gerencial, Administracin de la empresa digital. Mxico D.F. Pearson Educacin- Prentice Hall.

Anlisis de Sistemas - Unidad II Csar Luza Montero


SEGUNDA UNIDAD

EL PROCESO DE DESARROLLO, RUP Y UML Qu es un proceso de desarrollo, cuales son sus fases y actividades genricas? Cules son los modelos de proceso de desarrollo? Qu es metodologa, tcnica y herramienta de desarrollo? Qu es el UML y cuales son sus elementos, relaciones y diagramas? Qu es el RUP y cuales sus fases y flujos, artefactos, trabajadores, actividades?



Leccin 3

Proceso de desarrollo de sistemas de informacin La construccin de un sistema de informacin implica un esfuerzo conjunto de profesionales de tecnologa de informacin y lderes de la organizacin. Este esfuerzo implica realizar una serie de actividades conducentes a obtener un sistema de calidad. Esta serie de actividades se conoce como proceso de desarrollo que deviene en metodologas de desarrollo.

Esta leccin ayuda comprender las caractersticas de un proceso de desarrollo, los modelos que existen y los conceptos relacionados a las metodologas de desarrollo.

3.1 Proceso de desarrollo, una visin genrica

3.1.1 Qu es un proceso de desarrollo? El proceso de desarrollo es una gua acerca de las actividades y tareas necesarias para construir un sistema de informacin. En el contexto de software, programas de aplicacin o aplicaciones informticas, Pressman (2002) considera al Proceso como un marco de trabajo que define las tareas a realizar para desarrollar software de alta calidad.

Se han establecido diversos modelos de proceso de desarrollo de sistemas de informacin, con actividades y tareas especficas; pero se puede establecer una serie de actividades comunes que llamaremos visin genrica con las siguientes fases (Pressman, 2002): Definicin, Desarrollo y Evolucin.

Figura 3.1 Fases del proceso de desarrollo: Visin genrica

Fuente: (Pressman, 2002)

3.1.2 Fase de Definicin El propsito de la fase de Definicin es identificar las necesidades o requerimientos del cliente/usuario, tales como: la informacin que debe ser proporcionada, la funcionalidad y rendimiento que se desea, las interfaces que deben establecerse, las restricciones de diseo que existen y los criterios de validacin que se necesitan para definir un sistema correcto.

En esta fase, se realizan las siguientes actividades: Anlisis del Sistema, Requerimientos del Software y Planificacin del Proyecto.

Desarrollo

Evolucin

Definicin

Anlisis del Sistema

Requerimientos Planificacin

Diseo Codificacin Prueba

Correccin Adaptacin Mejora



Anlisis del sistema. Define el papel de cada elemento del sistema de informacin, asignando finalmente al software el papel que va a desempear.

Requerimientos del software. El mbito establecido para el software proporciona la direccin a seguir, pero antes de comenzar a trabajar es necesario disponer de una informacin mas detallada del mbito de la funcionalidad del software.

Planificacin del proyecto de software. Una vez establecido el mbito del software, se analizan los riesgos, se asignan los recursos, se estiman los costes, se definen las tareas y se planifica el trabajo.

3.1.3 Fase de Desarrollo El propsito de la fase de Desarrollo es determinar cmo han de disearse las estructuras de datos y la arquitectura del software, cmo han de implementarse los detalles procedimentales, cmo ha de traducirse el diseo a un lenguaje de programacin y cmo ha de realizarse la prueba.

En general se aplicarn tres pasos concretos: Diseo del Software, Codificacin y Pruebas del software.

Diseo de software. El diseo traduce los requisitos de software a un conjunto de representaciones (algunas grficas y otras tabulares o basadas en lenguajes) que describen las estructuras de bases de datos, la arquitectura, el procedimiento algortmico y las caractersticas de la interfaz.

Codificacin. Las representaciones del diseo debern ser traducidas a un lenguaje artificial (un lenguaje de programacin convencional o un lenguaje no procedimental T4G), dando como resultado unas instrucciones ejecutables en la computadora.

Prueba del software. Una vez que el software ha sido implementado en una forma ejecutable por la maquina, debe ser probado para descubrir los defectos que puedan existir, en la funcin, en la lgica y en la implementacin.

3.1.4 Fase de Evolucin La fase de Evolucin, tambin llamada fase de mantenimiento, se centra en los cambios que van asociados a la correccin de errores, a las adaptaciones requeridas por la evolucin del entorno del software y a las modificaciones debidas a los cambios de requisitos del usuario dirigidos a reforzar o ampliar el sistema.

La fase de mantenimiento vuelve a aplicar las fases de definicin y de desarrollo, pero en el contexto del software ya existente.

Se encuentran tres tipos de cambio: Correccin, Adaptacin y Mejora.

Correccin. Incluso llevando a cabo las mejores actividades de garanta de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los defectos.

Adaptacin. Con el paso del tiempo es probable que cambie el entorno original (sistemas operativos, equipos perifricos, etc.) para los que se desarrollo el software. El mantenimiento adaptativo consiste en modificar el software para acomodarlo a los cambios de su entorno externo.



Mejora. Conforme utilice el software, el usuario puede descubrir funciones adicionales que podran interesar que estuvieran incorporadas en el software. El mantenimiento perfectivo amplia el software ms all de sus requisitos funcionales originales.

3.2 Modelos de Proceso de desarrollo de software La implementacin de un proceso de software puede variar de acuerdo a la naturaleza: del proyecto, de la aplicacin de los mtodos a seguir y de las herramientas a utilizar. Se han establecido diversos modelos, conocidos como ciclo de vida del software.

En esencia, los modelos de ciclo de vida del software permiten determinar las fases productivas de un proyecto, los objetivos de cada fase productiva, los productos obtenidos en cada una de estas fases, as como sus caractersticas y los roles que se desempean en cada fase.

Los modelos de proceso de software se puede clasificar en: Secuencial, Iterativos y Evolutivos.

El modelo secuencial se caracteriza porque las actividades del desarrollo progresan de manera secuencial. Una actividad no puede iniciar si no ha terminado la anterior.

Los modelos iterativos se caracterizan porque las actividades se repiten de manera cclica. Entre los modelos iterativos podemos mencionar: Construccin de prototipos y Desarrollo Rpido de Aplicaciones.

Los modelos evolutivos se caracterizan porque son iterativos y en cada iteracin se agrega nueva funcionalidad (versiones) al sistema. Se ha dado gran impulso a estos modelos pues la realidad demuestra que los requisitos suelen cambiar a medida que el desarrollo avanza, haciendo que no se puedan cumplir con las metas fijadas inicialmente respecto de un producto final completo; otras veces, si bien se han captado claramente los requisitos centrales todava falta definir los detalles. Entre los modelos evolutivos podemos mencionar el modelo incremental y el modelo espiral.

3.2.1 Modelo Lineal Secuencial Este modelo, tambin conocido como Modelo de Ciclo de Vida Clsico o Modelo en Cascada, es el ms antiguo y ha sido el ms usado. Tal como su nombre lo indica, progresa en forma secuencial desde una primera fase de Anlisis de Sistemas, avanzando a travs de Requerimientos, el Diseo, la Codificacin, la Prueba y el Mantenimiento (figura 3.2) .

Figura 3.2 Modelo lineal secuencial

En este modelo, los requerimientos deben estar claramente identificados desde el inicio. Sin embargo, la realidad seala que raramente el cliente expone todos los requerimientos desde el inicio. En consecuencia, pueden surgir cambios durante el desarrollo lo que afectar la planificacin establecida.

Cuando se trata de proyectos grandes, el cliente debe tener paciencia porque no ver una versin operativa del sistema sino hasta que el proyecto est muy avanzado. Adems,

Anlisis de Sistemas

Requerimientos de software

Diseo Codificacin Prueba Mantenimiento



esto hace que no exista una validacin por parte del cliente hasta muy tarde. Si en estas etapas finales se detectase un error grave las consecuencias son desastrosas.

Aunque este modelo puede tener sus debilidades, siempre es mejor que un enfoque hecho al azar y puede resultar bueno cuando se trate de un proyecto donde todos los requerimientos estn claramente definidos desde el comienzo.

3.2.2 Modelo Construccin de Prototipos Muchas veces, en los proyectos de desarrollo, no todos los requisitos estn claros desde el inicio; en esta situacin puede resultar conveniente aplicar el Modelo de Construccin de Prototipos.

En este modelo el ciclo comienza con la captura de requerimientos del cliente por parte del desarrollador. Luego, el desarrollador construye un prototipo de diseo rpido concentrado en las interfaces de entrada y salida; que se constituye en la primera versin. Este prototipo es evaluado por el cliente y sirve para refinar los requerimientos. Se inicia nuevamente el ciclo, conocido como iteracin (figura 3.3).

Lo ideal es que este prototipo sirva slo para identificar los requisitos y una vez que esto se logr se lo deseche; generalmente, estos prototipos, si son operativos (working prototype) suelen ser muy lentos o muy grandes o torpes o las tres cosas a la vez. Lo ideal es, ahora, construir una versin rediseada en la que estos problemas no estn presentes.

Figura 3.3 Modelo Construccin de prototipos

Fuente: (Adaptado de Pressman, 2002)

En este modelo, cuando el cliente observa el prototipo operativo, cree que es la versin final del sistema, sin entender que se trata de solo un prototipo y que el producto no est terminado.

Por la presin de hacer que el prototipo funcione rpidamente, el desarrollador puede elegir, inadecuadamente, el sistema operativo o el lenguaje de programacin; incluso, puede usar un algoritmo incorrecto. Despus de algn tiempo, puede familiarizarse con estas elecciones y olvidarse las razones por las cuales son inadecuadas, dejndolas luego como una parte integral del sistema.

Aunque pueden surgir estos problemas, ste es un modelo til a la hora de construir un sistema donde no se tiene claros los requisitos inicialmente. La clave est en establecer claramente, al principio, las reglas de juego con el cliente y llegado el momento, no ceder a la presin de ste para conservarlo como producto final.



3.2.3 Modelo Desarrollo Rpido de Aplicaciones (DRA) El Modelo de Desarrollo Rpido de Aplicaciones (DRA), Rapid Application Development (RAD), es un modelo lineal secuencial con un ciclo extremadamente corto. La rapidez se logra gracias al reso de componentes, al empleo de Tcnicas de Cuarta Generacin, y a la posibilidad de dividir el sistema en mdulos o subsistemas, que pueden asignarse a equipos, independientes, que trabaja en paralelo; al finalizar el trabajo de los equipos, los mdulos se integran en un solo producto.

Cuando se utiliza para aplicaciones de sistemas de informacin, el enfoque DRA comprende las siguientes fases: modelo de negocio, modelo de datos, modelo de procesos, generacin de aplicaciones, prueba y entrega (figura 3.4.).

Modelo de Negocio: en esta fase se trata de responder a las siguientes preguntas: qu informacin maneja el proceso de negocio?, qu informacin se genera?, quin la genera?, a dnde va esa informacin?, quin la procesa?

Modelo de Datos: a partir del estudio del flujo de informacin en la fase anterior, se construye un modelo de datos que muestra los objetos, atributos y relaciones entre dichos objetos.

Modelo de Procesos: en esta fase se construye un modelo de procesos donde se muestran las transformaciones necesarias sobre los objetos del modelo de datos a los efectos de lograr la funcionalidad deseada.

Generacin de Aplicaciones: en esta fase se genera la aplicacin con el empleo de tcnicas de cuarta generacin, adems de re-usar componentes existentes (cuando es posible) y la creacin de componentes reutilizables (cuando es necesario).

Prueba y Entrega: Dado que enfatiza la reutilizacin de componentes, los cuales ya han sido probados, el tiempo de prueba se ve reducido. Sin embargo se deben probar todos los componentes nuevos y las interfaces entre mdulos.

Figura 3.4 Modelo DRA

Fuente: (Pressman, 2002)



En este modelo, cuando el proyecto es grande, se requiere un gran nmero de personas para formar equipos paralelos suficientes.

Requiere de un alto compromiso por parte de clientes y desarrolladores en lo que al tiempo se refiere. Si esto falla, el proyecto fracasa.

No todos los tipos de aplicaciones son aptos para aplicar este modelo. Por ejemplo, no son aptos aquellos sistemas que no se pueden modularizar, tampoco funciona bien para aquellos donde existe un bajo reuso de componentes, ya que nuevos deben ser desarrollados y probados.

No es apropiado cuando existen riesgos tecnolgicos altos. Por ejemplo, cuando se hace uso de una nueva tecnologa, o cuando el software nuevo requiere de una alta interoperabilidad con otros ya existentes.

3.2.4 Modelo Incremental En el Modelo Incremental, se aplica, repetidamente, el modelo Lineal Secuencial. Cada secuencia lineal entrega una versin operativa, llamada incremento. El primer incremento entrega la funcionalidad correspondiente a los requerimientos bsicos, el siguiente agrega nueva funcionalidad a la anterior y as, sucesivamente, hasta obtener el producto final (Figura 3.5).

Por ejemplo, para un editor de textos, en el primer incremento podramos entregar funcionando la gestin de archivos y la produccin de documentos, en el segundo incremento las funciones ms sofisticadas relacionadas con la edicin y en el tercer incremento la revisin ortogrfica.

Al finalizar cada incremento, el cliente recibe una versin operativa del producto y lo evala. Como resultado de su utilizacin y evaluacin, se desarrolla un plan para el siguiente incremento. Este plan contempla la modificacin del producto central para cumplir mejor con las necesidades del cliente y adems para agregar nueva funcionalidad.

Figura 3.5 Modelo Incremental

Fuente: (adaptado de Pressman, 2002)

Este modelo es particularmente til cuando no se est seguro de poder cumplir con los plazos de tiempo debido a falta de personal de desarrollo, o cuando se tenga una fecha



imposible de cambiar, ya que en todos los casos, el cliente se queda con una versin operativa del producto.

3.2.5 Modelo Espiral El Modelo en Espiral es un modelo iterativo que proporciona en cada iteracin una versin evolutiva (incremento) del producto.

Durante las primeras iteraciones la versin incremental podra ser un prototipo o un modelo en papel. Durante las ltimas iteraciones se producen versiones cada vez ms completas del software.

El modelo divide las actividades en regiones, generalmente entre tres y seis. En la figura 3.6, se observa un modelo espiral que contiene seis regiones: Comunicacin con el Cliente, Planificacin (se definen recursos y tiempo), Anlisis de Riesgos (se evalan riesgos tcnicos y de gestin), Ingeniera (se construyen modelos de la aplicacin a desarrollar), Construccin y Entrega (se construye, prueba, instala y proporciona soporte al usuario), Evaluacin del Cliente.

El proceso comienza desde el centro, girando en el sentido de las agujas del reloj. En la figura 3.6, el primer circuito, en gris ms oscuro alrededor del espiral, podra resultar en el desarrollo de una especificacin del producto (pueden ocurrir mltiples iteraciones dentro de un circuito); luego, circuitos sucesivos podran ser usadas para desarrollar un prototipo y progresivamente versiones mas sofisticadas del software.

Figura 3.6 Modelo Espiral

Fuente: (adaptado de Pressman, 2002) A diferencia del modelo lineal secuencial que termina cuando se entrega el software, el modelo en espiral puede ser adaptado para ser aplicado a un proyecto que se encuentre en cualquier punto del ciclo de desarrollo.

Cada cubo en la figura 3.6 representa un punto de entrada para un tipo diferente de proyecto. Podemos arrancar desde el cubo de ms adentro para el caso de un proyecto de desarrollo de conceptos hasta que el desarrollo del modelo conceptual haya finalizado. Si el concepto va a ser desarrollado en un producto real, el proceso avanza hasta el prximo cubo, y as sucesivamente para los distintos tipos de proyectos. De esta forma, el proceso puede permanecer parado por un tiempo, pero siempre que un cambio ocurre, el proceso reinicia desde el punto de entrada apropiado (por ejemplo, proyecto de mejora del producto).



3.3 Metodologas Asociado al concepto de proceso de desarrollo de sistemas de informacin, software, o aplicaciones informticas, est el concepto de Metodologa de Desarrollo.

Una Metodologa es el conjunto de procedimientos, tcnicas, herramientas, y un soporte documental que ayuda a los desarrolladores a realizar nuevo software (Pressman, 2005). Una metodologa representa el camino a seguir para desarrollar software o aplicaciones informticas de una manera sistemtica, consiste de un conjunto de fases subdivididas en etapas, actividades y tareas.

Una tarea es una actividad elemental siguiendo algn procedimiento. El procedimiento es la definicin de la forma de ejecutar la tarea. La tcnica es la herramienta utilizada para aplicar un procedimiento. Se pueden utilizar una o varias. Una herramienta es el soporte software que apoya la aplicacin de una tcnica. Un producto es el resultado de cada fase, etapa o actividad de una metodologa.

Se han establecido diversas metodologas para el desarrollo de sistemas de informacin, algunas de las mas citadas son: RUP, MTRICA V3, Merisse, SSADM V4, MDSI.

3.3.1 RUP Rational Unified Process, de la compaa IBM, es una plataforma de proceso de desarrollo de software configurable que entrega mejores prcticas comprobadas y una arquitectura configurable. Permite seleccionar y desplegar solamente los componentes de proceso que usted necesita para cada etapa de su proyecto.

El RUP es un proceso de desarrollo de software y junto con UML (Lenguaje Unificado de Modelado), constituye la metodologa estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.

Link: http://www-01.ibm.com/software/pe/rational/rup.shtml

3.3.2 MTRICA V3 MTRICA, versin 3, Metodologa de Planificacin, Desarrollo y Mantenimiento de Sistemas de Informacin, del Consejo Superior de Administracin Electrnica del Ministerio de la Presidencia del Gobierno de Espaa, ofrece a las Organizaciones un instrumento til para la sistematizacin de las actividades del proceso de desarrollo dentro del marco que permite alcanzar los siguientes objetivos:

Proporcionar o definir Sistemas de Informacin que ayuden a conseguir los fines de la Organizacin mediante la definicin de un marco estratgico para el desarrollo de los mismos.

Dotar a la Organizacin de productos software que satisfagan las necesidades de los usuarios dando una mayor importancia al anlisis de requisitos.

Mejorar la productividad de los departamentos de Sistemas y Tecnologas de la Informacin y las Comunicaciones, permitiendo una mayor capacidad de adaptacin a los cambios y teniendo en cuenta la reutilizacin en la medida de lo posible.

Facilitar la comunicacin y entendimiento entre los distintos participantes en la produccin de software a lo largo del ciclo de vida del proyecto, teniendo en cuenta su papel y responsabilidad, as como las necesidades de todos y cada uno de ellos.



Facilitar la operacin, mantenimiento y uso de los productos software obtenidos.

Link: http://www.csae.map.es/csi/metrica3/index.html

3.3.3 Merisse Merise es un mtodo integrado de anlisis, concepcin y gestin de proyectos, desarrollado en Francia, que provee un marco metodolgico y un lenguaje comn riguroso para los desarrollos informticos.

Es una metodologa de modelado de propsito general en el mbito del desarrollo de sistemas de informacin, ingeniera de software y gestin de proyectos. Fue introducido en la dcada de 1980, desarrollado y perfeccionado hasta el punto en que las organizaciones no gubernamentales francesas, comerciales e industriales ms grandes la han adoptado como metodologa estndar.

Merise separa el tratamiento de datos y de procesos, donde la vista de datos se modela en tres fases: conceptual, lgico y fsico. Del mismo modo, la vista de proceso pasa a travs de tres etapas: conceptual, organizacional y operacional. Estas etapas en el modelado de proceso son paralelas con las etapas del ciclo de vida: planificacin estratgica, el estudio preliminar, un estudio detallado, desarrollo, implementacin y mantenimiento.

Link: http://merise.developpez.com/

3.3.4 SSADM V4 El Mtodo de anlisis y diseo estructurado de sistemas (SSADM Structured Systems Analysis and Design Method (SSADM) es un enfoque de sistemas para el anlisis de sistemas de informacin; fue producido por Central Computer and Telecommunications Agency (nahora Office of Government Commerce), una oficina gubernamental de Reino Unido relacionada con el uso de tecnologa en el gobierno, a partir de 1980.

Las tres tcnicas ms importantes que se utilizan en SSADM son: Modelado lgico de Datos, Modelado de flujo de datos y Modelado de comportamiento de entidades.

Desde 1981 SSADM se ha perfeccionado y la versin 4 fue lanzado en 1990. SSADM es un estndar abierto, es decir, que esta disponible gratuitamente para su en la industria y muchas empresas ofrecen servicios de apoyo, formacin y herramientas CASE para ello.

3.3.5 MDSI La metodologa MDSI Versin 2.0, es una herramienta desarrollada en base a la metodologa de Mtrica 3 del Ministerio de Administracin Pblica de Espaa (MAP) y RUP (Rational Unified Process), han sido revisados y adaptados para su aplicacin en las entidades integrantes del Sistema Nacional de Informtica por la Oficina Nacional de Gobierno Electrnico e Informtica ONGEI de la Presidencia del Consejo de Ministros - PCM. Es un instrumento til para la sistematizacin de las actividades que dan soporte al ciclo de vida del software. Incluye: Modelamiento del Negocio, Modelamiento de Requerimientos, Modelamiento de Tecnologa, Construccin, Pruebas e Implantacin del Sistema de Informacin



Leccin 4

Introduccin al UML 4.1 Qu es el UML? UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado en una notacin grfica, que permite: especificar, construir, visualizar y documentar los elementos de un sistema software, as como para modelar los procesos de negocios u otros sistemas no software (Jacobson, 2006).

Puede ser utilizado por cualquier metodologa de desarrollo orientada a objetos. Este lenguaje es el resultado de la unificacin de los mtodos de modelado orientados a objetos de: Grady Booch, Jim Rumbaugh, Ivar Jacobson.

Un lenguaje de modelado permite expresar los distintos modelos (artefactos) que se producen en el proceso de desarrollo de software.

4.2 Artefacto, Modelo y Diagrama Artefacto

Un artefacto representa la informacin que es utilizada o producida durante un proceso de desarrollo de software. Ejemplo: documento de especificacin de requisitos, un modelo, un programa.

Modelo

Un modelo es una representacin abstracta de una especificacin, un diseo o un sistema desde un punto de vista particular. Representa uno o ms diagramas. Ejemplos: modelo de casos de uso, modelo de negocio.

Diagrama

Un diagrama es una representacin grfica de una coleccin de elementos del modelo. Ejemplos: diagrama de casos de uso, diagrama de clases.

4.3 Elementos en UML Los elementos del UML se clasifican en: estructurales, de comportamiento, de agrupacin y de anotacin.

Elementos Estructurales

Los elementos estructurales representan la parte esttica del sistema. Se incluyen (figura 4.1): Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de responsabilidad.

Figura 4.1 Elementos estructurales del UML

Clase

Interfaz Componente

Nodo Caso de uso Colaboracin



La Clase representa un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica.

La Interfaz representa la definicin un conjunto de especificaciones de operaciones

La Colaboracin representa una iteracin, es una sociedad de roles y otros elementos que colaboran cooperativamente

El Caso de Uso representa una funcionalidad del sistema, es un conjunto de secuencias de acciones que se ejecutan con el objetivo de lograr un resultado de inters para un grupo de usuarios en particular.

El Componente representa es empaquetamiento fsico de diferentes elementos lgicos como clases, interfaces, y colaboraciones.

El Nodo representa a un elemento fsico del sistema, es decir un recurso computacional.

Elementos de comportamiento

Los elementos de comportamiento representan la parte dinmica del sistema, es decir el comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.

La Interaccin representa un Conjunto de mensajes intercambiados entre objetos.

El Estado Identifica un perodo de tiempo del objeto (no instantneo) en el cual el objeto esta esperando alguna operacin, recibe cierto tipo de estmulos y especifica la secuencia de estado por las que pasa un objeto.

Elementos de agrupacin

Los elementos de agrupacin representan la parte organizativa del sistema. Incluye: Paquete.

El Paquete es el mecanismo de propsito general para organizar elementos.

Elementos de anotacin

Los elementos de anotacin representan la parte explicativa del sistema. Son comentarios. Incluye: la nota

La Nota sirve para hacer comentarios a un conjunto de elementos.

Interaccin

Mensaje

Estado

Paquete



4.4 Relaciones en UML Las relaciones del UML representan los vnculos entre dos elementos del modelo. Incluye: dependencia, asociacin, generalizacin y realizacin.

Dependencia

Representa una relacin semntica entre dos elementos, tal que un cambio en uno de ellos (el independiente) puede afectar al otro (el dependiente).

Asociacin

Representa una relacin estructural que describe un conjunto de links, siendo un link una conexin entre objetos.

Generalizacin

Representa una relacin de generalizacin/especializacin en la que el elemento especializado (descendiente) se construye sobre la especificacin del elemento generalizado (ancestro)

Realizacin

Representa una relacin semntica en la que un clasificador, tal como una interfaz o un caso de uso, especifica un contrato que otro clasificador, tal como una clase o una colaboracin, garantiza llevar a cabo.

4.5 Diagramas en UML La versin 2.0 del UML (Booch, 2006) considera 13 diagramas (figura 4.2), divididos en Diagramas dinmicos y estticos.

Figura 4.2 diagramas del UML

Fuente: (Adaptado de Jacobson, 2006)



El Diagrama de Clases, muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones.

El Diagrama de objetos, muestra una instantnea de un conjunto de objetos y sus relaciones.

El Diagrama de componentes, muestra la organizacin y dependencias entre un conjunto de componentes conocida como vista de implementacin de un sistema. Estn relacionados a Diagramas de clases en donde un componente se Corresponde con una o

ms clases interfaces o colaboraciones.

El Diagrama de despliegue, muestra los enlaces de comunicacin fsica entre elementos de hardware y las relaciones entre mquinas fsicas y procesos (qu se ejecuta y dnde).

El Diagrama de estructura compuesta, muestra la estructura interna (incluyendo partes y conectores) de un clasificador o una colaboracin estructurada.

El Diagrama de paquetes, muestra la descomposicin del modelo en unidades de organizacin y sus dependencias.

El Diagrama de casos de uso, muestra un conjunto de casos de uso y actores y sus relaciones.

El Diagrama de secuencia, es un diagrama de interaccin que muestra los objetos y actores que participan en una colaboracin poniendo el nfasis en el ordenamiento en el tiempo de los mensajes.

El Diagrama de colaboracin, es un diagrama de Interaccin que pone el nfasis en la organizacin estructural de los objetos o roles que envan y reciben mensajes.

El Diagrama de estados, muestra un autmata que consiste de estados, transiciones, eventos y actividades.

El Diagrama de actividades, muestra la estructura de un proceso u otro clculo como el flujo de control y datos paso a paso en el clculo.

El Diagrama cronolgico, es un diagrama de interaccin que muestra tiempos a lo largo de diferentes objetos o roles, y no secuencias relativas de mensajes.

El Diagrama de interacciones general, es un hbrido de diagramas de actividad y de secuencia.



Leccin 5

Introduccin al RUP 5.1 Qu es el RUP? El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo, es decir define quin hace qu, cundo y cmo (Jacobson, 2000).

Es un marco de trabajo genrico que puede especializarse. Es iterativo e incremental.

5.2 Elementos

5.2.1 Trabajador (Worker) Es un rol que debe ser realizada por una persona o equipo. Un worker o rol define el comportamiento y responsabilidades de un miembro especfico (o equipo especfico). Una misma persona puede llevar a cabo diversos roles. Algunos ejemplos de rol son Lder de Proyecto, Analista de sistemas, programador.

5.2.2 Actividad Es una unidad de trabajo que debe ser ejecutada. Una actividad es la ms pequea pieza de trabajo que es relevante. No es razonable hacer actividades en forma parcial. Dividir el trabajo de esta manera hace ms fcil controlar el avance del proyecto. Es mejor saber que hay 3 actividades completas de 5, que saber que llevamos el 60% de una actividad. Ejemplos de actividades son Planificar una Iteracin, Revisar el Diseo, Capturar requisitos.

5.2.3 Artefacto Es una pieza de informacin que es producida, modificada o usada en un proceso de desarrollo de software. Un artefacto es algo que se produce e el curso del desarrollo de un producto de software. Incluye el cdigo fuente, los modelos, documentos y otros productos del ciclo de vida. UML define la notacin para representar la mayor parte de los artefactos.

5.2.4 Modelo Cada Trabajador, necesita una perspectiva del Sistema. El Artefacto ms comn para representar una perspectiva es el Modelo. Los principales modelos de RUP son: Modelo del negocio, modelo de casos de uso, modelo de diseo, modelo de implementacin, modelo de prueba.

El Modelo de Negocios es el modelo de los procesos de negocio y su medioambiente. Es usado para generar requerimientos de los sistemas de informacin que lo soportan.

El Modelo de Casos de Uso es un modelo acerca de lo que el sistema debe hacer y su medioambiente.



El Modelo de Diseo es un modelo de objetos que describen la realizacin de los Casos de Uso. Sirve como una abstraccin del Modelo de Implementacin y su cdigo fuente.

El Modelo de Implementacin es un conjunto de componentes y subsistemas que los contienen.

El Modelo de Test abarca todos los casos de test y procedimientos requeridos para probar el sistema.

5.2.5 Flujos de trabajo (Workflow) Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso. Define una lista de actividades, trabajadores y artefactos.

El RUP trabaja a travs de modelos. Se requieren muchos modelos para describir el sistema durante su evolucin. Cada uno de los Workflows produce modelos, que se van desarrollando incrementalmente durante las iteraciones (figura 5.1)

Figura 5.1 Flujos y modelos.

Fuente: (Jacobson, 2000)

5.3 Fases El RUP es un modelo de proceso del software dividido en cuatro fases: Inicio. Elaboracin, Construccin y Transicin (Figura 5.2). Estas fases estn mucho ms relacionadas con el funcionamiento de la organizacin que con aspectos tcnicos de la implementacin

5.3.1 Fase de Inicio Su objetivo es el de establecer un caso de negocio para el sistema. Se deben identificar todas las entidades externas (personas y sistemas) que interactuarn con el sistema y definir estas interacciones. Esta informacin se utiliza entonces para evaluar la aportacin que el sistema hace al negocio. Si esta aportacin es de poca importancia se puede cancelar el proyecto despus de esta fase.

5.3.2 Fase de Elaboracin Los objetivos de esta fase son: Comprender el dominio del problema, Establecer un marco de trabajo arquitectnico para el sistema, Desarrollar el plan del proyecto, Identificar los riesgos clave del proyecto.



Al finalizar esta fase, se obtienen: Un modelo de los requerimientos del sistema (casos de uso UML), Una descripcin arquitectnica, Un plan de desarrollo del software,

5.3.3 Fase de Construccin Comprende fundamentalmente: El diseo del sistema, La implementacin, Las pruebas. Durante esta fase se desarrollan e integran las partes del sistema.

Al finalizar esta fase, se obtienen: Un sistema software funcional, La documentacin correspondiente a ste.

5.3.4 Fase de Transicin Se ocupa de mover el sistema desde la comunidad de desarrollo a la comunidad del usuario. Tambin de hacer trabajar el software en un entorno real. Esta fase es comnmente ignorada en la mayora delos modelos de proceso de software, an cuando es muy importante y pude implicar altos costos.

Al finalizar esta fase, se obtiene: Un sistema de software documentado adecuadamente y que funcione correctamente en su entorno operativo

5.4 Flujos La perspectiva esttica del RUP se centra en las actividades que tienen lugar durante el proceso de desarrollo. stas se denominan flujos de trabajo en la descripcin del RUP (Figura 5.2).

Existen seis flujos de trabajo del proceso: Modelado de negocio Requerimientos Anlisis y diseo Implementacin Pruebas Implantacin

Existen tres flujos de trabajo de soporte Administracin de cambios y configuracin Administracin del proyecto Entorno

Figura 5.2 Estructura del RUP, fases y flujos.

Fuente: (Jacobson, 2000)



Resumen Proceso de desarrollo de sistemas de informacin

Un proceso de desarrollo es una gua acerca de las actividades y tareas necesarias para construir un sistema de informacin. Es un marco de trabajo que define las tareas a realizar para desarrollar software de alta calidad.

Las fases genricas de un proceso de desarrollo son: Definicin, Desarrollo y Evolucin.

La fase de definicin se centra en el que. Su propsito es identificar las necesidades o requerimientos del cliente/usuario. Sus actividades son: Anlisis del sistema, Requerimientos de software, y Planificacin del proyecto de software.

La fase de desarrollo se centra en el cmo. Su propsito es descubrir cmo han de disearse las estructuras de datos y la arquitectura del software, etc. Se realizan tres pasos concretos: Diseo del Software, Codificacin y Pruebas del software.

La fase de evolucin, tambin llamada fase de mantenimiento, se centra en el cambio que va asociado a la Correccin, a la Adaptacin y Mejora del software.

Los modelos de proceso de desarrollo de software se clasifican en

Modelo secuencial, se caracteriza porque las actividades del desarrollo progresan de manera secuencial, una actividad no puede inicia sino a terminado la anterior.

Modelos iterativos, se caracterizan porque las actividades se repiten de manera cclica. Entre los modelos iterativos podemos mencionar: Construccin de prototipos y Desarrollo Rpido de Aplicaciones.

Modelos evolutivos, se caracterizan porque son iterativos y en cada iteracin se agrega nueva funcionalidad (versiones) al sistema. Se puede mencionar al modelo incremental y al modelo espiral.

Una metodologa representa el camino a seguir para desarrollar software o aplicaciones informticas de una manera sistemtica, consiste de un conjunto de fases subdivididas en etapas, actividades y tareas.

Una tarea es una actividad elemental siguiendo algn procedimiento.

El procedimiento es la definicin de la forma de ejecutar la tarea.

La tcnica es la herramienta utilizada para aplicar un procedimiento; se pueden utilizar una o varias.

Una herramienta es el soporte software que apoya la aplicacin de una tcnica.

Un producto es el resultado de cada fase, etapa o actividad de una metodologa

Introduccin a UML

UML (Unified Modeling Language, Lenguaje de Modelado Unificado) es un lenguaje, basado en una notacin grfica, que permite: especificar, construir, visualizar y documentar los elementos de un sistema software, as como para modelar los procesos de negocios u otros sistemas no software

Un artefacto representa la informacin que es utilizada o producida durante un proceso de desarrollo de software. Ejemplo: documento de especificacin de requisitos, un modelo, un programa.

Un modelo es una representacin abstracta de una especificacin, un diseo o un sistema desde un punto de vista particular. Representa uno o ms diagramas. Ejemplos: modelo de casos de uso, modelo de negocio.

Un diagrama es una representacin grfica de una coleccin de elementos del modelo. Ejemplos: diagrama de casos de uso, diagrama de clases.

Los elementos del UML se clasifican en: estructurales, de comportamiento, de agrupacin y de anotacin.

Los elementos estructurales representan la parte esttica del sistema. Se incluyen (figura 4.1): Clase, Interfaz, nodo, caso de uso, interfaz, clase activa, componente, cadena de responsabilidad.

Los elementos de comportamiento representan la parte dinmica del sistema, es decir el comportamiento en el tiempo y el espacio. Se incluyen: Interacciones y estados.



Los elementos de agrupacin representan la parte organizativa del sistema. Incluye: Paquete.

Los elementos de anotacin representan la parte explicativa del sistema. Son comentarios. Incluye: la nota

Las relaciones en UML representan los vnculos entre dos elementos del modelo. Incluye: dependencia, asociacin, generalizacin y realizacin.

La dependencia representa una relacin semntica entre dos elementos, tal que un cambio en uno de ellos (el independiente) puede afectar al otro (el dependiente, clase activa, componente, cadena de responsabilidad

La asociacin representa una relacin estructural que describe un conjunto de links, siendo un link una conexin entre objetos.

La generalizacin representa una relacin de generalizacin/especializacin en la que el elemento especializado (descendiente) se construye sobre la especificacin del elemento generalizado (ancestro)

La realizacin representa una relacin semntica en la que un clasificador, tal como una interfaz o un caso de uso, especifica un contrato que otro clasificador, tal como una clase o una colaboracin, garantiza llevar a cabo.

Los diagramas en UML, version2.0, son 13, divididos en diagramas estticos y dinmicos.

Los diagramas estticos son: diagrama de clases, diagrama de objetos, diagrama de componentes, diagrama de despliegue, diagrama de paquetes y diagrama de estructura.

Los diagramas dinmicos son: diagrama de casos de uso, diagrama de secuencia, diagrama de colaboracin, diagrama de estado, diagrama de actividades, diagrama cronolgico, diagrama de interacciones.

Introduccin a RUP

El RUP (Rational Unified Process, Proceso Unificado de Rational) es un proceso de desarrollo de

software, es una forma disciplinada de asignar tareas y responsabilidades en una empresa de

desarrollo, es decir define quin hace qu, cundo y cmo

Elementos del RUP

Un trabajador es un rol que debe ser realizada por una persona o equipo

Una actividad es una unidad de trabajo que debe ser ejecutada

Un artefacto es una pieza de informacin que es producida, modificada o usada en un proceso de desarrollo de software

Un modelo es una representacin de alguna perspectiva del sistema

Un flujo de trabajo es una secuencia de actividades que produce un resultado valioso, define una lista de actividades, trabajadores y artefactos.

Las fases del RUP son; Inicio, Elaboracin, Construccin y Transicin.



Lectura Tcnicas de cuarta generacin (*)

El trmino tcnicas de cuarta generacin (T4G) abarca un amplio espectro de herramientas de software que tienen algo en comn: todas facilitan al ingeniero del software la especificacin de algunas caractersticas del software a alto nivel. Luego, la herramienta genera automticamente el cdigo fuente basndose en la especificacin del tcnico. Cada vez parece ms evidente que cuanto mayor sea el nivel en el que se especifique el software, ms rpido se podr construir el programa. El paradigma T4G para la ingeniera del software se orienta hacia la posibilidad de especificar el software usando formas de lenguaje especializado o notaciones grficas que describa el problema que hay que resolver en trminos que los entienda el cliente. Actualmente, un entorno para el desarrollo de software que soporte el paradigma T4G puede incluir todas o algunas de las siguientes herramientas: lenguajes no procedimentales de consulta a bases de datos, generacin de informes, manejo de datos, interaccin y definicin de pantallas, generacin de cdigos, capacidades grficas de alto nivel y capacidades de hoja de clculo, y generacin automatizada de HTML y lenguajes similares utilizados para la creacin de sitios web usando herramientas de software avanzado. Inicialmente, muchas de estas herramientas estaban disponibles, pero slo para mbitos de aplicacin muy especficos, pero actualmente los entornos T4G se han extendido a todas las categoras de aplicaciones del software.

Al igual que otros paradigmas, T4G comienza con el paso de reunin de requisitos. Idealmente, el cliente describe los requisitos, que son, a continuacin, traducidos directamente a un prototipo operativo. Sin embargo, en la prctica no se puede hacer eso. El cliente puede que no est seguro de lo que necesita; puede ser ambiguo en la especificacin de hechos que le son conocidos, y puede que no sea capaz o no est dispuesto a especificar la informacin en la forma en que puede aceptar una herramienta T4G. Por esta razn, el dilogo cliente-desarrollador descrito por los otros paradigmas sigue siendo una parte esencial del enfoque T4G.

Para aplicaciones pequeas, se puede ir directamente desde el paso de recoleccin de requisitos al paso de implementacin, usando un lenguaje de cuarta generacin no procedimental (L4G) o un modelo comprimido de red de iconos grficos. Sin embargo, es necesario un mayor esfuerzo para desarrollar una estrategia de diseo para el sistema, incluso si se utiliza un L4G. El uso de T4G sin diseo (para grandes proyectos) causar las mismas dificultades (poca calidad, mantenimiento pobre, mala aceptacin por el cliente) que se encuentran cuando se desarrolla software mediante los enfoques convencionales.

La implementacin mediante L4G permite, al que desarrolla el software, centrarse en la representacin de los resultados deseados, que es lo que se traduce automticamente en un cdigo fuente que produce dichos resultados. Obviamente, debe existir una estructura de datos con informacin relevante y a la que el L4G pueda acceder rpidamente.

Para transformar una implementacin T4G en un producto, el que lo desarrolla debe dirigir una prueba completa, desarrollar con sentido una documentacin y ejecutar el resto de las actividades de integracin que son tambin requeridas por otros paradigmas de ingeniera del software. Adems, el software desarrollado con T4G debe ser construido de forma que facilite la realizacin del mantenimiento de forma expeditiva.

Al igual que todos los paradigmas del software, el modelo T4G tiene ventajas e inconvenientes. Los defensores aducen reducciones drsticas en el tiempo de desarrollo del software y una mejora significativa en la productividad de la gente que construye el software. Los detractores aducen que las herramientas actuales de T4G no son ms fciles de utilizar que los lenguajes de programacin, que el cdigo fuente producido por tales herramientas es ineficiente y que el mantenimiento de grandes sistemas de software desarrollados mediante T4G es cuestionable.



Hay algn mrito en lo que se refiere a indicaciones de ambos lados y es posible resumir el estado actual de los enfoques de T4G:

1. El uso de T4G es un enfoque viable para muchas de las diferentes reas de aplicacin. Junto con las herramientas de ingeniera de software asistida por computadora (CASE) y los generadores de cdigo, T4G ofrece una solucin fiable a muchos problemas del software.

2. Los datos recogidos en compaas que usan T4G parecen indicar que el tiempo requerido para producir software se reduce mucho para aplicaciones pequeas y de tamao medio, y que la cantidad de anlisis y diseo para las aplicaciones pequeas tambin se reduce.

3. Sin embargo, el uso de T4G para grandes trabajos de desarrollo de software exige el mismo o ms tiempo de anlisis, diseo y prueba (actividades de ingeniera del software), para lograr un ahorro sustancial de tiempo que puede conseguirse mediante la eliminacin de la codificacin.

Resumiendo, las tcnicas de cuarta generacin ya se han convertido en una parte importante del desarrollo de software. Cuando se combinan con enfoques de ensamblaje de componentes el paradigma T4G se puede convertir en el enfoque dominante hacia el desarrollo del software. (*)Fuente: (Pressman, 2002)



Actividades 1. Realice un cuadro comparativo entre los modelos de ciclo de vida de desarrollo de

software, indicando criterios de comparacin, ventajas y desventajas de cada una de ellas por cada criterio.

2. Busque en internet herramientas de software libre para modelar con el UML 2.0. .

Autoevaluacin Responda las siguientes preguntas:

1. Un proceso de desarrollo es 2. Las fase de un proceso de desarrollo son: 3. Indique las caractersticas de los siguientes modelos de ciclo de vida:

a. Secuencial b. Construccin de prototipos c. Desarrollo rpido de aplicaciones d. Incremental e. Espiral

4. Una definicin de metodologa es 5. Un producto, tcnica, herramientas son 6. El UM

Documents

Análisis de Sistemas