Objetivos del curso Ingeniera del Software I

3 I.T.I.Gestin
Miguel A. Laguna

Comprender los elementos caractersticos de la ingeniera del software Conocer de forma detallada los mtodos y herramientas de especificacin de requisitos Ser capaz de elaborar la especificacin completa de un sistema utilizando las herramientas, mtodos y procedimientos mostrados en el curso

Ingeniera del Software I

Introduccin a la Ingeniera del Software
Producto y Proceso Aspectos de Gestin

1. Introduccin
Ingeniera del Software I 3 I.T.I.Gestin
Miguel A. Laguna
3

Elicitacin, anlisis y especificacin de Requisitos

Modelado de actividades y casos de uso Modelado esttico (diagramas de clases) Modelado dinmico (diagramas de secuencia)

Objetivos
Presentar la disciplina de ingeniera del software y explicar su importancia Preguntas ms frecuentes (FAQs) sobre la ingeniera del software, proceso software, UML y aspectos ticos de la profesin

Desarrollo del tema

1.1. El software y la Ingeniera del software 1.2. Sistema de Informacin 1.3. Mtodo y Proceso 1.4.Disciplinas de gestin de proyectos 1.5. Aspectos profesionales y ticos de la Ingeniera del Software 1.6. Lenguaje Unificado de Modelado (UML)
6

sobre Ingeniera del Software

Qu es el Software? Cul es la importancia y coste del Software? Qu es la Ingeniera del Software? Cul es la diferencia entre Ingeniera del Software e Ingeniera de Sistemas? Qu es un sistema y un sistema de informacin? Qu es un proceso software y un mtodo de desarrollo? Cmo se gestiona el proceso? Qu es CASE (Computer-Aided Software Engineering)? Cules son las responsabilidades de un Ingeniero Software? Qu es el Lenguaje Unificado de Modelado (UML)? 7

FAQs: Preguntas frecuentes

1.1. El software y la Ingeniera del software

Qu es el Software?
Hace referencia a los programas y toda la informacin asociada y materiales necesarios para soportar su instalacin, operacin, reparacin y mejora. Para construir un nuevo elemento software se necesita: Detallar las especificaciones Disear la solucin Codificar el algoritmo Probar el programa Documentar Mantener Es lo que se conoce como el ciclo de vida del software.
9

Importancia del Software

Las economas de todos las paises son cada vez ms y ms dependientes del software Cada vez ms y ms sistemas estn controlados por software El gasto en desarrollo de software est aumentando su porcentaje en el PIB de todos las paises
10

Crisis del Software

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

Costes del Software

Los costes que representa el Software son a menudo mayores que el hardware El mantenimiento a e e o resulta esu a ms s caro a o que e el desarrollo:

En sistemas de vida larga puede ser varias veces ms caro

La Ingeniera del Software tiene que ver con el desarrollo de forma que sea econmicamente viable
12

11

Costes de los cambios

60-100x Tasa de fallos

El software se deteriora
Incremento de fallos

1.5-6x 1x Despus de entregado

cambio curva real curva ideal

Definicin

Desarrollo

Tiempo
13 14

Qu es la Ingeniera del software?

Disciplina que se ocupa del desarrollo del software.
Se enfrenta al software como un producto de ingeniera que requiere: planificacin, anlisis, diseo, implementacin, pruebas y mantenimiento. Trata de las teoras, mtodos y herramientas que los profesionales del desarrollo del software deben utilizar.

Ingeniera del software

No slo comprende los procesos tcnicos del desarrollo. Tambin, los principios ms relevantes de direccin y control de este proceso. Tambin, el desarrollo de nuevas teoras, mtodos y herramientas de apoyo a la produccin del software.
16

15

Objetivos de la Ingeniera del software

Mejorar la calidad del software Acortar los tiempos de desarrollo Aumentar la productividad Necesidad:
Incrementar la reutilizacin del software

Ingeniera del software

Los ingenieros de software deben adoptar un enfoque sistemtico y organizado en su trabajo y utilizar las herramientas y tcnicas ms apropiadas dependiendo
del problema a resolver, las restricciones del desarrollo y los recursos disponibles.
17 18

Cul es la diferencia entre Ingeniera del Software y las Ciencias de la Computacin? Las Ciencias de la Computacin tienen que ver con teoras y fundamentos La Ingeniera del Software tiene que ver con los aspectos prcticos del desarrollo del software

Cul es la diferencia entre Ingeniera del Software e Ingeniera de Sistemas? La Ingeniera de Sistemas tiene que ver con todos los aspectos del desarrollo de sistemas basados en computadoras: hardware, software e Ingeniera de procesos. Ingeniera del Software es una parte de este proceso
20

19

Disciplinas integradas en la Ingeniera del Software

Software Engineering Body of Knowledge (SWEBOK)
Requisitos del software Diseo del software Construccin del software P b del Prueba d l Software S ft Mantenimiento del software Gestin de la configuracin del software Gestin de la Ingeniera del Software Proceso de Ingeniera del Software Herramientas y mtodos de la Ingeniera del Software Calidad del software
21
Proceso de Ingeniera de Requisitos Obtencin de requisitos Anlisis de requisitos Especificacin de requisitos Validacin de requisitos Gestin de requisitos (a)

SWEBOK

Gua Gua SWEBOK SWEBOK (I) (I)

