Objetivos del curso Ingeniería del Software I - infor.uva.esmlaguna/is1/apuntes/1-intro.pdf · 1 Ingeniería del Software I 3º I.T.I.Gestión Miguel A. Laguna Objetivos del curso

1

Ingeniería del Software I

3º I.T.I.Gestión

Miguel A. Laguna

Objetivos del cursoComprender los elementos característicos de la ingeniería del software

Conocer de forma detallada los métodos y herramientas de especificación de requisitos

2

herramientas de especificación de requisitos

Ser capaz de elaborar la especificación completa de un sistema utilizando las herramientas, métodos y procedimientos mostrados en el curso

Ingeniería del Software IIntroducción a la Ingeniería del Software

Producto y ProcesoAspectos de Gestión

3

Elicitación, análisis y especificación de Requisitos

Modelado de actividades y casos de usoModelado estático (diagramas de clases)Modelado dinámico (diagramas de secuencia)

1. Introducción

Ingeniería del Software I3º I.T.I.Gestión

Miguel A. Laguna

Objetivos

Presentar la disciplina de ingeniería del software y explicar su importanciaPreguntas más frecuentes (FAQs) sobre

5

Preguntas más frecuentes (FAQs) sobre la ingeniería del software, proceso software, UML y aspectos éticos de la profesión

Desarrollo del tema

1.1. El software y la Ingeniería del software 1.2. Sistema de Información

6

1.3. Método y Proceso1.4.Disciplinas de gestión de proyectos1.5. Aspectos profesionales y éticos de la Ingeniería del Software1.6. Lenguaje Unificado de Modelado (UML)

2

FAQs: Preguntas frecuentes sobre Ingeniería del Software¿Qué es el Software? ¿Cuál es la importancia y coste del Software?¿Qué es la Ingeniería del Software?¿Cuál es la diferencia entre Ingeniería del Software e Ingeniería de Sistemas?

7

Ingeniería de Sistemas? ¿Qué es un sistema y un sistema de información?¿Qué es un proceso software y un método de desarrollo? ¿Cómo se gestiona el proceso?¿Qué es CASE (Computer-Aided Software Engineering)?¿Cuáles son las responsabilidades de un Ingeniero Software? ¿Qué es el Lenguaje Unificado de Modelado (UML)?

1.1. El software y la Ingeniería del software

Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación y mejora.

Para construir un nuevo elemento software se necesita:

¿Qué es el Software?

9

Detallar las especificacionesDiseñar la soluciónCodificar el algoritmoProbar el programaDocumentarMantener

Es lo que se conoce como el ciclo de vida del software.

Las economías de todos las paises son cada vez más y más dependientes del software

Importancia del Software

10

Cada vez más y más sistemas están controlados por softwareEl gasto en desarrollo de software está aumentando su porcentaje en el PIB de todos las paises

Crisis del Software

Crecimiento espectacular de los costes del software.Incumplimiento de los plazos de

11

Incumplimiento de los plazos de entrega.Muchas dudas sobre la calidad del software construido.

Los costes que representa el Software son a menudo mayores que el hardware

El mantenimiento resulta más caro que el

Costes del Software

12

a e e o esu a ás a o que edesarrollo:

En sistemas de vida larga puede ser varias veces más caro

La Ingeniería del Software tiene que ver con el desarrollo de forma que sea económicamente viable

3

Costes de los cambios

60-100x

13

Definición Desarrollo

1x

1.5-6x

Después de entregado

El software se deteriora

Tasa de fallos

Incremento de fallos

14

curva ideal

Tiempo

cambio

curva real

Disciplina que se ocupa del desarrollo del software.

Se enfrenta al software como un producto de

¿Qué es la Ingeniería del software?

15

Se enfrenta al software como un producto de ingeniería que requiere: planificación, análisis, diseño, implementación, pruebas y mantenimiento.

Trata de las teorías, métodos y herramientas que los profesionales del desarrollo del software deben utilizar.

No sólo comprende los procesos técnicos del desarrollo.También, los principios más relevantes

Ingeniería del software

16

También, los principios más relevantes de dirección y control de este proceso.También, el desarrollo de nuevas teorías, métodos y herramientas de apoyo a la producción del software.

Objetivos de la Ingeniería del software

Mejorar la calidad del softwareAcortar los tiempos de desarrolloAumentar la productividad

17

Aumentar la productividadNecesidad:

Incrementar la reutilización del software

Ingeniería del software

Los ingenieros de software deben adoptar un enfoque sistemático y organizado en su trabajo y

18

organizado en su trabajo y utilizar las herramientas y técnicas más apropiadas dependiendo

del problema a resolver, las restricciones del desarrollo y los recursos disponibles.

4

¿Cuál es la diferencia entre Ingeniería del Software y las Ciencias de la Computación?

Las Ciencias de la Computación tienen que ver con teorías y fundamentos

19

La Ingeniería del Software tiene que ver con los aspectos prácticos del desarrollo del software

¿Cuál es la diferencia entre Ingeniería del Software e Ingeniería de Sistemas?

La Ingeniería de Sistemas tiene que ver con todos los aspectos del desarrollo de sistemas basados en computadoras:

20

hardware, software e Ingeniería de procesos.

Ingeniería del Software es una parte de este proceso

Disciplinas integradas en la Ingeniería del SoftwareSoftware Engineering Body of Knowledge (SWEBOK)

Requisitos del softwareDiseño del softwareConstrucción del softwareP b d l S ft

21

Prueba del SoftwareMantenimiento del software

Gestión de la configuración del softwareGestión de la Ingeniería del SoftwareProceso de Ingeniería del SoftwareHerramientas y métodos de la Ingeniería del SoftwareCalidad del software

