Maestría en Redes y Sistemas Integrados

Fundamentos y Requerimientos de la
Ingeniería de Software
Fundamentos de Ingeniería de software
MC. Yesenia Hernández Velázquez
yesenia.hernandez@lania.edu.mx

Mayo 2020

TODOS LOS DERECHOS RESERVADOS

Agenda
1. Fundamentos de Ingeniería de software

1. El papel evolutivo del software

2. El proceso de desarrollo de software

3. Metodologías de desarrollo de software

4. Herramientas CASE y de soporte al proceso de desarrollo

Introducción

▪¿Qué es Ingeniería de
Software?

3
 Conceptos importantes

Software
Es el conjunto de los programas de cómputo, procedimientos,
reglas, documentación y datos asociados, que forman parte de
las operaciones de un sistema de computación [IEEE-610]

Los productos de Software pueden ser:

Genéricos: Desarrollados para venderse a un rango de clientes diferentes.
Hechos a la medida: desarrollado para un cliente único de acuerdo a sus
especificaciones

Un software nuevo puede crearse desarrollando programas nuevos,

configurando sistemas genéricos de software o reusando software
existente.

4
Conceptos Importantes

Del sistema

De tiempo
I.A real

Software
Web De gestión

De ingeniería
Incrustado o científico

5
Características que diferencian a un software
de otro.
▪Complejidad

▪Significado y forma de la información de entrada y

salida

▪Compartir recursos

▪La interacción con el Hardware (HW)

▪El objetivo para lo que fueron diseñados

6
EL PAPEL EVOLUTIVO DEL
SOFTWARE

EL TÉRMINO SOFTWARE SURGIÓ EN 1957

Eras de Software
▪Era Cero - 1940
• Los primeros sistemas computacionales no poseían
sistemas operativos.
• Los usuarios tenían completo acceso al lenguaje de la
maquina.
• Todas las instrucciones eran codificadas a mano.
Primera era 1950 - 1965
▪ Distribución limitada
▪ Software “a medida”
▪ Se trabajaba con la idea de “Codificar y
Corregir”
▪ No existía un planteamiento previo
▪ No existía documentación de ningún
tipo.
▪ Existencia de pocos métodos formales y
pocos creyentes en ellos.
▪ Desarrollo a base de prueba y error.

9
Segunda era 1965- 1972
▪Se busca simplificar código
▪Aparición de Multiprogramación y Sistemas
Multiusuarios
▪Sistemas de Tiempo Real apoyan la toma de decisiones
▪Aparición de Software como producto. (Casas de
Software)
▪INICIO DE LA CRISIS DEL SOFTWARE
▪Se buscan procedimientos para el desarrollo del
Software.

10
Tercera era 1972 - 1985
▪Nuevo Concepto: Sistemas Distribuidos

▪Complejidad en los Sistemas de Información

▪Aparecen: Redes de área local y global, y Comunicadores

Digitales

▪Amplio Uso de Microprocesadores.

11
Cuarta era 1985- 1995
▪Impacto Colectivo de Software

▪Aparecen: Redes de Información, Tecnologías

Orientadas a Objetos

▪Aparecen: Redes Neuronales, Sistemas Expertos y SW de

Inteligencia Artificial

▪La información como valor preponderante dentro de las

Organizaciones.

12
Quinta era
▪Utiliza algunos requisitos de las eras anteriores solo que
aumenta la omnipresencia de la web, la reutilización de
información y componentes de software

▪Codificar: Transformar mediante las reglas de un código

la formulación de un mensaje

▪Hardware: Componente físico de la computadora. Por

ejemplo: el monitor, la impresora o el disco rígido. El
hardware por sí mismo no hace que una máquina
funcione. Es necesario, además, instalar un Software
adecuado.

13
Quinta era
▪ Microprocesador: Es la parte más importante del ordenador, se
encarga de realizar todos los cálculos y controla su funcionamiento.
La velocidad de este "cerebro" determina la del ordenador

▪ Multiprogramación: Se denomina multiprogramación a la técnica

que permite que dos o más procesos ocupen la misma unidad de
memoria principal y que sean ejecutados al "mismo tiempo“

▪ Multiusuario: Capacidad de algunos sistemas para ofrecer sus