Requisitos Requisitos del del software software

Diseo Diseo del del software software

Conceptos y principios bsicos Elementos clave en el diseo del software Estructura y arquitectura del software Anlisis y evaluacin de la calidad del diseo Notaciones de diseo Estrategias y mtodos de diseo (b)

Construccin Construccin del del software software

Reduccin de la complejidad Anticipacin de la diversidad Estructuracin para la validacin Uso de estndares externos

Prueba Prueba del del software software

Conceptos bsicos y definiciones Niveles de pruebas Tcnicas de prueba Mtricas relacionadas con las pruebas Gestin del proceso de prueba

Mantenimiento Mantenimiento del del software software

Conceptos bsicos Proceso de mantenimiento Principales problemas del mantenimiento Tcnicas para el mantenimiento

(c)

(d)

(e)

22

SWEBOK
Gua Gua SWEBOK SWEBOK (II) (II) Gestin Gestin de de la la configuracin configuracin Gestin del proceso de gestin de la configuracin Id tifi Identificacin i de d l la configuracin del software Control de la configuracin del software Registro del estado de la configuracin del software Auditora de la gestin de la configuracin Gestin de la distribucin del software Gestin Gestin de de la la IS IS Gestin de la organizacin G ti del Gestin d l proceso/proyecto Medida de la IS Proceso Proceso de de IS IS Conceptos del proceso de IS Infraestructura del proceso Medida del proceso Definicin del proceso Anlisis cualitativo del proceso Implementacin y cambio del proceso Herramientas Herramientasy y mtodos mtodos de mtodos de la la IS IS Herramientas software Mtodos software Calidad Calidad del del software software Conceptos sobre calidad del software Propsito y planificacin f del SQA y de la V&V Actividades y tcnicas para SQA y V&V Mtricas aplicadas al SQA y a la V&V

1.2. Sistemas de Informacin

(a)

(b)

(c)

(d)

(e)

23

Qu es un sistema?
Un conjunto de elementos (hombres, mquinas, mtodos, reglas) en interaccin, que transforman (mediante un proceso) 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 diseado para hacer cambios en el entorno.
25

Sistema y subsistemas
Subsistemas:
Sistema fsico: Transforma un flujo fsico de entradas en un flujo fsico de salidas.
nivel operativo de la organizacin.

Sistema de gestin: controla el sistema fsico, decidiendo el comportamiento del mismo en funcin de los objetivos marcados.

26

Sistema y subsistemas
Fijacin de nuevos objetivos SISTEMA DE GESTIN OBJETIVOS Informacin de objetivos

Qu es un sistema de informacin?
Sistema de Informacin: Est encargado de
almacenar y tratar informaciones sobre el sistema fsico para ponerlas a disposicin del sistema de gestin recibir decisiones sobre su propio control interaccionar con el sistema fsico

Informacin de funcionamiento Entrada

Decisin de comportamiento

Salida SISTEMA FSICO

27 28

Qu es un sistema de informacin?
SIST. DE GESTION

Objetivos

Qu es un sistema de informacin?
Una empresa tpica cuenta con un SI compuesto por los siguientes subsistemas:

Inf. del sist. fsico

Decisin para su propio control Decisin de comportamiento

Subsistema de Recursos Humanos: Se ocupa tanto de la gestin ti del d l personal l como de d la l nmina. i Subsistema de Gestin Contable: Tanto para el control interno de la empresa como para hacer frente a las obligaciones legales. Subsistema de Gestin Comercial: Para el control de los clientes y de las ventas. Subsistema de Control de las Existencias: Del almacn y del inventario de bienes. 30

SIST. DE INFORMACION Interaccin Informacin con el sistema fsico Entrada Salida SIST. FISICO

29

Qu es un sistema de informacin automatizado?

Si todas las transformaciones significativas son efectuadas por mquinas Las tareas fundamentales de un SIA son:
Memorizacin del modelo y de la base de informacin. Tratamiento automtico (control, actualizacin, bsquedas, clculos). Captura de la informacin Salida de la informacin.

Propiedades emergentes
La compleja relacin entre los subsistemas de un sistema significa que ste es ms complejo que la suma de sus partes. L propiedades Las i d d emergentes son consecuencia de las relaciones entre los componentes. Slo pueden asegurarse y observarse cundo el sistema se considera como un todo.

31

32

Ejemplos de prop. emergentes

El peso total del sistema
Se puede calcular a partir de las propiedades de los componentes individuales.

La fiabilidad del sistema

Depende de la fiabilidad de los componentes y su interrelacin.

1.3. Mtodo y Proceso

La usabilidad

Esta propiedad compleja no depende slo del hardware y del software sino que tambin depende de los operadores y del entorno en que se utilice.
33

Qu es un mtodo?
Resulta necesario establecer un enfoque sistemtico y disciplinado para llevar a cabo un desarrollo software Definiciones:
Una metodologa de ingeniera del software es un proceso para producir software de forma organizada, empleando una coleccin de tcnicas y convenciones de notacin predefinidas (James Rumbaugh et al.) Conjunto de procedimientos, tcnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software (Mario Piattini et al.)
35

Componentes de un mtodo
Together Rose

HERRAMIENTAS TECNICAS PROCESO

UML

