16/09/2020

José Miguel Molina Conrado

Herramientas CASE (Computer Aided Software

Engineering, Ingeniería de Software Asistida por
Computadora)
Las herramientas CASE son unas diversas aplicaciones o
programas informáticos, los cuales son destinados a
aumentar el balance en el proceso del desarrollo de software
al reducir el costo de las mismas en términos de tiempo y de
dinero.
Estas herramientas pueden ayudar en todos los aspectos del
ciclo de vida de desarrollo del software en tareas al realizar
ciertos objetivos, como:
 Mejorar la productividad y aumentar la calidad del
software.
 Reducir el tiempo y costo de desarrollo y mantenimiento
de los sistemas informáticos.
 Mejorar la planificación de un proyecto.
 Aumentar la biblioteca de conocimiento informático de
una empresa ayudando a la búsqueda de soluciones
para los requisitos.
 Automatizar el desarrollo del software, la
documentación, la generación de código, las pruebas de
errores y la gestión del proyecto.
  Ayuda a la reutilización del software, portabilidad y
estandarización de la documentación.
 Gestión global en todas las fases de desarrollo de
software con una misma herramienta.
 Facilitar el uso de las distintas metodologías propias de
la ingeniería del software.
Ya en los años 70, un proyecto llamado ISDOS diseñó un
lenguaje y por lo tanto un producto que analizaba la relación
existente entre los requisitos de un problema y las
necesidades que estos generaban, el lenguaje en cuestión se
denominaba PSL (Problem Statement Language, Lenguaje
de Declaración de Problemas) y la aplicación que ayudaba a
buscar las necesidades de los diseñadores PSA (Problem
Statement Analyzer, Analizador de Declaración de
Problemas).
Aunque es difícil y existen muchas formas de clasificarlas, las
herramientas CASE se pueden clasificar teniendo en cuenta
los siguientes parámetros:
 Las plataformas que soportan.
 Las fases del ciclo de vida del desarrollo de sistemas
que cubren.
 La arquitectura de las aplicaciones que producen.
 Su funcionalidad.
Según las fases del ciclo de vida del desarrollo, la siguiente
clasificación es la más habitual basada en las fases del ciclo
de desarrollo que cubren:
 Upper CASE (U-CASE):
 Herramientas que ayudan en las fases
de planificación, análisis de requisitos y estrategia del
desarrollo, usando, entre otros diagramas UML.
 Middle CASE (M-CASE):
Herramientas para automatizar tareas en
el análisis y diseño de la aplicación.
 Lower CASE (L-CASE):
Herramientas que semi-automatizan la generación de
código, crean programas de detección de errores,
soportan la depuración de programas y pruebas.
Además, automatizan la documentación completa de la
aplicación. Aquí pueden incluirse las herramientas
de desarrollo rápido de aplicaciones.
De hecho, también existen otros nombres que se le dan a
este tipo de herramientas, y que no es una clasificación
excluyente entre sí, ni con las fases del ciclo de vida del
desarrollo:
 Integrated CASE (I-CASE):
Herramientas que engloban todo el proceso de
desarrollo software, desde el análisis hasta la
implementación.
 MetaCASE:
Herramientas que permiten la definición de nuestra
propia técnica de modelado, los elementos permitidos
del metamodelo generado se guardan en un repositorio
y pueden ser usados por otros analistas, es decir, es
como si definiéramos nuestro propio UML, con nuestros
elementos, restricciones y relaciones posibles.
  CAST (Computer-Aided Software Testing):
Herramientas de soporte a la prueba de software.
 IPSE (Integrated Programming Support Environment):
Herramientas que soportan todo el ciclo de vida,
incluyen componentes para la gestión de proyectos y
gestión de la configuración activa.
Por funcionalidad, se pueden diferenciar algunas, como las
herramientas de generación semiautomática de código, los
editores UML, las herramientas de refactorización de código,
y las herramientas de mantenimiento como los sistemas de
control de versiones.

Ciclo de Vida de Desarrollo de Software 

El ciclo de vida es el conjunto de fases por las que pasa el
sistema que se está desarrollando desde que nace la idea
inicial hasta que el software es retirado o remplazado (Osea,
se muere). También se denomina a veces paradigma. En
total, son 3 fases, y estas son:

1.) La fase de planificación y análisis:

