ORGANIZACIÓN DE ARCHIVOS DE ALTO NIVEL

Análisis y Diseño de Sistemas 1 Fundamentos del

Análisis y Diseño de Sistemas

FUNDAMENTOS DEL ANÁLISIS Y DISEÑO DE SISTEMAS

1.1 DEFINICIÓN Y CARACTERÍSTICAS DE LOS SISTEMAS

La palabra sistema se emplea actualmente en mucho ámbitos distintos: se habla de sistemas electrónicos, sistemas monetarios, sistemas de seguridad, el sistema solar, e incluso, de sistemas de juego e equipo de fútbol. La razón es que, al igual que lo que ocurre con otras palabras como conjunto, el término sistema se emplea par designar un concepto, una herramienta genérica que se puede emplear para explicar o analizar mejor cómo es o qué ocurre en una determinada área social, económica, física, etc. el diccionario de la Real Academia española nos dice que sistema es "un conjunto de cosas que, relacionadas entre sí ordenadamente, contribuyen a un determinado objetivo". A partir de esta definición, podemos identificar cuáles son los principales elementos presentes en cualquier sistema.

· Los componentes de sistema.

· Las relaciones entre ellos, que determinan la estructura del sistema.

· El objetivo del sistema

En todos lo sistemas también podemos identificar otros elementos importantes para comprender cómo son y cómo funcionan:

· El entorno del sistema: Aquello que lo rodea, dentro del cual está ubicado.

· Los límites del sistema: La frontera entre lo que es el sistema y lo que constituye el entorno.

Ejemplo: Sistema Circulatorio

Componente: Corazón, arterias, venas, etc.

Relaciones: El corazón bombea sangre hacia las arterias que están dispuestas según una determinada estructura, etc.

Objetivo: Asegurar el suministro de sangre a todo el cuerpo.

Entorno: El cuerpo.

Límites: La frontera entre lo que es el sistema y lo que constituye el entorno.

1.1.1 ELEMENTOS DE UN SISTEMA

No todos los sistemas tienen la misma combinación de elementos, siendo una configuración básica: la entrada, transformación y salidas.

(ENTRADATRANSFORMACIÓNSALIDA)

Por estos elementos fluyen los recursos de una organización. Existe un mecanismo de control que vigila el proceso de transformación para asegurar que el sistema cumpla con sus objetivos. El mecanismo de control se conecta al flujo de recursos por medio de un ciclo de retroalimentación, que obtiene información de las salidas del sistema y la pone a disposición del mecanismo de control, este compara las señales de retroalimentación con los objetivos y envía señales al elemento de salida en caso de que sea necesario alterar el funcionamiento del sistema.

Ejemplo:

Sistema de calefacción

Entrada

Gas natural o carbón

Transformación

Diferentes componentes

Salida

Calor

Mecanismo de control

Termostato

Ciclo de retroalimentación

Cableado que conecta el termostato con el calefactor

Objetivo

Temperatura que se ajusta al termostato

Ejemplo:

Compañía de manufactura

Entrada

Materias primas

Transformación

Diferentes maquinarias

Salida

Producto

Mecanismo de control

Gerencia de empresa

Ciclo de retroalimentación

Flujo de información hacia y desde la gerencia

Objetivo

Metas que tiene la compañía

1.1.2 SISTEMAS ABIERTOS Y SISTEMAS CERRADOS

Los sistemas son cerrados o abiertos, dependiendo de la naturaleza de la información que fluye dentro de una organización. Un sistema cerrado se mantiene aislado, sin conexión, con otro sistema: nada fluye de otro sistema, nada fluye hacia otro sistema. Un sistema abierto interactúa con otro sistema. Por ejemplo, un sistema de contabilidad que registra cuentas por cobrar, cuentas por pagar, y flujo de caja es abierto si recibe las cifras relacionados con los sueldos del sistema de sueldos. Por definición los subsistemas siempre son abiertos, como con componentes de un sistema más grande deben recibir información de otros subsistemas y dar información a éstos.

No todos los sistemas controlan sus propias operaciones. Un sistema que carece de los elementos de mecanismo de control, ciclo de retroalimentación y objetivos se denomina sistema de cicla abierto.

(ENTRADATRANSFORMACIÓNSALIDA)

Ejemplo:

Calefactor de espacios eléctricos, produce calor hasta que se le apague.

Un sistema provisto de los tres elementos de control (objetivos, mecanismo de control y ciclo de retroalimentación) es un sistema de ciclo cerrado.

(MECANISMO DE CONTROLTRANSFORMACIÓNOBJETIVOENTRADASALIDA)

1.1.3 SUBSISTEMAS

Un subsistema no es más que un sistema dentro de un sistema. Las partes de un sistema pueden ser de un sistema de un nivel más bajo o partes elementales.

(SISTEMA)

(PARTE ELEMENTAL) (SUBSISTEMA B) (SUBSISTEMA A)

(SUB - SUB SISTEMAS B-1) (SUB - SUB SISTEMAS A-1)

(SUB - SUB SISTEMAS B-2) (SUB - SUB SISTEMAS A-2)

(SUB - SUB SISTEMAS A-3)

(PARTE ELEMENTAL )

Ejemplo:

(AUTOMÓVILSUBSISTEMAS MOTORSUBSISTEMAS CARROCERÍASUBSISTEMAS DE SUSPENSIÓNSUBSISTEMAS CARBURADORSUBSISTEMAS GENERADORSUBSISTEMAS COMBUSTIBLES)

Una empresa es un sistema que se compone de funciones o subsistemas de información.

FUNCIONES

SUBSISTEMAS

SISTEMAS

AUTOMATIZADOS

COMERCIAL

Estudios de mercado

Ventas

Control de clientes

Inventarios de productos terminados

Comisiones a vendedores

Compras de productos terminados distribución

Sistemas empresariales que se integra por:

Compras

Ventas

Control de inventarios

Etc.

PRODUCCIÓN

Compras de materiales

Control de inventarios

Control de proveedores

Ordenes d producción

Costos de manufactura

Sistema integrado de producción

FINANZAS

Contabilidad

Presupuestos

Control fiscal

Control de activos fijos

Tesorería

Cuentas por cobrar y por pagar

Bancos

Sistema contable, integrado por:

Contabilidad

Presupuesto

Control de activo fijo

Fiscal

Etc.

ADMINISTRACIÓN

Recursos humanos

Capacitación

Control de préstamos

Recursos materiales

Sistemas de nóminas que integra:

Nóminas, préstamos, capacitación, etc.

Considere los diferentes departamentos de un negocio de producción. El departamento de mercadotecnia trata de promover la venta de los productos; el departamento de ingeniería trata de diseñar nuevos productos y mejorar el existente, el de finanzas trata de planear un presupuesto claro y devengar intereses por cada centavo no utilizados al final del día. Cada departamento es un subsistema con su propio objetivo, que es un sub objetivo de un sistema más grande (la empresa), cuyo objetivo es obtener la máxima ganancia.

1.2 PRINCIPALES TIPOS DE RECURSOS DE UNA COMPAÑÍA

El gerente de una compañía administra cinco tipos principales de recursos:

· Personal

· Material

· Máquina (incluido instalaciones y energía)

· Dinero

· Información (incluido datos)

La tarea del gerente es administrar estos recursos para aprovecharlos de la forma más eficaz posible.

Los primeros cuatro tipos de recursos son tangibles; existen físicamente y pueden tocarse, llamados recursos físicos.

El quinto tipo de recurso, información, no es valioso por su forma tangible sino por lo que representa, llamado recurso conceptual.

Los gerentes usan recursos conceptuales para administrar los recursos físicos:

1.3 ADMINISTRACIÓN DEL RECURSO INFORMACIÓN

El gerente se asegura que se recopila los datos necesarios en bruto y luego se procesan para producir información útil. Después, el o ella se asegura que los individuos apropiados reciban la información en un formato adecuado y en el momento oportuno para que pueda aprovecharse. Por último, el gerente desecha la información que ya no es útil y la sustituye por información y exacta. Toda esta actividad se denomina administración de la información.

Se administra la información por dos razones principales:

· Creciente complejidad de la actividad comercial

