Taller # 3

Taller # 3
“Metodologías para Desarrollo de Sistemas”
Análisis Comparativo entre diversas Metodologías para Desarrollo de Sistemas de Información.
Presentado Por: Román Bordones; Dídimo Higuera; Franklin South
Metodología: Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.
Tipos de metodologías:
Estructuradas
Orientadas a Procesos
Orientadas a datos
Jerárquicas
No Jerárquicas
Mixtas,
Orientadas a Objetos Para Sistemas de Tiempo Real
Metodologías Estructuradas
Metodologías estructuradas: Crea los modelos de forma descendente. Son las orientadas a procesos, a datos y las mixtas. Intentan aplicar formas ingenieriles para solucionar problemas técnicos al obtener un sistema de información, proponen la creación de modelos, flujos y estructuras mediante un top-down. La metodología orientada a procesos está fundamentada sobre el modelo entrada-proceso-salida., aplica un proceso interactivo para lograr un refinamiento progresivo; se compone de DFDs que representan procesos y datos, DDs donde se definen los datos y especificaciones del proceo donde se define cómo se obtienen las salidas a partir de las entradas. La metodología orientada a datos se divide en jarárquica y no jerárquica, la jerá rquica está orientada a las entradas y salidas, primero van las estructuras de datos y después se derivan los procesos; las no jerá rquicas definen un sistema a partir de la información que este maneja. La metodología estructurada mixta estudian los sistemas desde varios puntos de vista. La metodología orientada a objetos el modelado del sistema se concibe como conjunto de objetos que interactúan entre sí y se busca el enfoque unificador de los objetos.

Requisito: condiciones que debe tener un sistema para satisfacer un contrato, una norma o especificación y condición que un usuario necesita para resolver un problema.
Especificación: Es un documento que define los requisitos, el diseño y el comportamiento u otras características de un sistema.
Análisis da viabilidad: los aspectos a tener en cuenta son: económicos (determinan si el proyecto va a ser rentable), técnico (estudia si la funcionalidad y los factores marcados del proyecto son factibles), legales (se discute si ls requisitos atentan contra la ley) y operativo (determina si el sistema se puede implantar de forma efectiva en la empresa).
Atributos del Software: Características: proyecto lógico, se deteriora, pobre reutilización. Atributos de calidad: fiable, eficiente, robusto,correcto...
Método Demarco:
Construir el modelo físico, Actual (DFD físico actual), Construir el modelo lógico, Actual (DFD lógico actual), Crear un conjunto de modelos Físicos alternativos, Estimar los costes y tiempos De cada opción, Seleccionar un modelo, Empaquetar la especificación
Este documento tiene como objeto guiar a las partes en proyectos de cooperación sobre los procedimientos que deben adoptar en la planificación de los mismos. El método de marco lógico es un instrumento que ayuda a los organismos y agencias de cooperación a mejorar la planeación, implementación, seguimiento y valoración de los proyectos de desarrollo que emprenden.

