MODELAC... " Vive Para Salvar "

Descarga la exp. Formato MicrosoftWord 2003. aqui. ===>> MODELAC PDS

Asi lo publico: Macario Morales De La Cruz y  Alonso Vázquez Hernández.

Materia: Teoría de Sistemas.
Trabajo: El proceso de Diseño de Sistemas:
               El Paradigma de los Sistemas.

Carrera: Lic. En Informática
              Administrativa.

Alumnos: Macario Morales De La Cruz,
                Alonso Vázquez Hernández.

Nopalucan De La Granja, Pué. 9 de marzo del 2007.

I N D I C E

TEMA PÁGINA

Prologo……………………………………...III

I. Procesos de diseño de sistemas
1. Planificación de un proyecto de sistemas………...………..1
1.1. ¿Qué es un proyecto de software?.................…..……....1
1.2. Objetivos de la planificación del proyecto……….....……1
1.3. Actividades asociadas al proyecto de software……......1
1.3.1. Ámbito del software……………..………..........................1
1.4. Recursos……………………………………………................…...2
1.4.1. Recursos humanos…………………..…………….….............2
1.4.2. Recursos o componentes de software reutilizables….3
1.4.3. Recursos de entorno………………………………...........…..3
2. Diseño de sistemas de computación………………….........…3
2.1. Conceptos y principios………………………………................3

II. El paradigma de los sistemas

1. Introducción al paradigma de sistemas ..........................5
2. El análisis y diseño de sistemas …………………………........5
3. El analista de sistemas…………………………..........………….5
3.1. Las funciones del analista de sistemas por Santos……5
3.2. La definición del analista de sistemas por Senn…..……6
3.3. Clasificación según Kendall……………………………...........6
3.4. ¿Todos los analistas deben programar?........................6
4. Contacto del analista con los usuarios……………….....……7
5. El ciclo de vida del desarrollo de sistemas……………..…..7
5.1. Fases de Kendall.………………………………………..............7
5.2. Fases de Senn……………………….............……………………7
5.3. Obtenemos el CVDS moderno……………….........………….7
6. Conclusiones del paradigma de sistemas.………..………...8

III. Actividad……………………………………………………...9

IV. Actividad……………………………………………………..10

IV. Actividad……………………………………………………..11

V. Bibliografía........……………………………………………..12

P R O L O G O

En este proyecto podemos observar “el proceso del diseño de sistemas y el paradigma de los sistemas.”

El proceso del diseño de sistemas podemos comprenderlo como el análisis del diseño de sistemas y llevarlo a la practica como un proyecto de sistemas donde el proceso es una gestión para la creación de un sistema dentro del cual observaremos el objetivo de la planeación, los recursos requeridos para el proceso de diseño de sistemas y por ultimo las etapas para el diseño de sistemas, y de esta manera comprender el proceso paso por paso, solo bastara con leer para hacerlo.

El estudio de El Paradigma de los Sistemas es una disciplina de los estudiantes de Informática o sus derivados de la computación. El paradigma de Sistemas ha mostrado tanta importancia en cuanto al desarrollo

Para la realización de un buen sistema de información el cual cobra vida desde el Diseño de Sistemas y su buena aplicación puede favorecernos para un éxito seguro en el desarrollo de un sistema -dicese de sistema informático- tomando en cuenta las fases por las cuales pasa este desarrollo para la obtención de un sistema final.

El objetivo es que la persona que lee este documento tenga una visión en cuanto a los métodos para el desarrollo de un sistema y como adecuar un sistema a las necesidades de quien lo requiere, digamos un sistema ejemplar.

P R O C E S O D E D I S E Ñ O

D E S I S T E M A S

A N A L I S I S D E D I S E Ñ O S D E S I S T E M A S

Tema I. Planificación de un proyecto de sistemas.

Desarrollo

1.1. Que es un proyecto de Sistema o Software. ?