Los negocios siempre han sido complejos pero no hay su complejidad ha alcanzado niveles sin precedentes.

Todas las compañías están sujetas a influencias económicas internacionales:

· Origen en cualquier punto del mundo

· Se hacen evidentes en los valores relativos de las monedas de cada nación

Y compiten en un mercado mundial;

· La competencia es a nivel mundial

· Los efectos de la competencia se ven en las importaciones de otros países

La tecnología de los negocios se ha vuelto más compleja,

· Lectores de código de barra en los supermercados

· Sistemas de reservación aéreas por computadora

· Cajeros automáticos, etc.

Los plazos para emprender acciones se están reduciendo,

· Existen telecomunicaciones para ponerse en contacto telefónico con sus clientes segundos

· Las órdenes de venta se transmiten electrónicamente de una computadora a otra

Y han aparecido restricciones sociales,

· Las decisiones de negocio deben basarse en factores económicos, pero también deben considerarse los costos y las recompensas sociales

· Aumento en la capacidad de las computadoras

· enormes computadoras

· mini computadoras (microcomputadoras)

· el usuario moderno no considera la computadora como algo especial, sino como un equipo de oficina necesario

1.4 SISTEMAS DE INFORMACIÓN

Conjunto de instrucciones organizacionales sistematizadas y lógicas que se relacionan entre sí por medio de un lenguaje informático con el fin de obtener información, analizarla, relacionarla y generar nueva información para satisfacer las necesidades de las áreas administrativas, operativas de una organización en general.

Es un grupo de gente, una serie de procedimientos o equipos de procesamiento de datos que escogen, almacenan, procesan t recuperan datos para disminuir la incertidumbre en la toma de decisiones mediante el suministro de información a los niveles gerenciales para que sea utilizada eficazmente.

1.4.1 ELEMENTOS DE UN SISTEMA DE INFORMACIÓN

Existen Estos elementos son de naturaleza diversa y normalmente incluyen:

· El equipo computacional,

El hardware necesario para que el sistema de información pueda operar. Lo constituyen las computadoras y el equipo periférico que pueda conectarse a ellas.

· El recurso humano

Que interactúa con el Sistema de Información, el cual esta formado por las personas que utilizan el sistema, alimentándolo con datos o utilizando los resultados que genere.

· Los datos o información fuente

Son introducidos en el sistema; son todas las entradas que necesita el sistema para generar como resultado la información que se desea.

· Los programas

Son procesados y producen diferentes tipos de resultados. Los programas son parte del software del sistema de información que hará que los datos de entrada introducidos sean procesados correctamente y generen los resultados que se esperan.

1.4.2 NIVELES DE UN SISTEMA DE INFORMACIÓN

El Sistema de Información de una Organización no siempre está a un mismo nivel. Dentro de él podremos encontrar varios.

· Primer nivel Operacional o Transaccional

Existe en todas las Organizaciones y tiene que ver con la operativa diaria.

Ejemplo

En una empresa de servicios telefónicos, estaría incluido en este nivel, las operaciones de realizar un contrato, consultar el estado de un teléfono, dar de alta una avería, etc.

· Segundo nivel Sistemas de Información Administrativo (MIS)

Ayudan a los usuarios de mayor nivel en la empresa a tomar decisiones (todas o algunas), sobre asuntos que pueden presentarse con alguna regularidad. No son transacciones pero sí consultas estructuradas a partir de algún lenguaje de manipulación de datos que le permita obtener informes más o menos complejos.

Ejemplo

Siguiendo con el anterior podría ser: el número de averías en los últimos días.

· Tercer nivel Sistemas para el Soporte de Decisiones.

Su objetivo es ayudar en la toma de decisiones para situaciones poco frecuentes y sobre todo poco estructuradas.

Ejemplo

Un nuevo modelo de contestador.

Las Organizaciones añoran a un Sistema de Información total, con una característica de integración que permita los tres niveles, sobre las mismas herramientas, procesos y recursos.

1.5 METODOLOGÍAS, TÉCNICAS Y HERRAMIENTAS

Se consideraba que el análisis y diseño de sistemas era un arte en los tiempos pasados de la computación. Ahora la necesidad para los sistemas y software es grande, la gente en la industria y academias tienen desarrollados métodos de trabajo que hacen del análisis y diseño una disciplina de procesos. La meta es ayudar al conocimiento y habilidades para que entienda y siga tales diseños de procesos en la ingeniería de software.

Para los diseñadores en la ingeniería de software, existen varias metodologías, técnicas y herramientas que se tienen desarrollados, verificados y ampliamente usados para ayudar a las personas durante el análisis y diseño de sistemas.

· METODOLOGÍAS

Las metodologías son comprensivas, de múltiples pasos que dirigen a uno en el desarrollo de sistemas y que guiará su trabajo e influenciará en la calidad de su producto final: el Sistema de Información.

Una metodología adoptada por una organización sería consistente con su estilo de administración general (por ejemplo, la orientación de una organización hacia un acuerdo general de la administración influirá en su opción de metodología para el desarrollo del Sistemas)

· TÉCNICAS

Son procesos particulares que usted como analista seguirá para ayudar a asegurar que ese trabajo este bien pensado, completo y comprensible a los otros en su equipo de su proyecto.

· HERRAMIENTAS

Las herramientas son típicamente programas de computación de forma que hacen fácil de usar y beneficiar las técnicas y seguir fielmente la metodología del desarrollo del sistema.

1.6 UN MÉTODO MODERNO PARA EL ANÁLISIS Y DISEÑO DE SISTEMAS1.6.1 SEPARANDO DATOS Y PROCESOS QUE SE OCUPAN DE DATOS

Cada Sistema de información consiste de tres componentes claves que pueden claramente ser comprendidos por cualquiera que analiza y diseña un sistema.

Dato

Los datos son hechos crudos que describen a las personas objetos y eventos en una organización, como el número de cuenta de un cliente, el número de cajas de cereal que compró, si alguien es de la izquierda o derecha, etc.

Cada sistema de información depende de los datos para producir información, que es dato procesado y presentado en forma apropiada para la interpretación humana.

Los desarrolladores de sistemas deben entender qué tipo de datos se usa en un sistema y estos datos donde se originan.

Los datos y las relaciones entre los datos pueden ser descritos usando varias técnicas, como por ejemplo una tabla con filas y columnas.

Nombre

Edad

Partido

Juan Quispe

25

Ultraderecha

Maria Flores

42

Ultra izquierda

WilmaPlata

35

Independiente

Flujo de Datos

Los flujos de datos son grupos de datos que se mueven y fluyen a través de un sistema e incluyen una descripción de las fuentes y destinos para cada flujo de dato.

(ValidarCréditoVenta de TarjetaTransacciónPreparar informe de aceptaciónInformeNúmero de Cuenta y TransacciónNumero de Cuenta Validado y TransacciónNúmero de Cuenta y Transacción)

Procesos lógicos

Este tercer componente describe los pasos en la transformación del dato y los eventos que enlazan estos pasos.

Por ejemplo

El proceso lógico en una aplicación de tarjeta de crédito explicará como la computadora es capaz de dar el crédito de acuerdo al saldo actual del crédito y el monto de la transacción actual. El proceso lógico también indicará el cómputo del nuevo saldo de la tarjeta de crédito y ocurrirá que cuando un empleado presione la clave de la tarjeta de crédito en un scanner se confirmará la transacción del crédito.

Tradicionalmente, el diseño de un sistema de información era basado en lo que se suponía que el sistema hacía, como cargar una cuenta y el control de inventario: el enfoque estaba en las salidas y el proceso lógica. Aunque los datos que el sistema usaba como la entrada, eran importantes, los datos estaban subordinados a la aplicación.

La suposición era que nosotros pudiéramos anticiparnos a todas las salidas y los pasos apropiados del proceso con su necesidad de los datos. Por lo tanto, nosotros podríamos derivar todos los requerimientos de los datos fácilmente, de todo el sistema conocido.

Además, cada aplicación contenía sus propios archivos y capacidad de almacenamiento de datos. Los datos tenían que unir las especificaciones establecidas en cada aplicación y cada aplicación tenía que ser considerada separadamente.