La guía comienza por explicar los propósitos, definiciones, pasos y roles que se tienen al realizar un análisis de marco lógico. Para ayudar a evitar errores durante este proceso, se presenta una guía de taller de planificación y se analizan las ventajas que brinda este método. Ejemplos prácticos se anexan así como un análisis de riesgo paso a paso y una lista de “preguntas lógicas”.
Método de Gane y Sarson
Construir el modelo lógico actual (DFD lógico actual), Construir el modelo del nuevo Sistema, elaborar una especificación Estructurada y construir un modelo Lógico de datos en tercera forma Normal que exprese el contenido de Los almacenes de datos. Seleccionar un modelo lógico, Crear el nuevo modelo físico del sistema Empaquetar la especificación
Metodología de Yourdon/Constantine
Realizar los DFD del sistema Realizar el diagrama de estructuras Evaluar el diseño Preparar el diseño para la implantación La estructura de control del programa debe ser jerárquica y se debe derivar de la estructura de datos del programa. El proceso de diseño consiste en definir primero las estructuras de los datos de entrada y salida, mezclarlas todas en una estructura jerárquica de programa y después ordenar detalladamente la lógica procedimental para que se ajuste a esta estructura
El diseño lógico debe preceder y estar separado del diseño físico. Metodología Ingeniería de la Información.
Planificación: construir una arquitectura de la Información y una estrategia que soporte los objetivos de la organización Análisis: comprender las áreas del negocio y determinar los requisitos del sistema Diseño: establecer el comportamiento del sistema deseado por el usuario y que sea alcanzable por la tecnología Construcción: construir sistemas
y que sea alcanzable por la tecnología Construcción: construir sistemas que cumplan los tres niveles anteriores.
Metodologías Orientadas a Objetos
“Revolucionarios” o “puros”“Sintetistas” o “evolutivos
Se examinan los sistemas desde las funciones o tareas que deben realizar, que se descomponen sucesivamente en tareas más pequeñas para formar los módulos de la aplicación.
En OO cobra importancia del modelado del sistema examinando el dominio del problema como un conjunto de objetos que interactúan entre sí. En xxx se produce una dicotomía entre función y datos. En OO se propugna un enfoque: unificar de ambos aspectos que se encapsulan en los objetos
El modelo y diseño orientado a objetos u OMT( técnica de modelado de objetos ) se extiende desde el análisis hasta la implementación pasando por el diseño . Actualmente es una de las metodologías mas implantadas.
Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de compartimiento especifico.
Los propios objetos se pueden constituir a partir de otros , que a su vez pueden estar formados por otros objetos .Esto nos recuerda a una maquina compleja construida por partes , subpartes y sub-subpartes,etc.
La metodología de desarrollo de software orientada a objetos es cada día más usada, pues permite desarrollar software fácilmente extensible y reusable. Esto último es sólo posible si los desarrolladores conocen muy bien los fundamentos que esté basada esta metodología. Por eso, este curso revisa los conceptos más importantes que se encuentran en las distintas etapas del desarrollo de software orientado a objetos.
El curso parte dando a conocer la base del diseño y programación de buenas clases, tanto por si solas como a través del uso de herencia. Luego introduce el concepto de subtipos, como concepto teórico que está detrás de las distintas implementaciones de herencia que proveen los lenguajes y provee el marco conceptual de cuando usar referencia. Más tarde presenta el proceso de desarrollo de software orientado a objetos, primero enfocado en la etapa de diseño, en donde se dan a conocer las distintas relaciones entre clases que podemos encontrar, provee mecanismos para verificar si una clase y las relaciones entre ellas están bien diseñadas, y en particular si la herencia está bien usada.
Metodologías para sistemas de tiempo real
Manejo de interrupciones, Comunicación y sincronización entre tareas, Gestión de procesos concurrente, Respuesta oportuna ante eventos externos, Datos continuos o discretos. Se está produciendo una evolución de las metodologías orientadas a objetos para desarrollos de sistemas de tiempo real.
La previsión consiste en que los sistemas de tiempo real serán una tecnología de base para desarrollar sistemas de control empotrados con una serie de características comunes. Serán autónomos, en el sentido que tendrán prefijadas sus funciones y las realizarán sin intervención humana directa. Para ser capaces de realizar estas funciones, será imprescindible disponer de sistemas sensoriales avanzados que les permitan conocer el estado de los elementos del entorno, según sea necesario. Dispondrán de capacidades de comunicación inalámbricas, lo que les permitirá comunicarse con los humanos, entre ellos y con centros avanzados de control. Tendrán capacidades de aprendizaje y de adaptación a entornos cambiantes. Los dispositivos generales descritos tendrán una aplicación específica en distintos campos, que se analizan a continuación con algo más de detalle.


Escoger la metodología que se adapte al caso de estudio seleccionado por cada grupo para la presentación del informe de fin de semestre sobre el análisis y diseño de sistemas de información.