Es el Proceso de gestión para la creación de un Sistema o software, la cual encierra un conjunto de actividades, una de las cuales es la estimación, estimar es echar un vistazo al futuro y aceptamos resignados cierto grado de incertidumbre. Aunque la estimación, es mas un arte que una Ciencia, es una actividad importante que no debe llevarse a cabo de forma descuidada. Existen técnicas útiles para la estimación de costes de tiempo. Y dado que la estimación es la base de todas las demás actividades de planificación del proyecto y sirve como guía para una buena Ingeniería Sistemas y Software.

Al estimar tomamos en cuenta no solo del procedimiento técnico a utilizar en el proyecto, sino que se toma en cuenta los recursos, costos y planificación. El Tamaño del proyecto es otro factor importante que puede afectar la precisión de las estimaciones. A medida que el tamaño aumenta, crece rápidamente la interdependencia entre varios elementos del Software.

La disponibilidad de información Histórica es otro elemento que determina el riesgo de la estimación.

1.2. Objetivos de la Planificación del Proyecto.

El objetivo de la Planificación del proyecto de Software es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos costos y planificación temporal. Estas estimaciones se hacen dentro de un marco de tiempo limitado al comienzo de un proyecto de software, y deberían actualizarse regularmente medida que progresa el proyecto.

El Objetivo de la planificación se logra mediante un proceso de descubrimiento de la información que lleve a estimaciones razonables.

1.3 Actividades asociadas al proyecto de software.

1.3.1 Ámbito del Software.

Es la primera actividad de llevada a cabo durante la planificación del proyecto de Software.

En esta etapa se deben evaluar la función y el rendimiento que se asignaron al Software durante la Ingeniería del Sistema de Computadora para establecer un ámbito de proyecto que no sea ambiguo, e incomprensible para directivos y técnicos

Describe la función, el rendimiento, las restricciones, las interfaces y la fiabilidad, se evalúan las funciones del ámbito y en algunos casos se refinan para dar mas detalles antes del comienzo de la estimación. Las restricciones de rendimiento abarcan los requisitos de tiempo de respuesta y procesamiento, identifican los limites del software originados por el hardware externo, por la memoria disponible y por otros sistemas existentes.

1.4 RECURSOS:

La Segunda tarea de la planificación del desarrollo de Software es la estimación de los recursos requeridos para acometer el esfuerzo de desarrollo de Software, esto simula a una pirámide donde las Herramientas (hardware y Software), son la base proporciona la infraestructura de soporte al esfuerzo de desarrollo, en segundo nivel de la pirámide se encuentran los Componentes reutilizables.

Y en la parte mas alta de la pirámide se encuentra el recurso primario, las personas (el recurso humano).

Cada recurso queda especificado mediante cuatro características:

Descripción del Recurso.

Informes de disponibilidad.

Fecha cronológica en la que se requiere el recurso.

Tiempo durante el que será aplicado el recurso

1.4.1 Recursos Humanos.

La Cantidad de personas requeridas para el desarrollo de un proyecto de software solo puede ser determinado después de hacer una estimación del esfuerzo de desarrollo (por ejemplo personas mes o personas años), y seleccionar la posición dentro de la organización y la especialidad que desempeñara cada profesional.

1.4.2 Recursos o componentes de software reutilizables.

Cualquier estudio sobre recursos de software estaría incompleto sin estudiar la reutilización, esto es la creación y la reutilización de bloques de construcción de Software.

Tales bloques se deben establecer en catálogos y estandarizarse para una fácil aplicación y validarse para la también fácil integración.

El Autor Bennatan sugiere cuatro categorías de recursos de software:

Componentes ya desarrollados.

Componentes ya experimentados.

Componentes con experiencia Parcial.

Componentes nuevos.

1.4.3 Recursos de entorno.

El entorno es donde se apoya el proyecto de Software, llamado a menudo entorno de Ingeniería de Software, incorpora Hardware y Software.

El Hardware proporciona una plataforma con las herramientas (Software) requeridas para producir los productos que son el resultado de la buena practica de la Ingeniería del Software.