Técnica Orientado a Procesos

La concentración en el flujo, uso y transformación del dato en un sistema de información es denominada técnica orientado a procesos para el desarrollo del sistema.

Las técnicas y notaciones para el desarrollo de este enfoque son la vía del movimiento de datos desde su fuente, a través de los pasos de los procesos inmediatos, hasta su destino final.

Seguidamente varias partes de un sistema de información trabajan en diferentes planificaciones y a diferentes velocidades, el método orientado a procesos también muestra donde los datos son temporalmente almacenados hasta necesitarlos para su proceso. La estructura natural del dato, sin embargo, no esta especificada dentro del método orientado a procesos.

Los gerentes que procesaban los datos, pronto comprendieron que había problemas con el análisis y diseño de sistemas que sólo usaban esta técnica, orientado a procesos. Un resultado fue la existencia de muchos archivos de datos especializados, cada uno en diferentes aplicaciones y programas.

Muchos de los archivos en estas diferentes aplicaciones contenían algunos datos elementales. Cuando un simple dato elemental cambiaba, este tenía que ser cambiado en cada uno de estos archivos. Si, por ejemplo, existiese un sistema en su universidad y su dirección cambió, tendría que ser cambiado en los archivos de la biblioteca, la oficina del registrador, la oficina de ayuda financiero, y cada otro lugar donde su dirección fue guardada.

También se puso difícil combinar los archivos de datos especializados. Aun cuando los archivos contuviesen los mismos datos elementales, cada uno de los archivos usaría un nombre diferente y un formato para los datos.

Puesto que era importante estandarizar la representación de los datos elementos, vino gradualmente el proceso del manejo de datos separando los programas y los datos que estos programas usaban.

(Sistema de Planillas) (Sistema de Manejo de Proyectos) (Datos Proyecto) (Datos Personal) (DatosPersonal) (Datostributos)

Técnica orientado a datos

El enfoque en los datos representaba la técnica orientado a datos en el desarrollo de sistemas de información. El método orientado a datos, muestra la organización ideal de los datos, independiente de dónde y cómo se usan los datos dentro de un sistema.

La técnica usada para la orientación de datos resulta un modelo de dato que describe las clases de datos que se necesita en el sistema y las relaciones entre estos datos dentro de la compañía. Un modelo de dato describe las reglas y políticas de una compañía.

Algunas personas creen que un modelo de datos es más permanente que un modelo de proceso, puesto que, un modelo de datos refleja la naturaleza inherente de un negocio en lugar de que el negocio opera y constantemente está cambiando. Algunas personas se refieren al método orientado a datos como la ingeniería de información.

(Datos Proyecto) (Datostributos) (Sistema de Manejo de Proyectos) (Sistema de Planillas)

(Datos Personal)

La siguiente tabla muestra las diferencias entre el método orientado a procesos y orientado a datos.

Características

Orientado – Procesos

Orientado – Datos

Enfoque de sistemas

Lo que se supone que los sistemas hacen y cuando

Los datos que se necesitan en el sistema para operar

Estabilidad en el diseño

Limitado, cuando los procesos de negocio y las aplicaciones que los apoyan constantemente cambian

Más permanente, cuando las necesidades de una organización no cambien rápidamente

Organización de datos

Los archivos de datos diseñados para cada aplicación individual.

Los archivos de datos diseñados para la empresa

Estado de los datos

Duplicación incontrolable de datos

Duplicación limitada, controlada

1.6.2 SEPARANDO BASE DE DATOS Y APLICACIONES

Como la tecnología del manejo de almacenamiento de datos avanza, se puso posible no representar los datos en los archivos separados para cada aplicación sino en las bases de datos.

Base de datos

Una base de datos es una colección de datos lógicamente relacionados organizada de maneras que facilitan captura, almacenamiento, y recuperación para los usuarios múltiples en una organización.

Una base de datos involucra métodos de organización de datos que permiten manejar los datos de manera centralizada, estandarizada y consistente. En vez de una proliferación separada y distintos archivos de datos, la técnica de base de datos permite bases de datos centrales para ser la fuente de datos para muchas aplicaciones variadas.

Bajo la técnica orientado-datos para el desarrollo de los sistemas, se diseñan las bases de datos alrededor de las entidades, como clientes, proveedores, y partes.

Independencia de las aplicaciones

El diseño de base de datos alrededor de las entidades, lo habilita para usar y revisar la base de datos para muchas aplicaciones diferentes e independientes. Este enfoque produce la independencia de las aplicaciones, la separación de datos y la definición de datos de las aplicaciones.

El punto central de la independencia de las aplicaciones es que los datos y las aplicaciones se separan. La técnica orientado a datos es eficaz, sin embargo, otro cambio en el diseño de sistema necesita: Organizaciones que han manejado datos centralizados deben diseñar las nuevas aplicaciones para trabajar con las bases de datos existentes. Organizaciones que no han manejado almacenes de datos centralizados deben diseñar bases de datos que soporten las aplicaciones actuales y futuras.

1.7 ANÁLISIS Y DISEÑO DE SISTEMAS

Dentro de las organizaciones, el análisis y diseño de sistemas se refiere al proceso de examinar la situación de una empresa con el propósito de mejorarla con métodos y procedimientos más adecuados.

El desarrollo de sistemas puede considerarse, en general, formado por dos grandes componentes:

· El análisis de sistemas

Es el proceso de planificar, reemplaza o complementar un sistema organizacional.

· El diseño de sistemas

Es el proceso de clasificación e interpretación de hechos, diagnósticos de problemas y empleo de información para recomendar mejorar al sistema.

1.7.1 SU ROL Y OTRAS RESPONSABILIDADES EN EL DESARROLLO DE SISTEMAS

En una organización que desarrolla sus propios sistemas de información internamente, hay varios tipos de trabajos involucrados. En medio a las organizaciones grandes, hay usualmente un departamento de Sistemas de Información.

Dependiendo como las organizaciones se establecen, el departamento de SI puede ser una unidad relativamente independiente, mientras informa al gerente de la organización.

Alternativamente el departamento de SI puede ser parte de otro departamento funcional, tal como el departamento de finanzas, o puede haber un departamento de SI incluso en algunos de las unidades de mayor nivel de la compañía.

En cualquiera de estos casos, el gerente del departamento de SI estará involucrado en el desarrollo de sistemas.

Si el departamento es bastante grande, se podría separar en divisiones para el desarrollo de sistemas, el cual sea la casa base para el analista de sistemas y otras divisiones para programación, base de programadores. Las personas para quienes se realizan el análisis y diseño de sistemas son localizados en los departamentos funcionales y son llamado usuarios o usuarios finales.

Sin tener en cuenta como, en la estructura de la organización se encuentra el departamento de SI, el desarrollo de sistemas es un esfuerzo de equipo. Analistas de sistemas trabajan juntos en un equipo, normalmente organizado como una base del proyecto. El número de miembros del equipo puede extenderse para incluir a gerentes de SI, programadores, usuarios, y otros especialistas sean involucrados en el proyecto de desarrollo de sistemas.

Un equipo bueno es diverso y tolerante de diversidad:

· Un equipo diverso tiene la representación de todos los grupos diferentes, interesados en un sistema, y la representación de estos grupos incrementará la probabilidad de aceptación de los cambios que un nuevo sistema causará.

· La diversidad expone a los miembros del equipo a las nuevas y diferentes ideas, ideas en que ellos nunca podrían pensar tener todos los miembros del equipo de algunos aspectos de fondo, con las mismas habilidades y metas.

· Las nuevas y diferentes ideas pueden ayudar a un equipo a generar las buenas soluciones a sus problemas y puedan defender el curso de acción que éste escoge.

· Los miembros del equipo deben poder entretener las nuevas ideas sin ser demasiado crítico, sin despreciar las nuevas ideas simplemente porque ellos son nuevos.

· Los miembros del equipo deben poder tratar con la información ambigua así como con la complejidad y debe aprender a jugar un rol en un equipo (y roles diferentes en los equipos diferentes) para que los talentos de todos los miembros del equipo puedan ser el mejor.

El gerente de SI en el desarrollo de sistemas