recursos a diversos usuarios conectados a través de terminales.

▪ Preponderante: Que prepondera, prevalece o tiene cualquier tipo

de superioridad respecto a aquello con lo que es comparado
14
 Ingeniería de Software
▪ La aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el
desarrollo, operación y mantenimiento del software; es decir, la aplicación de
ingeniería al software [IEEE 610]

▪ La ingeniería de software es una disciplina de ingeniería que se ocupa de todos

los aspectos de producción de Software.

15
Ingeniería de Software
▪ Se ocupa de todos los aspectos de producción de Software
Ingenieriles
Administrativos

16
Ingeniería de Software
Ingeniería de
software

Aplicación y
Gestión de Gestión de la
desarrollo del
proyectos calidad
software

Definición de
Planeación Planeación
requisitos

Producción Control Control

Introducción y
Entrega Validación
uso

17
Mitos en el desarrollo de software
▪MITO
Una declaración general de los objetivos es suficiente para
comenzar a escribir los programas. Podemos dar los detalles más
adelante

▪REALIDAD
Una mala definición inicial es la principal causa del trabajo inútil
en software

18
Mitos en el desarrollo de software
▪MITO
Si fallamos en la planificación,
podemos añadir más
programadores y adelantar el
tiempo perdido

▪REALIDAD
El desarrollo de software no es un
proceso mecánico como la
fabricación. «...añadir gente a un
proyecto de software retrasado lo
retrasa aún más»

19
Mitos en el desarrollo de software
▪MITO
Hasta que el programa está «ejecutándose», realmente no existe
una forma de comprobar su calidad

▪REALIDAD
Desde el principio del proyecto se pueden aplicar mecanismos
efectivos para garantizar la calidad del software

20
Atributos de un buen software
▪ Funcionalidad
El software debe desarrollar los servicios para los que fue creado
▪ Mantenibilidad
El software debe poder evolucionar para cumplir con las
necesidades de cambio de los clientes
▪ Confiabilidad
El software debe ser fiable, seguro, no debe causar daños físicos o
económicos en el caso de una falla del sistema
▪ Eficiencia
El software debe aprovechar al máximo los recursos del sistema
▪ Usabilidad
El software debe ser fácil de utilizar.

21
 PROCESO DE DESARROLLO DE SOFTWARE

Requisitos, necesidades

¿Cómo se hace un proyecto

de software? Sistema de software
Introducción
▪ ¿Por qué se necesita de un proceso formal de desarrollo de
software?
• Frecuentemente ocurren fallas
• Desarrollar un sistema no es intuitivo
• Los proyectos exceden limites de tiempo, presupuesto y tienen menos
funcionalidad de la planeada

▪ Un analista es una persona clave, responsable de:

• Diseñar un sistema e incorporar valor agregado
• Entender los procesos de negocio
• El trabajo es gratificante pero difícil
• Requiere habilidades específicas

23
Ciclo de vida de un sistema

Planear

Implementar Analizar

Diseñar

24
El proceso del ciclo de vida
▪ El proceso consiste de cuatro fases, en las que:
• Consiste de una serie de pasos
• Tiene un conjunto de entregables

▪ Las fases se ejecutan secuencialmente,

incrementalmente, iterativamente o siguiendo algún
otro patrón

25
Preguntas a resolver
▪Fase: Planeación
• ¿Por qué debería construirse el sistema?
• ¿Qué valor o beneficio se obtendrá?
• ¿En que tiempo se construirá?
▪Fase: Análisis
• ¿Quién usará el Sistema?
• ¿Quién hará el Sistema?
• ¿Dónde y cuándo será utilizado?
▪ Fase: Diseño
• ¿Cómo se construirá?
• ¿Qué arquitectura?
• ¿Cómo y donde se administraran los datos?

26
Fase: Planeación
1. Comienzo del proyecto
• Desarrollar/recibir el requerimiento de desarrollo de software
• Realizar un análisis de factibilidad
Factibilidad técnica
Factibilidad económica
Factibilidad organizacional

2. Administrar el proyecto
• Desarrollar un plan de trabajo
• Asignar recursos humanos al proyecto
• Monitorear y controlar el proyecto

