Conceptos Básicos sobre Análisis y Diseño de Sistema

Conceptos Básicos sobre Análisis y Diseño de Sistemas INTRODUCCION A LOS SISTEMAS DE INFORMACION OBJETIVO. Conocer los conceptos básicos, los elementos y la clasificación de los sistemas de información y su relación con los analistas de sistemas. INTRODUCCION. En una organización o empresa, el analista y diseño de sistemas es el proceso de estudiar su situación con la finalidad de observar como trabaja y decir si es necesario realizar una mejora; el encargado de realizar estas tareas es el analista de sistemas para . Antes de comenzar el desarrollo de cualquier proyecto, se conoce un estudio de sistema s para detectar todos los detalles de la situación actual en la empresa. La información reunida con este estudio sirve como base para crear varias estrategias de diseño. Los administradores deciden qué estrategia seguir. Los gerentes, empleados y otros usuarios finales que se familiarizan cada vez más con el empleo de computadoras están teniendo un papel muy importante en el desarrollo de sistemas. Todas las organizaciones son sistemas que actúan recíprocamente con su medio ambiente recibiendo entradas y produciendo salidas. Los sistemas, que pueden estar formados por otros sistemas más pequeños denominados subsistemas, funcionan para alcanzar fines específicos. Sin embargo, los propósitos o metas se alcanzan sólo cuando se mantienen el control. SISTEMA DE INFORMACION Conjunto u ordenación de elementos organizados para llevar a cabo algún métodos, procedimiento o control mediante el proceso de información. ANALISIS Y SISTEMAS 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 mejorar con métodos y procedimientos más adecuados. El desarrollo de sistemas tiene dos componentes. Análisis Es el proceso de clasificación e interpretación de hechos, diagnostico de problemas y empleo de la información para recomendar mejoras al sistemas. Diseño: Especifica las características del producto terminado. Análisis: Especifica que es lo que el sistema debe hacer. Diseño: Establece como alcanzar el objetivo. LO QUE NO ES EL ANÁLISIS DE SISTEMAS NO es: El estudio de una empresa para buscar procesos ya existentes con el propósito de determinar cuáles deberían, ser llevados a cabo por una computadora y cuáles por métodos manuales. La finalidad del análisis está en comprender los detalles de una situación y decir si es deseable o factible una mejora. La selección del método, ya sea utilizando o no una computadora, es un aspecto secundario. No es: Determinar los cambios que deberían efectuarse. No es: Determinar la mejor forma de resolver un `problema de sistemas de información. Sin importar cuál sea la organización, el analista trabaja en los problemas de ésta. Es un error hacer una distinción entre los problemas de la empresa y los de sistemas ya que estos últimos no existirían sin los primeros. Cualquier sugerencia debe primero considerarse a la luz de si beneficiará o perjudicará a la organización. No se debe ir tras ideas técnicamente atractivas a menos que estas mejoren el sistema de la organización. EL ANALISTA DE SISTEMAS DE INFORMACION En una empresa pequeña, lo más probable es que realice las actividades: 1.-ANALISIS DE SITEMAS (Analista de información): Es reunir información y determinar los requisitos. Los analistas no son responsables del diseño de sistema. 2.-ANALISIS Y DISEÑO DEL SISTEMA (Diseñadores de sistemas, Diseñadores de aplicaciones): El analista tiene la responsabilidad adicional de diseñar el nuevo sistema. 3.-ANALISIS, DISEÑO Y PROGRAMACIÓN DEL SISTEMA (Analista programador): Desarrolla las especificaciones de diseño y escribe el software necesario para implementar el diseño. ELEMENTOS DE UN SISTEMA DE INFORMACION SOFWARE. Los programas de computadoras, as estructuras de datos y la documentación asociada, que sirve para realizar el método lógico. HARWARE: Los dispositivos electrónicos que proporcionan la capacidad de computación y que proporcionan las funciones del mundo exterior. GENTE: Los individuos que son usuarios y operadores del software y del hardware. BASES DE DATOS: Una colección grande y organizada de información a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema. DOCUMENTACION: Los manuales, los impresos y otra información descriptiva que explica el uso y / o la operación. PROCESAMIENTOS: Los pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles de control tolerables de rendimiento por ejemplo: el sistema de control de un calentador de agua. CLASIFICACION DE LOS ISTEMAS DE INFORMACION ABIERTOS. Son los que intercambian información, materiales y energía con su ambiente. CERRADOS. Son auto contenidos, no interactúan con el medio ambiente. PROBABILISTICO. No se conoce con certeza su comportamiento. DEERMINISTICO. Cualquier estado futuro que adopten puede preciarse con antelación. CARACTERISTICAS DE SISTEMA DE INFORMACION Sus principales características son: Suelen lograrse ahorros significativos de mano de obra. Son el primer tipo de sistemas de información que se implanta en las organizaciones. Son intensivos en entradas y salidas de información; sus cálculos y procesos suelen ser simples y copo sofisticados, requieren mucho manejo de datos para poder realizar sus operaciones y como resultado generan también gr4andes volúmenes de información. Tiene la propiedad de ser recolectores de información. Son adaptables de aplicación que se encuentran en el mercado.

Analisis y Diseño de Sistemas

ANALISIS Y SISTEMAS 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 mejorar con métodos y procedimientos más adecuados. El desarrollo de sistemas tiene dos componentes. Análisis Es el proceso de clasificación e interpretación de hechos, diagnostico de problemas y empleo de la información para recomendar mejoras al sistemas. Diseño: Especifica las características del producto terminado. Análisis: Especifica que es lo que el sistema debe hacer. Diseño: Establece como alcanzar el objetivo. LO QUE NO ES EL ANÁLISIS DE SISTEMAS NO es: El estudio de una empresa para buscar procesos ya existentes con el propósito de determinar cuáles deberían, ser llevados a cabo por una computadora y cuáles por métodos manuales. La finalidad del análisis está en comprender los detalles de una situación y decir si es deseable o factible una mejora. La selección del método, ya sea utilizando o no una computadora, es un aspecto secundario. No es: Determinar los cambios que deberían efectuarse. No es: Determinar la mejor forma de resolver un `problema de sistemas de información. Sin importar cuál sea la organización, el analista trabaja en los problemas de ésta. Es un error hacer una distinción entre los problemas de la empresa y los de sistemas ya que estos últimos no existirían sin los primeros. Cualquier sugerencia debe primero considerarse a la luz de si beneficiará o perjudicará a la organización. No se debe ir tras ideas técnicamente atractivas a menos que estas mejoren el sistema de la organización. EL ANALISTA DE SISTEMAS DE INFORMACION En una empresa pequeña, lo más probable es que realice las actividades: 1.-ANALISIS DE SITEMAS (Analista de información): Es reunir información y determinar los requisitos. Los analistas no son responsables del diseño de sistema. 2.-ANALISIS Y DISEÑO DEL SISTEMA (Diseñadores de sistemas, Diseñadores de aplicaciones): El analista tiene la responsabilidad adicional de diseñar el nuevo sistema. 3.-ANALISIS, DISEÑO Y PROGRAMACIÓN DEL SISTEMA (Analista programador): Desarrolla las especificaciones de diseño y escribe el software necesario para implementar el diseño. ELEMENTOS DE UN SISTEMA DE INFORMACION SOFWARE. Los programas de computadoras, as estructuras de datos y la documentación asociada, que sirve para realizar el método lógico. HARWARE: Los dispositivos electrónicos que proporcionan la capacidad de computación y que proporcionan las funciones del mundo exterior. GENTE: Los individuos que son usuarios y operadores del software y del hardware. BASES DE DATOS: Una colección grande y organizada de información a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema. DOCUMENTACION: Los manuales, los impresos y otra información descriptiva que explica el uso y / o la operación. PROCESAMIENTOS: Los pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. CONTROL: Los sistemas trabajan mejor cuando operan dentro de niveles de control tolerables de rendimiento por ejemplo: el sistema de control de un calentador de agua. CLASIFICACION DE LOS ISTEMAS DE INFORMACION ABIERTOS. Son los que intercambian información, materiales y energía con su ambiente. CERRADOS. Son auto contenidos, no interactúan con el medio ambiente. PROBABILISTICO. No se conoce con certeza su comportamiento. DEERMINISTICO. Cualquier estado futuro que adopten puede preciarse con antelación. CARACTERISTICAS DE SISTEMA DE INFORMACION Sus principales características son: Suelen lograrse ahorros significativos de mano de obra. Son el primer tipo de sistemas de información que se implanta en las organizaciones. Son intensivos en entradas y salidas de información; sus cálculos y procesos suelen ser simples y copo sofisticados, requieren mucho manejo de datos para poder realizar sus operaciones y como resultado generan también gr4andes volúmenes de información. Tiene la propiedad de ser recolectores de información. Son adaptables de aplicación que se encuentran en el mercado. Ejemplos: facturación, nóminas, cuentas por cobrar, cuentas por pagar, contabilidad general. SISTEMAS DE APOYO PARA LA TOMA DE DECISIONES Entre los tipos de sistemas que apoyan el proceso de toma de decisiones se idéntica los siguientes: Sistemas de Soporte para la Toma de Decisiones (DSS: Decision Support Systems) Apoyar la toma de decisiones mediante la generación y evaluación sistemática de diferentes alternativas o escenarios de decisión. Un DSS no soluciona problemas, ya que solo apoya al proceso de toma de decisiones. La responsabilidad de tomar una decisión, de adoptar y de realizarla es de los administradores, no del DSS. Puede emplearse para obtener información que revele los elementos clave de los problemas y las relaciones entre ellos. También puede usarse para identificar, crear y comunicar cursos de acción disponibles y alternativas de decisión. Sistemas de Soporte para la Toma de Decisiones de Grupo (Group Decisión Support Systems). Cubren el objetivo de lograr la participación de un grupo de personas durante la toma de decisiones en ambientes de anonimato y consenso, apoyando decisiones simultaneas. Sistemas Expertos de Soporte para la Toma de Decisiones (DEss: Expert Decision Supprt Systems). Permiten cargar bases de conocimiento que se integran por una serie de reglas de sentido común para que diferentes usuarios las consulten, apoyen la toma de decisiones, la capacitación, etc. Sistemas de Información para Ejecutivos (EIS: Executive information Systems). Están dirigidos a apoyar el proceso de toma de decisiones de los altos ejecutivos de una organización, presentado información relevante y usando recursos visuales de fácil interpretación, con el ejecutivo de mantenerlos informados. Las principales características de estos sistemas son las siguientes: La Información que generan sirve de apoyo a los mandos intermedios y a la alta administración en el proceso de toma de decisiones. Suelen ser intensivos en cálculos y escasos en entrada y salidas de información. Así, por ejemplo, un modelo de planeación financiera requiere poca información de entrada, genera poca información como resultado pero puede realizar muchos cálculos durante su proceso. No suelen ahorrar mano de obra. Suelen ser interactivos y amigable, con altos estándares de diseño grafico y visual, ya que están dirigidos al usuario final. Apoyan la toma de decisiones que por su misma naturaleza son estructuradas y no estructuradas. Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participación operativa de los analistas y programadores del área de informática.