El gerente de un departamento de SI puede tener el rol de director en el proceso de desarrollo de software si la organización es pequeña o si ése es el estilo del gerente. Típicamente, los gerentes de SI están más involucrados en la asignación de los recursos y vigilando el proyecto de desarrollo de sistemas que se aprobó, en lugar del desarrollo de procesos actuales.

Así, los gerentes de los SI pueden asistir a alguna reunión de revisión de proyecto y ciertamente esperarán el informe escrito del progreso del proyecto que cubre sus áreas de preocupación. Los gerentes de los SI pueden determinar qué metodologías, técnicas, y herramientas serán usadas y el procedimiento para informar el estado de proyectos. Como los líderes del departamento, los gerentes de los SI también son los responsables por la profesión de los analistas y diseñadores de sistemas y otros empleados y por resolver problemas que se levantan en el curso de proyectos de desarrollo.

El gerente del departamento SI, puede tener el título de Funcionario de Información Principal, puede informar al presidente de la empresa. Cada división del departamento de SI también tendrá un Director. Típicamente estos directores titulan Director de Desarrollo de SI, Director de Operaciones del SI y el de Director de Programación del SI. El Director de desarrollo de SI puede ser responsable en cualquier momento dado, de varios proyectos de desarrollo, cada uno de los cuales tienen un director del proyecto.

Analistas de Sistemas en el Desarrollo de Sistemas

Los analistas de sistemas son los individuos más importantes en el proceso de desarrollo de sistemas. Para tener éxito como un analista de sistemas, usted necesitará desarrollar cuatro habilidades:

· Analítico

Técnico

Directivo

Interpersonal.

Habilidades Analíticas

Las habilidades analíticas le permiten entender la organización y sus funciones, identificar oportunidades y problemas, y analizar y resolver los problemas. Una de las habilidades analíticas más importantes que usted puede desarrollar es pensar en sistemas o la habilidad de ver las organizaciones y sistemas de información como sistemas, el pensar en sistemas proporciona una estructura por la que ve las relaciones importantes entre los sistemas de información, las organizaciones en que ellos existen, y el entorno de organizaciones en que ellos mismos terminan.

Habilidades técnicas

Muchos aspectos de su trabajo como un analista de sistemas están orientados técnicamente. Para desarrollar sistemas de información basado en computadora, debemos entender como las computadoras, los datos conectados en red de computadoras, la administración de base de datos y sistemas operativos y un host de otras tecnologías, trabajan así como su potencial y limitaciones. Además, usted debe adaptarse con las diferentes notaciones para representar o modelar varios aspectos de los sistemas de información. Usted necesita estas habilidades técnicas no solamente para realizar tareas asignadas a usted sino también comunicarse con los otros miembros con los cuales trabaja el desarrollo del sistema.

Las actividades siguientes le ayudarán a ser quedarse versátil y moderno:

Leer publicaciones comerciales

Unirse con sociedades profesionales u otros clubes y sus reuniones (meeting)

Asista a las clases o enseña en una universidad local. Enseñar es una manera maravillosa de obligarse a quedarse actual y aprender de otros.

Asista a cursos o sesiones de instrucción ofrecidas por una organización.

Asista a conferencias profesionales, seminarios o demostraciones comerciales.

Participe en los tableros de anuncios electrónicos de nuevos grupos o conferencias locales, nacionales o internacionales.

Usted como analista de sistemas debe estar familiarizado con las siguientes tecnologías:

Microcomputadoras, workstations, mini computadoras y computadoras mainframe

Lenguajes de programación

Sistemas Operativos, para máquinas simples y redes.

Base de Datos y manejos de sistemas de archivos

Comunicación de datos estándar y software para redes locales y extendidas.

Herramientas de desarrollo de sistemas y entornos (tales como formas y generadores de reportes y herramientas de diseño de interfase de gráfico)

Así como métodos modernos y técnicas para describir y construir sistemas. A menudo, le pedirán que sea más técnico en las primeras fases de su carrera y entonces usted asumirá las responsabilidades de directivas más tarde cuando gane experiencia.

Habilidades Directivas

Los analistas de los sistemas casi siempre son miembros de equipos de proyectos y frecuentemente solicitan conducir los equipos. Las habilidades directivas son muy útiles para cualquiera persona en el rol de dirección. Como un analista, usted necesita también saber manejar su propio trabajo y cómo usar los recursos organizacionales de la manera más productiva posible.

La autogestión, entonces, es una habilidad importante por un analista. Existen cuatro categorías de habilidades directivas: recursos, proyectos, riegos y cambios de dirección.

Manejo de Recursos

Cualquier empleado de la organización debe saber como obtener y trabajar eficazmente con los recursos organizacionales. Un analista de los sistemas debe saber conseguir una amplia gama de recursos: las documentaciones de los sistemas, tecnología de información y dinero. Para un analista el recurso más importante es la gente, guiar un equipo. Un líder de equipo debe aprender cómo mejor y utilizar los talentos particulares de otros miembros del equipo. Ella o él debe ser capaces de delegar responsabilidades, autorizando a las personas para realizar tareas que son asignadas.

El manejo de recursos incluye las siguientes habilidades:

· Prediciendo el uso de los recursos (presupuesto).

· Buscar y considerar el consumo del recurso.

· Aprender como usar los recursos eficazmente.

· Evaluar la calidad de los recursos usados.

· Obtener los recursos de uso excesivo.

· Dejar los recursos cuando ya no se necesitan y cuando son obsoletos y no son útiles.

Manejo de Proyectos

Efectivamente el manejo de proyectos es crucial para el trabajo de un analista de sistemas. La meta del manejo de proyectos es impedir a los proyectos que entren en retraso y estén por encima del presupuesto. Además, la dirección de los proyectos está diseñada para ayudar a los gerentes a guardar y rastrear el progreso de los proyectos. Aun cuando usted no es un líder del proyecto, usted se dará responsabilidades para las partes de un proyecto. En el rol director de proyectos o de sub proyectos, usted necesita descomponer primero un proyecto en varias tareas independientes. El siguiente paso es determinar quien realizará las tareas y quien será responsable de las tareas.

A menudo, en el ambiente de desarrollo de hoy, muchos aspectos de un proyecto pueden cultivarse varios contratistas fuera de la organización. Usando a los contratistas independientes se tiene muchas ventajas:

· Un contratista particular puede ser más experimentado que el personal interior en una tecnología o menos caros.

· Si un proyecto es para un corto tiempo, tiene sentido contar con contratistas para desarrollar algunas partes del proyecto y así ayudar a la velocidad del proceso global.

Pero también existen desventajas con los contratistas:

· Los contratistas entregan trabajo retrasados o de baja calidad, o no está de acuerdo a los requerimientos.

· Si los requerimientos de los sistemas no están bien definidos, pueden potenciarse los problemas con los contratistas.

Por estas razones, es tan importante dirigir a los contratistas como dirigir a todos los demás que están involucrados en el proyecto.

Dos mecanismos que ayudan a manejar a contratistas son los contratos y la relación entre los directores.

1. Los contratos que son muy bien especificados y cuando se comprenden exactamente, se esperan que se muestren explícitamente las sanciones por la no-ejecución, pueden motivar a los contratistas a realizar las expectativas del proyecto. Por otro lado, este tipo de contratos, puede causar miedo de los contratistas que no pueden mantener las condiciones de semejante contrato.

2. Los directores de las relaciones actúan como los enlaces entre su empresa y los contratistas. Estableciendo las relaciones personales con las partes involucradas, los directores deben darse cuenta de los problemas antes de que las partes involucradas trabajen y se les proporcione el pago correspondiente.

Manejo de Riesgos

El manejo de riesgo es la habilidad de anticiparse a lo que podría ser un proyecto errado. Una vez que se han identificado riesgos en el proyecto, debe poder minimizar la probabilidad de aquellos riesgos realmente ocurrirán. Si minimizar el riesgo no es posible, entonces intenta minimizar el daño que podría resultar. También el manejo de riesgos incluye saber dónde poner los recursos (como las personas) donde ellos pueden realizar mejor el trabajo y priorizar las actividades para lograr la más grande ganancia.

Manejo de Cambios