Proceso: Define el marco de trabajo y permite un desarrollo racional de la IS Tcnicas: Indican cmo construir tcnicamente el software. Incluyen tcnicas de modelado Herramientas: Proporcionan el soporte automtico o semiautomtico para el proceso y para las tcnicas

UP

36

Qu es un proceso software?
Un conjunto estructurado de actividades y resultados asociados que conducen a la creacin de un producto de software: Especificacin de requisitos: Definir la funcionalidad y las restricciones en sus operaciones Diseo e implementacin: Producir software que cumple la especificacin Validacin: Asegurar que hace lo que el cliente desea. Mantenimiento (o Evolucin): Seguir cumpliendo los cambios en las necesidades del usuario.
37

Actividades complementarias de gestin

Organizar, planificar y programar los proyectos de software:
Estimacin del coste del p proyecto y Planificacin y calendarizacin del proyecto Gestin de la configuracin del software Calidad del software ....

38

Especificacin de requisitos del software

Etapa en que se establece qu servicios se requieren del sistema y cules son las restricciones de operacin y desarrollo del mismo. Se obtiene un documento de requisitos, con la especificacin ifi i del d l sistema. i t Fases de la Ingeniera de Requisitos:
Estudio de viabilidad Elicitacin y anlisis de requisitos Especificacin de requisitos: los del usuario y los del sistema Validacin de requisitos

Especificacin del software

Feasibility study Requirements elicitation and analysis Requirements specification Requirements validation System models User and system requirements Requirements document

Feasibility report

39

40

Diseo e implementacin
Etapa en la que se convierte la especificacin del sistema en un sistema ejecutable Diseo del software
Describir la estructura del software software, los datos datos, las interfaces entre componentes,

Diseo e implementacin
Requirements specification Design activities Architectural design Abstract specification Interface design Component design Data structure design Algorithm design

Implementacin
Transformar la estructura anterior en un programa ejecutable
System architecture Software specification Interface specification Component specification Design products Data structure specification Algorithm specification

Las actividades de estas etapas estn muy relacionadas y pueden interpolarse.

41

42

Tcnicas de diseo
Formas sistemticas de disear el sistema Generalmente se documenta con modelos grficos:
Diagramas de flujo de datos (DFDs) Diagramas Entidad-Relacin Diagramas de estructura Modelos orientados a objetos
43

Validacin del Software

La verificacin y la validacin pretenden demostrar que un sistema es conforme con su especificacin y que resuelve los requisitos del cliente La prueba del sistema implica ejecutar el sistema con los casos de prueba que se obtuvieron en la especificacin.

44

Etapas en el proceso de pruebas

Prueba de unidades Prueba de mdulos
Se comprueban los componentes individuales Se prueban colecciones de componentes dependientes Los mdulos se integran en subsistemas y se prueban. Sobre todo se prueba el acoplamiento de las interfaces. Se prueban las interacciones entre los subsistemas y las propiedades emergentes. Se prueba con datos reales para comprobar que el sistema es aceptable por el cliente.
45

Etapas en el proceso de pruebas

Requirements specification System specification System design Detailed design

Prueba de subsistemas Prueba del sistema

Acceptance test plan

System integration test plan

Sub-system integration test plan

Module and unit code and tess

Service

Acceptance test

System integration test

Sub-system integration test

Prueba de aceptacin

46

Mantenimiento del software

El software es intrnsecamente flexible y puede cambiar. De la misma forma que los requisitos cambian segn cambian las circunstancias del negocio, negocio el software que da soporte al negocio debe tambin desarrollarse y cambiar. Aunque histricamente ha existido una separacin entre el desarrollo y la mantenimiento (o evolucin) esto es cada vez ms irrelevante, puesto que apenas hay sistemas completamente nuevos.
47

Mantenimiento del software

Define system requirements

Assess existing systems

Propose system changes

Modify systems

Existing systems

New system

48

Ayuda automatizada al proceso (CASE)

La Ingeniera de Software asistida por Ordenador (CASE) es el software que se utiliza para ayudar a las actividades de desarrollo y evolucin del software. Automatizacin de actividades
Editores grficos para el desarrollo del modelo de sistema Diccionario de datos para gestionar las entidades del diseo Generadores de GUI para la construccin del interfaz de usuario Depuradores para encontrar los fallos de los programas Traductores automatizados para generar nuevas versiones de un programa
49

Tipos de herramientas CASE

Tool type Planning tools Editing tools Change management tools Configuration management tools Prototyping tools Method-support tools Language-processing tools Program analysis tools Testing tools Debugging tools Documentation tools Re-engineering tools Examples PERT tools, estimation tools, spreadsheets Text editors, diagram editors, word processors Requirements traceability tools, change control systems Version management systems, system building tools Very high-level languages, user interface generators Design editors, data dictionaries, code generators Compilers, interpreters Cross reference generators, static analysers, dynamic analysers Test data generators, file comparators Interactive debugging systems Page layout programs, image editors Cross-reference systems, program restructuring systems

50

Reengineering tools

Tipos de herramientas CASE

CASE technology

Testing tools Debugging tools Program analysis tools Language-processing tools Method support tools

Tools

Workbenches

Environments

Prototyping tools Configuration management tools

Editors

Compilers

File comparators

Integrated environments

Process-centred environments

Change management tools Documentation tools Editing tools

Analysis and design

Programming

Testing

Planning tools