El método estructurado en el análisis de sistemas

ANÁLISIS ESTRUCTURADO Conceptos generales Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de información, a menudo tienen que profundizar en un área de la organización con la que tienen poca familiaridad. A pesar de esto, futuros usuarios - de esa área. Cualquier nuevo sistema o conjunto de recomendaciones para cambios en el sistema existente, ya sea éste manual o automatizado, debe conducir hacia una mejora. Para alcanzar este resultado, se espera que los analistas de sistemas hagan lo siguiente: aprendan los detalles y procedimientos del sistema en uso. Obtengan una idea de las demandas futuras de la organización como resultado del crecimiento, del aumento de la competencia en el mercado, de los cambios en las necesidades de los consumidores, de la evolución de las estructuras financieras, de la introducción de la nueva tecnología y cambios en las políticas del gobierno entre otros. Documentar detalles del sistema actual para su revisión y discusión por otros. Evaluar la eficiencia y efectividad del sistema actual y sus procedimientos, tomando en cuenta el impacto sobre las demandas anticipadas para el futuro. Fomentar la participación de gerentes y empleados en todo el proceso, tanto para aprovechar su experiencia y conocimiento del sistema actual, como para conocer sus ideas, sentimientos y opiniones relacionadas con los requerimientos de un nuevo sistema o de los cambios para la cual. ¿ Qué es el análisis estructurado? El análisis estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas abordan una situación poco familiar, siempre existe una pregunta sobre donde comenzar el análisis. Una situación dinámica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente, como señalo MARY HELEN es su seminario. El análisis estructurado permite el analista conocer un sistema o proceso (actividad) en una forma lógica y manejable el mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente. Significado de estructurado ¿qué es lo que desea estructurar? ¿ que significa estructurar? El objetivo que persigue el análisis estructurado es organizar las tareas asociada con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. A partir de aquí determina los requerimientos que serán la base de un sistema nuevo o modificado. En el análisis estructurado la palabra estructura significa qué: 1) el método intenta estructurar el proceso de determinación de los requerimientos comenzando con la documentación del sistema existente; 2) el proceso está organizado de tal forma que intenta incluir todos los detalles relevante que describe al sistema en uso; 3) es fácil verificar cuando se han omitido detalles relevantes; 4) la identificación de los requerimientos será similar entre varios analistas e incluirá las mejora soluciones y estrategias para las oportunidades para de desarrollo de sistemas; y 5) los documentos de trabajo generados para documentar los sistemas existente o propuesto son dispositivos de comunicación eficientes. Componentes del análisis estructurado El análisis estructurado hace uso de los siguientes componentes. símbolos gráficos diccionario de datos descripciones de procesos y procedimientos reglas Que es el análisis de flujo de datos? Los analistas desean conocer las respuestas a cuatro preguntas especificas: Que procesos integran el sistema? ?que datos emplea cada proceso? ?qué datos son almacenado? ?que datos ingresan y abandonan el sistema? De lo anterior es claro que se da gran importancia al análisis de los datos. Los datos son la guía de las actividades de la empresa. Ellos pueden iniciar eventos (por ejemplo, los datos sobre nuevos pedidos) y ser procesados para dar información útil al personal que desea saber qué también se han manejado los eventos (al medir la calidad y tasa de trabajo, rentabilidad, etc.). el análisis de sistemas conoce el papel central que tienen los datos de la empresa en las organizaciones. Seguir el flujo de datos por todos los procesos de la empresa, que es la finalidad del análisis de flujo de datos, les dice mucho a los analistas sobre como se alcanza los objetivos de la organización. En el transcurso del manejo de transacciones y terminación de tareas los datos entran, son procesados, almacenados, recuperados, analizados, utilizados, cambiados y presentados como salidas. El análisis de flujo de datos estudia el empleo de los datos en cada actividad. Documento a los hallazgos con diagramas de flujo de datos que muestran en forma gráfica la relación entre procesos y datos, en los diccionarios de datos que describe de manera formal los datos del sistema y los sitios donde son utilizados. CARACTERISTICAS DE LA ESTRATEGIA DE FLUJOS DE DATOS El análisis de flujo de datos examina el empleo de los datos para llevar a cabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas. El análisis puede pensarse de tal manera que se estudia actividades del sistema desde el punto de vista de los datos: donde se originan, como se utilizan o cambian, hacia donde van, incluyendo las paradas a los largo del camino que siguen desde sus origen hasta sus destino. Los componentes de la estrategia de flujo de datos abarcan tanto la determinación de los requerimientos como el diseño de sistemas. Una notación bien establecida facilita la documentación del sistemas actual y su análisis por todos los participantes en el proceso de determinación de requerimientos. Herramientas de la estrategia de flujo de datos La estrategia de flujo de datos muestra el empleo de estos en forma gráfica. Las herramientas utilizadas al seguir esta estrategia muestran todas las características esenciales del sistema y la forma en que se ajustan entre sí. Puede ser difícil comprender en su totalidad un proceso de la empresa si se emplea para ello una descripción verbal; Las herramientas para el flujo de datos ayuda a mostrar los componentes esenciales de un sistema junto con sus interacciones. El análisis de flujo de datos utiliza la sguie. Herramientas. Diagrama de flujo de datos Una herramienta gráfica se emplea para describir y analizar el movimiento de datos a través de un sistema, ya sea que este fuera manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Estos diagramas reciben el nombre de diagramas lógicos de flujo de datos Diccionario de datos el diccionario contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenidos y organización. También identifica los procesos donde se emplea los datos y los sitios de donde se necesitan el acceso inmediato a la información. Sirve como puerto de partida para identificar los requerimientos de las bases de datos durante el diseño del sistema. Diagrama de estructura de datos Este diagrama es una descripción de la relación entre entidades (personas, lugares, eventos y objetos) de un sistema y el conjunto de información relacionada con la entidad. No considera el almacenamiento físico de los datos. gráfica de estructura Herramienta de diseño que muestra con símbolos la relación entre los módulos de procesamiento y el software de la computadora describe la jerarquía de los módulos componentes y los datos que serán transmitidos entre ellos. Incluye el análisis de las transformaciones entrada - salida y el análisis de transacción. DESARROLLO DE DIARAMAS DE FLUJO DE DATOS Para que de utilidad y proporcionan información los diagramas de flujo de datos deben dibujarse en forma adecuada. Esta sección muestra como dibujarlos: donde comenzar, como añadir detalles a las descripciones, cuando incorporar la información sobre el control y como mantener la consistencia al asignar los nombre s de los objetos incluidos en los diagramas. La presentación señala también errores comunes que deben evitarse. Diagramas físicos de flujo de datos Los diagramas de flujo de datos son de dos tipos: Diagramas físicos de datos Proporciona un panorama del sistema en uso, que es dependiente de la implantación, que muestra qué tareas se llevan a cabo y cómo. Las características físicas incluyen: Nombres de personas Nombre de números de formatos y documentos Nombres de departamentos Archivos maestros y de transacciones Equipo y dispositivos utilizados Ubicaciones Nombre de procedimientos Diagramas lógicos de flujo de datos Proporcionan un panorama del sistema independiente de la implantación, que se centra en el flujo de datos entre los procesos sin considerar los dispositivos específicos y la localización de almacenes de datos o personas en el sistema. En este tipo de diagramas no se indican las características físicas, lo cual si sucede con los diagramas físicos de flujo. El enfoque más amplio y útil para desarrollar una descripción exacta y completa del sistema en uso, comienza con el desarrollo del diagrama físico de flujo de datos. El empleo de estos diagramas es deseable por tres razones. Primera, es común que los analistas de sistemas encuentren mucho más fácil describir la interacción entre los componentes físicos que comprender las políticas empleadas para administrar la aplicación. Segunda, los diagramas físicos de flujo de datos son de utilidad para comunicarse con los usuarios. Éstos relacionan con facilidad a las personas, las localidades y los documentos ya que trabajan todos los días con cada entidad. (Es usual que los analistas de sistemas encuentren que los usuarios consideran "abstractos" los diagramas lógicos de flujo de datos porque no contienen componentes que les sean familiares.) Tercera, los diagramas físicos de flujo de datos proporcionan un camino para validar o verificar el punto de vista del usuario sobre la forma en que opera el sistema en uso. Si existen diferencias, éstas son anotadas y discutidas. No es poco usual encontrar que lo que un usuario piensa que está sucediendo difiere de forma importante de lo que en realidad está ocurriendo. Son estas diferencias las que probablemente expliquen los problemas o ineficiencias – quizá la razón por la que se propone un nuevo sistema. Dibujo de diagramas físicos de flujo La siguiente descripción sobre la forma como maneja una compañía su sistema de cuentas por pagar, será utilizada para el desarrollo de diagramas de flujo de datos: Dibujo del diagrama de contexto Como ya se indicó, los primeros pasos para determinar los requerimientos tienen como finalidad conocer las características generales del proceso bajo investigación. Para decirlo de algún modo, primero se estudian los detalles de la capa superior. Conforme los analistas comprenden mejor los detalles, ahondan con mayor profundidad para recopilar información más precisa y destellada. Cada vez se formulan preguntas más especificas utilizando para ello el análisis descendente (top-down). A menudo el diagrama de alto nivel se denomina diagrama de contexto. Contiene un solo proceso pero juega un papel muy importante en el estudio del sistema en uso. El diagrama de contexto define el sistema que va ha ser estudiado en el sentido de que determina las fronteras. Todo los que no se encuentre dentro de las fronteras identificadas en el diagrama de contexto del proceso no forma parte del estudio de sistemas. La forma en que funcionan las otras organizaciones o elementos externos (las fuentes y destinos) no está fuera de nuestro control y no será estudiada con detalle. No obstante, si afectan el proceso porque son fuentes o destinos, debe tener una interface, o medios para interactuar, con los elementos que están fuera de él. Desarrollo de gráficas de procesos Un sistema está formado por varias actividades o procesos. Usted ha aprendido en forma gradual aspectos pertinentes a la relación entre procesos; también ha descubierto que un proceso contiene varios pasos (procesos en pequeña escala). El la programación de computadoras, los programadores con frecuencia desarrollan el software como una colección de módulos independientes pero que interactuan entre sí. A menudo estos módulos se muestran en los diagramas de jerarquía. Estos diagramas son similares a los desaprobadores por los programadores.