Anexo
Método de la cascada pura
En un modelo en cascada, un proyecto progresa a través de una secuencia ordenada de pasos partiendo de la especificación de requerimientos hasta el mantenimiento del mismo.
El método realiza una revisión al final de cada etapa para determinar si está preparado para pasar a la siguiente etapa, por ejemplo, desde el análisis de requerimientos hasta el diseño.
Cuando la revisión determina que el proyecto no está listo pasar a la siguiente, permanece en la etapa actual hasta que esté preparado.
El modelo en cascada está dirigido por documentos.
Ayuda a localizar errores en las primeras etapas del proyecto a un bajo costo.
Ayuda a minimizar los gastos de la planificación porque permite realizarla sin planificación porque permite realizarla sin problemas.
Funciona especialmente bien si se dispone de personal poco cualificado o dispone de personal poco cualificado o inexperto, porque presenta el proyecto inexperto, porque presenta el proyecto con una estructura que ayuda a minimizar con una estructura el esfuerzo inútil.

En resumen, los inconvenientes del venerado modelo en cascada hacen que sea, a menudo, un modelo poco apropiado para un proyecto de desarrollo rápido. Incluso en los casos en los que las ventajas del modelo en cascada pura superan los inconvenientes, los modelos de cascada modificada (con retroceso) pueden funcionar mejor.
Las desventajas del modelo se centran en las dificultades para especificar claramente los requerimientos al comienzo del proyecto, antes de que se realice ningún trabajo de diseño y antes de escribir ningún código.
No proporciona resultados tangibles en forma de software hasta el final del ciclo de forma de software del ciclo de vida de Algunas herramientas, métodos y actividades que abarcan varias etapas de la cascada; estas actividades son difíciles de ajustar en las etapas discontinuas del modelo para un proyecto de desarrollo rápido, el modelo en cascada puede suponer una cantidad excesiva de documentación.
Método espiral
Es un modelo de ciclo de vida orientado a riesgos que divide un proyecto software en mini-proyectos.
Cada mini proyecto se centra en uno o más riesgos importantes hasta que todos estén controlados.
Después de controlar todos los riesgos más importantes, el modelo en espiral finaliza del mismo modo que el ciclo de vida en cascada
Funcionamiento:
Se parte de una escala pequeña en medio de la espiral, se localizan los riesgos, se genera un plan para manejar los riesgos, y a continuación se establece una aproximación a la siguiente interacción.
Cada iteración supone que el proyecto pasa a una escala superior. Se avanza un nivel en el Espiral, se comprueba que se tiene lo que se desea, y después se comienza a trabajar en el siguiente nivel:
Con cada iteración a través del espiral se construye sucesivas versiones de software cada vez más completas. En cada bucle alrededor del espiral, la culminación del análisis de riesgo resulta una decisión de “seguir” o “no seguir”.
Cada interacción en el método espiral lleva consigo los seis pasos que a continuación se nombran: Determinar objetivos, alternativas y límites, Identificar y resolver riesgos, Evaluar alternativas,
Generar las entregas de esa iteración, y comprobar que son correctas.
En el modelo en espiral, las primeras iteraciones son las menos costosas.
Supone menos gasto desarrollar el concepto de operación que realizar el desarrollo de los requerimientos, y también es menos costoso desarrollar los requerimientos que llevar a cabo el desarrollo del diseño, la implementación del producto y la prueba del mismo.
En cada Cuadrante del Método espiral se realiza las siguientes actividades:
Planificación:
Determinación de objetivos, alternativas, restricciones, y elaboración del plan de desarrollo para el ciclo actual.
Análisis de Riesgos:
Evaluación de las alternativas, identificación y resolución de riesgos. Se decide si se sigue o no con el proyecto
Ingeniería:
Desarrollo del producto siguiendo un modelo: del ciclo de vida o cascada, prototipo, etc. Evaluación por el cliente, Valoración de resultados.
Método de codificar y Corregir
(Code-and-fix)
Es un modelo poco útil, pero sin embargo bastante común Se puede tener una especificación formal, o no tenerla Si no se ha utilizado formalmente un método, probablemente ya se esté usando el método Codificar y Corregir en forma intuitiva Cuando se utiliza éste método se empieza con una idea general de lo que se necesita construir, Se utiliza cualquier combinación de diseño, código, depuración y métodos de prueba no formales que sirven hasta que se tiene el producto listo para entregarlo.
Ventajas:
No conlleva ninguna gestión; no se pierde tiempo en la planificación, en la documentación, en el control de calidad, en el cumplimiento de los estándares, o en cualquier otra actividad que no sea codificación pura.
Como se pasa directamente a codificar, se pueden mostrar inmediatamente indicios de progreso.
Requiere poca experiencia: cualquier persona que haya escrito alguna vez un programa está familiarizada con éste modelo.
Para proyectos pequeños que se intentan liquidar en un tiempo breve, o para modelos como programas de demostración o prototipos desechables, el modelo codificar y corregir puede ser útil.
Desventajas:
El modelo resulta peligroso para otro tipo de proyectos que no sean pequeños.
Puede que no suponga gestión alguna, pero tampoco ofrece medios de evaluación del progreso.
No proporciona medios de evaluación de la calidad o de identificación de riesgos.
Si al llevar tres cuartas partes de la codificación descubre que el diseño es incorrecto, no hay otra solución que desechar el trabajo y comenzar de nuevo.