Multi-method workbenches

Single-method workbenches

General-purpose workbenches

Language-specific workbenches

Specification
51

Design

Implementation

Verification and Validation 52

1.4. Disciplinas de gestin de proyectos

Objetivos de la gestin de proyectos

Organizar, planificar y programar los proyectos de software Disciplinas y tcnicas:
Planificacin y estimacin de costes Garanta de calidad Gestin de la Configuracin Gestin de personal

Tareas de gestin de proyectos

(competencias de un jefe de proyecto) Planificacin del proyecto
Tareas a realizar y plan de trabajo

1.4.1

Planificacin del proyecto

Medicin Estimacin El plan de proyecto Herramientas grficas

Estimacin del d l coste del d l proyecto Supervisin y revisin del proyecto

Para comparar los progresos y costes reales con los planeados y hacer ajustes

Seleccin y evaluacin del personal Redaccin y presentacin de informes

Planificacin del proyecto

Es la actividad que ms tiempo consume en la administracin de un proyecto Es un proceso iterativo que se completa cuando el proyecto mismo termina. El plan del proyecto debe ser revisado regularmente a la vista deestimar la evolucin Es imposible planificar sin o del mismo

Estimacin del coste del software

Predecir los recursos necesarios para un determinado proceso de desarrollo de software Preguntas:
Cunto esfuerzo se requiere para completar una actividad? Cunto tiempo de calendario se necesita para terminar una actividad? Cul es el coste total de una actividad?

estimar sin medir

Medicin de la Productividad
Se intenta determinar una medida de la cantidad de software y de documentacin asociada que produce un programador individual Hay que tener en cuenta que existen muchas soluciones software con distintas caractersticas: ms eficiente, ms mantenible, Hay varias propuestas de mtricas para medir diversos aspectos del software

Mtricas de la productividad
Mtricas relacionadas con el tamao.
nmero de lneas del cdigo fuente nmero de instrucciones del cdigo g objeto j nmero de pginas de la documentacin...

Mtricas relacionadas con la funcin.

Basadas en una estimacin de la funcionalidad del software entregado: los puntos de funcin.

10

Mtricas de Puntos de funcin

measurement parameter count number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces count-total complexity multiplier function points weighting factor simple avg. complex X 3 X 4 X 3 X 7 X 5 4 5 4 10 7 6 7 6 15 10 = = = = =

Calidad y productividad
Las mtricas basadas en volumen/unidad de tiempo (lneas/programador-mes) son imperfectas
no tienen ti en cuenta t factores f t como la l fiabilidad, fi bilid d el l mantenimiento,

La productividad se puede aumentar generalmente a costa de la calidad

Tcnicas de estimacin
No hay una forma simple de hacer una estimacin exacta del esfuerzo requerido para desarrollar un sistema de software
Las estimaciones iniciales se basan en informacin poco precisa que aportan los usuarios El software puede tener que ejecutarse en ordenadores no conocidos o utilizar tecnologa nueva El personal del proyecto es desconocido

Tcnicas de estimacin
Modelado algortmico de costes. Se analizan los costes de otros proyectos realizados. Se utiliza una frmula matemtica para predecir los costes del proyecto actual Opinin de expertos. S consulta Se l a varios i expertos y entre ellos ll acuerdan d una estimacin. Estimacin por analoga. Se estima por analoga con otros proyectos completados sobre el mismo dominio de aplicacin. Ley de Parkinson. El trabajo se extiende para llenar el tiempo disponible. El coste se determina segn los recursos disponibles. Precio para ganar. Se acuerda la funcionalidad aceptable para el sistema teniendo en cuenta el coste acordado.

Las estimaciones de los costes del proyecto tienden a autorealizarse

La estimacin determina el presupuesto y el producto se ajusta para cumplir el presupuesto

Estructura de un plan de proyecto

Se fijan los recursos disponibles, se divide el trabajo y se crea un calendario de trabajo.
1. Introduccin.
Objetivos del proyecto y restricciones econmicas y temporales

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. Divisin del trabajo.

Divisin del proyecto en actividades, marca hitos y productos a entregar

6. Calendario del proyecto.

Dependencias entre actividades, tiempo estimado requerido y asignacin de personal

2. Organizacin del proyecto.

Organizacin del equipo, personas involucradas y sus tareas

7. Mecanismos de supervisin e informe.

Cundo y qu tipo de informe debe producirse

3. Anlisis de riesgos.
Posibles riesgos con su probabilidad y estrategias de reduccin de riesgos propuestas

11

Calendario del proyecto

Partir el proyecto en tareas y estimar el tiempo y los recursos necesarios para terminar cada tarea Organizar las tareas concurrentemente para hacer un uso ptimo de la mano de obra Minimizar las dependencias entre tareas para evitar retrasos producidos cuando una tarea espera a otra para terminar Depende de la intuicin y la experiencia de los administradores del proyecto

Diagramas para la gestin de proyectos

Las notaciones grficas ilustran la planificacin del proyecto Muestran la descomposicin del proyecto en tareas.
Las tareas no deben ser demasiado pequeas.

Los diagramas de redes de actividades muestran las dependencias de las tareas y el camino crtico Los diagramas de barras muestran la planificacin sobre el calendario

Duracin de las tareas y dependencias

Tarea T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 T11 T12 Duracin (das) 8 15 15 10 10 5 20 25 15 15 7 10 Dependencias

