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!