Método Prototipo
Este método hace que el usuario participe de manera más directa en la experiencia de análisis y diseño que cualquiera de los ya presentados. La construcción de prototipos es muy eficaz bajo las circunstancias correctas. Sin embargo, al igual que los otros métodos, el método es útil sólo si se emplea en el momento adecuado y en la forma apropiada.
¿Qué es un prototipo?
El prototipo es un sistema que funciona, no solo una idea en el papel, desarrollado con la finalidad de probar ideas y suposiciones relacionadas con el nuevo sistema. Al igual que cualquier sistema basado en computadora, está constituido por software que acepta entradas, realiza cálculos, produce información ya sea impresa o presentada en una pantalla, o que lleva a cabo otras actividades significativas. Es la primera versión, o iteración, de un sistema de información.
Lo usuarios evalúan el diseño y la información generada por el sistema. Lo anterior sólo puede hacerse con efectividad si los datos utilizados, al igual que las situaciones, son reales. Por otra parte, deben esperarse cambios a medida que el sistema es utilizado.
Razones para desarrollar prototipos de sistemas:
Los requerimientos de información no siempre están bien definidos. Es probable que los usuarios conozcan sólo ciertas áreas de la empresa donde se necesiten mejoras o cambios en los procedimientos actuales. También es posible que reconozcan la necesidad de tener mejor información para administrar ciertas actividades pero que no estén seguros cual de esta información será la adecuada. Los requerimientos del usuario pueden ser demasiado vagos aun al formular el diseño. En otros casos, es probable que una investigación de sistemas bien llevada necesite del desarrollo de nueva tecnología.
Los prototipos permiten evaluar situaciones extraordinarias donde los encargados de diseñar e implantar sistemas no tienen información ni experiencia, o también donde existen situaciones de riesgo y costo elevados, y aquellas donde el diseño propuesto es novedoso y aún no se demuestra es la factibilidad de que los vendedores envíen ordenes de pedido al sistema de cómputo de la compañía desde el sitio donde efectúan la operación por medio de terminales portátiles enlazadas a teléfonos públicos. Para probar el concepto los administradores y encargados de sistemas pueden optar por construir una versión en pequeña escala del software, adquirir unas cuantas terminales y seleccionar un grupo de vendedores. El prototipo proporcionará información preliminar sobre la funcionalidad del concepto.
El prototipo es, en realidad, un modelo piloto o de prueba, en general, los analistas de sistemas encuentran que los prototipos tienen mayor utilidad bajo las siguientes condiciones:
• Los encargados de diseñar e implantar sistemas nunca han desarrollado uno con las características del sistema propuesto.
• Se conoce sólo una parte de las características esenciales del sistema; las demás no son identificables a pesar de un cuidadoso análisis de requerimientos.
• La experiencia con el uso del sistema añadirá una lista significativa de requerimientos que el sistema debe satisfacer.
• Las diferentes versiones del sistema evolucionan con la experiencia al igual que el desarrollo adicional y el refinamiento de sus características.
• Los usuarios del sistema participan en el proceso de desarrollo.
Los pasos a seguir en el proceso de desarrollo de prototipos son los siguientes:
• Identificar los requerimientos de información que el usuario conoce junto con las características necesarias del sistema.
• Desarrollar un prototipo que funcione.
• Utilizar el prototipo anotando las necesidades de cambios y mejoras. Esto expande la lista de los requerimientos de sistemas conocidos.
• Revisar el prototipo con base en la información obtenida a través de la experiencia del usuario.
• Repetir los pasos anteriores las veces que sea necesario hasta obtener5 un sistema satisfactorio.
Él analista debe de reunirse con los usuarios una o dos veces con la finalidad de identificar los requerimientos. El resultado de estas reuniones forma la base para la construcción del prototipo.
El desarrollo de un prototipo que funcione es responsabilidad del analista de sistemas, cuando el analista y el usuario deciden que cuentan ya con la suficiente información proveniente del proceso de construcción del prototipo, determinan cómo satisfacer los requerimientos ya identificados. En general se opta por una de las siguientes opciones:
• Volver a desarrollar el prototipo. Esta alternativa quizá signifique volver a programar por completo, empezando desde el principio.
• Implantar el prototipo como sistema terminado La eficiencia en el funcionamiento junto con los métodos para interactuar con el usuario son suficientes; esto permite utilizar el sistema tol como está.
• Abandonar el proyecto. En este caso el prototipo ha proporcionado información suficiente para demostrar que no es posible desarrollar el sistema para satisfacer los objetivos deseados dentro del marco de la tecnología existente o de lineamientos económicos u operacionales.
• Iniciar otra serie de construcción de prototipos. La información ganada con la experiencia sugiere ya sea un enfoque totalmente distinto o características contrastantes.
Cada una de estas opciones se considera como un éxito en el proceso de la construcción de prototipos.
Métodos para el desarrollo de prototipos
Con los prototipos la velocidad de desarrollo es más importante que la eficiencia en el procesamiento. Un sistema prototipo se construye con rapidez, los sistemas prototipo pueden desarrollarse con métodos y lenguajes de programación convencionales, quizá falten los controles de entrada y procesamiento y, en general, la documentación del sistema es un punto que suele evitarse. Lo importante es ensayar ideas y generar hipótesis relacionadas con los requerimientos y que la eficiencia y perfección alcanzadas.
La industria de computadora busca continuamente generadores de aplicaciones, programas que sirven para generar otros programas, para apoyar los esfuerzos de la construcción de prototipos. En algunos casos, aquellos donde el sistema será utilizado con poca frecuencia, el prototipo puede, de hecho, convertirse en el sistema terminado.