Introducir un nuevo sistema de información o mejorarlo en una organización, es el proceso de cambio. A las personas no les gusta en general, el cambio y tienden a resistirse; por consiguiente, cualquier cambio en el trabajo que realizan las personas en una organización, debe manejarse cuidadosamente. El manejo de cambios, entonces, es una habilidad muy importante del analista de los sistemas que, son los agentes de cambio de la organización. Debe saber conseguir que las personas hagan una transición uniforme de un sistema de información a otro, mientras van dejando los antiguos métodos de hacer las cosas y aceptar los nuevos métodos. También manejo de cambios incluye la habilidad de tratar con los problemas técnicos relacionados al cambio, como la obsolescencia y reutilidad.

Habilidades Interpersonales

Aunque, como un analista de sistema, usted llega a trabar en el área técnica de diseño y construcción de los sistemas de información basado en computadora, usted también trabajará extensivamente con todo de tipos de las personas. Quizás las habilidades más importantes que usted necesitará dominar son interpersonales. Las habilidades interpersonales necesarias para el trabajo de un analista sistemas son:

· Habilidades de comunicación

Las habilidades interpersonales más importantes para un analista, así como para cualquier profesional, es la habilidad de comunicarse claramente y eficazmente con otros. Los analistas deben poder comunicar con éxito con los usuarios, otros profesionales de los sistemas de información y dirección. Los analistas deben establecer una relación activa, abierta con los clientes manteniéndolo comunicado eficazmente durante el proyecto.

La comunicación toma muchas formas, desde escritos (los memorando, reportes) verbal (las llamadas telefónicas, las conversaciones cara a cara) visual (la presentación resbala, diagramas). El analista debe poder dominar tantas formas de comunicación como sea posible.

Las habilidades de comunicación oral y de escuchar, son consideradas por muchos profesionales de sistema de información las más importantes y necesarias por los analistas de sistemas para tener éxito.

Las habilidades de entrevistas no están distantes. Todos los tipos de comunicación, sin embargo, tienen una cosa en común: Ellos mejoran con la experiencia. Cuanto más practica, mejores resultados consiguen. Algunos de los tipos de comunicación que mencionan son:

· Entrevistar y escuchar

· Encuestas

· Presentaciones escritas y orales

· Trabajo exclusivo y con un equipo

Como un analista de los sistemas, usted debe trabajar a menudo y exclusivamente en ciertos aspectos de cualquier proyecto de desarrollo de sistemas. Con este fin, usted debe poder organizar y manejar su propio horario, compromisos y fechas límites. Muchas personas en la organización dependerán de su desempeño individual, todavía usted es un miembro de un equipo y debe trabajar con el equipo para lograr las metas del proyecto. Usted necesita saber cuándo confiar en la opinión de otros miembros del equipo, así como cuándo cuestionarlo.

Por ejemplo, cuando los miembros del equipo están hablando o están actuando de su experiencia y especialización, usted probablemente confía mas en su juicio que cuando ellos están hablando sobre algo más allá de su conocimiento.

Por esta razón, el analista que lleva el equipo debe entender las fuerzas y debilidades de los otros miembros del equipo. Para trabajar juntos eficazmente y asegurar la calidad del producto de grupo, el equipo debe establecer normas de cooperación y coordinación que la guía su trabajo.

Características de una actuación alta del equipo

1. Visión común, elevada o meta

2. Sentido de identidad del equipo

3. Estructura de los resultados manejados

4. Miembros competentes del equipo

5. El compromiso del equipo

6. La confianza mutua

7. Interdependencia entre los miembros del equipo

8. Comunicación efectiva

9. Sentido de autonomía

10. Sentido de fortalecimiento

11. Tamaño del equipo pequeño

12. Nivel alto de satisfacción

La primera característica es una visión compartida que le permite a cada miembro del equipo tener una comprensión clara de los objetivos del proyecto. Una visión compartida ayuda a los miembros del equipo a mantener sus prioridades correctas y no permiten elementos pequeños de poca importancia y que distraigan.

La segunda característica, la identidad del equipo, se refiere como los miembros del equipo trabajan juntos estrechamente y empiezan a compartir un idioma común y sentido de humor. La identidad del equipo sólo puede llevar a la sinergia de esfuerzos posibles cuando los grupos trabajan juntos y bien.

La tercera característica de los equipos de alto desempeño, es cómo los equipos son organizados. Una estructura de manejo de resultados, es uno que depende de los roles claros, el sistema de comunicación eficaz, los medios de supervisión la actuación individual y la decisión, basados en los hechos en lugar de las emociones.

La cuarta característica es la elección de las personas correctas para el equipo. Mc Connell, reporta que el desempeño del equipo puede diferir entre un factor de 5, dependiendo solamente de las habilidades y actitudes de los miembros del equipo.

Aunque las habilidades de cada miembro del equipo son importantes y determinantes para el desempeño del equipo, todos los miembros deben comprometerse con el equipo, la quinta característica el desempeño del equipo. Un grupo de individuos comprometido sólo con sus propios intereses, no ayuda a un verdadero equipo de talentos que son comprometidos auténticamente con los otros y con su esfuerzo.

Las siguientes cinco características de desempeño del equipo, son que todos los miembros del equipo actúan recíprocamente entre sí. Es muy importante que un miembro del equipo desarrolle la confianza genuina con los otros miembros.

· Facilitador de grupos

A veces usted necesita actuar recíprocamente con el grupo para comunicar y recibir la información. El diseño de aplicación de juntura (JAD) es el proceso en el cual el analista trabaja activamente con el grupo durante el desarrollo del sistema. Los analistas usan las sesiones de JAD para recoger los requisitos del sistema y dirigir las revisiones del diseño.

Las reuniones del grupo son el recurso más importante por el cual analista tiene el acceso durante un JAD y debe conseguir lo mayor parte de ese recurso; la preparación de grupos es una manera exitosa de hacer eso. En un JAD típico, hay un líder especializado de la sesión que ejecuta la muestra. Él o ella se han entrenado para facilitar los grupos, ayudarles a trabajar juntos, especialmente y para ayudarles a lograr sus metas comunes. La preparación de grupos necesariamente involucra una cierta cantidad de neutralidad por parte del facilitador.

El facilitador debe guiar el grupo sin ser parte del grupo y debe trabajar para guardar el esfuerzo en el recorrido, buscando las discrepancias y ayudando a resolver las diferencias en el grupo. Obviamente, el facilitador del grupo requiere el entrenamiento.

· El manejo de expectativas de usuarios y directores

El desarrollo de los sistemas es un proceso de cambio y cualquier cambio organizacional se recibe con la anticipación e incertidumbre por los miembros de la organización. Los miembros de la organización tendrán ciertas ideas, quizás basadas en sus esperanzas y deseos, sobre lo que un nuevo sistema de información podrá hacer para ellos; estas expectativas sobre el nuevo sistema pueden estar fácilmente fuera del control.

Ginzberg encontró con éxito, que las expectativas de los usuarios se relacionan con el manejo de la aplicación de los sistemas exitosamente. Para manejar las expectativas con éxito, usted necesita comprender la tecnología y lo que puede hacer. Usted debe entender que flujos de trabajo la tecnología apoyará y cómo el nuevo sistema los afectará. Más importante que entender, sin embargo, es su habilidad de comunicar un cuadro realista del nuevo sistema y qué que hará para los usuarios y directores. Las expectativas de los directores empiezan con el desarrollo del sistema para el negocio y extender todas las formas a través de la cual las personas usan el sistema acabado. Usted necesita instruir a aquellos que tienen pocas expectativas así como el optimismo de aquellos que esperan el nuevo sistema para realizar los milagros.

Programadores en el desarrollo de Sistemas

Los programadores acuerdan las especificaciones del sistema dadas a ellos por analistas en las instrucciones que la computadora pueda comprender. Escribir un programa en la computadora es llamado codificación.

Programadores también escriben documentación del programa y programas para probar los sistemas. Durante muchos años, programar fue considerado un arte. Sin embargo, un científico de la computadora descubrió que ese código podría mejorarse si fuera estructurado (Bohm y Jacopini, 1966) En la programación estructurada, todas las instrucciones de la informática pueden representarse a través del uso de tres estructuras simples: secuencial, repetitivas y selección. Para ser un programador experimentado toma años de entrenamiento y experimentación. Muchos estudiantes de sistemas de información por computadora empiezan el trabajo como programadores o programador/ analista.