27
Fase: Análisis
1. Desarrollar una estrategia de análisis
• Modelar el Sistema actual
• Proponer el nuevo sistema
2. Recopilar requerimientos
• Desarrollar el concepto del sistema
• Crear un modelo de negocio para representar:
Datos del negocio
Procesos de negocio
3. Desarrollar una propuesta del sistema

28
Fase: Diseño
1. Desarrollar una estrategia de diseño
2. Desarrollar arquitectura e interfaces
3. Desarrollar base de datos y especificaciones de
archivos
4. Desarrollar el diseño especifico de programas:
• ¿Qué programas deben escribirse?
• ¿Qué es lo que hará cada programa?

29
Fase: Implementación
1. Construir el sistema
• Escribir código
• Realizar pruebas
2. Instalar el sistema
• Capacitar usuarios
3. Realizar mantenimiento al sistema

30
El proceso de desarrollo
▪Es un conjunto de actividades cuya meta es el desarrollo o
evolución de software.

▪Algunas actividades genéricas en todo proceso de software

son:

• Especificación: Que es lo que el sistema debe hacer y sus restricciones

de diseño
• Desarrollo: Producción del sistema de software
• Validación: Checar que el software sea lo que los clientes desean
• Evolución: Cambiar el software en respuesta a las modificaciones
demandadas.
El proceso de desarrollo de software

• Conjunto estructurado de actividades y

Proceso resultados requeridos para desarrollar un
sistema de software

• Indican el como realizar la construcción de

software desde una perspectiva técnica.
Métodos Considera actividades desde comunicación y
análisis de requerimientos hasta soporte

• Proporcionan soporte automático o

Herramientas semiautomático para procesos y métodos

32
El proceso de desarrollo de software

Calidad

Proceso

Métodos

Herramientas

33
Modelos de desarrollo
▪ Definen un conjunto de actividades, acciones, tareas, puntos de
control, y productos de trabajo que son requeridos para producir
software de calidad.

▪ Aunque son perfectibles proporcionan estabilidad, control y

organización a una actividad que pudiera resultar caótica.

▪ Todo modelo debe ser adaptado para aplicarse efectivamente a

un proyecto específico

34
Modelos de desarrollo
▪Una organización podría variar su modelo de proceso
para cada proyecto, según:

• La naturaleza del proyecto

• La naturaleza de la aplicación

• Los métodos y herramientas a utilizar

• Los controles y entregas requeridas

35
Modelos de desarrollo

Modelos de
desarrollo

Modelo Modelo
Modelo en Modelo en
incremental Evolutivo:
cascada espiral
(RAD) Prototipado

36
Modelo de cascada
• Inicio de proyecto
Comunicación
• Identificación de requerimientos

• Estimación
Planeación • Calendarización
• Seguimiento

• Análisis
Modelado
• Diseño

• Codificación
Construcción
• Pruebas

• Entrega
Despliegue • Soporte
• Retroalimentación

37
Modelo en cascada
▪Propuesto por Winston Royce en 1970

▪Conocido como modelo secuencial lineal

▪Encadenamiento secuencial de las actividades
▪Cada etapa produce documentos que son la entrada a
la siguiente
▪Para desarrollar una etapa debe concluirse la anterior
▪Popular en la década 70

38
Modelo Incremental
Análisis
Funcionalidad y características

Diseño
Iteración # n
Implementación
Pruebas
Despliegue

Iteración # 2

Iteración # 1

Tiempo
39
Modelo Incremental
▪ Combina elementos del modelo en cascada aplicado en forma iterativa
▪ Desarrollo paso a paso donde las partes de algunas etapas se
posponen
▪ Permite construir el proyecto en etapas incrementales en donde cada
etapa agrega funcionalidad
▪ Cada etapa consiste en
• Requerimientos
• Diseño
• Codificación
• Pruebas
• Entrega

▪ Permite entregar al cliente un producto más rápido.

40
Modelo Incremental (RAD)
Rapid Application Development
Modelado

Construcción

Comunicación
Modelado

Despliegue
Planeación Construcción
Modelado

Construcción

60 a 90 días
 Modelo de desarrollo rápido de aplicaciones