Conceptos Basicos del modelo orientado a Objetos

5.1 Reconocimiento de objetos y clases en el mundo real y la interacción entre ellos En Java, un objeto se define como una estructura que encapsula atributos (características) y comportamientos (procedimientos) de una entidad con un papel bien definido en una aplicación. Cada objeto tiene: - Estado: Conjunto de valores de los atributos en un instante de tiempo dado. El comportamiento de un objeto puede modificar el estado de este. - Comportamiento: Relacionado con su funcionalidad y determina las operaciones que este puede realizar o a las que puede responder ante mensajes enviados por otros objetos. - Identidad: Es la propiedad que permite a un objeto diferenciarse de otros. Generalmente esta propiedad es tal, que da nombre al objeto. Los objetos, concretos y abstractos, están a nuestro alrededor, forman nuestro entorno. Podemos distinguir cada objeto en base a sus características y comportamientos. Por ejemplo, en un aula de clases observamos los siguientes objetos: • Alumno • Profesor • Mesa • Silla • Mesa banco • Pizarrón Interacción entre objetos: Los objetos no sólo tienen atributos relacionados con su forma física sino que, además, exhiben comportamientos específicos de su clase. • Alumno: Estudia, aprende. • Profesor: Enseña, evalúa. • Mesa: Ordenada, desordenada. • Silla: Ocupada, desocupada. • Mesa banco: Ocupado, desocupado. • Pizarrón: Pintado, borrado Observamos que en el aula hay varios objetos alumno, por lo que pensamos en el grupo de alumnos, al que denominaremos como la clase alumno. De igual manera, cada materia es impartida por un profesor; el conjunto de profesores forman la clase Profesor. Pudiéramos extender nuestro análisis al pizarrón, la mesa, la silla,, al conjunto de mesa bancos, etc. Clases: Es la definición de un objeto. Cuando se programa un objeto y se definen sus características y funcionalidades, realmente se programa una clase. 5.2 La abstracción y el encapsulamiento como un proceso natural Abstracción: Es un método por el cual abstraemos valga la redundancia, una determinada entidad de la realidad de sus características y funciones que desempeñan, estos son representados en clases por medio de atributos y métodos de dicha clase. Ejemplo: La abstracción de un automóvil. - Características: Color, año de fabricación, modelo, etc. - Métodos o Funciones: Frenar, encender, etc. A esto se le llama abstracción. En general un programa no es más que una descripción abstracta de un procedimiento o fenómeno que existe o sucede en el mundo real. - La abstracción es crucial para comprender este complejo mundo. - La abstracción es esencial para el funcionamiento de una mente humana normal y es una herramienta muy potente para tratar la complejidad. - La abstracción es clave para diseñar un buen software. Procedimientos: Proporcionó la primera posibilidad de ocultación de información. Módulos: Es una técnica que proporciona la posibilidad de dividir sus datos y procedimientos en una parte privada y una parte pública. Proporcionan un método efectivo de ocultación de la información, pero no permiten realizar instanciación, que es la capacidad de hacer múltiples copias de las zonas de datos. TADS: Un tipo abstracto de dato (TAD) es un tipo de dato definido por el programador que se puede manipular similarmente a los tipos de datos definidos por el sistema. Un tipo abstracto de dato corresponde a un conjunto (puede ser de tamaño indefinido) de valores legales de datos y un número de operaciones primitivas que se pueden realizar sobre esos valores. Para construir un tipo abstracto de dato se debe: 1.- Exponer una definición del tipo. 2.- Hacer disponible un conjunto de operaciones. 3.- Proteger los datos asociados con el tipo. 4.-Permitir instancias múltiples del tipo. Si nos concentramos en las cosas, podemos encapsular en un objeto nuestro entendimiento acerca de sus características y el comportamiento de ese objeto. Lo tratamos como una entidad definida y su comportamiento no esta disperso en nuestro diseño. Es decir, no separamos la viscosidad del aceite de su color sino creamos un objeto aceite y ponemos ambas características como característica de dicho objeto. El encapsulamiento nos permite considerar a los objetos como cajas negras: como objetos que podemos utilizar sin enfocarnos en la forma en que trabajan. Caja negra.- Un objeto en el que su comportamiento y atributos son conocidos pero no así su trabajo interno, el cual continúa siendo un misterio. Un mecánico debe saber como trabaja el motor y la transmisión de su carro, pero usted como conductor, puede usarlo sin preocuparse por estos detalles, El carro encapsula todos los detalles de las partes que lo constituyen, por lo que usted tan solo necesita conocer su interfaz: el acelerador, el freno y el volante. Si abre la caja negra de su carro y se fija en lo que hay bajo el cofre, no encontrara una masa amorfa de características, sino subobjetos simples que interactúan entre si: motor, transición, poleas, etc. Si abre alguno de estos objetos encontrará más objetos, por ejemplo, el motor esta construido por bujías, tubos, bandas, convertidores catalíticos, etc. Y cada uno de ellos contiene a su vez objetos más pequeños que cumplen con una tarea específica. Cuando el motor le da propulsión al carro, no hace todo el trabajo en un solo objeto monolítico. En vez de ello, delega a los objetos que lo constituyen una responsabilidad, A su vez, estos objetos pueden delegar responsabilidades a otro. De esta manera, el motor delega la acumulación de presión a los pistones y la responsabilidad de generar la chispa a las bujías. 5.3 La programación Orientada a Objetos (POO) y la complejidad del software La programación Orientada a objetos (POO) es una forma especial de programar, más cercana a como expresaríamos las cosas en la vida real que otros tipos de programación. Con la POO tenemos que aprender a pensar las cosas de una manera distinta, para escribir nuestros programas en términos de objetos, propiedades, métodos y otras cosas que veremos rápidamente para aclarar conceptos y dar una pequeña base que permita ver este tipo de programación. La complejidad del software se desarrolla mediante las personas que son hábiles para lo cual necesitan recopilar información necesaria es decir dominar la problemática del sistema para lo cual se ven enfocados al tratamiento del problema y después a gestionar un proceso mediante el cual desarrollaran el software y así atraves de eso podrán llevarlo a la practica hasta que atreves del usuario pueda tener la flexibilidad de probarlo, para lo cual el software y la poo tienen varias aplicaciones en la programación formando grandes estructuras de ellas En la historia de la programación ha habido varias evoluciones sucesivas. Una de las principales fue la programación estructurada, cuyo principio fundamental era dividir un programa en subprogramas más pequeños y fáciles de resolver, hasta llegar a niveles de complejidad elementales, siempre apoyándonos en la idea de ¿qué debe hacer el programa? Este método de diseño, a pesar de haber dado resultados satisfactorios, tiene limitaciones. Algunas de ellas son: • No favorece la reutilización del código. Si en la figura anterior f1 y f2 fue¬ran idénticas, este hecho seguramente pasaría desapercibido y no se comparti¬ría una única función fn. • Si dos subprogramas comparten una misma función fn reutilizando así el có¬digo que define la misma, y más adelante queremos modificar fn porque hay un cambio en uno de los subprogramas que la utilizan, la modificación afecta¬rá también al otro subprograma, razón por la que ahora tendremos que reali¬zar dos funciones. De lo expuesto se deduce que la programación tradicional se desarrolla a par¬tir de procedimientos y datos, sin delimitar qué procedimientos actúan sobre qué datos. Los datos se estructuran con el fin de que puedan ser procesados por un conjunto de procedimientos diferentes, por lo que ambos, estructuras de datos y procedimientos, están sujetos a cambios. Si la programación estructurada se interesa primero por los procedimientos y después por los datos, el diseño orientado a objetos se interesa en primer lugar por los datos, a los que se asocian posteriormente procedimientos. Esto es, ahora la ¬idea principal es ¿de qué trata el programa? Entonces se organizan los desarro¬llos alrededor de los datos manipulados, y no alrededor de las funcionalidades. Esta forma de construir el programa resulta mucho más eficaz puesto que en la vida de un programa los elementos más estables son los datos. Por lo tanto, en la programación orientada a objetos, un programa es una co¬lección de una sola entidad básica, el objeto, el cual combina los datos con los procedimientos que actúan sobre ellos. Durante la ejecución, los objetos reciben y envían mensajes a otros objetos para ejecutar las acciones requeridas. La programación orientada a objetos puede llevarse a cabo con lenguajes convencionales, pero esto exige al programador la construcción de los mecanis¬mos de que disponen los lenguajes orientados a objetos. Por ello, lo más apropia¬do es utilizar directamente un lenguaje orientado a objetos, ya que éstos soportan los mecanismos y las características que anteriormente se han expuesto, tales como objetos, clases, métodos, mensajes, herencia, etc. La herencia constituye uno de los mecanismos más potentes de la programación orientada a objetos.

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.

