EL ROL DEL ANALISTA DE SISTEMAS

Lectura de reflexión:

CONTRATACIÓN SANA: SE SOLICITA AYUDA PARA COMERCIO ELECTRÓNICO

"Estarán felices de enterarse que logramos convencer a la administración de que debemos contratar un nuevo analista de sistemas que se especialice en el desarrollo de comercio electrónico", comento AL Falfa, analista de sistemas de la cadena internacional de tiendas Marathon Vitamin Shops. Actualmente se reune con su numeroso equipo de analista de sistemas para determinar las cualidades con que debe contar el nuevo miembro de su equipo. Al continua: "De hecho, mostraron tanto interés por la posibilidad de que nuestro equipo colabore en la estrategia de comercio electrónico de Marathon que me indicaron que comencemos de inmediato nuestra búsqueda por el especialista y no esperemos hasta el otoño".

Ginger Rute, otra analista, muestra su aprobación: "Cuando la economía es saludable, la demanda de desarrolladores de sitios Web rebasa con mucho a la oferta. Debemos actuar con rapidez. Creo que el nuevo analista debe tener conocimientos en herramientas CASE, Visual Basic y Java Script, por mencionar algunos".

Al se sorprende al escuchar la larga de lenguajes que enumera Ginger y replica: "Tienes razón, esa es una de nuestras opciones. Sin embargo, también me gustaría que el nuevo mimbro tuviera algo de experiencia en negocios. La mayoría de los egresados de las escuelas tienen sólidos conocimientos de programación, pero también deberían saber sobre contabilidad inventarios y distribución de bienes y servicios".

 

La más nueva en el grupo de analistas de sistemas, Vita Minn, se incorpora al debate: "Una de las razones por las cuales me incliné a trabajar con todos ustedes fue porque considero que nos llevamos bastante bien unos con otros. Como tenia otras opciones, tuve cuidado de ver como era el ambiente aquí. Por lo que he visto, conformamos un grupo amistoso. Así que asegurémonos de contratar a alguien que cuente con una personalidad adecuada que se acople al equipo".

Al esta de acuerdo y continua: "Vita tiene razón. El nuevo analista debe ser alguien que se comunique bien con nosotros, lo mismo que con los clientes de negocios.

 Siempre nos estamos comunicando de alguna manera, ya sea mediante presentaciones formales, dibujando diagramas o entrevistando a los usuarios. Si entienden por que se toman las decisiones, su trabajo también se facilitara. Asimismo, Maratón tiene interés en integrar el comercio electrónico en toda la empresa. Requerimos alguien que comprenda al menos la importancia estratégica de la Web. El diseño de paginas es solo una pequeña parte de esto".

Ginger interviene nuevamente con una buena dosis de sentido practico: "Deja eso en manos de la administración. Sigo creyendo que la nueva persona debe ser un buen programador". Luego reflexiona en voz alta: "¿Me pregunto que tan importante será saber UML para el puesto?"

Después de escuchar con paciencia los argumentos de todos, uno de los analistas veteranos, Cal Siem, interviene, bromeando: "¡Mejor deberíamos ver si Supermán esta disponible!"

Mientras todos ríen, AL vislumbra la oportunidad de lograr el consenso y dice: "Hemos tenido la oportunidad de escuchar diferentes cualidades. Tomemos un momento y cada quien haga una lista de las cualidades que considere esenciales en la persona que se encargara del desarrollo del comercio electrónico. Las expondremos y continuaremos el debate hasta que definamos a la persona con suficiente detalle y podamos elaborar un perfil para que el departamento de recursos humanos le de seguimiento".

¿Qué cualidades debe buscar el equipo de analistas de sistemas al contratar l nuevo miembro del equipo de desarrollo de comercio electrónico? ¿Es más importante el conocimiento de lenguajes específicos o contar con habilidad para aprender con rapidez lenguajes y paquetes de software? ¿Qué tan importante es que la persona que se contrate tenga algunos conocimientos básicos de negocios? ¿Deberían todos los miembros del equipo contar con habilidades y conocimientos idénticos? ¿Qué rasgos personales y carácter debe tener un analista de sistemas que trabaje en el desarrollo de comercio electrónico?

EXISTEN TRES ROLES PRINCIPALES DEL ANALISTA DE SISTEMAS:

EL ROL DE CONSULTOR.

Añadir leyenda

