[Ciclo de Vida Clásico del Desarrollo de Sistemas]
El método de ciclo de vida para el desarrollo de sistemas es el conjunto de actividades que los analistas, diseñadores y usuarios realizan para desarrollar e implantar un sistema de información.
El método del ciclo de vida para el desarrollo de sistemas consta de seis fases:
1. [Investigación Preliminar]
Solicitud para recibir ayuda de un sistema de información puede originarse por varias razones: sin importar cuales sean estas, el proceso se inicia siempre con la petición de una organización.
2. [Determinación de los Requerimientos]
Aspecto fundamental del análisis de sistemas es comprender todas las facetas importantes de la parte de la organización que se encuentra bajo estudio. De esto se encargan los analistas, al trabajar con los empleados y administradores.
3. [Diseño]
En el diseño de un sistema de información produce los detalles que establecen la forma en la que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en contraste con la del desarrollo del software, a la que denominan diseño físico.
4. [Desarrollo de Software]
Los encargados de desarrollar software pueden instalar software comprobando a terceros o escribir programas diseñados a la medida del solicitante. La elección depende del costo de cada alternativa, del tiempo disponible para escribir el software y de la disponibilidad de los programadores. Por lo general, los programadores que trabajan en las grandes organizaciones pertenecen a un grupo permanente de profesionales.
5. [Prueba de Sistema]
Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. Se alimentan como entradas conjunto de datos de prueba para su procesamiento y después se examinan los resultados.
6. [Implementación]
La implementación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarla. Una vez instaladas, las aplicaciones se emplean durante muchos años. Sin embargo, las organizaciones y los usuarios cambian con el paso del tiempo, incluso el ambiente es diferente con el paso de las semanas y los meses.
[Método de Desarrollo por Análisis Estructurado]
Este método es una actividad de construcción de modelos. Mediante una notación que es única, se crean modelos que reflejan el flujo y el contenido de la información (datos y control); el sistema se divide funcionalmente y, según los distintos comportamientos, se establece la esencia de lo que se debe construir.
El análisis estructurado surge a mediados de los años 70 y se concentra en especificar lo que se requiere que haga el sistema o aplicación bien sea nuevo o ya existente. Permite que las personas observen los elementos lógicos (lo que hará el sistema) separados de los componentes físicos (computadora, terminales, sistemas de almacenamiento, etc.) sin omitir ningún detalle. Después de esto se puede desarrollar un diseño físico eficiente para la situación donde será utilizado.
El Diseño Estructurado es otro elemento del Método de Desarrollo por Análisis Estructurado que emplea la descripción gráfica, se enfoca en el desarrollo de especificaciones del software. El objetivo del Diseño Estructurado es programas formados por módulos independientes unos de otros desde el punto de vista funcional. La herramienta fundamental del Diseño Estructurado es el diagrama estructurado que es de naturaleza gráfica y evitan cualquier referencia relacionada con el hardware o detalles físicos. Su finalidad no es mostrar la lógica de los programas (que es la tarea de los diagramas de flujo). Los Diagramas Estructurados describen la interacción entre módulos independientes junto con los datos que un módulo pasa a otro cuando interacciona con él.
[Modelado de Datos]
El modelado de datos estudia los datos independientemente del procesamiento que los transforma.
El modelado de datos responde a:
¿Cuáles son las entidades de datos primarios que va a procesar el sistema?
¿Cuál es la composición de cada entidad de datos y que atributos la describen?
¿Cuál es la relación entre las entidades y los procesos que las transforman?
Para resolver estas cuestiones se realiza el diagrama entidad-relación, donde se representa la red de datos que existe en el sistema dado, indicando los datos que se introducen, se almacenan se transforman y se producen dentro de la aplicación.
[Modelado Funcional y Flujo de Información]
Diagramas de flujo de datos
Herramienta que nos permite mostrar el sistema como una red de sistemas conectados entre sí por los datos. Representa el flujo de la información y las transformaciones que se aplican a los datos al moverse desde la entrada hasta la salida.
Diagramas de flujo de Control
Estas ampliaciones permiten al analista reflejar el flujo de control y el procesamiento de control; muestran como fluyen los sucesos entre los distintos procesos e ilustran como los sucesos externos hacen que se activen los procesos. El DFC contiene los mismos procesos que el DFD, pero muestra el flujo de control en lugar de datos. Esta ampliación se centra menos en la creación de símbolos gráficos adicionales y más en la representación y especificación de los aspectos del software orientados al control.
Modelado de Comportamiento
El modelado del comportamiento es uno de los principios fundamentales de todos los métodos de análisis de requisitos. El Diagrama de transición de Estado representa el comportamiento de un sistema que muestra los estados y los sucesos que hacen que el sistema cambie de estado.
Diccionario de Datos
El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista tengan una misma comprensión de las entradas, salidas, almacenes de datos y cálculos intermedios.
Herramientas como por ejemplo: Diagrama entidad-relación, Diagrama de flujo de datos (DFD), Diagrama de transición de estados (DTE).
[Método de Construcción de Prototipos de Sistemas]
Los modelos de construcción de prototipos pertenecen a los modelos de desarrollo evolutivo, comienza con una recolección de requerimientos expresadas por el usuario inicial. Aunque es escasa la especificación de entradas, luego se pasa a la elaboración del diseño y este diseño nos lleva a la construcción del prototipo exigido por el cliente (esto se hace con el fin de mostrar el sistema de manera más “tangible”). Como el algoritmo está muy pobre de entrada de datos no se podrá generar de manera automática
La característica de estos modelos es que tienen la capacidad de mejorar visiblemente el prototipo por el desarrollador del software, lo cual produce las siguientes ventajas: mejor comunicación desarrollador-cliente/usuario; menores tiempos de planeamiento, modelado, diseño, desarrollo, implementación, mantenimiento y feedback (incluyendo la etapa característica de este método, que la construcción del prototipo entre diseño y desarrollo).
El cliente es quien parametriza esta fase de comunicación, por tanto el diseñador define las necesidades y proseguimos al plan rápido, que es aquel que se plantea cuando el cliente llega con el requerimiento y se pasa a modelar y diseñar el prototipo de sistema. Como se dijo antes, se posee tan poca información que el algoritmo no es lo suficientemente apropiado para generar un sistema 100% funcionante. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles para el usuario final, se hace la construcción del prototipo a partir del diseño ya propuesto este diseño es evaluado por el usuario final y luego se produce la retroalimentación y se hacen las respectivas integraciones o ajustes definidos por los usuarios o clientes, y por los mismos desarrolladores . Esta es una actividad cíclica que no lleva siempre al mismo punto, ya que hay que tener en cuenta que esta forma de modelización es de evolución continua, es decir, de continuo mejoramiento.
[Conceptos considerados]
Construcción de prototipos: creo que debe ser una guía para el mejor entendimiento entre el programador y el cliente, pero el programador debe asegurarse de que el cliente comprenda que no se le esta presentando una versión definitiva del sistema ni que podrá sugerir modificaciones demasiadas veces (ya que de esta manera la implementación no se finalizaría nunca).
El hecho de que el análisis estructurado permita la observación de los elementos lógicos separados de los componentes físicos, y después de esto se pueda desarrollar un diseño físico eficiente para la situación donde será utilizado, recuerda a la frase “mind over matter” (mente sobre materia).
En el Método Clásico, distintos autores proponen diferente cantidad de etapas (aunque agrupan las mismas actividades) las etapas presentadas en este trabajo práctico podrían fusionarse en el caso de la 1 y la 2, y de la 5 y la 6.
[Similitudes y diferencias]
Los tiempos del método de Construcción de Prototipos depende mas del cliente, porque al poder ver el producto semi terminado, el cliente tiene una comprensión mayor de los efectos del proceso de desarrollo, y la comunicación entre este ultimo y el desarrollador aumenta (cual es positivo), pero también podría insistir en el perfeccionismo y alargar innecesariamente el desarrollo.
En el método Clásico, los desarrolladores tienden a mantener un control mayor sobre las diversas etapas del proceso creador y productivo. Una consecuencia de esto es que recae mas responsabilidad en los profesionales de sistemas.
Si el sistema informático a desarrollar no existe y debe ser construido desde cero, el Método Clásico del Ciclo de Vida de Desarrollo de Sistemas tiende a ser el mas adecuado.
Si el sistema informático a desarrollar ya existe, es conveniente tomar la versión existente y aplicar el método de Construcción de Prototipos.
El feedback es fundamental en todos métodos.
A la hora de trabajar sobre organizaciones altamente estructuradas parece mas conveniente utilizar el Método de Desarrollo por Análisis Estructurado.
[Glosario]
Dato: Valor, abstracción que representa algún aspecto de la realidad.
Desarrollador: Programador, Analista. En términos formales puede ser un Analista, Programador, Ingeniero, Licenciado, etc.
Diagrama entidad-relación: representa las relaciones entre entidades de datos. Los atributos de cada entidad se pueden describir mediante la Descripción de datos.
Diagrama de flujo de datos (DFD): sirve para dos propósitos, indica como se transforman los datos a medida que se avanza en el sistema; y representa las funciones que transforman el flujo de datos. En la Especificación de proceso se encuentra un descripción de cada función representada en el DFD.
Diagrama de transición de estados (DTE): indica como se comporta el sistema como consecuencia de sucesos externos. La Especificación de control detalla mas información sobre los aspectos de control del software.
Feedback: Retroalimentación. Salidas que vuelven al sistema en forma de entradas.
Información: Dato procesado. Todo lo que ayuda a reducir la incertidumbre a la hora de tomar una decisión.
Modelo: Representación reducida de alguna cosa.
Módulo: En software es una porción de código que puede ser considerada como un programa individual o combinarse con otros módulos para crear un programa mas complejo.
Prototipo: Del griego “protos” = primero. Primero de su tipo, en este caso sistema funcionante del cual se derivaran versiones mejoradas.
Software: Sistema o programas. Algoritmos escritos en lenguaje de programación.
[Relación con la carrera de Sistemas de Información]
Considero fundamental un conocimiento básico de los tres métodos para tenerlos presentes al momento de abocarme al desarrollo de un sistema informático, para decidir cual método es mas adecuado según las necesidades de cada organización. También considero que los métodos pueden ser combinables, que se puede adoptar preferencias personales por cada uno (llevándonos a profundizar el conocimiento personal en el), y que hay que tomarse el debido tiempo antes de decidirse por un método, ya que una vez elegido seria muy perjudicial volver atrás.
[fuentes]
http://analisisdesistemasecci.blogspot.com.ar/search/label/Modelos%20De%20Prototipos.
http://grupo3seccionb.blogspot.com/
http://www.oocities.org/es/kagutierbcv/ads/t1/contenido.htm#2
No comments:
Post a Comment