Post on 04-Jun-2018
1
1
INGENIERIA DE SOFTWARE Tema 1: Introducción a la Ingeniería de Software
Presenta: David Martínez Torres Universidad Tecnológica de la Mixteca Instituto de Computación Oficina 37 dtorres@mixteco.utm.mx
2
Contenido
1. Importancia del Software
2. Evolución y características del software
3. Tipos de software
4. La crisis del software
5. Definición de Ingeniería de Software
6. Paradigmas de ciclos de vida de la Ingeniería de software
7. Herramientas CASE
8. Referencias
2
3
1. Importancia de Software
Las economías dependen en gran parte
del software.
El software se ha convertido en ubicuo en nuestras vidas.
Software como producto entrega la potencia informática del hardware
Software como vehículo actúa como la base de control de la PC.
4
2. Evolución y características del software
Los primeros años („50 - „60)
Orientación Batch (por lotes)
Distribución limitada
Software a medida
La Segunda era („70)
Ambiente multiusuario y tecnología de multiprogramación
Tiempo Real / Bases de datos / productos de software (Casas de software)
3
5
… 2. Evolución y características del software
La Tercera era („80)
Sistemas distribuidos
Incorporación de “inteligencia” a productos (Firmware)
Redes y HW de bajo costo
Microprocesadores
Consumo masivo
La Cuarta era („90 a la fecha)
PC‟s potentes
Tecnología O-O
Sistemas expertos
Redes neuronales
Computación paralela
Redes de información
6
…2. Evolución y características del Software
Características del sw como producto
Mantenibles
Confiabilidad
Eficiencia
Utilización adecuada
4
7
… 2. Evolución y características
Características del Sw vs. Hw
Producto lógico, no físico
Se desarrolla, no se fabrica
No se estropea (ver siguientes diapositivas)
Construcción a medida.
Mantenimiento complicado
8
… 2. Evolución y características
Curvas de fallas del Hardware
“Mortalidad Infantil”
“se estropea: desgaste de
materiales”
Tiempo
Ta
sa
de
falla
s
5
9
… 2. Evolución y características
Curvas de fallas del Software
“Puesta en marcha”
“Fallas por obsolescencia”
Tiempo
Ta
sa
de
falla
s
Se mantiene nivel hasta la obsolescencia
10
… 2. Evolución y características
Curvas de fallas de Sw “mas real”
Cambio
Incremento de la tasa de fallas
por efectos laterales
Tiempo
Ta
sa
de
falla
s
Curva idealizada
Curva Real
6
11
3. Tipos de Sw
Software de sistemas
Software de Tiempo Real
Software de Gestión
Software de Ingeniería y Científico
12
… 3. Tipos de Sw
Software empotrado (Firmware)
Software de PC
Software de Inteligencia Artificial
7
13
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
14
… 4. Crisis del Sw
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).
8
15
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 o área de la informática 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.
16
… 5. Definición de Ingeniería de Sw
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
9
… 5. Definición de Ingeniería de Sw
Definición combinada de las anteriores:
Disciplina de la ingeniería que establece y usa
principios robustos para el desarrollo y mantenimiento
de software de calidad, que sea fiable, eficiente, con
uso adecuado, mediante el uso de procesos, métodos y
herramientas.
18
5.1 Porque aplicar Ingeniería de Sw?
10
Las cuatro “P” de la Ingeniería de Software
Personas
(quién lo hace)
Reeditado de Ingeniería de Software: Una perspectiva Orientada a Objetos por Eric J. Braude (Wiley 2003)
Proceso (la manera
en que se hace)
Elaboration
Unified Process Matrix
Inception Construction Transition
Requirements
Analysis
Jacobson et al: USDP
Prelim.
iterations
Iter.
#1
Iter.
#n
Iter.
#n+1
Iter.
#m
Iter.
#m+1
Iter.
#k….. …..
Design
Implemen-tation
Test
..
Proyecto
(la realización)
Producto
(la aplicación de artefactos)
Personas
Interacción entre personas involucradas – éxito en proyecto de software
Los equipos trabajan mejor cuando tienen conocimiento de 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” - stakeholders
Personas
(quién lo hace)
11
Proceso
Desarrollo de secuencias:
Cascada
Iterativo
Marco de trabajo de los procesos:
Personal Software Process
Team Software Process
Capability Maturity Model
(para organizaciones)
Estándares:
Institute of Electrical and Electronic Engineers (IEEE)
International Standards Organization (ISO)
Conjunto de actividades realizadas para producir una aplicación
Elaboration
Unified Process Matrix
Inception Construction Transition
Requirements
Analysis
Jacobson et al: USDP
Prelim.
iterations
Iter.
#1
Iter.
#n
Iter.
#n+1
Iter.
#m
Iter.
#m+1
Iter.
#k….. …..
Design
Implemen-tation
Test
..
Proyecto
Métodos:
Estructurados
Orientación a Objetos
Lenguaje de modelado unificado: notación de diseño
Sistemas heredados
Mejoras o uso del sistema existente
Conjunto de actividades para producir los artefactos requeridos
personas Flujo del trabajo
12
Producto
Requerimientos
Arquitectura de software
Diseño detallado
Implementación
Artefactos de prueba
La aplicación y los artefactos asociados e incluidos
Códigos fuente Y objeto
Diseño del modelo
Especificación de requerimientos de software
Artefactos
Procedimientos de prueba; casos de pruebas
24
6. Paradigmas o Modelos del proceso de desarrollo de software
Modelo Secuencial (ciclo de vida básico o modelo en cascada) Análisis Diseño Código Pruebas
Ingeniería de Sistemas
Mantención
Análisis
Diseño
Código
Pruebas
Mantención
13
25
… Modelo Secuencial
Actividades:
1. Ingeniería y modelado de Sistemas/Información
Ubicación del software en el ámbito donde va a funcionar.
2. Análisis de los requisitos del software
La función requerida, comportamiento, rendimiento, etc
El cliente debe dar el visto bueno
3. Diseño
Arquitectura del software
Estructura del programa
Representaciones de la Interfaz
Detalle Procedimental (algoritmo)
26
… Modelo Secuencial
Actividades: (Continuación)
4. Generación de código o Implementación
Puede automatizarse si el diseño está bien detallado.
5. Pruebas
De Caja Blanca
De Caja Negra
6. Mantenimiento
Gestión de cambios en el software debidos a:
Errores durante el desarrollo.
14
27
… 6. Modelos de proceso de software
Modelo Prototipo
28
… … 6. Modelos de proceso de software
Modelo DRA(Desarrollo Rápido de Aplicaciones)
Adaptación a “alta velocidad” del MLS utilizando un enfoque de construcción basado en componentes.
Desarrollo de un sistema completamente funcional en periodos cortos (de 60 a 90 días).
Los componentes que se desarrollen se pueden reutilizar en posteriores proyectos.
Desarrollo independiente por distintos equipos en caso necesario.
15
29
… Modelo DRA
Se aplica cuando se cumplen condiciones como:
Se comprenden muy bien los requisitos por el propio desarrollador o porque se tiene experiencia en el tipo de sistema.
Se delimita muy bien el ámbito del problema.
La interacción del software con el nuevo sistema no es complicada o se utilizan nuevas tecnologías que son dominadas por el equipo de desarrollo.
… Modelo DRA
Inconvenientes
Debe haber un compromiso por parte del equipo y del
cliente.
Requiere recursos suficientes para crear el número de
equipos necesarios.
16
31
… 6. Diferentes Modelos de proceso de software: EVOLUTIVOS
El software, al igual que el resto de sistemas evoluciona
con el tiempo. Necesidad de procedimientos que
permitan una evolución del software.
Modelo Incremental
32
… Modelo Incremental
Combina MLS con prototipos.
Entrega de un producto operacional en cada
incremento
Fácil adaptación a requerimientos temporales de
entrega.
Modelo útil cuando el personal no está disponible
para una implementación completa.
17
33
… 6.1 Diferentes paradigmas de ciclos de vida: EVOLUTIVOS
Modelo en Espiral
Combina MLS y
prototipos
Entrega de una serie de
versiones incrementales
Inclusión de análisis de
riesgos técnicos y de
gestión
34
… Modelo en Espiral [2]
18
35
Modelo de ensamblaje de componentes
Uso de bibliotecas de rutinas o clases
Desarrollo en menor tiempo
Menores costos de desarrollo
Programadores más experimentados.
Menor dependencia de las personas que participaron en el proyecto.
Desarrollo para reutilizar y desarrollo con reutilización.
Uso de COTS (Commercial Off-The-
Shelf) y de Outsourcing
(subcontratación).
36
6.1 El ciclo de vida para software empotrado
1. Especificación del producto
2. División Hw y Sw
Diseño hw
Diseño sw
6. Prueba del producto
7. Mantenimiento y actualización
3. Iteración e implementación
4. Diseño detallado Hw y Sw
5. Integración de componentes Hw y Sw
19
37
Métodos formales
Se basan en lógica y matemáticas, para describir sistemas de hardware o software[1]
Especificación del software, verificación y diseño de componentes mediante notaciones matemáticas.
Buen manejo de la ambigüedad, inconsistencia y lo incompleto.
Diseño de sistemas de alta seguridad (aviación, medicina, control de procesos).
Lenguaje Z, C2
Especificación formal del software
Ejemplo de especificación en lógica formal de las funciones de insertar y borrar elementos de una pila [2]
L.push(e:stelement): Inserta e después del último elemento insertado
PRE: ∃L ∧ L ≠ {NULL} ∧ L = {PRF} ∧ tamaño(L) = n ∧
¬existe(L,clave(e))
POST: L = {PRF,e} ∧ tamaño(L) = n + 1
PRE: ∃L ∧ L = {NULL}
POST: L = {e} ∧ n = 1
20
Especificación formal del software
L.pop(): borra el elemento recientemente insertado
PRE: ∃L ∧ L = {PRF, e} ∧ tamaño(L) = n
POST: L = {PRF} ∧ tamaño(L) = n – 1
40
… 6.1 Diferentes paradigmas de ciclos de vida: EVOLUTIVOS
RUP (Rational Unified Process), 1999.
Jacobson-Metodología Objectory
Booch-Metodología Booch
Rumbaugh-OMT (Técnica de Modelado de Objetos)
21
41
RUP: Clasificación de Iteraciones
Iteración de concepción (prototipo):
Cliente preliminar
Usuarios
Inversionistas financieros, etc.
Iteración de elaboración: finalización de qué se desea y necesita; confirma la arquitectura
Iteración de construcción: se establece el producto básico
Iteración de transición: preparar la aplicación para que la libere el cliente
Elaboración
Matriz del Proceso Unificado
Concepción Construcción Transición
Requerimientos
Análisis
Jacobson et al: USDP
Iteraciones
PrelimIter.
1
Iter.
n
Iter.
n+1
Iter.
m
Iter.
m+1
Iter.
k….. …..
Diseño
Implemen-tación
Prueba
..
42
RUP: seis modelos o vistas de la aplicación
22
Métodos ágiles
Métodos basados en el desarrollo iterativo e incremental, estas metodologías son imprescindibles en un mundo en el que nos exponemos a cambios recurrentes
La última tendencia hoy puede que no exista mañana y por esto existe la metodología ágil donde los requisitos y soluciones evolucionan mediante la colaboración de grupos auto organizados y multidisciplinarios
Scrum
23
Scrum [5]
No es un proceso o una técnica para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos
Es ligero, fácil de entender y extremadamente difícil de llegar a dominar
Consiste de equipos Scrum, roles, eventos, artefactos y reglas asociadas
Scrum [5]
Utiliza cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación.
Reunión de Planificación del Sprint (Sprint Planning Meeting)
Scrum Diario (Daily Scrum)
Revisión del Sprint (Sprint Review)
Retrospectiva del Sprint (Sprint Retrospective)
24
El equipo Scrum (Scrum Team)
Se compone de:
Dueño de Producto (Product Owner),
El Equipo de Desarrollo (Development Team) y un
Scrum Master.
Son autoorganizados y multifuncionales.
Eligen la mejor forma de llevar a cabo su trabajo y no son dirigidos por personas externas al equipo.
Entregan productos de forma iterativa e incremental
Las entregas incrementales de producto “Terminado” aseguran que siempre estará disponible una versión potencialmente útil y funcional del producto.
El Dueño de Producto (Product Owner)
La única persona responsable de gestionar la Lista del Producto (Product Backlog).
Ordena los requerimientos
Asegura que esté visible la lista del producto
El único que puede cancelar un sprint, aunque a influencia del equipo scrum y de los interesados.
25
El Equipo de Desarrollo (Development Team)
Equipo de profesionales que el incremento del producto «terminado» durante el sprint
Son autoorganizados y multifuncionales
La responsabilidad recae en todo el equipo
El tamaño va de 3 a 9 personas
Los roles del dueño del producto y scrum master no cuenta en el tamaño, excepto que realicen desarrollo
El Scrum Master
Es responsable de asegurar que Scrum es entendido y adoptado.
Es un líder que está al servicio del Equipo Scrum
Encontrar técnicas para gestionar la Lista de Producto de manera efectiva
Asegurar que el Dueño de Producto conozca cómo ordenar la Lista de Producto para maximizar el valor;
Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional;
26
El Scrum Master
Ayuda al Equipo de Desarrollo a crear productos de alto valor;
Eliminar impedimentos para el progreso del Equipo de Desarrollo;
Liderar y guiar a la organización en la adopción de Scrum;
Trabajar con otros Scrum Masters para incrementar la efectividad de la aplicación de Scrum en la organización.
El Sprint
El corazón de Scrum es el Sprint, es un bloque de tiempo (time-box) de un mes o menos durante el cual se crea un incremento de producto “Terminado”, utilizable y potencialmente desplegable.
Contiene eventos formales (reuniones) para alcanzar el producto.
27
El Sprint
Durante el Sprint no se realizan cambios que puedan afectar al Objetivo del Sprint (Sprint Goal);
Los objetivos de calidad no disminuyen; y,
El alcance puede ser clarificado y renegociado entre el Dueño de Producto y el Equipo de Desarrollo a medida que se va aprendiendo más.
Los Sprints también limitan el riesgo al costo de un mes calendario.
El Sprint
Puede ser cancelado antes de que el bloque de tiempo llegue a su fin por el dueño del producto.
Se cancelaría si el Objetivo del Sprint llega a quedar obsoleto (la compañía cambia la dirección, o si las condiciones del mercado, o de la tecnología cambian)
28
Reunión de Planificación de Sprint (Sprint Planning Meeting)
Se determina la lista de pendientes del sprint (sprint backlog) a partir de la selección de la lista de producto (product backlog), mas el plan para terminarlos
El equipo de desarrollo comienza diseñando el incremento. Realiza una proyección de lo que pueda alcanzar
Reunión de Planificación de Sprint (Sprint Planning Meeting)
Al final de la Reunión, el Equipo de Desarrollo debería ser capaz de explicar al Dueño de Producto y al Scrum Master cómo pretende trabajar como un equipo autoorganizado para lograr el Objetivo del Sprint y crear el Incremento esperado.
Tiene una duración máxima de 8 hrs para sprint de 1 mes
29
Scrum Diario (Daily Scrum)
Es una reunión con un bloque de tiempo de 15 minutos para que el Equipo de Desarrollo sincronice sus actividades y cree un plan para las siguientes 24 horas.
Se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.
Scrum Diario (Daily Scrum)
Durante la reunión, cada miembro del Equipo de Desarrollo explica:
¿Qué hice ayer, que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?
30
Revisión de Sprint (Sprint Review)
Se realiza al final del Sprint.
Se inspecciona el Incremento y adapta la Lista de Producto si fuese necesario.
Tiene una duración máxima de cuatro horas para Sprints de un mes.
El Dueño de Producto explica qué elementos de la Lista de Producto se han “Terminado” y cuales no;
Revisión de Sprint (Sprint Review)
El Equipo de Desarrollo habla acerca de qué fue bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas;
La Revisión proporciona información para la siguiente Planificación del Sprint
31
Retrospectiva de Sprint (Sprint Retrospective)
Es una oportunidad para el Equipo Scrum de inspeccionarse a sí mismo y crear un plan de mejoras que sean abordadas durante el siguiente Sprint.
Se realiza después de la Revisión de Sprint y antes de la siguiente Reunión de Planificación de Sprint.
La duración es de tres horas para Sprints de un mes.
Artefactos de Scrum
Los artefactos están diseñados específicamente para maximizar la transparencia de la información clave, que es necesaria para asegurar que todos tengan el mismo entendimiento del artefacto.
Lista de Producto (Product Backlog)
Lista de Pendientes del Sprint (Sprint Backlog)
32
63
Modelos de Procesos Híbridos
Los sistemas grandes están hechos usualmente de varios subsistemas.
No es necesario utilizar el mismo modelo de proceso para todos los subsistemas.
El prototipado es recomendado cuando existen especificaciones de alto riesgo.
El modelo de cascada es utilizado en desarrollos bien comprendidos.
64
Documentos del Modelo de Cascada
33
Metodologías tradicionales vs Ágiles
66
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 Computer
A Aided
Assisted
Automated
S Software
Systems
E Engineering
34
67
¿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 software o administrador de proyecto durante una o más fases del desarrollo de software (o mantenimiento).”
En “The CASE Experience”, Carma McClure, BYTE Abril 1989 p.235:
“Una combinación de herramientas de software y metodologías de desarrollo”
68
Actividades que se pueden automatizar con herramientas CASE
1. Desarrollo de modelos gráficos del sistema en la especificación de requerimientos o diseño del software;
2. Desarrollo del diccionario de datos el cual tiene información sobre las entidades y relaciones del diseño;
3. Generación de interfaces de usuario, la cual es elaborada de forma interactiva por el usuario.
4. Depuración de programas por medio de la previsión de la información, proporcionada por los programas en ejecución.
5. 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.
35
69
Impacto de la tecnología 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 desarrolladores de tecnología
Varios problemas desarrollados en software no son disponibles de automatizar:
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
70
Clases de herramientas funcionales
TIPOS DE HERRAMIENTAS EJEMPLOS
De planeación Herramientas PERT, herramientas de
estimación, hojas de cálculo
De edición Editores de texto, editores de diagramas,
procesadores de palabra
De construcción de prototipos Entornos de desarrollo, generadores de
interface de usuario
De Procesamiento de lenguajes Compiladores, intérpretes
De prueba Generadores de pruebas de datos,
Comparadores de archivos
De depuración Sistemas de depuración interactiva
De reingeniería Sistemas de referencias cruzadas, sistemas de
reestructuración de programas,
36
71
8. Conclusiones
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 documentación. Los atributos de los productos son: mantenibilidad, confiabilidad, eficiencia y utilización adecuada (usabilidad).
El proceso de software consiste en aquellas actividades involucradas en el desarrollo de software.
72
… 8. Conclusiones
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.
Los Ingenieros de software deben tener responsabilidades éticas, sociales y profesionales.
37
73
9. Referencias
1. Pressman, S Roger (1998) “Ingeniería del Software: Un enfoque práctico”, 4a edición McGraw-Hill.
2. Somerville, Ian (2002) “Ingeniería de software”. 6a edición. Addison Wesley.
3. Braude Eric J. (2003) “Ingeniería de Software Una perspectiva orientada a objetos”, Alfaomega
4. Berger, A. (2002) Embedded Systems Design. An Introduction to Process, Tools and Techniques CMP Books.
5. Ken Schwaber y Jeff Sutherland. la Guia de SCRUM. ©2014 Scrum.Org and ScrumInc.
6. Weitzenfeld Alfredo (2004). Ingeniería de Software Orientada a Objetos con UML, Java e Internet. Cengage (Thomson) Learning (ISBN 970-686-190-4)
74
¿Preguntas?
Gracias!