Con frecuencia, el analista de sistemas desempeña el rol de consultor para un negocio y, por tanto, podría ser contratado de manera específica para enfrentar los problemas de sistemas de información de una empresa. Esta contratación se puede traducir en una ventaja porque los consultores externos tienen una perspectiva fresca de la cual carecen los demás miembros de una organización. También se puede traducir en una desventaja porque alguien externo nunca conocerá la verdadera cultura organizacional. 

EL ROL DE EXPERTO EN SOPORTE TÉCNICO.

Otro rol que tendrá que desempeñar es el de experto en soporte técnico dentro de la empresa en la cual labora de manera regular. En este rol el analista recurre a su experiencia profesional con el hardware y software de cómputo y al uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de sistemas, sino más bien la realización de pequeñas modificaciones o la toma de decisiones que se circunscriben a un solo departamento.

EL ROL DE AGENTE DE CAMBIO DEL ANALISTA DE SISTEMAS

El rol más completo y de mayor responsabilidad que asume el analista de sistemas es el de agente de cambio, ya sea interno o externo para la empresa. Como analista, usted es un agente de cambio si desempeña en cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo de sistemas (que se explicara en la siguiente sección) y está presente en la empresa durante un largo periodo. Un agente de cambio se puede definir como alguien que sirve de catalizador para el cambio, desarrolla un plan para el cambio y coopera con los demás para facilitar el cambio. 

 En su calidad de analista de sistema desempeñando la función de agente de cambio, debe promover un cambio que involucre el uso de los sistemas de información. También es parte de su tarea enseñar a los usuarios el proceso del cambio, ya que las modificaciones a un sistema de información no sólo afectan a éste sino que provocan cambios en el resto de la organización.

Comentario personal:

Según la lectura anterior, el rol del analista de sistemas frente a los constantes cambios y avance de la tecnología, debe ser amplio. Debe ser una persona predispuesta a la adquisición de nuevos conocimientos, es decir debe estar en constante actualización frente a los avances tecnológicos. Debe tener una personalidad de modo que sea capaz de adaptarse al equipo de trabajo  y tener un trato amable para con los clientes.

Respecto a los tres roles principales del analista de sistemas, refiriéndonos específicamente al rol de consultor, el analista, debe estar capacitado para responder a las demandas de diseño de nuevos sistemas frente a determinados problemas en la empresa o negocio que se desenvuelva.

En cuanto al rol de experto en soporte técnico,considero que es uno de los roles más demandados o solicitados por las empresas y personas particulares que tienen una computadora en sus hogares, por tanto el analista de sistemas debe estar capacitado en cuanto al manejo de hardware y software de computo.

El rol de agente de cambio, es ya un nuevo paradigma o forma parte del perfil profesional del  egresado. El analista de sistemas debe ser alguien que promueva un cambio sano y para bien de la empresa o negocio donde trabaja, debe desarrollar estrategias de trabajo en equipo y elaborar un plan para facilitar el cambio. Este cambio debe, necesariamente involucrar el uso de los sistemas de información.

Algo muy importante, el analista de sistemas debe tener ética personal y profesional firme que le ayude a mantener una comunicación cordial con sus clientes.

En síntesis, la profesión del analista de sistemas es muy exigente, ya que esta en constante evolución y  siempre trae nuevos retos.

Análisis y Diseño de sistemas usando UML

Introduccion a UML

Qué es UML ?

El Lenguaje Unificado de Modelado (UML, por siglas en inglés Unified Modeling Languaje) es un lenguaje muy popular de modelado de sistemas de software. Creado y administrado por OMG (Object Managed Group, grupo dedicado al desarrollo de estándares y tecnologías relacionados con la programación orientada a objetos), UML usa técnicas de notación gráfica para crear modelos visuales de sistemas de desarrollo de software. Hoy es el lenguaje de modelado de software más utilizado.

UML se encarga de documentar, visualizar y especificar las funciones y procesos de los sistemas de software orientados al objeto, pero no los programa, ya que de eso se encargan los lenguajes de programación orientados a objetos. UML representa un modelo estándar para visualizar un blueprint (dibujo técnico) de sistema, que incluye elementos como el actor (que especifica el papel que juega un usuario que interactúa con el sujeto), el proceso de negocio (tareas relacionadas lógicamente para lograr un negocio definido), el componente (encapsula el contenido del sistema), la actividad (tarea que toma lugar para cumplir un contrato de operación), los estatutos del lenguaje de programación, los esquemas de la base de datos y los componentes reusables del software.