CICLO DE VIDA DE UN SISTEMA CLASICO Y EXPERTO

Ciclo de vida de un sistema clásico y experto CICLO DE VIDA DE UN SISTEMA CLÁSICO 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. El ciclo de vida de uns sistema clasico consta de las siguientes etapas: Investigación Preliminar: Es el analisis que se realiza para determinar si es posible realizar un sistemas y se toma en cuenta los factores tecnicos, económicos y políticos. 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, aqui se determina todas las necesidades de una determinada empresa lo cual se realiza las siguientes preguntas que nos ayudará a determinar los requirimientos. ¿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? 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. 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. 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. 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. CICLO DE VIDA DE UN SISTEMA EXPERTO El desarrollo de tales sistemas nos permitirá ofrecer soluciones técnicas más completas y alimentar nuestro conocimiento del proceso del pensamiento humano. Por esta razón, los Sistemas Expertos constituyen el nivel especializado en la representación y explotación de aplicaciones basadas en conocimiento. El ciclo de vida pretenden alcanzar metas muy concretas sujetas a revisión y corrección El ciclo de vida consiste de seis fases. Este ciclo no es fijo. Cada fase puede necesitar de varias iteracciones antes de que un sistema completo pueda ser desarrollado. 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: La fase 1. Analisis del Problema. Consiste en encontrar un problema apropiado para un sistema experto, localizar un experto para contribuir en el conocimeinto maestro, establecer un enfoque preliminar, analizar los costos y beneficios y finalmente preparar un plan de desarrollo. La fase 2. Desarrollo de prototipo de sistema. El prototipo del sistema es una versión en pequeño del sistema experto diseñado para probar supuestos sobre cómo codificar los hechos, las relaciones y el conocimiento más profundo del campo del conocimiento maestro. La fase 3. Desarrollo. El desarrollo de un sistema a escala es probablemente la etapa más compleje del esfuerzo. La estructura central de todo el sistema debe ser determinada; esta es la base de conocimientos debe extenderse a la base de conocimientos totales de manera congruente con el mundo real, y debe desarrollarse la interfase con el usuario. La fase 4. Evaluación. Cuando el experto y el ingeniero de conocimento quedan satisfechos de que el sistema está completo, puede ser probado ya contra los criterios de desempeño establecidos en etapas anteriores. Es también tiempo de de mostrar el sistema a al institución e invitar a otros expertos a probarlo y presentar nuevos casos. La fase 5. Integración del sistema. Una vez construido, el sistema experto debe ser integrado al flujo de los datos y patrones de trabajo de la institución. La fase 6. Mantenimiento del sistema. Como cualquier sistema, el ambiente en el que el sistema experto opera está en cambios continuos. Esto significa que el sistema experto debe también cambiar de manera continua.