Red de actividades
14/7/99 8 days T1 25/7/99 M1 15 days T3 5 days T6 M3 15 days T2 10 days T4 18/7/99 M5 25 days T8 19/9/99 Finish 25/7/99 M2 T7 10 days T5 11/8/99 M7 15 days T10 20 days 7 days T11 5/9/99 M8 10 days T12 4/8/99 M4 15 days T9 25/8/99 M6 4/7/99 start

T1 (M1) T2, T4 (M2) T1, T2 (M3) T1 (M1) T4 (M5) T3, T6 (M4) T5, T7 (M7) T9 (M6) T11 (M8)

Actividades en el calendario
4/7 T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Finish 11/7 Start 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

Asignacin de personal
4/7 Fred T4 T8 Jane T1 T3 T9 Anne T2 T6 Jim Mary T7 T5 T10 T11 T12 11/7 18/7 25/ 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

12

Problemas en la planificacin
Estimar la dificultad de los problemas, y por lo tanto el coste de desarrollar una solucin, es difcil L productividad La d i id d no es proporcional i l al l nmero de personas que trabajan en una tarea Aadir personal al final del proyecto produce ms retraso por la sobrecarga en la comunicacin Lo inesperado siempre ocurre

1.4.2 Otras actividades de gestin

Gestin de riesgos Garanta de calidad Gestin de la configuracin

Gestin del riesgo

El anlisis de riesgos consiste en evaluar el proyecto, la tecnologa y los recursos con el fin determinar y comprender la naturaleza y el origen de los riesgos Posibles riesgos:
Comerciales (competencia, etc.) Financieros (econmicos, etc.) Tcnicos (base tecnolgica slida y probada?) De desarrollo (equipo experimentado?)

Tabla de riesgos
Riesgo Probabilidad Impacto Gestin y Mitigacin del Riesgo

Ejemplo:

Escala 1..5 1=impacto bajo 5=catstrofe

Software empotrado depende de hardware no disponible

60%

4(crtico)

Ajustar pruebas a la disponiblilidad del HW Utilizar simulacin

Garanta de calidad
Coste de los fallos encontrados en distintas etapas
100 60.00-100.00

Conceptos de calidad
Cmo se aplica al software? Control de calidad: inspecciones, revisiones, pruebas Aseguramiento de la calidad: anlisis, auditora e informes Estndares de calidad: ISO 90003
gua para la aplicacin de la ISO 9001:2000 para la adquisicin, suministro, desarrollo, instalacin y mantenimiento de SOFTWARE y servicios de soporte.

10 1.50 1 0.75 1.00

10.00 3.00

Req.

Diseo

Pruebas En uso Prueba Prog. del sistema

13

MODELO DE MADUREZ DE LA CAPACIDAD Garanta de calidad

Nivel Caractersticas
- Ausencia de gestin 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. - Se S establecen t bl programas de d formacin f i del d l personal de desarrollo y mantenimiento. - Los procesos de software son estables y repetibles. - La organizacin establece polticas de gerencia de proyectos y procesos. - La planificacin se basa en proyectos similares. - Existen estndares definidos y exigidos. - El proceso se enmarca en un sistema de gestin de proyectos basado en experiencias pasadas.

Resultados

Proceso y Estandares Revisiones formales

Inicial

Productividad y calidad escasa. Riesgo mximo

Anlisis & Informes Mtricas

Planificacin de las pruebas

Repetible

Productividad y calidad baja. Riesgo alto.

MODELO DE MADUREZ DE LA CAPACIDAD

Nivel Caractersticas Resultados

SITUACIN DE CMM EN ESPAA. 5/2006

Definido

-Los procesos son definidos: estandarizados, documentados e institucionalizados. - Los procesos de ingeniera y gerencia son estables y se Productividad y integran en uno slo. - Existe un entendimiento comn de los procesos, calidad media. Riesgo medio. funciones y responsabilidades. - La organizacin mantiene un grupo dedicado a la definicin, mejora y difusin del proceso - Los procesos son medibles o cuantificables - La productividad y la calidad se miden y registran para cada proyecto de la organizacin. Productividad y calidad alta. - Se fijan metas cuantitativas de la calidad del software. -Mediante el uso de mtricas de software, se crea una Riesgo mnimo. base cuantitativa para la evaluacin y estimacin en proyectos futuros. - Los procesos se mejoran continuamente. - La organizacin busca lograr el nivel mximo de capacidad. - Se incorporan nuevas tecnologas y mtodos para mejorar los procesos. Productividad y calidad total. Riesgo nulo.

Gestionado

Optimizado

Gestin de la configuracin del software

Cambios en Requisitos de negocio Cambios en Requisitos tcnicos C bi en Cambios Requisitos de usuario otros

Gestin de la configuracin del software

programas

documentacin

modelos de software Plan Pruebas cdigo

datos

Hay cambios en muchas piezas

datos

14

Gestin de la configuracin del software

HERRAMIENTAS TECNICAS PROCESO

identificacin control de versiones control de cambios auditora informes construccin

1.5. Aspectos profesionales y ticos de la Ingeniera del Software

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

Recomendaciones de IEEE-CS y ACM

Objetivos:
Cuerpo de conocimientos de la disciplina, criterio de acreditacin de los titulados, mantener un cdigo tico