SWEBOK GuíaSWEBOK (I)

GuíaSWEBOK (I)

Requisitos delsoftware

Requisitos delsoftware

Proceso deIngeniería de Requisitos

Diseñodel software

Diseñodel software

Conceptos y principios básicos

Diseñodel software

Diseñodel software

Conceptos y principios básicos

Construccióndel software


Reducción de lacomplejidad



Reducción de lacomplejidad

Prueba delsoftware

Prueba delsoftware

Conceptos básicosy definiciones

Mantenimientodel software

Mantenimientodel software

Conceptos básicos

22(a)(a) (b)(b) (c)(c) (d)(d) (e)(e)

Obtención derequisitos

Análisis derequisitos

Especificaciónde requisitos

Validación derequisitos

Gestión derequisitos

Elementos clave en eldiseño del software

Estructura y arquitectura del software

Análisis y evaluación dela calidad del diseño

Notaciones de diseño

Estrategias y métodosde diseño

Elementos clave en eldiseño del software

Estructura y arquitectura del software

Análisis y evaluación dela calidad del diseño

Notaciones de diseño

Estrategias y métodosde diseño

Anticipación de ladiversidad

Estructuración para la validación

Uso de estándaresexternos

Anticipación de ladiversidad

Estructuración para la validación

Uso de estándaresexternos

Niveles depruebas

Técnicas de prueba

Métricasrelacionadas conlas pruebas

Gestión del procesode prueba

Proceso de mantenimiento

Principales problemasdel mantenimiento

Técnicas parael mantenimiento

SWEBOKGuía

SWEBOK (II)Guía

SWEBOK (II)

Gestión de laconfiguraciónGestión de laconfiguración

Gestión del proceso de gestión de la configuración

Id tifi ió d l

Gestiónde la ISGestiónde la IS

Gestión dela organización

G tió d l

Proceso deIS

Proceso deIS

Conceptos delproceso de IS

Herramientas ymétodos de la ISHerramientas y

métodos de la IS

Herramientassoftware

é

Calidad delsoftware

Calidad delsoftware

Conceptos sobrecalidad del software

ó f ó

GuíaSWEBOK (II)

GuíaSWEBOK (II)



Id tifi ió d l



Id tifi ió d l



G tió d l



G tió d l

Proceso deIS

Proceso deIS


Proceso deIS

Proceso deIS



métodos de la IS


é


métodos


é

Calidad delsoftware

Calidad delsoftware


ó f ó

Calidad delsoftware

Calidad delsoftware


ó f ó

23(a)(a) (b)(b) (c)(c) (d)(d) (e)(e)

Identificación de la configuración del software

Control de la configuracióndel software

Registro del estado de laconfiguración del software

Auditoríade la gestiónde la configuración

Gestión de la distribucióndel software

Gestión delproceso/proyecto

Medida de laIS

Infraestructura delproceso

Medida delproceso

Definición delproceso

Análisis cualitativo del proceso

Implementación ycambio del proceso

Métodos software

Propósito y planificacióndel SQA y de la V&V

Actividades y técnicas paraSQA y V&V

Métricas aplicadas al SQAy a la V&V

(a)(a) (b)(b) (c)(c) (d)(d) (e)(e)












Medida de laIS


Medida de laIS


Medida delproceso





Medida delproceso




Métodos softwareMétodos software







1.2. Sistemas de Información

5

¿Qué es un sistema?

Un conjunto de elementos (hombres, máquinas, métodos, reglas) en interacción, que transforman (mediante un proceso) unos elementos (entradas) en otros

25

unos elementos (entradas) en otros (salidas).

Los sistemas no son entidades independientes, existen en un entorno:

El entorno afecta al funcionamiento y rendimiento del sistema. El sistema puede estar diseñado para hacer cambios en el entorno.

Sistema y subsistemasSubsistemas:

Sistema físico: Transforma un flujo físico de entradas en un flujo físico de salidas.

26

nivel operativo de la organización.

Sistema de gestión: controla el sistema físico, decidiendo el comportamiento del mismo en función de los objetivos marcados.

Sistema y subsistemas

SISTEMA DE GESTIÓN

OBJETIVOS

Información de objetivos

Fijación de nuevos objetivos

27

GESTIÓN

SISTEMA FÍSICO

Decisión de comportamientoInformación de funcionamiento

Entrada Salida

¿Qué es un sistema de información?

Sistema de Información: Está encargado dealmacenar y tratar informaciones sobre el sistema físico para ponerlas a disposición del sistema de gestión

28

recibir decisiones sobre su propio controlinteraccionar con el sistema físico


SIST. DEGESTION

Decisión para

Objetivos

29

SIST. DE INFORMACION

SIST. FISICOEntrada Salida

InformaciónInteracción con el sistema físico

Decisión para su propio control

Inf. del sist. físico

Decisión de comportamiento


Una empresa típica cuenta con un SI compuesto por los siguientes subsistemas:

Subsistema de Recursos Humanos: Se ocupa tanto de la tió d l l d l ó i

30

gestión del personal como de la nómina.

Subsistema de Gestión Contable: Tanto para el control interno de la empresa como para hacer frente a las obligaciones legales.

Subsistema de Gestión Comercial: Para el control de los clientes y de las ventas.

Subsistema de Control de las Existencias: Del almacén y del inventario de bienes.

6

¿Qué es un sistema de información automatizado?

Si todas las transformaciones significativasson efectuadas por máquinas

31

Las tareas fundamentales de un SIA son:Memorización del modelo y de la base de información.Tratamiento automático (control, actualización, búsquedas, cálculos).Captura de la informaciónSalida de la información.

Propiedades emergentes

La compleja relación entre los subsistemas de un sistema significa que éste es más complejo que la suma de sus partes.L i d d