MODELO DE PROTOTIPOS

Modelo de prototipos

El Modelo de prototipos, en Ingeniería de software, pertenece a los modelos de desarrollo evolutivo. El prototipo debe ser construido en poco tiempo, usando los programas adecuados y no se debe utilizar muchos recursos. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el cliente o el usuario final. Este diseño conduce a la construcción de un prototipo, el cual es evaluado por el cliente para una retroalimentación; gracias a ésta se refinan los requisitos del software que se desarrollará. La interacción ocurre cuando el prototipo se ajusta para satisfacer las necesidades del cliente. Esto permite que al mismo tiempo el desarrollador entienda mejor lo que se debe hacer y el cliente vea resultados a corto plazo. Etapas Plan rápido Modelado, diseño rápido Construcción del Prototipo Desarrollo, entrega y retroalimentación Comunicación Ventajas Este modelo es útil cuando el cliente conoce los objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida. También ofrece un mejor enfoque cuando el responsable del desarrollo del software está inseguro de la eficacia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debería tomar la interacción humano-máquina. La construcción de prototipos se puede utilizar como un modelo del proceso independiente, se emplea más comúnmente como una técnica susceptible de implementarse dentro del contexto de cualquiera de los modelos del proceso expuestos. Sin importar la forma en que éste se aplique, el paradigma de construcción de prototipos ayuda al desarrollador de software y al cliente a entender de mejor manera cuál será el resultado de la construcción cuando los requisitos estén satisfechos. De esta manera, este ciclo de vida en particular, involucra al cliente más profundamente para adquirir el producto. Inconvenientes El usuario tiende a crearse unas expectativas cuando ve el prototipo de cara al sistema final. A causa de la intención de crear un prototipo de forma rápida, se suelen desatender aspectos importantes, tales como la calidad y el mantenimiento a largo plazo, lo que obliga en la mayor parte de los casos a reconstruirlo una vez que el prototipo ha cumplido su función. Es frecuente que el usuario se muestre reacio a ello y pida que sobre ese prototipo se construya el sistema final, lo que lo convertiría en un prototipo evolutivo, pero partiendo de un estado poco recomendado. En aras de desarrollar rápidamente el prototipo, el desarrollador suele tomar algunas decisiones de implementación poco convenientes (por ejemplo, elegir un lenguaje de programación incorrecto porque proporcione un desarrollo más rápido). Con el paso del tiempo, el desarrollador puede olvidarse de la razón que le llevó a tomar tales decisiones, con lo que se corre el riesgo de que dichas elecciones pasen a formar parte del sistema final... Conclusiones A pesar de que tal vez surjan problemas, la construcción de prototipos puede ser un paradigma efectivo para la ingeniería del software. La clave es definir las reglas del juego desde el principio; es decir, el cliente y el desarrollador se deben poner de acuerdo en: Que el prototipo se construya y sirva como un mecanismo para la definición de requisitos. Que el prototipo se descarte, al menos en parte. Que después se desarrolle el software real con un enfoque hacia la calidad.