Responsabilidad del Ingeniero de Software

La Ingeniera del Software implica una serie de responsabilidades ms alla de las habilidades tcnicas Los Ingenieros de Software deben comportarse de modo honesto y tico si quieren lograr respeto como profesionales Es algo ms que cumplir la ley

Software Engineering Body of Knowledge (SWEBOK) E d Estndares de d la l Ingeniera I i del d l Software S f Software Engineering Education Project Software Engineering Code of Ethics and Professional Practice En Espaa: Colegios profesionales

87

88

ACM/IEEE-CS: cdigo tico

Sociedad: Los ingenieros de software actuarn de manera coherente con el inters general. Cliente y empresario: Los ingenieros de software debern actuar de tal modo que se sirvan los mejores intereses para sus clientes y empresarios, Producto: Los ingenieros del software debern garantizar que sus productos y las modificaciones relacionadas con ellos cumplen los estndares profesionales de mayor nivel que sea posible. Juicio: Los ingenieros del software debern mantener integridad e independencia en su valoracin profesional.

ACM/IEEE-CS: cdigo tico

Gestin: Los gestores y lderes en Ingeniera del Software suscribirn y promovern un enfoque tico a la gestin del desarrollo y el mantenimiento del software. Profesin: Los ingenieros del software debern progresar en la integridad y la reputacin de la profesin, de forma coherente con el inters pblico. Compaeros: Los ingenieros del software sern justos y apoyarn a sus compaeros. Persona: Los ingenieros del software debern participar en el aprendizaje continuo de la prctica de su profesin y promovern un enfoque tico en ella.

89

90

15

Por qu se necesita un lenguaje de modelado? 1.6.Lenguaje Unificado de Modelado (UML)

Los sistemas complejos son difciles de entender si no se cuenta con un modelo que los describa Disponer de un lenguaje capaz de modelar cualquier sistema software es esencial 1.6.1 1.6.2 1.6.3 1.6.4 Qu es UML? Arquitectura Elementos de Modelado Mecanismos de extensin El lenguaje de modelado tiene un valor aadido si dicho lenguaje es estndar.
92

Qu es UML?
Unified Modeling Language UML no es un mtodo OO UML propone una notacin y una semntica universal. Inicialmente:
Un lenguaje U l j para especificar, ifi construir t i yd documentar t artefactos software, que pretende cubrir los conceptos de Booch, OMT y OOSE con un lenguaje simple, comn y ampliamente utilizable por usuarios de otras metodologas UML es un un lenguaje para representar los modelos de cualquier mtodo OO.

UML- Objetivos
Establecer un lenguaje visual de modelado, expresivo y sencillo (?) en su uso Mantener una independencia (?) de los mtodos y de los lenguajes de programacin Establecer bases formales (?) Imponer un estndar mundial Integrar las mejores prcticas Modelar sistemas, y no nicamente software Establecer las relaciones entre modelos conceptuales y ejecutables Crear un lenguaje de modelado utilizable tanto por mquinas como por hombres
94

UML no fuerza a utilizar un mtodo concreto (distintos tipos de problemas conducen a diferentes mtodos de anlisis y diseo) 93

UML aglutina mltiples enfoques

Rumbaugh Booch Odell Shlaer-Mellor
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 ICON Computing (Desmond ( d DSouza) ) Intellicorp and James Martin & co. (James Odell) MCI Systemhouse Microsoft ObjecTime Oracle Platinium Technology Sterling Software Taskon Texas Instruments Unisys

Jacobson Meyer

UML

Pre- y Pre Post-condiciones

Harel
State Charts

Gamma et. al.

Frameworks, patrones

Embly
Singleton

Wirfs-Brock Fusion
Descripciones de operaciones, Numeracin de mensajes Responsabilidades

95

96

16

UML: Evolucin
septiembre de 2001

UML 2.x (08/2005)

UML 1.5

(2003)

Aspectos Novedosos
Definicin semi-formal del Meta-Modelo asociado Incluye stereotypes stereotypes como mecanismo de extensibilidad (usos particulares) Incluye un lenguaje para expresar restricciones, OCL (Object Constraint Language) desarrollado por IBM

UML 1.4 UML 1.3 UML 1.1

Estandarizacin

Documentos s pblicos

Abril 1999: Publicacin de UML 1.1 Septiembre 1997 Publicacin de UML 1.0 Enero 1997 Junio 96 y Octubre 1996 OOPSLA95

UML 1.0
Unificacin

UML 0.9 & 0.91 Colaboradores y expertos Mtodo Unificado 0.8 OMT-2

Booch93 Otros mtodos Booch91

Fragmentacin
OMT-1 OOSE
97 98

Perspectivas de UML
UML ya es el lenguaje de modelado predominante Participacin de importantes empresas Aceptacin como notacin estndar OMG Evidencias:
Herramientas UML, libros, Congresos, cursos, camisetas,

Modelado con UML

State State de Diagramas Diagrams Diagrams Clases

Use Case Use Case de Diagramas Diagrams Diagrams Secuencia Scenario Scenario de Diagramas Diagrams Diagrams Colaboracin Scenario Scenario de Diagramas Diagrams Diagrams Estados

Use Case Use Case de Diagramas Diagrams Diagrams Casos de Uso