32

Las propiedades emergentes son consecuencia de las relaciones entre los componentes. Sólo pueden asegurarse y observarse cuándo el sistema se considera como un todo.

Ejemplos de prop. emergentesEl peso total del sistema

Se puede calcular a partir de las propiedades delos componentes individuales.

La fiabilidad del sistema

33

La fiabilidad del sistemaDepende de la fiabilidad de los componentes y suinterrelación.

La usabilidadEsta propiedad compleja no depende sólo delhardware y del software sino que tambiéndepende de los operadores y del entorno en quese utilice.

1.3. Método y Proceso

¿Qué es un método?Resulta necesario establecer un enfoque sistemático y disciplinado para llevar a cabo un desarrollo software

Definiciones:

35

Definiciones:Una metodología de ingeniería del software es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas

(James Rumbaugh et al.)

Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software

(Mario Piattini et al.)

Componentes de un método

PROCESO

TECNICAS

HERRAMIENTASUML

TogetherRose

36

PROCESO

Proceso: Define el marco de trabajo y permite un desarrollo racional de la IS

Técnicas: Indican cómo construir técnicamente el software. Incluyen técnicas de modelado

Herramientas: Proporcionan el soporte automático o semiautomático para el proceso y para las técnicas

UP

7

¿Qué es un proceso software?Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software:

37

Especificación de requisitos: Definir la funcio-nalidad y las restricciones en sus operacionesDiseño e implementación: Producir software que cumple la especificaciónValidación: Asegurar que hace lo que el cliente desea.Mantenimiento (o Evolución): Seguir cumpliendo los cambios en las necesidades del usuario.

Actividades complementarias de gestión

Organizar, planificar y programar los proyectos de software:

Estimación del coste del proyecto

38

p yPlanificación y calendarización del proyectoGestión de la configuración del softwareCalidad del software....

Especificación de requisitos del softwareEtapa en que se establece qué servicios se requieren del sistema y cuáles son las restricciones de operación y desarrollo del mismo.Se obtiene un documento de requisitos, con la

ifi ió d l i t

39

especificación del sistema.

Fases de la Ingeniería de Requisitos:Estudio de viabilidadElicitación y análisis de requisitosEspecificación de requisitos: los del usuario y los del sistemaValidación de requisitos

Especificación del softwareFeasibility

study

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

40

validationreport

Systemmodels

User and systemrequirements

Requirementsdocument

Diseño e implementación

Etapa en la que se convierte la especificación del sistema en un sistema ejecutableDiseño del software

Describir la estructura del software los datos las

41

Describir la estructura del software, los datos, las interfaces entre componentes, …

ImplementaciónTransformar la estructura anterior en un programa ejecutable

Las actividades de estas etapas están muy relacionadas y pueden interpolarse.

Diseño e implementación

Architectural Abstract Interface Component Data Algorithm

Requirementsspecification

Design activities

42

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Design products

8

Técnicas de diseño

Formas sistemáticas de diseñar el sistema Generalmente se documenta con

43

Generalmente se documenta con modelos gráficos:

Diagramas de flujo de datos (DFDs)Diagramas Entidad-RelaciónDiagramas de estructuraModelos orientados a objetos

Validación del Software

La verificación y la validación pretenden demostrar que un sistema es conforme con su especificación y que resuelve los

44

requisitos del clienteLa prueba del sistema implica ejecutar el sistema con los casos de prueba que se obtuvieron en la especificación.

Etapas en el proceso de pruebas

Prueba de unidadesSe comprueban los componentes individuales

Prueba de módulosSe prueban colecciones de componentes dependientes

45

Se prueban colecciones de componentes dependientesPrueba de subsistemas

Los módulos se integran en subsistemas y se prueban. Sobre todo se prueba el acoplamiento de las interfaces.

Prueba del sistemaSe prueban las interacciones entre los subsistemas y las propiedades emergentes.

Prueba de aceptaciónSe prueba con datos reales para comprobar que el sistema es aceptable por el cliente.

Etapas en el proceso de pruebas

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andSub-systemSystem

46

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

Service Acceptancetest

Systemintegration test

Sub-systemintegration test

Mantenimiento del softwareEl software es intrínsecamente flexible y puede cambiar.

De la misma forma que los requisitos cambian según cambian las circunstancias del negocio el software

47

cambian las circunstancias del negocio, el software que da soporte al negocio debe también desarrollarse y cambiar.

Aunque históricamente ha existido una separación entre el desarrollo y la mantenimiento (o evolución) esto es cada vez más irrelevante, puesto que apenas hay sistemas completamente nuevos.

Mantenimiento del software

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

48

systemsrequirements changes systems

Newsystem

Existingsystems

9

Ayuda automatizada al proceso (CASE)

La Ingeniería de Software asistida por Ordenador (CASE) es el software que se utiliza para ayudar a las actividades de desarrollo y evolución del software.

49

Automatización de actividadesEditores gráficos para el desarrollo del modelo de sistemaDiccionario de datos para gestionar las entidades del diseñoGeneradores de GUI para la construcción del interfaz de usuarioDepuradores para encontrar los fallos de los programasTraductores automatizados para generar nuevas versiones de un programa

Tipos de herramientas CASETool type ExamplesPlanning tools PERT tools, estimation tools,

spreadsheetsEditing tools Text editors, diagram editors, word

processorsChange management tools Requirements traceability tools, change

control systems

50

Configuration management tools Version management systems, systembuilding tools

Prototyping tools Very high-level languages,user interface generators

Method-support tools Design editors, data dictionaries, codegenerators

Language-processing tools Compilers, interpretersProgram analysis tools Cross reference generators, static