TEMA II. DISEÑO DE SISTEMAS DE COMPUTACIÓN.

DESARROLLO.

2.1. Conceptos y principios:

El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física.

La etapa del Diseño del Sistema encierra cuatro etapas:

1. El diseño de los datos.

Trasforma el modelo de dominio de la información, creado durante el análisis, en las estructuras de datos necesarios para implementar el Software.

2. El Diseño Arquitectónico.

Define la relación entre cada uno de los elementos estructurales del programa

3. El Diseño de la Interfaz.

Describe como se comunica el Software consigo mismo, con los sistemas que operan junto con el y con los operadores y usuarios que lo emplean.

4. El Diseño de procedimientos.

Transforma elementos estructurales de la arquitectura del programa. La importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar con precisión los requerimientos del cliente.

El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas:

E l P a r a d i g m a d e l o s S i s t e m a s

EL Ejemplo o ejemplar de los Sistemas.

1. El Analista de Sistemas es imprescindible en cualquier organización, debido al abanico de destrezas que éste posee y los beneficios que le produce. Se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, es más que eso, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen.

Todo desarrollo líderizado o no por un analista de sistemas posee fases que pueden dividirse en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica. Este conjunto de fases son conocidas como el Ciclo de Vida de Desarrollo de Sistemas, herramienta fundamental para el desempeño de un analista de sistemas.

2. El Análisis y Diseño de 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 manejarla con métodos y procedimientos más adecuados". Se puede dividir en dos:

1. El análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema.
2. El diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable.

En pocas palabras;

Þ análisis especifica qué es lo que el sistema debe hacer”.

Þ diseño establece cómo alcanzar el objetivo”.

Ciertamente, todo sistema de información debe presentar salidas en base a entradas de datos y procesos, lo que nos dice que si deseamos entender todo lo que le ocurre a los datos antes de llegar al usuario como información –Es decir antes de ser interpretado por el usuario final- debemos utilizar metodologías que permiten ver los sistemas en base a sus procesos, por lo menos en sistemas de procesado por lotes o secuencial. Un ejemplo de ello es la metodología estructurada. Existen muchas metodologías pero esta es la más arraigada debido a su antigüedad. Recordemos que hace apenas dos décadas los computadores no soportaban el multitasking (procesamiento multitarea), lo que limitaba a procesar una pantalla a la vez, esto sólo permitía sistemas secuenciales donde cada tarea en procesamiento comenzaba cuando la anterior ya había terminado por completo.

3. El Analista de Sistema nace de la necesidad de recopilar, desglosar, catalogar y analizar información necesaria de una empresa para poder proponer nuevos métodos, mejores o modificar los actuales para que así aumente el desempeño de los departamentos dentro de la organización.

En toda organización un analista se vale de la información de entrada, los procesos modificadores y la información de salida, para así definir los procesos intermedios y poder entender con claridad a la organización. Todos estos flujos y procesos son estudiados sistemáticamente para poder determinar si son los adecuados, si se deben mejorar o si deben ser reemplazados por otros más idóneos.

3.1 Las Funciones del Analista de Sistemas por Santos (1980, p.12). Para la década de los ochenta.

"…el analista de problemas en computación deberá conocer procedimientos para indagar sobre lo existente y para saber proponer un verdadero sistema racionalizado, pero también deberá conocer sobre modernos sistemas de información, base del diseño, sobre todo en computación… Estos últimos factores son los que justifican tal especialidad, porque realmente debieron existir los analistas de sistemas, aunque no hubiera computadores, toda vez que siempre hubo sistemas para organizar, que posiblemente no se difundieron porque no existieron en importancia esos dos factores que hoy prevalecen: el computador y la información."

3.2 La Definición del Analista de Sistemas por Senn (1992, p. 12), agrega: "…Los analistas hacen mucho más que resolver problemas. Con frecuencia se solicita su ayuda para planificar la expansión de la organización…", es decir, el papel de los analistas sobrepasa los limites impuestos por la definición inicial, también cumplen el papel de asesores, ya sea en sistemas manuales o informatizados, o cualquier otro sistema donde la empresa tenga que invertir en información, después de todo esa es la razón de ser del analista.