State State de Diagramas Diagrams Diagrams Objetos State State de Diagramas Diagrams Diagrams Componentes

Inconvenientes:
Definicin separada del proceso de desarrollo Falta integracin con otras tcnicas tales como patrones de diseo, interfaces de usuario, etc. Monopolio de conceptos, tcnicas y mtodos en torno a UML
99

Modelo

Diagramas de Actividad

Component Component Diagrams Diagramas de Diagrams

Distribucin

Un modelo es una descripcin completa de un sistema desde una perspectiva concreta

100

Qu debe aportar un lenguaje de modelado?

Elementos de modelado Conceptos + Semntica Notacin Representacin visual de los elementos Recomendaciones Cmo usarlo

1.6.2. Arquitectura de UML

Principales elementos de UML:

Un metamodelo y una semntica Una notacin grfica Un conjunto de recomendaciones
101

17

Arquitectura
Arquitectura de cuatro capas, definida en la especificacin Meta Object Facility del OMG:
Meta-metamodelo: define el lenguaje para especificar p metamodelos Metamodelo: define el lenguaje para especificar modelos Modelo: define el lenguaje para describir un dominio de informacin Objetos de usuario: define un dominio de informacin especfico
103

Jerarqua de modelos

104

Modelado de objetos
Los objetos se relacionan con las clases de las que son creados por la relacin SerInstanciaDe (IsInstanceOf)

...Modelado de objetos
Una situacin parecida ocurre con las relaciones:

105

106

Metamodelado...
Se basa en la idea de modelar los tipos de entidades (clases y relaciones) con que forman los modelos Cuando d se ve la l clase l como un objeto, b la l clase l es una instancia de otra clase (o meta-clase)

Metamodelado...
Pop
Type = Real

UML

Attribute
type

Area
Type = Real HasAttribute

HasAttribute

HasAttribute

Class
NoOfInstances

City
NoOfInstances = 1

Houston
Pop = 2M Area = 40 SM

HasRelationship

HasRelationship IsIn

Relationship
SourceCardinality TargetCardinality

IsIn.Country
SourceCardinality = 0 TargetCardinality = 1

USA
Pop = 250M Area = 200 SM

Pop
Type = Real

Attribute
type

Area
Type = Real HasAttribute

HasAttribute

HasAttribute

Class
NoOfInstances

City
NoOfInstances = 1

Houston
Pop = 2M Area = 40 SM

HasRelationship

HasRelationship IsIn

Relationship
SourceCardinality TargetCardinality

IsIn.Country
SourceCardinality = 0 TargetCardinality = 1

USA
Pop = 250M Area = 200 SM

107

108

18

...Metamodelado
La idea fundamental en el metamodelado es que las entidades del modelo (ej: clases) juegan dos papeles:
el l papel l de d plantilla l till (cuando ( d se ve como una clase) l ) el papel de instancia (cuando se ve como instancia de la meta-clase)

Terminologa de metamodelado...
La idea de ver las clases como objetos puede ser aplicada repetidamente para crear una jerarqua de instanciacin del clases y objetos En principio est jerarqua podra continuar hasta cualquier profundidad arbitraria, pero en la prctica no se extiende ms all de cuatro niveles de profundidad

109

110

Terminologa de metamodelado...
UML se define en cuatro niveles (la gua semntica de UML representa justamente el nivel metamodelo)

...Terminologa de metamodelado

111

112

UML: Notacin
1.6.3 Elementos de modelado en UML
Elementos y Relaciones Diagramas UML Vistas Bloques
Elementos
Estructurales De comportamiento De Agrupacin De anotacin

Relaciones Diagramas

Mecanismos
Mecanismos de Especificacin Divisiones Adornos Mecanismos de extensibilidad

114

19

Bloques y relaciones
Clase Atributos Mtodos Atributos Estado Mtodos Objeto

Paquetes en UML
Son elementos auxiliares de organizacin y pueden contener cualquier elemento de modelado. Pueden anidarse a su vez.

Caso de Uso Actor

N d Nodo

Interfaz

Su utilidad final es ganar claridad

Paquete

Nota

Componente

Nombre
Dependencia Asociacin Generalizacin Realizacin

Nombre

Nombre

Nombre

115

116

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

UML- Diagramas

Ejemplo de una

Clase Atributos Mtodos

nota asociada a una clase

117

118

Diagramas de estructura

Diagramas de comportamiento

119

120

20

UML- Diagramas
Elicitacin de requisitos de usuario
Casos de Uso

UML- Casos de uso

Introducido formalmente por Ivar Jacobson De empleo en la etapa de elicitacin para captar los requisitos de los usuarios De fcil comprensin por parte de los usuarios de los sistemas Precisa otras tcnicas complementarias para ser utilizada en procesos de modelado OO

Modelado de la estructura esttica/anlisis y diseo Model do de la Modelado l estructura e t t e esttica/implementacin tti /implement in
Diagrama de Componentes Diagrama de Distribucin Diagrama de Clases

Modelado de interaccin

Diagrama de secuencia Diagrama de comunicacin

Modelado dinmico

Diagrama de Estados Diagrama de Actividades

121

122

UML- Casos de uso

incorporar libros include extend consultar libro include realizar prstamo crear nuevo cdigo

caso de uso

UML- Diagrama de Clases