DIAGRAMAS HIPO

DIAGRAMAS HIPO Y WARNIER/ORR Titulo de la actividad: Diagrama HIPO y Warnier/Orr. Objetivo: Comprender el uso y forma de aplicación de este tipo de diagramas. Actividades: Leer el Texto. Producto: Desarrollar un cuadro sinóptico sobre el tema. Fecha de entrega: Martes 13 de Abril. 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.

QUE ES UML

EL LENGUAJE UNIFICADO DE MODELADO (UML)

En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción. El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad". UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc. Los principales beneficios de UML son: Mejores tiempos totales de desarrollo (de 50 % o más). Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos. Establecer conceptos y artefactos ejecutables. Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica. Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas. Mejor soporte a la planeación y al control de proyectos. Alta reutilización y minimización de costos. UML, ¿Método o Lenguaje de Modelado? UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método. Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo ¾ los símbolos utilizados en los modelos ¾ y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas (figura 1). Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son: Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos. Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema. Vista de Componentes: Muestra la organización de los componentes de código. Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente. Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos. Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución. Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología. Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario. FASES DEL DESARROLLO DE UN SISTEMA Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas. Análisis de Requerimientos UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software. Análisis La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc. Diseño En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación. Programación En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código. Pruebas Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema satisface los requerimientos y son similares a las pruebas de sistema.

Análisis y Diseño de sistemas usando UML

UML es un lenguaje gráfico para construir modelos, no guía al desarrollador en la forma de realizar buenos análisis y diseños, ni le indica cual proceso de desarrollo adoptar. La idea de esta serie de artículos va más allá de aprender la notación UML utilizada para diseñar y construir sistemas software orientados a objetos de buena calidad independiente del proceso de desarrollo utilizado. Guiará al desarrollador principiante como yo a realizar buenos análisis y diseños orientados a objetos utilizando patrones de diseño. El caso de estudio que vamos a tratar es el simulador de la cantera que he diseñado para las prácticas de la asignatura Ingeniería del software de la universidad. Voy a intentar realizarlo todo más o menos siguiendo la temática del libro UML y patrones de Craig Larman. De esta forma me sirve a mí mismo para mejorar la implementación y el diseño que realizé y afirmar todo lo aprendido. Como soy un novato principiante en este mundillo, si algún lector sigue mis artículos y encuentra alguna burrada sería recomendable que me avisara para rectificarlo. De todas formas este curso va a seguir una bibliografía recomendada así que me voy a basar en principios reales y no inventar conceptos nuevos. En este curso, aprenderemos a crear modelos conceptuales del dominio del problema al que nos enfrentamos y a representarlos mediante diagramas de clases en UML. Aprenderemos a extraer los casos de usos funcionales a partir de la especificación de requerimientos del sistema que vamos a desarrollar y a representarlos mediante diagramas de casos de uso en UML. Aprenderemos a realizar diagramas de secuencia, de colaboración y de estado en UML. Paralelamente a este curso voy a intentar redactar otros artículos dedicados exclusivamente a los patrones de diseño, esta vez sin seguir un caso de uso, sino a partir de ejemplos donde podamos aplicarlos. Este proyecto puede durar mucho tiempo, debido a que paralelamente estoy redactando otros cursillos de PHP, y MySQL que incorporar al blog. Además en unas semanas empiezo a trabajar diseñando una aplicación de gestión inmobiliaria, así que no voy a tener mucho tiempo libre. En breves os explicaré el caso de estudio y realizaremos una especificación de funcionalidades que incorporar a nuestro sistema software. La implementación la desarrollaremos en el lenguaje C#. Para este curso voy a presuponer que se tienen ciertos conocimientos de la metodología orientada a objetos, así como del lenguaje C# y de construcción de aplicaciones mediante formularios windows. No va a tener acceso a base de datos para simplificar un poco el desarrollo. Ya explicaré el sistema que realizaremos para cargar y guardar datos.