Comparando las dos definiciones anteriores podemos notar que en veinte años no ha cambiado la descripción de analista de sistemas, más bien se le han atribuido nuevas características que lo definen como un ente de cambio, necesario en cualquier organización con tendencia a crecer.

Según Senn, dependiendo de las funciones de un analista de sistemas se puede clasificar en: Analista de sistemas, Analista y diseñador de sistemas y analista diseñador y programador de sistemas, en donde cada uno se puede identificar y diferenciar de los demás por las actividades que definen sus denominaciones.

3.3 clasificación según Kendall (1997, p.6). También podemos clasificar a los analistas de sistema como Consultor, Experto de soporte y Agente de cambio.

Vale la pena explicar un poco la clasificación de éste último autor debido a que no se basa en las actividades propias del analista, sino los papeles que cumple en las fases impuestas en el paradigma Ciclo de Vida de Desarrollo de Sistemas (CVDS). Cuando se comienza el CVDS el analista cumple en papel de consultor, asesorando a la empresa sobre los mejores métodos y sistemas que se pueden emplean para la óptima gestión de información, recomendando sistemas ya sean de tipo manual o de tipo informático, predominando claro, los sistemas informáticos que le dan la vida a ésta profesión. El experto en soporte se identifica con los últimos pasos del CVDS donde el analista se desempeña en el asesoramiento de hardware y software, basado en el conocimiento y especialmente en la experiencia. Sirviendo el analista muchas veces de escalón para hacer que el sistema desarrollado (no liderizado por él) tenga éxito. Como Agente de Cambio se tiene el papel más importante y más difícil, la comunicación con empleados dentro de la fase de recopilación de información es probable que los empleados piensen que el sistema los va a sustituir, aunque algunas veces es cierto, el analista debe internalizar que el cambio es en pro de la organización y no de un grupo minoritario o sectorial.

3.4 Una pregunta común sobre los analistas de sistemas es ¿Todos los analistas deben programar?, Según Senn (1992, p.16); "…La respuesta depende de la organización. Sin embargo, una cosa es evidente: el analista de sistemas más valioso y mejor calificado es aquel que sabe programar.", ciertamente el analista que tiene fuertes principios de programación sabe que se puede y que no se puede, o que es difícil de desarrollar en un lapso de tiempo, recordemos que todos los proyectos informáticos tienen siempre lapsos de tiempo bien reducidos y que si no se tiene el equipo apropiado es difícil cumplir con los plazos establecidos, lo que trae como consecuencia muchas veces la falla de todo el proyecto. Además el analista programador tiene facilidad para comunicar sus ideas a los constructores de código, ya que él estuvo en ese lugar alguna vez y sabe en que forma se necesita la información al momento de generar código.

4. Contacto del Analista con los Usuarios

Es difícil determinar el tamaño de un sistema a desarrollar si no conocemos los diferentes niveles del mismo, los diferentes detalles de las salidas de información, a quienes van dirigidas y cual es la mejor forma de hacerlo.

Los analistas de Sistemas están en la obligación de recorrer desde los niveles más altos de la empresa (gerentes y directivos), hasta los niveles más bajos (obreros y empleados) para determinar quienes realmente necesitan la información, con que oportunidad y grado de detalle de cada peldaño de la escalera institucional. "Los gerentes y empleados tienen buenas ideas -qué es lo que si trabaja y qué es lo que no, qué causa problemas y qué no, dónde son necesarios los cambios y dónde no."(Senn, p.13), en efecto, quien mejor que los que día a día ven el sistema y como sus compañeros o subordinados lo reciben, para decirle al analista con anticipación cual será la aceptación del producto final y que mejoras deben tener. A fin de cuentas ellos son los que le sacarán provecho al sistema, los que se alimentarán del mismo.