analysers, dynamic analysersTesting tools Test data generators, file comparatorsDebugging tools Interactive debugging systemsDocumentation tools Page layout programs, image editorsRe-engineering tools Cross-reference systems, program re-

structuring systems

Tipos de herramientas CASE

EnvironmentsWorkbenchesTools

CASEtechnology

51

Single-methodworkbenches

General-purposeworkbenches

Multi-methodworkbenches

Language-specificworkbenches

Programming TestingAnalysis anddesign

Integratedenvironments

Process-centredenvironments

FilecomparatorsCompilersEditors

Reengineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processingtools

Method support tools

Prototyping tools

Configuration

52

Configurationmanagement tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification Design Implementation Verificationand

Validation

1.4.Disciplinas de gestión de proyectos

Objetivos de la gestión de proyectos

Organizar, planificar y programar los proyectos de softwareDisciplinas y técnicas:Disciplinas y técnicas:

Planificación y estimación de costesGarantía de calidadGestión de la ConfiguraciónGestión de personal…

10

(competencias de un jefe de proyecto)Planificación del proyecto• Tareas a realizar y plan de trabajo

ó d l d l

Tareas de gestión de proyectos

Estimación del coste del proyectoSupervisión y revisión del proyecto• Para comparar los progresos y costes

reales con los planeados y hacer ajustesSelección y evaluación del personalRedacción y presentación de informes

1.4.1Planificación del proyecto

MediciónEstimaciónEl plan de proyectoHerramientas gráficas

Planificación del proyecto

Es la actividad que más tiempo consume en la administración de un proyectoEs un proceso iterativo que se completa cuando el proyecto mismo termina. El plan del proyecto debe ser revisado regularmente a la vista de la evolución del mismo

Es imposible planificar sin estimar o estimar sin medir…

Estimación del coste del software

Predecir los recursos necesarios para un determinado proceso de desarrollo de software

Preguntas:¿Cuánto esfuerzo se requiere para completar una actividad?¿Cuánto tiempo de calendario se necesita para terminar una actividad?¿Cuál es el coste total de una actividad?

Se intenta determinar una medida de la cantidad de software y de documentación asociada que produce un programador individual

Medición de la Productividad

Hay que tener en cuenta que existen muchas soluciones software con distintas características: más eficiente, más mantenible, …Hay varias propuestas de métricas para medir diversos aspectos del software

Métricas relacionadas con el tamaño. número de líneas del código fuentenúmero de instrucciones del código objeto

Métricas de la productividad

g jnúmero de páginas de la documentación...

Métricas relacionadas con la función.Basadas en una estimación de la funcionalidad del software entregado: los puntos de función.

11

Métricas de Puntos de función

number of user inputs number of user outputs

measurement parameter

3 4

countweighting factor

simple avg. complex

4 5

6 7

= =

X X

complexity multiplier

function points

number of user outputs number of user inquiries number of files number of ext.interfaces

4 3 7 5

5 4 10 7

7 6 15 10

= = =

count-total

X X X X

Las métricas basadas en volumen/unidad de tiempo (líneas/programador-mes) son imperfectas

ti t f t l fi bilid d l

Calidad y productividad

no tienen en cuenta factores como la fiabilidad, el mantenimiento, …

La productividad se puede aumentar generalmente a costa de la calidad

Técnicas de estimaciónNo hay una forma simple de hacer una estimación exacta del esfuerzo requerido para desarrollar un sistema de software

Las estimaciones iniciales se basan en información poco precisa que aportan los usuariospoco precisa que aportan los usuariosEl software puede tener que ejecutarse en ordenadores no conocidos o utilizar tecnología nuevaEl personal del proyecto es desconocido

Las estimaciones de los costes del proyecto tienden a “autorealizarse”

La estimación determina el presupuesto y el producto se ajusta para cumplir el presupuesto

Técnicas de estimaciónModelado algorítmico de costes.

Se analizan los costes de otros proyectos realizados. Se utiliza una fórmula matemática para predecir los costes del proyecto actual

Opinión de expertos.S l i ll dSe consulta a varios expertos y entre ellos acuerdan una estimación.

Estimación por analogía.Se estima por analogía con otros proyectos completados sobre el mismo dominio de aplicación.

Ley de Parkinson.El trabajo se extiende para llenar el tiempo disponible.El coste se determina según los recursos disponibles.

Precio para ganar.Se acuerda la funcionalidad aceptable para el sistema teniendo en cuenta el coste acordado.

Estructura de un plan de proyecto

Se fijan los recursos disponibles, se divide el trabajo y se crea un calendario de trabajo.

1. Introducción. Objetivos del proyecto y restricciones económicas y temporales

2. Organización del proyecto.Organización del equipo, personas involucradas y sus tareas

3. Análisis de riesgos.Posibles riesgos con su probabilidad y estrategias de reducciónde riesgos propuestas

Estructura de un plan de proyecto

4. Requisitos de recursos de hardware y de software.Precios de lo que hay que comprar y fechas de entrega

5. División del trabajo.División del proyecto en actividades, marca hitos yDivisión del proyecto en actividades, marca hitos y productos a entregar

6. Calendario del proyecto.Dependencias entre actividades, tiempo estimado requerido y asignación de personal

7. Mecanismos de supervisión e informe.Cuándo y qué tipo de informe debe producirse

12

Calendario del proyectoPartir el proyecto en tareas y estimar el tiempo y los recursos necesarios para terminar cada tareaOrganizar las tareas concurrentemente para hacer un uso óptimo de la mano de obrauso óptimo de la mano de obraMinimizar las dependencias entre tareas para evitar retrasos producidos cuando una tarea espera a otra para terminarDepende de la intuición y la experiencia de los administradores del proyecto