El proceso comienza con una fase inicial de planificación, que
incluye un análisis de requisitos. Los clientes pueden tener
una idea general del tipo de producto que necesitan, pero
esta información no nos aporta nada de cómo debe ser la
aplicación en realidad. Por ello, los profesionales del software
se fijan en los requisitos que piden los clientes para estudiar
qué requisitos están incompletos, cuales son ambiguos y
cuales son simplemente contradictorios. Para prevenir que los
requisitos que sean incorrectos, es útil hacer demostraciones
prácticas de cómo funcionaría la aplicación con frecuencia. La
siguiente fase sería fijar el alcance del proyecto de
desarrollo y ponerlo por escrito en un documento de forma
clara y concisa.

2.) Fases de implementación, pruebas y documentación del

código:
La implementación consiste en el desarrollo y
programación del código. Esto lo hacen los ingenieros del
software. La prueba o testeo del software es una parte
fundamental en el proceso de desarrollo del software, porque
asegura que los errores sean detectados en fases muy
tempranas y sobre todo, que puedan ser corregidos lo antes
posible. La documentación interna del diseño del software se
realiza durante todo el proceso de programación del código
de la aplicación. Esto ayudará mucho a mantener y mejorar el
programa en el futuro. El desarrollo de un interfaz de
programación de la aplicación o una API también puede
formar parte del proceso de documentación. El equipo de
desarrollo elige el proceso de ingeniería del software y sus
fases. También acordarán cuanta documentación interna se
necesita.

3.) Fases de despliegue y mantenimiento del software:

Estas fases solo se dan cuando el software ya ha sido
testado internamente de manera exhaustiva y esté ya
disponible en el mercado. A mayores, es recomendable
incluir formación y soporte, porque el software es efectivo
cuando se usa de forma apropiada. El mantenimiento y
mejora de los productos de software es crucial para poder
corregir defectos que vayan surgiendo o para poder atender a
los requisitos del software. Esto podría tomar mucho tiempo,
ya que en ocasiones hay que volver a empezar a diseñar y
programar el software desde cero.

Modelos que apoyan y soportan las diferentes

fases del proceso del Ciclo de Vida de Desarrollo
de Software 
Los modelos de desarrollo de software son una
representación abstracta de una manera en particular.
Realmente, esto no representa cómo se debe desarrollar el
software, sino de un enfoque común. Puede ser modificado y
adaptado de acuerdo a las necesidades del software en
proceso de desarrollo. Hay varios modelos para perfilar el
proceso de desarrollo, cada uno de las cuales cuenta con
pros y contras. El proyecto debería escoger el más apropiado
para sus necesidades. En ocasiones puede que una
combinación de varios modelos sea apropiado:
 Modelo de cascada:
El modelo de cascada define las siguientes etapas que deben
cumplirse de forma sucesiva:
1. ) Especificación de requisitos
2. ) Diseño del software
3. ) Construcción o Implementación del software
4. ) Integración
5. ) Pruebas (o validación)
6. ) Despliegue (o instalación)
7. ) Mantenimiento
Siguiendo el modelo de cascada de forma estricta, sólo
cuando se finaliza una fase, comienza la otra. En ocasiones
se realiza una revisión antes de iniciar la siguiente fase, lo
que permite la posibilidad de cambios (lo que puede incluir un
proceso de control formal de cambio). Las revisiones también
se utilizan para asegurar que la fase anterior ha sido
totalmente finalizada; Los criterios para completar una fase se
conocen frecuentemente con el término inglés "gate" (puerta).
Este modelo desaconseja revisitar y revisar fases que ya se
han completado. Esta falta de flexibilidad en un modelo de
cascada puro ha sido fuente de crítica de los defensores de
modelos más flexibles.
 Modelo de espiral:
La principal característica del modelo en espiral es la gestión
de riesgos de forma periódica en el ciclo de desarrollo. Este
modelo fue creado en 1988 por Barry Boehm, combinando
algunos aspectos clave de las metodologías del modelo de
cascada y del desarrollo rápido de aplicaciones, pero dando
énfasis en un área que para muchos no jugó el papel que
requiere en otros modelos: un análisis iterativo y concienzudo
de los riesgos, especialmente en el caso de sistema
complejos de gran escala.
La espiral se visualiza como un proceso que pasa a través de
algunas interacciones con el diagrama de los cuatro
cuadrantes representativos de las siguientes actividades:
1.) Crear planes con el propósito de identificar los
objetivos del software, seleccionados para implementar el
programa y clarificar las restricciones en el desarrollo del
software;
 2.) Análisis de riesgos: una evaluación analítica de