5. El Ciclo de Vida del Desarrollo de Sistemas (CVDS) es un paradigma de la programación estructurada que proporciona lineamientos para desarrollar un proyecto de sistema de información.

5.1 Fases de Kendall (1997). Divide el CVDS en siete fases:

Identificación de problemas, oportunidades y objetivos.

Determinación de los requerimientos de información.

Análisis de las necesidades del sistema.

Diseño del sistema recomendado.

Desarrollo y documentación del software.

Prueba y mantenimiento del sistema.

Implementación y evaluación del hardware.

5.2 Fases de Senn (1992). Siendo la siguiente;

Investigación preliminar.

Determinación de los requerimientos del sistema.

Diseño del sistema.

Desarrollo del software.

Prueba de los sistemas.

Implantación y evaluación.

Comparando los dos autores podemos observar que su división de las fases del CVDS es similar, de hecho a primera vista y sin definir cada una de las fases, si comparamos con sus homólogas podemos notar que Senn define las fases; Análisis de las Necesidades del Sistema Recomendado (3) y Diseño del Sistema Recomendado (4) de Kendall en una sola fase llamada Diseño del Sistema, la cual comprende estas dos actividades.

5.3 Simplificando aún más estas fases descritas anteriormente obtenemos el CVDS moderno;

1. Planificación del Proyecto.
2. Análisis del Sistema Actual.
3. Diseño del Sistema Propuesto.
4. Implantación y documentación del sistema.
5. Evaluación y soporte del sistema.

El CVDS es un conjunto de pasos que si bien son secuenciales no necesariamente deben llevarse con rigidez, en cualquier momento que el analista lo requiera puede devolverse al paso o fase anterior, de hecho, es muy común que si en alguna fase se requiera modificar algún análisis de una fase previa, o hasta repetir varias veces una misma tarea para comparar algún resultado.

"Los analistas no están de acuerdo con qué tantas fases exactas hay en el ciclo de vida de desarrollo de sistemas, pero, por lo general, alaban su enfoque organizado."(Kendall, 1997, p.8) Es cierto que el CVDS es un modelo muy organizado para la programación estructurada, pero no siempre se puede aplicar para el desarrollo de aplicaciones, especialmente cuando empezamos a utilizar nuevas metodologías y convenciones. Un ejemplo de ello es la dificultad de aplicar el enfoque estructurado del CVDS para el desarrollo de una aplicación Web.

Digamos que tenemos que diseñar un periódico electrónico y que nuestra base de datos se encuentra en un servidor A, que tenemos un servidor Web (WWW) en otra ubicación B y que tenemos un servidor de archivos (FTP) en otro sitio diferente C. Ya este tipo de organización lógica del sistema se sale de las expectativas de las personas que idearon la metodología estructurada del CVDS. Claro, con esto no digo que el paradigma no pueda adaptarse, crear como una especie de metodología híbrida que permita combinar diferentes herramientas, pero ya no tendría la estructura original.

6. Conclusiones del Paradigma de Sistemas

Cada sistema a desarrollar debe ser tratado con la metodología que mejor se adapte a los objetivos del análisis un producto final de calidad. El CVDS es el paradigma más fuertemente difundido para el desarrollo de sistema de cómputos y lotes óptimos, sin embargo el desconocimiento de nuevas metodologías nos puede llevar al uso indiscriminado de éste paradigma, ajustándose o no a nuestros objetivos.

Como analistas de sistemas debemos mantenernos a la par de los últimos avances en cuanto a las metodologías y tendencias dentro del incesante mundo del manejo de la Información.

Conforme pasa el tiempo el perfil del analista de sistemas irá incorporando nuevas posibilidades y deberes dentro de las organizaciones, lo que nos afirma que durante mucho tiempo tendremos trabajo, claro, manteniéndonos en la excelencia.

E l P a r a d i g m a d e l o s S i s t e m a s

EL Ejemplo o ejemplar de los Sistemas.

A C T I V I D A D IV

1. El Analista de Sistemas

a) ¿Describa la función del Analista de Sistemas?