Diagramas para la gestión de proyectos

Las notaciones gráficas ilustran la planificación del proyectoMuestran la descomposición del proyecto en tareas.

Las tareas no deben ser demasiado pequeñas.Las tareas no deben ser demasiado pequeñas.

Los diagramas de redes de actividades muestran las dependencias de las tareas y el camino crítico

Los diagramas de barras muestran la planificación sobre el calendario

Duración de las tareas y dependenciasTarea Duración (días) Dependencias

T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4)

T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8)

Red de actividades

start

M3T6

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days20 days

5 days25/7/99

15 days

T1

M1 T3T9

M6M4

T2

Finish

T10

M7T5

T7

M2T4

M5

T8

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

15 days

25/7/99

18/7/99

10 days

T11

M8

T12

Actividades en el calendario4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1T2

M1

T7T3

M5

Start

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T11M8

T12

Finish

Asignación de personal4/7 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T8 T11

T12

T1

Fred

Jane T1

T3

T9

T2

T6 T10

T7

T5

Jane

Anne

Mary

Jim

13

Problemas en la planificación

Estimar la dificultad de los problemas, y por lo tanto el coste de desarrollar una solución, es difícilL d i id d i l lLa productividad no es proporcional al número de personas que trabajan en una tareaAñadir personal al final del proyecto produce más retraso por la sobrecarga en la comunicaciónLo inesperado siempre ocurre

1.4.2Otras actividades de gestión

Gestión de riesgosGarantía de calidadGestión de la configuración

Gestión del riesgo

El análisis de riesgos consiste en evaluar el proyecto, la tecnología y los recursos con el fin determinar y comprender la naturaleza y el origen de los riesgosel origen de los riesgos

Posibles riesgos:Comerciales (competencia, etc.)Financieros (económicos, etc.)Técnicos (¿base tecnológica sólida y probada?)De desarrollo (¿equipo experimentado?)

Tabla de riesgos

Escala 1..5

Riesgo Probabilidad Impacto Gestión y Mitigación del

Riesgo

Escala 1..51=impacto

bajo 5=catástrofe

Ejemplo: Software empotrado depende de hardware no disponible 60% 4(crítico)

Ajustar pruebas a la disponiblilidad del HW

Utilizar simulación

Garantía de calidad

Coste de los fallos encontrados en distintas etapas

100 60.00-100.00

10

1

Req.Diseño

Prog.Pruebas En uso

0.75 1.001.50

3.00

10.00

Pruebadel sistema

Conceptos de calidad

¿Cómo se aplica al software?Control de calidad: inspecciones, revisiones, pruebasAseguramiento de la calidad: análisis, auditoría e informes

Estándares de calidad: ISO 90003guía para la aplicación de la ISO 9001:2000 para la adquisición, suministro, desarrollo, instalación y mantenimiento de SOFTWARE y servicios de soporte.

14

Garantía de calidad

Revisionesformales

Proceso y

Estandares

Planifica-ción de laspruebas

Métricas

Análisis&

Informes

Nivel Características Resultados

Inicial

- Ausencia de gestión de proyectos. - El proceso de software es cambiante e irregular:- Los planes, estimaciones y calidad son impredecibles.- El rendimiento depende de la capacidad individual de los miembros del grupo.

S t bl d f ió d l

Productividad y calidad escasa.Riesgo máximo

MODELO DE MADUREZ DE LA CAPACIDAD

- Se establecen programas de formación del personal de desarrollo y mantenimiento.

Repetible

- Los procesos de software son estables y repetibles. - La organización establece políticas de gerencia de proyectos y procesos.- La planificación se basa en proyectos similares.- Existen estándares definidos y exigidos.- El proceso se enmarca en un sistema de gestión de proyectos basado en experiencias pasadas.

Productividad y calidad baja.Riesgo alto.

MODELO DE MADUREZ DE LA CAPACIDAD

Nivel Características Resultados

Definido

-Los procesos son definidos:estandarizados, documentados e institucionalizados.- Los procesos de ingeniería y gerencia son estables y seintegran en uno sólo.- Existe un entendimiento común de los procesos,funciones y responsabilidades.- La organización mantiene un grupo dedicado a la

Productividad y calidad media.Riesgo medio.

definición, mejora y difusión del proceso

Gestionado

- Los procesos son medibles o cuantificables- La productividad y la calidad se miden y registran paracada proyecto de la organización.- Se fijan metas cuantitativas de la calidad del software.-Mediante el uso de métricas de software, se crea unabase cuantitativa para la evaluación y estimación enproyectos futuros.

Productividad y calidad alta.Riesgo mínimo.

Optimizado

- Los procesos se mejoran continuamente.- La organización busca lograr el nivel máximo decapacidad.- Se incorporan nuevas tecnologías y métodos paramejorar los procesos.

Productividad y calidad total.Riesgo nulo.

SITUACIÓN DE CMM EN ESPAÑA. 5/2006

Gestión de la configuración del software

Requisitos técnicos

Cambios en Requisitos de negocio

C bi

Cambios en

datos

otros

códigoPruebas

Plan

modelos de software

Cambios en Requisitos de usuario


programas documentación

datosHay cambiosen muchas piezas

15


PROCESO

TECNICAS

HERRAMIENTAS• identificación• control de versiones• control de cambios• auditoría• informes

Existen herramientas que ayudan al control de las versiones a medida que avanzan (SourceForge)

informes• construcción

1.5. Aspectos profesionales y éticos de la Ingeniería del Software

Recomendaciones de IEEE-CS y ACMObjetivos:

Cuerpo de conocimientos de la disciplina, criterio de acreditación de los titulados, mantener un código ético

Software Engineering Body of Knowledge (SWEBOK) E á d d l I i í d l S f