UML 2.0 tiene 13 tipos diferentes de diagramas, que permiten ver los diferentes aspectos de las entidades que se representan. Se pueden clasificar en 3 grupos que son: Diagramas de Estructura, que se centran en los elementos que debe poseer el sistema modelado (de clases, de componentes, de objetos, de estructura compuesta, de despliegue y de paquetes); Diagramas de Comportamiento, que se centran en lo que debe suceder en el sistema modelado (de actividades, de casos de uso y de estado); y Diagramas de Interacción, que son un tipo de diagramas de comportamiento que se centran en el flujo de control y de datos que existen entre los componentes del sistema modelado (de secuencia, de comunicación, de tiempos y de vista de interacción.

Es muy importante llegar a familiarizarse con UML, ya que, como hemos visto, cuenta con muchas herramientas. Una vez que lo conocemos bien, y sabemos para qué sirven los componentes y cuáles son sus limitaciones, podemos saber qué herramienta nos ayudará a cumplir con nuestro propósito. El UML permite ver claramente en pocos diagramas lo que podría ser tan complicado como lo es un sistema.

Diagramas HIPO

DIAGRAMAS HIPO

(En inglés, Hierarchy-Input-Process-Output) fueron desarrollados por IBM como esquemas de representación para un desarrollo jerárquico de arriba a abajo y como una ayuda de documentación para productos comercializados. Un conjunto de diagramas HIPO contiene una tabla visual de contenido, un conjunto de diagramas generales y un conjunto de diagramas de detalles.

1. La tabla visual de contenido es el directorio del conjunto de diagramas en el paquete; consta de un directorio con estructura de árbol (o de gráfica),

un resumen de los contenidos de cada diagrama general, y una explicación de los símbolos utilizados.

2. Los diagramas generales especifican los procesos de un sistema en forma funcional; cada diagrama describe las entradas, los pasos de proceso y las salidas para la función en cuestión; un diagrama general puede indicar la localización de los diagramas de detalles subordinados necesarios.

3. Los diagramas de detalle permiten crear para cada módulo la realización de un diagrama funcional . Por ejemplo validar transacciones

DIAGRAMAS WARNIER/ORR

Los diagramas de Warnier/Orr (también conocidos como construcción lógica de programas/construcción lógica de sistemas) fueron desarrollados inicialmente en Francia por Jean Dominique Warnier y en los Estados Unidos por Kenneth Orr. Este método ayuda al diseño de estructuras de programas identificando la salida y resultado del procedimiento, y entonces trabaja hacia atrás para determinar los pasos y combinaciones de entrada necesarios para producirlos. Los sencillos métodos gráficos usados en los diagramas de Warnier/Orr hacen evidentes los niveles en un sistema y más claros los movimientos de los datos en dichos niveles.

ELEMENTOS BASICOS

Los diagramas de Warnier/Orr muestran los procesos y la secuencia en que se realizan. Cada proceso se define de una manera jerárquica ; es decir, consta de conjuntos de subprocesos que lo definen, en cada nivel, el proceso se muestra en una llave que agrupa a sus componentes. Puesto que un proceso puede tener muchos subprocesos distintos, un diagrama de Warnier/Orr usa un conjunto de llaves para mostrar cada nivel del sistema.

USO DE DIAGRAMAS DE WARNIER/ORR

La capacidad de mostrar la relación entre procesos y pasos de un proceso no es exclusiva de los diagramas de Warnier/Orr, así como tampoco lo es el uso de la iteración, selección de alternativas o el tratamiento de casos individuales. Tanto los diagramas de flujo estructurado y los métodos del español estructurado logran eso también. Sin embargo, el enfoque que se usa para desarrollar las definiciones de un sistema por medio de estos diagramas es distinto y se adapta y se adaptan bien a los que se usan en el diseño de sistemas lógicos.

Para desarrollar un diagrama de Warnier/Orr , el analista trabaja hacia atrás, empezando con la salida del sistema y usando un análisis orientado hacia la salida. En el papel el desarrollo se mueve de izquierda a derecha. En primer lugar, se definen la salida o resultados esperados del procedimiento. En el nivel siguiente, mostrado mediante la inclusión por medio de una llave, se definen los pasos necesarios para producir la salida. A su vez, cada paso se define un poco mas. Las llaves adicionales agrupan los procesos requeridos para producir el resultado en el siguiente nivel.

Los diagramas de Warnier/Orr ofrecen a los expertos en sistemas algunas ventajas distintivas. Son simples en apariencia y fáciles de entender. Aun así, son poderosas herramientas de diseño. Tienen la ventaja de mostrar agrupaciones de procesos y los datos que deben transferirse de nivel a nivel. Además, la secuencia del trabajo hacia atrás garantiza que el sistema estará orientado hacia el resultad.

http://lum2010adsinf.blogspot.com/2010/04/diagramas-hipo-y-warnierorr.html

Fuentes para ampliar la informacion:

Diagramas HIPO

Diagramas hipo_2

El modelo de prototipos

Aquí está la pagina de donde la ing extrajo el tema de prototipos

El uso del prototipo en el ciclo de desarrollo de sistema

Enviado por Avelino Vedia Nuñez

Anuncios Google

Descarga Gratis

Indice1. Introducción
2. Prototipo
3. Desarrollo de Prototipo
4. Estrategias para el Desarrollo de Prototipos
5. Roles
6. Ventajas y Desventajas
7. Conclusiones
8. Bibliografía
1. Introducción
A menos que el proyecto de sistemas sea lo más tradicional o muy básico, los usuarios no siempre podrán definir sus requerimientos en forma adecuada y precisa o simplemente no pueden especificar los requerimientos de manera previa, sino que se deben descubrirlo. Prototipo es un vocablo usado por docentes, profesionales pero a que proyecto se debe emplear. Este trabajo pretende

1. Establecer los factores que llevan al uso de los prototipos.
2. Establecer los propósitos del prototipo
3. Determinar en que etapa del Desarrollo puedo usar prototipos.
4. Determinar los roles que desempeña tanto los usuarios como los profesionales de sistema al usar Prototipos.
5. Determinar las Ventajas y Desventajas al usar prototipos.

2. Prototipo
¿Qué es un Prototipo?
Es un modelo a escala o facsímil de lo real, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final. Proporcionando una retroalimentación temprana por parte de los usuarios acerca del Sistema.
Importancia de Definir su Objetivo
Siempre se debe establecer cual es su objetivo, ya que un prototipo puede ser útil en diferentes fases del proyecto, por ello su objetivo debe ser claro. Durante la fase de análisis se usa para obtener los requerimientos del usuario. En la fase de diseño se usa para ayudar a evaluar muchos aspectos de la implementación seleccionada.
Propósitos del Prototipo
En la fase de Análisis de un proyecto, su principal propósito es obtener y validar los requerimientos esenciales, manteniendo abiertas, las opciones de implementación. Esto implica que se debe tomar los comentarios de los usuarios, pero debemos regresar a sus objetivos para no perder la atención.
En la fase de Diseño, su propósito, basándose en los requerimientos previamente obtenidos, es mostrar las ventanas, su navegación, interacción, controles y botones al usuario y obtener una retroalimentación que nos permite mejorar el Diseño de Interfaz.
Características de los Prototipos
El proceso de desarrollo y empleo de prototipos tiene las siguientes características:

• El prototipo es una aplicación que funciona
• Los prototipos se crean con rapidez
• Los prototipos evolucionan a través de un proceso iterativo
• Los prototipos tienen un costo bajo de desarrollo

Información Obtenida con el uso del Prototipo
Reacciones Iniciales del Usuario
El profesional de Sistema por medio de la observación, evaluación y la retroalimentación, obtendrá como reaccionan los usuarios al trabajar con el prototipo, y que tan conveniente es el acoplamiento entre las necesidades y las características modeladas en el sistema. A través de la recopilación de tales reacciones, el profesional, irá descubriendo nuevas perspectivas del prototipo, incluso si los usuarios se encuentran satisfechos con él, o si habrá dificultades para vender o implantar el sistema.
Sugerencias
Las sugerencias son el fruto de la relación de los usuarios con el prototipo, las sugerencias aportadas por el usuario indican al profesional porque caminos dirigirse para refinar el prototipo, modificarlo o depurarlo, de forma que satisfaga mejor las necesidades de los usuarios.
Innovaciones
Las innovaciones son aquellas características nuevas del sistema que no fueron contempladas previamente a la interacción con el prototipo.
Prioridades
La información que se obtiene con el uso de prototipos permite al profesional establecer prioridades y reorientar sus planes de una manera menos costosas y con un mínimo de contratiempo.
Una de las peores cosas que le puede pasar a un profesional es diseñar e implantar un sistema que el usuario no necesita, ni desean.
3. Desarrollo de Prototipo
Problemas Candidatos
Para decidir si el prototipo debe incluirse o no Ciclo de Desarrollo de Sistema de Información, el profesional considera los siguientes factores:

• Problemas no estructurado, novedosos y complejos, de información personalizada del usuario, ya que sus salidas no son predecibles y definidas
• Problemas de ambiente Inestable, el profesional también debe evaluar el contexto del sistema
• Experiencia en diseños similares
• No se conocen los requerimientos, la naturaleza del sistema es tal que existe poca información con respecto a las características que debe tener el nuevo sistema para satisfacer las necesidades del usuario
• Los requerimientos deben evaluarse, se conocen los requerimientos aparentes de información pero es necesario verificarlos y evaluarlos
• Costos altos, donde la inversión involucra gran cantidad de recursos financieros y humanos.
• Altos riesgo, la evaluación inexacta de los requerimientos o el desarrollo incorrecto ponen en peligro a la organización
• El usuario, donde no está dispuesta examinar modelos en papel, o no sabe lo que quiere pero lo reconocerá cuando lo vea.
• Tecnologías Nuevas, la falta de experiencia en el uso de dichas tecnologías, junto con el deseo de instalar nuevas tecnología hace que sea propicio el uso del prototipo.

Etapas del Prototipo
El desarrollo de un prototipo se lleva a cabo en forma ordenada a través de las siguientes etapas, Figura 1:
Identificación de Requerimientos Conocidos
El profesional de sistema identifica los requerimientos conocidos, generales, o características esenciales y determina el propósito del prototipo de la aplicación.
Desarrollo de un Modelo
En esta etapa se explica el método iterativo y las responsabilidades a los usuarios ya que el usuario participa directamente en todo el proceso. La rapidez con la que se genera el sistema es esencial para que no se pierda el estado de ánimo sobre el proyecto y los usuarios puedan comenzar a evaluar la aplicación con la mayor brevedad posible. El profesional de sistema para construcción inicial del prototipo emplea cualquier herramienta, como Lenguajes de Cuarta Generación, Generadores de Reportes, Generadores de Pantallas
En el desarrollo de un prototipo se preparan los siguientes componentes:

• El lenguaje para el diálogo o conversación entre el usuario y el sistema
• Pantallas y formatos para la entrada de datos
• Módulos esenciales de procesamientos
• Salida del sistema

La incorporación en la interfaz de entrada/salida de características representativas de las que serán incluidas en el sistema final permite una mayor exactitud en el proceso de evaluación.
Revisión del Prototipo
Es responsabilidad del usuario trabajar con el prototipo y evaluar sus características y operación. La experiencia con el sistema bajo condiciones reales permite la familiaridad indispensable para determinar los cambios o mejoras que sean necesarios, o también la eliminación de características innecesarias.
El profesional de sistema captura la información sobre lo que le gusta y lo que le desagrada a los usuarios. Esta información tiene influencia en la siguiente versión del prototipo, la cual se presenta modificada, refinada.
Iteración
Los dos últimos etapas descriptas anteriormente se repiten varias veces hasta que estén usuarios y profesionales de sistema de acuerdo en que el prototipo ha evolucionado lo suficiente o que una iteración mas no traerá beneficios adicionales.
Prototipo Terminado
Cuando el prototipo está terminado, es decir, tenemos la información que buscamos seguimos en el punto donde habíamos quedado dentro del Ciclo de Desarrollo de Sistema.
4. Estrategias para el Desarrollo de Prototipos
Se puede desarrollar un prototipo para cada uno de los componentes de la aplicación
Prototipos por Pantallas
La interface entre el sistema y el usuario es la pantalla de visualización, esta es el vehiculo para presentar la información tal como ésta es proporcionada al sistema o como es recuperada de éste.
Los prototipos de pantalla permite evaluar la posición de información sobre la pantalla, los encabezados, los botones, mensajes. Tambíen permite la reacción de los usuarios por la cantidad de información sobre la pantalla. La ceación de un prototipo de pantalla conduce a:

• Que debe presentarse como información sobre la pantalla principal
• Cuál pertence a una pantalla de detalle

Prototipos para Procedimientos de Procesamientos
Las funciones de procesamiento incluye entradas, cálculos, recuperar información y actividades de salidas. Como los datos pocas veces son ingresados de la forma correcta o en la secuencia válida, es por ello que la aplicación se diseña para asegurar la detección de errores.
El objetivo es determinar si los procedimientos de aplicación fueron desarrollados adecuadamente.
La evaluación de los procedimientos y la observación de errores y equivocaciones cometidas por los individuos cuando emplean el prototipo, pueden sugerir la adición de características de manejo de errores que no se habían anticipado.
Prototipos de Funciones Básicas
Para determinar los requerimientos de una aplicación no es necesario desarrollar todos los módulos del sistema, sino los básicos, son aquellos que forman el núcleo de la aplicación.
Incluye las funciones primarias de la aplicación como edición y validación, y excluye las secundarias como el manejo de archivos que no forman parte del procesamiento esencial.
Por ejemplo:
Una aplicación de Reclamos de una venta, tendrá módulos de:

• Recepción de la información de la venta que se reclama
• Validación del número de factura
• Recuperación de la venta
• Generación de Nota de Crédito

Y pueden omitirse por ejemplo:

• La impresión de la Nota de Crédito
• Registro de esta operación

5. Roles
Rol del Usuario
El papel del usuario con el prototipo puede resumirse en compromiso y honestidad. Si carece de compromiso pocos son los motivos para desarrollar un prototipo, ya que el usuario es el pivote del proceso de desarrollo y evaluación. Los usuarios interactuan con el prototipo teniendo las siguientes responsabilidades:

• Utilizar y evaluar el prototipo las veces que sea necesario
• Identificar mejoras
• Sugerir las característica no deseadas
• Describir los requerimientos de datos
• Describir la salida deseada

Rol del Profesional de Sistema
El papel del profesional de sistema no solo debe contruir el prototipo sino tambien que debe:

• Crear el clima adecuado al usuario para que este se exprese sin temor alguno
• Familiarizar al usuario con el prototipo
• Crear el plan para el desarrollo del prototipo
• Contruir la versión inicial
• Evaluar las reacciones del usuario y plasmar las modificaciones en una nueva versión

6. Ventajas y Desventajas
Existen ventajas relevantes en el uso del Prototipo:

• Modificación del Sistema en Etapas tempranas de su desarrollo: El éxito del uso del prototipo depende de qué tan pronto y con que frecuencia se reciba la retroalimentación del usuario para hacer cambios y adecuarlos a las necesidades actuales. Los cambios iniciales durante el desarrollo de un proyecto son menos costosos que si se realizan en etapas tardías, como el prototipo puede cambiar varias veces la flexibilidad y adaptabilidad son su esencia, la pauta del cambio la da la retroalimentación, la cual nos permite conocer la opinión del usuario sobre cambios a la entrada o salida de un proceso, que al evaluarla nos permite obtener los requerimientos y mejorar el sistema.

El desarrollo de prototipos implica una inversión en tiempo y en dinero, siempre pero siempre es menor a la del sistema completo. Los problemas y descuidos de sistemas son más fáciles de detectar en un prototipo.

• Eliminación de sistemas indeseables: Por permitir recopilar información nos permite eliminar un sistema que no llegó a ser lo que esperaban de él los usuarios. La inversión de tiempo y dinero se destaca pero es menor que la del sistema completo. Se toma esta decisión cuando el sistema no es útil o no satisface los objetivos que se propuso el equipo de desarrollo, es una decisión dificil pero evita seguir gastando dinero y tiempo en un proyecto inservible.
• Diseño de Sistemas acorde a las necesidades y expectativas de los usuarios: El uso del prototipo hace que los sistemas se ajusten a las necesidades de los usuarios. Se reduce el intervalo de tiempo desde que se relevan los requerimientos y el sistema concluido. Permite que los usuarios se involucren desde el principio y lo hace participar en forma activa, de esta forma hacen suyo el proyecto, siendo los principales promotores del éxito.

El prototipo cuenta con las siguientes desventajas:

• Administración dificil: Dicha dificultad radica en manejar el prototipo como un proyecto dentro del Ciclo de Desarrollo de Sistema sin perder de vista cual era sus propósito.
• Adoptarlo como el sistema final: Los usuarios y profesionales de sistemas pueden considerar al prototipo como el sistema final cuando aún es imcompleto e inadecuado.

7. Conclusiones
La elaboración de prototipos es un enfoque de construir un poco y probar un poco, antes de construir el sistema final.
El profesional de sistema se encuentra ante una excelente técnica de relevamiento de información, obteniendo Reacciones del Usuario, Sugerencias, Innovaciones, Prioridades.
Los resultados de un acoplamiento estrecho entre el usuario, el profesional de sistema y los modelos reducen el vacío entre lo que los usuarios piensan de los sistemas y lo que realmente obtiene. Al usuario se lo introduce directamente en el desarrollo de manera que la aplicación se convierta en su proyecto, comunicando mejor sus requerimientos, reduciendo la habilidad del profesional de sistema en traducir los requerimientos.
El usuario prueba algo, ve lo que sucede, luego lo modifica, esta interacción proporciona una retroalimentación instantánea y le permite ver al usuario ver inmediatamente sus resultados y modificar el modelo tantas veces como sea necesario antes de su terminación. Los pasos de análisis, diseño y construcción se convinan en un flujo interactivo que es el paso clave.
La elaboración de prototipo no es aplicable para sistemas básicos pero si para desarrollo de sistemas únicos e innovadores que traen consigo un gran número de beneficios cualitativos, para satisfacer las necesidades especiales de reportes y toma de decisión, tal como se observa en la Figura 2
Consideraciones Generales
El enfoque que aquí se plantea consiste en desarrollar prototipos como parte del Ciclo de Desarrollo de Sistema. Con este enfoque se considera como un método complementario especializado para relevar requerimientos de información del usuario
8. Bibliografía

• BURCH J. G. y GRUDNITSKI G.,1997, Diseño de Sistemas de Información. Megabyte Noriega Asociados, 985 p.
• KENDALL, K. E. y KENDALL J. E.,1991, Análisis y Diseño de Sistema. Prentice –Hall Hispanoamericana S.A., 881 p.
• RUBLE, D. A., 1998, Análisis y Diseño Práctico de Sistemas Cliente/Servidor con GUI. Prentice Hall, 514 p.
• SENN, J. A., 1992, Análisis y Diseño de Sistemas de Información. McGraw –Hill, 942 p.
• YOURDON, E., 1989, Análisis Estructurado Moderno. Prentice –Hall Hispanoamericana S.A., 735 p.

Ciclo de vida clasico de un sistema

Ciclo de vida de un sistema de información

En la actualidad para muchas organizaciones, los sistemas de información basados en computadoras son el corazón de las actividades cotidianas y objeto de gran consideración en la toma de decisiones, las empresas consideran con mucho cuidados las capacidades de sus sistemas de información cuando deciden ingresar o no en nuevos mercados o cuando planean la respuesta que darán a la competencia.

Al establecer los sistemas de información basados en computadoras deben tener la certeza de que se logren dos objetivos principales: que sea un sistema correcto y que este correcto el sistema. Ningún sistema que deje satisfacer ambos objetivos será completamente útil para la gerencia u organización.
Si los dispositivos de un sistema de información no se adaptan a su población de clientes, no lograra sus objetivos potenciales. A mismo tiempo, aun cuando se identifiquen precisamente las necesidades del usuario, un sistema de información va tener un valor único si funciona en forma adecuada.
Los informes y las salidas producidas por el sistema deben ser precisos, confiables y completos. La función del Análisis puede ser dar soporte a las actividades de un negocio, o desarrollar un producto que pueda venderse para generar beneficios.
Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre.
Aunque la estimación, es más un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.
Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones.
A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software. La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.

CICLO DE VIDA DE UN SISTEMA DE INFORMACION

El ciclo de vida de un sistema de información es un enfoque por fases del análisis y diseño que sostiene que los sistemas son desarrollados de mejor manera mediante el uso de un ciclo especifico de actividades del analista y del usuario.
Según James Senn, existen tres estrategias para el desarrollo de sistemas: el método clásico del ciclo de vida de desarrollo de sistemas, el método de desarrollo por análisis estructurado y el método de construcción de prototipos de sistemas. Cada una de estas estrategias tienen un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada.

CICLO DE VIDA CLÁSICO DEL DESARROLLO DE SISTEMAS

 El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases:
1). Investigación Preliminar: La solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una persona.
2). Determinación de los requerimientos del sistema: El aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la empresa que se encuentra bajo estudio. Los analistas, al trabajar con los empleados y administradores, deben estudiar los procesos de una empresa para dar respuesta a las siguientes preguntas clave:
¿Qué es lo que hace?
¿Cómo se hace?
¿Con que frecuencia se presenta?
¿Qué tan grande es el volumen de transacciones o decisiones?
¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
¿Existe algún problema? ¿Qué tan serio es? ¿Cuál es la causa que lo origina?
3). Diseño del sistema: El diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.
4). Desarrollo del software: Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores.
Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.
5). Prueba de sistemas: Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga.
Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.
6). Implantación y evaluación: La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.
Por consiguiente, es indudable que debe darse mantenimiento a las aplicaciones. La evaluación de un sistema se lleva a cabo para identificar puntos débiles y fuertes. La evaluación ocurre a lo largo de cualquiera de las siguientes dimensiones:
*Evaluación operacional: Valoración de la forma en que funciona el sistema, incluyendo su facilidad de uso, tiempo de respuesta, lo adecuado de los formatos de información, confiabilidad global y nivel de utilización.
*Impacto organizacional: Identificación y medición de los beneficios para la organización en áreas tales como finanzas, eficiencia operacional e impacto competitivo. También se incluye el impacto sobre el flujo de información externo e interno.
*Opinión de loa administradores: evaluación de las actividades de directivos y administradores dentro de la organización así como de los usuarios finales.
*Desempeño del desarrollo: La evaluación de proceso de desarrollo de acuerdo con criterios tales como tiempo y esfuerzo de desarrollo, concuerdan con presupuestos y estándares, y otros criterios de administración de proyectos. También se incluye la valoración de los métodos y herramientas utilizados en el desarrollo.