Programar es una labor muy intensiva, por lo tanto, el propósito de las herramientas de computación llamados generadores de código tienen que ser desarrollados para generar códigos bastantes buenos.

Los generadores de código cambian la naturaleza de programar. Los programadores toman el código generado y arreglan los problemas con él, perfeccionándolos e integrándolos con otras partes del sistema. La meta de algunas herramientas de ingeniería de software, diseño asistido por computadora (CASE), proporcionar una variedad de código generado que pueden producir automáticamente el 90 por ciento o más o codifica directamente la especificación del sistema dada a un programador. Cuando esta meta se logra, el papel de los programadores en los equipos de desarrollo de sistemas, se cambiará en el futuro.

Usuarios finales en el desarrollo de sistemas

En el proceso de desarrollo de sistemas tradicional típico, los analistas de sistemas entrevistan, inspeccionan y observan a los usuarios finales para determinar lo que ellos necesitan de un sistema de información. Los usuarios finales son profesionales comerciales, que expertos en su campo, pero quienes normalmente no tienen la habilidad, el tiempo, el deseo o responsabilidad que exige el desarrollar los sistemas de información.

Por consiguiente, como un analista, usted trabajará con los usuarios para convertir sus conocimientos del negocio a favor de los sistemas de información. Los usuarios finales son a menudo sus clientes, las personas para quienes usted está construyendo un sistema. En muchos casos, los usuarios finales servirán también en el equipo de desarrollo de sistemas, mientras proporcionen su experiencia de manera muy activa.

Usted y otros profesionales de los SI también mantendrán apoyo y ayuda de aquellos usuarios finales más sofisticados que escriben, prueban y llevan a cabo su propia información o sistemas de distribución de datos.

Usuarios finales de en el desarrollo sistemas de soporte

Como el número de requerimientos aumentó para un nuevo sistema de información o mejorarlo, el departamento de SI deberá signar prioridades para desarrollar proyectos. Las prioridades significan que algunos usuarios conseguirán sus sistemas enseguida mientras otros deben esperar.

En los años setenta, con el desarrollo de sistemas de tiempo compartido que permitieron a varias personas que usaran una misma computadora al mismo tiempo, se hizo posible técnicamente para los usuarios finales desarrollar sus propios sistemas. Como los usuarios finales se hicieron hábiles en el manejo de esta tecnología a través de las instrucciones y experiencia, muchos usuario se impacientaron para desarrollar sus propias aplicaciones para los requerimientos de sus proyectos.

Por consiguiente, el rol significativo para analistas de sistemas y otros profesionales de SI es ayudar a los usuarios finales a desarrollar sus propios sistemas que soportan a menudo los sistemas o los sistemas distribuidos diseñados para reforzar sistemas existentes desarrollados por los profesionales de SI.

EL desarrollo de soporte delos usuarios finales tienen varias dimensiones:

Primero. Los profesionales de los SI deben evaluar y hacer herramientas convenientes y disponibles para los usuarios finales.

Segundo. Los profesionales de los SI deben entrenar a los usuarios finales en el uso de estas herramientas y su aplicación apropiada.

Tercero. Los profesionales de los SI deben estar disponibles para ayudar a los usuarios finales y contestar las preguntas o realizar el trabajo de desarrollo de sistemas complicado siempre que los usuarios finales tengan las dificultades.

Cuarto. Los profesionales de los SI deben continuar manteniendo la capture de los datos y transferir aplicaciones que manejan las bases de datos de los cuales los usuarios finales extraen los datos necesarios para los sistemas que ellos desarrollan.

Gerente de la empresa en el desarrollo de sistemas

Otro de grupo importante para de desarrollo de sistema son los gerentes de la empresa, como las cabezas de las secciones funcionales y los ejecutivos corporativos. Los gerentes son importantes para el desarrollo de los sistemas porque ellos tienen el poder para consolidar el desarrollo del proyecto y para asignar los recursos necesarios para el éxito del proyecto.

Debido a la decisión que hacen las autoridades y conocimiento de las líneas de la empresa, los líderes de los departamentos y los ejecutivos son capaces de dirigir también los requerimientos generales y las necesidades para desarrollar los proyectos.

En compañías más grandes dónde la importancia de proyectos de sistemas es relativa es determinada por un comité de dirección, estos ejecutivos tienen poder adicional, puesto que ellos normalmente son miembros de los comités de dirección o sistemas que planean los grupos.

Por consiguiente, los gerentes de la empresa tienen el poder para fijar la dirección para el desarrollo de los sistemas, proponer y aprobar los proyectos, para determinar la importancia relativa de los proyectos que ya han sido aceptados y han sido asignados a otros en la organización.

Otros gerentes técnicos de los SI en el desarrollo de los sistemas

En organizaciones más grandes dónde los roles se mas diferencian en los SI, puede haber varios profesionales de SI adicionales involucrados en el de desarrollo de sistemas.

Una empresa con un conjunto existente de base de datos tendrá probablemente un administrador de base de datos que está normalmente involucrado con cualquier proyecto del sistema que usa la base de datos de la empresa.

Expertos en redes y telecomunicaciones que ayudan al desarrollo de sistemas involucrando datos y/o comunicación de voz, ya sea interna o externa de la organización.

Algunas organizaciones tienen departamentos con un factor humano los cuales están interesados por las interfaces del sistema y facilitan el manejo de problemas, mientras instruyen a los usuarios, y escriben documentación del usuario y manuales. Vigilando el desarrollo del proyecto, sobre todo en los sistemas grandes o sensibles, los auditores internos, son interventores de una organización que aseguran que esos requerimientos se implementen en el sistema.

En muchas organizaciones, los auditores tienen también la responsabilidad de guardar las huellas de cambio en el diseño de sistemas.

ANALISTA DE SISTEMAS

Centro de Distribución

Nosotros estamos llevando al mundo la fabricación de nuestros productos de ropa de mujeres. Nuestra organización en el Lejano Este tiene una apertura para los analistas de sistemas.

· Grado de Bachelor en informática y/o administración de empresas con 5 años o mas de experiencia

· Comprender a fondo los conceptos industriales y distribución (Localización, el control de embarques, planificación de producción)

· Conocimiento del trabajo de dirección de proyectos y fases del ciclo de vida del desarrollo de sistemas

· Experiencia en herramientas CASE y PC es esencial

· Conocer el trabajo de AS/400 y/o el entorno de UNIX con el lenguaje C, RPG400 y/o Visual Basic.

El candidato escogido mantendrá la interfase primero con los usuarios del problema, responder técnicamente a las preguntas y requerimientos dentro del grupo de desarrollo de aplicaciones; trabajar con el usuario estableciendo prioridades; y dar recomendaciones y direcciones para mejorar el proceso a través de la automatización; las habilidades en un idioma asiático son una ventaja.....

1.8 DESARROLLO DE SISTEMAS DE INFORMACIÓN Y EL CICLO DE VIDA EN EL DESARROLLO

La mayoría de las organizaciones buscan un conjunto de pasos estándar llamado metodología de desarrollo de sistemas, para desarrollar y dar soporte a los sistemas de información. Como muchos procesos, el desarrollo de sistemas de información lleva a cabo un ciclo de vida.

Por ejemplo, un producto comercial sigue un ciclo de vida por el cual es creado, verificado e introducido al mercado. Aumenta las ventas al máximo y declinan. Finalmente el producto es sacado del mercado y reemplazado por algún otro.

Definición de un Modelo de Ciclo de Vida

Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.

Un modelo de ciclo de vida del software:

Describe las fases principales de desarrollo de software.

Define las fases primarias esperadas de ser ejecutadas durante esas fases.

Ayuda a administrar el progreso del desarrollo, y

Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.

Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.

ELEMENTOS DEL CICLO DE VIDA

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Según el modelo de ciclo de vida, la sucesión de fases puede ampliarse con bucles de realimentación, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar más de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecución aportaciones de los resultados intermedios que se van produciendo (realimentación).