EL ROL DEL ANALISIS DE SISTEMA

El rol del analista de sistemas Análisis y diseño de sistemas

Ingeniería de Sistemas Considero que la tesis del texto “El rol del analista de sistemas” es: “Los analistas de sistemas son personas que se comunican con los directivos y los usuarios en un entorno directivo/usuario; documenta sus experiencias; comprenden los problemas antes de proponer soluciones; piensan antes de hablar; desarrollan los sistemas de información necesarios para apoyar a la organización y disfrutan trabajando con otras personas.” Básicamente, actividad del analista de sistemas es poder desempeñarse en varias situaciones y demostrar la posición que tiene y el status que debe manejar. El analista también avalúa el funcionamiento de un negocio, mediante el examen de entradas, el procesamiento de datos y la producción de información tratando de mejorar los procesos internos y externos de una organización. El analista debe poseer la capacidad de tratar con todo tipo de personas y obviamente tener muchos conocimientos y demasiada experiencia en computadores, al igual que ser capaz de desenvolverse en diferentes roles y algunas veces al mismo tiempo. El analista debe saber hacer tres tareas básicas: 1. Consultor extremo para negocios, que le permite tener la capacidad de visualizar el medio externo en el que se desenvuelve el negocio para permitirle su permanencia en el medio. 2. Experto de soporte dentro de un negocio, que le permite ser esa ayuda idónea dentro del negocio para que este pueda mantenerse a flote. 3. Agente de cambio en situaciones tanto internas como externas, que le permite tener las ideas frescas y posibles de realizar en el momento necesario de solucionar dicho problema. El analista debe tener muchas habilidades y poder dividirlas en cada fase secuencial, pero a la vez esas fases están interconectadas. Algunas de esas habilidades ya las he comentado antes, pero hay algunas otras como: debe tener conocimientos generales de la empresa

PROTOTIPO

Prototipo La palabra prototipo tiene varios tipos de definiciones: Un Prototipo es un ejemplar o primer molde en que se fabrica una figura u otra cosa. Un prototipo perfecto y modelo de una virtud, vicio o cualidad. Un prototipo también se puede referir a cualquier tipo de máquina en pruebas, o un objeto diseñado para una demostración de cualquier tipo. Un prototipo o prototipado puede ser un modelo del ciclo de vida del software, tal como el desarrollo en espiral o el desarrollo en cascada. Un prototipo de belleza es aquel modelo que en función de la historia ha ido variando sobre como ha debido de ser el cuerpo de las personas, tanto en su forma como en su vestimenta. Éstos permiten testar el objeto antes de que entre en producción, detectar errores, deficiencias, etcétera. Cuando el prototipo está suficientemente perfeccionado en todos los sentidos requeridos y alcanza las metas para las que fue pensado, el objeto puede empezar a producirse. Métodos y herramientas para el desarrollo de prototipos Técnicas de cuarta generación: Estas comprenden una amplia gama de lenguajes de consulta y de otros lenguajes ideales para la creación rápida de prototipos. Componente de software reutilizables: El ensamblar más que el construir, es un prototipo mediante software existente. Un componente de software puede ser una estructura de datos o un componente arquitectónico. En pocas palabras un software existente que cumpla con los requisitos del cliente. Especificaciones formales y entornos para prototipos: Durante las pasadas dos décadas, se han desarrollado varios lenguajes formales de especificación y herramientas como sustitutos de las técnicas de especificación con lenguaje natural. Hoy en día los desarrolladores de estos lenguajes formales están desarrollando entornos interactivos que: Permitan al analista crear interactivamente una especificación basada en lenguaje de un sistema o software. Invoque herramientas automáticas que traducen la especificación basada en el lenguaje de código ejecutable. Permitan al cliente usar el código ejecutable del producto para refinar los requisitos formales. Métodos y herramientas para el desarrollo de los prototipos, para la selección de un enfoque apropiado de creación de prototipo.feoarmandollos Metrología En la ciencia y práctica de metrología, un prototipo es un objeto fabricado por el humano que se usa como un estándar de medida de alguna magnitud física contra la que medir sus cantidades físicas. En el Sistema Internacional de Unidades (SI), el único prototipo que aún se usa es el prototipo internacional de Kilogramo, un cilindro sólido de platino e iridio guardado en el Bureau International des Poids et Mesures en Sèvres, un barrio de París (Francia); que por definición es la masa de un kilogramo. Muchas naciones realizan copias de este prototipo para representar el estándar nacional del kilogramo, y lo comparan periódicamente con sus copias. Hasta 1960, el metro se definía mediante un prototipo consistente en una barra de platino-iridio con dos arañazos en él, separados por definición un metro. En 1983 el metro fue redefinido como la distancia en el espacio cubierta por la luz en un 1/299,792,458 de segundo. Todo el mundo considera que el prototipo de estándar de kilogramo será reemplazado por una definición de kilogramo que se defina en base a otra constante física, eliminando la necesidad de un prototipo que cambia ligeramente de peso todos los años por ganar o perder átomos.

