Apuntes para todos los estudiantes y cursos

Ciclo de vida del case

DISEÑO ASCENDENTE Este diseño se refiere a identificar los procesos que necesitan computarizarse conforme surgen, analizarlos como sistemas y codificar los procesos para resolver el problema inmediato. Los problemas que requieren computarizarse normalmente se encuentran en el nivel más bajo de la organización; por lo tanto, el nombre ascendente se refiere al nivel inferior en el cual se introduce primero la computarización.

Por ejemplo, con frecuencia los negocios toman este enfoque para el desarrollo de sistemas al adquirir software comercial para la contabilidad, un paquete diferente para la programación de producción y otro para el marketing.

DISEÑO DESCENDENTE Significa ver una descripción amplia del sistema y después dividirla en partes más pequeñas o subsistemas. El diseño descendente permite a los analistas de sistemas determinar primero los objetivos organizacionales globales, así como también determinar cómo se reúnen mejor en un sistema global; después el analista divide dicho sistema en subsistemas y sus requerimientos.

Las ventajas de usar un enfoque descendente para el diseño de sistemas incluyen evitar el caos de intentar diseñar un sistema de repente. Como hemos visto, planear e implementar sistemas de información de administración es increíblemente complejo. Intentar colocar todos los subsistemas en su lugar y ejecutarlos enseguida es casi un fracaso seguro. Una segunda ventaja, es que permite separar a los equipos de análisis de sistemas para trabajar en paralelo en diferentes subsistemas, lo cual puede ahorrar mucho tiempo. 

DESARROLLO ó PROGRAMACIÓN MODULAR Una vez que los programas se fueron haciendo todavía más complejos y, por lo tanto, mayores, aún fue necesario crear un nivel más de división. Así, ahora era necesario organizar todos los procedimientos y funciones de alguna forma. Los módulos agrupan, precisamente, procedimientos y funciones afines, y también los datos que manipulan, de manera que aquellos que no son empleados por el resto de módulos quedan ocultos a ellos.

Este tipo de programación funciona bien con el diseño descendente porque da énfasis a las interfaces entre los módulos y no los descuida hasta el final del desarrollo de sistemas. Idealmente, cada módulo individual debe ser funcionalmente cohesivo de manera que se encargue de realizar una sola función.

La programación modular persigue que cada módulo y función, cumpla las siguientes características:

  • Pequeño tamaño: de esta forma el impacto de un cambio puede ser perfectamente aislado.
  • Independencia modular: cuanto mayor es la independencia de los módulos y de sus procedimientos y funciones, más sencillo es trabajar con él. El diseño debe reducir la necesidad de compartir ficheros, datos, dispositivos y llamadas desde o  hacia otros módulos y procedimientos y funciones.
  • Características de caja negra: visión exclusiva de la funcionalidad de un módulo o procedimiento/función en base a sus entradas y salidas sin tener en cuenta como se realiza el proceso.

Modelo conceptual: un diseño es más fácil de mantener si el modelo de diseño empleado se ha basado en conceptos lógicos de organización, los cuales sean más familiares y comprensibles para el personal de mantenimiento.

Aislamiento de los detalles (encapsulación): en un sistema existen partes que reflejan la filosofía y otras que reflejan los detalles. Ambas partes deben diseñarse por separado para evitar que una variación en los detalles afecte a la  filosofía del sistema.

Ventajas principales:

1. Los módulos son más fáciles de escribir y de depurar porque prácticamente son independientes. Rastrear un error en un módulo es menos complicado, debido a que un problema en un módulo no debe causar problemas en otros.

2. Los módulos son más fáciles de mantener. Normalmente las modificaciones se limitarán a unos módulos y no seguirán en todo el programa.

3. Los módulos son más fáciles de entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lista del código de un módulo y entender su función.

La meta de la programación modular es obtener una organización de la arquitectura del software, con un diseño no orientado a la simple obtención del programa final, sino también a su mantenimiento, a su reutilización y a poder probarlo y  entenderlo de forma fácil.

Para medir la calidad de un diseño modular se emplean las medidas de cohesión y acoplamiento que se pueden aplicar sobre módulos y procedimientos o funciones.

Cohesión: es la medida de la fuerza o relación funcional de los elementos de un módulo (entendiendo por elementos, los procedimientos o funciones que lo componen, las definiciones de los datos y las llamadas a otros módulos). Un módulo coherente se encarga de una tarea relativamente sencilla en un programa y requiere de poca interacción con el resto de módulos y/o procedimientos y funciones. Por ejemplo, en un módulo de matemáticas, las funciones contenidas deben estar todas relacionadas con cálculos matemáticos, exclusivamente.

Acoplamiento: grado de interdependencia entre los distintos módulos. En general, dos módulos no deben compartir estructuras de datos o variables. Por otro lado, cada módulo debe definir las funciones y procedimientos, estructuras de datos y variables que le resulten necesarias para la realización de su función específica. Así, el módulo de matemáticas ya comentado no debe necesitar en absoluto de otros módulos para trabajar. Otros módulos más complejos pueden necesitar a su vez de módulos que le sirvan para proveer de más funcionalidad, pero siempre de la manera más independiente posible.