(RAD)
▪Es una adaptación a "alta velocidad" del modelo en
cascada
▪Modelo secuencial lineal con tiempos cortos de desarrollo
▪Varios equipos participando en el desarrollo
▪Cada equipo maneja una parte del sistema
▪Uso de herramientas de pruebas automatizadas
▪En cada etapa de liberación, los productos parciales son
integrados, probados y liberados

42
 Modelo de desarrollo rápido de aplicaciones
(RAD)
El modelado incluye tres grandes fases
▪Modelado de negocios,
▪Modelado de datos y
▪Modelado del proceso

La construcción resalta:
▪El empleo de componentes de software existente y
▪La aplicación de la generación automática de código

43
Modelo evolutivo prototipado
Comunicación

Planeación
Despliegue
rápida

Construcción Modelado
de prototipo rápido

44
Modelo prototipado
▪¿Qué es un prototipo?
• Versión preliminar de un sistema de información con fines de
demostración o evaluación.

▪Es un método menos formal de desarrollo

▪El prototipeo es una técnica para comprender las
especificaciones
▪Un prototipo puede ser eliminado
▪Un prototipo puede ser parte del producto final

45
Modelo Evolutivo en Espiral

46
Modelo en Espiral
▪Propuesto por Barry Boehm en 1988
▪Desarrollo en ciclos

▪En cada ciclo:

• se define el objetivo,
• se analizan los riesgos,
• desarrollo y verificación de la solución obtenida,
• revisión de resultados y planificación del siguiente ciclo

▪Se centra en algunas mejores prácticas:

• Manejo de Riesgos
• Orientación al Cliente
• Desarrollo Iterativo

47
Actividad
•Para cada uno de los modelos mencionados
previamente, elabora una tabla presentando
ventajas y desventajas.

• Asigna a tu actividad el nombre ISW-Apellido-

Nombre y súbela a la plataforma de Moodle.

48
¿Qué modelo utilizar?
▪Dado que cada proyecto es único, no existe un modelo
que se aplique al 100% a todos los proyectos de una
organización.

▪Una organización puede contar con uno o más

modelos de desarrollo para ser utilizados
dependiendo del tipo de proyecto.

▪El modelo seleccionado tendrá influencia en el éxito

del proyecto y en el tipo de decisiones que se deberán
hacer.

49
¿Qué modelo utilizar?
▪ ¿Qué tanto el cliente y nosotros conocemos el sistema?
▪ ¿Qué tan claros están los requerimientos?
▪ ¿Se conoce bien la tecnología a utilizar?
▪ ¿Qué tantos son los riesgos del proyecto?
▪ ¿Qué tan bien conocemos la arquitectura?
▪ Visibilidad que requiere el cliente del proyecto
▪ Visibilidad que requiere el proyecto hacia la gerencia
▪ ¿Qué tanta planeación hacia adelante es requerida?
▪ ¿Qué restricciones se tienen?
50
METODOLOGÍAS DE DESARROLLO DE
SOFTWARE
Metodologías de desarrollo de software
▪Una metodología de desarrollo de software se
denominará como tal cuando responda a las
preguntas:

• ¿Qué actividad debe realizar?

• ¿Quién debe efectuar las actividades (rol)?

• ¿Cuándo deben llevarse a cabo las actividades?

• ¿Cómo realizar cada actividad?

52
Metodologías de desarrollo de software
▪Tradicionales:
• uso exhaustivo de diferentes artefactos durante todo el ciclo del
proyecto

• Control específico de proceso y artefactos generados

• Comunicación formal con los clientes

Planteamiento Análisis Diseño Programación Pruebas Ejecución

53
Metodologías de desarrollo de software
▪Ágiles:
• Importancia en la capacidad de respuesta a los cambios

• Confianza en las habilidades del equipo

• Mantener una buena relación con el cliente

Requerimientos Ejecución
Planteamiento
priorizados

54
Metodologías tradicionales
▪Diseño Estructurado [Yourdon, Constantine, 1979]
• Revisión de fundamentos por medio de la representación a través de un
diagrama de contexto
• Revisión y refinamiento a través de diagramas de flujo de datos
(Representación del movimiento de datos entre unidades externas,
procesos y BD dentro de un sistema)
• Determinación de transacciones en un DFD
• Especificación de entradas y salidas para cada transacción
• Refactorización de DFD en dos niveles
• Refinamiento aplicando heurísticas de diseño