programas seleccionados, para evaluar como identificar y
eliminar el riesgo.
3.) La implementación del proyecto: implementación del
desarrollo del software y su pertinente verificación.
El Modelo de espiral con énfasis en los riesgos, haciendo
hincapié en las condiciones de las opciones y limitaciones
para facilitar la reutilización de software, la calidad del
software puede ayudar como una meta propia en la
integración en el desarrollo del producto. Sin embargo, el
modelo en espiral tiene algunas limitaciones, entre las que
destacan:
1.) El énfasis se sitúa en el análisis de riesgo, y por lo
tanto requiere de clientes que acepten este análisis y
actúen en consecuencia. Para ello es necesaria
confianza en los desarrolladores así como la
predisposición a gastar más para solventar los temas,
por lo cual este modelo se utiliza frecuentemente en
desarrollo interno de software a gran escala.
2.) Si la implementación del riesgo de análisis afectará
de forma esencial los beneficios del proyecto, no debería
utilizarse este modelo.
3.) Los desarrolladores de software han de buscar de
forma explícita riesgos y analizarlos de forma exhaustiva
para que este modelo funcione.
La primera fase es la búsqueda de un plan para conseguir los
objetivos con las limitaciones del proyecto para así buscar y
eliminar todos los riesgos potenciales por medio de un
cuidadoso análisis, y si fuera necesario incluyendo la
fabricación de un prototipo. Si es imposible descartar algunos
riesgos, el cliente ha de decidir si es conveniente terminar el
proyecto o seguir adelante ignorando los riesgos. Por último,
se evalúan los resultados y se inicia el diseño de la siguiente
fase.
 Modelo iterativo e incremental:
El modelo iterativo recomienda la construcción de secciones
reducidas de software que irán ganando en tamaño para
facilitar así la detección de problemas de importancia antes
de que sea demasiado tarde. Los procesos iterativos pueden
ayudar a desvelar metas del diseño en el caso de clientes
que no saben cómo definir lo que quieren.

 Modelo ágil:
El modelo ágil de software utiliza un desarrollo iterativo como
base para abogar por un punto de vista más ligero y más
centrado en las personas que en el caso de las soluciones
tradicionales. Los procesos ágiles utilizan retroalimentación
en lugar de planificación, como principal mecanismo de
control. La retroalimentación se canaliza por medio de
pruebas periódicas y frecuentes versiones del software. En el
caso de la programación extrema (XP), las fases se realizan
en pasos muy cortos (o "continuos") con respecto al anterior.
El primer paso (intencionalmente incompleto) por los pasos
puede ocurrir en un día o en una semana, en lugar de los
meses o años de cada paso completo en el modelo en
cascada. En primer lugar, se crean pruebas automatizadas
para proveer metas concretas al desarrollo. Después se
programa el código, que será completo cuando todas las
pruebas se superan sin errores, y los desarrolladores ya no
sabrían cómo mejorar el conjunto de pruebas necesario. El
diseño y la arquitectura emergen a partir de
la refactorización del código, y se da después de programar.
El diseño lo realizan los propios desarrolladores del código. El
sistema, incompleto, pero funcional se despliega para su
demostración a los usuarios (al menos uno de los cuales
pertenece al equipo de desarrollo). Llegado este punto, los
profesionales comienzan a escribir las pruebas para la
siguiente parte del sistema de más importancia.

Además de eso, también existen tres paradigmas de

los modelos de desarrollo de software:
1.) Paradigma Tradicional:
Es uno de los paradigmas más antiguos, se inventó durante
la creación del método estructurado. Si se elige un proyecto,
el método varía en etapas. Si se aplica este paradigma, unos
de los principales problemas, es que las etapas realizadas no
son autónomas de las siguientes, creando una dependencia
estructural que en la ocasión de un error, atrasaría todo el
proyecto. Se tiene que tener pautas bien definidas, y que no
se incurra a modificación porque implicaría en que el software
no cumpla con su ciclo de vida. Se debe tener en cuenta que
el cliente no se vea afectado por la impaciencia.
2.) Paradigma Orientado a Objetos:
Estos modelos se basan en la programación orientada a
objetos; por lo tanto, se refiere al concepto de clase, el
análisis de requisitos y el diseño. El modelo o paradigma
orientado a objetos posee dos características principales, las
cuales permiten la reutilización de software y facilitan el
desarrollo de herramientas informáticas de apoyo al
desarrollo, el cual es simple al implementarla en una notación
orientado a objetos llamado UML.
3.) Paradigma de Desarrollo Ágil:
Es un paradigma basado en procesos ágiles. Estos intentan
evitar los tediosos caminos de las metodologías tradicionales
enfocándose en las personas y los resultados. Usa un
enfoque basado en el valor para construir software,
colaborando con el cliente e incorporando los cambios
continuamente.