87

Estándares de la Ingeniería del SoftwareSoftware Engineering Education Project Software Engineering Code of Ethics and Professional Practice

En España: Colegios profesionales

Responsabilidad del Ingeniero de Software

La Ingeniería del Software implica una serie de responsabilidades más alla de las habilidades técnicas

88

Los Ingenieros de Software deben comportarse de modo honesto y ético si quieren lograr respeto como profesionales

Es algo más que cumplir la ley

ACM/IEEE-CS: código éticoSociedad: Los ingenieros de software actuarán de manera coherente con el interés general.Cliente y empresario: Los ingenieros de software deberán actuar de tal modo que se sirvan los mejores intereses para sus clientes y empresarios,

89

mejores intereses para sus clientes y empresarios, Producto: Los ingenieros del software deberán garantizar que sus productos y las modificaciones relacionadas con ellos cumplen los estándares profesionales de mayor nivel que sea posible.Juicio: Los ingenieros del software deberán mantener integridad e independencia en su valoración profesional.

ACM/IEEE-CS: código éticoGestión: Los gestores y líderes en Ingeniería del Software suscribirán y promoverán un enfoque ético a la gestión del desarrollo y el mantenimiento del software.Profesión: Los ingenieros del software deberán

90

Profesión: Los ingenieros del software deberán progresar en la integridad y la reputación de la profesión, de forma coherente con el interés público.Compañeros: Los ingenieros del software serán justos y apoyarán a sus compañeros.Persona: Los ingenieros del software deberán participar en el aprendizaje continuo de la práctica de su profesión y promoverán un enfoque ético en ella.

16

1.6.Lenguaje Unificado de Modelado (UML)

1.6.1 ¿Qué es UML? 1.6.2 Arquitectura 1.6.3 Elementos de Modelado 1.6.4 Mecanismos de extensión

¿Por qué se necesita un lenguaje de modelado?

Los sistemas complejos son difíciles de entender si no se cuenta con un modelo que los describa

92

Disponer de un lenguaje capaz de modelarcualquier sistema software es esencial

El lenguaje de modelado tiene un valor añadido si dicho lenguaje es estándar.

¿Qué es UML?

“Unified Modeling Language”UML no es un método OOUML propone una notación y una semántica universal.Inicialmente:

“U l j ifi t i d t

93

“Un lenguaje para especificar, construir y documentar artefactos software, que pretende cubrir los conceptos de Booch, OMT y OOSE con un lenguaje simple, común y ampliamente utilizable por usuarios de otras metodologías”

UML es un un lenguaje para representar los modelos de cualquier método OO.

UML no fuerza a utilizar un método concreto (distintos tipos de problemas conducen a diferentes métodos de análisis y diseño)

UML- ObjetivosEstablecer un lenguaje visual de modelado, expresivo y sencillo (?) en su usoMantener una independencia (?) de los métodos y de los lenguajes de programación Establecer bases formales (?)

94

Establecer bases formales (?)Imponer un estándar mundial

Integrar las mejores prácticasModelar sistemas, y no únicamente softwareEstablecer las relaciones entre modelos conceptuales y ejecutablesCrear un lenguaje de modelado utilizable tanto por máquinas como por hombres

UML aglutina múltiples enfoques

RumbaughJacobson

Odell

Booch

MeyerPre y

95

UML

Embly

Gamma et. al.

Pre- yPost-condiciones

Singleton

Frameworks, patrones

Harel

Wirfs-BrockFusion

Shlaer-Mellor

State Charts

Responsabilidades

Descripciones de operaciones, Numeración de mensajes

Ciclo de vida de los objetos

Participantes en UML

Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)Digital Equipment Hewlett-Packard i-Logix (David Harel)IBM

( d ’ )

96

ICON Computing (Desmond D’Souza)Intellicorp and James Martin & co. (James Odell)MCI SystemhouseMicrosoft ObjecTimeOracle Platinium TechnologySterling SoftwareTaskonTexas Instruments Unisys

17

UML: Evolución

UML 1.1Publicación de UML 1.1Septiembre 1997

s pú

blic

os

Estandarización

UML 1.3Abril 1999:

UML 1.4

UML 2.x (08/2005)

septiembre de 2001

UML 1.5 (2003)

97Otros métodos Booch’91 OMT-1 OOSE

Booch’93 OMT-2

OOPSLA’95 Método Unificado 0.8

Junio 96 y Octubre 1996 UML 0.9 & 0.91

UML 1.0Publicación de UML 1.0Enero 1997

Colaboradores yexpertosD

ocu

men

tos

Fragmentación

Unificación

Aspectos Novedosos

Definición semi-formal del Meta-Modeloasociado

Incluye “stereotypes” como mecanismo de

98

Incluye stereotypes como mecanismo de extensibilidad (usos particulares)

Incluye un lenguaje para expresar restricciones, OCL (Object Constraint Language) desarrollado por IBM

Perspectivas de UML

UML ya es el lenguaje de modelado predominante Participación de importantes empresasAceptación como notación estándar OMG Evidencias:

99

Herramientas UML, libros, Congresos, cursos, camisetas,

Inconvenientes:Definición separada del proceso de desarrollo Falta integración con otras técnicas tales como patrones de diseño, interfaces de usuario, etc. Monopolio de conceptos, técnicas y métodos en torno a UML

Modelado con UML

Use CaseDiagramsUse Case

DiagramsDiagramas de Casos de Uso

StateDiagramsState

DiagramsDiagramas de Objetos

Use CaseDiagramsUse Case

DiagramsDiagramas deSecuencia

StateDiagramsState

DiagramsDiagramas deClases

100

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deDistribución

ScenarioDiagramsScenario