55
Diagrama de contexto
▪Sirve para representar los límites del sistema, es
decir permite distinguir lo que es el sistema y su
entorno.

▪Ayuda a definir lo que hace y lo que no hace parte

del sistema.

▪La definición del contexto implica aspectos sociales y

organizacionales.

56
Ejemplo de un diagrama de contexto

57
Metodologías tradicionales
▪Proceso Unificado de Desarrollo de Software
[Jacobson, Booch, Rumbaugh, 1999]

• Puede ser utilizado para una gran cantidad de tipos de sistemas

de software, para diferentes áreas de aplicación, diferentes tipos
de organizaciones, diferentes niveles de competencia y
diferentes tamaños de proyectos

58
Proceso unificado
• Su meta es asegurar la producción de software de muy alta
calidad que satisfaga las necesidades de los usuarios finales,
dentro de un calendario y presupuesto predecible
• Tiene dos dimensiones:

• Un eje horizontal que representa el tiempo y muestra los aspectos del

ciclo de vida del proceso a lo largo de su desenvolvimiento

• Un eje vertical que representa las disciplinas, las cuales agrupan

actividades de una manera lógica de acuerdo a su naturaleza.

59
Proceso unificado

60
Proceso unificado
▪Usa el Lenguaje de Modelado Unificado (UML) en la
preparación de todos los planos del sistema. De hecho,
UML es una parte integral del Proceso Unificado, fueron
desarrollados a la par.

Aspectos distintivos:
▪Es dirigido por casos de uso (use-case driven)

▪Centrado en la arquitectura (architecture-centric)

▪Iterativo e incremental

61
Proceso unificado
▪Un caso de uso es una pieza en la funcionalidad del
sistema que le da al usuario un resultado de valor. Los
casos de uso capturan los requerimientos funcionales.
▪El concepto de arquitectura de software involucra los
aspectos estáticos y dinámicos más significativos del
sistema.
▪En cada iteración, los desarrolladores identifican y
especifican los casos de uso relevantes, crean el diseño
usando la arquitectura como guía, implementan el diseño
en componentes y verifican que los componentes
satisfacen los casos de uso.

62
Metodologías agiles

63
Metodologías agiles
▪La ingeniería de software ágil combina una filosofía con
un conjunto de lineamientos
• La satisfacción del cliente
• Entrega rápida de software incremental
• Equipos pequeños y muy motivados para efectuar el proyecto
• Métodos informales
• Los productos del trabajo con mínima ingeniería de software y
• La sencillez general en el desarrollo
• Enfatizan la entrega sobre el análisis y el diseño
• Comunicación activa y continua

64
Proceso Ágil
▪Un proceso ágil debe ser adaptable incrementalmente
▪Debe haber retroalimentación con el cliente
▪Se usa el prototipo como incrementos de software

1. Es difícil predecir qué requerimientos de software

persistirán y cuáles cambiarán.
2. Para muchos tipos de software, el diseño y la construcción
están inmersos. Es difícil predecir cuánto diseño se necesita
antes de que se use la construcción para probar el diseño.
3. El análisis, el diseño, la construcción y las pruebas no son
tan predecibles como nos gustaría

65
El espíritu ágil
▪La alianza ágil define 12 principios a seguir para
todos aquellos equipos que deseen alcanzar agilidad
en sus procesos de desarrollo.

▪No todo proceso ágil aplica los 12 principios con el

mismo énfasis.

▪Los principios definen el espíritu ágil de los procesos

de desarrollo de software
https://www.agilealliance.org/

66
Principios para alcanzar agilidad
1. Satisfacer al cliente mediante la entrega temprana y continua de
software útil.
2. Aceptar los cambios de requerimientos, incluso en fases avanzadas
del desarrollo.
3. Entregar software funcional frecuentemente.
4. Los ejecutivos y los desarrolladores deben trabajar juntos
diariamente.
5. Proporcionar a los individuos el ambiente y los medios para que se
sientan motivados.
6. Las conversaciones cara a cara son el medio más efectivo para
transmitir información.

67
Principios para alcanzar agilidad
7. El software funcional es la principal medida de progreso.

8. Los patrocinadores, desarrolladores y usuarios deberán mantener un

ritmo constante indefinidamente.