Bibliografía

www.slideshare.net/.
www.gestrategica.org/templates/listado_recursos.php?.
http://www.ati.es/novatica/2000/145/alealo-145.pdfc
www.ocw.upm.es
www.es.wikipedia.or.

Tarea # 2

Integrantes: fecha: 15/9/10
Didimo Higuera
Franklin south
Román Bordones
Luis Espino
prof. Virginia Juárez

1. Resalte a través de un medio impreso o digital en su Facultad o en la Universidad, o en el ciberespacio de la información "El Papel del Analista de Sistemas".
2. Escoger una empresa local a la cual se le debe realizar el análisis de su sistema de información. Elaborar un mapa de procesos donde se plasme el flujo general que sigue la información en el sistema de información seleccionado. Considere:
Flujo de procesos.
Requerimientos del sistema.
Información recolectada de los actores que intervienen en el sistema.
3. Invite a sus compañeros de clases y a profesores a que opinen acerca de su informe y retroalimenten el mismo para enriquecer su contenido.

Criterios de Evaluación.

a.) La valoración del producto final del informe de análisis realizado a la empresa seleccionada teniendo en cuenta que cumpla con todos las secciones que debe contener un informe
b.) Lista de chequeo para el mapa de procesos.

Desarrollo



1. El trabajo de un analista de sistema, es de analizar las necesidades, solicitudes, los requerimientos que necesita un cliente o usuario para que el sistema que se le está desarrollando funcione adecuadamente, y eficientemente como el mismo lo requiera. En base a ese análisis de las necesidades del cliente o persona al cual le está haciendo un sistema, se hace diversos documentos, como tablas, datos que se van a necesitar, estructuras que se van usar, el tiempo que va a llevar construir el producto necesario que cubra con dichos requerimientos, y eso le va a servir al cliente, para ver si realmente uno plasmo lo que el quería y para los desarrolladores para que puedan construir el sistema de acuerdo a los parámetros que solicito el usuario.