Bibliografia para ampliar informacion:
 http://www.monografias.com/trabajos29/ciclo-sistema/ciclo-sistema.shtml

Para ver si has comprendido la lectura, "si es que lo leiste" haz clic  AQUÍ Autoevaluacion del tema

Programacion orientada a objetos (POO)

Programación orientada a objetos

La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herencia, cohesión, abstracción, polimorfismo, acoplamiento y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe variedad de lenguajes de programación que soportan la orientación a objetos.

Introducción

Los objetos son entidades que tienen un determinado estado, comportamiento (método) e identidad:

• El estado está compuesto de datos o informaciones; serán uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
• El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.
• La identidad es una propiedad de un objeto que lo diferencia del resto; dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).

Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.

Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.

La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada solo se escriben funciones que procesan datos. Los programadores que emplean POO, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

Origen

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard, del Centro de Cómputo Noruego en Oslo. En este centro se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.

La programación orientada a objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.

Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp y Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos, pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha modificado; soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

Conceptos fundamentales

La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

• Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
• Herencia: (por ejemplo, herencia de la clase C a la clase D) es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables publicas declaradas en C. Los componentes registrados como "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de OOP.
• Objeto: entidad provista de un conjunto de propiedades o atributos (datos) y de comportamiento o funcionalidad (métodos), los mismos que consecuentemente reaccionan a eventos. Se corresponden con los objetos reales del mundo que nos rodea, o con objetos internos del sistema (del programa). Es una instancia a una clase.
• Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
• Evento: es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento la reacción que puede desencadenar un objeto; es decir, la acción que genera.
• Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
• Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
• Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase.
• Componentes de un objeto: atributos, identidad, relaciones y métodos.
• Identificación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes.