9. La atención continua a la excelencia técnica y al buen diseño

incrementa la agilidad.

10. La simplicidad es esencial.

11. Las mejores arquitecturas, diseños y requerimientos provienen de

equipos auto-organizados.

12. Regularmente el equipo reflexiona sobre cómo ser más eficaz, con lo
que afina y ajusta su comportamiento.

68
Factores humanos
▪El proceso ágil se debe amoldar a las necesidades de
la gente y del equipo, no al contrario.
▪Características del equipo que adapta o amolda el
proceso ágil:
• Capacidad.
• Enfoque común.
• Colaboración.
• Habilidad de toma de decisión.
• Habilidad para resolver problemas confusos.
• Confianza y respeto mutuos.
• Auto-organización.

69
Extreme Programing
•Historias de usuario (el cliente asigna
prioridad a cada historia)
•Valores de aceptación
•Criterios de prueba
Liberación Planeación •Plan de iteraciones

• Incremento del software

• Diseño simple
• Tarjetas CRC
• Prototipos
Pruebas Diseño •Principio KIS
•Alienta el uso
• Pruebas de unidad de refactoring
• Integración continua
• Pruebas de aceptación
Codificación • Programación en pares
• Pruebas de unidad
• Refactorización

70
71
Tareas de Ingeniería

72
Pruebas de aceptación

73
Tarjetas CRC

74
Algunos Roles
▪Programador
▪Cliente
▪Encargado de pruebas
▪Encargado de Seguimiento
▪Entrenador
▪Consultor
▪Gestor

75
Adaptive Software Development
•Ciclo de planeación adaptativo
•Identificación de misión
•Restricciones del proyecto
Especulación •Requerimientos base
• Plan de liberaciones ajustado a
Liberación tiempo

• Incremento del software

• Ajuste para ciclos subsecuentes

Aprendizaje Colaboración

• Levantamiento de requerimientos
• Pruebas e implementación de componentes
• Sesiones JAD
• Focalización en retroalimentación
• Mini especificaciones
• RTF , postmortems

76
Otras metodologías agiles
• Kanban
• Scrum
• Scrumban
• Crystal
• Feature Driven Development
• Agile Unified Process
• Desarrollo ligero (Lean)
• Dynamic System Development Method (DSMD)

77
¿Qué metodología utilizar?
Útil para Cascada Paralela Escalonada Prototipado Sketch* XP

Requerimientos Pobre Pobre Buena Excelente Excelente Excelente

poco claros

Tecnología Pobre Pobre Buena Pobre Excelente Pobre

desconocida

Sistemas Buena Buena Buena Pobre Excelente Pobre

complejos
Sistema fiable Buena Buena Buena Pobre Excelente Buena

Limitación de Pobre Buena Excelente Excelente Buena Excelente

tiempo
Prueba de Pobre Pobre Excelente Excelente Buena Buena
concepto
* Prototipo de usar y tirar

78
Actividad 2
• Investiga las características clave de una de las 8
metodologías ágiles indicadas previamente y realiza un
diagrama que las ilustre. Expón tu trabajo al grupo.

1. Kanban
2. Scrum
3. Scrumban
4. Crystal (2 personas)
5. Feature Driven Development
6. Agile Unified Process
7. Desarrollo ligero (Lean)
8. Dynamic System Development Method (DSMD)

79
Comparando
Metodologías Tradicionales Metodologías Ágiles
Basadas en normas provenientes de estándares seguidos Basadas en heurísticas provenientes de prácticas de
por el entorno de desarrollo producción de código
Cierta resistencia a los cambios Especialmente preparados para cambios durante el
proyecto
Impuestas externamente Impuestas internamente (por el equipo)
Proceso mucho más controlado, con numerosas Proceso menos controlado, con pocos principios.
políticas/normas
El cliente interactúa con el equipo de desarrollo mediante El cliente es parte del equipo de desarrollo
reuniones
Más artefactos Pocos artefactos
Más roles Pocos roles
Grupos grandes y posiblemente distribuidos Grupos pequeños (<10 integrantes) y trabajando en el
mismo sitio
La arquitectura del software es esencial y se Menos énfasis en la arquitectura del software
expresa mediante modelos
Existe un contrato prefijado No existe contrato tradicional o al menos es bastante
flexible