En Resumen lo que hace es analizar, desmenuzar, investigar las necesidades que tiene un usuario un cliente, en su negocio (ya sea una empresa, personalmente), para que pueda construirse un sistema (un producto ya sea en una plataforma, lenguaje determinado, arquitectura que se va a consensuar con el cliente) que le vaya a cubrir eficientemente los requerimientos e inquietudes del usuario.


Los roles principales de los analistas de sistemas son:
•Ser consultores externos a los negocios.
•Ser expertos de soporte técnico en un negocio.
•Ser agentes del cambio.

Habilidades
•Comunicación.
•Ética.
Empatía
ROLES DEL ANALISTA DE SISTEMAS

El analista de sistemas evalúa de manera sistemática el sistema de un negocio mediante el examen de la entrada y el procedimiento de datos y su consiguiente producción de información., con el propósito de mejorar los procesos de una organización. Muchas mejoras incluyen un mayor apoyo a las funciones de negocios a través del uso de sistemas de información computarizados. Esta definición pone énfasis en un enfoque sistemático y metódico para analizar, y en consecuencia mejorar, lo que sucede en el contexto específico creado por un negocio.

El analista debe tener la capacidad de trabajar con todo tipo de gente y contar con suficiente experiencia en computadoras. El analista desempeña diversos roles, en ocasiones varios de ellos al mismo tiempo. Los tres roles principales del analista de sistemas son: el de consultor, experto en soporte tecnico, y agente de cambio.

EL ROL DE CONSULTOR DEL ANALISTA DE SISTEMAS

Con frecuencia, el analista de sistemas desempeña el rol de consultor para un negocio y, por tanto, podría ser5 contratado de manera especifica para enfrentar los problemas de sistemas de información de una empresa. Esta contratación se puede traducir en una ventaja porque loas 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. En su función de consultor externo, usted dependerá en gran medida de los métodos sistemáticos PATRA analizar y diseñar sistemas de información apropiados para una empresa en particular. Además, tendrá que apoyarse en los usuarios de los sistemas de información para entender la cultura organizacional desde la perspectiva que tienen ellos.

EL ROL DE EXPERTO EN SOPORTE TECNICO DEL ANALISTA DE SISTEMAS

Otro rol que tendrá que desempañ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 e l hardware y software de computo y al uso que se le da en el negocio. Con frecuencia, este trabajo no implica un proyecto completo de sistemas, sino mas bien la realización de pequeñas modificación es o la toma de decisiones que se circunscriben a un solo departamento.
Como experto de soporte técnico, usted no esta a cargo del proyecto; tan solo actúa como recurso para aquellos que si los están. Si usted es un analista de sistemas contratado por una empresa de manufactura o servicios, gran parte de sus actividades podrían ajustarse a este rol.