DiagramsDiagramas deEstados Diagramas de

Actividad

Modelo

“Un modelo es una descripción completa de un sistema desde una perspectiva concreta”

¿Qué debe aportar un lenguaje de modelado?

Elementos de modelado Conceptos + SemánticaNotación Representación visual de los elementosRecomendaciones Cómo usarlo

101

Un metamodelo y una semántica

Una notación gráfica

Un conjunto de recomendaciones

Principales elementos de UML:

1.6.2. Arquitectura de UML

18

Arquitectura

Arquitectura de cuatro capas, definida en la especificación Meta Object Facility del OMG:

•Meta-metamodelo: define el lenguaje para especificar metamodelos

103

p

• Metamodelo: define el lenguaje para especificar modelos

• Modelo: define el lenguaje para describir un dominio de información

• Objetos de usuario: define un dominio de información específico

Jerarquía de modelos

104

Los objetos se relacionan con las clases de las que son creados por la relación “SerInstanciaDe” (“IsInstanceOf”)

Modelado de objetos

105

Una situación parecida ocurre con las relaciones:

...Modelado de objetos

106

Metamodelado...Se basa en la idea de modelar los tipos de entidades (clases y relaciones) con que forman los modelos

d l l b l l

107

Cuando se ve la clase como un objeto, la clase es una instancia de otra clase (o meta-clase)

Metamodelado...

CityClass

NoOfInstances

Attribute

type

NoOfInstances = 1

Area

Type = Real

HasAttribute

Pop

Type = Real

Relationship

SourceCardinality TargetCardinality

IsIn.Country

SourceCardinality = 0 TargetCardinality = 1

Houston

Pop = 2M Area = 40 SM

USA


IsInHasRelationship

HasAttribute

HasRelationship

HasAttributeUML

108

CityClass

NoOfInstances

Attribute

type

NoOfInstances = 1

Area

Type = Real

HasAttribute

Pop

Type = Real

Relationship

SourceCardinality TargetCardinality

IsIn.Country

SourceCardinality = 0 TargetCardinality = 1

Houston


USA


IsInHasRelationship

HasAttribute

HasRelationship

HasAttribute

19

...Metamodelado

La idea fundamental en el metamodelado es que las entidades del modelo (ej: clases) juegan dos papeles:

l l d l till ( d l )

109

el papel de plantilla (cuando se ve como una clase) el papel de instancia (cuando se ve como instancia de la meta-clase)

La idea de ver las clases como objetos puede ser aplicada repetidamente para crear una jerarquía de instanciación del clases y objetos

Terminología de metamodelado...

110

En principio está jerarquía podría continuar hasta cualquier profundidad arbitraria, pero en la práctica no se extiende más allá de cuatro niveles de profundidad

UML se define en cuatro niveles (la guía semántica de UML representa justamente el nivel meta-modelo)

Terminología de metamodelado...

111

...Terminología de metamodelado

112

1.6.3 Elementos de modelado en UML

Elementos y RelacionesDiagramas UMLVistas

UML: NotaciónBloques

ElementosEstructuralesDe comportamientoDe Agrupación

114

De AgrupaciónDe anotación

RelacionesDiagramas

Mecanismos Mecanismos de EspecificaciónDivisionesAdornosMecanismos de extensibilidad

20

Bloques y relaciones

Métodos

AtributosClase

Métodos

AtributosObjeto

Estado

Caso de N d

115

InterfazCaso de

Uso

Actor

Nodo

Paquete Nota Componente

Dependencia Generalización

Asociación Realización

Paquetes en UML

Son elementos auxiliares de organización y pueden contener cualquier elemento de modelado.

Pueden anidarse a su vez.

116

Nombre

NombreNombre Nombre

Su utilidad final es ganar claridad

Notas

Una nota es un comentario en el diagrama, que irá unida a él o a uno de sus elementos..

117

Ejemplo de una

nota asociada a una clase

Métodos

AtributosClase

UML- Diagramas

118

Diagramas de estructura

119

Diagramas de comportamiento

120

21

UML- DiagramasElicitación de requisitos de usuario

Casos de Uso

Modelado de la estructura estática/análisis y diseñoDiagrama de Clases

Model do de l e t t e táti /implement ión

121

Modelado de la estructura estática/implementaciónDiagrama de ComponentesDiagrama de Distribución

Modelado de interacciónDiagrama de secuenciaDiagrama de comunicación

Modelado dinámicoDiagrama de EstadosDiagrama de Actividades

UML- Casos de usoIntroducido formalmente por Ivar Jacobson

De empleo en la etapa de elicitación para captar los requisitos de los usuarios

122

De fácil comprensión por parte de los usuarios de los sistemas

Precisa otras técnicas complementarias para ser utilizada en procesos de modelado OO

UML- Casos de uso

incorporarlibros«include»

«extend»

caso de uso

123

realizarpréstamoAlumno

Bibliotecarioconsultar

libro

«include»

crear nuevocódigoactor

UML- Diagrama de ClasesProviene de los diagramas de entidad-relación de Chen (‘70s)

Fueron extendidos con conceptos de AOO, como generalización y agregación (‘80s)

124

Aunque también fueron empleados por Booch, conservan el aspecto de la notación propuesta por Rumbaugh en OMT

Permiten modelar la estructura estática de los sistemas

UML- Diagrama de Clases

PersonaAutor

1..*1

generalización

asociación

navegabilidadsolicita

125

Alumno Libro

Préstamo

0..* 0..*

notaclase

multiplicidad

clase asociación

solicita

UML- Diagrama de SecuenciaDescribe la forma en la que colaboran entre sí los objetos para llevar a cabo sus respectivas responsabilidades

Cada diagrama representa la funcionalidad (parcial) de un único caso de uso