80
Herramientas CASE y de soporte al proceso
de desarrollo
Herramientas CASE
▪CASE: Ingeniería de software Asistida por Computadora

▪Es un producto destinado al soporte de una o mas

actividades de ingeniería del software dentro de un
proceso de desarrollo de software

▪“Una combinación de herramientas de software y

metodologías de desarrollo”

82
Herramientas CASE
▪ Repositorio integrado. En el repositorio se almacena toda la
información de uno o varios sistemas de información

• El dominio de los sistemas desarrollados o en desarrollo

• Modelos de solución e implementación

• Información de la metodología que está siendo usada

• Historia de los proyectos, recursos, presupuestos, etc.

• Contexto organizacional: organigramas, planes estratégicos, factores críticos de

éxito, etc.

83
Objetivos
▪Aumentar la productividad de las áreas de desarrollo y
mantenimiento de los sistemas informáticos
▪Mejorar la calidad del software desarrollado
▪Reducir tiempos y costos de desarrollo y mantenimiento del
software
▪ Mejorar la gestión y dominio sobre el proyecto en cuanto a su
planificación, ejecución y control
▪Mejorar el archivo de datos (enciclopedia) de conocimientos
(know-how) y sus facilidades de uso, reduciendo la
dependencia de analistas y programadores.

84
Herramientas CASE
▪Automatizar :
• El desarrollo del software
• La documentación
• La generación del código
• El chequeo de errores
• La gestión del proyecto

▪Permitir:
• La reutilización (reusabilidad) del software
• La portabilidad del software
• La estandarización de la documentación
• Integrar las Mejorar el archivo de datos (enciclopedia) de conocimientos
.
• Facilitar la utilización de las distintas metodologías que desarrollan la
propia ingeniería del software.

85
Clasificación
▪Existen diferentes clasificaciones, pero para fines
prácticos considera la propuesta por Ian Sommerville
(2008)

86
Clasificación
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) o front-
end, 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) o back-
end, 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 reingeniería,
orientadas a la fase de mantenimiento.

87
Herramientas CASE

88
Clasificación - Funcional

89
Ejemplos y costos
▪ Con soporte a modelado utilizando UML
• http://www.objectsbydesign.com/tools/umltools_byProduct.html
• http://www.uml.org/

▪ Con soporte a diferentes actividades del proceso

• https://sites.google.com/site/herramientascaseudelp/lista-de-herramientas
• https://es.scribd.com/doc/25374125/Estudio-de-Herramientas-CASE-de-Soporte-a-
UML-y-UML2

90
Evolución de las herramientas CASE
▪Editores y procesadores de texto: Usados para
escribir programas y su documentación

▪Programas de dibujo: Usado para incorporar

notaciones gráficas

▪La primera herramienta comercial aparece en 1982

91
Tendencias
▪1990’s Integración empresarial
• Métodos agiles
• Arquitecturas de software especificas de un dominio
• Desarrollo de Open source

▪2000’s Agilidad y valor

• Métodos agiles híbridos
• Arquitectura orientada a servicios
• Desarrollo guiado por modelos

92
¿Qué no se resuelve con una herramienta?
▪Definición incorrecta o incompleta de requerimientos:
considerando la naturaleza dinámica de un dominio de
negocio, en donde los cambios se darán en todo
momento. Esto es particularmente notorio en proyectos
grandes
▪La ingeniería de Software es una actividad de diseño de
soluciones basada en la creatividad. Una herramienta
automatiza actividades rutinarias.
▪Comunicación. En todo equipo de desarrollo de software
la comunicación es un elemento crucial. Las herramientas
pueden apoyar la comunicación de no la resuelven.

93
Actividad
▪Realiza una presentación general de las
herramientas indicadas a continuación

• Rational Rose
http://www-
01.ibm.com/software/awdtools/developer/rose/java/index.html
• ArgoUML –
http://argouml.tigris.org/
• Enterprise Architech
http://www.sparxsystems.com/products/ea/index.html
• Startuml
http://staruml.io/

94
Actividad

▪Incluya en su presentación: funciones generales,

posibles desventajas y costo (en caso de que
aplique)
▪La presentación no debe durar más de 5 minutos
▪La investigación es por equipo

95