EL ROL DE AGENTE DE CAMBIO DEL ANALISTA DE SISTEMAS

El rol mas 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 cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo de sistemas y esta presente en la empresa durante un largo periodo (de dos semanas a más de un año). 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.

Su presencia en el negocio inicia el cambio. Como analista de datos, usted debe estar conciente de este hecho y utilizarlo como punto de partida para su análisis. De ahí que tenga que interactuar con los usuarios y la administración (si no son uno solo y el mismo) desde el principio de su proyecto. Sin su colaboración usted no podría comprender lo que ocurre en una organización y el cambio real nunca se daría.
Si el cambio (es decir las mejoras al negocio que se pueden concretar mediante los sistemas de información) parece factible después de efectuar el análisis, el siguiente paso es desarrollar un plan para el cambio de manera conjunta con quienes tienen la facultad de autorizarlo. Una vez que se haya alcanzado el consenso acerca de los cambios por realizar, usted tendrá que interactuar constantemente con quienes vayan a cambiar.
En su calidad de analista de sistemas 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 solo afectan a este sino que provocan cambios en el resto de la organización.

Mapa de Procesos
Definición El mapa de procesos ofrece una visión general del sistema de gestión.
1) Identificar quienes son los dueños, los clientes y los proveedores
Dueños: Carlos Cham S.A , Clientes: Mario espinali, Susana González, Probadores Manuel castillo, José calderón
2) Plantear cual es el objetivo a alcanzar
Brindar buen de servicio de calidad al cliente, incrementar las ventas y ganancias, sistematizar el negocio o empresa.
3) Que y quien da impulso al proceso
El sistema informático, La Administración Pública, La gerencia
4) Cuales son los elementos de entrada del proceso
El inventario de todo el código fuente y copias de reserva, son categorizados por sistema y subsistema
Asignación de identificadores únicos del sistema y del subsistema de 5 dígitos.
Acceso al programa y la copia del código fuente .Terminación del análisis ambiental

El sistema informático, La Administración Pública, La gerencia
5) Como y a través de quien (responsable) y con quien (interrelaciones) se ejecuta el proceso.
El sistema informático, La Administración Pública, La gerencia, equipo de ventas.
5) Cuales son los resultados del proceso (salidas).
Brindar buen servicio al cliente, incrementar las ventas y ganancias, sistematizar el negocio o empresa. Mapa de procesos:



1) Un requerimiento funcional puede ser una descripción de lo que un sistema debe hacer. Este tipo Brindar buen servicio al cliente, incrementar las ventas y ganancias, sistematizar el negocio o empresa. De requerimiento específica algo que el sistema entregado debe ser capaz de realizar.
Empresa mayorista



Brindar buen servicio de calidad al cliente, incrementar las ventas y ganancias, sistematizar el negocio o empresa.
2) Un requerimiento no funcional: de rendimiento, de calidad, etc.; especifica algo sobre el propio sistema, y cómo debe realizar sus funciones. Algunos ejemplos de aspectos solicitadles son la disponibilidad, el testeo, el mantenimiento, la facilidad de uso, etc.


Determinar la complejidad, estructura y los grados de defecto por programa, subsistema y sistema Extrapolando la complejidad y la calidad de los programas escritos en idiomas o en plataformas donde está inasequible el análisis automatizado Resumir estos datos para su uso en proyectos de planeación de mantenimiento y/o desarrollo de proyectos.
El análisis de flujo del proceso incluye los siguientes pasos:
Flujo de datos
Producen información
Compra a proveedores
Venta de mercancías
Reciben información
Inventario
Finanzas

Bibliografía.
http://www.scribd.com/doc/25590212/El-rol-del-analista-de-Sistemas-Kendall
http://www.comsysprojects.com/SystemTransformation/iataproa.htm
http://www.puntolog.com/foro/buzon/messages/6070.htm
http://www.Monografias.com