Se encarga no sólo estudiar la organización y desarrollar un sistema automatizado, la labor del analista de sistemas es también la de asesorar, supervisar, recomendar y modificar procesos internos y algunas veces de modificar la estructura misma de la empresa, con el propósito de lograr los objetivos que se proponen.

b) ¿Defina Ciclo de Vida de Desarrollo de Sistemas?

Todo desarrollo líderizado o no por un analista de sistemas posee fases que pueden dividirse en elementos discretos pero, que innegablemente son continuos, de alguna manera cíclica, que proporciona lineamientos para desarrollar un proyecto de sistema de información.

2. El Análisis y Diseño de Sistemas

c) ¿El análisis y diseño de sistemas se refiere a?

El proceso de examinar la situación de una empresa con el propósito de manejarla con métodos y procedimientos más adecuados".

d) ¿El análisis y diseño de sistemas Se puede dividir en?

3. El análisis de sistemas que comprende la planificación, el levantamiento inicial de información y el estudio en detalle del sistema actual para luego recomendar o estructurar las especificaciones necesarias para el nuevo sistema.
4. El diseño que consiste en llevar a cabo el sistema por medio de la clasificación y empleo de la información de manera que se pueda ofrecer una alternativa mucho más viable.

e) ¿Defina Análisis y Diseño?

Þ análisis especifica qué es lo que el sistema debe hacer”.

Þ diseño establece cómo alcanzar el objetivo”.

3. El Analista de Sistema

f) ¿El Analista de Sistema nace de la necesidad de?

Recopilar, desglosar, catalogar y analizar información necesaria de una empresa para poder proponer nuevos métodos, mejores o modificar los actuales para que así aumente el desempeño de los departamentos dentro de la organización.

3.4 Una pregunta común sobre los analistas de sistemas es ¿Todos los analistas deben programar?, Según Senn (1992, p.16);

g) ¿Todos los analistas deben programar?,

"…La respuesta depende de la organización. Sin embargo, una cosa es evidente: el analista de sistemas más valioso y mejor calificado es aquel que sabe programar."

4. Contacto del Analista con los Usuarios

5. El Ciclo de Vida del Desarrollo de Sistemas (CVDS)

5.3 Simplificando aún más estas fases descritas anteriormente obtenemos el CVDS moderno;

h) ¿Fases del Ciclo de Vida del Desarrollo de un Sistema Moderno?

6. Planificación del Proyecto.
7. Análisis del Sistema Actual.
8. Diseño del Sistema Propuesto.
9. Implantación y documentación del sistema.
10. Evaluación y soporte del sistema.

i) ¿El CVDS es un conjunto de pasos secuenciales?

No necesariamente deben llevarse con rigidez, en cualquier momento que el analista lo requiera puede devolverse al paso o fase anterior, de hecho, es muy común que si en alguna fase se requiera modificar algún análisis de una fase previa, o hasta repetir varias veces una misma tarea para comparar algún resultado.

B I B L I O G R A F I A

http://www.monografias.com/trabajos/anaydisesis/anaydisesis.shtml#plani

Análisis y Diseño de Sistemas

Autor: Henry F. Korth & Abraham Silberschatz

Segunda Edicion.

Editora Mc Graw Hill

Ingeniería del Software

Autor: Roger S. Pressman

Cuarta Edicion.

Editora Mc Graw Hill

Enciclopedia de Términos de Computación

Autor: Linda Gail/ John Christie

Editora: PHH, Pentice Hall

*******************************************************************************************************************

http://www.monografias.com/trabajos15/analista-sistem/analista-sistem.shtml#INTRO

SANTOS, Ernesto. (1980). Procesamiento de Datos. Ediciones Macchi. Argentina.

SENN, James A. (1992) Análisis y Diseño de Sistemas de Información. Segunda Edición. Editorial McGrawHill. México.

KENDALL&KENDALL, Kenneth y Julie. (1997) Análisis y Diseño de Sistemas. Tercera Edición. Editorial Prentice Hall. México.