Contenido 1. Importancia de Software 2. Evolución y características

Contenido
1.
2.
INGENIERIA DE SOFTWARE
Tema 1: Introducción a la Ingeniería de Software
3.
4.
5
5.
6.
Presenta: David Martínez Torres
7.
Universidad Tecnológica de la Mixteca
8.
Importancia del Software
Evolución y características del software
Tipos de software
La crisis del software
Definición de Ingeniería de Software
Paradigmas de ciclos de vida de la Ingeniería de software
Herramientas CASE
Referencias
dtorres@mixteco.utm.mx
Cubo 37
1
2
1. Importancia de Software
„
„
Las economías de los países desarrollados dependen en
gran parte del software.
Mas y más sistemas son actualmente controlados por
software.
„
„
„
„
Los primeros años (‘50 - ‘60)
„
„
Ej. Transportes, médicos, telecomunicaciones, militares,
procesos industriales, entretenimiento, productos de oficina,
educación, ingeniería genética, etc.
„
„
Sw como producto: entrega de potencia informática del
hw informático.
„
„
2. Evolución y características del software
La Segunda era (‘70)
„
Genéricos
Hechos a medida
Orientación Batch (por lotes)
Distribución limitada
Software a medida
„
Sw como vehículo: actúa como la base de control de la PC
(SO’s), la comunicación de info (redes) y la creación y
control de otros programas (herramientas sw y entornos)
Ambiente multiusuario y tecnología de
multiprogramación
Tiempo Real / Bases de datos / productos de software
(Casas de software)
3
… 2. Evolución y características del software
„
La Tercera era (‘80)
„
„
„
„
„
Sistemas distribuidos
Incorporación de
“inteligencia” a
productos
d t
(Firmware)
Redes y HW de bajo
costo
Microprocesadores
Consumo masivo
„
…2. Evolución y características del Software
„
La Cuarta era (‘90 a
la fecha)
„
„
„
„
„
„
4
Características del sw como producto
„
Mantenibles
„
PC’s potentes
Tecnología O-O
Sistemas expertos
Redes neuronales
Computación
paralela
Redes de
información
„
Confiabilidad
„
No debe causar daños físicos o económicos en el
caso de fallos
„
Eficiencia
„
Utilización adecuada
„
„
5
Que evolucione y que siga cumpliendo con sus
especificaciones
No debe desperdiciar los recursos del sistema
Debe contar con una interfaz de usuario adecuada y
su documentación
6
… 2. Evolución y características
„
… 2. Evolución y características
„
Características del Sw vs. Hw
„
„
„
„
“se estropea: desgaste de
materiales”
Producto lógico, no físico
Se desarrolla, no se fabrica
No se estropea (ver siguientes diapositivas)
Construcción a medida.
Mantenimiento complicado
Tasa de
e fallas
„
Curvas de fallas del Hardware
“Mortalidad Infantil”
Tiempo
7
… 2. Evolución y características
„
8
… 2. Evolución y características
Curvas de fallas del Software
„
Curvas de fallas de Sw “mas real”
Incremento de la tasa de fallas
por efectos laterales
Tassa de fallas
Tasa de
e fallas
“Fallas
Fallas por obsolescencia”
obsolescencia
“Puesta en marcha”
Cambio
Curva Real
Se mantiene nivel hasta la obsolescencia
Curva idealizada
Tiempo
Tiempo
9
3. Tipos de Sw
„
„
„
„
10
… 3. Tipos de Sw
Software de sistemas : Sistemas
operativos, editores, compiladores,
utilitarios de bajo nivel, cercano al
Hardware.
Software de Tiempo Real : Control de
p ocesos físicos
procesos
físicos. Altas limitaciones en
Tiempo-Respuesta, CAM.
Software de Gestión : Aplicaciones
administrativas, comerciales, contables,
SIG, inventarios, SAP/R3, etc.
Software de Ingeniería y Científico : Alto
uso de CPU, Ciencias (ej. Astronomía,
física, vulcanología...), CAD.
„
„
Software empotrado (Firmware) : Control del
funcionamiento en dispositivos electromecánicos.
Software de PC : Procesamiento de textos, hojas de cálculo,
multimedia, juegos, aplicaciones personales en bases de datos,
comercio, contabilidad, etc.
„
11
Software de Inteligencia Artificial : Usa algoritmos no
numéricos para resolver problemas complejos en que no son
adecuados el cálculo o el análisis directo. Reconocimiento de
imágenes, voz, símbolos (escritura), en general, situaciones en
que la entrada al sistema es compleja y aleatoria.
12
4. Crisis del Sw
„
„
… 4. Crisis del Sw
Constatación en una conferencia de la OTAN en 1968
Razones:
„
„
„
„
Miles de líneas de código
Incumplimiento de tiempos de desarrollo
Mantenimiento desbordado
Propuesta de solución:
„ Encapsulamiento de datos y procesos. Ejemplo:
construcción de interfaces.
„ Programación estructurada
„ Desarrollo masivo de componentes software
„ Reutilización de componentes. Bibliotecas de
subrutinas (sólo algoritmos).
13
5. Definición de Ingeniería de Sw
„
„
14
… 5. Definición de Ingeniería de Sw
[Somerville] Es una disciplina de ingeniería que
comprende todos los aspectos de la producción de
software.
„
[[Pressman]] Disciplina
l
o área
á
de
d la
l informática
f
á
o
ciencias de la computación que ofrece métodos y
técnicas para desarrollar y mantener software de
calidad que resuelven problemas de todo tipo.
„
La ingeniería de software es el establecimiento y uso
de principios robustos de la ingeniería a fin de
obtener económicamente software que sea fiable y
que funcione eficientemente sobre máquinas reales
La aplicación de un enfoque sistemático, disciplinado
y cuantificable hacia el desarrollo, operación y
mantenimiento del SW
15
5.1 Porque aplicar Ingeniería de Sw?
16
Actividades básicas de Ingeniería de Software
„
„
„
„
„
„
„
„
17
Definición del proceso de desarrollo de software que
se usará
Administración del proyecto de desarrollo
Descripción del producto de software que se desea
Diseño del producto
Implementación del producto (programación)
Prueba de las partes del producto
Integración de las partes del producto y pruebas del
producto completo
Mantenimiento del producto
Las cuatro “P” de la Ingeniería de Software
Personas
Unified Process Matrix
Jacobson et al: USDP
Inception Elaboration
Prelim.
iterations
Proceso
Personas
Iter.
#1
.. Iter.
#n
Construction
Iter.
#n+1
…..
Transition
Iter.
#m
Iter.
#m+1
…..
Iter.
#k
„
Requirements
Analysis
Design
Implementation
Test
(la manera
(quién lo hace)
en que se hace)
„
„
Proyecto
Producto
„
(la realización)
(la aplicación de artefactos)
„
Las interacciones entre las personas involucradas en un
proyecto de software tienen un efecto profundo en su
éxito.
Los equipos trabajan mejor cuando tienen conocimiento
de lo que se supone que deben hacer y cuando los
miembros tienen papeles específicos.
Revisar PSP, TSP y CMM, MOPROSOFT
Ver archivo “Una manera de decidir los aspectos iniciales
del equipo.docx”
Otro elemento del factor “personas” se refiere a los
interesados en el proyecto: personas que ganan o pierden
algo con los resultados del proyecto.
Reeditado de Ingeniería de Software: Una perspectiva Orientada a Objetos por Eric J. Braude (Wiley 2003)
Proceso
„
Desarrollo de secuencias:
„
„
„
Conjunto de actividades realizadas
para producir una aplicación
Unified Process Matrix
Jacobson et al: USDP
Inception Elaboration
Prelim.
iterations
Cascada
Iterativo
Construction
Iter. .. Iter. Iter.
#1
#n #n+1
…..
Iter.
#m
Transition
Iter. …..
#m+1
Iter.
#k
„
Analysis
Design
„
Implementation
Test
Personall Software
P
S f
P
Process
„ Team Software Process
„ Capability Maturity Model
(para organizaciones)
„
„
„
Institute of Electrical and Electronic Engineers (IEEE)
International Standards Organization (ISO)
Producto
„
Explica qué debe ser el producto
Arquitectura de software
„
Diseño detallado
„
Implementación
„
„
„
Usa el lenguaje de Patrones de diseño
Diseño del
modelo
Resalta los estándares
Emplea métodos formales seleccionados
Artefactos de prueba
Mejoras o uso del sistema
existente
6. Paradigmas o Modelos
del proceso de desarrollo de software
Ingeniería de Sistemas
Análisis
Usa la clasificación de Garlan and Shaw
„
„
Artefactos
Especificación
de requerimientos
de software
Requerimientos
„
„
La aplicación y los
artefactos asociados
e incluidos
LLenguaje
j de
d modelado
d l d
unificado: notación de diseño
Sistemas heredados: puntos de
inicio comunes
„
Estándares:
Flujo del trabajo
Estructurados
Orientación a Objetos:
paradigma útil
„
„
„
personas
Métodos:
„
Requirements
Marco de trabajo de los procesos:
Conjunto de actividades para
producir los artefactos requeridos
Proyecto
Diseño
Código
Pruebas
„
Modelo
Secuencial
(ciclo de
vida básico
o modelo en
cascada)
Mantención
Análisis
Diseño
Código
Códigos fuente
Y objeto
r
r
Procedimientos de prueba; casos de
pruebas
Pruebas
Mantención
24
… Modelo Secuencial
„
1.
Actividades:
Ingeniería y modelado de Sistemas/Información
„
2.
„
Actividades: (Continuación)
Generación de código o Implementación
„
4.
Ubicación del software en el ámbito donde va a funcionar.
„
Se deben conocer los aspectos relacionados con la información
a tratar, la función requerida, comportamiento, rendimiento, etc
del software.
El cliente debe dar el visto bueno
„
„
„
„
de los algoritmos
algoritmos.
De Caja Negra: Análisis de los procesos externos funcionales.
Mantenimiento
6.
„
Diseño
„
Puede automatizarse si el diseño está bien detallado.
Pruebas
„
De Caja Blanca: Análisis de los distintos caminos de ejecución
5.
Análisis de los requisitos del software
„
3.
… Modelo Secuencial
Gestión de cambios en el software debidos a:
„
Arquitectura del software
Estructura del programa
Representaciones de la Interfaz
Detalle Procedimental (algoritmo)
„
„
25
… 6. Modelos de proceso de software
„
Errores durante el desarrollo.
Adaptación a nuevos entornos. Ej. Sistema Operativo
Mejoras funcionales o de Rendimiento.
26
… … 6. Modelos de proceso de software
„
Modelo Prototipo
Modelo DRA(Desarrollo Rápido de Aplicaciones)
„
„
„
„
Es una adaptación a “alta velocidad” del modelo lineal
secuencial en el que se logra el desarrollo rápido
utilizando un enfoque de construcción basado en
componentes.
Puede permitir el desarrollo de un sistema
completamente funcional en periodos cortos de tiempo
(de 60 a 90 días).
Los componentes que se desarrollen se pueden
reutilizar en posteriores proyectos. Repositorio de
componentes.
El sistema se descompone en un conjunto de bloques
que se pueden desarrollar de manera independiente
por distintos equipos de desarrollo.
27
… 6. Diferentes Modelos de proceso de software:
EVOLUTIVOS
… Modelo DRA
„
Sólo puede aplicarse cuando se cumplen una serie de
condiciones:
„
„
„
„
28
Necesidad: El software, al igual que el resto de
sistemas evoluciona con el tiempo. Necesidad de
procedimientos que permitan una evolución del
software.
Se comprenden muy bien los requisitos del sistema a
desarrollar. Ya sea porque los conoce el propio desarrollador
o porque se tiene una experiencia previa en un sistema
similar.
Se delimita muy bien el ámbito del problema.
L interacción
La
i t
ió del
d l software
ft
con ell nuevo sistema
i t
no es
complicada o se utilizan nuevas tecnologías que son
dominadas por el equipo de desarrollo.
Modelo Incremental
„
Inconvenientes
„
„
Debe haber un compromiso por parte del equipo de
desarrollo y del cliente en el desarrollo rápido de
actividades.
Requiere recursos suficientes para crear el número de
equipos necesarios.
29
30
… 6.1 Diferentes paradigmas de ciclos de vida:
EVOLUTIVOS
… Modelo Incremental
„
„
„
„
Combina elementos del modelo lineal secuencial con
la filosofía interactiva de construcción de prototipos.
Se centra en la entrega de un producto operacional
con cada incremento
Fácil
á l adaptación
d
ó a requerimientos temporales
l de
d
entrega.
Este modelo es útil cuando la dotación de personal no
está disponible para una implementación completa.
„
Modelo en Espiral
„
„
Combina el modelo lineal
secuencial y el de
construcción de prototipos
El sw se desarrolla en una
serie de
d versiones
incrementales
31
32
… Modelo en Espiral [2]
Modelo de ensamblaje de componentes
„
„
„
„
„
„
„
Modelos anteriores, pero con uso de
bibliotecas de rutinas (tradicional) o
clases (orientación a objetos).
Más rápido.
Menores costos de desarrollo
desarrollo.
Programadores más experimentados.
Menor dependencia de las personas que
participaron en el proyecto.
Desarrollo para reutilizar y desarrollo con
reutilizacion.
Uso de COTS (Commercial Off-The-Shelf)
y de Outsourcing (subcontratación).
33
Métodos formales
6.1 El ciclo de vida para software empotrado
1.
2.
Especificación del
producto
División Hw y Sw
„
„
3.
Diseño hw
34
4.
5.
Iteración
e
implementación
Diseño detallado Hw y Sw
Integración
de
componentes Hw y Sw
„
Diseño sw
„
6.
7.
Prueba del producto
Mantenimiento y
actualización
„
35
Busca la especificación
matemática del Sw.
Buen manejo de la ambigüedad,
inconsistencia y lo incompleto.
Se utiliza en forma p
parcial en
diseño de sistemas de alta
seguridad (aviación, medicina,
control de procesos).
Se obtienen algoritmos bien
estructurados.
Lenguaje Z, C2
36
… 6.1 Diferentes paradigmas de ciclos de vida:
EVOLUTIVOS
„
RUP: Clasificación de Iteraciones
RUP (Rational Unified Process), 1999.
„
„
„
Iteración de concepción:
iteración preliminar con los
interesados
„ Cliente preliminar
„ Usuarios
„ Inversionistas financieros,
,
etc.
Iteración de elaboración:
finalización de qué se desea y
necesita; establecer la base de
la arquitectura
Iteración de construcción: dan
como resultado la capacidad
iterativa (producto básico)
Iteración de transición: terminar
la liberación del producto
„
Jacobson-Metodología Objectory
Booch-Metodología Booch
Rumbaugh-OMT (Técnica de Modelado de Objetos)
„
„
„
37
RUP: seis modelos o vistas de la aplicación
Matriz del Proceso Unificado
Jacobson et al: USDP
Concepción Elaboración
Iteraciones Iter.
Prelim
1
Construcción
.. Iter. Iter.
n
n+1
…..
Iter.
m
Transición
Iter.
m+1
…..
A áli i
Análisis
Diseño
Implementación
Prueba
„
„
La más destacada de los procesos ágiles.
Adaptabilidad contra previsibilidad.
Los cambios de requisitos sobre la
marcha son un aspecto natural
natural, inevitable
e incluso deseable del desarrollo de
proyectos.
39
Programación Extrema o eXtreme Programming (XP)
„
„
40
Programación Extrema o eXtreme Programming (XP)
Características fundamentales
„
38
Programación Extrema o eXtreme Programming (XP)
„
„
Iter.
k
Requerimientos
„
Desarrollo iterativo e incremental.
Pruebas unitarias continuas
„ pruebas de regresión
regresión.
„ Junit, Dunit.
Programación en parejas
Frecuente interacción del equipo de programación
con el cliente o usuario
„
„
„
41
Corrección de todos los errores antes de añadir
nueva funcionalidad. Hacer entregas frecuentes.
Refactorización del código
Propiedad del código compartida
Simplicidad en el código
42
Problemas y Riesgos con los Modelos
Programación Extrema o eXtreme Programming (XP)
„
„
La simplicidad y la comunicación son
extraordinariamente complementarias. Con más
comunicación resulta más fácil identificar qué se debe
y qué no se debe hacer.
Mientras más simple es el sistema
sistema, menos tendrá que
comunicar sobre este, lo que lleva a una
comunicación más completa, especialmente si se
puede reducir el equipo de programadores.
„
„
„
Cascada.
„ Alto riesgo en sistemas nuevos debido a problemas en
las especificaciones y en el diseño.
„ Bajo riesgo para desarrollos bien comprendidos utilizando
tecnología conocida.
Prototipado.
„ Bajo riesgo para nuevas aplicaciones debido a que las
especificaciones y el diseño se llevan a cabo paso a paso.
„ Alto riesgo debido a falta de visibilidad
Evolutivo
„ Alto riesgo debido a la necesidad de tecnología avanzada
y habilidades del grupo desarrollador.
43
Modelos de Procesos Híbridos
„
„
„
„
44
Visibilidad de Procesos
Los sistemas grandes están hechos usualmente de
varios subsistemas.
No es necesario utilizar el mismo modelo de proceso
para todos los subsistemas.
Ell prototipado
d es recomendado
d d cuando
d existen
especificaciones de alto riesgo.
El modelo de cascada es utilizado en desarrollos bien
comprendidos.
„
„
„
Los sistemas de software son intangibles por lo que los
administradores necesitan documentación para identificar
el progreso en el desarrollo.
Esto puede causar problemas
„ El tiempo planeado para entrega de resultados puede
no coincidir con el tiempo necesario para completar
una actividad
„ La necesidad de producir documentos restringe la
iteración entre procesos.
„ El tiempo para revisar y aprobar documentos es
significativo.
El modelo de cascada es aún el modelo con resultados
más utilizado.
45
Documentos del Modelo de Cascada
46
7. Herramientas CASE
„
CASE es un acrónimo para Computer-Aided Software
Engineering, aunque existen algunas variaciones para lo que
actualmente se entiende por CASE:
C
A
S
E
47
Computer
Aided
Assisted
Automated
Software
Systems
Engineering
48
1.2 Actividades que se pueden automatizar con
herramientas CASE
1.1 ¿Qué es una CASE?
„
En “Terminology for Software Engineering and Computer-aided
Software Engineering”, B.Terry & D.Logee, Software
Engineering Notes, Abril 1990, CASE es definido como:
“Herramientas individuales para ayudar al desarrollador de
proyecto
y
durante una o más fases
software o administrador de p
del desarrollo de software (o mantenimiento).”
„
El desarrollo de modelos gráficos del sistema como parte de la
especificación de requerimientos o del diseño del software;
La comprensión del diseño utilizando un diccionario de datos el
cual tiene información sobre las entidades y relaciones del diseño;
La generación de interfaces de usuario a partir de la descripción
gráfica de la interfaz
interfaz, la cual es elaborada de forma interactiva
por el usuario.
La depuración de programas por medio de la previsión de la
información, proporcionada por los programas en ejecución.
La conversión automática de programas de una versión anterior
de un lenguaje de programación, como COBOL, a una versión
mas reciente.
1.
2.
3.
En “The CASE Experience”, Carma McClure, BYTE Abril 1989
p.235:
4.
“Una combinación de herramientas de software y metodologías
de desarrollo”
5.
49
1.3 Impacto de la tecnología CASE
„
„
2. Clasificación CASE
La tecnología CASE ha provocado mejoras
significativas en la calidad y productividad
Sin embargo, la adaptación de esas mejoras fue
menor a la predicha inicialmente por los
g
desarrolladores de tecnología
„
„
„
Los sistemas CASE pueden clasificarse desde 3
perspectivas:
„
„
„
Varios problemas desarrollados en software no son
disponibles de automatizar:
„
„
50
Funcional
De proceso
De Integración
ó
El diseño y la comunicación.
Los sistemas CASE no son integrados
Los adaptadores de tecnología CASE subestiman el
entrenamiento y el costo de los procesos de adaptación
51
Clases de herramientas funcionales
TIPOS DE HERRAMIENTAS
De planeación
De edición
De construcción de prototipos
De Procesamiento de lenguajes
De prueba
De depuración
De reingeniería
52
8. Conclusiones
EJEMPLOS
Herramientas PERT, herramientas de
estimación, hojas de cálculo
Editores de texto, editores de diagramas,
procesadores de palabra
Entornos de desarrollo,
desarrollo generadores de
interface de usuario
Compiladores, intérpretes
„
„
„
Generadores de pruebas de datos,
Comparadores de archivos
Sistemas de depuración interactiva
Sistemas de referencias cruzadas, sistemas de
reestructuración de programas,
53
La Ingeniería de software concierne a las teorías,
métodos y herramientas para el desarrollo,
administración y evolución de productos de software
Los productos de software consisten de programas y
productos son:
documentación. Los atributos de los p
mantenibilidad, confiabilidad, eficiencia y utilización
adecuada (usabilidad).
El proceso de software consiste en aquellas
actividades involucradas en el desarrollo de software.
54
… 8. Conclusiones
„
„
„
„
„
„
9. Referencias
Una vez conocido el proceso a automatizar en sw, se debe
elegir el modelo más apropiado de desarrollo de sw.
El modelo de cascada considera cada actividad del proceso
como una actividad discreta.
El modelo de desarrollo evolutivo considera actividades del
proceso en forma concurrente.
El modelo de espiral se basa en análisis de riesgos.
La visibilidad del proceso involucra la creación de documentos
o resultados de las actividades.
Los Ingenieros de software deben tener responsabilidades
éticas, sociales y profesionales.
55
¿Preguntas?
„ Gracias!
„
57
1.
2.
3.
4.
Pressman, S Roger (1998) “Ingeniería del
Software: Un enfoque práctico”, 4a edición
McGraw-Hill.
Somerville, Ian (2002) “Ingeniería de software”.
6a edición. Addison Wesley.
Braude Eric J. (2003) “Ingeniería de Software
Una perspectiva orientada a objetos”, Alfaomega
Berger, A. (2002) Embedded Systems Design.
An Introduction to Process, Tools and
Techniques CMP Books.
56