126

Permite ver cómo se suceden cronológicamente los mensajes entre los objetos

Proviene de los diagramas POSA de Buschmann

Fueron utilizados por los tres autores del UML en sus respectivos métodos previos

22

UML- Diagrama de Secuencia

objeto 1 objeto 2 objeto 3

inicio de un método

127

auto-delegación

destrucción de un objeto

retorno

activación

UML- Diagrama de Comunicación

Es otro de los diagramas de interacción que se incluye en el UML

No permite observar gráficamente la cronología de

128

No permite observar gráficamente la cronología de los mensajes

Facilita la organización de los objetos en paquetes

Destaca la conexión estática entre los objetos

UML- Diagrama de Comunicación

: Usuario1: maximo_alcanzado ( )

129

2: ejemplares disponibles ( ): bibliotecario

: Libro

: Ejemplar2.1: prestado ( )

UML- Diagrama de estadosDescribe cómo cambian de estado los objetos a medida que ocurren eventos

Cada diagrama se utiliza para representar el ciclo de vida de los objetos de una única clase (estados posibles en la vida de los

130

objetos de una única clase (estados posibles en la vida de los objetos)

Provienen de los diagramas de estado de David Harel

Los emplearon Rumbaugh en OMT, Booch en su libro de 1994 y Jacobson con la incorporación de una notación amplia

UML- Diagrama de estados

131

UML- Diagrama de Actividad

Sin antecedentes claros

Permite destacar y sincronizar las operaciones concurrentes y establecer caminos alternativos

132

concurrentes y establecer caminos alternativos

Muestra el comportamiento combinado de varias clases

Se emplea para describir comportamientos complejos

23

UML- Diagrama de ActividadBuscar

transporte

TS

133

Entra a sutrabajo

Cambia demarcha

Mira por elespejo

Toma untaxi

Se va ensu auto

1.6.4 Mecanismos generales de extensión de UML

Estereotipos. Restricciones.Valores etiquetados.

Mecanismos de UMLTipos de mecanismos

Mecanismos de EspecificaciónCompleta el aspecto gráfico

Divisiones (dicotomías)Ej: clase y objeto operación y método

135

Ej: clase y objeto, operación y método.Adornos

Se pueden añadir detalles como la multiplicidad de una relación

Mecanismos de extensibilidadEstereotipos Valores etiquetadosRestricciones (OCL)

Mecanismos de extensión:

Estereotipos

Un estereotipo es un nuevo tipo de elemento de modelado.Los estereotipos se representan encerrados en los símbolos « » o mediante iconos

136


Valores etiquetados:

Se pueden añadir propiedades a los elementos de UML. Consisten en parejas de etiqueta + valor

137

Ventana{abstract,autor=José Z.,estado=comprobada}


Restricciones:

Una restricción es una relación semántica entre elementos del modelo que especifican condiciones y proposiciones que deben de ser respetadas o mantenidas como ciertas.

138

Todas las restricciones irán siempre encerradas entre llaves ( { } ).

En particular se puede utilizar OCL (Object Constraint Language)

24

Persona Comité

Miembro de

Preside

{Subconjunto}

*

*

*

1


Restricciones:

139

{Persona.empleador=Persona.jefe.empleador}

Persona EmpresaEmpleado Empleador* 0..1

trabajador

jefe

*

0..1


Restricciones: OCLUML propone un lenguaje para expresar la navegación a través de caminos de clases en el modelo.Estas expresiones se pueden encadenar, de

140

Estas expresiones se pueden encadenar, de tal forma que el elemento más a la izquierda sea un objeto o un conjunto de objetos.

vuelo.piloto.horas_de_entrenamiento > horas.avión.horas_min

empresa.empleado[cargo=“Gerente” and Count(Subordinados)>10].

Bibliografía general

Sommerville, I. "Ingeniería del software" Pearson, 2005 (7ª ed.)Pressman, Roger S. "Ingeniería del software : un enfoque práctico MacGraw-Hill", 2005 (6ª ed) Booch, G., Jacobson, I., Rumbaugh, J. “El Lenguaje Unificado de Modelado. Guía del usuario”. Addison-Wesley/Diaz de Santos, 1999.

141

Lecturas complementarias

OMG, “OMG Unified Modeling Language Specification. Version 1.5”. Object Management Group Inc., 2003.SWEBOK: http://www.swebok.orgCódigo etico: http://seeri.etsu.edu/SpanishVersionSECode.htmColegio profesional de ingenieros en informatica de Castilla y León: http://www.cpiicyl.org/index.html

Caso de estudio: Punto de venta

142Referencia: libro de Larman

Registrar las ventas, incluyendo el detalle de los productos y su

cantidad.

Manejar un catálogo con todos los productos.

é ó

Las ventas se registran a través de un terminal punto-de-venta (TPDV)

143

Registrar los productos a través del código de barras o tecleando su identificación. Se debe mostrar el nombre y el precio del producto.

Calcular el total de la venta ¿y los descuentos?

Si se paga en efectivo, calcular las vueltas

Si se paga con tarjeta, capturar los datos del cliente/tarjeta y autorizar el pago...

Actualizar automáticamente el stock de cada producto

El cajero debe identificarse (nombre y contraseña) para utilizar un terminal

Enfoque: Se pretende independizar las capas del sistema:

Capa de Interfaz

144

Venta Pago

Registro Persistencia

Capa de objetosdel dominio

Capa de servicios

Foco principal

Documents

Objetivos del curso Ingeniería del Software I - infor.uva.esmlaguna/is1/apuntes/1-intro.pdf · 1 Ingeniería del Software I 3º I.T.I.Gestión Miguel A. Laguna Objetivos del curso