A continuación presentamos los distintos elementos que integran un ciclo de vida:

· Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupación temporal de tareas impone requisitos temporales correspondientes a la asignación de recursos (humanos, financieros o materiales).  Cuanto más grande y complejo sea un proyecto, mayor detalle se necesitará en la definición de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un “micro-proyecto” en sí mismo, compuesto por un conjunto de micro-fases. 

Otro motivo para descomponer una fase en subfases menores puede ser el interés de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestión.

Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase.

(A la fase posterior) (Procedente de laFase anterior)

(Tareas propias de la Fase)

(Documentosy productosde entrada)

(Documentosy productosde salida)

(Validación del trabajo)

(Replanificación y/o realimentación)

(Experienciaacumulada)

Esquema general de operación de una fase

· Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuación o no a los requisitos funcionales y de condiciones de realización previamente establecidos. Cada una de estas evaluaciones puede servir, además, para la toma de decisiones a lo largo del desarrollo del proyecto.

ALTERNATIVAS DE MODELOS DE CICLO DE VIDA

CICLO DE VIDA DEL DESARROLLO DE SISTEMAS (SDLC) (TRADICIONAL)

El ciclo de vida del desarrollo de sistemas (SDLC) es una metodología común para desarrollar sistemas en muchas organizaciones, ofreciendo muchas fases que marcan el progreso del análisis y diseño del sistema. Cada autor de textos de libros y desarrollo de sistemas de información en las organizaciones usan, ligeramente, diferentes modelos de ciclo de vida.

(Identificación del Proyecto y Selección)

(Iniciación del Proyecto y Planificación)

(Análisis)

(Diseño Lógico)

(Diseño Físico)

(Implementación)

(Mantenimiento)

Aunque en cualquier ciclo de vida a primera vista parece un conjunto de fases secuencialmente ordenado, esto actualmente no es así. Los pasos específicos y su secuencia son explicativos para ser adaptados en un proyecto que requiere de éstos.

Por ejemplo, en cualquier fase dada del SDLC, el proyecto puede retornar a una fase anterior fácilmente si es necesario. Semejantemente, si un producto comercial no está bien elaborado, sólo después de su introducción, puede quitarse temporalmente del mercado y mejorarlo antes que se empieza a re-introducido.

En el ciclo de vida del desarrollo de sistemas es también posible complementar algunas actividades en una de las fases en paralelo con algunas de las actividades de otra fase. A veces el ciclo de vida es iterativo; que es, las fases son repetidas como requeridas hasta que un sistema aceptable es logrado.

MODELO ESPIRAL

El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:

1. Determinar qué quieres lograr.

2. Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.

3. Seguir la alternativa seleccionada en el paso 2.

4. Establecer qué tienes terminado.

La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto. Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.

Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.

El modelo espiral captura algunos principios básicos:

Decidir qué problema se quiere resolver antes de viajar a resolverlo.

Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.

Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.

No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y

Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.

El modelo espiral no es una alternativa al SDLC, ellos son completamente compatibles. 

MODELO ESTRUCTURADO

Ed Yourdon y sus colegas desarrollaron el análisis y diseño estructurado en los años 70 como un método para dirigir algunos de los problemas con el ciclo de vida del desarrollo de sistemas tradicional. Para hacer más disciplinado el análisis y diseño estructurado, Yourdon y sus colegas enfatizaron y mejoraron las fases del análisis y diseño de sistemas.

La meta era reducir el esfuerzo y el mantenimiento. El análisis y el diseño estructurado hace más fácil regresar a las fases anteriores del ciclo de vida cuando sea necesario, por ejemplo, cuando cambian los requerimientos.

Finalmente, existe también un énfasis sobre la partición o división de un problema en problemas más pequeños, unidades más manejables y hacer una clara distinción contre el diseño lógico y físico.

Las actividades involucradas en este modelo son:

La encuesta: También se conoce como el estudio de factibilidad o como el estudio inicial de negocios. Por lo común, empieza cuando el usuario solicita que una o más partes de su sistema se automaticen.

El análisis del sistema: El propósito principal de la actividad del análisis es transformar sus dos entradas – o insumos o factores – principales, las políticas del usuario y el esquema del proyecto, en una especificación estructurada. Esto implica modelar el ambiente del usuario con diagramas de flujo de datos, diagramas de entidad relación, diagramas de transición de estado y demás herramientas.

El modelo esencial del sistema es un modelo de lo que el sistema debe hacer para satisfacer los requerimientos del usuario, diciendo lo mínimo posible (de preferencia nada) acerca de cómo se implantará. Lo que significa que nuestro modelo del sistema supone que se tiene disponible una tecnología perfecta y que se puede obtener fácilmente y sin costo.

Específicamente, esto significa que cuando el analista habla con el usuario acerca del los requerimientos específicos de procesos (burbujas en un diagrama de flujo de datos) en el sistema; es decir no debe mostrar las funciones del sistema que están realzadas por humanos o por sistemas de cómputo existente.

El diseño: Se dedica a asignar proporciones de la especificación (también conocida como modelo esencial) a procesadores adecuados (sean máquinas o humanos) y las labores apropiadas (o tareas, particiones, etc) dentro de cada procesador. Dentro de cada labor, la actividad se dedica a la creación de una jerarquía de módulos de programas y de interfases entre ellos para implementar la especificación creada en la actividad del análisis.

Implantación: Incluye la codificación y la integración de módulos en n esqueleto progresivamente más completo del sistema final. Por eso, esta actividad incluye tanto programación estructurada como implantación descendente.

Como se podrá imaginar, el análisis típicamente no se verá involucrado en esta actividad, aunque hay algunos proyectos (y organizaciones) donde el análisis, el diseño y la implantación de sistemas lo hace la misma persona.

Generación de pruebas de aceptación: Es probable que el proceso de probar el sistema tome como la mitad de l tiempo programado para su desarrollo de qué tan cuidadosamente se hayan hecho las actividades iniciales de análisis, diseño y programación.

Las dos formas más comunes de realizar una prueba es:

El enfoque ascendente: empieza por probar módulos individuales pequeños separadamente.

El enfoque descendente, empieza con un esqueleto del sistema, es decir, la estrategia de prueba supone que se han desarrollado los módulos ejecutivos de alto nivel del sistema, pero que los de bajo nivel existen sólo como módulos ejecutivos de al ato nivel del sistema, pero que los de bajo nivel existen sólo como módulos vacíos. Dado que muchas de las funciones detalladas del sistema no se han implantado, las pruebas iniciales están muy limitadas; el propósito es simplemente comenzar a ejercitar las interfases entre los subsistemas principales. Las pruebas siguientes abarcan y tratan aspectos cada vez más detalladas de los sistemas.

Garantía de calidad: O la prueba final o la prueba de aceptación. Requiere como entradas los datos de la prueba de aceptación generada en la actividad de generación de pruebas y el sistema. El resultado de esta actividad de implementación.

Descripción del procedimiento: Una de las actividades importantes a realizar es la generación de una descripción de cómo interactúan lo usuarios con la parte automatizadas del nuevo sistema. El resultado de esta actividad es un manual del usuario.

Conversión de base de datos: en algunos proyectos, la conversión de bases de datos involucra más trabajo que el desarrollo de programas de computadora para el nuevo sistema. En el caso genera, esta actividad requiere como entrada la base de datos actual del usuario, al igual que la especificación del diseño producida por medio de la actividad de diseño.

Instalación: Sus entradas son manual del usuario producido en la actividad descripción del procedimiento, la base de datos convertida que se creó con la actividad conversión de base de datos y el sistema aceptado producido por la actividad garantía calidad. La instalación puede ser un proceso gradual tras otros usuarios van recibiendo manuales y entrenamiento y comenzando a usar el nuevo sistema.

Los elementos del diseño estructurado son: El diagrama de flujo de datos, el diagrama de entidad – relación, el diagrama de transición de estados, el diagrama estructurado.

MODELO POR PROTOTIPOS