En comparación con un lenguaje imperativo, una "variable" no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

Características de la POO

Existe un acuerdo acerca de qué características contempla la "orientación a objetos". Las características siguientes son las más importantes:

• Abstracción: denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un "agente" abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos, y, cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. El proceso de abstracción permite seleccionar las características relevantes dentro de un conjunto e identificar comportamientos comunes para definir nuevos tipos de entidades en el mundo real. La abstracción es clave en el proceso de análisis y diseño orientado a objetos, ya que mediante ella podemos llegar a armar un conjunto de clases que permitan modelar la realidad o el problema que se quiere atacar.

• Encapsulamiento: significa reunir todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente.

• Modularidad: se denomina modularidad a la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Estos módulos se pueden compilar por separado, pero tienen conexiones con otros módulos. Al igual que la encapsulación, los lenguajes soportan la modularidad de diversas formas.

• Principio de ocultación: cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas; solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no puedan cambiar el estado interno de un objeto de manera inesperada, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos.

• Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre; al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O, dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++.

• Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento, permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente agrupando los objetos en clases y estas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple.

• Recolección de basura: la recolección de basura o garbage collector es la técnica por la cual el entorno de objetos se encarga de destruir automáticamente, y por tanto desvincular la memoria asociada, los objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse expresamente.

 Fuente