HERRAMIENTAS CASE Desde principios de la década de 1990, los analistas empezaron a beneficiarse de las herramientas de productividad, denominadas herramientas de Ingeniería de Software Asistida por Computadora (CASE, Computer-Aided Software Engineering), que se crearon explícitamente para mejorar su trabajo rutinario mediante apoyo automatizado.

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.

Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinación de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software. La mejor razón para la creación de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Por esto, las compañías pudieron desarrollar sistemas sin encarar el problema detener cambios en las necesidades del negocio, antes de finalizar el proceso de desarrollo. También permite a las compañías competir más efectivamente usando estos sistemas desarrollados nuevamente para compararlos con sus necesidades de negocio actuales. En un mercado altamente competitivo, esto puede hacer la diferencia entre el éxito y el fracaso.

Razones para el uso de las herramientas case

  • Aumento en la productividad del analista: Un paquete de herramientas mejora la productividad de grupos al dar a los analistas la posibilidad de compartir fácilmente el trabajo con otros miembros del equipo, quienes sólo tienen que abrir el archivo en sus PCs y revisar o modificar lo que se haya hecho.
  • Mejora de la comunicación analista-usuario: Para que el sistema propuesto se concrete y sea útil en la práctica, es esencial una excelente comunicación entre analistas y usuarios durante todo el ciclo de vida del desarrollo de sistemas. El éxito de la futura implementación del sistema depende de la capacidad de analistas y usuarios para comunicarse de una manera eficiente.
  • Integración de las actividades del ciclo de vida: La tercera razón para el uso de las herramientas CASE es integrar las actividades y proporcionar continuidad de una fase a la siguiente durante todo el ciclo de vida del desarrollo de sistemas. Las herramientas CASE son especialmente útiles cuando una fase en particular del ciclo de vida requiere varias iteraciones de retroalimentación y modificaciones.
  • Evaluar de manera precisa los cambios en el mantenimiento: La cuarta, y probablemente una de las razones más importantes para el uso de herramientas CASE, es que permiten a los usuarios analizar y evaluar el impacto de los cambios en el mantenimiento. Por ejemplo, el tamaño de un elemento como un número de cliente podría requerir alargarse. La herramienta CASE pueden generar referencias cruzadas de cada pantalla, informe y archivo en el cual sea utilizado el elemento, dando lugar a un plan de mantenimiento integral.

Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:

1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.

2. Herramientas de alto nivel, U-CASE (Upper CASE – CASE superior): orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

3. Herramientas de bajo nivel, L-CASE (Lower CASE – CASE inferior): dirigidas a las últimas fases del desarrollo:construcción e implantación.

4. Juegos de herramientas o Tools-Case: son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingenieriaa, orientadas a la fase de mantenimiento

3. Los módulos son más fáciles de entender, debido a que son subsistemas independientes. Por lo tanto, un lector puede adquirir una lista del código de un módulo y entender su función.

La meta de la programación modular es obtener una organización de la arquitectura del software, con un diseño no orientado a la simple obtención del programa final, sino también a su mantenimiento, a su reutilización y a poder probarlo y  entenderlo de forma fácil.

Para medir la calidad de un diseño modular se emplean las medidas de cohesión y acoplamiento que se pueden aplicar sobre módulos y procedimientos o funciones.

Cohesión: es la medida de la fuerza o relación funcional de los elementos de un módulo (entendiendo por elementos, los procedimientos o funciones que lo componen, las definiciones de los datos y las llamadas a otros módulos). Un módulo coherente se encarga de una tarea relativamente sencilla en un programa y requiere de poca interacción con el resto de módulos y/o procedimientos y funciones. Por ejemplo, en un módulo de matemáticas, las funciones contenidas deben estar todas relacionadas con cálculos matemáticos, exclusivamente.

Acoplamiento: grado de interdependencia entre los distintos módulos. En general, dos módulos no deben compartir estructuras de datos o variables. Por otro lado, cada módulo debe definir las funciones y procedimientos, estructuras de datos y variables que le resulten necesarias para la realización de su función específica. Así, el módulo de matemáticas ya comentado no debe necesitar en absoluto de otros módulos para trabajar. HERRAMIENTAS CASE Desde principios de la década de 1990, los analistas empezaron a beneficiarse de las herramientas de productividad, denominadas herramientas de Ingeniería de Software Asistida por Computadora (CASE, Computer-Aided Software Engineering), que se crearon explícitamente para mejorar su trabajo rutinario mediante apoyo automatizado.

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.

Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinación de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software. La mejor razón para la creación de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Por esto, las compañías pudieron desarrollar sistemas sin encarar el problema detener cambios en las necesidades del negocio, antes de finalizar el proceso de desarrollo. También permite a las compañías competir más efectivamente usando estos sistemas desarrollados nuevamente para compararlos con sus necesidades de negocio actuales. En un mercado altamente competitivo, esto puede hacer la diferencia entre el éxito y el fracaso.