Proviene de los diagramas de entidad-relacin de Chen (70s) Fueron extendidos con conceptos de AOO, como generalizacin y agregacin (80s)

actor

Bibliotecario

Aunque tambin fueron empleados por Booch, conservan el aspecto de la notacin propuesta por Rumbaugh en OMT Permiten modelar la estructura esttica de los sistemas

Alumno

123

124

UML- Diagrama de Clases

Persona asociacin generalizacin Alumno 0..* Autor 1 solicita 0..* 1..* Libro navegabilidad

UML- Diagrama de Secuencia

Describe 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 Permite ver cmo se suceden cronolgicamente los mensajes entre los objetos Proviene de los diagramas POSA de Buschmann

clase clase asociacin

Prstamo

nota Fueron utilizados por los tres autores del UML en sus respectivos mtodos previos multiplicidad
125 126

21

UML- Diagrama de Secuencia

objeto 1 objeto 2 objeto 3

UML- Diagrama de Comunicacin

Es otro de los diagramas de interaccin que se incluye en el UML

inicio de un mtodo auto-delegacin

No permite observar grficamente la cronologa de los mensajes Facilita la organizacin de los objetos en paquetes

activacin retorno destruccin de un objeto

Destaca la conexin esttica entre los objetos

127

128

UML- Diagrama de Comunicacin

1: maximo_alcanzado ( ) : Usuario

UML- Diagrama de estados

Describe cmo 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 objetos) Provienen de los diagramas de estado de David Harel

: bibliotecario 2: ejemplares disponibles ( )

: Libro

: Ejemplar

2.1: prestado ( )

Los emplearon Rumbaugh en OMT, Booch en su libro de 1994 y Jacobson con la incorporacin de una notacin amplia

129

130

UML- Diagrama de estados

UML- Diagrama de Actividad

Sin antecedentes claros Permite destacar y sincronizar las operaciones concurrentes y establecer caminos alternativos Muestra el comportamiento combinado de varias clases Se emplea para describir comportamientos complejos

131

132

22

UML- Diagrama de Actividad

Buscar transporte

1.6.4 Mecanismos generales de extensin de UML

Estereotipos. Restricciones. Valores etiquetados.

Se va en S su auto

Toma un T taxi

Cambia de marcha

Mira por el espejo

Entra a su trabajo

133

Mecanismos de extensin:

Mecanismos de UML
Tipos de mecanismos
Mecanismos de Especificacin
Completa el aspecto grfico

Estereotipos
Un estereotipo es un nuevo tipo de elemento de modelado. Los estereotipos se representan encerrados en los smbolos o mediante iconos

Divisiones (dicotomas)
Ej: clase y objeto, objeto operacin y mtodo. mtodo

Adornos
Se pueden aadir detalles como la multiplicidad de una relacin

Mecanismos de extensibilidad
Estereotipos Valores etiquetados Restricciones (OCL)
135 136

Mecanismos de extensin:

Mecanismos de extensin:

Valores etiquetados:
Se pueden aadir propiedades a los elementos de UML. Consisten en parejas de etiqueta + valor

Restricciones:

Una restriccin es una relacin semntica entre elementos del modelo que especifican condiciones y proposiciones que deben de ser respetadas o mantenidas como ciertas. Todas las restricciones irn siempre encerradas entre llaves ( { } ). En particular se puede utilizar OCL (Object Constraint Language)

Ventana

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

137

138

23

Mecanismos de extensin:

Restricciones:
* Persona 1 trabajador jefe 0..1 * Persona

Mecanismos de extensin:

Restricciones: OCL
* Comit * Empleador 0..1 Empresa

Miembro de {Subconjunto} Preside Empleado *

UML propone un lenguaje para expresar la navegacin a travs de caminos de clases en el modelo. Estas expresiones se pueden encadenar, de tal forma que el elemento ms a la izquierda sea un objeto o un conjunto de objetos.
vuelo.piloto.horas_de_entrenamiento > horas.avin.horas_min

{Persona.empleador= Persona.jefe.empleador}
139

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

140

Bibliografa general
Sommerville, I. "Ingeniera del software" Pearson, 2005 (7 ed.) Pressman, Roger S. "Ingeniera del software : un enfoque prctico MacGraw-Hill", 2005 (6 ed) Booch, G., Jacobson, I., Rumbaugh, J. El Lenguaje Unificado de Modelado. Gua del usuario. Addison-Wesley/Diaz de Santos, 1999.

Caso de estudio: Punto de venta

Lecturas complementarias
OMG, OMG Unified Modeling Language Specification. Version 1.5. Object Management Group Inc., 2003.

SWEBOK: http://www.swebok.org Cdigo etico: http://seeri.etsu.edu/SpanishVersionSECode.htm Colegio profesional de ingenieros en informatica de Castilla y Len: http://www.cpiicyl.org/index.html
141

Referencia: libro de Larman

142

Las ventas se registran a travs de un terminal punto-de-venta (TPDV)

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

Enfoque: Se pretende independizar las capas del sistema:

Capa de Interfaz

Manejar un catlogo con todos los productos. Registrar los productos a travs del cdigo de barras o tecleando su identificacin. 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 automticamente el stock de cada producto El cajero debe identificarse (nombre y contrasea) para utilizar un 143 terminal
144
Capa de objetos del dominio
Venta Pago

Foco principal

Capa de servicios

Registro

Persistencia

24