ANÁLISIS Y DISEÑO DE SISTEMAS El Análisis y el Diseño de sistema, tienen como fin estudiar sistemáticamente la operación de ingreso de los datos, el flujo de los mismos y la salida de la información; todo ello dentro del contexto de una empresa en particular. ANÁLISIS ESTRUCTURADO El Análisis Estructurado es un método para el análisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener la comprensión completa y exacta de una situación dada. Componentes: - Símbolos gráficos: Son los iconos y convenciones para identificar y describir los componentes de un sistema y las relaciones entre estos. - Diccionarios de datos: Descripciones de todos los datos utilizados en el sistema. Puede ser manual o automatizado. - Descripciones de procesos y procedimientos: Declaraciones formales que emplean técnicas y lenguajes que permiten describir actividades importantes que forman parte del sistema. - Reglas: Estándares par describir y documentar el sistema en forma correcta y completa. DISEÑO ESTRUCTURADO El Diseño Estructurado es una técnica específica que busca crear programas formados por módulos independientes unos de otros desde el punto de vista funcional y no mostrar la lógica de los programas. La herramienta fundamental del diseño estructurado es el diagrama estructurado, el cual describe la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él. ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS La Orientación a Objetos puede describirse como el conjunto de disciplinas que desarrollan y modelizan software que facilitan la construcción de sistemas complejos a partir de componentes. El atractivo intuitivo de la orientación a objetos es que proporciona conceptos y herramientas con las cuales se modela y representa el mundo real tan fielmente como sea posible. Características Principales del Enfoque Orientado a Objetos - Identidad: Los datos se organizan en entidades discretas y distinguibles llamadas objetos. Estos objetos pueden ser concretos o abstractos, pero cada objeto tiene su propia identidad. - Clasificación: Los objetos que tengan los mismos atributos y comportamiento se agrupan en clases. Una clase es una abstracción que describe propiedades (atributos y comportamiento) relevantes para una aplicación determinada, ignorando el resto. - Polimorfismo: El polimorfismo permite que una misma operación pueda llevarse a cabo de forma diferente en clases diferentes. - Herencia: El concepto de herencia se refiere al compartir de atributos y operaciones basadas en una relación jerárquica entre varias clases. Una clase puede definirse de forma general y luego refinarse en sucesivas subclases. Cada clase hereda todas las propiedades (atributos y operaciones) de su superclase y añade sus propiedades particulares. DIFERENCIAS Análisis y Diseño Estructurado Análisis y diseño Orientado a Objetos El análisis estructurado se basa fundamentalmente en la descomposición funcional del sistema que se desea construir, lo cual requiere comprender primero el dominio del problema y a continuación documentar las funciones y subfunciones que debe proporcionar el sistema. El enfoque Orientado a Objetos invierte el método estructurado, se centra en primer lugar en identificar los objetos del dominio de aplicación y después en establecer procedimientos que los manejen. El software desarrollado con métodos estructurados suele ser más frágil ante los cambios de requisitos; pues si estos cambian, un sistema basado en descomposición funcional puede requerir una reestructuración masiva. El software Orientado a Objetos se mantiene mejor ante los cambios de requisitos, porque se basa en la estructura subyacente del dominio de aplicación por lo que las modificaciones necesarias pueden ser más fácilmente localizables. El Análisis Estructurado modela los sistemas desde un punto de vista más próximo a su implementación en un ordenador (entrada/proceso/salida). El Análisis Orientado a Objetos se basa en modelar el sistema mediante los objetos que forman parte de él y las relaciones estáticas (herencia y composición) o dinámicas (uso) entre estos objetos. Este enfoque pretende conseguir modelos que se ajusten mejor al problema real. El análisis estructurado incorpora modelos de datos, de procesos y de comportamiento. El enfoque Orientado a Objetos, utiliza los mismos modelos que el análisis estructurado. Las diferencias principales consisten en la mayor importancia que se da al modelo de datos, por encima de los otros dos, y en el enfoque orientado a objetos de este modelo. El modelado de datos mediante el enfoque estructurado, está más orientado al diseño de bases de datos y se centra exclusivamente en la identificación de los datos que maneja un sistema y en las relaciones estáticas que se establecen entre esos datos. En el AOO, los objetos encapsulan tanto atributos como procedimientos (operaciones que se realizan sobre los objetos), e incorpora además conceptos como el polimorfismo o la herencia que facilitan la reutilización de código. El uso de AOO puede facilitar mucho la creación de prototipos, y las técnicas de desarrollo evolutivo de software. Ciclo de vida clásico del desarrollo del sistema. 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 eluso de un ciclo especifico de actividades del analista y del usuario. Según James Senn (1999), 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 tiene un uso amplio en cada una de los diversos tipos de empresas que existen, y resultan efectivas si son aplicadas de manera adecuada. Para esta se utilizara el desarrollo del ciclo de vida clásico, donde el autor en cuestión dice lo siguiente: 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 e46 Implantar un sistema de información. El método del ciclo de vida para el desarrollo de sistemas consta de 6 fases las cuales son las siguientes: 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. Esta etapa tiene tres partes fundamentales: Aclaración de la situación. Muchas de las solicitudes que provienen de empleados y usuarios no están formuladas de manera clara. El analista del sistema debe examinarla con precisión para determinar lo que el solicitante desea es decir; antes de seguir adelante, la solicitud del proyecto debe estar claramente planteada. Estudio de factibilidad. Un resultado importante de la investigación preliminar es la determinación de que el sistema solicitado sea factible. El estudio de factibilidad lo lleva a cabo un pequeño equipos de personas que esta familiarizado con técnicos de sistemas de información, dicho equipo comprende la parte de la empresa u organización que participara o severa beneficiada por el proyecto, y son personas expertas en los procesos de análisis y diseño de sistemas. En general las personas que son responsables de evaluar la factibilidad son analistas capacitados y directivos. Aprobación de la solicitud. No todos los proyectos solicitados son deseables o factibles. Algunas organizaciones reciben tantas solicitudes de sus empleados que solo es posible entender unas cuantas, sin embargo aquellos proyectos que son deseables y factibles deben incorporarse en los planes; muchas organizaciones desarrollan sus planes para47 sistemas de información con el mismo cuidado con el que planifican nuevos productos y programas de fabricación o la expansión de sus instalaciones. Luego de aprobar la solicitud de un proyecto se estima su costo, el tiempo necesario para panificarlo y las necesidades de personal. 2. Determinación de los requerimientos. 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 la misma 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? Entre otras. Además conforme se reúnen los detalles este se encarga de estudiar los datos con la finalidad de identificar las características operacionales de un sistema tales como controles de procesamiento, tiempos de respuestas y métodos de entrada y salida. 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 de desarrollo del software, a la que denominan diseño fisco. Los analistas de sistemas comienzan el proceso de diseño identificándolos reportes y demás salidas que debe producir el sistema. Echo lo anterior se determinan con toda precisión los datos específicos para cada reporte de salida. Es común que los diseñadores hagan un bosquejo del formato o pantalla que esperan que aparezcan cuando el sistema