Razones para el uso de las herramientas case

  • Aumento en la productividad del analista: Un paquete de herramientas mejora la productividad de grupos al dar a los analistas la posibilidad de compartir fácilmente el trabajo con otros miembros del equipo, quienes sólo tienen que abrir el archivo en sus PCs y revisar o modificar lo que se haya hecho.
  • Mejora de la comunicación analista-usuario: Para que el sistema propuesto se concrete y sea útil en la práctica, es esencial una excelente comunicación entre analistas y usuarios durante todo el ciclo de vida del desarrollo de sistemas. El éxito de la futura implementación del sistema depende de la capacidad de analistas y usuarios para comunicarse de una manera eficiente.
  • Integración de las actividades del ciclo de vida: La tercera razón para el uso de las herramientas CASE es integrar las actividades y proporcionar continuidad de una fase a la siguiente durante todo el ciclo de vida del desarrollo de sistemas. Las herramientas CASE son especialmente útiles cuando una fase en particular del ciclo de vida requiere varias iteraciones de retroalimentación y modificaciones.
  • Evaluar de manera precisa los cambios en el mantenimiento: La cuarta, y probablemente una de las razones más importantes para el uso de herramientas CASE, es que permiten a los usuarios analizar y evaluar el impacto de los cambios en el mantenimiento. Por ejemplo, el tamaño de un elemento como un número de cliente podría requerir alargarse. La herramienta CASE pueden generar referencias cruzadas de cada pantalla, informe y archivo en el cual sea utilizado el elemento, dando lugar a un plan de mantenimiento integral.

Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:

1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.

2. Herramientas de alto nivel, U-CASE (Upper CASE – CASE superior): orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

3. Herramientas de bajo nivel, L-CASE (Lower CASE – CASE inferior): dirigidas a las últimas fases del desarrollo:construcción e implantación.

4. Juegos de herramientas o Tools-Case: son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingenieriaa, orientadas a la fase de mantenimiento

Se puede definir a las Herramientas CASE como un conjunto de programas y ayudas que dan asistencia a los analistas, ingenieros de software y desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un Software.

Las Herramientas CASE fueron desarrolladas para automatizar esos procesos y facilitar las tareas de coordinación de los eventos que necesitan ser mejorados en el ciclo de desarrollo de software. La mejor razón para la creación de estas herramientas fue el incremento en la velocidad de desarrollo de los sistemas. Por esto, las compañías pudieron desarrollar sistemas sin encarar el problema detener cambios en las necesidades del negocio, antes de finalizar el proceso de desarrollo.

Razones para el uso de las herramientas case

  • Aumento en la productividad del analista: Un paquete de herramientas mejora la productividad de grupos al dar a los analistas la posibilidad de compartir fácilmente el trabajo con otros miembros del equipo, quienes sólo tienen que abrir el archivo en sus PCs y revisar o modificar lo que se haya hecho.
  • Mejora de la comunicación analista-usuario: Para que el sistema propuesto se concrete y sea útil en la práctica, es esencial una excelente comunicación entre analistas y usuarios durante todo el ciclo de vida del desarrollo de sistemas. El éxito de la futura implementación del sistema depende de la capacidad de analistas y usuarios para comunicarse de una manera eficiente.
  • Integración de las actividades del ciclo de vida: La tercera razón para el uso de las herramientas CASE es integrar las actividades y proporcionar continuidad de una fase a la siguiente durante todo el ciclo de vida del desarrollo de sistemas. Las herramientas CASE son especialmente útiles cuando una fase en particular del ciclo de vida requiere varias iteraciones de retroalimentación y modificaciones.
  • Evaluar de manera precisa los cambios en el mantenimiento: La cuarta, y probablemente una de las razones más importantes para el uso de herramientas CASE, es que permiten a los usuarios analizar y evaluar el impacto de los cambios en el mantenimiento. Por ejemplo, el tamaño de un elemento como un número de cliente podría requerir alargarse. La herramienta CASE pueden generar referencias cruzadas de cada pantalla, informe y archivo en el cual sea utilizado el elemento, dando lugar a un plan de mantenimiento integral.

Las herramientas CASE, en función de las fases del ciclo de vida abarcadas, se pueden agrupar de la forma siguiente:

1. Herramientas integradas, I-CASE (Integrated CASE, CASE integrado): abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son llamadas también CASE workbench.

2. Herramientas de alto nivel, U-CASE (Upper CASE – CASE superior): orientadas a la automatización y soporte de las actividades desarrolladas durante las primeras fases del desarrollo: análisis y diseño.

3. Herramientas de bajo nivel, L-CASE (Lower CASE – CASE inferior): dirigidas a las últimas fases del desarrollo:construcción e implantación.

4. Juegos de herramientas o Tools-Case: son el tipo más simple de herramientas CASE. Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se encontrarían las herramientas de reingenieriaa, orientadas a la fase de mantenimiento

No se permite realizar comentarios.