El modelo de cascada anterior se sugiere para casos en que el cliente es maduro, siendo capaz de especificar correcta y completamente la aplicación deseada en un periodo de tiempo definido. No obstante, en la gran mayoría de los casos, lo anterior no es posible. Por ello, el equipo desarrollador debe evaluar el grado de madures del cliente, y proponer un modelo de desarrollo.

Si el cliente no tiene la madurez requerida, es necesario proponer otro modelo de desarrollo. Una alternativa es el modelo por prototipos, en que se hace madurar al cliente rápidamente en la primera fase de análisis. Esta fase incluye análisis, diseño y construcción de prototipos del sistema. Una vez que se logra lo anterior, se sigue el ciclo de igual forma que en el modelo de cascada.

(Análisis, diseño, producciónDiseñoProducciónTransformaciónOperaciónyMantenimiento)

Nótese que en la figura, la primera fase con el hito de aprobación por parte del cliente, de la especificación realizada por prototipos. Los prototipos no constituyen arte del producto mismo, por lo que generalmente no son utilizados en producto final.

De acuerdo con Pressman (1995), los problemas identificados en el modelo de desarrollo orientado a prototipos consisten, por una parte, en que “se ve lo que parece ser” (p.e. lo que examina es una representación del sistema con funcionalidades restringidas), por tanto, no se considera la calidad del software, ni sus aspectos de mantenimiento. Por otra parte, el equipo de desarrollo hace concesiones de programación impropios, sin importar la inadecuación posterior del producto.

ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

Desde comienzo de la década de los 80, el paradigma “orientado a objetos” ha ido madurando como un enfoque de desarrollo de software alternativo a la programación estructurada o modular. Se empezó a crear diseños de aplicaciones de todo tipo usando una forma de pensar orientado a objetos, y a implementar estos diseños utilizando lenguajes orientado a objetos. Sin embargo, el análisis de requisitos se quedó atrás. No se desarrollaron técnicas de análisis específicamente orientado a objetos.

Esta situación ha ido cambiando poco a poco, a medida que se desarrollaban técnicas de análisis específicas para desarrollar software orientado a objetos, e incluso como complemento de otros métodos de análisis, por ejemplo, OMT ( Técnicas de Modelado de Objetos).

El análisis y diseño orientado a objetos tienen dos aspectos:

· Estructura de los objetos

Análisis de la estructura de objetos

· Tipos de objetos

· Asociaciones de un objeto

· Generalización

· Composición

Diseño de la estructura de objetos

· Identificación de clases

· Herencia

· Estructura de datos

· Comportamiento de los objetos

Análisis del comportamiento de objetos

· Tipos de eventos

· Estados

· Reglas de activación

· Condiciones de control

· Funciones

Diseño del comportamiento de objetos

· Identificación de la operación

· Diseño del método

En las metodologías tradicionales para la generación, de sistemas, los modelos conceptuales utilizados para el análisis difieren de los que se emplean pare el diseño. La programación tiene también un tercer punto de vista del mundo. Los analistas los modelos de la relación entre entes, la descomposición funcional y la s matrices. Los diseñadores utilizan diagramas de flujo de datos, tablas de estructura y diagramas de acción. Los programadores utilizan las construcción C++ o ADA, etc.

En las técnicas OO, todos utilizan el mismo modelo conceptual: analistas, diseñadores, programadores y de modo particularmente importante, los usuarios finales. Todos piensen en los tipos de objetos, los objetos y su comportamiento. Establece jerarquías de tipos de objetos, los objetos o de clases donde los subtipos comparten las propiedades de su padre. Piensen en términos de objetos compuestos de otros y utilizan la generalización y el encapsulado. Piensan en eventos que cambian los estados de los objetos y activan ciertas funciones u operaciones.

La transición del análisis al diseño es tan natural, que a veces es difícil especificar el punto final del análisis y el punto inicial del diseño.

EJERCICIOS PROPUESTOS

1.

a. Explique por que la U.S.B. es un sistema. Explique por que es un subsistema

b. ¿Cuál es el mecanismo de control de la U.S.B.

c. Elabore un esquema jerárquico que refleje los subsistemas y las partes elementales de la U.S.B.

2.

a. “Un S.I. se compone de hardware y software. ¿Por qué no es exacta esta afirmación?

b. Observe que se emplea la palabra “apoyo” cuando se habla de sistemas de apoyo para la toma de decisiones. ¿Por qué no se les llama a estas aplicaciones sistemas de toma de decisiones?

3. Explique cual la diferencia entre a técnica orientada a procesos y la técnica orientada a datos.

4. “United ofrece más de 2300 vuelos diarios a 136 destinos en 28 países. La decisión de cuándo programar vuelos, desde cuál origen hasta cuál destino se basa en muchos factores, incluyendo la demanda de diferentes rutas de vuelo en horarios diferentes y la disponibilidad de otros medios de transporte. Es seguro que las decisiones de rutas no pueden hacerse a partir de la experiencia o corazonadas. Los datos deben apoyarlos. Para una aerolínea grande esto significa considerar una gran cantidad de datos. Un administrador lo afirmó así: para hacer dinero la empresa debe valor a los lugares correctos con la frecuencia correcta en los horarios correctos.

Para desarrollar el proyecto de calendarización automática el administrador del programa de United dirigió un equipo que identificó, seleccionó y estableció una solución para satisfacer la meta de la aerolínea: poder analizar factibilidad de vuelos. En otras palabras, los economistas y los administradores necesitan tener la capacidad de determinar si se agrega una ruta, se cancela otra o que plan usar en una ruta en particular.

El quipo del proyecto consideró veinte paquetes de software de apoyo para la toma de decisiones y de análisis, incluyendo algunos usados en las otras divisiones de la compañía. Seleccionó una herramienta de Broadbase. Los archivos que necesitaban incorporar a la nueva herramienta residían en archivos planos; es decir, no relacionados entre sí en una macrocomputadora. La instalación rápida del sistema fue muy importante. Una ventaja de la herramienta de Broadbase era que permitía que se integraran archivos planos con los componentes de análisis de software. Otro factor importante en la selección fue que esa herramienta podría usarse con cualquier sistema importante de administración de base de datos.

El principal reto en el proceso de selección no fue de tipo técnico sino lograr que los usuarios finales del sistema participaran. La falta de comunicación entre el departamento de S.I. y los usuarios era algo serio. El administrador del proyecto observó que no era fácil recibir entrada de los usuarios sobre funciones que querían en la interfaz del sistema, como iconos y menús.

El nuevo sistema se diseñó para que quienes hacían los calendarios pudieran considerar escenarios prospectivos del tipo “¿Qué pasaría si…?” para decidir si un nuevo vuelo a Chicago sería más redituable con un avión más pequeño o mas grande. Muchos factores entraban en los cálculos incluyendo datos históricos de vuelo con información sobre demanda de pasajeros, consumo de combustible, costos de mantenimiento, restricciones de aeropuertos y disponibilidad de tripulaciones. Quienes elaboraron los calendarios cambiaban un vuelo cerca de una vez por mes. Les tomaba aproximadamente un mes descubrir el mejor calendario para un nuevo vuelo. El nuevo sistema proporciona a United una de sus herramientas de administración mas útil”

Responda:

a) Identifique a que problemas está orientado el proyecto para United

b) ¿Qué necesidades serán alcanzadas con el proyecto?

c) Desarrolle un plan de comunicación entre el departamento de S.I. y los usuarios en United

d) ¿Qué herramienta determina utilizar el equipo? ¿Cuál su característica?

e) De acuerdo con lo visto en este caso el principal reto en el proceso de selección no era el origen técnico sino hacer que lo usuarios finales participen con el sistema. ¿Por qué esto es un reto en cualquier organización donde se considera un nuevo sistema de información?

REFERENCIAS BIBLIOGRAFICAS

(1) Jeffrey A. Hoffer – Joel F. George – Joseph S. Valacich, MODERN SYSTEMS ANÁLISIS & DESIGN, United Status of American, De. Addison Wesley Longman, 1999.

Organización del Departamento de SI

Administrador de

Base de Datos

Director

Analisis SI

Director

Programación

Director

Desarrollo de Sistemas

Director

Operaciones

Director

Comunicaciones de Voz

Director

Comunicación de Datos

Director

Telecomunicaciones

Departamento de SI

Gerente